深入浅出TCP三次握手以及四次挥手

 TCP三次握手、四次挥手，在面试这锅滚油里，可谓是炸了千百遍的老油条。

我们都知道TCP是面向连接的，三次握手就是用来建立连接的，四次挥手就是用来断开连接的。

前言

TCP三次握手和四次挥手是面试题的热门考点，它们分别对应TCP的连接和释放过程，今天我们先来认识一下TCP三次握手过程，以及是否可以使用“两报文握手”建立连接？。

1、TCP是什么？

TCP是面向连接的协议，它基于运输连接来传送TCP报文段，TCP运输连接的建立和释放，是每一次面向连接的通信中必不可少的过程。

TCP运输连接有以下三个阶段：

• 建立TCP连接，也就是通过三报文握手来建立TCP连接。
• 数据传送，也就是基于已建立的TCP连接进行可靠的数据传输。
• 释放连接，也就是在数据传输结束后，还要通过四报文挥手来释放TCP连接。

TCP的运输连接管理就是使运输连接的建立和释放都能正常的进行。

2、TCP首部格式

源端口: 占16比特，写入源端口号，用来 标识发送该TCP报文段的应用进程。 目的端口： 占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程。

序号: 占32比特，取值范围[0,2^32-1]，序号增加到最后一个后，下一个序号就又回到0。指出本TCP报文段数据载荷的第一个字节的序号。

确认号： 占32比特，取值范围[0,2^32-1]，确认号增加到最后一个后，下一个确认号就又回到0。指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。若确认号=n，则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据。

确认标志位ACK： 取值为1时确认号字段才有效；取值为0时确认号字段无效。TCP规定，在连接建立后所有传送的TCP报文段都必须把ACK置1。

数据偏移: 占4比特，并以4字节为单位。用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。这个字段实际上是指出了TCP报文段的首部长度。

        同步标志位SYN： 在TCP连接建立时用来同步序号。

        终止标志位FIN： 用来释放TCP连接。

        复位标志位RST： 用来复位TCP连接。

        推送标志位PSH： 接收方的TCP收到该标志位为1的报文段会尽快上交应用进程，而不必等到接收缓存都填满后再向上交付。

窗口： 占16比特，以字节为单位。指出发送本报文段的一方的接收窗。

校验和： 占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。在计算校验和时，要在TCP报文段的前面加上12字节的伪首部。

紧急指针： 占16比特，以字节为单位，用来指明紧急数据的长度。

填充： 由于选项的长度可变，因此使用填充来 确保报文段首部能被4整除，(因为数据偏移字段，也就是首部长度字段，是以4字节为单位的)。

3、TCP的连接建立

        TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP 报文段，称之为三报文握手，采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了，因而产生错误。

TCP的连接建立要解决以下三个问题：

• 1、使TCP双方能够确知对方的存在 。

• 2、使TCP双方能够协商一些参数（ 最大窗口值是否使用窗口扩大选项和时间戳选项，以及服务质量等）。

• 3、使TCP双方能够对运输实体资源（例如缓存大小连接表中的项目等）进行分配。

4、三次握手图文详解

这是两台要基于TCP进行通信的主机：

• 主动发起TCP连接建立称为TCP客户(client)。

• 被动等待TCP连接建立的应用进程称为TCP服务器(server)。

我们可以将TCP建立连接的过程比喻为”握手“，“握手”需要在TCP客户端和服务器之间交换三个TCP报文段。

①最初两端的TCP进程都处于关闭状态。

②一开始，TCP服务器进程首先创建传输控制块，用来存储TCP连接中的一些重要信息。 例如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针，当前的发送和接收序号等。之后就准备接受TCP客户进程的连接请求， 此时TCP服务器进程就要进入监听状态等待TCP客户进程的连接请求。

③TCP客户进程也是首先创建传输控制块，然后再打算建立。 TCP服务器进程是被动等待来自TCP客户端进程的连接请求，因此称为被动打开连接。

④TCP连接时向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态。

• TCP 连接请求报文段首部中的同步位SYN被设置为1，,表明这是一个tcp连接请求报文段。

• 序号字段seq被设置了一个初始值x作为TCP客户进程所选择的初始序号。

由于TCP连接建立是由TCP客户进程主动发起的，因此称为主动打开连接。 请注意TCP规定SYN被设置为1的报文段不能携带数据但要消耗掉一个序号。

⑤TCP服务器进程收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态。

• 该报文段首部中的同步位SYN和确认位ACK 都设置为1，表明这是一个TCP连接请求。
• 序号字段seq被设置了一个初始值y，作为TCP服务器进程所选择的初始序号。
• 确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号seq的确认。

请注意这个报文段也不能携带数据，因为它是SYN被设置为一的报文段但同样要消耗掉一个序号。

⑥TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP 确认报文段并进入连接已建立状态。

