前言
對於HTTP協議，想必你們都不陌生，在工做中常常用到，特別是針對移動端和前端開發人員來講，要獲取服務端數據，基本走的網絡請求都是基於HTTP協議，特別是RESTFUL + JSON 這種搭配特別主流。那若是讓你們具體講講HTTP協議背後的歷史、原理、交互流程、與HTTPS區別、身份認證、Web攻防技術等等信息，你們能講的出來嗎，反正我講的也是隻知其一;不知其二，雖然會常常看這方面的文章，但也只是在具體項目進行開發過程當中碰到對某個概念不清楚，纔會去特地看下，卻沒有特地去總結概括爲一直知識點，沒有完整的表達描述過，其實對這個知識點仍是沒掌握好的，因此用寫做方式來進行闡述是很好一個方式，目前也正在踐行着。php
思惟導圖
在寫做以前，這篇文章主要想講的內容在如下這張圖中，經過作思惟導圖方式來表達一篇文章內容，我以爲邏輯會特別清楚，同時也是對某個知識點會很好進行總結概括。 
前端
HTTP歷史
發展由來java
在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 頁面的方法。web
TCP/IP正則表達式
咱們都知道 HTTP 協議在 根據 TCP/IP 網絡分層來看，它是屬於應用層，TCP/IP 網絡分層總共有5層，它是屬於最上層，它的下一層則是 TCP/IP 傳輸層，如圖所示：算法
從邏輯平行來看，發送方和接受方都是處於同一平行層，發送方每層傳遞的信息會在下一層進行信息封裝加密，而後逐層傳遞，經過實際物理鏈路進行傳遞，而後接收方接收到信息進行解密分析，不斷把報文頭信息進行還原，最後處理髮送方發送過來的信息，處理完以後，再用一樣的方式傳遞回去，二者傳輸通訊方式是全雙工模式。在此以前須要一個創建鏈接過程，所謂的三次握手，通訊結束也有斷開鏈接過程，也就是四次握手斷開操做。sql
在講述 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、RC四、RC五、RC6和AES
非對稱加密
指加密和解密使用不一樣密鑰的加密算法，也稱爲公私鑰加密。假設兩個用戶要加密交換數據，雙方交換公鑰，使用時一方用對方的公鑰加密，另外一方便可用本身的私鑰解密。若是企業中有n個用戶，企業須要生成n對密鑰，並分發n個公鑰。因爲公鑰是能夠公開的，用戶只要保管好本身的私鑰便可，所以加密密鑰的分發將變得十分簡單。同時，因爲每一個用戶的私鑰是惟一的，其餘用戶除了能夠能夠經過信息發送者的公鑰來驗證信息的來源是否真實，還能夠確保發送者沒法否定曾發送過該信息。非對稱加密的缺點是加解密速度要遠遠慢於對稱加密，在某些極端狀況下，甚至能比非對稱加密慢上1000倍。
**常見的非對稱加密算法：**RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）
Hash算法
Hash算法特別的地方在於它是一種單向算法，用戶能夠經過Hash算法對目標信息生成一段特定長度的惟一的Hash值，卻不能經過這個Hash值從新得到目標信息。所以Hash算法經常使用在不可還原的密碼存儲、信息完整性校驗等。
**常見的Hash算法：**MD二、MD四、MD五、HAVAL、SHA、SHA-一、HMAC、HMAC-MD五、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來進行攻擊，解決方法：一、使用正則表達式來過濾用用戶提交的數據。例如,咱們能夠在輸入字符串中搜索(r 或 n)。二、永遠不要信任用戶的輸入。三、使用外部組建和庫
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 協議有了進一步的認知，同時也經過寫做整理過程讓本身對某一個知識點有很好的聯想和串聯，積累從點開始，而後造成面，最後就會有一個知識樹生長起來。