瀏覽器的一個請求從發送到返回都經歷了什麼？

1.用戶輸入url，瀏覽器內部代碼將url進行拆分解析

讓咱們來看一個URL（統一資源定位器）
scheme://login:password@address:port/path/to/resource/?query_string#fragment
1 ： 協議名稱
2 ：層級URL的標記符號（固定不變，語法規定）
3 ：訪問資源須要的憑證信息（可選）
4 ：從哪一個服務器獲取數據
5 ：須要鏈接的端口號（默認80，可選）
6 ：指向資源的層級文件路徑
7 ：查詢字符串
8 ：片斷ID

爲何用IP沒法訪問網站，而用域名能夠？

由於虛擬主機，主機放置了N個網站，而每一個網站綁定1個或以上域名，因此用域名訪問主機能夠解析到網站目錄，但用IP的話服務器就不知道解析到那個目錄了。由於http請求裏包含了域名信息，因此用域名訪問，虛擬主機服務器會根據域名來返回網站，直接用IP訪問是由於沒有域名信息，因此服務器不知道要訪問的是哪一個網站，只有共享IP的虛擬主機或者VPS纔有這樣的狀況，像有綁定獨立IP功能或者獨立主機的服務器就能夠直接經過域名和ip均可以訪問。

2.瀏覽器作了哪些事情？

瀏覽器首先去找本地hosts文件，檢查在該文件中是否有相應的域名、IP對應關係，若是有，則向其IP地址發送請求，若是沒有就會將domain（域）發送給DNS（域名服務器）進行解析（解析以下圖），將域名解析成對應的服務器IP地址，發回給瀏覽器。

解釋 ：

1：瀏覽器客戶端向本地DNS服務器發送一個含有域名www.cnblogs.com的DNS查詢報文。
2：本地DNS服務器把查詢報文轉發到根DNS服務器，根DNS服務器注意到其com後綴，因而向本地DNS服務器返回comDNS服務器的IP地址。
3：本地DNS服務器再次向comDNS服務器發送查詢請求，comDNS服務器注意到其www.cnblogs.com後綴並用負責該域名的權威DNS服務器的IP地址做爲迴應。
4：最後，本地DNS服務器將含有www.cnblogs.com的IP地址的響應報文發送給客戶端。

補充一下DNS域名解析

目前你們訪問互聯網進行上網瀏覽信息時，正常是經過域名進行訪問，而實際上網絡中的計算機之間只能基於IP地址來相互訪問識別對方的身份，並且要想在互聯網中傳輸數據，也必須基於外網的IP地址來完成。這裏就出現了DNS域名系統技術來幫咱們簡化此過程，以此來下降用戶訪問網絡資源的門欄。爲何呢？由於它相對於IP地址，域名更容易被理解並記憶，這樣你們即可以經過域名來訪問互聯網中各項服務了。
簡單來講，就是可以接受用戶輸入的域名或IP地址，而後自動查找與之匹配的IP地址或域名，即將域名解析爲IP地址（正向解析），或將IP地址解析爲域名（反向解析）。這樣咱們只須要在瀏覽器中輸入域名就能打開想要訪問的網站了。目前，DNS域名解析技術的正向解析也是咱們最常使用的一種工做模式。

層級結構

鑑於互聯網中的域名和IP地址對應關係數據庫太過於龐大，DNS域名解服務器採用了相似目錄樹的層次結構來記錄域名與IP地址之間的對應關係，從而造成了一個分佈式的數據庫系統，以下圖 ：

三種類型

