返回結果的HTTP狀態碼
服務器返回的各類狀態碼
狀態碼以3位數字和原因短語組成。
數字中的第一位指定了響應類型，後兩位無分類。響應類型有以下五種
| 類別 | 原因短語 | |
|---|---|---|
| 1XX | Informational(信息性狀態碼) | 接收的請求正在處理 |
| 2XX | Success(成功狀態碼) | 請求正常處理完畢 |
| 3XX | Redirection(重定向狀態碼) | 需要進行附加操作以完成請求 |
| 4XX | Client Error(客戶端錯誤狀態碼) | 服務器無法處理請求 |
| 5XX | Server Error(服務器錯誤狀態碼) | 服務器處理請求出錯 |
常見2XX狀態碼舉例
- 200 OK ：表示請求被正常處理
- 204 No Content：請求處理成功，但是沒有資源可以返回。
- 206 Partial Content：表示進程了範圍請求，響應報文包含由Content-Range指定範圍的實體內容。
常見3XX狀態碼舉例：
- 301 Moved Permanently：永久性重定向，表示該請求的資源已經分配了新的URI。如果已經把資源對應的URI保存爲書籤了，這時候應該按Location首部字段提示的URI重新保存。
- 302 Found：便是請求的資源已經被分配了新的URI，希望用戶（本次）能使用新的URI。
- 303 See Other：對應資源存在另一個URI，應使用GET方法定向獲取請求的資源。
- 304 Not Modified：服務端允許請求訪問資源，但未滿足條件。雖然也是3開頭，但和重定向沒有關係。
- 307 Temporary Redirect：臨時重定向，和302有相同的含義。
常見的4XX狀態碼舉例
- 400 Bad Request：表示請求報文中存在語法錯誤。需要修改請求內容後再次發送。
- 401 Unauthorized：顯示發送的請求需要通過認證。如果之前已經認證一次，表示用戶認證失敗。
- 403 Forbidden：表明對請求的資源的訪問被服務端拒絕了。服務端可以在實體的主體部分對原因進行描述，這樣就能讓用戶看到。
- 404 Not Found：便是無法找到請求的資源。也可以用在服務端拒絕請求且不想說理由時候
常見的5XX狀態碼舉例
- 500 Internal Server Error：表示服務端執行請求時候發生了錯誤。也可能是Web應用存在Bug或某些臨時的故障。
- 503 Service Unavailable：表示服務器暫時處於超負荷或正在進行停機維護，現在無法處理請求。可以再首部字段RetryAfter中寫入恢復時間。
與HTTP協作的Web服務器
用單臺虛擬主機實現多個域名
一臺實體服務器，可以建立多個虛擬主機，用來綁定多個域名。
由於虛擬可以寄存多個不同主機名和域名的Web網站，因此在發送HTTP請求時，必須在Host首部內完整指定主機名或域名的URI。
代理、網關、隧道
-
代理
是一種有轉發功能的應用程序，扮演位於服務器和客戶端之間的中間人角色。接收有客戶端發送的請求到服務端，同時接收服務端返回的響應到客戶端。
- 基本行爲：就是轉發客戶端請求到其他服務器，可以連接多個代理。每次通過代理會最佳寫入Via首部信息
- 使用理由：利用緩存技術減少網絡帶寬，阻止內部針對特定網站的訪問控制、獲取訪問日誌。
- 分類
- 緩存代理：代理會緩存之前訪問的資源，再次訪問時候，就可以不從原服務器獲取資源，而直接返回緩存了。
- 透明代理：轉發請求時候不對報文進行任何加工的代理稱爲透明代理。反之稱爲非透明代理。
-
網關
網關是轉發其他服務器通信數據的服務器，接收客戶端的請求後，他就像自己擁有資源的服務器一樣對請求處理，客戶端甚至不會發現
工作機制和代理類似，而網關可以使通信線路上的服務器提供非HTTP協議服務。
利用網關可以提高安全性。比如可以再客戶單與網關之間的通信線路上加密以保證連接的安全。
-
隧道
隧道是在相隔甚遠的客戶端和服務端之間進行中轉，並保持雙方通信連接的應用程序。
隧道的目的是確保客戶單能與服務器進行安全的通信。
隧道本身不會解析HTTP請求。會在通信雙方斷開連接時結束。
緩存
-
概念：
是指代理服務器或客戶端本地保存的資源副本，利用緩存可減少對源服務器的訪問，因此也就節省了通信流量和通信時間。 -
緩存的有效期
每次請求時候，即使存在緩存，也會和服務端確認緩存是或否有效，如果失效，將再次從服務器獲取新的資源並緩存。
HTTPS
-
HTTP的缺點
- 通信使用明文，內容可能會被竊聽
- 不驗證通信方的身份，因此可能遭遇僞裝
- 無法證明報文的完整性，所以有可能以遭篡改
-
HTTPS的特點
- 客戶端、服務端都使用證書來證明身份
- 不是一種新的協議，是HTTP通信接口部分用SSL和TLS協議代替而已。
相互交換密鑰的公開密鑰加密技術
SSL採用一種叫做公開密鑰加密的加密處理方式。也就是加密算法是公開的，而密鑰確是保密的。通過這種方式來保證加密方法的安全性。-
共享密鑰加密的困難：
加密解密都用一個密鑰的方法叫做共享密鑰加密。
如果使用這種加密，需要在加密時，把密鑰發送給對方。但是任何發送方式都可能被監聽。所以這個方法執行不下去了。
-
使用兩把密鑰的公開密鑰加密
公開密鑰加密使用一對非對稱的密鑰。一把私鑰一把公鑰。公鑰可以隨意發佈，私鑰需要自己保存。
發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息後，在使用自己的私鑰進行解密。利用這種方式，不需要發送用來解密的私有密鑰，也不用擔心被攔截。
而且根據密文和公開的密鑰，恢復到信息的原文是異常困難的。
公鑰加密後，可以用私鑰解密，不能用公鑰解密
-
HTTPS採用混合加密機制
- 先使用公鑰加密的方式安全的交換在稍後的共享密鑰加密中要使用的密鑰
- 確保交換的密鑰是安全的前提下，使用共享密鑰的方式進行通訊
- 公鑰、私鑰在一塊。公鑰會發送出去，用來對方加密。對方發來的信息肯定是用我方的公鑰加密的，這樣才能解開。
-
HTTPS證書的安全性
在使用過程中，我們無法證明服務器的公鑰是正確的公鑰。爲了解決這個問題，各種認證機構就開始產生了。
數字證書認證機構處於客戶端和服務端雙方都可信賴的第三方機構的立場上。數字證書認證時，會確定對應的機構是否有資質，然後發送對應的證書。
認證完後，客戶端拿到服務端的公鑰會先向數字認證機構驗證，已確認服務器的公開密鑰的真實性
確認訪問用戶身份的認證
-
何爲認證
計算機本身無法判斷使用者的身份，爲了弄清使用者的身份，就需要認證
認證需要覈對的信息有：
- 密碼：只有本人知道的字符串
- 動態令牌：僅限本人持有設備顯示的一次性密碼
- 數字證書：僅限本人持有的信息
- 生物認證：職位、虹膜及面部識別等
- IC卡等：僅限本人持有的信息
-
BASIC認證
- 發送請求
- 服務端返回401告知需要認證
- 客戶端鍵有戶名密碼用冒號連接，Base64編碼後發送
- 認證成功返回200，認證失敗返回401
缺陷
Base64只是編碼，不是加密，在HTTP等非加密通信的線路上進行BASIC認證的過程中，如果被竊聽，可能被盜。
-
DIGEST認證
步驟
-
客戶端發送請求
-
服務端返回臨時的質詢碼，告知需要認證的狀態碼401
首部字段內會包含realm和nonce這兩個字段的信息。客戶端就是依靠向服務器返回這兩個值進行認證的。
nonce是一種每次歲返回的401響應生成的任意隨機字符串。該字符串通常由Base64編碼的十六進制樹組成。
-
客戶端發送摘要以及有質詢碼計算出的響應碼
在響應嗎中，會包含服務端接收的字段realm和nonce。然後再加入username字段表示用戶名，response用來存放MD5加密後的密碼。這些字段會放入請求的首部字段Authorization中。
-
服務端認證成功返回200失敗再次發送狀態碼401
服務器收到還有字段Authorization的請求後，會確認認證的準確性，然後返回對應的結果。
缺陷
和HTTPS的客戶端認證相比仍舊較弱。雖然提供了放置密碼被竊聽的保護機制，但是並不能防止用戶僞裝的保護機制。
-
-
SSL客戶端認證
介紹
SSL客戶端認證是藉由HTTPS的客戶單證書完成的認證方式。憑藉客戶端證書認證，服務器可確認訪問是否來自已登錄的客戶端。
SSL客戶端認證的認證步驟
- 接受需要認真的請求時候，服務按會發送CertificateRequest報文，要求客戶端提供證書。
- 用戶端選擇證書，把證書信息用ClientCertificate報文方式發送給服務端
- 服務端驗證證書通過後，領取客戶端的公鑰，然後開始HTTPS加密通信。
SSL雙因素認證
也就是除了需要用證書來確定當前客戶端的合法性外，還需要賬號密碼來確認是用戶本人在使用當前電腦。
-
基於表單的認證
介紹
基於表單的認證方法並不是在HTTP協議中定義的。客戶端回想服務器上的Web應用程序發送登錄信息(Credential)，按登錄信息的驗證結果認證。
認證多半基於表單認證
由於使用便利性不太好，所以BASIC和DIGEST認證幾乎不怎麼使用，SSL客戶端認證雖然具有高度安全性，但因爲導入及費用等問題，還未普及。
Session管理及Cookie應用
表單認證時候一般會使用Cookie來管理Session(會話)。
具體步驟如下：
- 客戶端把ID和密碼放入報文實體部分，一般通過POST方法把請求發送給服務器。
- 服務端根據用戶名密碼發放用於識別用戶的SessionID。SessionID回放在首部字段Set-Cookie中。爲了安全不被盜用，SessionID應該是難以推測的字符串，而且服務器要對其有效期進行管理，保證其安全性。
- 客戶端收到服務端的SessionID後，會將其保存在本地Cookie，下次請求時候，會自動發送Cookie，SessionID也會隨之發送。
基於HTTP的功能追加協議
HTTP建立之初，只是爲了傳輸HTML文檔，完全沒有想到現在發展的這麼五花八門啥都想傳。所以HTTP有了很多限制，但是由於HPPT的使用範圍太廣了，所以一些新的協議只能基於HTTP來修改，這樣誕生了很多基於HTTP的協議。
-
SPDY協議
HTTP的瓶頸
在Facebook和微博等SNS網站上，用戶短時間發的信息是千萬級別的，web網站爲了顯示這些信息，需要不斷把服務器的最新內容反饋到客戶端，這個用HTTP十分難以實現。
解決方法
-
Ajax解決方法
利用JavaScript和DOM的操作，達到局部Web頁面替換加載的異步通訊手段。和以前的同步通訊相比，由於只是更新了一部分頁面，響應中傳輸的數據量會因此而減少。不過Ajax未解決HTTP協議本身的限制。
-
Comet解決方法
是一種延遲應答，模擬實現服務器向客戶端推送的功能。一但服務端有內容更新了，Comet不會讓請求等待，而是直接給客戶端返回。
這種方式雖然內容上做到了實時更新，但爲了保留響應，一次連接的持續時間也變長了。期間，爲了維護連接會消耗更多的資源，當然也沒有解決HTTP協議本身的問題。
-
引出了SPDY
爲了根本性的解決這一問題，需要有一些協議層面上的改動，處於持續開發狀態的SPDY協議，正是爲了在協議級別消除HTTP所遇到的瓶頸
-
-
SPDY的設計與功能
介紹
在TCP/IP的應用層與傳輸層之間通過新加會話層的形式運作。同時爲了安全考慮，SPDY規定通信中使用SSL
實用功能
使用SPDY後，HTTP協議額外獲得以下功能：
-
多路複用流
通過單一的TCP連接，可以無限制處理多個HTTP請求。所有請求的處理都在一條TCP連接上完成，因此TCP的處理效率得到提高。
-
賦予請求優先級
給請求逐個分配優先級順序，爲了在發送多個請求時，解決因帶寬低而導致響應變慢的問題。
-
壓縮HTTP首部
-
推送功能
可以支持服務器主動向客戶端推送數據。這樣服務器就可直接發送數據，而不必等待客戶端的請求。
-
服務器提示功能
服務器可以主動提示客戶端請求所需的資源。由於在客戶端實現資源之前就可以獲知資源的存在，因此在資源已緩存等情況下，可以避免發送不必要的請求。
綜上可以得出結論，SPDY的確是一種可有效消除HTTP瓶頸的技術，但很多Web網站的問題並非僅僅由HTTP瓶頸導致。對Web本身的速度提升，還應該從其他可細緻鑽研的地方入手，比如改善Web內容的編寫方式等。
-