從輸入 URL 到頁面加載完成的過程當中都發生了什麼

根據 URL 請求頁面過程

說實話，這類文章網上一抓一大把，而我仍想寫這篇博客，一方面是想再仔細縷一下這個過程，另外一方面是但願用清晰的語言和結構來解釋，也算是小小地挑戰一下本身。
過程概述

    瀏覽器查找域名對應的 IP 地址；

    瀏覽器根據 IP 地址與服務器創建 socket 鏈接；

    瀏覽器與服務器通訊： 瀏覽器請求，服務器處理請求；

    瀏覽器與服務器斷開鏈接。

天啦擼，結束了？也太簡單了吧。。。各位看官，不急，都說了是概述，且向下看。
根據域名查找 IP 地址
概念解釋

    IP 地址：IP 協議爲互聯網上的每個網絡和每一臺主機分配的一個邏輯地址。IP 地址如同門牌號碼，經過 IP 地址才能肯定一臺主機位置。服務器本質也是一臺主機，想要訪問某個服務器，必須先知道它的 IP 地址；

    域名（ DN ）：IP 地址由四個數字組成，中間用點號鏈接，在使用過程當中難記憶且易輸入錯誤，因此用咱們熟悉的字母和數字組合來代替純數字的 IP 地址，好比咱們只會記住 www.baidu.com（百度域名） 而不是 220.181.112.244（百度的其中一個 IP 地址）；

    DNS： 每一個域名都對應一個或多個提供相同服務服務器的 IP 地址，只有知道服務器 IP 地址才能創建鏈接，因此須要經過 DNS 把域名解析成一個 IP 地址。

知道了上面的概念，大概就知道了想要得到服務器的門牌號碼，須要先將域名轉換成 IP 地址。轉換過程以下（以查詢 www.baidu.com 的 IP 地址爲例，其中二、三、4步均在上一步未查詢成功的狀況下進行）：
查找過程

    瀏覽器搜索本身的 DNS 緩存（維護一張域名與 IP 地址的對應表）；

    搜索操做系統中的 DNS 緩存（維護一張域名與 IP 地址的對應表）；

    搜索操做系統的 hosts 文件（ Windows 環境下，維護一張域名與 IP 地址的對應表）；

    操做系統將域名發送至 LDNS（本地區域名服務器，若是你在學校接入互聯網，則 LDNS 服務器就在學校，若是經過電信接入互聯網，則 LDNS 服務器就在你當地的電信那裏。）LDNS 查詢 本身的 DNS 緩存（通常查找成功率在 80% 左右），查找成功則返回結果，失敗則發起一個迭代 DNS 解析請求；

        LDNS 向 Root Name Server （根域名服務器，其雖然沒有每一個域名的的具體信息，但存儲了負責每一個域，如 com、net、org等的解析的頂級域名服務器的地址）發起請求，此處，Root Name Server 返回 com 域的頂級域名服務器的地址；

        LDNS 向 com 域的頂級域名服務器發起請求，返回 baidu.com 域名服務器地址；

        LDNS 向 baidu.com 域名服務器發起請求，獲得 www.baidu.com 的 IP 地址；

    LDNS 將獲得的 IP 地址返回給操做系統，同時本身也將 IP 地址緩存起來；

    操做系統將 IP 地址返回給瀏覽器，同時本身也將 IP 地址緩存起來；

    至此，瀏覽器已經獲得了域名對應的 IP 地址。

補充說明

    域名與 URL 是兩個概念：域名是一臺或一組服務器的名稱，用來肯定服務器在 Internet 上的位置；URL 是統一資源定位符，用來肯定某一個文件的具體位置，例如，segmentfault.com 是 SF 的域名，根據這個域名能夠找到 SF 的服務器，segmentfault.com/a/1190000003829539 是 URL ，能夠根據這個 URL 定位我寫的第一篇博客；

    IP 地址與域名不是一一對應的關係：能夠把多個提供相同服務的服務器 IP 設置爲同一個域名，但在同一時刻一個域名只能解析出一個 IP地址；同時，一個 IP 地址能夠綁定多個域名，數量不限；

創建鏈接--三次握手

知道了服務器的 IP 地址，下面便開始與服務器創建鏈接了。

通俗地講，通訊鏈接的創建須要經歷如下三個過程：

    主機向服務器發送一個創建鏈接的請求（您好，我想認識您）；

    服務器接到請求後發送贊成鏈接的信號（好的，很高興認識您）；

    主機接到贊成鏈接的信號後，再次向服務器發送了確認信號（我也很高興認識您），自此，主機與服務器二者創建了鏈接。

補充說明

    TCP 協議：三次握手的過程採用 TCP 協議，其能夠保證信息傳輸的可靠性，三次握手過程當中，若一方收不到確認信號，協議會要求從新發送信號。

網頁請求與顯示

當服務器與主機創建了鏈接以後，下面主機便與服務器進行通訊。網頁請求是一個單向請求的過程，便是一個主機向服務器請求數據，服務器返回相應的數據的過程。

    瀏覽器根據 URL 內容生成 HTTP 請求，請求中包含請求文件的位置、請求文件的方式等等；

    服務器接到請求後，會根據 HTTP 請求中的內容來決定如何獲取相應的 HTML 文件；

    服務器將獲得的 HTML 文件發送給瀏覽器；

    在瀏覽器尚未徹底接收 HTML 文件時便開始渲染、顯示網頁；

    在執行 HTML 中代碼時，根據須要，瀏覽器會繼續請求圖片、CSS、JavsScript等文件，過程同請求 HTML ；

斷開鏈接--四次揮手

    主機向服務器發送一個斷開鏈接的請求（不早了，我該走了）；

    服務器接到請求後發送確認收到請求的信號（知道了）；

    服務器向主機發送斷開通知（我也該走了）；

    主機接到斷開通知後斷開鏈接並反饋一個確認信號（嗯，好的），服務器收到確認信號後斷開鏈接；

補充說明

    爲何服務器在接到斷開請求時不當即贊成斷開：當服務器收到斷開鏈接的請求時，可能仍然有數據未發送完畢，全部服務器先發送確認信號，等全部數據發送完畢後再贊成斷開。

    第四次握手後，主機發送確認信號後並無當即斷開鏈接，而是等待了 2 個報文傳送週期，緣由是：若是第四次握手的確認信息丟失，服務器將會從新發送第三次握手的斷開鏈接的信號，而服務器發覺丟包與從新發送的斷開鏈接到達主機的時間正好爲 2 個報文傳輸週期。