輸入網址按回車，到底發生了什么
詳解輸入網址點擊回車，后臺到底發生了什么。透析 HTTP 協議與 TCP 連接之間的千絲萬縷的關系。掌握為何是三次握手四次揮手？ time_wait 存在的意義是什么？全面圖解重點問題，再也不用擔心面試問這個問題。
大致流程
- URL 解析。
- DNS 查詢。
- TCP 連接。
- 服務器處理請求。
- 客戶端接收 HTTP 報文響應。
- 渲染頁面
重點來了：
- 如何理解 TCP 的三次握手與四次揮手？每次握手客戶端與服務端是怎樣的狀態？
- 為何揮手會出現 2MSL，遇到大量 Socket 處在 TIME_WAIT 或者 CLOSE_WAIT 狀態是什么問題？
- 三次握手與四次揮手的過程是怎樣的？
- HTTP 的報文格式又是怎樣的？
繼續閱讀本文，且聽碼哥字節答疑解惑，微信搜索 “碼哥字節”，關注公眾號更多硬核。
URL 解析
地址解析：首先判斷你輸入的是一個合法的 URL 還是一個待搜索的關鍵詞，并且根據你輸入的內容進行自動完成、字符編碼等操作。
HSTS 由于安全隱患，會使用 HSTS 強制客戶端使用 HTTPS 訪問頁面。詳見：你所不知道的 HSTS[1]。
其他操作 瀏覽器還會進行一些額外的操作，比如安全檢查、訪問限制（之前國產瀏覽器限制 996.icu）。
檢查緩存
DNS 查詢
- 瀏覽器緩存：先檢查是否在緩存中，沒有則調用系統庫函數進行查詢。
- 操作系統緩存：操作系統也有自己的 DNS 緩存，但在這之前，會向檢查域名是否存在本地的 Hosts 文件里，沒有則向 DNS 服務器發送查詢請求。
- 路由器緩存。
- ISP DNS 緩存：ISP DNS 就是在客戶端電腦上設置的首選 DNS 服務器，它們在大多數情況下都會有緩存。
根域名服務器查詢
在前面所有步驟沒有緩存的情況下，本地 DNS 服務器會將請求轉發到互聯網上的根域，下面這個圖很好的詮釋了整個流程：
需要注意的的是：
- 遞歸方式：一路查下去中間不返回，得到最終結果才返回信息（瀏覽器到本地 DNS 服務器的過程）
- 迭代方式，就是本地 DNS 服務器到根域名服務器查詢的方式。
- 什么是 DNS 劫持
- 前端 dns-prefetch 優化
TCP 連接建立與斷開
TCP/IP 分為四層，在發送數據時，每層都要對數據進行封裝：
應用層：發送 HTTP 請求
瀏覽器從地址欄得到服務器 IP，接著構造一個 HTTP 報文，其中包括：
- 請求報頭(Request Header)：請求方法、目標地址、遵循的協議等
- 請求主體，請求參數，比如 body 里面的參數
傳輸層：TCP 傳輸報文
傳輸層會發起一條到達服務器的 TCP 連接，為了方便傳輸，會對數據進行分割（以報文段為單位），并標記編號，方便服務器接受時能夠準確地還原報文信息。在建立連接前，會先進行 TCP 三次握手。
網絡層：IP 協議查詢 MAC 地址
將數據段打包，并加入源及目標的 IP 地址，并且負責尋找傳輸路線。判斷目標地址是否與當前地址處于同一網絡中，是的話直接根據 Mac 地址發送，否則使用路由表查找下一跳地址，以及使用 ARP 協議查詢它的 Mac 地址。
鏈路層：以太網協議
根據以太網協議將數據分為以“幀”為單位的數據包，每一幀分為兩個部分：
- 標頭：數據包的發送者、接受者、數據類型
- 數據：數據包具體內容
Mac 地址
以太網規定了連入網絡的所有設備都必須具備“網卡”接口，數據包都是從一塊網卡傳遞到另一塊網卡，網卡的地址就是 Mac 地址。每一個 Mac 地址都是獨一無二的，具備了一對一的能力。
主要的請求過程：
- 瀏覽器從地址欄中獲取服務器的 IP 和端口號；
- 瀏覽器有服務器之間通過 TCP 三次握手建立連接；
- 瀏覽器向服務器發送報文；
- 服務器接收報文處理，同時將響應報文發給瀏覽器；
- 瀏覽器解析報文，渲染輸出到頁面；
三次握手
在傳輸層傳輸數據之前需要建立連接，也就是三次握手創建可靠連接。
首先建立鏈接前需要 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] 這里是不是跟很多網上看到的不一樣？
- 其實是客戶端在發送 [FIN] 報文的時候順帶發了一個 [ACK] 確認上次傳輸確認。
- 接著服務端通過 80 端口響應了 [ACK] ，然后立馬響應 [FIN, ACK] 表示數據傳輸完了，可以關閉連接。
- 最后瀏覽器通過 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，沒有正確關閉鏈接導致的。
簡單地說就是
- 保證 TCP 協議的全雙工連接能夠可靠關閉；
- 保證這次連接的重復數據段從網絡中消失，防止端口被重用時可能產生數據混淆；
服務器處理請求并響應 HTTP 報文
深入分析下 HTTP 報文到底是什么玩意。數據傳輸都是通過 TCP/IP 協議負責底層的傳輸工作， HTTP 協議基本不用操心，所謂的 “超文本傳輸協議” 似乎不怎么例會 “傳輸” 這個事情，那 HTTP 的核心又是什么呢？
比圖 TCP 報文，它在實際要傳輸的數據之前附加了一個 20 字節的頭部數據，存儲 TCP 協議必須的額外信息，例如發送方的端口號、接收方的端口號、包序號、標志位等等。
有了這個附加的 TCP 頭，數據包才能夠正確傳輸，到了目的地后把頭部去掉，就可以拿到真正的數據。這個很容易理解，設置起點與終點，不同協議貼上不同的頭部，到了對應目的地就拆下這個頭部，提取真正的數據。
與 TCP/UDP 類似需要在傳輸數據前設置一些請求頭，不同的是 HTTP 是一個 “純文本” 的協議，所有的頭都是 ASCII 碼的文本，很容易看出來是什么。
再者就是他的請求報文與響應報文的結構基本一樣，主要三大部分組成：
- 起始行(Start Line)：描述請求或者響應的基本信息。
- Header：使用 key-value 的形式詳細說明報文信息。
- 空行。
- 消息正文（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，使用自定義頭需要注意事項：
- header 字段不區分大小寫，通常是首字母大寫；
- 字段名不允許有空格，可以使用 “-”，不能使用 “_”；
- 字段名必須緊接著 “:”，不能有空格，但是 “:” 后面可以有空格。
- 字段名順序沒有意義；
瀏覽器接收響應并渲染數據
瀏覽器接收到來自服務器的響應資源后，會對資源進行分析。首先查看 Response header，根據不同狀態碼做不同的事（比如上面提到的重定向）。如果響應資源進行了壓縮（比如 gzip），還需要進行解壓。然后，對響應資源做緩存。接下來，根據響應資源里的 MIME[3] 類型去解析響應內容（比如 HTML、Image 各有不同的解析方式）。
接下來將接收到的數據渲染出來，不同的瀏覽器也不是完全相同，但是大致流程是一樣的：
如果覺得閱讀后對你有幫助，希望多多分享、點贊與在看素質三連不做白嫖者。關注 【碼哥字節】解鎖更多硬核。
