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

according to: http://upload.wikimedia.org/wikipedia/commons/thumb/9/98/Tcp-handshake.svg/250px-Tcp-handshake.svg.png

1.) There is a 3 way TCP Establishment Handshake. Given I have a Ping-Time of 100 Millisecons, can I use the Ping-Time to calculate (in average) how long it will take to establish a TCP Connection?

2.) Given I have a Ping Time of 100 Millisecons, is it correct that it will require at least 150 Milliseconds? Or will it be 100 Milliseconds + one Microsecond (the microsecond is for sending the third ACK)? OR can the ACK even already contain data?

3.) What I do not understand is ( in the grafic above) when the Client know that his third ACK succeeded and he can now start sending regular data. I fully understand the SYN (1) then SYN ACK (2) and then ACK (3), but how does the Client know that the third ACK has been seent to the server and the client can start sending further information? Or is it as assumed above, that the third ACK can already contain data?

Thank you very much! Jens

share|improve this question

3 Answers 3

up vote 1 down vote accepted

Answer to your first question.

Yes ping time can give you an idea about the time taken to establish the TCP connect.

Second question. You are right. With a 100milisecond latency your connection time would be around 300ms. Here is the math for that

  1. Client(SYN)-->Server = 50ms
  2. Server(SYN+ACK)--->client = 50ms
  3. Client(ACK+data)--->Server = 50ms

In the third question. Usually the ACK sent by the client includes data in it too. The TCP has a timeout value associated with it. If within that time the client doesn't receive any ACK from the server it will retransmit the data. The second case is when the client is during an ongoing transmission. Suppose the client sent packets from 1-10 but only received ACK for packets from 1-7 then the client will start retransmitting from the 8th packet onwards.

Second question. Should be answer by the first question

share|improve this answer
    
thanks very much, your answer was very helpfull. –  jens Dec 10 '10 at 2:37

You can use ping time to monitor basic connectivity and link latency, but I wouldn't correlate ping with TCP connection speed because it uses a different protocol (ICMP). In particular some upstream providers will give higher priority to ICMP packets than TCP to produce favourable ping times.

share|improve this answer
1  
Actually they won't. In most cases they will give ping and tracert traffic lower priority. Providers don't care how favorable their ping times are. They care about routing "real" traffic as quickly and efficiently as possible. Responding to pings deters them from that mission so they'll often give ping and tracert traffic lower priority or ignore it all together. –  joeqwerty Dec 9 '10 at 13:24
1  
You both have a point. Some providers value low ping times because they know that third-parties and users use ping times for benchmarking. Some providers care more about "real" traffic. I don't know which is more common. Unless there's congestion, ping times at least gives an indication even though it might not be perfect, and there are other tools such as tcping if you're picky. Size also matters... –  bytesinflight Feb 15 at 21:42
    
Great point about tcping! –  Nexus Feb 17 at 5:20

Have a look at this page. At the end of the 3-way handshake, both the client and server have received an acknowledgement of the connection. Data exchange can start.

share|improve this answer

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.