TCP三次握手与四次挥手

TCP三次握手总结

TCP三次握手过程

1. 初始状态，客户端服务器都处于close， 服务器开启监听端口，变成Listen
2. 第一次握手：客户端初始化序列号CLINT，把序列号插入TCP首部的序号字段中，把SYN标志成一，把该报文发送给服务端，客户端处于SYN-sent状态
3. 第二次握手： 服务端收到SYN报文，初始化自己的序列号，填入TCP首部的序号字段，在确定应答号填入clint + 1，把SYN和ACK标志成一，把报文发送给客户端， 服务器处于SYN-RCVD状态
4. ACK变成一，确认应答号填入serson +1 ，最后把报文发送给服务端， 这一次可以携带数据

为什么是三次握手？不是两次、四次？

三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。
二次连接 提前进入了estalish状态，就是一个历史连接，避免资源浪费 四次握手由于把ack和序列号合
并，变成了三次握手

为什么每次建立 TCP 连接时，初始化的序列号都要求不一样呢？

如果每次建立连接，客户端和服务端的初始化序列号都是一样的话，很容易出现历史报文被下一个相同>四元组的连接接收的问题。

初始序列号 ISN 是如何随机产生的？

ISN = M + F(localhost, localport, remotehost, remoteport)。
时钟器加hash算法

既然 IP 层会分片，为什么 TCP 层还需要 MSS 呢？

● MTU：一个网络包的最大长度，以太网中一般为 1500 字节；
● MSS：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度；
ip分片传输，没有超时重传，如果缺失，tcp传输的时候，如果发现tcp报文的某一片缺失，不会响应ACK
当tcp分片时，mss< mtu不用ip分片了
第一次握手丢失了，会发生什么？
在linux中，最大重传次数是5，第一次重传在1s后，第二次在2s，第三次在4s，第四次在8s，第五次在16s，每次超时的时间是上一次的 2 倍。
第二次握手丢失了，会发生什么？
● 客户端会重传 SYN 报文，也就是第一次握手，最大重传次数由 tcp_syn_retries内核参数决定；
● 服务端会重传 SYN-ACK 报文，也就是第二次握手，最大重传次数由 tcp_synack_retries 内核参数决定。
第三次握手丢失了，会发生什么？
重传 SYN-ACK 报文，直到收到第三次握手，或者达到最大重传次数。

TCP四次挥手

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

第一次挥手丢失了，会发生什么？

如果第一次挥手丢失了，那么客户端迟迟收不到被动方的 ACK 的话，也就会触发超时重传机制，重传 FIN 报文，重发次数由 tcp_orphan_retries 参数控制。
当客户端重传 FIN 报文的次数超过 tcp_orphan_retries 后，就不再发送 FIN 报文，直接进入到 close 状态。

第二次挥手丢失了，会发生什么？

这意味着对于调用 close 关闭的连接，如果在 60 秒后还没有收到 FIN 报文，客户端（主动关闭方）的连接就会直接关闭。
但是注意，如果主动关闭方使用 shutdown 函数关闭连接且指定只关闭发送方向，而接收方向并没有关闭，那么意味着主动关闭方还是可以接收数据的。如果主动关闭方一直没收到第三次挥手，那么主动关闭方的连接将会一直处于 FIN_WAIT2 状态（tcp_fin_timeout 无法控制 shutdown 关闭的连接）。

第三次挥手丢失了，会发生什么？

服务端处于 CLOSE_WAIT 状态时，调用了 close 函数，内核就会发出 FIN 报文，同时连接进入 LAST_ACK 状态，等待客户端返回 ACK 来确认连接关闭。
如果迟迟收不到这个 ACK，服务端就会重发 FIN 报文，重发次数仍然由 tcp_orphan_retries 参数控制，这与客户端重发 FIN 报文的重传次数控制方式是一样的。

第四次挥手丢失了，会发生什么？

然后，服务端（被动关闭方）没有收到 ACK 报文前，还是处于 LAST_ACK 状态。
如果第四次挥手的 ACK 报文没有到达服务端，服务端就会重发 FIN 报文，重发次数仍然由前面介绍过的 tcp_orphan_retries 参数控制。