Assume the scenario that TCP client(A) sent SYN to the TCP Sever(B) and then TCP Client disconnected from the network, here TCP Server will be in the state SYN-RCVD how that TCP Server will know that Client is not reachable??
will TCP Server retransmit SYN+ACK ??
(Aif yes, How many times Server will retransmit SYN+ACK??
if no, How much time Server will remain in SYN-RCVD state??
will TCP Server retransmit SYN+ACK ??
Yes
How many times Server will retransmit SYN+ACK??
Depends on OS configuration.
In Linux:
/proc/sys/net/ipv4/tcp_synack_retries
In windows: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxConnectResponseRetransmissions
How much time Server will remain in SYN-RCVD state??
Until the last retransmit of SYN-ACK timeouts.
Usually over 3 minutes.
Related
I am using a simulator. in this simulator when a client sends a tcp syn request to a server and server responds it with RST packet (when the requesting port is close) the same client sends tcp syn retransmission to the same server (and the same port) for four times. i want to know real networks do the same? i mean in real networks if a client sends a tcp syn to a server and recieve RST , do that client sends tcp syn retransmission to that server for four times?
It totally depends on the client implementation. If you program a client to respond to a server's RST with a SYN 4 times, then that's what it will do. It might be that the server is sending an RST because it's detecting a SYN flood (if you keep on sending SYNs unsuccessfully, eventually heuristics will class it as such).
You may want to play with Scapy so you can easily write the client for these kinds of questions.
I have a server with multiple clients. The simulated network is in heavy congestion. What I found is that the server reset some TCP connections after received the ACK segment of three-way handshake. But it doesn't happen when the network is in good condition.
What I found is that the ACK of three-way handshake is received about 3.5s later than the SYN-ACK.
Is that because the three-way handshake SYN-ACK time-out? If SYN-ACK time out, why not resend SYN-ACK.
Thank you for any suggestions.
This looks like related to SYN cookies.
SYN cookies
When a Linux host receives too much SYN traffic, it activates the SYN cookies mechanism.
When SYN cookies is enabled, a server answers to SYN by issuing a SYN-ACK segment with specific data encoded in the TCP sequence field. In that field it encodes the timestamp, the MSS and a cryptographic hash of the two endpoints (local and remote IPs and ports) plus the timestamp.
This is done so that the server does not have to store anything about the connection at this point, it simply send the answer and forget about it.
Then, when the client answer with its ACK, the server checks the hash in the ack field (the ack of the client is the sequence of the server). If it is correct, it creates the connection with the data stored in the field.
SYN cookies explain why the server does not resend SYN-ACK packets when they timeout.
But, why the reset after receiving the ACK?
Maybe clients (or server) are behind a NAT that modifies ports and the NAT also gets congested, so that it cannot link the final ACK to the previous SYN, and assigns a new source port. When the server receives it, it resets the connection (it does not matter if SYN cookies are enabled or not).
Or maybe the server process is not accepting connections at the same speed they are arriving, the kernel queue has filled and newer ones are discarded that way.
In the process of 3 way hand-shaking between a client and a server, what will happen in the following scenarios? Thanks.
Lost (control) packets:
What happen if SYN lost? client vs. server actions
What happen if SYN+ACK lost? client vs. server actions
What happen if ACK lost? client vs. server actions
Duplicate (control) packets:
What does server do if duplicate SYN received?
What does client do if duplicate SYN+ACK received?
What does server do if duplicate ACK received?
What happen if SYN lost?
It is retransmitted by the client if it hasn't been acknowledged by the server with a SYN-ACK.
What happen if SYN+ACK lost?
The SYN is retransmitted by the client if it hasn't been acknowledged by the server with a SYN-ACK.
What happen if ACK lost?
The SYN-ACK is retransmitted by the server if it hasn't been acknowledged by the client with an ACK.
What does server do if duplicate SYN received?
It retransmits the SYN-ACK.
What does client do if duplicate SYN+ACK received?
It retransmits the ACK.
What does server do if duplicate ACK received?
Nothing.
when a TCP client wants to establish a tcp connection with a tcp server
it needs to send SYN and then ACK
while tcp server only sends SYN/ACK
so they are different
but , after the 3_way handshaking,
is this connection symmetric, namely, are TCP client and server in equal status
for example, after the 3-way handshake, usually the client send packet first,
can TCP server send packet first?
No, the procedure is not different at all, but instead of sending a SYN then an ACK in two different packets, the servers concatenate them by sending them via a single packet!
In the other hand, remember always that the client/server nomenclature is relative. The server is the party that remains in listening mode, while the client is the party that initiates the connection ...
After the establishment of the connection, both parties are equivalent (same status as you said: ESTABLISHED). For that reason, both can send the FIN statement to close the connection ...
After the connection is established, both ends are indeed "symmetric". Who sends first is decided by the underlying protocol and differes amongst them.
For example, HTTP starts with the GET <path> HTTP/1.0 command, while other protocols let the server give a greeting line first, and only then the client sends its request.
So in general, both ends are free to send their stuff first.
The SYN packet has the same source dest IP address & port with the established connection, so what will happen in this case?
The server will silently drop the packet since it already has a connection in the ESTABLISHED state, one of the four values from (client-ip, src-port, server-ip, dest-port) must be different for the new SYN to be accepted.
The server will attempt a new connection.
in tech terms it will send a syn,ack packet and wait for the client to finish the tcp handshake
and open the connection.
http://en.wikipedia.org/wiki/Transmission_Control_Protocol
will explain the process alot better than me.
the server will send some information to identify the connection in its syn,ack packet.
and that information is used to keep that connection seperate from others.
Most the time, the ports will not be the same
but when it is, it can cause problems with low grade nat routers,
They try to rewrite that ports that are used, and can get the connections confused.