輸入網址

當你輸入網址時，通過會輸入一個域名而非一個IP地址，因為IP地址是很難記憶的，一般需要特定物件告知才能訪問，比如云服務器商提供的IP，自建服務器搞到的公網IP，公司學校的特定公開局域網IP等等，但是大部分時候，我們往往會輸入www.baidu.com這樣的東西來訪問網站，這種東西叫做域名，
域名系統（Domain Name System） 是互聯網使用的命名系統，用來把人們使用的及其名字轉換為IP地址，當你輸入URL的時候，你就間接的使用了DNS，
DNS是應用層協議，事實上他是為其他應用層協議作業的，包括不限于HTTP和SMTP以及FTP，用于將用戶提供的主機名決議為ip地址，

我們的電腦上運行著DNS服務的客戶端，負責接收域名并執行決議作業，最終得到IP地址，

所以，瀏覽器抽取域名，并請求本機的DNS客戶端，進行域名決議，

DNS決議

1. 本地域名決議

在早期的時候，網路上只有數百臺計算機，因此我們只使用一個叫做hosts的檔案，記錄域名和對應的IP地址，每當我們進行訪問的時候，計算機就根據URL到這個檔案中查表，自動決議域名至IP，這樣就可以進行訪問了，這個檔案現在還在我們的電腦上存在，每當我們輸入URL的時候，首先DNS決議器客戶端查詢本地的快取和hosts檔案看是否能直接本地決議域名，若不能，決議器會將待決議的域名放在DNS請求報文中，以UDP方式發給本地域名服務器，本地服務器代理執行域名決議操作，能則回傳，DNS決議步驟成功，
本地域名服務器不是指在自己的機器上的服務器，而是一個設定好的DNS服務器IP地址，比如WINDOWS系統的網路設定中的DNS服務器和備用DNS服務器地址，他們距離用戶較近，一般不超過幾個路由器的距離，

2.遞回和迭代決議域名

當本地服務器接收到請求之后，就由本地服務器進行域名查詢，本地服務器可以到互聯網請求其他服務器幫助查詢域名，
互聯網的域名系統被設計為一個聯機分布式資料庫系統，采用C/S方式進行連接，因此互聯網上存在許多域名服務器在專設的節點上運行，
本地域名服務器在查找域名后，就會把對應的IP放在回答報文中回傳，行程即可獲得IP地址后進行通信了，DNS 查詢以各種不同的方式進行決議，

• DNS 服務器可使用其自身的資源記錄資訊快取來應答查詢，也可代表請求客戶機來查詢或聯系其他 DNS 服務器，以完全決議該名稱，并隨后將應答回傳至客戶機，這個程序稱為遞回，
• 另外，客戶機自己也可嘗試聯系其他的 DNS 服務器來決議名稱，如果客戶機這么做，它會使用基于服務器應答的獨立和附加的查詢，該程序稱作迭代，即DNS服務器之間的互動查詢就是迭代查詢，

采用遞回和迭代取決于最初報文設定的哪種方式，一般都是遞回查詢，
遞回和迭代具體的判斷方法如下，結合圖片進行理解，
1.DNS客戶端和本地名稱服務器是遞回，而本地名稱服務器和其他名稱服務器之間是迭代，
2.DNS客戶端和本地名稱服務器是遞回，而本地名稱服務器和其他名稱服務器之間也是遞回，

建立TCP鏈接

• 鏈接建立
  獲取到IP之后，需要向HTTP服務器獲取網站資源了，要使用HTTP協議，首先需要建立和網站的鏈接，HTTP協議是基于TCP鏈接的應用層協議，因此首先要和目標站點建立TCP鏈接，
  TCP鏈接建立的程序，通常被稱為三次握手，

報文格式

在進行講解之前，先了解一下報文格式，
在進行握手的時候，我們主要會用到序列號seq、確認號ack、SYN、ACK、FIN這幾個報文段，

