從使用者在瀏覽器輸入網域名稱開始，到web頁面載入完畢，這是乙個說複雜不複雜，說簡單不簡單的過程，下文暫且把這個過程稱作網頁載入過程。下面我將依靠自己的經驗，總結一下整個過程。如有錯漏，歡迎指正。
閱讀本文需要讀者已有一定的計算機知識，了解tcp、dns等。
眾所周知，開啟乙個網頁的過程中，瀏覽器會因頁面上的css/js/image等靜態資源會多次發起連線請求，所以我們暫且把這個網頁載入過程分成兩部分：
html(jsp/php/aspx) 頁面載入(假設存在簡單的nginx負載均衡)
css/js/image等 網頁靜態資源載入(假設使用cdn)
什麼是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域伺服器去進一步解析。所以其實這部分的網域名稱解析過程是乙個樹形的搜尋過程。
根域伺服器告訴我們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後，一步步向上返回，直到返回給瀏覽器。
瀏覽器會選擇乙個大於1024的本機埠向目標ip位址的80埠發起tcp連線請求。經過標準的tcp握手流程，建立tcp連線。
關於tcp協議的細節，這裡就不再闡述。這裡只是簡單地用一張圖說明一下tcp的握手過程。如果不了解tcp，可以選擇跳過此段，不影響本文其他部分的瀏覽。
其本質是在建立起的tcp連線中，按照http協議標準傳送乙個索要網頁的請求。
什麼是負載均衡？當一台伺服器無法支援大量的使用者訪問時，將使用者分攤到兩個或多個伺服器上的方法叫負載均衡。
什麼是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鏈處理，之後發回給我們的瀏覽器。
而filter的功能可以理解成先把前一步生成的結果處理一遍，再返回給瀏覽器。比如可以將前面沒有壓縮的網頁用gzip壓縮後再返回給瀏覽器。
1) 瀏覽器根據頁面內容，生成dom tree。根據css內容，生成css rule tree(規則樹)。呼叫js執行引擎執行js**。
2) 根據dom tree和css rule tree生成render tree(呈現樹)
3) 根據render tree渲染網頁
但是在瀏覽器解析頁面內容的時候，會發現頁面引用了其他未載入的image、css檔案、js檔案等靜態內容，因此開始了第二部分。
以阿里巴巴的**網首頁的logo為例，其url位址為 img.alicdn.com/tps/i2/tb1bne7lf***xaoxfxxwfsa1***-292-116.png_145x145.jpg
我們清楚地看到了url中有cdn字樣。
什麼是cdn？如果我在廣州訪問杭州的**網，跨省的通訊必然造成延遲。如果**網能在廣東建立乙個伺服器，靜態資源我可以直接從就近的廣東伺服器獲取，必然能提高整個**的開啟速度，這就是cdn。cdn叫內容分發網路，是依靠部署在各地的邊緣伺服器，使使用者就近獲取所需內容，降低網路擁塞，提高使用者訪問響應速度。
接下來的流程就是瀏覽器根據url載入該url下的內容。本質上是瀏覽器重新開始第一部分的流程，所以這裡不再重複闡述。區別只是負責均衡伺服器後端的伺服器不再是應用伺服器，而是提供靜態資源的伺服器。
乙個網頁開啟的全過程
從使用者在瀏覽器輸入網域名稱開始，到web頁面載入完畢，這是乙個說複雜不複雜，說簡單不簡單的過程，下文暫且把這個過程稱作網頁載入過程。下面我將依靠自己的經驗，總結一下整個過程。如有錯漏，歡迎指正。閱讀本文需要讀者已有一定的計算機知識，了解tcp dns等。眾所周知，開啟乙個網頁的過程中，瀏覽器會因頁...
訪問乙個網頁的全過程
前言 訪問目標位址有兩種方式 使用目標ip位址訪問。由於ip位址是一堆數字不方便記憶，於是有了網域名稱這種字元型標識。使用網域名稱訪問。網域名稱解析就是網域名稱到ip位址的轉換過程，網域名稱的解析工作由dns伺服器完成。比如說訪問 baidu.com 1.如果是網域名稱，首先將網域名稱解析成ip 計...
訪問乙個網頁的全過程詳解！
開啟乙個網頁的過程中，瀏覽器會因頁面上的css js image等靜態資源會多次發起連線請求，所以我們暫且把這個網頁載入過程分成兩部分 1 html jsp php aspx 頁面載入 假設存在簡單的nginx負載均衡 2 css js image等 網頁靜態資源載入 假設使用cdn 什麼是dns解...