HTTP sessions

So far, we've talked about the back and forth of the request/response communication patterns of HTTP, but we've neglected the context that allows that chatter to happen so seamlessly. This fluid interaction is facilitated by an underlying session established prior to satisfying the first request made by a client. Historically, this session has been provided by a Transmission Control Protocol (TCP) connection established against a specific port on the host server. This port can be specified in the URI when designating your target host, but typically will use default ports for HTTP, such as 80, 8080, or 443 (for HTTPS, which we'll cover later in this book). Once the connection is established, round trips of HTTP communication can proceed freely until the session is terminated.

You might have noticed that I specifically said that TCP is historically used for HTTP. This is because, for each of the current versions of HTTP (1.0, 1.1, and now HTTP/2), TCP has been the standard transport layer protocol supporting it. However, in the current proposed specification for HTTP/3, the protocol is being modified to take advantage of alternative transport protocols, including the User Datagram Protocol (UDP), or Google's experimental Quick UDP Internet Connections (QUIC) protocol. While there are trade-offs associated with these alternate transport protocols, the underlying sessions they provide are the same from our point of view. Each of these protocols serve to establish a connection with a listening host and facilitate the transmission of request and response messages. Next, let's take a look at some of the operations a client might request of a server, and how those operations are specified through the HTTP standard by way of request verbs.