• 该报文段首部中的确认位ACK被设置为1，表明这是一个普通的TCP确认报文段 。
• 序号字段seq 被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，并且不携带数据，因此第二个报文段的序号为x +1。
• 确认号字段ack被设置为y + 1，这是对TCP服务器进程所选择的初始序号的确认。

请注意TCP规定，普通的TCP确认报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下所发送的下一个数据报文段的序号仍是x + 1。

⑦TCP服务器进程收到该确认报文段后也进入连接已建立状态，现在TCP双方都进入了连接已建立状态，他们可以基于已建立好的TCP连接进行可靠的数据传输了。

三次握手文字总结

三次握手是 TCP 连接的建立过程。在握手之前，主动打开连接的客户端结束 CLOSE 阶段，被动打开的服务器也结束 CLOSE 阶段，并进入 LISTEN 阶段。随后进入三次握手阶段：

一次握手

① 首先客户端向服务器发送一个 SYN 包，并等待服务器确认，其中：

• 标志位为 SYN，表示请求建立连接；
• 序号为 seq = x（x 一般取随机数）；
• 随后客户端进入 SYN-SENT 阶段。
  • 注：SYN = 1，seq = x

两次握手

② 服务器接收到客户端发来的 SYN 包后，对该包进行确认后结束 LISTEN 阶段，并返回一段 TCP 报文，其中：

• 标志位为 SYN 和 ACK，表示确认客户端的报文 seq 序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接；
• 序号为 seq = y（y 一般取随机数）；；
• 确认号为 ack = x + 1，表示收到客户端的序号 seq 并将其值加 1 作为自己确认号 ack 的值，随后服务器端进入 SYN-RECV 阶段。
  • 注：SYN = 1，ACK = 1，seq = y，ack = x +1

三次握手

③ 客户端接收到发送的 SYN + ACK 包后，明确了从客户端到服务器的数据传输是正常的，从而结束 SYN-SENT 阶段。并返回最后一段报文。其中：

• 标志位为 ACK，表示确认收到服务器端同意连接的信号；
• 序号为 seq = x + 1，表示收到服务器端的确认号 ack，并将其值作为自己的序号值；
• 确认号为 ack= y + 1，表示收到服务器端序号 seq，并将其值加 1 作为自己的确认号 ack 的值。
• 随后客户端进入 ESTABLISHED。
  • 注：ACK = 1，seq = x + 1，ack = y + 1

        当服务器端收到来自客户端确认收到服务器数据的报文后，得知从服务器到客户端的数据传输是正常的，从而结束 SYN-RECV 阶段，进入 ESTABLISHED 阶段，从而完成三次握手。

 这里有个动态过程的图示：

为什么是三次握手而不是两次握手?

        第一种情况：客户端第一次发送请求(第一次握手)时，可能超时，那么就会超时重传，服务端收到后就打开端口，返回确认报文段(第二次握手)而后传输数据等等，后关闭连接，但此时，超时的请求又到达了服务端，服务端端口又会一直打开，造成资源浪费。

        第二种情况：服务端收到连接请求(第一次握手)，打开端口，但是返回的确认报文段(第二次握手)因为网络原因失了，丢失之后客户端就一直接收不到返回的数据包，客户端(超时重传机制)再重新发起新的请求，但是服务端是不知道的，认为是新的连接请求，此时服务器就会重新开启一个端口连接。长此以往， 这样的端口越来越多，就会造成服务器开销的浪费。

• 防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
• 为了防止服务器端开启一些无用的连接增加服务器开销

具体过程：

        考虑这样一种情况，TCP客户进程发出一个TCP连接请求报文段，但该报文段在某些网络节点长时间滞留了，这必然会造成该报文段的超时重传。

        假设重传的报文段被TCP服务器进程正常接收，TCP服务器进程给TCP客户进程发送一个TCP连接请求确认报文段，并进入连接已建立状态。

        请注意，由于我们改为两报文握手，因此TCP服务器进程发送完TCP连接请求确认报文段后，进入的是连接已建立状态，而不像三报文握手那样进入同步已接收状态，TCP服务器进程并等待TCP客户进程发来针对TCP连接请求确认报文段的普通确认报文段。TCP客户进程收到TCP连接请求确认报文段后进入TCP连接已建立状态，但不会给TCP服务器进程发送针对该报文段的普通确认报文段。

        现在，TCP双方都处于连接已建立状态，他们可以相互传输数据，之后可以通过四报文挥手来释放连接，TCP双方都进入了关闭状态。

        一段时间后，之前滞留在网络中的那个失效的TCP连接请求报文段到达了TCP服务器进程，TCP 服务器进程会误认为这是TCP客户进程又发起了一个新的TCP连接请求，于是给TCP客户进程发送TCP连接请求确认报文段并进入连接已建立状态。

        该报文段到达TCP客户进程，由于TCP客户进程并没有发起新的TCP连接请求，并且处于关闭状态，因此不会理会该报文段。

        但TCP服务器进程已进入了连接已建立状态，他认为新的TCP连接已建立好了，并一直等待TCP客户进程发来数据。这将白白浪费TCP服务器进程所在主机的很多资源。

        综上所述，采用三报文握手，而不是两报文握手来建立TCP连接，是为了防止已失效的连接请求报文段突然又传送到了TCP服务器进程因而导致错误。

