這段時間陸陸續(xù)續(xù)把《圖解HTTP》這本書看完了怎顾。平時開發(fā)雖然跟HTTP打的交道比較多惠呼，但是還是缺乏對HTTP有個系統(tǒng)性的認識恳守。本書主要從Web網(wǎng)絡基礎、什么是HTTP砌们、HTTP的構造杆麸、HTTP的擴展以及安全問題等幾個維度做了下介紹。本書的內容描述比較淺顯易懂浪感，結合文中舉得例子昔头、圖例能使讀者有個更深的理解。以下是根據(jù)個人理解對文中覺得比較關鍵的地方做了些摘要影兽，整本書共241頁揭斧，建議有興趣的朋友可以自己閱讀下本書。

第一章 了解Web及網(wǎng)絡基礎

使用HTTP協(xié)議訪問WEB

客戶端：通過指定的訪問地址獲扔俊（或上傳）服務器
服務器：使用HTTP與客戶端通信

網(wǎng)絡基礎TCP/IP

概念：通常使用的網(wǎng)絡是在TCP/IP協(xié)議族的基礎上運作的未蝌。而HTTP屬于它內部的一個子集。TCP/IP是互聯(lián)網(wǎng)相關的各類協(xié)議族的總稱茧妒。

TCP/IP的分層管理

應用層：決定了向用戶提供應用服務時通信的活動萧吠。（FTP、DNS桐筏、HTTP）
傳輸層：對上層應用層纸型，提供處于網(wǎng)絡連接中的兩臺計算機之間的數(shù)據(jù)傳輸。（TCP（傳輸控制協(xié)議）梅忌、UDP（用戶數(shù)據(jù)報協(xié)議））
網(wǎng)絡層：處理在網(wǎng)絡上流動的數(shù)據(jù)包狰腌。數(shù)據(jù)包是網(wǎng)絡傳輸?shù)淖钚?shù)據(jù)單位。該層規(guī)定了通過怎樣的路徑到達對方計算機牧氮，并把數(shù)據(jù)傳送給對方琼腔。
數(shù)據(jù)鏈路層：用來處理連接網(wǎng)絡的硬件部分。（操作系統(tǒng)踱葛、硬件的設備驅動丹莲、光纖等物理可見部分。）

TCP/IP通信傳輸流

發(fā)送端在層與層之間傳輸數(shù)據(jù)時尸诽，沒經(jīng)過一層時必定會被打上一個該層所屬的首部信息甥材。反之，接收端在層與層傳輸數(shù)據(jù)時性含，每經(jīng)過一層時會把對應的首部消去洲赵。這種把數(shù)據(jù)信息包裝起來的做法稱為封裝。

TCP/IP通信傳流

與HTTP關系密切的協(xié)議：IP商蕴、TCP和DNS

負責傳輸?shù)腎P協(xié)議-位于網(wǎng)絡層
IP協(xié)議的作用是把各種數(shù)據(jù)包傳送給對方叠萍。而要保證確實傳送到對方那里，則需要滿足各類條件究恤。其中兩個重要的條件是IP地址和MAC地址俭令。(使用ARP協(xié)議憑借MAC地址進行通信。)
確辈克蓿可靠性的TCP協(xié)議-位于傳輸層
采用三次握手策略抄腔，首先發(fā)送一個帶SYN標志的數(shù)據(jù)包給對方，接收端收到后理张，回傳一個帶有SYN/ACK標志的數(shù)據(jù)包以示傳達確認信息赫蛇，最后發(fā)送端再回傳一個帶ACK標志的數(shù)據(jù)包，代表握手結束雾叭。
負責域名解析的DNS服務-位于應用層
通過域名查找IP

第二章 簡單的HTTP協(xié)議

重要概念

• HTTP協(xié)議規(guī)定悟耘，請求從客戶端發(fā)出，最后服務器端響應該請求并返回织狐。
• 請求報文是由請求方法暂幼、請求URI筏勒、協(xié)議版本、可選的請求首部字段和內容實體構成的旺嬉。
• 響應報文是由協(xié)議版本管行、狀態(tài)碼、狀態(tài)碼的原因短語邪媳、響應首部字段捐顷、主體構成的。
• HTTP協(xié)議對于發(fā)送過的請求或響應都不做持久化處理雨效。

告知服務器意圖的HTTP方法

持久連接節(jié)省通信量

持久連接
管線化：從前發(fā)送請求后需等待并接收到響應才能發(fā)送下一個請求闰围。管線化技術出現(xiàn)后，不用等待響應亦可直接發(fā)送下一個請求既峡。

使用COOKIE的狀態(tài)管理

• COOKIE技術通過再請求和響應報文中寫入COOKIE信息來控制客戶端的狀態(tài)羡榴。COOKIE會根據(jù)從服務器端發(fā)送的響應報文內的一個叫做SET-COOKIE的首部字段信息，通知客戶端保存COOKIE运敢。當下次客戶端再往該服務器發(fā)送請求時校仑，客戶端會自動在請求報文中加入COOKIE值后發(fā)送出去。
• 服務器端發(fā)現(xiàn)客戶端發(fā)送過來的COOKIE后传惠，會去檢查究竟是從哪一個客戶端發(fā)送來的連接請求迄沫，然后對比服務器上的記錄，最后得到之前的狀態(tài)信息卦方。

