internet上的兩台機器a,b要建立起http連線了，在這之前要先建立tcp連線，情景大概是這樣子的：
網路上有個關於tcp的笑話，大概就是上面的意思。當然事實上的情景要比這個複雜：
tcp握手本質上是在約定一次二進位制通訊的引數，使得網路上的兩台機型能夠基於這個約定交換二進位制資料。因為大家也知道，二進位制資料就是一堆0和1，如果沒有事先約定好位元組長度的分割和每個位代表的意義，是無法解讀的。
還是上面的情景，a和b建立好tcp連線後，又要建立乙個tls連線了
實質上的tls協商要比這個複雜，交換很多細節引數，tls連線層的安全是，保證了以下三個方面的安全
不被監聽。即使第三方收到密文，也無法解密
不被篡改。如果報文有被篡改，雙方能通過一定方法檢驗到
不被冒充。通訊的物件不是假冒的
要達到以上三點，很細節上的點要去參考rfc的
https是基於tcp+tls的協議，要想進行https通訊，則先要進行一次tcp握手，再進行一次tls握手，然後才能開始https通訊。握手之後，a跟b就是在交換資料了
可以看到http1.1版本的請求基本上是在模擬人類的對話，一請示一響應，雙方以此交換資料。
http/2的多路復用可以減少這些來往
tls1.3目前還是乙個制定中的標準。其中加密部分是基於ecdh，而不是rsa的，所以我們並不需要等到服務端的證書傳送過來就可以開始一些加密的計算。ecdh的原理可以參考這裡。在此證書的作用就變成校驗，而不是加密了。 tls1.3握手的場景大概是這樣子的
a下面就可以進行get /之類的http請求
甚至還可以進行0-rtt的握手，當然這是基於以前已經握過手。
可以看出這個握手是直接把tcp，tls，http三合一，這也是quic 0-rtt的基本原理。
前面 #8
#5 的時候我在處理乙個網路的錯誤問題，當時只知道一些解決方法，也懷疑過是不是https的問題，但無法考證。後來系統地學習過https的知識之後，發現從這些知識解釋這個現象是很簡單的。
參考上面的tls握手，服務端把自己的證書交給客戶端之後，原則上客戶端是要從ca那裡去校驗這個證書的合法性的，一但無法驗證（verify），就會報上面的錯誤，而strict-ssl=false是讓npm不去驗證，node_tls_reject_unauthorized=0是讓node-gyp不去驗證。所以雙方就基於乙個假的證書在進行https通訊了。反過來也說明我在用的**有進行mitm攻擊。
如果乙個**部署了https，除了更加安全，前端也能基於它得到以下優化
Https小結 與隱患
伺服器端儲存乙份密碼，而使用者儲存乙個密碼在本地，不用通過網路傳輸 例如 銀行的u盾等 辦理業務時，伺服器對每個使用者生成乙個密碼，難度 加密種類 對稱 非對稱，等，都能選擇 以達到破譯的難度標準，記錄在伺服器上，並會儲存在u盾裡 硬體 使用者進行業務訪問時，伺服器對資料進行加解密 密碼儲存在資料庫...
https知識整理
最近在做和https相關的工作，因此把工作中遇到的問題及知識做一下梳理和總結。在網際網路時代，資訊互動存在著不安全性，你無法判斷你訪問的 是真實的還是中間服務，https就是為了解決這個問題而產生的。在說https具體的知識之前，先要普及2個知識，對稱演算法和非對稱演算法。對稱加密演算法 加密方和解...
https 相關知識 （openssl）
秘鑰演算法和協議 對稱加密 加密和解密使用同乙個秘鑰 des data encryption standard 不安全，容易被破解 56位秘鑰 3des triple des aes advanced encryption standard 安全性特別高 秘鑰128bits 192bits 256b...