Web請求過程

B/S架構

最多見的架構方式。

優勢：

1.客戶端使用統一（此處的統一主要指實現原理統一）的瀏覽器，不須要特殊的網絡配置。

2.服務端基於統一的HTTP協議。基於此協議的服務器有不少，如Tomcat，Nginx，JBoss。這些服務器能夠直接拿來用。

請求發生的完整過程

HTTP最大的特色就是無狀態的短鏈接的通訊方式，一般狀況下一次請求就完成了一次數據交互，一般也對應一次業務邏輯。而後此次通訊就斷開了。

採用這種方式是爲了可以同時服務更多的用戶，防止因爲一個用戶獨佔鏈接而形成阻塞的現象。

下面主要介紹用戶在瀏覽器輸入網址以後發生的整個完整過程。

1.用戶輸入URL，也就是網址。如www.google.com。

2.DNS域名服務器會將其轉換成IP地址。

3.用戶端根據IP地址向服務器發起請求。

4.服務器端可能會有負載均衡設備來平均分配全部的用戶請求。在請求到達服務器後，會通過一些複雜的業務邏輯來處理用戶請求。請求的數據可能在三個地方：
分佈式緩存系統，文件系統或者數據庫中。從其中取出數據返回給瀏覽器。

5.數據返回後，瀏覽器解析數據發現還有一些靜態的資源（CSS,JS或者圖片），而後再次發起請求。這些靜態資源頗有多是在CDN上，若是在的話CDN服務器會再次處理用戶的請求。

6.最終在瀏覽器端看到完整的網頁。

以上就是大體的請求數據的過程。

無論架構如何變化，有三個原則是始終不變的：

1)互聯網上的全部資源都要用一個URL表示。

2)必須基於HTTP與服務端交互。

3)數據展現必須在瀏覽器中進行。

如何發起請求

發起請求實質上就是創建一個Socket鏈接，可是這是一個特殊的Socket鏈接。

瀏覽器在創建Socket以前，必須根據地址欄裏輸入的URL的域名DNS解析出IP地址，在根據這個IP地址和默認的80端口與遠程服務器創建Socket連接，而後瀏覽器根據這個URL組裝成一個get類型的HTTP請求頭，經過outPutStream.write 發送到目標服務器，服務器等待inputString.read返回數據，最後斷開這個鏈接

端口號：80

因此徹底能夠本身模擬瀏覽器發起一個HTTP請求。專門有個處理HTTP請求的開源工具包，叫HttpClient。

在linux中經過curl+URL能夠簡單地發起一個HTTP請求。如：curl "www.google.com"

請求的解析

HTTP請求的最重要的部分就是HTTP的頭部。

HTTP請求頭：

Accept-Charset    用於指定客戶端接受的字符集
Accept-Encoding   可接受的內容編碼
Accept-Language   天然語言 好比zh-cn
Host              指定被請求資源的Internet主機和端口號
User-Agent        客戶端將它的操做系統、瀏覽器和其餘屬性告訴服務器
Connection        當前鏈接是否保持。

 

HTTP響應頭：

Server            使用的服務器名稱
Content-type      指明發送給接受者的實體正文的媒體類型，如Content_Type:text/html;charset = GBK
Content-Encoding: 告訴瀏覽器服務端採用的壓縮編碼
Content-Language: 描述了資源所用的天然語言
Content-Length  : 指明實體正文的長度
Keep-Alive      : 保持鏈接的時間

 

常見的狀態嗎：

200 客戶端請求成功
302 臨時跳轉，跳轉的地址經過Location
400 客戶端請求語法有錯誤，不能被服務器識別
404 請求資源不存在
403 服務器收到請求，可是拒絕提供服務
500 服務端發生不可預期的錯誤

 

瀏覽器的緩存設置

在瀏覽器端Ctrl+F5能夠從新發起請求而不使用緩存數據。發出報文的請求頭裏面相關字段告訴服務器，不要緩存要最新的數據。

這兩個字段是：Pragma:no-cache Cache-Control:no-cache

public:全部內容都將被緩存，在響應頭中設置
private:內容只緩存到私有緩存中，在響應頭中設置
no-cache:全部內容都不會被緩存，在請求頭和響應頭中設置
no-store:全部內容都不會被緩存到緩存或Internet臨時文件中，在響應頭中設置
must-revalidation/proxy-revalidation:若是緩存的內容失效，請求必須發送到服務器/代理以從新驗證，在請求頭中設置
max-age=xxx:緩存的內容將在XXX秒後失效，只在HTTP1.1可用，在請求頭中設置

