一个价值几百万美元的Bug

　　英文原文：The Several Million Dollar Bug

作者 Jacques Mattheij，13 岁开始编程，高中辍学，18 岁用一个月时间学习 COBOL，得到第一份工作。在因特网刚兴起时开发了第一个流媒体网络视频软件，卖给多家公司，曾被用来直播哈勃太空望远镜的修复工作。当时，互联网大部分网页还都是静态的。）

　　我们一直如履薄冰，因为我们只比对手多想到一点点。网景、微软以及其他浏览器厂商在 HTTP 协议上都犯了一个小而关键的错误。为此，他们写了更多的代码来让这个漏洞不出现，让每天的 HTTP 请求显得貌似很正常。

　　大家都知道 HTTP 无非这样一个套路：客户端建立连接；客户端请求；服务器响应。
RFC 1945是这样写的，但是程序就一定要按照这个流程写吗？

　　Stack Overflow 上就有人提问了，比方说服务器上有一个静态 HTML 页面和一张图片，如果你知道客户端每次都要访问这个 HTML 和图片，服务器能不能发送完 HTML 页面立即发送图片，而无需客户端再次请求呢？快 20 年了还有人问这样的问题实在太好笑了。但其实这是一个值得思考的问题，不是一个“no”或“yes”就可以打发的。

　　暂时别管什么“持久连接”（keep-alive）、“混杂内容”（mixing content types）和“最大并发连接数”（maximum number of parallel connections），那样到底行不行？

　　答案是必须可以。

　　不停的发送响应，完全不理会客户端请求，TCP 缓冲大致相当于一帧图像，装不下就直接丢弃，即时的速率适应，任何链路都是最大的帧率，这样做使我的网络视频软件从每秒 1 帧提升到每秒 15 帧。（大概 1995 年的时候）。就这么一件小事让我赚了一大笔钱。而我一直不明白竞争对手们怎么就想不到这一点。

　　每次各大浏览器更新，我就会睡眠不足。我要确认他们没把漏洞补上，不然我们就失业了。可是直到今天他们都没这么做。SPDY 现在倒是想把这种方法正式写进协议。