URL加載頁面的過程

整體過程：

一、DNS解析

二、TCP鏈接

三、發送HTTP請求

四、服務器處理請求並返回HTTP報文

五、瀏覽器解析渲染頁面

六、鏈接結束

 

 

1、DNS解析

在互聯網中，每一臺機計算機的惟一 標識是他的IP地址，因爲IP地址難以記憶，所以便有了與其相對應的網址，便於用戶搜索網站。因而，DNS解析就是將網址（即域名）解析爲IP地址的過程，具體以下（盜）圖：

 

講解一波：

忽然計算機中瀏覽器中有人輸入了www.google.com；

一、瀏覽器問本地域名服務器，你有沒有www.google.com的IP地址呢？（沒有）；

二、本地域名服務器去問根域名服務器，你有沒有www.google.com的IP地址呢？；

三、根域名返回答案：我沒有誒！；

四、本地域名服務器獲得答案後，就再去問COM頂級域名服務器，你有沒呢？；

五、頂級域名服務器也返回答案說：我也沒有呢！不過你能夠去找一下google.com；

六、本地域名服務器又去問了最終boss（google.com）；

7.google.com說我有www.google.com的IP地址呢！因而將IP地址返回給本地域名服務器；

八、本地域名服務器終於拿到了IP地址，因而將IP地址告訴給了瀏覽器；

 

以上過程爲最原始的DNS域名解析過程，可見覆雜與繁瑣程度，在現代用戶量與請求數以百萬級別計算的互聯網時代，假若每次訪問都須要進行這些步驟，顯然是不科學的。

因而，DNS緩存出現了。

上圖可見，DNS緩存在較近距離的服務器或者瀏覽器中，則第二次查詢的過程與時間便縮短不少。

DNS緩存，根據距離遠近分別爲：瀏覽器緩存、系統緩存、路由器緩存、IPS服務器緩存、根域名服務器緩存、頂級域名服務器緩存、主域名服務器緩存。

關於訪問頁面過程的優化還有一項：DNS負載均衡。

DNS負載均衡，又稱DNS重定向；是一種以空間換時間的技術。

具體實現爲：

假若用戶訪問的IP地址不變，都在某一臺服務器上，那該服務器所須要承受的性能要求便很是高。所以，做爲用戶，它只須要獲得對應的IP地址和請求內容就能夠，並不會在意是哪臺服務器提供的。

其中CDN（content  delivery network）內容分發網絡，就是一門DNS重定向技術，爲用戶響應最近的服務器須要的IP地址和請求內容。這樣將會大量提升用戶訪問速度。（空間交換時間）。

 

2、TCP鏈接

 TCP/IP協議簇共有四層，分別對應以下：

       應用層 ： HTTP、FTP、DNS、SMTP等

　　傳輸層：TCP、UDP等

　　網絡層：IP、ARP等

　　數據鏈路層：802.十一、WIFI等

 

TCP的鏈接與斷開過程，共須要發7個包才能實現，成爲「三次握手，四次揮手」，以下：

第一次握手：客戶端發送帶SYN標誌的數據報；（SYN請求鏈接）

第二次握手：服務端發送迴帶SYN/ACK標誌的數據報；（ACK確認應答，SYN請求鏈接）

第三次握手：客戶端發送帶ACK標誌的數據報；（ACK確認應答）

鏈接成功。

第一次揮手：客戶端發送帶FIN標誌的數據報；（FIN請求切開鏈接）

第二次揮手：服務端發送帶ACK標誌的數據報；（ACK確認應答）

第三次揮手：服務端發送帶FIN標誌的數據報；（FIN請求切開鏈接）

第四次揮手：客戶端發送帶ACK標誌的數據報；（ACK確認應答）

 

3、發送HTTP請求

 HTTP請求是基於TCP鏈接上的，也就是說只有創建起了TCP鏈接以後才能進行HTTP請求。

HTTP報文的整體以下圖：

以上部分是一個完整的HTTP請求。

第一部分是綜合體（General），第二部分是HTTP發送的請求，第三部分是HTTP的響應。（具體細節後面再述）。

關於HTTP請求和響應的組成分別爲：

請求：請求行、請求頭、請求體；

請求行：HTTP/1.1  304  Not modified；

請求頭：Accept-Ranges：bytes；

　　　　.........

　　　　Content-Length：0；

請求體：發送的數據（當請求爲GET時，請求體爲空）

 

響應：響應行、響應頭、響應體；

 

響應與請求相似，不過多闡述。

 

HTTP/1.1請求方法總結：

 GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT；

GET請求：GET方法是默認的HTTP其你去，請求已被URI識別的資源。指定資源經服務器端解析後返回響應內容。GET請求能夠再URL上明文傳參，可是安全性不高，固然也能夠不帶參數。當用來提交表單數據時，很容易被辨認出表單數據。

POST請求：用來傳輸實體的主體。而GET方法通常用來獲取響應的主體內容。所以做爲傳輸方法，POST請求克服了GET請求在傳輸實體的一些缺點。

 

GET請求與POST請求的區別比較：

1）服務器端安全方面。GET請求用於信息獲取，它不存在傳輸實體，所以對於修改方面或者數據庫方面是安全的。而POST請求的實質是修改服務器上資源的請求，相對來講容易被利用進行一些流氓操做。

