HTTP協議是用于客戶端和服務端之間的通信
- 請求訪問文本或圖像等資源的一端稱作為客戶端，而提供資源的一端稱作為服務端。
- 在一條HTTP通信線路上，客戶端和服務端是確定，必須有一端是客戶端和有一端是服務端。實際情況中，客戶端、服務端的角色可能會互換，但是從僅從一條通信線路上說，這兩端是確定的。
- HTTP是不保存狀態的協議HTTP協議自身不對請求和響應之間的通信狀態進行保存。
簡單的http協議
通信是從客戶端開始建立的，客戶端向服務端發送請求，服務端響應請求并且返回數據。那么就是通過請求和響應的交換達成通信。
-
客戶端發送請求的例子：
GET /index.html HTTP/1.1 HOST: hackr.jpGET表示請求的方式、方法（method），/index.html表示請求指定資源，稱為URI（request-URI），最后HTTP/1.1表示客戶端使用的協議版本。
請求報文是由請求方法、請求 URI、協議版本、可選的請求首部字段和內容實體構成的。
-
服務器響應的例子：
HTTP/1.1 200 ok Date: Tue, 10 Jul 2012 06:50:15 GMT Content-Length: 363 Content-Type: text/html <html> ...HTTP/1.1： 服務器的協議版本
200 ok： 響應的狀態碼和原因短語（簡短的解釋）
Date: Tue, 10 Jul 2012 06:50:15 GMT： 創建響應的時間
下面就是首部字段，然后空一行就是內容實體。
告知服務器意圖的HTTP方法
-
GET 獲取資源
GET方法用來請求已被已被URI識別（存在的）的資源。指定的資源經服務器解析后返回響應內容。
-
POST 傳輸實體主體
向服務器傳輸主體，POST的主要目的并不是獲取響應的主體內容。
PUT 傳輸文件
-
HEAD 獲取報文的首部
與GET類似，只是響應不會返回報文主體部分，只有頭部。
DELETE 刪除文件
-
OPTIONS 詢問支持的方法
用來查詢針對請求URI指定的資源支持的方法。
比如：// 請求 OPTIONS * HTTP/1.1 Host: www.hackr.jp // 響應 HTTP/1.1 200 OK Allow: GET,POST,HEAD,OPTIONS -
TRACE 追蹤路徑
客戶端通過TRACE方法可以查詢發出去的請求是怎么被加工修改、篡改的。一個請求想要連接到原目標服務器可能通過代理中轉，TRACE方法就是用來確認連接過程中發生的一系列的操作。但是TRACE方法本來不怎么常用，在加上它容易引發XST（Cross-Site Tracing，跨站追蹤）攻擊，通常就更不會使用了
-
CONNECT 要求用隧道協議連接代理
要求在與代理服務器通信時建立隧道，實現用隧道協議進行TCP通信。主要使用SSL（Secure Sockets Layer，安全套裝層）和TSL（Transport Layer Security，傳輸層安全）協議把通信內容加密后經網絡隧道傳輸。
持久連接節省通信量
HTTP初期的版本中，每進行一次通信就要斷開一次TCP連接，以當年通信情況來說，因為都是容量小的文本傳輸，所以即使這樣也沒有什么問題，但是現在來看，文檔中包含大量的圖片是很平常的需求，所以這種通信一次就斷掉的方法就不可取了。
-
為解決以上TCP通信問題，HTTP/1.1和一部分HTTP/1.0想出了持久連接（HTTP Persistent Connections，也稱為HTTP keep-alive或HTTP connection reuse）的方法。持久連接的特點是，只要任意一方沒有提出明確的斷開連接，則保持TCP連接狀態。
持續連接.png
在HTTP/1.1中，所有的默認連接都是持久連接，在HHTP/1.0中并沒有標準化。客戶端和服務端需要同時支持持久化才行。
使用Cookie的狀態管理
HTTP是無狀態協議，它不對之前發生過的請求和響應的狀態進行管理。也正是因為這一特性，自然可以減少服務器的CPU及內存資源的消耗。從另一側面來說，也正是HTTP協議本事是非常簡單的，所以才會被應用在各種場景中。
-
需要記錄狀態的場景：假設要求登錄認證的Web頁面本身無法進行狀態管理（不記錄的狀態），那么每次跳轉新頁面就要再次登錄，或者要在每次請求報文中附加參數來管理登錄狀態。
如果讓服務器管理全部客戶端狀態則會成為負擔
在保留無狀態這個特性的同是又要解決類似的矛盾問題，于是引入了Cookie技術。Cookie是通過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。
Cookie 會根據從服務端發送的響應報文內的一個叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值后發送出去。服務器端發現客戶端發過來的請求中包含Cookie信息，拿著Cookie信息去服務器上的記錄對比，來確定是哪一個客戶端，做相應的操作。
- 沒有Cookie.png
- 第二次請求帶Cookie.png
相應的頭部：
1.請求報文（沒有Cookie信息狀態）
GET /reader/ HTTP/1.1
Host: hackr.jp
* 首部字段沒有cookie的相關信息
2.響應報文（服務器生成Cookie信息）
HTTP/1.1 200 OK
Date: Thu, 12 Jul 2012 07:12:20 GMT
Server: Apache
<Set-Cookie: sid=1123423543234325; path=/; expires=Wed,10-Oct-12 07:12:20 GMT>
Content-Type: text/plain; charset=UTF-8
3.請求報文（自動發送保存著Cookie信息）
GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1123423543234325
github 歡迎Star，歡迎討論
