https及https調優

1 HTTPS

1.1 HTTPS簡介

  超文本傳輸安全協議(英語:HyperText Transfer Protocol Secure,縮寫:HTTPS;常稱爲HTTP over TLS、HTTP over SSL或HTTP Secure)是一種通過計算機網絡進行安全通信的傳輸協議。HTTPS經由HTTP進行通信,但利用SSL/TLS來加密數據包。HTTPS開發的主要目的,是提供對網站服務器的身份認證,保護交換數據的隱私與完整性。這個協議由網景公司(Netscape)在1994年首次提出,隨後擴展到互聯網上。歷史上,HTTPS連接經常用於萬維網上的交易支付和企業信息系統中敏感信息的傳輸。在2000年代末至2010年代初,HTTPS開始廣泛使用,以確保各類型的網頁真實,保護賬戶和保持用戶通信,身份和網絡瀏覽的私密性。另外,還有一種安全超文本傳輸協議(S-HTTP)的HTTP安全傳輸實現,但是HTTPS的廣泛應用而成爲事實上的HTTP安全傳輸實現,S-HTTP並沒有得到廣泛支持。

 emsp;現如今一般網址的前綴便可以看出該網站支持的協議類型分別爲http:\\https:\\

1.2 HTTPS和HTTP的區別

  HTTP是一種超文本傳輸協議,其在網絡中傳輸數據是通過明文進行傳輸,如果應用程序未對數據進行加密處理,則任何人都可以通過監聽或者中間人攻擊之類的技術手段查看其內容。HTTPS是在HTTP的基礎上對數據進行加密。

  1. https協議需要向CA申請證書,一般免費的證書比較少,需要一定的費用,而HTTP只是一種協議可以隨意使用,免費;
  2. http傳輸的是明文,https傳輸的是加密過的數據;
  3. http和https使用的連接方式和端口不同,前者是80,後者是443;
  4. http是無狀態連接,https協議是由SSL+Http協議構建的可進行加密傳輸、身份認證的網絡協議,比http協議安全。

在這裏插入圖片描述

1.3 HTTPS的工作原理

  在協議棧中http和https都屬於應用層,都是基於傳輸層的TCP協議實現的,https實在http的基礎上添加了一層SSL/TLS。
在這裏插入圖片描述

1.3.1 TLS

1.3.1.1 TLS簡介

  傳輸層安全性協議(英語:Transport Layer Security,縮寫:TLS)及其前身安全套接層(英語:Secure Sockets Layer,縮寫:SSL)是一種安全協議,目的是爲互聯網通信提供安全及數據完整性保障。網景公司(Netscape)在1994年推出首版網頁瀏覽器-網景導航者時,推出HTTPS協議,以SSL進行加密,這是SSL的起源。IETF將SSL進行標準化,1999年公佈TLS 1.0標準文件(RFC 2246)。隨後又公佈TLS 1.1(RFC 4346,2006年)、TLS 1.2(RFC 5246,2008年)和TLS 1.3(RFC 8446,2018年)。在瀏覽器、電子郵件、即時通信、VoIP、網絡傳真等應用程序中,廣泛使用這個協議。許多網站,如Google、Facebook、Wikipedia等也以這個協議來創建安全連線,發送數據。目前已成爲互聯網上保密通信的工業標準。

