確保Web安全的HTTPS
HTTP存在三個比較明顯的缺點：
- 通信使用明文（不加密），內容可能會被竊聽。
- 不驗證通信方的身份，因此有可能遭遇僞裝。
- 無法證明報文的完整性，所以可能已遭篡改。
儘管HTTP協議中沒有加密機制，但可以通過和SSL或TLS的組合使用加密HTTP的通信內容，組合在一起通常被稱爲HTTPS。
HTTP協議在通信過程會存在以下隱患： - 無法確定請求發送至目標的Web服務器是否是按真實意圖返回響應的那臺服務器，有可能是已僞裝的Web服務器。
- 無法確定響應返回到的客戶端是否是按真實意圖接受響應的那個客戶端，有可能是已僞裝的客戶端。
- 無法確定正在通信的對方是否具備訪問權限，因爲某些Web服務器上保存着重要的信息，只想發給特定用戶通信的權限。
- 無法判斷請求是來自何方，出自誰手。
- 即使是無意義的請求也會照單全收，無法阻止海量請求下的Dos攻擊(拒絕服務攻擊)。
- 請求或響應內容可能會在傳輸途中遭攻擊者攔截並篡改內容。
HTTPS即使HTTP加上加密處理和認證以及報文完整性保護(完整性是指信息的準確度)，其通信層次區別如圖：
SSL採用一種叫做公開密匙加密的加密處理方式，其加密算法是公開的，但密匙是保密的，加密和解密過程中都需要用到密匙。
加密和解密同用一個密鑰的方式稱爲共享密鑰加密，也叫做對稱密鑰加密。
公開密鑰加密使用一對非對稱的密鑰，一把叫做私有密鑰，另一把叫做公開密鑰，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發佈，任何都可以獲得，使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到加密的信息後，再使用自己的私有密鑰進行解密，這種方式，不需要發送用來解密的私有密鑰，也不必擔心密鑰被攻擊者竊聽而盜走，其整個過程如圖：
HTTPS結合上面兩種加密方式採用混合加密機制，因爲公開密使加密處理比共享密匙加密方式更復雜，效率較低，結合兩者的優勢，HTTPS在交換密匙環節使用公開密鑰加密方式，之後的建立通信交換報文加段則使用共享密鑰加密方式，過程如圖：
爲了認證你訪問的服務器就是原本預想的那臺服務器，這就需要客戶端和服務器雙方都可信賴的第三方機構——數字證書認證機構，服務器會將這份由數字認證機構頒發的公鑰證書(也叫數字證書)發送給客戶端，以進行公開密鑰加密方式通信，接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書書上的數字簽名進行驗證，以但驗證通過，就說明服務器的公開密鑰是值得信賴以及服務器是你預想訪問的那個服務，其整個過程如圖：
HTTPS通信大致步驟如下：
- 客戶端通過發送Client Hello報文開始SSL通信，報文中包含客戶端支持的SSL的指定版本，加密組件列表。
- 服務器可進行SSL通信時，會以Sever Hello報文作爲響應，和客戶端一樣，在報文中包含SSL版本以及加密組件，服務器的加密組件內容是從接收到的客戶端加密組件內選帥出來的。
- 之後服務器發送 Certificate報文，報文中包含公開密鑰 證書。
- 最後服務器發送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束。
- SSL第一次握手結束之後，客戶端以Client Key Exchange報文作爲迴應，報文中包含通信加密中使用的一種稱爲Pre-master secret的隨機密碼串，其過程用了來自服務器公開密鑰進行加密。
- 接着客戶單繼續發送Change Cipher Spec報文，該報文會提示服務器，在此報文之後的通信會採用Pre-master secret密鑰加密。
- 客戶端發送Finished報文，該報文包含連接至今全部報文的整體校驗值，這次握手協商是否成功，要以服務器是否能夠正確加密該報文作爲判定標準。
- 服務器同樣發送Change Cipher Spec報文。
- 服務器同樣發送Finished報文。
- 服務器和客戶端的Finished報文交換完畢之後，SSL連接就算建立完成，當然，通信會受到SSL的保護，從此處開始進行應用層協議的通信，即發送HTTP請求。
- 應用層協議通信，即發送HTTP響應。
最後由客戶端斷開連接。
整個HTTPS通信大致過程如圖：
HTTPS由於使用SSL獨立協議，根據上面的處理過程，我們知道該協議需要大量消耗CPU及內存資源等資源，故通信較慢，網絡負載較大。
確認訪問用戶身份的認證
HTTP協議通信過程會通過各種認證方式來確定其身份，通常涉及到的核對信息有以下幾點：
- 密碼：只有本人才會知道的字符串信息。
- 動態令牌：僅限本人持有的設備內顯示的一次性密碼。
- 數字認證：僅限本人持有的信息。
- 生物認證：指紋和虹膜等本人的生理信息。
- IC 卡等：僅限本人持有的信息。
HTTPS一般的認證方式：BASIC認證(基本認證),DIGEST認證(摘要認證)，SSL客戶端認證，FormBase認證(基於表單認證)。
BASIC認證步驟：
- 當請求的資源需要BASIC認證時，服務器會隨狀態碼401，返回帶WWW-Authenticate首部字段的響應，該字段內包含認證的方式(BASIC)及Request-URI安全域字符串(realm)。
- 接收到狀態碼401的客戶端爲了通過BASIC認證，需要將用戶ID及密碼發送給服務器，發送的字符串內容是由用戶ID和密碼構成，兩者中間以冒號(:)連接後，再經過Base64編碼處理，如：用戶ID爲guest,密碼是guest,連接起來就是guest:guest,然後會經過瀏覽器Base64編碼後，發送請求。
- 接收到包含首部字段Authorization請求的服務器，會對認證信息的正確性進行驗證，驗證通過，則返回一條包含Request-URI資源的響應。
整個認證過程如圖：
BASIC認證缺點：
- 在HTTP等非加密通信的線路上進行這種認證，容易被攔截竊聽。(注：Base64編碼用來加密，而是爲能在通信傳輸信息)
- 瀏覽器無法實現認證註銷操作。
DIGEST認證步驟：
- 請求需認證的資源時，服務器會隨狀態碼401，返回帶WWW-Authenticate首部字段的響應，該字段內包含質問響應方式認證所需的臨時質詢碼(隨機數，nonce).其中首部字段WWW-Authenticate內必須包含realm和nonce這兩個字段(nonce是一種每次隨返回的401響應生成的任意隨機字符串)。
- 接收到狀態碼401的客戶端，提取返回響應中首部字段Authorization信息，並在自己的首部字段Authorization還必須加上usename,uri,response的字段信息(response也叫做Request-Digest，存放經過MD5運算後的密碼字符串，形成響應碼。)
- 接收到包含首部字段Authorization請求的服務器，會對認證信息的正確性進行驗證，驗證通過，則返回一條包含Request-URI資源的響應。
整個認證過程如圖：
DIGEST認證比BASCI認證安全性等級要高，能提供防止密碼被竊聽的保護機制，但是並不存在防止用戶僞裝的保護機制。
SSL客戶端認證步驟：
- 接收到需要認證資源的請求，服務器會發送Certificate Request報文，要求客戶端提供客戶端證書(需要向認證機構購買)
- 用戶選擇將發送的客戶端證書，客戶端會把客戶端證書信息以Client Certificate報文方式發送給服務器。
- 服務器驗證客戶端證書，驗證通過後方可領取證書內的客戶端的公開密鑰，然後開始HTTPS加密通信。
SSL客戶端認證需要客戶持有客戶端證書才能完成認證，因此客戶需要在證書上支出費用。
表單認證：
- 客戶端吧用戶ID和密碼等登陸信息放入報文的實體部分，通常是以POST方法把請求發送給服務器，這時，會使用HTTPS通信來進行HTML表單畫面的顯示和用戶輸入數據的發送。
- 服務器會發放用以識別用戶的SessionID，通過驗證從客戶端發送過來的登陸信息進行身份認證，然後把用戶的認證狀態與SessionID綁定後記錄在服務器端(向客戶端返回響應時，會在首部字段Set-Cookie內寫入SessionID)。
- 客戶端接收到從服務器端發來的SessionID後，會將其作爲Cookie保存在本地，下次向服務器發送請求時，瀏覽器會自動發送Cookie，所以SessionID也隨之發送到服務器，服務器端通過此ID來驗證用戶。
表單認證：表單認證是最常見的認證方式，該認證方法並不是在HTTP協議中定義，它一般是由Web應用提供登陸信息界面，使其更友好和用戶交互，用戶在其表單界面按提示和指導填寫完信息後，才提交到Web那邊應用進行驗證。
基於HTTP瓶頸
HTTP通信協議有下面幾點瓶頸：
- 一條連接上只可發送一個請求。
- 請求只能從客戶端開始，客戶端不可以接收除響應外的指令。
- 請求/響應首部未經壓縮就發送，首部信息越多延遲越大。
- 發送冗長的首部，每次互相發送相同的首部造成的浪費較多。
- 可任意選擇數據壓縮格式，非強制壓縮發送。
引入Ajax技術來解決頁面局部更新，減少響應中傳輸的數據(Ajax是一種有效利用JavaScript和DOM的操作，實現局部Web頁面替換加載的異步通信手段。)
引入Comet技術手段來解決實時更新問題，它通過延遲應答，模擬實現服務器端向客戶端推送的功能，大致通信如下：
通常，服務器端接收到請求，在處理完畢後就會立即返回響應，但爲了實現推送功能，Comet會先將響應置於掛起狀態，當服務器有內容更新時，再返回該響應，因此，服務器端一有更新，就可以立即反饋給客戶端。(因要保留響應，一次連接持續時間更長，故消耗更多的資源)。
SPDY技術引入可以讓HTTP獲得額外幾點功能，如下：
- 多路複用流：通過單一的TCP連接，可以無限制處理多個HTTP請求，所有請求的處理都在一條TCP連接上完成，因此TCP的處理效率提高。
- 賦予請求優先級：SPDY通過給請求逐個分配優先級順序，可以解決在同時刻發送多個請求，帶寬低而導致響應慢的問題。
- 壓縮HTTP首部：壓縮HTTP請求和響應的首部，能使通信產生的數據包數量和發送的字節數減少。
- 推送功能：支持服務器主動向客戶端推送數據的功能，這樣服務器就可以不用再等客戶端發送請求才返回數據了。
- 服務器提示功能：服務器可以主動提示客戶端請求所需資源的額更新情況，因此在客戶端對請求資源已緩存等情況下，可以避免發送不必要的請求。
引入WebSocket協議來解決HTTP一些瓶頸，該協議有主要特點如下：
- *推送功能：支持服務器主動向客戶端推送數據的功能。
- 減少通信量:只要建立起WebSocket連接，就希望一直保持連接狀態，和HTTP相比，不但每次連接時的總開銷減少，而且由於WebSocket的首部信息很小，通信量也減少了。
不過實現WebSocket通信是建立在HTTP基礎上，因此需要用HTTP的Upgrade首部字段告知服務器通信協議的改變，以達到握手的目的，整個過程如圖：
