Given the discussion under https://news.ycombinator.com/item?id=33743935 https://news.ycombinator.com/item?id=33743935 about opening a connection to 1.2.3.4:443

Given the discussion under https://news.ycombinator.com/item?id=33743935 https://news.ycombinator.com/item?id=33743935 about opening a connection to 1.2.3.4:443 (I'm prompted by the same curiosity about ingress load-balancing, statelessly)... How does the ingress "router" load-balance incoming connections, which it must (even if the "router" is a default host or cluster)? CF isn't opening TCP, then HTTP just to send redirects to another IP for the same cluster. I guess hashing, on IP and port, is already readily used in routing decisions, so eyeball-addr and -port of the inbound packets, 4-tuple (CF-addr [fixed, shared], CF-port [443], eyeball-addr, eyeball-port), provides a consistent. I guess that this is good for 99.9 percent of connections, which are short-lived, and opportunistically kept open or reused. I suppose other long-lived connections might take place in the context of an application that tracks data above and outside of TCP-alone. I'm grasping for a missing middle, in size of use case, and can't quickly name things that people might proxy but need stable connections. CloudFlare's reverse proxying to web servers would count, if the web-fronting had to traverse someone else's proxy layer. What are the rough edges here? What's are next challenges here to build around?