Protocol used: HTTP 1.1
Header includes 'Transfer-Encoding: chunked'
On sending subsequent requests (same request to the same server), containing 'Transfer-Encoding: chunked', I see new TCP socket being opened for each request.
Should the same socket not be used for requests? Why is the socket being terminated each time?
Note:
Requests sent using fiddler
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
I'm building a HTTP client(for embedded devices) and I was wondering,
If I receive a HTTP 3xx response, and in the location header I get a hostname different from the one I had in the request. Should I disconnect the TCP connection and reconnect to the new host, or I just need to send a new request with a new host header and keep the old TCP connection alive.
Thank you
It doesn't make sense to reuse the original TCP connection if you're being redirected elsewhere. If my webserver only hosts example.com and I redirect you to elsewhere.net, my webserver will probably not respond to a request for elsewhere.net.
Worse, this also potentially sets you up for a great man-in-the-middle attack if my server redirects you to http://bank.com and you reuse the same TCP connection when sending a request to bank.com. My server can maliciously respond to requests with Host: bank.com, which isn't something you want to happen.
You can't assume the original connection can be reused unless the redirect is to the same same host with the same protocol.
Persistent HTTP connections are a little tricky with the number of client/server combinations. You can avoid the complexity by just wasting time closing and re-establishing each connection:
If you're implementing a HTTP/1.0 client, Connection: keep-alive isn't something you have to implement. Compliant servers should just close the connection after every request if you don't negotiate that you support persistent connections.
If you're implementing a HTTP/1.1 client and don't want to persist the connection, just send Connection: close with your request and a HTTP/1.1 server should close the connection.
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.
I noted that fiddler sends "connection:close" header when the client sends a CONNECT request to initiate secure connection along with the "200 connection established" message.
CONNECT request to a forward HTTP proxy over an SSL connection?
As explained in above question, the connection should be kept-alive between the client and the proxy so that the client can subsequently sent the actual request.
Why does fiddler sends the close header? wouldn't the client close the connection because of the header instead?.
Any Connection header in the successful response to the CONNECT request does not make any sense and gets ignored. CONNECT will establish a tunnel, which only ends with the end of the TCP connection. But a Connection header would make sense with an unsuccessful CONNECT, because with close the client would need to start a new TCP connection and with keep-alive (implicit with HTTP/1.1 response) it can reuse it with another request.
Connection: Close means that the connection will be closed after the request completes. Since the request in this scenario only completes when the HTTPS connection is closed, this is exactly the behavior you want for this sort of request.
Arguably, using Connection: keep-alive on a CONNECT request is invalid, since there's no legal way for the connection to be kept-alive after the tunnel is closed.
In http transaction for request and response which scenario is occurred ?
client (web browser) open connection and send it's request and connection open (keep alive) until server accept and answer then close connection ?
client (web browser) open connection and send it's request then connection is closed and server accept and answer and reconnect and send response ?
in http1.0 and http1.1 this scenario is different ?
A server can't directly reconnect to a client. Hence, your scenario #2 is unlikely.
In other words, in the WEB world, "transactions" between a Client Browser and a WEB Server is always "Client Browser Initiated".
Of course, if we are talking about server-to-server communication over HTTP, it is a different story: you can make up your own rules here, provided you control at least one server ;-)
As for the difference between HTTP 1.0 and HTTTP 1.1, I don't know enough.
In both 1.0 and 1,1 connection is kept open until response is sent. Keep alive refers to what happens afterwards.
In HTTP 1.0 server closes the connection after sending the response. Unless client sends and server understands keep-alive header (which was not a part of HTTP 1.0 standard)
In HTTP 1.1 connection is kept open after the response unless client sends Connection: close header.
Details
The scenario is:
The client (browser) opens a connection to the web server and sends HTTP request
The server receives the request and sends back the response to the client (browser)
If keep alive is enabled, the connection will not be closed until the keep alive timeout expires. The idea of keep alive is to use the same TCP connect to send/receive multiple requests/responses.
Persistent connection / Keep alive was officially introduced in the HTTP 1.1 specification. keep-alive was not officially documented in the specification of HTTP 1.0, however, some implementation of HTTP 1.0 supported keep alive connections.
regarding scenario 2: The server never initiate connections with browsers, the browser initiate connections with the server and the server uses the same connection to send back responses.