TCP三次握手和四次挥手

TCP三次握手

序列号：建立连接时计算机随机生成的随机数作为初始值，通过SYN包传给接收端主机，每发送一次数据就累加一次该数据字节数的大小。用来解决网络包乱序问题。
确认应答号：指下一次期望收到的数据的序列号，发送端收到这个确认应答以后认为在这个序号以前的数据都已经被正常接受。用来解决丢包问题。
ACK：确认应答的字段变为有效，TCP规定除了最初建立的SYN包外该位必须设置为1
RST：表示TCP连接中出现异常必须强制断开连接
SYN：表示希望建立连接，并在其序列号的字段进行序列号初始值的设定
FIN：表示今后不会再有数据发送，希望断开连接。通信结束希望断开连接时，通信双方的主机之间就可以相互交换FIN位为1的TCP段。

使用TCP前必须先建立连接，建立连接是通过三次握手来进行的。

三次握手中，第三次握手是可以携带数据的，前两次握手是不可以携带数据的。一旦完成三次握手，双方都处于ESTABLISHED状态，此时连接就已建立完成,客户端和服务端就可以相互发送数据了。
Linux系统查看TCP状态
netstat -napt

TCP四次挥手

客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。
服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSE_WAIT 状态。
客户端收到服务端的 ACK 应答报文后，之后进入 ==FIN_WAIT_2 ==状态。
等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。
客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
服务端收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。
客户端在经过 2MSL 一段时间后，自动进入 CLOSE 状态，至此客户端也完成连接的关闭。

为什么挥手需要四次？
关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
服务端收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送（closed_wait），等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。
服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，因此是需要四次挥手。
第一次挥手丢失，会发生什么？
根据 tcp_orphan_retries 决定重传次数

第二次挥手丢失，会发生什么？
由于ACK不会重传，如果服务端第二次挥手丢失客户端就会触发超时重传机制，重传FIN报文
根据 tcp_orphan_retries 决定重传次数

注意：
对于 close 函数关闭的连接，由于无法再发送和接收数据，所以FIN_WAIT2 状态不可以持续太久，而 tcp_fin_timeout 控制了这个状态下连接的持续时长，默认值是 60 秒。
如果主动关闭方使用 shutdown 函数关闭连接，指定了只关闭发送方向，而接收方向并没有关闭，那么意味着主动关闭方还是可以接收数据的，就会死等对方的FIN。

第三次挥手丢失，会发生什么？
同理第一次挥手丢失

第四次挥手丢失，会发生什么？
在 Linux 系统，TIME_WAIT 状态会持续 2MSL 后才会进入关闭状态。
客户端在收到第三次挥手后，就会进入 TIME_WAIT 状态，开启时长为 2MSL 的定时器，如果途中再次收到第三次挥手（FIN 报文）后，就会重置定时器，当等待 2MSL 时长后，客户端就会断开连接。

为什么 TIME_WAIT 等待的时间是 2MSL？
MSL为报文最大生存时间（单位是时间）TTL是经过路由跳数，因此MSL应该大于等于TTL消耗为0的时间确保报文已被自然消亡。

当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。
至少运行报文丢失一次
连续两次丢包概率万分之一，概率太小，忽略它比解决它更有性价比

2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。

待扩充