Suppose I initiate a TCP connection for HTTP request and response. After the completion of three way handshaking process, I now send a request to the server for a HTTP packet with SYN flag set. The server responses to my request with ACK flag. Upon completion of the response, it will send me a FIN flag. Now how can I determine the size of the packet that the server send me during the request and response? Is there any process to do so?
Suppose I initiate a TCP connection for HTTP request and response. After the completion of three way handshaking process, I now send a request to the server for a HTTP packet with SYN flag set.
No you don't. The SYN was in the first packet sent in the three-way handshake. That's done. At best you will be piggy-backing the HTTP request on the final ACK packet of the connect handshake.
The server responses to my request with ACK flag.
No, the server responds to your HTTP request with an HTTP response. The ACK is irrelevant at the HTTP level.
Upon completion of the response, it will send me a FIN flag.
No it won't, unless you're speaking HTTP 1.0 or you have set the Connection: close header. Otherwise it will keep the connection open for HTTP keepalive.
Now how can I determine the size of the packet that the server send me during the request and response? Is there any process to do so?
The server didn't send you anything during the request. The size of the response body is given by the Content-length header or the sum of the chunked-encoding section sizes if that's used. You need to read the HTTP 1.1 RFC about this, it's non-trivial.
You also need to stop confusing HTTP with TCP. HTTP is an application protocol layered on top.
Related
Below is the configured thread group
Thread Group
|
|--> HTTP SAMPLE
I am opening 5 threads in 5 seconds with loop count is 5. It means in each thread 5 HHTP request will be sent, so total 25 request.
Thread 1 : TCP CONNECTION OPENED --> HTTP REQUEST SENT ---> HTTP RESPONSE RECEIVED.
Question: After receiving response whether TCP connection will be closed and again TCP connection will be opened and then HTTP request will be sent?
Or once response is received in same TCP connection next HTTP request will be sent?
It depends on what do you set in the HTTP Request sampler, if you tick Use KeepAlive box - then JMeter will send Connection header with the value of keep-alive
it means that the underlying TCP connection will remain open and the next HTTP Request sampler(s) will be reusing this connection.
If you untick the box JMeter will send Connection header with the value of close and next HTTP Request sampler will re-establish the connection.
You need to check what's going on in reality using your browser developer tools or an external sniffer tool like Wireshark and configure JMeter to behave exactly like the real browser does
Client connects to server and sends request with keep-alive header. Server response also contains keep-alive header.
Now client loses power. Is there any mechanism (like ping) in TCP or HTTP stack, which tells server, that client is not there (other than timeout)?
Now client loses power. Is there any mechanism (like ping) in TCP or HTTP stack, which tells server, that client is not there (other than timeout)?
There is TCP keep alive which is specifically designed to detect lost connectivity.
HTTP is client - server communication where client always initiates the connection and server responds.
In the client server communication with HTTP 1.1 the following steps takes place:
1. Client sends the request to the server.
2. Server sends the response to the client with the response message and the status code.
My question is how is the data transfer handled in the protocol? I know HTTP is stateless and also it is either everything or nothing mechanism but how do you prove this? How is the handshake between server and client?
For example: When the server sends the response back to the client, what happens if 50% of the data is sent and then there is connection loss...then what will happen in this scenario? Will the client wait for remaining 50% of the message or it will start new transfer where server tries to send 100% of the message again? (In synchronous communication)
HTTP relies on a TCP connection, so in your example if 50% of the data is correctly sent but others packets (yes, you should think in terms of packets) are lost, the data will be sent again following the rules defined in TCP protocol
I have two questions on HTTP Connection close:
If a client sends a HTTP request with Connection: close to HTTP Server, Is it the HTTP Server or client responsibility to send TCP FIN after response is received by client?
If a client sends a bad formatted HTTP request, and server sends a 400 BAD REQUEST, is it best practice to close the connection by server (even though the HTTP request has connection: keep-alive) or is it good practice to keep the connection still active?
Thanks in advance for answering my queries?
When the server receives a 400 Bad Request, it is going to send the response with the keep-alive header because if the client feels like sending another request, then they can use a pre-existing connection (this connection is shut down within a certain amount of time, it has an expiration date). The Keep-Alive Header is more about not saturating the network with TCP connection demands. You basically say "I am going to talk to you, for 2 minutes, whatever you send me, I'll answer you though this connection"
The server is only an object that receives commands from an user. You ask him, he does or not. The TCP FIN is something you send to the server to shut down the connection, but you choose when you don't want to communicate with him anymore. The client transmits the first FIN, and receives an ACK to ensure that the server got it. Then the server launches its own FIN, and waits for the ACK. If everything is okay, you and your server are no longer friends.
I know that, the http clients sends 0x10 0x13 bytes to inform the http server that the request data has finished.
But how the server informs the http clients that the response data has finished? (it sends -1 i.e. <EOF> correct)?
No. HTTP Clients do not send CRLF to the server to indicate that the request is complete, and servers do not send a particular byte sequence to the client to indicate completion. You should read this document: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 to understand how clients and servers are able to determine when a request or response is complete. The short summary is that the Content-Length header, Chunked Transfer-encoding terminator, or TCP/IP connection closure are all used as signals.