Re: Proposal: Adopt State Synchronization into HTTPbis

I was curious about this just now:

On 10/10/24 6:30 PM, Mark Nottingham wrote:
> Holding a connection open to every web site you have an open tab for
> creates issues for server and network infrastructure (see above) as well
>   as for mobile battery life.

Because most web developers I know already open and maintain a WebSocket 
for every tab. So I'm collecting data on "what percentage of my current 
Chrome tabs have a connection open?"

This unix shell command tries to print out the number of TCP connections 
that Chrome has open:

    pgrep -f Google Chrome | xargs -I {} sudo lsof -i -n -P -a -p {} | grep ESTABLISHED | grep -E ':80|:443' | wc -l

And this one tries to print out QUIC connections:

    pgrep -f Google Chrome | xargs -I {} sudo lsof -i -n -P -a -p {} | grep UDP | wc -l

Across my 83 tabs, this says Chrome is maintaining 8 TCP and 26 UDP 
connections. This ratio of TCP/UDP surprises me, so maybe there's a bug 
in my scripts, but this data indicates one connection is open for every 
2.4 tabs.

If this is true, I think we'd be safe with even 1 connection per tab. 
That would only increase the number of connections by 2.4x. Connections 
are cheap on today's evented architectures. A single websocket 
connection in nodejs uses about 5KB of memory today. This is much better 
than the 1MB per connection we had in the old PHP/Ruby/Python/Java/CGI 
days, where we'd allocate an OS thread per connection.

However, we can do even better than 1 connection per tab— tabs can share 
a connection to the same origin, so we really only need 1 connection per 
origin.

And if that's too much, we can allow connections to go to sleep wherever 
necessary, like when in the background, and then phone implementations 
can periodically wake up and "ping" for changes in batch when desired 
(like when connected to power & wifi).

Cheers,

Michael