漫画：一招学会TCP的三次握手和四次挥手

关注

原创最新推荐文章于 2026-07-23 11:17:29 发布 802 阅读 AI 写同款· GEO 优化 ›

Python多线程爬虫实战：生产者-消费者模型高效抓取XKCD漫画网络爬虫是数据采集的核心技术，其核心原理是通过程序模拟浏览器请求，自动抓取并解析网页数据。在I/O密集型任务中，单线程爬虫因网络等待导致效率低下，多线程技术通过并发执行能显著提升CPU利用率与抓取速度。Python的threading模块结合生产者-消费者模型，实现了任务分发与执行的解耦，通过线程安全的Queue管理任务队列，有效避免了资源竞争问题。这种架构特别适用于图片、文档等批量下载场景，例如构建本地漫画库或商品图集。本文以XKCD中文站为案例，详细解析了多线程爬虫中线程安全与异常处理的关键实现，帮助开阅读详情

TCP三次握手和四次挥手的问题在面试中是最为常见的考点之一。很多读者都知道三次和四次，但是如果问深入一点，他们往往都无法作出准确回答。

本篇尝试使用动画来对这个知识点进行讲解，期望读者们可以更加简单地地理解TCP交互的本质。

TCP/IP代表传输控制协议/网际协议，指的是一系列协组。

可分为四个层次：

1、数据链路层、网络层、传输层和应用层。
2、在网络层:有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。
3、在传输层:中有TCP协议与UDP协议。
4、在应用层:有FTP、HTTP、TELNET、SMTP、DNS等协议。

TCP和UDP使用IP协议从一个网络传送数据包到另一个网络。把IP想像成一种高速公路，它允许其它协议在上面行驶并找到到其它电脑的出口。TCP和UDP是高速公路上的“卡车”，它们携带的货物就是像HTTP，文件传输协议FTP这样的协议等。

TCP和UDP是FTP，HTTP和SMTP之类使用的传输层协议。虽然TCP和UDP都是用来传输其他协议的，它们却有一个显著的不同：TCP提供有保证的数据传输，而UDP不提供。这意味着TCP有一个特殊的机制来确保数据安全的不出错的从一个端点传到另一个端点，而UDP不提供任何这样的保证。

TCP 三次握手

TCP 三次握手就好比两个人在街上隔着50米看见了对方，但是因为雾霾等原因不能100%确认，所以要通过招手的方式相互确定对方是否认识自己。

相互拥抱

我们看到这个过程中一共是四个动作，招手–点头微笑–招手–点头微笑。其中连续进行了2个动作，先是点头微笑(回复对方)，然后再次招手(寻求确认)，实际上可以将这两个动作合一，招手的同时点头和微笑(syn+ack)。于是四个动作就简化成了三个动作，招手–点头微笑并招手–点头微笑。这就是三次握手的本质，中间的一次动作是两个动作的合并。

我们看到有两个中间状态，syn_sent和syn_rcvd，这两个状态叫着「半打开」状态，就是向对方招手了，但是还没来得及看到对方的点头微笑。syn_sent是主动打开方的「半打开」状态，syn_rcvd是被动打开方的「半打开」状态。客户端是主动打开方，服务器是被动打开方。

syn_sent: syn package has been sent
syn_rcvd: syn package has been received

TCP 数据传输

TCP 数据传输就是两个人隔空对话，差了一点距离，所以需要对方反复确认听见了自己的话。

客户端喊了一句话(data)，接收方听见了之后要回复自己听见了(ack)。

如果喊了一句，半天没听到对方回复，就认为自己的话被大风吹走了，没听见，所以需要重新喊话，这就是tcp重传。

也有可能是服务端听到了客户端的话，但是Server向Client的回复被大风吹走了，以至于Client没听见Server的回复。Client并不能判断究竟是自己的话被大风吹走了还是Server的回复被大风吹走了，Client也不用管，重传一下就是。

Client可以向Server喊话，同样Server也可以向Client喊话，因为tcp链接是「双工的」，双方都可以主动发起数据传输。不过无论是哪方喊话，都需要收到对方的确认才能认为对方收到了自己的喊话。

Client可能是个高射炮，一说连说了八句话，这时候Server可以不用一句一句回复，而是连续听了这八句话之后，一起向对方回复说前面你说的八句话我都听见了，这就是批量ack。但是Client也不能一次性说了太多话，Server的脑子短时间可能无法消化太多，两人之间需要有协商好的合适的发送和接受速率，这个就是「TCP窗口大小」。

TCP三次连接总结

(1**) 第一次握手：**建立连接时，客户端A发送SYN包(SYN=j)到服务器B，并进入SYN_SEND状态，等待服务器B确认。

**(2) 第二次握手：**服务器B收到SYN包，必须确认客户A的SYN(ACK=j+1)，同时自己也发送一个SYN包(SYN=k)，即SYN+ACK包，此时服务器B进入SYN_RECV状态。

**(3) 第三次握手：**客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK(ACK=k+1)，此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。

完成三次握手，客户端与服务器开始传送数据。

TCP 四次挥手

