Saturday 4 January 2014

TCP Introduction – II



There are some other mechanisms we need to understand the TCP.

Interactive or bulk data flow:

Use interactive or bulk data flow is really depends on the applications. Some interactive application such as ssh/telnet or xwindow, it needs the server to give the feedback and response quickly. Other applications such as HTTP, the packages are meanling less unless all the packages arrive and put to the application. The formal is called interactive and the later one is called bulk.

Interactive data flow:

If TCP acknowledge every package, it will cause network congestion especially over WAN. So TCP will use Delayed Acknowledgement. It will try to combine the acknowledge with the next available application data. The delayed time is usually 200ms.
Nagle algorithm usually should be disabled. Nagle algorithm will try to combine tiny multiple application packages into a bigger package and send out. This algorithm will save transmission number. But it is not suitable for interactive data flow. The application can disable it by TCP_NODELAY.

Bulk data flow:

Bulk data flow is a little bit more complicated.


  1. usually TCP won’t acknowledge every package. A acknowledge is with the sequence number and it means acknowledge all packages before that sequence number.
  2. TCP uses sliding window to control the flow: the left side means the packages have been acknowledged. The right side means the packages have been transmitted but not acknowledged. Window Closes: acknowledgement is received. Window opens: data is delivered to the application.
  3. PUSH flag: it means the application data is finished. And it should be submitted to the application immediately.
  4. slow start: the sender will send just 1 package and wait for ack. If acked, it will send 2. if acked again, it will send 4. so it can use this method to test what is the limitation of the sending window. It will choose the min(congestion window, informing window) as the sending window.

Timeout and re-transmission

TCP timeout and retransmission is an important feature of TCP. When a package is sent, the TCP stack will start a timer, if no ack timeout, the TCP will resend the package.
TCP has a complicated method to estimate a suitable timeout value.

Different Timers

Retransmission Timer: used to control the sending packages. Tradictional value is 2*RTT. If received ack. Then send the next package and reset the timer, if not. Resend the package and reset the timer.
Persistent Timer: when the peer inform the sernder the window is 0, it means it can’t accept packages any more. Then the sender has to wait until the receiver sends ack to inform the resume. But the ack is probably lost in the network. So it can cause a deadlock. The sender wait for the ack, and the receiver wait for the new packages. The persistent timer is used to resolve the deadlock. When the persistent timer is timed out, the sender will send a window probe package to inform the receiver if he can start accepting new packages. Usually 60 seconds.

Keeplive Timer: used to test if the peer is alive of not. Usually 2 hours, if no application data is transferred, the server will send a probe package, if not acked after 10 times, server will terminated the TCP session.
Time_Wait Timer: after the last fin_ack, the connection is still in time wait status, the timer is usually 2*MSL.

No comments:

Post a Comment