HTTP

TCP/IP versus QUIC over UDP

TCP/IP

Data on the internet is managed and transmitted by a stack of network protocols that are collectively referred to as TCP/IP. Each layer in the stack can be mapped to layers in the OSI model and each has a different function. HTTP is part of the application layer and allows different applications to communicate with one another. It uses TCP to establish sessions between a client and a server. TCP is part of the transport layer in the stack. It divides messages into data packets at their source which are then reassembled at their destination. IP in the acronym TCP/IP is the protocol that directs packets of data to a specific computer via an IP address. IP is part of the network layer in the stack.

UDP

TheoreticallyHTTP could use an alternative transport layer protocol to TCPlike UDPbut HTTP almost always uses TCPwhich is connection-based and more reliable than UDP. It is favored by applications where the data must be reliablerelevantand completefor example a news story. UDP is a connectionless protocol and cannot retransmit lost data packets. HoweverUDP is faster than TCP and is often used in applications like video conferencing and streaming where small transfer hiccups are barely noticeable. Howeverthe most recent draft version of HTTPHTTP/3addresses some of the issues in TCP and UDPcombining features from two protocols: HTTP/2 and QUIC over UDP. HTTP/3 is also called HTTP-over-QUIC.  

QUIC

QUIC is a network protocol that functions as an alternative to a combination of TCPTransport Layer Security (TLS)and HTTP/2. It is implemented on top of UDP. QUIC transports HTTP/3 traffic over UDP more quickly and efficiently than older HTTP versions that use TCP. QUIC reduces connection latencyimproves congestion controlallows multiplexing without head-of-line blockingenables forward error correctionand allows connection migration. QUIC is fully encrypted with TLS 1.3 by default. UDP is a connectionless protocolso one of the main functions of QUIC is to ensure connection reliability by allowing the retransmission of packetsfor example.

HTTP versions

HTTP/09 (1991)

The first version of HTTP only included the GET request method and had no headersmetadata such as content typeor status codes. Because HTTP/09 did not use headersonly HTML pages (hypertext) could be returned to the client. After a response from the server was receivedthe client immediately closed the connection. HTTP/09 isfor the most partdeprecated but some popular web servers like nginx still support it.

HTTP/1.0 (1996)

HTTP/1.0 supported GET and POST methods and added versioning information and status codes. Headers were introducedwhich allowed a content type to be specified so that files other than HTML could be transmitted. After a response from the server was receivedthe client immediately closed the connection. The introduction of headers in HTTP/1.0 made HTTP very extensible.

HTTP/1.1 (1999)

When a request for a web page is madethe page must be rendered in multiple partsfor example text content and other content like images or videos. Imagevideoand audio files have their own URLsand each file must be requested separately. In HTTP/1this meant multiple individual requests had to be made to the server and multiple connections had to be initiated. HTTP/1.1 introduced persistent connections and pipelining. A persistent connection is not closed by default after a request is made. Pipelining means successive requests in a transaction can be made by a client without waiting for an answer from the server. Persistent connections and pipelining allowed for hypertext and other files like images to be sent successively from the server to the client over a single connection with reduced latency. HTTP/1.1 also allowed additional methodslike DELETEPUTand TRACE. This version introduced caching supportclient cookiesencoded transfersand content negotiation. Content negotiation allowed the server and client to select the most suitable content to exchange in terms of languageencodingor content type. HTTP/1.1 also made HTTP standardization more consistent and is currently the most widely used HTTP version.

HTTP/2 (2015)

Based on SPDYHTTP/2 is a deprecated communications protocol developed by Google to reduce web page loading latency and to improve security. It was designed to improve web performance and cut costs as HTTP/1.1 was expensive in terms of its use of CPU resources. HTTP/2 introduced advanced multiplexingwhich is the ability to efficiently stream data from multiple resources in a single session using HTTP frames and HTTP streams. This feature was introduced to address HTTP head-of-line blocking issues in HTTP/1.1 and to enable parallel communication over a single TCP connection. HTTP head-of-line blocking refers to the scenario where successive requests in a stream can be blocked if there is a problem with the current request in the queue or if it has not yet been completed.

While HTTP/1.1 requests and responses are in text formatHTTP/2 frames use binary format.

HTTP/2 binary frames break down a message request into separate logical unitslike header frames and data frameseach of which is encoded in binary and shares a common HTTP stream ID. An HTTP/2 stream is a singlebidirectionallogical request that comprises multiple frames. In HTTP/2multiple streams can be sent (multiplexed) over a single TCP connection to a server which then maps the frames by their stream ID and reassembles them into complete HTTP/2 request messages according to a predetermined message priority. Multiplexing allows multiple requests to take place over one connection and the server may also send multiple responses to the client in the same way. This feature prevents head-of-line blocking at the application layer and improves performance.

HTTP/2 also introduced better error handling and flow controland server push. Server push means the server can send data to the client that was not explicitly requestedfor example resources the server intuits may be needed by the client. It will first notify the client what it intends to push and the client may decline.

