RFC1379 日本語訳
1379 Extending TCP for Transactions -- Concepts. R. Braden. November 1992. (Format: TXT=91353 bytes) (Updated by RFC1644) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Braden
Request for Comments: 1379 ISI
November 1992
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 1379 ISI1992年11月
Extending TCP for Transactions -- Concepts
トランザクションのためにTCPを広げます--概念
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This extension would fill the large gap between connection-oriented TCP and datagram-based UDP, allowing TCP to efficiently perform many applications for which UDP is currently used. A separate memo contains a detailed functional specification for this proposed extension.
このメモは、仮想の回路操作を変更しないでトランザクション指向のサービスを提供するためにTCPの拡大について議論します。 この拡大は接続指向のTCPとデータグラムベースのUDPの大穴をいっぱいにしているでしょう、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. TRANSACTIONS USING STANDARD TCP ............................... 3
3. BYPASSING THE 3-WAY HANDSHAKE ................................. 6
3.1 Concept of TAO ........................................... 6
3.2 Cache Initialization ..................................... 10
3.3 Accepting <SYN,ACK> Segments ............................. 11
4. SHORTENING TIME-WAIT STATE .................................... 13
5. CHOOSING A MONOTONIC SEQUENCE ................................. 15
5.1 Cached Timestamps ........................................ 16
5.2 Current TCP Sequence Numbers ............................. 18
5.3 64-bit Sequence Numbers .................................. 20
5.4 Connection Counts ........................................ 20
5.5 Conclusions .............................................. 21
6. CONNECTION STATES ............................................. 24
7. CONCLUSIONS AND ACKNOWLEDGMENTS ............................... 32
APPENDIX A: TIME-WAIT STATE AND THE 2-PACKET EXCHANGE ............ 34
REFERENCES ....................................................... 37
Security Considerations .......................................... 38
Author's Address ................................................. 38
1. 序論… 2 2. 標準のTCPを使用するトランザクション… 3 3. 3ウェイ握手を迂回させます… 6 TAOの3.1概念… 6 3.2 初期設定をキャッシュしてください… 10 3.3 <SYN、ACK>セグメントを受け入れます… 11 4. 時間待ち状態を短くします… 13 5. 単調列を選びます… 15 5.1はタイムスタンプをキャッシュしました… 16 5.2 現在のTCP一連番号… 18 5.3の64ビットの一連番号… 20 5.4 接続は数えます… 20 5.5の結論… 21 6. 接続州… 24 7. 結論AND承認… 32 付録A: 時間待ち状態と2パケットの交換… 34の参照箇所… 37 セキュリティ問題… 38作者のアドレス… 38
Braden [Page 1] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[1ページ]RFC1379トランザクションTCP--概念1992年11月
1. INTRODUCTION
1. 序論
The TCP protocol [STD-007] implements a virtual-circuit transport service that provides reliable and ordered data delivery over a full-duplex connection. Under the virtual circuit model, the life of a connection is divided into three distinct phases: (1) opening the connection to create a full-duplex byte stream; (2) transferring data in one or both directions over this stream; and (3) closing the connection. Remote login and file transfer are examples of applications that are well suited to virtual-circuit service.
TCPプロトコル[STD-007]は、仮想の回路が信頼できて注文されたデータ配送を全二重接続の上に提供する輸送サービスであると実装します。 事実上の回路モデルの下では、接続の寿命は3つの異なったフェーズに分割されます: (1) 全二重バイトを作成するために接続を開いて、流れてください。 (2) 1でデータを移すか、これの上の方向の両方が流れます。 (3) そして、接続を終えること。 リモート・ログインとファイル転送は仮想の回路サービスによく合っているアプリケーションに関する例です。
Distributed applications, which are becoming increasingly numerous and sophisticated in the Internet, tend to use a transaction-oriented rather than a virtual circuit style of communication. Currently, a transaction-oriented Internet application must choose to suffer the overhead of opening and closing TCP connections or else build an application-specific transport mechanism on top of the connectionless transport protocol UDP. Greater convenience, uniformity, and efficiency would result from widely-available kernel implementations of a transport protocol supporting a transaction service model [RFC- 955].
分配されたアプリケーション(インターネットでますます多数で洗練されるようになっている)は、仮想であるというよりむしろトランザクション指向の回路スタイルに関するコミュニケーションを使用する傾向があります。 現在、トランザクション指向のインターネットアプリケーションは、TCP接続を開いて、終えるオーバーヘッドを受けるか、またはコネクションレスなトランスポート・プロトコルUDPの上にアプリケーション特有の移送機構を造るのを選ばなければなりません。 大便利、一様性、および効率はトランザクションサービスモデルが[RFC955]であるとサポートするトランスポート・プロトコルの広く利用可能なカーネル実装から生じるでしょう。
The transaction service model has the following features:
トランザクションサービスモデルには、以下の特徴があります:
* The fundamental interaction is a request followed by a response.
* 基本的な相互作用は応答がいうことになった要求です。
* An explicit open or close phase would impose excessive overhead.
* 明白な開いているか近いフェーズは過度のオーバーヘッドを課すでしょう。
* At-most-once semantics is required; that is, a transaction must
not be "replayed" by a duplicate request packet.
* 大部分、一度、意味論が必要です。 すなわち、トランザクションは写しリクエスト・パケットによって「再演されてはいけません」。
* In favorable circumstances, a reliable request/response
handshake can be performed with exactly one packet in each
direction.
* 順境では、ちょうど各方向への1つのパケットで信頼できる要求/応答握手を実行できます。
* The minimum transaction latency for a client is RTT + SPT, where
RTT is the round-trip time and SPT is the server processing
time.
* クライアントにとって、最小のトランザクション潜在はRTT+SPTです。(そこでは、RTTが往復の時間であり、SPTはサーバ処理時間です)。
We use the term "transaction transport protocol" for a transport- layer protocol that follows this model [RFC-955].
私たちはこのモデル[RFC-955]に続く輸送層のプロトコルに「トランザクショントランスポート・プロトコル」という用語を使用します。
The Internet architecture allows an arbitrary collection of transport protocols to be defined on top of the minimal end-to-end datagram service provided by IP [Clark88]. In practice, however, production systems implement only TCP and UDP at the transport layer. It has proven difficult to leverage a new transport protocol into place, to be widely enough available to be useful for application builders.
インターネットアーキテクチャは、トランスポート・プロトコルの任意の収集が終わりから終わりへのIP[Clark88]によって提供された最小量のデータグラムサービスの上で定義されるのを許容します。 しかしながら、実際には、プロダクションシステムはトランスポート層でTCPとUDPだけを実装します。 新しいトランスポート・プロトコルを場所に利用するのが、アプリケーションビルダーの役に立つように十分広く利用可能になるように難しいと判明しました。
Braden [Page 2] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[2ページ]RFC1379トランザクションTCP--概念1992年11月
This memo explores an alternative approach to providing a transaction transport protocol: extending TCP to implement the transaction service model, while continuing to support the virtual circuit model. Each transaction will then be a single instance of a TCP connection. The proposed transaction extension is effectively implementable within current TCPs and operating systems, and it should also scale to the much faster networks, interfaces, and CPUs of the future.
このメモはトランザクショントランスポート・プロトコルを提供することへの代替的アプローチについて調査します: 事実上の回路モデルをサポートし続けている間、トランザクションサービスモデルを実装するためにTCPを広げています。 そして各トランザクションはTCP接続のただ一つのインスタンスになるでしょう。 事実上、提案されたトランザクション拡大は現在のTCPsとオペレーティングシステムの中で実装可能です、そして、また、それは未来のはるかに速いネットワーク、インタフェース、およびCPUに比例するべきです。
The present memo explains the theory behind the extension, in somewhat exquisite detail. Despite the length and complexity of this memo, the TCP extensions required for transactions are in fact quite limited and simple. Another memo [TTCP-FS] provides a self-contained functional specification of the extensions.
現在のメモで、いくらか絶妙の詳細における拡大の後ろで理論がわかります。 このメモの長さと複雑さにもかかわらず、トランザクションに必要であるTCP拡張子は、事実上、かなり限られていて簡単です。 別のメモ[TTCP-FS]は拡大の自己充足的な機能的な仕様を提供します。
Section 2 of this memo describes the limitations of standard TCP for transaction processing, to motivate the extensions. Sections 3, 4, and 5 explore the fundamental extensions that are required for transactions. Section 6 discusses the changes required in the TCP connection state diagram. Finally, Section 7 presents conclusions and acknowledgments. Familiarity with the standard TCP protocol [STD-007] is assumed.
このメモのセクション2は、拡大を動機づけるためにトランザクション処理のための標準のTCPの限界について説明します。 セクション3、4、および5 トランザクションに必要である基本的な拡大について調査してください。 セクション6はTCP接続州のダイヤグラムで必要である変化について論じます。 最終的に、セクション7は結論と承認を提示します。 標準のTCPプロトコル[STD-007]への親しみは想定されます。
2. TRANSACTIONS USING STANDARD TCP
2. 標準のTCPを使用するトランザクション
Reliable transfer of data depends upon sequence numbers. Before data transfer can begin, both parties must "synchronize" the connection, i.e, agree on common sequence numbers. The synchronization procedure must preserve at-most-once semantics, i.e., be free from replay hazards due to duplicate packets. The TCP developers adopted a synchronization mechanism known as the 3-way handshake.
信頼できるデータ転送は一連番号に依存します。 データ転送が始まることができる前に、双方は接続、i.eが同意する「連動してください」共通配列番号が始まらなければなりません。 同期手順が保存しなければならない、大部分、一度、意味論、すなわち、パケットをコピーするのにおいて当然の再生危険から、自由であってください。 TCP開発者は3ウェイ握手として知られている同期メカニズムを採用しました。
Consider a simple transaction in which client host A sends a single- segment request to server host B, and B returns a single-segment response. Many current TCP implementations use at least ten segments (i.e., packets) for this sequence: three for the 3-way handshake opening the connection, four to send and acknowledge the request and response data, and three for TCP's full-duplex data-conserving close sequence. These ten segments represent a high relative overhead for two data-bearing segments. However, a more important consideration is the transaction latency seen by the client: 2*RTT + SPT, larger than the minimum by one RTT. As CPU and network speeds increase, the relative significance of this extra transaction latency also increases.
クライアントホストAがただ一つのセグメント要求をサーバー・ホストBに送る単純取引を考えてください。そうすれば、Bはただ一つのセグメント応答を返します。 多くの現在のTCP実装がこの系列に、少なくとも10のセグメント(すなわち、パケット)を使用します: 要求と応答データを送って、承諾するために4歳の接続を開く3ウェイ握手のための3、およびTCPの全二重データ保存のための3は系列を閉じます。 これらの10のセグメントが2つのデータを持つセグメントのために高い相対的なオーバーヘッドを表します。 しかしながら、より重要な考慮すべき事柄はクライアントによって見られたトランザクション潜在です: 最小限より1RTTで大きい2*RTT+SPT。 また、CPUとネットワーク速度が上がるのに従って、この付加的なトランザクション潜在の相対的な意味は増加します。
Proposed transaction transport protocols have typically used a "timer-based" approach to connection synchronization [Birrell84]. In this approach, once end-to-end connection state is established in the client and server hosts, a subset of this state is maintained for
提案されたトランザクショントランスポート・プロトコルは接続同期[Birrell84]への「タイマベース」のアプローチを通常使用しました。 このアプローチで終わりから端への接続状態がいったんクライアントとサーバホスト、この状態の部分集合が維持されるaに設置されると
Braden [Page 3] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[3ページ]RFC1379トランザクションTCP--概念1992年11月
some period of time. A new request before the expiration of this timeout period can then reestablish the full state without an explicit handshake. Watson pointed out that the timer-based approach of his Delta-T protocol [Watson81] would encompass both virtual circuits and transactions. However, the TCP group adopted the 3-way handshake (because of uncertainty about the robustness of enforcing the packet lifetime bounds required by Delta-T, within a general Internet environment). More recently, Liskov, Shrira, and Wroclawski [Liskov90] have proposed a different timer-based approach to connection synchronization, requiring loosely-synchronized clocks in the hosts.
いつかの期間。 そして、このタイムアウト時間の満了の前の新しい要求は明白な握手なしで完全な状態を回復させることができます。 ワトソンは、彼のデルタ-Tプロトコル[Watson81]のタイマベースのアプローチが仮想の回路とトランザクションの両方を取り囲むと指摘しました。 しかしながら、TCPグループは3ウェイ握手(一般的なインターネット環境の中でデルタ-Tによって必要とされたパケット生存期間の領域を実施する丈夫さに関する不確実性による)を採用しました。 より最近、Liskov、Shrira、およびWroclawski[Liskov90]は接続同期への異なったタイマベースのアプローチを提案しました、ホストで緩く連動している時計を必要として。
The technique proposed in this memo, suggested by Clark [Clark89], depends upon cacheing of connection state but not upon clocks or timers; it is described in Section 3 below. Garlick, Rom, and Postel also proposed a connection synchronization mechanism using cached state [Garlick77]. Their scheme required each host to maintain connection records containing the highest sequence number on each connection. The technique suggested here retains only per-host state, not per-connection state.
クラーク[Clark89]によって提案されたこのメモで提案されたテクニックは、接続状態をcacheingするのによりますが、時計かタイマでよるというわけではありません。 それは以下のセクション3で説明されます。 また、ガーリック、Rom、およびポステルは、キャッシュされた状態[Garlick77]を使用することで接続同期メカニズムを提案しました。 それらの体系は、各ホストが含む中で各接続で一連番号最も高い接続記録を保守するのを必要としました。 ここに示されたテクニックは1接続あたりの状態ではなく、ホストだけあたりの状態を保有します。
During TCP development, it was suggested that TCP could support transactions with data segments containing both SYN and FIN bits. (These "Kamikaze" segments were not supported as a service; they were used mainly to crash other experimental TCPs!) To illustrate this idea, Figure 1 shows a plausible application of the current TCP rules to create a minimal transaction. (In fact, some minor adjustments in the standard TCP spec would be required to make Figure 1 fully legal [STD-007]).
TCP開発の間、TCPがデータ・セグメントがSYNとFINビットの両方を含んでいるトランザクションをサポートすることができることが提案されました。 (これらの「神風」セグメントはサービスとしてサポートされませんでした; それらは主に他の実験的なTCPs!を墜落させるのに使用されました) この考えを例証するなら、図1は、最小量のトランザクションを作成するために現在のTCP規則のもっともらしい適用を示しています。 (事実上、標準のTCP仕様に基づくいくつかの小さい方の調整が図1を完全に法的な[STD-007]にするのに必要でしょう。)
Figure 1, like many of the examples shown in this memo, uses an abbreviated form to illustrate segment sequences. For clarity and brevity, it omits explicit sequence and acknowledgment numbers, assuming that these will follow the well-known TCP rules. The notation "ACK(x)" implies a cumulative acknowledgment for the control bit or data "x" and everything preceding "x" in the sequence space. The referent of "x" should be clear from the context. Also, host A will always be the client and host B will be the server in these diagrams.
このメモに示された例の多くのように、図1は、セグメント系列を例証するのに簡略化されたフォームを使用します。 明快と簡潔さのために、これらがよく知られるTCP規則に従うと仮定して、それは明白な系列と確認応答番号を省略します。 記法"ACK(x)"は、系列スペースで「x」に先行しながら、コントロールビットかデータ「x」とすべてのための累積している承認を含意します。 「x」の指示物は文脈から明確であるはずです。 また、ホストAはいつもクライアントになるでしょう、そして、ホストBはこれらのダイヤグラムでサーバになるでしょう。
The first three segments in Figure 1 implement the standard TCP three-way handshake. If segment #1 had been an old duplicate, the client side would have sent an RST (Reset) bit in segment #3, terminating the sequence. The request data included on the initial SYN segment cannot be delivered to user B until segment #3 completes the 3-way handshake. Loading control bits onto the segments has reduced the total number of segments to 5, but the client still observes a transaction latency of 2*RTT + SPT. The 3-way handshake
図1の最初の3つのセグメントが、標準のTCPが3方向ハンドシェイクであると実装します。 セグメント#1が古い写しであったなら、クライアント側はセグメント#3でRST(リセット)ビットを送ったでしょうに、系列を終えて。 セグメント#3が3ウェイ握手を終了するまで、初期のSYNセグメントに要求データを含んでいるのをユーザBに提供できません。 セグメントへのローディング管理ビットはセグメントの総数を5まで減少させましたが、クライアントはまだ2*RTT+SPTのトランザクション潜在を観測しています。 3ウェイ握手
Braden [Page 4] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[4ページ]RFC1379トランザクションTCP--概念1992年11月
thus precludes high-performance transaction processing.
その結果、高性能トランザクション処理を排除します。
TCP A (Client) TCP B (Server)
_______________ ______________
TCPは(クライアント)TCP B(サーバ)です。_______________ ______________
CLOSED LISTEN
閉じられて、聴いてください。
(Client sends request)
1. SYN-SENT --> <SYN,data1,FIN> --> SYN-RCVD
(data1 queued)
(クライアントは要求を送ります) 1。 SYNによって送られた(><SYN、data1、フィン>)>SYN-RCVD(列に並ばせられたdata1)
2. ESTABLISHED <-- <SYN,ACK(SYN)> <-- SYN-RCVD
2. 確立した<--<SYN、ACK(SYN)><--SYN-RCVD
3. FIN-WAIT-1 --> <ACK(SYN),FIN> --> CLOSE-WAIT
(data1 to server)
3. フィン待1ち--><ACK(SYN)、フィン>-->の厳密な待ち(サーバへのdata1)
(Server sends reply)
4. TIME-WAIT <-- <ACK(FIN),data2,FIN> <-- LAST-ACK
(data2 to client)
(サーバは回答を送ります) 4。 時間待ち<--<ACK(フィン)、data2、フィン><--最後のACK(クライアントへのdata2)
5. TIME-WAIT --> <ACK(FIN)> --> CLOSED
5. 時間待ち--><ACK(フィン)>-->は閉じました。
(timeout)
CLOSED
(タイムアウト)は閉じました。
Figure 1: Transaction Sequence: RFC-793 TCP
図1: トランザクション系列: RFC-793 TCP
The TCP close sequence also poses a performance problem for transactions: one or both end(s) of a closed connection must remain in "TIME-WAIT" state until a 4 minute timeout has expired [STD-007]. The same connection (defined by the host and port numbers at both ends) cannot be reopened until this delay has expired. Because of TIME-WAIT state, a client program should choose a new local port number (i.e., a different connection) for each successive transaction. However, the TCP port field of 16 bits (less the "well-known" port space) provides only 64512 available user ports. This limits the total rate of transactions between any pair of hosts to a maximum of 64512/240 = 268 per second. This is much too low a rate for low-delay paths, e.g., high-speed LANs. A high rate of short connections (i.e., transactions) could also lead to excessive consumption of kernel memory by connection control blocks in TIME- WAIT state.
また、TCPの近い系列はトランザクションのために性能問題を引き起こします: 4分間のタイムアウトが[STD-007]を吐き出すまで、1か閉じている接続の終わりの両方が「時間待ち」州に残らなければなりません。 この遅れが期限が切れるまで、同じ接続(両端におけるホストとポートナンバーで、定義される)は再開できません。 タイム誌-WAIT状態のために、クライアントプログラムはそれぞれの連続したトランザクションのための新しい地方のポートナンバー(すなわち、異なった接続)を選ぶはずです。 しかしながら、16ビット(より少ない「よく知られる」ポートスペース)のTCPポート分野は64512の利用可能なユーザポートだけを提供します。 これはどんな組のホストの間のトランザクション対最大64512/240 = 268の1秒あたりの総レートを制限します。 これは低い遅れ経路、例えば、高速LANの低過ぎるレートに多いです。 また、高い率の背の低い接続(すなわち、トランザクション)はタイム誌WAIT状態で接続制御ブロックでカーネルメモリの過剰消費につながることができました。
In summary, to perform efficient transaction processing in TCP, we need to suppress the 3-way handshake and to shorten TIME-WAIT state.
概要では、TCPで効率的なトランザクション処理を実行するために、私たちは、3ウェイ握手を抑圧して、タイム誌-WAIT状態を短くする必要があります。
Braden [Page 5] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[5ページ]RFC1379トランザクションTCP--概念1992年11月
Protocol mechanisms to accomplish these two goals are discussed in Sections 3 and 4, respectively. Both require the choice of a monotonic sequence-like space; Section 5 analyzes the choices and makes a selection for this space. Finally, the TCP connection state machine must be extended as described in Section 6.
セクション3と4でそれぞれこれらの2つの目標を達成するプロトコルメカニズムについて議論します。 両方が単調な系列のようなスペースの選択を必要とします。 セクション5は、選択を分析して、このスペースに選定します。 最終的に、セクション6で説明されるようにTCP接続州のマシンを広げなければなりません。
Transaction processing in TCP raises some other protocol issues, which are discussed in the functional specification memo [TTCP-FS]. These include:
TCPのトランザクション処理はある他のプロトコル問題を提起します。(機能的な仕様メモ[TTCP-FS]で問題について議論します)。 これらは:
(1) augmenting the user interface for transactions,
(1) トランザクションのためにユーザーインタフェースを増大させること。
(2) delaying acknowledgment segments to allow maximum piggy-backing
of control bits with data,
(2) データがあるコントロールビットの最大の便乗を許容するために確認応答セグメントを遅らせること。
(3) measuring the retransmission timeout time (RTO) on very short
connections, and
そして(3) 非常に背の低い接続の再送タイムアウト時間(RTO)を測定する。
(4) providing an initial server window.
(4) 初期のサーバウィンドウを提供すること。
A recently proposed set of enhancements [RFC-1323] defines a TCP Timestamps option that carries two 32-bit timestamp values. The Timestamps option is used to accurately measure round-trip time (RTT). The same option is also used in a procedure known as "PAWS" (Protect Againsts Wrapped Sequence) to prevent erroneous data delivery due to a combination of old duplicate segments and sequence number reuse at very high bandwidths. The particular approach to transactions chosen in this memo does not require the RFC-1323 enhancements; however, they are important and should be implemented in every TCP, with or without the transaction extensions described here.
最近提案されたセットの増進[RFC-1323]は2つの32ビットのタイムスタンプ値を運ぶTCP Timestampsオプションを定義します。 Timestampsオプションは、正確に、往復の時間(RTT)を測定するのに使用されます。 包装されて、Againstsを保護してください。また、同じオプションが「足」として知られている手順で使用される、(系列) 老人の組み合わせによる誤ったデータ配送を防ぐには、まさしくその高帯域にセグメントと一連番号再利用をコピーしてください。 このメモで選ばれたトランザクションへの特定のアプローチはRFC-1323増進を必要としません。 しかしながら、それらは、重要であり、ここで説明されたトランザクション拡大のあるなしにかかわらずあらゆるTCPで実装されるべきです。
3. BYPASSING THE 3-WAY HANDSHAKE
3. 3ウェイ握手を迂回させます。
To avoid 3-way handshakes for transactions, we introduce a new mechanism for validating initial SYN segments, i.e., for enforcing at-most-once semantics without a 3-way handshake. We refer to this as the TCP Accelerated Open, or TAO, mechanism.
取引のための3ウェイ握手を避けるために、私たちは初期のSYNセグメントを有効にするために新しいメカニズムを紹介します、すなわち、実施のために大部分、一度、3ウェイ握手のない意味論。 私たちはTCP Acceleratedオープン、またはTAO、メカニズムにこれについて言及します。
3.1 Concept of TAO
3.1 TAOの概念
The basis of TAO is this: a TCP uses cached per-host information
to immediately validate new SYNs [Clark89]. If this validation
fails, e.g., because there is no current cached state or the
segment is an old duplicate, the procedure falls back to a normal
3-way handshake to validate the SYN. Thus, bypassing a 3-way
handshake is considered to be an optional optimization.
TAOの基礎はこれです: TCPは、すぐに新しいSYNs[Clark89]を有効にするのに1ホストあたりのキャッシュされた情報を使用します。 例えば、どんな現在のキャッシュされた状態もないのでこの合法化が失敗するか、セグメントが古い写しであるなら、手順は、SYNを有効にするために通常の3ウェイ握手へ後ろへ下がります。 したがって、3ウェイ握手を迂回させるのは任意の最適化であると考えられます。
Braden [Page 6] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[6ページ]RFC1379取引TCP--概念1992年11月
The proposed TAO mechanism uses a finite sequence-like space of
values that increase monotonically with successive transactions
(connections) between a given (client, server) host pair. Call
this monotonic space M, and let each initial SYN segment carry an
M value SEG.M. If M is not the existing sequence (SEG.SEQ) field,
SEG.M may be carried in a TCP option.
提案されたTAOメカニズムは与えられた(クライアント、サーバ)ホスト組の間には、連続した取引(接続)がある状態で単調に増加する値の有限系列のようなスペースを使用します。 Mにこの単調なスペースに電話をしてください、そして、それぞれの初期のSYNセグメントにM値のSEG.M. Ifを運ばせてください。Mが既存の系列(SEG.SEQ)分野でない、SEG.MはTCPオプションで運ばれてもよいです。
When host B receives from host A an initial SYN segment containing
a new value SEG.M, host B compares this against cache.M[A], the
latest M value that B has cached for host A. This comparison is
the "TAO test". Because the M values are monotonically
increasing, SEG.M > cache.M[A] implies that the SYN must be new
and can be accepted immediately. If not, a normal 3-way handshake
is performed to validate the initial SYN segment. Figure 2
illustrates the TAO mechanism; cached M values are shown enclosed
in square brackets. The M values generated by host A satisfy
x0 < x1, and the M values generated by host B satisfy y0 < y1.
ホストBがホストAから新しい値のSEG.Mを含む初期のSYNセグメントを受けるとき、ホストBはcache.M[A]に対してこれを比較して、ホストA.のためにキャッシュされて、最新のMは、Bがそうしたのを評価します。This比較は「TAOテスト」です。 値が単調に増加させているM、SEG.M>cache.M[A]が、SYNがそうしなければならないのを含意するので、新しく、すぐに、受け入れることができます。 そうでなければ、通常の3ウェイ握手は、初期のSYNセグメントを有効にするために実行されます。 図2はTAOメカニズムを例証します。 角括弧で同封されていた状態で値が示されるMをキャッシュしました。 ホストAで発生している値がx0<x1を満たすM、および値がホストBで発生させたMはy0<y1を満たします。
An appropriate choice for the M value space is discussed in
Section 5. M values are drawn from a finite number space, so
inequalities must be defined in the usual way for sequence numbers
[STD-007]. The M space must not wrap so quickly that an old
duplicate SYN will be erroneously accepted. We assume that some
maximum segment lifetime (MSL) is enforced by the IP layer.
Mがスペースを評価するので、セクション5で適当な選択について議論します。 有限数スペースから得られるので、Mが、評価する不断のとおり一連番号[STD-007]のために不平等を定義しなければなりません。 スペースが誤って古い写しSYNを受け入れるほどすぐに包装してはいけないM。 私たちは、いつかの最大のセグメント寿命(MSL)がIP層によって励行されると思います。
____T_C_P__A_____ ____T_C_P__B_____
____ T_C_P__A_____ ____ T_C_P__B_____
cache.M[B] cache.M[A]
V V
cache.M[B] cache.M[A]V V
[ y0 ] [ x0 ]
[y0][x0]
1. --> <SYN,data1,M=x1> --> ( (x1 > x0) =>
data1 -> user_B;
cache.M[A]= x1)
1. --><SYN、data1、x1M=>-->。((x1>x0)は>data1->ユーザ_Bと等しいです; cache.M[A]=x1)
[ y0 ] [ x1 ]
2. <-- <SYN,ACK(data1),data2,M=y1> <--
[y0][x1]2。 <-- <SYN、ACK(data1)、data2、Mはy1><と等しいです--
(data2 -> user_A,
cache.M[B]= y1)
(data2->ユーザ、cache.M[B]=y1)
[ y1 ] [ x1 ]
... (etc.) ...
[y1][x1]… (など) ...
Figure 2. TAO: Three-Way Handshake is Bypassed
図2。 タオ: 3方法のHandshakeはBypassedです。
Braden [Page 7] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[7ページ]RFC1379取引TCP--概念1992年11月
Figure 2 shows the simplest case: each side has cached the latest
M value of the other, and the SEG.M value in the client's SYN
segment is greater than the value in the cache at the server host.
As a result, B can accept the client A's request data1 immediately
and pass it to the server application. B's reply data2 is shown
piggybacked on the <SYN,ACK> segment. As a result of this 2-way
exchange, the cached M values are updated at both sites; the
client side becomes relevant only if the client/server roles
reverse. Validation of the <SYN,ACK> segment at host A is
discussed later.
図2は最も簡単なケースを示しています: それぞれの側がMが評価するもう片方の最新のものをキャッシュして、サーバー・ホストでは、クライアントのSYNセグメントのSEG.M値はキャッシュにおける値より大きいです。 その結果、Bは、すぐに、クライアントAの要求data1を受け入れて、それをサーバ・アプリケーションに通過できます。 ビーズは<SYNで便乗して、回答data2が示されるACK>はセグメントです。 この2ウェイの結果、両方のサイトで交換、キャッシュをアップデートしますMが、評価する。 クライアント/サーバーの役割が逆になる場合にだけ、クライアント側は関連するようになります。 後で<SYNの合法化、ホストAにおけるACK>セグメントについて議論します。
Figure 3 shows the TAO test failing but the consequent 3-way
handshake succeeding. B updates its cache with the value x2 >= x1
when the initial SYN is known to be valid.
TAOテストが失敗するのを示しますが、図3は、結果の3ウェイ握手が成功するのを示します。 初期のSYNが有効であることが知られていると、Bは値のx2>=x1でキャッシュをアップデートします。
_T_C_P__A _T_C_P__B
___T_C_Pは_T_C_P__Bです。
cache.M[B] cache.M[A]
V V
cache.M[B] cache.M[A]V V
[ y0 ] [ x0 ]
1. --> <SYN,data1,M=x1> --> ( (x1 <= x0) =>
data1 queued;
3-way handshake)
[y0][x0]1。 --><SYN、data1、x1M=>-->。((x1<=x0)はdata1が列に並ばせた>と等しいです; 3ウェイ握手)
[ y0 ] [ x0 ]
2. <-- <SYN,ACK(SYN),M=y1> <--
(cache.M[B]= y1)
[y0][x0]2。 <-- <SYN、ACK(SYN)、Mはy1><と等しいです--(cache.M[B]=y1)
[ y1 ] [ x0 ]
3. --> <ACK(SYN),M=x2> --> (Handshake OK =>
data1->user_B,
cache.M[A]= x2)
[y1][x0]3。 --><ACK(SYN)、M=x2>-->。(>data1Handshake OK=>ユーザ_B、cache.M[A]=x2)
[ y1 ] [ x2 ]
... (etc.) ...
[y1][x2]… (など) ...
Figure 3. TAO Test Fails but 3-Way Handshake Succeeds.
図3。 TAOテストは失敗しますが、3ウェイ握手は成功します。
There are several possible causes for a TAO test failure on a
legitimate new SYN segment (not an old duplicate).
正統の新しいSYNセグメント(古い写しでない)に関するTAOテストの故障のいくつかの考えられる原因があります。
(1) There may be no cached M value for this particular client
host.
(1) この特定のクライアントのための値が接待するMはキャッシュされないかもしれません。
(2) The SYN may be the one of a set of nearly-simultaneous SYNs
for different connections but from the same host, which
(2) 異なった接続のためのほとんど同時のSYNsの1セットの1つですが、SYNが同じホストからのそうであるかもしれない、どれ
Braden [Page 8] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[8ページ]RFC1379取引TCP--概念1992年11月
arrived out of order.
故障していた状態で、到着しました。
(3) The finite M space may have wrapped around between successive
transactions from the same client.
(3) スペースが同じくらいからの連続した取引の間でクライアントを巻きつけたかもしれない有限M。
(4) The M values may advance too slowly for closely-spaced
transactions.
(4) 値があまりにゆっくり進むかもしれないMは密接に取引を区切りました。
None of these TAO failures will cause a lockout, because the
resulting 3-way handshake will succeed. Note that the first
transaction between a given host pair will always require a 3-way
handshake; subsequent transactions can take advantage of TAO.
結果として起こる3ウェイ握手が成功するので、これらのTAOの故障のいずれもロックアウトを引き起こさないでしょう。 与えられたホスト組の間の最初の取引がいつも3ウェイ握手を必要とすることに注意してください。 その後の取引はTAOを利用できます。
The per-host cache required by TAO is highly desirable for other
reasons, e.g., to retain the measured round trip time and MTU for
a given remote host. Furthermore, a host should already have a
per-host routing cache [HR-COMM] that should be easily extensible
for this purpose.
TAOによって必要とされた1ホストあたりのキャッシュは、他の理由で例えば与えられたリモートホストのための測定周遊旅行時間とMTUを保有するために非常に望ましいです。 その上、ホストには、1ホストあたり1つの容易にこのために広げることができるべきルーティングキャッシュ[HR-COMM]が既にあるべきです。
Figure 4 illustrates a complete TCP transaction sequence using the
TAO mechanism. Bypassing the 3-way handshake leads to new
connection states; Figure 4 shows three of them, "SYN-SENT*",
"CLOSE-WAIT*", and "LAST-ACK*". Explanation of these states is
deferred to Section 6.
図4は、TAOメカニズムを使用することで完全なTCP取引系列を例証します。 3ウェイ握手を迂回させるのは新しい接続州に通じます。 それらの3つを示していて、「*をSYN送る」という図4、「厳密な待ち*」、および「最後のACK*。」 これらの州に関する説明はセクション6に延期されます。
TCP A (Client) TCP B (Server)
_______________ ______________
TCPは(クライアント)TCP B(サーバ)です。_______________ ______________
CLOSED LISTEN
閉じられて、聴いてください。
1. SYN-SENT* --> <SYN,data1,FIN,M=x1> --> CLOSE-WAIT*
(TAO test OK=>
data1->user_B)
1. SYNによって送られた*(><SYN、x1data1、フィン、M=>)>厳密な待ち*(TAOテストOK=>data1>ユーザ_B)
<-- <SYN,ACK(FIN),data2,FIN,M=y1> <-- LAST-ACK*
2. TIME-WAIT
(data2->user_A)
<--<SYN、ACK(フィン)、data2、フィン、Mはy1><と等しいです--最後のACK*2。 時間待ち(data2->、ユーザ、)
3. TIME-WAIT --> <ACK(FIN),M=x2> --> CLOSED
3. 時間待ち--><ACK(フィン)、Mはx2>と等しいです-->は閉じました。
(timeout)
CLOSED
(タイムアウト)は閉じました。
Figure 4: Minimal Transaction Sequence Using TAO
図4: TAOを使用する最小量の取引系列
Braden [Page 9] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[9ページ]RFC1379取引TCP--概念1992年11月
3.2 Cache Initialization
3.2 キャッシュ初期設定
The first connection between hosts A and B will find no cached
state at one or both ends, so both M caches must be initialized.
This requires that the first transaction carry a specially marked
SEG.M value, which we call SEG.M.NEW. Receiving a SEG.M.NEW value
in an initial SYN segment, B will cache this value and send its
own M back to initialize A's cache. When a host crashes and
restarts, all its cached M values cache.M[*] must be invalidated
in order to force a re-synchronization of the caches at both ends.
ホストAとBの間の最初の接続が1か両端でキャッシュされた状態に全く当たらないので、Mがキャッシュする両方を初期化しなければなりません。 これは、最初の取引が特に著しいSEG.M値を運ぶのを必要とします。(私たちは値をSEG.M. NEWと呼びます)。 初期のSYNセグメントでSEG.M. NEW値を受けて、Bは、Aのキャッシュを初期化するためにこの値をキャッシュして、それ自身のMを返送するでしょう。 aであるときに、ホストは、クラッシュして、再開して、すべてのキャッシュされたM値がcache.Mです。両端でキャッシュの再同期を強制するために[*]を無効にしなければなりません。
This cache synchronization procedure is illustrated in Figure 5,
where client host A has crashed and restarted with its cache
entries undefined, as indicated by "??". Since cache.TS[B] is
undefined, A sends a SEG.M.NEW value instead of SEG.M in the <SYN>
segment of its first transaction request to B. Receiving this
SEG.M.NEW, the server host B invalidates cache.TS[A] and performs
a 3-way handshake. SEG.M in segment #2 updates A's cache, and
when the handshake completes successfully, B updates its cached M
value to x2 >= x1.
このキャッシュ同期手順は、クライアントホストAがクラッシュした図5で例証されて、キャッシュエントリーが未定義の状態で再開されます、“??"によって示されるように. cache.TS[B]が未定義であるので、AがB.Receivingへの最初のトランザクション要求の<SYN>セグメントのSEG.Mの代わりにSEG.M. NEW値にこのSEG.M. NEWを送って、サーバー・ホストBは、cache.TS[A]を無効にして、3ウェイ握手を実行します。 SEG.Mはセグメント#2でAのキャッシュ、およびいつをアップデートするか。握手が首尾よく完成する、Bはx2>=x1にキャッシュされたM値をアップデートします。
_T_C_P__A _T_C_P__B
___T_C_Pは_T_C_P__Bです。
cache.M[B] cache.M[A]
V V
[ ?? ] [ x0 ]
cache.M[B] cache.M[A]V V、[]? [x0]
1. --> <SYN,data1,M.NEW=x1> --> (invalidate cache;
queue data1;
[ ?? ] 3-way handshake)
1. --><SYN、data1、M.新しい=x1>-->。(キャッシュを無効にしてください; data1を列に並ばせてください;、[]?、3ウェイ握手)
[ ?? ]
2. <-- <SYN,ACK(SYN),M=y1> <--
(cache.M[B]= y1)
[ ?? ] 2. <-- <SYN、ACK(SYN)、Mはy1><と等しいです--(cache.M[B]=y1)
[ y1 ] [ ?? ]
[y1][ ?? ]
3. --> <ACK(SYN),M=x2> --> data1->user_B,
cache.M[A]= x2)
3. --><ACK(SYN)、Mはx2>と等しいです-->data1>ユーザ_B、cache.M[A]がx2と等しい、)
[ y1 ] [ x2 ]
... (etc.) ...
[y1][x2]… (など) ...
Figure 5. Client Host Crashed
図5。 クライアントホストはクラッシュしました。
Suppose that the 3-way handshake failed, presumably because
おそらく、3ウェイ握手が失敗したと仮定してください。
Braden [Page 10] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[10ページ]RFC1379取引TCP--概念1992年11月
segment #1 was an old duplicate. Then segment #3 from host A
would be an RST segment, with the result that both side's caches
would be left undefined.
セグメント#1は古い写しでした。 そして、その結果、RSTセグメント、側のキャッシュが残される両方が未定義であるなら、ホストAからのセグメント#3はそうするでしょうに。
Figure 6 shows the procedure when the server crashes and restarts.
Upon receiving a <SYN> segment from a host for which it has no
cached M value, B initiates a 3-way handshake to validate the
request and sends its own M value to A. Again the result is to
update cached M values on both sides.
図6はサーバがいつクラッシュして、再開するかを手順に示します。 それがキャッシュされたM値を全く持っていないホストから<SYN>セグメントを受けると、Bは、両側で要求を有効にするために3ウェイ握手を開始して、A.Againへの結果がアップデートすることになっているそれ自身のM値にキャッシュされたM値を送ります。
_T_C_P__A _T_C_P__B
___T_C_Pは_T_C_P__Bです。
cache.M[B] cache.M[A]
V V
[ y0 ] [ ?? ]
cache.M[B] cache.M[A]V V[y0][ ?? ]
1. --> <SYN,data1,M=x1> --> (data1 queued;
3-way handshake)
1. --><SYN、data1、x1M=>-->。(data1は列を作りました; 3ウェイ握手)
[ y0 ] [ ?? ]
2. <-- <SYN,ACK(SYN),M=y1> <--
(cache.M[B]= y1)
[y0]、[]? 2. <-- <SYN、ACK(SYN)、Mはy1><と等しいです--(cache.M[B]=y1)
[ y1 ] [ ?? ]
3. --> <ACK(SYN),M=x2> --> (data1->user_B,
cache.M[A]= x2)
[y1]、[]? 3. --><ACK(SYN)、M=x2>-->。(data1>ユーザ_B、cache.M[A]=x2)
[ y1 ] [ x2 ]
... (etc.) ...
[y1][x2]… (など) ...
Figure 6. Server Host Crashed
図6。 サーバー・ホストはクラッシュしました。
3.3 Accepting <SYN,ACK> Segments
3.3 <SYN、ACK>セグメントを受け入れること。
Transactions introduce a new hazard of erroneously accepting an
old duplicate <SYN,ACK> segment. To be acceptable, a <SYN,ACK>
segment must arrive in SYN-SENT state, and its ACK field must
acknowledge something that was sent. In current TCPs the
effective send window in SYN-SENT state is exactly one octet, and
an acceptable <SYN,ACK> must exactly ACK this one octet. The
clock-driven selection of Initial Sequence Number (ISN) makes an
erroneous acceptance exceedingly unlikely. An old duplicate SYN
could be accepted erroneously only if successive connection
attempts occurred more often than once every 4 microseconds, or if
the segment lifetime exceeded the 4 hour wraparound time for ISN
取引は誤って古い写し<SYN、ACK>セグメントを受け入れる新しい危険を導入します。 許容できます、<SYN、ACK>セグメントがSYN-SENT状態に到着しなければならなくて、ACK分野が何かを承認しなければならないということになるようにそれを送りました。 中では、有効な現在のTCPsは中のSYN-SENTがまさにある八重奏であると述べる窓、および許容できる<SYN、ちょうどACK>必須ACKにこの1つの八重奏を送ります。 Initial Sequence Number(ISN)の時計駆動の選択で、誤った承認はきわめてありそうもなくなります。 連続した接続試みが4マイクロセカンドあたりの一度よりしばしば単に起こったか、またはセグメント寿命がISNのために巻きつけて着るドレス時間4時間を超えているなら、誤って古い写しSYNを受け入れることができるでしょうに。
Braden [Page 11] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[11ページ]RFC1379取引TCP--概念1992年11月
selection.
選択。
However, when TCP is used for transactions, data sent with the
initial SYN increases the range of sequence numbers that have been
sent. This increases the danger of accepting an old duplicate
<SYN,ACK> segment, and the consequences are more serious. In the
example in Figure 7, segments 1-3 form a normal transaction
sequence, and segment 4 begins a new transaction (incarnation) for
the same connection. Segment #5 is a duplicate of segment #2 from
the preceding transaction. Although the new transaction has a
larger ISN, the previous ACK value 402 falls into the new range
[200,700) of sequence numbers that have been sent, so segment #5
could be erroneously accepted and passed to the client as the
response to the new request.
しかしながら、TCPが取引に使用されるとき、初期のSYNと共に送られたデータは送られた一連番号の範囲を増加させます。 これは古い写し<SYN、ACK>セグメントを受け入れるという危険を増加させます、そして、結果は、より重大です。 図7の例では、セグメント1-3は正常な取引系列を形成します、そして、セグメント4は同じ接続のために、新しい取引(肉体化)を始めます。 セグメント#5は前の取引からのセグメント#2の写しです。 新しい取引には、より大きいISNがありますが、前のACK値402が送られた新しい範囲[200,700)の一連番号になるので、新しい要求への応答としてセグメント#5を誤って認めて、クライアントに渡すことができました。
_T_C_P__A _T_C_P__B
___T_C_Pは_T_C_P__Bです。
CLOSED LISTEN
閉じられて、聴いてください。
1. --> <seq=100,SYN,data=300,FIN,M=x1> --> (TAO test OK)
1. --><seq=100、SYN、x1 300、フィン、データ=M=>-->。(TAOテストOK)
2. <-- <seq=800,ack=402,SYN,data=350,FIN,M=y1> <--
2. <-- 350、フィン、<seq=800、ack=402、SYN、データ=Mはy1><と等しいです--
3. TIME-WAIT --> <ACK(FIN)> --> CLOSED
(short timeout)
CLOSED
3. タイム誌-WAIT--><ACK(FIN)>-->CLOSED(短いタイムアウト)CLOSED
(New Request)
4. --> <seq=200,SYN,data=500,FIN,M=x2> --> ...
(新しい要求) 4。 --500、フィン、><seq=200、SYN、データ=Mはx2>と等しいです-->。
(Duplicate of segment #2)
5. <-- <seq=800,ack=402,SYN,data=300,FIN,M=y1> <--...
(Acceptable!!)
(セグメント#2の写し) 5。 <-- <seq=800、ack=402、SYN、y1>300、フィン、データ=M=<--… (許容できる!)
Figure 7: Old Duplicate <SYN,ACK> Causing Error
図7: 古い写し<SYN、誤りを引き起こすACK>。
Unfortunately, we cannot simply use TAO on the client side to
detect and reject old duplicate <SYN,ACK> segments. A TAO test at
the client might fail for a valid <SYN,ACK> segment, due to out-
of-order delivery, and this could result in permanent non-delivery
of a valid transaction reply.
残念ながら、私たちは、古い写し<SYN、ACK>セグメントを検出して、拒絶するのにクライアント側の上のTAOを絶対に使用できません。 クライアントでのTAOテストは有効な<SYNのために失敗するかもしれません、ACK>セグメント、注文配送の外のため、そして、これは有効な取引回答の永久的な非配送をもたらすかもしれません。
Instead, we include a second M value, an echo of the client's M
value from the initial <SYN> segment, in the <SYN,ACK> segment. A
代わりに、私たちは第2M値を入れます、初期の<SYN>セグメントからのクライアントMの価値のエコー、<SYNで、ACK>セグメント。 A
Braden [Page 12] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[12ページ]RFC1379取引TCP--概念1992年11月
specially-marked M value, SEG.M.ECHO, is used for this purpose.
The client knows the value it sent in the initial <SYN> and can
therefore positively validate the <SYN,ACK> using the echoed
value. This is illustrated in Figure 12, which is the same as
Figure 4 with the addition of the echoed value on the <SYN,ACK>
segment #2.
特に、Mが値、SEG.M. ECHOであるとマークして、このために使用されます。 クライアントは、それが初期の<SYN>で送った値を知って、したがって、明確に、<SYN(反響している値を使用するACK>)を有効にすることができます。 これは図12で例証されます、ACK>セグメント#2。(反響している価値の添加が<SYNにある状態で、図は図4と同じです)。
It should be noted that TCP allows a simultaneous open sequence in
which both sides send and receive an initial <SYN> (see Figure 8
of [STD-007]. In this case, the TAO test must be performed on
both sides to preserve the symmetry. See [TTCP-FS] for an
example.
TCPが両側が初期の<SYN>を送って、受ける同時の開いている系列を許容することに注意されるべきです。[STD-007]の図8を見てください。この場合、対称を保存するために両側にTAOテストを実行しなければなりません。(例に関して[TTCP-FS]を見てください。
4. SHORTENING TIME-WAIT STATE
4. 時間待ち状態を短くします。
Once a transaction has been initiated for a particular connection (pair of ports) between a given host pair, a new transaction for the same connection cannot take place for a time that is at least:
取引が与えられたホスト組の間の特定の接続(ポートの組)のためにいったん開始されると、同じ接続のための新しい取引は少なくとも時間、行われることができません:
RTT + SPT + TIME-WAIT_delay
RTT+SPT+時間待ち_遅れ
Since the client host can cycle among the 64512 available port numbers, an upper bound on the transaction rate between a particular host pair is:
クライアントホストが64512の有効なポートナンバーの中で自転車で行くことができるので、特定のホスト組の間の取引率に関する上限は以下の通りです。
[1] TRmax = 64512 /(RTT + TIME-WAIT_Delay)
[1] TRmax=64512/(RTT+時間待ち_遅れ)
in transactions per second (Tps), where we assumed SPT is negligible. We must reduce TIME-WAIT_Delay to support high-rate TCP transaction processing.
2番目の(Tps)あたりの取引では、私たちがどこでSPTを仮定したかは、取るにたらないです。 私たちは、高い率TCPトランザクション処理を支持するためにタイム誌WAIT_Delayを減少させなければなりません。
TIME-WAIT state performs two functions: (1) supporting the full- duplex reliable close of TCP, and (2) allowing old duplicate segments from an earlier connection incarnation to expire before they can cause an error (see Appendix to [RFC-1185]). The first function impacts the application model of a TCP connection, which we would not want to change. The second is part of the fundamental machinery of TCP reliable delivery; to safely truncate TIME-WAIT state, we must provide another means to exclude duplicate packets from earlier incarnations of the connection.
タイム誌-WAIT州は2つの機能を実行します: (1) 誤りを引き起こす場合がある([RFC-1185]へのAppendixを見てください)前に以前の接続肉体化からの古い写しセグメントが期限が切れる近くでTCP、および(2)で信頼できる完全なデュプレックスを支持します。 最初の機能はTCP接続のアプリケーションモデルに影響を与えます。(接続を変えたいと思わないでしょう)。 2番目はTCP信頼できる配信の基本的な機械の一部です。 タイム誌-WAIT状態に安全に先端を切らせるために、私たちは接続の以前の肉体化に写しパケットを入れないようにする別の手段を提供しなければなりません。
To minimize the delay in TIME-WAIT state while performing both functions, we propose to set the TIME-WAIT delay to:
両方の機能を実行している間、タイム誌-WAIT状態で遅れを最小にするために、私たちは、タイム誌-WAIT遅れに以下のことように設定するよう提案します。
[2] TIME-WAIT_Delay = max( K*RTO, U )
[2] タイム誌WAIT_Delay=は最大限にします。(K*RTO、U)
where U and K are constants and RTO is the dynamically-determined retransmission timeout, the measured RTT plus an allowance for the
RTOがUとKが定数であり、ダイナミックに断固とした再送タイムアウトと、測定RTTと小遣いであるところ
Braden [Page 13] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[13ページ]RFC1379取引TCP--概念1992年11月
RTT variance [Jacobson88]. We choose K large enough so that there is high probability of the close completing successfully if at all possible; K = 8 seems reasonable. This takes care of the first function of TIME-WAIT state.
RTT変化[Jacobson88]。 私たちが十分大きいKを選ぶので、できれば、近い完成の高い確率が首尾よくあります。 K=8は妥当に思えます。 これはタイム誌-WAIT状態の最初の関数の世話をします。
In a real implementation, there may be a minimum RTO value Tr, corresponding to the precision of RTO calculation. For example, in the popular BSD implementation of TCP, the minimum RTO is Tr = 0.5 second. Assuming K = 8 and U = 0, Eqns [1] and [2] impose an upper limit of TRmax = 16K Tps on the transaction rate of these implementations.
本当の実現には、RTO計算の精度に対応している、最小のRTO値のTrがあるかもしれません。 例えば、TCPのポピュラーなBSD実現では、最小のRTOは0.5Tr=秒です。 K=8とU=が0であると仮定して、Eqns[1]と[2]は16TRmax=KのTpsの上限をこれらの実現の取引率に課します。
It is possible to have many short connections only if RTO is very small, in which case the TIME-WAIT delay [2] reduces to U. To accelerate the close sequence, we need to reduce U below the MSL enforced by the IP layer, without introducing a hazard from old duplicate segments. For this purpose, we introduce another monotonic number sequence; call it X. X values are required to be monotonic between successive connection incarnations; depending upon the choice of the X space (see Section 5), X values may also increase during a connection. A value from the X space is to be carried in every segment, and a segment is rejected if it is received with an X value smaller than the largest X value received. This mechanism does not use a cache; the largest X value is maintained in the TCP connection control block (TCB) for each connection.
RTOが非常に小さい場合にだけ多くの背の低い接続があるのが、可能である、その場合、タイム誌-WAIT遅れ[2]はU.に減少します。Toは近い系列を加速して、私たちは、IP層によって実施されたMSLの下でUを減少させる必要があります、古い写しセグメントから危険を導入しないで。 このために、私たちは別の単調な数順を紹介します。 それをX.と呼んでください。X値が連続した接続肉体化の間で単調になるのに必要です。 Xスペース(セクション5を見る)の選択によって、また、X値は接続の間、増加するかもしれません。 Xスペースからの値があらゆるセグメントで運ぶことであり、X値が最も大きいX対価領収より小さい状態でそれを受け取るなら、セグメントを拒絶します。 このメカニズムはキャッシュを使用しません。 最も大きいX値は各接続のためにTCP接続制御ブロック(TCB)で維持されます。
The value of U depends upon the choice for the X space, discussed in the next section. If X is time-like, U can be set to twice the time granularity (i.e, twice the minimum "tick" time) of X. The TIME-WAIT delay will then ensure that current X values do not overlap the X values of earlier incarnations of the same connection. Another consequence of time-like X values is the possibility that an open but idle connection might allow the X value to wrap its sign bit, resulting in a lockup of the connection. To prevent this, a 24-day idle timer on each open connection could bypass the X check on the first segment following the idle period, for example. In practice, many implementations have keep-alive mechanisms that prevent such long idle periods [RFC-1323].
Uの値は次のセクションで議論したXスペースのために選択に依存します。 Xが時間のようであるなら、次に、X. タイム誌-WAIT遅れの粒状(i.e、最小の「カチカチする音」時間の2倍)が、現在のX値が同じ接続の以前の肉体化のX値を重ね合わせないのを確実にするとき、二度Uを設定できます。 時間のようなX値の別の結果は開いていますが、無駄な接続がX値に符号ビットを包装させるかもしれない可能性です、接続の留置所をもたらして。 これを防ぐために、例えば、活動していない期間に続いて、それぞれのオープンな接続での24日の使用されていないタイマは最初のセグメントのXチェックを迂回させるかもしれません。 実際には、実現にはある多くがそのような長い活動していない期間[RFC-1323]を防ぐメカニズムを生かします。
Referring back to Figure 4, our proposed transaction extension results in a minimum exchange of 3 packets. Segment #3, the final ACK segment, does not increase transaction latency, but in combination with the TIME-WAIT delay of K*RTO it ensures that the server side of the connection will be closed before a new transaction is issued for this same pair of ports. It also provides an RTT measurement for the server.
私たちの提案された取引拡大は3つのパケットの最小の交換をもたらして、図4を差し戻します。 セグメント#3(最終的なACKセグメント)は取引潜在を高めませんが、K*RTOのタイム誌-WAIT遅れと組み合わせて、それは、新しい取引がポートのこの同じ組のために発行される前に接続のサーバ側面が閉じられるのを確実にします。 また、それはサーバのためのRTT測定を提供します。
We may ask whether it would be possible to further reduce the TIME-
私たちは、タイム誌をさらに減少させるのが可能であるかどうか尋ねるかもしれません。
Braden [Page 14] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[14ページ]RFC1379取引TCP--概念1992年11月
WAIT delay. We might set K to zero; alternatively, we might allow the client TCP to start a new transaction request while the connection was still in TIME-WAIT state, with the new initial SYN acting as an implied acknowledgment of the previous FIN. Appendix A summarizes the issues raised by these alternatives, which we call "truncating" TIME-WAIT state, and suggests some possible solutions. Further study would be required, but these solutions appear to bend the theory and/or implementations of the TCP protocol farther than we wish to bend them.
WAITは延着します。 私たちはゼロにKを設定するかもしれません。 あるいはまた、接続がまだタイム誌-WAIT状態にあった間、私たちはクライアントTCPに新しいトランザクション要求を始めさせるかもしれません、新しい初期のSYNが前のFINの暗示している承認として機能して。 付録Aは、私たちがタイム誌-WAIT状態が「先端を切る」であると呼ぶこれらの代替手段で提起された問題をまとめて、いくつかの可能な解決策を示します。 これらの解決策は理論を曲げるように見えます、そして、さらなる研究が必要でしょうが、私たちより遠いTCPプロトコルの実現はそれらを曲げたがっています。
We therefore propose using formula [2] with K=8 and retaining the final ACK(FIN) transmission. To raise the transaction rate, therefore, we require small values of RTO and U.
したがって、私たちは、K=8がある公式[2]を使用して、最終的なACK(FIN)トランスミッションを保有するよう提案します。 したがって、取引率を上げるために、私たちはRTOとUの小さい値を必要とします。
5. CHOOSING A MONOTONIC SEQUENCE
5. 単調列を選びます。
For simplicity, we want the monotonic sequence X used for shortening TIME-WAIT state to be identical to the monotonic sequence M for bypassing the 3-way handshake. Calling the common space M, we will send an M value SEG.M in each TCP segment. Upon receipt of an initial SYN segment, SEG.M will be compared with a per-host cached value to authenticate the SYN without a 3-way handshake; this is the TAO mechanism. Upon receipt of a non-SYN segment, SEG.M will be compared with the current value in the connection control block and used to discard old duplicates.
簡単さのために、私たちは、3ウェイ握手を迂回させるのに単調列Mと同じになるようにタイム誌-WAIT状態を短くするのに単調列Xを使用して欲しいと思います。 共用面積をMと呼んで、私たちはそれぞれのTCPセグメントでM値のSEG.Mを送るつもりです。 初期のSYNセグメントを受け取り次第、SEG.Mは3ウェイ握手なしでSYNを認証するために1ホストあたり1つのキャッシュされた値と比較されるでしょう。 これはTAOメカニズムです。 非SYNセグメントを受け取り次第、SEG.Mは、接続制御ブロックの現行価値と比較されて、古い写しを捨てるのに使用されるでしょう。
Note that the situation with TIME-WAIT state differs from that of bypassing 3-way handshakes in two ways: (a) TIME-WAIT requires duplicate detection on every segment vs. only on SYN segments, and (b) TIME-WAIT applies to a single connection vs. being global across all connections. This section discusses possible choices for the common monotonic sequence.
タイム誌-WAIT状態がある状況が3ウェイ握手を2つの方法で迂回させるものと異なっていることに注意してください: (a) タイム誌-WAITはSYNセグメントだけであらゆるセグメントにおける写し検出を必要として、(b)タイム誌-WAITは単独結合対すべての接続の向こう側にグローバルに適用します。 このセクションは一般的な単調列のための可能な選択について論じます。
The SEG.M values must satisfy the following requirements.
SEG.M値は以下の要件を満たさなければなりません。
* The values must be monotonic; this requirement is defined more
precisely below.
* 値は単調であるに違いありません。 この要件は、より正確に以下で定義されます。
* Their granularity must be fine-grained enough to support a high
rate of transaction processing; the M clock must "tick" at least
once between successive transactions.
* それらの粒状はきめ細かに高い率のトランザクション処理を支持できるくらい粒状でなければなりません。 時計が連続した取引の間に少なくとも一度「カチカチと音を立てなければならない」M。
* Their range (wrap-around time) must be great enough to allow a
realistic MSL to be enforced by the network.
* それらの範囲(巻きつけて着るドレス時間)は現実的なMSLがネットワークによって実施されるのを許容するほど大きくなければなりません。
The TCP spec calls for an MSL of 120 secs. Since much of the Internet does not carefully enforce this limit, it would be safer to have an MSL at least an order of magnitude larger. We set as an
TCP仕様は120secsのMSLを求めます。 インターネットの大部分が慎重にこの限界を実施しないので、MSLを少なくとも1桁より大きくするのは、より安全でしょう。 私たちはセットしました。
Braden [Page 15] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[15ページ]RFC1379取引TCP--概念1992年11月
objective an MSL of at least 2000 seconds. If there were no TIME- WAIT delay, the ultimate limit on transaction rate would be set by speed-of-light delays in the network and by the latency of host operating systems. As the bottleneck problems with interfacing CPUs to gigabit LANs are solved, we can imagine transaction durations as short as 1 microsecond. Therefore, we set an ultimate performance goal of TRmax at least 10**6 Tps.
少なくとも2000年のMSLが後援する目的。 タイム誌WAIT遅れが全くなければ、取引率における究極の限界はネットワークの光速遅れとホスト・オペレーティング・システムの潜在によって設定されるでしょうに。ギガビットLANにCPUを連結する隘路の問題が解決されているとき、私たちは1マイクロセカンドと同じくらい急に取引持続時間を想像できます。 したがって、私たちはTRmax少なくとも10**6Tpsの究極の性能目標を設定します。
A particular connection between hosts A and B is identified by the
local and remote TCP "sockets", i.e., by the quadruplet: {A, B,
Port.A, Port.B}. Imagine that each host keeps a count CC of the
number of TCP connections it has initiated. We can use this CC
number to distinguish different incarnations of the same connection.
Then a particular SEG.M value may be labeled implicitly by 6
quantities: {A, B, Port.A, Port.B, CC, n}, where n is the byte offset
of that segment within the connection incarnation.
ホストAとBの間の特定の接続は地方の、そして、リモートなTCP「ソケット」によって特定されます、すなわち、四つ子で: A、B、Port.A、Port.B。 各ホストが、カウントがそれが開始したTCP接続の数のCCであることを保つと想像してください。 私たちは、同じ接続の異なった肉体化を区別するのにこのCC番号を使用できます。 次に、特定のSEG.M値は6つの量によってそれとなくラベルされるかもしれません: A、B、Port.A、Port.B、CC、n。(そこでは、nは接続肉体化の中のそのセグメントのバイトオフセットです)。
To bypass the 3-way handshake, we require thgt SEG.M values on successive SYN segments from a host A to a host B be monotone increasing. If CC' > CC, then we require that:
3ウェイ握手を迂回させるために、私たちはホストAからホストBまで連続したSYNセグメントのthgt SEG.M値を必要とします。単調増加になってください。 'CC'>CCであるなら、私たちが、以下のことが必要です。
SEG.M(A,B,Port.A,Port.B,CC',0) > SEG.M(A,B,Port.A,Port.B,CC,0)
'SEG.M、(A、B、Port.A、Port.BがCCする、'、0)>SEG.M(A、B、Port.A、Port.B、cc、0)
for any legal values of Port.A and Port.B.
Port.AとPort.Bのどんな法定価格のためにも。
To delete old duplicates (allowing TIME-WAIT state to be shortened), we require that SEG.M values be disjoint across different incarnations of the same connection. If CC' > CC then
古い写し(タイム誌-WAIT状態が短くされるのを許容する)を削除するために、私たちは、SEG.M値が同じ接続の異なった肉体化の向こう側にばらばらになることであることを必要とします。 'CC'>であるなら、その時をCCしてください。
SEG.M(A,B,Port.A,Port.B,CC',n') > SEG.M(A,B,Port.A,Port.B,CC,n),
'SEG.M(A、B、Port.A、Port.B、CC、'n')>SEG.M(A、B、Port.A、Port.B、cc、n)
for any non-negative integers n and n'.
'どんな非負の整数nとnも'。
We now consider four different choices for the common monotonic space: RFC-1323 timestamps, TCP sequence numbers, the connection count, and 64-bit TCP sequence numbers. The results are summarized in Table I.
私たちは現在、一般的な単調なスペースと4つの異なった選択を考えます: RFC-1323タイムスタンプ、TCP一連番号、接続カウント、および64ビットのTCP一連番号。 結果はTable Iにまとめられます。
5.1 Cached Timestamps
5.1 キャッシュされたタイムスタンプ
The PAWS mechanism [RFC-1323] uses TCP "timestamps" as
monotonically increasing integers in order to throw out old
duplicate segments within the same incarnation. Jacobson
suggested the cacheing of these timestamps for bypassing 3-way
handshakes [Jacobson90], i.e., that TCP timestamps be used for our
common monotonic space M. This idea is attractive since it would
allow the same timestamp options to be used for RTTM, PAWS, and
transactions.
PAWSメカニズム[RFC-1323]は同じ肉体化の中に古い写しセグメントを放り出すために整数を単調に増加させるとしてTCP「タイムスタンプ」を使用します。 ジェーコブソンは3ウェイ握手[Jacobson90]を迂回させるためのこれらのタイムスタンプのcacheingについて提案しました、同じタイムスタンプオプションがRTTM、PAWS、および取引に使用されるのを許容するでしょう、すなわち、したがって、TCPタイムスタンプが私たちの一般的な単調な宇宙M.This考えに使用されるのは、魅力的です。
Braden [Page 16] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[16ページ]RFC1379取引TCP--概念1992年11月
To obtain at-most-once service, the criterion for immediate
acceptance of a SYN must be that SEG.M is strictly greater than
the cached M value. That is, to be useful for bypassing 3-way
handshakes, the timestamp clock must tick at least once between
any two successive transactions between the same pair of hosts
(even if different ports are used). Hence, the timestamp clock
rate would determine TRmax, the maximum possible transaction rate.
得る、大部分、一度、サービス、SYNの即座の承認のための評価基準はSEG.MにキャッシュされたM値より厳密にすばらしいということであるに違いありません。 すなわち、3ウェイ握手を迂回させることの役に立つように、タイムスタンプ時計は同じ組のホストの間のどんな2つの連続した取引の間も少なくとも一度チェックしなければなりません(異なったポートが使用されていても)。 したがって、タイムスタンプクロックレートはTRmax、最大の可能な取引率を測定するでしょう。
Unfortunately, the timestamp clock frequency called for by RFC-
1323, in the range 1 sec to 1 ms, is much too slow for
transactions. The TCP timestamp period was chosen to be
comparable to the fundamental interval for computing and
scheduling retransmission timeouts; this is generally in the range
of 1 sec. to 1 ms., and in many operating systems, much closer to
1 second. Although it would be possible to increase the timestamp
clock frequency by several orders of magnitude, to do so would
make implementation more difficult, and on some systems
excessively expensive.
残念ながら、取引には、1msへの1秒の範囲でRFC1323によって求められたタイムスタンプクロック周波数は非常に遅過ぎます。 TCPタイムスタンプの期間は基本間隔に匹敵しているために再送タイムアウトを計算して、計画をするのに選ばれました。 これは一般に、1つの原稿への1秒の範囲、および多くのオペレーティングシステムであります、1秒にはるかに近いです。 タイムスタンプクロック周波数を数桁増加させるのが可能でしょうが、そうするのに、実現は、より難しく、いくつかのシステムの上で過度に高価になるでしょう。
The wraparound time for TCP timestamps, at least 24 days, causes
no problem for transactions.
TCPタイムスタンプのための巻きつけて着るドレス時間(少なくとも24日間)は取引のために問題を全く引き起こしません。
The PAWS mechanism uses TCP timestamps to protect against old
duplicate non-SYN segments from the same incarnation [RFC-1323].
It can also be used to protect against old duplicate data segments
from earlier incarnations (and therefore allow shortening of
TIME-WAIT state) if we can ensure that the timestamp clock ticks
at least once between the end of one incarnation and the beginning
of the next. This can be achieved by setting U = 2 seconds, i.e.,
to twice the maximum timestamp clock period. This value in
formula [2] leads to an upper bound TRmax = 32K Tps between a host
pair. However, as pointed out above, old duplicate SYN detection
using timestamps leads to a smaller transaction rate bound, 1 Tps,
which is unacceptable. In addition, the timestamp approach is
imperfect; it allows old ACK segments to enter the new connection
where they can cause a disconnect. This happens because old
duplicate ACKs that arrive during TIME-WAIT state generate new
ACKs with the current timestamp [RFC-1337].
PAWSメカニズムは、同じ肉体化[RFC-1323]から古い写し非SYNセグメントから守るのにTCPタイムスタンプを使用します。 また、私たちが、タイムスタンプ時計が1回の肉体化の終わりと次の始まりの間を少なくとも一度チェックするのを保証できるなら、以前の肉体化(したがって、タイム誌-WAIT状態を短くさせる)から古い重複データセグメントから守るのにそれを使用できます。 2U=秒すなわち、最大のタイムスタンプ時計の期間の2倍までセットすることによって、これを達成できます。 公式[2]のこの値はホスト組の間の上限TRmax=32K Tpsに通じます。 しかしながら、上で指摘されるように、タイムスタンプを使用する古い写しSYN検出が、より小さい取引レートバウンド、1Tpsに通じます。(Tpsは容認できません)。 さらに、タイムスタンプアプローチは不完全です。 それで、古いACKセグメントはそれらが分離を引き起こす場合があるところに新しい接続を入れることができます。 タイム誌-WAIT状態の間に到着する古い写しACKsが現在のタイムスタンプ[RFC-1337]で新しいACKsを発生させるので、これは起こります。
We therefore conclude that timestamps are not adequate as the
monotonic space M; see Table I. However, they may still be useful
to effectively extend some other monotonic number space, just as
they are used in PAWS to extend the TCP sequence number space.
This is discussed below.
したがって、私たちは、タイムスタンプが単調なスペースMとして適切でないと結論を下します。 Table I.を見てください。However、それらは事実上、ある他の単調な数のスペースを広げるためにまだ役に立っているかもしれません、ちょうどそれらがTCP一連番号スペースを広げるのにPAWSで使用されるように。 以下でこれについて議論します。
Braden [Page 17] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[17ページ]RFC1379取引TCP--概念1992年11月
5.2 Current TCP Sequence Numbers
5.2 現在のTCP一連番号
It is useful to understand why the existing 32-bit TCP sequence
numbers do not form an appropriate monotonic space for
transactions.
取引のために既存の32ビットのTCP一連番号がなぜ適切な単調なスペースを形成しないかを理解しているのは役に立ちます。
The sequence number sent in an initial SYN is called the Initial
Sequence Number or ISN. According to the TCP specification, an
ISN is to be selected using:
一連番号は、初期のSYNがInitial Sequence NumberかISNと呼ばれるのを送りました。 TCP仕様に従って、ISNによる選択された使用です:
[3] ISN = (R*T) mod 2**32
[3] ISNは(R*T)モッズ2**32と等しいです。
where T is the real time in seconds (from an arbitrary origin,
fixed when the system is started) and R is a constant, currently
250 KBps. These ISN values form a monotonic time sequence that
wraps in 4.55 hours = 16380 seconds and has a granularity of 4
usecs. For transaction rates up to roughly 250K Tps, the ISN
value calculated by formula [3] will be monotonic and could be
used for bypassing the 3-way handshake.
Tが秒(システムが始動されるとき修理された任意の起源からの)のリアルタイムであるところでは、現在、Rは定数、250KBpsです。 これらのISN値は4.55時間=で16380秒を包装して、4usecsの粒状を持っている単調な時間系列を形成します。 取引率の最大およそ250KのTpsにおいて、公式[3]によって計算されたISN値は、単調であり、3ウェイ握手を迂回させるのに使用できました。
However, TCP sequence numbers (alone) could not be used to shorten
TIME-WAIT state, because there are several ways that overlap of
the sequence space of successive incarnations can occur (as
described in Appendix to [RFC-1185]). One way is a "fast
connection", with a transfer rate greater than R; another is a
"long" connection, with a duration of approximately 4.55 hours.
TIME-WAIT delay is necessary to protect against these cases. With
the official delay of 240 seconds, formula [1] implies a upper
bound (as RTT -> 0) of TRmax = 268 Tps; with our target MSL of
2000 sec, TRmax = 32 Tps. These values are unacceptably low.
しかしながら、タイム誌-WAIT状態を短くするのにTCP一連番号だけを使用できませんでした、連続した肉体化の系列スペースのオーバラップが起こることができる(Appendixで[RFC-1185]に説明されるように)いくつかの方法があるので。 1つの方法がRよりすばらしい転送レートとの「速い接続」です。 別のものはおよそ4.55時間の持続時間との「長い」関係です。 タイム誌-WAIT遅れが、これらのケースから守るのに必要です。 240秒の公式の遅れで、公式[1]は、TRmaxの上限(RTT->0としての)が268Tpsと等しいのを含意します。 私たちの2000秒の目標MSLと共に、TRmaxは32Tpsと等しいです。 これらの値は容認できないほど低いです。
To improve this transaction rate, we could use TCP timestamps to
effectively extend the range of the TCP sequence numbers.
Timestamps would guard against sequence number wrap-around and
thereby allow us to increase R in [3] to exceed the maximum
possible transfer rate. Then sequence numbers for successive
incarnations could not overlap. Timestamps would also provide
safety with an MSL as large as 24 days. We could then set U = 0
in the TIME-WAIT delay calculation [2]. For example, R = 10**9
Bps leads to TRmax <= 10**9 Tps. See 2(b) in Table I. These
values would more than satisfy our objectives.
この取引率を改良するなら、私たちは、事実上、TCP一連番号の範囲を広げるのにTCPタイムスタンプを使用するかもしれません。 タイムスタンプは、一連番号巻きつけて着るドレスに用心して、その結果、私たちが最大の可能な転送レートを超えるために[3]でRを増加させるのを許容するでしょう。 そして、連続した肉体化のための一連番号は重なることができませんでした。 また、タイムスタンプは24日間と同じくらい大きいMSLを安全に提供するでしょう。 そして、私たちはタイム誌-WAIT遅れ計算[2]にU=0をはめ込むことができました。 例えば、10**9R=Bpsは10**9TRmax<=Tpsに通じます。 Table I.These値における2(b)が私たちの目的を満たすよりそうするのを確実にしてください。
We should make clear how this proposal, sequence numbers plus
timestamps, differs from the timestamps alone discussed (and
rejected) in the previous section. The difference lies in what is
cached and tested for TAO; the proposal here is to cache and test
BOTH the latest TCP sequence number and the latest TCP timestamp.
In effect, we are proposing to use timestamps to logically extend
私たちはこの提案(一連番号とタイムスタンプ)がどう単独でタイムスタンプと前項で議論していた状態で(そして、拒絶されます)異なっているかを明らかにするべきです。 TAOがないかどうかキャッシュされて、テストされることには違いがあります。 ここでの提案は、最新のTCP一連番号のBOTHと最新のTCPタイムスタンプをキャッシュして、テストすることです。 事実上、私たちは、論理的に広がるのにタイムスタンプを使用するよう提案しています。
Braden [Page 18] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[18ページ]RFC1379取引TCP--概念1992年11月
the sequence space to 64 bits. Another alternative, presented in
the next section, is to directly expand the TCP sequence space to
64 bits.
64ビットへの系列スペース。 次のセクションに提示された別の代替手段は直接TCP系列スペースを64ビットに広げることです。
Unfortunately, the proposed solution (TCP sequence numbers plus
timestamps) based on equation [3] would be difficult or impossible
to implement on many systems, which base their TCP implementation
upon a very low granularity software clock, typically O(1 sec).
To adapt the procedure to a system with a low granularity software
clock, suppose that we calculate the ISN as:
残念ながら、方程式[3]に基づく提案された解決策(TCP一連番号とタイムスタンプ)は、多くのシステムの上で実行するのが、難しいか、または不可能でしょう。システムは彼らのTCP実現を非常に低い粒状ソフトウェア時計、通常O(1秒)に基礎づけます。 低い粒状ソフトウェア時計で手順をシステムに適合させるには、私たちが以下としてISNについて計算すると仮定してください。
[4] ISN = ( R*Ts*floor(T/Ts) + q*CC) mod 2**32
[4] ISNは(R*t*床(T/t)+q*CC)モッズ2**32と等しいです。
where Ts is the time per tick of the software clock, CC is the
connection count, and q is a constant. That is, the ISN is
incremented by the constant R*Ts once every clock tick and by the
constant q for every new connection. We need to choose q to
obtain the required monotonicity.
CCは接続カウントです、そして、Tsがソフトウェアのカチカチする音あたり時間であるところでは、時間を計ってください、そして、qは定数です。 すなわち、ISNはすべての新しい接続のために一定のR*tによって一度あらゆる時計カチカチする音と定数q増加されます。 私たちは、必要な単調を得るためにqを選ぶ必要があります。
For monotonicity of the ISN's themselves, q=1 suffices. However,
monotonicity during the entire connection requires q = R*Ts. This
value of q can be deduced as follows. Let S(T, CC, n) be the
sequence number for byte offset n in a connection with number CC
at time T:
ISNの単調ために、自分たちであり、q=1は十分です。 しかしながら、全体の接続の間の単調はq=R*tを必要とします。 以下の通りqのこの値を推論できます。 時Tに数のCCとの関係におけるバイトオフセットnのためにS(T、CC、n)が一連番号であることをさせてください:
S(T, CC, n) = (R*Ts*floor(T/Ts) + q*CC + n) mod 2**32.
S(T、CC、n)は(R*t*床(T/t)+q*CC+n)モッズ2**32と等しいです。
For any T1 > T2, we require that: S(T2, CC+1, 0) - S(T1, CC, n) >
0 for all n. Since R is assumed to be an upper bound on the
transfer rate, we can write down:
どんなT1>T2に関してはも、私たちが、以下のことが必要です。 S(T2、CC+1、0)--すべてのnのためのS(T1、CC、n)>0。 Rが転送レートに関する上限であると思われるので、私たちは以下に書くことができます。
R > n/(T2 - T1), or T2/Ts - T1/Ts > n/(R*Ts)
R>n/(T2--T1)、またはT2/t、--、T1/t>n/(R*t)
Using the relationship: floor(x)-floor(y) > x-y-1 and a little
algebra leads to the conclusion that using q = R*Ts creates the
required monotonic number sequence. Therefore, we consider:
関係を使用します: 床(x)床(y)の>x-y-1と少しの代数がq=R*tを使用すると必要な単調な数順が作成されるという結論につながります。 したがって、私たちは考えます:
[5] ISN = R*Ts*(floor(T/Ts) + CC) mod 2**32
[5] ISNは*t*(床(T/t)+CC)モッズ風のR2**32と等しいです。
(which is the algorithm used for ISN selection by BSD TCP).
(ISN選択にBSD TCPによって使用されたアルゴリズムです。)
For error-free operation, the sequence numbers generated by [5]
must not wrap the sign bit in less than MSL seconds. Since CC
cannot increase faster than TRmax, the safe condition is:
エラーのない操作のために、[5]で発生する一連番号はMSL秒ほど符号ビットを包んではいけません。 CCがTRmaxより速く増加できないので、安全な状態は以下の通りです。
R* (1 + Ts*TRmax) * MSL < 2**31.
R*(1+t*TRmax)*MSL<2**31。
We are interested in the case: Ts*TRmax >> 1, so this relationship
私たちはケースに興味を持っています: したがって、t*TRmax>>1、この関係
Braden [Page 19] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[19ページ]RFC1379取引TCP--概念1992年11月
reduces to:
以下への減少
[6] R * Ts * TRmax * MSL < 2**31.
[6] R*t*TRmax*MSL<2**31。
This shows a direct trade-off among the maximum effective
bandwidth R, the maximum transaction rate TRmax, and the maximum
segment lifetime MSL. For reasonable limiting values of R, Ts,
and MSL, formula [6] leads to a very low value of TRmax. For
example, with MSL= 2000 secs, R=10**9 Bps, and Ts = 0.5 sec, TRmax
< 2*10**-3 Tps.
これは最大の有効な帯域幅R、最大の取引レートTRmax、および最大のセグメント生涯MSLのときにダイレクトトレードオフを示しています。 R、Ts、およびMSLの妥当な制限値のために、公式[6]はTRmaxの非常に低い値につながります。 例えば、MSL=と共に、2000secs、R=10**9Bps、およびTsが0.5秒、TRmax<2*10**-3Tpsと等しいです。
To ease the situation, we could supplement sequence numbers with
timestamps. This would allow an effective MSL of 2 seconds in
[6], since longer times would be protected by differing
timestamps. Then TRmax < 2**30/(R*Ts). The actual enforced MSL
would be increased to 24 days. Unfortunately, TRmax would still
be too small, since we want to support transfer rates up to R ~
10**9 Bps. Ts = 0.5 sec would imply TRmax ~ 2 Tps. On many
systems, it appears infeasible to decrease Ts enough to obtain an
acceptable TRmax using this approach.
状況を緩和するために、私たちはタイムスタンプで一連番号を補うことができました。 より長い回は異なったタイムスタンプによって保護されるでしょう、したがって、これが[6]に2秒の有効なMSLを許容するでしょう。 そして、TRmax<2**30/(R*t)。 実際の実施されたMSLは24日間まで増加するでしょう。 残念ながら、転送レートをR~10**9Bpsまで支持したいと思うので、TRmaxはまだ小さ過ぎるでしょう。 0.5t=秒はTRmax~2Tpsを含意するでしょう。 多くのシステムの上では、Tsをこのアプローチを使用することで許容できるTRmaxを入手できるくらい減少させるのは実行不可能に見えます。
5.3 64-bit TCP Sequence Numbers
5.3 64ビットのTCP一連番号
Another possibility would be to simply increase the TCP sequence
space to 64 bits as suggested in [RFC-1263]. We would also
increase the R value for clock-driven ISN selection, beyond the
fastest transfer rate of which the host is capable. A reasonable
upper limit might be R = 10**9 Bps. As noted above, in a
practical implementation we would use:
別の可能性は[RFC-1263]に示されるようにTCP系列スペースを単に64ビットまで増加させるだろうことです。 また、私たちは時計駆動のISN選択のためにR値を増加させるでしょう、ホストができる最も速い転送レートを超えて。 妥当な上限は10**9R=Bpsであるかもしれません。 上で述べたように、実用的な実現に、私たちは以下を使用するでしょう。
ISN = R*Ts*( floor(T/Ts) + CC) mod 2**64
ISNは*t*(床(T/t)+CC)モッズ風のR2**64と等しいです。
leading to:
通じます:
R*(1 + Ts * TRmax) * MSL < 2**63
R*(1+t*TRmax)*MSL<2**63
For example, suppose that R = 10**9 Bps, Ts = 0.5, and MSL = 16K
secs (4.4 hrs); then this result implies that TRmax < 10**6 Tps.
We see that adding 32 bits to the sequence space has provided
feasible values for transaction processing.
Tsは0.5と等しいです、そして、例えば、Rが10**9Bpsと等しいと仮定してください、そして、MSLは16Kのsecs(4.4時間)と等しいです。 そして、この結果はそのTRmax<10**6Tpsを含意します。 私たちは、系列スペースに32ビットを加えると可能な値がトランザクション処理に提供されたのを見ます。
5.4 Connection Counts
5.4 接続カウント
The Connection Count CC is well suited to be the monotonic
sequence M, since it "ticks" exactly once for each new connection
incarnation and is constant within a single incarnation. Thus, it
perfectly separates segments from different incarnations of the
same connection and would allow U = 0 in the TIME-WAIT state delay
Connection Count CCは単調列Mになるようによく合っています、それがそれぞれの新しい接続肉体化のためにまさにかつて「カチカチし」て、単一の肉体化の中で一定であるので。 したがって、それは、同じ接続の異なった肉体化とセグメントを完全に切り離して、タイム誌-WAIT州の遅れでU=0を許容するでしょう。
Braden [Page 20] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[20ページ]RFC1379取引TCP--概念1992年11月
formula [2]. (Strictly, U cannot be reduced below 1/R = 4 usec,
as noted in Section 4. However, this is of little practical
consequence until the ultimate limits on TRmax are approached).
公式[2]。 厳密に、Uは4 1/R=usecの下で減少できません、セクション4に述べられるように。(しかしながら、TRmaxにおける究極の限界がアプローチされるまで、これは小さい実用的な結果のものです。)
Assume that CC is a 32-bit number. To prevent wrap-around in the
sign bit of CC in less than MSL seconds requires that:
CCが32ビットの数であると仮定してください。 MSL秒以下でCCに関する符号ビットで巻きつけて着るドレスを防ぐのが、以下のことが必要です。
TRmax * MSL < 2**31
TRmax*MSL<2**31
For example, if MSL = 2000 seconds then TRmax < 10**6 Tp. These
are acceptable limits for transaction processing. However, if
they are not, we could augment CC with TCP timestamps to obtain
very far-out limits, as discussed below.
例えばMSL=2000秒の当時のTRmax<10**6Tpであるなら。 これらはトランザクション処理のための合格限界です。 しかしながら、それらがそうでないなら、私たちは、非常に型破りの限界を得るために以下で議論するようにTCPタイムスタンプでCCを増大させるかもしれません。
It would be an implementation choice at the client whether CC is
global for all destinations or private to each destination host
(and maintained in the per-host cache). In the latter case, the
last CC value assigned for each remote host could also be
maintained in the per-host cache. Since there is not typically a
large amount of parallelism in the network connection of a host,
there should be little difference in the performance of these two
different approaches, and the single global CC value is certainly
simpler.
CCがすべての目的地にグローバルであるか、または各あて先ホストにとって、個人的であること(そして、1ホストあたりのキャッシュで維持されます)にかかわらずそれはクライアントでの実現選択でしょう。 また、後者の場合では、1ホストあたりのキャッシュでそれぞれのリモートホストのために割り当てられた最後のCC値は維持できました。 ホストのネットワーク接続には多量の平行関係が通常でないあるので、これらの2つの異なるアプローチの性能に少しの違いがあるべきです、そして、確かに、ただ一つのグローバルなCC値は、より簡単です。
To augment CC with TCP timestamps, we would bypass a 3-way
handshake if both SEG.CC > cache.CC[A] and SEG.TSval >=
cache.TS[A]. The timestamp check would detect a SYN older than 2
seconds, so that the effective wrap-around requirement would be:
TCPタイムスタンプでCCを増大させるために、SEG.CC>cache.CC[A]とSEG.TSval>の両方がcache.TS[A]と等しいなら、私たちは3ウェイ握手を迂回させるでしょう。 タイムスタンプチェックは有効な巻きつけて着るドレス要件があるように、2秒より古いSYNを検出するでしょう:
TRmax * 2 < 2**31
TRmax*2<2**31
i.e., TRmax < 10**9 Tps. The required MSL would be raised to 24
days. Using timestamps in this way, we could reduce the size of
CC. For example, suppose CC were 16 bits. Then the wrap-around
condition TRmax * 2 < 2**15 implies that TRmax is 16K.
すなわち、TRmax<10**9Tps。 必要なMSLは24日間まで上げられるでしょう。 このようにタイムスタンプを使用して、私たちはCCのサイズを減少させることができました。 CCが例えば16ビットであるなら。 そして、巻きつけて着るドレス状態TRmax*2<2**15は、TRmaxが16Kであることを含意します。
Finally, note that using CC to delete old duplicates from earlier
incarnations would not obviate the need for the time-stamp-based
PAWS mechanism to prevent errors within a single incarnation due
to wrapping the 32-bit TCP sequence space at very high transfer
rates.
最終的に、以前の肉体化から古い写しを削除するのにCCを使用するのが時間スタンプベースのPAWSメカニズムが非常に高い転送レートで32ビットのTCP系列スペースを包装するのによる単一の肉体化の中で誤りを防ぐ必要性を取り除かないことに注意してください。
5.5 Conclusions
5.5 結論
The alternatives for monotonic sequence are summarized in Table I.
We see that there are two feasible choices for the monotonic
space: the connection count and 64-bit sequence numbers. Of these
two, we believe that the simpler is the connection count.
単調列のための代替手段はTable I.にまとめられます。Weは、単調なスペースへの2つの可能な選択があるのがわかります: 接続カウントと64ビットの一連番号。 これらの2では、私たちは、接続カウントが、より簡単であると信じています。
Braden [Page 21] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[21ページ]RFC1379取引TCP--概念1992年11月
Implementation of 64-bit sequence numbers would require
negotiation of a new header format and expansion of all variables
and calculations on the sequence space. CC can be carried in an
option and need be examined only once per packet.
64ビットの一連番号の実現は系列スペースで新しいヘッダー形式の交渉とすべての変数と計算の拡大を必要とするでしょう。 CCは、オプションで運ぶことができて、パケット単位で一度だけ調べられなければなりません。
We propose to use a simple 32-bit connection count CC, without
augmentation with timestamps, for the transaction extension. This
choice has the advantages of simplicity and directness. Its
drawback is that it adds a third sequence-like space (in addition
to the TCP sequence number and the TCP timestamp) to each TCP
header and to the main line of packet processing. However, the
additional code is in fact very modest.
私たちは、取引拡大にタイムスタンプで増大なしで簡単な32ビットの接続カウントCCを使用するよう提案します。 この選択には、簡単さと率直さの利点があります。 欠点は3番目の系列のようなスペース(TCP一連番号とTCPタイムスタンプに加えた)をそれぞれのTCPヘッダーと、そして、パケット処理の本線に加えるということです。 しかしながら、事実上、追加コードは非常に穏やかです。
We now have a general outline of the proposed TCP extensions for transactions.
私たちには、現在、取引のための提案されたTCP拡張子に関する概要があります。
o A host maintains a 32-bit global connection counter variable CC.
o ホストは、32ビットのグローバルな接続カウンタが変化するCCであると主張します。
o The sender's current CC value is carried in an option in every
TCP segment.
o 送付者の現在のCC値はあらゆるTCPセグメントでオプションで運ばれます。
o CC values are cached per host, and the TAO mechanism is used to
bypass the 3-way handshake when possible.
o CC値はホスト単位でキャッシュされます、そして、TAOメカニズムは、可能であるときに、3ウェイ握手を迂回させるのに使用されます。
o In non-SYN segments, the CC value is used to reject duplicates
from earlier incarnations. This allows TIME-WAIT state delay to
be reduced to K*RTO (i.e., U=0 in Eq. [2]).
o 非SYNセグメントでは、CC値は、以前の肉体化からの写しを拒絶するのに使用されます。 これは、タイム誌-WAIT州の遅れがK*RTOに変えられるのを許容します。(すなわち、EqのU=0。 [2]).
Braden [Page 22] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[22ページ]RFC1379取引TCP--概念1992年11月
TABLE I: Summary of Monotonic Sequences
テーブルI: 単調列の概要
APPROACH TRmax (Tps) Required MSL COMMENTS
__________________________________________________________________
アプローチTRmax(Tps)はMSLコメントを必要としました。__________________________________________________________________
1. Timestamp & PAWS 1 24 days TRmax is
too small
__________________________________________________________________
1. タイムスタンプとPAWS1 24日間のTRmaxは小さ過ぎます。__________________________________________________________________
2. Current TCP Sequence Numbers
2. 現在のTCP一連番号
(a) clock-driven
ISN: eq. [3] 268 240 secs TRmax & MSL
too small
(a) 駆動ISNの時間を計ってください: eq。 [3]268 240秒TRmax&MSL、も小ささ
(b) Timestamps& clock-
driven ISN [3] & 10**9 24 days Hard to
R=10**9 implement
R=10**9へのタイムスタンプ、時計の駆動ISN[3]、および10**9の24日間のHardが実行する(b)
(c) Timestamps & c-dr
ISN: eq. [4] 2**30/(R*Ts) 24 days TRmax too
small.
__________________________________________________________________
(c) タイムスタンプとc-dr ISN: eq。 [4] 2**30/(R*t)の24日間のTRmax、も小さいです。 __________________________________________________________________
3. 64-bit TCP Sequence Numbers
3. 64ビットのTCP一連番号
2**63/(MSL*R*Ts) MSL Significant
TCP change
e.g., R=10**9 Bps,
MSL = 4.4 hrs,
Ts = 0.5 sec=>
TRmax = 10**6
__________________________________________________________________
2**>0.5Ts=秒例えば、R=10**9Bps、4.4MSL=時間の63/(MSL*R*t)MSL Significant TCP変化=TRmaxは10**6と等しいです。__________________________________________________________________
4. Connection Counts
4. 接続カウント
(a) no timestamps 2**31/MSL MSL 3rd sequence
e.g., MSL=2000 sec space
TRmax = 10**6
(a) タイムスタンプがない2**31/MSL MSL第3系列例えば、MSL=2000秒のスペースTRmaxは10**6と等しいです。
(b) with timestamps 2**30 24 days (ditto)
and PAWS
__________________________________________________________________
(b) タイムスタンプ2**の30 24日間(同様である)とPAWSと共に__________________________________________________________________
Braden [Page 23] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[23ページ]RFC1379取引TCP--概念1992年11月
6. CONNECTION STATES
6. 接続州
TCP has always allowed a connection to be half-closed. TAO makes a significant addition to TCP semantics by allowing a connection to be half-synchronized, i.e., to be open for data transfer in one direction before the other direction has been opened. Thus, the passive end of a connection (which receives an initial SYN) can accept data and even a FIN bit before its own SYN has been acknowledged. This SYN, data, and FIN may arrive on a single segment (as in Figure 4), or on multiple segments; packetization makes no difference to the logic of the finite-state machine (FSM) defining transitions among connection states.
TCPは、いつも接続が半開きであることを許容しました。 TAOは接続が半分連動されているのを許容することによって、TCP意味論への重要な追加をします、すなわち、以前一方向へのデータ転送において開くように、もう片方の指示が開かれました。 したがって、接続(初期のSYNを受ける)の受け身の終わりはデータとそれ自身のSYNが承認される前に噛み付かれたFINさえ受け入れることができます。 このSYN、データ、およびFINはただ一つのセグメント(図4のように)の上、または、複数のセグメントの上で到着するかもしれません。 packetizationは、接続州の中で変遷を定義しながら、有限状態機械(FSM)の論理に重要ではありません。
Half-synchronized connections have several consequences.
半分連動している接続には、いくつかの結果があります。
(a) The passive end must provide an implied initial data window in
order to accept data. The minimum size of this implied window
is a parameter in the specification; we suggest 4K bytes.
(a) 受け身の終わりは、データを受け入れるために暗示している初期のデータウィンドウを提供しなければなりません。 仕様でこの暗示している窓の最小規模はパラメタです。 私たちは4Kのバイトを勧めます。
(b) New connection states and transitions are introduced into the
TCP FSM at both ends of the connection. At the active end, new
states are required to piggy-back the FIN on the initial SYN
segment. At the passive end, new states are required for a
half-synchronized connection.
(b) 新しい接続州と変遷は接続の両端のTCP FSMに紹介されます。 アクティブな終わりに、新しい州は初期のSYNセグメントのFINを子豚で支持しなければなりません。 受け身の終わりに、新しい州が半分連動している接続に必要です。
This section develops the resulting FSM description of a TCP connection as a conventional state/transition diagram. To develop a complete FSM, we take a constructive approach, as follows: (1) write down all possible events; (2) write down the precedence rules that govern the order in which events may occur; (3) construct the resulting FSM; and (4) augment it to support TAO. In principle, we do this separately for the active and passive ends; however, the symmetry of TCP results in the two FSMs being almost entirely coincident.
このセクションは従来の状態/変遷ダイヤグラムとしてTCP接続の結果として起こるFSM記述を開発します。 完全なFSMを開発するために、私たちは以下の通り建設的なアプローチを取ります: (1) すべての可能な出来事を書き留めてください。 (2) 出来事が起こるかもしれないオーダーを支配する先行規則を書き留めてください。 (3) 結果として起こるFSMを組み立ててください。 (4) そして、それを増大させて、TAOを支持してください。 原則として、私たちはアクティブで受け身の終わりに別々にこれをします。 しかしながら、TCPの対称はほぼ完全にコインシデンスである2FSMsをもたらします。
Figure 8 lists all possible state transitions for a TCP connection in the absence of TAO, as elementary events and corresponding actions. Each transition is labeled with a letter. Transitions a-g are used by the active side, and c-i are used by the passive side. Without TAO, transition "c" (event "rcv ACK(SYN)") synchronizes the connection, allowing data to be accepted for the user.
エイト環はTAOが不在のときTCP接続のためにすべての可能な状態遷移を記載します、根元事象と対応する動作として。 各変遷は手紙でラベルされます。 変遷a-gはアクティブ側によって使用されます、そして、c-iは受け身側によって使用されます。 TAOがなければ、データがユーザのために受け入れられるのを許容して、変遷「c」(イベント「rcv ACK(SYN)」)は接続を同時にさせます。
By definition, the first transition for an active (or passive) side
must be "a" (or "i", respectively). During a single instance of a
connection, the active side will progress through some permutation of
the complete sequence of transitions {a b c d e f } or the sequence
{a b c d e f g}. The set of possible permutations is determined by
precedence rules governing the order in which transitions can occur.
定義上、アクティブで(受動)の側のための前縁が“a"であるに違いない、(または、「i」、それぞれ) 接続のただ一つの例の間、アクティブ側は変遷の完全な配列の何らかの順列でb c d e fか系列をb c d e f gで進行するでしょう。 可能な順列のセットは変遷が起こることができるオーダーを支配する先行規則で決定します。
Braden [Page 24] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[24ページ]RFC1379取引TCP--概念1992年11月
Label Event / Action
_____ ________________________
a OPEN / snd SYN
ラベル出来事/動作_____ ________________________ オープン/snd SYN
b rcv SYN [No TAO]/ snd ACK(SYN)
b rcv SYN[TAOがない]/snd ACK(syn)
c rcv ACK(SYN) /
c rcv ACK(SYN)/
d CLOSE / snd FIN
d CLOSE / snd FIN
e rcv FIN / snd ACK(FIN)
e rcv FIN / snd ACK(フィン)
f rcv ACK(FIN) /
f rcv ACK(FIN)/
g timeout=2MSL / delete TCB
___________________________________________________
h passive OPEN / create TCB
gタイムアウト=2MSL/はTCBを削除します。___________________________________________________ h受け身のオープン/はTCBを作成します。
i rcv SYN [No TAO]/ snd SYN, ACK(SYN)
___________________________________________________
i rcv SYN[TAOがない]/snd SYN、ACK(SYN)___________________________________________________
Figure 8. Basic TCP Connection Transitions
エイト環。 基本的なTCP接続変遷
Using the notation "<." to mean "must precede", the precedence rules are:
使用、記法"<" 「必須は先行します」と意味するために、先行規則は以下の通りです。
(1) Logical ordering: must open connection before closing it:
(1)の論理的な注文: それを閉じる前の必須のオープンな接続:
b <. e
b<e
(2) Causality -- cannot receive ACK(x) before x has been sent:
(2)因果関係--xを送る前にACK(x)を受けることができません:
a <. c and i <. c and d <. f
a<c、i<c、およびd<f
(3) Acknowledgments are cumulative
(3) 承認は累積しています。
c <. f
c<f
(4) First packet in each direction must contain a SYN.
(4) 各方向への最初のパケットはSYNを含まなければなりません。
b <. c and b <. f
b<b<cとf
(5) TIME-WAIT state
(5) タイム誌-WAIT状態
Whenever d precedes e in the sequence, g must be the last
transition.
dが系列のeに先行するときはいつも、gは立下り区間であるに違いありません。
Braden [Page 25] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[25ページ]RFC1379取引TCP--概念1992年11月
Applying these rules, we can enumerate all possible permutations of the events and summarize them in a state transition diagram. Figure 9 shows the result, with boxes representing the states and directed arcs representing the transitions.
これらの規則を適用して、私たちは、出来事のすべての可能な順列を列挙して、状態遷移ダイヤグラムでそれらをまとめることができます。 箱が州を代表していて、指示されたアークが変遷を表していて、図9は結果を示しています。
________ ________
| | h | |
| CLOSED |--------->| LISTEN |
|________| |________|
| |
| a | i
____V____ ____V___ ________
| | b | | e | |
| |--------->| |-------------->| |
|________| |________| |________|
/ / | / |
/ / | c d / | c
/ / __V_____ | ____V___
/ / | | e | | |
d | d / | |------------>| |
| | |________| | |________|
| | | | |
| | | ___V____ |
| | | | | |
| | | | | |
| | | |________| |
| | | | |
____V___ ______V_ | ________ | |
| | b | | e | | | | |
| |------->| |--------->| | | |
|________| |________| | |________| | |
| / | | |
c | / d c | c | d |
| / | | |
_V___V__ ____V___ V_____V_
| | e | | | |
| |---->| | | |
|________| |________| |________|
| | |
| f | f | f
____V___ ____V___ ___V____
| | e | TIME- | g | |
| |---->| WAIT |-->| CLOSED |
|________| |________| |________|
________ ________ | | h| | | 閉じられます。|、-、-、-、-、-、-、-、--、>| 聴いてください。| |________| |________| | | | a| i____V____ ____V___ ________ | | b| | e| | | |、-、-、-、-、-、-、-、--、>| |、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |________| |________| |________| / / | / | / / | c d/| c//______ | ____V___ / / | | e| | | d| d/| |、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |________| | |________| | | | | | | | | ___V____ | | | | | | | | | | | | | | | | |________| | | | | | | ____V___ ______V_| ________ | | | | b| | e| | | | | | |、-、-、-、-、-、--、>| |、-、-、-、-、-、-、-、--、>|、|、|、| |________| |________| | |________| | | | / | | | c| /d c| c| d| | / | | | _V___V______V___ V_____V_| | e| | | | | |、-、-、--、>|、|、|、| |________| |________| |________| | | | | f| f| f____V___ ____V___ ___V____ | | e| 時間| g| | | |、-、-、--、>| 待ち| -->、| 閉じられます。| |________| |________| |________|
Figure 9: Basic State Diagram
図9: 基本的な州のダイヤグラム
Braden [Page 26] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[26ページ]RFC1379取引TCP--概念1992年11月
Although Figure 9 gives a correct representation of the possible event sequences, it is not quite correct for the actions, which do not compose as shown. In particular, once a control bit X has been sent, it must continue to be sent until ACK(X) is received. This requires new transitions with modified actions, shown in the following list. We use the labeling convention that transitions with the same event part all have the same letter, with different numbers of primes to indicate different actions.
図9は可能なイベント系列の正しい表現を与えますが、動作には、それは全く正しいというわけではありません。(動作は示されるように構成されません)。 いったんコントロールビットXを送ると、特に、それは、ACK(X)が受け取られているまで送られ続けなければなりません。 これは以下のリストに示された変更された動作による新しい変遷を必要とします。 私たちはラベルしているコンベンションを使用します。同じイベント部分がある変遷にはすべて、異なった動作を示すために、同じ手紙が異なった数の盛りと共にあります。
Label Event / Action
_____ _______________________________________
b' (=i) rcv SYN [No TAO] / snd SYN,ACK(SYN)
b'' rcv SYN [No TAO] / snd SYN,FIN,ACK(SYN)
d' CLOSE / snd SYN,FIN
e' rcv FIN / snd FIN,ACK(FIN)
e'' rcv FIN / snd SYN,FIN,ACK(FIN)
ラベル出来事/動作_____ _______________________________________ '「b'(=i) rcv SYN[TAOがない]/snd SYN、ACK(SYN)b」rcv SYN[TAOがない]/snd SYN、FIN、ACK(SYN)d'CLOSE / snd SYN、FIN e'rcv FIN / snd FIN、ACK(FIN)e」rcv FIN / snd SYN、FIN、ACK(フィン)
Figure 10 shows the state diagram of Figure 9, with the modified transitions and with the states used by standard TCP [STD-007] identified. Those states that do not occur in standard TCP are numbered 1-5.
図9、変更された変遷、および州が特定された標準のTCP[STD-007]によって使用されている状態で、図10は州のダイヤグラムを示しています。 標準のTCPに起こらないそれらの州は1-5に付番されます。
Standard TCP has another implied restriction: a FIN bit cannot be recognized before the connection has been synchronized, i.e., c <. e. This eliminates from standard TCP the states 1, 2, and 5 shown in Figure 10. States 3 and 4 are needed if a FIN is to be piggy-backed on a SYN segment (note that the states shown in Figure 1 are actually wrong; the states shown as SYN-SENT and ESTABLISHED are really states 3 and 4). In the absence of piggybacking the FIN bit, Figure 10 reduces to the standard TCP state diagram [STD-007].
標準のTCPには、別の暗示している制限があります: . 接続が同時にする前にFINビットを認識できないで、すなわち、c<はeです。 これは標準のTCPから図10で見せられた州1、2、および5を排除します。 FINがSYNセグメント(図1で見せられた州が実際に間違っているというメモ; SYN-SENTとESTABLISHEDが本当に州3と4であるのに見せられた州)で背負われるつもりであるなら、州3と4が必要です。 FINビットを背負うことが不在のとき、図10は標準のTCP州のダイヤグラム[STD-007]に減少します。
The FSM described in Figure 10 is intended to be applied cumulatively; that is, parsing a single packet header may lead to more than one transition. For example, the standard TCP state diagram includes a direct transition from SYN-SENT to ESTABLISHED:
図10で説明されたFSMによって累積的に適用されることを意図します。 すなわち、独身のパケットのヘッダーを分析するのは1つ以上の変遷に通じるかもしれません。 例えば、標準のTCP州のダイヤグラムはダイレクトSYN-SENTからESTABLISHEDまでの変遷を含んでいます:
rcv SYN,ACK(SYN) / snd ACK(SYN).
rcv SYN、ACK(SYN)/snd ACK(SYN)。
This is transition b followed immediately by c.
これはcによるすぐにいうことになられた変遷bです。
Braden [Page 27] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[27ページ]RFC1379取引TCP--概念1992年11月
________ ________
| | h | |
| CLOSED |--------->| LISTEN |
|________| |________|
| |
| a | i
____V____ ____V___ ________
| SYN- | b' | SYN- | e' | |
| SENT |--------->|RECEIVED|-------------->| 1 |
|________| |________| |________|
/ / | | |
d'/ d'/ | c d' | c |
/ / __V_____ | _V______
/ / |ESTAB- | e | | CLOSE- |
| / | LISHED|------------|-->| WAIT |
| | |________| | |________|
| | | | |
| | | _____V__ |
| | | | | |
| | | | 2 | |
| | | |________| |
| | | | |
____V___ ______V_ | ________ | |
| | b'' | |e''' | | | | |
| 3 |------->| 4 |--------->| 5 | | |
|________| |________| | |________| | |
| / | | |
c | / d c | c | d |
| / | | |
_V___V__ ____V___ V_____V_
| FIN- | e'' | | | LAST- |
| WAIT-1|---->|CLOSING | | ACK |
|________| |________| |________|
| | |
| f | f | f
____V___ ____V___ ___V____
| FIN- | e | TIME- | g | |
| WAIT-2|---->| WAIT |-->| CLOSED |
|________| |________| |________|
________ ________ | | h| | | 閉じられます。|、-、-、-、-、-、-、-、--、>| 聴いてください。| |________| |________| | | | a| i____V____ ____V___ ________ | SYN| 'b'| SYN| 'e'| | | 発信します。|、-、-、-、-、-、-、-、--、>|受信します。|、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 1 | |________| |________| |________| / / | | | 'd'/d'/| 'c d'| c| //______ | _V______ / / |ESTAB| e| | 閉じてください。| | / | LISHED|、-、-、-、-、-、-、-、-、-、-、--、|、--、>| 待ち| | | |________| | |________| | | | | | | | | _____V__| | | | | | | | | | | 2 | | | | | |________| | | | | | | ____V___ ______V_| ________ | | | | 「b」| |'「e」'| | | | | | 3 |、-、-、-、-、-、--、>| 4 |、-、-、-、-、-、-、-、--、>| 5 | | | |________| |________| | |________| | | | / | | | c| /d c| c| d| | / | | | _V___V______V___ V_____V_| フィン| 「e」| | | 最終| | 待ち-1|、-、-、--、>|閉じます。| | ACK| |________| |________| |________| | | | | f| f| f____V___ ____V___ ___V____ | フィン| e| 時間| g| | | 待ち-2|、-、-、--、>| 待ち| -->、| 閉じられます。| |________| |________| |________|
Figure 10: Basic State Diagram -- Correct Actions
図10: 基本的な州のダイヤグラム--正しい動作
Next we introduce TAO. If the TAO test succeeds, the connection becomes half-synchronized. This requires a new set of states, mirroring the states of Figure 10, beginning with acceptance of a SYN (transition "b" or "i"), and ending when ACK(SYN) arrives (transition
次に、私たちはTAOを導入します。 TAOテストが成功するなら、接続は半分連動するようになります。 これは新しいセットに州を要求します、図10の事情を反映して、SYNの承認で(変遷「b」か「i」)を始めて、ACK(SYN)が到着すると終わって(変遷
Braden [Page 28] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[28ページ]RFC1379取引TCP--概念1992年11月
"c"). Figure 11 shows the result of augmenting Figure 10 with the additional states for TAO. The transitions are defined in the following table:
「c」) 図11はTAOのために追加州がある図10を増大させるという結果を示しています。 変遷は以下のテーブルで定義されます:
Key for Figure 11: Complete State Diagram with TAO
図11のためのキー: TAOがある完全な州のダイヤグラム
Label Event / Action
_____ ________________________
ラベル出来事/動作_____ ________________________
a OPEN / create TCB, snd SYN
b' rcv SYN [no TAO]/ snd SYN,ACK(SYN)
b'' rcv SYN [no TAO]/ snd SYN,FIN,ACK(SYN)
c rcv ACK(SYN) /
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) /
g timeout=2MSL / 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)
「'オープン/はTCBを作成します、snd SYN b'rcv SYN[TAOがない]/snd SYN、ACK(SYN)b」rcv SYN[TAOがない]/snd SYN、FIN、ACK(SYN)c rcv ACK(SYN)/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)/gタイムアウト=2MSL/は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)
Each new state in Figure 11 bears a very simple relationship to a standard TCP state. We indicate this by naming the new state with the standard state name followed by a star. States SYN-SENT* and SYN-RECEIVED* differ from the corresponding unstarred states in recording the fact that a FIN has been sent. The other new states with starred names differ from the corresponding unstarred states in being half-synchronized (hence, a SYN bit needs to be transmitted).
図11のそれぞれの新しい州は標準のTCP状態との非常に簡単な関係に堪えます。 私たちは、標準の州の名が星によって従われている状態で新しい状態を命名することによって、これを示します。 州のSYN-SENT*とSYN-RECEIVED*はFINを送ったという事実を記録するのにおいて対応する非主演された州と異なっています。 主演された名前がある他の新しい州は半分連動しているのにおいて対応する非主演された州と異なっています(したがって、SYNビットは、伝えられる必要があります)。
The state diagram of Figure 11 is more general than required for transaction processing. In particular, it handles simultaneous connection synchronization from both sides, allowing one or both sides to bypass the 3-way handshake. It includes other transitions that are unlikely in normal transaction processing, for example, the server sending a FIN before it receives a FIN from the client (ESTABLISHED* -> FIN-WAIT-1* in Figure 11).
図11の州のダイヤグラムはトランザクション処理のために必要とされるより一般的です。 ものか両側が3ウェイ握手を迂回させるのを許容して、特に、それは両側から同時接続同期を扱います。 それは他の通常のトランザクション処理でありそうもない変遷を含んでいます、例えば、それの前にFINを送るサーバがクライアント(図11のESTABLISHED*->FIN-WAIT-1*)からFINを受けます。
Braden [Page 29] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[29ページ]RFC1379取引TCP--概念1992年11月
________ ________
| | h | |
| CLOSED |--------------->| LISTEN |
|________| |________|
| / |
a| / i | j
| / |
| / _V______ ________
| j | |ESTAB- | e' | CLOSE- |
| /---------|----->| LISHED*|------------>| WAIT*|
| / | |________| |________|
| / | | | | |
| / | |d' | c d' | | c
____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- | g | |
| WAIT-2 |---->| WAIT |-->| CLOSED |
|________| |________| |________|
________ ________ | | h| | | 閉じられます。|、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 聴いてください。| |________| |________| | / | a| /i| j| / | | /______ ________ | j| |ESTAB| 'e'| 閉じてください。| | /---------|、-、-、-、--、>| LISHED*|、-、-、-、-、-、-、-、-、-、-、--、>| *を待ってください。| | / | |________| |________| | / | | | | | | / | |'d'| 'c d'| | c____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|時間| g| | | 待ち-2|、-、-、--、>| 待ち| -->、| 閉じられます。| |________| |________| |________|
Figure 11: Complete State Diagram with TAO
図11: TAOがある完全な州のダイヤグラム
The relationship between starred and unstarred states is very regular. As a result, the state extensions can be implemented very simply using the standard TCP FSM with the addition of two "hidden" boolean flags, as described in the functional specification memo
主演されて非主演された州の間の関係は非常に通常です。 その結果、非常に単に2個の「隠された」論理演算子旗の添加がある標準のTCP FSMを使用することで州の拡大を実行できます、機能的な仕様メモで説明されるように
Braden [Page 30] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[30ページ]RFC1379取引TCP--概念1992年11月
[TTCP-FS].
[TTCP-FS。]
As an example of the application of Figure 11, consider the minimal transaction shown in Figure 12.
図11の応用に関する例と、図12に示された最小量の取引を考えてください。
TCP A (Client) TCP B (Server)
_______________ ______________
TCPは(クライアント)TCP B(サーバ)です。_______________ ______________
CLOSED LISTEN
閉じられて、聴いてください。
1. SYN-SENT* --> <SYN,data1,FIN,CC=x1> --> CLOSE-WAIT*
(TAO test OK=>
data1->user_B)
1. SYNによって送られた*(x1SYN(data1、フィン)がCCする><=>)>厳密な待ち*(TAOテストOK=>data1>ユーザ_B)
LAST-ACK*
<-- <SYN,ACK(FIN),data2,FIN,CC=y1,CC.ECHO=x1> <--
2. TIME-WAIT
(TAO test OK,
data2->user_A)
最後のACK*<--<SYN(ACK(フィン)、data2、フィン)は=y1、CC.ECHO=x1><をCCします--2。 時間待ち(TAOがOKをテストする、data2->、ユーザ、)
3. TIME-WAIT --> <ACK(FIN),CC=x2> --> CLOSED
3. 時間待ち--><ACK(フィン)、CC=x2>-->は閉じました。
(timeout)
CLOSED
(タイムアウト)は閉じました。
Figure 12: Minimal Transaction Sequence
図12: 最小量の取引系列
Sending segment #1 leaves the client end in SYN-SENT* state, which differs from SYN-SENT state in recording the fact that a FIN has been sent. At the server end, passing the TAO test enters ESTABLISHED* state, which passes the data to the user as in ESTABLISHED state and also records the fact that the connection is half synchronized. Then the server processes the FIN bit of segment #1, moving to CLOSE-WAIT* state.
SYN-SENT*状態で1が残すセグメント#にクライアント終わりを送ります。(それは、FINを送ったという事実を記録するのにおいてSYN-SENT状態と異なっています)。 サーバ終わりに、TAOテストに合格するのはESTABLISHED*州に入ります。(それは、ESTABLISHED状態のようにデータをユーザに渡して、また、接続が半分同時にするという事実を記録します)。 そして、CLOSE-WAIT*状態に動いて、サーバはセグメント#1のFINビットを処理します。
Moving to CLOSE-WAIT* state should cause the server to send a segment containing SYN and ACK(FIN). However, transmission of this segment is deferred so the server can piggyback the response data and FIN on the same segment, unless a timeout occurs first. When the server does send segment #2 containing the response data2 and a FIN, the connection advances from CLOSE-WAIT* to LAST-ACK* state; the connection is still half-synchronized from B's viewpoint.
CLOSE-WAIT*状態に動くのはサーバにSYNとACK(FIN)を含むセグメントを送らせるべきです。 しかしながら、サーバが同じセグメントで応答のデータとFINを背負うことができるように、このセグメントの送信は延期されます、タイムアウトが最初に起こらない場合。 サーバが応答data2とFINを含むセグメント#2を送るとき、接続はCLOSE-WAIT*からLAST-ACK*状態まで進みます。 接続はビーズ観点からまだ半分連動されています。
Processing segment #2 at the client again results in multiple transitions:
クライアントでの処理セグメント#2は再び複数の変遷をもたらします:
Braden [Page 31] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[31ページ]RFC1379取引TCP--概念1992年11月
SYN-SENT* -> FIN-WAIT-1* -> CLOSING* -> CLOSING -> TIME-WAIT
SYNによって送られた*->フィン待ち-1->閉鎖*->終わりの->時間*待ち時間
These correspond respectively to receiving a SYN, a FIN, an ACK for A's SYN, and an ACK for A's FIN.
これらはそれぞれSYN、FIN、AのSYNのためのACK、およびAのFINのためのACKを受けると対応しています。
Figure 13 shows a slightly more complex example, a transaction sequence in which request and response data each require two segments. This figure assumes that both client and server TCP are well-behaved, so that e.g., the client sends the single segment #5 to acknowledge both data segments #3 and #4. SEG.CC values are omitted for clarity.
図13はわずかに複雑な例(要求と応答データがそれぞれ2つのセグメントを必要とする取引系列)を示しています。 この図は、クライアントとサーバTCPの両方が品行方正であると仮定します、例えば、クライアントがデータ・セグメント#3と#4の両方を承認するためにただ一つのセグメント#5を送るように。 SEG.CC値は明快ために省略されます。
_T_C_P__A _T_C_P__B
___T_C_Pは_T_C_P__Bです。
1. SYN-SENT* --> <SYN,data1> --> ESTABLISHED*
(TAO OK,
data1-> user)
1. SYNによって送られた*(><SYN、data1>)>確立した*(TAO OK、data1->ユーザ)
2. SYN-SENT* --> <data2,FIN> --> CLOSE-WAIT*
(data2-> user)
2. SYNによって送られた*(><data2、フィン>)>厳密な待ち*(data2->ユーザ)
3. FIN-WAIT-2 <-- <SYN,ACK(FIN),data3> <-- CLOSE-WAIT*
(data3->user)
3. フィン待2ち<--<SYN、ACK(フィン)、data3><--厳密な待っている*(data3->、ユーザ、)
4. TIME_WAIT <-- <ACK(FIN),data4,FIN> <-- LAST-ACK*
(data4->user)
4. タイム誌_は<--<ACK(フィン)、data4、フィン><--最後のACKの*を待っています。(data4->、ユーザ、)
5. TIME-WAIT --> <ACK(FIN)> --> CLOSED
5. 時間待ち--><ACK(フィン)>-->は閉じました。
Figure 13. Multi-Packet Request/Response Transaction
図13。 マルチパケット要求/応答取引
7. CONCLUSIONS AND ACKNOWLEDGMENTS
7. 結論と承認
TCP was designed to be a highly symmetric protocol. This symmetry is evident in the piggy-backing of acknowledgments on data and in the common header format for data segments and acknowledgments. On the other hand, the examples and discussion in this memo are in general highly unsymmetrical; the actions of a "client" are clearly distinguished from those of a "server". To explain this apparent discrepancy, we note the following. Even when TCP is used for virtual circuit service, the data transfer phase is symmetrical but the open and close phases are not. A minimal transaction, consisting of one segment in each direction, compresses the open, data transfer, and close phases together, and making the asymmetry of the open and
TCPは、非常に左右対称のプロトコルになるように設計されました。 この対称はデータでの承認の便乗とデータ・セグメントと承認のための一般的なヘッダー形式で明白です。 他方では、一般に、このメモにおける例と議論がそうである、非常に、unsymmetrical。 「クライアント」の動作は「サーバ」のものと明確に区別されます。 この見かけの食い違いについて説明するために、私たちは以下に注意します。 TCPが仮想のサーキットサービスに使用さえされるとき、データ転送段階は対称ですが、開いていて近いフェーズは対称であるというわけではありません。 そして各方向へのあるセグメントから成って、戸外、データ転送、および近いフェーズを一緒に圧縮して、戸外の非対称を作る最小量の取引。
Braden [Page 32] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[32ページ]RFC1379取引TCP--概念1992年11月
close phases dominant. As request and response messages increase in size, the virtual circuit model becomes increasingly relevant, and symmetry again dominates.
優位な状態でフェーズを閉じてください。 要求と応答メッセージが大きくなるのに従って、事実上の回路モデルはますます関連するようになります、そして、対称は再び支配されます。
TCP's 3-way handshake precludes any performance gain from including data on a SYN segment, while TCP's full-duplex data-conserving close sequence ties up communication resources to the detriment of high- speed transactions. Merely loading more control bits onto TCP data segments does not provide efficient transaction service. To use TCP as an effective transaction transport protocol requires bypassing the 3-way handshake and shortening the TIME-WAIT delay. This memo has proposed a backwards-compatible TCP extension to accomplish both goals. It is our hope that by building upon the current version of TCP, we can give a boost to community acceptance of the new facilities. Furthermore, the resulting protocol implementations will retain the algorithms that have been developed for flow and congestion control in TCP [Jacobson88].
TCPの3ウェイ握手はSYNセグメントに関するデータを含んでいるので、どんな性能向上も排除します、TCPのデータを保存する全二重近い系列は高い速度取引の損傷にコミュニケーションリソースをタイアップしますが。 単にTCPデータ・セグメントをより多くのコントロールビット押し込むのは効率的な取引サービスを提供しません。 有効な取引トランスポート・プロトコルとしてTCPを使用するのは、3ウェイ握手を迂回させて、タイム誌-WAIT遅れを短くするのを必要とします。 このメモは、両方の目標を達成するために後方にコンパチブルTCP拡張子を提案しました。 それはTCPの最新版を当てにすることによって、私たちが新しい設備の共同体承認に後押しできるという私たちの望みです。 その上、結果として起こるプロトコル実現はTCP[Jacobson88]で流れと輻輳制御のために開発されたアルゴリズムを保有するでしょう。
O'Malley and Peterson have recently recommended against backwards- compatible extensions to TCP, and suggested instead a mechanism to allow easy installation of alternative versions of a protocol [RFC- 1263]. While this is an interesting long-term approach, in the shorter term we suggest that incremental extension of the current TCP may be a more effective route.
オマリーとピーターソンは、最近後方にであることに対するコンパチブル拡大をTCPに推薦して、プロトコル[RFC1263]の異本の簡単なインストールを許容するために代わりにメカニズムを勧めました。 これはおもしろい長期のアプローチですが、もっと短期的に見れば私たちは、現在のTCPの増加の拡大が、より効果的なルートであるかもしれないと示唆します。
Besides the backward-compatible extension proposed here, there are two other possible approaches to making efficient transaction processing widely available in the Internet: (1) a new version of TCP or (2) a new protocol specifically adapted to transactions. Since current TCP "almost" supports transactions, we favor (1) over (2). A new version of TCP that retained the semantics of STD-007 but used 64 bit sequence numbers with the procedures and states described in Sections 3, 4, and 6 of this memo would support transactions as well as virtual circuits in a clean, coherent manner.
ここで提案された後方コンパチブル拡大以外に、インターネットで効率的なトランザクション処理を広く利用可能にすることへの他の2つの可能なアプローチがあります: (1) (2) TCPの新しいバージョンか新しいプロトコルが明確に取引に順応しました。 現在のTCPが取引を「ほとんど」支持するので、私たちは(2)より(1)を好みます。 このメモのセクション3、4、および6で説明される手順と州と共にSTD-007の意味論を保有しましたが、64ビットの一連番号を使用したTCPの新しいバージョンは清潔で、論理的な態度による仮想のサーキットと同様に取引を支持するでしょう。
A potential application of transaction-mode TCP might be SMTP. If commands and responses are batched, in favorable cases complete SMTP delivery operations on short messages could be performed with a single minimal transaction; on the other hand, the body of a message may be arbitrarily large. Using a TCP extended as in this memo could significantly reduce the load on large mail hosts.
取引モードTCPの潜在的アプリケーションはSMTPであるかもしれません。 コマンドと応答がbatchedされるなら、好ましい場合では、短いメッセージにおける完全なSMTP配送操作はただ一つの最小量の取引で実行されるかもしれません。 他方では、メッセージのボディーは任意に大きいかもしれません。 このメモのように広げられたTCPを使用すると、負荷は大きいメールホストでかなり減少するかもしれません。
This work began as an elaboration of the concept of TAO, due to Dave Clark. I am grateful to him and to Van Jacobson, John Wroclawski, Dave Borman, and other members of the End-to-End Research group for helpful ideas and critiques during the long development of this work. I also thank Liming Wei, who tested the initial implementation in Sun OS.
この仕事はデーブ・クラークのためTAOの概念の労作として始まりました。 私は彼と、そして、ヴァン・ジェーコブソンに感謝しています、ジョンWroclawski、デーヴ・ボーマン、そして、Endから終わりへのResearchの他のメンバーは役立っている考えと批評のためにこの仕事の長い開発の間、分類します。 また、私はLimingウェイに感謝します。(ウェイは、Sun OSで初期の実現をテストしました)。
Braden [Page 33] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[33ページ]RFC1379取引TCP--概念1992年11月
APPENDIX A -- TIME-WAIT STATE AND THE 2-PACKET EXCHANGE
付録A--時間待ち状態と2パケットの交換
This appendix considers the implications of reducing TIME-WAIT state delay below that given in formula [2].
この付録は、タイム誌-WAITを減少させる含意が公式[2]で与えられたそれの下に遅れを述べると考えます。
An immediate consequence of this would be the requirement for the server host to accept an initial SYN for a connection in LAST-ACK state. Without the transaction extensions, the arrival of a new <SYN> in LAST-ACK state looks to TCP like a half-open connection, and TCP's rules are designed to restore correspondence by destroying the state (through sending a RST segment) at one end or the other. We would need to thwart this action in the case of transactions.
この即座の結果はサーバー・ホストがLAST-ACK状態での接続のために初期のSYNを受け入れるという要件でしょう。 取引拡大がなければ、新しい<SYN>のLAST-ACK状態への到着は半開きな接続のようにTCPを当てにします、そして、TCPの規則は、片端かもう片方で状態(RSTセグメントを送るのによる)を破壊することによって通信を回復するように設計されています。 私たちは、取引の場合でこの動作を阻む必要があるでしょう。
There are two different possible ways to further reduce TIME-WAIT delay.
タイム誌-WAIT遅れをさらに減少させる2つの異なった可能な方法があります。
(1) Explicit Truncation of TIME-WAIT state
(1) タイム誌-WAIT状態の明白なTruncation
TIME-WAIT state could be explicitly truncated by accepting a new
sendto() request for a connection in TIME-WAIT state.
タイム誌-WAIT状態は、タイム誌-WAIT状態での接続を求める新しいsendto()要求を受け入れることによって、明らかに先端を切られるかもしれません。
This would allow the ACK(FIN) segment to be delayed and sent
only if a timeout occurs before a new request arrives. This
allows an ideal 2-segment exchange for closely-spaced
transactions, which would restore some symmetry to the
transaction exchange. However, explicit truncation would
represent a significant change in many implementations.
新しい要求が到着する前にタイムアウトが起こる場合にだけ、これは、ACK(FIN)セグメントが遅らせて、送られるのを許容するでしょう。 これは密接に区切られた取引への理想的な2セグメントの交換を許容します。(取引は取引交換への何らかの対称を回復するでしょう)。 しかしながら、明白なトランケーションは多くの実現における著しい変化を表すでしょう。
It might be supposed that even greater symmetry would result if
the new request segment were a <SYN,ACK> that explicitly
acknowledges the previous reply, rather than a <SYN> that is
only an implicit acknowledgment. However, the new request
segment might arrive at B to find the server side in either
LAST-ACK or CLOSED state, depending upon whether the ACK(FIN)
had arrived. In CLOSED state, a <SYN,ACK> would not be
acceptable. Hence, if the client sent an initial <SYN,ACK>
instead of a <SYN> segment, there would be a race condition at
the server.
さらに大きい対称が新しい要求セグメントが<SYNであるなら結果として生じると思われるかもしれません、明らかに暗黙の承認であるにすぎない<SYN>よりむしろ前の回答を承諾するACK>。 しかしながら、新しい要求セグメントはLAST-ACKかCLOSEDのどちらかのサーバ側に状態を見つけるためにBに到着するかもしれません、ACK(FIN)が到着したかどうかによって。 CLOSED状態、<SYNでは、ACK>は許容できないでしょう。 したがって、クライアントが初期の<SYN、<SYN>セグメントの代わりにACK>を送るなら、サーバには競合条件があるでしょうに。
(2) No TIME-WAIT delay
(2) タイム誌-WAIT遅れがありません。
TIME-WAIT delay could be removed entirely. This would imply
that the ACK(FIN) would always be sent (which does not of course
guarantee that it will be received). As a result, the arrival
of a new SYN in LAST-ACK state would be rare.
タイム誌-WAIT遅れを完全に取り除くことができました。 これは、ACK(FIN)がいつも送られるのを含意するでしょう(もちろんそれが受け取られるのを保証しません)。 その結果、LAST-ACK状態への新しいSYNの到着はまれでしょう。
This choice is much simpler to implement. Its drawback is that
the server will get a false failure report if the ACK(FIN) is
この選択は実行するのがはるかに簡単です。 欠点はACK(FIN)が得るとサーバが誤った異常報告書を得るということです。
Braden [Page 34] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[34ページ]RFC1379取引TCP--概念1992年11月
lost. This may not matter in practice, but it does represent a
significant change of TCP semantics. It should be noted that
reliable delivery of the reply is not an issue. The client
enter TIME-WAIT state only after the entire reply, including the
FIN bit, has been received successfully.
無くなる。 これは実際には重要でないかもしれませんが、それはTCP意味論の著しい変化を表します。 回答の信頼できる配信が問題でないことに注意されるべきです。 首尾よくFINビットを含む全体の回答を受け取った後にだけクライアントはタイム誌-WAIT状態に入ります。
The server host B must be certain that a new request received in LAST-ACK state is indeed a new SYN and not an old duplicate; otherwise, B could falsely acknowledge a previous response that has not in fact been delivered to A. If the TAO comparison succeeds, the SYN must be new; however, the server has a dilemma if the TAO test fails.
サーバー・ホストBは本当に、LAST-ACK状態に受け取られた新しい要求が古い写しではなく、新しいSYNであることを確信しているに違いありません。 さもなければ、Bは間違って事実上、TAO比較が引き継ぐA.Ifに渡されていない前の応答を承諾できて、SYNは新しいに違いありません。 しかしながら、サーバには、TAOテストが失敗するなら、ジレンマがあります。
In Figure A.1, for example, the reply segment from the first transaction has been lost; since it has not been acknowledged, it is still in B's retransmission queue. An old duplicate request, segment #3, arrives at B and its TAO test fails. B is in the position of having old state it cannot discard (the retransmission queue) and needing to build new state to pursue a 3-way handshake to validate the new SYN. If the 3-way handshake failed, it would need to restore the earlier LAST-ACK* state. (Compare with Figure 15 "Old Duplicate SYN Initiates a Reset on Two Passive Sockets" in STD-007). This would be complex and difficult to accomplish in many implementations.
図A.1では、例えば、最初の取引からの回答セグメントは失われました。 承認されていないので、それはまだビーズの再送キュー中です。 古い写し要求(セグメント#3)はBに到着します、そして、TAOテストは失敗します。 Bがそれが捨てることができない古い状態(再送キュー)を持って、新しいSYNを有効にするために3ウェイ握手を追求するために新しい状態を造るのが必要であることの位置にあります。 3ウェイ握手が失敗するなら、それは、以前のLAST-ACK*状態を回復する必要があるでしょうに。 (STD-007の「古い写しSYNは2個の受け身のソケットの上にリセットを開始する」という図15と、比較します。) これは、複雑であって、多くの実現で達成するのは難しいでしょう。
TCP A (Client) TCP B (Server)
_______________ ______________
TCPは(クライアント)TCP B(サーバ)です。_______________ ______________
CLOSED LISTEN
閉じられて、聴いてください。
1. SYN-SENT* --> <SYN,data1,FIN> --> CLOSE-WAIT*
(TAO test OK;
data1->server)
1. SYNによって送られた*(><SYN、data1、フィン>)>厳密な待ち*(TAOはOKをテストします;、data1->、サーバ、)
2. (lost) X<-- <SYN,ACK(FIN),data2,FIN> <-- LAST-ACK*
2. (無くなる)です。 X<--<SYN、ACK(フィン)、data2、フィン><--最後のACKの*
(old duplicate)
3. ... <SYN,data3,FIN> --> LAST-ACK*
(TAO test fail;
3-way handshake?)
(古い写し) 3。 ... <SYN、data3、フィン>-->の最後のACK*(TAOテストは失敗します; 3ウェイ握手)?
Figure A.1: The Server's Dilemma
A.1は計算します: サーバのジレンマ
The only practical action A can taken when the TAO test fails on a new SYN received in LAST-ACK state is to ignore the SYN, assuming it is really an old duplicate. We must pursue the possible consequences
テストがLAST-ACK状態に受け取られた新しいSYNで失敗するTAOがSYNを無視することになっているなら取って、唯一の実用的な動きAがそうすることができます、それが本当に古い写しであると仮定して。 私たちは可能な結果を追求しなければなりません。
Braden [Page 35] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[35ページ]RFC1379取引TCP--概念1992年11月
of this action.
この動作について。
Section 3.1 listed four possible reasons for failure of the TAO test on a legitimate SYN segment: (1) no cached state, (2) out-of-order delivery of SYNs, (3) wraparound of CCgen relative to the cached value, or (4) the M values advance too slowly. We are assuming that there is a cached CC value at B (otherwise, the SYN cannot be acceptable in LAST-ACK state). Wrapping the CC space is very unlikely and probably impossible; it is difficult to imagine circumstances which would allow the new SYN to be delivered but not the ACK(FIN), especially given the long wraparound time of CCgen.
セクション3.1は正統のSYNセグメントのTAOテストの失敗の4つの可能な理由をリストアップしました: (1) (4) いいえは状態をキャッシュしました、SYNsの(2)の不適切な配送、キャッシュされた値に比例したCCgenの(3)巻きつけて着るドレス、または、Mがあまりにゆっくり進歩を評価します。 私たちは、BにおけるキャッシュされたCC値があると思っています(さもなければ、SYNはLAST-ACK状態で許容できるはずがありません)。 CCスペースを包装するのは、非常にありそうもなくて、たぶん不可能です。 ACK(FIN)ではなく、新しいSYNが届けられるのを許容する事情を想像するのは難しいです、CCgenの長い巻きつけて着るドレス時間を特に考えて。
This leaves the problem of out-of-order delivery of two nearly- concurrent SYNs for different ports. The second to be delivered may have a lower CC option and thus be locked out. This can be solved by using a new CCgen value for every retransmission of an initial SYN.
これは異なったポートのために2の不適切な配送の問題をほとんど同時発生のSYNsに残します。 渡されるべき2番目は、低いCCオプションを持って、その結果、締め出されるかもしれません。 初期のSYNのあらゆる「再-トランスミッション」に新しいCCgen値を使用することによって、これを解決できます。
Truncation of TIME-WAIT state and acceptance of a SYN in LAST-ACK state should take place only if there is a cached CC value for the remote host. Otherwise, a SYN arriving in LAST-ACK state is to be processed by normal TCP rules, which will result in a RST segment from either A or B.
リモートホストのためのキャッシュされたCC値がある場合にだけ、タイム誌-WAIT状態のトランケーションとLAST-ACK状態のSYNの承認は行われるべきです。 さもなければ、LAST-ACK状態に到着するSYNは正常なTCP規則で処理されることになっています。(規則はAかBのどちらかからのRSTセグメントをもたらすでしょう)。
This discussion leads to a paradigm for rejecting old duplicate segments that is different from TAO. This alternative scheme is based upon the following:
この議論は古い写しセグメントを拒絶するためのTAOと異なったパラダイムにつながります。 この代替の計画は以下に基づいています:
(a) Each retransmission of an initial SYN will have a new value of
CC, as described above.
(a) 初期のSYNの各「再-トランスミッション」には、CCの新しい値が上で説明されるようにあるでしょう。
This provision takes care of reordered SYNs.
この支給はreordered SYNsの世話をします。
(b) A host maintains a distinct CCgen value for each remote host.
This value could easily be maintained in the same cache used for
the received CC values, e.g., as cache.CCgen[].
(b) ホストはそれぞれのリモートホストのために異なったCCgen値を維持します。 例えば、容認されたCC値、cache.CCgen[]として使用される同じキャッシュで容易にこの値を維持できました。
Once the caches are primed, it should always be true that
cache.CCgen[B] on host A is equal to cache.CC[A] on host B, and
the next transaction from A will carry a CC value exactly 1
greater. Thus, there is no problem of wraparound of the CC
value.
キャッシュがいったん用意されていると、ホストAの上のcache.CCgen[B]がホストBでcache.CC[A]と等しいのが、いつも本当であるはずであり、Aからの次の取引はキャリーa CC価値によりすばらしい状態でまさに1を望んでいます。 したがって、CC価値の巻きつけて着るドレスの問題が全くありません。
(c) A new SYN is acceptable if its SEG.CC > cache.CC[client],
otherwise the SYN is ignored as an old duplicate.
(c) SEG.CC>cache.CC[クライアント]、そうでなければSYNが古い写しとして無視されるなら、新しいSYNは許容できます。
This alternative paradigm was not adopted because it would be a somewhat greater perturbation of TCP rules, because it may not have the robustness of TAO, and because all of its consequences may not be
それはTCP規則のいくらかすごい摂動でしょう、したがって、この代替のパラダイムが採用されませんでした、それにはTAOの丈夫さがないかもしれなくて、また結果のすべてがないかもしれないので
Braden [Page 36] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[36ページ]RFC1379取引TCP--概念1992年11月
understood.
理解にされる。
REFERENCES
参照
[Birrell84] Birrell, A. and B. Nelson, "Implementing Remote
Procedure Calls", ACM TOCS, Vo. 2, No. 1, February 1984.
[Birrell84] ビレルとA.とB.ネルソン、「遠隔手続き呼び出しを実行します」、ACMトックス、Vo。 2 1984年2月のNo.1。
[Clark88] Clark, D., "The Design Philosophy of the Internet
Protocols", ACM SIGCOMM '88, Stanford, CA, August 1988.
[Clark88] クラーク、D.、「インターネットプロトコルの設計理念」、ACM SIGCOMM88年、スタンフォード、カリフォルニア、1988年8月。
[Clark89] Clark, D., Private communication, 1989.
[Clark89] クラーク、D.、兵士のコミュニケーション、1989。
[Garlick77] Garlick, L., R. Rom, and J. Postel, "Issues in Reliable
Host-to-Host Protocols", Proc. Second Berkeley Workshop on
Distributed Data Management and Computer Networks, May 1977.
[Garlick77] ガーリック、L.、R.Rom、およびJ.ポステル、「信頼できるホスト間プロトコルの問題」、Proc。 1977年5月の分散データ管理とコンピュータネットワークに関する第2バークレーワークショップ。
[HR-COMM] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers", STD-003, RFC-1122, October 1989.
[時間-COMM] ブレーデン、R.、エド、「インターネットホストのための要件--コミュニケーションは層にする」、STD-003、RFC-1122、10月1989日
[Jacobson88] Jacobson, V., "Congestion Avoidance and Control",
SIGCOMM '88, Stanford, CA., August 1988.
[Jacobson88] ジェーコブソンと、V.と、「輻輳回避とコントロール」、SIGCOMM88年、スタンフォード(カリフォルニア)、8月1988日
[Jacobson90] Jacobson, V., private communication, 1990.
[Jacobson90] ジェーコブソン、V.、私信、1990。
[Liskov90] Liskov, B., Shrira, L., and J. Wroclawski, "Efficient
At-Most-Once Messages Based on Synchronized Clocks", ACM SIGCOMM
'90, Philadelphia, PA, September 1990.
[Liskov90] Liskov、B.、Shrira、L.、およびJ.Wroclawski、「効率的である、大部分、一度、メッセージが連動している時計に基づかせた、」、ACM SIGCOMM90年(フィラデルフィア(PA)1990年9月)
[RFC-955] Braden, R., "Towards a Transport Service Transaction
Protocol", RFC-955, September 1985.
[RFC-955]ブレーデン、「輸送サービス取引プロトコル」へのR.RFC-955、1985年9月。
[RFC-1185] Jacobson, V., Braden, R., and Zhang, L., "TCP Extension
for High-Speed Paths", RFC-1185, October 1990.
1990年10月の[RFC-1185]ジェーコブソンとV.とブレーデン、R.とチャン、L.、「高速経路のためのTCP拡張子」RFC-1185。
[RFC-1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered
Harmful", RFC-1263, University of Arizona, October 1991.
[RFC-1263] オマリーとS.とL.ピーターソン、「有害であると考えられたTCP拡張子」、RFC-1263、アリゾナ大学、1991年10月。
[RFC-1323] Jacobson, V., Braden, R., and Borman, D., "TCP
Extensions for High Performance, RFC-1323, February 1991.
[RFC-1323] ジェーコブソンとV.とブレーデン、R.とボーマン、D.、「高性能のためのTCP拡張子、RFC-1323、1991年2月。」
[RFC-1337] Braden, R., "TIME-WAIT Assassination Hazards in TCP",
RFC-1337, May 1992.
[RFC-1337]ブレーデン(R.、「TCPの時間待ち暗殺危険」、RFC-1337)は1992がそうするかもしれません。
[STD-007] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", STD-007, RFC-793,
September 1981.
[STD-007] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD-007、RFC-793、1981年9月。
Braden [Page 37] RFC 1379 Transaction TCP -- Concepts November 1992
ブレーデン[37ページ]RFC1379取引TCP--概念1992年11月
[TTCP-FS] Braden, R., "Transaction TCP -- Functional
Specification", Work in Progress, September 1992.
[TTCP-FS]ブレーデン、R.、「取引TCP--、機能的な仕様、」、9月1992、進行中で、働いてください。
[Watson81] Watson, R., "Timer-based Mechanisms in Reliable
Transport Protocol Connection Management", Computer Networks, Vol.
5, 1981.
[Watson81] ワトソン、R.、「信頼できるトランスポート・プロトコル接続管理におけるタイマベースのメカニズム」、コンピュータネットワーク、Vol.5、1981。
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ページ]
一覧
スポンサーリンク
