Thank you Lagapides. i got it now. what about UDP header?
Hello Gowthamraj
The UDP header is much simpler than the TCP header because it doesnât include flow control, error correction, and session maintenance mechanisms. A UDP datagram is sent on its way by the sender and forgotten.
Below you can see the UDP header:
It has source and destination port fields, a length field and a checksum field. The source and destination ports are the values of the transport layer ports that the particular application layer protocol is using. The UDP length field simply indicates the size of the datagram including the header. The checksum is used for error checking of the header and data. This field is actually optional for IPv4 but mandatory for IPv6. If the checksum results in an error, the datagram is simply discarded.
More info about UDP and its differences compared to TCP can be found at the following lesson:
I hope this has been helpful!
Laz
thank you lagapides. what is UDP header min and max bytes.
Hello Gowthamraj
The UDP header does not have any additional options that can be added, so it is always fixed at 8 bytes. The Length field of the UDP header is used to indicate the length of the whole datagram, including the header and payload. The minimum size of a UDP datagram is 8 bytes, which means you can send a UDP datagram with 0 payload. The maximum size of a UDP datagram can theoretically be up to 65535 bytes including the header, as the length field, a field of 16 bits can only define sizes up to that value.
I hope this has been helpful!
Laz
thank you lagapides. theoretically upto 65535 but in real time same like MTU 1500 bytes right
Hello Gowthamraj
In general, yes this is the case. But remember that we can have fragmentation at the encapsulation of a UDP datagram into multiple IP packets, as well as the fragmentation of one IP packet, into multiple Ethernet frames. In this way, the MTU will not be violated, but you can have UDP datagrams (and IP packets) larger than the allowable MTU at lower layers.
I hope this has been helpful!
Laz
Hi Rene,
If one packet is missed during the transfer(From 8,9,10 packet 10 is missed) how can you get that packet back ?
Thanks,
Hello Nihar
TCP creates a session between the two hosts that are communicating. Within this session, various parameters are agreed upon and implemented. One of these is the window size. This is the number of bytes that can be sent by one host to another before expecting an acknowledgement back from the receiver that they have been successfully received.
For example, take a look at the following image:
Imagine we have a window size of 7000 bytes, and each segment is 1000 bytes in size. H1 has sent seven segments to H2. H2 responds with an ACKnowledgement stating that it has received segments 1 to 7 and is expecting segment 8 (in actuality, the value of the ACK would be the next expected byte, which in this case should be 7001).
If segment 5 failed to arrive, H1 would continue to send segments until the window is exhausted. It will then wait for an ACKnowledgment. H2 will wait for segment 5 for a predefined timeout period, and will then send an ACKnowledgement stating the next expected byte. So the ACK it would send is 5 (or the byte that corresponds to that next segment). H1 will receive this, and begin sending segments again, starting at segment 5, 6, 7 and so on.
So if there is a missed segment, the receiving host will inform the sender of the next expected byte, thus ensuring that segments arrive successfully.
I hope this has been helpful!
Laz
Hi Renne,
Please explain about TCP flags.
Hello Ashish
You can find information about TCP flags in the following lesson:
I hope this has been helpful!
Laz
Hello @lagapidis @ReneMolenaar
o RST: this resets the connection, when you receive this you have to terminate the connection right away. This is only used when there are unrecoverable errors and itâs not a normal way to finish the TCP connection.
It is mentioned that RST flag is used when there are unrecoverable errors.
Can you please give some examples of what kind of errors could cause the server/host to send RST flag?
Hello Tejas
The RST flag or reset flag is a way in which a TCP session can be terminated immediately. Itâs kind of like a âhard terminationâ or âhard resetâ of the session. Under normal circumstances, the RST flag is set to 0. If however, a host receives a TCP segment with RST set to 1, it indicates that the host should immediately stop using the TCP connection. It should not send any more packets using the ports in the session, and any further packets it receives from this session should be dropped.
This may occur under various circumstances, such as when host A, for example, crashes while a TCP connection is in progress with host B. Host B will continue to send TCP packets since it doesnât know that host A has crashed. If host A recovers (say after a reboot) it will begin receiving packets from host B from the connection that existed before the crash. Host A has no TCP session with these parameters, so it will send a TCP reset to host B. This indicates to host B that the session has failed.
I hope this has been helpful!
Laz
1 Like
What is the maximum data size i can sent in one segment or in one window in TCP ?
Hello Narad
The maximum segment size of a TCP segment is a value that is found within the TCP header and is negotiated during the 3-way handshake, specifically in the TCP SYN packet. By default, the MSS is set to 536 but is often changed to accommodate the underlying network and datalink layers. The MSS however is associated somewhat with the IP MTU and the Ethernet interface MTU. Typically the MSS is negotiated in order not to exceed the MTU of the underlying layers so that fragmentation is minimized. It cannot be changed once the session is up and running.
The actual maximum value of the MSS is defined using a two-byte field in the TCP options, so the maximum MSS you can have is 65535.
Now, this is different from the maximum window size. Remember the window size is the maximum number of bytes that can be sent before an acknowledgement is received. This value is defined in a different field called the Window Size which is part of the main TCP header. This too has a size of two bytes, so the maximum window size is 65535. This value can be renegotiated during a session.
Typically such large values for window size and for MSS are used in long fat networks, which are high capacity long-distance networks such as undersea fiber or satellite links, that generally require fewer acknowledgments due to their long transmission delay and super-high capacities. Unless you work for an international Tier-1 telecom provider, it is not common to see such large window sizes.
I hope this has been helpful!
Laz
1 Like
Hello Team,
I have a confusion between details of an ACK and SEQ, please once explain with a simple example that how SEQ ( next seq number ) and ACK ( ack of seq received) numbers calculated and used, if possible with a packet capture.
Hello Imran
Take a look at this post which shows the process in a little more detail. If you have any specific questions, let us know!
I hope this has been helpful!
Laz
Hi when we use options in the TCP header ?
Hello Abdul
The options field in the TCP header can contain various pieces of information. These include things like maximum segment size, window scale, and timestamps. The type of option is denoted by a one-byte âOption-Kindâ field, which is further defined by the IANA. These definitions can be found here:
https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1
The truth is that there is relatively limited use of the TCP options field, and most Option-Kind values are either historical, obsolete, experimental or simply unassigned.
For more info, take a look at this NetworkLessons note on the subject.
I hope this has been helpful!
Laz
Hello,
Why does the Checksum field exist when the 802.11 and 802.3 frames (as well as all other types of Ethernet frames) already have FCS fields in their trailers?
Thanks.
Attila
Hello Attila
The Checksum field in the TCP header plays a similar role to the FCS field in the trailer of Ethernet frames in that they both check the integrity of the transmitted data. However, because they exist at different layers, they perform and behave very differently and thus serve somewhat different purposes.
The FCS field in the Ethernet frames ensures that a received frame has not been corrupted during transit. Remember that communication at Layer 2, which is where Ethernet resides, is performed on a hop-by-hop basis. The FCS is actually recalculated at every hop. If the FCS fails when transmitted from one router to another, the frame is simply dropped. It is up to higher-layer protocols to recover from such a failure.
On the contrary, the Checksum field in the TCP header is used to ensure data integrity for end-to-end communications (as opposed to hop by hop). The checksum provides end-to-end error detection between the source and destination application and is tested when received by the intended application. This means that it checks for errors across the entire path of the communication. If the checksum fails, the receiver will not accept the segment but will inform the sender to resend the segment that was not received correctly. TCP does not simply drop the segment. This is part of why TCP is considered a âreliableâ protocol because it has mechanisms to correct faults rather than simply discarding the segment.
One final difference between the two is that the TCP checksum checks the integrity of the TCP header and payload, while the FCS in the Ethernet frame covers the entire frame, including the Ethernet header and payload, and the IP header and payload. These different scopes are important to ensure data integrity across the different layers of the network stack.
I hope this has been helpful!
Laz
1 Like