TCP 滑动窗口

• 滑动窗口协议
  • 流量控制方法
• PUSH
• 慢启动

 

隔一个报文段确认”的策略实际就是由于 delayed ack，同时接收到两个待确认的ACK包时，就当即发送确认包。

 

滑动窗口实例

---

 

解决了快的发送方-》慢的接收方

 

• 发送方发送 4个背靠背（back-to-back）的数据报文段去填充接收方的窗口，而后停下来等待一个ACK。
• 接收方发送 ACK（报文段 8），但通告其窗口大小为 0，这说明接收方已收到全部数据，但这些数据都在接收方的 TCP缓冲区，由于应用程序尚未机会读取这些数据。
• 另外一个ACK，窗口更新 在17.4ms后发送，代表接收方如今能够接收另外的4096个字节的数据。
• 发送方发送最后4个报文段(10~13)，再次填充了接收方的窗口。
• • 注意到报文段13中包括两个比特标志：PUSH和FIN。
• 随后从接收方传来另外两个 ACK，它们确认了最后的 4096字节的数据（从4097到8192字节）和FIN（标号为8192）

 

滑动窗口协议：

 

 

 

• 窗口大小6个字节，覆盖第4-9字节
  • 说明字节1-3 是发送并被确认的
• 窗口大小起始于确认序号字段。
  • 发送方能够计算它的可用窗口，
    • 好比窗口大小6，已经被确认1-3，发送但未被确认4-6，则可用窗口大小3，起始第7序号
    • 可用窗口代表有多少数据能够当即被发送
• 当接收方确认数据后，这个滑动窗口不时地向右移动。
• 窗口左右边沿的运动现象的三个术语
  • 左边沿向右靠近----窗口合拢
    • 现象发生在数据被发送和确认时。
  • 右边沿向右靠近----窗口张开
    • 将容许发送更多的数据
    • 现象发生在接收端进程读取已经确认的数据并释放了TCP的接收缓存时。
  • 右边沿向左靠近----窗口收缩
    • RFC 强烈建议不要使用这种方式
    • 但TCP 有特殊场景会使用到
• 若是左边沿到达右边沿，则称其为一个零窗口，此时发送方不可以发送任何数据

 

 

对应上图的滑动窗口协议的动态性

 

 

窗口大小

由接收方提供的窗口的大小一般能够由接收进程控制，这将影响 TCP的性能

 

PUSH标志

• 发送方使用该标志通知接收方将全部接收到的数据所有提交给接收进程
• 包括与PUSH一块儿传送的数据以及接收方TCP 已经接收到的其余数据

 

慢启动

• 出现缘由
• • 在发送与接收方存在多个路由器和速率较慢的链路时
  • • 中间路由器必须缓存分组包，并可能耗尽存储器的空间
    • 严重下降TCP链接的吞吐量
• 工做原理
• • 观察新分组进入网络的速率应该与另外一端返回确认的速率相同而进行工做。
  • 慢启动为发送方增长另外一个窗口：拥塞窗口(congestion window) cwnd.
  • • 当创建TCP链接时，拥塞窗口被初始化为1个报文段（即另外一端通告的报文段大小）
    • 每收到一个ACK，拥塞窗口就增长一个报文段，拥塞窗口从1增长到2，便可以发送两个报文段。
    • 发送方取拥塞窗口与通告窗口中的最小值做为发送上限。
• 拥塞窗口是发送方使用的流量控制
• 通告窗口则是接收方使用的流量控制

 

 

 

capacity(bit) = bandwidth(b/s) * round-trip(s)

            容量  = 带宽 * 延时

 

电话线每193bit 有1个做为 帧同步

所以原始比特率 1544000 b/s --》 实际比特率 1544000/193=8000,1544000-8000=1536000 b/s

 

计算滑动窗口大小：

有人抱怨说美国和日本之间的一个 128 ms时延、速率为256 000 b/s的链

路吞吐量为120 000 b/s（利用率为47 %），而当链路经过卫星时其吞吐量则为33 000 b/s（利用

率为13％）。试问在这两种状况下窗口大小各为多少（假定卫星链路的时延为 500 ms）？卫星

链路的窗口大小应该如何调整？

 

1.吞吐量12000 b/s * 延时128ms =15360 b  / 8 =1920 bit

 

2.链路经过卫星

吞吐量33000 b/s * 延时500ms =16500 b /8 = 2062 bit