I'm extremely excited about html5's websockets spec but I have a concern.
These days everyone is operating off of some network, with routers (wired/wireless) that have built in firewalls, windows has a built in firewall too.
With that in mind when the server attempts to connect back to the browser that started the websocket handshake will it fail for the vast majority of users? (most people have no idea how to set up port forwarding on their routers)
Or is my thinking incorrect and it will go through fine?
I'm not an expert (so please check to confirm) but I believe there will be an UPGRADE mechanism where a regular HTTP connection can be made, then upgraded to a WebSocket, so no existing firewall rules interfere unless they are doing aggressive application level packet inspection. Connections are still initiated by the browser.
HTML 5 WebSockets don't require port forwarding. Connections continue to be established from the client, but the client and server asymmetry disappears once the connection is established. WebSockets also punch through proxies by using the same CONNECT mechanism that HTTPS uses today.
Since firewalls typically simply enforce the rules for inbound traffic rejection and outbound traffic routing (usually through the proxy server), there usually are no specific WebSocket traffic-related firewall concerns.
Proxy servers (and to some extent, certain load balancing routers as well) are a different matter though (See Why don't current websocket client implementations support proxies?)
来源：https://stackoverflow.com/questions/1967943/will-html5-websockets-be-crippled-by-firewalls