談一談HTTP請求過程 三

2021-08-21 04:21:52 字數 1564 閱讀 6322

我們以訪問 google 為例,當我們在瀏覽器位址列中敲下回車鍵之後,整個計算機網路將會發生什麼呢?

本機的網路相關引數如下:

首先我們應用層的瀏覽器決定向 dns 伺服器請求解析網域名稱「www.google.com」,那麼就要遵循 dns 協議。

dns 執行在 53 號埠,於是瀏覽器會建立乙個 udp 套接字,標識該套接字的二元組分別是『目的 ip 位址』和『目的埠』。而套接字本質上就是為了唯一標識應用層程序,就是為了讓響應報文能夠找到目的地。

那麼這裡會建立乙個 udp 套接字,二元組為「本機 ip 位址 192.168.43.138」和「隨機產生乙個未使用的埠號」。

接著,瀏覽器將 dns 請求報文封裝好推入套接字,開始我們的 dns 解析過程。

有關 dns 的相關細節,這裡不再贅述了,可以參考前面的文章,拿到 dns 伺服器的響應報文,運輸層拆開資料報,得到該報文的目的 ip 位址和目的埠號,於是對應著去找套接字交付報文即可。

指定了一些請求引數與動作,以及一些要求響應報文的返回格式要求,具體的我們不細說了。

緊接著,這個報文會被推進 tcp 套接字中,等待運輸層來收取。

運輸層收取了報文,並判斷與目的主機是否建立了 tcp 連線,這裡假設沒有。

那麼,運輸層將不急著傳送應用層資料,得先判斷與目的主機之間能夠正常通訊,也就是需要『握手』打招呼。

『三次握手』的相關細節,我們這裡也不再贅述了,上篇文章描述的很詳細了,通過『三次握手』,傳送端和接收端確認過傳送與確認序號,分配了相應的快取資源等。

一切準備就緒之後,運輸層將應用層發過來的資料報又一層封裝,新增進『源埠號』和『目的埠號』以及相關差錯檢驗字段。

最後將 tcp 資料報向下傳遞到網路層。

網路層其實很簡單,拿到資料報並封裝成 ip 資料報,即在原 tcp 報文的前提之上新增『源 ip 位址』和『目的 ip 位址』等字段資訊。

然後交由資料鏈路層。

資料鏈路層拿到 ip 資料報,它需要封裝成乙太網幀才能在網路中傳輸,也就是它需要目的主機的 mac 位址,然而我們只知道目的主機的 ip 位址。

所以,鏈路層有乙個 arp 協議,直接或間接的能夠根據目的 ip 位址獲得使用該 ip 位址的主機 mac 位址。

當然,arp 協議執行的前提是,目的 ip 位址和當前傳送方主機處於同一子網路中。如果不然,傳送方將目的 mac 位址填自己閘道器路由的 mac 位址,然後通過物理層傳送出去。

閘道器路由由於具有**表和路由選擇演算法,所以它知道目的網路該怎麼到達,所以一路**,最終會傳送到目的網路的閘道器路由上。

最後,目的網路的閘道器路由同樣會經由 arp 協議,取得目的主機的 mac 位址,然後廣播傳送,最後被目的主機接受。

這樣谷歌的伺服器就接受到乙個 http 請求,於是它解析這個請求,確定該請求的動作是什麼,也就是它需要什麼東西,並構建響應報文,以同樣的方式從網路到達源主機。

最後你將看到你想要的谷歌搜尋頁面:

談一談HTTP協議

http1.0需要使用keep alive引數來告知伺服器端要建立乙個長連線,而http1.1預設就是長連線,http是基於tcp ip協議的,建立乙個tcp連線是需要經過三次握手的,有一定的開銷,如果每次通訊都要重新建立連線的話,對效能有影響,因此要維持乙個長連線,可以用乙個長連線來發多個請求 h...

談一談教育

今晚和研究生的師兄聊了會天,突然就說到教育的問題,有點感想,就寫下來,算是我對中國教育的一點看法吧。毫無疑問,中國的教育體制存在不少問題。在高中的時候或許還不是那麼明顯 對比起大學來說 上了大學,我才看清了我們教育的一些弊端。我覺得,最大的弊端,在於價值觀的引導問題上。不知道大家有沒和我一樣覺得當今...

談一談裁員

資本寒冬,經濟不景氣,要保持公司運作,可能會涉及到裁員。另外,有些員工的價值觀已經與公司不符,再留用可能會影響團隊和公司的和諧,此時也可能會涉及到裁員。裁員,不是說想裁就能裁的,需要考慮幾個方面 為什麼要裁?是否可以不裁?裁員是否會影響業務程序?裁員是否會付出經濟代價 賠償 裁員是否會負一定的法律責...