終極解密輸入網址按回車到底發生了什麼

終極解密輸入網址按回車到底發生了什麼

詳解輸入網址點擊回車，後臺到底發生了什麼。透析 HTTP 協議與 TCP 鏈接之間的千絲萬縷的關係。掌握爲什麼是三次握手四次揮手？ time_wait 存在的意義是什麼？全面圖解重點問題，不再用擔憂面試問這個問題。

大體流程

• URL 解析，解析 http 協議、端口、資源地址。
• DNS 查詢：首先查詢本地 host，再訪問 DNS 服務器將 域名解析成 ip 地址。
• 創建 TCP 鏈接。
• 服務器收到請求後處理，而且構造響應返回給客戶端。
• 客戶端接收 HTTP 報文響應。
• 渲染頁面，最後有可能會四次揮手斷開鏈接，也可能不會而是複用鏈接。

重點來了：

• 如何理解 TCP 的三次握手與四次揮手？每次握手客戶端與服務端是怎樣的狀態？
• 爲什麼揮手會出現 2MSL，遇到大量 Socket 處在 TIME_WAIT 或者 CLOSE_WAIT 狀態是什麼問題？
• 三次握手與四次揮手的過程是怎樣的？
• HTTP 的報文格式又是怎樣的？

繼續閱讀本文，且聽碼哥字節答疑解惑，微信搜索 「碼哥字節」，關注公衆號更多硬核。

URL 解析

好比 【碼哥字節】在思否發佈的一篇文章的地址：https://segmentfault.com/a/1190000023475177。url 遵照的規則是這個樣子

scheme://host.domain:port/path/filename

每一個名詞的含義以下解釋：

• scheme 定義應用層協議類型，好比 http、https、 ftp 等；
• host 定義域主機（http 的默認主機是 www）；
• domain 定義因特網域名，好比 segmentfault.com；
• port 主機的端口，http 默認是 80, https 默認是 443；
• path 服務器上的資源路徑；
• filename - 定義文檔/資源的名稱；

DNS 查詢

瀏覽器不能直接經過域名找到服務器，只能經過 IP 地址。

那瀏覽器是如何經過域名查詢到咱們輸入的 url 對應的 IP 呢？

• 瀏覽器緩存：按照必定頻率緩存 DNS 數據。
• 操做系統緩存：若是瀏覽器緩存好啊不到記錄則去操做系統中找。
• 路由緩存：路由器 DNS 緩存。
• ISP 的 DNS 服務器：ISP 是互聯網服務提供商(Internet Service Provider)的簡稱，ISP 有專門的 DNS 服務器應對 DNS 查詢請求。
• 根服務器：ISP 的 DNS 服務器還找不到的話，它就會向根服務器發出請求，進行遞歸查詢（DNS 服務器先問根域名服務器.com 域名服務器的 IP 地址，而後再問 .baidu 域名服務器，依次類推）

TCP 鏈接創建與斷開

經過域名解析出 IP 地址之後就要創建 TCP/IP 鏈接了。

TCP/IP 分爲四層，每一層都會加上一個頭部再發送給下一層。到了接收方後，對應的每一層則把對應層的頭部解析拆除，丟上上一層，跟發送端的過程反過來。

應用層：發送 HTTP 請求

瀏覽器從地址欄獲得服務器 IP，接着構造一個 HTTP 報文，其中包括：

• 請求行包含請求方法、URL、協議版本

• 請求報頭(Request Header)：由 「關鍵字: 值」對組成，每行一對，關鍵字與值使用英文 「:」 分割
• 請求體：請求參數，並非全部的請求有又請求參數。通常 get 參數 的格式 name=tom&password=1234&realName=tomson,也能夠將參數放在 body 裏面。

傳輸層：TCP 傳輸報文

在傳輸報文以前會先創建 TCP/IP 鏈接，也就是後面咱們要說的三次握手。

在這一層解決了數據可靠傳輸、及流量控制、擁塞控制。

可靠傳輸

對於發送方發送的數據，接收方在接受到數據以後必需要給予確認，確認它收到了數據。若是在規定時間內，沒有給予確認則意味着接收方沒有接受到數據，而後發送方對數據進行重發。

TCP的可靠傳輸是經過確認和超時重傳的機制來實現的，而確認和超時重傳的具體的實現是經過以字節爲單位的滑動窗口機制來完成。

TCP擁塞控制

TCP協議經過慢啓動機制、擁塞避免機制、加速遞減機制、快重傳和快恢復機制來共同實現擁塞控制。

流量控制

採用通知窗口實現對發送端的流量控制，通知窗口大小的單位是字節。TCP經過在TCP數據段首部的窗口字段中填入當前設定的接收窗口(即通知窗口)的大小，用來告知對方 '我方當前的接收窗口大小'，以實現流量控制。

通訊雙方的發送窗口大小由雙方在鏈接創建的時候商定，在通訊過程，雙方能夠動態地根據本身的狀況調整對方的發送窗口大小。

網絡層：IP 協議查詢 MAC 地址

將數據段打包，並加入源及目標的 IP 地址，而且負責尋找傳輸路線。判斷目標地址是否與當前地址處於同一網絡中，是的話直接根據 Mac 地址發送，不然使用路由表查找下一跳地址，以及使用 ARP 協議查詢它的 Mac 地址。

鏈路層：以太網協議

根據以太網協議將數據分爲以「幀」爲單位的數據包，每一幀分爲兩個部分：

• 標頭：數據包的發送者、接受者、數據類型
• 數據：數據包具體內容

Mac 地址

以太網規定了連入網絡的全部設備都必須具有「網卡」接口，數據包都是從一塊網卡傳遞到另外一塊網卡，網卡的地址就是 Mac 地址。每個 Mac 地址都是獨一無二的，具有了一對一的能力。

三次握手

在傳輸層傳輸數據以前須要創建鏈接，也就是三次握手建立可靠鏈接。

首先創建連接前須要 Server 端先監聽端口，所以 Server 端創建連接前的初始狀態就是 LISTEN 狀態，這時 Client 端準備創建連接，先發送一個 SYN 同步包，發送完同步包後，Client 端的連接狀態變成了 SYN_SENT 狀態。Server 端收到 SYN 後，贊成創建連接，會向 Client 端回覆一個 ACK。

因爲 TCP 是雙工傳輸，Server 端也會同時向 Client 端發送一個 SYN，申請 Server 向 Client 方向創建連接。發送完 ACK 和 SYN 後，Server 端的連接狀態就變成了 SYN_RCVD。

Client 收到 Server 的 ACK 後，Client 端的連接狀態就變成了 ESTABLISHED 狀態，同時，Client 向 Server 端發送 ACK，回覆 Server 端的 SYN 請求。

Server 端收到 Client 端的 ACK 後，Server 端的連接狀態也就變成了的 ESTABLISHED 狀態，此時建連完成，雙方隨時能夠進行數據傳輸。

在面試時須要明白三次握手是爲了創建雙向的連接，須要記住 Client 端和 Server 端的連接狀態變化。另外回答建連的問題時，能夠提到 SYN 洪水***發生的緣由，就是 Server 端收到 Client 端的 SYN 請求後，發送了 ACK 和 SYN，可是 Client 端不進行回覆，致使 Server 端大量的連接處在 SYN_RCVD 狀態，進而影響其餘正常請求的建連。能夠設置 tcp_synack_retries = 0 加快半連接的回收速度，或者調大 tcp_max_syn_backlog 來應對少許的 SYN 洪水***

四次揮手

咱們只要關注 80 端口與 13743 端口創建的鏈接斷開過程，瀏覽器經過 13747 端口發送 [FIN, ACK] 這裏是否是跟不少網上看到的不同？

1. 實際上是客戶端在發送 [FIN] 報文的時候順帶發了一個 [ACK] 確認上次傳輸確認。

2. 接着服務端經過 80 端口響應了 [ACK] ，而後立馬響應 [FIN, ACK] 表示數據傳輸完了，能夠關閉鏈接。
3. 最後瀏覽器經過 13743 端口 發送 [ACK] 包給服務端，客服端與服務端鏈接就關閉了。

具體流程以下圖抓包所示：

三次握手與四次揮手

客戶端：

