共计 3242 个字符，预计需要花费 9 分钟才能阅读完成。
TCP 的整个连接过程
如果没有基础的话，直接看这张图或者网络上各种文字描述，十分生涩，所以先看懂接下来的握手挥手的图，理解之后，再看这个有限状态机就感觉原来如此简单。
三次握手
握手过程
第一次握手：主机 A 发送位码为 syn=1，随机产生 seq number= x 的数据包到服务器，客户端进入 SYN_SEND 状态，等待服务器的确认；主机 B 由 SYN= 1 知道 A 要求建立连接。
第二次握手：主机 B 收到请求后要确认连接信息，向 A 发送 ack number(主机 A 的 seq+1)、syn=1、ack=1，随机产生 seq= y 的包，此时服务器进入 SYN_RECV 状态。
第三次握手：主机 A 收到后检查 ack number 是否正确，即第一次发送的 seq number+1，以及位码 ack 是否为 1，若正确，主机 A 会再发送 ack number(主机 B 的 seq+1)、ack=1，主机 B 收到后确认 seq 值与 ack= 1 则连接建立成功。客户端和服务器端都进入 ESTABLISHED 状态。
三次握手的必要性
- 第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
- 第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
- 第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收能力，服务器自己的发送能力也正常。
至此，客户端和服务端可以确定双方的接收和发送能力均正常。
第三次握手的必要性
这主要是为了防止已失效的连接请求报文段突然又传送到了服务器端，从而减少服务端的开销。
如果只有两次握手就建立连接会出现这种情况：客户端发出的连接请求报文段在某些网络节点长时间滞留了，以致延误到连接释放以后的某个时间才能到达服务端。本来这是一个早已失效的报文段，但服务端收到此失效的连接请求报文段后，就误认为客户端又发出了一次新的连接请求。于是向客户端发出确认报文段，同意建立连接。由于现在客户端并没有发出建立连接的请求，因此不会处理服务端的确认，也不会向服务端发送数据。但服务端却以为新的连接已经建立了，并一直等待客户端发来数据。服务端会因此浪费很多了。
如果第三次握手丢失了，客户端服务端会如何处理？
服务端：
该 TCP 连接的状态为 SYN_RECV, 并且会根据 TCP 的超时重传机制，会等待 3 秒、6 秒、12 秒后重新发送 SYN+ACK 包，以便 Client 重新发送 ACK 包。而 Server 重发 SYN+ACK 包的次数，可以通过设置 /proc/sys/net/ipv4/tcp_synack_retries 修改，默认值为 5。如果重发指定次数之后，仍然未收到客户端的 ACK 应答，那么一段时间后，服务端自动关闭这个连接。
客户端：
客户端在接收到 SYN+ACK 包，它的 TCP 连接状态就为 ESTABLISHED（已连接），表示该连接已经建立。那么如果第三次握手中的 ACK 包丢失的情况下，客户端向服务端发送数据，服务端将以 RST 包 (reset 重置) 响应，才能感知到服务端的错误。
什么是 syn flood 攻击
syn flood 是一种经典的 ddos 攻击手段，这里面用到了 TCP 三次握手存在的漏洞。当服务端接收到 SYN 后进入 SYN-RECV 状态，此时的连接称为半连接，同时会被服务端写入一个半连接队列。如果攻击者在短时间内不断的向服务端发送大量的 SYN 包而不响应，那么服务器的半连接队列很快会被写满，从而导致无法工作。实现 syn flood 的手段，可以通过伪造源 IP 的方式，这样服务器的响应就永远到达不了客户端(握手无法完成)；当然，通过设定客户端防火墙规则也可以达到同样的目的。对 syn flood 实现拦截是比较困难的，可以通过启用 syn_cookies 的方式实现缓解，但这通常不是最佳方案。最好的办法是通过专业的防火墙来解决，基本上所有的云计算大 都具备这个能力。
四次挥手
挥手过程
第一次挥手：主机 A（可以是客户端，也可以是服务器端），设置 Sequence Number 和 Acknowledgment Number，向主机 B 发送一个 FIN 报文段；此时，主机 A 进入 FIN_WAIT_1 状态；这表示主机 A 没有数据要发送给主机 B 了。
第二次挥手：主机 B 收到了主机 A 发送的 FIN 报文段，向主机 A 回一个 ACK 报文段，Acknowledgment Number 为 Sequence Number 加 1，主机 A 进入 FIN_WAIT_2 状态；主机 B 告诉主机 A，我也没有数据要发送了，可以进行关闭连接了。
第三次挥手：主机 B 向主机 A 发送 FIN 报文段，请求关闭连接，同时主机 B 进入 CLOSE_WAIT 状态。
第四次挥手：主机 A 收到主机 B 发送的 FIN 报文段，向主机 B 发送 ACK 报文段，然后主机 A 进入 TIME_WAIT 状态；主机 B 收到主机 A 的 ACK 报文段以后，就关闭连接；此时，主机 A 等待 2MSL 后依然没有收到回复，则证明主机 B 已正常关闭，那好，主机 A 也可以关闭连接了。
主机 B 发送了 FIN-ACK 之后，会立即启动超时重传计时器
主机 A 在发送最后一个 ACK 之后，会立即启动时间等待计时器
挥手为什么需要四次？
因为当服务端收到客户端的 SYN 连接请求报文后，可以直接发送 SYN+ACK 报文。其中 ACK 报文是用来应答的，SYN 报文是用来同步的。但是关闭连接时，当服务端收到 FIN 报文时，很可能并不会立即关闭 SOCKET，所以只能先回复一个 ACK 报文，告诉客户端，” 你发的 FIN 报文我收到了 ”。只有等到我服务端所有的报文都发送完了，我才能发送 FIN 报文，因此不能一起发送。故需要四次挥手。
RST 是什么，为什么会出现
RST 是一个特殊的标记，用来表示当前应该立即终止连接。以下这些情况都会产生 RST：
- 向一个未被监听的端口发送数据
- 对方已经调用 close 关闭连接
- 存在一些数据未处理(接收缓冲区)，请求关闭连接时，会发送 RST 强制关闭
- 某些请求发生了超时
为什么服务器会有大量 closewait
半关闭的状态下的服务器连接会处于 closewait 状态，直到服务器发送了 FIN。那么在应用层则是调用 socket.close()会执行 FIN 的发送，如果服务器出现大量 CLOSE_WAIT 状态的连接，那么有可能的原因：
- 服务器压力过大，根本来不及调用 close
- 存在连接泄露问题(Bug)，服务器未及时关闭连接
四次挥手释放连接时，等待 2MSL 的意义
为了保证客户端发送的最后一个 ACK 报文段能够到达服务器。因为这个 ACK 有可能丢失，从而导致处在 LAST-ACK 状态的服务器收不到对 FIN-ACK 的确认报文。服务器会超时重传这个 FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待 2MSL，而是在发送完 ACK 之后直接释放关闭，一但这个 ACK 丢失的话，服务器就无法正常的进入关闭连接状态。
MSL 是 Maximum Segment Lifetime 的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。我们都知道 IP 头部中有个 TTL 字段，TTL 是 time to live 的缩写，可译为“生存时间”，这个生存时间是由源主机设置初始值代表一个 IP 数据包可以经过的最大路由数，每经过一个路由器，它的值就减 1，当此值为 0 则数据报被丢弃，同时发送 ICMP 报文通知源主机。RFC793 中规定 MSL 为 2 分钟，但这完全是从工程上来考虑，对于现在的网络，常用值 30 秒或 1 分钟。因此 TCP 允许不同的实现可根据具体情况使用更小的 MSL 值。
最后，限于笔者经验水平有限，欢迎读者就文中的观点提出宝贵的建议和意见。如果想获得更多的学习资源或者想和更多的是技术爱好者一起交流，可以关注我的公众号『全菜工程师小辉』后台回复关键词领取学习资料、进入前后端技术交流群和程序员副业群。同时也可以加入程序员副业群 Q 群：735764906 一起交流。
