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.
Related
We're seeing this pattern happen a lot between two RHEL 6 boxes that are transferring data via a TCP connection. The client issues a TCP Window Full, 0.2s later the client sends TCP Keep-Alives, to which the server responds with what look like correctly shaped responses. The client is unsatisfied by this however and continues sending TCP Keep-Alives until it finally closes the connection with an RST nearly 9s later.
This is despite the RHEL boxes having the default TCP Keep-Alive configuration:
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75
...which declares that this should only occur until 2hrs of silence. Am I reading my PCAP wrong (relevant packets available on request)?
Below is Wireshark screenshot of the pattern, with my own packet notes in the middle.
Actually, these "keep-alive" packets are not used for TCP keep-alive! They are used for window size updates detection.
Wireshark treats them as keep-alive packets just because these packets look like keep-alive packet.
A TCP keep-alive packet is simply an ACK with the sequence number set to one less than the current sequence number for the connection.
(We assume that ip 10.120.67.113 refers to host A, 10.120.67.132 refers to host B.) In packet No.249511, A acks seq 24507484. In next packet(No.249512), B send seq 24507483(24507484-1).
Why there are so many "keep-alive" packets, what are they used for?
A sends data to B, and B replies zero-window size to tell A that he temporarily can't receive data anymore. In order to assure that A knows when B can receive data again, A send "keep-alive" packet to B again and again with persistence timer, B replies to A with his window size info (In our case, B's window size has always been zero).
And the normal TCP exponential backoff is used when calculating the persist timer. So we can see that A send its first "keep-alive" packet after 0.2s, send its second packet after 0.4s, the third is sent after 0.8, the fouth is sent after 1.6s...
This phenomenon is related to TCP flow control.
The source and destination IP addresses in the packets originating from client do not match the destination and source IP addresses in the response packets, which indicates that there is some device in between the boxes doing NAT. It is also important to understand where the packets have been captured. Probably a packet capture on the client itself will help understand the issue.
Please note that the client can generate TCP keepalive if it does not receive a data packet for two hours or more. As per RFC 1122, the client retries keepalive if it does not receive a keepalive response from the peer. It eventually disconnects after continuous retry failure.
The NAT devices typically implement connection caches to maintain the state of ongoing connections. If the size of the connection reaches limit, the NAT devices drops old connections in order to service the new connections. This could also lead to such a scenario.
The given packet capture indicates that there is a high probability that packets are not reaching the client, so it will be helpful to capture packets on client machine.
I read the trace slightly differently:
Sender sends more data than receiver can handle and gets zerowindow response
Sender sends window probes (not keepalives it is way to soon for that) and the application gives up after 10 seconds with no progress and closes the connection, the reset indicates there is data pending in the TCP sendbuffer.
If the application uses a large blocksize writing to the socket it may have seen no progress for more than the 10 seconds seen in the tcpdump.
If this is a straight connection (no proxies etc.) the most likely reason is that the receiving up stop receiving (or is slower than the sender & data transmission)
It looks to me like packet number 249522 provoked the application on 10.120.67.113 to abort the connection. All the window probes get a zero window response from .132 (with no payload) and then .132 sends (unsolicited) packet 249522 with 63 bytes (and still showing 0 window). The PSH flag suggests that this 63 bytes is the entire data written by the app on .132. Then .113 in the same millisecond responds with an RST. I can't think of any reason why the TCP stack would send a RST immediately after receiving data (sequence numbers are correct). In my view it is almost certain that the app on .113 decided to give up based on the 63 byte message sent by .132.
In a TCP connection the end that performs the active close is required to stay in TIME_WAIT state for 2MSL of time. Why exactly does it need to be 2MSL? Many people said that one MSL is for the final ACK and the other MSL is for retransmitted FIN. But, the RTO of FIN is way shorter than MSL, and the FIN doesn't need to wait for an MSL to be retransmitted. So, their explanation doesn't make sense to me. Can anyone present a specific example of how segments are exchanged during that time?
Figure 1. Packet exchange for TCP connection.
Why does the TIME_WAIT state exist?
The book <<UNIX Network Programming(Volume1,3rd)>> give an answer:
There are two reasons for the TIME_WAIT state:
To implement TCP's full-duplex connection termination reliably
To allow old duplicate segments to expire in the network
I think this is also the answer to this question(Why TIME_WAIT state need to be 2MSL long?)
First look at reason 1. In order to reliably terminate the full-duplex connection, suppose that the last ACK sent by the client in Figure 1 is lost, and the server will retransmit the FIN. In order to receive this timeout and retransmitted FIN, the client needs TIME_WAIT Status; does the TIME_WAIT status have to be 2MSL? In fact, this depends on the server-side FIN timeout retransmission time RTO. If RTO is less than MSL, then TIME_WAIT state MSL is enough. If RTO is greater than 2MSL then TIME_WAIT state 2MSL is not enough, so only when RTO is between MSL and 2MSL , Reason 1 for the existence of the TIME_WAIT state is the reason why the time of TIME_WAIT is 2MSL. In fact, in general, RTO is much smaller than MSL, but considering the worst case, RTO is 2MSL, so the TIME_WAIT state is 2MSL to ensure that the worst case can also receive the FIN that is retransmitted over time.
The time of TIME_WAIT is another important reason for 2MSL. Reason 2, in order to ensure that all packets generated during the duration of this connection disappear from the network, that is, to ensure that when a new TCP connection is established, the old duplicate packets from the connection are already in Disappeared from the network. Some people here may have a question: After the client replies to the last ACK, it feels that all packets can disappear with one MSL. Why do all packets of 2MSL disappear? The reason is:
Suppose that the client sends an ACK just after one MSL time, and the server just starts to retransmit the FIN over time before receiving the ACK, so if the FIN disappears, 2MSL is needed.
Let's recall the process
A FIN B
B ACK A
B FIN A
A ACK B
After above 4 steps, A is now at TIME_WAIT stage while B is at LASK_ACK.
What if step 4(A ACK B) is lost?
B will wait for 1 MSL for step 4, yet failed to get it, so B redo step 3, and step 3 will take 1 MSL to reach A. Hence, A has to wait for 2 MSL for a graceful wave goodbyte.
But there is another question, what if step 4 is lost again? :)
I also have the same question about this. I thought of an assumption.
In extreme senario, suppose the last ACK from client end spends MSL to reach server end. At this point, the end point thinks that this ACK has already perished due to MSL timeout. So server end retransmit the FIN imediately. In order to assure this FIN can reach client end (or if not, we have to assure its perishment), we must have another MSL.
The purpose of TIME-WAIT is to prevent delayed packets from one connection being accepted by a later connection. It can happen as:
A connection from (address a, port p) to (address b, port q) is terminated
A second connection from (address a, port p) to (address b, port q) is established
A duplicate packet from the first connection is delayed in the network and arrives at the second connection when its sequence number is in the second connection’s window.
In such cases the endponts have no idea to identify to identify which connection the packet belongs.
The two reasons for the existence of the TIME-WAIT state and the 2SML timer:
If the last ACK segment is lost, the server TCP, which sets a timer for the last FIN (Finish) bit set, assumes that its FIN is lost and resends it. If the client goes to the CLOSED state and closes the connection before the 2MSL timer expires, it never receives this resent FIN segment, and consequently, the server never receives the final ACK. The server cannot close the connection. The 2MSL timer makes the client wait for a duration that is enough time for an ACK to be lost (one SML) and a FIN to arrive (another SML). If during the TIME-WAIT state, a new FIN arrives, the client sends a new ACK and restarts the 2SML timer.
A duplicate segment from one connection might appear in the next one. Assume a client and a server have closed a connection. After a short period, they open a connection with the same socket addresses (same source and destination IP addresses and the same source and destination port numbers). A duplicated segment from the previous connection may arrive in this new connection and be interpreted as belonging to the new connection if there is not enough time between the two connections. To prevent this problem, TCP requires that an incarnation cannot occur unless a 2MSL amount of time has elapsed.
Tcp must prevent old duplicates from a connection from reappearing at some later time and being misinterpreted as belonging to a new the same connection. To do this, Tcp will not initiate a new connection that is currently in the TIME_WAIT state.
The TIME_WAIT state is twice the MSL, this allows MSL seconds for a packet in one direction to be lost, and another MSL seconds for the reply to be lost.
if there is a tcp connection between A and B,
A send some packets and then a TCP RST(or TCP FIN/ACK) to close the connection,
let me say?
PKT1, PKT2, PKT3, TCP_RST
or
PKT1, PKT2, PKT3, TCP_FIN/ACK
but the packet arrival is out of order
PKT1, TCP_RST(or TCP_FIN/ACK), PKT2, PKT3
then how will B react?
according to the sequence number of TCP_RST and TCP_FIN/ACK,
B knows there are some packets missing(PKT2 and PKT3),
will B wait for PKT2 and PKT3 before it close the connection,
or B immediately close the connection when it receives TCP_RST(or TCP_FIN/ACK)?
thanks
The TCP protocol will reorder the packets before sending them further up the stack. This means it will wait for out of order packets according to the sequence number, ask for retransmission if needed, etc. and wait for the last ack before closing the connection.
You can find the TCP state diagram here:
http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html#ST
TCP guarantees sequence. That includes the sequence of the EOS. It must be delivered after all the data.
I use raw socket to create TCP packets, with focus on the sequence number and TCP flags(SYN, ACK)
I used one machine S to send a tcp ACK packet (flag ACK is set to 1) and another machine R to receive it these two machines are in different subnets, all in my school
meanwhile, I used tcpdump to capture the packets.
Strange things happens! On machine S, the captured packet is as expected, it is an ACK packet however, on the receiving machine R, the packet becomes a SYN packet, and the sequence number is changed, the seq no is 1 smaller the expected and the ack_seq become 0!
what are potential problems?
my guess is that the router/firewall modified the ACK packet to a SYN packet because it never sees a SYN SYN/ACK exchange ahead of the ACK?
is it possible or not?
the two captured packets are:
https://docs.google.com/file/d/0B09y_TWqTtwlVnpuUlNwUmM1YUE/edit?usp=sharing
https://docs.google.com/file/d/0B09y_TWqTtwlTXhjUms4ZnlkMVE/edit?usp=sharing
The biggest problem you will encounter will be that the receiving TCP stack in each case will receive the packet and possibly reply to it. What you are attempting is really not possible.
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.