TCP Header

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!

Laz

Hlw Lazaros,

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

br//
zaman

Zaman,
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

Many Thanks Andrew …

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

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!

Laz

2 Likes

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

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!

Laz

3 Likes

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

Untitled

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!

Laz

2 Likes

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

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!

Laz

1 Like

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

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

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!

Laz

Thank you Lazaros,
now it is clear.

1 Like

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

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!

Laz

hi Rene,
please ,
I have question about TCP Header especially Destination port
how can know the Destination port ??
thanks…

Hello Abd

When a TCP session begins, the initiator sends a TCP segment which includes a source port and a destination port. The destination port is determined based on the service that is being requested.

If the TCP session is initiated by a client towards a server, then the destination port will be that of the service that is being requested. For example, if a PC is connecting to a web server such as www.networklessons.com, then the default destination port used will be 80, because that is what is used for HTTP. If you are using a secure connection, using HTTPS, then the default destination port will be 443. You can change this port by using the following syntax: www.networklessons.com:8080, which will connect you to port 8080. However, if the server is not offering services on this port, you will obviously be denied.

When a server responds to a request, the destination port is that of the original request. So if your PC uses source port 53988 and destination port 80 for the initial communication, the return communication will use a source port of 80 and a destination port of 53988.

I hope this has been helpful!

Laz

1 Like