1.1 http的概念及歷史版本
http的概念: 超文本傳輸協(xié)議，當年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)目標他炊。這時争剿，會采用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ù)能到達目標
為了準確無誤地將數(shù)據(jù)送達目標處履恩，TCP協(xié)議采用了三次握手策略锰茉。用TCP協(xié)議把數(shù)據(jù)包送出去后呢蔫，TCP不會對傳送后的情況置之不理切心，它一定會向?qū)Ψ酱_認是是否成功送達飒筑。
三次握手的過程
握手過程中使用了TCP的標志(flag)SYN和ACK。
發(fā)送端首先發(fā)送一個帶SYN標志的數(shù)據(jù)包給對方绽昏。接受端收到后协屡，回傳一個帶SYN/ACK標志的數(shù)據(jù)包以示傳達確認信息。最后全谤，發(fā)送端再回傳一個帶ACK標志的數(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)上的資源师抄。當客戶端請求訪問資源而發(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甸私。當客戶端再往該服務(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通信澎粟。當使用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ù)器是否能夠真確解密該報文作為判斷標準。
步驟8: 服務(wù)器同樣發(fā)送Change Cipher Spec 報文堵幽。
步驟9: 服務(wù)器同樣發(fā)送Finished 報文狗超。
步驟10: 服務(wù)器和客戶端的Finished報文交換完畢之后，SSL連接就算建立完成谐檀。當然抡谐，通信會受到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)存資源药磺。如果每次通信都加密告组，會消耗相當多的資源，平攤到一臺計算機上時癌佩，能夠處理的請求數(shù)量必定也會隨之減少木缝。因此如果是非敏感信息則使用HTTP通信，只有在包含個人信息等敏感數(shù)據(jù)時围辙，才利用HTTPS加密通信我碟。
