1. HTTP簡介
HTTP協 議（HyperText Transfer Protocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機 正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先於圖形)等。
在了解HTTP如何工作之前，我們先了解計算機之間的通信。
2. 計算機相互之間的通信
互聯網的關鍵技術就是TCP/IP協議。兩台計算機之間的通信是通過TCP/IP協議在因特網上進行的。實際上這個是兩個協議：
TCP : Transmission Control Protocol 傳輸控制協議和IP： Internet Protocol 網際協議。
IP：計算機之間的通信
IP協議是計算機用來相互識別的通信的一種機制，每台計算機都有一個IP.用來在internet上標識這台計算機。 IP 負責在因特網上發送和接收數據包。通過 IP，消息（或者其他數據）被分割為小的獨立的包，並通過因特網在計算機之間傳送。IP 負責將每個包路由至它的目的地。
IP協議僅僅是允許計算機相互發消息，但它並不檢查消息是否以發送的次序到達而且沒有損壞（只檢查關鍵的頭數據）。為了提供消息檢驗功能，直接在IP協議上設計了傳輸控制協議TCP.
TCP確保數據包以正確的次序到達，並且嘗試確認數據包的內容沒有改變。TCP在IP地址之上引端口（port），它允許計算機通過網絡提供各種服務。一些端口號為不同的服務保留，而且這些端口號是眾所周知。
服務或者守護進程：在提供服務的機器上，有程序監聽特定端口上的通信流。例如大多數電子郵件通信流出現在端口25上，用於wwww的HTTP通信流出現在80端口上。
當應用程序希望通過 TCP 與另一個應用程序通信時，它會發送一個通信請求。這個請求必須被送到一個確切的地址。在雙方“握手”之后，TCP 將在兩個應用程序之間建立一個全雙工 (full-duplex) 的通信，占用兩個計算機之間整個的通信線路。TCP 用於從應用程序到網絡的數據傳輸控制。TCP 負責在數據傳送之前將它們分割為 IP 包，然后在它們到達的時候將它們重組。
TCP/IP 就是TCP 和 IP 兩個協議在一起協同工作，有上下層次的關系。
TCP 負責應用軟件（比如你的瀏覽器）和網絡軟件之間的通信。IP 負責計算機之間的通信。TCP 負責將數據分割並裝入 IP 包，IP 負責將包發送至接受者，傳輸過程要經IP路由器負責根據通信量、網絡中的錯誤或者其他參數來進行正確地尋址，然后在它們到達的時候重新組合它們。
3. HTTP協議所在的協議層
HTTP是基於TCP協議之上的。在TCP/IP協議參考模型的各層對應的協議如下圖, 
4. HTTP請求響應模型
HTTP由請求和響應構成，是一個標准的客戶端服務器模型（B/S）。HTTP協議永遠都是客戶端發起請求，服務器回送響應。見下圖:
HTTP是一個無狀態的協議。無 狀態是指客戶機（Web瀏覽器）和服務器之間不需要建立持久的連接，這意味着當一個客戶端向服務器端發出請求，然后服務器返回響應(response)， 連接就被關閉了，在服務器端不保留連接的有關信息.HTTP遵循請求(Request)/應答(Response)模型。客戶機（瀏覽器）向服務器發送請 求，服務器處理請求並返回適當的應答。所有HTTP連接都被構造成一套請求和應答。
5. HTTP工作過程
一次HTTP操作稱為一個事務，其工作整個過程如下：
1 ) 、地址解析，
如用客戶端瀏覽器請求這個頁面：http://localhost.com:8080/index.htm
從中分解出協議名、主機名、端口、對象路徑等部分，對於我們的這個地址，解析得到的結果如下：
協議名：http
主機名：localhost.com
端口：8080
對象路徑：/index.htm
在這一步，需要
2）、封裝HTTP請求數據包
把以上部分結合本機自己的信息，封裝成一個HTTP請求數據包
3）封裝成TCP包，建立TCP連接（ 在HTTP工作 開始之前，客戶機（Web瀏覽器）首先要通過網絡與服務器建立連接，該連接是通過TCP來完成的，該協議與IP協議共同構建Internet，即著名的 TCP/IP協議族，因此Internet又被稱作是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議，根據規則，只有低層協議建立之后才能， 才能進行更層協議的連接，因此，首先要建立TCP連接，一般TCP連接的端口號是80。這里是8080端口
4）客戶機發送請求命令
建立連接后，客戶機發送一個請求給服務器，請求方式的格式為：統一資源標識符（URL）、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可內容。
5）服務器響應
服務器接到請求后，給予相應的響應信息，其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。
實體消息是服務器向瀏覽器發送頭信息后，它會發送一個空白行來表示頭信息的發送到此為結束，接着，它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據
6）服務器關閉TCP連接
一般情況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP連接，然后如果瀏覽器或者服務器在其頭信息加入了這行代碼
Connection:keep-alive
TCP連接在發送后將仍然保持打開狀態，於是，瀏覽器可以繼續通過相同的連接發送請求。
6. HTTP協議棧中各層數據流
首先我們看看客戶端請求的時候，數據在各層協議的數據組織如下圖：
而服務器解析客戶機請求就是反向操作的過程，如下圖：
客戶機發起一次請求的時候：
客戶機會將請求封裝成http數據包-->封裝成Tcp數據包-->封裝成Ip數據包--->封裝成數據幀--->硬件將幀數據轉換成bit流（二進制數據）-->最后通過物理硬件（網卡芯片）發送到指定地點。
服務器硬件首先收到bit流....... 然后轉換成ip數據包。於是通過ip協議解析Ip數據包，然后又發現里面是tcp數據包，就通過tcp協議解析Tcp數據包，接着發現是http數據包通過http協議再解析http數據包得到數據。
6. HTTPS實現原理
HTTPS（全 稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL。其所用的端口號是 443。
有兩種基本的加解密算法類型：
1）對稱加密（symmetrcic encryption）：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES，RC5，3DES等；
對稱加密主要問題是共享秘鑰，除你的計算機（客戶端）知道另外一台計算機（服務器）的私鑰秘鑰，否則無法對通信流進行加密解密。解決這個問題的方案非對稱秘鑰。
2）非對稱加密：使用兩個秘鑰：公共秘鑰和私有秘鑰。私有秘鑰由一方密碼保存（一般是服務器保存），另一方任何人都可以獲得公共秘鑰。
這種密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。
下面看一下https的通信過程：
https通信的優點：
1）客戶端產生的密鑰只有客戶端和服務器端能得到；
2）加密的數據只有客戶端和服務器端才能得到明文；
3）客戶端到服務端的通信是安全的。
7. HTTP各種長度限制
1. URL長度限制
2. Post數據的長度限制
3. Cookie的長度限制
4. Html5 LocalStorage
但是這次IE比較大方，允許的最大長度是10MB
1. HTTP版本
HTTP/1.0
HTTP/1.1
HTTP-NG
2. 會話方式
HTTP/1.0
建立連接->請求->響應->斷開連接
每次連接只處理一次請求和相應，對資源的每一次訪問都要建立一個單獨的連接。
瀏覽器到服務器的每次通訊都是完全分開的。
沒有Host域，所以不可以創建基於主機頭的虛擬主機。
HTTP/1.1
在一個TCP連接中可以傳送多個HTTP請求和響應
不需要等待上次HTTP響應完畢，可以多個HTTP請求同時進行。服務器會根據瀏覽器發送的請求順序來按順序進行響應，這被稱作管線。
有Host域，可以建立虛擬主機。
3. 請求消息
結構：
請求行
若干消息頭(可選)
(CRLF)
實體內容(可選)
GET無實體內容
4. 響應消息
結構：
狀態行
若干消息頭(可選)
(CRLF)
實體內容(可選)
5. HTTP消息
對於HTTP/1.1，如果消息中包括實體內容，且沒有采用Transfer-Encoding: chunked傳輸編碼方式，則必須要有Content-Length消息頭。否則瀏覽器和服務器都不知道何時消息結束。
6. 簡單請求消息和簡單響應消息
沒有消息頭。
其中，簡單請求消息只可用於GET方式，且請求行中不指定HTTP版本號，
對於簡單請求消息，服務器將會返回簡單響應消息，只返回實體內容。
如：
ROOT /index.html
7. HTTP消息頭概述
瀏覽器通過消息頭，比如可以告訴服務器瀏覽器的國家語言版本信息，可以告訴服務器訪問者是從哪個頁面訪問到當前頁面的。
服務器通過消息頭，比如可以告訴瀏覽器隔多長時間刷新一下，用哪種字符集顯示內容，創建Cookie。
結構：
頭字段名稱(不區分大小寫):_值，值，值(CRLF)
頭字段名稱(不區分大小寫):_值，值，值(CRLF)
頭字段名稱(不區分大小寫):_值，值，值(CRLF)
(可以任意順序排列)
分為：通用信息頭、請求頭、響應頭、實體頭四類。
8. 請求行
結構：
請求方式_資源路徑_HTTP版本號(CRLF)
如：
GET /index.htm HTTP/1.1
請求方式：
| Method |
|
| GET |
請求獲取Request-URI所標識的資源 |
| POST |
在Request-URI所標識的的資源后附加新的數據 |
| HEAD |
請求獲取Request-URI所標識的資源的響應消息報頭 |
| PUT |
請求服務器存儲一個資源，並用Request-URI作為資源標識 |
| DELETE |
請求服務器刪除Request-URI所標識的資源 |
| TRACE |
請求服務器回送收到的請求信息，主要用於測試和診斷 |
| CONNECT |
保留將來使用 |
| OPTIONS |
請求查詢服務器的性能，或者查詢與資源相關的選項和需求 |
9. 狀態行
結構：
HTTP版本號_狀態碼_狀態描述(CRLF)
如：
HTTP/1.1 200 OK
10. 使用GET和POST傳遞參數
GET使用URL傳遞參數
如：
GET /List.aspx?Catagoryid=5&Cityid=23 HTTP/1.1
POST使用實體內容傳遞參數
如：
POST /List.aspx HTTP/1.1
Content-Type:application/x-www-form-urlencoded
Content-Length:22
Catagoryid=5&Cityid=23
在POST消息頭中要設置Content-Type的值為application/x-www-form-urlencoded，以及使用Content-Length 以標識實體內容的長度。
當Content-Length長度比實體內容長度短時，則會忽略多出部分的實體內容。當Content-Length少於實體長度時，則會繼續等待。
11. 響應狀態碼
狀態代碼由三位數字組成，第一位定義了響應的類別：
1xx:指示信息——表示請求已接收，繼續處理。
2xx:成功——表示請求已被成功接收、理解、接受。
3xx:重定向——要完成請求必須進行更進一步的操作。
4xx:客戶端錯誤——請求有語法錯誤或請求無法實現。
5xx:服務器端錯誤——服務器未能實現合法的請求。
常見狀態碼：
| Status-Code |
Reason-Phrase |
|
| 200 |
OK |
客戶端請求成功 |
| 206 |
|
客戶端發送了帶有Range頭的GET請求，服務器正確的返回了該范圍的數據 |
| 302/307 |
|
指出被請求的文檔已經臨時移動到別處，此文檔的新的URL在Location響應頭中給出 |
| 304 |
|
客戶機緩存的版本是最新的，客戶機應該繼續使用它 |
| 400 |
Bad Request |
客戶端請求有語法錯誤，不能被服務器理解 |
| 401 |
Unauthorized |
表示客戶機訪問的是一個受口令和密碼保護的頁面，並且在WWW-Authenticate響應頭提示客戶機應重新發出一個帶有Authorization頭的請求信息。 |
| 403 |
Forbidden |
服務器收到請求，但是拒絕提供服務 |
| 404 |
Not Found |
請求的資源不存在 |
| 500 |
Internal Server Error |
服務器端的CGI、ASP、JSP發生錯誤 |
| 503 |
Server Unavaliable |
服務器當前不能處理客戶端的請求，一段時間后可能恢復正常 |
12. 通用信息頭
通用信息頭既能用於請求消息中，也可以用於響應消息中，他包括一些與被傳輸的實體沒有關系的常用消息頭字段。
Cache-Control: no-cache
如果用於客戶機發送的請求消息時，通知代理服務器該如何處理緩存。如設置為no-cache，則代理服務器必須要去服務器驗證資源，以確保發給客戶端的文檔時最新的。
如果用於響應消息中，則通知客戶機及代理服務器如何緩存當前的響應消息。如服務器有一些資源只有實時才有意義，如網頁計數器、股票信息，這時應當在響應消息中使用no-cache，通知代理服務器和客戶端不要緩存資源。
Connection: close
用於指定處理完本次請求和響應后，客戶端與服務器是否還要繼續保持連接。當請求消息中設置了Connection: close時，則通知服務器端在響應本次請求后，斷開連接。當請求消息中設置了Connection: Keep-Alive時，則通知服務器端在響應本次請求后，不要斷開連接。
HTTP/1.1默認為Connection: Keep-Alive，所以當沒有指定該域時，則默認為Connection: Keep-Alive。
Date: Tue, 11 Jul 2000 18:23:51 GMT
用於表示HTTP消息產生的時間。必須為GMT格式。服務器返回的正常響應消息中總是包含Date頭的。
Progma: no-cache
值只能為no-cache。在HTTP/1.0中，指示客戶端不要緩存當前的響應消息。
Trailer: Date
用於指示在實體內容的后面可以出現哪些頭字段。一般情況下會將消息頭放在實體內容的前面，但也可以將消息頭放在實體內容的后面。對於這些要放在后面的消息頭，則使用Trailer來說明。上例表示：Date消息頭將放在實體內容的后面傳輸。
Transfer-Encoding: chunked
如果HTTP消息的實體內容部分采用了某種傳輸編碼方式，那么Transfer-Encoding消息頭是用於指定傳輸編碼方式的。目前的標准設置值只有chunked。Chunked表示，要將整個HTTP響應消息的實體內容分成若干段以后再進行傳輸，並且在每個分段的開始部分都要使用一個16進制的數字來表示這個即將傳輸的這個分段的大小，最后一個分段的大小必須為0，這個0分段表示這個HTTP消息傳送完畢。
服務器端程序(如ASP、JSP)並不是將資源按一個字符一個字符的發送到客戶端，而是先將資源內容寫在緩沖區中，當緩沖區寫滿時，將內容發送給客戶端。如果資源完畢，則也將緩沖區中的內容發送給客戶端。當第一次緩沖時就將已將全部內容都寫入到實體內容時，則服務器知道本消息的Content-Length，所以將會在消息頭中指明Content-Length。
Upgrade: HTTP/2.0, SHTTP/1.3
表示客戶端支持並且希望切換到的協議。
Via: HTTP/1.1 Proxy1, HTTP/1.1 Proxy2
用於表明這個HTTP請求所途徑的代理服務器的名稱和所使用的協議。這個頭的值由代理服務器進行追加。於是該頭也記錄了代理服務器的順序。
Warning: any text
用於存儲狀態碼所不能表明的一些信息。
13. 請求頭
請求頭用於客戶端在請求消息中向服務器傳遞附加消息，主要包括：客戶端可以接受的數據類型、壓縮算法、語言、以及發出請求的超鏈接所屬網頁的URL地址等信息。
Accept: text/html, image/*
用於指出客戶端程序能夠處理的MIME類型。如：服務器可以輸出png格式或gif格式等圖片，但是某些瀏覽器不支持png格式的圖片。所以服務器在響應時要檢查Accept消息頭，看瀏覽器是否支持png格式。
Accept-Charset: ISO-8859-1, Unicode-1-1
用於指出客戶端可以顯示的字符集。
Accept-Encoding: gzip, compress
用於指定客戶機可以解碼的編碼方式，主要指壓縮方式。
Accept-Language: en-gb, zh-cn
用於指定客戶機期望服務器返回哪個國家的語言的文檔。如設置Accept-Language: ja, zh-cn，則訪問www.google.com則會打開日文的谷歌。
Authorization: Basic enh4OjEyMzQ1Ng==
當客戶端訪問受用戶名和密碼保護的服務器資源時，服務器就會向客戶端發送401的響應狀態碼和一個WWW-Authenticate響應頭，要求客戶端使用Authorization請求頭來進行應答。根據服務器發送的WWW-Authenticate響應頭指定的驗證方式的不同，客戶端需要使用的Authorization請求頭的值的格式也不同。有兩種方式，一個是Basic，一個是Regist。使用Basic方式傳遞時，會將用戶名和密碼用“:”分隔形成一個串，然后進行Base-64編碼。使用Base-64很容易就會被解碼，所以相當於是用明文傳送用戶名和密碼。
Host: www.111.com:80
用於指定客戶端訪問的資源所在的主機名和端口號
If-Match: “xyzzy”, “r2d2xxx”
瀏覽器可以緩存服務器響應的數據。當瀏覽器再次訪問服務器的該資源時，只有當服務器的該資源已經更新，則服務器才將新內容傳遞給客戶機，否則客戶機要使用上次緩存的內容。
可以定義各種條件來判斷服務器端資源是否已經更新。如，服務器在響應中，可以發送一些代表實體內容的頭字段 “xyzzy”, “r2d2xxx”，這些頭字段被稱為實體標簽，當客戶機再次向服務器請求這些內容時，就可以使用If-Match請求頭傳送以前緩存的實體標簽內容。服務器在收到If-Match請求頭后，則會比較這些實體標簽內容是否與當前的頁面的特征一致。如果相同，則說明資源沒有更改，服務器不用將再次發送這些資源。
If-Modified-Since: Tue. 11 Jul 2000 18:23:51 GMT
當客戶機訪問一個已緩存的資源時，可以設置If-Modified-Since頭，指定當服務器上的資源修改時間比這個頭的值的時間要新，則服務器才返回新的資源。該值必須為GMT格式，一般情況這個頭的值是使用上次訪問該資源時響應消息中的LastModified頭的值。
If-None-Match: “xyzzy”, “r2d2xxx”
與If-Match相反。
If-Range: Tue. 11 Jul 2000 18:23:51 GMT
結合Range頭使用。可以設為實體標簽，也可以是時間值。當在If-Range值之前服務器資源沒有改變，則根據Range頭的值進行續傳。否則服務器返回整個文檔內容。
If-Unmodified-Since: Tue. 11 Jul 2000 18:23:51 GMT
與If-Modified-Since相反。
Max-Forwards: 1
指定了當前HTTP請求可以途徑的代理服務器個數。每經過一個代理服務器，這個值就會被減1。如果減到0，則代理服務器中止繼續發送。
Proxy-Authorization: Basic enh4OjEyMzQ1Ng==
與Authorization類似，是與代理服務器的驗證時使用。
Range: bytes=100-599
客戶端通知服務器只需返回資源的部分內容，以及部分內容的范圍。
這對於較大文檔的斷點續傳是有很大幫助的。如果客戶機在一次請求中，只收到了服務器返回的部分內容，即服務器作出的響應只有一部分到達了客戶端，則客戶端可以發出一個帶Range頭的請求，這時服務器將會返回Range頭值的那部分內容。
Range頭有三種格式：
bytes=100-599，返回第100到第599個字節之間的內容(初始為0，包括100,599)。
bytes=100-，返回第100個字節以后的所有的內容。
bytes=-100，返回整個文檔中的最后100個字節的內容。
Referer: http://www.google.cn
告訴服務器，這次請求是通過點擊哪個網頁上的超鏈接和轉向過來的。由於可以使用telnet來仿造HTTP請求，所以Referer是不可靠的。由於HTTP的作者的拼寫錯誤，所以不可以寫成正確的拼寫方式Referrer。
TE: trailers, deflate
用於說明客戶機可接受的除了chunked以外的傳輸編碼類型。或者當使用chunked時，是否可以使用trailers頭字段在每一次發送的實體片段內容之后來設置一些響應頭。
User-Agent
用於指定瀏覽器的類型和名字。如：服務器看到使用PDA版的IE，則可以返回wml的頁面。
14. 實體頭
實體頭用作實體內容的元信息，描述了實體內容的屬性，包括實體內容類型、長度、壓縮方法、最后一次修改時間、數據有效期等。
Allow: GET, POST
可以使用哪些方式訪問資源
Content-Encoding: gzip
實體內容以哪種方式編碼。
Content-Language: zh-cn
實體內容的國家語言類型。
Content-Length: 80
實體內容的大小。
Content-Location: http://www.111.org/index.html
服務器可以說明返回響應實體內容的真正的實際位置。
Content-MD5: CVBNMDYHJFK==
實體內容的MD5摘要算法Base-64值，以提供實體內容的完整性校驗。服務器可以通過對實體內容進行MD5摘要算法與此頭的值是否相同來確定接收的請求是否沒有錯誤與改變。
Content-Range: bytes 2543-4532/7898
實體內容的部分的所在位置。表明本次響應是實體內容的第2543字節到第4532字節，7898是實體內容的總大小。
Content-Type: text/html, charset=GB2312
由於網絡上傳送的均為二進制流，所以瀏覽器不知道傳送的資源時什么類型的，所以服務器要告訴瀏覽器本響應的資源時什么類型的。計算機中有多種的數據格式，人們為每一個格式都定義了一個名稱，稱作MIME。本頭指出實體內容的MIME。由於WEB服務器不知道這些資源文件是哪種MIME，所以可以對WEB服務器進行設置，使文件擴展名與MIME之間進行映射。
Expires: Tue. 11 Jul 2000 18:23:51 GMT
當前文檔在何時之后被認為過期。瀏覽器在這個時間之后再訪問這個頁面時，將不再使用緩存中的內容。而是在需要時發出新的訪問請求。
Last-Modified: Tue. 11 Jul 2000 18:23:51 GMT
指定文檔的最后更新時間。
15. 擴展頭
在HTTP消息中，也可以使用一些在HTTP/1.1正式規范里沒有定義的頭字段，這些頭字段統稱為自定義HTTP頭或擴展頭，他們通常被當作是一種實體頭處理。
現在流行的瀏覽器基本都支持Cookie、Set-Cookie、Refresh和Content-Disposition等幾個常用的擴展頭字段。
Refresh: 1
Refresh: 1;url=http://www.111.com
過1秒之后刷新或跳轉頁面。
Content-Type: application/octet-stream
Content-Disposition: attachment; filename=aaa.zip
Content-Disposition只有一個值，為attachment，在后面可以增加filename=aaa.zip，表示被保存的初始參考文件名。
HTTP是一個應用層協議，由請求和響應構成，是一個標准的客戶端服務器模型。HTTP是一個無狀態的協議。
在Internet中所有的傳輸都是通過TCP/IP進行的。HTTP協議作為TCP/IP模型中應用層的協議也不例外。HTTP協議通常承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了我們常說的HTTPS。如下圖所示：
HTTP默認的端口號為80，HTTPS的端口號為443。
瀏覽網頁是HTTP的主要應用，但是這並不代表HTTP就只能應用於網頁的瀏覽。HTTP是一種協議，只要通信的雙方都遵守這個協議，HTTP就能有用武之地。比如咱們常用的QQ，迅雷這些軟件，都會使用HTTP協議(還包括其他的協議)。
二、簡史
它的發展是萬維網協會（World Wide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結果，（他們）最終發布了一系列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。
三、特點
HTTP協議永遠都是客戶端發起請求，服務器回送響應。這樣就限制了使用HTTP協議，無法實現在客戶端沒有發起請求的時候，服務器將消息推送給客戶端。
HTTP協議的主要特點可概括如下：
1、支持客戶/服務器模式。支持基本認證和安全認證。
2、簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
3、靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
4、HTTP 0.9和1.0使用非持續連接：限制每次連接只處理一個請求，服務器處理完客戶的請求，並收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。HTTP 1.1使用持續連接：不必為每個web對象創建一個新的連接，一個連接可以傳送多個對象。
5、無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。
無狀態協議：
協議的狀態是指下一次傳輸可以“記住”這次傳輸信息的能力。
http是不會為了下一次連接而維護這次連接所傳輸的信息,為了保證服務器內存。
比如客戶獲得一張網頁之后關閉瀏覽器，然后再一次啟動瀏覽器，再登陸該網站，但是服務器並不知道客戶關閉了一次瀏覽器。
由於Web服務器要面對很多瀏覽器的並發訪問，為了提高Web服務器對並發訪問的處理能力， 在設計HTTP協議時規定Web服務器發送HTTP應答報文和文檔時，不保存發出請求的Web瀏覽器進程的任何狀態信息。這有可能出現一個瀏覽器在短短幾 秒之內兩次訪問同一對象時，服務器進程不會因為已經給它發過應答報文而不接受第二期服務請求。由於Web服務器不保存發送請求的Web瀏覽器進程的任何信 息，因此HTTP協議屬於無狀態協議（Stateless Protocol）。
HTTP協議是無狀態的和Connection: keep-alive的區別：
無狀態是指協議對於事務處理沒有記憶能力，服務器不知道客戶端是什么狀態。從另一方面講，打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯系。
HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議（無連接）。
從HTTP/1.1起，默認都開啟了Keep-Alive，保持連接特性，簡單地說，當一個網頁打開完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。
Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。
四、工作流程
一次HTTP操作稱為一個事務，其工作過程可分為四步：
1）首先客戶機與服務器需要建立連接。只要單擊某個超級鏈接，HTTP的工作開始。
2）建立連接后，客戶機發送一個請求給服務器，請求方式的格式為：統一資源標識符（URL）、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。
3）服務器接到請求后，給予相應的響應信息，其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。
4）客戶端接收服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然后客戶機與服務器斷開連接。
如果在以上過程中的某一步出現錯誤，那么產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標點擊，等待信息顯示就可以了。
HTTP是基於傳輸層的TCP協議，而TCP是一個端到端的面向連接的協議。所謂的端到端可以理解為進程到進程之間的通信。所以HTTP在開始傳輸之前，首先需要建立TCP連接，而TCP連接的過程需要所謂的“三次握手”。下圖所示TCP連接的三次握手。
在TCP三次握手之后，建立了TCP連接，此時HTTP就可以進行傳輸了。一個重要的概念是面向連接，既HTTP在傳輸完成之間並不斷開TCP連接。在HTTP1.1中(通過Connection頭設置)這是默認行為。
五、使用Wireshark抓TCP、http包
打開Wireshark，選擇工具欄上的"Capture"->"Options"
點擊"Capture Filter"，此處選擇的是"HTTP TCP port（80）"，選擇后點擊上圖的"Start"開始抓包。
然后在瀏覽器中打開http://image.baidu.com/，抓包結果如下圖所示：
在上圖中，可清晰的看到客戶端瀏覽器（ip為192.168.1.6）與服務器（115.239.210.36）的交互過程：
1）No1：瀏覽器（192.168.1.6）向服務器（115.239.210.36）發出連接請求。此為TCP三次握手第一步，此時從圖中可以看出，為SYN，seq:X （x=0）；
2）No2：服務器（115.239.210.36）回應了瀏覽器（192.168.1.6）的請求，並要求確認，此時為：SYN，ACK，此時seq：y（y為0），ACK：x+1（為1）。此為三次握手的第二步；
3）No3：瀏覽器（192.168.1.6）回應了服務器（115.239.210.36）的確認，連接成功。為：ACK，此時seq：x+1（為1），ACK：y+1（為1）。此為三次握手的第三步；
4）No4：瀏覽器（192.168.1.6）發出一個頁面HTTP請求；
5）No5：服務器（115.239.210.36）確認；
6）No6：服務器（115.239.210.36）發送數據；
7）No8：客戶端瀏覽器（192.168.1.6）確認；
8）No81：客戶端（192.168.1.6）發出一個圖片HTTP請求；
9）No202：服務器（115.239.210.36）發送狀態響應碼200 OK。
六、頭域
每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前可以添加任何數量的空格符，頭域可以被擴展為多行，在每行開始處，使用至少一個空格或制表符。
6.1、請求信息：
發出的請求信息格式如下：
●請求行，例如GET /images/logo.gif HTTP/1.1，表示從/images目錄下請求logo.gif這個文件。
●（請求）頭，例如Accept-Language: en
●空行
●可選的消息體 請求行和標題必須以<CR><LF>作為結尾（也就是，回車然后換行）。空行內必須只有<CR><LF>而無其他空格。在HTTP/1.1協議中，所有的請求頭，除post外，都是可選的。
三個部分分別是：請求行、消息報頭、請求正文。
6.2、請求方法
HTTP/1.1協議中共定義了八種方法（有時也叫“動作”）來表明Request-URI指定的資源的不同操作方式：
OPTIONS - 返回服務器針對特定資源所支持的HTTP請求方法。也可以利用向Web服務器發送'*'的請求來測試服務器的功能性。
HEAD- 向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應消息頭中的元信息。該方法常用於測試超鏈接的有效性，是否可以訪問，以及最近是否更新。
GET - 向特定的資源發出請求。注意：GET方法不應當被用於產生“副作用”的操作中，例如在web app.中。其中一個原因是GET可能會被網絡蜘蛛等隨意訪問。
POST - 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
PUT - 向指定資源位置上傳其最新內容。
DELETE - 請求服務器刪除Request-URI所標識的資源。
TRACE- 回顯服務器收到的請求，主要用於測試或診斷。
CONNECT - HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。
PATCH - 用來將局部修改應用於某一資源，添加於規范RFC5789。
方法名稱是區分大小寫的。當某個請求所針對的資源不支持對應的請求方法的時候，服務器應當返回狀態碼405（Method Not Allowed）；當服務器不認識或者不支持對應的請求方法的時候，應當返回狀態碼501（Not Implemented）。
HTTP服務器至少應該實現GET和HEAD方法，其他方法都是可選的。此外，除了上述方法，特定的HTTP服務器還能夠擴展自定義的方法。
GET和POST的區別：
1、GET提交的數據會放在URL之后，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中。
2、GET提交的數據大小有限制，最多只能有1024字節（因為瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制。
3、GET方式需要使用Request.QueryString來取得變量的值，而POST方式通過Request.Form來獲取變量的值。
4、GET方式提交數據，會帶來安全問題，比如一個登錄頁面，通過GET方式提交數據時，用戶名和密碼將出現在URL上，如果頁面可以被緩存或者其他人可以訪問這台機器，就可以從歷史記錄獲得該用戶的賬號和密碼。
6.3、響應消息
客戶端向服務器發送一個請求，服務器以一個狀態行作為響應，響應的內容包括：消息協議的版本、成功或者錯誤編碼、服務器信息、實體元信息以及必要的實體內容。根據響應類別的類別，服務器響應里可以含實體內容，但不是所有的響應都有實體內容。
響應頭第一行也稱為狀態行，格式如下（下圖中紅線標出的那行）：
HTTP-Version 空格 Status-Code 空格 Reason-Phrase CRLF
HTTP- Version表示HTTP版本，例如為HTTP/1.1。Status- Code是結果代碼，用三個數字表示。Reason-Phrase是個簡單的文本描述，解釋Status-Code的具體原因。Status-Code用 於機器自動識別，Reason-Phrase用於人工理解。Status-Code的第一個數字代表響應類別，可能取5個不同的值。后兩個數字沒有分類作 用。Status-Code的第一個數字代表響應的類別，后續兩位描述在該類響應下發生的具體狀況，具體請參見：HTTP狀態碼 。
響應消息的結構：
三個部分分別是：狀態行、消息報頭、響應正文。
無論你何時瀏覽一個網頁，你的電腦都會通過一個使用HTTP協議的服務器來獲取所請求的數 據。在你請求的網頁顯示在瀏覽器之前，支配網頁的網站服務器會返回一個包含有狀態碼的HTTP頭文件。這個狀態碼提供了有關所請求網頁的相關條件信息。如 果一切正常，一個標准網頁會收到一條諸如200的狀態碼。當然我們的目的不是去研究200響應碼，而是去探討那些代表出現錯誤信息的服務器頭文件響應碼， 例如表示“未找到指定網頁”的404碼。
6.4、響應頭域
服務器需要傳遞許多附加信息，這些信息不能全放在狀態行里。因此，需要另行定義響應頭域，用來描述這些附加信息。響應頭域主要描述服務器的信息和Request-URI的信息。
6.5、HTTP常見的請求頭（在HTTP/1.1 協議中，所有的請求頭，除Host外，都是可選的）
If-Modified-Since： 把瀏覽器端緩存頁面的最后修改時間發送到服務器去，服務器會把這個時間與服務器上實際文件的最后修改時間進行對比。如果時間一致，那么返回304，客戶端 就直接使用本地緩存文件。如果時間不一致，就會返回200和新的文件內容。客戶端接到之后，會丟棄舊文件，把新文件緩存起來，並顯示在瀏覽器中。
例如：If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT
If-None-Match：If- None-Match和ETag一起工作，工作原理是在HTTP Response中添加ETag信息。 當用戶再次請求該資源時，將在HTTP Request 中加入If-None-Match信息(ETag的值)。如果服務器驗證資源的ETag沒有改變（該資源沒有更新），將返回一個304狀態告訴客戶端使用 本地緩存文件。否則將返回200狀態和新的資源和Etag. 使用這樣的機制將提高網站的性能。例如: If-None-Match: "03f2b33c0bfcc1:0"。
Pragma： 指定“no-cache”值表示服務器必須返回一個刷新后的文檔，即使它是代理服務器而且已經有了頁面的本地拷貝；在HTTP/1.1版本中，它和 Cache-Control:no-cache作用一模一樣。Pargma只有一個用法， 例如： Pragma: no-cache
注意: 在HTTP/1.0版本中，只實現了Pragema:no-cache, 沒有實現Cache-Control
Cache-Control： 指定請求和響應遵循的緩存機制。緩存指令是單向的（響應中出現的緩存指令在請求中未必會出現），且是獨立的（在請求消息或響應消息中設置Cache- Control並不會修改另一個消息處理過程中的緩存處理過程）。請求時的緩存指令包括no-cache、no-store、max-age、max- stale、min-fresh、only-if-cached，響應消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage。
Cache-Control:Public 可以被任何緩存所緩存
Cache-Control:Private 內容只緩存到私有緩存中
Cache-Control:no-cache 所有內容都不會被緩存
Cache-Control:no-store 用於防止重要的信息被無意的發布。在請求消息中發送將使得請求和響應消息都不使用緩存。
Cache-Control:max-age 指示客戶機可以接收生存期不大於指定時間（以秒為單位）的響應。
Cache-Control:min-fresh 指示客戶機可以接收響應時間小於當前時間加上指定時間的響應。
Cache-Control:max-stale 指示客戶機可以接收超出超時期間的響應消息。如果指定max-stale消息的值，那么客戶機可以接收超出超時期指定值之內的響應消息。
Accept： 瀏覽器端可以接受的MIME類型。例如：Accept: text/html 代表瀏覽器可以接受服務器回發的類型為 text/html 也就是我們常說的html文檔，如果服務器無法返回text/html類型的數據，服務器應該返回一個406錯誤(non acceptable)。通配符 * 代表任意類型，例如 Accept: */* 代表瀏覽器可以處理所有類型，(一般瀏覽器發給服務器都是發這個)。
Accept-Encoding： 瀏覽器申明自己可接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法（gzip，deflate）;Servlet能夠向支持gzip的 瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。例如： Accept-Encoding: gzip, deflate。如果請求消息中沒有設置這個域，服務器假定客戶端對各種內容編碼都可以接受。
Accept-Language：瀏覽器申明自己接收的語言。語言跟字符集的區別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等；例如：Accept-Language: en-us。如果請求消息中沒有設置這個報頭域，服務器假定客戶端對各種語言都可以接受。
Accept-Charset：瀏覽器可接受的字符集。如果在請求消息中沒有設置這個域，缺省表示任何字符集都可以接受。
User-Agent：告訴HTTP服務器，客戶端使用的操作系統和瀏覽器的名稱和版本。
例如： User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)。
Content-Type：例如：Content-Type: application/x-www-form-urlencoded。
Referer： 包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面。提供了Request的上下文信息的服務器，告訴服務器我是從哪個鏈接過來的，比如從 我主頁上鏈接到一個朋友那里，他的服務器就能夠從HTTP Referer中統計出每天有多少用戶點擊我主頁上的鏈接訪問他的網站。
例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT
Connection：
例如：Connection: keep-alive 當一個網頁打開完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立 的連接。HTTP 1.1默認進行持久連接。利用持久連接的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一 點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入 ByteArrayOutputStream，然后在正式寫出內容之前計算它的大小。
Connection: close 代表一個Request完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接會關閉，當客戶端再次發送Request，需要重新建立TCP連接。
Host：（發送請求時，該頭域是必需的）主要用於指定被請求資源的Internet主機和端口號，它通常從HTTP URL中提取出來的。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態碼返回。
例如: 我們在瀏覽器中輸入：http://www.guet.edu.cn/index.html，瀏覽器發送的請求消息中，就會包含Host請求頭 域：Host：http://www.guet.edu.cn，此處使用缺省端口號80，若指定了端口號，則變成：Host：指定端口號。
Cookie：最重要的請求頭之一, 將cookie的值發送給HTTP服務器。
Content-Length：表示請求消息正文的長度。例如：Content-Length: 38。
Authorization： 授權信息，通常出現在對服務器發送的WWW-Authenticate頭的應答中。主要用於證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，如果收 到服務器的響應代碼為401（未授權），可以發送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證。
UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標准的請求頭，表示屏幕大小、顏色深度、操作系統和CPU類型。
From：請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它。
Range：可以請求實體的一個或者多個子范圍。例如，
表示頭500個字節：bytes=0-499
表示第二個500字節：bytes=500-999
表示最后500個字節：bytes=-500
表示500字節以后的范圍：bytes=500-
第一個和最后一個字節：bytes=0-0,-1
同時指定幾個范圍：bytes=500-600,601-999
但是服務器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應會以狀態碼206（PartialContent）返回而不是以200（OK）。
6.6、HTTP常見的響應頭
Allow：服務器支持哪些請求方法（如GET、POST等）。
Date： 表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世 界標准時，換算成本地時間，需要知道用戶所在的時區。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩
Expires：指明應該在什么時候認為文檔已經過期，從而不再緩存它，重新從服務器獲取，會更新緩存。過期之前使用本地緩存。HTTP1.1的客戶端和緩存會將非法的日期格式（包括0）看作已經過期。eg：為了讓瀏覽器不要緩存頁面，我們也可以將Expires實體報頭域，設置為0。
例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT
P3P：用於跨域設置Cookie, 這樣可以解決iframe跨域訪問cookie的問題
例如: P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR
Set-Cookie：非常重要的header, 用於把cookie發送到客戶端瀏覽器，每一個寫入cookie都會生成一個Set-Cookie。
例如: Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com
ETag：和If-None-Match 配合使用。
Last-Modified：用於指示資源的最后修改日期和時間。Last-Modified也可用setDateHeader方法來設置。
Content-Type：WEB 服務器告訴瀏覽器自己響應的對象的類型和字符集。Servlet默認為text/plain，但通常需要顯式地指定為text/html。由於經常要設置 Content-Type，因此HttpServletResponse提供了一個專用的方法setContentType。可在web.xml文件中配 置擴展名和MIME類型的對應關系。
例如:Content-Type: text/html;charset=utf-8
Content-Type:text/html;charset=GB2312
Content-Type: image/jpeg
媒體類型的格式為：大類/小類，比如text/html。
IANA(The Internet Assigned Numbers Authority，互聯網數字分配機構)定義了8個大類的媒體類型，分別是:
application— (比如: application/vnd.ms-excel.)
audio (比如: audio/mpeg.)
image (比如: image/png.)
message (比如,:message/http.)
model(比如:model/vrml.)
multipart (比如:multipart/form-data.)
text(比如:text/html.)
video(比如:video/quicktime.)
Content-Range： 用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的范圍和整個實體長度。一般格 式：Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-length。
例如，傳送頭500個字節次字段的形式：Content-Range:bytes0-499/1234如果一個http消息包含此節（例如，對范圍請求的響 應或對一系列范圍的重疊請求），Content-Range表示傳送的范圍。
Content-Length： 指明實體正文的長度，以字節方式存儲的十進制數字來表示。在數據下行的過程中，Content-Length的方式要預先在服務器中緩存所有數據，然后所 有數據再一股腦兒地發給客戶端。只有當瀏覽器使用持久HTTP連接時才需要這個數據。如果你想要利用持久連接的優勢，可以把輸出文檔寫入 ByteArrayOutputStram，完成后查看其大小，然后把該值放入Content-Length頭，最后通過 byteArrayStream.writeTo(response.getOutputStream()發送內容。
例如: Content-Length: 19847
Content-Encoding：WEB 服務器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應中的對象。只有在解碼之后才可以得到Content-Type頭指定的內容類型。 利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix 上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應該通過查看Accept-Encoding頭（即request.getHeader("Accept- Encoding")）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面。
例如：Content-Encoding：gzip
Content-Language：WEB服務器告訴瀏覽器自己響應的對象所用的自然語言。例如： Content-Language:da。沒有設置該域則認為實體內容將提供給所有的語言閱讀。
Server：指明HTTP服務器用來處理請求的軟件信息。例如：Server: Microsoft-IIS/7.5、Server：Apache-Coyote/1.1。此域能包含多個產品標識和注釋，產品標識一般按照重要性排序。
X-AspNet-Version：如果網站是用ASP.NET開發的，這個header用來表示ASP.NET的版本。
例如: X-AspNet-Version: 4.0.30319
X-Powered-By：表示網站是用什么技術開發的。
例如： X-Powered-By: ASP.NET
Connection：
例如：Connection: keep-alive 當一個網頁打開完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。
Connection: close 代表一個Request完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接會關閉，當客戶端再次發送Request，需要重新建立TCP連接。
Location： 用於重定向一個新的位置，包含新的URL地址。表示客戶應當到哪里去提取文檔。Location通常不是直接設置的，而是通過 HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼為302。Location響應報頭域常用在更換域名的 時候。
Refresh： 表示瀏覽器應該在多少時間之后刷新文檔，以秒計。除了刷新當前文檔之外，你還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。注意這種功能通常是通過設置HTML頁面HEAD區的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">實現，這是因為，自動刷新或重定向對於那些不能使用CGI或Servlet的 HTML編寫者十分重要。但是，對於Servlet來說，直接設置Refresh頭更加方便。注意Refresh的意義是“N秒之后刷新本頁面或訪問指定 頁面”，而不是“每隔N秒刷新本頁面或訪問指定頁面”。因此，連續刷新要求每次都發送一個Refresh頭，而發送204狀態代碼則可以阻止瀏覽器繼續刷 新，不管是使用Refresh頭還是<META HTTP-EQUIV="Refresh" ...>。注意Refresh頭不屬於HTTP 1.1正式規范的一部分，而是一個擴展，但Netscape和IE都支持它。
WWW-Authenticate：該響應報頭域必須被包含在401（未授權的）響應消息中，客戶端收到401響應消息時候，並發送Authorization報頭域請求服務器對其進行驗證時，服務端響應報頭就包含該報頭域。
eg：WWW-Authenticate:Basic realm="Basic Auth Test!" //可以看出服務器對請求資源采用的是基本驗證機制。
七、解決HTTP無狀態的問題
7.1、通過Cookies保存狀態信息
通過Cookies，服務器就可以清楚的知道請求2和請求1來自同一個客戶端。
7.2、通過Session保存狀態信息
Session機制是一種服務器端的機制，服務器使用一種類似於散列表的結構（也可能就是使用散列表）來保存信息。
當程序需要為某個客戶端的請求創建一個session的時候，服務器首先檢查這個客戶端的請 求里是否已包含了一個session標識 - 稱為 session id，如果已包含一個session id則說明以前已經為此客戶端創建過session，服務器就按照session id把這個 session檢索出來使用（如果檢索不到，可能會新建一個），如果客戶端請求不包含session id，則為此客戶端創建一個session並且生成一個與此session相關聯的session id，session id的值應該是一個既不會重復，又不容易被找到規律以仿造的字符串，這個session id將被在本次響應中返回給客戶端保存。
Session的實現方式：
1、使用Cookie來實現
服務器給每個Session分配一個唯一的JSESSIONID，並通過Cookie發送給客戶端。
當客戶端發起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID。這樣服務器能夠找到這個客戶端對應的Session。
2、使用URL回寫來實現
URL回寫是指服務器在發送給瀏覽器頁面的所有鏈接中都攜帶JSESSIONID的參數，這樣客戶端點擊任何一個鏈接都會把JSESSIONID帶會服務器。如果直接在瀏覽器輸入服務端資源的url來請求該資源，那么Session是匹配不到的。
Tomcat對Session的實現，是一開始同時使用Cookie和URL回寫機制，如果 發現客戶端支持Cookie，就繼續使用Cookie，停止使用URL回寫。如果發現Cookie被禁用，就一直使用URL回寫。jsp開發處理到 Session的時候，對頁面中的鏈接記得使用response.encodeURL() 。
Cookie和Session有以下明顯的不同點：
1）Cookie將狀態保存在客戶端，Session將狀態保存在服務器端；
2）Cookies是服務器在本地機器上存儲的小段文本並隨每一個請求發送至同一個服務器。 Cookie最早在RFC2109中實現，后續RFC2965做了增強。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些 cookies並將它們保存為一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies。Session並沒有在HTTP的協議中定義；
3）Session是針對每一個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置為由get來返回給服務器；
4）就安全性來說：當你訪問一個使用session 的站點，同時在自己機子上建立一個cookie，建議在服務器端的SESSION機制更安全些。因為它不會任意讀取客戶存儲的信息。
7.3、通過表單變量保持狀態
除了Cookies之外，還可以使用表單變量來保持狀態，比如Asp.net就通過一個叫ViewState的Input=“hidden”的框來保持狀態,比如:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKMjA0OTM4MTAwNGRkXUfhlDv1Cs7/qhBlyZROCzlvf5U=" />
這個原理和Cookies大同小異，只是每次請求和響應所附帶的信息變成了表單變量。
7.4、通過QueryString保持狀態
QueryString通過將信息保存在所請求地址的末尾來向服務器傳送信息，通常和表單結合使用，一個典型的QueryString比如:www.xxx.com/xxx.aspx?var1=value&var2=value2
八、使用telnet進行http測試
在Windows下，可使用命令窗口進行http簡單測試。輸入cmd進入命令窗口，在命令行鍵入如下命令后按回車：
telnet www.baidu.com 80
而后在窗口中按下"Ctrl+]"后按回車可讓返回結果回顯。
接着開始發請求消息，例如發送如下請求消息請求baidu的首頁消息，使用的HTTP協議為HTTP/1.1：
GET /index.html HTTP/1.1
注意：copy如上的消息到命令窗口后需要按兩個回車換行才能得到響應的消息，第一個回車換行是在命令后鍵入回車換行，是HTTP協議要求的。第二個是確認輸入，發送請求。
可看到，當采用HTTP/1.1時，連接不是在請求結束后就斷開的。若采用HTTP1.0，在命令窗口鍵入：
GET /index.html HTTP/1.0
此時可以看到請求結束之后馬上斷開。
讀者還可以嘗試在使用GET或POST等時，帶上頭域信息，例如鍵入如下信息：
GET /index.html HTTP/1.1
connection: close
Host: www.baidu.com
九、URL詳解
URL(Uniform Resource Locator) 地址用於描述一個網絡上的資源， 基本格式如下
schema://host[:port#]/path/.../[;url-params][?query-string][#anchor]
scheme 指定低層使用的協議(例如：http, https, ftp)
host HTTP服務器的IP地址或者域名
port# HTTP服務器的默認端口是80，這種情況下端口號可以省略。如果使用了別的端口，必須指明，例如 http://www.cnblogs.com:8080/
path 訪問資源的路徑
url-params
query-string 發送給http服務器的數據
anchor- 錨
URL 的一個例子：
http://www.mywebsite.com/sj/test;id=8079?name=sviergn&x=true#stuff
Schema: http
host: www.mywebsite.com
path: /sj/test
URL params: id=8079
Query String: name=sviergn&x=true
Anchor: stuff
十、緩存的實現原理
WEB緩存(cache)位於Web服務器和客戶端之間。
緩存會根據請求保存輸出內容的副本，例如html頁面，圖片，文件，當下一個請求來到的時候：如果是相同的URL，緩存直接使用副本響應訪問請求，而不是向源服務器再次發送請求。
HTTP協議定義了相關的消息頭來使WEB緩存盡可能好的工作。
10.1、緩存的優點
減少相應延遲：因為請求從緩存服務器（離客戶端更近）而不是源服務器被相應，這個過程耗時更少，讓web服務器看上去相應更快。
減少網絡帶寬消耗：當副本被重用時會減低客戶端的帶寬消耗；客戶可以節省帶寬費用，控制帶寬的需求的增長並更易於管理。
10.2、客戶端緩存生效的常見流程
服務器收到請求時，會在200OK中回送該資源的Last-Modified和ETag頭， 客戶端將該資源保存在cache中，並記錄這兩個屬性。當客戶端需要發送相同的請求時，會在請求中攜帶If-Modified-Since和If- None-Match兩個頭。兩個頭的值分別是響應中Last-Modified和ETag頭的值。服務器通過這兩個頭判斷本地資源未發生變化，客戶端不 需要重新下載，返回304響應。
10.3、Web緩存機制
HTTP/1.1中緩存的目的是為了在很多情況下減少發送請求，同時在許多情況下可以不需要 發送完整響應。前者減少了網絡回路的數量；HTTP利用一個“過期（expiration）”機制來為此目的。后者減少了網絡應用的帶寬；HTTP用“驗 證（validation）”機制來為此目的。
HTTP定義了3種緩存機制：
1）Freshness：允許一個回應消息可以在源服務器不被重新檢查，並且可以由服務器和客戶端來控制。例如，Expires回應頭給了一個文檔不可用的時間。Cache-Control中的max-age標識指明了緩存的最長時間；
2）Validation：用來檢查以一個緩存的回應是否仍然可用。例如，如果一個回應有一個Last-Modified回應頭，緩存能夠使用If-Modified-Since來判斷是否已改變，以便判斷根據情況發送請求；
3）Invalidation：在另一個請求通過緩存的時候，常常有一個副作用。例如，如果一個URL關聯到一個緩存回應，但是其后跟着POST、PUT和DELETE的請求的話，緩存就會過期。
十一、HTTP應用
11.1、斷點續傳的實現原理
HTTP協議的GET方法，支持只請求某個資源的某一部分；
206 Partial Content 部分內容響應；
Range 請求的資源范圍；
Content-Range 響應的資源范圍；
在連接斷開重連時，客戶端只請求該資源未下載的部分，而不是重新請求整個資源，來實現斷點續傳。
分塊請求資源實例：
Eg1：Range: bytes=306302- ：請求這個資源從306302個字節到末尾的部分；
Eg2：Content-Range: bytes 306302-604047/604048：響應中指示攜帶的是該資源的第306302-604047的字節，該資源共604048個字節；
客戶端通過並發的請求相同資源的不同片段，來實現對某個資源的並發分塊下載。從而達到快速下載的目的。目前流行的FlashGet和迅雷基本都是這個原理。
11.2、多線程下載的原理
下載工具開啟多個發出HTTP請求的線程；
每個http請求只請求資源文件的一部分：Content-Range: bytes 20000-40000/47000；
合並每個線程下載的文件。
11.3、http代理
http代理服務器
代理服務器英文全稱是Proxy Server，其功能就是代理網絡用戶去取得網絡信息。形象的說：它是網絡信息的中轉站。
代理服務器是介於瀏覽器和Web服務器之間的一台服務器，有了它之后，瀏覽器不是直接到Web服務器去取回網頁而是向代理服務器發出請求，Request信號會先送到代理服務器，由代理服務器來取回瀏覽器所需要的信息並傳送給你的瀏覽器。
而且，大部分代理服務器都具有緩沖的功能，就好象一個大的Cache，它有很大的存儲空間， 它不斷將新取得數據儲存到它本機的存儲器上，如果瀏覽器所請求的數據在它本機的存儲器上已經存在而且是最新的，那么它就不重新從Web服務器取數據，而直 接將存儲器上的數據傳送給用戶的瀏覽器，這樣就能顯著提高瀏覽速度和效率。更重要的是：Proxy Server(代理服務器)是Internet鏈路級網關所提供的一種重要的安全功能，它的工作主要在開放系統互聯(OSI)模型的對話層。
http代理服務器的主要功能：
1）突破自身IP訪問限制，訪問國外站點。如：教育網、169網等網絡用戶可以通過代理訪問國外網站；
2）訪問一些單位或團體內部資源，如某大學FTP(前提是該代理地址在該資源的允許訪問范圍之內)，使用教育網內地址段免費代理服務器，就可以用於對教育 網開放的各類FTP下載上傳，以及各類資料查詢共享等服務；
3）突破中國電信的IP封鎖：中國電信用戶有很多網站是被限制訪問的，這種限制是人為的，不同Serve對地址的封鎖是不同的。所以不能訪問時可以換一個國外的代理服務器試試；
4）提高訪問速度：通常代理服務器都設置一個較大的硬盤緩沖區，當有外界的信息通過時，同時也將其保存到緩沖區中，當其他用戶再訪問相同的信息時，則直接由緩沖區中取出信息，傳給用戶，以提高訪問速度；
5）隱藏真實IP：上網者也可以通過這種方法隱藏自己的IP，免受攻擊。
對於客戶端瀏覽器而言，http代理服務器相當於服務器。
而對於Web服務器而言，http代理服務器又擔當了客戶端的角色。
11.4、虛擬主機
虛擬主機：是在網絡服務器上划分出一定的磁盤空間供用戶放置站點、應用組件等，提供必要的站點功能與數據存放、傳輸功能。
所謂虛擬主機，也叫“網站空間”就是把一台運行在互聯網上的服務器划分成多個“虛擬”的服務 器，每一個虛擬主機都具有獨立的域名和完整的Internet服務器（支持WWW、FTP、E-mail等）功能。一台服務器上的不同虛擬主機是各自獨立 的，並由用戶自行管理。但一台服務器主機只能夠支持一定數量的虛擬主機，當超過這個數量時，用戶將會感到性能急劇下降。
虛擬主機的實現原理
虛擬主機是用同一個WEB服務器，為不同域名網站提供服務的技術。Apache、Tomcat等均可通過配置實現這個功能。
相關的HTTP消息頭：Host。
例如：Host: www.baidu.com
客戶端發送HTTP請求的時候，會攜帶Host頭，Host頭記錄的是客戶端輸入的域名。這樣服務器可以根據Host頭確認客戶要訪問的是哪一個域名。
十二、HTTP認證方式
HTTP請求報頭： Authorization
HTTP響應報頭： WWW-Authenticate
HTTP認證是基於質詢/回應(challenge/response)的認證模式。
12.1 基本認證 basic authentication（HTTP1.0提出的認證方法）
基本認證是一種用來允許Web瀏覽器或其他客戶端程序在請求時提供用戶名和口令形式的身份憑證的一種登錄驗證方式。
把 "用戶名+冒號+密碼"用BASE64算法加密后的字符串放在http request 中的header Authorization中發送給服務端。
客戶端對於每一個realm，通過提供用戶名和密碼來進行認證的方式。
包含密碼的明文傳遞。
當瀏覽器訪問使用基本認證的網站的時候， 瀏覽器會提示你輸入用戶名和密碼，如下圖：
假如用戶名密碼錯誤的話，服務器會返回401，如下圖：
基本認證步驟：
1、客戶端訪問一個受http基本認證保護的資源。
2、服務器返回401狀態，要求客戶端提供用戶名和密碼進行認證。（驗證失敗的時候，響應頭會加上WWW-Authenticate: Basic realm="請求域"。）
401 Unauthorized
WWW-Authenticate： Basic realm="WallyWorld"
3、客戶端將輸入的用戶名密碼用Base64進行編碼后，采用非加密的明文方式傳送給服務器。
Authorization: Basic xxxxxxxxxx.
4、服務器將Authorization頭中的用戶名密碼解碼並取出，進行驗證，如果認證成功，則返回相應的資源。如果認證失敗，則仍返回401狀態，要求重新進行認證。
特記事項：
1、Http是無狀態的，同一個客戶端對同一個realm內資源的每一個訪問會被要求進行認證。
2、客戶端通常會緩存用戶名和密碼，並和authentication realm一起保存，所以，一般不需要你重新輸入用戶名和密碼。
3、以非加密的明文方式傳輸，雖然轉換成了不易被人直接識別的字符串，但是無法防止用戶名密碼被惡意盜用。雖然用肉眼看不出來，但用程序很容易解密。
優點：
基本認證的一個優點是基本上所有流行的網頁瀏覽器都支持基本認證。基本認證很少在可公開訪問的互聯網網站上使用，有時候會在小的私有系統中使用（如路由器
網頁管理接口）。后來的機制HTTP摘要認證是為替代基本認證而開發的，允許密鑰以相對安全的方式在不安全的通道上傳輸。
程序員和系統管理員有時會在可信網絡環境中使用基本認證，使用Telnet或其他明文網絡協議工具手動地測試Web服務器。這是一個麻煩的過程，但是網絡上傳輸的
內容是人可讀的，以便進行診斷。
缺點：
雖然基本認證非常容易實現，但該方案建立在以下的假設的基礎上，即：客戶端和服務器主機之間的連接是安全可信的。特別是，如果沒有使用SSL/TLS這樣的傳輸
層安全的協議，那么以明文傳輸的密鑰和口令很容易被攔截。該方案也同樣沒有對服務器返回的信息提供保護。
現存的瀏覽器保存認證信息直到標簽頁或瀏覽器被關閉，或者用戶清除歷史記錄。HTTP沒有為服務器提供一種方法指示客戶端丟棄這些被緩存的密鑰。這意味着服務
器端在用戶不關閉瀏覽器的情況下，並沒有一種有效的方法來讓用戶登出。
一個例子：
這一個典型的HTTP客戶端和HTTP服務器的對話，服務器安裝在同一台計算機上（localhost），包含以下步驟：
客戶端請求一個需要身份認證的頁面，但是沒有提供用戶名和口令。這通常是用戶在地址欄輸入一個URL，或是打開了一個指向該頁面的鏈接。服務端響應一個401應
答碼，並提供一個認證域。接到應答后，客戶端顯示該認證域（通常是所訪問的計算機或系統的描述）給用戶並提示輸入用戶名和口令。此時用戶可以選擇確定或取
消。用戶輸入了用戶名和口令后，客戶端軟件會在原先的請求上增加認證消息頭（值是base64encode(username+":"+password)），然后重新發送再次嘗試。
在本例中，服務器接受了該認證屏幕並返回了頁面。如果用戶憑據非法或無效，服務器可能再次返回401應答碼，客戶端可以再次提示用戶輸入口令。
注意:客戶端有可能不需要用戶交互，在第一次請求中就發送認證消息頭。
服務端應答：
HTTP/1.0 401 Authorization Required
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:18:15 GMT
WWW-Authenticate: Basic realm="Secure Area"
Content-Type: text/html
Content-Length: 311
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd"> <HTML> <HEAD> <TITLE>Error</TITLE> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> </HEAD> <BODY><H1>401 Unauthorized.</H1></BODY> </HTML>
服務端的應答：
HTTP/1.0 200 OK
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:19:07 GMT
Content-Type: text/html
Content-Length: 10476
（跟隨一個空行，隨后是需憑據頁的HTML文本）。
HTTP OAuth認證
OAuth對於Http來說，就是放在Authorization header中的不是用戶名密碼， 而是一個token。微軟的Skydrive就是使用這樣的方式。
12.2、摘要認證 digest authentication（HTTP1.1提出的基本認證的替代方法）
這個認證可以看做是基本認證的增強版本，不包含密碼的明文傳遞。
引入了一系列安全增強的選項；“保護質量”(qop)、隨機數計數器由客戶端增加、以及客戶生成的隨機數。
在HTTP摘要認證中使用 MD5 加密是為了達成"不可逆的"，也就是說，當輸出已知的時候，確定原始的輸入應該是相當困難的。如果密碼本身太過簡單，也許可以
通過嘗試所有可能的輸入來找到對應的輸出（窮舉攻擊），甚至可以通過字典或者適當的查找表加快查找速度。
示例及說明
下面的例子僅僅涵蓋了“auth”保護質量的代碼，因為在撰寫期間，所知道的只有Opera和Konqueror網頁瀏覽器支持“auth-int”（帶完整性保護的認證）。
典型的認證過程包括如下步驟：
客戶端請求一個需要認證的頁面，但是不提供用戶名和密碼。通常這是由於用戶簡單的輸入了一個地址或者在頁面中點擊了某個超鏈接。
服務器返回401 "Unauthorized" 響應代碼，並提供認證域(realm)，以及一個隨機生成的、只使用一次的數值，稱為密碼隨機數 nonce。
此時，瀏覽器會向用戶提示認證域(realm)（通常是所訪問的計算機或系統的描述），並且提示用戶名和密碼。用戶此時可以選擇取消。
一旦提供了用戶名和密碼，客戶端會重新發送同樣的請求，但是添加了一個認證頭包括了響應代碼。
注意：客戶端可能已經擁有了用戶名和密碼，因此不需要提示用戶，比如以前存儲在瀏覽器里的。
服務器響應：
HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm@host.com", //認證域
qop="auth,auth-int", //保護質量
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", //服務器密碼隨機數
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 311
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd"> <HTML> <HEAD> <TITLE>Error</TITLE> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> </HEAD> <BODY><H1>401 Unauthorized.</H1></BODY> </HTML>
客戶端請求 (用戶名 "Mufasa", 密碼 "Circle Of Life")：
GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001, //請求計數
cnonce="0a4f113b", //客戶端密碼隨機數
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
(跟隨一個新行，形式如前所述)。
服務器響應：
HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984
(隨后是一個空行，然后是所請求受限制的HTML頁面)
response 值由三步計算而成。當多個數值合並的時候，使用冒號作為分割符：
1、對用戶名、認證域(realm)以及密碼的合並值計算 MD5 哈希值，結果稱為 HA1。
2、對HTTP方法以及URI的摘要的合並值計算 MD5 哈希值，例如，"GET" 和 "/dir/index.html"，結果稱為 HA2。
3、對HA1、服務器密碼隨機數(nonce)、請求計數(nc)、客戶端密碼隨機數(cnonce)、保護質量(qop)以及 HA2 的合並值計算 MD5 哈希值。結果即為客戶端提供的
response 值。
因為服務器擁有與客戶端同樣的信息，因此服務器可以進行同樣的計算，以驗證客戶端提交的 response 值的正確性。在上面給出的例子中，結果是如下計算的。
（MD5()表示用於計算MD5哈希值的函數；“\”表示接下一行；引號並不參與計算）
HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )
= 939e7578ed9e3c518a452acee763bce9
HA2 = MD5( "GET:/dir/index.html" )
= 39aff3a2bab6126f332b942af96d3366
Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
dcd98b7102dd2f0e8b11d0f600bfb0c093:\
00000001:0a4f113b:auth:\
39aff3a2bab6126f332b942af96d3366" )
= 6629fae49393a05397450978507c4ef1
此時客戶端可以提交一個新的請求，重復使用服務器密碼隨機數(nonce)（服務器僅在每次 “401”響應后發行新的nonce），但是提供新的客戶端密碼隨機數(cnonce)。在后續的請求中，十六進制請求計數器(nc)必須比前一次使用的 時候要大，否則攻擊者可以簡單的使用同樣的認證信息重放老的請求。由服務器來確保在每個發出的密碼隨機數nonce時，計數器是在增加的，並拒絕掉任何錯 誤的請求。顯然，改變HTTP方法和/或計數器數值都會導致不同的 response值。
服務器應當記住最近所生成的服務器密碼隨機數nonce的值。也可以在發行每一個密碼隨機數nonce后，記住過一段時間讓它們過期。如果客戶端使用了一個過期的值，服務器應該響應“401”狀態號，並且在認證頭中添加stale=TRUE，表明客戶端應當使用新提供的服務器密碼隨機數nonce重發請求，而不必提示用戶其它用戶名和口令。
服務器不需要保存任何過期的密碼隨機數，它可以簡單的認為所有不認識的數值都是過期的。服務器也可以只允許每一個服務器密碼隨機數nonce使用一次，當然，這樣就會迫使客戶端在發送每個請求的時候重復認證過程。需要注意的是，在生成后立刻過期服務器密碼隨機數nonce是不行的，因為客戶端將沒有任何機會來使用這個nonce。
PS：以上只介紹了兩種比較基礎的，還有其他的一些認證方式就不在這里一一說明了。
十三、HTTPS傳輸協議原理
HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容 請看SSL。
13.1、兩種基本的加解密算法類型
對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等。
非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。
13.2、HTTPS通信過程
13.3、HTTPS通信的優點
客戶端產生的密鑰只有客戶端和服務器端能得到；
加密的數據只有客戶端和服務器端才能得到明文；
客戶端到服務端的通信是安全的。
十四、http的狀態響應碼
| 1**(信息類)：表示接收到請求並且繼續處理 2**(響應成功)：表示動作被成功接收、理解和接受 3**(重定向類)：為了完成指定的動作，必須接受進一步處理 4**(客戶端錯誤類)：請求包含錯誤語法或不能正確執行 5**(服務端錯誤類)：服務器不能正確執行一個正確的請求 |
結束語：其他協議還有：文件傳輸協議FTP、電子郵件傳輸協議SMTP、域名系統服務DNS、網絡新聞傳輸協議NNTP和HTTP協議等