[TOC] **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](https://link.zhihu.com/?target=https%3A//developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/MIME_types)?類型去解析響應內容（比如 HTML、Image各有不同的解析方式） ### 1.8瀏覽器渲染頁面 太長了，[看這里](https://zhuanlan.zhihu.com/p/80551769)吧