TCP 三次握手和四次挥手与重传

一、看图说话

1、基于套接字的TCP服务器/客户端程序流程

 



2、TCP三次握手建立连接

 

  



3、TCP四次交互断开连接





 

4、TCP状态转移图





 

这张图看不懂的话解释在计算机网络第四版P274。解释下MSL：最长分节生存周期，他代表了IP数据报载网络上的最长生命周期。保证该连接上的数据包在网络中全部消失。

二、TCP重传

1、重传的原因

1）发端计时器超时

TCP每发送一个报文段，就对这个报文段设置一次计时器。当计时器超时而没有收到确认时，就重传该报文。

注：原来报文哪去了呢？两种可能：1）在中间节点丢了。2）还在路上，走的慢。

对于第一种情况：接收端是不知情的，而对于第二种情况，接收端表现为收到两个一摸一样的报文。

2）快重传

原理说明：自己来张图吧。





 

就是说在发送端一连收到4个ack报文，其中3个重复报文时，就立即重传相应的报文而不等到定时器超时。

注：1）原来报文的去向以上同。

2）重传报文可以与原报文不同，就是说重传报文长度可以比原报文长也可以比原报文短等。

3）说明下逆序问题。还没到快重传的时候，走丢的包就出现了。这时候接收端保留逆序包，发送端不用对其进行重传。

 

 



2、重传的判定

TCM监测点要求计算一次HTTP过程的重传率，公式：重传率=重传报文数/有效报文数

其中有效报文数：指的是除了纯ACK包外的报文总数。因为纯ACK包没有重传的说法。

重传报文的判定分双向进行，现在的算法（简要说明）：

设置一个变量MaxSeq，初始化为0.每来一个包，查看其seq，如果该seq大于MaxSeq，则

MaxSeq = seq，否则判定为重传包。

该算法的缺点：目前看到的情况，无法区分逆序后来的包和重传包。如同逆序图所示:其实M3只是迟到了，并没有重传，但我们的算法却把它判定为重传报文。

不知有人对这个问题有所研究没，欢迎发表意见。

三、因重传引起的问题

1.         在测量过程中发现某个网站TCP连接的重置率特别高，抓包后发现，原来都是重传惹的祸（FIN
ACK包重传）。

图示：





 

对照状态图，可以理解当服务器收到客户端第一个Ack报文时，该次TCP连接就关闭了。再次收到ACK，就出错。