TCP的三次握手和四次挥手

目录

前言

三次握手

四次挥手

详细的流程：

1.套接字：

三次握手：

具体流程：

DDOS攻击：

解决办法:

四次挥手：

结语

---

前言

在互联网的庞大世界中，TCP（传输控制协议）是保障数据可靠传输的核心基石。无论是网页加载、文件下载，还是实时通信，TCP都默默承担着建立连接、有序传输、优雅断开的关键职责。而这一过程的核心机制，正是经典的三次握手与四次挥手。

理解这两个机制，不仅能帮助开发者深入网络通信的底层逻辑，还能为排查连接超时、端口占用、资源泄漏等问题提供关键线索。本文将用通俗的语言和示意图，解析三次握手与四次挥手的工作原理、状态转换及常见面试考点，助你掌握这一高频面试题的同时，更从容地应对实际开发中的网络问题。

翻译成人话就是：

三次握手

1. 客户端：我想发送请求
2. 服务端：好的，我知道你要发送请求了，同意发送
3. 客户端：好的，我知道你同意了，那我开始发送了
...

四次挥手

1. 客户端：我不需要请求了，可以关闭连接了
2. 服务端：好的，我知道你要关闭了
3. 服务端：我发送完成了，可以关闭了
4. 客户端：好的，我知道你发送完成了，确认关闭

详细的流程：

1.套接字：

如果我的电脑分别用谷歌浏览器和火狐浏览器进行访问B站。客户端和服务端之间有IP地址可以进行通信，此时B站需要将请求各自的发送给两个应用进程，同一个客户端的不同应用进程与B站通信如何区分呢？

这就涉及到我们要说的套接字了

我们在访问B站服务器的时候，浏览器会给我们加上端口号：443，因为走的是HTTPS协议，电脑中会给谷歌和火狐分配相对应的端口号，这样进行连接，就会像管道一样，特定的进行传输。

如：

• 192.168.3.4：50978 
• 192.168.3.4：51022

 

那这样的话，两个浏览器都可以通过不同的管道接收和发送B站的消息了。

三次握手：

TCP保温里面有SYN,ACK,FIN等标识，（1是开启，0是关闭），首先在客户端发送这些报文时，会把SYN开启（Synchronization :同步）服务器随机生成一个Sequence序号，发送给客户端。

为什么要生成这个Sequence序号？

• 因为应用程序可能连续发送多个序号给服务器，这样服务器就起码可以知道那些事累赘信息，因为Sequence序号是随机生成的，这样就更加保证了通道的唯一性。

具体流程：

1. 首先客户端会生成一个初始序号（8633），发送给服务端，并且发送SYN（请求同步）
2. 服务端收到后，自己也生成一个序号（303），并且把客户端的初始序号+1变成确认号（8633+1）,然后发送SYN+ACK，（确认同步）
3. 客户端接收到服务端的序号，也把他+1，当作自己的确认号（303+1）将服务端传过来的确认号（8633+1）当成自己的序号，再发送ACK（确认）

DDOS攻击：

如果每一次发过来的SYN，服务器都要记住客户端的序号（8633）并且生成自己需要的序号（303），那服务器就需要挂上非常多的资源，如果有个黑客，不断地发送SYN，而且不进行下一步，就会导致服务器原地崩溃。

解决办法:

服务端不保存自己的序号，而是根据服务器的IP地址和端口号等私有的信息进行算法的运算得到序号。

四次挥手：

步骤其实和三次挥手很像。

注意的地方就是：服务端发完ACK时，还需要再发一次FIN+ACK。这是因为可能有未发完的数据，所以需要再次确认。

结语

三次握手与四次挥手，看似简单的“一来一回”，却承载着TCP协议对可靠性的极致追求。从连接的建立到资源的释放，每一步都体现了协议设计者对效率和稳定性的权衡。

作为开发者，深入理解这些机制，不仅能帮助我们在面试中游刃有余，更能在实际场景中快速定位问题——比如分析TIME_WAIT状态过多的原因，或是优化高并发下的连接性能。技术之路的成长，正源于对这些“基础细节”的不断深挖。