For sites that do want to keep the connection open there could be additional savings for the server. Imagine the normal process of doing this (for instant message delivery etc) involves you opening a connection to the remote web server, which parses your request, and then fires up an instance of perl or php etc to handle it. To hold the connection open, that instance of perl/php will stay running, holding the connection open, and printing to it should it need. With a multiplexing connection this needn't be true; a minimal connection handling server can stay running, holding details of the connection (inter-connection persistent headers etc) in its memory, but allowing the script process to unload until next needed again, if it's needed again. The other option is that other request handlers may be able to open a channel to you through the held open connection and send data to you. Without this (assuming an instant-messenging model) both the sender and receiver of the message would each have their own instances of the script processor running, with the process handling the senders request connecting to the process handling the receivers request, and sending it the message which it would then bounce on to you.
So yeah don't worry about it, this should all mean you can keep all your tabs open, and now with up to 50% less guilt! :-)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds