HTTP是不保存狀態(tài)的協(xié)議，協(xié)議本身不保留之前一切的請求或響應(yīng)報文的信息英融。這是為了更快地處理大量事物，確保協(xié)議的可伸縮性歇式，而特意把HTTP協(xié)議設(shè)計成如此簡單的驶悟。

可是，隨著Web的不斷發(fā)展材失，因無狀態(tài)而導(dǎo)致業(yè)務(wù)處理變得棘手的情況增多了痕鳍。比如，用戶登錄到一家購物網(wǎng)站龙巨，即使他跳轉(zhuǎn)到該站的其他頁面后笼呆，也需要保持登錄狀態(tài)。針對這個實(shí)例旨别，網(wǎng)站為了能夠掌握是誰送出的請求诗赌，需要保存用戶的狀態(tài)。

HTTP1.1雖然是無狀態(tài)協(xié)議秸弛，但為了實(shí)現(xiàn)期望的保持狀態(tài)功能铭若，于是引入了Cookie技術(shù)洪碳。有了Cookie再用HTTP協(xié)議通信，就可以管理狀態(tài)了叼屠。

在HTTP1.1中瞳腌，所有的連接默認(rèn)都是持久連接，但在HTTP1.0內(nèi)并未標(biāo)準(zhǔn)化镜雨。雖然有一部分服務(wù)器通過非標(biāo)準(zhǔn)化的手段實(shí)現(xiàn)了持久連接嫂侍，但服務(wù)器端不一定能夠支持持久連接。毫無疑問荚坞，除了服務(wù)器挑宠，客戶端也需要支持持久連接。

狀態(tài)碼：

1XX：信息性狀態(tài)碼西剥，表示接收的請求正在處理
2XX：成功狀態(tài)碼痹栖，表示請求正常處理完畢。
200：OK
204：No Content
206：Partical Content(指定范圍的實(shí)體內(nèi)容)
3XX：重定向狀態(tài)碼瞭空，表示需要進(jìn)行附加操作以完成請求
301：永久性重定向
302：臨時性重定向
303：與302有相同的功能，但303狀態(tài)碼明確表示客戶端應(yīng)當(dāng)采用GET
方法獲取資源疗我，這點(diǎn)與302狀態(tài)碼有區(qū)別咆畏。
304：客戶端發(fā)送請求，未滿足條件的情況下吴裤，直接返回304

304狀態(tài)碼的意義:
如果一個網(wǎng)站被搜索引擎抓取的次數(shù)以及頻率越多那么他是越有利于排名的旧找，但是如果你的網(wǎng)站出現(xiàn)太多的304，那么一定會降低搜索引擎的抓取頻率以及次數(shù)麦牺，從而讓自己的網(wǎng)站排名比別人落一步

.
307：和302有相同含義
4XX：客戶端錯誤狀態(tài)碼钮蛛，表示服務(wù)器無法處理請求
400：客戶端請求報文中存在語法錯誤
401：發(fā)送請求需要通過HTTP認(rèn)證，當(dāng)瀏覽器初次收到401響應(yīng)剖膳，會彈出認(rèn)證用的對話窗口
403：客戶端請求訪問資源魏颓，被服務(wù)器拒絕了，未獲得文件系統(tǒng)的訪問權(quán)
404：服務(wù)器上無法找到請求的資源
5XX：服務(wù)器錯誤狀態(tài)碼吱晒，服務(wù)器處理請求出錯
500：服務(wù)器故障
501：服務(wù)器暫時超負(fù)荷或停機(jī)維護(hù)

通信數(shù)據(jù)轉(zhuǎn)發(fā)程序：網(wǎng)關(guān)甸饱、代理、隧道
代理：服務(wù)器和客戶端中間人的角色仑濒。有兩種基準(zhǔn)分類：1.是否使用緩存 2.是否會修改報文
網(wǎng)關(guān)：工作機(jī)制和代理相似叹话，網(wǎng)關(guān)能使通信線路上的服務(wù)器提供非HTTP協(xié)議服務(wù)。如Web購物網(wǎng)站上進(jìn)行信用卡結(jié)算時墩瞳，網(wǎng)關(guān)可以和信用卡結(jié)算系統(tǒng)聯(lián)動驼壶，提高通信的安全性。
隧道：隧道通信線路會使用SSL等加密手段進(jìn)行通信喉酌，目的是確比劝迹客戶端與服務(wù)器進(jìn)行安全通信箩溃。

HTTP首部

HTTP協(xié)議的請求和響應(yīng)報文中必定包含HTTP首部。
HTTP報文：報文首部+空行+報文主體
HTTP請求報文的報文首部：請求行（報文方法+URI+HTTP版本）+HTTP首部字段（請求首部字段+通用首部字段+實(shí)體首部字段）+其他
HTTP響應(yīng)報文的報文首部：狀態(tài)行（HTTP版本+狀態(tài)碼）+HTTP首部字段（響應(yīng)首部字段+通用首部字段+實(shí)體首部字段）+其他

HTTP使用首部字段（字段名：字段值）是為了給瀏覽器和服務(wù)器提供報文主體大小碌嘀、所使用的語言涣旨、認(rèn)證信息等內(nèi)容。

