當我們想要前往某個網站獲取想要的內容時，我們一般的操作流程是：打開瀏覽器，輸入URL地址，然後回車就可以了。
但是這中間發生了什麼呢？
下面給大家分享一下大致流程：
- URL 解析
- DNS 查詢
- TCP 連接
- 服務器處理請求
- 客戶端接收 HTTP 報文響應
- 渲染頁面
URL 解析
地址解析：首先判斷你輸入的是一個合法的 URL 還是一個待搜索的關鍵詞，並且根據你輸入的內容進行自動完成、字符編碼等操作。
HSTS： 由於安全隱患，會使用 HSTS 強制客戶端使用 HTTPS 訪問頁面。
其他操作： 瀏覽器還會進行一些額外的操作，比如安全檢查、訪問限制（你懂的~）。
檢查客戶端緩存
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 各有不同的解析方式）。
接下來將接收到的數據渲染出來，不同的瀏覽器也不是完全相同，但是大致流程是一樣的：
