v139 · network / connectivity
Re-Sizing TCP Connection Pool
This experiment evaluates the impact of changing the per-profile TCP socket pool size from 256 (the current default), down to 255, and up to 257, 512, and 1024 (possibly at 1-2 numbers between those based on findings). We will study the performance impact of these changes in stages, starting with 255 and 257. If no ill effects are seen, 5
concepts
-
Connection Pool Note
Chromes TCP connection pool now resizes dynamically based on observed network conditions. Tile-heavy sites (maps, image grids) get smoother throughput.
-
Sidechannel Leak
The xsleaks attack the experiment is studying: an attacker saturates the shared TCP pool, opens the victim site, and infers logged-in state from timing. Tweak the parameters and watch the leak verdict change.
-
Pool Exhaustion Simulator
Three pool sizes — 256, 512, 1024 — race the same request burst. Pick burst size, work mix, and per-request work; see the p50/p95/p99 latency delta and how much burst time the bigger pool saves.
-
Connection Pool Monitor
Simulates a live pool with active/idle/queued connection counters. A memory-pressure slider shrinks the pool. A "request burst" button fires 20 simultaneous requests and shows the queue drain in real time. A rolling chart tracks pool utilization, and an efficiency score measures queue wait vs throughput.
why it shipped
Having a fixed pool of TCP sockets available to an entire profile allows attackers to effectively divinate the amount of network requests done by other tabs, and learn things about them to the extent that any given site can be profiled. For example, if a site does X network requests if it’s logged in and Y if it’s logged out, by saturating the TCP socket pool and watching movement after calling window.open, the state of the other site can be gleaned.