Can you summarize the following document?
        
  在大多數情況中(不包括SDCH),協商使用兩個步驟完成,這描述在RFC 2616:  1. 網頁客戶端在HTTP請求的頭部通告其支援的壓縮方案為一個標記列表(tokens)。對於Content-Encoding,這個列表稱作Accept-Encoding;對於Transfer-Encoding,該欄位被稱為TE。2. 如果伺服器支援一種或多種壓縮方案,輸出的資料可能用一種或多種雙方支援的方法壓縮。如果是這種情況,伺服器將在HTTP響應中新增一個Content-Encoding或Transfer-Encoding欄位表明使用的方案,用逗號分隔。  網頁伺服器本身沒有義務使用任何壓縮方法——這取決於網頁伺服器的內部設定,並可能依賴於網站的內部架構。  在SDCH的情況下,完成一份字典協商也是必須的,其中可能涉及額外的步驟,比如從外部伺服器下載一個合適的字典。

  伺服器和客戶端的標記(token)的官方列表由IANA維護,它包括: 除此之外,一些非官方或非標準化的標記也已被一些伺服器或客戶端使用:  HTTP中的壓縮也可以使用伺服器指令碼語言(例如PHP;或者程式語言,例如Java)來實現。

  2009年Google工程師Arvind Jain和Jason Glasgow的文章指出,每天有超過99人年的時間由於使用者沒有接收到已壓縮內容而增加的頁面載入時間而浪費。這可能發生於:反病毒軟體檢查連線導致內容變為未壓縮;使用代理伺服器(網頁伺服器為保相容性而放棄壓縮);伺服器配置不當;瀏覽器遇到問題而停止使用壓縮。Internet Explorer 6在使用代理伺服器時會回退到使用HTTP 1.0(沒有壓縮、流水線等特性)——這是企業環境中的常見配置——這也是主流瀏覽器最常遇到的,回落到未壓縮HTTP的情況。  另一個大規模部署HTTP壓縮遇到的問題是,deflate編碼的定義:HTTP 1.1將deflate編碼定義為將deflate壓縮(<nowiki>RFC 1951</nowiki>)的資料放入一個zlib格式的資料流(RFC 1950),而微軟伺服器和客戶端產品歷來將它實現為“原樣”("raw")資料流,這使其部署是不可靠的。出於此原因,部分軟體(包括Apache HTTP Server)只實現gzip編碼。

  2012年,一種對資料壓縮不利的普遍性攻擊被公佈,它被稱為CRIME。CRIME攻擊可能對大量協議產生效果,包括但不限於TLS以及應用層協議(例如SPDY或HTTP)。只有針對TLS和SPDY的攻擊被論證,並且在瀏覽器和伺服器中得到了大幅緩解。CRIME利用的HTTP壓縮沒有得到全面的緩解,即使CRIME的作者已經警告說,該漏洞的影響範圍可能比SPDY和TLS的壓縮更廣泛。  2013年,涉及HTTP壓縮的CRIME攻擊新例項被髮布,這被稱為BREACH。BREACH攻擊可以在30秒內從TLS加密的網頁流量中提取登入令牌、電子郵件地址或其他敏感資訊(時間取決於要提取的位元組數),這也可能使攻擊者誘騙受害者訪問惡意的網站連結。TLS和SSL的所有版本都受到了BREACH的影響,無論使用何種加密演算法或密碼本。 不同於以往的CRIME例項,那些都可以通過關閉TLS壓縮或SPDY頭壓縮緩解攻擊;BREACH利用的HTTP壓縮基本上不能關閉,因為幾乎所有網頁伺服器都依賴它提高與使用者的資料傳輸速度。
HTTP壓縮是一種內建到網頁伺服器和網頁客戶端中以改進傳輸速度和頻寬利用率的方式。