TCP协议详解

TCP报文格式

TCP流量控制

流量控制（flow  control）就是让发送方的发送速率不要太快，要让接收方来得及接收。

在连接建立时，B告知A它的rwnd(recevicer window)=400,发送方的发送窗口不能超过接收方给出的接收窗口。

其中存在一个问题：B向A发送了一个零窗口，但是过了不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd=400的报文段，但是这个报文段传输过程中丢了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。

为了解决上诉这个问题，TCP为每一个连接设有一个持续计数器（persistence  timer）。只要TCP连接的一方收到对方的零窗口通知，就启动持续计数器。若持续计数器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零，那么收到这个报文段的一方就重新设置持续计数器。如果窗口不是零，那么死锁的僵局就可以打破了。

TCP拥塞控制

拥塞控制：就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

拥塞控制所要做的都有一个前提，就是网络能够承受现有网络的网络负荷。

流量控制与拥塞控制的区别：

流量控制：往往是指点到点通信的控制，是个端到端的问题（接收端控制发送端）。流量控制要做的就是抑制发送端发送数据的速率，以便接收端来得及接收。

拥塞控制：是一个全局性的过程，涉及到所有主机、所有的路由器、以及与降低网络传输性能有关的所有因素。

 

慢开始

首先cwnd(congestion window)=1,每经过一个传输轮次，拥塞窗口cwnd就加倍。

拥塞避免算法

每经过一个传输轮次，拥塞窗口cwnd就加1。

首先进行慢开始算法，当cwnd = ssthresh时，执行拥塞避免算法。

当发生超时时，ssthresh=cwnd / 2 , cwnd = 1,执行慢开始算法。

快恢复

当收到3次重复a的ck时，ssthresh=cwnd / 2 , cwnd = ssthresh,执行拥塞避免算法。

快重传

快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。发送方只要一连收到3个重复确认，就知道接收方确实没有收到报文段，因而立即进行重传。这样就不会出现超时，发送方也不会认为出现了网络拥塞。

 

TCP三次握手四次挥手

TCP报文段首部格式：

序号seq：本报文段所发送的数据的第一个字节的序号；

确认号ack：期待收到对方下一个报文段的第一个数据字节的序号；

确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效；

同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段；

                  若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文；

终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接。
 

三次握手

三次握手确认的信息：

（1）序列号

（2）窗口大小（接收缓冲区大小）

（3）MSS

第一个SYN连接会指明本端所能接收的最大报文段MSS（Maximum Segment Size）以太网通常大小为1460，Internet:536

两端会取最低的MSS来通信。IP的DF位置1，中间路由器MTU小于MSS，则收到ICMP的报错会调整MSS。

连接建立超时：

指数退避：每隔2s,4s,8s,16s发送SYN请求，30s后停止。

 

为什么是三次握手，而不是两次握手或者四次握手呢？

不可以两次握手的原因：

为了防止已经失效的链接请求报文段突然又传送到了B，因而产生错误。比如下面这种情况：A发出的第一个连接请求报文段并没有丢失，而是在网路结点长时间滞留了，以致于延误到连接释放以后的某个时间段才到达B。本来这是一个早已失效的报文段。但是B收到此失效的链接请求报文段后，就误认为A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。

对于上面这种情况，如果不进行第三次握手，B发出确认后就认为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。

如果采用了三次握手，由于A实际上并没有发出建立连接请求，所以不会理睬B的确认，也不会向B发送数据。B由于收不到确认，就知道A并没有要求建立连接。

不需要四次握手的原因：

有人可能会说A发出第三次握手的信息后在没有接收到B的请求就已经进入了连接状态，那如果A的这个确认包丢失或者滞留了怎么办？

我们需要明白一点，完全可靠的通信协议是不存在的。在经过三次握手之后，客户端和服务端已经可以确认之前的通信状况，都收到了确认信息。所以即便再增加握手次数也不能保证后面的通信完全可靠，所以是没有必要的。
 

四次挥手

为什么A在TIME-WAIT状态必须等待2MSL的时间呢？

1、为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着A重传一次确认，重新启动2MSL计时器。最后，A和B都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段，这样，B就无法按照正常步骤进入CLOSED状态。

2、防止已失效的连接请求报文段出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。