iOS開發(fā)·讀書筆記之《圖解HTTP》（下）

第六章 HTTP首部

6.1 HTTP報文首部

IMG_0701.JPG
  • HTTP協(xié)議的請求和響應報文中必定包含HTTP首部。首部內容為客戶端和服務器分別處理請求和響應提供所需要的信息憾股。
  • 報文首部由幾個字段構成

HTTP請求報文

  • 在請求中鹿蜀，HTTP報文由方法、URI服球、HTTP版本耻姥、HTTP首部字段等部分構成。


    IMG_0702.JPG

  • 例如：訪問：http：//hackr.jp時有咨，請求報文的首部信息琐簇。


    IMG_0703.PNG

HTTP響應報文

  • 在響應中，HTTP報文由HTTP版本、狀態(tài)碼（數字和原因短語）婉商、HTTP首部字段3部分構成


    IMG_0704.JPG
  • 例子：請求訪問http://hackr.js時似忧，返回的響應報文的首部信息
    IMG_0705.PNG
  • 在報文眾多的字段當中，HTTP首部字段包含的信息最為豐富丈秩。首部字段同事存在于請求和響應報文內盯捌，并涵蓋HTTP報文相關的內容信息。
  • 因HTTP版本或擴展規(guī)范的變化蘑秽，首部字段可支持的字段內容略有不同饺著。

6.2 HTTP首部字段

HTTP首部字段傳遞重要信息

  • HTTP首部字段是構成HTTP報文的要素之一。在客戶端與服務器之間以HTTP協(xié)議進行通信的過程中肠牲，無論是請求還是響應都會使用首部字段幼衰，它能起到傳遞額外重要信息的作用。

  • 使用首部字段是我了給瀏覽器和服務器提供報文主體大小缀雳、所使用的語言渡嚣、認證信息等內容


    IMG_0706.JPG

HTTP首部字段結構

  • HTTP首部字段是由首部字段名和字段值構成的，中間用冒號“：”分隔肥印；


    IMG_0707.PNG

  • 例如识椰，在HTTP首部匯總以Content-Type這個字段來表示報文主體的對象類型。


    IMG_0708.PNG
  • 就以上述示例來看深碱，首部字段名為Content-Type腹鹉，字符串text/html是字段值。

  • 另外敷硅，字段值對應單個HTTP首部字段可以有多個值种蘸，如下所示：


    IMG_0709.PNG

若HTTP首部字段重復了會如何

  • 當HTTP報文首部中出現了兩個或兩個以上具有哦相同首部字段名時會怎么樣？這種情況在規(guī)范內尚未明確竞膳，根據瀏覽器內部處理邏輯的不同，結果可能并不一致诫硕。有些瀏覽器會有限處理第一次出現的首部字段，而有些則會優(yōu)先處理最后出現的首部字段；

4種HTTP首部字段類型

  • HTTP首部字段根據實際用途被分為一下4種類型宾娜。
通用首部字段
  • 請求報文和響應報文兩方都會使用的首部
請求首部字段
  • 從客戶端向服務器端發(fā)送請求報文時使用的首部瘫怜。補充了請求的附加內容、客戶端信息藕届、響應內容相關優(yōu)先級等信息挪蹭。
響應首部字段
  • 從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容休偶，也會要求客戶端附加額外的內容信息梁厉。
實體首部字段
  • 針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與試題有關的信息。

HTTP/1.1 首部字段一覽

  • HTTP/1.1規(guī)范定義了如下47種首部字段词顾。


    IMG_0710.JPG

    IMG_0711.JPG

    IMG_0712.JPG

    IMG_0713.JPG

非HTTP/1.1首部字段

  • 在HTTP協(xié)議通信交互中使用到的首部字段八秃，不限于RFC2616中定義的47種首部字段，還有Cookie肉盹、Set-Cookie和Content-Disposition等再其他RFC中定義的首部字段昔驱，他們的使用頻率也很高。
  • 這些非正式的首部字段統(tǒng)一歸納在RFC4229 HTTP Header Field Registrations中上忍。

End - to - end首部和Hop - by - hop首部

  • HTTP首部字段講定義成緩存代理和非緩存代理的行為骤肛，分成2種類型。
端到端首部
  • 分在此類別中的首部會轉發(fā)給請求/響應對應的最終接收目標窍蓝，且必須保存在由緩存生成的響應中腋颠，另外規(guī)定它必須被轉發(fā)。
逐跳首部
  • 粉在此類別中的首部只對單次轉發(fā)有效它抱，會因通過緩存或代理而不再轉發(fā)秕豫。HTTP/1.1和之后版本中，如果要使用hop - by - hop首部观蓄，需提供Connection首部字段混移。
  • 下面列舉了HTTP/1.1中的逐跳首部字段，除這8個首部字段之外侮穿，其他所有字段都屬于端到端首部
    • Conncetion
    • Keep-Alive
    • Proxy-Authenticate
    • Proxy-Authorization
    • Trailer
    • TE
    • Transfer-Encoding
    • Upgrade

6.3 HTTP/1.1通用首部字段

  • 通用首部字段是指歌径，請求報文和響應報文雙方都會使用的首部。

Cache-Control

  • 通過指定首部字段Cache-Control的指令亲茅，就能操作緩存的工作機制回铛。


    IMG_0714.JPG

  • 指令的參數是可選的，多個指令之間通過“克锣，”分隔茵肃。首部字段Cache-Control的指令可用于請求及響應時。


    IMG_0715.PNG
Cache-Control指令一覽

  • 可用的指令按請求和響應分類如下所示：


    IMG_0716.JPG

    IMG_0717.JPG
  • 表示是否能緩存的指令
public指令
IMG_0718.PNG
  • 當指定使用public指令時袭祟，則明確表明其他用戶也可利用緩存验残。
private指令
IMG_0719.JPG

IMG_0720.PNG
  • 當指定private指令后，響應只以特定的用戶作為對象巾乳，這與public指令的行為相反您没。
  • 緩存服務器會對該特定用戶提供資源緩存的服務，對于其他用戶發(fā)送過來的請求胆绊，代理服務器則不會返回緩存氨鹏。
no-cache指令
IMG_0721.JPG

IMG_0722.PNG
  • 使用no-cache指令的目的是為了防止從緩存中返回過期的資源。
  • 客戶端發(fā)送的請求中如果包含no-cache指令压状，則表示客戶端講不會接受緩存過的響應仆抵。于是，“中間”的緩存服務器必須把客戶端請求轉發(fā)給源服務器。

  • 如果服務器返回的響應中包含no-cache指令肢础，那么緩存服務器不能對資源進行緩存还栓。源服務器以后也將不再對緩存服務器請求中提出的資源有效性進行確認，且禁止其對響應資源進行緩存操作传轰。


    IMG_0723.PNG
  • 由服務器返回的響應中剩盒，若報文首部字段Cache-Control中對no-cache字段名具體指定參數值，那么客戶端在接收到這個被指定參數值的首部字段對應的響應報文后慨蛙，就不能使用緩存辽聊。換言之，無參數值的首部字段可以使用緩存期贫。只能在響應指令中指定該參數跟匆。
控制可執(zhí)行緩存的對象的指令
no-store指令
IMG_0724.PNG
  • 當使用no-store指令時，暗示請求（和對應的響應）或響應匯總包含機密信息通砍。
  • 因此玛臂，該指令規(guī)定緩存不能在本地存儲請求或響應的任一部分。
指定緩存期限和認證的指令
s-maxage指令
IMG_0725.PNG
  • s-maxage指令的功能和max-age指令的相同封孙，它們的不同點是s-maxage指令只適用于供多位用戶使用的公共緩存服務器迹冤。也就是說，對于向同一用戶重復返回響應的服務器來說虎忌，這個指令沒有任何作用泡徙。
  • 另外，當使用s-macage指令后膜蠢，則直接忽略對Expires首部字段及max-age指令的處理堪藐。
max-age指令
IMG_0726.JPG

IMG_0727.PNG
  • 當客戶端發(fā)送的請求中包含max-age指令時，如果判定緩存資源的緩存時間數值比指定時間的數值更小挑围，那么客戶端就接收緩存的資源礁竞。另外，當指定max-age值為0杉辙，那么緩存服務器通常需要將請求轉發(fā)給源服務器模捂。
  • 當服務器返回的響應中包含max-age指令時，緩存服務器將不對資源的有效性再作確認奏瞬，而max-age數值代表資源保存為緩存的最長時間。
  • 應用HTTP/1.1版本的緩存服務器遇到同時存在Expires首部字段的情況時泉孩，會優(yōu)先處理max-age指令硼端，而忽略掉Expirse首部字段。而HTTP/1.0版本的緩存服務器的情況卻相反寓搬，max-age指令會被忽略掉珍昨。
min-fresh指令
IMG_0728.JPG

IMG_0729.PNG
  • min-fresh指令要求緩存服務器返回至少還未過指定時間的緩存資源。
  • 比如，當指定min-fresh為60秒后镣典，在這60秒以內如果有超過有效期限的資源都無法作為響應返回了兔毙。
max-stale指令
IMG_0730.PNG
  • 使用max-stale可指示緩存資源，即使過期也照常接收兄春。
  • 如果指令未指定參數值澎剥，那么無論經過多久，客戶端都會接收響應赶舆；如果指令中指定了具體數值哑姚，那么即使過期，只要仍處于max-stale指定的時間內芜茵，仍舊會被客戶端接收叙量。
only-if-cached指令
IMG_0731.PNG
  • 使用only-if-cached指令表示客戶端僅在緩存服務器本地緩存目標資源的情況下才會要求其返回。換言之九串，該指令要求緩存吳福氣不重新加載響應绞佩，也不會再次確認資源有效性。若發(fā)生請求緩存服務器的本地緩存無響應猪钮，則返回狀態(tài)碼504 Gateway Timeout品山；
must-revalidate指令
IMG_0732.PNG
  • 使用must-revalidate指令，代理會向源服務器再次驗證即將返回的響應緩存目前是否仍然有效躬贡。
  • 若代理無法連通源服務器再次獲取有效資源的話谆奥，緩存必須給客戶端一條504狀態(tài)碼；
  • 另外拂玻，使用must-revalidate指令會忽略請求的max-stale指令（即使已經在首部使用了max-stale酸些，也不會再有效果）。
proxy-revalidate指令
IMG_0733.PNG
  • proxy-recalidate指令要求所有的緩存服務器在接收到苦短帶有該指令的請求返回響應之前檐蚜，必須再次驗證緩存的有效性魄懂。
