在瀏覽器輸入url到頁面展示的過程

在瀏覽器輸入 url 到頁面展示的過程 ,我主要從網絡相關的層面去講一下。

當你輸入了 www.baidu.com 到頁面顯示出來一共發生了什麼?

解析url

首先這個過程肯定是需要涉及到 「 客戶端跟服務端的數據傳輸 」 的,數據傳輸的前提就是 「 雙方建立連接 」 ,那麼這個建立連接的過程是如何建立的呢?

當你敲上網址然後敲了回車之後,瀏覽器就會開始解析這個域名了,其實解析域名最主要的就是 「 把url網址解析成對應的服務器的IP地址 」 ,而解析成地址的方式有很多種,這裡從最外層的瀏覽器一直到路由器再到dns服務器都有。具體流程的話有:

  1. 檢查瀏覽器緩存中是否緩存過該域名對應的IP地址
  2. 查看host文件有沒有跟域名對應的規則(本地主機host文件中一般會存儲經常訪問的url到host文件中)。
  3. 查看路由器裡面有沒有緩存。
  4. 最後才發出DNS請求到本地DNS(域名分佈系統)服務器 。本地DNS服務器一般都是你的網絡接入服務器商提供,比如中國電信,中國移動。

建立tcp連接

為什麼要建立tcp連接呢?主要就是為了保證兩端能夠進行 「 可靠的傳輸 」 ,可靠的傳輸的基本,就是兩端對數據的發送和接收的功能。

ssl / tls 證書

ssl / tls 是什麼?大白話來說一下,在我們中國,身份證就是我們個人的專屬身份的標誌,同理,在網絡中,為了確定連接那頭的人是不是你要找的人,就會有一個大型的網上認證系統,ssl / tls 其實就是每個人自己服務器的 身份證, 確認了建立連接對面的人是你要的那個人,就是通過 ssl / tls 這個證書來確認的。

所以由於http的 「 明文傳輸 」 ,導致了一次普通的沒有 身份證 的http的調用其實是不不夠安全的,有可能會被惡意修改數據或者是截取信息,這個時候https來了,它主要就是通過 ssl / tls 提供驗證服務端的身份,加密處理數據等等,只要服務端提前在ca機構註冊好自己的

身份證, 就可以做到保證兩端身份的確定性,就進行可靠安全的傳輸了。這裡的話不細講具體是如何加密的,簡單說一下流程。

  1. 客戶端向服務端請求連接,請求頭裡麵包含了客戶端支持的加密解密類型等等。
  2. 服務端根據客戶端可接受的加密類型中,選擇最合適自己的那一個,加密自己的私鑰,並且存在證書裡面,連同 「 證書 」 一起發給客戶端。
  3. 客戶端收到證書之後,首先向權威 「 ca機構 」 驗證證書的有效性,確認了服務端的身份後,將自己用來對稱加密的公鑰用證書返回的公鑰加密,發送給服務端。

總的來說,就是確定了雙方同時持有對稱加密使用的公鑰,就可以安全的進行傳輸了。

這裡補充一下,假如服務端申請了客戶端未信任的證書機構的話(也有可能自己製作ssl證書),客戶端需要信任(或者直接拒絕訪問了),而且自制的ssl證書容易被偽造的,不咋安全(畢竟沒收到國際認證和電子簽發許可),所以這也是一種可能被釣魚的情況之一。

三次握手

三次握手的主要目的,就是確定 「 雙方同時具備正常的收和發功能 」 的功能,需要站在客戶端和服務端的角度來看這個為什麼需要三次握手的問題,接下來說一下流程:

  1. 客戶端發送連接請求 「 你好服務器兄弟聽得到嗎 」 給服務端,服務端收到。

「 服務端的角度 」

服務端的角度:我服務端收到了客戶端的消息,所以服務端是知道客戶端的發是正常的,服務端自己的收也是正常的。


作者:同花技術筆記
鏈接:https://juejin.im/post/5e7225b5e51d452709675485

在瀏覽器輸入url到頁面展示的過程

「 客戶端的角度 」

客戶端的角度:不清楚自己發出去的服務端收到沒,也不清楚自己能不能收到服務端的消息。

在瀏覽器輸入url到頁面展示的過程

  • 服務端發送 「 聽得到啊,客戶端兄弟聽得到嗎 」 給客戶端,客戶端收到了。
  • 「 服務端的角度 」

    服務端的角度:是隻能確認自己的收是正常的,但是不確定客戶端有沒有收到自己發出去的東西。


    在瀏覽器輸入url到頁面展示的過程

    「 客戶端的角度 」

    客戶端的角度:客戶端是已經可以確認,客戶端的收發的功能都是正常的,服務端的收發功能也是正常的。(此時客戶端的角度已經確認好了)。


    在瀏覽器輸入url到頁面展示的過程

  • 客戶端發送 「 我也聽得到 」
    給服務端。
  • 這個時候服務端才知道,客戶端收到了,所以就確認了自己可以發數據給客戶端。(此時服務端的角度也確認好了)。 總的來說,照著 「 確定雙方同時具備收和發的功能 」 這個思路說下去,三次握手就很好理解了。

    「 服務端的角度 」

    在瀏覽器輸入url到頁面展示的過程

    「 客戶端的角度 」


    在瀏覽器輸入url到頁面展示的過程

    數據傳輸。

    連接建立後自然就是發送數據了,這時候客戶端也就可以發送請求給服務端了,服務端收到對應的請求,(可能有代理)找到自己的對應的服務對應的端口去做相應的處理,並反回數據給客戶端(tcp的擁塞機制)。


    在瀏覽器輸入url到頁面展示的過程


    四次揮手

    四次揮手 「 連接終止協議 」 ,這個很好理解,主要就是確認雙方都沒有數據發送了。

    為什麼要四次揮手? 主要就是因為上面說到的三次握手,建立的連接是去確定雙方同時具備收和發的功能來建立的一個通道,那麼關閉這個通道肯定也是要雙方去確認的,所以我們可以按照這個思路往下去整理。

    1. 當客戶端發起所有需要的請求後,決定關閉連接了,他向服務器發送了一個 「 我已經沒啥要的了 」
    2. 服務器收到後,要給客戶端返回一個 「 收到 」

    其實這樣的話是存在服務器數據還沒發完數據的情況的,所以上面的兩次揮手的主要作用只是斷開了客戶端的發,但服務器還是可以繼續傳輸沒傳輸完的數據。

    1. 當服務器發送完所有之後,決定關閉連接了,他向客戶端發送了一個 「 我也把東西都發完給你了 」
    2. 完了客戶端也要回復一個 「 收到 」

    到此四次揮手就結束了,這裡補充一張四次揮手的圖給大家參悟一下。


    在瀏覽器輸入url到頁面展示的過程


    最後

    關於https相關流程可以看看 HTTPS原理及流程。


    作者:同花技術筆記
    鏈接:https://juejin.im/post/5e7225b5e51d452709675485


    分享到:


    相關文章: