我是靠谱客的博主 鳗鱼糖豆,最近开发中收集的这篇文章主要介绍TCP的11种时序状态与C/S连接过程对应,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

C/S连接过程对应
TCP的11种时序状态
状态状态的行为/说明
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不在连接状态(这是为方便描述假想的状态,实际不存在)

TIME_WAIT 两个存在的理由(为何要等待2MSL时间):

  • 可靠的实现tcp全双工连接的终止,即防止客户端最后一次发给服务器的确认在网络中丢失以至于客户端关闭,而服务端并未关闭,导致资源的浪费。;
  • 等待最大的2MSL可以让老的重复分节(旧的相同端口号IP地址的连接化身(incarnation))在网络中消逝;如果client直接closed,然后又向server发起了一个新连接,我们不能保证这个新连接和刚关闭的连接的端口号是不同的。假设新连接和已经关闭的老端口号是一样的,如果前一次滞留的某些数据仍然在网络中,这些延迟数据会在新连接建立后到达Server,所以socket就认为那个延迟的数据是属于新连接的,数据包就会发生混淆。所以client要在TIME_WAIT状态等待2倍的MSL,这样保证本次连接的所有数据都从网络中消失。

FIN_WAITTIME_WAIT状态有三种形式:

  • 正常关闭,主动关闭请求端发送FIN后,依次接收到来自被动端传来的ACK(转为FIN_WAIT2)、FIN,并发送ACK给被动端(转为TIME_WAIT);
  • 同时关闭,主动关闭请求段发送FIN时,相对的被动关闭请求端也申请主动关闭(接收到FIN,回复ACK)(转换为CLOSING),再接受一ACK关闭连接(转为TIME_WAIT);
  • 正常关闭,但被动关闭请求端同时发来了ACK确认和FIN请求,则回复ACK即可,直接跨入TIME_WAIT状态;

对于SYN_RCVD状态下的服务器,其若是接收到设置了RST位的分节,则表明连接搁置,返回到LISTEN状态。


最后

以上就是鳗鱼糖豆为你收集整理的TCP的11种时序状态与C/S连接过程对应的全部内容,希望文章能够帮你解决TCP的11种时序状态与C/S连接过程对应所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(59)

评论列表共有 0 条评论

立即
投稿
返回
顶部