TCP的三次握手与四次挥手

最近在看一些Tcp网络编程方面的内容，不免涉及客户端和服务器交互的内容，其中最经典的应该是TCP的三次握手和四次挥手了。

背景描述

通过上一篇中网络模型中的IP层的介绍，我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。

UDP，在传送数据前不需要先建立连接，远地的主机在收到UDP报文后也不需要给出任何确认。虽然UDP不提供可靠交付，但是正是因为这样，省去和很多的开销，使得它的速度比较快，比如一些对实时性要求较高的服务，就常常使用的是UDP。对应的应用层的协议主要有 DNS,TFTP,DHCP,SNMP,NFS 等。

TCP，提供面向连接的服务，在传送数据之前必须先建立连接，数据传送完成后要释放连接。因此TCP是一种可靠的的运输服务，但是正因为这样，不可避免的增加了许多的开销，比如确认，流量控制等。对应的应用层的协议主要有 SMTP,TELNET,HTTP,FTP 等。

常用的熟知端口号

应用程序	FTP	TFTP	TELNET	SMTP	DNS	HTTP	SSH	MYSQL
熟知端口	21,20	69	23	25	53	80	22	3306
传输层协议	TCP	UDP	TCP	TCP	UDP	TCP

TCP的概述

TCP把连接作为最基本的对象，每一条TCP连接都有两个端点，这种断点我们叫作套接字（socket），它的定义为端口号拼接到IP地址即构成了套接字，例如，若IP地址为192.3.4.16 而端口号为80，那么得到的套接字为192.3.4.16:80。

TCP报文首部

源端口和目的端口，各占2个字节，分别写入源端口和目的端口；
序号，占4个字节，TCP连接中传送的字节流中的每个字节都按顺序编号。例如，一段报文的序号字段值是 301 ，而携带的数据共有100字段，显然下一个报文段（如果还有的话）的数据序号应该从401开始；
确认号，占4个字节，是期望收到对方下一个报文的第一个数据字节的序号。例如，B收到了A发送过来的报文，其序列号字段是501，而数据长度是200字节，这表明B正确的收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701；
数据偏移，占4位，它指出TCP报文的数据距离TCP报文段的起始处有多远；
保留，占6位，保留今后使用，但目前应都位0；
紧急URG，当URG=1，表明紧急指针字段有效。告诉系统此报文段中有紧急数据；
确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；
推送PSH，当两个应用进程进行交互式通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应，这时候就将PSH=1；
复位RST，当RST=1，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立连接；
同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；
终止FIN，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放；
窗口，占2字节，指的是通知接收方，发送本报文你需要有多大的空间来接受；
检验和，占2字节，校验首部和数据这两部分；
紧急指针，占2字节，指出本报文段中的紧急数据的字节数；
选项，长度可变，定义一些其他的可选的参数。

TCP连接的建立（三次握手）

这里写图片描述

最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。

TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；
TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

为什么TCP客户端最后还要发送一次确认呢？

一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。

如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

TCP连接的释放（四次挥手）

这里写图片描述

数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。

客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2 $*$
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

下图是 TCP 挥手的一个完整流程，这里引用了 tcpipguide 的流程图，更加直观的了解下挥手过程。

undefined

首先不要被这里的图给迷惑了，因为连接的主动断开是可以发生在客户端，也同样可以发生在服务端。

FIN_WAIT1

由图可知，当一方接受到来自应用断开连接的信号时候，就发送 FIN 数据报来进行主动断开，并且该连接进入 FIN_WAIT1 状态，连接处于半段开状态(可以接受、应答数据，当不能发送数据)，并将连接的控制权托管给 Kernel，程序就不再进行处理。一般情况下，连接处理 FIN_WAIT1 的状态只是持续很短的一段时间。

我这里通过对数据包的拦截（不对 FIN 请求进行应答）来实现 FIN_WAIT1 状态，下图是主动断开一遍的 FIN 数据发送抓包记录。

undefined

在 18:12.43 的时间点，这台机器主动断开连接，并发送 FIN 请求，并且达到 RTO 后未收到响应后，一共重试了9次，每次重试时间是上一次的2倍，这条连接额外占用了 54 秒的时间。如果在服务中，这类连接数据一多就会消耗大量的服务器资源，我这里简单的提供 2 个参数来处理这个问题。

tcp_orphan_retries ：Integer，这里系统参数默认为 9（文档里面默认值为7，和系统配置有关），就是近端丢弃 TCP 连接的时候，重试次数，在我的系统中。在刚刚那种情况，如果将该参数调整为 3 次，这类连接在系统中存活的时间就会大大减少，从而缓解这个问题。如果你的系统负载很大，有发现是因为 FIN_WAIT1 引起的，也可以适当的调整这个参数。

tcp_max_orphans：Integer，默认值 8096。系统所能处理不属于任何进程的 TCP sockets 最大数量。当超过这个值所有不属于任何进程的 TCP 连接(孤儿连接)都会被重置。这个参数仅仅是为了防御简单的 Dos ，不能依赖这个参数。

FIN_WAIT2

当主动断开一端的 FIN 请求发送出去后，并且成功够接受到相应的 ACK 请求后，就进入了 FIN_WAIT2 状态。其实 FIN_WAIT1 和 FIN_WAIT2 状态都是在等待对方的 FIN 数据报。当 TCP 一直保持这个状态的时候，对方就有可能永远都不断开连接，导致该连接一直保持着。

