摘要
本文轉(zhuǎn)自《go web編程》一書辟狈，覺得說的比較好，特轉(zhuǎn)過來收藏夏跷。
原文地址：web的工作方式哼转，http協(xié)議簡介 - Carlton.C.X.Z的個人頁面 - 開源中國社區(qū)
我們平時瀏覽網(wǎng)頁的時候,會打開瀏覽器，輸入網(wǎng)址后按下回車鍵槽华，然后就會顯示出你想要瀏覽的內(nèi)容壹蔓。在這個看似簡單的用戶行為背后，到底隱藏了些什么呢猫态？
對于普通的上網(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連接柳譬。
圖3.1 用戶訪問一個Web站點的過程
一個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)語言的解釋引擎負(fù)責(zé)處理“動態(tài)內(nèi)容”，并將處理得到的數(shù)據(jù)返回給客戶端
客戶機與服務(wù)器斷開酱虎。由客戶端解釋HTML文檔雨膨，在客戶端屏幕上渲染圖形結(jié)果
一個簡單的HTTP事務(wù)就是這樣實現(xiàn)的，看起來很復(fù)雜读串，原理其實是挺簡單的聊记。需要注意的是客戶機與服務(wù)器之間的通信是非持久連接的，也就是當(dāng)服務(wù)器發(fā)送了應(yīng)答后就與客戶機斷開連接恢暖，等待下一次請求排监。
我們?yōu)g覽網(wǎng)頁都是通過URL訪問的，那么URL到底是怎么樣的呢杰捂？
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，這種情況下端口號可以省略嫁佳。如果使用了別的端口挨队，必須指明，例如 http://www.cnblogs.com: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就是這樣的一位“翻譯官”情臭，它的基本工作原理可用下圖來表示。
圖3.2 DNS工作原理
更詳細(xì)的DNS解析的過程如下赌蔑，這個過程有助于我們理解DNS的工作模式
在瀏覽器中輸入www.qq.com域名俯在，操作系統(tǒng)會先檢查自己本地的hosts文件是否有這個網(wǎng)址映射關(guān)系，如果有娃惯，就先調(diào)用這個IP地址映射跷乐，完成域名解析。
如果hosts里沒有這個域名的映射趾浅，則查找本地DNS解析器緩存愕提，是否有這個網(wǎng)址映射關(guān)系馒稍，如果有，直接返回浅侨，完成域名解析纽谒。
如果hosts與本地DNS解析器緩存都沒有相應(yīng)的網(wǎng)址映射關(guān)系，首先會找TCP/IP參數(shù)中設(shè)置的首選DNS服務(wù)器如输，在此我們叫它本地DNS服務(wù)器鼓黔，此服務(wù)器收到查詢時，如果要查詢的域名不见，包含在本地配置區(qū)域資源中澳化，則返回解析結(jié)果給客戶機，完成域名解析稳吮，此解析具有權(quán)威性缎谷。
如果要查詢的域名，不由本地DNS服務(wù)器區(qū)域解析灶似，但該服務(wù)器已緩存了此網(wǎng)址映射關(guān)系列林，則調(diào)用這個IP地址映射，完成域名解析酪惭，此解析不具有權(quán)威性席纽。
如果本地DNS服務(wù)器本地區(qū)域文件與緩存解析都失效，則根據(jù)本地DNS服務(wù)器的設(shè)置（是否設(shè)置轉(zhuǎn)發(fā)器）進行查詢撞蚕，如果未用轉(zhuǎn)發(fā)模式润梯，本地DNS就把請求發(fā)至 “根DNS服務(wù)器”，“根DNS服務(wù)器”收到請求后會判斷這個域名(.com)是誰來授權(quán)管理甥厦，并會返回一個負(fù)責(zé)該頂級域名服務(wù)器的一個IP纺铭。本地DNS服務(wù)器收到IP信息后，將會聯(lián)系負(fù)責(zé).com域的這臺服務(wù)器刀疙。這臺負(fù)責(zé).com域的服務(wù)器收到請求后舶赔，如果自己無法解析谦秧，它就會找一個管理.com域的下一級DNS服務(wù)器地址(qq.com)給本地DNS服務(wù)器锥累。當(dāng)本地DNS服務(wù)器收到這個地址后桶略，就會找qq.com域服務(wù)器际歼，重復(fù)上面的動作鹅心，進行查詢旭愧，直至找到www.qq.com主機。
如果用的是轉(zhuǎn)發(fā)模式用押，此DNS服務(wù)器就會把請求轉(zhuǎn)發(fā)至上一級DNS服務(wù)器靶剑，由上一級服務(wù)器進行解析桩引，上一級服務(wù)器如果不能解析，或找根DNS或把轉(zhuǎn)請求轉(zhuǎn)至上上級血崭，以此循環(huán)夹纫。不管是本地DNS服務(wù)器用是是轉(zhuǎn)發(fā)舰讹，還是根提示，最后都是把結(jié)果返回給本地DNS服務(wù)器锄开，由此DNS服務(wù)器再返回給客戶機院刁。
圖3.3 DNS解析的整個流程
所謂?遞歸查詢過程?就是 “查詢的遞交者” 更替, 而?迭代查詢過程?則是 “查詢的遞交者”不變。
舉個例子來說享潜，你想知道某個一起上法律課的女孩的電話剑按，并且你偷偷拍了她的照片澜术，回到寢室告訴一個很仗義的哥們兒，這個哥們兒二話沒說鸟废，拍著胸脯告訴你，甭急盒延，我替你查(此處完成了一次遞歸查詢缩擂，即，問詢者的角色更替)胯盯。然后他拿著照片問了學(xué)院大四學(xué)長博脑，學(xué)長告訴他票罐，這姑娘是xx系的君账；然后這哥們兒馬不停蹄又問了xx系的辦公室主任助理同學(xué)沈善，助理同學(xué)說是xx系yy班的闻牡，然后很仗義的哥們兒去xx系yy班的班長那里取到了該女孩兒電話净赴。(此處完成若干次迭代查詢，即罩润，問詢者角色不變玖翅，但反復(fù)更替問詢對象)最后，他把號碼交到了你手里。完成整個查詢過程金度。
通過上面的步驟应媚，我們最后獲取的是IP地址，也就是瀏覽器最后發(fā)起請求的時候是基于IP來和服務(wù)器做信息交互的猜极。
HTTP協(xié)議是Web工作的核心中姜，所以要了解清楚Web的工作方式就需要詳細(xì)的了解清楚HTTP是怎么樣工作的。
HTTP是一種讓W(xué)eb服務(wù)器與瀏覽器(客戶端)通過Internet發(fā)送與接收數(shù)據(jù)的協(xié)議,它建立在TCP協(xié)議之上跟伏，一般采用TCP的80端口丢胚。它是一個請求、響應(yīng)協(xié)議--客戶端發(fā)出一個請求受扳，服務(wù)器響應(yīng)這個請求携龟。在HTTP中，客戶端總是通過建立一個連接與發(fā)送一個HTTP請求來發(fā)起一個事務(wù)勘高。服務(wù)器不能主動去與客戶端聯(lián)系峡蟋，也不能給客戶端發(fā)出一個回調(diào)連接∠嗦客戶端與服務(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滿負(fù)荷或內(nèi)存不足）的攻擊方式重父。
我們先來看看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//客戶端能接收的mineAccept-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抓包可以看到如下請求信息:
圖3.4 fiddler抓取的GET信息
圖3.5 fiddler抓取的POST信息
我們看看GET和POST的區(qū)別:
我們可以看到GET請求消息體為空，POST請求帶有消息體嘱根。
GET提交的數(shù)據(jù)會放在URL之后髓废，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連该抒，如EditPosts.aspx?name=test1&id=123456慌洪。POST方法是把提交的數(shù)據(jù)放在HTTP包的body中。
GET提交的數(shù)據(jù)大小有限制（因為瀏覽器對URL的長度有限制）凑保，而POST方法提交的數(shù)據(jù)沒有限制冈爹。
GET方式提交數(shù)據(jù)，會帶來安全問題欧引，比如一個登錄頁面频伤，通過GET方式提交數(shù)據(jù)時，用戶名和密碼將出現(xiàn)在URL上芝此，如果頁面可以被緩存或者其他人可以訪問這臺機器憋肖，就可以從歷史記錄獲得該用戶的賬號和密碼。
我們再來看看HTTP的response包婚苹，他的結(jié)構(gòu)如下：
HTTP/1.1 200 OK? ? ? ? ? ? ? ? ? ? //狀態(tài)行Server:nginx/1.0.8? ? ? ? ? ? ? ? //服務(wù)器使用的WEB軟件名及版本Date:Date:Tue,30Oct201204:14:25GMT//發(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)合法的請求
我們看下面這個圖展示了詳細(xì)的返回信息，左邊可以看到有很多的資源返回碼院仿，200是常用的秸抚，表示正常信息速和，302表示跳轉(zhuǎn)。response header里面展示了詳細(xì)的信息剥汤。
圖3.6 訪問一次網(wǎng)站的全部請求信息
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è)置這個時間。
圖3.7 一次請求的request和response
上面這張圖我們可以了解到整個的通訊過程峭范，同時細(xì)心的讀者是否注意到了一點财松，一個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ù)器的壓力鲤妥。
