接下来，让我们了解为什么需要进行三次握手，而不是两次握手、四次握手。 当客户端和服务端刚开始时，它们都处于关闭状态。同时，服务器端始终处于监听状态，以便随时接收连接请求。...当某个客户端需要建立连接时，它会发送一个确定连接的报文。这个报文被称为同步报文 (Sync Packet)，其中 SYN = 1，并且会生成一个随机序号 seq = x。这是第一次握手。...具体而言，该报文中 SYN = 1 和 ACK = 1，同时服务端也会生成一个随机序号 seq = y，并将确认序号设置为 x + 1。这是第二次握手。...当客户端接收到服务端的确认报文后，它会发送一个用于确认服务端已接收到确认报文的确认报文（ACK）。该报文中 ACK = 1，序号 seq = x + 1，确认序号 ack = y + 1。...如果采用四次握手，假设在三次握手的过程中，客户端接收到了服务器发送的确认报文，但是由于某些原因，这个确认报文在网络中丢失了。 客户端没有收到服务器的确认，会认为连接没有建立成功，并会重发连接请求。
，他们都属于TCP/IP协议族： UDP UDP的全称是⽤户数据报协议，在⽹络中它与TCP协议⼀样⽤于处理数据包，是⼀种⽆连接的协议。...在OSI模型中，在传输层，处于IP协议的上⼀层。UDP有 不提供数据包分组、组装和不能对数据包进⾏排序的缺点，也就是说，当报⽂发送之后，是⽆法得知其是否安全完整到达的。...在确认报⽂段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y 第三次握⼿：客户端收到 SYN 报⽂之后，会发送⼀个 ACK 报⽂，当然，也是⼀样把服务器的 ISN+1 作为 ACK...确认报⽂段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第⼆个报⽂段所以要+1），ACK报⽂段可以携带数据，不携带数据则不消耗序号。...即服务端没有要向客户端发出的数据，服务端发出连接释放报⽂段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进⼊LAST_ACK（最后确认）状态，等待客户端的确认。
之后将同步位 SYN 设置为 1，同时选择一个初始序列号 seq=x，这时客户端 A 进入到 SYN-SENT（同步已发送）状态。...在确认报文段中 同步位 SYN=1、确认位 ACK=1、确认号 ack=x+1，同时也为自己选择一个初始序列号 seq=y，这时服务器 B 进入 SYN-RCVID 状态。...第一次挥手:A 先发送连接释放报文段，段首部的终止控制位 FIN=1，序号seq=u（等于A前面发送数据的最后一个序号加1）；然后 A 进入 FIN-WAIT-1（终止等待1）状态，等待 B 的确认。...第二次挥手:B 收到 A 的连接释放报文段后，立刻发出确认报文段，确认号 ack=u+1，序号 seq=v（等于 B 前面发送数据的最后一个序号加1）；然后 B 进入 CLOSE-WAIT（关闭等待）状态...第四次挥手:A收到B的连接释放报文段并发出确认，确认段中 确认位 ACK=1，确认号 ack=w+1，序号 seq=u+1；然后 A 进入到TIME-WAIT（时间等待）状态。
2、服务端收到客户端的 SYN 报文后，也随机一个初始序列号 (seq=y)，设置 ack=x+1，表示收到了客户端的 x 之前的数据，希望客 户端下次发送的数据从 x+1 开始。...设置 SYN=1 和 ACK=1。表示这 是一个 SYN 握手和 ACK 确认应答报文。最后把该报文发给客户端，该 报文也不包含应用层数据，之后服务端处于同步已接收状态。...3、客户端收到服务端报文后，还要向服务端回应最后一个应答报文， 将 ACK 置为 1 ，表示这是一个应答报文 ack=y+1 ，表示收到了服务 器的 y 之前的数据，希望服务器下次发送的数据从 y+1...建立连接时，客户端和服务器需要交换三个数据包；关闭连接时，需要交换四个数据包。 四次握手中，最后一个ACK是为了确认服务器已经接收到了客户端的关闭请求，防止出现丢失的情况。...在三次握手中，最后一个ACK是用来确认客户端已经接收到服务器的同意连接请求。 总体来说，三次握手和四次握手是TCP连接的建立和关闭的标准过程，确保通信双方的状态同步和数据的可靠传输。
SYN—为1表示这是连接请求或是连接接受请求，用于创建连接和使顺序号同步 FIN—为1表示发送方没有数据要传输了，要求释放连接， Seq---序号，这是为了连接以后传送数据用的， Ack---确认号对收到的数据包的确认...即Ack的值等于Client发过来Seq的值加1，即Ack = X+1。因为我都知道你发过来的Seq的值，所以这个数据包没有丢失。...Seq = Y（第二次握手的数据包序列号） Server给Client的数据包序列号，为了数据包在到达Client之后的验证，所以这次从Server到Client的数据包中同样也会随机产生一个Seq number...= Y， 第三次握手 ACK=1（对第二次握手的确认） 首先Client会打开Server发送过来的Ack验证一下是否正确为Seq+1，即第一次发送的seq number+1，确认无误后，Client...五、TCP的十种状态 这十种状态分别是三次握手和四次挥手中的状态，在上面两个图中都给大家标记出来了，这里再给大家一个简单的图表示 ?
我们在着重讲一下在三次握手和四次挥手中的用到序列号、确认号及标志位。 1....序列号seq 占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生，给字节编上序号后，就给每一个报文段指派一个序号，序列号seq就是这个报文段中的第一个字节的数据编号...（其中，SYN=1，ACK=0，表示这是一个TCP连接请求数据报文；序号seq=x，表明传输数据时的第一个数据字节的序号是x）。 step2:第二次握手 服务器收到请求后，必须确认客户的数据包。...（其中确认报文段中，标识位SYN=1，ACK=1，表示这是一个TCP连接响应数据报文，并含服务端的初始序号seq(服务器)=y，以及服务器对客户端初始序号的确认号ack(服务器)=seq(客户端)+1=...step4：第四次挥手 客户端收到FIN后，并发回一个ACK报文确认，并将确认序号seq设置为收到序号加一。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
TCP 连接，检查 ACK 是否为 1，ack 是否为 x + 1；客户端发包，确认标志位 ACK = 1，确认号 ack = y + 1（表示自己希望下一次收到服务端发过来的是 y + 1），seq...= x + 1 服务端收包，确认 ACK = 1，确认 seq = x + 1，双方成功建立 TCP 连接 为什么是三次握手，而不是两次或者四次？...一开始，双方都处于 established 状态 第一次挥手：客户端发送一个连接释放报文段（FIN=1.seq = u），表示自己已经不再发送数据了，打算主动关闭 TCP 连接。...三次握手之所以只需要三次，是因为服务端在第一次响应中，可以将 ACK 和 SYN 一并发送给客户端，一方面对客户端的 SYN 做一个确认，另一方面做一个同步，表示自己也想要建立 TCP 连接，==注意这两件事完全可以在一次响应中同时完成...快速重传解决了等待 timeout 的问题，但是它和超时重传一样，无法做到单独重传丢失了的数据包，而是将该数据包和之后陆续发送的数据包一起重传（因为发送端并不清楚具体丢失了多少个数据包，可能认为后面的数据包都丢失了
通信流程 TCP 的通信流程 上图中的每一个箭头都代表着一次 TCP数据包的发送 需要注意的是， 上图中出现的 ACK = x +1 的写法很容易让人误以为数据包中的 ACK 域的数据值被填成了...ACK = x+1 的实际含义是： TCP 包的 ACK 标志位（1 bit） 被置成了 1 TCP 包的确认号（acknowledgement number ） 的值为 x+1 类似的， TCP 数据包中的...UDP 和 TCP 协议都是基于同样的互联网基础设施， 且都基于 IP 协议实现， 互联网基础设施中对于数据包的发送过程是会发生丢包现象的， 为什么 TCP 就可以实现可靠传输， 而 UDP 不行？...题外话 有一位读者关注到了三次握手中， 序列号变化的问题， 让笔者临时想起了曾经困扰自己的一个问题 为什么三次握手最后一次握手中， 在上面的示意图中回复的 seq = x+1 。...所以三次握手结束后， 客户端下一个发送的报文中 seq 依旧是 x+1， 示意图如下 注意到， 上图第四步发送的 seq 和第三次握手的 seq 是一样的， 体现了最后一次握手， 默认不消耗序列号的特点
TCP连接建立过程需要经过三次握，断开过程需要经过四次挥手，为什么？ 有没有其他的连接建立、断开方式？ 一、 TCP连接建立过程 1. 三次握手 TCP正常的建立连接过程如下图所示： ?...服务器收到数据包后，根据标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=x+1，随机产生一个初始序号seq=y，并将该数据包发送给Client以确认连接请求...Client收到确认后，检查ack是否为x+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=y+1，并将该数据包发送给Server。...为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态 为了保证主动关闭方发送的最后一个ACK报文能够到达被动关闭方。...A和B再次建立连接，所用IP和端口与1中相同，二者数据传输过程中，B正好请求A发送seq为100的数据，这时1中滞留的报文到达B，TCP认为该报文合法，就接收了这个报文。
TCP协议在双方建立连接的时候需要三次握手，首先客户端发送SYN标志为1的TCP数据包，然后服务器端收到之后，也会发送一个SYN标志置位，并且带有ack应答的数据包，最后客户端再发送给服务端一个应答，...首先看TCP数据包头部各个字段： 在三次握手和四次挥手过程中，主要看UAPRSF6个标志和seq ack的变化。...> 0xc571), seq 1, ack 1, win 229, length 0，发现没了选项字段，说明在默认情况下，选项字段是在三次握手中前两次握手时确定了双方的各种属性。...c480也就是服务端发来的ack字段，ack为服务端的seq + 1，标志变成了0x10只置位了ACK字段，说明这就是一个简单的确认报文。...标志位为 0x11，ACK 和FIN为1，所以客户端发送的是关闭连接请求。
TCP头部 源端口和目的端口在TCP层确定双方进程，序列号表示的是报文段数据中的第一个字节号，ACK表示确认号，该确认号的发送方期待接收的下一个序列号，即最后被成功接收的数据字节序列号加1，这个字段只有在...为什么要“三次握手，四次挥手” 三次握手 换个易于理解的视角来看为什么要3次握手。 客户端和服务端通信前要进行连接，“3次握手”的作用就是双方都能明确自己和对方的收、发能力是正常的。...“三次握手，四次挥手”怎么完成？ 其实3次握手的目的并不只是让通信双方都了解到一个连接正在建立，还在于利用数据包的选项来传输特殊的信息，交换初始序列号ISN。...服务端发起自己的FIN段，ACK=K+1, Seq=L 客户端确认。ACK=L+1 为什么建立连接是三次握手，而关闭连接却是四次挥手呢？...查看是否有连接溢出 netstat -s | grep LISTEN 半连接队列满了 在三次握手协议中，服务器维护一个半连接队列，该队列为每个客户端的SYN包开设一个条目(服务端在接收到SYN包的时候，
在确认报文段中应把SYN位和ACK位都置1，确认号是ack=x+1，同时也为自己选择一个初始序号seq=y。注意。这个报文段也不能携带数据，但同样要消耗掉一个序号。...总结： 客户端在三次握手中，状态的转变是：CLOSED->SYN_SEND->ESTABLISHED 服务端在三次握手中，状态的转变是：CLOSED->LISTENED->SYN_RCVD->ESTABLISHED...在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态.当收到ACK后，服务器转入ESTABLISHED...第二次挥手： 服务端收到客户端的FIN报文段，会发送一个确认报文段ACK=1，以及确认序列号ack=u+1，还有自己的序列号seq=v（告诉客户端，我已经收到你的请求关闭消息，但是我还没准备好，请继续等待...在TCP连接中，服务端SYN和ACK向客户端发送是一次性发送的，而在断开连接的过程中，服务端向客户端发送的ACK和FIN是分两次发送的。
3次握手 第一次握手：主机A发送位码为syn＝1,随机产生seq number=x的数据包到服务器，客户端进入SYN_SEND状态，等待服务器的确认；主机B由SYN=1知道，A要求建立联机； 第二次握手...number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1...4次挥手 第一次挥手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT...这个 RST 数据包的 TCP 首部中，控制位中的 RST 位被设置为 1。这表示连接信息全部被初始化，原有的 TCP 通信不能继续进行。...实际上，在第三步中，客户端收到 FIN 包时，它会设置一个计时器，等待相当长的一段时间。如果客户端返回的 ACK 丢失，那么服务端还会重发 FIN 并重置计时器。
控制位 (Control Bits)：在三次握手和四次挥手中会经常看到 SYN、ACK 和 FIN 的身影，一共有 6 个标志位，它们表示的意义如下： URG (Urgent Bit)：值为 1 时，紧急指针生效...紧急指针 (Urgent Pointer)：当 URG 控制位值为 1 时，此字段生效，紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。...该包中也包含一个随机生成的序列号ISN，同时将确认序列号ACK设置为客户端的ISN+1。 第三次握手（ACK）：客户端收到服务器的SYN+ACK包后，向服务器发送ACK包，表示客户端也同意建立连接。...该包的序列号设置为服务器的ISN+1，确认序列号设置为服务器的ISN+1。 在三次握手完成后，TCP连接建立成功，双方可以开始进行数据传输。...在TCP三次握手的过程中，第三次握手中的ACK包中确认号（ACK number）是根据第二次握手中的序列号（Sequence number）加1生成的，这样可以确保双方都能够正确地识别对方的身份和数据传输的正确性
，将 SYN 位置为1，seq 为 y；服务端将上述所有信息放到一个报文段（即 SYN+ACK 报文段）中，一并发送给客户端，此时服务端进入 SYN_RECV 的状态； 第三次握手：客户端收到服务端的...然后将ack设置为y+1，向服务端发送ACK报文段，这个报文段发送完毕以后，客户端和服务端端都进入 ESTABLISHED 状态，完成TCP三次握手。...第一次挥手：客户端设置 seq和ack，向服务端发送一个FIN报文段；此时，客户端进入 FIN_WAIT_1 状态；这表示客户端没有数据要发送给服务端了； 第二次挥手：服务端收到了客户端发送的FIN报文段...其中序号 1-3 为三次握手的数据包，序号 4-7 为两次数据交换的数据包，8-10 为三次挥手的数据包。 ? 抓到的10个数据包 问题1：4-7 为什么是两次数据交换呢？...可以看出，我们所抓的包中，将第二次挥手和第三次挥手合并为一个数据包了，也就是192.168.78.130->192.168.78.128的包中既有FIN也有ACK，所以这也是三次挥手而不是四次挥手的原因
TCP四次挥手 四次挥手断开连接的过程： 1、Client主动关闭连接，序列号Sequence Number为和Server通信时Server的最后一次ACK报文的ack的值（假设seq值为x），...1，序列号Sequence Number的值为和Client通信时Client的最后一次ACK报文的ack的值（假设seq=z），确认序号Acknowledgement Number（ack）为Client...代码中客户端一共发送了4次数据，tcpdump也监听到了4组对应发送数据和ack的报文。 最后4行就是四次挥手的过程。...比如客户端同时发送了三个报文，每个报文seq分别为1、2、3，假如服务端只收到seq为1的报文，回复的报文ack为2（表示2之前的报文都收到了，请发送seq为2的报文吧）；假如服务端收到seq为1、2的报文...，回复的报文ack为3（表示3之前的报文都收到了，请发送seq为3的报文吧）；假如服务端短时间内都收到了，就只会回复一个ack为4的报文（表示4之前的报文都收到了，请发送seq为4的报文吧）。
源端口和目的端口在TCP层确定双方进程，序列号表示的是报文段数据中的第一个字节号，ACK表示确认号，该确认号的发送方期待接收的下一个序列号，即最后被成功接收的数据字节序列号加1，这个字段只有在ACK位被启用的时候才有效...为什么要“三次握手，四次挥手” 三次握手 换个易于理解的视角来看为什么要3次握手。 客户端和服务端通信前要进行连接，“3次握手”的作用就是双方都能明确自己和对方的收、发能力是正常的。...“三次握手，四次挥手”怎么完成？ 其实3次握手的目的并不只是让通信双方都了解到一个连接正在建立，还在于利用数据包的选项来传输特殊的信息，交换初始序列号ISN。...ACK=L+1 为什么建立连接是三次握手，而关闭连接却是四次挥手呢？ 这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。...查看是否有连接溢出 netstat -s | grep LISTEN 半连接队列满了 在三次握手协议中，服务器维护一个半连接队列，该队列为每个客户端的SYN包开设一个条目(服务端在接收到SYN包的时候，
之后将同步位 SYN 设置为 1，同时选择一个初始序列号 seq=x，这时客户端 A 进入到 SYN-SENT（同步已发送）状态。...在确认报文段中 同步位 SYN=1、确认位 ACK=1、确认号 ack=x+1，同时也为自己选择一个初始序列号 seq=y，这时服务器 B 进入 SYN-RCVID 状态。...Socket TCP 是如何断开连接的 第一次挥手:A 先发送连接释放报文段，段首部的终止控制位 FIN=1，序号seq=u（等于A前面发送数据的最后一个序号加1）；然后 A 进入 FIN-WAIT-1...第二次挥手:B 收到 A 的连接释放报文段后，立刻发出确认报文段，确认号 ack=u+1，序号 seq=v（等于 B 前面发送数据的最后一个序号加1）；然后 B 进入 CLOSE-WAIT（关闭等待）状态...等待 2MSL 原因如下 1.得原来连接的数据包消失 如果B没有收到自己的ACK，会超时重传FiN那么A再次接到重传的FIN，会再次发送ACK 如果B收到自己的ACK，也不会再发任何消息 在最后一次挥手后
简称 seq）中填入一个随机值 J，并将该数据包发送给服务器端，客户端进入 SYN_SENT 状态，等待服务器端确认。...第二次握手：服务器端收到数据包后由请求报文标志位 SYN=1 知道客户端请求建立连接，服务器端将应答报文标志位 SYN 和 ACK 都置为 1，应答报文的 Acknowledgment Number字段...（简称 ack）中填入 ack=J+1，应答报文的 seq 中填入一个随机值 K，并将该数据包发送给客户端以确认连接请求，服务器端进入 SYN_RCVD 状态。...，既然是 syn 包，里面当然会带上 seq 值，本次通信是 1979849485，tcp 报文格式中的 syn 字段被设置为 1，用来表明这是一个 syn 包 第二次握手 数据链路层和 IP 层的报文我们不再查阅...同时 tcp 报文格式中的syn 字段被设置为 1，Acknowledgment 字段被设置为 1，用来表明这是一个 syn/ack 包 第三次握手 客户端收到应答报文后，检查 ack 是否为 J+1，
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
云直播
对象存储
腾讯会议