1.3.1.2 TLS握手

  TLS協議採用主從式架構模型,用於在兩個應用程序間透過網絡創建起安全的連線,防止在交換數據時受到竊聽及篡改。

  TLS協議的優勢是與高層的應用層協議(如HTTP、FTP、Telnet等)無耦合。應用層協議能透明地運行在TLS協議之上,由TLS協議進行創建加密信道需要的協商和認證。應用層協議傳送的數據在通過TLS協議時都會被加密,從而保證通信的私密性。TLS協議是可選的,必須配置客戶端和服務器才能使用。主要有兩種方式實現這一目標:一個是使用統一的TLS協議端口(例如:用於HTTPS的端口443);另一個是客戶端請求服務器連接到TLS時使用特定的協議機制(例如:電子郵件常用的STARTTLS)。一旦客戶端和服務器都同意使用TLS協議,他們通過使用一個握手過程協商出一個有狀態的連接以傳輸數據[1]。通過握手,客戶端和服務器協商各種參數用於創建安全連接。

  握手過程如下:

  1. 客戶端連接到支持TLS協議的服務器通過TCP要求創立鏈接,最先是最基本的TCP三次握手過程;
  2. 在三次握手的第三次客戶端會向服務提提供自身支持的TLS版本、TLS選項、密碼包(加密算法,散列算法等)等;
  3. 服務器從客戶端提供的密碼包列表中選擇一個密碼包通知客戶端,併發送服務器經過CA認證的數字證書、公鑰;
  4. 客戶端確認其證書有效性,使用服務器的公鑰和協商的加密套件加密一個對稱密鑰(通過隨機數生成),該密鑰只能通過服務器的私鑰解密;
  5. 服務器使用私鑰解密出對稱密鑰後發送加密的Finish消息,表明握手完成。

在這裏插入圖片描述

  可以明顯的看到,TLS的我收過程比較複雜。

1.3.1.3 TLS加密

  從上面的握手過程中可以看到,整個過程使用到了兩種加密方式:非對稱加密和對稱加密。

  非對稱加密:
  非對稱加密:非對稱加密也稱公開密鑰密碼,是密碼學的一種算法,分別需要公鑰和私鑰兩個密鑰,公鑰用於加密,私鑰用於解密,因爲加密和解密的密鑰不同,因此稱之爲非對稱加密。其公鑰可以公開,可任意向外發布;私鑰不可以公開,必須由用戶自行嚴格祕密保管,絕不透過任何途徑向任何人提供,也不會透露給被信任的要通信的另一方。
  常見的非對稱加密算法有:RSA、ElGamal、DS、ECDSA、ECC等,其中RSA使用最爲廣泛。另外多說一句:RSA需要解決的問題是大整數因數分解。

  對稱加密
  對稱加密:對稱加密在加密和解密過程中使用相同的密鑰,與公開密鑰加密相比,要求雙方獲取相同的密鑰是對稱密鑰加密的主要缺點之一。
  常見的對稱加密算法有:AES、DES、ChaCha20等。

  對稱加密和非對稱加密的不同

  1. 對稱加密加密解密速度快,非對稱加密解密速度慢;
  2. 對稱加密安全性不高,非對稱加密安全性高;
  3. 對稱加密密鑰管理不方便,非對稱加密密鑰管理方便。

  因此TLS通過融合對稱加密和非對稱加密的優缺點:使用對稱加密加密數據,使用非對稱加密進行對稱加密的密鑰交換。從握手過程中可以看到發生在過程4和5。

在這裏插入圖片描述

1.4 HTTPS的優缺點

  優點

  1. HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議,要比http協議安全,可防止數據在傳輸過程中不被竊取、改變,確保數據的完整性;
  2. HTTPS是現行架構下最安全的解決方案,雖然不是絕對安全,但它大幅增加了中間人攻擊的成本;

  缺點

  1. HTTPS並不能防止站點被網絡爬蟲抓取。在某些情形中,被加密資源的URL可僅通過截獲請求和響應的大小推得,這就可使攻擊者同時知道明文(公開的靜態內容)和密文(被加密過的明文),從而使選擇密文攻擊成爲可能;
  2. 因爲SSL在HTTP之下工作,對上層協議一無所知,所以SSL服務器只能爲一個IP地址/端口組合提供一個證書。這就意味着在大部分情況下,使用HTTPS的同時支持基於名字的虛擬主機是不很現實的;
  3. 證書通常並不是免費的;
  4. HTTPS中握手過程繁瑣,數據需要經過加密,響應速度不如HTTP;
  5. SSL證書通常需要綁定IP,不能在同一IP上綁定多個域名,IPv4資源不可能支撐這個消耗;
  6. HTTPS協議的加密範圍也比較有限,在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼作用。最關鍵的,SSL證書的信用鏈體系並不安全,特別是在某些國家可以控制CA根證書的情況下,中間人攻擊一樣可行。

2 HTTPS調優

 由於TLS繁瑣的握手和加密過程導致HTTPS的性能不佳,如何調優tls提升https的服務響應是必要的。HTTPS協議包含HTTP、TCP和TLS三部分,因此調優也是從三部分入手。