第三章 HTTP報文內的HTTP信息

請求報文及響應報文的結構

請求報文羊瘩、響應報文示例

請求行：包含用于請求的方法，請求URI和HTTP版本
狀態(tài)行：包含表明響應結果的狀態(tài)碼，原因短語和HTTP版本
首部字段：包含表示請求和響應的各種條件和屬性的各類首部尘吗。（通用首部逝她、請求首部、響應首部和實體首部）

編碼提升傳輸速率

報文主體和實體主體的差異

報文：是HTTP通信中的基本單位睬捶，由8位字節(jié)流組成汽绢，通過HTTP通信傳輸。
實體：作為請求或響應的有效載荷數(shù)據(jù)被傳輸侧戴，其內容由實體首部和實體主體組成。

壓縮傳輸?shù)膬热菥幋a

指明應用在實體內容上的編碼格式跌宛，并保持實體信息原樣壓縮酗宋。內容編碼后的實體由客戶端接收并負責解碼。

分割發(fā)送的分塊傳輸編碼

• 分塊傳輸編碼會將實體主體分成多個部分疆拘，每一塊都會用十六進制來標記塊的大小蜕猫，而實體主體的最后一塊會用”0(CR+LF)“來標記。
• 使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼哎迄，恢復到編碼前的實體主體回右。

發(fā)送多種數(shù)據(jù)的多部分對象集合

發(fā)送的報文主體內可以含有多類型實體，通常是在圖片或文本文件等上傳時使用漱挚。
對象如下：
multipart/form-data：在WEB表單文件上傳時使用
multipart/byteranges：狀態(tài)碼206響應報文包含了多個范圍的內容時使用

獲取部分內容的范圍請求

用首部字段Range來指定資源的byte范圍

內容協(xié)商返回最合適的內容

概念：客戶端和服務端就響應的資源內容進行交涉翔烁，然后提供給客戶端最為合適的資源。內容協(xié)商會以響應資源的語言旨涝、字符集蹬屹、編碼方式等作為判斷的基準。
類型：
服務器驅動協(xié)商：以請求的首部字段為參考白华，在服務器端自動處理慨默。
客戶端驅動協(xié)商：用戶從瀏覽器現(xiàn)實的可選項列表中手動選擇。還可以利用javascript腳本在web頁面上自動進行上述選擇弧腥。比如按os的類型或瀏覽器類型厦取，自動切換pc版頁面或移動版頁面。
透明協(xié)商：兩者的結合體管搪，是有服務端和客戶端各自進行內容協(xié)商的一種方法虾攻。

第四章 返回結果的HTTP狀態(tài)碼

狀態(tài)碼告知從服務器返回的請求結果

第五章 與HTTP協(xié)作的web服務器

用單臺虛擬主機實現(xiàn)多個域名

• 即只有一臺物理服務器，使用虛擬主機的功能更鲁，則可以假想已具有多臺服務器台谢。
• 必須在host首部內完整指定主機名或域名的URI。

通信數(shù)據(jù)轉發(fā)程序：代理岁经、網(wǎng)關朋沮、隧道

代理

概念：一種有轉發(fā)功能的應用程序，接受客戶端發(fā)送的請求并發(fā)送給服務器，同時也接收服務器返回的響應并轉發(fā)給客戶端樊拓。在http通信過程中纠亚，可及聯(lián)多臺代理服務器，轉發(fā)時附加via首部字段以標記出經(jīng)過的主機信息筋夏。
作用：利用緩存技術減少網(wǎng)絡帶寬的流量蒂胞，組織內部針對特定網(wǎng)絡的訪問控制，以獲取訪問日志為主要目的条篷。
類型：
緩存代理：代理轉發(fā)響應時骗随，預先將資源的副本保存在代理服務器上。當代理再次接收到對相同資源的請求時赴叹，將之前緩存的資源作為響應返回鸿染。
透明代理：轉發(fā)或請求響應時，不對報文做任何加工的代理類型被稱為透明代理乞巧。

網(wǎng)關

概念：與代理類似涨椒，而網(wǎng)關能使通信線路上的服務器提供非http協(xié)議服務。利用網(wǎng)關能提高通信的安全性绽媒，因為可以在客戶端與網(wǎng)關之間的通信線路上加密以確保連接的安全蚕冬。

隧道

概念：可按要求建立起一條與其他服務器的通信線路，屆時使用ssl等加密手段進行通信是辕，隧道的目的時確倍谌龋客戶端與服務器進行安全的通信。

保存資源的緩存

概念：當代理轉發(fā)從服務器返回的響應時获三，代理服務器將會保存一份資源的副本赢乓。避免多次從源服務器轉發(fā)資源。
緩存的有效期限：若判斷失效石窑，會重新跟源服務器獲取最新資源
客戶端緩存：如瀏覽器

第六章 HTTP首部

