【网络】TCP三次握手连接和四次挥手断开

bandaoyu

已于 2022-09-06 16:22:08 修改

阅读量1k

点赞数 1

分类专栏：网络编程文章标签： tcp/ip 网络 http

于 2018-11-21 21:20:45 首次发布

本文链接：https://blog.csdn.net/bandaoyu/article/details/84330128

版权

网络编程专栏收录该内容

125 篇文章 67 订阅

订阅专栏

TCP报文格式

关于三次握手与四次挥手面试官想考我们什么？

三次握手

四次挥手

TCP连接为什么是三次握手？断开为什么是四次挥手？

TCP/IP详解10-传输层：TCP：传输控制协议_Lincoln_cz的博客-CSDN博客

实战

TCP的状态 (SYN, FIN, ACK, PSH, RST, URG)https://www.cnblogs.com/azraelly/archive/2012/12/25/2832393.html

简单记（编辑中）

三次握手：

我和同事在同一层楼，但是不同部门，不怎么认识，今天需要找他沟通，不知道他坐哪，但是可以搜工号，用邮件（SYN）约他：

我---------------------同事

---------------------->邮件（SYN）：有空？沟通一下。 SYN（J）

<--------------------邮件（SYN）：我坐在B区16号。 SYN（K） + ACK(J+1)

知道他在哪个位置了，直接喊话：

--------------------->我在A区8号呀，过来聊一下。 ACK（K+1）

考点：

一、三次握手目的：

1、确认双方收发能力正常。（确认同事有空有能力沟通）

2、首要目的是同步序列号（SYN），为后面的可靠传送做准备。

~~3、如果是 https 协议的话，三次握手这个过程，还会进行数字证书的验证以及加密密钥的生成到。~~

二、为啥只有三次握手才能确认双方的接受与发送能力是否正常，而两次却不可以

只有三次握手，双方才能确认对端收发功能都OK。

第一次：客户端发，服务端收到了。

------>客户端知：客发OK。服务端知：服收OK+客发OK

第二次：服务端发，客户端收到了

----->客户端知：服发OK（不然也不会收到服务信息） + 客收OK。服务端知：服发OK

第三次：客户端发，服务端收到了。

----->客户端知：服收OK（不然也会给客回此次）。服务端知：客收OK（不然也不会回此次）

三次加起来：

客户端知：客发OK + 服发OK；服收OK + 客收OK；

服务端知：服收OK+服发OK；客发OK + 客收OK；

四次挥手

白话

转自：“三次握手，四次挥手”这么讲，保证你忘不了：https://zhuanlan.zhihu.com/p/374998210

目的：

1、TCP是收发两个方向的通道，确保方向的通道都完成关闭。

2、确保两个方向的通道里的数据都能发完全了再关闭。

为什么断开连接需要四次挥手
我们都知道，TCP连接是全双工通信的，而断开时双方都需要确定两个问题：自己是否还有数据要发送，对端是否还有数据要发送，而四次挥手正好在双方同步了这两个问题。

关于三次握手与四次挥手面试官想考我们什么？

在面试中，三次握手和四次挥手可以说是问的最频繁的一个知识点，下面是比较重要的点，是比较被面试官给问到：

三次握手

当面试官问你为什么需要有三次握手、三次握手的作用、讲讲三次三次握手的时候，我想很多人会这样回答：

首先很多人会先讲下握手的过程：

1、第一次握手：客户端给服务器发送一个 SYN 报文。

2、第二次握手：服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。

3、第三次握手：客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。

4、服务器收到 ACK 报文之后，三次握手建立完成。

作用是为了确认双方的接收与发送能力是否正常 + 同步序列号。

这里我顺便解释一下为啥只有三次握手才能确认双方的接受与发送能力是否正常，而两次却不可以：
第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

因此，需要三次握手才能确认双方的接收与发送能力是否正常。

这样回答其实也是可以的，但我觉得，这个过程的我们应该要描述的更详细一点，因为三次握手的过程中，双方是由很多状态的改变的，而这些状态，也是面试官可能会问的点。所以我觉得在回答三次握手的时候，我们应该要描述的详细一点，而且描述的详细一点意味着可以扯久一点。加分的描述我觉得应该是这样：

