TCP/IP 之 滑动窗口和延迟确认

滑动窗口(Sliding window)是一种流量控制技术。早期的网络通信中,通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况,同时发送数据,导致中间节点阻塞掉包,谁也发不了数据,所以就有了滑动窗口机制来解决此问题。(百度百科)

其实滑动窗口就是互相的协商, 发送的数据不能超过对方的处理能力.

  1. #1 表示已经发送并确认的数据
  2. #2 表示已经发送但是并未 Ack 的数据
  3. #3 表示即将要发送还未发送的数据
  4. #4 表示没有发送的数据

其中黑色的框就是我们说的滑动窗口, 它的大小为 20 字节, 当 #2 Ack回来的时候, 会重新返回对方的窗口大小, 然后发送方进行动态调节.

上图展示了发送窗口和接收窗口两端的实际执行情况, 有意思的是最后出现了 窗口占满(window=0) 的情况, 通常这种情况会发生 RST 标志位进行重置. 这个不再此次范围讨论里面.

上图中我们可以看到 Server 端每次根据自身消费数据缓冲区情况,重新计算 RCV.WND 值大小, ACK 响应给 Client 端都会携带 window 字段, Client 端根据 Server端的 window 大小, 重新调整了 发送窗口 大小.

Nagle算法 和 延迟确认

Naggle

但是如果频繁的进行 TCP小包 通信, 网络效率是非常低下的, 对于发送方来说我们可以使用 Nagle 算法来提高传输效率

只有收到前一数据的 ACK 消息时或者超时40ms、达到了 MSS 值时, Nagle 算法才发送下一份数据。 TCP 套接字默认使用的 Nagle 算法交换数据, 因此最大限度地进行缓冲, 直到收到 ACK。

可以使用 TCP_NODELAY 参数关闭掉 Naggle 算法.

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章