首頁>科技>

IT程式設計師:對於那些月薪三萬以下,自稱IT工程師的碼農們,其實我們從來沒有把他們歸為我們IT工程師的隊伍。他們雖然總是以IT工程師自居,但只是他們一廂情願罷了。

此話一出,不知激起了多少(碼農)程式設計師的憤怒,卻又無可奈何,於是碼農問程式設計師。

碼農:你知道get和post請求到底有什麼區別?

程式設計師:你看這篇就知道了。

碼農:你月薪三萬了?

程式設計師:嗯。

碼農:你是怎麼做到的?

程式設計師:我做夢做到的

下面我們一起來看一下吧。

1.1 http的特點

基於tcp/ip、一種網路應用層協議、超文字傳輸協議HyperText Transfer Protocol

工作方式:客戶端請求服務端應答的模式

快速:無狀態連線

靈活:可以傳輸任意物件,物件型別由Content-Type標記

客戶端請求request訊息包括以下格式:請求行(request line)、請求頭部(header)、空行、請求資料

服務端響應response也由四個部分組成,分別是:狀態行、訊息報頭、空行、響應正文

1.2 請求方法

http請求可以使用多種請求方法。

HTTP1.0定義了三種請求方法: GET, POST 和 HEAD方法。

HTTP1.1新增了五種請求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

HTTP2.0 新的二進位制格式(Binary Format),HTTP1.x的解析是基於文字。基於文字協議的格式解析存在天然缺陷,文字的表現形式有多樣性,要做到健壯性考慮的場景必然很多,二進位制則不同,只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定採用二進位制格式,實現方便且健壯。

多路複用(MultiPlexing),即連線共享,即每一個request都是是用作連線共享機制的。一個request對應一個id,這樣一個連線上可以有多個request,每個連線的request可以隨機的混雜在一起,接收方可以根據request的 id將request再歸屬到各自不同的服務端請求裡面。

header壓縮,如上文中所言,對前面提到過HTTP1.x的header帶有大量資訊,而且每次都要重複傳送,HTTP2.0使用encoder來減少需要傳輸的header大小,通訊雙方各自cache一份header fields表,既避免了重複header的傳輸,又減小了需要傳輸的大小。

服務端推送(server push),同SPDY一樣,HTTP2.0也具有server push功能。

1 GET 請求指定的頁面資訊,並返回實體主體。

2 HEAD 類似於get請求,只不過返回的響應中沒有具體的內容,用於獲取報頭

3 POST 向指定資源提交資料進行處理請求(例如提交表單或者上傳檔案)。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。

4 PUT 從客戶端向伺服器傳送的資料取代指定的文件的內容。

6 CONNECT HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。

7 OPTIONS 允許客戶端檢視伺服器的效能。

8 TRACE 回顯伺服器收到的請求,主要用於測試或診斷。

1.3 我們耳熟能詳的的區別

http協議最常見的兩種方法GET和POST,這幾點答案其實有幾點並不準確

請求快取:GET 會被快取,而post不會

收藏書籤:GET可以,而POST不能

保留瀏覽器歷史記錄:GET可以,而POST不能

用處:get常用於取回資料,post用於提交資料

安全性:post比get安全

請求引數:querystring 是url的一部分get、post都可以帶上。 get的querystring(僅支援urlencode編碼),post的引數是放在body(支援多種編碼)

請求引數長度限制:get請求長度最多1024kb,post對請求資料沒有限制

02 常見的誤區

get和post誤區

針對上面常見的區別,如果面試的時候這麼說,肯定是有很大的毛病,剛在學校面試的時候也曾經囫圇吞棗地這樣說過,現在回過頭再想以前的錯誤認知,又有許多新的認識。

2.1 誤區一

“用處:get常用於取回資料,post用於提交資料”

曾聽到過這樣一種說法:get替換post來優化網站效能,雖然這種說法沒錯,也的確get常被用於取回資料,但是post也被一些ui框架使用於取回資料,比如kendo ui中的grid,就是用post來接受資料的。所以結論是get、post用途也是因地制宜。如果你有使用過kendo UI,會發現分頁、過濾、自定義的引數都包含在form data裡面。

請求引數

get是querystring(僅支援urlencode編碼),post是放在body(支援多種編碼)

query引數是URL的一部分,而GET、POST等是請求方法的一種,不管是哪種請求方法,都必須有URL,而URL的query是可選的,可有可無。

2.2 誤區二

“請求引數長度限制:get請求長度最多1024kb,post對請求資料沒有限制”

這句話看上去實在沒毛病啊,菜鳥教程也是這樣說的啊。雖然字面意思上沒有錯誤,但是理解一定要正確。我想說的是GET方法提交的url引數資料大小沒有限制,在http協議中沒有對url長度進行限制(不僅僅是querystring的長度),這個限制是特定的瀏覽器及伺服器對他的限制

下面就是對各種瀏覽器和伺服器的最大處理能力做一些說明

IE瀏覽器對URL的最大限制為2083個字元

Firefox (Browser):對於Firefox瀏覽器URL的長度限制為65,536個字元。

Safari (Browser):URL最大長度限制為 80,000個字元。

Opera (Browser):URL最大長度限制為190,000個字元。

Google (chrome):URL最大長度限制為8182個字元。

Apache (Server):能接受最大url長度為8,192個字元。

Microsoft Internet Information Server(IIS):能接受最大url的長度為16,384個字元。

所以為了符合所有標準,url的最好不好超過最低標準的2083個字元(2k+35)。當然在做客戶端程式時,url並不展示給使用者,只是個程式呼叫,這時長度只收web伺服器的影響了。對於中文的傳遞,一個漢字最終編碼後的字元長度是9個字元。

