摘要：但收到此失效的連接請求報(bào)文段后，就誤認(rèn)為是再次發(fā)出的一個(gè)新的連接請求。采用三次握手的辦法可以防止上述現(xiàn)象發(fā)生。

概覽

日期：2018-4-26
目標(biāo)：了解從輸入URL到頁面加載完成的過程中都發(fā)生了什么事情
總用時(shí)：一天
完成情況：達(dá)成

基本過程

為什么會(huì)想要了解從輸入URL到頁面加載完成的過程中都發(fā)生了什么事情這個(gè)問題呢，因?yàn)檎n程參考資料的Web 建站技術(shù)中HTML、HTML5、XHTML、CSS、SQL、JavaScript、PHP、ASP.NET、Web Services 是什么中最高票答案中給出了下圖所示的網(wǎng)站訪問基本過程，張秋怡學(xué)姐的解答也十分易懂：

再者這個(gè)問題可謂是常見的面試題之一，而這張圖中只是給出了非常基本的一個(gè)前后端交互的過程，由于自己有基礎(chǔ)，所以列出的相關(guān)概念也都基本理解了，于是就花些時(shí)間擴(kuò)展一下

跟我一起來學(xué)起來

我們在打開瀏覽器，然后在輸入URL的時(shí)候有沒有發(fā)現(xiàn)瀏覽器會(huì)給你一些你似曾相識(shí)且與你輸入的內(nèi)容相匹配的網(wǎng)址呢？

其實(shí)我們在瀏覽器中輸入URL的時(shí)候，瀏覽器就會(huì)開始智能的匹配可能URL，瀏覽器會(huì)從歷史記錄，書簽等地方，找到你已經(jīng)輸入的字符串可能對(duì)應(yīng)的URL，然后給出智能提示

在輸好URL后我們會(huì)按下Enter鍵，瀏覽器會(huì)發(fā)起請求，如果URL是域名而不是IP地址，將進(jìn)行域名解析，所謂域名解析是指什么呢？

IP地址是網(wǎng)絡(luò)上標(biāo)識(shí)站點(diǎn)的數(shù)字地址，為了方便記憶，采用域名來代替IP地址標(biāo)識(shí)站點(diǎn)地址，域名解析就是域名到IP地址的轉(zhuǎn)換過程。

域名解析按下面的步驟進(jìn)行（部分內(nèi)容涉及到計(jì)算機(jī)網(wǎng)絡(luò)知識(shí)）：

我們本地硬盤下有一個(gè)hosts(windows下路徑為C:WindowsSystem32driversetc)文件，作用是將一些常用的網(wǎng)址域名與其對(duì)應(yīng)的IP地址建立一個(gè)關(guān)聯(lián)“數(shù)據(jù)庫”。一般來說，系統(tǒng)會(huì)首先自動(dòng)從hosts文件中尋找對(duì)應(yīng)的IP地址，如果有的話就直接使用hosts文件里面的IP地址，然后直接進(jìn)行端口確認(rèn)

如果上一步?jīng)]有找到，瀏覽器將調(diào)用解析程序，并成為DNS服務(wù)器的一個(gè)客戶，把待解析的域名放在DNS請求報(bào)文中，以UDP用戶數(shù)據(jù)報(bào)的方式發(fā)給本地DNS服務(wù)器

如果本地DNS服務(wù)器查找到相應(yīng)的域名的IP地址，就把對(duì)應(yīng)的IP地址放在回答報(bào)文中返回

如果上一步?jīng)]有找到，即本地DNS服務(wù)器不知道被查詢域名的IP地址，由于主機(jī)向本地DNS服務(wù)器的查詢是遞歸查詢，所以此時(shí)，本地DNS服務(wù)器就會(huì)以DNS客戶的身份向其他根DNS服務(wù)器繼續(xù)發(fā)出查詢請求報(bào)文。本地DNS服務(wù)器向根DNS服務(wù)器的查詢是迭代查詢，當(dāng)找到相應(yīng)域名的IP地址后，就會(huì)把這個(gè)結(jié)果返回給最初發(fā)起查詢請求的瀏覽器

