Get和Post請求

Get和Post在面試中通常都會問到，通常的區別： 
（1）post更安全（不會做爲url的一部分，不會被緩存、保存在服務器日誌、以及瀏覽器瀏覽記錄中） 
（2）post發送的數據更大（get有url長度限制） 
（3）post能發送更多的數據類型（get只能發送ASCII字符） 
（4）post比get慢 
（5）post用於修改和寫入數據，get通常用於搜索排序和篩選之類的操做（淘寶，支付寶的搜索查詢都是get提交），目的是資源的獲取，讀取數據 
雖然在開發中常常用get或者post請求，可是因爲咱們資歷經驗的欠缺，或許就重來沒有深究過什麼場合用get請求，什麼場合用post請求，我相信不止我一我的當看到第4,5條的時候，就會明白爲何面試官對咱們的回答不滿意，也明白了本身對get或post用法理解的欠缺，那麼get比post更快，究竟快多少呢？表如今那些方面？ 
1、爲何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左右，這個口說無憑，網上已經有網友進行過測試。

3.get會將數據緩存起來，而post不會 
能夠作個簡短的測試，使用ajax採用get方式請求靜態數據（好比html頁面，圖片）的時候，若是兩次傳輸的數據相同，第二次之後消耗的時間將會在10ms之內（chrome測試），而post每次消耗的時間都差很少。經測試，chrome和firefox下若是檢測到get請求的是靜態資源，則會緩存，若是是數據，則不會緩存，可是IE什麼都會緩存起來，固然，應該沒有人用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）是不進行管道化傳輸的，除非手動開啓！ 
2、get傳參最大長度的理解誤區 
1.總結 
（1）http協議並未規定get和post的長度限制 
（2）get的最大長度限制是由於瀏覽器和web服務器限制了URL的長度 
（3）不一樣的瀏覽器和web服務器，限制的最大長度不同 
（4）要支持IE，則最大長度爲2083byte，若支持Chrome，則最大長度8182byte

2.誤解 
（1）首先即便get有長度限制，也是限制的整個URL的長度，而不只僅是參數值數據長度，http協議從未規定get/post的請求長度限制是多少 
（2）所謂的請求長度限制是由瀏覽器和web服務器決定和設置的，各類瀏覽器和web服務器的設定均不同，這依賴於各個瀏覽器廠家的規定或者能夠根據web服務器的處理能力來設定。IE 和 Safari 瀏覽器 限制 2k，Opera 限制4k，Firefox 限制 8k（很是老的版本 256byte），若是超出了最大長度，大部分的服務器直接截斷，也有一些服務器會報414錯誤。

3.各個瀏覽器和web服務器的最大長度總結 
瀏覽器 
（1）IE：IE瀏覽器（Microsoft Internet Explorer） 對url長度限制是2083（2K+53），超過這個限制，則自動截斷（如果form提交則提交按鈕不起做用）。 
（2）firefox：firefox（火狐瀏覽器）的url長度限制爲 65536字符，但實際上有效的URL最大長度很多於100,000個字符。 
（3）chrome：chrome（谷歌）的url長度限制超過8182個字符返回本文開頭時列出的錯誤。 
（4）Safari：Safari的url長度限制至少爲 80 000 字符。 
（5）Opera：Opera 瀏覽器的url長度限制爲190 000 字符。Opera9 地址欄中輸入190000字符時依然能正常編輯。 
服務器 
（1）Apache：Apache能接受url長度限制爲8 192 字符 
（2）IIS：Microsoft Internet Information Server(IIS)能接受url長度限制爲16384個字符。這個是能夠經過修改的（IIS7） 
configuration/system.webServer/security/requestFiltering/requestLimits@maxQueryStringsetting.