　　序列號（Sequence Number）：該欄位用來標識TCP源端設備向目的端設備發送的位元組流，它表示在這個報文段中的第幾個資料位元組，序列號是一個32位的數，
　　確認號（Acknowledge Number）：TCP使用32位的確認號欄位標識期望收到的下一個段的第一個位元組，并宣告此前的所有資料已經正確無誤地收到，因此，確認號應該是上次已成功收到的資料位元組序列號加1，收到確認號的源計算機會知道特定的段已經被收到，確認號的欄位只在ACK標志被設定時才有效，
　　ACK（Acknowledgement field significant，確認欄位標志）： 取1時表示應答欄位有效，也即TCP應答號將包含在TCP段中，為0則反之，
　　SYN（Synchronize sequence numbers，同步序列號）：表示同步序號，用來建立連接，為1時，表示處于同步階段，為0則反之，
　　FIN（No more data from sender）：表示發送端已經發送到資料末尾，資料傳送完成，發送FIN標志位的TCP段，連接將被斷開，此時進入四報文揮手階段，

三報文握手

三報文握手即為三次握手，叫他三報文握手的原因是，我們其實是通過三次報文交換達成了一次握手，從而建立鏈接，而不是握手了三次，這聽起來就跟建立三次連接一樣，有一定的語意模糊，

握手的目標

1. 讓每一方都確定對方的存在
2. 允許雙方協調一些引數
3. 對運輸物體資源進行分配，

TCP協議的握手需要滿足可靠性，因為TCP協議保證了資訊傳輸必須可靠，

握手的程序

第一次報文發送 客戶端向服務端發送連接請求報文段，
該報文段的頭部中SYN=1，ACK=0，seq=x，
請求發送后，客戶端便進入SYN-SENT狀態，

第二次報文發送 服務端收到連接請求報文段后，如果同意連接，則會發送一個應答：
SYN=1，ACK=1，seq=y，ack=x+1， 該應答發送完成后便進入SYN-RCVD狀態，

第三次報文發送 當客戶端收到連接同意的應答后，還要向服務端發送一個確認報文段，表示：服務端發來的連接同意應答已經成功收到， 該報文段的頭部為：
ACK=1，seq=x+1，ack=y+1，
客戶端發完這個報文段后便進入ESTABLISHED狀態，服務端收到這個應答后也進入ESTABLISHED狀態，此時連接的建立完成！
規律總結：
SYN是同步的意思，在第一次請求的時候 SYN=1,ACK=0,表示第一次請求連接，
服務器回應請求的時候，使用SYN=1，ACK=1,ACK表示對客戶端的握手請求進行回應，

• ACK規律：在連接建立后所有傳送的報文段都必須把ACK置為1.
  第三次請求，SYN=0，說明不是第一次請求了，此時鏈接已經建立了，SYN=0，ACK在之后永遠為1.
• seq規律：seq在起始的時候隨機一個數進行產生，范圍是 [ 0 , 2 32 ? 1 ] [0,2^{32}-1] [0,232?1]，即32位bit的長度，他的含義是本報文段所發送的資料的第一個位元組的序號，雖然握手三報文沒有資料，只有報文頭，協議還是規定占1長度，因此是x+1這樣的表示，
• ack規律：ack表示的是期望收到對方下一個報文段的第一個資料位元組的序號，比如服務器回應的時候ack=x+1，就是期望下次收到一個seq=x+1的序號，在握手的時候，資料長度為1，因此是x+1，但是在傳輸狀態的時候，因為存在要傳輸的資料體，那么期望序號應該就是上次的收到的客戶端的序號x+資料體的長度了，比如x=501,資料體長度=200，那么501+200就可以得出701，此為下次期望收到的seq序號，
  

為什么不是兩次報文交換？

我們可以看到，前兩次之后SYN已經置為0，說明建立了鏈接，那么為什么還需要第三次報文發送？這是基于可靠性進行考慮的做法，
設想以下情況：

原因： 已失效的連接請求報文段

當A發送一個握手請求到B，但是由于網路抖動、網路時延，過了一段時間B沒有向A發回應，那么A就會重傳一個握手包過去，此時有2次握手的報文向B發送了，則B很可能會接收到兩次握手請求，那么此時如果是二報文握手，B就會認為這是兩個鏈接建立請求，會認為應該建立2次鏈接，那么B就會先建立2個鏈接資源，切換狀態，并發送2次回應，這就導致資源浪費了，因為其中一個鏈接永遠不會有資料發來，若是三報文握手，就能防止這樣的現象的發生，因為A只會進行一次回應，這樣B就知道A并沒有2次要求建立鏈接了，

