簡(jiǎn)介

• HTTP全稱是Hyper Text Transfer Protocol胳泉，翻譯過(guò)來(lái)叫超文本傳輸協(xié)議而昨，看起來(lái)很高端的名字舶担，實(shí)際上他就是字面意思，就比如你想知道“HTTP協(xié)議是什么”箕昭，服務(wù)器上呢有個(gè)超文本誉简，就姑且當(dāng)他是個(gè)記事本里面記錄著“HTTP協(xié)議是什么”的答案，你想要盟广，那么服務(wù)器就和你約定好了用“順豐快遞傳”，所以這就是傳輸超文本的協(xié)議瓮钥。
• 它是一個(gè)屬于應(yīng)用層的協(xié)議筋量，什么叫應(yīng)用層烹吵，簡(jiǎn)單說(shuō)就是和應(yīng)用進(jìn)程交互 的層，想想應(yīng)用里面有什么好交互的桨武，當(dāng)然是數(shù)據(jù)了肋拔，也就是說(shuō)這一層解決的是如何包裝數(shù)據(jù)的，還是很像快遞呀酸。

特點(diǎn)

1. C/S模式凉蜂，快遞員服務(wù)于客戶。
2. 簡(jiǎn)單：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)性誉，只需傳送請(qǐng)求方法和路徑窿吩。請(qǐng)求方法常用的有GET、HEAD错览、POST纫雁，每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。就相當(dāng)于告訴快遞員你的地址(路徑)和你要的運(yùn)輸?shù)姆绞?請(qǐng)求方法)倾哺，比如我家住安卓小區(qū)你給我空運(yùn)過(guò)來(lái)轧邪。。羞海。
3. 快速：由于HTTP協(xié)議簡(jiǎn)單忌愚，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快却邓。
4. 靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象硕糊。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。
5. 無(wú)連接：無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求申尤。服務(wù)器處理完客戶的請(qǐng)求癌幕，并收到客戶的應(yīng)答后，即斷開連接昧穿。采用這種方式可以節(jié)省傳輸時(shí)間勺远。但是這種方式在請(qǐng)求頻繁的條件下，將會(huì)在建立和斷開連接上花費(fèi)大部分時(shí)間时鸵，所以在1.0胶逢、1.1持久連接變?yōu)榱四J(rèn)連接方式，有興趣的可以自己查一下這個(gè)方式饰潜。
6. 無(wú)狀態(tài)：HTTP協(xié)議是無(wú)狀態(tài)協(xié)議初坠，簡(jiǎn)單說(shuō)就是健忘、沒(méi)腦子彭雾。打電話給常年在小區(qū)送快遞的快遞小哥：“哥碟刺，還送老地方”，小哥：“你誰(shuí)呀不認(rèn)識(shí)薯酝！”半沽，掛了爽柒。。者填。所以無(wú)狀態(tài)意味著如果后續(xù)處理需要前面的信息浩村，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大占哟。另一方面心墅，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。

URL 格式

http://host[":"port][abs_path]

如：http://blog.csdn.net:80/qijinglai
http表示要通過(guò)HTTP協(xié)議來(lái)定位網(wǎng)絡(luò)資源榨乎；host表示合法的Internet主機(jī)域名或者IP地址怎燥；port指定一個(gè)端口號(hào)，為空則使用默認(rèn)端口80谬哀；abs_path指定請(qǐng)求資源的URI（Web上任意的可用資源）刺覆。

Http報(bào)文

http報(bào)文可以分為請(qǐng)求報(bào)文和響應(yīng)報(bào)文，格式大同小異史煎。主要分為三個(gè)部分：

1. 起始行
2. 首部
3. 主體

請(qǐng)求報(bào)文格式：

<method> <request-url> <version>
<headers>

<entity-body>

響應(yīng)報(bào)文格式：

<version> <status> <reason-phrase>
<headers>

<entity-body>

從請(qǐng)求報(bào)文格式和響應(yīng)報(bào)文格式可以看出谦屑，兩者主要在起始行上有差異。這里稍微解釋一下各個(gè)標(biāo)簽：

<method> 指請(qǐng)求方法篇梭，常用的主要是Get氢橙、 Post、Head 還有其他一些我們這里就不說(shuō)了恬偷，有興趣的可以自己查閱一下