6.1 HTTP報文首部

HTTP請求報文

• 首部內容為客戶端和服務器端分別處理請求和響應提供所需的信息牌芋。
• 報文首部由請求行（方法、URI松逊、HTTP版本）躺屁、HTTP首部字段（請求首部字段、通用首部字段经宏、實體首部字段）

HTTP響應報文

• 在響應中犀暑，HTTP報文由HTTP版本、狀態(tài)碼烁兰、HTTP首部字段3部分組成耐亏。
• 報文首部由狀態(tài)行（HTTP版本、狀態(tài)碼）沪斟、HTTP首部字段（響應首部字段广辰、通用首部字段、實體首部字段）

6.2 HTTP首部字段

HTTP首部字段傳遞重要信息：使用首部字段是為了給瀏覽器和服務器提供報文主題大小、所使用的語言择吊、認證信息內容李根。
HTTP首部字段結構：結構：【首部字段名:字段值，字段值】

6.3 4種HTTP首部字段類型

通用首部字段：請求報文和響應報文兩方都會使用的首部几睛。
請求首部字段：從客戶端向服務器端發(fā)送請求報文時使用的首部房轿。補充了請求的附加內容、客戶端信息所森、響應內容優(yōu)先級等信息囱持。
響應首部字段：從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容焕济，也會要求客戶端附加額外內容纷妆。
實體首部字段：針對請求、響應報文的實體部分使用的首部吼蚁。補充了資源內容更新時間等與實體有關信息。

6.4 HTTP首部類型

End-to-Header首部

• 端到端首部分在此類中的首部會轉發(fā)給請求/響應對應的最終接受目標问欠，且必須保存在由緩存生成的響應匯總肝匆，另外規(guī)定它必須被轉發(fā)。

Hop-by-Hop首部

• 逐跳首部分在此類別中的首部只對單次轉發(fā)有效顺献，會因通過緩存或代理而不再轉發(fā)旗国。需提供Connection首部字段。
• 除了以下首部字段之外注整，其他所有字段都屬于端到端首部：Connection能曾、Keep-Alive、Proxy-Authenticate肿轨、Proxy-Authorization寿冕、Trailer、TE椒袍、Transfer-Encoding驼唱、Upgrade

6.5 HTTP/1.1通用首部字段

Cache-Control

作用：通過制定指令，操作緩存的工作機制驹暑。

Cache-Control指令

Pragma

Connection

作用：控制不在轉發(fā)給代理的首部字段；管理持久連接（HTTP/1.1版本的默認連接都是持久連接最易，指定Connection首部字段的值為Close客戶斷開連接）怒坯；

Trailer

事先說明在報文主體后記錄了哪些首部字段。（不明覺厲藻懒？剔猿？）

Transfer-Encoding

規(guī)定了傳輸報文主體時采用的編碼方式

Upgrade

用于檢測HTTP協(xié)議及其他協(xié)議是否可使用更高的版本進行通信，其參數(shù)值可以用來制定一個完全不同的通信協(xié)議嬉荆。需要額外指定Connection:Upgrade
例子：
Upgrade:TLS/1.0, HTTP/1.1
Connection:Upgrade

Via

追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑艳馒。

Warning

通常會告知用戶一些與緩存相關的問題的警告。

6.6 請求首部字段

概念：是從客戶端往服務器端發(fā)送請求報文中所使用的字段员寇，用于補充請求的附加信息弄慰、客戶端信息、對響應內容相關的優(yōu)先級等內容蝶锋。

Accept

可通知服務器陆爽，用戶代理能夠處理的媒體類型及媒體類型的相對優(yōu)先級“饴疲可使用type/subtype這種形式慌闭，一次指定多種媒體類型别威。使用q=來額外標識權重值，范圍是0~1驴剔，默認為1省古。

類型

• 文本文件：text/html, text/plain,text/css...
• 圖片文件：image/jpeg,image/gif,image/png
• 視頻文件：video/mpeg,video/quicktime
• 應用程序使用的二進制文件：application/octet-stream,application/zip

Accept-Charset：用來告知服務器用戶代理支持的內容編碼及內容編碼的優(yōu)先級順序，可一次性指定多種內容編碼丧失。使用q=來額外標識權重值豺妓，范圍是0~1，默認為1布讹×帐茫可使用*號作為通配符，指定任意的編碼格式描验。
例子
gzip
identity
compress
deflate

Accept-Language：用來告知服務器用戶代理能夠處理的自然語言集（中文或英文等）白嘁，使用q=來額外標識權重值，范圍是0~1膘流，默認為1絮缅。

Authorization：用來告知服務器，用戶代理的認證信息呼股。

Expect：期望服務器作出某種特定行為耕魄，如發(fā)現(xiàn)錯誤時，返回417卖怜。

From：告知服務器使用用戶代理的用戶的電子郵件地址屎开。

Host：告知服務器阐枣，請求的資源所處的互聯(lián)網(wǎng)主機名和端口號马靠。必須被包含在請求內的首部字段。