2.1 HTTP

  HTTP協議有兩個版本HTTP1.0和HTTP2.0。HTTP2.0是針對HTTP1.0的缺陷設計出的高響應版本。
  HTTP1.0的缺陷:

  1. 每個請求都需要建立單獨鏈接,無法保持長連接;
  2. 每個請求和響應都需要完整的head信息;
  3. 數據未加密。

  相比而言,HTTP2.0的優點:

  1. 支持多路複用,可以通過單個鏈接發起多重請求-響應消息,而不是維護多個TCP鏈接;
  2. 二進制分幀,在兼容HTTP1.0的基礎上添加了一個二進制分幀層,改進傳輸性能,實現低延遲和高吞吐量;
  3. 首部壓縮,HTTP2.0通過HPACK算法對首部進行壓縮;
  4. 服務端推送,服務端推送是一種在客戶端請求之前發送數據的機制,服務端主動把客戶端可能需要的資源推送給客戶端,而不是需要客戶端主動請求;

  因此在協議選擇上選擇HTTP2.0相比於HTTP1.0性能上更好。

2.2 TCP

  由於TCP擁塞控制算法中的慢啓動算法,導致剛開始建立鏈接的cwnd窗口很小,HTTP的數據包可能被拆分爲多個小數據包,而小數據包在網絡中傳輸到達需要再進行重組無疑增加了開銷,可以通過修改慢啓動的初始窗口值,但是這一步需要考慮到目標網絡的狀況,需要根據實際的網絡狀況調整。

  TCP鏈接會在當前鏈接幾乎沒有任何流量的時候減小cwnd,開啓慢啓動算法,在服務端可以通過命令sysctl -w net.ipv4.tcp_slow_start_after_idle=0禁止空閒慢啓動,也可以將其寫入/etc/sysctl.conf使其永久有效。

  當然還可以調整TCP的其他參數調優TCP,詳情見TCP參數調優詳解

2.3 TLS

2.3.1 長連接

  HTTPS主要性能瓶頸之一是每個鏈接開始握手階段,在資源數允許的情況下儘可能的保持每一個鏈接存活時間長。現在的趨勢是使用事件驅動的 WEB 服務器,通過使用固定的線程池(甚至單個線程)處理所有通訊,從而減少每個連接的成本以及被攻擊的可能性。長連接的缺點是在最後一個 HTTP 連接完成之後,服務器在關閉連接之前會等待一定時間,雖然一個連接不會消耗太多的資源,但是降低了服務器的總體伸縮性。長連接適用於客戶端突發大量請求的場景。

2.3.2 密鑰

  TLS中設計加密算法和密鑰交換算法。
  如何選擇非對稱加密算法,對稱加密算法,加密長度,密鑰交換算法最好根據實際情況進行權衡。
  非對稱加密算法常用的有RSA,ECDSA,ECDSA在性能和安全性上要優於 RSA,256位的 ECDSA (128位加密強度)提供和 3072位的 RSA 一樣的安全性,卻有更好地性能。
  目前有兩種可用的密鑰交換算法:DHE 和 ECDHE。其中 DHE 太慢不推薦使用。 密鑰交換算法的性能取決於配置的協商參數長度。對於DHE,常用的1024和2048位,分別提供80和112位安全等級。橢圓曲線迪菲-赫爾曼金鑰交換(英語:Elliptic Curve Diffie–Hellman key exchange,縮寫爲ECDH),是一種匿名的密鑰合意協議(Key-agreement protocol),這是迪菲-赫爾曼密鑰交換的變種,採用橢圓曲線密碼學來加強性能與安全性。在這個協定下,雙方利用由橢圓曲線密碼學建立的公鑰與私鑰對,在一個不安全的通道中,建立起安全的共有加密資料。