Cache-Control和Expires同時出現時，Cache-Control會覆蓋其餘字段

Expires:通常後面跟一個日期時間，超過這個時間設置以後，緩存內容將失效，也就是瀏覽器在發出請求以前檢查這個頁面的這個字段，看頁面是否過時了，過時了就從新向瀏覽器發起服務

Last-Modified:通常表示服務器上資源最後修改時間，根據這個修改時間能夠判斷當前請求的資源是不是最新的，若是是最新的，服務器就返回304狀態碼告知瀏覽器

Etag:服務器給每一個頁面分配一個惟一的編號，而後區分編號判斷頁面內容是不是最新的

DNS域名解析過程

1.用戶輸入URL，瀏覽器檢查自身有沒有緩存該域名的IP地址。

2.若是沒有，瀏覽器檢查操做系統緩存中是否有這個DNS解析結果。

3.若是緩存中尚未，則操做系統會把這個域名發送給LDNS（Local DNS）即本地域名服務器。

4.若是LDNS中尚未，則只能去Root Server域名服務器中請求解析了。這樣的狀況比較罕見，由於全球只有13臺左右這樣的服務器。

5.根域名服務器會返回一個本地域名服務器所查域的主域名服務器(gTLD Server)地址。gTLD是國際頂級域名服務器地址，如.com、.cn、.org，全球只有13臺

6.LDNS向gTLD發送請求。

7.gTLD接受此請求，返回一個此域名對應的Name Server域名服務器的地址。這個Name Server一般就是你註冊的域名服務器。

8.Name Server返回該域名對應的IP和TTL值，而後Local DNS Server會緩存這個對應關係，緩存時間由TTL控制。

9.解析結果返回用戶。用戶根據TTL值緩存在本地系統緩存此對應關係。

TTL是域名解析的生命週期，TTL值全稱是「生存時間（Time To Live)」，簡單的說它表示DNS記錄在DNSf服務器上的緩存時間。

清除緩存域名

Local DNS的緩存由TTL來控制，很難人工介入。可是本地機器的緩存能夠用如下命令來清除：

Windows: ipconfig /flushdns Linux: /etc/init.d/nscd restart

幾種域名的解析方式

域名解析記錄主要分爲：A 記錄、MX記錄、CNAME 記錄、NS記錄和 TXT記錄

A記錄：A 表明的是Address，用來指定域名對應的IP地址。域名能夠多對一可是不能一對多。

MX記錄：Mail Exchange,就是講某個域名下的郵件服務器指向本身的Mail Server。

CNAME記錄：別名解析。將一個域名設置一個或者多個別名。

NS記錄：爲某個域名指定DNS解析服務器。

TXT記錄：爲某個主機名或者域名設置文字說明。

CDN

工做機制

CDN即內容分發網絡。經過現有的Internet中增長一層新的網絡架構，將網站的內容發佈到最接近用戶的網絡邊緣，使用戶能夠就近取得所須要的內容，提升用戶網站的響應速度。

負載均衡

對工做任務進行平衡、分攤到多個操做單元上去，共同完成任務。

三種架構：

1.鏈路負載均衡

由DNS解析來完成負載均衡，用戶直接訪問目標服務器，而不須要通過其餘的代理服務器，一般訪問速度會更快。

缺點：一旦某臺服務器掛掉，因爲用戶本地和Local DNS都有DNS緩存，緩存沒有及時更新，則形成用戶沒法訪問這個域名。

2.集羣負載均衡

硬件負載均衡：由一臺專門的硬件設備負責轉發請求，太貴通常公司用不起，可是性能很好（一分錢一分貨啊）

軟件負載均衡：由多臺代理服務器組成。網絡延時較長。

3.操做系統負載均衡

利用操做系統級別的軟中斷或者硬件中斷來完成。

動態加速

在CDN的DNS解析過程當中，經過動態鏈路探測來尋找回源最好的一條路徑，而後經過DNS調度將全部請求調度到選定這條路徑上回源，從而加速用戶訪問的效率。

回源：有用戶訪問某一個URL的時候，若是被解析到的那個CDN節點沒有緩存響應的內容，或者是緩存已經到期，就會回源站去獲取。若是沒有人訪問，那麼CDN節點不會主動去源站拿的。