http協議相關:
http協議的特性: http協議是建立在TCP/IP協議之上應用層協議,默認端口為80或者8080。http協議的的特點是無狀態,無連接(并不是真的沒有連接,而是在請求數據的時候有連接,在數據回來的時候就斷開連接,不想tcp那樣是一個長連接)
http協議的請求:
利用抓包工具httpwatch可以獲取報文,http協議的報文傳輸的是ASCII碼,在TCP/IP協議之上,主要主要分為三部分:請求行、請求頭、請求體
- 請求行: 第一行,包含三個信息:請求方式,url,http協議版本對應下面的:
GET /books/?sex=man&name=Professional HTTP/1.1
- 比如下面的GET請求(GET請求和POST請求是http進行通訊的兩種不同的方式),在get請求參數如果包含
&
符號在發送請求時就會被當做參數的分隔符處理,比如請求參數:var url= "xxxx?name=" + "aaa&bbb"
期望的請求參數應該是name = aaa&bbb
實際的請求參數會變成name = aaa
和bbb=
處理方法: 在拼接參數的時候,使用encodeURIComponent()
進行手動轉義。var url= "xxxx?name=" + encodeURIComponent("aaa&bbb")
。下面代碼是發送http請求后能夠獲得的數據,
GET /books/?sex=man&name=Professional HTTP/1.1 //GET是請求方式、/books/?sex=man&name=Professional是url就是進行請求的網址、第三個是http協議的版本Host: www.example.comUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)Gecko/20050225 Firefox/1.0.1Connection: Keep-Alive
- 下面是POST請求:
POST / HTTP/1.1 //POST是請求方式Host: www.example.comUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)Gecko/20050225 Firefox/1.0.1Content-Type: application/x-www-form-urlencodedContent-Length: 40Connection: Keep-Alivesex=man&name=Professional
-
GET請求和POST請求的區別: ① url可見性:get,參數url可見;post,url參數不可見。② 數據傳輸上:get,通過拼接url進行傳遞參數;post,通過body體傳輸參數。③ 緩存性:get請求是可以緩存的,post請求不可以緩存。④ 后退頁面的反應:get請求頁面后退時,不產生影響,post請求頁面后退時,會重新提交請求。⑤ 傳輸數據的大小:get一般傳輸數據大小不超過2k-4k(根據瀏覽器不同,限制不一樣,但相差不大),post請求傳輸數據的大小根據php.ini 配置文件設定,也可以無限大。⑥ 安全性:這個也是最不好分析的,原則上post肯定要比get安全,畢竟傳輸參數時url不可見,但也擋不住部分人閑的沒事在那抓包玩。安全性個人覺得是沒多大區別的,防君子不防小人就是這個道理。對傳遞的參數進行加密,其實都一樣。
本質區別: GET產生一個TCP數據包;POST產生兩個TCP數據包。對于GET方式的請求,瀏覽器會把http header和data一并發送出去,服務器響應200(200是狀態碼,服務器返回數據);而對于POST,瀏覽器先發送header,服務器響應100 continue,瀏覽器再發送data,服務器響應200 ok(返回數據)。 -
請求頭: 瀏覽器向服務器發送一些狀態數據,標識數據等等。一個信息一行,包括信息名:信息值 按行分隔,注意: 請求頭信息,需要使用一個空行結束!
User-Agent: firefox//表示發送請求的瀏覽器(請求代理端)是firefox
Host: shop.100.com//表示請求的主機域名(基于域名的虛擬主機就是靠這個頭判斷的)
Cookie:name=itcast//瀏覽器攜帶的cookie數據。
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive
- 請求主體: 請求代理端向服務器端,發送的請求數據!典型的就是POST形式發送的表單數據!get請求,沒有請求主體部分!get數據是在請求行中的url上進行傳遞的!
http協議的響應:
響應包括:響應行、響應頭、響應體。注意: 每行,包括相應行和響應頭,都需要一個 \r\n結尾
HTTP/1.1 200 0K
Date: Tue,19 Nov 2013 03:08:55 GMT
Server: Apache/2. 2.22 (Win32) PHP/5.3. 13
X- -Powered -By: PHP/5. 3.13
Content-Length: 16
Content- Type: text/html
- 響應行: 響應行包括:協議版本、狀態碼、狀態消息。典型的狀態碼:1xx:消息、2xx:成功、3xx:請求被重定向、4xx:瀏覽器端錯誤、5xx:服務器端錯誤。比如:500 服務器內部錯誤、404 請求的頁面沒有找到、403 沒有權限、200 請求成功。
- 響應頭: Content-Type: text/html 內容類型,告知瀏覽器接下來發送的響應主體數據是什么格式!Content-Length: 響應主體數據的長度!Date: 響應的時間。GMT時間!
- 響應主體: 主要的響應數據,在瀏覽器的主體區域顯示的數據都是相應主體!
https協議:
http協議是明文傳輸的,因此很容易被截取和解析,泄漏個人數據。https協議是在http和tcp之間多添加了一層,進行身份驗證和數據加密。
- HTTPS 原理:
- ① 客戶端將它所支持的算法列表和一個用作產生密鑰的隨機數發送給服務器
② 服務器從算法列表中選擇一種加密算法,并將它和一份包含服務器公用密鑰的證書發送給客戶端;該證書還包含了用于認證目的的服務器標識,服務器同時還提供了一個用作產生密鑰的隨機數;
③ 客戶端對服務器的證書進行驗證(有關驗證證書,可以參考數字簽名),并抽取服務器的公用密鑰;然后,再產生一個稱作 pre_master_secret 的隨機密碼串,并使用服務器的公用密鑰對其進行加密(參考非對稱加 / 解密),并將加密后的信息發送給服務器。
④ 客戶端與服務器端根據 pre_master_secret 以及客戶端與服務器的隨機數值獨立計算出加密和 MAC密鑰(參考 DH密鑰交換算法);
⑤ 客戶端將所有握手消息的 MAC 值發送給服務器 ;
⑥ 服務器將所有握手消息的 MAC 值發送給客戶端
密碼學基礎:
- 明文: 明文指的是未被加密過的原始數據。
- 密文:明文被某種加密算法加密之后,會變成密文,從而確保原始數據的安全。密文也可以被解密,得到原始的明文。
- 密鑰:密鑰是一種參數,它是在明文轉換為密文或將密文轉換為明文的算法中輸入的參數。密鑰分為對稱密鑰與非對稱密鑰,分別應用在對稱加密和非對稱加密上。
- 對稱加密:對稱加密又叫做私鑰加密,即信息的發送方和接收方使用同一個密鑰去加密和解密數據。對稱加密的特點是算法公開、加密和解密速度快,適合于對大數據量進行加密,常見的對稱加密算法有DES、3DES、TDEA、Blowfish、RC5和IDEA。
其加密過程如下:明文 + 加密算法 + 私鑰 => 密文
解密過程如下: 密文 + 解密算法 + 私鑰 => 明文 - 對稱加密中用到的密鑰叫做私鑰,私鑰表示個人私有的密鑰,即該密鑰不能被泄露。 其加密過程中的私鑰與解密過程中用到的私鑰是同一個密鑰,這也是稱加密之所以稱之為“對稱”的原因。由于對稱加密的算法是公開的,所以一旦私鑰被泄露,那么密文就很容易被破解,所以對稱加密的缺點是密鑰安全管理困難。
- 非對稱加密:非對稱加密也叫做公鑰加密。非對稱加密與對稱加密相比,其安全性更好。對稱加密的通信雙方使用相同的密鑰,如果一方的密鑰遭泄露,那么整個通信就會被破解。而非對稱加密使用一對密鑰,即公鑰和私鑰,且二者成對出現。私鑰被自己保存,不能對外泄露。公鑰指的是公共的密鑰,任何人都可以獲得該密鑰。用公鑰或私鑰中的任何一個進行加密,用另一個進行解密。
- 被公鑰加密過的密文只能被私鑰解密, 過程如下:
明文 + 加密算法 + 公鑰 => 密文
密文 + 解密算法 + 私鑰 => 明文
被私鑰加密過的密文只能被公鑰解密,過程如下:
明文 + 加密算法 + 私鑰 => 密文
密文 + 解密算法 + 公鑰 => 明文 - 由于加密和解密使用了兩個不同的密鑰,這就是非對稱加密“非對稱”的原因。 非對稱加密的缺點是加密和解密花費時間長、速度慢,只適合對少量數據進行加密。 在非對稱加密中使用的主要算法有:RSA、Elgamal、Rabin、D-H、ECC(橢圓曲線加密算法)等。
參考博文:http