1. 現代瀏覽器在與伺服器建立了乙個 tcp 連線後是否會在乙個 http 請求完成後斷開？什麼情況下會斷開？
在 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 連線不會斷開，只有在請求報頭中宣告 connection: close 才會在請求完成後關閉連線。
2. 乙個 tcp 連線可以對應幾個 http 請求？
從上面的問題可知： 如果維持連線，乙個 tcp 連線是可以傳送多個 http 請求的。
3. 乙個 tcp 連線中 http 請求傳送可以一起傳送麼（比如一起發三個請求，再三個響應一起接收，即批量傳送，批量接收）？
在 http/1.1 存在 pipelining 技術可以完成這個多個請求同時傳送，但是由於瀏覽器預設關閉，所以可以認為這是不可行的。在 http2 中由於 multiplexing 特點的存在，多個 http 請求可以在同乙個 tcp 連線中並行進行。
那麼在 http/1.1 時代，瀏覽器是如何提高頁面載入效率的呢？主要有下面兩點：
維持和伺服器已經建立的 tcp 連線，在同一連線上順序處理多個請求。
和伺服器建立多個 tcp 連線。
所以答案是：有。chrome 最多允許對同乙個 host 建立六個 tcp 連線。不同的瀏覽器有一些區別。
如果都是 https 連線並且在同乙個網域名稱下，那麼瀏覽器在 ssl 握手之後會和伺服器商量能不能用 http2，如果能的話就使用 multiplexing 功能在這個連線上進行多路傳輸。不過也未必會所有掛在這個網域名稱的資源都會使用乙個 tcp 連線去獲取，但是可以確定的是 multiplexing 很可能會被用到。
如果發現用不了 http2 呢？或者用不了 https（現實中的 http2 都是在 https 上實現的，所以也就是只能使用 http/1.1）。
那瀏覽器就會在乙個 host 上建立多個 tcp 連線，連線數量的最大限制取決於瀏覽器設定，這些連線會在空閒的時候被瀏覽器用來傳送新的請求，如果所有的連線都正在傳送請求呢？那其他的請求就只能等等了
HTTP與TCP的區別
一次面試中問到的問題，整理一下 首選需要提到osi open system interconnection 七層模型。第二列是相關協議 應用層http 用於封裝和顯示資料 telnet ftp 表示層會話層 傳輸層 tcp udp 網路層ip icmp igmp 資料鏈路層 物理層那麼，最明顯的區別...
Http請求的TCP連線
這句話其實只對了一半，我們現如今的http協議，大部分都是1.1的，因此我們平時用的基本上都是長連線。但是前半句是不對的，http協議根本沒有長短連線這一說，也正因為誤解了這個，導致lz對於長連線一直不明不白，始終不得其要領，具體下面一段會說到。網路上很多文章都是誤人子弟，根本沒有說明白這個概念。這...
HTTP與TCP的關係
http協議是瀏覽器與伺服器之間的協議。他是乙個應用層的協議，http作為應用層協議它是基於tcp協議經行資料傳輸的。http協議主要做什麼呢？它主要是規範了瀏覽器與伺服器之間通訊的格式，並不會進行資料報的傳輸。然而具體的資料報傳輸是由傳輸層的tcp協議完成的。總的來說，當你在web頁面輸入 時，你...