TCP断开链接的过程和建立链接的过程比较类似，只不过中间的两部并不总是会合成一步走，所以它分成了4个动作，Client挥手(fin)——Server伤感地微笑(ack)——Server挥手(fin)——Client伤感地微笑(ack)。

之所以中间的两个动作没有合并，是因为tcp存在「半关闭」状态，也就是单向关闭。Client已经挥了手，可是人还没有走，只是不再说话，但是耳朵还是可以继续听，Server呢继续喊话。等待Server累了，也不再说话了，超Client挥了挥手，Client伤感地微笑了一下，才彻底结束了。

上面有一个非常特殊的状态time_wait，它是主动关闭的一方在回复完对方的挥手后进入的一个长期状态，这个状态标准的持续时间是4分钟，4分钟后才会进入到closed状态，释放套接字资源。不过在具体实现上这个时间是可以调整的。

它就好比主动分手方要承担的责任，是你提出的要分手，你得付出代价。这个后果就是持续4分钟的time_wait状态，不能释放套接字资源(端口)，就好比守寡期，这段时间内套接字资源(端口)不得回收利用。

它的作用是重传最后一个ack报文，确保对方可以收到。因为如果对方没有收到ack的话，会重传fin报文，处于time_wait状态的套接字会立即向对方重发ack报文。

同时在这段时间内，该链接在对话期间于网际路由上产生的残留报文(因为路径过于崎岖，数据报文走的时间太长，重传的报文都收到了，原始报文还在路上)传过来时，都会被立即丢弃掉。4分钟的时间足以使得这些残留报文彻底消逝。不然当新的端口被重复利用时，这些残留报文可能会干扰新的链接。

4分钟就是2个MSL，每个MSL是2分钟。MSL就是maximium segment lifetime——最长报文寿命。这个时间是由官方RFC协议规定的。至于为什么是2个MSL而不是1个MSL，我还没有看到一个非常满意的解释。

四次挥手也并不总是四次挥手，中间的两个动作有时候是可以合并一起进行的，这个时候就成了三次挥手，主动关闭方就会从fin_wait_1状态直接进入到time_wait状态，跳过了fin_wait_2状态。

TCP四次分手总结

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

**客户端A发送一个FIN，**用来关闭客户A到服务器B的数据传送(报文段4)。
服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1(报文段5)。和SYN一样，一个FIN将占用一个序号。
服务器B关闭与客户端A的连接，发送一个FIN给客户端A(报文段6)。
客户端A发回ACK报文确认，并将确认序号设置为收到序号加1(报文段7)。

总结

TCP状态转换是一个非常复杂的过程，本文仅对一些简单的基础知识点进行了类比讲解。关于TCP的更多知识还需要读者去搜寻相关技术文章进入深入学习。如果读者对TCP的基础知识掌握得比较牢固，高级的知识理解起来就不会太过于吃力。

补充

最近作为面试管在面试的时候，发现很多人框架很强，java基础的时候就有些薄弱了，很多童鞋们对于HTTP、TCP、UDP以及SOCKET的概念不是很清楚，傻傻的分不清楚，这里我们也简单的提一下

HTTP本身就是一个协议，是从Web服务器传输超文本到本地浏览器的传送协议。

HTTP(超文本传输协议)是利用TCP在两台电脑(通常是Web服务器和客户端)之间传输信息的协议。客户端使用Web浏览器发起HTTP请求给Web服务器，Web服务器发送被请求的信息给客户端。

HTTP协议是建立在请求/响应模型上的。首先由客户建立一条与服务器的TCP链接，并发送一个请求到服务器，请求中包含请求方法、URL、协议版本以及相关的MIME样式的消息。服务器响应一个状态行，包含消息的协议版本、一个成功和失败码以及相关的MIME式样的消息。

HTTP/1.0为每一次HTTP的请求/响应建立一条新的TCP链接，因此一个包含HTML内容和图片的页面将需要建立多次的短期的TCP链接。一次TCP链接的建立将需要3次握手。

另外，为了获得适当的传输速度，则需要TCP花费额外的回路链接时间（RTT）。每一次链接的建立需要这种经常性的开销，而其并不带有实际有用的数据，只是保证链接的可靠性，因此HTTP/1.1提出了可持续链接的实现方法。HTTP/1.1将只建立一次TCP的链接而重复地使用它传输一系列的请求/响应消息，

因此减少了链接建立的次数和经常性的链接开销。

虽然HTTP本身是一个协议，但其最终还是基于TCP的。

SOCKET：TCP/IP网络的API。

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。

Socket 接口是TCP/IP网络的API，Socket接口定义了许多函数或例程，用以开发TCP/IP网络上的应用程序。

这是为了实现以上的通信过程而建立成来的通信管道，其真实的代表是客户端和服务器端的一个通信进程，双方进程通过socket进行通信，而通信的规则采用指定的协议。socket只是一种连接模式，不是协议,tcp,udp，简单的说（虽然不准确）是两个最基本的协议,很多其它协议都是基于这两个协议如，http就是基于tcp的，用socket可以创建tcp连接，也可以创建udp连接**，这意味着，用socket可以创建任何协议的连接，因为其它协议都是基于此的。