计算机网络之TCP协议段格式及解析 ，TCP定时器

一 TCP协议段格式及解析

TCP协议与UDP一样，也是有源和目的端口号，以及32位序列号，32位确认序号，窗口大小等，另外还设置有URG,ACK,PSH,RST,SYN,FIN六个控制位，下来我们来一一解释这些内容。

（1）32位序号：序号是递增的，是对自己信息进行编号。

（2）32位确认序号：是自己对对方 发来信息的确认。

（3）URG：  紧急指针当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的                     数据），而不要按原来的排队顺序来传送。 当URG置1时，发送应用进程就告诉发送方的TCP有紧急数据要传送。于                       是发送方TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数 据。这 时要与手中紧                     急指针字段配合使用。

（4）ACK：确认字符，表示发来的数据是否已经确认接收无误。

（5）PSH：当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。这                      种情况下，TCP就可以使用推送(push)操作。这时， 发送方TCP把PSH置1，并立即创建一个报文段发送出去。接                          收方TCP收到PSH=1的报文段，就尽快的(即“推送”向前)交付接收应用进程，而不再等到整个缓存都填满了后再向上                    交付。

（6）RST：复位，当RST=1时，表明TCP连接中出现差错，必须释放连接，然后再重新建立连接。RST置1还用来拒绝打开一个连                     接。

（7）SYN：同步，想新建连接时，要设置SYN

（8）FIN：断开连接时，设FIN为有效

URG和PSH的区别

（1）在给进程交付数据的时候，URG只有紧急数据，且紧急数据不进入接收缓冲区而直接交付给进程；而PSH在个进程交付数据的时候，            交付的数据是在缓冲区排好序的数据及当前报文中的数据。

（2）URG在前端处理，接收到数据就马上进行操作。而PSH在处理的后端。

 二  为什么是三次握手四次挥手

1.为什么建立TCP连接需要三次握手？

如果在client发起连接的连接请求报文在网络中没有丢失，而是在某个网络节点长时间滞留了，导致延迟到达

server。本来这是一个已经失效的连接报文，但是server接收到这个连接报文之后，会认为client发起了新的连接，于是向client发送

确认报文段。此时因为没有了连接的3次握手，client不会对server的确认报文作出回应，也不会向server发送数据，server就以为连

接已经建立，一直在空等client的数据，这样server的这一部分网络资源就被浪费了。所以之所以要三次握手是为了应对网络中存在

的延迟的server重复接收的问题

2.为什么断开TCP连接需要进行四次挥手 ？

因为TCP连接是全双工的网络协议，允许同时通信的双方同时进行数据的收发，同样也允许收发两个方向的连接被独立关闭，以避

免client数据发送完毕，向server发送FIN关闭连接，而server还有发送到client的数据没有发送完毕的情况。所以关闭TCP连接需要

进行四次握手，每次关闭一个方向上的连接需要FIN和ACK两次握手。

3.主动断开链接的一方为什么要进入TIME_WAIT状态

在TCP连接中，当被动关闭连接的一方(图中client)发送的FIN报文到达时，被动关闭连接的一方会发送ACK确认报文，并且进入TIME_WAIT状态，并且等待2MSL

时间段。因为（1）被动关闭连接的一方(图中的server)在一段时间内没有收到对方的ACK确认数据包，会重新发送FIN数据包，使得对方莫名其妙。（2因而主动

关闭连接的一方需要停留在等待状态以处理对方重新发送的FIN数据包。否则他会回应一个RST数据包给被动关闭连接的一方，）在TIME_WAIT状态下，不允许应

用程序在当前ip和端口上和之前通信的client建立一个新的连接。这样就能避免新的连接收到之前的ip和端口一致的连接残存在网络中的数据包。这也是

TIME_WAIT状态的等待时间被设置为2MSL的原因，以确保网络上当前连接两个方向上尚未接收的TCP报文已经全部消失。

三 常见的TCP定时器

常见的TCP定时器有七种

1.建立连接定时器(connection-establishment timer)

 在TCP建立连接的过程中，在发送SYN时，会启动一个定时器(默认是3秒)，如果SYN包丢失了， 那么3秒以后会重新发送SYN包的(当然还会启动一个新的定时器， 设置成6秒超时)，当然也不会一直没完没了的发SYN包 。

1. 2.重传定时器(retransmission timer)

2.   重传定时器在TCP发送数据时设定，在计时器超时后没有收到返回的确认ACK，发送端就会重新发送队列中需要重传的报文段。使用RTO重传计时器一般有如下规则：

   1. （1）当TCP发送了位于发送队列最前端的报文段后就启动这个RTO计时器；
   2. （2）如果队列为空则停止计时器，否则重启计时器；
   3. （3）当计时器超时后，TCP会重传发送队列最前端的报文段；
   4. （4）当一个或者多个报文段被累计确认后，这个或者这些报文段会被清除出队列

3. 3.延迟应答定时器(delayed ACK timer)
4. 延迟应答也被成为捎带ACK， 这个定时器是在延迟应答的时候使用的。 为什么要延迟应答呢？ 延迟应答是为了提高网络传输的效率
5. 4.坚持定时器(persist timer)
6. 
   

7. 如果窗口大小为 0会发生什么，如果这个确认ACK丢失了，则双方就有可能因为等待对方而使连接终止：接收方等待接收数据（因

8. 为它已经向发送方通告了一个非0的窗口），而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器 (persist timer)来周期性地向接收方查询，以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查 (window probe)。

9. 么情况呢？这将有效地阻止发送方传送数据，直到窗口变为非0为止。接收端窗口变为非0后，就会发送一个确认ACK指明需要的报文段序号以及窗口大小。

10. 5.保活定时器(keepalive timer)
11. 
    
12. 在TCP连接建立的时候指定了SO_KEEPALIVE，保活定时器才会生效。如果客户端和服务端长时间没有数据交互，那么需要保活定时器来判断是否对端还活着，但是这个其实很不实用，因为默认是2小时没有数据交互才探测，时间实在是太长了。如果你真的要确认对端是否活着， 那么应该自己实现心跳包，而不是依赖于这个保活定时器
    
13. 6.FIN_WAIT_2定时器(FIN_WAIT_2 timer)
14. 
    
15.  主动关闭的一端调用完close以后（即发FIN给被动关闭的一端， 并且收到其对FIN的确认ACK）则进入FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一段宕机等原因，导致主动关闭的一端不能收到被动关闭的一端发来的FIN，主动关闭的一段总不能一直傻等着，占着资源不撒手吧？这个时候就需要FIN_WAIT_2定时器出马了， 如果在该定时器超时的时候，还是没收到被动关闭一端发来的FIN，那么不好意思， 不等了， 直接释放这个链接。 
    
16. 7.TIME_WAIT定时器 (TIME_WAIT timer, 也叫2MSL timer)

TIME_WAIT是主动关闭连接的一端最后进入的状态， 而不是直接变成CLOSED的状态；万一被动关闭的一端在超时时间内没有收到最后一个ACK， 则会重发最后的FIN，2MSL（报文段最大生存时间）等待时间保证了重发的FIN会被主动关闭的一段收到且重新发送最后一个ACK；在2MSL等待时间时，任何迟到的报文段会被接收并丢弃，防止老的TCP连接的包在新的TCP连接里面出现。不可避免的，在这个2MSL等待时间内，不会建立同样(源IP, 源端口，目的IP，目的端口)的连接。