https傳輸長文本時是否會先壓縮再加密傳輸？

01-01

加入文本有1MB，如果人為採用某演算法壓縮，可以壓縮至20KB。
那麼問題來了，HTTPS在傳輸數據時，為了增加傳輸速度，是否有自動壓縮的功能，先對文本壓縮，再加密，再解密，再解壓？
如果沒有，是否我們需要提前壓縮文本，然後再使用https傳輸？

----------------------------------------------------
edit：看到stackoverflow上有人說https開啟gzip會有security vulnerability(BREACH/CRIME)，所以實際上沒什麼人開啟gzip嗎？

https - Can you use gzip over SSL? And Connection: Keep-Alive headers
nginx - HTTPS + gzip: Is it a security vulnerability if I only gzip non-sensitive files?

HTTP服務可以啟用gzip模塊，會自動對內容進行壓縮，採用的是DEFLATE（同時使用哈夫曼編碼和LZ77演算法的一個無損數據壓縮演算法）。

HTTPS也是一樣。

實際上純文本自己壓縮是不划算的，因為zip或者rar文件還需要進行一次編碼才能通過HTTP協議傳輸，實際尺寸還會略大。

ssl協議裡面在傳輸數據的時候是有壓縮這個步驟的，它是分塊、壓縮、計算校驗碼、加密，最後封裝。

HTTPS起到兩個作用，一是加密二是防篡改。

CRIME漏洞的原理是：如果啟用壓縮，攻擊者可以通過選擇明文來與被加密的其他數據一同發送，因為HTTPS不加密關於數據原文長度的信息，可以通過比較原文與密文的長度計算壓縮率，如果與被加密數據的明文有重合的話壓縮率會提高，如果沒有重合的話壓縮率則會降低。這時可以採用分治演算法的輸入不斷選擇明文最終推斷密文的內容。唯一的解決方法就是在啟用HTTPS禁用壓縮。

當然如果是js, css等主要是為了防篡改而啟用https的資源，gzip壓縮並無影響。

需要注意的是微軟為了防止IE受到影響，如果啟用HTTPS就會停止支持壓縮。

HTTPS協議實際上包含了HTTP協議和STL/SSL協議兩層。這兩層協議又有各自獨立的壓縮邏輯。

CRIME是針對STL層壓縮的攻擊。BREACH是針對HTTP層壓縮的攻擊。

這些壓縮邏輯都是協議自帶的，瀏覽器會自動選擇是否壓縮，你沒必要操心。