自寫 HTTP 服務器：Chrome 秒開 vs 360 瀏覽器卡頓的根因分析

現象

自寫 HTTP 服務器，Chrome 瞬間顯示頁面，360 瀏覽器（兼容模式/IE 內核）顯示卡住，需新開標籤才渲染出來。

根因：HTTP 協議完整性缺失

自寫服務器可能缺少以下關鍵響應要素，導致 IE 內核解析阻塞：

1. 缺少 Content-Length 或 Transfer-Encoding: chunked：IE 內核需明確知道響應體結束位置，否則持續等待數據
2. 缺少 Connection: close / keep-alive 明確聲明
3. 頭部結束標記 \r\n\r\n 缺失或格式錯誤
4. 響應頭大小寫/順序不規範：IE 內核對頭部解析更嚴格

標準 HTTP 響應模板

// 最小完整響應
HTTP/1.1 200 OK\r\n
Content-Type: text/html; charset=utf-8\r\n
Content-Length: 1234\r\n
Connection: close\r\n
\r\n
...body...

分塊傳輸編碼（動態生成內容）

HTTP/1.1 200 OK\r\n
Content-Type: text/html; charset=utf-8\r\n
Transfer-Encoding: chunked\r\n
Connection: close\r\n
\r\n
第一塊長度(hex)\r\n
塊內容\r\n
第二塊長度(hex)\r\n
塊內容\r\n
0\r\n  // 結束塊
\r\n

調試步驟

1. 用 curl -v https://localhost:port 查看原始響應頭
2. 對比 Chrome/360 的 Network 面板（F12）加載瀑布圖
3. 抓包（Wireshark/Fiddler）分析 TCP 流、HTTP 解析錯誤

最佳實踐

• 不要手寫 HTTP 解析/響應：用成熟庫
• Node.js: http/express/koa
• Python: http.server/flask/fastapi
• Go: net/http/gin
• C++: cpp-httplib/crow/pistache
• Java: Jetty/Undertow/Spring Boot

為什麼 Chrome 沒事？

Chrome (Blink 內核) 容錯性極強，採用投機解析、增量渲染，甚至無 Content-Length 也能按連接關閉判斷結束。IE/360 兼容模式 (Trident/MSHTML) 嚴格遵循 RFC 2616，缺頭等待超時才渲染。

**結論**：補全 HTTP 響應頭（特別是 Content-Length），或直接用成熟框架，問題即刻消失。