According to W3TechsHTTP/2 is used by about 46 percent of websites. It is not compatible with previous HTTP versions.

HTTP/3 (2019)

The third version of HTTPHTTP/3is designed to improve the performance of HTTP/2 and addresses some HTTP/2 issues. HTTP/3 uses UDP at the transport layer instead of TCP. Head-of-line blocking at the TCP layer in HTTP/2 is resolved by the use of UDP. TCP head-of-line blocking refers to the scenario whereif a packet is losta message is blocked until the packet can be retrieved. HTTP/3 allows faster connections as it does not rely on IP addresses. It uses connection IDs so that downloads are consistent even when there is a network change. Unlike TCPUDP does not require that a data transfer is confirmed before the next request is transmitted. Connections are also faster because fewer data packets need to be sent over parallel streams. To establish a connectionTCP uses a three-way handshake. UDP creates a connection in one round trip. Because TLS 1.3 is integrated into HTTP/3it only supports encrypted (HTTPS) connections.

Main features of HTTP

Extensible

Headers make HTTP extensible as client and server may agree to add any new field names and information to suit their needs.

Stateless

Although it canan HTTP server is not required to store any information between requests. This feature made early HTTP versions stateless. Requests in versions before HTTP/2 were made independently without any knowledge of what happened in previous requests. HTTP was designed as a stateless model mainly for scalability; HTTP requests can be routed to any server because the server does not need to maintain a particular state for a client. This makes it easy to scale the number of servers to match the expected workload where maintaining a persistent connection would be resource intensive. When it is necessary to interact with a website in a progressive wayfor example when online shoppingHTTP may use cookiesserver-side sessionsURL rewritingor hidden variables to enable stateful sessions These workarounds are called stateful functions. Another advantage of statelessness is that the amount of data that needs to be transferred in most cases is minimized.

The full TCP/IP stack is not stateless. TCP at the transport layer is statefulmaintaining the state of an HTTP session and ensuring that lost data packets can be retransmitted.

Connectionless

HTTP is generally considered connectionless becauseafter the client has established a connection with a serversent a requestand received a responsethe connection is immediately dropped. HTTP is also considered connectionless because network connections are controlled at the transport layernot at the application layer. HTTP uses TCPwhich is connection basedat the transport layer.

Media independent

As long as both the client and the server know how to handle specific data content as specified by the MIME-type in a headerany type of data can be sent via HTTP. MIME stands for Multipurpose Internet Mail Extensions.

Where is HTTP used?

HTTP is used on the web wherever data needs to be transferred between a client and serverfor example APIsweb servicesand browser requests.

HTTP is usually used by users that do not have any confidential information that they have to worry about being hackedwho do not wish to purchase an SSL certificateor who do not want the complexity of maintaining a secure site.

How does HTTP work?

HTTP sessions

Early versions of HTTP were stateless but not sessionless. Typicallyan HTTP session has three stepswith some variation in how the steps are handled in different versions.

Firstthe client establishes a connection to the server. In most versions of HTTPthis is a TCP connectionbut HTTP/3 uses UDP at the transport layer.

Secondthe client sends a request message to view a web pagefor example. A request method in the message specifies the action that the server needs to take. For exampleto view a web pagethe client will use the GET method.

Thirdthe server processes the request and returns a response message to the clientfor example the content of the requested web page if the request was successfuland a status code.

In HTTP versions before HTTP/1.1the connection was closed after the completion of a request by default. If the client wanted the connection to be kept openit had to specify that by enabling the Keep-Alive Connection header. HTTP/1.1 and subsequent HTTP versions allow the client to send additional request messages and the connection is kept alive by default. Soif a client receives an error codeit might want to retry the request. If the client wants the connection to be closedit must be specified with the Close Connection header.

Between the client and server are numerous other servers called proxieswhich are intermediaries that perform additional functions like encrypting contentcaching and compressing dataload balancingloggingand providing shared connections for concurrent users.

HTTP message format

HTTP messages are exchanged in a MIME-like format. MIME is a standard for internet mail that enables the format of message requests to be extended to support data other than plain ASCII text. MIME-like headers in HTTP have a similar function; for examplethey allow a client to select the appropriate application to open files other than textlike videoimagesexecutablesaudioetc.

HTTP requests and HTTP responses use the same message format. Messages consist of a start line (either a request line in the case of a request message or a status line in the case of a response message)one or more optional header fieldsan empty line that indicates there are no more header fieldsand an optional message body.

The start line includes the protocol version and some information about either the type of requestin the case of a request messageor the success or failure of the requestin the case of a response message.

HTTP headers allow the inclusion of additional information about the request or response such as the request method in the case of request messages and the length of the returned content in the case of response messages.

The optional message body in a request may include the information that needs to be uploaded to or deleted from a server. The optional message body in a response may include the content requested by the client.

HTTP headers

The use of headers is what makes HTTP flexible and extensible as a clientand a server may create new headers relevant to a transaction as long as they both agree on the format.