遞歸查詢：在該模式下DNS服務(wù)器接收到客戶機(jī)請求，必須返回一個(gè)準(zhǔn)確的查詢結(jié)果給客戶機(jī)。如果該DNS服務(wù)器本地沒有存儲(chǔ)被查詢的DNS信息，那么該服務(wù)器會(huì)（替客戶機(jī)）詢問其他服務(wù)器，并將返回的查詢結(jié)果再返回給客戶機(jī)。

迭代查詢：在該模式下DNS服務(wù)器接收到客戶機(jī)請求，如果該DNS服務(wù)器本地沒有存儲(chǔ)被查詢的DNS信息，DNS服務(wù)器會(huì)向客戶機(jī)提供其他能夠解析查詢請求的DNS服務(wù)器地址，讓客戶機(jī)再向這臺(tái)DNS服務(wù)器提交請求，依次循環(huán)直到返回查詢的結(jié)果為止。

經(jīng)過上面的步驟后，瀏覽器已經(jīng)獲得輸入域名的IP地址，可以進(jìn)行下一步了。

瀏覽器得到IP地址后，還要確認(rèn)一下端口，默認(rèn)端口是80端口，一個(gè)服務(wù)器可能會(huì)提供不同的服務(wù)，這些服務(wù)通過端口來區(qū)分，可以指定端口號(hào)

瀏覽器得到IP地址并確認(rèn)端口后，會(huì)向目標(biāo)服務(wù)器發(fā)起HTTP請求，HTTP請求是通過TCP連接來發(fā)送的(如果是HTTPS則需要先建立SSL連接，再是TCP連接，下面的討論基于HTTP)，具體如下

瀏覽器會(huì)生成目標(biāo)服務(wù)器的HTTP請求報(bào)文，請求報(bào)文一般包含請求方法、請求URI、協(xié)議版本、請求首部字段等內(nèi)容，HTTP請求準(zhǔn)備好后，HTTP請求報(bào)文從應(yīng)用層傳到傳輸層后會(huì)被分割為報(bào)文段，并會(huì)發(fā)起一條到達(dá)目標(biāo)服務(wù)器的TCP連接，開始TCP三次握手，過程如圖所示：

通俗的可以理解為：

A主動(dòng)向B打電話：嗨，能聽到嗎（SYN=1，seq=x），然后A就開始等待B的回答（SYN-SENT狀態(tài)），此時(shí)A不知道B能不能聽到

B聽到A的話之后，可以確認(rèn)它能聽到A，但是它還要確認(rèn)一下A能不能聽到他自己的聲音，于是B說：我能聽到你的聲音（ACK=1，ack=x+1），你能聽到我的聲音嗎（SYN=1,seq=y），然后B開始等待A的恢復(fù)（SYN-RECD狀態(tài)）

A聽到B的話之后，A可以確認(rèn)兩件事，一是B能聽到它說話，二是它也能聽到B說話，A已經(jīng)可以隨時(shí)說話和傾聽了（ESTABLISHED狀態(tài)）。但是此時(shí)的B還在等待中，并不知道A能不能聽到，所以此時(shí)A需要再回復(fù)B說：我可以聽到你的聲音（ACK=1，ack=y+1）,開始愉快的聊天吧~（seq=x+1），B聽到這句話后便也可以隨時(shí)說話和傾聽了（ESTABLISHED狀態(tài)）

之后兩個(gè)人就可以balabalabala....

HTTP請求的請求報(bào)文是直接附在第三次握手的消息中

穿插補(bǔ)充小知識(shí)，為什么是三次握手，而不是兩次四次？

有一種觀點(diǎn)是三次握手是基于TCP協(xié)議的可靠性（Reliability）要求，這是確認(rèn)雙發(fā)都能進(jìn)行收發(fā)的最小次數(shù)，兩次確認(rèn)不了，四次多余。但是并沒有完全意義上的可靠，不論握手多少次都只能表明握手的時(shí)候是可靠的，不能保證后面數(shù)據(jù)傳輸時(shí)一直可靠，因?yàn)?strong>信道是不可靠的，當(dāng)然三次握手至少可以表明它曾經(jīng)可靠，這是兩次握手無法完成的，而四次甚至更多次握手僅僅是提高“它曾經(jīng)可靠”這個(gè)結(jié)論的可信程度。所以這個(gè)握手也只是確保可靠的一個(gè)基本需要，TCP協(xié)議的可靠性（注意區(qū)分完整性integrity）更多的是由校驗(yàn)和、定時(shí)器超時(shí)重傳、確認(rèn)機(jī)制
在《計(jì)算機(jī)網(wǎng)絡(luò)》一書中也有講過這個(gè)問題，給出的解釋是：三次握手是為了防止失效的連接請求報(bào)文段被服務(wù)端接收，從而產(chǎn)生錯(cuò)誤。具體例子如下所述：
client發(fā)出的一個(gè)連接請求報(bào)文段并沒有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請求。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接。
假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了。但是由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)。而server卻以為新的連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費(fèi)掉了。
采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)，就知道client并沒有要求建立連接