If-Match：附加條件請求蔼两，只有判斷指定條件為真時甩鳄，才會執(zhí)行請求。服務器會對比If-Match字段值和資源的ETag值额划，僅當兩者一致時妙啃，才會執(zhí)行請求。反之則返回412 Precondition Failed的響應俊戳。

If-Modified-Since：判斷指定時間內服務器資源是否有更新揖赴，如有則服務器接受請求，如無則返回304Not Modified的響應抑胎。

If-None-Match：指定If-None-Match字段值的實體標記ETag與請求資源的ETag不一致時燥滑，它就告知服務器處理該請求。

If-Range：告知服務器返回范圍內的資源阿逃，如未指定則返回全體資源

If-Unmodified-Since：告知服務器指定的請求資源只有在字段值內指定的日期時間之后铭拧，未發(fā)生更新的情況下赃蛛，才能處理請求。如果再指定日期時間后發(fā)生了更新搀菩，則以狀態(tài)碼412 Precondition Failed作為響應返回呕臂。

Max-Forwards：服務器在往下一個服務器轉發(fā)請求之前，Max-Forwards的值減1后重新賦值肪跋，當值為0時歧蒋，則不再進行轉發(fā)，而是直接返回響應澎嚣∈枘颍可以靈活使用它針對問題產(chǎn)生的原因展開調查，確定哪臺服務器為重點傳輸路徑易桃。

Proxy-Authorization：告知服務器認證所需要的信息褥琐，發(fā)生在客戶端與代理之間。

Range：只需獲取部分資源的范圍請求晤郑，如從第5001字節(jié)至第10000字節(jié)的資源敌呈。

Referer：告知服務器請求的原始資源的URI

TE：告知服務器客戶端能夠處理響應的傳輸編碼方式及相對優(yōu)先級。

User-Agent：用于傳達瀏覽器和用戶代理名稱等信息傳達給服務器造寝。

6.7 響應首部字段

概念：服務器端向客戶端返回響應報文中所使用的字段磕洪，用于補充響應的附加信息逐虚、服務器信息抗悍，以及對客戶端的附加要求等

Accept-Ranges：告知客戶端服務器是否能處理范圍請求渔肩，以指定獲取服務器端某個部分的資源定踱∴途可指定的字段值有兩種痪欲，可處理范圍請求時指定其為bytes庸疾，反之則指定其為none吸申。

Age：告知客戶端锦聊，源服務器在多久前創(chuàng)建了響應歹嘹。字段值的單位為秒。若創(chuàng)建該響應的服務器是緩存服務器孔庭，Age值是指緩存后的響應再次發(fā)起認證到認證完成的時間值尺上。代理創(chuàng)建響應時必須加上首部字段Age。

ETag：告知客戶端實體標識圆到，它是一種可將資源以字符串形式做唯一標識的方式怎抛，服務器會為每份資源分配對應的ETag。

• 強ETag值：不論實體發(fā)生多么細微的變化都會改變其值芽淡。
• 弱ETag值：只用于提示資源是否相同马绝，只有資源發(fā)生了根本改變，產(chǎn)生差異時才會改變ETag值吐绵，這時會在字段最開始處附加W/迹淌。

Location：可將響應接收方引導至某個與請求URI位置不同的資源河绽。配合3xx: Redirection的響應，提供重定向的URI唉窃。

Proxy-Authenticate：把由代理服務器所要求的認證信息發(fā)送給客戶端耙饰。

Retry-After：告知客戶端應該在多久之后再次發(fā)送請求，配合503 Service Unavailable或3xx Redirect響應一起使用纹份。

Server：告知客戶端當前服務器上安裝的HTTP服務器應用程序的信息苟跪。

Vary：當代理服務器接收到帶有Vary首部字段指定獲取資源的請求時，如果使用的Accept-Language字段的值相同蔓涧，那么久直接從緩存時返回響應件已。反之則需要先從源服務器端獲取資源后才能作為響應返回。

WWW-Authenticate：告知客戶端適用于訪問請求URI所指定資源的認證方案（Basic or Digest）和帶參數(shù)提示的質詢元暴。

6.8 實體首部字段

概念：包含在請求報文和響應報文中的實體部分所使用的首部篷扩，用于補充內容的更新時間等與實體相關的信息。

Allow：通知客戶端能夠支持Request-URI指定資源的所有HTTP方法茉盏。當服務器接收到不支持HTTP的方法時鉴未，會以狀態(tài)碼405 Method Not Allowed作為響應返回。還會把所有能支持的HTTP方法寫入首部字段Allow后返回鸠姨。

Content-Encoding：告知服務器對實體的主題部分選用的內容編碼方式（在不丟失實體信息的前提下所進行的壓縮）铜秆。有gzip compress deflate identity

Content-Language：告知客戶端實體主體使用的自然語言。

Content-Length：表明實體主體部分的大小讶迁。

Content-Location：給出與報文主體部分相對應的URI连茧。

Content-MD5：是一串MD5算法生成的值，其目的在于檢查報文主體在傳輸過程中是否把持完整巍糯，以及去人傳輸?shù)轿弧?/p>

