v145 · Web APIs · Privacy
TCP Socket Pool Limit Randomization
Chrome 145 randomizes the per-origin TCP socket pool limit (previously a fixed value of 6) within a small range each browsing session, preventing fingerprinting that exploited the predictable concurrent connection count to identify browsers.
background
Browsers maintain a per-origin connection pool — a maximum number of simultaneous TCP connections to the same server. Chrome's limit was a fixed 6 connections per origin, matching the HTTP/1.1 recommendation. An attacker could exploit this predictable limit: by timing how many parallel requests to a single origin could proceed simultaneously, they could confirm the user was using Chrome.
Chrome 145 randomizes this limit (within a range that preserves reasonable performance) so the connection count varies between sessions and across origins, defeating this fingerprinting vector.
concepts
-
TCP Pool Demo
Fires a burst of parallel resource requests and uses Resource Timing to observe how many proceed simultaneously — illustrating that the exact concurrency limit is no longer a fixed, predictable value.
-
Security Context
How the fixed connection limit enabled fingerprinting, the range of the new randomized limit, and performance implications of varying the pool size.
-
Connection Fingerprint Lab
Burst tester that counts how many timing "steps" appear in a batch of fetches — the canonical signal trackers used to infer the socket pool size. Shows whether the pattern looks like Chrome 144 or Chrome 145.
-
Connection Queue Simulator
Step-through simulator showing how requests queue behind a configurable pool limit. Switch between HTTP/1.1 (pool-constrained) and HTTP/2 (multiplexed, no queue) to see how Chrome 145's randomized limit affects in-flight request counts.
the change
// No web API change — the TCP socket limit is an internal browser detail.
// Web developers do not set it; it's not configurable from JavaScript.
// Before Chrome 145: fixed limit of 6 concurrent connections per origin
// Chrome 145+: limit is randomized each session within a small range
// (e.g., 5–8 connections per origin)
// Impact on web developers:
// - HTTP/1.1 sites: slightly different queue behaviour per session (minor)
// - HTTP/2 and HTTP/3: not affected — these multiplex over one connection
// - Fingerprinting resistance: connection count probe no longer reliable
// Best practice: use HTTP/2 or HTTP/3, which eliminates connection limits
// as a performance concern entirely.