HTTP請求

發送HTTP請求

在建立連接之后，就可以發送請求了，此時瀏覽器依據HTTP協議，向服務器發送請求，具體的請求內容可以F12查看，一個HTTP請求報文就發送出去了，
如下圖所示，我們可以從右邊看到請求的報文頭，具體的內容，請參考HTTP協議語法規定等等，這些字符將作為TCP流中的內容發送到服務器，然后服務器再通過TCP將內容進行回應，

可以看到左邊密密麻麻的多個回應，這就是多次瀏覽器和服務器進行HTTP協議通訊的程序，根據HTTP協議版本和頭資訊，這些內容有可能每次都需要TCP握手，也有可能握手之后保活（keep-alive），從而不需要再建立TCP通道，直接多次進行HTTP協議的通信，

HTTP協議中，規定可以從瀏覽器本地快取網頁，因此如果HTTP請求有快取欄位，有可能直接在本地就獲取資源，不需要發送請求通過互聯網獲取資源了，

良好的快取策略可以降低資源的重復加載，提高網頁的整體加載速度，

具體的快取策略如下，

強快取與協商快取

此處參考快取（二）——瀏覽器快取機制：強快取、協商快取
想要詳細學習，可以進入進一步了解，
通常瀏覽器快取策略分為兩種：強快取和協商快取
1、基本原理

1）瀏覽器在加載資源時，根據請求頭的expires和cache-control判斷是否命中強快取，是則直接從快取讀取資源，不會發請求到服務器，
2）如果沒有命中強快取，瀏覽器一定會發送一個請求到服務器，通過last-modified和etag驗證資源是否命中協商快取，如果命中，服務器會將這個請求回傳，但是不會回傳這個資源的資料，依然是從快取中讀取資源
3）如果前面兩者都沒有命中，直接從服務器加載資源

2、相同點
如果命中，都是從客戶端快取中加載資源，而不是從服務器加載資源資料；

3、不同點
強快取不發請求到服務器，協商快取會發請求到服務器，

當快取命中，可以觀察F12進行判斷，可以看到從磁盤或記憶體快取中直接拿出了網頁資源，

具體流程圖如下，可以看到，先進行強快取命中判斷，再進行協商快取判斷，還有過期、版本判斷等等，最終得到資源，

轉發HTTP請求

一個HTTP請求報文在互聯網中并不是點對點傳輸到對方服務器的，這其中要經過很多的中轉站進行轉發，比如路由器，又或者特殊的快取節點，又或者公司的網關等等，進行層層轉發后，才會最終到達目標服務器，這其中有幾種比較特殊的節點，

代理服務器節點

代理服務器把最近的一些請求和回應暫存在本地磁盤中，當請求與快取的相同，就可以直接回傳，不需要去繼續轉發了，這樣就減少了給服務器的壓力，服務器處理的請求更少，回應速度快，請求時延也會降低，性能就可以得到一定的優化，

反向代理節點

反向代理服務器,如Nginx，對請求進行反向代理，轉發請求到其他IP埠，從而進行負載均衡等功能，

HTTP服務器

Nginx可以充當簡單的靜態服務器，回傳http進行應答，Tomcat、Apache等軟體也可以當Http服務器，進行應答，在復雜的架構當中，HTTP服務器可以充當業務網關，進行復雜的權限管理、灰度測驗轉發等安全和運維方面的配置，然后在公司的業務集群中進行多次網路通信，最后給出結果，

處理HTTP請求

對HTTP進行處理，根據網站的復雜程度，動態網站需要運行腳本，根據模板和業務邏輯處理回傳靜態的HTTP資訊，也可以直接回傳HTTP和各種資源，再通過Ajax等異步手段，發起請求，異步獲取網頁資訊，
通過HTTP服務器，可以將請求頭決議，程式員通過API獲取請求資訊，并作出業務處理，產生相應的動作和資料，然后使用模板或者JSON方式回傳資訊，

