number of simultaneous tcp/ip connections on 32 bit linux

Discussion in 'Linux Networking' started by g918273l, Jul 27, 2015.

  1. g918273l

    g918273l Guest

    Hi All,

    I have a specific question on implementing a load balancer or a TCP/IP server program that does TCP/IP.

    Since port number is 16 bits, there are a max of only 65536 ports on a single Linux box at any given time.
    And TCP/IP needs a port number to talk to the outside world.
    1) when a client establishes a connection, an ephemeral port number is chosen.
    2) when a server listening on a socket accepts a connection, a port number is assigned.

    So in my understanding at any given time only maximum 65536 TCP/IP connections can exist on a given machine.

    So how is it that some or most load balancers claim 200,000 or more concurrent connections?

    Can someone please explain that?

    Also regarding load balancers, once a load balancer has forwarded a requestto one of the servers behind it, can the load balancer somehow pass some information to it, that will help the server to respond back to the originating client directly to avoid the latency of sending back the response via the load balancer?

    Thanks everyone for your help.
    Gargi
     
    g918273l, Jul 27, 2015
    #1
    1. Advertisements

  2. A TCP connection is identified by the source address, source port,
    destination address and destination port. Lots more than 65536
    possibilities.
     
    Richard Kettlewell, Jul 27, 2015
    #2
    1. Advertisements

  3. g918273l

    Bob Martin Guest

    True, but it doesn't answer the OP's question.
     
    Bob Martin, Jul 28, 2015
    #3
  4. Certainly it does... The port number only specifies the
    specific server program that will respond to requests on
    a given machine. There might be many thousands of
    connections to that one program, on that one port.

    Consider for example that port 80 is normally assigned
    to the HTTP server, and there are commonly hundreds or
    thousands of browsers connected to many of the busier
    web servers.

    In addition to just that one port, the same machine
    might also have server programs listening to dozens of
    other ports at the same time. There might be thousands
    of TCP/IP connections to each of several different ports.
    FTP, HTTP, HTTPS, SMTP, SSH, NTTP, POP3, and many
    others.

    The 16 bit size of the port number only limits the
    number of services, handled by that many different
    server programs.
     
    Floyd L. Davidson, Jul 28, 2015
    #4
  5. It doesn’t even limit that. Maximum number of listeners = numbers of
    possible ports multiplied by number of local addresses. Now it’s
    certainly true that a common configuration is only one local address (or
    two if you have IPv6) (other than loopback) and for listeners to bind to
    all local addresses, but it’s not the only possibility.
     
    Richard Kettlewell, Jul 28, 2015
    #5
  6. g918273l

    Jorgen Grahn Guest

    Nitpick: it helps if you write "TCP" when you mean TCP. "TCP/IP" was
    a term you saw a lot in the 1990s, but I never understood what it
    meant ... possibly it was simply used when "IP" didn't look impressive
    enough.

    /Jorgen
     
    Jorgen Grahn, Jul 28, 2015
    #6
  7. g918273l

    Denis Corbin Guest

    TCP/IP means TCP over IP ... (TCP = layer 4 of OSI model, IP is at
    layer 3)... OK now, I have not seen TCP over anything else than IP ...
    OSI, IPX, or DECnet stacks do not implement TCP at layer 4 to my
    knowledge... right?
     
    Denis Corbin, Jul 28, 2015
    #7
  8. g918273l

    Lew Pitcher Guest

    Then, you haven't looked at VPN technologies.

    It is possible (and common) for a VPN to interpose additional protocols
    between TCP and the (normal) carrier protocol. So, you /can/ find TCP over
    UDP over IP (for instance).
     
    Lew Pitcher, Jul 28, 2015
    #8
  9. g918273l

    Denis Corbin Guest

    Le 28/07/2015 18:51, Lew Pitcher a écrit :
    yes, but these are still part of the IP stack... so it's still "TCP over
    IP".
    .... yes TCP ... over IP. :)
     
    Denis Corbin, Jul 28, 2015
    #9
  10. g918273l

    Lew Pitcher Guest


    OK then, how about RFC 1791: TCP and UDP over IPX
    (https://tools.ietf.org/html/rfc1791) ?

    TCP is TCP; it corresponds (loosly) to an OSI level 4 protocol (loosly,
    because the internetworking protocols were not developed to the OSI model).

    It matters not to TCP whether it is carried by IP, IPX, DECNET (or any other
    OSI level 3 "network layer" protocol), or encapsulated in UDP packets (or any
    other OSI level 4 protocol), or even by Avian carrier.

    So, TCP can refer to *any number* of TCP/network_layer combinations, *one* of
    which is TCP/IP.


    [snip]
     
    Lew Pitcher, Jul 28, 2015
    #10
  11. g918273l

    Denis Corbin Guest

    Interesting!

    A funny thing in this RFC is the use of "TCP/IP" as discussed previously
    in this thread. For example in the introduction you can read:

    "to let TCP/IP applications run over IPX, we would need to have TCP and
    UDP run over IPX"

    Obviously here "TCP/IP applications" stands for "TCP and/or UDP based
    applications"... which makes this sentence a Lapalissade... else such
    applications would need IP protocol and could not be used over IPX by
    simply putting TCP over IPX nor UDP over IPXF over IPX as described in
    this RFC.

    I was not aware it was common in the last century to use "TCP/IP" for
    designing either TCP or probably rather the IP stack as a whole.

    Thanks for this reference.
     
    Denis Corbin, Jul 29, 2015
    #11
  12. Hi Gargi,

    No. As pointed out elsewhere, only 65536 different services may be
    differentiated. A TCP connection is identified by source-IP, source-port
    (choosen "randomly" by client, different for multiple connections to
    same server port), server-IP, desintation-port.
    A service, e.g. running on port 80, is able to receive many, many
    connections on the same port.
    I'm not aware of a way to achieve this on network level, because even if
    you use DNAT, the packets still need to go back via load balancer since
    it needs to re-write the sender address of the server's response.

    There might be application level solutions (like redirecting from
    www.yourdomein.com to www1...www4.yourdomain.com). On network level you
    somehow need to keep the client's "illusion" that it's talking to one
    server.

    I'm no load balancing expert though and happy to learn something new.
    :)

    Jamma.
     
    Jamma Tino Schwarze, Aug 6, 2015
    #12
  13. g918273l

    JT Guest

    On 06/08/15 12:12, Jamma Tino Schwarze wrote:
    Nothing to do with load balancing, but I'm puzzled about the numbers
    flying around.

    65536? Minus 1023 that is. 0 won't be a valid portnumber. And ports
    1-1024 won't be advised (I hope); these are reserved for root-usage.

    So that leaves 64512. Or thereabout.

    But that number should (or am I wrong) be multiplied by the number of
    network interfaces your machine has. Eacht network interface has it's
    own IP number, or?

    Just my 2p. And forgive me if I'm off-topic.
     
    JT, Aug 6, 2015
    #13
  14. g918273l

    Rick Jones Guest

    You don't necessarily need to have multiple network interfaces - one
    can have multiple IPs per network interface. And depending on whether
    one's system/stack adheres to the strong versus weak end system model
    the IP addresses are either a property of the interface or of the
    system as a whole.

    rick
     
    Rick Jones, Aug 6, 2015
    #14
  15. Let me take a crack at it. A program running on a given machine and
    listening on a particular port number can accept any number of connections
    on that port number - even if they all come from the same machine.
    For example, imagine your server is at 10.0.0.1 and is listening on
    port 1234. A machine at 10.0.0.2 can open a connection to your server;
    it'll probably be assigned a random port number (e.g. 24576). The four
    items that uniquely identify the connection are as follows:

    Server IP address Server port Client IP address Client port
    ----------------- ----------- ----------------- -----------
    10.0.0.1 1234 10.0.0.2 24576

    If another client, at IP address 10.0.0.3, connects, the list of
    connections might look like this:

    10.0.0.1 1234 10.0.0.2 24576
    10.0.0.1 1234 10.0.0.3 31400

    Now suppose the first client opens another connection to the
    server. It'll grab another random port number, and the list
    might now look like this:

    10.0.0.1 1234 10.0.0.2 24576
    10.0.0.1 1234 10.0.0.3 31400
    10.0.0.1 1234 10.0.0.2 25212

    Because each line of the list differs in some form, everything
    is OK. Note that you could even run this experiment entirely
    on one machine; in the list above all IP addresses would be
    replaced with 10.0.0.1. Note also that this works even if
    each machine has only one network interface.

    Been there, done that, wrote the source code.
     
    Charlie Gibbs, Aug 6, 2015
    #15
  16. On TCP/UDP-level nobody cares about that Unix tradition of reserving 1-1024
    to root processes. These are valid port numbers and may be used.

    One IP = up to 65535 different TCP ports. Period. Another 65535 for UDP
    and maybe different IP protocols which use some kind of port number.
    Slightly. ;-) The original question whas about number of simulateneous
    tcp/ip connections. Which is a completely different issue.

    Another perspective: Given one IP (=server) running exactly one service,
    one particular client cannot open more than 65535 connections to that
    service - in theory! In practice, probably a lot less because not all
    source port numbers will be available for use. It's not a problem on
    server side, but client side this time.

    If that one server runs a second service on a different port, the same
    client might be able to establish another 65535 connections. In theory!
    I'm not sure whether common operating systems will allocate the same
    source port for different destinations. Maybe, maybe not.

    But that's all theory and my (non-TCP/IP expert) half-knowledge. ;-)

    Jamma.
     
    Jamma Tino Schwarze, Aug 26, 2015
    #16
  17. The client could use more than one IP address (although client software
    is not usually smart enough to exploit this).
     
    Richard Kettlewell, Aug 26, 2015
    #17
  18. You are granted today's nitpicking award! :)

    Of course, you are right - if there were multiple suitable IP addressses
    available to the client.

    Jamma.
     
    Jamma Tino Schwarze, Aug 27, 2015
    #18
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.