家里有事阅签，所以最近不加班掐暮，導致我每天忙的團團轉(zhuǎn)，實在擠不出時間看書政钟，請諒解~

接著上一篇隨筆路克，我原先計劃總結(jié)HTTP首部這個重要的內(nèi)容，但是這些內(nèi)容是瑣碎的养交，是有點兒拗口的精算，又是重要的。希望大家可以結(jié)合書本第六章以及瀏覽器開發(fā)工具里的請求和響應等實際情況碎连，去理解第六章灰羽，大概就會明白我現(xiàn)在雖然讀完了第六章，但是卻依然無法總結(jié)出來點東西的無奈鱼辙。谦趣。

廢話很多，這里是正文座每，網(wǎng)友們

1 HTTP安全及安全小能手HTTPS

互聯(lián)網(wǎng)是一個連通你我他的廣闊大環(huán)境，它不是私人的摘悴，任何人都擁有索取和發(fā)送的權(quán)利峭梳，當然，也可以有人蹲在墻角偷聽蹂喻，偷聽時皮一下葱椭，可能會對報文進行破壞和修改。So,what should we do guys?

一定會有阿秀同學說 加密唄口四！ 但是加密處理的通信孵运，也一定能讓別人窺視到，只是在一定程度上的保護報文有可能不會被解密蔓彩，但是依然可以被篡改治笨。 為了防止被竊聽，我們可以使用通信的加密赤嚼。所以對于加密來說旷赖，我們分為通信加密和內(nèi)容加密，通信加密就是使用運輸層的SSL或TLS的組合使用更卒，建成一個安全線路等孵，保護該線上的報文，還有一種是報文內(nèi)容加密蹂空，客戶端和服務端同事具有加密解密機制俯萌，可以在一定程度保護報文果录。

那如果壞人偽裝成用戶，對服務器請求消息咐熙，該怎么辦弱恒？如果該用戶沒有權(quán)限訪問我網(wǎng)站的用戶數(shù)量，服務端該怎么處理糖声？當然有方法斤彼！我們使用證書，雖然HTTP協(xié)議無法確定通信仿蘸泻，但是使用SSL就可以琉苇，因為它不僅提供加密處理，而且使用一種手段叫證書悦施，可以確定通信方并扇。這對使用者里說，減少了個人信息泄露危險性抡诞，也完成了有效的認證穷蛹。

所以SSL是一個好伙伴，為了將二者組合昼汗，HTTPS出現(xiàn)肴熏，（原文->)HTTPS是添加了加密及認證機制的HTTP，換言顷窒，HTTPS是身披SSL外殼的HTTP蛙吏。但是目前并沒有一直使用HTTPS，因為它也有缺點鞋吉，加密解密會消耗CPU及內(nèi)存資源鸦做，所以對于非敏感信息，我們可以不使用HTTPS谓着。差點忘了泼诱，這里還有個面試知識點，SSL是使用非對稱加密的方式哦赊锚！?

2 確認訪問用戶身份的認證

對于那些請求敏感信息的人時治筒，服務端也是很敏感的，它要知道你是不是那個擁有權(quán)限舷蒲，擁有密碼矢炼，擁有證書，合適而又安全的那個你阿纤。于是使用認證句灌。HTTP/1.1使用的認證有BASIC認證、DIGEST認證、SSL客戶端認證胰锌、FormBase認證等骗绕。

Basic認證就是在HTTP首部添加Authorization字段，并把用戶ID和密碼以base64方式編碼后發(fā)送资昧。但它不太靈活酬土，不能多次進行basic認證。?

DIGEST認證使用質(zhì)詢/響應的方式格带，當客戶端發(fā)送認證要求撤缴，服務端會發(fā)送質(zhì)詢碼表示響應，然后客戶端對其進行計算叽唱，最后生成響應碼屈呕，返回給對方進行認證。DIGEST使用這種方式棺亭，保護了密碼防止被竊聽虎眨，但是不能防止用戶偽裝。

SSL客戶端認證镶摘，則是通過借用證書嗽桩，達到認證效果，但多數(shù)情況下凄敢，SSL客戶端不會僅依靠證書完成認證碌冶，會結(jié)合基于表單的認證組合形成雙因素認證來使用。它的缺點就是貴涝缝！?

基于表單認證种樱，是客戶端會向服務器上的Web應用程序發(fā)送登錄信息，按照登錄信息的驗證結(jié)果認證俊卤。（<-此定義讀三遍）表單認證時，一般使用cookie來管理Session害幅，在發(fā)送時綁定cookie進行發(fā)送消恍，從而使session id也隨之發(fā)送，服務端可通過驗證接收到的session id 識別用戶和認證狀態(tài)以现。

今天的有感到此時已經(jīng)沒有感了狠怨，2018年快過去了，2019 希望看更多的書分享給網(wǎng)友邑遏。（后面3章是一些對http的追加技術(shù)或介紹http的攻擊佣赖，不屬于知識型內(nèi)容，請大家自行翻閱 增長知識）记盒。