從輸入URL到頁面加載的過程
之前一直都是直接看一下總結的八股文章,對于實際的整個鏈路并不是特別熟悉,這次花了一天多的時間看了很多資料,對于整個頁面加載的流程有了自己的理解,從前端開始訪問的瀏覽器多線程、緩存等問題,到計算機網絡的各層協議的處理,再到服務器接收請求的整個過程,都進行了一些了解,原始文檔是在飛書中寫的,所以在這邊排版可能會存在一些問題,已經修改了一部分。
文章的不足之處也請大佬在評論中指出!
1. HTTP 解析URL:
瀏覽器是多進程,瀏覽器內核是多線程,瀏覽器接收URL,瀏覽器根據解析出的協議,根據解析的內容生成HTTP請求,開辟一個網絡線程去請求資源,會先查找本地緩存是否緩存了該資源,如果有緩存資源那么直接返回資源給瀏覽器進程;如果在本地緩存中沒有查找到資源,那么直接進入網絡請求流程;
2. DNS(應用層協議) 解析:
如果輸入的是域名,需要將域名解析成對應的 IP 地址,如果請求協議是HTTPS,那么還需要建立SSL/TLS連接(TLS的四次握手在TCP的三次握手之后);(DNS的解析過程見問題5) 通過DNS獲取到IP之后,就可以把HTTP的傳輸工作交給操作系統中的協議棧。
應用程序(瀏覽器)通過調用 Socket 庫,來委托協議棧工作。協議棧的上半部分有兩塊,分別是負責收發數據的 TCP 和 UDP 協議,這兩個傳輸協議會接受應用層的委托執行收發數據的操作。
協議棧的下面一半是用 IP 協議控制網絡包收發操作,在互聯網上傳數據時,數據會被切分成一塊塊的網絡包,而將網絡包發送給對方的操作就是由 IP 負責的。
此外 IP 中還包括 ICMP 協議和 ARP 協議。
- ICMP 用于告知網絡包傳送過程中產生的錯誤以及各種控制信息。
- ARP 用于根據 IP 地址查詢相應的以太網 MAC 地址。
IP 下面的網卡驅動程序負責控制網卡硬件,而最下面的網卡則負責完成實際的收發操作,也就是對網線中的信號執行發送和接收操作。
3. TCP 連接:
利用IP地址和服務器通過三次握手,建立 TCP 連接(HTTP是基于TCP協議傳輸的)(詳細內容見問題15)
TCP 的連接狀態查看,在 Linux 可以通過 netstat -napt 命令查看
4. 向服務器發送 HTTP 請求:
連接建立之后,瀏覽器端會構建請求行、請求頭等信息,并把和該域名相關的 Cookie 等數據附加到請求頭中,然后向服務器發送構建的請求信息。
五層協議棧:從應用層的發送http請求,到傳輸層通過三次握手建立tcp/ip連接,再到網絡層的ip尋址,再到數據鏈路層的封裝成幀,最后到物理層的利用物理介質傳輸。
- HTTP報文(請求方式+URL+數據)
- 傳輸層添加TCP頭部(源端口號+目的端口號)
- IP 增加 IP報文頭部(協議號(06表示協議為TCP) + 源IP地址 + 目的IP地址)
- 添加以太網頭部(MAC地址):接收方 MAC 地址、發送方 MAC 地址 ARP協議通過廣播的方式幫我們找到MAC地址
- 網卡將包轉為電信號通過網線發出
- 交換機:電信號到達網線接口,交換機里的模塊進行接收,將電信號轉換為數字信號,校驗完成之后,如果是發送給自己的則將包放入緩沖區,接下來查詢接收方MAC地址,交換機根據 MAC 地址表查詢 MAC 地址,然后將信號發送到相應的端口。
如果沒有在MAC地址表中查詢到指定的MAC地址,就將接收方MAC地址置為廣播地址,將包發送到除了源端口之外的所有端口。
- 路由器:這一步轉發的工作原理和交換機類似,也是通過查表判斷包轉發的目標
5. 服務器處理請求,返回 HTTP 響應:
- Nginx可以處理靜態請求,也可以將動態請求轉發;
- Gateway網關處理,用于處理請求的路由、認證、授權等;
- 應用服務器服務器處理:請求被轉發到后端服務器,執行相應的邏輯;
- 應用服務器生成HTTP響應。
6. 瀏覽器解析并渲染頁面:遇到外鏈資源的情況下,會單獨開啟一個線程去下載資源;
7. 斷開連接:TCP 四次揮手,連接結束
參考文檔:
- 從輸入URL到頁面加載的過程?如何由一道題完善自己的前端知識體系! | Dailc的個人主頁
- 一文讀懂網關概念+Nginx正反向代理+負載均衡+Spring Cloud Gateway
- 在瀏覽器輸入 URL 回車之后發生了什么(超詳細版)