從輸入URL到頁面渲染完成

原文-英文
譯文

推薦閱讀《圖解HTTP》

各類協議與HTTP協議的關係(參照該圖理解下文)

1. 輸入URL地址

2. 瀏覽器根據域名查詢IP地址

從要訪問的域名中獲取IP地址，DNS查詢的步驟以下：

1. 從瀏覽器緩存中查詢。瀏覽器會存儲必定時間的DNS記錄，操做系統不會告訴瀏覽器每一個DNS記錄的保存時限，不一樣瀏覽器設置保存時限爲一個固定值（不一樣瀏覽器狀況不一樣，通常在2-30分鐘）。
2. 從操做系統緩存中查詢。若是瀏覽器中沒有包含想要的緩存記錄，那瀏覽器就會發起操做系統請求，繼續查詢操做系統緩存
3. 從路由器中查詢DNS緩存。請求持續發送到你的路由，它一般會有本身的DNS緩存。
4. 從ISP中查詢DNS緩存。下一個被查詢地方是ISP緩存DNS的服務器。
5. 域名服務器遞歸查詢。首先從root域名服務器中查詢如.com域名服務器，而後逐步向前查詢，.com頂級域名服務器到Facebook的域名服務器。通常來講，.com級別的都已經在緩存中了，因此通常不會進行對root域名服務器的查詢。下面給出一張遞歸查詢的圖。

擴展

什麼是DNS？

DNS（Domain Name System，域名系統），因特網上做爲域名和IP地址相互映射的一個分佈式數據庫，可以使用戶更方便的訪問互聯網，而不用去記住可以被機器直接讀取的IP數串。經過主機名，最終獲得該主機名對應的IP地址的過程叫作域名解析（或主機名解析）。

DNS查詢的兩種方式：遞歸查詢和迭代查詢

一、遞歸解析

當局部DNS服務器本身不能回答客戶機的DNS查詢時，它就須要向其餘DNS服務器進行查詢。
此時有兩種方式，如圖所示的是遞歸方式。
局部DNS服務器本身負責向其餘DNS服務器進行查詢，通常是先向該域名的根域服務器查詢，再由根域名服務器一級級向下查詢。
最後獲得的查詢結果返回給局部DNS服務器，再由局部DNS服務器返回給客戶端。

二、迭代解析

當局部DNS服務器本身不能回答客戶機的DNS查詢時，也能夠經過迭代查詢的方式進行解析，如圖所示。
局部DNS服務器不是本身向其餘DNS服務器進行查詢，而是把能解析該域名的其餘DNS服務器的IP地址返回給客戶端DNS程序，客戶端DNS程序再繼續向這些DNS服務器進行查詢，直到獲得查詢結果爲止。
也就是說，迭代解析只是幫你找到相關的服務器而已，而不會幫你去查。
好比說：baidu.com的服務器ip地址在192.168.4.5這裏，你本身去查吧，本人比較忙，只能幫你到這裏了。

DNS域名稱空間的組織方式

咱們在前面有說到根DNS服務器，域DNS服務器，這些都是DNS域名稱空間的組織方式。
按其功能命名空間中用來描述 DNS 域名稱的五個類別的介紹詳見下表中，以及與每一個名稱類型的示例:

3. 瀏覽器發送HTTP請求到web服務器

向 http://facebook.com/ 發出GET請求

HTTP請求報文

在請求中，HTTP報文首部由方法、URI、HTTP版本、HTTP首部字段等構成。

確保可靠性的TCP協議

擴展

TCP三次握手

• 第一次握手：
  客戶端A將標誌位SYN置爲1,隨機產生一個值爲seq=J（J的取值範圍爲=1234567）的數據包到服務器，客戶端A進入SYN_SENT狀態，等待服務端B確認；
• 第二次握手：
  服務端B收到數據包後由標誌位SYN=1知道客戶端A請求創建鏈接，服務端B將標誌位SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給客戶端A以確認鏈接請求，服務端B進入SYN_RCVD狀態。