no-transform指令
IMG_0734.PNG
  • 使用no-transform指令規(guī)定無論是在請求還是響應中，緩存都不能改變試題主體的媒體類型闯第。
  • 這樣做可防止緩存活代理壓縮圖片等類似操作市栗。
Cache-Control拓展
cache-extension token
IMG_0735.PNG
  • 通過cache-extension標記（token），可以拓展Cache-Control首部字段內的指令咳短。
  • 如上例填帽，Cache-Control首部字段本身沒有community這個指令。借助extension tokens實現了該指令的添加咙好。如果緩存服務器不能理解community這個新指令篡腌，就會直接忽略。因此勾效，extension tokens僅對能理解它的緩存服務器來說是有意義的嘹悼。

Connection

Connection首部字段具備如下兩個作用
  • 控制不再轉發(fā)給代理的首部字段
  • 管理持久連接
控制不再轉發(fā)給代理的首部字段
IMG_0736.JPG

IMG_0737.PNG
  • 在客戶端發(fā)送請求和服務器返回響應內叛甫，使用Connection首部字段，可控制不再轉發(fā)給代理的首部字段杨伙。
管理持久連接
IMG_0738.JPG

IMG_0739.PNG

  • HTTP/1.1版本的默認連接都是持久連接其监。為此，客戶端會在持久連接上連續(xù)發(fā)送請求限匣。當服務器端想明確斷開連接時抖苦，則指定Connection首部字段的值為Close。


    IMG_0740.JPG

    IMG_0741.PNG
  • HTTP/1.1之前的HTTP版本的默認連接都是非持久連接膛腐。為此睛约，如果想在舊版本的HTTP協(xié)議上維持連接，則需要指定Conection首部字段的值為Keep-Alive哲身。
  • 為上圖①所示辩涝，客戶端發(fā)送請求給服務器時，服務器端會像上圖②那樣加上首部字段Keep-Alive及首部字段Connection后返回響應勘天。

Date

  • 首部字段Date表明創(chuàng)建HTTP報文的日期和時間怔揩。


    IMG_0742.JPG

  • HTTP/1.1協(xié)議使用在RFC1123中規(guī)定的日期時間的格式，如下實例：


    IMG_0743.PNG

  • 之前的HTTP協(xié)議版本中使用在RFC850中定義的格式脯丝，如下實例：


    IMG_0744.PNG

  • 除此之外商膊，還有一種格式。它與C標準庫內的asctime（）函數的輸出格式一致宠进。


    IMG_0745.PNG

Pragma

  • Pragma是HTTP/1.1之前版本的歷史遺留字段晕拆，僅作為與HTTP/1.0的向后兼容而定義。

  • 規(guī)范定義的形式唯一材蹬，如下所示：


    IMG_0746.PNG

  • 該首部字段屬于通用首部字段实幕，但只用在客戶端發(fā)送的請求中〉唐鳎客戶端會要求所有的中間服務器不返回緩存的資源


    IMG_0747.JPG

  • 所有的中間服務器如果都能以HTTP/1.1為基準昆庇，那直接采用Cache-Control：no-cache指定緩存的處理方式是最為理想的。但要整體掌握全部中間服務器使用的HTTP協(xié)議版本缺是不現實的闸溃。因此整吆，發(fā)送的請求會同時含有下面兩個首部字段。


    IMG_0748.PNG

Trailer

IMG_0749.JPG

  • 首部字段Trailer會事前說明在報文主體后記錄了哪些首部字段辉川。改首部字段可應用在HTTP/1.1版本分塊傳輸編碼時表蝙。


    IMG_0750.PNG
  • 以上用例中，指定首部字段Trailer的值為Expires乓旗，在報文主體之后出現了首部字段Expires府蛇。

Transfer-Encoding

IMG_0751.JPG
  • 首部字段Transfer-Encoding規(guī)定了傳輸報文主體時采用的編碼方式拓轻。

  • HTTP/1.1的傳輸編碼方式僅對分塊傳輸編碼有效。


    IMG_0752.PNG
  • 以上用例中泵肄，正如在首部字段Transfer-Encoding中指定的那樣返劲，有效使用分塊傳輸編碼窃爷，且分別被分成3312字節(jié)和914字節(jié)大小的分塊數據约巷。

Upgrade

  • 首部字段Upgrade用于檢測HTTP協(xié)議及其他協(xié)議是否可使用更高的版本進行通信栓票，其參數值可以用來指定一個完全不同的通信協(xié)議衅鹿。


    IMG_0753.JPG
  • 上圖用例匯總毅厚，首部字段Upgrade指定的值為TLS/1.0塞颁。請注意此處兩個字段首部字段的對應關系，Connection的值被指定為Upgrade吸耿。Upgrade首部字段產生作用的Upgrade對象僅限于客戶端和鄰接服務器之間祠锣。因此，使用首部字段Upgrade時咽安，還需要額外指定Connection：Upgrade伴网。
  • 對于附有首部字段Upgrade的請求，服務器可用101 Awitching Protocols狀態(tài)碼作為響應返回妆棒。

Via

  • 使用首部字段Via是為了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑澡腾。
  • 報文經過代理或網關時，會先在首部字段Via中附加該服務器的信息糕珊，然后再進行轉發(fā)动分。這個做法和traceroute及電子郵件的Received首部的工作機制很類似。

  • 首部字段Via不僅用于追蹤報文的轉發(fā)红选，還可避免請求回環(huán)的發(fā)生澜公。所以必須在經過代理時附加該首部字段內容。


    IMG_0754.JPG
  • 上圖用例中喇肋，在經過代理服務器A時坟乾，Via首部附加了“1.0 gw.hackr.jp”這樣的字符串值。行頭的1.0是指接收請求的服務器上應用的HTTP協(xié)議版本苟蹈。接下來經過代理服務器B時亦是如此糊渊，在Via首部附加服務器信息，也可增加1個新的Via首部寫入服務器信息慧脱。
  • Via首部是為了追蹤傳輸路徑渺绒，所以經常會和TRACE方法一起使用。比如菱鸥，代理服務器接收到由TRACE方法發(fā)送過來的請求時宗兼，代理服務器就不能再轉發(fā)該請求了。這種情況下氮采，代理服務器會將自身的信息附加到Via首部后殷绍，返回該請求的響應。

Warning

  • HTTP/1.1的Warning首部是從HTTP/1.0的首部演變過來的鹊漠。該首部通常會告知用戶一些與緩存相關的問題的警告主到。


    IMG_0755.PNG

  • Warning首部的格式如下茶行。最后的日期時間部分可省略。


    IMG_0756.PNG

    IMG_0757.JPG

6.4 請求首部字段

  • 請求首部字段是從客戶端往服務器端發(fā)送請求報文中所使用的字段登钥，用于補充請求的附加信息畔师、客戶端信息、對響應內容相關的優(yōu)先級等內容牧牢。


    IMG_0758.JPG

Accept

IMG_0759.JPG

IMG_0760.PNG
  • Accept首部字段可通知服務器看锉，用戶代理能夠處理的媒體類型及媒體類型的相對優(yōu)先級∷ⅲ可使用type/subtype這種形式伯铣，一次指定多種媒體類型。
  • 下面我們試舉幾個媒體類型的例子轮纫。
    • 文本文件
      • text/html, text/plain, text/css....
      • application/xhtml+xml, application/xml....
    • 圖片文件
      • image/jpeg, image/gif, image/png....
    • 視頻文件
      • video/mpeg, video/quicktime
    • 應用程序使用的二進制文件
      • application/octet-stream, application/zip...
  • 比如：如果瀏覽器不支持PNG圖片的顯示腔寡，那Accept就不指定image/png, 而指定可處理的image/gif和image/jpeg等圖片類型。
  • 若想要給顯示的媒體類型增加優(yōu)先級掌唾，則使用q=來額外表示權重值蹬蚁，用分號進行分隔。權重值q的范圍是0~1郑兴，且1為最大值犀斋。不指定權重q值時，默認權重為q=1.0.
  • 當服務器提供多種內容時情连，將會首先返回權重值值最高的媒體類型叽粹。

Accept-Charset

IMG_0761.JPG

IMG_0762.PNG
  • Accept-Charset首部字段可用來通知服務器用戶代理支持的字符集及字符集的相對優(yōu)先順序。另外却舀，可一次性指定多種字符集虫几。與首部字段Accept相同的是可用權重q值來表示相對優(yōu)先級。
  • 該首部字段應用于內容協(xié)商機制的服務器驅動協(xié)商挽拔。

Accept-Encoding

IMG_0763.JPG

IMG_0764.PNG
  • Accept-Encoding首部字段用來告知服務器用戶代理支持的內容編碼及內容編碼的優(yōu)先級順序辆脸。可一次性指定多種內容編碼螃诅。
  • 下面試舉出幾個內容編碼的例子啡氢。
    gzip
    • 由文件壓縮程序gzip生成的編碼格式，采用Lempel-Ziv算法及32位循環(huán)冗余校驗术裸。
    compress
    • 由UNIX文件壓縮程序compress生成的編碼格式倘是，采用Lempel-Ziv-Welch算法。
    deflate
    • 組合使用zlib格式及由deflate壓縮算法生成的編碼格式
    identity
    • 不執(zhí)行壓縮或不會辯護阿德默認編碼格式
  • 采用權重q值來表示相對優(yōu)先級袭艺，這點與首部字段Accept相同搀崭。另外，也可使用星號作為通配符猾编，指定任意的編碼格式瘤睹。

Accept-Language

IMG_0765.JPG

IMG_0766.PNG
  • 首部字段Accept-Language用來告知服務器用戶代理能夠處理的自然語言集升敲，以及自然語言集的相對優(yōu)先級『浯可一次性指定多種自然語言集冻晤。
  • 和Accept首部字段一樣，按權重值q來表示相對優(yōu)先級绸吸。在上述圖例中，客戶端在服務器有中文版資源的情況下设江，會請求其返回中文版對應的響應锦茁，沒有中文版時，則請求返回英文版響應叉存。

Authorization

IMG_0767.JPG

IMG_0768.PNG
  • 首部字段Authorization是用來告知服務器码俩，用戶代理的認證信息。通常歼捏，想要通過服務器認證的用戶代理會在接收到返回的401狀態(tài)碼響應后稿存，吧首部字段Authorization加入請求中。公用緩存在接收到含有Authorization首部字段的請求時的操作處理會略有差異瞳秽。

Expect