刚开始客户端处于 closed 的状态，服务端处于 listen 状态。然后

1、第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_Send 状态。

2、第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。

3、第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 establised 状态。

4、服务器收到 ACK 报文之后，也处于 establised 状态，此时，双方以建立起了链接。

黑客基础知识——SYN泛洪攻击原理及防御

三次握手的作用

三次握手的作用也是有好多的，多记住几个，保证不亏。例如：

1、确认双方收发能力正常。

2、指定自己的初始化序列号，为后面的可靠传送做准备。

3、如果是 https 协议的话，三次握手这个过程，还会进行数字证书的验证以及加密密钥的生成到。

三次握手建立连接的首要目的是（SYN）同步序列号。只有同步了序列号才有可靠的传输，TCP 协议的许多特性都是依赖序列号实现的，比如流量控制、重传等等，这也是三次握手中的报文被称为 SYN 的原因，因为 SYN 的全称就叫做 Synchronize SequenceNumbers。
链接：https://www.jianshu.com/p/74c19f436c2d

单单这样还不足以应付三次握手，面试官可能还会问一些其他的问题，例如：

1、（ISN）是固定的吗

三次握手的一个重要功能是客户端和服务端交换ISN(Initial Sequence Number), 以便让对方知道接下来接收数据的时候如何按序列号组装数据。

如果ISN是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

2、什么是半连接队列

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

这里在补充一点关于 SYN-ACK 重传次数的问题：　服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s, 2s, 4s, 8s, ....

3、三次握手过程中可以携带数据吗

其实第三次握手的时候，是可以携带数据的。也就是说，第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。

为什么这样呢？大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。也就是说，第一次握手可以放数据的话，其中一个简单的原因就是会让服务器更加容易受到攻击了。

而对于第三次的话，此时客户端已经处于 established 状态，也就是说，对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据页没啥毛病。

关于三次握手的，https 的认证过程能知道一下最好，不过我就不说了，留着写 http 面试相关时的文章再说。

四次挥手

四次挥手也一样，千万不要对方一个 FIN 报文，我方一个 ACK 报文，再我方一个 FIN 报文，我方一个 ACK 报文。然后结束，最好是说的详细一点，要把每个阶段的状态记好，我上次面试就被问了几个了：

刚开始双方都处于 establised 状态，假如是客户端先发起关闭请求，则：

1、第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时服务端处于CLOSED_WAIT1状态。

2、第二次握手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT2状态。

3、第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

4、第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态

5、服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

（主动关闭（active close)的一方，被动关闭（passive close）的一方，网络上类似的图有很多，但是有的细节不够，有的存在误导。有的会把两条线分别标记成Client和Server。给读者造成困惑。）

这里特别需要主要的就是TIME_WAIT这个状态了，这个是面试的高频考点，就是要理解，为什么客户端发送 ACK 之后不直接关闭，而是要等一阵子才关闭。这其中的原因就是，要确保服务器是否已经收到了我们的 ACK 报文，如果没有收到的话，服务器会重新发 FIN 报文给客户端，客户端再次收到 ACK 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文。（如果服务器重发多次FIN 一直收不到ack会怎么样？见文章后末尾）

至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时，如果过了这个计时没有再次收到 FIN 报文，则代表对方成功就是 ACK 报文，此时处于 CLOSED 状态。

（关于TIME_WAIT持续时间影响性能的案例：性能案例-Linux下解决time_wait连接过多（Linux内核优化）-https://zhuanlan.zhihu.com/p/29334504）

最后，在放在三次握手与四次挥手的图

关于三次握手与四次挥手面试官想考我们什么？--- 不看后悔系列 - 知乎

这里我给出每个状态所包含的含义，有兴趣的可以看看。

LISTEN - 侦听来自远方TCP端口的连接请求；
SYN-SENT -在发送连接请求后等待匹配的连接请求；
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认；
ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；
FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；
FIN-WAIT-2 - 从远程TCP等待连接中断请求；
CLOSE-WAIT - 等待从本地用户发来的连接中断请求；
CLOSING -等待远程TCP对连接中断的确认；
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；
TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认；
CLOSED - 没有任何连接状态；

