网络编程经验：意料之外的自连接

   这是一个花了我三个小时时间才解决的bug。

   bug是这样发生的：我写了一个服务器，负责从VDE上接受数据，进行fast压缩之后再推送给其他人写的服务。其他的人写的服务不停都尝试重新连接我的监听端口。因为我的服务在每一天晚上是停止对外服务的，只在VDE有了数据之后才对外服务。发送股票的市场状态。某一天早上，我起程序的时候，发现接收到了一个abort的signal。

   于是我尝试跟踪它，跟踪的过程很崩溃，反正用printf大法，我看到崩溃的位置。很普通的语句，就是给一个套接字绑定监听的ip和端口的地方。

    okay，端口已经被其他进程占用了。

    从这里可以看到：

    $ss -a|grep 33233 ESTAB 0 0 10.10.0.22:33233 10.10.0.22:33233

    这就是一个典型的自连接。

    因为意料之外的自连接的存在，导致原本的服务端口被占用。

    内核的参数net.ipv4.ip_local_port_range决定了本地使用的端口范围。而一个晚上的Reconnect导致，产生了一个自连接。

    这个问题，曾经在linux kernel maillist中大家关注过，参见

    Re: tcp/ip bug (2.2.12) or telnet client bug Craig Milo Rogers (rogers@ISI.EDU) Mon, 27 Sep 1999 13:21:44 -0700 Messages sorted by: [ date ][ thread ][ subject ][ author ] Next message: Jordan Mendelson: "The Linux Kernel Project Management System (INITIAL PROPOSAL)" Previous message: Zygo Blaxell: "ide-cd vs sr0 and ide-scsi" Maybe in reply to: Vedad Kajtaz: "tcp/ip bug (2.2.12) or telnet client bug" Next in thread: sergey@memco.com: "Re: tcp/ip bug (2.2.12) or telnet client bug" -------------------------------------------------------------------------------- >> > Confirmed that version 2.3.13 has that bug also. > >Its not a bug > >> so do ./stest 1316 and it connects... >> this is not meant to happen as far as I know ... > >RTFRFC > >yes it is supposed to happen. Here is my position on this problem. I welcome discussion, although we should take it offline, I think. Statement of Problem ========= == ======= When the application opens a TCP connection without specifying a local port number, the system will sometimes assign the same local port number as the foreign port number in the connection, creating an open, looped connection if the local and foreign IP adresses are the same. The application programmer expected the connection to fail, as the specified "foreign" port did not exist prior to the attempt to open the "local" port and connection. Note that the question isn't, "Should explicitly requested TCP self-connections be allowed?". Rather, it is, "Should unintentional TCP self-connects be prevented?" References ========== The two current RFCs governing TCP behavior in this area are: RFC793 Transmission Control Protocol RFC1122 Requirements for Internet hosts - communication layers Analysis ======== The closest thing to a statement about allocating ports in general is in RFC 793 section 2.7: TCPs are free to associate ports with processes however they choose. In this sense, the present Linux TCP behavour is allowed by the RFC. :-) On the other hand, the Robustness Principle (RFC 1122 section 1.2.2) should also be taken into consideration; although it is described in terms of packet processing, it can be applied in other areas. RFC 1122 section 4.2.2.1 divdes the port space into the well-known ports, the reserved port range of some implementations, and the remainder of the port space. I don't see any particularly pertinent constraints here. RFC 793 section 3.8 discusses the minimum required functional interface btween the "user" (the application program) and the system-level TCP implmentation. The key point here is that, in all of the connection opening interfaces illustrated in the RFC, the local port number is allocated by the application program rather than by the system-level TCP code. RFC 1122 continues the use of the "application allocates the port" model. So, is the self-connect behavior supposed to happen, according to the RFCs? I could answer, "No, it is not supposed to happen", on the grounds that the RFCs do not illustrate the system-level TCP implementation allocating the local port in the first place. That would be misstating the intent of the RFCs, though: additional functionality is permitted in the TCP API, so long as the minimum functionality is provided. In conclusion, the current RFCs do not address the issue of whether opening a TCP connection using an system-assigned local port should be allowed to create a self-connection. Personal Experience ======== ========== Given that the RFCs are silent on the issue of preventing unintentional self-connects that may occur through system-level local port assignment, one can ask more subjective questions, such as, "what id the TCP designers intend?" or "what is common practice?". I offer the following personal experience: In the early 1980's, the BBN Tenex/TOPS-20 TCP/IP implementation was considered the reference standard. My memories are vague, and I don't have sources handy anymore, but I believe it had the feature of allowing the system to assign the local port number in a connection opening request. I believe that, when reading the BBN TCP sources, I came across a line of code that refused to dynamically generate a local port number that matched the foreign port number in the request. I discussed this line with jon, and he said that the intent was to prevent unintentional self-connects. Conclusions =========== The RFCs do not address the issue of whether unintentional self-connects should or should not be allowed; the RFCs do not address the particular application API details that cause the existance of the problem. The Robustness Principle, and personal experience, lead me to believe that unintentional self-connects should be prevented, as prevention is cheap and does not change any of the explicitly required system functionality. Of course, I think that the Robustness Principle also implies that a port scanning program should explicitly allocate a fixed local port before performing this sort of activity. Craig Milo Rogers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ -------------------------------------------------------------------------------- Next message: Jordan Mendelson: "The Linux Kernel Project Management System (INITIAL PROPOSAL)" Previous message: Zygo Blaxell: "ide-cd vs sr0 and ide-scsi" Maybe in reply to: Vedad Kajtaz: "tcp/ip bug (2.2.12) or telnet client bug" Next in thread: sergey@memco.com: "Re: tcp/ip bug (2.2.12) or telnet client bug"

    这个行为是合法的。

    出现的概率可能很低，也可能很高。

    根据三次握手：

   

 

• 总结： 上面的邮件列表提到了自连接很可能是一个合法，但是出乎程序员意料之外的连接。因为在没有监听套接字的前提下，产生了local和peer完全一样的连接。本文我提到了，我的服务正好需要绑定这个端口。所以对我来说是一个意料之外的情况。我觉得解决这个问题最简单的方法是在断线自动重连的逻辑上加上几句代码，判断是否local和peer的端口是否一样，一样就重新连接。