tcp_fin_timeout ：Integer，默认 60，单位秒，不属于任何应用的孤儿连接保持 FIN_WAIT2 状态的最长时间，一当超过这个时间，就会被本地直接关闭，不会进入 TIME_WAIT 状态。
但是总体上来将处于 FIN_WAIT2 状态的 TCP 连接，威胁要比 FIN_WAIT1 的小，占用的资源也很小，通常不会有什么问题。

TIME_WAIT

当前面的步骤都顺利完成了，并且接受到了被动关闭端发送过来的 FIN 数据报后，系统做出 ACK 应答后，该连接就进入了尾声，也就是 TIME_WAIT 状态。内核会设定一个时间长度为 2MSL 的定时器，当定时器在到时间点后，内核就会将该连接关闭。反之，当连接尚未关闭的时候，又收到了对方发送过来的 FIN 请求（可能是我们发送出去的请求对方并未收到），或者收到 ICMP 请求（比如 ACK 数据报，在网络传输中出现了错误），该连接就会重新发送 ACK 请求，并重置定时器。

为什么客户端最后还要等待2MSL？

MSL 是Maximum Segment Lifetime,译为“报文最大生存时间”，任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候，服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

tcp_timestamps: Boolean，默认1，表示tcp通讯的时候是否是否使用时间戳。如下图，在 TCP 头部信息的扩展头部字段中就附带了时间戳，数据长度为两个4字节。TSval是该数据报发送出来的时间，TSecr是回显时间戳（即该ack对应的data或者该data对应的上次 ack 中的 TSval 值）

undefined

tcp_tw_reuse:Boolean，默认0，只在客户端有效，就是 TCP TIME_WAIT 链路复用。比如，当客户端不断向服务端建立连接获取数据，当每次都是客户端自己关闭连接，导致服务端进入 TIME_WAIT，之后客户端又要不断重连对方继续拉取数据，这个时候就可以复用 TIME_WAIT 的连接。当连接复用后势必会有旧连接残留在网络上的数据报，那么这些数据报要怎么处理，才能不影响新的连接的使用呢。可以使用上面的参数，时间戳来判断，建立建立后将缓存的时间戳更新到现在，当早于这个时间戳的数据报进来就表明是老连接的数据，内核会直接废弃掉。

tcp_tw_recycle:Boolean，默认0，启动后能够更快地回收 TIME_WAIT 套接字。不再是2MSL，而是几个 RTO 内进行回收。所以在网络上同样会残存旧连接的数据报，内核同样可以通过时间戳的方式来判断、丢弃过时数据报。

在早期的网络通信中，开启这个参数会导致一个问题。当多个客户端通过NAT方式联网同时与服务端通信，对于服务端只收到一个IP就好像是一台客户端进行与其进行通讯，但是客户端之间会有时间戳差异，就会导致服务端会将认为过期的数据报丢弃。导致只允许一个客户端与其进行通讯。现在的 NAT 服务器已经将协议升级成了NAPT，可以采用多端口与服务端通讯就可以避免这件事情。

CLOSE_WAIT

当被动关闭端，也就是图中的服务端，接受到了对方发送过来的 FIN 请求，并且对请求做出应答后，该连接就进入了 CLOSE_WAIT ，当连接处于这个状态的时候，该连接可能有数据需要发送，或者一些其他事情要做，当这类连接过多的时候，就会导致网络性能下降，耗尽连接数，无法建立新的连接。

比如连接一直没得到释放，相应的资源一直被占用，一但达到句柄数的上限（ linux 可以通过 ulimit -a 查看 open files 数值，默认1024 ）后，新的请求就无法继续处理，就会返回大量的 Too Many Open Files 错误。

常见错误原因

1.代码层面上未对连接进行关闭，比如关闭代码未写在 finally 块关闭，如果程序中发生异常就会跳过关闭代码，自然未发出指令关闭，连接一直由程序托管，内核也无权处理，自然不会发出 FIN 请求，导致连接一直在 CLOSE_WAIT 。

2.程序响应过慢，比如双方进行通讯，当客户端请求服务端迟迟得不到响应，就断开连接，重新发起请求，导致服务端一直忙于业务处理，没空去关闭连接。这种情况也会导致这个问题。

缓解方案

1.修改 /etc/security/limits.conf 配置文件中参数，提高句柄数上限
2.修改 tcp 参数

参数名	默认值	优化值	说明
net.ipv4.tcp_keepalive_time	7200	1800	单位秒，默认为7200s，就是说一个异常的CLOSE_WAIT连接至少会维持2个小时
net.ipv4.tcp_keepalive_probes	9	3	在认定TCP连接失效之前，最多发送多少个keepalive探测消息。
tcp_keepalive_intvl	75	15	探测消息未获得响应时，重发该消息的间隔时间（秒）。

3.检查自己的代码，修改连接不规范的地方。

LAST_ACK

当被动关闭一段，发送出去了 FIN 数据报后，套接字就进入了 LAST_ACK 状态，并且等待对方进行发送 ACK 数据报。

1.收到了响应的ACK数据报后，连接进入CLOSED 状态，并释放相关资源
2.如果超时未收到响应，就触发了TCP的重传机制。