【从面试出发学习java】- 网络 - TCP三次握手&四次挥手

TCP 在传输之前会进行三次沟通，一般称为“三次握手”， 传完数据断开的时候要进行四次沟通，一般称为“四次挥手”。
数据包说明

1. 源端口号（16位）：它（连同源主机 IP 地址）标识源主机的一个应用进程。
2. 目的端口号（16位）：它（连同目的主机 IP 地址）标识目的主机的一个应用进程。这两个值加上IP报头中的源主机IP地址和目的主机IP地址唯一确定一个TCP连接。
3. 顺序号 seq（32位）：用来标识从 TCP 源端向TCP目的端发送的数据字节流，它表示在这个 报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则TCP用顺序号对每个字节进行计数。 序号是 32bit 的无符号数，序号到达2的32次方－1后又从0开始。当建立一个新的连接时， SYN 标志变1 ，顺序号字段包含由这个主机选择的该 连接的初始顺序号ISN（Initial Sequence Number ）。
4. 确认号ack（32位）：包含发送确认的一端所期望收到的下一个顺序号。因此，确认序号应当是上次已成功收到数据字节顺序号加 1 。只有ACK标志为1时确认序号字段才有效。 TCP 为应用层提供全双工服务，这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据顺序号。
5. TCP 报头长度（4位）：给出报头中 32bit 字的数目，它实际上指明数据从哪里开始。需要这个值是因为任选字段的长度是可变的。这个字段占4bit，因此TCP最多有60字节的首部。然而，没有任选字段，正常的长度是20字节。
6. 保留位（6位）：保留给将来使用，目前必须置为0 。
7. 控制位（control flags，6 位）：在TCP报头中有6个标志比特，它们中的多个可同时被设置为1 。依次为：
   URG：为1表示紧急指针有效，为 0 则忽略紧急指针值。
   ACK：为1表示确认号有效，为 0 表示报文中不包含确认信息，忽略确认号字段。
   PSH：为1表示是带有 PUSH 标志的数据，指示接收方应该尽快将这个报文段交给应用层 而不用等待缓冲区装满。
   RST：用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报文段和拒绝连接请求。一般情况下，如果收到一个 RST 为 1 的报文，那么一定发生了某些问题。
   SYN：同步序号，为1表示连接请求，用于建立连接和使顺序号同步（synchronize）。
   FIN：用于释放连接（关闭），为 1 表示发送方已经没有数据发送了，即关闭本方数据流。
8. 窗口大小（16位）：数据字节数，表示从确认号开始，本报文的源方可以接收的字节数，即源方接收窗口大小。窗口大小是一个 16bit 字段，因而窗口大小最大为 65535 字节。
9. 校验和（16位）：此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字进行计算所得。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。
10. 紧急指针（16位）：只有当 URG 标志置 1 时紧急指针才有效。TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。
11. 选项：最常见的可选字段是最长报文大小，又称为 MSS(Maximum Segment Size) 。每个连接方通常都在通信的第一个报文段（为建立连接而设置 SYN 标志的那个段）中指明这个选项， 它指明本端所能接收的最大长度的报文段。 选项长度不一定是32位字的整数倍，所以要加填充位，使得报头长度成为整字数。
12. 数据：TCP报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

三次握手

第一次握手：主机A发送位码为 syn＝1, 随机产生 seq number=1234567 的数据包到服务器，主机B由SYN=1 知道，A要求建立联机；
第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1), syn=1, ack=1, 随机产生seq=7654321的包
第三次握手：主机A收到后检查ack number 是否正确，即第一次发送的seq number+1, 以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1), ack=1，主机B收到后确认seq 值与 ack=1 则连接建立成功。

四次挥手

TCP断开连接要进行四次。这是由于 TCP 的半关闭造成的。因为 TCP 连接是全双工的(即数据可在两个方向上同时传递) 所以进行关闭时每个方向上都要单独进行关闭。这个单方向的关闭就叫半关闭。当一方完成它的数据发送任务，就发送一个 FIN 来向另一方通告将要终止这个方向的连接。
1） 关闭客户端到服务器的连接：首先客户端 A 发送一个 FIN，用来关闭客户到服务器的数据传送， 然后等待服务器的确认。其中终止标志位 FIN=1，序列号 seq=u
2） 服务器收到这个FIN，它发回一个ACK，确认号ack为收到的序号加1。
3） 关闭服务器到客户端的连接：也是发送一个 FIN 给客户端。
4） 客户段收到 FIN 后，并发回一个 ACK 报文确认，并将确认序号 seq 设置为收到序号加 1。 首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

第一次挥手：Client发送一个FIN, 用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态
第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态
第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态；
第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server,确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手

TCP连接必须经过时间2MSL后才真正释放掉

为什么会有TIME_WAIT状态？

1. 确保有足够的时间让对方收到ACK，如果被动关闭的那方没有收到ACK就会触发被动关重发FIN包，一来一去正好是2MSL
2. 有足够的时间避免新旧连接混淆，因为有些路由器会缓存ip数据包，如果连接被重用，那么延迟收到的包有可能跟新的混在一起

为什么需要四次挥手？

因为全双工，发送方和接收方都需要FIN报文和ACK报文，也就是说发送方和接收方各只需两次挥手即可。只不过有一方是被动的，所以就成了四次挥手

Linux Socket服务器出现大量CLOSE_WAIT的原因？

问题的表现之一就是客户端一直在请求但是返回给客户端的信息是异常的，服务端并没有收到请求
出现大量CLOSE_WAIT只有一种情况在对象发送一个FIN报文之后，程序这边没有进一步发送ACK或者FIN报文以确认，换句话说就是在对方关闭连接后，程序里没有检测到或者程序本身这个时候就已经忘了这个时候需要关闭连接，于是这个资源就一直被程序占用。
遇到这种情况多数是因为程序里有bug，通常是某些连接没有及时释放导致的，或者是某些配置如线程池中的线程数之类的配置不合理，此时就需要结合实际的业务去排查