HTTP筆記

「你知道當咱們在網頁瀏覽器（Web browser）的地址欄中輸入 URL 時，Web 頁面是如何呈現的嗎？」

HTTP協議

HTTP協議（HyperText Transfer Protocol）即超文本傳輸協議是用於服務器傳輸到客戶端瀏覽器的傳輸協議。Web上，服務器和客戶端利用HTTP協議進行通訊會話。

在Web上，HTTP協議使用TCP協議而不是UDP協議的緣由在於一個網頁必須傳送不少數據，並且保證其完整性。TCP協議提供傳輸控制，按順序組織數據和錯誤糾正的一系列功能。

一次HTTP操做稱爲一個事務，其工做過程可分爲四步：

一、客戶端與服務器須要創建鏈接。（好比某個超級連接，HTTP就開始了。）
二、創建鏈接後，發送請求。
三、服務器接到請求後，響應其響應信息。
四、客戶端接收服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開鏈接。

忽略掉鏈接過程是這樣的:

URI、URL與RFC

先看看官方的解釋：
URI：uniform resource identifier 統一資源標識符
URL：uniform resource location 統一資源定位符

URI用字符串標識某一互聯網資源，而URL表示資源的地點。可見URL是URI的子集。

URI要使用涵蓋所有必要信息的URI、絕對URL以及相對URL。相對URL是指從瀏覽器中基本URI處理的URL，來先看下URI的格式:

RFC：reqeust for comments 徵求修正意見書
RFC素有網絡知識聖經之稱，規定了網絡中協議的基本內容。所以許多的不一樣系統的應用程序才能夠互相訪問。

HTTP請求方式

請求行-請求方法

• GET 獲取資源
• POST 傳輸實體主體
• PUT 傳輸文件
• HEAD 獲取報文首部
• DELETE 刪除文件
• OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求
• TRACE 請求服務器回送收到的請求信息，主要用於測試或診斷
• CONNECT 要求用隧道協議鏈接代理(SSL：Secure Sockets Layer安全套接層，TLS：Transport Layer Security傳輸層安全)

get和post區別

看別人總結的吧
還有這篇

狀態碼

狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。藉助狀態碼，用戶能夠知道服務器端是正常處理了請求，仍是出現了錯誤。

常見的狀態碼

200 OK
請求成功（其後是對GET和POST請求的應答文檔。）

304 Not Modified
未按預期修改文檔。客戶端有緩衝的文檔併發出了一個條件性的請求（通常是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩衝的文檔還能夠繼續使用。

404 Not Found
服務器沒法找到被請求的頁面。
 
500 Internal Server Error
請求未完成。服務器遇到不可預知的狀況。

HTTP報文

HTTP報文由從客戶機到服務器的請求和從服務器到客戶機的響應構成。

請求我博客園首頁時發送的報文內容:

　其中最常使用的屬性是：

• URL, 即http訪問的地址
• request method, 報文的請求方式
• Remote Address,遠程地址
• status code, 狀態碼以及狀態短語
• Connection, 鏈接方式
• Content-Type頭：即是接收方實體的介質類型。
• Accept Encoding, 內容編碼
• Date頭域：時間描述
• Referer頭域：容許客戶端指定請求URL的資源地址。
• Cookie, 添加的cookie內容
• Host, 目標主機
• User-Agent, 客戶端瀏覽器的相關信息
• Set-Cookie, 指定想要在Cookie中保存的內容

持久鏈接

「HTTP 協議的初始版本中，每進行一次 HTTP 通訊就要斷開一次 TCP 鏈接。」

「爲解決上述 TCP 鏈接的問題，HTTP/1.1 和一部分的 HTTP/1.0 想出了持久鏈接（HTTP Persistent Connections，也稱爲 HTTP keep-alive 或 HTTP connection reuse）的方法。持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態。」

持久鏈接的好處在於減小了 TCP 鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。另外，減小開銷的那部分時間，使 HTTP 請求和響應可以更早地結束，這樣 Web 頁面的顯示速度也就相應提升了。
在 HTTP/1.1 中，全部的鏈接默認都是持久鏈接

管線化

「持久鏈接使得多數請求以管線化（pipelining）方式發送成爲可能。從前發送請求後需等待並收到響應，才能發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求。

這樣就可以作到同時並行發送多個請求，而不須要一個接一個地等待響應了。」

好比，當請求一個包含 10 張圖片的 HTML Web 頁面，與挨個鏈接相比，用持久鏈接可讓請求更快結束。而管線化技術則比持久鏈接還要快。請求數越多，時間差就越明顯。

內容編碼

因爲某些報文的內容過大，所以在傳輸時，爲了減小傳輸的時間，會採起一些壓縮的措施。

例如上面的報文信息中，Accept-Encoding就定義了內容編碼的格式：gzip,deflate

有下面幾種方式：

• gzip：GNU壓縮格式
• compress：UNIX系統的標準壓縮格式
• deflate：是一種同時使用了LZ77和哈弗曼編碼的無損壓縮格式
• identity：不進行壓縮

範圍請求

之前，用戶不能使用如今這種高速的帶寬訪問互聯網，當時，下載一個尺寸稍大的圖片或文件就已經很吃力了。若是下載過程當中遇到網絡中斷的狀況，那就必須重頭開始。爲了解決上述問題，須要一種可恢復的機制。所謂恢復是指能從以前下載中斷處恢復下載。

要實現該功能須要指定下載的實體範圍。像這樣，指定範圍發送的請求叫作範圍請求（Range Request）。

對一份 10 000 字節大小的資源，若是使用範圍請求，能夠只請求 5001~10 000 字節內的資源。

