RFC1185 日本語訳
1185 TCP Extension for High-Speed Paths. V. Jacobson, R.T. Braden, L.Zhang. October 1990. (Format: TXT=49508 bytes) (Obsoleted by RFC1323) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group V. Jacobson
Request for Comments: 1185 LBL
R. Braden
ISI
L. Zhang
PARC
October 1990
コメントを求めるワーキンググループV.ジェーコブソン要求をネットワークでつないでください: 1185 LBL R.ブレーデンISI L.チャンPARC1990年10月
TCP Extension for High-Speed Paths
高速経路のためのTCP拡張子
Status of This Memo
このメモの状態
This memo describes an Experimental Protocol extension to TCP 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.
このメモは、インターネットコミュニティのためにExperimentalプロトコル拡張子についてTCPに説明して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Summary
概要
This memo describes a small extension to TCP to support reliable operation over very high-speed paths, using sender timestamps transmitted using the TCP Echo option proposed in RFC-1072.
このメモは非常に高速な経路の上の信頼できる操作を支持するために小さい拡大についてTCPに説明します、RFC-1072で提案されたTCP Echoオプションを使用することで伝えられた送付者タイムスタンプを使用して。
1. INTRODUCTION
1. 序論
TCP uses positive acknowledgments and retransmissions to provide reliable end-to-end delivery over a full-duplex virtual circuit called a connection [Postel81]. A connection is defined by its two end points; each end point is a "socket", i.e., a (host,port) pair. To protect against data corruption, TCP uses an end-to-end checksum. Duplication and reordering are handled using a fine-grained sequence number space, with each octet receiving a distinct sequence number.
TCPは、接続[Postel81]と呼ばれる全二重の仮想のサーキットの上に終わりから終わりへの信頼できる配送を供給するのに肯定応答と「再-トランスミッション」を使用します。 接続は2つのエンドポイントによって定義されます。 各エンドポイントは「ソケット」、すなわち、(ホスト、ポート)組です。 データの汚染から守るために、TCPは終わりから終わりへのチェックサムを使用します。 複製と再命令は、異なった一連番号を受ける各八重奏と共にきめ細かに粒状の一連番号スペースを使用することで扱われます。
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. In practice, proper TCP implementations have demonstrated remarkable robustness in adapting to a wide range of network characteristics. For example, 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.
TCPプロトコル[Postel81]は、通信速度、遅れ、不正、複製、またはセグメントを再命令することにかかわらずほとんどどんなトランスミッション媒体の上でも確かに作動するように設計されました。 実際には、適切なTCP実現はさまざまなネットワークの特性に順応する際に顕著な丈夫さを示しました。 例えば、TCP実現は現在、10**7ビーピーエスと往復へのビーピーエスが範囲1msで100秒まで遅らせる100の範囲で転送レートに順応します。
However, 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 and RFC- 1072 [Jacobson88] propose modest extensions to TCP to extend the
しかしながら、光ファイバーの導入は、より絶えず高い伝送速度をもたらしています、そして、最も速い経路はTCPが元々設計されたドメインから引っ越しています。 このメモとRFC1072[Jacobson88]は、広がるように穏やかな拡大をTCPに提案します。
Jacobson, Braden & Zhang [Page 1] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[1ページ]RFC1185TCP
domain of its application to higher speeds.
より高い速度へのアプリケーションのドメイン。
There is no one-line answer to the question: "How fast can TCP go?". The issues are reliability and performance, and these depend upon the round-trip delay and the maximum time that segments may be queued in the Internet, as well as upon the transmission speed. We must think through these relationships very carefully if we are to successfully extend TCP's domain.
1線の質問の答が全くありません: 「どれくらい速く、TCPは行くことができますか?」? 問題は、信頼性と性能です、そして、これらは往復の遅れとセグメントがインターネットに列に並ばせられるかもしれない最大の時間と、伝送速度に依存します。 首尾よく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. RFC-1072 proposed a set of TCP extensions to improve TCP efficiency for "LFNs" (long fat networks), i.e., networks with large bandwidth*delay products.
TCP性能は転送レート自体ではなく、むしろ転送レートの製品と往復の遅れに依存します。 この「帯域幅*遅れ製品」は「パイプをいっぱいにする」データ量を測定します。 それは経路の上のTCP関係に関する最大のスループットを得るのに送付者と受信機で必要であるバッファ領域です。 RFC-1072は、「LFNs」(長い太っているネットワーク)(すなわち、大きい帯域幅*遅れ製品があるネットワーク)のためにTCP効率を高めるために1セットのTCP拡張子を提案しました。
On the other hand, high transfer rate can threaten TCP reliability by violating the assumptions behind the TCP mechanism for duplicate detection and sequencing. The present memo specifies a solution for this problem, extending TCP reliability to transfer rates well beyond the foreseeable upper limit of bandwidth.
他方では、高い転送レートは、写し検出と配列のために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, was delivered to the receiver at the wrong moment so that its sequence numbers fell 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 lock up the connection so that no further progress can be made and a RST is required to resynchronize the two ends.
特に重大な種類の誤りはデータ・セグメントにおける、TCP一連番号の偶然の再利用から生じるかもしれません。 一連番号が間違った瞬間に「古い写しセグメント」(例えばインターネット待ち行列で遅れた重複データセグメント)を受信機に渡したので現在の窓の中のどこかまで下がったと仮定してください。 誤りを警告しないチェックサムのことが全くないでしょう、そして、結果はデータの非検出された不正であるかもしれません。 送信機の古い写しACKセグメントのレセプションはわずかにだけ重大であったはずがありません: それが接続を監禁しそうであるので、さらなる進歩を全く作ることができないで、RSTが2つの終わりを再連動させるのに必要です。
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 may be delayed in
queues. Section 2 discusses this case and proposes a mechanism
to reject old duplicates on the current connection.
TCP一連番号は32ビットを含んでいます。 十分高い転送レートでは、32ビットの系列スペースはセグメントが待ち行列で遅れるかもしれない時中に「包装されるかもしれない」(循環します)。 セクション2は、現在の接続に関する古い写しを拒絶するために本件について論じて、メカニズムを提案します。
(2) Segment from an earlier connection incarnation
(2) 以前の接続肉体化からのセグメント
Jacobson, Braden & Zhang [Page 2] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[2ページ]RFC1185TCP
Suppose 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. This case is discussed in Section 3.
接続が適切な近い系列かホストクラッシュのため終わって、同じ接続(すなわち、ソケットの同じ組を使用する)がすぐに再開すると仮定してください。 終えられた接続からの遅れたセグメントは、新しい肉体化のために現在の窓の中で低下して、有効であるとして認めることができました。 セクション3で本件について議論します。
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分野によって励行されます。
Watson's Delta-T protocol [Watson81] includes network-layer mechanisms for precise enforcement of an MSL. In contrast, the IP 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). The timestamp algorithm described in the following section gives a way out of this dilemma for high-speed networks.
ワトソンのデルタ-Tプロトコル[Watson81]はMSLの正確な実施のためのネットワーク層メカニズムを含んでいます。 対照的に、MSL実施のためのIPメカニズムは、緩く定義されて、インターネットで、より緩く実行さえされます。 したがって、TCP接続のためにMSLの活発な実施によるのが賢明でなく、現行価値より小さくMSLのものを設定すると想像するのは非現実的です(例えば120秒はTCPに指定しました)。 以下のセクションで説明されたタイムスタンプアルゴリズムは高速ネットワークのためのこのジレンマから崩れます。
2. SEQUENCE NUMBER WRAP-AROUND
2. 一連番号巻きつけて着るドレス
2.1 Background
2.1 バックグラウンド
Avoiding reuse of sequence numbers within the same connection is
simple in principle: enforce a segment lifetime shorter than the
time it takes to cycle the sequence space, whose size is
effectively 2**31.
同じ接続の中で一連番号の再利用を避けるのは原則として簡単です: 事実上、サイズが2**31である系列スペースを循環させるためにそれがかかる時間より短いセグメント生涯を実施してください。
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 & Zhang [Page 3] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[3ページ]RFC1185TCP
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 why wrap-around of the sequence space was 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の一連番号スペースを循環させると対応しています。
Based on this reasoning, an earlier RFC [McKenzie89] has cautioned
that expanding the TCP window space as proposed in RFC-1072 will
lead to sequence wrap-around and hence to possible data
corruption. We believe that this is mis-identifying the culprit,
which is not the larger window but rather the high bandwidth.
この推理に基づいて、以前のRFC[McKenzie89]は、RFC-1072で提案されるようにTCP窓のスペースを広げるのが系列巻きつけて着るドレスと、そして、したがって、可能なデータの汚染に導くと警告しました。 私たちは、これが罪人にもかかわらず、どれが、より大きい窓でないか、しかし、むしろ高帯域を誤認していると信じています。
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
例えば、10kmの直径がある(非常に大きい)のFDDI LANを考えてください。 光速を使用して、私たちがリングの向こう側にRTTを計算できる、(2、*10**4) /、(3 *10**8)は67マイクロセカンド等しく、そして、遅れ*帯域幅生成物は833バイトです。 833バイトだけの窓を使用するこのLANの向こう側のTCP関係は、完全な100mbpsを走って、TCPのMSLのおよそ3分非常に近く系列スペースを包むことができます。 その結果、高いです。
Jacobson, Braden & Zhang [Page 4] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[4ページ]RFC1185TCP
speed alone can cause a reliability problem with sequence
number wrap-around, even without extended windows.
速度だけが一連番号巻きつけて着るドレスと、そして、拡張窓なしでさえ信頼性の問題を引き起こす場合があります。
An "obvious" fix for the problem of cycling the sequence space is
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. However, the proposals for
making such a change while maintaining compatibility with current
TCP have tended towards complexity and ugliness.
系列スペースを循環させるという問題のための「明白な」フィックスはTCP一連番号分野のサイズを増加させることです。 例えば、一連番号分野(そして、承認分野も)を64ビットに広げることができました。 しかしながら、現在のTCPとの互換性を維持している間、そのような変更を行うための提案は複雑さと醜さの傾向がありました。
This memo proposes a simple solution to the problem, using the TCP
echo options defined in RFC-1072. Section 2.2 which follows
describes the original use of these options to carry timestamps in
order to measure RTT accurately. Section 2.3 proposes a method of
using these same timestamps to reject old duplicate segments that
could corrupt an open TCP connection. Section 3 discusses the
application of this mechanism to avoiding old duplicates from
previous incarnations.
RFC-1072で定義されたTCPエコーオプションを使用して、このメモは問題の簡単な解決を提案します。 セクション2.2 どれが続くかが正確にRTTを測定するためにタイムスタンプを運ぶためにこれらのオプションのオリジナルの使用について説明します。 セクション2.3はオープンなTCP接続を買収できた古い写しセグメントを拒絶するこれらの同じタイムスタンプを使用する方法を提案します。 セクション3は前の肉体化からの古い写しを避けるのにこのメカニズムの応用について論じます。
2.2 TCP Timestamps
2.2 TCPタイムスタンプ
RFC-1072 defined two TCP options, Echo and Echo Reply. Echo
carries a 32-bit number, and the receiver of the option must
return this same value to the source host in an Echo Reply option.
RFC-1072は2つのTCPオプション、Echo、およびEcho Replyを定義しました。 エコーは32ビットの数を運びます、そして、オプションの受信機はEcho Replyオプションでこの同じ値を送信元ホストに返さなければなりません。
RFC-1072 furthermore describes the use of these options to contain
32-bit timestamps, for measuring the RTT. A TCP sending data
would include Echo options containing the current clock value.
The receiver would echo these timestamps in returning segments
(generally, ACK segments). The difference between a timestamp
from an Echo Reply option and the current time would then measure
the RTT at the sender.
その上、RFC-1072は、RTTを測定するための32ビットのタイムスタンプを含むようにこれらのオプションの使用について説明します。 データを送るTCPは現在の時計値を含むEchoオプションを含んでいるでしょう。 受信機は戻っているセグメント(一般にACKセグメント)でこれらのタイムスタンプを反映するでしょう。 そして、Echo Replyオプションからのタイムスタンプと現在の時間の違いは送付者でRTTを測定するでしょう。
This mechanism was designed to solve the following problem: almost
all TCP implementations base their RTT measurements on a sample of
only one packet per window. 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). Unfortunately, this lower sampling frequency
violates Nyquist's criteria and may introduce "aliasing" artifacts
into the estimated RTT [Hamming77].
このメカニズムは以下の問題を解決するように設計されました: ほとんどすべてのTCP実現がそれらのRTT測定値を1窓あたり1つのパケットだけのサンプルに基礎づけます。 私たちが信号加工上の問題(それがそうである)としてRTT見積りを見るなら、何らかの頻度(パケットレート)におけるデータ信号は下側の頻度(窓のレート)で抽出されています。 残念ながら、この下側のサンプリング周波数は、Nyquistの評価基準に違反して、およそRTT[Hamming77]に「エイリアシング」人工物を紹介するかもしれません。
A good RTT estimator with a conservative retransmission timeout
calculation can tolerate the 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
サンプリング周波数が「近いところにデータ頻度の」あるとき、保守的な再送タイムアウト計算の良いRTT見積り人はエイリアシングを許容できます。 例えば、8つのパケットの窓、見本郵送料率と共に、1/8があります。データ頻度--1桁の異なるよりそれほど。 しかしながら、窓が10か何百ものパケットである、いつ、RTT見積り人は真剣にいるかもしれないか。
Jacobson, Braden & Zhang [Page 5] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[5ページ]RFC1185TCP
error, resulting in spurious retransmissions.
偽物の「再-トランスミッション」をもたらす誤り。
A solution to the aliasing problem that actually simplifies the
sender substantially (since the RTT code is typically the single
biggest protocol cost for TCP) is as follows: the will sender
place a timestamp in each segment and the receiver will reflect
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). RFC-1072 defined a timestamp echo option for
this purpose.
実際に実質的(RTTコードが通常TCPに、ただ一つの最も大きいプロトコル費用であるので)に送付者を簡素化するエイリアシング問題の解決は以下の通りです: 各セグメントと受信機のタイムスタンプがACKセグメントでこれらのタイムスタンプを映し出す意志の送付者場所。 シングルが引き算するその時はあらゆるACKセグメント(分別がある受信機で他のあらゆるデータ・セグメントに対応する)のための正確なRTT測定を送付者に与えます。 RFC-1072はこのためにタイムスタンプエコーオプションを定義しました。
It is vitally important to use the timestamp echo option 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.
大きい窓によるタイムスタンプエコーオプションを使用するのはきわめて重要です。 さもなければ、ドアはエイリアシングによるいくつかの危険な不安定性に開けられます。 その上、送付者を簡素化するので、オプションはたぶんTCPのすべてのものの役に立ちます。
2.3 Avoiding Old Duplicate Segments
2.3 古い写しセグメントを避けること。
Timestamps carried from sender to receiver in TCP Echo options can
also be used to prevent data corruption caused by sequence number
wrap-around, as this section describes.
また、一連番号巻きつけて着るドレスによって引き起こされたデータの汚染を防ぐのにTCP Echoオプションで送付者から受信機まで運ばれたタイムスタンプは使用できます、このセクションが説明するように。
2.3.1 Basic Algorithm
2.3.1 基本的なアルゴリズム
Assume that every received TCP segment contains a timestamp.
The basic idea is that a segment received with a timestamp that
is earlier than the timestamp of the most recently accepted
segment can be discarded as an old duplicate. More
specifically, the following processing is to be performed on
normal incoming segments:
あらゆる容認されたTCPセグメントがタイムスタンプを含むと仮定してください。 基本的な考え方はセグメントに古い写しとして最も最近受け入れられたセグメントに関するタイムスタンプを捨てることができるより初期のタイムスタンプで受信されたということです。 より明確に、以下の処理は正常な入って来るセグメントに実行されることです:
R1) If the timestamp in the arriving segment timestamp is less
than the timestamp of the most recently received in-
sequence segment, treat the arriving segment as not
acceptable:
R1) 到着しているセグメントタイムスタンプのタイムスタンプが最近受け取られた大部分に関するタイムスタンプ以下であるなら、中でセグメントを配列してください、そして、許容できないとして到着セグメントを扱ってください:
If SEG.LEN > 0, send an acknowledgement in reply as
specified in RFC-793 page 69, and drop the segment;
otherwise, just silently drop the segment.*
SEG.LEN>0であるなら、RFC-793 69ページにおける指定されるとしての回答における承認を送ってください、そして、セグメントを落としてください。 そうでなければ、ただ静かにセグメントを落としてください、*
_________________________ *Sending an ACK segment in reply is not strictly necessary, since the case can only arise when a later in-order segment has already been received. However, for consistency and simplicity, we suggest treating a timestamp failure the same way TCP treats any other unacceptable segment.
_________________________ *回答におけるACKセグメントを送るのは厳密に必要ではありません、既にオーダーにおける後のセグメントを受け取ったときだけ、ケースが起こることができるので。 しかしながら、一貫性と簡単さのために、私たちは、TCPがいかなる他の容認できないセグメントも扱う同じようにタイムスタンプ失敗を扱うことを提案します。
Jacobson, Braden & Zhang [Page 6] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[6ページ]RFC1185TCP
R2) If the segment is outside the window, reject it (normal
TCP processing)
R2) 窓の外にセグメントがあるなら、それを拒絶してください。(通常のTCP処理)
R3) If an arriving segment is in-sequence (i.e, at the left
window edge), accept it normally and record its timestamp.
R3) 到着セグメントが連続して(左の窓の縁のi.e)であるなら、通常、それを受け入れてください、そして、タイムスタンプを記録してください。
R4) Otherwise, treat the segment as a normal in-window, out-
of-sequence TCP segment (e.g., queue it for later delivery
to the user).
R4) さもなければ、窓で正常なaとしてセグメントを扱ってください、系列の出ているTCPセグメント(例えば、後の配送のためにユーザへそれを列に並ばせてください)。
Steps R2-R4 are the normal TCP processing steps specified by
RFC-793, except that in R3 the latest timestamp is set from
each in-sequence segment that is accepted. Thus, the latest
timestamp recorded at the receiver corresponds to the left edge
of the window and only advances when the left edge moves
[Jacobson88].
ステップR2-R4はRFC-793によって指定された、通常のTCP処理ステップです、最新のタイムスタンプがR3に系列の受け入れられる各セグメントから設定されるのを除いて。 したがって、受信機に記録された最新のタイムスタンプは、窓の左の縁に対応している、左の縁が[Jacobson88]を動かすときだけ、進みます。
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 is queued. 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 highest in-sequence
timestamp 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, the receivers's current timestamp is set to 2.
セグメントが系列であると仮定してください: A.1、B.1、C.1…, Z.1(手紙は一連番号を示す)を送りました、そして、ケタはタイムスタンプを表します。 また、そのセグメントB.1がなくされたと仮定してください。 系列の最も高いタイムスタンプは1(A.1からの)であり、そうはC.1です…, Z.1は許容できると考えられて、列に並ばせられます。 BがセグメントB.2として再送されるとき(最新のタイムスタンプを使用して)、それは、穴をふさいでいて、Zを通したすべてのセグメントがユーザに承認されて、渡されることを引き起こします。 列に並ばせられたセグメントに関するタイムスタンプは*ではなく、既にそれらを受け入れて以来このとき再び点検されている*です。 B.2を受け入れるとき、受信機sの現在のタイムスタンプを2に設定します。
This rule is vital to allow reasonable performance under loss.
A full 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
それがセグメントであるともう一度仮定してください: A.1、B.1、C.1…, Z.1はそうしました。
Jacobson, Braden & Zhang [Page 7] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[7ページ]RFC1185TCP
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.
送られた系列とそのセグメント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 ACK's, then the
queued segments that caused these ACK's must have been received
already.
本件は非常に起こりそうにはありません。 「再-トランスミッション」がタイムアウト、セグメントC.1、…のいくつかによって引き起こされたなら Z.1はRTO時間より長い間、遅れたに違いありません。 おそらく、これはありそうもない出来事です、または多くの偽りのタイムアウトと「再-トランスミッション」があるでしょう。 すなわち、「速く再送してください」というアルゴリズム、写しACKのものがビーズの「再-トランスミッション」を引き起こしたなら、既にACKのこれらのものを引き起こした列に並ばせられたセグメントを受け取ったに違いありません。
Even if a segment was delayed past the RTO, the selective
acknowledgment (SACK) facility of RFC-1072 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の先で遅らせられたとしても、B.2と同時にRFC-1072の選択している承認(SACK)施設で遅れたパケットを再送するでしょう、余分なRTTを避けて、したがって、非常に小さいパフォーマンスに不利な条件を引き起こします。
We know of no case with a significant probability of occurrence
in which timestamps will cause performance degradation by
unnecessarily discarding segments.
私たちはタイムスタンプが不必要にセグメントを捨てることによって性能退行を引き起こす発生の重要な確率があるケースを全く知りません。
2.3.2 Header Prediction
2.3.2 ヘッダー予測
"Header prediction" [Jacobson90] is a high-performance
transport protocol implementation technique that is 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?"
高速リンクに、[Jacobson90]が高性能トランスポート・プロトコル実現のテクニックであるという「ヘッダー予測」は最も重要です。 このテクニックは最も一般的なケースのためにコードを最適化します: 正しさと注文におけるセグメントを受けます。 ヘッダー予測を使用して、受信機は、「このセグメントは系列の次ですか?」と質問します。 質問より少ない機械語命令、「窓の中にこのセグメントはありますか?」でこの質問に答えることができます。
Adding header prediction to our timestamp procedure leads to
the following 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.
H3) 通常、RFC-793で指定されるようにセグメントを処理してください。
Jacobson, Braden & Zhang [Page 8] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[8ページ]RFC1185TCP
This includes dropping segments that are outside the
window and possibly sending acknowledgments, and queueing
in-window, out-of-sequence segments.
窓、ことによると発信している承認、および待ち行列の外で窓であるセグメントを落とす順序が狂ってセグメントをこれは含んでいます。
However, the timestamp check in step H1 is very unlikely to
fail, and it is a relatively expensive operation since it
requires interval arithmetic on a finite field. To perform
this check on every single segment seems like poor
implementation engineering, defeating the purpose of header
prediction. Therefore, we suggest that an implementor
interchange H1 and H2, i.e., perform header prediction FIRST,
performing H1 and H3 only if header prediction fails. We
believe that this change might gain 5-10% in performance on
high-speed networks.
しかしながら、ステップH1でのタイムスタンプチェックは非常に失敗しそうにはありません、そして、それは、有限フィールドで区間算術を必要とするので、比較的高価な操作です。 ヘッダー予測の目的をくつがえして、あらゆるセグメントにこのチェックを実行するのは貧しい実現工学のように見えます。 したがって、私たちは、作成者がH1とH2を交換することを提案します、すなわち、ヘッダー予測FIRSTを実行してください、ヘッダー予測が失敗する場合にだけH1とH3を実行して。 私たちは、この変化が高速ネットワークに関する性能で%を5-10に獲得するかもしれないと信じています。
This reordering does raise a theoretical hazard: a segment from
2**32 bytes in the past may arrive at exactly the wrong time
and be accepted mistakenly by the header-prediction step. We
make the following argument to show that the probability of
this failure is negligible.
この再命令は理論上の危険を上げます: 過去の2**32バイトからのセグメントはまさに間違った時間に到着して、ヘッダー予測ステップで誤って受け入れるかもしれません。 私たちは、この失敗の確率が取るにたらないのを示すために以下の議論をします。
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チェックサムの信頼性を超えているプロトコルメカニズムは「十分良い」と考えられるべきです、すなわち、それは総合誤差率にかなり貢献しないでしょう。 したがって、私たちは、タイムスタンプをチェックする前にヘッダーに予測することによって受け入れられる古い写しの問題を無視できると信じています。
2.3.3 Timestamp Frequency
2.3.3 タイムスタンプ頻度
It is important to understand that the receiver algorithm for
timestamps does not involve clock synchronization with the
sender. The sender's clock is used to stamp the segments, and
the sender uses this fact to measure RTT's. However, the
タイムスタンプのための受信機アルゴリズムが送付者との時計同期を伴わないのを理解しているのは重要です。 送付者の時計はセグメントを押し込むのに使用されます、そして、送付者はRTTのものを測定するのにこの事実を使用します。 しかしながら
Jacobson, Braden & Zhang [Page 9] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[9ページ]RFC1185TCP
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.
受信機は時計との少しも必要な接続なしで単にa単調増加通し番号としてタイムスタンプを扱います。 受信機の観点から、タイムスタンプは一連番号の高位のビットの論理的な拡大として機能しています。
However, the receiver algorithm dpes place some requirements on
the frequency of the timestamp "clock":
しかしながら、受信機アルゴリズムdpesは「時計」というタイムスタンプの頻度にいくつかの要件を置きます:
(a) 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 ~2 Gbps; a 1ms clock will work up to link
speeds of 2 Tbps (10**12 bps!).
この以上を量的にするように、1カチカチする音/秒より速いどんな時計も~2Gbpsのリンク速度のために古い写しセグメントを拒絶するでしょう。 1ms時計は2Tbpsのリンク速度をあおるでしょう(10**12ビーピーエス!)。
(b) Timestamp clock must not be "too fast".
(b) タイムスタンプ時計は「速過ぎてはいけません」。
Its cycling 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, since the sender is using the timestamp for RTT
calculations, the timestamp doesn't need to have much more
resolution than the granularity of the retransmit timer,
e.g., tens or hundreds of milliseconds.
しかしながら、送付者がRTT計算にタイムスタンプを使用しているので、タイムスタンプは再送信タイマ、例えば、10の粒状か何百ミリセカンドよりもはるかに多くの解決を必要としません。
Thus, both limits are easily satisfied with a reasonable clock
rate in the range 1-100ms per tick.
したがって、両方の限界は容易に1-100 1カチカチする音あたりの範囲msの妥当なクロックレートに満たされています。
Using the timestamp option relaxes the requirements on MSL for
avoiding sequence number wrap-around. For example, with a 1 ms
timestamp clock, the 32-bit timestamp will wrap its sign bit in
25 days. Thus, it will reject old duplicates on the same
connection as long as MSL is 25 days or less. This appears to
be a very safe figure. If the timestamp has 10 ms resolution,
the MSL requirement is boosted to 250 days. An MSL of 25 days
or longer can probably be assumed by the gateway system without
requiring precise MSL enforcement by the TTL value in the IP
layer.
タイムスタンプオプションを使用すると、MSLに関する要件は、一連番号巻きつけて着るドレスを避けるためにリラックスします。 例えば、1個のmsタイムスタンプ時計で、32ビットのタイムスタンプは25日間後に符号ビットを包装するでしょう。 したがって、それはMSLが25日間以下である限り、同じ接続に関する古い写しを拒絶するでしょう。 これは非常に安全な図であるように見えます。 タイムスタンプに10ms解決があるなら、MSL要件は250日間まで上げられます。 IP層のTTL値で正確なMSL実施を必要としないで、ゲートウェイシステムはたぶん25日間のMSLを想定できます。
Jacobson, Braden & Zhang [Page 10] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[10ページ]RFC1185TCP
3. DUPLICATES FROM EARLIER INCARNATIONS OF CONNECTION
3. 前から、接続の肉体化をコピーします。
We turn now to the second potential cause of old duplicate packet errors: packets from an earlier incarnation of the same connection. The appendix contains a review the mechanisms currently included in TCP to handle this problem. These mechanisms depend upon the enforcement of a maximum segment lifetime (MSL) by the Internet layer.
私たちは今、古い写しパケット誤りの2番目の潜在的原因に変わります: 同じ接続の以前の肉体化からのパケット。 付録はメカニズムが現在この問題を扱うためにTCPに含んだレビューを含んでいます。 これらのメカニズムはインターネット層のそばで最大のセグメント生涯(MSL)の実施によります。
The MSL required to prevent failures due to an earlier connection incarnation does not depend (directly) upon the transfer rate. However, the timestamp option used as described in Section 2 can provide additional security against old duplicates from earlier connections. Furthermore, we will see that with the universal use of the timestamp option, enforcement of a maximum segment lifetime would no longer be required for reliable TCP operation.
以前の接続肉体化のため失敗を防がなければならなかったMSLは(直接)転送レートによりません。 しかしながら、セクション2で説明されるように使用されるタイムスタンプオプションは古い写しに対して以前の接続から追加担保を提供できます。 その上、私たちは、タイムスタンプオプションの普遍的な使用で、最大のセグメント生涯の実施は信頼できるTCP操作にもう必要でないことがわかるでしょう。
There are two cases to be considered (see the appendix for more explanation): (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つのセクションで説明されるでしょう。
3.1 System Crash with Loss of State
3.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 seem to 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. Fortunately, we can back off from this
strict requirement. Suppose that the clock is always re-
synchronized to within N timestamp clock ticks and that booting
静かな時間を完全に省くのはホスト時計がクラッシュ/再開の期間、1つのタイムスタンプの時計カチカチする音の精度で安定したか、または、より良い時間ソースに連動するのが必要であるように思えるでしょう。 幸い、私たちはこの厳しい要件から引き返すことができます。 時計がいつもNタイムスタンプ時計カチカチする音とその穂ばらみに再連動すると仮定してください。
Jacobson, Braden & Zhang [Page 11] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[11ページ]RFC1185TCP
(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がなくても古い写しを拒絶するのにタイムスタンプを使用できます)。
3.2 Closing and Reopening a Connection
3.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. This delay
serves two different purposes:
TCP接続が閉じられるとき、タイム誌-WAITの2*MSLの遅れは4分間ソケット組に結びつきを述べます。[Postel81]のセクション3.5を見てください。(1つの接続を終えて、新しいものを開くTCPで組立てられたアプリケーション(例えば、Streamモードを使用しているFTPデータ転送コネクション)がその都度新しいソケット組を選ばなければならない、この遅れは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.*
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.
最終的な厳密なステップを遅らせる適切な時間は本当にMSLに関連しません。 それは代わりにFINセグメントのためのRTOとしたがって、経路のRTTによります。*どんな正式な上限も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 no worse at high transfer
speeds.
アプリケーションが繰り返して1つの接続を終えて、超短波で別のものを開く必要があるなら、タイム誌-WAIT州は間接的な性能問題を引き起こす場合があるでしょうに、ホストの上の利用可能なTCPポートの数が2**16より少ないので。 しかしながら、高いネットワーク速度はこの問題への一流の貢献者ではありません。 RTTは接続をどれくらいすぐに開いて、閉店させることができるかの限定因子です。 したがって、この問題は高い転送速度で、よりひどくそうしないでしょう。
(b) Allow old duplicate segements to expire.
(b) 古い写しsegementsの期限が切れさせてください。
Suppose that a host keeps a cache of the last timestamp
received from each remote host. This can be used to reject
old duplicate segments from earlier incarnations of the
_________________________
*Note: 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.
ホストが、それぞれのリモートホストから最後のタイムスタンプのキャッシュを受け取り続けると仮定してください。 以前の肉体化からの古い写しセグメントを拒絶するのにこれを使用できます。_________________________ *以下に注意してください。 FINを送る側が、それがどの程度の信頼性を必要とするかを知っていると主張できて、したがって、それはFINの受取人のためにタイム誌-WAIT遅れの長さを測定できるべきです。 適切なTCPオプションでFINセグメントでこれを達成できました。
Jacobson, Braden & Zhang [Page 12] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[12ページ]RFC1185TCP
connection, if the timestamp clock can be guaranteed to have
ticked at least once since the old conennection was open.
This requires that the TIME-WAIT delay plus the RTT together
must be at least one tick of the sender's timestamp clock.
接続、以来に少なくとも一度カチカチしたことがあるようにタイムスタンプ時計を保証できるなら、古いconennectionは開いていました。 これは、タイム誌-WAIT遅れと一緒にRTTが送付者のタイムスタンプ時計の少なくとも1回のカチカチする音であるに違いないことを必要とします。
Note that this is a variant on the mechanism proposed by
Garlick, Rom, and Postel (see the appendix), 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、およびポステル(付録を見る)によって提案されたメカニズムの上の異形であることに注意してください。 代わりにタイムスタンプを使用して、単にリモートホストあたり1つの量を保つのが必要です、そのホストへの同時接続の数にかかわらず。
We conclude that if all hosts used the TCP timestamp algorithm
described in Section 2, enforcement of a maximum segment lifetime
would be unnecessary and the quiet time at system startup could be
shortened or removed. In any case, the timestamp mechanism can
provide additional security against old duplicates from earlier
connection incarnations. However, a 4 minute TIME-WAIT delay
(unrelated to MSL enforcement or network speed) must be retained
to provide the reliable close handshake of TCP.
私たちは、すべてのホストがセクション2で説明されたTCPタイムスタンプアルゴリズムを使用するなら、最大のセグメント生涯の実施が不要であり、システム起動における静かな時間を短くしたか、または取り除くことができたと結論を下します。 どのような場合でも、タイムスタンプメカニズムは古い写しに対して以前の接続肉体化から追加担保を提供できます。 しかしながら、TCPの信頼できる厳密な握手を提供するために、4分のタイム誌-WAIT遅れ(MSL実施かネットワーク速度に関係ない)を保有しなければなりません。
4. CONCLUSIONS
4. 結論
We have presented a mechanism, based upon the TCP timestamp echo option of RFC-1072, that will allow very high TCP transfer rates without reliability problems due to old duplicate segments on the same connection. This mechanism also provides additional security against intrusion of old duplicates from earlier incarnations of the same connection. If the timestamp mechanism were used by all hosts, the quiet time at system startup could be eliminated and enforcement of a maximum segment lifetime (MSL) would no longer be necessary.
私たちは同じ接続のときに古い写しセグメントのため信頼性の問題なしで非常に高いTCP転送レートを許容するRFC-1072のTCPタイムスタンプエコーオプションに基づくメカニズムを提示しました。 また、このメカニズムは古い写しの押しつけに対して同じ接続の以前の肉体化から追加担保を提供します。 タイムスタンプメカニズムがすべてのホストによって使用されるなら、システム起動における静かな時間を排除できるでしょうに、そして、最大のセグメント生涯(MSL)の実施はもう必要でないでしょう。
REFERENCES
参照
[Cerf76] Cerf, V., "TCP Resynchronization", Tech Note #79, Digital Systems Lab, Stanford, January 1976.
[Cerf76]サーフ、V.、"TCP Resynchronization"科学技術の注意#79、デジタル・システム研究室、スタンフォード、1976年1月。
[Dalal74] Dalal, Y., "More on Selecting Sequence Numbers", INWG Protocol Note #4, October 1974.
[Dalal74] Dalal、INWGが「さらにセレクティングシーケンス番号」で議定書の中で述べるY.は#4、1974年10月に注意します。
[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。
Jacobson, Braden & Zhang [Page 13] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[13ページ]RFC1185TCP
[Jacobson88] Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay Paths", RFC 1072, LBL and USC/Information Sciences Institute, October 1988.
[Jacobson88] RFC1072、LBL、およびUSC/情報科学は、1988年10月にジェーコブソン、V.、およびR.ブレーデン、「長時間の遅延経路のためのTCP拡張子」と設けます。
[Jacobson90] Jacobson, V., "4BSD Header Prediction", ACM Computer Communication Review, April 1990.
[Jacobson90] ジェーコブソン、V.、「4BSDヘッダー予測」、ACMコンピュータコミュニケーションレビュー、1990年4月。
[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月。
[Postel81] Postel, J., "Transmission Control Protocol", RFC 793, DARPA, September 1981.
[Postel81] ポステル、J.、「通信制御プロトコル」、RFC793、DARPA、1981年9月。
[Tomlinson74] Tomlinson, R., "Selecting Sequence Numbers", INWG Protocol Note #2, September 1974.
[Tomlinson74] トムリンスン、R.、「セレクティングシーケンス番号」、INWGプロトコル注意#2、1974年9月。
[Watson81] Watson, R., "Timer-based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.
[Watson81] ワトソン、R.、「信頼できるトランスポート・プロトコル接続管理におけるタイマベースのメカニズム」、コンピュータネットワーク、Vol.5、1981。
Jacobson, Braden & Zhang [Page 14] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[14ページ]RFC1185TCP
APPENDIX -- Protection against Old Duplicates in TCP
付録--TCPの古い写しに対する保護
During the development of TCP, a great deal of effort was devoted to the problem of protecting a TCP connection from segments left from earlier incarnations of the same connection. Several different mechanisms were proposed for this purpose [Tomlinson74] [Dalal74] [Cerf76] [Garlick77].
TCPの開発の間、大きな努力が同じ接続の以前の肉体化から残っているセグメントからTCP接続を保護するという問題にささげられました。 数個の異なったメカニズムがこのために[Tomlinson74][Dalal74][Cerf76][Garlick77]提案されました。
The connection parameters that are required in this discussion are:
この議論で必要である接続パラメタは以下の通りです。
Tc = Connection duration in seconds.
Tcは秒に接続持続時間と等しいです。
Nc = Total number of bytes sent on connection.
Total Nc=バイト数は接続を転送しました。
B = Effective bandwidth of connection = Nc/Tc.
接続の有効なB=帯域幅はNc/Tcと等しいです。
Tomlinson proposed a scheme with two parts: a clock-driven selection of ISN (Initial Sequence Number) for a connection, and a resynchronization procedure [Tomlinson74]. The clock-driven scheme chooses:
トムリンスンは2つの部品で計画を提案しました: 接続、および再同期手順[Tomlinson74]のためのISN(初期のSequence Number)の時計駆動の選択。 時計駆動の計画は選ばれます:
ISN = (integer(R*t)) mod 2**32 [2]
ISNは(整数(R*t))モッズ2**32と等しいです。[2]
where t is the current time relative to an arbitrary origin, and R is a constant. R was intended to be chosen so that ISN will advance faster than sequence numbers will be used up on the connection. However, at high speeds this will not be true; the consequences of this will be discussed below.
tが任意の起源に比例した現在の時間であり、Rが定数であるところ。 ISNが一連番号が接続のときに使いきられるより速く進むようにRが選ばれることを意図しました。 しかしながら、高速では、これは当てはまらないでしょう。 以下でこの結果について議論するでしょう。
The clock-driven choice of ISN in formula [2] guarantees freedom from old duplicates matching a reopened connection if the original connection was "short-lived" and "slow". By "short-lived", we mean a connection that stayed open for a time Tc less than the time to cycle the ISN, i.e., Tc < 2**32/R seconds. By "slow", we mean that the effective transfer rate B is less than R.
公式[2]におけるISNの時計駆動の選択はオリジナルの接続が「短命で」「遅かった」なら再開している接続に合っている古い写しから自由を保証します。 「短命」で、私たちは時間ISNを循環させる時間ほどTcを営業させなかった接続を言っています、すなわち、32/R秒のTc<2**。 「遅くなってください」で、私たちは、有効な転送率BがRより少ないと言っています。
This is illustrated in Figure 1, where sequence numbers are plotted against time. The asterisks show the ISN lines from formula [2], while the circles represent the trajectories of several short-lived incarnations of the same connection, each terminating at the "x".
これは図1で例証されます。そこでは、一連番号が時間に対して記入されます。 アスタリスクは公式[2]からISN線を示しています、円が同じ接続の数回の短命な肉体化の軌道を表しますが、「x」でそれぞれ終わって。
Note: allowing rapid reuse of connections was believed to be an
important goal during the early TCP development. This
requirement was driven by the hope that TCP would serve as a
basis for user-level transaction protocols as well as
connection-oriented protocols. The paradigm discussed was the
"Christmas Tree" or "Kamikazee" segment that contained SYN and
FIN bits as well as data. Enthusiasm for this was somewhat
以下に注意してください。 接続の急速な再利用を許すのは早めのTCP開発の間の重要な目標であると信じられていました。 この要件はTCPがユーザレベル取引プロトコルの基礎として機能するだろうという望みでやる気満々の、そして、接続指向のプロトコルでした。 議論したパラダイムはデータと同様にSYNとFINビットを含んだ「クリスマスツリー」か"Kamikazee"セグメントでした。 これに対する熱意はいくらかそうでした。
Jacobson, Braden & Zhang [Page 15] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[15ページ]RFC1185TCP
dampened when it was observed that the 3-way SYN handshake and
the FIN handshake mean that 5 packets are required for a minimum
exchange. Furthermore, the TIME-WAIT state delay implies that
the same connection really cannot be reopened immediately. No
further work has been done in this area, although existing
applications (especially SMTP) often generate very short TCP
sessions. The reuse problem is generally avoided by using a
different port pair for each connection.
3ウェイSYN握手とFIN握手が、5つのパケットが最小の交換に必要であることを意味するのを観測されたとき、湿っています。 その上、タイム誌-WAIT州の遅れは、同じ接続がすぐに本当に再開できないのを含意します。 既存のアプリケーション(特にSMTP)は非常に短いTCPセッションをしばしば発生させますが、この領域でさらなる仕事を全くしていません。 一般に、再利用問題は、各接続に異なったポート組を使用することによって、避けられます。
|- 2**32 ISN ISN
| * *
| * *
| * *
| *x *
| o *
^ | * *
| | * x *
| * o *
S | *o *
e | o *
q | * *
| * *
# | * x *
| *o *
|o_______________*____________
^ Time -->
4.55hrs
|、-、2**32ISN ISN| * * | * * | * * | *x*| o * ^ | * * | | * x*| * o * S| *o * e| o * q| * * | * * # | * x*| *o * |o_______________*____________ ^時間--4.55時間の>。
Figure 1. Clock-Driven ISN avoiding duplication on
short-Lived, slow connections.
図1。 急に送られて、遅い接続のときに重複を避ける時計駆動のISN。
However, clock-driven ISN selection does not protect against old duplicate packets for a long-lived or fast connection: the connection may close (or crash) just as the ISN has cycled around and reached the same value again. If the connection is then reopened, a datagram still in transit from the old connection may fall into the current window. This is illustrated by Figure 2 for a slow, long- lived connection, and by Figures 3 and 4 for fast connections. In each case, the point "x" marks the place at which the original connection closes or crashes. The arrow in Figure 2 illustrates an old duplicate segment. Figure 3 shows a connection whose total byte count Nc < 2**32, while Figure 4 concerns Nc >= 2**32.
しかしながら、時計駆動のISN選択は長命の、または、速い接続のために古い写しパケットから守りません: ちょうど、ISNが自転車を乗り回して、再び同じ値に達したとき、接続は閉じるかもしれません(クラッシュしてください)。 次に、接続が再開するなら、年取った接続からのまだトランジットにおけるデータグラムは現在の窓になるかもしれません。 これは遅くて、長い間送られた接続のための図2、および速い接続のための図3と4によって例証されます。 その都度、ポイント「x」はオリジナルの接続が閉じるか、またはクラッシュする場所を示します。 図2の矢は古い写しセグメントを例証します。 図3は、だれの総バイトがNc<2**32を数えるかを接続に示しますが、図4は、>が2**32と等しいのがNcに関係があります。
To prevent the duplication illustrated in Figure 2, Tomlinson proposed to "resynchronize" the connection sequence numbers if they
図2で例証された複製を防ぐために、トムリンスンは、それらであるなら接続一連番号が"再連動"であるよう提案しました。
Jacobson, Braden & Zhang [Page 16] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[16ページ]RFC1185TCP
came within an MSL of the ISN. Resynchronization might take the form of a delay (point "y") or the choice of a new sequence number (point "z").
ISNのMSLに含まれました。 Resynchronizationは遅れの形(ポイント「y」)か新しい一連番号の選択(ポイント「z」)を取るかもしれません。
|- 2**32 ISN ISN
| * *
| * *
| * *
| * *
| * *
^ | * *
| | * *
| * *
S | * *
e | * x* y
q | * o *
| * o *z
# | *o *
| * *
|*_________________*____________
^ Time -->
4.55hrs
|、-、2**32ISN ISN| * * | * * | * * | * * | * * ^ | * * | | * * | * * S| * * e| * x*y q| * o * | * o *z#| *o * | * * |*_________________*____________ ^時間--4.55時間の>。
Figure 2. Resynchronization to Avoid Duplication
on Slow, Long-Lived Connection
図2。 遅くて、長命の接続のときに重複を避けるResynchronization
|- 2**32 ISN ISN
| * *
| x o * *
| * *
| o-->o* *
| * *
^ | o o *
| | * *
| o * *
S | * *
e | o * *
q | * *
| o* *
# | * *
| o *
|*_________________*____________
^ Time -->
4.55hrs
|、-、2**32ISN ISN| * * | x o**| * * | o-->o* * | * * ^ | o o * | | * * | o * * S| * * e| o * * q| * * | o* * # | * * | o * |*_________________*____________ ^時間--4.55時間の>。
Figure 3. Duplication on Fast Connection: Nc < 2**32 bytes
図3。 速い接続の複製: Nc<2**32バイト
Jacobson, Braden & Zhang [Page 17] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[17ページ]RFC1185TCP
|- 2**32 ISN ISN
| o * *
| x * *
| * *
| o * *
| o *
^ | * *
| | o * *
| * o *
S | * *
e | o * *
q | * o *
| * *
# | o *
| * o *
|*_________________*____________
^ Time -->
4.55hrs
|、-、2**32ISN ISN| o * * | x**| * * | o * * | o * ^ | * * | | o * * | * o * S| * * e| o * * q| * o * | * * # | o * | * o * |*_________________*____________ ^時間--4.55時間の>。
Figure 4. Duplication on Fast Connection: Nc > 2**32 bytes
図4。 速い接続の複製: Nc>2**32バイト
In summary, Figures 1-4 illustrated four possible failure modes for old duplicate packets from an earlier incarnation. We will call these four modes F1 , F2, F3, and F4:
概要では、図1-4は古い写しパケットのために以前の肉体化から4つの可能な故障モードを例証しました。 私たちは、これらの4つのモードをF1、F2、F3、およびF4と呼ぶつもりです:
F1: B < R, Tc < 4.55 hrs. (Figure 1)
F1: B<R、4.55時間のTc<。 (図1)
F2: B < R, Tc >= 4.55 hrs. (Figure 2)
F2: B<R、4.55時間のTc>= (図2)
F3: B >= R, Nc < 2**32 (Figure 3)
F3: B>はR、Nc<2**32と等しいです。(図3)
F4: B >= R, Nc >= 2**32 (Figure 4)
F4: B>はRと等しく、Nc>は2**32と等しいです。(図4)
Another limitation of clock-driven ISN selection should be mentioned. Tomlinson assumed that the current time t in formula [2] is obtained from a clock that is persistent over a system crash. For his scheme to work correctly, the clock must be restarted with an accuracy of 1/R seconds (e.g, 4 microseconds in the case of TCP). While this may be possible for some hosts and some crashes, in most cases there will be an uncertainty in the clock after a crash that ranges from a second to several minutes.
時計駆動のISN選択の別の制限は言及されるべきです。 トムリンスンは、公式[2]の現在の時間tがシステムクラッシュについてしつこい時計から得られると仮定しました。 彼の計画が正しくうまくいくために、1/R秒(e.g、TCPの場合における4マイクロセカンド)の精度で時計を再開しなければなりません。 何人かのホストといくつかのクラッシュに、これが可能であるかもしれない間、多くの場合、不確実性が1秒から数分まで及ぶクラッシュの後に時計にあるでしょう。
As a result of this random clock offset after system reinitialization, there is a possibility that old segments sent before the crash may fall into the window of a new connection incarnation. The solution to this problem that was adopted in the
システム再初期化の後に相殺されたこの無作為の時計の結果、クラッシュが新しい接続肉体化の窓になるかもしれない前に古いセグメントが発信した可能性があります。 それが採用されたこの問題の解決
Jacobson, Braden & Zhang [Page 18] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[18ページ]RFC1185TCP
final TCP spec is a "quiet time" of MSL seconds when the system is initialized [Postel81, p. 28]. No TCP connection can be opened until the expiration of this quiet time.
最終的なTCP仕様はシステムが初期化されるMSL秒の「静かな時間」です。[Postel81、p。 28]. この静かな時間の満了までTCP接続を全く開くことができません。
A different approach was suggested by Garlick, Rom, and Postel [Garlick77]. Rather than using clock-driven ISN selection, they proposed to maintain connection records containing the last ISN used on every connection. To immediately open a new incarnation of a connection, the ISN is taken to be greater than the last sequence number of the previous incarnation, so that the new incarnation will have unique sequence numbers. To handle a system crash, they proposed a quiet time, i.e., a delay at system startup time to allow old duplicates to expire. Note that the connection records need be kept only for MSL seconds; after that, no collision is possible, and a new connection can start with sequence number zero.
異なるアプローチはガーリック、Rom、およびポステル[Garlick77]によって提案されました。 時計駆動のISN選択を使用するよりむしろ、彼らは、すべての接続のときに使用された最後のISNを含む接続記録を保守するよう提案しました。 前の肉体化の最後の一連番号よりすばらしくなるようにISNを取ります、すぐに肉体化のような新しい接続を開くなら新しい肉体化にはユニーク配列番号があるように。 システムクラッシュを扱うために、彼らは静かな時間(すなわち、古い写しが期限が切れるのを許容するシステム起動時の遅れ)を提案しました。 記録が必要とする接続がMSL秒だけの間保たれることに注意してください。 その後に、どんな衝突も可能ではありません、そして、新しい接続は一連番号ゼロから始まることができます。
The scheme finally adopted for TCP combines features of both these proposals. TCP uses three mechanisms:
TCPのために最終的に採用された計画はこれらの提案の両方の特徴を結合します。 TCPは3つのメカニズムを使用します:
(A) ISN selection is clock-driven to handle short-lived connections.
The parameter R = 250KBps, so that the ISN value cycles in
2**32/R = 4.55 hours.
(A) ISN選択は、短命な接続を扱うために時計による駆動です。 パラメタRが250KBpsと等しいので、ISN値は=4.55時間2**32/Rを循環します。
(B) (One end of) a closed connection is left in a "busy" state,
known as "TIME-WAIT" state, for a time of 2*MSL. TIME-WAIT
state handles the proper close of a long-lived connection
without resynchronization. It also allows reliable completion
of the full-duplex close handshake.
(B)、(片端、)、閉じている接続は「時間待ち」状態として知られている「忙しい」状態に2*MSLの時間に残されます。 タイム誌-WAIT州は再同期なしで長命の接続の適切な閉鎖を扱います。 また、それは全二重の厳密な握手の信頼できる完成を許します。
(C) There is a quiet time of one MSL at system startup. This
handles a crash of a long-lived connection and avoids time
resynchronization problems in (A).
(C) システム起動には1MSLの静かな時間があります。 これは、長命の接続のクラッシュを扱って、(A)で時間再同期問題を避けます。
Notice that (B) and (C) together are logically sufficient to prevent accidental reuse of sequence numbers from a different incarnation, for any of the failure modes F1-F4. (A) is not logically necessary since the close delay (B) makes it impossible to reopen the same TCP connection immediately. However, the use of (A) does give additional assurance in a common case, perhaps compensating for a host that has set its TIME-WAIT state delay too short.
失敗モードF1-F4のいずれに関しても(B)と一緒に(C)が異なった肉体化から一連番号の偶然の再利用を防ぐために論理的に十分であるのに注意してください。 (A) 近い遅れ(B)ですぐに同じTCP接続を再開させるのは以来に不可能に論理的になる必要はありません。 しかしながら、(A)の使用はよくある例で追加保証を与えます、恐らくあまりに急にタイム誌-WAIT州の遅れを設定したホストを補って。
Some TCP implementations have permitted a connection in the TIME-WAIT state to be reopened immediately by the other side, thus short- circuiting mechanism (B). Specifically, a new SYN for the same socket pair is accepted when the earlier incarnation is still in TIME-WAIT state. Old duplicates in one direction can be avoided by choosing the ISN to be the next unused sequence number from the preceding connection (i.e., FIN+1); this is essentially an
いくつかのTCP実現が、タイム誌-WAIT状態での接続はその結果、すぐ反対側、短いcircuitingメカニズム(B)によって再開させられることを許可しました。 以前の肉体化がまだタイム誌-WAIT状態にあるとき、明確に、同じソケット組新しいSYNを受け入れます。 前の接続(すなわち、FIN+1)から次の未使用の一連番号になるようにISNを選ぶことによって、一方向への古い写しを避けることができます。 これは本質的にはそうです。
Jacobson, Braden & Zhang [Page 19] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[19ページ]RFC1185TCP
application of the scheme of Garlick, Rom, and Postel, using the connection block in TIME-WAIT state as the connection record.
接続記録としてタイム誌-WAIT状態での接続ブロックを使用するガーリック、Rom、およびポステルの計画のアプリケーション。
However, the connection is still vulnerable to old duplicates in the other direction. Mechanism (A) prevents trouble in mode F1, but failures can arise in F2, F3, or F4; of these, F2, on short, fast connections, is the most dangerous.
しかしながら、接続はもう片方の指示でまだ古い写しに傷つきやすいです。 メカニズム(A)はモードF1における問題を防ぎますが、失敗はF2、F3、またはF4に起こることができます。 これらでは、短くて、速い接続のときに、F2は最も危険です。
Finally, we note TCP will operate reliably without any MSL-based mechanisms in the following restricted domain:
最終的に、私たちは、TCPが以下の制限されたドメインの少しもMSLベースのメカニズムなしで確かに作動することに注意します:
* Total data sent is less then 2**32 octets, and
* そして送られた総データが、より少ない当時の2**32八重奏である。
* Effective sustained rate less than 250KBps, and
* そして250KBpsより少ない有効な持続しているレート。
* Connection duration less than 4.55 hours.
* 4.55時間未満の接続持続時間。
At the present time, the great majority of current TCP usage falls into this restricted domain. The third component, connection duration, is the most commonly violated.
現在では、現在のTCP用法の大多数はこの制限されたドメインに落ちます。 3番目のコンポーネント(接続持続時間)は最も一般的に違反されます。
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: (213) 822-1511 EMail: Braden@ISI.EDU
以下に電話をしてください。 (213) 822-1511 メールしてください: Braden@ISI.EDU
Jacobson, Braden & Zhang [Page 20] RFC 1185 TCP over High-Speed Paths October 1990
経路1990年10月高速な上のジェーコブソン、ブレーデン、およびチャン[20ページ]RFC1185TCP
Lixia Zhang XEROX Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304
Lixiaチャンゼロックスパロアルト研究センター3333コヨーテヒル・Roadパロアルト、カリフォルニア 94304
Phone: (415) 494-4415 EMail: lixia@PARC.XEROX.COM
以下に電話をしてください。 (415) 494-4415 メールしてください: lixia@PARC.XEROX.COM
Jacobson, Braden & Zhang [Page 21]
ジェーコブソン、ブレーデン、およびチャン[21ページ]
一覧
スポンサーリンク