2）傳輸信息方面。GET請求將數據信息附在URL上面明文傳輸，而POST請求將傳輸的信息放在HTTP報文中，在信息安全性方面，POST請求比GET請求更好。

3）數據大小方面。GET請求傳輸的數據量限制通常爲2KB左右，緣由：GET請求經過URL傳輸數據，URL對於數據是沒有限制的，可是不一樣瀏覽器對於URL的大小是存在限制的，因此通常來講是2KB。POST                                請求對於數據是不存在限制的，惟一可能限制的緣由是服務器端處理數據的能力。

 

HEAD請求：與GET請求相似，不過不返回報文的主體信息。

　　　　　　具體做用：判斷類型；查看狀態碼；判斷資源是否修改；檢查超連接的有效性；

PUT請求：修改服務器端指定資源，通常用戶上傳文件，但因爲該方法在HTTP/1.1自身不帶驗證機制，因此沒法保證安全性，所以通常不使用。

DELETE請求：與PUT請求相反，請求修改服務器上的指定資源；

OPTIONS請求：獲取服務器端支持的HTTP請求方法；用途：獲取HTTP請求方法（黑客經常使用）；檢查服務器性能（未深刻）；

TRACE請求和CONNECT請求（暫時不瞭解過多）；

 

HTTP狀態碼：

 1XX：提示信息類，表示請求被成功接收，繼續處理；

2XX：請求成功類，表示請求被成功接收，理解，接受；

3XX：重定向類，要完成請求必須進行更進一步的處理；

4XX：客戶端錯誤類，請求有語法錯誤或請求沒法處理；

5XX：服務端錯誤類，服務器未能實現合法的請求；

 

常見狀態碼：

200：請求被成功完成，資源已返回到客戶端。

301：重定向，客戶請求的文檔在其餘地方，表示永久性轉移。

302：重定向，客戶請求的文檔在其餘地方，表示暫時性轉移。

304：自從上次請求後，請求的網頁從未修改過。即瀏覽器獲取緩存便可（詳細見前端緩存篇）

400：請求出現語法錯誤。

401：客戶試圖未經受權訪問受密碼保護的頁面。（即未受權）

403：資源不可用，禁止訪問。

404：沒法找到指定位置的資源。

405：請求方法對指定資源不適用。

500：常見的服務器端錯誤。

503：服務器暫時沒法處理請求（可能維護或過載）

 

301和302區別：

二者都表示地址的重定向。也就是當瀏覽器獲得服務器返回的這兩種狀態碼，就會進行從舊地址跳轉到一個新的地址，新的地址能夠從響應的Location的首部獲得。

區別：301表示資源被永遠地在舊地址移除，搜索引擎會進行新舊地址的交換。302表示資源暫時從舊地址遷出去，過段時間會回來，搜索引擎還會保留舊地址。

通常出現重定向的狀況：網站目錄調整；網站地址更改；網頁擴展名更改。若是沒有重定向，會返回404，致使用戶流量浪費。

儘可能少用302重定向，易發生網址劫持。

所謂網址劫持：A網站擁有簡潔友好的url，可是B網站的url很是長且混亂，若是A網站重定向到B網站，對於搜索引擎算法來講，它依舊可能將網址顯示爲A網站，便於用戶，此時的狀況就是：瀏覽器中是A網站的網址，可是頁面內容爲B網站的。此時，B網站Url就不能被抓取了，也就是發生了URL的劫持。

 

URI和URL的區別：

URI：統一資源標識符，表示網絡資源。

URL：統一資源定位符，表示網絡資源的地址，即網址。

 

RFC：徵求修正意見書，RFC是互聯網設計文檔。假若不按照RFC標準執行，可能致使沒法通訊的狀況。（暫未深刻）

HTTP：無狀態協議，對請求和響應不作持久化處理。

無狀態：協議對於事務處理沒有記憶能力。通俗點，當瀏覽器發送請求給服務器，服務器響應，當瀏覽器再次發送請求給服務器時，服務器不會知道你是上次的瀏覽器，或者說，服務器不會記住瀏覽器。

 

TCP協議和UDP協議都屬於TCP/IP協議簇。

TCP：面向鏈接，可靠的鏈接；UDP：非鏈接，儘量交付，不可靠鏈接；

 

HTTP和HTTPs區別：

HTTP:超文本傳輸協議，應用層的協議。

缺點：

一、通訊內容爲明文，未加密，內容可能被竊聽。

二、通訊雙方的身份未進行驗證，可能出現假裝身份的狀況。（例如DOS攻擊）

三、接受的報文的完整性沒法保證，中途可能被篡改。

 

鑑於HTTP的缺點，HTTPS在HTTP的基礎上增長了：

一、通訊加密； 二、證書認證； 三、完整性保護

 

SSL是如何配合HTTP進行通訊加密的：

HTTPS並不是一個新的協議，能夠說是：HTTPS = HTTP +SSL；

由圖可見，SSL協議獨立於HTTP協議，也能夠用於其餘協議的加密。如 SMTP等。

目前，百度搜索引擎對於HTTPS的抓取還不是很支持，可是谷歌是支持的。

 

HTTPS會下降通訊效率：

一、通訊速率下降，加多了一層SSL協議的通訊過程。

二、加密過程消耗資源。

三、證書開銷，須要向認證機構購買證書。