IMG_0770.PNG
  • 客戶端使用首部字段Expect來告知服務器瓣履，期望出現的某種特定行為。因服務器無法理解客戶端的期望作出回應而發(fā)生錯誤時练俐，會返回狀態(tài)碼417 Expectation Failed袖迎。
  • 客戶端可以利用改首部字段，寫明所期望的拓展腺晾。雖然HTTP/1.1規(guī)范只定義了100-continue燕锥。
  • 等待狀態(tài)碼100響應的客戶端在發(fā)生請求時，需要指定expect：100-continue悯蝉。

From

IMG_0771.JPG
  • 首部字段From用來告知服務器使用用戶代理的用戶的電子郵件地址归形。通常，其使用目的就是為了顯示搜索引擎等用戶代理的負責人的電子郵件聯系方式鼻由。使用代理時暇榴，應盡可能包含From首部字段。

Host

圖：虛擬知己運行在同一個IP上蕉世，因此使用首部字段Host加以區(qū)分跺撼。.JPG

IMG_0773.PNG
  • 首部字段Host會告知服務器，請求的資源所處的互聯網主機名和端口號讨彼。Host首部字段在HTTP/1.1規(guī)范內是唯一一個必須被包含在請求內的首部字段歉井。
  • 首部字段Host和以單臺服務器分配多個域名的虛擬主機的工作機制有很密切的關聯，這是首部字段Host必須存在的意義哈误。

  • 請求唄發(fā)送至服務器時哩至，請求中的知己名會用IP地址直接替換解決躏嚎。但如果這時，相同的IP地址下不熟運行著多個域名菩貌，那么服務器就會無法理解酒精是哪個域名對應的請求卢佣。因此，就需要使用首部字段Host來明確指出請求的主機名箭阶。若服務器未設定主機名虚茶，那直接發(fā)送一個空值即可。如下所示：


    IMG_0773.PNG

If-Match

圖：附帶條件請求.JPG

  • 形如If-xxx這種樣式的請求首部字段仇参，都可稱為條件請求嘹叫。服務器收到附帶條件的請求后，只有判斷指定條件為真時诈乒，才會執(zhí)行請求罩扇。


    圖：只有當If-Match的字段值跟ETag值匹配一致時，服務器才會接受請求.JPG

    IMG_0777.PNG
  • 首部字段If-Match怕磨，屬附帶條件之一喂饥，它會告知服務器匹配資源所用的試題標記值。這時的吳福氣無法使用弱ETag值肠鲫。
  • 服務器會對比If-Match的字段值和資源的ETag值员帮，僅當兩者一致時，才會執(zhí)行請求导饲。反之集侯，則返回狀態(tài)碼412 Precondition Failed的響應。
  • 還可以使用型號指定If-Match的字段值帜消。針對這種情況棠枉，服務器將會忽略ETag的值，只要資源存在就處理請求泡挺。

If-Modified-Since

圖：如果在If-Modified-Since字段指定的日期時間后辈讶，資源發(fā)生了更新，服務器會接受請求.JPG

IMG_0780.PNG
  • 首部字段If-Modified-Since娄猫，屬附帶條件之一贱除，它會告知服務器若If-Modified-Since字段值早于資源的更新時間，則希望能處理該請求媳溺。而在指定If-Modified-Since字段值的日期時間之后月幌，如果請求的資源都沒有過更新，則返回狀態(tài)碼304 Not Modififed的響應悬蔽。
  • If-Modified-Since用于確認代理或客戶端擁有的本地資源的有效性扯躺。獲取資源的更新日期時間，可通過確認首部字段Last-Modified來確定。

If-None-Match

圖：只有在If-None-Match的字段值與ETag值不一致時录语，可處理該請求倍啥。與If-Match首部字段的作用相反.JPG
  • 首部字段If-None-Match屬于附帶條件之一。它和首部字段If-Match作用相反澎埠。用于指定If-None-Match字段值的實體標記值與請求自愿的ETag不一致時虽缕，它就告知服務器處理該請求。
  • 在GET或HEAD方法中使用首部字段If-None-Match可獲取最新的資源蒲稳。因此氮趋，這與使用首部字段If-Modified-Since時有些類似。

If-Range

IMG_0781.JPG

  • 首部字段If-Range屬于附帶條件之一江耀。它告知服務器若指定的If-Range字段值和請求資源的ETag值或時間相一致時剩胁，則作為范圍請求處理。反之决记，則返回全體資源。


    IMG_0782.JPG
  • 如果不使用首部字段If-Range發(fā)送請求的情況倍踪。故武器端的資源如果更新系宫，那客戶端持有資源中的一部分也會隨之無效，當然建车，范圍請求作為前提是無效的扩借。這時廊佩，服務器會暫且以狀態(tài)碼412 Precondition Failed作為響應返回螃征，其目的是催促客戶端再次發(fā)送請求。這樣一來逗宁，與使用首部字段If-Range比起來领斥，就需要花費兩倍的功夫嫉到。

If-Unmodified-Since

IMG_0783.PNG
  • 首部字段If-Unmodified-Since和首部字段If-Modified-Since的作用相反。它的作用的是告知服務器月洛，指定的請求資源只有在字段值內指定的日期時間之后何恶，未發(fā)生更新的情況下，才能處理請求嚼黔。如果在指定日期時間后發(fā)生了更新细层，則以狀態(tài)碼412 Precondition Failed作為響應返回。

Max-Forwards

圖：每次轉發(fā)數值減1唬涧，當數值變0時返回響應.JPG

IMG_0785.PNG
  • 通過TRACE方法或OPTIONS方法疫赎，發(fā)送包含首部字段Max-Forwards的請求時，該字段以十進制整數形式指定可經過的服務器做大數目碎节。服務器在往下一個服務器轉發(fā)請求之前捧搞，會將Max-Forwards的值減1后重新賦值。當服務器接收到Max-Forwards值為0的請求時，則不再進行轉發(fā)实牡，而是直接返回響應陌僵。
  • 使用HTTP協(xié)議通信時，請求可能會經過代理等多臺服務器创坞。途中碗短，如果代理服務器由于某些原因導致請求轉發(fā)失敗，客戶端也就等不到服務器返回的響應了题涨。

  • 可以靈活使用首部字段Max-Forwards偎谁，針對以上問題產生的原因展開調查。由于當Max-Forwards字段值為0時纲堵，服務器就會理解返回響應巡雨，因此我們至少可以對以那臺服務器未終點的傳輸路徑的捅進狀況有鎖把握。


    圖：代理B到源服務器的請求失敗了席函，但客戶端不知道.PNG

    圖L由于未知原因铐望，導致請求陷入代理之間的循環(huán)，但客戶端不知道.JPG

Proxy-Authorization

IMG_0788.PNG
  • 接收到從代理服務器發(fā)來的認證質詢時茂附，客戶端會發(fā)送包含首部字段Proxy-Authorization的請求正蛙，以告知服務器認證所需要的信息。
  • 這個行為是與客戶端和服務器之間的HTTP訪問認證相類似的营曼，不同之處在于乒验，認證行為未發(fā)生在客戶端與代理之間〉仝澹客戶端與服務器之間的認證锻全，使用首部字段Authorization可起到相同作用。

Range

IMG_0789.PNG
  • 對于只需獲取部分資源的范圍請求录煤，包含首部字段Range即可告知服務器資源的指定范圍鳄厌。上面的示例表示請求獲取從第5001字節(jié)至第10000字節(jié)的資源。
  • 接收到附帶Range首部字段請求的服務器妈踊，會在處理請求之后返回狀態(tài)碼206 Partial Content的響應部翘。無法處理該范圍請求時，則會返回狀態(tài)碼200 OK的響應及全部資源响委。

Referer

IMG_0790.JPG

IMG_0791.PNG
  • 首部字段Refierer會告知服務器請求的原始資源的URI新思。
  • 客戶端一般都會發(fā)送Referer首部字段給服務器。但當直接在瀏覽器的地址欄輸入URI赘风，或出于安全性的考慮時夹囚，也可以不發(fā)送該首部字段。
  • 因為原始資源的URI中的查詢字符串可能含有ID和密碼等保密信息邀窃，要是寫進Referer轉發(fā)給其他服務器荸哟，則有可能導致保密信息的泄漏假哎。
  • 另外，Referer的正確的拼寫應該是Referrer鞍历，但不知為何舵抹，大家一致沿用這個錯誤的拼寫。

TE

IMG_0792.PNG
  • 首部字段TE會告知服務器客戶端能夠處理響應的傳輸編碼方式及相對優(yōu)先級劣砍。它和首部字段Accept-Encoding的功能很相像惧蛹，但是用于傳輸編碼。

  • 首部字段TE除指定傳輸編碼之外刑枝，還可以指定伴隨trailer字段的分塊傳輸編碼的方式香嗓，應用后者時，值需吧trailers賦值給該字段值装畅。


    IMG_0793.PNG

User-Agent

圖：User-Agent用于傳達瀏覽器的種類.JPG

IMG_0795.PNG
  • 首部字段User-Agent會將創(chuàng)建請求的瀏覽器和用戶代理名稱等信息傳達給服務器靠娱。
  • 由網絡爬蟲發(fā)起請求時，有可能會在字段內添加爬蟲作者的電子郵件地址掠兄。此外像云，如果請求經過代理，那么中間也可能被添加上代理服務器的名稱蚂夕。

6.5 響應首部字段

  • 響應首部字段是由服務器端向客戶端返回響應報文中所使用的字段迅诬，用于補充響應的附加信息、服務器信息双抽，以及對客戶端的附加要求等信息百框。


    圖：HTTP響應報文中使用的首部字段.JPG

Accept-Ranges

當不能處理范圍請求時闲礼，Accept-Ranges：none.JPG

IMG_0798.PNG
  • 首部字段Accept-Ranges是用來告知客戶端服務器是否能處理范圍請求牍汹，以指定獲取服務器端某個部分的資源。
  • 可指定的字段值有兩種柬泽，可處理范圍請求時指定其為bytes慎菲，反之則指定其為none。

Age

IMG_0799.JPG

IMG_0800.PNG
  • 首部字段Age能告知客戶端锨并，源服務器在多久前創(chuàng)建了響應露该。字段值的單位為秒。
  • 若創(chuàng)建該響應的服務器是緩存服務器第煮，Age值是值緩存后的響應再次發(fā)起認證到認證完成的的時間值解幼。代理創(chuàng)建響應時必須加上首部字段Age。

ETag

IMG_0801.JPG

