本文由原作者松若章原創(chuàng)發(fā)布，作者主頁(yè)：zhihu.com/people/hrsonion/posts，感謝原作者的無(wú)私分享。
1、引言
一道經(jīng)典的面試題是：從 URL 在瀏覽器被被輸入到頁(yè)面展現(xiàn)的過(guò)程中發(fā)生了什么？
大多數(shù)回答都是說(shuō)請(qǐng)求響應(yīng)之后 DOM 怎么被構(gòu)建，被繪制出來(lái)。但是你有沒(méi)有想過(guò)，收到的 HTML 如果包含幾十個(gè)圖片標(biāo)簽，這些圖片是以什么方式、什么順序、建立了多少連接、使用什么協(xié)議被下載下來(lái)的呢？
要搞懂這個(gè)問(wèn)題，我們需要先解決下面五個(gè)問(wèn)題：
1）現(xiàn)代瀏覽器在與服務(wù)器建立了一個(gè) TCP 連接后是否會(huì)在一個(gè) HTTP 請(qǐng)求完成后斷開(kāi)？什么情況下會(huì)斷開(kāi)？
2）一個(gè) TCP 連接可以對(duì)應(yīng)幾個(gè) HTTP 請(qǐng)求？
3）一個(gè) TCP 連接中 HTTP 請(qǐng)求發(fā)送可以一起發(fā)送么（比如一起發(fā)三個(gè)請(qǐng)求，再三個(gè)響應(yīng)一起接收）？
4）為什么有的時(shí)候刷新頁(yè)面不需要重新建立 SSL 連接？
5）瀏覽器對(duì)同一 Host 建立 TCP 連接到數(shù)量有沒(méi)有限制？
好了，帶著上面的問(wèn)題，我來(lái)閱讀本文內(nèi)容。
（本文同步發(fā)布于：http://www.52im.net/thread-2680-1-1.html）
2、相關(guān)文章
3、第一個(gè)問(wèn)題：與服務(wù)器建立的連接是否會(huì)在一個(gè)HTTP請(qǐng)求后斷開(kāi)？什么情況下斷開(kāi)？
如題所示，先來(lái)談?wù)劦谝粋€(gè)問(wèn)題：現(xiàn)代瀏覽器在與服務(wù)器建立了一個(gè) TCP 連接后是否會(huì)在一個(gè) HTTP 請(qǐng)求完成后斷開(kāi)？什么情況下會(huì)斷開(kāi)？
在 HTTP/1.0 中，一個(gè)服務(wù)器在發(fā)送完一個(gè) HTTP 響應(yīng)后，會(huì)斷開(kāi) TCP 鏈接。但是這樣每次請(qǐng)求都會(huì)重新建立和斷開(kāi) TCP 連接，代價(jià)過(guò)大。所以雖然標(biāo)準(zhǔn)中沒(méi)有設(shè)定，某些服務(wù)器對(duì) Connection: keep-alive 的 Header 進(jìn)行了支持。意思是說(shuō)，完成這個(gè) HTTP 請(qǐng)求之后，不要斷開(kāi) HTTP 請(qǐng)求使用的 TCP 連接。這樣的好處是連接可以被重新使用，之后發(fā)送 HTTP 請(qǐng)求的時(shí)候不需要重新建立 TCP 連接，以及如果維持連接，那么 SSL 的開(kāi)銷(xiāo)也可以避免。
下面兩張圖片是我短時(shí)間內(nèi)兩次訪問(wèn) https://www.github.com 的時(shí)間統(tǒng)計(jì)：
▲ 頭一次訪問(wèn)，有初始化連接和 SSL 開(kāi)銷(xiāo)
▲ 初始化連接和 SSL 開(kāi)銷(xiāo)消失了，說(shuō)明使用的是同一個(gè) TCP 連接
持久連接：既然維持 TCP 連接好處這么多，HTTP/1.1 就把 Connection 頭寫(xiě)進(jìn)標(biāo)準(zhǔn)，并且默認(rèn)開(kāi)啟持久連接，除非請(qǐng)求中寫(xiě)明 Connection: close，那么瀏覽器和服務(wù)器之間是會(huì)維持一段時(shí)間的 TCP 連接，不會(huì)一個(gè)請(qǐng)求結(jié)束就斷掉。
所以第一個(gè)問(wèn)題的答案是：默認(rèn)情況下建立 TCP 連接不會(huì)斷開(kāi)，只有在請(qǐng)求報(bào)頭中聲明 Connection: close 才會(huì)在請(qǐng)求完成后關(guān)閉連接。（詳細(xì)文檔請(qǐng)見(jiàn)：https://tools.ietf.org/html/rfc2616#section-8.1）
4、第二個(gè)問(wèn)題：一個(gè) TCP 連接可以對(duì)應(yīng)幾個(gè) HTTP 請(qǐng)求？
了解了第一個(gè)問(wèn)題之后，其實(shí)這個(gè)問(wèn)題已經(jīng)有了答案：如果維持連接，一個(gè) TCP 連接是可以發(fā)送多個(gè) HTTP 請(qǐng)求的。
5、第三個(gè)問(wèn)題：一個(gè) TCP 連接中 HTTP 請(qǐng)求發(fā)送可以一起發(fā)送么？
再來(lái)看看第三個(gè)問(wèn)題：一個(gè) TCP 連接中 HTTP 請(qǐng)求發(fā)送可以一起發(fā)送么（比如一起發(fā)三個(gè)請(qǐng)求，再三個(gè)響應(yīng)一起接收）？
HTTP/1.1 存在一個(gè)問(wèn)題：單個(gè) TCP 連接在同一時(shí)刻只能處理一個(gè)請(qǐng)求。
意思是說(shuō)：兩個(gè)請(qǐng)求的生命周期不能重疊，任意兩個(gè) HTTP 請(qǐng)求從開(kāi)始到結(jié)束的時(shí)間在同一個(gè) TCP 連接里不能重疊。
雖然 HTTP/1.1 規(guī)范中規(guī)定了 Pipelining 來(lái)試圖解決這個(gè)問(wèn)題，但是這個(gè)功能在瀏覽器中默認(rèn)是關(guān)閉的。
先來(lái)看一下 Pipelining 是什么，RFC 2616 中規(guī)定了：
原文：A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.
翻譯：一個(gè)支持持久連接的客戶(hù)端可以在一個(gè)連接中發(fā)送多個(gè)請(qǐng)求（不需要等待任意請(qǐng)求的響應(yīng)）。收到請(qǐng)求的服務(wù)器必須按照請(qǐng)求收到的順序發(fā)送響應(yīng)。
至于標(biāo)準(zhǔn)為什么這么設(shè)定，我們可以大概推測(cè)一個(gè)原因：由于 HTTP/1.1 是個(gè)文本協(xié)議，同時(shí)返回的內(nèi)容也并不能區(qū)分對(duì)應(yīng)于哪個(gè)發(fā)送的請(qǐng)求，所以順序必須維持一致。比如你向服務(wù)器發(fā)送了兩個(gè)請(qǐng)求 GET /query?q=A 和 GET /query?q=B，服務(wù)器返回了兩個(gè)結(jié)果，瀏覽器是沒(méi)有辦法根據(jù)響應(yīng)結(jié)果來(lái)判斷響應(yīng)對(duì)應(yīng)于哪一個(gè)請(qǐng)求的。
Pipelining 這種設(shè)想看起來(lái)比較美好，但是在實(shí)踐中會(huì)出現(xiàn)許多問(wèn)題：
1）一些代理服務(wù)器不能正確的處理 HTTP Pipelining；
2）正確的流水線實(shí)現(xiàn)是復(fù)雜的。詳見(jiàn)《HTTP/1.x 的連接管理》；
3）Head-of-line Blocking 連接頭阻塞：在建立起一個(gè) TCP 連接之后，假設(shè)客戶(hù)端在這個(gè)連接連續(xù)向服務(wù)器發(fā)送了幾個(gè)請(qǐng)求。按照標(biāo)準(zhǔn)，服務(wù)器應(yīng)該按照收到請(qǐng)求的順序返回結(jié)果，假設(shè)服務(wù)器在處理首個(gè)請(qǐng)求時(shí)花費(fèi)了大量時(shí)間，那么后面所有的請(qǐng)求都需要等著首個(gè)請(qǐng)求結(jié)束才能響應(yīng)。
所以現(xiàn)代瀏覽器默認(rèn)是不開(kāi)啟 HTTP Pipelining 的。
但是，HTTP2 提供了 Multiplexing 多路傳輸特性，可以在一個(gè) TCP 連接中同時(shí)完成多個(gè) HTTP 請(qǐng)求。至于 Multiplexing 具體怎么實(shí)現(xiàn)的就是另一個(gè)問(wèn)題了。我們可以看一下使用 HTTP2 的效果。
▲ 綠色是發(fā)起請(qǐng)求到請(qǐng)求返回的等待時(shí)間，藍(lán)色是響應(yīng)的下載時(shí)間，可以看到都是在同一個(gè) Connection，并行完成的
所以這個(gè)問(wèn)題也有了答案：在 HTTP/1.1 存在 Pipelining 技術(shù)可以完成這個(gè)多個(gè)請(qǐng)求同時(shí)發(fā)送，但是由于瀏覽器默認(rèn)關(guān)閉，所以可以認(rèn)為這是不可行的。在 HTTP2 中由于 Multiplexing 特點(diǎn)的存在，多個(gè) HTTP 請(qǐng)求可以在同一個(gè) TCP 連接中并行進(jìn)行。
那么在 HTTP/1.1 時(shí)代，瀏覽器是如何提高頁(yè)面加載效率的呢？
主要有下面兩點(diǎn)：
1）維持和服務(wù)器已經(jīng)建立的 TCP 連接，在同一連接上順序處理多個(gè)請(qǐng)求；
2）和服務(wù)器建立多個(gè) TCP 連接。
6、第四個(gè)問(wèn)題：為什么有的時(shí)候刷新頁(yè)面不需要重新建立 SSL 連接？
在第一個(gè)問(wèn)題的討論中已經(jīng)有答案了：TCP 連接有的時(shí)候會(huì)被瀏覽器和服務(wù)端維持一段時(shí)間。TCP 不需要重新建立，SSL 自然也會(huì)用之前的。
7、第五個(gè)問(wèn)題：瀏覽器對(duì)同一 Host 建立 TCP 連接到數(shù)量有沒(méi)有限制？
假設(shè)我們還處在 HTTP/1.1 時(shí)代，那個(gè)時(shí)候沒(méi)有多路傳輸，當(dāng)瀏覽器拿到一個(gè)有幾十張圖片的網(wǎng)頁(yè)該怎么辦呢？
肯定不能只開(kāi)一個(gè) TCP 連接順序下載，那樣用戶(hù)肯定等的很難受，但是如果每個(gè)圖片都開(kāi)一個(gè) TCP 連接發(fā) HTTP 請(qǐng)求，那電腦或者服務(wù)器都可能受不了，要是有 1000 張圖片的話總不能開(kāi) 1000 個(gè)TCP 連接吧，你的電腦同意 NAT 也不一定會(huì)同意。
所以答案是：有。Chrome 最多允許對(duì)同一個(gè) Host 建立六個(gè) TCP 連接。不同的瀏覽器有一些區(qū)別，詳見(jiàn)：https://developers.google.com/web/tools/chrome-devtools/network/issues#queued-or-stalled-requests。
那么回到最開(kāi)始的問(wèn)題：收到的 HTML 如果包含幾十個(gè)圖片標(biāo)簽，這些圖片是以什么方式、什么順序、建立了多少連接、使用什么協(xié)議被下載下來(lái)的呢？
如果圖片都是 HTTPS 連接并且在同一個(gè)域名下，那么瀏覽器在 SSL 握手之后會(huì)和服務(wù)器商量能不能用 HTTP2，如果能的話就使用 Multiplexing 功能在這個(gè)連接上進(jìn)行多路傳輸。不過(guò)也未必會(huì)所有掛在這個(gè)域名的資源都會(huì)使用一個(gè) TCP 連接去獲取，但是可以確定的是 Multiplexing 很可能會(huì)被用到。
如果發(fā)現(xiàn)用不了 HTTP2 呢？或者用不了 HTTPS（現(xiàn)實(shí)中的 HTTP2 都是在 HTTPS 上實(shí)現(xiàn)的，所以也就是只能使用 HTTP/1.1）。那瀏覽器就會(huì)在一個(gè) HOST 上建立多個(gè) TCP 連接，連接數(shù)量的最大限制取決于瀏覽器設(shè)置，這些連接會(huì)在空閑的時(shí)候被瀏覽器用來(lái)發(fā)送新的請(qǐng)求，如果所有的連接都正在發(fā)送請(qǐng)求呢？那其他的請(qǐng)求就只能等等了。
（原文鏈接：點(diǎn)此進(jìn)入）
附錄：更多網(wǎng)絡(luò)編程基礎(chǔ)資料
《TCP/IP詳解 - 第11章·UDP：用戶(hù)數(shù)據(jù)報(bào)協(xié)議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時(shí)與重傳》
《技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機(jī)慎點(diǎn)）》
《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)》
《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動(dòng)窗口、擁塞處理》
《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過(guò)程詳解》
《理論聯(lián)系實(shí)際：Wireshark抓包分析TCP 3次握手、4次揮手過(guò)程》
《計(jì)算機(jī)網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）》
《UDP中一個(gè)包的大小最大能多大？》
《P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理、P2P簡(jiǎn)介》
《P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術(shù)詳解(三)：P2P技術(shù)之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術(shù)中的NAT穿透原理》
《高性能網(wǎng)絡(luò)編程(一)：?jiǎn)闻_(tái)服務(wù)器并發(fā)TCP連接數(shù)到底可以有多少》
《高性能網(wǎng)絡(luò)編程(二)：上一個(gè)10年，著名的C10K并發(fā)連接問(wèn)題》
《高性能網(wǎng)絡(luò)編程(三)：下一個(gè)10年，是時(shí)候考慮C10M并發(fā)問(wèn)題了》
《高性能網(wǎng)絡(luò)編程(四)：從C10K到C10M高性能網(wǎng)絡(luò)應(yīng)用的理論探索》
《高性能網(wǎng)絡(luò)編程(五)：一文讀懂高性能網(wǎng)絡(luò)編程中的I/O模型》
《高性能網(wǎng)絡(luò)編程(六)：一文讀懂高性能網(wǎng)絡(luò)編程中的線程模型》
《不為人知的網(wǎng)絡(luò)編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》
《不為人知的網(wǎng)絡(luò)編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》
《不為人知的網(wǎng)絡(luò)編程(三)：關(guān)閉TCP連接時(shí)為什么會(huì)TIME_WAIT、CLOSE_WAIT》
《不為人知的網(wǎng)絡(luò)編程(四)：深入研究分析TCP的異常關(guān)閉》
《不為人知的網(wǎng)絡(luò)編程(五)：UDP的連接性和負(fù)載均衡》
《不為人知的網(wǎng)絡(luò)編程(六)：深入地理解UDP協(xié)議并用好它》
《不為人知的網(wǎng)絡(luò)編程(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網(wǎng)絡(luò)編程(八)：從數(shù)據(jù)傳輸層深度解密HTTP》
《網(wǎng)絡(luò)編程懶人入門(mén)(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》
《網(wǎng)絡(luò)編程懶人入門(mén)(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）》
《網(wǎng)絡(luò)編程懶人入門(mén)(三)：快速理解TCP協(xié)議一篇就夠》
《網(wǎng)絡(luò)編程懶人入門(mén)(四)：快速理解TCP和UDP的差異》
《網(wǎng)絡(luò)編程懶人入門(mén)(五)：快速理解為什么說(shuō)UDP有時(shí)比TCP更有優(yōu)勢(shì)》
《網(wǎng)絡(luò)編程懶人入門(mén)(六)：史上最通俗的集線器、交換機(jī)、路由器功能原理入門(mén)》
《網(wǎng)絡(luò)編程懶人入門(mén)(七)：深入淺出，全面理解HTTP協(xié)議》
《網(wǎng)絡(luò)編程懶人入門(mén)(八)：手把手教你寫(xiě)基于TCP的Socket長(zhǎng)連接》
《網(wǎng)絡(luò)編程懶人入門(mén)(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《技術(shù)掃盲：新一代基于UDP的低延時(shí)網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》
《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》
《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》
《聊聊iOS中網(wǎng)絡(luò)編程長(zhǎng)連接的那些事》
《移動(dòng)端IM開(kāi)發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》
《移動(dòng)端IM開(kāi)發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計(jì)思路》
《腦殘式網(wǎng)絡(luò)編程入門(mén)(一)：跟著動(dòng)畫(huà)來(lái)學(xué)TCP三次握手和四次揮手》
《腦殘式網(wǎng)絡(luò)編程入門(mén)(二)：我們?cè)谧x寫(xiě)Socket時(shí)，究竟在讀寫(xiě)什么？》
《腦殘式網(wǎng)絡(luò)編程入門(mén)(三)：HTTP協(xié)議必知必會(huì)的一些知識(shí)》
《腦殘式網(wǎng)絡(luò)編程入門(mén)(四)：快速理解HTTP/2的服務(wù)器推送(Server Push)》
《腦殘式網(wǎng)絡(luò)編程入門(mén)(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網(wǎng)絡(luò)編程入門(mén)(六)：什么是公網(wǎng)IP和內(nèi)網(wǎng)IP？NAT轉(zhuǎn)換又是什么鬼？》
《以網(wǎng)游服務(wù)端的網(wǎng)絡(luò)接入層設(shè)計(jì)為例，理解實(shí)時(shí)通信的技術(shù)挑戰(zhàn)》
《邁向高階：優(yōu)秀Android程序員必知必會(huì)的網(wǎng)絡(luò)基礎(chǔ)》
《全面了解移動(dòng)端DNS域名劫持等雜癥：技術(shù)原理、問(wèn)題根源、解決方案等》
《美圖App的移動(dòng)端DNS優(yōu)化實(shí)踐：HTTPS請(qǐng)求耗時(shí)減小近半》
《Android程序員必知必會(huì)的網(wǎng)絡(luò)通信傳輸層協(xié)議——UDP和TCP》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(一)：通信交換技術(shù)的百年發(fā)展史(上)》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(二)：通信交換技術(shù)的百年發(fā)展史(下)》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(三)：國(guó)人通信方式的百年變遷》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(四)：手機(jī)的演進(jìn)，史上最全移動(dòng)終端發(fā)展史》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(五)：1G到5G，30年移動(dòng)通信技術(shù)演進(jìn)史》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(六)：移動(dòng)終端的接頭人——“基站”技術(shù)》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(七)：移動(dòng)終端的千里馬——“電磁波”》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(八)：零基礎(chǔ)，史上最強(qiáng)“天線”原理掃盲》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(九)：無(wú)線通信網(wǎng)絡(luò)的中樞——“核心網(wǎng)”》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(十)：零基礎(chǔ)，史上最強(qiáng)5G技術(shù)掃盲》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(十一)：為什么WiFi信號(hào)差？一文即懂！》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(十二)：上網(wǎng)卡頓？網(wǎng)絡(luò)掉線？一文即懂！》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(十三)：為什么手機(jī)信號(hào)差？一文即懂！》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(十四)：高鐵上無(wú)線上網(wǎng)有多難？一文即懂！》
《IM開(kāi)發(fā)者的零基礎(chǔ)通信技術(shù)入門(mén)(十五)：理解定位技術(shù)，一篇就夠》
《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(一)：DNS優(yōu)化篇》
《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(二)：網(wǎng)絡(luò)連接優(yōu)化篇》
《百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(三)：移動(dòng)端弱網(wǎng)優(yōu)化篇》
《技術(shù)大牛陳碩的分享：由淺入深，網(wǎng)絡(luò)編程學(xué)習(xí)經(jīng)驗(yàn)干貨總結(jié)》
《可能會(huì)搞砸你的面試：你知道一個(gè)TCP連接上能發(fā)起多少個(gè)HTTP請(qǐng)求嗎？》
>> 更多同類(lèi)文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-2680-1-1.html）