RFC1644 日本語訳
1644 T/TCP -- TCP Extensions for Transactions FunctionalSpecification. R. Braden. July 1994. (Format: TXT=87362 bytes) (Updates RFC1379) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Braden Request for Comments: 1644 ISI Category: Experimental July 1994
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 1644年のISIカテゴリ: 実験的な1994年7月
T/TCP -- TCP Extensions for Transactions
Functional Specification
T/TCP--、トランザクションに、機能的なTCP拡張子、仕様
Status of this Memo
このMemoの状態
This memo describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. It does not specify an Internet Standard. Distribution is unlimited.
このメモは改良のためにインターネットコミュニティ、要求議論、および提案のためのExperimentalプロトコルについて説明します。 それはインターネットStandardを指定しません。 分配は無制限です。
Abstract
要約
This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This backwards-compatible extension could fill the gap between the current connection-oriented TCP and the datagram-based UDP.
このメモは効率的なトランザクション指向(要求/応答)のサービスにT/TCP、実験的なTCP拡張子を指定します。 この後方にコンパチブル拡大は現在の接続指向のTCPとデータグラムベースのUDPの不足をいっぱいにするかもしれません。
This work was supported in part by the National Science Foundation under Grant Number NCR-8922231.
この仕事はグラントNumber NCR-8922231の下で国立科学財団によって一部サポートされました。
Table of Contents
目次
1. INTRODUCTION .................................................. 2
2. OVERVIEW ..................................................... 3
2.1 Bypassing the Three-Way Handshake ........................ 4
2.2 Transaction Sequences .................................... 6
2.3 Protocol Correctness ..................................... 8
2.4 Truncating TIME-WAIT State ............................... 12
2.5 Transition to Standard TCP Operation ..................... 14
3. FUNCTIONAL SPECIFICATION ..................................... 17
3.1 Data Structures .......................................... 17
3.2 New TCP Options .......................................... 17
3.3 Connection States ........................................ 19
3.4 T/TCP Processing Rules ................................... 25
3.5 User Interface ........................................... 28
4. IMPLEMENTATION ISSUES ........................................ 30
4.1 RFC-1323 Extensions ...................................... 30
4.2 Minimal Packet Sequence .................................. 31
4.3 RTT Measurement .......................................... 31
4.4 Cache Implementation ..................................... 32
4.5 CPU Performance .......................................... 32
4.6 Pre-SYN Queue ............................................ 33
6. ACKNOWLEDGMENTS .............................................. 34
7. REFERENCES ................................................... 34
APPENDIX A. ALGORITHM SUMMARY ................................... 35
1. 序論… 2 2. 概要… 3 2.1 3方向ハンドシェイクを迂回させます… 4 2.2 トランザクション系列… 6 2.3 正当性について議定書の中で述べてください… 8 2.4 時間待ち状態に先端を切らせます… 12 標準のTCP操作への2.5変遷… 14 3. 機能的な仕様… 17 3.1のデータ構造… 17 3.2 新しいTCPオプション… 17 3.3 接続州… 19 3.4 T/TCP処理は統治されます… 25 3.5ユーザーインタフェース… 28 4. 実装問題… 30 4.1 RFC-1323拡張子… 30 4.2 最小量のパケット系列… 31 4.3 RTT測定… 31 4.4 実装をキャッシュしてください… 32 4.5CPUパフォーマンス… 32 4.6 プレSYNは列を作ります… 33 6. 承認… 34 7. 参照… 34付録A.アルゴリズム概要… 35
Braden [Page 1] RFC 1644 Transaction/TCP July 1994
ブレーデン[1ページ]RFC1644トランザクション/TCP1994年7月
Security Considerations .......................................... 38 Author's Address ................................................. 38
セキュリティ問題… 38作者のアドレス… 38
1. INTRODUCTION
1. 序論
TCP was designed to around the virtual circuit model, to support streaming of data. Another common mode of communication is a client-server interaction, a request message followed by a response message. The request/response paradigm is used by application-layer protocols that implement transaction processing or remote procedure calls, as well as by a number of network control and management protocols (e.g., DNS and SNMP). Currently, many Internet user programs that need request/response communication use UDP, and when they require transport protocol functions such as reliable delivery they must effectively build their own private transport protocol at the application layer.
TCPは、データのストリーミングをサポートするように事実上の回路モデルの周りに設計されました。 要求メッセージは、応答メッセージでコミュニケーションの別の一般的なモードがクライアント/サーバ相互作用であるのに続きました。 多くのトランザクション処理を実装する応用層プロトコルか遠隔手続き呼び出し、ネットワーク制御、および管理プロトコル(例えば、DNSとSNMP)によって要求/応答パラダイムは使用されます。 現在、要求/応答コミュニケーションを必要とする多くのインターネットユーザ・プログラムがUDPを使用します、そして、彼らが信頼できる配信などの輸送プロトコル機能を必要とするとき、事実上、それらは応用層でそれら自身の個人的なトランスポート・プロトコルを築き上げなければなりません。
Request/response, or "transaction-oriented", communication has the following features:
要求/応答の、または、「トランザクション指向」のコミュニケーションには、以下の特徴があります:
(a) The fundamental interaction is a request followed by a response.
(a) 基本的な相互作用は応答がいうことになった要求です。
(b) An explicit open or close phase may impose excessive overhead.
(b) 明白な開いているか近いフェーズは過度のオーバーヘッドを課すかもしれません。
(c) At-most-once semantics is required; that is, a transaction must
not be "replayed" as the result of a duplicate request packet.
(c)、大部分、一度、意味論が必要です。 写しリクエスト・パケットの結果としてすなわち、トランザクションを「再演してはいけません」。
(d) The minimum transaction latency for a client should be RTT +
SPT, where RTT is the round-trip time and SPT is the server
processing time.
(d) クライアントにとって、最小のトランザクション潜在はRTT+SPTであるべきです。(そこでは、RTTが往復の時間であり、SPTはサーバ処理時間です)。
(e) In favorable circumstances, a reliable request/response
handshake should be achievable with exactly one packet in each
direction.
(e) 順境では、信頼できる要求/応答握手はちょうど各方向への1つのパケットで達成可能であるべきです。
This memo concerns T/TCP, an backwards-compatible extension of TCP to provide efficient transaction-oriented service in addition to virtual-circuit service. T/TCP provides all the features listed above, except for (e); the minimum exchange for T/TCP is three segments.
このメモは、T/TCP、TCPの後方にコンパチブル拡大が仮想の回路サービスに加えた効率的なトランザクション指向のサービスを提供するのが関係があります。 T/TCPは(e)を除いて、上にリストアップされたすべての特徴を提供します。 T/TCPに、最小の交換は3つのセグメントです。
In this memo, we use the term "transaction" for an elementary request/response packet sequence. This is not intended to imply any of the semantics often associated with application-layer transaction processing, like 3-phase commits. It is expected that T/TCP can be used as the transport layer underlying such an application-layer service, but the semantics of T/TCP is limited to transport-layer services such as reliable, ordered delivery and at-most-once
このメモでは、私たちは基本の要求/応答パケット系列に「トランザクション」という用語を使用します。 3フェーズが公約するようにこれがしばしば応用層トランザクション処理に関連している意味論のどれかを含意することを意図しません。 そして、そのような応用層サービスの基礎となるトランスポート層としてT/TCPを使用できると予想されますが、T/TCPの意味論が信頼できて、注文された配送などのトランスポート層サービスに制限される、大部分、一度
Braden [Page 2] RFC 1644 Transaction/TCP July 1994
ブレーデン[2ページ]RFC1644トランザクション/TCP1994年7月
operation.
操作。
An earlier memo [RFC-1379] presented the concepts involved in T/TCP. However, the real-world usefulness of these ideas depends upon practical issues like implementation complexity and performance. To help explore these issues, this memo presents a functional specification for a particular embodiment of the ideas presented in RFC-1379. However, the specific algorithms in this memo represent a later evolution than RFC-1379. In particular, Appendix A in RFC-1379 explained the difficulties in truncating TIME-WAIT state. However, experience with an implementation of the RFC-1379 algorithms in a workstation later showed that accumulation of TCB's in TIME-WAIT state is an intolerable problem; this necessity led to a simple solution for truncating TIME-WAIT state, described in this memo.
以前のメモ[RFC-1379]はT/TCPにかかわる概念を提示しました。 しかしながら、これらの考えの本当の世界の有用性は実装の複雑さと性能のような実用的な問題に依存します。 これらの問題を探るのを助けるために、このメモはRFC-1379に提示された考えの特定の実施例のための機能的な仕様を提示します。 しかしながら、このメモの特定のアルゴリズムはRFC-1379より遅い発展を表します。 特に、RFC-1379のAppendix Aはタイム誌-WAIT状態に先端を切らせることにおける苦労について説明しました。 しかしながら、ワークステーションのRFC-1379アルゴリズムの実装の経験は、後でタイム誌-WAIT状態でのTCBの蓄積が堪え難い問題であることを示しました。 この必要性はこのメモで説明されたタイム誌-WAIT状態に先端を切らせるための簡単なソリューションにつながりました。
Section 2 introduces the T/TCP extensions, and section 3 contains the complete specification of T/TCP. Section 4 discusses some implementation issues, and Appendix A contains an algorithmic summary. This document assumes familiarity with the standard TCP specification [STD-007].
セクション2はT/TCP拡張子を紹介します、そして、セクション3はT/TCPの完全な仕様を含みます。 セクション4はいくつかの導入問題について論じます、そして、Appendix Aはアルゴリズムの概要を含んでいます。 このドキュメントは標準のTCP仕様[STD-007]への親しみを仮定します。
2. OVERVIEW
2. 概要
The TCP protocol is highly symmetric between the two ends of a connection. This symmetry is not lost in T/TCP; for example, T/TCP supports TCP's symmetric simultaneous open from both sides (Section 2.3 below). However, transaction sequences use T/TCP in a highly unsymmetrical manner. It is convenient to use the terms "client host" and "server host" for the host that initiates a connection and the host that responds, respectively.
TCPプロトコルは接続の2つの終わりの間で非常に左右対称です。 この対称はT/TCPで失われていません。 例えば、T/TCPは両側(以下のセクション2.3)からTCPの左右対称の同時の戸外をサポートします。 しかしながら、トランザクション系列は非常に「非-対称」の方法でT/TCPを使用します。 接続と応じるホストを開始するホストに「クライアントホスト」と「サーバー・ホスト」という用語を使用するのはそれぞれ便利です。
The goal of T/TCP is to allow each transaction, i.e., each request/response sequence, to be efficiently performed as a single incarnation of a TCP connection. Standard TCP imposes two performance problems for transaction-oriented communication. First, a TCP connection is opened with a "3-way handshake", which must complete successfully before data can be transferred. The 3-way handshake adds an extra RTT (round trip time) to the latency of a transaction.
T/TCPの目標は、各トランザクション、すなわち、それぞれの要求/応答系列を許容して、TCP肉体化のような単一の接続として効率的に実行されることです。 標準のTCPはトランザクション指向のコミュニケーションのために2つの性能問題を課します。 まず最初に、TCP接続は「3ウェイ握手」で開かれます。(データを移すことができる前にそれは、首尾よく完成しなければなりません)。 3ウェイ握手は付加的なRTT(周遊旅行時間)をトランザクションの潜在に加えます。
The second performance problem is that closing a TCP connection leaves one or both ends in TIME-WAIT state for a time 2*MSL, where MSL is the maximum segment lifetime (defined to be 120 seconds). TIME-WAIT state severely limits the rate of successive transactions between the same (host,port) pair, since a new incarnation of the connection cannot be opened until the TIME-WAIT delay expires. RFC- 1379 explained why the alternative approach, using a different user port for each transaction between a pair of hosts, also limits the
2番目の性能問題はTCP接続を終えると時間のタイム誌-WAIT状態の1か両端が2*MSLにいなくなるということです。(そこでは、MSLが最大のセグメント生涯(120秒になるように、定義される)です)。 タイム誌-WAIT州は厳しく同じ(ホスト、ポート)組の間の連続したトランザクションのレートを制限します、タイム誌-WAIT遅れが期限が切れるまで接続の新しい肉体化を開くことができないので。 RFC1379は、代替手段になぜアプローチするかを説明しました、1組のホスト、限界の間でも各トランザクションにa異なったユーザポートを使用して
Braden [Page 3] RFC 1644 Transaction/TCP July 1994
ブレーデン[3ページ]RFC1644トランザクション/TCP1994年7月
transaction rate: (1) the 16-bit port space limits the rate to 2**16/240 transactions per second, and (2) more practically, an excessive amount of kernel space would be occupied by TCP state blocks in TIME-WAIT state [RFC-1379].
トランザクションレート: (1) (2) 16ビットのポートスペースは1秒あたり16/240のトランザクションにレートを2**に制限します、そして、より実際に、過量のカーネルスペースはタイム誌-WAIT状態[RFC-1379]でのTCP州のブロック占められるでしょう。
T/TCP solves these two performance problems for transactions, by (1) bypassing the 3-way handshake (3WHS) and (2) shortening the delay in TIME-WAIT state.
T/TCPはトランザクションのためのこれらの2つの性能問題を解決します、タイム誌-WAIT状態で遅れを短くしながら3ウェイ握手(3WHS)と(2)を迂回させる(1)。
2.1 Bypassing the Three-Way Handshake
2.1 3方向ハンドシェイクを迂回させること。
T/TCP introduces a 32-bit incarnation number, called a "connection
count" (CC), that is carried in a TCP option in each segment. A
distinct CC value is assigned to each direction of an open
connection. A T/TCP implementation assigns monotonically
increasing CC values to successive connections that it opens
actively or passively.
T/TCPはTCPオプションで各セグメントで運ばれる「接続カウント」(CC)と呼ばれる32ビットの肉体化番号を紹介します。 異なったCC値はオープンな接続の各方向に割り当てられます。 T/TCP実装はそれが活発か受け身に開く連続した接続に増加するCC値を単調に割り当てます。
T/TCP uses the monotonic property of CC values in initial <SYN>
segments to bypass the 3WHS, using a mechanism that we call TCP
Accelerated Open (TAO). Under the TAO mechanism, a host caches a
small amount of state per remote host. Specifically, a T/TCP host
that is acting as a server keeps a cache containing the last valid
CC value that it has received from each different client host. If
an initial <SYN> segment (i.e., a segment containing a SYN bit but
no ACK bit) from a particular client host carries a CC value
larger than the corresponding cached value, the monotonic property
of CC's ensures that the <SYN> segment must be new and can
therefore be accepted immediately. Otherwise, the server host
does not know whether the <SYN> segment is an old duplicate or was
simply delivered out of order; it therefore executes a normal 3WHS
to validate the <SYN>. Thus, the TAO mechanism provides an
optimization, with the normal TCP mechanism as a fallback.
T/TCPは3WHSを迂回させるのに初期の<SYN>セグメントにCC値の単調な特性を使用します、私たちがTCP Acceleratedオープン(TAO)と呼ぶメカニズムを使用して。 TAOメカニズムの下では、ホストは少量のリモートホストあたりの状態をキャッシュします。 明確に、サーバがそれが持っている最後の有効なCC値を含むキャッシュを保つので、行動しているT/TCPホストはそれぞれの異なったクライアントホストから受信しました。 特定のクライアントホストからの初期の<SYN>セグメント(すなわち、SYNビットを含んでいますが、どんなACKビットも含まないセグメント)が対応より大きい値が値、単調な特性をキャッシュしたCCを運ぶ、CC、したがって、<SYN>セグメントが確実に新しくなければならなくなるようにして、すぐに、受け入れることができます。 さもなければ、サーバー・ホストは、<SYN>セグメントが古い写しですかそれとも単に故障していた状態で提供されたかを知りません。 したがって、それは、<SYN>を有効にするために正常な3WHSを実行します。 したがって、TAOメカニズムは後退として正常なTCPメカニズムに最適化を供給します。
The CC value carried in non-<SYN> segments is used to protect
against old duplicate segments from earlier incarnations of the
same connection (we call such segments 'antique duplicates' for
short). In the case of short connections (e.g., transactions),
these CC values allow TIME-WAIT state delay to be safely discuss
in Section 2.3.
CC値が運び込んだ、非、-SYN>が区分する<は、同じ接続の以前の肉体化から古い写しセグメントから守るのに使用されます(私たちは、そのようなセグメントを略して'アンティークな写し'と呼びます)。 背の低い接続(例えば、トランザクション)の場合では、これらのCC値は、タイム誌-WAIT州の遅れがセクションで安全に2.3について議論することであることを許容します。
T/TCP defines three new TCP options, each of which carries one
32-bit CC value. These options are named CC, CC.NEW, and CC.ECHO.
The CC option is normally used; CC.NEW and CC.ECHO have special
functions, as follows.
T/TCPは3つの新しいTCPオプションを定義します。それはそれぞれ1つの32ビットのCC値を運びます。 これらのオプションはCC、CC.NEW、およびCC.ECHOと命名されます。 通常、CCオプションは使用されます。 CC.NEWとCC.ECHOには、以下の特別な機能があります。
Braden [Page 4] RFC 1644 Transaction/TCP July 1994
ブレーデン[4ページ]RFC1644トランザクション/TCP1994年7月
(a) CC.NEW
(a) CC.NEW
Correctness of the TAO mechanism requires that clients
generate monotonically increasing CC values for successive
connection initiations. These values can be generated using
a simple global counter. There are certain circumstances
(discussed below in Section 2.2) when the client knows that
monotonicity may be violated; in this case, it sends a CC.NEW
rather than a CC option in the initial <SYN> segment.
Receiving a CC.NEW causes the server to invalidate its cache
entry and do a 3WHS.
TAOメカニズムの正当性は、クライアントが、連続した接続開始のために増加するCCが値であると単調に生成するのを必要とします。 簡単なグローバルなカウンタを使用することでこれらの値を生成することができます。 クライアントが、単調が違反されるかもしれないのを知っているとき、ある事情(以下では、セクション2.2で議論する)があります。 この場合、それは初期の<SYN>セグメントでCCオプションよりむしろCC.NEWを送ります。 CC.NEWを受けるのは、サーバがキャッシュエントリーを無効にして、3WHSをすることを引き起こします。
(b) CC.ECHO
(b) CC.ECHO
When a server host sends a <SYN,ACK> segment, it echoes the
connection count from the initial <SYN> in a CC.ECHO option,
which is used by the client host to validate the <SYN,ACK>
segment.
サーバー・ホストが<SYN、ACK>セグメントを送るとき、それは初期の<SYN>からCC.ECHOオプションで接続カウントをまねます。(それは、<SYN(ACK>セグメント)を有効にするのにクライアントホストによって使用されます)。
Figure 1 illustrates the TAO mechanism bypassing a 3WHS. The
cached CC values, denoted by cache.CC[host], are shown on each
side. The server host compares the new CC value x in segment #1
against x0, its cached value for client host A; this comparison is
called the "TAO test". Since x > x0, the <SYN> must be new and
can be accepted immediately; the data in the segment can therefore
be delivered to the user process B, and the cached value is
updated. If the TAO test failed (x <= x0), the server host would
do a normal three-way handshake to validate the <SYN> segment, but
the cache would not be updated.
図1は3WHSを迂回させるTAOメカニズムを例証します。 cache.CC[ホスト]によって指示されたキャッシュされたCC値はそれぞれの側に示されます。 サーバー・ホストはx0に対してセグメント#1における新しいCC値xを比較します、クライアントホストAのためのキャッシュされた値。 この比較は「TAOテスト」と呼ばれます。 x>x0以来、<SYN>を新しくなければならなく、すぐに、受け入れることができます。 したがって、セグメントのデータをユーザ・プロセスBに提供できます、そして、キャッシュされた値をアップデートします。 TAOテストが失敗するなら(x<はx0と等しいです)、サーバー・ホストは<SYN>セグメントを有効にするために通常の3方向ハンドシェイクをするでしょうにが、キャッシュをアップデートしないでしょう。
Braden [Page 5] RFC 1644 Transaction/TCP July 1994
ブレーデン[5ページ]RFC1644トランザクション/TCP1994年7月
TCP A (Client) TCP B (Server)
_______________ ______________
TCPは(クライアント)TCP B(サーバ)です。_______________ ______________
cache.CC[A]
V
cache.CC[A]V
[ x0 ]
[x0]
#1 --> <SYN, data1, CC=x> --> (TAO test OK (x > x0) =>
data1->user_B and
cache.CC[A]= x; )
#1 --x SYN(data1)がCCする><=>-->。(TAOテストOK(x>x0)は>data1->ユーザ_Bとcache.CC[A]=xと等しいです;)
[ x ]
#2 <-- <SYN, ACK(data1), data2, CC=y, CC.ECHO=x> <--
(data2->user_A;)
[x]#2<--<SYN(ACK(data1)、data2)は=y、CC.ECHO=x><をCCします--(data2->、ユーザ、)
Figure 1. TAO: Three-Way Handshake is Bypassed
図1。 タオ: 3方法のHandshakeはBypassedです。
The CC value x is echoed in a CC.ECHO option in the <SYN,ACK>
segment (#2); the client side uses this option to validate the
segment. Since segment #2 is valid, its data2 is delivered to the
client user process. Segment #2 also carries B's CC value; this
is used by A to validate non-SYN segments from B, as explained in
Section 2.4.
CC値xは<SYNのCC.ECHOオプション、ACK>セグメント(#2)で反響されます。 クライアント側は、セグメントを有効にするのにこのオプションを使用します。 セグメント#2が有効であるので、data2はクライアントユーザ・プロセスに提供されます。 また、セグメント#2はビーズCC価値を運びます。 これはセクション2.4で説明されるようにAによって使用されて、Bから非SYNセグメントを有効にします。
Implementing the T/TCP extensions expands the connection control
block (TCB) to include the two CC values for the connection; call
these variables TCB.CCsend and TCB.CCrecv (or CCsend, CCrecv for
short). For example, the sequence shown in Figure 1 sets
TCB.CCsend = x and TCB.CCrecv = y at host A, and vice versa at
host B. Any segment that is received with a CC option containing
a value SEG.CC different from TCB.CCsend will be rejected as an
antique duplicate.
T/TCP拡張子を実装すると、接続制御ブロック(TCB)は接続のための2つのCC値を含むように広がります。 TCB.CCsendとTCB.CCrecv(または、CCsend、略してCCrecv)にこれらの変数に電話をしてください。 例えば、TCB.CCsendがxと等しく、TCB.CCrecvがホストAでyと等しく、CCオプションがTCB.CCsendと異なった値のSEG.CCを含んでいて受け取られるホストB.Anyセグメントで逆もまた同様ですが図1セットで示された系列はアンティークな写しとして拒絶されるでしょう。
2.2 Transaction Sequences
2.2 トランザクション系列
T/TCP applies the TAO mechanism described in the previous section
to perform a transaction sequence. Figure 2 shows a minimal
transaction, when the request and response data can each fit into
a single segment. This requires three segments and completes in
one round-trip time (RTT). If the TAO test had failed on segment
#1, B would have queued data1 and the FIN for later processing,
and then it would have returned a <SYN,ACK> segment to A, to
perform a normal 3WHS.
T/TCPはトランザクション系列を実行するために前項で説明されたTAOメカニズムを適用します。 要求と応答データがそれぞれただ一つのセグメントに収まることができるなら、図2は最小量のトランザクションを示しています。 これは、3つのセグメントを必要として、往復の1回の後に(RTT)を完成します。 TAOテストがセグメント#1で失敗したなら、Bは後で処理するためにdata1とFINを列に並ばせたでしょうに、そして、次に、それは正常な3WHSを実行するために<SYN、ACK>セグメントをAに返したでしょう。
Braden [Page 6] RFC 1644 Transaction/TCP July 1994
ブレーデン[6ページ]RFC1644トランザクション/TCP1994年7月
TCP A (Client) TCP B (Server)
_______________ ______________
TCPは(クライアント)TCP B(サーバ)です。_______________ ______________
CLOSED LISTEN
閉じられて、聴いてください。
#1 SYN-SENT* --> <SYN,data1,FIN,CC=x> --> CLOSE-WAIT*
(TAO test OK)
(data1->user_B)
#1 SYN-SENT*--><SYN(data1、FIN)は=x>をCCします-->CLOSE-WAIT*(TAOはOKをテストします)(data1>ユーザ_B)
<-- LAST-ACK*
#2 TIME-WAIT <-- <SYN,ACK(FIN),data2,FIN,CC=y,CC.ECHO=x>
(data2->user_A)
<--最後のACK*#2時間待ち<--<SYN(ACK(フィン)、data2、フィン)は=y、CC.ECHO=x>をCCします。(data2->、ユーザ、)
#3 TIME-WAIT --> <ACK(FIN),CC=x> --> CLOSED
#3 時間待ち--><ACK(フィン)、CC=x>-->は閉じました。
(timeout)
CLOSED
(タイムアウト)は閉じました。
Figure 2: Minimal T/TCP Transaction Sequence
図2: 最小量のT/TCPトランザクション系列
T/TCP extensions require additional connection states, e.g., the
SYN-SENT*, CLOSE-WAIT*, and LAST-ACK* states shown in Figure 2.
Section 3.3 describes these new connection states.
T/TCP拡張子は図2で見せられた追加接続州、例えば、SYN-SENT*、CLOSE-WAIT*、およびLAST-ACK*州を必要とします。 セクション3.3はこれらの新しい接続州について説明します。
To obtain the minimal 3-segment sequence shown in Figure 2, the
server host must delay acknowledging segment #1 so the response
may be piggy-backed on segment #2. If the application takes
longer than this delay to compute the response, the normal TCP
retransmission mechanism in TCP B will send an acknowledgment to
forestall a retransmission from TCP A. Figure 3 shows an example
of a slow server application. Although the sequence in Figure 3
does contain a 3-way handshake, the TAO mechanism has allowed the
request data to be accepted immediately, so that the client still
sees the minimum latency.
図2に示された最小量の3セグメントの系列を得るために、サーバー・ホストが、セグメント#1を承認するのを遅らせなければならないので、応答はセグメント#2で背負われるかもしれません。 アプリケーションがTCP A.から「再-トランスミッション」を出し抜くにはTCP Bで応答、正常なTCP retransmissionメカニズムを計算するこの遅れが承認を送るより長い間かかるなら、図3は遅いサーバ・アプリケーションに関する例を示しています。 図3の系列は3ウェイ握手を含んでいますが、TAOメカニズムは、要求データがすぐに受け入れられるのを許容しました、クライアントがまだ最小の潜在を見ているように。
Braden [Page 7] RFC 1644 Transaction/TCP July 1994
ブレーデン[7ページ]RFC1644トランザクション/TCP1994年7月
TCP A (Client) TCP B (Server)
_______________ ______________
TCPは(クライアント)TCP B(サーバ)です。_______________ ______________
CLOSED LISTEN
閉じられて、聴いてください。
#1 SYN-SENT* --> <SYN,data1,FIN,CC=x> --> CLOSE-WAIT*
(TAO test OK =>
data1->user_B)
#1 SYNによって送られた*(x SYN(data1、フィン)がCCする><=>)>厳密な待ち*(TAOテストOK=>data1>ユーザ_B)
(timeout)
#2 FIN-WAIT-1 <-- <SYN,ACK(FIN),CC=y,CC.ECHO=x> <-- CLOSE-WAIT*
(タイムアウト)#2フィン待1ち<--<SYN(ACK(フィン))は=y、CC.ECHO=x><をCCします--厳密な待っている*
#3 FIN-WAIT-1 --> <ACK(SYN),FIN,CC=x> --> CLOSE-WAIT
#3 フィン待1ち--x ACK(SYN)(フィン)がCCする><=>-->の厳密な待ち
#4 TIME-WAIT <-- <ACK(FIN),data2,FIN,CC=y> <-- LAST-ACK
(data2->user_A)
#4 時間待ち<--y>ACK(フィン)(data2、フィン)がCCする<=<--最後のACK(data2->、ユーザ、)
#5 TIME_WAIT --> <ACK(FIN),CC=x> --> CLOSED
#5 タイム誌_は待っています--><ACK(フィン)、=x>をCCしてください-->は閉じました。
(timeout)
CLOSED
(タイムアウト)は閉じました。
Figure 3: Acknowledgment Timeout in Server
図3: サーバにおける承認タイムアウト
2.3 Protocol Correctness
2.3 プロトコルの正当性
This section fills in more details of the TAO mechanism and
provides an informal sketch of why the T/TCP protocol works.
このセクションは、TAOメカニズムに関するその他の詳細に記入して、T/TCPプロトコルが働いている理由に関する非公式のスケッチを提供します。
CC values are 32-bit integers. The TAO test requires the same
kind of modular arithmetic that is used to compare two TCP
sequence numbers. We assume that the boundary between y < z and z
< y for two CC values y and z occurs when they differ by 2**31,
i.e., by half the total CC space.
CC値は32ビットの整数です。 TAOテストは2つのTCP一連番号を比較するのに使用される同じ種類の合同算術を必要とします。 私たちは、2**31で異なると2つのCC値yとzのためのy<zとz<yの間の境界が起こると思います、すなわち、総CCスペースの半分で。
The essential requirement for correctness of T/TCP is this:
T/TCPの正当性のための必須の条件はこれです:
CC values must advance at a rate slower than 2**31 [R1]
counts per 2*MSL
CC値は速度で2**31[R1]が2*MSL単位で数えられるより遅く進まなければなりません。
where MSL denotes the maximum segment lifetime in the Internet.
The requirement [R1] is easily met with a 32-bit CC. For example,
it will allow 10**6 transactions per second with the very liberal
MSL of 1000 seconds [RFC-1379]. This is well in excess of the
インターネットのMSLが最大のセグメント生涯を指示するところ。 必要条件[R1]は32ビットのCCで容易に満たされます。 例えば、それは1000秒[RFC-1379]の非常に寛容なMSLと共に1秒あたり6つのトランザクションを10**に許容するでしょう。 これは、より良いです。
Braden [Page 8] RFC 1644 Transaction/TCP July 1994
ブレーデン[8ページ]RFC1644トランザクション/TCP1994年7月
transaction rates achievable with current operating systems and
network latency.
現在のオペレーティングシステムとネットワーク潜在で達成可能なトランザクションレート。
Assume for the present that successive connections from client A
to server B contain only monotonically increasing CC values. That
is, if x(i) and x(i+1) are CC values carried in two successive
initial <SYN> segments from the same host, then x(i+1) > x(i).
Assuming the requirement [R1], the CC space cannot wrap within the
range of segments that can be outstanding at one time. Therefore,
those successive <SYN> segments from a given host that have not
exceeded their MSL must contain an ordered set of CC values:
当分、連続したクライアントAからサーバBまでの接続が増加するCC値を単調だけに含むと仮定してください。 そして、それはx(i)とx(i+1)が同じホストから2つの連続した初期の<SYN>セグメントで運ばれたCC値であるならx(i+1)>x(i)です。 要件が[R1]であると仮定する場合、CCスペースはひところ傑出する場合があるセグメントの範囲を中に包装できません。 したがって、与えられたホストからのそれらのMSLを超えていないそれらの連続した<SYN>セグメントは1つの順序集合のCC値を含まなければなりません:
x(1) < x(2) < x(3) ... < x(n),
x(1)<x(2)<x(3)… <x(n)
where the modular comparisons have been replaced by simple
arithmetic comparisons. Here x(n) is the most recent acceptable
<SYN>, which is cached by the server. If the server host receives
a <SYN> segment containing a CC option with value y where y >
x(n), that <SYN> must be newer; an antique duplicate SYN with CC
value greater than x(n) must have exceeded its MSL and vanished.
Hence, monotonic CC values and the TAO test prevent erroneous
replay of antique <SYN>s.
モジュールの比較が簡単な算術比較に取り替えられたところ。 ここで、x(n)は最新の許容できる<SYN>です。サーバー・ホストがy>x(n)、その<SYN>がそうしなければならない値yでCCオプションを含む<SYN>セグメントを受けるなら、より新しくいてください。(>はサーバによってキャッシュされます)。 CC値がx(n)より大きいアンティークな写しSYNはMSLを超えて、消え失せたに違いありません。 したがって、単調なCC値とTAOテストはアンティークな<SYN>sの誤った再生を防ぎます。
There are two possible reasons for a client to generate non-
monotonic CC values: (a) the client may have crashed and
restarted, causing the generated CC values to jump backwards; or
(b) the generated CC values may have wrapped around the finite
space. Wraparound may occur because CC generation is global to
all connections. Suppose that host A sends a transaction to B,
then sends more than 2**31 transactions to other hosts, and
finally sends another transaction to B. From B's viewpoint, CC
will have jumped backward relative to its cached value.
クライアントが非単調なCCが値であると生成する2つの可能な理由があります: (a) 発生しているCC値が後方にジャンプすることを引き起こして、クライアントは、ダウンして、再開したかもしれません。 (b) または、発生しているCC値は有限スペースを巻きつけたかもしれません。 すべての接続に、CC発生がグローバルであるので、巻きつけて着るドレスは現れるかもしれません。 そのホストAがトランザクションをBに送って、次に、2**31トランザクション以上を他のホストに送って、最終的にB.Fromビーズ観点に別のトランザクションを送るなら、CCはキャッシュされた値に比例して後方までジャンプしてしまうでしょう。
In either of these two cases, the server may see the CC value jump
backwards only after an interval of at least MSL since the last
<SYN> segment from the same client host. In case (a), client host
restart, this is because T/TCP retains TCP's explicit "Quiet Time"
of an MSL interval [STD-007]. In case (b). wrap around, [R1]
ensures that a time of at least MSL must have passed before the CC
space wraps around. Hence, there is no possibility that a TAO
test will succeed erroneously due to either cause of non-
monotonicity; i.e., there is no chance of replays due to TAO.
これらの2つのケースのどちらかでは、サーバは、同じクライアントホストからCC値が単に少なくとも最後の<SYN>セグメント以来のMSLぶりに後方にジャンプするのを見るかもしれません。 (a)、クライアントホストが再開してこれはT/TCPがTCPのMSL間隔[STD-007]の明白な「静かな時間」を保有するからです。 ケース(b)およそ包装の中では、[R1]は、CCスペースが巻きつけられる前に少なくともMSLの時間が経過したに違いないのを確実にします。 したがって、TAOテストが非単調の原因のため誤って成功する可能性が全くありません。 すなわち、TAOによる再生の見込みが全くありません。
However, although CC values jumping backwards will not cause an
error, it may cause a performance degradation due to unnecessary
3WHS's. This results from the generated CC values jumping
backwards through approximately half their range, so that all
succeeding TAO tests fail until the generated CC values catch up
しかしながら、後方にジャンプするCC値は誤りを引き起こさないでしょうが、それは不要な3WHSのものによる性能退行を引き起こすかもしれません。 これはそれらの範囲のおよそ半分を通して後方にジャンプする発生しているCC値から生じます、発生しているCC値が追いつくまで続くすべてのTAOテストが失敗するように
Braden [Page 9] RFC 1644 Transaction/TCP July 1994
ブレーデン[9ページ]RFC1644トランザクション/TCP1994年7月
to the cached value. To avoid this degradation, a client host
sends a CC.NEW option instead of a CC option in the case of either
system restart or CC wraparound. Receiving CC.NEW forces a 3WHS,
but when this 3WHS completes successfully the server cache is
updated to the new CC value. To detect CC wraparound, the client
must cache the last CC value it sent to each server. It therefore
maintains cache.CCsent[B] for each server B. If this cached value
is undefined or if it is larger than the next CC value generated
at the client, then the client sends a CC.NEW instead of a CC
option in the next SYN segment.
キャッシュされた値に。 この退行を避けるために、クライアントホストはシステムリスタートかCC巻きつけて着るドレスのどちらかの場合におけるCCオプションの代わりにCC.NEWオプションを送ります。 CC.NEWを受けると、3WHSは強制されますが、この3WHSがいつ首尾よくサーバキャッシュを完成するか新しいCC値にアップデートします。 巻きつけて着るドレス、クライアントが検出しなければならないCCを検出するために、最終がCCするキャッシュはそれを評価します。したがって. それが各サーバB.Ifのためにcache.CCsent[B]であることを支持する各サーバに送って、このキャッシュされた値が未定義であるか、またはそれがクライアントで生成された次のCC値より大きいなら、クライアントは次のSYNセグメントにおけるCCオプションの代わりにCC.NEWを送ります。
This is illustrated in Figure 4, which shows the scenario for the
first transaction from A to B after the client host A has crashed
and recovered. A similar sequence occurs if x is not greater than
cache.CCsent[B], i.e., if there is a wraparound of the generated
CC values. Because segment #1 contains a CC.NEW option, the
server host invalidates the cache entry and does a 3WHS; however,
it still sets B's TCB.CCrecv for this connection to x. TCP B uses
this CCrecv value to validate the <ACK> segment (#3) that
completes the 3WHS. Receipt of this segment updates cache.CC[A],
since the cache entry was previously undefined. (If a 3WHS always
updated the cache, then out-of-order SYN segments could cause the
cached value to jump backwards, possibly allowing replays).
Finally, the CC.ECHO option in the <SYN,ACK> segment #2 defines
A's cache.CCsent entry.
これは、図4で例証されて、回復されます。(クライアントホストAがダウンした後に図は最初のトランザクションのためにAからBまでシナリオを示しています)。 xがcache.CCsent[B]ほど大きくないなら、同様の系列は起こります、すなわち、発生しているCC値の巻きつけて着るドレスがあれば。 セグメント#1がCC.NEWオプションを含んでいるので、サーバー・ホストは、キャッシュエントリーを無効にして、3WHSをします。 しかしながら、それはまだxとのこの接続にビーズTCB.CCrecvを設定しています。 TCP Bは、3WHSを完成する<ACK>セグメント(#3)を有効にするのにこのCCrecv値を使用します。 キャッシュエントリーが以前に未定義であったので、このセグメントの領収書はcache.CC[A]をアップデートします。 (いつもキャッシュで、次に、故障していた状態でアップデートして、キャッシュされた値は3WHSであるならSYNセグメントで後方にジャンプするかもしれません、ことによると再生を許容して。) 最終的に、<SYN、ACK>セグメント#2におけるCC.ECHOオプションはAのcache.CCsentエントリーを定義します。
This algorithm delays updating cache.CCsent[] until the <SYN> has
been ACK'd. This allows the undefined cache.CCsent value to used
as a a "first-time switch" to reliable resynchronization of the
cached value at the server after a crash or wraparound.
<SYN>がACKになるまでcache.CCsent[]をアップデートする遅れがそうするこのアルゴリズム。 これはキャッシュの信頼できる再同期へのaとしての、「最初に、スイッチを調節してください」というクラッシュか巻きつけて着るドレスの後のサーバにおける中古の値に未定義のcache.CCsent値を許容します。
When we use the term "cache", we imply that the value can be
discarded at any time without introducing erroneous behavior
although it may degrade performance.
「キャッシュ」という用語を使用すると、私たちは、いつでも性能を下げるかもしれませんが、誤った振舞いを導入しないで値を捨てることができると暗示します。
(a) If a server host receives an initial <SYN> from client A but
has no cached value cache.CC[A], the server simply forces a
3WHS to validate the <SYN> segment.
(a) サーバー・ホストがクライアントAから初期の<SYN>を受けますが、キャッシュされた値のcache.CC[A]を全く持っていないなら、サーバによって、3WHSは単にやむを得ず<SYN>セグメントを有効にします。
(b) If a client host has no cached value cache.CCsent[B] when it
needs to send an initial <SYN> segment, the client simply
sends a CC.NEW option in the segment. This forces a 3WHS at
the server.
(b) それが、初期の<SYN>セグメントを送る必要がある場合クライアントホストがキャッシュされた値のcache.CCsent[B]を全く持っていないなら、クライアントはセグメントで単にCC.NEWオプションを送ります。 これはサーバで3WHSを強制します。
Braden [Page 10] RFC 1644 Transaction/TCP July 1994
ブレーデン[10ページ]RFC1644トランザクション/TCP1994年7月
TCP A (Client) TCP B (Server)
_______________ ______________
TCPは(クライアント)TCP B(サーバ)です。_______________ ______________
cache.CCsent[B] cache.CC[A]
V V
cache.CCsent[B] cache.CC[A]V V
(Crash and restart)
[ ?? ] [ x0 ]
(墜落して、再開します)、[]? [x0]
#1 --> <SYN, data1,CC.NEW=x> --> (invalidate cache;
queue data1;
3-way handshake)
#1 --><SYN、data1、CC.NEW=x>-->。(キャッシュ; data1を列に並ばせるのを無効にしてください; 3ウェイ握手)
[ ?? ] [ ?? ]
#2 <-- <SYN, ACK(data1),CC=y,CC.ECHO=x> <--
(cache.CCsent[B]= x;)
[ ?? ] [ ?? ] #2 <-- <SYN(ACK(data1))は=y、CC.ECHO=x><をCCします--(cache.CCsent[B]はxと等しいです;)
[ x ] [ ?? ]
[x][ ?? ]
#3 --> <ACK(SYN),CC=x> --> data1->user_B;
cache.CC[A]= x;
#3 --><ACK(SYN)、CCはx>と等しいです-->data1>ユーザ_B cache.CC[A]はxと等しいです。
[ x ] [ x ]
[x][x]
Figure 4. Client Host Restarting
図4。 クライアントホスト再開
So far, we have considered only correctness of the TAO mechanism
for bypassing the 3WHS. We must also protect a connection against
antique duplicate non-SYN segments. In standard TCP, such
protection is one of the functions of the TIME-WAIT state delay.
(The other function is the TCP full-duplex close semantics, which
we need to preserve; that is discussed below in Section 2.5). In
order to achieve a high rate of transaction processing, it must be
possible to truncate this TIME-WAIT state delay without exposure
to antique duplicate segments [RFC-1379].
今までのところ、私たちは、3WHSを迂回させるためにTAOメカニズムの正当性だけを考えました。 また、私たちはアンティークな写し非SYNセグメントに対して接続を保護しなければなりません。 標準のTCPでは、そのような保護はタイム誌-WAIT州の遅れの機能の1つです。 (もう片方の機能は私たちが保存する必要があるTCPの全二重の近い意味論です; すなわち、以下では、セクション2.5で議論します。) 高い率のトランザクション処理を達成するために、アンティークな写しセグメント[RFC-1379]への露出なしでこのタイム誌-WAIT州の遅れに先端を切らせるのは可能でなければなりません。
For short connections (e.g., transactions), the CC values assigned
to each direction of the connection can be used to protect against
antique duplicate non-SYN segments. Here we define "short" as a
duration less than MSL. Suppose that there is a connection that
uses the CC values TCB.CCsend = x and TCB.CCrecv = y. By the
requirement [R1], neither x nor y can be reused for a new
connection from the same remote host for a time at least 2*MSL.
If the connection has been in existence for a time less than MSL,
then its CC values will not be reused for a period that exceeds
MSL, and therefore all antique duplicates with that CC value must
vanish before it is reused. Thus, for "short" connections we can
背の低い接続(例えば、取引)において、アンティークな写し非SYNセグメントから守るのに接続の各方向に割り当てられたCC値は使用できます。 ここには、私たちがMSLより持続時間を「短く」定義づけません。 CC値TCB.CCsend=xとTCB.CCrecv=yを使用する接続があると仮定してください。 要件[R1]で、新しい接続のために時間少なくとも2*MSLの同じリモートホストからxもyも再利用できません。 接続がMSL、次に、CC値がしばらく再利用されないより少ないMSLを超えていて、したがってすべての骨董品を超えている時間現存しているなら、それが再利用される前にそのCC値がある写しは消え失せなければなりません。 したがって、「短い」接続のために、私たちはそうすることができます。
Braden [Page 11] RFC 1644 Transaction/TCP July 1994
ブレーデン[11ページ]RFC1644取引/TCP1994年7月
guard against antique non-SYN segments by simply checking the CC
value in the segment againsts TCB.CCrecv. Note that this check
does not use the monotonic property of the CC values, only that
they not cycle in less than 2*MSL. Again, the quiet time at
system restart protects against errors due to crash with loss of
state.
セグメントagainsts TCB.CCrecvで単にCC値をチェックすることによって、アンティークな非SYNセグメントに用心してください。 このチェックがCC値の単調な特性を使用しないで、2未満*MSLを循環するだけではないことに注意してください。 一方、システムリスタートにおける静かな時間は状態の損失と押しかけるのにおいて当然の誤りから守ります。
If the connection duration exceeds MSL, safety from old duplicates
still requires a TIME-WAIT delay of 2*MSL. Thus, truncation of
TIME-WAIT state is only possible for short connections. (This
problem has also been noticed by Shankar and Lee [ShankarLee93]).
This difference in behavior for long and for short connections
does create a slightly complex service model for applications
using T/TCP. An application has two different strategies for
multiple connections. For "short" connections, it should use a
fixed port pair and use the T/TCP mechanism to get rapid and
efficient transaction processing. For connections whose durations
are of the order of MSL or longer, it should use a different user
port for each successive connection, as is the current practice
with unmodified TCP. The latter strategy will cause excessive
overhead (due to TCB's in TIME-WAIT state) if it is applied to
high-frequency short connections. If an application makes the
wrong choice, its attempt to open a new connection may fail with a
"busy" error. If connection durations may range between long and
short, an application may have to be able to switch strategies
when one fails.
接続持続時間がMSLを超えているなら、古い写しから安全はまだ2*MSLのタイム誌-WAIT遅れを必要としています。 したがって、背の低い接続だけに、タイム誌-WAIT状態のトランケーションは可能です。 (また、この問題はシャンカルとリー[ShankarLee93]が気付かれました。) 長さと背の低い接続のための振舞いのこの違いは、T/TCPを使用することでアプリケーションのためのわずかに複雑なサービスモデルを創造します。 アプリケーションには、複数の接続のための2つの異なった戦略があります。 「短い」接続には、固定ポート組を使用するべきです、そして、T/TCPメカニズムを使用して、急速で効率的なトランザクション処理を得てください。 持続時間がMSLの注文があるか、または、より長い接続のために、それぞれの連続した接続のための異なったユーザポートを使用するべきです、変更されていないTCPがある現在の習慣のように。 それが高周波の背の低い接続に適用されると、後者の戦略は過度のオーバーヘッド(タイム誌-WAITのTCBのものによる状態)を引き起こすでしょう。 アプリケーションが選択を誤るなら、「忙しい」誤りに応じて、新しい接続を開く試みは失敗するかもしれません。 1つが失敗するとき、接続持続時間が長さであることの間、そして、急に及ぶかもしれないなら、アプリケーションは戦略を切り換えることができなければならないかもしれません。
2.4 Truncating TIME-WAIT State
2.4 時間待ち状態に先端を切らせること。
Truncation of TIME-WAIT state is necessary to achieve high
transaction rates. As Figure 2 illustrates, a standard
transaction leaves the client end of the connection in TIME-WAIT
state. This section explains the protocol implications of
truncating TIME-WAIT state, when it is allowed (i.e., when the
connection has been in existence for less than MSL). In this
case, the client host should be able to interrupt TIME-WAIT state
to initiate a new incarnation of the same connection (i.e., using
the same host and ports). This will send an initial <SYN>
segment.
タイム誌-WAIT状態のトランケーションが、高い取引率を達成するのに必要です。 図2が例証するように、標準の取引は接続のクライアント終わりにタイム誌-WAIT状態でいなくなります。 このセクションはタイム誌-WAITに先端を切らせる含意が述べるプロトコルについて説明します、それが許容されているとき(すなわち、接続はいつMSLより以下で現存していますか)。 この場合、クライアントホストは、同じ接続(すなわち、同じホストを使用して、ポート)の新しい肉体化を起こすためにタイム誌-WAIT状態を中断できるべきです。 これは初期の<SYN>セグメントを送るでしょう。
It is possible for the new <SYN> to arrive at the server before
the retransmission state from the previous incarnation is gone, as
shown in Figure 5. Here the final <ACK> (segment #3) from the
previous incarnation is lost, leaving retransmission state at B.
However, the client received segment #2 and thinks the transaction
completed successfully, so it can initiate a new transaction by
sending <SYN> segment #4. When this <SYN> arrives at the server
host, it must implicitly acknowledge segment #2, signalling
前の肉体化からの「再-トランスミッション」状態がなくなる前に新しい<SYN>がサーバに届くのは、可能です、図5に示されるように。 ここで、前の肉体化からの最終的な<ACK>(セグメント#3)が無くなる、B.Howeverの状態に「再-トランスミッション」を発って、クライアントは、セグメント#2を受け取って、首尾よく完了される取引を考えて、したがって、それは<SYN>セグメント#4を送ることによって、新しい取引を開始できます。 この<SYN>がサーバー・ホストに届くと、それはそれとなくセグメント#2、合図を承認しなければなりません。
Braden [Page 12] RFC 1644 Transaction/TCP July 1994
ブレーデン[12ページ]RFC1644取引/TCP1994年7月
success to the server application, deleting the old TCB, and
creating a new TCB, as shown in Figure 5. Still assuming that the
new <SYN> is known to be valid, the server host marks the new
connection half-synchronized and delivers data3 to the server
application. (The details of how this is accomplished are
presented in Section 3.3.)
図5に示されるように古いTCBを削除して、新しいTCBを作成するサーバ・アプリケーションへの成功。 新しい<SYN>が有効であることが知られているとまだ仮定していて、サーバー・ホストは、新しい接続が半分連動されているとマークして、data3をサーバ・アプリケーションに届けます。 (これがどう優れるかに関する詳細はセクション3.3に提示されます。)
The earlier discussion of the TAO mechanism assumed that the
previous incarnation was closed before a new <SYN> arrived at the
server. However, TAO cannot be used to validate the <SYN> if
there is still state from the previous incarnation, as shown in
Figure 5; in this case, it would be exceedingly awkward to perform
a 3WHS if the TAO test should fail. Fortunately, a modified
version of the TAO test can still be performed, using the state in
the earlier TCB rather than the cached state.
TAOメカニズムの以前の議論は、新しい<SYN>がサーバに届く前に前の肉体化が閉じられたと仮定しました。しかしながら、前の肉体化からの状態がまだあれば、<SYN>を有効にするのにTAOを使用できません、図5に示されるように。 この場合、TAOテストが失敗するなら、3WHSを実行するのはきわめてまずいでしょう。 幸い、まだTAOテストの変更されたバージョンを実行できます、キャッシュされた状態よりむしろ以前のTCBで状態を使用して。
(A) If the <SYN> segment contains a CC or CC.NEW option, the
value SEG.CC from this option is compared with TCB.CCrecv,
the CC value in the still-existing state block of the
previous incarnation. If SEG.CC > TCB.CCrecv, the new <SYN>
segment must be valid.
(A) <SYN>セグメントがCCかCC.NEWオプションを含んでいるなら、このオプションからの値のSEG.CCはTCB.CCrecv(前の肉体化のそれでも、現状ブロックのCC値)と比較されます。 SEG.CC>TCB.CCrecvであるなら、新しい<SYN>セグメントは有効であるに違いありません。
(B) Otherwise, the <SYN> is an old duplicate and is simply
discarded.
(B) さもなければ、<SYN>は古い写しであり、単に捨てられます。
Truncating TIME-WAIT state may be looked upon as composing an
extended state machine that joins the state machines of the two
incarnations, old and new. It may be described by introducing new
intermediate states (which we call I-states), with transitions
that join the two diagrams and share some state from each. I-
states are detailed in Section 3.3.
タイム誌-WAIT状態に先端を切らせるのは古くて新しい2回の肉体化の州のマシンを接合する拡張州のマシンを構成するとして見られるかもしれません。 それは新しい中間的州(私たちがI-州と呼ぶ)を導入することによって、説明されるかもしれません、2個のダイヤグラムを接合して、それぞれから何らかの状態を共有する変遷で。 I州はセクション3.3で詳細です。
Notice also segment #2' in Figure 5. TCP's mechanism to recover
from half-open connections (see Figure 10 of [STD-007]) cause TCP
A to send a RST when 2' arrives, which would incorrectly make B
think that the previous transaction did not complete successfully.
The half-open recovery mechanism must be defeated in this case, by
A ignoring segment #2'.
図5の'また、セグメント#2に注意してください'。 '2であるときにRSTを送る半開きな接続([STD-007]の図10を見る)原因TCP Aから回収するTCPのメカニズム'(不当にBに前の取引が完全でなくしたと首尾よく思わせる)は到着します。 'この場合セグメント#2を無視するAで半開きな回収機構を破らなければなりません'。
Braden [Page 13] RFC 1644 Transaction/TCP July 1994
ブレーデン[13ページ]RFC1644取引/TCP1994年7月
TCP A (Client) TCP B (Server)
_______________ ______________
TCPは(クライアント)TCP B(サーバ)です。_______________ ______________
CLOSED LISTEN
閉じられて、聴いてください。
#1 --> <...,FIN,CC=x> --> LAST-ACK*
#1 --><…フィン、CCはx>と等しいです-->の最後のACKの*
#2 <-- <...ACK(FIN),data2,FIN,CC=y,CC.ECHO=x> <--- LAST-ACK*
TIME-WAIT
(data2->user_A)
#2 <-- <…ACK(フィン)(data2、フィン)は=y、CC.ECHO=x><をCCします。--- 最後のACKの*時間待ち(data2->、ユーザ、)
#3 TIME-WAIT --> <ACK(FIN),CC=x> --> X (DROP)
#3 時間待ち--><ACK(フィン)、CC=x>-->X(低下)
(New Active Open) (New Passive Open)
(新しい活発なオープン)(開いている新しい受動態)
#4 SYN-SENT* --> <SYN, data3,CC=z> ...
#4 ><SYN(data3)が=z>をCCするという*をSYN送ります。
LISTEN-LA
#2' (discard) <-- <...ACK(FIN),data2,FIN,CC=y> <--- (retransmit)
'LAを聴いている#2'(捨てる)<--<…ACK(フィン)(data2、フィン)は=y><をCCします。--- (再送します)
#4 SYN-SENT* ... <SYN,data3,CC=z> --> ESTABLISHED*
SYN OK (see text) =>
{Ack seg #2;
Delete old TCB;
Create new TCB;
data3 -> user_B;
cache.CC[A]= z;}
#4 *をSYN送ります… <SYN(data3)は=z>をCCします-->ESTABLISHED*SYN OK(テキストを見る)は>と等しいです。Ack seg#2; 古いTCBを削除してください; 新しいTCBを作成してください; data3->ユーザ_B; cache.CC[A]=z
Figure 5: Truncating TIME-WAIT State: SYN as Implicit ACK
図5: 時間待ち状態に先端を切らせます: 内在しているACKとしてのSYN
2.5 Transition to Standard TCP Operation
2.5 標準のTCP操作への変遷
T/TCP includes all normal TCP semantics, and it will continue to
operate exactly like TCP when the particular assumptions for
transactions do not hold. There is no limit on the size of an
individual transaction, and behavior of T/TCP should merge
seamlessly from pure transaction operation as shown in Figure 2,
to pure streaming mode for sending large files. All the sequences
shown in [STD-007] are still valid, and the inherent symmetry of
TCP is preserved.
T/TCPはすべての正常なTCP意味論を含んでいます、そして、取引のための特定の仮定が成立しないとき、それはちょうどTCPのように作動し続けるでしょう。 限界が全く個々の取引のサイズにありません、そして、T/TCPの動きは図2に示されるように純粋な取引操作から継ぎ目なく合併するべきです、送付の大きいファイルのための純粋なストリーミングのモードに。 [STD-007]に示されたすべての系列がまだ有効です、そして、TCPの固有の対称は保存されます。
Figure 6 shows a possible sequence when the request and response
messages each require two segments. Segment #2 is a non-SYN
segment that contains a TCP option. To avoid compatibility
problems with existing TCP implementations, the client side should
図6は、要求と応答メッセージがいつそれぞれ2つのセグメントを必要とするかを可能な系列に示します。 セグメント#2はTCPオプションを含む非SYNセグメントです。 TCP実現、クライアント側がそうするべきである存在の互換性の問題を避けるために
Braden [Page 14] RFC 1644 Transaction/TCP July 1994
ブレーデン[14ページ]RFC1644取引/TCP1994年7月
send segment #2 only if cache.CCsent[B] is defined, i.e., only if
host A knows that host B plays the new game.
すなわち、ホストAが、ホストBが新しいゲームをするのを知っている場合にだけcache.CCsent[B]が定義される場合にだけ、セグメント#2を送ってください。
TCP A (Client) TCP B (Server)
_______________ ______________
TCPは(クライアント)TCP B(サーバ)です。_______________ ______________
CLOSED LISTEN
閉じられて、聴いてください。
#1 SYN-SENT* --> <SYN,data1,CC=x> --> ESTABLISHED*
(TAO test OK =>
data1-> user)
#1 SYNによって送られた*(x SYN(data1)がCCする><=>)>確立した*(TAOテストOK=>data1->ユーザ)
#2 SYN-SENT* --> <data2,FIN,CC=x> --> CLOSE-WAIT*
(data2-> user)
#2 SYNによって送られた*(x data2、フィンがCCする><=>)>厳密な待ち*(data2->ユーザ)
CLOSE-WAIT*
#3 FIN-WAIT-2 <-- <SYN,ACK(FIN),data3,CC=y,CC.ECHO=x> <--
(data3->user)
厳密な待#*3ちフィン待2ち<--<SYN(ACK(フィン)、data3)は=y、CC.ECHO=x><をCCします--(data3->、ユーザ、)
#4 TIME_WAIT <-- <ACK(FIN),data4,FIN,CC=y> <-- LAST-ACK*
(data4->user)
#4 タイム誌_は<--y>ACK(フィン)(data4、フィン)がCCする<=<--最後のACKの*を待っています。(data4->、ユーザ、)
#5 TIME-WAIT --> <ACK(FIN),CC=x> --> CLOSED
#5 時間待ち--><ACK(フィン)、CC=x>-->は閉じました。
Figure 6. Multi-Packet Request/Response Sequence
図6。 マルチパケット要求/応答系列
Figure 7 shows a more complex example, one possible sequence with
TAO combined with simultaneous open and close. This may be
compared with Figure 8 of [STD-007].
TAOが同時の戸外と閉鎖に結合されている状態で、図7は、より複雑な例、1つの可能な系列を示しています。 これは[STD-007]の図8と比較されるかもしれません。
Braden [Page 15] RFC 1644 Transaction/TCP July 1994
ブレーデン[15ページ]RFC1644取引/TCP1994年7月
TCP A TCP B
_______________ ______________
TCPはTCP Bです。_______________ ______________
CLOSED CLOSED
閉じられた状態で、閉じられます。
#1 SYN-SENT* --> <SYN,data1,FIN,CC=x> ...
#1 ><SYN(data1、フィン)が=x>をCCするという*をSYN送ります。
#2 CLOSING* <-- <SYN,data2,FIN,CC=y> <-- SYN-SENT*
(TAO test OK =>
data2->user_A
#2 CLOSING*<--<SYN(data2、FIN)は=y><をCCします--SYN-SENT*、(TAOがOK=>をテストする、data2->、ユーザ
#3 CLOSING* --> <FIN,ACK(FIN),CC=x,CC.ECHO=y> ...
#3 *を閉じます--<フィン、ACK(フィン)がCCする>はx、CC.ECHO=y>と等しいです…
#1' ... <SYN,data1,FIN,CC=x> --> CLOSING*
(TAO test OK =>
data1->user_B)
#1' ... <SYN(data1、フィン)は=x>をCCします-->終わりの*(TAOテストOK=>data1>ユーザ_B)
#4 TIME-WAIT <-- <FIN,ACK(FIN),CC=y,CC.ECHO=x> <-- CLOSING*
#4 時間待ち<--*を閉じて、<フィン、ACK(フィン)は=y、CC.ECHO=x><をCCします。
#5 TIME-WAIT --> <ACK(FIN),CC=x> ...
#5 時間待ち--><ACK(フィン)、CCはx>と等しいです…
#3' ... <FIN,ACK(FIN),CC=x,CC.ECHO=y> --> TIME-WAIT
#3' ... <フィン、ACK(フィン)、CC=x、CC.ECHO=y>-->時間待ち
#6 TIME-WAIT <-- <ACK(FIN),CC=y> <--- TIME-WAIT
#6 時間待ち<--<ACK(フィン)、CC=y><。--- 時間待ち
#5' TIME-WAIT ... <ACK(FIN),CC=x> --> TIME-WAIT
#'5'時待ってください… <ACK(フィン)、CC=x>-->時間待ち
(timeout) (timeout)
CLOSED CLOSED
(タイムアウト)が閉じた(タイムアウト)は閉じました。
Figure 7: Simultaneous Open and Close
図7: 同時のオープンと閉鎖
Braden [Page 16] RFC 1644 Transaction/TCP July 1994
ブレーデン[16ページ]RFC1644取引/TCP1994年7月
3. FUNCTIONAL SPECIFICATION
3. 機能的な仕様
3.1 Data Structures
3.1 データ構造
A connection count is an unsigned 32-bit integer, with the value
zero excluded. Zero is used to denote an undefined value.
ゼロが除いた値に従って、接続カウントは無記名の32ビットの整数です。 ゼロは、未定義値を指示するのに使用されます。
A host maintains a global connection count variable CCgen, and
each connection control block (TCB) contains two new connection
count variables, TCB.CCsend and TCB.CCrecv. Whenever a TCB is
created for the active or passive end of a new connection, CCgen
is incremented by 1 and placed in TCB.CCsend of the TCB; however,
if the previous CCgen value was 0xffffffff (-1), then the next
value should be 1. TCB.CCrecv is initialized to zero (undefined).
ホストはグローバルな接続カウントの可変CCgenを維持します、そして、それぞれの接続制御ブロック(TCB)は2の新しい接続のカウント変数、TCB.CCsend、およびTCB.CCrecvを含んでいます。 TCBが新しい接続のアクティブであるか受け身の終わりに作成されるときはいつも、CCgenは1つ増加されて、TCBのTCB.CCsendに置かれます。 しかしながら、前のCCgen値が0xffffffff(-1)であるなら、次の値は1でしょうに。 TCB.CCrecvはゼロに(未定義)で初期化されます。
T/TCP adds a per-host cache to TCP. An entry in this cache for
foreign host fh includes two CC values, cache.CC[fh] and
cache.CCsent[fh]. It may include other values, as discussed in
Sections 4.3 and 4.4. According to [STD-007], a TCP is not
permitted to send a segment larger than the default size 536,
unless it has received a larger value in an MSS (Maximum Segment
Size) option. This could constrain the client to use the default
MSS of 536 bytes for every request. To avoid this constraint, a
T/TCP may cache the MSS option values received from remote hosts,
and we allow a TCP to use a cached MSS option value for the
initial SYN segment.
T/TCPは1ホストあたり1つのキャッシュをTCPに加えます。 異種宿主fhのためのこのキャッシュにおけるエントリーは2つのCC値、cache.CC[fh]、およびcache.CCsent[fh]を含んでいます。 それはセクション4.3と4.4で議論するように他の値を含むかもしれません。 [STD-007]に従って、TCPがデフォルトサイズ536より大きいセグメントを送ることが許可されていません、MSS(最大のSegment Size)オプションにおけるさらに大きい値を受けていない場合。 これは、クライアントがあらゆる要求に536バイトのデフォルトMSSを使用するのを抑制するかもしれません。 この規制を避けるために、T/TCPはリモートホストから受け取られたMSSオプション価値をキャッシュするかもしれません、そして、私たちはTCPが初期のSYNセグメントにキャッシュされたMSSオプション価値を使用するのを許します。
When the client sends an initial <SYN> segment containing data, it
does not have a send window for the server host. This is not a
great difficulty; we simply define a default initial window; our
current suggestion is 4K. Such a non-zero default should be be
conditioned upon the existence of a cached connection count for
the foreign host, so that data may be included on an initial SYN
segment only if cache.CC[foreign host] is non-zero.
クライアントがデータを含む初期の<SYN>セグメントを送るとき、それで、aはサーバー・ホストのために窓を送りません。 これは大きな困難ではありません。 私たちは単にデフォルトの初期のウィンドウを定義します。 私たちの現在の提案は4Kです。 そのような非ゼロデフォルトは、cache.CC[異種宿主]が非ゼロである場合にだけ異種宿主のためのキャッシュされた接続カウントの存在初期のSYNセグメントにデータを含むことができるように条件とするべきです。
In TCP, the window is dynamically adjusted to provide congestion
control/avoidance [Jacobson88]. It is possible that a particular
path might not be able to absorb an initial burst of 4096 bytes
without congestive losses. If this turns out to be a problem, it
should be possible to cache the congestion threshold for the path
and use this value to determine the maximum size of the initial
packet burst created by a request.
TCPでは、窓は、輻輳制御/回避[Jacobson88]を提供するようにダイナミックに調整されます。 特定の経路が充血性の損失なしで4096バイトのイニシャル・バーストを吸収できないのは、可能です。 これが問題であると判明するなら、混雑敷居を経路にキャッシュして、要求で引き起こされた初期のパケット炸裂の最大サイズを測定するのにこの値を使用するのは可能であるべきです。
3.2 New TCP Options
3.2 新しいTCPオプション
Three new TCP options are defined: CC, CC.NEW, and CC.ECHO. Each
carries a connection count SEG.CC. The complete rules for sending
and processing these options are given in Section 3.4 below.
3つの新しいTCPオプションが定義されます: CC、CC.NEW、およびCC.ECHO。 それぞれが接続カウントSEG.CCを運びます。 セクション3.4でこれらのオプションを送って、処理するための完全な規則を以下に与えます。
Braden [Page 17] RFC 1644 Transaction/TCP July 1994
ブレーデン[17ページ]RFC1644取引/TCP1994年7月
CC Option
CCオプション
Kind: 11
種類: 11
Length: 6
長さ: 6
+--------+--------+--------+--------+--------+--------+
|00001011|00000110| Connection Count: SEG.CC |
+--------+--------+--------+--------+--------+--------+
Kind=11 Length=6
+--------+--------+--------+--------+--------+--------+ |00001011|00000110| 接続カウント: SEG.CC| +--------+--------+--------+--------+--------+--------+ 親切な=11長さ=の6
This option may be sent in an initial SYN segment, and it may
be sent in other segments if a CC or CC.NEW option has been
received for this incarnation of the connection. Its SEG.CC
value is the TCB.CCsend value from the sender's TCB.
初期のSYNセグメントでこのオプションを送るかもしれません、そして、接続のこの肉体化のためにCCかCC.NEWオプションを受け取ったなら、他のセグメントでそれを送るかもしれません。 SEG.CC値は送付者のTCBからのTCB.CCsend値です。
CC.NEW Option
CC.NEWオプション
Kind: 12
種類: 12
Length: 6
長さ: 6
+--------+--------+--------+--------+--------+--------+
|00001100|00000110| Connection Count: SEG.CC |
+--------+--------+--------+--------+--------+--------+
Kind=12 Length=6
+--------+--------+--------+--------+--------+--------+ |00001100|00000110| 接続カウント: SEG.CC| +--------+--------+--------+--------+--------+--------+ 親切な=12長さ=の6
This option may be sent instead of a CC option in an initial
<SYN> segment (i.e., SYN but not ACK bit), to indicate that the
SEG.CC value may not be larger than the previous value. Its
SEG.CC value is the TCB.CCsend value from the sender's TCB.
初期の<SYN>セグメント(すなわち、ACKではなく、SYNが噛み付いた)におけるCCオプションの代わりにSEG.CC値が前の値ほど大きくないかもしれないのを示すためにこのオプションを送るかもしれません。 SEG.CC値は送付者のTCBからのTCB.CCsend値です。
CC.ECHO Option
CC.ECHOオプション
Kind: 13
種類: 13
Length: 6
長さ: 6
+--------+--------+--------+--------+--------+--------+
|00001101|00000110| Connection Count: SEG.CC |
+--------+--------+--------+--------+--------+--------+
Kind=13 Length=6
+--------+--------+--------+--------+--------+--------+ |00001101|00000110| 接続カウント: SEG.CC| +--------+--------+--------+--------+--------+--------+ 親切な=13長さ=の6
This option must be sent (in addition to a CC option) in a
segment containing both a SYN and an ACK bit, if the initial
SYN segment contained a CC or CC.NEW option. Its SEG.CC value
is the SEG.CC value from the initial SYN.
SYNとACKビットの両方を含むセグメントでこのオプションを送らなければなりません(CCオプションに加えて)、初期のSYNセグメントがCCかCC.NEWオプションを含んだなら。 SEG.CC値は初期のSYNからのSEG.CC値です。
Braden [Page 18] RFC 1644 Transaction/TCP July 1994
ブレーデン[18ページ]RFC1644取引/TCP1994年7月
A CC.ECHO option should be sent only in a <SYN,ACK> segment and
should be ignored if it is received in any other segment.
CC.ECHOオプションを<SYN、ACK>セグメントだけで送るべきであり、いかなる他のセグメントでもそれを受け取るなら、無視するべきです。
3.3 Connection States
3.3 接続州
T/TCP requires new connection states and state transitions.
Figure 8 shows the resulting finite state machine; see [RFC-1379]
for a detailed development. If all state names ending in stars
are removed from Figure 8, the state diagram reduces to the
standard TCP state machine (see Figure 6 of [STD-007]), with two
exceptions:
T/TCPは新しい接続州と状態遷移を必要とします。 エイト環は結果として起こる有限状態機械を見せています。 詳細な開発に関して[RFC-1379]を見てください。 図8から星に終わるすべての州の名を取り除くなら、州のダイヤグラムは標準のTCP州のマシンに減少します([STD-007]の図6を見てください)、2つの例外で:
* STD-007 shows a direct transition from SYN-RECEIVED to FIN-
WAIT-1 state when the user issues a CLOSE call. This
transition is suspect; a more accurate description of the
state machine would seem to require the intermediate SYN-
RECEIVED* state shown in Figure 8.
* STD-007は、ユーザがいつCLOSE呼び出しを発行するかをダイレクトSYN-RECEIVEDからFIN- WAIT-1状態までの変遷に示します。 この変遷は疑わしいです。 州のマシンの、より正確な記述は図8で見せられた中間的SYN- RECEIVED*状態を必要とするように思えるでしょう。
* In STD-007, a user CLOSE call in SYN-SENT state causes a
direct transition to CLOSED state. The extended diagram of
Figure 8 forces the connection to open before it closes,
since calling CLOSE to terminate the request in SYN-SENT
state is normal behavior for a transaction client. In the
case that no data has been sent in SYN-SENT state, it is
reasonable for a user CLOSE call to immediately enter CLOSED
state and delete the TCB.
* STD-007では、SYN-SENT状態でのユーザCLOSE呼び出しはCLOSED状態へのダイレクト変遷を引き起こします。 図8の拡張ダイヤグラムによって、閉じる前に、接続はやむを得ず開きます、SYN-SENT状態で要求を終えるためにCLOSEと呼ぶのが、取引クライアントのための正常な行動であるので。 SYN-SENT状態でデータを全く送らないで、すぐに、CLOSED状態に入れて、TCBを削除するというユーザCLOSE要求に、それは妥当です。
Each of the new states in Figure 8 bears a starred name, created
by suffixing a star onto a standard TCP state. Each "starred"
state bears a simple relationship to the corresponding "unstarred"
state.
図8のそれぞれの新しい州は標準のTCP状態に星をsuffixingすることによって作成された主演された名前を示します。 それぞれの「主演された」州は対応する"非主演"の状態との簡単な関係に堪えます。
o SYN-SENT* and SYN-RECEIVED* differ from the SYN-SENT and
SYN-RECEIVED state, respectively, in recording the fact that
a FIN needs to be sent.
o SYN-SENT*とSYN-RECEIVED*はFINが、送られる必要があるという事実を記録するのにおいてそれぞれSYN-SENTとSYN-RECEIVED状態と異なっています。
o The other starred states indicate that the connection is
half-synchronized (hence, a SYN bit needs to be sent).
o 他の主演された州は、接続が半分連動されているのを示します(したがって、SYNビットは、送られる必要があります)。
Braden [Page 19] RFC 1644 Transaction/TCP July 1994
ブレーデン[19ページ]RFC1644取引/TCP1994年7月
________ g ________
| |<------------| |
| CLOSED |------------>| LISTEN |
|________| h ------|________|
| / | |
| / i| j|
| / | |
a| a'/ | _V______ ________
| / j | |ESTAB- | e' | CLOSE- |
| / -----------|-->| LISHED*|------------>| WAIT*|
| / / | |________| |________|
| / / | | | | |
| / / | | c| d'| c|
____V_V_ / _______V | __V_____ | __V_____
| SYN- | b' | SYN- |c | |ESTAB- | e | | CLOSE- |
| SENT |------>|RECEIVED|---|->| LISHED|----------|->| WAIT |
|________| |________| | |________| | |________|
| | | | | |
| | | | __V_____ |
| | | | | LAST- | |
d'| d'| d'| d| | ACK* | |
| | | | |________| |
| | | | | |
| | ______V_ | ________ |c' |d
| k | | FIN- | | e''' | | | |
| -------|-->| WAIT-1*|---|------>|CLOSING*| | |
| / | |________| | |________| | |
| / | | | | | |
| / | c'| | c'| | |
___V___ / ____V___ V_____V_ ____V___ V____V__
| SYN- | b'' | SYN- | c | FIN- | e'' | | | LAST- |
| SENT* |---->|RECEIVD*|---->| WAIT-1 |---->|CLOSING | | ACK |
|________| |________| |________| |________| |________|
| | |
f| f| f'|
___V____ ____V___ ___V____
| FIN- | e |TIME- | T | |
| WAIT-2 |---->| WAIT |-->| CLOSED |
|________| |________| |________|
________ g________ | | <、-、-、-、-、-、-、-、-、-、-、--、|、|、| 閉じられます。|、-、-、-、-、-、-、-、-、-、-、--、>| 聴いてください。| |________| h------|________| | / | | | /i| j| | / | | a| /| _V______ ________ | /j| |ESTAB| 'e'| 閉じてください。| | / -----------| -->、| LISHED*|、-、-、-、-、-、-、-、-、-、-、--、>| *を待ってください。| | / / | |________| |________| | / / | | | | | | / / | | c| 'd'| c| ____V_V_/_______V| __V_____ | __V_____ | SYN| 'b'| SYN|c| |ESTAB| e| | 閉じてください。| | 発信します。|、-、-、-、-、--、>|受信します。|、-、--、|、-、>| LISHED|、-、-、-、-、-、-、-、-、--、|、-、>| 待ち| |________| |________| | |________| | |________| | | | | | | | | | | __V_____ | | | | | | 最終| | 'd'| 'd'| 'd'| d| | ACK*| | | | | | |________| | | | | | | | | | ______V_| ________ |'c'|d| k| | フィン| | '「e」'| | | | | -------| -->、| 待-1ち*|、-、--、|、-、-、-、-、--、>|*を閉じます。| | | | / | |________| | |________| | | | / | | | | | | | / | 'c'| | 'c'| | | ___V___ / ____V___ V_____V_____V___ V____V__| SYN| 「b」| SYN| c| フィン| 「e」| | | 最終| | *を送りました。|、-、-、--、>|RECEIVD*|、-、-、--、>| 待ち-1|、-、-、--、>|閉じます。| | ACK| |________| |________| |________| |________| |________| | | | f| f| 'f'| ___V____ ____V___ ___V____ | フィン| e|時間| T| | | 待ち-2|、-、-、--、>| 待ち| -->、| 閉じられます。| |________| |________| |________|
Figure 8A: Basic T/TCP State Diagram
図8A: 基本的なT/TCP州のダイヤグラム
Braden [Page 20] RFC 1644 Transaction/TCP July 1994
ブレーデン[20ページ]RFC1644取引/TCP1994年7月
________________________________________________________________
| |
| Label Event / Action |
| _____ ________________________ |
| |
| a Active OPEN / create TCB, snd SYN |
| a' Active OPEN / snd SYN |
| b rcv SYN [no TAO]/ snd ACK(SYN) |
| b' rcv SYN [no TAO]/ snd SYN,ACK(SYN) |
| b'' rcv SYN [no TAO]/ snd SYN,FIN,ACK(SYN) |
| c rcv ACK(SYN) / |
| c' rcv ACK(SYN) / snd FIN |
| d CLOSE / snd FIN |
| d' CLOSE / snd SYN,FIN |
| e rcv FIN / snd ACK(FIN) |
| e' rcv FIN / snd SYN,ACK(FIN) |
| e'' rcv FIN / snd FIN,ACK(FIN) |
| e''' rcv FIN / snd SYN,FIN,ACK(FIN) |
| f rcv ACK(FIN) / |
| f' rcv ACK(FIN) / delete TCB |
| g CLOSE / delete TCB |
| h passive OPEN / create TCB |
| i (= b') rcv SYN [no TAO]/ snd SYN,ACK(SYN) |
| j rcv SYN [TAO OK] / snd SYN,ACK(SYN) |
| k rcv SYN [TAO OK] / snd SYN,FIN,ACK(SYN) |
| T timeout=2MSL / delete TCB |
| |
| |
| Figure 8B. Definition of State Transitions |
|________________________________________________________________|
________________________________________________________________ | | | ラベル出来事/動作| | _____ ________________________ | | | | Activeオープン/はTCB、snd SYNを作成します。| | Activeオープン/snd SYN| | b rcv SYN[TAOがない]/snd ACK(SYN)| | 'b'rcv SYN[TAOがない]/snd SYN、ACK(SYN)| | 「b」rcv SYN[TAOがない]/snd SYN、FIN、ACK(SYN)| | c rcv ACK(SYN)/| | 'c'rcv ACK(SYN)/snd FIN| | d CLOSE / snd FIN| | 'd'CLOSE / snd SYN、FIN| | e rcv FIN / snd ACK(FIN)| | 'e'rcv FIN / snd SYN、ACK(FIN)| | 「e」rcv FIN / snd FIN、ACK(FIN)| | 「'e」rcv FIN / snd SYN、FIN、ACK(FIN)'| | f rcv ACK(FIN)/| | 'f'rcv ACK(FIN)/はTCBを削除します。| | g CLOSE/はTCBを削除します。| | h受け身のオープン/はTCBを作成します。| | 'i(b'と等しい)rcv SYN[TAOがない]/snd SYN、ACK(SYN)| | j rcv SYN[TAO OK]/snd SYN、ACK(SYN)| | k rcv SYN[TAO OK]/snd SYN、FIN、ACK(SYN)| | Tタイムアウト=2MSL/はTCBを削除します。| | | | | | 図8B。 状態遷移の定義| |________________________________________________________________|
This simple correspondence leads to an alternative state model,
which makes it easy to incorporate the new states in an existing
implementation. Each state in the extended FSM is defined by the
triplet:
この簡単な通信は代替の州のモデルにつながります。(モデルは既存の実現に新しい州を法人組織にするのを簡単にします)。 拡張FSMの各状態は三つ子によって定義されます:
(old_state, SENDSYN, SENDFIN)
(古い_状態、SENDSYN、SENDFIN)
where 'old_state' is a standard TCP state and SENDFIN and SENDSYN
are Boolean flags see Figure 9. The SENDFIN flag is turned on (on
the client side) by a SEND(... EOF=YES) call, to indicate that a
FIN should be sent in a state which would not otherwise send a
FIN. The SENDSYN flag is turned on when the TAO test succeeds to
indicate that the connection is only half synchronized; as a
result, a SYN will be sent in a state which would not otherwise
send a SYN.
'古い_状態'が標準のTCP状態であり、SENDFINとSENDSYNがブールであるところでは、旗は図9を見ます。 FINがそうでなければFINを送らない州で送られるべきであるのを示すので、SENDFIN旗はSEND(… EOFははいと等しい)呼び出しでつけられています(クライアント側で)。 TAOテストが接続が半分同時にするだけであるのを示すために成功するとき、SENDSYN旗はつけられています。 その結果、そうでなければSYNを送らない州でSYNを送るでしょう。
Braden [Page 21] RFC 1644 Transaction/TCP July 1994
ブレーデン[21ページ]RFC1644取引/TCP1994年7月
________________________________________________________________
| |
| New state: Old_state: SENDSYN: SENDFIN: |
| __________ __________ ______ ______ |
| |
| SYN-SENT* => SYN-SENT FALSE TRUE |
| |
| SYN-RECEIVED* => SYN-RECEIVED FALSE TRUE |
| |
| ESTABLISHED* => ESTABLISHED TRUE FALSE |
| |
| CLOSE-WAIT* => CLOSE-WAIT TRUE FALSE |
| |
| LAST-ACK* => LAST-ACK TRUE FALSE |
| |
| FIN-WAIT-1* => FIN-WAIT-1 TRUE FALSE |
| |
| CLOSING* => CLOSING TRUE FALSE |
| |
| |
| Figure 9: Alternative State Definitions |
|________________________________________________________________|
________________________________________________________________ | | | 新しい州: 古い_州: SENDSYN: SENDFIN: | | __________ __________ ______ ______ | | | | SYN、-送って、SYNによって送られた状態で、*は本当に>と虚偽で等しいです。| | | | SYNを受け取られていさせた状態で、SYNによって容認された*は本当に>と虚偽で等しいです。| | | | 確立した*は本当に虚偽で設立された>と等しいです。| | | | -近くでは、待ちは*本当に>の厳密な待ちと虚偽で等しいです。| | | | -最後に、ACK*は本当に>の最後のACKと虚偽で等しいです。| | | | フィン待-1ち*は本当に>フィン待1ちと虚偽で等しいです。| | | | *を閉じるのは本当に虚偽で閉じる>と等しいです。| | | | | | 図9: 代替の州の定義| |________________________________________________________________|
Here is a more complete description of these boolean variables.
ここに、これらのブール変数の、より完全な記述があります。
* SENDFIN
* SENDFIN
SENDFIN is turned on by the SEND(...EOF=YES) call, and turned
off when FIN-WAIT-1 state is entered. It may only be on in
SYN-SENT* and SYN-RECEIVED* states.
FIN-WAIT-1状態が入られるとき、SENDFINはSEND(… EOFははいと等しい)呼び出しでつけられていて、オフにされます。 それはSYN-SENT*とSYN-RECEIVED*州だけでオンであるかもしれません。
SENDFIN has two effects. First, it causes a FIN to be sent
on the last segment of data from the user. Second, it causes
the SYN-SENT[*] and SYN-RECEIVED[*] states to transition
directly to FIN-WAIT-1, skipping ESTABLISHED state.
SENDFINには、2つの効果があります。 まず最初に、それで、データの最後のセグメントでユーザからFINを送ります。 2番目に、ESTABLISHED状態をスキップして、それはSYN-SENT[*]とSYN-RECEIVED[*]州を直接FIN-WAIT-1への変遷に引き起こします。
* SENDSYN
* SENDSYN
The SENDSYN flag is turned on when an initial SYN segment is
received and passes the TAO test. SENDSYN is turned off when
the SYN is acknowledged (specifically, when there is no RST
or SYN bit and SEG.UNA < SND.ACK).
SENDSYN旗は、初期のSYNセグメントが受け取られているとき、つけられていて、TAOテストに合格します。 SYNが承認されるとき(どんなRSTもSYNビットとSEG.UNA<SND.ACKも明確にないとき)、SENDSYNはオフにされます。
SENDSYN has three effects. First, it causes the SYN bit to
be set in segments sent with the initial sequence number
(ISN). Second, it causes a transition directly from LISTEN
state to ESTABLISHED*, if there is no FIN bit, or otherwise
SENDSYNには、3つの効果があります。 まず最初に、それで、初期シーケンス番号(ISN)と共に送られたセグメントでSYNビットを設定します。 2番目に、どんな噛み付いているか、またはそうでないFINもなければ、それが直接LISTEN状態からESTABLISHED*までの変遷を引き起こします。
Braden [Page 22] RFC 1644 Transaction/TCP July 1994
ブレーデン[22ページ]RFC1644取引/TCP1994年7月
to CLOSE-WAIT*. Finally, it allows data to be received and
processed (passed to the application) even if the segment
does not contain an ACK bit.
CLOSE-WAIT*最終的に、セグメントがACKビットを含まないでも、それは、データが受け取られて、処理されるのを(アプリケーションに通過されます)許容します。
According to the state model of the basic TCP specification [STD-
007], the server side must explicitly issued a passive OPEN call,
creating a TCB in LISTEN state, before an initial SYN may be
accepted. To accommodate truncation of TIME-WAIT state within
this model, it is necessary to add the five "I-states" shown in
Figure 10. The I-states are: LISTEN-LA, LISTEN-LA*, LISTEN-CL,
LISTEN-CL*, and LISTEN-TW. These are 'bridge states' between two
successive the state diagrams of two successive incarnations.
Here D is the duration of the previous connection, i.e., the
elapsed time since the connection opened. The transitions labeled
with lower-case letters are taken from Figure 8.
基本的なTCPの州のモデルに従って、[STD007]、サーバ側がそうしなければならない仕様は明らかに受け身のオープン呼び出しを発行しました、LISTEN状態でTCBを作成して、初期のSYNを受け入れるかもしれない前に。 このモデルの中にタイム誌-WAIT状態のトランケーションを収容するために、図10に示された5「I-州」を加えるのが必要です。 I-州は以下の通りです。 LAを聴いて、LA*を聴いて、Clを聴いて、Cl*を聴いて、TWを聴きます。 これらは2の間に連続した'橋の州'です。2回の連続した肉体化の州のダイヤグラム。 ここで、すなわち、接続が開いて以来の経過時間の間、Dは前の接続の持続時間です。 小文字アルファベットでラベルされた変遷は図8から抜粋されます。
Fortunately, many TCP implementations have a different user
interface model, in which the use can issue a generic passive open
("listen") call; thereafter, when a matching initial SYN arrives,
a new TCB in LISTEN state is automatically generated. With this
user model, the I-states of Figure 10 are unnecessary.
幸い、多くのTCP実現には、異なったユーザ・インタフェース・モデルがいます。(そこでは使用が(「聴いてください」)一般的な受け身の開いている呼び出しを発行できます)。 合っている初期のSYNがその後到着するとき、LISTEN状態の新しいTCBは自動的に発生します。 このユーザモデルでは、図10のI-事情は不要です。
For example, suppose an initial SYN segment arrives for a
connection that is in LAST-ACK state. If this segment carries a
CC option and if SEG.CC is greater than TCB.CCrecv in the existing
TCB, the "q" transition shown in Figure 10 can be made directly
from the LAST-ACK state. That is, the previous TCB is processed
as if an ACK(FIN) had arrived, causing the user to be notified of
a successful CLOSE and the TCB to be deleted. Then processing of
the new SYN segment is repeated, using a new TCB that is generated
automatically. The same principle can be used to avoid
implementing any of the I-states.
例えば、初期のSYNセグメントがLAST-ACK状態にある接続のために到着すると仮定してください。 このセグメントがCCオプションを運んで、既存のTCBでは、SEG.CCがTCB.CCrecvより大きいなら、直接LAST-ACK状態から図10に示された「q」変遷はすることができます。 まるでACK(FIN)が到着したかのようにすなわち、前のTCBは処理されます、削除されるためにユーザがうまくいっているCLOSEとTCBについて通知されることを引き起こして。 そして、自動的に発生する新しいTCBを使用して、新しいSYNセグメントの処理は繰り返されます。 I-州のどれかを実行するのを避けるのに同じ原則を使用できます。
Braden [Page 23] RFC 1644 Transaction/TCP July 1994
ブレーデン[23ページ]RFC1644取引/TCP1994年7月
______________________________
| P: Passive OPEN / |
| |
| Q: Rcv SYN, special TAO test | d'| d|
| (see text) / Delete TCB, | ________ ___V____ |
| create TCB, snd SYN | |LISTEN- | P | LAST- | |
| | | LA* |<-----| ACK* | |
| Q': (same as Q) if D < MSL | |________| |________| |
| | | | | |
| R: Rcv ACK(FIN) / Delete TCB,| Q| c'| c'| |
| create TCB | | | | |
| | | ___V____ V______V
| S': Active OPEN if D < MSL / | | |LISTEN- | P | LAST- |
| Delete TCB, create TCB, | | | LA |<-----| ACK |
| snd SYN. | | |________| |________|
|______________________________| | | | |
| Q| R| f|
________ ________ | | | |
e''' | | P |LISTEN- | | | V V
---->|CLOSING*|----->| CL* | | | LISTEN CLOSED
|________| |________| | |
| | Q| | |
c'| c'| V V V
| | ESTABLISHED*
____V___ V_______
e'' | | P |LISTEN- |
---->|CLOSING |------>| CL |
|________| |________|
| R| Q|
f| V V
| LISTEN ESTABLISHED*
____V___ _________
e |TIME- | P | LISTEN- |
---->| WAIT |------------->| TW |
|________| |_________|
/ | | | |
S'/ T| T| Q'| |S'
| _____V_ h _____V__ | V
| | |-------->| | | SYN-SENT
| | CLOSED |<--------| LISTEN | |
| |________| ------|________| |
| | / | j| |
| a| a'/ i| V V
| | / | ESTABLISHED*
V V V V
SYN-SENT ...
______________________________ | P: 受け身の戸外/| | | | Q: Rcv SYN、特別なTAOテスト| 'd'| d| | (テキストを見ます) /はTCBを削除します。| ________ ___V____ | | TCB、snd SYNを作成してください。| |聴いてください。| P| 最終| | | | | LA*| <、-、-、-、--、| ACK*| | | 'Q': (Qと同じこと) D<MSLです。| |________| |________| | | | | | | | | R: Rcv ACK(フィン)/はTCBを削除します。| Q| 'c'| 'c'| | | TCBを作成してください。| | | | | | | | ___V____ V______V| 'S': 能動態はD<MSL/であるなら開きます。| | |聴いてください。| P| 最終| | TCBを削除してください、そして、TCBを作成してください。| | | LA| <、-、-、-、--、| ACK| | snd SYN。 | | |________| |________| |______________________________| | | | | | Q| R| f| ________ ________ | | | | '「e」'| | P|聴いてください。| | | V V---->|*を閉じます。|、-、-、-、--、>| Cl*| | | じっと聞いてください。|________| |________| | | | | Q| | | 'c'| 'c'| V V V| | 確立した*____V___ V_______ 「e」| | P|聴いてください。| ---->|閉じます。|、-、-、-、-、--、>| Cl| |________| |________| | R| Q| f| V V| 確立した*を聴いてください。____V___ _________ e|時間| P| 聴いてください。| ---->| 待ち|、-、-、-、-、-、-、-、-、-、-、-、--、>| TW| |________| |_________| / | | | | 'S'/T| T| 'Q'| |S| _____V_h_____V__| V| | |、-、-、-、-、-、-、--、>|、|、| SYNによって送られます。| | 閉じられます。| <、-、-、-、-、-、-、--、| 聴いてください。| | | |________| ------|________| | | | / | j| | | a| /i| V V| | / | 確立した*V V V VはSYN発信しました…
Figure 10: I-States for TIME-WAIT Truncation
図10: 時間待ちトランケーションのためのI-州
Braden [Page 24] RFC 1644 Transaction/TCP July 1994
ブレーデン[24ページ]RFC1644取引/TCP1994年7月
3.4 T/TCP Processing Rules
3.4 T/TCP処理規則
This section summarizes the rules for sending and processing the
T/TCP options.
このセクションはT/TCPオプションを送って、処理するための規則をまとめます。
INITIALIZATION
初期化
I1: All cache entries cache.CC[*] and cache.CCsent[*] are
undefined (zero) when a host system initializes, and CCgen
is set to a non-zero value.
I1: ホストシステムであるときに、すべてのキャッシュエントリーのcache.CC[*]とcache.CCsent[*]が未定義の(ゼロ)である、初期化、CCgenは非ゼロ値に用意ができています。
I2: A new TCB is initialized with TCB.CCrecv = 0 and
TCB.CCsend = current CCgen value; CCgen is then
incremented. If the result is zero, CCgen is incremented
again.
I2: 新しいTCBはTCB.CCrecv=0で初期化されます、そして、TCB.CCsendは現在のCCgen値と等しいです。 そして、CCgenは増加されます。 結果がゼロであるなら、CCgenは再び増加されます。
SENDING SEGMENTS
送付セグメント
S1: Sending initial <SYN> Segment
S1: 送付の初期の<SYN>Segment
An initial <SYN> segment is sent with either a CC option
or a CC.NEW option. If cache.CCsent[fh] is undefined or
if TCB.CCsend < cache.CCsent[fh], then the option
CC.NEW(TCB.CCsend) is sent and cache.CCsent[fh] is set to
zero. Otherwise, the option CC(TCB.CCsend) is sent and
cache.CCsent[fh] is set to CCsend.
CCオプションかCC.NEWオプションのどちらかと共に初期の<SYN>セグメントを送ります。 cache.CCsent[fh]が未定義であるか、TCB.CCsend<cache.CCsent[fh]であるなら、オプションCC.NEW(TCB.CCsend)を送ります、そして、cache.CCsent[fh]はゼロに用意ができています。 さもなければ、オプションCC(TCB.CCsend)を送ります、そして、cache.CCsent[fh]はCCsendに用意ができています。
S2: Sending <SYN,ACK> Segment
S2: <SYN、ACK>にセグメントを送ります。
If the sender's TCB.CCrecv is non-zero, then a <SYN,ACK>
segment is sent with both a CC(TCB.CCsend) option and a
CC.ECHO (TCB.CCrecv) option.
<SYNであり送付者のTCB.CCrecvが非ゼロであるならCC(TCB.CCsend)オプションとCC.ECHOの両方と共にACK>セグメントを送ります。(TCB.CCrecv)オプション。
S3: Sending Non-SYN Segment
S3: 送付非SYNセグメント
A non-SYN segment is sent with a CC(TCB.CCsend) option if
the TCB.CCrecv value is non-zero, or if the state is SYN-
SENT or SYN-SENT* and cache.CCsent[fh] is non-zero (this
last is required to send CC options in the segments
following the first of a multi-segment request message;
see segment #2 in Figure 6).
状態がTCB.CCrecv値が非ゼロである、SYN- SENTまたはSYN-SENT*であるならCC(TCB.CCsend)オプションと共に非SYNセグメントを送ります、そして、cache.CCsent[fh]は非ゼロ(マルチセグメント要求メッセージの1番目に続いて、これが最後にセグメントでCCオプションを送るのに必要です;図6のセグメント#2を見る)です。
RECEIVING INITIAL <SYN> SEGMENT
初期の<SYN>セグメントを受けます。
Suppose that a server host receives a segment containing a SYN
bit but no ACK bit in LISTEN, SYN-SENT, or SYN-SENT* state.
サーバー・ホストがSYNビットを含んでいますが、LISTEN、SYN-SENT、またはSYN-SENT*州にどんなACKビットも含まないセグメントを受けると仮定してください。
Braden [Page 25] RFC 1644 Transaction/TCP July 1994
ブレーデン[25ページ]RFC1644取引/TCP1994年7月
R1.1:If the <SYN> segment contains a CC or CC.NEW option,
SEG.CC is stored into TCB.CCrecv of the new TCB.
R1.1: <SYN>セグメントがCCかCC.NEWオプションを含んでいるなら、SEG.CCは新しいTCBのTCB.CCrecvに格納されます。
R1.2:If the segment contains a CC option and if the local cache
entry cache.CC[fh] is defined and if
SEG.CC > cache.CC[fh], then the TAO test is passed and the
connection is half-synchronized in the incoming direction.
The server host replaces the cache.CC[fh] value by SEG.CC,
passes any data in the segment to the user, and processes
a FIN bit if present.
R1.2: セグメントがCCオプションを含んでいて、地方のキャッシュエントリーcache.CC[fh]が定義されて、SEG.CC>cache.CC[fh]であるなら、TAOテストに合格されて、接続は入って来る方向と半分同時にされます。 サーバー・ホストは、cache.CC[fh]値をSEG.CCに取り替えて、セグメントでどんなデータもユーザに渡して、存在しているなら、FINビットを処理します。
Acknowledgment of the SYN is delayed to allow piggybacking
on a response segment.
SYNの承認は、応答セグメントで便乗するのを許容するために遅れます。
R1.3:If SEG.CC <= cache.CC[fh] (the TAO test has failed), or if
cache.CC[fh] is undefined, or if there is no CC option
(but possibly a CC.NEW option), the server host proceeds
with normal TCP processing. If the connection was in
LISTEN state, then the host executes a 3-way handshake
using the standard TCP rules. In the SYN-SENT or SYN-
SENT* state (i.e., the simultaneous open case), the TCP
sends ACK(SYN) and enters SYN-RECEIVED state.
R1.3: SEG.CC<がcache.CC[fh]と等しい(TAOテストは失敗しました)、cache.CC[fh]が未定義である、またはCCオプション(しかし、ことによるとCC.NEWオプション)が全くなければ、サーバー・ホストは通常のTCP処理を続けます。 接続がLISTEN状態にあったなら、ホストは、標準のTCP規則を使用することで3ウェイ握手を実行します。 SYN-SENTかSYN- SENT*状態(すなわち、同時の開いているケース)では、TCPはACK(SYN)を送って、SYN-RECEIVED状態に入れます。
R1.4:If there is no CC option (but possibly a CC.NEW option),
then the server host sets cache.CC[fh] undefined (zero).
Receiving an ACK for a SYN (following application of rule
R1.3) will update cache.CC[fh], by rule R3.
R1.4: CCオプション(しかし、ことによるとCC.NEWオプション)が全くなければ、サーバー・ホストはcache.CC[fh]の未定義の(ゼロ)を設定します。 SYN(規則R1.3の次のアプリケーション)のためにACKを受けると、cache.CC[fh]は規則R3によってアップデートされるでしょう。
Suppose that an initial <SYN> segment containing a CC or CC.NEW
option arrives in an I-state (i.e., a state with a name of the
form 'LISTEN-xx', where xx is one of TW, LA, L8, CL, or CL*):
CCを含む初期の<SYN>セグメントかCC.NEWオプションがI-状態(すなわち、名前xxがTW、LA、L8、CL、またはCL*の1つであるフォーム'LISTEN-xx'がある状態)に到着すると仮定してください:
R1.5:If the state is LISTEN-TW, then the duration of the
current connection is compared with MSL. If duration >
MSL then send a RST:
R1.5: 状態がLISTEN-TWであるなら、現在の接続の持続時間はMSLと比較されます。 持続時間>MSLであるなら、RSTを送ってください:
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST、ACK>。
drop the packet, and return.
パケットを落としてください、そして、戻ってください。
R1.6:Perform a special TAO test: compare SEG.CC with
TCB.CCrecv.
R1.6: 特別なTAOテストを実行してください: TCB.CCrecvとSEG.CCを比べてください。
If SEG.CC is greater, then processing is performed as if
an ACK(FIN) had arrived: signal the application that the
previous close completed successfully and delete the
previous TCB. Then create a new TCB in LISTEN state and
reprocess the SYN segment against the new TCB.
SEG.CCが、より大きいなら、まるでACK(FIN)が到着したかのように処理は実行されます: 前の閉鎖が首尾よく終了したアプリケーションに合図してください、そして、前のTCBを削除してください。 次に、LISTEN状態で新しいTCBを作成してください。そうすれば、「再-過程」は新しいTCBに対するSYNセグメントを作成します。
Braden [Page 26] RFC 1644 Transaction/TCP July 1994
ブレーデン[26ページ]RFC1644取引/TCP1994年7月
Otherwise, silently discard the segment.
そうでなければ、静かにセグメントを捨ててください。
RECEIVING <SYN,ACK> SEGMENT
<SYN、ACK>セグメントを受けます。
Suppose that a client host receives a <SYN,ACK> segment for a
connection in SYN-SENT or SYN-SENT* state.
クライアントホストが接続のためにSYN-SENTかSYN-SENT*状態で<SYN、ACK>セグメントを受けると仮定してください。
R2.1:If SEG.ACK is not acceptable (see [STD-007]) and
cache.CCsent[fh] is non-zero, then simply drop the segment
without sending a RST. (The new SYN that the client is
(re-)transmitting will eventually acknowledge any
outstanding data and FIN at the server.)
R2.1: SEG.ACKが許容できないで([STD-007]を見てください)、cache.CCsent[fh]が非ゼロであるなら、RSTを送らないで、単にセグメントを落としてください。(クライアントがそうである新しいSYN、(再、)、伝えるのが結局サーバでどんな傑出しているデータとFINも承認する、)
R2.2:If the segment contains a CC.ECHO option whose SEG.CC is
different from TCB.CCsend, then the segment is
unacceptable and is dropped.
R2.2: セグメントがSEG.CCがTCB.CCsendと異なっているCC.ECHOオプションを含んでいるなら、セグメントは、容認できなく、落とされます。
R2.3:If cache.CCsent[fh] is zero, then it is set to TCB.CCsend.
R2.3: cache.CCsent[fh]がゼロであるなら、それはTCB.CCsendに設定されます。
R2.4:If the segment contains a CC option, its SEG.CC is stored
into TCB.CCrecv of the TCB.
R2.4: セグメントがCCオプションを含んでいるなら、SEG.CCはTCBのTCB.CCrecvに格納されます。
RECEIVING <ACK> SEGMENT IN SYN-RECEIVED STATE
SYNによって容認された状態で<ACK>セグメントを受けます。
R3.1:If a segment contains a CC option whose SEG.CC differs
from TCB.CCrecv, then the segment is unacceptable and is
dropped.
R3.1: セグメントがSEG.CCがTCB.CCrecvと異なっているCCオプションを含んでいるなら、セグメントは、容認できなく、落とされます。
R3.2:Otherwise, a 3-way handshake has completed successfully at
the server side. If the segment contains a CC option and
if cache.CC[fh] is zero, then cache.CC[fh] is replaced by
TCB.CCrecv.
R3.2: さもなければ、3ウェイ握手はサーバで側を首尾よく完成しました。 セグメントがCCオプションを含んでいて、cache.CC[fh]がゼロであるなら、cache.CC[fh]をTCB.CCrecvに取り替えます。
RECEIVING OTHER SEGMENT
他のセグメントを受けます。
R4: Any other segment received with a CC option is
unacceptable if SEG.CC differs from TCB.CCrecv. However,
a RST segment is exempted from this test.
R4: SEG.CCがTCB.CCrecvと異なっているなら、CCオプションで受け取られたいかなる他のセグメントも容認できません。 しかしながら、RSTセグメントはこのテストから免除されています。
OPEN REQUEST
開いている要求
To allow truncation of TIME-WAIT state, the following changes
are made in the state diagram for OPEN requests (see Figure
10):
タイム誌-WAIT状態のトランケーションを許容するために、以下の変更はオープン要求のための州のダイヤグラムで行われます(図10を見てください):
O1.1:A new passive open request is allowed in any of the
states: LAST-ACK, LAST-ACK*, CLOSING, CLOSING*, or TIME-
WAIT. This causes a transition to the corresponding I-
O1.1: 新しい受け身の開いている要求は州のどれかで許されています: 最後のACK、最後のACK*、閉鎖、閉鎖*、または時間待ってください。 これは対応するIへの変遷を引き起こします。
Braden [Page 27] RFC 1644 Transaction/TCP July 1994
ブレーデン[27ページ]RFC1644取引/TCP1994年7月
state (see Figure 10), which retains the previous state,
including the retransmission queue and timer.
州(図10を見ます)。(その州は再送キューとタイマを含む前のを保有します)。
O1.2 A new active open request is allowed in TIME-WAIT or
LISTEN-TW state, if the elapsed time since the current
connection opened is less than MSL. The result is to
delete the old TCB and create a new one, send a new SYN
segment, and enter SYN-SENT or SYN-SENT* state (depending
upon whether or not the SYN segment contains a FIN bit).
新しい活発な開いている要求が現在の接続が開いたので経過時間がMSL以下であるならタイム誌-WAITかLISTEN-TW状態で許されているO1.2。 結果は、古いTCBを削除して、新しいものを作成して、新しいSYNセグメントを送って、SYN-SENTかSYN-SENT*状態に入れる(SYNセグメントがFINビットを含んでいるかどうかによって)ことです。
Finally, T/TCP has a provision to improve performance for the case
of a client that "sprays" transactions rapidly using many
different server hosts and/or ports. If TCB.CCrecv in the TCB is
non-zero (and still assuming that the connection duration is less
than MSL), then the TIME-WAIT delay may be set to min(K*RTO,
2*MSL). Here RTO is the measured retransmission timeout time and
the constant K is currently specified to be 8.
最終的に、T/TCPには、急速に取引を「スプレーする」クライアントのケースのために多くの異なったサーバー・ホスト、そして/または、ポートを使用することで性能を向上させる支給があります。 TCBのTCB.CCrecvが非ゼロ(接続持続時間がMSL以下であるとまだ仮定していて)であるなら、タイム誌-WAIT遅れは分(K*RTO、2*MSL)に設定されるかもしれません。 ここで、RTOは測定再送タイムアウト時間です、そして、一定のKは、現在、8になるように指定されます。
3.5 User Interface
3.5 ユーザーインタフェース
STD-007 defines a prototype user interface ("transport service")
that implements the virtual circuit service model [STD-007,
Section 3.8]. One addition to this interface in required for
transaction processing: a new Boolean flag "end-of-file" (EOF),
added to the SEND call. A generic SEND call becomes:
STD-007は事実上のサーキットサービスモデル[STD-007、セクション3.8]を実行する原型ユーザーインタフェース(「輸送サービス」)を定義します。 これへの添加が連結する1つがトランザクション処理に必要です: SEND呼び出しに加えられた新しいブール旗の「ファイルの終り」(EOF。) 一般的なSEND呼び出しはなります:
Send
発信してください。
Format: SEND (local connection name, buffer address,
byte count, PUSH flag, URGENT flag, EOF flag [,timeout])
形式: 発信してください。(市内接続名、バッファアドレス、バイト・カウント、PUSH旗、EOFが旗を揚げさせるURGENT旗[タイムアウト])
The following text would be added to the description of SEND in
[STD-007]:
以下のテキストは[STD-007]のSENDの記述に加えられるでしょう:
If the EOF (End-Of-File) flag is set, any remaining queued
data is pushed and the connection is closed. Just as with the
CLOSE call, all data being sent is delivered reliably before
the close takes effect, and data may continue to be received
on the connection after completion of the SEND call.
EOF(ファイルの端)旗が設定されるなら、どんな残っている列に並ばせられたデータも押されます、そして、接続は閉じられます。 ちょうどCLOSE呼び出しのように、閉鎖が実施して、SEND呼び出しの完成の後に接続のときに受け取られ続けるかもしれない前に送られるすべてのデータを確かに送ります。
Figure 8A shows a skeleton sequence of user calls by which a
client could initiate a transaction. The SEND call initiates a
transaction request to the foreign socket (host and port)
specified in the passive OPEN call. The predicate "recv_EOF"
tests whether or not a FIN has been received on the connection;
this might be implemented using the STATUS command of [STD-007],
or it might be implemented by some operating-system-dependent
mechanism. When recv_EOF returns TRUE, the connection has been
図8Aはクライアントが取引を開始できるだろうユーザ呼び出しの骸骨の系列を示しています。 SEND呼び出しは受け身のオープン呼び出しで指定された外国ソケット(接待して、移植する)にトランザクション要求を開始します。 接続のときにFINを受け取ったか否かに関係なく、述部「recv_EOF」はテストします。 これが[STD-007]のSTATUSコマンドを使用することで実行されるかもしれませんか、またはそれは何らかの操作システム依存性機序によって実行されるかもしれません。 EOFがTRUE、接続を返すrecv_はいつですか。
Braden [Page 28] RFC 1644 Transaction/TCP July 1994
ブレーデン[28ページ]RFC1644取引/TCP1994年7月
completely closed and the client end of the connection is in
TIME-WAIT state.
完全に閉じられる、そして、接続の終わりがあるタイム誌-WAITが述べるクライアント。
__________________________________________________________________
| |
| |
| OPEN(local_port, foreign_socket, PASSIVE) -> conn_name; |
| |
| SEND(conn_name, request_buffer, length, |
| PUSH=YES, URG=NO, EOF=YES); |
| |
| while (not recv_EOF(conn_name)) { |
| |
| RECEIVE(conn_name, reply_buffer, length) -> count; |
| |
| <Process reply_buffer.> |
| } |
| |
| |
| Figure 8A: Client Side User Interface |
|__________________________________________________________________|
__________________________________________________________________ | | | | | オープン(地方の_ポート、外国_ソケット、PASSIVE)->コン_名。 | | | | SEND(コン_名、要求_バッファ、長さ、| | PUSH=はい、URG=ノー、EOF=はい)。 | | | | (recv_EOF(コン_名前)でない)である、| | | | RECEIVE(コン_名、回答_バッファ、長さ)->カウント; | | | | <Process回答_バッファ>|、|| | | | | | 図8A: クライアントサイドユーザーインタフェース| |__________________________________________________________________|
If a client is going to send a rapid series of such requests to
the same foreign_socket, it should use the same local_port for
all. This will allow truncation of TIME-WAIT state. Otherwise,
it could leave local_port wild, allowing TCP to choose successive
local ports for each call, realizing that each transaction may
leave behind a significant control block overhead in the kernel.
クライアントが急速なシリーズのそのような要求を同じ外国_ソケットに送るなら、それはすべてに同じ地方の_ポートを使用するべきです。 これはタイム誌-WAIT状態のトランケーションを許容するでしょう。 さもなければ、ワイルドな状態で地方の_ポートを出るかもしれません、TCPが各呼び出しのための連続した地方のポートを選ぶのを許容して、各取引がカーネルにおける重要な制御ブロックオーバーヘッドを後に残すかもしれないとわかって。
Figure 8B shows a basic sequence of server calls. The server
application waits for a request to arrive and then reads and
processes it until a FIN arrives (recv_EOF returns TRUE). At this
time, the connection is half-closed. The SEND call used to return
the reply completes the close in the other direction. It should
be noted that the use of SEND(... EOF=YES) in Figure 4B instead of
a SEND, CLOSE sequence is only an optimization; it allows
piggybacking the FIN in order to minimize the number of segments.
It should have little effect on transaction latency.
図8Bはサーバ呼び出しの基本的な系列を示しています。 FINが到着するまで、次に、サーバ・アプリケーションは、それを到着するという要求を待っていて、読んで、処理します(recv_EOFはTRUEを返します)。 このとき、接続は半開きです。 回答を返すのに使用されるSEND呼び出しはもう片方の指示に基づく閉鎖を完成します。 それが注意されるべきである、それ、SENDの代わりに図4BにおけるSEND(… EOFははいと等しい)の使用、CLOSE系列は最適化にすぎません。 それで、セグメントの数を最小にするためにFINを背負います。 それはほとんど取引潜在に影響を与えるべきではありません。
Braden [Page 29] RFC 1644 Transaction/TCP July 1994
ブレーデン[29ページ]RFC1644取引/TCP1994年7月
__________________________________________________________________
| |
| |
| OPEN(local_port, ANY_SOCKET, PASSIVE) -> conn_name; |
| |
| <Wait for connection to open.> |
| |
| STATUS(conn_name) -> foreign_socket |
| |
| while (not recv_EOF(conn_name)) { |
| |
| RECEIVE(conn_name, request_buffer, length) -> count; |
| |
| <Process request_buffer.> |
| } |
| |
| <Compute reply and store into reply_buffer.> |
| |
| SEND(conn_name, reply_buffer, length, |
| PUSH=YES, URG=NO, EOF=YES); |
| |
| |
| Figure 8B: Server Side User Interface |
|__________________________________________________________________|
__________________________________________________________________ | | | | | オープン(地方の_ポート、_いずれもSOCKET、PASSIVE)->コン_名。 | | | | 接続が開く<待ち。>|| | | STATUS(コン_名前)の->の外国_ソケット| | | | (recv_EOF(コン_名前)でない)である、| | | | RECEIVE(コン_名、要求_バッファ、長さ)->カウント; | | | | <Processは_バッファ>を要求します|、|| | | | <は回答_バッファの中に回答と店を計算します。>|| | | SEND(コン_名、回答_バッファ、長さ、| | PUSH=はい、URG=ノー、EOF=はい)。 | | | | | | 8Bは計算します: サーバサイドユーザーインタフェース| |__________________________________________________________________|
4. IMPLEMENTATION ISSUES
4. 導入問題
4.1 RFC-1323 Extensions
4.1 RFC-1323拡張子
A recently-proposed set of TCP enhancements [RFC-1323] defines a
Timestamps option, which carries two 32-bit timestamp values.
This option is used to accurately measure round-trip time (RTT).
The same option is also used in a procedure known as "PAWS"
(Protect Against Wrapped Sequence) to prevent erroneous data
delivery due to a combination of old duplicate segments and
sequence number reuse at very high bandwidths. The approach to
transactions specified in this memo is independent of the RFC-1323
enhancements, but implementation of RFC-1323 is desirable for all
TCP's.
最近提案されたセットのTCP増進[RFC-1323]はTimestampsオプションを定義します。(それは、2つの32ビットのタイムスタンプ値を運びます)。 このオプションは、正確に、往復の時間(RTT)を測定するのに使用されます。 また、同じオプションは、まさしくその高帯域で古い写しセグメントと一連番号再利用の組み合わせによる誤ったデータ配送を防ぐのに「足」(包装された系列を保護する)として知られている手順で使用されます。 このメモで指定された取引へのアプローチはRFC-1323増進から独立していますが、TCPのすべてのものに、RFC-1323の実現は望ましいです。
The RFC-1323 extensions share several common implementation issues
with the T/TCP extensions. Both require that TCP headers carry
options. Accommodating options in TCP headers requires changes in
the way that the maximum segment size is determined, to prevent
inadvertent IP fragmentation. Both require some additional state
variable in the TCB, which may or may not cause implementation
difficulties.
RFC-1323拡張子はT/TCP拡張子といくつかの一般的な導入問題を共有します。 両方が、TCPヘッダーがオプションを運ぶのを必要とします。 TCPヘッダーでオプションに対応するのは最大のセグメントサイズが不注意なIP断片化を防ぐために決定している方法で釣り銭がいます。 両方がTCBの何らかの追加州の変数を必要とします。(TCBは実現困難を引き起こすかもしれません)。
Braden [Page 30] RFC 1644 Transaction/TCP July 1994
ブレーデン[30ページ]RFC1644取引/TCP1994年7月
4.2 Minimal Packet Sequence
4.2 最小量のパケット系列
Most TCP implementations will require some small modifications to
allow the minimal packet sequence for a transaction shown in
Figure 2.
ほとんどのTCP実現が、図2に示された取引のための最小量のパケット系列を許容するためにいくつかの小さい変更を必要とするでしょう。
Many TCP implementations contain a mechanism to delay
acknowledgments of some subset of the data segments, to cut down
on the number of acknowledgment segments and to allow piggybacking
on the reverse data flow (typically character echoes). To obtain
minimal packet exchanges for transactions, it is necessary to
delay the acknowledgment of some control bits, in an analogous
manner. In particular, the <SYN,ACK> segment that is to be sent
in ESTABLISHED* or CLOSE-WAIT* state should be delayed. Note that
the amount of delay is determined by the minimum RTO at the
transmitter; it is a parameter of the communication protocol,
independent of the application. We propose to use the same delay
parameter (and if possible, the same mechanism) that is used for
delaying data acknowledgments.
多くのTCP実現が確認応答セグメントの数でデータ・セグメントの何らかの部分集合の承認をカットに遅らせて、裏面にデータフロー(通常キャラクタエコー)を背負うのを許容するメカニズムを含んでいます。 取引への最小量のパケット交換を得るのに、いくつかのコントロールビットの承認を遅らせるのが必要です、類似の方法で。 特に、<SYN、ESTABLISHED*で送られることになっているACK>セグメントまたはCLOSE-WAIT*状態が遅れるべきです。 遅れの量が送信機の最小のRTOによって測定されることに注意してください。 それはアプリケーションの如何にかかわらず通信プロトコルのパラメタです。 私たちは、データ承認を遅らせるのに使用されるのと同じ遅れパラメタ(そして、できれば同じメカニズム)を使用するよう提案します。
To get the FIN piggy-backed on the reply data (segment #3 in
Figure 2), thos implementations that have an implied PUSH=YES on
all SEND calls will need to augment the user interface so that
PUSH=NO can be set for transactions.
回答データ(図2のセグメント#3)でFINを背負わせるために、暗示しているPUSH=はいをすべてのSEND呼び出しに持っているthos実現は、そのPUSH=ノーを取引に設定できるようにユーザーインタフェースを増大させる必要があるでしょう。
4.3 RTT Measurement
4.3 RTT測定
Transactions introduce new issues into the problem of measuring
round trip times [Jacobson88].
取引は周遊旅行時間[Jacobson88]を測定するという問題に新規発行を取り入れます。
(a) With the minimal 3-segment exchange, there can be exactly one
RTT measurement in each direction for each transaction.
Since dynamic estimation of RTT cannot take place within a
single transaction, it must take place across successive
transactions. Therefore, cacheing the measured RTT and RTT
variance values is essential for transaction processing; in
normal virtual circuit communication, such cacheing is only
desirable.
(a) 最小量の3セグメントの交換と共に、各取引のための各方向には1つのRTT測定がまさにあることができます。 RTTのダイナミックな見積りが単一取引の中で行われることができないので、それは連続した取引の向こう側に行われなければなりません。 したがって、トランザクション処理に、測定RTTとRTT変化の値をcacheingするのは不可欠です。 単に正常な仮想のサーキットコミュニケーションでは、そのようなcacheingは望ましいです。
(b) At the completion of a transaction, the values for RTT and
RTT variance that are retained in the cache must be some
average of previous values with the values measured during
the transaction that is completing. This raises the question
of the time constant for this average; quite different
dynamic considerations hold for transactions than for file
transfers, for example.
(b) 取引の完成のときに、キャッシュで保有されるRTTのための値とRTT変化は値が完成である取引の間、測定されている前の値の何らかの平均であるに違いありません。 これはこの平均のために時定数の問題を引き起こします。 例えば、全く異なったダイナミックな問題はファイル転送で取引に当てはまります。
(c) An RTT measurement by the client will yield the value:
(c) クライアントによるRTT測定は値をもたらすでしょう:
Braden [Page 31] RFC 1644 Transaction/TCP July 1994
ブレーデン[31ページ]RFC1644取引/TCP1994年7月
T = RTT + min(SPT, ATO),
T=RTT+分(SPT、ATO)
where SPT (server processing time) was defined in the
introduction, and ATO is the timeout period for sending a
delayed ACK. Thus, the measured RTT includes SPT, which may
be arbitrarily variable; however, the resulting variability
of the measured T cannot exceed ATO. (In a popular TCP
implementation, for example, ATO = 200ms, so that the
variance of SPT makes a relatively small contribution to the
variance of RTT.)
SPT(サーバ処理時間)が序論で定義されて、ATOが遅れたACKを送るためのタイムアウト時間であるところ。 したがって、測定RTTはSPTを含んでいます。(SPTは任意に可変であるかもしれません)。 しかしながら、Tが超えることができない測定の結果として起こる可変性、ATO。 (例えば、ポピュラーなTCP実現において、ATOは200msと等しいです、SPTの変化がRTTの変化への比較的小さい貢献をするように。)
(d) Transactions sample the RTT at random times, which are
determined by the client and the server applications rather
than by the network dynamics. When there are long pauses
between transactions, cached path properties will be poor
predictors of current values in the network.
(d) 取引は無作為にRTTを抽出します。回。(その回はクライアントとネットワーク力学でというよりむしろサーバ・アプリケーションで決定しています)。 取引の間に長い間があるとき、キャッシュされた経路の特性はネットワークにおける現行価値の貧しい予言者になるでしょう。
Thus, the dynamics of RTT measurement for transactions differ from
those for virtual circuits. RTT measurements should work
correctly for very short connections but reduce to the current TCP
algorithms for long-lasting connections. Further study is this
issue is needed.
したがって、取引のためのRTT測定の力学は仮想のサーキットへのそれらと異なっています。 RTT測定値は、非常に背の低い接続のために正しく働いていますが、持続的な接続のために現在のTCPアルゴリズムに減少するべきです。 さらなる研究はこの問題が必要であるということです。
4.4 Cache Implementation
4.4 キャッシュ実現
This extension requires a per-host cache of connection counts.
This cache may also contain values of the smoothed RTT, RTT
variance, congestion avoidance threshold, and MSS values.
Depending upon the implementation details, it may be simplest to
build a new cache for these values; another possibility is to use
the routing cache that should already be included in the host
[RFC-1122].
この拡張子は接続カウントの1ホストあたり1つのキャッシュを必要とします。 また、このキャッシュは平坦なRTT、RTT変化、輻輳回避敷居、およびMSS値の値を含むかもしれません。 実現の詳細によって、これらの値のために新しいキャッシュを築き上げるのは最も簡単であるかもしれません。 別の可能性はホスト[RFC-1122]に既に含まれているべきであるルーティングキャッシュを使用することです。
Implementation of the cache may be simplified because it is
consulted only when a connection is established; thereafter, the
CC values relevant to the connection are kept in the TCB. This
means that a cache entry may be safely reused during the lifetime
of a connection, avoiding the need for locking.
接続が確立されるときだけ、それが相談されるので、キャッシュの実現は簡素化されるかもしれません。 その後、接続に関連しているCC値はTCBに保たれます。 これは、キャッシュエントリーが接続の生涯安全に再利用されるかもしれないことを意味します、ロックする必要性を避けて。
4.5 CPU Performance
4.5 CPUパフォーマンス
TCP implementations are customarily optimized for streaming of
data at high speeds, not for opening or closing connections.
Jacobson's Header Prediction algorithm [Jacobson90] handles the
simple common cases of in-sequence data and ACK segments when
streaming data. To provide good performance for transactions, an
implementation might be able to do an analogous "header
prediction" specifically for the minimal request and the response
TCP実現は接続を開くか、または終えることで最適化されるのではなく、データのストリーミングのために高速で通例に最適化されます。 データを流すとき、ジェーコブソンのHeader Predictionアルゴリズム[Jacobson90]は連続してデータとACKセグメントの簡単なよくある例を扱います。 望ましい市場成果を取引に提供するために、実現は特に最小量の要求と応答のための類似の「ヘッダー予測」ができるかもしれません。
Braden [Page 32] RFC 1644 Transaction/TCP July 1994
ブレーデン[32ページ]RFC1644取引/TCP1994年7月
segments.
セグメント。
The overhead of UDP provides a lower bound on the overhead of
TCP-based transaction processing. It will probably not be
possible to reach this bound for TCP transactions, since opening a
TCP connection involves creating a significant amount of state
that is not required by UDP.
UDPのオーバーヘッドはTCPベースのトランザクション処理のオーバーヘッドで下界を提供します。 TCP取引のためのこのバウンドに達するのはたぶん可能でないでしょう、TCP接続を開くのが、UDPによって必要とされないかなりの量の状態を創設することを伴うので。
McKenney and Dove [McKenney92] have pointed out that transaction
processing applications of TCP can stress the performance of the
demultiplexing algorithm, i.e., the algorithm used to look up the
TCB when a segment arrives. They advocate the use of hash-table
techniques rather than a linear search. The effect of
demultiplexing on performance may become especially acute for a
transaction client using the extended TCP described here, due to
TCB's left in TIME-WAIT state. A high rate of transactions from a
given client will leave a large number of TCB's in TIME-WAIT
state, until their timeout expires. If the TCP implementation
uses a linear search for demultiplexing, all of these control
blocks must be traversed in order to discover that the new
association does not exist. In this circumstance, performance of
a hash table lookup should not degrade severely due to
transactions.
McKenneyとDove[McKenney92]は、TCPのトランザクション処理アプリケーションが逆多重化アルゴリズム(すなわち、セグメントが到着するとき、TCBを見上げるのに使用されるアルゴリズム)の性能を強調できると指摘しました。 彼らはリニアサーチよりむしろハッシュ表のテクニックの使用を支持します。 性能への逆多重化の効果はここで説明された拡張TCPを使用することで取引クライアントには特に鋭くなるかもしれません、タイム誌-WAIT状態のTCBの左のため。 与えられたクライアントからの高い率の取引はタイム誌-WAIT状態にTCBの多くのものを残すでしょう、それらのタイムアウトが期限が切れるまで。 TCP実現が逆多重化にリニアサーチを使用するなら、新連合が存在しないと発見するためにこれらの制御ブロックのすべてを横断しなければなりません。 この状況では、ハッシュ表ルックアップの性能は取引のため厳しく下がるべきではありません。
4.6 Pre-SYN Queue
4.6 プレSYNは列を作ります。
Suppose that segment #1 in Figure 4 is lost in the network; when
segment #2 arrives in LISTEN state, it will be ignored by the TCP
rules (see [STD-007] p.66, "fourth other text and control"), and
must be retransmitted. It would be possible for the server side
to queue any ACK-less data segments received in LISTEN state and
to "replay" the segments in this queue when a SYN segment does
arrive. A data segment received with an ACK bit, which is the
normal case for existing TCP's, would still a generate RST
segment.
図4のセグメント#1がネットワークで失われていると仮定してください。 セグメント#2がLISTEN状態に到着するとき、それをTCP規則([STD-007]p.66と、「他のテキストと4番目のコントロール」を見る)で無視されて、再送しなければなりません。 サーバ側がLISTEN状態に受け取られたどんなACKなしのデータ・セグメントも列に並ばせて、SYNセグメントが到着するときのこの待ち行列におけるセグメントが「再演」であることは可能でしょう。 データ・セグメントはACKビットで受信されて、それでも、aはRSTセグメントを発生させるでしょうか?(ビットは既存のTCPのもののための正常なケースです)。
Note that queueing segments in LISTEN state is different from
queueing out-of-order segments after the connection is
synchronized. In LISTEN state, the sequence number corresponding
to the left window edge is not yet known, so that the segment
cannot be trimmed to fit within the window before it is queued.
In fact, no processing should be done on a queued segment while
the connection is still in LISTEN state. Therefore, a new "pre-
SYN queue" would be needed. A timeout would be required, to flush
the Pre-SYN Queue in case a SYN segment was not received.
接続が同時にした後にLISTENのセグメントが述べる待ち行列が待ち行列の不適切なセグメントと異なっていることに注意してください。 LISTEN状態では、左の窓の縁に対応する一連番号はまだ知られていません、それが列に並ばせられる前に窓の中で合うようにセグメントを整えることができないように。 事実上、接続がまだLISTEN状態にある間、列に並ばせられたセグメントで処理するべきでないこと。 したがって、新しい「プレSYN待ち行列」が必要でしょう。 タイムアウトが、SYNセグメントが受け取られないといけなかったのでPre-SYN Queueを洗い流すのに必要でしょう。
Although implementation of a pre-SYN queue is not difficult in BSD
TCP, its limited contribution to throughput probably does not
プレSYN待ち行列の実現はBSD TCP、スループットへの限られた貢献がたぶんそうしない難しいコネではありませんが
Braden [Page 33] RFC 1644 Transaction/TCP July 1994
ブレーデン[33ページ]RFC1644取引/TCP1994年7月
justify the effort.
努力を正当化してください。
6. ACKNOWLEDGMENTS
6. 承認
I am very grateful to Dave Clark for pointing out bugs in RFC-1379 and for helping me to clarify the model. I also wish to thank Greg Minshall, whose probing questions led to further elucidation of the issues in T/TCP.
私はRFC-1379でバグを指摘して、私がモデルをはっきりさせるのを助けてくださったことにデーブ・クラークに非常に感謝しています。 また、調べ質問がT/TCPでの問題の一層の解明に通じたグレッグMinshallに感謝申し上げます。
7. REFERENCES
7. 参照
[Jacobson88] Jacobson, V., "Congestion Avoidance and Control", ACM
SIGCOMM '88, Stanford, CA, August 1988.
[Jacobson88] ジェーコブソンと、V.と、「輻輳回避とコントロール」、ACM SIGCOMM88年、スタンフォード、カリフォルニア、8月1988
[Jacobson90] Jacobson, V., "4BSD Header Prediction", Comp Comm
Review, v. 20, no. 2, April 1990.
[Jacobson90] ジェーコブソン、V.、「4BSDヘッダー予測」、Comp Comm Review、v。 20 1990年4月のNo.2。
[McKenney92] McKenney, P., and K. Dove, "Efficient Demultiplexing
of Incoming TCP Packets", ACM SIGCOMM '92, Baltimore, MD, October
1992.
ボルチモア(MD)1992年10月の[McKenney92]McKenney、P.とK.鳩、「入って来るTCPパケットの効率的な逆多重化」ACM SIGCOMM92年。
[RFC-1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communications Layers", STD-3, RFC-1122, USC/Information Sciences
Institute, October 1989.
[RFC-1122] ブレーデン、R.、エド、「インターネットホストのための要件--コミュニケーションは層にする」、STD-3、RFC-1122、科学が設けるUSC/情報、10月1989日
[RFC-1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance, RFC-1323, LBL, USC/Information Sciences
Institute, Cray Research, February 1991.
[RFC-1323] ジェーコブソンとV.とブレーデン、R.とD.ボーマン、「高性能、RFC-1323、LBL、科学が設けるUSC/情報、クレイリサーチ、1991年2月のためのTCP拡張子。」
[RFC-1379] Braden, R., "Transaction TCP -- Concepts", RFC-1379,
USC/Information Sciences Institute, September 1992.
[RFC-1379]ブレーデン、R.、「取引TCP--、概念、」、RFC-1379、科学が設けるUSC/情報、9月1992日
[ShankarLee93] Shankar, A. and D. Lee, "Modulo-N Incarnation
Numbers for Cache-Based Transport Protocols", Report CS-TR-3046/
UIMACS-TR-93-24, University of Maryland, March 1993.
[ShankarLee93] 「キャッシュベースのトランスポート・プロトコルの法-N顕現番号」というシャンカル、A.、およびD.リーはCs-TR-3046/ UIMACS-TR-93-24を報告します、メリーランド大学、1993年3月。
[STD-007] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", STD-007, RFC-793,
USC/Information Sciences Institute, September 1981.
[STD-007] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD-007、RFC-793、科学が1981年9月に設けるUSC/情報。
Braden [Page 34] RFC 1644 Transaction/TCP July 1994
ブレーデン[34ページ]RFC1644取引/TCP1994年7月
APPENDIX A. ALGORITHM SUMMARY
付録A.アルゴリズム概要
This appendix summarizes the additional processing rules introduced by T/TCP. We define the following symbols:
この付録はT/TCPによって導入された追加処理規則をまとめます。 私たちは以下のシンボルを定義します:
Options
オプション
CC(SEG.CC): TCP Connection Count (CC) Option
CC.NEW(SEG.CC): TCP CC.NEW option
CC.ECHO(SEG.CC): TCP CC.ECHO option
CC(SEG.CC): TCP接続カウント(CC)オプションCC.NEW(SEG.CC): TCP CC.NEWオプションCC.ECHO(SEG.CC): TCP CC.ECHOオプション
Here SEG.CC is option value in segment.
ここで、SEG.CCはセグメントのオプション価値です。
Per-Connection State Variables in TCB
TCBの1接続あたりの州の変数
CCsend: CC value to be sent in segments
CCrecv: CC value to be received in segments
Elapsed: Duration of connection
CCsend: セグメントCCrecvで送られる値をCCしてください: 値をCCして、セグメントElapsedに受け取ってください: 接続の持続時間
Global Variables:
大域変数:
CCgen: CC generator variable
cache.CC[fh]: Cache entry: Last CC value received.
cache.CCsent[fh]: Cache entry: Last CC value sent.
CCgen: ジェネレータの可変cache.CC[fh]をCCしてください: エントリーをキャッシュしてください: 最後に、対価領収cache.CCsent[fh]をCCしてください: エントリーをキャッシュしてください: 最後のCC値は発信しました。
PSEUDO-CODE SUMMARY:
中間コード概要:
Passive OPEN => {
Create new TCB;
}
受け身の開いている=>。新しいTCBを作成してください。
Active OPEN => {
<Create new TCB>
CCrecv = 0;
CCsend = CCgen;
If (CCgen == 0xffffffff) then Set CCgen = 1;
else Set CCgen = CCgen + 1.
<Send initial {SYN} segment (see below)>
}
アクティブな開いている=>。<は新しいTCB>CCrecv=0を作成します; CCsendは次に、(CCgen=0xffffffff)Set CCgen=1であるならCCgenと等しいです; CCgen+1の<のSendの初期のほかのSet CCgen=SYNは>を区分します(以下を見ます)。
Send initial {SYN} segment => {
セグメント=>を初期のSYNに送ってください。
If (cache.CCsent[fh] == 0 OR CCsend < cache.CCsent[fh] ) then {
(0OR CCsend<cache.CCsent[fh]=cache.CCsent[fh])その時です。
Include CC.NEW(CCsend) option in segment;
Set cache.CCsent[fh] = 0;
セグメントでCC.NEW(CCsend)オプションを含めてください。 cache.CCsent[fh]=0を設定してください。
Braden [Page 35] RFC 1644 Transaction/TCP July 1994
ブレーデン[35ページ]RFC1644取引/TCP1994年7月
}
else {
ほか
Include CC(CCsend) option in segment;
Set cache.CCsent[fh] = CCsend;
}
}
セグメントでCC(CCsend)オプションを含めてください。 cache.CCsent[fh]=CCsendを設定してください。 } }
Send {SYN,ACK} segment => {
セグメント=>をSYN、ACKに送ってください。
If (CCrecv != 0) then
Include CC(CCsend), CC.ECHO(CCrecv) options in segment.
}
(CCrecv!=0)であるなら、Includeはセグメントで(CCsend)、CC.ECHO(CCrecv)にオプションをCCします。 }
Receive {SYN} segment in LISTEN, SYN-SENT, or SYN-SENT* state => {
LISTENのセグメント、SYN-SENT、またはSYN-SENT*が>と等しいと述べるSYNを受けてください。
If state == LISTEN then {
CCrecv = 0;
CCsend = CCgen;
If (CCgen == 0xffffffff) then Set CCgen = 1;
else Set CCgen = CCgen + 1.
}
その時=LISTENを述べてくださいならCCsendがCCgenと等しいというCCrecv=0は次に、Set CCgen=1 ; (CCgen=0xffffffff)ほかのSet CCgenであるならCCgen+1と等しいです。
If (Segment contains CC option OR
Segment contains CC.NEW option) then
Set CCrecv = SEG.CC.
セグメントはOR Segmentが含むCCオプションを含んでいます。(CC.NEWオプション) 次に、Set CCrecvはSEG.CCと等しいです。
if (Segment contains CC option AND
cache.CC[fh] != 0 AND
SEG.CC > cache.CC[fh] ) then { /* TAO Test OK */
(セグメントはCCオプションを含んでいます、そして、cache.CC[fh!]は0AND SEG.CC>cache.CC[fh]と等しいです)その時、/*TAO Testは*/を承認します。
Set cache.CC[fh] = CCrecv;
<Mark connection half-synchronized>
<Process data and/or FIN and return>
}
cache.CC[fh]=CCrecvを設定してください。 <マークの接続は><Processデータ、そして/または、FINとリターン>を半分連動させました。
If (Segment does not contain CC option) then
Set cache.CC[fh] = 0;
次に、(セグメントはCCオプションを含んでいません)Set cache.CC[fh]=0であるなら。
<Do normal TCP processing and return>.
}
<は通常のTCP処理をして、>を返します。 }
Receive {SYN} segment in LISTEN-TW, LISTEN-LA, LISTEN-LA*, LISTEN-CL,
or LISTEN-CL* state => {
受信してください。SYNが中でLISTEN-TWを区分する、LISTEN-LA、LISTEN LA*、LISTEN-CL、またはLISTEN-CLが>と等しいです*が、述べる。
Braden [Page 36] RFC 1644 Transaction/TCP July 1994
ブレーデン[36ページ]RFC1644取引/TCP1994年7月
If ( (Segment contains CC option AND CCrecv != 0 ) then {
(セグメントはCCオプションとCCrecv!=0を含んでいます)その時です。
If (state = LISTEN-TW AND Elapsed > MSL ) then
<Send RST, drop segment, and return>.
次に、(状態はLISTEN-TW AND Elapsed>MSLと等しいです)<Send RSTであるなら、セグメントを落としてください、そして、>を返してください。
if (SEG.CC > CCrecv ) then {
<Implicitly ACK FIN and data in retransmission queue>;
<Close and delete TCB>;
<Reprocess segment>.
/* Expect to match new TCB
* in LISTEN state.
*/
}
}
else
<Drop segment>.
}
(SEG.CC>CCrecv)その時、再送キュー>; <Closeの<Implicitly ACK FINとデータ、TCB>を削除してください; <Reprocessセグメント>/*が、LISTEN状態*/で新しいTCB*を合わせると予想する、ほかの<Dropセグメント>。 }
Receive {SYN,ACK} segment => {
受信、SYN、ACKは=>を区分します。
if (Segment contains CC.ECHO option AND
SEG.CC != CCsend) then
<Send a reset and discard segment>.
次に、(セグメントはCC.ECHOオプションAND SEG.CC!=CCsendを含んでいます)<Sendであるなら、リセットと破棄は>を区分します。
if (Segment contains CC option) then {
Set CCrecv = SEG.CC.
(セグメントはCCオプションを含んでいます)その時、セットCCrecvはSEG.CCと等しいです。
if (cache.CC[fh] is undefined) then
Set cache.CC[fh] = CCrecv.
}
}
次に、(cache.CC[fh]は未定義です)Set cache.CCであるなら、[fh]はCCrecvと等しいです。 } }
Send non-SYN segment => {
非SYNセグメント=>を送ってください。
if (CCrecv != 0 OR
(cache.CCsent[fh] != 0 AND
state is SYN-SENT or SYN-SENT*)) then
Include CC(CCsend) option in segment.
}
(0CCrecv!=OR(0とcache.CCsent[fh!]=状態は、SYN-SENTかSYN-SENT*である))であるなら、Includeはセグメントで(CCsend)オプションをCCします。 }
Receive non-SYN segment in SYN-RECEIVED state => {
SYN-RECEIVED状態=>で非SYNセグメントを受けてください。
if (Segment contains CC option AND RST bit is off) {
if (SEG.CC != CCrecv) then
<Segment is unacceptable; drop it and send an
(セグメントはAND RSTビットがあるCCオプションを含んでいます)、(SEG.CC!=CCrecv)であるなら、<Segmentは容認できません; それを落としてください、そして、発信してください。
Braden [Page 37] RFC 1644 Transaction/TCP July 1994
ブレーデン[37ページ]RFC1644取引/TCP1994年7月
ACK segment, as in normal TCP processing>.
正常なTCP処理>のようなACKセグメント。
if (cache.CC[fh] is undefined) then
Set cache.CC[fh] = CCrecv.
}
}
次に、(cache.CC[fh]は未定義です)Set cache.CCであるなら、[fh]はCCrecvと等しいです。 } }
Receive non-SYN segment in (state >= ESTABLISHED) => {
(州の>=ESTABLISHED)=>で非SYNセグメントを受けてください。
if (Segment contains CC option AND RST bit is off) {
if (SEG.CC != CCrecv) then
<Segment is unacceptable; drop it and send an
ACK segment, as in normal TCP processing>.
}
}
(セグメントはAND RSTビットがあるCCオプションを含んでいます)、(SEG.CC!=CCrecv)であるなら、<Segmentは容認できません; ACKセグメントを止めて、送ってください、正常なTCP処理>のように。 }
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
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
Braden [Page 38]
ブレーデン[38ページ]
一覧
スポンサーリンク
