前端学习/ Day1/HTTP简单易懂/GET POST/HTTP特性/HTTP与HTTPS/HTTP版本演变/加解密数字签名数字证书
How Does The Internet Work ?
假設有十臺電腦 每個電腦有9個插口
那么需要45根網線
太麻煩
如果把這些電腦都連到一臺路由器上
那么只需要10根網線
如果要連接成百上千臺電腦
那就需要路由器連路由器
有點接近互聯網了
在家里我們會發現有根線接了進來
電話📞
電話也是一種網絡
為了連接這種網絡
需要調制解調器
就是 modem
可以把網絡信息變成modem可以處理的信息
反之亦然
所以我們可以 modem 連 modem
為了把信息從我們的網絡發到我們想要到達的地方
需要把網絡連接到 ISP （運營商 互聯網服務提供商）
ISP管理這些路由器
所以互聯網大概就是
PCA - Router - Modem - ISP1（Modem-Router） - ISP2 - ISP3 - Modem - Router - PCB
PCA 要發給PCB發信息
那么PCA需要知道PCB的地址
即 IP地址 xxx.xxx.xxx.xxx 例如192.168.1.1
為了好記，用域名來代替他
例 google.com = 172.217.7.14
互聯網(Internet)是基礎設施
而網絡(Web)是建立再這種基礎設施之上的服務
Client ----Server
服務器是存儲網頁、站點、應用的計算機
當Client想要獲取一個網頁
就從服務器上下載到客戶端（電腦、手機）上的瀏覽器顯示
除了客戶端和服務器
還要了解：
舉個栗子
你聽說一點點的奶茶好喝，想喝，
但是具體是哪里的一點點呢，這時候打開地圖（DNS）一查，原來在福建福州啊（IP地址) ，于是下單，買了10杯奶茶，留下了姓名電話地址，并要求發順豐（HTTP）
讓我們視角轉到一點點奶茶店。
為了打包奶茶，在路途上不撒出來，有規定要先密封好，再用泡沫紙墊著，再用紙箱包著，再用透明膠捆著，再貼上快遞單，快遞單上寫明是什么奶茶，誰發的，發給誰，等信息，這大概就是TCP/IP 即定義數據如何傳輸的通信協議
這一層層打包包裹和一層層拆包裹，因為一個包裹要經過好幾個快遞員手，所以數據包封裝也是這樣，
從上到下分別是應用層、傳輸層、網絡層、數據鏈路層、物理層
在數據（奶茶）上要加TCP頭部（快遞單 假設送到順豐公司）、順豐快遞員拿到后 再加上IP頭部（從順豐到村子所在地方）、再加上MAC頭部（到達家門口），最后的物理層其實是比特流，物理介質 網線
快遞到了家門口，我說是順豐嗎，他說是順豐，這才收下快遞
1、瀏覽器在DNS服務器上找到存放網頁的服務器的實際地址（一點點店的位置）
2、瀏覽器發HTTP請求信息到服務器（下單）這條消息，客戶端和服務器之間傳遞的數據都是通過互聯網使用TCP/IP協議傳輸的
3、服務器同意客戶端的請求后，返回”200 OK“的信息，然后將網頁的文件以數據包的形式傳輸到瀏覽器（快遞回來）
4、瀏覽器將數據包聚集成完整的網頁然后呈現給你看（奶茶到了家門口）
村子肯定要通路 才能讓快遞進來 （ 網絡連接 web）
村子到福州的路 就像互聯網 錯綜復雜
HTTP
1、基本知識
-
是什么？
超文本傳輸協議，是一個在計算機世界里專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規范。兩點不僅是服務器傳輸超文本到本地瀏覽器，也可以是服務器<–>服務器
-
狀態碼？
1xx：提示信息，是協議處理中的中間狀態，實際用的比較少
2xx：服務器成功處理客戶端的請求，成功碼
200 OK ：表示一切正常，如果是非HEAD請求，服務器返回的響應頭會有body數據
204 No Content ：與200 OK 基本相同，但是響應頭里沒有body數據
206 Partial Content ：應用于 HTTP 分塊下載或斷電續傳，表示響應返回的 body 數據并不是資源的全部，而是其中的一部分，也是服務器處理成功的狀態。3xx:需要客戶端用新的URL重新發送請求獲取資源，也就是重定向
301 Moved Permanently：永久重定向，說明請求的資源已經不存在了，需改用新的 URL 再次訪問
302 Moved Permanently：臨時重定向，說明請求的資源還在，但暫時需要用另一個 URL 來訪問
301 和 302 都會在響應頭里使用字段 Location，指明后續要跳轉的 URL，瀏覽器會自動重定向新的 URL
304 Not Modified：不具有跳轉的含義，表示資源未修改，重定向已存在的緩沖文件，也稱緩存重定向，用于緩存控制。4xx ：表示客戶端發送的報文有誤，服務器無法處理，也就是錯誤碼的含義
400 Bad Request：表示客戶端請求的報文有錯誤，但只是個籠統的錯誤。
403 Forbidden：表示服務器禁止訪問資源，并不是客戶端的請求出錯
404 Not Found：表示請求的資源在服務器上不存在或未找到，所以無法提供給客戶端5xx ：表示客戶端請求報文正確，但是服務器處理時內部發生了錯誤，屬于服務器端的錯誤碼
500 Internal Server Error：與 400 類型，是個籠統通用的錯誤碼，服務器發生了什么錯誤，我們并不知道。
501 Not Implemented：表示客戶端請求的功能還不支持，類似“即將開業，敬請期待”的意思。
502 Bad Gateway：通常是服務器作為網關或代理時返回的錯誤碼，表示服務器自身工作正常，訪問后端服務器發生了錯誤。
503 Service Unavailable：表示服務器當前很忙，暫時無法響應服務器，類似“網絡服務正忙，請稍后重試”的意思。 -
常見字段？
（1）Host 客戶端發送請求時，用來指定服務器的域名
Host: http://www.A.com
（2）Content-Length 服務器在返回數據時，表明本次回應的數據長度。
Content-Length: 1000
（3）Connection客戶端要求服務器使用 TCP 持久連接，以便其他請求復用。
Connection: keep-alive
（4）Content-Type 服務器回應時，告訴客戶端，本次數據是什么格式。
Content-Type: text/html; charset=utf-8
客戶端請求的時候，可以使用 Accept 字段聲明自己可以接受哪些數據格式。Accept: */ *表示接受所有數據格式
（5）Content-Encoding 服務器返回的數據使用了什么壓縮格式
Content-Encoding: gzip
Accept-Encoding: gzip, deflate
2、GET POST
-
區別 ？
GET Get 方法的含義是請求從服務器獲取資源，這個資源可以是靜態的文本、頁面、圖片視頻等
POST 向 URI 指定的資源提交數據(比如留言 瀏覽器就會執行一次POST請求)，數據就放在報文的 body 里，通過TCP協議發送到服務器 -
都是安全和冪等的嗎？
在 HTTP 協議里，所謂的「安全」是指請求方法不會「破壞」服務器上的資源。
所謂的「冪等」，意思是多次執行相同的操作，結果都是「相同」的。那么很明顯 GET 方法就是安全且冪等的，因為它是「只讀」操作，無論操作多少次，服務器上的數據都是安全的，且每次的結果都是相同的。
POST 因為是「新增或提交數據」的操作，會修改服務器上的資源，所以是不安全的，且多次提交數據就會創建多個資源，所以不是冪等的。
3、HTTP特性
-
優點 HTTP 最凸出的優點是「簡單、靈活和易于擴展、應用廣泛和跨平臺」
-
缺點 無狀態、明文傳輸，同時還有一大缺點「不安全」
無狀態的好處，因為服務器不會去記憶 HTTP 的狀態，所以不需要額外的資源來記錄狀態信息，這能減輕服務器的負擔，能夠把更多的 CPU 和內存用來對外提供服務。
無狀態的壞處，既然服務器沒有記憶能力，它在完成有關聯性的操作時會非常麻煩
無狀態的問題，解法方案有很多種，其中比較簡單的方式用 Cookie 技術
Cookie 通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態
明文傳輸的好處 ，在傳輸過程中的信息，是可方便閱讀的，通過瀏覽器的 F12 控制臺或 Wireshark 抓包都可以直接肉眼查看，為我們調試工作帶了極大的便利性。
明文傳輸的壞處，HTTP 的所有信息都暴露在了光天化日下，相當于信息裸奔。在傳輸的漫長的過程中，信息的內容都毫無隱私可言，很容易就能被竊取，如果里面有你的賬號密碼信息，那你號沒了。
不安全：
通信使用明文（不加密），內容可能會被竊聽。比如，賬號信息容易泄漏，那你號沒了。
不驗證通信方的身份，因此有可能遭遇偽裝。比如，訪問假的淘寶、拼多多，那你錢沒了。
無法證明報文的完整性，所以有可能已遭篡改。比如，網頁上植入垃圾廣告，視覺污染，眼沒了。
HTTP 的安全問題，可以用HTTPS 也就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層 -
性能？
HTTP 協議是基于 TCP/IP，并且使用了「請求 - 應答」的通信模式，所以性能的關鍵就在這兩點里
早期 HTTP/1.0 性能上的一個很大的問題，那就是每發起一個請求，都要新建一次 TCP 連接（三次握手），而且是串行請求，增加了通信開銷
為了解決上述 TCP 連接問題，HTTP/1.1 提出了長連接的通信方式，也叫持久連接。這種方式的好處在于減少了 TCP 連接的重復建立和斷開所造成的額外開銷，減輕了服務器端的負載。
管道網絡傳輸 即可在同一個 TCP 連接里面，客戶端可以發起多個請求
以前的做法是，在同一個TCP連接里面，先發送 A 請求，然后等待服務器做出回應，收到后再發出 B 請求。管道機制則是允許瀏覽器同時發出 A 請求和 B 請求。
服務器還是按照順序，先回應 A 請求，完成后再回應 B 請求。要是 前面的回應特別慢，后面就會有許多請求排隊等著。這稱為「隊頭堵塞」
「請求 - 應答」的模式加劇了 HTTP 的性能問題
總之 HTTP/1.1 的性能一般般，后續的 HTTP/2 和 HTTP/3 就是在優化 HTTP 的性能
4、HTTP HTTPS
-
區別 ？
HTTP 是超文本傳輸協議，信息是明文傳輸，存在安全風險的問題。
HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 之間加入了 SSL/TLS 安全協議，使得報文能夠加密傳輸。
HTTP 連接建立相對簡單， TCP 三次握手之后便可進行 HTTP 的報文傳輸。而 HTTPS 在 TCP 三次握手之后，還需進行 SSL/TLS 的握手過程，才可進入加密報文傳輸。
HTTP 的端口號是 80，HTTPS 的端口號是 443
HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證服務器的身份是可信的。 -
HTTPS解決了HTTP什么問題 ？
HTTP 由于是明文傳輸，所以安全上存在以下三個風險：
竊聽風險，比如通信鏈路上可以獲取通信內容，用戶號容易沒。
篡改風險，比如強制入垃圾廣告，視覺污染，用戶眼容易瞎。
偽裝風險，比如冒充淘寶網站，用戶錢容易沒。
HTTPS 在 HTTP 與 TCP 層之間加入了 SSL/TLS 協議
信息加密：交互信息無法被竊取
校驗機制：無法篡改通信內容，篡改了就不能正常顯示，但百度「競價排名」依然可以搜索垃圾廣告。
身份證書：證明淘寶是真的淘寶網 -
HTTPS如何解決HTTP不安全問題的 ？
HTTPS 采用的是對稱加密和非對稱加密結合的「混合加密」方式，解決了竊聽的風險
非對稱加密密鑰，對稱加密數據摘要算法的方式來實現完整性，它能夠為數據生成獨一無二的「指紋」，指紋用于校驗數據的完整性，解決了篡改的風險
客戶端先向服務器端索要公鑰，然后用公鑰加密信息，服務器收到密文后，用自己的私鑰解密。
這就存在些問題，如何保證公鑰不被篡改和信任度？
所以這里就需要借助第三方權威機構 CA （數字證書認證機構），將服務器公鑰放在數字證書（由數字證書認證機構頒發）中，只要證書是可信的，公鑰就是可信的。通過數字證書的方式保證服務器公鑰的身份，解決冒充的風險
-
HTTPS如何建立連接，交互了什么 ？
SSL/TLS 協議基本流程：
客戶端向服務器索要并驗證服務器的公鑰。
雙方協商生產「會話秘鑰」。
雙方采用「會話秘鑰」進行加密通信。前兩步是 SSL/TLS 的建立過程，也就是握手階段，四次通信
ClientHello 客戶端向服務器發起加密通信請求
（1）客戶端支持的 SSL/TLS 協議版本，如 TLS 1.2 版本。
（2）客戶端生產的隨機數（Client Random），后面用于生產「會話秘鑰」。
（3）客戶端支持的密碼套件列表，如 RSA 加密算法。
SeverHello服務器收到客戶端請求后，向客戶端發出響應
（1）確認 SSL/ TLS 協議版本，如果服務器不支持，則關閉加密通信。
（2）服務器生產的隨機數（Server Random），后面用于生產「會話秘鑰」。
（3）確認的密碼套件列表，如 RSA 加密算法。
（4）服務器的數字證書。
客戶端回應客戶端收到服務器的回應之后，首先通過瀏覽器或者操作系統中的 CA 公鑰，確認服務器的數字證書的真實性，如果證書沒有問題，客戶端會從數字證書中取出服務器的公鑰，然后使用它加密報文，向服務器發送如下信息，
（1）一個隨機數（pre-master key）。該隨機數會被服務器公鑰加密。
（2）加密通信算法改變通知，表示隨后的信息都將用「會話秘鑰」加密通信。
（3）客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時把之前所有內容的發生的數據做個摘要，用來供服務端校驗。
服務器的最后回應服務器收到客戶端的第三個隨機數（pre-master key）之后，通過協商的加密算法，計算出本次通信的「會話秘鑰」。然后，向客戶端發生最后的信息：
（1）加密通信算法改變通知，表示隨后的信息都將用「會話秘鑰」加密通信。
（2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時把之前所有內容的發生的數據做個摘要，用來供客戶端校驗。
至此，整個 SSL/TLS 的握手階段全部結束。接下來，客戶端與服務器進入加密通信，就完全是使用普通的 HTTP 協議，只不過用「會話秘鑰」加密內容。
5、HTTP/1.1 HTTP/2 HTT/3演變
-
1.1比1.0 提高了什么性能 ？
使用 TCP 長連接的方式改善了 HTTP/1.0 短連接造成的性能開銷。
支持管道（pipeline）網絡傳輸，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的響應時間。
但 HTTP/1.1 還是有性能瓶頸：
請求 / 響應頭部（Header）未經壓縮就發送，首部信息越多延遲越大。只能壓縮 Body 的部分；
發送冗長的首部。每次互相發送相同的首部造成的浪費較多；
服務器是按請求的順序響應的，如果服務器響應慢，會招致客戶端一直請求不到數據，也就是隊頭阻塞；
沒有請求優先級控制；
請求只能從客戶端開始，服務器只能被動響應。 -
HTTP/2 針對 1.1 做了什么優化 ？
HTTP/2 協議是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的
頭部壓縮 HTTP/2 會壓縮頭（Header）如果你同時發出多個請求，他們的頭是一樣的或是相似的，那么，協議會幫你消除重復的分。
這就是所謂的 HPACK 算法：在客戶端和服務器同時維護一張頭信息表，所有字段都會存入這個表，生成一個索引號，以后就不發送同樣字段了，只發送索引號，這樣就提高速度了。
二進制格式HTTP/2 不再像 HTTP/1.1 里的純文本形式的報文，而是全面采用了二進制格式。頭信息和數據體都是二進制，并且統稱為幀（frame）：頭信息幀和數據幀。
二進制增加了數據傳輸的效率數據流 Stream HTTP/2 的數據包不是按順序發送的，同一個連接里面連續的數據包，可能屬于不同的回應。因此，必須要對數據包做標記，指出它屬于哪個回應。
每個請求或回應的所有數據包，稱為一個數據流
每個數據流都標記著一個獨一無二的編號，其中規定客戶端發出的數據流編號為奇數， 服務器發出的數據流編號為偶數
客戶端還可以指定數據流的優先級。優先級高的請求，服務器就先響應該請求多路復用 HTTP/2 是可以在一個連接中并發多個請求或回應，而不用按照順序一一對應。
移除了 HTTP/1.1 中的串行請求，不需要排隊等待，也就不會再出現「隊頭阻塞」問題，降低了延遲，大幅度提高了連接的利用率。
服務器推送 Server Push，也叫 Cache Push，HTTP/2 還在一定程度上改善了傳統的「請求 - 應答」工作模式，服務不再是被動地響應，也可以主動向客戶端發送消息。在瀏覽器剛請求 HTML 的時候，就提前把可能會用到的 JS、CSS 文件等靜態資源主動發給客戶端，減少延時的等待 -
2 有哪些缺陷 ？ 3 做了哪些優化 ？
HTTP/2 主要的問題在于：多個 HTTP 請求在復用一個 TCP 連接，下層的 TCP 協議是不知道有多少個 HTTP 請求的。所以一旦發生了丟包現象，就會觸發 TCP 的重傳機制，這樣在一個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。
HTTP/1.1 中的管道（ pipeline）傳輸中如果有一個請求阻塞了，那么隊列后請求也統統被阻塞住了
HTTP/2 多請求復用一個TCP連接，一旦發生丟包，就會阻塞住所有的 HTTP 請求。
這都是基于 TCP 傳輸層的問題，所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP！
UDP 發生是不管順序，也不管丟包的，所以不會出現 HTTP/1.1 的隊頭阻塞 和 HTTP/2 的一個丟包全部重傳問題。UDP 是不可靠傳輸的，但基于 UDP 的 QUIC 協議 可以實現類似 TCP 的可靠性傳輸。
QUIC 有自己的一套機制可以保證傳輸的可靠性的。當某個流發生丟包時，只會阻塞這個流，其他流不會受到影響。
TL3 升級成了最新的 1.3 版本，頭部壓縮算法也升級成了 QPack
HTTPS 要建立一個連接，要花費 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，減少了交互次數。
所以， QUIC 是一個在 UDP 之上的偽 TCP + TLS + HTTP/2 的多路復用的協議。
QUIC 是新協議，對于很多網絡設備，根本不知道什么是 QUIC，只會當做 UDP，這樣會出現新的問題。所以 HTTP/3 現在普及的進度非常的緩慢，不知道未來 UDP 是否能夠逆襲 TCP。
總結
以上是生活随笔為你收集整理的前端学习/ Day1/HTTP简单易懂/GET POST/HTTP特性/HTTP与HTTPS/HTTP版本演变/加解密数字签名数字证书的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 工作34：第三方登录
- 下一篇： 前端学习（2150）：webpack之配