組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者： 徐標（xbxiaoer  xub@mail.ndsc.com.cn）
譯文發布時間：2002-3-1
版權：本中文翻譯文檔版權歸中國互動出版網所有?？梢杂糜诜巧虡I用途自由轉載，但必須保留本文檔的翻譯及版權信息


Network Working Group                                                  J. Woods
Request for Comments: 1979                                        Proteon, Inc.
Category: Informational                                             August 1996

                        
           PPP Deflate壓縮協議（PPP Deflate Protocol）

備忘錄的狀態
   本備忘錄為Internet團體提供信息。不在任何形式上規定一個Internet標準。發布本備忘錄不受任何限制。
摘要   
   點到點協議（PPP）[1]提供了一種在點到點鏈路上傳輸多協議數據報的標準方法。壓縮控制協議（CCP）[2]提供了一種在PPP封裝鏈路上協商和使用壓縮協議的方法。本文檔描述了如何使用PPP Deflate壓縮協議壓縮PPP封裝報文。
目錄
     1.   介紹 .......................... .......................... .. ........2   
        1.1 使用許可..... ..... ..... ..... ..... ..... ..... ..... ..... .....2
     2.     PPP Deflate 報文 ..   .............................................3
        2.1       報文格式      ...............................................4
     3.     構造選項格式 ......................................................5
     安全考慮 .................................................................6
     參考資料 .................................................................6
     致謝 .....................................................................7
     主席地址 .................................................................7
    作者地址 .................................................................7

介紹  
被PKZIP和gzib壓縮機制使用，并且被收錄到自由和廣泛發布的zlib庫源代碼，“deflate”壓縮格式[3]有以下特點；
       —一個明顯的不受限制的編碼和壓縮算法，和開放的公共可用的規范。

       —對不可壓縮數據的低開支的避開機制。PPP Deflate 規范提供了更大程度上減少開支的選項。
      
       —很廣泛的使用在網絡、調制解調器和其他點到點鏈路上為個人計算機和工作站傳輸文件。
       
      —對壓縮方和解壓縮方來說，使用少于64K的內存，可以在Calgary corpus[5]上很容易的達到2：1的壓縮率。

1.1 使用許可

      zlib源代碼是廣泛的和自由的使用，遵守以下版權：
      (C) 1995 Jean-Loup Gailly and Mark Adler

提供本軟件完全隨意，不需要任何表示或者隱含的保證。軟件的作者不對因為使用本軟件而帶來的損害負有任何責任。

    授權給為任何目的使用本軟件的任何人，包括商用程序，可以自由的改變和重新發布本軟件。遵守以下限制：
       
       1.本軟件的原始資料不能被歪曲，不能聲明你寫的最原始的軟件。如果你在你的產品里使用了本軟件，應該在該產品文檔里面表示致謝，但這并不是要求。
 
       2. 對源版本的任何改變必須明白的標出，而且絕對不允許不如實的反映源軟件。
      
       3. 本提示可以從任何發布的源文件中移出或改變。

       Jean-Loup Gailly        Mark Adler
       gzip@prep.ai.mit.edu    madler@alumni.caltech.edu

      如果你在你的產品中使用了zlib庫，我們很不情愿收到冗長的要簽署的法律文件。源代碼是免費提供，不需要任何形式的授權。這個庫是完全由Jean-Loup Gailly 和 Mark Adler寫成，不包含第三方的代碼。
  
   Deflate格式和壓縮算法是基于Lempel-Ziv LZ77壓縮。為了支持其專利免費狀態，GNU計劃和小型網絡圖形（Portable Network Graphics）工作組做了更廣泛的研究。

2.  PPP Deflate 報文
    在傳輸任何PPP Deflate報文被之前，PPP必須達到網絡層協議（Network-Layer Protocol）階段，CCP控制協議必須達到開放（Opened）狀態
    一個Deflate數據報被封裝在PPP的信息域中，同時PPP協議域內容是0xFD 或者0xFB。當不使用PPP多鏈路協議或者在多鏈路之“上（above）”時使用0xFD，當為了在一個多鏈路束的單鏈路上單獨進行壓縮，在多鏈路之“下（below）”時使用0xFB。