連接建立之后，開始進(jìn)行數(shù)據(jù)傳輸，雖然瀏覽器知道目標(biāo)服務(wù)器的IP和端口，但是數(shù)據(jù)總不可能飛過去吧？HTTP請求報(bào)文段會(huì)從傳輸層傳到網(wǎng)絡(luò)層，在網(wǎng)絡(luò)層被封裝成IP數(shù)據(jù)包，網(wǎng)絡(luò)層規(guī)定了通過怎樣的路徑（所謂的傳輸路線）到達(dá)目標(biāo)服務(wù)器，并把數(shù)據(jù)包傳送給對(duì)方。

網(wǎng)絡(luò)層封裝好的IP數(shù)據(jù)包會(huì)進(jìn)一步傳到下一層 --- 數(shù)據(jù)鏈路層，然后會(huì)再次被封裝到MAC數(shù)據(jù)幀結(jié)構(gòu)中，由于IP地址間的通信依賴于MAC地址（網(wǎng)卡所屬的固定地址），所以MAC數(shù)據(jù)幀結(jié)構(gòu)中會(huì)有經(jīng)過ARP協(xié)議解析后的MAC地址（不一定是目標(biāo)服務(wù)器的MAC地址，因?yàn)閷?shí)際上通信的雙方在同一局域網(wǎng)（LAN）內(nèi)的情況是很少的，一般都會(huì)經(jīng)過路由中轉(zhuǎn)）。

數(shù)據(jù)鏈路層的MAC數(shù)據(jù)幀再向下傳，便會(huì)到達(dá)物理層，這里要注意物理層考慮的是怎樣才能在連接各種計(jì)算機(jī)的傳輸媒體上傳輸數(shù)據(jù)比特流，而不是指具體的傳輸媒體。 物理層需要確保原始的數(shù)據(jù)可在各種物理媒體上傳輸，它規(guī)定了傳輸媒體的機(jī)械特性、電氣特性、功能特性、過程特性：

常見的傳輸媒體有雙絞線、電纜、光纜、無線信道等，物理層的任務(wù)就是要讓數(shù)據(jù)在這些傳輸媒體上都能能進(jìn)行傳輸

通過MAC地址匹配，數(shù)據(jù)通過傳輸媒體到達(dá)目標(biāo)服務(wù)器的物理層，物理層接收數(shù)據(jù)比特流然后向上傳送到服務(wù)器的數(shù)據(jù)鏈路層，在數(shù)據(jù)鏈路層MAC數(shù)據(jù)幀將進(jìn)行封裝的逆操作，還原成IP數(shù)據(jù)包之后向上傳送到網(wǎng)絡(luò)層，網(wǎng)絡(luò)層也進(jìn)行封裝的逆操作還原成HTTP請求報(bào)文段（分割后的一小段一小段的），然后這些報(bào)文段向上傳到傳輸層，在傳輸層按原來的序號(hào)重新組裝成完整的HTTP請求報(bào)文，再向上傳到應(yīng)用層，應(yīng)用層的HTTP協(xié)議便會(huì)開始對(duì)請求進(jìn)行處理

這個(gè)處理可能是直接返回靜態(tài)的資源，也可能經(jīng)過PHP、JAVA等語言進(jìn)行處理等，等處理完成后，會(huì)返回一個(gè)HTTP響應(yīng)，它生成一個(gè)HTTP響應(yīng)報(bào)文，與HTTP請求報(bào)文結(jié)構(gòu)類似，然后這個(gè)響應(yīng)報(bào)文會(huì)“走過”請求報(bào)文來時(shí)的路到達(dá)瀏覽器

