16

Won't that HTTP header also cause the connection to remain open for a long time? So what is the advantage?

Can anyone please clarify for me? I seem to have missed the concept, I think.

malana
  • 5,045
  • 3
  • 28
  • 41
Muhammad Umer
  • 2,228
  • 2
  • 18
  • 17
  • Links that helped me: http://stackoverflow.com/questions/10028770/html5-websocket-vs-long-polling-vs-ajax ------- http://stackoverflow.com/questions/11077857/what-are-long-polling-websockets-server-sent-events-sse-and-comet – Muhammad Umer Jul 13 '13 at 07:06
  • "For example in node.js you can share same memory for different socket connections, so that way they can access shared variables. So you don't need to use database as exchange point in the middle (like with AJAX or Long Polling and for example PHP). You can store data in RAM, or even republish between sockets straight away." – Muhammad Umer Jul 21 '13 at 23:07
  • http://stackoverflow.com/questions/10028770/html5-websocket-vs-long-polling-vs-ajax – Muhammad Umer Jul 21 '13 at 23:09

1 Answers1

16

At the TCP/IP level it looks the same: a socket is open.

But from the browser point of view they are completely different. The keep-alive is for the browser to re-use to request more content (e.g. images, css files, next page on the site). WebSockets is for two-way communication from within your Javascript application code. The server can choose to send content at any time. Your JS application can send data to the server at any time.

Also worth comparing to SSE (aka EventSource), which also allows the server to choose to send content at any time, but is one-way (your JS application has to resort to using XHR when it needs to send more data). (A full comparison of WebSockets and SSE can get very complex, so I'll say no more here, except to say that SSE can often be the correct choice.)

Also compare to Server Push in HTTP/2 (aka SPDY). This is for the server to proactively push files (images, css files, next page on the site), but it is at the browser-level again, not controlled from Javascript.

Darren Cook
  • 27,837
  • 13
  • 117
  • 217
  • SO you are saying that in content:keep alive server sends data only when browser requests it. Which it's requesting continuously as the connection is open while in web socket browser doesnt have to request server can send when it wants to. ANd you can manually request/tell server to send if need be. – Muhammad Umer Jul 12 '13 at 20:50
  • I don't think the browser will be "requesting continuously". (Though if you had a javascript loop that loaded a new image every second, then I suppose it would be kept busy.) Also remember that http/1.1 will typically make 6 connections to a server if there is a lot of content to fetch. (I realize your question was theoretical, but very long keep-alive times are almost certainly going to be a bad idea, overall.) – Darren Cook Jul 13 '13 at 03:40
  • I think i got it, even in long polling/http.. for client to communicate with server it needs to send http req. Server may though talk to client. But connection times out and has to be connected unnecessarily eventually. But i see people saying that websocket let more clients share space. How does that work. – Muhammad Umer Jul 13 '13 at 07:05
  • @MuhammadUmer Re: "people saying that websocket let more clients share space", I'm not sure what it means. Do you have a link or something? – Darren Cook Jul 15 '13 at 23:44
  • i read that in php each open connection uses one thread and that is the size of 2mb. What about websocket. – Muhammad Umer Jul 21 '13 at 23:07
  • 1
    To make comparisons like that you'll need to be more precise in what you are comparing; and also what you are optimizing for (memory?). As I answered, a keep-alive http connection from browser to server is serving a different purpose, so comparisons are a bit weird anyway. But, if your websocket server is a PHP instance then it is using a thread and 2MB (or whatever) too. – Darren Cook Jul 21 '13 at 23:42