在一個PPP鏈路上傳輸的PPP Deflate數據報的最大長度和一個PPP封裝報文的信息域（Information field）的最大長度是一樣的。
    PPP報文中，只有其PPP協議號在0x0000到0x3FFF范圍內，并且不是0xFD和0xFB的才能被壓縮，其他報文總是不被壓縮的傳輸。控制報文是很少的，因為軟件健壯性的原因不被壓縮。
  
   填充（Padding）

    如果填充被加到報文里面，PPP Deflate報文要求Self-Describing-Padding構造選項在此之前被協商。如果不增加填充，Self-Describing-Padding不需要協商。
 
   可靠性和順序性（Reliability and Sequencing）

    PPP Deflate要求按順序傳送報文。它依賴Reset-Request 和 Reset-Ack LCP報文或者重新協商壓縮控制協議（CCP）[2]來顯示在發送端和接收端之間同步被破壞。LCP的 FCS探測到損壞的報文，正常的處理機制丟棄他們。在解碼之前通過順序號探測丟失的或者失序的報文。
    當探測到一個順序號錯誤后，除了發送Reset-Request外，接收端MAY立刻通過發送一個新的CCP Configure-Request來強迫CCP放棄Opened狀態。不過這個方法比使用Reset-Requests要花費更大的代價。
    當接收端第一次遇到一個異常的順序號，它SHOULD發送一個Reset-Requests LCP報文。Reset-Requests報文在壓縮控制協議里面已經定義。發送端發送了一個Reset-Ack或者接收端收到了一個Reset-Ack報文后，他們必須重置順序號為0，清空壓縮字典，重新發送或者接收報文。接收端MUST丟棄所有探測到錯誤后收到的報文，直到它接收到Reset-Ack報文。這種處理策略可以這么認為：放棄一個傳輸“文件”，開始另外一個新“文件”的傳輸。
    每次接收到一個Reset-Request，傳輸端必須清空它的壓縮歷史和發送一個應答Reset-Ack，因為他不知道在次以前發送的Reset-Ack是否已經到達接收端。接收端收到一個Reset-Ack后不需要對他的壓縮歷史做任何事情，因為發送端不會再參考任何以前的歷史（‘deflate’是一種滑動窗口壓縮）。
     如果鏈路繁忙，在接收到Reset-Ack之前，發現一個解壓錯誤時可能后面已經跟著幾個錯誤。發送Reset-Requests的頻率大于鏈路的round-trip-time是不合適宜的。因為多余的Reset-Requests 會導致沒有必要的壓縮字典的清空。
每收到一個壓縮的或者沒壓縮的報文，接收端MAY發送一個附加的Reset-Request直到收到一個Reset-Ack，但是接收端不應該發送另外一個Reset-Request除非上一個Reset-Request的Reset-Ack晚了。接收端要發送足夠多的Reset-Request來確保發送端收到至少一個Reset-Request。舉個例子，接收端可以選擇每秒發送一個Reset-Request。（或者已經接收到Reset-Ack并且解壓器已經啟動）

   數據擴展（Data Expansion）
      
      在本標準中使用的‘deflate’會擴展不可壓縮數據大約14-18個字節（8個字節是最壞情況下的‘defalte’等級，2個另外的字節是‘deflate’塊尾（end-of-block）和零長（zero-length）同步塊頭，兩個字節的順序號，另外增加PPP協議域到發送的數據單元占兩個字節。）
      BSD壓縮建議草稿 [7]描述了一種對不可壓縮數據逃逸機制，是交替使用一種對變量的讓人刺激的復雜的因素分層違反和潛在的不可預測的有效的MTU長度。直接的逃逸機制同樣也用在這里。
      如果一個不可壓縮數據報文不符合鏈路的MRU，那么這個報文MUST用它的最原始狀態被發送，并且不被CCP封裝。PPP報文
當收到一個PPP協議號在0x0000到0x3FFF（理所當然應該除去0Xfd 0Xfb）范圍內，假設已經造成報文擴展，報文被本地地增加到壓縮歷史中去。(按照已經定義的‘deflate’格式，這樣做的一個簡便方便的方法是本地化解壓一個適當的長度存儲塊的頭，后面是實際數據塊，或者可以簡單的附加在接收端的歷史中，這依賴執行細節)。
     
      在他們的本地封裝中發送不可壓縮報文可以避免最大傳輸單元復雜化。如果未壓縮報文比他們的本地形式要大，對執行的上層來說，有必要認為PPP鏈路有一個較小的MTU，來確保經過壓縮處理后的不可壓縮數據絕對不會大于協商的PPP MTU。
      
對不可壓縮報文的本地封裝使執行復雜化。發送端和接收端必須用在同一個報文時向字典里面添加信息，不是為了同步而等到一個壓縮的報文的到來。清空字典后的前幾個報文通常是不可壓縮的，最可能的是用本地封裝把他們發送出去，就好象處理沒有執行壓縮之前的報文。如果CCP或者LCP報文從網絡層被分開處理（例如，用一個‘daemon’來處理控制報文，‘kernel code’來處理數據報文），必須注意確保發送端用開始壓縮前的configure-ACK 或 Reset-Ack同步清空字典，同時接收端也必須類似的確保在處理下一個報文之前清空字典。
      
