本文不会完整的介绍TCP,只有在涉及到的时候随便提一下。不适合对TCP整个流程和框架没有了解过的人阅读。
1 TCP 四次挥手中的TIME_WAIT状态的意义何在。
下图四次挥手的一个大体的流程
我们发现在A发送完一个最后一个ACK后,B一收到这个ACK就证明关闭请求已经被确认了,所以可以直接关闭.但是这时候A怎么知道这个ACK是否已经到达了对端呢?这个时候为了保证双方能够正常关闭,就引入了一个MSL时间,MSL定义
”一个电磁波信号在地球最大的存活时间 ” . 所以该ACK存活一个MSL时间,然后我们假设该ACK丢失了,那么B在超时机制下会重新发送一个FIN,那么这个FIN 也要一个MSL时间后才从地球上消失,所以为了保证A的新连接不会被延迟的FIN终结掉,A在TIME_WAIT阶段要等待2个MSL时间
2 每个TCP连接实现单一计时器的可行性
我们知道对于每个数据报文都会有一个超时时间,在超时时间内如果没有收到一个ACK的话,那么我们就需要进行重传了,最简单的实现就是对于每个数据报都启动一个定时器,不过这样子有个很大的弊端就是太耗内存了,数据一大肯定计算器顶不顺。所以,现在业界默认都是按照每个TCP的重传计时由单一计时器来实现的。
单一计时器必须实现的2点:
key1 : 每一个报文在长期收不到确认都必须可以超时;
Key2 : 这个长期收不到中长期不能和测量的RTT相隔太远。
RFC2988定义一套很简单的原则:
a.发送TCP分段时,如果还没有重传定时器开启,那么开启它。
b.发送TCP分段时,如果已经有重传定时器开启,不再开启它。
c.收到一个非冗余ACK时,如果有数据在传输中,重新开启重传定时器。
d.收到一个非冗余ACK时,如果没有数据在传输中,则关闭重传定时器。
下图是按照RFC定义的粗略的画了一下流程
从图中我们看到,首先发送数据1的时候,发现没有定时器,所以就开启了定时器(RFC a),再发数据2的时候,定时器已经存在了,所以不再启动定时器(RFC b)。在RTO_1时间内,如果没有ACK到来,那么就要启动重传机制了。
情景一: 假设数据1 的ack在RTO_1快要结束的时候到来,那么由于这个是非冗余的ack,所以要重置计时器(RFC c),那么数据2的超时重传时间要多少呢,如图所示接近于RTO_1 + RTO_2 ,差不多是2倍的RTT时间。如果我们按照这种最坏的设想(数据报3,4都在RTO快到的时候才收到ACK)推算下去,假设发送数据1,2,3,4的时间分别是T1,T2,T3,T4
数据1 的超时时间: time1 = RTO_1
数据2 的超时时间: time2 = RTO_1 + RTO_2 -(T2 - T1)
数据3的超时时间: time3 = RTO_1 + RTO_2 + RTO3 - (T3 - T1)
数据4的超时时间: time4 = RTO_1 + RTO_2 + RTO3 + RTO4 -(T4 - T1)
RTT(往返时间)的计算公式为:
那么在数据1,2,3,4所处的不同阶段的RTT值分配以RTT1,RTT2 .... 来表示
RTT1 = N #N代表初始值
RTT2 = RTT1 + g(RTO1 + RTO 2 - (T2 - T1)) = RTT1 + g time2
RTT3 = RTT2 + g timer3
RTT4 = RTT3 + g time4
我们会发现其实每个RTT 都与当时的time是紧密联系的,所以基本上满足Key_2。
情景二:
这种情况基本上是情况一的调转过来,新的超时时间如下:
数据4 的超时时间: time1 = RTO_1 + (T4 - T1)
数据3 的超时时间: time2 = RTO_1 + RTO_2 -(T3 - T1)
数据2的超时时间: time3 = RTO_1 + RTO_2 + RTO3 - (T2 - T1)
数据1的超时时间: time4 = RTO_1 + RTO_2 + RTO3 + RTO4
在这种情况里其实会引入一个机制---快速重传,因为TCP的ACK机制是按照接收方接受窗口中已接受到的数据中最大序号(max_seq)来填写ack值:ack = max_seq + 1,所以当B接受到数据4,3,2的时候,ack值都是数据1的第一个字节序号,只要连续三次重复ack同个数据后,就会启动快速重传机制,这时候数据1就不等超时时间了,直接就进行重发。
还有一个问题就是,由于定时器和数据报之间是一种一对多的关系,那么如果超时了,
我要如何区分是哪个数据报超时了?
在一个发送窗口中有2种数据,一种是已经发送出去但是还没收到确认的数据,一种是还未发送的数据。上图中2个指针分别指示这两种数据,左侧的指针还标识着一个发送窗口的左边界,而第二个指针指示着下个要发送的数据位置。按照这个图来看,我们很容易就可以发现,如果过了超时时间了,那么要重传的一定就是左侧的指针指向的位置,因为如果该元素收到ACK后,那么必然会像161一样随着发送窗口的滑动而不在这个窗口范围内。
3 接受窗口为0时的处理方案
在TCP的头部里面可以看到有2个字节的字段来标识窗口大小。
当接收窗口的值为0的时候,那么这时候发送端就不能再发数据,即使发了数据也会被扔掉。当接收窗口不为0的时候,接收端会发送一个报文来告诉发送端当前新的窗口值,但是考虑如果发送端的这个通告报文丢失了,那么发送端以为接收端的窗口值为0,接收端以为发送端没有数据,那么就会造成无限等待的死锁状况发生。所以TCP为了防止这种死锁状况,设定了一个坚持定时器(persist timer)规定在这种情况下发送端按无限次的指数避让间隔发出窗口探测包(1字节),TCP接收端立刻确认并更新通知窗口
4 糊涂窗口的场景和解决方案
假设接收窗口为0,接收端的处理程序反应很慢,每次只处理一个字节,如果现在就发送一个报文通知发送端现在接收窗口=1,那么按照定义来看,这时候发送端要发送一个“特殊”的报文即“至少20字节的头部 + 1字节的数据”,如果按照这样的趋势进行交互下去无疑会浪费很多的带宽,这就是糊涂窗口的症状。
解决方案: 当接受窗口再次达到MSS(最大报文长度)的一半大小的时候才发送一个报文来通告这个新的窗口值。在这个期间对发送端的探测报文都回应窗口值为0.