爲何get比post更快

引言

　　get和post在面試過程當中通常都會問到，通常的區別：

　　1.post更安全（不會做爲url的一部分，不會被緩存、保存在服務器日誌、以及瀏覽器瀏覽記錄中）

　　2.post發送的數據量更大（get有url長度限制）

　　3.post能發送更多的數據類型（get只能發送ASCII字符）

　　4.post比get慢

　　

　　我相信不止一我的跟我同樣有這種疑惑，既然post有這麼多優勢，那咱們爲何要使用get？甚至有個同事說，我們封裝一個ajax底層，直接不用get算了……

　　可是，get比post更快，那究竟快多少呢？表如今哪些方面？

1.post請求包含更多的請求頭

　　由於post須要在請求的body部分包含數據，因此會多了幾個數據描述部分的首部字段（如content-type），這實際上是微乎其微的

2.最重要的一條，post在真正接受數據以前會先將請求頭髮送給服務器進行確認，而後才真正發送數據

　　post請求的過程：

　　1.瀏覽器請求tcp鏈接（第一次握手）

　　2.服務器答應進行tcp鏈接（第二次握手）

　　3.瀏覽器確認，併發送post請求頭（第三次握手，這個報文比較小，因此http會在此時進行第一次數據發送）

　　4.服務器返回100 continue響應

　　5.瀏覽器開始發送數據

　　6.服務器返回200 ok響應

 

　　get請求的過程

　   1.瀏覽器請求tcp鏈接（第一次握手）

　　2.服務器答應進行tcp鏈接（第二次握手）

　　3.瀏覽器確認，併發送get請求頭和數據（第三次握手，這個報文比較小，因此http會在此時進行第一次數據發送）

　　4.服務器返回200 ok響應

 

　　也就是說，目測get的總耗是post的2/3左右

　　口說無憑，已經有網友進行測試了

　　尋根究底:Ajax請求的GET與POST方式比較

3.get會將數據緩存起來，而post不會

　　能夠作個簡短的測試，使用ajax採用get方式請求靜態數據（好比html頁面，圖片）的時候，若是兩次傳輸的數據相同，第二次之後耗費的時間將在10ms之內（chrome測試），而post每次耗費的時間都差很少……

　　經測試，chrome下和firefox下若是檢測到get請求的是靜態資源，則會緩存，若是是數據，則不緩存，可是IE這個傻X啥都會緩存起來

　　固然，應該沒人會用post去獲取靜態數據吧，反正我是沒看到過。

4.post不能進行管道化傳輸

　　http權威指南中是這樣說的：

　　http在的一次會話須要先創建tcp鏈接（大部分是tcp，可是其餘安全協議也是能夠的），而後才能通訊，若是每次鏈接都只進行一次http會話，那這個鏈接過程佔的比例太大了！

　　因而出現了持久鏈接：在http/1.0+中是connection首部中添加keep-alive值，在http/1.1中是在connection首部中添加persistent值，固然二者不只僅是命名上的差異，http/1.1中，持久鏈接是默認的，除非顯示在connection中添加close，不然持久鏈接不會關閉，而http/1.0+中則剛好相反，除非顯示在connection首部中添加keep-alive，不然在接收數據包後鏈接就斷開了。

　　出現了持久鏈接還不夠，在http/1.1中，還有一種稱爲管道通訊的方式進行速度優化：把須要發送到服務器上的全部請求放到輸出隊列中，在第一個請求發送出去後，不等到收到服務器的應答，第二個請求緊接着就發送出去，可是這樣的方式有一個問題：不安全，若是一個管道中有10個鏈接，在發送出9個後，忽然服務器告訴你，鏈接關閉了，此時客戶端即便收到了前9個請求的答覆，也會將這9個請求的內容清空，也就是說，白忙活了……此時，客戶端的這9個請求須要從新發送。這對於冪等請求還好（好比get，多發送幾回都不要緊，每次都是相同的結果），若是是post這樣的非冪等請求（好比支付的時候，多發送幾回就慘了），確定是行不通的。

　　因此，post請求不能經過管道的方式進行通訊！

　　頗有可能，post請求須要從新創建鏈接，這個過程不跟徹底沒優化的時候同樣了麼？

　　因此，在可使用get請求通訊的時候，不要使用post請求，這樣用戶體驗會更好，固然，若是有安全性要求的話，post會更好。

　　管道化傳輸在瀏覽器端的實現還需考證，貌似默認狀況下大部分瀏覽器（除了opera）是不進行管道化傳輸的，除非手動開啓！！

　：