Home/ Questions/Q 8321915
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-08T23:11:21+00:00

I am trying to learn more about websocket and its internal implementations. But still

  • 0

I am trying to learn more about websocket and its internal implementations. But still can’nt understand few things. I tried googling for a in-depth explanation, but most of them just gives the high-level overview. Following are my doubts

1. According to what I read, web socket server (C# / C++ implementation) by default uses port 80. Although we can use any port, it’s preferred that we use port 80 as we won’t have any firewall issues. If that’s so, how are we supposed to run both the webserver and web socket server on the same port (80)?

2. Let’s assume that the web socket server is running on port 81 and webserver is running on port 80.

  1. So when the browser issues the initial handshake HTTP request (Upgrade: websocket) , this request sent to port 81. Right? If so, this request (See below) does’nt have any relation to an HTTP protocol. But still we use HTTP protocol headers. Why?

           GET /mychat HTTP/1.1
       Host: server.example.com
       Upgrade: websocket
       Connection: Upgrade
       Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
       Sec-WebSocket-Protocol: chat
       Sec-WebSocket-Version: 13
       Origin: http://example.com

  2. Why dint they use the same websocket interface currently implemented in most browser to issue a direct TCP/IP connection with the given port, without any HTTP stuff?

3. Is there any packet size limit or data/buffer limit for data sent/received from client/server? If that’s the case, do we need to frame the data and handle it ourselves?

4. Does the websocket server always needs to be a separate service/process? In future will the webserver’s (IIS, apache) will include support for hosting web socket servers within its process space?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    1. By using an HTTP compatible handshake you can integrate a WebSocket handler into your webserver or just have the webserver forward the websocket connection to a dedicated WebSocket server.

    2. The WebSocket handshake uses an HTTP compatible handshake to allow both protocols to be handled easily on the same port and it allows existing firewall configurations to much more easily support WebSocket traffic. In addition, preventing cross-side script attacks in well understood in the context of HTTP requests and so WebSocket leverages that knowledge. Even after the connection is established, WebSocket is not a raw socket connection. It is a message based protocol and therefore requires framing. In addition, the framing is masked when sent from client (browser) to server in order to alleviate fears of a theoretical vulnerability in misbehaving proxies/caches/intermediaries.

    3. There is no limit on message size in the protocol itself. A message can be split into multiple frames. There is a protocol limit to frame size but it’s 2^64 bytes. The actual frame size limit will be smaller depending on client/server implementation. If you have multi-megabyte single messages that you want to send you might consider changing your application to use smaller messages to maximize cross-browser and cross-server support.

    4. WebSocket handling can definitely be integrated into web servers and this was very much a scenario envisioned by the working group. For example, consider pywebsocket which is designed to run both standalone or as a mod_python module in Apache. As another example, ASP.NET 4.5 and IIS 8 will have built-in support for WebSockets.

    • 0