第八章 確認(rèn)訪問用戶身份的認(rèn)證
1.http使用的認(rèn)證方式
basic認(rèn)證：basic認(rèn)證采用base64編碼，但不是加密處理。安全性低。
digest認(rèn)證：使用質(zhì)詢/相應(yīng)的方式，但不會(huì)像basic認(rèn)證那樣直接發(fā)送明文密碼。
所謂質(zhì)詢響應(yīng)方式是指，一開始一方會(huì)先發(fā)送認(rèn)證要求給另一方，接著使用從另一方那接收到的質(zhì)詢碼計(jì)算生成響應(yīng)碼。最后將響應(yīng)碼返回給對(duì)方進(jìn)行認(rèn)證的方式。
因?yàn)榘l(fā)送給對(duì)方的只是響應(yīng)摘要及由質(zhì)詢碼產(chǎn)生的計(jì)算結(jié)果，所以比起B(yǎng)ASIC認(rèn)證，密碼泄露的可能性就降低了。
客戶端——1.發(fā)送臨時(shí)的質(zhì)詢碼（隨機(jī)數(shù)，nonce）以及告知需要認(rèn)證的狀態(tài)碼401——2.發(fā)送摘要以及由質(zhì)詢碼計(jì)算出的響應(yīng)碼（response）——3.認(rèn)證成功返回狀態(tài)碼200，失敗則再次發(fā)送狀態(tài)碼401
ssl客戶端認(rèn)證：
多數(shù)情況下，ssl客戶端認(rèn)證不會(huì)僅依靠證書完成認(rèn)證，一般會(huì)和基于表單認(rèn)證（稍后講解）組合形成一種雙因素認(rèn)證（Two-factorauthentication）來使用。
。所謂雙因素認(rèn)證就是指，認(rèn)證過程中不僅需要密碼這一個(gè)因素，還需要申請(qǐng)認(rèn)證者提供其他持有信息，從而作為另一個(gè)因素，與其組合使用的認(rèn)證方式。
基于表單認(rèn)證：
基于表單認(rèn)證本身是通過服務(wù)器端的Web應(yīng)用，將客戶端發(fā)送過來的用戶ID和密碼與之前登錄過的信息做匹配來進(jìn)行認(rèn)證的。
步驟1：
客戶端把用戶ID
和密碼等登錄信息放入報(bào)文的實(shí)體部分，通常是以POST方法把請(qǐng)求發(fā)送給服務(wù)器。而這時(shí)，會(huì)使用HTTPS通信來進(jìn)行HTML表單畫面的顯示和用戶輸入數(shù)據(jù)的發(fā)送。
步驟2：
服務(wù)器會(huì)發(fā)放用以識(shí)別用戶的Session ID。通過驗(yàn)證從客戶端發(fā)送過來的登錄信息進(jìn)行身份認(rèn)證，然后把用戶的認(rèn)證狀態(tài)Session ID綁定后記錄在服務(wù)器端。
向客戶端返回響應(yīng)時(shí)，會(huì)在首部字段Set-Cookie內(nèi)寫入SessionID。
步驟3：
客戶端接收到從服務(wù)器端發(fā)來的Session ID后，會(huì)將其作為Cookie保存在本地。下次向服務(wù)器發(fā)送請(qǐng)求時(shí)，瀏覽器會(huì)自動(dòng)發(fā)Cookie
，所以Session ID也隨之發(fā)送到服務(wù)器。服務(wù)器端可通過驗(yàn)證接收到的Session ID識(shí)別用戶和其認(rèn)證狀態(tài)。
第九章基于http功能追加協(xié)議
1.Google在2010年發(fā)布了SPDY（取自SPeeDY，發(fā)音同speedy），其開發(fā)目標(biāo)只在解決http的性能瓶頸，縮短web頁面的加載時(shí)間（50%）。
2.ajax是一種有效利用JavaScript和dom（document object model文檔對(duì)象模型）的操作，以達(dá)到局部web頁面替換加載的異步通信手段。
而利用Ajax實(shí)時(shí)地從服務(wù)器獲取內(nèi)容，有可能會(huì)導(dǎo)致大量請(qǐng)求產(chǎn)生。另外，Ajax仍未解決HTTP協(xié)議本身存在的問題。
comet的解決方法
一旦服務(wù)器端有內(nèi)容更新了，Comet不會(huì)讓請(qǐng)求等待，而是直接給客戶端返回響應(yīng)。這是一種通過延遲應(yīng)答，模擬實(shí)現(xiàn)服務(wù)器端向客戶端推送（Server Push）的功能。
通常，服務(wù)器端接收到請(qǐng)求，在處理完畢后就會(huì)立即返回響應(yīng)，但為了實(shí)現(xiàn)推送功能，Comet會(huì)先將響應(yīng)置于掛起狀態(tài)，當(dāng)服務(wù)器端有內(nèi)容更新時(shí)，再返回該響應(yīng)。因此，服務(wù)器端一旦有更新，就可以立即反饋給客戶端。
內(nèi)容上雖然可以做到實(shí)時(shí)更新，但為了保留響應(yīng)，一次連接的持續(xù)時(shí)間也變長了。期間，為了維持連接會(huì)消耗更多的資源。另外，Comet也仍未解決HTTP協(xié)議本身存在的問題。
3.spdy的設(shè)計(jì)與功能
SPDY沒有完全改寫HTTP協(xié)議，而是在TCP/IP的應(yīng)用層與運(yùn)輸層之SPDY間通過新加會(huì)話層的形式運(yùn)作。同時(shí)，考慮到安全性問題，規(guī)定通信中使用SSL。
使用spdy后，http協(xié)議額外獲得以下功能。
多路復(fù)用流：
通過單一tcp連接，可以無限制處理多個(gè)http
請(qǐng)求。
賦予請(qǐng)求優(yōu)先級(jí)：
SPDY不僅可以無限制地并發(fā)處理請(qǐng)求，還可以給請(qǐng)求逐個(gè)分配優(yōu)先級(jí)順序。這樣主要是為了在發(fā)送多個(gè)請(qǐng)求時(shí)，解決因帶寬低而導(dǎo)致響應(yīng)變慢的問題。
壓縮http首部：
壓縮HTTP請(qǐng)求和響應(yīng)的首部。這樣一來，通信產(chǎn)生的數(shù)據(jù)包數(shù)量和發(fā)送的字節(jié)數(shù)就更少了。
推送功能：
支持服務(wù)器主動(dòng)向客戶端推送數(shù)據(jù)的功能。這樣，服務(wù)器可直接發(fā)送數(shù)據(jù)，而不必等待客戶端的請(qǐng)求。
服務(wù)器提示功能：
服務(wù)器可以主動(dòng)提示客戶端請(qǐng)求所需的資源。由于在客戶端發(fā)現(xiàn)資源之前就可以獲知資源的存在，因此在資源已緩存等情況下，可以避免發(fā)送不必要的請(qǐng)求。
4.websocket協(xié)議
一旦Web服務(wù)器與客戶端之間建立起WebSocket協(xié)議的通信連接，之后所有的通信都依靠這個(gè)專用協(xié)議進(jìn)行。通信過程中可互相發(fā)送JSON、XML、HTML或圖片等任意格式的數(shù)據(jù)。
websocket協(xié)議主要特點(diǎn)：
推送功能
支持由服務(wù)器向客戶端推送數(shù)據(jù)的推送功能。這樣，服務(wù)器可直接發(fā)送數(shù)據(jù)，而不必等待客戶端的請(qǐng)求。
減少通信量：
只要建立起WebSocket連接，就希望一直保持連接狀態(tài)。和HTTP相比，不但每次連接時(shí)的總開銷減少，而且由于WebSocket的首部信息很小，通信量也相應(yīng)減少了。
![ZAR}]APRKJZNN{JXZ00YS$4.png](https://upload-images.jianshu.io/upload_images/9284422-4e5f3bcc1a484314.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
