獲取資源的過程

對于普通的上網(wǎng)過程，系統(tǒng)其實是這樣做的：瀏覽器本身是一個客戶端，當(dāng)你輸入URL時，首先瀏覽器會去請求DNS服務(wù)器，通過DNS獲取相應(yīng)的域名對應(yīng)的IP，然后通過IP地址找到IP對應(yīng)的服務(wù)器后，要求建立TCP連接，等瀏覽器發(fā)送完HTTP Request(請求)包后，服務(wù)器接收到請求包之后才開始處理請求包，服務(wù)器調(diào)用自身服務(wù)，返回HTTP Response(響應(yīng))包；客戶端接收到來自服務(wù)器的響應(yīng)后開始渲染這個Response包里的主體(body)，等收到全部的內(nèi)容后斷開與該服務(wù)器之間的TCP連接。（瀏覽器和服務(wù)器交互的過程包含TCP的三次握手和四次揮手）。
如圖，用戶訪問一個Web站點的過程：

成都創(chuàng)新互聯(lián)專注于貞豐網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供貞豐營銷型網(wǎng)站建設(shè)，貞豐網(wǎng)站制作、貞豐網(wǎng)頁設(shè)計、貞豐網(wǎng)站官網(wǎng)定制、微信平臺小程序開發(fā)服務(wù)，打造貞豐網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供貞豐網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

Web服務(wù)器也被稱為HTTP服務(wù)器，它通過HTTP協(xié)議與客戶端通信。這個客戶端通常指Web瀏覽器（手機端內(nèi)部也是瀏覽器實現(xiàn)的）。

Web服務(wù)器的工作原理可以簡單歸納為:

• 客戶機通過TCP/IP協(xié)議建立到服務(wù)器的TCP連接；
• 客戶端向服務(wù)器發(fā)送HTTP協(xié)議請求包，請求服務(wù)器里的資源文檔；
• 服務(wù)器向客戶機發(fā)送HTTP協(xié)議應(yīng)答包，如果請求的資源包含有動態(tài)語言的內(nèi)容，那么服務(wù)器會調(diào)用動態(tài)語言的解釋引擎負責(zé)處理"動態(tài)內(nèi)容"，并將處理得到的數(shù)據(jù)返回給客戶端；
• 客戶機與服務(wù)器斷開。由客戶端解釋HTML文檔，在客戶端屏幕上渲染圖形結(jié)果。

注：客戶機與服務(wù)器之間的通信是非持久連接的，也就是當(dāng)服務(wù)器發(fā)送了應(yīng)答后就與客戶機斷開連接，等待下一次請求。

URL和DNS解析

URL（Uniform Resource Locator）是"統(tǒng)一資源定位符"的英文縮寫，用于描述一個網(wǎng)絡(luò)上的資源，基本格式如下：

scheme://host[:port#]/path/.../[?query-string][#anchor]
scheme         指定底層使用的協(xié)議(例如：http, https, ftp等).
host           HTTP服務(wù)器的IP地址或者域名.
port#          HTTP服務(wù)器的默認(rèn)端口是80，這種情況下端口號可以省略。如果使用了別的端口，必須指明，例如 https://amesy.me:8080/
path           訪問資源的路徑.
query-string   發(fā)送給http服務(wù)器的數(shù)據(jù).
anchor         錨.

DNS(Domain Name System)是"域名系統(tǒng)"的英文縮寫，是一種組織成域?qū)哟谓Y(jié)構(gòu)的計算機和網(wǎng)絡(luò)服務(wù)命名系統(tǒng)，被用于TCP/IP網(wǎng)絡(luò)，它的功能就是將主機名或域名轉(zhuǎn)換為實際IP地址。DNS就是這樣的一位“翻譯官”，它的基本工作原理可用下圖來表示：

更詳細的DNS解析的過程如下：

