重新思考TCP三次握手,两次握手的缺点

两次握手也能保证有序可达

  两次握手在CS架构中是能保证有序、可达的,因为客户端在收到服务器的确认后,客户端知道服务器知晓了自己的下一个序号,客户端到服务器

的单向连接就建立了,只是服务器此时不能再发送消息,因为服务器不知道客户端有没有收到自己消息,客户端如果没收到,服务器发送下一序号

信息将不能保证服务器信息有序到达,除非客户端重传了连接请求或者发送了下一个序号的消息。服务器收到客户端第二次消息后,服务器知道客户

端知晓自己的下一个序号,服务器到客户端的连接也就建立了。

 

两次握手会有什么问题

  教科书给的答案是过时的连接请求发送到服务端会一直等待直到超时,以产生资源浪费,那服务端不等不行吗,下面分析一下。

  若两次握手,当客户端发送的SYN1在链路阻塞后,客户端重传SYN2,在与服务器交互完SYN2的需求并断开连接后,服务器收到SYN1的报文,

服务器将发送确认报文,之后当然不会有任何客户端报文再发来,服务器需要考虑几种情况:

  1. 客户端已退出,将不会收到确认报文(此时真实情况)
  2. 客户端暂时没有请求数据,只是建立连接

服务器将对这几种情况一视同仁,进行超时重传,直到到达最大时间限制,客户端没有发送消息,服务器关闭此次连接。这里的关键在于超时时

间的设置,服务器不知道此时情况,超时时间的设置将是相同的。

实际上,只有情况2需要长连接,如果服务器只考虑2,来一个连接请求就等待几小时,那么对于情况1服务器将无谓的等待。

  如果服务器想知道是否是情况1,怎么做?这需要客户端返回一个对服务器响应的响应,如果服务器短时间没收到响应,那么可能是1,那阻塞情况

又怎么区分呢,没错,重传多次,如果还是没有响应,那就一律按1处理(这条件,上炕都费劲还指望我给你服务呢),服务器将进入Closed状态。服务器

知道具体情况前是一视同仁的,对于情况2,服务器也将需要客户端发送响应,有响应消息,确认是情况2后,服务器可以安详等待了,直到超时再做相

应工作。

  我超,这不就是三次握手吗!!

 

posted @   h20  阅读(623)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· Manus的开源复刻OpenManus初探
· AI 智能体引爆开源社区「GitHub 热点速览」
· 三行代码完成国际化适配,妙~啊~
· .NET Core 中如何实现缓存的预热?
点击右上角即可分享
微信分享提示