Web protocols
HTTP and HTTPS: stateless request and response messages (a method, a target, header fields, a status code) that browsers, APIs, proxies and CDNs all understand.
How they work
HTTP defines one set of semantics (RFC 9110) and three ways to put it on the wire. HTTP/1.1 sends text messages over TCP, one at a time per connection. HTTP/2 frames them in binary and interleaves many on one TCP connection. HTTP/3 does the same over QUIC, so one lost packet no longer stalls every request. A request looks the same in all three: a method such as GET or POST, a target, header fields and an optional body, answered with a status code such as 200 or 404.
HTTPS is HTTP inside TLS. An https URL defaults to TCP port 443 instead of 80, the client checks that the server’s certificate is valid for the host name before sending anything, and everything after the handshake is encrypted and protected against tampering. A site can also send Strict-Transport-Security, after which browsers refuse to talk to it over plain HTTP.
Because each HTTP message can be understood on its own, intermediaries can reuse connections and spread requests across servers, which is why load balancers, caches, CDNs and API gateways are built around it. Use HTTPS for anything that leaves one machine; keep plain HTTP for local testing and for redirecting to HTTPS.