In real-time applications, it goes without saying that there is a need to fetch information from the server as soon as it is available. And, fundamentally, the classic HTTP 请求/响应schema isn't up to the job. Because the server will remain silent regardless of new data unless or until the consumer requests an update.
请求/响应This limitation led to various hacks and workarounds (some of which became official and widely adopted) as developers attempted to adapt models to the needs of the more dynamic real-time web.
All of these techniques and approaches, from Comet to HTTP long polling, have one thing in common: essentially, they start to create the illusion of true real-time (event-driven) data exchange/communication, so when the server has some new data, it sends a response.
Although HTTP is not an event-driven protocol, and thus not truly real-time, these methods are actually quite effective in specific use cases, such as Gmail chat. However, problems arise in low-latency applications or large-scale applications, mainly because of the processing requirements associated with HTTP.
That is, with HTTP it is very resource intensive to have to constantly request updates (and get responses): client establishes connection -> requests updates -> gets response from server, then closes connection. Imagine this process being repeated endlessly by thousands of concurrent users, which is very taxing on the server.
It was these issues that eventually led developers Michael Carter and Ian Hickson to develop WebSockets, essentially a thin transport layer built on top of a device's TCP/IP stack. Its purpose is to provide web applications with what is essentially a TCP communication layer, as close to native as possible, forbidding some abstractions to remove some security-based complexities and other concerns.
请求/响应 This article will look at some of the techniques used to circumvent the limitations of HTTP mode in real-time applications , some of the associated issues with each technique, and how WebSockets can help overcome these issues.
HTTP
HTTP is essentially a protocol 客户端-服务器in the computing model 请求/响应and is the primary means of communication for the World Wide Web. The original version, proposed by Tim Berners-Lee in 1989 as an application protocol, was very limited and was quickly revised to support a wider range of browser and server capabilities.
Although HTTP/1.0 is not considered a formal specification or Internet standard, these modifications were finally documented as HTTP/1.0 by the HTTP Working Group in 1996 ( RFC 1945 ).
HTTP/1.1
The arrival of HTTP/1.1, the most widely supported version in web browsers and servers, was a big step forward as it implemented some very important optimizations and enhancements, from persistent and piped connections to new request / response header field . Chief among these are two headers that are the basis for many improvements that contribute to a more dynamic live web:
Keep-Alive 标头: Used to set up persistent communication between hosts. Meaning the connection can be reused for multiple requests, which significantly reduces request latency so that the client doesn't need to renegotiate the TCP handshake (3-way handshake) connection after sending the first request. Another positive side effect is that connections get faster over time due to TCP's slow start mechanism. Before HTTP/1.1, a new connection had to be opened for each request/response pair.
Upgrade 头: Used to upgrade the connection to an enhanced protocol mode (such as WebSockets).
HTTP polling
HTTP polling represents an advancement of the classic request/response mechanism, and although there are many versions of polling, only long polling is in any case suitable for real-time WEB programs.
For example, HTTP short polling uses an AJAX-based timer to ensure that client devices send server requests at regular intervals. However, the server will still respond to each request immediately, either by providing new data or by sending an " empty " response without new data, before closing the connection . So this isn't really of much use in a real-time application when the client needs to respond as soon as new data is available.
It's this limitation that led to the development of HTTP long polling, which is essentially a technique designed to emulate the functionality of server push.
Essentially long polling is a technique where the server chooses to keep the client's connection open for as long as possible (typically 20 seconds), delivering a response only after either data becomes available or a timeout threshold is reached.
The main advantage of long polling is that, in theory, new information will be sent to the client as soon as it is available. The downside, however, is the additional overhead of processing HTTP requests.
HTTP streaming
HTTP streaming is a push data transfer technique that allows a web server to continuously send data to a client over a single HTTP connection that is kept open indefinitely. Essentially, the client issues an HTTP request and the server issues a response of indeterminate length.
However, while HTTP streaming is performant, easy to use, and a viable alternative to WebSockets, it has limitations. From a real-time perspective, the main problem is that the intermediary can interrupt the connection (whether through a timeout or simply because it serves multiple requests in a "round-robin fashion"), so real-time is not always guaranteed.
HTTP/2.0
HTTP/2.0 evolved from SPDY, an experimental protocol originally announced by Google in 2009. By 2015, the HTTP Working Group published HTTP/2.0 as a proposed standard, using the SPDY specification as a starting point.
It is essentially a performance update aimed at improving the speed of web communication, with two main useful features:
-
Multiplexing : Instead of transmitting data in clear text, the data is encoded as binary and encapsulated within frames, which can be multiplexed along bidirectional channels called streams, all over a single TCP connection. This allows many parallel request/response to happen at the same time
-
Server push : Server push is a performance feature that allows a server to send a response to an HTTP/2 compliant client before the client requests a response. This is useful when the server knows that the client needs to "push" the response to fully process the original request.
Despite these advances, today's explosive growth in Internet traffic due to the heavy use of mobile devices makes it difficult for HTTP/2.0 to provide a smooth, transparent web browsing experience, especially with the growing demands of real-time applications and their users.
advantage
-
All browsers support the HTTP/2 protocol over HTTPS by installing an SSL certificate.
-
HTTP/2 allows clients to send all requests concurrently over a single TCP connection, theoretically allowing clients to load resources faster.
-
TCP is a reliable, stable connection protocol.
shortcoming
-
Concurrent requests increase the load on the server. HTTP/2 servers can receive requests in large batches, which can cause requests to time out. The problem of server load spikes can be solved by using a load balancer or proxy server to limit forwarding requests.
-
Server support for HTTP/2 priorities is immature. Software support is still evolving and some CDNs or load balancers may not support priorities correctly.
-
HTTP/2 push functionality can be difficult to get right.
-
HTTP/2 solves the HTTP head-to-tail blocking problem, but blocking at the TCP level can still cause problems.
HTTP/3.0
HTTP/3.0 is a new iteration of HTTP that has been in development since 2018, and although it is still a draft standard, some browsers already support it, such as Chrome.
The goal of HTTP/3 is to provide fast, reliable, and secure web connections on all forms of devices by solving the transport-related problems of HTTP/2. To do this, it uses a different transport-layer networking protocol called QUIC, which runs over User Datagram Protocol (UDP) instead of TCP like other earlier versions.
However, HTTP/3 has started to have some potential problems, such as:
-
Transport Layer Impact : Transitioning to HTTP/3 involves changes not only at the application layer, but also at the underlying transport layer. Therefore, adoption of HTTP/3 is more challenging than its predecessor.
-
Reliability and data integrity issues : UDP is generally suitable for applications where packet loss is acceptable because UDP does not guarantee that packets will arrive in order. In fact, it does not guarantee that packets will arrive, so if data integrity is important to your application instance and you are using HTTP/3, you will have to build in mechanisms to ensure message ordering and complete arrival.
advantage
-
The introduction of a new (different) transport protocol QUIC running over UDP means theoretical and currently experimental latency reductions.
-
Since UDP does not perform error checking and correction in the protocol stack, it is suitable for use cases where these are not required or performed in the application. UDP is often used in time-sensitive applications, such as real-time systems, which cannot wait for packets to be retransmitted, so some dropped packets can be tolerated.
shortcoming
-
Transport Layer Impact : Transitioning to HTTP/3 involves changes not only at the application layer, but also at the underlying transport layer. Therefore, adoption of HTTP/3 is more challenging than its predecessor.
-
Reliability issues : UDP applications tend to lack reliability and must accept that there will be some degree of packet loss, reordering, error or duplication. It is up to the end-user application to provide any necessary handshaking, such as real-time acknowledgment that a message has been received.
-
HTTP/3 is not yet fully standardized.
WebSockets
For a detailed introduction to WebSockets, please refer to " Deep Learning WebSockets Concepts and Practices ".
WebSockets allow servers and clients to push messages at any time without any relationship to previous requests. A significant advantage of using WebSockets is that almost every browser supports WebSockets.
WebSocket solves some HTTP problems:
-
Two-way protocol : client/server can send messages to each other (in HTTP, requests are always initiated by the client and responses are handled by the server)
-
Full-duplex communication : The client and server can communicate with each other simultaneously and independently.
-
Single TCP connection : After upgrading the HTTP connection at the beginning, the client and server communicate through the same TCP connection (persistent connection) during the entire life cycle of the WebSocket connection, which saves server resources and bandwidth very well.
advantage
-
WebSocket is an event-driven protocol, which means it can be used for true real-time communication. Unlike HTTP (where updates must be constantly requested), with websockets updates are sent as soon as they are available.
-
WebSockets keep a single persistent connection open while eliminating the latency issues that come with HTTP request/response based approaches.
-
WebSockets generally don't use XMLHttpRequest, so no headers are sent every time you need to get more information from the server. This in turn reduces the data load sent to the server.
shortcoming
-
When the connection is terminated, WebSockets will not automatically recover. This is a mechanism that needs to be implemented in application development, and it is also one of the reasons why there are many client-side open source libraries.
-
Browsers older than 2011 cannot support WebSocket connections, which is now negligible.
Summarize
In general, in the context of real-time, constant communication, WebSockets will be the better choice.
HTTP-based technologies tend to be more resource-intensive on the server, while WebSockets have a very small footprint on the server. At the same time, methods like long polling also require multiple hops between server and device, and these gateways often have different limits on how long a connection is allowed to remain open.
If there is a need for long connections, continuous updates, and real-time data interaction in the project, WebSockets should be preferred for construction.