名詞解釋
- 超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol）
- 傳輸控制協(xié)議（TCP，Transmission Control Protocol）
- 因特網(wǎng)協(xié)議（IP，Internet Protocol）
- 地址解析協(xié)議（ARP，Address Resolution Protocol）
- 一套標準/文檔 (RFC，Request For Comments)-意即“請求注解”,
- 域名系統(tǒng)(DNS， Domain Name System)
- 安全套接層（SSL，Secure Socket Layer）
- 高級加密算法/對稱加密 （AES，Advanced Encryption Standard）
- 非對稱加密算法（RSA）
- 安全層傳輸協(xié)議（TLS，Transport Layer Security）
- 計算機網(wǎng)絡(luò)模型OSI（Open Systems Interconnect）
- 內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN,Content Delivery Network)
網(wǎng)絡(luò)協(xié)議
根據(jù)ISO模型分為7層：
物理層、鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層、應用層
根據(jù)TCP/IP模型分為4層：
鏈路層(網(wǎng)絡(luò)接口層)、網(wǎng)絡(luò)層、傳輸層、應用層
IPv4
- IPv4的概念
IPv4地址是32位的地址，分為4個部分，每個部分由8位二進制組成，像我們看到的192.168.1.1是為了方便記憶轉(zhuǎn)換成了十進制。最大的數(shù)字肯定也就是255了，比如：255.255.255.255 - IPv4的尷尬之處
隨著互聯(lián)網(wǎng)的日益發(fā)展的今天，IPv4面臨枯竭已成不爭的事實，共有2^32次方個
由于資源緊張，IP地址動態(tài)更換的。不同的人在不同的時間段共用一個IP，無法做到上網(wǎng)用戶和IP地址一一對應。所以根據(jù)IP地址查一些信息自然也是存在缺陷的，由于數(shù)據(jù)量的龐大，各運營商只保留一段時間的上網(wǎng)日志，假如你前幾年發(fā)表了一些言論，想根據(jù)IP來查詢是誰發(fā)送的，就不能實現(xiàn)了。 - 升級位數(shù)，IPv6的出現(xiàn)
如果換成IPv6呢，這個問題就輕而易舉的解決了，共有地址是2^128個，這樣的話就不用共用了，為每個上網(wǎng)用戶分配一個即可。就像我們身份證號一樣，當然如果人口劇增，18位的身份證又滿足不了，再升級就是了，換成36位的身份證號
DoS（DenialOfService）拒絕服務(wù)的縮寫
一般用非正常手段造成合法的用戶無法正常請求，一般有以下三種手段：
制造大流量網(wǎng)絡(luò)數(shù)據(jù)，造成網(wǎng)絡(luò)堵塞，使攻擊主機無法與外界通信
反復高頻的發(fā)出重復請求，使被攻擊主機來不及處理其他請求
反復發(fā)送畸形數(shù)據(jù)從而引發(fā)系統(tǒng)錯誤分配大量系統(tǒng)資源，使主機處于掛起狀態(tài)甚至死機
服務(wù)器很難區(qū)別何為正常請求，何為攻擊請求
持久連接
在HTTP 協(xié)議的最初版本中，每進行一次 HTTP 通信就要斷開一次 TCP 連接，日后隨著HTTP的發(fā)展，傳輸大文件或者展示大量圖片，這種每次都要連接和斷開，無疑增加了通信量的開銷
在HTTP /1.1和部分HTTP/1.0 提出了TCP持久連接機制。最主要的特征就是，TCP連接之后，只要任何一端沒有提出斷開連接，則保持TCP連接狀態(tài)
持久連接的好處是:減少了重復連接斷開造成的額外開銷，也相應減少了開銷的時間，是的HTTP請求和相應可以更早的結(jié)束，顯示速度也相應提高
在HTTP1.1中，所有的連接默認都是持久連接
HTTP的缺點
- 通信使用明文，內(nèi)容可能被竊聽
- 不驗證通信方身份，可能被偽裝
- 無法驗證報文的完整性，有可能被篡改
這些問題不僅僅出現(xiàn)在HTTP，其他不加密的協(xié)議同樣如此，
HTTPS（HTTP+SSL/TLS）
HTTPS 采用對稱加密和非對稱加密兩種加密機制
- 首先來解決第一個問題：如何使得黑客縱然截取內(nèi)容后也枉然？
使用對稱加密解決
收發(fā)內(nèi)容全程加密，使用同一個秘鑰，發(fā)送前加密，接收后解密。這樣的話，中間即便黑客獲取到內(nèi)容，也是兩眼淚汪汪，白忙一場。因為內(nèi)容是加密的
- 隨之引發(fā)的第二個問題：如何把秘鑰安全送達到對方手里
使用非對稱加密解決
這個問題，讓我們又回到了原點，把秘鑰給另一方的過程中，黑客獲取到了秘鑰等于前面做的努力都白費了！如果能把秘鑰安全送達，且不能篡改，那直接發(fā)送數(shù)據(jù)就行了，何必繞這么一大圈，雞生蛋，蛋生雞的問題。
使用公鑰和私鑰的來進行對傳輸?shù)拿罔€加密，但是過程中有一個小問題，怎么才能確認此公鑰是真實有效官方發(fā)布的
- 呼之即來的第三個問題：如何證明公鑰是真實有效的
CA機構(gòu)騰空出世
是啊，老鐵，咋整啊？這個時候，人們提出找一個權(quán)威機構(gòu)做認證，即公鑰發(fā)布之前先去認證，中間認證機構(gòu)，其頒發(fā)的證書也就是我們常說的CA證書，CA機構(gòu)申請給將要分發(fā)的公鑰進行數(shù)字簽名
數(shù)字簽名證書的本質(zhì)就是服務(wù)端的公鑰+CA私鑰加密的Hash值
當客戶端收到該公鑰數(shù)字證書后，會驗證其有效性。大部分客戶端都會預裝CA機構(gòu)的公鑰，也就是CA公鑰
最終把對稱加密使用的秘鑰，發(fā)送給客戶端，從而進行加密解密。
讓我們簡單回顧一下整個流程：
1.為了通信內(nèi)容的安全性，通過對稱加密的方式對傳輸內(nèi)容進行加密解密。
2.這其中有一個關(guān)鍵性的難題，怎么把秘鑰安全的傳輸給客戶端
3.這時候通過非對稱加密的方式，即公鑰和私鑰，對第2步中的秘鑰進行加密
4.可是這個時候又出現(xiàn)一個問題，怎么識別公鑰是官方發(fā)布的，如果這個公鑰是個冒牌貨，客戶端豈不是把銀行卡號，密碼全泄漏出去了，通過CA證書認證，公鑰發(fā)布之前，先認證
5.客戶端在一般都預裝了CA機構(gòu)的公鑰，這樣就會檢驗服務(wù)端的公鑰，是否是官方發(fā)布。
6.有了3.4.5步的保證，第2步秘鑰最終才能順利到達彼岸，真是環(huán)環(huán)相扣
不忘初心，方得始終。真心不容易，大體的流程大概就是這樣的
查看電腦中安裝的證書：開始運行中輸入certmgr.msc
