We all know that HTTP is connectionless. After a request-response, the connection is torn down. It remembers the "state" based on cookies supplied by the browser.
Is this the case with HTTPS also? Since it works over TLS/SSL, is the connection persistent? Will my system have an established connection to port 443 of the server for the entire duration when I am interacting with the website? If yes, then is it not too much of an overhead for the server to maintain a lot many connections at a time?
I was reading this tutorial and was a bit confused by what it explains.
02 Answers
We all know that HTTP is connectionless
No, HTTP is stateless. It still runs on top of a connection-oriented transport (typically TCP), but it does not assign any state to that particular connection. The client is free to re-use the same connection for multiple requests (as many HTTP/1.1 clients do), or to create a brand new connection for each request (as HTTP/1.0 clients used to do).
(HTTP itself is neither connectionless nor connection-oriented, because maintaining connections the job of transport protocols. TCP, SCTP, QUIC are connection-oriented transports, while UDP is connectionless. Some application protocols associate state with the underlying connection; some carry all relevant state in their own packets.)
Is this the case with HTTPS also? Since it works over TLS/SSL, is the connection persistent?
Both regular HTTP and TLS-based HTTPS still use the same transport (TCP), and both handle connections the same way. TLS is only an extra layer in-between HTTP and TCP.
Will my system have an established connection to port 443 of the server for the entire duration when I am interacting with the website?
Most web browsers will reuse the same 1-2 connections to request all necessary resources, but will close them a few minutes after those connections become idle.
2http and https are connectionless in much the same way - they are, except when they arn't. HTTPS just wraps some encryption around the stream.
Both can work 1 request per tcp connection and both can allow you persist connections.
Certainly https overhead is a concern, (and you are right that there is more back-and-forth for https ) if you are doing volume, but I guess thats what reverse proxies are for.
