一個tcp支援多少個http

問題1：用戶端在與伺服器建立了一個TCP連接配接後是否會在一個 HTTP 請求完成後斷開？

在 HTTP/1.0 中，一個伺服器在發送完一個 HTTP 響應後，會斷開 TCP 連結。但是這樣每次請求都會重建立立和斷開 TCP 連接配接，代價過大。是以雖然标準中沒有設定，某些伺服器對 Connection: keep-alive 的 Header 進行了支援。意思是說，完成這個 HTTP 請求之後，不要斷開 HTTP 請求使用的 TCP 連接配接。這樣的好處是連接配接可以被重新使用，之後發送 HTTP 請求的時候不需要重建立立 TCP 連接配接，節省了 SSL（Secure Sockets Layer，安全套接層）的開銷。

持久連接配接：既然維持 TCP 連接配接好處這麼多，HTTP/1.1 就把 Connection 頭寫進标準，并且預設開啟持久連接配接，除非請求中寫明 Connection: close，那麼浏覽器和伺服器之間是會維持一段時間的 TCP 連接配接，不會一個請求結束就斷掉。

是以，一個TCP連接配接是支援多個http請求的。

問題2：一個 TCP 連接配接中 HTTP 請求發送可以一起發送麼（比如一起發三個請求，再三個響應一起接收）？

在HTTP/1.1 中規定了持久連接配接，但仍存在一個問題，單個 TCP 連接配接在同一時刻隻能處理一個請求，意思是說：兩個http請求的生命周期不能重疊，任意兩個 HTTP 請求從開始到結束的時間在同一個 TCP 連接配接裡不能重疊。

雖然 HTTP/1.1 規範中規定了 Pipelining 來試圖解決這個問題，但是這個功能在浏覽器中預設是關閉的。在RFC 2616 中對Pipelining做了如下規定：一個支援持久連接配接的用戶端可以在一個連接配接中發送多個請求（不需要等待任意請求的響應），收到請求的伺服器必須按照請求收到的順序發送響應。

至于為什麼這麼規定，主要是因為 HTTP/1.1 是個文本協定，同時傳回的内容也并不能區分對應于哪個發送的請求，是以順序必須維持一緻。比如你向伺服器發送了兩個請求 GET/query?q=A 和 GET/query?q=B，伺服器傳回了兩個結果，浏覽器是沒有辦法根據響應結果來判斷響應對應于哪一個請求的。

Pipelining 這種設想看起來比較美好，但是在實踐中會出現許多問題：

• 一些代理伺服器不能正确的處理 HTTP Pipelining。
• 正确的流水線實作是複雜的。
• Head-of-line Blocking 連接配接頭阻塞：在建立起一個 TCP 連接配接之後，假設用戶端在這個連接配接連續向伺服器發送了幾個請求。按照标準，伺服器應該按照收到請求的順序傳回結果，假設伺服器在處理首個請求時花費了大量時間，那麼後面所有的請求都需要等着首個請求結束才能響應。

是以現代浏覽器預設是不開啟 HTTP Pipelining 的。

但是，HTTP2 提供了 Multiplexing 多路傳輸特性，可以在一個 TCP 連接配接中同時完成多個 HTTP 請求。我們可以看一下使用 HTTP2 的效果。

那麼在 HTTP/1.1 時代，浏覽器是如何提高頁面加載效率的呢？主要有下面兩點：

• 維持和伺服器已經建立的 TCP 連接配接，在同一連接配接上順序處理多個請求。
• 和伺服器建立多個 TCP 連接配接。

問題3：浏覽器對同一 Host 建立 TCP 連接配接到數量有沒有限制？