1. 在瀏覽器中輸入www.google.com這個域名，操作系統(tǒng)會先檢查自己本地的hosts文件是否有這個網(wǎng)址映射關(guān)系，如果有就先調(diào)用這個IP地址映射，完成域名解析。
2. 如果hosts里沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網(wǎng)址映射關(guān)系，如果有直接返回，完成域名解析。
3. 如果hosts與本地DNS解析器緩存都沒有相應(yīng)的網(wǎng)址映射關(guān)系，那么系統(tǒng)首先會找TCP/IP參數(shù)中設(shè)置的選DNS服務(wù)器，在此我們叫它本地DNS服務(wù)器，此服務(wù)器收到查詢時，如果要查詢的域名，包含在本地配置區(qū)域資源中，則返回解析結(jié)果給客戶機，完成域名解析，此解析具有權(quán)威性。
4. 如果待查詢的域名不由本地DNS服務(wù)器區(qū)域解析，但該服務(wù)器已緩存了此網(wǎng)址映射關(guān)系，則調(diào)用這個IP地址映射，完成域名解析，此解析不具有權(quán)威性。
5. 如果本地DNS服務(wù)器的本地區(qū)域文件與緩存解析都失效，則根據(jù)本地DNS服務(wù)器的設(shè)置（是否設(shè)置轉(zhuǎn)發(fā)器）進行查詢，如果未用轉(zhuǎn)發(fā)模式，本地DNS就把請求發(fā)至 “根DNS服務(wù)器”，“根DNS服務(wù)器”收到請求后會判斷這個域名(.com)是誰來授權(quán)管理，并會返回一個負責(zé)該頂級域名服務(wù)器的一個IP。本地DNS服務(wù)器收到IP信息后，將會聯(lián)系負責(zé).com域的這臺服務(wù)器。這臺負責(zé)".com域"的服務(wù)器收到請求后，如果自己無法解析，它就會找一個管理".com域"的下一級DNS服務(wù)器地址(google.com)給本地DNS服務(wù)器。當(dāng)本地DNS服務(wù)器收到這個地址后，就會找google.com域的服務(wù)器，重復(fù)上面的動作，進行查詢，直至找到www.google.com主機。
6. 如果用的是轉(zhuǎn)發(fā)模式，此DNS服務(wù)器就會把請求轉(zhuǎn)發(fā)至上一級DNS服務(wù)器，由上一級服務(wù)器進行解析，上一級服務(wù)器如果不能解析，或找根DNS或把轉(zhuǎn)發(fā)請求轉(zhuǎn)至上上級，以此循環(huán)。不管是本地DNS服務(wù)器用的是轉(zhuǎn)發(fā)還是根提示，最后都是把結(jié)果返回給本地DNS服務(wù)器，由此DNS服務(wù)器再返回給客戶機。

圖示，DNS解析的整個流程：

• 遞歸查詢：客戶端只發(fā)出一次請求一定要得到最終結(jié)果;(主機向本地域名服務(wù)器的查詢一般都是采用遞歸查詢.)

• 迭代查詢：服務(wù)器發(fā)出多次請求,層層請求后返回最終結(jié)果;(本地域名服務(wù)器向根域名服務(wù)器的查詢(域名服務(wù)器之間的查詢)一般都是采用迭代查詢)

最后，通過上面的步驟，我們最后獲取的是IP地址，也就是瀏覽器最后發(fā)起請求的時候是基于IP來和服務(wù)器做信息交互的。

HTTP協(xié)議詳解

HTTP協(xié)議是Web工作的核心，所以要了解清楚Web的工作方式就需要先詳細的了解清楚HTTP是怎樣工作的。

HTTP是一種讓W(xué)eb服務(wù)器與瀏覽器(客戶端)通過Internet發(fā)送與接收數(shù)據(jù)的協(xié)議，它建立在TCP協(xié)議之上，一般默認(rèn)采用TCP的80端口。它是一個請求、響應(yīng)協(xié)議，即客戶端發(fā)出一個請求，服務(wù)器響應(yīng)這個請求。在HTTP中客戶端總是通過建立一個連接與發(fā)送一個HTTP請求來發(fā)起一個事務(wù)。服務(wù)器不能主動去連接客戶端，也不能給客戶端發(fā)出一個回調(diào)連接?？蛻舳伺c服務(wù)器端都可以提前中斷一個連接。例如當(dāng)瀏覽器下載一個文件時，你可以通過點擊"停止"鍵來中斷文件的下載，關(guān)閉與服務(wù)器的HTTP連接。

HTTP協(xié)議是無狀態(tài)的，同一個客戶端的這次請求和上次請求是沒有對應(yīng)關(guān)系的，對HTTP服務(wù)器來說，它并不知道這兩個請求是否來自同一個客戶端。為了解決這個問題， Web程序引入了Cookie機制來維護連接的可持續(xù)狀態(tài)。

HTTP協(xié)議是建立在TCP協(xié)議之上的，因此TCP***一樣會影響HTTP的通訊，例如比較常見的一些***：SYN Flood是當(dāng)前最流行的DoS（拒絕服務(wù)***）與DdoS（分布式拒絕服務(wù)***）的方式之一，這是一種利用TCP協(xié)議缺陷，發(fā)送大量偽造的TCP連接請求，從而使得被***方資源耗盡（CPU滿負荷或內(nèi)存不足）的***方式。

HTTP請求包（瀏覽器信息）

我們先來看看Request包的結(jié)構(gòu)。Request包分為3部分，第一部分叫Request line（請求行）, 第二部分叫Request header（請求頭）,第三部分是body（主體）。header和body之間有個空行，請求包的例子所示:

GET /domains/example/ HTTP/1.1      //請求行: 請求方法 請求URI HTTP協(xié)議/協(xié)議版本
Host：www.iana.org               //服務(wù)端的主機名
User-Agent：Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4          //瀏覽器信息
Accept：text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  //客戶端能接收的mine
Accept-Encoding：gzip,deflate,sdch       //是否支持流壓縮
Accept-Charset：UTF-8,*;q=0.5        //客戶端字符編碼集
//空行,用于分割請求頭和消息體
//消息體,請求資源參數(shù),例如POST傳遞的參數(shù)