IMG_0802.PNG
  • 首部字段ETag能告知客戶端實體標識包警。它是一種可將資源以字符串形式做唯一性標識的方式撵摆。服務器會為每份資源分配對應的ETag。

  • 另外害晦，當資源更新時特铝，ETag值也需要更新。生成ETag值時，并沒有統(tǒng)一的算法規(guī)則鲫剿，而僅僅是由服務器來分配鳄逾。


    IMG_0803.JPG
  • 資源被緩存時，就會被分配唯一性標識灵莲。例如雕凹，當使用中文版的瀏覽器訪問http：//www.google.com/時，就會返回中文版對應的資源笆呆，而使用英文版的瀏覽器訪問時请琳，則會返回英文版對應的資源。兩者的URI是相同的赠幕，所以僅憑URI指定緩存的資源是相當困難的俄精。若再下載過程中出現連接中斷、再聯機的情況榕堰，都會依照ETag值來指定資源竖慧。
強ETag和弱ETag值
  • ETag中有強ETag值和弱ETag值之分。
強ETag值

  • 強ETag值逆屡，不論實體發(fā)生多么細微的變化都會改變其值圾旨。


    IMG_0804.PNG
弱ETag值

  • 弱ETag值只用于提示資源是否相同。只有資源發(fā)生了根本改變魏蔗，產生差異時才會改變ETag值砍的。這時，會在字段值最開始處附加W/莺治。


    IMG_0805.PNG

Location

IMG_0806.JPG

IMG_0807.PNG
  • 使用首部字段Location可以將相應接收方引導至某個與請求你URI位置不同的資源廓鞠。
  • 基本上，該字段會配合3xx：Redirection的響應谣旁，提供重定向的URI床佳。
  • 幾乎所有的蘭蘭器在接收到包含首部字段Location的響應后，都會強制性地嘗試對已提示的重定向資源的訪問榄审。

Proxy-Authenticate

IMG_0808.PNG
  • 首部字段Proxy-Authenticate會把由代理服務器所要求的認證信息發(fā)送給客戶端砌们。
  • 它與客戶端和服務器之前的HTTP訪問認證的行為相似，不同之處在與其認證行為是在客戶端與代理之間進行的搁进。而客戶端與服務器之間進行認證時浪感，首部字段WWW-Authorization有著相同的作用。

Retry-After

IMG_0809.JPG

IMG_0810.PNG
  • 首部字段Retry-After告知客戶端應該在多久之后再次發(fā)送請求饼问。主要配合狀態(tài)碼503 Service Unavailable響應影兽，或3xx Redirect響應一起使用。
  • 字段值可以指定為具體的日期時間匆瓜，可以是創(chuàng)建響應后的秒數赢笨。

Server

IMG_0811.JPG

IMG_0812.PNG

  • 首部字段Server告知客戶端當前服務器上安裝的HTTP服務器應用程序的信息不單單會標出服務器上的然健應用名稱未蝌，還有可能包括版本號和安裝時啟用的可選項。


    IMG_0813.PNG

Vary

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

IMG_0815.PNG
  • 首部字段Vary可對緩存進行控制纸型。源服務器會向代理服務器傳達關于本地緩存使用方法的命令。
  • 從代理服務器接收到源服務器返回包含Vary指定項的響應之后梅忌，若再要進行緩存狰腌，僅對請求中含有相同Vary指定首部字段的請求返回緩存。即使對相同資源發(fā)起請求牧氮，但由于Vary指定的首部字段不相同琼腔，因此必須要從源服務器重新獲取資源。

WWW-Authenticate

IMG_0816.PNG
  • 首部字段WWW-Authenticate用于HTTP訪問認證踱葛。它會告知客戶端適用于訪問請求URI所指定資源的認證方案和帶參數提示的質詢丹莲。狀態(tài)碼401 Unauthorized響應中，肯定帶有首部字段WWW-Authenticate尸诽。
  • 上述示例中甥材，realm字段的字符串是為了辨別請求URI指定資源所受到的保護策略。

6.6 實體首部字段

  • 實體首部字段是包含在請求報文和響應報文中的實體部分所使用的首部性含，用于補充內容的更新時間等與實體相關的信息洲赵。


    圖：在請求和響應兩方的HTTP報文中都含有與實體相關的首部字段

Allow

IMG_0818.JPG

IMG_0819.PNG
  • 首部字段Allow用于通知客戶端能夠支持Request-URI指定資源的所有HTTP方法。當服務器接收到不支持的HTTP方法時商蕴，會以狀態(tài)碼405 Method Not Allowed作為響應返回叠萍。與此同時，還會把所有能支持的HTTP方法寫入首部字段Allow后返回究恤。

Content-Encoding

IMG_0820.PNG

  • 首部字段Content-Encoding會告知客戶端服務器對實體的主體部分選用的內容編碼方式俭令。內容編碼是指在不丟失實體信息的前提下所進行的壓縮后德。


    IMG_0821.JPG
  • 主要采用以下4種內容編碼的方式部宿。
    • gzip
    • compress
    • deflate
    • identity

Content-Language

IMG_0822.JPG

IMG_0823.PNG
  • 首部字段 Content-Language會告知客戶端，實體主體使用的自然語言瓢湃。

Content-Length

IMG_0824.JPG

IMG_0825.PNG
  • 首部字段Content-Length表明了實體主體本分的大小理张。對實體主體進行內容編碼傳輸時，不能再使用Content-Length首部字段绵患。由于實體主體大小的計算方法略微復雜雾叭，所以在此不再展開。

Content-Location

IMG_0826.PNG
  • 首部字段Content-Location給出與報文主體部分相對應的UTI落蝙。和首部字段Location不同织狐，Content-Location表示的是報文主體返回資源對應的URI暂幼。
  • 比如，對于使用首部字段Accept-Language的服務器驅動型請求移迫，當返回的頁面內容與實際請求的對象不同時旺嬉，首部字段Content-Location內會寫明URI。

Content-MD5

圖：客戶端會對接收的報文主體執(zhí)行相同的MD5算法厨埋，然后與首部字段Content-MD5的字段值比較.JPG

IMG_0828.PNG
  • 首部字段Content-MD5是一串由MD5算法生成的值邪媳，其目的在于檢查報文主體在傳輸過程中是否保持完整，以及確認傳輸到達荡陷。
  • 對報文主體執(zhí)行MD5算法獲得的128位二進制數雨效，再通過Base64編碼后將結果寫入Content-MD5字段值。由于HTTP首部無法記錄二進制值废赞，所以要通過Base64編碼處理徽龟。為確保報文的有效性，作為接收方的客戶端會對報文主體再執(zhí)行一次相同的MD5算法唉地。計算出的值與字段值作比較后顿肺，即可判斷出報文主體的準確性。
  • 采用這種方法渣蜗，對內容上的偶發(fā)性改變是無從查證的屠尊，也無法檢測出惡意篡改，那么同時意味著Content-MD5也可重新計算然后被篡改。所以處于接收階段的客戶端是無法一時到報文主體以及首部字段Content-MD5是已經被篡改過的疯攒。

Content-Range

IMG_0829.JPG

IMG_0830.PNG
  • 針對范圍請求腕巡，返回響應時使用的首部字段Content-Range，能告知哭護短作為響應返回的實體的哪個部分符合范圍請求浸赫。字段值以字節(jié)為單位，表示當前發(fā)送部分及整個實體大小赃绊。

Content-Type

IMG_0831.PNG
  • 首部字段Content-Type說明了試題主體內對象的媒體類型既峡。和首部字段Accept一樣，字段值用type/subtype形式賦值碧查。

Expires

IMG_0832.JPG

IMG_0833.PNG
  • 首部字段Expires會將資源失效的日期告知客戶端运敢。緩存服務器在接收到含有首部字段Expires的響應后，會以緩存來應答請求忠售，在Expires字段值指定的時間之前传惠，響應的副本會一直被保存。當超過指定的時間后稻扬，緩存服務器在請求發(fā)送過來時卦方，會轉向源服務器請求資源。
  • 源服務器不希望緩存服務器對資源緩存時泰佳，最好在Expires字段內謝日與首部字段Date相同的時間值盼砍。
  • 但是尘吗，當首部字段Cache-Control有指定max-age指令時，比起首部字段Expires浇坐，會有限處理max-age指令摇予。

Last-Modified

IMG_0834.JPG

IMG_0835.PNG
  • 首部字段Last-Modified指明資源最終修改的時間。一般來說吗跋，這個值就是Request-URI指定資源被修改的時間侧戴。但類似使用CGI腳本進行動態(tài)數據處理時，改值有可能會變成數據最終修改時的時間跌宛。

6.7 為Cookie服務的首部字段

  • 管理服務器與客戶端之間狀態(tài)的Cookie酗宋，雖然沒有被編入標準化HTTP/1.1的RFC2616中，但在Web網站方面得到了廣泛的應用疆拘。
  • Cookie的工作機制是用戶識別及狀態(tài)管理蜕猫。Web汪涵為了管理用戶的狀態(tài)會通過Web瀏覽器，把一些數據臨時寫入用戶的計算機內哎迄。接著當用戶訪問該Web網站時回右，可通過通信方式取回之前存放的Cookie。
  • 調用Cookie時漱挚，由于可校驗Cookie的有效期翔烁，以及發(fā)送方的域、路徑旨涝、協(xié)議等信息蹬屹，所以正規(guī)發(fā)布的Cookie內的數據不會因來自為他Web站點和攻擊者的攻擊而泄漏。
  • Cookie的規(guī)格標準文檔有以下4種白华。
由網景公司頒布的規(guī)格標準
  • 網景通信公司設計并開發(fā)了Cookie慨默，并制定相關的規(guī)格標準。1994年前后弧腥，Cookie正式應用在網景瀏覽器中厦取。目前最為普及的Cookie方式也是以此為基準的。
RFC2109
  • 某公司嘗試以獨立技術對Cookie規(guī)格進行標準化統(tǒng)籌管搪。原本的意圖是想和網景公司制定的標準交互應用虾攻，可惜發(fā)生了微妙的差異。現在該標準已淡出了人們的視線抛蚤。
RFC2965
  • 為終結Internet Explorer瀏覽器與Netscape Navigator的標準差異而導致的瀏覽器戰(zhàn)爭台谢，RFC2965內定了新的HTTP首部Set-Cookie2和Cookie2寻狂。
RFC6265
  • 將網景公司制定的標準作為業(yè)界試試標準岁经，重新定義Cookie標準后的產物。
  • 目前使用最廣泛的Cookie標準缺不是RFC中定義的任何一個蛇券。而是在網景公司制定的標準上進行擴展后的產物缀壤。
  • 下面的表格內列舉了與Cookie相關的首部字段說明樊拓。
