• 靚仔靚女們大家好，我們又見(jiàn)面了，：java小杰要加油，這周來(lái)分享一篇關(guān)于HTTP協(xié)議相關(guān)的文章
• 看完此文可以對(duì)
  • HTTP報(bào)文格式、HTTP各種請(qǐng)求頭，HTTP響應(yīng)碼、 cookie屬性以及HTTPS為什么安全（涉及到三種加密方式） 有個(gè)清晰的認(rèn)知
• 全文五千來(lái)字，強(qiáng)烈建議收藏，鞏固基礎(chǔ)
• 若文中涉及到的知識(shí)點(diǎn)有所偏差的話，還請(qǐng)大佬們指出，小杰感激不盡，沖沖沖！~

• 話不多說(shuō)，直接開(kāi)搞

HTTP簡(jiǎn)介

• 超文本傳輸協(xié)議（Hypertext Transfer Protocol，HTTP）是一個(gè)簡(jiǎn)單的請(qǐng)求-響應(yīng)協(xié)議，它通常運(yùn)行在TCP之上。它指定了客戶(hù)端可能發(fā)送給服務(wù)器什么樣的消息以及得到什么樣的響應(yīng)
• 現(xiàn)在主要應(yīng)用 http1.1 協(xié)議
• http是無(wú)狀態(tài)協(xié)議，不會(huì)保存多次請(qǐng)求之間的關(guān)系，使用cookie做狀態(tài)管理
• 持久連接節(jié)省通信量（HTTP1.1和部分HTTP1.0）
• 通過(guò)請(qǐng)求方法告知服務(wù)器意圖，get,post等

HTTP報(bào)文

• 用于HTTP協(xié)議交互的信息叫做HTTP報(bào)文
• 報(bào)文由報(bào)文首部和報(bào)文主體來(lái)組成，其中由空行分割
• 請(qǐng)求報(bào)文和響應(yīng)報(bào)文的報(bào)文結(jié)構(gòu)不一樣，其中最大的區(qū)別就是在報(bào)文首部中，各有各的特定的首部

image

• 報(bào)文首部：服務(wù)器或者客戶(hù)端需要處理的請(qǐng)求或者響應(yīng)的內(nèi)容及其屬性
• 報(bào)文主體：被發(fā)送的數(shù)據(jù)

HTTP請(qǐng)求報(bào)文結(jié)構(gòu)

• 由客戶(hù)端發(fā)送的報(bào)文叫做請(qǐng)求報(bào)文

image

• 請(qǐng)求行：包含用于請(qǐng)求的方法，請(qǐng)求URI和HTTP版本
• 請(qǐng)求首部字段：請(qǐng)求報(bào)文里特有的字段（后文會(huì)提到）
• 通用首部字段：請(qǐng)求報(bào)文和響應(yīng)報(bào)文都會(huì)用到的首部
• 實(shí)體首部字段：針對(duì)請(qǐng)求報(bào)文的實(shí)體部分使用的首部
• 其他：可能包含HTTP的RFC里未定義的首部（如Cookie等）

HTTP響應(yīng)報(bào)文結(jié)構(gòu)

• 由服務(wù)端發(fā)送的報(bào)文叫做響應(yīng)報(bào)文

image

• 狀態(tài)行：包含表明響應(yīng)結(jié)果的狀態(tài)碼，原因短語(yǔ)和HTTP版本
• 響應(yīng)首部字段：響應(yīng)報(bào)文里特有的字段（后文會(huì)提到）
• 通用首部字段：請(qǐng)求報(bào)文和響應(yīng)報(bào)文都會(huì)用到的首部
• 實(shí)體首部字段：針對(duì)響應(yīng)報(bào)文的實(shí)體部分使用的首部
• 其他：可能包含HTTP的RFC里未定義的首部（如Set-Cookie等）

注：若HTTP首部字段重復(fù)了的話，不同的瀏覽器處理機(jī)制不一樣

• 有些瀏覽器會(huì)優(yōu)先處理第一次出現(xiàn)的字段
• 有些瀏覽器會(huì)優(yōu)先處理最后一次出現(xiàn)的字段

HTTP響應(yīng)碼

2xx 成功

2xx的響應(yīng)結(jié)果就代表請(qǐng)求被正常處理了

• 200 OK：表示客戶(hù)端發(fā)來(lái)的請(qǐng)求被服務(wù)器正常處理了
• 204 Not Content:請(qǐng)求被成功處理，但是返回的響應(yīng)報(bào)文不包含實(shí)體的主體部分
• 206 Partial Content:客戶(hù)端進(jìn)行范圍請(qǐng)求，而服務(wù)器重新執(zhí)行了這部分的GET請(qǐng)求

3xx 重定向

3xx的響應(yīng)結(jié)果就表明瀏覽器需要執(zhí)行某些特殊的處理以正確處理請(qǐng)求

• 301 Moved Permanently：永久重定向。表示請(qǐng)求的資源已經(jīng)被分配了新的URI，以后應(yīng)該使用新的URI
• 302 Found:臨時(shí)重定向。代表資源只是暫時(shí)的移動(dòng)了以后還可能會(huì)移動(dòng)為新的URI
• 303 See Other:由于請(qǐng)求對(duì)應(yīng)的資源存在著另一個(gè)URI，應(yīng)使用GET方法定向獲取請(qǐng)求的資源
• 304 Not Modified:客戶(hù)端發(fā)送附帶條件（請(qǐng)求首部中if開(kāi)頭的屬性中的一種）的請(qǐng)求的時(shí)候，服務(wù)端允許訪問(wèn)資源，但是那些請(qǐng)求并沒(méi)有滿(mǎn)足，直接返回304，即服務(wù)端資源未改變，可以直接使用客戶(hù)端未過(guò)期的緩存，304返回時(shí)，不包含任何響應(yīng)的主體部分（雖然被劃分為3xx里，但是和重定向沒(méi)有任何關(guān)系）

4xx 客戶(hù)端錯(cuò)誤

4xx的響應(yīng)結(jié)果就表明客戶(hù)端是發(fā)生錯(cuò)誤的原因所在

• 400 Bad Requset：請(qǐng)求報(bào)文中存在語(yǔ)法錯(cuò)誤，請(qǐng)修改請(qǐng)求內(nèi)容后再發(fā)送請(qǐng)求
• 401 Unauthorized:客戶(hù)端未認(rèn)證授權(quán)
• 403 Forbidden:服務(wù)端禁止客戶(hù)端訪問(wèn)此資源
• 404 Not Found:URL寫(xiě)錯(cuò)了，找不到此路徑

5xx 服務(wù)器錯(cuò)誤

5xx的響應(yīng)結(jié)果就表明服務(wù)器本身發(fā)生錯(cuò)誤

• 500 Internal Server Error：服務(wù)器內(nèi)部故障，可能是bug導(dǎo)致的
• 503 Service Unavaliable：服務(wù)器暫時(shí)不可用（停機(jī)維護(hù)或者超負(fù)載），如果事先知道解除這種情況所需的時(shí)間，最好寫(xiě)入響應(yīng)頭中的Retry-After這個(gè)字段再返回給客戶(hù)端

HTTP報(bào)文首部

HTTP1.1 規(guī)定了 以下47種首部字段

通用首部 （共9種）

下面我們來(lái)看挑幾個(gè)重要的屬性來(lái)看下~

2. Connection 他有兩個(gè)作用

• 控制不再轉(zhuǎn)發(fā)給代理的首部字段

GET / HTTP/1.1
Upgrade: HTTP/1.1    // 就會(huì)把次字段刪除后再?gòu)拇矸?wù)器轉(zhuǎn)發(fā)出去
Connection: Upgrade   // 不再轉(zhuǎn)發(fā)的首部字段名

image

• 管理持久鏈接（這個(gè)比較常見(jiàn)）
  • HTTP/1.1默認(rèn)連接都是持久連接Connction: Keep-Alive
  • 當(dāng)服務(wù)器想斷開(kāi)的時(shí)候，需要指定Connction: close

4. Pragme :是HTTP/1.1之前版本遺留的字段，僅僅是為了與HTTP/1.0向后兼容而定義
   • Pragm：no-cache :通用首部字段，在請(qǐng)求頭中，表示所有的中間服務(wù)器不返回緩存的資源
   • 可是所有的中間服務(wù)器都以HTTP/1.1為基準(zhǔn)的話，可以直接采用 Cache-Control：no-cache
   • 所以一般會(huì)發(fā)送兩個(gè)字段Cache-Control：no-cache Pragm：no-cache

請(qǐng)求報(bào)文首部 （共19種）

9. If-Match：只有當(dāng) If-Match 字段值跟 ETag 值匹配一致時(shí)，服務(wù)器才會(huì)接受請(qǐng)求
   • 它會(huì)告知服務(wù)器匹配資源所用的實(shí)體標(biāo)記（ETag）值，這時(shí)服務(wù)器無(wú)法使用弱ETag值
   • 僅當(dāng)兩者一致時(shí)才會(huì)執(zhí)行請(qǐng)求，否則返回412 Precondition Failed的響應(yīng)
   • 還可以使用 * 號(hào)指定If-Match的字段值，如果這樣的話，那么服務(wù)器將會(huì)忽略ETag的值，只要資源存在就處理請(qǐng)求。
10. If-Modified-Since ：
    • 若資源更新時(shí)間確實(shí)在此字段指定時(shí)間之后的話，則處理該請(qǐng)求，否則返回304 Not Modified
    • 用于確認(rèn)代理或客戶(hù)端擁有本地資源的有效性，若想獲取資源的更新日期時(shí)間的話可以通過(guò)確認(rèn)首部字段Last-Modified來(lái)確定
11. If-None-Match
    • 只有在If-None-Match的字段值與ETag值不一致時(shí)，才可以處理該請(qǐng)求，與前文中提到的If-Match作用相反
12. If-Range
    • 他告知服務(wù)器若指定的If-Range字段值（ETag值或者時(shí)間）和請(qǐng)求資源的ETag值或時(shí)間一致時(shí)，則作為范圍請(qǐng)求處理，否則，返回全體資源
13. If-Unmodified-Since
    • 指定的請(qǐng)求資源只有在字段值內(nèi)指定的日期時(shí)間之后未發(fā)生更新，才會(huì)執(zhí)行這個(gè)請(qǐng)求，否則，返回412 Precondition Failed狀態(tài)響應(yīng)，與If-Modified-Since作用相反
14. Max-Forwards
    • 每次請(qǐng)求轉(zhuǎn)發(fā)時(shí)數(shù)值減一，直到0時(shí)返回響應(yīng)
    • 有可能這個(gè)請(qǐng)求經(jīng)過(guò)了多臺(tái)服務(wù)器代理轉(zhuǎn)發(fā)，如果突然間請(qǐng)求出現(xiàn)了什么問(wèn)題導(dǎo)致轉(zhuǎn)發(fā)失敗，而客戶(hù)端不知道，此時(shí)就可以用此屬性來(lái)定位問(wèn)題，這個(gè)時(shí)候我們就可以掌握一個(gè)出問(wèn)題的轉(zhuǎn)發(fā)路徑，從而方便進(jìn)一步的排查問(wèn)題。
15. Range:
    • 對(duì)于只需要獲取部分資源的范圍請(qǐng)求，Range字段可以指定獲取資源范圍Range: bytes=10001-20000
    • 例子中表示請(qǐng)求獲取從第10001字節(jié)到20000字節(jié)的資源
    • 服務(wù)器處理請(qǐng)求后會(huì)返回206 Partial Content的響應(yīng)。無(wú)法處理時(shí)，則會(huì)返回狀態(tài)碼200 OK的響應(yīng)及其全部資源

響應(yīng)報(bào)文首部 （共9種）

1. Accept-Ranges
   • Accept-Ranges：bytes 可以處理范圍請(qǐng)求
   • Accept-Ranges：none 不可以處理范圍請(qǐng)求
2. Age
   • 可以告知客戶(hù)端，源服務(wù)器多久之前創(chuàng)建了資源，單位是秒
   • 若創(chuàng)建該響應(yīng)的是緩存服務(wù)器，則Age值是指緩存后的響應(yīng)再次發(fā)起發(fā)起認(rèn)證到認(rèn)證完成的時(shí)間值。代理創(chuàng)建響應(yīng)時(shí)必須加上首部字段Age
3. ETag

   它是一種可將資源以字符串形式做唯一標(biāo)識(shí)的方式，服務(wù)器會(huì)為每份資源分配對(duì)應(yīng)的ETag值,資源被更新時(shí)，ETag值也會(huì)被更新，并沒(méi)有統(tǒng)一的算法規(guī)則，而是由服務(wù)器來(lái)分配

   • 強(qiáng)ETag：無(wú)論實(shí)體發(fā)生多么細(xì)微的變化都會(huì)改變其值
   • 弱ETag：只用于提示資源是否相同，只有資源發(fā)生了根本的改變才會(huì)改變ETag值，這時(shí)會(huì)在字段值最開(kāi)始加W/,
     ETag：W/"XXX"
4. Location
   • 使用該響應(yīng)字段可以將響應(yīng)接收方引導(dǎo)至某個(gè)與請(qǐng)求的URI位置不同的資源
   • 基本上，該字段配合3XX，Redirection的響應(yīng)，提供重定向的URI
5. Vary

   首部字段vary可對(duì)緩存進(jìn)行控制，源服務(wù)器會(huì)向代理服務(wù)器傳達(dá)關(guān)于本地緩存使用方法的命令

   • 當(dāng)代理服務(wù)器接收到服務(wù)器返回包含Vary指定項(xiàng)的響應(yīng)后，僅對(duì)請(qǐng)求中含有相同Vary指定首部字段的請(qǐng)求返回緩存
   • 即使對(duì)相同資源發(fā)起請(qǐng)求，但是由于Vary指定的首部字段不相同，因此必須從源服務(wù)器重新獲取資源
   • 例如下面這個(gè)，如果使用的Accept-Language：en-us字段的值相同，那么直接從緩存返回響應(yīng)，否則從源服務(wù)器請(qǐng)求資源后再返回響應(yīng)
     
     image

實(shí)體報(bào)文首部 （共10種）

其他字段（cookie等）

• cookie，我們下面單獨(dú)講這個(gè)

cookie

• 注 : 文中例子中的各種請(qǐng)求，報(bào)文，均來(lái)自 京東物流官網(wǎng)
• ps：小杰個(gè)人挺喜歡JDL的標(biāo)語(yǔ)的，有速度，更有溫度，祝JDL越來(lái)越好！

image

set-cookie

谷歌瀏覽器控制臺(tái)查看cookie

image

• cookie中的thor和JSESSIONID這兩個(gè)key的后HttpOnly屬性被打上了√，就表明，此key無(wú)法被js腳本訪問(wèn)，防止跨站腳本攻擊（Cross Site Scripting，XSS）對(duì)cookie的竊取
  我們來(lái)看下再console控制臺(tái)輸入document.cookie
  得出的cookie無(wú)法找到這兩個(gè)key

image

image

image

因?yàn)檫@個(gè)屬性JSESSIONID比較重要，存儲(chǔ)的是sessionId，這個(gè)要是被別人拿到的話，別人就可以冒充我在網(wǎng)站上做某些事情了，像我自己一樣請(qǐng)求某些數(shù)據(jù)了

postman 模擬拿到cookie后發(fā)送請(qǐng)求

image

image

我把網(wǎng)頁(yè)上的cookie拿下來(lái)，放到postman里測(cè)試，發(fā)現(xiàn)和我自己在網(wǎng)站上請(qǐng)求數(shù)據(jù)是一樣的

cookie存儲(chǔ)的地方，清理緩存到底是清理什么？

清理緩存主要就是清理cookie,抹去自己登陸痕跡以及瀏覽器中的資源緩存，重新請(qǐng)求網(wǎng)站資源

image

image

image

HTTP 與 HTTPS

HTTP不足

• 通信使用明文（不加密），內(nèi)容可能會(huì)被篡改
• 不驗(yàn)證通信方的身份，因此有可能遭遇偽裝
• 無(wú)法證明報(bào)文的完整性，所以有可能已遭遇篡改

HTTPS結(jié)構(gòu)

HTTPS是身披SSL（Secure Socket Layer）外殼的HTTP

image

• 在采用SSL后，HTP就擁有了HTTPS的加密、證書(shū)和完整性保護(hù)這些功能
• 想要了解HTTPS是怎么加密的，得先了解下下面兩種提到的加密技術(shù)

對(duì)稱(chēng)加密原理

• 客戶(hù)端和服務(wù)端約定好用同一把密鑰
• 這把密鑰可以對(duì)數(shù)據(jù)進(jìn)行加密/解密

image

• 客戶(hù)端和服務(wù)端之間的共享密鑰的傳送問(wèn)題也是一個(gè)問(wèn)題，如果能夠安全傳送不被截獲的話，那豈不是數(shù)據(jù)也可以安全的傳送到不被截獲？雞生蛋蛋生雞的問(wèn)題。
• 圖中客戶(hù)端和服務(wù)端傳輸加密數(shù)據(jù)的時(shí)候，如果雙方的共享密鑰泄露的被黑客截取到的話，黑客就可以用它來(lái)解開(kāi)這加密的數(shù)據(jù)，所以對(duì)稱(chēng)加密不安全

非對(duì)稱(chēng)加密原理（公開(kāi)密鑰加密）

• 一共有兩把密鑰（是一對(duì)），一個(gè)公開(kāi)密鑰，一個(gè)私人密鑰
• 公開(kāi)密鑰加密的數(shù)據(jù)，只有對(duì)應(yīng)的私鑰才可以解密，
• 私鑰加密的數(shù)據(jù)，公鑰也可以解密

image

• 問(wèn)題就是，從服務(wù)端發(fā)送給客戶(hù)端數(shù)據(jù)時(shí)無(wú)法保證數(shù)據(jù)的安全性，因?yàn)榇藭r(shí)有可能黑客截獲到了公鑰，對(duì)私鑰加密的數(shù)據(jù)進(jìn)行了解密
• 服務(wù)器端為什么不發(fā)送用公鑰加密的數(shù)據(jù)？因?yàn)榭蛻?hù)端沒(méi)有私鑰，無(wú)法解密。

混合加密原理

聰明的大佬們用兩種加密算法混合了一下

• 客戶(hù)端一開(kāi)始向服務(wù)端傳輸?shù)氖?，用公開(kāi)密鑰加密的共享密鑰！
• 這樣的話，服務(wù)端收到這個(gè)加密的數(shù)據(jù)后用自己的私鑰密鑰解密后得到的就是共享密鑰，以后和客戶(hù)端交互時(shí)都用這個(gè)共享密鑰就可以啦，因?yàn)楹诳褪菬o(wú)法獲得這個(gè)共享密鑰的，畢竟公開(kāi)密鑰加密的數(shù)據(jù)，只有對(duì)應(yīng)的私鑰才可以解密，而這個(gè)私鑰一開(kāi)始就在服務(wù)端手里而不在黑客手里

image

我曾經(jīng)以為這樣就萬(wàn)無(wú)一失了，文章也就到此結(jié)束了，可以和血包殺手愉快的timi了，可是，你有沒(méi)有聽(tīng)說(shuō)過(guò)，中間人攻擊？

中間人攻擊

黑客攔截”用公開(kāi)加密密鑰機(jī)密后的共享密鑰“后不是解密不了嗎，好，那我就不攔截這個(gè)了，我攔截第一個(gè)請(qǐng)求好吧，我攔截服務(wù)端傳給你的公開(kāi)密鑰，我攔截到了，我再給你個(gè)假的，（像極了《讓子彈飛》中，張麻子與馬邦德的關(guān)系，出任鵝城縣長(zhǎng)）。從根上就偽裝成你，以后就等于我是個(gè)中間人（中轉(zhuǎn)站），所有的請(qǐng)求，數(shù)據(jù)都要經(jīng)過(guò)我，那我就可以記錄下來(lái)其中你的敏感數(shù)據(jù)，可怕。

image

• 其實(shí)中間人攻擊還要有好多種，以后有機(jī)會(huì)寫(xiě)一寫(xiě)，我們先大概了解下是什么意思就好~

數(shù)字證書(shū)

• 所以現(xiàn)在問(wèn)題又到了這里，我無(wú)法確保這個(gè)公鑰是服務(wù)端發(fā)給我的，還是中間人發(fā)給我的？可這世上沒(méi)有用錢(qián)解決不了的問(wèn)題，雖然我確保不了，可是有人可以確保，就是得花錢(qián)，我們可以使用由數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)（CA）和其他相關(guān)機(jī)構(gòu)頒發(fā)的公開(kāi)密鑰證書(shū)
• 數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)處于客戶(hù)端和服務(wù)器雙方都信賴(lài)的第三方機(jī)構(gòu)的立場(chǎng)上。有興趣的同學(xué)可以自行去了解下~
• 所以HTTPS靠非對(duì)稱(chēng)性加密及數(shù)字證書(shū)保證了安全性

寫(xiě)在最后

總結(jié)

• 此文章從HTTP報(bào)文結(jié)構(gòu)開(kāi)始，到HTTP首部，到返回狀態(tài)碼，到cookie，再延伸到HTTPS加密方式，每一部分都進(jìn)行了詳細(xì)的介紹，希望對(duì)大家有用！

絮絮叨叨

• 如果大家覺(jué)得這篇文章對(duì)自己有一點(diǎn)點(diǎn)幫助的話，歡迎關(guān)注此號(hào) java小杰要加油
• 原創(chuàng)不易，實(shí)需鼓勵(lì)

若文章有誤歡迎指出，靚仔靚女們，我們下篇文章見(jiàn)，關(guān)注我，開(kāi)啟我們的故事