HTTP協(xié)議定義了很多與服務(wù)器交互的請求方法，最基本的有4種，分別是GET,POST,PUT,DELETE。一個URL地址用于描述一個網(wǎng)絡(luò)上的資源，而HTTP中的GET, POST, PUT, DELETE就對應(yīng)著對這個資源的查，增，改，刪4個操作。最常見的就是GET和POST。GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息。

通過fiddler抓包可以看到如下請求信息:

GET信息：

POST信息：

GET和POST的區(qū)別

1. 從上圖抓取到的信息可以看到GET請求消息體為空，POST請求帶有消息體。
2. GET提交的數(shù)據(jù)會放在URL之后，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連，如EditPosts.aspx?name=test1&id=123456。POST方法是把提交的數(shù)據(jù)放在HTTP包的body中。
3. GET提交的數(shù)據(jù)大小有限制（因為瀏覽器對URL的長度有限制），而POST方法提交的數(shù)據(jù)沒有限制。
4. GET方式提交數(shù)據(jù)，會帶來安全問題，比如一個登錄頁面，通過GET方式提交數(shù)據(jù)時，用戶名和密碼將出現(xiàn)在URL上，如果頁面可以被緩存或者其他人可以訪問這臺機器，就可以從歷史記錄獲得該用戶的賬號和密碼。

HTTP響應(yīng)包（服務(wù)器信息）

HTTP的Response包的結(jié)構(gòu)如下：

HTTP/1.1 200 OK                     //狀態(tài)行
Server: nginx/1.10.1                //服務(wù)器使用的WEB軟件名及版本
Date:Date: Tue, 30 Oct 2012 04:14:25 GMT        //發(fā)送時間
Content-Type: text/html             //服務(wù)器發(fā)送信息的類型
Transfer-Encoding: chunked          //表示發(fā)送HTTP包是分段發(fā)的
Connection: keep-alive              //保持連接狀態(tài)
Content-Length: 90                  //主體內(nèi)容長度
//空行 用來分割消息頭和主體

Response包中的第一行叫做狀態(tài)行，由HTTP協(xié)議版本號, 狀態(tài)碼, 狀態(tài)消息三部分組成。

狀態(tài)碼用來告訴HTTP客戶端,HTTP服務(wù)器是否產(chǎn)生了預(yù)期的Response。HTTP/1.1協(xié)議中定義了5類狀態(tài)碼，狀態(tài)碼由三位數(shù)字組成，第一個數(shù)字定義了響應(yīng)的類別

• 1XX 提示信息 - 表示請求已被成功接收，繼續(xù)處理.
• 2XX 成功 - 表示請求已被成功接收，理解，接受.
• 3XX 重定向 - 要完成請求必須進行更進一步的處理.
• 4XX 客戶端錯誤 - 請求有語法錯誤或請求無法實現(xiàn).
• 5XX 服務(wù)器端錯誤 - 服務(wù)器未能實現(xiàn)合法的請求.

下面這個圖展示了一次詳細的資源訪問，可以看到資源狀態(tài)返回碼304表示跳轉(zhuǎn)。response header里面展示了詳細的訪問信息。

HTTP協(xié)議是無狀態(tài)的和Connection: keep-alive的區(qū)別

無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。從另一方面講，打開一個服務(wù)器上的網(wǎng)頁和你之前打開這個服務(wù)器上的網(wǎng)頁之間沒有任何聯(lián)系。

HTTP是一個無狀態(tài)的面向連接的協(xié)議，無狀態(tài)不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協(xié)議（面對無連接）。

從HTTP/1.1起，默認(rèn)都開啟了Keep-Alive保持連接特性，簡單地說，當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁，會繼續(xù)使用這一條已經(jīng)建立的TCP連接。

Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同服務(wù)器軟件（如Apache）中設(shè)置這個時間。

請求實例

上面這張圖我們可以了解到整個的通訊過程，可以看到一個URL請求, 但是左邊欄里面有很多的資源被請求(這些都是靜態(tài)文件，go對于靜態(tài)文件有專門的處理方式)。

這個就是瀏覽器的一個功能。第一次請求url，服務(wù)器端返回的是html頁面，然后瀏覽器開始渲染HTML：當(dāng)解析到HTML DOM里面的圖片鏈接、css腳本和js腳本的鏈接，瀏覽器就會自動發(fā)起一個請求靜態(tài)資源的HTTP請求，獲取相應(yīng)的靜態(tài)資源，然后瀏覽器就會渲染出來，最終將所有資源整合、渲染，完整展現(xiàn)在我們面前的屏幕上。

網(wǎng)頁優(yōu)化方面有一項措施是減少HTTP請求次數(shù)，就是把盡量多的css和js資源合并在一起，目的是盡量減少網(wǎng)頁請求靜態(tài)資源的次數(shù)，提高網(wǎng)頁加載速度，同時減緩服務(wù)器的壓力。

參考文檔：https://github.com/astaxie/build-web-application-with-golang

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。


文章標(biāo)題：Web工作方式-創(chuàng)新互聯(lián)
標(biāo)題URL：http://weahome.cn/article/dchjec.html