瀏覽器輸入一個URL地址訪問的全過程

原文鏈接:https://blog.csdn.net/weixin_38497513/article/details/80918425

1.根據域名到DNS中找到IP

2.根據IP建立TCP連接(三次握手)

3.連接建立成功發起http請求

4.服務器響應http請求

5.瀏覽器解析HTML代碼並請求html中的靜態資源(js,css)

6.關閉TCP連接(四次揮手)

7.瀏覽器渲染頁面

一、解析DNS域名

1.瀏覽器查找自己的DNS緩存,如果有直接返回,如果沒有進行步驟二

2.操作系統查找自己的DNS緩存,如果有直接返回給瀏覽器,如果沒有進行步驟三

3.操作系統查找自己的本地host文件,如果有返回給瀏覽器,如果沒有則進行步驟四

4.操作系統向本地域名服務器發起請求,查找本地DNS緩存,如果有,返回給操作系統,然後操作系統返回給瀏覽器,如果沒有進行步驟五

5.操作系統向根域名服務器發起請求得到頂級域名服務器的IP,然後根域名服務器向頂級域名服務器發起請求得到權限域名服務器的IP,頂級域名服務器再向權限域名服務器發起請求得到IP,本地域名服務器返回給操作系統IP,同時將IP緩存起來,操作系統將IP返回給瀏覽器,同時將IP緩存起來。

二、過程中使用到的協議

該過程中使用到了ARP,RIP,OSFP

ARP(地址解析協議):他主要解決的是同一個局域網內主機或路由器IP地址和MAC地址之間的映射問題。

                                     工作過程:當源主機要發送數據的時候,他會查看自己的ARP高速緩存中是否有目的主機IP地址對應的MAC地址,如果與,則直接發送,如果沒有,他就會向本網段所有主機發送ARP請求分組,接到請求的主機查看目的IP與自己的IP是否相等,如果不等就忽略,如果相等,就把源主機的IP和MAC寫入自己的ARP高速緩存,如果之前有就覆蓋掉,然後把自己的MAC寫入ARP相應包,源主機接到ARP響應包後把目的主機的IP和MAC地址寫入ARP高速緩存,並且利用此信息發送數據。

路由選擇協議

1.內部網關協議

1)RIP協議

 RIP基於UDP的應用層協議,他認爲一個好的路由是他通過的路由器少,RIP允許一條路徑最多可以包含15個路由,16個即爲不可達了。

 工作過程:假設路由器R0向R1發送一個報文段

                 首先修改R0發來的RIP報文中所有的項目,把嚇一跳字段的地址改爲R0,把所有距離字段值加1,

                 對於修改後的RIP報文的每一項進行如下步驟,

                 步驟一、首先看原來的路由表中是否有目的網絡N,如果沒有直接加入到路由表中,如果有進行步驟2

                 步驟二、然後看嚇一跳,如果嚇一跳的地址是R0則用新的項目替換原來的項目,如果嚇一跳不同則進行步驟三

                 步驟三、對比距離,如果距離小於源路由器的項目,那麼更新,否則什麼都不做。

首先將R0發來的路由更新信息的距離都+1,下一跳都改爲R0

Net1在源路由表中沒有所以直接寫入,Net2中嚇一跳相同,直接覆蓋原路由表中的Net2那一行,Net3的嚇一跳不同,所以選擇路徑最小的。

2)OSPF(最短路徑優先)

     OSPF是網絡層協議基於IP,當路由的鏈路狀態發生變化時,他會使用洪泛法向本自治系統中所有路由發送自己的的鏈路狀態(鏈路狀態就是自己和那些路由相鄰)

2.外部網關協議

BGP

BGP是不同自治系統路由器之間交換路由信息的協議,他只是力求尋找能達到目的網絡的比較好的協議,而並非最佳路由。

BGP發言人:每一個自治系統的管理員都需要至少有一個路由器作爲BGP發言人,BGP發言人一般是邊界路由器,當然也有不是邊界路由器的情況。

BGP交換路由信息:BGP發言人如果想和別的自治系統的BGP發言人交換信息(到達某個網絡所要經歷的一系列AS),他需要先建立起TCP連接,連接建立成功後在此鏈接上交換BGP報文,建立BGP會話,使用TCP是因爲可以提供可靠的服務,也簡化了路由選擇協議。

     

三、HTTP報文格式

 

Http請求報文結構

http報文結構由請求行,請求頭,空行、請求正文組成(Get請求,沒有請求正文)

請求行:請求方法、url、版本號

請求頭:Host:接收請求的服務器地址,可以是ip也可以是端口號

             User-Agent:發送請求的應用程序名稱

             Connection:指定與連接相關的屬性,Connection:Keep-Alive

             Accept-Charset:指定可接收的編碼格式

             Accept-Encoding:指定可接收的數據壓縮格式

             Accept-Language:指定可以接收的語言

空行:表示請求頭結束

請求正文:可選,get就沒有請求正文

 

 

 

Http響應報文結構

http響應報文由狀態行、響應頭、空行、響應正文四部分組成

 

狀態行:協議版本、狀態碼、狀態描述,之間用空格分開

響應頭:Server:服務器應用程序軟件的名稱和版本號

             Content-Type:相應正文的類型(是圖片還是二進制)

             Content-Length:相應正文的長度

             Content-Charset:相應正文的使用編碼

             Content-Encoding:相應正文使用的數據壓縮格式

             Content-Language:相應正文使用的語言

空行:表示響應頭結束

響應正文

 

 
 ———————————————— 
版權聲明:本文爲CSDN博主「是Y呀」的原創文章,遵循CC 4.0 by-sa版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/weixin_38497513/article/details/80918425

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章