本備忘錄狀態
This memo PRovides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
版權聲明
Copyright (C) The Internet Society (1999). All Rights Reserved.

摘要
本文檔定義一種標準算法，傳輸控制協議（TCP）的發送方需要使用該算法來計算和維護它們的重發定時器。它擴展了RFC1122的第4.2.3.1節的討論，并且把支持該算法的要求從應該升級到必須。
目錄
1 介紹 2
2 基本算法 2
3 采樣RTT 3
4 時鐘間隔 3
5 維護RTO定時器 3
6 安全考慮 4
鳴謝 4
參考 5
作者地址 5
版權說明 6
致謝 6

1 介紹
傳輸控制協議（TCP）[Pos81]使用一個重發定時器，在缺乏任何遠端的數據接收方反饋的情況下來保障數據的傳遞。該定時器的時間間隔被稱為RTO（重發超時）。RFC1122 [Bra89]指明，RTO應該按照[Jac88]的描述進行計算。
本文檔使設置RTO的算法法規化。另外，本文檔擴展了RFC1122的第4.2.3.1節的討論，并且把支持該算法的要求從應該升級到必須。RFC2581[APS99]描述了該算法，TCP使用它在RTO超時之后和一次重發被發出之后開始發送。本文檔不改變在RFC2581[APS99]中所描述的行為。
在某些情況下，對于一個TCP發送方而言，采用比本文檔下面所要詳述的算法更加保守一點的方法可能更有利一些。然而，一個TCP不可以采用比本文檔下面的算法更為激進的方法。
在本文檔中的要害詞“必須”“不可以”“須要”“將要”“將不”“應該”“不應該”“建議”“可以”“可選”等應該按照[Bra97]中的描述進行翻譯。
2 基本算法
要計算當前的RTO，TCP發送方需要維護兩個狀態變量，SRTT （平滑環回時間）和RTTVAR（環回時間變量）。另外，我們假設一個時鐘間隔G秒。
規定計算SRTT、RTTVAR和RTO的法則如下：
(2.1) 在對一個收發雙方之間所發出的一個段完成回環時間（RTT）測量之前，發送方應該將RTO設置為3秒（見RFC1122 [Bra89]），雖然5.5節中討論的反復重發問題的“還原” 仍然適用。
注重到有一些設施可能采用一種“心跳式”定時器，它能夠產生一個介于2.5秒和3秒之間的值。因此，在該定時器絕不會在短于2.5秒的時間內超時的情況下，作為一個較低的2.5秒的步進也是可以接受的，使用間隔為G的心跳式定時器的設施，它不應該設置該定時器的值低于2.5 + G秒。
(2.2) 當完成第一個RTT測量R時，宿主機必須設置
SRTT <- R
RTTVAR <- R/2
RTO <- SRTT + max (G, K*RTTVAR)
其中K = 4。
(2.3) 當完成一個并發的RTT測量R'時，宿主機必須設置
RTTVAR <- (1 - beta) * RTTVAR + beta * SRTT - R'
SRTT <- (1 - alpha) * SRTT + alpha * R'
用來更新RTTVAR的SRTT的值，就是那個使用第二次分配來更新SRTT之前的SRTT值本身。就是說，更新RTTVAR和SRTT必須按照上述的順序進行計算。
上述計算應該使用alpha=1/8和beta=1/4進行計算（如[JK88]所推薦）。
在計算之后，宿主機必須更新RTO <- SRTT + max (G, K*RTTVAR)。
(2.4) 一旦RTO計算好，假如它小于1秒鐘，則RTO應該補充到1秒。
傳統地，TCP設施使用粗間隔時鐘來測量RTT并觸發RTO，這使得應用于RTO上的最小值很大。研究表明，需要一個很大的最小RTO值來保持TCP的保守，以避免虛假重發 [AP99]。因此，本規范要求有一個很大的最小RTO值作為保守之需，而同時承認，在未來的某個時刻，研究可能表明一個小一些的最小RTO值是可接受的，或者，是優越的。
(2.5) 可以給RTO使用最大值，假如該值至少有60秒。
3 采樣RTT
TCP必須使用Karn的算法[KP87]來采樣RTT。亦即，不可以使用重發過的段進行RTT 采樣（由此，究竟響應是針對于信包的第一個實例還是后來的實例就變得很模糊）。TCP可以安全地從重發段進行RTT采樣的唯一情況是當該TCP使用了時間戳選項[JBB92]，因為時間戳選項去除了關于數據段實例所觸發的響應的不明確性
傳統上，TCP設施一次進行一個RTT測量（典型情況每RTT一次）。然而，當使用時間戳選項時，每一個ACK響應可以用作一個RTT樣本。RFC1323 [JBB92]建議，使用大的阻塞窗口的TCP連接應該在每個數據窗口中采取許多的RTT樣本，以避免被評估的RTT中的假名效應。一個TCP設施必須在每一個RTT期間進行一次RTT測量（除非無法經由Karn的算法計算）。
對于相當適度的阻塞窗口尺寸，研究表明，每段定時并不能導致更好的RTT評估[AP99]。另外，當間于每兩個RTT多次采樣時，在第二節中定義的alpha和beta值可能保持不充分的RTT歷史。一種改變這些常量的辦法目前還是一個開放的研究問題。
4 時鐘間隔
在計算RTT度量和不同狀態變量的時候，不需要使用時鐘間隔。然而，假如在RTO計算中的K*RTTVAR項等于零，則間隔出現的不一致情況必須經由擴展達到G秒（亦即，使用步驟2.3中的方程）。
RTO <- SRTT + max (G, K*RTTVAR)
經驗表明，更精細的時鐘間隔（<= 100毫秒）某種程度上性能優于更粗的時鐘間隔。
注重到[Jac88]描述了幾種聰明的技巧，可以用來從粗時鐘間隔定時器中獲得更好的時鐘精度。這種方法被廣泛的使用在現存的TCP設施上。
5 維護RTO定時器
一個設施必須維護重發定時器，使得一個段絕不會過早的重發，亦即，在該段的前一次發送之后少于一個RTO的時間里重發。
下面是推薦的維護重發定時器的算法。
(5.1) 每一次一個包含數據的包被發送（包括重發），假如該定時器沒有運行則啟動它，使得它在RTO秒之后超時（按照當前的RTO值）。
(5.2) 當所有的發出數據都被確認之后，關閉該重發定時器。
(5.3) 當接收到一個ACK確認一個新的數據，重新啟動該重發定時器，使得它在RTO秒之后超時（按照當前的RTO值）。
當重發定時器超時后，作下列事情：
(5.4) 重發最早的尚未被TCP接收方響應的段。
(5.5) 宿主機必須設置RTO <- RTO * 2（“還原定時器”）。在上面(2.5)中討論的最大值可以用來為該兩倍乘操作提供一個上限。
(5.6) 啟動重發定時器，使得在RTO秒之后它會超時（對于5.5所描述的兩倍乘操作之后的RTO的值而言）。
注重到在重發之后，一旦一個新的RTT測量完成（這只有在新的數據被發出并且得到響應時才會發生），在第二節中描述的計算就會執行，包括RTO計算，而這可能會導致“崩潰的”RTO在按指數補償之后被放棄（規則5.5）。
注重到一個TCP設施可能在還原定時器多次之后清除SRTT和RTTVAR的值，因為有可能當前的SRTT和RTTVAR的值在此情況下是偽造的。一旦SRTT和RTTVAR被清除，它們需要使用下一個按照2.2的RTT采樣而不是使用2.3的采樣進行初始化。
6 安全考慮
本文檔要求一個TCP在一個未被響應的段被重發之前等待一個給定的時間間隔。攻擊行為可能造成一個TCP發送方因為增加延時到被定時的信包反應時間上，或者增加延時到它的響應上，而造成RTO計算值過大。然而，對一個信包的反應時間添加延時的能力經常與導致信包丟失的能力相一致，因此很難看出攻擊者能夠從這種可能導致比簡單丟失某些TCP連接的信包更危險的攻擊當中獲得什么好處。
Internet在某種相當大的程度上依靠于正確實施RTO算法（它在RFC2581中也有描述）， 以保持網絡的穩定性，并且避免阻塞性崩潰。一個攻擊者可能造成TCP端節點在面臨阻塞時，通過在接收方真正接收到數據之前強行響應數據段的方法，反應更加激進一些，而因此將RTO降低到一個不安全的值。但是，這樣做需要正確地欺騙響應動作，而這是非常困難的，除非該攻擊者可以控制在收發雙方之間的路徑上的流量。另外，即使假如攻擊者可以引起發送方的RTO達到非常小的值，這顯示出該攻擊者不能調控這種行為使之成為一種攻擊（這比較于他們可以造成的其他危險而言，假如他們能夠欺騙那些屬于該連接的信包的話），因為發送方TCP在面臨由真正阻塞引起的不正常的發送出去的信包丟失時，仍然能夠還原它的定時器值。
鳴謝
本備忘錄中所描述的算法是由Van Jacobson在[Jac88]中創建的。
參考
[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM 99.
[APS99] Allman, M., Paxson V. and W. Stevens, "TCP Congestion Control", RFC2581, April 1999.
[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC1122, October 1989.
[Bra97] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997.
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
[JK88] Jacobson, V. and M. Karels, "Congestion Avoidance and Control", FTP://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 87.
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC793, September 1981.
作者地址
Vern Paxson
ACIRI / ICSI
1947 Center Street
Suite 600
Berkeley, CA 94704-1198

Phone: 510-666-2882
Fax: 510-643-7684
EMail: vern@aciri.org
http://www.aciri.org/vern/

Mark Allman
NASA Glenn Research Center/BBN Technologies
Lewis Field
21000 Brookpark Rd. MS 54-2
Cleveland, OH 44135

Phone: 216-433-6586
Fax: 216-433-8705
EMail: mallman@grc.nasa.gov
http://roland.grc.nasa.gov/~mallman
版權說明
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise eXPlain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all sUCh copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
致謝
Funding for the RFCEditor function is currently provided by the Internet Society.