計算機網(wǎng)絡系列文章匯總

主要講述HTTPS的安全性原理臂港、加密過程屑柔，以及對稱加密和非對稱加密的各種加密算法烈钞，最后會分析HTTP和HTTPS的區(qū)別

主要內(nèi)容：

1. HTTP的認識
2. HTTPS的認識
3. 對稱加密和非對稱加密的認識
4. SSL/TLS協(xié)議
5. HTTP和HTTPS的區(qū)別

1先匪、HTTP的認識

HTTP(Hyper Transfer Protocol)超文本傳輸協(xié)議，是一個應用層協(xié)議你弦，基于TCP鏈接進行可靠傳輸惊豺，客戶端向服務器發(fā)送請求報文，服務器端回復響應報文進行一次通話

1.1 請求響應過程

請求響應.png

1. 每個萬維網(wǎng)網(wǎng)點都有一個服務器進程禽作，它不斷地監(jiān)聽 TCP 的端口 80尸昧，以便發(fā)現(xiàn)是否有瀏覽器向它發(fā)出連接建立請求。
2. 一旦監(jiān)聽到連接建立請求并建立了 TCP 連接之后旷偿，瀏覽器就向萬維網(wǎng)服務器發(fā)出瀏覽某個頁面的請求烹俗，服務器接著就返回所請求的頁面作為響應。

1.2 長短連接

• 長連接和短連接是針對運輸層的萍程，并非應用層幢妄，但是http是基于TCP的
• 長連接就是在建立TCP的通信連接后并且完成這一次的HTTP請求信息的交互后不會立即釋放連接，而是會繼續(xù)保持連接狀態(tài)茫负，等待這個端口的其他http請求的使用蕉鸳。因為一個tcp協(xié)議最終通過主機的端口來查找應用進程，所以只有相同應用進程的HTTP請求才會復用這個長連接。并且會有一個背背ⅲ活時間榕吼，保活時間到了之后會關閉TCP連接
• 而短連接在http的一次請求結(jié)束后就斷開TCP連接勉失。
• HTTP1.1協(xié)議以后羹蚣，連接默認都是長連接
• 長連接可以在多請求的場景中使用
• 如果一次請求就會結(jié)束就使用短連接

1.3 使用

在網(wǎng)絡中使用統(tǒng)一資源定位符URL來查找
應用層協(xié)議都要在URL中寫明

URL.png

1.4 請求方式（簡述）

分別是增刪改查
POST：

• 對服務器數(shù)據(jù)進行修改（增加）
• 需要發(fā)送body數(shù)據(jù)，增加的數(shù)據(jù)放在body中

DELETE：

• 用于刪除服務器資源
• 不需要發(fā)送body數(shù)據(jù)

PUT：

• 修改服務器資源使用
• 發(fā)送給服務器的數(shù)據(jù)在body中

GET：

• 一般用于獲取資源
• 不需要發(fā)送body數(shù)據(jù)
• 不對服務器數(shù)據(jù)進行修改

1.5 Request Status Code 狀態(tài)碼

• 1xx：臨時性消息戴质。如：100 （繼續(xù)發(fā)送）度宦、101（正在切換協(xié)議）
• 2xx：成功。最典型的是 200（OK）201（創(chuàng)建成功）
• 3xx：重定向告匠。如 301（永久移動）戈抄、302（暫時移動）、304（內(nèi)容未改變）
• 4xx：客戶端錯誤后专。如 400（客戶端請求錯誤）划鸽、401（認證失敗）戚哎、403（被禁?）裸诽、404（找不到內(nèi)容）
• 5xx：服務器錯誤。如 500（服務器內(nèi)部錯誤）

2型凳、HTTPS詳解

HTTPS是在HTTP的基礎上增加了一個安全層丈冬，SSL/TLS層可以看做處在運輸層和應用層中間，可以對數(shù)據(jù)進行加密后供應用層使用

詳細過程下面會說明

3甘畅、加密算法的理解

HTPP協(xié)議有一個致命的缺點就是不夠安全埂蕊，HTTP協(xié)議的信息傳輸完全以明文方式，不做任何加密疏唾，很容易被中間人惡意截獲甚至篡改蓄氧，因此需要采用加密技術對明文加密后再傳輸，總的來說有兩種加密方式槐脏，對稱加密和非對稱加密喉童，下面就分別來看。

3.1 對稱加密

對稱加密就是通信雙方先約定一個接下來要使用的密鑰顿天，后續(xù)的通信中堂氯，信息發(fā)送方都使用密鑰對信息加密，而信息接收方通過同樣的密鑰對信息解密牌废。

過程：

