1. 程式人生 > >從瀏覽器輸入一個URL(www.baidu.com)的全過程

從瀏覽器輸入一個URL(www.baidu.com)的全過程

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,IP,SOFP

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:相應正文使用的語言

空行:表示響應頭結束

響應正文