TCP/IP協議學習（三）一次完整的http請求過程

來自網絡小白的筆記三

---

簡要過程

一、使用DNS域名解析；

二、發起TCP的3次握手

三、創建TCP鏈接後發起http請求；

四、服務器響應http請求，瀏覽器獲得返回response；

五、瀏覽器解析response，並請求其它的資源（如js、css、圖片等）；

六、瀏覽器對頁面進行渲染。

---

舉個🌰

訪問一個網址的時候，例如www.baidu.com，具體流程以下

• 對www.baidu.com這個網址進行DNS域名解析到IP
• 經過IP，使用ARP地址解析協議，找到對應的服務器，發起TCP三次握手
• 創建TCP請求後，發起HTTP請求（例如TOMCAT部署的springMVC程序）
• 服務器響應HTTP請求，返回RESPONSE
• 遊覽器解析response，並請求其它的資源文件（js、css等）
• 遊覽器進行渲染界面

注：DNS域名解析採用的是遞歸查詢的方式，軟考時有考過，先從本地的DNS緩存中查找--->緩存中沒有的話就去找根域名服務器—-->根域名服務器找不到繼續找下一級，這樣遞歸查找到再返回給遊覽器。

---

具體細節

域名解析

1）首先會搜索瀏覽器自身的DNS緩存（緩存時間比較短，大概只有1分鐘，且只能容·和他們納1000條緩存）

2）若是瀏覽器自身的緩存裏面沒有找到，那麼瀏覽器會搜索系統自身的DNS緩存

3）若是尚未找到，那麼嘗試從 hosts文件裏面去找

4）在前面三個過程都沒獲取到的狀況下，就遞歸地去域名服務器去查找，

---

TCP鏈接

到了你們都很是熟悉的三次🤝和四次👋流程

正常的QA：

Q: 爲何鏈接的時候是三次握手，關閉的時候倒是四次握手？

A: 由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。

Q: 爲何TIME_WAIT狀態須要通過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

A: 一方面是爲了等待這個客戶從新鏈接的時候能夠進行復用，另外一方面必須假象網絡是不可靠的，有能夠最後一個ACK丟失。因此TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

Q: 若是TCP鏈接丟失了第三個ACK包怎麼辦？

A: 若是丟失了ACK包，SERVER端將該TCP鏈接的狀態爲SYN_RECV，而且依次等待3秒、6秒、12秒後從新發送SYN+ACK包，以便Client從新發送ACK包。若是超過設定的次數，將會斷開鏈接。可是Client認爲這個鏈接已經創建，若是Client端向Server寫數據，Server端將以RST包響應，方能讓Client感知到Server的錯誤。

---

參考資料

1. 一次完整的HTTP請求過程
2. TCP協議中的三次握手和四次揮手(圖解)