[要約] 要約：RFC 2525は、既知のTCP実装の問題を文書化したものであり、TCPプロトコルの実装者に対して問題の認識と解決策を提供することを目的としています。目的：RFC 2525の目的は、TCP実装の問題を特定し、それらの問題に対する解決策を提供することにより、TCPプロトコルの信頼性とパフォーマンスを向上させることです。
Network Working Group V. Paxson
Request for Comments: 2525 Editor
Category: Informational ACIRI / ICSI
M. Allman
NASA Glenn Research Center/Sterling Software
S. Dawson
Real-Time Computing Laboratory
W. Fenner
Xerox PARC
J. Griner
NASA Glenn Research Center
I. Heavens
Spider Software Ltd.
K. Lahey
NASA Ames Research Center/MRJ
J. Semke
Pittsburgh Supercomputing Center
B. Volz
Process Software Corporation
March 1999
Known TCP Implementation Problems
Status of this Memo
このメモの位置付け
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 Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Table of Contents
目次
1. INTRODUCTION....................................................2
2. KNOWN IMPLEMENTATION PROBLEMS...................................3
2.1 No initial slow start........................................3
2.2 No slow start after retransmission timeout...................6
2.3 Uninitialized CWND...........................................9
2.4 Inconsistent retransmission.................................11
2.5 Failure to retain above-sequence data.......................13
2.6 Extra additive constant in congestion avoidance.............17
2.7 Initial RTO too low.........................................23
2.8 Failure of window deflation after loss recovery.............26
2.9 Excessively short keepalive connection timeout..............28
2.10 Failure to back off retransmission timeout..................31
2.11 Insufficient interval between keepalives....................34
2.12 Window probe deadlock.......................................36
2.13 Stretch ACK violation.......................................40
2.14 Retransmission sends multiple packets.......................43
2.15 Failure to send FIN notification promptly...................45
2.16 Failure to send a RST after Half Duplex Close...............47
2.17 Failure to RST on close with data pending...................50
2.18 Options missing from TCP MSS calculation....................54
3. SECURITY CONSIDERATIONS........................................56
4. ACKNOWLEDGEMENTS...............................................56
5. REFERENCES.....................................................57
6. AUTHORS' ADDRESSES.............................................58
7. FULL COPYRIGHT STATEMENT.......................................60
This memo catalogs a number of known TCP implementation problems. The goal in doing so is to improve conditions in the existing Internet by enhancing the quality of current TCP/IP implementations. It is hoped that both performance and correctness issues can be resolved by making implementors aware of the problems and their solutions. In the long term, it is hoped that this will provide a reduction in unnecessary traffic on the network, the rate of connection failures due to protocol errors, and load on network servers due to time spent processing both unsuccessful connections and retransmitted data. This will help to ensure the stability of the global Internet.
このメモは知られているTCPの実装上の問題の数をカタログ。そうすることで目標は、現在のTCP / IP実装の品質を向上させることにより、既存のインターネットの状況を改善することです。両方のパフォーマンスと正確性の問題は、問題とその解決策の実装者が意識することによって解決できることを期待しています。長期的には、原因失敗した接続と再送データの両方を処理する時間にネットワークサーバ上のネットワーク上の不要なトラフィックの減少、プロトコルエラーによる接続障害の割合、および負荷を提供することが期待されます。これは、グローバルなインターネットの安定性を確保するのに役立ちます。
Each problem is defined as follows:
次のようにそれぞれの問題が定義されています。
Name of Problem The name associated with the problem. In this memo, the name is given as a subsection heading.
問題の問題に関連した名前です。このメモでは、名前は、サブセクションの見出しとして与えられています。
Classification One or more problem categories for which the problem is classified: "congestion control", "performance", "reliability", "resource management".
問題が分類された分類の一つまたは複数の問題カテゴリ：「輻輳制御」、「パフォーマンス」、「信頼性」、「リソース管理」。
Description A definition of the problem, succinct but including necessary background material.
説明に必要な背景素材を含む簡潔問題の定義、しかし。
Significance A brief summary of the sorts of environments for which the problem is significant.
意義の問題が重要であるために環境の種類の簡単な要約。
Implications Why the problem is viewed as a problem.
問題が問題視されるのはなぜな意味。
Relevant RFCs The RFCs defining the TCP specification with which the problem conflicts. These RFCs often qualify behavior using terms such as MUST, SHOULD, MAY, and others written capitalized. See RFC 2119 for the exact interpretation of these terms.
関連のRFC RFCは、問題が競合しているとTCPの仕様を定義します。これらのRFCは、多くの場合、このようなMUST、SHOULD、MAY、および大文字で書かれた他の人のような用語を使用して動作を修飾します。これらの用語の正確な解釈については、RFC 2119を参照してください。
Trace file demonstrating the problem One or more ASCII trace files demonstrating the problem, if applicable.
該当する場合、問題を実証する問題の一つまたは複数のASCIIトレースファイルを実演するトレースファイル。
Trace file demonstrating correct behavior One or more examples of how correct behavior appears in a trace, if applicable.
正しい動作に該当する場合、トレースにどのように表示されるか、正しい行動の1つの以上の例を実証したファイルをトレースします。
References References that further discuss the problem.
さらに問題を議論参照参照。
How to detect How to test an implementation to see if it exhibits the problem. This discussion may include difficulties and subtleties associated with causing the problem to manifest itself, and with interpreting traces to detect the presence of the problem (if applicable).
それは、問題を示すかどうかを確認するために実装をテストする方法を検出する方法。この議論は、それ自体を明示するために問題の原因とし、（該当する場合）、問題の存在を検出するためにトレースの解釈に伴う困難と微妙を含むことができます。
How to fix For known causes of the problem, how to correct the implementation.
実装を修正するためにどのような問題の既知の原因については、修正する方法。
Name of Problem No initial slow start
問題ありません最初のスロースタートの名前
Classification Congestion control
分類輻輳制御
Description When a TCP begins transmitting data, it is required by RFC 1122, 4.2.2.15, to engage in a "slow start" by initializing its congestion window, cwnd, to one packet (one segment of the maximum size). (Note that an experimental change to TCP, documented in [RFC2414], allows an initial value somewhat larger than one packet.) It subsequently increases cwnd by one packet for each ACK it receives for new data. The minimum of cwnd and the receiver's advertised window bounds the highest sequence number the TCP can transmit. A TCP that fails to initialize and increment cwnd in this fashion exhibits "No initial slow start".
説明TCPは、データの送信を開始するとき、一つのパケット（最大サイズのセグメント）に、その輻輳ウィンドウCWNDを初期化することによって、「スロースタート」に従事すること、RFC 1122 4.2.2.15によって必要とされます。 （[RFC2414]に記載されTCPの実験的変化は、初期値幾分より大きい一つのパケットを可能にすることに留意されたい。）これは、その後、それぞれ、新しいデータのための受信ACKを1個のパケット分のcwndを増加させます。 cwndと受信機の広告ウィンドウの最小値は、TCPが送信できる最大のシーケンス番号の境界。この方法でのcwndを初期化し、増分に失敗TCPは、「いいえ初期スロースタート」を示しません。
Significance In congested environments, detrimental to the performance of other connections, and possibly to the connection itself.
他の接続の性能に有害、そしておそらく接続自体に混雑した環境では、意義。
Implications A TCP failing to slow start when beginning a connection results in traffic bursts that can stress the network, leading to excessive queueing delays and packet loss.
含意TCPは、過度のキューイング遅延やパケット損失につながる、ネットワークを強調することができますトラフィックバーストの接続結果を開始するとき、開始を遅くすることができません。
Implementations exhibiting this problem might do so because they suffer from the general problem of not including the required congestion window. These implementations will also suffer from "No slow start after retransmission timeout".
彼らは必要な輻輳ウィンドウを含めないの一般的な問題に苦しむので、この問題を呈する実装はそうかもしれません。これらの実装はまた、「再送タイムアウトの後にノースロースタート」に苦しむだろう。
There are different shades of "No initial slow start". From the perspective of stressing the network, the worst is a connection that simply always sends based on the receiver's advertised window, with no notion of a separate congestion window. Another form is described in "Uninitialized CWND" below.
「いいえ初期スロースタート」のさまざまな色合いがあります。ネットワークを重視する観点から、最悪の事態は単純に常に別の輻輳ウィンドウの概念と、受信側の広告ウィンドウに基づいて送信する接続です。別の形態は、下記の「初期化されていないCWND」に記載されています。
Relevant RFCs RFC 1122 requires use of slow start. RFC 2001 gives the specifics of slow start.
関連のRFCのRFC 1122は、スロースタートを使用する必要があります。 RFC 2001は、スロースタートの詳細を提供します。
Trace file demonstrating it Made using tcpdump [Jacobson89] recording at the connection responder. No losses reported by the packet filter.
トレース・ファイルは、それが接続応答での記録[Jacobson89]のtcpdumpを使用して作られて実証しました。パケットフィルタによって報告されていない損失はありません。
10:40:42.244503 B > A: S 1168512000:1168512000(0) win 32768 <mss 1460,nop,wscale 0> (DF) [tos 0x8] 10:40:42.259908 A > B: S 3688169472:3688169472(0) ack 1168512001 win 32768 <mss 1460> 10:40:42.389992 B > A: . ack 1 win 33580 (DF) [tos 0x8] 10:40:42.664975 A > B: P 1:513(512) ack 1 win 32768 10:40:42.700185 A > B: . 513:1973(1460) ack 1 win 32768 10:40:42.718017 A > B: . 1973:3433(1460) ack 1 win 32768 10:40:42.762945 A > B: . 3433:4893(1460) ack 1 win 32768 10:40:42.811273 A > B: . 4893:6353(1460) ack 1 win 32768 10:40:42.829149 A > B: . 6353:7813(1460) ack 1 win 32768 10:40:42.853687 B > A: . ack 1973 win 33580 (DF) [tos 0x8] 10:40:42.864031 B > A: . ack 3433 win 33580 (DF) [tos 0x8]
10：40：42.244503 Bは> A：S 1168512000：1168512000（0）32768 <MSS 1460、NOP、wscale 0>を獲得[0x8というTOS]（DF）10：40：42.259908 A> B：S 3688169472：3688169472（0） 40：ACK 1168512001は32768 <MSS 1460> 10に勝つ42.389992 B> A：。 40：ACK 1 [0x8というTOS] 10 33580（DF）を勝つ42.664975 A> B：P 1：40：42.700185 A> B 513（512）、ACK 1 32768 10に勝ちます：。 513：40：42.718017 A> B 1973（1460）ACK 1 32768 10に勝ちます：。 1973：40：42.762945 A> B 3433（1460）ACK 1 32768 10に勝ちます：。 3433：40：42.811273 A> B 4893（1460）ACK 1 32768 10に勝ちます：。 4893：40：42.829149 A> B 6353（1460）ACK 1 32768 10に勝ちます：。 6353：40：42.853687 B> A 7813（1460）ACK 1 32768 10に勝ちます：。 40：42.864031 B> A：ACK 1973 33580（DF）[TOS、0x8という〕10に勝ちます。 ACK 3433 33580（DF）[TOS 0x8という]を勝ち取ります
After the third packet, the connection is established. A, the connection responder, begins transmitting to B, the connection initiator. Host A quickly sends 6 packets comprising 7812 bytes, even though the SYN exchange agreed upon an MSS of 1460 bytes (implying an initial congestion window of 1 segment corresponds to 1460 bytes), and so A should have sent at most 1460 bytes.
第3のパケットの後、接続が確立されます。 、接続応答は、B、接続イニシエータに送信を開始します。 SYN交換（1つのセグメントの初期の輻輳ウィンドウは1460バイトに相当する意味）1460バイトのMSS合意にもかかわらず、迅速に7812バイトを含む6つのパケットを送信ホスト、およびそう最も1460バイトで送信されているべきです。
The ACKs sent by B to A in the last two lines indicate that this trace is not a measurement error (slow start really occurring but the corresponding ACKs having been dropped by the packet filter).
最後の2行中にBによって送信されるACKは、このトレースは、測定誤差（スロースタート実際に発生するが、対応するACKがパケットフィルタによってドロップされた）ではないことを示しています。
A second trace confirmed that the problem is repeatable.
第2のトレースは、問題が再現可能であることを確認しました。
Trace file demonstrating correct behavior Made using tcpdump recording at the connection originator. No losses reported by the packet filter.
接続発信元でtcpdumpの記録を使用して作られた正しい動作を実証したファイルをトレースします。パケットフィルタによって報告されていない損失はありません。
12:35:31.914050 C > D: S 1448571845:1448571845(0) win 4380 <mss 1460> 12:35:32.068819 D > C: S 1755712000:1755712000(0) ack 1448571846 win 4096 12:35:32.069341 C > D: . ack 1 win 4608 12:35:32.075213 C > D: P 1:513(512) ack 1 win 4608 12:35:32.286073 D > C: . ack 513 win 4096 12:35:32.287032 C > D: . 513:1025(512) ack 1 win 4608 12:35:32.287506 C > D: . 1025:1537(512) ack 1 win 4608 12:35:32.432712 D > C: . ack 1537 win 4096 12:35:32.433690 C > D: . 1537:2049(512) ack 1 win 4608 12:35:32.434481 C > D: . 2049:2561(512) ack 1 win 4608 12:35:32.435032 C > D: . 2561:3073(512) ack 1 win 4608 12:35:32.594526 D > C: . ack 3073 win 4096 12:35:32.595465 C > D: . 3073:3585(512) ack 1 win 4608 12:35:32.595947 C > D: . 3585:4097(512) ack 1 win 4608 12:35:32.596414 C > D: . 4097:4609(512) ack 1 win 4608 12:35:32.596888 C > D: . 4609:5121(512) ack 1 win 4608 12:35:32.733453 D > C: . ack 4097 win 4096
12：35：31.914050 C> D：S 1448571845：1448571845（0）勝つ4380 <MSS 1460> 12：35：32.068819 D> C：S 1755712000：1755712000（0）ACK 1448571846 4096勝つ12：35：32.069341 C> D ：。 35：32.075213 C> D：P 1：513（512）、ACK 1勝4608 12：35：32.286073 D> C：ACK 1 4608 12勝ちます。 35：32.287032 C> D：513 12 4096に勝つackを。 513：1025（512）、ACK 1勝4608 12：35：32.287506 C> D：。 1025：1537（512）、ACK 1勝4608 12：35：32.432712 D> C：。 35：ACK 1537は4096 12に勝つ32.433690 C> D：。 1537：2049（512）、ACK 1勝4608 12：35：32.434481 C> D：。 2049：2561（512）、ACK 1勝4608 12：35：32.435032 C> D：。 2561：3073（512）、ACK 1勝4608 12：35：32.594526 D> C：。 35：ACK 3073は4096 12に勝つ32.595465 C> D：。 3073：3585（512）、ACK 1勝4608 12：35：32.595947 C> D：。 3585：4097（512）、ACK 1勝4608 12：35：32.596414 C> D：。 4097：4609（512）、ACK 1勝4608 12：35：32.596888 C> D：。 4609：5121（512）、ACK 1勝4608 12：35：32.733453 D> C：。 ACK 4097は4096に勝ちます
References This problem is documented in [Paxson97].
参考文献は、この問題は、[Paxson97]に記述されています。
How to detect For implementations always manifesting this problem, it shows up immediately in a packet trace or a sequence plot, as illustrated above.
常にこの問題を顕在実装を検出するためにどのように上に示したように、それは、パケットトレースまたはシーケンスプロットにすぐに表示されます。
How to fix If the root problem is that the implementation lacks a notion of a congestion window, then unfortunately this requires significant work to fix. However, doing so is important, as such implementations also exhibit "No slow start after retransmission timeout".
根本的な問題は、実装が輻輳ウィンドウの概念が欠如している、そして残念ながら、これは修正するために重要な作業を必要とすることであるならば修正する方法。そのような実装はまた、「再送タイムアウト後にはスロースタート」を示さないようしかし、そうすることは、重要です。
Name of Problem No slow start after retransmission timeout
再送タイムアウト後に問題はありませんスロースタートの名前
Classification Congestion control
分類輻輳制御
Description When a TCP experiences a retransmission timeout, it is required by RFC 1122, 4.2.2.15, to engage in "slow start" by initializing its congestion window, cwnd, to one packet (one segment of the maximum size). It subsequently increases cwnd by one packet for each ACK it receives for new data until it reaches the "congestion avoidance" threshold, ssthresh, at which point the congestion avoidance algorithm for updating the window takes over. A TCP that fails to enter slow start upon a timeout exhibits "No slow start after retransmission timeout".
TCPは再送タイムアウトを経験する説明は、一つのパケット（最大サイズのセグメント）に、その輻輳ウィンドウCWNDを初期化することによって、「スロースタート」に従事すること、RFC 1122 4.2.2.15によって必要とされます。それは、その後、それぞれが、それはウィンドウを更新するための輻輳回避アルゴリズムが引き継ぎ、その時点で「輻輳回避」閾値、SSTHRESHに達するまで、新しいデータのための受信ACKを1個のパケット分のcwndを増加させます。タイムアウト展示「再送タイムアウト後のノースロースタート」時にスロースタートを入力しなかったTCP。
Significance In congested environments, severely detrimental to the performance of other connections, and also the connection itself.
他の接続のパフォーマンス、また、接続自体に深刻な有害な混雑した環境では、意義。
Implications Entering slow start upon timeout forms one of the cornerstones of Internet congestion stability, as outlined in [Jacobson88]. If TCPs fail to do so, the network becomes at risk of suffering "congestion collapse" [RFC896].
【Jacobson88]に概説されるようにタイムアウト時にスロースタートに入る意味は、インターネット混雑安定性の基礎の1つを形成します。 TCPがそうすることに失敗した場合、ネットワークは、「輻輳崩壊」[RFC896]を患うリスクになります。
Relevant RFCs RFC 1122 requires use of slow start after loss. RFC 2001 gives the specifics of how to implement slow start. RFC 896 describes congestion collapse.
関連のRFCのRFC 1122は損失後のスロースタートを使用する必要があります。 RFC 2001は、スロースタートを実装する方法の詳細を提供します。 RFC 896は、輻輳崩壊を説明します。
The retransmission timeout discussed here should not be confused with the separate "fast recovery" retransmission mechanism discussed in RFC 2001.
ここで説明する再送タイムアウトは、RFC 2001で説明した別の「高速回復」再送信メカニズムと混同してはなりません。
Trace file demonstrating it Made using tcpdump recording at the sending TCP (A). No losses reported by the packet filter.
トレース・ファイルには、送信側TCP（A）でtcpdumpの記録を使用して作られて実証しました。パケットフィルタによって報告されていない損失はありません。
10:40:59.090612 B > A: . ack 357125 win 33580 (DF) [tos 0x8] 10:40:59.222025 A > B: . 357125:358585(1460) ack 1 win 32768 10:40:59.868871 A > B: . 357125:358585(1460) ack 1 win 32768 10:41:00.016641 B > A: . ack 364425 win 33580 (DF) [tos 0x8] 10:41:00.036709 A > B: . 364425:365885(1460) ack 1 win 32768 10:41:00.045231 A > B: . 365885:367345(1460) ack 1 win 32768 10:41:00.053785 A > B: . 367345:368805(1460) ack 1 win 32768 10:41:00.062426 A > B: . 368805:370265(1460) ack 1 win 32768 10:41:00.071074 A > B: . 370265:371725(1460) ack 1 win 32768 10:41:00.079794 A > B: . 371725:373185(1460) ack 1 win 32768 10:41:00.089304 A > B: . 373185:374645(1460) ack 1 win 32768 10:41:00.097738 A > B: . 374645:376105(1460) ack 1 win 32768 10:41:00.106409 A > B: . 376105:377565(1460) ack 1 win 32768 10:41:00.115024 A > B: . 377565:379025(1460) ack 1 win 32768 10:41:00.123576 A > B: . 379025:380485(1460) ack 1 win 32768 10:41:00.132016 A > B: . 380485:381945(1460) ack 1 win 32768 10:41:00.141635 A > B: . 381945:383405(1460) ack 1 win 32768 10:41:00.150094 A > B: . 383405:384865(1460) ack 1 win 32768 10:41:00.158552 A > B: . 384865:386325(1460) ack 1 win 32768 10:41:00.167053 A > B: . 386325:387785(1460) ack 1 win 32768 10:41:00.175518 A > B: . 387785:389245(1460) ack 1 win 32768 10:41:00.210835 A > B: . 389245:390705(1460) ack 1 win 32768 10:41:00.226108 A > B: . 390705:392165(1460) ack 1 win 32768 10:41:00.241524 B > A: . ack 389245 win 8760 (DF) [tos 0x8]
10：40：59.090612 B> A：。 357125を確認応答33580（DF）[TOS、0x8という] 10勝利：40：59.222025 A> Bを：。 357125：40：358585（1460）ACK 1 32768 10に勝つ59.868871 A> Bを：。 357125：41：358585（1460）ACK 1 32768 10に勝つ00.016641 B> A：。 364425を確認応答33580（DF）[TOS、0x8という] 10勝利：41：00.036709 A> Bを：。 364425：41：365885（1460）ACK 1 32768 10に勝つ00.045231 A> Bを：。 365885：41：367345（1460）ACK 1 32768 10に勝つ00.053785 A> Bを：。 367345：41：368805（1460）ACK 1 32768 10に勝つ00.062426 A> Bを：。 368805：41：370265（1460）ACK 1 32768 10に勝つ00.071074 A> Bを：。 370265：41：371725（1460）ACK 1 32768 10に勝つ00.079794 A> Bを：。 371725：41：373185（1460）ACK 1 32768 10に勝つ00.089304 A> Bを：。 373185：41：374645（1460）ACK 1 32768 10に勝つ00.097738 A> Bを：。 374645：41：376105（1460）ACK 1 32768 10に勝つ00.106409 A> Bを：。 376105：41：377565（1460）ACK 1 32768 10に勝つ00.115024 A> Bを：。 377565：41：379025（1460）ACK 1 32768 10に勝つ00.123576 A> Bを：。 379025：41：380485（1460）ACK 1 32768 10に勝つ00.132016 A> Bを：。 380485：41：381945（1460）ACK 1 32768 10に勝つ00.141635 A> Bを：。 381945：41：383405（1460）ACK 1 32768 10に勝つ00.150094 A> Bを：。 383405：41：384865（1460）ACK 1 32768 10に勝つ00.158552 A> Bを：。 384865：41：386325（1460）ACK 1 32768 10に勝つ00.167053 A> Bを：。 386325：41：387785（1460）ACK 1 32768 10に勝つ00.175518 A> Bを：。 387785：41：389245（1460）ACK 1 32768 10に勝つ00.210835 A> Bを：。 389245：41：390705（1460）ACK 1 32768 10に勝つ00.226108 A> Bを：。 390705：41：392165（1460）ACK 1 32768 10に勝つ00.241524 B> A：。 389245は8760（DF）を勝つ確認応答[TOS、0x8という]
The first packet indicates the ack point is 357125. 130 msec after receiving the ACK, A transmits the packet after the ACK point, 357125:358585. 640 msec after this transmission, it retransmits 357125:358585, in an apparent retransmission timeout. At this point, A's cwnd should be one MSS, or 1460 bytes, as A enters slow start. The trace is consistent with this possibility.
358585：最初のパケットがACK点がACKを受信した後、357125. 130ミリ秒であることを示し、Aは、ACK点後357125にパケットを送信します。見かけ再送タイムアウトで、358585：640ミリ秒、この送信した後、それは357125を再送信します。 Aはスロースタートに入ると、この時点で、Aさんにcwndは、1 MSS、または1460バイトでなければなりません。トレースは、この可能性と一致しています。
B replies with an ACK of 364425, indicating that A has filled a sequence hole. At this point, A's cwnd should be 1460*2 = 2920 bytes, since in slow start receiving an ACK advances cwnd by MSS. However, A then launches 19 consecutive packets, which is inconsistent with slow start.
Bは、Aが配列孔を充填したことを示す、364425のACKで応答します。スロースタートにMSSによってcwndをACK進歩を受けるので、この時点で、AのCWNDは、* 2 = 2920 1460バイトであるべきです。ただし、Aは、スロースタートと矛盾している19の連続したパケットを、起動します。
A second trace confirmed that the problem is repeatable.
第2のトレースは、問題が再現可能であることを確認しました。
Trace file demonstrating correct behavior Made using tcpdump recording at the sending TCP (C). No losses reported by the packet filter.
送信TCP（C）でtcpdumpの記録を使用して作られた正しい動作を実演するトレースファイル。パケットフィルタによって報告されていない損失はありません。
12:35:48.442538 C > D: P 465409:465921(512) ack 1 win 4608 12:35:48.544483 D > C: . ack 461825 win 4096 12:35:48.703496 D > C: . ack 461825 win 4096 12:35:49.044613 C > D: . 461825:462337(512) ack 1 win 4608
12：35：48.442538 C> D：P 465409：465921（512）ACK 1勝4608 12：35：48.544483 D> C：。 35：48.703496 D> C 461825は、12 4096に勝つACKの場合：。 35：461825は、12 4096に勝つackを49.044613 C> D：。 461825：462337（512）ACK 1 4608に勝ちます
12:35:49.192282 D > C: . ack 465921 win 2048 12:35:49.192538 D > C: . ack 465921 win 4096 12:35:49.193392 C > D: P 465921:466433(512) ack 1 win 4608 12:35:49.194726 C > D: P 466433:466945(512) ack 1 win 4608 12:35:49.350665 D > C: . ack 466945 win 4096 12:35:49.351694 C > D: . 466945:467457(512) ack 1 win 4608 12:35:49.352168 C > D: . 467457:467969(512) ack 1 win 4608 12:35:49.352643 C > D: . 467969:468481(512) ack 1 win 4608 12:35:49.506000 D > C: . ack 467969 win 3584
12：35：49.192282 D> C：。 35：49.192538 D> C 465921は、12 2048に勝つACKの場合：。 ackを465921 4096 12勝利：35：49.193392 C> D：P 465921：466433（512）ACK 1勝4608 12：35：49.194726 C> D：P 466433：466945（512）ACK 1勝4608 12：35：49.350665 D > C：。 35：466945は、12 4096に勝つackを49.351694 C> D：。 466945：467457（512）ACK 1勝4608 12：35：49.352168 C> D：。 467457：467969（512）ACK 1勝4608 12：35：49.352643 C> D：。 467969：468481（512）ACK 1勝4608 12：35：49.506000 D> C：。 ackを467969は3584を獲得します
After C transmits the first packet shown to D, it takes no action in response to D's ACKs for 461825, because the first packet already reached the advertised window limit of 4096 bytes above 461825. 600 msec after transmitting the first packet, C retransmits 461825:462337, presumably due to a timeout. Its congestion window is now MSS (512 bytes).
最初のパケットが既に最初のパケットを送信した後461825. 600ミリ秒の上記4096バイトの広告ウィンドウ限界に達したため、CがDに示す第一パケットを送信した後、それは461825ためD'SのACKに応答してアクションを実行しません、Cは461825を再送します。おそらくタイムアウト462337、。その輻輳ウィンドウは現在、MSS（512バイト）です。
D acks 465921, indicating that C's retransmission filled a sequence hole. This ACK advances C's cwnd from 512 to 1024. Very shortly after, D acks 465921 again in order to update the offered window from 2048 to 4096. This ACK does not advance cwnd since it is not for new data. Very shortly after, C responds to the newly enlarged window by transmitting two packets. D acks both, advancing cwnd from 1024 to 1536. C in turn transmits three packets.
DのACK 465921は、Cの再送シーケンスの穴を埋めていることを示します。このACKは、新しいデータのためではないので、このACKはcwndのが進まない2048〜4096に提供されるウィンドウを更新するために、DのACK 465921再び非常にすぐ後に512から1024へのCのCWNDを進めます。非常直後に、Cは、2つのパケットを送信することで、新たに拡大ウィンドウに応答します。 DのACKの両方を、今度は1024〜1536℃にCWNDを前進すると、3つのパケットを送信します。
References This problem is documented in [Paxson97].
参考文献は、この問題は、[Paxson97]に記述されています。
How to detect Packet loss is common enough in the Internet that generally it is not difficult to find an Internet path that will force retransmission due to packet loss.
パケット損失を検出する方法、一般的に、パケット損失に再送信を強制するインターネットパスを見つけることは難しいことではありません、インターネットに十分に一般的です。
If the effective window prior to loss is large enough, however, then the TCP may retransmit using the "fast recovery" mechanism described in RFC 2001. In a packet trace, the signature of fast recovery is that the packet retransmission occurs in response to the receipt of three duplicate ACKs, and subsequent duplicate ACKs may lead to the transmission of new data, above both the ack point and the highest sequence transmitted so far. An absence of three duplicate ACKs prior to retransmission suffices to distinguish between timeout and fast recovery retransmissions. In the face of only observing fast recovery retransmissions, generally it is not difficult to repeat the data transfer until observing a timeout retransmission.
前損失に有効なウィンドウが十分に大きい場合、しかし、その後、TCPは、パケットトレースはRFC 2001に記載された「高速回復」機構を使用して再送信することができる、高速回復の署名は、パケット再送に応答して起こることです3個の重複ACK、およびその後の重複ACKの受信は、ACKポイント及びこれまでに送信最高配列の両方の上に、新たなデータの伝送につながる可能性があります。 3個の重複ACKの不在は、再送信する前にタイムアウトと高速リカバリ再送信を区別するのに十分です。唯一の高速リカバリ再送信を観察する顔には、一般的には、タイムアウト再送を観測するまでのデータ転送を繰り返すことは難しいことではありません。
Once armed with a trace exhibiting a timeout retransmission, determining whether the TCP follows slow start is done by computing the correct progression of cwnd and comparing it to the amount of data transmitted by the TCP subsequent to the timeout retransmission.
タイムアウト再送信を示すトレースで武装一旦、TCPのスロースタートがCWNDの正しい進行を計算し、タイムアウト再送以降TCPにより送信されるデータの量と比較することによってなされる以下かどうかを決定します。
How to fix If the root problem is that the implementation lacks a notion of a congestion window, then unfortunately this requires significant work to fix. However, doing so is critical, for reasons outlined above.
根本的な問題は、実装が輻輳ウィンドウの概念が欠如している、そして残念ながら、これは修正するために重要な作業を必要とすることであるならば修正する方法。しかし、そうすることは上記で概説した理由のために、非常に重要です。
Name of Problem Uninitialized CWND
問題初期化されていないCWNDの名前
Classification Congestion control
分類輻輳制御
Description As described above for "No initial slow start", when a TCP connection begins cwnd is initialized to one segment (or perhaps a few segments, if experimenting with [RFC2414]). One particular form of "No initial slow start", worth separate mention as the bug is fairly widely deployed, is "Uninitialized CWND". That is, while the TCP implements the proper slow start mechanism, it fails to initialize cwnd properly, so slow start in fact fails to occur.
TCP接続が（[RFC2414]を試している場合、または、おそらくいくつかのセグメント）CWNDが1つのセグメントに初期化され始めたときのような説明は、「いいえ初期スロースタート」について上記しました。 「いいえ初期スロースタート」、バグがかなり広く展開されているとして価値が別々の言及の一つの特定の形式は、「初期化されていないCWND」です。これは、TCPが適切なスロースタートメカニズムを実装していながら、適切にcwndの初期化に失敗し、実際にそうスロースタートが発生しなかった、です。
One way the bug can occur is if, during the connection establishment handshake, the SYN ACK packet arrives without an MSS option. The faulty implementation uses receipt of the MSS option to initialize cwnd to one segment; if the option fails to arrive, then cwnd is instead initialized to a very large value.
バグが発生する可能性があります一つの方法は、接続確立ハンドシェイク中に、SYN ACKパケットがMSSオプションなしで到着した場合などです。障害のある実装では、一つのセグメントにCWNDを初期化するためにMSSオプションの受領を使用します。オプションが到着しなかった場合、その後にcwndが代わりに非常に大きな値に初期化されます。
Significance In congested environments, detrimental to the performance of other connections, and likely to the connection itself. The burst can be so large (see below) that it has deleterious effects even in uncongested environments.
接続自体への他の接続の性能に有害と、おそらく混雑した環境では、意義。バーストは、それがあっても非輻輳環境に有害な効果を有すること（下記参照）が大きくすることができます。
Implications A TCP exhibiting this behavior is stressing the network with a large burst of packets, which can cause loss in the network.
含意は、この挙動を示すTCPは、ネットワーク内の損失を引き起こす可能性がパケットの大バースト、とのネットワークを強調しています。
Relevant RFCs RFC 1122 requires use of slow start. RFC 2001 gives the specifics of slow start.
関連のRFCのRFC 1122は、スロースタートを使用する必要があります。 RFC 2001は、スロースタートの詳細を提供します。
Trace file demonstrating it This trace was made using tcpdump running on host A. Host A is the sender and host B is the receiver. The advertised window and timestamp options have been omitted for clarity, except for the first segment sent by host A. Note that A sends an MSS option in its initial SYN but B does not include one in its reply.
このトレースは、ホストAホストA上で実行されているのtcpdumpを使用して作られた、それを実演するトレースファイルには、送信者とホストBは、受信機です。広告ウィンドウとタイムスタンプオプションは、Aが初期SYNにMSSオプションを送信しますが、Bはその応答内の1つを含んでいないことをホストA.注によって送信された最初のセグメントを除いて、明確にするために省略されています。
16:56:02.226937 A > B: S 237585307:237585307(0) win 8192 <mss 536,nop,wscale 0,nop,nop,timestamp[|tcp]> 16:56:02.557135 B > A: S 1617216000:1617216000(0) ack 237585308 win 16384 16:56:02.557788 A > B: . ack 1 win 8192 16:56:02.566014 A > B: . 1:537(536) ack 1 16:56:02.566557 A > B: . 537:1073(536) ack 1 16:56:02.567120 A > B: . 1073:1609(536) ack 1 16:56:02.567662 A > B: P 1609:2049(440) ack 1 16:56:02.568349 A > B: . 2049:2585(536) ack 1 16:56:02.568909 A > B: . 2585:3121(536) ack 1
16：56：02.226937 A> B：Sの237585307：237585307（0）8192 <MSS 536、NOP、wscale 0、NOP、NOP、タイムスタンプ勝つ[| TCP]> 16：56：02.557135 B> A：S 1617216000：1617216000を56：02.557788 A> B（0）ACK 237585308 16384 16に勝ちます：。 56：02.566014 A> B ACK 1 8192 16勝ちます：。 1：537（536）、ACK 1 16：56：02.566557 A> B：。 537：1073（536）、ACK 1 16：56：02.567120 A> B：。 1073：1609（536）、ACK 1 16：56：02.567662 A> B：P 1609：2049（440）、ACK 1 16：56：02.568349 A> B：。 2049：2585（536）、ACK 1 16：56：02.568909 A> B：。 2585：3121（536）、ACK 1
[54 additional burst segments deleted for brevity]
[54個の追加のバーストセグメントは簡潔にするために削除します]
16:56:02.936638 A > B: . 32065:32601(536) ack 1 16:56:03.018685 B > A: . ack 1
16：56：02.936638 A> B. 32065：32601（536）OH 1：16 A.M：56：03.018685 B> A.ああ1
After the three-way handshake, host A bursts 61 segments into the network, before duplicate ACKs on the first segment cause a retransmission to occur. Since host A did not wait for the ACK on the first segment before sending additional segments, it is exhibiting "Uninitialized CWND"
最初のセグメント上の重複ACKが再送信を発生させる前に、スリーウェイハンドシェイクの後、ホストAは、ネットワークに61個のセグメントをバースト。ホストAは、追加のセグメントを送信する前に、最初のセグメントのACKを待ちませんでしたので、それは「初期化されていないCWND」を展示しています
Trace file demonstrating correct behavior
正しい動作を実演するトレースファイル
See the example for "No initial slow start".
「いいえ初期スロースタート」の例を参照してください。
References This problem is documented in [Paxson97].
参考文献は、この問題は、[Paxson97]に記述されています。
How to detect This problem can be detected by examining a packet trace recorded at either the sender or the receiver. However, the bug can be difficult to induce because it requires finding a remote TCP peer that does not send an MSS option in its SYN ACK.
どのようにこの問題を検出するために、送信者または受信者のいずれかで記録されたパケットトレースを調べることにより検出することができます。しかし、バグは、そのSYN ACKでMSSオプションを送信しませんリモートTCPピアを見つける必要があるため、誘導することは困難です。
How to fix This problem can be fixed by ensuring that cwnd is initialized upon receipt of a SYN ACK, even if the SYN ACK does not contain an MSS option.
この問題を解決する方法のcwndがSYN ACKは、MSSオプションが含まれていない場合でも、SYN ACKを受信したときに初期化されることを保証することによって固定することができます。
Name of Problem Inconsistent retransmission
問題一貫性のない再送信の名前
Classification Reliability
分類の信頼性
Description If, for a given sequence number, a sending TCP retransmits different data than previously sent for that sequence number, then a strong possibility arises that the receiving TCP will reconstruct a different byte stream than that sent by the sending application, depending on which instance of the sequence number it accepts.
説明指定されたシーケンス番号を、送信TCPは以前にそのシーケンス番号の送信とは異なるデータを再送し、強い可能性は、受信TCPがどのインスタンスに応じて、送信側アプリケーションによって送信されたものとは異なるバイトストリームを再構成することを生じ、場合それは受け入れるシーケンス番号の。
Such a sending TCP exhibits "Inconsistent retransmission".
このような送信TCP展示「一貫性のない再送信」。
Significance Critical for all environments.
すべての環境のために重要な意義。
Implications Reliable delivery of data is a fundamental property of TCP.
データの意味合い信頼性の高い配信は、TCPの基本的な特性です。
Relevant RFCs RFC 793, section 1.5, discusses the central role of reliability in TCP operation.
関連のRFC RFC 793、セクション1.5は、TCP操作の信頼性の中心的な役割を論じています。
Trace file demonstrating it Made using tcpdump recording at the receiving TCP (B). No losses reported by the packet filter.
トレース・ファイルには、受信側TCP（B）でtcpdumpの記録を使用して作られて実証しました。パケットフィルタによって報告されていない損失はありません。
12:35:53.145503 A > B: FP 90048435:90048461(26) ack 393464682 win 4096 4500 0042 9644 0000 3006 e4c2 86b1 0401 83f3 010a b2a4 0015 055e 07b3 1773 cb6a 5019 1000 68a9 0000 data starts here>504f 5254 2031 3334 2c31 3737*2c34 2c31 2c31 3738 2c31 3635 0d0a 12:35:53.146479 B > A: R 393464682:393464682(0) win 8192 12:35:53.851714 A > B: FP 90048429:90048463(34) ack 393464682 win 4096 4500 004a 965b 0000 3006 e4a3 86b1 0401 83f3 010a b2a4 0015 055e 07ad 1773 cb6a 5019 1000 8bd3 0000 data starts here>5041 5356 0d0a 504f 5254 2031 3334 2c31 3737*2c31 3035 2c31 3431 2c34 2c31 3539 0d0a
12：35：53.145503 A> B：FP 90048435：393464682 ACK 90048461（26）4096 4500 0042 9644 0000 3006 e4c2 86b1 0401 83f3 010A b2a4 0015 055e 1773 07b3 cb6a 5019千68a9 0000データ2c31 3737 5254 2031 3334 504F>ここから勝ちます* 2c34 2c31 2c31 3738 2c31 3635 0D0A 12：35：53.146479 B> A：R 393464682：393464682（0）8192 12勝利：35：53.851714 A> B：FP 90048429：90048463（34）ACK 393464682 4096 4500勝つ004Aと965B 0000 3006 e4a3 86b1 0401 83f3 010A b2a4 0015 055eの07ad 1773 cb6a 5019 1000年8bd3 0000のデータはここから> 5041 5356 5254 2031 3334 3737 2c31 * 2c31 3035 2c31 3431 2c34 2c31 3539 0D0A 504F 0D0A
The sequence numbers shown in this trace are absolute and not adjusted to reflect the ISN. The 4-digit hex values show a dump of the packet's IP and TCP headers, as well as payload. A first sends to B data for 90048435:90048461. The corresponding data begins with hex words 504f, 5254, etc.
このトレースに示される配列番号は、絶対とISNを反映するように調整されません。 4桁の16進値は、パケットのIPおよびTCPヘッダのダンプだけでなく、ペイロードを示しています。 90048461：最初は90048435のためのBデータを送信します。対応するデータは、六角言葉504F、5254、などで始まります
B responds with a RST. Since the recording location was local to B, it is unknown whether A received the RST.
BはRSTで応答します。記録位置がBに対してローカルであったので、AはRSTを受信したかどうかは不明です。
A then sends 90048429:90048463, which includes six sequence positions below the earlier transmission, all 26 positions of the earlier transmission, and two additional sequence positions.
以前送信下6つの配列位置、以前のすべての伝送の26の位置、および2つの追加の配列位置を含む、90048463：次に90048429を送ります。
The retransmission disagrees starting just after sequence 90048447, annotated above with a leading '*'. These two bytes were originally transmitted as hex 2c34 but retransmitted as hex 2c31. Subsequent positions disagree as well.
再送が主導して上に注釈を付け、ちょうどシーケンス90048447後に開始する同意しません「*」。これらの2つのバイトは、もともとの六角2c34として送信が、六角2c31として再送されました。後続の位置も同様に反対します。
This behavior has been observed in other traces involving different hosts. It is unknown how to repeat it.
この動作は、異なるホストを含む他のトレースに観察されています。それを繰り返す方法は不明です。
In this instance, no corruption would occur, since B has already indicated it will not accept further packets from A.
Bは既にそれはAからさらにパケットを受け付けない示したので、この場合には、全く破損が発生しないであろう
A second example illustrates a slightly different instance of the problem. The tracing again was made with tcpdump at the receiving TCP (D).
第二の例は、問題のわずかに異なるインスタンスを示しています。トレースは、再び受信TCP（D）でtcpdumpを用いて行われました。
22:23:58.645829 C > D: P 185:212(27) ack 565 win 4096 4500 0043 90a3 0000 3306 0734 cbf1 9eef 83f3 010a 0525 0015 a3a2 faba 578c 70a4 5018 1000 9a53 0000 data starts here>504f 5254 2032 3033 2c32 3431 2c31 3538 2c32 3339 2c35 2c34 330d 0a 22:23:58.646805 D > C: . ack 184 win 8192 4500 0028 beeb 0000 3e06 ce06 83f3 010a cbf1 9eef 0015 0525 578c 70a4 a3a2 fab9 5010 2000 342f 0000 22:31:36.532244 C > D: FP 186:213(27) ack 565 win 4096 4500 0043 9435 0000 3306 03a2 cbf1 9eef 83f3 010a 0525 0015 a3a2 fabb 578c 70a4 5019 1000 9a51 0000 data starts here>504f 5254 2032 3033 2c32 3431 2c31 3538 2c32 3339 2c35 2c34 330d 0a
22：23：58.645829 C> D：P 185：212（27）確認応答565勝つ4096 4500 0043 90a3 0000 3306 0734 CBF1 9eef 83f3 010A 0525 0015 a3a2ソラマメの578c 70a4 5018千9a53 0000データ2c32 3431 5254 2032 3033 504F>ここから2c31 3538 2c32 3339 2c35 2c34 330D 0A 22：23：58.646805 D> C：。 31：36.532244 C> D：FP 186：213（27）565 ACK 4096 4500 0043 9435 0000 3306 03a2を獲得184 0000 22 342f 8192 4500 0028 beeb 0000 3e06 ce06 83f3 010A CBF1 9eef 0015 0525 578c 70a4 a3a2 fab9 5010 2000勝つ確認応答CBF1 9eef 83f3 010A 0525 0015 a3a2 FABB 578c 70a4 5019 1000年9a51 0000データここから> 504F 5254 2032 3033 2c32 3431 2c31 3538 2c32 3339 2c35 2c34 330dは0A
In this trace, sequence numbers are relative. C sends 185:212, but D only sends an ACK for 184 (so sequence number 184 is missing). C then sends 186:213. The packet payload is identical to the previous payload, but the base sequence number is one higher, resulting in an inconsistent retransmission.
このトレースでは、シーケンス番号は相対的なものです。 Cは185送信：212が、Dは、（SOシーケンス番号184が欠落している）184に対するACKを送信します。 213：Cは、186を送信します。パケットペイロードは、前のペイロードと同一であるが、基本シーケンス番号は一貫性のない再送をもたらす、高い方です。
Neither trace exhibits checksum errors.
どちらのトレースは、チェックサムエラーを示します。
Trace file demonstrating correct behavior (Omitted, as presumably correct behavior is obvious.)
正しい動作を実演するトレースファイル（おそらく正しい振る舞いは明らかなように、省略。）
References None known.
参考認知済みのものは無し。
How to detect This problem unfortunately can be very difficult to detect, since available experience indicates it is quite rare that it is manifested. No "trigger" has been identified that can be used to reproduce the problem.
残念ながら、この問題を検出する方法利用可能な経験は、明示されることは極めて稀であることを示しているため、検出が非常に難しいことができます。 NO「トリガー」は、問題を再現するために使用することができますが同定されていません。
How to fix In the absence of a known "trigger", we cannot always assess how to fix the problem.
知られている「トリガー」がない場合には修正するためにどのように、私たちは常に問題を解決する方法を評価することはできません。
In one implementation (not the one illustrated above), the problem manifested itself when (1) the sender received a zero window and stalled; (2) eventually an ACK arrived that offered a window larger than that in effect at the time of the stall; (3) the sender transmitted out of the buffer of data it held at the time of the stall, but (4) failed to limit this transfer to the buffer length, instead using the newly advertised (and larger) offered window. Consequently, in addition to the valid buffer contents, it sent whatever garbage values followed the end of the buffer. If it then retransmitted the corresponding sequence numbers, at that point it sent the correct data, resulting in an inconsistent retransmission. Note that this instance of the problem reflects a more general problem, that of initially transmitting incorrect data.
（1）送信者がゼロウィンドウを受信したときにストール一の実装（上記図示されていないもの）において、問題は、それ自体を明示しました。 （2）最終的にACKが失速時の効果よりも大きなウィンドウを提供し、その到着しました。 （3）送信者は、それが失速時に保持されたデータのバッファから送信されたが、（4）の代わりに新たにアドバタイズ（以上）提供ウィンドウを使用して、バッファ長にこの転送を制限することができませんでした。したがって、有効なバッファの内容に加えて、ごみ値がバッファの末尾に続くものは何でも送信しました。それは、対応するシーケンス番号を再送した場合、その時点でそれは矛盾再送をもたらす、正しいデータを送信しました。 、問題のこのインスタンスは、より一般的な問題を反映していることを最初に間違ったデータを送信することに注意してください。
Name of Problem Failure to retain above-sequence data
上記のシーケンスデータを保持する問題の失敗の名前
Classification Congestion control, performance
分類輻輳制御、パフォーマンス
Description When a TCP receives an "above sequence" segment, meaning one with a sequence number exceeding RCV.NXT but below RCV.NXT+RCV.WND, it SHOULD queue the segment for later delivery (RFC 1122, 4.2.2.20). (See RFC 793 for the definition of RCV.NXT and RCV.WND.) A TCP that fails to do so is said to exhibit "Failure to retain above-sequence data".
説明TCPは、RCV.NXTを超えるシーケンス番号を有するがRCV.NXT + RCV.WND以下のいずれかを意味する「上記配列」セグメントを受信すると、それは後で配信するためのセグメント（RFC 1122 4.2.2.20）をキューすべきです。 （RCV.NXTとRCV.WNDの定義のためのRFC 793を参照してください。）そうすることを失敗したTCPは、「上記のシーケンスデータを保持するために失敗」を示すと言われています。
It may sometimes be appropriate for a TCP to discard above-sequence data to reclaim memory. If they do so only rarely, then we would not consider them to exhibit this problem. Instead, the particular concern is with TCPs that always discard above-sequence data.
TCPは、メモリを解放するために、上記シーケンスデータを破棄することは、時には適切であり得ます。彼らはまれにしかそうしない場合、我々はこの問題を示すためにそれらを考えていません。代わりに、特定の懸念は常に上記系列データを破棄したTCPです。
Significance In environments prone to packet loss, detrimental to the performance of both other connections and the connection itself.
両方の他の接続のパフォーマンスと接続自体に有害なパケットロスが発生しやすい環境では意義。
Implications In times of congestion, a failure to retain above-sequence data will lead to numerous otherwise-unnecessary retransmissions, aggravating the congestion and potentially reducing performance by a large factor.
混雑の時間に影響は、上記シーケンスデータを保持する障害が輻輳を悪化させると、潜在的に大きな要因によって性能を低下させる、多数のそれ以外の場合は、不要な再送につながります。
Relevant RFCs RFC 1122 revises RFC 793 by upgrading the latter's MAY to a SHOULD on this issue.
関連のRFCのRFC 1122は、この問題にすべきか、後者のMAYをアップグレードすることにより、RFC 793を改訂します。
Trace file demonstrating it Made using tcpdump recording at the receiving TCP. No losses reported by the packet filter.
トレース・ファイルには、受信側TCPでtcpdumpの記録を使用して作られて実証しました。パケットフィルタによって報告されていない損失はありません。
B is the TCP sender, A the receiver. A exhibits failure to retain above sequence-data:
Bは、TCPの送信側、受信側です。展示障害が上記のシーケンスデータを保持します。
10:38:10.164860 B > A: . 221078:221614(536) ack 1 win 33232 [tos 0x8] 10:38:10.170809 B > A: . 221614:222150(536) ack 1 win 33232 [tos 0x8] 10:38:10.177183 B > A: . 222150:222686(536) ack 1 win 33232 [tos 0x8] 10:38:10.225039 A > B: . ack 222686 win 25800
10：38：10.164860 B> A：。 221078：38：221614（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.170809 B> A：。 221614：38：222150（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.177183 B> A：。 222150：38：10.225039 A> B 222686（536）ACK 1が33232 [TOS、0x8という] 10勝ちます：。 222686 ACK 25800を獲得
Here B has sent up to (relative) sequence 222686 in-sequence, and A accordingly acknowledges.
ここでBは、インシーケンス（相対）配列222686まで送られており、Aはそれに応じて肯定応答します。
10:38:10.268131 B > A: . 223222:223758(536) ack 1 win 33232 [tos 0x8] 10:38:10.337995 B > A: . 223758:224294(536) ack 1 win 33232 [tos 0x8] 10:38:10.344065 B > A: . 224294:224830(536) ack 1 win 33232 [tos 0x8] 10:38:10.350169 B > A: . 224830:225366(536) ack 1 win 33232 [tos 0x8] 10:38:10.356362 B > A: . 225366:225902(536) ack 1 win 33232 [tos 0x8]
10：38：10.268131 B> A：。 223222：38：223758（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.337995 B> A：。 223758：38：224294（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.344065 B> A：。 224294：38：224830（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.350169 B> A：。 224830：38：225366（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.356362 B> A：。 225366：225902（536）ACK 1 33232 [TOS 0x8という]を勝ち取ります
10:38:10.362445 B > A: . 225902:226438(536) ack 1 win 33232 [tos 0x8] 10:38:10.368579 B > A: . 226438:226974(536) ack 1 win 33232 [tos 0x8] 10:38:10.374732 B > A: . 226974:227510(536) ack 1 win 33232 [tos 0x8] 10:38:10.380825 B > A: . 227510:228046(536) ack 1 win 33232 [tos 0x8] 10:38:10.387027 B > A: . 228046:228582(536) ack 1 win 33232 [tos 0x8] 10:38:10.393053 B > A: . 228582:229118(536) ack 1 win 33232 [tos 0x8] 10:38:10.399193 B > A: . 229118:229654(536) ack 1 win 33232 [tos 0x8] 10:38:10.405356 B > A: . 229654:230190(536) ack 1 win 33232 [tos 0x8]
10：38：10.362445 B> A：。 225902：38：226438（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.368579 B> A：。 226438：38：226974（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.374732 B> A：。 226974：38：227510（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.380825 B> A：。 227510：38：228046（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.387027 B> A：。 228046：38：228582（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.393053 B> A：。 228582：38：229118（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.399193 B> A：。 229118：38：229654（536）ACK 1は、[0x8というTOS] 10 33232を獲得10.405356 B> A：。 229654：230190（536）ACK 1 33232 [TOS 0x8という]を勝ち取ります
A now receives 13 additional packets from B. These are above-sequence because 222686:223222 was dropped. The packets do however fit within the offered window of 25800. A does not generate any duplicate ACKs for them.
223222滴下した。今、これらは上記シーケンス222686が原因であるBから13個の追加のパケットを受信します。パケットは、しかし、彼らのために任意の重複ACKを生成しません25800. Aの提供ウィンドウ内に収まるん。
The trace contributor (V. Paxson) verified that these 13 packets had valid IP and TCP checksums.
トレース貢献（V.パクソン）は、これらの13個のパケットが有効なIPやTCPチェックサムを持っていたことを確認しました。
10:38:11.917728 B > A: . 222686:223222(536) ack 1 win 33232 [tos 0x8] 10:38:11.930925 A > B: . ack 223222 win 32232
10：38：11.917728 B> A：。 222686：38：11.930925 A> B 223222（536）ACK 1が33232 [TOS、0x8という] 10勝ちます：。 223222 ACK 32232を獲得
B times out for 222686:223222 and retransmits it. Upon receiving it, A only acknowledges 223222. Had it retained the valid above-sequence packets, it would instead have ack'd 230190.
222686のためのアウトB回数：223222、それを再送信します。それを受信すると、Aは223222.は、それが有効な上記の一連のパケットを保持していた、それは代わりに230190をack'dただろう認めています。
10:38:12.048438 B > A: . 223222:223758(536) ack 1 win 33232 [tos 0x8] 10:38:12.054397 B > A: . 223758:224294(536) ack 1 win 33232 [tos 0x8] 10:38:12.068029 A > B: . ack 224294 win 31696
10：38：12.048438 B> A：。 223222：38：223758（536）ACK 1は、[0x8というTOS] 10 33232を獲得12.054397 B> A：。 223758：38：12.068029 A> B 224294（536）ACK 1が33232 [TOS、0x8という] 10勝ちます：。 224294 ACK 31696を獲得
B retransmits two more packets, and A only acknowledges them. This pattern continues as B retransmits the entire set of previously-received packets.
Bは、さらに2つのパケットを再送信、およびAは、それらだけを認めています。 Bは、以前に受信されたパケットのセット全体を再送信するように、このパターンは継続します。
A second trace confirmed that the problem is repeatable.
第2のトレースは、問題が再現可能であることを確認しました。
Trace file demonstrating correct behavior Made using tcpdump recording at the receiving TCP (C). No losses reported by the packet filter.
受信側TCP（C）でtcpdumpの記録を使用して作られた正しい動作を実演するトレースファイル。パケットフィルタによって報告されていない損失はありません。
09:11:25.790417 D > C: . 33793:34305(512) ack 1 win 61440 09:11:25.791393 D > C: . 34305:34817(512) ack 1 win 61440 09:11:25.792369 D > C: . 34817:35329(512) ack 1 win 61440 09:11:25.792369 D > C: . 35329:35841(512) ack 1 win 61440 09:11:25.793345 D > C: . 36353:36865(512) ack 1 win 61440 09:11:25.794321 C > D: . ack 35841 win 59904
09：11：25.790417 D> C：。 33793：11：25.791393 D> C 34305（512）ACK 1 61440 09勝ちます：。 34305：11：25.792369 D> C 34817（512）ACK 1 61440 09勝ちます：。 34817：11：25.792369 D> C 35329（512）ACK 1 61440 09勝ちます：。 35329：11：25.793345 D> C 35841（512）ACK 1 61440 09勝ちます：。 36353：36865（512）ACK 1 61440 09勝利：11：25.794321 C> D：。 35841 59904勝つackを
A sequence hole occurs because 35841:36353 has been dropped.
36353が削除された：35841ので、シーケンス・ホールが発生します。
09:11:25.794321 D > C: . 36865:37377(512) ack 1 win 61440 09:11:25.794321 C > D: . ack 35841 win 59904 09:11:25.795297 D > C: . 37377:37889(512) ack 1 win 61440 09:11:25.795297 C > D: . ack 35841 win 59904 09:11:25.796273 C > D: . ack 35841 win 61440 09:11:25.798225 D > C: . 37889:38401(512) ack 1 win 61440 09:11:25.799201 C > D: . ack 35841 win 61440 09:11:25.807009 D > C: . 38401:38913(512) ack 1 win 61440 09:11:25.807009 C > D: . ack 35841 win 61440 (many additional lines omitted) 09:11:25.884113 D > C: . 52737:53249(512) ack 1 win 61440 09:11:25.884113 C > D: . ack 35841 win 61440
09：11：25.794321 D> C：。 36865：37377（512）ACK 1 61440 09勝利：11：25.794321 C> D：。 11：：ackを35841は59904 09に勝つ25.795297 D> C：。 37377：37889（512）ACK 1 61440 09勝利：11：25.795297 C> D：。 ackを35841は59904 09勝つ：11：25.796273 C> D：。 11：：ackを35841は61440 09に勝つ25.798225 D> C：。 37889：38401（512）ACK 1 61440 09勝利：11：25.799201 C> D：。 11：：ackを35841は61440 09に勝つ25.807009 D> C：。 38401：38913（512）ACK 1 61440 09勝利：11：25.807009 C> D：。 11：25.884113 D> C 35841は、61440（省略多くの追加のライン）09を獲得ACKの場合：。 52737：53249（512）ACK 1 61440 09勝利：11：25.884113 C> D：。 35841 61440勝つackを
Each additional, above-sequence packet C receives from D elicits a duplicate ACK for 35841.
CはDから受け取るそれぞれの追加、上記シーケンスパケットは、35841の重複ACKを誘発します。
09:11:25.887041 D > C: . 35841:36353(512) ack 1 win 61440 09:11:25.887041 C > D: . ack 53249 win 44032
09：11：25.887041 D> C：。 35841：36353（512）ACK 1 61440 09勝利：11：25.887041 C> D：。 53249 44032勝つackを
D retransmits 35841:36353 and C acknowledges receipt of data all the way up to 53249.
36353およびCはすべての方法53249までのデータの受信を確認する：Dは、35841を再送します。
References This problem is documented in [Paxson97].
参考文献は、この問題は、[Paxson97]に記述されています。
How to detect Packet loss is common enough in the Internet that generally it is not difficult to find an Internet path that will result in some above-sequence packets arriving. A TCP that exhibits "Failure to retain ..." may not generate duplicate ACKs for these packets. However, some TCPs that do retain above-sequence data also do not generate duplicate ACKs, so failure to do so does not definitively identify the problem. Instead, the key observation is whether upon retransmission of the dropped packet, data that was previously above-sequence is acknowledged.
パケット損失を検出する方法、一般的に到着し、いくつかの上記シーケンスパケットになりますインターネットパスを見つけることは難しいことではありません、インターネットに十分に一般的です。 「...保持する失敗」を示すTCPは、これらのパケットの重複ACKを生成しないことがあります。これを行うには失敗が決定的に問題を特定しないようにしかし、上述したシーケンスデータを保持しますいくつかのTCPはまた、重複ACKを生成しません。代わりに、キーの観察は、ドロップされたパケットの再送時、先にシーケンスしたデータが確認されているかどうかです。
Two considerations in detecting this problem using a packet trace are that it is easiest to do so with a trace made at the TCP receiver, in order to unambiguously determine which packets arrived successfully, and that such packets may still be correctly discarded if they arrive with checksum errors. The latter can be tested by capturing the entire packet contents and performing the IP and TCP checksum algorithms to verify their integrity; or by confirming that the packets arrive with the same checksum and contents as that with which they were sent, with a presumption that the sending TCP correctly calculates checksums for the packets it transmits.
パケットトレースを使用してこの問題を検出する二つの考慮事項は、それが明確に成功到着したパケットを決定するために、TCP受信機で行われた痕跡でそうするのが最も簡単です、そして彼らが到着した場合、このようなパケットが正常に破棄することができるということですチェックサムエラー。後者は、パケット全体の内容を取り込み、それらの完全性を検証するためにIPとTCPチェックサム・アルゴリズムを実行することによって試験することができます。または、パケットが送信TCPが正しく、それが送信するパケットに対してチェックサムを算出する推定と、送信されたとものと同じチェックサムと内容で到着することを確認することによって。
It is considerably easier to verify that an implementation does NOT exhibit this problem. This can be done by recording a trace at the data sender, and observing that sometimes after a retransmission the receiver acknowledges a higher sequence number than just that which was retransmitted.
実装がこの問題を示さないことを確認するためにかなり容易です。これは、データ送信側でトレースを記録し、時には再送信後に受信機が再送だっただけよりも高いシーケンス番号を認識することを観察することによって行うことができます。
How to fix If the root problem is that the implementation lacks buffer, then then unfortunately this requires significant work to fix. However, doing so is important, for reasons outlined above.
根本的な問題は、実装がバッファに欠けるし、その後、残念ながら、これは修正するために重要な作業を必要とすることであるならば修正する方法。しかし、そうすることは上記で概説した理由のために、重要です。
Name of Problem Extra additive constant in congestion avoidance
輻輳回避で問題エクストラ添加定数の名前
Classification Congestion control / performance
分類輻輳制御/パフォーマンス
Description RFC 1122 section 4.2.2.15 states that TCP MUST implement Jacobson's "congestion avoidance" algorithm [Jacobson88], which calls for increasing the congestion window, cwnd, by:
説明RFC 1122個のセクション4.2.2.15 TCPは輻輳ウィンドウを増加させるために呼び出すヤコブソンの「輻輳回避」アルゴリズム[Jacobson88]を、実装しなければならない状態、cwndは、によって：
MSS * MSS / cwnd
MSS * MSS / CWND
for each ACK received for new data [RFC2001]. This has the effect of increasing cwnd by approximately one segment in each round trip time.
各ACKのための新たなデータ[RFC2001]のために受け取りました。これは、各ラウンドトリップ時間におよそセグメントによってCWND増加させる効果を有します。
Some TCP implementations add an additional fraction of a segment (typically MSS/8) to cwnd for each ACK received for new data [Stevens94, Wright95]:
いくつかのTCP実装は、各ACKが新しいデータ[Stevens94、Wright95]のために受信するためのcwndをするセグメント（典型的には、MSS / 8）の付加的な部分を追加します。
(MSS * MSS / cwnd) + MSS/8
（MSS * MSS / CWND）+ MSS / 8
These implementations exhibit "Extra additive constant in congestion avoidance".
これらの実装の展示「輻輳回避に予備の添加定数」。
Significance May be detrimental to performance even in completely uncongested environments (see Implications).
意義さえ完全に非輻輳環境（影響を参照）での性能に有害である可能性があります。
In congested environments, may also be detrimental to the performance of other connections.
混雑した環境では、また、他の接続の性能に有害である可能性があります。
Implications The extra additive term allows a TCP to more aggressively open its congestion window (quadratic rather than linear increase). For congested networks, this can increase the loss rate experienced by all connections sharing a bottleneck with the aggressive TCP.
意味合い余分な添加剤の用語は、TCPは、より積極的に輻輳ウィンドウ（二次ではなく、直線的に増加）を開くことができます。混雑したネットワークでは、これは積極的なTCPとボトルネックを共有するすべての接続が経験損失率を高めることができます。
However, even for completely uncongested networks, the extra additive term can lead to diminished performance, as follows. In congestion avoidance, a TCP sender probes the network path to determine its available capacity, which often equates to the number of buffers available at a bottleneck link. With linear congestion avoidance, the TCP only probes for sufficient capacity (buffer) to hold one extra packet per RTT.
ただし、次のようにしても完全に輻輳していないネットワークのために、余分な添加剤の用語は、パフォーマンスの低下につながることができます。輻輳回避では、TCPの送信者は、多くの場合、ボトルネックリンクで使用可能なバッファの数に相当し、その利用可能な容量を決定するためにネットワークパスをプローブします。 RTTごとに1つの余分のパケットを保持するのに十分な容量（バッファ）のための線形輻輳回避では、TCPは、プローブのみ。
Thus, when it exceeds the available capacity, generally only one packet will be lost (since on the previous RTT it already found that the path could sustain a window with one less packet in flight). If the congestion window is sufficiently large, then the TCP will recover from this single loss using fast retransmission and avoid an expensive (in terms of performance) retransmission timeout.
それは利用可能な容量を超えた場合（前のRTTに既にパスが飛行中の1つの少ないパケットでウィンドウを維持することがわかっているため）このように、一般的に唯一のパケットが失われます。輻輳ウィンドウが十分に大きい場合には、TCPは、高速再送信を使用して、この単一の損失から回復し、（パフォーマンスの面で）高価な再送タイムアウトを回避します。
However, when the additional additive term is used, then cwnd can increase by more than one packet per RTT, in which case the TCP probes more aggressively. If in the previous RTT it had reached the available capacity of the path, then the excess due to the extra increase will again be lost, but now this will result in multiple losses from the flight instead of a single loss. TCPs that do not utilize SACK [RFC2018] generally will not recover from multiple losses without incurring a retransmission timeout [Fall96,Hoe96], significantly diminishing performance.
追加の添加剤の用語が使用されている場合しかし、その後にcwndは、より積極的ケースでTCPプローブ、RTTごとに複数のパケットによって増やすことができます。前のRTTで、それは、パスの利用可能な容量に達した場合は、原因の余分な増加への過剰が再び失われますが、今これではなく、単一の損失の飛行からの複数の損失になります。一般SACK [RFC2018]を利用しないのTCPパフォーマンスが大幅に減少、再送タイムアウトを招くことなく、複数の損失から[Fall96、Hoe96]を回復することはありません。
Relevant RFCs RFC 1122 requires use of the "congestion avoidance" algorithm. RFC 2001 outlines the fast retransmit/fast recovery algorithms. RFC 2018 discusses the SACK option.
関連のRFCのRFC 1122は、「輻輳回避」アルゴリズムを使用する必要があります。 RFC 2001は、高速再送/高速回復アルゴリズムの概要を説明します。 RFC 2018は、SACKオプションについて説明します。
Trace file demonstrating it Recorded using tcpdump running on the same FDDI LAN as host A. Host A is the sender and host B is the receiver. The connection establishment specified an MSS of 4,312 bytes and a window scale factor of 4. We omit the establishment and the first 2.5 MB of data transfer, as the problem is best demonstrated when the window has grown to a large value. At the beginning of the trace excerpt, the congestion window is 31 packets. The connection is never receiver-window limited, so we omit window advertisements from the trace for clarity.
それはAが送信者とホストBは、受信機であるホストAホストと同じFDDI LAN上で動作しているのtcpdumpを使用して記録を証明ファイルをトレースします。接続の確立は、我々は、ウィンドウが大きな値に成長したときに問題を最もよく示されているように、確立とデータ転送の最初の2.5 MBの省略4,312バイトのMSS及び4のウィンドウスケールファクタを指定しました。トレースの抜粋の開始時に、輻輳ウィンドウは31のパケットです。接続は決して受信ウィンドウ制限されているので、我々は明確にするためのトレースから窓の広告を省略します。
11:42:07.697951 B > A: . ack 2383006 11:42:07.699388 A > B: . 2508054:2512366(4312) 11:42:07.699962 A > B: . 2512366:2516678(4312) 11:42:07.700012 B > A: . ack 2391630 11:42:07.701081 A > B: . 2516678:2520990(4312) 11:42:07.701656 A > B: . 2520990:2525302(4312) 11:42:07.701739 B > A: . ack 2400254 11:42:07.702685 A > B: . 2525302:2529614(4312) 11:42:07.703257 A > B: . 2529614:2533926(4312) 11:42:07.703295 B > A: . ack 2408878 11:42:07.704414 A > B: . 2533926:2538238(4312) 11:42:07.704989 A > B: . 2538238:2542550(4312) 11:42:07.705040 B > A: . ack 2417502 11:42:07.705935 A > B: . 2542550:2546862(4312) 11:42:07.706506 A > B: . 2546862:2551174(4312) 11:42:07.706544 B > A: . ack 2426126 11:42:07.707480 A > B: . 2551174:2555486(4312) 11:42:07.708051 A > B: . 2555486:2559798(4312) 11:42:07.708088 B > A: . ack 2434750 11:42:07.709030 A > B: . 2559798:2564110(4312) 11:42:07.709604 A > B: . 2564110:2568422(4312) 11:42:07.710175 A > B: . 2568422:2572734(4312) *
11：42：07.697951 B> A：。 42：07.699388 A> B 2383006 11がACKの場合：。 2508054：2512366（4312）11：42：07.699962 A> B：。 2512366：2516678（4312）11：42：07.700012 B> A：。 42：07.701081 A> B 2391630 11がACKの場合：。 2516678：2520990（4312）11：42：07.701656 A> B：。 2520990：2525302（4312）11：42：07.701739 B> A：。 42：07.702685 A> B 2400254 11がACKの場合：。 2525302：2529614（4312）11：42：07.703257 A> B：。 2529614：2533926（4312）11：42：07.703295 B> A：。 42：07.704414 A> B 2408878 11がACKの場合：。 2533926：2538238（4312）11：42：07.704989 A> B：。 2538238：2542550（4312）11：42：07.705040 B> A：。 42：07.705935 A> B 2417502 11がACKの場合：。 2542550：2546862（4312）11：42：07.706506 A> B：。 2546862：2551174（4312）11：42：07.706544 B> A：。 42：07.707480 A> B 2426126 11がACKの場合：。 2551174：2555486（4312）11：42：07.708051 A> B：。 2555486：2559798（4312）11：42：07.708088 B> A：。 42：07.709030 A> B 2434750 11がACKの場合：。 2559798：2564110（4312）11：42：07.709604 A> B：。 2564110：2568422（4312）11：42：07.710175 A> B：。 2568422：2572734（4312）*
11:42:07.710215 B > A: . ack 2443374 11:42:07.710799 A > B: . 2572734:2577046(4312) 11:42:07.711368 A > B: . 2577046:2581358(4312) 11:42:07.711405 B > A: . ack 2451998 11:42:07.712323 A > B: . 2581358:2585670(4312) 11:42:07.712898 A > B: . 2585670:2589982(4312) 11:42:07.712938 B > A: . ack 2460622 11:42:07.713926 A > B: . 2589982:2594294(4312) 11:42:07.714501 A > B: . 2594294:2598606(4312) 11:42:07.714547 B > A: . ack 2469246 11:42:07.715747 A > B: . 2598606:2602918(4312) 11:42:07.716287 A > B: . 2602918:2607230(4312) 11:42:07.716328 B > A: . ack 2477870 11:42:07.717146 A > B: . 2607230:2611542(4312) 11:42:07.717717 A > B: . 2611542:2615854(4312) 11:42:07.717762 B > A: . ack 2486494 11:42:07.718754 A > B: . 2615854:2620166(4312) 11:42:07.719331 A > B: . 2620166:2624478(4312) 11:42:07.719906 A > B: . 2624478:2628790(4312) **
11：42：07.710215 B> A：。 42：07.710799 A> B 2443374 11がACKの場合：。 2572734：2577046（4312）11：42：07.711368 A> B：。 2577046：2581358（4312）11：42：07.711405 B> A：。 42：07.712323 A> B 2451998 11がACKの場合：。 2581358：2585670（4312）11：42：07.712898 A> B：。 2585670：2589982（4312）11：42：07.712938 B> A：。 42：07.713926 A> B 2460622 11がACKの場合：。 2589982：2594294（4312）11：42：07.714501 A> B：。 2594294：2598606（4312）11：42：07.714547 B> A：。 42：07.715747 A> B 2469246 11がACKの場合：。 2598606：2602918（4312）11：42：07.716287 A> B：。 2602918：2607230（4312）11：42：07.716328 B> A：。 42：07.717146 A> B 2477870 11がACKの場合：。 2607230：2611542（4312）11：42：07.717717 A> B：。 2611542：2615854（4312）11：42：07.717762 B> A：。 42：07.718754 A> B 2486494 11がACKの場合：。 2615854：2620166（4312）11：42：07.719331 A> B：。 2620166：2624478（4312）11：42：07.719906 A> B：。 2624478：2628790（4312）**
11:42:07.719958 B > A: . ack 2495118 11:42:07.720500 A > B: . 2628790:2633102(4312) 11:42:07.721080 A > B: . 2633102:2637414(4312) 11:42:07.721739 B > A: . ack 2503742 11:42:07.722348 A > B: . 2637414:2641726(4312)
11：42：07.719958 B> A：。 42：07.720500 A> B 2495118 11がACKの場合：。 2628790：2633102（4312）11：42：07.721080 A> B：。 2633102：2637414（4312）11：42：07.721739 B> A：。 42：07.722348 A> B 2503742 11がACKの場合：。 2637414：2641726（4312）
11:42:07.722918 A > B: . 2641726:2646038(4312) 11:42:07.769248 B > A: . ack 2512366
11：42：07.722918 A> B：。 2641726：2646038（4312）11：42：07.769248 B> A：。 ACK 2512366
The receiver's acknowledgment policy is one ACK per two packets received. Thus, for each ACK arriving at host A, two new packets are sent, except when cwnd increases due to congestion avoidance, in which case three new packets are sent.
受信者の承認ポリシーは、受信した2つのパケットにつき1個のACKです。したがって、ホストAに到着する各ACKのために、二つの新しいパケットはつの新しいパケットが送信される場合には輻輳回避のためにcwndを増加し、除いて、送信されます。
With an ack-every-two-packets policy, cwnd should only increase one MSS per 2 RTT. However, at the point marked "*" the window increases after 7 ACKs have arrived, and then again at "**" after 6 more ACKs.
ACK-おき-2-パケットポリシーでは、cwndのはわずか2 RTTごとに1つのMSSを増やす必要があります。 7つのACKが6個の以上のACKの後に「**」に再び到着し、した後しかし、ポイントでウィンドウが増加「*」マーク。
While we do not have space to show the effect, this trace suffered from repeated timeout retransmissions due to multiple packet losses during a single RTT.
我々は効果を表示するスペースがありませんが、このトレースが原因単一RTT中に複数のパケット損失を繰り返し、タイムアウト、再送信に苦しみました。
Trace file demonstrating correct behavior Made using the same host and tracing setup as above, except now A's TCP has been modified to remove the MSS/8 additive constant. Tcpdump reported 77 packet drops; the excerpt below is fully self-consistent so it is unlikely that any of these occurred during the excerpt.
正しい動作を実演するトレースファイルには、同じホストを使用して、現在はAのTCPは、MSS / 8追加の定数を削除するように変更されている以外、上記のようにセットアップをトレースメイド。 tcpdumpが77のパケットドロップを報告しました。以下の抜粋は、完全に自己矛盾であるので、これらのいずれかを抜粋中に発生したことはほとんどありません。
We again begin when cwnd is 31 packets (this occurs significantly later in the trace, because the congestion avoidance is now less aggressive with opening the window).
CWNDは31のパケット（輻輳回避は、現在のウィンドウを開くとあまり積極的であるので、これは、後のトレースで有意に発生した）ときに我々は再び始まります。
14:22:21.236757 B > A: . ack 5194679 14:22:21.238192 A > B: . 5319727:5324039(4312) 14:22:21.238770 A > B: . 5324039:5328351(4312) 14:22:21.238821 B > A: . ack 5203303 14:22:21.240158 A > B: . 5328351:5332663(4312) 14:22:21.240738 A > B: . 5332663:5336975(4312) 14:22:21.270422 B > A: . ack 5211927 14:22:21.271883 A > B: . 5336975:5341287(4312) 14:22:21.272458 A > B: . 5341287:5345599(4312) 14:22:21.279099 B > A: . ack 5220551 14:22:21.280539 A > B: . 5345599:5349911(4312) 14:22:21.281118 A > B: . 5349911:5354223(4312) 14:22:21.281183 B > A: . ack 5229175 14:22:21.282348 A > B: . 5354223:5358535(4312) 14:22:21.283029 A > B: . 5358535:5362847(4312) 14:22:21.283089 B > A: . ack 5237799 14:22:21.284213 A > B: . 5362847:5367159(4312) 14:22:21.284779 A > B: . 5367159:5371471(4312) 14:22:21.285976 B > A: . ack 5246423 14:22:21.287465 A > B: . 5371471:5375783(4312)
14：22：21.236757 B> A：。 22：21.238192 A> B 5194679 14がACKの場合：。 5319727：5324039（4312）14：22：21.238770 A> B：。 5324039：5328351（4312）14：22：21.238821 B> A：。 22：21.240158 A> B 5203303 14がACKの場合：。 5328351：5332663（4312）14：22：21.240738 A> B：。 5332663：5336975（4312）14：22：21.270422 B> A：。 22：21.271883 A> B 5211927 14がACKの場合：。 5336975：5341287（4312）14：22：21.272458 A> B：。 5341287：5345599（4312）14：22：21.279099 B> A：。 22：21.280539 A> B 5220551 14がACKの場合：。 5345599：5349911（4312）14：22：21.281118 A> B：。 5349911：5354223（4312）14：22：21.281183 B> A：。 22：21.282348 A> B 5229175 14がACKの場合：。 5354223：5358535（4312）14：22：21.283029 A> B：。 5358535：5362847（4312）14：22：21.283089 B> A：。 22：21.284213 A> B 5237799 14がACKの場合：。 5362847：5367159（4312）14：22：21.284779 A> B：。 5367159：5371471（4312）14：22：21.285976 B> A：。 22：21.287465 A> B 5246423 14がACKの場合：。 5371471：5375783（4312）
14:22:21.288036 A > B: . 5375783:5380095(4312) 14:22:21.288073 B > A: . ack 5255047 14:22:21.289155 A > B: . 5380095:5384407(4312) 14:22:21.289725 A > B: . 5384407:5388719(4312) 14:22:21.289762 B > A: . ack 5263671 14:22:21.291090 A > B: . 5388719:5393031(4312) 14:22:21.291662 A > B: . 5393031:5397343(4312) 14:22:21.291701 B > A: . ack 5272295 14:22:21.292870 A > B: . 5397343:5401655(4312) 14:22:21.293441 A > B: . 5401655:5405967(4312) 14:22:21.293481 B > A: . ack 5280919 14:22:21.294476 A > B: . 5405967:5410279(4312) 14:22:21.295053 A > B: . 5410279:5414591(4312) 14:22:21.295106 B > A: . ack 5289543 14:22:21.296306 A > B: . 5414591:5418903(4312) 14:22:21.296878 A > B: . 5418903:5423215(4312) 14:22:21.296917 B > A: . ack 5298167 14:22:21.297716 A > B: . 5423215:5427527(4312) 14:22:21.298285 A > B: . 5427527:5431839(4312) 14:22:21.298324 B > A: . ack 5306791 14:22:21.299413 A > B: . 5431839:5436151(4312) 14:22:21.299986 A > B: . 5436151:5440463(4312) 14:22:21.303696 B > A: . ack 5315415 14:22:21.305177 A > B: . 5440463:5444775(4312) 14:22:21.305755 A > B: . 5444775:5449087(4312) 14:22:21.308032 B > A: . ack 5324039 14:22:21.309525 A > B: . 5449087:5453399(4312) 14:22:21.310101 A > B: . 5453399:5457711(4312) 14:22:21.310144 B > A: . ack 5332663 ***
14：22：21.288036 A> B：。 5375783：5380095（4312）14：22：21.288073 B> A：。 22：21.289155 A> B 5255047 14がACKの場合：。 5380095：5384407（4312）14：22：21.289725 A> B：。 5384407：5388719（4312）14：22：21.289762 B> A：。 22：21.291090 A> B 5263671 14がACKの場合：。 5388719：5393031（4312）14：22：21.291662 A> B：。 5393031：5397343（4312）14：22：21.291701 B> A：。 22：21.292870 A> B 5272295 14がACKの場合：。 5397343：5401655（4312）14：22：21.293441 A> B：。 5401655：5405967（4312）14：22：21.293481 B> A：。 22：21.294476 A> B 5280919 14がACKの場合：。 5405967：5410279（4312）14：22：21.295053 A> B：。 5410279：5414591（4312）14：22：21.295106 B> A：。 22：21.296306 A> B 5289543 14がACKの場合：。 5414591：5418903（4312）14：22：21.296878 A> B：。 5418903：5423215（4312）14：22：21.296917 B> A：。 22：21.297716 A> B 5298167 14がACKの場合：。 5423215：5427527（4312）14：22：21.298285 A> B：。 5427527：5431839（4312）14：22：21.298324 B> A：。 22：21.299413 A> B 5306791 14がACKの場合：。 5431839：5436151（4312）14：22：21.299986 A> B：。 5436151：5440463（4312）14：22：21.303696 B> A：。 22：21.305177 A> B 5315415 14がACKの場合：。 5440463：5444775（4312）14：22：21.305755 A> B：。 5444775：5449087（4312）14：22：21.308032 B> A：。 22：21.309525 A> B 5324039 14がACKの場合：。 5449087：5453399（4312）14：22：21.310101 A> B：。 5453399：5457711（4312）14：22：21.310144 B> A：。 *** 5332663を確認応答
14:22:21.311615 A > B: . 5457711:5462023(4312) 14:22:21.312198 A > B: . 5462023:5466335(4312) 14:22:21.341876 B > A: . ack 5341287 14:22:21.343451 A > B: . 5466335:5470647(4312) 14:22:21.343985 A > B: . 5470647:5474959(4312) 14:22:21.350304 B > A: . ack 5349911 14:22:21.351852 A > B: . 5474959:5479271(4312) 14:22:21.352430 A > B: . 5479271:5483583(4312) 14:22:21.352484 B > A: . ack 5358535 14:22:21.353574 A > B: . 5483583:5487895(4312) 14:22:21.354149 A > B: . 5487895:5492207(4312) 14:22:21.354205 B > A: . ack 5367159 14:22:21.355467 A > B: . 5492207:5496519(4312) 14:22:21.356039 A > B: . 5496519:5500831(4312) 14:22:21.357361 B > A: . ack 5375783 14:22:21.358855 A > B: . 5500831:5505143(4312) 14:22:21.359424 A > B: . 5505143:5509455(4312) 14:22:21.359465 B > A: . ack 5384407
14：22：21.311615 A> B：。 5457711：5462023（4312）14：22：21.312198 A> B：。 5462023：5466335（4312）14：22：21.341876 B> A：。 22：21.343451 A> B 5341287 14がACKの場合：。 5466335：5470647（4312）14：22：21.343985 A> B：。 5470647：5474959（4312）14：22：21.350304 B> A：。 22：21.351852 A> B 5349911 14がACKの場合：。 5474959：5479271（4312）14：22：21.352430 A> B：。 5479271：5483583（4312）14：22：21.352484 B> A：。 22：21.353574 A> B 5358535 14がACKの場合：。 5483583：5487895（4312）14：22：21.354149 A> B：。 5487895：5492207（4312）14：22：21.354205 B> A：。 22：21.355467 A> B 5367159 14がACKの場合：。 5492207：5496519（4312）14：22：21.356039 A> B：。 5496519：5500831（4312）14：22：21.357361 B> A：。 22：21.358855 A> B 5375783 14がACKの場合：。 5500831：5505143（4312）14：22：21.359424 A> B：。 5505143：5509455（4312）14：22：21.359465 B> A：。 ACK 5384407
14:22:21.360605 A > B: . 5509455:5513767(4312) 14:22:21.361181 A > B: . 5513767:5518079(4312) 14:22:21.361225 B > A: . ack 5393031 14:22:21.362485 A > B: . 5518079:5522391(4312) 14:22:21.363057 A > B: . 5522391:5526703(4312) 14:22:21.363096 B > A: . ack 5401655 14:22:21.364236 A > B: . 5526703:5531015(4312) 14:22:21.364810 A > B: . 5531015:5535327(4312) 14:22:21.364867 B > A: . ack 5410279 14:22:21.365819 A > B: . 5535327:5539639(4312) 14:22:21.366386 A > B: . 5539639:5543951(4312) 14:22:21.366427 B > A: . ack 5418903 14:22:21.367586 A > B: . 5543951:5548263(4312) 14:22:21.368158 A > B: . 5548263:5552575(4312) 14:22:21.368199 B > A: . ack 5427527 14:22:21.369189 A > B: . 5552575:5556887(4312) 14:22:21.369758 A > B: . 5556887:5561199(4312) 14:22:21.369803 B > A: . ack 5436151 14:22:21.370814 A > B: . 5561199:5565511(4312) 14:22:21.371398 A > B: . 5565511:5569823(4312) 14:22:21.375159 B > A: . ack 5444775 14:22:21.376658 A > B: . 5569823:5574135(4312) 14:22:21.377235 A > B: . 5574135:5578447(4312) 14:22:21.379303 B > A: . ack 5453399 14:22:21.380802 A > B: . 5578447:5582759(4312) 14:22:21.381377 A > B: . 5582759:5587071(4312) 14:22:21.381947 A > B: . 5587071:5591383(4312) ****
14：22：21.360605 A> B：。 5509455：5513767（4312）14：22：21.361181 A> B：。 5513767：5518079（4312）14：22：21.361225 B> A：。 22：21.362485 A> B 5393031 14がACKの場合：。 5518079：5522391（4312）14：22：21.363057 A> B：。 5522391：5526703（4312）14：22：21.363096 B> A：。 22：21.364236 A> B 5401655 14がACKの場合：。 5526703：5531015（4312）14：22：21.364810 A> B：。 5531015：5535327（4312）14：22：21.364867 B> A：。 22：21.365819 A> B 5410279 14がACKの場合：。 5535327：5539639（4312）14：22：21.366386 A> B：。 5539639：5543951（4312）14：22：21.366427 B> A：。 22：21.367586 A> B 5418903 14がACKの場合：。 5543951：5548263（4312）14：22：21.368158 A> B：。 5548263：5552575（4312）14：22：21.368199 B> A：。 22：21.369189 A> B 5427527 14がACKの場合：。 5552575：5556887（4312）14：22：21.369758 A> B：。 5556887：5561199（4312）14：22：21.369803 B> A：。 22：21.370814 A> B 5436151 14がACKの場合：。 5561199：5565511（4312）14：22：21.371398 A> B：。 5565511：5569823（4312）14：22：21.375159 B> A：。 22：21.376658 A> B 5444775 14がACKの場合：。 5569823：5574135（4312）14：22：21.377235 A> B：。 5574135：5578447（4312）14：22：21.379303 B> A：。 22：21.380802 A> B 5453399 14がACKの場合：。 5578447：5582759（4312）14：22：21.381377 A> B：。 5582759：5587071（4312）14：22：21.381947 A> B：。 5587071：5591383（4312）****
"***" marks the end of the first round trip. Note that cwnd did not increase (as evidenced by each ACK eliciting two new data packets). Only at "****", which comes near the end of the second round trip, does cwnd increase by one packet.
「***」の最初のラウンドトリップの終わりを示します。 CWNDが（二つの新しいデータパケットを引き出す各ACKによって明らかなように）増加しなかったことに注意してください。のみ「****」、第二ラウンドトリップの終わり近くに来る時に、1個のパケット分の増加をcwndをありません。
This trace did not suffer any timeout retransmissions. It transferred the same amount of data as the first trace in about half as much time. This difference is repeatable between hosts A and B.
このトレースは、任意のタイムアウト再送を受けませんでした。それは多くの時間と約半分に最初のトレースと同じ量のデータを転送します。この差は、ホストAとBとの間に反復可能です
References [Stevens94] and [Wright95] discuss this problem. The problem of Reno TCP failing to recover from multiple losses except via a retransmission timeout is discussed in [Fall96,Hoe96].
参考文献[Stevens94]と[Wright95]この問題を議論します。再送タイムアウト介し以外複数の損失から回復することができないリノTCPの問題は[Fall96、Hoe96]に記載されています。
How to detect If source code is available, that is generally the easiest way to detect this problem. Search for each modification to the cwnd variable; (at least) one of these will be for congestion avoidance, and inspection of the related code should immediately identify the problem if present.
ソースコードが利用可能であるかどうかを検出する方法、それは一般的に、この問題を検出するための最も簡単な方法です。 cwnd変数への各変更を検索します。 （少なくとも）これらのいずれかが輻輳回避のためになり、存在する場合、関連するコードの検査は直ちに問題を識別すべきです。
The problem can also be detected by closely examining packet traces taken near the sender. During congestion avoidance, cwnd will increase by an additional segment upon the receipt of (typically) eight acknowledgements without a loss. This increase is in addition to the one segment increase per round trip time (or two round trip times if the receiver is using delayed ACKs).
問題は密接に送信者の近くに撮影したパケットトレースを調べることにより検出することができます。輻輳回避中、CWNDは損失なしに（通常は）8つの肯定応答を受信すると、追加のセグメントによって増大します。 （受信機が遅延ACKを使用している場合又は二ラウンドトリップ時間）、この増加は、ラウンドトリップ時間当たり一つのセグメントの増加に加えてあります。
Furthermore, graphs of the sequence number vs. time, taken from packet traces, are normally linear during congestion avoidance. When viewing packet traces of transfers from senders exhibiting this problem, the graphs appear quadratic instead of linear.
また、パケットトレースから採取時間に対するシーケンス番号のグラフは、通常、輻輳回避中に線形です。この問題を示す送信者から転送パケットトレースを表示する場合、グラフではなく、線形の二次現れます。
Finally, the traces will show that, with sufficiently large windows, nearly every loss event results in a timeout.
最後に、トレースは十分に大きな窓、タイムアウトでほぼすべての損失事象の結果と、それが表示されます。
How to fix This problem may be corrected by removing the "+ MSS/8" term from the congestion avoidance code that increases cwnd each time an ACK of new data is received.
どのようにこの問題を解決するには、新しいデータのACKが受信されるcwndのたびに増加し、輻輳回避コードから「+ MSS / 8」という用語を削除することによって補正することができます。
Name of Problem Initial RTO too low
問題の初期RTOの名前が低すぎます
Classification Performance
分類性能
Description When a TCP first begins transmitting data, it lacks the RTT measurements necessary to have computed an adaptive retransmission timeout (RTO). RFC 1122, 4.2.3.1, states that a TCP SHOULD initialize RTO to 3 seconds. A TCP that uses a lower value exhibits "Initial RTO too low".
説明TCPは最初のデータ送信を開始すると、それは適応再送タイムアウト（RTO）を計算しているために必要なRTT測定値を欠いています。 RFC 1122、4.2.3.1は、TCPは3秒にRTOを初期化するべきであると述べています。低い値を使用してTCPは、「低すぎる初期RTO」を示します。
Significance In environments with large RTTs (where "large" means any value larger than the initial RTO), TCPs will experience very poor performance.
（「大」は初期RTOよりも大きな任意の値を意味する）大のRTTを持つ環境で意義、TCPは非常にパフォーマンスの低下が発生します。
Implications Whenever RTO < RTT, very poor performance can result as packets are unnecessarily retransmitted (because RTO will expire before an ACK for the packet can arrive) and the connection enters slow start and congestion avoidance. Generally, the algorithms for computing RTO avoid this problem by adding a positive term to the estimated RTT. However, when a connection first begins it must use some estimate for RTO, and if it picks a value less than RTT, the above problems will arise.
パケットが不必要に再送されるよう（パケットのACKが到着する前に、RTOが期限切れになるため）、接続が遅いスタートと輻輳回避に出るたびRTO <RTT、非常に貧弱なパフォーマンス意味合いが発生することがあります。一般的に、RTOを計算するためのアルゴリズムは、推定RTTに正の用語を追加することで、この問題を回避します。しかし、接続が最初に開始したときには、RTOのためのいくつかの推定値を使用する必要があり、それはRTT未満の値を選ぶ場合は、上記の問題が発生します。
Furthermore, when the initial RTO < RTT, it can take a long time for the TCP to correct the problem by adapting the RTT estimate, because the use of Karn's algorithm (mandated by RFC 1122, 4.2.3.1) will discard many of the candidate RTT measurements made after the first timeout, since they will be measurements of retransmitted segments.
時の初期RTO <RTTさらに、それは（RFC 1122、4.2.3.1によって義務付け）カーンのアルゴリズムの使用は、候補者の多くが破棄されますので、RTT推定値を適応させることによって、問題を修正するために、TCPのために長い時間がかかることがありますそれらは再送セグメントの測定であるのでRTT測定値は、最初のタイムアウト後に行われました。
Relevant RFCs RFC 1122 states that TCPs SHOULD initialize RTO to 3 seconds and MUST implement Karn's algorithm.
関連のRFCのRFC 1122は、TCP間が3秒にRTOを初期化する必要がありますし、カーンのアルゴリズムを実装しなければならないと述べています。
Trace file demonstrating it The following trace file was taken using tcpdump at host A, the data sender. The advertised window and SYN options have been omitted for clarity.
それを実演するトレースファイルは、次のトレースファイルは、ホストA、データ送信側でのtcpdumpを使用して撮影されました。広告ウィンドウとSYNオプションは、明確にするために省略されています。
07:52:39.870301 A > B: S 2786333696:2786333696(0) 07:52:40.548170 B > A: S 130240000:130240000(0) ack 2786333697 07:52:40.561287 A > B: P 1:513(512) ack 1 07:52:40.753466 A > B: . 1:513(512) ack 1 07:52:41.133687 A > B: . 1:513(512) ack 1 07:52:41.458529 B > A: . ack 513 07:52:41.458686 A > B: . 513:1025(512) ack 1 07:52:41.458797 A > B: P 1025:1537(512) ack 1 07:52:41.541633 B > A: . ack 513 07:52:41.703732 A > B: . 513:1025(512) ack 1 07:52:42.044875 B > A: . ack 513 07:52:42.173728 A > B: . 513:1025(512) ack 1 07:52:42.330861 B > A: . ack 1537 07:52:42.331129 A > B: . 1537:2049(512) ack 1 07:52:42.331262 A > B: P 2049:2561(512) ack 1 07:52:42.623673 A > B: . 1537:2049(512) ack 1 07:52:42.683203 B > A: . ack 1537 07:52:43.044029 B > A: . ack 1537 07:52:43.193812 A > B: . 1537:2049(512) ack 1
07：52：39.870301のA> B：S 2786333696：2786333696（0）07：52：40.548170 B> A：Sの130240000：130240000（0）ACK 2786333697 07：52：40.561287 A> B：P 1：513（512） 52：40.753466 A> B 1 07がACKの場合：。 1：513（512）、ACK 1 07：52：41.133687 A> B：。 1：513（512）、ACK 1 07：52：41.458529 B> A：。確認応答513 07：52：41.458686 A> B：。 513：1025（512）、ACK 1 07：52：41.458797 A> B：P 1025：1537（512）、ACK 1 07：52：41.541633 B> A：。確認応答513 07：52：41.703732 A> B：。 513：1025（512）、ACK 1 07：52：42.044875 B> A：。確認応答513 07：52：42.173728 A> B：。 513：1025（512）、ACK 1 07：52：42.330861 B> A：。 52：42.331129 A> B 1537 07がACKの場合：。 1537：2049（512）、ACK 1 07：52：42.331262 A> B：P 2049：2561（512）、ACK 1 07：52：42.623673 A> B：。 1537：2049（512）、ACK 1 07：52：42.683203 B> A：。 52：1537年07 ackを43.044029 B> A：。 52：43.193812 A> B 1537 07がACKの場合：。 1537：2049（512）、ACK 1
Note from the SYN/SYN-ACK exchange, the RTT is over 600 msec. However, from the elapsed time between the third and fourth lines (the first packet being sent and then retransmitted), it is apparent the RTO was initialized to under 200 msec. The next line shows that this value has doubled to 400 msec (correct exponential backoff of RTO), but that still does not suffice to avoid an unnecessary retransmission.
SYN / SYN-ACK交換から注、RTTが600ミリ秒を超えています。しかし、3行目と4行目との間の経過時間から（最初のパケットが送信され、その後、再送）は、RTOが200ミリ秒未満に初期化された明らかです。次の行は、この値は400ミリ秒（RTOの正確な指数バックオフ）に倍増しているが、それは依然として不要再送を回避するために十分ではないことを示しています。
Finally, an ACK from B arrives for the first segment. Later two more duplicate ACKs for 513 arrive, indicating that both the original and the two retransmissions arrived at B. (Indeed, a concurrent trace at B showed that no packets were lost during the entire connection). This ACK opens the congestion window to two packets, which are sent back-to-back, but at 07:52:41.703732 RTO again expires after a little over 200 msec, leading to an unnecessary retransmission, and the pattern repeats. By the end of the trace excerpt above, 1536 bytes have been successfully transmitted from A to B, over an interval of more than 2 seconds, reflecting terrible performance.
最後に、BからACKが最初のセグメントのために到着します。後で513のための2つの重複ACKが（実際、Bにおける同時トレースが全くパケットが全体の接続中に失われなかったことを示した）元の二つの再送の両方がBに到着したことを示し、到着します。このACKは、背中合わせに送信された2つのパケットの輻輳ウィンドウを開きますが、07時：52：41.703732 RTOが再び不必要な再送を引き起こす、200ミリ秒にわたって少し後に期限切れに、パターンが繰り返されます。上記トレースの抜粋の終わりまでに、1536のバイトが正常ひどい性能を反映し、2秒以上の間隔で、AからBに送信されてきました。
Trace file demonstrating correct behavior The following trace file was taken using tcpdump at host C, the data sender. The advertised window and SYN options have been omitted for clarity.
正しい動作を実演するトレースファイルは、次のトレースファイルは、ホストC、データ送信側でのtcpdumpを使用して撮影されました。広告ウィンドウとSYNオプションは、明確にするために省略されています。
17:30:32.090299 C > D: S 2031744000:2031744000(0) 17:30:32.900325 D > C: S 262737964:262737964(0) ack 2031744001 17:30:32.900326 C > D: . ack 1 17:30:32.910326 C > D: . 1:513(512) ack 1 17:30:34.150355 D > C: . ack 513 17:30:34.150356 C > D: . 513:1025(512) ack 1 17:30:34.150357 C > D: . 1025:1537(512) ack 1 17:30:35.170384 D > C: . ack 1025 17:30:35.170385 C > D: . 1537:2049(512) ack 1 17:30:35.170386 C > D: . 2049:2561(512) ack 1 17:30:35.320385 D > C: . ack 1537 17:30:35.320386 C > D: . 2561:3073(512) ack 1 17:30:35.320387 C > D: . 3073:3585(512) ack 1 17:30:35.730384 D > C: . ack 2049
17：30：32.090299 C> D：S 2031744000：2031744000（0）17：30：32.900325 D> C：S 262 737 964 262 737 964（0）ACK 2031744001 17：30：32.900326 C> D :. OH 1時17 A.M：30：32.910326 C> D :. 1：513（512）ACK 1 17：30：34.150355 D> C. OH 513 17：30：34.150356 C> D :. 513 1025（512）OH 1：17 A.M：30：34.150357 C> D :. 1025 1537（512）OH 1時17 A.M：30：35.170384 D> C. 1025 OH 17：30：35.170385 C> D :. 2049（512）OH 1：17 A.M：30：1537 35.170386 C> D :. 2049：2561（512）OHで1時17分A.M：30：35.320385 D> C. 1537 OH 17：30：35.320386 C> D :. 3073（512）OH 1：17 A.M：30：2561 35.320387 C> D :. 3073：3585（512）OHで1時17分A.M：30：35.730384 D> C. 2049年オハイオ州
The initial SYN/SYN-ACK exchange shows that RTT is more than 800 msec, and for some subsequent packets it rises above 1 second, but C's retransmit timer does not ever expire.
最初のSYN / SYN-ACK交換はRTTが800以上のミリ秒であり、いくつかの後続のパケットのために、それは1秒以上に上昇することを示しているが、Cの再送信タイマーは、これまでに有効期限はありません。
References This problem is documented in [Paxson97].
参考文献は、この問題は、[Paxson97]に記述されています。
How to detect This problem is readily detected by inspecting a packet trace of the startup of a TCP connection made over a long-delay path. It can be diagnosed from either a sender-side or receiver-side trace. Long-delay paths can often be found by locating remote sites on other continents.
どのようにこの問題を検出することは容易に長い遅延パスを介して作られたTCPコネクションの開始のパケットトレースを検査することによって検出されます。これは、送信側または受信側のトレースのいずれかから診断することができます。長い遅延パスは、多くの場合、他の大陸でのリモートサイトを配置することによって見つけることができます。
How to fix As this problem arises from a faulty initialization, one hopes fixing it requires a one-line change to the TCP source code.
この問題は、障害のある初期化から生じるとおり修正する方法、人はそれを固定することは、TCPのソースコードに1行の変更を必要としたいと考えています。
Name of Problem Failure of window deflation after loss recovery
損失回復後のウィンドウのデフレの問題失敗の名前
Classification Congestion control / performance
分類輻輳制御/パフォーマンス
Description The fast recovery algorithm allows TCP senders to continue to transmit new segments during loss recovery. First, fast retransmission is initiated after a TCP sender receives three duplicate ACKs. At this point, a retransmission is sent and cwnd is halved. The fast recovery algorithm then allows additional segments to be sent when sufficient additional duplicate ACKs arrive. Some implementations of fast recovery compute when to send additional segments by artificially incrementing cwnd, first by three segments to account for the three duplicate ACKs that triggered fast retransmission, and subsequently by 1 MSS for each new duplicate ACK that arrives. When cwnd allows, the sender transmits new data segments.
説明高速回復アルゴリズムは、TCPの送信者が損失回復中に新しいセグメントを送信し続けることができます。 TCPの送信側が3つの重複ACKを受信した後まず、高速な再送信が開始されます。この時点で、再送が送信されるとのcwndが半分になります。高速回復アルゴリズムは、十分な追加重複ACKが到着したときに、追加のセグメントを送信することができます。到着したそれぞれの新しい重複ACKのためのいくつかの高速回復コンピューティングの実装人工的にcwndを増加させることによって、追加のセグメントを送信するために、高速な再送をトリガー3つの重複ACKを説明するには三つのセグメントによる最初の、そしてその後に1 MSSによります。 CWNDが許す場合、送信側は、新しいデータセグメントを送信します。
When an ACK arrives that covers new data, cwnd is to be reduced by the amount by which it was artificially increased. However, some TCP implementations fail to "deflate" the window, causing an inappropriate amount of data to be sent into the network after recovery. One cause of this problem is the "header prediction" code, which is used to handle incoming segments that require little work. In some implementations of TCP, the header prediction code does not check to make sure cwnd has not been artificially inflated, and therefore does not reduce the artificially increased cwnd when appropriate.
ACKは、それが新しいデータをカバーして到着すると、cwndはそれが人為的に増加した分だけ減少することがあります。しかし、いくつかのTCP実装は、回復後にネットワークに送信するデータの不適切な量を引き起こし、ウィンドウを「収縮」しません。この問題の一つの原因は、ほとんどの作業を必要とする着信セグメントを処理するために使用される「ヘッダ予測」コードです。 TCPのいくつかの実装では、ヘッダ予測コードは、cwndを人為的に膨張されていないので、適切な場合に人工的に増加したのcwndを低下させないことを確認するチェックしません。
Significance TCP senders that exhibit this problem will transmit a burst of data immediately after recovery, which can degrade performance, as well as network stability. Effectively, the sender does not reduce the size of cwnd as much as it should (to half its value when loss was detected), if at all. This can harm the performance of the TCP connection itself, as well as competing TCP flows.
この問題を呈する意義のTCPの送信者は、性能だけでなく、ネットワークの安定性を低下させることができ、すぐに回復した後にデータのバーストを送信します。 （損失が検出されたとき、その値の半分まで）で、すべての場合には効果的に、送信者は、同じくらいそれが必要としてのcwndのサイズを削減しません。これは、TCP接続自体だけでなく、競合するTCPフローのパフォーマンスに悪影響を与えることができます。
Implications A TCP sender exhibiting this problem does not reduce cwnd appropriately in times of congestion, and therefore may contribute to congestive collapse.
含意は、この問題を示すTCPの送信者は、輻輳時に適切にcwndを減少させないので、うっ血性崩壊に寄与することができます。
Relevant RFCs RFC 2001 outlines the fast retransmit/fast recovery algorithms. [Brakmo95] outlines this implementation problem and offers a fix.
関連のRFCのRFC 2001は、高速再送/高速回復アルゴリズムの概要を説明します。 [Brakmo95]この実装の問題を概説し、修正を提供しています。
Trace file demonstrating it The following trace file was taken using tcpdump at host A, the data sender. The advertised window (which never changed) has been omitted for clarity, except for the first packet sent by each host.
それを実演するトレースファイルは、次のトレースファイルは、ホストA、データ送信側でのtcpdumpを使用して撮影されました。 （変更されません）広告ウィンドウは、各ホストによって送信された第1のパケットを除き、明確にするために省略されています。
08:22:56.825635 A.7505 > B.7505: . 29697:30209(512) ack 1 win 4608 08:22:57.038794 B.7505 > A.7505: . ack 27649 win 4096 08:22:57.039279 A.7505 > B.7505: . 30209:30721(512) ack 1 08:22:57.321876 B.7505 > A.7505: . ack 28161 08:22:57.322356 A.7505 > B.7505: . 30721:31233(512) ack 1 08:22:57.347128 B.7505 > A.7505: . ack 28673 08:22:57.347572 A.7505 > B.7505: . 31233:31745(512) ack 1 08:22:57.347782 A.7505 > B.7505: . 31745:32257(512) ack 1 08:22:57.936393 B.7505 > A.7505: . ack 29185 08:22:57.936864 A.7505 > B.7505: . 32257:32769(512) ack 1 08:22:57.950802 B.7505 > A.7505: . ack 29697 win 4096 08:22:57.951246 A.7505 > B.7505: . 32769:33281(512) ack 1 08:22:58.169422 B.7505 > A.7505: . ack 29697 08:22:58.638222 B.7505 > A.7505: . ack 29697 08:22:58.643312 B.7505 > A.7505: . ack 29697 08:22:58.643669 A.7505 > B.7505: . 29697:30209(512) ack 1 08:22:58.936436 B.7505 > A.7505: . ack 29697 08:22:59.002614 B.7505 > A.7505: . ack 29697 08:22:59.003026 A.7505 > B.7505: . 33281:33793(512) ack 1 08:22:59.682902 B.7505 > A.7505: . ack 33281 08:22:59.683391 A.7505 > B.7505: P 33793:34305(512) ack 1 08:22:59.683748 A.7505 > B.7505: P 34305:34817(512) ack 1 *** 08:22:59.684043 A.7505 > B.7505: P 34817:35329(512) ack 1 08:22:59.684266 A.7505 > B.7505: P 35329:35841(512) ack 1 08:22:59.684567 A.7505 > B.7505: P 35841:36353(512) ack 1 08:22:59.684810 A.7505 > B.7505: P 36353:36865(512) ack 1 08:22:59.685094 A.7505 > B.7505: P 36865:37377(512) ack 1
08：22：56.825635 A.7505> B.7505：。 29697：30209（512）ACK 1勝4608 08：22：57.038794 B.7505> A.7505：。 > B.7505を57.039279 A.7505：22：27649 08 4096に勝つACKの場合：。 30209：30721（512）ACK 1 08：22：57.321876 B.7505> A.7505：。 22：57.322356 A.7505> B.7505 28161 08 ACKの場合：。 30721：31233（512）ACK 1 08：22：57.347128 B.7505> A.7505：。 22：57.347572 A.7505> B.7505 28673 08 ACKの場合：。 31233：31745（512）ACK 1 08：22：57.347782 A.7505> B.7505：。 31745：32257（512）ACK 1 08：22：57.936393 B.7505> A.7505：。 22：57.936864 A.7505> B.7505 29185 08 ACKの場合：。 32257：32769（512）ACK 1 08：22：57.950802 B.7505> A.7505：。 > B.7505を57.951246 A.7505：22：29697 08 4096に勝つACKの場合：。 32769：33281（512）ACK 1 08：22：58.169422 B.7505> A.7505：。 ：22：：> A.7505 B.7505 58.638222 29697 08 ackを。 ：22：：> A.7505 B.7505 58.643312 29697 08 ackを。 22：58.643669 A.7505> B.7505 29697 08 ACKの場合：。 29697：30209（512）ACK 1 08：22：58.936436 B.7505> A.7505：。 ：22：：> A.7505 B.7505 59.002614 29697 08 ackを。 22：59.003026 A.7505> B.7505 29697 08 ACKの場合：。 33281：33793（512）ACK 1 08：22：59.682902 B.7505> A.7505：。 22：59.683391 A.7505> B.7505：Pの33793：34305（512）ACK 1 08：22：59.683748 A.7505> B.7505：Pの34305：34817（512）ACK 1 08 *** 33281 08は、ACK ：22：59.684043 A.7505> B.7505：Pの34817：35329（512）ACK 1 08：22：59.684266 A.7505> B.7505：Pの35329：35841（512）ACK 1 08：22：59.684567のA. 7505> B.7505：Pの35841：36353（512）ACK 1 08：22：59.684810 A.7505> B.7505：Pの36353：36865（512）ACK 1 08：22：59.685094 A.7505> B.7505。 P 36865：37377（512）ACK 1
The first 12 lines of the trace show incoming ACKs clocking out a window of data segments. At this point in the transfer, cwnd is 7 segments. The next 4 lines of the trace show 3 duplicate ACKs arriving from the receiver, followed by a retransmission from the sender. At this point, cwnd is halved (to 3 segments) and artificially incremented by the three duplicate ACKs that have arrived, making cwnd 6 segments. The next two lines show 2 more duplicate ACKs arriving, each of which increases cwnd by 1 segment. So, after these two duplicate ACKs arrive the cwnd is 8 segments and the sender has permission to send 1 new segment (since there are 7 segments outstanding). The next line in the trace shows this new segment being transmitted. The next packet shown in the trace is an ACK from host B that covers the first 7 outstanding segments (all but the new segment sent during recovery). This should cause cwnd to be reduced to 3 segments and 2 segments to be transmitted (since there is already 1 outstanding segment in the network). However, as shown by the last 7 lines of the trace, cwnd is not reduced, causing a line-rate burst of 7 new segments.
トレースの最初の12行は、データセグメントの窓を計時受信ACKを示しています。転送のこの時点で、CWNDは、7つのセグメントです。トレースの次の4行は、送信側からの再送に続いて受信機から到着3つの重複ACKを示します。この時点で、CWND（3つのセグメントに）半減され、人為的にCWND 6つのセグメントを作り、到着した3個の重複ACKインクリメント。次の2行は、1つのセグメントによってCWNDが増加各々が到着する2つの以上の重複ACKを示します。だから、これらの二つの重複ACKが到着した後にcwndは8つのセグメントで、送信者が（未解決の7つのセグメントがあるので）1つの新しいセグメントを送信する権限を持ちます。トレースの次の行が送信されているこの新しいセグメントを示しています。トレースに示される次のパケットは、（回復中に送信される新しいセグメントが、すべての）第7未処理のセグメントをカバーし、ホストBからのACKです。 （1つの傑出したセグメントは、ネットワーク内に既に存在するので）これは、CWNDが送信される3つのセグメント及び2つのセグメントに減少させるべきです。しかし、トレースの最後の7行で示すように、CWNDが7つの新たなセグメントのラインレートバーストを引き起こし、減少しません。
Trace file demonstrating correct behavior The trace would appear identical to the one above, only it would stop after the line marked "***", because at this point host A would correctly reduce cwnd after recovery, allowing only 2 segments to be transmitted, rather than producing a burst of 7 segments.
この時点のホストでAが正しく、唯一の2つのセグメントを送信することができるように、回復後にcwndを減らすことになるので、トレースは、「***」の行がマークされた後にのみ、それは停止する、上記のものと同じに見える正しい動作を実証したファイルをトレースむしろ、7つのセグメントのバーストを生成するより。
References This problem is documented and the performance implications analyzed in [Brakmo95].
参考資料この問題は、文書化され、パフォーマンスへの影響は、[Brakmo95]で分析しました。
How to detect Failure of window deflation after loss recovery can be found by examining sender-side packet traces recorded during periods of moderate loss (so cwnd can grow large enough to allow for fast recovery when loss occurs).
損失の回復が緩やかな損失の期間（これにcwndは損失が発生した場合に高速リカバリを可能にするために十分な大きさに成長することができます）の間に記録された送信側のパケットトレースを調べることによって見つけることができた後、ウィンドウのデフレの故障を検出する方法。
How to fix When this bug is caused by incorrect header prediction, the fix is to add a predicate to the header prediction test that checks to see whether cwnd is inflated; if so, the header prediction test fails and the usual ACK processing occurs, which (in this case) takes care to deflate the window. See [Brakmo95] for details.
このバグは、誤ったヘッダ予測によって引き起こされる場合には修正するためにどのように、修正がCWNDが膨張されているかどうかをチェックし、ヘッダ予測テストに述語を追加することです。もしそうであれば、ヘッダ予測テストは失敗し、通常のACK処理が発生し、（この場合）ウィンドウを収縮するように注意をとります。詳細については、[Brakmo95]を参照してください。
Name of Problem Excessively short keepalive connection timeout
問題短すぎるキープアライブ接続タイムアウトの名前
Classification Reliability
分類の信頼性
Description Keep-alive is a mechanism for checking whether an idle connection is still alive. According to RFC 1122, keepalive should only be invoked in server applications that might otherwise hang indefinitely and consume resources unnecessarily if a client crashes or aborts a connection during a network failure.
説明キープアライブアイドル状態の接続がまだ生きているかどうかをチェックするためのメカニズムです。 RFC 1122によると、キープアライブはそうでない場合は無期限にハングアップすると、クライアントがクラッシュした場合、不必要にリソースを消費する可能性があるサーバーアプリケーションで呼び出されたか、ネットワーク障害時の接続を中止しなければなりません。
RFC 1122 also specifies that if a keep-alive mechanism is implemented it MUST NOT interpret failure to respond to any specific probe as a dead connection. The RFC does not specify a particular mechanism for timing out a connection when no response is received for keepalive probes. However, if the mechanism does not allow ample time for recovery from network congestion or delay, connections may be timed out unnecessarily.
RFC 1122はまた、キープアライブメカニズムが実装されている場合、それは死ん接続として特定のプローブへの応答に失敗したことを解釈してはならないことを指定します。 RFCは、応答がキープアライブプローブのために受信されない接続をタイムアウトするための特定の機構を指定しません。メカニズムは、ネットワークの輻輳や遅延からの回復のための十分な時間を許可していない場合は、接続が不必要にタイムアウトしても良いです。
Significance In congested networks, can lead to unwarranted termination of connections.
混雑したネットワークで意義は、接続の不当な終了につながることができます。
Implications It is possible for the network connection between two peer machines to become congested or to exhibit packet loss at the time that a keep-alive probe is sent on a connection. If the keep-alive mechanism does not allow sufficient time before dropping connections in the face of unacknowledged probes, connections may be dropped even when both peers of a connection are still alive.
2台のピア・マシン間のネットワーク接続が混雑したり、キープアライブプローブが接続で送信された時点で、パケットロスを発揮するための含意ことが可能です。キープアライブメカニズムは未確認のプローブの顔に接続を切断する前に十分な時間を許可しない場合、接続は、接続の両方のピアがまだ生きていてもドロップすることができます。
Relevant RFCs RFC 1122 specifies that the keep-alive mechanism may be provided. It does not specify a mechanism for determining dead connections when keepalive probes are not acknowledged.
関連のRFCのRFC 1122は、キープアライブメカニズムを提供することができることを指定します。これは、キープアライブプローブが確認されていない時に死んでの接続を決定するためのメカニズムを指定しません。
Trace file demonstrating it Made using the Orchestra tool at the peer of the machine using keep-alive. After connection establishment, incoming keep-alives were dropped by Orchestra to simulate a dead connection.
トレース・ファイルには、キープアライブ使用してマシンのピアでオーケストラのツールを使用して作られて実証しました。接続確立後、入ってくるキープアライブが死んでの接続をシミュレートするために、オーケストラによって廃棄されました。
22:11:12.040000 A > B: 22666019:0 win 8192 datasz 4 SYN 22:11:12.060000 B > A: 2496001:22666020 win 4096 datasz 4 SYN ACK 22:11:12.130000 A > B: 22666020:2496002 win 8760 datasz 0 ACK (more than two hours elapse) 00:23:00.680000 A > B: 22666019:2496002 win 8760 datasz 1 ACK 00:23:01.770000 A > B: 22666019:2496002 win 8760 datasz 1 ACK 00:23:02.870000 A > B: 22666019:2496002 win 8760 datasz 1 ACK 00:23.03.970000 A > B: 22666019:2496002 win 8760 datasz 1 ACK
22：11：12.040000のA> B：22666019：0勝つ8192 datasz 4 SYN 22：11：12.060000 B> A：2496001：22666020 4096 dataszを獲得4 SYN ACK 22：11：12.130000 A> B：22666020：2496002勝つ8760 datasz 0 ACK（二つ以上の時間経過）00：23：00.680000 A> B：22666019：2496002 8760 datasz 1 ACK 00勝利：23：01.770000 A> B：22666019：2496002勝つ8760 datasz 1 ACK 00：23：02.870000 Aを> B：22666019：2496002勝つ8760 datasz 1 ACK 00：23.03.970000 A> B：22666019：2496002勝つ8760 datasz 1 ACK
00:23.05.070000 A > B: 22666019:2496002 win 8760 datasz 1 ACK
00：23.05.070000 A> B：22666019：2496002が勝つ8760 datasz 1 ACK
The initial three packets are the SYN exchange for connection setup. About two hours later, the keepalive timer fires because the connection has been idle. Keepalive probes are transmitted a total of 5 times, with a 1 second spacing between probes, after which the connection is dropped. This is problematic because a 5 second network outage at the time of the first probe results in the connection being killed.
最初の3つのパケットには、接続設定のためのSYN交換あります。約2時間後に、キープアライブタイマー火災接続がアイドル状態だったため。キープアライブプローブは、接続が切断された後にプローブ間の1秒の間隔で、合計5回送信されます。接続の最初のプローブ結果の時に5秒ネットワーク障害が殺されているので、これは問題です。
Trace file demonstrating correct behavior Made using the Orchestra tool at the peer of the machine using keep-alive. After connection establishment, incoming keep-alives were dropped by Orchestra to simulate a dead connection.
正しい動作を実演するトレースファイルには、キープアライブ使用してマシンのピアでオーケストラのツールを使用して作られました。接続確立後、入ってくるキープアライブが死んでの接続をシミュレートするために、オーケストラによって廃棄されました。
16:01:52.130000 A > B: 1804412929:0 win 4096 datasz 4 SYN 16:01:52.360000 B > A: 16512001:1804412930 win 4096 datasz 4 SYN ACK 16:01:52.410000 A > B: 1804412930:16512002 win 4096 datasz 0 ACK (two hours elapse) 18:01:57.170000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:03:12.220000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:04:27.270000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:05:42.320000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:06:57.370000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:08:12.420000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:09:27.480000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:10:43.290000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:11:57.580000 A > B: 1804412929:16512002 win 4096 datasz 0 ACK 18:13:12.630000 A > B: 1804412929:16512002 win 4096 datasz 0 RST ACK
16：01：52.130000のA> B：1804412929：01：52.360000 B> A：16512001：1804412930勝つ4096 datasz 4 SYN ACK 16：01：52.410000 A> B：1804412930：16512002勝つ4096 datasz 0 4096 datasz 4 SYN 16に勝ちます0 ACK（二時間経過）18：01：57.170000 A> B：1804412929：16512002勝つ4096 datasz 0 ACK 18：03：12.220000 A> B：1804412929：勝つ4096 datasz 0 ACK 18 16512002：04：27.270000 A> B： 1804412929：勝つ4096 16512002 datasz 0 ACK 18：05：42.320000 A> B：1804412929：16512002勝つ4096 datasz 0 ACK 18：06：57.370000 A> B：1804412929：16512002勝つ4096 datasz 0 ACK 18：08：12.420000 A> B ：1804412929：16512002 ACK 18を4096 datasz 0を獲得：09：27.480000 A> B：1804412929：16512002勝つ4096 datasz 0 ACK 18：10：43.290000 A> B：1804412929：勝つ4096 16512002 datasz 0 ACK 18：11：57.580000 A> B：1804412929：16512002勝つ4096 datasz 0 ACK 18：13：12.630000のA> B：1804412929：16512002勝つ4096 datasz 0 RST ACK
In this trace, when the keep-alive timer expires, 9 keepalive probes are sent at 75 second intervals. 75 seconds after the last probe is sent, a final RST segment is sent indicating that the connection has been closed. This implementation waits about 11 minutes before timing out the connection, while the first implementation shown allows only 5 seconds.
キープアライブタイマーが満了したとき、このトレースでは、9つのキープアライブプローブは、75秒間隔で送信されます。最後のプローブが送信された75秒後に、最終的なRSTセグメントは、接続が閉じられたことを示す送信されます。図示最初の実装はわずか5秒を可能にしながら、この実装では、接続がタイムアウトする前に約11分間待ちます。
References This problem is documented in [Dawson97].
参考文献は、この問題は、[Dawson97]に記述されています。
How to detect For implementations manifesting this problem, it shows up on a packet trace after the keepalive timer fires if the peer machine receiving the keepalive does not respond. Usually the keepalive timer will fire at least two hours after keepalive is turned on, but it may be sooner if the timer value has been configured lower, or if the keepalive mechanism violates the specification (see Insufficient interval between keepalives problem). In this example, suppressing the response of the peer to keepalive probes was accomplished using the Orchestra toolkit, which can be configured to drop packets. It could also have been done by creating a connection, turning on keepalive, and disconnecting the network connection at the receiver machine.
この問題を顕在実装を検出するためにどのようにキープアライブを受信したピア・マシンが応答しない場合、それは、キープアライブタイマーが起動した後、パケットトレースに表示されます。通常、キープアライブタイマーはキープアライブが（キープアライブの問題間の不十分な間隔を参照）がオンになっているが、タイマ値が低く設定されている場合、それはすぐにであってもよいし、キープアライブメカニズムが仕様に違反している場合、少なくとも2時間後に起動します。この例では、プローブをキープアライブするために、ピアの応答を抑制することは、パケットをドロップするように構成することができるオーケストラツールキットを用いて行きました。また、接続を作成するキープアライブをオンにすると、受信機でのネットワーク接続を切断することによって行われている可能性があります。
How to fix This problem can be fixed by using a different method for timing out keepalives that allows a longer period of time to elapse before dropping the connection. For example, the algorithm for timing out on dropped data could be used. Another possibility is an algorithm such as the one shown in the trace above, which sends 9 probes at 75 second intervals and then waits an additional 75 seconds for a response before closing the connection.
この問題を解決する方法の接続をドロップする前に経過する時間の長い期間を可能にキープアライブを計時する別の方法を用いて固定することができます。たとえば、ドロップされたデータのタイミングアウトのためのアルゴリズムを使用することができます。別の可能性は、75秒間隔で9つのプローブを送信し、接続を閉じる前に応答するための追加の75秒待機上のトレースに示されるもののようなアルゴリズムです。
Name of Problem Failure to back off retransmission timeout
再送タイムアウトをオフにバックアップする問題の失敗の名前
Classification Congestion control / reliability
分類輻輳制御/信頼性
Description The retransmission timeout is used to determine when a packet has been dropped in the network. When this timeout has expired without the arrival of an ACK, the segment is retransmitted. Each time a segment is retransmitted, the timeout is adjusted according to an exponential backoff algorithm, doubling each time. If a TCP fails to receive an ACK after numerous attempts at retransmitting the same segment, it terminates the connection. A TCP that fails to double its retransmission timeout upon repeated timeouts is said to exhibit "Failure to back off retransmission timeout".
説明再送タイムアウトは、パケットがネットワーク内でドロップされたときを決定するために使用されます。このタイムアウトは、ACKの到着せずに期限切れになった場合には、セグメントが再送されます。セグメントが再送されるたびに、タイムアウトは各倍加時間、指数バックオフアルゴリズムに従って調整されます。 TCPは、同じセグメントを再送で多数の試みの後にACKを受信できなかった場合、それは接続を終了します。繰り返しタイムアウト時にその再送タイムアウトを倍増するために失敗したTCPは、「再送タイムアウトをバックオフの失敗」を示すと言われています。
Significance Backing off the retransmission timer is a cornerstone of network stability in the presence of congestion. Consequently, this bug can have severe adverse affects in congested networks. It also affects TCP reliability in congested networks, as discussed in the next section.
再送タイマバックオフ意義は、輻輳の存在下でのネットワークの安定性の礎石です。したがって、このバグは不利な厳しい混雑したネットワークに影響を与えることができます。次のセクションで説明したようにそれはまた、混雑したネットワークでTCPの信頼性に影響を与えます。
Implications It is possible for the network connection between two TCP peers to become congested or to exhibit packet loss at the time that a retransmission is sent on a connection. If the retransmission mechanism does not allow sufficient time before dropping connections in the face of unacknowledged segments, connections may be dropped even when, by waiting longer, the connection could have continued.
2つのTCPピア間のネットワーク接続が混雑したり、再送信が接続で送信された時点で、パケットロスを発揮するための含意ことが可能です。再送メカニズムが未確認のセグメントの顔に接続を切断する前に十分な時間を許可しない場合、接続は長く待つことによって、接続が続いている可能性が場合でも、ドロップすることができます。
Relevant RFCs RFC 1122 specifies mandatory exponential backoff of the retransmission timeout, and the termination of connections after some period of time (at least 100 seconds).
関連のRFCのRFC 1122は必須指数再送タイムアウトのバックオフ、およびある程度の期間（少なくとも100秒）後の接続の終了を指定します。
Trace file demonstrating it Made using tcpdump on an intermediate host:
それを実演するトレースファイルは、中間ホスト上でtcpdumpを使用して作られました。
16:51:12.671727 A > B: S 510878852:510878852(0) win 16384 16:51:12.672479 B > A: S 2392143687:2392143687(0) ack 510878853 win 16384 16:51:12.672581 A > B: . ack 1 win 16384 16:51:15.244171 A > B: P 1:3(2) ack 1 win 16384 16:51:15.244933 B > A: . ack 3 win 17518 (DF)
16：51：12.671727 Aは> B：Sの510878852：51：510878852（0）16384 16に勝つ12.672479 Bは> A：S 2392143687：51：12.672581 A> B 2392143687（0）ACK 510878853 16384 16に勝ちます：。 51：15.244171 A> B：P 1：3（2）ACK 1 16384 16勝利：51：15.244933 B> Aを：ACK 1 16384 16に勝ちます。 3は17518に勝つACK（DF）
<receiving host disconnected>
<受信ホストが切断しました>
16:51:19.381176 A > B: P 3:5(2) ack 1 win 16384 16:51:20.162016 A > B: P 3:5(2) ack 1 win 16384 16:51:21.161936 A > B: P 3:5(2) ack 1 win 16384 16:51:22.161914 A > B: P 3:5(2) ack 1 win 16384 16:51:23.161914 A > B: P 3:5(2) ack 1 win 16384 16:51:24.161879 A > B: P 3:5(2) ack 1 win 16384 16:51:25.161857 A > B: P 3:5(2) ack 1 win 16384 16:51:26.161836 A > B: P 3:5(2) ack 1 win 16384 16:51:27.161814 A > B: P 3:5(2) ack 1 win 16384 16:51:28.161791 A > B: P 3:5(2) ack 1 win 16384 16:51:29.161769 A > B: P 3:5(2) ack 1 win 16384 16:51:30.161750 A > B: P 3:5(2) ack 1 win 16384 16:51:31.161727 A > B: P 3:5(2) ack 1 win 16384
16：51：19.381176のA> B：P 3：5（2）ACK 1が16384を獲得16：51：20.162016は、A> B：P 3：5（2）ACK 1が勝つ16384 16：51：21.161936 A> B：P 3：5（2）ACK 1が勝つ16384 16：51：22.161914のA> B：P 3：5（2）ACK 1が16384を獲得16：51：23.161914は、A> B：P 3：5（2）ACK 1勝つ16384 16：51：24.161879のA> B：P 3：5（2）ACK 1が16384を獲得16：51：25.161857は、A> B：P 3：5（2）ACK 1が勝つ16384 16：51：26.161836 A> B：P 3：5（2）ACK 1が勝つ16384 16：51：27.161814のA> B：P 3：5（2）ACK 1が16384を獲得16：51：28.161791は、A> B：P 3：5（2）ACK 1勝つ16384 16：51：29.161769のA> B：P 3：5（2）ACK 1が16384を獲得16：51：30.161750は、A> B：P 3：5（2）ACK 1が勝つ16384 16：51：31.161727 A> B：P 3：5（2）ACK 1が16384に勝ちます
16:51:32.161701 A > B: R 5:5(0) ack 1 win 16384
16：51：32.161701 A> B：R 5：5（0）ACK 1が16384に勝ちます
The initial three packets are the SYN exchange for connection setup, then a single data packet, to verify that data can be transferred. Then the connection to the destination host was disconnected, and more data sent. Retransmissions occur every second for 12 seconds, and then the connection is terminated with a RST. This is problematic because a 12 second pause in connectivity could result in the termination of a connection.
最初の3つのパケットは、データを転送することができることを確認し、接続設定のためのSYN交換、単一のデータ・パケットです。次いで、宛先ホストへの接続が切断され、より多くのデータが送信されました。再送は、12秒ごとに発生し、その後、接続がRSTで終了します。接続に12秒の休止が接続の終了をもたらす可能性があるため、これは問題です。
Trace file demonstrating correct behavior Again, a tcpdump taken from a third host:
再度正しい動作を実演するトレースファイル、第3のホストから取られたのtcpdump：
16:59:05.398301 A > B: S 2503324757:2503324757(0) win 16384 16:59:05.399673 B > A: S 2492674648:2492674648(0) ack 2503324758 win 16384 16:59:05.399866 A > B: . ack 1 win 17520 16:59:06.538107 A > B: P 1:3(2) ack 1 win 17520 16:59:06.540977 B > A: . ack 3 win 17518 (DF)
16：59：05.398301 A> B：S 2503324757：2503324757（0）16384 16勝利：59：05.399673 B> A：S 2492674648：59：2492674648（0）ACK 2503324758 16 16384を獲得05.399866 A> B：。 59：06.538107 A> B：P 1：3（2）ACK 1 17520 16勝利：59：06.540977 B> Aを：ACK 1 17520 16に勝ちます。 3は17518に勝つACK（DF）
<receiving host disconnected>
<受信ホストが切断しました>
16:59:13.121542 A > B: P 3:5(2) ack 1 win 17520 16:59:14.010928 A > B: P 3:5(2) ack 1 win 17520 16:59:16.010979 A > B: P 3:5(2) ack 1 win 17520 16:59:20.011229 A > B: P 3:5(2) ack 1 win 17520 16:59:28.011896 A > B: P 3:5(2) ack 1 win 17520 16:59:44.013200 A > B: P 3:5(2) ack 1 win 17520 17:00:16.015766 A > B: P 3:5(2) ack 1 win 17520 17:01:20.021308 A > B: P 3:5(2) ack 1 win 17520 17:02:24.027752 A > B: P 3:5(2) ack 1 win 17520 17:03:28.034569 A > B: P 3:5(2) ack 1 win 17520 17:04:32.041567 A > B: P 3:5(2) ack 1 win 17520 17:05:36.048264 A > B: P 3:5(2) ack 1 win 17520 17:06:40.054900 A > B: P 3:5(2) ack 1 win 17520
16：59：13.121542のA> B：P 3：5（2）ACK 1が17520を獲得16：59：14.010928は、A> B：P 3：5（2）ACK 1が勝つ17520 16：59：16.010979 A> B：P 3：5（2）ACK 1が勝つ17520 16：59：20.011229のA> B：P 3：5（2）ACK 1が17520を獲得16：59：28.011896は、A> B：P 3：5（2）ACK 1勝つ17520 16：59：44.013200のA> B：P 3：5（2）ACK 1が17520を獲得17：00：16.015766は、A> B：P 3：5（2）ACK 1が勝つ17520 17：01：20.021308 A> B：P 3：5（2）ACK 1が勝つ17520 17：02：24.027752のA> B：P 3：5（2）ACK 1が17520を獲得17：03：28.034569は、A> B：P 3：5（2）ACK 1勝つ17520 17：04：32.041567のA> B：P 3：5（2）ACK 1が17520を獲得17：05：36.048264は、A> B：P 3：5（2）ACK 1が勝つ17520 17：06：40.054900 A> B：P 3：5（2）ACK 1が17520に勝ちます
17:07:44.061306 A > B: R 5:5(0) ack 1 win 17520
17：07：44.061306 A> B：R 5：5（0）ACK 1が17520に勝ちます
In this trace, when the retransmission timer expires, 12 retransmissions are sent at exponentially-increasing intervals, until the interval value reaches 64 seconds, at which time the interval stops growing. 64 seconds after the last retransmission, a final RST segment is sent indicating that the connection has been closed. This implementation waits about 9 minutes before timing out the connection, while the first implementation shown allows only 12 seconds.
再送タイマが満了したときに間隔値が間隔が成長を停止し、その時点で64秒に達するまで、このトレースでは、12回の再送信は、指数関数的に増加した間隔で送信されます。 64秒最後の再送の後に、最終的なRSTセグメントは、接続が閉じられたことを示す送信されます。図示最初の実装はわずか12秒を可能にしながら、この実装では、接続がタイムアウトする前に、約9分間待ちます。
References None known.
参考認知済みのものは無し。
How to detect A simple transfer can be easily interrupted by disconnecting the receiving host from the network. tcpdump or another appropriate tool should show the retransmissions being sent. Several trials in a low-rtt environment may be required to demonstrate the bug.
簡単な転送を検出する方法簡単にネットワークから受信したホストを切断によって中断することができます。 tcpdumpのまたは別の適切なツールが送信されて再送信を表示する必要があります。低RTT環境でのいくつかの試験では、バグを実証するために必要な場合があります。
How to fix For one of the implementations studied, this problem seemed to be the result of an error introduced with the addition of the Brakmo-Peterson RTO algorithm [Brakmo95], which can return a value of zero where the older Jacobson algorithm always returns a positive value. Brakmo and Peterson specified an additional step of min(rtt + 2, RTO) to avoid problems with this. Unfortunately, in the implementation this step was omitted when calculating the exponential backoff for the RTO. This results in an RTO of 0 seconds being multiplied by the backoff, yielding again zero, and then being subjected to a later MAX operation that increases it to 1 second, regardless of the backoff factor.
古いヤコブソンアルゴリズムは常に返しどこ研究実装の1つの修正方法また、この問題は、ゼロの値を返すことができBrakmo・ピーターソンRTOアルゴリズム[Brakmo95]を追加で導入されたエラーの結果であるように見えました正の値。 Brakmoとピーターソンは、このに関する問題を回避するために、分（RTT + 2、RTO）の追加のステップを指定しました。 RTOのための指数バックオフを計算するときに残念なことに、実装では、このステップは省略されました。これは再びゼロを生じる、バックオフによって乗算される0秒のRTOをもたらし、その後に関係なくバックオフ因子の、1秒にそれを増加後MAX操作に供されます。
A similar TCP persist failure has the same cause.
同様のTCPは、障害が同じ原因が持続します。
Name of Problem Insufficient interval between keepalives
キープアライブ間の問題が不十分間隔の名前
Classification Reliability
分類の信頼性
Description Keep-alive is a mechanism for checking whether an idle connection is still alive. According to RFC 1122, keep-alive may be included in an implementation. If it is included, the interval between keep-alive packets MUST be configurable, and MUST default to no less than two hours.
説明キープアライブアイドル状態の接続がまだ生きているかどうかをチェックするためのメカニズムです。 RFC 1122によると、キープアライブが実装に含まれていてもよいです。それが含まれている場合は、キープアライブパケットの間隔は構成可能でなければなりません、そして2時間を下回らないをデフォルトとしなければなりません。
Significance In congested networks, can lead to unwarranted termination of connections.
混雑したネットワークで意義は、接続の不当な終了につながることができます。
Implications According to RFC 1122, keep-alive is not required of implementations because it could: (1) cause perfectly good connections to break during transient Internet failures; (2) consume unnecessary bandwidth ("if no one is using the connection, who cares if it is still good?"); and (3) cost money for an Internet path that charges for packets. Regarding this last point, we note that in addition the presence of dial-on-demand links in the route can greatly magnify the cost penalty of excess keepalives, potentially forcing a full-time connection on a link that would otherwise only be connected a few minutes a day.
含意はRFC 1122によると、キープアライブの実装が要求されていない、それは可能性があるため、（1）過渡インターネットの障害中に破損するのに最適な接続を引き起こします。 （「誰が、それはまだ良いであれば気に接続し、使用しない場合は？」）（2）は、不要な帯域幅を消費します。そして（3）パケットのための充電インターネットパスのためにお金がかかります。この最後の点については、私たちは、ほかにルートでダイヤルオンデマンドのリンクの存在は非常に潜在的にそうでない場合は、ほんの数を接続することになるリンク上での常時接続を強制的に、過剰キープアライブのコストペナルティを拡大することができますことに注意してください分の日。
If keepalive is provided the RFC states that the required inter-keepalive distance MUST default to no less than two hours. If it does not, the probability of connections breaking increases, the bandwidth used due to keepalives increases, and cost increases over paths which charge per packet.
キープアライブが提供されている場合RFCは、必要な間キープアライブ間隔が2時間を下回らないをデフォルトとしなければならないと述べています。そうでない場合は、増加を壊す接続する確率は、帯域幅は、パケット当たりの電荷の経路上に起因キープアライブが増加し、コストが上昇するために使用されます。
Relevant RFCs RFC 1122 specifies that the keep-alive mechanism may be provided. It also specifies the two hour minimum for the default interval between keepalive probes.
関連のRFCのRFC 1122は、キープアライブメカニズムを提供することができることを指定します。また、キープアライブプローブ間のデフォルトの間隔のために2時間の最小値を指定します。
Trace file demonstrating it Made using the Orchestra tool at the peer of the machine using keep-alive. Machine A was configured to use default settings for the keepalive timer.
トレース・ファイルには、キープアライブ使用してマシンのピアでオーケストラのツールを使用して作られて実証しました。マシンAには、キープアライブタイマーのデフォルト設定を使用するように設定されました。
11:36:32.910000 A > B: 3288354305:0 win 28672 datasz 4 SYN 11:36:32.930000 B > A: 896001:3288354306 win 4096 datasz 4 SYN ACK 11:36:32.950000 A > B: 3288354306:896002 win 28672 datasz 0 ACK
11：36：32.910000 A> B：3288354305：0勝つ28672 datasz 4 SYN 11：36：32.930000 B> A：896001：3288354306勝つ4096 datasz 4 SYNはACK 11：36：32.950000 A> B：3288354306：896002勝つ28672 datasz 0 ACK
11:50:01.190000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 11:50:01.210000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
11：50：01.190000 A> B：3288354305：896002勝つ28672 datasz 0 ACK 11：50：01.210000 B> A：896002：3288354306勝つ4096 datasz 0 ACK
12:03:29.410000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 12:03:29.430000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
12：03：29.410000 A> B：3288354305：896002勝つ28672 datasz 0 ACK 12：03：29.430000 B> A：896002：3288354306勝つ4096 datasz 0 ACK
12:16:57.630000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 12:16:57.650000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
12：16：57.630000 A> B：3288354305：896002勝つ28672 datasz 0 ACK 12：16：57.650000 B> A：896002：3288354306勝つ4096 datasz 0 ACK
12:30:25.850000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 12:30:25.870000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
12：30：25.850000 A> B：3288354305：896002勝つ28672 datasz 0 ACK 12：30：25.870000 B> A：896002：3288354306勝つ4096 datasz 0 ACK
12:43:54.070000 A > B: 3288354305:896002 win 28672 datasz 0 ACK 12:43:54.090000 B > A: 896002:3288354306 win 4096 datasz 0 ACK
12：43：54.070000 A> B：3288354305：896002勝つ28672 datasz 0 ACK 12：43：54.090000 B> A：896002：3288354306勝つ4096 datasz 0 ACK
The initial three packets are the SYN exchange for connection setup. About 13 minutes later, the keepalive timer fires because the connection is idle. The keepalive is acknowledged, and the timer fires again in about 13 more minutes. This behavior continues indefinitely until the connection is closed, and is a violation of the specification.
最初の3つのパケットには、接続設定のためのSYN交換あります。約13分後に、キープアライブタイマー火災接続がアイドル状態であるためです。キープアライブは、約13分以上に再び認め、タイマーが起動されます。この現象は、接続がクローズされるまで無期限に継続し、仕様の違反です。
Trace file demonstrating correct behavior Made using the Orchestra tool at the peer of the machine using keep-alive. Machine A was configured to use default settings for the keepalive timer.
正しい動作を実演するトレースファイルには、キープアライブ使用してマシンのピアでオーケストラのツールを使用して作られました。マシンAには、キープアライブタイマーのデフォルト設定を使用するように設定されました。
17:37:20.500000 A > B: 34155521:0 win 4096 datasz 4 SYN 17:37:20.520000 B > A: 6272001:34155522 win 4096 datasz 4 SYN ACK 17:37:20.540000 A > B: 34155522:6272002 win 4096 datasz 0 ACK
17：37：20.500000のA> B：34155521：0勝つ4096 datasz 4 SYN 17：37：20.520000 B> A：6272001：34155522 4096 dataszを獲得4 SYN ACK 17：37：20.540000 A> B：34155522：6272002勝つ4096 datasz 0 ACK
19:37:25.430000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 19:37:25.450000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
19：37：25.430000 A> B：34155521：6272002勝つ4096 datasz 0 ACK 19：37：25.450000 B> A：6272002：34155522勝つ4096 datasz 0 ACK
21:37:30.560000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 21:37:30.570000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
21：37：30.560000 A> B：34155521：6272002勝つ4096 datasz 0 ACK 21：37：30.570000 B> A：6272002：34155522勝つ4096 datasz 0 ACK
23:37:35.580000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 23:37:35.600000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
23：37：35.580000 A> B：34155521：6272002勝つ4096 datasz 0 ACK 23：37：35.600000 B> A：6272002：34155522勝つ4096 datasz 0 ACK
01:37:40.620000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 01:37:40.640000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
01：37：40.620000 A> B：34155521：6272002勝つ4096 datasz 0 ACK 01：37：40.640000 B> A：6272002：34155522勝つ4096 datasz 0 ACK
03:37:45.590000 A > B: 34155521:6272002 win 4096 datasz 0 ACK 03:37:45.610000 B > A: 6272002:34155522 win 4096 datasz 0 ACK
03：37：45.590000 A> B：34155521：6272002勝つ4096 datasz 0 ACK 03：37：45.610000 B> A：6272002：34155522勝つ4096 datasz 0 ACK
The initial three packets are the SYN exchange for connection setup. Just over two hours later, the keepalive timer fires because the connection is idle. The keepalive is acknowledged, and the timer fires again just over two hours later. This behavior continues indefinitely until the connection is closed.
最初の3つのパケットには、接続設定のためのSYN交換あります。わずか2時間後に、キープアライブタイマー火災接続がアイドル状態であるためです。キープアライブは、タイマ火災はわずか2時間後に再び認め、とされます。接続が閉じられるまで、この動作は、無限に続きます。
References This problem is documented in [Dawson97].
参考文献は、この問題は、[Dawson97]に記述されています。
How to detect For implementations manifesting this problem, it shows up on a packet trace. If the connection is left idle, the keepalive probes will arrive closer together than the two hour minimum.
この問題を顕在実装を検出するためにどのように、それはパケットトレースに表示されます。接続がアイドル状態のままにすると、キープアライブプローブは、2時間の最小値よりも互いに接近して到着します。
Name of Problem Window probe deadlock
問題ウィンドウプローブのデッドロックの名前
Classification Reliability
分類の信頼性
Description When an application reads a single byte from a full window, the window should not be updated, in order to avoid Silly Window Syndrome (SWS; see [RFC813]). If the remote peer uses a single byte of data to probe the window, that byte can be accepted into the buffer. In some implementations, at this point a negative argument to a signed comparison causes all further new data to be considered outside the window; consequently, it is discarded (after sending an ACK to resynchronize). These discards include the ACKs for the data packets sent by the local TCP, so the TCP will consider the data unacknowledged.
説明アプリケーションが全ウィンドウから1バイトを読み取ると、ウィンドウは愚かなウィンドウ症候群（SWS; [RFC813]参照）を回避するために、更新されるべきではありません。リモートピアがウィンドウをプローブするためにデータの1バイトを使用する場合、そのバイトは、バッファに受け入れることができます。いくつかの実装形態では、この時点で署名された比較に負の引数は、ウィンドウの外に考慮すべき全ての更なる新しいデータを生じさせます。結果的に、それは（再同期するACKを送信した後に）破棄されます。 TCPは、データが未確認検討していきますので、これらを廃棄するには、ローカルTCPによって送信されたデータパケットのACKを含んでいます。
Consequently, the application may be unable to complete sending new data to the remote peer, because it has exhausted the transmit buffer available to its local TCP, and buffer space is never being freed because incoming ACKs that would do so are being discarded. If the application does not read any more data, which may happen due to its failure to complete such sends, then deadlock results.
それはそのローカルTCPに利用可能な送信バッファを使い果たした、とそうでしょう、着信ACKが破棄されているので、バッファ・スペースが解放されないされないされているのでその結果、アプリケーションは、リモートピアに新しいデータを送信完了できない場合があります。アプリケーションが送信などを完了するために、その故障が原因で起こる可能性があり、それ以上のデータを、読んでいない場合は、その結果をデッドロック。
Significance It's relatively rare for applications to use TCP in a manner that can exercise this problem. Most applications only transmit bulk data if they know the other end is prepared to receive the data. However, if a client fails to consume data, putting the server in persist mode, and then consumes a small amount of data, it can mistakenly compute a negative window. At this point the client will discard all further packets from the server, including ACKs of the client's own data, since they are not inside the (impossibly-sized) window. If subsequently the client consumes enough data to then send a window update to the server, the situation will be rectified. That is, this situation can only happen if the client consumes 1 < N < MSS bytes, so as not to cause a window update, and then starts its own transmission towards the server of more than a window's worth of data.
意義のアプリケーションは、この問題を行使することができます方法で、TCPを使用することは比較的まれです。彼らはもう一方の端がデータを受信する準備が知っていれば、ほとんどのアプリケーションでは、唯一の大量のデータを送信します。クライアントモードを持続して、サーバーを置く、データを消費するために失敗し、少量のデータを消費している場合しかし、それは誤って負のウィンドウを計算することができます。彼らは（信じられないほどの大きさ）ウィンドウ内ではありませんので、この時点でクライアントは、クライアント自身のデータのACKを含め、サーバーからすべてのさらなるのパケットを破棄します。その後、クライアントは、サーバへのウィンドウ更新を送信するために十分なデータを消費した場合、状況は是正されます。つまり、このような状況は、クライアントが1 <N消費した場合、ウィンドウの更新が発生しないように、MSSバイト<起こり、その後、データのウィンドウの価値以上のサーバーに向けて、自身の送信を開始することができます。
Implications TCP connections will hang and eventually time out.
含意TCP接続がハングし、最終的にタイムアウトします。
Relevant RFCs RFC 793 describes zero window probing. RFC 813 describes Silly Window Syndrome.
関連のRFC RFC 793は、プロービングゼロウィンドウについて説明します。 RFC 813は、愚かな窓シンドロームについて説明します。
Trace file demonstrating it Trace made from a version of tcpdump modified to print out the sequence number attached to an ACK even if it's dataless. An unmodified tcpdump would not print seq:seq(0); however, for this bug, the sequence number in the ACK is important for unambiguously determining how the TCP is behaving.
それを実演するトレースファイルには、データレスだ場合でも、ACKに添付シーケンス番号を印刷するように変更のtcpdumpのバージョンから作られたトレース。未修飾のtcpdumpは配列を印刷しないであろう：配列（0）。しかし、このバグのため、ACKのシーケンス番号は、TCPがどのように動作しているか明確に決定するために重要です。
[ Normal connection startup and data transmission from B to A. Options, including MSS of 16344 in both directions, omitted for clarity. ] 16:07:32.327616 A > B: S 65360807:65360807(0) win 8192 16:07:32.327304 B > A: S 65488807:65488807(0) ack 65360808 win 57344 16:07:32.327425 A > B: . 1:1(0) ack 1 win 57344 16:07:32.345732 B > A: P 1:2049(2048) ack 1 win 57344 16:07:32.347013 B > A: P 2049:16385(14336) ack 1 win 57344 16:07:32.347550 B > A: P 16385:30721(14336) ack 1 win 57344 16:07:32.348683 B > A: P 30721:45057(14336) ack 1 win 57344 16:07:32.467286 A > B: . 1:1(0) ack 45057 win 12288
[通常の接続の起動とデータ送信Bから明確にするために省略両方向における16344のMSSを含むA.オプションに関する。 ] 16：07：32.327616のA> B：Sは65360807：07：32.327304 B> A：S 65488807：07：65488807（0）ACK 65360808 16 57344を獲得65360807（0）8192 16が勝つ32.327425 A> B：。 1：1（0）ACK 1が勝つ57344 16：07：32.345732 B> A：P 1：2049（2048）ACK 1勝つ57344 16：07：32.347013 B> A：P 2049：16385（14336）ACK 1勝つ57344 16：07：32.347550 B> A：Pの16385：30721（14336）ACK 1勝つ57344 16：07：32.348683 B> A：Pの30721：07：32.467286 A> B 45057（14336）ACK 1 16 57344を獲得：。 1：1（0）45057 12288 ACKを獲得
16:07:32.467854 B > A: P 45057:57345(12288) ack 1 win 57344
16：07：32.467854 B> A：Pの45057：57345（12288）ACK 1勝つ57344
[ B fills up A's offered window ] 16:07:32.667276 A > B: . 1:1(0) ack 57345 win 0
[BがAの提供ウィンドウをいっぱいに] 16：07：32.667276 A> B：。 1：1（0）57345 ACK 0に勝ちます
[ B probes A's window with a single byte ] 16:07:37.467438 B > A: . 57345:57346(1) ack 1 win 57344
[シングルバイトとBプローブAのウィンドウ] 16：07：37.467438 B> A：。 57345：57346（1）ACK 1は、57344を獲得
[ A resynchronizes without accepting the byte ] 16:07:37.467678 A > B: . 1:1(0) ack 57345 win 0
07：16 [Aは、バイトを受け入れずに再同期] 37.467678 A> B：。 1：1（0）57345 ACK 0に勝ちます
[ B probes A's window again ] 16:07:45.467438 B > A: . 57345:57346(1) ack 1 win 57344
[BプローブAのウィンドウを再び] 16：07：45.467438 B> A：。 57345：57346（1）ACK 1は、57344を獲得
[ A resynchronizes and accepts the byte (per the ack field) ] 16:07:45.667250 A > B: . 1:1(0) ack 57346 win 0
[Aは、再同期と（ACKフィールドごと）バイトを受け入れ] 16：07：45.667250 A> B：。 1：1（0）57346 ACK 0に勝ちます
[ The application on A has started generating data. The first packet A sends is small due to a memory allocation bug. ] 16:07:51.358459 A > B: P 1:2049(2048) ack 57346 win 0
[A上のアプリケーションは、データの生成を開始しました。 Aが送信する最初のパケットが原因メモリ割り当てのバグに小さいです。 ] 16：07：51.358459 A> B：P 1：2049（2048）57346 ACKが0に勝ちます
[ B acks A's first packet ] 16:07:51.467239 B > A: . 57346:57346(0) ack 2049 win 57344
【Aの最初のパケットのACK B] 16：07：51.467239 B> A：。 57346：57346（0）2049 ACK 57344を獲得
[ This looks as though A accepted B's ACK and is sending another packet in response to it. In fact, A is trying to resynchronize with B, and happens to have data to send and can send it because the first small packet didn't use up cwnd. ] 16:07:51.467698 A > B: . 2049:14337(12288) ack 57346 win 0
AはBのACKを受け入れ、それに応じて他のパケットを送信しているかのように[これが見えます。実際には、AはBと再同期しようとすると、送信するデータを持っているために起こり、最初の小さなパケットはcwndのを使用していなかったので、それを送ることができています。 ] 16：07：51.467698 A> B：。 2049：14337（12288）ACK 57346は0に勝ちます
[ B acks all of the data that A has sent ] 16:07:51.667283 B > A: . 57346:57346(0) ack 14337 win 57344
【Aが送信したデータの全てのACK B] 16：07：51.667283 B> A：。 57346：57346（0）14337 57344 ACKを獲得
[ A tries to resynchronize. Notice that by the packets seen on the network, A and B *are* in fact synchronized; A only thinks that they aren't. ] 16:07:51.667477 A > B: . 14337:14337(0) ack 57346 win 0
[Aは、再同期しようとします。ネットワーク上で見られるパケットによって、AおよびB *が同期実際に*されていることに注意してください。彼らだけではないと思います。 ] 16：07：51.667477 A> B：。 14337：14337（0）57346 ACK 0に勝ちます
[ A's retransmit timer fires, and B acks all of the data. A once again tries to resynchronize. ] 16:07:52.467682 A > B: . 1:14337(14336) ack 57346 win 0 16:07:52.468166 B > A: . 57346:57346(0) ack 14337 win 57344 16:07:52.468248 A > B: . 14337:14337(0) ack 57346 win 0
[Aの再送信タイマーが起動し、データのすべてのACK B。もう一度再同期しようとします。 ] 16：07：52.467682 A> B：。 1：07：57346 ACK 14337が（14336）0 16を獲得52.468166 B> A：。 57346：57346（0）14337 ACK 57344 16勝利：07：52.468248 A> Bを：。 14337：14337（0）57346 ACK 0に勝ちます
[ A's retransmit timer fires again, and B acks all of the data. A once again tries to resynchronize. ] 16:07:55.467684 A > B: . 1:14337(14336) ack 57346 win 0
[Aの再送信タイマー再び火災、およびすべてのデータのACK B。もう一度再同期しようとします。 ] 16：07：55.467684 A> B：。 1：14337（14336）57346は0に勝つACK
16:07:55.468172 B > A: . 57346:57346(0) ack 14337 win 57344 16:07:55.468254 A > B: . 14337:14337(0) ack 57346 win 0
16：07：55.468172 B> A：。 57346：57346（0）14337 ACK 57344 16勝利：07：55.468254 A> Bを：。 14337：14337（0）57346 ACK 0に勝ちます
Trace file demonstrating correct behavior Made between the same two hosts after applying the bug fix mentioned below (and using the same modified tcpdump).
下記のバグ修正を適用する（と同じ修正tcpdumpを使用）した後、同じ2つのホスト間で行わ正しい動作を実演するトレースファイル。
[ Connection starts up with data transmission from B to A. Note that due to a separate bug (the fact that A and B are communicating over a loopback driver), B erroneously skips slow start. ] 17:38:09.510854 A > B: S 3110066585:3110066585(0) win 16384 17:38:09.510926 B > A: S 3110174850:3110174850(0) ack 3110066586 win 57344 17:38:09.510953 A > B: . 1:1(0) ack 1 win 57344 17:38:09.512956 B > A: P 1:2049(2048) ack 1 win 57344 17:38:09.513222 B > A: P 2049:16385(14336) ack 1 win 57344 17:38:09.513428 B > A: P 16385:30721(14336) ack 1 win 57344 17:38:09.513638 B > A: P 30721:45057(14336) ack 1 win 57344 17:38:09.519531 A > B: . 1:1(0) ack 45057 win 12288 17:38:09.519638 B > A: P 45057:57345(12288) ack 1 win 57344
【接続により別のバグ（A及びBは、ループバック・ドライバを介して通信されるという事実）に、Bが誤ってスロースタートをスキップすることA.注にBからのデータ送信で起動します。 ] 17：38：09.510854のA> B：Sは3110066585：38：09.510926 B> A：S 3110174850：38：3110174850（0）ACK 3110066586 17 57344を獲得3110066585（0）16384 17が勝つ09.510953 A> B：。 1：1（0）ACK 1が勝つ57344 17：38：09.512956 B> A：P 1：2049（2048）ACK 1勝つ57344 17：38：09.513222 B> A：P 2049：16385（14336）ACK 1勝つ57344 17：38：09.513428 B> A：Pの16385：30721（14336）ACK 1勝つ57344 17：38：09.513638 B> A：Pの30721：38：09.519531 A> B 45057（14336）ACK 1 17 57344を獲得：。 1：1（0）45057 ACK 12288 17勝利：38：09.519638 B> A：Pの45057：57345（12288）ACK 1が57344に勝ちます
[ B fills up A's offered window ] 17:38:09.719526 A > B: . 1:1(0) ack 57345 win 0
[BがAの提供ウィンドウいっぱい] 17：38：09.719526 A> B：。 1：1（0）57345 ACK 0に勝ちます
[ B probes A's window with a single byte. A resynchronizes without accepting the byte ] 17:38:14.499661 B > A: . 57345:57346(1) ack 1 win 57344 17:38:14.499724 A > B: . 1:1(0) ack 57345 win 0
[BプローブシングルバイトとAのウィンドウ。 38：] 17バイトを受け付けずに再同期14.499661 B> A：。 57345：57346（1）ACK 1 57344 17勝利：38：14.499724 A> Bを：。 1：1（0）57345 ACK 0に勝ちます
[ B probes A's window again. A resynchronizes and accepts the byte, as indicated by the ack field ] 17:38:19.499764 B > A: . 57345:57346(1) ack 1 win 57344 17:38:19.519731 A > B: . 1:1(0) ack 57346 win 0
再びAのウィンドウ[Bプローブ。再同期とACKフィールドによって示されるように、バイトを受け入れ] 17：38：19.499764 B> A：。 57345：57346（1）ACK 1 57344 17勝利：38：19.519731 A> Bを：。 1：1（0）57346 ACK 0に勝ちます
[ B probes A's window with a single byte. A resynchronizes without accepting the byte ] 17:38:24.499865 B > A: . 57346:57347(1) ack 1 win 57344 17:38:24.499934 A > B: . 1:1(0) ack 57346 win 0
[BプローブシングルバイトとAのウィンドウ。 38：] 17バイトを受け付けずに再同期24.499865 B> A：。 57346：57347（1）ACK 1 57344 17勝利：38：24.499934 A> Bを：。 1：1（0）57346 ACK 0に勝ちます
[ The application on A has started generating data. B acks A's data and A accepts the ACKs and the data transfer continues ] 17:38:28.530265 A > B: P 1:2049(2048) ack 57346 win 0 17:38:28.719914 B > A: . 57346:57346(0) ack 2049 win 57344
[A上のアプリケーションは、データの生成を開始しました。 AのデータのACK B及びAはACKを受け取り、データ転送] 17続け：38：28.530265 A> B：P 1：38：57346 ACK 2049（2048）0 17を獲得28.719914 B> A：。 57346：57346（0）2049 ACK 57344を獲得
17:38:28.720023 A > B: . 2049:16385(14336) ack 57346 win 0 17:38:28.720089 A > B: . 16385:30721(14336) ack 57346 win 0
17：38：28.720023 A> B：。 2049：38：16385（14336）57346 ACKは0 17を獲得28.720089 A> Bを：。 16385：30721（14336）57346 ACK 0に勝ちます
17:38:28.720370 B > A: . 57346:57346(0) ack 30721 win 57344
17：38：28.720370 B> A：。 57346：57346（0）30721 57344 ACKを獲得
17:38:28.720462 A > B: . 30721:45057(14336) ack 57346 win 0 17:38:28.720526 A > B: P 45057:59393(14336) ack 57346 win 0 17:38:28.720824 A > B: P 59393:73729(14336) ack 57346 win 0 17:38:28.721124 B > A: . 57346:57346(0) ack 73729 win 47104
17：38：28.720462 A> B：。 30721：45057（14336）57346 0 17勝つACK：38：28.720526 A> B：Pの45057：38：59393（14336）57346 ACKは0 17を獲得28.720824 A> B：Pの59393：73729（14336）57346 ACK 0に勝ちます17：38：28.721124 B> A：。 57346：57346（0）73729 47104 ACKを獲得
17:38:28.721198 A > B: P 73729:88065(14336) ack 57346 win 0 17:38:28.721379 A > B: P 88065:102401(14336) ack 57346 win 0
17：38：28.721198 A> B：Pの73729：38：88065（14336）57346 ACKは0 17を獲得28.721379 A> B：Pの88065：102401（14336）を57346に0を獲得確認応答します
17:38:28.721557 A > B: P 102401:116737(14336) ack 57346 win 0 17:38:28.721863 B > A: . 57346:57346(0) ack 116737 win 36864
17：38：28.721557 A> B：P 102401：38：57346 ACK 116737（14336）が0 17を獲得28.721863 B> A：。 57346：57346（0）116737 ACK 36864を獲得
References None known.
参考認知済みのものは無し。
How to detect Initiate a connection from a client to a server. Have the server continuously send data until its buffers have been full for long enough to exhaust the window. Next, have the client read 1 byte and then delay for long enough that the server TCP sends a window probe. Now have the client start sending data. At this point, if it ignores the server's ACKs, then the client's TCP suffers from the problem.
クライアントからサーバーへの接続を開始し検出する方法。そのバッファは、ウィンドウを排出するのに十分な長さを完全にされるまで、サーバーが継続的にデータを送っています。次に、クライアントは、サーバのTCPウィンドウプローブを送信する十分な長さのために遅らせた後、1つのバイトを読んでいます。今、クライアントがデータの送信を開始しています。それは、サーバのACKを無視する場合は、この時点では、クライアントのTCPが問題に苦しんでいます。
How to fix In one implementation known to exhibit the problem (derived from 4.3-Reno), the problem was introduced when the macro MAX() was replaced by the function call max() for computing the amount of space in the receive window:
（4.3-リノ由来）の問題を示すことが知られている一の実装では修正するためにどのようにマクロMAX（）が受信ウィンドウ内のスペースの量を計算するための関数呼び出しMAX（）によって置き換えられたとき、問題が導入されました：
tp->rcv_wnd = max(win, (int)(tp->rcv_adv - tp->rcv_nxt));
TP-> rcv_wnd = MAX（勝利、（int型）（TP-> rcv_adv - TP-> rcv_nxt））;
When data has been received into a window beyond what has been advertised to the other side, rcv_nxt > rcv_adv, making this negative. It's clear from the (int) cast that this is intended, but the unsigned max() function sign-extends so the negative number is "larger". The fix is to change max() to imax():
データは、この負のを作り、他の側、rcv_nxt> rcv_advにアドバタイズされたもの以外のウィンドウに受信した場合。これは、（int型）から明らかに、これは意図されていることをキャストだが、符号なしのMAX（）関数のように、負の数は、「大きな」である符号拡張します。修）（IMAX MAXを（）に変更することです：
tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt));
TP-> rcv_wnd = IMAX（勝利、（int型）（TP-> rcv_adv - TP-> rcv_nxt））;
4.3-Tahoe and before did not have this bug, since it used the macro MAX() for this calculation.
4.3-タホ、それはこの計算のためのマクロMAX（）を使用するので、このバグを持っていなかったの前に。
Name of Problem Stretch ACK violation
問題ストレッチACK違反の名前
Classification Congestion Control/Performance
分類輻輳制御/パフォーマンス
Description To improve efficiency (both computer and network) a data receiver may refrain from sending an ACK for each incoming segment, according to [RFC1122]. However, an ACK should not be delayed an inordinate amount of time. Specifically, ACKs SHOULD be sent for every second full-sized segment that arrives. If a second full-sized segment does not arrive within a given timeout (of no more than 0.5 seconds), an ACK should be transmitted, according to [RFC1122]. A TCP receiver which does not generate an ACK for every second full-sized segment exhibits a "Stretch ACK Violation".
効率（コンピュータとネットワークの両方）データ受信を改善するために、説明は[RFC1122]によれば、各受信セグメントに対するACKを送信を控えることができます。しかし、ACKは途方もない時間を遅らせるべきではありません。具体的には、ACKが到着する毎秒フルサイズのセグメントのために送信されるべきです。第フルサイズセグメント（これ以上0.5秒以下の）指定されたタイムアウト時間内に到着しない場合、ACKは、[RFC1122]によれば、送信されるべきです。毎秒フルサイズのセグメントに対するACKを生成しないTCP受信機は、「ストレッチACK違反」を示します。
Significance TCP receivers exhibiting this behavior will cause TCP senders to generate burstier traffic, which can degrade performance in congested environments. In addition, generating fewer ACKs increases the amount of time needed by the slow start algorithm to open the congestion window to an appropriate point, which diminishes performance in environments with large bandwidth-delay products. Finally, generating fewer ACKs may cause needless retransmission timeouts in lossy environments, as it increases the possibility that an entire window of ACKs is lost, forcing a retransmission timeout.
この挙動を示す意義のTCP受信機は混雑した環境でのパフォーマンスが低下する可能性がバースト的トラフィックを生成するためにTCPの送信者が発生します。加えて、より少ないACKを生成することは、大きな帯域幅遅延製品と環境における性能を低下させる適切なポイントに輻輳ウィンドウを開くために、スロースタートアルゴリズムによって必要とされる時間の量を増加させます。それは再送タイムアウトを強制的に、ACKのウィンドウ全体が失われる可能性を増加させるように、最終的に、より少ないACKを生成することは、損失の多い環境で不再送タイムアウトを引き起こす可能性があります。
Implications When not in loss recovery, every ACK received by a TCP sender triggers the transmission of new data segments. The burst size is determined by the number of previously unacknowledged segments each ACK covers. Therefore, a TCP receiver ack'ing more than 2 segments at a time causes the sending TCP to generate a larger burst of traffic upon receipt of the ACK. This large burst of traffic can overwhelm an intervening gateway, leading to higher drop rates for both the connection and other connections passing through the congested gateway.
ない損失回復に、TCPの送信側が受信したすべてのACKが新しいデータセグメントの送信をトリガーする意味合い。バースト・サイズは、各ACKがカバー以前に未確認のセグメントの数によって決定されます。したがって、一度に2つの以上のセグメントをack'ing TCP受信機は、ACKを受信すると、トラフィックの大きなバーストを生成するために、送信TCPを引き起こします。トラフィックのこの大きなバースト接続と輻輳ゲートウェイを通過する他の接続の両方のためのより高い降下速度をもたらす、介在するゲートウェイを圧倒することができます。
In addition, the TCP slow start algorithm increases the congestion window by 1 segment for each ACK received. Therefore, increasing the ACK interval (thus decreasing the rate at which ACKs are transmitted) increases the amount of time it takes slow start to increase the congestion window to an appropriate operating point, and the connection consequently suffers from reduced performance. This is especially true for connections using large windows.
また、TCPスロースタートアルゴリズムは、ACKが受信された各1つのセグメントによって輻輳ウィンドウを増加させます。したがって、ACK間隔（従ってたACKが送信される速度を低下さ）を大きくすることは、適切な動作点に混雑ウィンドウを増加させるためにスロースタートに要する時間の量を増加させ、そして接続は、結果として性能低下に悩まされます。これは、大きな窓を使用して接続する場合に特に当てはまります。
Relevant RFCs RFC 1122 outlines delayed ACKs as a recommended mechanism.
関連のRFCのRFC 1122は、推奨メカニズムとして遅延ACKを概説します。
Trace file demonstrating it Trace file taken using tcpdump at host B, the data receiver (and ACK originator). The advertised window (which never changed) and timestamp options have been omitted for clarity, except for the first packet sent by A:
それは、ホストB、データ受信（及びACK元）でのtcpdumpを使用して撮影したファイルを追跡実証ファイルをトレース。アドバタイズされた（変更されません）ウィンドウとタイムスタンプオプションはAによって送られた最初のパケットを除き、明確にするために省略されています：
12:09:24.820187 A.1174 > B.3999: . 2049:3497(1448) ack 1 win 33580 <nop,nop,timestamp 2249877 2249914> [tos 0x8] 12:09:24.824147 A.1174 > B.3999: . 3497:4945(1448) ack 1 12:09:24.832034 A.1174 > B.3999: . 4945:6393(1448) ack 1 12:09:24.832222 B.3999 > A.1174: . ack 6393 12:09:24.934837 A.1174 > B.3999: . 6393:7841(1448) ack 1 12:09:24.942721 A.1174 > B.3999: . 7841:9289(1448) ack 1 12:09:24.950605 A.1174 > B.3999: . 9289:10737(1448) ack 1 12:09:24.950797 B.3999 > A.1174: . ack 10737 12:09:24.958488 A.1174 > B.3999: . 10737:12185(1448) ack 1 12:09:25.052330 A.1174 > B.3999: . 12185:13633(1448) ack 1 12:09:25.060216 A.1174 > B.3999: . 13633:15081(1448) ack 1 12:09:25.060405 B.3999 > A.1174: . ack 15081
12：09：24.820187 A.1174> B.3999：。 2049：3497（1448）ACK 1勝つ33580 <NOP、NOP、タイムスタンプ2249877 2249914> [TOS、0x8という] 12：09：24.824147 A.1174> B.3999：。 3497：4945（1448）ACK 1 12：09：24.832034 A.1174> B.3999：。 4945：6393（1448）ACK 1 12：09：24.832222 B.3999> A.1174：。 09：24.934837 A.1174> B.3999 6393 12 ACKの場合：。 6393：7841（1448）ACK 1 12：09：24.942721 A.1174> B.3999：。 7841：9289（1448）ACK 1 12：09：24.950605 A.1174> B.3999：。 9289：10737（1448）ACK 1 12：09：24.950797 B.3999> A.1174：。 09：24.958488 A.1174> B.3999 10737 12がACKの場合：。 10737：12185（1448）ACK 1 12：09：25.052330 A.1174> B.3999：。 12185：13633（1448）ACK 1 12：09：25.060216 A.1174> B.3999：。 13633：15081（1448）ACK 1 12：09：25.060405 B.3999> A.1174：。 15081の確認応答
This portion of the trace clearly shows that the receiver (host B) sends an ACK for every third full sized packet received. Further investigation of this implementation found that the cause of the increased ACK interval was the TCP options being used. The implementation sent an ACK after it was holding 2*MSS worth of unacknowledged data. In the above case, the MSS is 1460 bytes so the receiver transmits an ACK after it is holding at least 2920 bytes of unacknowledged data. However, the length of the TCP options being used [RFC1323] took 12 bytes away from the data portion of each packet. This produced packets containing 1448 bytes of data. But the additional bytes used by the options in the header were not taken into account when determining when to trigger an ACK. Therefore, it took 3 data segments before the data receiver was holding enough unacknowledged data (>= 2*MSS, or 2920 bytes in the above example) to transmit an ACK.
トレースのこの部分は、明らかに、受信機（ホストB）を受信したすべての第三のフルサイズのパケットに対してACKを送信することを示しています。この実装の詳しい調査の結果、増加したACK間隔の原因はTCPオプションが使用されていることがわかりました。それは未確認データの2 * MSSの価値を保持した後に実装がACKを送りました。それは未確認データの少なくとも2920のバイトを保持した後、受信機がACKを送信するので、上記の場合に、MSSは1460バイトです。しかしながら、[RFC1323]を使用しているTCPオプションの長さは12バイト離れた各パケットのデータ部分から取りました。これはデータの1448バイトを含むパケットを生成しました。 ACKをトリガするときを決定する場合には、ヘッダにオプションで使用される追加のバイトが考慮されていませんでした。データ受信機がACKを送信するのに十分な未確認データを保持（> = 2 * MSS、または上記の例で2920バイト）前したがって、3つのデータセグメントを取りました。
Trace file demonstrating correct behavior Trace file taken using tcpdump at host B, the data receiver (and ACK originator), again with window and timestamp information omitted except for the first packet:
最初のパケットを除いて省略ウィンドウとタイムスタンプ情報を再度、ホストBでのtcpdumpを使用して撮影し、正しい行動トレースファイル、データ受信（及びACK発信）を実証するファイルをトレース。
12:06:53.627320 A.1172 > B.3999: . 1449:2897(1448) ack 1 win 33580 <nop,nop,timestamp 2249575 2249612> [tos 0x8] 12:06:53.634773 A.1172 > B.3999: . 2897:4345(1448) ack 1 12:06:53.634961 B.3999 > A.1172: . ack 4345 12:06:53.737326 A.1172 > B.3999: . 4345:5793(1448) ack 1 12:06:53.744401 A.1172 > B.3999: . 5793:7241(1448) ack 1 12:06:53.744592 B.3999 > A.1172: . ack 7241
12：06：53.627320 A.1172> B.3999：。 1449：2897（1448）ACK 1勝つ33580 <NOP、NOP、タイムスタンプ2249575 2249612> [TOS、0x8という] 12：06：53.634773 A.1172> B.3999：。 2897：4345（1448）ACK 1 12：06：53.634961 B.3999> A.1172：。 06：53.737326 A.1172> B.3999 4345 12 ACKの場合：。 4345：5793（1448）ACK 1 12：06：53.744401 A.1172> B.3999：。 5793：7241（1448）ACK 1 12：06：53.744592 B.3999> A.1172：。 ACK 7241
12:06:53.752287 A.1172 > B.3999: . 7241:8689(1448) ack 1 12:06:53.847332 A.1172 > B.3999: . 8689:10137(1448) ack 1 12:06:53.847525 B.3999 > A.1172: . ack 10137
12：06：53.752287 A.1172> B.3999 :. 7241：8689（1448）OH 1時12分A.M：06：53.847332 A.1172> B.3999 :. 8689：10137（1448）OH 1：12 A.M：06：53.847525 B.3999> A.1172 :.オハイオ州10137
This trace shows the TCP receiver (host B) ack'ing every second full-sized packet, according to [RFC1122]. This is the same implementation shown above, with slight modifications that allow the receiver to take the length of the options into account when deciding when to transmit an ACK.
このトレースは、[RFC1122]によれば、毎秒フルサイズのパケットack'ing TCPレシーバ（ホストB）を示しています。これは、ACKを送信するときを決定する際に、受信機は、アカウントにオプションの長さを取ることができるようにわずかな修正を加えて、上に示した同じ実装です。
References This problem is documented in [Allman97] and [Paxson97].
参考文献は、この問題は、[Paxson97] [Allman97]で文書化されています。
How to detect Stretch ACK violations show up immediately in receiver-side packet traces of bulk transfers, as shown above. However, packet traces made on the sender side of the TCP connection may lead to ambiguities when diagnosing this problem due to the possibility of lost ACKs.
ストレッチACK違反を検出する方法上記のように、バルク転送の受信側パケットトレースに直ちに現れます。この問題を診断するときしかし、TCPコネクションの送信側に作られたパケットトレースが失われたACKの可能性を曖昧につながる可能性があります。
Name of Problem Retransmission sends multiple packets
問題再送信の名前は、複数のパケットを送信します
Classification Congestion control
分類輻輳制御
Description When a TCP retransmits a segment due to a timeout expiration or beginning a fast retransmission sequence, it should only transmit a single segment. A TCP that transmits more than one segment exhibits "Retransmission Sends Multiple Packets".
説明TCPがタイムアウト満了にセグメントを再送したり、高速再送シーケンスを開始すると、それだけで単一のセグメントを送信する必要があります。 「再送が複数のパケットを送信し、」複数のセグメントの展示を送信するTCP。
Instances of this problem have been known to occur due to miscomputations involving the use of TCP options. TCP options increase the TCP header beyond its usual size of 20 bytes. The total size of header must be taken into account when retransmitting a packet. If a TCP sender does not account for the length of the TCP options when determining how much data to retransmit, it will send too much data to fit into a single packet. In this case, the correct retransmission will be followed by a short segment (tinygram) containing data that may not need to be retransmitted.
この問題のインスタンスが原因TCPオプションの使用を含むmiscomputationsに発生することが知られています。 TCPオプションは、20バイトのその通常のサイズを超えてTCPヘッダを高めます。パケットを再送信する場合、ヘッダの合計サイズを考慮しなければなりません。再送信するデータの量を決定する際のTCP送信側がTCPオプションの長さを考慮していない場合は、それが単一のパケットに収まるようにあまりにも多くのデータを送信します。この場合、正しい再送が再送される必要がないかもしれないデータを含む短いセグメント（tinygram）が続きます。
A specific case is a TCP using the RFC 1323 timestamp option, which adds 12 bytes to the standard 20-byte TCP header. On retransmission of a packet, the 12 byte option is incorrectly interpreted as part of the data portion of the segment. A standard TCP header and a new 12-byte option is added to the data, which yields a transmission of 12 bytes more data than contained in the original segment. This overflow causes a smaller packet, with 12 data bytes, to be transmitted.
特定の場合には、標準の20バイトのTCPヘッダに12バイトを追加RFC 1323タイムスタンプオプションを使用して、TCPです。パケットの再送に、12バイトのオプションが誤ってセグメントのデータ部分の一部として解釈されます。標準のTCPヘッダと新しい12バイトのオプションは、元のセグメントに含まれるよりも12バイトの送信より多くのデータが得られるデータに付加されます。このオーバーフローは、送信される、12のデータバイトと、小さいパケットを引き起こします。
Significance This problem is somewhat serious for congested environments because the TCP implementation injects more packets into the network than is appropriate. However, since a tinygram is only sent in response to a fast retransmit or a timeout, it does not effect the sustained sending rate.
TCPの実装が適切であるよりも、ネットワークに多くのパケットを注入するので意義は、この問題は、混雑した環境のためにやや深刻です。 tinygramのみ高速再送またはタイムアウトに応答して送信されているのでしかし、それは持続的な送信レートには影響しません。
Implications A TCP exhibiting this behavior is stressing the network with more traffic than appropriate, and stressing routers by increasing the number of packets they must process. The redundant tinygram will also elicit a duplicate ACK from the receiver, resulting in yet another unnecessary transmission.
意味合いこの挙動を示すTCPは、適切なより多くのトラフィックとネットワークを強調し、彼らが処理しなければならないパケットの数を増やすことで、ルータを強調しています。冗長tinygramはまた、さらに別の不要な伝送をもたらす、受信機からの重複ACKを誘発します。
Relevant RFCs RFC 1122 requires use of slow start after loss; RFC 2001 explicates slow start; RFC 1323 describes the timestamp option that has been observed to lead to some implementations exhibiting this problem.
関連のRFCのRFC 1122は損失後のスロースタートを使用する必要があります。 RFC 2001は、スロースタートをexplicates。 RFC 1323には、この問題を示すいくつかの実装につながることが観察されているタイムスタンプオプションを説明します。
Trace file demonstrating it Made using tcpdump recording at a machine on the same subnet as Host A. Host A is the sender and Host B is the receiver. The advertised window and timestamp options have been omitted for clarity, except for the first segment sent by host A. In addition, portions of the trace file not pertaining to the packet in question have been removed (missing packets are denoted by "[...]" in the trace).
それはホストAホストAと同じサブネット上のマシンでtcpdumpの記録を使用して作られた実演するトレースファイルが送信者であるとホストBは、受信機です。広告ウィンドウとタイムスタンプオプションはまた、ホストAによって送信された最初のセグメントを除き、明確にするために省略されている、問題のパケットに関係ないトレースファイルの一部が欠落しているパケットは[」によって示されている（削除されています。.. 。]」トレースで）。
11:55:22.701668 A > B: . 7361:7821(460) ack 1 win 49324 <nop,nop,timestamp 3485348 3485113> 11:55:22.702109 A > B: . 7821:8281(460) ack 1 [...]
11：55：22.701668 A> B：。 7361：55：22.702109 A> B 7821（460）、ACK 1は、49324 <NOP、NOP、タイムスタンプ3485348 3485113> 11勝ちます：。 7821：8281（460）ACK 1 [...]
11:55:23.112405 B > A: . ack 7821 11:55:23.113069 A > B: . 12421:12881(460) ack 1 11:55:23.113511 A > B: . 12881:13341(460) ack 1 11:55:23.333077 B > A: . ack 7821 11:55:23.336860 B > A: . ack 7821 11:55:23.340638 B > A: . ack 7821 11:55:23.341290 A > B: . 7821:8281(460) ack 1 11:55:23.341317 A > B: . 8281:8293(12) ack 1
11：55：23.112405 B> A.オハイオ州7821 11：55：23.113069 A> B. 12421：12881（460）ACK 1 11：55：23.113511 A> B. 12881：13341（460）ACK 1 11：55：23.333077 B> A. 55：：7821 11ああ23.336860 B> A. 55：：7821 11ああ23.340638 B> A.オハイオ州7821 11：55：23.341290 A> B. 7821：8281（460）ACK 1 11：55：23.341317 A> B. 8281：8293（12）ACK 1
11:55:23.498242 B > A: . ack 7821 11:55:23.506850 B > A: . ack 7821 11:55:23.510630 B > A: . ack 7821
11：55：23.498242 B> A. 55：：7821 11ああ23.506850 B> A. 55：：7821 11ああ23.510630 B> A. 7821オハイオ州
[...]
「。。。」
11:55:23.746649 B > A: . ack 10581
11：55：23.746649 B> A.オハイオ州10581
The second line of the above trace shows the original transmission of a segment which is later dropped. After 3 duplicate ACKs, line 9 of the trace shows the dropped packet (7821:8281), with a 460- byte payload, being retransmitted. Immediately following this retransmission, a packet with a 12-byte payload is unnecessarily sent.
上記トレースの2行目は、後で廃棄されたセグメントの元の送信を示しています。 3個の重複ACKの後、トレースの線9がドロップされたパケット（7821：8281）を示し、460-バイトのペイロードと、再送信されます。すぐにこの再送信以下、12バイトのペイロードを持つパケットが不必要に送信されます。
Trace file demonstrating correct behavior The trace file would be identical to the one above, with a single line:
正しい動作を実演するトレースファイルは、トレース・ファイルには、1つの行で、上記のものと同じになります：
11:55:23.341317 A > B: . 8281:8293(12) ack 1
11：55：23.341317 A> B. 8281：8293（12）ACK 1
omitted.
省略。
References [Brakmo95]
参考文献[Brakmo95]
How to detect This problem can be detected by examining a packet trace of the TCP connections of a machine using TCP options, during which a packet is retransmitted.
どのようにこの問題を検出するために、パケットを再送されている間のTCPオプションを使用しているマシンのTCPコネクションのパケットトレースを調べることにより検出することができます。
Name of Problem Failure to send FIN notification promptly
速やかFIN通知を送信するために問題の失敗の名前
Classification Performance
分類性能
Description When an application closes a connection, the corresponding TCP should send the FIN notification promptly to its peer (unless prevented by the congestion window). If a TCP implementation delays in sending the FIN notification, for example due to waiting until unacknowledged data has been acknowledged, then it is said to exhibit "Failure to send FIN notification promptly".
（輻輳ウィンドウによって防止されない限り）は、アプリケーションが接続を閉じるの説明は、対応するTCPは、そのピアに速やかFIN通知を送信すべきです。未確認データが確認されるまで待つこと例えば、FIN通知を送信におけるTCPの実装の遅延した場合、「速やかにFIN通知を送信するために失敗」を示すと言われています。
Also, while not strictly required, FIN segments should include the PSH flag to ensure expedited delivery of any pending data at the receiver.
厳密には必要ではないながらも、FINセグメントは、受信機における保留中のデータの迅速な送達を確実にするためにPSHフラグを含むべきです。
Significance The greatest impact occurs for short-lived connections, since for these the additional time required to close the connection introduces the greatest relative delay.
これらの接続を閉じるために必要な追加時間は、最大相対遅延を導入するので、有意最大の影響は、短命接続のために生じます。
The additional time can be significant in the common case of the sender waiting for an ACK that is delayed by the receiver.
追加の時間は、受信機によって遅延されたACKを待っている送信者の一般的なケースでは重要になります。
Implications Can diminish total throughput as seen at the application layer, because connection termination takes longer to complete.
接続終了が完了するまでに時間がかかりますので、アプリケーション層で見られるような影響が全体のスループットを低下させることができます。
Relevant RFCs RFC 793 indicates that a receiver should treat an incoming FIN flag as implying the push function.
関連のRFCのRFC 793は、受信機がプッシュ機能を意味するように、着信FINフラグを治療する必要があることを示しています。
Trace file demonstrating it Made using tcpdump (no losses reported by the packet filter).
トレース・ファイルは、それが（パケットフィルタによって報告された無損失）のtcpdumpを使用していないメイドを実証しています。
10:04:38.68 A > B: S 1031850376:1031850376(0) win 4096 <mss 1460,wscale 0,eol> (DF) 10:04:38.71 B > A: S 596916473:596916473(0) ack 1031850377 win 8760 <mss 1460> (DF) 10:04:38.73 A > B: . ack 1 win 4096 (DF) 10:04:41.98 A > B: P 1:4(3) ack 1 win 4096 (DF) 10:04:42.15 B > A: . ack 4 win 8757 (DF) 10:04:42.23 A > B: P 4:7(3) ack 1 win 4096 (DF) 10:04:42.25 B > A: P 1:11(10) ack 7 win 8754 (DF) 10:04:42.32 A > B: . ack 11 win 4096 (DF) 10:04:42.33 B > A: P 11:51(40) ack 7 win 8754 (DF) 10:04:42.51 A > B: . ack 51 win 4096 (DF) 10:04:42.53 B > A: F 51:51(0) ack 7 win 8754 (DF) 10:04:42.56 A > B: FP 7:7(0) ack 52 win 4096 (DF) 10:04:42.58 B > A: . ack 8 win 8754 (DF)
10：04：38.68 A> B：S 1031850376：04：38.71 B> A：Sの596916473：596916473（0）ACK 1031850377は8760勝つ1031850376（0）4096 <MSS 1460 wscale 0、EOL>（DF）10に勝ちます<MSS 1460>（DF）10：04：38.73 A> B：。 04：41.98 A> B：P 1：4（3）ACK 1勝4096（DF）10：04：42.15 B> A：ACK 1（DF）10を4096に勝ちます。 04：ACK 4 8757（DF）10を獲得42.23 A> B：P 4：7（3）ACK 1が4096（DF）を勝つ10：04：42.25 B> A：P 1：11（10）ACK 7勝利8754 （DF）10：04：42.32 A> B：。 04：42.33 B> A：P 11時51分（40）ACK 7勝利8754（DF）10：04：42.51 A> B：11 4096（DF）10を獲得確認応答。 04：42.53 B> A：51 4096（DF）10を獲得確認応答F 51:51（0）ACK 7勝つ8754（DF）10：04：42.56 A> B：FP 7：7（0）52が勝つACK 4096 （DF）10：04：42.58 B> A：。 8は8754を獲得ACK（DF）
Machine B in the trace above does not send out a FIN notification promptly if there is any data outstanding. It instead waits for all unacknowledged data to be acknowledged before sending the FIN segment. The connection was closed at 10:04.42.33 after requesting 40 bytes to be sent. However, the FIN notification isn't sent until 10:04.42.51, after the (delayed) acknowledgement of the 40 bytes of data.
抜群のいずれかのデータがある場合は、上記のトレースでのコンピュータBは、速やかにFIN通知を送信しません。これは、代わりにFINセグメントを送信する前に承認されるために、すべての未確認のデータを待ちます。接続は10で閉じられました：04.42.33 40のバイトを要求した後送信されます。データの40バイト（遅延）確認応答の後、04.42.51：ただし、FIN通知が10まで送信されません。
Trace file demonstrating correct behavior Made using tcpdump (no losses reported by the packet filter).
正しい動作を実演するトレースファイルは、（パケットフィルタによって報告された無損失）のtcpdumpを使用していないメイド。
10:27:53.85 C > D: S 419744533:419744533(0) win 4096 <mss 1460,wscale 0,eol> (DF) 10:27:53.92 D > C: S 10082297:10082297(0) ack 419744534 win 8760 <mss 1460> (DF) 10:27:53.95 C > D: . ack 1 win 4096 (DF) 10:27:54.42 C > D: P 1:4(3) ack 1 win 4096 (DF) 10:27:54.62 D > C: . ack 4 win 8757 (DF) 10:27:54.76 C > D: P 4:7(3) ack 1 win 4096 (DF) 10:27:54.89 D > C: P 1:11(10) ack 7 win 8754 (DF) 10:27:54.90 D > C: FP 11:51(40) ack7 win 8754 (DF) 10:27:54.92 C > D: . ack 52 win 4096 (DF) 10:27:55.01 C > D: FP 7:7(0) ack 52 win 4096 (DF) 10:27:55.09 D > C: . ack 8 win 8754 (DF)
10：27：53.85 C> D：Sの419744533：27：53.92 D> C：S 10082297：10082297（0）ACK 419744534 8760を獲得419744533（0）4096 <MSS 1460 wscale 0、EOL>（DF）10に勝ちます<MSS 1460>（DF）10：27：53.95 C> D：。 ACK 1 4096に勝つ（DF）10：27：54.42 C> D：P 1：27：4（3）ACK 1、4096（DF）10を獲得54.62 D> C：。 27：ACK 4 8757（DF）10を獲得54.76 C> D：P 4：7（3）ACK 1が4096（DF）を勝つ10：27：54.89 D> C：P 1：11（10）ACK 7勝利8754 （DF）10：27：54.90 D> C：FP 11時51分（40）ack7 8754（DF）10勝利：27：54.92 C> D：。確認応答52は4096（DF）10勝利：27：55.01 C> D：FPは7：27：7（0）52 4096 ACK（DF）10を獲得55.09 D> C：。 8は8754を獲得ACK（DF）
Here, Machine D sends a FIN with 40 bytes of data even before the original 10 octets have been acknowledged. This is correct behavior as it provides for the highest performance.
ここでは、マシンDは、元の10個のオクテットが確認されている前であっても、データの40バイトのFINを送信します。それが最高のパフォーマンスを提供しますので、これは正しい動作です。
References This problem is documented in [Dawson97].
参考文献は、この問題は、[Dawson97]に記述されています。
How to detect For implementations manifesting this problem, it shows up on a packet trace.
この問題を顕在実装を検出するためにどのように、それはパケットトレースに表示されます。
Name of Problem Failure to send a RST after Half Duplex Close
半二重クローズ後RSTを送信するために問題の失敗の名前
Classification Resource management
分類リソース管理
Description RFC 1122 4.2.2.13 states that a TCP SHOULD send a RST if data is received after "half duplex close", i.e. if it cannot be delivered to the application. A TCP that fails to do so is said to exhibit "Failure to send a RST after Half Duplex Close".
説明RFC 1122のデータは、「近い半二重」の後に受信された場合、TCPはRSTを送るべき4.2.2.13の状態、すなわち、それはアプリケーションに配信することができない場合。そうするために失敗したTCPは、「半二重クローズ後RSTを送信するために失敗」を示すと言われています。
Significance Potentially serious for TCP endpoints that manage large numbers of connections, due to exhaustion of memory and/or process slots available for managing connection state.
メモリの枯渇および/または接続状態を管理するために利用可能なプロセス・スロットのために多数の接続を管理するTCPエンドポイントのための潜在的に重大な意義。
Implications Failure to send the RST can lead to permanently hung TCP connections. This problem has been demonstrated when HTTP clients abort connections, common when users move on to a new page before the current page has finished downloading. The HTTP client closes by transmitting a FIN while the server is transmitting images, text, etc. The server TCP receives the FIN, but its application does not close the connection until all data has been queued for transmission. Since the server will not transmit a FIN until all the preceding data has been transmitted, deadlock results if the client TCP does not consume the pending data or tear down the connection: the window decreases to zero, since the client cannot pass the data to the application, and the server sends probe segments. The client acknowledges the probe segments with a zero window. As mandated in RFC1122 4.2.2.17, the probe segments are transmitted forever. Server connection state remains in CLOSE_WAIT, and eventually server processes are exhausted.
RSTを送信するために、障害が永続的につながる可能性の示唆は、TCP接続を切りました。現在のページのダウンロードが完了する前に、ユーザーが新しいページに移動するとき、HTTPクライアントは、共通の接続を中止すると、この問題は実証されています。 HTTPクライアントは、サーバは、画像、テキストなどのサーバTCPがFINを受信を送信している間、FINを送信することで閉じますが、すべてのデータが伝送のためにキューイングされるまで、そのアプリケーションは接続を閉じません。先行するすべてのデータが送信されるまで、サーバがFINを送信しないので、デッドロックの結果は、クライアントのTCPは、保留中のデータを消費するか、接続を切断していない場合：ウィンドウはゼロに減少、クライアントがにデータを渡すことはできませんので、アプリケーション、およびサーバーは、プローブセグメントを送信します。クライアントは、ゼロウィンドウでプローブセグメントを認めています。 RFC1122 4.2.2.17に規定されているように、プローブセグメントは永遠に送信されます。サーバーの接続状態がCLOSE_WAITのままであり、最終的にはサーバプロセスが排出されます。
Note that there are two bugs. First, probe segments should be ignored if the window can never subsequently increase. Second, a RST should be sent when data is received after half duplex close. Fixing the first bug, but not the second, results in the probe segments eventually timing out the connection, but the server remains in CLOSE_WAIT for a significant and unnecessary period.
2つのバグがあることに注意してください。ウィンドウがその後増加したことがないことができればまず、プローブセグメントは無視されるべきです。データは半二重クローズ後に受信されたときに、第2、RSTを送信する必要があります。最初のバグを修正するが、プローブセグメントにおける第二、結果は、最終的に接続をタイムアウトしないが、サーバーは、重要な不要な期間、CLOSE_WAITのままです。
Relevant RFCs RFC 1122 sections 4.2.2.13 and 4.2.2.17.
関連のRFCのRFC 1122個のセクション4.2.2.13と4.2.2.17。
Trace file demonstrating it Made using an unknown network analyzer. No drop information available.
トレース・ファイルは、それが未知のネットワークアナライザを使用して作られて実証しました。利用可能なドロップ情報がありません。
client.1391 > server.8080: S 0:1(0) ack: 0 win: 2000 <mss: 5b4> server.8080 > client.1391: SA 8c01:8c02(0) ack: 1 win: 8000 <mss:100> client.1391 > server.8080: PA client.1391 > server.8080: PA 1:1c2(1c1) ack: 8c02 win: 2000 server.8080 > client.1391: [DF] PA 8c02:8cde(dc) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A 8cde:9292(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A 9292:9846(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A 9846:9dfa(5b4) ack: 1c2 win: 8000 client.1391 > server.8080: PA server.8080 > client.1391: [DF] A 9dfa:a3ae(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A a3ae:a962(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A a962:af16(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A af16:b4ca(5b4) ack: 1c2 win: 8000 client.1391 > server.8080: PA server.8080 > client.1391: [DF] A b4ca:ba7e(5b4) ack: 1c2 win: 8000 server.8080 > client.1391: [DF] A b4ca:ba7e(5b4) ack: 1c2 win: 8000 client.1391 > server.8080: PA server.8080 > client.1391: [DF] A ba7e:bdfa(37c) ack: 1c2 win: 8000 client.1391 > server.8080: PA server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c2 win: 8000 client.1391 > server.8080: PA
client.1391> server.8080：S 0：1（0）ACK：0勝利：2000 <MSS：5B4> server.8080> client.1391：SA 8c01：8c02（0）ACK：1勝：8000 <MSS： 100> client.1391> server.8080：PA client.1391> server.8080：PA 1：1C2（1C1）ACK：8c02勝利2000 server.8080> client.1391：[DF] PA 8c02：8cde（DC） ACK：1C2勝利：8000 server.8080> client.1391：[DF] A 8cde：9292（5B4）ACK：1C2勝利：8000 server.8080> client.1391：[DF] 9292：9846（5B4）ACK： 1C2勝利：8000 server.8080> client.1391：[DF] 9846：9dfa（5B4）ACK：1C2勝利：8000 client.1391> server.8080：PA server.8080> client.1391：[DF] 9dfa ：a3ae（5B4）ACK：1C2勝利：8000 server.8080> client.1391：[DF] a3ae：a962（5B4）ACK：1C2勝利：8000 server.8080> client.1391：[DF] a962：AF16 （5B4）ACK：1C2勝利：8000 server.8080> client.1391：[DF] AF16：b4ca（5B4）ACK：1C2勝利：8000 client.1391> server.8080：PA server.8080> client.1391。 [DF] b4ca：ba7eは（5B4）ACK：1C2勝利：8000 server.8080> client.1391：[DF] b4ca：ba7e（5B4）ACK：1C2勝利：8000 client.1391> server.8080：PAはサーブr.8080> client.1391：[DF] ba7e：bdfa（37C）ACK：1C2勝利：8000 client.1391> server.8080：PA server.8080> client.1391：[DF] A bdfa：BDFB（1 ）ACK：1C2勝利：8000 client.1391> server.8080：PA
[ HTTP client aborts and enters FIN_WAIT_1 ]
[HTTPクライアントは中止され、FIN_WAIT_1に入り]
client.1391 > server.8080: FPA
client.1391> server.8080：FPA
[ server ACKs the FIN and enters CLOSE_WAIT ]
[FIN ACKをサーバに入射CLOSE_WAIT]
server.8080 > client.1391: [DF] A
server.8080> client.1391：[DF] A
[ client enters FIN_WAIT_2 ]
[クライアントがFIN_WAIT_2に入り]
server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000
server.8080> client.1391：[DF] A bdfa：BDFB（1）ACK：1C3勝利：8000
[ server continues to try to send its data ]
[サーバーは、そのデータを送信しようとし続け]
client.1391 > server.8080: PA < window = 0 > server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000 client.1391 > server.8080: PA < window = 0 > server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000 client.1391 > server.8080: PA < window = 0 > server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000 client.1391 > server.8080: PA < window = 0 > server.8080 > client.1391: [DF] A bdfa:bdfb(1) ack: 1c3 win: 8000 client.1391 > server.8080: PA < window = 0 >
client.1391> server.8080：PA <ウィンドウ= 0> server.8080> client.1391：[DF] A bdfa：BDFB（1）ACK：1C3勝利：8000 client.1391> server.8080：PA <ウィンドウ= 0> server.8080> client.1391：[DF] A bdfa：BDFB（1）ACK：1C3勝利：8000 client.1391> server.8080：PA <ウィンドウ= 0> server.8080> client.1391：[DF ] A bdfa：BDFB（1）ACK：1C3勝利：8000 client.1391> server.8080：PA <ウィンドウ= 0> server.8080> client.1391：[DF] A bdfa：BDFB（1）ACK：1C3勝利：8000 client.1391> server.8080：PA <ウィンドウ= 0>
[ ... repeat ad exhaustium ... ]
[...広告exhaustium繰り返し...]
Trace file demonstrating correct behavior Made using an unknown network analyzer. No drop information available.
正しい動作を実演するトレースファイルには、未知のネットワークアナライザを使用して作られました。利用可能なドロップ情報がありません。
client > server D=80 S=59500 Syn Seq=337 Len=0 Win=8760 server > client D=59500 S=80 Syn Ack=338 Seq=80153 Len=0 Win=8760 client > server D=80 S=59500 Ack=80154 Seq=338 Len=0 Win=8760
クライアント>サーバD = 80、S = 59500シンSEQ = 337レン= 0勝利= 8760サーバー>クライアントD = 59500 S = 80 SYN ACK = 338 SEQ = 80153レン= 0勝利= 8760クライアント>サーバD = 80、S = 59500 = 80154 SEQ = 338レン= 0勝利= 8760 ACK
[ ... normal data omitted ... ]
[...省略し、通常のデータ...]
client > server D=80 S=59500 Ack=14559 Seq=596 Len=0 Win=8760 server > client D=59500 S=80 Ack=596 Seq=114559 Len=1460 Win=8760
クライアント>サーバD = 80、S = 59500 ACK = 14559 SEQ = 596レン= 0勝利= 8760サーバー>クライアントD = 59500 S = 80 ACK = 596 SEQ = 114559レン= 1460ウィン= 8760
[ client closes connection ]
[クライアントが接続を閉じます]
client > server D=80 S=59500 Fin Seq=596 Len=0 Win=8760 server > client D=59500 S=80 Ack=597 Seq=116019 Len=1460 Win=8760
クライアント>サーバD = 80、S = 59500フィンSEQ = 596レン= 0勝利= 8760サーバー>クライアントD = 59500 S = 80 ACK = 597 SEQ = 116019レン= 1460ウィン= 8760
[ client sends RST (RFC1122 4.2.2.13) ]
[クライアントがRST（RFC1122 4.2.2.13）を送信します]
client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0 server > client D=59500 S=80 Ack=597 Seq=117479 Len=1460 Win=8760 client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0 server > client D=59500 S=80 Ack=597 Seq=118939 Len=1460 Win=8760 client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0 server > client D=59500 S=80 Ack=597 Seq=120399 Len=892 Win=8760 client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0 server > client D=59500 S=80 Ack=597 Seq=121291 Len=1460 Win=8760 client > server D=80 S=59500 Rst Seq=597 Len=0 Win=0
クライアント>サーバD = 80、S = 59500 RstをSEQ = 597レン= 0のWin = 0サーバー>クライアントD = 59500 S = 80 ACK = 597 SEQ = 117479レン= 1460ウィン= 8760クライアント>サーバD = 80、S = 59500 RstをSEQ = 597レン= 0のWin = 0サーバー>クライアントD = 59500 S = 80 ACK = 597 SEQ = 118939レン= 1460ウィン= 8760クライアント>サーバD = 80、S = 59500 RstをSEQ = 597レン= 0のWin = 0サーバー>クライアントD = 59500 S = 80 ACK = 597 SEQ = 120399レン= 892ウィン= 8760クライアント>サーバD = 80、S = 59500 RstをSEQ = 597レン= 0のWin = 0サーバー>クライアントD = 59500 S = 80 ACK = 597 SEQ = 121291レン= 1460ウィン= 8760クライアント>サーバD = 80、S = 59500 RstをSEQ = 597レン= 0勝利= 0
"client" sends a number of RSTs, one in response to each incoming packet from "server". One might wonder why "server" keeps sending data packets after it has received a RST from "client"; the explanation is that "server" had already transmitted all five of the data packets before receiving the first RST from "client", so it is too late to avoid transmitting them.
「クライアント」のRST、「サーバー」から各着信パケットに応答して、1つの番号を送信します。 「サーバー」は、それが「クライアント」からRSTを受信した後にデータパケットを送信し続ける理由の一つは、不思議に思うかもしれません。説明は、「サーバー」はすでに「クライアント」からの最初のRSTを受信する前に、データパケットの5つすべてを送信していたことなので、それらを送信避けるために遅すぎます。
How to detect The problem can be detected by inspecting packet traces of a large, interrupted bulk transfer.
どのように問題を検出する大規模な、中断されたバルク転送のパケットトレースを検査することによって検出することができます。
Name of Problem Failure to RST on close with data pending
保留中のデータと密接にRSTに問題の失敗の名前
Classification Resource management
分類リソース管理
Description When an application closes a connection in such a way that it can no longer read any received data, the TCP SHOULD, per section 4.2.2.13 of RFC 1122, send a RST if there is any unread received data, or if any new data is received. A TCP that fails to do so exhibits "Failure to RST on close with data pending".
アプリケーションは、それはもはや、任意のRFC 1122のセクション4.2.2.13あたりに、TCP SHOULD、データを受信したリード未読の受信データがある場合はRSTを送ったり、新しいデータであればできるような方法で接続を閉じ説明受信されました。その展示「保留中のデータと密接にRSTに失敗」を行うには失敗したTCP。
Note that, for some TCPs, this situation can be caused by an application "crashing" while a peer is sending data.
いくつかのTCPのために、このような状況は、ピアがデータを送信している間に「クラッシュ」のアプリケーションが原因で発生することができ、ことに注意してください。
We have observed a number of TCPs that exhibit this problem. The problem is less serious if any subsequent data sent to the now-closed connection endpoint elicits a RST (see illustration below).
私たちは、この問題は発生したTCPの数を観察しています。問題は今閉じ接続エンドポイントに送信された後続データRSTを誘発する場合より少なく深刻である（以下の図を参照）。
Significance This problem is most significant for endpoints that engage in large numbers of connections, as their ability to do so will be curtailed as they leak away resources.
意義この問題は、彼らが資源を離れてリークするとして、そうする能力が縮小されるように、多数の接続に従事するエンドポイントの最も重要です。
Implications Failure to reset the connection can lead to permanently hung connections, in which the remote endpoint takes no further action to tear down the connection because it is waiting on the local TCP to first take some action. This is particularly the case if the local TCP also allows the advertised window to go to zero, and fails to tear down the connection when the remote TCP engages in "persist" probes (see example below).
最初にいくつかのアクションを実行するローカルTCP上で待機しているため、リモートエンドポイントが接続を切断する以降のアクションを実行しませんした恒久的にハング接続、につながることができ、接続をリセットする意味が失敗。ローカルTCPはまた、ゼロに移動するために広告ウィンドウを可能にし、リモートTCPが「持続」プローブ（以下の例を参照）に係合したときに接続を切断することができない場合、これは特にそうです。
Relevant RFCs RFC 1122 section 4.2.2.13. Also, 4.2.2.17 for the zero-window probing discussion below.
関連のRFC RFC 1122のセクション4.2.2.13。また、ゼロウィンドウの4.2.2.17は、以下の議論をプロービングします。
Trace file demonstrating it Made using tcpdump. No drop information available.
それを実演するトレースファイルに、tcpdumpを使用して作られました。利用可能なドロップ情報がありません。
13:11:46.04 A > B: S 458659166:458659166(0) win 4096 <mss 1460,wscale 0,eol> (DF) 13:11:46.04 B > A: S 792320000:792320000(0) ack 458659167 win 4096 13:11:46.04 A > B: . ack 1 win 4096 (DF) 13:11.55.80 A > B: . 1:513(512) ack 1 win 4096 (DF) 13:11.55.80 A > B: . 513:1025(512) ack 1 win 4096 (DF) 13:11:55.83 B > A: . ack 1025 win 3072 13:11.55.84 A > B: . 1025:1537(512) ack 1 win 4096 (DF) 13:11.55.84 A > B: . 1537:2049(512) ack 1 win 4096 (DF) 13:11.55.85 A > B: . 2049:2561(512) ack 1 win 4096 (DF) 13:11:56.03 B > A: . ack 2561 win 1536 13:11.56.05 A > B: . 2561:3073(512) ack 1 win 4096 (DF) 13:11.56.06 A > B: . 3073:3585(512) ack 1 win 4096 (DF) 13:11.56.06 A > B: . 3585:4097(512) ack 1 win 4096 (DF) 13:11:56.23 B > A: . ack 4097 win 0 13:11:58.16 A > B: . 4096:4097(1) ack 1 win 4096 (DF) 13:11:58.16 B > A: . ack 4097 win 0 13:12:00.16 A > B: . 4096:4097(1) ack 1 win 4096 (DF) 13:12:00.16 B > A: . ack 4097 win 0 13:12:02.16 A > B: . 4096:4097(1) ack 1 win 4096 (DF) 13:12:02.16 B > A: . ack 4097 win 0 13:12:05.37 A > B: . 4096:4097(1) ack 1 win 4096 (DF) 13:12:05.37 B > A: . ack 4097 win 0 13:12:06.36 B > A: F 1:1(0) ack 4097 win 0 13:12:06.37 A > B: . ack 2 win 4096 (DF) 13:12:11.78 A > B: . 4096:4097(1) ack 2 win 4096 (DF)
13：11：46.04 A> B：Sの458659166：11：46.04 B> A：Sの792320000：792320000（0）ACK 458659167 4096を獲得458659166（0）4096 <MSS 1460 wscale 0、EOL>（DF）13に勝ちます13：11：46.04 A> B：。 11.55.80 A> B：ACK 1 4096（DF）13を獲得：。 1：513（512）、ACK 1勝4096（DF）13：11.55.80 A> B：。 513：1025（512）、ACK 1勝4096（DF）13：11：55.83 B> A：。 ACK 1025は3072 13に勝つ：11.55.84 A> B：。 1025：1537（512）、ACK 1勝4096（DF）13：11.55.84 A> B：。 1537：2049（512）、ACK 1勝4096（DF）13：11.55.85 A> B：。 2049：2561（512）、ACK 1勝4096（DF）13：11：56.03 B> A：。 ACK 2561は、1536年13勝つ：11.56.05 A> B：。 2561：3073（512）、ACK 1勝4096（DF）13：11.56.06 A> B：。 3073：3585（512）、ACK 1勝4096（DF）13：11.56.06 A> B：。 3585：4097（512）、ACK 1勝4096（DF）13：11：56.23 B> A：。 11：ACK 4097 0 13を獲得58.16 A> B：。 4097（1）ACK 1勝4096（DF）13：4096 11：58.16 B> A：。 12：ACK 4097 0 13を獲得00.16 A> B：。 4097（1）ACK 1勝4096（DF）13：4096 12：00.16 B> A：。 12：ACK 4097 0 13を獲得02.16 A> B：。 4097（1）ACK 1勝4096（DF）13：4096 12：02.16 B> A：。 12：ACK 4097 0 13を獲得05.37 A> B：。 4097（1）ACK 1勝4096（DF）13：4096 12：05.37 B> A：。 12：ACK 4097 0 13を獲得06.36 B> A：F 1：12：1（0）ACK 4097 0 13を獲得06.37 A> B：。 12：ACK 2 4096（DF）13を獲得11.78 A> B：。 4096：4097（1）ACK 2勝つ4096（DF）
13:12:11.78 B > A: . ack 4097 win 0 13:12:24.59 A > B: . 4096:4097(1) ack 2 win 4096 (DF) 13:12:24.60 B > A: . ack 4097 win 0 13:12:50.22 A > B: . 4096:4097(1) ack 2 win 4096 (DF) 13:12:50.22 B > A: . ack 4097 win 0
13：12：11.78 B> A：。 12：ACK 4097 0 13を獲得24.59 A> B：。 4097（1）ACK 2勝利4096（DF）13：4096 12：24.60 B> A：。 12：ACK 4097 0 13を獲得50.22 A> B：。 4097（1）ACK 2勝利4096（DF）13：4096 12：50.22 B> A：。 4097 ACK 0に勝ちます
Machine B in the trace above does not drop received data when the socket is "closed" by the application (in this case, the application process was terminated). This occurred at approximately 13:12:06.36 and resulted in the FIN being sent in response to the close. However, because there is no longer an application to deliver the data to, the TCP should have instead sent a RST.
ソケットは、アプリケーションによって「閉」である場合トレースにおけるマシンBは、上記受信したデータをドロップしない（この場合、アプリケーション・プロセスが終了しました）。 12：：これは約13で発生した06.36とFINが近くに応答して送信されているが生じました。データを配信するためにアプリケーションがなくなったのでしかし、TCPの代わりにRSTを送信していないはずです。
Note: Machine A's zero-window probing is also broken. It is resending old data, rather than new data. Section 3.7 in RFC 793 and Section 4.2.2.17 in RFC 1122 discuss zero-window probing.
注意：プロービングマシンAのゼロ・ウィンドウも壊れています。それは古いデータではなく、新しいデータを再送信されます。 RFC 1122でのRFC 793で、セクション3.7とセクション4.2.2.17プロービングゼロウィンドウを議論します。
Trace file demonstrating better behavior Made using tcpdump. No drop information available.
tcpdumpのを使用して作られた、より良い行動を実証したファイルをトレースします。利用可能なドロップ情報がありません。
Better, but still not fully correct, behavior, per the discussion below. We show this behavior because it has been observed for a number of different TCP implementations.
より良い、まだ完全には、正しい行動、以下の議論あたりません。それは別のTCP実装の数のために観察されているので、私たちは、この挙動を示します。
13:48:29.24 C > D: S 73445554:73445554(0) win 4096 <mss 1460,wscale 0,eol> (DF) 13:48:29.24 D > C: S 36050296:36050296(0) ack 73445555 win 4096 <mss 1460,wscale 0,eol> (DF) 13:48:29.25 C > D: . ack 1 win 4096 (DF) 13:48:30.78 C > D: . 1:1461(1460) ack 1 win 4096 (DF) 13:48:30.79 C > D: . 1461:2921(1460) ack 1 win 4096 (DF) 13:48:30.80 D > C: . ack 2921 win 1176 (DF) 13:48:32.75 C > D: . 2921:4097(1176) ack 1 win 4096 (DF) 13:48:32.82 D > C: . ack 4097 win 0 (DF) 13:48:34.76 C > D: . 4096:4097(1) ack 1 win 4096 (DF) 13:48:34.84 D > C: . ack 4097 win 0 (DF) 13:48:36.34 D > C: FP 1:1(0) ack 4097 win 4096 (DF) 13:48:36.34 C > D: . 4097:5557(1460) ack 2 win 4096 (DF) 13:48:36.34 D > C: R 36050298:36050298(0) win 24576 13:48:36.34 C > D: . 5557:7017(1460) ack 2 win 4096 (DF) 13:48:36.34 D > C: R 36050298:36050298(0) win 24576
13：48：29.24 C> D：S 73445554：48：29.24 D> C：S 36050296：36050296（0）ACK 73445555勝利4096 73445554（0）4096 <MSS 1460 wscale 0、EOL>（DF）13に勝ちます<MSS 1460 wscale 0、EOL>（DF）13：48：29.25 C> D：。 48：ACK 1 4096（DF）13を獲得30.78 C> D：。 1：48：1461（1460）ACK 1、4096（DF）13を獲得30.79 C> D：。 1461：48：2921（1460）ACK 1、4096（DF）13を獲得30.80 D> C：。 48：ACK 2921は、13（DF）を1176年に勝つ32.75 C> D：。 2921：48：4097（1176）ACK 1、4096（DF）13を獲得32.82 D> C：。 48：ACK 4097は、0（DF）13を獲得34.76 C> D：。 4096：48：4097（1）ACK 1、4096（DF）13を獲得34.84 D> C：。 48：ACK 4097は、0（DF）13を獲得36.34 D> C：FP 1：1（0）にACK 4097が4096（DF）を勝つ13：48：36.34 C> D：を。 4097：48：5557（1460）、ACK 2、4096（DF）13を獲得36.34 D> C：R 36050298：48：36050298（0）24576 13を獲得36.34 C> D：。 5557：7017勝利4096（1460）、ACK 2（DF）13：48：36.34 D> C：R 36050298：36050298（0）24576に勝ちます
In this trace, the application process is terminated on Machine D at approximately 13:48:36.34. Its TCP sends the FIN with the window opened again (since it discarded the previously received data). Machine C promptly sends more data, causing Machine D to reset the connection since it cannot deliver the data to the application. Ideally, Machine D SHOULD send a RST instead of dropping the data and re-opening the receive window.
48：36.34このトレースでは、アプリケーション・プロセスは、約13のマシンDに終了されます。そのTCPは、（それが以前に受信したデータを破棄するので）、再び開いたウィンドウでFINを送信します。マシンCは、速やかに、それはアプリケーションにデータを配信することはできませんので、マシンDは、接続をリセットさせ、より多くのデータを送信します。理想的には、マシンDは、データおよび再開放受信ウィンドウを落とすのではなく、RSTを送信すべきです。
Note: Machine C's zero-window probing is broken, the same as in the example above.
注：プロービングマシンCのゼロウィンドウが壊れている、上記の例と同様です。
Trace file demonstrating correct behavior Made using tcpdump. No losses reported by the packet filter.
正しい動作を実演するトレースファイルに、tcpdumpを使用して作られました。パケットフィルタによって報告されていない損失はありません。
14:12:02.19 E > F: S 1143360000:1143360000(0) win 4096 14:12:02.19 F > E: S 1002988443:1002988443(0) ack 1143360001 win 4096 <mss 1460> (DF) 14:12:02.19 E > F: . ack 1 win 4096 14:12:10.43 E > F: . 1:513(512) ack 1 win 4096 14:12:10.61 F > E: . ack 513 win 3584 (DF) 14:12:10.61 E > F: . 513:1025(512) ack 1 win 4096 14:12:10.61 E > F: . 1025:1537(512) ack 1 win 4096 14:12:10.81 F > E: . ack 1537 win 2560 (DF) 14:12:10.81 E > F: . 1537:2049(512) ack 1 win 4096 14:12:10.81 E > F: . 2049:2561(512) ack 1 win 4096 14:12:10.81 E > F: . 2561:3073(512) ack 1 win 4096 14:12:11.01 F > E: . ack 3073 win 1024 (DF) 14:12:11.01 E > F: . 3073:3585(512) ack 1 win 4096 14:12:11.01 E > F: . 3585:4097(512) ack 1 win 4096 14:12:11.21 F > E: . ack 4097 win 0 (DF) 14:12:15.88 E > F: . 4097:4098(1) ack 1 win 4096 14:12:16.06 F > E: . ack 4097 win 0 (DF) 14:12:20.88 E > F: . 4097:4098(1) ack 1 win 4096 14:12:20.91 F > E: . ack 4097 win 0 (DF) 14:12:21.94 F > E: R 1002988444:1002988444(0) win 4096
14：12：02.19 E> F：S 1143360000：12：02.19 F> E：S 1002988443：1002988443（0）ACK 1143360001勝利4096 <MSS 1460>（DF）14：12：02.19 1143360000（0）4096 14勝ちますE> F：。 12：10.43 E> F 1勝4096 14 ACKの場合：。 1：513（512）、ACK 1 14 4096勝つ：12：10.61 F> Eが：。 12：：ackを513は3584（DF）14に勝つ10.61 E> F：。 513：1025（512）、ACK 1勝4096 14：12：10.61 E> F：。 1025：1537（512）、ACK 1勝4096 14：12：10.81 F> E：。 12：ACK 1537は、2560（DF）14に勝つ10.81 E> F：。 1537：12：2049（512）、ACK 1、4096 14に勝つ10.81 E> F：。 2049：12：2561（512）、ACK 1、4096 14に勝つ10.81 E> F：。 2561：3073（512）、ACK 1勝4096 14：12：11.01 F> E：。 12：ACK 3073 1024（DF）14に勝つ11.01 E> F：。 3073：12：3585（512）、ACK 1、4096 14に勝つ11.01 E> F：。 3585：4097（512）、ACK 1勝4096 14：12：11.21 F> E：。 12：ACK 4097は0（DF）14に勝つ15.88 E> F：。 4097：12：4098（1）ACK 1、4096 14に勝つ16.06 F> E：。 12：ACK 4097は0（DF）14に勝つ20.88 E> F：。 4097：12：4098（1）ACK 1、4096 14に勝つ20.91 F> E：。 12：ACK 4097は、0（DF）14を獲得21.94 F> E：R 1002988444：1002988444（0）4096に勝ちます
When the application terminates at 14:12:21.94, F immediately sends a RST.
アプリケーションは14で終了するとき：12：21.94、FはすぐにRSTを送信します。
Note: Machine E's zero-window probing is (finally) correct.
注意：探査機Eのゼロ・ウィンドウが（最終的に）正しいです。
How to detect The problem can often be detected by inspecting packet traces of a transfer in which the receiving application terminates abnormally. When doing so, there can be an ambiguity (if only looking at the trace) as to whether the receiving TCP did indeed have unread data that it could now no longer deliver. To provoke this to happen, it may help to suspend the receiving application so that it fails to consume any data, eventually exhausting the advertised window. At this point, since the advertised window is zero, we know that the receiving TCP has undelivered data buffered up. Terminating the application process then should suffice to test the correctness of the TCP's behavior.
どのように問題を検出するのには、多くの場合、受信側アプリケーションが異常終了した場合の転送のパケットトレースを検査することによって検出することができます。その際（トレースだけを見ている場合）、受信側TCPは確かにそれはもはや届けることができなかったことを未読のデータを持っていなかったかどうかがあいまいになることがあります。これを実現するために挑発するには、それが最終的に広告ウィンドウを排出する、任意のデータを消費するために失敗したように、受信アプリケーションを中断するのを助けることができます。広告ウィンドウがゼロであるため、この時点で、我々は、受信TCPがアップバッファされたデータを未配信していることを知っています。その後、アプリケーション・プロセスを終了すると、TCPの行動の正しさをテストするために十分です。
Name of Problem Options missing from TCP MSS calculation
TCP MSSの計算から欠落している問題のオプションの名前
Classification Reliability / performance
分類信頼性/パフォーマンス
Description When a TCP determines how much data to send per packet, it calculates a segment size based on the MTU of the path. It must then subtract from that MTU the size of the IP and TCP headers in the packet. If IP options and TCP options are not taken into account correctly in this calculation, the resulting segment size may be too large. TCPs that do so are said to exhibit "Options missing from TCP MSS calculation".
説明TCPデータはパケットごとに送信するためにどのくらいと判断した場合、それはパスのMTUに基づいてセグメントサイズを計算します。その後、パケット内のIPおよびTCPヘッダのMTUサイズそれから減算する必要があります。 IPオプションおよびTCPオプションが正しく、この計算では考慮されていない場合は、結果のセグメントサイズが大きすぎる可能性があります。そうTCPは、「TCP MSSの計算から欠落しているオプション」を示すと言われています。
Significance In some implementations, this causes the transmission of strangely fragmented packets. In some implementations with Path MTU (PMTU) discovery [RFC1191], this problem can actually result in a total failure to transmit any data at all, regardless of the environment (see below).
いくつかの実装では意義が、これは奇妙に断片化されたパケットの送信が発生します。パスMTU（PMTU）の発見[RFC1191]を有するいくつかの実装では、この問題は実際にかかわらず、環境の（下記参照）、全くデータを送信するための総故障をもたらすことができます。
Arguably, especially since the wide deployment of firewalls, IP options appear only rarely in normal operations.
間違いなく、特にファイアウォールの幅広い展開するので、IPオプションは、通常の操作では稀にしか表示されません。
Implications In implementations using PMTU discovery, this problem can result in packets that are too large for the output interface, and that have the DF (don't fragment) bit set in the IP header. Thus, the IP layer on the local machine is not allowed to fragment the packet to send it out the interface. It instead informs the TCP layer of the correct MTU size of the interface; the TCP layer again miscomputes the MSS by failing to take into account the size of IP options; and the problem repeats, with no data flowing.
PMTU検出を使用して実装において影響は、この問題は、出力インタフェースには大きすぎるパケットをもたらすことができる、それはDF（断片化していない）IPヘッダ内のビットセットを有します。このように、ローカルマシンのIP層は、インターフェースを、それを送信するためにパケットをフラグメント化することはできません。これは、代わりにインターフェースの正しいMTUサイズのTCP層に通知します。 TCP層は再び考慮にIPオプションのサイズを取ることができないことにより、MSSをmiscomputes。そして問題は、データが流れていないと、繰り返されます。
Relevant RFCs RFC 1122 describes the calculation of the effective send MSS. RFC 1191 describes Path MTU discovery.
関連のRFCのRFC 1122は、有効送信MSSの計算を説明します。 RFC 1191は、パスMTU発見を説明します。
Trace file demonstrating it Trace file taking using tcpdump on host C. The first trace demonstrates the fragmentation that occurs without path MTU discovery:
それは、ホストCにtcpdumpのを使用して最初のトレースを取って、ファイルをトレース実演するトレースファイルは、パスMTU探索せずに発生する断片化を示しています。
13:55:25.488728 A.65528 > C.discard: P 567833:569273(1440) ack 1 win 17520 <nop,nop,timestamp 3839 1026342> (frag 20828:1472@0+) (ttl 62, optlen=8 LSRR{B#} NOP)
（TTL 62の場合、optlen = 8 LSRR 13：55：25.488728 A.65528> C.discard：P 567833：569273（1440）ACK 1勝つ17520 <NOP、NOP、タイムスタンプ3839 1026342>（0 + @ 1472 FRAG 20828） {B位} NOP）
13:55:25.488943 A > C: (frag 20828:8@1472) (ttl 62, optlen=8 LSRR{B#} NOP)
13：55：25.488943 A> C：（フラグ・20828：1472 @ 8）（TTL 62の場合、optlen = 8 LSRR {B位} NOP）
13:55:25.489052 C.discard > A.65528: . ack 566385 win 60816 <nop,nop,timestamp 1026345 3839> (DF) (ttl 60, id 41266)
13：55：25.489052 C.discard> A.65528：。 566385を確認応答60816 <NOP、NOP、タイムスタンプ1026345 3839>（DF）（TTL 60、ID 41266）を勝ちます
Host A repeatedly sends 1440-octet data segments, but these hare fragmented into two packets, one with 1432 octets of data, and another with 8 octets of data.
繰り返し1440オクテットのデータセグメントを送信するホストが、これらは二つのパケット、データの8つのオクテットとのデータの1432個のオクテットを有するもの、及び他に断片化ウサギ。
The second trace demonstrates the failure to send any data segments, sometimes seen with hosts doing path MTU discovery:
第2のトレースは、時々、パスMTUディスカバリを行うホストと見られ、任意のデータセグメントを送信するために失敗したことを示しています。
13:55:44.332219 A.65527 > C.discard: S 1018235390:1018235390(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 3876 0> (DF) (ttl 62, id 20912, optlen=8 LSRR{B#} NOP)
13：55：44.332219 A.65527> C.discard：Sは1018235390：1018235390（0）16384 <MSS 1460、NOP、wscale 0、NOP、NOP、タイムスタンプ3876 0>（DF）に勝つ（TTL 62、ID 20912の場合、optlen = 8 LSRR {B位} NOP）
13:55:44.333015 C.discard > A.65527: S 1271629000:1271629000(0) ack 1018235391 win 60816 <mss 1460,nop,wscale 0,nop,nop,timestamp 1026383 3876> (DF) (ttl 60, id 41427)
13：55：44.333015 C.discard> A.65527：Sは1271629000：1271629000（0）ACK 1018235391勝つ60816 <MSS 1460、NOP、wscale 0、NOP、NOP、タイムスタンプ1026383 3876>（DF）（TTL 60、ID 41427 ）
13:55:44.333206 C.discard > A.65527: S 1271629000:1271629000(0) ack 1018235391 win 60816 <mss 1460,nop,wscale 0,nop,nop,timestamp 1026383 3876> (DF) (ttl 60, id 41427)
13：55：44.333206 C.discard> A.65527：Sは1271629000：1271629000（0）ACK 1018235391勝つ60816 <MSS 1460、NOP、wscale 0、NOP、NOP、タイムスタンプ1026383 3876>（DF）（TTL 60、ID 41427 ）
This is all of the activity seen on this connection. Eventually host C will time out attempting to establish the connection.
これは、この接続で見られる活動のすべてです。最終的にはCが接続を確立しようとタイムアウトします主催。
How to detect The "netcat" utility [Hobbit96] is useful for generating source routed packets:
[Hobbit96]は、ソースルーティングされたパケットを生成するのに有用である「netcatを」ユーティリティを検出する方法：
1% nc C discard (interactive typing) ^C 2% nc C discard < /dev/zero ^C 3% nc -g B C discard (interactive typing) ^C 4% nc -g B C discard < /dev/zero ^C
1％のNC C廃棄（対話型タイピング）^ C 2％のNC C破棄</ DEV /ゼロ^ C 3％NC -g BのC廃棄（対話型タイピング）^ C 4％NC -g BのC破棄</ DEV /ゼロ^ C
Lines 1 through 3 should generate appropriate packets, which can be verified using tcpdump. If the problem is present, line 4 should generate one of the two kinds of packet traces shown.
3を介してライン1に、tcpdumpを使用して確認することができる適切なパケットを生成しなければなりません。問題が存在する場合、ライン4が示すパケットトレースの二種類のいずれかを生成するべきです。
How to fix The implementation should ensure that the effective send MSS calculation includes a term for the IP and TCP options, as mandated by RFC 1122.
どのようにRFC 1122で義務付けられて効果的な送信MSSの計算は、IPおよびTCPオプションのための用語が含まれていることを確認する必要があり、実装を修正します。
This memo does not discuss any specific security-related TCP implementation problems, as the working group decided to pursue documenting those in a separate document. Some of the implementation problems discussed here, however, can be used for denial-of-service attacks. Those classified as congestion control present opportunities to subvert TCPs used for legitimate data transfer into excessively loading network elements. Those classified as "performance", "reliability" and "resource management" may be exploitable for launching surreptitious denial-of-service attacks against the user of the TCP. Both of these types of attacks can be extremely difficult to detect because in most respects they look identical to legitimate network traffic.
ワーキンググループは、別の文書でそれらを文書化追求することを決めたように、このメモは、いかなる特定のセキュリティ関連のTCPの実装上の問題を議論しません。ここで議論し、実装上の問題のいくつかは、しかし、サービス拒否攻撃のために使用することができます。過剰ローディングネットワーク要素に正規のデータ転送に使用されるのTCPを破壊する輻輳制御本機会として分類されるもの。 「パフォーマンス」、「信頼性」と「資源管理」として分類されるものは、TCPの利用者に対して内密サービス拒否攻撃を起動するための悪用可能かもしれません。ほとんどの点で、彼らは正当なネットワークトラフィックと同じに見えるので、この種の攻撃の両方を検出するのは非常に困難な場合があります。
Thanks to numerous correspondents on the tcp-impl mailing list for their input: Steve Alexander, Larry Backman, Jerry Chu, Alan Cox, Kevin Fall, Richard Fox, Jim Gettys, Rick Jones, Allison Mankin, Neal McBurnett, Perry Metzger, der Mouse, Thomas Narten, Andras Olah, Steve Parker, Francesco Potorti`, Luigi Rizzo, Allyn Romanow, Al Smith, Jerry Toporek, Joe Touch, and Curtis Villamizar.
スティーブ・アレクサンダー、ラリーBackman、ジェリー・チュー、アラン・コックス、ケビン秋、リチャード・フォックス、ジム・ゲティーズ、リック・ジョーンズ、アリソンマンキン、ニールMcBurnett、ペリーメッツガー、DERマウス：自分の入力のためのTCP-のimplメーリングリストに多数の特派おかげ、トーマスNarten氏、アンドラーシュオラー、スティーブ・パーカー、フランチェスコPotorti`、ルイジ・リゾ、アリンRomanow、アル・スミス、ジェリーToporek、ジョー・タッチ、そしてカーティスVillamizar。
Thanks also to Josh Cohen for the traces documenting the "Failure to send a RST after Half Duplex Close" problem; and to John Polstra, who analyzed the "Window probe deadlock" problem.
また、ジョシュ・コーエンのおかげで問題「半二重クローズ後RSTを送信するために失敗を」文書化トレース用;そして「ウィンドウプローブデッドロック」の問題を分析したジョンPolstra、へ。
[Allman97] M. Allman, "Fixing Two BSD TCP Bugs," Technical Report CR-204151, NASA Lewis Research Center, Oct. 1997. http://roland.grc.nasa.gov/~mallman/papers/bug.ps
[Allman97] M.オールマン、 "二BSDのTCPのバグを修正、" テクニカルレポートCR-204151、NASAルイスリサーチセンター、10月1997年http://roland.grc.nasa.gov/~mallman/papers/bug.ps
[RFC2414] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[RFC2414]オールマン、M.、フロイド、S.とC.ヤマウズラ、 "増加するTCPの初期ウィンドウ"、RFC 2414、1998年9月。
[RFC1122] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、エディタ、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[Brakmo95] L. Brakmo and L. Peterson, "Performance Problems in BSD4.4 TCP," ACM Computer Communication Review, 25(5):69-86, 1995.
[Brakmo95] L. BrakmoとL.ピーターソン、ACMコンピュータコミュニケーションレビュー、25（5） "BSD4.4 TCP、でのパフォーマンス上の問題"：69から86、1995。
[RFC813] Clark, D., "Window and Acknowledgement Strategy in TCP," RFC 813, July 1982.
[RFC813]クラーク、D.、 "TCPのウィンドウと謝辞戦略、" RFC 813、1982年7月。
[Dawson97] S. Dawson, F. Jahanian, and T. Mitton, "Experiments on Six Commercial TCP Implementations Using a Software Fault Injection Tool," to appear in Software Practice & Experience, 1997. A technical report version of this paper can be obtained at ftp://rtcl.eecs.umich.edu/outgoing/sdawson/CSE-TR-298- 96.ps.gz.
[Dawson97]ソフトウェア実践＆経験、1997年にこの論文の技術レポートのバージョンを表示するS.ドーソン、F. Jahanian、およびT.ミトン、「ソフトウェア障害インジェクションツールを使用して、6つの商業TCPの実装上の実験は、」することができftp://rtcl.eecs.umich.edu/outgoing/sdawson/CSE-TR-298- 96.ps.gz.で得られました
[Fall96] K. Fall and S. Floyd, "Simulation-based Comparisons of Tahoe, Reno, and SACK TCP," ACM Computer Communication Review, 26(3):5-21, 1996.
[Fall96] K.秋とS.フロイド、 "タホ、リノ、およびSACK TCPのシミュレーションベースの比較、" ACMコンピュータコミュニケーションレビュー、26（3）：5-21、1996。
[Hobbit96] Hobbit, Avian Research, netcat, available via anonymous ftp to ftp.avian.org, 1996.
[Hobbit96]ホビットは、鳥の研究は、netcatを、匿名FTPによって利用は、1996 ftp.avian.orgします。
[Hoe96] J. Hoe, "Improving the Start-up Behavior of a Congestion Control Scheme for TCP," Proc. SIGCOMM '96.
[Hoe96] J.鍬、PROC「TCP輻輳制御方式のスタート・アップ挙動を改善」。 SIGCOMM '96。
[Jacobson88] V. Jacobson, "Congestion Avoidance and Control," Proc. SIGCOMM '88. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z
[Jacobson88] V. Jacobson氏、 "輻輳回避とコントロール、" PROC。 SIGCOMM '88。 ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z
[Jacobson89] V. Jacobson, C. Leres, and S. McCanne, tcpdump, available via anonymous ftp to ftp.ee.lbl.gov, Jun. 1989.
【Jacobson89】V. Jacobsonの、C. Leres、及びS. McCanne、tcpdumpを、ftp.ee.lbl.govへの匿名ftpを介して入手可能な、1989年6月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2018]マティス、M.、Mahdavi、J.、フロイド、S.とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC896] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
[RFC896]ネーグル、J.、 "IP / TCPインターネットワークにおける輻輳制御"、RFC 896、1984年1月。
[Paxson97] V. Paxson, "Automated Packet Trace Analysis of TCP Implementations," Proc. SIGCOMM '97, available from ftp://ftp.ee.lbl.gov/papers/vp-tcpanaly-sigcomm97.ps.Z.
【Paxson97] V.パクソン、「TCP実装の自動化されたパケットトレース分析、」PROC。 SIGCOMM '97、ftp://ftp.ee.lbl.gov/papers/vp-tcpanaly-sigcomm97.ps.Zから入手できます。
[RFC793] Postel, J., Editor, "Transmission Control Protocol," STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、エディタ、 "伝送制御プロトコル、" STD 7、RFC 793、1981年9月。
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[RFC2001]スティーブンス、W.、 "TCPスロースタート、輻輳回避、高速再送、および高速リカバリアルゴリズム"、RFC 2001、1997年1月。
[Stevens94] W. Stevens, "TCP/IP Illustrated, Volume 1", Addison-Wesley Publishing Company, Reading, Massachusetts, 1994.
[Stevens94] W.スティーブンス、 "TCP / IPイラスト、第1巻"、アディソン・ウェズリー出版社、読書、マサチューセッツ州、1994年。
[Wright95] G. Wright and W. Stevens, "TCP/IP Illustrated, Volume 2", Addison-Wesley Publishing Company, Reading Massachusetts, 1995.
[Wright95] G.ライトとW.スティーブンス、 "TCP / IPイラスト、第2巻"、アディソン・ウェズリー出版社、読書マサチューセッツ州、1995年。
Vern Paxson ACIRI / ICSI 1947 Center Street Suite 600 Berkeley, CA 94704-1198
バーン・パクソンACIRI / ICSI 1947センターストリートスイート600バークレー、CA 94704から1198
Phone: +1 510/642-4274 x302 EMail: vern@aciri.org
電話：+1 510/642から4274 X302メール：vern@aciri.org
Mark Allman <mallman@grc.nasa.gov> NASA Glenn Research Center/Sterling Software Lewis Field 21000 Brookpark Road MS 54-2 Cleveland, OH 44135 USA
マーク・オールマン<mallman@grc.nasa.gov> NASAグレンリサーチセンター/スターリングソフトウェアルイス・フィールド21000ブルックパークロードMS 54-2クリーブランド、オハイオ州44135 USA
Phone: +1 216/433-6586 Email: mallman@grc.nasa.gov
電話：+1 216/433から6586 Eメール：mallman@grc.nasa.gov
Scott Dawson Real-Time Computing Laboratory EECS Building University of Michigan Ann Arbor, MI 48109-2122 USA
ミシガン州アナーバー、MI 48109-2122 USAのスコット・ドーソンリアルタイムコンピューティング研究所EECSビル大学
Phone: +1 313/763-5363 EMail: sdawson@eecs.umich.edu
電話：+1 313/763から5363 Eメール：sdawson@eecs.umich.edu
William C. Fenner Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304 USA
ウィリアム・C・フェナーゼロックスPARC 3333コヨーテヒルロードパロアルト、CA 94304 USA
Phone: +1 650/812-4816 EMail: fenner@parc.xerox.com
電話：+1 650/812から4816 Eメール：fenner@parc.xerox.com
Jim Griner <jgriner@grc.nasa.gov> NASA Glenn Research Center Lewis Field 21000 Brookpark Road MS 54-2 Cleveland, OH 44135 USA
ジム・Griner <jgriner@grc.nasa.gov> NASAグレンリサーチセンタールイス・フィールド21000ブルックパークロードMS 54-2クリーブランド、オハイオ州44135 USA
Phone: +1 216/433-5787 EMail: jgriner@grc.nasa.gov
電話：+1 216/433から5787 Eメール：jgriner@grc.nasa.gov
Ian Heavens Spider Software Ltd. 8 John's Place, Leith Edinburgh EH6 7EL UK
イアン・天スパイダーソフトウェア株式会社8ジョンの場所、リースエジンバラEH6 7EL英国
Phone: +44 131/475-7015 EMail: ian@spider.com
電話：+44 131/475から7015 Eメール：ian@spider.com
Kevin Lahey NASA Ames Research Center/MRJ MS 258-6 Moffett Field, CA 94035 USA
ケビン・レイヒーNASAエイムズ研究センター/ MRJ MS 258から6モフェットフィールド、CA 94035 USA
Phone: +1 650/604-4334 EMail: kml@nas.nasa.gov
電話：+1 650/604から4334 Eメール：kml@nas.nasa.gov
Jeff Semke Pittsburgh Supercomputing Center 4400 Fifth Ave Pittsburgh, PA 15213 USA
ジェフSemkeピッツバーグ・スーパーコンピューティング・センター4400フィフスアベニューピッツバーグ、PA 15213 USA
Phone: +1 412/268-4960 EMail: semke@psc.edu
電話：+1 412/268から4960 Eメール：semke@psc.edu
Bernie Volz Process Software Corporation 959 Concord Street Framingham, MA 01701 USA
バーニーフォルツプロセスSoftware Corporationの959コンコードストリートフラミンガム、MA 01701 USA
Phone: +1 508/879-6994 EMail: volz@process.com
電話：+1 508/879から6994 Eメール：volz@process.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。