HTTP首部字段：通用首部字段股冗、請求首部字段霹陡、響應(yīng)首部字段、實(shí)體首部字段

一 通用首部字段:請求報文和響應(yīng)報文雙方都會使用的首部止状。

1.Cache-Control：緩存工作機(jī)制
1.1 public:表明其他用戶可以利用緩存
1.2 private：緩存服務(wù)器對特定用戶提供資源緩存服務(wù)烹棉，對于其他用戶發(fā)送過來的請求，代理服務(wù)器則不會返回緩存
1.3 no-cache：直接從服務(wù)器獲取資源怯疤，不從緩存服務(wù)器中返回資源
1.4 no-store：請求或響應(yīng)中包含機(jī)密信息浆洗。因此緩存不能在本地存儲請求或響應(yīng)的任一部分。
1.5 s-maxage：適用于供多位用戶使用的公共緩存服務(wù)器集峦。對單一用戶重復(fù)返回響應(yīng)的服務(wù)器來說伏社，該指令無效。
1.6 max-age：代表資源保存為緩存的最長時間
1.7 min-fresh：緩存服務(wù)器返回緩存資源的指定時間塔淤，超過則不返回
1.8 max-stale：緩存資源過期也照常接收
1.9 only-if-cached：緩存服務(wù)器不重新加載響應(yīng)摘昌，也不會再次確認(rèn)資源有效性。若發(fā)生緩存服務(wù)器無響應(yīng)高蜂，則返回狀態(tài)碼504 Gateway Timeout
1.10 must-revalidate：代理會向服務(wù)器再次驗證即將返回的響應(yīng)緩存目前是否仍然有效聪黎。該指令會忽略請求的max-stale指令
1.11 proxy-revalidate：緩存服務(wù)器在接收到客戶端帶有該指令的請求，在返回響應(yīng)之前备恤，必須再次驗證緩存的有效性稿饰。
1.12 no-transform：無論請求還是響應(yīng)中，緩存都不能改變實(shí)體主體的媒體類型露泊，以防止緩存或代理壓縮圖片等操作喉镰。

2.Connection 控制不再轉(zhuǎn)發(fā)給代理的首部字段+管理持久連接
HTTP/1.1之前的HTTP版本的默認(rèn)連接都是非持久連接。為此滤淳，如果想在舊版本的HTTP協(xié)議想維持持續(xù)連接梧喷，則需要制定Connection首部字段的值為Keep-Alive。

3.Date 創(chuàng)建HTTP報文的日期和時間

4.Pragma HTTP/1.1之前版本的歷史遺留字段脖咐，僅作為與HTTP/1.0的向后兼容而定義铺敌。全部服務(wù)器使用的HTTP協(xié)議版本一致是不現(xiàn)實(shí)的，發(fā)送請求時會含有下面兩個字段：
Cache-Control：no-cache
Pragma：no-cache

5.Trailer 應(yīng)用在HTTP/1.1版本分塊傳輸編碼時

6.Transfer-Encoding 規(guī)定了傳輸報文主體時采用的編碼方式

7.Update 用于檢測HTTP協(xié)議及其他協(xié)議是否可使用更高的版本進(jìn)行通信屁擅，其參數(shù)可以用來指定一個完全不同的通信協(xié)議偿凭。

8.Via 追蹤客戶端與服務(wù)器之間的請求和響應(yīng)報文的傳輸路徑。報文經(jīng)過代理或網(wǎng)關(guān)時派歌，會先在首部字段Via中添加該服務(wù)器的信息弯囊，然后再進(jìn)行轉(zhuǎn)發(fā)痰哨。這個做法和traceroute及電子郵件的Received首部的工作機(jī)制很類似。

9.Warning 告知用戶一些與緩存相關(guān)的問題的警告

二 請求首部字段：客戶端往服務(wù)器發(fā)送請求報文中所使用的字段匾嘱，用于補(bǔ)充請求的附加信息斤斧、客戶端信息、對響應(yīng)內(nèi)容相關(guān)的優(yōu)先級等內(nèi)容霎烙。

