HTTP知識點總結

唉扯遠了，說點實在的吧。web相關的開發人員應該都知道http協議的重要性，無論是做後端還是前端，安卓還是ios，都要跟http打交道。想必用fiddler除錯web api的時候，對返回的各種4xx、5xx狀態碼感到一頭霧水絕不是什麼愉快的體驗。最近也是複習了一些相關的知識，今天就總結一下。

通常所說的網路（包括網際網路），是在tcp/ip協議族的基礎上運作的，而http是它的乙個子集。tcp/ip協議族可以分為4層，分別是應用層、傳輸層、網路層和鏈路層。下面分別介紹一下各層的作用：

三次握手

我們知道tcp和udp主要的區別是udp只負責傳送，不確保一定送達；而tcp提供可靠的位元組流服務（byte stream service），採用三次握手策略確保資料送達。三次握手的過程使用了tcp 標誌——syn（synchronize）和ack（acknowledgement）：

傳送端傳送乙個帶syn標誌的資料報給對方。

接收端收到後，回傳乙個帶有syn/ack標誌的資料報以示傳達確認資訊。

傳送端回傳乙個帶ack標誌的資料報，表示握手結束。

客戶端在應用層（http協議）發出一項想看某個web頁面的http請求。

在傳輸層（tcp協議）把從應用層處收到的資料（http請求報文）進行分割，並在各個報文上打上標記序號及埠號後**給網路層。

在網路層（ip協議），增加作為通訊目的地的mac位址後**給鏈路層。

經過以上步驟，乙個網路請求就準備齊全了。經過網路傳輸之後，接收端的伺服器在鏈路層接收到資料，按序往上層傳送，一直到應用層。到了應用層才算真正接收到由客戶端傳送過來的http請求。

傳送端在層與層之間傳輸資料時，每經過一層必定會被打上乙個該層所屬的首部資訊；反之，接收端在層與層傳輸資料時，每經過一層時會把對應的首部消去。這種把資料資訊包裝起來的做法，也叫封裝（encapsulate）。

http協議用於客戶端與伺服器端之間的通訊，協議規定，請求從客戶端發出，最後伺服器端響應該請求並返回。來看乙個請求報文的例子：

起始行的get是乙個http動詞，也稱為方法（method），它可以指定請求的資源按期望產生某種行為，隨後的字串/search.jsp指明了請求訪問的資源物件，稱為請求uri（request-uri），http/1.1即http的版本號，用來提示客戶端使用的http協議功能。所以這段報文的意思翻譯一下是這樣的：請求用get方法訪問網域名稱為g.hxgoogle.com的伺服器上的/search.jsp頁面資源。

乙個完整的請求報文由header和body組成，header包括請求方法、請求uri、協議版本、可選的請求首部欄位等，body指報文主體。下面重點介紹一下請求uri和http方法。

uri和url

uri表示統一資源識別符號，是uniform resource identifier的縮寫。rfc2396(rfc，request for comments，徵求修正意見書，一些指定http協議技術標準的文件)分別對這三個單詞進行了如下定義：

綜上所述，uri就是由某個協議方案（如http、ftp）表示的資源的定位識別符號。如下列舉幾種uri的例子：

ldap://[2001:db8::7]/c=gb?objectclass?one

mailto:[email protected]

tel:+1-816-555-1212

http方法

我們最常用的http方法是get和post，這導致很多人以為http方法只有get和post。這是不對的，這些年restful api非常流行，所以作為web開發人員至少還應該知道put和delete。當然http方法並不只有這麼幾種，下面介紹幾種http/1.1中的方法：

http響應同樣可分為header和body，它一般長這樣：

...空行(cr + lf)

...第一行是狀態行，包含http版本、表明響應結果的狀態碼和原因短語。接下來是一些首部字段，一般包括響應首部字段、通用首部字段、實體首部欄位和rfc裡未定義的首部（cookie等），最後是報文主體。下面重點說明一下狀態碼和原因短語，它們描述了本次請求的結果。

狀態碼狀態碼的第一位數字指定了響應類別，共可分為5類：

下面列舉幾種常見的錯誤碼和原因短語：

http協議的初始版本中，每進行一次http通訊就要斷開一次tcp連線。這在當年都是一些小容量文字傳輸的情況下是可行的，但隨著http的普及，傳輸過程中包含大量的情況多了起來。譬如使用瀏覽器瀏覽乙個包含多張的html頁面時，在傳送請求訪問該html頁面資源的同時，也會請求該頁面包含的其他資源如各種不同的，它們是在不同伺服器上的。如果每次請求都得重新建立一次tcp連線的話，無疑會增加通訊量的開銷，而且頻繁斷開又重連會導致頁面載入緩慢，影響使用者體驗。

持久連線（http persistent connections）

為了解決上述問題，http/1.1和一部分http/1.0開始支援持久連線。持久連線的特點是，只要任意一端沒有明確提出斷開連線，則保持tcp連線狀態。http/1.1中所有的連線預設都是持久連線。

管線化（pipelining）

持久連線使得多數請求以管線化方式傳送成為可能。以往傳送請求後需等待並收到響應後才能傳送下乙個請求，管線化技術出現後，無需等待亦可傳送下乙個請求。這就實現了多個請求的並行傳送，提高了網路通訊效率。

cookie

http是無狀態協議，它不對之前發生過的請求和響應狀態進行管理。無狀態自然可以減少伺服器的cpu及記憶體資源消耗，但有些時候我們又需要對過去的狀態進行管理，譬如登入驗證之後使用者在瀏覽該**其他網頁時應該保持登入的狀態而不是重新進行登入。當然要實現狀態管理，我們可以使用很多方法，無外乎是在伺服器端和客戶端都儲存乙個憑證，之後每次請求都帶上這個憑證，然後在伺服器端進行比對，獲取狀態資訊。http協議中引入的cookie技術，也是為了解決狀態管理問題，採用的方法也跟我上面說的差不多，只不過這是發生在協議層面，不需要自己寫很多**管理。

具體來說，cookie技術通過在請求和響應報文中寫入cookie資訊來控制客戶端狀態，過程如下：

客戶端第一次傳送請求，請求報文中沒有cookie資訊。

伺服器端生成cookie資訊，在響應報文中通過set-cookie這個首部字段，通知客戶端儲存cookie，大概長這樣：

客戶端再次傳送請求時，自動在請求報文中加入cookie值後傳送出去。大概長這樣：

伺服器端收到cookie資訊後，會去檢查從哪個客戶端發來的連線請求，然後對比伺服器上的記錄，得到之前的狀態資訊。

HTTP知識點總結

http 是超文字傳輸協議，也就是hypertext transfer protocol。uri 統一資源識別符號 url uniform resource locator，統一資源定位符 無狀態 伺服器不維護任何有關客戶端過去所發請求的資訊 主要使用 ssl secure sockets laye...

HTTP 校招知識點總結

http協議概述http報文格式請求方法與響應碼瀏覽器搜尋到頁面顯示的過程，http與tcpsession與cookieshttp1.0,1.1,2.0restful 程式設計風格https http是指超文字傳輸協議，顧名思義就是通過網路在主機之間傳遞超文字的一種協議，廣泛用於bs 瀏覽器和web...

Http協議知識點

1.型別 http伺服器會給在http中傳送的http資源物件附加乙個mime型別，接收http資源物件的客戶端會根據這個型別來判斷是否能夠進行處理，例如瀏覽器就能夠處理上百種mime型別的http資源物件 2.mime型別是一種文字標記，表示一種主要物件型別和一種特定的子型別，中間用一條斜槓來分隔...