11

I do not understand why creating a new TCP connections is considered an expensive task. Basically setting up a new connection refers to performing TCP's 3-way handshake. So that's sending two packets and receiving one. Considering that thousands of (data-)packets will follow, the handshake can't be the expensive part. Can it?

Improve this question
4
  • Maybe due to the CPU and memory usage of connections?
    – joeqwerty
    Aug 16, 2012 at 21:00
  • @joeqwerty I understand that a new TCP connection usually also means creating a new process/thread on e.g. the server, but that's not because of TCP, but due to the application.
    – user132452
    Aug 16, 2012 at 21:09
  • If thousands of data packets follow, the handshaks isn't the expensive part. But why not use a new TCP connection for each data chunk? Because creating a new TCP connection is expensive. That's why you establish one connection and then use it for thousands of chunks of data.
    – David Schwartz
    Aug 16, 2012 at 21:25
  • 1
    Also consider the new connection creation might not be limited to only the TCP handshake. For example SSL adds a lot of negotiation of authentication and encryption details on top.
    – Zoredache
    Aug 16, 2012 at 21:36

4 Answers 4

Reset to default
10

I believe, generally speaking, that opening a TCP connection is considered expensive when compared to the ability to reuse already open connections by keeping it open. You are correct, opening a connecting will take only 3 packets/turns, but that time - 3 x your RTT - is far beyond the cost of reusing an already open connection, which is far closer to 0. The disparity grows even faster if you're opening and closing connections frequently.

You are certainly correct though, when compared to the number of turns you're going to see as the application "does it's thing," those 3 packets can seem pretty small, but again, it depends on how you want to compare the options AND how your application behaves/how many times you plan on opening a connection.

Edit If we're talking UDP vs. TCP though, Cheekaleek here is 100% correct - the overhead of is massive in the long term when compared to the connectionless operations of UDP

Improve this answer
1
  • 2
    A good example I've seen in a packet-trace: A reused MySQL connection can turn queries around in 2-5ms. A series of ElasticSearch queries turns queries around in 17-25ms, most of that time was in connection setup (including initial DNS lookup).
    – sysadmin1138 ♦
    Aug 16, 2012 at 22:26
2

It's certainly more overhead than sending a UDP packet and not caring what happens past that.

TCP also comes with more header data, and maintains the connection state, which will consume resources.

So yes, compared to UDP, TCP is more expensive, but expensive is a relative term.

"TCP connections are a girl's best friend???"

Improve this answer
1
  • 5
    "TCP connections are a girl's best friend???" No, they're not. I got a girl thousands of those for her birthday and all she did was stop returning my emails. :(
    – HopelessN00b
    Aug 16, 2012 at 21:48
2

It's not just sending and receiving packets. Additional memory has to be allocated and at a minimum networking state tables updated at each step until the session is established. Not to mention any additional security checks that may be performed (route spoof protection, etc).

Just using some example numbers (because we're not talking about any specific operating system) if a packet for an established session has a CPU cost of 1 unit, the cost of a new session may be 10x or 100x that cost in the number of operations performed. Most hardware firewalls that I've worked with can handle an order of magnitude fewer new connections per second than they can handle established sessions.

It's often not that big a deal, especially since a SYN-SYN/ACK-ACK happens in milliseconds, but for large systems with many customers new sessions can turn into a significant overhead.

Improve this answer
2

The amount- or type- of traffic matters a lot less than the code associated with actually allocating memory and the associated tracking of state information. If you want to get a very rough sense of what this implies take a look at the amount of code in the Linux kernel associated with TCP vs that associated with UDP or ICMP. An incredibly rough comparison shows TCP requiring something like 10x the number of lines of code found in UDP.

In IP networking the amount of state maintenance required is one of the most important determinants of scalability. For TCP endpoints this is expressed not just in SYN/ACK but also in ongoing maintenance of sliding windows, sequence numbers, buffer management and QoS actions, etc. Check out the complexity of the FSM for tcp and consider the inherent lack of same in UDP...

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.