最常見的form表單,瀏覽器預設的form表單,預設的content-type是application/x-www-form-urlencoded,提交的資料會按照key value的方式,jquery的ajax預設的也是這種content-type。當然在post方式中新增querystring一定是可以接收的到,但是在get方式中加body引數就不一定能成功接收到了。

2.3 誤區三

“post比get安全性要高”

這裡的安全是相對性,並不是真正意義上的安全,通過get提交的資料都將顯示到url上,頁面會被瀏覽器快取,其他人檢視歷史記錄會看到提交的資料,而post不會。另外get提交資料還可能會造成CSRF攻擊。

2.4 誤區四:“GET產生一個TCP資料包;POST產生兩個TCP資料包。”

這一點理解起來還是有一定難度的,實際上,不論哪一種瀏覽器,在傳送 POST 的時候都沒有帶 Expect 頭,server 也自然不會發 100 continue。通過抓包發現,儘管會分兩次,body 就是緊隨在 header 後面傳送的,根本不存在『等待伺服器響應』這一說。

從另一個角度說,TCP 是傳輸層協議。別人問你應用層協議裡的 GET 和 POST 有啥區別,你回答說這倆在傳輸層上傳送資料的時候不一樣,確定別人不抽你?

3 http狀態碼附錄

3.1 狀態碼1xx

100 Continue:

伺服器僅接收到部分請求,但是一旦伺服器並沒有拒絕該請求,客戶端應該繼續傳送其餘的請求。

101 Switching Protocols:

伺服器轉換協議:伺服器將遵從客戶的請求轉換到另外一種協議。

102: 由WebDAV(RFC 2518):

擴充套件的狀態碼,代表處理將被繼續執行

3.2 狀態碼2xx:成功

200 OK:

請求成功(其後是對GET和POST請求的應答文件。)

201 Created:

請求被建立完成,同時新的資源被建立。

202 Accepted:

供處理的請求已被接受,但是處理未完成。

203 Non-authoritative Information:

文件已經正常地返回,但一些應答頭可能不正確,因為使用的是文件的拷貝。

204 No Content:

沒有新文件。瀏覽器應該繼續顯示原來的文件。如果使用者定期地重新整理頁面,而Servlet可以確定使用者文件足夠新,這個狀態程式碼是很有用的。

205 Reset Content:

沒有新文件。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。

206 Partial Content:

客戶傳送了一個帶有Range頭的GET請求,伺服器完成了它。

3.3 狀態碼3xx:重定向

300 Multiple Choices:

多重選擇。連結列表。使用者可以選擇某連結到達目的地。最多允許五個地址。

301 Moved Permanently:

所請求的頁面已經轉移至新的url

302 Found:

所請求的頁面已經臨時轉移至新的url。

303 See Other:

所請求的頁面可在別的url下被找到。

304 Not Modified:

未按預期修改文件。客戶端有緩衝的文件併發出了一個條件性的請求(一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文件)。伺服器告訴客戶,原來緩衝的文件還可以繼續使用。

305 Use Proxy:

客戶請求的文件應該通過Location頭所指明的代理伺服器提取。

306 Unused:

此程式碼被用於前一版本。目前已不再使用,但是程式碼依然被保留。

307 Temporary Redirect:

被請求的頁面已經臨時移至新的url。

3.4 狀態碼4xx:客戶端錯誤

400 Bad Request:

伺服器未能理解請求。

401 Unauthorized:

被請求的頁面需要使用者名稱和密碼。

401.1:

登入失敗。

401.2:

伺服器配置導致登入失敗。

401.3:

由於 ACL 對資源的限制而未獲得授權。

401.4:

篩選器授權失敗。

401.5:

ISAPI/CGI 應用程式授權失敗。

401.7:

訪問被 Web 伺服器上的 URL 授權策略拒絕。這個錯誤程式碼為 IIS 6.0 所專用。

402 Payment Required:

此程式碼尚無法使用。

403 Forbidden:

對被請求頁面的訪問被禁止。

404 Not Found:

伺服器無法找到被請求的頁面。

405 Method Not Allowed:

請求中指定的方法不被允許。

406 Not Acceptable:

伺服器生成的響應無法被客戶端所接受。

407 Proxy Authentication Required:

使用者必須首先使用代理伺服器進行驗證,這樣請求才會被處理。

408 Request Timeout:

請求超出了伺服器的等待時間。

409 Conflict:

由於衝突,請求無法被完成。

410 Gone:

被請求的頁面不可用。

411 Length Required:

“Content-Length” 未被定義。如果無此內容,伺服器不會接受請求。

412 Precondition Failed:

請求中的前提條件被伺服器評估為失敗。

413 Request Entity Too Large:

由於所請求的實體的太大,伺服器不會接受請求。

414 Request-url Too Long:

由於url太長,伺服器不會接受請求。當post請求被轉換為帶有很長的查詢資訊的get請求時,就會發生這種情況。

415 Unsupported Media Type:

由於媒介型別不被支援,伺服器不會接受請求。

416 Requested Range Not Satisfiable:

伺服器不能滿足客戶在請求中指定的Range頭。

417 Expectation Failed:

執行失敗。

423:

鎖定的錯誤。

3.5 狀態碼5** 服務端錯誤

500 Internal Server Error:

請求未完成。伺服器遇到不可預知的情況。

501 Not Implemented:

請求未完成。伺服器不支援所請求的功能。

502 Bad Gateway:

請求未完成。伺服器從上游伺服器收到一個無效的響應。

503 Service Unavailable:

請求未完成。伺服器臨時過載或宕機。

504 Gateway Timeout:

閘道器超時。

505 HTTP Version Not Supported:

伺服器不支援請求中指明的HTTP協議版本。

  • 整治雙十一購物亂象,國家再次出手!該跟這些套路說再見了
  • 現在還在用QQ的人注意了!!!