• 第三次握手：
  客戶端A收到確認後，檢查ack是否爲J+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給服務端B，服務端B檢查ack是否爲K+1，ACK是否爲1，若是正確則鏈接創建成功，客戶端A和服務端B進入ESTABLISHED狀態，完成三次握手，隨後客戶端A與服務端B之間能夠開始傳輸數據了。

爲什須要三次握手？

《計算機網絡》第四版中講「三次握手」的目的是「爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤」

書中的例子是這樣的，「已失效的鏈接請求報文段」的產生在這樣一種狀況下：client發出的第一個鏈接請求報文段並無丟失，而是在某個網絡結點長時間的滯留了，以至延誤到鏈接釋放之後的某個時間纔到達server。
原本這是一個早已失效的報文段。但server收到此失效的鏈接請求報文段後，就誤認爲是client再次發出的一個新的鏈接請求。因而就向client發出確認報文段，贊成創建鏈接。

假設不採用「三次握手」，那麼只要server發出確認，新的鏈接就創建了。因爲如今client並無發出創建鏈接的請求，所以不會理睬server的確認，也不會向server發送數據。但server卻覺得新的運輸鏈接已經創建，並一直等待client發來數據。這樣，server的不少資源就白白浪費掉了。採用「三次握手」的辦法能夠防止上述現象發生。

例如剛纔那種狀況，client不會向server的確認發出確認。server因爲收不到確認，就知道client並無要求創建鏈接。」。主要目的防止server端一直等待，浪費資源。

TCP四次揮手

• 第一次揮手：
  Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。
• 第二次揮手：
  Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
• 第三次揮手：
  Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。
• 第四次揮手：
  Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1，Server進入CLOSED狀態，完成四次揮手。

爲何創建鏈接是三次握手，而關閉鏈接倒是四次揮手呢？

這是由於服務端在LISTEN狀態下，收到創建鏈接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。

而關閉鏈接時，當收到對方的FIN報文時，僅僅表示對方再也不發送數據了可是還能接收數據，己方也未必所有數據都發送給對方了，因此己方能夠當即close，也能夠發送一些數據給對方後，再發送FIN報文給對方來表示贊成如今關閉鏈接，所以，己方ACK和FIN通常都會分開發送。

什麼是反向代理？

客戶端原本能夠直接經過HTTP協議訪問某網站應用服務器，網站管理員能夠在中間加上一個Nginx，客戶端請求Nginx，Nginx請求應用服務器，而後將結果返回給客戶端，此時Nginx就是反向代理服務器。

負責傳輸的IP協議

• IP間的通訊依賴MAC地址
• ARP協議：(Address Resolution Protocol)用以解析地址的協議，根據通訊方的IP地址就能夠反查出對應的MAC地址

4. Facebook服務器返回一個永久重定向響應

服務器會發送一個301永久重定向響應來告訴瀏覽器訪問 http://www.facebook.com/ 而不是 http://facebook.com/。

爲何服務器堅持重定向而不是直接給予瀏覽器用戶須要的結果，這有不少有意思緣由:

• 一個緣由是搜索引擎排名，若是有兩個URLs指向同一個頁面，好比 http://www.igoro.com/ 和 http://igoro.com/ ,搜索引擎會認爲這是兩個不一樣的網站，結果他們兩個每一個都有一部分訪問量，可是也只能擁有更低的搜索引擎排名。若是使用了301定位，搜索引擎將會識別重定向，進而將同一來源的多個連接算做一個。
• 另外一個緣由是，一樣的內容多個URLs還不利於緩存，一樣的內容擁有多個名字，潛在形成緩存浪費。

擴展

301和302的區別：

301和302狀態碼都表示重定向，就是說瀏覽器在拿到服務器返回的這個狀態碼後會自動跳轉到一個新的URL地址，這個地址能夠從響應的Location首部中獲取（用戶看到的效果就是他輸入的地址A瞬間變成了另外一個地址B）——這是它們的共同點。