1. 客戶端在向服務端發(fā)送連接請求咽白，服務端的確認請求連接中需要帶上一個隨機生成的秘鑰
2. 客戶端接收到密鑰后，發(fā)送信息時需要將明文通過密鑰加密后再發(fā)送給服務端
3. 服務端接收到加密后的信息后通過密鑰進行解密畔规，就可以得到信息了。

缺點：

• 此時并不一定安全
• 雖然我們在后續(xù)的通信中對明文進行了加密恨统，但是第一次約定加密方式時進行通信的密鑰仍然是明文
• 如果第一次通信就已經(jīng)被攔截了叁扫，那么密鑰就會泄露給中間人三妈，中間人仍然可以解密后續(xù)所有的通信內(nèi)容。

解決：

• 針對密鑰的傳遞也是明文的莫绣，我們就需要在傳遞密鑰時對密鑰也進行加密畴蒲，這就是非對稱加密

3.2 非對稱加密

在對稱加密的第一次約定加密方式通信過程中有可能被中間人截獲，中間人獲取到密鑰后可以自行加密解密对室。所以這種方式并不安全模燥，需要使用非對稱加密，為密鑰的傳輸做一層額外的保護掩宜。

非對稱加密的一組秘鑰對中蔫骂，包含一個公鑰和一個私鑰。明文既可以用公鑰加密牺汤，用私鑰解密辽旋；也可以用私鑰加密，用公鑰解密檐迟。本文以公鑰加密补胚，私鑰解密為例。

過程：

1. 客戶端向服務端發(fā)送連接請求時追迟，服務端先返回一個公鑰
2. 客戶端收到公鑰后溶其，自己生成一個密鑰，并用收到的公鑰對密鑰進行加密敦间。
3. 客戶端將加密后的密鑰發(fā)送給服務端瓶逃，服務端使用私鑰進行解密，就可以拿到密鑰
4. 此時客戶端和服務端都有相同的密鑰每瞒，后續(xù)就可以使用這個密鑰來進行加密和解密了金闽。
5. 因為密鑰的傳輸是通過公鑰來加密的，而用來解密的私鑰并不會傳輸剿骨，所以外界無法截取到私鑰代芜，也就無法破解拿到密鑰了。

缺點：

• 這種情況還是不一定安全
• 因為中間人雖然無法獲取私鑰浓利，但是截獲公鑰挤庇。
• 中間人先創(chuàng)建自己的公鑰和私鑰，當服務端給客戶端發(fā)送公鑰時贷掖，中間人截獲后把自己的公鑰發(fā)送給客戶端嫡秕。
• 下次客戶端返回被公鑰加密后的秘鑰后，中間人再次截獲到就可以用自己的私鑰來解密了苹威。同時再將解密后的秘鑰再用客戶端的公鑰加密后發(fā)送給服務端昆咽。
• 這樣就神不知鬼不覺的拿到了密鑰

解決：

• 基于公鑰被截獲后，客戶端會以中間人的公鑰來加密造成的問題。想要解決就需要讓客戶端可以識別出服務器端的公鑰掷酗。如果驗證失敗說明是中間人的公鑰而不會進行通信了调违。
• 但是客戶端與服務端尚未進行通信，如何能夠識別呢泻轰，這就需要引入第三方了技肩，一個權威的證書頒發(fā)機構（CA）來解決。通過約定的第三方的信息就可以認證了浮声。下面就是開始分析CA證書流程

3.3 CA證書

在非對稱加密中仍然有可能被破解虚婿，因此需要引入第三方驗證公鑰。服務端通過第三方獲取到證書后泳挥，向客戶端發(fā)送證書然痊，客戶端也通過第三方信息驗證證書就可以獲取到密鑰。

證書（簡化后）：

證書內(nèi)容.png

• 證書頒發(fā)機構羡洁、服務端網(wǎng)址玷过、經(jīng)過機構私鑰加密的服務端公鑰，經(jīng)過機構私鑰加密的證書前面
• 證書簽名是通過服務端網(wǎng)址等服務端的一些信息生成的
• 這些信息會在客戶端解析驗證筑煮，以此確認是否被中間人攻擊

過程：

