TCP 三次握手和四次挥手详解

转载请注明出处：

　　TCP协议（Transmission Control Protocol）

　　　　面向连接的，可靠的，基于字节流的传输层通信协议

　　　　特点：

- - 基于连接的：数据传输之前需要建立连接

- - 全双工的：双向传输

- - 字节流：不限制数据大小，打包成报文段，保证有序接收，重复报文自动丢弃

- - 流量缓冲：解决双方处理能力的不匹配

- - 可靠的传输服务：保证可达，丢包时通过重发机制实现可靠性

- - 拥塞控制：防止网络出现恶性拥塞

　　TCP连接管理

1. TCP连接
2. 重要词汇
3. TCP三次握手
4. TCP 四次挥手
5. TIME_WITE状态
6. 常见问题

　　1.TCP连接：四元组[ 源地址，源端口，目的地址，目的端口 ]

　　2.重要词汇

　　　　　（1）序号（sequence number）：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。

　　　　　（2）确认号（acknowledgement number）：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。

　　　　　（3）标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：

　　　　　　　　URG：紧急指针（urgent pointer）有效。

　　　　　　　　ACK：确认序号有效。PSH：接收方应该尽快将这个报文交给应用层。

　　　　　　RST：重置连接。

　　　　　　 SYN：发起一个新连接。

　　　　　　FIN：释放一个连接。

　　　　需要注意的是：

　　　　　　不要将确认序号Ack与标志位中的ACK搞混了。确认方Ack=发起方Seq+1，两端配对。

　　3.TCP三次握手

　　　　a. 同步通信双方初始序列号( ISN, initial sequence number )

　　　　b. 协商TCP通信参数（MSS, 窗口信息，指定校验和算法）

发送端首先发送一个带SYN（synchronize）标志的数据包给接收方【第一次的seq序列号是随机产生的，这样是为了网络安全，如果不是随机产生初始序列号，黑客将会以很容易的方式获取到你与其他主机之间的初始化序列号，并且伪造序列号进行攻击】

接收端收到后，回传一个带有SYN/ACK（acknowledgement）标志的数据包以示传达确认信息【SYN 是为了告诉发送端，发送方到接收方的通道没问题；ACK 用来验证接收方到发送方的通道没问题】

最后，发送端再回传一个带ACK标志的数据包，代表握手结束若在握手某个过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包

连接状态查看:

netstat ‐ntp ‐c 1

　　4.TCP 四次挥手

　　过程：

　　　　A: 发送FIN数据包，代表A不再发送数据

　　　　B：收到请求，开始应答，避免了A重新发送FIN重试（应答机制）

　　　　B: 处理完数据之后关闭，关闭连接,及发送FIN请求

　　　　A: 收到请求后发送ACK应答，B服务可以释放连接

　　5. TIME_WAIT 状态：

　　　　TIME_WAIT 是这么一种状态：TCP 四次挥手结束后，连接双方都不再交换消息，但主动关闭的一方保持这个连接在一段时间内不可用。

　　TIME_WAIT 是为了保证全双工的 TCP 连接正常终止。为了保证网络中迷失的数据包正常过期。

　　6. 常见问题

　　6.1 为什么需要三次握手？

　　　　为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手，为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后　　两次(第二次和第三次)握手。若TCP连接建立失败，服务器端则关闭连接端口，由此减少服务器开销和接收到失效请求发生的错误。

　　6.2. 为什么连接的时候是三次握手，关闭的时候却是四次握手？

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

　　6.3. 为什么TCP挥手每两次中间有一个 FIN-WAIT2等待时间？

主动关闭的一端调用完close以后（即发FIN给被动关闭的一端，并且收到其对FIN的确认ACK）则进入FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一段宕机等原因，导致主动关闭的一端不能收到被动关闭的一端发来的FIN（防止对端不发送关闭连接的FIN包给本端），这个时候就需要FIN_WAIT_2定时器，如果在该定时器超时的时候，还是没收到被动关闭一端发来的FIN，那么直接释放这个链接，进入CLOSE状态

　　6.4. 为什么客户端最后还要等待2MSL？为什么还有个TIME-WAIT的时间等待？

保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，服务器已经发送了FIN+ACK报文，请求断开，客户端却没有回应，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，这样新的连接中不会出现旧连接的请求报文。
2MSL，最大报文生存时间，一个MSL 30 秒，2MSL = 60s

　　6.5. 客户端 TIME-WAIT 状态过多会产生什么后果？怎样处理？

作为服务器，短时间内关闭了大量的Client连接，就会造成服务器上出现大量的TIME_WAIT连接，占据大量的tuple /tApl/ ，严重消耗着服务器的资源，此时部分客户端就会显示连接不上
作为客户端，短时间内大量的短连接，会大量消耗的Client机器的端口，毕竟端口只有65535个，端口被耗尽了，后续就无法在发起新的连接了

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上

高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了
短连接表示“业务处理+传输数据的时间远远小于 TIMEWAIT超时的时间”的连接

解决方法：

用负载均衡来抗这些高并发的短请求；
服务器可以设置 SO_REUSEADDR 套接字选项来避免 TIME_WAIT状态，TIME_WAIT 状态可以通过优化服务器参数得到解决，因为发生TIME_WAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的
强制关闭，发送 RST 包越过TIMEWAIT状态，直接进入CLOSED状态

　　6.6. 服务器出现了大量 CLOSE_WAIT 状态如何解决？

大量 CLOSE_WAIT 表示程序出现了问题，对方的 socket 已经关闭连接，而我方忙于读或写没有及时关闭连接，需要检查代码，特别是释放资源的代码，或者是处理请求的线程配置。