前言
對於HTTP協議，想必大家都不陌生，在工作中經常用到，特別是針對移動端和前端開發人員來說，要獲取服務端數據，基本走的網絡請求都是基於HTTP協議，特別是RESTFUL + JSON 這種搭配特別主流。那如果讓大家具體講講HTTP協議背后的歷史、原理、交互流程、與HTTPS區別、身份認證、Web攻防技術等等信息，大家能講的出來嗎，反正我講的也是一知半解，雖然會經常看這方面的文章，但也只是在具體項目進行開發過程中碰到對某個概念不清楚，才會去特意看下，卻沒有特意去總結歸納為一直知識點，沒有完整的表達描述過，其實對這個知識點還是沒掌握好的，所以用寫作方式來進行闡述是很好一個方式，目前也正在踐行着。
思維導圖
在寫作之前，這篇文章主要想講的內容在以下這張圖中，通過做思維導圖方式來表達一篇文章內容，我覺得邏輯會特別清楚，同時也是對某個知識點會很好進行總結歸納。
HTTP歷史
發展由來
在1989 年 3 月， 互聯網還只屬於少數人。 在這一互聯網的黎明期， HTTP 誕生了。CERN（ 歐洲核子研究組織）的蒂姆 • 伯納斯 - 李（ Tim BernersLee）博士提出了一種能讓遠隔兩地的研究者們共享知識的設想。 最初設想 的 基本理念是： 借助多文檔之間相互關聯形成的超文本（ HyperText），連成可相互參閱的 WWW（ World Wide Web，萬維網）。並且版本從 HTTP 1.0 到 HTTP 1.1 再到現在的 HTTP 2.0，目前主流版本還是基於 HTTP 1.1，HTTP 協議同時也是目前互聯網上應用最為廣泛的一種網絡協議，所有的 WWW 文件都必須遵守這個標准，設計HTTP 最初的目的是為了提供一種發布和接收 HTML 頁面的方法。
TCP/IP
我們都知道 HTTP 協議在 根據 TCP/IP 網絡分層來看，它是屬於應用層，TCP/IP 網絡分層總共有5層，它是屬於最上層，它的下一層則是 TCP/IP 傳輸層，如圖所示：
從邏輯平行來看，發送方和接受方都是處於同一平行層，發送方每層傳遞的信息會在下一層進行信息封裝加密，然后逐層傳遞，通過實際物理鏈路進行傳遞，然后接收方接收到信息進行解密分析，不斷把報文頭信息進行還原，最后處理發送方發送過來的信息，處理完之后，再用同樣的方式傳遞回去，兩者傳輸通信方式是全雙工模式。在此之前需要一個建立連接過程，所謂的三次握手，通信結束也有斷開連接過程，也就是四次握手斷開操作。
在講述 HTTP 協議為何了解 TCP/IP 內容呢，因為我們需要知道 HTTP 協議實際通信過程是怎么樣的，它所依賴的環境是怎么樣的，從切面角度去看，實際是經歷了這5層通信，從平面去看，默認以為是客戶端與服務端僅僅進行平層通信而已，那是因為封裝的方便。
HTTP 1.1
因為目前主流在用的還是以 HTTP 1.1 版本為主，那就用這個版本來分析。
HTTP請求協議詳解
一個典型HTTP1.1的請求協議報文結構，大體上可以分為三塊，即請求行、頭部、消息主體。
請求行
請求行包含HTTP請求方法、請求的URL、HTTP協議版本三個內容，它們之間以空格間隔，並以回車+換行結束。HTTP請求方法有下面幾種,常用的有GET、POST請求。
- OPTIONS
- GET
- HEAD
- POST
- DELETE
- TRACE
- CONNECT
請求頭部
頭部可以分成三個部分，為常用頭域、請求頭域、實體頭域。其中常用頭域和實體頭域部分內容在響應協議部分也有相同的定義。
常用頭域
| 常用頭域名稱 | 作用描述 |
|---|---|
| Cache-Control | 緩存控制 |
| Connection | HTTP 1.1默認是支持長連接的(Keep-Alive)，如果不希望支持長連接則需要在此域中寫入close |
| Date | 表明消息產生的日期和時間 |
| Pragma | |
| Trailer | |
| Transfer-Encoding | 告知接收端為了保證報文的可靠傳輸，對報文采用了什么編碼方式 |
| Upgrade | 給出了發送端可能想要”升級”使用的新版本或協議 |
| Via | 顯示了報文經過的中間節點(代理、網關) |
| Warning |
請求頭域
| 請求頭域名稱 | 作用描述 |
|---|---|
| Accept | 指明請求端可以接受處理的媒體類型 |
| Accept-Charset | 指明請求端可以接受的字符集 |
| Accept-Encoding | 指明請求端可以接受的編碼格式 |
| Authorization | 授權 |
| Expect | 允許客戶端列出某請求所要求的服務器行為 |
| From | 提供了客戶端用戶的E-mail地址 |
| Host | 指明請求端的網絡主機和端口號 |
| If-Match | 服務端在響應頭部里面返回ETag信息，客戶端請求時在頭部添加If-Match（值為響應的ETag），服務端接收后判斷ETag是否相同，若相同則處理請求，否則不處理請求。 |
| If-Modified-Since | 客戶端在請求某一資源文件時，在頭部加上If-Modified-Since(值為該資源文件的最后修改時間)，服務端接收后將客戶端上報的修改時間與服務器存儲的文件的最后修改時間做對比，如果相同，說明資源文件沒有更新，返回304狀態碼，告訴客戶端使用原來的緩存文件。否則返回資源內容。 |
| If-None-Match | 服務端在響應頭部里面返回ETag信息，客戶端請求時在頭部添加If-None-Match(值為響應的ETag)，服務端接收后判斷ETag是否相同，若相同，說明資源沒有更新，返回304狀態碼，告訴客戶端使用原來的緩存文件。否則返回資源內容。 |
| If-Range | 該頭域與Range頭域一起使用，服務端在響應頭部里面返回ETag信息,客戶端請求時在頭部添加If-Range（值為響應的ETag)，服務端接收后判斷ETag是否相同，若相同，則返回狀態碼206，返回內容為Range指定的字節范圍。若不相同，則返回狀態碼200，返回內容為整個實體。 |
| If-Unmodified-Since | 客戶端在請求某一資源文件時，在頭部加上If-Modified-Since(值為該資源文件的最后修改時間)，端接收后將客戶端上報的修改時間與服務器存儲的文件的最后修改時間做對比，如果相同，則返回資源內容，如果不相同則返回狀態碼412。 |
| Max-Forwards | 配合TRACE、OPTIONS方法使用，限制在通往服務器的路徑上的代理或網關的數量。 |
| Proxy-Authorization | 代理授權 |
| Range | 表示客戶端向服務端請求指定范圍的字節數量:Range:bytes=0-500表示請求第1個到第501個的字節數量。Range:bytes=100-表示請求第101到文件倒數第一個字節的字節數量。Range:bytes=-500表示請求最后500個字節的數量。Range可以同時指定多組(Range:bytes=500-600,601-999)。並不是所有的服務端都支持字節范圍請求的，如果支持字節范圍請求，服務端會返回狀態碼206，若不支持則會返回200，客戶端需要根據狀態碼來判斷服務端是否支持字節范圍操作。此域可用於斷點下載，即在斷點處請求后面的內容，也可用於多線程下載同一個文件，每個線程負責一個文件的一部分下載工作，多個線程協同完成整個文件的下載。 |
| Referer | 用於指定客戶端請求的來源，是從搜索引擎過來的？還是從其它網站鏈接過來的？服務器根據此域，有時可以用做防盜鏈處理，不在指定范圍內的來源，統統拒絕。 |
| TE | 指明客戶端可以接受哪些傳輸編碼。 |
實體頭域
| 實體頭域名稱 | 作用描述 |
|---|---|
| Allow | 指明被請求的資源所支持的方法，如GET、HEAD、PUT |
| Content-Encoding | 指明實體內容所采用的編碼方式 |
| Content-Language | 指明實體內容使用的語言 |
| Content-Length | 指明請求實體的字節數量 |
| Content-Location | 可以用來為實體提供對應資源的位置 |
| Content-MD5 | 指定實體內容的MD5，用於內容的完整性校驗(base64的128位MD5) |
| Content-Range | |
| Content-Type | 指定實體的媒體類型 |
| Expires | 指明實體的過期時間 |
| Last-Modified | 指明實體最后被修改的時間 |
HTTP響應協議詳解
HTTP1.1的響應協議報文結構，大體上可以分為三塊，即狀態行、頭部、消息主體。
狀態行
狀態行包含HTTP協議版本、狀態碼、原因短語三個內容，它們之間以空格間隔，並以回車+換行結束。
狀態碼由三位數字組成，第一位數字定義了響應類型，主要有如下五種類型的狀態碼
| 狀態碼類型 | 作用描述 |
|---|---|
| 1xx | 報告（請求被接收，繼續處理） |
| 2xx | 成功（請求被成功的接收並處理） |
| 3xx | 重發 |
| 4xx | 客戶端出錯（客戶端錯誤的協議格式和不能處理的請求） |
| 5xx | 服務器出錯（服務器無法完成有效的請求處理） |
狀態碼和對應的原因短語詳細描述
| 狀態碼 | 原因短語 | 中文描述 |
|---|---|---|
| 100 | Continue | 繼續 |
| 101 | Switching Protocols | 切換協議 |
| 200 | OK | 成功 |
| 201 | Created | 已創建 |
| 202 | Accepted | 接受 |
| 203 | Non-Authoritative information | 非權威信息 |
| 204 | No Content | 無內容 |
| 205 | Reset Content | 重置內容 |
| 206 | Partial Content | 部分內容 |
| 300 | Multiple Choices | 多個選擇 |
| 301 | Moved Permanently | 永久移動 |
| 302 | Found | 發現 |
| 303 | See Other | 見其它 |
| 304 | Not Modified | 沒有改變 |
| 305 | Use Proxy | 使用代理 |
| 307 | Temporary Redirect | 臨時重發 |
| 400 | Bad Request | 壞請求 |
| 401 | Unauthorized | 未授權的 |
| 402 | Payment Required | 必需的支付 |
| 403 | Forbidden | 禁用 |
| 404 | Not Found | 沒有找到 |
| 405 | Method Not Allowed | 方法不被允許 |
| 406 | Not Acceptable | 不可接受的 |
| 407 | Proxy Authentication Required | 需要代理驗證 |
| 408 | Request Timeout | 請求超時 |
| 409 | Confilict | 沖突 |
| 410 | Gone | 不存在 |
| 411 | Length Required | 長度必需 |
| 412 | Precondition Failed | 先決條件失敗 |
| 413 | Request Entity Too Large | 請求實體太大 |
| 414 | Request-URI Too Long | 請求URI太長 |
| 415 | Unsupported Media Type | 不支持的媒體類型 |
| 416 | Requested Range Not Satisfiable | 請求范圍不被滿足 |
| 417 | Expectation Failed | 期望失敗 |
| 500 | Internal Server Error | 內部服務器錯誤 |
| 501 | Not Implemented | 服務端沒有實現 |
| 502 | Bad Gateway | 壞網關 |
| 503 | Service Unavailable | 服務不能獲得 |
| 504 | Gateway Timeout | 網關超時 |
| 505 | HTTP Version Not Supported | HTTP協議版本不支持 |
響應頭域
| 響應頭域名稱 | 作用描述 |
|---|---|
| Accept-Ranges | 服務器向客戶端指明服務器對范圍請求的接受度 |
| Age | 從原始服務器到代理緩存形成的估算時間（以秒計，非負） |
| ETag | 實體標簽 |
| Location | 指定重定向的URI |
| Proxy-Autenticate | 它指出認證方案和可應用到代理的該URL上的參數 |
| Retry-After | 如果實體暫時不可取，通知客戶端在指定時間之后再次嘗試 |
| Server | 指明服務器用於處理請求的軟件信息 |
| Vary | 告訴下游代理是使用緩存響應還是從原始服務器請求 |
| WWW-Authenticate | 表明客戶端請求實體應該使用的授權方案 |
交互流程
整體通信其實就是發送/響應過程，一個請求過去，對方有響應內容來返回，請求發送和響應回答方式，同時 HTTP 1.1 的特點是無狀態的、快速響應的，一次連接則馬上就斷開。HTTP 2.0 則是相反，完善了 HTTP 1.1 出現的問題，兩者連接是可復用的，同時可支持並行發送，一次多個文件傳遞，多個文件響應，支持傳遞的文件大小以二進制方式，這樣確保可支持更大文件，在安全性上比 HTTP 1.1上更強大，具體細節可查閱相關文檔。
URL 和 URI
這里有必要提下 URL 和 URI 這個兩個名詞的區別。URL表示標記了一個WWW互聯網資源（用地址標記），並給出了他的訪問地址。而URI表示一個網絡資源，僅此而已。
HTTPS
通信流程
具體步驟：
步驟 1：客戶端通過發送 Client Hello 報文開始 SSL 通信。 報文中包含客戶端支持的 SSL 的指定版本、 加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
步驟 2：服務器可進行 SSL 通信時， 會以 Server Hello 報文作為應答。 和客戶端一樣， 在報文中包含 SSL 版本 以及加密組件。 服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
步驟 3：之后服務器發送 Certificate 報文。 報文中包含公開密鑰證書。
步驟 4：最后服務器發送 Server Hello Done 報文通知客戶端， 最初階段的 SSL 握手協商部分結束。
步驟 5：SSL 第一次握手結束之后， 客戶端以 Client Key Exchange 報文作為回應。 報文中包含通信加密中使用 的一種被稱為 Pre- master secret 的隨機密碼串。 該報文已用步驟 3 中的公開密鑰進行加密。
步驟 6：接着客戶端繼續發送 Change Cipher Spec 報文。 該報文會提示服務器， 在此報文之后的通信會采用 Pre- master secret 密鑰加密。
步驟 7：客戶端發送 Finished 報文。 該報文包含連接至今全部報文的整體校驗值。 這次握手協商是否能夠成功， 要以服務器是否能夠正確解密該報文作為判定標准。
步驟 8：服務器同樣發送 Change Cipher Spec 報文。
步驟 9：服務器同樣發送 Finished 報文。
步驟 10：服務器和客戶端的 Finished 報文交換完畢之后， SSL 連接就算建立完成。 當然， 通信會受到 SSL 的保護。 從此處開始進行應用層協議的通信， 即發送 HTTP 請求。
步驟 11： 應用層協議通信， 即發送 HTTP 響應。
步驟 12： 最后 由 客戶 端斷開連接。 斷開連接時， 發送 close_ notify 報文。 上圖做了一些省略， 這步之后再 發送 TCP FIN 報文來關閉與 TCP 的通信。
加密算法
常見的加密算法可以分成三類，對稱加密算法，非對稱加密算法和Hash算法。
對稱加密
指加密和解密使用相同密鑰的加密算法。對稱加密算法的優點在於加解密的高速度和使用長密鑰時的難破解性。假設兩個用戶需要使用對稱加密方法加密然后交換數據，則用戶最少需要2個密鑰並交換使用，如果企業內用戶有n個，則整個企業共需要n×(n-1) 個密鑰，密鑰的生成和分發將成為企業信息部門的惡夢。對稱加密算法的安全性取決於加密密鑰的保存情況，但要求企業中每一個持有密鑰的人都保守秘密是不可能的，他們通常會有意無意的把密鑰泄漏出去——如果一個用戶使用的密鑰被入侵者所獲得，入侵者便可以讀取該用戶密鑰加密的所有文檔，如果整個企業共用一個加密密鑰，那整個企業文檔的保密性便無從談起。
常見的對稱加密算法：DES、3DES、DESX、Blowfish、IDEA、RC4、RC5、RC6和AES
非對稱加密
指加密和解密使用不同密鑰的加密算法，也稱為公私鑰加密。假設兩個用戶要加密交換數據，雙方交換公鑰，使用時一方用對方的公鑰加密，另一方即可用自己的私鑰解密。如果企業中有n個用戶，企業需要生成n對密鑰，並分發n個公鑰。由於公鑰是可以公開的，用戶只要保管好自己的私鑰即可，因此加密密鑰的分發將變得十分簡單。同時，由於每個用戶的私鑰是唯一的，其他用戶除了可以可以通過信息發送者的公鑰來驗證信息的來源是否真實，還可以確保發送者無法否認曾發送過該信息。非對稱加密的缺點是加解密速度要遠遠慢於對稱加密，在某些極端情況下，甚至能比非對稱加密慢上1000倍。
常見的非對稱加密算法：RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）
Hash算法
Hash算法特別的地方在於它是一種單向算法，用戶可以通過Hash算法對目標信息生成一段特定長度的唯一的Hash值，卻不能通過這個Hash值重新獲得目標信息。因此Hash算法常用在不可還原的密碼存儲、信息完整性校驗等。
常見的Hash算法：MD2、MD4、MD5、HAVAL、SHA、SHA-1、HMAC、HMAC-MD5、HMAC-SHA1
數字證書和數字簽名證書
數字證書是由權威的CA機構頒發的無法被偽造的證書，用於校驗發送方實體身份的認證。解決如上問題，只需要發送方A找一家權威的CA機構申請頒發數字證書，證書內包含A的相關資料信息以及A的公鑰，然后將正文A、數字證書以及A生成的數字簽名發送給B，此時中間人M是無法篡改正文內容而轉發給B的，因為M不可能擁有這家CA的私鑰，無法隨機制作數字證書。當然，如果M也申請了同一家CA的數字證書並替換發送修改后的正文、M的數字證書和M的數字簽名，此時B接收到數據時，會校驗數字證書M中的信息與當前通信方是否一致，發現數字證書中的個人信息為M並非A，說明證書存在替換風險，可以選擇中斷通信。
為什么CA制作的證書是無法被偽造的？其實CA制作的數字證書內還包含CA對證書的數字簽名，接收方可以使用CA公開的公鑰解密數字簽名，並使用相同的摘要算法驗證當前數字證書是否合法。制作證書需要使用對應CA機構的私鑰，因此CA頒發的證書是無法被非法偽造的（CA的私鑰泄露不在考慮討論與考慮范圍內）。
數字證書簽名的基礎就是非對稱加密算法和數字簽名，其無法偽造的特性使得其應用面較廣，HTTPS中就使用了數字證書來保證握手階段服務端傳輸的公鑰的可靠性。
數字簽名是非對稱加密算法和摘要算法的一種應用，能夠保證信息在傳輸過程中不被篡改，也能保證數據不能被偽造。使用時，發送方使用摘要算法獲得發布內容的摘要，然后使用私鑰對摘要進行加密（加密后的數據就是數字簽名），然后將發布內容、數字簽名和公鑰一起發送給接收方即可。接收方接收到內容后，首選取出公鑰解密數字簽名，獲得正文的摘要數據，然后使用相同的摘要算法計算摘要數據，將計算的摘要與解密的摘要進行比較，若一致，則說明發布內容沒有被篡改。
身份認證
計算機本身無法判斷坐在顯示器前的使用者的身份。 進一步說， 也無法確認網絡的那頭究竟有誰。 可見，為了 弄清究竟是誰在訪問服務器， 就得讓對方的客戶端自報家門。 比如，就算正在訪問服務器的對方聲稱自己是 小明， 身份是否屬實這點卻也無從談起。 為確認小明本人是否真的具有訪問系統的權限， 就需要核對“ 登錄者 本人才知道的信息”、“ 登錄者本人才會有的信息”。所以才需要以下幾種驗證。
- Basic認證：Basic 認證是HTTP中非常簡單的認證方式，因為簡單，所以不是很安全，不過仍然非常常用。當一個客戶端向一個需要認證的HTTP服務器進行數據請求時，如果之前沒有認證過，HTTP服務器會返回401狀態碼，要求客戶端輸入用戶名和密碼。用戶輸入用戶名和密碼后，用戶名和密碼會經過BASE64加密附加到請求信息中再次請求HTTP服務器，HTTP服務器會根據請求頭攜帶的認證信息，決定是否認證成功及做出相應的響應。
- Digest認證：Digest 認證試圖解決 Basic 認證的諸多缺陷而設計，用戶密碼在整個認證過程中是個關鍵性要素。
- SSL客戶端認證：從使用用戶 ID 和密碼的認證方式方面來講， 只要二者的內容正確， 即可認證是本人的 行為。 但如果用戶 ID 和密碼被盜， 就很有可能被第三者冒充。 利用 SSL 客戶端認證則可以避免 該情況的發生。 SSL 客戶端認證是借由 HTTPS 的客戶端證書完成認證的方式。 憑借客戶端證書認證， 服務器可確認訪問是否來自已登錄的客戶 端。
Web攻防技術
常見的web攻擊技術有哪些呢，如下：
1，XSS 跨站攻擊技術：主要是攻擊者往網頁里嵌入惡意腳本，或者通過改變 HTML 元素屬性來實現攻擊，主要原因在於開發者對用戶的變量直接使用導致進入 HTML 中會被直接編譯成 JS，通常的 GET 請求通過 URL 來傳參，可以在 URL 中傳入惡意腳本，從而獲取信息，解決方法：特殊字符過濾。
2，SQL 注入攻擊：主要是就是通過把 SQL 命令插入到 Web 表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的 SQL 命令，比如 select * from test where username="wuxu" or 1=1，這樣會使用戶跳過密碼直接登錄，具體解決方案：
- 特殊字符過濾，不要用拼接字符串的方法來湊sql語句。
- 對 sql 語句進行預編譯，比如 java 的 preparedstatement。
- 關閉錯誤信息，攻擊者可能會通過不斷的嘗試來得到數據庫的一些信息，所以關閉錯誤信息變得重要起來。
- 客戶端對數據進行加密，使原來傳進來的參數因為加密而被過濾掉。
- 控制數據庫的權限，比如只能 select，不能 insert，防止攻擊者通過 select * from test ；drop tables這種操作。
3，OS 命令注入攻擊：系統提供命令執行類函數主要方便處理相關應用場景的功能.而當不合理的使用這類函數，同時調用的變量未考慮安全因素，就會執行惡意的命令調用，被攻擊利用。主要原因是服務端在調用系統命令時采用的是字符串連接的方式，比如 a="a.txt;rm -rf *",system("rm -rf {$a}")，這會給服務端帶去慘痛的代價，具體解決方案：
- 在程序開發時少用系統命令，執行命令的參數盡量不要從外部獲取。
- 參數特殊字符過濾
4，HTTP 首部注入攻擊
5，郵件首部注入攻擊：它允許惡意攻擊者注入任何郵件頭字段,BCC、CC、主題等,它允許黑客通過注入手段從受害者的郵件服務器發送垃圾郵件。主要是利用郵件系統傳參的bug來進行攻擊，解決方法：1、使用正則表達式來過濾用用戶提交的數據。例如,我們可以在輸入字符串中搜索(r 或 n)。2、永遠不要信任用戶的輸入。3、使用外部組建和庫
6，目錄遍歷攻擊：目錄遍歷是Http所存在的一個安全漏洞，它使得攻擊者能夠訪問受限制的目錄，並在Web服務器的根目錄以外執行命令。
7，遠程目錄包含攻擊，原理就是注入一段用戶能控制的腳本或代碼，並讓服務端執行。比如 php 中的include($filename)，而此 filename 由用戶傳入，用戶即可傳入一段惡意腳本，從而對服務其造成傷害，解決方法：當采用文件包含函數的時候，不應動態傳入，而應該有具體的文件名，如果動態傳入，要保證動態變量不被用戶所控制
8，會話劫持：這是一種通過獲取用戶Session ID后，使用該 Session ID 登錄目標賬號的攻擊方法，此時攻擊者實際上是使用了目標賬戶的有效 Session。會話劫持的第一步是取得一個合法的會話標識來偽裝成合法用戶，因此需要保證會話標識不被泄漏，通俗一點就是用戶在登錄時，唯一標示用戶身份的 session id被劫持，使得攻擊者可以用這個 session id 來進行登錄后操作，而攻擊者主要是通過 竊取：使用網絡嗅探，XSS 攻擊等方法獲得。而第一種方式網絡嗅探，我們可以通過 ssl 加密，也就是 https 來對報文進行加密，從而防止報文被截獲，而第二種方式xss 攻擊，方式在第一種已經給出，不再贅述。此外通過設置 HttpOnly。通過設置 Cookie 的 HttpOnly 為 true，可以防止客戶端腳本訪問這個 Cookie，從而有效的防止 XSS 攻擊，還有就是設置 token 驗證。關閉透明化Session ID。透明化 Session ID 指當瀏覽器中的 Http 請求沒有使用 Cookie 來存放 Session ID 時，Session ID 則使用URL來傳遞。
9，會話固定：會話固定是會話劫持的一種，區別就是，會話固定是攻擊者通過某種手段重置目標用戶的SessionID，然后監聽用戶會話狀態；用戶攜帶sessionid進行登錄，攻擊者獲取sessionid來進行會話，解決方案：服務端設置用戶登錄后的sessionid與登錄前不一樣即可，另外會話劫持的方法也可以用在會話固定上
10，csrf跨站偽造請求攻擊：其實就是攻擊者盜用了你的身份，以你的名義發送惡意請求。
總的來說，通過輸出這么一篇文章，自己的對 HTTP 協議有了進一步的認知，同時也通過寫作整理過程讓自己對某一個知識點有很好的聯想和串聯，積累從點開始，然后形成面，最后就會有一個知識樹生長起來。