2.1   報文格式
   下面是PPP  Deflate 報文格式概略圖。
   域從左向右傳輸。
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PPP Protocol          |           Sequence            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Data ...
   +-+-+-+-+-+-+-+-+

   PPP 協議域（PPP Protocol）

      PPP 協議域在Point-to-Point Protocol Encapsulation[1]中描述。
     如果通過PPP 壓縮控制協議（CCP）[2]成功協商了PPP Deflate壓縮協議，那么協議域的值是0XFD或OXFB，如果Protocol-Field-Compression已經協商，這個址MAY被壓縮。
   
   順序號域（Sequence）
      
      順序號是被發送的最有意義的八位字節。當字典清空的時候，它從0開始，對每個報文來說每次加1（包括未壓縮的報文）。順序號大于65535時變為0。
      順序號確保丟失或者失序的報文不會導致對端的壓縮數據庫變為不同步的。如果遇到一個意外的順序號，必須發送Reset-Request 或 Configure-Request報文來使壓縮字典重新同步。順序號在一個壓縮報文被解碼之前應該被檢查。
   
   數據

      壓縮后的PPP封裝報文，由原始的、未壓縮的報文的協議和數據域組成。
      協議域壓縮MUST應用于在順序號被計算之前或者整個報文被壓縮之前的最原始的報文的協議域，不論協議域壓縮是否被協商。這樣，如果原始的協議號小于0x100，肯定會被壓縮為一個單字節。
     壓縮數據的基本格式在‘Deflate’的Compressed Data Format Specification[3]中被描述。當不可壓縮數據重置傳輸端狀態時，為了確保同步，每一個被發送的報文必須以一個‘deflate’塊邊界開始。為了做到這點，每一個被發送的報文用一個零長（zero-length）的‘deflate’未壓縮塊（non-compressed）。這就意味著壓縮數據的最后四個字節必須是0x00 0x00 0xFF 0xFF。這些字節在傳輸前必須被移走，如果執行需要的話接收端能夠重新把他們插入。
3.  構造選項格式
   描述
    CCP PPP Deflate 構造選項在PPP鏈路上協商使用PPP Deflate壓縮算法。默認或者最后協商失敗，不使用任何壓縮算法。
   下面是PPP Deflate 構造選項格式的概要圖。域從左項、向右傳輸。
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |Window | Method|    MBZ    |Chk|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type（類型）
      26
   Length（長度）
      3
   Window（窗口）
     
      表示解壓器能夠迅速分配的最大窗口的大小。是LZ77窗口大小取以2為底的對數，減8。‘Deflate’順應解壓器必須能夠接受最大32K的窗口大小，用值7表示。一個‘deflate’順應壓縮器可以自由的使用簡化的窗口大小，所以一個PPP Deflate壓縮器MUST要不接受這樣請求的現在或者拒絕這個玄鄉。
      
   Method（方法）

     必須是二進制的1000。‘zlib’壓縮方法（Method）標志符8對‘deflate’來說是達到32K窗口大小
   MBZ

      所有位必須是0。.
   Chk

      必須所有是0表示順序號校驗方法。

.安全考慮
     本備忘錄不考慮安全問題。

.參考資料

   [1]   Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
         RFC 1661, July 1994.

   [2]   Rand, D., "The PPP Compression Control Protocol (CCP)",
         RFC 1962, June 1996.

   [3]   Deutsch, L.P., "'Deflate' Compressed Data Format
         Specification", draft available in
         ftp.uu.net:/pub/archiving/zip/doc/deflate-1.1.doc.

   [4]   Gailly, J.-L., "Zlib 0.95 beta".

   [5]   Bell, T.C., Cleary, G. G. and Witten, I.H., "Text Compression",
         Prentice_Hall, Englewood Cliffs NJ, 1990.  The compression
         corpus itself can be found in ftp.uu.net:/pub/archiving/zip/.

   [6]   Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994.

   [7]   Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
         August 1996.

致謝
    在不可壓縮報文方面，William Simpson提供了非常有價值的方法從而不使用附加的頭字節。
主席的地址

   可以通過以下地址聯系工作組的主席：
   Karl Fox
   Ascend Communications
   3518 Riverside Drive, Suite 101
   Columbus, Ohio 43221

   EMail: karl@ascend.com

作者的地址

   關于本備忘錄有任何問題可以直接聯系：
   John Woods
   Proteon, Inc.
   9 Technology Drive
   Westborough MA 01581-1799

   (508) 898-2800 ext. 2651
   EMail: jfw@funhouse.com