TCP连接为什么是三次握手？断开为什么是四次挥手？

1.三次握手
TCP连接换成四次握手行不行？为什么？换成两次握手行不行？为什么？这是我面试时遇到的原题

首先来说一下三次握手，为什么需要三次握手呢？因为TCP提供的是可靠传输服务，因此它在传输之前必须要进行传输的可靠性测试和一些信息的同步，反观UDP就不用这些握手操作。三次握手正好使双方都能测试传输的可靠性，同时也能进行信息同步，三次握手过程如下：

在这里插入图片描述

那么三次握手到底是在握什么呢？抓包测试一下(抓包测试请看另一篇)：

在这里插入图片描述
三次握手的作用
第一次握手：client同步自己的发送序号seq和接收窗口win（还有其他可选信息），同时测试自己的发送能力是否正常
第二次握手：server发送确认号ack，证明了client发送正常。同时同步自己的发送信息seq和win，还要测试自己的发送能力是否正常
第三次握手：client发送确认号ack，证明了server发送正常
至此，发送信息同步完成，可靠性测试完成

两次握手是否可以
可以发现，前两次握手都需要发送同步信息，因此前两次肯定是必不可少的，唯一有可能的就是第三次，但是从上面的分析来看，如果少了第三次握手，那么client知道自己的发送能力正常，发送信息也同步完成，但是server不能确定自己的发送能力是否正常，也不知道自己的发送信息是否同步完成，因此第三次握手也是必不可少的。

PS：SYN泛洪攻击原理就是恶意终端故意不发送第三个握手包，操作系统在发送完第二次握手包后，会分配一些资源给这个半连接，同时将这个半连接放入半连接队列，半连接过多时会导致server半连接队列满，正常用户的请求得不到相应，同时过多的半连接占用过多的资源还会影响server性能。

四次握手是否可以
有的人可能会想，第三次握手万一丢失了呢？是不是需要第四次握手来对第三次进行确认？第三次握手确实可能会丢失，假如采用第四次来对第三次进行确认，那么第四次需要第五次来确人… …可以发现无论是四次五次或是更多次效果都是一样的，这样的协议既不可能实现也没有任何的效率可言。于是TCP采用了超时重传的策略来保证传输的可靠性，server在发送完第二次握手包之后，就会开启一个定时器，超时后如果没有收到第三次握手包，它就会重新发送SYN+ACK，重复以上步骤，如果失败三次后则说明连接失败，数据传输时采用同样的策略。

四次挥手
TCP四次挥手流程：

在这里插入图片描述

抓包测试：

在这里插入图片描述

第一次挥手：client告诉server自己的数据已全部发送，client可以回收发送缓冲区，server可以回收接收缓冲区
第二次挥手：server告诉client自己收到了关闭信息
第三次挥手：server告诉client自己的数据已全部发送，server可以回收发送缓冲区，client可以回收接收缓冲区
第四次挥手：client告诉server自己收到了关闭信息
可以发现，四次挥手同样一次都不能少，如果少了其中任何一次，总有一方不能可靠的通知对方自己的数据已发送完毕，因此，连接不可能可靠的断开，TCP也就成了不可靠的协议。

原文链接：https://blog.csdn.net/qq_40843865/article/details/103989969

#################################################################################################

TCP三次握手过程

1 主机A通过向主机B 发送一个含有同步序列号的标志位的数据段给主机B ,向主机B 请求建立连接,通过这个数据段,
主机A告诉主机B 两件事:我想要和你通信;你可以用哪个序列号作为起始数据段来回应我.
2 主机B 收到主机A的请求后,用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A,也告诉主机A两件事:
我已经收到你的请求了,你可以传输数据了;你要用哪个序列号作为起始数据段来回应我
3 主机A收到这个数据段后,再发送一个确认应答,确认已收到主机B 的数据段:"我已收到回复,我现在要开始传输实际数据了