5、 四次挥手

还是先上图：

聚散终有时，TCP 断开连接是通过四次挥手方式。

双方都可以主动断开连接，断开连接后主机中的「资源」将被释放。

上图是客户端主动关闭连接 ：

一次挥手

• 客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。(A告诉B要断开A->B的连接了)
• 注：FIN = 1，ACK = 1，seq = u，ack = v

二次挥手

• 服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。(B收到A的消息，回复A：我知道了)
• 注：ACK = 1，seq = v，ack = u + 1

三次挥手

• 客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。(B告诉A，我也要断开B-A的连接了)
• 注：FIN = 1，ACK = 1，seq = w，ack = u + 1

四次挥手

• 客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
• 服务器收到了 ACK 应答报文后，就进入了 CLOSED 状态，至此服务端已经完成连接的关闭。
• 客户端在经过 2MSL 一段时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭。（A收到消息，回复B：我知道了）
• 注：ACK = 1，seq = u + 1，ack = w + 1

你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。

为什么要挥手四次？

再来回顾下四次挥手双方发 FIN 包的过程，就能理解为什么需要四次了。

• 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
• 服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。
• 最后客户端收到了B的FIN同意关闭的消息，也回一个ACK应答报文。

        从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，从而比三次握手导致多了一次。

为什么客户端在TIME-WAIT阶段要等2MSL？

        为的是确认服务器端是否收到客户端发出的 ACK 确认报文，当客户端发出最后的 ACK 确认报文时，并不能确定服务器端能够收到该段报文。

        所以客户端在发送完 ACK 确认报文之后，会设置一个时长为 2MSL 的计时器。

        MSL 指的是 Maximum Segment Lifetime：一段 TCP 报文在传输过程中的最大生命周期。

        2MSL 即是服务器端发出为 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长。

        服务器端在 1MSL 内没有收到客户端发出的 ACK 确认报文，就会再次向客户端发出 FIN 报文：

• 如果客户端在 2MSL 内，再次收到了来自服务器端的 FIN 报文，说明服务器端由于各种原因没有接收到客户端发出的 ACK 确认报文。

客户端再次向服务器端发出 ACK 确认报文，计时器重置，重新开始 2MSL 的计时。

• 否则客户端在 2MSL 内没有再次收到来自服务器端的 FIN 报文，说明服务器端正常接收了 ACK 确认报文，客户端可以进入 CLOSED 阶段，完成“四次挥手”。

所以，客户端要经历时长为 2SML 的 TIME-WAIT 阶段;这也是为什么客户端比服务器端晚进入 CLOSED 阶段的原因。

这里同样有个动态过程的图示：

 好了，我们的文章到这就……

唉，不对，就这么完了，这会我好像知道了，但过会儿那就说不定了。

没关系，我苦思冥想，找了两个大白话的例子，保准你忘不了。

大白话说三次握手

在二十年前的农村，电话没有普及，手机就更不用说了，所以，通信基本靠吼。

老张和老王是邻居，这天老张下地了，结果家里有事，热心的邻居老王赶紧跑到村口，开始叫唤老王。

• 老王：老张唉！我是老王，你能听到吗？
• 老张一听，是老王的声音：老王老王，我是老张，我能听到，你能听到吗？
• 老王一听，嗯，没错，是老张：老张，我听到了，我有事要跟你说。

"你老婆要生了，赶紧回家吧！"

老张风风火火地赶回家，老婆顺利地生了个带把的大胖小子。

握手的故事充满了幸福和美满。

大白话说四次挥手

假如博主有一个女朋友——只是“假如”，该死的，这不争气的眼泪，怎么止不住地滴在键盘上。

由于博主上班九九六，下班肝博客，导致没有时间陪女朋友，女朋友忍无可忍。

• 女朋友：臭男人，最近你都不理我，你是不是不爱我了？你是不是外面有别的狗子了？我要和你分手？
• 沙雕博主一愣，怒火攻心：分手就分手，不陪你闹了，等我把东西收拾收拾。

沙雕博主小心翼翼地装起了自己的青轴机械键盘。

• 哼，蠢女人，我已经收拾完了，我先滚为敬，再见！
• 女朋友：滚，滚的远远的，越远越好，我一辈子都不想再见到你。

唉，挥手的故事总充满了悲伤和遗憾！

好了，白话纯属娱乐！看在博主费了不少脑子的份上，点个赞再走呗！！