RFC1323 日本語訳
1323 TCP Extensions for High Performance. V. Jacobson, R. Braden, D.Borman. May 1992. (Format: TXT=84558 bytes) (Obsoletes RFC1072, RFC1185) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group V. Jacobson
Request for Comments: 1323 LBL
Obsoletes: RFC 1072, RFC 1185 R. Braden
ISI
D. Borman
Cray Research
May 1992
コメントを求めるワーキンググループV.ジェーコブソン要求をネットワークでつないでください: 1323LBLは以下を時代遅れにします。 RFC1072、RFC1185R.ブレーデンISI D.ボーマンクレイリサーチ1992年5月
TCP Extensions for High Performance
高性能のためのTCP拡張子
Status of This Memo
このメモの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences). Selective acknowledgments are not included in this memo.
このメモは、大きい帯域幅*遅れ製品経路にわたる性能を向上させて、非常に高速な経路の上に信頼できる操作を提供するために1セットのTCP拡張子を提示します。 それはスケーリングされた窓とタイムスタンプのための新しいTCPオプションを定義します。(タイムスタンプは、拡大を実行しないTCPのものをコンパチブル織り込むのに提供するように設計されています)。 タイムスタンプは2台の異なる機序に使用されます: RTTM(周遊旅行時間測定)と足(包装された系列から守ります)。 選択している承認はこのメモに含まれていません。
This memo combines and supersedes RFC-1072 and RFC-1185, adding additional clarification and more detailed specification. Appendix C summarizes the changes from the earlier RFCs.
追加明確化と、より詳細な仕様を加えて、このメモは、RFC-1072とRFC-1185を結合して、取って代わります。 付録Cは以前のRFCsから変化をまとめます。
TABLE OF CONTENTS
目次
1. Introduction ................................................. 2 2. TCP Window Scale Option ...................................... 8 3. RTTM -- Round-Trip Time Measurement .......................... 11 4. PAWS -- Protect Against Wrapped Sequence Numbers ............. 17 5. Conclusions and Acknowledgments .............................. 25 6. References ................................................... 25 APPENDIX A: Implementation Suggestions ........................... 27 APPENDIX B: Duplicates from Earlier Connection Incarnations ...... 27 APPENDIX C: Changes from RFC-1072, RFC-1185 ...................... 30 APPENDIX D: Summary of Notation .................................. 31 APPENDIX E: Event Processing ..................................... 32 Security Considerations .......................................... 37
1. 序論… 2 2. TCP窓のスケールオプション… 8 3. RTTM--往復の時間測定… 11 4. 足--包装された一連番号から守ってください… 17 5. 結論と承認… 25 6. 参照… 25 付録A: 実現提案… 27 付録B: 前から、接続顕現をコピーします… 27 付録C: RFC-1072、RFC-1185からの変化… 30 付録D: 記法の概要… 31 付録E: イベント処理… 32 セキュリティ問題… 37
Jacobson, Braden, & Borman [Page 1] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[1ページ]RFC1323TCP拡張子
Authors' Addresses ............................................... 37
作者のアドレス… 37
1. INTRODUCTION
1. 序論
The TCP protocol [Postel81] was designed to operate reliably over almost any transmission medium regardless of transmission rate, delay, corruption, duplication, or reordering of segments. Production TCP implementations currently adapt to transfer rates in the range of 100 bps to 10**7 bps and round-trip delays in the range 1 ms to 100 seconds. Recent work on TCP performance has shown that TCP can work well over a variety of Internet paths, ranging from 800 Mbit/sec I/O channels to 300 bit/sec dial-up modems [Jacobson88a].
TCPプロトコル[Postel81]は、通信速度、遅れ、不正、複製、またはセグメントを再命令することにかかわらずほとんどどんなトランスミッション媒体の上でも確かに作動するように設計されました。 TCP実現が現在移すために適合させる生産は範囲1msで100の範囲で100秒まで10**7ビーピーエスと往復の遅れにビーピーエスを評定します。 TCP性能の近作は、TCPがさまざまなインターネット経路にわたってうまくいくことができるのを示しました、800個のメガビット/秒の入出力チャンネルから300ビット/秒のダイヤルアップモデム[Jacobson88a]まで及んで。
The introduction of fiber optics is resulting in ever-higher transmission speeds, and the fastest paths are moving out of the domain for which TCP was originally engineered. This memo defines a set of modest extensions to TCP to extend the domain of its application to match this increasing network capability. It is based upon and obsoletes RFC-1072 [Jacobson88b] and RFC-1185 [Jacobson90b].
光ファイバーの導入は、より絶えず高い伝送速度をもたらしています、そして、最も速い経路はTCPが元々設計されたドメインから引っ越しています。 このメモは、この増加するネットワーク能力を合わせるためにアプリケーションのドメインを広げるために1セットの穏やかな拡大をTCPと定義します。 それは、RFC-1072[Jacobson88b]とRFC-1185[Jacobson90b]をに基礎づけていて、時代遅れにします。
There is no one-line answer to the question: "How fast can TCP go?". There are two separate kinds of issues, performance and reliability, and each depends upon different parameters. We discuss each in turn.
1線の質問の答が全くありません: 「どれくらい速く、TCPは行くことができますか?」? 別々の2種類の問題、性能、および信頼性があります、そして、それぞれが異なったパラメタに依存します。 私たちは順番にそれぞれについて議論します。
1.1 TCP Performance
1.1 TCPパフォーマンス
TCP performance depends not upon the transfer rate itself, but
rather upon the product of the transfer rate and the round-trip
delay. This "bandwidth*delay product" measures the amount of data
that would "fill the pipe"; it is the buffer space required at
sender and receiver to obtain maximum throughput on the TCP
connection over the path, i.e., the amount of unacknowledged data
that TCP must handle in order to keep the pipeline full. TCP
performance problems arise when the bandwidth*delay product is
large. We refer to an Internet path operating in this region as a
"long, fat pipe", and a network containing this path as an "LFN"
(pronounced "elephan(t)").
TCP性能は転送レート自体ではなく、むしろ転送レートの製品と往復の遅れに依存します。 この「帯域幅*遅れ製品」は「パイプをいっぱいにする」データ量を測定します。 それは経路(すなわち、TCPがパイプラインを完全に保つために扱わなければならない不承認のデータの量)の上のTCP関係に関する最大のスループットを得るのに送付者と受信機で必要であるバッファ領域です。 帯域幅*遅れ製品が大きいときに、TCP性能問題は起こります。 私たちは、「長くて、太っているパイプ」とこの領域で作動するインターネット経路を呼んで、"LFN"("elephan(t)"であると断言される)としてこの経路を含むネットワークを呼びます。
High-capacity packet satellite channels (e.g., DARPA's Wideband
Net) are LFN's. For example, a DS1-speed satellite channel has a
bandwidth*delay product of 10**6 bits or more; this corresponds to
100 outstanding TCP segments of 1200 bytes each. Terrestrial
fiber-optical paths will also fall into the LFN class; for
example, a cross-country delay of 30 ms at a DS3 bandwidth
(45Mbps) also exceeds 10**6 bits.
高容量パケット衛星チャンネル(例えば、DARPAのWidebandネット)はLFNのものです。 例えば、DS1-速度衛星チャンネルには、10**の帯域幅*遅れ製品が6ビット以上あります。 これはそれぞれ1200バイトの100の傑出しているTCPセグメントに対応しています。 また、地球のファイバー光路はLFNのクラスになるでしょう。 例えば、また、DS3帯域幅(45Mbps)の30msのクロスカントリーの遅れは10**を6ビット超えています。
There are three fundamental performance problems with the current
TCP over LFN paths:
LFN経路の上に現在のTCPに関する3つの基本的な性能問題があります:
Jacobson, Braden, & Borman [Page 2] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[2ページ]RFC1323TCP拡張子
(1) Window Size Limit
(1)ウィンドウサイズ限界
The TCP header uses a 16 bit field to report the receive
window size to the sender. Therefore, the largest window
that can be used is 2**16 = 65K bytes.
TCPヘッダーは、レシーブ・ウィンドウ・サイズを送付者に報告するのに16ビットの分野を使用します。 したがって、使用できる中で最も大きい窓は16 = 65 2**Kバイトです。
To circumvent this problem, Section 2 of this memo defines a
new TCP option, "Window Scale", to allow windows larger than
2**16. This option defines an implicit scale factor, which
is used to multiply the window size value found in a TCP
header to obtain the true window size.
この問題を回避するなら、このメモのセクション2は、2**16より大きい窓を許容するために新しいTCPオプション、「窓のスケール」を定義します。 このオプションは暗黙の位取り因数を定義します。(それは、本当のウィンドウサイズを得るためにTCPヘッダーで見つけられたウィンドウサイズ値を掛けるのに使用されます)。
(2) Recovery from Losses
(2) 損失からの回復
Packet losses in an LFN can have a catastrophic effect on
throughput. Until recently, properly-operating TCP
implementations would cause the data pipeline to drain with
every packet loss, and require a slow-start action to
recover. Recently, the Fast Retransmit and Fast Recovery
algorithms [Jacobson90c] have been introduced. Their
combined effect is to recover from one packet loss per
window, without draining the pipeline. However, more than
one packet loss per window typically results in a
retransmission timeout and the resulting pipeline drain and
slow start.
LFNのパケット損失は壊滅的な影響をスループットに与えることができます。 最近まで、適切に稼働しているTCP実現は、データパイプラインがあらゆるパケット損失のときに排水することを引き起こして、回復するために遅れた出発動作を必要とするでしょう。最近、Fast RetransmitとFast Recoveryアルゴリズム[Jacobson90c]を導入しました。 それらの結合された効果は1窓あたり1回のパケット損失からパイプラインを排出しないで回復することです。 しかしながら、1窓あたり1回以上のパケット損失が再送タイムアウト、結果として起こるパイプライン排水、および遅れた出発を通常もたらします。
Expanding the window size to match the capacity of an LFN
results in a corresponding increase of the probability of
more than one packet per window being dropped. This could
have a devastating effect upon the throughput of TCP over an
LFN. In addition, if a congestion control mechanism based
upon some form of random dropping were introduced into
gateways, randomly spaced packet drops would become common,
possible increasing the probability of dropping more than one
packet per window.
LFNの容量を合わせるためにウィンドウサイズを広げると、1落とされる窓あたり1つ以上のパケットの確率の対応する増加はもたらされます。 これはLFNの上にTCPに関するスループットに破壊的な効果を持つかもしれません。 さらに、何らかのフォームの無作為の低下であることに基づく混雑制御機構がゲートウェイに紹介されるなら、手当たりしだいに区切られたパケット滴は、1つ以上のパケットを落とすという1窓あたりの確率に増加しながら、一般的で、可能になるでしょうに。
To generalize the Fast Retransmit/Fast Recovery mechanism to
handle multiple packets dropped per window, selective
acknowledgments are required. Unlike the normal cumulative
acknowledgments of TCP, selective acknowledgments give the
sender a complete picture of which segments are queued at the
receiver and which have not yet arrived. Some evidence in
favor of selective acknowledgments has been published
[NBS85], and selective acknowledgments have been included in
a number of experimental Internet protocols -- VMTP
[Cheriton88], NETBLT [Clark87], and RDP [Velten84], and
proposed for OSI TP4 [NBS85]. However, in the non-LFN
regime, selective acknowledgments reduce the number of
窓単位で落とされた複数のパケットを扱うためにFast Retransmit/速いRecoveryメカニズムを広めるために、選択している承認が必要です。 TCPの通常の累積している承認と異なって、選択している承認は完全な絵を送付者に与えます(セグメントが受信機に列に並ばせられて、まだ到着していません)。 選択している承認は多くの実験インターネットプロトコルに含まれています--選択している承認を支持して何らかの証拠が発表されて[NBS85]、VMTP[Cheriton88]、NETBLT[Clark87]、および[Velten84]の、そして、OSI TP4のために提案されたRDP[NBS85]。 しかしながら、非LFN政権では、選択している承認が数を減らします。
Jacobson, Braden, & Borman [Page 3] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[3ページ]RFC1323TCP拡張子
packets retransmitted but do not otherwise improve
performance, making their complexity of questionable value.
However, selective acknowledgments are expected to become
much more important in the LFN regime.
それらの疑わしい価値の複雑さを作って、パケットは、再送しますが、そうでなければ、性能を向上させません。 しかしながら、選択している承認がLFN政権ではるかに重要になると予想されます。
RFC-1072 defined a new TCP "SACK" option to send a selective
acknowledgment. However, there are important technical
issues to be worked out concerning both the format and
semantics of the SACK option. Therefore, SACK has been
omitted from this package of extensions. It is hoped that
SACK can "catch up" during the standardization process.
RFC-1072は、選択している承認を送るために新しいTCP「袋」オプションを定義しました。 しかしながら、形式とSACKオプションの意味論の両方に関して解決されるために、重要な専門的な問題があります。 したがって、SACKは拡大のこのパッケージから省略されました。 SACKが標準化過程の間「追いつくことができること」が望まれています。
(3) Round-Trip Measurement
(3) 往復の測定
TCP implements reliable data delivery by retransmitting
segments that are not acknowledged within some retransmission
timeout (RTO) interval. Accurate dynamic determination of an
appropriate RTO is essential to TCP performance. RTO is
determined by estimating the mean and variance of the
measured round-trip time (RTT), i.e., the time interval
between sending a segment and receiving an acknowledgment for
it [Jacobson88a].
TCPは、いくつかの再送タイムアウト(RTO)間隔以内に承認されないセグメントを再送することによって、確実な資料配送を実行します。 適切なRTOの正確なダイナミックな決断はTCP性能に不可欠です。 RTOは、測定往復の現代(RTT)(すなわち、それ[Jacobson88a]のためにセグメントを送って、承認を受けるところの時間間隔)の平均と変化を見積もっていることによって、決定します。
Section 4 introduces a new TCP option, "Timestamps", and then
defines a mechanism using this option that allows nearly
every segment, including retransmissions, to be timed at
negligible computational cost. We use the mnemonic RTTM
(Round Trip Time Measurement) for this mechanism, to
distinguish it from other uses of the Timestamps option.
セクション4は、新しいTCPオプション、「タイムスタンプ」を導入して、次に、ほとんどあらゆるセグメントを許容するこのオプションを使用することでメカニズムを定義します、取るにたらないコンピュータの費用で調節されるために「再-トランスミッション」を含んでいて。 私たちは、Timestampsオプションの他の用途とそれを区別するのに、このメカニズムのための簡略記憶RTTM(丸いTrip Time Measurement)を使用します。
1.2 TCP Reliability
1.2 TCPの信頼性
Now we turn from performance to reliability. High transfer rate
enters TCP performance through the bandwidth*delay product.
However, high transfer rate alone can threaten TCP reliability by
violating the assumptions behind the TCP mechanism for duplicate
detection and sequencing.
今、私たちは性能から信頼性にターンします。 高い転送レートは帯域幅*遅れ製品を通したTCP性能を入れます。 しかしながら、高い転送レートだけが、写し検出と配列のためにTCPメカニズムの後ろで仮定に違反することによって、TCPの信頼性を脅かすことができます。
An especially serious kind of error may result from an accidental
reuse of TCP sequence numbers in data segments. Suppose that an
"old duplicate segment", e.g., a duplicate data segment that was
delayed in Internet queues, is delivered to the receiver at the
wrong moment, so that its sequence numbers falls somewhere within
the current window. There would be no checksum failure to warn of
the error, and the result could be an undetected corruption of the
data. Reception of an old duplicate ACK segment at the
transmitter could be only slightly less serious: it is likely to
特に重大な種類の誤りはデータ・セグメントにおける、TCP一連番号の偶然の再利用から生じるかもしれません。 「古い写しセグメント」(例えばインターネット待ち行列で遅れた重複データセグメント)が間違った瞬間に受信機に渡されると仮定してください、一連番号が現在の窓の中のどこかまで下がるように。 誤りを警告しないチェックサムのことが全くないでしょう、そして、結果はデータの非検出された不正であるかもしれません。 送信機の古い写しACKセグメントのレセプションはわずかにだけ重大であったはずがありません: それはありそうです。
Jacobson, Braden, & Borman [Page 4] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[4ページ]RFC1323TCP拡張子
lock up the connection so that no further progress can be made,
forcing an RST on the connection.
接続にRSTを押しつけて、さらなる進歩を全く作ることができないように接続を監禁してください。
TCP reliability depends upon the existence of a bound on the
lifetime of a segment: the "Maximum Segment Lifetime" or MSL. An
MSL is generally required by any reliable transport protocol,
since every sequence number field must be finite, and therefore
any sequence number may eventually be reused. In the Internet
protocol suite, the MSL bound is enforced by an IP-layer
mechanism, the "Time-to-Live" or TTL field.
TCPの信頼性をセグメントの生涯のバウンドの存在に依存します: 「最大のセグメント生涯」かMSL。 一般に、MSLはどんな信頼できるトランスポート・プロトコルによっても必要とされます、あらゆる一連番号分野が有限であるに違いありません、そして、したがって、どんな一連番号も結局、再利用されるかもしれません。 インターネット・プロトコル群では、MSLバウンドがIP-層のメカニズム、「生きる時間」またはTTL分野によって励行されます。
Duplication of sequence numbers might happen in either of two
ways:
一連番号の複製は2つの方法のどちらかで起こるかもしれません:
(1) Sequence number wrap-around on the current connection
(1) 現在の接続での一連番号巻きつけて着るドレス
A TCP sequence number contains 32 bits. At a high enough
transfer rate, the 32-bit sequence space may be "wrapped"
(cycled) within the time that a segment is delayed in queues.
TCP一連番号は32ビットを含んでいます。 十分高い転送レートでは、32ビットの系列スペースはセグメントが待ち行列で遅れる時中に「包装されるかもしれない」(循環します)。
(2) Earlier incarnation of the connection
(2) 接続の以前の肉体化
Suppose that a connection terminates, either by a proper
close sequence or due to a host crash, and the same
connection (i.e., using the same pair of sockets) is
immediately reopened. A delayed segment from the terminated
connection could fall within the current window for the new
incarnation and be accepted as valid.
接続が適切な近い系列かホストクラッシュのため終わって、同じ接続(すなわち、ソケットの同じ組を使用する)がすぐに再開すると仮定してください。 終えられた接続からの遅れたセグメントは、新しい肉体化のために現在の窓の中で低下して、有効であるとして認めることができました。
Duplicates from earlier incarnations, Case (2), are avoided by
enforcing the current fixed MSL of the TCP spec, as explained in
Section 5.3 and Appendix B. However, case (1), avoiding the
reuse of sequence numbers within the same connection, requires an
MSL bound that depends upon the transfer rate, and at high enough
rates, a new mechanism is required.
以前の肉体化からの写し(Case(2))はTCP仕様の現在の固定MSLを実施することによって、避けられます、そして、同じ接続の中で一連番号の再利用を避けて、ケース(1)はセクション5.3とAppendix B.Howeverで説明されるように転送レートによるMSLバウンドを必要とします、そして、十分高いレートで、新しいメカニズムが必要です。
More specifically, if the maximum effective bandwidth at which TCP
is able to transmit over a particular path is B bytes per second,
then the following constraint must be satisfied for error-free
operation:
より明確に、TCPが特定の経路の上を伝わることができる最大の有効な帯域幅が1秒あたりBバイトであるなら、エラーのない操作のために以下の規制を満たさなければなりません:
2**31 / B > MSL (secs) [1]
2**31/B>MSL(secs)[1]
The following table shows the value for Twrap = 2**31/B in
seconds, for some important values of the bandwidth B:
以下のテーブルは、帯域幅Bのいくつかの重要な値のためにTwrapのための値が秒に2**31/Bと等しいのを示します:
Jacobson, Braden, & Borman [Page 5] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[5ページ]RFC1323TCP拡張子
Network B*8 B Twrap
bits/sec bytes/sec secs
_______ _______ ______ ______
ネットワークB*8B Twrapビット/秒バイト/秒のsecs_______ _______ ______ ______
ARPANET 56kbps 7KBps 3*10**5 (~3.6 days)
アルパネット56kbps 7KBps3*10**5(~3.6日間)
DS1 1.5Mbps 190KBps 10**4 (~3 hours)
DS1 1.5Mbps 190KBps10**4(~3時間)
Ethernet 10Mbps 1.25MBps 1700 (~30 mins)
イーサネット10Mbps 1.25MBps1700(~30mins)
DS3 45Mbps 5.6MBps 380
DS3 45Mbps 5.6MBps380
FDDI 100Mbps 12.5MBps 170
FDDI 100Mbps 12.5MBps170
Gigabit 1Gbps 125MBps 17
ギガビット1Gbps 125MBps17
It is clear that wrap-around of the sequence space is not a
problem for 56kbps packet switching or even 10Mbps Ethernets. On
the other hand, at DS3 and FDDI speeds, Twrap is comparable to the
2 minute MSL assumed by the TCP specification [Postel81]. Moving
towards gigabit speeds, Twrap becomes too small for reliable
enforcement by the Internet TTL mechanism.
系列スペースのその巻きつけて着るドレスが56kbpsパケット交換か10Mbps Ethernetsさえのためのあらゆる問題であることは明確ではありません。 他方では、DS3とFDDI速度では、TwrapはTCP仕様[Postel81]でMSLが仮定した2分に匹敵しています。 ギガビット速度に近づいて、TwrapはインターネットTTLメカニズムで信頼できる実施に小さくなり過ぎます。
The 16-bit window field of TCP limits the effective bandwidth B to
2**16/RTT, where RTT is the round-trip time in seconds
[McKenzie89]. If the RTT is large enough, this limits B to a
value that meets the constraint [1] for a large MSL value. For
example, consider a transcontinental backbone with an RTT of 60ms
(set by the laws of physics). With the bandwidth*delay product
limited to 64KB by the TCP window size, B is then limited to
1.1MBps, no matter how high the theoretical transfer rate of the
path. This corresponds to cycling the sequence number space in
Twrap= 2000 secs, which is safe in today's Internet.
TCPの16ビットの窓の分野は有効な帯域幅Bを2**16/RTTに制限します。そこでは、RTTが秒[McKenzie89]の往復の時間です。 RTTが十分大きいなら、これはBを大きいMSL値の規制[1]を満たす値に制限します。 例えば、60msのRTTがある大陸横断の背骨を考えてください(物理法則で、セットしてください)。 帯域幅*遅れ製品がTCPウィンドウサイズによって64KBに制限されている状態で、次に、Bは1.1MBpsに制限されます、経路の理論上の転送レートがどんなに高くても。 これは今日のインターネットで安全な2000Twrap=secsの一連番号スペースを循環させると対応しています。
It is important to understand that the culprit is not the larger
window but rather the high bandwidth. For example, consider a
(very large) FDDI LAN with a diameter of 10km. Using the speed of
light, we can compute the RTT across the ring as
(2*10**4)/(3*10**8) = 67 microseconds, and the delay*bandwidth
product is then 833 bytes. A TCP connection across this LAN using
a window of only 833 bytes will run at the full 100mbps and can
wrap the sequence space in about 3 minutes, very close to the MSL
of TCP. Thus, high speed alone can cause a reliability problem
with sequence number wrap-around, even without extended windows.
罪人がそうでないことを理解するために、窓にもかかわらず、むしろ高帯域が、より大きいのは、重要です。 例えば、10kmの直径がある(非常に大きい)のFDDI LANを考えてください。 光速を使用して、私たちがリングの向こう側にRTTを計算できる、(2、*10**4) /、(3 *10**8)は67マイクロセカンド等しく、そして、遅れ*帯域幅生成物は833バイトです。 833バイトだけの窓を使用するこのLANの向こう側のTCP関係は、完全な100mbpsを走って、TCPのMSLのおよそ3分非常に近く系列スペースを包むことができます。 したがって、高速だけが一連番号巻きつけて着るドレスと、そして、拡張窓なしでさえ信頼性の問題を引き起こす場合があります。
Watson's Delta-T protocol [Watson81] includes network-layer
mechanisms for precise enforcement of an MSL. In contrast, the IP
ワトソンのデルタ-Tプロトコル[Watson81]はMSLの正確な実施のためのネットワーク層メカニズムを含んでいます。 対照的に、IP
Jacobson, Braden, & Borman [Page 6] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[6ページ]RFC1323TCP拡張子
mechanism for MSL enforcement is loosely defined and even more
loosely implemented in the Internet. Therefore, it is unwise to
depend upon active enforcement of MSL for TCP connections, and it
is unrealistic to imagine setting MSL's smaller than the current
values (e.g., 120 seconds specified for TCP).
MSL実施のためのメカニズムは、緩く定義されて、インターネットで、より緩く実行さえされます。 したがって、TCP接続のためにMSLの活発な実施によるのが賢明でなく、現行価値より小さくMSLのものを設定すると想像するのは非現実的です(例えば120秒はTCPに指定しました)。
A possible fix for the problem of cycling the sequence space would
be to increase the size of the TCP sequence number field. For
example, the sequence number field (and also the acknowledgment
field) could be expanded to 64 bits. This could be done either by
changing the TCP header or by means of an additional option.
系列スペースを循環させるという問題のための可能なフィックスはTCP一連番号分野のサイズを増加させるだろうことです。 例えば、一連番号分野(そして、承認分野も)を64ビットに広げることができました。 TCPヘッダーを変えるか、追加オプションによってこれができました。
Section 5 presents a different mechanism, which we call PAWS
(Protect Against Wrapped Sequence numbers), to extend TCP
reliability to transfer rates well beyond the foreseeable upper
limit of network bandwidths. PAWS uses the TCP Timestamps option
defined in Section 4 to protect against old duplicates from the
same connection.
セクション5は、ネットワーク回線容量の予見できる上限を超えてレートをよく移すためにTCPの信頼性を広げるために、異なったメカニズムを提示します。(私たちはそれをPAWS(Against Wrapped Sequence番号を保護する)と呼びます)。 PAWSは同じ接続から古い写しから守るためにセクション4で定義されたTCP Timestampsオプションを使用します。
1.3 Using TCP options
1.3 TCPオプションを使用すること。
The extensions defined in this memo all use new TCP options. We
must address two possible issues concerning the use of TCP
options: (1) compatibility and (2) overhead.
このメモで定義された拡大はすべて、新しいTCPオプションを使用します。 私たちはTCPオプションの使用に関して可能な2冊を記述しなければなりません: (1) 互換性と(2)オーバーヘッド。
We must pay careful attention to compatibility, i.e., to
interoperation with existing implementations. The only TCP option
defined previously, MSS, may appear only on a SYN segment. Every
implementation should (and we expect that most will) ignore
unknown options on SYN segments. However, some buggy TCP
implementation might be crashed by the first appearance of an
option on a non-SYN segment. Therefore, for each of the
extensions defined below, TCP options will be sent on non-SYN
segments only when an exchange of options on the SYN segments has
indicated that both sides understand the extension. Furthermore,
an extension option will be sent in a <SYN,ACK> segment only if
the corresponding option was received in the initial <SYN>
segment.
私たちは既存の実現と共にすなわち、互換性、interoperationへの慎重な注意を向けなければなりません。 以前に定義された唯一のTCPオプション(MSS)がSYNセグメントだけに現れるかもしれません。 あらゆる実現がSYNセグメントで未知のオプションを無視するべきです(私たちは、大部分がそうすると予想します)。 しかしながら、何らかのバギーのTCP実現が非SYNセグメントにおけるオプションの初登場で墜落するかもしれません。 したがって、以下で定義されたそれぞれの拡大において、SYNセグメントにおけるオプションの交換が、両側が拡大を理解しているのを示したときだけ、非SYNセグメントでTCPオプションを送るでしょう。 その上、<SYNで拡大オプションを送って、対応するオプションである場合にだけ初期の<SYN>セグメントでACK>セグメントを受け取りました。
A question may be raised about the bandwidth and processing
overhead for TCP options. Those options that occur on SYN
segments are not likely to cause a performance concern. Opening a
TCP connection requires execution of significant special-case
code, and the processing of options is unlikely to increase that
cost significantly.
疑問はTCPオプションのために帯域幅と処理オーバヘッドに関して引き起こされるかもしれません。 SYNセグメントに起こるそれらのオプションは性能心配をかけそうにはありません。 TCP接続を開くのは重要な特別なケースコードの実行を必要とします、そして、オプションの処理はその費用をかなり上げそうにはありません。
On the other hand, a Timestamps option may appear in any data or
ACK segment, adding 12 bytes to the 20-byte TCP header. We
他方では、TimestampsオプションはどんなデータやACKセグメントにも現れるかもしれません、20バイトのTCPヘッダーに12バイトを加えて。 私たち
Jacobson, Braden, & Borman [Page 7] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[7ページ]RFC1323TCP拡張子
believe that the bandwidth saved by reducing unnecessary
retransmissions will more than pay for the extra header bandwidth.
不要な「再-トランスミッション」を減少させることによって救われた帯域幅が余分なヘッダー帯域幅のための賃金よりそうすると信じてください。
There is also an issue about the processing overhead for parsing
the variable byte-aligned format of options, particularly with a
RISC-architecture CPU. To meet this concern, Appendix A contains
a recommended layout of the options in TCP headers to achieve
reasonable data field alignment. In the spirit of Header
Prediction, a TCP can quickly test for this layout and if it is
verified then use a fast path. Hosts that use this canonical
layout will effectively use the options as a set of fixed-format
fields appended to the TCP header. However, to retain the
philosophical and protocol framework of TCP options, a TCP must be
prepared to parse an arbitrary options field, albeit with less
efficiency.
また、オプションの可変バイトで並べられた形式を分析するための処理オーバヘッドに関する問題があります、特にRISC構造CPUで。 この関心を満たすなら、Appendix Aは、合理的なデータ・フィールド整列を達成するためにTCPヘッダーにオプションのお勧めのレイアウトを含んでいます。 Header Predictionの精神では、TCPはこのレイアウトとそれが確かめられた当時の使用であるかどうかがないかどうかすぐに高速経路をテストできます。 事実上、この正準なレイアウトを使用するホストがTCPヘッダーに追加された1セットの固定フォーマット野原としてオプションを使用するでしょう。 しかしながら、TCPオプションの哲学的、そして、プロトコル枠組みを保有するために、任意のオプション分野を分析するようにTCPを準備しなければなりません、より少ない効率で。
Finally, we observe that most of the mechanisms defined in this
memo are important for LFN's and/or very high-speed networks. For
low-speed networks, it might be a performance optimization to NOT
use these mechanisms. A TCP vendor concerned about optimal
performance over low-speed paths might consider turning these
extensions off for low-speed paths, or allow a user or
installation manager to disable them.
最終的に、私たちは、LFNのもの、そして/または、非常に高速なネットワークに、このメモで定義されたメカニズムの大部分が重要であることを観測します。 低速ネットワークにおいて、それは、これらのメカニズムを使用しないためにはパフォーマンスの最適化であるかもしれません。低速経路の上の最適の性能に関して心配しているTCP業者は、ユーザかインストールマネージャがそれらを無能にするのをこれらの拡大を低速経路にオフにすると考えるか、または許すかもしれません。
2. TCP WINDOW SCALE OPTION
2. TCP窓のスケールオプション
2.1 Introduction
2.1 序論
The window scale extension expands the definition of the TCP
window to 32 bits and then uses a scale factor to carry this 32-
bit value in the 16-bit Window field of the TCP header (SEG.WND in
RFC-793). The scale factor is carried in a new TCP option, Window
Scale. This option is sent only in a SYN segment (a segment with
the SYN bit on), hence the window scale is fixed in each direction
when a connection is opened. (Another design choice would be to
specify the window scale in every TCP segment. It would be
incorrect to send a window scale option only when the scale factor
changed, since a TCP option in an acknowledgement segment will not
be delivered reliably (unless the ACK happens to be piggy-backed
on data in the other direction). Fixing the scale when the
connection is opened has the advantage of lower overhead but the
disadvantage that the scale factor cannot be changed during the
connection.)
窓のスケール拡大は、TCPの窓の定義を32ビットに広げて、次に、TCPヘッダー(RFC-793のSEG.WND)の16ビットのWindow分野でこの32の噛み付いている値を運ぶのに位取り因数を使用します。 Window Scale、位取り因数は新しいTCPオプションで運ばれます。 SYNセグメント(SYNビットがオンのセグメント)だけでこのオプションを送ります、接続を開くとき、したがって、各方向に窓のスケールを固定します。 (別のデザイン選択はあらゆるTCPセグメントで窓のスケールを指定するだろうことです。 位取り因数が変化したときのだけ窓のスケールオプションを送るのは不正確でしょう、承認セグメントにおけるTCPオプションが確かに提供されないので(ACKがもう片方の指示のデータでたまたま便乗しない場合)。 接続が開かれるときスケールを固定するのにおいて、低いオーバーヘッドの利点がありますが、接続の間スケールが因数分解する不都合を変えることができません。)
The maximum receive window, and therefore the scale factor, is
determined by the maximum receive buffer space. In a typical
modern implementation, this maximum buffer space is set by default
最大は窓を受けます、そして、したがって、位取り因数は最大の受信バッファスペースのそばで決定しています。 典型的な現代の実現では、この最大のバッファ領域はデフォルトで設定されます。
Jacobson, Braden, & Borman [Page 8] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[8ページ]RFC1323TCP拡張子
but can be overridden by a user program before a TCP connection is
opened. This determines the scale factor, and therefore no new
user interface is needed for window scaling.
しかし、TCP接続が開かれる前にユーザ・プログラムでくつがえすことができます。 これは、位取り因数を必要としますが、したがって、どんな新しいユーザーインタフェースも窓のスケーリングに必要でないことを決定します。
2.2 Window Scale Option
2.2 窓のスケールオプション
The three-byte Window Scale option may be sent in a SYN segment by
a TCP. It has two purposes: (1) indicate that the TCP is prepared
to do both send and receive window scaling, and (2) communicate a
scale factor to be applied to its receive window. Thus, a TCP
that is prepared to scale windows should send the option, even if
its own scale factor is 1. The scale factor is limited to a power
of two and encoded logarithmically, so it may be implemented by
binary shift operations.
3バイトのWindow ScaleオプションはSYNセグメントでTCPによって送られるかもしれません。 それには、2つの目的があります: (1) (2) TCPがともに窓のスケーリングを送って、受けるように準備されるのを示してくださいといって、適用される位取り因数を伝えてください、それ、窓を受けてください。 したがって、窓をスケーリングするように準備されるTCPはオプションを送るはずです、それ自身の位取り因数が1であっても。 位取り因数が2のパワーに制限されて、対数関数的にコード化されるので、それは2進の交替制で実行されるかもしれません。
TCP Window Scale Option (WSopt):
TCP窓のスケールオプション(WSopt):
Kind: 3 Length: 3 bytes
種類: 3の長さ: 3バイト
+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+
+---------+---------+---------+ | 種類=3|長さ=3|shift.cnt| +---------+---------+---------+
This option is an offer, not a promise; both sides must send
Window Scale options in their SYN segments to enable window
scaling in either direction. If window scaling is enabled,
then the TCP that sent this option will right-shift its true
receive-window values by 'shift.cnt' bits for transmission in
SEG.WND. The value 'shift.cnt' may be zero (offering to scale,
while applying a scale factor of 1 to the receive window).
このオプションは約束ではなく、申し出です。 両側は、どちらの指示も計量する窓を可能にするためにそれらのSYNセグメントでオプションをWindow Scaleに送らなければなりません。 窓のスケーリングが可能にされると、このオプションを送ったTCPはSEG.WNDのトランスミッションのための'shift.cnt'ビットの本当の窓を受信している値を権利で移動させるでしょう。 値の'shift.cnt'がゼロであるかもしれない、(1の位取り因数を適用している間、比例すると申し出る、受信、窓)
This option may be sent in an initial <SYN> segment (i.e., a
segment with the SYN bit on and the ACK bit off). It may also
be sent in a <SYN,ACK> segment, but only if a Window Scale op-
tion was received in the initial <SYN> segment. A Window Scale
option in a segment without a SYN bit should be ignored.
初期の<SYN>セグメント(すなわち、SYNビットがオンであり、ACKビットが下にあるセグメント)でこのオプションを送るかもしれません。 また、<SYNでそれを送るかもしれません、ACK>セグメント、しかし、Window Scaleオプアートである場合にだけ、初期の<SYN>セグメントでtionを受け取りました。 SYNビットのないセグメントにおけるWindow Scaleオプションは無視されるべきです。
The Window field in a SYN (i.e., a <SYN> or <SYN,ACK>) segment
itself is never scaled.
SYN(すなわち、<SYN>か<SYN、ACK>)セグメント自体のWindow分野は決してスケーリングされません。
2.3 Using the Window Scale Option
2.3 窓のスケールオプションを使用すること。
A model implementation of window scaling is as follows, using the
notation of RFC-793 [Postel81]:
RFC-793[Postel81]の記法を使用して、窓のスケーリングのモデル実現は以下の通りです:
* All windows are treated as 32-bit quantities for storage in
* すべての窓が格納のために中で32ビットの量として扱われます。
Jacobson, Braden, & Borman [Page 9] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[9ページ]RFC1323TCP拡張子
the connection control block and for local calculations.
This includes the send-window (SND.WND) and the receive-
window (RCV.WND) values, as well as the congestion window.
接続制御ブロックとローカルな計算のために。 そして、これが、窓を発信させるのを(SND.WND)含んでいる、窓(RCV.WND)の値、および混雑ウィンドウを受けてください。
* The connection state is augmented by two window shift counts,
Snd.Wind.Scale and Rcv.Wind.Scale, to be applied to the
incoming and outgoing window fields, respectively.
* 2ウィンドウの桁送り数、Snd.Wind.Scale、およびRcv.Wind.Scaleは、それぞれ送受信の窓の分野に適用されるために接続状態を増大させます。
* If a TCP receives a <SYN> segment containing a Window Scale
option, it sends its own Window Scale option in the <SYN,ACK>
segment.
* TCPがWindow Scaleオプションを含む<SYN>セグメントを受けるなら、それは<SYN(ACK>セグメント)のそれ自身のWindow Scaleオプションを送ります。
* The Window Scale option is sent with shift.cnt = R, where R
is the value that the TCP would like to use for its receive
window.
* shift.cnt=Rと共にRがTCPが使用したがっている値であるところにWindow Scaleオプションを送る、それ、窓を受けてください。
* Upon receiving a SYN segment with a Window Scale option
containing shift.cnt = S, a TCP sets Snd.Wind.Scale to S and
sets Rcv.Wind.Scale to R; otherwise, it sets both
Snd.Wind.Scale and Rcv.Wind.Scale to zero.
* Window Scaleオプションがshift.cnt=Sを含んでいてSYNセグメントを受けると、TCPはSにSnd.Wind.Scaleを設定して、RにRcv.Wind.Scaleを設定します。 さもなければ、それはSnd.Wind.ScaleとRcv.Wind.Scaleの両方をゼロに設定します。
* The window field (SEG.WND) in the header of every incoming
segment, with the exception of SYN segments, is left-shifted
by Snd.Wind.Scale bits before updating SND.WND:
* SYNセグメント以外のあらゆる入って来るセグメントのヘッダーの窓の分野(SEG.WND)はSND.WNDをアップデートする前の左でSnd.Wind.Scaleによって移動させられたビットです:
SND.WND = SEG.WND << Snd.Wind.Scale
SND.WNDはSEG.WND<<Snd.Wind.Scaleと等しいです。
(assuming the other conditions of RFC793 are met, and using
the "C" notation "<<" for left-shift).
(左シフトのために、RFC793が会われて、「C」記法「<<」を使用するという他の条件を仮定します。)
* The window field (SEG.WND) of every outgoing segment, with
the exception of SYN segments, is right-shifted by
Rcv.Wind.Scale bits:
* SYNセグメント以外のあらゆる外向的なセグメントの窓の分野(SEG.WND)はRcv.Wind.Scaleビットによってまさしく移行されています:
SEG.WND = RCV.WND >> Rcv.Wind.Scale.
SEG.WNDはRCV.WND>>Rcv.Wind.Scaleと等しいです。
TCP determines if a data segment is "old" or "new" by testing
whether its sequence number is within 2**31 bytes of the left edge
of the window, and if it is not, discarding the data as "old". To
insure that new data is never mistakenly considered old and vice-
versa, the left edge of the sender's window has to be at most
2**31 away from the right edge of the receiver's window.
Similarly with the sender's right edge and receiver's left edge.
Since the right and left edges of either the sender's or
receiver's window differ by the window size, and since the sender
and receiver windows can be out of phase by at most the window
size, the above constraints imply that 2 * the max window size
TCPはデータ・セグメントが窓の左の縁で2**の中に一連番号が31バイトあるか否かに関係なく、テストすることによって「古い」か「新しく」、それが新しくないかどうか決定します、「古い」としてデータを捨てて。 新しいデータが古い、そして、副versaであることは誤って決して考えられないのを保障するために、送付者の窓の左の縁が高々受信機の窓の正しい縁から31遠くの2**でなければなりません。 同様に、送付者と共に、正しい縁と受信機は縁を出ました。 送付者か受信機の窓の左右な縁がウィンドウサイズで異なって、送付者と受信機の窓が高々ウィンドウサイズでフェーズから脱できるので、上の規制がその2*を含意する、最大ウィンドウサイズ
Jacobson, Braden, & Borman [Page 10] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[10ページ]RFC1323TCP拡張子
must be less than 2**31, or
または2**以下が31であったならそうしなければならない。
max window < 2**30
最大窓の<2**30
Since the max window is 2**S (where S is the scaling shift count)
times at most 2**16 - 1 (the maximum unscaled window), the maximum
window is guaranteed to be < 2*30 if S <= 14. Thus, the shift
count must be limited to 14 (which allows windows of 2**30 = 1
Gbyte). If a Window Scale option is received with a shift.cnt
value exceeding 14, the TCP should log the error but use 14
instead of the specified value.
最大ウィンドウがほとんどの2**16--1(最大の非スケーリングされた窓)の2**S(Sがスケーリング桁送り数であるところ)回であるので、最大の窓はS<=14であるなら<2*30になるように保証されます。 したがって、桁送り数を14に制限しなければなりません(2**30 = 1ギガバイトの窓を許容します)。 shift.cnt値が14を超えていてWindow Scaleオプションを受け取るなら、TCPは誤りを登録しますが、規定値の代わりに14を使用するはずです。
The scale factor applies only to the Window field as transmitted
in the TCP header; each TCP using extended windows will maintain
the window values locally as 32-bit numbers. For example, the
"congestion window" computed by Slow Start and Congestion
Avoidance is not affected by the scale factor, so window scaling
will not introduce quantization into the congestion window.
位取り因数はTCPヘッダーで伝えられるようにWindow分野だけに適用されます。 拡張窓を使用する各TCPは、窓が局所的に32ビットの数を重んじると主張するでしょう。 例えば、Slow StartとCongestion Avoidanceによって計算された「混雑ウィンドウ」が位取り因数で影響を受けないので、窓のスケーリングは混雑ウィンドウに量子化を導入しないでしょう。
3. RTTM: ROUND-TRIP TIME MEASUREMENT
3. RTTM: 往復の時間測定
3.1 Introduction
3.1 序論
Accurate and current RTT estimates are necessary to adapt to
changing traffic conditions and to avoid an instability known as
"congestion collapse" [Nagle84] in a busy network. However,
accurate measurement of RTT may be difficult both in theory and in
implementation.
正確で現在のRTT見積りが、交通状況を変えるのに適合して、「混雑崩壊」[Nagle84]として忙しいネットワークで知られている不安定性を避けるのに必要です。 しかしながら、RTTの正確な寸法は理論上と実現で難しいかもしれません。
Many TCP implementations base their RTT measurements upon a sample
of only one packet per window. While this yields an adequate
approximation to the RTT for small windows, it results in an
unacceptably poor RTT estimate for an LFN. If we look at RTT
estimation as a signal processing problem (which it is), a data
signal at some frequency, the packet rate, is being sampled at a
lower frequency, the window rate. This lower sampling frequency
violates Nyquist's criteria and may therefore introduce "aliasing"
artifacts into the estimated RTT [Hamming77].
多くのTCP実現がそれらのRTT測定値を1窓あたり1つのパケットだけのサンプルに基礎づけます。 これは小さい窓のために適切な近似をRTTに譲りますが、それはLFNに、容認できないほど不十分なRTT見積りをもたらします。 私たちが信号加工上の問題(それがそうである)としてRTT見積りを見るなら、何らかの頻度におけるデータ信号(パケットレート)は下側の頻度(窓のレート)で抽出されています。 この下側のサンプリング周波数は、Nyquistの評価基準に違反して、したがって、およそRTT[Hamming77]に「エイリアシング」人工物を紹介するかもしれません。
A good RTT estimator with a conservative retransmission timeout
calculation can tolerate aliasing when the sampling frequency is
"close" to the data frequency. For example, with a window of 8
packets, the sample rate is 1/8 the data frequency -- less than an
order of magnitude different. However, when the window is tens or
hundreds of packets, the RTT estimator may be seriously in error,
resulting in spurious retransmissions.
サンプリング周波数が「近いところにデータ頻度の」あるとき、保守的な再送タイムアウト計算の良いRTT見積り人はエイリアシングを許容できます。 例えば、8つのパケットの窓、見本郵送料率と共に、1/8があります。データ頻度--1桁の異なるよりそれほど。 しかしながら、窓が10か何百ものパケットであるときに、RTT見積り人は真剣に間違うかもしれません、偽物の「再-トランスミッション」をもたらして。
If there are dropped packets, the problem becomes worse. Zhang
パケットが落とされるなら、問題は、より悪くなります。 チャン
Jacobson, Braden, & Borman [Page 11] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[11ページ]RFC1323TCP拡張子
[Zhang86], Jain [Jain86] and Karn [Karn87] have shown that it is
not possible to accumulate reliable RTT estimates if retransmitted
segments are included in the estimate. Since a full window of
data will have been transmitted prior to a retransmission, all of
the segments in that window will have to be ACKed before the next
RTT sample can be taken. This means at least an additional
window's worth of time between RTT measurements and, as the error
rate approaches one per window of data (e.g., 10**-6 errors per
bit for the Wideband satellite network), it becomes effectively
impossible to obtain a valid RTT measurement.
再送されたセグメントが見積りに含まれているなら、[Zhang86]、ジャイナ教の[Jain86]、およびKarn[Karn87]は、信頼できるRTT見積りを蓄積するのが可能でないことを示しました。 データの完全な窓が「再-トランスミッション」の前に伝えられてしまうだろうので、次のRTTのサンプルを取ることができる前に、その窓のセグメントのすべてがACKedにならなければならないでしょう。 これはRTT測定値の間で少なくとも追加窓の倍の価値を意味します、そして、誤り率がデータ(例えば、Wideband衛星ネットワークのためのビットあたり10**-6つの誤り)の窓あたり1つにアプローチするのに従って、有効なRTT測定を得るのは事実上、不可能になります。
A solution to these problems, which actually simplifies the sender
substantially, is as follows: using TCP options, the sender places
a timestamp in each data segment, and the receiver reflects these
timestamps back in ACK segments. Then a single subtract gives the
sender an accurate RTT measurement for every ACK segment (which
will correspond to every other data segment, with a sensible
receiver). We call this the RTTM (Round-Trip Time Measurement)
mechanism.
これらの問題の解決(実際に実質的に送付者を簡素化する)は以下の通りです: TCPオプションを使用して、送付者は各データ・セグメントにタイムスタンプを置きます、そして、受信機はACKセグメントでこれらのタイムスタンプを映し出します。 シングルが引き算するその時はあらゆるACKセグメント(分別がある受信機で他のあらゆるデータ・セグメントに対応する)のための正確なRTT測定を送付者に与えます。 私たちは、これをRTTM(丸い旅行Time Measurement)メカニズムと呼びます。
It is vitally important to use the RTTM mechanism with big
windows; otherwise, the door is opened to some dangerous
instabilities due to aliasing. Furthermore, the option is
probably useful for all TCP's, since it simplifies the sender.
大きい窓があるRTTMメカニズムを使用するのはきわめて重要です。 さもなければ、ドアはエイリアシングによるいくつかの危険な不安定性に開けられます。 その上、送付者を簡素化するので、オプションはたぶんTCPのすべてのものの役に立ちます。
3.2 TCP Timestamps Option
3.2 TCPタイムスタンプオプション
TCP is a symmetric protocol, allowing data to be sent at any time
in either direction, and therefore timestamp echoing may occur in
either direction. For simplicity and symmetry, we specify that
timestamps always be sent and echoed in both directions. For
efficiency, we combine the timestamp and timestamp reply fields
into a single TCP Timestamps Option.
TCPが左右対称のプロトコルである、データはどちらの指示もいつでも、送られて、したがって、タイムスタンプ反響を送られるのを許容するのがどちらの方向にも起こるかもしれません。 簡単さと対称として、私たちはタイムスタンプがいつも両方の方向に送られて、反映されると指定します。 効率のために、私たちはタイムスタンプとタイムスタンプ回答分野を独身のTCP Timestamps Optionに結合します。
Jacobson, Braden, & Borman [Page 12] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[12ページ]RFC1323TCP拡張子
TCP Timestamps Option (TSopt):
TCPタイムスタンプオプション(TSopt):
Kind: 8
種類: 8
Length: 10 bytes
長さ: 10バイト
+-------+-------+---------------------+---------------------+
|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
+-------+-------+---------------------+---------------------+
1 1 4 4
+-------+-------+---------------------+---------------------+ |種類=8| 10 | tは(TSval)を評価します。|tは回答(TSecr)をまねます。| +-------+-------+---------------------+---------------------+ 1 1 4 4
The Timestamps option carries two four-byte timestamp fields.
The Timestamp Value field (TSval) contains the current value of
the timestamp clock of the TCP sending the option.
Timestampsオプションは2つの4バイトのタイムスタンプ野原を運びます。 Timestamp Value分野(TSval)はオプションを送るTCPのタイムスタンプ時計の現行価値を含んでいます。
The Timestamp Echo Reply field (TSecr) is only valid if the ACK
bit is set in the TCP header; if it is valid, it echos a times-
tamp value that was sent by the remote TCP in the TSval field
of a Timestamps option. When TSecr is not valid, its value
must be zero. The TSecr value will generally be from the most
recent Timestamp option that was received; however, there are
exceptions that are explained below.
ACKビットがTCPヘッダーに設定される場合にだけ、Timestamp Echo Reply分野(TSecr)は有効です。 有効であるなら、それはこだまします。回はTimestampsオプションのTSval分野のリモートTCPによって送られた値を詰めます。 TSecrが有効でないときに、値はゼロでなければなりません。 一般に、TSecr値は受け取られた最新のTimestampオプションから来ているでしょう。 しかしながら、以下で説明される例外があります。
A TCP may send the Timestamps option (TSopt) in an initial
<SYN> segment (i.e., segment containing a SYN bit and no ACK
bit), and may send a TSopt in other segments only if it re-
ceived a TSopt in the initial <SYN> segment for the connection.
TCPは初期の<SYN>セグメント(すなわち、SYNビットを含んでいますが、どんなACKビットも含まないセグメント)でTimestampsオプション(TSopt)を送って、それが接続のために初期の<SYN>セグメントでTSoptを再ceivedした場合にだけ、他のセグメントでTSoptを送るかもしれません。
3.3 The RTTM Mechanism
3.3 RTTMメカニズム
The timestamp value to be sent in TSval is to be obtained from a
(virtual) clock that we call the "timestamp clock". Its values
must be at least approximately proportional to real time, in order
to measure actual RTT.
TSvalで送られるタイムスタンプ値は私たちが「タイムスタンプ時計」と呼ぶ(仮想)の時計から得ることです。 値は、実際のRTTを測定するためにリアルタイムで少なくともほとんど比例していなければなりません。
The following example illustrates a one-way data flow with
segments arriving in sequence without loss. Here A, B, C...
represent data blocks occupying successive blocks of sequence
numbers, and ACK(A),... represent the corresponding cumulative
acknowledgments. The two timestamp fields of the Timestamps
option are shown symbolically as <TSval= x,TSecr=y>. Each TSecr
field contains the value most recently received in a TSval field.
以下の例は損失なしで連続して到着するセグメントを片道データフローに入れます。 ここ、A、B、C. 連続したブロックの一連番号を占領するデータ・ブロック、およびACK(A)を表してください… 対応する累積している承認を表してください。 Timestampsオプションの2つのタイムスタンプ分野が<TSval= x、TSecr=y>として象徴的に示されます。 それぞれのTSecr分野はごく最近TSval分野に受け取られた値を含んでいます。
Jacobson, Braden, & Borman [Page 13] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[13ページ]RFC1323TCP拡張子
TCP A TCP B
TCPはTCP Bです。
<A,TSval=1,TSecr=120> ------>
<A、TSval=1、TSecr=120>。------>。
<---- <ACK(A),TSval=127,TSecr=1>
<。---- <ACK(A)、TSval=127、TSecr=1>。
<B,TSval=5,TSecr=127> ------>
<B、TSval=5、TSecr=127>。------>。
<---- <ACK(B),TSval=131,TSecr=5>
<。---- <ACK(B)、TSval=131、TSecr=5>。
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
<C,TSval=65,TSecr=131> ------>
<C、TSval=65、TSecr=131>。------>。
<---- <ACK(C),TSval=191,TSecr=65>
<。---- <ACK(C)、TSval=191、TSecr=65>。
(etc)
(など)
The dotted line marks a pause (60 time units long) in which A had
nothing to send. Note that this pause inflates the RTT which B
could infer from receiving TSecr=131 in data segment C. Thus, in
one-way data flows, RTTM in the reverse direction measures a value
that is inflated by gaps in sending data. However, the following
rule prevents a resulting inflation of the measured RTT:
点線はAが何も送るものを持っていなかったくぎり(60長さタイム・ユニットの)をマークします。 このくぎりがRTTをふくらませるというBがデータ・セグメントC.Thus、片道データフローでTSecr=131を受けるので推論できたメモ、反対の方向へのRTTMはギャップによってデータを送る際にふくらませられる値を測定します。 しかしながら、以下の規則は測定RTTの結果として起こるインフレーションを防ぎます:
A TSecr value received in a segment is used to update the
averaged RTT measurement only if the segment acknowledges
some new data, i.e., only if it advances the left edge of the
send window.
すなわち、左の縁を進める場合にだけセグメントがいくつかの新しいデータを承認する場合にだけセグメントのA TSecr対価領収が平均したRTT測定をアップデートするのに使用される、窓を送ってください。
Since TCP B is not sending data, the data segment C does not
acknowledge any new data when it arrives at B. Thus, the inflated
RTTM measurement is not used to update B's RTTM measurement.
TCP Bがデータを送らないので、B.Thusに到着する場合、データ・セグメントCは少しの新しいデータも承認しないで、また充満しているRTTM測定はビーズのRTTM測定をアップデートするのに使用されません。
3.4 Which Timestamp to Echo
3.4 反響するどのタイムスタンプ
If more than one Timestamps option is received before a reply
segment is sent, the TCP must choose only one of the TSvals to
echo, ignoring the others. To minimize the state kept in the
receiver (i.e., the number of unprocessed TSvals), the receiver
should be required to retain at most one timestamp in the
connection control block.
回答セグメントを送る前に1つ以上のTimestampsオプションが受け取られているなら、TCPは反響するようにTSvalsについて1つだけを選ばなければなりません、他のものを無視して。 受信機(すなわち、未加工のTSvalsの数)に維持された状態を最小にするために、受信機は接続制御ブロックの1つのタイムスタンプを高々保有するべきでなければなりません。
Jacobson, Braden, & Borman [Page 14] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[14ページ]RFC1323TCP拡張子
There are three situations to consider:
考える3つの状況があります:
(A) Delayed ACKs.
(A) ACKsを遅らせました。
Many TCP's acknowledge only every Kth segment out of a group
of segments arriving within a short time interval; this
policy is known generally as "delayed ACKs". The data-sender
TCP must measure the effective RTT, including the additional
time due to delayed ACKs, or else it will retransmit
unnecessarily. Thus, when delayed ACKs are in use, the
receiver should reply with the TSval field from the earliest
unacknowledged segment.
TCPの多くのものが短い時間間隔以内に到着するセグメントのグループからあらゆるだけKthセグメントを承認します。 一般に、この方針は「遅れたACKs」として知られています。 データ送付者TCPが遅れたACKsのため追加時間を含む有効なRTTを測定しなければならない、さもなければ、それは不必要に再送されるでしょう。 遅れたACKsが使用中であるときに、したがって、受信機はTSval分野で最も早い不承認のセグメントから返答するはずです。
(B) A hole in the sequence space (segment(s) have been lost).
(B) 系列スペース(セグメントは失われた)の穴。
The sender will continue sending until the window is filled,
and the receiver may be generating ACKs as these out-of-order
segments arrive (e.g., to aid "fast retransmit").
窓がいっぱいにされるまで、送付者は、発信し続けるでしょう、そして、これらの不適切なセグメントが到着するのに応じて(例えば「速く再送してください」を支援する)、受信機はACKsを発生させているかもしれません。
The lost segment is probably a sign of congestion, and in
that situation the sender should be conservative about
retransmission. Furthermore, it is better to overestimate
than underestimate the RTT. An ACK for an out-of-order
segment should therefore contain the timestamp from the most
recent segment that advanced the window.
無くなっているセグメントはたぶん混雑のサインです、そして、その状況で、送付者は「再-トランスミッション」に関して保守的であるべきです。 その上、それは、過大評価するためにRTTを過小評価するより良いです。 したがって、不適切なセグメントのためのACKは窓を進めた最新のセグメントからのタイムスタンプを含むはずです。
The same situation occurs if segments are re-ordered by the
network.
セグメントがネットワークによって再命令されるなら、同じ状況は起こります。
(C) A filled hole in the sequence space.
(C) 系列スペースのいっぱいにされた穴。
The segment that fills the hole represents the most recent
measurement of the network characteristics. On the other
hand, an RTT computed from an earlier segment would probably
include the sender's retransmit time-out, badly biasing the
sender's average RTT estimate. Thus, the timestamp from the
latest segment (which filled the hole) must be echoed.
穴をふさぐセグメントはネットワークの特性の最新の測定を表します。 他方では、以前のセグメントから計算されたRTTは、たぶんタイムアウトを再送して、ひどく送付者の平均したRTT見積りに偏りながら、送付者のものを含んでいるでしょう。 したがって、最新のセグメント(穴をふさいだ)からのタイムスタンプを反映しなければなりません。
An algorithm that covers all three cases is described in the
following rules for Timestamps option processing on a synchronized
connection:
すべての3つのケースをカバーするアルゴリズムは連動している接続のときにTimestampsオプション処理のための以下の規則で説明されます:
(1) The connection state is augmented with two 32-bit slots:
TS.Recent holds a timestamp to be echoed in TSecr whenever a
segment is sent, and Last.ACK.sent holds the ACK field from
the last segment sent. Last.ACK.sent will equal RCV.NXT
except when ACKs have been delayed.
(1) 接続状態は2つの32ビットのスロットで増大します: セグメントを送るときはいつも、TS.RecentはTSecrで反響されるようにタイムスタンプを保持します、そして、Last.ACK.sentは最後のセグメントからのACK野原が送られるままにします。 ACKsが遅れた時を除いて、Last.ACK.sentはRCV.NXTと等しいでしょう。
Jacobson, Braden, & Borman [Page 15] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[15ページ]RFC1323TCP拡張子
(2) If Last.ACK.sent falls within the range of sequence numbers
of an incoming segment:
(2) Last.ACK.sentが入って来るセグメントの一連番号の範囲の中に落ちるなら:
SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN
SEG.SEQ<はLast.ACK.sent<SEG.SEQ+SEG.LENと等しいです。
then the TSval from the segment is copied to TS.Recent;
otherwise, the TSval is ignored.
次に、セグメントからのTSvalはTS.Recentにコピーされます。 さもなければ、TSvalは無視されます。
(3) When a TSopt is sent, its TSecr field is set to the current
TS.Recent value.
(3) TSoptを送るとき、現在のTS.Recent値にTSecr分野を設定します。
The following examples illustrate these rules. Here A, B, C...
represent data segments occupying successive blocks of sequence
numbers, and ACK(A),... represent the corresponding
acknowledgment segments. Note that ACK(A) has the same sequence
number as B. We show only one direction of timestamp echoing, for
clarity.
以下の例はこれらの規則を例証します。 ここ、A、B、C. 連続したブロックの一連番号、およびACK(A)を占領するデータ・セグメントを表してください… 対応する確認応答セグメントを表してください。 B.Weがタイムスタンプ反響の一方向だけを示している明快によってACK(A)には同じ一連番号があることに注意してください。
o Packets arrive in sequence, and some of the ACKs are delayed.
o パケットは連続して到着します、そして、いくつかのACKsが遅れます。
By Case (A), the timestamp from the oldest unacknowledged
segment is echoed.
Case(A)によって、最も古い不承認のセグメントからのタイムスタンプは反映されます。
TS.Recent
<A, TSval=1> ------------------->
1
<B, TSval=2> ------------------->
1
<C, TSval=3> ------------------->
1
<---- <ACK(C), TSecr=1>
(etc)
TS.Recent<A、TSval=1>。------------------->1<B、TSval=2>。------------------->1<C、TSval=3>。------------------->1<。---- <ACK(C)、TSecr=1>。(など)
o Packets arrive out of order, and every packet is
acknowledged.
o パケットは故障していた状態で到着します、そして、あらゆるパケットが承認されます。
By Case (B), the timestamp from the last segment that
advanced the left window edge is echoed, until the missing
segment arrives; it is echoed according to Case (C). The
same sequence would occur if segments B and D were lost and
retransmitted..
Case(B)によって、左の窓の縁を進めた最後のセグメントからのタイムスタンプは反映されます、なくなったセグメントが到着するまで。 Case(C)によると、それは反響されます。 セグメントBとDが失われていて、再送されるなら、同じ系列は起こるでしょうに。
Jacobson, Braden, & Borman [Page 16] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[16ページ]RFC1323TCP拡張子
TS.Recent
<A, TSval=1> ------------------->
1
<---- <ACK(A), TSecr=1>
1
<C, TSval=3> ------------------->
1
<---- <ACK(A), TSecr=1>
1
<B, TSval=2> ------------------->
2
<---- <ACK(C), TSecr=2>
2
<E, TSval=5> ------------------->
2
<---- <ACK(C), TSecr=2>
2
<D, TSval=4> ------------------->
4
<---- <ACK(E), TSecr=4>
(etc)
TS.Recent<A、TSval=1>。------------------->1<。---- <ACK(A)、TSecr=1>1<C、TSval=3>。------------------->1<。---- <ACK(A)、TSecr=1>1<B、TSval=2>。------------------->2<。---- <ACK(C)、TSecr=2>2<E、TSval=5>。------------------->2<。---- <ACK(C)、TSecr=2>2<D、TSval=4>。------------------->4<。---- <ACK(E)、TSecr=4>。(など)
4. PAWS: PROTECT AGAINST WRAPPED SEQUENCE NUMBERS
4. 足: 包装された一連番号から守ってください。
4.1 Introduction
4.1 序論
Section 4.2 describes a simple mechanism to reject old duplicate
segments that might corrupt an open TCP connection; we call this
mechanism PAWS (Protect Against Wrapped Sequence numbers). PAWS
operates within a single TCP connection, using state that is saved
in the connection control block. Section 4.3 and Appendix C
discuss the implications of the PAWS mechanism for avoiding old
duplicates from previous incarnations of the same connection.
セクション4.2はオープンなTCP接続を買収するかもしれない古い写しセグメントを拒絶するために簡単なメカニズムについて説明します。 私たちは、このメカニズムをPAWSと呼びます(Against Wrapped Sequence番号を保護してください)。 接続制御ブロックで節約される状態を使用して、PAWSは単独のTCP接続の中で作動します。 セクション4.3とAppendix Cは、同じ接続の前の肉体化からの古い写しを避けるためにPAWSメカニズムの含意について論じます。
4.2 The PAWS Mechanism
4.2 足メカニズム
PAWS uses the same TCP Timestamps option as the RTTM mechanism
described earlier, and assumes that every received TCP segment
(including data and ACK segments) contains a timestamp SEG.TSval
whose values are monotone non-decreasing in time. The basic idea
is that a segment can be discarded as an old duplicate if it is
received with a timestamp SEG.TSval less than some timestamp
recently received on this connection.
PAWSは、より早く説明されたRTTMメカニズムと同じTCP Timestampsオプションを使用して、あらゆる容認されたTCPセグメント(データとACKセグメントを含んでいる)が時間内に値が一本調子非減少であるタイムスタンプSEG.TSvalを含むと仮定します。 基本的な考え方は何らかのタイムスタンプより少ないSEG.TSvalがこの接続のときに最近受け取ったタイムスタンプでそれを受け取るなら古い写しとしてセグメントを捨てることができるということです。
In both the PAWS and the RTTM mechanism, the "timestamps" are 32-
PAWSとRTTMメカニズムの両方では、「タイムスタンプ」は32です。
Jacobson, Braden, & Borman [Page 17] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[17ページ]RFC1323TCP拡張子
bit unsigned integers in a modular 32-bit space. Thus, "less
than" is defined the same way it is for TCP sequence numbers, and
the same implementation techniques apply. If s and t are
timestamp values, s < t if 0 < (t - s) < 2**31, computed in
unsigned 32-bit arithmetic.
モジュールの32ビットのスペースで符号のない整数に噛み付きました。 このようにして、「より少なさ、」 それがTCP一連番号のためのものであり、同じ実現のテクニックが適用される同じ方法と定義されます。 sとtであるなら、0<(t--s)<2*であるなら、タイムスタンプ値、s<はtです。*31無記名の32ビットの演算で計算されて。
The choice of incoming timestamps to be saved for this comparison
must guarantee a value that is monotone increasing. For example,
we might save the timestamp from the segment that last advanced
the left edge of the receive window, i.e., the most recent in-
sequence segment. Instead, we choose the value TS.Recent
introduced in Section 3.4 for the RTTM mechanism, since using a
common value for both PAWS and RTTM simplifies the implementation
of both. As Section 3.4 explained, TS.Recent differs from the
timestamp from the last in-sequence segment only in the case of
delayed ACKs, and therefore by less than one window. Either
choice will therefore protect against sequence number wrap-around.
この比較のために保存される入って来るタイムスタンプの選択は単調増加である値を保証しなければなりません。 例えば、私たちが最終が左の縁を進めたセグメントからのタイムスタンプを保存するかもしれない、窓、すなわち、最新のコネ系列セグメントを受けてください。 私たちは、以来PAWSとRTTMの両方に一般的な値を使用すると両方の実現が代わりに簡略化するのをRTTMメカニズムのためにセクション3.4で導入された値のTS.Recentを選びます。 セクション3.4が説明したように、TS.Recentは単に遅れたACKsに関するケースの中としたがって、1つ未満の窓のそばで系列の最後のセグメントからのタイムスタンプと異なっています。 したがって、選択は一連番号巻きつけて着るドレスから守るでしょう。
RTTM was specified in a symmetrical manner, so that TSval
timestamps are carried in both data and ACK segments and are
echoed in TSecr fields carried in returning ACK or data segments.
PAWS submits all incoming segments to the same test, and therefore
protects against duplicate ACK segments as well as data segments.
(An alternative un-symmetric algorithm would protect against old
duplicate ACKs: the sender of data would reject incoming ACK
segments whose TSecr values were less than the TSecr saved from
the last segment whose ACK field advanced the left edge of the
send window. This algorithm was deemed to lack economy of
mechanism and symmetry.)
RTTMは対称の方法で指定されました、TSvalタイムスタンプがデータとACKセグメントの両方で運ばれて、戻っているACKかデータ・セグメントで運ばれたTSecr野原の中で反映されるように。 PAWSはすべての入って来るセグメントを同じテストにかけて、したがって、データ・セグメントと同様に写しACKセグメントから守ります。 (代替の不-左右対称のアルゴリズムは古い写しACKsから守るでしょう: データの送付者がTSecr値が分野がACKで左の縁を進めた最後のセグメントから取っておかれたTSecr以下であった入って来るACKセグメントを拒絶するだろう、窓を送ってください。 このアルゴリズムがメカニズムと対称の経済を欠いていると考えられました。)
TSval timestamps sent on {SYN} and {SYN,ACK} segments are used to
initialize PAWS. PAWS protects against old duplicate non-SYN
segments, and duplicate SYN segments received while there is a
synchronized connection. Duplicate {SYN} and {SYN,ACK} segments
received when there is no connection will be discarded by the
normal 3-way handshake and sequence number checks of TCP.
セグメントが使用されているSYNに送られたTSvalタイムスタンプとSYN、ACKはPAWSを初期化します。 PAWSは古い写し非SYNセグメント、および連動している接続がありますが、受け取られた写しSYNセグメントから守ります。 接続が全くないとき、受け取って、SYNとSYN、ACKが区分する写しはTCPの通常の3ウェイ握手と一連番号チェックで捨てられるでしょう。
It is recommended that RST segments NOT carry timestamps, and that
RST segments be acceptable regardless of their timestamp. Old
duplicate RST segments should be exceedingly unlikely, and their
cleanup function should take precedence over timestamps.
RSTセグメントがタイムスタンプを運ばないで、RSTセグメントがそれらのタイムスタンプにかかわらず許容できるのは、お勧めです。 古い写しRSTセグメントはきわめてありそうもないはずです、そして、それらのクリーンアップ機能はタイムスタンプの上で優先するべきです。
4.2.1 Basic PAWS Algorithm
4.2.1 基本的な足アルゴリズム
The PAWS algorithm requires the following processing to be
performed on all incoming segments for a synchronized
connection:
PAWSアルゴリズムは、以下の処理が連動している接続のためにすべての入って来るセグメントに実行されるのを必要とします:
Jacobson, Braden, & Borman [Page 18] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[18ページ]RFC1323TCP拡張子
R1) If there is a Timestamps option in the arriving segment
and SEG.TSval < TS.Recent and if TS.Recent is valid (see
later discussion), then treat the arriving segment as not
acceptable:
R1) Timestampsオプションが到着セグメントとSEG.TSval<TS.Recentにあって、TS.Recentが有効であるなら(後の議論を見てください)、許容できないとして到着セグメントを扱ってください:
Send an acknowledgement in reply as specified in
RFC-793 page 69 and drop the segment.
RFC-793 69ページにおける指定されるとしての回答における承認を送ってください、そして、セグメントを落としてください。
Note: it is necessary to send an ACK segment in order
to retain TCP's mechanisms for detecting and
recovering from half-open connections. For example,
see Figure 10 of RFC-793.
以下に注意してください。 ACKセグメントを送るのが、半開きな接続から検出して、回復するためのTCPのメカニズムを保有するのに必要です。 例えば、RFC-793の図10を見てください。
R2) If the segment is outside the window, reject it (normal
TCP processing)
R2) 窓の外にセグメントがあるなら、それを拒絶してください。(通常のTCP処理)
R3) If an arriving segment satisfies: SEG.SEQ <= Last.ACK.sent
(see Section 3.4), then record its timestamp in TS.Recent.
R3) 到着セグメントが以下を満たすなら SEG.SEQ<=Last.ACK.sent(セクション3.4を見る)、そして、TS.Recentのタイムスタンプを記録してください。
R4) If an arriving segment is in-sequence (i.e., at the left
window edge), then accept it normally.
R4) 到着セグメントが系列であるなら(すなわち、左の窓の縁の)、通常、それを受け入れてください。
R5) Otherwise, treat the segment as a normal in-window, out-
of-sequence TCP segment (e.g., queue it for later delivery
to the user).
R5) さもなければ、窓で正常なaとしてセグメントを扱ってください、系列の出ているTCPセグメント(例えば、後の配送のためにユーザへそれを列に並ばせてください)。
Steps R2, R4, and R5 are the normal TCP processing steps
specified by RFC-793.
ステップのR2、R4、およびR5はRFC-793によって指定された通常のTCP処理ステップです。
It is important to note that the timestamp is checked only when
a segment first arrives at the receiver, regardless of whether
it is in-sequence or it must be queued for later delivery.
Consider the following example.
セグメントが最初に受信機に到着するときだけ、タイムスタンプがチェックされることに注意するのは重要です、それが系列である、または後の配送のためにそれを列に並ばせなければならないことにかかわらず。 以下の例を考えてください。
Suppose the segment sequence: A.1, B.1, C.1, ..., Z.1 has
been sent, where the letter indicates the sequence number
and the digit represents the timestamp. Suppose also that
segment B.1 has been lost. The timestamp in TS.TStamp is
1 (from A.1), so C.1, ..., Z.1 are considered acceptable
and are queued. When B is retransmitted as segment B.2
(using the latest timestamp), it fills the hole and causes
all the segments through Z to be acknowledged and passed
to the user. The timestamps of the queued segments are
*not* inspected again at this time, since they have
already been accepted. When B.2 is accepted, TS.Stamp is
set to 2.
セグメントが系列であると仮定してください: A.1、B.1、C.1…, Z.1(手紙は一連番号を示す)を送りました、そして、ケタはタイムスタンプを表します。 また、そのセグメントB.1がなくされたと仮定してください。 TS.TStampのタイムスタンプは1(A.1からの)であり、そうはC.1です…, Z.1は許容できると考えられて、列に並ばせられます。 BがセグメントB.2として再送されるとき(最新のタイムスタンプを使用して)、それは、穴をふさいでいて、Zを通したすべてのセグメントがユーザに承認されて、渡されることを引き起こします。 列に並ばせられたセグメントに関するタイムスタンプは*ではなく、既にそれらを受け入れて以来このとき再び点検されている*です。 B.2を受け入れるとき、TS.Stampは2に用意ができています。
This rule allows reasonable performance under loss. A full
この規則は損失で妥当な性能を許容します。 満
Jacobson, Braden, & Borman [Page 19] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[19ページ]RFC1323TCP拡張子
window of data is in transit at all times, and after a loss a
full window less one packet will show up out-of-sequence to be
queued at the receiver (e.g., up to ~2**30 bytes of data); the
timestamp option must not result in discarding this data.
データの窓はトランジットいつも中です、そして、損失の後に、完全なウィンドウより少ない1パケットは受信機(例えば、~2**30バイトのデータまでの)に列に並ばせられるために順序が狂って現れるでしょう。 タイムスタンプオプションはこのデータを捨てるのに結果として生じてはいけません。
In certain unlikely circumstances, the algorithm of rules R1-R4
could lead to discarding some segments unnecessarily, as shown
in the following example:
あるありそうもない事情、R1-R4が通じることができた以下の例に示されるように不必要にいくつかのセグメントを捨てる規則のアルゴリズムで:
Suppose again that segments: A.1, B.1, C.1, ..., Z.1 have
been sent in sequence and that segment B.1 has been lost.
Furthermore, suppose delivery of some of C.1, ... Z.1 is
delayed until AFTER the retransmission B.2 arrives at the
receiver. These delayed segments will be discarded
unnecessarily when they do arrive, since their timestamps
are now out of date.
それがセグメントであるともう一度仮定してください: A.1、B.1、C.1…, 連続してZ.1を送りました、そして、そのセグメントB.1をなくしました。 その上、いくらかのC.1の配送を仮定してください… AFTER retransmission B.2が受信機に到着するまで、Z.1は遅れます。到着するとき、これらの遅れたセグメントは不必要に捨てられるでしょう、それらのタイムスタンプが現在時代遅れであるので。
This case is very unlikely to occur. If the retransmission was
triggered by a timeout, some of the segments C.1, ... Z.1 must
have been delayed longer than the RTO time. This is presumably
an unlikely event, or there would be many spurious timeouts and
retransmissions. If B's retransmission was triggered by the
"fast retransmit" algorithm, i.e., by duplicate ACKs, then the
queued segments that caused these ACKs must have been received
already.
本件は非常に起こりそうにはありません。 「再-トランスミッション」がタイムアウト、セグメントC.1、…のいくつかによって引き起こされたなら Z.1はRTO時間より長い間、遅れたに違いありません。 おそらく、これはありそうもない出来事です、または多くの偽りのタイムアウトと「再-トランスミッション」があるでしょう。 すなわち、「速く再送してください」というアルゴリズム、写しACKsがビーズの「再-トランスミッション」を引き起こしたなら、既にこれらのACKsを引き起こした列に並ばせられたセグメントを受け取ったに違いありません。
Even if a segment were delayed past the RTO, the Fast
Retransmit mechanism [Jacobson90c] will cause the delayed
packets to be retransmitted at the same time as B.2, avoiding
an extra RTT and therefore causing a very small performance
penalty.
セグメントがRTOの先で遅らせられたとしても、Fast Retransmitメカニズム[Jacobson90c]でB.2と同時に遅れたパケットを再送するでしょう、余分なRTTを避けて、したがって、非常に小さいパフォーマンスに不利な条件を引き起こします。
We know of no case with a significant probability of occurrence
in which timestamps will cause performance degradation by
unnecessarily discarding segments.
私たちはタイムスタンプが不必要にセグメントを捨てることによって性能退行を引き起こす発生の重要な確率があるケースを全く知りません。
4.2.2 Timestamp Clock
4.2.2 タイムスタンプ時計
It is important to understand that the PAWS algorithm does not
require clock synchronization between sender and receiver. The
sender's timestamp clock is used to stamp the segments, and the
sender uses the echoed timestamp to measure RTT's. However,
the receiver treats the timestamp as simply a monotone-
increasing serial number, without any necessary connection to
its clock. From the receiver's viewpoint, the timestamp is
acting as a logical extension of the high-order bits of the
sequence number.
PAWSアルゴリズムが送付者と受信機の間の時計同期を必要としないのを理解しているのは重要です。送付者のタイムスタンプ時計はセグメントを押し込むのに使用されます、そして、送付者はRTTのものを測定するのに反響しているタイムスタンプを使用します。 しかしながら、受信機は同じくらい単にタイムスタンプを扱います。時計との少しも必要な接続のない一本調子の増加する通し番号。 受信機の観点から、タイムスタンプは一連番号の高位のビットの論理的な拡大として機能しています。
Jacobson, Braden, & Borman [Page 20] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[20ページ]RFC1323TCP拡張子
The receiver algorithm does place some requirements on the
frequency of the timestamp clock.
受信機アルゴリズムはタイムスタンプ時計の頻度にいくつかの要件を置きます。
(a) The timestamp clock must not be "too slow".
(a) タイムスタンプ時計は「遅過ぎてはいけません」。
It must tick at least once for each 2**31 bytes sent. In
fact, in order to be useful to the sender for round trip
timing, the clock should tick at least once per window's
worth of data, and even with the RFC-1072 window
extension, 2**31 bytes must be at least two windows.
それは31バイトが送った各2**のために少なくとも一度カチカチしなければなりません。 事実上、時計は、周遊旅行タイミングで送付者の役に立つ窓のデータの価値単位で少なくともかつてカチカチして、RFC-1072窓の拡張子、31バイトがそうしなければならない2**があっても少なくとも2つの窓であるべきです。
To make this more quantitative, any clock faster than 1
tick/sec will reject old duplicate segments for link
speeds of ~8 Gbps. A 1ms timestamp clock will work at
link speeds up to 8 Tbps (8*10**12) bps!
この以上を量的にするように、1カチカチする音/秒より速いどんな時計も~8Gbpsのリンク速度のために古い写しセグメントを拒絶するでしょう。 1msタイムスタンプ時計が最大8のリンク速度Tbpsで動作する、(8 *10**12) ビーピーエス!
(b) The timestamp clock must not be "too fast".
(b) タイムスタンプ時計は「速過ぎてはいけません」。
Its recycling time must be greater than MSL seconds.
Since the clock (timestamp) is 32 bits and the worst-case
MSL is 255 seconds, the maximum acceptable clock frequency
is one tick every 59 ns.
再生時間はMSL秒より長いに違いありません。 時計(タイムスタンプ)が32ビットであり、最悪の場合MSLが255秒であるので、最大の許容できるクロック周波数は59ナノ秒毎1回のカチカチする音です。
However, it is desirable to establish a much longer
recycle period, in order to handle outdated timestamps on
idle connections (see Section 4.2.3), and to relax the MSL
requirement for preventing sequence number wrap-around.
With a 1 ms timestamp clock, the 32-bit timestamp will
wrap its sign bit in 24.8 days. Thus, it will reject old
duplicates on the same connection if MSL is 24.8 days or
less. This appears to be a very safe figure; an MSL of
24.8 days or longer can probably be assumed by the gateway
system without requiring precise MSL enforcement by the
TTL value in the IP layer.
しかしながら、多くを確立するのが無駄な接続(セクション4.2.3を見る)に関する時代遅れのタイムスタンプを扱って、一連番号巻きつけて着るドレスを防ぐためのMSL要件を弛緩するために、より長い間期間を再生するのは、望ましいです。 1個のmsタイムスタンプ時計で、32ビットのタイムスタンプは24.8日間後に符号ビットを包装するでしょう。 したがって、それはMSLが24.8日間以下であるなら同じ接続に関する古い写しを拒絶するでしょう。 これは非常に安全な図であるように見えます。 IP層のTTL値で正確なMSL実施を必要としないで、ゲートウェイシステムはたぶん24.8日間のMSLを想定できます。
Based upon these considerations, we choose a timestamp clock
frequency in the range 1 ms to 1 sec per tick. This range also
matches the requirements of the RTTM mechanism, which does not
need much more resolution than the granularity of the
retransmit timer, e.g., tens or hundreds of milliseconds.
これらの問題に基づいて、私たちは範囲で1カチカチする音あたり1 1秒までのmsにタイムスタンプクロック周波数を選びます。 また、この範囲は再送信タイマ、例えば、10の粒状よりはるかに多くの解決を必要としないRTTMメカニズムの要件か何百ミリセカンドにも合っています。
The PAWS mechanism also puts a strong monotonicity requirement
on the sender's timestamp clock. The method of implementation
of the timestamp clock to meet this requirement depends upon
the system hardware and software.
また、PAWSメカニズムは強い単調要件を送付者のタイムスタンプ時計に置きます。 タイムスタンプ時計の実現がこの必要条件を満たす方法はシステムハードウェアとソフトウェアによります。
* Some hosts have a hardware clock that is guaranteed to be
monotonic between hardware resets.
* ホストの中にはハードウェアリセットの間で単調になるように保証されるハードウェア時計を持っている人もいます。
Jacobson, Braden, & Borman [Page 21] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[21ページ]RFC1323TCP拡張子
* A clock interrupt may be used to simply increment a binary
integer by 1 periodically.
* 時計割込みは、単に2進整数を定期的に1つ増加するのに使用されるかもしれません。
* The timestamp clock may be derived from a system clock
that is subject to being abruptly changed, by adding a
variable offset value. This offset is initialized to
zero. When a new timestamp clock value is needed, the
offset can be adjusted as necessary to make the new value
equal to or larger than the previous value (which was
saved for this purpose).
* タイムスタンプ時計は受けることがあるシステムクロックから突然に変えるまで引き出されるかもしれません、可変オフセット価値を高めることによって。 このオフセットはゼロに初期化されます。 新しいタイムスタンプ時計価値が必要であるときに、新しい値を前の値(このために救われた)より等しいか大きくするように必要に応じてオフセットを調整できます。
4.2.3 Outdated Timestamps
4.2.3 時代遅れのタイムスタンプ
If a connection remains idle long enough for the timestamp
clock of the other TCP to wrap its sign bit, then the value
saved in TS.Recent will become too old; as a result, the PAWS
mechanism will cause all subsequent segments to be rejected,
freezing the connection (until the timestamp clock wraps its
sign bit again).
接続がもう片方のTCPのタイムスタンプ時計が符号ビットを包装できるくらいの長い間活動していないままでいると、TS.Recentで節約された値は古くなり過ぎるでしょう。 その結果、PAWSメカニズムですべてのその後のセグメントを拒絶するでしょう、接続を凍らせて(タイムスタンプ時計が再び符号ビットを包装するまで)。
With the chosen range of timestamp clock frequencies (1 sec to
1 ms), the time to wrap the sign bit will be between 24.8 days
and 24800 days. A TCP connection that is idle for more than 24
days and then comes to life is exceedingly unusual. However,
it is undesirable in principle to place any limitation on TCP
connection lifetimes.
選ばれた範囲のタイムスタンプ時計頻度(1msへの1秒)と共に、符号ビットを包装する時間が24.8日間と24800日間の間あるでしょう。 24日間以上活動していなく、次に生き返るTCP接続はきわめて珍しいです。 しかしながら、原則としてTCPコネクション存続期間にどんな制限も置くのは望ましくありません。
We therefore require that an implementation of PAWS include a
mechanism to "invalidate" the TS.Recent value when a connection
is idle for more than 24 days. (An alternative solution to the
problem of outdated timestamps would be to send keepalive
segments at a very low rate, but still more often than the
wrap-around time for timestamps, e.g., once a day. This would
impose negligible overhead. However, the TCP specification has
never included keepalives, so the solution based upon
invalidation was chosen.)
したがって、私たちは、PAWSの実現が接続が24日間以上無駄であるときに、TS.Recent値を「無効にする」ためにメカニズムを含んでいるのを必要とします。 (時代遅れのタイムスタンプの問題の代替の解決はタイムスタンプのための巻きつけて着るドレス時間、例えば、かつての1日より非常に低いレートでましてしばしばkeepaliveセグメントを送るだろうことです。 これは取るにたらないオーバーヘッドを課すでしょう。 しかしながら、TCP仕様がkeepalivesを一度も含んだことがないので、無効にすることに基づいた解決策は選ばれました。)
Note that a TCP does not know the frequency, and therefore, the
wraparound time, of the other TCP, so it must assume the worst.
The validity of TS.Recent needs to be checked only if the basic
PAWS timestamp check fails, i.e., only if SEG.TSval <
TS.Recent. If TS.Recent is found to be invalid, then the
segment is accepted, regardless of the failure of the timestamp
check, and rule R3 updates TS.Recent with the TSval from the
new segment.
最悪を仮定しなければならないためにTCPが頻度を知っていて、その結果もう片方のTCPの巻きつけて着るドレス時間は知らないことに注意してください。 すなわち、基本的なPAWSタイムスタンプチェックがSEG.TSval<TS.Recentである場合にだけ失敗する場合にだけ、TS.Recentの正当性は、チェックされる必要があります。 TS.Recentが無効であることがわかっているなら、タイムスタンプチェックの失敗にかかわらずセグメントを受け入れます、そして、規則R3はTSvalと共に新しいセグメントからTS.Recentをアップデートします。
To detect how long the connection has been idle, the TCP may
接続がどれくらい長い間無駄であるかを検出するために、TCPはそうするかもしれません。
Jacobson, Braden, & Borman [Page 22] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[22ページ]RFC1323TCP拡張子
update a clock or timestamp value associated with the
connection whenever TS.Recent is updated, for example. The
details will be implementation-dependent.
例えば、TS.Recentをアップデートするときはいつも、接続に関連している時計かタイムスタンプ値をアップデートしてください。 詳細は実現依存するようになるでしょう。
4.2.4 Header Prediction
4.2.4 ヘッダー予測
"Header prediction" [Jacobson90a] is a high-performance
transport protocol implementation technique that is most
important for high-speed links. This technique optimizes the
code for the most common case, receiving a segment correctly
and in order. Using header prediction, the receiver asks the
question, "Is this segment the next in sequence?" This
question can be answered in fewer machine instructions than the
question, "Is this segment within the window?"
「ヘッダー予測」[Jacobson90a]は高速リンクに、最も重要な高性能トランスポート・プロトコル実現のテクニックです。 正しさと注文におけるセグメントを受けて、このテクニックは最も一般的なケースのためにコードを最適化します。 ヘッダー予測を使用して、受信機は、「このセグメントは系列の次ですか?」と質問します。 質問より少ない機械語命令、「窓の中にこのセグメントはありますか?」でこの質問に答えることができます。
Adding header prediction to our timestamp procedure leads to
the following recommended sequence for processing an arriving
TCP segment:
私たちのタイムスタンプ手順にヘッダー予測を追加するのは到着しているTCPセグメントを処理するための以下のお勧めの系列に通じます:
H1) Check timestamp (same as step R1 above)
H1) タイムスタンプをチェックしてください。(上のステップR1と同じこと)
H2) Do header prediction: if segment is next in sequence and
if there are no special conditions requiring additional
processing, accept the segment, record its timestamp, and
skip H3.
H2) ヘッダーに予測してください: セグメントが連続して次であり、追加処理を必要とするどんな特別な状態もなければ、セグメントを受け入れてください、そして、タイムスタンプを記録してください、そして、H3をスキップしてください。
H3) Process the segment normally, as specified in RFC-793.
This includes dropping segments that are outside the win-
dow and possibly sending acknowledgments, and queueing
in-window, out-of-sequence segments.
H3) 通常、RFC-793で指定されるようにセグメントを処理してください。 勝利ダウ船、ことによると発信している承認、および待ち行列の外で窓であるセグメントを落とす順序が狂ってセグメントをこれは含んでいます。
Another possibility would be to interchange steps H1 and H2,
i.e., to perform the header prediction step H2 FIRST, and
perform H1 and H3 only when header prediction fails. This
could be a performance improvement, since the timestamp check
in step H1 is very unlikely to fail, and it requires interval
arithmetic on a finite field, a relatively expensive operation.
To perform this check on every single segment is contrary to
the philosophy of header prediction. We believe that this
change might reduce CPU time for TCP protocol processing by up
to 5-10% on high-speed networks.
別の可能性は、ヘッダー予測が失敗する場合にだけ、すなわち、ヘッダー予測ステップH2 FIRSTを実行するためにステップのH1とH2を交換して、H1とH3を実行するだろうことです。 これは性能改良であるかもしれません、ステップH1でのタイムスタンプチェックが非常に失敗しそうになくて、有限分野、比較的高価な操作のときに区間算術を必要とするので。 あらゆるセグメントにこのチェックを実行するのはヘッダー予測の哲学に反対です。 私たちは、この変化がTCPプロトコル処理のためのCPU時間を高速ネットワークの5-10%短縮するかもしれないと信じています。
However, putting H2 first would create a hazard: a segment from
2**32 bytes in the past might arrive at exactly the wrong time
and be accepted mistakenly by the header-prediction step. The
following reasoning has been introduced [Jacobson90b] to show
that the probability of this failure is negligible.
しかしながら、最初にH2を置くと、危険は作成されるでしょう: 過去の2**32バイトからのセグメントはまさに間違った時間に到着して、ヘッダー予測ステップで誤って受け入れるかもしれません。 この失敗の確率が取るにたらないのを示すために以下の推理を導入しました[Jacobson90b]。
Jacobson, Braden, & Borman [Page 23] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[23ページ]RFC1323TCP拡張子
If all segments are equally likely to show up as old
duplicates, then the probability of an old duplicate
exactly matching the left window edge is the maximum
segment size (MSS) divided by the size of the sequence
space. This ratio must be less than 2**-16, since MSS
must be < 2**16; for example, it will be (2**12)/(2**32) =
2**-20 for an FDDI link. However, the older a segment is,
the less likely it is to be retained in the Internet, and
under any reasonable model of segment lifetime the
probability of an old duplicate exactly at the left window
edge must be much smaller than 2**-16.
すべてのセグメントが古い写しとして等しく現れそうであるなら、古い写しがまさに左の窓の縁に合っているという確率は最大の系列スペースのサイズが割られたセグメントサイズ(MSS)です。 この比率はMSSが<2**16であるに違いないので、2**-16より少ないに違いありません。 例えば、それはFDDIリンクへの(2**12)/(2**32)=にな2**-20るでしょう。 しかしながら、セグメントが古ければ古いほど、インターネットで、より保有されそうになくて、セグメント生涯のどんな合理的なモデルの下ではも、ちょうど左の窓の縁の古い写しの確率は2**-16よりはるかにわずかでなければなりません。
The 16 bit TCP checksum also allows a basic unreliability
of one part in 2**16. A protocol mechanism whose
reliability exceeds the reliability of the TCP checksum
should be considered "good enough", i.e., it won't
contribute significantly to the overall error rate. We
therefore believe we can ignore the problem of an old
duplicate being accepted by doing header prediction before
checking the timestamp.
また、16ビットのTCPチェックサムは2**16の一部の基本的な非信頼性を許容します。 信頼性がTCPチェックサムの信頼性を超えているプロトコルメカニズムは「十分良い」と考えられるべきです、すなわち、それは総合誤差率にかなり貢献しないでしょう。 したがって、私たちは、タイムスタンプをチェックする前にヘッダーに予測することによって受け入れられる古い写しの問題を無視できると信じています。
However, this probabilistic argument is not universally
accepted, and the consensus at present is that the performance
gain does not justify the hazard in the general case. It is
therefore recommended that H2 follow H1.
しかしながら、この確率的な議論は一般に受け入れられません、そして、現在のところのコンセンサスは性能向上が一般的な場合における危険を正当化しないということです。 したがって、H2がH1に続くのは、お勧めです。
4.3. Duplicates from Earlier Incarnations of Connection
4.3. 前から、接続の顕現をコピーします。
The PAWS mechanism protects against errors due to sequence number
wrap-around on high-speed connection. Segments from an earlier
incarnation of the same connection are also a potential cause of
old duplicate errors. In both cases, the TCP mechanisms to
prevent such errors depend upon the enforcement of a maximum
segment lifetime (MSL) by the Internet (IP) layer (see Appendix of
RFC-1185 for a detailed discussion). Unlike the case of sequence
space wrap-around, the MSL required to prevent old duplicate
errors from earlier incarnations does not depend upon the transfer
rate. If the IP layer enforces the recommended 2 minute MSL of
TCP, and if the TCP rules are followed, TCP connections will be
safe from earlier incarnations, no matter how high the network
speed. Thus, the PAWS mechanism is not required for this case.
PAWSメカニズムは高速接続のときに一連番号巻きつけて着るドレスによる誤りから守ります。 また、同じ接続の以前の肉体化からのセグメントは古い写し誤りの潜在的原因です。 どちらの場合も、そのような誤りを防ぐTCPメカニズムはインターネット(IP)層のそばで最大のセグメント生涯(MSL)の実施によります(詳細な論議に関してRFC-1185のAppendixを見てください)。 系列スペース巻きつけて着るドレスに関するケースと異なって、以前の肉体化から古い写し誤りを防がなければならなかったMSLは転送レートによりません。 そして、IP層がTCPの2分のお勧めのMSLを実施するならTCP規則は従われていて、TCP接続は以前の肉体化で安全になるでしょう、ネットワーク速度がどんなに高くても。 したがって、PAWSメカニズムはこのような場合必要ではありません。
We may still ask whether the PAWS mechanism can provide additional
security against old duplicates from earlier connections, allowing
us to relax the enforcement of MSL by the IP layer. Appendix B
explores this question, showing that further assumptions and/or
mechanisms are required, beyond those of PAWS. This is not part
of the current extension.
私たちは、PAWSメカニズムが古い写しに対して以前の接続から追加担保を提供できるかどうかまだ尋ねているかもしれません、私たちがIP層のそばでMSLの実施を弛緩するのを許容して。 さらなる仮定、そして/または、メカニズムがPAWSのものを超えて必要であることを示して、付録Bはこの質問を探ります。 これは現在の拡大の一部ではありません。
Jacobson, Braden, & Borman [Page 24] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[24ページ]RFC1323TCP拡張子
5. CONCLUSIONS AND ACKNOWLEDGMENTS
5. 結論と承認
This memo presented a set of extensions to TCP to provide efficient operation over large-bandwidth*delay-product paths and reliable operation over very high-speed paths. These extensions are designed to provide compatible interworking with TCP's that do not implement the extensions.
このメモは、非常に高速な経路の上で大きい帯域幅*遅れの製品の経路と信頼できる操作の上に効率的な操作を提供するために1セットの拡大をTCPに提示しました。 これらの拡大は、拡大を実行しないTCPのものをコンパチブル織り込むのに提供するように設計されています。
These mechanisms are implemented using new TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences).
これらのメカニズムは、スケーリングされた窓とタイムスタンプに新しいTCPオプションを使用することで実行されます。 タイムスタンプは2台の異なる機序に使用されます: RTTM(周遊旅行時間測定)と足(包装された系列から守ります)。
The Window Scale option was originally suggested by Mike St. Johns of USAF/DCA. The present form of the option was suggested by Mike Karels of UC Berkeley in response to a more cumbersome scheme defined by Van Jacobson. Lixia Zhang helped formulate the PAWS mechanism description in RFC-1185.
Window Scaleオプションは元々、USAF/DCAのマイク通りジョーンズによって提案されました。 オプションの現行様式はヴァン・ジェーコブソンによって定義されたより厄介な計画に対応してUCバークレーのマイクKarelsによって勧められました。 Lixiaチャンは、RFC-1185でPAWSメカニズム記述を定式化するのを助けました。
Finally, much of this work originated as the result of discussions within the End-to-End Task Force on the theoretical limitations of transport protocols in general and TCP in particular. More recently, task force members and other on the end2end-interest list have made valuable contributions by pointing out flaws in the algorithms and the documentation. The authors are grateful for all these contributions.
最終的に、この仕事の多くがEndから終わりへの一般に、トランスポート・プロトコルの理論上の制限でのTask Forceと特にTCP中に議論の結果として由来しました。 より最近、end2end-関心リストのメンバーの、そして、他の特別委員会は、アルゴリズムとドキュメンテーションの欠点を指摘することによって、有価約因をしました。 作者はこれらのすべての貢献に感謝しています。
6. REFERENCES
6. 参照
[Clark87] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk
Data Transfer Protocol", RFC 998, MIT, March 1987.
[Clark87] クラーク、D.、ランバート、M.、およびL.チャン、「NETBLT:」 「バルク・データ転送プロトコル」、RFC998、MIT、1987年3月。
[Garlick77] Garlick, L., R. Rom, and J. Postel, "Issues in
Reliable Host-to-Host Protocols", Proc. Second Berkeley Workshop
on Distributed Data Management and Computer Networks, May 1977.
[Garlick77] ガーリック、L.、R.Rom、およびJ.ポステル、「信頼できるホスト間プロトコルの問題」、Proc。 1977年5月の分散データ管理とコンピュータネットワークに関する第2バークレーワークショップ。
[Hamming77] Hamming, R., "Digital Filters", ISBN 0-13-212571-4,
Prentice Hall, Englewood Cliffs, N.J., 1977.
[Hamming77] ハミング、R.、「デジタル・フィルタ」、ISBN0-13-212571-4、新米のホール、イングルウッドがけ、ニュージャージー州、1977。
[Cheriton88] Cheriton, D., "VMTP: Versatile Message Transaction
Protocol", RFC 1045, Stanford University, February 1988.
[Cheriton88]Cheriton、D.、「VMTP:」 「多能なメッセージ取引プロトコル」、RFC1045、スタンフォード大学、1988年2月。
[Jacobson88a] Jacobson, V., "Congestion Avoidance and Control",
SIGCOMM '88, Stanford, CA., August 1988.
[Jacobson88a] ジェーコブソンと、V.と、「輻輳回避とコントロール」、SIGCOMM88年、スタンフォード(カリフォルニア)、8月1988日
[Jacobson88b] Jacobson, V., and R. Braden, "TCP Extensions for
Long-Delay Paths", RFC-1072, LBL and USC/Information Sciences
Institute, October 1988.
[Jacobson88b] RFC-1072、LBL、およびUSC/情報科学は、1988年10月にジェーコブソン、V.、およびR.ブレーデン、「長時間の遅延経路のためのTCP拡張子」と設けます。
Jacobson, Braden, & Borman [Page 25] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[25ページ]RFC1323TCP拡張子
[Jacobson90a] Jacobson, V., "4BSD Header Prediction", ACM
Computer Communication Review, April 1990.
[Jacobson90a] ジェーコブソン、V.、「4BSDヘッダー予測」、ACMコンピュータコミュニケーションレビュー、1990年4月。
[Jacobson90b] Jacobson, V., Braden, R., and Zhang, L., "TCP
Extension for High-Speed Paths", RFC-1185, LBL and USC/Information
Sciences Institute, October 1990.
[Jacobson90b] 「高速経路のためのTCP拡張子」、RFC-1185、LBL、およびUSC/情報科学が1990年10月に任命するジェーコブソンとV.とブレーデン、R.とチャン、L.。
[Jacobson90c] Jacobson, V., "Modified TCP congestion avoidance
algorithm", Message to end2end-interest mailing list, April 1990.
[Jacobson90c] ジェーコブソン、V.、「変更されたTCP輻輳回避アルゴリズム」、end2end-関心メーリングリストへのMessage、1990年4月。
[Jain86] Jain, R., "Divergence of Timeout Algorithms for Packet
Retransmissions", Proc. Fifth Phoenix Conf. on Comp. and Comm.,
Scottsdale, Arizona, March 1986.
[Jain86] ジャイナ教徒、R.、「パケットRetransmissionsのためのタイムアウトアルゴリズムの分岐」、Proc。 第5フェニックスConfコンピュータCommに関してスコッツデール(アリゾナ)3月1986番目
[Karn87] Karn, P. and C. Partridge, "Estimating Round-Trip Times
in Reliable Transport Protocols", Proc. SIGCOMM '87, Stowe, VT,
August 1987.
[Karn87] KarnとP.とC.ヤマウズラ、「信頼できるトランスポート・プロトコルの往復の回を見積もっています」、Proc。 SIGCOMM87年、ストウ、バーモント、1987年8月。
[McKenzie89] McKenzie, A., "A Problem with the TCP Big Window
Option", RFC 1110, BBN STC, August 1989.
[McKenzie89] マッケンジー、A.、「TCPの大きい窓のオプションに関する問題」、RFC1110、BBN STC、1989年8月。
[Nagle84] Nagle, J., "Congestion Control in IP/TCP
Internetworks", RFC 896, FACC, January 1984.
[Nagle84] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、RFC896、FACC、1984年1月。
[NBS85] Colella, R., Aronoff, R., and K. Mills, "Performance
Improvements for ISO Transport", Ninth Data Comm Symposium,
published in ACM SIGCOMM Comp Comm Review, vol. 15, no. 5,
September 1985.
[NBS85]Colella(R.とAronoff、R.とK.ミルズ、「ISO輸送のためのパフォーマンス改良」Ninth Data Comm Symposium)はACM SIGCOMM Comp Comm Reviewで発行しました、vol.15、No.5、1985年9月。
[Postel81] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", RFC 793, DARPA,
September 1981.
[Postel81] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC793、DARPA、1981年9月。
[Velten84] Velten, D., Hinden, R., and J. Sax, "Reliable Data
Protocol", RFC 908, BBN, July 1984.
[Velten84] フェルテンとD.とHinden、R.とJ.サクソフォーン、「確実な資料プロトコル」、RFC908、BBN、1984年7月。
[Watson81] Watson, R., "Timer-based Mechanisms in Reliable
Transport Protocol Connection Management", Computer Networks, Vol.
5, 1981.
[Watson81] ワトソン、R.、「信頼できるトランスポート・プロトコル接続管理におけるタイマベースのメカニズム」、コンピュータネットワーク、Vol.5、1981。
[Zhang86] Zhang, L., "Why TCP Timers Don't Work Well", Proc.
SIGCOMM '86, Stowe, Vt., August 1986.
[Zhang86] チャン、L.、「TCPタイマが動作しない理由は噴出する」Proc。 SIGCOMM86年、ストウ、バーモント州、1986年8月。
Jacobson, Braden, & Borman [Page 26] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[26ページ]RFC1323TCP拡張子
APPENDIX A: IMPLEMENTATION SUGGESTIONS
付録A: 実現提案
The following layouts are recommended for sending options on non-SYN segments, to achieve maximum feasible alignment of 32-bit and 64-bit machines.
送付オプションのために、非SYNセグメントで以下のレイアウトが32ビットの、そして、64ビットのマシンの最大の可能な整列を達成することが勧められます。
+--------+--------+--------+--------+
| NOP | NOP | TSopt | 10 |
+--------+--------+--------+--------+
| TSval timestamp |
+--------+--------+--------+--------+
| TSecr timestamp |
+--------+--------+--------+--------+
+--------+--------+--------+--------+ | NOP| NOP| TSopt| 10 | +--------+--------+--------+--------+ | TSvalタイムスタンプ| +--------+--------+--------+--------+ | TSecrタイムスタンプ| +--------+--------+--------+--------+
APPENDIX B: DUPLICATES FROM EARLIER CONNECTION INCARNATIONS
付録B: 前から、接続肉体化をコピーします。
There are two cases to be considered: (1) a system crashing (and losing connection state) and restarting, and (2) the same connection being closed and reopened without a loss of host state. These will be described in the following two sections.
考えられる2つのケースがあります: (1) 同じ接続存在がホスト状態の損失なしで閉じて、再開させたシステムクラッシュ(接続状態を失って)、再開、および(2)。 これらは以下の2つのセクションで説明されるでしょう。
B.1 System Crash with Loss of State
状態の損失に伴うB.1システムクラッシュ
TCP's quiet time of one MSL upon system startup handles the loss
of connection state in a system crash/restart. For an
explanation, see for example "When to Keep Quiet" in the TCP
protocol specification [Postel81]. The MSL that is required here
does not depend upon the transfer speed. The current TCP MSL of 2
minutes seems acceptable as an operational compromise, as many
host systems take this long to boot after a crash.
TCPのシステム起動での1MSLの静かな時間はシステムクラッシュ/再開における、接続状態の損失を扱います。 説明に関しては、例えば、TCPプロトコル仕様[Postel81]で「いつ静かにしていますか。」と見てください。 ここで必要であるMSLは転送速度に依存しません。 2分の現在のTCP MSLは操作上の妥協として許容できるように思えます、多くのホストシステムがクラッシュのその上後にこれに時間がかかるとき。
However, the timestamp option may be used to ease the MSL
requirements (or to provide additional security against data
corruption). If timestamps are being used and if the timestamp
clock can be guaranteed to be monotonic over a system
crash/restart, i.e., if the first value of the sender's timestamp
clock after a crash/restart can be guaranteed to be greater than
the last value before the restart, then a quiet time will be
unnecessary.
しかしながら、タイムスタンプオプションは、MSL要件を緩和すること(データの汚染に対して追加担保を提供するために)に使用されるかもしれません。 タイムスタンプが使用されていて、すなわち、再開の前に最終値よりすばらしくなるようにクラッシュ/再開の後の送付者のタイムスタンプ時計の最初の値を保証できるならシステムクラッシュ/再開の上で単調になるようにタイムスタンプ時計を保証できるなら静かな時間が不要になるなら。
To dispense totally with the quiet time would require that the
host clock be synchronized to a time source that is stable over
the crash/restart period, with an accuracy of one timestamp clock
tick or better. We can back off from this strict requirement to
take advantage of approximate clock synchronization. Suppose that
the clock is always re-synchronized to within N timestamp clock
静かな時間を完全に省くのは、ホスト時計がクラッシュ/再開の期間、1つのタイムスタンプの時計カチカチする音の精度で安定したか、または、より良い時間ソースに連動するのを必要とするでしょう。 私たちは大体の時計同期を利用するというこの厳しい要件から引き返すことができます。 時計がいつもNタイムスタンプ時計に再連動すると仮定してください。
Jacobson, Braden, & Borman [Page 27] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[27ページ]RFC1323TCP拡張子
ticks and that booting (extended with a quiet time, if necessary)
takes more than N ticks. This will guarantee monotonicity of the
timestamps, which can then be used to reject old duplicates even
without an enforced MSL.
カチカチする音とその穂ばらみ(静かな時間で必要なら拡張している)はNがカチカチするより取ります。 これはタイムスタンプの単調を保証するでしょう。(次に、実施されたMSLがなくても古い写しを拒絶するのにタイムスタンプを使用できます)。
B.2 Closing and Reopening a Connection
接続を終えて、再開させるB.2
When a TCP connection is closed, a delay of 2*MSL in TIME-WAIT
state ties up the socket pair for 4 minutes (see Section 3.5 of
[Postel81]. Applications built upon TCP that close one connection
and open a new one (e.g., an FTP data transfer connection using
Stream mode) must choose a new socket pair each time. The TIME-
WAIT delay serves two different purposes:
TCP接続が閉じられるとき、タイム誌-WAITの2*MSLの遅れは4分間ソケット組に結びつきを述べます。[Postel81]のセクション3.5を見てください。(1つの接続を終えて、新しいものを開くTCPで組立てられたアプリケーション(例えば、Streamモードを使用しているFTPデータ転送コネクション)がその都度新しいソケット組を選ばなければならない、タイム誌WAIT遅れは2つの異なる役割に役立ちます:
(a) Implement the full-duplex reliable close handshake of TCP.
(a) TCPの全二重の信頼できる厳密な握手を実行してください。
The proper time to delay the final close step is not really
related to the MSL; it depends instead upon the RTO for the
FIN segments and therefore upon the RTT of the path. (It
could be argued that the side that is sending a FIN knows
what degree of reliability it needs, and therefore it should
be able to determine the length of the TIME-WAIT delay for
the FIN's recipient. This could be accomplished with an
appropriate TCP option in FIN segments.)
最終的な厳密なステップを遅らせる適切な時間は本当にMSLに関連しません。 それは代わりにFINセグメントのためのRTOとしたがって、経路のRTTによります。 (FINを送る側が、それがどの程度の信頼性を必要とするかを知っていると主張できて、したがって、それはFINの受取人のためにタイム誌-WAIT遅れの長さを測定できるべきです。 適切なTCPオプションでFINセグメントでこれを達成できました。)
Although there is no formal upper-bound on RTT, common
network engineering practice makes an RTT greater than 1
minute very unlikely. Thus, the 4 minute delay in TIME-WAIT
state works satisfactorily to provide a reliable full-duplex
TCP close. Note again that this is independent of MSL
enforcement and network speed.
どんな正式な上限もRTTにありませんが、一般的なネットワークエンジニアリング方式で、1分以上のRTTは非常にありそうもなくなります。 したがって、タイム誌-WAIT状態の4分の遅れは、信頼できる全二重TCP閉鎖を提供するために満足に働いています。 これがMSL実施とネットワーク速度から独立していることにもう一度注意してください。
The TIME-WAIT state could cause an indirect performance
problem if an application needed to repeatedly close one
connection and open another at a very high frequency, since
the number of available TCP ports on a host is less than
2**16. However, high network speeds are not the major
contributor to this problem; the RTT is the limiting factor
in how quickly connections can be opened and closed.
Therefore, this problem will be no worse at high transfer
speeds.
アプリケーションが繰り返して1つの接続を終えて、超短波で別のものを開く必要があるなら、タイム誌-WAIT州は間接的な性能問題を引き起こす場合があるでしょうに、ホストの上の利用可能なTCPポートの数が2**16より少ないので。 しかしながら、高いネットワーク速度はこの問題への一流の貢献者ではありません。 RTTは接続をどれくらいすぐに開いて、閉店させることができるかの限定因子です。 したがって、この問題は高い転送速度で、より悪くならないでしょう。
(b) Allow old duplicate segments to expire.
(b) 古い写しセグメントの期限が切れさせてください。
To replace this function of TIME-WAIT state, a mechanism
would have to operate across connections. PAWS is defined
strictly within a single connection; the last timestamp is
TS.Recent is kept in the connection control block, and
タイム誌-WAIT状態のこの関数を置き換えるために、メカニズムは接続の向こう側に動作しなければならないでしょう。 PAWSは単独結合の中で厳密に定義されます。 そして最後のタイムスタンプがTS.Recentが接続制御ブロックに保たれるということである。
Jacobson, Braden, & Borman [Page 28] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[28ページ]RFC1323TCP拡張子
discarded when a connection is closed.
接続が閉じられるとき、捨てられます。
An additional mechanism could be added to the TCP, a per-host
cache of the last timestamp received from any connection.
This value could then be used in the PAWS mechanism to reject
old duplicate segments from earlier incarnations of the
connection, if the timestamp clock can be guaranteed to have
ticked at least once since the old connection was open. This
would require that the TIME-WAIT delay plus the RTT together
must be at least one tick of the sender's timestamp clock.
Such an extension is not part of the proposal of this RFC.
最後のタイムスタンプの1ホストあたり1つのキャッシュが、どんな接続からも追加メカニズムをTCPに加えることができるのを受けました。 次に、接続の以前の肉体化から古い写しセグメントを拒絶するのにPAWSメカニズムでこの値を使用できました、年取った接続がオープンである時から少なくとも一度カチカチしたことがあるようにタイムスタンプ時計を保証できるなら。 これは、タイム誌-WAIT遅れと一緒にRTTが送付者のタイムスタンプ時計の少なくとも1回のカチカチする音であるに違いないことを必要とするでしょう。 そのような拡大はこのRFCの提案の一部ではありません。
Note that this is a variant on the mechanism proposed by
Garlick, Rom, and Postel [Garlick77], which required each
host to maintain connection records containing the highest
sequence numbers on every connection. Using timestamps
instead, it is only necessary to keep one quantity per remote
host, regardless of the number of simultaneous connections to
that host.
これが各ホストが含む中ですべての接続で一連番号最も高い接続記録を保守するのを要求したガーリック、Rom、およびポステル[Garlick77]によって提案されたメカニズムの上の異形であることに注意してください。 代わりにタイムスタンプを使用して、単にリモートホストあたり1つの量を保つのが必要です、そのホストへの同時接続の数にかかわらず。
Jacobson, Braden, & Borman [Page 29] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[29ページ]RFC1323TCP拡張子
APPENDIX C: CHANGES FROM RFC-1072, RFC-1185
付録C: RFC-1072、RFC-1185からの変化
The protocol extensions defined in this document differ in several important ways from those defined in RFC-1072 and RFC-1185.
本書では定義されたプロトコル拡大はRFC-1072とRFC-1185で定義されたものといくつかの重要な道において異なります。
(a) SACK has been deferred to a later memo.
(a) SACKは後のメモに延期されました。
(b) The detailed rules for sending timestamp replies (see Section
3.4) differ in important ways. The earlier rules could result
in an under-estimate of the RTT in certain cases (packets
dropped or out of order).
(b) 送付タイムスタンプ回答(セクション3.4を見る)のための細則は重要な道において異なります。 以前の規則がある場合にはRTTの過小をもたらすかもしれない、(パケット、低下するか故障する、)
(c) The same value TS.Recent is now shared by the two distinct
mechanisms RTTM and PAWS. This simplification became possible
because of change (b).
(c) 同じ値のTS.Recentは現在2時までに異なった状態で共有されたメカニズムのRTTMとPAWSです。 この簡素化は変化(b)のために可能になりました。
(d) An ambiguity in RFC-1185 was resolved in favor of putting
timestamps on ACK as well as data segments. This supports the
symmetry of the underlying TCP protocol.
(d) データ・セグメントと同様にACKにタイムスタンプを置くことを支持してRFC-1185のあいまいさは取り除かれました。 これは基本的なTCPプロトコルの対称を支持します。
(e) The echo and echo reply options of RFC-1072 were combined into a
single Timestamps option, to reflect the symmetry and to
simplify processing.
(e) RFC-1072のエコーとエコー・リプライオプションは、対称を反映して、処理を簡素化するためにただ一つのTimestampsオプションに結合されました。
(f) The problem of outdated timestamps on long-idle connections,
discussed in Section 4.2.2, was realized and resolved.
(f) セクション4.2.2で議論した長い無駄な接続に関する時代遅れのタイムスタンプの問題は、実現されて、解決されました。
(g) RFC-1185 recommended that header prediction take precedence over
the timestamp check. Based upon some scepticism about the
probabilistic arguments given in Section 4.2.4, it was decided
to recommend that the timestamp check be performed first.
(g) そのヘッダー予測が推薦されたRFC-1185はタイムスタンプチェックの上で優先します。 セクション4.2.4で与えられた確率的な議論に関する何らかの懐疑論に基づいて、それは、タイムスタンプチェックが最初に実行されることを勧めるために決められました。
(h) The spec was modified so that the extended options will be sent
on <SYN,ACK> segments only when they are received in the
corresponding <SYN> segments. This provides the most
conservative possible conditions for interoperation with
implementations without the extensions.
(h) それらであるときにだけ、拡張オプションを<SYNに送るように仕様を変更して、対応する<SYN>セグメントでACK>セグメントを受け取ります。 これは拡大なしでinteroperationに、可能な限り保守的な状態に実現を提供します。
In addition to these substantive changes, the present RFC attempts to specify the algorithms unambiguously by presenting modifications to the Event Processing rules of RFC-793; see Appendix E.
これらの実質的な変化に加えて、現在のRFCは、明白にRFC-793のEvent Processing規則への変更を提示することによってアルゴリズムを指定するのを試みます。 Appendix Eを見てください。
Jacobson, Braden, & Borman [Page 30] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[30ページ]RFC1323TCP拡張子
APPENDIX D: SUMMARY OF NOTATION
付録D: 記法の概要
The following notation has been used in this document.
以下の記法は本書では使用されました。
Options
オプション
WSopt: TCP Window Scale Option
TSopt: TCP Timestamps Option
WSopt: TCPウィンドウスケールオプションTSopt: TCPタイムスタンプオプション
Option Fields
オプション・フィールド
shift.cnt: Window scale byte in WSopt.
TSval: 32-bit Timestamp Value field in TSopt.
TSecr: 32-bit Timestamp Reply field in TSopt.
shift.cnt: WSoptの窓のスケールバイト。 TSval: TSoptの32ビットのTimestamp Value分野。 TSecr: TSoptの32ビットのTimestamp Reply分野。
Option Fields in Current Segment
現在のセグメントのオプション・フィールド
SEG.TSval: TSval field from TSopt in current segment.
SEG.TSecr: TSecr field from TSopt in current segment.
SEG.WSopt: 8-bit value in WSopt
SEG.TSval: 現在のセグメントのTSoptからのTSval分野。 SEG.TSecr: 現在のセグメントのTSoptからのTSecr分野。 SEG.WSopt: WSoptの8ビット値
Clock Values
時計値
my.TSclock: Local source of 32-bit timestamp values
my.TSclock.rate: Period of my.TSclock (1 ms to 1 sec).
my.TSclock: 32ビットのタイムスタンプの地元筋はmy.TSclock.rateを評価します: my.TSclock(1 1秒までのms)について以上。
Per-Connection State Variables
1接続あたりの州の変数
TS.Recent: Latest received Timestamp
Last.ACK.sent: Last ACK field sent
TS.Recent: 最新の容認されたTimestamp Last.ACK.sent: 最後のACK野原は発信しました。
Snd.TS.OK: 1-bit flag
Snd.WS.OK: 1-bit flag
Snd.TS.OK: 1ビットの旗のSnd.WS.OK: 1ビットの旗
Rcv.Wind.Scale: Receive window scale power
Snd.Wind.Scale: Send window scale power
Rcv.Wind.Scale: 窓のスケールパワーSnd.Wind.Scaleを受けてください: 窓のスケール権限を送ってください。
Jacobson, Braden, & Borman [Page 31] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[31ページ]RFC1323TCP拡張子
APPENDIX E: EVENT PROCESSING
付録E: イベント処理
Event Processing
イベント処理
OPEN Call
オープンコール
...
An initial send sequence number (ISS) is selected. Send a SYN
segment of the form:
... イニシャルは一連番号(ISS)を送ります。選択されます。 フォームのSYNセグメントを送ってください:
<SEQ=ISS><CTL=SYN><TSval=my.TSclock><WSopt=Rcv.Wind.Scale>
<SEQ=ISS><CTL=SYN><TSval=my.TSclock><WSopt=Rcv.Wind.Scale>。
...
...
SEND Call
呼び出しを送ってください。
CLOSED STATE (i.e., TCB does not exist)
閉じている状態(すなわち、TCBは存在していません)
...
...
LISTEN STATE
状態を聴いてください。
If the foreign socket is specified, then change the connection
from passive to active, select an ISS. Send a SYN segment
containing the options: <TSval=my.TSclock> and
<WSopt=Rcv.Wind.Scale>. Set SND.UNA to ISS, SND.NXT to ISS+1.
Enter SYN-SENT state. ...
外国ソケットが指定されるなら、受動態からアクティブになるまでの接続を変えてください、そして、ISSを選択してください。 オプションを含むSYNセグメントを送ってください: <TSval=my.TSclock>と<WSopt=Rcv.Wind.Scale>。 ISS、SND.NXTへのSND.UNAをISS+1に設定してください。 SYN-SENT状態に入ってください。 ...
SYN-SENT STATE
SYN-RECEIVED STATE
SYNによって送られた州のSYNによって容認された状態
...
...
ESTABLISHED STATE
CLOSE-WAIT STATE
確立した州の近い待ち状態
Segmentize the buffer and send it with a piggybacked
acknowledgment (acknowledgment value = RCV.NXT). ...
便乗している承認(承認値はRCV.NXTと等しい)と共にバッファをSegmentizeして、それを送ります。 ...
If the urgent flag is set ...
緊急の旗が設定されるなら…
If the Snd.TS.OK flag is set, then include the TCP Timestamps
option <TSval=my.TSclock,TSecr=TS.Recent> in each data segment.
Snd.TS.OK旗が設定されるなら、各データ・セグメントでTCP Timestampsオプション<TSval=my.TSclock、TSecr=TS.Recent>を含めてください。
Scale the receive window for transmission in the segment header:
スケール、トランスミッションのためにセグメントヘッダーで窓を受けてください:
SEG.WND = (SND.WND >> Rcv.Wind.Scale).
SEG.WNDは(SND.WND>>Rcv.Wind.Scale)と等しいです。
Jacobson, Braden, & Borman [Page 32] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[32ページ]RFC1323TCP拡張子
SEGMENT ARRIVES
セグメントは到着します。
...
...
If the state is LISTEN then
その時状態がLISTENであるなら
first check for an RST
まず最初に、RSTがないかどうかチェックしてください。
...
...
second check for an ACK
2番目に、ACKがないかどうかチェックしてください。
...
...
third check for a SYN
SYNがないかどうか3番目にチェックしてください。
if the SYN bit is set, check the security. If the ...
SYNビットが設定されるなら、セキュリティをチェックしてください。 …
...
...
If the SEG.PRC is less than the TCB.PRC then continue.
SEG.PRCがTCB.PRC以下であるなら、続いてください。
Check for a Window Scale option (WSopt); if one is found, save
SEG.WSopt in Snd.Wind.Scale and set Snd.WS.OK flag on.
Otherwise, set both Snd.Wind.Scale and Rcv.Wind.Scale to zero
and clear Snd.WS.OK flag.
Window Scaleオプション(WSopt)がないかどうかチェックしてください。 1つが見つけられるなら、Snd.Wind.ScaleとセットSnd.WS.OK旗でオンなSEG.WSoptを取っておいてください。 さもなければ、Snd.Wind.ScaleとRcv.Wind.Scaleの両方をゼロに設定してください。そうすれば、明確なSnd.WS.OKは弛みます。
Check for a TSopt option; if one is found, save SEG.TSval in the
variable TS.Recent and turn on the Snd.TS.OK bit.
TSoptオプションがないかどうかチェックしてください。 1つが見つけられるなら、可変TS.RecentにSEG.TSvalを取っておいてください、そして、Snd.TS.OKビットをつけてください。
Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any other
control or text should be queued for processing later. ISS
should be selected and a SYN segment sent of the form:
IRSはSEG.SEQに用意ができています、そして、SEG.SEQ+1にRCV.NXTを設定してください、そして、いかなる他のコントロールかテキストも後で処理のために列に並ばせられるべきです。 ISSは選択されるべきでした、そして、SYNセグメントはフォームを発信させました:
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN、ACK>。
If the Snd.WS.OK bit is on, include a WSopt option
<WSopt=Rcv.Wind.Scale> in this segment. If the Snd.TS.OK bit is
on, include a TSopt <TSval=my.TSclock,TSecr=TS.Recent> in this
segment. Last.ACK.sent is set to RCV.NXT.
Snd.WS.OKビットがオンであるなら、このセグメントでWSoptオプション<WSopt=Rcv.Wind.Scale>を含めてください。 Snd.TS.OKビットがオンであるなら、このセグメントでTSopt<TSval=my.TSclock、TSecr=TS.Recent>を含めてください。 Last.ACK.sentはRCV.NXTに用意ができています。
SND.NXT is set to ISS+1 and SND.UNA to ISS. The connection
state should be changed to SYN-RECEIVED. Note that any other
incoming control or data (combined with SYN) will be processed
in the SYN-RECEIVED state, but processing of SYN and ACK should
not be repeated. If the listen was not fully specified (i.e.,
the foreign socket was not fully specified), then the
unspecified fields should be filled in now.
SND.NXTはISSへのISS+1とSND.UNAに用意ができています。 接続状態はSYN-RECEIVEDに変わるべきです。 いかなる他の入って来るコントロールかデータ(SYNに結合される)もSYN-RECEIVED状態で加工処理されますが、SYNとACKの処理が繰り返されるべきでないことに注意してください。 聴取、完全に指定されているというわけではなくて(すなわち、外国ソケットは完全に指定されたというわけではありません)、そして、不特定の分野は現在、記入されるべきです。
Jacobson, Braden, & Borman [Page 33] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[33ページ]RFC1323TCP拡張子
fourth other text or control
他のテキストか4番目のコントロール
...
...
If the state is SYN-SENT then
その時状態がSYN-SENTであるなら
first check the ACK bit
まず最初に、ACKビットをチェックしてください。
...
...
fourth check the SYN bit
4番目にSYNビットをチェックしてください。
...
...
If the SYN bit is on and the security/compartment and precedence
are acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to
SEG.SEQ, and any acknowledgements on the retransmission queue
which are thereby acknowledged should be removed.
SYNビットがオンであり、セキュリティ/コンパートメントと先行がその時許容できるなら、RCV.NXTはSEG.SEQ+1に用意ができています、そして、IRSはSEG.SEQに用意ができています、そして、再送キューのその結果承諾されるどんな承認も移されるべきです。
Check for a Window Scale option (WSopt); if is found, save
SEG.WSopt in Snd.Wind.Scale; otherwise, set both Snd.Wind.Scale
and Rcv.Wind.Scale to zero.
Window Scaleオプション(WSopt)がないかどうかチェックしてください。 Snd.Wind.Scaleの備え付けることのセーブSEG.WSoptがそうなら さもなければ、Snd.Wind.ScaleとRcv.Wind.Scaleの両方をゼロに設定してください。
Check for a TSopt option; if one is found, save SEG.TSval in
variable TS.Recent and turn on the Snd.TS.OK bit in the
connection control block. If the ACK bit is set, use my.TSclock
- SEG.TSecr as the initial RTT estimate.
TSoptオプションがないかどうかチェックしてください。 1つが見つけられるなら、可変TS.RecentにSEG.TSvalを取っておいてください、そして、接続制御ブロックでSnd.TS.OKビットをつけてください。 ACKビットが設定されるなら、my.TSclockを使用してください--初期のRTT見積りとしてのSEG.TSecr。
If SND.UNA > ISS (our SYN has been ACKed), change the connection
state to ESTABLISHED, form an ACK segment:
SND.UNA>ISS(私たちのSYNはACKedである)であるなら、接続状態をESTABLISHEDに変えてください、そして、ACKセグメントを形成してください:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>。
and send it. If the Snd.Echo.OK bit is on, include a TSopt
option <TSval=my.TSclock,TSecr=TS.Recent> in this ACK segment.
Last.ACK.sent is set to RCV.NXT.
そして、それを送ってください。 Snd.Echo.OKビットがオンであるなら、このACKセグメントでTSoptオプション<TSval=my.TSclock、TSecr=TS.Recent>を含めてください。 Last.ACK.sentはRCV.NXTに用意ができています。
Data or controls which were queued for transmission may be
included. If there are other controls or text in the segment
then continue processing at the sixth step below where the URG
bit is checked, otherwise return.
トランスミッションのために列に並ばせられたデータかコントロールが含まれるかもしれません。 セグメントに他のコントロールかテキストがあれば、URGビットがチェックされるところの下の第6ステップで処理し続けてください。さもなければ、戻ってください。
Otherwise enter SYN-RECEIVED, form a SYN,ACK segment:
さもなければ、SYN-RECEIVEDに入ってください、そして、SYN、ACKセグメントを形成してください:
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN、ACK>。
and send it. If the Snd.Echo.OK bit is on, include a TSopt
option <TSval=my.TSclock,TSecr=TS.Recent> in this segment. If
そして、それを送ってください。 Snd.Echo.OKビットがオンであるなら、このセグメントでTSoptオプション<TSval=my.TSclock、TSecr=TS.Recent>を含めてください。 if
Jacobson, Braden, & Borman [Page 34] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[34ページ]RFC1323TCP拡張子
the Snd.WS.OK bit is on, include a WSopt option
<WSopt=Rcv.Wind.Scale> in this segment. Last.ACK.sent is set to
RCV.NXT.
Snd.WS.OKビットはオンであり、このセグメントでWSoptオプション<WSopt=Rcv.Wind.Scale>を含めてください。 Last.ACK.sentはRCV.NXTに用意ができています。
If there are other controls or text in the segment, queue them
for processing after the ESTABLISHED state has been reached,
return.
セグメントに他のコントロールかテキストがあれば、ESTABLISHED状態に達した後に処理のためにそれらを列に並ばせてください、リターン。
fifth, if neither of the SYN or RST bits is set then drop the
segment and return.
SYNかRSTビットのどちらも設定されないなら、5番目に、セグメントとリターンを落としてください。
Otherwise,
そうでなければ
First, check sequence number
まず最初に、一連番号をチェックしてください。
SYN-RECEIVED STATE
ESTABLISHED STATE
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
CLOSE-WAIT STATE
CLOSING STATE
LAST-ACK STATE
TIME-WAIT STATE
SYNによって容認された州は州のフィン待1ち州のフィン待2ちの終わりの州の最後のACK州の時間州の近い待ち状態待ち状態を確立しました。
Segments are processed in sequence. Initial tests on arrival
are used to discard old duplicates, but further processing is
done in SEG.SEQ order. If a segment's contents straddle the
boundary between old and new, only the new parts should be
processed.
セグメントは連続して処理されます。 古い写しを捨てるのに到着次第初期のテストを使用しますが、SEG.SEQオーダーでさらなる処理をします。 セグメントの内容が古く新しいことの間の境界にまたがっているなら、新しい部分だけが加工処理されるべきです。
Rescale the received window field:
受け取られていることの窓がさばくRescale:
TrueWindow = SEG.WND << Snd.Wind.Scale,
TrueWindowはSEG.WND<<Snd.Wind.Scaleと等しいです。
and use "TrueWindow" in place of SEG.WND in the following steps.
そして、以下のステップにおけるSEG.WNDに代わって"TrueWindow"を使用してください。
Check whether the segment contains a Timestamps option and bit
Snd.TS.OK is on. If so:
セグメントがTimestampsオプションを含んでいて、ビットSnd.TS.OKがオンであるかどうかチェックしてください。 そうだとすれば:
If SEG.TSval < TS.Recent, then test whether connection has
been idle less than 24 days; if both are true, then the
segment is not acceptable; follow steps below for an
unacceptable segment.
SEG.TSval<TS.Recentであるなら、接続が24日間未満無駄であるか否かに関係なく、テストしてください。 両方が本当であるなら、セグメントは許容できません。 容認できないセグメントのために下の方法に従ってください。
If SEG.SEQ is equal to Last.ACK.sent, then save SEG.ECopt in
variable TS.Recent.
SEG.SEQがLast.ACK.sentと等しいなら、可変TS.RecentにSEG.ECoptを取っておいてください。
Jacobson, Braden, & Borman [Page 35] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[35ページ]RFC1323TCP拡張子
There are four cases for the acceptability test for an incoming
segment:
入って来るセグメントのための受容性テストのための4つのケースがあります:
...
...
If an incoming segment is not acceptable, an acknowledgment
should be sent in reply (unless the RST bit is set, if so drop
the segment and return):
入って来るセグメントが許容できないなら、回答で承認を送るべきです(RSTビットが設定されない場合、そうだとすれば、セグメントとリターンを落としてください):
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>。
Last.ACK.sent is set to SEG.ACK of the acknowledgment. If the
Snd.Echo.OK bit is on, include the Timestamps option
<TSval=my.TSclock,TSecr=TS.Recent> in this ACK segment. Set
Last.ACK.sent to SEG.ACK and send the ACK segment. After
sending the acknowledgment, drop the unacceptable segment and
return.
Last.ACK.sentは承認のSEG.ACKに用意ができています。 Snd.Echo.OKビットがオンであるなら、このACKセグメントでTimestampsオプション<TSval=my.TSclock、TSecr=TS.Recent>を含めてください。 SEG.ACKにLast.ACK.sentを設定してください、そして、ACKセグメントを送ってください。 承認を送った後に、容認できないセグメントとリターンを落としてください。
...
...
fifth check the ACK field.
5番目にACK分野をチェックしてください。
if the ACK bit is off drop the segment and return.
ACKビットがオフであるなら、セグメントとリターンを落としてください。
if the ACK bit is on
ACKビットがオンであるなら
...
...
ESTABLISHED STATE
設立された状態
If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK.
Also compute a new estimate of round-trip time. If Snd.TS.OK
bit is on, use my.TSclock - SEG.TSecr; otherwise use the
elapsed time since the first segment in the retransmission
queue was sent. Any segments on the retransmission queue
which are thereby entirely acknowledged...
SND.UNA<SEG.ACKがその時<SND.NXTと等しいなら、SND.UNA<SEG.ACKを設定してください。 また、往復の時間の新しい見積りを計算してください。 Snd.TS.OKビットがオンであるなら、my.TSclockを使用してください--SEG.TSecr さもなければ、再送キューにおける最初のセグメントを送ったので、経過時間を費やしてください。 再送キューのその結果完全に承認されるどんなセグメントも…
...
...
Seventh, process the segment text.
7番目に、セグメントテキストを処理してください。
ESTABLISHED STATE
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
確立した州のフィン待1ち州のフィン待2ち状態
...
...
Send an acknowledgment of the form:
形式の承認を送ってください:
Jacobson, Braden, & Borman [Page 36] RFC 1323 TCP Extensions for High Performance May 1992
ジェーコブソン、ブレーデン、および高性能1992年5月のためのボーマン[36ページ]RFC1323TCP拡張子
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>。
If the Snd.TS.OK bit is on, include Timestamps option
<TSval=my.TSclock,TSecr=TS.Recent> in this ACK segment. Set
Last.ACK.sent to SEG.ACK of the acknowledgment, and send it.
This acknowledgment should be piggy-backed on a segment being
transmitted if possible without incurring undue delay.
Snd.TS.OKビットがオンであるなら、このACKセグメントでTimestampsオプション<TSval=my.TSclock、TSecr=TS.Recent>を含めてください。 承認のSEG.ACKにLast.ACK.sentを設定してください、そして、それを送ってください。 この承認は、できれば、不当な遅延を被らないで伝えられながら、セグメントで背負われるべきです。
...
...
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Van Jacobson University of California Lawrence Berkeley Laboratory Mail Stop 46A Berkeley, CA 94720
ヴァン・ジェーコブソン・カリフォルニア大学ローレンスバークレイ研究所メール停止46Aバークレー、カリフォルニア 94720
Phone: (415) 486-6411 EMail: van@CSAM.LBL.GOV
以下に電話をしてください。 (415) 486-6411 メールしてください: van@CSAM.LBL.GOV
Bob Braden University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ボブブレーデン南カリフォルニア情報Sciences Institute大学4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: (310) 822-1511 EMail: Braden@ISI.EDU
以下に電話をしてください。 (310) 822-1511 メールしてください: Braden@ISI.EDU
Dave Borman Cray Research 655-E Lone Oak Drive Eagan, MN 55121
655EのデーヴボーマンクレイリサーチのひとりのオークDriveイーガン、ミネソタ 55121
Phone: (612) 683-5571 Email: dab@cray.com
以下に電話をしてください。 (612) 683-5571 メールしてください: dab@cray.com
Jacobson, Braden, & Borman [Page 37]
ジェーコブソン、ブレーデン、およびボーマン[37ページ]
一覧
スポンサーリンク
