HTTP學習筆記 - 台部落

1. HTTP請求方法

1. GET

用來請求已被URL識別的資源。
GET請求是冪等的，也就是說，每次請求GET的結果必須一樣。
GET請求的參數放在url後面，大部分瀏覽器對url的長度有限制，因此，使用GET請求上傳數據有大小限制。
GET上的數據類型只允許使用ASCII字符
GET請求的資源可以緩存

2. POST

用於向服務器傳送數據
POST請求的數據放在請求實體中
POST的數據類型沒有限制，支持二進制數據

POST和GET的區別：

GET請求數據放在url裏面，傳送數據有限；POST數據放在請求體，傳送數據不限制大小。
GET數據類型只能用ASCII碼，post支持任意數據類型。
GET請求的資源可以緩存，POST請求永遠不緩存。
POST請求較安全。
GET請求一般用於請求資源，POST用於可能改變服務器狀態。
GET請求產生一個TCP數據包，POST請求產生兩個TCP數據包。
原因：對於GET請求，瀏覽器會把header和數據一起發送出去，服務器返回200和數據。而對於POST請求，瀏覽器先發送http header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok和數據）。

3. HEAD

獲取響應行、響應頭
HEAD方法跟GET方法相同，只不過服務器響應時不會返回消息體。經常用來測試超鏈接的有效性、可用性和最近的修改。(通過last-modified、if-modified-since或者ETag)

4. PUT

客戶端向服務器傳送數據，取代指定文件的內容。
關於使用PUT請求和使用POST請求，如果一個資源重複更新，產生的效果是一樣的，使用PUT請求，否則，使用POST請求。
PUT請求是冪等的（相同的請求得到相同的響應結果，GET，HEAD，PUT，DELETE）

5. DELETE

客戶端讓服務器刪除url對應的資源

2. HTTP請求報文

舉例

    GET / HTTP/1.1
    Host: www.baidu.com
    Connection: keep-alive
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
    Referer: https://www.baidu.com/s?wd=HTTP%20%E5%8D%8F%E8%AE%AE%E6%9C%89%E5%87%A0%E7%A7%8D%E5%92%8C.....
    Accept-Encoding: gzip, deflate, sdch, br
    Accept-Language: zh-CN,zh;q=0.8
    Cookie: BIDUPSID=670A04B660AAF2716D3120BEAF946A11; BAIDUID=2454D4....

1. 請求行

依次爲：請求方法，請求的URL， HTTP版本

2. 請求頭

緊接請求行的，因此和請求行沒有分隔。
用來說明服務器要使用的附加信息，如下圖：

3. 請求實體

請求頭後面必須空一行，然後纔到請求體，即使沒有請求體，也要空一行。
請求體可以添加任意的其他數據。

3. HTTP響應報文

舉例：

HTTP/1.1 200 OK
Server: bfe/1.0.8.18
Date: Mon, 16 Jan 2017 06:35:24 GMT
Content-Type: text/html;charset=utf-8
Connection: keep-alive
Cache-Control: private
Expires: Mon, 16 Jan 2017 06:35:24 GMT
Content-Encoding: gzip
Set-Cookie: BDSVRTM=104; path=/

1. 響應行

依次爲：HTTP版本、狀態碼、狀態消息

2. 響應頭

用來說明客戶端要使用的一些附加信息，也就是一些參數。

3. 響應實體

響應頭後面必須空一行

4. 常見狀態碼

2XX 成功

200 OK

204 No Content：請求已經成功處理，但是返回的響應報文不包含實體的主體部分。一般在只需要從客戶端往服務器發送信息，而不需要返回數據時使用。

206 Partial Content

3XX 重定向

301 Moved Permanently：永久性重定向

302 Found：臨時性重定向

303 See Other

注：雖然 HTTP 協議規定 301、302 狀態下重定向時不允許把 POST 方法改成 GET 方法，但是大多數瀏覽器都會把 301、302 和 303 狀態下的重定向把 POST 方法改成 GET 方法。

304 Not Modified：如果請求報文首部包含一些條件，例如：If-Match，If-ModifiedSince，If-None-Match，If-Range，If-Unmodified-Since，但是不滿足條件，則服務器會返回 304 狀態碼。

