一、、Http 與 Https
1、Http / Https介紹
- HTTP是Hyper Text Transfer Protoco(超文本傳輸協議)的縮寫。HTTP協議是用於從Web服務器傳輸超文本到本地瀏覽器的協議,它能使瀏覽器更加高效,使網絡傳輸減少,保證計算機正確快速地傳輸超文本文檔。
- 現在我們普遍使用的版本是HTTP1.1。HTTP是一個應用層協議,它由請求和響應組成,是一個標準的B/S模型。同時,它也是一個無狀態的協議,即同一個客戶端上,此次請求與上一次請求是沒有對應關係的。
- HTTPS簡單地說就是HTTP的安全版。在安全性要求比較高的網站(例如銀行網站)上會看到HTTPS,它本質上也是HTTP協議,只是在HTTP增加了一個SSL或TLS協議層。SSL/TLS協議提供了加解密的機制,所以它比HTTP明文傳輸更安全。
- HTTP可以直接進入TCP傳輸層,也可以在TCP層上加一層SSL/TLS層,這樣就先經過SSL/TLS再進入TCP傳輸層。這兩種方式便是HTTP與HTTPS。一般HTTP的端口號爲80,而HTTPS的端口號爲443。
2、SSL/TLS協議層主要的職責
藉助下層協議的信道安全地協商出一份加密密鑰,並且用此密鑰來加密HTTP請求響應報文。解決安全性方面的問題
a:提供驗證服務,驗證本次會話實體身份的合法性
b:提供加密服務,強加密機制能保證通信過程中的消息不會被破譯
c:提供防篡改服務,利用Hash算法對消息進行簽名,通過驗證簽名保證通信內容不被篡改
3、對稱加密、非對稱加密、Hash 算法
- 對稱加密。密鑰只有一個,加密、解密都是這個密碼,加解密速度快,典型的對稱加密算法有DES、AES、RC4等。
- 非對稱加密。密鑰成對出現,分別爲公鑰與私鑰,從公鑰無法推知私鑰,反之,從私鑰也不能推知公鑰。
a: 加密、解密使用不同的密鑰,公鑰加密需要私鑰解密,反之,私鑰加密需要公鑰解密。
b: 非對稱加密速度較慢,典型的非對稱加密算法有RSA、DSA、DSS等
- Hash算法,這是一種不可逆的算法,它常用於驗證數據的完整性。
4、HTTPS的工作原理及流程
HTTPS是基於TCP/IP協議通信的,屬於可靠傳輸,必須要先進行三次握手,完成連接的建立。接着是SSL的握手協議,此協議非常有效地讓客戶和服務器之間完成相互之間的身份驗證及密鑰協商。
- 客戶端瀏覽器向服務器發送SSL/TLS協議的版本號、加密算法的種類、產生的隨機數,以及其他需要的各種信息。
- 服務器從客戶端支持的加密算法中選擇一組加密算法與Hash算法,並且把自己的證書(包含網站地址、加密公鑰、證書頒發機構等)也發送給客戶端。
- 瀏覽器獲取服務器證書後驗證其合法性,驗證頒發機構是否合法,驗證證書中的網址是否與正在訪問的地址一致,通過驗證的瀏覽器會顯示一個小鎖頭,否則,提示證書不受信。
- 客戶端瀏覽器生成一串隨機數並用服務器傳來的公鑰加密,再使用約定好的Hash算法計算握手消息,發送到服務器端。
- 服務器接到握手消息後用自己的私鑰解密,並用散列算法驗證,這樣雙方都有了此次通信的密鑰。
- 服務器再使用密鑰加密一段握手消息,返回給客戶端瀏覽器。
- 瀏覽器用密鑰解密,並用散列算法驗證,確定算法與密鑰。
二、HTTP請求/響應模型
1、HTTP協議永遠都由客戶端發起請求,由服務器進行響應併發送回響應報文。
- 如果沒有客戶端進行請求或曾經請求過,那麼服務器是無法將消息推送到客戶端的。HTTP採用了請求/響應模型,客戶端向服務器發送一個請求,請求頭包含請求方法、URI、協議版本、請求修飾符、客戶信息,以及類似於MIME結構的消息內容。
- 服務器以一個狀態行作爲響應,內容包括消息協議版本、成功(或失敗)編碼、服務器信息、實體元信息及一些實體內容。這樣就完成了一個請求/響應過程。
2、一個HTTP請求/響應的工作流程
- 客戶端瀏覽器先要與服務器建立連接,即通過三次握手建立連接。在瀏覽器上最常見的場景就是單擊一個鏈接,這就觸發了連接的建立。
- 連接建立後,客戶端瀏覽器發送一個請求到服務器,這個過程其實是組裝請求報文的過程。
- 服務器端接收到請求報文後,對報文進行解析,組裝成一定格式的響應報文,返回給客戶端。
- 客戶端瀏覽器接收到響應報文後,通過瀏覽器內核對其進行解析,按照一定的外觀進行顯示,然後與服務器斷開連接。
三、解析HTTP報文
1、具體請求與響應報文格式是怎樣的?報文又是怎樣解析的?
- 一個HTTP請求由三部分組成:請求行、請求頭部、請求體。
a: 請求行(request line)由請求方法字段、URL字段和HTTP協議版本字段組成,它們用空格分隔並以“\r\n”結尾。
b: 請求頭部(request header)包含若干個屬性與屬性值,它們通過冒號分隔,格式爲“屬性名:屬性值”,每個屬性-屬性值對以“\r\n”結尾,整個請求頭部又以“\r\n”結尾。
c: 請求體(requestbody)一般在POST方法裏使用,而不在GET方法中使用,例如瀏覽器將表單中的組件格式化成param1=value1¶m2=value2鍵值對組,然後將其存放至請求體中,以此完成對錶單參數的傳輸。
2、請求方法:
GET 和 POST(最常見的請求方法) DELETE、HEAD、OPTIONS、PUT、TRACE
3、GET 和 POST
- GET方法,請求參數和值附加在URL後面,用問號隔開,如/index.jsp? id=10000。用GET方法傳遞的參數都能在地址欄上看到,大多瀏覽器對地址的字符長度做了限制,最多是1024個字符。
- 所以要傳送大量數據,就要選擇用POST方法。POST方法允許客戶端提交更多信息給服務器,它把請求參數封裝到請求體中,可以傳輸大量數據,不會對數據大小進行限制,同時也不在地址欄顯示參數。
4、請求頭部常見的典型屬性有:
- User-Agent:客戶端請求的瀏覽器類型,是客戶端應用程序的名稱,不同版本、不同廠商的值都可能不相同。
- Accept:告訴服務器客戶端可識別的媒體類型列表。這個屬性的值可以是一個或多個MIME類型的值,服務器可以根據這個判斷是否發送這個媒體類型。
- Host:供客戶端訪問的那臺機器的主機名和端口號。
- Cookie:用於傳輸客戶端的Cookie到服務器,服務器維護的Session就是通過Cookie附帶的JSESSIONID值來區分哪個客戶端關聯哪個Session的。還可以通過重寫URL的方式將JSESSIONID附帶在URL後面。
- Referer:表示這個請求是從哪個URL過來的,可以讓服務器知道客戶端從哪裏獲得其請求的RUL。
例如在A網站的頁面單擊一個鏈接進入B網站的頁面,瀏覽器就會在請求中插入一個帶有A網站中該頁面地址的Referer頭部。
- Cache-Control:通過這個屬性可以對緩存進行控制。
5、HTTP響應報文
- 響應報文由三部分組成:響應行、響應頭部、響應體(如圖1.5所示)。
a: 響應行(response line)包含協議及版本、狀態碼及描述,並以“\r\n”結尾。
b: 響應頭部(response header)包含若干個屬性與屬性值,它們通過冒號分隔,格式爲“屬性名:屬性值”,每個屬性-鍵值對都以“\r\n”結尾,並且響應頭部最後以“\r\n”結尾。
c: 響應體(response body)存放真正需要的文本。
6、常用的狀態碼(響應狀態碼由三位數字組成)
- 200 OK:客戶端請求成功。
- 400 Bad Request:客戶端請求有語法錯誤,服務器無法識別。
- 401 Unauthorized:請求未經授權。
- 403 Forbidden:服務器收到請求,但拒絕提供服務。
- 404 Not Found:請求資源不存在。
- 500 Internal Server Error:服務器發生不可預期的錯誤。
- 503 Server Unavailable:服務器當前不能處理客戶端的請求,一段時間後可能恢復正常。常用的響應報文頭屬性如下。
Cache-Control:服務器通過該報文頭屬性告訴客戶端如何對響應的內容進行緩存。
例如,值爲max-age=600,則表示客戶端對響應內容緩存600秒,在此期間,如果客戶端再次訪問該資源,可以直接從客戶端緩存中獲取內容,不必再向服務器獲取。
Location:這個屬性用於網頁重定向,
例如,服務器把重定向的地址添加到響應報文頭部的這個屬性,這樣客戶端瀏覽器解析報文後就直接重新跳轉到這個地址。
Set-Cookie:利用這個屬性服務器端可對客戶端的Cookie進行設置。