1.1 http的概念及歷史版本
http的概念: 超文本傳輸協(xié)議，當(dāng)年http的出現(xiàn)主要是為了解決文本傳輸?shù)碾y題。
http版本: HTTP/0.9、HTTP/1.0 、HTTP/1.1。其中HTTP/1.1是目前主流的HTTP協(xié)議版本。
1.2 TCP/IP
TCP/IP: 是互聯(lián)網(wǎng)相關(guān)的各類協(xié)議族的總稱。
TCP/IP協(xié)議族按層次分別分為以下四層: 應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層。
應(yīng)用層: 應(yīng)用層決定了向用戶提供應(yīng)用服務(wù)時通信的活動。TCP/IP協(xié)議族內(nèi)預(yù)存了各類通用的應(yīng)用服務(wù)。比如,FTP(文件傳輸協(xié)議)和DNS(域名系統(tǒng))服務(wù)就是其中兩類；HTTP協(xié)議也處于該層。
傳輸層: 傳輸層對上層應(yīng)用層提供處于網(wǎng)絡(luò)連接中的兩臺計算機之間的數(shù)據(jù)傳輸。傳輸層有兩個性質(zhì)不同的協(xié)議TCP和UDP。
網(wǎng)絡(luò)層: 網(wǎng)絡(luò)層是用來處理網(wǎng)上流動的數(shù)據(jù)包。數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚?shù)據(jù)單位。該層規(guī)定了通過怎樣的路徑到達對方的計算機(所謂的傳輸路線)，并把數(shù)據(jù)包傳給對方。與對方計算機之間通過多臺計算機或網(wǎng)絡(luò)設(shè)備進行傳輸時，網(wǎng)絡(luò)層所起的作用就是在眾多的選項內(nèi)選擇一條傳輸路徑。
鏈路層:用來處理連接網(wǎng)絡(luò)的硬件部分。包括控制操作系統(tǒng)、硬件的設(shè)備驅(qū)動、NIC(網(wǎng)絡(luò)適配器即網(wǎng)卡)，及光纖等物理可見部分。硬件上的范疇均在鏈路層的作用范圍之內(nèi)。
1.3 TCP/IP通信傳輸流
利用TCP/IP協(xié)議族進行網(wǎng)絡(luò)通信時，會通過分層順序與對方進行通信。發(fā)送端從應(yīng)用往下走，接受端則從應(yīng)用層往上走。
發(fā)送端在層與層之間傳輸數(shù)據(jù)時，每經(jīng)過一層時必定會被打上一個該層所屬的首部信息。反之，接受端在層與層傳輸數(shù)據(jù)時，每經(jīng)過一層時會把對應(yīng)的首部去掉。
1.4 與HTTP關(guān)系密切的協(xié)議IP、TCP和DNS
IP協(xié)議
IP協(xié)議:按層次分IP網(wǎng)際協(xié)議位于網(wǎng)絡(luò)層。TCP/IP協(xié)議族中的IP指的就是網(wǎng)級協(xié)議。 IP協(xié)議的作用是把各種數(shù)據(jù)包傳送給對方。
IP地址:指明節(jié)點被分配到的地址，可變換。
MAC地址:是指網(wǎng)卡所屬的固定地址，MAC地址基本不會更改。
使用ARP協(xié)議憑借MAC地址進行通信
IP間的通信依賴MAC地址。在網(wǎng)絡(luò)上，通信的雙方在同一局域網(wǎng)內(nèi)的情況很少，通常是經(jīng)過多臺計算機和網(wǎng)絡(luò)設(shè)備中轉(zhuǎn)才能連接到對方。而在進行中轉(zhuǎn)時，會利用下一站中轉(zhuǎn)設(shè)備的MAC地址來搜索下一個中轉(zhuǎn)目標(biāo)。這時，會采用ARP協(xié)議。ARP協(xié)議是一種以解析地址的協(xié)議，根據(jù)通信的雙方的IP地址就可以反查出對應(yīng)的MAC地址。
TCP協(xié)議
TCP協(xié)議:按層次分，TCP位于傳輸層，提供可靠的字節(jié)流服務(wù)。
字節(jié)流服務(wù)：為了方便傳輸，將大塊數(shù)據(jù)分割成報文段為單位的數(shù)據(jù)包進行管理。
TCP協(xié)議為了更容易傳送大數(shù)據(jù)才進行分割，而且TCP協(xié)議能夠確認數(shù)據(jù)最終是否送達到對方。
確保數(shù)據(jù)能到達目標(biāo)
為了準確無誤地將數(shù)據(jù)送達目標(biāo)處，TCP協(xié)議采用了三次握手策略。用TCP協(xié)議把數(shù)據(jù)包送出去后，TCP不會對傳送后的情況置之不理，它一定會向?qū)Ψ酱_認是是否成功送達。
三次握手的過程
握手過程中使用了TCP的標(biāo)志(flag)SYN和ACK。
發(fā)送端首先發(fā)送一個帶SYN標(biāo)志的數(shù)據(jù)包給對方。接受端收到后，回傳一個帶SYN/ACK標(biāo)志的數(shù)據(jù)包以示傳達確認信息。最后，發(fā)送端再回傳一個帶ACK標(biāo)志的數(shù)據(jù)包，代表“握手”結(jié)束。若在握手過程中某個階段莫名中斷，TCP協(xié)議會再次以相同的順序發(fā)送相同的數(shù)據(jù)包
DNS服務(wù)
DNS服務(wù):按層次分，位于應(yīng)用層的協(xié)議，它提供域名到IP地址之間的解析服務(wù)。
1.5 各種協(xié)議和HTTP協(xié)議的關(guān)系
2. HTTP協(xié)議
HTTP協(xié)議:HTTP協(xié)議和TCP/IP協(xié)議族內(nèi)的其他眾多的協(xié)議相同，用于客戶端和服務(wù)器之間的通信。
請求訪問文本或者圖像等資源的一端稱為客戶端，而提供資源響應(yīng)的一端稱為服務(wù)器端。
請求報文: 請求報文是由請求方法、請求URI、協(xié)議版本、可選的請求首部字段和內(nèi)容實體構(gòu)成的。
響應(yīng)報文:響應(yīng)報文基本上是由協(xié)議版本、狀態(tài)碼、用以解釋狀態(tài)碼的原因短語、可選的響應(yīng)首部字段以及實體主體構(gòu)成。
2.1 HTTP是不保存狀態(tài)的協(xié)議
HTTP是一種不保存狀態(tài)，即無狀態(tài)協(xié)議。HTTP協(xié)議自身不對請求和響應(yīng)之間的通信狀態(tài)進行保存。也就是說在HTTP這個級別，協(xié)議對于發(fā)送過的請求或者響應(yīng)都不做持久化處理。
2.2請求URI定位資源
HTTP協(xié)議使用URI定位互聯(lián)網(wǎng)上的資源。當(dāng)客戶端請求訪問資源而發(fā)送請求是，URI需要將作為請求報文包含在內(nèi)。
請求URI的方式
a. URI為完整的請求URI
b.在首部字段Host中寫明網(wǎng)絡(luò)域名或者IP地址
2.3 HTTP請求的方法
- GET: 獲取資源
- POST: 傳輸實體
- PUT: 傳輸文件
- HEAD: 獲得報文首部
- DELETE: 刪除文件
- OPTION: 詢問支持的方法
2.4 持久連接節(jié)省通信量
HTTP協(xié)議的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接。
持久連接
為了解決TCP連接問題，HTTP/1.1和一部分的HTTP/1.0想出了持久連接(也稱為HTTP keep-alive)的方法。持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態(tài)。
持久連接旨在建立1次TCP連接后進行多次請求和響應(yīng)的交互
持久連接的優(yōu)點: 減少TCP連接的重復(fù)建立和斷開所造成的額外開銷，減輕服務(wù)器的負載。另外，減少開銷的那部分時間，使HTTP請求和響應(yīng)能夠更早結(jié)束，這樣客戶端響應(yīng)的速度也提高了。
2.5 管線化
持久連接使得多數(shù)請求以管線化方式發(fā)送成為可能。從前發(fā)送請求后需要等待并收到響應(yīng)，才能發(fā)送下一個請求。管線化技術(shù)出現(xiàn)后，不用等待響應(yīng)也可以直接發(fā)送下一個請求。
2.6 使用cookie的狀態(tài)管理
Cookie:Cookie技術(shù)是通過在請求和響應(yīng)報文中寫入Cookie信息來控制客戶端的狀態(tài)。
Cookie保存客戶端狀態(tài)的具體過程:
Cookie會根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報文內(nèi)的一個叫Set-Cookie的首部字段信息，通知客戶端保存Cookie。當(dāng)客戶端再往該服務(wù)器發(fā)送請求時，客戶端會在動在請求報文中加入Cookie值后發(fā)送出去。服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的Cookie后，會去檢查究竟是從那一個客戶端發(fā)送過來的連接請求，然后對比服務(wù)器上的記錄，最后得到之前的狀態(tài)。
-
沒有Cookie信息狀態(tài)下的請求
截圖16.png -
第2次以后(存有cookie信息狀態(tài))的請求
截圖17.png
(1) 請求報文 (沒有Cookie信息狀態(tài))
(2) 響應(yīng)報文(服務(wù)器端生成Cookie信息)
(3)請求報文 (自動發(fā)送保存著的Cookie信息)
3.1 HTTP報文
用于HTTP協(xié)議交互的信息被稱為HTTP報文。請求端(客戶端)的HTTP報文叫做請求報文，響應(yīng)端(服務(wù)器端)的叫做響應(yīng)報文。HTTP報文本身是由多行(用CR+LF作換行符)數(shù)據(jù)構(gòu)成的字符串文本。HTTP報文大致可分為報文首部和報文主體兩塊。兩者由最初出現(xiàn)的空行(CR+LF)來劃分。通常，并不一定有報文主體。
3.2請求報文及響應(yīng)報文的結(jié)構(gòu)
圖：請求報文(上)和響應(yīng)報文(下)的結(jié)構(gòu)
圖: 請求報文(上)和響應(yīng)報文(下)的實例
請求行:包含用于請求的方法，請求URI和HTTP版本。
狀態(tài)行:包含表明響應(yīng)結(jié)果的狀態(tài)碼，原因短語和HTTP版本。
首部字段:包含表示請求和響應(yīng)的各種條件和屬性的各類首部。
一般有4種首部，分別是：通用首部、請求首部、響應(yīng)首部、和實體首部。
4.1返回結(jié)構(gòu)的HTTP狀態(tài)碼
2XX的響應(yīng)結(jié)構(gòu)表明請求被正常處理了。
3XX的響應(yīng)結(jié)果表明瀏覽器需要執(zhí)行某些特殊的處理以正確處理請求。(重定向)
4XX的響應(yīng)結(jié)果表明客戶端是發(fā)生錯誤的原因所在。
5XX的響應(yīng)結(jié)果表明服務(wù)器本身發(fā)生錯誤。
5.1 HTTP常用的首部字段
HTTP首部字段是由首部字段名和字段值構(gòu)成的，中間用冒號“:”分隔
首部字段名：字段值
例如:
Content-Type: text/html
另外，字段值對應(yīng)單個HTTP首部字段可以有多個值，例如
Keep-Alive: timeout=15, max = 100
6. HTTPS相關(guān)
在HTTP協(xié)議中有可能存在信息竊聽或身份偽裝等安全問題。使用HTTPS通信機制可以有效地防止這些問題。
HTTP的缺點:
- 通信使用明文(不加密)，內(nèi)容可能被竊聽
- 不驗證通信方的身份，因此有可能遭遇偽裝
- 無法證明報文的完整性，所以有可能已遭篡改
我們把添加了加密及認證機制的HTTP稱為HTTPS。
HTTP + 加密 + 認證 + 完整性保護 = HTTPS
7.1 HTTPS是身披SSL外殼的HTTP
HTTPS并非是應(yīng)用層的一種新協(xié)議。只是HTTP通信接口部分使用SSL和TLS協(xié)議代替而已。
通常，HTTP直接和TCP通信。當(dāng)使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信了。簡而言之，所謂HTTPS，其實就是身披SSL協(xié)議這層外殼的HTTP。
在采用了SSL后，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。
SSL采用一種叫做公開密鑰加密的加密處理方式
共享密鑰加密
加密和解密同用一個密鑰的方式稱為共享密鑰加密,也被叫做對稱密鑰加密。這種加密方式有兩個問題一個是密鑰在發(fā)送過程中會被竊取還有就是密鑰的保存問題。
公開密鑰加密
公開密鑰加密使用一對非對稱密鑰。一把叫做私有密鑰，另一把叫做公開密鑰。使用公開密鑰加密方式，發(fā)送密鑰的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息后，再使用自己的私有密鑰進行解密。
HTTPS采用混合加密機制
HTTPS采用共享密鑰加密和公開密鑰加密兩者混合并用的混合加密機制。在密鑰交換環(huán)節(jié)使用公開密鑰加密方式，之后的建立通信交換報文階段則使用共享密鑰加密方式。
7.2 證明公開密鑰正確性的證書。
為了解決公開密鑰在傳輸過程中，真正的公開密鑰被攻擊者替換掉，可以使用由數(shù)字證書認證機構(gòu)和相關(guān)頒發(fā)的公開密鑰證書。
數(shù)字證書
數(shù)字證書認證機構(gòu)處于客戶端與服務(wù)器雙方都可信賴的第三方認證機構(gòu)的立場上。
數(shù)字證書認證機構(gòu)的業(yè)務(wù)流程
首先，服務(wù)器的運營人員向數(shù)字證書認證機構(gòu)提出公開密鑰的申請，數(shù)字證書認證機構(gòu)在判明提出申請者的身份之后，會對已申請的公開密鑰做數(shù)字簽名，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公鑰證書后綁定在一起。
服務(wù)器會將這份由數(shù)字證書認證機構(gòu)頒發(fā)的公鑰證書發(fā)送給客戶端，以進行公開密鑰加密方式通信。公鑰證書也可以叫做數(shù)字證書或者直接稱為證書。
接到證書的客戶端可使用數(shù)字證書認證機構(gòu)的公開密鑰，對那張證書上的數(shù)字簽名進行驗證，一旦驗證通過，客戶端便可以明確兩件事：一、認證服務(wù)器的公開密鑰是真實有效的數(shù)字證書認證機構(gòu)。二、服務(wù)器的公開密鑰是值得信賴的。
7.3 HTTPS的安全通信機制
步驟1: 客戶端通過發(fā)送Client Hello 報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本、加密組件列表(所使用的加密算法及密鑰長度)
步驟2: 服務(wù)器可進行SSL通信時，會以Server Hello 報文作為應(yīng)答。和客戶端一樣，在報文中包含SSL版本及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的。
步驟3: 之后服務(wù)器發(fā)送Certificate報文。報文中包含公開密鑰證書。
步驟4: 最后服務(wù)器發(fā)送Server Hello Done報文通知客戶端，最初階段的SSL握手協(xié)商部分結(jié)束。
步驟5: SSL第一次握手結(jié)束之后，客戶端以Client Key Exchange報文最為回應(yīng)。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文已用步驟3中的公開密鑰進行加密。
步驟6：接著客戶端繼續(xù)發(fā)送Change Cipher Spec報文。該報文會提示服務(wù)器，在此報文之后的通信會采用Pre-master secret密鑰加密。
步驟7: 客戶端發(fā)送Finished報文。該報文包含連接至今全部報文的整體校驗值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠真確解密該報文作為判斷標(biāo)準。
步驟8: 服務(wù)器同樣發(fā)送Change Cipher Spec 報文。
步驟9: 服務(wù)器同樣發(fā)送Finished 報文。
步驟10: 服務(wù)器和客戶端的Finished報文交換完畢之后，SSL連接就算建立完成。當(dāng)然，通信會受到SSL的保護。從此處開始進行應(yīng)用層協(xié)議通信。即發(fā)送HTTP請求。
步驟11: 應(yīng)用層協(xié)議通信，即發(fā)送HTTP響應(yīng)。
步驟12: 最后由客戶端斷開連接。斷開連接時，發(fā)送close_nofity報文。這步之后再發(fā)送TCP FIN 報文來關(guān)閉與TCP的通信。
以上流程中，應(yīng)用層發(fā)送數(shù)據(jù)時會附加一種叫做MAC的報文摘要。MAC能夠查知報文是否遭到篡改，從而保護報文完整性。
SSL速度慢嗎？
SSL的慢分兩種。一種是指通信慢。另一種是指由于大量消耗CPU及內(nèi)存等資源，導(dǎo)致處理速度變慢。和使用HTTP相比，網(wǎng)絡(luò)負載可能會變慢2到100倍。除去和TCP連接，發(fā)送HTTP請求響應(yīng)外，還必須進行SSL通信，因此整體上處理通信量不可避免會增加。
另一點是SSL必須進行加密處理。服務(wù)器和客戶端都需要進行加密和解密的運算處理。因此從結(jié)果上講，比起HTTP會更多地消耗服務(wù)器和客戶端的硬件資源，導(dǎo)致負載增強。
為什么不一直使用HTTPS?
其中一個原因是，因為與純文本通信相比，加密通信會消耗更多的CPU及內(nèi)存資源。如果每次通信都加密，會消耗相當(dāng)多的資源，平攤到一臺計算機上時，能夠處理的請求數(shù)量必定也會隨之減少。因此如果是非敏感信息則使用HTTP通信，只有在包含個人信息等敏感數(shù)據(jù)時，才利用HTTPS加密通信。
