一個價值幾百萬美元的Bug
英文原文：The Several Million Dollar Bug
作者 Jacques Mattheij，13 歲開始編程，高中輟學，18 歲用一個月時間學習 COBOL，得到第一份工作。在因特網剛興起時開發了第一個流媒體網絡視頻軟件，賣給多家公司，曾被用來直播哈勃太空望遠鏡的修復工作。當時，互聯網大部分網頁還都是靜態的。）
</blockquote>我們一直如履薄冰，因為我們只比對手多想到一點點。網景、微軟以及其他瀏覽器廠商在 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 現在倒是想把這種方法正式寫進協議。
來自: 伯樂在線本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！