TCP 滑动窗口

隔一个报文段确认”的策略实际就是因为 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标志

慢启动

出现原因
- 在发送与接收方存在多个路由器和速率较慢的链路时
- - 中间路由器必须缓存分组包，并可能耗尽存储器的空间
  - 严重降低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

posted on 2017-08-05 10:52 Aiapple 阅读(773) 评论(0) 编辑收藏举报