Conntent-Range：告知客戶端作為響應返回的實體的那個部分符合范圍請求啸驯。字段值一字節(jié)為單位，表示當前發(fā)送部分及整個個實體大小鳞贷。

Content-Type：說明了實體主體內對象的媒體類型坯汤。用type/subtype形式賦值虐唠。

Expires：將資源失效的日期告知客戶端搀愧，在字段值指定的時間之前，響應的副本會一直被保存在緩存服務器疆偿，超過指定的時間后咱筛，緩存服務器在請求發(fā)送過來時，會轉向源服務器請求資源杆故。

Last-Modified：指明資源最終修改的時間迅箩。

6.9 為Cookie服務的首部字段

作用：WEB網(wǎng)站為了管理用戶的狀態(tài)回通過WEB瀏覽器，把一些數(shù)據(jù)臨時寫入用戶的計算機內处铛，接著當用戶訪問該WEB網(wǎng)站時饲趋，可通過通信方式取回之前發(fā)放的COOKIE拐揭。調用COOKIE時，可校驗COOKIE的有效期奕塑，以及發(fā)送方的域堂污、路徑、協(xié)議等信息龄砰，所以正規(guī)發(fā)布的COOKIE內的數(shù)據(jù)不會因來自其他WEB站點和攻擊者的攻擊而泄露盟猖。

Set-Cookie

概念：當服務器準備開始管理客戶端的狀態(tài)時，會事先告知各種信息换棚。
屬性

• expires：指定瀏覽器可發(fā)送COOKIE的有效期式镐，當省略該屬性時，有效期僅限于維持瀏覽器會話時間段內固蚤，通常限于瀏覽器應用程序被關閉之前娘汞。
• path：將服務器上的文件目錄作為COOKIE的適用對象。
• domain：作為COOKIE適用對象的域名夕玩，不指定該屬性顯得更安全价说。
• secure：限制web頁面僅在HTTPS安全連接時，才可以發(fā)送cookie风秤。當省略該屬性時鳖目，不論HTTP還是HTTPS都會對COOKIE進行回收。
• HttpOnly：使javaScript腳本無法獲得Cookie缤弦，其主要目的為防止跨站腳本攻擊對Cookie的信息竊取领迈。

Cookie：告知服務器，當客戶端想獲得HTTP狀態(tài)管理支持時碍沐，就會在請求中包含從服務器接收到的COOKIE狸捅。接收到多個COOKIE時，同樣可以以多個COOKIE形式發(fā)送累提。

其他首部字段

X-Frame-Options：用于控制網(wǎng)站內容在其他Web網(wǎng)站的Frame標簽內的顯示問題尘喝，其主要目的是為了防止點擊劫持攻擊。

指定值

• DENY:拒絕
• SAMEORIGIN:僅同源域名下的頁面匹配時許可

X-XSS-Protection：針對跨站腳本攻擊的一種對策斋陪，用于控制瀏覽器XSS防護機制的開關朽褪。

• 值0：將XSS過濾設置成無效狀態(tài)
• 值1：將XSS過濾設置成有效狀態(tài)

DNT：拒絕個人信息被收集，是表示拒絕被精準廣告追蹤的一種方法无虚。

• 值0：同意被追蹤
• 值1：拒絕被追蹤

P3P：讓WEB網(wǎng)站上的個人隱私變成一種僅供程序可理解的形式缔赠，以達到保護用戶隱私的目的。

第八章 確認訪問用戶身份的認證

BASIC認證

    步驟1：當請求的資源需要BASIC認真時友题，服務器會隨狀態(tài)碼401返回帶WWW-Authenticate首部字段的響應嗤堰。該字段內包含認證的方式及Request-URI安全域字符串。
    步驟2：接收到狀態(tài)碼401的客戶端為了通過BASIC認證度宦，需要將用戶ID及密碼發(fā)送給服務器踢匣。發(fā)送的字符串內容是由用戶ID和密碼構成告匠，兩者中間以冒號連接后，再經(jīng)過BASE64編碼處理离唬。
    步驟3：接收到包含首部字段Authorization請求的服務器凫海，會對認證信息的正確性進行驗證。如驗證通過后男娄，則返回一條包含Request-URI資源的響應行贪。
    BASIC認證使用上不夠便捷靈活，且達不到多數(shù)WEB網(wǎng)站期望的安全性等級模闲，因此它并不常用建瘫。

DIGEST認證

    步驟1：請求需認證的資源時，服務器會隨著狀態(tài)碼401尸折，返回帶WWW-Authenticate首部字段的響應啰脚。該字段內包含質問響應方式認證所需的臨時質詢碼。首部字段WWW-Authenticate內必須包含realm和nonce這兩個字段的信息实夹。nonce是一種每次隨返回的401響應生產(chǎn)的任意隨機字符串橄浓，該字符串通常推薦由BASE64編碼的十六進制數(shù)組成。
    步驟2：接收到401狀態(tài)碼的客戶端亮航，返回的響應中包含DIGEST認真必須的首部字段Authenticate信息（username, realm, nonce, uri, response-經(jīng)過MD5運算后的密碼字符串形成響應碼）荸实。
    步驟3：接收到包含首部字段Authorization請求的服務器，會確認認證信息的正確性缴淋。認證通過后則返回包含Request-URI資源的響應准给。
    DIGEST認證安全等級高于BASIC但低于HTTPS，它提供防止密碼被竊聽的保護機制重抖，但并不存在防止用戶偽裝的保護機制露氮。

