I don't fully understand when a TCP connection ends. That is, when a client sends a request to a server and the server responds, is that response part of the same TCP connection? Or is that response made through a brand new TCP connection?
A TCP connection ends when both sides have closed it. A response is sent over the same connection as the request, and there can be many request/response pairs over a single connection. Or none, just a download for example.
Related
By definition, HTTP pipelining is a technique in which multiple HTTP requests are sent on a single TCP connection without waiting for the corresponding responses, according to Wikipedia, and some other resources. What is meant by TCP connection, is it the connection that starts when the client and server first communicate doing the 3 way handshake? Is it the same TCP stream? TCP stream meaning that the client and server communicate with each other using the same combination of ports.
Im trying to write a server client program, where client sends request through UDP socket to a server, then server responds back to a client through TCP socket.
My question is, how can server establish a TCP connection back to a client after getting the request through UDP?
I'll add code parts on Monday, but I more interested in pseudocode for that. Does that mean that the client should listen on tcp port after sending udp request? So confused
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.
What is happening to a TCP connection after
an end of an HTTP session?
for example, after loading a static webpage from a webserver
Thanks
A HTTP session usually refers to the server is keeping an association to a specific user and could potentially be of any length (using, for instance, cookies as association tokens).
A HTTP session therefore usually contains multiple TCP sessions. For non persistent HTTP connections, every request has its own TCP session (and is closed after). For persistent HTTP connections on the other hand, multiple HTTP resources could be fetched wihtin a TCP session and either side will close it upon a reached timeout threshold on either side.
Wikipedia article on Persistent HTTP connections (Keep-Alive: true)
You can have several HTTP request in one TCP connection. So it if you refer a HTTP session as a set of HTTP requests/responses, the TCP connection will be closed.
At TCP level the closing side sends a packet with the FIN flag set, the other side acknowledges this with ACK, and immediately or eventually does his own FIN, which the first acknowledges again with ACK. It's also possible that the connection is abandonded with the RST instead of FIN flag. The port that sent the first FIN goes into the TIME_WAIT state. This is used to reject packets that arrive subsequently, that would otherwise be misinterpreted as packets of a new connection. After the timeout the port goes from the TIME_WAIT state to the CLOSED state.
Edit: Normal termination is indicated by the FIN flag.
TCP Stream in a tcp dump off a remote network segment showed proper handshake and conversation up to the 8s mark followed by a 20s delay where no packets were sent from either client or server. Server send sent FIN,ACK followed shortly by client's ACK and then RST packets. Why wouldn't the client send a FIN? And is FIN,ACK the proper response for a session timeout from the server's side?
The RST means that the client had already closed the connection.
The FIN means that the server closed the connection. It's one reasonable response to a timeout.