輸入網(wǎng)址并點(diǎn)回車，后臺(tái)到底發(fā)生了什么。透析 HTTP 協(xié)議與 TCP 連接之間的千絲萬縷的關(guān)系。掌握為何是三次握手四次揮手？ 存在的意義是什么？全面圖解重點(diǎn)問題，再也不用擔(dān)心面試問這個(gè)問題。
大致流程
重點(diǎn)來了：
URL 解析
url 遵守的規(guī)則是這個(gè)樣子
scheme://host.domain:port/path/filename
每個(gè)名詞的含義如下解釋：
DNS 查詢
瀏覽器不能直接通過域名找到服務(wù)器，只能通過 IP 地址。
那瀏覽器是如何通過域名查詢到我們輸入的 url 對(duì)應(yīng)的 IP 呢？
TCP 連接建立與斷開
通過域名解析出 IP 地址以后就要建立 TCP/IP 連接了。
TCP/IP 分為四層，每一層都會(huì)加上一個(gè)頭部再發(fā)送給下一層。到了接收方后，對(duì)應(yīng)的每一層則把對(duì)應(yīng)層的頭部解析拆除，丟上上一層，跟發(fā)送端的過程反過來。
TCP/IP四層模型應(yīng)用層：發(fā)送 HTTP 請(qǐng)求
瀏覽器從地址欄得到服務(wù)器 IP，接著構(gòu)造一個(gè) HTTP 報(bào)文，其中包括：
傳輸層：TCP 傳輸報(bào)文
在傳輸報(bào)文之前會(huì)先建立 TCP/IP 連接，也就是后面我們要說的三次握手。
在這一層解決了數(shù)據(jù)可靠傳輸、及流量控制、擁塞控制。
可靠傳輸
對(duì)于發(fā)送方發(fā)送的數(shù)據(jù)，接收方在接受到數(shù)據(jù)之后必須要給予確認(rèn)，確認(rèn)它收到了數(shù)據(jù)。如果在規(guī)定時(shí)間內(nèi)tcp/ip三次握手的通信過程是，沒有給予確認(rèn)則意味著接收方?jīng)]有接受到數(shù)據(jù)，然后發(fā)送方對(duì)數(shù)據(jù)進(jìn)行重發(fā)。
TCP的可靠傳輸是通過確認(rèn)和超時(shí)重傳的機(jī)制來實(shí)現(xiàn)的，而確認(rèn)和超時(shí)重傳的具體的實(shí)現(xiàn)是通過以字節(jié)為單位的滑動(dòng)窗口機(jī)制來完成。
TCP擁塞控制
TCP協(xié)議通過慢啟動(dòng)機(jī)制、擁塞避免機(jī)制、加速遞減機(jī)制、快重傳和快恢復(fù)機(jī)制來共同實(shí)現(xiàn)擁塞控制。
流量控制
采用通知窗口實(shí)現(xiàn)對(duì)發(fā)送端的流量控制，通知窗口大小的單位是字節(jié)。TCP通過在TCP數(shù)據(jù)段首部的窗口字段中填入當(dāng)前設(shè)定的接收窗口(即通知窗口)的大小，用來告知對(duì)方 '我方當(dāng)前的接收窗口大小'，以實(shí)現(xiàn)流量控制。
通信雙方的發(fā)送窗口大小由雙方在連接建立的時(shí)候商定，在通信過程，雙方可以動(dòng)態(tài)地根據(jù)自己的情況調(diào)整對(duì)方的發(fā)送窗口大小。
網(wǎng)絡(luò)層：IP 協(xié)議查詢 MAC 地址
將數(shù)據(jù)段打包，并加入源及目標(biāo)的 IP 地址，并且負(fù)責(zé)尋找傳輸路線。判斷目標(biāo)地址是否與當(dāng)前地址處于同一網(wǎng)絡(luò)中，是的話直接根據(jù) Mac 地址發(fā)送，否則使用路由表查找下一跳地址，以及使用 ARP 協(xié)議查詢它的 Mac 地址。
鏈路層：以太網(wǎng)協(xié)議
根據(jù)以太網(wǎng)協(xié)議將數(shù)據(jù)分為以“幀”為單位的數(shù)據(jù)包，每一幀分為兩個(gè)部分：
Mac 地址
以太網(wǎng)規(guī)定了連入網(wǎng)絡(luò)的所有設(shè)備都必須具備“網(wǎng)卡”接口，數(shù)據(jù)包都是從一塊網(wǎng)卡傳遞到另一塊網(wǎng)卡，網(wǎng)卡的地址就是 Mac 地址。每一個(gè) Mac 地址都是獨(dú)一無二的，具備了一對(duì)一的能力。
三次握手
在傳輸層傳輸數(shù)據(jù)之前需要建立連接，也就是三次握手創(chuàng)建可靠連接。
三次握手
首先建立鏈接前需要 端先監(jiān)聽端口，因此 端建立鏈接前的初始狀態(tài)就是 狀態(tài)，這時(shí) 端準(zhǔn)備建立鏈接，先發(fā)送一個(gè) SYN 同步包，發(fā)送完同步包后， 端的鏈接狀態(tài)變成了 狀態(tài)。 端收到 SYN 后，同意建立鏈接，會(huì)向 端回復(fù)一個(gè) ACK。
由于 TCP 是雙工傳輸， 端也會(huì)同時(shí)向 端發(fā)送一個(gè) SYN，申請(qǐng) 向 方向建立鏈接。發(fā)送完 ACK 和 SYN 后， 端的鏈接狀態(tài)就變成了 。
收到 的 ACK 后， 端的鏈接狀態(tài)就變成了 狀態(tài)，同時(shí)， 向 端發(fā)送 ACK，回復(fù) 端的 SYN 請(qǐng)求。
端收到 端的 ACK 后， 端的鏈接狀態(tài)也就變成了的 狀態(tài)，此時(shí)建連完成，雙方隨時(shí)可以進(jìn)行數(shù)據(jù)傳輸。
在面試時(shí)需要明白三次握手是為了建立雙向的鏈接，需要記住 端和 端的鏈接狀態(tài)變化。另外回答建連的問題時(shí)，可以提到 SYN 洪水攻擊發(fā)生的原因，就是 端收到 端的 SYN 請(qǐng)求后tcp/ip三次握手的通信過程是，發(fā)送了 ACK 和 SYN，但是 端不進(jìn)行回復(fù)，導(dǎo)致 端大量的鏈接處在 狀態(tài)，進(jìn)而影響其他正常請(qǐng)求的建連。可以設(shè)置 = 0 加快半鏈接的回收速度，或者調(diào)大 來應(yīng)對(duì)少量的 SYN 洪水攻擊
四次揮手
我們只要關(guān)注 80 端口與 13743 端口建立的連接斷開過程，瀏覽器通過 13747 端口發(fā)送 [FIN, ACK] 這里是不是跟很多網(wǎng)上看到的不一樣？
其實(shí)是客戶端在發(fā)送 [FIN] 報(bào)文的時(shí)候順帶發(fā)了一個(gè) [ACK] 確認(rèn)上次傳輸確認(rèn)。
接著服務(wù)端通過 80 端口響應(yīng)了 [ACK] ，然后立馬響應(yīng) [FIN, ACK] 表示數(shù)據(jù)傳輸完了，可以關(guān)閉連接。
最后瀏覽器通過 13743 端口 發(fā)送 [ACK] 包給服務(wù)端，客服端與服務(wù)端連接就關(guān)閉了。
具體流程如下圖抓包所示：
三次握手與四次揮手
TCP 連接與斷開
客戶端：
服務(wù)端：
狀態(tài)存在的理由：
劃重點(diǎn)了
另外回答斷鏈的問題時(shí)，可以提到實(shí)際應(yīng)用中有可能遇到大量 處在 或者 狀態(tài)的問題。一般開啟 和 能夠加快 TIME-WAIT 的 回收；而大量 可能是被動(dòng)關(guān)閉的一方存在代碼 bug，沒有正確關(guān)閉鏈接導(dǎo)致的。
簡單地說就是
保證 TCP 協(xié)議的全雙工連接能夠可靠關(guān)閉； 保證這次連接的重復(fù)數(shù)據(jù)段從網(wǎng)絡(luò)中消失，防止端口被重用時(shí)可能產(chǎn)生數(shù)據(jù)混淆；