SSL客戶端認證

    SSL客戶端認證時借由HTTPS的客戶端證書完成認證的方式。憑借客戶端證書認證钟沛，服務器可確認訪問是否來自已登錄的客戶端畔规。
    需要事先將客戶端證書分發(fā)給客戶端，且客戶端必須安裝此證書恨统。
    步驟1：接收到需要認真資源的請求叁扫，服務器會發(fā)送Certificate Request報文，要求客戶端提供客戶端證書延欠。
    步驟2：用戶選擇將發(fā)送的客戶端證書后陌兑，客戶端會把客戶端證書信息以Client Certificate報文方式發(fā)送給服務器沈跨。
    步驟3：服務器驗證客戶端證書驗證通過后方可領取證書內客戶端的公開秘鑰由捎，然后開始HTTPS加密通信。
    SSL客戶端認證采用雙因素認證：除了依靠證書完成認證饿凛，一般會和基于表單認證組合形成一種雙因素認證來使用狞玛，就是證書+用戶密碼软驰。

基于表單認證

    - 認證多半為基于表單認證
    - Session管理及Cookie應用
        一般會使用Cookie來管理Session。
        步驟1：客戶端把用戶ID和密碼等登錄信息放入報文的實體部分心肪，通常是以POST方法把請求發(fā)送給服務器锭亏。而這時，會使用HTTPS通信來進行HTML表單畫面的顯示和用戶輸入數(shù)據(jù)的發(fā)送硬鞍。
        步驟2：服務器會發(fā)送以識別用戶的Session ID慧瘤。通過驗證從客戶端發(fā)送過來的登錄信息進行身份認證，然后把用戶的認證狀態(tài)與Session ID綁定后記錄在服務端固该。（在首部字段Set-Cookie內寫入SessionID锅减、為減輕跨站腳本攻擊XSS造成的損失，建議事先在Cookie內加上httponly屬性）
        步驟3：客戶端接收到服務器端發(fā)送來的SessionID后伐坏，會將其作為Cookie保存在本地怔匣。下次發(fā)送服務器請求時，瀏覽器會自動發(fā)送Cookie桦沉，所以Session ID也隨之發(fā)送到服務器每瞒。服務器端通過驗證Session ID識別用戶和其認證狀態(tài)。
        安全的保存方法是利用給密碼加鹽salt的方式增加額外信息纯露，再使用散列hash函數(shù)計算出散列值后保存
        salt：由服務器隨機生成的一個字符串剿骨，好處是就算使用了同一個密碼，由于隨機生成的salt值不同埠褪，對應的散列值也就不同懦砂，減少密碼泄露的風險。

第九章 基于HTTP的功能追加協(xié)議

消除HTTP瓶頸的SPDY

解決HTTP的性能瓶頸组橄，縮短WEB頁面的加載時間（50%）

HTTP的瓶頸

舉個微博的例子荞膘，如果使用HTTP協(xié)議探知服務器上是否有內容更新，就必須頻繁地從客戶端到服務器端進行確認玉工，如果服務器上沒有內容更新羽资，那么就會產(chǎn)生徒勞的通信。

具體瓶頸

• 一條連接上只可發(fā)送一個請求
• 請求只能從客戶端開始遵班。客戶端不可以接收除響應以外的指令狭郑。
• 請求/響應首部未經(jīng)壓縮就發(fā)送腹暖，首部信息越多延遲越大黄绩。
• 發(fā)送冗長的首部粤蝎，每次互相發(fā)送相同的首部造成的浪費較多墓懂。
• 可任意選擇數(shù)據(jù)壓縮格式，非強制壓縮發(fā)送捕仔。

解決方法

• Ajax：核心技術是名為XMLHttpRequest的API匕积，通過JavaScript腳本語言的調用就能和服務器進行HTTP通信。借由這種手段榜跌，就能從已加載完畢的WEB頁面上發(fā)起請求闪唆，只更新局部頁面。缺點是可能導致大量請求的產(chǎn)生钓葫。
• Comet：一旦服務器端有內容更新了悄蕾，Comet不會讓請求等待，而是直接給客戶端返回響應础浮。這是一種通過延遲應答帆调，模擬實現(xiàn)服務器端向客戶端推送的功能。缺點是為了維持連接會消耗更多的資源
• 這兩種方案豆同，HTTP的瓶頸都仍然存在番刊。

SPDY

SPDY沒有完成改寫HTTP協(xié)議，而是在TCP/IP的應用層與運輸層之間通過新加會話層的形式運作影锈，同時考慮到安全性問題芹务，SPDY規(guī)定通信中使用SSL蝉绷。

功能

• 多路復用流
• 賦予請求優(yōu)先級
• 壓縮HTTP首部
• 推送功能
• 服務器提示功能