<version> 指協(xié)議版本悍手，現(xiàn)在通常都是Http/1.1了

<request-url> 請(qǐng)求地址

<status> 指響應(yīng)狀態(tài)碼， 我們熟悉的200袍患、404等等

<reason-phrase> 原因短語(yǔ)坦康，200 OK 、404 Not Found 這種后面的描述就是原因短語(yǔ)诡延，通常不必太關(guān)注滞欠。

method

HTTP請(qǐng)求方法有8種

1. GET：請(qǐng)求獲取Request-URI所標(biāo)識(shí)的資源
2. POST：在Request-URI所標(biāo)識(shí)的資源后附加新的數(shù)據(jù)
3. HEAD：請(qǐng)求獲取由Request-URI所標(biāo)識(shí)的資源的響應(yīng)消息報(bào)頭
4. PUT： 請(qǐng)求服務(wù)器存儲(chǔ)一個(gè)資源，并用Request-URI作為其標(biāo)識(shí)
5. DELETE ：請(qǐng)求服務(wù)器刪除Request-URI所標(biāo)識(shí)的資源
6. TRACE ： 請(qǐng)求服務(wù)器回送收到的請(qǐng)求信息肆良，主要用于測(cè)試或診斷
7. CONNECT： HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器筛璧。
8. OPTIONS ：請(qǐng)求查詢服務(wù)器的性能，或者查詢與資源相關(guān)的選項(xiàng)和需求

GET和POST的區(qū)別

兩個(gè)方法之間在傳輸形式上有一些區(qū)別惹恃，通過(guò)Get方法發(fā)起請(qǐng)求時(shí)夭谤，會(huì)將請(qǐng)求參數(shù)拼接在request-url尾部，格式是url?param1=xxx&param2=xxx&[…]巫糙。
我們需要知道朗儒，這樣傳輸參數(shù)會(huì)使得參數(shù)都暴露在地址欄中。并且由于url是ASCII編碼的，所以參數(shù)中如果有Unicode編碼的字符采蚀，例如漢字疲牵，都會(huì)編碼之后傳輸。另外值得注意的是榆鼠，雖然http協(xié)議并沒(méi)有對(duì)url長(zhǎng)度做限制，但是一些瀏覽器和服務(wù)器可能會(huì)有限制亥鸠，所以通過(guò)GET方法發(fā)起的請(qǐng)求參數(shù)不能夠太長(zhǎng)妆够。而通過(guò)POST方法發(fā)起的請(qǐng)求是將參數(shù)放在請(qǐng)求體中的，所以不會(huì)有GET參數(shù)的這些問(wèn)題负蚊。
另外一點(diǎn)差別就是方法本身的語(yǔ)義上的神妹。GET方法通常是指從服務(wù)器獲取某個(gè)URL資源，其行為可以看作是一個(gè)讀操作家妆，對(duì)同一個(gè)URL進(jìn)行多次GET并不會(huì)對(duì)服務(wù)器產(chǎn)生什么影響鸵荠。而POST方法通常是對(duì)某個(gè)URL進(jìn)行添加、修改伤极，例如一個(gè)表單提交蛹找，通常會(huì)往服務(wù)器插入一條記錄。多次POST請(qǐng)求可能導(dǎo)致服務(wù)器的數(shù)據(jù)庫(kù)中添加了多條記錄哨坪。所以從語(yǔ)義上來(lái)講庸疾，兩者也是不能混為一談的。

狀態(tài)碼

狀態(tài)代碼有三位數(shù)字組成当编，第一個(gè)數(shù)字定義了響應(yīng)的類別届慈，且有五種可能取值：

• 100~199：指示信息，表示請(qǐng)求已接收忿偷，繼續(xù)處理
• 200~299：請(qǐng)求成功金顿，表示請(qǐng)求已被成功接收、理解鲤桥、接受
• 300~399：重定向揍拆，要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作
• 400~499：客戶端錯(cuò)誤，請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無(wú)法實(shí)現(xiàn)
• 500~599：服務(wù)器端錯(cuò)誤芜壁，服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求

常見的狀態(tài)碼如下：

• 200 OK：客戶端請(qǐng)求成功
• 400 Bad Request：客戶端請(qǐng)求有語(yǔ)法錯(cuò)誤礁凡，不能被服務(wù)器所理解
• 401 Unauthorized：請(qǐng)求未經(jīng)授權(quán)，這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用
• 403 Forbidden：服務(wù)器收到請(qǐng)求慧妄，但是拒絕提供服務(wù)
• 500 Internal Server Error：服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤
• 503 Server Unavailable：服務(wù)器當(dāng)前不能處理客戶端的請(qǐng)求顷牌，一段時(shí)間后可能恢復(fù)正常

header

在請(qǐng)求報(bào)文和響應(yīng)報(bào)文中都可以攜帶一些信息，通過(guò)與其他部分配合塞淹，能夠?qū)崿F(xiàn)各種強(qiáng)大的功能窟蓝。這些信息位于起始行之下與請(qǐng)求實(shí)體之間，以鍵值對(duì)的形式饱普，稱之為首部运挫。每條首部以回車換行符結(jié)尾状共，最后一個(gè)首部額外多一個(gè)換行，與實(shí)體分隔開谁帕。

• 通用報(bào)頭峡继，既可以出現(xiàn)在請(qǐng)求報(bào)頭，也可以出現(xiàn)在響應(yīng)報(bào)頭中
  Date：表示消息產(chǎn)生的日期和時(shí)間
  Connection：允許發(fā)送指定連接的選項(xiàng)匈挖，例如指定連接是連續(xù)的碾牌，或者指定“close”選項(xiàng)，通知服務(wù)器儡循，在響應(yīng)完成后舶吗，關(guān)閉連接
  Cache-Control：用于指定緩存指令，緩存指令是單向的（響應(yīng)中出現(xiàn)的緩存指令在請(qǐng)求中未必會(huì)出現(xiàn)）择膝，且是獨(dú)立的（一個(gè)消息的緩存指令不會(huì)影響另一個(gè)消息處理的緩存機(jī)制）

• 請(qǐng)求報(bào)頭誓琼，用于服務(wù)器傳遞自身信息的響應(yīng)，常見的響應(yīng)報(bào)頭：
  Location：用于重定向接受者到一個(gè)新的位置肴捉，常用在更換域名的時(shí)候
  Server：包含可服務(wù)器用來(lái)處理請(qǐng)求的系統(tǒng)信息腹侣，與User-Agent請(qǐng)求報(bào)頭是相對(duì)應(yīng)的

• 實(shí)體報(bào)頭，實(shí)體報(bào)頭用來(lái)定于被傳送資源的信息每庆，既可以用于請(qǐng)求也可用于響應(yīng)筐带。請(qǐng)求和響應(yīng)消息都可以傳送一個(gè)實(shí)體，常見的實(shí)體報(bào)頭為：
  Content-Type：發(fā)送給接收者的實(shí)體正文的媒體類型
  Content-Lenght：實(shí)體正文的長(zhǎng)度
  Content-Language：描述資源所用的自然語(yǔ)言缤灵，沒(méi)有設(shè)置則該選項(xiàng)則認(rèn)為實(shí)體內(nèi)容將提供給所有的語(yǔ)言閱讀
  Content-Encoding：實(shí)體報(bào)頭被用作媒體類型的修飾符伦籍，它的值指示了已經(jīng)被應(yīng)用到實(shí)體正文的附加內(nèi)容的編碼，因而要獲得Content-Type報(bào)頭域中所引用的媒體類型腮出，必須采用相應(yīng)的解碼機(jī)制帖鸦。
  Last-Modified：實(shí)體報(bào)頭用于指示資源的最后修改日期和時(shí)間
  Expires：實(shí)體報(bào)頭給出響應(yīng)過(guò)期的日期和時(shí)間

實(shí)體

請(qǐng)求發(fā)送的資源，或是響應(yīng)返回的資源胚嘲。

Http緩存

當(dāng)我們發(fā)起一個(gè)http請(qǐng)求后作儿，服務(wù)器返回所請(qǐng)求的資源，這時(shí)我們可以將該資源的副本存儲(chǔ)在本地馋劈，這樣當(dāng)再次對(duì)該url資源發(fā)起請(qǐng)求時(shí)攻锰，我們能快速的從本地存儲(chǔ)設(shè)備中獲取到該url資源，這就是所謂的緩存妓雾。緩存既可以節(jié)約不必要的網(wǎng)絡(luò)帶寬娶吞，又能迅速對(duì)http請(qǐng)求做出響應(yīng)。

先擺出幾個(gè)概念：
新鮮度檢測(cè)
再驗(yàn)證
再驗(yàn)證命中

我們知道械姻，有些url所對(duì)應(yīng)的資源并不是一成不變的妒蛇，服務(wù)器中該url的資源可能在一定時(shí)間之后會(huì)被修改。這時(shí)本地緩存中的資源將與服務(wù)器一側(cè)的資源有差異。

既然在一定時(shí)間之后可能資源會(huì)改變绣夺，那么在某個(gè)時(shí)間之前我們可以認(rèn)為這個(gè)資源沒(méi)有改變吏奸，從而放心大膽的使用緩存資源，當(dāng)請(qǐng)求時(shí)間超過(guò)來(lái)該時(shí)間陶耍，我們認(rèn)為這個(gè)緩存資源可能不再與服務(wù)器端一致了奋蔚。所以當(dāng)我們發(fā)起一個(gè)請(qǐng)求時(shí)，我們需要先對(duì)緩存的資源進(jìn)行判斷物臂，看看究竟我們是否可以直接使用該緩存資源旺拉，這個(gè)就叫做新鮮度檢測(cè)。即每個(gè)資源就像一個(gè)食品一樣棵磷，擁有一個(gè)過(guò)期時(shí)間，我們吃之前需要先看看有沒(méi)有過(guò)期晋涣。

如果發(fā)現(xiàn)該緩存資源已經(jīng)超過(guò)了一定的時(shí)間仪媒，我們?cè)俅伟l(fā)起請(qǐng)求時(shí)不會(huì)直接將緩存資源返回，而是先去服務(wù)器查看該資源是否已經(jīng)改變谢鹊，這個(gè)就叫做再驗(yàn)證算吩。如果服務(wù)器發(fā)現(xiàn)對(duì)應(yīng)的url資源并沒(méi)有發(fā)生變化，則會(huì)返回304 Not Modified佃扼，并且不再返回對(duì)應(yīng)的實(shí)體偎巢。這稱之為再驗(yàn)證命中。相反如果再驗(yàn)證未命中兼耀，則返回200 OK压昼，并將改變后的url資源返回，此時(shí)緩存可以更新以待之后請(qǐng)求瘤运。

我們看看具體的實(shí)現(xiàn)方式：

新鮮度檢測(cè)
我們需要通過(guò)檢測(cè)資源是否超過(guò)一定的時(shí)間窍霞，來(lái)判斷緩存資源是否新鮮可用。那么這個(gè)一定的時(shí)間怎么決定呢拯坟？其實(shí)是由服務(wù)器通過(guò)在響應(yīng)報(bào)文中增加Cache-Control:max-age但金，或是Expire這兩個(gè)首部來(lái)實(shí)現(xiàn)的。值得注意的是Cache-Control是http1.1的協(xié)議規(guī)范郁季，通常是接相對(duì)的時(shí)間冷溃，即多少秒以后，需要結(jié)合last-modified這個(gè)首部計(jì)算出絕對(duì)時(shí)間梦裂。而Expire是http1.0的規(guī)范似枕，后面接一個(gè)絕對(duì)時(shí)間。
再驗(yàn)證
如果通過(guò)新鮮度檢測(cè)發(fā)現(xiàn)需要請(qǐng)求服務(wù)器進(jìn)行再驗(yàn)證塞琼，那么我們至少需要告訴服務(wù)器菠净，我們已經(jīng)緩存了一個(gè)什么樣的資源了，然后服務(wù)器來(lái)判斷這個(gè)緩存資源到底是不是與當(dāng)前的資源一致。邏輯是這樣沒(méi)錯(cuò)毅往。那怎么告訴服務(wù)器我當(dāng)前已經(jīng)有一個(gè)備用的緩存資源了呢牵咙？我們可以采用一種稱之為條件請(qǐng)求的方式實(shí)現(xiàn)再驗(yàn)證。
Http定義了5個(gè)首部用于條件請(qǐng)求:
If-Modified-Since
If-None-Match
If-Unmodified-Since
If-Range
If-Match

