この文書はRFC793の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの文書の配布を制限しません。
※gifイメージが１つ入ってるので、コピーする際は忘れずに
RFC: 793
TRANSMISSION CONTROL PROTOCOL
転送制御プロトコル
DARPA INTERNET PROGRAM
DARPAインターネットプログラム
PROTOCOL SPECIFICATION
プロトコル仕様書
September 1981
１９８１年９月
prepared for
Defense Advanced Research Projects Agency
Information Processing Techniques Office
1400 Wilson Boulevard
Arlington, Virginia 22209
by
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
TABLE OF CONTENTS
目次
PREFACE （序文）
1. INTRODUCTION （導入）
1.1. Motivation （動機）
1.2. Scope （範囲）
1.3. About this Document （このドキュメントについて）
1.4. Interfaces （インタフェース）
1.5. Operation （オペレーション）
2. PHILOSOPHY （哲学）
2.1. Elements of the Internetwork System （インターネットワークシステムの要素）
2.2. Model of Operation （オペレーションのモデル）
2.3. The Host Environment （ホスト環境）
2.4. Interfaces （インタフェース）
2.5. Relation to Other Protocols （他のプロトコルへの関係）
2.6. Reliable Communication （信頼できる通信）
2.7. Connection Establishment and Clearing （接続の確立とクリア）
2.8. Data Communication （データ通信）
2.9. Precedence and Security （優先順位と安全）
2.10. Robustness Principle （安定原理）
3. FUNCTIONAL SPECIFICATION （機能仕様）
3.1. Header Format （ヘッダーフォーマット）
3.2. Terminology （技術用語）
3.3. Sequence Numbers （シーケンス番号）
3.4. Establishing a connection （接続を確立する）
3.5. Closing a Connection （接続を閉じる）
3.6. Precedence and Security （優先順位と安全）
3.7. Data Communication （データ通信）
3.8. Interfaces （インタフェース）
3.9. Event Processing （イベント処理）
GLOSSARY （用語集）
REFERENCES （参考文献）
PREFACE
序文
This document describes the DoD Standard Transmission Control Protocol
(TCP). There have been nine earlier editions of the ARPA TCP
specification on which this standard is based, and the present text
draws heavily from them. There have been many contributors to this work
both in terms of concepts and in terms of text. This edition clarifies
several details and removes the end-of-letter buffer-size adjustments,
and redescribes the letter mechanism as a push function.
このドキュメントはDoD標準送信制御プロトコル（TCP）を記述する。この標準が
基礎を置くARPATCP仕様の９冊の以前の版がり、そして現在のテキストはかなり
それらから引き抜いている。この仕事の概念と原文に関して多くの貢献者がいた。
この版はいくつかの細部を明確にして、そして文字列終了バッファサイズ修正を
取り除いて、そして文字メカニズムをプッシュ機能と説明する。
Jostel
Editor
RFC: 793
Replaces: RFC 761
IENs: 129, 124, 112, 81,
55, 44, 40, 27, 21, 5
TRANSMISSION CONTROL PROTOCOL
送信制御プロトコル
DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION
ＤＡＲＰＡインターネットプログラム
プロトコル規定
1. INTRODUCTION
導入
The Transmission Control Protocol (TCP) is intended for use as a highly
reliable host-to-host protocol between hosts in packet-switched computer
communication networks, and in interconnected systems of such networks.
送信制御プロトコル（TCP）はパケット交換コンピュータ通信ネットワークで、
そしてこのようなネットワークの相互接続系でホストの間に大いに信頼性が高い
ホスト対ホストプロトコルとして使用のために意図される。
This document describes the functions to be performed by the
Transmission Control Protocol, the program that implements it, and its
interface to programs or users that require its services.
このドキュメントは、送信制御プロトコルによって行われる機能、それを実行す
るプログラム、そしてそのサービスを必要とするプログラムあるいはユーザへの
インタフェースを記述する。
1.1. Motivation
動機
Computer communication systems are playing an increasingly important
role in military, government, and civilian environments. This
document focuses its attention primarily on military computer
communication requirements, especially robustness in the presence of
communication unreliability and availability in the presence of
congestion, but many of these problems are found in the civilian and
government sector as well.
コンピュータ通信システムが軍の、政府の、そして民間の環境でますます重
要な役割を演じている。このドキュメントは通信頼りなさと有効性の面前で
輻輳の面前で主に軍のコンピュータ通信要求事項、特に強靭性にその注意を
集中する、しかしこれらの問題の多くが同様に民間と政府部門で見いだされ
る。
As strategic and tactical computer communication networks are
developed and deployed, it is essential to provide means of
interconnecting them and to provide standard interprocess
communication protocols which can support a broad range of
applications. In anticipation of the need for such standards, the
Deputy Undersecretary of Defense for Research and Engineering has
declared the Transmission Control Protocol (TCP) described herein to
be a basis for DoD-wide inter-process communication protocol
standardization.
戦略上の、そして戦術的なコンピュータ通信ネットワークが開発されて、
そして配置されるにつれて、それらを相互に結び付ける手段を供給すること、
そしてアプリケーションの広範囲をサポートすることができる標準プロセス
間通信プロトコルを供給することは不可欠である。このような標準の必要の
予想で、研究と工学のに対する防衛の代理次官はここに記述された送信制御
プロトコル（TCP）がDoD規模のプロセス間通信プロトコル標準化のために基
準であると宣言した。
TCP is a connection-oriented, end-to-end reliable protocol designed to
fit into a layered hierarchy of protocols which support multi-network
applications. The TCP provides for reliable inter-process
communication between pairs of processes in host computers attached to
distinct but interconnected computer communication networks. Very few
assumptions are made as to the reliability of the communication
protocols below the TCP layer. TCP assumes it can obtain a simple,
potentially unreliable datagram service from the lower level
protocols. In principle, the TCP should be able to operate above a
wide spectrum of communication systems ranging from hard-wired
connections to packet-switched or circuit-switched networks.
TCPがマルチネットワークのアプリケーションをサポートするプロトコルの層
状の階層に適切であるよう意図される結線指向の、端と端をつないだ信頼性
が高いプロトコルである。TCPは別個だが相互に結び付けられたコンピュータ
通信ネットワークに置かれたホストコンピュータでプロセスの対の間に信頼
できるプロセス間通信を供給する。極めて少数の仮説しかTCPレイヤの下に通
信プロトコルの安定性についてされない。TCPがそれがより低いレベルプロト
コルから単純な、潜在的に、当てにならないデータグラムサービスを得るこ
とができると想定する。原則として、TCPは広範囲のハードワイヤード接続か
らパケット交換あるいは回線交換ネットワークまで及んでいる通信システム
の上に稼働することが可能であるべきである。
TCP is based on concepts first described by Cerf and Kahn in [1]. The
TCP fits into a layered protocol architecture just above a basic
Internet Protocol [2] which provides a way for the TCP to send and
receive variable-length segments of information enclosed in internet
datagram "envelopes". The internet datagram provides a means for
addressing source and destination TCPs in different networks. The
internet protocol also deals with any fragmentation or reassembly of
the TCP segments required to achieve transport and delivery through
multiple networks and interconnecting gateways. The internet protocol
also carries information on the precedence, security classification
and compartmentation of the TCP segments, so this information can be
communicated end-to-end across multiple networks.
TCPは[1]で最初にCerfとカーンによって記述されたコンセプトに基づいている。
TCPは基本的なインターネット・プロトコル[2]の上に層のプロトコルアーキテ
クチャに適切である、それは情報の可変長部分がインターネットデータグラム
「エンベロープ」に囲まれたTCPを送受信する方法を供給する。インターネット
データグラムは異なったネットワークで発信と着信TCPを扱うことに対して手
段を供給する。インターネット・プロトコルは、多数のネットワークと相互接
続のゲートウェイを通して輸送と配送が要求される、TCP部分について断片化と
組み立てを扱う。インターネット・プロトコルは同じくTCP部分の優先順位につ
いての情報、安全の格付けと仕分けを伴う、それで情報は多数のネットワーク
を横切って伝達されエンドツーエンドであり得る。
Protocol Layering
プロトコルの重なり
+---------------------+
| higher-level |
+---------------------+
| TCP |
+---------------------+
| internet protocol |
+---------------------+
|communication network|
+---------------------+
Figure 1
図1
Much of this document is written in the context of TCP implementations
which are co-resident with higher level protocols in the host
computer. Some computer systems will be connected to networks via
front-end computers which house the TCP and internet protocol layers,
as well as network specific software. The TCP specification describes
an interface to the higher level protocols which appears to be
implementable even for the front-end case, as long as a suitable
host-to-front end protocol is implemented.
このドキュメントの多くがホストコンピュータの高位レベルプロトコルと共同
居住者であるTCP実装という環境で書かれる。若干のコンピュータシステムが、
ネットワーク特定ソフトウェアと同様に、TCPとインターネット・プロトコル
レイヤを収容するフロントエンドコンピュータによってネットワークに接続す
るであろう。TCP仕様は、適当なホストからフロントエンドへプロトコルが実
行される限り、フロントエンドケースでさえ実装可能であるように思われる高
レベルプロトコルへのインタフェースを記述する。
1.2. Scope
範囲
The TCP is intended to provide a reliable process-to-process
communication service in a multinetwork environment. The TCP is
intended to be a host-to-host protocol in common use in multiple
networks.
TCPはマルチネットワーク環境で信頼できるプロセス対プロセス通信サービス
を供給するように意図される。TCPは多数のネットワークで共通使用のホスト
対ホストプロトコルであるように意図される。
1.3. About this Document
このドキュメントについて
This document represents a specification of the behavior required of
any TCP implementation, both in its interactions with higher level
protocols and in its interactions with other TCPs. The rest of this
section offers a very brief view of the protocol interfaces and
operation. Section 2 summarizes the philosophical basis for the TCP
design. Section 3 offers both a detailed description of the actions
required of TCP when various events occur (arrival of new segments,
user calls, errors, etc.) and the details of the formats of TCP
segments.
このドキュメントはどんなTCP実装にも要求される、高位レベルプロトコルと
の相互作用と他のTCPとの相互作用の、挙動の仕様を表す。このセクションの
残りがプロトコルインタフェースとオペレーションの非常に短い考察を提供
する。セクション２がTCPデザインのために哲学的な基準を要約する。セクショ
ン３が種々のイベント（新しい部分の到着、ユーザ呼出、エラーなど）が起
こる時TCPの必要とされる活動の詳細な記載そしてTCP部分のフォーマットの
細部を提供する。
1.4. Interfaces
インタフェース
The TCP interfaces on one side to user or application processes and on
the other side to a lower level protocol such as Internet Protocol.
TCPは片側はユーザあるいはアプリケーションプロセスに、そして他の側はイン
ターネットプロトコルのようなより下位レベルプロトコルに接続する。
The interface between an application process and the TCP is
illustrated in reasonable detail. This interface consists of a set of
calls much like the calls an operating system provides to an
application process for manipulating files. For example, there are
calls to open and close connections and to send and receive data on
established connections. It is also expected that the TCP can
asynchronously communicate with application programs. Although
considerable freedom is permitted to TCP implementors to design
interfaces which are appropriate to a particular operating system
environment, a minimum functionality is required at the TCP/user
interface for any valid implementation.
アプリケーションプロセスとTCPの間のインタフェースは妥当な詳細で説明さ
れる。このインタフェースは、オペレーティング・システムがアプリケーショ
ンプロセスにファイル操作を供給するたくさんの呼出しのような、呼出しの
集合から成り立つ。例えば、接続を開いたり閉じたり、そしてそして確立さ
れた接続上でデータを送信したり受信したりする呼出しがある。TCPが非同期
にアプリケーションプログラムと通信することができると思われる。特定の
運用システム環境に適切なインタフェースを設計するためにかなりの自由度
がTCP実装者に認められるけれども、どんな妥当な実装に対しても最小の機能
がTCP／ユーザ・インタフェースで必要とされる。
The interface between TCP and lower level protocol is essentially
unspecified except that it is assumed there is a mechanism whereby the
two levels can asynchronously pass information to each other.
Typically, one expects the lower level protocol to specify this
interface. TCP is designed to work in a very general environment of
interconnected networks. The lower level protocol which is assumed
throughout this document is the Internet Protocol [2].
TCPとより下位レベルプロトコルの間のインタフェースは、２つのレベルがお
互いに非同期に情報を渡すことができるメカニズムがあると想定されること以
外、本質的に特定されていない。一般に、下位レベルプロトコルがこのインタ
フェースに規定されることを期待する。TCPが相互に結び付けられたネットワー
クの非常に一般的な環境で働くよう意図される。このドキュメントを通じて仮
定されるより低いレベルプロトコルはインターネット・プロトコル[2]である。
1.5. Operation
オペレーション
As noted above, the primary purpose of the TCP is to provide reliable,
securable logical circuit or connection service between pairs of
processes. To provide this service on top of a less reliable internet
communication system requires facilities in the following areas:
上記の通り、TCPの主要な目的はプロセスの対の間に信頼性が高い、安心な論理
回路あるいは接続サービスを供給することである。低い信頼性のインターネット
通信システムの上にこのサービスを供給するには次のエリアで機能を必要とする：
Basic Data Transfer 基本データ転送
Reliability 安定性
Flow Control フロー制御
Multiplexing 多重送信
Connections 接続
Precedence and Security 優先順位と安全
The basic operation of the TCP in each of these areas is described in
the following paragraphs.
これらのエリアのそれぞれでのTCPの基本操作は次の段落で記述される。
Basic Data Transfer:
基本データ転送：
The TCP is able to transfer a continuous stream of octets in each
direction between its users by packaging some number of octets into
segments for transmission through the internet system. In general,
the TCPs decide when to block and forward data at their own
convenience.
TCPはインターネットシステムを通して送信セグメントの中にあるオクテッ
トの番号をパッケージすることによってそのユーザの間にそれぞれの方角
でオクテットの絶え間がないストリームを移すことが可能である。一般に、
TCPはそれら自身の都合でいつデータを止めて、いつ転送するべきか決める。
Sometimes users need to be sure that all the data they have
submitted to the TCP has been transmitted. For this purpose a push
function is defined. To assure that data submitted to a TCP is
actually transmitted the sending user indicates that it should be
pushed through to the receiving user. A push causes the TCPs to
promptly forward and deliver data up to that point to the receiver.
The exact push point might not be visible to the receiving user and
the push function does not supply a record boundary marker.
しばしばユーザはTCPに提出したすべてのデータを伝達したか確かめる必要が
ある。この目的のために後押し機能が定義される。TCPに提出されたデータが
実際に伝達されることを確実にするために、送信ユーザは受信ユーザに完全
に押し付けるべきであることを表す。ひと押しが受信者への即座のデータ転
送と配達するTCPを起こす。正確な後押しポイントは受け取っているユーザに
見えないかも知れない、そして後押し機能はレコード境界標識を供給しない。
Reliability:
安定性：
The TCP must recover from data that is damaged, lost, duplicated, or
delivered out of order by the internet communication system. This
is achieved by assigning a sequence number to each octet
transmitted, and requiring a positive acknowledgment (ACK) from the
receiving TCP. If the ACK is not received within a timeout
interval, the data is retransmitted. At the receiver, the sequence
numbers are used to correctly order segments that may be received
out of order and to eliminate duplicates. Damage is handled by
adding a checksum to each segment transmitted, checking it at the
receiver, and discarding damaged segments.
TCPはインターネット通信システムによる損害、損失、重複、あるいは不配
を与えられるデータから回復しなくてはならない。これはシーケンス番号を
それぞれの伝達されたオクテットに割り当てて、そして受信TCPから確かな
確認（ACK）を必要とすることによって達せられる。もしACKがタイムアウト
間隔内に受け取られないなら、データは再び送られる。受信器において、
シーケンス番号は順番に送られないかもしれないセグメントの正確な順序と
重複を削除するために使われる。それぞれの伝達されたセグメントにチェッ
クサムを加えて、受信器においてそれをチェックして、そして損害を与えら
れたセグメントを捨てることによって、害損が処理される。
As long as the TCPs continue to function properly and the internet
system does not become completely partitioned, no transmission
errors will affect the correct delivery of data. TCP recovers from
internet communication system errors.
TCPが正確に機能し続け、そしてインターネットシステムが完全に分割され
ないかぎり、伝送エラーがデータの正しい配送に影響を与えないであろう。
TCPがインターネット通信システムエラーから回復する。
Flow Control:
フロー制御：
TCP provides a means for the receiver to govern the amount of data
sent by the sender. This is achieved by returning a "window" with
every ACK indicating a range of acceptable sequence numbers beyond
the last segment successfully received. The window indicates an
allowed number of octets that the sender may transmit before
receiving further permission.
TCPが受信者のために送信者によって送られるデータ量を抑制する手段を供
給する。これはすべてのACKで「ウインドウ」を返すことによって達せられ
る、ACKは正しく受け取ったセグメントとさらに受入れ可能なシーケンス番
号の範囲をを示す。ウインドウは送信者が、送信者からの許可を受け取る
前に伝達を許されたオクテット数を示す。
Multiplexing:
多重送信：
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network
and host addresses from the internet communication layer, this forms
a socket. A pair of sockets uniquely identifies each connection.
That is, a socket may be simultaneously used in multiple
connections.
ひとつのホスト内の同時にTCP通信施設を使うで多くのプロセスを考慮する
ため、TCPはそれぞれのホストの中でアドレスあるいはポートのセットを供
給する。インターネットコミュニケーションレイヤから得られるネットワー
クアドレスとホストアドレスと連結して、これはソケットを形成する。１
対のソケットがユニークにそれぞれの接続を識別する。すなわち、ソケット
が多重接続で同時に使われるだろう。
The binding of ports to processes is handled independently by each
Host. However, it proves useful to attach frequently used processes
(e.g., a "logger" or timesharing service) to fixed sockets which are
made known to the public. These services can then be accessed
through the known addresses. Establishing and learning the port
addresses of other processes may involve more dynamic mechanisms.
プロセスとポートの結び付けはそれぞれのホストによって独立して処理され
る。しかし、しばしば有用なプロセス（例えば、「ログ」あるいはタイムシェ
アリングサービス）を既知の固定したソケットに置くことは便利であると分
かる。これらのサービスはその時既知のアドレスを通じてアクセスできる。
他のプロセスのポートアドレスを開設して、そして学習するには動的な機構
を必要とするかも知れない。
Connections:
接続：
The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for
each data stream. The combination of this information, including
sockets, sequence numbers, and window sizes, is called a connection.
Each connection is uniquely specified by a pair of sockets
identifying its two sides.
上記の安定性とフロー制御機構は、TCPがそれぞれのデータストリームのた
めにある特定のステータス情報を初期化して持続することを要求する。ソ
ケット、シーケンス番号とウインドウサイズを含む情報の結合は接続と呼ば
れる。それぞれの接続がユニークにその２つの端を識別しているソケットの
対によって規定される。
When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.
２つのプロセスが通信することを望む時、それらのTCPのは最初に接続を確
立し（それぞれの端のステータス情報を初期化する）なければならな。それ
らの通信が完了した時、接続は他の使用のため資源を解放するために終えら
れるか、閉じられる。
Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid
erroneous initialization of connections.
接続が当てにならないホストの間にそして当てにならないインターネット通
信システムの上に確立されなくてはならないので、時計ベースのシーケンス
番号を使うハンドシェイクメカニズムが接続の誤た初期設定を避けるために
使われる。
Precedence and Security:
優先順位と安全：
The users of TCP may indicate the security and precedence of their
communication. Provision is made for default values to be used when
these features are not needed.
TCPのユーザは安全とそれらの通信の優先順位を示してもよい。これらのフュー
チャが必要とされない時、使用するデフォルト値が供給される。
2. PHILOSOPHY
哲学
2.1. Elements of the Internetwork System
インターネットワークシステムの要素
The internetwork environment consists of hosts connected to networks
which are in turn interconnected via gateways. It is assumed here
that the networks may be either local networks (e.g., the ETHERNET) or
large networks (e.g., the ARPANET), but in any case are based on
packet switching technology. The active agents that produce and
consume messages are processes. Various levels of protocols in the
networks, the gateways, and the hosts support an interprocess
communication system that provides two-way data flow on logical
connections between process ports.
インターネットワーク環境はゲートウェイによって順に相互に結び付けられる
ネットワークとネットワークに接続したホストから成り立つ。ネットワークは
ローカルネットワーク（例えばイーサネット）かもしれないし、あるいは大き
いネットワーク（例えば、ARPANET）かも知れない、しかしどんなケースでで
もパケット交換工学に基づくことが想定される。メッセージを作り出して、そ
して消費する活動中のエージェントはプロセスである。ネットワーク、ゲート
ウェイとホストでのプロトコルのさまざまなレベルで、プロセスポート間に論
理接続上の双方向データフローを供給する、プロセス間通信システムがサポー
トされる。
The term packet is used generically here to mean the data of one
transaction between a host and its network. The format of data blocks
exchanged within the a network will generally not be of concern to us.
用語パケットはここではホストとそのネットワークの間の１つの取引きのデー
タを意味するために総称で使われる。ネットワークの中で交換されたデータブ
ロックのフォーマットは一般に我々に関心事ではないであろう。
Hosts are computers attached to a network, and from the communication
network's point of view, are the sources and destinations of packets.
Processes are viewed as the active elements in host computers (in
accordance with the fairly common definition of a process as a program
in execution). Even terminals and files or other I/O devices are
viewed as communicating with each other through the use of processes.
Thus, all communication is viewed as inter-process communication.
ホストがネットワークに接続したコンピュータであって、そして通信網の見地
から、パケットの発信者と着信者である。プロセスがホストコンピュータ（プ
ロセスのかなり普通の定義、プログラムの実行で）で能動素子だと見なされる。
端末とファイルあるいは他のＩ／Ｏデバイスさえプロセスの使用を通してお互
いに通信するとして見なされる。それで、すべての通信がプロセス間通信だと
見なされる。
Since a process may need to distinguish among several communication
streams between itself and another process (or processes), we imagine
that each process may have a number of ports through which it
communicates with the ports of other processes.
プロセスがそれ自身と他のプロセスの間のいくつかの通信ストリームを区別す
る必要があるかも知れないので、我々はそれぞれのプロセスが他のプロセスの
ポートと通信するいくつかのポートを持っているかも知れないと想像する。
2.2. Model of Operation
オペレーションのモデル
Processes transmit data by calling on the TCP and passing buffers of
data as arguments. The TCP packages the data from these buffers into
segments and calls on the internet module to transmit each segment to
the destination TCP. The receiving TCP places the data from a segment
into the receiving user's buffer and notifies the receiving user. The
TCPs include control information in the segments which they use to
ensure reliable ordered data transmission.
プロセスがTCPを呼び出して、そしてデータバッファーを引き数として渡すこと
でデータを伝達する。TCPはこれらのバッファーからセグメントの中にデータを
パッケージする。そしてインターネットモジュールに着側TCPへそれぞれのセグ
メントを伝達することを求める。着側TCPは受信ユーザのバッファーの中にセグ
メントからのデータを置いて、そして着側ユーザに通知する。TCPはセグメント
に信頼できる順序づけられたデータ伝送を保証するために使う制御情報を含む。
The model of internet communication is that there is an internet
protocol module associated with each TCP which provides an interface
to the local network. This internet module packages TCP segments
inside internet datagrams and routes these datagrams to a destination
internet module or intermediate gateway. To transmit the datagram
through the local network, it is embedded in a local network packet.
インターネット通信のモデルはローカルネットワークへのインタフェースを供
給するそれぞれのTCPと結び付けられたインターネットプロトコルモジュール
があるということである。このインターネットモジュールはインターネットデー
タグラムの中にTCPセグメントをパッケージして、そして着信インターネット
モジュールあるいは中間ゲートウェイにデータグラムの経路を決める。ローカ
ルネットワークを通してデータグラムを伝達するために、それはローカルネッ
トワークパケットに埋めこまれる。
The packet switches may perform further packaging, fragmentation, or
other operations to achieve the delivery of the local packet to the
destination internet module.
パケット交換は着信インターネットモジュールにローカルパケットの配送を行
うためさらなるパッケージ、分割、あるいは他の操作を行うかも知れない。
At a gateway between networks, the internet datagram is "unwrapped"
from its local packet and examined to determine through which network
the internet datagram should travel next. The internet datagram is
then "wrapped" in a local packet suitable to the next network and
routed to the next gateway, or to the final destination.
ネットワークの間のゲートウェイにおいて、インターネットデータグラムはそ
のローカルパケットから「包みを解かれて」、そして次にいずれのネットワー
クへインターネットデータグラムが移動するべきか決定するために調べられる。
インターネットデータグラムは次のネットワークに適したローカルパケットで
「くるまれて」、そして次のゲートウェイに、あるいは最終宛先に経路を決め
られる。
A gateway is permitted to break up an internet datagram into smaller
internet datagram fragments if this is necessary for transmission
through the next network. To do this, the gateway produces a set of
internet datagrams; each carrying a fragment. Fragments may be
further broken into smaller fragments at subsequent gateways. The
internet datagram fragment format is designed so that the destination
internet module can reassemble fragments into internet datagrams.
ゲートウェイは、もし次のネットワークを通した送信に必要であるなら、より
小さいインターネットデータグラムフラグメントの中にインターネットデータ
グラムを分割するのを許される。これをするため、ゲートウェイはそれぞれフ
ラグメントを運んでいるインターネットデータグラムの集合を作り出す。フラ
グメントが次のゲートウェイにおいてより小さいフラグメントにさらに砕かれ
るかも知れない。インターネットデータグラムフラグメントフォーマットは、
着信インターネットモジュールがインターネットデータグラムのフラグメント
を組み立てることができるように、設計される。
A destination internet module unwraps the segment from the datagram
(after reassembling the datagram, if necessary) and passes it to the
destination TCP.
着信インターネットモジュールが（もし必要であるなら、データグラムを組み
立てた後で）データグラムからセグメントの包みを解いて、そして着信TCPに
それを渡す。
This simple model of the operation glosses over many details. One
important feature is the type of service. This provides information
to the gateway (or internet module) to guide it in selecting the
service parameters to be used in traversing the next network.
Included in the type of service information is the precedence of the
datagram. Datagrams may also carry security information to permit
host and gateways that operate in multilevel secure environments to
properly segregate datagrams for security considerations.
このオペレーションの単純モデルは多くの細部をうまく言い逃れる。１つの
重要な特徴はサービス種別である。これは次に使用するネットワークを選ぶ
際に使われるサービスパラメータとしてゲートウェイ（あるいはインターネッ
トモジュール）に情報を供給する。データグラムの優先順位がサービス種別
情報に含められる。データグラムが許可ホストに同じくセキュリティ情報を
運ぶかも知れない、そしてマルチレベルで稼働するゲートウェイが機密保持
対策のために正確にデータグラムを分離できる環境を保証する。
2.3. The Host Environment
ホスト環境
The TCP is assumed to be a module in an operating system. The users
access the TCP much like they would access the file system. The TCP
may call on other operating system functions, for example, to manage
data structures. The actual interface to the network is assumed to be
controlled by a device driver module. The TCP does not call on the
network device driver directly, but rather calls on the internet
datagram protocol module which may in turn call on the device driver.
TCPはオペレーティング・システムでモジュールであると考えられる。ユーザ
は、ファイルシステムにアクセスにするかのように、TCPにアクセスする。TCP
は、例えば、データ構造を処理するために他のオペレーティングシステム関数
をコールするかも知れない。ネットワークへの実際のインタフェースはデバイ
ス・ドライバモジュールによってコントロールされると考えられる。TCPは直
接ネットワークデバイス・ドライバを呼び出さず、デバイス駆動装置を呼び出
であろうインターネットデータグラムプロトコルモジュールを呼出す。
The mechanisms of TCP do not preclude implementation of the TCP in a
front-end processor. However, in such an implementation, a
host-to-front-end protocol must provide the functionality to support
the type of TCP-user interface described in this document.
TCP構造はフロントエンドプロセッサにTCPを実装するのをを妨げない。しかし、
このような実装では、フロントエンド対ホストプロトコルがこのドキュメント
で記述されたTCPユーザ・インタフェースをサポートする機能を供給しなくて
はならない。
2.4. Interfaces
インタフェース
The TCP/user interface provides for calls made by the user on the TCP
to OPEN or CLOSE a connection, to SEND or RECEIVE data, or to obtain
STATUS about a connection. These calls are like other calls from user
programs on the operating system, for example, the calls to open, read
from, and close a file.
TCP／ユーザ・インタフェースは、TCP上でユーザの作った呼に対し、接続を開
いたり閉じたり、データを送信したり受信したり、あるいは接続状態の取得を
供給する。これらの呼出しはオペレーティングシステムの上のユーザプログラ
ムからの他の呼出し、例えば、ファイルを開いて読んで閉じる呼出しのようで
ある。
The TCP/internet interface provides calls to send and receive
datagrams addressed to TCP modules in hosts anywhere in the internet
system. These calls have parameters for passing the address, type of
service, precedence, security, and other control information.
TCP／インターネットインタフェースは、インターネットシステムのどこにあ
るホストでも、TCPモジュール宛のデータグラムを送受する呼出しを供給する。
これらの呼出しはアドレス、サービスの種別、優先順位、安全と他の制御情
報を渡すパラメータを持っている。
2.5. Relation to Other Protocols
他のプロトコルへの関係
The following diagram illustrates the place of the TCP in the protocol
hierarchy:
次のダイアグラムはプロトコル階層におけるTCPの位置を説明する：
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | |Voice| ... | | Application Level
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | RTP | ... | | Host Level
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol & ICMP | Gateway Level
+-------------------------------+
|
+---------------------------+
| Local Network Protocol | Network Level
+---------------------------+
Protocol Relationships
プロトコル関係
Figure 2.
図2.
It is expected that the TCP will be able to support higher level
protocols efficiently. It should be easy to interface higher level
protocols like the ARPANET Telnet or AUTODIN II THP to the TCP.
TCPが効率的に上位レベルプロトコルをサポートすることが可能であると思わ
れる。TCPにARPANET TelnetあるいはAUTODIN II THPのような上位レベルプロ
トコルを接続することは容易であるべきである。
2.6. Reliable Communication
信頼できる通信
A stream of data sent on a TCP connection is delivered reliably and in
order at the destination.
TCP接続の上に送られたデータの流れが着信において信頼できるように、そして
順番になるように配達される。
Transmission is made reliable via the use of sequence numbers and
acknowledgments. Conceptually, each octet of data is assigned a
sequence number. The sequence number of the first octet of data in a
segment is transmitted with that segment and is called the segment
sequence number. Segments also carry an acknowledgment number which
is the sequence number of the next expected data octet of
transmissions in the reverse direction. When the TCP transmits a
segment containing data, it puts a copy on a retransmission queue and
starts a timer; when the acknowledgment for that data is received, the
segment is deleted from the queue. If the acknowledgment is not
received before the timer runs out, the segment is retransmitted.
シーケンス番号と確認応答の使用によって伝送の信頼性を高くする。概念的に、
それぞれのデータのオクテットにシーケンス番号を割り当てる。セグメントで
のデータの最初のオクテットのシーケンス番号はそのセグメントで伝達されて、
そしてセグメントシーケンス番号と呼ばれる。逆方向のセグメントで同じく次
の送信が期待されるデータオクテットのシーケンス番号である確認番号を運ぶ。
TCPがデータを含んでいるセグメントを伝達する時、再送待ち行列の上にコピー
を置いて、タイマを始動させる；そのデータの確認応答が受け取られると、セ
グメントは待ち行列から削除される。もし確認応答が、タイムアウト前に、受
け取られないなら、セグメントは再び送られる。
An acknowledgment by TCP does not guarantee that the data has been
delivered to the end user, but only that the receiving TCP has taken
the responsibility to do so.
TCPによる確認応答は、受信TCPが応答をしただけであり、データがエンドユー
ザに届けられたことを保証するのではない。
To govern the flow of data between TCPs, a flow control mechanism is
employed. The receiving TCP reports a "window" to the sending TCP.
This window specifies the number of octets, starting with the
acknowledgment number, that the receiving TCP is currently prepared to
receive.
TCP間のデータの流れを抑制するために、フロー制御機構が用いられている。
受信TCPは「ウィンドウ」を送信TCPに報告する。このウインドウは受信TCPが
現在受け取る用意ができている、確認番号から始まる、オクテット数を指定する。
2.7. Connection Establishment and Clearing
接続の確立とクリア
To identify the separate data streams that a TCP may handle, the TCP
provides a port identifier. Since port identifiers are selected
independently by each TCP they might not be unique. To provide for
unique addresses within each TCP, we concatenate an internet address
identifying the TCP with a port identifier to create a socket which
will be unique throughout all networks connected together.
TCPが取扱うであろう別のデータストリームを識別するために、TCPはポート識
別子を供給する。ポート識別子がそれぞれのTCPによって独立して選ばれるの
で、それらはユニークではないかも知れない。それぞれのTCPで固有のアドレ
スを供給するために、我々はすべての接続されたネットワークを通じてユニー
クであるであろうソケットを作るため、TCPを識別するインターネットアドレ
スとポート識別子を連結する。
A connection is fully specified by the pair of sockets at the ends. A
local socket may participate in many connections to different foreign
sockets. A connection can be used to carry data in both directions,
that is, it is "full duplex".
接続が両端の１対のソケットによって完全に規定される。ローカルソケットが
異なった外の多くのソケットと接続するかも知れない。接続が両方向でデータ
を運ぶために使うことができる、すなわち「全二重」である。
TCPs are free to associate ports with processes however they choose.
However, several basic concepts are necessary in any implementation.
There must be well-known sockets which the TCP associates only with
the "appropriate" processes by some means. We envision that processes
may "own" ports, and that processes can initiate connections only on
the ports they own. (Means for implementing ownership is a local
issue, but we envision a Request Port user command, or a method of
uniquely allocating a group of ports to a given process, e.g., by
associating the high order bits of a port name with a given process.)
TCPはプロセスがポートを選択するのに関して、プロセスがどんな選択をする
として、自由である。しかしながら、いくつかの基本概念はどんな実装ででも
必要である。ある手段によって「適切な」プロセスとだけ結び付く知られてい
るソケットがあるだろう。我々はプロセスがポートを「所有する」し、そして
プロセスがそれらが所有するポートだけで接続を開始できることを想定する。
（所有権を実行するための手段はローカルな問題である、しかし我々はポート
要求ユーザコマンド、あるいは例えばポート名の上位ビットをプロセスと結び
付けるなど、プロセスへユニークにポートのグループを割り当てる手順を想像
する。）
A connection is specified in the OPEN call by the local port and
foreign socket arguments. In return, the TCP supplies a (short) local
connection name by which the user refers to the connection in
subsequent calls. There are several things that must be remembered
about a connection. To store this information we imagine that there
is a data structure called a Transmission Control Block (TCB). One
implementation strategy would have the local connection name be a
pointer to the TCB for this connection. The OPEN call also specifies
whether the connection establishment is to be actively pursued, or to
be passively waited for.
接続が自局側ポートと外のソケットを引数としたOPEN呼出で指定される。応答
でTCPは、ユーザが次の呼出しで接続を参照する短いローカル接続名を供給する。
接続に関する記憶されなくてはならないものがいくつかある。この情報を記憶
するために、我々は送信制御ブロック（TCB）と呼ばれたデータ構造があると想
像する。ある実現方法ではローカル接続名がこの接続のためのTCBへのポインタ
であるであろう。OPEN呼出は、接続の確立が積極的に行われるかあるいは受動
的に待つか否かにかかわらず、同じく指定する。
A passive OPEN request means that the process wants to accept incoming
connection requests rather than attempting to initiate a connection.
Often the process requesting a passive OPEN will accept a connection
request from any caller. In this case a foreign socket of all zeros
is used to denote an unspecified socket. Unspecified foreign sockets
are allowed only on passive OPENs.
受動的なオープン要求はプロセスが接続を始めようと試みるのでなく、むしろ
入接続の要請を受け入れることを望むことを意味する。しばしば受動的なオー
プンを求めているプロセスはどんな発呼者からでも接続要求を受け入れるであ
ろう。この場合オールゼロの外のソケットが特定されていないソケットを示す
ために使われる。特定されていない外のソケットが受動的なオープンのためだ
けに許される。
A service process that wished to provide services for unknown other
processes would issue a passive OPEN request with an unspecified
foreign socket. Then a connection could be made with any process that
requested a connection to this local socket. It would help if this
local socket were known to be associated with this service.
未知の他のプロセスにサービスを提供することを望んだサービスプロセスが特
定されていない外のソケットで受動的なオープン要求を発行するであろう。こ
のローカルソケットに接続を求めたどんなプロセスからでも接続ができる。も
しこのローカルソケットがこのサービスと結び付けられることが知られている
なら、役立つであろう。
Well-known sockets are a convenient mechanism for a priori associating
a socket address with a standard service. For instance, the
"Telnet-Server" process is permanently assigned to a particular
socket, and other sockets are reserved for File Transfer, Remote Job
Entry, Text Generator, Echoer, and Sink processes (the last three
being for test purposes). A socket address might be reserved for
access to a "Look-Up" service which would return the specific socket
at which a newly created service would be provided. The concept of a
well-known socket is part of the TCP specification, but the assignment
of sockets to services is outside this specification. (See [4].)
よく知られているソケットがソケットアドレスを標準サービスと結び付けるた
めの都合が良いメカニズムである。例えば、「Telnetサーバー」プロセスは永
久に特定なソケットに割り当てられる、そして他のソケットはファイル転送、
遠隔ジョブ入力、テキスト生成プログラム、エコー、シンクのプロセスために
予約される（最後の３つはテスト目的である）。ソケットアドレスが新たに作
られたサービスが供給する特定のソケットを返す「検索」サービスのアクセス
のために確保されるかも知れない。よく知られているソケットのコンセプトは
TCP仕様の一部である、しかしサービスへのソケットの割当てはこの仕様の範
囲外である。（[4]を参照）
Processes can issue passive OPENs and wait for matching active OPENs
from other processes and be informed by the TCP when connections have
been established. Two processes which issue active OPENs to each
other at the same time will be correctly connected. This flexibility
is critical for the support of distributed computing in which
components act asynchronously with respect to each other.
プロセスが受動的なオープンを発行でき、そして他のプロセスから一致してい
る有効なオープンを待って、接続が確立された時、TCPによって知らせられる。
同時にお互いに有効なオープンを発行する２つのプロセスは正確に接続される
であろう。この柔軟性は構成要素がお互いに非同期に動作する分散計算のサポー
トのために重要である。
There are two principal cases for matching the sockets in the local
passive OPENs and an foreign active OPENs. In the first case, the
local passive OPENs has fully specified the foreign socket. In this
case, the match must be exact. In the second case, the local passive
OPENs has left the foreign socket unspecified. In this case, any
foreign socket is acceptable as long as the local sockets match.
Other possibilities include partially restricted matches.
ローカルな受動的なオープンと外の能動的なオープンがソケットで一致する２
つの主要なケースがある。最初のケースで、ローカルな受動態的オープンは完
全に外のソケットを指定した。この場合、マッチは正確であるに違いない。２
番目のケースで、ローカルな受動態的オープンは外のソケットを特定されてい
ないままにしておく。この場合、どんな外のソケットでも、ローカルソケット
に一致する限り限り、受け入れられる。他の可能性は部分的に限定された一致
を含む。
If there are several pending passive OPENs (recorded in TCBs) with the
same local socket, an foreign active OPEN will be matched to a TCB
with the specific foreign socket in the foreign active OPEN, if such a
TCB exists, before selecting a TCB with an unspecified foreign socket.
訳注：RFC誤植情報によると上記の"an foreign"は"a foreign"が正しいそうです。
もし同じローカルソケットに（TCBsで記録された）いくつかの保留中の受動的
なオープンがあるなら、外交のアクティブなオープンが、不特定の外来のソケッ
トのTCBを選ぶ前に、もしこのようなTCBがあれば、特定の外来のソケッのTCB
合わせられるであろう。
The procedures to establish connections utilize the synchronize (SYN)
control flag and involves an exchange of three messages. This
exchange has been termed a three-way hand shake [3].
接続を確立するために手順は同期（SYN）制御フラグを利用して、そして３つ
のメッセージの交換を必要とする。この交換はスリーウェイハンドシェイク
[3]と呼ばれる。
A connection is initiated by the rendezvous of an arriving segment
containing a SYN and a waiting TCB entry each created by a user OPEN
command. The matching of local and foreign sockets determines when a
connection has been initiated. The connection becomes "established"
when sequence numbers have been synchronized in both directions.
接続がそれぞれがユーザオープンコマンドによって作った待機中のTCBエントリ
と、SYNを含んでいる到着セグメントのランデブーによって始められる。ロー
カルと外来のソケットの一致は接続が開始を決定する。接続は、シーケンス番
号が両方の方角で同期した時「確定する」。
The clearing of a connection also involves the exchange of segments,
in this case carrying the FIN control flag.
接続を片付けることは同じくセグメントの交換が、この場合FIN制御フラグを
運ぶのを必要とする。
2.8. Data Communication
データ通信
The data that flows on a connection may be thought of as a stream of
octets. The sending user indicates in each SEND call whether the data
in that call (and any preceeding calls) should be immediately pushed
through to the receiving user by the setting of the PUSH flag.
接続の上に流れ出るデータはオクテットの流れであると考えられるかも知れな
い。送信ユーザはSEND呼び出しでその呼出（と待機中の呼出）内ののデータが
PUSHフラグの設定によって受信ユーザにすぐに送信されるべきであるかどうか
示す。
A sending TCP is allowed to collect data from the sending user and to
send that data in segments at its own convenience, until the push
function is signaled, then it must send all unsent data. When a
receiving TCP sees the PUSH flag, it must not wait for more data from
the sending TCP before passing the data to the receiving process.
送信TCPが、後押し機能が示されるまで、送信ユーザからデータを集めて、そ
れ自身の都合がいいときにそのセグメント内のデータを送ることが許される。
後押し機能が示される時、全ての未送信データを送らなくてはならない。受信
TCPがPUSHフラグを見る時、それは受信プロセスにデータを渡す前に送信TCPか
ら後のデータを待ってはならない。
There is no necessary relationship between push functions and segment
boundaries. The data in any particular segment may be the result of a
single SEND call, in whole or part, or of multiple SEND calls.
プッシュ機能とセグメント境界の間に必要な関係がない。どんなセグメントの
データでもこれはひとつのSEND呼び出しの、全体あるいは部分かもしれないし、
あるいは多数のSEND呼び出しの結果であるかも知れない。
The purpose of push function and the PUSH flag is to push data through
from the sending user to the receiving user. It does not provide a
record service.
プッシュ機能とPUSHフラグの目的は送信ユーザから受信ユーザまで完全にデー
タを押すことである。それはレコードサービスを供給しない。
There is a coupling between the push function and the use of buffers
of data that cross the TCP/user interface. Each time a PUSH flag is
associated with data placed into the receiving user's buffer, the
buffer is returned to the user for processing even if the buffer is
not filled. If data arrives that fills the user's buffer before a
PUSH is seen, the data is passed to the user in buffer size units.
プッシュ機能とTCP／ユーザ・インタフェース間のデータのバッファーの使用
の間に関係がある。PUSHフラグが受信ユーザのバッファーの中に置かれてデー
タと結び付けられるたびに、バッファーは、たとえバッファが満たされない
としても、処理のためにユーザに返される。もし、プッシュが起こる前に、
ユーザのバッファを満たすデータが到着するなら、データはバッファサイズ
単位でユーザにパスする。
TCP also provides a means to communicate to the receiver of data that
at some point further along in the data stream than the receiver is
currently reading there is urgent data. TCP does not attempt to
define what the user specifically does upon being notified of pending
urgent data, but the general notion is that the receiving process will
take action to process the urgent data quickly.
TCPが同じくデータの受信者に、受信者が現在読んでいるある時点で送られた
データストリームより、緊急のデータがあると伝える手段を供給する。TCPが
ユーザが保留中の緊急のデータを通知された場合に、特に何をするか定義しな
い、しかし一般的な見解は受信プロセスが速く緊急のデータを処理する行動を
とるであろうということである。
2.9. Precedence and Security
優先順位と安全
The TCP makes use of the internet protocol type of service field and
security option to provide precedence and security on a per connection
basis to TCP users. Not all TCP modules will necessarily function in
a multilevel secure environment; some may be limited to unclassified
use only, and others may operate at only one security level and
compartment. Consequently, some TCP implementations and services to
users may be limited to a subset of the multilevel secure case.
TCPはインターネットプロトコルタイプオブサービスフィールドと優先順位と
安全を供給する安全オプションを,TCPユーザ基づきに接続単位で利用する。
すべてのTCPモジュールがマルチレベル安全環境機能を望むわけではない；い
くらかは機密扱いでない使用のみに制限されるかも知れないし、そして他の
ものはある１つの安全レベルと隔離区画においてのみ稼働するかも知れない。
従って、あるユーザへのTCP実装とサービスが、マルチレベルの安全の部分に
制限をするだろう。
TCP modules which operate in a multilevel secure environment must
properly mark outgoing segments with the security, compartment, and
precedence. Such TCP modules must also provide to their users or
higher level protocols such as Telnet or THP an interface to allow
them to specify the desired security level, compartment, and
precedence of connections.
マルチレベルで安全な環境を操作するTCPモジュールが安全、隔室と優先順位
で正確に出て行くセグメントをマークしなくてはならない。このようなTCPモ
ジュールは同じくそれらのユーザあるいはTelnetあるいはTHPのようなもっと
レベルが高いプロトコルにそれらに望ましい安全レベル、隔室と接続の優先
順位を規定することを許すインタフェースを供給しなくてはならない。
2.10. Robustness Principle
安定原理
TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others.
TCP実装が安定の一般原則の従うであろう：あなたがすることは保守的であって、
あなたが他のものから受け入れるものについて寛大でありなさい。
3. FUNCTIONAL SPECIFICATION
機能仕様
3.1. Header Format
ヘッダーフォーマット
TCP segments are sent as internet datagrams. The Internet Protocol
header carries several information fields, including the source and
destination host addresses [2]. A TCP header follows the internet
header, supplying information specific to the TCP protocol. This
division allows for the existence of host level protocols other than
TCP.
TCPセグメントがインターネットデータグラムとして送られる。インターネッ
ト・プロトコルヘッダーは、発信と接続先ホストアドレス[2]を含めて、い
くつかの情報フィールドを運ぶ。TCPヘッダーがインターネットヘッダーの
後に続き、TCPプロトコルに特定の情報を供給している。この分離はTCP以
外のホストレベルプロトコルの存在を考慮する。
TCP Header Format
TCPヘッダーフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP Header Format
TCPヘッダーフォーマット
Note that one tick mark represents one bit position.
１目盛りが１ビット位置を表すことに注意しなさい。
Figure 3.
図３
Source Port: 16 bits
発信ポート：１６ビット
The source port number.
発信ポート番号。
Destination Port: 16 bits
着信ポート：１６ビット
The destination port number.
着信ポート番号。
Sequence Number: 32 bits
シーケンス番号：３２ビット
The sequence number of the first data octet in this segment (except
when SYN is present). If SYN is present the sequence number is the
initial sequence number (ISN) and the first data octet is ISN+1.
（SYNが存在している時を除いて）このセグメントでの最初のデータオクテッ
トのシーケンス番号。もしSYNが存在しているなら、シーケンス番号は最初
のシーケンス番号（ISN）である、そして最初のデータオクテットはISN＋１
である。
Acknowledgment Number: 32 bits
確認番号：３２ビット
If the ACK control bit is set this field contains the value of the
next sequence number the sender of the segment is expecting to
receive. Once a connection is established this is always sent.
もしACK制御ビットがセットされるなら、このフィールドはセグメントの送
り主が受け取ることを予期している次のシーケンス番号の値を含む。接続
が確立された以降は常に送られる。
Data Offset: 4 bits
データオフセット：４ビット
The number of 32 bit words in the TCP Header. This indicates where
the data begins. The TCP header (even one including options) is an
integral number of 32 bits long.
３２ビット単位のTCPヘッダの長さ。これはデータがどこでを始めるか示す。
TCPヘッダー（オプションを含めて）は３２ビット長の倍数である。
Reserved: 6 bits
予約済：６ビット
Reserved for future use. Must be zero.
未来の使用のために確保された。ゼロであるに違いない。
Control Bits: 6 bits (from left to right):
コントロールビット(ControlBits)：６ビット（左から右まで）：
URG: Urgent Pointer field significant
緊急ポインタフィールドに意味がある
ACK: Acknowledgment field significant
確認フィールドに意味がある
PSH: Push Function
プッシュ機能
RST: Reset the connection
接続をリセット
SYN: Synchronize sequence numbers
同期シーケンス番号
FIN: No more data from sender
これ以上の送信側からのデータがない
Window: 16 bits
ウインドウ：１６ビット
The number of data octets beginning with the one indicated in the
acknowledgment field which the sender of this segment is willing to
accept.
このセグメントの送信者が受信できる、確認フィールドで示されたものから
始まる、データオクテットの数。
Checksum: 16 bits
チェックサム：１６ビット
The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header and text. If a
segment contains an odd number of header and text octets to be
checksummed, the last octet is padded on the right with zeros to
form a 16 bit word for checksum purposes. The pad is not
transmitted as part of the segment. While computing the checksum,
the checksum field itself is replaced with zeros.
チェックサムフィールドはすべてのヘッダーとテキストの１６のビットワー
ドの１の補数合計を示す、16ビットの１の補数である。もしセグメントの
チェックサムされるべきヘッダーとテキストオクテットが奇数なら、最後の
オクテットはチェックサムの目的で16ビットのワードを形成するために右側
をゼロで埋められる。パッドはセグメントの一部として伝達されない。チェッ
クサムを計算する間、チェックサムフィールドそれ自身はゼロと取り替えら
れる。
The checksum also covers a 96 bit pseudo header conceptually
prefixed to the TCP header. This pseudo header contains the Source
Address, the Destination Address, the Protocol, and TCP length.
This gives the TCP protection against misrouted segments. This
information is carried in the Internet Protocol and is transferred
across the TCP/Network interface in the arguments or results of
calls by the TCP on the IP.
チェックサムは同じく概念的にTCPヘッダーに頭に付ける９６のビット疑似
ヘッダをカバーする。この疑似ヘッダは発アドレス、宛先アドレス、プロト
コルとTCP長を含んでいる。これは誤ったセグメントに対してTCP保護を与え
る。この情報はインターネット・プロトコルで運ばれて、そしてTCPによる
IP上の呼出の引数あるいは結果でTCP／ネットワークインタフェースの相手
側に移される。
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
The TCP Length is the TCP header length plus the data length in
octets (this is not an explicitly transmitted quantity, but is
computed), and it does not count the 12 octets of the pseudo
header.
TCP長は、オクテット単位でのTCPヘッダ長＋データ長である（これは明示
的に伝えられた量ではないが計算できる）で、そして疑似ヘッダの１２の
オクテットを数に入れない。
Urgent Pointer: 16 bits
緊急ポインタ：１６ビット
This field communicates the current value of the urgent pointer as a
positive offset from the sequence number in this segment. The
urgent pointer points to the sequence number of the octet following
the urgent data. This field is only be interpreted in segments with
the URG control bit set.
このフィールドは、このセグメントのシーケンス番号からの正のオフセット
として、緊急ポインタの現行値を伝達する。緊急ポインタは緊急のデータの
後に続くオクテット単位のシーケンス番号を指さす。このフィールドはURG制
御ビットが設定されているセグメントでのみ解釈される。
Options: variable
オプション：変数
Options may occupy space at the end of the TCP header and are a
multiple of 8 bits in length. All options are included in the
checksum. An option may begin on any octet boundary. There are two
cases for the format of an option:
オプションがTCPヘッダーの終わりの場所を占領するかも知れなくて、そして
長は８ビットの倍数である。すべてのオプションがチェックサムに含められ
る。オプションはどんなオクテット境界ででも始まるかも知れない。オプショ
ンのフォーマットは２つの場合がある：
Case 1: A single octet of option-kind.
場合１： 単独のオクテットのオプション種別。
Case 2: An octet of option-kind, an octet of option-length, and
the actual option-data octets.
場合２： オプション種別、オプション長の１オクテットと実際のオプショ
ンデータオクテット。
The option-length counts the two octets of option-kind and
option-length as well as the option-data octets.
オプション長は、オプションデータオクテットと同様、オプション種別とオ
プション長の２オクテットを含む。
Note that the list of options may be shorter than the data offset
field might imply. The content of the header beyond the
End-of-Option option must be header padding (i.e., zero).
オプションのリストがデータオフセットフィールドが暗示するより短いかも
知れないことに注意しなさい。「オプションのエンド」オプションの後のヘッ
ダーの内容はヘッダーパディング（すなわち、ゼロ）であるに違いない。
A TCP must implement all options.
TCPはすべてのオプションを実行しなくてはならない。
Currently defined options include (kind indicated in octal):
現在定義されたオプション（８進数表示の種別）：
Kind Length Meaning
種別 長さ 意味
---- ------ -------
0 - End of option list.
オプションリストのエンド
1 - No-Operation.
ノー−オペレーション
2 4 Maximum Segment Size.
最大のセグメント大きさ
Specific Option Definitions
詳細なオプション定義
End of Option List
オプションリストのエンド
+--------+
|00000000|
+--------+
Kind=0
This option code indicates the end of the option list. This
might not coincide with the end of the TCP header according to
the Data Offset field. This is used at the end of all options,
not the end of each option, and need only be used if the end of
the options would not otherwise coincide with the end of the TCP
header.
このオプションコードはオプションリストの終わりを示す。これはデー
タオフセットフィールドによるTCPヘッダーの終わりと一致しないかも
知れない。これは、それぞれのオプションの終わりではなく、すべての
オプションの終わりにおいて使われて、そして、もしオプションの終わ
りがTCPヘッダーの終わりと一致しない場合にのみ使うことが必要である。
No-Operation
ノー−オペレーション
+--------+
|00000001|
+--------+
Kind=1
This option code may be used between options, for example, to
align the beginning of a subsequent option on a word boundary.
There is no guarantee that senders will use this option, so
receivers must be prepared to process options even if they do
not begin on a word boundary.
このオプションコードは、例えば、ワード境界に次のオプションの初
めを整列させるためオプション間に使われるかも知れない。送信者が
このオプションを使うであろうという保証はない、それで受信者はた
とえワード境界に始まらないとしても、オプションを処理する用意が
できているに違いない。
Maximum Segment Size
最大のセグメント大きさ
+--------+--------+---------+--------+
|00000010|00000100| max seg size |
+--------+--------+---------+--------+
Kind=2 Length=4
Maximum Segment Size Option Data: 16 bits
最大のセグメント大きさオプションデータ：１６ビット
If this option is present, then it communicates the maximum
receive segment size at the TCP which sends this segment.
This field must only be sent in the initial connection request
(i.e., in segments with the SYN control bit set). If this
option is not used, any segment size is allowed.
もしこのオプションが存在しているなら、セグメントを送信するTCPの
受信セグメントの最大値を伝える。このフィールドは最初の接続要求
（すなわち、SYN制御ビットが設定されているセグメントで）のみで送
ることができる。もしこのオプションが使われないなら、どんなセグ
メントの大きさでも許される。
Padding: variable
パディング：変数
The TCP header padding is used to ensure that the TCP header ends
and data begins on a 32 bit boundary. The padding is composed of
zeros.
TCPヘッダーパディングはTCPヘッダーが終わる、そしてデータが32ビット
の境界の上に始まることを保証するために使われる。パディングはゼロで
構成されている。
3.2. Terminology
技術用語
Before we can discuss very much about the operation of the TCP we need
to introduce some detailed terminology. The maintenance of a TCP
connection requires the remembering of several variables. We conceive
of these variables being stored in a connection record called a
Transmission Control Block or TCB. Among the variables stored in the
TCB are the local and remote socket numbers, the security and
precedence of the connection, pointers to the user's send and receive
buffers, pointers to the retransmit queue and to the current segment.
In addition several variables relating to the send and receive
sequence numbers are stored in the TCB.
我々がTCPのオペレーションについて議論する前に、いくつかの詳細な技術用
語を紹介する必要がある。TCP接続の維持はいくつかの変数を覚えていること
を必要とする。我々は送信制御ブロックあるいはTCBと呼ばれた接続レコード
にストアされている変数を想定する。TCBにしまっておかれた変数は、ローカ
ルと遠隔ソケットナンバー、接続の安全と優先順位、ユーザの送信と受信の
バッファのへのポインタ、再送信待ち行列へのポインタと、現在のセグメン
トへのポインタである。さらにTBCに記憶される、送信と受信シーケンス番号
に関連するいくつかの変数である。
Send Sequence Variables
送信シーケンス変数
SND.UNA - send unacknowledged
- 送信未確認
SND.NXT - send next
- 次に送信
SND.WND - send window
- 送信ウインドウ
SND.UP - send urgent pointer
- 送信緊急ポインタ
SND.WL1 - segment sequence number used for last window update
- 最後のウインドウ更新のために使ったセグメントシーケンス番号。
SND.WL2 - segment acknowledgment number used for last window
update
- 最後のウインドウ更新のために使われたセグメント確認番号。
ISS - initial send sequence number
- 最初の送信シーケンス番号
Receive Sequence Variables
受信シーケンス変数
RCV.NXT - receive next
- 次に受信
RCV.WND - receive window
- 受信ウィンドウ
RCV.UP - receive urgent pointer
- 受信緊急ポインタ
IRS - initial receive sequence number
- 最初の受信シーケンス番号
The following diagrams may help to relate some of these variables to
the sequence space.
次のダイアグラムはシーケンス空間にこれらの変数を関連づける助けになる
かも知れない。
Send Sequence Space
送信シーケンス空間
1 2 3 4
----------|----------|----------|----------
SND.UNA SND.NXT SND.UNA
+SND.WND
1 - old sequence numbers which have been acknowledged
確認された古いシーケンス番号
2 - sequence numbers of unacknowledged data
確認されていないデータのシーケンス番号
3 - sequence numbers allowed for new data transmission
新しいデータ伝送が可能なシーケンス番号
4 - future sequence numbers which are not yet allowed
まだ伝送可能でない未来のシーケンス番号
Send Sequence Space
送信シーケンス空間
Figure 4.
図4.
The send window is the portion of the sequence space labeled 3 in
figure 4.
送信ウインドウは図４で３というレッテルをはられるシーケンス空間の部分で
ある。
Receive Sequence Space
受信シーケンス空間
1 2 3
----------|----------|----------
RCV.NXT RCV.NXT
+RCV.WND
1 - old sequence numbers which have been acknowledged
確認された古いシーケンス番号
2 - sequence numbers allowed for new reception
新しく受信が可能なシーケンス番号
3 - future sequence numbers which are not yet allowed
まだ受信できない未来のシーケンス番号
Receive Sequence Space
受信シーケンス空間
Figure 5.
図５
The receive window is the portion of the sequence space labeled 2 in
figure 5.
受信ウインドウは図５で２というレッテルをはられるシーケンス空間の部分
である。
There are also some variables used frequently in the discussion that
take their values from the fields of the current segment.
現在のセグメントのフィールドから値を取り出すある議論でしばしば使われ
る変数がある。
Current Segment Variables
現在のセグメント変数
SEG.SEQ - segment sequence number
セグメントシーケンス番号
SEG.ACK - segment acknowledgment number
セグメント確認番号
SEG.LEN - segment length
セグメント長
SEG.WND - segment window
セグメントウインドウ
SEG.UP - segment urgent pointer
セグメント緊急ポインタ
SEG.PRC - segment precedence value
セグメント優先値
A connection progresses through a series of states during its
lifetime. The states are: LISTEN, SYN-SENT, SYN-RECEIVED,
ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK,
TIME-WAIT, and the fictional state CLOSED. CLOSED is fictional
because it represents the state when there is no TCB, and therefore,
no connection. Briefly the meanings of the states are:
接続がそのライフタイムの間に一連の状態を通って進行する。状態はそうで
ある：LISTEN,SYN-SENT,SYN-RECEIVED,ESTABLISHED,FIN-WAIT-1,FIN-WAIT-2,
CLOSE-WAIT,CLOSING,LAST-ACK,TIME-WAIT、そして作り話状態CLOSED。CLOSED
はTCBがない時の状態を表すから作り話でそれ故に無接続である。手短かに状
態の意味はそうである：
LISTEN - represents waiting for a connection request from any remote
TCP and port.
LISTEN-任意の遠隔TCPとポートからの接続要求を待つことを表す。
SYN-SENT - represents waiting for a matching connection request
after having sent a connection request.
SYN-SENT-接続要求を送った後で一致する接続要求を待つことを表す。
SYN-RECEIVED - represents waiting for a confirming connection
request acknowledgment after having both received and sent a
connection request.
SYN-RECEIVED-接続要求の受信と送信の後で接続要求確認応答の確認を待つ
ことを表す。
ESTABLISHED - represents an open connection, data received can be
delivered to the user. The normal state for the data transfer phase
of the connection.
ESTABLISHED-オープン接続を表す、受信データをユーザに届けることができ
る。接続のデータ転送フェーズ間の基底状態。
FIN-WAIT-1 - represents waiting for a connection termination request
from the remote TCP, or an acknowledgment of the connection
termination request previously sent.
FIN-WAIT-1-遠隔TCPからの接続終了要求あるいは前に送った接続終了要求の
確認応答を待つことを表す。
FIN-WAIT-2 - represents waiting for a connection termination request
from the remote TCP.
FIN-WAIT-2-遠隔TCPから接続終了要求を待つことを表す。
CLOSE-WAIT - represents waiting for a connection termination request
from the local user.
CLOSE-WAIT-ローカルユーザから接続終了要求を待つことを表す。
CLOSING - represents waiting for a connection termination request
acknowledgment from the remote TCP.
CLOSING-遠隔TCPから接続終了要求確認応答を待つことを表す。
LAST-ACK - represents waiting for an acknowledgment of the
connection termination request previously sent to the remote TCP
(which includes an acknowledgment of its connection termination
request).
LAST-ACK-（その接続終了要求の確認応答を含む）遠隔TCPに前に送られた接
続終了要求の確認応答を待つことを表す。
TIME-WAIT - represents waiting for enough time to pass to be sure
the remote TCP received the acknowledgment of its connection
termination request.
TIME-WAIT-遠隔TCPがその接続終了要求の確認応答を受取りを確かに認められ
るのに十分の時間待つことを表す。
CLOSED - represents no connection state at all.
CLOSED-まったくの無接続状態を表す。
A TCP connection progresses from one state to another in response to
events. The events are the user calls, OPEN, SEND, RECEIVE, CLOSE,
ABORT, and STATUS; the incoming segments, particularly those
containing the SYN, ACK, RST and FIN flags; and timeouts.
TCP接続がイベントに応えて１状態からもう１つまで進行する。イベントはユー
ザ呼び出しOPEN・SEND・RECEIVE・CLOSE・ABORT・STATUSと、特にSYN・ACK・
RST・FINフラグを含んでいる入ってくるセグメントと、タイムアウトである。
The state diagram in figure 6 illustrates only state changes, together
with the causing events and resulting actions, but addresses neither
error conditions nor actions which are not connected with state
changes. In a later section, more detail is offered with respect to
the reaction of the TCP to events.
図６での状態遷移図はただ状態変更・イベントの結果・動作の結果だけを説明
する、しかしエラー条件と動作の状態変更は記述されていない。後のセクショ
ンで、TCPイベントの動作に関して、もっと多くの細部が提供される。
NOTE BENE: this diagram is only a summary and must not be taken as
the total specification.
注釈：この線図は概要であり、完全な仕様と思ってはならない。
TCP Connection State Diagram
TCP接続状態遷移図
Figure 6.
図６
3.3. Sequence Numbers
シーケンス番号
A fundamental notion in the design is that every octet of data sent
over a TCP connection has a sequence number. Since every octet is
sequenced, each of them can be acknowledged. The acknowledgment
mechanism employed is cumulative so that an acknowledgment of sequence
number X indicates that all octets up to but not including X have been
received. This mechanism allows for straight-forward duplicate
detection in the presence of retransmission. Numbering of octets
within a segment is that the first data octet immediately following
the header is the lowest numbered, and the following octets are
numbered consecutively.
基本的なデザインの考えで、すべてのTCP接続上で送らるデータオクテットが
シーケンス番号を持っている。すべてのオクテットが順序立てて並べられるの
で、それらのそれぞれに受領通知を出すことができる。使用される確認応答機
構は累積的で、シーケンス番号Xの確認応答が、Xを含まない、すべてのXまで
のオクテットが受けられたことを表す。この機構は再送の簡単な重複検出を許
す。セグメントの中のオクテット番号がヘッダーのすぐ後に続く最初のデータ
オクテットで、最も小さい番号を付けられるものである、そして次のオクテッ
トは連続して番号を付けられる。
It is essential to remember that the actual sequence number space is
finite, though very large. This space ranges from 0 to 2**32 - 1.
Since the space is finite, all arithmetic dealing with sequence
numbers must be performed modulo 2**32. This unsigned arithmetic
preserves the relationship of sequence numbers as they cycle from
2**32 - 1 to 0 again. There are some subtleties to computer modulo
arithmetic, so great care should be taken in programming the
comparison of such values. The symbol "=<" means "less than or equal"
(modulo 2**32).
実際のシーケンス番号スペースは非常に大きいけれども、有限であることを覚
えていることが必須である。このスペースは0から2**32-1まで及ぶ。スペース
が有限であるので、すべてのシーケンス番号を扱う算術が2**32のモジュロで
あるに違いない。この符号無し算術は、それらが再び2**32-1から0まで回ると
き、シーケンス番号の関係を維持する。コンピュータモジュロ算術にある繊細
さが必要で、このような値の比較のプログラムする際に大きな注意がとられる
べきである。シンボル"=<"が「より小さいあるいは同じ」（モジュロが2**32）
を意味する。
The typical kinds of sequence number comparisons which the TCP must
perform include:
TCPが実行しなくてはならない典型的な種類のシーケンス番号比較は含む：
(a) Determining that an acknowledgment refers to some sequence
number sent but not yet acknowledged.
(a) 送られたが確認されていないあるシーケンス番号を参照する確認
応答を決定する。
(b) Determining that all sequence numbers occupied by a segment
have been acknowledged (e.g., to remove the segment from a
retransmission queue).
(b) セグメント内の全てのシーケンス番号が認められたと決定する（例
えば、セグメントを再送待ち行列から取り除くために）。
(c) Determining that an incoming segment contains sequence numbers
which are expected (i.e., that the segment "overlaps" the
receive window).
(c) 入ってくるセグメントが期待されるシーケンス番号を含んでいると
決定する（すなわち、セグメントが受信ウインドウを「重ねる」）。
In response to sending data the TCP will receive acknowledgments. The
following comparisons are needed to process the acknowledgments.
送信データに応えてTCPは確認応答を受け取るであろう。次の比較は確認応答を
処理するために必要とされる。
SND.UNA = oldest unacknowledged sequence number
最も古い確認されていないシーケンス番号
SND.NXT = next sequence number to be sent
次に送られるシーケンス番号
SEG.ACK = acknowledgment from the receiving TCP (next sequence
number expected by the receiving TCP)
受信TCP（受信TCPから期待される次のシーケンス番号）か
らの確認応答
SEG.SEQ = first sequence number of a segment
セグメントの最初のシーケンス番号
SEG.LEN = the number of octets occupied by the data in the segment
(counting SYN and FIN)
セグメントでデータにの占めるオクテット数（SYNやFINを数える）
SEG.SEQ+SEG.LEN-1 = last sequence number of a segment
セグメントの最後のシーケンス番号
A new acknowledgment (called an "acceptable ack"), is one for which
the inequality below holds:
新しい確認応答（"acceptable ack"と呼ばれた）は以下の不等式が下を保つ
ものである：
SND.UNA < SEG.ACK =< SND.NXT
A segment on the retransmission queue is fully acknowledged if the sum
of its sequence number and length is less or equal than the
acknowledgment value in the incoming segment.
再送待ち行列の上のセグメントのシーケンス番号と長さの合計が、もし入って
くるセグメントの確認応答値より少いか等しいなら、完全に確認される。
When data is received the following comparisons are needed:
データが受け取られる時、次の比較は必要とされる：
RCV.NXT = next sequence number expected on an incoming segments, and
is the left or lower edge of the receive window
受信セグメント上で期待される次のシーケンス番号で、そして受信ウイ
ンドウの左か下の端
RCV.NXT+RCV.WND-1 = last sequence number expected on an incoming
segment, and is the right or upper edge of the receive window
受信セグメントの上で期待される最後のシーケンス番号で、そして受信
ウインドウの右か上の端
SEG.SEQ = first sequence number occupied by the incoming segment
受信セグメントに入っている最初のシーケンス番号
SEG.SEQ+SEG.LEN-1 = last sequence number occupied by the incoming
segment
受信セグメントに入っている最後のシーケンス番号
A segment is judged to occupy a portion of valid receive sequence
space if
以下の場合、セグメントが有効な受信シーケンス空間の部分と判定される、
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
or
RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
The first part of this test checks to see if the beginning of the
segment falls in the window, the second part of the test checks to see
if the end of the segment falls in the window; if the segment passes
either part of the test it contains data in the window.
このテストの最初の部分はセグメントの初めがウインドウにはまるかどうか見
るために調べる、テストの２番目の部分はセグメントの終わりがウインドウに
入るかどうか見るために調べる；もしセグメントがいずれかのテストの部分を
通過するなら、ウインドウに入るデータを含んでいる。
Actually, it is a little more complicated than this. Due to zero
windows and zero length segments, we have four cases for the
acceptability of an incoming segment:
実際はこれよりもう少し複雑である。ゼロウィンドウとゼロ長セグメントのた
めに、受信セグメントの受領可能性は４つの場合がある：
Segment Receive Test
Length Window
セグメ 受信ウィ テスト
ント長 ンドウ
------- ------- -------------------------------------------
0 0 SEG.SEQ = RCV.NXT
0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
>0 0 not acceptable
>0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
Note that when the receive window is zero no segments should be
acceptable except ACK segments. Thus, it is be possible for a TCP to
maintain a zero receive window while transmitting data and receiving
ACKs. However, even when the receive window is zero, a TCP must
process the RST and URG fields of all incoming segments.
受信ウインドウがゼロである時、セグメントがACKセグメント以外許容範囲内
になるべきではないことに注意しなさい。それで、TCPがデータを伝達し確認
応答を受信する間、ゼロ受信ウインドウを保つことが可能である。しかしなが
ら、受信ウインドウがゼロである時でも、TCPはすべての受信セグメントのRST
とURGフィールドを処理しなくてはならない。
We have taken advantage of the numbering scheme to protect certain
control information as well. This is achieved by implicitly including
some control flags in the sequence space so they can be retransmitted
and acknowledged without confusion (i.e., one and only one copy of the
control will be acted upon). Control information is not physically
carried in the segment data space. Consequently, we must adopt rules
for implicitly assigning sequence numbers to control. The SYN and FIN
are the only controls requiring this protection, and these controls
are used only at connection opening and closing. For sequence number
purposes, the SYN is considered to occur before the first actual data
octet of the segment in which it occurs, while the FIN is considered
to occur after the last actual data octet in a segment in which it
occurs. The segment length (SEG.LEN) includes both data and sequence
space occupying controls. When a SYN is present then SEG.SEQ is the
sequence number of the SYN.
我々は同様にある特定の制御情報を保護するナンバリング計画を利用した。こ
れは暗黙のうちにシーケンス空間にある制御装置フラグを含めることによって
達せられる、それでそれらは再び送られて、そして混乱）無しで受領通知を出
すことができる（すなわち、必ずそして唯一の制御のコピーだけが行動を起こ
すであろう。制御情報がセグメントデータスペースで物理的に運ばれない。従っ
て、我々は暗黙のうちにシーケンス番号を制御情報に割り当てることに対して
規則を採用しなくてはならない。SYNとFINはこの保護を必要とする唯一の制御
情報である、そしてこれらの制御情報は接続開始と終了においてだけ使われる。
シーケンス番号目的のために、SYNは発生するセグメントの最初の実際のデー
タオクテットの前に発生すると考えられ、FINがそれが発生するセグメントの
最後の実際のデータオクテットの後に起こると考えられる。セグメント長
（SEG.LEN）はデータと制御情報で占められるシーケンス空間両方を含む。
SYNが存在している時、SEG.SEQはSYNのシーケンス番号である。
Initial Sequence Number Selection
最初のシーケンス番号選択
The protocol places no restriction on a particular connection being
used over and over again. A connection is defined by a pair of
sockets. New instances of a connection will be referred to as
incarnations of the connection. The problem that arises from this is
-- "how does the TCP identify duplicate segments from previous
incarnations of the connection?" This problem becomes apparent if the
connection is being opened and closed in quick succession, or if the
connection breaks with loss of memory and is then reestablished.
プロトコルは特定な接続が繰り返し使われることについて制限を置かない。
接続がソケットの対によって明記される。新しい接続は以前の接続を参照す
るであろう。これから生ずる問題は−「どのようにTCPは以前の接続から重
複セグメントを識別するか？」。もし接続の開始と終了が速く連続的に行わ
れるなら、あるいはもし接続がメモリ不足で壊れ、再確立される場合、この
問題は生じる。
To avoid confusion we must prevent segments from one incarnation of a
connection from being used while the same sequence numbers may still
be present in the network from an earlier incarnation. We want to
assure this, even if a TCP crashes and loses all knowledge of the
sequence numbers it has been using. When new connections are created,
an initial sequence number (ISN) generator is employed which selects a
new 32 bit ISN. The generator is bound to a (possibly fictitious) 32
bit clock whose low order bit is incremented roughly every 4
microseconds. Thus, the ISN cycles approximately every 4.55 hours.
Since we assume that segments will stay in the network no more than
the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
hours we can reasonably assume that ISN's will be unique.
混乱を避けるために、前の接続による以前のセグメントがネットワークでまだ
存在しているかも知れない間、同じシーケンス番号使われるのを阻止しなくて
はならない。我々は、たとえTCPがクラッシュして、すべての（今まで）使って
いたシーケンス番号の知識を失うとしても、これを保証することを望む。新し
い接続が作られる時、新しい32ビットの最初のシーケンス番号（ISN）を選ぶISN
ジェネレータが使用される。ジェネレータはその下位ビットが４マイクロセカン
ドごとにおよそ増加する（多分架空の）32ビットの時計に結び付いている。それ
でISNはおよそ４.５５時間ごとに一回転する。セグメントが最大セグメント寿
命（MSL）以上ネットワークで留まらないであろうし、MSLが４.５５時間以下で
あると想定できるので、合理的にISNがユニークであると想定できる。
For each connection there is a send sequence number and a receive
sequence number. The initial send sequence number (ISS) is chosen by
the data sending TCP, and the initial receive sequence number (IRS) is
learned during the connection establishing procedure.
それぞれの結線のために送信シーケンス番号と受信シーケンス番号がある。最初
の送信シーケンス番号（ＩＳＳ）はTCPを送信データによって選択され、最初の
受信シーケンス番号（IRS）は接続確立手順の中で知られる。
For a connection to be established or initialized, the two TCPs must
synchronize on each other's initial sequence numbers. This is done in
an exchange of connection establishing segments carrying a control bit
called "SYN" (for synchronize) and the initial sequence numbers. As a
shorthand, segments carrying the SYN bit are also called "SYNs".
Hence, the solution requires a suitable mechanism for picking an
initial sequence number and a slightly involved handshake to exchange
the ISN's.
接続が確立されるか初期化されるために、２つのTCPはお互いの最初のシーケ
ンス番号を同期しなくてはならない。これは"SYN"（同期のために）と呼ばれ
た制御ビットと最初のシーケンス番号を運ぶ接続確立セグメントの交換でなさ
れる。短縮形としてSYNビットを運んでいるセグメントが"SYNs"と呼ばれる。
従って、解法は最初のシーケンス番号を選ぶための適当な機構とISNを交換す
るべきわずかに複雑なハンドシェイクを必要とする。
The synchronization requires each side to send it's own initial
sequence number and to receive a confirmation of it in acknowledgment
from the other side. Each side must also receive the other side's
initial sequence number and send a confirming acknowledgment.
同期はそれぞれの側でそれは自身の最初のシーケンス番号の送信と、他の側か
らの確認応答での確認の受信を必要とする。それぞれの側が同じく他の側の最
初のシーケンス番号を受け取って、そして確認のため確認応答を送らなくては
ならない。
1) A --> B SYN my sequence number is X
私のシーケンス番号はXである。
2) A <-- B ACK your sequence number is X
あなたのシーケンス番号はXである。
3) A <-- B SYN my sequence number is Y
私のシーケンス番号はYである。
4) A --> B ACK your sequence number is Y
あなたのシーケンス番号はYである。
Because steps 2 and 3 can be combined in a single message this is
called the three way (or three message) handshake.
階段２と３がひとつのメッセージに結合できるから、これは３手順（ある
いは３メッセージ）ハンドシェイクと呼ばれる。
A three way handshake is necessary because sequence numbers are not
tied to a global clock in the network, and TCPs may have different
mechanisms for picking the ISN's. The receiver of the first SYN has
no way of knowing whether the segment was an old delayed one or not,
unless it remembers the last sequence number used on the connection
(which is not always possible), and so it must ask the sender to
verify this SYN. The three way handshake and the advantages of a
clock-driven scheme are discussed in [3].
シーケンス番号がネットワークのグローバルな時計に結び付けられないから、
そしてTCPがISNを選ぶ際に他の機構を持っているかも知れないので、３手順
ハンドシェイクが必要である。最初のSYNの受信者は、接続で使われた最後の
シーケンス番号を覚えていないかぎり（常に可能であるというわけではない）、
セグメントが古い遅たものかどうか知る方法を持たない、そのため送信者に
このSYNを確かめるように頼まなくてはならない。３手順ハンドシェイクと時
計駆動の計画の長所は[3]で論じられる。
Knowing When to Keep Quiet
いつまで沈黙するか知る
To be sure that a TCP does not create a segment that carries a
sequence number which may be duplicated by an old segment remaining in
the network, the TCP must keep quiet for a maximum segment lifetime
(MSL) before assigning any sequence numbers upon starting up or
recovering from a crash in which memory of sequence numbers in use was
lost. For this specification the MSL is taken to be 2 minutes. This
is an engineering choice, and may be changed if experience indicates
it is desirable to do so. Note that if a TCP is reinitialized in some
sense, yet retains its memory of sequence numbers in use, then it need
not wait at all; it must only be sure to use sequence numbers larger
than those recently used.
TCPがネットワークで残留して古いセグメントのシーケンス番号と同じかもし
れないシーケンス番号を運ぶセグメントを作らないことを確かにするため、
TCPは開始時あるいは使用中のシーケンス番号の記憶が失われるようなクラッ
シュから回復した後、シーケンス番号を割り当てる前にセグメントライフタイ
ム（MSL）を最大時間の間、沈黙してなくてはならない。この仕様のためにMSL
は２分であるととられる。これは工学選択であって、もし経験的に望ましいな
ら、変えられるかも知れない。もしTCPがある理由で再初期化されて、それで
使用中のシーケンス番号の記憶を維持するなら、まったく待つ必要がないこと
に注意しなさい；ただ最近使ったシーケンス番号より大きいシーケンス番号を
使うことを確認するだけでよい。
The TCP Quiet Time Concept
TCP沈黙時間概念
This specification provides that hosts which "crash" without
retaining any knowledge of the last sequence numbers transmitted on
each active (i.e., not closed) connection shall delay emitting any
TCP segments for at least the agreed Maximum Segment Lifetime (MSL)
in the internet system of which the host is a part. In the
paragraphs below, an explanation for this specification is given.
TCP implementors may violate the "quiet time" restriction, but only
at the risk of causing some old data to be accepted as new or new
data rejected as old duplicated by some receivers in the internet
system.
この仕様はそれぞれの有効な(つまり閉じていない)接続上で伝達する最後の
シーケンス番号の知識を維持しないで「クラッシュする」ホストが、その所
属するインターネットシステムで、少なくとも承認された最大セグメントラ
イフタイム（MSL）の間、どんなTCPセグメントでも発することを延ばすべき
であることを規定する。以下の段落でこの仕様のための説明が与えられる。
TCP実装者が「沈黙時間」制限を破るかも知れない、しかし危険性は、イン
ターネットシステムのある受信者により、ある古いデータを新しいものと思
われて受信するあるいは新しいデータが古いものにより拒否されることだけ
である。
TCPs consume sequence number space each time a segment is formed and
entered into the network output queue at a source host. The
duplicate detection and sequencing algorithm in the TCP protocol
relies on the unique binding of segment data to sequence space to
the extent that sequence numbers will not cycle through all 2**32
values before the segment data bound to those sequence numbers has
been delivered and acknowledged by the receiver and all duplicate
copies of the segments have "drained" from the internet. Without
such an assumption, two distinct TCP segments could conceivably be
assigned the same or overlapping sequence numbers, causing confusion
at the receiver as to which data is new and which is old. Remember
that each segment is bound to as many consecutive sequence numbers
as there are octets of data in the segment.
TCPが、セグメントが形成されて、そして発信ホストにおいてネットワー
ク出力キューの中に入力されるたびに、シーケンス番号スペースを消費す
る。TCPプロトコルでの重複検出と順序付けアルゴリズムは、すべての
2**32個のシーケンス番号値が、シーケンス番号と結び付いているセグメン
トデータが受信者に届けられ、認められ、そしてすべてのセグメントの複
製がインターネットから「排出される」より前に、巡回しないであろうと
いう大きなシーケンス空間で、セグメントデータのユニーク割付ができる
ことに依存する。このような仮説無しでは、２つの別のTCPセグメントがお
そらく同じあるいは部分的に重なり合っているシーケンス番号を割り当て
られ、新しいデータと古いデータ受信者が混乱を起こすことがあり得る。
それぞれのセグメントがセグメントのデータのオクテットと同じぐらい多
くの連続したシーケンス番号と結び付いていることを記憶しなさい。
Under normal conditions, TCPs keep track of the next sequence number
to emit and the oldest awaiting acknowledgment so as to avoid
mistakenly using a sequence number over before its first use has
been acknowledged. This alone does not guarantee that old duplicate
data is drained from the net, so the sequence space has been made
very large to reduce the probability that a wandering duplicate will
cause trouble upon arrival. At 2 megabits/sec. it takes 4.5 hours
to use up 2**32 octets of sequence space. Since the maximum segment
lifetime in the net is not likely to exceed a few tens of seconds,
this is deemed ample protection for foreseeable nets, even if data
rates escalate to l0's of megabits/sec. At 100 megabits/sec, the
cycle time is 5.4 minutes which may be a little short, but still
within reason.
正常状態の下で、シーケンス番号の最初の使用の受領通知が出る前に間違っ
てシーケンス番号を使うのを避けるように、TCPが発すべき次のシーケンス
番号と最も古い待ち受け中の確認応答を記録する。これは単独で古い重複デー
タがネットから排出させられることを保証しない、それでシーケンス空間は
さまよい歩きの重複が到着し故障を起こす可能性を減らすために非常に大き
くした。２メガビット／秒においてシーケンス空間の2**32オクテットを使い
尽くすことは４.５時間を要する。ネットワークでの最大セグメントライフ
タイムが数何十秒を超える可能性は高くないので予測できるネット、たとえ
データレートが１０メガビット／秒に拡大しても、十分な保障であると見な
される。１００のメガビット／秒においては、サイクル時間は５.４分で少
し短い、しかし依然として妥当である。
The basic duplicate detection and sequencing algorithm in TCP can be
defeated, however, if a source TCP does not have any memory of the
sequence numbers it last used on a given connection. For example, if
the TCP were to start all connections with sequence number 0, then
upon crashing and restarting, a TCP might re-form an earlier
connection (possibly after half-open connection resolution) and emit
packets with sequence numbers identical to or overlapping with
packets still in the network which were emitted on an earlier
incarnation of the same connection. In the absence of knowledge
about the sequence numbers used on a particular connection, the TCP
specification recommends that the source delay for MSL seconds
before emitting segments on the connection, to allow time for
segments from the earlier connection incarnation to drain from the
system.
TCPでの基本的な重複検出と順序付けアルゴリズムは、もし発信TCPが所定の
接続の最後に使ったシーケンス番号の記憶を持っていないなら破られること
がある。例えば、もしTCPがシーケンス番号０ですべての接続を始めること
があったなら、クラッシュして再起動するや否や、TCPが以前の接続を再編
して（半開きの接続の後で可能）、同じ接続の以前のものが発したのと同一
のシーケンス番号あるいはまだネットワークにあるパケットとシーケンス番
号の重なるパケットを発するかも知れない。特定の接続上で使われたシーケ
ンス番号についての知識がない場合、以前の接続のセグメントがシステムか
ら排出される時間を与えるため、TCP仕様は接続する際セグメントを発散す
る前にMSL秒間発信を遅れを推薦する。
Even hosts which can remember the time of day and used it to select
initial sequence number values are not immune from this problem
(i.e., even if time of day is used to select an initial sequence
number for each new connection incarnation).
時刻を覚えていて最初のシーケンス番号値を選ぶためにこれを使うホストで
もこの問題が免除されない（すなわち、たとえ時刻がそれぞれの新しい接続
の最初のシーケンス番号を選ぶために使われるとしても）
Suppose, for example, that a connection is opened starting with
sequence number S. Suppose that this connection is not used much
and that eventually the initial sequence number function (ISN(t))
takes on a value equal to the sequence number, say S1, of the last
segment sent by this TCP on a particular connection. Now suppose,
at this instant, the host crashes, recovers, and establishes a new
incarnation of the connection. The initial sequence number chosen is
S1 = ISN(t) -- last used sequence number on old incarnation of
connection! If the recovery occurs quickly enough, any old
duplicates in the net bearing sequence numbers in the neighborhood
of S1 may arrive and be treated as new packets by the receiver of
the new incarnation of the connection.
例えば、接続がシーケンス番号Ｓで開始すると考えなさい。この接続があま
り使われない、そして結局はシーケンス番号初期化関数(ISN(t))が、このTCP
の特定の接続上で送られた最後のセグメントのシーケンス番号、S1とする、
と等しい値を与えると考えなさい。今、この瞬間において、ホストがクラッ
シュし回復して、そして新しい接続を確立すると考えなさい。選択された最
初のシーケンス番号はS1=ISN(t)である、つまり古い接続の最後のシーケン
ス番号である！もし障害回復が十分に速く起こるなら、S1に近いシーケンス
番号を運んでいるネットワーク内の古いパケットが到着し、新しい接続の受
信者によって新しいパケットとして取り扱われるかも知れない。
The problem is that the recovering host may not know for how long it
crashed nor does it know whether there are still old duplicates in
the system from earlier connection incarnations.
問題は回復しているホストがどれぐらい長くの間それがクラッシュしたか知
らない、以前の接続によりシステムに古いパケットがあるかどうか知らない
ないかも知れないということである。
One way to deal with this problem is to deliberately delay emitting
segments for one MSL after recovery from a crash- this is the "quite
time" specification. Hosts which prefer to avoid waiting are
willing to risk possible confusion of old and new packets at a given
destination may choose not to wait for the "quite time".
Implementors may provide TCP users with the ability to select on a
connection by connection basis whether to wait after a crash, or may
informally implement the "quite time" for all connections.
Obviously, even where a user selects to "wait," this is not
necessary after the host has been "up" for at least MSL seconds.
この問題を扱う１つの方法はクラッシュからの回復の後に故意に１MSLの間
セグメントを発することを延ばすことである、これは「沈黙時間」仕様であ
る。待つのを避けることを好むホストは、「沈黙時間」を待たない選択ため
に、所定の着信において古いのと新しいパケットによる混乱の可能性の危険
性に遭遇する。インプリメンタが接続毎にクラッシュの後に待つべきかどう
か選択する能力をTCPユーザに提供してもよいし、あるいはすべての接続に
略式「沈黙時間」を実行してもよい。明らかに、ユーザが「待つ」を選択し
た場合でも、ホストが少なくともMSL秒に「稼働していた」後では、これ必
要ではない。
To summarize: every segment emitted occupies one or more sequence
numbers in the sequence space, the numbers occupied by a segment are
"busy" or "in use" until MSL seconds have passed, upon crashing a
block of space-time is occupied by the octets of the last emitted
segment, if a new connection is started too soon and uses any of the
sequence numbers in the space-time footprint of the last segment of
the previous connection incarnation, there is a potential sequence
number overlap area which could cause confusion at the receiver.
要約すると：すべての発信セグメントがシーケンス空間で１つあるいはそれ
以上のシーケンス番号を占める、セグメントによって占められた番号はMSL
秒が過ぎ去るまで「使用中」、クラッシュすると１空間のブロックが最後の
発信セグメントのオクテットによって占められる、もし新しい接続があまり
早く始められて、そして前の接続の最後のセグメントのシーケンス番号のど
れかを使うなら、シーケンス番号重複エリアにより受信者が混乱を起こす可
能性がある。
3.4. Establishing a connection
接続を確立する
The "three-way handshake" is the procedure used to establish a
connection. This procedure normally is initiated by one TCP and
responded to by another TCP. The procedure also works if two TCP
simultaneously initiate the procedure. When simultaneous attempt
occurs, each TCP receives a "SYN" segment which carries no
acknowledgment after it has sent a "SYN". Of course, the arrival of
an old duplicate "SYN" segment can potentially make it appear, to the
recipient, that a simultaneous connection initiation is in progress.
Proper use of "reset" segments can disambiguate these cases.
「３手順ハンドシェイク」は接続を確立するために使われる手続である。こ
の手順は通常１つのTCPによって始められて、そしてもう１つのTCPによって
返答される。手順は、もし２つのTCPが同時に手順を始めても同じく動作する。
同時接続が起こる時、それぞれのTCPは"SYN"を送った後、確認応答のない"SYN"
セグメントを受け取る。もちろん、古い重複"SYN"セグメントの到着は潜在的
に受信者に同時接続起動が進行中であるように思すことになる。「リセット」
セグメントの適切な使用でこれらの場合を回避できる。
Several examples of connection initiation follow. Although these
examples do not show connection synchronization using data-carrying
segments, this is perfectly legitimate, so long as the receiving TCP
doesn't deliver the data to the user until it is clear the data is
valid (i.e., the data must be buffered at the receiver until the
connection reaches the ESTABLISHED state). The three-way handshake
reduces the possibility of false connections. It is the
implementation of a trade-off between memory and messages to provide
information for this checking.
接続起動のいくつかの例が次に続く。これらの例がデータを運ぶセグメントを
使っての接続同期を示さないけれどもこれは正当である、TCPはデータが正当
であることは明確になるまでユーザデータに届けないで受信する（つまり接続
がESTABLISHED状態に達するまで、データが受信者でバッファに入れられなく
てはならない）。３手順ハンドシェイクは誤った接続の可能性を減らす。この
チェックに情報を提供するメモリとメッセージの間にのトレードオフの実装で
ある。
The simplest three-way handshake is shown in figure 7 below. The
figures should be interpreted in the following way. Each line is
numbered for reference purposes. Right arrows (-->) indicate
departure of a TCP segment from TCP A to TCP B, or arrival of a
segment at B from A. Left arrows (<--), indicate the reverse.
Ellipsis (...) indicates a segment which is still in the network
(delayed). An "XXX" indicates a segment which is lost or rejected.
Comments appear in parentheses. TCP states represent the state AFTER
the departure or arrival of the segment (whose contents are shown in
the center of each line). Segment contents are shown in abbreviated
form, with sequence number, control flags, and ACK field. Other
fields such as window, addresses, lengths, and text have been left out
in the interest of clarity.
最も単純な３手順ハンドシェイクは下に図７で示される。図は次の方法で解釈
されるべきである。それぞれのラインが参照目的のために番号を付けられる。
右向き矢印（−＞）が、TCPＡからTCPＢまでTCPセグメントの出発、あるいは
ＡからＢへのセグメントの到着、を示す。左向き矢印（＜−）が逆を表す。省
略(...)が、まだネットワークにある（遅れている）セグメントを示す。「XXX」
が失われるか、あるいは拒絶されるセグメントを示す。コメントが括弧に現わ
れる。TCP状態が（内容がそれぞれのラインの中心にある）セグメントの出発あ
るいは到着の後の状態の示す。セグメント中身が短縮された形式で、シーケン
ス番号、制御フラグとACKフィールドと一緒に示される。ウインドウ、アドレス、
長さとテキストのような他のフィールドが明快さのために抜かされてる。
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED
3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
Basic 3-Way Handshake for Connection Synchronization
接続同期のための基本的な３方向ハンドシェイク
Figure 7.
図７
In line 2 of figure 7, TCP A begins by sending a SYN segment
indicating that it will use sequence numbers starting with sequence
number 100. In line 3, TCP B sends a SYN and acknowledges the SYN it
received from TCP A. Note that the acknowledgment field indicates TCP
B is now expecting to hear sequence 101, acknowledging the SYN which
occupied sequence 100.
図７のライン２で、TCP Aがシーケンス番号１００から始まるめてシーケンス番
号を使うであろうことを表わすSYNセグメントによって始まる。ライン３で、
TCP BがSYNを送って、そしてそれがTCP Aから受け取ったSYNを認める。確認応答
フィールドがTCP Bが今シーケンス１０１を聞くことを予期して、シーケンス
１００を占領したSYNを認めていることを表すことに注意しなさい。
At line 4, TCP A responds with an empty segment containing an ACK for
TCP B's SYN; and in line 5, TCP A sends some data. Note that the
sequence number of the segment in line 5 is the same as in line 4
because the ACK does not occupy sequence number space (if it did, we
would wind up ACKing ACK's!).
ライン４において、TCP AがTCP BのSYNのためのACKを含むからのセグメントで
返答する、そしてライン５でTCP Aがいくらかデータを送る。ライン５でのセ
グメントのシーケンス番号が、ACKがシーケンス番号空間を占領しないので
（もし占領するならACKのACKが生じるであろう！）ライン４と同じであること
に注意しなさい。
Simultaneous initiation is only slightly more complex, as is shown in
figure 8. Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to
ESTABLISHED.
同時の起動は図８に示されるようにわずかに複雑である。それぞれのTCPが
CLOSEDからSYN-SENT、SYN-RECEIVED、ESTABLISHEDまで回る。
TCP A TCP B
1. CLOSED CLOSED
2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT
4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
Simultaneous Connection Synchronization
同時の接続同期
Figure 8.
図８
The principle reason for the three-way handshake is to prevent old
duplicate connection initiations from causing confusion. To deal with
this, a special control message, reset, has been devised. If the
receiving TCP is in a non-synchronized state (i.e., SYN-SENT,
SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset.
If the TCP is in one of the synchronized states (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it
aborts the connection and informs its user. We discuss this latter
case under "half-open" connections below.
３手順ハンドシェイクの原理理由は混乱を起こすため古い重複結合開始を妨げ
るはずである。これを扱うために特別な制御メッセージ、リセットが考案され
た。もし受信TCPが非同期状態なら（すなわちSYN-SENT、SYN-RECEIVEDなら）、
それは受領できるリセットによりLISTENへ戻る。もしTCPが同期状態の１つ
(ESTABLISHED,FIN-WAIT-1,FIN-WAIT-2,CLOSE-WAIT,CLOSING,LAST-ACK,TIME-WAIT)
にあるなら、それは接続を中止してユーザに知らせる。我々は下に「半開き」
接続のもとでこの事例を論じる。
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
3. (duplicate) ... <SEQ=90><CTL=SYN> --> SYN-RECEIVED
4. SYN-SENT <-- <SEQ=300><ACK=91><CTL=SYN,ACK> <-- SYN-RECEIVED
5. SYN-SENT --> <SEQ=91><CTL=RST> --> LISTEN
6. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
7. SYN-SENT <-- <SEQ=400><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
8. ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK> --> ESTABLISHED
Recovery from Old Duplicate SYN
古い重複SYNからの回復
Figure 9.
図９
As a simple example of recovery from old duplicates, consider
figure 9. At line 3, an old duplicate SYN arrives at TCP B. TCP B
cannot tell that this is an old duplicate, so it responds normally
(line 4). TCP A detects that the ACK field is incorrect and returns a
RST (reset) with its SEQ field selected to make the segment
believable. TCP B, on receiving the RST, returns to the LISTEN state.
When the original SYN (pun intended) finally arrives at line 6, the
synchronization proceeds normally. If the SYN at line 6 had arrived
before the RST, a more complex exchange might have occurred with RST's
sent in both directions.
古い重複からの回復の単純な例として、図９を考えなさい。ライン３において、
古い重複SYNがTCP Bに到着する・・・。TCP Bがこれが古い重複であると見分
けることができない、それでそれは通常返答する（ライン４）。TCPＡがACK
フィールドが正しくないことを検出する、信じてしまったセグメントを指定し
たSEQフィールドでRST（リセット）を返す。TCP BはRSTを受け取るとLISTEN状
態に戻る。オリジナルのSYN（意図した物）が最終的にライン６で到着し、同
期は通常進む。もしライン６においてのSYNがRSTの前に到着していたなら、両
方向でRSTを使って複雑な交換が起こったかも知れない。
Half-Open Connections and Other Anomalies
半開き接続と他の例外
An established connection is said to be "half-open" if one of the
TCPs has closed or aborted the connection at its end without the
knowledge of the other, or if the two ends of the connection have
become desynchronized owing to a crash that resulted in loss of
memory. Such connections will automatically become reset if an
attempt is made to send data in either direction. However, half-open
connections are expected to be unusual, and the recovery procedure is
mildly involved.
確定した接続が、もし一方のTCPが他に知らせず接続を閉じるか中止したなら、
あるいは、もし接続両端がメモリの損失をもたらすクラッシュにより同期損失
をおこしたなら、「半開き」であると言われる。このような接続は、もしいず
れかの方角にデータを送る試みがあれば、自動的にリセットされるであろう。
しかし半開き接続がまれであると見込まれ、そして回復手順は少し必要とされ
る。
If at site A the connection no longer exists, then an attempt by the
user at site B to send any data on it will result in the site B TCP
receiving a reset control message. Such a message indicates to the
site B TCP that something is wrong, and it is expected to abort the
connection.
もしサイトＡにおいて接続がもう存在しないなら、サイトＢにおいてユーザに
よるどんなそれ以上のデータを送る試みもサイトＢのTCPがリセット制御メッ
セージを受け取るという結果になるであろう。このようなメッセージはサイト
ＢのTCPに何かが間違っていることを表し、接続を中止することが期待される。
Assume that two user processes A and B are communicating with one
another when a crash occurs causing loss of memory to A's TCP.
Depending on the operating system supporting A's TCP, it is likely
that some error recovery mechanism exists. When the TCP is up again,
A is likely to start again from the beginning or from a recovery
point. As a result, A will probably try to OPEN the connection again
or try to SEND on the connection it believes open. In the latter
case, it receives the error message "connection not open" from the
local (A's) TCP. In an attempt to establish the connection, A's TCP
will send a segment containing SYN. This scenario leads to the
example shown in figure 10. After TCP A crashes, the user attempts to
re-open the connection. TCP B, in the meantime, thinks the connection
is open.
２つのユーザプロセスAとBがお互いと通信していて、クラッシュがAのTCPメモ
リの損失を起こしたと想定しなさい。AのTCPをサポートしているオペレーティ
ング・システムにより、あるエラー回復機構が存在することはあえる。TCPが
再び動き出した時、Aが最初からあるいは回復ポイントから再開することはあ
りえる。結果として、Aが再び接続を開こうとするか、あるいは開いていて信
じる接続上で送信しようとするであろう。後者では（Aの）ローカルTCPから
エラーメッセージ「開いていない接続」を受け取る。接続を確立する試みで、
AのTCPがセグメントにSYNを含めるであろう。このシナリオは図１０に示す事
例に導く。TCP Aがクラッシュした後、ユーザは接続を再度開こうと試みる。
TCP Bが、その間、接続が開いてると思う。
TCP A TCP B
1. (CRASH) (send 300,receive 100)
2. CLOSED ESTABLISHED
3. SYN-SENT --> <SEQ=400><CTL=SYN> --> (??)
4. (!!) <-- <SEQ=300><ACK=100><CTL=ACK> <-- ESTABLISHED
5. SYN-SENT --> <SEQ=100><CTL=RST> --> (Abort!!)
6. SYN-SENT CLOSED
7. SYN-SENT --> <SEQ=400><CTL=SYN> -->
Half-Open Connection Discovery
半開き接続発見
Figure 10.
図１０
When the SYN arrives at line 3, TCP B, being in a synchronized state,
and the incoming segment outside the window, responds with an
acknowledgment indicating what sequence it next expects to hear (ACK
100). TCP A sees that this segment does not acknowledge anything it
sent and, being unsynchronized, sends a reset (RST) because it has
detected a half-open connection. TCP B aborts at line 5. TCP A will
continue to try to establish the connection; the problem is now
reduced to the basic 3-way handshake of figure 7.
SYNがライン３に到着する時、TCP Bは、同期状態にあり入ってくるセグメント
はウィンドウの外である時、確認応答が次に聞くことを予期するシーケンスを
示して返答する（ACK100）。TCP Aが送ったことのないセグメントの確認応答
を見て、非同期の存在を知り、それが半開き接続を検出したためリセット(RST)
を送る。TCP Bがライン５において中断する。TCP Aが接続を確立しようとする
ために続くであろう；問題は図７の基本的な３方向ハンドシェイクに還元され
る。
An interesting alternative case occurs when TCP A crashes and TCP B
tries to send data on what it thinks is a synchronized connection.
This is illustrated in figure 11. In this case, the data arriving at
TCP A from TCP B (line 2) is unacceptable because no such connection
exists, so TCP A sends a RST. The RST is acceptable so TCP B
processes it and aborts the connection.
面白い代わりの事例が、TCP AがクラッシュしTCP Bがデータを同期していると
思う接続上に送ろうとする時、起こる。これは図１１で説明される。この場合、
TCP B（ライン２）からTCP Aに到着しているデータは、接続が存在しないので
受け入れられず、TCP AがRSTを送る。RSTは受領でき、TCP Bがそれを処理し、
接続を中止する。
TCP A TCP B
1. (CRASH) (send 300,receive 100)
2. (??) <-- <SEQ=300><ACK=100><DATA=10><CTL=ACK> <-- ESTABLISHED
3. --> <SEQ=100><CTL=RST> --> (ABORT!!)
Active Side Causes Half-Open Connection Discovery
活動側が半開き接続発見
Figure 11.
図１１
In figure 12, we find the two TCPs A and B with passive connections
waiting for SYN. An old duplicate arriving at TCP B (line 2) stirs B
into action. A SYN-ACK is returned (line 3) and causes TCP A to
generate a RST (the ACK in line 3 is not acceptable). TCP B accepts
the reset and returns to its passive LISTEN state.
図１２で、２つの受動的な接続のTCP AとBがSYNを待つという状態と思う。
TCP B（ライン２）に到着している古い重複がＢを行動に巻き込む。SYN-ACKが
返され（ライン３）、TCP AはRSTを作り出す（ライン３でのACKは受容できない）。
TCP Bがリセットを受け入れて、受動的なLISTEN状態に戻る。
TCP A TCP B
1. LISTEN LISTEN
2. ... <SEQ=Z><CTL=SYN> --> SYN-RECEIVED
3. (??) <-- <SEQ=X><ACK=Z+1><CTL=SYN,ACK> <-- SYN-RECEIVED
4. --> <SEQ=Z+1><CTL=RST> --> (return to LISTEN!)
5. LISTEN LISTEN
Old Duplicate SYN Initiates a Reset on two Passive Sockets
古い重複SYNが２つの受動的なソケット上のリセットを初期化
Figure 12.
図１２
A variety of other cases are possible, all of which are accounted for
by the following rules for RST generation and processing.
いろいろな他のケースが可能である、そしてそのすべてはRST生成と処理の次
の規則によって説明される。
Reset Generation
リセット生成
As a general rule, reset (RST) must be sent whenever a segment arrives
which apparently is not intended for the current connection. A reset
must not be sent if it is not clear that this is the case.
一般規則として、外見上は現在の接続に意図されないセグメントが到着する時
はいつでもリセット（RST）が送らなくてはならない。リセットが、もしこのよ
うな場合であると明らかでないなら送ってはならない。
There are three groups of states:
３つの状態グループがある：
1. If the connection does not exist (CLOSED) then a reset is sent
in response to any incoming segment except another reset. In
particular, SYNs addressed to a non-existent connection are rejected
by this means.
１．もし接続が存在しないなら（CLOSED）、リセット以外どんな入ってくる
セグメントに対しても、リセットが送られる。特に、非実在の接続へのSYNs
がこの手段によって拒絶される。
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the CLOSED state.
もし入ってくるセグメントがACKフィールドを持っているなら、リセットは
セグメントのACKフィールドからそのシーケンス番号をとる、さもなければ
リセットはシーケンス番号をゼロにする、そしてACKフィールドはシーケン
ス番号と入ってくるセグメントのセグメント長さの合計にセットされる。接
続はCLOSED状態で残留する。
2. If the connection is in any non-synchronized state (LISTEN,
SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
something not yet sent (the segment carries an unacceptable ACK), or
if an incoming segment has a security level or compartment which
does not exactly match the level and compartment requested for the
connection, a reset is sent.
２．もし接続が非同期状態にいるなら（SYN-SENT、SYN-RECEIVED、LISTENす
る）、そして入ってくるセグメントはまだ送られなかった何かの確認応答を
するか（セグメントは受け入れ難いACKを運ぶ）、あるいはもし入ってくる
セグメントが接続にあっていない安全レベルと隔離を持つならばリセットが
送られる。
If our SYN has not been acknowledged and the precedence level of the
incoming segment is higher than the precedence level requested then
either raise the local precedence level (if allowed by the user and
the system) or send a reset; or if the precedence level of the
incoming segment is lower than the precedence level requested then
continue as if the precedence matched exactly (if the remote TCP
cannot raise the precedence level to match ours this will be
detected in the next segment it sends, and the connection will be
terminated then). If our SYN has been acknowledged (perhaps in this
incoming segment) the precedence level of the incoming segment must
match the local precedence level exactly, if it does not a reset
must be sent.
もし我々のSYNが認められず、そして入ってくるセグメントの優先順位レベ
ルが要求されたものより高いなら、（もしユーザとシステムによって許され
るなら）、ローカル優先順位レベルを引き上げるか、あるいはリセットを送
る；あるいはもし入ってくるセグメントの優先順位レベルが要求されたもの
より低いなら、優先順位があってるかのように継続される（もし遠隔のTCP
が次のセグメントの送信でこれに気付いて我々のに合う優先順位レベルを引
き上げることができないなら、接続がその時終了するだろう）。もし我々の
SYNが（多分この入ってくるセグメントで）認められたなら、入ってくるセ
グメントの優先順位レベルは正確にローカル優先順位レベルに一致しなくて
はならない、もしそうでなければリセットが送られなくてはならない。
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the same state.
もし入ってくるセグメントがACKフィールドを持っているなら、リセットは
セグメントのACKフィールドからそのシーケンス番号をとる、さもなければ
リセットはシーケンス番号をゼロであるようにする、そしてACKフィールド
はシーケンス番号と入ってくるセグメントのセグメント長さの合計にセット
される。接続は同じ状態で残留する。
3. If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptible acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
３．もし接続が同期状態であるなら（ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、
CLOSE-WAIT、CLOSING、LAST-ACK、TIME-WAIT）、どんな受領できないセグメ
ントでも（ウインドウシーケンス番号が範囲外あるいは受領できない確認番
号）、現在の送信シーケンス番号と次に受信が期待されるシーケンス番号を
示す確認応答を含む、空の確認応答を引き出し、接続は同じ状態で残留する。
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection,a reset is sent and
connection goes to the CLOSED state. The reset takes its sequence
number from the ACK field of the incoming segment.
もし入ってくるセグメントが接続に要求されている安全レベルと隔離と優先
順位に一致しないなら、リセットが送られ、接続がCLOSED状態に行く。リセッ
トは入ってくるセグメントのACKフィールドからそのシーケンス番号をとる。
Reset Processing
リセット処理
In all states except SYN-SENT, all reset (RST) segments are validated
by checking their SEQ-fields. A reset is valid if its sequence number
is in the window. In the SYN-SENT state (a RST received in response
to an initial SYN), the RST is acceptable if the ACK field
acknowledges the SYN.
SYN-SENT以外すべての状態で、すべてのリセット（RST）セグメントがそれら
のSEQ-フィールドをチェックすることによって有効にされる。リセットが、も
しそのシーケンス番号がウインドウにあるなら、効力がある。SYN-SENT状態
（最初のSYNの応答としてRST受信）で、RSTは、もしACKフィールドがSYNを認
めるなら、受容できる。
The receiver of a RST first validates it, then changes state. If the
receiver was in the LISTEN state, it ignores it. If the receiver was
in SYN-RECEIVED state and had previously been in the LISTEN state,
then the receiver returns to the LISTEN state, otherwise the receiver
aborts the connection and goes to the CLOSED state. If the receiver
was in any other state, it aborts the connection and advises the user
and goes to the CLOSED state.
RSTの受信者は最初にそれを有効にし、それから状態を変える。もし受信者が
LISTEN状態にいたなら、それを無視する。もし受信者がSYN-RECEIVED状態にい
て、そして前にLISTEN状態にいたなら、受信者はLISTEN状態に戻る、さもなけ
れば受信者は接続を中止して、CLOSED状態に行く。もし受信者が他の状態にい
たなら、それは接続を中止して、そしてユーザに知らせて、そしてCLOSED状態
に行く。
3.5. Closing a Connection
接続を閉じる
CLOSE is an operation meaning "I have no more data to send." The
notion of closing a full-duplex connection is subject to ambiguous
interpretation, of course, since it may not be obvious how to treat
the receiving side of the connection. We have chosen to treat CLOSE
in a simplex fashion. The user who CLOSEs may continue to RECEIVE
until he is told that the other side has CLOSED also. Thus, a program
could initiate several SENDs followed by a CLOSE, and then continue to
RECEIVE until signaled that a RECEIVE failed because the other side
has CLOSED. We assume that the TCP will signal a user, even if no
RECEIVEs are outstanding, that the other side has closed, so the user
can terminate his side gracefully. A TCP will reliably deliver all
buffers SENT before the connection was CLOSED so a user who expects no
data in return need only wait to hear the connection was CLOSED
successfully to know that all his data was received at the destination
TCP. Users must keep reading connections they close for sending until
the TCP says no more data.
クローズが「私は送るべきこれ以上のデータを持っていない。」ことを意味す
るオペレーションである。全二重結線を閉じることについての考えは、接続の
受信側を処理することが明白ではないだろうから、あいまいな解釈を受けやす
い。我々は単一な方法でクローズを扱うことに決めた。終了するユーザは、他
の側が閉じたと言うまで、受信を継続してもよい。それで、プログラムがクロー
ズした後いくつかのセンドを始めて、そして受信が他の側が閉じたから、失敗
したと示されるまで、受信を継続することができる。たとえ未処理の受信がな
いとしても、TCPがユーザに他の側がクローズしたと信号を送るであろうと想
定する、それでユーザは優雅に彼の側を終結することができる。TCPが、接続
が閉じられる前に、信頼できるようにすべての送られたバッファを配達するで
あろう、それで戻り値のデータを必要としないユーザが、必要でのデータがた
だ結線を聞くのを待つことだけをしないと思うユーザが、彼のすべてのデータ
が着信TCPに受け取られたことを知るために、正常に閉じられたのを待つだけ
でよい。ユーザはTCPがこれ以上のデータがない言う、送信に対して閉じた接
続を、読み続けなくてはならない。
There are essentially three cases:
本質的に３つのケースがある：
1) The user initiates by telling the TCP to CLOSE the connection
1) ユーザはTCP言うことで接続を閉じる始める
2) The remote TCP initiates by sending a FIN control signal
2) 遠隔TCPがFIN制御信号を送信することで始まる
3) Both users CLOSE simultaneously
3) 両方のユーザが同時にクローズ
Case 1: Local user initiates the close
事例１： ローカルユーザが終結を始める
In this case, a FIN segment can be constructed and placed on the
outgoing segment queue. No further SENDs from the user will be
accepted by the TCP, and it enters the FIN-WAIT-1 state. RECEIVEs
are allowed in this state. All segments preceding and including FIN
will be retransmitted until acknowledged. When the other TCP has
both acknowledged the FIN and sent a FIN of its own, the first TCP
can ACK this FIN. Note that a TCP receiving a FIN will ACK but not
send its own FIN until its user has CLOSED the connection also.
この場合、FINセグメントが作られ、出て行くセグメント待ち行列に置くこ
とができる。それ以上ユーザからのSENDsはTCPによって受け入れられないで
あろう、そしてFIN-WAIT-1状態に入る。受信がこの状態で許される。FINよ
り先のそして含んでいるすべてセグメントが確認されるまで再送されるであ
ろう。他のTCPがFINを確認しそしてそれ自身のFINを送った時、最初のTCPは
このFINに確認応答することができる。FINを受信したTCPが確認応答するで
あろうが、ユーザが接続を閉じるまでそれ自身のFINを送ってはいけないこ
とに注意がいる。
Case 2: TCP receives a FIN from the network
事例２： TCPがネットワークからFINを受け取る
If an unsolicited FIN arrives from the network, the receiving TCP
can ACK it and tell the user that the connection is closing. The
user will respond with a CLOSE, upon which the TCP can send a FIN to
the other TCP after sending any remaining data. The TCP then waits
until its own FIN is acknowledged whereupon it deletes the
connection. If an ACK is not forthcoming, after the user timeout
the connection is aborted and the user is told.
もし望まないFINがネットワークから到着したら、受信TCPはそれに確認応答
して、そして接続が閉じたことをユーザを示すことができる。ユーザはクロー
ズで返答するし、TCPは残っているデータを送った後でFINを他のTCPに送る
ことができるであろう。TCPは、それ自身のFINが認められるまで待ち、接続
を削除する。もし確認応答が来ないなら、ユーザタイムアウトの後に接続は
中止され、ユーザに示される。
Case 3: both users close simultaneously
事例３： 両方のユーザが同時に終了する
A simultaneous CLOSE by users at both ends of a connection causes
FIN segments to be exchanged. When all segments preceding the FINs
have been processed and acknowledged, each TCP can ACK the FIN it
has received. Both will, upon receiving these ACKs, delete the
connection.
ユーザによる同時の終了は両方の接続の端におけるFINセグメントの交換を
起こす。すべてのFINより先のセグメントが処理されて、確認された時、そ
れぞれのTCPが受信FINに確認応答することができる。両者はこれらの確認応
答を受け取り、接続を削除するであろう。
TCP A TCP B
1. ESTABLISHED ESTABLISHED
2. (Close)
FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> --> CLOSE-WAIT
3. FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> <-- CLOSE-WAIT
4. (Close)
TIME-WAIT <-- <SEQ=300><ACK=101><CTL=FIN,ACK> <-- LAST-ACK
5. TIME-WAIT --> <SEQ=101><ACK=301><CTL=ACK> --> CLOSED
6. (2 MSL)
CLOSED
Normal Close Sequence
標準的なクローズシーケンス
Figure 13.
図１３
TCP A TCP B
1. ESTABLISHED ESTABLISHED
2. (Close) (Close)
FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> ... FIN-WAIT-1
<-- <SEQ=300><ACK=100><CTL=FIN,ACK> <--
... <SEQ=100><ACK=300><CTL=FIN,ACK> -->
3. CLOSING --> <SEQ=101><ACK=301><CTL=ACK> ... CLOSING
<-- <SEQ=301><ACK=101><CTL=ACK> <--
... <SEQ=101><ACK=301><CTL=ACK> -->
4. TIME-WAIT TIME-WAIT
(2 MSL) (2 MSL)
CLOSED CLOSED
Simultaneous Close Sequence
同時のクローズシーケンス
Figure 14.
図１４
3.6. Precedence and Security
優先順位と安全
The intent is that connection be allowed only between ports operating
with exactly the same security and compartment values and at the
higher of the precedence level requested by the two ports.
要は、正確に同じ安全と隔離値で、そして２つのポートに求められたもののう
ちより高い優先順位レベルで、稼働してポート間にのみ接続が許されるという
ことである。
The precedence and security parameters used in TCP are exactly those
defined in the Internet Protocol (IP) [2]. Throughout this TCP
specification the term "security/compartment" is intended to indicate
the security parameters used in IP including security, compartment,
user group, and handling restriction.
優先順位とTCPで使われた安全パラメータは正確にインターネット・プロトコ
ル（IP）[2]で定義されるものである。このTCP仕様を通じて用語「安全／隔離」
は、IPで使った安全パラメータが安全、隔離、ユーザーグループと取り扱い制
限を示すように意図される。
A connection attempt with mismatched security/compartment values or a
lower precedence value must be rejected by sending a reset. Rejecting
a connection due to too low a precedence only occurs after an
acknowledgment of the SYN has been received.
不釣り合いな安全／隔離値あるいはより低い優先順位値を持っている接続がリ
セットを送ることで拒絶されなくてはならない。低い優先順位による接続拒否
はSYNの確認応答が受け取られた後起こるだけである。
Note that TCP modules which operate only at the default value of
precedence will still have to check the precedence of incoming
segments and possibly raise the precedence level they use on the
connection.
優先順位のデフォルト値においてだけ稼働するTCPモジュールがまだ入ってく
るセグメントの優先順位をチェックして、できる限りそれらが接続上で使う優
先順位レベルに引き上げなければならないことに注意しなさい。
The security paramaters may be used even in a non-secure environment
(the values would indicate unclassified data), thus hosts in
non-secure environments must be prepared to receive the security
parameters, though they need not send them.
安全パラメータは保全性がない環境（値は機密扱いでないデータを示すであろ
う）でさえ使われるかも知れない、それで保全性がない環境でのホストがそれ
らを送る必要がないけれども、安全パラメータを受け取る用意ができているで
あろう。
3.7. Data Communication
データ通信
Once the connection is established data is communicated by the
exchange of segments. Because segments may be lost due to errors
(checksum test failure), or network congestion, TCP uses
retransmission (after a timeout) to ensure delivery of every segment.
Duplicate segments may arrive due to network or TCP retransmission.
As discussed in the section on sequence numbers the TCP performs
certain tests on the sequence and acknowledgment numbers in the
segments to verify their acceptability.
接続が確立されるとデータがセグメントの交換によって伝えられる。セグメン
トはエラー（チェックサム試験不合格）あるいはネットワーク輻輳のために失
われるかも知れないから、TCPがすべてのセグメントの配送を保証するために
（タイムアウトの後に）再送を使う。重複セグメントがネットワークあるいは
TCP再送のために到着するかも知れない。シーケンス番号の章で論じられたよ
うに、TCPはそれらが受領可能かを確かめるためにセグメントのシーケンス番
号と確認番号のあるテストを実行する。
The sender of data keeps track of the next sequence number to use in
the variable SND.NXT. The receiver of data keeps track of the next
sequence number to expect in the variable RCV.NXT. The sender of data
keeps track of the oldest unacknowledged sequence number in the
variable SND.UNA. If the data flow is momentarily idle and all data
sent has been acknowledged then the three variables will be equal.
データの送り主は変数SND.NXTで次に使うべきシーケンス番号を記憶する。デー
タの受信者は変数RCV.NXTで次に期待するシーケンス番号を記憶する。データ
の送り主は変数SND.UNAで最も古い確認されていないシーケンス番号を記憶する。
もしデータの流れがしばらくなく、そしてすべての送られたデータが確認され
たなら、３つの変数は等しいであろう。
When the sender creates a segment and transmits it the sender advances
SND.NXT. When the receiver accepts a segment it advances RCV.NXT and
sends an acknowledgment. When the data sender receives an
acknowledgment it advances SND.UNA. The extent to which the values of
these variables differ is a measure of the delay in the communication.
The amount by which the variables are advanced is the length of the
data in the segment. Note that once in the ESTABLISHED state all
segments must carry current acknowledgment information.
送り主がセグメントを作って送信する時、送り主はSND.NXTを進める。受信者
がセグメントを受け入れる時RCV.NXTを進めて確認応答を送る。データ送り主
が確認応答を受け取る時SND.UNAを進める。これらの変数の値が異なる程度は
通信の遅れの基準である。変数が進められる量はセグメントのデータの長さで
ある。ESTABLISHED状態ですべてのセグメントが現在の確認情報を運ばなくて
はならないことに注意しなさい。
The CLOSE user call implies a push function, as does the FIN control
flag in an incoming segment.
クローズユーザ呼び出しはプッシュ機能を暗示する、そして入ってくるセグメ
ントのFIN制御装置フラグもそうである。
Retransmission Timeout
再送タイムアウト
Because of the variability of the networks that compose an
internetwork system and the wide range of uses of TCP connections the
retransmission timeout must be dynamically determined. One procedure
for determining a retransmission time out is given here as an
illustration.
インターネットワークシステムを構成するネットワークの変動性とTCP接続の
広範囲の使用のために再送タイムアウトは動的に決定しなくてはならない。再
送タイムアウトを決定する手順の１つが具体例としてここで与えられる。
An Example Retransmission Timeout Procedure
再送タイムアウト手順例
Measure the elapsed time between sending a data octet with a
particular sequence number and receiving an acknowledgment that
covers that sequence number (segments sent do not have to match
segments received). This measured elapsed time is the Round Trip
Time (RTT). Next compute a Smoothed Round Trip Time (SRTT) as:
特定のシーケンス番号でデータオクテットを送りそのシーケンス番号を覆
う確認応答（送信セグメントと受信セグメントが一致しなくてもよい）を
受け取る間の経過時間を測定しなさい。この計測した経過時間は往復遅延
時間（RTT）である。次にスムーズ往復遅延時間（SRTT）を以下のように
計算する：
SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)
and based on this, compute the retransmission timeout (RTO) as:
そしてこれに基づいて、再送タイムアウト（RTO）を以下のように計算する：
RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]
where UBOUND is an upper bound on the timeout (e.g., 1 minute),
LBOUND is a lower bound on the timeout (e.g., 1 second), ALPHA is
a smoothing factor (e.g., .8 to .9), and BETA is a delay variance
factor (e.g., 1.3 to 2.0).
UBOUNDがタイムアウトの上限（例えば、１分）で、LBOUNDはタイムアウト
の下限（例えば、１秒）で、ALPHAは平滑化因数（例えば、０．８から
０．９）で、BETAは遅延分散因数（例えば、１.３から２.０）である。
The Communication of Urgent Information
緊急情報の通信
The objective of the TCP urgent mechanism is to allow the sending user
to stimulate the receiving user to accept some urgent data and to
permit the receiving TCP to indicate to the receiving user when all
the currently known urgent data has been received by the user.
TCP緊急のメカニズムの目的は送信ユーザに受信ユーザにある緊急のデータを
受け入れるよう促進することを許し、受信ユーザがいつすべての現在周知の緊
急データを受け取るか指示することを受信TCPに許すことである。
This mechanism permits a point in the data stream to be designated as
the end of urgent information. Whenever this point is in advance of
the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
must tell the user to go into "urgent mode"; when the receive sequence
number catches up to the urgent pointer, the TCP must tell user to go
into "normal mode". If the urgent pointer is updated while the user
is in "urgent mode", the update will be invisible to the user.
このメカニズムはデータストリーム内の緊急情報の終わりを示すポインタを認
める。受信TCPにおいてこのポイントが受信シーケンス番号(RCV.NXT)より先に
ある時はいつでも、TCPはユーザに「緊急モード」に入るよう告げなくてはな
らない；受信シーケンス番号がが緊急ポインタに追いつく時、TCPはユーザに
「ノーマルモード」に入るように言わなくてはならない。もし緊急ポインタが、
ユーザが「緊急モード」にいる間に、最新のものにされるなら、更新はユーザ
に見えないであろう。
The method employs a urgent field which is carried in all segments
transmitted. The URG control flag indicates that the urgent field is
meaningful and must be added to the segment sequence number to yield
the urgent pointer. The absence of this flag indicates that there is
no urgent data outstanding.
手順は全部の伝送したセグメントで運ばれる緊急のフィールドを使用する。
URG制御装置フラグは緊急フィールドが意味があることを表し、そして緊急ポ
インタに譲ったセグメントシーケンス番号を加算しなくてはならない。このフ
ラグがないことは未処理の緊急のデータがないことを表す。
To send an urgent indication the user must also send at least one data
octet. If the sending user also indicates a push, timely delivery of
the urgent information to the destination process is enhanced.
緊急の指示を送るために、ユーザは少なくとも１つのデータオクテットを送ら
なくてはならない。もし送信ユーザが同じくプッシュを示すなら、着信プロセ
スへの緊急の情報のタイムリーな配送が要求される。
Managing the Window
ウィンドウを管理する
The window sent in each segment indicates the range of sequence
numbers the sender of the window (the data receiver) is currently
prepared to accept. There is an assumption that this is related to
the currently available data buffer space available for this
connection.
それぞれのセグメントで送られたウインドウは、ウィンドウの送り主（データ
受信者）が現在受け入れる用意ができているシーケンス番号の範囲を示す。こ
れはこの接続のために利用可能な現在のデータバッファスペースと関係がある
と仮定される。
Indicating a large window encourages transmissions. If more data
arrives than can be accepted, it will be discarded. This will result
in excessive retransmissions, adding unnecessarily to the load on the
network and the TCPs. Indicating a small window may restrict the
transmission of data to the point of introducing a round trip delay
between each new segment transmitted.
大きいウインドウを示すことは送信を奨励する。もし受け入れられるより多く
のデータが到着するなら、それは捨てられるであろう。これは、極端な再送を
結果として生じ、ネットワークとTCPに不必要に負荷に付け加える。小さいウ
インドウを示すことはそれぞれの伝達された新しいセグメントの間に伝送遅延
をもたらすくらいデータ伝送を限定するかも知れない。
The mechanisms provided allow a TCP to advertise a large window and to
subsequently advertise a much smaller window without having accepted
that much data. This, so called "shrinking the window," is strongly
discouraged. The robustness principle dictates that TCPs will not
shrink the window themselves, but will be prepared for such behavior
on the part of other TCPs.
規定されたメカニズムはTCPに大きいウィンドウを公表し、その後それほどデー
タを受け入れずにずっとより小さいウィンドウを公表することを許す。これの
「ウインドウを縮小」と呼ばれる物は、強い抑制を示す。安定原理はTCPがそ
れら自身のウインドウを縮小しないことを要求する、けれども他TCPの一部の
このような挙動に対する用意を要求する。
The sending TCP must be prepared to accept from the user and send at
least one octet of new data even if the send window is zero. The
sending TCP must regularly retransmit to the receiving TCP even when
the window is zero. Two minutes is recommended for the retransmission
interval when the window is zero. This retransmission is essential to
guarantee that when either TCP has a zero window the re-opening of the
window will be reliably reported to the other.
送信TCPはユーザから受け入れて、たとえ送信ウインドウがゼロであるとして
も、少なくとも新しいデータの１つのオクテットを送る用意ができているに違
いない。送信TCPは規則的に受信TCPにウインドウがゼロである時さえ再び送ら
なくてはならない。２分が、ウインドウがゼロである時の再送間隔に推薦され
ている。この再送はいずれかのTCPがゼロウインドウを持っている時、ウィン
ドウが再開したことを確実に他に報告できることを保証するために必須である。
When the receiving TCP has a zero window and a segment arrives it must
still send an acknowledgment showing its next expected sequence number
and current window (zero).
受信TCPがゼロウインドウを持っていそしてセグメントが到着する時、次に期
待するシーケンス番号を示す確認応答と現在のウインドウ（ゼロ）を示さなく
てはならない。
The sending TCP packages the data to be transmitted into segments
which fit the current window, and may repackage segments on the
retransmission queue. Such repackaging is not required, but may be
helpful.
送信TCPは現在のウィンドウに適したセグメントを送信するためにデータをパッ
ケージしたり、再送待ち行列上でセグメントを荷造りし直してもよい。このよ
うな荷造りし直すことは必要でないが助けになるだろう。
In a connection with a one-way data flow, the window information will
be carried in acknowledgment segments that all have the same sequence
number so there will be no way to reorder them if they arrive out of
order. This is not a serious problem, but it will allow the window
information to be on occasion temporarily based on old reports from
the data receiver. A refinement to avoid this problem is to act on
the window information from segments that carry the highest
acknowledgment number (that is segments with acknowledgment number
equal or greater than the highest previously received).
接続で一方向のデータフローで、ウインドウ情報はすべてが同じシーケンス番
号を持つ確認応答セグメントで運ばれるであろう、それでもし順序通りに来な
かった場合、再送を要求する方法がないであろう。これは重大な問題ではない
が、ウインドウ情報が時々一時的に古いデータ受信からの報告に基くことを許
すであろう。この問題を避けるための改善は最大きい確認応答を運ぶセグメン
ト（以前に受信したもっとも大きいの以上の確認番号を持つセグメント）から
のウインドウ情報で行動することである。
The window management procedure has significant influence on the
communication performance. The following comments are suggestions to
implementers.
ウインドウ管理手続きは通信性能に重要な影響を持っている。次のコメントは
実装者への示唆である。
Window Management Suggestions
ウインドウマネジメント示唆
Allocating a very small window causes data to be transmitted in
many small segments when better performance is achieved using
fewer large segments.
少ない大きいセグメントを使って良い性能が達成できる時、非常に小さい
ウインドウを割り当てることは、データを多くの小さいセグメントで伝達
する結果となる。
One suggestion for avoiding small windows is for the receiver to
defer updating a window until the additional allocation is at
least X percent of the maximum allocation possible for the
connection (where X might be 20 to 40).
小さいウィンドウを避けるための１つの示唆が受信者が接続のため追加の
割当てが最大の割当ての少なくともXパーセントになるまで、ウィンドウ
を更新することを延期することである（Xが２０から４０であろう）。
Another suggestion is for the sender to avoid sending small
segments by waiting until the window is large enough before
sending data. If the the user signals a push function then the
data must be sent even if it is a small segment.
もう１つの示唆が送り主がウインドウがデータを送るのに十分に大きくな
るまで待つことによって小さいセグメントを送るのを避けることである。
もしユーザがプッシュ機能を示すなら、小さいセグメントになったとして
もデータが送られなくてはならない。
Note that the acknowledgments should not be delayed or unnecessary
retransmissions will result. One strategy would be to send an
acknowledgment when a small segment arrives (with out updating the
window information), and then to send another acknowledgment with
new window information when the window is larger.
確認応答が遅れるべきではない、あるいは不必要な再送が結果として生じ
ることに注意しなさい。１つの戦略は、（ウインドウ情報を更新していな
い）小さいセグメントが到着する時、確認応答を送ることであるであろう、
そしてウインドウがより大きくなる時、新しいウインドウ情報ともう１つ
の確認応答を送る。
The segment sent to probe a zero window may also begin a break up
of transmitted data into smaller and smaller segments. If a
segment containing a single data octet sent to probe a zero window
is accepted, it consumes one octet of the window now available.
If the sending TCP simply sends as much as it can whenever the
window is non zero, the transmitted data will be broken into
alternating big and small segments. As time goes on, occasional
pauses in the receiver making window allocation available will
result in breaking the big segments into a small and not quite so
big pair. And after a while the data transmission will be in
mostly small segments.
ゼロウィンドウを探るために送るセグメントは、とても小さなセグメント
の中に送信データの一部を入れてもよい。もしゼロウィンドウを探るため
に送られたひとつのデータオクテットを含んでいるセグメントが受け入れ
られるなら、それは今利用可能なウィンドウの１つのオクテットを消費す
る。もし送信TCPが、ウインドウがゼロでない時はいつでも、遅れる限り
の量のデータを送るなら、送信データは大小の交互のセグメントに分解さ
れるであろう。時間が経つにつれて、受信者での時折のウインドウ割付け
の休止は大きなセグメントを小さくそしてそう大きくないペアにわけるで
あろう。そしてしばらくの後データ伝送はたいてい小さいセグメントにな
るであろう。
The suggestion here is that the TCP implementations need to
actively attempt to combine small window allocations into larger
windows, since the mechanisms for managing the window tend to lead
to many small windows in the simplest minded implementations.
示唆は、最も単純な実装ではウィンドウを管理するための機構が多くの小
さいウィンドウを導く傾向があるから、TCP実装はより大きいウインドウ
の中に小さいウインドウ割当てを結合しようと活発に試みる必要があると
いうことである。
3.8. Interfaces
インタフェース
There are of course two interfaces of concern: the user/TCP interface
and the TCP/lower-level interface. We have a fairly elaborate model
of the user/TCP interface, but the interface to the lower level
protocol module is left unspecified here, since it will be specified
in detail by the specification of the lowel level protocol. For the
case that the lower level is IP we note some of the parameter values
that TCPs might use.
関心のある２つのインタフェースがある：ユーザ／TCPインタフェースと、
TCP／低レベルインタフェース。我々はユーザ／TCPインタフェースのかなり手
が込んだモデルを持っている、しかしより低レベルプロトコルモジュールへの
インタフェースは、それが低レベルプロトコルの仕様で詳細で規定されるであ
ろうから、ここで規定されないままにしておかれる。低レベルがIPである場合、
TCPがパラメータ値のいくつかを使うかもしれないことを注意しておく。
User/TCP Interface
ユーザ／TCPインタフェース
The following functional description of user commands to the TCP is,
at best, fictional, since every operating system will have different
facilities. Consequently, we must warn readers that different TCP
implementations may have different user interfaces. However, all
TCPs must provide a certain minimum set of services to guarantee
that all TCP implementations can support the same protocol
hierarchy. This section specifies the functional interfaces
required of all TCP implementations.
次のTCPへのユーザコマンドの機能説明は、せいぜい、すべてのオペレーティ
ング・システムが異なった機能を持つであろうので、架空である。従って、
我々は読者に異なったTCP実装が異なったユーザ・インタフェースを持ってい
るかも知れないことを警告しなくてはならない。しかしながら、すべてのTCP
実装が同じプロトコル階層をサポートすることができることを保証するため、
すべてのTCPがあるサービスの最小のセットを供給しなくてはならない。この
セクションはすべてのTCP実装に要求された機能的なインタフェースを規定す
る。
TCP User Commands
TCPユーザコマンド
The following sections functionally characterize a USER/TCP
interface. The notation used is similar to most procedure or
function calls in high level languages, but this usage is not
meant to rule out trap type service calls (e.g., SVCs, UUOs,
EMTs).
次のセクションは機能上ユーザ／TCPインタフェースを述べる。使われた
表記法は高級言語でたいていの手順あるいは関数呼出しに類似している、
しかしこの使用は外部割込型のサービス呼出を意図しない（例えば、SVCs、
UUOs、ＥＭＴ）。
The user commands described below specify the basic functions the
TCP must perform to support interprocess communication.
Individual implementations must define their own exact format, and
may provide combinations or subsets of the basic functions in
single calls. In particular, some implementations may wish to
automatically OPEN a connection on the first SEND or RECEIVE
issued by the user for a given connection.
下に記述されたユーザコマンドはTCPがプロセス間通信をサポートするた
めに実行しなくてはならない基本機能を規定する。個別の実装がそれら自
身の正確なフォーマットを明記しなくてはならなくて、そしてひとつの呼
び出しで基本機能の組合せあるいはサブセットを供給してもよい。特に、
ある実装がユーザの公表した既定接続のため、最初のSENDあるいはRECEIVE
で自動的に接続をOPENすることを望むかも知れない。
In providing interprocess communication facilities, the TCP must
not only accept commands, but must also return information to the
processes it serves. The latter consists of:
プロセス間通信施設を供給することにおいて、TCPはただコマンドを受け
入れることだけをし、そして給仕をするプロセスに情報を返さなくてはな
らない。後者は成る：
(a) general information about a connection (e.g., interrupts,
remote close, binding of unspecified foreign socket).
(a) 接続についての一般情報（例えば、割り込み、遠隔の終了、不特定
の外ソケットの割当）。
(b) replies to specific user commands indicating success or
various types of failure.
(b) 特定のユーザコマンドが成功あるいは種々のタイプの失敗を示す返
事。
Open
オープン
Format: OPEN (local port, foreign socket, active/passive
[, timeout] [, precedence] [, security/compartment] [, options])
-> local connection name
フォーマット：OPEN(ローカルポート,外ソケット,能動／受動態
[,タイムアウト][,優先順位][,安全保証／隔離][,オプション])
->ローカル接続名
We assume that the local TCP is aware of the identity of the
processes it serves and will check the authority of the process
to use the connection specified. Depending upon the
implementation of the TCP, the local network and TCP identifiers
for the source address will either be supplied by the TCP or the
lower level protocol (e.g., IP). These considerations are the
result of concern about security, to the extent that no TCP be
able to masquerade as another one, and so on. Similarly, no
process can masquerade as another without the collusion of the
TCP.
我々はローカルTCPがプロセス識別し、給仕し、規定した接続を使うプ
ロセスの権限をチェックする、と想定する。TCPの実装により、発信ア
ドレスとしてのローカルネットワークとTCPの識別子はTCPあるいは下位
プロトコル（例えば、IP）が供給する。これらの考慮は安全についての
考慮の結果で、TCPが他のTCPになりすますことが可能ではないためであ
る。同様に、プロセスがTCPの共謀無しでたのプロセスのふりをするこ
とができない。
If the active/passive flag is set to passive, then this is a
call to LISTEN for an incoming connection. A passive open may
have either a fully specified foreign socket to wait for a
particular connection or an unspecified foreign socket to wait
for any call. A fully specified passive call can be made active
by the subsequent execution of a SEND.
もし能動／受動なフラグが受動にセットされるなら、これは入接続を
LISTENする呼び出しである。受動的なオープンは、特定の接続を待つた
め完全に規定した外ソケットか、あるいは誰でも呼ぶのを待つべき不特
定の外ソケットを持っているだろう。完全に規定する受動的な呼び出し
が次のSENDの実行によって能動にすることができる。
A transmission control block (TCB) is created and partially
filled in with data from the OPEN command parameters.
送信制御ブロック（TCB）が作られて、そしてOPENコマンドパラメータ
からのデータで部分的に書き込まれる。
On an active OPEN command, the TCP will begin the procedure to
synchronize (i.e., establish) the connection at once.
能動OPENコマンドでTCPはすぐに接続同期手順を始めるであろう（すな
わち、確立する）。
The timeout, if present, permits the caller to set up a timeout
for all data submitted to TCP. If data is not successfully
delivered to the destination within the timeout period, the TCP
will abort the connection. The present global default is five
minutes.
タイムアウトは、もし存在しているなら、発呼者にTCPに提出したすべ
てのデータのタイムアウトを設けるのを許す。もしデータがタイムアウ
ト期間の内に着信者に正常に届けられないなら、TCPは接続を中止する
であろう。現在のグローバルなデフォルトは５分である。
The TCP or some component of the operating system will verify
the users authority to open a connection with the specified
precedence or security/compartment. The absence of precedence
or security/compartment specification in the OPEN call indicates
the default values must be used.
TCPあるいはいずれかのオペレーティング・システムの構成要素が規定
する優先順位あるいは安全保証／隔離で接続を開くためにユーザ権限を
実証するであろう。OPEN呼出での優先順位あるいは安全保証／隔離規定
の欠如はデフォルト値を使うことを意味する。
TCP will accept incoming requests as matching only if the
security/compartment information is exactly the same and only if
the precedence is equal to or higher than the precedence
requested in the OPEN call.
安全保証／隔離情報が正確に同じである場合に限り、そして優先順位が
等しいあるいはOPEN呼び出しで求めたより高い場合に限り、TCPが入っ
てくるリクエストを受け入れるであろう。
The precedence for the connection is the higher of the values
requested in the OPEN call and received from the incoming
request, and fixed at that value for the life of the
connection.Implementers may want to give the user control of
this precedence negotiation. For example, the user might be
allowed to specify that the precedence must be exactly matched,
or that any attempt to raise the precedence be confirmed by the
user.
接続の優先順位は、OPEN呼び出しで求められたものと入ってくるリクエ
ストから受け取られてたものより高く、そして接続の寿命の間固定され
る。実装者はユーザにこの優先順位交渉の制御を与えることを望むかも
知れない。例えば、ユーザに優先順位が正確に一致しなくてはならない
ことを明示することを許すかも知れないし、あるいは優先順位を引き上
げるどんな試みもユーザに許すかも知れない。
A local connection name will be returned to the user by the TCP.
The local connection name can then be used as a short hand term
for the connection defined by the <local socket, foreign socket>
pair.
ローカル接続名がTCPによってユーザに返されるであろう。ローカル接
続名は＜ローカルソケット、外ソケット＞ペアによって明記される接続
の短縮形として用いることができる。
Send
送信
Format: SEND (local connection name, buffer address, byte
count, PUSH flag, URGENT flag [,timeout])
フォーマット：SEND（ローカル接続名,バッファーアドレス,バイト数,
PUSHフラグ,緊急フラグ[,タイムアウト]）
This call causes the data contained in the indicated user buffer
to be sent on the indicated connection. If the connection has
not been opened, the SEND is considered an error. Some
implementations may allow users to SEND first; in which case, an
automatic OPEN would be done. If the calling process is not
authorized to use this connection, an error is returned.
この呼び出しは示されたユーザバッファに含んでるデータを示された接
続の上に送る。もし接続が開かれてなかったら、SENDはエラーであると
考えられる。ある実装がユーザに最初に送信することを許すかも知れな
い；その場合、自動的なOPENがされるであろう。もし呼出しプロセスが
この接続を使うために権限を与えられないなら、エラーが返される。
If the PUSH flag is set, the data must be transmitted promptly
to the receiver, and the PUSH bit will be set in the last TCP
segment created from the buffer. If the PUSH flag is not set,
the data may be combined with data from subsequent SENDs for
transmission efficiency.
もしPUSHフラグがセットされるなら、データは、受信者に、即座に伝達
されなくてはならない、そして最後のバッファーから作ったTCPセグメ
ントのPUSHビットがセットされるであろう。もしPUSHフラグがセットさ
れないなら、データは伝送効率のために次のSENDsでのデータと一緒に
されるかも知れない。
If the URGENT flag is set, segments sent to the destination TCP
will have the urgent pointer set. The receiving TCP will signal
the urgent condition to the receiving process if the urgent
pointer indicates that data preceding the urgent pointer has not
been consumed by the receiving process. The purpose of urgent
is to stimulate the receiver to process the urgent data and to
indicate to the receiver when all the currently known urgent
data has been received. The number of times the sending user's
TCP signals urgent will not necessarily be equal to the number
of times the receiving user will be notified of the presence of
urgent data.
もし緊急のフラグがセットされるなら、着信TCPに送られたセグメント
が緊急ポインタセットを持つであろう。受信TCPは、もし緊急ポインタ
が緊急ポインタより先に起こっているデータが受信プロセスによって消
費されなかったことを表すなら、受信プロセスに緊急の状態を示すであ
ろう。緊急の目的は受信者に緊急データを処理して、そして受信者にい
つすべての現在周知の緊急のデータが受け取られたか示すよう促進する
ことである。送信ユーザのTCPが緊急で信号を送る回数は受信ユーザが
緊急のデータの存在の知らされる回数に等しくないであろう。
If no foreign socket was specified in the OPEN, but the
connection is established (e.g., because a LISTENing connection
has become specific due to a foreign segment arriving for the
local socket), then the designated buffer is sent to the implied
foreign socket. Users who make use of OPEN with an unspecified
foreign socket can make use of SEND without ever explicitly
knowing the foreign socket address.
もし外部ソケットがOPENで規定されなかったが、接続が確立さたなら
（例えば、着外部セグメントのためにLISTENing接続が開始し、ローカ
ルソケットが指定された）、示されたバッファは暗黙の外部ソケットに
送られる。不特定の外部ソケットでOPENを利用するユーザが常に明示的
に外部ソケットアドレスを知らないでSENDを利用することができる。
However, if a SEND is attempted before the foreign socket
becomes specified, an error will be returned. Users can use the
STATUS call to determine the status of the connection. In some
implementations the TCP may notify the user when an unspecified
socket is bound.
しかしながら、もしSENDが外部ソケットが指定される前に試みられるな
ら、エラーが返されるであろう。ユーザが接続の状態を決定するSTATUS
呼び出しを使うことができる。ある実装でTCPは、不特定のソケットが
つながられる時、ユーザに通知するかも知れない。
If a timeout is specified, the current user timeout for this
connection is changed to the new one.
もしタイムアウトが規定されるなら、この接続のための現行ユーザタイ
ムアウトは新しいものに変えられる。
In the simplest implementation, SEND would not return control to
the sending process until either the transmission was complete
or the timeout had been exceeded. However, this simple method
is both subject to deadlocks (for example, both sides of the
connection might try to do SENDs before doing any RECEIVEs) and
offers poor performance, so it is not recommended. A more
sophisticated implementation would return immediately to allow
the process to run concurrently with network I/O, and,
furthermore, to allow multiple SENDs to be in progress.
Multiple SENDs are served in first come, first served order, so
the TCP will queue those it cannot service immediately.
最も単純な実装で、SENDは、あるいは送信が完了する、あるいはタイム
アウトがおきるまで、送信プロセスに制御を返さないであろう。しかし
ながら、この単純な手順は両側の行き詰まり（例えば、接続の両側が受
信をする前にSENDsをしようとするかも知れない）を受けやすく、低い
性能を提供するため、推薦されていない。いっそう洗練された実装はプ
ロセスにネットワーク入出力と同時に走ることを許し、さらに、多数の
SENDを進行させることを許すためにすぐに戻るであろう。複数のSENDは
最初に来るものを最初順番で実施され、TCPはすぐにサービスできない
ものを待ち行列に入れるであろう。
We have implicitly assumed an asynchronous user interface in
which a SEND later elicits some kind of SIGNAL or
pseudo-interrupt from the serving TCP. An alternative is to
return a response immediately. For instance, SENDs might return
immediate local acknowledgment, even if the segment sent had not
been acknowledged by the distant TCP. We could optimistically
assume eventual success. If we are wrong, the connection will
close anyway due to the timeout. In implementations of this
kind (synchronous), there will still be some asynchronous
signals, but these will deal with the connection itself, and not
with specific segments or buffers.
我々は暗黙のうちに、TCPからのあるシグナルあるいは疑似割り込みに
よる、後からSENDを引き出す非同期のユーザ・インタフェースを仮定し
た。代案はすぐに応答を返すことである。例えば、SENDは、たとえ送ら
れたセグメントが（まだ）遠いTCPによって確認されていなかったとし
ても、即刻のローカル確認を返すかも知れない。我々は楽しそうに終局
の成功を仮定することができる。もし我々が間違っていても、接続はタ
イムアウトのためにとにかく終了するであろう。この（同期的な）種類
の実装で、ある非同期のシグナルがまだあるであろう、しかしこれらは
特定のセグメントあるいはバッファーではなく、接続それ自身を扱うで
あろう。
In order for the process to distinguish among error or success
indications for different SENDs, it might be appropriate for the
buffer address to be returned along with the coded response to
the SEND request. TCP-to-user signals are discussed below,
indicating the information which should be returned to the
calling process.
プロセスが異なったSENDでエラーあるいは成功表示の区別のために、
バッファーアドレスがSEND要求の応答とともに返されることは適切であ
るかも知れない。呼出しプロセスに返されるべきである情報を示して、
TCPからユーザへのシグナルが以下に論じられる。
Receive
受信
Format: RECEIVE (local connection name, buffer address, byte
count) -> byte count, urgent flag, push flag
フォーマット：RECEIVE(ローカル接続名,バッファーアドレス,バイト数)
->バイト数,緊急フラグ,プッシュフラグ
This command allocates a receiving buffer associated with the
specified connection. If no OPEN precedes this command or the
calling process is not authorized to use this connection, an
error is returned.
このコマンドは規定する接続と結び付けられた受信バッファを割り当て
る。もしオープンがこのコマンドに先に起こらないか、あるいは呼出し
プロセスがこの接続を使うために公認されないなら、エラーが返される。
In the simplest implementation, control would not return to the
calling program until either the buffer was filled, or some
error occurred, but this scheme is highly subject to deadlocks.
A more sophisticated implementation would permit several
RECEIVEs to be outstanding at once. These would be filled as
segments arrive. This strategy permits increased throughput at
the cost of a more elaborate scheme (possibly asynchronous) to
notify the calling program that a PUSH has been seen or a buffer
filled.
最も単純な実装で、制御が、バッファーが満たされるか、あるいはある
エラーが起きるまで、呼出しプログラムに戻らないであろう、しかしこ
の計画は大いに行き詰まりやすい。いっそう洗練された実装はいくつか
の受信を直ちに未処理にするのを許すであろう。これらは、セグメント
が到着するとき、満たされるであろう。この戦略は処理能力の増加を認
める、いっそう入念なコスト計画において呼出しプログラムに（多分非
同期で）、PUSHがあった、あるいはバッファがいっぱいになったこと、
通知する。
If enough data arrive to fill the buffer before a PUSH is seen,
the PUSH flag will not be set in the response to the RECEIVE.
The buffer will be filled with as much data as it can hold. If
a PUSH is seen before the buffer is filled the buffer will be
returned partially filled and PUSH indicated.
もし十分なデータが、PUSHがある前に、バッファを満たすために来るな
ら、PUSHフラグはRECEIVEの応答でセットされないであろう。バッファ
はできる限り多くのデータで満たされるであろう。もしプッシュが、
バッファが満たされる前にあなら、バッファーは部分的に満たされて返
され、そしてPUSHが示されるであろう。
If there is urgent data the user will have been informed as soon
as it arrived via a TCP-to-user signal. The receiving user
should thus be in "urgent mode". If the URGENT flag is on,
additional urgent data remains. If the URGENT flag is off, this
call to RECEIVE has returned all the urgent data, and the user
may now leave "urgent mode". Note that data following the
urgent pointer (non-urgent data) cannot be delivered to the user
in the same buffer with preceeding urgent data unless the
boundary is clearly marked for the user.
もし緊急のデータがあるなら、ユーザは、それがTCPからユーザシグナ
ルによって到着するとすぐに、知らせられるであろう。受信ユーザはそ
れで「緊急モード」になるべきである。もしURGENTのフラグがオンであ
るなら、追加の緊急のデータが残っている。もし緊急フラグがオフなら、
このRECEIVEへの呼び出しはすべての緊急のデータを返した、そしてユー
ザは今「緊急モード」を去ってもよい。緊急ポインタの後に続いている
データ（緊急でないデータ）が、境界がユーザに明らかにマークが付け
られていないなら、前の緊急のデータと同じバッファでユーザに届ける
ことができないことに注意しなさい。
To distinguish among several outstanding RECEIVEs and to take
care of the case that a buffer is not completely filled, the
return code is accompanied by both a buffer pointer and a byte
count indicating the actual length of the data received.
いくつかの未処理の受信間を識別して、そしてバッファが完全に満たさ
れない場合の面倒を見るために、戻りコードはバッファーポインタと受
け取られたデータの実際長さを示しているバイト数両方になる。
Alternative implementations of RECEIVE might have the TCP
allocate buffer storage, or the TCP might share a ring buffer
with the user.
受信の代わりの実装がTCPがバッファ記憶装置を割り当てるようにする
かも知れない、あるいはTCPはユーザとリングバッファを共有するかも
知れない。
Close
クローズ
Format: CLOSE (local connection name)
フォーマット:CLOSE(ローカル接続名)
This command causes the connection specified to be closed. If
the connection is not open or the calling process is not
authorized to use this connection, an error is returned.
Closing connections is intended to be a graceful operation in
the sense that outstanding SENDs will be transmitted (and
retransmitted), as flow control permits, until all have been
serviced. Thus, it should be acceptable to make several SEND
calls, followed by a CLOSE, and expect all the data to be sent
to the destination. It should also be clear that users should
continue to RECEIVE on CLOSING connections, since the other side
may be trying to transmit the last of its data. Thus, CLOSE
means "I have no more to send" but does not mean "I will not
receive any more." It may happen (if the user level protocol is
not well thought out) that the closing side is unable to get rid
of all its data before timing out. In this event, CLOSE turns
into ABORT, and the closing TCP gives up.
このコマンドは指定した接続の終了を起こす。もし接続が開いていない
か、あるいは呼出しプロセスがこの接続を使うために権限を与えられな
いなら、エラーが返される。接続を閉じることは、サービスが行われフ
ロー制御が許す限り、未処理のSENDが伝達される（再送させる）ような
上品な処理を意図する。それで、CLOSEの後に続くいくつかのSEND呼び
出しを受け入れ、全てのデータを着信者へ送るべきである。ユーザが、
他の側が最後のデータを伝達しようとしているかも知れないので、
CLOSEした接続にRECEIVEを継続することは同じく明確であるべきである。
それで、CLOSEが「私が送るべきものがこれ以上ない」ことを意味する
が、しかし「私はこれ以上なにも受けないであろう。」ことを意味しな
い。終了した側がタイムアウトする前にデータを追い出すことが不可能
であるということがたまたま起きるかも知れない（もしユーザレベルプ
ロトコルが熟考されていないなら）。このイベントで、CLOSEがABORTに
変わる、そして終了中のTCPはあきらめる。
The user may CLOSE the connection at any time on his own
initiative, or in response to various prompts from the TCP
(e.g., remote close executed, transmission timeout exceeded,
destination inaccessible).
ユーザは彼自身の主導権で、あるいは種々のせりふ付けに応えてTCPか
らいつでも接続をCLOSEしてもよい（例えば、実行された遠隔の終了、
タイムアウトが超えた送信、アクセスできない着信）。
Because closing a connection requires communication with the
foreign TCP, connections may remain in the closing state for a
short time. Attempts to reopen the connection before the TCP
replies to the CLOSE command will result in error responses.
接続を閉じることは外部のTCPと通信を必要とするから、接続が短期間
の間終わりの状態で残っているかも知れない。CLOSEコマンドにTCP答え
の前に接続を再開する試みがエラー応答をもたらすであろう。
Close also implies push function.
クローズが同じくプッシュ機能を暗示する。
Status
ステータス
Format: STATUS (local connection name) -> status data
フォーマット:STATUS(ローカル接続名)->ステータスデータ
This is an implementation dependent user command and could be
excluded without adverse effect. Information returned would
typically come from the TCB associated with the connection.
これは実装に依存するユーザコマンドであって、そして悪影響無しで除
去されることができた。返された情報が典型的に接続と結び付けられて
TCBから来るであろう。
This command returns a data block containing the following
information:
このコマンドは次の情報を含んでいるデータブロックを返す：
local socket,
ローカルソケット
foreign socket,
外部ソケット
local connection name,
ローカル接続名
receive window,
受信ウインドウ
send window,
送信ウインドウ
connection state,
接続状態
number of buffers awaiting acknowledgment,
確認応答を待ち受けている、バッファーの数
number of buffers pending receipt,
バッファーに保留中の受入の番号
urgent state,
緊急の状態
precedence,
優先順位
security/compartment,
安全保証／隔離
and transmission timeout.
そして送信タイムアウト
Depending on the state of the connection, or on the
implementation itself, some of this information may not be
available or meaningful. If the calling process is not
authorized to use this connection, an error is returned. This
prevents unauthorized processes from gaining information about a
connection.
接続の状態、あるいは実装それ自身によって、この情報のいくらかが利
用可能であるか、あるいは有意義ではないかも知れない。もし呼出しプ
ロセスがこの接続を使うために権限を与えられないなら、エラーが返さ
れる。これは無許可のプロセスが接続についての情報を得るのを阻止す
る。
Abort
アボート
Format: ABORT (local connection name)
フォーマット:ABORT(ローカル接続名)
This command causes all pending SENDs and RECEIVES to be
aborted, the TCB to be removed, and a special RESET message to
be sent to the TCP on the other side of the connection.
Depending on the implementation, users may receive abort
indications for each outstanding SEND or RECEIVE, or may simply
receive an ABORT-acknowledgment.
このコマンドはすべて保留中のSENDとRECEIVESの中止、TCBの除去、そ
して他の接続の側のTCPに特別なリセットメッセージの送信、を起こす。
実装により、ユーザがそれぞれの未処理のSENDあるいはRECEIVEの中止
指示を受け取るかもしれない、あるいは、ただABORT確認応答を受け取
るかも知れない。
TCP-to-User Messages
TCPからユーザへのメッセージ
It is assumed that the operating system environment provides a
means for the TCP to asynchronously signal the user program. When
the TCP does signal a user program, certain information is passed
to the user. Often in the specification the information will be
an error message. In other cases there will be information
relating to the completion of processing a SEND or RECEIVE or
other user call.
運営上のシステム環境がTCPに非同期にユーザプログラムへ信号を送る手
段を供給すると想定される。TCPがユーザプログラムに信号を送る時、あ
る特定の情報をユーザに渡す。仕様の中で情報はしばしばエラーメッセー
ジであるであろう。他の場合にSENDあるいはRECEIVEを処理の完了あるい
は他のユーザ呼び出しに関連している情報があるであろう。
The following information is provided:
次の情報は供給される：
Local Connection Name Always
ローカル接続名 常に
Response String Always
応答文字列 常に
Buffer Address Send & Receive
バッファーアドレス 送信＆受信
Byte count (counts bytes received) Receive
バイト数（受信バイト数） 受信
Push flag Receive
プッシュフラグ 受信
Urgent flag Receive
緊急 フラグ板石受信
TCP/Lower-Level Interface
TCP／下位レベルインタフェース
The TCP calls on a lower level protocol module to actually send and
receive information over a network. One case is that of the ARPA
internetwork system where the lower level module is the Internet
Protocol (IP) [2].
CPは下位レベルプロトコルモジュールにネットワークの上で実際に情報を送
信し、受信することを求める。ARPAインターネットワークシステムの事例は
下位レベルモジュールがインターネット・プロトコル(IP)[2]である。
If the lower level protocol is IP it provides arguments for a type
of service and for a time to live. TCP uses the following settings
for these parameters:
もしより下位レベルプロトコルがIPであるなら、サービス種別と生存期間の
ための引数を提供する。TCPがこれらのパラメータのために次の設定を使う：
Type of Service = Precedence: routine, Delay: normal, Throughput:
normal, Reliability: normal; or 00000000.
タイプオブサービス＝優先順位：慣例、遅延：通常、スループット：通常、
安定性：標準的、あるいは00000000。
Time to Live = one minute, or 00111100.
有効時間＝１分、あるいは00111100。
Note that the assumed maximum segment lifetime is two minutes.
Here we explicitly ask that a segment be destroyed if it cannot
be delivered by the internet system within one minute.
想定された最大セグメントライフタイムが２分であることに注意しなさ
い。ここで我々は明示的にセグメントが、もしそれが１分の内にインター
ネット系によって配達されることができないなら、破壊されることを頼
む。
If the lower level is IP (or other protocol that provides this
feature) and source routing is used, the interface must allow the
route information to be communicated. This is especially important
so that the source and destination addresses used in the TCP
checksum be the originating source and ultimate destination. It is
also important to preserve the return route to answer connection
requests.
もしより低いレベルがIP（あるいはこの特徴を供給する他のプロトコル）で
あり、そして発信者ルーティングが使われるなら、インタフェースは径路情
報に連絡を取られることを許さなくてはならない。これは、アドレスがTCP
チェックサムで使った発信と着信が出発点の発信と最後の着信であるので、
特に重要である。接続要求に答えるためにリターンルートを維持することは
同じく重要である。
Any lower level protocol will have to provide the source address,
destination address, and protocol fields, and some way to determine
the "TCP length", both to provide the functional equivlent service
of IP and to be used in the TCP checksum.
どんなより下位レベルプロトコルでも発信アドレス、宛先アドレスとプロト
コルフィールドと「TCP長さ」を決定することについて、IPに機能的な等し
いサービスを供給して、そしてTCPチェックサムで使われるいずれかの方法
を供給しなければならないであろう。
3.9. Event Processing
イベント処理
The processing depicted in this section is an example of one possible
implementation. Other implementations may have slightly different
processing sequences, but they should differ from those in this
section only in detail, not in substance.
このセクションで描写される処理は１つの可能な実装の例である。他の実装が
わずかに異なった処理シーケンスを持っているかも知れない、しかしそれらは、
要するにではなく、詳細でだけこのセクションでそれらとは違うべきである。
The activity of the TCP can be characterized as responding to events.
The events that occur can be cast into three categories: user calls,
arriving segments, and timeouts. This section describes the
processing the TCP does in response to each of the events. In many
cases the processing required depends on the state of the connection.
TCPの活動はイベントに返答していると述べられることができる。起こるイベ
ントは３つのカテゴリの中に分けれる：ユーザ呼び出し、セグメントの到着と
タイムアウト。このセクションはTCPがイベントのそれぞれに応えてする処理
を記述する。多くの場合必要とされる処理は接続の状態に頼る。
Events that occur:
起こるイベント：
User Calls
ユーザ呼び出し
OPEN
SEND
RECEIVE
CLOSE
ABORT
STATUS
Arriving Segments
セグメントの到着
SEGMENT ARRIVES
Timeouts
タイムアウト
USER TIMEOUT
RETRANSMISSION TIMEOUT
TIME-WAIT TIMEOUT
The model of the TCP/user interface is that user commands receive an
immediate return and possibly a delayed response via an event or
pseudo interrupt. In the following descriptions, the term "signal"
means cause a delayed response.
TCP／ユーザ・インタフェースのモデルはユーザコマンドが即時にリターンし、
多分少し遅れてイベントあるいは疑似割り込みによって応答を受けるというこ
とである。次の記載で、用語「信号」遅延応答の理由を意味する。
Error responses are given as character strings. For example, user
commands referencing connections that do not exist receive "error:
connection not open".
エラー応答が文字列として与えられる。例えば、存在しない接続を参照するユー
ザコマンドが受信する「エラー：開いていない接続」。
Please note in the following that all arithmetic on sequence numbers,
acknowledgment numbers, windows, et cetera, is modulo 2**32 the size
of the sequence number space. Also note that "=<" means less than or
equal to (modulo 2**32).
どうか以下ですべての算術がシーケンス番号、アクノレッジメント数、ウイン
ドウなどで、シーケンス番号スペースの大きさが、モジュロ2**32であること
に注意してください。同じく"=<"が（モジュロが2**32）以下を意味するきと
に注意しなさい。そうすること。
A natural way to think about processing incoming segments is to
imagine that they are first tested for proper sequence number (i.e.,
that their contents lie in the range of the expected "receive window"
in the sequence number space) and then that they are generally queued
and processed in sequence number order.
入ってくるセグメントを処理することについて考える自然の方法がそれらが最
初に適切なシーケンス番号についてテストされると想像することである（すな
わち、それらの中身はシーケンス番号スペースで期待された「受信ウインドウ」
の範囲でにある）そしてそれらが一般に待ち行列に入れられて、そしてシーケ
ンス番号順序で処理されること。
When a segment overlaps other already received segments we reconstruct
the segment to contain just the new data, and adjust the header fields
to be consistent.
セグメントが他のすでに受け取ったセグメントと重なり合う時、我々はちょう
ど新しいデータを含んでいるセグメントを再構築して、そしてヘッダーフィー
ルドが一貫しているように調整する。
Note that if no state change is mentioned the TCP stays in the same
state.
もし状態変更が述べられないなら、TCPが同じ状態で留まることに注意しなさ
い。
OPEN Call
OPEN呼出し
CLOSED STATE (i.e., TCB does not exist)
CLOSED状態(つまり,TCBが存在しない)
Create a new transmission control block (TCB) to hold connection
state information. Fill in local socket identifier, foreign
socket, precedence, security/compartment, and user timeout
information. Note that some parts of the foreign socket may be
unspecified in a passive OPEN and are to be filled in by the
parameters of the incoming SYN segment. Verify the security and
precedence requested are allowed for this user, if not return
"error: precedence not allowed" or "error: security/compartment
not allowed." If passive enter the LISTEN state and return. If
active and the foreign socket is unspecified, return "error:
foreign socket unspecified"; if active and the foreign socket is
specified, issue a SYN segment. An initial send sequence number
(ISS) is selected. A SYN segment of the form <SEQ=ISS><CTL=SYN>
is sent. Set SND.UNA to ISS, SND.NXT to ISS+1, enter SYN-SENT
state, and return.
接続状態情報を持つために新しい送信制御ブロック（TCB）を作りなさい。
ローカルソケット識別子、外部ソケット、優先順位、安全保証／隔離とユー
ザタイムアウト情報を記入しなさい。外部ソケットのある部分が受動的な
OPENで不特定であるかも知れなくて、そして入ってくるSYNセグメントの
パラメータによって記入されるはずであることに注意しなさい。求められ
た安全と優先順位がこのユーザに許されるかを、もしそうでなければ、
「エラー：優先順位が許さなかった」あるいは「エラー：安全保証／隔離
が許さなかった」を返しなさい。もし受動的であるならLISTEN状態に入っ
て、そしてリターンしなさい。もし能動態で外部ソケットが不特定である
なら、「エラー：特定されていない外部ソケット」をリターンしなさい；
もし能動態で、そして外部ソケットが規定されるなら、SYNセグメントを
発行しなさい。最初の送信シーケンス番号(ISS)が選ばれる。書式
<SEQ=ISS><CTL=SYN>のSYNセグメントが送られる。SND.UNAをISS、SND.NXT
をISS+1にセットして、SYN-SENT状態に入って、そしてリターンしなさい。
If the caller does not have access to the local socket specified,
return "error: connection illegal for this process". If there is
no room to create a new connection, return "error: insufficient
resources".
もし発呼者が指定されたローカルソケットへのアクセスができないなら、
「エラー：このプロセスでは違反の接続」とリターンしなさい。もし新し
い接続を作る空領域がないなら、「エラー：不十分な資源」とリターンし
なさい。
LISTEN STATE
LISTEN状態
If active and the foreign socket is specified, then change the
connection from passive to active, select an ISS. Send a SYN
segment, set SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT
state. Data associated with SEND may be sent with SYN segment or
queued for transmission after entering ESTABLISHED state. The
urgent bit if requested in the command must be sent with the data
segments sent as a result of this command. If there is no room to
queue the request, respond with "error: insufficient resources".
If Foreign socket was not specified, then return "error: foreign
socket unspecified".
もし能動態で外部ソケットが規定されるなら、受動態から能動態まで接続
を変えて、ISSを選びなさい。SYNセグメントを送って、SND.UNAをISS、
SND.NXTをISS+1へセットしなさい。SYN-SENT状態に入りなさい。SENDと結
び付けられたデータがSYNセグメントで送られるか、あるいはESTABLISHED
状態に入った後で送信のために待ち行列に入れられるかも知れない。緊急
のビットはもしコマンドで求められるならこのコマンドの結果として送ら
れたデータセグメントで送られなくてはならない。もしリクエストを待ち
行列に入れる空領域がないなら、「エラー：不十分な資源」で応答しなさ
い。もし外部ソケットが規定されなかったなら、その時「エラー：特定さ
れていない外部ソケット」とリターンしなさい。
SYN-SENT STATE
SYN-SENT状態
SYN-RECEIVED STATE
SYN-RECEIVED状態
ESTABLISHED STATE
ESTABLISHED状態
FIN-WAIT-1 STATE
FIN-WAIT-1状態
FIN-WAIT-2 STATE
FIN-WAIT-2状態
CLOSE-WAIT STATE
CLOSE-WAIT状態
CLOSING STATE
CLOSING状態
LAST-ACK STATE
LAST-ACK状態
TIME-WAIT STATE
TIME-WAIT状態
Return "error: connection already exists".
「エラー：接続がすでに存在する」とリターンしなさい。
SEND Call
SEND呼出し
CLOSED STATE (i.e., TCB does not exist)
CLOSED状態(つまり,TCBが存在しない)
If the user does not have access to such a connection, then return
"error: connection illegal for this process".
もしユーザがこのような接続にアクセスできないなら、その時「エラー：
このプロセスでは違反の接続」とリターンしなさい。
Otherwise, return "error: connection does not exist".
さもなければ、「エラー：接続が存在しない」をリターンしなさい。
LISTEN STATE
LISTEN状態
If the foreign socket is specified, then change the connection
from passive to active, select an ISS. Send a SYN segment, set
SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. Data
associated with SEND may be sent with SYN segment or queued for
transmission after entering ESTABLISHED state. The urgent bit if
requested in the command must be sent with the data segments sent
as a result of this command. If there is no room to queue the
request, respond with "error: insufficient resources". If
Foreign socket was not specified, then return "error: foreign
socket unspecified".
もし外部ソケットが規定されるなら、受動態から能動態までその時接続を
変えて、ISSを選びなさい。SYNセグメントを送って、SND.UNAをISS、
SND.NXTをISS+1にセットしなさい。SYN-SENT状態に入りなさい。SENDと結
び付けられたデータがSYNセグメントで送られるか、あるいはESTABLISHED
状態に入った後で送信のために待ち行列に入れられるかも知れない。緊急
のビットはもしコマンドで求められるならこのコマンドの結果として送ら
れたデータセグメントで送られなくてはならない。もしリクエストを待ち
行列に入れる空領域がないなら、「エラー：不十分な資源」を返す。もし
外部ソケットが規定されなかったなら、その時「エラー：特定されていな
い外部ソケット」とリターンしなさい。
SYN-SENT STATE
SYN-SENT状態
SYN-RECEIVED STATE
SYN-RECEIVED状態
Queue the data for transmission after entering ESTABLISHED state.
If no space to queue, respond with "error: insufficient
resources".
ESTABLISHED状態に入った後で送信のためデータを待ち行列に入れなさい。
もし列を作るスペースではないなら、「エラー：不十分な資源」を応答し
なさい。
ESTABLISHED STATE
ESTABLISHED状態
CLOSE-WAIT STATE
CLOSE-WAIT状態
Segmentize the buffer and send it with a piggybacked
acknowledgment (acknowledgment value = RCV.NXT). If there is
insufficient space to remember this buffer, simply return "error:
insufficient resources".
バッファーをセグメント化して、そして確認応答と共に（確認応答値＝
RCV.NXT）でそれを送りなさい。もしバッファーを覚えているために十分
な空間がないならこの、ただ「エラー：不十分な資源」とリターンしなさ
い。
If the urgent flag is set, then SND.UP <- SND.NXT-1 and set the
urgent pointer in the outgoing segments.
もし緊急のフラグがセットされるなら、その時SND.UP<-SND.NXT-1、そし
て緊急ポインタを出て行くセグメントにセットしなさい。
FIN-WAIT-1 STATE
FIN-WAIT-1状態
FIN-WAIT-2 STATE
FIN-WAIT-2状態
CLOSING STATE
CLOSING状態
LAST-ACK STATE
LAST-ACK状態
TIME-WAIT STATE
TIME-WAIT状態
Return "error: connection closing" and do not service request.
「エラー：終了している接続」とリターンしなさい、そしてリクエストに
応じてはいけない。
RECEIVE Call
受信呼出しCall
CLOSED STATE (i.e., TCB does not exist)
CLOSED状態(つまり,TCBが存在しない)
If the user does not have access to such a connection, return
"error: connection illegal for this process".
もしユーザがこのような接続にアクセスできないなら、「エラー：このプ
ロセスでは違反の接続」とリターンしなさい。
Otherwise return "error: connection does not exist".
さもなければ「エラー：接続が存在しない」をリターンしなさい。
LISTEN STATE
LISTEN状態
SYN-SENT STATE
SYN-SENT 状態
SYN-RECEIVED STATE
SYN-RECEIVED状態
Queue for processing after entering ESTABLISHED state. If there
is no room to queue this request, respond with "error:
insufficient resources".
ESTABLISHED状態に入った後で処理のために列を作りなさい。もしこのリ
クエストを待ち行列に入れる空領域がないなら、「エラー：不十分な資
源」を応答しなさい。
ESTABLISHED STATE
ESTABLISHED状態
FIN-WAIT-1 STATE
FIN-WAIT-1状態
FIN-WAIT-2 STATE
FIN-WAIT-2状態
If insufficient incoming segments are queued to satisfy the
request, queue the request. If there is no queue space to
remember the RECEIVE, respond with "error: insufficient
resources".
もしリクエストに合うために十分な入りセグメントが待ち行列に入れられ
ていないなら、リクエストを待ち行列に入れなさい。もしRECEIVEを覚え
ている待ち行列スペースがないなら、「エラー：不十分な資源」を応答し
なさい。
Reassemble queued incoming segments into receive buffer and return
to user. Mark "push seen" (PUSH) if this is the case.
待ち行列に入れられた入りセグメントを受信バッファ内に組立て、そして
ユーザにリターンする。もしこれが本当であるなら、「プッシュあり」
（PUSH）をマークしなさい。
If RCV.UP is in advance of the data currently being passed to the
user notify the user of the presence of urgent data.
もしRCV.UPがユーザに渡している現在データより前であるなら、緊急のデー
タの存在をユーザに通知しなさい。
When the TCP takes responsibility for delivering data to the user
that fact must be communicated to the sender via an
acknowledgment. The formation of such an acknowledgment is
described below in the discussion of processing an incoming
segment.
TCPがユーザにデータを届けることに対して責任をとる時、その事実は確
認応答によって送り主に伝えられなくてはならない。このような確認応答
の形成は入りセグメントの処理についての議論に記述される。
CLOSE-WAIT STATE
CLOSE-WAIT状態
Since the remote side has already sent FIN, RECEIVEs must be
satisfied by text already on hand, but not yet delivered to the
user. If no text is awaiting delivery, the RECEIVE will get a
"error: connection closing" response. Otherwise, any remaining
text can be used to satisfy the RECEIVE.
遠隔側がすでにFINを送っていているので、RECEIVEが手元にありしかしユー
ザにまだ配達されてないテキストによって満たされる。もし配達を待って
いるテキストがないなら、RECEIVEは「エラー：終了している接続」レス
ポンスを得るであろう。さもなければ、どんな残っているテキストでも
RECEIVEを満足させるために使われることができる。
CLOSING STATE
CLOSING状態
LAST-ACK STATE
LAST-ACK状態
TIME-WAIT STATE
TIME-WAIT状態
Return "error: connection closing".
リターン「エラー：終了している接続」。
CLOSE Call
CLOSE呼出し
CLOSED STATE (i.e., TCB does not exist)
CLOSED状態(つまり,TCBが存在しない)
If the user does not have access to such a connection, return
"error: connection illegal for this process".
もしユーザがこのような接続にアクセスできないなら、「エラー：このプ
ロセスでは違反の接続」とリターンしなさい。
Otherwise, return "error: connection does not exist".
さもなければ、「エラー：接続が存在しない」へリターンしなさい。
LISTEN STATE
LISTEN状態
Any outstanding RECEIVEs are returned with "error: closing"
responses. Delete TCB, enter CLOSED state, and return.
どんな未処理のRECEIVEでも「エラー：閉じること」レスポンスでリター
ンされる。TCBを削除して、CLOSED状態に入って、そしてリターンしなさ
い。
SYN-SENT STATE
SYN-SENT状態
Delete the TCB and return "error: closing" responses to any
queued SENDs, or RECEIVEs.
TCBを削除しなさい、そしてすべての待ち行列に入ってるSEND、あるいは
RECEIVEに対しても「エラー：閉じること」応答をへリターンしなさい。
SYN-RECEIVED STATE
SYN-RECEIVED状態
If no SENDs have been issued and there is no pending data to send,
then form a FIN segment and send it, and enter FIN-WAIT-1 state;
otherwise queue for processing after entering ESTABLISHED state.
もしSENDsが支給されなかった、そして保留中の送信データがないなら、
FINセグメントを形成して、そしてそれを送って、FIN-WAIT-1状態に入り
なさい、さもなければESTABLISHED状態に入った後で処理のために列を作
りなさい。
ESTABLISHED STATE
ESTABLISHED状態
Queue this until all preceding SENDs have been segmentized, then
form a FIN segment and send it. In any case, enter FIN-WAIT-1
state.
すべて前のSENDsがセグメント化されるまで、これを待ち行列に入れて、
その時FINセグメントを形成して、そしてそれを送りなさい。どんな事例
ででも、FIN-WAIT-1状態に入りなさい。
FIN-WAIT-1 STATE
FIN-WAIT-1状態
FIN-WAIT-2 STATE
FIN-WAIT-2状態
Strictly speaking, this is an error and should receive a "error:
connection closing" response. An "ok" response would be
acceptable, too, as long as a second FIN is not emitted (the first
FIN may be retransmitted though).
厳密に言えば、これはエラーであって、そして「エラー：終了している接
続」レスポンスを受け取るべきである。「ＯＫ」応答は受容できるであろ
う、２つ目のFINが発せられない（最初のFINが再び送られるかも知れない）。
CLOSE-WAIT STATE
CLOSE-WAIT状態
Queue this request until all preceding SENDs have been
segmentized; then send a FIN segment, enter CLOSING state.
すべて前のSENDsがセグメント化されるまで、このリクエストを待ち行列
に入れて、その時FINセグメントを送って、CLOSING状態に入りなさい。
CLOSING STATE
CLOSING状態
LAST-ACK STATE
LAST-ACK状態
TIME-WAIT STATE
TIME-WAIT状態
Respond with "error: connection closing".
「エラー：接続が閉じてる」を返送。
ABORT Call
ABORT呼出し
CLOSED STATE (i.e., TCB does not exist)
CLOSED状態(つまり,TCBが存在しない)
If the user should not have access to such a connection, return
"error: connection illegal for this process".
もしユーザがこのような接続にアクセスを持つべきではないなら、「エラー
：このプロセスでは違反の接続」とリターンしなさい。
Otherwise return "error: connection does not exist".
さもなければ「エラー：接続が存在しない」へリターンしなさい。
LISTEN STATE
LISTEN状態
Any outstanding RECEIVEs should be returned with "error:
connection reset" responses. Delete TCB, enter CLOSED state, and
return.
どんな未処理のRECEIVEでも「エラー：接続リセット」レスポンスでリター
ンされるべきである。TCBを削除して、CLOSED状態に入って、そしてリ
ターンしなさい。
SYN-SENT STATE
SYN-SENT状態
All queued SENDs and RECEIVEs should be given "connection reset"
notification, delete the TCB, enter CLOSED state, and return.
すべて待ち行列に入れられてるSENDとRECEIVEは「接続リセット」通知を
与えられて、TCBを削除して、CLOSED状態に入って、そしてリターンする
べきである。
SYN-RECEIVED STATE
SYN-RECEIVED状態
ESTABLISHED STATE
ESTABLISHED状態
FIN-WAIT-1 STATE
FIN-WAIT-1状態
FIN-WAIT-2 STATE
FIN-WAIT-2状態
CLOSE-WAIT STATE
CLOSE-WAIT状態
Send a reset segment:
リセットセグメントを送りなさい：
<SEQ=SND.NXT><CTL=RST>
All queued SENDs and RECEIVEs should be given "connection reset"
notification; all segments queued for transmission (except for the
RST formed above) or retransmission should be flushed, delete the
TCB, enter CLOSED state, and return.
すべての待ち行列に入れたSENDとRECEIVEが「接続リセット」通知を与え
られるべきである；すべての送信あるいは再送のために待ち行列に入れた
セグメントが（上に形成されたRST以外）追い出され、TCBを削除して、
CLOSED状態に入って、そしてリターンするべきである。
CLOSING STATE
CLOSING状態
LAST-ACK STATE
LAST-ACK状態
TIME-WAIT STATE
TIME-WAIT状態
Respond with "ok" and delete the TCB, enter CLOSED state, and
return.
"ok"と返答して、そしてTCBを削除して、CLOSED状態に入って、そしてリ
ターンしなさい。
STATUS Call
STATUS呼出し
CLOSED STATE (i.e., TCB does not exist)
CLOSED状態(つまり,TCBが存在しない)
If the user should not have access to such a connection, return
"error: connection illegal for this process".
もしユーザがこのような接続にアクセスを持つべきではないなら、「エラー
：このプロセスでは違反の接続」とリターンしなさい。
Otherwise return "error: connection does not exist".
さもなければ「エラー：接続が存在しない」へリターンしなさい。
LISTEN STATE
LISTEN状態
Return "state = LISTEN", and the TCB pointer.
「状態＝LISTEN」とTCBポインタをリターンしなさい。
SYN-SENT STATE
SYN-SENT状態
Return "state = SYN-SENT", and the TCB pointer.
「状態＝SYN-SENT」とTCBポインタをリターンしなさい。
SYN-RECEIVED STATE
SYN-RECEIVED状態
Return "state = SYN-RECEIVED", and the TCB pointer.
「状態＝SYN-RECEIVED」とTCBポインタをリターンしなさい。
ESTABLISHED STATE
ESTABLISHED状態
Return "state = ESTABLISHED", and the TCB pointer.
「状態＝ESTABLISHED」とTCBポインタをリターンしなさい。
FIN-WAIT-1 STATE
FIN-WAIT-1状態
Return "state = FIN-WAIT-1", and the TCB pointer.
「状態＝FIN-WAIT-2」とTCBポインタをリターンしなさい。
FIN-WAIT-2 STATE
FIN-WAIT-2状態
Return "state = FIN-WAIT-2", and the TCB pointer.
「状態＝FIN-WAIT-2」とTCBポインタをリターンしなさい。
CLOSE-WAIT STATE
CLOSE-WAIT状態
Return "state = CLOSE-WAIT", and the TCB pointer.
「状態＝CLOSE-WAIT」とTCBポインタをリターンしなさい。
CLOSING STATE
CLOSING状態
Return "state = CLOSING", and the TCB pointer.
「状態＝CLOSING」とTCBポインタをリターンしなさい。
LAST-ACK STATE
LAST-ACK状態
Return "state = LAST-ACK", and the TCB pointer.
「状態＝LAST-ACK」とTCBポインタをリターンしなさい。
TIME-WAIT STATE
TIME-WAIT状態
Return "state = TIME-WAIT", and the TCB pointer.
「状態＝TIME-WAIT」とTCBポインタをリターンしなさい。
SEGMENT ARRIVES
セグメント到着
If the state is CLOSED (i.e., TCB does not exist) then
もしCLOSED状態(つまり,TCBが存在しない)なら
all data in the incoming segment is discarded. An incoming
segment containing a RST is discarded. An incoming segment not
containing a RST causes a RST to be sent in response. The
acknowledgment and sequence field values are selected to make the
reset sequence acceptable to the TCP that sent the offending
segment.
すべての入ってくるセグメントでのデータが捨てられる。RSTを含んでい
る入ってくるセグメントが捨てられる。RSTを含んでいない入ってくるセ
グメントが来たらRSTを含む応答が送られる。確認応答とシーケンスフィー
ルド値は誤ったセグメントを送ったTCPにリセット手順を受け入れさせる
ように選ばれる。
If the ACK bit is off, sequence number zero is used,
もしACKビットがオフなら、ゼロのシーケンス番号が使われる、
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
If the ACK bit is on,
もしACKビットがオンであるなら、
<SEQ=SEG.ACK><CTL=RST>
Return.
リターンしなさい。
If the state is LISTEN then
もし状態がLISTENであるなら
first check for an RST
最初にRSTを調べなさい
An incoming RST should be ignored. Return.
入ってくるRSTが無視されるべきである。リターンしなさい。
second check for an ACK
第二にACKを調べなさい
Any acknowledgment is bad if it arrives on a connection still in
the LISTEN state. An acceptable reset segment should be formed
for any arriving ACK-bearing segment. The RST should be
formatted as follows:
アクノレッジメントが、もしそれがまだLISTEN状態で接続の上に到着す
るなら、良くない。受容できるリセットセグメントがどんな到着してい
るACKを運ぶセグメントのためにでも形成されるべきである。RSTは次の
ように方式を決められるべきである：
<SEQ=SEG.ACK><CTL=RST>
Return.
リターンしなさい。
third check for a SYN
３番目SYNを調べなさい
If the SYN bit is set, check the security. If the
security/compartment on the incoming segment does not exactly
match the security/compartment in the TCB then send a reset and
return.
もしSYNビットがセットされるなら、安全をチェックしなさい。もし入っ
てくるセグメントの上の安全保証／隔離がTCBの時正確に安全保証／隔
離に合わないなら、リセットを送って、そしてリターンしなさい。
<SEQ=SEG.ACK><CTL=RST>
If the SEG.PRC is greater than the TCB.PRC then if allowed by
the user and the system set TCB.PRC<-SEG.PRC, if not allowed
send a reset and return.
もしSEG.PRCがTCB.PRCよりより大きいならもしユーザが許すならシステ
ムはTCB.PRC<-SEG.PRCと設定し、もし許されないならリセットを送って、
そしてリターンしなさい。
<SEQ=SEG.ACK><CTL=RST>
If the SEG.PRC is less than the TCB.PRC then continue.
もしSEG.PRCがTCB.PRCより小さければ、継続しなさい。
Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any other
control or text should be queued for processing later. ISS
should be selected and a SYN segment sent of the form:
RCV.NXTをSEG.SEQ+1にセットしなさい、IRSはSEG.SEQに設定される、そ
して他のいかなるコントロールあるいはテキストが後に処理のために待
ち行列に入れられるべきである。ISSは選ばれるべきである、そしてSYN
セグメントが送信される形式は：
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
SND.NXT is set to ISS+1 and SND.UNA to ISS. The connection
state should be changed to SYN-RECEIVED. Note that any other
incoming control or data (combined with SYN) will be processed
in the SYN-RECEIVED state, but processing of SYN and ACK should
not be repeated. If the listen was not fully specified (i.e.,
the foreign socket was not fully specified), then the
unspecified fields should be filled in now.
SND.NXTはISS+1にSND.UNAはISS設定される。接続状態はSYN-RECEIVEDに
変えられるべきである。他のいかなる入ってくるコントロールあるいは
（SYNと一緒にされる）データがSYN-RECEIVED状態で処理されるであろ
う、しかしSYNとACKの処理が繰り返されるべきではないことに注意しな
さい。もしソケットが完全に明示されてなかったなら（すなわち、外部
ソケットが完全に指定されなかった）、不特定のフィールドは今記入さ
れるべきである。
fourth other text or control
第四に、他のテキストあるいはコントロール
Any other control or text-bearing segment (not containing SYN)
must have an ACK and thus would be discarded by the ACK
processing. An incoming RST segment could not be valid, since
it could not have been sent in response to anything sent by this
incarnation of the connection. So you are unlikely to get here,
but if you do, drop the segment, and return.
（SYNを含んでいない）他のコントロールあるいはテキストを運ぶセグ
メントがACKを持たなくてはならなくて、そしてACK処理によって捨てら
れるであろう。入ってくるRSTセグメントが、それが古い接続によって
送られた何かに応えて送られたはずがないので、有効でない。それでこ
の手順まで来ることはありそうもない、しかしもし来たら、セグメント
を捨て、そしてリターンする。
If the state is SYN-SENT then
もし状態がその時SYN-SENTなら
first check the ACK bit
最初に、ACKビットをチェックしなさい
If the ACK bit is set
最初に、ACKビットをチェックしなさい
If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset (unless
the RST bit is set, if so drop the segment and return)
もしSEG.ACK=<ISS、あるいはSEG.ACK>SND.NXT、ならば、リセットを
送るりなさい（RSTビットが設定されていない限り、もしそうならセ
グメントを捨てて、リターンする）
<SEQ=SEG.ACK><CTL=RST>
and discard the segment. Return.
そしてセグメントを捨てなさい。リターンしなさい。
If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is acceptable.
もしSND.UNA=<SEG.ACK=<SND.NXTであるなら、それでACKは受容できる。
second check the RST bit
第二に、RSTビットをチェックしなさい
If the RST bit is set
もしRSTビットがセットされるなら
If the ACK was acceptable then signal the user "error:
connection reset", drop the segment, enter CLOSED state,
delete TCB, and return. Otherwise (no ACK) drop the segment
and return.
もしACKがその時受容できたならユーザ「エラー：接続リセット」に
信号を送って、セグメントを落として、CLOSED状態に入って、TCBを
削除して、そしてリターンしなさい。さもなければ（ACKなし）セグ
メントを捨てて、リターンしない。
third check the security and precedence
３番目、安全と優先順位をチェックしなさい
If the security/compartment in the segment does not exactly
match the security/compartment in the TCB, send a reset
もしセグメントでの安全保証／隔離が正確にTCBの安全保証／隔離に
合わないなら、リセットを送りなさい
If there is an ACK
もしACKがあるなら
<SEQ=SEG.ACK><CTL=RST>
Otherwise
さもなければ
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
If there is an ACK
もしACKがあるなら
The precedence in the segment must match the precedence in the
TCB, if not, send a reset
セグメントでの優先順位はTCBで優先順位に釣合わなくてはならない、
もしそうでなければ、リセットを送りなさい。
<SEQ=SEG.ACK><CTL=RST>
If there is no ACK
もしACKがないなら
If the precedence in the segment is higher than the precedence
in the TCB then if allowed by the user and the system raise
the precedence in the TCB to that in the segment, if not
allowed to raise the prec then send a reset.
もしセグメントでの優先順位がTCBの優先順位より高いならもしユー
ザとシステムによって許されるならTCBでの優先順位をセグメントの
それに引き上げて、もし優先順位を上げることを許されないならリセッ
トを送りなさい。
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
If the precedence in the segment is lower than the precedence
in the TCB continue.
もしセグメントでの優先順位がTCBで優先順位より低いなら、継続しなさい。
If a reset was sent, discard the segment and return.
もしリセットが送られたなら、セグメントを捨てて、そしてリターンし
なさい。
fourth check the SYN bit
第四に、SYNビットをチェックしなさい。
This step should be reached only if the ACK is ok, or there is
no ACK, and it the segment did not contain a RST.
このステップは、ACKがＯＫである場合、あるいはACKがなくセグメント
はRSTを含んでいない場合に限り、達するであろう。
If the SYN bit is on and the security/compartment and precedence
are acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to
SEG.SEQ. SND.UNA should be advanced to equal SEG.ACK (if there
is an ACK), and any segments on the retransmission queue which
are thereby acknowledged should be removed.
もしSYNビットがオンであり、そして安全保証／隔離と優先順位がその
時受容できるなら、RCV.NXTがSEG.SEQ+1に設定される、IRSがSEG.SEQ.
に設定される。SND.UNAは（もしACKがあるなら）SEG.ACKに等しくなる
よう進められる、そしてそれによって確認された再送待ち行列の上のセ
グメントは取り去られるべきである。
If SND.UNA > ISS (our SYN has been ACKed), change the connection
state to ESTABLISHED, form an ACK segment
もしSND.UNA>ISS（我々のSYNが確認された）なら、接続状態を
ESTABLISHEDに変えて、ACKセグメントを形成しなさい。
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
and send it. Data or controls which were queued for
transmission may be included. If there are other controls or
text in the segment then continue processing at the sixth step
below where the URG bit is checked, otherwise return.
そしてそれを送りなさい。送信のために待ち行列に入れられたデータあ
るいはコントロールが含まれるかも知れない。もしその時セグメントに
他のコントロールあるいはテキストがあるなら下にURGビットがチェッ
クされるところの６番目のステップの処理を続けて、さもなければリター
ンしなさい。
Otherwise enter SYN-RECEIVED, form a SYN,ACK segment
さもなければSYN-RECEIVEDに入って、SYN、ACKセグメントを形成しなさい
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
and send it. If there are other controls or text in the
segment, queue them for processing after the ESTABLISHED state
has been reached, return.
そしてそれを送りなさい。もしセグメントに他のコントロールあるいは
テキストがあるなら、ESTABLISHED状態が達した後での処理のためにそ
れらを待ち行列に入れて、リターンしなさい。
fifth, if neither of the SYN or RST bits is set then drop the
segment and return.
５番目、もしSYNあるいはRSTビットのいずれが設定されているなら、セ
グメントを捨て、そしてリターンしなさい。
Otherwise,
さもなければ、
first check sequence number
最初に、シーケンス番号をチェックしなさい
SYN-RECEIVED STATE
SYN-RECEIVED状態
ESTABLISHED STATE
ESTABLISHED状態
FIN-WAIT-1 STATE
FIN-WAIT-1状態
FIN-WAIT-2 STATE
FIN-WAIT-2状態
CLOSE-WAIT STATE
CLOSE-WAIT状態
CLOSING STATE
CLOSING状態
LAST-ACK STATE
LAST-ACK状態
TIME-WAIT STATE
TIME-WAIT状態
Segments are processed in sequence. Initial tests on arrival
are used to discard old duplicates, but further processing is
done in SEG.SEQ order. If a segment's contents straddle the
boundary between old and new, only the new parts should be
processed.
セグメントが順番で処理される。到着後の最初のテストが古い重複を捨
てるために用いられる、しかしそれ以後の処理がSEG.SEQ順序でされる。
もしセグメントの内容が古い物と新しい物を含むのであれば、ただ新し
い部分だけが処理されるべきである。
There are four cases for the acceptability test for an incoming
segment:
入ってくるセグメントのために受け入れ可能テストの４つのケースがあ
る：
Segment Receive Test
Length Window
セグメ 受信ウイ テスト
ント長 ンドウ
------- ------- -------------------------------------------
0 0 SEG.SEQ = RCV.NXT
0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
>0 0 not acceptable
>0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
If the RCV.WND is zero, no segments will be acceptable, but
special allowance should be made to accept valid ACKs, URGs and
RSTs.
もしRCV.WNDがゼロであるなら、セグメントが受容できないであろう、
しかし特別な許容が正当なACK、URGとRSTを受け入れるためになされる
べきである。
If an incoming segment is not acceptable, an acknowledgment
should be sent in reply (unless the RST bit is set, if so drop
the segment and return):
もし入ってくるセグメントが受容できないなら、確認応答が答えて送ら
れるべきである（RSTビットが設定されていないなら、セグメントを捨
てそしてリターンする）：
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, drop the unacceptable segment
and return.
確認応答を送った後で、受け入れ難いセグメントを捨てそしてリターン
しなさい。
In the following it is assumed that the segment is the idealized
segment that begins at RCV.NXT and does not exceed the window.
One could tailor actual segments to fit this assumption by
trimming off any portions that lie outside the window (including
SYN and FIN), and only processing further if the segment then
begins at RCV.NXT. Segments with higher begining sequence
numbers may be held for later processing.
以下でセグメントがRCV.NXTに始まる理想的と考えられたセグメントで
あって、そしてウィンドウを超えないと想定される。（SYNとFINを含め
て）、ウィンドウの外に横たわるどんな取り分でも切り整えることに
よって、そしてセグメントがRCV.NXTから始まるよう処理して、実際の
セグメントをこの仮説に適しているように適応させることができる。
大きいシーケンス番号で始まるセグメントが後の処理のために保持さ
れるかも知れない。
second check the RST bit,
第二に、RSTビットをチェックする、
SYN-RECEIVED STATE
SYN-RECEIVED状態
If the RST bit is set
もしRSTビットがセットされるなら
If this connection was initiated with a passive OPEN (i.e.,
came from the LISTEN state), then return this connection to
LISTEN state and return. The user need not be informed. If
this connection was initiated with an active OPEN (i.e., came
from SYN-SENT state) then the connection was refused, signal
the user "connection refused". In either case, all segments
on the retransmission queue should be removed. And in the
active OPEN case, enter the CLOSED state and delete the TCB,
and return.
もしこの接続が受動的なOPENで始められたなら（すなわち、LISTEN状
態から来る）、その時この接続はLISTEN状態と戻り、リターンする。
ユーザに知らせる必要がない。もしこの接続が能動態のOPENで始めら
れたなら（すなわち、SYN-SENT状態から来る）接続は拒否され、ユー
ザには「接続が拒否した」と信号を送る。いずれかの事例で、すべて
の再送待ち行列の上のセグメントが取り去られるべきである。そして
能動態のOPENの場合、CLOSED状態に入って、そしてTCBを削除して、
リターンしなさい。
ESTABLISHED
ESTABLISHED状態
FIN-WAIT-1
FIN-WAIT-1状態
FIN-WAIT-2
FIN-WAIT-2状態
CLOSE-WAIT
CLOSE-WAIT状態
If the RST bit is set then, any outstanding RECEIVEs and SEND
should receive "reset" responses. All segment queues should be
flushed. Users should also receive an unsolicited general
"connection reset" signal. Enter the CLOSED state, delete the
TCB, and return.
もしRSTビットが設定されているなら、どんな未処理のRECEIVEとSENDも
「リセット」応答を受け取るべきである。すべてのセグメント待ち行列
がクリアされるべきである。ユーザが同じく望まれない一般的な「接続
リセット」シグナルを受けるべきである。CLOSED状態に入って、TCBを
削除して、そしてリターンしなさい。
CLOSING STATE
CLOSING状態
LAST-ACK STATE
LAST-ACK状態
TIME-WAIT
TIME-WAIT状態
If the RST bit is set then, enter the CLOSED state, delete the
TCB, and return.
もしRSTビットが設定されるなら、CLOSED状態に入って、TCBを削除して、
そしてリターンしなさい。
third check security and precedence
３番目、チェック安全保証と優先順位
SYN-RECEIVED
SYN-RECEIVED状態
If the security/compartment and precedence in the segment do not
exactly match the security/compartment and precedence in the TCB
then send a reset, and return.
もしセグメントでの安全保証／隔離と優先順位がTCBでの時正確に安全
保証／隔離と優先順位に釣合わないなら、リセットを送って、そしてリ
ターンしなさい。
ESTABLISHED STATE
ESTABLISHED状態
If the security/compartment and precedence in the segment do not
exactly match the security/compartment and precedence in the TCB
then send a reset, any outstanding RECEIVEs and SEND should
receive "reset" responses. All segment queues should be
flushed. Users should also receive an unsolicited general
"connection reset" signal. Enter the CLOSED state, delete the
TCB, and return.
もしセグメントでの安全保証／隔離と優先順位が正確にTCBでの安全保
証／隔離と優先順位に釣合わないなら、リセットを送りなさい、どんな
未処理のRECEIVEとSENDも「リセット」レスポンスを受け取るべきであ
る。すべてのセグメント待ち行列がクリアされるべきである。ユーザが
同じく望まれない一般的な「接続リセット」シグナルを受けるべきであ
る。CLOSED状態に入って、TCBを削除して、そしてリターンしなさい。
Note this check is placed following the sequence check to prevent
a segment from an old connection between these ports with a
different security or precedence from causing an abort of the
current connection.
このチェックがこれらのポートの間での安全あるいは優先順位の異なった
古い接続からのセグメントが現在の接続を中断することを防ぐためにチェッ
ク手順の後に置かれていることに注意しなさい。
fourth, check the SYN bit,
第四に、SYNビットをチェックする、
SYN-RECEIVED
SYN-RECEIVED状態
ESTABLISHED STATE
ESTABLISHED状態
FIN-WAIT STATE-1
FIN-WAIT 状態-1
FIN-WAIT STATE-2
FIN-WAIT 状態-2
CLOSE-WAIT STATE
CLOSE-WAIT状態
CLOSING STATE
CLOSING状態
LAST-ACK STATE
LAST-ACK状態
TIME-WAIT STATE
TIME-WAIT状態
If the SYN is in the window it is an error, send a reset, any
outstanding RECEIVEs and SEND should receive "reset" responses,
all segment queues should be flushed, the user should also
receive an unsolicited general "connection reset" signal, enter
the CLOSED state, delete the TCB, and return.
もしSYNがウインドウに入っていたらエラーである、リセットを送る、
どんな未処理のRECEIVEとSENDでも「リセット」レスポンスを受け取る
べきである、すべてのセグメント待ち行列がクリアされるべきである、
ユーザは同じく望まれない一般的な「接続リセット」シグナルを受けて、
CLOSED状態に入って、TCBを削除して、そしてリターンするべきである。
If the SYN is not in the window this step would not be reached
and an ack would have been sent in the first step (sequence
number check).
もしSYNがウインドウに入ってないなら、このステップに到着しないで
あろう、そしてackが第１ステップ（シーケンス番号チェック）で送ら
れたであろう。
fifth check the ACK field,
５番目のチェック、ACKフィールド、
if the ACK bit is off drop the segment and return
もしACKビットがオフならセグメントを捨て、そしてリターンしなさい
if the ACK bit is on
もしACKビットがオンであるなら
SYN-RECEIVED STATE
SYN-RECEIVED状態
If SND.UNA =< SEG.ACK =< SND.NXT then enter ESTABLISHED state
and continue processing.
もしSND.UNA=<SEG.ACK=<SND.NXTであるならその時ESTABLISHED状態に
入って、そして処理を続けなさい。
If the segment acknowledgment is not acceptable, form a
reset segment,
もしセグメント確認応答が受容できないなら、リセットセグメント
を形成する、
<SEQ=SEG.ACK><CTL=RST>
and send it.
そしてそれを送りなさい。
ESTABLISHED STATE
ESTABLISHED 状態
If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK.
Any segments on the retransmission queue which are thereby
entirely acknowledged are removed. Users should receive
positive acknowledgments for buffers which have been SENT and
fully acknowledged (i.e., SEND buffer should be returned with
"ok" response). If the ACK is a duplicate
(SEG.ACK < SND.UNA), it can be ignored. If the ACK acks
something not yet sent (SEG.ACK > SND.NXT) then send an ACK,
drop the segment, and return.
もしSND.UNA<SEG.ACK=<SND.NXTならSND.UNA<-SEG.ACKを設定しなさい。
それによって完全に確認されるどんな再送待ち行列の上のセグメント
でも取り去られる。ユーザが送られて、そして完全に確認されたバッ
ファのために確かな確認応答を受け取るべきである（すなわち、SEND
バッファが"ok"なレスポンスでリターンされるべきである）。もしACK
が重複（SEG.ACK<SND.UNA）であるなら、それは無視されることができ
る。もし何かがまだ送らなかったものに確認応答するならば
（SEG.ACK>SND.NXT）、ACKを送り、セグメントを落として、そしてリ
ターンしなさい。
If SND.UNA < SEG.ACK =< SND.NXT, the send window should be
updated. If (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and
SND.WL2 =< SEG.ACK)), set SND.WND <- SEG.WND, set
SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK.
もしSND.UNA<SEG.ACK=<SND.NXTであるなら、送信ウインドウは最新の
ものにされるべきである。もし（SND.WL1<SEG.SEQあるいは
（SND.WL1=SEG.SEQとSND.WL2=<SEG.ACK））なら、SND.WND<-SEG.WNDと
SND.WL1<-SEG.SEQとSND.WL2<-SEG.ACKを設定しなさい。
Note that SND.WND is an offset from SND.UNA, that SND.WL1
records the sequence number of the last segment used to update
SND.WND, and that SND.WL2 records the acknowledgment number of
the last segment used to update SND.WND. The check here
prevents using old segments to update the window.
SND.WNDがSND.UNAからのオフセットであることに注意しなさい、その
SND.WL1はセグメントがSND.WNDを更新するために使った最後のシーケ
ンス番号を記録する、そしてそのSND.WL2はセグメントがSND.WNDを更
新するために使った最後の確認応答番号を記録する。ここでのチェッ
クはウィンドウを更新するために古いセグメントを使うことを妨げる。
FIN-WAIT-1 STATE
FIN-WAIT-1状態
In addition to the processing for the ESTABLISHED state, if
our FIN is now acknowledged then enter FIN-WAIT-2 and continue
processing in that state.
ESTABLISHED状態の処理の加えて、もし我々のFINがその時今確認され
るならFIN-WAIT-2に入って、そしてその状態で処理を続けなさい。
FIN-WAIT-2 STATE
FIN-WAIT-2状態
In addition to the processing for the ESTABLISHED state, if
the retransmission queue is empty, the user's CLOSE can be
acknowledged ("ok") but do not delete the TCB.
ESTABLISHED状態の処理の加えて、もし再送待ち行列が空なら、ユー
ザのCLOSEが確認されることができる("ok")しかしTCBを削除してはい
けない。
CLOSE-WAIT STATE
CLOSE-WAIT状態
Do the same processing as for the ESTABLISHED state.
ESTABLISHED状態と同じ処理をしなさい。
CLOSING STATE
CLOSING状態
In addition to the processing for the ESTABLISHED state, if
the ACK acknowledges our FIN then enter the TIME-WAIT state,
otherwise ignore the segment.
ESTABLISHED状態の処理に加えて、もしACKが我々のFINを認めるなら
TIME-WAIT状態に入って、さもなければセグメントを無視しなさい。
LAST-ACK STATE
LAST-ACK状態
The only thing that can arrive in this state is an
acknowledgment of our FIN. If our FIN is now acknowledged,
delete the TCB, enter the CLOSED state, and return.
この状態に到着することができる唯一のことは我々のFINの確認応答
である。もし我々のFINが今確認されるなら、TCBを削除して、CLOSED
状態に入って、そしてリターンしなさい。
TIME-WAIT STATE
TIME-WAIT状態
The only thing that can arrive in this state is a
retransmission of the remote FIN. Acknowledge it, and restart
the 2 MSL timeout.
この状態に到着することができる唯一のことは遠隔のFINの再送であ
る。それを認めて、そして２MSLタイムアウトを再開しなさい。
sixth, check the URG bit,
６番目、URGビットをチェックしなさい、
ESTABLISHED STATE
ESTABLISHED状態
FIN-WAIT-1 STATE
FIN-WAIT-1状態
FIN-WAIT-2 STATE
FIN-WAIT-2状態
If the URG bit is set, RCV.UP <- max(RCV.UP,SEG.UP), and signal
the user that the remote side has urgent data if the urgent
pointer (RCV.UP) is in advance of the data consumed. If the
user has already been signaled (or is still in the "urgent
mode") for this continuous sequence of urgent data, do not
signal the user again.
もしURGビットが設定され、RCV.UP<-max(RCV.UP,SEG.UP)、であるなら、
そしてもし緊急ポインタ(RCV.UP)が消費されたデータの前方であるなら、
ユーザに遠方側が緊急のデータを持っていると合図しなさい。もしユー
ザがすでに信号を送られた（あるいはまだ「緊急のモード」である）な
ら、この緊急のデータの連続溶接のために、再びユーザに信号を送って
はいけない。
CLOSE-WAIT STATE
CLOSE-WAIT状態
CLOSING STATE
CLOSING状態
LAST-ACK STATE
LAST-ACK状態
TIME-WAIT
TIME-WAIT状態
This should not occur, since a FIN has been received from the
remote side. Ignore the URG.
これは、FINが遠隔の側面から受け取られたので、起こるべきではない。
URGを無視しなさい。
seventh, process the segment text,
７番目、セグメントテキスト処理、
ESTABLISHED STATE
ESTABLISHED状態
FIN-WAIT-1 STATE
FIN-WAIT-1状態
FIN-WAIT-2 STATE
FIN-WAIT-2状態
Once in the ESTABLISHED state, it is possible to deliver segment
text to user RECEIVE buffers. Text from segments can be moved
into buffers until either the buffer is full or the segment is
empty. If the segment empties and carries an PUSH flag, then
the user is informed, when the buffer is returned, that a PUSH
has been received.
かつてESTABLISHED状態で、ユーザRECEIVEバッファーにセグメントテキ
ストを配達することは可能である。セグメントからのテキストが、ある
いはバッファがいっぱいである、あるいはセグメントがからになるまで、
バッファーの中に動かされることができる。もしセグメントが空になっ
て、そしてPUSHフラグを運ぶなら、その時ユーザが知らせられる、バッ
ファーがリターンされる時、PUSHが受信される。
When the TCP takes responsibility for delivering the data to the
user it must also acknowledge the receipt of the data.
TCPがユーザにデータを届けることに対して責任をとる時、それは同じく
データの受領書を認めなくてはならない。
Once the TCP takes responsibility for the data it advances
RCV.NXT over the data accepted, and adjusts RCV.WND as
apporopriate to the current buffer availability. The total of
RCV.NXT and RCV.WND should not be reduced.
TCPがデータに対して責任をとる途端に、それは受け入れたデータで
RCV.NXTを進めて、そして同じぐらい現在のバッファー利用度に適切な
RCV.WNDを調整する。RCV.NXTとRCV.WNDの合計は減らされるべきではない。
Please note the window management suggestions in section 3.7.
どうかセクション３.７でウインドウ管理示唆に注意してください。
Send an acknowledgment of the form:
形式の確認応答を送りなさい：
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
This acknowledgment should be piggybacked on a segment being
transmitted if possible without incurring undue delay.
この確認応答は、もし過度の遅れを受けないで可能であるなら、伝達さ
るセグメントに便乗されるべきである。
CLOSE-WAIT STATE
CLOSE-WAIT状態
CLOSING STATE
CLOSING状態
LAST-ACK STATE
LAST-ACK状態
TIME-WAIT STATE
TIME-WAIT状態
This should not occur, since a FIN has been received from the
remote side. Ignore the segment text.
これは、FINが遠隔の側面から受け取られたので、起こるべきではない。
セグメントテキストを無視しなさい。
eighth, check the FIN bit,
８番目、チェックFINビット
Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT
since the SEG.SEQ cannot be validated; drop the segment and
return.
もし状態がCLOSED、LISTENあるいはSYN-SENTであるなら、SEG.SEQが有効
にできないので、FINを処理してはいけない；セグメントを捨てて、そし
てリターンする
If the FIN bit is set, signal the user "connection closing" and
return any pending RECEIVEs with same message, advance RCV.NXT
over the FIN, and send an acknowledgment for the FIN. Note that
FIN implies PUSH for any segment text not yet delivered to the
user.
もしFINビットがセットされるなら、ユーザ「接続取引完了」を示して、
そして同じメッセージでどんな保留中のRECEIVEへでもリターンして、
FINの上にRCV.NXTを進めて、そしてFINのために確認応答を送りなさい。
FINが原文がユーザにまだ届けなかったどんなセグメントのためにでも
PUSHを暗示することに注意しなさい。
SYN-RECEIVED STATE
SYN-RECEIVED状態
ESTABLISHED STATE
ESTABLISHED状態
Enter the CLOSE-WAIT state.
CLOSE-WAIT状態に入りなさい。
FIN-WAIT-1 STATE
FIN-WAIT-1状態
If our FIN has been ACKed (perhaps in this segment), then
enter TIME-WAIT, start the time-wait timer, turn off the other
timers; otherwise enter the CLOSING state.
もし我々のFINが（多分このセグメントで）ACKされたなら、その時
TIME-WAITに入って、時待ちタイマを始動させて、他のタイマを消し
て、さもなければCLOSING状態に入りなさい。
FIN-WAIT-2 STATE
FIN-WAIT-2状態
Enter the TIME-WAIT state. Start the time-wait timer, turn
off the other timers.
TIME-WAIT状態に入りなさい。時待ちタイマを始動させて、他のタイ
マを消しなさい。
CLOSE-WAIT STATE
CLOSE-WAIT状態
Remain in the CLOSE-WAIT state.
CLOSE-WAIT状態で残留しなさい。
CLOSING STATE
CLOSING状態
Remain in the CLOSING state.
CLOSINGの状態で残留しなさい。
LAST-ACK STATE
LAST-ACK状態
Remain in the LAST-ACK state.
LAST-ACK状態で残留しなさい。
TIME-WAIT STATE
TIME-WAIT状態
Remain in the TIME-WAIT state. Restart the 2 MSL time-wait
timeout.
TIME-WAIT状態で残留しなさい。２つのMSL時待ちタイムアウトを再開
しなさい。
and return.
そしてリターンしなさい。
USER TIMEOUT
ユーザタイムアウト
For any state if the user timeout expires, flush all queues, signal
the user "error: connection aborted due to user timeout" in general
and for any outstanding calls, delete the TCB, enter the CLOSED
state and return.
どんな状態のためにでももしユーザタイムアウトが期限が切れるなら、すべ
ての待ち行列をクリアして、一般にそしてどんな未処理の呼び出しのために
でもユーザ「エラー：接続がユーザタイムアウトのために中断した」に信号
を送って、TCBを削除して、CLOSEDされた状態に入って、そしてリターンし
なさい。
RETRANSMISSION TIMEOUT
再送タイムアウト
For any state if the retransmission timeout expires on a segment in
the retransmission queue, send the segment at the front of the
retransmission queue again, reinitialize the retransmission timer,
and return.
どんな状態のためにでももし再送タイムアウトが再送待ち行列でセグメン
トの上に期限が切れるなら、再びセグメントを再送待ち行列の前部におい
て送って、再送タイマを再設定して、そしてリターンしなさい。
TIME-WAIT TIMEOUT
タイムアウトを時-待ちなさい
If the time-wait timeout expires on a connection delete the TCB,
enter the CLOSED state and return.
もし時待ちタイムアウトが接続の上に期限が切れるならTCBを削除して、
CLOSEDされた状態に入って、そしてリターンしなさい。
GLOSSARY
用語集
1822
BBN Report 1822, "The Specification of the Interconnection of
a Host and an IMP". The specification of interface between a
host and the ARPANET.
BBN報告1822、「ホストとIMPの接続の仕様」。ホストとARPANETの間
のインタフェースの指定。
ACK
A control bit (acknowledge) occupying no sequence space, which
indicates that the acknowledgment field of this segment
specifies the next sequence number the sender of this segment
is expecting to receive, hence acknowledging receipt of all
previous sequence numbers.
シーケンス空間を占領しない制御ビット 確認応答で、このセグメ
ントの確認応答フィールドはこのセグメントの送主が次に受取ること
を予期しているシーケンス番号を指定する、つまりこれより前のシー
ケンス番号の確認している受領書。
ARPANET message
The unit of transmission between a host and an IMP in the
ARPANET. The maximum size is about 1012 octets (8096 bits).
ARPANETでホストとIMPの間に送信の単位。最大寸法はおよそ１０１２
のオクテット（８０９６ビット）である。
ARPANET packet
A unit of transmission used internally in the ARPANET between
IMPs. The maximum size is about 126 octets (1008 bits).
IMP間にARPANETで内服で使われた透過のユニット。最大寸法はおよそ
１２６のオクテット（１００８ビット）である。
connection
A logical communication path identified by a pair of sockets.
ソケットの対によって識別された論理的な通信経路。
datagram
A message sent in a packet switched computer communications
network.
パケット交換コンピュータ通信網で送られたメッセージ。
Destination Address
The destination address, usually the network and host
identifiers.
宛先アドレス、通常ネットワークとホスト識別子。
FIN
A control bit (finis) occupying one sequence number, which
indicates that the sender will send no more data or control
occupying sequence space.
１つのシーケンス番号を占領している制御ビット（終わり）、それは
送り主がもうシーケンス空間を占領するデータあるいはコントロール
がないことを表す。
fragment
A portion of a logical unit of data, in particular an internet
fragment is a portion of an internet datagram.
データの論理的な単位の１部、特にインターネットフラグメントがイ
ンターネットデータグラムの１部である。
FTP
A file transfer protocol.
ファイル転送プロトコル。
header
Control information at the beginning of a message, segment,
fragment, packet or block of data.
メッセージ、セグメント、フラグメント、パケットあるいはデータの
ブロックの始めの制御情報。
host
A computer. In particular a source or destination of messages
from the point of view of the communication network.
コンピュータ。特に通信網の見地からメッセージの発信者あるいは着
信者。
Identification
An Internet Protocol field. This identifying value assigned
by the sender aids in assembling the fragments of a datagram.
インターネット・プロトコルフィールド。これはデータグラムのフラ
グメントを組立の手助けで送信者によって割り当てられた識別値。
IMP
The Interface Message Processor, the packet switch of the
ARPANET.
インタフェースメッセージプロセッサ、ARPANETのパケット交換機。
internet address
A source or destination address specific to the host level.
ホストレベルで規定される発信あるいは着信アドレス。
internet datagram
The unit of data exchanged between an internet module and the
higher level protocol together with the internet header.
インターネットモジュールと上位レベルのプロトコル間に交換され
るデータのユニット、どちらもインターネットヘッダーを含む。
internet fragment
A portion of the data of an internet datagram with an internet
header.
インターネットヘッダーを持っているインターネットデータグラムの
データの１部。
IP
Internet Protocol.
インターネット・プロトコル。
IRS
The Initial Receive Sequence number. The first sequence
number used by the sender on a connection.
最初の受信シーケンス番号。接続の上で送信者によって使われる最初
のシーケンス番号。
ISN
The Initial Sequence Number. The first sequence number used
on a connection, (either ISS or IRS). Selected on a clock
based procedure.
最初のシーケンス番号。接続の上で使われたる最初のシーケンス番号
（ISSあるいはIRS）。時刻ベースの手順で選ばれ。
ISS
The Initial Send Sequence number. The first sequence number
used by the sender on a connection.
最初の送信シーケンス番号。接続の上で送信者によって使われた最初
のシーケンス番号。
leader
Control information at the beginning of a message or block of
data. In particular, in the ARPANET, the control information
on an ARPANET message at the host-IMP interface.
メッセージの始めの制御情報あるいはデータのブロック。特にARPANET
では、ホストIMPインタフェースにおいてのARPANETメッセージの制御
装置情報。
left sequence
This is the next sequence number to be acknowledged by the
data receiving TCP (or the lowest currently unacknowledged
sequence number) and is sometimes referred to as the left edge
of the send window.
これはデータ受信TCPによって確認される次のシーケンス番号である
（あるいは最も低い現在認められていないシーケンス番号）そしてそ
れは送信ウインドウの左の端として時々参照される。
local packet
The unit of transmission within a local network.
ローカルネットワークで伝送するユニット。
module
An implementation, usually in software, of a protocol or other
procedure.
通常ソフトウェアで、プロトコルあるいは他の手続の実装。
MSL
Maximum Segment Lifetime, the time a TCP segment can exist in
the internetwork system. Arbitrarily defined to be 2 minutes.
最大セグメントライフタイム、TCPセグメントがインターネットワー
クシステムで存在することができる時。独断的に２分と定義された。
octet
An eight bit byte.
８ビットバイト
Options
An Option field may contain several options, and each option
may be several octets in length. The options are used
primarily in testing situations; for example, to carry
timestamps. Both the Internet Protocol and TCP provide for
options fields.
オプションフィールドがいくつかのオプションを含むかも知れない、
そしてそれぞれのオプションが長さにおいていくつかのオクテットで
あるかも知れない。オプションはテスト状況で主に使われる；例えば、
タイムスタンプを運ぶために。インターネット・プロトコルとTCP両
方がオプションフィールドを提供する。
packet
A package of data with a header which may or may not be
logically complete. More often a physical packaging than a
logical packaging of data.
ヘッダーを持っていて論理的に完全であるあるいは完全でない１パッ
ケージのデータ。しばしばデータの論理的なパッケージというより物
理的なパッケージ。
port
The portion of a socket that specifies which logical input or
output channel of a process is associated with the data.
ソケットの部分、それはデータをいずれのプロセスの論理的な入力あ
るいは出力チャネルと結び付けるか明示する。
process
A program in execution. A source or destination of data from
the point of view of the TCP or other host-to-host protocol.
プログラムの実行。TCPあるいは他のホスト対ホストプロトコルの見
地からのデータの発信者あるいは着信者。
PUSH
A control bit occupying no sequence space, indicating that
this segment contains data that must be pushed through to the
receiving user.
このセグメントが受信ユーザに完全に押されなくてはならないデー
タを含んでいることを表して、シーケンス空間を占領しない制御
ビット。
RCV.NXT
receive next sequence number
次の受信シーケンス番号
RCV.UP
receive urgent pointer
受信緊急ポインタ
RCV.WND
receive window
受信ウインドウ
receive next sequence number
This is the next sequence number the local TCP is expecting to
receive.
これはローカルTCPが受け取ることを予期している次のシーケンス番
号である。
receive window
This represents the sequence numbers the local (receiving) TCP
is willing to receive. Thus, the local TCP considers that
segments overlapping the range RCV.NXT to
RCV.NXT + RCV.WND - 1 carry acceptable data or control.
Segments containing sequence numbers entirely outside of this
range are considered duplicates and discarded.
これはローカル（受信）TCPが受け取ることをいとわないシーケンス
番号を表す。それで、ローカルTCPはRCV.NXT+RCV.WND-1とRCV.NXTの
範囲を重ねて、セグメントの運ぶ受容できるデータあるいはコント
ロールを検討する。全てこの範囲以外のシーケンス番号を含んでい
るセグメントが重複であると検討されて、そして捨てられる。
RST
A control bit (reset), occupying no sequence space, indicating
that the receiver should delete the connection without further
interaction. The receiver can determine, based on the
sequence number and acknowledgment fields of the incoming
segment, whether it should honor the reset command or ignore
it. In no case does receipt of a segment containing RST give
rise to a RST in response.
シーケンス空間を占領しなくて、受信者がそれ以上の交互作用無しで
接続を削除するべきであることを表しす、１制御ビット（リセット）。
受信者は、シーケンス番号と入ってくるセグメントの確認応答フィー
ルドに基づいて、それのリセットコマンドを重んじるか、あるいはそ
れを無視するべきであるかどうか決定することができる。RSTを含む
セグメントの受領通知が応答でRSTに上昇を与えることはない。
RTP
Real Time Protocol: A host-to-host protocol for communication
of time critical information.
リアルタイムプロトコル：時間が重要な情報のコミュニケーションの
ためのホスト対ホストプロトコル。
SEG.ACK
segment acknowledgment
セグメント確認応答
SEG.LEN
segment length
セグメント長
SEG.PRC
segment precedence value
セグメント優先順位値
SEG.SEQ
segment sequence
セグメントシーケンス
SEG.UP
segment urgent pointer field
セグメント緊急ポインタフィールド
SEG.WND
segment window field
セグメントウインドウフィールド
segment
A logical unit of data, in particular a TCP segment is the
unit of data transfered between a pair of TCP modules.
データの論理ユニットで、特にTCPセグメントが１対のTCPモジュール
の間に移されるデータのユニットである。
segment acknowledgment
The sequence number in the acknowledgment field of the
arriving segment.
到着しているセグメントの確認応答フィールドの中のシーケンス番号。
segment length
The amount of sequence number space occupied by a segment,
including any controls which occupy sequence space.
シーケンス空間を占領するどんなコントロールも含むセグメントによっ
て占領されたシーケンス番号空間の量。
segment sequence
The number in the sequence field of the arriving segment.
到着しているセグメントのシーケンスフィールドの中の番号。
send sequence
This is the next sequence number the local (sending) TCP will
use on the connection. It is initially selected from an
initial sequence number curve (ISN) and is incremented for
each octet of data or sequenced control transmitted.
これはローカルな（送信）TCPが接続の上で使うであろう次のシーケ
ンス番号である。それは最初のシーケンス番号曲線（ISN）から初め
に選ばれて、そしてそれぞれの送信データあるいは順序立てて並べら
れたコントロールのオクテットのために増加する。
send window
This represents the sequence numbers which the remote
(receiving) TCP is willing to receive. It is the value of the
window field specified in segments from the remote (data
receiving) TCP. The range of new sequence numbers which may
be emitted by a TCP lies between SND.NXT and
SND.UNA + SND.WND - 1. (Retransmissions of sequence numbers
between SND.UNA and SND.NXT are expected, of course.)
これは遠隔の（受信）TCPが受け取ることをいとわないシーケンス番
号を表す。それは遠隔の（データを受け取って）いるTCPからセグメ
ントで指定されるウインドウフィールドの値である。TCPによって発
散されるかも知れない新しいシーケンス番号の距離はSND.NXTと
SND.UNA+SND.WND-1の間に横たわる。（SND.UNAとSND.NXTの間のシー
ケンス番号の再送が、もちろん、期待される。）
SND.NXT
send sequence
シーケンスを送りなさい
SND.UNA
left sequence
左のシーケンス
SND.UP
send urgent pointer
送信緊急ポインタ
SND.WL1
segment sequence number at last window update
最後のウインドウ更新においてのセグメントシーケンス番号
SND.WL2
segment acknowledgment number at last window update
最後のウインドウ更新においてのセグメント確認番号
SND.WND
send window
送信ウインドウ
socket
An address which specifically includes a port identifier, that
is, the concatenation of an Internet Address with a TCP port.
特にポート識別子を含むアドレス、それはTCPポートとインターネッ
トアドレスの連結である。
Source Address
The source address, usually the network and host identifiers.
発信アドレス、通常ネットワークとホスト識別子。
SYN
A control bit in the incoming segment, occupying one sequence
number, used at the initiation of a connection, to indicate
where the sequence numbering will start.
入ってくるセグメントでの、１つのシーケンス番号を占領する制御
ビット、接続の起動において、どこで順序番号付けが始まるであろ
うか示したものであった。
TCB
Transmission control block, the data structure that records
the state of a connection.
送信制御ブロック、接続の状態を記録するデータ構造。
TCB.PRC
The precedence of the connection.
接続の優先順位。
TCP
Transmission Control Protocol: A host-to-host protocol for
reliable communication in internetwork environments.
送信制御プロトコル：信頼できるコミュニケーションのためにイン
ターネットワーク環境でホスト対ホストプロトコル。
TOS
Type of Service, an Internet Protocol field.
タイプオブサービス、インターネット・プロトコルフィールド。
Type of Service
An Internet Protocol field which indicates the type of service
for this internet fragment.
このインターネットフラグメントのためにタイプオブサービスを示す
インターネット・プロトコルフィールド。
URG
A control bit (urgent), occupying no sequence space, used to
indicate that the receiving user should be notified to do
urgent processing as long as there is data to be consumed with
sequence numbers less than the value indicated in the urgent
pointer.
シーケンス空間を占領しない制御ビット（緊急）、受信ユーザが緊急
ポインタで示した値より少ないシーケンス番号のデータがある限り、
非常処理をするように知らせられるべきであることを表したものであ
る。
urgent pointer
A control field meaningful only when the URG bit is on. This
field communicates the value of the urgent pointer which
indicates the data octet associated with the sending user's
urgent call.
ただURGビットがオンにである時だけ意味がある制御フィールド。こ
のフィールドはデータオクテットが送信ユーザの至急通話と提携し
たことを表す緊急ポインタの値を伝える。
REFERENCES
参考文献
[1] Cerf, V., and R. Kahn, "A Protocol for Packet Network
Intercommunication", IEEE Transactions on Communications,
Vol. COM-22, No. 5, pp 637-648, May 1974.
[2] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
Protocol Specification", RFC 791, USC/Information Sciences
Institute, September 1981.
[3] Dalal, Y. and C. Sunshine, "Connection Management in Transport
Protocols", Computer Networks, Vol. 2, No. 6, pp. 454-473,
December 1978.
[4] Postel, J., "Assigned Numbers", RFC 790, USC/Information Sciences
Institute, September 1981.