1.Accept 通知服務(wù)器撬讽，用戶代理能夠處理的媒體類型及媒體類型的相對優(yōu)先級。
2.Accept-Charset 通知服務(wù)器用戶代理支持的字符集及字符集的相對優(yōu)先順序悬垃。
3.Accept-Encoding 告知服務(wù)器用戶代理支持的內(nèi)容編碼及內(nèi)容編碼的優(yōu)先級順序游昼。
4.Accept-Language 告知服務(wù)器用戶代理能處理的自然語言集（指中文或英文等），以及自然語言集的相對優(yōu)先級尝蠕『嫱悖可一次指定多種自然語言集。
5.Authorization 告知服務(wù)器看彼，用戶代理的認(rèn)證信息
6.Expect 告知服務(wù)器廊佩，期望出現(xiàn)的某種特定行為
7.From 告知服務(wù)器使用用戶代理的用戶的電子郵件地址
8.Host 告知服務(wù)器，請求資源所處的互聯(lián)網(wǎng)主機(jī)名和端口號
9.If-Match 當(dāng)If-Match的字段值跟ETag值匹配一致時闲昭，服務(wù)器才會接受請求罐寨。
10.If-Modified-Since 告知服務(wù)器，若在If-Modified-Since日期后序矩，更新過資源，則處理請求跋破，若未更新過簸淀，則返回狀態(tài)碼304Not Modified的響應(yīng)。
11.If-None-Match If-None-Match字段值的實(shí)體標(biāo)記（ETag）值與請求資源的ETag不一致時毒返，它就告知服務(wù)器處理該請求租幕。
12.If-Range 告知服務(wù)器若指定的If-Range字段值（ETag值或時間）和請求資源的ETag值或時間相一致時，則作為范圍請求處理拧簸。反之劲绪，則返回全體資源。
13.If-Unmodified-Since 告知服務(wù)器盆赤，若在If-Unmodified-Since字段值后贾富，未更新過資源，則處理請求牺六，若更新過颤枪，則返回狀態(tài)碼412 Precondition Failed的響應(yīng)。
14.Max-Forwards 通過TRACE或OPTIONS方法淑际，發(fā)送包含首部字段Max-Forwards的請求時畏纲，該字段以十進(jìn)制整數(shù)形式指定可經(jīng)過的服務(wù)器最大數(shù)目扇住。服務(wù)器在往下一個服務(wù)器轉(zhuǎn)發(fā)請求之前，會將Max-Forwards的值減1后重新賦值盗胀。當(dāng)服務(wù)器接收到Max-Forwards的值為0時艘蹋，則不再進(jìn)行轉(zhuǎn)發(fā)，而是直接返回響應(yīng)票灰。
15.Proxy-Authorization 從代理服務(wù)器發(fā)來的認(rèn)證質(zhì)詢時女阀，客戶端會發(fā)送包含首部字段Proxy-Authorization的請求，以告知服務(wù)器認(rèn)證所需要的信息米间。認(rèn)證行為發(fā)生在客戶端和代理之間强品，客戶端和服務(wù)器之間的認(rèn)證，使用首部字段Authorization可起到相同作用屈糊。
16.Range 對于只需獲取部分資源的范圍請求的榛，包含首部字段Range即可告知服務(wù)器資源的指定范圍。
17.Refer 首部字段Refer會告知服務(wù)器請求的原始資源的URI逻锐。
18.TE 告知服務(wù)器客戶端能夠處理響應(yīng)的傳輸編碼方式及相對優(yōu)先級夫晌。它和首部字段Accept-Encoding的功能很相像，但是用于傳輸編碼昧诱。
19.User-Agent 將創(chuàng)建請求的瀏覽器和用戶代理名稱等信息傳達(dá)給服務(wù)器

三 響應(yīng)首部字段：響應(yīng)首部字段是有服務(wù)器向客戶端返回響應(yīng)報文中所使用的字段晓淀，用于補(bǔ)充響應(yīng)的附加信息、服務(wù)器信息盏档，以及對客戶端的附加要求等信息凶掰。

1.Accept-Ranges 告知客戶端 服務(wù)器是否能處理范圍請求，以指定獲取服務(wù)器端某個部分的資源蜈亩∨尘剑可處理范圍請求時指定為：bytes 反之則指定為：none
2.Age 告知客戶端，源服務(wù)器在多久前創(chuàng)建了響應(yīng)稚配。單位：秒
3.ETag 客戶端實(shí)體標(biāo)識畅涂。它是一種可將資源以字符串形式做唯一性標(biāo)識的方式。服務(wù)器會為每份資源分配對應(yīng)的ETag值道川。
4.Location 可以將響應(yīng)接收方引導(dǎo)至某個與請求URI位置不同的資源午衰。
5.Proxy-Authenticate 會把由代理服務(wù)器所要求的認(rèn)證信息發(fā)送給客戶端
6.Retry-After 告知客戶端應(yīng)該在多久之后再次發(fā)送請求
7.Sever 告知客戶端當(dāng)前服務(wù)器上安裝的HTTP服務(wù)器應(yīng)用程序的信息
8.Vary 對緩存進(jìn)行控制。如：Vary:Accept-Language 則只對持相同自然語言的請求返回緩存
9.WWW-Authenticate 用于HTTP訪問認(rèn)證

四 實(shí)體首部字段：實(shí)體首部字段是指包含在請求報文和響應(yīng)報文中的實(shí)體部分所使用的首部冒萄，用于補(bǔ)充內(nèi)容的更新時間等與實(shí)體相關(guān)的信息臊岸。

