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

• 話不多說晶默，直接開搞

HTTP簡介

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

HTTP報(bào)文

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

image

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

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

• 由客戶端發(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)碼，原因短語和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：表示客戶端發(fā)來的請(qǐng)求被服務(wù)器正常處理了
• 204 Not Content:請(qǐng)求被成功處理硝枉，但是返回的響應(yīng)報(bào)文不包含實(shí)體的主體部分
• 206 Partial Content:客戶端進(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:客戶端發(fā)送附帶條件（請(qǐng)求首部中if開頭的屬性中的一種）的請(qǐng)求的時(shí)候责球，服務(wù)端允許訪問資源，但是那些請(qǐng)求并沒有滿足拓劝，直接返回304雏逾，即服務(wù)端資源未改變，可以直接使用客戶端未過期的緩存郑临，304返回時(shí)栖博，不包含任何響應(yīng)的主體部分（雖然被劃分為3xx里，但是和重定向沒有任何關(guān)系）

4xx 客戶端錯(cuò)誤

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

• 400 Bad Requset：請(qǐng)求報(bào)文中存在語法錯(cuò)誤厢洞，請(qǐng)修改請(qǐng)求內(nèi)容后再發(fā)送請(qǐng)求
• 401 Unauthorized:客戶端未認(rèn)證授權(quán)
• 403 Forbidden:服務(wù)端禁止客戶端訪問此資源
• 404 Not Found:URL寫錯(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í)間妹孙，最好寫入響應(yīng)頭中的Retry-After這個(gè)字段再返回給客戶端

HTTP報(bào)文首部

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

通用首部 （共9種）

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

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

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

GET / HTTP/1.1
Upgrade: HTTP/1.1    // 就會(huì)把次字段刪除后再從代理服務(wù)器轉(zhuǎn)發(fā)出去
Connection: Upgrade   // 不再轉(zhuǎn)發(fā)的首部字段名

image

• 管理持久鏈接（這個(gè)比較常見）
  • HTTP/1.1默認(rèn)連接都是持久連接Connction: Keep-Alive
  • 當(dāng)服務(wù)器想斷開的時(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ù)器無法使用弱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)代理或客戶端擁有本地資源的有效性串慰，若想獲取資源的更新日期時(shí)間的話可以通過確認(rèn)首部字段Last-Modified來確定
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)過了多臺(tái)服務(wù)器代理轉(zhuǎn)發(fā)蚁堤，如果突然間請(qǐng)求出現(xiàn)了什么問題導(dǎo)致轉(zhuǎn)發(fā)失敗醉者，而客戶端不知道，此時(shí)就可以用此屬性來定位問題披诗，這個(gè)時(shí)候我們就可以掌握一個(gè)出問題的轉(zhuǎn)發(fā)路徑，從而方便進(jì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)。無法處理時(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
   • 可以告知客戶端宪摧，源服務(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ì)被更新沿彭，并沒有統(tǒng)一的算法規(guī)則，而是由服務(wù)器來分配

   • 強(qiáng)ETag：無論實(shí)體發(fā)生多么細(xì)微的變化都會(huì)改變其值
   • 弱ETag：只用于提示資源是否相同尖滚，只有資源發(fā)生了根本的改變才會(huì)改變ETag值喉刘，這時(shí)會(huì)在字段值最開始加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)文，均來自 京東物流官網(wǎng)
• ps：小杰個(gè)人挺喜歡JDL的標(biāo)語的课舍，有速度塌西，更有溫度，祝JDL越來越好筝尾！

image

set-cookie

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

image

• cookie中的thor和JSESSIONID這兩個(gè)key的后HttpOnly屬性被打上了√站辉，就表明，此key無法被js腳本訪問损姜，防止跨站腳本攻擊（Cross Site Scripting饰剥，XSS）對(duì)cookie的竊取
  我們來看下再console控制臺(tái)輸入document.cookie
  得出的cookie無法找到這兩個(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)頁上的cookie拿下來棒卷，放到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)證通信方的身份蜒什，因此有可能遭遇偽裝
• 無法證明報(bào)文的完整性测秸，所以有可能已遭遇篡改

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

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

image

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

對(duì)稱加密原理

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

image

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

非對(duì)稱加密原理（公開密鑰加密）

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

image

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

混合加密原理

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

• 客戶端一開始向服務(wù)端傳輸?shù)氖侵也溃霉_密鑰加密的共享密鑰呢堰！
• 這樣的話，服務(wù)端收到這個(gè)加密的數(shù)據(jù)后用自己的私鑰密鑰解密后得到的就是共享密鑰凡泣，以后和客戶端交互時(shí)都用這個(gè)共享密鑰就可以啦枉疼，因?yàn)楹诳褪菬o法獲得這個(gè)共享密鑰的，畢竟公開密鑰加密的數(shù)據(jù)鞋拟，只有對(duì)應(yīng)的私鑰才可以解密骂维，而這個(gè)私鑰一開始就在服務(wù)端手里而不在黑客手里

image

我曾經(jīng)以為這樣就萬無一失了，文章也就到此結(jié)束了严卖，可以和血包殺手愉快的timi了席舍，可是，你有沒有聽說過哮笆，中間人攻擊？

中間人攻擊

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

image

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

數(shù)字證書

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

寫在最后

總結(jié)

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

絮絮叨叨

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

若文章有誤歡迎指出叫胖，靚仔靚女們，我們下篇文章見她奥，關(guān)注我瓮增，開啟我們的故事