關於http等網絡相關知識你瞭解多少？

  HTTP能夠說是前端須要掌握的一塊領域，知識點其實不少，寫這篇文章的初衷其實也是本身想梳理一下HTTP包含哪些內容，並記錄下來，供本身之後學習參考。

一、HTTP是什麼？

  HTTP被設計於20世紀90年代初期，是一種可擴展的協議，是應用層的協議。HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是因特網上應用最爲普遍的一種網絡傳輸協議，全部的WWW文件都必須遵照這個標準。HTTP是一個基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。它是在 Web 上進行數據交換的基礎，是一種 client-server 協議。客戶端和服務端經過交換各自的消息進行交互。由像瀏覽器這樣的客戶端發出的消息叫作 requests，被服務端響應的消息叫作 responses。

二、HTTP的組成及其特色？

  HTTP由兩部分組成，客戶端請求消息和服務端響應消息（請求報文和響應報文） 。客戶端發送一個HTTP請求到服務器的請求消息包括如下格式：請求行（request line,包括請求方法、url）、請求頭（header）、空行和請求體據(queryString) 四個部分組成。HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。

  特色

• 一、簡單快速： 客戶向服務器請求服務時，只需傳送請求方法和路徑（url和method）。因爲 HTTP 協議簡單，使得 HTTP 服務器的程序規模小，於是通訊速度很快
• 二、靈活： HTTP 容許傳輸任意類型的數據對象。正在傳輸的類型由 Content-Type 加以標記.
• 三、無鏈接：無鏈接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接，採用這種方式能夠節省傳輸時間
• 四、無狀態： HTTP 協議是無狀態協議。無狀態是指協議對於事物處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能會致使每次鏈接傳送的數據量增大。

三、HTTP請求方式？

  HTTP 協議中共定義了八種方法來代表對 Request-URI 指定的資源的不一樣操做方式，具體介紹以下：

• 一、OPTIONS：返回服務器針對特定資源所支持的HTTP請求方法。也能夠利用向Web服務器發送'*'的請求來測試服務器的功能性。
• 二、HEAD：向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法能夠在沒必要傳輸整個響應內容的狀況下，就能夠獲取包含在響應消息頭中的元信息。
• 三、GET：向特定的資源發出請求。
• 四、POST：向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的建立和/或已有資源的修改。
• 五、PUT：向指定資源位置上傳其最新內容。
• 六、DELETE：請求服務器刪除 Request-URI 所標識的資源。
• 七、TRACE：回顯服務器收到的請求，主要用於測試或診斷。
• 八、CONNECT：HTTP/1.1 協議中預留給可以將鏈接改成管道方式的代理服務器。

  雖然 HTTP 的請求方式有 8 種，可是咱們在實際應用中經常使用的也就是 GET 和 POST，其餘請求方式也均可以經過這兩種方式間接的來實現。

下面就來對比一下GET和POST的區別：

應用過程當中的區別（因爲HTTP的規定和瀏覽器/服務器的限制）： 不一樣點：

不一樣點	GET	POST
使用目的	通常是信息獲取	主要是修改服務器上的資源
字數限制	使用UR傳遞參數，url的字數限制在2000個字符左右。	發送的信息字數沒有限制。
緩存	URL請求記錄會被緩存，請求參數會被完整保留在瀏覽器歷史記錄裏	不會被緩存，參數不會被保留，除非手動設置
後臺獲取數據方式	Request.QueryString	Request.Form
傳值方式	地址欄傳值	經過提交表單（body）傳值
編碼類型	支持更多的編碼類型且不對數據類型限制	只接受ASCII字符
瀏覽器回退	在瀏覽器回退時是無害的	在瀏覽器回退時會再次提交請求
安全性	參數直接暴露在URL上，不安全	安全性好
根本區別	GET產生一個TCP數據包，瀏覽器會把http header和data一併發送出去，服務器響應200（返回數據）	POST產生兩個TCP數據包，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）

相同點：

  一、GET和POST本質上就是TCP連接，並沒有差異。

  然而，在如下狀況中，請使用 POST 請求：

