Is there a way to keep idle connection open after a specified timeout at the server side?
I have a http server implemented using golang1.4 and an API will respond after 10 seconds. While I set MaxIdleConnsPerHost at the client (using golang1.4), I still get the read tcp xx.xx.xx.xx:xx: use of closed network connection. I think it may be caused by server closing the idle connection.
I found GOLANG, HTTP having “use of closed network connection” error and http.Server: timeout for idle connections only?, but they didn't help.
At the server side, set ReadTimeout may help.
Ref: Creating an idle timeout in Go?
Related
I'm implementing HTTP over TLS proxy server (sni-proxy) that make two socket connection:
Client to ProxyServer
ProxyServer to TargetServer
and transfer data between Client and TargetServer(TargetServer detected using server_name extension in ClientHello)
The problem is that the client doesn't close the connection after the response has been received and the proxy server waits for data to transfer and uses resources when the request has been done.
What is the best practice for implementing this project?
The client behavior is perfectly normal - HTTP keep alive inside the TLS connection or maybe even a Websocket connection. Given that the proxy does transparent forwarding of the encrypted traffic it is not possible to look at the HTTP traffic in order to determine exactly when the connection can be closed. A good approach is therefore to keep the connection open as long as the resources allow this and on resource shortage close the connections which were idle (no traffic) the longest time.
Clients connect to my Nginx instance with the keep-alive of 15s. I set worker_shutdown_timeout to 30s, and server keep-alive to 90s.
When I send -HUP signal or using Nginx -s reload to my instance. It creates new workers and immediately shuts down old workers. This causes my clients to get 499 EOFs.
Any idea what am I doing wrong?
Keepalive connections are closed immediately regardless of the worker_shutdown_timeout value, as clients are expected to re-open them as needed. The worker_shutdown_timeout applies to connections with actual requests being processed - these requests will be terminated when shutdown timeout expires.
If your clients cannot handle keepalive connection being closed by the server, probably there is room for improvement in the client code.
I've been playing around with an http server I'm creating using boost::asio (hence the c++ tag).
With HTTP/1.1 the default is to keep the clients connection open for more than 1 request/response.
My question is:
How long should I keep a client connection open? Should I use a deadline_timer which closes the connection after some arbitrary amount of time?
Or, should I just wait for the underlying socket receive timeout to expire? At which point my receive handler will be invoked with an EOF error prompting me to remove the client connection from my list of connections.
Furthermore, if this is specified in an RFC document, which one?
I understand that http2 uses one tcp connection to serve multiple requests, for example, if I request index.html which contains a.css and a.js, these three requests will be done in one tcp connection.
What happens if user clicks index2.html? does this request still use the same previous tcp connection? If so, will the browser keep the connection open until user closes the browser? And on the server side, does the server keep many connections open all the time?
When using HTTP/2, browsers typically open only one connection per domain.
In your example, index2.html will be sent on the same TCP connection that was used for index.html, a.css and a.js.
In HTTP/2 requests are multiplexed on the same TCP connection, so that the browser can send them concurrently, without waiting for a previous request to be responded to.
Both browsers and servers have an idle timeout for TCP connections.
If the connection is idle for long enough, it will be closed by either party - the one that has the shorter idle timeout, to save resources.
For example, you may open a connection to a wikipedia.org, perform a few requests, and then leave that tab and work on something else.
After a while (typically 30 seconds) the browser will close the TCP connection to wikipedia.org.
On the server side, the server will keep the connections from various clients open, until they are either closed by the client or until the server-side idle timeout fires, at which point it's the server that initiated the close of the TCP connection.
With HTTP/2, the number of connections that a server has to maintain is vastly less than it was with HTTP/1.1.
With HTTP/2, a server has to maintain just 1 TCP connection per client; with HTTP/1.1, the server had to maintain typically 2-8 TCP connections per client.
What happens if user clicks index2.html? does this request still use the same previous tcp connection?
Yes. On top of that, multiple browser tabs/windows also share a single HTTP/2 connection.
If so, will the browser keep the connection open until user closes the browser?
Below from RFC - connection management
For best performance, it is expected that clients will not close
connections until it is determined that no further communication with
a server is necessary (for example, when a user navigates away from a
particular web page) or until the server closes the connection.
Clients SHOULD NOT open more than one HTTP/2 connection to a given
host and port pair.
And on the server side, does the server keep many connections open all the time?
Servers are encouraged to maintain open connections for as long as
possible but are permitted to terminate idle connections if necessary.
When either endpoint chooses to close the transport-layer TCP
connection, the terminating endpoint SHOULD first send a GOAWAY
(Section 6.8) frame so that both endpoints can reliably determine
whether previously sent frames have been processed and gracefully
complete or terminate any necessary remaining tasks.
More info on connection error below.
RFC connection-error-handling
A connection error is any error that prevents further processing of
the frame layer or corrupts any connection state. An endpoint that
encounters a connection error SHOULD first send a GOAWAY frame with
the stream identifier of the last stream that it successfully received
from its peer. The GOAWAY frame includes an error code that indicates
why the connection is terminating. After sending the GOAWAY frame for
an error condition, the endpoint MUST close the TCP connection. It is
possible that the GOAWAY will not be reliably received by the
receiving endpoint. In the event of a connection error, GOAWAY only
provides a best-effort attempt to communicate with the peer about why
the connection is being terminated.
An endpoint can end a connection at any time. In particular, an
endpoint MAY choose to treat a stream error as a connection error.
Endpoints SHOULD send a GOAWAY frame when ending a connection,
providing that circumstances permit it.
On http persistent there is a "keep alive" timer.
When the keep alive time is over , what happend?
the tcp connection will close? i don't think so because there is keep alive on tcp connection that exsist.
so what is the affect of "keep alive http timer"?
If i open http connection to url (TCP) on port 80 ,
the port of server will not be free until the tcp connection will end.
so what if the http keep alive end?
I tried to understand that .
i will be happy if i get an official source to this .
thanks!
On http persistent there is a "keep alive" timer.
Correct. Don't confuse it with TCP keepalive, which is a completely different thing (RFC 1122). I am here assuming you are talking about HTTP as per your text.
When the keep alive time is over, what happened?
The connection will be closed by one peer or the other.
the tcp connection will close?
Correct.
I don't think so because there is keep alive on tcp connection that exist.
I don't know what this means.
so what is the affect of "keep alive http timer"?
It closes open HTTP connections when the specified period of inactivity has expired.
If i open http connection to url (TCP) on port 80 , the port of server will not be free until the tcp connection will end.
Incorrect. You can open many connections to the same listening port.
so what if the http keep alive end?
The connection is closed. You've already asked that.
I will be happy if I get an official source to this.
The official source for HTTP 1.1 is RFC 7230-5, the successors of RFC 2616.
TCP level keepalive is done out of band, so there is no stream data associated with this. This means applications using sockets don't see the effect of TCP keepalives, so an idle connection will still be closed by an http server or proxy.
Also, the interval for sending TCP keepalives is typically very long by default (hours). You can find more information on the keepalive socket option here on MSDN
HTTP doesn't allow a server to attempt to prompt a client to do something, so if the client doesn't use a connection, the only option is to close it or leave it open. That is typically a configuration option in the server or proxy.