TCP Header

(Manami B) #11

Hi Rene,

I failed to understand the difference between Urgent Pointer and Push Function. Urgent Pinter has highest Priority over other data and Push function; this tells an application that the data should be transmitted immediately. Please help to understand.


(Lazaros Agapides) #12

Hello Manami

To understand the function of the PSH flag, it is important to first understand how TCP buffers data. TCP operates at layer four of the OSI model. To allow applications to read from and write to a TCP session, buffers are implemented on both sides of a TCP connection in both directions.

Buffers allow for more efficient transfer of data when sending multiple segments of maximum size, such as when sending a large file. TCP will wait until a segment reaches its maximum size before sending it on its way. There are however some applications where this would be inappropriate. A Telnet connection for example, requires that a character be sent immediately once it is typed, even though it fills only a tiny fraction of the maximum segment size. Consider what would happen to your Telnet session if TCP waited until there was enough data to fill a segment before it would send one. You would have to type over a thousand characters before the first packet would make it to the remote device. Not very useful.

This is where the PSH flag is used. When the PSH flag is set, the segment is sent or “pushed” immediately to the remote device. Additionally, when the segment reaches the destination, TCP immediately forward the segment up to the application without waiting for its buffer to fill.

Essentially, TCP’s push capability accomplishes two things:

  1. The sending application informs TCP that data should be sent immediately.
  2. The PSH flag in the TCP header informs the receiving host that the data should be pushed up to the receiving application immediately.

The Urgent Flag has a different function. It is used to indicate that certain data within a segment is urgent and should be prioritised. If the URG flag is set, the receiving station evaluates the value of the Urgent Pointer, a 16-bit field in the TCP header. This pointer indicates what part of the data in the segment, counting from the first byte, is urgent. This is not used very often in modern networks.

I hope this has been helpful!


(Lazaros Agapides) #13

Hello Mohammad

I’m not quite sure what you mean when you say “how many flags in TCP.” The header contains 9 different flags which are used to establish and terminate connections and to control data flow.

If this hasn’t answered your question, please clarify.

I hope this has been helpful!


(Mohammad Hasanuz Zaman) #14

Hlw Lazaros,

Yes , got my answer . Clould you please mention that flags name ?


(Andrew P) #15

Here are the names of the 9 flags:

  1. Explicit Congestion Notification Nonce Concealment Protection (that’s a mouthful!)
  2. Congestion Window Reduction
  3. Explicit Congestion Notification Echo
  4. Urgent
  5. Acknowledgement
  6. Push
  7. Reset
  8. Synchronize
  9. Final
(Mohammad Hasanuz Zaman) #16

Many Thanks Andrew …

(Mohammad Goush M) #17

Hi Rene,
Could you please explain what is PHANTOM BYTE in tcp?

(Lazaros Agapides) #18

Hello Mohammad

When a TCP session is in progress, the sequence numbers are used to keep track of the number of bytes that have been transmitted within the session. When 100 bytes are sent from host A to host B, host B will respond with an ACK that is incremented by 100. If this is the beginning of the transaction and we started with a sequence number of 0, then the ACK that host B will send will be 100 indicating that the amount of data that has been received so far is 100 bytes.

During the three way handshake, the first SYN packet is sent with an initial sequence number of 0, and has no data payload. That means that the number of bytes sent is 0. Even though the payload is 0, host B responds with an ACK incremented by 1. Because the SEQ and ACK numbers are associated with the number of bytes sent and received, when this occurs, we are actually incrementing the sequence numbers when no bytes have been sent. So this is referred to as the phantom byte, where 1 byte of payload is counted when 0 have been sent.

I hope this has been helpful!


(Hussein Samir) #19

Hi Rene,

I have Three questions :-

1- You say that seq number indicate how much data is sent during the TCP session and also say the initial sequence number is a random 32 bit value, so my question is how seq number determine the amount of data that it’s sent if the seq number not start from 0 ???

2- You tell me in my old question in this topic that “When we hit the final sequence number then it will wrap around and we start with 0 again and keep sending data in a single TCP connection”, again my question is how it can indicate the amount of data that it’s sent if we reach this point ???

3- Is there any relationship between the window size and download speed ??

(Lazaros Agapides) #20

Hello Hussein.

First of all the sequence number doesn’t indicate how much data is sent, but the difference between the original sequence number and the acknowledgement number sent back to the reciever indicates the amount of data that has been sent in one window.

Your first two questions have to do with something called windowing which is a flow control mechanism of TCP. Specifically, when a TCP session begins, the sequence number is chosen randomly. For example, let’s say the initial sequence number is 100588. During the initial handshake, the window size is also determined. This value is in bytes. Let’s say the initial window size is 10000 bytes.