他們的不一樣在於。301表示舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜索引擎在抓取新內容的同時也將舊的網址換爲重定向以後的網址；

302表示舊地址A的資源還在（仍然能夠訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜索引擎會抓取新的內容而保存舊的網址。 SEO 302好於301

重定向緣由：

• 網站調整（如改變網頁目錄結構）；
• 網頁被移到一個新地址；
• 網頁擴展名改變(如應用須要把.php改爲.Html或.shtml)。
  這種狀況下，若是不作重定向，則用戶收藏夾或搜索引擎數據庫中舊地址只能讓訪問客戶獲得一個404頁面錯誤信息，訪問流量白白喪失；再者某些註冊了多個域名的網站，也須要經過重定向讓訪問這些域名的用戶自動跳轉到主站點等。

何時進行301或者302跳轉呢？

當一個網站或者網頁24—48小時內臨時移動到一個新的位置，這時候就要進行302跳轉，而使用301跳轉的場景就是以前的網站由於某種緣由須要移除掉，而後要到新的地址訪問，是永久性的。

清晰明確而言：使用301跳轉的大概場景以下：

一、 域名到期不想續費（或者發現了更適合網站的域名），想換個域名。
二、 在搜索引擎的搜索結果中出現了不帶www的域名，而帶www的域名卻沒有收錄，這個時候能夠用301重定向來告訴搜索引擎咱們目標的域名是哪個。
三、 空間服務器不穩定，換空間的時候。

5. 瀏覽器會跟蹤重定向地址

瀏覽器知道了 http://www.facebook.com/ 是真正應該訪問的URL，因此就發送了另一個GET請求。

6. 服務器處理請求

服務器會接收這個GET請求，而且返回一個響應結果

怎麼存儲數據是每一個動態網站都會面臨的有趣難題

小網站會常常有一個SQL數據庫來存儲他們的數據，可是網站存儲數據量過大或者流量過大後就必須將數據庫分佈在多臺機器，解決的方法有不少種

包括sharding(在主鍵基礎上劃分表到多個數據庫中)，複製和使用簡化的弱語義一致性數據庫

推遲一些任務到批處理做業是廉價保持數據更新的的一種技術。

例如，Facebook必須儘快更新新聞供應，但數據支持的「你可能認識的人」功能可能只須要每晚進行更新（做者猜想是這樣）。批處理做業的更新致使存在一些舊的相對不重要的數據，可是使數據更新更快更簡單。

7.服務器返回一個HTML響應

HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
    pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT
...

整個完整的響應是36KB，其中大部分處理後由blob類型傳送
內容編碼頭部告訴瀏覽器響應體使用了gzip壓縮算法。在解析blob後，你就會看到你指望的HTML了。

8. 瀏覽器開始渲染HTML

在瀏覽器接收完整HTML文件前，瀏覽器就開始渲染頁面了。

9. 瀏覽器發送嵌入在HTML中的對象的請求

隨着瀏覽器渲染HTML，瀏覽器會注意到有些標籤須要請求其餘URLs的資源，瀏覽器將會發送一個GET請求來從新獲取每一個文件 。

10. 瀏覽器發送異步請求

在web2.0時代，即便在頁面渲染後客戶端仍是持續與服務器端通訊。

例如，當你的朋友上線或下線時，Facebook聊天功能將會持續更新你已經登陸的朋友列表。爲了更新這個列表，你瀏覽器上運行的JS將會發送異步請求到服務器，異步請求是發送給特殊URL的GET或POST請求。在Facebook的例子中，客戶端會發送一個POST請求到 http://www.facebook.com/ajax/chat/buddy_list.php ，獲取你在線的朋友列表

這個模式被稱爲AJAX，是「Asynchronous JavaScript And XML」,的縮寫，雖然不太清楚爲何服務器必須將響應格式化爲xml。

相關閱讀：

當你訪問淘寶的時候，發生了什麼？