If-Modified-Since 可以結(jié)合Last-Modified這個(gè)服務(wù)器返回的響應(yīng)首部使用攀唯，當(dāng)我們發(fā)起條件請(qǐng)求時(shí)洁桌，將Last-Modified首部的值作為If-Modified-Since首部的值傳遞到服務(wù)器，意思是查詢服務(wù)器的資源自從我們上一次緩存之后是否有修改侯嘀。

If-None-Match 需要結(jié)合另一個(gè)Etag的服務(wù)器返回的響應(yīng)首部使用另凌。Etag首部實(shí)際上可以認(rèn)為是服務(wù)器對(duì)文檔資源定義的一個(gè)版本號(hào)。有時(shí)候一個(gè)文檔被修改了戒幔，可能所做的修改極為微小吠谢，并不需要所有的緩存都重新下載數(shù)據(jù)∈ィ或者說(shuō)某一個(gè)文檔的修改周期極為頻繁工坊，以至于以秒為時(shí)間粒度的判斷已經(jīng)無(wú)法滿足需求。這個(gè)時(shí)候可能就需要Etag這個(gè)首部來(lái)表明這個(gè)文檔的版號(hào)了敢订。發(fā)起條件請(qǐng)求時(shí)可將緩存時(shí)保存下來(lái)的Etag的值作為If-None-Match首部的值發(fā)送至服務(wù)器王污，如果服務(wù)器的資源的Etag與當(dāng)前條件請(qǐng)求的Etag一致，表明這次再驗(yàn)證命中楚午。

OAuth

OAuth是一個(gè)用于授權(quán)第三方獲取相應(yīng)資源的協(xié)議昭齐。與以往的授權(quán)方式不同的是，OAuth的授權(quán)能避免用戶暴露自己的用戶密碼給第三方矾柜，從而更加的安全阱驾。OAuth協(xié)議通過(guò)設(shè)置一個(gè)授權(quán)層，以區(qū)分用戶和第三方應(yīng)用把沼。用戶本身可以通過(guò)用戶密碼登陸服務(wù)提供商啊易，獲取到賬戶所有的資源。而第三方應(yīng)用只能通過(guò)向用戶請(qǐng)求授權(quán)饮睬，獲取到一個(gè)Access Token租谈，用以登陸授權(quán)層，從而在指定時(shí)間內(nèi)獲取到用戶授權(quán)訪問(wèn)的部分資源捆愁。

OAuth定義的幾個(gè)角色：

 +--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+

從上圖可以看出昼丑，一個(gè)OAuth授權(quán)的流程主要可以分為6步：

1. 客戶端向用戶申請(qǐng)授權(quán)呻逆。
2. 用戶同意授權(quán)。
3. 客戶端通過(guò)獲取的授權(quán)菩帝，向認(rèn)證服務(wù)器申請(qǐng)Access Token咖城。
4. 認(rèn)證服務(wù)器通過(guò)授權(quán)認(rèn)證后茬腿，下發(fā)Access Token。
5. 客戶端通過(guò)獲取的到Access Token向資源服務(wù)器發(fā)起請(qǐng)求宜雀。
   6.資源服務(wù)器核對(duì)Access Token后下發(fā)請(qǐng)求資源切平。

Https

簡(jiǎn)單的說(shuō) Http + 加密 + 認(rèn)證 + 完整性保護(hù) = Https

傳統(tǒng)的Http協(xié)議是一種應(yīng)用層的傳輸協(xié)議，Http直接與TCP協(xié)議通信辐董。其本身存在一些缺點(diǎn)：

1. Http協(xié)議使用明文傳輸悴品，容易遭到竊聽。
2. Http對(duì)于通信雙方都沒(méi)有進(jìn)行身份驗(yàn)證简烘，通信的雙方無(wú)法確認(rèn)對(duì)方是否是偽裝的客戶端或者服務(wù)端苔严。
3. Http對(duì)于傳輸內(nèi)容的完整性沒(méi)有確認(rèn)的辦法，往往容易在傳輸過(guò)程中被劫持篡改孤澎。

因此届氢，在一些需要保證安全性的場(chǎng)景下，比如涉及到銀行賬戶的請(qǐng)求時(shí)覆旭，Http無(wú)法抵御這些攻擊悼沈。
Https則可以通過(guò)增加的SSL\TLS，支持對(duì)于通信內(nèi)容的加密姐扮，以及對(duì)通信雙方的身份進(jìn)行驗(yàn)證。