My Site mainly Requires Web-Sockets.

The origins of HTTP were essentially ‘sessionless’. This meant that with a server always listening on Port 80, a client could request one URL at a time, in response to which the server would return the page in question directly to the client’s port number. This included the CGI-scripts’ FORM data. But as the early Internet evolved, Web-sites started to become ‘session-aware’. I explained this to my friends in the past as follows:

The client connects to the assigned port number 80 on the server, and requests a session, which causes the server to start listening on another port number, this forming a ‘session socket’. The one listening on port 80 was the ‘server socket’. The server’s session socket was dedicated to one client and to one session.

My friends did not acknowledge this description of how TCP works, I think mainly, because I did not use the right terminology. What I had referred to as a ‘session socket’, is officially termed a “Web-Socket” in the case of HTTP. It turns out that with an Apache server, many sub-processes can bear these Web-Sockets. They don’t exclusively exist in order to output Web-pages at a faster rate, in response to individual requests made by the clients, to the process still listening on port 80.

One fact to know about my site, is that for such purposes as viewing this blog, the use of Web-Sockets is required. In the case of certain other sections of my site, such as, the use of Web-Sockets is not required, because those Web-pages exist mainly in a sessionless way – they can be fetched one at a time without error.

Certain proxy-servers will not allow a Web-Socket to get forwarded. These are logically also proxies which don’t allow SSL connections to be forwarded, because the encrypted SSL data is also sent via Web-Sockets or their equivalent. If you are connecting to the Internet via such a proxy, I’m afraid you won’t be able to navigate my blog correctly. I apologize for this, but there is little I can do about that. I think that you should still be able to fetch a single posting of mine, that comes up through a search engine.


(Edit: ) This may also apply if you’re trying to connect to my IPv6 address, because my IPv6 is being provided by a Teredo proxy, which might have just assigned reduced privileges to my client:

Previous Post


About Tor and Multi-Protocol Port Numbers.

On a past occasion I had tried to write on Facebook – of all places – that each computer, and therefore each IP Number, has seemingly arbitrary Port Numbers that it receives packets to, primarily to prevent most connection attempts from being futile. I.e., I was stating that there is an official, assigned port number, for most types of protocol that devices communicate with over the Internet. Yes, There Are Many More types of protocols, than just those for HTTP (80), HTTPS (443), POP, SMTP, IMAP, etc..

But this proclamation of mine just serves to remind, that no matter how hard we try to convey the truth, we only end up with approximations.

It’s possible for one server-program to listen on one port number, and to accept requests for a number of protocols – all on the same port number.

One example where this happens, is with proxy-servers. Typically, they might be listening for HTTP connections, let’s say on port 8118. But then the next question people might ask when setting up their browsers could be: ‘I like sending my regular HTML text through a proxy, let’s say to filter it, but I must also forward my HTTPS requests through a proxy – or not – And one might not want to send all the browser’s data through a single SOCKS5 port, just so that the proxy-server can do some differentiation. Therefore, where should I tell my browser to forward my HTTPS traffic?’

And in most cases, the answer would be through port 8118 again .  And that’s because a typical HTTP proxy, reacts to an HTTPS request, via a CONNECT instruction, which means that it treats the encrypted data as gibberish, and then either lets it through or not so. It’s not strictly necessary for a proxy server to analyze traffic, in order to be able to forward it. Yet, there can exist some HTTP proxies, whose feature just to accept a CONNECT command has been disabled. But you can in some cases just try them out.

Another example of this would be the “Tor” anonymizing network. Its standard port number has been 9050 for some time, but a Tor node simply listens on this one port number, regardless of whether that’s to accept connections from Tor nodes someplace else on the Internet, or whether that’s to accept an outbound connection from a local proxy-server – i.e. from another program on the same computer. With Tor specifically, If in doubt, you’d simply try to fire a connection at it and see what happens, via its only listening port. But for the most part, Tor likes a SOCKS5 connection going out.

Now there has been the issue, that certain firewalls will specifically block requests to connect to port 9050 on outside machines. And so some Tor nodes have been instructed to listen on some other port number, for incoming connections. But in order to get that to work, a kind of quiet agreement has been reached between Tor users, as to which port number they’re hijacking – that port number now being one officially assigned to an existing, other protocol.

So was I half-right, or half-wrong? I was trying to state basic knowledge, which might still be taken as a first-order approximation of the real world.