中小企业网站制作多少钱,app立即打开,浦东新区手机网站设计,photoshop手机版免费TCP的三次握手和四次挥手实质就是TCP通信的连接和断开。 三次握手#xff1a;为了对每次发送的数据量进行跟踪与协商#xff0c;确保数据段的发送和接收同步#xff0c;根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系#xff0c;并建立虚连接。 四次挥手为了对每次发送的数据量进行跟踪与协商确保数据段的发送和接收同步根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系并建立虚连接。 四次挥手即终止TCP连接就是指断开一个TCP连接时需要客户端和服务端总共发送4个包以确认连接的断开。 首先要明白握手的目的是什么 可以将TCP双向通信的过程看成两个单向通信过程的组合 一次 “请求连接——确认”操作可以确保一方做好了发送准备另一方做好了接收准备因此可以建议一个单向的连接 一次 “请求关闭——确认”操作可以确保一方发完了数据希望关闭发送另一方收到请求关闭接收最后关闭掉一个单向的连接。
在建立连接时是为了判断双方是否能够正常建立连接即客户端—服务端、服务端-客户端两个单向的收发都是正常的。
而在关闭连接时是为了判断双方是否应该关闭连接即客户端—服务端、服务端-客户端两个单向的收发是否应该关闭。
在握手过程中每一端自己当然清楚自己这边的状态关键是从过程中判断对方的状态。
一、建立TCP连接三次握手协议 客户端我要对你讲话你能听到吗 服务端我能听到而且我也要对你讲话你能听到吗 客户端我也能听到。 ……. 互相开始通话
过程分析
第一步客户端向服务端发送请求服务端收到了客户端请求因此服务端可以判断 客户端—服务端单向收发正常。
第二步服务端向客户端发送确认客户端收到了确认因此客户端可以判断服务端正常收到了自己刚才的请求所以 客户端—服务端单向收发正常、服务端—客户端单向收发正常。于是客户端为连接分配相关资源开始监听端口。
第三步客户端针对刚才收到的包发送确认服务端收到了这个确认包因此服务端可以判断 客户端—服务端单向收发正常、服务端—客户端单向收发正常 于是服务端未连接分配相关资源开始监听端口。
为何要分三步握手而不能是两步握手 其实在理想的网络环境下只需要两次握手就行了在上面第二步之后客户端已经知道两个方向收到都是正常的了它的确可以发送数据了。
但问题在于网络环境并不总是理想的在第一步客户端发送请求的过程有可能出现发送后迟迟收不到确认包而重发请求如果之前已经过时的这个请求包真得彻底消散在网络传输中倒也罢了但有时候它只是因为网络延迟到达服务端比较晚过了一阵子时间后可能又到达服务端了。如果这个旧的请求包到达的时间是在正常请求包到达之前或者是在整个连接关闭之后才到达那么服务端是无法判断这是过时请求的服务端会正常发送确认需要客户端来验明其过期的身份然后告知服务端。
那么如果是两次握手的话一旦出现这种情况服务端在第一步就会为连接分配资源开始监听端口。但这是个过时的无效请求客户端会抛弃掉不会做对应的连接处理也不会去发送数据。服务端会一直耗费资源傻等着。
如果是三次连接的话多了客户端验证这一步服务端能判断出这是一个无效请求因此不会去做对应的资源分配。SYN:该字段被设置为1即true表示请求建立连接 FIN该字段被设置为1即true表示请求关闭连接 seq:该字段为请求序列号譬如为seqx, 能够标示一个请求包在众多包种区分其身份 ack:该字段为确认字段譬如ackx1表示已经收到对方发来的seqx的请求包。 客户端通过ack可以判断当前确认包是针对哪个请求包在做确认。
二关闭TCP连接四次握手协议 客户端我说完了我要闭嘴了 服务端我收到请求我要闭耳朵了 客户端收到这个确认于是安心地闭嘴了。 ……. 服务端还没倾诉完自己的故事于是继续唠唠叨叨向客户端说了半天直到说完为止 ……. 服务端我说完了我也要闭嘴了 客户端我收到请求我要闭耳朵了事实上客户端为了保证这个确认包成功送达等待了两个最大报文生命周期后才闭上耳朵。 服务端收到这个确认于是安心地闭嘴了。 发送方之所以要收到确认后才关闭发送是怕接收方没收到自己的请求避免自己关闭了发送而接收方还一直傻等着去接收。 客户端收到请求包后为什么要等待两个最大报文生命周期后才闭上耳朵呢 为了以防万一因为最后一个发往服务端B的确认包有可能丢失等待两个最大报文生命周期是为了尽可能保障服务端能够收到一次确认包避免服务单始终处在等待关闭发送的状态。 分析 一个“最大报文时长”是TCP数据包在网络中存在的最长时间超过这个时间报文会被丢弃掉。 客户端每次在收到服务端的“关闭请求”后开始计时服务端一旦超时收不到客户端的确认包就会重发请求而TCP协议中的确认超时时长应该不会超过“最大报文周期”而重发的网络请求的传输时间也不超过“最大报文周期”这样正常情况下重发的请求在两个“最大报文周期”内应该能够到达客户端客户端每次在收到服务端的“关闭请求”后又会重新开始计时两个“最大报文周期”又会重复前面的过程。 这样可以很大限度上保障服务端能收到一次确认包。当然会有收不到的情况所以应该会有别的超时机制来兜底。
