一、http協(xié)議的定義
HTTP是超文本傳輸協(xié)議的縮寫。是互聯(lián)網(wǎng)上使用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，適用于www服務(wù)器傳輸超文本到本地瀏覽器傳輸協(xié)議。它可以使瀏覽器的傳輸更加高效，使網(wǎng)絡(luò)傳輸減少。他還能使計算機能快速準(zhǔn)確的傳輸超文本文檔。HTTP是客戶端到服務(wù)端請求與應(yīng)答的標(biāo)準(zhǔn)，http協(xié)議規(guī)定了超文本傳輸所要遵守的規(guī)則?？蛻舳耸墙K端用戶（瀏覽器），服務(wù)端是網(wǎng)站，當(dāng)服務(wù)端發(fā)起一個指定端口的HTTP請求。
二、http協(xié)議特性
無狀態(tài)：
1、HTTP協(xié)議自身不對請求和響應(yīng)之間的通信狀態(tài)進行保存。（即多個請求之間服務(wù)器并不知道是否是同一個客戶端的請求。）
1、由于請求之間無狀態(tài)保持，服務(wù)器就無法進行身份識別，比如大部分網(wǎng)站都要求登錄后才能進行下一步操作，此時服務(wù)器就無法知道請求是哪一個客戶端發(fā)起的。
解決無狀態(tài)問題的方法：
cookie一種用來管理HTTP協(xié)議請求狀態(tài)技術(shù)。
Cookie 技術(shù)通過在請求和響應(yīng)報文中寫入相應(yīng)的Cookie 信息來控制客戶端的狀態(tài)。
1、當(dāng)客戶端發(fā)起請求時，服務(wù)器端發(fā)送的響應(yīng)報文內(nèi)添加一個?Set-Cookie 的部字段信息， 通知客戶端保存Cookie。
2、當(dāng)下次客戶端再次向服務(wù)器發(fā)送請求時， 客戶端的瀏覽器會自動在請求報文中加入 Cookie字段和值后發(fā)送給服務(wù)器。
3、服務(wù)器端收到客戶端發(fā)送過來的 Cookie 后， 會將cookie的值與之前保存的cookie進行對比， 通過對比就可以知道是否值之前已經(jīng)請求過客戶端， 也可以得到之前的狀態(tài)信息了。
如下是第一個是登錄請求
第二個是登錄后發(fā)起請求：
2、session
session 是一種基于cookie技術(shù)的讓服務(wù)器能識別某個用戶的「機制」，然也可以1特指服務(wù)器存儲的 session數(shù)據(jù)。
使用 Cookie 來 管理 Session，以彌補 HTTP 協(xié)議中不存在的狀態(tài)管理功能。
可以這么認(rèn)為session是對cookie的一種補充。
1.用戶在瀏覽器輸入用戶名密碼提交給服務(wù)端，服務(wù)端驗證通過后會創(chuàng)建一個session對象用于記錄用戶的相關(guān)信息。
2.服務(wù)器創(chuàng)建session后，會生成的session信息 通過setCookie 字段添加到http響應(yīng)頭部中返回給客戶端。
3、瀏覽器處理請求的響應(yīng)信息發(fā)現(xiàn)響應(yīng)頭部有 set-cookie字段，就把這個cookie 保存瀏覽器指定域名下
4、當(dāng)瀏覽器再次對服務(wù)器發(fā)起請求時，瀏覽器會自動發(fā)送含有session的cookie，服務(wù)端接到請求后會通過驗證session是否已經(jīng)存在，如果有，就證明這個用戶是登錄狀態(tài)。
三、Http協(xié)議狀態(tài)碼
最常見的http狀態(tài)碼：
200 ： 請求已經(jīng)被成功處理
302：302表示重定向，服務(wù)返回302時，返回的頭部信息中會包含一個 Location 字段，內(nèi)容是重定向到的url地址，此時瀏覽器會自動訪問該地址。
404：請求的資源不存在
500：服務(wù)器錯誤。無法響應(yīng)
四、http報文的組成
http請求報文分為三部分：請求行（開始行）、請求首部（首部行）、請求體（實體主體）
請求行（開始行）：請求的第一行是“方法、URL、協(xié)議/版本”
請求頭（請求首部）：請求頭包含許多有關(guān)的客戶端環(huán)境和請求正文的有用信息。例如，請求頭可以聲明瀏覽器所用的語言，請求正文的長度等
常見的請求頭參數(shù)：
Content-Type是返回消息中非常重要的內(nèi)容，表示后面的文檔屬于什么MIME類型。Content-Type: [type]/[subtype]; parameter。例如最常見的就是text/html，它的意思是說返回的內(nèi)容是文本類型，這個文本又是HTML格式的。原則上瀏覽器會根據(jù)Content-Type來決定如何顯示返回的消息體內(nèi)容
Host指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務(wù)器或網(wǎng)關(guān)的位置。HTTP/1.1請求必須包含主機頭域，否則系統(tǒng)會以400狀態(tài)碼返回
Accept瀏覽器可接受的MIME類型
Accept-Charset瀏覽器可接受的字符集
Accept-Encoding瀏覽器能夠進行解碼的數(shù)據(jù)編碼方式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經(jīng)gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間
Accept-Language瀏覽器所希望的語言種類，當(dāng)服務(wù)器能夠提供一種以上的語言版本時要用到
Authorization授權(quán)信息，通常出現(xiàn)在對服務(wù)器發(fā)送的WWW-Authenticate頭的應(yīng)答中
Connection表示是否需要持久連接。如果Servlet看到這里的值為“Keep- Alive”，或者看到請求使用的是HTTP1.1（HTTP 1.1默認(rèn)進行持久連接），它就可以利用持久連接的優(yōu)點，當(dāng)頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現(xiàn)這一點，Servlet需要在應(yīng)答中發(fā)送一個Content-Length頭，最簡單的實現(xiàn)方法是：先把內(nèi)容寫入 ByteArrayOutputStream，然后在正式寫出內(nèi)容之前計算它的大小
Content-Length表示請求消息正文的長度
Cookie這是最重要的請求頭信息之一
If-Modified-Since只有當(dāng)所請求的內(nèi)容在指定的日期之后又經(jīng)過修改才返回它，否則返回304“Not Modified”應(yīng)答
Referer包含一個URL，用戶從該URL代表的頁面出發(fā)訪問當(dāng)前請求的頁面
User-Agent瀏覽器類型，如果Servlet返回的內(nèi)容與瀏覽器類型有關(guān)則該值非常有用
請求正文（請求體）：
請求頭和請求正文之間用空行分隔，表示請求頭已經(jīng)結(jié)束，接下來的是請求正文。請求正文中可以包含客戶提交的查詢字符串信息：
例如：elephone=xxxxx&userType=1&
http請求報文也分為三部分：狀態(tài)行（開始行）、響應(yīng)首部（首部行）、響應(yīng)體（實體主體）
狀態(tài)行：由協(xié)議版本、數(shù)字形式的狀態(tài)代碼、及相應(yīng)的狀態(tài)描述，各元素之間以空格分隔。
響應(yīng)頭：響應(yīng)頭包含許多有關(guān)的服務(wù)端環(huán)境和服務(wù)端的信息
常見的響應(yīng)頭
Server：??
Server響應(yīng)報頭域包含了服務(wù)器用來處理請求的軟件信息。它和User-Agent請求報頭域是相對應(yīng)的，前者發(fā)送服務(wù)器端軟件的信息，后者發(fā)送客戶?端軟件(瀏覽器)和操作系統(tǒng)的信息。下面是Server響應(yīng)報頭域的一個例子：Server: Apache-Coyote/1.1
WWW-Authenticate：
WWW-Authenticate響應(yīng)報頭域必須被包含在401(未授權(quán)的)響應(yīng)消息中，這個報頭域和前面講到的Authorization請求報頭域是?相關(guān)的，當(dāng)客戶端收到401響應(yīng)消息，就要決定是否請求服務(wù)器對其進行驗證。如果要求服務(wù)器對其進行驗證，就可以發(fā)送一個包含了?Authorization報頭域的請求，下面是WWW-Authenticate響應(yīng)報頭域的一個例子：WWW-Authenticate: Basic realm="Basic Auth Test!"
從這個響應(yīng)報頭域，可以知道服務(wù)器端對我們所請求的資源采用的是基本驗證機制。
Content-Encoding：
Content-Encoding實體報頭域被使用作媒體類型的修飾符，它的值指示了已經(jīng)被應(yīng)用到實體正文的附加內(nèi)容編碼，因而要獲得Content- Type報頭域中所引用的媒體類型，必須采用相應(yīng)的解碼機制。Content-Encoding主要用語記錄文檔的壓縮方法，下面是它的一個例子：?Content-Encoding: gzip。如果一個實體正文采用了編碼方式存儲，在使用之前就必須進行解碼。
Content-Language：
Content-Language實體報頭域描述了資源所用的自然語言。Content-Language允許用戶遵照自身的首選語言來識別和區(qū)分實體。?如果這個實體內(nèi)容僅僅打算提供給丹麥的閱讀者，那么可以按照如下的方式設(shè)置這個實體報頭域：Content-Language: da。
如果沒有指定Content-Language報頭域，那么實體內(nèi)容將提供給所以語言的閱讀者。
Content-Length：
Content-Length實體報頭域用于指明正文的長度，以字節(jié)方式存儲的十進制數(shù)字來表示，也就是一個數(shù)字字符占一個字節(jié)，用其對應(yīng)的ASCII碼存儲傳輸。
???????要注意的是：這個長度僅僅是表示實體正文的長度，沒有包括實體報頭的長度。
Content-Type :
?????Content-Type實體報頭域用語指明發(fā)送給接收者的實體正文的媒體類型。例如：
Content-Type: text/html;charset=ISO-8859-1
???Content-Type: text/html;charset=GB2312
Last-Modified :
?????Last-Modified實體報頭域用于指示資源最后的修改日期及時間。
五、http協(xié)議的請求方式
GET： 用于請求訪問已經(jīng)被URI（統(tǒng)一資源標(biāo)識符）識別的資源，可以通過URL傳參給服務(wù)器
POST：用于傳輸信息給服務(wù)器，主要功能與GET方法類似，但一般推薦使用POST方式。
PUT： 傳輸文件，報文主體中包含文件內(nèi)容，保存到對應(yīng)URI位置。
HEAD： 獲得報文首部，與GET方法類似，只是不返回報文主體，一般用于驗證URI是否有效。
DELETE：刪除文件，與PUT方法相反，刪除對應(yīng)URI位置的文件。
OPTIONS：查詢相應(yīng)URI支持的HTTP方法。
1、get請求通常是向服務(wù)器獲取資源、post請求通常是向服務(wù)器發(fā)送數(shù)據(jù)
2、get傳輸數(shù)據(jù)是通過URL請求，以field（字段）= value的形式，置于URL后，并用"?"連接，多個請求數(shù)據(jù)間用"&"連接，傳輸?shù)臄?shù)據(jù)也是有限的（1M），如http://127.0.0.1/ogin.do?name=admin&password=admin
3、get請求是將請求參數(shù)放在請求的url中，相對來說不安全
4、post是通過表單的方式傳輸數(shù)據(jù)的，傳輸數(shù)據(jù)沒有限制、比get請求安全
六、HTTP與HTTPS
? ? ? ?HTTP：是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，是一個客戶端和服務(wù)器端請求和應(yīng)答的標(biāo)準(zhǔn)（TCP），用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議，它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。
HTTPS：是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。
HTTPS協(xié)議的主要作用可以分為兩種：一種是建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?；另一種就是確認(rèn)網(wǎng)站的真實性。
HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是明文的，使用HTTP協(xié)議傳輸隱私信息是不安全的，為了保證這些隱私數(shù)據(jù)能加密傳輸，于是設(shè)計了SSL（Secure Sockets Layer）協(xié)議用于對HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進行加密，從而就誕生了HTTPS。簡單來說，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全。
HTTPS和HTTP的區(qū)別主要如下：
1、https協(xié)議需要到ca申請網(wǎng)站證書。
2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是采用ssl加密傳輸協(xié)議。
3、http和https采用不同的連接方式，用的端口也不一樣，http的默認(rèn)端口是80，https的默認(rèn)端口是443。
https建立通信過程如下：
（1）客戶使用https的URL訪問服務(wù)器，請求與服務(wù)器建立SSL連接。
（2）服務(wù)器收到客戶端請求后，會將網(wǎng)站的證書信息（證書中包含公鑰）返回給客戶端。
?。?）客戶端的瀏覽器與服務(wù)器進行協(xié)商SSL連接的安全等級，也就是信息加密的等級。
?。?）客戶端的瀏覽器根據(jù)雙方同意的安全等級，建立會話密鑰，然后利用網(wǎng)站的公鑰將會話密鑰加密，并傳送給網(wǎng)站。
（5）服務(wù)器利用自己的私鑰解密出會話密鑰。
?。?）服務(wù)器利用會話密鑰加密與客戶端之間的通信。
歡迎大家關(guān)注我的訂閱號，會定期分享一些關(guān)于測試相關(guān)的文章，有問題也歡迎一起討論學(xué)習(xí)！
