1、對稱加密
1、什么是對稱加密？
對稱加密就是指，加密和解密使用同一個密鑰的加密方式。需要用到的有加密算法和加密秘鑰。例如加密算法可以類似這樣的加密規則(a ->b，b->w，c->a)
2、對稱加密的工作過程
發送方使用密鑰將明文數據加密成密文，然后發送出去，接收方收到密文后，使用同一個密鑰將密文解密成明文讀取。
3、對稱加密的優點 和 缺點
優點：加密計算量小、速度快，效率高，適合對大量數據進行加密的場景。
缺點：（1）密鑰不適合在網上傳輸（容易被截取），（2）密鑰維護麻煩
4、常見的對稱加密算法
DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES。
5、數據加密標準DES
數據加密標準DES屬于常規密鑰密碼體制，是一種分組密碼。加密前，先對整個明文進行分組，每一組長為64位，然后對每一個64位二進制數據進行加密處理，產生一組64位密文數據。最后將各組密文串接起來，即得出整個的密文。使用的密鑰為64位（實際密鑰長度為56位，有8位用于奇偶檢驗）
DES的保密性取決于密鑰的保密，而算法是公開的。盡管人們在破譯DES方面取得了許多進展，但至今仍未能找到比窮舉搜索密鑰更有效的方法。DES是世界上第一個公認的實用密碼算法標準，它曾對密碼學的發展做出了重大貢獻。目前較為嚴重的問題是DES的密鑰長度，現在已經設計出搜索DES密鑰的專用芯片。
DES算法安全性取決于密鑰長度，56位密鑰破解需要3.5到21分鐘，128位密鑰破解需要5.4 * 10^18次方年
注意的是：這里是沒有密鑰的情況下，直接窮舉密鑰嘗試破解。如果密鑰在傳送過程中被人截取了，就相當于直接知道加密規則了，根本不需要破解，因此密鑰在網絡中傳送還是不安全。
2、非對稱加密
1、什么是非對稱加密？
與對稱加密算法不同，非對稱加密算法需要密鑰對，即兩個密鑰：公開密鑰（公鑰）和私有密鑰（私鑰）。
公開密鑰與私有密鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；如果用私有密鑰對數據進行加密，那么只有用對應的公開密鑰才能解密。因為加密和解密使用的是兩個不同的密鑰，所以這種算法叫作非對稱加密算法。
公鑰和私鑰是怎么來的？
操作系統隨機生成一個隨機數，將這個隨機數通過某個函數進行運算，分成兩部分，公鑰和私鑰
2、非對稱加密的工作過程
- A要向B發送信息，A和B都要產生一對用于加密和解密的公鑰和私鑰。
- A的私鑰保密，A的公鑰告訴B；B的私鑰保密，B的公鑰告訴A。
- A要給B發送信息時，A用B的公鑰加密信息，因為A知道B的公鑰。
- A將這個消息發給B（已經用B的公鑰加密消息）。
- B收到這個消息后，B用自己的私鑰解密A的消息，其他所有收到這個報文的人都無法解密，因為只有B才有B的私鑰。
- 反過來，B向A發送消息也是一樣。
3、非對稱加密的優點 和 缺點
優點：安全性高
缺點：加密與解密速度慢。
4、常見的非對稱加密算法
RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）。
5、為什么把公鑰給了別人，而私鑰一定要保存好，能不能給那個人發信息的時候也用私鑰加密
答案是不能
鑒于非對稱加密的機制，我們可能會有這種思路：服務器先把公鑰直接明文傳輸給瀏覽器，之后瀏覽器向服務器傳數據前都先用這個公鑰加密好再傳，這條數據的安全似乎可以保障了！因為只有服務器有相應的私鑰能解開這條數據。
然而由服務器到瀏覽器的這條路怎么保障安全？如果服務器用它的的私鑰加密數據傳給瀏覽器，那么瀏覽器用公鑰可以解密它，而這個公鑰是一開始通過明文傳輸給瀏覽器的，這個公鑰被誰劫持到的話，他也能用該公鑰解密服務器傳來的信息了。所以目前似乎只能保證由瀏覽器向服務器傳輸數據時的安全性（其實仍有漏洞，下文會說）。
3、混合加密
1、先通過非對稱加密技術，把對稱加密的密鑰X傳給對方，使得這個對稱加密的密鑰X是安全的
2、后面再通過對稱加密技術進行數據傳輸
詳細流程
（1）服務器端擁有用于非對稱加密的公鑰A、私鑰A’。
（2）客戶端向網站服務器請求，服務器先把公鑰A明文給傳輸瀏客戶端
（3）客戶端隨機生成一個用于對稱加密的密鑰X，用公鑰A加密后傳給服務器端。
（4）服務器端拿到后用私鑰A’解密得到密鑰X。
（5）這樣雙方就都擁有密鑰X了，且別人無法知道它。之后雙方所有數據都用密鑰X加密解密。
4、數字簽名
數字簽名是基于公鑰密碼體制（非對稱密鑰密碼體制）的。
1.1.基本特征
數字簽名必須保證以下三點：
- 報文鑒別——接收者能夠核實發送者對報文的簽名；
- 報文的完整性——接收者不能偽造對報文的簽名或更改報文內容。
- 不可否認——發送者事后不能抵賴對報文的簽名；
1.2.數字簽名的驗證過程
上圖位用戶A使用數字簽名向用戶B傳輸一份文件的過程：
首先，文件經過單向散列函數的處理得到一份占128位的摘要（無論文件多大，經過單向散列函數的處理，生成的摘要都是128位），這份摘要相當于該文件的"指紋"，能夠唯一地識別文件。注意：只要文件發生改動，經過單向散列函數處理后得到地摘要都會不一樣。所以，文件和文件的摘要具有很強的對應關系。
隨后，用戶A使用自己地私鑰對這份128位地摘要進行加密，得到一份加密地摘要。
然后，用戶A把文件、加密的摘要和公鑰打包一起發給用戶B。傳輸的過程中并沒有對文件進行加密處理。
用戶B將收到的文件經過單向散列函數處理得出一份128位摘要，這份摘要是通過收到的文件得到的，存在被更改的可能；使用A提供的公鑰對收到的"加密的摘要"進行解密得到另一份128位摘要，這份摘要是通過原始文件得到的，一般認為代表真正的文件；然后將兩份摘要進行比較。
如果兩份摘要相等，說明文件經過用戶A簽名之后，在傳輸的過程中沒有被更改；若不相等，說明文件在傳輸過程中被更改了，或者說已經不是原來的文件了，此時用戶A的簽名失效。
數字簽名三個特征的驗證
- 不可否認——只有用戶A擁有私鑰A，并能使用私鑰A產生"加密的摘要"，這樣用戶A就不能否認給用戶B發送了經過簽名的密文。
- 報文的完整性——用戶B通過比較得出的兩份摘要是否相等，可以判斷簽名或文件內容是否發生改變。
- 報文鑒別——用戶B可以使用收到的公鑰對"加密的摘要"進行解密，從而核實用戶A對文件的簽名。
需要強調
- 用戶A使用私鑰對由文件生成的128位摘要進行加密的過程稱為數字簽名的過程，得到的"加密的摘要"，稱為該文件的數據簽名。
- 用戶A使用私鑰加密的是摘要而不是文件。
- 用戶B驗證簽名實際上是比較得出的兩份摘要是否相等。
1.3.數字簽名使用的場合
什么時候使用這種不對文件加密，而對文件的摘要加密（對文件進行簽名）的技術呢？
- 數字簽名解決的核心問題是：確保收到的文件沒有被更改。
- 比如：公司的領導給員工下發放假通知，這時候就需要對郵件進行數字簽名來證明這個通知是領導發的。員工收到通知，看到上面有領導的簽名，于是就可以放心休假了。如果有人冒充領導發通知，上面沒有領導的簽名，員工休假回來就要扣工資。同樣的，通知有了領導的簽名，領導想抵賴也不行。
5、證書頒發機構CA
1.1CA簡介
證書頒發機構，即認證中心CA (Certification Authority)，來將公鑰與其對應的實體（人或機器）進行綁定(binding)；即給公司或個人頒發證書。
-
認證中心一般由政府出資建立。每個實體都有CA 發來的證書(certificate)，里面有公鑰及其擁有者的標識信息。此證書被 CA 進行了數字簽名。任何用戶都可從可信的地方獲得認證中心 CA 的公鑰，此公鑰用來驗證某個公鑰是否為某個實體所擁有。有的大公司也提供認證中心服務。
image.png
如圖所示，用戶A使用數字簽名時給用戶B發送了一個數據包，數據包中包含了A的公鑰、文件和加密的摘要。那么問題來了：用戶B如何確定收到的公鑰是用戶A發送的，而不是他人冒充用戶A發送的呢？- 舉個例子：把用戶A的公鑰和私鑰假設為身份證。如果是用戶A自己造的身份證別人會信嗎？反之，用戶A拿著真正的身份證去住賓館，老板一開始也不相信身份證是用戶A的，但是老板相信給用戶A發身份證的公安局，老板通過比對公安網上對應身份證號碼的信息就可以判斷這個身份證是不是用戶A的，由此可以確認用戶A的身份。
- 同理，B一開始并不確認收到的公鑰是來自用戶A的，用戶A也可抵賴B收到的公鑰不是自己發送的。這時就需要有一個雙方都信任的第三方證書頒發機構來協調。
1.2.證書頒發和使用過程
首先，用戶A向證書頒發機構提交個人信息，申請證書。通過CA審核后，CA生成用戶A的證書，證書中包括了A的公鑰和私鑰還有CA的數字簽名。證書頒發機構CA本身擁有一對密鑰，這是對CA所頒發的證書進行數字簽名和保密的基礎，絕不能泄露。
用戶A收到的證書中包括了帶有CA數字簽名的，專屬A公鑰和私鑰，CA的數字簽名確保了別人不能偽造用戶A的公鑰和私鑰。
同時，用戶B也必須信任給用戶A頒發證書的第三方認證機構CA，即用戶B擁有CA頒發的"CA公鑰"。
通信時，用戶A向用戶B發送的數據包中的"加密的摘要"上有用戶A的數字簽名，“A公鑰” 上有認證機構CA的數字簽名。用戶B收到數據包之后，先要驗證收到的 “A公鑰” 是否來源合法：是認證機構頒發的帶有CA簽名的公鑰嗎？用戶B并不信任用戶A，但是用戶B信任第三方認證機構CA。所以，用戶B先使用證書頒發機構頒發的 "CA公鑰" 驗證收到的 "A公鑰" 是否由同一認證機構頒發，是否在頒發之后更改過。
驗證通過后，用戶B便相信收到的 "A公鑰" 確實來自真實的用戶A。隨后再使用 "A公鑰" 對 "加密的摘要" 進行解密，進行上文提到的對比操作，以判斷文件是否更改。
注意：這里強調的是只有“A公鑰” 上有認證機構CA的數字簽名，意思是CA用它的私鑰對“A公鑰”的內容進行單向散列函數得到的加密摘要（數字簽名），該簽名放在“A公鑰”中（左上角那個），對于B用戶來說，它從可靠的路徑拿到CA的公鑰，使用CA的公鑰解密“A公鑰”的內容得到的128位的摘要 和 “A公鑰”的內容通過單向散列函數計算出來的是否一致，如果是表示認可這個“A公鑰”
1.4.證書的吊銷
當用戶A遺失或泄露了CA頒發的證書后，為了避免他人使用該證書冒充用戶A，用戶A向認證機構CA "掛失" 該證書。于是認證機構CA把該證書放入該認證機構的證書吊銷列表（CRL）中，并在網上公示。
用戶B在收到用戶A的公鑰時，除了要驗證該公鑰是否位認證機構頒發的，還要登錄認證機構的網站查看該公鑰是否已被認證機構吊銷變為無效證書。
1.5.總結
認證機構CA的作用：
- 為企業和用戶頒發數字證書，確保這些企業和個人的身份是真實的；
- 發布證書吊銷列表，供用戶查詢收到的證書是否已被機構吊銷而無效；
6、http 和 https的區別
1、http連接很簡單，是無狀態的，明文傳輸。https協議 = http協議 + SSL，可以進行加密傳輸，身份認證
2、http連接的是80端口，https連接的是443端口
3、https協議需要服務器端到CA申請SSL證書，即客戶端請求的時候，服務器端發送SSL證書給客戶端，SSL證書內容包括公鑰、CA機構的數字簽名。驗證了服務器端的身份以及公鑰的可靠性。（注意：混合加密那里“將公鑰A給客戶端”，嚴格的來說是把SSL證書給客戶端）
SSL提供以下三個功能
1、SSL服務器鑒別。允許用戶證實服務器的身份。具有SSL功能的瀏覽器維持一個表，上面有一些可信賴的認證中心CA和它們的公鑰
2、SSL客戶鑒別。允許服務器證實客戶的身份。
3、加密的SSL會話，通過混合加密實現的。客戶和服務器交互的所有數據都是發送方加密，接受方解密
SSL的位置
7、http請求報文
1、請求行
（1）方法：get，post，head，put，delete，option，trace，connect
（2）URL字段
（3）HTTP協議版本
2、請求頭
User-Agent：產生請求的瀏覽器類型
Aceept：客戶端可識別的內容類型列表
Host：主機地址
3、請求數據 （post方法中，會把數據以key value形式發送請求）
4、空行 （發送回車符和換行符）
8、http的常見狀態碼
200：請求被成功處理
301：永久性重定向
302：臨時性重定向
403：沒有訪問權限
404：沒有對應資源
500：服務器錯誤
503：服務器停機
9、http1.0 和 http1.1的區別
- http1.0 一個文件建立一個TCP連接（例如一個網站有3張圖片，需要額外建立多3次TCP連接）
- http1.1 訪問網站，建立一個TCP連接，可用這個連接傳輸所有文件，有流水線和非流水線兩種方式
10、HTTP協議中的長連接和短連接
HTTP協議的底層使用TCP協議，所以HTTP協議的長連接和短連接在本質上是TCP層的長連接和短連接。由于TCP建立連接、維護連接、釋放連接都是要消耗一定的資源，浪費一定的時間。所對于服務器來說，頻繁的請求釋放連接會浪費大量的時間，長時間維護太多的連接的話又需要消耗資源。所以長連接和短連接并不存在優劣之分，只是適用的場合不同而已。長連接和短連接分別有如下優點和缺點：
長連接優點：可以節省較多的TCP連接和釋放的操作，節約時間，對于頻繁請求資源的用戶來說，適合長連接。
長連接缺點：由于有保活功能，當遇到大量的惡意連接時，服務器的壓力會越來越大。這時服務器需要采取一些策略，關閉一些長時間沒有進行讀寫事件的的連接。
短連接優點：短連接對服務器來說管理比較簡單，只要存在的連接都是有效連接，不需要額外的控制手段，而且不會長時間占用資源 。
短連接缺點：如果客戶端請求頻繁的話，會在TCP的建立和釋放上浪費大量的時間。
注意：從HTTP/1.1版本起，默認使用長連接用以保持連接特性。使用長連接的HTTP協議，會在響應消息報文段加入: Connection: keep-alive。TCP中也有keep alive，但是TCP中的keep alive只是探測TCP連接是否活著，而HTTP中的keep-alive是讓一個TCP連接獲得更久一點。
