1. 在瀏覽器輸入一個網址或在頁面裡點選一個超連結
2. 本機上的dns開始解析，看最近這兩天有沒有訪問過這個網站(本機dns最多儲存1000個最近訪問的網址)，有的話直接返回。沒有的話，本機dns會將這個網址傳送給dns根伺服器
3. dns根伺服器收到這個網址以後，進行解析(具體解析過程見下文)，最後會返回一個ip地址給瀏覽器
4. 瀏覽器拿到這個ip以後，也就是知道這個web伺服器的地址了，就開始對其進行訪問
5. 首先通過tcp三次握手與這個web伺服器進行連線
6. 連線建立以後，瀏覽器開始往伺服器傳送http請求（get或post之類）
7. web伺服器收到這個請求，解析以後，返回對應的靜態資源和動態資源（html頁面和js），瀏覽器解析，顯示在頁面

第三步：DNS的解析

① 本機向負責自己的本地DNS傳送查詢報文，如果本地伺服器快取中有，直接返回。
②本地DNS伺服器發現快取中沒有，於是從內建在內部的根伺服器列表中選一個傳送查詢報文。
③DNS根伺服器解析一下字尾名，告訴本地DNS伺服器負責.com的所有頂級伺服器列表。
④本地伺服器選擇一個頂級域伺服器繼續查詢，.com域伺服器拿到域名後又開始解析，返回 負責.xx域的所有權威伺服器的列表。
⑥本地伺服器從返回的權威伺服器之一再次傳送查詢報文，最終會從某一個權威伺服器上得到具體的ip地址
⑦本地DNS伺服器拿到解析結果
⑧本機獲取到最終的ip地址
⑨對對應ip地址的web伺服器發起請求
⑩拿到頁面並展示

ps：也可以把這個DNS解析過程看成是一個從DNS角度來解釋一個請求的過程，之後的建立tcp連線之類的都存在於⑨，發起請求這一步。
整個DNS報文的傳送與響應過程都要走網路模型的五層協議
連結：https://blog.csdn.net/qzcsu/article/details/72861891

第五步：TCP三次握手建立連線

三次握手目的：為了防止已經失效的連線請求報文段突然又傳到伺服器，因而產生錯誤
Q ：為什麼要三次握手而不是兩次？
A ：假如客戶端發出去的第一個連線請求阻塞在了某個網路節點裡(可不可以理解為某個路由裡)，一直延遲到連線釋放以後伺服器端才收到這個請求，本來這事一個失效的請求，而伺服器端收到以後，以為這是一個新的連線請求，於是伺服器端又給客戶端傳送了確認報文，表示確認建立。假如不採用三次握手，伺服器端就會認為，只要我這邊確認報文發出去了，連線就建立了，會一直等待著客戶端的資料，但是客戶端並沒有發出建立連線的請求，所以不會向伺服器端傳送資料，就這樣進入了死等，浪費了伺服器端大量的資源。所以有了三次握手。有了三次握手，假如伺服器端收到一個過時失效的請求報文，向客戶端傳送確認報文，此時客戶端並沒有要求建立建立，所以就不會向伺服器端傳送確認報文，連線就不會建立。

舉個栗子：
三次握手打電話：
A：喂，能聽見嗎？
B：嗯，能聽見，你能聽見我說話嗎？
A：嗯，我也能聽見，Balbala。。。。。。。

沒有三次握手的打電話：
A：喂，能聽見嗎？
（A通電話說完話以後去廁所了）
B：嗯，能聽見。
（A在廁所拉肚子，拉完以後出來忘記打了電話）
B：？？？？？。。。。。。

第七步：伺服器解讀請求

當TCP連線建立以後，瀏覽器就開始給伺服器發起了http請求，當伺服器端web程式接受到http請求以後，基於開始處理這個請求，處理之後返回給瀏覽器html檔案。
那麼，伺服器端收到這個http請求之後，到底是怎麼生成html檔案的？
（假如這個伺服器配置了nginx）

1. nginx在收到瀏覽器的請求時，會讀取http請求裡面頭部的資訊，根據host來匹配自己的所有 的虛擬主機的配置檔案server_name，看看有沒有匹配的，有匹配的就讀取改虛擬主機的配置，也就相當於， 靜態的html頁面，是在nginx這裡搞定的
2. 當html頁面到達瀏覽器的時候，瀏覽器會解析這個html，看需不需要別的資源，比如js/css/img，需要的話就想伺服器端請求下載
3. 動態資源。。。。。。。。資料庫。。。。

第八步：TCP四次揮手