瀏覽器接收HTTP響應(yīng)，然后有可能釋放TCP連接，也有可能重新使用這個(gè)TCP連接發(fā)送新的請求（持久連接），此處了解一下TCP連接的釋放，不同于TCP連接建立的三次握手，TCP連接的釋放是四次揮手，客戶端和服務(wù)器端都可以發(fā)起關(guān)閉請求，也存在兩者同時(shí)發(fā)起關(guān)閉請求的情況，圖中為客戶端A主動(dòng)發(fā)起關(guān)閉請求：

同樣通俗的解釋一波：

A對(duì)B要傳的文件已經(jīng)傳完了，于是他對(duì)B說：我要傳的文件已經(jīng)傳完了，我要準(zhǔn)備下線了（seq=u，F(xiàn)IN=1）。然后A就等待B的回復(fù)（FIN-WAIT-1狀態(tài)）

B看到A的消息后，回復(fù)A說：知道了，但是我還有文件給你（ACK=1,ack=u+1,seq=v）。B進(jìn)入等他文件傳完的狀態(tài)（CLOSE-WAIT狀態(tài)）。
A收到B的回復(fù)之后，下線不了了，于是繼續(xù)等待著B的文件傳完（FIN-WAIT-2狀態(tài)）

幾分鐘后，B的文件傳完了，此時(shí)他對(duì)A說：我的文件傳完了，我也要下線了（seq=w,FIN=1,ACK=1,ack=u+1），然后B等待A的回復(fù)來確認(rèn)真的可以下線了（LAST-ACK狀態(tài)）

A收到B的回復(fù)后，便對(duì)A說：好的，那你下線吧（ACK=1，seq=u+1,ack=w+1）。此時(shí)A會(huì)等待一段時(shí)間（2MSL，TIME-WAIT狀態(tài)），B收到后就直接下線了（CLOSE狀態(tài)），然后2MSL時(shí)間到了之后，A也下線（CLOSE狀態(tài)）

為什么服務(wù)器B在接到A的斷開請求時(shí)不立即同意斷開？
當(dāng)服務(wù)器B收到斷開連接的請求時(shí)，服務(wù)器可能仍然有數(shù)據(jù)未發(fā)送完畢，所以服務(wù)器先發(fā)送確認(rèn)信號(hào)，等所有數(shù)據(jù)發(fā)送完畢后再同意斷開

為什么是四次揮手，而不是像建立連接一樣的三次
因?yàn)?b>TCP連接是全雙工模式，服務(wù)器B收到A的斷開請求時(shí)，僅僅表明A沒有東西傳給服務(wù)器B了，但此時(shí)服務(wù)器B可能向A的傳輸還沒結(jié)束，所以服務(wù)器B要先給A一個(gè)確認(rèn)收到A的斷開請求的ACK報(bào)文，然后繼續(xù)向A把信息傳完，等傳完之后服務(wù)器B再向A發(fā)送斷開請求的報(bào)文段，等A收到并回復(fù)ACK報(bào)文后再釋放連接。
也就是說對(duì)于A來說他要發(fā)送請求給B并等待B確認(rèn)，對(duì)于B來說也要發(fā)送請求給A并等待A確認(rèn)，兩者都經(jīng)過這兩個(gè)過程才能完全釋放TCP連接，而非單方面的釋放。
建立連接只需要建立，沒有數(shù)據(jù)的影響，而釋放連接還要考慮數(shù)據(jù)是否傳輸完，所以建立連接的時(shí)候B確認(rèn)收到A的建立請求與B發(fā)送建立請求這一步可以合成一步成為TCP建立連接的第二次握手，而釋放連接時(shí)卻必須分開。

最后一次握手后A為什么要等2MSL？
首先解釋一下MSL，MSL是指最長報(bào)文段壽命，RFC793建議為兩分鐘，但實(shí)際上可據(jù)實(shí)際情況而定，也就是說一個(gè)報(bào)文段最久可存在的時(shí)間是MSL

