https加密的應用已經成為網際網路主流趨勢，啟用全站https**也越來越多。由於tls握手過程會給https增加多個rtt網路傳輸時間，很多**擔心速度效能受到影響。但隨著技術的迭代更新，越來越多的網路技術對https更加友好，合理配置使用新的網路技術優化https效能可以讓全站https加密全面提速。
使用者習慣於使用http請求你的**，為了讓使用者能夠自動切換至https，需要強制302/301跳轉到https，這樣的跳轉會至少增加1個rtt的延時，302跳轉後要再次tcp建連，增加1個rtt的延時。合理使用hsts，可以要求瀏覽器對http訪問的url重寫成https，避免始終強制302重定向帶來的延時開銷。
hsts（http strict transport security，http嚴格傳輸安全協議）的實現原理是：當瀏覽器第一次http請求伺服器時，返回的響應頭中增加strict-transport-security，告訴瀏覽器在指定的時間內，這個**必須通過https協議來訪問。也就是對於這個**的http位址，瀏覽器需要現在本地替換為https之後再傳送請求。
沃通ca建議伺服器開啟hsts的方法是：當客戶端通過https發出請求時，在伺服器返回的超文字傳輸協議響應頭中包含strict-transport-security欄位。非加密傳輸時設定的hsts欄位無效。最佳的部署方案是部署在離使用者最近的位置，例如：架構有前端反向**和後端web伺服器，在前端**處配置hsts是最好的，否則就需要在web伺服器層配置hsts。如果web伺服器不明確支援hsts，可以通過增加響應頭的機制。如果其他方法都失敗了，可以在應用程式層增加hsts。
hsts啟用比較簡單，只需在相應頭中加上如下資訊：
strict-transport-security: max-age=63072000; includesubdomains;preload;
strict-transport-security是header欄位名，max-age代表hsts在客戶端的生效時間。 includesubdomains表示對所有子網域名稱生效，preload是使用瀏覽器內建的網域名稱列表。
hsts策略只能在https響應中進行設定，**必須使用預設的443埠，必須使用網域名稱，不能是ip。因此需要把http重定向到https，如果明文響應中允許設定hsts頭，中間人攻擊者就可以通過在普通站點中注入hsts資訊來執行dos攻擊。
https會話恢復機制（session resumption）是指在一次完整協商的連線斷開時，客戶端和服務端會將會話的安全引數儲存一段時間。後續的連線時，雙方使用簡單握手恢復之前協商的會話，大大減少了tls握手的開銷。
https會話恢復的方案可以分為兩種：會話id（session id）和會話票證（session ticket）。會話id通過服務端為會話指定唯一的標識，並快取會話狀態。在第一次完整協商的過程中，serverhello訊息中將會話id發回客戶端。希望恢復會話的客戶端在下一次握手中將會話id放入clienthello，服務端認可後接著使用之前協商的主金鑰進行加密，而會話票證將所有會話狀態保持在客戶端（類似於http cookie）。
https會話恢復機制可以有效減少多次訪問時的握手次數，降低訪問延遲，但是也存在一定的弊端。會話恢復依賴於初始握手期間傳遞給客戶端裝置的會話恢復識別符號，並且這個識別符號在瀏覽器tls快取中持續存在，管理配置不當可能會導致會話恢復識別符號被跟蹤。因此，沃通ca建議https會話恢復識別符號應合理設定乙個更短的到期時間。
ocsp stapling是一種允許在tls握手中包含吊銷資訊的協議功能。啟用ocsp stapling後，服務端可以代替客戶端完成證書吊銷狀態的檢測，當客戶端訪問站點時，在握手階段就可以直接拿到 ocsp 響應結果和證書鏈，不需要再向 ca 請求介面，對訪問速度有明顯提公升。諮詢沃通ca技術支援了解ocsp stapling設定方法。
早期的ssl技術根據經典的pki公鑰基礎設施設計，預設一台伺服器（乙個ip）只會提供乙個服務，所以ssl握手時服務端可以確信客戶端請求的是哪張證書。然而，虛擬主機的大力發展造成了乙個ip對應多個網域名稱的情況。在http協議中，請求的網域名稱作為主機頭(host)放在http header中，所以伺服器端知道應該把請求引向哪個網域名稱，但是早期的ssl做不到這一點，因為在ssl握手的過程中，根本不會有host的資訊，所以伺服器端通常返回的是配置中的第乙個可用證書。因而一些較老的環境，可能會產生多網域名稱分別配好了證書，但返回的始終是同乙個。
sni擴充套件（server name indication, 伺服器名稱指示）定義在rfc 4366，主要用於同一ip配置多個https主機 的場景中，它允許客戶端在發起ssl握手請求時（具體說來，是客戶端發出ssl請求中的clienthello階段）就提交請求的主機名，即使同一ip位址上有多個伺服器，也能快速切換到正確網域名稱並返回正確的證書，sni欄位有助於大規模的tls託管工作，大大節省請求時間。
2023年iesg正式批准tls 1.3協議公布面世，它將成為客戶端和伺服器之間通過https連線建立加密通訊的最新標準。tls 1.3協議不僅在安全性方面得到重大提公升，而且大大提公升https連線的速度效能，建立tls握手過程中，tls 1.2協議需要2次訊息往返才能建立握手，載入時間會額外增加。而對於tls1.3來說，首次握手只需要1次訊息往來，大大降低一次連線所需的訊息往來耗時。對於近期訪問過的站點，還可以在第一次給伺服器發訊息時就傳送有用的資料，這就是「零訊息往來」模式(0-rtt)，會使網頁載入變得更快！
隨著新技術和計算力的提公升，為了防止金鑰被暴力破解，我們需要建立更強大、更安全的金鑰，tls握手過程中，更強大的金鑰意味著必須來回傳送更多的資料以驗證連線。而ecc橢圓曲線加密演算法只需要較短的金鑰長度就能提供更好的安全性。例如，256位的ecc金鑰加密強度等同於3072位rsa金鑰的水平(目前普通使用的rsa金鑰長度是2048位)，較小的金鑰意味著較小的證書和較少的資料來傳遞以建立https連線，在確保安全性的同時提公升連線速度。在apache和iis伺服器採用ecc演算法ssl證書，經國外有關權威機構測試，web伺服器響應時間比rsa快十幾倍。
MFC6大技術之RTTI
rtti為動態識別,cobject原始碼如下 bool cobject iskindof const cruntimeclsaa pclass const return false 定義了乙個鍊錶，即類別型錄表，在執行時識別此類是否和引數表示的類屬於同乙個類別。鍊錶節點 struct cruntim...
技術問題 Centos6配置yum源
由於centos6已經停止更新，各yum映象已經下架了相關依賴包，需要更換yum源為參考1 參考2，具體如下 備份原yum配置檔案 將目錄 etc yum.repos.d下repo檔案放入repo bak資料夾。wget o etc yum.repos.d centos base.repo 修改re...
Oracle大頁記憶體和核心引數優化配置
1 大記憶體頁設定 在linux系統上使用oracle資料庫，強烈建議使用大記憶體頁，否則對大sga和高連線數系統來說，系統的效能和穩定性將會受到嚴重影響。下面是大記憶體頁設定的具體步驟 1 確認作業系統支援大記憶體頁 有的作業系統核心不支援大記憶體頁，通過下面的命令可以確認系統是否支援大記憶體頁。...