Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
Maybe due to the CPU and memory usage of connections? –  joeqwerty Aug 16 '12 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. –  Jakob Buchgraber Aug 16 '12 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 '12 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 '12 at 21:36
add comment

4 Answers

up vote 8 down vote accepted

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

share|improve this answer
1  
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 '12 at 22:26
add comment

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???"

share|improve this answer
1  
"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 '12 at 21:48
add comment

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.

share|improve this answer
add comment

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...

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.