這是為了保證A發(fā)送的最后一個(gè)ACK報(bào)文能夠到達(dá)服務(wù)器B，如果這個(gè)ACK報(bào)文丟失了，服務(wù)器B沒有收到，B會(huì)超時(shí)重傳第三次握手的FIN+ACK報(bào)文給A，這個(gè)時(shí)候處于等待的A就可以收到這個(gè)重傳的FIN+ACK報(bào)文，并再次發(fā)送ACK報(bào)文給服務(wù)器B，并且重新啟動(dòng)2MSL計(jì)時(shí)器，最終結(jié)果是A和B都正常進(jìn)入CLOSE狀態(tài)。如果A發(fā)完ACK報(bào)文后就直接釋放了A-->B的連接，那么A就收不到B重傳的FIN+ACK報(bào)文，也不能重新發(fā)送ACK`報(bào)文，那么B就無法按正常步驟釋放B-->A的連接

防止“已失效的連接請求報(bào)文”出現(xiàn)在下一個(gè)新的連接中，因?yàn)橐粋€(gè)報(bào)文段的壽命是MSL，所以A在發(fā)送完最后一個(gè)ACK報(bào)文段之后，再經(jīng)過時(shí)間2MSL，本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都將在網(wǎng)絡(luò)中消失，這樣這些舊的報(bào)文段便不會(huì)出現(xiàn)在下一個(gè)新的連接中

瀏覽器之后會(huì)檢查HTTP的響應(yīng)狀態(tài)，主要通過響應(yīng)碼來判斷

1xx: 表示通知信息的，比如請求收到了或正在處理    
  2xx：表示成功，操作被成功接收并處理 
  3xx：表示重定向，一般完成請求還必須采取進(jìn)一步的行動(dòng)
  4xx：表示客戶端的差錯(cuò)
  5xx：表示服務(wù)器的差錯(cuò)

如果響應(yīng)可緩存，瀏覽器將把響應(yīng)存入緩存

瀏覽器根據(jù)HTTP報(bào)頭信息解碼響應(yīng)，決定如何處理這些響應(yīng)，并展現(xiàn)響應(yīng)，以響應(yīng)為一個(gè)HTML為例

瀏覽器開始自上而下，自左而右的加載HTML文檔，最開始會(huì)遇到聲明，然后根據(jù)聲明瀏覽器就知道該用哪種規(guī)范來解析這個(gè)文檔

再繼續(xù)邊加載邊解析，邊生成DOM樹，加載過程中遇到外部CSS文件，瀏覽器便會(huì)另外發(fā)出一個(gè)請求，來獲取CSS文件（過程和上面說的一樣），獲取CSS后會(huì)生成CSS Rule樹。DOM樹和CSS Rule樹生成Render樹，頁面可以開始邊加載邊渲染了

渲染樹和DOM樹的關(guān)系：那些不可見的DOM元素（如…，display=none的元素）不會(huì)被插入渲染樹中；還有像一些節(jié)點(diǎn)是絕對(duì)定位或浮動(dòng)，這些節(jié)點(diǎn)會(huì)在文本流之外，因此他們會(huì)在渲染樹和DOM樹的不同位置，渲染樹標(biāo)識(shí)出真實(shí)的位置，并用一個(gè)占位結(jié)構(gòu)標(biāo)識(shí)出他們原來的位置，而DOM樹上是他們原來的位置

渲染包含"布局"（layout）和"繪制"（paint）這兩個(gè)步驟，所謂"布局"是指給出每個(gè)DOM節(jié)點(diǎn)在瀏覽器窗口中的準(zhǔn)確位置，"繪制"是指遍歷Render樹將布局好的DOM節(jié)點(diǎn)繪制在屏幕上。

瀏覽器繼續(xù)加載渲染，如果遇到＜script＞標(biāo)簽，瀏覽器會(huì)立即執(zhí)行（暫不考慮defer及async屬性），此時(shí)會(huì)出現(xiàn)頁面阻塞，不僅要等待文檔中JS文件下載加載完畢，還要等待JS解析執(zhí)行完畢，才可以恢復(fù)HTML文檔的加載解析。

這是瀏覽器為了防止出現(xiàn)JS修改DOM樹，需要重新構(gòu)建DOM樹的情況，DOM樹改變?yōu)g覽器需要回過頭來重新渲染這部分代碼，所以瀏覽器希望通過阻塞其他內(nèi)容的下載和呈現(xiàn)，來避免出現(xiàn)更多的不必要的Reflow（稱為回流或者重排）

如果