Two popular lower layer protocols that web protocols use called transport layer protocols:
TCP: https://tools.ietf.org/html/rfc793 (1981)
Requires an agreement or a handshake. The advantage is a from of gaurantee in delivery. It is a connection-based stateful protocol. This makes the transmission more reliable, but also more costly and slower.
UDP: https://tools.ietf.org/html/rfc768 (1980)
Compared to TCP, there is no strict requirment or hadshake. Features like, in order delivery, flow control, acknowledgement of receipt are not required. It is connection-less state-less protocol. This makes the transmission less reliable, but it is less costly and faster.
The protocols below rely on some form of lower level transport layer protocols:
HTTP 1.0: https://tools.ietf.org/html/rfc1945 (1996)
It is request-response protocol layered on TCP. The client makes one full request, the server gives one full response, and then the connection is closed. The request methods (GET, POST, HEAD) have specific transactional meaning for resources on the server.
HTTP 1.1: https://tools.ietf.org/html/rfc7231 (1999)
Maintains the request-response nature of HTTP 1.0, but allows the connection to stay open for multiple full requests and full responses (one response per request). Still has full headers in the request and response but the connection is re-used and not closed. HTTP 1.1 also has additional request methods (OPTIONS, PUT, DELETE, TRACE, CONNECT) which also have specific transactional meanings. However, as noted in the introduction to the HTTP 2.0 draft proposal, HTTP 1.1 pipelining is not widely deployed so this greatly limits the utility of HTTP 1.1 to solve latency between browsers and servers.
HTTP long-polling/streaming: https://tools.ietf.org/html/rfc6202
Modification of HTTP (either 1.0 or 1.1) where the server does not respond immediately, or responds partially with headers, to the client request. After a server response, the client immediately sends a new request, using the same connection if over HTTP 1.1. HTTP streaming: https://www.w3.org/TR/eventsource/ A variety of techniques that allow the server to send more than one response to a single client request. The W3C is standardizing this as Server-Sent Events using a text/event-stream MIME type. The browser API (which is fairly similar to the WebSocket API) is called the EventSource API. Comet/server push: Long-poll and HTTP streaming. Comet libraries usually support multiple techniques to try and maximize cross-browser and cross-server support.
WebSockets: https://tools.ietf.org/html/rfc6455
Built-on TCP that uses an HTTP friendly Upgrade handshake. Unlike TCP, which is a streaming transport, WebSockets is a message based transport: messages are delimited on the wire and are re-assembled in-full before delivery to the application. WebSocket connections are bi-directional, full-duplex and long-lived. After the initial handshake request/response, there is no transactional semantics and there is very little per message overhead. The client and server may send messages at any time and must handle message receipt asynchronously.
Google initiated proposal to extend HTTP using a more efficient wire protocol but maintaining all HTTP semantics (request/response, cookies, encoding). SPDY introduces a new framing format (with length-prefixed frames) and specifies a way to layering HTTP request/response pairs onto the new framing layer. Headers can be compressed and new headers can be sent after the connection has been established.
HTTP 2.0: https://tools.ietf.org/html/rfc7540
The aim is to reduce HTTP latency and overhead while preserving HTTP semantics. It is derived from SPDY and defines an upgrade handshake and data framing that is very similar the the WebSocket standard for handshake and framing. An alternate to HTTP 2.0 draft proposal (httpbis-speed-mobility) actually uses WebSockets for the transport layer and adds the SPDY multiplexing and HTTP mapping as an WebSocket extension. WebSocket extensions are negotiated during the handshake.
Competing proposals from Google and Microsfot to allow peer-to-peer connectivity between browsers. This may enable lower average and maximum latency communication because as the underlying transport is SDP/datagram rather than TCP. This allows out-of-order delivery of packets/messages which avoids the TCP issue of latency spikes caused by dropped packets which delay delivery of all subsequent packets to guarantee in-order delivery.
Aimed at reducing latency. QUIC is very similar to TCP+TLS+SPDY implemented on UDP. QUIC provides multiplexing and flow control equivalent to HTTP 2.0, security and connection semantics, reliability, and congestion control equivalentto TCP. Because TCP is implemented in operating system kernels, and middlebox firmware, making significant changes to TCP is next to impossible. However, since QUIC is built on top of UDP, it suffers from no such limitations. QUIC is designed and optimised for HTTP 2 semantics.