TCP协议（保留位URG、PSH，定时器，连接的建立和断开）

●TCP段格式

       其中，6位保留位分别为：紧急标志URG、推送标志PSH、确认标志ACK、复位标志RST、链接同步标志SYN以及结束标志FIN。

○紧急标志URG(U)：

       占1位，当URG=1时，表示紧急指针字段有效。通知发送方本数据报文段中含有紧急数据，需要马上传输，这时发送方不会等到缓冲区满再发送，而是直接优先将该报文段发送出去。 

○推送标志PSH(P)：

       占1位，PSH=1时，表示当前报文段需要请求推送（Push）操作，即接收方TCP收到推送标志位为1的报文时 ，就立即提交给接收的应用进程，而不必等到整个缓存都填满后再向上提交。 

○URG和PSH的区别： 

       ①紧急URG将紧急报文字段插入到普通报文字段的前面，而推送PSH是利用紧急数据重新直接创建一个报文，并立即发送出去； 
       ②URG=1，表示紧急数据(数据从序号开始到紧急指针指向字节)不经过缓冲区直接交付应用进程，PSH=1表示尽快推送，将数据先交给缓冲区，不等待缓冲区填满（默认TCP/IP是将数据缓存到一定上限，才交由上层）就交给上层程序； 
       ③URG=1交给上层进程的只有紧急数据，PSH=1交给上层程序的是紧急数据和之前接收方缓冲区排好序的数据。

●TCP定时器

       对于每个连接，TCP 管理着四个不同的定时器：重传定时器、坚持定时器、保活定时器 以及 2MSL 定时器。

○重传定时器

       为了防止丢失数据报文段或确认报文段，当 TCP 发送报文段时，启动了特定报文段的重传计时器，若在计时器超时之前收到对报文段的确认，则撤销计时器。若收到特定报文段的确认之前计时器已经超时，则重传该报文，并把计时器复位。这里最重要的是超时的时间计算，有关该时间的请查阅具体的算法，这里不再进行记录。

○坚持定时器

       坚持定时器主要是解决零窗口大小通知可能导致的死锁问题。刚开始接收端向发送端发送了一个零窗口报文段。在不久之后，如果接收端的缓存区有一定的空间可以接收数据，此时接收端就会向发送端发送了一个非零窗口大小的报文段(即窗口更新)，但是这个非零窗口大小的报文段在传输过程中丢失，导致发送端无法接收到该非零窗口大小的报文段。因此，发送端就会一直处于等待非零窗口大小的报文端通知，由于接收端已经发送了非零窗口大小的报文段，而且并不知道该报文段在传输过程中丢失，则接收端会一直处于等待接收数据状态，如果没有任何措施的话，这个死锁的局面会一直延续下去。

       为了解决上面这个问题，TCP 为每一个连接设有一个坚持定时器(也叫持续计数器)。当发送端收到零窗口的确认时，就启动坚持计时器，当坚持计时器截止期到时，发送端就发送一个特殊的报文段，叫探测报文段，这个报文段只有一个字节的数据。探测报文段有序号，但序号永远不需要确认，甚至在计算对其他部分数据的确认时这个序号也被忽略。探测报文段提醒接收端，确认已丢失，必须重传。

       坚持计时器的截止期设置为重传时间的值，但若没有收到来自接收端的响应，则发送另一个探测报文段，并将坚持计时器的值加倍和并复位，发送端继续发送探测报文段，将坚持计时器的值加倍和复位，直到这个值增大到阈值为止(通常为 60 秒)。在此之后，发送端每隔 60s 就发送一个报文段，直到窗口重新打开为止。

       坚持定时器的原理：当 TCP 服务器收到了客户端的 0 滑动窗口报文时，启动一个定时器来计时，并在定时器溢出的时向客户端查询窗口是否已经增大，如果得到非零的窗口就重新开始发送数据，如果得到零窗口就再开一个新的定时器准备下一次查询。

○保活定时器

       保活定时器是为了应对 TCP 连接双方出现长时间的没有数据传输的情况。如果客户端与服务器建立了 TCP 连接之后，客户端由于某种原因导致主机故障，则服务器就不能收到来自客户端的数据，而服务器不可能一直处于等待状态，保活定时器就是用来解决这个问题的。服务器每收到一次客户端的数据，就重新设置保活定时器，通常为 2 小时，如果 2 小时没有收到客户端的数据，服务端就发送一个探测报文，以后每隔75秒发送一次，如果连续发送10次探测报文段后仍没有收到客户端的响应，服务器就认为客户端出现了故障，就可以终止这个连接。

