不清楚CSRF的，可以先看看Http基礎一 cookie session token和Http基礎二 Web安全簡介 SQL注入 XSS CSRF(token)。
一、post 相比get 有很多優點，爲什麼現在的HTTP通信中大多數請求還是使用get？
1.POST 是否比 GET 安全
是的， POST要比GET安全一點點，注意，是一點點。。。說這兩者都是明文傳送當然是沒有錯的了，但是這裏有一個細節，就是GET的URL會被放在瀏覽器歷史和WEB 服務器日誌裏面。POST 發完基本就木有了。。所以如果你把關鍵數據放在GET裏面，被人偷窺了瀏覽器，或者WEB服務器被入侵日誌被人倒去了，基本泄露可能性100%。而POST來說，日誌沒有記錄，只要數據庫服務器不被入侵，基本還是安全的。當然如果被抓了包，這一切都沒有什麼卵用，所以，HTTPS該用還是得用。
2.GET 相對 POST 的優勢是什麼
最大的優勢是， GET 的URL可以人肉手輸啊。。。你在地址欄打個POST給我看看。本質上面， GET 的所有信息都在URL， 所以很方便的記錄下來重複使用。
所以如果你希望
- 請求中的URL可以被手動輸入
- 請求中的URL可以被存在書籤裏，或者歷史裏，或者快速撥號裏面，或者分享給別人。－ 請求中的URL是可以被搜索引擎收錄的。
- 帶雲壓縮的瀏覽器，比如Opera mini/Turbo 2, 只有GET才能在服務器端被預取的。
- 請求中的URL可以被緩存。請使用GET.
大家有沒有注意到，其實這裏面很多方面的要求是和網站的運營相關的，而不是技術相關的。任何的技術行爲中，其實多多少少都能看到商業的影子。
反之，就用POST. 特別是有一些東西你是不想讓人家可以在瀏覽器地址欄裏面可以輸入的。比如，如果你設計一個blog系統, 設計這樣一個URL來刪掉所有帖子。http://myblog.com/?action=delete_all。我只能說很快你就知道什麼叫不作死就不會死這個道理了，搜索引擎的爬蟲分分鐘教你做人。
另外一個準則是，可以重複的交互，比如取個數據，跳個頁面， 用GET.不可以重複的操作， 比如創建一個條目/修改一條記錄， 用POST, 因爲POST不能被緩存，所以瀏覽器不會多次提交。WEB API 的設計相對於網頁來說更加複雜，同時也有GET/POST的問題，目前主流接受的方法是RESTful
3. 這裏另一個答主提到了CDN緩存
get表達的是一種冪等的，只讀的，純粹的操作，即它除了返回結果不應該會產生其它副作用（如寫數據庫），因此絕大部分get請求（通常超過90%）都直接被CDN緩存了，這能大大減少web服務器的負擔。
而post所表達的語義是非冪等的，有副作用的操作，所以必須交由web服務器處理。把所有get請求換成post，意味着主幹網絡上的所有CDN都廢掉了，web服務器要處理的請求數量將成百上千倍地增加，顯然這不是一個聰明的做法！
1.通常的理解
w3schools關於這個問題的解答：HTTP 方法：GET 對比 POST 列出了一般的理解，比如：
- GET後退按鈕/刷新無害，POST數據會被重新提交（瀏覽器應該告知用戶數據會被重新提交）。
- GET書籤可收藏，POST爲書籤不可收藏。
- GET能被緩存，POST不能緩存 。
- GET編碼類型application/x-www-form-url，POST編碼類型encodedapplication/x-www-form-urlencoded 或 multipart/form-data。爲二進制數據使用多重編碼。
- GET歷史參數保留在瀏覽器歷史中。POST參數不會保存在瀏覽器歷史中。
- GET對數據長度有限制，當發送數據時，GET 方法向 URL 添加數據；URL 的長度是受限制的（URL 的最大長度是 2048 個字符）。POST無限制。
- GET只允許 ASCII 字符。POST沒有限制。也允許二進制數據。
- 與 POST 相比，GET 的安全性較差，因爲所發送的數據是 URL 的一部分。在發送密碼或其他敏感信息時絕不要使用 GET ！POST 比 GET 更安全，因爲參數不會被保存在瀏覽器歷史或 web 服務器日誌中。
- GET的數據在 URL 中對所有人都是可見的。POST的數據不會顯示在 URL 中。
2.關於語義上的差別
一種語言是合法句子的集合。什麼樣的句子是合法的呢？可以從兩方面來判斷：語法和語義。語法是和文法結構有關，然而語義是和按照這個結構所組合的單詞符號的意義有關。合理的語法結構並不表明語義是合法的。例如我們常說：我上大學，這個句子是符合語法規則的，也符合語義規則。但是大學上我，雖然符合語法規則，但沒有什麼意義，所以說是不符合語義的。
GET的語義是請求獲取指定的資源。GET方法是安全、冪等、可緩存的（除非有 Cache-ControlHeader的約束）,GET方法的報文主體沒有任何語義。
POST的語義是根據請求負荷（報文主體）對指定的資源做出處理，具體的處理方式視資源類型而不同。POST不安全，不冪等，（大部分實現）不可緩存。爲了針對其不可緩存性，有一系列的方法來進行優化，以後有機會再研究（FLAG已經立起）。
還是舉一個通俗栗子吧，在微博這個場景裏，GET的語義會被用在「看看我的Timeline上最新的20條微博」這樣的場景，而POST的語義會被用在「發微博、評論、點贊」這樣的場景中。
另外，關於HTTP中的GET和POST，瀏覽器在喊冤也提到這個觀點。
1.GET 和 POST 報文上的區別
先下結論，GET 和 POST 方法沒有實質區別，只是報文格式不同。
GET 和 POST 只是 HTTP 協議中兩種請求方式，而 HTTP 協議是基於 TCP/IP 的應用層協議，無論 GET 還是 POST，用的都是同一個傳輸層協議，所以在傳輸上，沒有區別。
報文格式上，不帶參數時，最大區別就是第一行方法名不同
POST方法請求報文第一行是這樣的 POST /uri HTTP/1.1 \r\n
GET方法請求報文第一行是這樣的 GET /uri HTTP/1.1 \r\n
是的，不帶參數時他們的區別就僅僅是報文的前幾個字符不同而已
帶參數時報文的區別呢？ 在約定中，GET 方法的參數應該放在 url 中，POST 方法參數應該放在 body 中
舉個例子，如果參數是 name=qiming.c, age=22。
GET 方法簡約版報文是這樣的
GET /index.php?name=qiming.c&age=22 HTTP/1.1
Host: localhost
POST 方法簡約版報文是這樣的
POST /index.php HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
name=qiming.c&age=22
現在我們知道了兩種方法本質上是 TCP 連接，沒有差別，也就是說，如果我不按規範來也是可以的。我們可以在 URL 上寫參數，然後方法使用 POST；也可以在 Body 寫參數，然後方法使用 GET。當然，這需要服務端支持。
2.GET 方法參數寫法是固定的嗎？
在約定中，我們的參數是寫在 ? 後面，用 & 分割。
我們知道，解析報文的過程是通過獲取 TCP 數據，用正則等工具從數據中獲取 Header 和 Body，從而提取參數。
也就是說，我們可以自己約定參數的寫法，只要服務端能夠解釋出來就行，一種比較流行的寫法是 http://www.example.com/user/name/chengqm/age/22。
3.POST 方法比 GET 方法安全？
按照網上大部分文章的解釋，POST 比 GET 安全，因爲數據在地址欄上不可見。
然而，從傳輸的角度來說，他們都是不安全的，因爲 HTTP 在網絡上是明文傳輸的，只要在網絡節點上捉包，就能完整地獲取數據報文。
要想安全傳輸，就只有加密，也就是 HTTPS。
4.GET 方法的長度限制是怎麼回事？
在網上看到很多關於兩者區別的文章都有這一條，提到瀏覽器地址欄輸入的參數是有限的。
首先說明一點，HTTP 協議沒有 Body 和 URL 的長度限制，對 URL 限制的大多是瀏覽器和服務器的原因。
瀏覽器原因就不說了，服務器是因爲處理長 URL 要消耗比較多的資源，爲了性能和安全（防止惡意構造長 URL 來攻擊）考慮，會給 URL 長度加限制。
5.POST 方法會產生兩個TCP數據包？
有些文章中提到，post 會將 header 和 body 分開發送，先發送 header，服務端返回 100 狀態碼再發送 body。
HTTP 協議中沒有明確說明 POST 會產生兩個 TCP 數據包，而且實際測試(Chrome)發現，header 和 body 不會分開發送。
所以，header 和 body 分開發送是部分瀏覽器或框架的請求方法，不屬於 post 必然行爲。