2.3.3 證書

  一次完整的 TLS 握手期間,服務器會把它的證書鏈發送給客戶端驗證。證書鏈的長度和正確性對握手的性能有很大影響。

  1. 使用盡可能少的證書,證書鏈裏的每個證書都會增大握手數據包,證書鏈中包含太多證書有可能導致 TCP 初始擁塞窗口溢出;
  2. 只包含必需的證書,證書鏈裏包含非必需證書是個常見錯誤,每個這樣的證書會給握手協議額外增加1-2KB;
  3. 提供完整的證書鏈,服務器必須提供一個被根證書信任的完整證書鏈;
  4. 使用橢圓曲線證書鏈,因爲 ECDSA 私鑰長度使用更少的位,所以 ECDSA 證書會更小;
  5. 避免同一張證書綁定過多域名,每增加一個域名都會增加證書的大小,對於大量域名來說會有明顯的影響。

2.3.4 吊銷檢查

  雖然證書吊銷狀態在不斷變化,並且用戶代理對證書吊銷的行爲差異很大,但是作爲服務器,要做的就是儘可能快地傳遞吊銷信息。

  1. 使用OCSP,信息的證書 OCSP 被設計用於提供實時查詢,允許用戶代理只請求訪問網站的吊銷信息,查詢簡短而快速(一個HTTP請求)。相比之下 CRL 是一個包含大量被吊銷證書的列表;
  2. 使用具有快速且可靠的 OCSP 響應程序的 CA,不同 CA 之間的 OCSP 響應程序性能不同,在你向 CA 提交之前先檢查他們的歷史 OCSP 響應程序。 另一個選擇 CA 的標準是它更新 OCSP 響應程序的速度;
  3. 部署 OCSP stapling,OCSP stapling 是一種允許在 TLS 握手中包含吊銷信息(整個OCSP響應)的協議功能。啓用之後,通過給予用戶代理進行吊銷檢查的全部信息以帶來更好地性能,可以省去用戶代理通過獨立的連接獲取 CA 的 OCSP 響應程序來查詢吊銷信息。

2.3.5 協議兼容和硬件加速

  如果你的服務器與一些新版本協議的特性(例如TLS 1.2)不兼容,瀏覽器可能需要通過與服務器進行多次嘗試,才能協商一個加密的連接。確保良好的 TLS 性能的最好方式是升級最新的 TLS 協議棧以支持較新的協議版本和擴展。
  隨着 CPU 速度的不斷提高,基於軟件的 TLS 實現在普通 CPU 上已經運行得足夠快,無需專門的加密硬件就能處理大量的 HTTPS 請求。但安裝加速卡或許能夠提升速度。

2.4 CDN

  使用 CDN 可以實現世界級的性能,它利用地理上分散的服務器提供邊緣緩存和流量優化。
  當用戶離你的服務器越遠,訪問網絡就越慢,在這種情況下連接建立是一個很大的限制因素。爲了服務器儘可能靠近最終用戶,CDN 經營着大量的地理分佈的服務器,它可以提供兩種降低延遲的方式,即邊緣緩存和連接管理。

2.4.1 邊緣緩存

  由於 CDN 服務器貼近用戶,可以將你的文件提供給用戶,就像你的服務器真的在那裏一樣。

2.4.2 連接管理

  如果你的內容是動態的、用戶特定的,那麼久無法通過 CDN 緩存數據。但是,一個不錯的 CDN 即使沒有任何緩存,也能通過連接管理提供幫助,那就是它可以通過長時間保持的長連接消除大部分建立連接的成本。
  建立連接期間大部分的時間都花在等待上面。爲了儘量較少等待,CDN 通過自己的基礎設置將流量路由到距離目的地最近的一個點。因爲是 CDN 自己完全可控的服務器,它可以內部保持長連接很長一段時間。
  當使用 CDN 時,用戶連接到最近的 CDN 節點,這隻有很短的距離,TLS 握手的網絡延遲也很短;而 CDN 與服務器之間可以直接複用已有的遠距離長連接。這意味着與 CDN 快速初始 TLS 握手後,用戶與服務器就建立了有效連接。

參考

維基-HTTPS
HTTPS加密(握手)過程
How does https works?
how https works
對稱加密和非對稱的加密 的優缺點和理解
維基-TLS
HTTP與HTTPS的區別
TCP參數調優詳解
HTTP2.0與HTTP1.0的區別
HTTP2的優點
維基-ECDHE
HTTPS 之 TLS 性能調優

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章