不清楚CSRF的，可以先看看Http基礎(chǔ)一 cookie session token和Http基礎(chǔ)二 Web安全簡介 SQL注入 XSS CSRF(token)劳翰。
一抽减、post 相比get 有很多優(yōu)點盒发，為什么現(xiàn)在的HTTP通信中大多數(shù)請求還是使用get郁竟？
1.POST 是否比 GET 安全
是的玛迄， POST要比GET安全一點點，注意棚亩，是一點點蓖议。藻肄。。說這兩者都是明文傳送當(dāng)然是沒有錯的了拒担，但是這里有一個細(xì)節(jié)，就是GET的URL會被放在瀏覽器歷史和WEB 服務(wù)器日志里面攻询。POST 發(fā)完基本就木有了从撼。。所以如果你把關(guān)鍵數(shù)據(jù)放在GET里面钧栖，被人偷窺了瀏覽器低零，或者WEB服務(wù)器被入侵日志被人倒去了，基本泄露可能性100%拯杠。而POST來說掏婶，日志沒有記錄，只要數(shù)據(jù)庫服務(wù)器不被入侵潭陪，基本還是安全的雄妥。當(dāng)然如果被抓了包，這一切都沒有什么卵用依溯，所以老厌，HTTPS該用還是得用。
2.GET 相對 POST 的優(yōu)勢是什么
最大的優(yōu)勢是黎炉， GET 的URL可以人肉手輸啊枝秤。。慷嗜。你在地址欄打個POST給我看看淀弹。本質(zhì)上面， GET 的所有信息都在URL庆械， 所以很方便的記錄下來重復(fù)使用薇溃。
所以如果你希望
- 請求中的URL可以被手動輸入
- 請求中的URL可以被存在書簽里，或者歷史里干奢，或者快速撥號里面痊焊，或者分享給別人。－ 請求中的URL是可以被搜索引擎收錄的忿峻。
- 帶云壓縮的瀏覽器薄啥，比如Opera mini/Turbo 2, 只有GET才能在服務(wù)器端被預(yù)取的。
- 請求中的URL可以被緩存逛尚。請使用GET.
大家有沒有注意到垄惧，其實這里面很多方面的要求是和網(wǎng)站的運營相關(guān)的，而不是技術(shù)相關(guān)的绰寞。任何的技術(shù)行為中到逊，其實多多少少都能看到商業(yè)的影子铣口。
反之，就用POST. 特別是有一些東西你是不想讓人家可以在瀏覽器地址欄里面可以輸入的觉壶。比如脑题，如果你設(shè)計一個blog系統(tǒng), 設(shè)計這樣一個URL來刪掉所有帖子。http://myblog.com/?action=delete_all铜靶。我只能說很快你就知道什么叫不作死就不會死這個道理了叔遂，搜索引擎的爬蟲分分鐘教你做人。
另外一個準(zhǔn)則是争剿，可以重復(fù)的交互已艰，比如取個數(shù)據(jù)，跳個頁面蚕苇， 用GET.不可以重復(fù)的操作哩掺， 比如創(chuàng)建一個條目/修改一條記錄， 用POST, 因為POST不能被緩存涩笤，所以瀏覽器不會多次提交嚼吞。WEB API 的設(shè)計相對于網(wǎng)頁來說更加復(fù)雜，同時也有GET/POST的問題蹬碧，目前主流接受的方法是RESTful
3. 這里另一個答主提到了CDN緩存
get表達的是一種冪等的誊薄，只讀的，純粹的操作锰茉，即它除了返回結(jié)果不應(yīng)該會產(chǎn)生其它副作用（如寫數(shù)據(jù)庫）呢蔫，因此絕大部分get請求（通常超過90%）都直接被CDN緩存了，這能大大減少web服務(wù)器的負(fù)擔(dān)飒筑。
而post所表達的語義是非冪等的片吊，有副作用的操作，所以必須交由web服務(wù)器處理协屡。把所有g(shù)et請求換成post俏脊，意味著主干網(wǎng)絡(luò)上的所有CDN都廢掉了，web服務(wù)器要處理的請求數(shù)量將成百上千倍地增加肤晓，顯然這不是一個聰明的做法爷贫！
二、get和post區(qū)別补憾？
1.通常的理解
w3schools關(guān)于這個問題的解答：HTTP 方法：GET 對比 POST 列出了一般的理解漫萄，比如：
- GET后退按鈕/刷新無害，POST數(shù)據(jù)會被重新提交（瀏覽器應(yīng)該告知用戶數(shù)據(jù)會被重新提交）盈匾。
- GET書簽可收藏腾务，POST為書簽不可收藏。
- GET能被緩存削饵，POST不能緩存 岩瘦。
- GET編碼類型application/x-www-form-url未巫，POST編碼類型encodedapplication/x-www-form-urlencoded 或 multipart/form-data。為二進制數(shù)據(jù)使用多重編碼启昧。
- GET歷史參數(shù)保留在瀏覽器歷史中叙凡。POST參數(shù)不會保存在瀏覽器歷史中。
- GET對數(shù)據(jù)長度有限制密末，當(dāng)發(fā)送數(shù)據(jù)時狭姨，GET 方法向 URL 添加數(shù)據(jù)；URL 的長度是受限制的（URL 的最大長度是 2048 個字符）苏遥。POST無限制。
- GET只允許 ASCII 字符赡模。POST沒有限制田炭。也允許二進制數(shù)據(jù)。
- 與 POST 相比漓柑，GET 的安全性較差教硫，因為所發(fā)送的數(shù)據(jù)是 URL 的一部分。在發(fā)送密碼或其他敏感信息時絕不要使用 GET 辆布！POST 比 GET 更安全瞬矩，因為參數(shù)不會被保存在瀏覽器歷史或 web 服務(wù)器日志中。
- GET的數(shù)據(jù)在 URL 中對所有人都是可見的锋玲。POST的數(shù)據(jù)不會顯示在 URL 中景用。
2.關(guān)于語義上的差別
一種語言是合法句子的集合。什么樣的句子是合法的呢惭蹂？可以從兩方面來判斷：語法和語義伞插。語法是和文法結(jié)構(gòu)有關(guān)，然而語義是和按照這個結(jié)構(gòu)所組合的單詞符號的意義有關(guān)盾碗。合理的語法結(jié)構(gòu)并不表明語義是合法的媚污。例如我們常說：我上大學(xué)，這個句子是符合語法規(guī)則的廷雅，也符合語義規(guī)則耗美。但是大學(xué)上我，雖然符合語法規(guī)則航缀，但沒有什么意義商架，所以說是不符合語義的。
GET的語義是請求獲取指定的資源芥玉。GET方法是安全甸私、冪等、可緩存的（除非有 Cache-ControlHeader的約束）,GET方法的報文主體沒有任何語義飞傀。
POST的語義是根據(jù)請求負(fù)荷（報文主體）對指定的資源做出處理皇型，具體的處理方式視資源類型而不同诬烹。POST不安全，不冪等弃鸦，（大部分實現(xiàn)）不可緩存绞吁。為了針對其不可緩存性，有一系列的方法來進行優(yōu)化唬格，以后有機會再研究（FLAG已經(jīng)立起）家破。
還是舉一個通俗栗子吧，在微博這個場景里购岗，GET的語義會被用在「看看我的Timeline上最新的20條微博」這樣的場景汰聋，而POST的語義會被用在「發(fā)微博、評論喊积、點贊」這樣的場景中烹困。
另外，關(guān)于HTTP中的GET和POST乾吻，瀏覽器在喊冤也提到這個觀點髓梅。
三、都2019年了绎签，還問GET和POST的區(qū)別
1.GET 和 POST 報文上的區(qū)別
先下結(jié)論枯饿，GET 和 POST 方法沒有實質(zhì)區(qū)別，只是報文格式不同诡必。
GET 和 POST 只是 HTTP 協(xié)議中兩種請求方式奢方，而 HTTP 協(xié)議是基于 TCP/IP 的應(yīng)用層協(xié)議，無論 GET 還是 POST爸舒，用的都是同一個傳輸層協(xié)議袱巨，所以在傳輸上，沒有區(qū)別碳抄。
報文格式上愉老，不帶參數(shù)時，最大區(qū)別就是第一行方法名不同
POST方法請求報文第一行是這樣的 POST /uri HTTP/1.1 \r\n
GET方法請求報文第一行是這樣的 GET /uri HTTP/1.1 \r\n
是的剖效，不帶參數(shù)時他們的區(qū)別就僅僅是報文的前幾個字符不同而已
帶參數(shù)時報文的區(qū)別呢嫉入？ 在約定中，GET 方法的參數(shù)應(yīng)該放在 url 中璧尸，POST 方法參數(shù)應(yīng)該放在 body 中
舉個例子咒林，如果參數(shù)是 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
現(xiàn)在我們知道了兩種方法本質(zhì)上是 TCP 連接爷光，沒有差別垫竞，也就是說，如果我不按規(guī)范來也是可以的。我們可以在 URL 上寫參數(shù)欢瞪，然后方法使用 POST活烙；也可以在 Body 寫參數(shù)，然后方法使用 GET遣鼓。當(dāng)然啸盏，這需要服務(wù)端支持。
2.GET 方法參數(shù)寫法是固定的嗎骑祟？
在約定中回懦，我們的參數(shù)是寫在 ? 后面，用 & 分割次企。
我們知道怯晕，解析報文的過程是通過獲取 TCP 數(shù)據(jù)，用正則等工具從數(shù)據(jù)中獲取 Header 和 Body缸棵，從而提取參數(shù)舟茶。
也就是說，我們可以自己約定參數(shù)的寫法蛉谜，只要服務(wù)端能夠解釋出來就行，一種比較流行的寫法是 http://www.example.com/user/name/chengqm/age/22崇堵。
3.POST 方法比 GET 方法安全型诚？
按照網(wǎng)上大部分文章的解釋，POST 比 GET 安全鸳劳，因為數(shù)據(jù)在地址欄上不可見狰贯。
然而，從傳輸?shù)慕嵌葋碚f赏廓，他們都是不安全的涵紊，因為 HTTP 在網(wǎng)絡(luò)上是明文傳輸?shù)模灰诰W(wǎng)絡(luò)節(jié)點上捉包幔摸，就能完整地獲取數(shù)據(jù)報文摸柄。
要想安全傳輸，就只有加密既忆，也就是 HTTPS驱负。
4.GET 方法的長度限制是怎么回事？
在網(wǎng)上看到很多關(guān)于兩者區(qū)別的文章都有這一條患雇，提到瀏覽器地址欄輸入的參數(shù)是有限的跃脊。
首先說明一點，HTTP 協(xié)議沒有 Body 和 URL 的長度限制苛吱，對 URL 限制的大多是瀏覽器和服務(wù)器的原因酪术。
瀏覽器原因就不說了，服務(wù)器是因為處理長 URL 要消耗比較多的資源翠储，為了性能和安全（防止惡意構(gòu)造長 URL 來攻擊）考慮绘雁，會給 URL 長度加限制橡疼。
5.POST 方法會產(chǎn)生兩個TCP數(shù)據(jù)包？
有些文章中提到咧七，post 會將 header 和 body 分開發(fā)送衰齐，先發(fā)送 header，服務(wù)端返回 100 狀態(tài)碼再發(fā)送 body继阻。
HTTP 協(xié)議中沒有明確說明 POST 會產(chǎn)生兩個 TCP 數(shù)據(jù)包耻涛，而且實際測試(Chrome)發(fā)現(xiàn)，header 和 body 不會分開發(fā)送瘟檩。
所以抹缕，header 和 body 分開發(fā)送是部分瀏覽器或框架的請求方法，不屬于 post 必然行為墨辛。
