Hi Marcel,
That’s right, that picture should show SEQ=1 otherwise we only sent 1 byte. Just updated the picture, thanks!
Rene
Hello, if we established a TCP session with a server and the client is requesting a file. How does the client know when the file transfer from the server has been completed. For example we haven’t reached the received window size, how does the client know when to ACK the last packet, if the server won’t send a fin packet.
Thanks a lot.
Regards,
Lukas
Hello Lukas
TCP will take care of things like window size, reliable transfer, and sequencing. Mechanisms involving the recognition of the end of the file being sent have to do with the application layer protocols being used for file transfer. If you’re using FTP, then FTP has mechanisms in place to keep track of the remaining bytes of a file being sent. Once the file is complete, then the other end will be informed using the exchange of FTP information. How does TCP participate in this? Well, if the session is finished, FTP will close the session, thus instructing TCP to send a FIN flag. The same goes for any other upper layer protocol such as SMB, or even HTTP for file transfer.
TCP doesn’t care about if a file has been completed or not. It cares only about sessions. Sessions will be kept open as long as necessary. They’ll be closed only with the FIN flag, and only if that is what the application layer protocol being used needs.
I hope this has been helpful!
Laz
1 Like
Hi Laz,
thanks a lot for your answer 
. Does that mean, that HTTP,FTP,SMB will initiate an ACK, when the protocol has received all requested data? For example if you have a webserver, how does the client know if all http files have been downloaded or if the http file download has been completed. I have seen a packet capture with HTTP traffic to the client and suddenly the client sends an ACK to the server.
Regards,
Lukas
Hello Lukas
This has to do with the way that each application protocol addresses “end of file” issues, and any other issues for that matter. For the example of HTTP, during encapsulation, the HTTP information is encapsulated within a TCP segment, with the TCP header containing the flags (SYN, ACK, FIN etc) that define the TCP interaction between hosts.
With the appropriate commands and signalling, during the encapsulation process, HTTP will inform TCP of its requirements. When the communication starts, HTTP will inform TCP that a session is to be created, so the three way handshake takes place. During transfer, HTTP informs TCP that there is still more information to be sent. When the file transfer completes, during encapsulation, HTTP will inform TCP that this is the last segment, so TCP will send the FIN flag and the appropriate procedures for closing a session take place.
It is important here to make clear that HTTP itself does not initiate or send transport layer flags. HTTP (and any application layer protocol) will simply inform the transport layer protocol of its requirements, and the transport layer protocol will interpret these requirements and make the appropriate decisions (flags, sessions, etc). Each layer is distinct and it does not get involved in the operation of other layers, other than to make its requirements known.
ACKs may be sent for all the duration of a session. ACKs are sent whenever a full window-size piece of data has been received. The ACK simply lets the sender know that all the expected data has been received and that the next set of data can now be sent. This is a purely transport layer operation and does not involve HTTP. More about the ACK flag and its mechanisms can be seen in the following lesson:
I hope this has been helpful!
Laz
2 Likes
Hello Laz,
your answer is great and thank you so much for your detailed reply.
My last questions 
What if the TCP Window Size is not full, but the client has received all data? Does that mean, that the client is expecting some data and knows by itsself, based on the HTTP Header that it has received all data and then sends an ACK?
I’ve found the following HTTP Conversation in Cloudshark:
https://www.cloudshark.org/captures/0012f52602a3
Why is the ACK Flag set in the data packets? (Packet 6,8,…)
Why does the client ACK each packet and not waiting for full windows size?
Can you recommend a book or tutorial to learn more about TCP/IP conversations?
Thank you so much again, your answer is really helpful.
Kind Regards,
Lukas
Hello Lukas
This is a misconception that is often encountered when looking at windowing. It is the statement that “a receiver will wait until the window has been exhausted before sending an ACKnowledgement.” This is not the case. The truth is that “a sender is obligated to pause if a window-sized set of data is sent without receiving an ACKnowledgement”. This does not restrict the receiver from sending ACKnowledgements more often than the window size requires. So window size does not determine how often or when a receiver should send ACKnowledgements, as they are allowed to send them more often. Originally, TCP was designed to ACKnowledge each segment, but this was optimized later to allow the receiver to send ACKnowledgements after many segments have been sent. You will see this occurring under more traffic demanding situations such as the transmission of large files where efficiency is important.
In the example you sent, the receiver is ACKnowledging each segment, but the sender is not waiting for this ACKnowledgement to send the next packet. It is however taking these ACKnowledgements into account as the Ack value is increasing accordingly and the window size is also increasing from the moment that the receiver is acknowledging the segments so efficiently.
Whenever the ACK flag is set, it means that the acknowledgement number in the field is significant. During the three way handshake, the ACK flag is set to 0 initially, because there is no acknowledgement number defined, so anything in that field should be ignored. Every segment after the first one will have an ACK bit set, meaning the ACK number is valid and used in the exchange. Remember that TCP is bidirecitonal, and this means that there isn’t only one sender and one receiver, but both parties are both senders and receivers. This means there is a SEQ number for one direction, and an independent SEQ number for the other. The same goes for the ACK number, as well as window size.
In the example you gave, you can see that the ACK number for segments going from the host to the server started at 0. Once the GET command was sent, which had a length of 134, the ACK sent back by the server was 135, which is the next expected byte. But this is not incremented at all and remains 135 for all subsequent segments. This is because there is currently no data being sent from host to server, so no additional bytes are sent, thus the ACK number is not incremented stating “I received no data”. But the ACK flag is set, because this states that the value in the ACK field is significant.
I hope this has been helpful!
Laz
2 Likes
Hi Laz, your answer is awesome. Thank you so much
2 Likes
Hello Laz,
Its little interesting to learn in deep and I am getting more query here.
How acknowledge number is calculated, Sequence number + Message length + 1 ?
Next, Let us assume i have a file of size 100bytes,
Host1 which is sending a file has send buffer size as 10 bytes.
Host2 Receive buffer size is 5 bytes.
As per my understanding during handshake,
Host1 -> seq no is 1 and ack is 0 for syn.
Host2 -> Seq no is 20 and ack is 2 (syn seq no + 1) for syn/ack.
Host3 -> Seq no is 2 and ack is 21 (20 + 1) for ack.
During handshake while calculating acknowledgement number it wont add message length or Message length would be 0?
Once after when we started transferring data, After ack how data transmission will start transfer. Host1 will start transmission immediately after sending ack?
In such a case what will be the sequence number and ack for that packet?
Host2 will send an ack only if there is a change in window size? or How frequent it will send ack, assuming it wont send for each and every packet?
Hello Thiyagarajan
The acknowledgement number can be viewed as the next byte that a receiver expects to receive.
In other words, you are correct. It is the last received sequence number + message length + 1.
The acknowledgement number that that is sent in parts 2 and 3 of the handshake won’t add the message length, because the message length is zero.
Yes, once H1 sends the ACK, it will then begin transferring data immediately.
The third part of the 3way handshake does not have to be acknowledged immediately by H2, so the SEQ will be 3 and the ACK will still be 101. The SEQ is always incremented from the previous packet by the message length +1. Since there is no message length, SEQ is simply +1, so it will be 3. The ACK number will always be the last SEQ number recieved +1. So this remains the same (101) since no new segment has been received from H2.
Host 2 will send an ACK whenever it wants, depending on it’s traffic load. If it is capable of sending an ACK for each segment, it will, but if not, it will always send an ACK within the window size. You can see more detail about this in the following post:
I hope this has been helpful!
Laz
Hi Laz,
Thanks for clarifying.
Little confusion with window size and fragmentation.
Window size is based on size of our send or receive buffer.
What about Fragmentation in IP packet.
On what basis it will get fragmented and how it will get reassembled at receiver side.
Hello Thiyagarajan
Window size is indeed based on the size of the send and receive buffer. It also depends on how fast the receiver can receive, process, and reassemble TCP segments at a particular time. This in turn depends on the NIC of the host, the resources (CPU and memory) available for the process at the time, as well as how many TCP sessions are competing for the available bandwidth and resources of the NIC and the host. If too many segments are lost, the receiver will send a message to the sender to slow down. So window size is something dynamic and essentially tells a sender “the maximum number of bytes it can send before having to wait for an acknowledgement.”
As for fragmentation, it depends on what you mean. Fragmentation usually refers to one aspect of encapsulating an IP packet into an Ethernet frame. Specifically, it is the act of breaking IP packets into smaller fragments during encapsulation in order to “fit” them into the maximum available size of the Ethernet frame. This has to do with the Maximum Transmission Unit (MTU)
However, I believe what you are referring to in this post is not fragmentation, but segmentation. This is the process by which the data is segmented into TCP segments during the encapsulation process from the Application to the Transport layer. Here it is the Maximum Segment Size (MSS) that determines the maximum payload a single TCP segment can have. For TCP sessions, this value is negotiated for each direction of traffic. For UDP, where there is no negotiation, this is determined by the sender based on the application being used.
Both MTU and MSS are described in full including their interdependencies in the following lesson:
I hope this has been helpful!
Laz
1 Like
Hi Laz,
Again thanks for the brief info.
1 Like
Hi Rene,
in this article u capture 3 way handshake in wires hark, from the first packet itself its showing win=5840 how this value came during three way handshake.
Hello Gowtham
Take a look at the response to this post.
I hope this has been helpful!
Laz
Hi Laz,
I want to know, In 3 way handshaking and while data being transmitted is ACK no will always be +1 to the sender’s sequence no or any random no?
Hello Pradyumna
The initial sequence and acknowledgement numbers used in a TCP handshake are random. But once they are established in the handshake, they are incremented accordingly. After the handshake, when a sender sends X bytes of data, as shown in the lesson, the receiver will respond with an acknowledgement number equal to the next expected byte. The next expected byte is X+1.
A more detailed description of this process, for both the handshake and the process of exchanging data can be found at this post:
I hope this has been helpful!
Laz
Hello lazaros ,
In TCP 3 way handshake,H2 will send ACK=2 for the SEQ=1 but in the flow control section why H2 is sending ACK =11 for the SEQ=1. Is the acknowledgement is based on the sequence number Or total number of data’s received?
Thank you
Hello Rajaram
The value that H2 sends as an ACK is always the number of the next expected byte. This is also the same as the value of the next SEQ number that will be sent from H1 and is expected by H2.
So looking at this picture:
- H1 has sent a sequence number of 1 and 10 bytes of data.
- H2 sends back an ACK saying to H1 “the next byte I’m expecting is number 11”
- H1 will send the next batch of data, starting with byte number 11, which is also the value of the SEQ number it sends.
In the case of the 3-way handshake, the initial SYN packet has no payload, so it is considered to be a single byte. Therefore, H2 sends an ACK of “the next expected byte” which is the initial SEQ it received from H1 + 1.
So the ACK behaves the same in both the 3-way handshake as well as while transferring data…
I hope this has been helpful!
Laz
1 Like
Q-1:-In UDP The minimum length is 8 bytes ,I have a doubt that this 8 byte is fixed for UDP header OR it can be more than that ?
Q-2:-What is the minimum and maximum a tcp header length can be ?
Q-3:- The sequence number of all fragmented packets are going to be same or not ?
Kindly help me to understand it please…!!