更好阅读体验:《理解 TCP 和 UDP》— By Gitbook
TCP 是一种提供可靠性交付的协议。
也就是说,通过 TCP 连接传输的数据,无差错、不丢失、不重复、并且按序到达。
但是在网络中相连两端之间的介质,是复杂的,并不确保数据的可靠性交付,那么 TCP 是怎么样解决问题的?
这就需要了解 TCP 的几种技术:
滑动窗口
超时重传
流量控制
拥塞控制
下面来分别讲一下这几种技术的实现原理。
超时重传
重传时机
TCP 报文段在传输的过程中,下面的情况都是有可能发生的:
数据包中途丢失;
数据包顺利到达,但对方发送的 ACK 报文中途丢失;
数据包顺利到达,但对方异常未响应 ACK 或被对方丢弃;
当出现这些异常情况时,TCP 就会超时重传。
TCP 每发送一个报文段,就对这个报文段设置一次计时器。只要计时器设置的重传时间到了,但还没有收到确认,就重传这一报文段,这个就叫做「超时重传」。
重传算法
先认识两个概念
RTO ( Retransmission Time-Out ) 重传超时时间
指发送端发送数据后、重传数据前等待接收方收到该数据 ACK 报文的时间。
大白话就是,需要等待多长时间还没收到确认,就重新传一次。
RTO 的设置对于重传非常重要:
设长了,重发就慢,没有效率,性能差;
设短了,重发得就快,会增加网络拥塞,导致更多的超时,更多的超时导致更多的重发。
RTT ( Round Trip Time ) 连接往返时间
指发送端从发送 TCP 包开始到接收它的 ACK 报文之间所耗费的时间。
而在实际的网络传输中,RTT 的值每次都是随机的,无法事先预预知。
TCP 通过测量来获得连接当前 RTT 的一个估计值,并以该 RTT 估计值为基准来设置当前的 RTO。
这就引入了一类算法的称呼:自适应重传算法(Adaptive Restransmission Algorithm)
这类算法的关键就在于对当前 RTT 的准确估计,以便适时调整 RTO。
关于自适应重传算法,经历过多次的迭代和修正。
从 1981 年的 RFC793 提及的经典算法,到 1987 年 Karn 提出的 Karn/Partridge 算法,再到后来的 1988 年的 Jacobson / Karels 算法。
最后的这个算法在被用在今天的 TCP 协议中(Linux的源代码在:tcp_rtt_estimator
)。
自适应重传算法的发展读者有兴趣可以参考其他资料,在这里我拎一个现在在用的算法出来讲讲,随意感受一下。
Jacobson / Karels 算法
1988年,有人推出来了一个新的算法,这个算法叫 Jacobson / Karels Algorithm(参看RFC6298)。
其计算公式:
SRTT = SRTT + α ( RTT – SRTT ) —— 计算平滑 RTT
DevRTT = ( 1-β ) DevRTT + β ( | RTT - SRTT | ) ——计算平滑 RTT 和真实的差距(加权移动平均)
RTO= µ SRTT + ∂ DevRTT
其中:
α
、β
、μ
、∂
是可以调整的参数,在 RFC6298 中给出了对应的参考值,而在Linux下,α = 0.125,β = 0.25, μ = 1,∂ = 4;SRTT 是 Smoothed RTT 的意思,是 RTT 的平滑计算值,即根据每次测量的 RTT 和旧的 RTT 进行运算,得出新的 RTT。SRTT 的值,会在每一次测量到 RTT 之后进行更新;
DevRTT 是 Deviation RTT 的意思,根据每次测量的 RTT 和旧的 SRTT 值进行运算,得出新的 DevRTT;
由算法可以知道 RTO 的值会根据每次测量的 RTT 值变化而变化,基本要点是 TCP 监视每个连接的性能,由每一个 TCP 的连接情况推算出合适的 RTO 值,根据不同的网络情况,自动修改 RTO 值,以适应负责的网络变化。
拥塞控制
滑动窗口 Sliding Window
滑动窗口协议比较复杂,也是 TCP 协议的精髓所在。
TCP 头里有一个字段叫 Window,叫 Advertised-Window,这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据,而不会导致接收端处理不过来。
滑动窗口分为「接收窗口」和「发送窗口」
因为 TCP 协议是全双工的,会话的双方都可以同时接收和发送,那么就需要各自维护一个「发送窗口」和「接收窗口」。
发送窗口
大小取决于对端通告的接受窗口。
只有收到对端对于本端发送窗口内字节的 ACK 确认,才会移动发送窗口的左边界。
下图是发送窗口的示意图:
对于发送窗口,在缓存内的数据有四种状态:
#1 已发送,并得到接收方 ACK 确认;
#2 已发送,但还未收到接收方 ACK;
#3 未发送,但接收方允许发送,接收方还有空间
#4 未发送,且接收方不允许发送,接收方没有空间
如果下一刻,收到了接收方对于 32-36 字节序的数据包的 ACK 确认,那么发送方的窗口就会发生「滑动」。
并且发送下一个 46-51 字节序的数据包。
滑动窗口的概念,描述了 TCP 的数据是怎么发送,以及怎么接收的。
TCP 的滑动窗口是动态的,我们可以想象成小学常见的一个数学题,一个水池,体积 V,每小时进水量 V1, 出水量 V2。
当水池满了就不允许再注入了,如果有个液压系统控制水池大小,那么就可以控制水的注入速率和量了。
应用程序可以根据自身的处理能力变化,通过 API 来控制本端 TCP 接收窗口的大小,来进行流量控制。
接收窗口
大小取决于应用、系统、硬件的限制。
下图是接收窗口的示意图(找不到图,唯有自己画了):
相对于发送窗口,接受窗口在缓存内的数据只有三种状态:
已接收已确认;
未接收,准备接收;
未接收,并未准备接收;
下一刻接收到来自发送端的 32-36 数据包,然后回送 ACK 确认报,并且移动接收窗口。
另外接收端相对于发送端还有不同的一点,只有前面所有的段都确认的情况下才会移动左边界,
在前面还有字节未接收但收到后面字节的情况下,窗口不会移动,并不对后续字节确认,以此确保对端会对这些数据重传。
假如 32-36 字节不是一个报文段的,而是每个字节一个报文段的话,那么就会分成了 5 个报文段。
在实际的网络环境中,不能确保是按序收到的,其中会有一些早达到,一些迟到达。
如图中的 34、35 字节序,先收到了,接收窗口也不会移动。
因为有可能 32、33 字节序会出现丢包或者超时,这时就需要发送端重发报文段了。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。