IMG_0836.JPG
IMG_0837.JPG

Set-Cookie

IMG_0838.PNG
  • 當服務器準備開始管理客戶端的狀態(tài)時，會事先告知各種信息塘慕。

  • 下面的表格列舉了Set-Cookie的字段值


    IMG_0839.JPG
expires屬性
  • Cookie的expires屬性指定瀏覽器可發(fā)送Cookie的有效期筋夏。
  • 當省略expires屬性時，其有效期僅限于維持瀏覽器回話時間段內图呢，這通常限于瀏覽器應用程序被關閉之前条篷。
  • 另外，一旦Cookie從服務器端發(fā)送至客戶端蛤织，服務器端就不存在可以顯示刪除Cookie的方法赴叹。但可通過覆蓋已過期的Cookie，實現對客戶端Cookie的實質性刪除操作指蚜。
path屬性
  • Cookie的path屬性可用于限制指定Cookie的發(fā)送范圍的文件目錄乞巧。不過另有辦法可避開這項限制，看來對其作為安全機制的效果不能抱有期待摊鸡。
domain屬性
  • 通過Cookie的domain屬性指定的域名可做到與結尾匹配一致绽媒。比如，當指定example.com后免猾，除example.com以外是辕，www.example.com或www2.example.com等都可以發(fā)送Cookie；
  • 因此猎提，除了針對具體指定的多個域名發(fā)送Cookie之外免糕，不指定domain屬性顯得更安全。
secure屬性
  • Cookie的secure屬性用于限制Web頁面僅在HTTP安全連接時忧侧，才可以發(fā)送Cookie石窑。
  • 發(fā)送Cookie時，指定secure屬性的方法如下所示
IMG_0840.PNG
  • 以上例子僅當在https://www.example.com/安全連接的情況下才會進行Cookie的回收蚓炬。也就是說松逊，即使域名相同，HTTP://www.example.com/也不會發(fā)生Cookie回收行為肯夏。
  • 當省略secure屬性時经宏，不論HTTP還是HTTPS，都會對Cookie進行回收驯击。
HttpOnly屬性
  • Cookie的HttpOnly屬性是Cookie的拓展功能烁兰，它使JavaScript腳本無法獲得Cookie。其主要目的為防止跨站腳本攻擊對Cookie的信息竊取徊都。
  • 發(fā)送指定HttpOnly屬性的Cookie的方法如下所示：
IMG_0841.PNG
  • 通過上述設置沪斟，通常從Web頁面內還可以對Cookie進行讀取操作。但使用JavaScript的document.cookie就無法讀取附加HttpOnly屬性后的Cookie的內容了暇矫，因此主之，也就無法在XSS中利用JavaScript劫持Cookie了择吊。
  • 雖然是獨立的拓展功能，但Internet Explorer 6 SPI以上版本等當下的主流瀏覽器都已經支持該拓展了槽奕，該拓展并非是為了防止XSS而開發(fā)的几睛。

Cookie

IMG_0842.PNG
  • 首部字段Cookie會告知服務器，當客戶端想獲得HTTP狀態(tài)管理支持時粤攒，就會在請求中包含從服務器接收到的Cookie所森。接收到多個Cookie時，同樣可以以多個Cookie形式發(fā)送夯接。

6.8 其他首部字段

  • HTTP首部字段是可以自行拓展的必峰。所以在Web服務器和瀏覽器的應用上，會出現各種非標準的首部字段钻蹬。
  • 接下來吼蚁，我們就一些最為常見的首部字段進行說明
    • X-Frame-Options
    • X-XXS-Protection
    • DNT
    • P3P

X-Frame-Options

IMG_0843.PNG
  • 首部字段X-Frame-Options屬于HTTP響應首部，用于控制網站內容在其他Web網站的Frame標簽內的顯示問題问欠。其主要目的是為了防止點擊劫持攻擊肝匆。
  • 首部字段X-Frame-Options有以下兩個可指定的字段值。
    • DENY：拒絕
    • SAMEORIGIN：僅同源域名下的頁面匹配時許可顺献。支持該首部字段的瀏覽器有Internet Explorer 8旗国、Firefox 3.6.9+、Chrome 4.1.249.1024+注整、Safari 4+和Opera 10.50+等能曾。
    • 能在所有的Web服務器端預先設定好X-Frame-Options字段值是最理想的狀態(tài)
對apache2.conf的配置實例
IMG_0844.PNG

X-XXS-Protection

IMG_0845.PNG
  • 首部字段X-XXS-Protection屬于HTTP響應首部，它是針對跨站腳本攻擊的一種對策肿轨，用于控制瀏覽器XSS防護機制的開關寿冕；
  • 首部字段X-XXS-Protection可指定的字段值如下：
    • 0：將XSS過濾設置成無效狀態(tài)
    • 1：將XSS過濾設置成有效狀態(tài)

DNT

IMG_0846.JPG
IMG_0847.PNG
  • 首部字段DNT屬于HTTP請求首部，其中DNT是Do Not Track的簡稱椒袍，意為拒絕個人信息被收集驼唱，是表示拒絕被精準廣告追蹤的一種方法。
  • 首部字段DNT可指定的字段值如下驹暑。
    • 0：同意被追蹤玫恳；
    • 1：不同意被追蹤；
    • 由于首部字段DNT的工鞥具備有效性优俘，所以Web服務器需要對DNT做對應的支持京办。

P3P

IMG_0848.PNG
  • 首部字段P3P屬于HTTP響應首部，通過利用P3P技術帆焕，可以讓Web網站上的個人隱私變成一種僅供程序可理解的形式惭婿，以達到保護用戶隱私的目的。
  • 要進行P3P的設定，需按一下操作步驟進行：
    • 步驟1：創(chuàng)建P3P隱私
    • 步驟2：創(chuàng)建P3P隱私對照文件后审孽，保存命名在/w3c/p3p.xml
    • 步驟3：從P3P隱私中新建Compactpolicies后县袱，輸出到HTTP響應中浑娜。

第七章 確保Web安全的HTTPS

7.1 HTTP的缺點

  • 到現在為止佑力，我們已了解到HTTP具有相當優(yōu)秀和方便的一面，然而HTTP并非只有好的一面筋遭，食物皆具兩面性打颤，它也是有不足之處的。
  • HTTP主要有這些不足漓滔，例如：
    • 通信使用明文编饺，內容可能會被竊聽
    • 不檢驗通信方的身份，因此有可能遭遇偽裝
    • 無法證明報文的完整性响驴，所以有可能已遭篡改
  • 這些問題不僅在HTTP上出現透且，其他未加密的協(xié)議中也會存在這類問題。
  • 除此之外豁鲤，HTTP本身還有很多缺點秽誊。而且，還有像某些特定的Web服務器和特定的Web瀏覽器在實際應用中存在的不足琳骡，另外锅论，用Java和PHP等變成語言開發(fā)的Web應用也可能存在安全漏洞。

通信使用明文可能會被竊聽

  • 由于HTTP本身不具備加密的功能楣号，所以也無法做到對通信整體進行加密最易。即，HTTP報文使用明文方式發(fā)送炫狱。
TCP/IP是可能被竊聽的網絡
  • 如果要問為什么通信時不加密是一個缺點藻懒，這是因為，按TCP/IP協(xié)議族的工作機制视译，通信內容在所有的通信線路上都有可能遭到窺視束析。
  • 所謂互聯網，是由能聯通到全世界的網絡組成的憎亚。無論世界哪個角落的服務器在和哭護短通信時员寇，在此通信線路上的某些網絡設備、光纜第美、計算機等都不可能是個人的私有物蝶锋，所以不排除某個環(huán)節(jié)中遭到惡意窺視的行為。
  • 即使已經過加密處理的通信什往，也會被窺視到通信內容扳缕，這點和未加密的通信是相同的。只是說如果通信經過加密，就有可能讓人無法皮杰報文信息的含義躯舔，但加密處理后的報文信息本身還是會被看到的驴剔。
圖：互聯網上的任何角落都存在通信內容被竊聽的風險.JPG
  • 窺視相同段上的通信并非難事。只需要手機在互聯網上流動的數據包就行了粥庄。對于收集來的數據包的解析工作丧失，可交給那些抓包或嗅探器工具。
  • 下面的圖片示例就是被廣泛使用的抓包工具Wireshark惜互。它可以獲取HTTP協(xié)議的請求和響應的內容布讹，并對其進行解析。
  • 像使用GET方法發(fā)送請求训堆、響應返回了200 OK描验，查看HTTP響應報文的全部內容等一系列的事情都可以做到。
IMG_0850.JPG
加密處理防止被窺視
  • 在目前大家正在研究的如何防止竊聽保護信息的幾種對策中坑鱼，最為普及的就是加密技術膘流。加密的對象可以有這么幾個。
通信的加密
  • 一種方式就是將通信加密鲁沥。HTTP協(xié)議中沒有加密機制呼股，但可以通過和SSL或TLS的組合使用，加密HTTP的通信內容黍析。
  • 用SSL建立安全通信線路之后卖怜，就可以在這條線路上進行HTTP通信了。與SSL組合使用的HTTP唄稱為HTTPS或HTTP over SSL阐枣。
IMG_0851.JPG
內容的加密
  • 還有一種將參與通信的內容本身加密的方式马靠。由于HTTP協(xié)議中沒有加密機制，那么就對HTTP協(xié)議傳輸的內容本身加密蔼两。即把HTTP報文里所含的內容進行加密處理甩鳄。
  • 在這種情況下，客戶端需要對HTTP報文進行加密處理后再發(fā)送請求额划。
IMG_0852.JPG
  • 為了做到有效的內容加密妙啃，前提是要求客戶端和服務器同事具備加密和解密機制。主要應用在Web服務中俊戳。有一點必須引起注意揖赴，由于該方式不同于SSL或TLS將這個通信線路加密處理，所以內容仍有被篡改的奉獻抑胎。

不驗證通信方的身份就可能遭遇偽裝

  • HTTP協(xié)議中的請求和響應不會對通信方進行確認燥滑。也就是說存在“服務器是否就是發(fā)送請求中HRI真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端”等類似問題阿逃。
任何人都可發(fā)起請求
  • 在HTTP協(xié)議通信時铭拧，由于不存在確認通信方的處理步驟赃蛛，任何人都可以發(fā)起請求。另外搀菩，服務器只要接收到請求呕臂，不管對方是誰都會返回一個相應。
