HTTP protocol can work for not often updated system. Simply in http, you find out distant data only by making request and getting answer. Http request and http answer are rather many bytes (file, text), and after request is made, it recieves the answer , and connection is close . unless you specify "Connection:Keep-Alive" header, so that client may use the connection for other requests it fires (src's of img , css. js. in link tag and all data it knows url for), nearly no server supports it and your browser allways recieve "Connection:Close" header in answer, so these are allways separate reqests. Do not even think of sending data to clients of the server. In http, client gets/asks data and server is suposed to respond only and do not invoke.Simply put, you can update clients only if they (the aplication) make request. If your aplication might find use of http ptrotocol, it might be very good, but http protocol is not designed for permanent frame data exchenge. But then,
what if your game, before it strats, makes a reqest for xml scene and elements data,so that it can bring player to game? Nice idea. Imagine you could wake up one morning, and to all the players bring new stuff, scene,. just by updating document and files in text of the document.

planning the networking for a game around cheap HTTP-based hosting is not how to go about

And I would stress that, you should provide your own aplication that serves your clients, but for that you will need a box, and that is not 2GB dedicated on a host machine, housing a box on a up link costs 80 euro. But if your aplication visits some http domains, it might be very benefitial for your aplication, though volatile data will have to be exchanged defintily not by http protocol, but by raw abstraction between udp link you established between your aplications and server. But games might find big use of http, but in other manners than constant interaction between players.

HTTP protocol can work for not often updated system. Simply in http, you find out distant data only by making request and getting answer. Http request and http answer are rather many bytes (file, text), and after request is made, it recieves the answer , and connection is close . unless you specify "Connection:Keep-Alive" header, so that client may use the connection for other requests it fires (src's of img , css. js. in link tag and all data it knows url for), nearly no server supports it and your browser allways recieve "Connection:Close" header in answer, so these are allways separate reqests.

I wrote a web-server of my own and it always let the connections stay open for some time (normaly 60 seconds). A web-browser creates numerous connection in parallel if there are references to content is on the page. The number of connections vary. Some use google as a proxy service where you can get a dozen connections in parallel for the requested page content but every request comes from another IP. The only way to "see" that all requests are from the same client would be cookie with some session id.

It would be possible to create a stream connection to a browser. You can send a reply without giving a size information and afterwards send chunks of data on this stream.
This way you can stream a video to a client.

You can send a reply without giving a size information and afterwards send chunks of data on this stream.
This way you can stream a video to a client.

Yes, you could fake constant data update by streaming a dynamic file, but only in server-to-client direction, as it would be very monstrous to collect data from clients that server needs through http hammering requests .