• 一、沒法使用緩存文件（更新服務器上的文件或數據庫）；
• 二、向服務器發送大量數據（POST 沒有數據量限制）；
• 三、發送包含未知字符的用戶輸入時，POST 比 GET 更穩定也更可靠。

四、HTTP狀態碼

下面列舉的是一些可能進程被用到的狀態碼。

1XX-消息

  這一類型的狀態碼，表明請求已被接受，須要繼續處理。這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，並以空行結束。

狀態碼	英文意思	解釋
100	Continue	客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收，且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分，或者若是請求已經完成，忽略這個響應。
101	Switching Protocols	服務器已經理解了客戶端的請求，並將經過Upgrade 消息頭通知客戶端採用不一樣的協議來完成這個請求。只有在切換新的協議更有好處的時候才應該採起相似措施
102	processing	表明處理將被繼續執行

2XX-成功

  這一類型的狀態碼，表明請求已成功被服務器接收、理解、並接受。

狀態碼	英文意思	解釋
200	Ok	請求已成功，請求所但願的響應頭或數據體將隨此響應返回。出現此狀態碼是表示正常狀態。
201	Created	請求已經被實現，並且有一個新的資源已經依據請求的須要而創建，且其 URI 已經隨Location 頭信息返回。假如須要的資源沒法及時創建的話，應當返回 '202 Accepted'。
202	Accepted	服務器已接受請求，但還沒有處理。返回202狀態碼的響應的目的是容許服務器接受其餘過程的請求（例如某個天天只執行一次的基於批處理的操做），而沒必要讓客戶端一直保持與服務器的鏈接直到批處理操做所有完成。
203	Non-Authoritative Information	服務器已成功處理了請求，但返回的實體頭部元信息不是在原始服務器上有效的肯定集合，而是來自本地或者第三方的拷貝。
204	No Content	服務器成功處理了請求，但不須要返回任何實體內容，而且但願返回更新了的元信息。 因爲204響應被禁止包含任何消息體，所以它始終以消息頭後的第一個空行結尾。
205	Reset Content	服務器成功處理了請求，且沒有返回任何內容。可是與204響應不一樣，返回此狀態碼的響應要求請求者重置文檔視圖。該響應主要是被用於接受用戶輸入後，當即重置表單，以便用戶可以輕鬆地開始另外一次輸入。與204響應同樣，該響應也被禁止包含任何消息體，且以消息頭後的第一個空行結束。
206	Partial Content	服務器已經成功處理了部分 GET 請求。相似於 FlashGet 或者迅雷這類的 HTTP下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解爲多個下載段同時下載。
207	Multi-Status	表明以後的消息體將是一個XML消息，而且可能依照以前子請求數量的不一樣，包含一系列獨立的響應代碼。

3XX-重定向

  這類狀態碼錶明須要客戶端採起進一步的操做才能完成請求。一般，這些狀態碼用來重定向，後續的請求地址（重定向目標）在本次響應的 Location 域中指明。

狀態碼	英文意思	解釋
300	Multiple Choices	被請求的資源有一系列可供選擇的回饋信息，每一個都有本身特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器可以自行選擇一個首選的地址進行重定向。
301	Moved Permanently	被請求的資源已永久移動到新位置
302	Move Temporarily	請求的資源臨時從不一樣的 URI響應請求。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。 若是這不是一個 GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認。 只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。
303	See Other	對應當前請求的響應能夠在另外一個 URL 上被找到，並且客戶端應當採用 GET 的方式訪問那個資源。這個方法的存在主要是爲了容許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的 URI 不是原始資源的替代引用。同時，303響應禁止被緩存。固然，第二個請求（重定向）可能被緩存。
304	Not Modified	若是客戶端發送了一個帶條件的 GET 請求且該請求已被容許，而文檔的內容（自上次訪問以來或者根據請求的條件）並無改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，所以始終以消息頭後的第一個空行結尾。 該響應必須包含如下的頭信息：Date、ETag 和/或 Content-Location、Expires, Cache-Control，和/或Vary
305	Use Proxy	被請求的資源必須經過指定的代理才能被訪問

4XX-請求錯誤

  這類的狀態碼錶明瞭客戶端看起來可能發生了錯誤，妨礙了服務器的處理。