307 Temporary Redirect：臨時重定向，與 302 的含義類似，但是 307 要求瀏覽器不會把重定向請求的 POST 方法改成 GET 方法。

4XX 客戶端錯誤

400 Bad Request：請求報文中存在語法錯誤

401 Unauthorized：該狀態碼錶示發送的請求需要有通過 HTTP 認證（BASIC 認證、DIGEST 認證）的認證信息。如果之前已進行過一次請求，則表示用戶認證失敗。

403 Forbidden：請求被拒絕，服務器端沒有必要給出拒絕的詳細理由。

404 Not Found

5XX 服務器錯誤

500 Internal Server Error：服務器正在執行請求時發生錯誤

503 Service Unavilable：該狀態碼錶明服務器暫時處於超負載或正在進行停機維護，現在無法處理請求。

5.HTTP緩存相關參數

1. Last-Modified和If-Modified-Since

Last-Modified屬於響應頭的參數，是服務器發給客戶端的，指示資源的最後修改時間。
If-Modified-Since是屬於請求頭的參數，是客戶端發給服務器的，與 Last-Modified配合使用：客戶端再次請求相同資源時，會將上一次請求響應報文中的Last-Modified作爲If-Modified-Since，然後發給服務器。服務器通過If-Modified-Since與服務器上的文件的實際最後修改時間做對比，如果時間一致返回304，客戶端使用本地緩存；否則返回200和新的文件內容，客戶端丟棄舊的本地內容，並緩存新的文件。

2. ETag和If-none-much

由服務端生成的一段字符串，附加在文件（image、css、js）後面，隨着文件內容的變化而變化。這樣客戶端只會重新請求獲取ETag發生變化的文件，加快瀏覽器反應速度，同時減少服務端壓力。
主要爲了解決Last-Modified無法解決的問題。（1）If-Modified-Since只能記錄秒級的修改。ETag能記錄秒級以下的修改。（2）一些文件也許會進行週期性的更改，但是它的內容並不改變（僅僅改變修改時間），這個時候，我們並不希望客戶端認爲文件被修改了，而重新GET
具體使用：與if-not-match配合使用。客戶端使用請求一個文件，服務器返回響應行、響應頭、響應體，包括該文件和ETag的值；當客戶端再次請求該文件時，請求頭中將該Etag值填入到if-not-match字段中，如果服務器發現該文件Etag沒有改變，則返回304，客戶端使用本地緩存；否則返回200和新的文件內容以及新的Etag，客戶端丟棄舊的本地內容，並緩存新的文件。

3. HTTP 1.0 緩存控制響應頭Pragma和Expire

Pragma: no-cache 。由客戶端發給服務器的，防止客戶端緩存，需要強制從服務端獲取最新數據（參數的值只能是no-cache，只有一種用法）
Exipres：由服務器返回的，設置本地緩存的過期時間（絕對時間）
例如：Expires: Sun, 16 Oct 2016 05:43:02 GMT

4. HTTP 1.1 緩存控制響應頭Cache-Control

請求、響應都可用，一般用於請求頭
Cache-Control: no-cache指示請求或響應消息不能緩存。強制客戶端每次都請求服務端最新的資源，不經過本地緩存的副本驗證。
Cache-Control: no-store 指示客戶端不保存請求和響應的副本。
Cache-Control: max-age=[秒] 客戶端副本緩存的最長時間，類似HTTP1.0 的Expires，只是此處基於請求的相對間隔來計算，而非絕對時間。
Public 響應可被任何緩存區緩存，任何情況下都得緩存該資源。
Cache-Control: Private 指示對於單個用戶的整個或部分響應消息，不能被共享緩存處理。緩存只開放給某些特定的用戶。
Cache-Control: min-fresh 客戶端想要獲取一個小於指定時間內被更新過的資源。單位爲秒。
Cache-Control: max-stale 客戶端想獲取超出緩存時間多少秒的資源。

6. cookie和session

