Why achieving real time connection was difficult with HTTP protocol.
As HTTP is implemented over TCP connection which is reliable and continuing the persistent connection should be easier . right?.
How Web Sockets solves this persistent connection problem?
Prior to HTTP/2, HTTP/0.9 and HTTP/1.x were just command+response protocols only. A client would send a command, the server would send a reply, done, nothing more. And prior to HTTP/1.1, keeping the TCP connection alive after each response was impossible in HTTP/0.9 and not common practice in HTTP/1.0. HTTP/1.1 standardized that practice.
So it was very difficult to implement any kind of persistent real-time bi-direction communications over HTTP until recent years. Sure, various technologies were devised to try to address this (long polling, server-side pushes, etc), but nothing was really widely accepted and put into common practice across all implementations.
Then WebSockets came along, which was specifically designed for persistent bi-directional communications, in such a way that was easy to add to existing HTTP infrastructures so server admins didn't have to re-invest in new technologies, while maintaining backwards compatibility with older HTTP systems that can't/won't support WebSockets.
Then HTTP/2 came along, which now has server pushes and multiplexing built right in to the HTTP protocol, solving many of the shortcomings of old HTTP versions, and covers some of the use-cases that WebSockets were being used for, but doesn't obsolete Websockets completely.
HTTP has a very long history of evolution to get to where it is today. Evolution takes time.
Related
As modern systems, especially for micro-services, connection pooling for HTTP client is quite often deployed. But with the QUIC + TLS1.3, it seems like to me that connection pooling would be useless as there is support for 0-RTT in QUIC.
Is any QUIC expert available to share more on this topic?
It's still valid, because:
a 0-RTT request is more computentionally expensive on both the client as well as the server side than just reusing the connection, since all private key crypto operations and certificate checks still apply
0-RTT requests can introduce security issues due to providing a chance for replay attacks (see https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-34#section-9.2). Without using the 0-RTT feature a QUIC handshake still requires 1-RTT.
However since QUIC already provides multiplexing multiple requests on a stream the client should not be required to keep a full pool of connections around. A single connection is typically sufficient, as long as the server advertises being able to support a high enough number of streams.
that's the question.
Dose anyone know?
I wonder If I could develop a UDP protocol based application to enhance service response.
There is a reason HTTP uses TCP. TCP provides reliability, e.g. no lost, no duplicate and no reordered data. This features are necessary, so that you don't get any broken content back from the server and no broken uploads. Of course you can re-implement this in UDP - but I doubt that you will have improved response time compared to TCP when you are done.
Imagine I'm building an ordinary old website. Not a game, not a chat program, an ordinary website. Let's say it's a stack overflow clone.
The client side would simply make service calls to the server side. The server is essentially a dumb data store and never sends down HTML. The client handles all templating via javascript.
If I established a single websocket connection and did all requests through that, would I see a significant speedup over doing ajax requests?
The obvious advantage to using a single connection is that it only has to be established once. But how much time does that actually save? I know establishing a TCP connection can be costly, but in the grand scheme of things, does it matter?
I would not recommend websockets for webpages. HTTP 1.1 can reuse a TCP-connection for multiple requests, it's only HTTP 1.0 that had to use a new TCP connection for each request.
SPDY is probably a protocol that do what you are looking for. See SPDY: An experimental protocol for a faster web, but it's only supported by Chrome.
If you use websockets, the requests will not be cached.
One HTTP connection can only by used for one HTTP request at the same time. Say that a page requested a 100Kb document, nothing else will be send from the client to the server until that 100Kb document has been transferred. This is called head-of-line blocking. The client can establish an additional connection with the server, but there is also a limit on the amount of concurrent connections with the same server.
One of the primary reasons for developing SPDY and later HTTP/2 was solving this exact problem. However, support for SPDY and HTTP/2 is not yet as widespread as for WebSocket. WebSocket can get you there earlier because it supports multiple streams in full-duplex mode.
Once HTTP/2 is better supported it will be the preferred solution for this problem, but WebSocket will still be better for real-time web applications, where server needs to push data to the client.
Have a look at the N2O framework, it was created to address the problems I described above. In N2O WebSocket is used to send all assets associated with a page.
How much speed you could gain from using WebSocket instead of standard HTTP requests pretty much depends on your specific website: how often it requests data from the server, how big is a typical response, etc.
I've been working with websockets lately in detail. Created my own server and there's a public demo. I don't have such detailed experience or knowledge re: http. (Although since websocket requests are upgraded http requests, I have some.)
On my end, the server reports details of each hit. Among them are a bunch of http keep-alive requests. My server doesn't handle them because they're not websocket requests. But it got my curiosity up.
The whole big thing about websockets is that the connection stays alive. Then you can pass messages in both directions (simultaneously even). I've read that the Keep-Alive HTTP connection is a relatively new development (I don't know how many years in people time, just that it's only included in the latest standard - 1.1 - is that actually old now?)
I guess I can assume that there's a behavioral difference between the two or there would have been no reason for a websocket standard? What's the difference?
A Keep Alive HTTP header since HTTP 1.0, which is used to indicate a HTTP client would like to maintain a persistent connection with HTTP server. The main objects is to eliminate the needs for opening TCP connection for each HTTP request. However, while there is a persistent connection open, the protocol for communication between client and server is still following the basic HTTP request/response pattern. In other word, server side can't push data to client.
WebSocket is completely different mechanism, which is used to setup a persistent, full-duplex connection. With this full-duplex connection, server side can push data to client and client should be expected to process data from server side at any time.
Quoting corresponding entries on Wikipedia for reference:
1) http://en.wikipedia.org/wiki/HTTP_persistent_connection
2) http://en.wikipedia.org/wiki/WebSocket
You should read up on COMET, a design pattern which shows the limits of HTTP Keep-Alive. Keep-Alive is over 12 years old now, so it's not a new feature of HTTP. The problem is that it's not sufficient; the client and server cannot communicate in a truly asynchronous manner. The client must always use a "hanging" request in order to get a message back from the server; the server may not just send a message to the client at any time it wants.
HTTP vs Websockets
REST (HTTP)
Resources benefit from caching when the representation of a resource changes rarely or multiple clients are expected to retrieve the resource.
HTTP methods have well-known idempotency and safety properties. A request is “idempotent” if it can be issued multiple times without resulting in unique outcomes.
The HTTP design allows for responses to describe errors with the request, with the resource, or to provide nuanced status information to differentiate between success scenarios.
Have request and response functionality.
HTTP v1.1 may allow multiple requests to reuse a single connection, there will generally be small timeout periods intended to control resource consumption.
You might be using HTTP incorrectly if…
Your design relies on a client polling the service often, without the user taking action.
Your design requires frequent service calls to send small messages.
The client needs to quickly react to a change to a resource, and it cannot predict when the change will occur.
The resulting design is cost-prohibitive. Ask yourself: Is a WebSocket solution substantially less effort to design, implement, test, and operate?
WebSockets
WebSocket design does not allow explicit or transparent proxies to cache messages, which can degrade client performance.
WebSocket protocol offers support only for error scenarios affecting the establishment of the connection. Once the connection is established and messages are exchanged, any additional error scenarios must be addressed in the messaging layer design, but WebSockets allow for a higher amount of efficiency compared to REST because they do not require the HTTP request/response overhead for each message sent and received.
When a client needs to react quickly to a change (especially one it cannot predict), a WebSocket may be best.
This makes the protocol well suited to “fire and forget” messaging scenarios and poorly suited for transactional requirements.
WebSockets were designed specifically for long-lived connection scenarios, they avoid the overhead of establishing connections and sending HTTP request/response headers, resulting in a significant performance boost
You might be using WebSockets incorrectly if..
The connection is used only for a very small number of events, or a very small amount of time, and the client does not - need to quickly react to the events.
Your feature requires multiple WebSockets to be open to the same service at once.
Your feature opens a WebSocket, sends messages, then closes it—then repeats the process later.
You’re re-implementing a request/response pattern within the messaging layer.
The resulting design is cost-prohibitive. Ask yourself: Is a HTTP solution substantially less effort to design, implement, test, and operate?
Ref: https://blogs.windows.com/buildingapps/2016/03/14/when-to-use-a-http-call-instead-of-a-websocket-or-http-2-0/
I have two servers running in iis on different computers and they need to communicate with each other. Because of firewalls etc http is the only real option. It's bidirectional communication, not just request/response. Web sockets would be good, but the spec for that isn't finished so I'm wondering if there are any other options I should look at?
I would spend a few minutes thinking about wether my communication could actually be done using request response, a lot of times you can convert your communication into request response. HTTP is really very request response based so you kind of have to hack around it using various comet techniques like long polling. If you have control over both ends of the communication then there is no reason not to use web sockets even if the standard isn't settled upon. So long as you agree with yourself how it should be implemented complying with the final standard isn't important.