DNS域名系統技術做爲互聯網基礎設施中的重要一環，爲了提供不間斷、穩定且快速的域名查詢服務，保證互聯網的正常運轉，提供瞭如下三種類型的服務器 ：
主服務器 ：在特定區域內具備惟一性，負責維護該區域內的域名與IP地址之間的對應關係；
從服務器 ：從主服務器中得到域名與IP地址的對應關係並進行維護，以防主服務器宕機等狀況；
緩存服務器 ：經過向其餘域名解析服務器查詢得到域名與IP地址的對應關係，並常常查詢的域名信息保存到服務器本地，以此來提升重複查詢的效率。
主服務器是用於管理域名和IP地址對應關係的真正服務器，從服務器幫助主服務器「打下手」，分散部署在各個國家、省市或地區，以便讓用戶就近查詢域名，從而減輕主服務器的負載壓力。緩存服務器不太經常使用，通常部署在企業內網的網關位置，用於加速用戶的域名查詢請求。
DNS域名解析服務採用了分佈式的數據結構來存放海量的「區域數據」信息，在執行用戶發起的域名查詢請求時，具備遞歸查詢迭代查詢兩種方式。所謂的遞歸查詢，是指DNS服務器在收到用戶發起的請求時，必須向用戶返回一個準確的查詢結果。若是DNS服務器本地沒有存儲與之對應的信息，則該服務器須要詢問其餘服務器，並將返回的查詢結構提交給用戶。而迭代查詢則是指，DNS服務器在收到用戶發起的請求時，並不直接回複查詢結構，而是告訴另外一臺DNS服務器的地址，用戶再向這臺DNS服務器提交請求，這樣依次反覆，直到返回查詢結果。
運營商DNS  --》 根域名服務器 --》頂級域名服務器 --》域名註冊商服務器

網絡通訊

拿到服務器IP，分層由高到低分別爲 ：應用層、傳輸層、網絡層、數據鏈路層。發送端從應用層往下走，接收端從數據鏈路層往上走

首先 ：應用層客戶端發送HTTP請求

HTTP請求包括請求報頭和請求主體兩個部分，其中請求報頭了相當重要的信息，包括請求的方法（GET/POST）、目標url、遵循的協議（http/https/ftp..）,返回的信息是否須要換成，以及客戶端是否發送cookie等。

而後：傳輸層TCP傳輸報文

位於傳輸層的TCP協議爲傳輸報文提供可靠的字節流服務。它爲了方便傳輸，將大塊的數據分割成以報文段爲單位的數據包進行管理，併爲它們編號，方便服務器接收時能準確地還原報文信息。TCP協議經過「三次握手」等方法保證傳輸的安全可靠。
客戶端發送一個帶有SYN標誌的數據包給服務端，在必定的延遲時間內等待接收的回覆。服務端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息，最後客戶端再回傳一個帶ACK標誌的數據包，表明握手結束，鏈接成功。
SYN（Synchronize Sequence Numbers）同步序列編號
ACK（Acknowledgement）確認字符

接着 ：網絡層IP協議查詢MAC地址

IP地址的做用是把TCP分割好的各類數據包傳遞給接收方。而要保證確實能傳到接收方還須要接收方的MAC地址，也就是物理地址。IP地址和MAC地址是一一對應的關係，一個網絡設備的IP地址能夠更換，可是MAC地址通常是固定不變的。ARP協議能夠將IP地址解析成對應的MAC地址。當通訊的雙方不在用一個局域網時，須要屢次中轉才能到達最終的目標，在中轉的過程當中須要經過下一個中轉站的MAC地址來搜索下一個中轉目標。
數據到達數據鏈路層
在招待對方的MAC地址後，就將數據發送到數據鏈路層傳輸，這時，客戶端發送請求的階段結束。

再次 ：服務器接收數據

接收端的服務器在鏈路層接收到數據包，再層層上直到應用層。這過程當中包括在運輸層經過TCP協議將分段的數據包從新組成原來的HTTP請求報文。

服務器響應請求

服務接收到客戶端發送的HTTP請求後，查找客戶端請求的資源，並返回響應報文，響應報文中包括一個重要的信息 -- 狀態碼。狀態碼由三位數字組成。

服務器返回相應文件

服務器端收到請求後的由web服務器（準確說應該是http服務器）處理請求，諸如Apache、Ngnix、IIS等。web服務器解析用戶請求，知道了須要調度那些資源文件，再經過相應的這些資源文件處理用戶請求和參數，並調用數據庫信息，最後將結果經過web服務器返回給瀏覽器客戶端。

關閉TCP鏈接

爲了不服務器與客戶端雙方的資源佔用和損壞，當雙方沒有請求或響應傳遞時，任意一方均可以發起關閉請求。與建立TCP鏈接的3次握手相似，關閉TCP鏈接，須要四次握手。

參考 ：http://www.cnblogs.com/echo-hui/p/9298203.html