執行範圍請求時，會用到首部字段 Range 來指定資源的 byte 範圍。

byte 範圍的指定形式以下。

• 5001~10 000 字節

Range: bytes=5001-10000

• 從 5001 字節以後所有的

Range: bytes=5001-

• 從一開始到 3000 字節和 5000~7000 字節的多重範圍

Range: bytes=-3000, 5000-7000

針對範圍請求，響應會返回狀態碼爲 206 Partial Content 的響應報文。另外，對於多重範圍的範圍請求，響應會在首部字段 Content-Type 標明 multipart/byteranges 後返回響應報文。

若是服務器端沒法響應範圍請求，則會返回狀態碼 200 OK 和完整的實體內容。」

Cookie

HTTP 是無狀態協議，它不對以前發生過的請求和響應的狀態進行管理。也就是說，沒法根據以前的狀態進行本次的請求處理。

假設要求登陸認證的 Web 頁面自己沒法進行狀態的管理（不記錄已登陸的狀態），那麼每次跳轉新頁面不是要再次登陸，就是要在每次請求報文中附加參數來管理登陸狀態。

Cookie 技術經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。

Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。

服務器端發現客戶端發送過來的 Cookie 後，會去檢查到底是從哪個客戶端發來的鏈接請求，而後對比服務器上的記錄，最後獲得以前的狀態信息。

HTTPS

HTTP 主要有這些不足，例舉以下。

• 通訊使用明文（不加密），內容可能會被竊聽
• 不驗證通訊方的身份，所以有可能遭遇假裝
• 沒法證實報文的完整性，因此有可能已遭篡改」

這些問題不只在 HTTP 上出現，其餘未加密的協議中也會存在這類問題。

HTTPS 並不是是應用層的一種新協議。只是 HTTP 通訊接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協議代替而已。

一般，HTTP 直接和 TCP 通訊。當使用 SSL 時，則演變成先和 SSL 通訊，再由 SSL 和 TCP 通訊了。簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的 HTTP。

在採用 SSL 後，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。

SSL 是獨立於 HTTP 的協議，因此不光是 HTTP 協議，其餘運行在應用層的 SMTP 和 Telnet 等協議都可配合 SSL 協議使用。能夠說 SSL 是當今世界上應用最爲普遍的網絡安全技術。

步驟 1： 客戶端經過發送 Client Hello 報文開始 SSL 通訊。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。

步驟 2： 服務器可進行 SSL 通訊時，會以 Server Hello 報文做爲應答。和客戶端同樣，在報文中包含 SSL 版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。

步驟 3： 以後服務器發送 Certificate 報文。報文中包含公開密鑰證書。

步驟 4： 最後服務器發送 Server Hello Done 報文通知客戶端，最初階段的 SSL 握手協商部分結束。

步驟 5： SSL 第一次握手結束以後，客戶端以 Client Key Exchange 報文做爲迴應。報文中包含通訊加密中使用的一種被稱爲 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。

步驟 6： 接着客戶端繼續發送 Change Cipher Spec 報文。該報文會提示服務器，在此報文以後的通訊會採用 Pre-master secret 密鑰加密。

步驟 7： 客戶端發送 Finished 報文。該報文包含鏈接至今所有報文的總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確解密該報文做爲斷定標準。

步驟 8： 服務器一樣發送 Change Cipher Spec 報文。

步驟 9： 服務器一樣發送 Finished 報文。

步驟 10： 服務器和客戶端的 Finished 報文交換完畢以後，SSL 鏈接就算創建完成。固然，通訊會受到 SSL 的保護。今後處開始進行應用層協議的通訊，即發送 HTTP 請求。

步驟 11： 應用層協議通訊，即發送 HTTP 響應。

步驟 12： 最後由客戶端斷開鏈接。斷開鏈接時，發送 close_notify 報文。上圖作了一些省略，這步以後再發送 TCP FIN 報文來關閉與 TCP 的通訊。

在以上流程中，應用層發送數據時會附加一種叫作 MAC（Message Authentication Code）的報文摘要。MAC 可以查知報文是否遭到篡改，從而保護報文的完整性。

HTTP認證

　　有一些網址或者服務須要用戶的身份信息，所以須要隨時知道這些消息，可是確定不能每次都讓用戶輸入用戶密碼，所以關於認證就有下面幾種方式：

其中BASIC認證是最簡單的認證，大體過程以下：
1 、客戶端訪問某URL。
2 、服務器端返回401狀態碼，提示用戶輸入用戶名密碼。
3 、用戶輸入用戶名密碼，經過BASE64編碼傳輸。
4 、服務器經過認證，返回狀態碼200

經過上面的過程，就能夠發現BASIC的問題：

• 僅僅經過BASE64編碼，其實仍是屬於明文傳輸，安全性不高
• 有的瀏覽器不支持註銷

鑑於上面BASIC的問題，DIGEST作了補充，它的過程與上面相似：
1 、客戶端訪問
2 、服務器端返回質詢碼
3 、客戶端發送響應碼

這裏經過隨機的生成質詢碼來做爲計算的一種方式，客戶端依據這個質詢碼生成響應碼，進行驗證。
這樣就彌補了明文傳輸用戶密碼的風險。

SSL客戶端驗證，這個比較廣泛了！

像支付寶啊，郵政網銀啊之類的，在登陸時，都須要下載一個數字認證的東西，這個東西就屬於一種SSL客戶端的驗證。

很顯然它的缺點就是須要客戶去手動的安裝，這個對於通常的用戶來講，代價有點高。

最後一種是應用最廣泛的，經過表單記錄用戶的身份信息，可使用cookie或者session的方式保存用戶信息。