大家都知道，在客戶端與伺服器資料傳輸的過程中，http協議的傳輸是不安全的，也就是一般情況下http是明文傳輸的。但https協議的資料傳輸是安全的，也就是說https資料的傳輸是經過加密的。
在客戶端與伺服器這兩個完全沒有見過面的陌生人交流中，https是如何保證資料傳輸的安全性的呢？下面我們來一步步了解https是如何加密才得以保證資料傳輸的安全性的？
我們先把客戶端稱為小客，伺服器稱為小服。然後一步步探索在小客與小服的交流中（就是一方請求一方響應），https是如何保證他們的交流不會被中間人竊聽的。
假如現在小客與小服要進行一次私密的對話，他們不希望這次對話內容被其他外人知道。可是，我們平時的資料傳輸過程中又是明文傳輸的，萬一被某個黑客把他們的對話內容給竊取了，那就難受了。
為了解決這個問題，小服這傢伙想到了乙個方法來加密資料，讓黑客看不到具體的內容。該方法是這樣子的：
在每次資料傳輸之前，小服會先傳輸給小客一把金鑰，然後小服在之後給小客發訊息的過程中，會用這把金鑰對這些訊息進行加密。小客在收到這些訊息後，會用之前小服給的那把金鑰對這些訊息進行解密，這樣，小客就能得到密文裡面真正的資料了。如果小客要給小服發訊息，也同樣用這把金鑰來對訊息進行加密，小服收到後也用這把金鑰進行解密。
這樣，就保證了資料傳輸的安全性。如圖所示：
這種方法稱之為對稱加密，加密和解密都用同一把金鑰。
這時，小服想著自己的策咯，還是挺得意的。但這個策略安全的前提是，小客擁有小服的那把金鑰。可問題是，小服是以明文的方式把這把金鑰傳輸給小客的，如果黑客擷取了這把金鑰，小服與小客就算是加密了內容，在擷取了金鑰的黑客老哥眼裡，這和明文沒啥區別。
小服還是挺聰明的，意識到了金鑰會被擷取這個問題，他又想到了另外一種方法：用非對稱加密的方法來加密資料。方法如下：
小服和小客都擁有兩把鑰匙，一把鑰匙是公開的（全世界都知道也沒關係），稱之為公鑰；而另一把鑰匙是保密（也就是只有自己才知道），稱之為私鑰。並且，用公鑰加密的資料，只有對應的私鑰才能解密；用私鑰加密的資料，只有對應的公鑰才能解密。
所以在傳輸資料的過程中，小服在給小客傳輸資料的過程中，會用小客給他的公鑰進行加密，然後小客收到後，再用自己的私鑰進行解密。小客給小服發訊息的時候，也一樣會用小服給他的公鑰進行加密，然後小服再用自己的私鑰進行解密。
這樣，資料就能安全到達雙方。如圖：
想著這麼複雜的策略都能想出來，小服可是得意的不能再得意了……還沒等小服得意多久，小客就給它潑了一波冷水。
小客嚴肅著說：其實，你的這種方法也不是那麼安全啊，還是存在被黑客擷取的危險啊。例如：
你在給我傳輸公鑰的過程中，如果黑客擷取了你的公鑰，並且拿著自己的公鑰來冒充你的公鑰來發給我。我收到公鑰之後，會用公鑰進行加密傳輸（這時用的公鑰實際上是黑客的公鑰）。黑客擷取了加密的訊息之後，可以用他自己的私鑰來進行解密來獲取訊息內容。然後再用你（小服）的公鑰來對訊息進行加密，之後再發給你（小服）。 這樣子，我們的對話內容還是被黑客給擷取了（倒過來小客給小服傳輸公鑰的時候也一樣）。…這麼精妙的想法居然也不行，小服這波，滿臉無神。
這裡插講下，其實在傳輸資料的過程中，在速度上用對稱加密的方法會比非對稱加密的方法快很多。所以在傳輸資料的時候，一般不單單只用非對稱加密這種方法（我們先假設非對稱密碼這種方法很安全），而是會用非對稱加密 + 對稱加密這兩種結合的方法。基於這個，我們可以用非對稱加密方法來安全著傳輸金鑰，之後再用對稱加密的方法來傳輸訊息內容（當然，我這裡假定了非對稱加密傳輸是安全的，下面會講如何使之安全）。
我們回頭想一下，是什麼原因導致非對稱加密這種方法的不安全性呢？它和對稱加密方法的不安全性不同。非對稱加密之所以不安全，是因為小客收到了公鑰之後，無法確定這把公鑰是否真的屬於小服。
也就是說，我們需要找到一種策略來證明這把公鑰就是小服的，而不是別人冒充的。
為了解決這個問題，小服和小客絞盡腦汁想出了一種終極策略：數字證書——我們需要找到乙個擁有公信力、大家都認可的認證中心（ca）。小服在給小客發公鑰的過程中，會把公鑰以及小服的個人資訊通過hash演算法生成訊息摘要。如圖：
為了防止摘要被人調換，小服還會用ca提供的私鑰對訊息摘要進行加密來形成數字簽名。如圖：
並且，最後還會把原來沒hash演算法之前的資訊和數字簽名合併在一起，形成數字證書。如圖：
當小客拿到這份數字證書之後，就會用ca提供的公鑰來對數字證書裡面的數字簽名進行解密得到訊息摘要，然後對數字證書裡面小服的公鑰和個人資訊進行hash得到另乙份訊息摘要，然後把兩份訊息摘要進行對比，如果一樣，則證明這些東西確實是小服的，否則就不是。如圖：
這時可能有人會有疑問，ca的公鑰是怎麼拿給小客的呢？小服又怎麼有ca的私鑰呢？
其實，（有些）伺服器在一開始就向認證中心申請了這些證書，而客戶端裡，也會內建這些證書。如圖（此圖來元阮一峰的網路日誌）：
當客戶端收到伺服器返回來的資料時，就會在內建的證書列表裡，檢視是否有有解開該數字證書的公鑰。
HTTPS資料傳輸流程
1.客戶端向伺服器端發起https請求，連線到伺服器端的443埠上 2.伺服器端有乙個秘鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的，伺服器端儲存著私鑰，將公鑰傳送給客戶端 3.客戶端收到伺服器端的公鑰之後，對公鑰進行檢查，驗證其合法性，如果發現公鑰有問題，那麼https傳輸無法繼續 如果合格，那...
網路資料傳輸
網路資料傳輸 wcdma全名是widebandcdma，中文譯名為 寬頻分碼多工訪問 它可支援384kbps到2mbps不等的資料傳輸速率，在高速移動的狀態，可提供384kbps的傳輸速率，在低速或是室內環境下，則可提供高達2mbps的傳輸速率。而gsm系統目前只能傳送9.6kbps，固定線路mod...
Qt 網路資料傳輸
以前寫介面主要用qt做ui，底層的功能是呼叫別人提供的介面，分工比較明確，但要更好地實現跨平台，則盡量使用qt內部的介面 當然，也有很多比較強大的庫，例如libcurl qt5自帶的網路處理模組qtnetwork 主要通過qnetworkaccessmanager qnetworkrequest q...