繼續(xù)學(xué)習(xí)圖解HTTP。
http協(xié)議是用于客戶端和服務(wù)端之間的通信
- 請求訪問文本或圖片等資源的一端統(tǒng)稱為客戶端。
- 提供資源響應(yīng)的一端稱之為服務(wù)端。
在兩臺(tái)計(jì)算機(jī)之間使用http通訊時(shí)，必然有一端是客戶端，有一端是服務(wù)端。
有時(shí)候兩臺(tái)計(jì)算機(jī)作為客戶端和服務(wù)端的角色可能會(huì)互換，但是在一次訪問中，客戶端和服務(wù)端是固定的。
通過請求和響應(yīng)的交換達(dá)成通信
請求必定從客戶端發(fā)出，而服務(wù)端回復(fù)反應(yīng)。
書中介紹了一些http的組成，比如請求報(bào)文頭，協(xié)議版本之類的，但是其實(shí)多數(shù)時(shí)候我個(gè)人使用http都是直接拿來用的，所以這塊接觸的很少。
HTTP是不保存狀態(tài)的協(xié)議
這個(gè)其實(shí)很多地方都有講到，http的三大特性就包括無狀態(tài)。
簡而言之協(xié)議自身不對請求和響應(yīng)的通信狀態(tài)進(jìn)行保存。也就是不持久化。
比如每當(dāng)有新的請求就會(huì)對應(yīng)有新的響應(yīng)，協(xié)議本身不保存之前的請求和響應(yīng)。這樣做是為了簡化http協(xié)議，可以更快的處理大量事務(wù)。
但是有的時(shí)候我們又必須需要保存一些東西，比如登錄淘寶以后，不管點(diǎn)到任何頁面都要保存登錄狀態(tài)，任何請求都要服務(wù)端知道具體是哪個(gè)用戶發(fā)送的請求。為了實(shí)現(xiàn)這個(gè)功能，http1.1引入了cookie功能。
請求URI定位資源
這里要提一下上一篇中的小知識(shí)點(diǎn)：URL是一種特殊的URI。
然后繼續(xù)說，URI是統(tǒng)一資源標(biāo)識(shí)符，所以通過完整的URI是可以定位互聯(lián)網(wǎng)上的資源的。
當(dāng)客戶端請求資源時(shí)，要寫明URI，指明URI的方式很多：
以上兩種是一樣的效果。
告知服務(wù)器意圖的 HTTP 方法
get：獲取資源。
這是一種常用的請求方式，但是這個(gè)因?yàn)槟軅鬟f的數(shù)據(jù)很小，所以一般用來獲取資源。
post：傳輸實(shí)體主體
與fet相比，post可傳輸?shù)臄?shù)據(jù)更多，而且更加安全。是一個(gè)平時(shí)較為常用的方法。（可傳輸文件等）
put：傳輸文件
在請求報(bào)文的主題中包含文件內(nèi)容，直接上傳到指定url。
這個(gè)方法自身不帶驗(yàn)證機(jī)制，所以有一些安全問題，所以一般的web網(wǎng)站不適用這個(gè)方法。
如果用web驗(yàn)證機(jī)制，或者rest標(biāo)準(zhǔn)，才會(huì)開放使用這種方法。
head：獲取報(bào)文首部
這個(gè)與get類似，但是不返回報(bào)文主體部分，只能確認(rèn)url是否有效及資源更新的時(shí)間等。
delete：刪除文件。
這個(gè)同put正好相反，但是機(jī)制差不多，都是要有web驗(yàn)證機(jī)制或者rest風(fēng)格開發(fā)才會(huì)使用。
options：詢問支持的方法
用來查詢針對請求 URI 指定的資源支持的方法。大多數(shù)時(shí)候我們會(huì)規(guī)定某接口支持什么方法，比如：
如圖，第一個(gè)接口只支持get，第二個(gè)只支持post，第三個(gè)則都可以。options就是可以詢問一個(gè)接口支持什么方法。
剩下還有幾樣我都沒見過的，只能說很不常見，所以這里就不一一列舉了。
使用方法下達(dá)命令
向請求URL發(fā)送請求報(bào)文時(shí)，采用不同方法被稱為方法的命令。
HTTP1.0和HTTP1.1是不同的，有一些細(xì)微的差別：
持久連接節(jié)省通信量
在以前，一次HTTP協(xié)議就要斷開一個(gè)TCP鏈接。當(dāng)年2G傳輸，一次資源很少，這樣也就可以了。但是現(xiàn)在隨著HTTP的普及，一個(gè)HTML中可能包含大量圖片。在發(fā)送請求訪問 HTML 頁面資源的同時(shí)，也會(huì)請求該 HTML 頁面里包含的其他資源。因此，每次的請求都會(huì)造成無謂的 TCP 連接建立和斷開，增加通信量的開銷。
持久連接
持久連接也叫長連接。持久連接的特點(diǎn)是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。
在 HTTP/1.1 中，所有的連接默認(rèn)都是持久連接，但在 HTTP/1.0 內(nèi)并未標(biāo)準(zhǔn)化。
注意一點(diǎn)：持久連接只是保持TCP的連接。
管線化
持久連接似的多數(shù)請求管線化成為可能。從前發(fā)送請求要能收到反應(yīng)后才能再次發(fā)送請求，而現(xiàn)在不用等待響應(yīng)就可以直接再次發(fā)送請求。
比如，當(dāng)請求一個(gè)包含 10 張圖片的 HTML Web 頁面，與挨個(gè)連接相比，用持久連接可以讓請求更快結(jié)束。而管線化技術(shù)則比持久連接還要快。請求數(shù)越多，時(shí)間差就越明顯。
使用cookie的狀態(tài)管理
上面就提到了，HTTP是無狀態(tài)協(xié)議，他不對任何請求和響應(yīng)做保存，所以想要實(shí)現(xiàn)登錄認(rèn)證，只能人為的來處理。
其實(shí)HTTP的無狀態(tài)，由于不必保存狀態(tài)，自然可減少服務(wù)器的 CPU 及內(nèi)存資源的消耗。也正是因?yàn)檫@點(diǎn)才會(huì)被廣泛使用。
保留無狀態(tài)協(xié)議這個(gè)特征的同時(shí)又要解決類似的矛盾問題，于是引入了 Cookie 技術(shù)。Cookie 技術(shù)通過在請求和響應(yīng)報(bào)文中寫入 Cookie 信息來控制客戶端的狀態(tài)。
Cookie 會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當(dāng)下次客戶端再往該服務(wù)器發(fā)送請求時(shí)，客戶端會(huì)自動(dòng)在請求報(bào)文中加入 Cookie 值后發(fā)送出去。
服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的 Cookie 后，會(huì)去檢查究竟是從哪一個(gè)客戶端發(fā)來的連接請求，然后對比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息。
其實(shí)簡而言之，就是在第一次返回響應(yīng)時(shí)人為的在某地方放置一個(gè)辨別碼，由http自動(dòng)獲取這個(gè)辨別碼然后放到請求報(bào)文中。下次服務(wù)器就知道是誰訪問的了。
原書中這一塊的圖很可愛，分享給大家：