缺點

• 只將單個域名的通信多路復用
• WEB網(wǎng)站導入該技術的進展不佳

使用瀏覽器進行全雙工通信的WebSocket

WEB瀏覽器與WEB服務器之間全雙工通信標準，WebSocket協(xié)議由IETF定為標準锄禽，WebSocket API有W3C定為標準潜必。主要為了解決AJAX和CONMET里XMLHttpRequest附帶的缺陷所引起的問題靴姿。
一旦WEB服務器與客戶端之間建立起WebSocket協(xié)議的通信連接沃但，之后所有的通信都依靠這個專用協(xié)議進行。通信過程中可互相發(fā)送JSON佛吓、XML宵晚、HTML或圖片等任意格式的數(shù)據(jù)。連接的發(fā)起方仍是客戶端维雇，一旦確立WebSocket通信連接淤刃，不論服務器還是客戶端，任意一方都可直接向對方發(fā)送報文吱型。

特點

• 推送功能：支持服務器向客戶端推送數(shù)據(jù)的推送功能逸贾，不必等待客戶端請求。
• 減少通信量：只要建立起WebSocket連接津滞，就希望一直保持連接狀態(tài)铝侵，而且WebSocket的首部信息很小，通信量也相應減少了触徐。

實現(xiàn)
在HTTP連接建立后咪鲜，需要完成一次“握手”的步驟

• 握手-請求：需要用到HTTP的Upgrade首部字段，告知服務器通信協(xié)議發(fā)生改變撞鹉，以達到握手的目的疟丙。
• 握手-響應：返回狀態(tài)碼101的響應。

Web服務器管理文件的WebDAV

概念：是一個可對WEB服務器上的內容直接進行文件復制鸟雏、編輯等操作的分布式文件系統(tǒng)享郊。除了創(chuàng)建、刪除文件等基本功能孝鹊，它還具備文件創(chuàng)建者管理拂蝎、文件編輯過程中禁止其他用戶內容覆蓋的加鎖功能，以及對文件內容修改的版本控制功能惶室。

第十一章 Web的攻擊技術

針對WEB的攻擊技術

HTTP不具備必要的安全功能温自，應用HTTP協(xié)議的服務器和客戶端，以及運行在服務器上的WEB應用等資源才是攻擊目標

針對WEB應用的攻擊模式

• 以服務器為目標的主動攻擊：通過直接訪問WEB應用把攻擊代碼傳入的攻擊模式
  SQL注入攻擊皇钞；
  OS命令注入攻擊悼泌；
• 以服務器為目標的被動攻擊：利用圈套策略執(zhí)行攻擊代碼的攻擊模式

1. 攻擊者誘使用戶觸發(fā)已設置好的陷阱，而陷阱會啟動發(fā)送已嵌入攻擊代碼的HTTP請求夹界。
2. 用戶不知不覺中招之后馆里，用戶的瀏覽器或郵件客戶端就會觸發(fā)這個陷阱
3. 中招后的用戶瀏覽器會把含有攻擊代碼的HTTP請求發(fā)送給作為攻擊目標的WEB應用，運行攻擊代碼。
   4.執(zhí)行完攻擊代碼鸠踪，存在安全漏洞的WEB應用會成為攻擊者的跳板丙者，可能導致用戶所持的Cookie等個人信息被竊取，登錄狀態(tài)中的用戶權限遭惡意濫用等后果营密。

因輸出值轉義不完全引發(fā)的安全漏洞

客戶端的驗證

WEB應用端（服務器端）的驗證

• 輸入值驗證
• 輸出值轉義

跨腳本攻擊

概念：通過存在安全漏洞的Web網(wǎng)站注冊用戶的瀏覽器內運行非法的HTML標簽或JavaScript進行的一種攻擊械媒。
影響

• 利用虛假輸入表單片區(qū)用戶個人信息
• 竊取用戶的Cookie值，被害者在不知情的情況下评汰，幫助攻擊者發(fā)送惡意的請求
• 顯示偽造的文章或圖片

SQL注入攻擊

概念：針對WEB應用使用的數(shù)據(jù)庫纷捞，通過運行非法的SQL而產(chǎn)生的攻擊。
影響：可能引發(fā)極大的威脅被去，有時會直接導致個人信息及機密信息的泄露主儡。

OS命令注入攻擊

概念：指通過WEB應用，執(zhí)行非法的操作系統(tǒng)命令達到攻擊的目的惨缆，只要在能調用SHELL函數(shù)的地方就有存在被攻擊的風險糜值。
影響：OS命令注入攻擊可以向SHELL發(fā)送命令，讓WINDOWS或LINUX操作系統(tǒng)的命令行啟動程序坯墨，也就是說寂汇，通過OS注入攻擊可執(zhí)行OS上安裝著的各種程序。

HTTP首部注入攻擊

概念：通過在響應首部字段內插入換行畅蹂，添加任意響應首部或主體的一種攻擊健无，屬于被動攻擊模式。
影響

