瀏覽器的一個請求從發送到返回都經歷了什麼

我大概講下個人答案：

一、先從網絡模型層面：

client （瀏覽器）與 server 經過 http 協議通信，http 協議屬於應用層協議，http 基於 tcp 協議，因此 client 與 server 主要經過 socket 進行通信；

而 tcp 屬於傳輸層協議、若是走 https 還須要會話層 TLS、SSL 等協議； 傳輸層之下網絡層，這裏主要是路由協議 OSPF 等進行路由轉發之類的。再向下數據鏈路層主要是 ARP、RARP 協議完成 IP 和 Mac 地址互解析，再向下到最底層物理層基本就是 IEEE 802.X 等協議進行數據比特流轉成高低電平的的一些定義等等；

當瀏覽器發出請求，首先進行數據封包，而後數據鏈路層解析 IP 與 mac 地址的映射，而後上層網路層進行路由查表路由，經過應用層 DNS 協議獲得目標地址對應的 IP ，在這裏進行 n 跳的路由尋路；而傳輸層 tcp 協議能夠說下比較經典的三次握手、四次分手的過程和狀態機，這裏放個圖能夠做爲參考：

二、應用層方面：

數據交換主要經過 http 協議， http 協議是無狀態協議，這裏能夠談一談 post、get 的區別以及 RESTFul 接口設計，而後能夠講服務器 server 模型 epoll、select 等，接着能夠根據實際經驗講下 server 處理流程，好比我： server 這邊 Nginx 拿到請求，進行一些驗證，好比黑名單攔截之類的，而後 Nginx 直接處理靜態資源請求，其餘請求 Nginx 轉發給後端服務器，這裏我用 uWSGI, 他們之間經過 uwsgi 協議通信，uWSGI 拿到請求，能夠進行一些邏輯， 驗證黑名單、判斷爬蟲等，根據 wsgi 標準，把拿到的 environs 參數扔給 Django ，Django 根據 wsgi 標準接收請求和 env， 而後開始 start_response ，先跑 Django 相關後臺邏輯，Django 拿到請求執行 request middleware 內的相關邏輯，而後路由到相應 view 執行邏輯，出錯執行 exception middleware 相關邏輯，接着 response 前執行 response middleware 邏輯，最後經過 wsgi 標準構造 response， 拿到須要返回的東西，設置一些 headers，或者 cookies 之類的，最後 finish_response 返回，再經過 uWSGI 給 Nginx ，Nginx 返回給瀏覽器。