2

TCP 握手中,怎么理解从 LISTEN 转换到 SYN_SENT?

 2 years ago
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.
neoserver,ios ssh client

V2EX  ›  程序员

TCP 握手中,怎么理解从 LISTEN 转换到 SYN_SENT?

  amiwrong123 · 9 小时 28 分钟前 · 337 次点击

正常情况下,是上图这样的。就不会有 LISTEN 转换到 SYN_SENT 。

但是好像也存在从 LISTEN 转换到 SYN_SENT 的。

我简单画了个图,不知道下面这样对不对。( https://www.zhihu.com/question/50200176

但我看到书中有这么一句话,就是说,只有 LISTEN 状态下的套接字才可以接受到 SYN 报文段。

那我就有个疑问了,我理解 客户端那边是不会有 LISTEN 状态的套接字的,那么客户端怎么能接受到 服务器发来的 SYN 报文呢

4 条回复    2021-12-19 01:29:10 +08:00

choury

choury      7 小时 38 分钟前 via Android

给你个关键字 tcp 打洞

TomChaai

TomChaai      6 小时 57 分钟前

因为两边可以理解为不是同一条 TCP 连接,客户端先建立一个 TCP 要求服务器开始个业务,服务器反而转变为客户端,尝试把原来的客户端当作服务器尝试建立另一个连接。
这是应用层的设计导致传输层状态变化的例子,不能简单从传输层理解。

3dwelcome

3dwelcome      6 小时 24 分钟前

那个知乎的 FTP 回答有问题,我去 GITHUB 查了代码,有看到:

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

sisylocke      6 小时 8 分钟前

我不同意这是应用层的设计导致的问题,这些差别就是 TCP 协议的不同实现。

首先你的图客户端和服务端是不是弄反了,一般把被动打开的一方称为服务端,主动的一方称为客户端。

在建立 TCP 连接的时候,客户端和服务端各自都需要初始化一个控制块( TCB ),根据 RFC793 的建议的标准做法,这个连接的初始状态就是 Listen 。但是在具体实现的时候就会发现这一步是多余的。客户端在初始化 TCB 后发送 SYN ,然后状态立即变为 SYNSENT ;服务端接收 SYN 请求,然后初始化一个 TCB 后,状态又立即变为 SYN-RCVD 。所以 Listen 状态是一个很短暂的状态,完全可以一步到位将 TCB 初始化为 SYN 或者 SYNRCVD 状态。

所以在新连接的时候一般不会出现 LISTEN 状态,但是不是说 LISTEN 状态就没用了。当接受到 RST 的时候,并不一定代表对方是关闭连接,所以有的 TCP 实现并不会直接丢弃这个连接,而是重新初始化 TCB 等待重新握手恢复连接,这时的状态就是 LISTEN 。

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK