前言
對(duì)于HTTP協(xié)議鸟赫，想必大家都不陌生，在工作中經(jīng)常用到，特別是針對(duì)移動(dòng)端和前端開發(fā)人員來說幕袱，要獲取服務(wù)端數(shù)據(jù)瘪松，基本走的網(wǎng)絡(luò)請(qǐng)求都是基于HTTP協(xié)議咸作，特別是RESTFUL + JSON 這種搭配特別主流。那如果讓大家具體講講HTTP協(xié)議背后的歷史宵睦、原理记罚、交互流程、與HTTPS區(qū)別壳嚎、身份認(rèn)證桐智、Web攻防技術(shù)等等信息，大家能講的出來嗎烟馅，反正我講的也是一知半解说庭，雖然會(huì)經(jīng)常看這方面的文章郑趁，但也只是在具體項(xiàng)目進(jìn)行開發(fā)過程中碰到對(duì)某個(gè)概念不清楚刊驴，才會(huì)去特意看下，卻沒有特意去總結(jié)歸納為一直知識(shí)點(diǎn)穿撮，沒有完整的表達(dá)描述過缺脉，其實(shí)對(duì)這個(gè)知識(shí)點(diǎn)還是沒掌握好的痪欲，所以用寫作方式來進(jìn)行闡述是很好一個(gè)方式，目前也正在踐行著攻礼。
思維導(dǎo)圖
在寫作之前业踢，這篇文章主要想講的內(nèi)容在以下這張圖中，通過做思維導(dǎo)圖方式來表達(dá)一篇文章內(nèi)容礁扮，我覺得邏輯會(huì)特別清楚知举，同時(shí)也是對(duì)某個(gè)知識(shí)點(diǎn)會(huì)很好進(jìn)行總結(jié)歸納。
HTTP歷史
發(fā)展由來
在1989 年 3 月太伊， 互聯(lián)網(wǎng)還只屬于少數(shù)人雇锡。 在這一互聯(lián)網(wǎng)的黎明期， HTTP 誕生了僚焦。CERN（ 歐洲核子研究組織）的蒂姆 ? 伯納斯 - 李（ Tim BernersLee）博士提出了一種能讓遠(yuǎn)隔兩地的研究者們共享知識(shí)的設(shè)想锰提。 最初設(shè)想 的 基本理念是： 借助多文檔之間相互關(guān)聯(lián)形成的超文本（ HyperText），連成可相互參閱的 WWW（ World Wide Web芳悲，萬維網(wǎng)）立肘。并且版本從 HTTP 1.0 到 HTTP 1.1 再到現(xiàn)在的 HTTP 2.0，目前主流版本還是基于 HTTP 1.1名扛，HTTP 協(xié)議同時(shí)也是目前互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議谅年，所有的 WWW 文件都必須遵守這個(gè)標(biāo)準(zhǔn)，設(shè)計(jì)HTTP 最初的目的是為了提供一種發(fā)布和接收 HTML 頁面的方法肮韧。
TCP/IP
我們都知道 HTTP 協(xié)議在 根據(jù) TCP/IP 網(wǎng)絡(luò)分層來看融蹂，它是屬于應(yīng)用層，TCP/IP 網(wǎng)絡(luò)分層總共有5層弄企，它是屬于最上層超燃，它的下一層則是 TCP/IP 傳輸層，如圖所示：
從邏輯平行來看桩蓉，發(fā)送方和接受方都是處于同一平行層淋纲，發(fā)送方每層傳遞的信息會(huì)在下一層進(jìn)行信息封裝加密，然后逐層傳遞院究，通過實(shí)際物理鏈路進(jìn)行傳遞洽瞬，然后接收方接收到信息進(jìn)行解密分析，不斷把報(bào)文頭信息進(jìn)行還原业汰，最后處理發(fā)送方發(fā)送過來的信息伙窃，處理完之后，再用同樣的方式傳遞回去样漆，兩者傳輸通信方式是全雙工模式为障。在此之前需要一個(gè)建立連接過程，所謂的三次握手，通信結(jié)束也有斷開連接過程鳍怨，也就是四次握手?jǐn)嚅_操作呻右。
在講述 HTTP 協(xié)議為何了解 TCP/IP 內(nèi)容呢，因?yàn)槲覀冃枰?HTTP 協(xié)議實(shí)際通信過程是怎么樣的鞋喇，它所依賴的環(huán)境是怎么樣的声滥，從切面角度去看，實(shí)際是經(jīng)歷了這5層通信侦香，從平面去看落塑，默認(rèn)以為是客戶端與服務(wù)端僅僅進(jìn)行平層通信而已，那是因?yàn)榉庋b的方便罐韩。
HTTP 1.1
因?yàn)槟壳爸髁髟谟玫倪€是以 HTTP 1.1 版本為主憾赁，那就用這個(gè)版本來分析。
HTTP請(qǐng)求協(xié)議詳解
一個(gè)典型HTTP1.1的請(qǐng)求協(xié)議報(bào)文結(jié)構(gòu)散吵，大體上可以分為三塊龙考，即請(qǐng)求行、頭部错蝴、消息主體洲愤。
請(qǐng)求行
請(qǐng)求行包含HTTP請(qǐng)求方法颓芭、請(qǐng)求的URL顷锰、HTTP協(xié)議版本三個(gè)內(nèi)容，它們之間以空格間隔亡问，并以回車+換行結(jié)束官紫。HTTP請(qǐng)求方法有下面幾種,常用的有GET、POST請(qǐng)求州藕。
- OPTIONS
- GET
- HEAD
- POST
- DELETE
- TRACE
- CONNECT
請(qǐng)求頭部
頭部可以分成三個(gè)部分束世，為常用頭域、請(qǐng)求頭域床玻、實(shí)體頭域毁涉。其中常用頭域和實(shí)體頭域部分內(nèi)容在響應(yīng)協(xié)議部分也有相同的定義。
常用頭域
| 常用頭域名稱 | 作用描述 |
|---|---|
| Cache-Control | 緩存控制 |
| Connection | HTTP 1.1默認(rèn)是支持長連接的(Keep-Alive)锈死，如果不希望支持長連接則需要在此域中寫入close |
| Date | 表明消息產(chǎn)生的日期和時(shí)間 |
| Pragma | |
| Trailer | |
| Transfer-Encoding | 告知接收端為了保證報(bào)文的可靠傳輸贫堰，對(duì)報(bào)文采用了什么編碼方式 |
| Upgrade | 給出了發(fā)送端可能想要”升級(jí)”使用的新版本或協(xié)議 |
| Via | 顯示了報(bào)文經(jīng)過的中間節(jié)點(diǎn)(代理、網(wǎng)關(guān)) |
| Warning |
請(qǐng)求頭域
| 請(qǐng)求頭域名稱 | 作用描述 |
|---|---|
| Accept | 指明請(qǐng)求端可以接受處理的媒體類型 |
| Accept-Charset | 指明請(qǐng)求端可以接受的字符集 |
| Accept-Encoding | 指明請(qǐng)求端可以接受的編碼格式 |
| Authorization | 授權(quán) |
| Expect | 允許客戶端列出某請(qǐng)求所要求的服務(wù)器行為 |
| From | 提供了客戶端用戶的E-mail地址 |
| Host | 指明請(qǐng)求端的網(wǎng)絡(luò)主機(jī)和端口號(hào) |
| If-Match | 服務(wù)端在響應(yīng)頭部里面返回ETag信息待牵，客戶端請(qǐng)求時(shí)在頭部添加If-Match（值為響應(yīng)的ETag）其屏，服務(wù)端接收后判斷ETag是否相同，若相同則處理請(qǐng)求缨该，否則不處理請(qǐng)求偎行。 |
| If-Modified-Since | 客戶端在請(qǐng)求某一資源文件時(shí)，在頭部加上If-Modified-Since(值為該資源文件的最后修改時(shí)間)，服務(wù)端接收后將客戶端上報(bào)的修改時(shí)間與服務(wù)器存儲(chǔ)的文件的最后修改時(shí)間做對(duì)比蛤袒，如果相同熄云，說明資源文件沒有更新，返回304狀態(tài)碼妙真，告訴客戶端使用原來的緩存文件皱碘。否則返回資源內(nèi)容。 |
| If-None-Match | 服務(wù)端在響應(yīng)頭部里面返回ETag信息隐孽，客戶端請(qǐng)求時(shí)在頭部添加If-None-Match(值為響應(yīng)的ETag)癌椿，服務(wù)端接收后判斷ETag是否相同，若相同菱阵，說明資源沒有更新踢俄，返回304狀態(tài)碼，告訴客戶端使用原來的緩存文件晴及。否則返回資源內(nèi)容都办。 |
| If-Range | 該頭域與Range頭域一起使用，服務(wù)端在響應(yīng)頭部里面返回ETag信息,客戶端請(qǐng)求時(shí)在頭部添加If-Range（值為響應(yīng)的ETag)虑稼，服務(wù)端接收后判斷ETag是否相同琳钉，若相同，則返回狀態(tài)碼206蛛倦，返回內(nèi)容為Range指定的字節(jié)范圍歌懒。若不相同，則返回狀態(tài)碼200溯壶，返回內(nèi)容為整個(gè)實(shí)體及皂。 |
| If-Unmodified-Since | 客戶端在請(qǐng)求某一資源文件時(shí)，在頭部加上If-Modified-Since(值為該資源文件的最后修改時(shí)間)且改，端接收后將客戶端上報(bào)的修改時(shí)間與服務(wù)器存儲(chǔ)的文件的最后修改時(shí)間做對(duì)比验烧，如果相同，則返回資源內(nèi)容又跛，如果不相同則返回狀態(tài)碼412碍拆。 |
| Max-Forwards | 配合TRACE、OPTIONS方法使用慨蓝，限制在通往服務(wù)器的路徑上的代理或網(wǎng)關(guān)的數(shù)量感混。 |
| Proxy-Authorization | 代理授權(quán) |
| Range | 表示客戶端向服務(wù)端請(qǐng)求指定范圍的字節(jié)數(shù)量:Range:bytes=0-500表示請(qǐng)求第1個(gè)到第501個(gè)的字節(jié)數(shù)量。Range:bytes=100-表示請(qǐng)求第101到文件倒數(shù)第一個(gè)字節(jié)的字節(jié)數(shù)量菌仁。Range:bytes=-500表示請(qǐng)求最后500個(gè)字節(jié)的數(shù)量浩习。Range可以同時(shí)指定多組(Range:bytes=500-600,601-999)。并不是所有的服務(wù)端都支持字節(jié)范圍請(qǐng)求的济丘，如果支持字節(jié)范圍請(qǐng)求谱秽，服務(wù)端會(huì)返回狀態(tài)碼206洽蛀，若不支持則會(huì)返回200，客戶端需要根據(jù)狀態(tài)碼來判斷服務(wù)端是否支持字節(jié)范圍操作疟赊。此域可用于斷點(diǎn)下載郊供，即在斷點(diǎn)處請(qǐng)求后面的內(nèi)容，也可用于多線程下載同一個(gè)文件近哟，每個(gè)線程負(fù)責(zé)一個(gè)文件的一部分下載工作驮审，多個(gè)線程協(xié)同完成整個(gè)文件的下載。 |
| Referer | 用于指定客戶端請(qǐng)求的來源吉执，是從搜索引擎過來的疯淫？還是從其它網(wǎng)站鏈接過來的？服務(wù)器根據(jù)此域戳玫，有時(shí)可以用做防盜鏈處理熙掺，不在指定范圍內(nèi)的來源，統(tǒng)統(tǒng)拒絕咕宿。 |
| TE | 指明客戶端可以接受哪些傳輸編碼币绩。 |
實(shí)體頭域
| 實(shí)體頭域名稱 | 作用描述 |
|---|---|
| Allow | 指明被請(qǐng)求的資源所支持的方法，如GET府阀、HEAD缆镣、PUT |
| Content-Encoding | 指明實(shí)體內(nèi)容所采用的編碼方式 |
| Content-Language | 指明實(shí)體內(nèi)容使用的語言 |
| Content-Length | 指明請(qǐng)求實(shí)體的字節(jié)數(shù)量 |
| Content-Location | 可以用來為實(shí)體提供對(duì)應(yīng)資源的位置 |
| Content-MD5 | 指定實(shí)體內(nèi)容的MD5，用于內(nèi)容的完整性校驗(yàn)(base64的128位MD5) |
| Content-Range | |
| Content-Type | 指定實(shí)體的媒體類型 |
| Expires | 指明實(shí)體的過期時(shí)間 |
| Last-Modified | 指明實(shí)體最后被修改的時(shí)間 |
HTTP響應(yīng)協(xié)議詳解
HTTP1.1的響應(yīng)協(xié)議報(bào)文結(jié)構(gòu)试浙，大體上可以分為三塊董瞻，即狀態(tài)行、頭部川队、消息主體力细。
狀態(tài)行
狀態(tài)行包含HTTP協(xié)議版本、狀態(tài)碼固额、原因短語三個(gè)內(nèi)容，它們之間以空格間隔煞聪，并以回車+換行結(jié)束斗躏。
狀態(tài)碼由三位數(shù)字組成，第一位數(shù)字定義了響應(yīng)類型昔脯，主要有如下五種類型的狀態(tài)碼
| 狀態(tài)碼類型 | 作用描述 |
|---|---|
| 1xx | 報(bào)告（請(qǐng)求被接收啄糙，繼續(xù)處理） |
| 2xx | 成功（請(qǐng)求被成功的接收并處理） |
| 3xx | 重發(fā) |
| 4xx | 客戶端出錯(cuò)（客戶端錯(cuò)誤的協(xié)議格式和不能處理的請(qǐng)求） |
| 5xx | 服務(wù)器出錯(cuò)（服務(wù)器無法完成有效的請(qǐng)求處理） |
狀態(tài)碼和對(duì)應(yīng)的原因短語詳細(xì)描述
| 狀態(tài)碼 | 原因短語 | 中文描述 |
|---|---|---|
| 100 | Continue | 繼續(xù) |
| 101 | Switching Protocols | 切換協(xié)議 |
| 200 | OK | 成功 |
| 201 | Created | 已創(chuàng)建 |
| 202 | Accepted | 接受 |
| 203 | Non-Authoritative information | 非權(quán)威信息 |
| 204 | No Content | 無內(nèi)容 |
| 205 | Reset Content | 重置內(nèi)容 |
| 206 | Partial Content | 部分內(nèi)容 |
| 300 | Multiple Choices | 多個(gè)選擇 |
| 301 | Moved Permanently | 永久移動(dòng) |
| 302 | Found | 發(fā)現(xiàn) |
| 303 | See Other | 見其它 |
| 304 | Not Modified | 沒有改變 |
| 305 | Use Proxy | 使用代理 |
| 307 | Temporary Redirect | 臨時(shí)重發(fā) |
| 400 | Bad Request | 壞請(qǐng)求 |
| 401 | Unauthorized | 未授權(quán)的 |
| 402 | Payment Required | 必需的支付 |
| 403 | Forbidden | 禁用 |
| 404 | Not Found | 沒有找到 |
| 405 | Method Not Allowed | 方法不被允許 |
| 406 | Not Acceptable | 不可接受的 |
| 407 | Proxy Authentication Required | 需要代理驗(yàn)證 |
| 408 | Request Timeout | 請(qǐng)求超時(shí) |
| 409 | Confilict | 沖突 |
| 410 | Gone | 不存在 |
| 411 | Length Required | 長度必需 |
| 412 | Precondition Failed | 先決條件失敗 |
| 413 | Request Entity Too Large | 請(qǐng)求實(shí)體太大 |
| 414 | Request-URI Too Long | 請(qǐng)求URI太長 |
| 415 | Unsupported Media Type | 不支持的媒體類型 |
| 416 | Requested Range Not Satisfiable | 請(qǐng)求范圍不被滿足 |
| 417 | Expectation Failed | 期望失敗 |
| 500 | Internal Server Error | 內(nèi)部服務(wù)器錯(cuò)誤 |
| 501 | Not Implemented | 服務(wù)端沒有實(shí)現(xiàn) |
| 502 | Bad Gateway | 壞網(wǎng)關(guān) |
| 503 | Service Unavailable | 服務(wù)不能獲得 |
| 504 | Gateway Timeout | 網(wǎng)關(guān)超時(shí) |
| 505 | HTTP Version Not Supported | HTTP協(xié)議版本不支持 |
響應(yīng)頭域
| 響應(yīng)頭域名稱 | 作用描述 |
|---|---|
| Accept-Ranges | 服務(wù)器向客戶端指明服務(wù)器對(duì)范圍請(qǐng)求的接受度 |
| Age | 從原始服務(wù)器到代理緩存形成的估算時(shí)間（以秒計(jì)，非負(fù)） |
| ETag | 實(shí)體標(biāo)簽 |
| Location | 指定重定向的URI |
| Proxy-Autenticate | 它指出認(rèn)證方案和可應(yīng)用到代理的該URL上的參數(shù) |
| Retry-After | 如果實(shí)體暫時(shí)不可取云稚，通知客戶端在指定時(shí)間之后再次嘗試 |
| Server | 指明服務(wù)器用于處理請(qǐng)求的軟件信息 |
| Vary | 告訴下游代理是使用緩存響應(yīng)還是從原始服務(wù)器請(qǐng)求 |
| WWW-Authenticate | 表明客戶端請(qǐng)求實(shí)體應(yīng)該使用的授權(quán)方案 |
交互流程
整體通信其實(shí)就是發(fā)送/響應(yīng)過程隧饼，一個(gè)請(qǐng)求過去，對(duì)方有響應(yīng)內(nèi)容來返回静陈，請(qǐng)求發(fā)送和響應(yīng)回答方式燕雁，同時(shí) HTTP 1.1 的特點(diǎn)是無狀態(tài)的诞丽、快速響應(yīng)的，一次連接則馬上就斷開拐格。HTTP 2.0 則是相反僧免，完善了 HTTP 1.1 出現(xiàn)的問題，兩者連接是可復(fù)用的捏浊，同時(shí)可支持并行發(fā)送懂衩，一次多個(gè)文件傳遞，多個(gè)文件響應(yīng)金踪，支持傳遞的文件大小以二進(jìn)制方式浊洞，這樣確保可支持更大文件胡岔，在安全性上比 HTTP 1.1上更強(qiáng)大沛申，具體細(xì)節(jié)可查閱相關(guān)文檔。
URL 和 URI
這里有必要提下 URL 和 URI 這個(gè)兩個(gè)名詞的區(qū)別姐军。URL表示標(biāo)記了一個(gè)WWW互聯(lián)網(wǎng)資源（用地址標(biāo)記）铁材，并給出了他的訪問地址。而URI表示一個(gè)網(wǎng)絡(luò)資源奕锌，僅此而已著觉。
HTTPS
通信流程
具體步驟：
步驟 1：客戶端通過發(fā)送 Client Hello 報(bào)文開始 SSL 通信。 報(bào)文中包含客戶端支持的 SSL 的指定版本惊暴、 加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）饼丘。
步驟 2：服務(wù)器可進(jìn)行 SSL 通信時(shí)， 會(huì)以 Server Hello 報(bào)文作為應(yīng)答辽话。 和客戶端一樣肄鸽， 在報(bào)文中包含 SSL 版本 以及加密組件。 服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的油啤。
步驟 3：之后服務(wù)器發(fā)送 Certificate 報(bào)文典徘。 報(bào)文中包含公開密鑰證書。
步驟 4：最后服務(wù)器發(fā)送 Server Hello Done 報(bào)文通知客戶端益咬， 最初階段的 SSL 握手協(xié)商部分結(jié)束逮诲。
步驟 5：SSL 第一次握手結(jié)束之后， 客戶端以 Client Key Exchange 報(bào)文作為回應(yīng)幽告。 報(bào)文中包含通信加密中使用 的一種被稱為 Pre- master secret 的隨機(jī)密碼串梅鹦。 該報(bào)文已用步驟 3 中的公開密鑰進(jìn)行加密。
步驟 6：接著客戶端繼續(xù)發(fā)送 Change Cipher Spec 報(bào)文冗锁。 該報(bào)文會(huì)提示服務(wù)器齐唆， 在此報(bào)文之后的通信會(huì)采用 Pre- master secret 密鑰加密。
步驟 7：客戶端發(fā)送 Finished 報(bào)文冻河。 該報(bào)文包含連接至今全部報(bào)文的整體校驗(yàn)值箍邮。 這次握手協(xié)商是否能夠成功茉帅， 要以服務(wù)器是否能夠正確解密該報(bào)文作為判定標(biāo)準(zhǔn)。
步驟 8：服務(wù)器同樣發(fā)送 Change Cipher Spec 報(bào)文媒殉。
步驟 9：服務(wù)器同樣發(fā)送 Finished 報(bào)文担敌。
步驟 10：服務(wù)器和客戶端的 Finished 報(bào)文交換完畢之后， SSL 連接就算建立完成廷蓉。 當(dāng)然全封， 通信會(huì)受到 SSL 的保護(hù)。 從此處開始進(jìn)行應(yīng)用層協(xié)議的通信桃犬， 即發(fā)送 HTTP 請(qǐng)求刹悴。
步驟 11： 應(yīng)用層協(xié)議通信， 即發(fā)送 HTTP 響應(yīng)攒暇。
步驟 12： 最后 由 客戶 端斷開連接土匀。 斷開連接時(shí)， 發(fā)送 close_ notify 報(bào)文形用。 上圖做了一些省略就轧， 這步之后再 發(fā)送 TCP FIN 報(bào)文來關(guān)閉與 TCP 的通信。
加密算法
常見的加密算法可以分成三類田度，對(duì)稱加密算法妒御，非對(duì)稱加密算法和Hash算法。
對(duì)稱加密
指加密和解密使用相同密鑰的加密算法镇饺。對(duì)稱加密算法的優(yōu)點(diǎn)在于加解密的高速度和使用長密鑰時(shí)的難破解性乎莉。假設(shè)兩個(gè)用戶需要使用對(duì)稱加密方法加密然后交換數(shù)據(jù)，則用戶最少需要2個(gè)密鑰并交換使用奸笤，如果企業(yè)內(nèi)用戶有n個(gè)惋啃，則整個(gè)企業(yè)共需要n×(n-1) 個(gè)密鑰，密鑰的生成和分發(fā)將成為企業(yè)信息部門的惡夢(mèng)监右。對(duì)稱加密算法的安全性取決于加密密鑰的保存情況边灭，但要求企業(yè)中每一個(gè)持有密鑰的人都保守秘密是不可能的，他們通常會(huì)有意無意的把密鑰泄漏出去——如果一個(gè)用戶使用的密鑰被入侵者所獲得秸侣，入侵者便可以讀取該用戶密鑰加密的所有文檔存筏，如果整個(gè)企業(yè)共用一個(gè)加密密鑰，那整個(gè)企業(yè)文檔的保密性便無從談起味榛。
常見的對(duì)稱加密算法：DES、3DES予跌、DESX搏色、Blowfish、IDEA券册、RC4频轿、RC5垂涯、RC6和AES
非對(duì)稱加密
指加密和解密使用不同密鑰的加密算法，也稱為公私鑰加密航邢。假設(shè)兩個(gè)用戶要加密交換數(shù)據(jù)耕赘，雙方交換公鑰，使用時(shí)一方用對(duì)方的公鑰加密膳殷，另一方即可用自己的私鑰解密操骡。如果企業(yè)中有n個(gè)用戶，企業(yè)需要生成n對(duì)密鑰赚窃，并分發(fā)n個(gè)公鑰册招。由于公鑰是可以公開的，用戶只要保管好自己的私鑰即可勒极，因此加密密鑰的分發(fā)將變得十分簡單是掰。同時(shí)，由于每個(gè)用戶的私鑰是唯一的辱匿，其他用戶除了可以可以通過信息發(fā)送者的公鑰來驗(yàn)證信息的來源是否真實(shí)键痛，還可以確保發(fā)送者無法否認(rèn)曾發(fā)送過該信息。非對(duì)稱加密的缺點(diǎn)是加解密速度要遠(yuǎn)遠(yuǎn)慢于對(duì)稱加密匾七，在某些極端情況下絮短，甚至能比非對(duì)稱加密慢上1000倍。
常見的非對(duì)稱加密算法：RSA乐尊、ECC（移動(dòng)設(shè)備用）戚丸、Diffie-Hellman、El Gamal扔嵌、DSA（數(shù)字簽名用）
Hash算法
Hash算法特別的地方在于它是一種單向算法限府，用戶可以通過Hash算法對(duì)目標(biāo)信息生成一段特定長度的唯一的Hash值，卻不能通過這個(gè)Hash值重新獲得目標(biāo)信息痢缎。因此Hash算法常用在不可還原的密碼存儲(chǔ)胁勺、信息完整性校驗(yàn)等。
常見的Hash算法：MD2独旷、MD4署穗、MD5、HAVAL嵌洼、SHA案疲、SHA-1、HMAC麻养、HMAC-MD5褐啡、HMAC-SHA1
數(shù)字證書和數(shù)字簽名證書
數(shù)字證書是由權(quán)威的CA機(jī)構(gòu)頒發(fā)的無法被偽造的證書，用于校驗(yàn)發(fā)送方實(shí)體身份的認(rèn)證鳖昌。解決如上問題备畦，只需要發(fā)送方A找一家權(quán)威的CA機(jī)構(gòu)申請(qǐng)頒發(fā)數(shù)字證書低飒，證書內(nèi)包含A的相關(guān)資料信息以及A的公鑰，然后將正文A懂盐、數(shù)字證書以及A生成的數(shù)字簽名發(fā)送給B褥赊，此時(shí)中間人M是無法篡改正文內(nèi)容而轉(zhuǎn)發(fā)給B的，因?yàn)镸不可能擁有這家CA的私鑰莉恼，無法隨機(jī)制作數(shù)字證書拌喉。當(dāng)然，如果M也申請(qǐng)了同一家CA的數(shù)字證書并替換發(fā)送修改后的正文类垫、M的數(shù)字證書和M的數(shù)字簽名司光，此時(shí)B接收到數(shù)據(jù)時(shí)，會(huì)校驗(yàn)數(shù)字證書M中的信息與當(dāng)前通信方是否一致悉患，發(fā)現(xiàn)數(shù)字證書中的個(gè)人信息為M并非A残家，說明證書存在替換風(fēng)險(xiǎn)，可以選擇中斷通信售躁。
為什么CA制作的證書是無法被偽造的坞淮？其實(shí)CA制作的數(shù)字證書內(nèi)還包含CA對(duì)證書的數(shù)字簽名，接收方可以使用CA公開的公鑰解密數(shù)字簽名陪捷，并使用相同的摘要算法驗(yàn)證當(dāng)前數(shù)字證書是否合法回窘。制作證書需要使用對(duì)應(yīng)CA機(jī)構(gòu)的私鑰，因此CA頒發(fā)的證書是無法被非法偽造的（CA的私鑰泄露不在考慮討論與考慮范圍內(nèi)）市袖。
數(shù)字證書簽名的基礎(chǔ)就是非對(duì)稱加密算法和數(shù)字簽名啡直，其無法偽造的特性使得其應(yīng)用面較廣，HTTPS中就使用了數(shù)字證書來保證握手階段服務(wù)端傳輸?shù)墓€的可靠性苍碟。
數(shù)字簽名是非對(duì)稱加密算法和摘要算法的一種應(yīng)用酒觅，能夠保證信息在傳輸過程中不被篡改，也能保證數(shù)據(jù)不能被偽造微峰。使用時(shí)舷丹，發(fā)送方使用摘要算法獲得發(fā)布內(nèi)容的摘要，然后使用私鑰對(duì)摘要進(jìn)行加密（加密后的數(shù)據(jù)就是數(shù)字簽名）蜓肆，然后將發(fā)布內(nèi)容颜凯、數(shù)字簽名和公鑰一起發(fā)送給接收方即可。接收方接收到內(nèi)容后仗扬，首選取出公鑰解密數(shù)字簽名症概，獲得正文的摘要數(shù)據(jù)，然后使用相同的摘要算法計(jì)算摘要數(shù)據(jù)早芭，將計(jì)算的摘要與解密的摘要進(jìn)行比較穴豫，若一致，則說明發(fā)布內(nèi)容沒有被篡改逼友。
身份認(rèn)證
計(jì)算機(jī)本身無法判斷坐在顯示器前的使用者的身份精肃。 進(jìn)一步說， 也無法確認(rèn)網(wǎng)絡(luò)的那頭究竟有誰帜乞。 可見司抱，為了 弄清究竟是誰在訪問服務(wù)器， 就得讓對(duì)方的客戶端自報(bào)家門黎烈。 比如习柠，就算正在訪問服務(wù)器的對(duì)方聲稱自己是 小明， 身份是否屬實(shí)這點(diǎn)卻也無從談起照棋。 為確認(rèn)小明本人是否真的具有訪問系統(tǒng)的權(quán)限资溃， 就需要核對(duì)“ 登錄者 本人才知道的信息”、“ 登錄者本人才會(huì)有的信息”烈炭。所以才需要以下幾種驗(yàn)證溶锭。
- Basic認(rèn)證：Basic 認(rèn)證是HTTP中非常簡單的認(rèn)證方式，因?yàn)楹唵畏叮圆皇呛馨踩贿^仍然非常常用霹疫。當(dāng)一個(gè)客戶端向一個(gè)需要認(rèn)證的HTTP服務(wù)器進(jìn)行數(shù)據(jù)請(qǐng)求時(shí)拱绑，如果之前沒有認(rèn)證過，HTTP服務(wù)器會(huì)返回401狀態(tài)碼丽蝎，要求客戶端輸入用戶名和密碼猎拨。用戶輸入用戶名和密碼后，用戶名和密碼會(huì)經(jīng)過BASE64加密附加到請(qǐng)求信息中再次請(qǐng)求HTTP服務(wù)器屠阻，HTTP服務(wù)器會(huì)根據(jù)請(qǐng)求頭攜帶的認(rèn)證信息红省，決定是否認(rèn)證成功及做出相應(yīng)的響應(yīng)。
- Digest認(rèn)證：Digest 認(rèn)證試圖解決 Basic 認(rèn)證的諸多缺陷而設(shè)計(jì)栏笆，用戶密碼在整個(gè)認(rèn)證過程中是個(gè)關(guān)鍵性要素类腮。
- SSL客戶端認(rèn)證：從使用用戶 ID 和密碼的認(rèn)證方式方面來講， 只要二者的內(nèi)容正確蛉加， 即可認(rèn)證是本人的 行為蚜枢。 但如果用戶 ID 和密碼被盜， 就很有可能被第三者冒充针饥。 利用 SSL 客戶端認(rèn)證則可以避免 該情況的發(fā)生厂抽。 SSL 客戶端認(rèn)證是借由 HTTPS 的客戶端證書完成認(rèn)證的方式。 憑借客戶端證書認(rèn)證丁眼， 服務(wù)器可確認(rèn)訪問是否來自已登錄的客戶 端筷凤。
Web攻防技術(shù)
常見的web攻擊技術(shù)有哪些呢，如下：
1，XSS 跨站攻擊技術(shù)：主要是攻擊者往網(wǎng)頁里嵌入惡意腳本藐守，或者通過改變 HTML 元素屬性來實(shí)現(xiàn)攻擊挪丢，主要原因在于開發(fā)者對(duì)用戶的變量直接使用導(dǎo)致進(jìn)入 HTML 中會(huì)被直接編譯成 JS，通常的 GET 請(qǐng)求通過 URL 來傳參卢厂，可以在 URL 中傳入惡意腳本乾蓬，從而獲取信息，解決方法：特殊字符過濾慎恒。
2任内，SQL 注入攻擊：主要是就是通過把 SQL 命令插入到 Web 表單提交或輸入域名或頁面請(qǐng)求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的 SQL 命令融柬，比如 select * from test where username="wuxu" or 1=1死嗦，這樣會(huì)使用戶跳過密碼直接登錄，具體解決方案：
- 特殊字符過濾粒氧，不要用拼接字符串的方法來湊sql語句越除。
- 對(duì) sql 語句進(jìn)行預(yù)編譯，比如 java 的 preparedstatement靠欢。
- 關(guān)閉錯(cuò)誤信息廊敌，攻擊者可能會(huì)通過不斷的嘗試來得到數(shù)據(jù)庫的一些信息，所以關(guān)閉錯(cuò)誤信息變得重要起來门怪。
- 客戶端對(duì)數(shù)據(jù)進(jìn)行加密骡澈，使原來傳進(jìn)來的參數(shù)因?yàn)榧用芏贿^濾掉。
- 控制數(shù)據(jù)庫的權(quán)限掷空，比如只能 select肋殴，不能 insert，防止攻擊者通過 select * from test 坦弟；drop tables這種操作护锤。
3，OS 命令注入攻擊：系統(tǒng)提供命令執(zhí)行類函數(shù)主要方便處理相關(guān)應(yīng)用場(chǎng)景的功能.而當(dāng)不合理的使用這類函數(shù)酿傍，同時(shí)調(diào)用的變量未考慮安全因素烙懦，就會(huì)執(zhí)行惡意的命令調(diào)用，被攻擊利用赤炒。主要原因是服務(wù)端在調(diào)用系統(tǒng)命令時(shí)采用的是字符串連接的方式氯析，比如 a="a.txt;rm -rf *",system("rm -rf {$a}")，這會(huì)給服務(wù)端帶去慘痛的代價(jià)莺褒，具體解決方案：
- 在程序開發(fā)時(shí)少用系統(tǒng)命令掩缓，執(zhí)行命令的參數(shù)盡量不要從外部獲取。
- 參數(shù)特殊字符過濾
4遵岩，HTTP 首部注入攻擊
5你辣，郵件首部注入攻擊：它允許惡意攻擊者注入任何郵件頭字段,BCC、CC、主題等,它允許黑客通過注入手段從受害者的郵件服務(wù)器發(fā)送垃圾郵件舍哄。主要是利用郵件系統(tǒng)傳參的bug來進(jìn)行攻擊宴凉，解決方法：1、使用正則表達(dá)式來過濾用用戶提交的數(shù)據(jù)蠢熄。例如,我們可以在輸入字符串中搜索(r 或 n)跪解。2、永遠(yuǎn)不要信任用戶的輸入签孔。3、使用外部組建和庫
6窘行，目錄遍歷攻擊：目錄遍歷是Http所存在的一個(gè)安全漏洞饥追，它使得攻擊者能夠訪問受限制的目錄，并在Web服務(wù)器的根目錄以外執(zhí)行命令罐盔。
7但绕，遠(yuǎn)程目錄包含攻擊，原理就是注入一段用戶能控制的腳本或代碼惶看，并讓服務(wù)端執(zhí)行捏顺。比如 php 中的include($filename)，而此 filename 由用戶傳入纬黎，用戶即可傳入一段惡意腳本幅骄，從而對(duì)服務(wù)其造成傷害，解決方法：當(dāng)采用文件包含函數(shù)的時(shí)候本今，不應(yīng)動(dòng)態(tài)傳入拆座，而應(yīng)該有具體的文件名，如果動(dòng)態(tài)傳入冠息，要保證動(dòng)態(tài)變量不被用戶所控制
8挪凑，會(huì)話劫持：這是一種通過獲取用戶Session ID后，使用該 Session ID 登錄目標(biāo)賬號(hào)的攻擊方法逛艰，此時(shí)攻擊者實(shí)際上是使用了目標(biāo)賬戶的有效 Session躏碳。會(huì)話劫持的第一步是取得一個(gè)合法的會(huì)話標(biāo)識(shí)來偽裝成合法用戶，因此需要保證會(huì)話標(biāo)識(shí)不被泄漏散怖，通俗一點(diǎn)就是用戶在登錄時(shí)菇绵，唯一標(biāo)示用戶身份的 session id被劫持，使得攻擊者可以用這個(gè) session id 來進(jìn)行登錄后操作杭抠，而攻擊者主要是通過 竊攘掣省：使用網(wǎng)絡(luò)嗅探，XSS 攻擊等方法獲得偏灿。而第一種方式網(wǎng)絡(luò)嗅探丹诀，我們可以通過 ssl 加密，也就是 https 來對(duì)報(bào)文進(jìn)行加密，從而防止報(bào)文被截獲铆遭，而第二種方式xss 攻擊硝桩，方式在第一種已經(jīng)給出，不再贅述枚荣。此外通過設(shè)置 HttpOnly碗脊。通過設(shè)置 Cookie 的 HttpOnly 為 true，可以防止客戶端腳本訪問這個(gè) Cookie橄妆，從而有效的防止 XSS 攻擊衙伶，還有就是設(shè)置 token 驗(yàn)證。關(guān)閉透明化Session ID害碾。透明化 Session ID 指當(dāng)瀏覽器中的 Http 請(qǐng)求沒有使用 Cookie 來存放 Session ID 時(shí)矢劲，Session ID 則使用URL來傳遞。
9慌随，會(huì)話固定：會(huì)話固定是會(huì)話劫持的一種芬沉，區(qū)別就是，會(huì)話固定是攻擊者通過某種手段重置目標(biāo)用戶的SessionID阁猜，然后監(jiān)聽用戶會(huì)話狀態(tài)丸逸；用戶攜帶sessionid進(jìn)行登錄，攻擊者獲取sessionid來進(jìn)行會(huì)話剃袍，解決方案：服務(wù)端設(shè)置用戶登錄后的sessionid與登錄前不一樣即可黄刚，另外會(huì)話劫持的方法也可以用在會(huì)話固定上
10，csrf跨站偽造請(qǐng)求攻擊：其實(shí)就是攻擊者盜用了你的身份笛园，以你的名義發(fā)送惡意請(qǐng)求隘击。
總的來說，通過輸出這么一篇文章研铆，自己的對(duì) HTTP 協(xié)議有了進(jìn)一步的認(rèn)知埋同，同時(shí)也通過寫作整理過程讓自己對(duì)某一個(gè)知識(shí)點(diǎn)有很好的聯(lián)想和串聯(lián)，積累從點(diǎn)開始棵红，然后形成面凶赁，最后就會(huì)有一個(gè)知識(shí)樹生長起來。