Some HTTP headers are specific to request or response messagesfor example the Accept-Language header is specific to request messages. Howeversome headers may either appear in requests or responses. For examplethe Content-Type headercategorized as a representation headermay be included in request or response messages. In the formerit specifies what type of content the client wants. In the latterit specifies what type of content the server is returning.

Request headers may include additional information about the client and the resource. For examplethe Uniform Resource Identifier (URI) is the resource upon which the method needs to act to get information from a specific websitefor example. HTTP request headers may also specify information about what data should be cachedgeneral connection informationauthentication detailsdate and timetransfer encoding informationin what format information can be used to transfer contentetc.

Accept request headers – like Accept-language and Accept-encoding – and some complementary representation headers – like Content-Language and Content-Encoding – allow the content negotiation feature of HTTP. The Accept headers specify the client’s preferences and complementary representation headers in the response specify what the server actually returned.

Response headers may include additional information about the server and the resource. They may also specify any cookiesthe length of the returned contentthe type of contentwhen the content was last modifiedetc.

There are special headers for numerous HTTP functions like authenticationconnection typesstoring cookiesdownloading filesproxy managementsecuritytransfer encodingetc.

HTTP alternatives

HTTP is a request-response model for network communication. Its counterpart is the publish-subscribe model in which a server (also called a broker) receives and distributes data while the client either publishes data to the server to update it or subscribes to the server to receive information. In the publish-subscribe modeldata is automatically exchanged but only when it changes or if the information is new. MQTT is an example of a transport protocol that uses publish-subscribe.

Web Real-Time Communication (WebRTC) is used to perform peer-to-peer (P2P) connectionswhich allow the easy sharing of application data and media files like audio and video. Facebook Messenger is an example of an application that uses WebRTC.

QUIC uses TCP but is built on top of UDP. QUIC was designed to reduce latency in internet data transfers and to address some HTTP/2 issues. Google Chrome is an example of an application that uses QUIC.

The InterPlanetary File System (IPFS) is a recent alternative to HTTP that has a distributed P2P architecture and allows a choice of TCPQUICor WebRTC connections. With its distributed architectureit was designed to resolve server failure issues that are common to centralized network communication protocol models like HTTP.

Advantages of HTTP

• The latest versions of HTTP have numerous performance featuresincluding flexible caching optionsrequest pipelining to increase throughputoptional data compressionand the capability to send partial content. Sending partial content allows a client to request information about the contentlike its sizewithout receiving the body of the content.
• Using a MIME-type header allows a client to download programsextensionsor add-ons that may be necessary to open different file types such as a video file or PDF document. The file type is sent to the client before the file itselfso the client can download the necessary application beforehand.
• Because web pages are a mixture of different elements – like textvideoimagesaudioetc. – HTTP/2 and subsequent versions allow parallel connections to download different elements concurrently.
• HTTP is simple and user friendly – it is written in plain text that is easy to follow. It can assign IP addresses to recognizable and easily remembered names for websiteswhich helps commercial websites engage the public.
• Because HTTP is statelessit does not need to manage sessions at the application layer and is therefore very scalable.
• Because it may use fewer TCP/IP connectionsHTTP versions as of HTTP/1 reduce network congestion. The use of fewer connections also reduces memory usage.
• Because handshaking immediately takes placea connection is establishedand latency is reduced as no handshaking is required for subsequent requests in HTTP/3.

Disadvantages of HTTP

• HTTP is inherently unsecure because it does not use encryption. A hacker could view all the content. For businessesHTTP is not viable as it puts customers’ personal information at risk. With HTTPthe identity of the client and server are not verifiedcould be spoofedand the integrity of a message cannot be proved.
• There is an overhead with early HTTP versions (pre-HTTP/1.1) in using multiple connections to transmit a web page that may include multiple elements like textimagesaudioetc.
• IoT devices require a lot of memory to support older versions of HTTP.
• Mobile is not optimized for older versions of HTTP.
• HTTP is not SEO friendly.

HTTP versus HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is basically HTTP with encryption; it “wraps” HTTP messages in an encrypted format. HTTPS uses Transport Layer Security (TLS) to encrypt HTTP requests and responses.

HTTP and HTTPS use different ports. CustomarilyHTTP uses port 80 and HTTPS uses port 443 althoughin theoryany port can be used except for those that are reserved for specific services.

The primary advantage of using HTTPS is the improved security. For websites that do not transfer confidential informationHTTP could be an acceptable option and less complex to set up and maintain. In additionin 2014Google announced that it would be using HTTPS as a lightweight ranking signal to encourage businesses to switch from HTTP to HTTPS.

There are some subtle andin practiceminor disadvantages in using HTTPS instead of HTTP. Firstthere may be some extra overhead when transferring data as some handshaking must be done first. Secondthe process of generating encryption keys may keep the server from performing other tasks. Thirdsome content cannot be cached locally because the data is encrypted.

By defaultHTTP/3 is only available with HTTPS.