Get & Post
post 更安全(不會作為url的一部分，不會被緩存，保存在服務(wù)器日志、以及瀏覽器瀏覽記錄中)
post發(fā)送的數(shù)據(jù)量更大（get有url長度限制）
post能發(fā)送更多的數(shù)據(jù)類型（get只能發(fā)送ASCII字符）
-
post比get慢
post確實比get請求慢，實測過。大概將近會慢二倍
-
post請求包含更多的請求頭
因為post需要在請求的body部分包含數(shù)據(jù)，所以會多了幾個數(shù)據(jù)描述部分的首部字段，這其實是微乎其微的
-
最重要的一條：post在真正接受數(shù)據(jù)之前會先將請求頭發(fā)送給服務(wù)器進行確認，然后才真正發(fā)送數(shù)據(jù)
post請求的過程：
a. 瀏覽器請求tcp連接（第一次握手）
b. 服務(wù)器答應(yīng)進行tcp連接（第二次握手）
c. 瀏覽器確認，并發(fā)送post請求頭（第三次握手，這個報文比較小，所以http會在此時進行第一次數(shù)據(jù)發(fā)送）
d. 服務(wù)器返回100 continue響應(yīng)
e. 瀏覽器開始發(fā)送數(shù)據(jù)
f. 服務(wù)器返回200 ok響應(yīng)
get請求的過程：
a. 瀏覽器請求tcp連接（第一次握手）
b. 服務(wù)器答應(yīng)進行tcp連接（第二次握手）
c. 瀏覽器確認，并發(fā)送get請求頭和數(shù)據(jù)（第三次握手，這個報文比較小，所以http會在此時進行第一次數(shù)據(jù)發(fā)送）
d. 服務(wù)器返回200 ok響應(yīng)
對比get 總耗時 是post'請求的 2/3 左右
- get會講數(shù)據(jù)緩存起來，而post不會
可以做個簡短的測試，使用ajax采用get方式請求靜態(tài)數(shù)據(jù)（比如html頁面，圖片）的時候，如果兩次傳輸?shù)臄?shù)據(jù)相同，第二次以后耗費的時間將在10ms以內(nèi)（chrome測試），而post每次耗費的時間都差不多……
經(jīng)測試，chrome下和firefox下如果檢測到get請求的是靜態(tài)資源，則會緩存，如果是數(shù)據(jù)，則不緩存，但是IE這個傻X啥都會緩存起來
當然，應(yīng)該沒人會用post去獲取靜態(tài)數(shù)據(jù)吧，反正我是沒看到過。
- post不能進行管道化傳輸
http權(quán)威指南中：http在的一次會話需要先建立tcp連接（大部分是tcp，但是其他安全協(xié)議也是可以的），然后才能通信，如果每次連接都只進行一次http會話，那這個連接過程占的比例太大了！
于是出現(xiàn)了持久連接：在http/1.0+中是connection首部中添加keep-alive值，在http/1.1中是在connection首部中添加persistent值，當然兩者不僅僅是命名上的差別，http/1.1中，持久連接是默認的，除非顯示在connection中添加close，否則持久連接不會關(guān)閉，而http/1.0+中則恰好相反，除非顯示在connection首部中添加keep-alive，否則在接收數(shù)據(jù)包后連接就斷開了。
出現(xiàn)了持久連接還不夠，在http/1.1中，還有一種稱為管道通信的方式進行速度優(yōu)化：把需要發(fā)送到服務(wù)器上的所有請求放到輸出隊列中，在第一個請求發(fā)送出去后，不等到收到服務(wù)器的應(yīng)答，第二個請求緊接著就發(fā)送出去，但是這樣的方式有一個問題：不安全，如果一個管道中有10個連接，在發(fā)送出9個后，突然服務(wù)器告訴你，連接關(guān)閉了，此時客戶端即使收到了前9個請求的答復(fù)，也會將這9個請求的內(nèi)容清空，也就是說，白忙活了……此時，客戶端的這9個請求需要重新發(fā)送。這對于冪等請求還好（比如get，多發(fā)送幾次都沒關(guān)系，每次都是相同的結(jié)果），如果是post這樣的非冪等請求（比如支付的時候，多發(fā)送幾次就慘了），肯定是行不通的。
所以，post請求不能通過管道的方式進行通信！
很有可能，post請求需要重新建立連接，這個過程不跟完全沒優(yōu)化的時候一樣了么？所以，在可以使用get請求通信的時候，不要使用post請求，這樣用戶體驗會更好，當然，如果有安全性要求的話，post會更好。
管道化傳輸在瀏覽器端的實現(xiàn)還需考證，貌似默認情況下大部分瀏覽器（除了opera）是不進行管道化傳輸?shù)?，除非手動開啟?。?/p>
-
-
