第八章 確認訪問用戶身份的認證
1.http使用的認證方式
basic認證：basic認證采用base64編碼，但不是加密處理钾菊。安全性低。
digest認證：使用質(zhì)詢/相應的方式偎肃，但不會像basic認證那樣直接發(fā)送明文密碼煞烫。
所謂質(zhì)詢響應方式是指，一開始一方會先發(fā)送認證要求給另一方累颂，接著使用從另一方那接收到的質(zhì)詢碼計算生成響應碼滞详。最后將響應碼返回給對方進行認證的方式。
因為發(fā)送給對方的只是響應摘要及由質(zhì)詢碼產(chǎn)生的計算結(jié)果紊馏，所以比起B(yǎng)ASIC認證料饥，密碼泄露的可能性就降低了。
客戶端——1.發(fā)送臨時的質(zhì)詢碼（隨機數(shù)朱监，nonce）以及告知需要認證的狀態(tài)碼401——2.發(fā)送摘要以及由質(zhì)詢碼計算出的響應碼（response）——3.認證成功返回狀態(tài)碼200岸啡，失敗則再次發(fā)送狀態(tài)碼401
ssl客戶端認證：
多數(shù)情況下，ssl客戶端認證不會僅依靠證書完成認證赫编，一般會和基于表單認證（稍后講解）組合形成一種雙因素認證（Two-factorauthentication）來使用巡蘸。
。所謂雙因素認證就是指擂送，認證過程中不僅需要密碼這一個因素悦荒，還需要申請認證者提供其他持有信息，從而作為另一個因素嘹吨，與其組合使用的認證方式搬味。
基于表單認證：
基于表單認證本身是通過服務器端的Web應用，將客戶端發(fā)送過來的用戶ID和密碼與之前登錄過的信息做匹配來進行認證的。
步驟1：
客戶端把用戶ID
和密碼等登錄信息放入報文的實體部分碰纬，通常是以POST方法把請求發(fā)送給服務器萍聊。而這時，會使用HTTPS通信來進行HTML表單畫面的顯示和用戶輸入數(shù)據(jù)的發(fā)送悦析。
步驟2：
服務器會發(fā)放用以識別用戶的Session ID寿桨。通過驗證從客戶端發(fā)送過來的登錄信息進行身份認證，然后把用戶的認證狀態(tài)Session ID綁定后記錄在服務器端她按。
向客戶端返回響應時，會在首部字段Set-Cookie內(nèi)寫入SessionID炕柔。
步驟3：
客戶端接收到從服務器端發(fā)來的Session ID后酌泰，會將其作為Cookie保存在本地。下次向服務器發(fā)送請求時匕累，瀏覽器會自動發(fā)Cookie
陵刹，所以Session ID也隨之發(fā)送到服務器。服務器端可通過驗證接收到的Session ID識別用戶和其認證狀態(tài)欢嘿。
第九章基于http功能追加協(xié)議
1.Google在2010年發(fā)布了SPDY（取自SPeeDY衰琐，發(fā)音同speedy），其開發(fā)目標只在解決http的性能瓶頸炼蹦，縮短web頁面的加載時間（50%）羡宙。
2.ajax是一種有效利用JavaScript和dom（document object model文檔對象模型）的操作，以達到局部web頁面替換加載的異步通信手段掐隐。
而利用Ajax實時地從服務器獲取內(nèi)容狗热，有可能會導致大量請求產(chǎn)生。另外虑省，Ajax仍未解決HTTP協(xié)議本身存在的問題匿刮。
comet的解決方法
一旦服務器端有內(nèi)容更新了，Comet不會讓請求等待探颈，而是直接給客戶端返回響應熟丸。這是一種通過延遲應答，模擬實現(xiàn)服務器端向客戶端推送（Server Push）的功能伪节。
通常光羞，服務器端接收到請求，在處理完畢后就會立即返回響應怀大，但為了實現(xiàn)推送功能狞山，Comet會先將響應置于掛起狀態(tài)，當服務器端有內(nèi)容更新時叉寂，再返回該響應萍启。因此，服務器端一旦有更新，就可以立即反饋給客戶端勘纯。
內(nèi)容上雖然可以做到實時更新局服，但為了保留響應，一次連接的持續(xù)時間也變長了驳遵。期間淫奔，為了維持連接會消耗更多的資源。另外堤结，Comet也仍未解決HTTP協(xié)議本身存在的問題唆迁。
3.spdy的設(shè)計與功能
SPDY沒有完全改寫HTTP協(xié)議竞穷，而是在TCP/IP的應用層與運輸層之SPDY間通過新加會話層的形式運作鼠哥。同時，考慮到安全性問題，規(guī)定通信中使用SSL于颖。
使用spdy后谴垫，http協(xié)議額外獲得以下功能乳怎。
多路復用流：
通過單一tcp連接恕出，可以無限制處理多個http
請求金蜀。
賦予請求優(yōu)先級：
SPDY不僅可以無限制地并發(fā)處理請求尝胆，還可以給請求逐個分配優(yōu)先級順序。這樣主要是為了在發(fā)送多個請求時贪染，解決因帶寬低而導致響應變慢的問題。
壓縮http首部：
壓縮HTTP請求和響應的首部寺渗。這樣一來汁果，通信產(chǎn)生的數(shù)據(jù)包數(shù)量和發(fā)送的字節(jié)數(shù)就更少了。
推送功能：
支持服務器主動向客戶端推送數(shù)據(jù)的功能棘利。這樣，服務器可直接發(fā)送數(shù)據(jù)，而不必等待客戶端的請求系冗。
服務器提示功能：
服務器可以主動提示客戶端請求所需的資源。由于在客戶端發(fā)現(xiàn)資源之前就可以獲知資源的存在，因此在資源已緩存等情況下拄养，可以避免發(fā)送不必要的請求寻馏。
4.websocket協(xié)議
一旦Web服務器與客戶端之間建立起WebSocket協(xié)議的通信連接，之后所有的通信都依靠這個專用協(xié)議進行。通信過程中可互相發(fā)送JSON唧垦、XML振亮、HTML或圖片等任意格式的數(shù)據(jù)。
websocket協(xié)議主要特點：
推送功能
支持由服務器向客戶端推送數(shù)據(jù)的推送功能鞭莽。這樣澎怒，服務器可直接發(fā)送數(shù)據(jù)褒搔，而不必等待客戶端的請求乖酬。
減少通信量：
只要建立起WebSocket連接，就希望一直保持連接狀態(tài)审洞。和HTTP相比芒澜，不但每次連接時的總開銷減少仰剿，而且由于WebSocket的首部信息很小，通信量也相應減少了南吮。
![ZAR}]APRKJZNN{JXZ00YS$4.png](https://upload-images.jianshu.io/upload_images/9284422-4e5f3bcc1a484314.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
