Suppose that Host A and B are communicating over a TCP connection, and Host B has
already received from A all bytes up through byte 126. Suppose Host A then
sends two segments to Host B back-to-back. The first and second segments
contain 80 and 40 bytes of data, respectively. In the first segment, the
sequence number is 127, the source port number is 302, and the destination
port number is 80. Host B sends an acknowledgment whenever it receives a
segment from Host A.
In the second segment sent from Host A to B, what are the
sequence number, source port number, and destination port number?
If the first segment arrives before the second segment, in the
acknowledgment of the first arriving segment, what is the
acknowledgment number, the source port number, and the destination
port number?
If the second segment arrives before the first segment, in the
acknowledgment of the first arriving segment, what is the
acknowledgment number?
Suppose the two segments sent by A arrive in order at B. The first
acknowledgment is lost and the second acknowledgment arrives after
the first timeout interval.How this will be managed ? what will
happen to acknowledgement and sequence number ?
Related
If a router or a host receives a packet, the value of "total length" field is larger than the packet's actual length, what will the router (or the host) do?
Below is a sample, I edited a packet, then captured by Wireshark. But it's only a local capture result, I want to know the actual situation when the packet arrives at a router (or host).
IPv4 total length exceeds packet length
I have read that if a packet in TCP does not have a valid sequence number, then the packet will be dropped by the receiving side.
But what if the packet have a valid sequence number but have an invalid ACK number, will the packet also be dropped by the receiving side?
There's really no such thing as an "invalid" acknowledgement number. If you mean that the number doesn't fall within the window (the advertised memory buffer of the host), that's a different question.
If the ACK isn't within the window, the host will respond with a reset to indicate that it has no notion of there being a connection with these "keys", where the keys are source, destination, source port, destination port, sequence numbers.
By which fields of TCP packet, we can tell if it is a continuation of a previous TCP packet?
To be part of the same TCP stream, TCP segments must belong to the same session .i.e have the same source IP, source port, destination IP and destination port.
Once two segments are from the same stream, they can be ordered by the sequence number field in the TCP header. The sequence number of the next segment should be equal to the sequence number of the previous segment plus the number of bytes in the previous segment.
So if we have a segment with seq# 1000 and a payload of 200 bytes, the next one should have the number 1200.
TCP: Sequence number, Acknowledgement number.
In Wireshark, you can Right Click on a packet and choose Follow to follow TCP or HTTP stream. It should help seeing how there values change from packet to packet.
I was reading a book about computer network written by Tanenbaum specifically about handshaking. In there he explains two-way handshake is not enough, considering this case:
A wants to transfer money to B, so A sends a SYN to B, and then B sends an ACK to A. Connection is established and then A can send his money and then drop the connection after it's done. If there is a delayed duplicate SYN from A to B, B will send its ACK again and A will be transferring its money again.
That is one of the weakness of two-way handshake based on the book written by Tanenbaum if I understands it right. The book says three-way handshake can solve this problem.
With a delayed duplicate SYN from A, B sends an ACK and SYN which get rejected by A. This is where I don't get it, it's as if "Hey B why do you send me a SYN and ACK? Oh I know, this is from a delayed SYN, I should just drop it.". Why not, in two-way handshake, A doesn't know that the ACK is made by a delayed duplicate SYN?
Thanks.
To establish a connection, the three-way (or 3-step) handshake occurs:
SYN: The active open is performed by the client sending a SYN to the server. The client sets the segment's sequence number to a random value A.
SYN-ACK: In response, the server replies with a SYN-ACK. The acknowledgment number is set to one more than the received sequence number i.e. A+1, and the sequence number that the server chooses for the packet is another random number, B.
ACK: Finally, the client sends an ACK back to the server. The sequence number is set to the received acknowledgement value i.e. A+1, and the acknowledgement number is set to one more than the received sequence number i.e. B+1.
At this point, both the client and server have received an acknowledgment of the connection. The steps 1, 2 establish the connection parameter (sequence number) for one direction and it is acknowledged. The steps 2, 3 establish the connection parameter (sequence number) for the other direction and it is acknowledged. With these, a full-duplex communication is established.
According to Kurose and Ross's "Computer Networking: A top-down approach", 6th Edition, p. 232,
The first two segments carry no payload, that is, no application-layer data; the third of these segments may carry a payload. Because three segments are sent between the two hosts, this connection-establishment procedure is often referred to as a three-way handshake
In other words, A does not need to wait for the three-way handshake to complete before sending data. Only B needs to wait for the three-way handshake to complete.
And why does B need to wait? As S. Richmond says, B needs to know that A has received its sequence number before it starts sending data.
The three-way handshake is necessary because both parties need to synchronize their segment sequence numbers used during their transmission.
So, they(in turn) send a SYN segment with a sequence number set to a value n, which then is acknowledged by the other party via a ACK segment with a sequence number set to n+1.
Suppose that client does not send ACK(case of 2 way handshake). Now there might exist a case where seq number of client is not synchronized, but the server will assume that it is synchronized. This could cause a problem.
I have a question on how TCP_ACK works when the original packet are fragmented.
For example, original packet size is 1,500*N bytes and MTU is 1,500. Then, the packet will be frgmented into (approximately) N packets.
In this case, how does the receiver sends TCP_ACK to the sender?
I checked with wireshark, it seems that the receiver sends TCP_ACK for every two fragmented packet. Is it right?
Could you give me some refereces for this or explanation?
Thanks.
IP layer on the receiver stack reassembles all the IP fragments into a single TCP segment before handing the packet over to TCP. Under normal conditions, TCP should send only one ACK for the entire TCP segment. The ACK # would be the next expected SEQ # as usual.