☰

源和目标的 IP 端口相同

tag-icon • tag-icon networking hadoop
源和目标的 IP 端口相同

昨天，我在 Hadoop 集群中进行调试时，发现了一些奇怪的事情

# netstat -taupen | grep 54310 tcp 0 0 10.0.12.209:54310 10.0.12.209:54310 TIME_WAIT

您可以注意到源 ip:port 与目标 ip:port 相同。这怎么可能呢？有人能解释一下 TCP 层是如何运作的，才能使此连接正常工作吗？

答案1

建立 TCP 连接的最常见方式是使用三次握手，包括：

  • 同步
  • 同步确认
  • 确认

但这不是建立 TCP 连接的唯一方法。为了建立 TCP 连接，每一方都必须发送 SYN，而另一方必须发送 ACK，但并不要求一方将 SYN 和 ACK 组合在一个数据包中。四次握手同样可行，其中每个端点发送一个 SYN，然后每个端点发送一个 ACK​​。

这种四次握手的一个用例是建立一对位于防火墙后面的主机之间的连接。如果您在受防火墙保护的网络上运行对等应用程序，这将非常有用。每个端点将发送一个 SYN 并重新传输，直到收到响应。这意味着连接两端的防火墙将看到本地端点发出 SYN 数据包，一旦它看到这样的传出数据包，它将允许另一端的 SYN 和 ACK 数据包通过。（虽然这种方法在实践中适用于 TCP 和 UDP，但很少用于 TCP。）

对您的场景而言，所有这些意味着，如果应用程序创建一个 TCP 套接字并将其绑定到本地 IP 地址和端口号，然后尝试连接到相同的 IP 地址和端口号，则 TCP 层将首先生成一个 SYN 数据包，该数据包被传送给自己，然后用 ACK 进行响应，该 ACK 也被传送给自己。

结果是 TCP 套接字可以连接到其自身，并且对于 TCP 层来说，这看起来像是四次握手。

我不知道这种连接到自身的 TCP 套接字是否有任何有用的用途，但是这会产生像您的情况下那样的连接。

答案2

这是可能的，因为有两个进程（可能是来自一个 fork）。左侧是客户端（它调用 bind(2) 来设置其源 IP 和端口，这通常不会发生），右侧是服务器。

这是实现IPC（进程间通信）的一种方法。

相关内容