WebSockets use the websockets protocol: WS:/example.com/yourscript.js and open a synchronous connection – meaning the connection is held open and dedicated to the browser.
httpd servers, like apache2 (used by most shared hosting providers) use the http protocol: http://example.com/yourscript.js and open an asynchronous connection – meaning that no connection is held open between the server and the browser. (You can prolong open connections, modestly, by setting certain configuration parameters – but generally speaking, it’s asynchronous.)
As you can imagine, maintaining open connections between the browser and the server dedicates more server resources to each browser connection, and is therefore more taxing of server resources than dropping connections after each request. Shared hosting providers are understandably disinclined to support WS on shared hosting.
While certain shared hosts may have mod_python installed, thereby allowing your plugin users to run pywebsocket, pywebsocket’s own documentation clearly state that “pywebsocket is intended for testing or experimental purposes.”
So, while one may imagine a plugin bundling python code to create a pywebsocket server, given an apache server that supports it, I don’t believe it would ever be a reasonable to distribute a plugin that did so.