这样3次握手就完成了,主机A和主机B 就可以传输数据了.
3次握手的特点
没有应用层的数据
SYN这个标志位只有在TCP建产连接时才会被置1
握手完成后SYN标志位被置0

4次断开

1 当主机A完成数据传输后,将控制位FIN置1,提出停止TCP连接的请求
2 主机B收到FIN后对其作出响应,确认这一方向上的TCP连接将关闭,将ACK置1
3 由B 端再提出反方向的关闭请求,将FIN置1
4 主机A对主机B的请求进行确认,将ACK置1,双方向的关闭结束.
由TCP的三次握手和四次断开可以看出,TCP使用面向连接的通信方式,大大提高了数据通信的可靠性,使发送数据端
和接收端在数据正式传输前就有了交互,为数据正式传输打下了可靠的基础

名词解释
ACK TCP报头的控制位之一,对数据进行确认.确认由目的端发出,用它来告诉发送端这个序列号之前的数据段
都收到了.比如,确认号为X,则表示前X-1个数据段都收到了,只有当ACK=1时,确认号才有效,当ACK=0时,确认号无效,这时会要求重传数据,保证数据的完整性.
SYN 同步序列号,TCP建立连接时将这个位置1
FIN 发送端完成发送任务位,当TCP完成数据传输需要断开时,提出断开连接的一方将这位置1

解释原因：

