http-protocol-connection
Overview
HTTP mostly relies on TCP for its transport protocol, providing a connection between the client and the server. In its infancy(early stage like http1.0), HTTP used a single model to handle such connections. These connections were short-lived: a new one created each time a request needed sending, and closed(server does) once the answer was sent
But in HTTP/1.x, there are several models: short-lived connections, persistent connections, and HTTP pipelining(never used in practice, but the foundation of http2.0(pipeline mode)), The persistent-connection model keeps connections opened between successive requests, reducing the time needed to open new connections. The HTTP pipelining model goes one step further, by sending several successive requests without even waiting for an answer, reducing much of the latency in the network.
short-lived connection
The default one in HTTP/1.0, is short-lived connections. Each HTTP request is completed on its own connection; this means a TCP handshake happens before each HTTP request and these are serialized.
The TCP handshake itself is time-consuming, but a TCP connection adapts to its load, becoming more efficient with more sustained (or warm) connections. Short-lived connections do not make use of this efficiency feature of TCP, and performance degrades from optimum by persisting to transmit over a new, cold connection.
This model is the default model used in HTTP/1.0 (if there is no Connection header, or if its value is set to close). In HTTP/1.1, short-lived model is only used when the Connection header is sent with a value of close.
persistent-connection(keep-alive)
A persistent connection is one which remains open for a period of time, and can be reused for several requests, saving the need for a new TCP handshake, and utilizing TCP’s performance enhancing capabilities. This connection will not stay open forever: idle connections are closed after some time (a server may use the Keep-Alive header to specify a minimum time the connection should be kept open).
Persistent connections also have drawbacks; even when idling they consume server resources, and under heavy load, DoS attacks can be conducted. In such cases, using non-persistent connections, which are closed as soon as they are idle, can provide better performance.
In HTTP/1.1, persistence is the default, and the Connection header is not a must(but it is often added as a defensive measure against cases requiring a fallback to HTTP/1.0).
Conclusion
If server does not allow keepalive(like apache, can be configed), no matter http1.0 or http1.1, server sends response; then (close the connection)FIN, if server allows keepalive, if client sends Connection header, uses the way that client suggested, if client no preference, by default, http1.0 send FIN(no keepalive), http1.1 not FIN(keepalive).
Improved connection management allows considerable boosting of performance in HTTP. With HTTP/1.1 or HTTP/1.0, using a persistent connection at least until it becomes idle leads to the best performance.