八 大話HTTP協議 Nginx HTTPS搭建

在動手之前，最好有乙個屬於自己的雲伺服器，並且擁有乙個備案成功的網域名稱。對於個人學習和做出像樣成品還是比較重要的。基於此，我們可以進行下面的https服務的搭建，本篇文章主要是基於nginx進行的配置，其他比如tomcat下的配置也都可以試驗。

本篇文章暫且不去**https原理，我們先把這個小鎖整出來，再來看理論，我認為或許是比較好的學習方式。

要在nginx中配置https，就必須安裝ssl模組，也就是:http_ssl_module。

下面依然是編譯和安裝：

make 

make install

發現最後確實已經包含了ssl模組。

我們先來簡單說明下tls是如何握手的，下面文章詳細說明https原理。

傳輸層安全性協定 tls（transport layer security），及其前身安全套接層 ssl（secure sockets layer）是一種安全協議，目的是為網際網路通訊，提供安全及資料完整性保障。

如圖，tls 在建立連線時是需要經歷如下過程：

可以看到，第二步中，伺服器端返回了證書，那麼證書是個什麼玩意呢？

證書用來證明公鑰擁有者身份的憑證。

首先我們需要知道 證書是怎麼來的。數字證書一般由數字證書認證機構簽發，需要：

證書包含了:

好了，那麼客戶端拿到證書是如何進行驗證的呢？

客戶端拿到證書後，需要驗證證書的有效性，即是否被篡改，如何驗證呢？我們可以看到上面申請證書的時候，用ca的私鑰對「數字簽名m和摘要演算法」進行了加密，客戶端需要用ca公鑰進行解密，按照演算法同樣對整個資訊生成新的摘要數字簽名m1，客戶端需要對m和m1進行對比是否相等，相等則說明此證書沒有被篡改！

數字證書認證機構（英語：certificate authority，縮寫為ca），也稱為電子商務認證中心、電子商務認證授權機構，是負責發放和管理數字證書的權威機構，並作為電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。

其實任何個體/組織都可以成為ca（自簽證書），但是你發發布的證書客戶端是不信任的，也是就前文提及的需要權威。比如symantec、comodo、godaddy、digicert。

客戶端信任這些ca，就會在其本地保持這些ca的 根證書（root certificate），根證書是ca自己的證書，是證書驗證鏈的開頭。

根證書沒有機構（已經是權威了）再為其做數字簽名，所以都是自簽證書。

總結下，ca是乙個權威機構，從他那可以申請到證書，由於大家都信任ca，所以它頒發的證書都會信任。證書是乙個包含了公鑰、頒發者、證書擁有者等資訊的憑證，這個憑證可以證明這個**是值得信任的。這樣，這個**就證明了我就是我，並且我跟你之前的通訊是可靠的。

也就是說，免費的證書就是讓你個人玩一玩的，商用的還請老老實實交錢，不然出問題導致**不能訪問可就別哭了。

這個頁面有個「申請免費證書」，按照下一步下一步無腦配置即可。

好了，至此，關於證書和私鑰的申請和配置就說到這裡。

有了證書和私鑰，就差nginx的配置了，我們這裡簡單用nginx預設頁面來做下測試。配置檔案如下：

最後啟動來測試下，可以看到，我這裡監聽了80埠和443埠，分別訪問兩個頁面的效果：

當我們訪問時展示：

當我們訪問時展示：

終於見到了可愛的小鎖，ok，https服務搭建完畢。

九 大話HTTP協議 加密問題

實際上，用https的方式即可，輸入使用者名稱密碼進行驗證，並且現在也不是每次都要輸入使用者名稱密碼，作業系統會記憶，不過也可以自己去配置使用者名稱密碼，達到避免每次https方式clone或push都要輸入密碼的尷尬。關於https和ssh兩種方式，可自行谷歌搜尋區別 我們回到ssh方式，初學者可...

八 大話設計模式之模板方法模式

good 把不變的 部分都轉移到父類中，將可變的 用 virtual 留到子類重寫。迪公尺特法則 如果兩個類不直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果乙個類需要呼叫另乙個類的某個方法的話，可以通過第三個類 這個呼叫。在類的結構設計上，每乙個類都應該盡量降低成員的訪問許可權。該法則在後面...

HTTP 的 八大請求方式

http 的 八大請求方式 get post head options put delete trace connect。1.get get 動作 用於獲取資源，當採用 get 方式請求指定資源時，被訪問的資源經伺服器解析後立即返回響應內容。通常以 get 方式請求特定資源時，請求中不應該包含請求體...