IMG_0853.JPG
  • HTTP協(xié)議的實現本身非常簡單肪跋，不論是誰發(fā)送過來的請求都會返回響應歧蒋，因此不確認通信方，會存在以下各種隱患澎嚣。
    • 無法確定請求發(fā)送至目標的Web服務器是否是按真是意圖返回響應的那臺服務器疏尿，有可能是已偽裝的Web服務器。
    • 無法確定響應返回到的客戶端是否是按真是意圖接收響應的那個客戶端。有可能是已偽裝的客戶端忧饭。
    • 無法確定正在通信的對方是否具備訪問權限运悲。因為某些Web服務器上保存著重要的信息，只想發(fā)給特定用戶通信的權限书斜。
    • 無法判定請求是來自何方、出自誰手。
    • 即使是無意義的請求也會照單全收造寝。無法阻止海量請求下的DoS攻擊。
查明對手的證書
  • 雖然使用HTTP協(xié)議無法無額定通信方吭练，但如果使用SSL則可以诫龙。SSL不僅提供加密處理，而且還使用了一種被稱為證書的手段鲫咽，可用于確定方签赃。
  • 證書由值得信任的第三方機構頒發(fā)，用以證明服務器和客戶端是實際存在的分尸。另外锦聊，偽造證書從技術角度來說是異常困難的一件事，所以只要能夠確認通信方持有的證書箩绍，即可判斷通信方的真實意圖孔庭。
IMG_0854.JPG
  • 通過使用證書，以證明通信方就是意料中的服務器材蛛。這對使用者個人來講圆到，也減少了個人信息泄漏的危險性。
  • 另外卑吭，客戶端持有證書即可完成個人身份的確認芽淡，也可用于對Web網站的認證環(huán)節(jié)。

無法證明報文完整性陨簇，可能已遭篡改

  • 所謂完整性是指信息的準確度吐绵。若無法證明其完整性迹淌，通常也就意味著無法判斷信息是否準確。
接收到的內容可能有誤
  • 由于HTTP協(xié)議無法證明通信的報文完整性己单，因此唉窃，在請求或響應送出之后直到對方接收之前的這段時間內，即使請求或響應的內容遭到篡改纹笼，也沒有辦法獲悉纹份。
  • 換句話說，沒有任何辦法確認廷痘，發(fā)出的請求/響應和接收到的請求/請求是前后相同的蔓涧。
IMG_0855.JPG
  • 比如，從某個Web網站上下載內容笋额，是無法確定客戶端下載的文件和服務器上存放的文件是否前后一致的元暴。文件內容在傳輸途中可能已經被篡改為其他的內容。即使內容真的已改變兄猩，作為接收方的客戶端也是覺察不到的茉盏。
  • 像這樣，請求或響應再傳輸途中枢冤，遭攻擊者攔截并篡改內容的攻擊稱為中間人攻擊鸠姨。
圖：中間人攻擊.JPG
如何防止篡改
  • 雖然是使用HTTP協(xié)議確定報文完整性的方法，但事實上并不編輯淹真、可靠讶迁。其中常用的是MD5和SHA-1等散列值校驗的方法，已經用來確認文件的數組簽名方法核蘸。
IMG_0857.JPG
  • 提供文件下載服務的Web網站也會提供相應的以PGP創(chuàng)建的數字簽名及MD5算法生成的散列值巍糯。PGP是用來證明創(chuàng)建文件的數字簽名，MD5是由單項函數生成的散列值值纱。不論使用哪一種方法鳞贷，都需要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務器上的文件。瀏覽器無法自動幫用戶檢查虐唠。
  • 可惜的是搀愧，用這些方法也依然無法百分百保證確認結果正確。因為PGP和MD5本身唄改寫的話疆偿，用戶就沒有辦法意識到的咱筛。
  • 為了有效防止這些弊端，有必要使用HTTPS杆故。SSL提供認證和加密處理及摘要功能迅箩。僅靠HTTP確保完整性是非常困難的，因此通過和其他協(xié)議組合使用來實現這個目標处铛。

7.2 HTTP + 加密 + 認證 + 完整性保護 = HTTPS

HTTP加上加密處理和認證以及完整性保護后即是HTTPS

  • 如果在HTTP協(xié)議通信過程中使用未經加密的明文饲趋，比如在Web頁面中輸入信用卡號拐揭，如果這條通信線路遭到竊聽，那么信用卡號就暴露了奕塑。
  • 另外堂污，對于HTTP來說，服務器也好龄砰，客戶端也好盟猖，都是沒有辦法確認同新方的。因為很有可能并不是和原本預想的同新方在實際通信换棚。并且還需要考慮到接收到的報文在通信途中已經遭到篡改這一可能性式镐。
  • 為了統(tǒng)一解決上述這些問題，需要在HTTP再加上加密處理和認證等機制固蚤。我們把增加了加密及認證機制的HTTP稱為HTTPS娘汞。
IMG_0858.JPG
  • 經常會在Web的登錄頁面和購物結算界面等使用HTTPS通信，使用HTTPS通信時颇蜡，不再用http://价说，而是改用http://辆亏。另外风秤，當瀏覽器訪問HTTPS通信有效的Web網站時，瀏覽器的地址欄內會出現一個帶鎖的標記扮叨。對HTTPS通信有效的Web網站時缤弦，瀏覽器的地址欄內出現一個帶鎖的標記。對HTTPS的顯示方式會因瀏覽器的不同而有所改變彻磁。
IMG_0859.JPG

HTTPS是身披SSL外殼的HTTP

  • HTTPS并非是應用層的一種新協(xié)議碍沐。只是HTTP通信接口部分用SSL和TLS協(xié)議代替而已。
  • 通常衷蜓，HTTP直接和TCP通信累提。當使用SSL時，則演變成先和SSL通信磁浇，再由SSL和TCP通信了斋陪。簡言之，所謂HTTPS置吓，其實就是身披SSL協(xié)議這層外殼的HTTP无虚。
IMG_0860.JPG
  • 在采用SSL后，HTTP就擁有了HTTPS的加密衍锚、證書和完整性保護這些功能友题。
  • SSL是獨立于HTTP的協(xié)議，所以不光是HTTP協(xié)議戴质，其他運行在應用層的SMTP和Telnet等協(xié)議均可配合SSL協(xié)議使用度宦√呦唬可以說SSL是當今世界上應用最為廣泛的網絡安全技術。

相互交換秘鑰的公開秘鑰加密技術

  • 在堆SSL進行講解之前戈抄，我們先來了解一下加密方法符糊。SSL采用一種叫做公開秘鑰加密的加密處理方式。
  • 近代的加密方法中加密算法是公開的呛凶，而秘鑰卻是保密的男娄。通過這種方式得以保持加密方法的安全性。
  • 加密和解密都會用到密鑰漾稀。沒有密鑰就無法對棉麻解密模闲，翻過來說，任何人只要持有密鑰就能解密了崭捍。如果密鑰被攻擊者獲得尸折，那加密也就失去了意義。
共享密鑰加密的困境
  • 加密和解密同用一個密鑰的方式稱為共享密鑰加密殷蛇，也被叫做對稱密鑰加密
IMG_0861.JPG
  • 以共享密鑰方式加密時必須將密鑰也發(fā)給對方实夹。可究竟怎樣才能安全地轉交粒梦？在互聯網上轉發(fā)密鑰時亮航，如果通信被監(jiān)聽那么密鑰就可會落入攻擊者之手，同時也就失去了加密的意義匀们。另外還得設法安全地保管接收到的密鑰缴淋。
IMG_0862.JPG
使用兩把密鑰的公開密鑰加密
  • 公開密鑰加密方式很好地解決了共享密鑰加密的困難。
  • 公開密鑰加密使用一對非對稱的密鑰泄朴。一把叫做私有密鑰重抖，另一把叫做公開密鑰。顧名思義祖灰，私有密鑰不能讓其他任何人知道钟沛，而公開密鑰則可以隨意發(fā)布，任何人都可以獲得局扶。
  • 使用公開密鑰加密方式恨统，發(fā)送密文的一方受用對方的公開密鑰進行加密處理，對方收到被加密的信息后详民，再使用自己的私有密鑰進行解密延欠。利用這種方式，不需要發(fā)送用來解密的私有密鑰沈跨，也不必擔心密鑰被攻擊者竊聽而盜走由捎。
  • 另外，要想根據密文和公開密鑰饿凛，恢復到信息原文是異常困難的狞玛，因為解密過程就是在對離散對數進行求值软驰，這并非輕而易舉就能辦到。退一步講心肪，如果能對一個非常大的證書做到快速地因式分解锭亏，那么密鑰破解還是存在希望的。但就目前的技術來看是不太現實的硬鞍。
IMG_0863.JPG
HTTPS采用混合加密機制
  • HTTPS采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機制慧瘤。若密鑰能夠實現安全交換，那么有可能會考慮僅使用公開密鑰加密來通信固该。但是公開密鑰加密與共享密鑰加密相比锅减，其處理速度要慢。
  • 所以應充分利用兩者各自的優(yōu)勢伐坏，將多種方法組合起來用于通信怔匣，在交換密鑰環(huán)節(jié)使用公開密鑰加密方式，之后的簡歷通信交換報文階段則使用共享密鑰加密方式桦沉。
IMG_0864.JPG

證明公開秘鑰正確性的證書

  • 遺憾的是每瞒，公開密鑰加密方式還是存在一些問題的。那就是無法證明公開密鑰本身就是貨真價實的公開密鑰纯露。比如剿骨，正準備和某臺服務器建立公開密鑰加密方式下的通信時，如果證明收到的公開密鑰就是原本預想的那臺服務器發(fā)行的公開密鑰苔埋∨成埃或許在公開密鑰傳輸途中，真正的公開密鑰已經被攻擊者替換掉了组橄。
  • 為了解上述問題，可以使用由數字證書認證記否和其相關機關頒發(fā)的公開密鑰證書罚随。
  • 數字證書認證機構處于客戶端與服務器雙方都可信賴的第三方機構的立場上玉工。威瑞信就是其中一家非常有名的數字證書認證機構，我們來接胡搜啊一下數字證書認證機構的業(yè)務流程淘菩。首先遵班，服務器的運營人員向數字證書認證機構提出公開密鑰的請求。數字證書認證機構在判明提出申請者的身份之后潮改，會對已申請的公開密鑰做數字簽名狭郑，然后分配這個已簽名的公開木遙，并將該公開密鑰放入公鑰證書后綁定在一起汇在。
  • 服務器會將這份由數字證書認證機構頒發(fā)的公鑰證書發(fā)送給客戶端翰萨，以進行公開密鑰加密方式通信。公鑰證書也可叫做數字證書或直接成為證書糕殉。
  • 接到證書的客戶端可使用數字證書認證機構的公開密鑰亩鬼，對那張證書上的數字簽名進行驗證殖告，一旦驗證通過，客戶端便可明確兩件事：一雳锋，認證服務器的公開密鑰的是真實有效的數字證書認證機構黄绩。二，服務器的公開密鑰是值得信賴的玷过。
  • 此處認證機構的公開密鑰必須安全地轉交給客戶端爽丹。使用通信方式時，如何安全轉交是一件很苦難的事辛蚊，因此习劫，多數瀏覽器開發(fā)商發(fā)布版本時，會事先在內部植入常用認證機關的公開密鑰
IMG_0865.JPG
IMG_0866.JPG
可證明組織真實性的EV SSL證書
  • 證書的一個作用是用來證明作為通信一方的服務器是否規(guī)范嚼隘，另外一個作用是可確認對方服務器背后運營的企業(yè)是否真實存在诽里。擁有改特性的證書就是EV SSL證書。
  • EV SSL證書是基于國際標準的認證知道方針辦法的證書飞蛹。其嚴格規(guī)定了對運營組織是否真實的確認方針谤狡，因此，通過認證的Web網站能夠獲得更高的認可度卧檐。持有EV SSL證書的Web網站的瀏覽器地址欄處的背景色是綠色的墓懂，從視覺上就能一眼辨別出。而且在地址欄的左側顯示了SSL證書中記錄的組織名稱以及辦法證書的認證機構的名稱霉囚；

  • 上述機制的愿意圖是為了防止用戶被釣魚攻擊捕仔，但就效果上來講，還得打一個問號盈罐。


    IMG_0867.JPG
用以確認客戶端的客戶端證書
  • HTTPS中還可以使用客戶端證書榜跌。以客戶端證書進行客戶端認證，證明服務器正在通信的對方始終是預料之內的客戶端盅粪，其作用跟服務器證書如出一轍钓葫。
  • 但客戶端證書扔存在幾處問題點。其中的一個問題點是證書的獲取及法本票顾。
  • 想獲取證書時础浮，用戶得自行安裝客戶端證書。但由于客戶端證書是要付費購買的奠骄，且沒漲生疏對應到每位用戶也就以為著需支付和用戶數對等的費用豆同。另外，要讓知識層次不同的用戶們自行安裝證書含鳞，這件事本身也充滿了各種挑戰(zhàn)影锈。
  • 現狀是，安全性極高的認證機構可頒發(fā)客戶端證書但僅用于特殊用途的業(yè)務，比如那些可制成客戶端證書支出費用的業(yè)務精居。
  • 客戶端證書存在的另一個問題點是锄禽，客戶端證書畢竟只能用來證明客戶端實際存在，兒不能用來證明用戶本人的真實有效性靴姿，也就是說沃但，只要獲得了安裝有客戶端證書的計算機的使用權限，也就意味著同時擁有了客戶端證書的使用權限佛吓。
認證機構信譽第一
  • SSL機制中介入認證機構之所以可行宵晚，是因為建立在其信用絕對可靠這一大前提下的。然而维雇，2011年7月淤刃，荷蘭的一家名叫DigiNotar的認證機構曾遭黑客不法入侵，頒布了google.com和witter.com等網站的偽造證書時間吱型。這一時間從根本上撼動了SSL的可信度逸贾。
  • 因為偽造證書上有正規(guī)認證機構的數字簽名，所以瀏覽器會判定該證書是正當的津滞。當偽造的證書被用做服務器偽裝之時铝侵，用戶根本無法察覺到。
  • 雖然存在可將證書無效化的證書吊銷列表機制触徐，以及從客戶端闡述根證書頒發(fā)機構的對策烤礁，但是距離生效還需要一段時間神得，而在這段時間內盒粮，到底會有多少用戶的利益蒙受損失不得而知了余黎。
由自認證機構頒發(fā)的認證稱為自簽名證書
  • 如果使用OpenSSL這套開源程序，每個人都可以構建一套屬于自己的認證機構鸟雏，從而自己給自己頒發(fā)服務器證書享郊，但該服務器證書在互聯網上不可作為證書使用，似乎沒什么幫助崔慧。
  • 獨立構建的認證機構叫做自認證記否拂蝎，由自認證機構頒發(fā)的“無用”證書也被戲稱為自簽名證書。

  • 瀏覽器訪問該服務器時惶室，會顯示“無法確認連接安全性”或“該網站的安全證書存在問題”等警告消息。


    IMG_0868.JPG
  • 由自認證機構頒發(fā)的服務器證書之所以不起作用玄货，是因為它無法消除偽裝的可能性皇钞，自認證機構能夠產生的作用頂多也就是自己對外宣稱“我是**”的這種程度。即使采用自簽名證書松捉，通過SSL加密之后夹界，可能偶爾還會看見通信處在安全狀態(tài)的提示，可那也是有問題的隘世。因為就算加密通信可柿，也不能排除正在和已經過偽裝的假服務器保持通信鸠踪。
  • 值得信賴的第三方機構介入認證，才能讓已植入在瀏覽器內的認證機構頒布的公開密鑰發(fā)揮作用复斥，并借此證明服務器的真實性营密。
  • 中級認證機構的證書可能會變成自認證證書
  • 多數瀏覽器內預先已植入備受新來的認證機構的證書，但也有一小部分瀏覽器會植入中級認證機構的證書目锭；
  • 對于中級認證機構頒布的服務器證書评汰，某些瀏覽器會以正規(guī)的證書來對待，可有的瀏覽器會當做自簽名證書痢虹。

HTTPS的安全通信機制

  • HTTPS的通信步驟


    IMG_0869.JPG
  • 步驟1：
    • 客戶端通過發(fā)送Client Hello報文開始SSL通信被去。報文中包含客戶端支持的SSL的指定版本、加密組件列表奖唯。
  • 步驟2：
    • 服務器可進行SSL通信時惨缆，會以Server Hello報文作為應答。和客戶端一樣丰捷，在報文中包含SSL版本以及加密組件坯墨。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
  • 步驟3：
    • 之后服務器發(fā)送Certificate報文.報文中包含公開密鑰證書.
  • 步驟4：
    • 最后服務器發(fā)送Server Hello Done報文通知客戶端瓢阴，最初剪短的SSL握手協(xié)商部分結束畅蹂。
  • 步驟5：
    • SSl第一次握手結束之后，客戶端以Xlient Key Exchange報文作為回應荣恐。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串液斜。該報文已用步驟3中的公開密鑰進行加密。
  • 步驟6：
    • 接著客戶端繼續(xù)發(fā)送Change Cipher Spec報文叠穆。該報文會提示服務器少漆，在此報文之后的通信會采用Pre-master secret密鑰加密；
  • 步驟7：
    • 客戶端發(fā)送Finished報文硼被。該報文包含連接至今全部報文的整體校驗值示损。這次握手協(xié)商是否能夠成功，要以服務器是否能夠正確解密改報文作為判定標準嚷硫。
  • 步驟8：
    • 服務器同樣發(fā)送Change Cipher Spec報文检访。
  • 步驟9：
    • 服務器同樣發(fā)送Finished報文。
  • 步驟10：
    • 服務器和客戶端的Finished報文交換完畢之后仔掸，SSL連接就算簡歷完成脆贵。當然，通信會受到SSL的保護起暮。從此處開始進行應用層協(xié)議的通信卖氨，即發(fā)送HTTP請求。
  • 步驟11：
    • 應用層協(xié)議通信，即發(fā)送HTTP響應筒捺。
  • 步驟12：
    • 最后由客戶端斷開連接柏腻。斷開連接時，發(fā)送close_notify報文系吭。上圖做了一些省略五嫂，這步之后再發(fā)送TCPFIN報文來關閉與TCP的通信。在以上流程中村斟，應用層發(fā)送數據時會附加一種叫做MAC的報文摘要贫导。MAC能夠查知報文是否遭到篡改，從而保護報文的完整性蟆盹。

  • 下面是對整個流程的圖解孩灯，途中說明了從僅使用服務器端的公開密鑰證書簡歷HTTPS通信的整個過程。


    IMG_0870.JPG
SSL和TLS
  • HTTPS使用SSL和TLS這兩個協(xié)議逾滥。
  • SSL技術最初是由瀏覽器開發(fā)商網景通信公司率先倡導的峰档，開發(fā)過SSL3.0之前的版本。目前主導權已轉移到IETF的手中寨昙。
  • IETF以SSL3.0為基準讥巡，后又制定了TLS1.0、TLS1.1和TLS1.2.TSL是以SSL為原型開發(fā)的協(xié)議舔哪，有時會統(tǒng)一稱該協(xié)議為SSL欢顷。當前主流的版本是SSL3.0和TLS1.0.
  • 由于SSL1.0版本在設計之初被發(fā)現出了問題，就沒有實際投入使用≥SSL2.0也被發(fā)現存在問題捉蚤，所以很多瀏覽器直接飛出了改協(xié)議版本抬驴。
SSL速度慢嗎
  • HTTPS也存在一些問題，那就是當使用SSL時缆巧，他的處理速度會變慢布持。
IMG_0871.JPG
  • SSL的慢分兩種。一種是指通信慢陕悬。另一種是指由于大量消耗CPU及內存等資源题暖，導致處理速度變慢。
  • 和使用HTTP相比捉超，網絡負載可能會變慢2到100倍胧卤。出去和TCP連接、發(fā)送HTTP請求-響應以外拼岳，還必須進行SSL通信灌侣，因此整體上處理通信量不可避免會增加。
  • 另一點是SSL必須進行加密處理裂问。在服務器和客戶端都需要進行加密和解密的運算處理。因此從結果上講，比起HTTP會更多地消耗服務器和客戶端的硬件資源堪簿，導致負載增強痊乾。
  • 針對速度變慢這一問題，并沒有根本性的解決方案椭更，我們會使用SSL加速器這種硬件來改善該問題哪审。該硬件為SSL通信專用硬件，相對軟件來講虑瀑，能夠提高數倍SSL的計算速度湿滓。僅在SSL處理時發(fā)揮SSL加速器的功效，以分擔負載舌狗。
為什么不一直使用HTTPS
  • 既然HTTPS那么安全可靠叽奥，那為何所有的Web網站不一直使用HTTS？
  • 其中一個原因是痛侍，因為與純文本通信相比朝氓，加密通信會消耗更多的CPU及內存資源。如果每次通信都加密主届，會消耗相當多的資源赵哲，平攤到一臺計算機上時，能夠處理的請求數量必定也會隨之減少君丁。
  • 因此枫夺，如果是非敏感信息則使用HTTP通信，只有在包含個人信息等敏感數據時绘闷，才利用HTTPS加密通信橡庞。
  • 特別是每當那些訪問量較多的Web網站在進行加密處理時，他們所承擔著的負載不容小窺簸喂。毙死、在進行加密處理時，并非對所有內容都進行加密處理喻鳄，而是僅在那些需要信息隱藏時才會加密扼倘，以節(jié)約資源。
  • 除此之外除呵，想要節(jié)約購買證書的開銷也是原因之一再菊。
  • 要進行HTTPS通信，證書是必不可少的颜曾。而使用的證書必須向認證機構購買纠拔，證書價格可能會格局不同的認證機構略有不同。

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

8.1 何為認證

  • 計算機本身無法判斷坐在顯示器前的使用者的身份泛豪。進一步說稠诲，也無法確認網絡的那頭究竟有誰侦鹏。可見臀叙，為了弄清究竟是誰在訪問服務器略水，就得讓對方的客戶端自報家門。
  • 可是劝萤，就算正在訪問服務器的對方聲稱自己的ueno渊涝，身份是否屬實這點卻也無從談起。為確認ueno本人是否真的具有訪問系統(tǒng)的權限床嫌，就需要核對“登錄者本人才知道的信息”跨释、“登錄者本人才會有的信息”；
  • 核對的信息通常是指一下這些：
    • 密碼：只有本人才會知道的字符串信息厌处。
    • 動態(tài)令牌：僅限本人持有的設備內顯示的一次性密碼鳖谈；
    • 數字證書：僅限本人持有的信息。
    • 生物認證：指紋和虹膜等本人的生理信息嘱蛋。
    • IC卡等：僅限本人持有的信息
IMG_0872.JPG
  • 但是蚯姆，即便對方是假冒的用戶，只要能通過用戶驗證洒敏，那么計算機就會默認是出自本人的行為龄恋。因此，掌控機密信息的密碼絕不能讓他人得到凶伙，更不能輕易地就被破解出來郭毕。
  • HTTP使用的認證方式
    • HTTP/1.1使用的認證方式如下所示。
      • BASIC認證（基本認證）
      • DIGEST認證（摘要認證）
      • SSL客戶端認證
      • FormBase認證（基于表單認證）
    • 此外函荣，還有Windows統(tǒng)一認證（Keberos認證显押、NTLM認證）；

8.2 BASIC認證

  • BASIC認證（基本認證）是從HTTP/1.0就定義的認證方式傻挂。即便是現在仍有一部分的網站會使用這種認證方式乘碑。是Web服務器與通信客戶端之前進行的認證方式。

BASIC認證的認證步驟

IMG_0873.JPG

  • 步驟1：

    • 當請求的資源需要BASIC認證時金拒，服務器會隨時狀態(tài)碼401 Authorization Required兽肤，返回帶WWW-Authenticate首部字段的響應。該字段內包含認證的方式（BASIC）及Request-URI安全域字符串绪抛。

  • 步驟2：

    • 接收到狀態(tài)碼401的客戶端為了通過BASIC認證资铡，需要將用戶ID及密碼發(fā)送給服務器。發(fā)送的字符串內容是由用戶ID和密碼構成幢码，兩者中間以冒號（：）連接后笤休，再經過Base64編碼處理。假設用戶ID未guest症副，密碼是guest店雅，連接起來就會形成guest：guest這樣的字符串政基。然后經過Base64編碼，最后的結果即是Z3Vlc3Q6Z3VQ=底洗。把這串字符串寫入首部字段Authorization后腋么，發(fā)送請求。當用戶代理為瀏覽器時亥揖，用戶僅需輸入用戶ID和密碼即可，之后圣勒，瀏覽器會自動完成到BASE64編碼的轉換工作费变。


      IMG_0874.JPG

  • 步驟3：

    • 接收到包含首部字段Authorization請求的服務器，會對認證信息的正確性進行驗證圣贸。如驗證通過挚歧，則返回一條包含Requset-URI資源的響應
    • BASIC認證雖然采用Base64編碼方式，但這不是加密處理吁峻。不需要任何附加信息即可對其解碼滑负。換言之，由于明文解碼后就是用戶ID和密碼用含，在HTTP等非加密通信的線路上進行BASIC認證的過程中矮慕，如果被人竊聽，被盜的可能性極高啄骇。
    • 另外痴鳄，除此之外想再進行一次BASIC認證時，一般的瀏覽器卻不乏實現認證注銷操作缸夹，這也是問題之一痪寻。
    • BASIC認證使用上不夠便捷靈活，且達不到多次Web往回走哪期望的安全性等級虽惭，因此它并不常用橡类。

8.3 DIFEST認證

  • 為彌補BASIC認證存在的弱點，從HTTP/1.1起就有了DIGEST認證芽唇。DIGEST認證同樣使用質詢/響應的方式顾画，但不會像BASIC認證那樣直接發(fā)送明文密碼。

  • 所謂質詢響應方式是指披摄，一開始一方會發(fā)送認證要求給另一方亲雪，接著使用從另一方那接收到的質詢碼計算生成響應碼。最后將響應碼返回給對方進行認證的方式疚膊。


    IMG_0875.JPG

  • 因此方法給對方的只是響應摘要及由質詢碼產生的計算結果义辕，所以比起B(yǎng)ASIC認證，面膜企鵝樓的可能性就降低了寓盗。

DIFEST認證的認證步驟

IMG_0876.JPG

8.4 SSL客戶端認證

SSL客戶端認證的認證步驟

SSL客戶端認證采用雙因素認證

SSL客戶端認證必要的費用

8.5 基于表單認證

認證多半未基于表單認證

Session管理及Cookie應用

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

最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 人面猴
    序言：七十年代末灌砖，一起剝皮案震驚了整個濱河市璧函，隨后出現的幾起案子，更是在濱河造成了極大的恐慌基显，老刑警劉巖蘸吓，帶你破解...
    沈念sama閱讀 207,113評論 6贊 481
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現場離奇詭異撩幽，居然都是意外死亡库继，警方通過查閱死者的電腦和手機，發(fā)現死者居然都...
    沈念sama閱讀 88,644評論 2贊 381
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門窜醉，熙熙樓的掌柜王于貴愁眉苦臉地迎上來宪萄，“玉大人，你說我怎么就攤上這事榨惰“萦ⅲ” “怎么了？”我有些...
    開封第一講書人閱讀 153,340評論 0贊 344
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵琅催，是天一觀的道長居凶。 經常有香客問我，道長藤抡，這世上最難降的妖魔是什么侠碧？ 我笑而不...
    開封第一講書人閱讀 55,449評論 1贊 279
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮杰捂，結果婚禮上舆床，老公的妹妹穿的比我還像新娘。我一直安慰自己嫁佳，他們只是感情好挨队，可當我...
    茶點故事閱讀 64,445評論 5贊 374
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著蒿往，像睡著了一般盛垦。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上瓤漏，一...
    開封第一講書人閱讀 49,166評論 1贊 284
  • 城市分裂傳說
    那天腾夯，我揣著相機與錄音，去河邊找鬼蔬充。 笑死蝶俱，一個胖子當著我的面吹牛，可吹牛的內容都是我干的饥漫。 我是一名探鬼主播榨呆，決...
    沈念sama閱讀 38,442評論 3贊 401
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼庸队！你這毒婦竟也來了积蜻？” 一聲冷哼從身側響起闯割，我...
    開封第一講書人閱讀 37,105評論 0贊 261
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎竿拆，沒想到半個月后宙拉，有當地人在樹林里發(fā)現了一具尸體，經...
    沈念sama閱讀 43,601評論 1贊 300
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡丙笋，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 36,066評論 2贊 325
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年谢澈，在試婚紗的時候發(fā)現自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片不见。...
    茶點故事閱讀 38,161評論 1贊 334
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡雅任，死狀恐怖傲茄，靈堂內的尸體忽然破棺而出菊霜，到底是詐尸還是另有隱情蔽午，我是刑警寧澤好芭，帶...
    沈念sama閱讀 33,792評論 4贊 323
  • ?日本核電站爆炸內幕
    正文 年R本政府宣布蚁孔，位于F島的核電站睬魂，受9級特大地震影響模庐，放射性物質發(fā)生泄漏瑞你。R本人自食惡果不足惜酪惭，卻給世界環(huán)境...
    茶點故事閱讀 39,351評論 3贊 307
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望者甲。 院中可真熱鬧春感，春花似錦、人聲如沸虏缸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,352評論 0贊 19
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽刽辙。三九已至窥岩，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間宰缤，已是汗流浹背颂翼。 一陣腳步聲響...
    開封第一講書人閱讀 31,584評論 1贊 261
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留慨灭，地道東北人朦乏。 一個月前我還...
    沈念sama閱讀 45,618評論 2贊 355
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像氧骤，于是被迫代替她去往敵國和親呻疹。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當晚...
    茶點故事閱讀 42,916評論 2贊 344

推薦閱讀更多精彩內容

  • 本文是《圖解HTTP》讀書筆記的第二篇语淘，主要包括此書的第六章內容诲宇，因為第六章的內容較多际歼，而且比較重要，所以單獨寫為...
    lijiankun24閱讀 1,357評論 0贊 6
  • HTTP 首部 1. HTTP 報文首部 HTTP 協(xié)議的請求和響應報文中必定包含 HTTP 首部姑蓝，首部內容為客戶...
    13kmsteady閱讀 379評論 0贊 2
  • 作者：李成文鹅心；標簽: http首部 HTTP報文首部 HTTP協(xié)議的請求和響應報文中必定包含HTTP首部。首部內容...
    廣州蘆葦科技web前端閱讀 1,087評論 0贊 0
  • 1. HTTP報文首部 HTTP協(xié)議的請求和響應報文中必定包含HTTP首部纺荧。首部內容為客戶端和服務器分別處理請求和...
    笙繩省盛閱讀 1,790評論 0贊 5
  • HTTP 首部 HTTP 報文首部 HTTP 協(xié)議的請求和響應報文中必定包含 HTTP 首部旭愧。首部內容為客 戶端和...
    Gu_Ran閱讀 741評論 0贊 3