TCP 握手中,怎么理解从 LISTEN 转换到 SYN_SENT?
source link: https://www.v2ex.com/t/823043
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
正常情况下,是上图这样的。就不会有 LISTEN 转换到 SYN_SENT 。
但是好像也存在从 LISTEN 转换到 SYN_SENT 的。
我简单画了个图,不知道下面这样对不对。( https://www.zhihu.com/question/50200176 )
但我看到书中有这么一句话,就是说,只有 LISTEN 状态下的套接字才可以接受到 SYN 报文段。
那我就有个疑问了,我理解 客户端那边是不会有 LISTEN 状态的套接字的,那么客户端怎么能接受到 服务器发来的 SYN 报文呢
choury 7 小时 38 分钟前 via Android
TomChaai 6 小时 57 分钟前
这是应用层的设计导致传输层状态变化的例子,不能简单从传输层理解。
3dwelcome 6 小时 24 分钟前
Serv-U FTP Server v6.3
on PORT command, the client listen on a port and wait the server to connect.
on PASV command, the server listen on a port and wait the client to connect.
说明在 FTP 里,服务器去反向连接客户端,并不是 listen socket 的内置状态切换,而是就是普通的客户端 listen 监听,服务端 connect 连接罢了。
可能早期 TCP/IP 协议里有设计 LISTEN 转换到 SYN_SENT ,随着时间推移,已经被淘汰了。
我甚至都不知道转换代码要怎么写,也没从看到过案例。
sisylocke 6 小时 8 分钟前
首先你的图客户端和服务端是不是弄反了,一般把被动打开的一方称为服务端,主动的一方称为客户端。
在建立 TCP 连接的时候,客户端和服务端各自都需要初始化一个控制块( TCB ),根据 RFC793 的建议的标准做法,这个连接的初始状态就是 Listen 。但是在具体实现的时候就会发现这一步是多余的。客户端在初始化 TCB 后发送 SYN ,然后状态立即变为 SYNSENT ;服务端接收 SYN 请求,然后初始化一个 TCB 后,状态又立即变为 SYN-RCVD 。所以 Listen 状态是一个很短暂的状态,完全可以一步到位将 TCB 初始化为 SYN 或者 SYNRCVD 状态。
所以在新连接的时候一般不会出现 LISTEN 状态,但是不是说 LISTEN 状态就没用了。当接受到 RST 的时候,并不一定代表对方是关闭连接,所以有的 TCP 实现并不会直接丢弃这个连接,而是重新初始化 TCB 等待重新握手恢复连接,这时的状态就是 LISTEN 。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK