Introduction to TCP and UDP

Lessons Discussion
64

Hello Narad

The UDP header is fixed at 8 bytes. There are no optional additional fields that can be added.

I hope this has been helpful!

Laz

1 Like
65

What is the minimum and maximum TCP header length ??.

Can u please explain little bit about the TCP global synchronization and TCP slow start ??

66

Hello Narad

For the minimum and maximum TCP header length, take a look at this post:
https://forum.networklessons.com/t/introduction-to-tcp-and-udp/862/63?u=lagapides

Concerning TCP global synchronization and slow start, take a look at this lesson:

I hope this has been helpful!

Laz

67

Hello Narad

The length of the header of a UDP datagram is always 8 bytes. The fields within the header are always source port, destination port, length, and checksum, and each one is 2 bytes, which means a total of 8 bytes. Now the value within the Length field specifies the total size of the UDP datagram in bytes, including the header. This means that the Length can range from a minimum of 8 bytes to a maximum of 65535. This is a minimum of 8 bytes simply because you can have a UDP datagram with no payload, so its size will be the size of the header alone. The maximum value of the Length which is a 16-bit number is 65535.

For TCP, it is the Data offset field that specifies the size of the header in 32-bit chunks, or words. The data offset is 4 bits in length, so it can have values from 0 to 15. But the minimum value is 5, which is the size of the TCP header without options (532 = 160 bits or 20 bytes). The TCP header can also include options making the header larger, with a maximum possible header size of 1532 = 480 bits or 60 bytes.

As for your third question, when a TCP segment gets fragmented and placed into multiple IP packets, there is still only one sequence number associated with that segment. There is still only one header for that segment. TCP segments are fragmented based on the Maximum Segment Size or MSS. This is something that is negotiated at the beginning of a TCP session. If the MSS is larger than the lower layer IP MTU allows, then that segment will be placed within two or more IP packets, and will be reassembled during decapsulation at the other end. Even if a segment is split into three IP packets for example, there is still only one TCP header. Therefore, there is only one sequence number associated with that segment as a whole.

For more info about such fragmentation, take a look at the following lesson:

I hope this has been helpful!

Laz

1 Like
68

Hi,

Can you please answer the following questions on TCP?
When Sender try to initiate a connection, he sends SYN. Let say the receiver never responded to SYN, will sender sends another SYN? If yes, how many more SYN will he send? How long will sender keep sending the SYN?

Thanks,
Nihar

69

Hello Nihar

When a host attempts to begin a TCP session, it will indeed send out a TCP segment with the SYN flag set o 1 in the TCP header. If the receiver never responds to this, what happens next depends on various things. It depends upon the operating system of the device in question, as well as the application that is using that TCP session. There is a SYN timeout that is configured on each type of device.

For example, a Linux device will use a hardcoded retransmission timeout setting, where it will attempt to establish the connection every one second. It will continue to do so until the application trying to establish that session will choose to stop, and to consider the attempt failed.

Windows uses a dynamic TCP timeout which can be configured in the registry. The initial timeout is 3 seconds, but it doubles each time a SYN attempt fails. It has a maximum number of retransmissions of 5 before the attempt is considered a failure.

These behaviors can typically be adjusted by the application performing the connection, and should be adjusted to fit the needs of that application. An email client will operate differently than a web browser for example.

I hope this has been helpful!

Laz

70

Hi Rene,

In case of TCP, before source sends data, source will divide into segments and puts sequence numbers to each segment. and during transmission, if some data segments are dropped then how will source end knows that this data segment has been dropped for retransmission.
And how does receive end knows that some data segments has been dropped?

Thanks,

71

Hello Zahid

Take a look at this lesson which describes the process in detail.

In summary, a sender will send a number of segments whose total size in bytes is equal to the window size. It will wait for an acknowledgment (ACK) from the receiver telling it the next sequence number it is expecting. The sender will then begin sending once again, starting from the sequence number it just received in the ACK.

If a segment is lost in transit, the receiver will send back in its ACK the next expected sequence number of the last successfully and sequentially received segment. For example:

  • Sender A sends segments with sequence numbers 17, 18, 19, 20, 21, and 22.
  • Segment number 20 has been lost, but the rest arrive correctly
  • Receiver B, after a certain amount of time will send an ACK to Sender A with the sequence number 20.

Even though 21 and 22 were successfully received, the receiver will ask for the segments starting from the first missing segment, which is 20. Sender A will begin at 20 and continue sending 21, 22, 23 and so onā€¦

I hope this has been helpful!

Laz

72

HI,

Iā€™ve learned recently about another transport layer protocol called SCTP (Stream Control Transmission Protocol).
Also, Iā€™ve seen that this protocol is not recognized into an extended access-list.

Do you have any lesson about this topic?

Thanks

73

Hello Giovanni

SCTP is a protocol that incorporates the message-oriented operation of UDP along with the reliability of TCP. In general it hasnā€™t been implemented widely typically due to lack of implementation and lack of awareness. No large vendor has adopted it thus in general it remains an obscure protocol.

There are no lessons on this topic in the site, since it is not covered in any of the Cisco exams covered here, however, you can find information about it on Cisco devices. For example, the following documentation explains its implementation:

I hope this has been helpful!

Laz

74

Hello team, am grateful to be on this network lessons forum.

I have a question?
Am running two vms noted, each vm in different network, i have done a routing on the router to reach each other, the issue is TCP 3 way handshake doesnā€™t establish between the two vms, i resolved the issue by creating a loopback interface on the router with the same ip of one vm, then i tried to ping the second vm is reachable. I have removed the loopback interface from the router then the TCP establish between the two vms.

Please i need someone to explain why that happens

75

Hello Moris

Thatā€™s a very strange situation. In order for us to help you out, can you provide the following additional information?

  1. Is there initial connectivity between the two VMs? Can they ping each other? Simply pinging from one VM to another is different from establishing a TCP session. So if you canā€™t ping, then you should troubleshoot basic connectivity. If you can ping but canā€™t establish a TCP session, then we can troubleshoot the session itself.
  2. You say that the 3-way handshake doesnā€™t establish. Can you tell us why? Does the handshake begin but there is no response from the other end? Are they handshaking but simply canā€™t negotiate a session? If you do a Wireshark capture of the handshake, the reason for the failure should appear in the flags of the TCP header. Or, you will be able to see if any TCP segments during the handshake are not reaching the VMs for some reason.

This is indeed strange behavior. Is this router virtual or hardware based? Can you give us some more information about your topology? It would be helpful for us to suggest further troubleshooting actions.

I hope this has been helpful!

Laz

76

It is very hard to understand ,can you please help me for more insights over this ??

Regards
Shivam Chaudhary

77

Hello Shivam

Iā€™m not sure what part of the explanation you donā€™t understand. Can you tell me a little more about what you find difficult to comprehend? Thanks!

Laz

78

+++++++++++++++++++
Need to understand this one article just need to know when data be send is it after handshake complete and how the seq and acknowledgment number incremented .

Need more insight over this and explain the diagram in detail

???

81

Hello Shivam

Take a look at this NetworkLessons note on the topic of the TCP Three-Way Handshake. In it you will find detailed information about the sequence and acknowledgment numbers and how they function. If you have further questions, feel free to let us know!

I hope this has been helpful!

Laz

82

Hi Chaps, thanks for the great article. Very helpful and information.
Wanted to ask a question on sequence numbers to make sure i understand this correctly.

image
image1424Ɨ104 26.9 KB

Taking the above example from the article into account (using H1 and H2 as examples):

  1. H1 send a SYN to H2 with Seq=0
  2. H2 sends a SYN, ACK back with:
    ACK=1 i.e. to acknowledge Seq=0 and is expecting the next Session starting from 1
    SEQ=0 i.e. itā€™s OWN sequence number it is sending to H1
  3. H1 sends a ACK back with:
    ACK=1 i.e. to acknowledge Seq=0 sent from H2 and H1 happy with H2ā€™s sequence number starting from 0

My question is, for number 3. the sequence number that H1 sends back to H2 is SEQ=1. Is this to state that H1 is sending H2 a new sequence ā€œnumber of dataā€ and this is sequence number 1? Sequence number 1 was already sent in 1.
And for the next reply from H2 to H1 (not on the image), the sequence number H2 will send H1 will be Sequence number 1.

I also read that after the 3 way handshake is completed the sequence and acknowledge number will refer to the number of bytes which is good to know!

Thanks.

83

Hello Irfan

In your three steps that you shared, in step 2, you said that H2 sent an ACK of 1. This ACK states that it is expecting the next segment to start with sequence number 1.

When H1 sends an ACK back in step 3, it must thus send a SEQ equal to 1. Thatā€™s what H2 is expecting, thatā€™s what H2 asked for with its ACK=1. So this is why the third part of the three way handshake has SEQ=1.

SEQ of 1 was not sent in 1. SEQ was equal to 0 in step 1.

Thatā€™s correct. In fact we have two different and independent sequence numbers that are incremented. We have the SEQ sent by H1 and the SEQ sent by H2. These are not the same. So the SEQ value of 1 that H2 sends in the next reply (not shown) is incremented from H2ā€™s initial SYN ACK. Does that make sense?

Yes, this is indeed the case. The ACK number sent back to the sender tells the sender which byte it is expecting. This is important to keep the segments in order and to ensure error checking and TCP windowing.

I hope this has been helpful!

Laz

1 Like
84

Hi,

I am confused about acknowledge in TCP.

Some say Seq. no. + length = Acknowledge

& Some say Seq. no. + 1 = Acknowledge

So, What is correct either of two?

85

Hello Hemant

Remember that the sender and the receiver both maintain their own SEQ and ACK values, so there are two SEQs and two ACKs. The ACK that a host sends always indicates the next byte it is expected to receive from the other host. Thus, the ACK that will be sent will be the SEQ number it has received PLUS the number of bytes it has received.

You can see this in more detail in the NetworkLessons note titled TCP - SEQ and ACK values.

I hope this has been helpful!

Laz