2018-07-16 ( 一個網頁打開的全過程)

一個網頁打開的全過程

<article style="box-sizing: inherit; outline: 0px; display: block; position: relative; padding-top: 16px; color: rgb(51, 51, 51); font-family: "SF Pro Display", Roboto, Noto, Arial, "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;">

1、概要

從用戶在瀏覽器輸入域名開始,到web頁面加載完畢,這是一個說復雜不復雜,說簡單不簡單的過程,下文暫且把這個過程稱作網頁加載過程。下面我將依靠自己的經驗,總結一下整個過程。如有錯漏,歡迎指正。

閱讀本文需要讀者已有一定的計算機知識,了解TCP、DNS等。

2、分析

眾所周知,打開一個網頁的過程中,瀏覽器會因頁面上的css/js/image等靜態資源會多次發起連接請求,所以我們暫且把這個網頁加載過程分成兩部分:

  1. html(jsp/php/aspx) 頁面加載(假設存在簡單的Nginx負載均衡)
  2. css/js/image等 網頁靜態資源加載(假設使用CDN)

2.1 頁面加載

先上一張圖,直觀明了地讓大家了解下基本流程,然后我們再逐一分析。

1.jpg

2.1.1 DNS解析

什么是DNS解析?當用戶輸入一個網址并按下回車鍵的時候,瀏覽器得到了一個域名。而在實際通信過程中,我們需要的是一個IP地址。因此我們需要先把域名轉換成相應的IP地址,這個過程稱作DNS解析。

1) 瀏覽器首先搜索瀏覽器自身緩存的DNS記錄。

或許很多人不知道,瀏覽器自身也帶有一層DNS緩存。Chrome 緩存1000條DNS解析結果,緩存時間大概在一分鐘左右。

(Chrome瀏覽器通過輸入:chrome://net-internals/#dns 打開DNS緩存頁面)

2) 如果瀏覽器緩存中沒有找到需要的記錄或記錄已經過期,則搜索hosts文件和操作系統緩存。

在Windows操作系統中,可以通過 ipconfig /displaydns 命令查看本機當前的緩存。

通過hosts文件,你可以手動指定一個域名和其對應的IP解析結果,并且該結果一旦被使用,同樣會被緩存到操作系統緩存中。

Windows系統的hosts文件在%systemroot%\system32\drivers\etc下,linux系統的hosts文件在/etc/hosts下。

3) 如果在hosts文件和操作系統緩存中沒有找到需要的記錄或記錄已經過期,則向域名解析服務器發送解析請求。

其實第一臺被訪問的域名解析服務器就是我們平時在設置中填寫的DNS服務器一項,當操作系統緩存中也沒有命中的時候,系統會向DNS服務器正式發出解析請求。這里是真正意義上開始解析一個未知的域名。

一般一臺域名解析服務器會被地理位置臨近的大量用戶使用(特別是ISP的DNS),一般常見的網站域名解析都能在這里命中。

4) 如果域名解析服務器也沒有該域名的記錄,則開始遞歸+迭代解析。

這里我們舉個例子,如果我們要解析的是mail.google.com。

首先我們的域名解析服務器會向根域服務器(全球只有13臺)發出請求。顯然,僅憑13臺服務器不可能把全球所有IP都記錄下來。所以根域服務器記錄的是com域服務器的IP、cn域服務器的IP、org域服務器的IP……。如果我們要查找.com結尾的域名,那么我們可以到com域服務器去進一步解析。所以其實這部分的域名解析過程是一個樹形的搜索過程。

image
   根域服務器告訴我們com域服務器的IP。

接著我們的域名解析服務器會向com域服務器發出請求。根域服務器并沒有mail.google.com的IP,但是卻有google.com域服務器的IP。

接著我們的域名解析服務器會向google.com域服務器發出請求。...

如此重復,直到獲得mail.google.com的IP地址。

為什么是遞歸:問題由一開始的本機要解析mail.google.com變成域名解析服務器要解析mail.google.com,這是遞歸。

為什么是迭代:問題由向根域服務器發出請求變成向com域服務器發出請求再變成向google.com域發出請求,這是迭代。

5) 獲取域名對應的IP后,一步步向上返回,直到返回給瀏覽器。

2.1.2 發起TCP請求

瀏覽器會選擇一個大于1024的本機端口向目標IP地址的80端口發起TCP連接請求。經過標準的TCP握手流程,建立TCP連接。

