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.
Related
I understand that the client and the server are connected after client receives SYN ACK messages from the server during 3 way handshake and sending ACK messages to the Server. After they are connected, when the client sends the other messages to the server, what happens if that messages arrives at the server before the ACK message that client sent when doing the 3 way handshake?
what happens if that messages arrives at the server before the ACK message that client sent when doing the 3 way handshake?
ACK is just the flag in the TCP header together with the sequence number of the latest received data. It can be contained in an empty packet (i.e. no payload, just TCP header) but also in a packet with payload. It does not matter if a specific packet with an ACK is received as long as an ACK covering the data is received at all.
This means it is sufficient if the initial data send by the client cover the final ACK for the TCP handshake. In fact there is not even a need to send a standalone ACK (without payload) from the client at all to finish the TCP handshake but the client can start sending data as soon as the client has received the SYN and ACK from the server.
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.
Which software libraries does exist for such task for Linux, Windows OS?
Does it exist some info in RFC how people should do it?
I'm interesting how can I create functionality for my C++ project like presented here in that software: https://secure.logmein.com/ru/products/hamachi/download.aspx
There is not much difference if you want to make a connection through TURN relay server. The only difference is how TCP and UDP creates connection and nothing else.
There are some big differences if you want to make P2P connection.
If you are in same network(behind same NAT): In UDP you send a stun binding request to your peer candidate and then if you get a response back then you know you are connected. Same in TCP you have to create one active socket on one side and one passive socket on another. And then send syn from active socket and receive it from passive socket and then send syn ack to the active socket. And then active socket send an ack and the connection is established.
If you are in different Network(behind different NAT): You have to employ TCP hole punching technique for making a connection. Because your NAT won't allow a TCP syn packet through if previously no packet was sent to the address the syn is coming from.
TCP hole punching in details:
You have to use a TCP simultaneous open socket. This socket acts in both active and passive mode. Both end needs to know each others private and public IP:Port.
TCP simultaneous open will happen as follows:
Peer A keeps sending SYN to Peer B
Peer B keeps sending SYN to Peer A
When NAT-a receives the outgoing SYN from Peer A, it creates a mapping in its state machine.
When NAT-b receives the outgoing SYN from Peer B, it creates a mapping in its state machine.
Both SYN cross somewhere along the network path, then:
SYN from Peer A reaches NAT-b, SYN from Peer B reaches NAT-a
Depending on the timing of these events (where in the network the SYN cross),
at least one of the NAT will let the incoming SYN through, and map it to the internal destination peer
Upon receipt of the SYN, the peer sends a SYN+ACK back and the connection is established.
From WIKI.
Also to learn about TCP simultaneous open connection read from here. To learn about NAT filtering behavior see this answer.
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.
Connect function returns after sending the last ACK(3rd segment of 3-way handshake of initiating TCP connection). What happens if this 3rd segment is lost because listen is still waiting for ACK at server but there is no one at client to send that ACK again ?
If the client sends its ACK with a data packet, and it gets lost, the client will notice that the data hasn't been ACKd by the server and resend the packet.
If the client sends its ACK in a separate packet, and it gets lost, the server will notice that the SYN/ACK hasn't been ACKd by the client and resend the packet. Client will respond by resending the ACK.
Whether the application's connect call is still blocking at that time doesn't matter, since the ACKing is done by the OS's TCP/IP implementation.