在 http/1.0 中，乙個伺服器在傳送完乙個 http 響應後，會斷開 tcp 鏈結。但是這樣每次請求都會重新建立和斷開 tcp 連線，代價過大。所以雖然標準中沒有設定，某些伺服器對 connection: keep-alive 的 header 進行了支援。意思是說，完成這個 http 請求之後，不要斷開 http 請求使用的 tcp 連線。這樣的好處是連線可以被重新使用，之後傳送 http 請求的時候不需要重新建立 tcp 連線，以及如果維持連線，那麼 ssl 的開銷也可以避免。
持久連線：既然維持 tcp 連線好處這麼多，http/1.1 就把 connection 頭寫進標準，並且預設開啟持久連線，除非請求中寫明 connection: close，那麼瀏覽器和伺服器之間是會維持一段時間的 tcp 連線，不會乙個請求結束就斷掉。
了解了第乙個問題之後，其實這個問題已經有了答案，如果維持連線，乙個 tcp 連線是可以傳送多個 http 請求的。
http/1.1 存在乙個問題，單個 tcp 連線在同一時刻只能處理乙個請求，意思是說：兩個請求的生命週期不能重疊，任意兩個 http 請求從開始到結束的時間在同乙個 tcp 連線裡不能重疊。
雖然 http/1.1 規範中規定了 pipelining 來試**決這個問題，但是這個功能在瀏覽器中預設是關閉的，原因略過，參考：
http2 提供了 multiplexing 多路傳輸特性，可以在乙個 tcp 連線中同時完成多個 http 請求。
所以這個問題也有了答案：在 http/1.1 存在 pipelining 技術可以完成這個多個請求同時傳送，但是由於瀏覽器預設關閉，所以可以認為這是不可行的。在 http2 中由於 multiplexing 特點的存在，多個 http 請求可以在同乙個 tcp 連線中並行進行。
那麼在 http/1.1 時代，瀏覽器是如何提高頁面載入效率的呢？主要有下面兩點：
1 維持和伺服器已經建立的 tcp 連線，在同一連線上順序處理多個請求。
2 和伺服器建立多個 tcp 連線。
為什麼有的時候重新整理頁面不需要重新建立 ssl 連線？
在第乙個問題的討論中已經有答案了，tcp 連線有的時候會被瀏覽器和服務端維持一段時間。tcp 不需要重新建立，ssl 自然也會用之前的。
瀏覽器對同一 host 建立 tcp 連線到數量有沒有限制？
所以答案是：有。chrome 最多允許對同乙個 host 建立六個 tcp 連線。不同的瀏覽器有一些區別。
如果都是 https 連線並且在同乙個網域名稱下，那麼瀏覽器在ssl 握手之後會和伺服器商量能不能用 http2，如果能的話就使用 multiplexing 功能在這個連線上進行多路傳輸。不過也未必會所有掛在這個網域名稱的資源都會使用乙個 tcp 連線去獲取，但是可以確定的是 multiplexing 很可能會被用到。
如果發現用不了 http2 呢？或者用不了 https（現實中的 http2 都是在 https 上實現的，所以也就是只能使用 http/1.1）。那瀏覽器就會在乙個 host 上建立多個 tcp 連線，連線數量的最大限制取決於瀏覽器設定，這些連線會在空閒的時候被瀏覽器用來傳送新的請求，如果所有的連線都正在傳送請求呢？那其他的請求就只能等等了。
乙個TCP連線可以發多少個HTTP請求
一 從url被輸入瀏覽器到頁面展現，這個過程中發生了什麼？二 現代瀏覽器與伺服器建立乙個tcp連線後，是否會在乙個http請求完成後斷開？什麼情況下會斷開？2.http 1.0會斷開，除非設定connection keep alive 3.http 1.1不會斷開，不會再次進行初始化連線和ssl，除...
乙個TCP 連線可以發多少個 HTTP 請求呢？
dns伺服器請求解析 檢查host檔案 建立tcp連線，三次握手 傳送http請求，請求行 請求頭部 空行和請求資料4部分組 伺服器返回，伺服器將資源複本寫到tcp套接字，由客戶端讀取。乙個響應由狀態行 響應頭部 空行和響應資料4部分組成 主動釋放or延時釋放 瀏覽器進行渲染 現代瀏覽器在與伺服器建...
乙個TCP連線可以傳送多少個HTTP請求？
一道經典的面試題是從url在瀏覽器被輸入到頁面展現的過程中發生了什麼？大多數回答都是請求響應之後dom是怎麼被構建 被繪製出來。要搞懂這個問題，我們需要先解決下面五個問題 在http 1.0中，乙個伺服器在傳送完乙個http響應後，會斷開tcp連線。但是這樣每次請求都會重新建立和斷開tcp連線，代價...