從輸入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查詢的兩種方式：遞迴查詢和迭代查詢

1、遞迴解析

當局部DNS伺服器自己不能回答客戶機的DNS查詢時，它就需要向其他DNS伺服器進行查詢。
此時有兩種方式，如圖所示的是遞迴方式。
區域性DNS伺服器自己負責向其他DNS伺服器進行查詢，一般是先向該域名的根域伺服器查詢，再由根域名伺服器一級級向下查詢。
最後得到的查詢結果返回給區域性DNS伺服器，再由區域性DNS伺服器返回給客戶端。

2、迭代解析

當局部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跳轉的大概場景如下：

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

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。

相關閱讀：

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