Cookie和Session都是用來保存客戶端狀態信息的機制。
Session是在服務端保存的一個數據結構，用來跟蹤用戶的狀態，這個數據可以保存在集羣、數據庫、文件中；
Cookie是客戶端保存用戶信息的一種機制，用來記錄用戶的一些信息，也是實現Session的一種方式。
cookie常用來實現記錄用戶名密碼等功能。
當程序需要爲某個客戶端的請求創建一個Session的時候，先會查看客戶端的請求裏面是否包含sessionId，如果有，就通過sessionId查找對應的session，否則就新建一個session對象，並生成一個sessionId，這個sessionId將在本次響應中返回給用戶保存（Set-Cookie:JSESSIONID=xxxx）。
客戶端發送sessionId給服務器的方法有兩種：
1. sesionId保存在Cookie中，在請求的時候把sessionId發送給服務器(Cookie:JSESSIONID=xxxx)
2. URL重寫的方式：把sessionId直接附加在URL路徑後面，發送給服務器。
Session不會隨着瀏覽器關閉而刪除。一般來說瀏覽器關閉，存儲sessionId的Cookie在關閉瀏覽器之後被刪除了，因此，再次打開瀏覽器，去服務器找不到原來的sesion，就會覺得原來的session被刪除了。
一般會給session設置一個失效時間。當距離客戶端上一次使用session的時間超過這個失效時間，服務器就認爲這個客戶端已經停止了活動，因此刪除該session，以節省存儲空間。

7. HTTP1.0和1.1

HTTP/1.0支持長連接(Connecttion:Keep-alive)，但是默認是短連接。HTTP/1.1，默認就是長連接
HTTP/1.1支持chunked編碼（分塊編碼）傳輸，分塊傳輸編碼允許服務器在最後發送消息頭字段，實時生成消息長度。
HTTP/1.1新增了請求流水線（管道化連接）：在一個TCP連接的過程中，多個HTTP請求可以同時並行，下一個HTTP請求在上一個HTTP請求響應前就可以發起。服務端按照HTTP請求的順序返回響應。（請求&響應採用FIFO模式）
HTTP/1.1支持字節範圍請求。向服務器請求數據的一部分，該功能通過在請求頭中加入range參數來實現，在響應頭中，使用Content-Range參數表明了返回的這部分數據的偏移和長度。（可以用於實現多線程下載。）
HTTP/1.1新增了一批HTTP請求方法：OPTIONS、PUT、DELETE、TRACE、CONNECT
HTTP/1.1 引入 ETag緩存處理，新增Cache-Control緩存控制

8. HTTPS

1. 概念

運行在SSL或者TLS協議所構建的安全層之上的HTTP協議，採用對稱加密和非對稱加密結合的方式。

2. HTTPS的通信過程

3. 對稱加密和非對稱加密

對稱加密

通信雙方使用一個密匙，該密匙既用於數據加密（發送方），也用於數據解密（接收方）
對稱加密的一大缺點是密鑰的管理與分配，換句話說，如何把密鑰發送到需要解密你的消息的人的手裏是一個問題。在發送密鑰的過程中，密鑰有很大的風險會被黑客們攔截。

非對稱加密

非對稱加密爲數據的加密與解密提供了一個非常安全的方法，它使用了一對密鑰，公鑰（public key）和私鑰（private key）。私鑰只能由一方安全保管，不能外泄，而公鑰則可以發給任何請求它的人。非對稱加密使用這對密鑰中的一個進行加密，而解密則需要另一個密鑰。
比如，你向銀行請求公鑰，銀行將公鑰發給你，你使用公鑰對消息加密，那麼只有私鑰的持有人–銀行才能對你的消息解密。與對稱加密不同的是，銀行不需要將私鑰通過網絡發送出去，因此安全性大大提高。

4. TLS和SSL

SSL：（Secure Socket Layer，安全套接字層），位於可靠的面向連接的網絡層協議和應用層協議之間的一種協議層。SSL通過互相認證、使用數字簽名確保完整性、使用加密確保私密性，以實現客戶端和服務器之間的安全通訊。該協議由兩層組成：SSL記錄協議和SSL握手協議。
TLS（Transport Layer Security，傳輸層安全協議）：由SSL發展而來，是SSL更安全。用於兩個應用程序之間提供保密性和數據完整性，該協議由兩部分組成：TLS記錄協議和TLS握手協議，SSL和TLS僅保障傳輸層安全。