一、從 URL 在瀏覽器被被輸入到頁面展現的過程中發生了什麼？
-
在瀏覽器地址中輸入了URL並回車
URL（Uniform Resource Locator），統一資源定位符，用於定位互聯網上的資源。
URL的格式一般爲：協議類型://<主機名>:<端口>/<路徑>/<文件名>
協議類型有http、https、ftp、file等等。其中http協議是最常見的網絡傳輸協議，https則是進行加密的網絡傳輸協議，安全性更高。
再來解釋一下什麼是IP：
IP 是Internet Protocol的縮寫。也就是爲計算機網絡相互連接進行通信而設計的協議。在因特網中，它是能使連接到網上的所有計算機網絡實現相互通信的一套規則，規定了計算機在因特網上進行通信時應當遵守的規則。
簡單來說，每個處於互聯網中的設備都有IP地址，比如192.168.0.1，127.0.0.1等等。
-
域名解析
域名解析過程中，域名指的是什麼呢？
比如 https://www.baidu.com ，前面的"https"表示採用了https協議，而域名就是www.baidu.com，所以我們常說的網站名其實就是該網站的域名。同時域名www.baidu.com也在域名服務器綁定了一個IP，理論上輸入與之對應的IP也是可以訪問百度首頁的，但是使用IP地址進行訪問遠不如使用域名方便，一個原因是域名更容易被人腦記住，同時域名也是很多公司的名字。
而域名解析這個過程，就是在鍵入了URL之後，把域名指向網站空間IP，讓人們通過註冊的域名可以方便地訪問到網站的一種服務。
瀏覽器具體會從以下幾個緩存去查找域名對應的IP：
- 瀏覽器緩存：瀏覽器會檢查DNS緩存中是否有與該域名對應的IP
- 系統緩存：從Hosts文件查找是否有對應域名和IP
- 路由器緩存：路由器也會緩存DNS，從路由器的DNS中查找對應IP
- IPS DNS：比如到8.8.8.8或者114.114.114.114，也就是谷歌或者互聯網的應用提供商的DNS緩存服務器中查找IP
（DNS：Domain Name System，域名系統，因特網上作爲域名和IP地址相互映射的一個分佈式數據庫，能夠使用戶更方便的訪問互聯網，而不用去記住能夠被機器直接讀取的IP數串。）
-
服務器處理請求
服務器是一臺安裝系統的機器，常見的系統有Linux、Windows Server 2012。而每臺服務器的系統中都會安裝處理請求的應用——Web server。
Web server可以解析接收到的HTTP請求（Rquest），返回一個HTTP響應（Response）給用戶，或者接受請求後反向代理到其他的Web服務器進行別的解析。總而言之，服務器端都會產生相應的HTML響應讓瀏覽器進行瀏覽。
具體接收到的HTTP請求則是在後臺進行處理，後臺處理的主流框架是按照MVC：模型（model）-視圖（view）-控制器（controller）進行搭建的。
-
瀏覽器處理
瀏覽器會接收到服務器處理返回的HTML字符串，然後進行解析，HTML頁面經歷了加載、解析、渲染過程。
比如瀏覽器解析到了link標籤，瀏覽器會重新發送請求獲取css文件；解析到了img標籤，也會發送請求獲取圖片資源；當解析到了script標籤，html文檔會掛起渲染（加載解析渲染同步）的線程，不僅要等待文檔中js文件加載完畢，還要等待解析執行完畢，纔可以恢復html文檔的渲染線程。
-
網頁的繪製
- 瀏覽器根據HTML和css計算得到渲染樹，最終繪製到屏幕上。也就是瀏覽器中我們能看到和進行交互的頁面。
二、收到的 HTML 如果包含幾十個圖片標籤，這些圖片是以什麼方式、什麼順序、建立了多少連接、使用什麼協議被下載下來的呢？
要搞懂這個問題，我們需要先解決下面五個問題：
-
現代瀏覽器在與服務器建立了一個 TCP 連接後是否會在一個 HTTP 請求完成後斷開？什麼情況下會斷開。
-
一個 TCP 連接可以對應幾個 HTTP 請求？
-
一個 TCP 連接中 HTTP 請求發送可以一起發送麼（比如一起發三個請求，再三個響應一起接收）？
-
爲什麼有的時候刷新頁面不需要重新建立 SSL 連接？
-
瀏覽器對同一 Host 建立 TCP 連接到數量有沒有限制？
第一個問題：
現代瀏覽器在與服務器建立了一個 TCP 連接後是否會在一個 HTTP 請求完成後斷開？什麼情況下會斷開。
在 HTTP/1.0 中，一個服務器在發送完一個 HTTP 響應後，會斷開 TCP 鏈接。但是這樣每次請求都會重新建立和斷開 TCP 連接，代價過大。所以雖然標準中沒有設定，某些服務器對 Connection: keep-alive 的 Header 進行了支持。
意思是說，完成這個 HTTP 請求之後，不要斷開 HTTP 請求使用的 TCP 連接。
這樣的好處是連接可以被重新使用，之後發送 HTTP 請求的時候不需要重新建立 TCP 連接。
另外，如果維持連接，那麼 SSL 的開銷也可以避免，兩張圖片是我短時間內兩次訪問 https://www.github.com 的時間統計：
頭一次訪問，有初始化連接和 SSL 開銷
初始化連接和 SSL 開銷消失了，說明使用的是同一個 TCP 連接
持久連接：既然維持 TCP 連接好處這麼多，HTTP/1.1 就把 Connection 頭寫進標準，並且默認開啓持久連接
除非請求中寫明 Connection: close，那麼瀏覽器和服務器之間是會維持一段時間的 TCP 連接，不會一個請求結束就斷掉。
所以第一個問題的答案是：默認情況下建立 TCP 連接不會斷開，只有在請求報頭中聲明 Connection: close 纔會在請求完成後關閉連接。
第二個問題：
一個 TCP 連接可以對應幾個 HTTP 請求？
瞭解了第一個問題之後，其實這個問題已經有了答案，如果維持連接，一個 TCP 連接是可以發送多個 HTTP 請求的。
第三個問題：
一個 TCP 連接中 HTTP 請求發送可以一起發送麼（比如一起發三個請求，再三個響應一起接收）？
HTTP/1.1 存在一個問題，單個 TCP 連接在同一時刻只能處理一個請求
它的意思是說：兩個請求的生命週期不能重疊，任意兩個 HTTP 請求從開始到結束的時間在同一個 TCP 連接裏不能重疊。
雖然 HTTP/1.1 規範中規定了 Pipelining 來試圖解決這個問題，但是這個功能在瀏覽器中默認是關閉的。
但是，HTTP2 提供了 Multiplexing 多路傳輸特性，可以在一個 TCP 連接中同時完成多個 HTTP 請求。
至於 Multiplexing 具體怎麼實現的就是另一個問題了。我們可以看一下使用 HTTP2 的效果。
綠色是發起請求到請求返回的等待時間，藍色是響應的下載時間，可以看到都是在同一個 Connection，並行完成的
所以這個問題也有了答案：在 HTTP/1.1 存在 Pipelining 技術可以完成這個多個請求同時發送，但是由於瀏覽器默認關閉，所以可以認爲這是不可行的。
在 HTTP2 中由於 Multiplexing 特點的存在，多個 HTTP 請求可以在同一個 TCP 連接中並行進行。
那麼在 HTTP/1.1 時代，瀏覽器是如何提高頁面加載效率的呢？主要有下面兩點：
-
維持和服務器已經建立的 TCP 連接，在同一連接上順序處理多個請求。
-
和服務器建立多個 TCP 連接。
第四個問題：
爲什麼有的時候刷新頁面不需要重新建立 SSL 連接？
在第一個問題的討論中已經有了答案：TCP 連接有的時候會被瀏覽器和服務端維持一段時間。TCP 不需要重新建立，SSL 自然也會用之前的。
第五個問題：
瀏覽器對同一 Host 建立 TCP 連接到數量有沒有限制？
假設我們還處在 HTTP/1.1 時代，那個時候沒有多路傳輸，當瀏覽器拿到一個有幾十張圖片的網頁該怎麼辦呢？
肯定不能只開一個 TCP 連接順序下載，那樣用戶肯定等的很難受
但是如果每個圖片都開一個 TCP 連接發 HTTP 請求，那電腦或者服務器都可能受不了
要是有 1000 張圖片的話總不能開 1000 個TCP 連接吧，你的電腦同意 NAT 也不一定會同意。
所以答案是：有。Chrome 最多允許對同一個 Host 建立六個 TCP 連接。不同的瀏覽器有一些區別。
那麼，回到最開始的問題：
收到的 HTML 如果包含幾十個圖片標籤，這些圖片是以什麼方式、什麼順序、建立了多少連接、使用什麼協議被下載下來的呢？
如果圖片都是 HTTPS 連接並且在同一個域名下，那麼瀏覽器在 SSL 握手之後會和服務器商量能不能用 HTTP2
如果能的話就使用 Multiplexing 功能在這個連接上進行多路傳輸。不過也未必會所有掛在這個域名的資源都會使用一個 TCP 連接去獲取，但是可以確定的是 Multiplexing 很可能會被用到。
如果發現用不了 HTTP2 呢？或者用不了 HTTPS（現實中的 HTTP2 都是在 HTTPS 上實現的，所以也就是隻能使用 HTTP/1.1）
那瀏覽器就會在一個 HOST 上建立多個 TCP 連接，連接數量的最大限制取決於瀏覽器設置，這些連接會在空閒的時候被瀏覽器用來發送新的請求，如果所有的連接都正在發送請求呢？那其他的請求就只能等等了。
參考文章：
1 《從URL輸入到頁面展現，過程中發生了什麼？》 https://www.jianshu.com/p/9958129a006e
2 《你猜一個 TCP 連接上面能發多少個 HTTP 請求》 https://zhuanlan.zhihu.com/p/61423830