• SYN_SENT - 客戶端發起第 1 次握手後，鏈接狀態爲 SYN_SENT ，等待服務端內核進行應答，若是服務端來不及處理（例如服務端的 backlog 隊列已滿）就能夠看到這種狀態的鏈接。
• ESTABLISHED - 表示鏈接處於正常狀態，能夠進行數據傳送。客戶端收到服務器回覆的 SYN+ACK 後，對服務端的 SYN 單獨回覆（第 3 次握手），鏈接創建完成，進入 ESTABLISHED 狀態。服務端程序收到第 3 次握手包後，也進入 ESTABLISHED 狀態。
• FIN_WAIT_1 - 客戶端發送了關閉鏈接的 FIN 報文後，等待服務端回覆 ACK 確認。
• FIN_WAIT_2 - 表示我方已關閉鏈接，正在等待服務端關閉。客戶端發了關閉鏈接的 FIN 報文後，服務器發回 ACK 應答，可是沒進行關閉，就會處於這種狀態。
• TIME_WAIT - 雙方都正常關閉鏈接後，客戶端會維持 TIME_WAIT 一段時間，以確保最後一個 ACK 能成功發送到服務器端。停留時長爲 2 倍的 MSL (報文最大生存時間)，Linux 下大約是 60 秒。因此在一個頻繁創建短鏈接的服務器上一般能夠看到成千上萬的 TIME_WAIT 鏈接。

服務端：

• LISTEN - 表示當前程序正在監聽某個端口時。
• SYN_RCVD - 服務端收到第 1 次握手後，進入 SYN_RCVD 狀態，並回復一個 SYN+ACK（第 2 次握手），再等待對方確認。
• ESTABLISHED - 表示鏈接處於正常狀態，能夠進行數據傳送。完成 TCP3 次握手後，鏈接創建完成，進入 ESTABLISHED 狀態。
• CLOSE_WAIT - 表示客戶端已經關閉鏈接，可是本地還沒關閉，正在等待本地關閉。有時客戶端程序已經退出了，但服務端程序因爲異常或 BUG 沒有調用 close()函數對鏈接進行關閉，那在服務器這個鏈接就會一直處於 CLOSE_WAIT 狀態，而在客戶機已經不存在這個鏈接了。
• LAST_ACK - 表示正在等待客戶端對服務端的關閉請求進行最終確認。

TIME_WAIT 狀態存在的理由：

劃重點了

• 可靠地實現 TCP 全雙工鏈接的終止 在進行關閉鏈接四路握手協議時，最後的 ACK 是由主動關閉端發出的，若是這個最終的 ACK 丟失，服務器將重發最終的 FIN，所以客戶端必須維護狀態信息允 許它重發最終的 ACK。如 果不維持這個狀態信息，那麼客戶端將響應 RST 分節，服務器將此分節解釋成一個錯誤（ 在 java 中會拋出 connection reset 的 SocketException)。於是，要實現 TCP 全雙工鏈接的正常終 止，必須處理終止序列四個分節中任何一個分節的丟失狀況，主動關閉 的客戶端必須維持狀 態信息進入 TIME_WAIT 狀態。
• 容許老的重複分節在網絡中消逝 TCP 分節可能因爲路由器異常而「迷途」，在迷途期間，TCP 發送端可能因確認超時而重發這個 分節，迷途的分節在路由器修復後也會被送到最終目的地，這個 原來的迷途分節就稱爲 lost duplicate。在關閉一個 TCP 鏈接後，立刻又從新創建起一個相同的 IP 地址和端口之間的 TCP 鏈接，後一個鏈接被稱爲前一個鏈接的化身 （ incarnation)，那麼有可能出現這種狀況，前一 個鏈接的迷途重複分組在前一個鏈接終止後出現，從而被誤解成從屬於新的化身。爲了不 這個情 況，TCP 不容許處於 TIME_WAIT 狀態的鏈接啓動一個新的化身，由於 TIME_WAIT 狀 態持續 2MSL，就能夠保證當成功創建一個 TCP 鏈接的時 候，來自鏈接先前化身的重複分組已 經在網絡中消逝。