1.Allow 通知客戶端能夠支持Request-URI指定資源的所有HTTP方法。當(dāng)服務(wù)器接收到不支持的HTTP方法時宦言，會以狀態(tài)碼405 Method Not Allowed 作為響應(yīng)返回扇单。與此同時，還會把所有能支持的HTTP方法寫入首部字段Allow后返回奠旺。
2.Content-Encoding 告知客戶端 服務(wù)器對實(shí)體的主體部分選用的內(nèi)容編碼方式
3.Content-Language 告知客戶端蜘澜，實(shí)體主體使用的自然語言（指中文或英文等語言）
4.Content-Length 表明了實(shí)體主體部分的大小
5.Content-Location 給出報文主體部分相對應(yīng)的URI施流。和首部字段Location不同，Content-Location表示的是報文主體返回資源對應(yīng)的URI鄙信。
6.Content-MD5 是一串MD5算法生成的值瞪醋，其目的在于檢查報文主體在傳輸過程中是否保持完整，以及確認(rèn)傳輸?shù)竭_(dá)装诡。
7.Content-Range 針對范圍請求银受，返回響應(yīng)是使用的首部字段Content-Range，能告知客戶端作為響應(yīng)返回的實(shí)體的哪個部分符合范圍請求鸦采。字段值以字節(jié)為單位宾巍，表示當(dāng)前發(fā)送部分以及整個實(shí)體大小。例：Content-Range：bytes 5001-10000/10000
8.Content-Type 說明了實(shí)體主體內(nèi)對象的媒體類型
9.Empires 會將資源失效的日期告知客戶端
10.Last-Modified 指資源最終修改的時間

Post請求下的Content-Type類型（編碼類型）

1. application/x-www-form-urlencoded
   這應(yīng)該是最常見的 POST 提交數(shù)據(jù)的方式了渔伯。瀏覽器的原生 <form> 表單顶霞，如果不設(shè)置 enctype 屬性，那么最終就會以 application/x-www-form-urlencoded 方式提交數(shù)據(jù)锣吼。請求類似于下面這樣（無關(guān)的請求頭在本文中都省略掉了）：

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

首先选浑，Content-Type 被指定為 application/x-www-form-urlencoded；其次玄叠，提交的數(shù)據(jù)按照 key1=val1&key2=val2 的方式進(jìn)行編碼古徒，key 和 val 都進(jìn)行了 URL 轉(zhuǎn)碼。

2. multipart/form-data
   這又是一個常見的 POST 數(shù)據(jù)提交的方式读恃。我們使用表單上傳文件時隧膘，必須讓 <form> 表單的 enctype 等于 multipart/form-data。
   直接來看一個請求示例：
   form表單：

<form action="/upload" enctype="multipart/form-data" method="post">
    Username: <input type="text" name="username">
    Password: <input type="password" name="password">
    File: <input type="file" name="file">
    <input type="submit">
</form>

Http協(xié)議請求：

POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA
 
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"
 
title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png
 
PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

這個例子稍微復(fù)雜點(diǎn)寺惫。首先生成了一個 boundary 用于分割不同的字段舀寓，為了避免與正文內(nèi)容重復(fù)，boundary 很長很復(fù)雜肌蜻。然后 Content-Type 里指明了數(shù)據(jù)是以 multipart/form-data 來編碼，本次請求的 boundary 是什么內(nèi)容必尼。消息主體里按照字段個數(shù)又分為多個結(jié)構(gòu)類似的部分蒋搜，每部分都是以 --boundary 開始，緊接著是內(nèi)容描述信息判莉，然后是回車豆挽，最后是字段具體內(nèi)容（文本或二進(jìn)制）。如果傳輸?shù)氖俏募眩€要包含文件名和文件類型信息帮哈。消息主體最后以 --boundary-- 標(biāo)示結(jié)束。關(guān)于 multipart/form-data 的詳細(xì)定義锰镀，請前往 rfc1867 查看娘侍。

這種方式一般用來上傳文件咖刃，各大服務(wù)端語言對它也有著良好的支持。

上面提到的這兩種 POST 數(shù)據(jù)的方式憾筏，都是瀏覽器原生支持的嚎杨，而且現(xiàn)階段標(biāo)準(zhǔn)中原生 <form> 表單也只支持這兩種方式（通過 <form> 元素的 enctype 屬性指定，默認(rèn)為 application/x-www-form-urlencoded氧腰。其實(shí) enctype 還支持 text/plain枫浙，不過用得非常少）。

3. application/json
   application/json 這個 Content-Type 作為響應(yīng)頭大家肯定不陌生古拴。實(shí)際上箩帚，現(xiàn)在越來越多的人把它作為請求頭，用來告訴服務(wù)端消息主體是序列化后的 JSON 字符串黄痪。由于 JSON 規(guī)范的流行紧帕，除了低版本 IE 之外的各大瀏覽器都原生支持 JSON.stringify，服務(wù)端語言也都有處理 JSON 的函數(shù)满力，使用 JSON 不會遇上什么麻煩焕参。

JSON 格式支持比鍵值對復(fù)雜得多的結(jié)構(gòu)化數(shù)據(jù)，這一點(diǎn)也很有用油额。記得我?guī)啄昵白鲆粋€項目時叠纷，需要提交的數(shù)據(jù)層次非常深，我就是把數(shù)據(jù) JSON 序列化之后來提交的潦嘶。不過當(dāng)時我是把 JSON 字符串作為 val涩嚣，仍然放在鍵值對里，以 x-www-form-urlencoded 方式提交掂僵。

Google 的 AngularJS 中的 Ajax 功能航厚，默認(rèn)就是提交 JSON 字符串。例如下面這段代碼：