• 設置任何Cookie信息
• 重定向至任意URL
• 顯示任意的主題（HTTP響應截斷攻擊）
  HTTP響應截斷攻擊

郵件首部注入攻擊

WEB應用中的郵件發(fā)送功能液斜，攻擊者通過向郵件首部TO或Subject內任意添加非法內容發(fā)起的攻擊累贤。利用存在安全漏洞的WEB網(wǎng)站，可對任意郵件地址發(fā)送廣告郵件或病毒郵件少漆。
方法：%0D%0A臼膏，一旦WEB應用接收了這個換行符，就可能實現(xiàn)對BCC郵件地址的追加發(fā)送

目錄遍歷攻擊

對本無意公開的文件目錄示损，通過非法截斷其目錄路徑后渗磅，達成訪問目的的一種攻擊。

遠程文件包含漏洞

部分腳本內容需要從其他文件讀入時检访，攻擊者利用指定外部服務器的URL充當依賴文件始鱼，讓腳本讀取之后，就可運行任意腳本的一種攻擊脆贵。

因設置或設計上的缺陷引發(fā)的安全漏洞

錯誤設置WEB服務器医清，或是由設計上的一些問題引起的安全漏洞。

強制瀏覽：從安置在WEB服務器的公開目錄下的文件中卖氨，瀏覽哪些原本非自愿公開的文件会烙。

影響

• 泄露顧客的個人信息等重要情報
• 泄露原本需要具有訪問權限的用戶才可查閱的信息內容
• 泄露未外連到外界的文件

不正確的錯誤消息處理

• WEB應用的錯誤信息內包含對攻擊者有用的信息
  WEB應用拋出的錯誤消息
  數(shù)據(jù)庫等系統(tǒng)拋出的而錯誤消息

• 集中在幾個方面：
  PHP或ASP等腳本錯誤
  數(shù)據(jù)庫或中間件的錯誤
  WEB服務器的錯誤

• 開放重定向
  對指定的任意URL作重定向跳轉的功能：訪問A網(wǎng)站結果跳到了B網(wǎng)站

因會話管理疏忽引發(fā)的安全漏洞

管理用戶狀態(tài)的必備功能负懦，但是如果再會話管理上有所疏忽，就會導致用戶的認證狀態(tài)唄竊取等后果柏腻。

會話劫持

通過某種手段拿到了用戶的會話ID纸厉，并非法使用會話ID偽裝成用戶，達到攻擊的目的五嫂。
途徑

• 通過非正規(guī)的生產(chǎn)方法推測會話ID
• 通過竊聽或XSS攻擊盜取會話ID
• 通過會話固定攻擊強行獲取會話ID

會話固定攻擊

對以竊取目標會話ID為主動攻擊手段的會話劫持而已颗品，會話固定攻擊會強制用戶使用攻擊者指定的會話ID，屬于被動攻擊贫导。
攻擊者訪問登錄頁面抛猫，服務器返回一個會話ID蟆盹，攻擊者誘導用戶前去認證孩灯，認證后攻擊者用已認證的ID進行訪問。

跨站點請求偽造

攻擊者通過設置好的陷阱逾滥，強制對已完成認證的用戶進行非預期的個人信息或設定信息等某些狀態(tài)更新峰档，屬于被動攻擊。

影響

• 利用已通過認證的用戶權限更新設定信息等
• 利用已通過認證的用戶權限購買商品
• 利用已通過認證的用戶權限在留言板上發(fā)表言論

其他安全漏洞

密碼破解

通過網(wǎng)絡的密碼試錯

• 窮舉法：用所有可行的候選密碼對目標的密碼系統(tǒng)試錯
• 字典攻擊：利用事先收集好的候選密碼（經(jīng)過各種組合方式后存入字典）寨昙，枚舉字典中的密碼讥巡，嘗試通過認證的一種攻擊手法。

對已加密密碼的破解

• 把加密處理的密碼還原成明文形式
• 通過窮舉法*字典攻擊進行類推
• 彩虹表：由明文密碼及與之對應的散列構成的一張數(shù)據(jù)庫表舔哪，是一種通過事先制作龐大的彩虹表欢顷，可在窮舉法*字典攻擊等實際破解過程中縮短消耗時間的技巧。從彩虹表內搜索散列值就可以推導出對應的明文密碼捉蚤。
• 拿到秘鑰
• 加密算法的漏洞

點擊劫持

利用透明的按鈕或鏈接做成陷阱抬驴，覆蓋在WEB頁面上。

DOS攻擊

運行中的服務呈停止狀態(tài)的攻擊缆巧，也叫服務停止攻擊或拒絕服務攻擊布持。
兩種方式

• 集中利用訪問請求造成資源過載，資源用盡的同事陕悬，實際上服務也就呈停止狀態(tài)题暖。
• 通過攻擊安全漏洞使服務停止。

后門程序

設置隱藏入口捉超，可不按正常步驟使用受限功能胧卤，利用后門才能使用。
3種類型

• 開發(fā)階段作為DEBUG調用的后門程序
• 開發(fā)者為了自身利益植入的后門程序
• 攻擊者通過某種方法設置的后門程序