I have a question about the TCP's three way handshake - Why there are three messages before the connection start? Why does the server reply with another seq_num after the first message from the client?
Thanks!
So that the client knows the connection has been accepted, and
So that a sequence number for the direction server -> client had been established, as it's a full-duplex connection, i.e. with independence on each direction.
Related
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.
I understand that in the three-way handshake, sometimes the receiving end will send a SYNACK packet when establishing a connection (piggybacking), but when would it ever send a SYN and then an ACK packet?
For example:
->SYN
<-SYN_ACK
->ACK
versus:
->SYN
<-SYN
->SYN_ACK
Thanks!
No it won't - here's the reason why
SYN is typically sent by the 'client' (eg. your browser) when it wants to open a TCP connection to a server (eg. your web server). A server has no way of 'knowing' beforehand which client wants to open a connection (and hence send a SYN) to it. So it cannot send an unsolicited SYN.
SYN and ACK are flags, so the SYN-ACK from server is an ACK to the client's SYN (and it's own SYN). Technically, it can send them separately, but, sending SYN and ACK separately would involve additional half round trip. 'cos then it would be a four way handshake ((c)SYN -> , <- SYN(s), <-ACK(s), (c)ACK ->) that doesn't achieve any more reliability than three way handshake offers. Consequently it makes no sense to do that way.
Having said so you could theoretically design a protocol with 4 way handshake, but TCP isn't designed so.
Hope that helps.
Four-way handshake connection termination can be reduced to three-way and even two way one. Is it possible the three-way handshake connection establishment would be extended to four-way?
SYN=>
<=ACK
<=SYN
ACK=>
Given the semantics of SYN and ACK it should be possible to send SYN+ACK in different packets and those delay the handshake. E.g. client sends a SYN, server replies with an ACK to acknowledge the wish of the client for a new connection, but it does not grant the wish yet. Later the server sends a SYN and gets the matching ACK back from the client and the connection is established. But I doubt that anybody does connection establishment this way and it might be, that some OS will croak on it.
But, there is another scenario for a four-way-handshake, however with a different ordering of the packets. It could happen, if both side try to establish a connection to the other side at the same time, e.g. both send a SYN to the peer, and get an ACK back. It is described in the RFC 793 (TCP) section 3.4. But I doubt you will ever see such a handshake, because it does not fit into the typical client-server-scenario where one end is waiting for connects and the other end does the connect.
Edit: the handshake you envision exists and it is called "split handshake". See http://hackmageddon.com/2011/04/17/tcp-split-handshake-attack-explained/ . And like I expected, it is not universally supported.
I am sending HTTP requests from IP_ADDR1 to IP_ADDR2. I observed that HTTP requests are not reaching to application level. When I take wireshark logs I noticed some issue at TCP level. What are these issue? when this occurs ? How to get rid of this? Attaching the Wireshark snapshot here.
'TCP port number reused' means that it saw a successful connection handshake, then the client sent another SYN packet with the same port numbers. If the client hadn't already acknowledged the SYN-ACK, this would have been reported as a retransmission. But since it did acknowlege the SYN-ACK, it shouldn't need to retransmit the SYN. This could mean that something on your network is duplicating packets.
'TCP out-of-order' means that the packets aren't being received in the order that their sequence numbers indicate. It might be a side effect of the duplicate packet that's causing the reused port number error -- that may be resetting the sequence numbers back to the beginning of the connection. Because otherwise it looks like the packet is in order; an HTTP command should be the next thing after the connection handshake.
I'm troubleshooting some communications issues and in the network traces I am occasionally coming across TCP sequence errors. One example I've got is:
Server to Client: Seq=3174, Len=50
Client to Server: Ack=3224
Server to Client: Seq=3224, Len=50
Client to Server: Ack=3224
Server to Client: Seq=3274, Len=10
Client to Server: Ack=3224, SLE=3274, SRE=3284
Packets 4 & 5 are recorded in the trace (which is from a router in between the client and server) at almost exactly the same time so they most likely crossed in transit.
The TCP session has got out of sync with the client missing the last two transmissions from the server. Those two packets should have been retransmitted but they weren't, the next log in the trace is a RST packet from the Client 24 seconds after packet 6.
My question is related to what could be responsible for the failure to retransmit the server data from packets 3 & 5? I would assume that the retransmit would be at the operating system level but is there anyway the application could influence it and stop it being sent? A thread blocking or put to sleep or something like that?
Only one packet has been lost from server to client - packet 3. Packet 6 contains a selective acknowledgement (SACK) for packet 5, so that got through.
In answer to your specific question, no, application-level issues shouldn't prevent TCP retransmissions.