var data = {'title':'test', 'sub' : [1,2,3]};
$http.post(url, data).success(function(result) {
    ...
});

最終發(fā)送的請求是：

POST http://www.example.com HTTP/1.1
Content-Type: application/json;charset=utf-8
 
{"title":"test","sub":[1,2,3]}

php://input
json_decode

當(dāng)然 AngularJS 也可以配置為使用 x-www-form-urlencoded 方式提交數(shù)據(jù)锰蓬。如有需要幔睬，可以參考這篇文章。

4. text/xml
   它是一種使用 HTTP 作為傳輸協(xié)議芹扭，XML 作為編碼方式的遠(yuǎn)程調(diào)用規(guī)范麻顶。典型的 XML-RPC 請求是這樣的：

POST http://www.example.com HTTP/1.1
Content-Type: text/xml
 
<?xml version="1.0"?>
<methodCall>
    <methodName>examples.getStateName</methodName>
    <params>
        <param>
            <value><i4>41</i4></value>
        </param>
    </params>
</methodCall>

XML-RPC 協(xié)議簡單、功能夠用舱卡，各種語言的實(shí)現(xiàn)都有辅肾。它的使用也很廣泛，如 WordPress 的 XML-RPC Api轮锥，搜索引擎的 ping 服務(wù)等等矫钓。JavaScript 中，也有現(xiàn)成的庫支持以這種方式進(jìn)行數(shù)據(jù)交互，能很好的支持已有的 XML-RPC 服務(wù)新娜。不過赵辕，我個人覺得 XML 結(jié)構(gòu)還是過于臃腫，一般場景用 JSON 會更靈活方便杯活。

相比之下匆帚，get方式的數(shù)據(jù)提交方式（編碼方式）只有一種，就是application/x-www-form-urlencoding

確保Web安全的HTTPS

HTTP與HTTPS之間的最重要差別在于會話的連接建立階段旁钧。在TCP連接建立好吸重、HTTP請求發(fā)送前，客戶端與服務(wù)器之間必須建立SSL會話歪今。SSL會話建立包含多個階段:客戶端與服務(wù)器協(xié)商使用何種密碼嚎幸、交換公鑰、驗證協(xié)商以及驗證身份（可選）寄猩。當(dāng)SSL會話建立完畢后嫉晶，在TCP連接之上傳輸?shù)乃袛?shù)據(jù)都將是加密的。

HTTPS 的實(shí)現(xiàn)原理

SSL 建立連接過程

SSL 建立連接過程.png

SSL建立連接過程.png

1. client 向 server 發(fā)送請求 https://baidu.com田篇，然后連接到 server 的 443 端口替废，發(fā)送的信息主要是隨機(jī)值1和客戶端支持的加密算法。
2. server 接收到信息之后給予 client 響應(yīng)握手信息泊柬，包括隨機(jī)值2和匹配好的協(xié)商加密算法椎镣，這個加密算法一定是 client 發(fā)送給 server 加密算法的子集。
3. 隨即 server 給 client 發(fā)送第二個響應(yīng)報文是數(shù)字證書兽赁。服務(wù)端必須要有一套數(shù)字證書状答，可以自己制作，也可以向組織申請刀崖。區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過惊科，才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面亮钦，這套證書其實(shí)就是一對公鑰和私鑰馆截。傳送證書，這個證書其實(shí)就是公鑰蜂莉，只是包含了很多信息孙咪，如證書的頒發(fā)機(jī)構(gòu)，過期時間巡语、服務(wù)端的公鑰，第三方證書認(rèn)證機(jī)構(gòu)(CA)的簽名淮菠，服務(wù)端的域名信息等內(nèi)容男公。
4. 客戶端解析證書，這部分工作是由客戶端的 TLS 來完成的，首先會驗證公鑰是否有效枢赔，比如頒發(fā)機(jī)構(gòu)澄阳，過期時間等等，如果發(fā)現(xiàn)異常踏拜，則會彈出一個警告框碎赢，提示證書存在問題。如果證書沒有問題速梗，那么就生成一個隨即值（預(yù)主秘鑰）肮塞。
5. 客戶端認(rèn)證證書通過之后，接下來是通過隨機(jī)值1姻锁、隨機(jī)值2和預(yù)主秘鑰組裝會話秘鑰枕赵。然后通過證書的公鑰加密會話秘鑰。
6. 傳送加密信息位隶，這部分傳送的是用證書加密后的會話秘鑰拷窜，目的就是讓服務(wù)端使用秘鑰解密得到隨機(jī)值1、隨機(jī)值2和預(yù)主秘鑰涧黄。
7. 服務(wù)端解密得到隨機(jī)值1篮昧、隨機(jī)值2和預(yù)主秘鑰，然后組裝會話秘鑰笋妥，跟客戶端會話秘鑰相同懊昨。
8. 客戶端通過會話秘鑰加密一條消息發(fā)送給服務(wù)端于购，主要驗證服務(wù)端是否正常接受客戶端加密的消息炫刷。
9. 同樣服務(wù)端也會通過會話秘鑰加密一條消息回傳給客戶端斯够，如果客戶端能夠正常接受的話表明SSL層連接建立完成了疤估。

怎么保證保證服務(wù)器給客戶端下發(fā)的公鑰是真正的公鑰碧查，而不是中間人偽造的公鑰呢罪郊？

因為客戶端 TLS 驗證公鑰失敗颖对，之后的流程就不會執(zhí)行挺据，中間人獲取不到客戶端的發(fā)出的信息：如下圖虛線部分無法執(zhí)行嫁赏。

不讓請求變成無效的唯一方法就是信任其掂，該信任由網(wǎng)絡(luò)庫放置在接收到的證書之中。證書
只是簽名的公鑰潦蝇。因此款熬，如果網(wǎng)絡(luò)庫信任簽名者，那它也會信任主機(jī)提供的公鑰攘乒。黑客提
供的假的根證書成為了讓所有安全措施崩潰的罪魁禍?zhǔn)住?/p>

這個問題的解決方案就是所謂的證書鎖定贤牛。這種方案的工作原理是，通過只信任一個或幾個能夠作為應(yīng)用 根證書的證書则酝，應(yīng)用創(chuàng)建一個自定義的信任級別殉簸。這允許應(yīng)用僅信任來自白名單的證書， 確保設(shè)備上永不安裝那些允許網(wǎng)絡(luò)監(jiān)視的未知證書。

SSL 建立連接.png

HTTP的缺點(diǎn)：

通信使用明文（不加密）般卑，內(nèi)容可能會被竊聽
抓包工具可獲取到HTTP響應(yīng)報文的內(nèi)容武鲁，所以我們需要對通信進(jìn)行加密。
不驗證通信防的身份蝠检，因此有可能遭遇偽裝
任何人都可以發(fā)起請求沐鼠，所以我們?yōu)榱舜_認(rèn)通信方，就可以使用查明對手證書的方式進(jìn)行驗證叹谁。
無法證明報文的完整性饲梭，所以有可能已遭篡改
SSL提供認(rèn)證和加密處理及摘要功能。HTTP直接和TCP通信本慕，當(dāng)使用SSL時排拷，則演變成先和SSL通信，再由SSL和TCP通信了锅尘。簡言之监氢，所謂HTTPS，其實(shí)就是身披SSL協(xié)議這層外殼的HTTP藤违。
SSL技術(shù)最初是由瀏覽器開發(fā)商網(wǎng)景通信公司率先倡導(dǎo)的浪腐，開發(fā)過SSL3.0之前的版本。目前主導(dǎo)權(quán)已轉(zhuǎn)移到IETF（Internet Engineering Task Force顿乒，Internet工程任務(wù)組）的手中议街。IETF以SSL3.0為基準(zhǔn)，后又制定了TLS1.0璧榄、TLS1.1特漩、TLS1.2。TLS是以SSL為原型開發(fā)的協(xié)議骨杂，有時會統(tǒng)一稱該協(xié)議為SSL涂身。當(dāng)前主流的版本是SSL3.0和TLS1.0。
HTTPS在使用SSL時搓蚪，它的處理速度會變慢蛤售。一是因為先與SSL通信，通信量會增加妒潭，二是因為悴能，SSL必須進(jìn)行加密處理，會消耗服務(wù)器和客戶端的硬件資源雳灾。

基于HTTP的功能追加協(xié)議
HTTP協(xié)議的缺點(diǎn)：
一條連接上只可發(fā)送一個請求
請求只能從客戶端開始漠酿。客戶端不可以接收除響應(yīng)以外的指令谎亩。
請求/響應(yīng)首部未經(jīng)壓縮就發(fā)送记靡。首部信息越多延遲越大谈竿。
發(fā)送冗長的首部。每次相互發(fā)送相同的首部造成的浪費(fèi)較多摸吠。
可任意選擇數(shù)據(jù)壓縮方式。非強(qiáng)制壓縮發(fā)送嚎花。
追加的協(xié)議:
1.Google發(fā)布了SPDY協(xié)議寸痢，在TCP/IP的應(yīng)用層與運(yùn)輸層之間通過新加會話層的形式運(yùn)作，通過多路復(fù)用流（單個TCP連接可以無限制處理多個HTTP請求）紊选、賦予請求優(yōu)先級啼止、壓縮HTTP首部、推送功能兵罢、服務(wù)器提示功能献烦，來縮短Web頁面的加載時間。
2.Ajax利用JavaScript和DOM的操作卖词，以達(dá)到局部Web頁面替換加載的異步通信手段巩那。通過JavaScript腳本語言功能就能和服務(wù)器進(jìn)行HTTP通信，借由這種手段此蜈，就能從已加載完的Web頁面上發(fā)起請求即横，只更新局部頁面。
3.Comet將響應(yīng)置于掛起狀態(tài)裆赵，當(dāng)服務(wù)器端有內(nèi)容更新時东囚，再返回該響應(yīng)。因此战授，服務(wù)器端一旦有更新页藻，就可以立即反饋給客戶端。這樣就會導(dǎo)致一次連接的持續(xù)時間變長植兰，會消耗更多資源份帐。
4.WebSocket是建立在HTTP基礎(chǔ)上的協(xié)議，連接的發(fā)起方仍是客戶端钉跷，一旦建立WebSocket通信連接弥鹦，不論服務(wù)器還是客戶端，任意一方都可直接向?qū)Ψ桨l(fā)送報文爷辙。因為服務(wù)器可以直接發(fā)送數(shù)據(jù)彬坏，服務(wù)器就具備推送功能。和HTTP相比膝晾，不但每次連接時的總開銷減少栓始，而且由于WebSocket的首部信息很小，通信量也相應(yīng)減少血当。
5.HTTP Speed + Mobility由微軟公司起草幻赚，用于改善并提高移動端通信時的通信速度和性能的標(biāo)準(zhǔn)禀忆。
6.Network-Friendly HTTP Upgrade主要是在移動端通信時改善HTTP性能的標(biāo)準(zhǔn)

構(gòu)建Web內(nèi)容的技術(shù)
Web頁面幾乎全有HTML（超文本標(biāo)記語言）構(gòu)建
2014年左右使用的HTML5標(biāo)準(zhǔn)，依然是現(xiàn)在HTML的使用標(biāo)準(zhǔn)
CSS指定如何展現(xiàn)HTML內(nèi)的各種元素落恼，屬于樣式表標(biāo)準(zhǔn)之一箩退。
動態(tài)HTML技術(shù)是客戶端通過JavaScript實(shí)現(xiàn)對HTML的Web頁面的動態(tài)改造，利用DOM可指定欲發(fā)生動態(tài)變化的HTML元素佳谦。
服務(wù)器返回事先編寫好的HTML是屬于靜態(tài)內(nèi)容
服務(wù)器返回由Web服務(wù)器上的程序創(chuàng)建的HTML內(nèi)容戴涝，叫動態(tài)內(nèi)容
XML（可擴(kuò)展標(biāo)記語言）和HTML都是從標(biāo)準(zhǔn)通用標(biāo)記語言SGML簡化而成。
XML文檔中讀取數(shù)據(jù)比HTML簡單钻蔑，而被互聯(lián)網(wǎng)廣泛接受
RSS（簡易信息聚合）/ Atom都用到了XML
JSON是一種由JavaScript的對象表示法為基礎(chǔ)的輕量級數(shù)據(jù)標(biāo)記語
言啥刻。