1. 服務端發(fā)送公鑰給證書頒發(fā)機構申請證書
2. 證書頒發(fā)機構通過自己的私鑰對服務端公鑰進行加密辛蚊，并且通過服務端網(wǎng)址等信息生成一個證書簽名，證書簽名同樣經(jīng)過機構的私鑰加密真仲。證書制作完成后袋马，機構把證書發(fā)送給了服務端
3. 當客戶端向服務端請求通信時，服務端不再直接返回自己的公鑰秸应，而是把自己申請的證書返回客戶端
4. 客戶端收到證書后虑凛，首先驗證證書的真?zhèn)危笕〕龇斩说墓€
   1. 客戶端按照同樣的簽名規(guī)則软啼，自己也生成一個證書簽名桑谍，如果兩個簽名一致，說明證書是有效的祸挪。
   2. 驗證成功后锣披，再次利用機構公鑰，解密出服務端的公鑰
   3. 需要說明的是：各大瀏覽器和操作系統(tǒng)已經(jīng)維護了所有權威證書機構的名稱和公鑰贿条。因此在客戶端本地就可以創(chuàng)建簽名和解密雹仿。
5. 客戶端拿到服務端的公鑰后，再對自己的密鑰進行加密后發(fā)送給服務端整以。
6. 最后服務端拿到加密后的公鑰后胧辽，使用自己的私鑰進行解密得到客戶端的密鑰
7. 接下來就可以使用密鑰加密通信了

安全性分析：
此時如果中間人自己創(chuàng)建證書后，截獲服務端證書公黑，并將自己的證書發(fā)給客戶端邑商，是否可以欺騙客戶端呢摄咆？

• 不可以
• 因為證書的簽名是通過服務端網(wǎng)址等信息生成的
• 并且經(jīng)過機構私鑰加密，中間人也無法篡改
• 所以自己創(chuàng)建的證書是無法通過客戶端的驗證的

4人断、SSL協(xié)議工作原理

SSL協(xié)議其實就是使用了上面分析的對稱加密和非對稱加密的的一種協(xié)議豆同。處于運輸層以上，應用層以下含鳞，用來做一層安全防護（當然其實是邏輯的一層，并不是真實的）

原理： 先通過非對稱加密方式約定好密鑰芹务，之后再通過對稱加密方式使用密鑰對明文加密傳輸數(shù)據(jù)

SSL層所在位置.png

加密過程：

SSL協(xié)議加密過程.png

說明：

1. 分為兩個情況蝉绷，第一個是SSL握手，第二個是實際的數(shù)據(jù)傳輸
2. SSL握手是通過非對稱加密來實現(xiàn)的
3. 實際的數(shù)據(jù)傳輸需要使用對稱加密來傳輸?shù)?/li>

SSL握手：

SSL握手.png

說明：

1枣抱、客戶機發(fā)送一條“客戶機hello”消息熔吗。消息里包括了客戶機的SSL版本號、密碼設置佳晶、會話相關數(shù)據(jù)以及其他信息桅狠。
2、服務器發(fā)送一條“服務器hello”響應消息轿秧。消息里包括了服務器的SSL版本號中跌、密碼設置、會話相關數(shù)據(jù)菇篡、帶有公鑰的SSL證書以及其他信息漩符。
3、客戶機從CA(Certificate Authority/證書頒發(fā)機構)驗證服務器的SSL證書驱还，并對服務器進行身份驗證嗜暴。如果身份驗證失敗，則客戶機拒絕SSL連接并拋出異常议蟆。如果身份驗證成功闷沥，則繼續(xù)執(zhí)行步驟4。
4咐容、客戶機創(chuàng)建一個會話密鑰舆逃，用服務器的公鑰加密它并將其發(fā)送到服務器。如果服務器請求驗證客戶機身份(主要是在服務器到服務器通信中)疟丙，則客戶機將自己的證書發(fā)送給服務器颖侄。
5、服務器使用其私鑰解密會話密鑰享郊，并將確認消息（使用會話密鑰加密）發(fā)送給客戶機览祖。
6、在SSL握手結(jié)束時炊琉，客戶機和服務器都有一個有效的會話密鑰展蒂，它們將使用該密鑰加密或解密實際數(shù)據(jù)又活。此后將不再使用公鑰和私鑰。

數(shù)據(jù)傳輸：

加密會話.png

說明：

1. 客戶機和服務器現(xiàn)在使用共享的會話密鑰對實際的傳輸數(shù)據(jù)進行加密和解密锰悼，這里使用的是對稱加密柳骄，對稱加密的優(yōu)點是簡單，消耗資源少箕般。
2. 因此耐薯，SSL基本上使用非對稱加密和對稱加密。在現(xiàn)實生活中丝里，實現(xiàn)SSL通信涉及到某些基礎設施曲初，這些基礎設施稱為公鑰基礎設施。

5杯聚、HTTP和HTTPS的區(qū)別

• 根本區(qū)別在于HTTPS在HTTP的基礎上對數(shù)據(jù)進行了加密臼婆，通過SSL/TLS協(xié)議來進行加密
• SSL/TLS可以視作一層處在運輸層和應用層之間，而HTTPS比HTTP多了這么一層進行安全加密