客戶端輸入 url 後的相應過程
http 的工作過程通常包括請求和相應兩個環節，屬於標準的客戶端服務器模型（ C/S 模型）。客戶端發起 http 協議請求，服務器接收到請求後，返回對應的相應。具體過程包括：
- url 地址解析：域名解析系統（DNS）解析域名得到訪問網站所在主機的 IP 地址。
- 完整的 url 通常包括模式協議（https）、域名、訪問端口、 虛擬目錄、文件名部分、參數部分、錨點部分等。
- 進行 DNS 解析前，會先從瀏覽器 DNS 緩存查找，一旦找到就完成了解析工程。如果沒有找到，接着會從電腦本地的 hosts 文件中查找（最簡單的科學上 google 的方法就是通過修改 hosts 文件實現）。一般來說，除非特別指定，否則 hosts 文件是不會存在解析地址的。這時只能向運營商服務器發送解析報文，獲取域名對應的 IP 地址。
- 瀏覽器向首選 DNS 服務器發起域名解析請求，通過 UDP 協議向 DNS 的 53 端口發起遞歸請求。先請求本地域名服務器（Local DNS Server）解析，若沒找到結果再向根域名服務器（Root Server）發起解析請求，其返回給本地域名服務器一個所查詢域的主域名服務器（gTLD Server）地址。
- 實際生活中訪問頁面時常常會出現奇奇怪怪的的廣告，那麼很大可能是運營商 DNS 被劫持，一般通過手動設置 DNS 可以避免。
- 構建 http 請求報文：封裝的內容包括目標地址以及部分本機信息。
- 構建 TCP 包：建立 TCP 連接 （TCP 的三次握手）。
- 發送請求命令：成功建立 TCP 連接後，客戶機向服務器發送請求。
- 一般的網站訪問會發送 GET 請求。
- 在實際網絡鏈路上傳送數據幀時，還涉及到 ARP（地址解析協議），根據 IP 地址，通過 ARP 廣播請求獲取目的主機的物理地址（MAC 地址）。
- 服務器響應：服務器接收到 http 請求報文，給予相應的響應信息。
- 服務器關閉 TCP 連接：通常由 Web 服務器發起關閉 TCP 連接的請求。
- 從 HTTP 1.1 開始，服務器可以與客戶端保持長連接，這取決於服務器的操作。
- 像網頁版微信爲了保證實時顯示消息，就不會關閉 TCP 連接。
- 客戶端解析報文：解析 html 代碼，對於像 css，js 或者圖片這一類靜態資源，會發起另外的請求，解析 html之後再客戶端屏幕上渲染圖形結果。
F5 刷新瀏覽器：當我們使用 F5 刷新頁面時，瀏覽器會直接向目標 url 發送請求，而不是讀取瀏覽器緩存的數據。
瀏覽器業務中的 UDP
在 DNS 解析域名的過程中，DNS 服務默認使用 UDP 協議獲得查詢結果，通常僅當結果超過 512 字節或者進行 DNS 服務器同步時纔會使用 TCP 協議。這是因爲 DNS 的使用非常頻繁，又是基礎，響應速度是優先需要考慮的。使用 UDP 可以滿足速度上的要求，但同時也引入了類似於 “DNS 攻擊” 這類問題。
WebRTC（Web Real-Time Communication）出現之前，DNS 幾乎是瀏覽器唯一使用的基於 UDP 的協議。WebRTC 提供的三大功能中，MediaStream 與網絡無關，RTCPeerConnection 和 RTCDataChannel 都是基於 UDP。
Google 正在試驗一種新的傳輸層協議：QUIC（Quick UDP Internet Connections），它的本質是基於 UDP 實現 HTTP，相當於之前的 TCP + TLS。從目前的資料來看，QUIC 可以大幅減少建立連接的時間，這是通過簡化握手步驟從而減少 RTT（Round-Trip Time）來實現的。
HTTP 常見狀態碼
- 1XX: 指示信息，表示請求已接受，繼續處理；
- 2XX: 成功，表示請求已接受，已處理。常見的是 200；
- 3XX：重定向，要完成請求必須進行更進一步地操作。例如常見的有 301 永久重定向和 302 臨時重定向。302 重定向的網站會保留原有的網址，而影響搜索引擎的抓取；
- 4XX：客戶端錯誤，請求有語法錯誤或請求無法實現。常見的有 400 錯誤，前後端協議字段不一致；403錯誤，表示資源不可用，訪問被禁止；404 錯誤，資源不存在；
- 5XX：服務端錯誤，無法響應客戶端請求。