首页 > 其他分享 >1.8TCP的3次握手和4次挥手

1.8TCP的3次握手和4次挥手

时间:2024-07-21 21:26:11浏览次数:13  
标签:ACK 握手 1.8 SYN TCP 链接 服务器 报文 客户端

1.8TCP的3次握手4次挥手
TCP协议非常重要,这里把它的连接和释放整理一下。
首先是三次握手:
1、 客户端发起,像服务器发送的报文SYN=1,ACK=0,然后选择了一个初始序号:seq=x。
SYN是干什么用的?
在链接的时候创建一个同步序号,当SYN=1同时ACK=0的时候,表明这是一个连接请求的报文段。如果对方有意链接,返回的报文里面SYN=1,ACK=1,。从这个意义上来说,SYN=1的时候,就表明这是一个‘请求’或者‘接受请求’的报文。
SYN=1的报文段不能携带数据。但是要消耗掉一个序号,
ACK是干什么用的?
仅当ACK=1的时候,确认字号(期望收到对方下一个报文段的第一个数据字节的编号)才有效。因此,TCP规定,当链接建立之后,所有往来的报文里面的ACK都应该是1(事实上,也只有客户端发起的链接请求报文的ACK没有置1)。
现在的状态:客户端进入SYN-SEND状态;
2、 服务器接收到了SYN=1,ACK=0的请求报文之后,返回一个SYN=1,ACK=1的确认报文。
同时,确认号ack=x+1,同时也为自己选择一个初始序号seq=y
现在的状态:服务器进入SYN-REVD状态;
3、 客户端接收到了服务器的返回信息之后,还要给服务器返回最后一条确认,ACK=1,确认号ack=y+1;
现在的状态:客户端进入ESTABLISHED状态。
下面说一下为什么两次握手不行,非得三次:
首先说明一种正常的情况,就是客户端发送了一条请求链接的报文,但是由于网络原因丢失了,所以,不可能接收到服务器端的确认。这个时候,客户端就就只有再一次发送原来的请求报文,这次服务器收到之后返回确认,客户端再确认一次,链接确立。
然后考虑一种不正常的情况,客户端发了两次请求链接的报文,第二条被服务器捕捉到,返回数据,完成了两次握手。数据传送完成之后,链接关闭。但是这时候,第一条拥塞的请求报文现在到达了服务器端,服务器还以为客户端要又一次建立连接,于是发送确认,然后把自己敞开,等着客户端发送过来数据。于是,很多的网络资源就是这样浪费掉了。
要是实行三次握手,服务器收到了一条过期的请求报文,返回确认信息,客户端接收到了服务器的信息之后感到莫名其妙,心想:我他妈又没要链接,你返回这个是不是疯了。于是不置一词。服务器过一段时间还没有收到第三次握手的数据,知道客户端并没有要求建立链接的请求,含泪离开。
然后是四次分手:
现在双方的状态都是ESTABLISHED状态。
1、 客户端发起请求,请求断开链接。FIN=1,seq=u。u是之前传送过来的最后一个字节的序号+1。
FIN:用来释放一个链接,当FIN=1的时候,表明此报文的发送方已经完成了数据的发送,没有新的数据要传送,并要求释放链接。
客户端进入FIN-WAIT-1状态,等着服务器返回确认;
2、 服务器收到客户端的请求断开链接的报文之后,返回确认信息。ACK=1,seq=v,ack=u+1。
服务器进入CLOSE-WAIT状态。
这个时候,客户端不能给服务器发送信息报文,只能接收。但是服务器要是还有信息要传给服务器,仍然能传送。
3、 当服务器也没有了可以传的信息之后,给客户端发送请求结束的报文。FIN=1,ACK=1,
ack=u+1,seq=w。
这个时候的状态:服务器进入LAST-ACK状态。
4、 客户端接收到FIN=1的报文之后,返回确认报文,ACK=1,seq=u+1,ack=w+1。
发送完毕之后,客户端进入等待状态,等待两个时间周期。关闭。
为什么最后还要等待两个时间周期呢?
1、 客户端的最后一个ACK报文在传输的时候丢失,服务器并没有接收到这个报文。这个候。
服务器就会超时重传这个FIN消息,然后客户端就会重新返回最后一个ACK报文,等待两个时间周期,完成关闭。如果不等待这两个时间周期,服务器重传的那条消息就不会收到。服务器就因为接收不到客户端的信息而无法正常关闭。
2、 预防上一次在三次握手中提到的失效的报文干扰。两个时间周期过去之后,所有的报文都会在网络中消失,保证下一次重新连接的时候有乱七八糟的报文影响。

