http是現(xiàn)在web領域極其普遍的應用層傳輸協(xié)議霎奢， 目前常見的使用版本則是http1.1， 當然最先版本是http2.0梢灭。
傳統(tǒng)的Http應用里都是一次TCP連接一次request夷家。
這種情況下效率有點低：
- 服務端負載增加，每個請求過來都得占用端口
- 客戶端或服務端對客戶端連接數(shù)的限制（chrome 限制是6個）
這種情況很多敏释，比如網頁加載對于這個case的處理就是使用將靜態(tài)資源放置到不同Domain或者壓縮打包減少數(shù)量來提高效率
http1.1 協(xié)議里增加了 keepalive的支持库快， 并且默認開啟。
客戶端和服務端在建立連接并完成request后并不會立即斷開TCP連接钥顽，而是在下次request來臨時復用這次TCP連接义屏。但是這里也必須要有TCP連接的timeout時間限制。不然會造成服務端端口被長期占用釋放不了耳鸯。
對于不適用keepalive的request來說湿蛔，不管是客戶端還是服務端都是通過TCP的鏈接的斷開知道request的結束（TCP 揮手時會check 數(shù)據(jù)包的 seq， 保證數(shù)據(jù)完整性）县爬。
支持keepalive后阳啥，如何知道request結束了呢？
在Http1.1的版本里财喳， 解決方案是request 和reponse里使用contentLength來幫助確認是否收到全部數(shù)據(jù)察迟。
另一個問題就是在使用keepalive的情況斩狱，客戶端依然有同時發(fā)送多個請求的情況，比如網頁加載是需要同時load多個靜態(tài)資源扎瓶。比如 瀏覽器默認最大連接數(shù)是6所踊，現(xiàn)在有十個資源同時加載，那么這十個里會有6個并行概荷，4個與前6個串行秕岛。
在keepalive里有個問題就是如果能知道每個repose與其對應的request的話，并發(fā)的請求可以只需要一次TCP連接误证，這也就是http2.0實現(xiàn)的多路復用继薛。
