HTTP与TCP传输特征错配催生的前端优化Tricks及历史局限

HTTP传输的对象天生是”数量多、时间短、资源小、切换快”，而TCP协议是面向 长时间、大数据传输设计的——建连要三次握手（百毫秒级开销），还有慢启动 特性（刚建连时速度最低，逐步提速）。这个错配催生出经典的YSlow-23条前端 优化规则：合并雪碧图/CSS/JS减少请求数、跨域名分片扩大并发连接数、启用 GZip压缩、避免重定向、按重要性调整资源加载顺序等。但这些规则本质是在 “HTTP/TCP不匹配”这个技术根基问题上打补丁，随着HTTP协议本身持续演进 （从HTTP/1.0/1.1到2015年HTTP/2、2019年HTTP/3），”什么样的请求适合传输” 这个前提在不断变化，很多曾经的最佳实践后来反而变成反模式——例如HTTP/2 引入多路复用后，刻意合并资源减少请求数不仅不再必要，还会因为破坏HTTP/2 基于字典编码的Header压缩效果而适得其反（见[[HTTP-2多路复用终结队首阻塞 与连接数优化战争]]）。这提示一个可迁移的教训：针对协议实现细节做的性能 优化，其保质期往往绑定在协议版本上，一旦底层协议演进，昨天的最佳实践就 可能变成今天的反模式。