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.
Related
Say we have sender A sending a message to receiver B using TCP. Say the message to be sent from A to B is split into three packets of length 500 bytes, 500 bytes and 50 bytes, to be sent in that order. How does A indicate to B that the packet of length 50 bytes is the last part of the message? I can understand that an ACK from B to A, sent every other packet received by B, indicates using the sequence number how much data has been received by B since the last ACK was sent by B. I read that FIN is used to terminate the connection between the sender and receiver. However, I can't find a description of how the the last packet, of a message split into several packets, is indicated. I'm thinking the packets have to be reassembled, in order, before the message is sent to the receiving application. I think that as one of TCPs actions is to split the message into packets, there must be some way of the sender flagging the last packet of a message has been sent.
I think that as one of TCPs actions is to split the message into
packets
No, TCP takes a stream of data and segments it into PDUs called segments. It is IP that uses the TCP segments as the payload of IP packets, which are in turn the payload of the data-link protocol, e.g. ethernet, frames.
However, I can't find a description of how the the last packet, of a
message split into several packets, is indicated.
Something like that is up to a higher protocol, e.g. HTTP. I think you are looking at TCP the wrong way. A TCP connection is like a bidirectional pipe; whatever you put in one end comes out the other end. TCP has no idea of the data structure, it just sends whatever it gets from the application or application-layer protocol. When an application or application-layer protocol is through using the connection, it tells TCP to tear it down.
The receiving TCP simply receives data and reorders it, asking for lost or missing segments. It passes properly ordered data up to the application or application-layer protocol, having no idea of the data structure because it is just a data stream to TCP.
Also, remember that both ends of a TCP connection are peers that can send and receive, and either end can send a segment with FIN that tells the other end that it is done sending, but the end sending the FIN is obligated to continue to receive until the other end also sends a FIN to say it is done sending. Either side could also kill the connection with a RST segment.
there must be some way of the sender flagging the last packet of a
message has been sent.
Probably, but that is not the job of TCP, that is up to the application or application-layer protocol. When the application-layer is done, it tells TCP to close, and that starts the FIN process. TCP has no idea what is the last part of a message is because it knows nothing about the data. It keeps the pipe open until it is told to close it.
I am very new to networking, so this might sound simple. Though I have tried to look here and here and here and have got few basics of TCP, there are few questions whose answers I am not certain about.
Is a request and response part of 2 different TCP establishments. To explain that :
Is a connection established, kept alive until all packets are delivered, request sent and connection closed for each request and same happens for its response.
or
A connection is opened, request sent, connection kept alive, response arrives and connection closed.
Is the ACK number always 1 + sequence number of sent segment.
Is a request and response part of 2 different TCP establishments
You need just 3 packets to handshake and establish a bidirectional TCP connection. So no, you do not establish TCP connection for receiving and sending parts.
On the other hand, there is a sutdown() system call which allows to shutdown a part of the bidirectional connection. See man shutdown(2). So there is a possibility to establish a unidirectional connection by opening a bidirectional and then shutdown one of the sides.
Is the ACK number always 1 + sequence number of sent segment.
We usually do not send ACK for every received packet. There are also selective ACKs, retransmissions etc. So in general, the answer is no, the ACK number is not always seq + 1.
On the other hand, if you are sending a small amount of data and waiting for the confirmation, no errors or packet loss occurred, most probably there will be just one packet with that data and one ACK with seq + 1.
Hope that helps.
Why does the TCP three-way handshake bump the sequence number when acking during the initial handshake? How is that better than just leaving the acknowledgement number equal to the sequence number?
The connection is established with
Client sends SYN,A
Server responds with SYN-ACK,A+1,B
Client confirms with ACK,B+1
How is that better than
Client sends SYN,A
Server responds with SYN-ACK,A,B
Client confirms with ACK,B
That's because the ACK field means this when the ACK flag is set:
Acknowledgment number (32 bits) – if the ACK flag is set then the value of this field is the next sequence number that the receiver is expecting.
If it is not set to (inital sequence number+1), it would be inconsistently mean both ack'ing the SYN (both SYN and ACK flags must be set in this packet) and saying it is expecting that sequence number again (i.e. hasn't received it).
Can anyone please let me know the procedures that happens in closing a tcp connection.
suppose there is A(Client) and B(Server) that A establish a TCP connection
A is creating a TCP connection with B
In opening a connection what happens if SYN packet from A drops in reaching the B, even if u do some retransmissions.
What happens if SYN+ACK drops in the network if B sending the packet to A.
What happens if ACK drops in the network from A to B.
A is closing the connection with B.
In closing a connection what happens if FIN packet from A drops in reaching the B, even if u do some retransmissions.
What happens if FIN+ACK drops in the network if B sending the packet to A.
What happens if ACK drops in the network from A to B.
Initial SYN packets are re-transmitted with an exponential backoff, usually starting at 2 seconds. I.e. 2s, 4s, 8s, 16s, etc.
The same goes for re-transmitted SYN-ACK packets (though there are some odd implementations that you really don't want to know about).
No ACK is ever re-transmitted blindly. If the other side re-transmits a packet, then another ACK will be sent.
The above is true for FIN as well, just substitute FIN where you see SYN. Of course, the starting re-transmit time is not 2s but whatever has been calculated to be the round-trip-time over the course of the session.
A SYN/FIN packet is treated the same as a data packet with regard to re-transmissions and reliability. Those flags even take up a sequence number so they can be properly tracked.
Say our client is sending the packets at a constant rate. Now, if server goes down temporarily there can be two situations
(We are using the TCP protocol)
1) The packet won't be delivered to the server. Consequently, the other packets in the line have to wait for the server to respond. And the communication can be carried out from there.
2) The packet won't be delivered and will be tried again, but the other packages won't be affected by this packet.
Say, packets A, B and C are to be transferred. While I am sending packet A the server goes down temporarily, then the packets B and C will be sent at the time they were initially scheduled to be or they will be sent once A is received by the server.
TCP is a stream-oriented protocol. This means that if, on a single TCP connection, you send A followed by B then the reciever will never see B until after it has seen A.
If you send A and B over separate TCP connections, then it is possible for B to arrive before A.
When you say "goes down temporarily", what do you mean? I can see two different scenarios.
Scenario 1: The connection between Server and Client is interrupted.
Packet A is sent on its way. Unfortunately, as it is winding its ways through he cables, one cable breaks and A is lost. Meanwhile, depending on the exact state of the TCP windowing algorithm, packets B and C may or may not be sent (as that would depend on the window size, the size of A/B7C and the amount of as-yet unacknowledged bytes sent). I guess that is saying both your "1" and "2" may be right?
If B and/or C have been sent, there will be no ack of A, until it has been resent. If they have been sent, once A has arrived, the server will ack up until the end of the last frame received in sequence (so, C, if taht is the case).
Scenario 2: The sever goes down
If this happens, all TCP state will be lost and connections will have to be re-established after the server has finished rebooting.