TCP建立连接要进行3次握手,而断开连接要进行4次,这是由于TCP的半关闭造成的,因为TCP连接是全双工的(
即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭,这个单方向的关闭就叫半关闭.
关闭的方法是一方完成它的数据传输后,就发送一个FIN来向另一方通告将要终止这个方向的连接.当一端收到一个FIN,它必须
通知应用层TCP连接已终止了这个方向的数据传送,发送FIN通常是应用层进行关闭的结果.

为什么不能两次握手能进行连接？

我们知道，3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

TCP 的三次握手过程？为什么会采用三次握手，若采用二次握手可以吗？

建立连接的过程是利用客户服务器模式，假设主机 A 为客户端，主机 B 为服务器端。

1 ） TCP 的三次握手过程：主机 A 向 B 发送连接请求；主机 B 对收到的主机 A 的报文段进行确认；主机 A 再次对主机 B 的确认进行确认。

2 ）采用三次握手是：为了防止失效的连接请求报文段突然又传送到主机 B ，因而产生错误。

失效的连接请求报文段是指：主机 A 发出的连接请求没有收到主机 B 的确认，于是经过一段时间后，主机 A 又重新向主机 B 发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机 A 第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机 B ，主机 B 以为是主机 A 又发起的新连接，于是主机 B 同意连接，并向主机 A 发回确认，但是此时主机 A 根本不会理会，主机 B 就一直在等待主机 A 发送数据，导致主机 B 的资源浪费

TCP的状态变迁图:

TCP/IP详解10-传输层：TCP：传输控制协议_Lincoln_cz的博客-CSDN博客

请问如何提升TCP三次握手的性能？

面试官：请问如何提升TCP三次握手的性能？ - 简书

实战

error 111: (111) Connection refused 原因分析

【网络】连接服务器失败（错误原因：Connection refused）| error 111: (111) Connection refused 原因分析_bandaoyu的note-CSDN博客

抓包结果：连接服务器失败（错误原因：Connectionrefused）error111抓包结果-其它文档类资源-CSDN下载

40449	23.888712	192.169.136.113	192.169.136.111	TCP	60	6811 → 33580 [ACK] Seq=1 Ack=1 Win=501 Len=0
40450	23.888763	192.169.136.112	192.169.136.111	TCP	167	6803 → 54332 [PSH, ACK] Seq=1 Ack=1 Win=501 Len=113
40451	23.888781	192.169.136.112	192.169.136.111	TCP	167	6807 → 53000 [PSH, ACK] Seq=1 Ack=1 Win=501 Len=113
40452	23.888786	192.169.136.112	192.169.136.111	TCP	71	6807 → 53000 [PSH, ACK] Seq=114 Ack=1 Win=501 Len=17
40453	23.888794	192.169.136.112	192.169.136.111	TCP	167	6811 → 54634 [PSH, ACK] Seq=1 Ack=1 Win=501 Len=113
40454	23.888798	192.169.136.112	192.169.136.111	TCP	71	6803 → 54332 [PSH, ACK] Seq=114 Ack=1 Win=501 Len=17
40455	23.888807	192.169.136.113	192.169.136.111	TCP	167	6807 → 34066 [PSH, ACK] Seq=1 Ack=1 Win=501 Len=113
40456	23.888808	192.169.136.112	192.169.136.111	TCP	71	6811 → 54634 [PSH, ACK] Seq=114 Ack=1 Win=501 Len=17
40457	23.888829	192.169.136.113	192.169.136.111	TCP	71	6807 → 34066 [PSH, ACK] Seq=114 Ack=1 Win=501 Len=17
40458	23.888873	192.169.136.113	192.169.136.111	TCP	167	6811 → 33580 [PSH, ACK] Seq=1 Ack=1 Win=501 Len=113
40459	23.888878	192.169.136.113	192.169.136.111	TCP	71	6811 → 33580 [PSH, ACK] Seq=114 Ack=1 Win=501 Len=17
40460	23.889119	192.169.136.112	192.169.136.111	TCP	60	6803 → 54332 [ACK] Seq=131 Ack=18 Win=501 Len=0
40461	23.889140	192.169.136.112	192.169.136.111	TCP	60	6811 → 54634 [ACK] Seq=131 Ack=18 Win=501 Len=0
40474	23.895604	182.200.29.46	182.200.29.24	TCP	60	8500 → 37873 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
40475	23.895700	182.200.29.46	182.200.29.24	TCP	60	8500 → 50231 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
40476	23.895727	182.200.29.47	182.200.29.24	TCP	60	8500 → 39099 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
40479	23.895766	182.200.29.47	182.200.29.24	TCP	60	8500 → 50907 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
40480	23.895812	182.200.29.48	182.200.29.24	TCP	60	8500 → 39059 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
40481	23.895837	182.200.29.48	182.200.29.24	TCP	60	8500 → 34037 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
40487	23.905299	192.169.29.124	192.169.29.125	TCP	63	49240 → 6818 [PSH, ACK] Seq=1 Ack=1 Win=176 Len=9
40488	23.905393	192.169.29.124	192.169.29.125	TCP	60	49240 → 6818 [ACK] Seq=10 Ack=10 Win=176 Len=0
40490	23.911898	182.200.100.84	182.200.100.95	TCP	74	2181 → 55892 [PSH, ACK] Seq=1 Ack=1 Win=21 Len=20
40491	23.912584	182.200.100.84	182.200.100.95	TCP	74	2181 → 43776 [PSH, ACK] Seq=1 Ack=1 Win=21 Len=20
40496	23.917271	192.169.29.126	192.169.29.125	TCP	63	46832 → 6822 [PSH, ACK] Seq=1 Ack=1 Win=443 Len=9
40497	23.917286	192.169.29.126	192.169.29.125	TCP	63	34540 → 6820 [PSH, ACK] Seq=1 Ack=1 Win=201 Len=9
40498	23.917361	192.169.29.126	192.169.29.125	TCP	60	46832 → 6822 [ACK] Seq=10 Ack=10 Win=443 Len=0
40499	23.917368	192.169.29.126	192.169.29.125	TCP	60	34540 → 6820 [ACK] Seq=10 Ack=10 Win=201 Len=0
40505	23.925733	182.200.100.84	182.200.100.95	TCP	66	37308 → 2181 [PSH, ACK] Seq=1 Ack=1 Win=22 Len=12
40506	23.925876	182.200.100.84	182.200.100.95	TCP	60	37308 → 2181 [ACK] Seq=13 Ack=21 Win=22 Len=0
40507	23.929033	192.169.136.113	192.169.136.111	TCP	60	6803 → 54244 [ACK] Seq=131 Ack=18 Win=501 Len=0
40508	23.930029	192.169.136.113	192.169.136.111	TCP	60	6811 → 33580 [ACK] Seq=131 Ack=18 Win=501 Len=0
40509	23.930038	192.169.136.113	192.169.136.111	TCP	60	6807 → 34066 [ACK] Seq=131 Ack=18 Win=501 Len=0
40510	23.930106	192.169.136.112	192.169.136.111	TCP	60	6807 → 53000 [ACK] Seq=131 Ack=18 Win=501 Len=0
40512	23.933592	172.17.29.124	172.17.29.126	TCP	63	6804 → 59380 [PSH, ACK] Seq=1 Ack=1 Win=1711 Len=9
40513	23.933598	172.17.29.125	172.17.29.126	TCP	63	6807 → 50964 [PSH, ACK] Seq=1 Ack=1 Win=11180 Len=9

TCP的状态 (SYN, FIN, ACK, PSH, RST, URG)https://www.cnblogs.com/azraelly/archive/2012/12/25/2832393.html

在TCP层，有个FLAGS字段，这个字段有以下几个标识：SYN, FIN, ACK, PSH, RST, URG.

其中，对于我们日常的分析有用的就是前面的五个字段。

它们的含义是：

SYN表示建立连接，

FIN表示关闭连接，

ACK表示响应，

PSH表示有 DATA数据传输，

RST表示连接重置。

其中，ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应，

如果只是单个的一个SYN，它表示的只是建立连接。

TCP的几次握手就是通过这样的ACK表现出来的。

但SYN与FIN是不会同时为1的，因为前者表示的是建立连接，而后者表示的是断开连接。

RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。

一般地，当出现FIN包或RST包时，我们便认为客户端与服务器端断开了连接；而当出现SYN和SYN＋ACK包时，我们认为客户端与服务器建立了一个连接。

PSH为1的情况，一般只出现在 DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。

TCP的连接建立和连接关闭，都是通过请求－响应的模式完成的。

概念补充-TCP三次握手：

TCP(Transmission Control Protocol)传输控制协议

TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接：

位码即tcp标志位，有6种标示：SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)Sequence number(顺序号码) Acknowledge number(确认号码)

