5 ms·

Should we be expecting in a few years, that web sockets will be advanced enough for us leave HTTP/1.1. behind? Aside from chat/messaging I'm not sure how web so

by marquis 15y ago

Should we be expecting in a few years, that web sockets will be advanced enough for us leave HTTP/1.1. behind? Aside from chat/messaging I'm not sure how web sockets can provide additional functionality from what we have now. Edit: I confused web sockets with SPDY. I have to go read up on what these things actually are.

igrigorik 15y ago
WebSockets is not a replacement for HTTP/SPDY. Don't forget that a WebSocket is effectively an upgraded HTTP / SPDY connection (in fact, there is work in progress to enable WS over SPDY). In many cases, you don't need bi-directional communication.. Which is also why HTML5 spec introduced Server Sent Events (SSE): http://www.igvita.com/2011/08/26/server-sent-event-notifications-with-html5/ http://www.igvita.com/2011/08/26/server-sent-event-notificat...
maratd 15y ago
> Aside from chat/messaging I'm not sure how web sockets can provide additional functionality from what we have now. Ever edit a document with multiple people, at the same time? Much easier with web sockets. Ever get a notification that a new email has arrived the second it arrived? Much easier with web sockets. And yes, there's chat and messaging. There are many more scenarios that will become evident as people start using the tech. It is a step up from XHR.
- marquis 15y ago
  >It is a step up from XHR Thanks, this is the simplification I was after.
- hello_moto 15y ago
  So if someone wants to implement EtherPad or Google Wave, they don't have to write a complex system utilizing Operational Transformation algorithms? Or... don't have to deal with concurrent editing/locking mechanism? WebSockets do that for us?
  - maratd 15y ago
    > WebSockets do that for us? Nope. However, it will allow you to contact any connected client at will from the server-side. Try doing that with XHR without constantly polling the server.
    - pork 15y ago
      What's wrong with long polling and keep-alive connections, handled with evented socket code on the server side? Is it mainly because of the HTTP request overhead?
      - LeafStorm 15y ago
        Pretty much. That, and I don't think you can really send data back to the server over a long-polling connection - if you can, it's a giant hack - but WebSockets is explicitly designed for bidirectionality. SSE, on the other hand, basically is long-polling and keep-alives, but with better defined behavior and a nicer API on the client side.
      - simpsond 15y ago
        There is nothing inherently wrong with long polling, but when you consider the overhead of a small payload (let's say 4 bytes for fun) the HTTP request headers add significant overhead. WebSockets have very little overhead for a 4 byte payload (2-4 bytes depending on masking (4 for the spec)) ... and the latency is less than half. It's just more efficient.
      - igrigorik 15y ago
        With long-polling you have reconnect after every message, which is a very expensive operation (relatively speaking). HTTP headers often form the bulk of the request, and the number of connections you have to maintain is high. All of these things add up. In addition, TCP slow start, window sizing, etc, work against you when it comes to optimizing for latency: http://www.igvita.com/2011/10/20/faster-web-vs-tcp-slow-start/ http://www.igvita.com/2011/10/20/faster-web-vs-tcp-slow-star...
      - maratd 15y ago

by marquis 15y ago

igrigorik 15y ago

WebSockets is not a replacement for HTTP/SPDY. Don't forget that a WebSocket is effectively an upgraded HTTP / SPDY connection (in fact, there is work in progress to enable WS over SPDY). In many cases, you don't need bi-directional communication.. Which is also why HTML5 spec introduced Server Sent Events (SSE): http://www.igvita.com/2011/08/26/server-sent-event-notifications-with-html5/ http://www.igvita.com/2011/08/26/server-sent-event-notificat...

maratd 15y ago

> Aside from chat/messaging I'm not sure how web sockets can provide additional functionality from what we have now. Ever edit a document with multiple people, at the same time? Much easier with web sockets. Ever get a notification that a new email has arrived the second it arrived? Much easier with web sockets. And yes, there's chat and messaging. There are many more scenarios that will become evident as people start using the tech. It is a step up from XHR.

marquis 15y ago
>It is a step up from XHR Thanks, this is the simplification I was after.
hello_moto 15y ago
So if someone wants to implement EtherPad or Google Wave, they don't have to write a complex system utilizing Operational Transformation algorithms? Or... don't have to deal with concurrent editing/locking mechanism? WebSockets do that for us?
- maratd 15y ago
  > WebSockets do that for us? Nope. However, it will allow you to contact any connected client at will from the server-side. Try doing that with XHR without constantly polling the server.
  - pork 15y ago
    What's wrong with long polling and keep-alive connections, handled with evented socket code on the server side? Is it mainly because of the HTTP request overhead?
    - LeafStorm 15y ago
      Pretty much. That, and I don't think you can really send data back to the server over a long-polling connection - if you can, it's a giant hack - but WebSockets is explicitly designed for bidirectionality. SSE, on the other hand, basically is long-polling and keep-alives, but with better defined behavior and a nicer API on the client side.
    - simpsond 15y ago
      There is nothing inherently wrong with long polling, but when you consider the overhead of a small payload (let's say 4 bytes for fun) the HTTP request headers add significant overhead. WebSockets have very little overhead for a 4 byte payload (2-4 bytes depending on masking (4 for the spec)) ... and the latency is less than half. It's just more efficient.
    - igrigorik 15y ago
      With long-polling you have reconnect after every message, which is a very expensive operation (relatively speaking). HTTP headers often form the bulk of the request, and the number of connections you have to maintain is high. All of these things add up. In addition, TCP slow start, window sizing, etc, work against you when it comes to optimizing for latency: http://www.igvita.com/2011/10/20/faster-web-vs-tcp-slow-start/ http://www.igvita.com/2011/10/20/faster-web-vs-tcp-slow-star...
    - maratd 15y ago