龔秀梅
“我是喲喲吼說科技，專注於數據網絡的回答，歡迎大家與我交流數據網絡的問題”
HTTP（HyperText Transfer Protocol，超文本傳輸協議）是訪問網站時最常用的協議，也是互聯網上應用最廣泛的一種網絡協議。
HTTP協議是基於TCP協議來實現的，在客戶端發送一個HTTP請求後，會默認使用80端口來建立TCP連接，服務器端則最80端口監聽客戶端發送的HTTP請求，進而對其進行回應。
如題，HTTP協議與TCP協議在數量上的對應關係是什麼呢？
喲喲認為，一個完整的HTTP請求可能對應多個TCP連接，沒有具體定義數量的對應關係。數量的關係會受連接時間、網絡穩定性等因素來影響。
下面喲喲來簡單介紹一下一個HTTP請求必要的TCP連接有哪些？
1、建立連接
首先會使用TCP三次握手的機制來建立連接，因此肯定會有3個握手數據報文；
2、request
在建立連接後會發送request請求，這裡不止會有1個request，因此至少有1個以上的TCP連接；
3、response
一個request會對應多個response，分別為1次確認發送和不止1此的負載數據，因此這裡最少有3個TCP連接；
4、斷開連接
在數據交互完成後，會使用TCP四次揮手的機制來斷開連接，因此肯定會有4個揮手數據報文；
若考慮到網絡穩定性差的因素，那麼會有多次重傳的數據報文，因此對應的TCP連接數量會無法計算，總之，一個HTTP請求無法明確的定義TCP連接數量的對應關係。
歡迎大家多多關注我，在下方評論區說出自己的見解。
喲喲吼說科技
假設你基本瞭解HTTP和TCP，在這個基礎上回答你的問題
這個需要分協議版本解釋。
HTTP1.0/0.9
http1.0不支持keep-alive，要完成一次HTTP請求，需要建立一個新的TCP連接，然後發送http請求，待接收響應後關閉連接。
HTTP1.1
http1.1默認使用keep-alive，一次HTTP請求完成後不會關閉TCP連接，會繼續為下一個HTTP請求服務（可以類比數據庫連接池和線程池的設計），減小建立和關閉TCP連接的開銷（三次握手四次揮手）。
以瀏覽器為例，瀏覽器在客戶端為請求排隊，同時使用4-6條TCP通道來發送HTTP消息。HTTP協議的設計無法實現對TCP通道的分用和複用（原因以後我會在頭條專門寫），一個HTTP消息在發送請求到響應回來之間是獨佔一個TCP通道的（pipeline模式除外，一般很少用）。
比較大的門戶網站，比如京東，首頁請求非常多，但是大量都需要排隊等TCP空閒。這樣設計的出發點主要是性能，否則會佔用服務器太多Socket資源（考慮socket預留的讀寫緩衝區，windows的內核對象或者linux的文件句柄）或者變相地造成DoS攻擊。
從這個角度看，TCP通道在傳輸的時候，同一時間只對應一次HTTP請求，同時在它關閉之前可能會傳輸很多次不同的HTTP請求。所以，HTTP頭部的Content-Length非常重要，這樣才能從TCP流中根據長度提取一個完整HTTP消息。
Pipelineing模式一般都不用，這裡直接無視過掉。
異常
如果因為網絡原因導致TCP連接失效，結果會怎麼樣？
標準的HTTP協議實現組件，只會給上層完整的HTTP消息處理。舉個例子，Web服務器接受客戶端Put或者Post的大文件(比如800M)，服務器的HTTP協議層會使用臨時文件存儲接收，完整接收整個消息後，再通過臨時文件流的方式交給應用服務處理。
如果文件尚未傳輸完畢，TCP連接失效的話，前面所有的傳輸都浪費了。必須重新發起。
所以，HTTP協議傳輸文件需要自己做分片，就是這個道理。
使用Tips
HTTP客戶端組件一般會提供諸如ConnectionLimit的選項讓你控制最大TCP連接數。如果你是桌面客戶端，或者請求遠程服務，不宜設置過大。如果你是內部服務之間調用，可以根據需求合理設置以增加併發性能。
Web服務端一般會提供限制請求消息大小的選項，如果你需要傳輸大文件，特別注意這個選項。
還有到底在內存中還是臨時文件中保存客戶端上傳的文件的閥值，如果你內存夠用，可以考慮稍微設置大一點，比如上傳圖片較多，可以考慮設置5M左右，避免磁盤延遲。
個人見解純手打，歡迎大家評論或者提出意見。