第一次握手：主机A发送位码为syn＝1，随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；

第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1)，syn=1，ack=1，随机产生seq=7654321的包；

第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1)，ack=1，主机B收到后确认seq值与ack=1则连接建立成功。

完成三次握手，主机A与主机B开始传送数据。

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据. 摘自中国云安网(www.yunsec.net) 原文：幸运快3开奖号-幸运快3最准的计划幸运快3全天计划单期海外分公司

TCP报文格式

处于last_ack状态的连接，如果一直收不到对方的ack，会怎么样？

链接：https://www.zhihu.com/question/27564314/answer/2005063108

开局先上一副四次挥手的图，清晰明朗好交流。

被动关闭方进入 LAST_ACK 状态，等待主动方返回 ACK 来确认连接关闭，操作系统才不是傻姑，会让这个状态一直持续，持续状态意味着占用链接，肯定有兜底方案的嘛。

如果迟迟收不到这个 ACK，内核就会重发 FIN 报文，如果重传的次数超过 tcp_orphan_retries 内核参数设置的次数，就会放弃重传，然后进入close状态。

tcp_orphan_retries 内核参数的默认值是 0，如果你要自定义 fin 报文的重传次数可以看：

你可能会好奇，这 0 表示几次？实际上当为 0 时，特指 8 次，从下面的内核源码可知：

絮叨

bandaoyu

关注

1
点赞
踩
6

收藏

觉得还不错? 一键收藏
1
评论
【网络】TCP三次握手连接和四次挥手断开

TCP连接为什么是三次握手？断开为什么是四次挥手？1.三次握手TCP连接换成四次握手行不行？为什么？换成两次握手行不行？为什么？这是我面试时遇到的原题首先来说一下三次握手，为什么需要三次握手呢？因为TCP提供的是可靠传输服务，因此它在传输之前必须要进行传输的可靠性测试和一些信息的同步，反观UDP就不用这些握手操作。三次握手正好使双方都能测试传输的可靠性，同时也能进行信息同步，三...
复制链接

扫一扫