Web的攻擊技術(shù)
1.因為HTTP不具備必要的安全功能，攻擊者就可以在客戶端和服務(wù)器發(fā)起攻擊咪笑。在客戶端篡改請求可帽、以服務(wù)器端為目標(biāo)的主動攻擊：SQL注入攻擊 和 OS命令注入攻擊、以服務(wù)器端為目標(biāo)的被動攻擊：利用設(shè)置好的陷阱劫持用戶所持的Cookie等個人信息窗怒。
2.因輸出值轉(zhuǎn)義不完全引發(fā)的安全漏洞映跟。
1）跨站腳本攻擊，就是彈出一些窗口來獲取用戶的Cookie等個人信息
2）SQL注入攻擊兜粘，就是通過修改SQL語句申窘，導(dǎo)致用戶瀏覽的數(shù)據(jù)遭到非法瀏覽及篡改。
3）OS命令注入攻擊孔轴，通過Web應(yīng)用剃法，執(zhí)行非法的操作系統(tǒng)命令達(dá)到攻擊的目的。只要在能調(diào)用Shell函數(shù)的地方就有存在被攻擊的風(fēng)險路鹰。OS命令注入攻擊可以向Shell發(fā)送命令贷洲，執(zhí)行OS上安裝的各種程序。
4）HTTP首部注入攻擊晋柱，是指攻擊者通過在響應(yīng)首部字段內(nèi)插入換行优构，添加任意響應(yīng)首部或主體的一種攻擊。就是讓服務(wù)器跳轉(zhuǎn)到指定頁面的一種攻擊手段雁竞。
5）郵件注入攻擊钦椭，是指Web應(yīng)用中的郵件發(fā)送功能，攻擊者通過向郵件首部To或Subject內(nèi)任意添加非法內(nèi)容發(fā)起的攻擊碑诉。利用存在安全漏洞的Web網(wǎng)站彪腔，可對任意郵件地址發(fā)送廣告郵件或病毒郵件。
6）目錄遍歷攻擊进栽，是指對本無意公開的文件目錄德挣，通過非法截斷其目錄路徑后，達(dá)到訪問目的的一種攻擊快毛。這種攻擊有時也稱為路徑遍歷攻擊格嗅。
7）遠(yuǎn)程文件包含漏洞番挺，是指當(dāng)部分腳本內(nèi)容需要從其他文件讀入時，攻擊者利用指定外部服務(wù)器的URL充當(dāng)依賴文件玄柏，讓腳本讀取之后，就可運(yùn)行任意腳本的一種攻擊贴铜。這主要是PHP存在的安全漏洞禁荸，對PHP的include或require來說，通過設(shè)定阀湿，指定外部服務(wù)器URL作為文件名的功能。由于太危險瑰妄，PHP5.2.0之后默認(rèn)設(shè)定此功能無效陷嘴。
8）遠(yuǎn)程文件包含漏洞，是指當(dāng)部分腳本內(nèi)容需要從其他文件讀入時间坐，攻擊者利用指定外部服務(wù)器的URL充當(dāng)依賴文件灾挨，讓腳本讀取之后，就可運(yùn)行任意腳本的一種攻擊竹宋。
3.因設(shè)置或設(shè)計上的缺陷引發(fā)的安全漏洞劳澄。
1）強(qiáng)制瀏覽，從安置在Web服務(wù)器的公開目錄下的文件中蜈七，瀏覽哪些原本非自愿公開的文件秒拔。
2）不正確的錯誤消息處理。系統(tǒng)拋出的錯誤信息是對開發(fā)者有用的信息飒硅，對于用戶來說是沒必要展示的砂缩，但對攻擊者來說，詳細(xì)的錯誤信息可能會給他們下一次攻擊以提示三娩。
3）開放重定向庵芭，是一種對指定的任意URL作重定向跳轉(zhuǎn)的功能∪讣啵可信度高的Web網(wǎng)站双吆，如果開放重定向功能，則很有可能被攻擊者選中并用來作為釣魚攻擊的跳板会前。
4.因會話管理疏忽引發(fā)的安全漏洞好乐。
1）會話劫持，是指被攻擊者拿到了用戶的會話ID回官，并非法使用此會話ID偽裝成用戶曹宴，達(dá)到攻擊的目的。
2）會話固定攻擊歉提，會強(qiáng)制用戶使用攻擊者指定的會話ID笛坦。
3）跨站點(diǎn)請求偽造区转，是指攻擊者通過設(shè)置好的陷阱，強(qiáng)制對已完成認(rèn)證的用戶進(jìn)行非預(yù)期的個人信息設(shè)定或設(shè)定信息等某些狀態(tài)更新版扩。
5.其他安全漏洞废离。
1）密碼破解，窮舉法礁芦、字典攻擊
2）點(diǎn)擊劫持蜻韭，是指利用透明的按鈕或鏈接做成陷阱，覆蓋在Web頁面之上柿扣。用戶在不知情的情況下肖方，點(diǎn)擊鏈接的一種攻擊手段，又稱為界面?zhèn)窝b未状。
3）DoS攻擊俯画，拒絕服務(wù)攻擊，有以下兩種DoS攻擊方式
·集中利用訪問請求造成資源過載司草，資源用盡的同時艰垂，實(shí)際上服務(wù)也就呈停止?fàn)顟B(tài)。
·通過攻擊安全漏洞使服務(wù)停止埋虹。
4）后門程序猜憎，是指開發(fā)設(shè)置的隱藏入口，可使用受限功能搔课。分為下面3種類型：
·開發(fā)階段作為Debug調(diào)用的后門程序
·開發(fā)者為了自身利益植入的后門程序
·攻擊者通過某種方法設(shè)置的后門程序

RESTful API接口規(guī)范

GET：獲取資源

• 安全且冪等
• 讀取服務(wù)器內(nèi)容時使用
• 變更時獲取表示（緩存）
• 沒有請求體

POST：創(chuàng)建或更新資源

• 不安全且不冪等
• 使用服務(wù)端管理的（自動產(chǎn)生）的實(shí)例號創(chuàng)建資源
• 創(chuàng)建子資源
• 部分更新資源
• 如果沒有被修改胰柑，則不更新資源（樂觀鎖）
• 有請求體

PUT：創(chuàng)建或更新資源

• 不安全但冪等
• 用客戶端管理的實(shí)例號創(chuàng)建一個資源
• 通過替換的方式更新資源
• 如果未被修改，則更新資源（樂觀鎖）

DELETE：刪除資源

• 不安全但冪等
• 刪除資源

HEAD：獲取資源的元數(shù)據(jù)

• 安全且冪等
• 遞交獲取資源的元數(shù)據(jù)

OPTIONS：獲取信息

• 安全且冪等
• 獲取信息辣辫，關(guān)于資源的哪些屬性是客戶端可以改變的旦事。

PATCH：局部更新資源

• 不安全，可以是不冪等的
• 局部更新資源
• 與PUT區(qū)別：只更新少部分內(nèi)容急灭；可能根據(jù)原數(shù)據(jù)進(jìn)行變化（比如基本工資加200元）姐浮，這時就不冪等了。

POST和PUT的區(qū)別

• 在更新資源的操作上葬馋，POST 和 PUT 基本相同卖鲤。

• 在創(chuàng)建資源時，PUT可以指定資源路徑畴嘶，POST無法指定資源路徑蛋逾。

  因而，PUT是冪等的操作窗悯，即重復(fù)操作不會產(chǎn)生變化区匣，10次PUT 的創(chuàng)建請求與1次PUT 的創(chuàng)建請求相同，只會創(chuàng)建一個資源蒋院，其實(shí)后面9次的請求只是對已創(chuàng)建資源的更新亏钩，且更新內(nèi)容與原內(nèi)容相同莲绰，所以不會產(chǎn)生變化。

  POST 的重復(fù)操作截然不同姑丑，10次POST請求將會創(chuàng)建10個資源蛤签。