關于TCP協議的細節,這里就不再闡述。這里只是簡單地用一張圖說明一下TCP的握手過程。如果不了解TCP,可以選擇跳過此段,不影響本文其他部分的瀏覽。

image

2.1.3 發起HTTP請求

其本質是在建立起的TCP連接中,按照HTTP協議標準發送一個索要網頁的請求。

2.1.4 負載均衡

什么是負載均衡?當一臺服務器無法支持大量的用戶訪問時,將用戶分攤到兩個或多個服務器上的方法叫負載均衡。

什么是Nginx?Nginx是一款面向性能設計的HTTP服務器,相較于Apache、lighttpd具有占有內存少,穩定性高等優勢。

負載均衡的方法很多,Nginx負載均衡、LVS-NAT、LVS-DR等。這里,我們以簡單的Nginx負載均衡為例。關于負載均衡的多種方法詳情大家可以Google一下。

Nginx有4種類型的模塊:core、handlers、filters、load-balancers。

我們這里討論其中的2種,分別是負責負載均衡的模塊load-balancers和負責執行一系列過濾操作的filters模塊。

1) 一般,如果我們的平臺配備了負載均衡的話,前一步DNS解析獲得的IP地址應該是我們Nginx負載均衡服務器的IP地址。所以,我們的瀏覽器將我們的網頁請求發送到了Nginx負載均衡服務器上。

2) Nginx根據我們設定的分配算法和規則,選擇一臺后端的真實Web服務器,與之建立TCP連接、并轉發我們瀏覽器發出去的網頁請求。

Nginx默認支持 RR輪轉法 和 ip_hash法 這2種分配算法。

前者會從頭到尾一個個輪詢所有Web服務器,而后者則對源IP使用hash函數確定應該轉發到哪個Web服務器上,也能保證同一個IP的請求能發送到同一個Web服務器上實現會話粘連。

也有其他擴展分配算法,如:

fair:這種算法會選擇相應時間最短的Web服務器

url_hash:這種算法會使得相同的url發送到同一個Web服務器

3) Web服務器收到請求,產生響應,并將網頁發送給Nginx負載均衡服務器。

4) Nginx負載均衡服務器將網頁傳遞給filters鏈處理,之后發回給我們的瀏覽器。

image

而Filter的功能可以理解成先把前一步生成的結果處理一遍,再返回給瀏覽器。比如可以將前面沒有壓縮的網頁用gzip壓縮后再返回給瀏覽器。

2.1.5 瀏覽器渲染

1) 瀏覽器根據頁面內容,生成DOM Tree。根據CSS內容,生成CSS Rule Tree(規則樹)。調用JS執行引擎執行JS代碼。

2) 根據DOM Tree和CSS Rule Tree生成Render Tree(呈現樹)

3) 根據Render Tree渲染網頁

但是在瀏覽器解析頁面內容的時候,會發現頁面引用了其他未加載的image、css文件、js文件等靜態內容,因此開始了第二部分。

2.2 網頁靜態資源加載

以阿里巴巴的淘寶網首頁的logo為例,其url地址為 img.alicdn.com/tps/i2/TB1bNE7LFXXXXaOXFXXwFSA1XXX-292-116.png_145x145.jpg

我們清楚地看到了url中有cdn字樣。

什么是CDN?如果我在廣州訪問杭州的淘寶網,跨省的通信必然造成延遲。如果淘寶網能在廣東建立一個服務器,靜態資源我可以直接從就近的廣東服務器獲取,必然能提高整個網站的打開速度,這就是CDN。CDN叫內容分發網絡,是依靠部署在各地的邊緣服務器,使用戶就近獲取所需內容,降低網絡擁塞,提高用戶訪問響應速度。

接下來的流程就是瀏覽器根據url加載該url下的圖片內容。本質上是瀏覽器重新開始第一部分的流程,所以這里不再重復闡述。區別只是負責均衡服務器后端的服務器不再是應用服務器,而是提供靜態資源的服務器。

</article>

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,401評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,011評論 3 413
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事?!?“怎么了?”我有些...
    開封第一講書人閱讀 175,263評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,543評論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,323評論 6 404
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,874評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 42,968評論 3 439
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,095評論 0 286
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,605評論 1 331
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,551評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,720評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,242評論 5 355
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 43,961評論 3 345
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,358評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,612評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,330評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,690評論 2 370

推薦閱讀更多精彩內容