聲明：博客內容是彙總的，侵刪~
說一下本篇博客回答了哪些問題：
1. 瀏覽器輸入URL後發生了什麼？各個步驟都用到了哪些協議？
一會說。
2. 瀏覽器在與服務器建立了一個 TCP 連接後是否會在一個 HTTP 請求完成後斷開？什麼情況下會斷開？
默認情況下建立 TCP 連接不會斷開，只有在請求報頭中聲明 Connection: close 纔會在請求完成後關閉連接
3. 一個 TCP 連接可以對應幾個 HTTP 請求？(這在問你HTTP1.0和1.1的區別)
瞭解了上個問題之後，其實這個問題已經有了答案，如果維持連接，一個 TCP 連接是可以發送多個 HTTP 請求的
4. 爲什麼有的時候刷新頁面不需要重新建立 SSL 連接？
TCP 連接有的時候會被瀏覽器和服務端維持一段時間。
TCP 不需要重新建立，SSL 自然也會用之前的
5. 一個 TCP 連接中 HTTP 請求發送可以一起發送麼（比如一起發三個請求，再三個響應一起接收）？(提示，這就是在問你HTTP2.0和HTTP1.1協議的區別)
HTTP/1.1 存在一個問題，單個 TCP 連接在同一時刻只能處理一個請求，
即：兩個請求的生命週期不能重疊，任意兩個 HTTP 請求從開始到結束的時間在同一個 TCP 連接裏不能重疊。
雖然 HTTP/1.1 規範中規定了 Pipelining 來試圖解決這個問題，但現代瀏覽器默認是不開啓 HTTP Pipelining 的。
HTTP2 提供了 Multiplexing 多路傳輸特性，可以在一個 TCP 連接中同時完成多個 HTTP 請求
所以問題的答案是：
在 HTTP/1.1 存在 Pipelining 技術可以完成這個多個請求同時發送，但是由於瀏覽器默認關閉，
所以可以認爲這是不可行的。在 HTTP2 中由於 Multiplexing 特點的存在，多個 HTTP 請求可以
在同一個 TCP 連接中並行進行
6. 瀏覽器對同一Host建立TCP連接到數量有沒有限制？(拜託，一個網站那麼多圖片，開一個TCP連接，按順序下載？那不是等到死？)
有。Chrome 最多允許對同一個 Host 建立六個 TCP 連接。不同的瀏覽器有一些區別
7. 收到的 HTML 如果包含幾十個圖片標籤，這些圖片是以什麼方式、什麼順序、建立了多少連接、使用什麼協議被下載下來的呢？
如果圖片都是 HTTPS 連接並且在同一個域名下，那麼瀏覽器在 SSL 握手之後會和
服務器商量能不能用 HTTP2，如果能的話就使用 Multiplexing 功能在這個連接上
進行多路傳輸。不過也未必會所有掛在這個域名的資源都會使用一個 TCP 連接去獲
取，但是可以確定的是 Multiplexing 很可能會被用到。
如果發現用不了 HTTP2 呢？或者用不了 HTTPS（現實中的 HTTP2 都是在 HTTPS
上實現的，所以也就是隻能使用 HTTP/1.1）。那瀏覽器就會在一個 HOST 上建立
多個 TCP 連接，連接數量的最大限制取決於瀏覽器設置，這些連接會在空閒的時候
被瀏覽器用來發送新的請求，如果所有的連接都正在發送請求呢？
那其他的請求就只能等等了
1. 瀏覽器輸入URL後發生了什麼？
這個問題可以分爲八個步驟，每一部都可以拆開講，我先列出來，有空就補（也可能永遠沒空）
並且，後面都帶着連珠炮一樣的提問，當時被字節問傻了..
1.1 根據域名，進行DNS解析，拿到IP地址（DNS/HTTP/HTTPS協議，屬於應用層協議）
- 瀏覽器搜索自己的DNS緩存，緩存中維護一張域名與IP地址的對應表；
- 沒有則查hosts文件，看是否有對應的映射。
- 若沒有，則搜索操作系統的DNS緩存；
- 若沒有，則操作系統將域名發送至本地域名服務器（遞歸查詢方式），本地域名服務器查詢自己的DNS緩存，查找成功則返回結果，否則，通過以下方式迭代查找：
- 本地域名服務器向根域名服務器發起請求，根域名服務器返回com域的頂級域名服務器的地址；
- 本地域名服務器向com域的頂級域名服務器發起請求，返回權限域名服務器地址；
- 本地域名服務器向權限域名服務器發起請求，得到IP地址；
![]()
1.2 封裝數據，並三次握手建立TCP連接（傳輸層）
1.2.1 應用層：發送 HTTP 請求
在前面的步驟我們已經得到服務器的 IP 地址，瀏覽器會開始構造一個 HTTP 報文，其中包括：
- 請求報頭（Request Header）：請求方法、目標地址、遵循的協議等等
- 請求主體（其他參數）
其中需要注意的點：
- 瀏覽器只能發送 GET、POST 方法，而打開網頁使用的是 GET 方法
1.2.1 傳輸層：TCP 傳輸報文
選擇傳輸協議，TCP或者UDP，TCP是可靠的傳輸控制協議，對HTTP請求進行封裝，加入了端口號等信息；
對於TCP協議，傳輸層會發起一條到達服務器的 TCP 連接，爲了方便傳輸，會對數據進行分割（以報文段爲單位），並標記編號，方便服務器接受時能夠準確地還原報文信息。
在建立連接前，會先進行 TCP 三次握手。
1.3 向IP地址發送HTTP請求（網絡層+數據鏈路層）
1.3.1 網絡層：IP協議查詢Mac地址
通過IP協議將IP地址封裝爲IP數據報，並加入源及目標的IP地址，並且負責尋找傳輸路線。
判斷目標地址是否與當前地址處於同一網絡中，是的話直接根據 Mac 地址發送，否則使用路由表查找下一跳MAC地址，此時會用到ARP協議，主機發送信息時將包含目標IP地址的ARP請求廣播到網絡上的所有主機，並接收返回消息，以此確定目標的物理地址，找到目的MAC地址。
注意：在 OSI 參考模型中 ARP 協議位於鏈路層，但在 TCP/IP 中，它位於網絡層
1.3.2 數據鏈路層：以太網協議
以太網協議
接下來到了數據鏈路層，把網絡層交下來的IP數據報添加首部和尾部，封裝爲MAC幀，，接收端在收到物理層上交的比特流後，根據首尾的標記，識別幀的開始和結束，將中間的數據部分上交給網絡層，然後層層向上傳遞到應用層。
TCP/IP 分爲四層，在發送數據時，每層都要對數據進行封裝
1.4 服務器收到請求並處理
服務器接受請求，接受過程就是把以上步驟逆轉過來，參見上圖
HTTPD
最常見的 HTTPD 有 Linux 上常用的 Apache 和 Nginx，以及 Windows 上的 IIS。
它會監聽得到的請求，然後開啓一個子進程去處理這個請求。
處理請求
接受 TCP 報文後，會對連接進行處理，對HTTP協議進行解析（請求方法、域名、路徑等），並且進行一些驗證：
- 驗證是否配置虛擬主機
- 驗證虛擬主機是否接受此方法
- 驗證該用戶可以使用該方法（根據 IP 地址、身份信息等）
重定向
假如服務器配置了 HTTP 重定向，就會返回一個 301永久重定向響應，瀏覽器就會根據響應，重新發送 HTTP 請求（重新執行上面的過程）。
URL 重寫
然後會查看 URL 重寫規則，如果請求的文件是真實存在的，比如圖片、html、css、js文件等，則會直接把這個文件返回。
否則服務器會按照規則把請求重寫到 一個 REST 風格的 URL 上。
然後根據動態語言的腳本，來決定調用什麼類型的動態文件解釋器來處理這個請求。
以 PHP 語言的 MVC 框架舉例，它首先會初始化一些環境的參數，根據 URL 由上到下地去匹配路由，然後讓路由所定義的方法去處理請求
1.5 服務器返回響應結果
返回響應資源。
1.6關閉TCP連接
（不一定關閉）
1.7瀏覽器解析HTML
瀏覽器接收到來自服務器的響應資源後，會對資源進行分析。
首先查看 Response header，根據不同狀態碼做不同的事（比如上面提到的重定向）。
如果響應資源進行了壓縮（比如 gzip），還需要進行解壓。
然後，對響應資源做緩存。
接下來，根據響應資源裏的 MIME 類型去解析響應內容（比如 HTML、Image各有不同的解析方式）
1.8瀏覽器渲染頁面
太長了，看這裏吧