标签:ACK,握手,1.8,SYN,TCP,链接,服务器,报文,客户端
From: https://blog.csdn.net/weixin_44770477/article/details/140590917

相关文章

  • 从输入URL到页面展示到底发生了什么?--02 握手的故事:三次握手详解
    在这个数字化时代,网络通讯就像人类之间的交流,需要一种方式来确保彼此能够顺利对话。在计算机网络中,TCP三次握手就是这样一种确保双方通信顺畅的机制。今天,我们将通过一个生动有趣的故事来讲解这个重要的过程。引子:约会前的准备想象一下,你要和朋友约个饭,但由于时间久了彼此不太确......
  • 为什么必须使用三次握手?
    TCP(传输控制协议)的三次握手是建立可靠连接的关键步骤,其设计目的是确保通信双方都准备好,并且避免重复的连接初始化。三次握手并不是随意设定的,而是有其重要的技术理由。1.防止重复的连接初始化假设只使用两次握手,会存在以下问题:旧的重复SYN包问题:如果网络中的一个旧的SYN包(因......
  • TCP协议
    TCP协议-----传输控制协议        一种面向连接的可靠传输协议。        TCP协议建立的连接是双向连接。面向连接:在数据传输之前,收发双方需要预先建立一条逻辑通路。无面向连接。TCP分段:因为IP分片后,TCP协议无法保证数据的......
  • TCP协议详解
    TCP协议是一种传输控制协议,一种面向连接的可靠传输协议。TCP协议建立的链接是双向连接。双向连接:在数据传输之前,收发双方需要预先建立一条逻辑通路。无面向连接。序列号SN确认序列号AN6位标志位(URG、ACK、PSH、RST、SYN、FIN)URG---告诉对方有紧急数据......
  • dpvs 调整tcp mss
    修改tcpoptions中mss值src/ipvs/ip_vs_proto_tcp.c因为tcp头部options中不同kind顺序是随机的,所以需要遍历找到kind值是mss2和length值是4,再修改后面的mssvalue。staticvoidtcp_out_adjust_mss(intaf,structtcphdr*tcph){unsignedchar*ptr;intlength;......
  • STM32被拔网线 LWIP的TCP无法重连解决方案
    目录一、问题描述二、项目构成三、问题解决1.问题代码2.解决思路3.核心代码: 四、完整代码1.监测网口插入拔出任务2.TCP任务3.创建tcp任务4.删除tcp任务五、总结一、问题描述最近遇到一个问题,就是我的stm32设备作为tcp客户端和上位机交互,如果在连接过程中网线......
  • keepalived绑定单播地址、非抢占模式及LVS的TCP模式的高可用【转】
    背景:keepalived默认是组播地址进行播放,且默认地址是224.0.0.18,如果配置多个keepalived主机,会导致虚拟IP地址存在冲突问题,这种问题怎么解决呢?解决办法:就是将keepalived主机的多播地址修改为单播地址,绑定固定IP地址,避免在多播模式下,通过VRRP进行广播地址,造成IP地址地址冲突。vrrp_......
  • 解决Could not find artifact jdk.tools:jdk.tools:jar:1.8 at specified
    报错详细信息Failedtoexecutegoalorg.apache.maven.plugins:maven-dependency-plugin:3.1.1:tree(default-cli)onprojectspringbootbd-product:Cannotbuildprojectdependencygraph:Couldnotresolvenorcollectfollowingdependencies:[jdk.tools:jdk.tools:ja......
  • socket 收发TCP/UDP
    一、c++个人测试记录,有问题还请指出,谢谢参考:C++开发基础之网络编程WinSock库使用详解TCP/UDPSocket开发_c++udp使用什么库-CSDN博客代码中Logger测试见文章: c++中spdlog的使用/python中logger的使用-CSDN博客1、main.cpp收发TCP信号:#include<iostream>#include<thr......
  • TCP/IP协议,以及对等网络通信原理!
    TCP/IP模型协议分层应用层:HTTP:超文本传输协议(网站访问WEB)(Apache、nginx)(IIS)FTP:文件传输协议(网络文件传输)TFTP:简单文件传输协议(交换机和路由器重装)SMTP:简单邮件传输协议(发信)POP3:邮局协议3代(收信)SNMP:简单网络管理协议(服务器监控)DNS:域名系统(域名与IP解析)传输层:TCP:传......