With these values, the sender begins to send segments of data until it sends the window size number of bytes. Then it waits for an acknowledgement. When the reciever recieves the 10000 bytes, it sends the acknolwegement which includes the next expected byte. The next expected byte is calculated as the initial sequence number plus the window size plus 1. So the reciever would send 100588 + 10000 + 1 = 110589 as the next expected byte.

When the sender recieves this information, he begins sending the next “window” of data, that is the next 10000 bytes beginning with byte number 110589. (Remember that this value is a relative value and not an absolute value. It is relative to the original random sequence number.)

Once those 10000 bytes are sent, the reciever sends an acknowledgement with the next expected byte which is 110589 + 10000 + 1 = 120590. The sender recives this acknowledgement and begins sending the next section of data beginning at byte number 120590 and so on.

When the value of the sequence number becomes 4294967295, which is the maximum value a 32 bit binary number can have, it then wraps around to 0 and continues counting. The devices know that an original sequence number of 4294967290 with a final sequence number of 5 will have a difference of 10.

As for your third question, the answer is yes. More accurately however, the window size determines the efficiency with which a link is utilized. Take a look at the excellent video found in this lesson which demonstrates how the window size affects the throughput of data.

I hope this has been helpful!


(Hussein Samir) #21

Thanks LAZ that indeed helpful,

the seq number indicate the amount of data has been sent in one window not in the entire TCP session, I was confused because Rene said seq number indicates how much data is sent during the TCP session


(Lazaros Agapides) #22

Hello Hussein

Yes I understand the confusion. Keep in mind that if you take the first sequence number that was used when the session was initiated and the last sequence number that was used before termination, if you calculate the difference between them, it will indeed be the total amount of data in bytes that have been sent over the whole session (taking into account the number of times the sequence number has to be reset to zero when it reaches the upper limit of the 32 bit field).

I hope this has been helpful!


(Hussein Samir) #23

Hello @lagapides

Thank you very much, now everything is clear, only one thing which is how to find out the number of times the sequence has been reset to zero ?? I mean is there any filed or option in TCP header determine that ??

(Lazaros Agapides) #24

Hello Hussein

Unfortunately there isn’t. Because the window size is always going to be much much smaller than the largest available sequence number, it will never reset to zero within a single segment. Segments are always many many orders of magnitude smaller. Only the hosts between them keep track of when the counter resets to zero. Even when it does, they only detect it at that specific segment. Once the segment is received and acknowledged, there is no need to keep track of the resetting of the counter from the host’s point of view.

If you want to keep track of the total amount of data that has been sent in a session, there are other mechanisms that can do that, that belong to higher layers. For example, in an FTP transaction, FTP keeps track of bytes transferred and other such statistics.

I hope this has been helpful!


1 Like
(Hussein Samir) #25

Thank you very much @lagapides your answer very clear and helpful for me

(Muhammad Rasoul A) #26

Hi there,
Could you please tell me what is Urgent Pointer field and URG in the Flag field.

(Lazaros Agapides) #27

Hello Muhammad

A host can have many TCP sessions occurring at the same time. Hosts will generally processes TCP segments on a first come first serve (FIFO) basis even when these segments come from multiple TCP sessions. When large volumes of data are being transferred, this can impact the responsiveness of some of the TCP sessions.

If the URG flag is set to zero, segments are treated in a FIFO manner. When the URG flag is set to 1, this tells the receiving host that this segment should be treated as urgent. How urgent? Well that depends on what is found within the Urgent Pointer field. The Urgent Pointer field instructs the TCP stack to halt other sequential data pushes and immediately create a secondary “out of band” channel for those packets to speed up data transmission. The value in the Urgent Pointer is known as a sequence number offset, indicating how far forward in the sequence numbering of the TCP segments this particular segment should be placed.

Examples of the use of the URG flag and the Urgent Pointer include its use in Telnet and SSH sessions where an immediate response, such as the echoing of typed characters, is required.

I hope this has been helpful!


(Muhammad Rasoul A) #28

Thank you Lazaros,
now it is clear.

1 Like
(Dominique R) #29

Hi Rene and staff,
please , could you add some explanations about TCP header in TCP connections with MD5 authentication ?

(Lazaros Agapides) #30

Hello Dominique

The TCP authentication using MD5 is a feature that is included in the Options portion of the TCP header. This feature is primarily used to protect BGP sessions using an MD5 Signature. This is further described in RFC 2385. However, this is now considered obsolete and has been replaced by the TCP Authentication Option which is described in RFC 5925.

Cisco has support for the Authentication Option in its Nexus platforms which can be seen here:

Most of the info concerning TCP header fields for both AO and MD5 authentication can be found in the RFCs.

I hope this has been helpful!