狀態碼	英文意思	解釋
400	Bad Request	一、語義有誤，當前請求沒法被服務器理解。二、請求參數有誤。
401	Unauthorized	當前請求須要用戶驗證。該響應必須包含一個適用於被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息。
403	Forbidden	服務器已經理解請求，可是拒絕執行它。
404	Not Found	請求失敗，請求所但願獲得的資源未被在服務器上發現。
405	Method Not Allowed	請求行中指定的請求方法不能被用於請求相應的資源。
406	Not Acceptable	請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體。
407	Proxy Authentication Required	客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個 Proxy-Authenticate 用以進行身份詢問。
408	Request Timeout	請求超時。客戶端沒有在服務器預備等待的時間內完成一個請求的發送。客戶端能夠隨時再次提交這一請求而無需進行任何更改。
409	Method Not Allowed	因爲和被請求的資源的當前狀態之間存在衝突，請求沒法完成。用戶被認爲可以解決衝突，而且會從新提交新的請求。
411	Length Required	服務器拒絕在沒有定義 Content-Length 頭的狀況下接受請求。在添加了代表請求消息體長度的有效 Content-Length 頭以後，客戶端能夠再次提交該請求。
413	Request Entity Too Large	服務器拒絕處理當前請求，由於該請求提交的實體數據大小超過了服務器願意或者可以處理的範圍。
414	Request-URI Too Long	請求的URI 長度超過了服務器可以解釋的長度，所以服務器拒絕對該請求提供服務。這比較少見，一般的狀況包括：一、本應使用POST方法的表單提交變成了GET方法，致使查詢字符串（Query String）過長。二、重定向URI 「黑洞」，例如每次重定向把舊的 URI 做爲新的 URI 的一部分，致使在若干次重定向後 URI 超長。
415	Unsupported Media Type	對於當前請求的方法和所請求的資源，請求中提交的實體並非服務器中所支持的格式，所以請求被拒絕。

5XX-服務器錯誤

  這類狀態碼錶明瞭服務器在處理請求的過程當中有錯誤或者異常狀態發生，也有多是服務器意識到以當前的軟硬件資源沒法完成對請求的處理。

狀態碼	英文意思	解釋
500	Internal Server Error	通常來講，這個問題都會在服務器端的源代碼出現錯誤時出現。
501	Not Implemented	服務器沒法識別請求的方法，而且沒法支持其對任何資源的請求。
502	Bad Gateway	做爲網關或者代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應。
503	Service Unavailable	因爲臨時的服務器維護或者過載，服務器當前沒法處理請求。注意：503狀態碼的存在並不意味着服務器在過載的時候必須使用它。某些服務器只不過是但願拒絕客戶端的鏈接。
504	Gateway Timeout	做爲網關或者代理工做的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。
505	HTTP Version Not Supported	服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本
506	Use Proxy	被請求的資源必須經過指定的代理才能被訪問

六、HTTP的緩存機制？

  緩存機制無處不在，有客戶端緩存（cookie、localstorage等），服務端緩存（session），代理服務器緩存等。在HTTP中具備緩存功能的是瀏覽器緩存。 HTTP緩存做爲web性能優化的重要手段，對於從事web開發的朋友有重要的意義。

 6.1緩存的分類

  緩存分爲強制緩存和協商緩存。

• 強制緩存：當本地緩存中含有請求的數據且（及緩存時間還未過時）時，客戶端直接從本地緩存中獲取數據。當本地緩存沒有所請求的數據時，客戶端的纔會從服務端獲取數據。
    對於強制緩存，服務器響應的header中會用兩個字段來代表——Expires和Cache-Control。
    一、Expires
    Exprires的值爲服務端返回的數據到期時間。當再次請求時的請求時間小於返回的此時間，則直接使用緩存數據。但因爲服務端時間和客戶端時間可能有偏差，這也將致使緩存命中的偏差，另外一方面，Expires是HTTP1.0的產物，故如今大多數使用Cache-Control替代。   二、Cache-Control

  Cache-Control有不少屬性，不一樣的屬性表明的意義也不一樣。 
    private：客戶端能夠緩存  
    public：客戶端和代理服務器均可以緩存  
    max-age=t：緩存內容將在t秒後失效  
    no-cache：須要使用協商緩存來驗證緩存數據  
    no-store：全部內容都不會緩存。  
    must-revalidate：緩存在考慮使用一個陳舊的資源時，必須先驗證它的狀態，已過時的緩存將不被使用
  複製代碼

