【web必知必会】—— 图解HTTP（下）
上一篇《圖解HTTP 上》總結了HTTP的報文格式，發送方式，以及HTTP的一些使用。
本文再總結以下內容：
1 http狀態碼
2 http報文首部中的各字段
3 http中的身份驗證
通過上篇粗略的描述，大體了解了http首部的概念。
其實請求報文與響應報文長得差不多，區別就在于請求報文與響應報文有一個各自的報文首部，和一個請求行和狀態行。
可以看到，差別就在于
請求行中指定的是HTTP版本和請求的方式（GET\POST等）。
狀態行中指定了HTTP版本和返回的狀態碼以及短語。
并且，請求首部與相應首部中擁有不同的屬性，一會再說。
那么我們看看常見的狀態碼都有什么：
其中需要說明的是302,即臨時重定向，這個比較常見。前兩天我登百度的時候，突然發現前面的協議變成了https，我還納悶，這兩天在看又變回來了。原因就是當時訪問www.baidu.com時默認使用Http，但是返回的302臨時重定向和一個Location，我們的瀏覽器會自定跳轉到這個返回的location:https://www.baidu.com中。由于現在改回來了，就不做截圖說明了。
常見的一些狀態碼都在導圖中列出來了，最常見的還是404：經常開發中遇到，就是因為訪問的URL寫錯了。
再看看各首部字段中都有些什么內容吧。
這里面學問最大的當然要是Cahce了，合理的使用Cache會讓網站的訪問達到登峰造極的地步，當然！我不會.....
這些屬性，用到的時候再詳細查看吧，這里也就不一一贅述了。
HTTP+加密+認證+完整性保護=HTTPS
為什么會出現https呢，多個s又有什么用呢！
http有幾個缺點：
1 傳輸的時候使用明文，這顯然會被不法者截取干一些見不得人的勾當。
2 沒有認證機制，這樣我們就可以偽造一些http訪問，這顯然會造成一些困擾。比如Jmeter就是典型的例子，偽造一大堆的http URL然后壓力測試，這也就是DOS攻擊的一種。
3 無法驗證報文的完整性，比如一個http的報文已經被不法者截取并且篡改，服務器端也無法驗證。
而HTTPS相當于套上SSL的HTTP，相當于穿上黃金甲的青銅圣斗士：
? ? ? ?
不僅僅是逼格的提升！
但是HTTPS也有它自身的缺點：
1 通信的速度變慢，由于需要加密，一個握手就多了好幾個往返
2 對用戶端的機器負載的增加。
因此，如果不是像金融支付這種需要高強度的安全性的場景，還是http比較好。
最后看一下HTTP中關于認證的概念
有一些網址或者服務需要用戶的身份信息，因此需要隨時知道這些消息，但是肯定不能每次都讓用戶輸入用戶密碼，因此關于認證就有下面幾種方式：
其中BASIC認證是最簡單的認證，大致過程如下：
1 客戶端訪問某URL。
2 服務器端返回401狀態碼，提示用戶輸入用戶名密碼。
3 用戶輸入用戶名密碼，通過BASE64編碼傳輸。
4 服務器通過認證，返回狀態碼200
? ? ?通過上面的過程，就可以發現BASIC的問題：
1 僅僅通過BASE64編碼，其實還是屬于明文傳輸，安全性不高
2 有的瀏覽器不支持注銷
?
鑒于上面BASIC的問題，DIGEST做了補充，它的過程與上面類似：
1 客戶端訪問
2 服務器端返回質詢碼
3 客戶端發送響應碼
這里通過隨機的生成質詢碼來作為計算的一種方式，客戶端依據這個質詢碼生成響應碼，進行驗證。
這樣就彌補了明文傳輸用戶密碼的風險。
?
SSL客戶端驗證，這個比較普遍了！
像支付寶啊，郵政網銀啊之類的，在登錄時，都需要下載一個數字認證的東西，這個東西就屬于一種SSL客戶端的驗證。
很顯然它的缺點就是需要客戶去手動的安裝，這個對于一般的用戶來說，代價有點高。
?
最后一種是應用最普遍的，通過表單記錄用戶的身份信息，可以使用cookie或者session的方式保存用戶信息。
?
參考
[1] wiki 302狀態碼：http://zh.wikipedia.org/wiki/HTTP_302
[2] http與https：http://19841026.iteye.com/blog/600615
[3] 狀態碼301 302：http://wlei1818.iteye.com/blog/1749456?
[4] 《圖解http》
posted on 2015-03-04 17:20 NET未來之路 閱讀(...) 評論(...) 編輯 收藏轉載于:https://www.cnblogs.com/lonelyxmas/p/4313873.html
總結
以上是生活随笔為你收集整理的【web必知必会】—— 图解HTTP（下）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： BC#29A:GTY's math pr
- 下一篇： spring处理方法返回值的类型