0

I'm not clear why the handshake for WebSocket is HTTP. Wiki says "The handshake resembles HTTP so that servers can handle HTTP connections as well as WebSocket connections on the same port." What is the benefit of this? Once you start communicating over WebSocket you are using port 80 also...so why can't the initial handshake be in WebSocket format?

Also, how do you have both WebSocket and HTTP servers listening on port 80? Or is it typically the same application functioning as HTTP and WebSocket servers?

Thanks y'all :)

allstar
  • 1,155
  • 4
  • 13
  • 29

1 Answers1

1

WebSockets are designed to work almost flawlessly with existing web infrastructures. That is the reason why WS connections starts as HTTP and then switches to a persistent binary connection.

This way the deployment is simplified. You don't need to modify your router's port forwarding and server listen ports... Also, because it starts as HTTP it can be load balanced in the same way that a normal HTTP request, firewalls are more lean to let the connection through, etc.. etc... Last but not the least, the HTTP handshake also carry cookies, which it is great to integrate with the rest of the app in the same way that AJAX does.

Both, traditional HTTP request-response and WS, can operate in the same port. Basiclally the WS client sends a HTTP request asking for "Upgrade:websocket", then if the server accepts the WS connections, replies with a HTTP response indicating "101 Switching Protocols", from that point the connection remains open and both ends consider it as a binary connection.

vtortola
  • 34,709
  • 29
  • 161
  • 263
  • Thanks for your response. So if I understand correctly, while typically it's one application per port, that's not a hard-and-fast rule...it's more due to the way OS APIs are designed? As in this answer: http://stackoverflow.com/a/1694271/1628347. So it's possible to have both HTTP and WS servers running on one machine listening on one port. Why doesn't HTTPS also use port 80 for the same reasons you describe? – allstar Dec 26 '14 at 16:06
  • It is ok to have both in the same port as long it is the same process whom is processing both, because both are somehow HTTP. HTTPS is HTTP over SSL/TLS, meaning that the beginning of the connection is totally different, it will be the SSL/TLS handshake, and then the HTTP matter afterwards, that is why runs in a different port, because the process is not (immediately) expecting a HTTP request at that port. The same happens with ws:// and wss://, they must run in different ports because the same reason. – vtortola Dec 26 '14 at 18:50
  • Don't applications run in different processes? So it has to be the same web server application that handles HTTP and WS, such that it is the same process. – allstar Dec 26 '14 at 19:41
  • "application" is a high level concept, that usually maps to a single process, but it may be several process working together. In Microsoft world, you can run your application with several application domains that are actually different processes, but they are managed in a special way that allows them hang from http.sys, that is the responsible of listening at the IIS configured ports. – vtortola Dec 27 '14 at 00:22