• 協商緩存：又稱對比緩存，客戶端會先從本地緩存中獲取到一個緩存數據的標識(ETag)， 而後服務器檢查該ETag證是否失效，若是沒有失效服務端會返回304，此時客戶端直接從緩存中獲取所請求的數據，若是標識失效，服務端會返回更新後的數據。
  協商緩存又分兩種狀況。

  狀況1：根據Last-Modified來進行協商緩存

  Last-Modified： 服務器在響應請求時，會告訴瀏覽器資源的最後修改時間。

  if-Modified-Since: 瀏覽器再次請求服務器的時候，請求頭會包含此字段，後面跟着在緩存中得到的最後修改時間。服務端收到此請求頭髮現有if-Modified-Since，則與被請求資源的最後修改時間進行對比，若是一致則返回304和響應報文頭，瀏覽器只須要從緩存中獲取信息便可。
  從字面上看，就是說：從某個時間節點算起，是否文件被修改了。
  一、若是真的被修改：那麼開始傳輸響應一個總體，服務器返回：200 OK。
  二、若是沒有被修改：那麼只需傳輸響應header，服務器返回：304 Not Modified（沒有響應體）。

  if-Unmodified-Since: 從字面上看, 就是說: 從某個時間點算起, 是否文件沒有被修改。
  一、若是沒有被修改:則開始`繼續'傳送文件: 服務器返回: 200 OK。
  二、若是文件被修改:則不傳輸,服務器返回: 412 Precondition failed (預處理錯誤) 。

  Last-Modified也有不足之處，若是實在服務器上，一個資源被修改了，但其實際內容並無發生改變，會由於Last-Modified時間匹配不上而返回整個實體給客戶端（即便客戶端緩存裏有一個如出一轍的資源。爲了解決這個問題，因此HTTP1.1推出了ETag）。

  狀況2：根據ETag（HTTP1.1產物）來進行協商緩存

  Etag： ETag 是URL的Entity Tag，用於標示URL對象是否改變，區分不一樣語言和Session等等。具體內部含義是服務器控制的，就像Cookie那樣。ETag由服務器端生成，而後服務器經過響應頭髮送給客戶端。
  客戶端使用**（If-Match/If-None-Match）** 這個條件判斷請求來驗證資源是否修改。
  第一次請求
  1.客戶端發起 HTTP GET 請求一個文件；
  2.服務器處理請求，返回文件內容和一堆Header，固然包括ETag(例如"2e681a-6-5d044840")(假設服務器支持ETag生成和已經開啓了ETag)，狀態碼200。
  第二次請求
  一、客戶端發起 HTTP GET 請求一個文件，注意這個時候客戶端同時發送一個If-None-Match頭，這個頭的內容就是第一次請求時服務器返回的Etag：2e681a-6-5d0448402。
  二、服務器檢查該ETag，並判斷出該頁面自上次客戶端請求以後是否被修改，所以If-None-Match爲False，即沒有被修改，則響應header和空的body，瀏覽器直接從緩存中獲取數據信息。返回狀態碼304。若是ETag被修改了，說明資源被改動過，則響應整個資源內容，返回狀態碼200。
  可是實際應用中因爲Etag的計算是使用算法來得出的，而算法會佔用服務端計算的資源，全部服務端的資源都是寶貴的，因此就不多使用Etag了。

  6.二、若是服務器同時設置了Cache-Control:max-age和Expires以及ETag(If-None-Match)、If-Modified-Since（Last Modified）時，怎麼辦？
  具體判斷過程以下所示。

• 當發送一個服務器請求時，瀏覽器首先會進行緩存過時判斷。瀏覽器根據緩存過時時間判斷緩存文件是否過時。
  情景一(Cache-Control等瀏覽器本地判斷)：
    若沒有過時，則不向服務器發送請求，直接使用緩存中的結果，此時咱們在瀏覽器控制檯中能夠看到 200 OK(from cache) ，此時的狀況就是徹底使用緩存，瀏覽器和服務器沒有任何交互的。
  情景二(服務器端判斷)：
    若已過時，則向服務器發送請求，此時請求中會帶上設置的文件修改時間和ETag，而後進行資源更新判斷。這要分兩種情形進行判斷。
    情形一： 若兩種判斷的結論都是文件沒有被修改過，則服務器就不給瀏覽器發index.html的內容了，直接告訴它，文件沒有被修改過，你用你那邊的緩存吧—— 304 Not Modified， 此時瀏覽器就會從本地緩存中獲取index.html的內容。
    情形二： 若文件修改時間和ETag判斷有任意一個沒有經過，則服務器會受理這次請求。並從服務器加載數據。
  
  總結： 兩類緩存機制能夠同時存在，強制緩存的優先級高於協商緩存，當執行強制緩存時，若是expire字段對應的時間還未過時，則直接使用本地緩存數據，過時了再進行緩存協商。總而言之，先在瀏覽器端判斷緩存是否過時，沒有過時則使用本地緩存（狀態碼爲200 from cache）。過時了再進行協商緩存，若是經過判斷ETag和文件最後修改時間，發現請求文件都沒被修改過，則直接從本地緩存中獲取數據（狀態碼爲304 Not Modified）。若是有一個修改了都會從服務器從新加載數據（狀態碼爲200 Ok）

七、HTTP是如何基於TCP/IP通訊的？

  爲了準確無誤地把數據送達目標處，TCP協議採用了三次握手策略。 用TCP協議把數據包送出去後，TCP不會對傳送後的狀況置之不理，它必定會向對方確認是否成功送達。握手過程當中使用了TCP的標誌：SYN和ACK。
  一、發送端首先發送一個帶SYN標誌的數據包給對方。（發送端發數據包）
  二、接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。(接收端表示知道)
  三、最後，發送端再回傳一個帶ACK標誌的數據包，表明"握手"結束。若在握手過程當中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的數據包。 (接收端回傳數據包)

  斷開一個TCP鏈接則須要「四次揮手」：

  一、第一次揮手：主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的數據傳送，也就是主動關閉方告訴被動關閉方：我已經不會再給你發數據了(固然，在FIN包以前發送出去的數據，若是沒有收到對應的ACK確認報文，主動關閉方依然會重發這些數據)，可是，此時主動關閉方還能夠接受數據。（主動關閉方將不會發送數據）
  二、第二次揮手：被動關閉方收到FIN包後，發送一個ACK給對方。(被動關閉方知道將不會收到數據)
  三、第三次揮手：被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的數據傳送，也就是告訴主動關閉方，個人數據也發送完了，不會再給你發數據了。(被動關閉方將不會發送數據)
  四、第四次揮手：主動關閉方收到FIN後，發送一個ACK給被動關閉方至此，完成四次揮手。(主動關閉方知道將不會收到數據)

八、TCP與UDP的區別?

• TCP（Transmission Control Protocol，傳輸控制協議）是基於鏈接的協議，也就是說，在正式收發數據前，必須和對方創建可靠的鏈接。一個TCP鏈接必需要通過三次「對話」才能創建起來。
• UDP（User Data Protocol，用戶數據報協議）是與TCP相對應的協議。它是面向非鏈接的協議，它不與對方創建鏈接，而是直接就把數據包發送過去。udp實時性比較好，可是質量就不敢保證了。UDP適用於一次只傳送少許數據、對可靠性要求不高的應用環境。

九、常見web安全及防禦原理?

 一、XSS(Cross Site Scripting)

  跨站腳本攻擊。惡意攻擊者往Web頁面裏插入惡意的Script代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的Script代碼會被執行，從而達到惡意攻擊用戶的目的。分爲存儲型和反射型兩類。

  存儲型XSS： 存儲型XSS，持久化，代碼是存儲在服務器中的，如在我的信息或發表文章等地方，加入代碼，若是沒有過濾或過濾不嚴，那麼這些代碼將儲存到服務器中，用戶訪問該頁面的時候觸發代碼執行。這種XSS比較危險，容易形成蠕蟲，盜竊cookie。

  反射型XSS： 非持久化，須要欺騙用戶本身去點擊連接才能觸發XSS代碼（服務器中沒有這樣的頁面和內容），通常容易出如今搜索頁面。

  常見攻擊手段：
  一、攻擊者在論壇中放一個看似安全的連接，騙取用戶點擊後，竊取cookie中的用戶私密信息；
  二、或者攻擊者在論壇中加一個惡意表單，當用戶提交表單的時候，卻把信息傳送到攻擊者的服務器中，而不是用戶本來覺得的信任站點。

  常見防護手段：
  一、代碼裏對用戶輸入的地方和變量都須要仔細檢查長度和對"<",">",";","’"等特殊字符作過濾(長度限制及特殊字符判斷)；
  二、任何內容寫到頁面以前都必須加以encode，避免不當心把html tag弄出來（encode解密）。
  三、首先，避免直接在cookie中泄露用戶隱私，例如email、密碼等等。其次，經過將cookie和系統ip綁定來下降cookie泄露後的危險。這樣攻擊者獲得的cookie沒有實際價值，不可能拿來重放。最後，若是網站不須要在瀏覽器端對cookie進行操做，能夠在Set-Cookie末尾加上HttpOnly來防止javascript代碼直接獲取cookie(cookie)。
  四、儘可能採用POST而非GET提交表單。

 二、CSRF(Cross-site request forgery)

  跨站請求僞造。也被稱爲「One Click Attack」或者Session Riding。攻擊經過在受權用戶訪問的頁面中包含連接或者腳本的方式工做。與XSS的區別在於：XSS是獲取信息，不須要提早知道其餘用戶頁面的代碼和數據包。CSRF是代替用戶完成指定的動做，須要知道其餘用戶頁面的代碼和數據包。與XSS攻擊相比，CSRF攻擊每每不大流行和難以防範，因此被認爲比XSS更具危險性。

  要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：
  一、登陸受信任網站A，並在本地生成Cookie。
  二、在不登出A的狀況下，訪問危險網站B。

  常見攻擊手段 ：一個網站用戶Bob可能正在瀏覽聊天論壇，而同時另外一個用戶Alice也在此論壇中，而且後者剛剛發佈了一個具備Bob銀行連接的圖片消息。設想一下，Alice編寫了一個在Bob的銀行站點上進行取款的form提交的連接，並將此連接做爲圖片src。若是Bob的銀行在cookie中保存他的受權信息，而且此cookie沒有過時，那麼當Bob的瀏覽器嘗試裝載圖片時將提交這個取款form和他的cookie，這樣在沒經Bob贊成的狀況下便受權了此次事務。

  CSRF的防護手段
  一、服務端的CSRF方式方法不少樣，但總的思想都是一致的，就是在客戶端頁面增長僞隨機數。
  二、經過驗證碼的方法。
  三、對於web站點，將持久化的受權方法（例如cookie或者HTTP受權）切換爲瞬時的受權方法（在每一個form中提供隱藏field）。一種相似的方式是在form中包含祕密信息、用戶指定的代號做爲cookie以外的驗證。

 三、sql注入（來自百度百科）

  就是經過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來講，它是利用現有應用程序，將（惡意的）SQL命令注入到後臺數據庫引擎執行。

  防護方法：
  1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，能夠經過正則表達式，或限制長度；對單引號和 雙"-"進行轉換等
  2.永遠不要使用動態拼裝sql，可使用參數化的sql或者直接使用存儲過程進行數據查詢存取。
  3.永遠不要使用管理員權限的數據庫鏈接，爲每一個應用使用單獨的權限有限的數據庫鏈接。
  4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。
  5.應用的異常信息應該給出儘量少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝
  6.sql注入的檢測方法通常採起輔助軟件或網站平臺來檢測，軟件通常採用sql注入檢測工具jsky，網站平臺就有億思網站安全平臺檢測工具。MDCSOFT SCAN等。採用MDCSOFT-IPS能夠有效的防護SQL注入，XSS攻擊等。

參考文檔：
一、HTTP----HTTP緩存機制
二、程序員都該懂點 HTTP
三、HTTP 緩存
四、LTTP緩存-MDN
五、99%的人都理解錯了HTTP中GET與POST的區別