TCP链接的三次握手与四次断开

Posted 2021-01-02

一直总觉得三次握手和四次断开，之前老师讲的有问题，经过自己再次琢磨，发现是的，老师讲的没毛病，这次也把自己的理解总结一下，让对这个知识模糊的小伙伴再换种思路去理解

首先看一下TCP三次握手发生了哪些：

TCP三次握手

这是第一次用画图工具画图，有点low，细节处理的不好见谅

这是第一次设计三次握手的过程，实际上发生了四件事，其次你要清楚TCP链接建立的标准是双向的，就像谈恋爱表白一样，你必须俩人相互喜欢才能表白成功啊

白话版:
TCP 链接建立就像谈恋爱一样，互相表白才是表白成功
背景条件:某专业 某低富帅 和 某黑富美 表白过程
1，低富帅向自己爱慕依旧的黑富美表白说：俺喜欢你
2，黑富美听到低富帅的告白，回复：恩
-->到这一阶段，看到这情况也就是说这哥们已经凉了，但是作为上帝的我肯定要他表白成功啊
3，黑富美回答之后，又思考了一下毕竟门当户对，于是随即也向低富帅表白说：俺喜欢你
4，低富帅听到黑富美的告白，激动地回复：恩
-->到此，俩人恩爱的在了一起，就像TCP一样，通讯链接建立成功

但是有一点不好的是TCP三次握手原型要建立四次链接，考虑到Server在第2步和第3步都要向Client分别建立一次请求，那么显然这是浪费流量，后来改良版后的就将三次握手改成了现在的样子，如下：

经过这样的一次裁剪和优化顺利的将四次握手变成了现在的三次握手

TCP四次断开

什么是四次断开呢，那么既然能告白在一起，也能性格不合而分手，而四次断开就是发生在Client和Server数据传输完成时所发生的

白话版:
背景条件:某专业 某渣男 和 某白富美 因xxx事件，分手过程
1，有一天,渣男的主动向白富美说：咱俩分手吧
2，白富美听到渣男的请求，回复：恩，我知道了，你等下吧，我下午吧行李收拾下搬回学校
3，下午白富美搬回学校后，给渣男说，我甩了你，咱俩分手吧
4，渣男收到请求后，恋爱结束

当然可能有吃瓜群众坐不住了，为什么三次握手能压缩成三次，四次断开为什么不能？？？
四次断开由于服务器传输完毕后并不代表客户端也同时接收完毕，所以emmmm..

完整的TCP通讯和过程状态

对于tcp的通讯过程还有一个重要的点就是通讯状态，每次tcp的交流在系统中都是可以监控的，看看状态有哪些吧

我们来捋一下每一个状态：
三次握手阶段
第一次握手：建立连接时，客户端发送syn包到服务器，并进入SYN_SENT状态，等待服务器确认
第二次握手：服务器收到syn包，必须确认客户的SYN，同时自己也发送一个SYN包，即SYN+ACK包，此时服务器进入SYN_RCVD状态；(SYN_RCVD,原名为syn_received有的博客是写SYN_RCVD也有的是RECV,但我理解的是表达的都是一个意思)
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK，此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
开始数据传输
...
四次断开阶段

第一次握手: 客户端向服务端发起断开请求，发送FIN，发送seq编号，并回复上次正常数据传输的ack确认，客户端进入FIN_WAIT_1
第二次握手: 服务端收到后，首先回复ack一个确认，进入CLOSE_WAIT状态，而客户端进入FIN_WAIT_2阶段
第三次握手: 服务端向客户端发送FIN断开请求，和seq编号，进入LAST_ACK状态，客户端进入TIME_WAIT状态
第四次握手: 客户端收到FIN请求后，回复ack,则通讯连接断开

其中两个梗

SYN_RCVD:如果你的服务器出现了大量的SYN_RCVD，你可能要留意了可能遭遇了SYN泛洪×××

TCP SYN泛洪发生在OSI第四层，这种方式利用TCP协议的特性，就是三次握手。×××者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当服务器返回ACK后，该×××者就不对其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给×××者。这样更加会浪费服务器的资源。×××者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。*

TIME_WAIT:如果你的服务器出现大量TIME_WAIT，那么请格外留意你的服务器负载
TIME_WAY是TCP链接的最后一步，大规模的出现说明你的访问量很大，一定要格外的留意资源的消耗，已做好随时增加设备或者调整的准备

baklog什么梗

表示内核为相应套接字排队的最大连接个数。SYN-ACK重传次数服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。