回應HTTP請求

回傳的時候，HTTP服務器會組裝HTTP回應頭，程式員也可通過配置HTTP服務器或者使用編程語言修改頭部部分欄位，最終通過TCP方式，將HTTP回應報文發送到瀏覽器客戶端，

關閉TCP鏈接

發送完HTTP請求之后，需要關閉TCP的連接通道，這樣的時候僅需要進行TCP的連接釋放，
這時候就需要進行四次揮手，其實揮手也是一種握手，表示埠之間進行協商的程序，

四報文揮手

• 步驟一
  客戶端向服務端發送報文，報文中，FIN=1，seq=u，其中seq是前面已傳送過的資料的最后一個位元組的序號加一，A進入FIN－ＷAIT-1狀態
• 步驟二
  服務端接收到資訊，進行回應，此時報文內容是ACK=1，seq=v，ack=u+1，v的大小與u的規律是一樣的，然后服務端進入CLOSE－WAIT狀態，并且此時TCP服務器行程會對高層應用進行通知，在此時，鏈接已經處于半關閉狀態，如果服務端向客戶端發送資料，客戶端仍要接收，
• 步驟三
  客戶端收到服務端的通知后，進入FIN-WAIT-2狀態，
• 步驟四
  如果服務端已經沒有向客戶端發送的資料，就會通知TCP釋放服務端到客戶端的連接，這個時候發送的報文內容是FIN=1，ACK=1，seq=w,因為服務端可能又發送了一些資料，w表示上次發送末尾的seq序號的+1，ack為u+1這里的u+1就是上次客戶端終結握手的時候發送的u+1，這個時候B進入了LAST-ACK狀態，
• 步驟五
  客戶端在收到服務端的通知之后，發出確認報文，ACK=1，seq=u+1,ack=w+1，進入到TIME-WAIT狀態，在這個狀態等待2MSL之后，客戶端進入到了CLOSE狀態，
  具體圖解如下：

TIME-WAIT狀態的意義

為什么在TIME-WAIT狀態要等待2MSL的時間呢？這也是基于可靠性來考慮的，

場景一

如果在最后的ACK沒有發送到服務端，服務端就會一直在LAST-ACK狀態進行等待，無法順利進入CLOSE狀態，這必然導致資源的浪費，為了解決這個問題，服務器就會發起超時重傳，重新發送一個FIN=1的ACK訊息，這個時候，處于TIME-WAIT的客戶端就可以再次發送確認的報文，并重置TIME-WAIT的計時，這樣服務端就能順利關閉了，

場景二

協議認為，在2MSL的時間后，本連接持續時間內產生的所有報文都會從網路上消失，不會有“已失效的連接報文欄位”這種現象的發生，因此需要等待2MSL，等待報文失效，這樣就能確保下次再次進行連接是新的連接，而不是由于重傳等導致的無效連接請求了，

瀏覽器決議資源

DOM決議

當HTTP傳輸到瀏覽器后，瀏覽器就會啟動資源決議流程，
瀏覽器對HTTP檔案進行詞法分析，從而把HTML檔案化為一顆檔案樹的資料結構，
HTTP的本質是XML，XML可以被決議為樹的資料結構，而HTTP決議之后的樹叫做DOM Tree

此時瀏覽器也會接收CSS、圖片資源、各種資源合并到DOM的決議當中，遇到JS資源的時候，也會對JS進行語法決議等一系列步驟，并執行js，

瀏覽器布局渲染

顯示Render樹

瀏覽器對CSS規則、DOM樹、圖片、JS檔案等資源進行復雜的處理之后，會形成一顆渲染樹，此時瀏覽器就會對渲染樹進行重繪和顯示了，當JS操作DOM或者有其他情況發生的時候，會觸發回流(reflow)現象，導致瀏覽器的重繪，這可能是一項耗時的作業，現代前端框架Vue、React等使用Virtual DOM來合并對DOM的修改操作，盡可能減少多次重繪帶來的性能損失，