TCP simultaneous open and self connect prevention

后端 未结 9 822
长情又很酷
长情又很酷 2020-12-08 11:54

TCP standard has \"simultaneous open\" feature.

The implication of the feature, client trying to connect to local port, when the port is from ephemeral range, can o

相关标签:
9条回答
  • 2020-12-08 12:31

    When I stumbled into this I was flabbergasted. I could figure out that the outgoing port number accidentally matches the incoming port number, but not why the TCP handshake (SYN SYN-ACK ACK) would succeed (ask yourself: who is sending the ACK if there is nobody doing a listen() and accept()???)

    Both Linux and FreeBSD show this behavior.

    Anyway, one solution is to stay out of the high range of port numbers for servers.

    I noticed that Darwin side-steps this issue by not allowing the outgoing port to be the same as the destination port. They must have been bitten by this as well...

    An easy way to show this effect is as follows:

    while true
    do
        telnet 127.0.0.1 50000 
    done
    

    And wait for a minute or so and you will be chatting with yourself...

    Trying 127.0.0.1...
    telnet: Unable to connect to remote host: Connection refused
    Trying 127.0.0.1...
    telnet: Unable to connect to remote host: Connection refused
    Trying 127.0.0.1...
    telnet: Unable to connect to remote host: Connection refused
    Trying 127.0.0.1...
    Connected to 127.0.0.1.
    Escape character is '^]'.
    hello?
    hello?
    

    Anyway, it makes good job interview material.

    0 讨论(0)
  • 2020-12-08 12:34

    Bind the client socket to port 0 (system assigns), check the system assigned port, if it matches the local server port you already know the server is down and and can skip connect().

    0 讨论(0)
  • 2020-12-08 12:35

    That's an interesting issue! If you're mostly concerned that your server is running, you could always implement a heartbeat mechanism in the server itself to report status to another process. Or you could write a script to check and see if your server process is running.

    If you're concerned more about the actual connection to the server being available, I'd suggest moving your client to a different machine. This way you can verify that your server at least has some network connectivity.

    0 讨论(0)
提交回复
热议问题