當你在地址欄輸入一個URL地址回車後，將會發生什麼事情-第一次回答

寫在前面

最近在學習計算機網絡，看的是《自頂向下》那本書，而且找到了國立清華大學以此書做爲教材錄製的公開課。不一樣於一般計算機網絡教學書籍的知識安排——從網絡的低層次開始到高層次，本書是從高層次開始，而後深刻到低層次，其主要的優點在於可以調動學生學習的動力。對於一個學習前端的人，在看完第一章對計算機網絡整體的簡介後，書籍隨後的第二章就開始講解計算機網絡層次中的最頂層——應用層，在此就能夠接觸到咱們熟悉或者應該熟悉的HTTP協議和DNS服務。

在學習網絡過程當中，我深感僅僅看書和視頻是不夠的，儘管每一章都提供了實踐題目，可是其知識點過於針對性，沒法使各個部分的知識串聯起來。在我看來，把知識串聯起來是學習網絡很是重要的一環，爲了達到這個目的，我發現回答 當你在地址欄輸入一個URL地址回車後，將會發生什麼事情？ 這個問題，是一個很是好的練習。爲此我決定，每學完一個計算機網絡的層次，便對這個問題進行一次回答。本次是第一次，對應到書籍上，也就是完成第二章對 應用層 的學習。

正文

• 輸入url(juejin.im/timeline)並回車後，瀏覽器會建立一個udp類型的socket。

• 瀏覽器經過這個socket，向本地dns服務器發送查詢請求報文(message)，要求其返回域名(juejin.im)對應的ip地址

• 通常狀況下，本地dns服務器不知道域名對應ip地址，因而便向dns根服務器查詢，要求其返回域名對應的ip地址

• 根服務器經過查詢，雖然沒找到域名對應的ip地址，可是找到了存儲以.im結尾域名對應ip地址的dns頂級域服務器，返回一個包含(name, value, type, ttl)被稱爲資源記錄的四元組

• 其中name是juejin.im表示要查詢的域名，value也是一個地址，對應着知道juejin.im對應ip的權威dns服務器的地址（頂級域服務器也沒有直接給出域名對應的地址），type是NS，表示返回的是另外一個dns服務器的地址，ttl是這條記錄的有效時間。

• 本地dns服務器接收到報文後，把根據報文內容，向權威dns服務發送查詢請求

• 權威dns服務器查詢到對應的ip地址，一樣返回包含資源記錄的四元組，不一樣的是，value是域名對應的ip地址。type是A，表示這條記錄的內容是域名到ip的映射

• 本地dns服務器獲得域名對應的ip地址，返回給瀏覽器建立的udp socket

• 瀏覽器獲得域名對應的ip地址

• 瀏覽器建立了一個tcp類型的socket(下文簡稱爲 tcp socket)，向目標ip地址的80號端口發起了鏈接

• tcp socket首先與服務器的**歡迎套接字(welcome socket)**完成三次握手

• 完成三次握手後，服務器會建立一個**鏈接套接字(connection socket)**專用於握手後的tcp socket

• 此時tcp鏈接正式創建，瀏覽器將經過這個tcp sokcet向服務器發送類型爲請求報文的報文(message)(此報文類型由http協議規定)

• 請求報文通常由**請求行(request line)和多個請求頭部(request header)行以及請求體(request body)**組成

• 請求報文至少含有請求行

• 請求行的格式爲 method url http-version\r\n

• 例：GET /timeline HTTP/1.1

• GET是請求方法(method)，/timeline是url，HTTP/1.1是客戶端使用的HTTP協議版本,\r\n表示crlf類型的換行符

• 服務器經過鏈接套接字獲得tcp socket傳輸過來的請求報文

• 服務器經過分析請求報文，找到被請求的文件

• 服務器生成類型爲響應報文的報文

• 響應報文通常包含狀態行(status line)，多個頭部行(header line)和響應體(entity body)

• 狀態行格式爲http/version statusCode statusMessage

• 例：HTTP/1.1 200 OK

• HTTP/1.1表示服務器使用的HTTP協議爲1.1版本，200是本次響應的狀態號碼，200表示本次響應是正常的，OK是對狀態號的簡短解釋

• 頭部行取決於服務器的設計

• 響應體則是被請求對象的數據

• 服務器經過鏈接套接字返回響應報文

• 瀏覽器接收到響應報文，分析內容，渲染出來

上面沒提到的

dns緩存機制

在通常dns查詢的過程當中，存在着緩存機制，不須要來回跑那麼多趟，也許一次請求就拿到對應ip地址了

沒說http緩存機制

http協議也存在緩存相關的規定，經過設置頭部和條件GET等方式，能夠加快獲取網頁的速度

關於http請求複用tcp鏈接

假若每個http請求都要走一次三次握手和發收報文的流程，會致使性能上的浪費以及太高的響應時間。把發出請求到收到響應的時間稱爲一個往返時間(RRT)，三次握手會消耗一個RRT，發收報文會消耗一個RRT，對於一個含有四個圖片的網頁來講，在串行請求且不復用tcp鏈接狀況下，須要10個RRT時間才能顯示完整的頁面。而複用TCP鏈接的狀況下，只須要6個RRT時間。(這裏忽略了服務器處理請求的時間，而且簡化了三次握手和發收報文的流程，在真實的狀況下，三次握手和發收報文並非徹底割裂的兩個行爲，其中存在着交集)

http是無狀態的協議

爲了儘量的簡單，http協議不要求保持狀態(儘管這和咱們的認知不合,好比說你在淘寶上把商品加入購物車，在另外一個電腦登錄時依然存在)。我我的對此的理解時，http協議自己在設計時就沒有考慮保持狀態的生氣，雖然http協議經過使用cookie的技術使得服務器能夠區分請求的發送者，但這是在http層面上的一層進行的一種封裝，服務器自己是沒法經過http協議自己來區分請求者的。做爲對比，ftp協議就是有狀態(設計時就考慮到這點)的協議，在使用ftp協議時，須要兩條tcp鏈接，一條用來維持狀態，發出命令，一條用來傳輸數據。