另外回答斷鏈的問題時，能夠提到實際應用中有可能遇到大量 Socket 處在 TIME_WAIT 或者 CLOSE_WAIT 狀態的問題。通常開啓 tcp_tw_reuse 和 tcp_tw_recycle 可以加快 TIME-WAIT 的 Sockets 回收；而大量 CLOSE_WAIT 多是被動關閉的一方存在代碼 bug，沒有正確關閉連接致使的。

簡單地說就是

1. 保證 TCP 協議的全雙工鏈接可以可靠關閉；
2. 保證此次鏈接的重複數據段從網絡中消失，防止端口被重用時可能產生數據混淆；

服務器處理請求並響應 HTTP 報文

深刻分析下 HTTP 報文究竟是什麼玩意。數據傳輸都是經過 TCP/IP 協議負責底層的傳輸工做， HTTP 協議基本不用操心，所謂的 「超文本傳輸協議」 彷佛不怎麼例會 「傳輸」 這個事情，那 HTTP 的核心又是什麼呢？

比圖 TCP 報文，它在實際要傳輸的數據以前附加了一個 20 字節的頭部數據，存儲 TCP 協議必須的額外信息，例如發送方的端口號、接收方的端口號、包序號、標誌位等等。

有了這個附加的 TCP 頭，數據包纔可以正確傳輸，到了目的地後把頭部去掉，就能夠拿到真正的數據。這個很容易理解，設置起點與終點，不一樣協議貼上不一樣的頭部，到了對應目的地就拆下這個頭部，提取真正的數據。

與 TCP/UDP 相似須要在傳輸數據前設置一些請求頭，不一樣的是 HTTP 是一個 「純文本」 的協議，全部的頭都是 ASCII 碼的文本，很容易看出來是什麼。

再者就是他的請求報文與響應報文的結構基本同樣，主要三大部分組成：

1. 起始行(Start Line)：描述請求或者響應的基本信息。
2. Header：使用 key-value 的形式詳細說明報文信息。
3. 空行。
4. 消息正文（Entity）：傳輸的數據，圖片、視頻、文本等均可以。

這其中前兩部分起始行和頭部字段常常又合稱爲「請求頭」或「響應頭」，消息正文又稱爲「實體」，但與「header」對應，不少時候就直接稱爲「body」。

敲黑板了

HTTP 協議規定報文必須包含 Header，並且以後必須有一個 「空行」，也就是「CRLF」，十六進制的「0D0A」，能夠沒有 「body」。

報文結構以下圖所示：

截取一段報文：

請求頭-起始行

請求行由請求方法字段、URL 字段和 HTTP 協議版本字段 3 個字段組成，它們用空格分隔。例如，GET / HTTP/1.1。

HTTP 協議的請求方法有 GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。

GET 是請求方法， 「/」 是請求的目標資源，「HTTP/1.1」 請求協議版本號。

GET / HTTP/1.1 翻譯成文字大概就是：「hello，服務器，我要請求根目錄下的默認文件使用的是 HTTP 1.1 協議版本」。

頭部 Header

第二部分就是 Header，組成形式是 key：value，使用自定義頭須要注意事項：

1. header 字段不區分大小寫，一般是首字母大寫；
2. 字段名不容許有空格，可使用 「-」，不能使用 「_」；
3. 字段名必須緊接着 「:」，不能有空格，可是 「:」 後面能夠有空格。
4. 字段名順序沒有意義；

瀏覽器接收響應並渲染數據

接收到響應文本 HTML，則開始執行瀏覽器渲染機制。

不一樣的瀏覽器渲染可能有所差別，可是基本按照如下步驟執行：

1. 根據 HTML 解析 DOM 樹；
2. 根據 CSS 解析出 CSS 規則樹；
3. 結合 DOM 樹與 CSS 規則樹，生成渲染樹；
4. 根據生成的渲染樹計算每一個節點的信息；
5. 根據節點信息繪製畫面展現給用戶。

推薦閱讀

如下幾篇文章閱讀量與讀者反饋都很好，推薦你們閱讀：

• RESTful 最佳實踐
• Tomcat 架構原理解析到架構設計借鑑
• Tomcat 高併發之道原理拆解與性能調優
• 數據庫系統設計概述

若是以爲閱讀後對你有幫助，但願多多分享、點贊與在看素質三連不作白嫖者。關注 【碼哥字節】解鎖更多硬核。

個人我的微信：MageByte1024