○2MSL 定时器

        2MSL 定时器主要是解决以下两种情况：

       TIME_WAIT 确保有足够的时间让对端收到了ACK，如果被动关闭的那方没有收到 ACK，就会触发被动端重发 FIN。因为最后一次确认应答 ACK 报文段很有可能丢失，因而使被动关闭方处于在LIST_ACK 状态的，此时被动关闭方会重发这个 FIN+ACK 报文段，在这等待的 2MSL 时间内主动关闭方重新收到这个被动关闭方重发的 FIN+ACK 报文段，因此，主动关闭方会重新发送确认应答信息，从而重新启动 2MSL 计时器，直到通信双方都进入 CLOSED 状态。如果主动关闭方在 TIME_WAIT 状态不等待一段时间就直接释放连接并进入 CLOSED 状态，那么主动关闭方无法收到来自被动关闭方重发的 FIN+ACK 报文段，也就不会再发送一次确认 ACK 报文段，因此被动关闭方就无法正常进入CLOSED 状态。

       有足够的时间让这个连接不会跟后面的连接混在一起。防止已失效的请求连接出现在本连接中。在连接处于 2MSL 等待时，任何迟到的报文段将被丢弃，因为处于 2MSL等待的、由该插口(插口是IP和端口对的意思，socket)定义的连接在这段时间内将不能被再用，这样就可以使下一个新的连接中不会出现这种旧的连接之前延迟的报文段。

●TCP三次握手和四次挥手

○1~3是建立连接的过程，也叫“三次握手”，进行“三次”握手的原因是：

       “已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。

○7~10是断开连接的过程，也叫“四次挥手”，“四次”挥手的原因是：

       四次挥手是因为TCP为全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。

  首先调用close()发起主动关闭的一方会进入TIME_WAIT状态。进入TIME_WAIT状态的TCP连接需要经过2MSL才能回到初始状态，这意味着TIME_WAIT的典型持续时间为1-4分钟。TIME_WAIT存在的原因是：

  ①为实现TCP这种全双工连接的可靠释放
       TCP释放连接4次挥手过程中，假设的发起端来连接一方（图中为client）发送的ACK在网络中丢失，那么由于TCP的重传机制，另一方（图中为server）需要重发其FIN，在该FIN到达client之前，client必须维护这条连接的状态。也就是说，这条TCP连接对应的local_ip, local_port资源不能被立即释放或重新分配。直到重发的FIN达到，client也重发ACK后，该TCP连接才能断开。如果client不进入TIME_WAIT以维护其连接状态，则当server重发的FIN达到时，client的TCP传输层会以RST包响应对方，这会被对方认为有错误发生。
        ②为使旧的数据包在网络因过期而消失
       假设TCP协议中不存在TIME_WAIT状态的限制，再假设当前有一条TCP连接：local_ip, local_port, remote_ip,remote_port。我们先关闭，接着很快以相同的四元组建立一条新连接，因为TCP协议栈是无法区分前后两条TCP连接的不同的，就可能发生这样的情况：前一条TCP连接由local peer发送的数据到达remote peer后，会被该remot peer的TCP传输层当做当前TCP连接的正常数据接收并向上传递至应用层（而事实上，在我们假设的场景下，这些旧数据到达remote peer前，旧连接已断开且一条由相同四元组构成的新TCP连接已建立，因此，这些旧数据是不应该被向上传递至应用层的），从而引起数据错乱进而导致各种无法预知的诡异现象。作为一种可靠的传输协议，TCP必须在协议层面考虑并避免这种情况的发生。
       也就是说，local peer主动调用close后，此时的TCP连接进入TIME_WAIT状态，处于该状态下的TCP连接不能立即以同样的四元组建立新连接，即发起active close的那方占用的local port在TIME_WAIT期间不能再被重新分配。由于TIME_WAIT状态持续时间为2MSL，这样保证了旧TCP连接双工链路中的旧数据包均因过期（超过MSL）而消失，此后，就可以用相同的四元组建立一条新连接而不会发生前后两次连接数据错乱的情况。