[要約] RFC 9293 は、TCP の進化と変更をまとめたものであり、RFC 793 を置き換えるものです。TCP の仕様と変更点を包括的に記述しています。
Internet Engineering Task Force (IETF) W. Eddy, Ed.
STD: 7 MTI Systems
Request for Comments: 9293 August 2022
Obsoletes: 793, 879, 2873, 6093, 6429, 6528,
6691
Updates: 1011, 1122, 5961
Category: Standards Track
ISSN: 2070-1721
Transmission Control Protocol (TCP)
トランスミッションコントロールプロトコル（TCP）
Abstract
概要
This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.
このドキュメントは、伝送制御プロトコル（TCP）を指定します。TCPは、インターネットプロトコルスタックの重要な輸送層プロトコルであり、インターネットの数十年の使用と成長にわたって継続的に進化しています。この間、RFC 793で指定されたように、TCPに多くの変更が行われましたが、これらは断片的な方法でのみ文書化されています。このドキュメントは、RFC 793からのプロトコル仕様とともにこれらの変更を収集してもたらします。このドキュメントは、RFCS 879、2873、6093、6429、6528、および6691を廃止します。1122、そしてTCP要件を扱うそれらのドキュメントの一部の代替品と見なされるべきです。また、同期された状態でリセット処理で小さな明確化を追加することにより、RFC 5961を更新します。RFC 793のTCPヘッダー制御ビットもRFC 3168に基づいて更新されています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9293.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9293で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Purpose and Scope
2. Introduction
2.1. Requirements Language
2.2. Key TCP Concepts
3. Functional Specification
3.1. Header Format
3.2. Specific Option Definitions
3.2.1. Other Common Options
3.2.2. Experimental TCP Options
3.3. TCP Terminology Overview
3.3.1. Key Connection State Variables
3.3.2. State Machine Overview
3.4. Sequence Numbers
3.4.1. Initial Sequence Number Selection
3.4.2. Knowing When to Keep Quiet
3.4.3. The TCP Quiet Time Concept
3.5. Establishing a Connection
3.5.1. Half-Open Connections and Other Anomalies
3.5.2. Reset Generation
3.5.3. Reset Processing
3.6. Closing a Connection
3.6.1. Half-Closed Connections
3.7. Segmentation
3.7.1. Maximum Segment Size Option
3.7.2. Path MTU Discovery
3.7.3. Interfaces with Variable MTU Values
3.7.4. Nagle Algorithm
3.7.5. IPv6 Jumbograms
3.8. Data Communication
3.8.1. Retransmission Timeout
3.8.2. TCP Congestion Control
3.8.3. TCP Connection Failures
3.8.4. TCP Keep-Alives
3.8.5. The Communication of Urgent Information
3.8.6. Managing the Window
3.9. Interfaces
3.9.1. User/TCP Interface
3.9.2. TCP/Lower-Level Interface
3.10. Event Processing
3.10.1. OPEN Call
3.10.2. SEND Call
3.10.3. RECEIVE Call
3.10.4. CLOSE Call
3.10.5. ABORT Call
3.10.6. STATUS Call
3.10.7. SEGMENT ARRIVES
3.10.8. Timeouts
4. Glossary
5. Changes from RFC 793
6. IANA Considerations
7. Security and Privacy Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Other Implementation Notes
A.1. IP Security Compartment and Precedence
A.1.1. Precedence
A.1.2. MLS Systems
A.2. Sequence Number Validation
A.3. Nagle Modification
A.4. Low Watermark Settings
Appendix B. TCP Requirement Summary
Acknowledgments
Author's Address
In 1981, RFC 793 [16] was released, documenting the Transmission Control Protocol (TCP) and replacing earlier published specifications for TCP.
1981年、RFC 793 [16]がリリースされ、伝送制御プロトコル（TCP）を文書化し、TCPの以前に公開された仕様を置き換えました。
Since then, TCP has been widely implemented, and it has been used as a transport protocol for numerous applications on the Internet.
それ以来、TCPは広く実装されており、インターネット上の多数のアプリケーションの輸送プロトコルとして使用されています。
For several decades, RFC 793 plus a number of other documents have combined to serve as the core specification for TCP [49]. Over time, a number of errata have been filed against RFC 793. There have also been deficiencies found and resolved in security, performance, and many other aspects. The number of enhancements has grown over time across many separate documents. These were never accumulated together into a comprehensive update to the base specification.
数十年にわたり、RFC 793と他の多くのドキュメントが組み合わさって、TCPのコア仕様として機能してきました[49]。時間が経つにつれて、RFC 793に対して多くのERRATAが提出されました。また、セキュリティ、パフォーマンス、その他多くの側面で見つかった不足が見つかり、解決されました。強化の数は、多くの個別のドキュメントで時間とともに増加しています。これらは、ベース仕様の包括的な更新に蓄積されることはありませんでした。
The purpose of this document is to bring together all of the IETF Standards Track changes and other clarifications that have been made to the base TCP functional specification (RFC 793) and to unify them into an updated version of the specification.
このドキュメントの目的は、すべてのIETF標準を追跡し、ベースTCP機能仕様（RFC 793）に対して行われたその他の明確化を追跡し、それらを更新されたバージョンの仕様に統合することです。
Some companion documents are referenced for important algorithms that are used by TCP (e.g., for congestion control) but have not been completely included in this document. This is a conscious choice, as this base specification can be used with multiple additional algorithms that are developed and incorporated separately. This document focuses on the common basis that all TCP implementations must support in order to interoperate. Since some additional TCP features have become quite complicated themselves (e.g., advanced loss recovery and congestion control), future companion documents may attempt to similarly bring these together.
一部のコンパニオンドキュメントは、TCPで使用される重要なアルゴリズム（渋滞制御のために）で参照されていますが、このドキュメントには完全に含まれていません。これは意識的な選択です。このベース仕様は、個別に開発および組み込まれる複数の追加アルゴリズムで使用できるためです。このドキュメントは、すべてのTCP実装が相互運用するためにサポートする必要があるという共通に焦点を当てています。いくつかの追加のTCP機能が非常に複雑になっているため（例：高度な損失の回復と輻輳制御など）、将来のコンパニオン文書も同様にこれらをまとめようとするかもしれません。
In addition to the protocol specification that describes the TCP segment format, generation, and processing rules that are to be implemented in code, RFC 793 and other updates also contain informative and descriptive text for readers to understand aspects of the protocol design and operation. This document does not attempt to alter or update this informative text and is focused only on updating the normative protocol specification. This document preserves references to the documentation containing the important explanations and rationale, where appropriate.
コードで実装されるTCPセグメント形式、生成、および処理ルールを記述するプロトコル仕様に加えて、RFC 793およびその他の更新には、読者がプロトコルの設計と操作の側面を理解するための有益で記述的なテキストも含まれています。このドキュメントは、この有益なテキストを変更または更新しようとせず、規範的プロトコル仕様の更新にのみ焦点を当てています。このドキュメントでは、必要に応じて、重要な説明と理論的根拠を含むドキュメントへの参照を保持しています。
This document is intended to be useful both in checking existing TCP implementations for conformance purposes, as well as in writing new implementations.
このドキュメントは、適合目的で既存のTCP実装をチェックすることと、新しい実装を書くことの両方に役立つことを目的としています。
RFC 793 contains a discussion of the TCP design goals and provides examples of its operation, including examples of connection establishment, connection termination, and packet retransmission to repair losses.
RFC 793には、TCPの設計目標の議論が含まれており、接続確立、接続終了、パケットの再送信の例を含む、その運用の例を提供します。
This document describes the basic functionality expected in modern TCP implementations and replaces the protocol specification in RFC 793. It does not replicate or attempt to update the introduction and philosophy content in Sections 1 and 2 of RFC 793. Other documents are referenced to provide explanations of the theory of operation, rationale, and detailed discussion of design decisions. This document only focuses on the normative behavior of the protocol.
このドキュメントでは、最新のTCP実装で予想される基本機能について説明し、RFC 793のプロトコル仕様を置き換えます。RFC793のセクション1および2の紹介と哲学の内容を再現または更新しようとしません。設計上の決定の操作、根拠、および詳細な議論。このドキュメントは、プロトコルの規範的な動作にのみ焦点を当てています。
The "TCP Roadmap" [49] provides a more extensive guide to the RFCs that define TCP and describe various important algorithms. The TCP Roadmap contains sections on strongly encouraged enhancements that improve performance and other aspects of TCP beyond the basic operation specified in this document. As one example, implementing congestion control (e.g., [8]) is a TCP requirement, but it is a complex topic on its own and not described in detail in this document, as there are many options and possibilities that do not impact basic interoperability. Similarly, most TCP implementations today include the high-performance extensions in [47], but these are not strictly required or discussed in this document. Multipath considerations for TCP are also specified separately in [59].
「TCPロードマップ」[49]は、TCPを定義し、さまざまな重要なアルゴリズムを記述するRFCSのより広範なガイドを提供します。TCPロードマップには、このドキュメントで指定された基本操作を超えて、パフォーマンスやTCPの他の側面を改善する強力な促進拡張機能に関するセクションが含まれています。一例として、輻輳制御の実装（[8]）の実装はTCP要件ですが、基本的な相互運用性に影響を与えない多くのオプションと可能性があるため、このドキュメントでは詳細に説明されていない複雑なトピックです。。同様に、今日のほとんどのTCP実装には、[47]の高性能拡張機能が含まれていますが、これらはこのドキュメントで厳密に必要または議論されていません。TCPのマルチパスに関する考慮事項も[59]で個別に指定されています。
A list of changes from RFC 793 is contained in Section 5.
RFC 793からの変更のリストは、セクション5に含まれています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [3] [12] when, and only when, they appear in all capitals, as shown here.
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「このドキュメントでは、BCP 14 [3] [12]で説明されているように解釈されます。
Each use of RFC 2119 keywords in the document is individually labeled and referenced in Appendix B, which summarizes implementation requirements.
ドキュメント内のRFC 2119キーワードの各使用は、実装要件を要約する付録Bで個別にラベル付けおよび参照されます。
Sentences using "MUST" are labeled as "MUST-X" with X being a numeric identifier enabling the requirement to be located easily when referenced from Appendix B.
「必須」を使用した文は「必須X」とラベル付けされ、xは数値識別子であり、付録Bから参照されると簡単に配置できる要件を可能にします。
Similarly, sentences using "SHOULD" are labeled with "SHLD-X", "MAY" with "MAY-X", and "RECOMMENDED" with "REC-X".
同様に、「seff」を使用した文は、「shld-x」、「5月」で「5月x」、および「rec-x」で「推奨」でラベル付けされます。
For the purposes of this labeling, "SHOULD NOT" and "MUST NOT" are labeled the same as "SHOULD" and "MUST" instances.
このラベル付けの目的のために、「すべきではない」と「そうでない」は、「必要」と「必須」と同じようにラベル付けされます。
TCP provides a reliable, in-order, byte-stream service to applications.
TCPは、アプリケーションに信頼できる、注文内のバイトストリームサービスを提供します。
The application byte-stream is conveyed over the network via TCP segments, with each TCP segment sent as an Internet Protocol (IP) datagram.
アプリケーションバイトストリームは、TCPセグメントを介してネットワークを介して伝達され、各TCPセグメントはインターネットプロトコル（IP）データグラムとして送信されます。
TCP reliability consists of detecting packet losses (via sequence numbers) and errors (via per-segment checksums), as well as correction via retransmission.
TCPの信頼性は、パケット損失（シーケンス番号を介して）とエラー（セグメントごとのチェックサムを介して）の検出、および再送信による修正で構成されています。
TCP supports unicast delivery of data. There are anycast applications that can successfully use TCP without modifications, though there is some risk of instability due to changes of lower-layer forwarding behavior [46].
TCPは、データのユニキャスト配信をサポートしています。低層転送挙動の変化により不安定性のリスクがあるが、変更なしでTCPを正常に使用できるAnycastアプリケーションがあります[46]。
TCP is connection oriented, though it does not inherently include a liveness detection capability.
TCPは接続指向ですが、本質的にlivension検出機能は含まれていません。
Data flow is supported bidirectionally over TCP connections, though applications are free to send data only unidirectionally, if they so choose.
データフローは、TCP接続で双方向でサポートされていますが、アプリケーションは自由にデータを選択しても、選択した場合にのみ独自のものを送信できます。
TCP uses port numbers to identify application services and to multiplex distinct flows between hosts.
TCPは、ポート番号を使用してアプリケーションサービスを識別し、ホスト間の異なるフローを多重化します。
A more detailed description of TCP features compared to other transport protocols can be found in Section 3.1 of [52]. Further description of the motivations for developing TCP and its role in the Internet protocol stack can be found in Section 2 of [16] and earlier versions of the TCP specification.
他の輸送プロトコルと比較したTCP機能のより詳細な説明は、[52]のセクション3.1に記載されています。TCPを開発する動機とインターネットプロトコルスタックにおけるその役割のさらなる説明は、[16]およびTCP仕様の以前のバージョンのセクション2に記載されています。
TCP segments are sent as internet datagrams. The Internet Protocol (IP) header carries several information fields, including the source and destination host addresses [1] [13]. A TCP header follows the IP headers, supplying information specific to TCP. This division allows for the existence of host-level protocols other than TCP. In the early development of the Internet suite of protocols, the IP header fields had been a part of TCP.
TCPセグメントはインターネットデータグラムとして送信されます。インターネットプロトコル（IP）ヘッダーには、ソースおよび宛先ホストアドレス[1] [13]を含むいくつかの情報フィールドが搭載されています。TCPヘッダーはIPヘッダーに従い、TCPに固有の情報を提供します。この部門は、TCP以外のホストレベルのプロトコルの存在を可能にします。インターネットスイートのプロトコルの初期の開発では、IPヘッダーフィールドはTCPの一部でした。
This document describes TCP, which uses TCP headers.
このドキュメントは、TCPヘッダーを使用するTCPについて説明しています。
A TCP header, followed by any user data in the segment, is formatted as follows, using the style from [66]:
[66]のスタイルを使用して、セグメント内のユーザーデータが次に続く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 | |C|E|U|A|P|R|S|F| |
| Offset| Rsrvd |W|C|R|C|S|S|Y|I| Window |
| | |R|E|G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Options] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
: Data :
: |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that one tick mark represents one bit position.
1つのティックマークが1つのビット位置を表すことに注意してください。
Figure 1: TCP Header Format
図1：TCPヘッダー形式
where:
ただし：
Source Port: 16 bits
ソースポート：16ビット
The source port number.
ソースポート番号。
Destination Port: 16 bits
宛先ポート：16ビット
The destination port number.
宛先ポート番号。
Sequence Number: 32 bits
シーケンス番号：32ビット
The sequence number of the first data octet in this segment (except when the SYN flag is set). If SYN is set, the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1.
このセグメントの最初のデータOctetのシーケンス番号（Synフラグが設定されている場合を除く）。Synが設定されている場合、シーケンス番号は初期シーケンス番号（ISN）であり、最初のデータOctetはISN 1です。
Acknowledgment Number: 32 bits
謝辞番号：32ビット
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 (DOffset): 4 bits
データオフセット（doffset）：4ビット
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 integer multiple of 32 bits long.
TCPヘッダーの32ビット語の数。これは、データがどこから始まるかを示します。TCPヘッダー（オプションを含むものも）は、長さ32ビットの整数倍です。
Reserved (Rsrvd): 4 bits
予約済み（RSRVD）：4ビット
A set of control bits reserved for future use. Must be zero in generated segments and must be ignored in received segments if the corresponding future features are not implemented by the sending or receiving host.
将来の使用のために予約されているコントロールビットのセット。生成されたセグメントではゼロである必要があり、対応する将来の機能が送信または受信ホストによって実装されていない場合は、受信セグメントで無視する必要があります。
Control bits: The control bits are also known as "flags". Assignment is managed by IANA from the "TCP Header Flags" registry [62]. The currently assigned control bits are CWR, ECE, URG, ACK, PSH, RST, SYN, and FIN.
コントロールビット：コントロールビットは「フラグ」とも呼ばれます。割り当ては、「TCPヘッダーフラグ」レジストリ[62]のIANAによって管理されます。現在割り当てられているコントロールビットは、CWR、ECE、URG、ACK、PSH、RST、SYN、およびFINです。
CWR: 1 bit
CWR：1ビット
Congestion Window Reduced (see [6]).
輻輳ウィンドウが減少しました（[6]を参照）。
ECE: 1 bit
ECE：1ビット
ECN-Echo (see [6]).
ECNエコー（[6]を参照）。
URG: 1 bit
urg：1ビット
Urgent pointer field is significant.
緊急のポインターフィールドは重要です。
ACK: 1 bit
ACK：1ビット
Acknowledgment field is significant.
謝辞フィールドは重要です。
PSH: 1 bit
PSH：1ビット
Push function (see the Send Call description in Section 3.9.1).
プッシュ関数（セクション3.9.1の送信コール説明を参照）。
RST: 1 bit
RST：1ビット
Reset the connection.
接続をリセットします。
SYN: 1 bit
syn：1ビット
Synchronize sequence numbers.
シーケンス番号を同期します。
FIN: 1 bit
フィン：1ビット
No more data from sender.
送信者からのデータはもうありません。
Window: 16 bits
ウィンドウ：16ビット
The number of data octets beginning with the one indicated in the acknowledgment field that the sender of this segment is willing to accept. The value is shifted when the window scaling extension is used [47].
このセグメントの送信者が受け入れる意思があることを確認分野で示されたものから始まるデータの数の数。ウィンドウスケーリング拡張機能を使用すると、値はシフトされます[47]。
The window size MUST be treated as an unsigned number, or else large window sizes will appear like negative windows and TCP will not work (MUST-1). It is RECOMMENDED that implementations will reserve 32-bit fields for the send and receive window sizes in the connection record and do all window computations with 32 bits (REC-1).
ウィンドウサイズは署名のない数字として扱う必要があります。そうしないと、大きなウィンドウサイズがネガティブウィンドウのように表示され、TCPは機能しません（必須）。実装は、接続レコードの送信および受信ウィンドウサイズに32ビットフィールドを予約し、32ビット（REC-1）ですべてのウィンドウ計算を行うことをお勧めします。
Checksum: 16 bits
チェックサム：16ビット
The checksum field is the 16-bit ones' complement of the ones' complement sum of all 16-bit words in the header and text. The checksum computation needs to ensure the 16-bit alignment of the data being summed. If a segment contains an odd number of header and text octets, alignment can be achieved by padding the last octet with zeros on its right 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ビットの補数の16ビットのフィールドの補体です。チェックサムの計算では、合計されているデータの16ビットアライメントを確保する必要があります。セグメントに奇数のヘッダーとテキストのオクテットが含まれている場合、チェックサムの目的で16ビット語を形成するために、ゼロをゼロで最後のオクテットをパディングすることでアラインメントを達成できます。パッドはセグメントの一部として送信されません。チェックサムを計算している間、チェックサムフィールド自体はゼロに置き換えられます。
The checksum also covers a pseudo-header (Figure 2) conceptually prefixed to the TCP header. The pseudo-header is 96 bits for IPv4 and 320 bits for IPv6. Including the pseudo-header in the checksum gives the TCP connection protection against misrouted segments. This information is carried in IP headers and is transferred across the TCP/network interface in the arguments or results of calls by the TCP implementation on the IP layer.
チェックサムは、TCPヘッダーに概念的に前に付けられた擬似ヘッダー（図2）もカバーしています。擬似ヘッダーは、IPv4では96ビット、IPv6では320ビットです。チェックサムに擬似ヘッダーを含めると、誤った誤ったセグメントに対するTCP接続保護が得られます。この情報はIPヘッダーで伝えられ、IPレイヤー上のTCP実装によるコールの引数または結果のTCP/ネットワークインターフェイス全体で転送されます。
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
Figure 2: IPv4 Pseudo-header
図2：IPv4 pseudo-header
Pseudo-header components for IPv4: Source Address: the IPv4 source address in network byte order
IPv4用の擬似ヘッダーコンポーネント：ソースアドレス：ネットワークバイト順序のIPv4ソースアドレス
Destination Address: the IPv4 destination address in network byte order
宛先アドレス：ネットワークバイトの順序でIPv4宛先アドレス
zero: bits set to zero
ゼロ：ビットはゼロに設定されています
PTCL: the protocol number from the IP header
PTCL：IPヘッダーからのプロトコル番号
TCP Length: 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ヘッダーの長さとオクテットのデータ長さ（これは明示的に送信された量ではなく、計算されます）であり、擬似ヘッダーの12オクテットをカウントしません。
For IPv6, the pseudo-header is defined in Section 8.1 of RFC 8200 [13] and contains the IPv6 Source Address and Destination Address, an Upper-Layer Packet Length (a 32-bit value otherwise equivalent to TCP Length in the IPv4 pseudo-header), three bytes of zero padding, and a Next Header value, which differs from the IPv6 header value if there are extension headers present between IPv6 and TCP.
IPv6の場合、擬似ヘッダーはRFC 8200のセクション8.1 [13]で定義されており、IPv6ソースアドレスと宛先アドレス、上層層パケット長（IPv4擬似のTCP長さに相当する32ビット値（32ビット値）が含まれています。ヘッダー）、3バイトのゼロパディング、および次のヘッダー値。IPv6とTCPの間に拡張ヘッダーが存在する場合、IPv6ヘッダー値とは異なります。
The TCP checksum is never optional. The sender MUST generate it (MUST-2) and the receiver MUST check it (MUST-3).
TCPチェックサムは決してオプションではありません。送信者はそれを生成する必要があり（Must-2）、受信者はそれをチェックする必要があります（必須3）。
Urgent Pointer: 16 bits
緊急ポインター：16ビット
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 to be interpreted in segments with the URG control bit set.
このフィールドは、このセグメントのシーケンス番号からの正のオフセットとして、緊急ポインターの現在の値を伝えます。緊急のポインターは、緊急データに続くオクテットのシーケンス番号を指します。このフィールドは、URGコントロールビットセットのあるセグメントでのみ解釈されます。
Options: [TCP Option]; size(Options) == (DOffset-5)*32; present only
when DOffset > 5. Note that this size expression also includes any
padding trailing the actual options present.
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ヘッダーの端にあるスペースを占める場合があり、長さは8ビットの倍数です。すべてのオプションはチェックサムに含まれています。オプションは、オクテットの境界で開始される場合があります。オプションの形式には2つのケースがあります。
Case 1: A single octet of option-kind.
ケース1：オプションキンドの単一のオクテット。
Case 2: An octet of option-kind (Kind), an octet of option-length, and the actual option-data octets.
ケース2：オプションキンド（種類）のオクテット、オプション長のオクテット、および実際のオプションデータオクテット。
The option-length counts the two octets of option-kind and option-length as well as the option-data octets.
オプション長は、オプションキンドとオプション長の2オクテットとオプションデータオクテットをカウントします。
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 List Option MUST be header padding of zeros (MUST-69).
オプションのリストは、データのオフセットフィールドが暗示するよりも短い場合があることに注意してください。オプションリストの終わりを超えたヘッダーのコンテンツは、ゼロのヘッダーパディングでなければなりません（必見）。
The list of all currently defined options is managed by IANA [62], and each option is defined in other RFCs, as indicated there. That set includes experimental options that can be extended to support multiple concurrent usages [45].
現在定義されているすべてのオプションのリストはIANA [62]によって管理されており、各オプションは他のRFCで定義されています。このセットには、複数の同時使用をサポートするために拡張できる実験オプションが含まれています[45]。
A given TCP implementation can support any currently defined options, but the following options MUST be supported (MUST-4 -- note Maximum Segment Size Option support is also part of MUST-14 in Section 3.7.1):
指定されたTCP実装は、現在定義されているオプションをサポートできますが、次のオプションをサポートする必要があります（マスト4-注最大セグメントサイズオプションサポートは、セクション3.7.1のマスト14の一部でもあります）：
+======+========+============================+
| Kind | Length | Meaning |
+======+========+============================+
| 0 | - | End of Option List Option. |
+------+--------+----------------------------+
| 1 | - | No-Operation. |
+------+--------+----------------------------+
| 2 | 4 | Maximum Segment Size. |
+------+--------+----------------------------+
Table 1: Mandatory Option Set
表1：必須オプションセット
These options are specified in detail in Section 3.2.
これらのオプションは、セクション3.2で詳細に指定されています。
A TCP implementation MUST be able to receive a TCP Option in any segment (MUST-5).
TCP実装は、任意のセグメント（必須5）でTCPオプションを受信できる必要があります。
A TCP implementation MUST (MUST-6) ignore without error any TCP Option it does not implement, assuming that the option has a length field. All TCP Options except End of Option List Option (EOL) and No-Operation (NOP) MUST have length fields, including all future options (MUST-68). TCP implementations MUST be prepared to handle an illegal option length (e.g., zero); a suggested procedure is to reset the connection and log the error cause (MUST-7).
TCP実装は、オプションに長さフィールドがあると仮定して、実装していないTCPオプションをエラーなしで無視する必要があります。オプションリストの終了オプション（EOL）およびノーオペレーション（NOP）を除くすべてのTCPオプションには、すべての将来のオプションを含む長さのフィールドが必要です（必見）。TCP実装は、違法なオプションの長さ（ゼロなど）を処理するために準備する必要があります。推奨される手順は、接続をリセットし、エラー原因を記録することです（必見）。
Note: There is ongoing work to extend the space available for TCP Options, such as [65].
注：[65]などのTCPオプションで利用可能なスペースを拡張するための継続的な作業があります。
Data: variable length
データ：変数長
User data carried by the TCP segment.
TCPセグメントによって運ばれるユーザーデータ。
A TCP Option, in the mandatory option set, is one of an End of Option List Option, a No-Operation Option, or a Maximum Segment Size Option.
必須オプションセットのTCPオプションは、オプションリストの終了オプション、オペレーションなしオプション、または最大セグメントサイズオプションの1つです。
An End of Option List Option is formatted as follows:
オプションリストの終了オプションは、次のようにフォーマットされます。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
where:
ただし：
Kind: 1 byte; Kind == 0.
種類：1バイト;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ヘッダーの終了と一致しない場合にのみ使用する必要があります。
A No-Operation Option is formatted as follows:
操作なしオプションは次のようにフォーマットされます。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+
where:
ただし：
Kind: 1 byte; Kind == 1.
種類：1バイト;Kind == 1。
This option code can 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 (MUST-64).
このオプションコードは、たとえば、単語の境界上の後続のオプションの先頭を調整するためにオプション間で使用できます。送信者がこのオプションを使用するという保証はないため、単語の境界（必見）で開始しなくても、受信機をオプションを処理する準備をする必要があります。
A Maximum Segment Size Option is formatted as follows:
次のように、最大セグメントサイズオプションがフォーマットされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Length | Maximum Segment Size (MSS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Kind: 1 byte; Kind == 2.
種類：1バイト;Kind == 2。
If this option is present, then it communicates the maximum receive segment size at the TCP endpoint that sends this segment. This value is limited by the IP reassembly limit. This field may be sent in the initial connection request (i.e., in segments with the SYN control bit set) and MUST NOT be sent in other segments (MUST-65). If this option is not used, any segment size is allowed. A more complete description of this option is provided in Section 3.7.1.
このオプションが存在する場合、このセグメントを送信するTCPエンドポイントで最大受信セグメントサイズを通知します。この値は、IP再組み立て制限によって制限されます。このフィールドは、最初の接続要求（つまり、Syn Control Bit Setのセグメント）で送信され、他のセグメントで送信しないでください（必須65）。このオプションが使用されない場合、セグメントサイズは許可されます。このオプションのより完全な説明は、セクション3.7.1に記載されています。
Length: 1 byte; Length == 4.
長さ：1バイト;長さ== 4。
Length of the option in bytes.
バイト内のオプションの長さ。
Maximum Segment Size (MSS): 2 bytes.
最大セグメントサイズ（MSS）：2バイト。
The maximum receive segment size at the TCP endpoint that sends this segment.
このセグメントを送信するTCPエンドポイントでの最大受信セグメントサイズ。
Additional RFCs define some other commonly used options that are recommended to implement for high performance but are not necessary for basic TCP interoperability. These are the TCP Selective Acknowledgment (SACK) Option [22] [26], TCP Timestamp (TS) Option [47], and TCP Window Scale (WS) Option [47].
追加のRFCは、高性能のために実装することをお勧めしますが、基本的なTCPの相互運用性には必要ない一般的に使用される他のいくつかのオプションを定義します。これらは、TCP Selective Aumponedment（SACK）オプション[22] [26]、TCPタイムスタンプ（TS）オプション[47]、およびTCPウィンドウスケール（WS）オプション[47]です。
Experimental TCP Option values are defined in [30], and [45] describes the current recommended usage for these experimental values.
実験的なTCPオプション値は[30]で定義されており、[45]は、これらの実験値の現在の推奨使用法を説明しています。
This section includes an overview of key terms needed to understand the detailed protocol operation in the rest of the document. There is a glossary of terms in Section 4.
このセクションには、ドキュメントの残りの部分で詳細なプロトコル操作を理解するために必要な重要な用語の概要が含まれています。セクション4には用語の用語集があります。
Before we can discuss the operation of the TCP implementation in detail, we need to introduce some detailed terminology. The maintenance of a TCP connection requires maintaining state for 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 IP addresses and port numbers, the IP security level, and compartment of the connection (see Appendix A.1), 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に保存されている変数の中には、ローカルおよびリモートIPアドレスとポート番号、IPセキュリティレベル、接続のコンパートメント（付録A.1を参照）、ユーザーの送信および受信バッファーのポインター、再送信キューへのポインターがあります。そして現在のセグメントに。さらに、送信および受信シーケンス番号に関連するいくつかの変数がTCBに保存されます。
+==========+=====================================================+
| Variable | Description |
+==========+=====================================================+
| 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 |
+----------+-----------------------------------------------------+
Table 2: Send Sequence Variables
表2：シーケンス変数を送信します
+==========+=================================+
| Variable | Description |
+==========+=================================+
| RCV.NXT | receive next |
+----------+---------------------------------+
| RCV.WND | receive window |
+----------+---------------------------------+
| RCV.UP | receive urgent pointer |
+----------+---------------------------------+
| IRS | initial receive sequence number |
+----------+---------------------------------+
Table 3: Receive Sequence Variables
表3：シーケンス変数を受信します
The following diagrams may help to relate some of these variables to the sequence space.
次の図は、これらの変数の一部をシーケンス空間に関連付けるのに役立つ場合があります。
1 2 3 4
----------|----------|----------|----------
SND.UNA SND.NXT SND.UNA
+SND.WND
1 - old sequence numbers that have been acknowledged 2 - sequence numbers of unacknowledged data 3 - sequence numbers allowed for new data transmission 4 - future sequence numbers that are not yet allowed
1-認識されている古いシーケンス番号2-シーケンスの未充填データの数値3-新しいデータ送信に許可されるシーケンス番号 - まだ許可されていない将来のシーケンス番号
Figure 3: Send Sequence Space
図3：シーケンススペースを送信します
The send window is the portion of the sequence space labeled 3 in Figure 3.
送信ウィンドウは、図3の3にラベル付けされたシーケンススペースの部分です。
1 2 3
----------|----------|----------
RCV.NXT RCV.NXT
+RCV.WND
1 - old sequence numbers that have been acknowledged 2 - sequence numbers allowed for new reception 3 - future sequence numbers that are not yet allowed
1-認められている古いシーケンス番号2-新しい受信に許可されるシーケンス番号3-まだ許可されていない将来のシーケンス番号
Figure 4: Receive Sequence Space
図4：シーケンススペースを受信します
The receive window is the portion of the sequence space labeled 2 in Figure 4.
受信ウィンドウは、図4に2ラベル付けされたシーケンススペースの部分です。
There are also some variables used frequently in the discussion that take their values from the fields of the current segment.
また、議論で頻繁に使用されるいくつかの変数があり、現在のセグメントのフィールドから価値を取得しています。
+==========+===============================+
| Variable | Description |
+==========+===============================+
| SEG.SEQ | segment sequence number |
+----------+-------------------------------+
| SEG.ACK | segment acknowledgment number |
+----------+-------------------------------+
| SEG.LEN | segment length |
+----------+-------------------------------+
| SEG.WND | segment window |
+----------+-------------------------------+
| SEG.UP | segment urgent pointer |
+----------+-------------------------------+
Table 4: Current Segment Variables
表4：現在のセグメント変数
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:
接続は、一生の間に一連の状態を経て進みます。州は次のとおりです。リッスン、シンセント、シンレイブ、確立された、Fin-Wait-1、Fin-Wait-2、Close-Wait、閉鎖、Last-ack、Time-Wait、および架空の状態は閉鎖されています。閉鎖は架空のものであり、TCBがない場合、したがって接続がない状態を表すためです。簡単に言えば、州の意味は次のとおりです。
LISTEN - represents waiting for a connection request from any remote TCP peer and port.
聞く - リモート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.
確立される - オープン接続を表し、受信したデータはユーザーに配信できます。接続のデータ転送フェーズの通常の状態。
FIN-WAIT-1 - represents waiting for a connection termination request from the remote TCP peer, 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 peer.
FIN-WAIT-2-リモートTCPピアからの接続終了要求を待つことを表します。
CLOSE-WAIT - represents waiting for a connection termination request from the local user.
Close -Wait -Localユーザーからの接続終了要求を待つことを表します。
CLOSING - represents waiting for a connection termination request acknowledgment from the remote TCP peer.
終了 - リモートTCPピアからの接続終了要求の確認を待つことを表します。
LAST-ACK - represents waiting for an acknowledgment of the connection termination request previously sent to the remote TCP peer (this termination request sent to the remote TCP peer already included an acknowledgment of the termination request sent from the remote TCP peer).
last -ack-リモートTCPピアに以前に送信された接続終了要求の確認を待つことを表します（リモートTCPピアに送信されたこの終了要求には、リモートTCPピアから送信された終了要求の確認が既に含まれています）。
TIME-WAIT - represents waiting for enough time to pass to be sure the remote TCP peer received the acknowledgment of its connection termination request and to avoid new connections being impacted by delayed segments from previous connections.
タイムウェイト - リモートTCPピアが接続終了要求の承認を受け取ったことを確認し、以前の接続からの遅延セグメントによって新しい接続が影響を受けることを避けるために、通過するのに十分な時間を待つことを表します。
CLOSED - represents no connection state at all.
クローズド - 接続状態はまったくありません。
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接続は、イベントに応じて、ある状態から別の状態に進みます。イベントは、ユーザーコール、オープン、送信、受信、閉鎖、中止、およびステータスです。着信セグメント、特にSyn、ACK、RST、およびFINフラグを含むセグメント。とタイムアウト。
The OPEN call specifies whether connection establishment is to be actively pursued, or to be passively waited for.
オープンコールは、接続確立が積極的に追求されるか、受動的に待機されるかどうかを指定します。
A passive OPEN request means that the process wants to accept incoming connection requests, in contrast to an active OPEN attempting to initiate a connection.
パッシブオープンリクエストとは、接続を開始しようとするアクティブなオープンが対照的に、プロセスが着信接続要求を受け入れたいことを意味します。
The state diagram in Figure 5 illustrates only state changes, together with the causing events and resulting actions, but addresses neither error conditions nor actions that are not connected with state changes. In a later section, more detail is offered with respect to the reaction of the TCP implementation to events. Some state names are abbreviated or hyphenated differently in the diagram from how they appear elsewhere in the document.
図5の状態図は、原因となるイベントや結果のアクションとともに、状態の変化のみを示していますが、状態の変更に関連していないエラー条件もアクションにも対応していません。後のセクションでは、イベントに対するTCP実装の反応に関する詳細については、詳細を提供します。一部の状態名は、ドキュメント内の他の場所にどのように表示されるかを図で略したり、ハイフネーションを省略したりします。
NOTA BENE: This diagram is only a summary and must not be taken as the total specification. Many details are not included.
Nota Bene：この図は概要にすぎず、合計仕様として取得してはなりません。多くの詳細は含まれていません。
+---------+ ---------\ active OPEN
| CLOSED | \ -----------
+---------+<---------\ \ create TCB
| ^ \ \ snd SYN
passive OPEN | | CLOSE \ \
------------ | | ---------- \ \
create TCB | | delete TCB \ \
V | \ \
rcv RST (note 1) +---------+ CLOSE | \
-------------------->| LISTEN | ---------- | |
/ +---------+ delete TCB | |
/ rcv SYN | | SEND | |
/ ----------- | | ------- | V
+--------+ snd SYN,ACK / \ snd SYN +--------+
| |<----------------- ------------------>| |
| SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT |
| | snd SYN,ACK | |
| |------------------ -------------------| |
+--------+ rcv ACK of SYN \ / rcv SYN,ACK +--------+
| -------------- | | -----------
| x | | snd ACK
| V V
| CLOSE +---------+
| ------- | ESTAB |
| snd FIN +---------+
| CLOSE | | rcv FIN
V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+
| FIN |<---------------- ------------------>| CLOSE |
| WAIT-1 |------------------ | WAIT |
+---------+ rcv FIN \ +---------+
| rcv ACK of FIN ------- | CLOSE |
| -------------- snd ACK | ------- |
V x V snd FIN V
+---------+ +---------+ +---------+
|FINWAIT-2| | CLOSING | | LAST-ACK|
+---------+ +---------+ +---------+
| rcv ACK of FIN | rcv ACK of FIN |
| rcv FIN -------------- | Timeout=2MSL -------------- |
| ------- x V ------------ x V
\ snd ACK +---------+delete TCB +---------+
-------------------->|TIME-WAIT|------------------->| CLOSED |
+---------+ +---------+
Figure 5: TCP Connection State Diagram
図5：TCP接続状態図
The following notes apply to Figure 5:
次のメモが図5に適用されます。
Note 1: The transition from SYN-RECEIVED to LISTEN on receiving a RST is conditional on having reached SYN-RECEIVED after a passive OPEN.
注1：RSTを受信することでリッスンをするために同期からの移行は、受動的なオープンの後にシンが受信したことを条件としています。
Note 2: The figure omits a transition from FIN-WAIT-1 to TIME-WAIT if a FIN is received and the local FIN is also acknowledged.
注2：図は、FINが受信され、ローカルフィンも認められている場合、FIN-WAIT-1からTime-Waitへの移行を省略します。
Note 3: A RST can be sent from any state with a corresponding transition to TIME-WAIT (see [70] for rationale). These transitions are not explicitly shown; otherwise, the diagram would become very difficult to read. Similarly, receipt of a RST from any state results in a transition to LISTEN or CLOSED, though this is also omitted from the diagram for legibility.
注3：RSTは、対応するタイムウェイトへの移行を伴ういずれかの状態から送信できます（[70]を参照してください。これらの遷移は明示的に示されていません。そうしないと、図を読みにくくなります。同様に、州からのRSTの受領により、聴取または閉鎖される移行が行われますが、これは読みやすさのために図からも省略されています。
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 straightforward duplicate detection in the presence of retransmission. The numbering scheme of octets within a segment is as follows: the first data octet immediately following the header is the lowest numbered, and the following octets are numbered consecutively.
設計の基本的な概念は、TCP接続を介して送信されるデータのすべてのオクテットにはシーケンス番号があるということです。すべてのオクテットがシーケンスされるため、それぞれが認められる可能性があります。採用されている承認メカニズムは累積的であるため、シーケンス番号xの認識は、すべてのオクテットがxを受け取ったが含まれていないことを示します。このメカニズムにより、再送信の存在下で簡単に重複する検出が可能になります。セグメント内のオクテットの番号付けスキームは次のとおりです。ヘッダーの直後の最初のデータオクテットは最も低い番号で、次のオクテットに連続して番号が付けられています。
It is essential to remember that the actual sequence number space is finite, though 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-1から0に再びサイクリングする際のシーケンス数の関係が保持されます。コンピューターモジュロの算術にはいくつかの微妙さがあるため、そのような値の比較をプログラミングする際には細心の注意を払う必要があります。シンボル「= <」は、「等しくない」を意味します（モジュロ2^32）。
The typical kinds of sequence number comparisons that the TCP implementation 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 that are expected (i.e., that the segment "overlaps" the receive window).
(c) 着信セグメントには、予想されるシーケンス番号が含まれていると判断します（つまり、セグメントが受信ウィンドウを「重複」します）。
In response to sending data, the TCP endpoint will receive acknowledgments. The following comparisons are needed to process the acknowledgments:
データの送信に応じて、TCPエンドポイントは謝辞を受け取ります。謝辞を処理するには、次の比較が必要です。
SND.UNA = oldest unacknowledged sequence number
snd.una =最も古い非概要シーケンス番号
SND.NXT = next sequence number to be sent
snd.nxt =送信される次のシーケンス番号
SEG.ACK = acknowledgment from the receiving TCP peer (next sequence number expected by the receiving TCP peer)
seg.ack =受信TCPピアからの謝辞（受信TCPピアが期待する次のシーケンス番号）
SEG.SEQ = first sequence number of a segment
seg.seq =セグメントの最初のシーケンス番号
SEG.LEN = the number of octets occupied by the data in the segment (counting SYN and FIN)
seg.len =セグメント内のデータが占めるオクテットの数（synとfinをカウント）
SEG.SEQ+SEG.LEN-1 = last sequence number of a segment
seg.seq seg.len-1 =セグメントの最後のシーケンス番号
A new acknowledgment (called an "acceptable ack") is one for which the inequality below holds:
新しい謝辞（「許容可能な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 than or equal to 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 segment, and is the left or lower edge of the receive window
rcv.nxt =着信セグメントで期待される次のシーケンス番号、および受信ウィンドウの左または下端です
RCV.NXT+RCV.WND-1 = last sequence number expected on an incoming segment, and is the right or upper edge of the receive window
RCV.NXT RCV.WND-1 =着信セグメントで予想される最後のシーケンス番号、および受信ウィンドウの右端または上端です
SEG.SEQ = first sequence number occupied by the incoming segment
seg.seq =着信セグメントが占める最初のシーケンス番号
SEG.SEQ+SEG.LEN-1 = last sequence number occupied by the incoming segment
seg.seq seg.len-1 =着信セグメントが占める最後のシーケンス番号
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.
このテストの最初の部分は、セグメントの開始がウィンドウに落ちるかどうかを確認するためにチェックします。テストの2番目の部分は、セグメントの終わりが窓に落ちるかどうかを確認します。セグメントがテストのいずれかの一部を渡すと、ウィンドウにデータが含まれています。
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:
実際、それはこれよりも少し複雑です。ウィンドウとゼロの長さのセグメントがゼロのため、着信セグメントを許容するための4つのケースがあります。
+=========+=========+======================================+
| 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 |
+---------+---------+--------------------------------------+
Table 5: Segment Acceptability Tests
表5：セグメント許容性テスト
Note that when the receive window is zero no segments should be acceptable except ACK segments. Thus, it is possible for a TCP implementation to maintain a zero receive window while transmitting data and receiving ACKs. A TCP receiver MUST process the RST and URG fields of all incoming segments, even when the receive window is zero (MUST-66).
受信ウィンドウがゼロの場合、ACKセグメント以外のセグメントは受け入れられないことに注意してください。したがって、データの送信とACKの受信中に、TCP実装がゼロ受信ウィンドウを維持することが可能です。TCPレシーバーは、受信ウィンドウがゼロであっても、すべての着信セグメントの最初と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.
特定の制御情報も保護するために、番号付けスキームを利用しました。これは、シーケンス空間にいくつかのコントロールフラグを暗黙的に含めることで達成され、混乱なしに再送信および認めることができます（つまり、コントロールの1つのコピーのみが実行されます）。制御情報は、セグメントデータスペースに物理的に運ばれません。その結果、制御するためにシーケンス番号を暗黙的に割り当てるためのルールを採用する必要があります。SynとFinは、この保護を必要とする唯一のコントロールであり、これらのコントロールは接続の開閉でのみ使用されます。シーケンス番号の目的では、Synは発生するセグメントの最初の実際のデータオクテットの前に発生すると見なされますが、FINは、発生するセグメントの最後の実際のデータOctetの後に発生すると見なされます。セグメントの長さ（SEG.LEN）には、データとシーケンスの両方のスペース占有コントロールが含まれます。synが存在する場合、seg.seqはsynのシーケンス番号です。
A connection is defined by a pair of sockets. Connections can be reused. 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 implementation 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. To support this, the TIME-WAIT state limits the rate of connection reuse, while the initial sequence number selection described below further protects against ambiguity about which incarnation of a connection an incoming packet corresponds to.
接続は、ソケットのペアによって定義されます。接続を再利用できます。接続の新しいインスタンスは、接続の化身と呼ばれます。これから生じる問題は、「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 endpoint loses all knowledge of the sequence numbers it has been using. When new connections are created, an initial sequence number (ISN) generator is employed that selects a new 32-bit ISN. There are security issues that result if an off-path attacker is able to predict or guess ISN values [42].
混乱を避けるために、接続の1つの化身からのセグメントが使用されるのを防ぐ必要がありますが、同じシーケンス番号がまだネットワークに以前の化身から存在する可能性があります。TCPエンドポイントが使用しているシーケンス番号のすべての知識を失ったとしても、これを保証したいと思います。新しい接続が作成されると、新しい32ビットISNを選択する初期シーケンス番号（ISN）ジェネレーターが使用されます。オフパス攻撃者がISN値を予測または推測できる場合に生じるセキュリティの問題があります[42]。
TCP initial sequence numbers are generated from a number sequence that monotonically increases until it wraps, known loosely as a "clock". This clock is a 32-bit counter that typically increments at least once every roughly 4 microseconds, although it is neither assumed to be realtime nor precise, and need not persist across reboots. The clock component is intended to ensure that with a Maximum Segment Lifetime (MSL), generated ISNs will be unique since it cycles approximately every 4.55 hours, which is much longer than the MSL. Please note that for modern networks that support high data rates where the connection might start and quickly advance sequence numbers to overlap within the MSL, it is recommended to implement the Timestamp Option as mentioned later in Section 3.4.3.
TCP初期シーケンス番号は、「クロック」としてゆるく知られているラップするまで単調に増加する数値シーケンスから生成されます。このクロックは32ビットカウンターで、通常は約4マイクロ秒ごとに少なくとも1回は増加しますが、リアルタイムでも正確でもないと想定されておらず、再起動全体で持続する必要はありません。クロックコンポーネントは、最大セグメント寿命（MSL）で生成されたISNSが約4.55時間ごとにサイクルするため、MSLよりもはるかに長いことを確認することを目的としています。接続が開始され、MSL内でオーバーラップするためにシーケンス番号を迅速に進める可能性のある高いデータレートをサポートする最新のネットワークの場合、セクション3.4.3で後述するように、タイムスタンプオプションを実装することをお勧めします。
A TCP implementation MUST use the above type of "clock" for clock-driven selection of initial sequence numbers (MUST-8), and SHOULD generate its initial sequence numbers with the expression:
TCPの実装は、初期シーケンス番号（必見）のクロック駆動型の選択には上記のタイプの「クロック」を使用する必要があり、式で初期シーケンス番号を生成する必要があります。
ISN = M + F(localip, localport, remoteip, remoteport, secretkey)
where M is the 4 microsecond timer, and F() is a pseudorandom function (PRF) of the connection's identifying parameters ("localip, localport, remoteip, remoteport") and a secret key ("secretkey") (SHLD-1). F() MUST NOT be computable from the outside (MUST-9), or an attacker could still guess at sequence numbers from the ISN used for some other connection. The PRF could be implemented as a cryptographic hash of the concatenation of the TCP connection parameters and some secret data. For discussion of the selection of a specific hash algorithm and management of the secret key data, please see Section 3 of [42].
ここで、Mは4マイクロ秒タイマーであり、F（）は接続の識別パラメーター（「LocalIP、LocalPort、RemoteIP、Remoteport」）の擬似ランダム関数（PRF）とシークレットキー（「SecretKey」）（SHLD-1）です。f（）は、外部から計算可能であってはなりません（必見）、または攻撃者が他の接続に使用されるISNからのシーケンス番号を推測することもできます。PRFは、TCP接続パラメーターといくつかの秘密データの連結の暗号化ハッシュとして実装できます。特定のハッシュアルゴリズムの選択とシークレットキーデータの管理の議論については、[42]のセクション3を参照してください。
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 peer, and the initial receive sequence number (IRS) is learned during the connection-establishing procedure.
各接続には、送信シーケンス番号と受信シーケンス番号があります。初期送信シーケンス番号（ISS）は、TCPピアを送信するデータによって選択され、接続確立手順中に初期受信シーケンス番号（IRS）が学習されます。
For a connection to be established or initialized, the two TCP peers 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 ISNs.
接続を確立または初期化するには、2つのTCPピアが互いの初期シーケンス番号で同期する必要があります。これは、「syn」（同期用）と初期シーケンス番号と呼ばれるコントロールビットを運ぶ接続確立セグメントの交換で行われます。速記として、synビットを運ぶセグメントは「syn」とも呼ばれます。したがって、このソリューションには、初期シーケンス番号を選択するための適切なメカニズムと、ISNを交換するためのわずかに関与する握手が必要です。
The synchronization requires each side to send its own initial sequence number and to receive a confirmation of it in acknowledgment from the remote TCP peer. Each side must also receive the remote peer's initial sequence number and send a confirming acknowledgment.
同期では、各側が独自の初期シーケンス番号を送信し、リモートTCPピアから確認してその確認を受信する必要があります。また、各側は、リモートピアの初期シーケンス番号を受け取り、確認する謝辞を送信する必要があります。
1) A --> B SYN my sequence number is X
2) A <-- B ACK your sequence number is X
3) A <-- B SYN my sequence number is Y
4) A --> B ACK your sequence number is Y
Because steps 2 and 3 can be combined in a single message this is called the three-way (or three message) handshake (3WHS).
ステップ2と3を単一のメッセージで組み合わせることができるため、これは3方向（または3つのメッセージ）ハンドシェイク（3WH）と呼ばれます。
A 3WHS is necessary because sequence numbers are not tied to a global clock in the network, and TCP implementations may have different mechanisms for picking the ISNs. The receiver of the first SYN has no way of knowing whether the segment was an old 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 for ISN selection are discussed in [69].
シーケンス番号はネットワーク内のグローバルクロックに結び付けられていないため、3whsが必要であり、TCP実装にはISNを選択するためのメカニズムが異なる場合があります。最初のsynの受信機は、接続で使用された最後のシーケンス番号を覚えていない限り（常に可能ではない）、セグメントが古いものであるかどうかを知る方法がありません。syn。3方向の握手とISN選択の時計駆動型スキームの利点については、[69]で説明しています。
A theoretical problem exists where data could be corrupted due to confusion between old segments in the network and new ones after a host reboots if the same port numbers and sequence space are reused. The "quiet time" concept discussed below addresses this, and the discussion of it is included for situations where it might be relevant, although it is not felt to be necessary in most current implementations. The problem was more relevant earlier in the history of TCP. In practical use on the Internet today, the error-prone conditions are sufficiently unlikely that it is safe to ignore. Reasons why it is now negligible include: (a) ISS and ephemeral port randomization have reduced likelihood of reuse of port numbers and sequence numbers after reboots, (b) the effective MSL of the Internet has declined as links have become faster, and (c) reboots often taking longer than an MSL anyways.
同じポート番号とシーケンススペースが再利用された場合、ホストの再起動後、ネットワーク内の古いセグメントと新しいセグメント間の混乱のためにデータを破損できる理論的問題が存在します。以下で説明する「静かな時間」の概念はこれに対処しており、それの議論は関連性がある状況に含まれていますが、現在のほとんどの実装では必要であるとは感じられません。この問題は、TCPの歴史の初期により関連性がありました。今日のインターネットでの実際の使用では、エラーが発生しやすい条件は、無視することが安全である可能性が十分に低いと十分にありません。現在無視できる理由は次のとおりです。（a）ISSおよびはかないポートのランダム化により、再起動後にポート番号とシーケンス番号の再利用の可能性が低下し、（b）リンクが高速になるにつれてインターネットの有効なMSLが減少しました。）とにかくMSLよりも時間がかかることがよくあります。
To be sure that a TCP implementation does not create a segment carrying a sequence number that may be duplicated by an old segment remaining in the network, the TCP endpoint must keep quiet for an MSL before assigning any sequence numbers upon starting up or recovering from a situation where 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 endpoint 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は2分間になります。これはエンジニアリングの選択であり、経験がそうすることが望ましいことを示している場合、変更される場合があります。TCPエンドポイントが何らかの意味で再活性化されているが、使用中のシーケンス数のメモリを保持している場合、まったく待つ必要はないことに注意してください。最近使用されたものよりも大きいシーケンス番号のみを使用する必要があります。
Hosts that for any reason lose 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 MSL in the internet system that the host is a part of. In the paragraphs below, an explanation for this specification is given. TCP implementers 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 data by some receivers in the internet system.
何らかの理由で、各アクティブ（つまり、閉じていない）接続で送信された最後のシーケンス番号の知識が失われることは、ホストが一部であるインターネットシステムで少なくとも合意されたMSLのTCPセグメントを放射することを遅らせることです。以下の段落では、この仕様の説明が記載されています。TCP実装者は、「静かな時間」の制限に違反する可能性がありますが、インターネットシステムの一部の受信機によって古いまたは新しいデータが拒否された新しいデータまたは新しいデータが拒否されたために、いくつかの古いデータを受け入れるリスクがある場合のみです。
TCP endpoints 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 TCP 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 and SYN or FIN flags in the segment.
TCPエンドポイントは、セグメントが形成され、ソースホストのネットワーク出力キューに入力されるたびにシーケンス番号スペースを消費します。TCPの重複検出およびシーケンスアルゴリズムは、セグメントデータの一意のバインディングに依存して、シーケンス番号がそれらのシーケンス番号にバインドされたセグメントデータが配信され、認識される前に、シーケンス番号がすべて2^32値を循環しない程度まで、シーケンス空間に依存しています。受信者とセグメントのすべての複製コピーは、インターネットから「排出」されています。このような仮定がなければ、2つの異なるTCPセグメントに同じまたは重複したシーケンス番号を割り当てることができ、どのデータが新しく、どのデータが古いかについての受信機で混乱を引き起こす可能性があります。各セグメントは、セグメントにデータとSYNまたはFINフラグのオクテットがあるのと同じくらい多くの連続したシーケンス番号にバインドされていることを忘れないでください。
Under normal conditions, TCP implementations keep track of the next sequence number to emit and the oldest awaiting acknowledgment so as to avoid mistakenly reusing a sequence number 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 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 10s of megabits/sec. At 100 megabits/sec., the cycle time is 5.4 minutes, which may be a little short but still within reason. Much higher data rates are possible today, with implications described in the final paragraph of this subsection.
通常の条件下では、TCPの実装は、最初の使用が認められる前にシーケンス番号を誤って再利用することを避けるために、エミットする次のシーケンス番号と最も古い待望の承認を追跡します。これだけでは、古い複製データがネットから排出されることを保証するものではないため、放浪の複製が到着時にトラブルを引き起こす可能性を減らすために、シーケンススペースが大きくなりました。2メガビット/秒で、シーケンススペースの2^32オクテットを使用するのに4.5時間かかります。ネットの最大セグメント寿命は数十秒を超える可能性は低いため、データレートが10秒のメガビット/秒にエスカレートする場合でも、これは予見可能なネットの十分な保護と見なされます。100メガビット/秒では、サイクルタイムは5.4分ですが、これは少し短いかもしれませんが、それでも合理的です。今日、はるかに高いデータレートが可能であり、このサブセクションの最終段落に記載されている影響があります。
The basic duplicate detection and sequencing algorithm in TCP can be defeated, however, if a source TCP endpoint does not have any memory of the sequence numbers it last used on a given connection. For example, if the TCP implementation were to start all connections with sequence number 0, then upon the host rebooting, a TCP peer 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実装がシーケンス番号0ですべての接続を開始する場合、ホストの再起動時に、TCPピアは以前の接続（おそらく半分のオープン接続解像度の後）を再編成し、同一のシーケンス番号を持つパケットを発します。または、ネットワーク内のパケットと重複するもので、同じ接続の以前の化身で放出されました。特定の接続で使用されたシーケンス番号に関する知識がない場合、TCP仕様は、以前の接続の化身からのセグメントがシステムから排出される時間を確保するために、接続のセグメントを放出する前にMSL秒のソース遅延を推奨しています。
Even hosts that can remember the time of day and use 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).
時刻を覚えていて、それを使用して初期シーケンス番号値を選択できるホストでさえ、この問題から免疫がありません（つまり、たとえ1日時間を使用して、新しい接続の各化身の初期シーケンス番号を選択しても）。
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 endpoint on a particular connection. Now suppose, at this instant, the host reboots 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.
たとえば、シーケンス番号Sで接続が開かれているとします。この接続があまり使用されておらず、最終的に初期シーケンス数関数（ISN（T））がシーケンス番号に等しい値を取るとします。、特定の接続でこのTCPエンドポイントによって送信された最後のセグメントの。この瞬間に、ホストが接続の新しい化身を再起動して確立するとします。選択された初期シーケンス番号はS1 = ISN（T）です。これは、古い接続の化身で最後に使用されたシーケンス番号です！回復が十分に迅速に発生した場合、S1の近傍のネットベアリングシーケンス数の古い複製は到着し、接続の新しい化身の受信者によって新しいパケットとして扱われる可能性があります。
The problem is that the recovering host may not know for how long it was down between rebooting 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 reboot -- this is the "quiet time" specification. Hosts that prefer to avoid waiting and are willing to risk possible confusion of old and new packets at a given destination may choose not to wait for the "quiet time". Implementers may provide TCP users with the ability to select on a connection-by-connection basis whether to wait after a reboot, or may informally implement the "quiet 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.
この問題に対処する1つの方法は、再起動から回復した後、1つのMSLのセグメントを意図的に放射することを遅らせることです。これは「静かな時間」の仕様です。待機を避け、特定の目的地での古いパケットや新しいパケットの混乱の可能性を冒すことをいとわないホストは、「静かな時間」を待たないことを選択する場合があります。実装者は、TCPユーザーに、再起動後の待機、またはすべての接続の「静かな時間」を非公式に実装するかどうかを接続ごとに選択する機能を提供する場合があります。明らかに、ユーザーが「待機」を選択する場合でも、ホストが少なくともMSL秒間「アップ」された後にこれは必要ありません。
To summarize: every segment emitted occupies one or more sequence numbers in the sequence space, and the numbers occupied by a segment are "busy" or "in use" until MSL seconds have passed. Upon rebooting, a block of space-time is occupied by the octets and SYN or FIN flags of any potentially still in-flight segments. If a new connection is started too soon and uses any of the sequence numbers in the space-time footprint of those potentially still in-flight segments of the previous connection incarnation, there is a potential sequence number overlap area that could cause confusion at the receiver.
要約すると、放出されたすべてのセグメントは、シーケンス空間内の1つ以上のシーケンス番号を占有し、セグメントで占める数値はMSL秒が経過するまで「ビジー」または「使用中」です。再起動すると、時空のブロックは、潜在的にまだ飛行中のセグメントのオクテットとシンまたはフィンフラグによって占められています。新しい接続が早く開始されすぎて、以前の接続の化身の潜在的にまだ飛行中のセグメントの時空フットプリントのシーケンス番号のいずれかを使用する場合、受信者に混乱を引き起こす可能性のある潜在的なシーケンス数のオーバーラップ領域があります。
High-performance cases will have shorter cycle times than those in the megabits per second that the base TCP design described above considers. At 1 Gbps, the cycle time is 34 seconds, only 3 seconds at 10 Gbps, and around a third of a second at 100 Gbps. In these higher-performance cases, TCP Timestamp Options and Protection Against Wrapped Sequences (PAWS) [47] provide the needed capability to detect and discard old duplicates.
高性能のケースは、上記のベースTCP設計が考慮しているベースTCP設計が1秒あたりのメガビットのケースよりも短縮されます。1 gbpsでは、サイクル時間は34秒、10 gbpsで3秒、100 gbpsで約3分の1です。これらの高性能の場合、TCPタイムスタンプオプションとラップシーケンス（PAWS）に対する保護[47]は、古い重複を検出および廃棄するために必要な機能を提供します。
The "three-way handshake" is the procedure used to establish a connection. This procedure normally is initiated by one TCP peer and responded to by another TCP peer. The procedure also works if two TCP peers simultaneously initiate the procedure. When simultaneous open occurs, each TCP peer receives a SYN segment that 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.
「3方向の握手」は、接続を確立するために使用される手順です。この手順は通常、1つのTCPピアによって開始され、別のTCPピアによって対応されます。2つの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 endpoint doesn't deliver the data to the user until it is clear the data is valid (e.g., the data is buffered at the receiver until the connection reaches the ESTABLISHED state, given that the three-way handshake reduces the possibility of false connections). It is a trade-off between memory and messages to provide information for this checking.
接続開始のいくつかの例が続きます。これらの例では、データキャリーセグメントを使用した接続の同期は表示されませんが、受信TCPエンドポイントがデータが有効になるまでユーザーにデータを配信しない限り、これは完全に正当です。3方向の握手が誤った接続の可能性を減らすことを考えると、接続が確立された状態に到達するまで受信機で）。これは、このチェックの情報を提供するためのメモリとメッセージのトレードオフです。
The simplest 3WHS is shown in Figure 6. 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 Peer A to TCP Peer B or arrival of a segment at B from A. Left arrows (<--) indicate the reverse. Ellipses (...) indicate a segment that is still in the network (delayed). Comments appear in parentheses. TCP connection 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.
最も単純な3WHを図6に示します。図は、次の方法で解釈する必要があります。各行には参照目的で番号が付けられています。右矢印（ - >）は、TCPピアAからTCPピアBへのTCPセグメントの出発を示します。楕円（...）は、まだネットワーク内にあるセグメントを示します（遅延）。括弧内にコメントが表示されます。TCP接続状態は、セグメントの出発または到着後の状態を表します（各ラインの中央に内容が表示されます）。セグメントの内容は、シーケンス番号、制御フラグ、およびACKフィールドを備えた略式形式で示されています。ウィンドウ、アドレス、長さ、テキストなどの他のフィールドは、明確にするために除外されています。
TCP Peer A TCP Peer B
TCPピアA TCPピアb
1. CLOSED LISTEN
1. 閉じた聞き取り
2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED
2. syn-sent-> <seq = 100> <ctl = syn> - > syn-received
3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
3. 確立< - <seq = 300> <ack = 101> <ctl = syn、ack> <- syn-received
4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
4. 確立 - > <seq = 101> <ack = 301> <ctl = ack> - >確立
5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
5. 確立 - > <seq = 101> <ack = 301> <ctl = ack> <data> - >確立
Figure 6: Basic Three-Way Handshake for Connection Synchronization
図6：接続の同期のための基本的な3方向握手
In line 2 of Figure 6, TCP Peer A begins by sending a SYN segment indicating that it will use sequence numbers starting with sequence number 100. In line 3, TCP Peer B sends a SYN and acknowledges the SYN it received from TCP Peer A. Note that the acknowledgment field indicates TCP Peer B is now expecting to hear sequence 101, acknowledging the SYN that occupied sequence 100.
図6の行2では、TCPピアAは、シーケンス番号100から始まるシーケンス番号を使用することを示すSynセグメントを送信することから始まります。3行目では、TCP Peer BはSynを送信し、TCP Peer Aから受け取ったSynを認めます。確認フィールドは、TCPピアBがシーケンス101を聞くことを期待していることを示しており、シーケンスを占有したSynを認めていることを示しています。
At line 4, TCP Peer A responds with an empty segment containing an ACK for TCP Peer B's SYN; and in line 5, TCP Peer 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 ACKs!).
4行目では、TCPピアBのSynのACKを含む空のセグメントでTCP PEER Aが応答します。5行目では、TCP Peer Aがデータを送信します。ACKがシーケンス番号スペースを占有していないため、5行目のセグメントのシーケンス番号は4行目と同じであることに注意してください（もしそうなら、Acking Ackを巻き上げます！）。
Simultaneous initiation is only slightly more complex, as is shown in Figure 7. Each TCP peer's connection state cycles from CLOSED to SYN-SENT to SYN-RECEIVED to ESTABLISHED.
図7に示すように、同時開始はわずかに複雑です。各TCPピアの接続状態状態は、閉じてからシンセントまで、確立されたシンセントまでの状態です。
TCP Peer A TCP Peer B
TCPピアA TCPピアb
1. CLOSED CLOSED
1. 閉じた閉じた
2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
2. syn-sent-> <seq = 100> <ctl = syn> ...
3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT
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> ...
5. syn-received-> <seq = 100> <ack = 301> <ctl = syn、ack> ...
6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
6. 確立< - <seq = 300> <ack = 101> <ctl = syn、ack> <- syn-received
7. ... <SEQ=100><ACK=301><CTL=SYN,ACK> --> ESTABLISHED
Figure 7: Simultaneous Connection Synchronization
図7：同時接続の同期
A TCP implementation MUST support simultaneous open attempts (MUST-10).
TCP実装は、同時オープン試行（必須）をサポートする必要があります。
Note that a TCP implementation MUST keep track of whether a connection has reached SYN-RECEIVED state as the result of a passive OPEN or an active OPEN (MUST-11).
TCPの実装は、パッシブオープンまたはアクティブオープンの結果として、接続がシンレシーブ状態に到達したかどうかを追跡する必要があることに注意してください（必須です）。
The principal 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, is specified. If the receiving TCP peer is in a non-synchronized state (i.e., SYN-SENT, SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset. If the TCP peer 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.
3方向の握手の主な理由は、古い複製接続の開始が混乱を引き起こすのを防ぐことです。これに対処するために、特別なコントロールメッセージであるリセットが指定されています。受信TCPピアが非同期状態（つまり、syn-sent、syn-received）にある場合、許容可能なリセットの受信でリッスンに戻ります。TCPピアが同期された状態の1つ（確立された、Fin-Wait-1、Fin-Wait-2、Close-Wait、閉鎖、Last-ack、Time-Wait）にある場合、接続を中止し、ユーザーに通知します。この後者のケースについては、以下の「半分のオープン」接続の下で説明します。
TCP Peer A TCP Peer B
TCPピアA TCPピアb
1. CLOSED LISTEN
1. 閉じた聞き取り
2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
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
4. syn-sent < - <seq = 300> <ack = 91> <ctl = syn、ack> <- syn-received
5. SYN-SENT --> <SEQ=91><CTL=RST> --> LISTEN
5. syn-sent-> <seq = 91> <ctl = rst> - >聞く
6. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
7. ESTABLISHED <-- <SEQ=400><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
7. 確立< - <seq = 400> <ack = 101> <ctl = syn、ack> <- syn-received
8. ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK> --> ESTABLISHED
8. 確立 - > <seq = 101> <ack = 401> <ctl = ack> - >確立
Figure 8: Recovery from Old Duplicate SYN
図8：古い重複synからの回復
As a simple example of recovery from old duplicates, consider Figure 8. At line 3, an old duplicate SYN arrives at TCP Peer B. TCP Peer B cannot tell that this is an old duplicate, so it responds normally (line 4). TCP Peer A detects that the ACK field is incorrect and returns a RST (reset) with its SEQ field selected to make the segment believable. TCP Peer B, on receiving the RST, returns to the LISTEN state. When the original SYN 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 RSTs sent in both directions.
古い重複からの回復の簡単な例として、図8を考慮してください。3行目では、TCPピアBに古い重複synが到着します。TCPピアBは、これが古い複製であることを知ることができないため、正常に応答します（4行目）。TCP PEER Aは、ACKフィールドが正しくないことを検出し、セグメントを信頼できるように選択したSEQフィールドでRST（リセット）を返します。TCPピアBは、RSTを受け取ったときに、リスニング状態に戻ります。元のSynが最終的に6行6に到着すると、同期は正常に進行します。6行目のsynが最初に到着した場合、RSTSが両方向に送信された状態で、より複雑な交換が発生した可能性があります。
An established connection is said to be "half-open" if one of the TCP peers 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 failure or reboot 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.
確立された接続は、TCPピアの1つが他方の知識なしに接続を閉じたり中止したりした場合、または接続の両端が失敗または失敗のために非同期化された場合、「ハーフオープン」と言われています。再起動してメモリが失われました。どちらの方向にもデータを送信する試みが行われた場合、このような接続は自動的にリセットされます。ただし、半分のオープン接続は珍しいことが予想されます。
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 endpoint receiving a reset control message. Such a message indicates to the site B TCP endpoint that something is wrong, and it is expected to abort the connection.
サイトAに接続が存在しなくなった場合、サイトBでユーザーがデータを送信しようとすると、サイトB TCPエンドポイントがリセット制御メッセージを受信します。このようなメッセージは、サイトB TCPエンドポイントに何かが間違っていることを示しており、接続を中止することが期待されています。
Assume that two user processes A and B are communicating with one another when a failure or reboot occurs causing loss of memory to A's TCP implementation. Depending on the operating system supporting A's TCP implementation, it is likely that some error recovery mechanism exists. When the TCP endpoint 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 implementation. In an attempt to establish the connection, A's TCP implementation will send a segment containing SYN. This scenario leads to the example shown in Figure 9. After TCP Peer A reboots, the user attempts to reopen the connection. TCP Peer B, in the meantime, thinks the connection is open.
Aと再起動が発生し、AのTCP実装にメモリが失われると、2つのユーザープロセスAとBが互いに通信していると仮定します。AのTCP実装をサポートするオペレーティングシステムに応じて、エラー回復メカニズムが存在する可能性があります。TCPエンドポイントが再び上昇すると、Aは最初からまたは回復ポイントから再び開始する可能性があります。その結果、Aはおそらく再び接続を開き、開いていると思われる接続を送信しようとするでしょう。後者の場合、ローカル（Aの）TCP実装からエラーメッセージ「接続が開いていない」を受信します。接続を確立するために、AのTCP実装はSynを含むセグメントを送信します。このシナリオは、図9に示す例につながります。TCPピアAの再起動の後、ユーザーは接続の再開を試みます。その間、TCPピアBは、接続が開いていると考えています。
TCP Peer A TCP Peer B
TCPピアA TCPピアb
1. (REBOOT) (send 300,receive 100)
1. （再起動）（300を送信、100を受信）
2. CLOSED ESTABLISHED
2. 閉鎖された
3. SYN-SENT --> <SEQ=400><CTL=SYN> --> (??)
3. syn-sent-> <seq = 400> <ctl = syn> - >（??）
4. (!!) <-- <SEQ=300><ACK=100><CTL=ACK> <-- ESTABLISHED
5. SYN-SENT --> <SEQ=100><CTL=RST> --> (Abort!!)
5. syn-sent-> <seq = 100> <ctl = rst> - >（abort !!）
6. SYN-SENT CLOSED
6. syn-sentは閉じた
7. SYN-SENT --> <SEQ=400><CTL=SYN> -->
7. syn-sent-> <seq = 400> <ctl = syn> - >
Figure 9: Half-Open Connection Discovery
図9：ハーフオープン接続の発見
When the SYN arrives at line 3, TCP Peer 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 Peer 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 Peer B aborts at line 5. TCP Peer A will continue to try to establish the connection; the problem is now reduced to the basic three-way handshake of Figure 6.
Synが3行目に到着すると、同期された状態にあるTCPピアB、および窓の外側の入っているセグメントは、次に聞くと予想されるシーケンス（ACK 100）を示す認識で応答します。TCP Peer Aは、このセグメントが送信されたものを認めていないことを確認し、半分のオープン接続が検出されたため、リセット（RST）を送信します。TCPピアBは5行目で中止します。TCPPEERAは引き続き接続を確立しようとします。この問題は、図6の基本的な3方向握手に縮小されました。
An interesting alternative case occurs when TCP Peer A reboots and TCP Peer B tries to send data on what it thinks is a synchronized connection. This is illustrated in Figure 10. In this case, the data arriving at TCP Peer A from TCP Peer B (line 2) is unacceptable because no such connection exists, so TCP Peer A sends a RST. The RST is acceptable so TCP Peer B processes it and aborts the connection.
TCPピアAの再起動とTCPピアBが同期接続と思われるものに関するデータを送信しようとすると、興味深い代替ケースが発生します。これを図10に示します。この場合、TCPピアB（行2）からTCPピアAに到達するデータは、そのような接続が存在しないため容認できないため、TCPピアAはRSTを送信します。RSTは許容されるため、TCPピアBはそれを処理し、接続を中止します。
TCP Peer A TCP Peer B
TCPピアA TCPピアb
1. (REBOOT) (send 300,receive 100)
1. （再起動）（300を送信、100を受信）
2. (??) <-- <SEQ=300><ACK=100><DATA=10><CTL=ACK> <-- ESTABLISHED
3. --> <SEQ=100><CTL=RST> --> (ABORT!!)
Figure 10: Active Side Causes Half-Open Connection Discovery
図10：アクティブサイドは、半分のオープン接続発見を引き起こします
In Figure 11, two TCP Peers A and B with passive connections waiting for SYN are depicted. An old duplicate arriving at TCP Peer 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 Peer B accepts the reset and returns to its passive LISTEN state.
図11では、synを待っているパッシブ接続を備えた2つのTCPピアAとBが描かれています。TCPピアB（2行目）に到着する古い複製がBを動かします。syn-ackが返され（3行目）、TCP AがRSTを生成します（3行目のACKは受け入れられません）。TCPピアBはリセットを受け入れ、受動的なリスニング状態に戻ります。
TCP Peer A TCP Peer B
TCPピアA TCPピアb
1. LISTEN LISTEN
1. 聞いてください
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
5. 聞いてください
Figure 11: Old Duplicate SYN Initiates a Reset on Two Passive Sockets
図11：古い重複synが2つのパッシブソケットでリセットを開始する
A variety of other cases are possible, all of which are accounted for by the following rules for RST generation and processing.
他のさまざまなケースが可能であり、そのすべてがRST生成と処理のための以下のルールによって説明されています。
A TCP user or application can issue a reset on a connection at any time, though reset events are also generated by the protocol itself when various error conditions occur, as described below. The side of a connection issuing a reset should enter the TIME-WAIT state, as this generally helps to reduce the load on busy servers for reasons described in [70].
TCPユーザーまたはアプリケーションは、いつでも接続でリセットを発行できますが、以下で説明するように、さまざまなエラー条件が発生した場合、リセットイベントはプロトコル自体によっても生成されます。リセットを発行する接続の側面は、[70]に記載されている理由で忙しいサーバーの負荷を減らすのに役立つため、タイムウェイト状態を入力する必要があります。
As a general rule, reset (RST) is sent whenever a segment arrives that 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:
州には3つのグループがあります。
1. If the connection does not exist (CLOSED), then a reset is sent in response to any incoming segment except another reset. A SYN segment that does not match an existing connection is rejected by this means.
1. 接続が存在しない場合（閉じた）、別のリセットを除く受信セグメントに応答してリセットが送信されます。既存の接続と一致しないSynセグメントは、この手段によって拒否されます。
If the incoming segment has the ACK bit set, 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フィールドは、着信セグメントのシーケンス番号とセグメント長の合計に設定されます。接続は閉じた状態のままです。
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 (Appendix A.1) that does not exactly match the level and compartment requested for the connection, a reset is sent.
2. 接続が非同期状態にある（聞く、syn-sent、syn-received）、および着信セグメントがまだ送信されていないもの（セグメントには許容できないACKを運ぶ）を認めている場合、または受信セグメントにセキュリティレベルがある場合または接続の要求されたレベルとコンパートメントと正確に一致しないコンパートメント（付録A.1）、リセットが送信されます。
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 unacceptable acknowledgment number) must be responded to with an empty acknowledgment segment (without any user data) 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.
3. 接続が同期された状態（確立された、Fin-Wait-1、Fin-Wait-2、Close-Wait、閉鎖、Last-ack、Time-wait）にある場合、容認できないセグメント（ウィンドウ外シーケンス番号または容認できない謝辞番号）は、現在の送信シーケンス番号を含む空の確認セグメント（ユーザーデータなし）と、受信されると予想される次のシーケンス番号を示す承認を含む応答する必要があり、接続は同じ状態のままです。
If an incoming segment has a security level or compartment that does not exactly match the level and compartment requested for the connection, a reset is sent and the connection goes to the CLOSED state. The reset takes its sequence number from the ACK field of the incoming segment.
着信セグメントに、接続の要求されたレベルとコンパートメントと正確に一致しないセキュリティレベルまたはコンパートメントがある場合、リセットが送信され、接続が閉じた状態になります。リセットは、着信セグメントのACKフィールドからシーケンス番号を取得します。
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）セグメントは、配列フィールドをチェックすることにより検証されます。シーケンス番号がウィンドウにある場合、リセットは有効です。Syn-Sent状態（最初のSynに応じてRECOMEDを受け取った最初の状態）では、ACKフィールドがSynを認めた場合、RSTは許容されます。
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.
最初にReceiverが最初にそれを検証し、次に状態を変更します。受信者がリスニング状態にあった場合、それはそれを無視します。受信者が同期された状態にあり、以前にリスニング状態にあった場合、受信者はリスニング状態に戻ります。それ以外の場合、受信機は接続を中止し、閉じた状態に行きます。受信者が他の状態にあった場合、接続を中止し、ユーザーにアドバイスし、閉じた状態に行きます。
TCP implementations SHOULD allow a received RST segment to include data (SHLD-2). It has been suggested that a RST segment could contain diagnostic data that explains the cause of the RST. No standard has yet been established for such data.
TCP実装では、受信したRSTセグメントがデータ（SHLD-2）を含めることができます。RSTセグメントには、RSTの原因を説明する診断データを含めることができることが示唆されています。このようなデータの標準はまだ確立されていません。
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 the TCP receiver is told that the remote peer 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 remote peer has CLOSED. The TCP implementation will signal a user, even if no RECEIVEs are outstanding, that the remote peer has closed, so the user can terminate their side gracefully. A TCP implementation 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 their data was received at the destination TCP endpoint. Users must keep reading connections they close for sending until the TCP implementation indicates there is no more data.
Closeは、「送信するデータがもうない」という意味の操作です。全二重接続を閉じるという概念は、もちろん、接続の受信側をどのように扱うかは明らかではないかもしれないので、曖昧な解釈の対象となります。シンプルな方法で扱いをすることを選択しました。閉じるユーザーは、TCPレシーバーがリモートピアも閉じていると言われるまで受け取り続けることができます。したがって、プログラムはいくつかの送信を開始し、その後に終了する可能性があり、その後、リモートピアが閉じたために受信が失敗したことを合図するまで受信し続けます。 TCPの実装は、たとえ受信が未解決の場合でも、リモートピアが閉じていることをユーザーに信号します。そのため、ユーザーは自分の側を優雅に終了できます。 TCPの実装は、接続が閉じる前に送信されるすべてのバッファーを確実に配信するため、返品が必要ないと予想されるユーザーは、すべてのデータが宛先TCPエンドポイントで受信されたことを知るために接続が正常に閉鎖されたのを待つだけです。ユーザーは、TCPの実装がデータがないことを示すまで、送信のために接続を読み続ける必要があります。
There are essentially three cases:
基本的に3つのケースがあります。
1) The user initiates by telling the TCP implementation to CLOSE the connection (TCP Peer A in Figure 12).
1) ユーザーは、TCP実装に接続を閉じるように指示することで開始します（図12のTCPピアA）。
2) The remote TCP endpoint initiates by sending a FIN control signal (TCP Peer B in Figure 12).
2) リモートTCPエンドポイントは、フィン制御信号を送信することにより開始されます（図12のTCPピアB）。
3) Both users CLOSE simultaneously (Figure 13).
3) 両方のユーザーは同時に閉じます（図13）。
Case 1: Local user initiates the close
ケース1：ローカルユーザーが終了を開始します
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 implementation, 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 peer has both acknowledged the FIN and sent a FIN of its own, the first TCP peer can ACK this FIN. Note that a TCP endpoint receiving a FIN will ACK but not send its own FIN until its user has CLOSED the connection also.
この場合、FINセグメントを構築して、発信セグメントキューに配置できます。ユーザーからの送信はTCP実装に受け入れられ、Fin-Wait-1状態に入ります。この状態では受信が許可されています。FINの前後のすべてのセグメントは、確認されるまで再送信されます。他のTCPピアがFINを認め、独自のフィンを送信したとき、最初のTCPピアはこのフィンをACKすることができます。FINを受信するTCPエンドポイントは、ユーザーが接続を閉じるまで独自のFINを送信しないことに注意してください。
Case 2: TCP endpoint receives a FIN from the network
ケース2：TCPエンドポイントはネットワークからFINを受け取ります
If an unsolicited FIN arrives from the network, the receiving TCP endpoint can ACK it and tell the user that the connection is closing. The user will respond with a CLOSE, upon which the TCP endpoint can send a FIN to the other TCP peer after sending any remaining data. The TCP endpoint 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.
ネットワークから未承諾のフィンが到着した場合、受信TCPエンドポイントはそれをACKし、接続が閉じていることをユーザーに伝えることができます。ユーザーは、残りのデータを送信した後、TCPエンドポイントが他のTCPピアにFINを送信できます。その後、TCPエンドポイントは、独自のフィンが認められるまで待機し、接続が削除されます。ACKが近づいていない場合、ユーザーのタイムアウト後に接続が中止され、ユーザーが通知されます。
Case 3: Both users close simultaneously
ケース3：両方のユーザーが同時に閉じます
A simultaneous CLOSE by users at both ends of a connection causes FIN segments to be exchanged (Figure 13). When all segments preceding the FINs have been processed and acknowledged, each TCP peer can ACK the FIN it has received. Both will, upon receiving these ACKs, delete the connection.
接続の両端のユーザーが同時に近づくと、フィンセグメントが交換されます（図13）。フィンに先行するすべてのセグメントが処理され、認められている場合、各TCPピアは受信したフィンをACKできます。どちらも、これらのACKを受信すると、接続を削除します。
TCP Peer A TCP Peer B
TCPピアA TCPピアb
1. ESTABLISHED ESTABLISHED
1. 確立された
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
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
5. Time-wait-> <seq = 101> <ack = 301> <ctl = ack> - >閉じている
6. (2 MSL) CLOSED
6. （2 MSL）閉じた
Figure 12: Normal Close Sequence
図12：通常のクローズシーケンス
TCP Peer A TCP Peer B
TCPピアA TCPピアb
1. ESTABLISHED ESTABLISHED
1. 確立された
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> -->
3. 閉鎖 - > <seq = 101> <ack = 301> <ctl = ack> ...閉じる<- <<seq = 301> <ack = 101> <ctl = ack> < - ... <seq =101> <ack = 301> <ctl = ack> - >
4. TIME-WAIT TIME-WAIT (2 MSL) (2 MSL) CLOSED CLOSED
4. Time-Wait Time-Wait（2 MSL）（2 MSL）閉鎖
Figure 13: Simultaneous Close Sequence
図13：同時閉鎖シーケンス
A TCP connection may terminate in two ways: (1) the normal TCP close sequence using a FIN handshake (Figure 12), and (2) an "abort" in which one or more RST segments are sent and the connection state is immediately discarded. If the local TCP connection is closed by the remote side due to a FIN or RST received from the remote side, then the local application MUST be informed whether it closed normally or was aborted (MUST-12).
TCP接続は2つの方法で終了する場合があります。（1）FINハンドシェイクを使用した通常のTCPクローズシーケンス（図12）、および（2）1つ以上のr R r r r r segmentが送信され、接続状態がすぐに廃棄される「中止」。リモート側からのFINまたはRSTが最初に受信されたためにリモート側によってローカルTCP接続が閉じられている場合、ローカルアプリケーションに正常に閉じたか中止されたかどうか（必須）に通知する必要があります。
The normal TCP close sequence delivers buffered data reliably in both directions. Since the two directions of a TCP connection are closed independently, it is possible for a connection to be "half closed", i.e., closed in only one direction, and a host is permitted to continue sending data in the open direction on a half-closed connection.
通常のTCPクローズシーケンスは、バッファーされたデータを両方向に確実に提供します。TCP接続の2つの方向は独立して閉じられているため、接続が「ハーフクローズ」、つまり1つの方向のみが閉じていることが可能です。閉じた接続。
A host MAY implement a "half-duplex" TCP close sequence, so that an application that has called CLOSE cannot continue to read data from the connection (MAY-1). If such a host issues a CLOSE call while received data is still pending in the TCP connection, or if new data is received after CLOSE is called, its TCP implementation SHOULD send a RST to show that data was lost (SHLD-3). See [23], Section 2.17 for discussion.
ホストは「ハーフデュペックス」TCPクローズシーケンスを実装するため、Closeと呼ばれるアプリケーションが接続からデータを読み続けることはできません（5月1日）。このようなホストが、受信したデータがTCP接続でまだ保留中に緊密な呼び出しを発行する場合、または閉鎖後に新しいデータが受信された場合、TCP実装はデータが失われたことを示すためにRSTを送信する必要があります（SHLD-3）。ディスカッションについては、[23]、セクション2.17を参照してください。
When a connection is closed actively, it MUST linger in the TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime) (MUST-13). However, it MAY accept a new SYN from the remote TCP endpoint to reopen the connection directly from TIME-WAIT state (MAY-2), if it:
接続が積極的に閉じられている場合、2xmsl（最大セグメント寿命）（必須-13）の時間、時間待ち状態に残る必要があります。ただし、リモートTCPエンドポイントから新しいsynを受け入れて、Time-Wait状態（5月2日）から接続を直接再開する場合があります。
(1) assigns its initial sequence number for the new connection to be larger than the largest sequence number it used on the previous connection incarnation, and
(1) 新しい接続の初期シーケンス番号を、以前の接続の化身で使用した最大のシーケンス番号よりも大きくなるように割り当て、
(2) returns to TIME-WAIT state if the SYN turns out to be an old duplicate.
(2) Synが古い複製であることが判明した場合、Time-Wait状態に戻ります。
When the TCP Timestamp Options are available, an improved algorithm is described in [40] in order to support higher connection establishment rates. This algorithm for reducing TIME-WAIT is a Best Current Practice that SHOULD be implemented since Timestamp Options are commonly used, and using them to reduce TIME-WAIT provides benefits for busy Internet servers (SHLD-4).
TCPタイムスタンプのオプションが利用可能になると、より高い接続確立率をサポートするために、[40]で改善されたアルゴリズムが説明されています。タイムウェイトを削減するためのこのアルゴリズムは、タイムスタンプのオプションが一般的に使用されているため実装する必要がある最良の現在のプラクティスであり、それらを使用してタイムウェイトを削減することで、忙しいインターネットサーバー（SHLD-4）に利点があります。
The term "segmentation" refers to the activity TCP performs when ingesting a stream of bytes from a sending application and packetizing that stream of bytes into TCP segments. Individual TCP segments often do not correspond one-for-one to individual send (or socket write) calls from the application. Applications may perform writes at the granularity of messages in the upper-layer protocol, but TCP guarantees no correlation between the boundaries of TCP segments sent and received and the boundaries of the read or write buffers of user application data. In some specific protocols, such as Remote Direct Memory Access (RDMA) using Direct Data Placement (DDP) and Marker PDU Aligned Framing (MPA) [34], there are performance optimizations possible when the relation between TCP segments and application data units can be controlled, and MPA includes a specific mechanism for detecting and verifying this relationship between TCP segments and application message data structures, but this is specific to applications like RDMA. In general, multiple goals influence the sizing of TCP segments created by a TCP implementation.
「セグメンテーション」という用語は、送信アプリケーションからバイトのストリームを摂取し、そのバイトのストリームをTCPセグメントにパケット化するときに実行されるアクティビティを指します。個々のTCPセグメントは、アプリケーションからの個々の送信（またはソケット書き込み）コールに1対1に対応しないことがよくあります。アプリケーションは、上層層プロトコルのメッセージの粒度で書き込みを実行する場合がありますが、TCPは、送信および受信したTCPセグメントの境界とユーザーアプリケーションデータの読み取りまたは書き込みバッファーの境界の間に相関関係がないことを保証します。直接データ配置（DDP）およびマーカーPDUアライメントフレーミング（MPA）[34]を使用したリモートダイレクトメモリアクセス（RDMA）などの特定のプロトコルでは、TCPセグメントとアプリケーションデータユニットの関係が可能な場合、パフォーマンスの最適化が可能です。制御された、およびMPAには、TCPセグメントとアプリケーションメッセージデータ構造の間のこの関係を検出および検証するための特定のメカニズムが含まれていますが、これはRDMAなどのアプリケーションに固有です。一般に、複数の目標は、TCP実装によって作成されたTCPセグメントのサイジングに影響します。
Goals driving the sending of larger segments include:
より大きなセグメントの送信を促進する目標は次のとおりです。
* Reducing the number of packets in flight within the network.
* ネットワーク内の飛行中のパケットの数を減らす。
* Increasing processing efficiency and potential performance by enabling a smaller number of interrupts and inter-layer interactions.
* 少数の割り込みと層間相互作用を可能にすることにより、処理効率と潜在的なパフォーマンスを向上させます。
* Limiting the overhead of TCP headers.
* TCPヘッダーのオーバーヘッドを制限します。
Note that the performance benefits of sending larger segments may decrease as the size increases, and there may be boundaries where advantages are reversed. For instance, on some implementation architectures, 1025 bytes within a segment could lead to worse performance than 1024 bytes, due purely to data alignment on copy operations.
大きいセグメントを送信することのパフォーマンスの利点は、サイズが増加するにつれて減少する可能性があり、利点が逆になる境界がある可能性があることに注意してください。たとえば、いくつかの実装アーキテクチャでは、セグメント内の1025バイトは、純粋にコピー操作のデータアラインメントにより、1024バイトよりもパフォーマンスが低下する可能性があります。
Goals driving the sending of smaller segments include:
より小さなセグメントの送信を促進する目標は次のとおりです。
* Avoiding sending a TCP segment that would result in an IP datagram larger than the smallest MTU along an IP network path because this results in either packet loss or packet fragmentation. Making matters worse, some firewalls or middleboxes may drop fragmented packets or ICMP messages related to fragmentation.
* IPネットワークパスに沿って最小のMTUよりも大きいIPデータグラムを作成するTCPセグメントの送信を回避すると、パケットの損失またはパケットの断片化のいずれかが生じるためです。さらに悪いことに、一部のファイアウォールまたはミドルボックスは、断片化されたパケットまたは断片化に関連するICMPメッセージをドロップする可能性があります。
* Preventing delays to the application data stream, especially when TCP is waiting on the application to generate more data, or when the application is waiting on an event or input from its peer in order to generate more data.
* 特にTCPがアプリケーションをより多くのデータを生成するためにアプリケーションを待っている場合、またはより多くのデータを生成するためにピアからのイベントまたは入力をアプリケーションが待っている場合、アプリケーションデータストリームの遅延を防ぐ。
* Enabling "fate sharing" between TCP segments and lower-layer data units (e.g., below IP, for links with cell or frame sizes smaller than the IP MTU).
* TCPセグメントと低層データユニット間の「運命共有」を有効にします（例：IP以下、IP MTUよりも小さいセルまたはフレームサイズのリンクについて）。
Towards meeting these competing sets of goals, TCP includes several mechanisms, including the Maximum Segment Size Option, Path MTU Discovery, the Nagle algorithm, and support for IPv6 Jumbograms, as discussed in the following subsections.
これらの競合する目標のセットを満たすために、TCPには、以下のサブセクションで説明されているように、最大セグメントサイズオプション、パスMTU発見、ナグルアルゴリズム、IPv6ジャンボグラムのサポートなど、いくつかのメカニズムが含まれています。
TCP endpoints MUST implement both sending and receiving the MSS Option (MUST-14).
TCPエンドポイントは、MSSオプションの送信と受信の両方を実装する必要があります（Must-14）。
TCP implementations SHOULD send an MSS Option in every SYN segment when its receive MSS differs from the default 536 for IPv4 or 1220 for IPv6 (SHLD-5), and MAY send it always (MAY-3).
TCPの実装は、受信MSSがIPv4のデフォルト536またはIPv6（SHLD-5）の1220（SHLD-5）のデフォルト536とは異なる場合、すべてのSYNセグメントでMSSオプションを送信する必要があり、常に（5月3日）を送信する場合があります。
If an MSS Option is not received at connection setup, TCP implementations MUST assume a default send MSS of 536 (576 - 40) for IPv4 or 1220 (1280 - 60) for IPv6 (MUST-15).
接続セットアップでMSSオプションが受信されない場合、TCP実装は、IPv4の場合は536（576-40）のデフォルトの送信MSSを想定する必要があります。
The maximum size of a segment that a TCP endpoint really sends, the "effective send MSS", MUST be the smaller (MUST-16) of the send MSS (that reflects the available reassembly buffer size at the remote host, the EMTU_R [19]) and the largest transmission size permitted by the IP layer (EMTU_S [19]):
TCPエンドポイントが実際に送信するセグメントの最大サイズである「効果的な送信MSS」は、送信MSSの小さい（必須（必見）でなければなりません（リモートホストで利用可能な再組み立てバッファサイズを反映しています。EMTU_R[19]）およびIPレイヤーによって許可される最大の伝送サイズ（EMTU_S [19]）：
Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize
where:
ただし：
* SendMSS is the MSS value received from the remote host, or the default 536 for IPv4 or 1220 for IPv6, if no MSS Option is received.
* SendMSSは、MSSオプションが受信されない場合、リモートホストから受信したMSS値、またはIPv4の場合はデフォルト536またはIPv6の場合は1220です。
* MMS_S is the maximum size for a transport-layer message that TCP may send.
* MMS_Sは、TCPが送信する輸送層メッセージの最大サイズです。
* TCPhdrsize is the size of the fixed TCP header and any options. This is 20 in the (rare) case that no options are present but may be larger if TCP Options are to be sent. Note that some options might not be included on all segments, but that for each segment sent, the sender should adjust the data length accordingly, within the Eff.snd.MSS.
* TCPHDRSIZEは、固定されたTCPヘッダーのサイズと任意のオプションです。これは、（まれな）オプションが存在しないが、TCPオプションを送信する場合は大きくなる可能性があるという（まれな）ケースでは20です。いくつかのオプションはすべてのセグメントに含まれていないかもしれませんが、送信される各セグメントに対して、送信者はそれに応じてeff.snd.mss内でデータの長さを調整する必要があることに注意してください。
* IPoptionsize is the size of any IPv4 options or IPv6 extension headers associated with a TCP connection. Note that some options or extension headers might not be included on all packets, but that for each segment sent, the sender should adjust the data length accordingly, within the Eff.snd.MSS.
* IPOPTIONSIZEは、TCP接続に関連付けられたIPv4オプションまたはIPv6拡張ヘッダーのサイズです。いくつかのオプションまたは拡張ヘッダーはすべてのパケットに含まれていない場合がありますが、送信される各セグメントに対して、送信者はEff.snd.mss内でそれに応じてデータの長さを調整する必要があることに注意してください。
The MSS value to be sent in an MSS Option should be equal to the effective MTU minus the fixed IP and TCP headers. By ignoring both IP and TCP Options when calculating the value for the MSS Option, if there are any IP or TCP Options to be sent in a packet, then the sender must decrease the size of the TCP data accordingly. RFC 6691 [43] discusses this in greater detail.
MSSオプションで送信されるMSS値は、有効なMTUから固定IPおよびTCPヘッダーを差し引いて等しくする必要があります。MSSオプションの値を計算するときにIPとTCPオプションの両方を無視することにより、パケットに送信するIPまたはTCPオプションがある場合、送信者はそれに応じてTCPデータのサイズを減らす必要があります。RFC 6691 [43]はこれについて詳しく説明します。
The MSS value to be sent in an MSS Option must be less than or equal to:
MSSオプションで送信されるMSS値は、以下以下でなければなりません。
MMS_R - 20
MMS_R -20
where MMS_R is the maximum size for a transport-layer message that can be received (and reassembled at the IP layer) (MUST-67). TCP obtains MMS_R and MMS_S from the IP layer; see the generic call GET_MAXSIZES in Section 3.4 of RFC 1122. These are defined in terms of their IP MTU equivalents, EMTU_R and EMTU_S [19].
ここで、MMS_Rは、受信できる（およびIPレイヤーで再組み立てされた）輸送層メッセージの最大サイズです（必見）。TCPは、IPレイヤーからMMS_RおよびMMS_Sを取得します。RFC 1122のセクション3.4の一般的な呼び出しget_maxsizesを参照してください。これらは、IP MTU等価物であるEMTU_RおよびEMTU_S [19]の観点から定義されています。
When TCP is used in a situation where either the IP or TCP headers are not fixed, the sender must reduce the amount of TCP data in any given packet by the number of octets used by the IP and TCP options. This has been a point of confusion historically, as explained in RFC 6691, Section 3.1.
IPヘッダーまたはTCPヘッダーが固定されていない状況でTCPが使用される場合、送信者は、IPおよびTCPオプションで使用されるオクテットの数によって、特定のパケットのTCPデータの量を減らす必要があります。これは、RFC 6691、セクション3.1で説明されているように、歴史的に混乱のポイントでした。
A TCP implementation may be aware of the MTU on directly connected links, but will rarely have insight about MTUs across an entire network path. For IPv4, RFC 1122 recommends an IP-layer default effective MTU of less than or equal to 576 for destinations not directly connected, and for IPv6 this would be 1280. Using these fixed values limits TCP connection performance and efficiency. Instead, implementation of Path MTU Discovery (PMTUD) and Packetization Layer Path MTU Discovery (PLPMTUD) is strongly recommended in order for TCP to improve segmentation decisions. Both PMTUD and PLPMTUD help TCP choose segment sizes that avoid both on-path (for IPv4) and source fragmentation (IPv4 and IPv6).
TCP実装は、直接接続されたリンク上のMTUを認識している場合がありますが、ネットワークパス全体でMTUについて洞察を得ることはめったにありません。IPv4の場合、RFC 1122は、直接接続されていない宛先の場合、576以下のIP層デフォルト有効MTUを推奨します。IPv6の場合、これは1280です。これらの固定値を使用すると、TCP接続のパフォーマンスと効率が制限されます。代わりに、TCPがセグメンテーションの決定を改善するためには、Path MTU Discovery（PMTUD）およびPacketization Layer Path MTU Discovery（PLPMTUD）の実装が強く推奨されます。PMTUDとPLPMTUDの両方が、TCPがオンパス（IPv4の場合）とソースフラグメンテーション（IPv4およびIPv6）の両方を避けるセグメントサイズを選択するのに役立ちます。
PMTUD for IPv4 [2] or IPv6 [14] is implemented in conjunction between TCP, IP, and ICMP. It relies both on avoiding source fragmentation and setting the IPv4 DF (don't fragment) flag, the latter to inhibit on-path fragmentation. It relies on ICMP errors from routers along the path whenever a segment is too large to traverse a link. Several adjustments to a TCP implementation with PMTUD are described in RFC 2923 in order to deal with problems experienced in practice [27]. PLPMTUD [31] is a Standards Track improvement to PMTUD that relaxes the requirement for ICMP support across a path, and improves performance in cases where ICMP is not consistently conveyed, but still tries to avoid source fragmentation. The mechanisms in all four of these RFCs are recommended to be included in TCP implementations.
IPv4 [2]またはIPv6 [14]のPMTUDは、TCP、IP、およびICMPの間で実装されています。ソースの断片化を回避し、IPv4 DF（断片化しない）フラグを設定することの両方に依存しています。後者は、パス断片化を阻害します。セグメントが大きすぎてリンクを通過できない場合はいつでも、パスに沿ったルーターからのICMPエラーに依存しています。PMTUDを使用したTCP実装のいくつかの調整は、実際に経験した問題に対処するためにRFC 2923で説明されています[27]。PLPMTUD [31]は、パス全体でICMPサポートの要件を緩和し、ICMPが一貫して伝えられていない場合のパフォーマンスを向上させるPMTUDの標準トラック改善です。これら4つのRFCすべてのメカニズムは、TCP実装に含めることをお勧めします。
The TCP MSS Option specifies an upper bound for the size of packets that can be received (see [43]). Hence, setting the value in the MSS Option too small can impact the ability for PMTUD or PLPMTUD to find a larger path MTU. RFC 1191 discusses this implication of many older TCP implementations setting the TCP MSS to 536 (corresponding to the IPv4 576 byte default MTU) for non-local destinations, rather than deriving it from the MTUs of connected interfaces as recommended.
TCP MSSオプションは、受信できるパケットのサイズの上限を指定します（[43]を参照）。したがって、MSSオプションの値を小さく設定すると、PMTUDまたはPLPMTUDがより大きなパスMTUを見つける機能に影響を与える可能性があります。RFC 1191は、推奨されるように接続されたインターフェイスのMTUから導出するのではなく、非ローカル宛先のTCP MSSを536（IPv4 576バイトデフォルトMTUに対応）に設定する多くの古いTCP実装のこの意味について説明します。
The effective MTU can sometimes vary, as when used with variable compression, e.g., RObust Header Compression (ROHC) [37]. It is tempting for a TCP implementation to advertise the largest possible MSS, to support the most efficient use of compressed payloads. Unfortunately, some compression schemes occasionally need to transmit full headers (and thus smaller payloads) to resynchronize state at their endpoint compressors/decompressors. If the largest MTU is used to calculate the value to advertise in the MSS Option, TCP retransmission may interfere with compressor resynchronization.
有効なMTUは、可変圧縮で使用される場合、たとえば堅牢なヘッダー圧縮（ROHC）[37]で使用する場合がある場合があります。TCP実装が可能な限り最大のMSSを宣伝し、圧縮ペイロードの最も効率的な使用をサポートするのは魅力的です。残念ながら、一部の圧縮スキームは、エンドポイントコンプレッサー/分解器で状態を再同期させるために、フルヘッダー（したがって小さなペイロード）を送信する必要がある場合があります。最大のMTUがMSSオプションで広告する値を計算するために使用される場合、TCPの再送信はコンプレッサーの再同期を妨げる可能性があります。
As a result, when the effective MTU of an interface varies packet-to-packet, TCP implementations SHOULD use the smallest effective MTU of the interface to calculate the value to advertise in the MSS Option (SHLD-6).
その結果、インターフェイスの有効なMTUがパケットごとに変化する場合、TCP実装はインターフェイスの最小の有効なMTUを使用して、MSSオプション（SHLD-6）で広告する値を計算する必要があります。
The "Nagle algorithm" was described in RFC 896 [17] and was recommended in RFC 1122 [19] for mitigation of an early problem of too many small packets being generated. It has been implemented in most current TCP code bases, sometimes with minor variations (see Appendix A.3).
「Nagleアルゴリズム」はRFC 896 [17]で説明されており、RFC 1122 [19]で、生成されているほど多くの小さなパケットの初期の問題の緩和について推奨されました。これは、ほとんどの現在のTCPコードベースで実装されており、時にはわずかなバリエーションがあります（付録A.3を参照）。
If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the sending TCP endpoint buffers all user data (regardless of the PSH bit) until the outstanding data has been acknowledged or until the TCP endpoint can send a full-sized segment (Eff.snd.MSS bytes).
未承認のデータ（つまり、snd.nxt> snd.una）がある場合、TCPエンドポイントを送信すると、未解決のデータが認められるまで、またはTCPエンドポイントがフルを送信できるまで、すべてのユーザーデータ（PSHビットに関係なく）が送信されます。サイズのセグメント（eff.snd.mssバイト）。
A TCP implementation SHOULD implement the Nagle algorithm to coalesce short segments (SHLD-7). However, there MUST be a way for an application to disable the Nagle algorithm on an individual connection (MUST-17). In all cases, sending data is also subject to the limitation imposed by the slow start algorithm [8].
TCP実装では、Nagleアルゴリズムを実装して短いセグメント（SHLD-7）を合体する必要があります。ただし、アプリケーションが個々の接続でナグルアルゴリズムを無効にする方法がなければなりません（必須-17）。すべての場合において、データの送信は、スロースタートアルゴリズム[8]によって課される制限の対象となります。
Since there can be problematic interactions between the Nagle algorithm and delayed acknowledgments, some implementations use minor variations of the Nagle algorithm, such as the one described in Appendix A.3.
ナグルアルゴリズムと遅延承認との間に問題のある相互作用がある可能性があるため、いくつかの実装は、付録A.3で説明したものなど、ナグルアルゴリズムのマイナーなバリエーションを使用します。
In order to support TCP over IPv6 Jumbograms, implementations need to be able to send TCP segments larger than the 64-KB limit that the MSS Option can convey. RFC 2675 [24] defines that an MSS value of 65,535 bytes is to be treated as infinity, and Path MTU Discovery [14] is used to determine the actual MSS.
IPv6ジャンボグラムよりもTCPをサポートするには、MSSオプションが伝えることができる64 kbの制限よりも大きなTCPセグメントを送信できる必要があります。RFC 2675 [24]は、65,535バイトのMSS値が無限として扱われることを定義しており、PATH MTU発見[14]が実際のMSSを決定するために使用されます。
The Jumbo Payload Option need not be implemented or understood by IPv6 nodes that do not support attachment to links with an MTU greater than 65,575 [24], and the present IPv6 Node Requirements does not include support for Jumbograms [55].
ジャンボペイロードオプションは、65,575を超えるMTUとのリンクへのアタッチメントをサポートしないIPv6ノード[24]で実装または理解する必要はありません。
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 to ensure delivery of every segment. Duplicate segments may arrive due to network or TCP retransmission. As discussed in the section on sequence numbers (Section 3.4), the TCP implementation performs certain tests on the sequence and acknowledgment numbers in the segments to verify their acceptability.
接続が確立されると、データはセグメントの交換によって通信されます。エラー（チェックサムテストの障害）またはネットワークの混雑によりセグメントが失われる可能性があるため、TCPは再送信を使用してすべてのセグメントの配信を確保します。ネットワークまたはTCPの再送信により、重複したセグメントが到着する場合があります。シーケンス番号（セクション3.4）のセクションで説明したように、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で最も古い非概要シーケンス番号を追跡します。データフローが一時的にアイドル状態であり、送信されたすべてのデータが認められている場合、3つの変数は等しくなります。
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 and SYN or FIN flags in the segment. Note that, once in the ESTABLISHED state, all segments must carry current acknowledgment information.
送信者がセグメントを作成して送信すると、送信者はsnd.nxtを進めます。受信者がセグメントを受け入れると、RCV.NXTを進め、謝辞を送信します。データ送信者が謝辞を受け取ると、SND.UNAを進めます。これらの変数の値が異なる程度は、通信の遅延の尺度です。変数が高度になる量は、セグメント内のデータとSynまたはFINフラグの長さです。確立された状態に入ると、すべてのセグメントが現在の確認情報を掲載する必要があることに注意してください。
The CLOSE user call implies a push function (see Section 3.9.1), as does the FIN control flag in an incoming segment.
閉じるユーザーコールは、プッシュ関数を意味します（セクション3.9.1を参照）。
Because of the variability of the networks that compose an internetwork system and the wide range of uses of TCP connections, the retransmission timeout (RTO) must be dynamically determined.
インターネットワークシステムを構成するネットワークの変動性とTCP接続の幅広い用途のため、再送信タイムアウト（RTO）を動的に決定する必要があります。
The RTO MUST be computed according to the algorithm in [10], including Karn's algorithm for taking RTT samples (MUST-18).
RTOは、RTTサンプルを採取するためのKarnのアルゴリズムを含む[10]のアルゴリズムに従って計算する必要があります（必須18）。
RFC 793 contains an early example procedure for computing the RTO, based on work mentioned in IEN 177 [71]. This was then replaced by the algorithm described in RFC 1122, which was subsequently updated in RFC 2988 and then again in RFC 6298.
RFC 793には、IEN 177 [71]で言及されている作業に基づいて、RTOを計算するための初期の例手順が含まれています。これは、RFC 1122で説明されているアルゴリズムに置き換えられ、その後RFC 2988で更新され、その後RFC 6298で更新されました。
RFC 1122 allows that if a retransmitted packet is identical to the original packet (which implies not only that the data boundaries have not changed, but also that none of the headers have changed), then the same IPv4 Identification field MAY be used (see Section 3.2.1.5 of RFC 1122) (MAY-4). The same IP Identification field may be reused anyways since it is only meaningful when a datagram is fragmented [44]. TCP implementations should not rely on or typically interact with this IPv4 header field in any way. It is not a reasonable way to indicate duplicate sent segments nor to identify duplicate received segments.
RFC 1122により、再送信パケットが元のパケットと同一である場合（これは、データの境界が変更されていないだけでなく、ヘッダーが変更されていないことを意味する場合、同じIPv4識別フィールドを使用できます（セクションを参照してください。RFC 1122の3.2.1.5）（5月4日）。とにかく同じIP識別フィールドは、データグラムが断片化されている場合にのみ意味があるため、とにかく再利用される可能性があります[44]。TCPの実装は、このIPv4ヘッダーフィールドに依存したり、通常やり取りしたりしないでください。重複したセグメントを示す合理的な方法ではなく、重複した受信セグメントを識別することはできません。
RFC 2914 [5] explains the importance of congestion control for the Internet.
RFC 2914 [5]は、インターネットの混雑制御の重要性を説明しています。
RFC 1122 required implementation of Van Jacobson's congestion control algorithms slow start and congestion avoidance together with exponential backoff for successive RTO values for the same segment. RFC 2581 provided IETF Standards Track description of slow start and congestion avoidance, along with fast retransmit and fast recovery. RFC 5681 is the current description of these algorithms and is the current Standards Track specification providing guidelines for TCP congestion control. RFC 6298 describes exponential backoff of RTO values, including keeping the backed-off value until a subsequent segment with new data has been sent and acknowledged without retransmission.
RFC 1122 Van Jacobsonの混雑制御アルゴリズムの実装が必要なのは、同じセグメントの連続したRTO値の指数関数的なバックオフとともに、スロースタートと輻輳回避を回避しました。RFC 2581は、IETF標準を提供して、速い開始および輻輳回避の説明を追跡し、迅速な再送信と迅速な回復を追跡しました。RFC 5681は、これらのアルゴリズムの現在の説明であり、TCP混雑制御のガイドラインを提供する現在の標準トラック仕様です。RFC 6298は、RTO値の指数関数的バックオフについて説明します。これには、新しいデータを使用した後続のセグメントが送信されなくなるまでバックオフ値を維持することが含まれます。
A TCP endpoint MUST implement the basic congestion control algorithms slow start, congestion avoidance, and exponential backoff of RTO to avoid creating congestion collapse conditions (MUST-19). RFC 5681 and RFC 6298 describe the basic algorithms on the IETF Standards Track that are broadly applicable. Multiple other suitable algorithms exist and have been widely used. Many TCP implementations support a set of alternative algorithms that can be configured for use on the endpoint. An endpoint MAY implement such alternative algorithms provided that the algorithms are conformant with the TCP specifications from the IETF Standards Track as described in RFC 2914, RFC 5033 [7], and RFC 8961 [15] (MAY-18).
TCPエンドポイントは、輻輳崩壊条件の作成を避けるために、基本的な混雑制御アルゴリズムのスロースタート、渋滞回避、およびRTOの指数関数的なバックオフを実装する必要があります（必須19）。RFC 5681およびRFC 6298は、広く適用されるIETF標準トラックの基本的なアルゴリズムを説明しています。他の複数の適切なアルゴリズムが存在し、広く使用されています。多くのTCP実装は、エンドポイントで使用するために構成できる一連の代替アルゴリズムをサポートしています。エンドポイントは、RFC 2914、RFC 5033 [7]、およびRFC 8961 [15]（5月18日）で説明されているように、アルゴリズムがIETF標準トラックのTCP仕様に適合している場合、そのような代替アルゴリズムを実装する場合があります。
Explicit Congestion Notification (ECN) was defined in RFC 3168 and is an IETF Standards Track enhancement that has many benefits [51].
明示的な混雑通知（ECN）はRFC 3168で定義されており、多くの利点を持つIETF標準トラックの強化です[51]。
A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD-8).
TCPエンドポイントは、RFC 3168（SHLD-8）に記載されているようにECNを実装する必要があります。
Excessive retransmission of the same segment by a TCP endpoint indicates some failure of the remote host or the internetwork path. This failure may be of short or long duration. The following procedure MUST be used to handle excessive retransmissions of data segments (MUST-20):
TCPエンドポイントによる同じセグメントの過度の再送信は、リモートホストまたはインターネットワークパスのある程度の障害を示します。この障害は、短期間または長い期間である可能性があります。以下の手順を使用して、データセグメントの過度の再送信を処理する必要があります（必見）。
(a) There are two thresholds R1 and R2 measuring the amount of retransmission that has occurred for the same segment. R1 and R2 might be measured in time units or as a count of retransmissions (with the current RTO and corresponding backoffs as a conversion factor, if needed).
(a) 同じセグメントで発生した再送信量を測定する2つのしきい値R1とR2があります。R1とR2は、時間単位または再送信のカウントとして測定される場合があります（必要に応じて、現在のRTOおよび対応するバックオフを変換係数として）。
(b) When the number of transmissions of the same segment reaches or exceeds threshold R1, pass negative advice (see Section 3.3.1.4 of [19]) to the IP layer, to trigger dead-gateway diagnosis.
(b) 同じセグメントの送信の数がしきい値R1に達するか、それを超える場合、否定的なアドバイス（[19]のセクション3.3.1.4を参照）をIP層に渡し、デッドゲートウェイの診断をトリガーします。
(c) When the number of transmissions of the same segment reaches a threshold R2 greater than R1, close the connection.
(c) 同じセグメントのトランスミッションの数がR1より大きいしきい値R2に達すると、接続を閉じます。
(d) An application MUST (MUST-21) be able to set the value for R2 for a particular connection. For example, an interactive application might set R2 to "infinity", giving the user control over when to disconnect.
(d) アプリケーション（Must-21）は、特定の接続のR2の値を設定できる必要があります。たとえば、インタラクティブなアプリケーションはR2を「無限」に設定し、ユーザーがいつ切断するかを制御することができます。
(e) TCP implementations SHOULD inform the application of the delivery problem (unless such information has been disabled by the application; see the "Asynchronous Reports" section (Section 3.9.1.8)), when R1 is reached and before R2 (SHLD-9). This will allow a remote login application program to inform the user, for example.
(e) TCPの実装は、配信問題の適用を通知する必要があります（アプリケーションによってそのような情報が無効になっていない限り、R1に到達した場合、R2（SHLD-9）の前に、「非同期レポート」セクション（セクション3.9.1.8）を参照）。これにより、リモートログインアプリケーションプログラムがユーザーに通知できるようになります。
The value of R1 SHOULD correspond to at least 3 retransmissions, at the current RTO (SHLD-10). The value of R2 SHOULD correspond to at least 100 seconds (SHLD-11).
R1の値は、現在のRTO（SHLD-10）で、少なくとも3回の再送信に対応する必要があります。R2の値は、少なくとも100秒（SHLD-11）に対応する必要があります。
An attempt to open a TCP connection could fail with excessive retransmissions of the SYN segment or by receipt of a RST segment or an ICMP Port Unreachable. SYN retransmissions MUST be handled in the general way just described for data retransmissions, including notification of the application layer.
TCP接続を開く試みは、Synセグメントの過度の再送信、またはRSTセグメントまたはICMPポートの到達不能を受け取って失敗する可能性があります。Synの再送信は、アプリケーションレイヤーの通知を含むデータ再送信について、先ほど説明した一般的な方法で処理する必要があります。
However, the values of R1 and R2 may be different for SYN and data segments. In particular, R2 for a SYN segment MUST be set large enough to provide retransmission of the segment for at least 3 minutes (MUST-23). The application can close the connection (i.e., give up on the open attempt) sooner, of course.
ただし、R1とR2の値は、SYNとデータセグメントで異なる場合があります。特に、SynセグメントのR2は、少なくとも3分間セグメントの再送信を提供するのに十分な大きさに設定する必要があります（Must-23）。もちろん、アプリケーションはより早く接続を閉じる（つまり、オープンな試みをあきらめる）ことができます。
A TCP connection is said to be "idle" if for some long amount of time there have been no incoming segments received and there is no new or unacknowledged data to be sent.
TCP接続は、ある程度の時間の間、受信セグメントが届かず、送信される新しいまたは未把握されていないデータがない場合、「アイドル」であると言われています。
Implementers MAY include "keep-alives" in their TCP implementations (MAY-5), although this practice is not universally accepted. Some TCP implementations, however, have included a keep-alive mechanism. To confirm that an idle connection is still active, these implementations send a probe segment designed to elicit a response from the TCP peer. Such a segment generally contains SEG.SEQ = SND.NXT-1 and may or may not contain one garbage octet of data. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection (MUST-24), and they MUST default to off (MUST-25).
実装者は、TCP実装（5月5日）に「Keep-Alives」を含めることができますが、この実践は普遍的に受け入れられていません。ただし、一部のTCP実装には、キープアライブメカニズムが含まれています。アイドル接続がまだアクティブであることを確認するために、これらの実装は、TCPピアからの応答を引き出すように設計されたプローブセグメントを送信します。このようなセグメントには通常、seg.seq = snd.nxt-1が含まれており、1つのガベージオクテットのデータが含まれている場合と含まれない場合があります。Keep-Alivesが含まれている場合、アプリケーションはTCP接続ごとにそれらをオンまたはオフにすることができなければなりません（必須-24）。
Keep-alive packets MUST only be sent when no sent data is outstanding, and no data or acknowledgment packets have been received for the connection within an interval (MUST-26). This interval MUST be configurable (MUST-27) and MUST default to no less than two hours (MUST-28).
Keep-Aliveパケットは、送信されたデータが未解決の場合にのみ送信される必要があり、間隔内（Must-26）内の接続に対してデータまたは確認パケットが受信されていません。この間隔は構成可能でなければならず（Must-27）、デフォルトで2時間以上（Must-28）が必要です。
It is extremely important to remember that ACK segments that contain no data are not reliably transmitted by TCP. Consequently, if a keep-alive mechanism is implemented it MUST NOT interpret failure to respond to any specific probe as a dead connection (MUST-29).
データを含むACKセグメントがTCPによって確実に送信されないことを覚えておくことは非常に重要です。したがって、キープアライブメカニズムが実装されている場合、特定のプローブへの応答の失敗を死んだ接続として解釈してはなりません（Must-29）。
An implementation SHOULD send a keep-alive segment with no data (SHLD-12); however, it MAY be configurable to send a keep-alive segment containing one garbage octet (MAY-6), for compatibility with erroneous TCP implementations.
実装では、データなしのキープアライブセグメントを送信する必要があります（SHLD-12）。ただし、誤ったTCP実装との互換性のために、1つのガベージオクテット（5月6日）を含むキープアライブセグメントを送信することができます。
As a result of implementation differences and middlebox interactions, new applications SHOULD NOT employ the TCP urgent mechanism (SHLD-13). However, TCP implementations MUST still include support for the urgent mechanism (MUST-30). Information on how some TCP implementations interpret the urgent pointer can be found in RFC 6093 [39].
実装の違いとミドルボックスの相互作用の結果として、新しいアプリケーションはTCP緊急メカニズムを採用してはなりません（SHLD-13）。ただし、TCPの実装には、緊急メカニズムのサポート（必須30）を含める必要があります。一部のTCP実装が緊急ポインターをどのように解釈するかに関する情報は、RFC 6093 [39]に記載されています。
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 endpoint 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 endpoint, then the TCP implementation must tell the user to go into "urgent mode"; when the receive sequence number catches up to the urgent pointer, the TCP implementation 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 an urgent field that 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. Note that because changes in the urgent pointer correspond to data being written by a sending application, the urgent pointer cannot "recede" in the sequence space, but a TCP receiver should be robust to invalid urgent pointer values.
緊急の表示を送信するには、ユーザーは少なくとも1つのデータOctetも送信する必要があります。送信ユーザーがプッシュを示している場合、宛先プロセスへの緊急情報のタイムリーな配信が強化されます。緊急ポインターの変更は、送信アプリケーションによって記述されるデータに対応するため、緊急ポインターはシーケンススペースで「後退」することはできませんが、TCPレシーバーは緊急ポインター値を無効にするために堅牢である必要があります。
A TCP implementation MUST support a sequence of urgent data of any length (MUST-31) [19].
TCPの実装は、任意の長さの一連の緊急データをサポートする必要があります（必見）[19]。
The urgent pointer MUST point to the sequence number of the octet following the urgent data (MUST-62).
緊急のポインターは、緊急のデータに続くオクテットのシーケンス番号を指す必要があります（必見）。
A TCP implementation MUST (MUST-32) inform the application layer asynchronously whenever it receives an urgent pointer and there was previously no pending urgent data, or whenever the urgent pointer advances in the data stream. The TCP implementation MUST (MUST-33) provide a way for the application to learn how much urgent data remains to be read from the connection, or at least to determine whether more urgent data remains to be read [19].
TCPの実装は、緊急のポインターを受け取るたびにアプリケーション層に非同期に通知する必要があり、以前は緊急のデータが保留されていなかった場合、または緊急のポインターがデータストリームで進むたびに通知する必要があります。TCPの実装は、[必須]（33）が、アプリケーションが接続から読み取られる緊急データの残りの部分を学習する方法を提供するか、少なくともより緊急のデータが読み取られているかどうかを判断する方法を提供する必要があります[19]。
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 data buffer space currently available for this connection.
各セグメントで送信されたウィンドウは、ウィンドウの送信者（データレシーバー）が現在受け入れる準備ができているシーケンス番号の範囲を示しています。これは、この接続で現在利用可能なデータバッファースペースに関連しているという仮定があります。
The sending TCP endpoint packages the data to be transmitted into segments that 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 an acknowledgment number equal to or greater than the highest previously received).
一方向のデータフローに関連して、ウィンドウ情報はすべて同じシーケンス番号を持っていることを確認するセグメントで伝えられます。これは深刻な問題ではありませんが、データ受信機からの古いレポートに基づいて、ウィンドウ情報を一時的に一時的に行うことができます。この問題を回避するための洗練は、最高の承認番号（つまり、以前に受け取った中で最も高い以上の承認番号があるセグメント）を持つセグメントからのウィンドウ情報に基づいて行動することです。
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 TCP endpoints. 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 endpoint 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 [19] dictates that TCP peers will not shrink the window themselves, but will be prepared for such behavior on the part of other TCP peers.
提供されるメカニズムにより、TCPエンドポイントが大きなウィンドウを宣伝し、その後、その多くのデータを受け入れることなく、はるかに小さなウィンドウを宣伝することができます。このいわゆる「窓の縮小」は強く落胆しています。堅牢性の原則[19]は、TCPピアが窓を縮まらないでください。他のTCPピアの側でそのような動作に備えられると述べています。
A TCP receiver SHOULD NOT shrink the window, i.e., move the right window edge to the left (SHLD-14). However, a sending TCP peer MUST be robust against window shrinking, which may cause the "usable window" (see Section 3.8.6.2.1) to become negative (MUST-34).
TCPレシーバーは、ウィンドウを縮小しないでください。つまり、右ウィンドウの端を左に移動します（SHLD-14）。ただし、送信するTCPピアは、ウィンドウの縮小に対して堅牢でなければなりません。これにより、「使用可能なウィンドウ」（セクション3.8.6.2.1を参照）がネガティブになる可能性があります（必見）。
If this happens, the sender SHOULD NOT send new data (SHLD-15), but SHOULD retransmit normally the old unacknowledged data between SND.UNA and SND.UNA+SND.WND (SHLD-16). The sender MAY also retransmit old data beyond SND.UNA+SND.WND (MAY-7), but SHOULD NOT time out the connection if data beyond the right window edge is not acknowledged (SHLD-17). If the window shrinks to zero, the TCP implementation MUST probe it in the standard way (described below) (MUST-35).
これが発生した場合、送信者は新しいデータ（SHLD-15）を送信する必要はありませんが、SND.UNAとSND.UNA SND.WND（SHLD-16）の間の古い未装甲データを通常再送信する必要があります。送信者は、SND.UNA SND.WND（5月7日）を超えて古いデータを再送信することもできますが、右ウィンドウの端を超えたデータが認められていない場合（SHLD-17）、接続をタイムアウトさせるべきではありません。ウィンドウがゼロに縮小する場合、TCP実装は標準的な方法（以下で説明）でプローブする必要があります（必須）。
The sending TCP peer must regularly transmit at least one octet of new data (if available), or retransmit to the receiving TCP peer even if the send window is zero, in order to "probe" the window. This retransmission is essential to guarantee that when either TCP peer has a zero window the reopening of the window will be reliably reported to the other. This is referred to as Zero-Window Probing (ZWP) in other documents.
送信TCPピアは、少なくとも1オクテットの新しいデータ（利用可能な場合）を定期的に送信するか、[送信]ウィンドウがゼロであっても、ウィンドウを「プローブ」するために受信TCPピアを再送信する必要があります。この再送信は、いずれかのTCPピアがゼロウィンドウを持っている場合、ウィンドウの再開が他方に確実に報告されることを保証するために不可欠です。これは、他のドキュメントではゼロウィンドウプロービング（ZWP）と呼ばれます。
Probing of zero (offered) windows MUST be supported (MUST-36).
ゼロ（提供された）ウィンドウの調査をサポートする必要があります（必須）。
A TCP implementation MAY keep its offered receive window closed indefinitely (MAY-8). As long as the receiving TCP peer continues to send acknowledgments in response to the probe segments, the sending TCP peer MUST allow the connection to stay open (MUST-37). This enables TCP to function in scenarios such as the "printer ran out of paper" situation described in Section 4.2.2.17 of [19]. The behavior is subject to the implementation's resource management concerns, as noted in [41].
TCP実装は、提供された受信ウィンドウを無期限に閉じたままにすることができます（5月8日）。受信TCPピアがプローブセグメントに応じて謝辞を送信し続ける限り、送信TCPピアは接続を開いたままにする必要があります（必須37）。これにより、TCPは[19]のセクション4.2.2.17で説明されている「プリンターが紙がなくなった」状況などのシナリオで機能することができます。この動作は、[41]に記載されているように、実装のリソース管理上の懸念の対象となります。
When the receiving TCP peer 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 transmitting host SHOULD send the first zero-window probe when a zero window has existed for the retransmission timeout period (SHLD-29) (Section 3.8.1), and SHOULD increase exponentially the interval between successive probes (SHLD-30).
送信ホストは、再送信タイムアウト期間（SHLD-29）（セクション3.8.1）にゼロウィンドウが存在する場合、最初のゼロウィンドウプローブを送信する必要があり、連続プローブ間の間隔を指数関数的に増加させるはずです（SHLD-30）。
The "Silly Window Syndrome" (SWS) is a stable pattern of small incremental window movements resulting in extremely poor TCP performance. Algorithms to avoid SWS are described below for both the sending side and the receiving side. RFC 1122 contains more detailed discussion of the SWS problem. Note that the Nagle algorithm and the sender SWS avoidance algorithm play complementary roles in improving performance. The Nagle algorithm discourages sending tiny segments when the data to be sent increases in small increments, while the SWS avoidance algorithm discourages small segments resulting from the right window edge advancing in small increments.
「愚かなウィンドウ症候群」（SWS）は、小さな増分窓の動きの安定したパターンであり、TCPのパフォーマンスが非常に低下します。SWSを回避するためのアルゴリズムは、送信側と受信側の両方について以下に説明します。RFC 1122には、SWS問題の詳細な議論が含まれています。Nagleアルゴリズムと送信者SWS回避アルゴリズムは、パフォーマンスの向上に補完的な役割を果たすことに注意してください。Nagleアルゴリズムは、送信されるデータがわずかに増加したときに小さなセグメントを送信することを思いとどまらせますが、SWS回避アルゴリズムは、右窓のエッジがわずかに増加したことに起因する小さなセグメントを思いとどまらせます。
A TCP implementation MUST include a SWS avoidance algorithm in the sender (MUST-38).
TCP実装には、送信者にSWS回避アルゴリズムを含める必要があります（必須）。
The Nagle algorithm from Section 3.7.4 additionally describes how to coalesce short segments.
セクション3.7.4のNagleアルゴリズムでは、さらに短いセグメントを合体する方法について説明します。
The sender's SWS avoidance algorithm is more difficult than the receiver's because the sender does not know (directly) the receiver's total buffer space (RCV.BUFF). An approach that has been found to work well is for the sender to calculate Max(SND.WND), which is the maximum send window it has seen so far on the connection, and to use this value as an estimate of RCV.BUFF. Unfortunately, this can only be an estimate; the receiver may at any time reduce the size of RCV.BUFF. To avoid a resulting deadlock, it is necessary to have a timeout to force transmission of data, overriding the SWS avoidance algorithm. In practice, this timeout should seldom occur.
送信者のSWS回避アルゴリズムは、受信者の合計バッファースペース（RCV.BUFF）を（直接）知らないため、受信者のSWS回避アルゴリズムよりも困難です。うまく機能することがわかったアプローチは、送信者がMAX（SND.WND）を計算するためのものです。これは、これまでに接続で見られた最大送信ウィンドウであり、この値をRCV.Buffの推定として使用します。残念ながら、これは見積もりにすぎません。レシーバーは、いつでもRCV.Buffのサイズを削減できます。結果のデッドロックを回避するには、SWS回避アルゴリズムをオーバーライドするデータの送信を強制するためのタイムアウトを持つ必要があります。実際には、このタイムアウトはめったに発生しません。
The "usable window" is:
「使用可能なウィンドウ」は次のとおりです。
U = SND.UNA + SND.WND - SND.NXT
i.e., the offered window less the amount of data sent but not acknowledged. If D is the amount of data queued in the sending TCP endpoint but not yet sent, then the following set of rules is recommended.
つまり、提供されたウィンドウは、送信されたデータの量を減らしますが、確認されていません。Dが送信TCPエンドポイントでキューに留められているがまだ送信されていないデータの量である場合、次の一連のルールが推奨されます。
Send data:
データを送る：
(1) if a maximum-sized segment can be sent, i.e., if:
(1) 最大サイズのセグメントを送信できる場合、つまり、次の場合。
min(D,U) >= Eff.snd.MSS;
(2) or if the data is pushed and all queued data can be sent now, i.e., if:
(2) または、データがプッシュされ、すべてのキューに掲載されたデータを今すぐ送信できる場合、つまり以下の場合は次の場合
[SND.NXT = SND.UNA and] PUSHed and D <= U
(the bracketed condition is imposed by the Nagle algorithm);
（括弧付きの条件は、ナグルアルゴリズムによって課されます）;
(3) or if at least a fraction Fs of the maximum window can be sent, i.e., if:
(3) または、最大ウィンドウの少なくとも分数fsを送信できる場合、つまり以下を送信できます。
[SND.NXT = SND.UNA and]
[snd.nxt = snd.unaと]
min(D,U) >= Fs * Max(SND.WND);
(4) or if the override timeout occurs.
(4) または、オーバーライドタイムアウトが発生した場合。
Here Fs is a fraction whose recommended value is 1/2. The override timeout should be in the range 0.1 - 1.0 seconds. It may be convenient to combine this timer with the timer used to probe zero windows (Section 3.8.6.1).
ここでは、FSは推奨値が1/2である分数です。オーバーライドタイムアウトは、0.1〜1.0秒の範囲にある必要があります。このタイマーとゼロウィンドウをプローブするために使用されるタイマーを組み合わせると便利かもしれません（セクション3.8.6.1）。
A TCP implementation MUST include a SWS avoidance algorithm in the receiver (MUST-39).
TCP実装には、受信機にSWS回避アルゴリズムを含める必要があります（必須）。
The receiver's SWS avoidance algorithm determines when the right window edge may be advanced; this is customarily known as "updating the window". This algorithm combines with the delayed ACK algorithm (Section 3.8.6.3) to determine when an ACK segment containing the current window will really be sent to the receiver.
受信者のSWS回避アルゴリズムは、右のウィンドウエッジがいつ進んでいるかを決定します。これは慣習的に「ウィンドウの更新」として知られています。このアルゴリズムは、遅延ACKアルゴリズム（セクション3.8.6.3）と組み合わされ、現在のウィンドウを含むACKセグメントが実際にレシーバーに送信される時期を決定します。
The solution to receiver SWS is to avoid advancing the right window edge RCV.NXT+RCV.WND in small increments, even if data is received from the network in small segments.
レシーバーSWSのソリューションは、小さなセグメントでネットワークからデータが受信されたとしても、右ウィンドウエッジRCV.NXT RCV.WNDをわずかに刻みながら進めないようにすることです。
Suppose the total receive buffer space is RCV.BUFF. At any given moment, RCV.USER octets of this total may be tied up with data that has been received and acknowledged but that the user process has not yet consumed. When the connection is quiescent, RCV.WND = RCV.BUFF and RCV.USER = 0.
合計受信バッファースペースがrcv.buffであるとします。いつでも、この合計のRCV.USERオクテットは、受信および認められたデータと結びついている可能性がありますが、ユーザープロセスはまだ消費されていません。接続が静止している場合、rcv.wnd = rcv.buffおよびrcv.user = 0。
Keeping the right window edge fixed as data arrives and is acknowledged requires that the receiver offer less than its full buffer space, i.e., the receiver must specify a RCV.WND that keeps RCV.NXT+RCV.WND constant as RCV.NXT increases. Thus, the total buffer space RCV.BUFF is generally divided into three parts:
データが到着し、認識されているときに右のウィンドウエッジを固定したままにするには、レシーバーが完全なバッファスペースよりも少ないことを提供する必要があります。つまり、RCV.NXTが増加するにつれてRCV.NXT RCV.WND定数を維持するRCV.WNDを指定する必要があります。したがって、総バッファスペースRCV.BUFFは、通常、3つの部分に分割されます。
|<------- RCV.BUFF ---------------->|
1 2 3
----|---------|------------------|------|----
RCV.NXT ^
(Fixed)
1 - RCV.USER = data received but not yet consumed;
2 - RCV.WND = space advertised to sender;
3 - Reduction = space available but not yet
advertised.
The suggested SWS avoidance algorithm for the receiver is to keep RCV.NXT+RCV.WND fixed until the reduction satisfies:
受信機の推奨されるSWS回避アルゴリズムは、RCV.NXT RCV.を維持し、削減が満たされるまで修正することです。
RCV.BUFF - RCV.USER - RCV.WND >=
min( Fr * RCV.BUFF, Eff.snd.MSS )
min（fr * rcv.buff、eff.snd.mss）
where Fr is a fraction whose recommended value is 1/2, and Eff.snd.MSS is the effective send MSS for the connection (see Section 3.7.1). When the inequality is satisfied, RCV.WND is set to RCV.BUFF-RCV.USER.
ここで、FRは推奨値が1/2である分数であり、Eff.snd.mssは接続の有効送信MSSです（セクション3.7.1を参照）。不平等が満たされると、rcv.wndはrcv.buff-rcv.userに設定されます。
Note that the general effect of this algorithm is to advance RCV.WND in increments of Eff.snd.MSS (for realistic receive buffers: Eff.snd.MSS < RCV.BUFF/2). Note also that the receiver must use its own Eff.snd.MSS, making the assumption that it is the same as the sender's.
このアルゴリズムの一般的な効果は、eff.snd.mss（現実的な受信バッファーの場合：eff.snd.mss <rcv.buff/2）の増分でrcv.wndを進めることであることに注意してください。また、受信者は独自のeff.snd.mssを使用する必要があり、送信者と同じであると仮定する必要があることに注意してください。
A host that is receiving a stream of TCP data segments can increase efficiency in both the network and the hosts by sending fewer than one ACK (acknowledgment) segment per data segment received; this is known as a "delayed ACK".
TCPデータセグメントのストリームを受信しているホストは、受信したデータセグメントごとに1つ未満のACK（承認）セグメントを送信することにより、ネットワークとホストの両方で効率を高めることができます。これは「遅延ACK」として知られています。
A TCP endpoint SHOULD implement a delayed ACK (SHLD-18), but an ACK should not be excessively delayed; in particular, the delay MUST be less than 0.5 seconds (MUST-40). An ACK SHOULD be generated for at least every second full-sized segment or 2*RMSS bytes of new data (where RMSS is the MSS specified by the TCP endpoint receiving the segments to be acknowledged, or the default value if not specified) (SHLD-19). Excessive delays on ACKs can disturb the round-trip timing and packet "clocking" algorithms. More complete discussion of delayed ACK behavior is in Section 4.2 of RFC 5681 [8], including recommendations to immediately acknowledge out-of-order segments, segments above a gap in sequence space, or segments that fill all or part of a gap, in order to accelerate loss recovery.
TCPエンドポイントは、遅延ACK（SHLD-18）を実装する必要がありますが、ACKを過度に遅らせることはできません。特に、遅延は0.5秒未満でなければなりません（必須）。ACKは、少なくとも2秒ごとのフルサイズのセグメントまたは2*RMSSバイトの新しいデータ（RMSSは、確認されるセグメントを受信するTCPエンドポイントによって指定されたMSS、または指定されていない場合はデフォルト値）（SHLD）に生成する必要があります（SHLD）-19）。ACKの過度の遅延は、往復タイミングとパケット「Clocking」アルゴリズムを乱す可能性があります。遅延ACKの動作のより完全な議論は、RFC 5681 [8]のセクション4.2にあります。損失回復を加速するため。
Note that there are several current practices that further lead to a reduced number of ACKs, including generic receive offload (GRO) [72], ACK compression, and ACK decimation [28].
ジェネリック受信オフロード（GRO）[72]、ACK圧縮、ACKデシメーション[28]など、ACKの数の減少にさらにつながるいくつかの現在の慣行があることに注意してください。
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 lower-level protocol. For the case that the lower level is IP, we note some of the parameter values that TCP implementations might use.
もちろん、ユーザー/TCPインターフェイスとTCP/低レベルのインターフェイスの2つの懸念事項があります。ユーザー/TCPインターフェイスのかなり手の込んだモデルがありますが、低レベルのプロトコルモジュールへのインターフェイスは、低レベルのプロトコルの指定によって詳細に指定されるため、ここでは不特定のままにされています。低いレベルがIPである場合、TCP実装が使用する可能性のあるパラメーター値の一部に注意します。
The following functional description of user commands to the TCP implementation 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 TCP implementations 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実装に必要な機能インターフェイスを指定します。
Section 3.1 of [53] also identifies primitives provided by TCP and could be used as an additional reference for implementers.
[53]のセクション3.1は、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.
次のセクションは、ユーザー/TCPインターフェイスを機能的に特徴付けます。使用される表記は、高レベルの言語でのほとんどの手順または関数呼び出しに似ていますが、この使用法はTRAPタイプのサービスコールを除外することを意図したものではありません。
The user commands described below specify the basic functions the TCP implementation 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実装が実行する必要がある基本的な機能を指定します。個々の実装は、独自の正確な形式を定義する必要があり、単一呼び出しで基本関数の組み合わせまたはサブセットを提供する場合があります。特に、一部の実装では、特定の接続に対してユーザーが発行した最初の送信時に接続を自動的に開くことをお勧めします。
In providing interprocess communication facilities, the TCP implementation 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 remote socket).
(a) 接続に関する一般的な情報（例：割り込み、リモートクローズ、不特定のリモートソケットのバインディング）。
(b) replies to specific user commands indicating success or various types of failure.
(b) 成功またはさまざまな種類の失敗を示す特定のユーザーコマンドへの返信。
Format: OPEN (local port, remote socket, active/passive [, timeout]
[, Diffserv field] [, security/compartment] [, local IP address] [,
options]) -> local connection name
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 remote socket to wait for a particular connection or an unspecified remote socket to wait for any call. A fully specified passive call can be made active by the subsequent execution of a SEND.
アクティブ/パッシブフラグがパッシブに設定されている場合、これは着信接続を聞くための呼び出しです。パッシブオープンには、特定の接続を待つために完全に指定されたリモートソケットがあるか、不特定のリモートソケットが通話を待つことができます。完全に指定されたパッシブコールは、その後の送信の実行によりアクティブにすることができます。
A transmission control block (TCB) is created and partially filled in with data from the OPEN command parameters.
トランスミッションコントロールブロック（TCB）が作成され、オープンコマンドパラメーターのデータが部分的に埋められます。
Every passive OPEN call either creates a new connection record in LISTEN state, or it returns an error; it MUST NOT affect any previously created connection record (MUST-41).
すべてのパッシブオープンコールは、リッスン状態で新しい接続レコードを作成するか、エラーを返します。以前に作成された接続レコード（必須41）に影響を与えてはなりません。
A TCP implementation that supports multiple concurrent connections MUST provide an OPEN call that will functionally allow an application to LISTEN on a port while a connection block with the same local port is in SYN-SENT or SYN-RECEIVED state (MUST-42).
複数の並行接続をサポートするTCP実装は、同じローカルポートを持つ接続ブロックがSyn-SentまたはSyn-Received状態（必見）である間、アプリケーションがポートで機能的にリスニングできるようにするオープンコールを提供する必要があります。
On an active OPEN command, the TCP endpoint will begin the procedure to synchronize (i.e., establish) the connection at once.
アクティブなオープンコマンドで、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 endpoint will abort the connection. The present global default is five minutes.
タイムアウトは、存在する場合、TCPに送信されたすべてのデータのタイムアウトを発信者に設定することを許可します。データがタイムアウト期間内に宛先に正常に配信されない場合、TCPエンドポイントは接続を中止します。現在のグローバルデフォルトは5分です。
The TCP implementation or some component of the operating system will verify the user's authority to open a connection with the specified Diffserv field value or security/compartment. The absence of a Diffserv field value or security/compartment specification in the OPEN call indicates the default values must be used.
TCP実装またはオペレーティングシステムの一部のコンポーネントは、指定されたdiffservフィールド値またはセキュリティ/コンパートメントとの接続を開くというユーザーの権限を検証します。オープンコールにdiffservフィールド値またはセキュリティ/コンパートメントの仕様がないことは、デフォルト値を使用する必要があることを示します。
TCP will accept incoming requests as matching only if the security/ compartment information is exactly the same as that requested in the OPEN call.
TCPは、セキュリティ/コンパートメント情報がオープンコールで要求されているものとまったく同じ場合にのみ、着信要求を一致するものとして受け入れます。
The Diffserv field value indicated by the user only impacts outgoing packets, may be altered en route through the network, and has no direct bearing or relation to received packets.
ユーザーが示すdiffservフィールド値は、発信パケットにのみ影響を与え、ネットワークを通過する途中で変更される場合があり、受信したパケットへの直接的なベアリングや関係はありません。
A local connection name will be returned to the user by the TCP implementation. The local connection name can then be used as a shorthand term for the connection defined by the <local socket, remote socket> pair.
TCP実装により、ローカル接続名がユーザーに返されます。ローカル接続名は、<ローカルソケット、リモートソケット>ペアで定義された接続の速記用語として使用できます。
The optional "local IP address" parameter MUST be supported to allow the specification of the local IP address (MUST-43). This enables applications that need to select the local IP address used when multihoming is present.
オプションの「ローカルIPアドレス」パラメーターをサポートして、ローカルIPアドレスの指定を許可する必要があります（必須）。これにより、マルチホミングが存在するときに使用されるローカルIPアドレスを選択する必要があるアプリケーションが可能になります。
A passive OPEN call with a specified "local IP address" parameter will await an incoming connection request to that address. If the parameter is unspecified, a passive OPEN will await an incoming connection request to any local IP address and then bind the local IP address of the connection to the particular address that is used.
指定された「ローカルIPアドレス」パラメーターを使用したパッシブオープンコールは、そのアドレスへの着信接続要求を待ちます。パラメーターが不特定の場合、受動的なオープンは、ローカルIPアドレスへの着信接続要求を待っており、使用されている特定のアドレスに接続のローカルIPアドレスをバインドします。
For an active OPEN call, a specified "local IP address" parameter will be used for opening the connection. If the parameter is unspecified, the host will choose an appropriate local IP address (see RFC 1122, Section 3.3.4.2).
アクティブなオープンコールの場合、指定された「ローカルIPアドレス」パラメーターが接続を開くために使用されます。パラメーターが不特定の場合、ホストは適切なローカルIPアドレスを選択します（RFC 1122、セクション3.3.4.2を参照）。
If an application on a multihomed host does not specify the local IP address when actively opening a TCP connection, then the TCP implementation MUST ask the IP layer to select a local IP address before sending the (first) SYN (MUST-44). See the function GET_SRCADDR() in Section 3.4 of RFC 1122.
マルチホームホストのアプリケーションがTCP接続を積極的に開くときにローカルIPアドレスを指定していない場合、TCP実装は（最初の）syn（必見）を送信する前に、IPレイヤーにローカルIPアドレスを選択するように依頼する必要があります。RFC 1122のセクション3.4の関数get_srcaddr（）を参照してください。
At all other times, a previous segment has either been sent or received on this connection, and TCP implementations MUST use the same local address that was used in those previous segments (MUST-45).
他のすべての場合、以前のセグメントはこの接続で送信または受信されており、TCPの実装は、これらの以前のセグメントで使用された同じローカルアドレス（必須45）を使用する必要があります。
A TCP implementation MUST reject as an error a local OPEN call for an invalid remote IP address (e.g., a broadcast or multicast address) (MUST-46).
TCP実装は、無効なリモートIPアドレス（放送またはマルチキャストアドレスなど）のローカルオープンコール（必見）のローカルオープンコールとして拒否する必要があります。
Format: SEND (local connection name, buffer address, byte count, URGENT flag [, PUSH flag] [, timeout])
フォーマット：送信（ローカル接続名、バッファアドレス、バイトカウント、緊急フラグ[、プッシュフラグ] [、タイムアウト]）
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. For example, this might be one way for application data to be included in SYN segments. If the calling process is not authorized to use this connection, an error is returned.
この呼び出しにより、指定されたユーザーバッファに含まれるデータが指定された接続で送信されます。接続が開かれていない場合、送信はエラーと見なされます。いくつかの実装では、ユーザーが最初に送信できる場合があります。その場合、自動オープンが行われます。たとえば、これはアプリケーションデータをSynセグメントに含める1つの方法かもしれません。呼び出しプロセスがこの接続を使用することを許可されていない場合、エラーが返されます。
A TCP endpoint MAY implement PUSH flags on SEND calls (MAY-15). If PUSH flags are not implemented, then the sending TCP peer: (1) MUST NOT buffer data indefinitely (MUST-60), and (2) MUST set the PSH bit in the last buffered segment (i.e., when there is no more queued data to be sent) (MUST-61). The remaining description below assumes the PUSH flag is supported on SEND calls.
TCPエンドポイントは、送信コール（5月15日）にプッシュフラグを実装できます。プッシュフラグが実装されていない場合、送信TCPピア：（1）データを無期限にバッファリターにバッファリター（必須）、（2）最後のバッファーセグメントにPSHビットを設定する必要があります（つまり、これ以上キューがない場合送信されるデータ）（必見）。以下の残りの説明は、送信コールでプッシュフラグがサポートされていると想定しています。
If the PUSH flag is set, the application intends the data to be transmitted promptly to the receiver, and the PSH bit will be set in the last TCP segment created from the buffer.
プッシュフラグが設定されている場合、アプリケーションはデータを迅速に受信機に送信することを意図し、PSHビットはバッファから作成された最後のTCPセグメントに設定されます。
The PSH bit is not a record marker and is independent of segment boundaries. The transmitter SHOULD collapse successive bits when it packetizes data, to send the largest possible segment (SHLD-27).
PSHビットはレコードマーカーではなく、セグメントの境界から独立しています。トランスミッターは、データを梱包するときに連続したビットを崩壊させ、可能な限り最大のセグメント（SHLD-27）を送信する必要があります。
If the PUSH flag is not set, the data may be combined with data from subsequent SENDs for transmission efficiency. When an application issues a series of SEND calls without setting the PUSH flag, the TCP implementation MAY aggregate the data internally without sending it (MAY-16). Note that when the Nagle algorithm is in use, TCP implementations may buffer the data before sending, without regard to the PUSH flag (see Section 3.7.4).
プッシュフラグが設定されていない場合、データは、送信効率のために後続の送信からのデータと組み合わせることができます。アプリケーションがプッシュフラグを設定せずに一連の送信コールを発行すると、TCP実装はデータを送信せずに内部的に集約する場合があります（5月16日）。Nagleアルゴリズムが使用されている場合、TCP実装は、プッシュフラグに関係なく送信前にデータをバッファリングする可能性があることに注意してください（セクション3.7.4を参照）。
An application program is logically required to set the PUSH flag in a SEND call whenever it needs to force delivery of the data to avoid a communication deadlock. However, a TCP implementation SHOULD send a maximum-sized segment whenever possible (SHLD-28) to improve performance (see Section 3.8.6.2.1).
アプリケーションプログラムは、通信デッドロックを避けるためにデータの配信を強制する必要がある場合はいつでも、送信コールにプッシュフラグを設定するために論理的に必要です。ただし、TCPの実装では、可能な限り最大サイズのセグメントを送信して（SHLD-28）、パフォーマンスを改善する必要があります（セクション3.8.6.2.1を参照）。
New applications SHOULD NOT set the URGENT flag [39] due to implementation differences and middlebox issues (SHLD-13).
新しいアプリケーションは、実装の違いとミドルボックスの問題（SHLD-13）のために、緊急フラグ[39]を設定する必要はありません。
If the URGENT flag is set, segments sent to the destination TCP peer will have the urgent pointer set. The receiving TCP peer 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 the URGENT flag 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 implementation 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 remote socket was specified in the OPEN, but the connection is established (e.g., because a LISTENing connection has become specific due to a remote segment arriving for the local socket), then the designated buffer is sent to the implied remote socket. Users who make use of OPEN with an unspecified remote socket can make use of SEND without ever explicitly knowing the remote socket address.
オープンでリモートソケットが指定されていないが、接続が確立されている場合（たとえば、ローカルソケットに到着するリモートセグメントのためにリスニング接続が固有になっているため）、指定されたバッファーが暗黙のリモートソケットに送信されます。不特定のリモートソケットを使用してOpenを使用するユーザーは、リモートソケットアドレスを明示的に知ることなく、送信を利用できます。
However, if a SEND is attempted before the remote socket becomes specified, an error will be returned. Users can use the STATUS call to determine the status of the connection. Some TCP implementations may notify the user when an unspecified socket is bound.
ただし、リモートソケットが指定される前に送信が試行された場合、エラーが返されます。ユーザーはステータスコールを使用して、接続のステータスを決定できます。一部の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 endpoint will queue those it cannot service immediately.
最も単純な実装では、送信は送信が完了するか、タイムアウトが超えるまで送信プロセスに制御を返さないでしょう。ただし、この単純な方法は、デッドロックの影響を受けます（たとえば、接続の両側は受信する前に送信を試みる可能性があります）、パフォーマンスが低いため、推奨されません。より洗練された実装はすぐに戻ってきて、プロセスがネットワークI/Oと同時に実行できるようにし、さらに、複数の送信が進行中のことを可能にします。複数の送信が最初に提供され、最初に提供される注文で提供されるため、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 endpoint. 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 endpoint. 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.
私たちは、Sendが後でサービングTCPエンドポイントから何らかの信号または擬似インターデントを誘発する非同期ユーザーインターフェイスを暗黙的に想定しています。別の方法は、すぐに応答を返すことです。たとえば、送信されたセグメントが遠い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 that should be returned to the calling process.
プロセスが異なるセンドのエラーまたは成功指示を区別するためには、送信要求に対するコード化された応答とともにバッファーアドレスが返されるのが適切かもしれません。TCPからユーザーの信号については以下で説明し、呼び出しプロセスに返すべき情報を示します。
Format: RECEIVE (local connection name, buffer address, byte count) -> byte count, URGENT flag [, PUSH flag]
フォーマット：受信（ローカル接続名、バッファアドレス、バイトカウント） - >バイトカウント、緊急フラグ[、プッシュフラグ]
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.
最も単純な実装では、コントロールはバッファが充填されるか、何らかのエラーが発生するまで呼び出しプログラムに戻りませんが、このスキームはデッドロックの影響を非常に受けます。より洗練された実装により、いくつかの受信者が一度に傑出していることができます。セグメントが到着すると、これらは埋められます。この戦略により、より精巧なスキーム（おそらく非同期）のコストでスループットが増加し、プッシュが見られたかバッファーが満たされていることを通知プログラムに通知することができます。
A TCP receiver MAY pass a received PSH bit to the application layer via the PUSH flag in the interface (MAY-17), but it is not required (this was clarified in RFC 1122, Section 4.2.2.2). The remainder of text describing the RECEIVE call below assumes that passing the PUSH indication is supported.
TCPレシーバーは、受信したPSHビットをインターフェイスのプッシュフラグ（5月17日）を介してアプリケーションレイヤーに渡すことができますが、必要ありません（これはRFC 1122、セクション4.2.2.2で明確にされました）。以下の受信コールを説明する残りのテキストは、プッシュ表示に合格することがサポートされていると仮定しています。
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.
プッシュが表示される前にバッファーを埋めるのに十分なデータが到着した場合、プッシュフラグは受信への応答に設定されません。バッファーには、保持できる限りのデータが満たされます。バッファが充填される前にプッシュが表示されると、バッファーが部分的に満たされ、プッシュが示されます。
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 preceding urgent data unless the boundary is clearly marked for the user.
緊急のデータがある場合、ユーザーはTCPからユーザーへの信号を介して到着するとすぐに通知されます。したがって、受信ユーザーは「緊急モード」にある必要があります。緊急のフラグが点灯している場合、追加の緊急データは残ります。緊急のフラグがオフになった場合、この呼び出しを受けるという呼び出しはすべての緊急データを返し、ユーザーは「緊急モード」を離れることがあります。緊急ポインター（非緊急データ）に続くデータは、ユーザーに境界が明確にマークされていない限り、前の緊急データを持つ同じバッファーでユーザーに配信できないことに注意してください。
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 endpoint allocate buffer storage, or the TCP endpoint might share a ring buffer with the user.
受信の代替実装により、TCPエンドポイントがバッファストレージを割り当てるか、TCPエンドポイントがユーザーとリングバッファーを共有する場合があります。
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 remote peer 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 peer gives up.
このコマンドにより、指定された接続が閉じられます。接続が開かれていない場合、または呼び出しプロセスがこの接続を使用することを許可されていない場合、エラーが返されます。クロージング接続は、すべてがサービスが提供されるまで、フロー制御が許可されているように、未解決の送信が送信される（および再送信）という意味で優雅な操作になることを目的としています。したがって、いくつかの送信コールを行い、その後に終了し、すべてのデータが宛先に送信されることを期待することは許容されるはずです。また、リモートピアがデータの最後のデータを送信しようとしている可能性があるため、ユーザーが接続の閉鎖時に引き続き受信する必要があることも明らかです。したがって、近いことは「私はこれ以上送る必要はありません」が、「もう受け取らない」という意味ではありません。（ユーザーレベルのプロトコルが十分に考えられていない場合）、閉鎖側がタイミングを出す前にすべてのデータを取り除くことができないことが発生する可能性があります。この場合、クローズは中止になり、閉鎖TCPピアはあきらめます。
The user may CLOSE the connection at any time on their own initiative, or in response to various prompts from the TCP implementation (e.g., remote close executed, transmission timeout exceeded, destination inaccessible).
ユーザーは、自分のイニシアチブでいつでも接続を閉じることができます。または、TCP実装からのさまざまなプロンプト（例：リモートクローズ実行、送信タイムアウトが超え、宛先がアクセスできない）に応じて閉じることができます。
Because closing a connection requires communication with the remote TCP peer, connections may remain in the closing state for a short time. Attempts to reopen the connection before the TCP peer replies to the CLOSE command will result in error responses.
接続を閉じるには、リモートTCPピアとの通信が必要なため、接続は短時間で終了状態にとどまることがあります。TCPピアが緊密なコマンドに返信する前に接続を再開しようとすると、エラー応答が発生します。
Close also implies push function.
閉じることは、プッシュ機能も意味します。
Format: STATUS (local connection name) -> status data
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,
ローカルソケット、
remote socket,
リモートソケット、
local connection name,
ローカル接続名、
receive window,
ウィンドウを受け取る、
send window,
ウィンドウを送信し、
connection state,
接続状態、
number of buffers awaiting acknowledgment,
謝辞を待っているバッファーの数、
number of buffers pending receipt,
保留中のバッファーの数、
urgent state,
緊急の状態、
Diffserv field value,
Diffservフィールド値、
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.
接続の状態、または実装自体に応じて、この情報の一部は利用可能でも意味がない場合があります。呼び出しプロセスがこの接続を使用することを許可されていない場合、エラーが返されます。これにより、不正なプロセスが接続に関する情報を得ることができなくなります。
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 RST message to be sent to the remote TCP peer 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.
このコマンドにより、すべての保留中の送信および受信が中止され、TCBが削除され、接続のリモートTCPピアに送信される特別なRSTメッセージが削除されます。実装に応じて、ユーザーは、発行済みの送信または受信ごとに中止された適応症を受け取ることができます。また、単に中断の承認を受け取ることもできます。
Some TCP implementations have included a FLUSH call, which will empty the TCP send queue of any data that the user has issued SEND calls for but is still to the right of the current send window. That is, it flushes as much queued send data as possible without losing sequence number synchronization. The FLUSH call MAY be implemented (MAY-14).
一部のTCP実装にはフラッシュコールが含まれています。これにより、ユーザーが発行したデータのTCP送信キューが空になりますが、現在の送信ウィンドウの右側にあります。つまり、シーケンス番号の同期を失うことなく、できるだけ多くのキューに囲まれた送信データを洗い流します。フラッシュコールが実装される場合があります（5月14日）。
There MUST be a mechanism for reporting soft TCP error conditions to the application (MUST-47). Generically, we assume this takes the form of an application-supplied ERROR_REPORT routine that may be upcalled asynchronously from the transport layer:
ソフトTCPエラー条件をアプリケーションに報告するメカニズムが必要です（必須）。一般的に、これは、輸送層から非同期にアップコールされる可能性のあるアプリケーションがサプライされたerror_reportルーチンの形をとると仮定します。
ERROR_REPORT(local connection name, reason, subreason)
ERROR_REPORT（ローカル接続名、理由、サブリーシーズン）
The precise encoding of the reason and subreason parameters is not specified here. However, the conditions that are reported asynchronously to the application MUST include:
ここでは、理由とサブリーズンパラメーターの正確なエンコーディングとサブリーズンパラメーターは指定されていません。ただし、アプリケーションに非同期に報告されている条件には、以下が含まれている必要があります。
* ICMP error message arrived (see Section 3.9.2.2 for description of handling each ICMP message type since some message types need to be suppressed from generating reports to the application)
* ICMPエラーメッセージが届きました（各ICMPメッセージタイプの処理の説明については、セクション3.9.2.2を参照
* Excessive retransmissions (see Section 3.8.3)
* 過度の再送信（セクション3.8.3を参照）
* Urgent pointer advance (see Section 3.8.5)
* 緊急のポインターの前進（セクション3.8.5を参照）
However, an application program that does not want to receive such ERROR_REPORT calls SHOULD be able to effectively disable these calls (SHLD-20).
ただし、そのようなERROR_REPORT呼び出しを受信したくないアプリケーションプログラムは、これらの呼び出しを効果的に無効にすることができるはずです（SHLD-20）。
3.9.1.9. Set Differentiated Services Field (IPv4 TOS or IPv6 Traffic Class)
3.9.1.9. 差別化されたサービスフィールド（IPv4 TOSまたはIPv6トラフィッククラス）を設定します
The application layer MUST be able to specify the Differentiated Services field for segments that are sent on a connection (MUST-48). The Differentiated Services field includes the 6-bit Differentiated Services Codepoint (DSCP) value. It is not required, but the application SHOULD be able to change the Differentiated Services field during the connection lifetime (SHLD-21). TCP implementations SHOULD pass the current Differentiated Services field value without change to the IP layer, when it sends segments on the connection (SHLD-22).
アプリケーションレイヤーは、接続で送信されるセグメントの差別化されたサービスフィールドを指定できる必要があります（必須）。差別化されたサービスフィールドには、6ビット差別化されたサービスコードポイント（DSCP）値が含まれます。必須ではありませんが、アプリケーションは、接続寿命（SHLD-21）の間に差別化されたサービスフィールドを変更できるはずです。TCP実装は、接続にセグメントを送信するときに、IPレイヤーを変更せずに現在の差別化されたサービスフィールド値を渡す必要があります（SHLD-22）。
The Differentiated Services field will be specified independently in each direction on the connection, so that the receiver application will specify the Differentiated Services field used for ACK segments.
差別化されたサービスフィールドは、接続の各方向に個別に指定され、受信機アプリケーションがACKセグメントに使用される差別化されたサービスフィールドを指定します。
TCP implementations MAY pass the most recently received Differentiated Services field up to the application (MAY-9).
TCP実装は、最近受け取った差別化されたサービスフィールドをアプリケーションまで渡すことができます（5月9日）。
The TCP endpoint calls on a lower-level protocol module to actually send and receive information over a network. The two current standard Internet Protocol (IP) versions layered below TCP are IPv4 [1] and IPv6 [13].
TCPエンドポイントは、低レベルのプロトコルモジュールで、ネットワークを介して実際に情報を送信および受信するよう呼びます。TCPの下に階層化された2つの現在の標準インターネットプロトコル（IP）バージョンは、IPv4 [1]とIPv6 [13]です。
If the lower-level protocol is IPv4, it provides arguments for a type of service (used within the Differentiated Services field) and for a time to live. TCP uses the following settings for these parameters:
低レベルのプロトコルがIPv4の場合、タイプのサービス（差別化されたサービスフィールド内で使用）としばらくの間、ライブの引数を提供します。TCPは、これらのパラメーターに次の設定を使用します。
Diffserv field: The IP header value for the Diffserv field is given by the user. This includes the bits of the Diffserv Codepoint (DSCP).
DiffServフィールド：DiffServフィールドのIPヘッダー値は、ユーザーによって与えられます。これには、DiffServ CodePoint（DSCP）のビットが含まれます。
Time to Live (TTL): The TTL value used to send TCP segments MUST be configurable (MUST-49).
Time to Live（TTL）：TCPセグメントの送信に使用されるTTL値は、構成可能でなければなりません（必須）。
* Note that RFC 793 specified one minute (60 seconds) as a constant for the TTL because the assumed maximum segment lifetime was two minutes. This was intended to explicitly ask that a segment be destroyed if it could not be delivered by the internet system within one minute. RFC 1122 updated RFC 793 to require that the TTL be configurable.
* RFC 793は、想定される最大セグメント寿命が2分であったため、TTLの定数として1分（60秒）を指定したことに注意してください。これは、1分以内にインターネットシステムによって配信できない場合、セグメントを破壊することを明示的に求めることを目的としていました。RFC 1122がRFC 793を更新して、TTLを構成可能にすることを要求しました。
* Note that the Diffserv field is permitted to change during a connection (Section 4.2.4.2 of RFC 1122). However, the application interface might not support this ability, and the application does not have knowledge about individual TCP segments, so this can only be done on a coarse granularity, at best. This limitation is further discussed in RFC 7657 (Sections 5.1, 5.3, and 6) [50]. Generally, an application SHOULD NOT change the Diffserv field value during the course of a connection (SHLD-23).
* DifFServフィールドは、接続中に変更が許可されていることに注意してください（RFC 1122のセクション4.2.4.2）。ただし、アプリケーションインターフェイスはこの能力をサポートしていない可能性があり、アプリケーションには個々のTCPセグメントに関する知識がないため、これはせいぜい粗い粒度でのみ行うことができます。この制限については、RFC 7657（セクション5.1、5.3、および6）でさらに説明します[50]。一般に、アプリケーションは、接続の過程でDiffServフィールド値を変更してはなりません（SHLD-23）。
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 equivalent service of IP and to be used in the TCP checksum.
低レベルのプロトコルは、ソースアドレス、宛先アドレス、およびプロトコルフィールド、および「TCP長」を決定するための何らかの方法を提供する必要があります。
When received options are passed up to TCP from the IP layer, a TCP implementation MUST ignore options that it does not understand (MUST-50).
受信オプションがIPレイヤーからTCPに渡されると、TCP実装では、理解できないオプションを無視する必要があります（必須50）。
A TCP implementation MAY support the Timestamp (MAY-10) and Record Route (MAY-11) Options.
TCP実装は、タイムスタンプ（5月10日）およびレコードルート（5月11日）オプションをサポートする場合があります。
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チェックサムで使用されるソースと宛先アドレスが発信元のソースと最終目的地になるようにします。また、接続リクエストに応答するためにリターンルートを保持することも重要です。
An application MUST be able to specify a source route when it actively opens a TCP connection (MUST-51), and this MUST take precedence over a source route received in a datagram (MUST-52).
アプリケーションは、TCP接続（必須51）を積極的に開くときにソースルートを指定できる必要があり、これはデータグラム（必須52）で受信したソースルートよりも優先する必要があります。
When a TCP connection is OPENed passively and a packet arrives with a completed IP Source Route Option (containing a return route), TCP implementations MUST save the return route and use it for all segments sent on this connection (MUST-53). If a different source route arrives in a later segment, the later definition SHOULD override the earlier one (SHLD-24).
TCP接続が受動的に開かれ、完成したIPソースルートオプション（戻りルートを含む）でパケットが到着すると、TCP実装は戻りルートを保存し、この接続に送信されるすべてのセグメントに使用する必要があります（必須53）。別のソースルートが後のセグメントに到着した場合、後の定義は以前のセグメント（SHLD-24）をオーバーライドする必要があります。
TCP implementations MUST act on an ICMP error message passed up from the IP layer, directing it to the connection that created the error (MUST-54). The necessary demultiplexing information can be found in the IP header contained within the ICMP message.
TCP実装は、IPレイヤーから渡されたICMPエラーメッセージに基づいて動作し、エラーを作成した接続に向けています（必須54）。必要な非複数の情報は、ICMPメッセージに含まれるIPヘッダーに記載されています。
This applies to ICMPv6 in addition to IPv4 ICMP.
これは、IPv4 ICMPに加えてICMPv6に適用されます。
[35] contains discussion of specific ICMP and ICMPv6 messages classified as either "soft" or "hard" errors that may bear different responses. Treatment for classes of ICMP messages is described below:
[35] 異なる応答を負担する可能性のある「ソフト」または「ハード」エラーとして分類された特定のICMPおよびICMPV6メッセージの議論が含まれています。ICMPメッセージのクラスの治療を以下に説明します。
Source Quench TCP implementations MUST silently discard any received ICMP Source Quench messages (MUST-55). See [11] for discussion.
ソースクエンチTCP実装は、受信したICMPソースクエンチメッセージ（必須55）を静かに破棄する必要があります。ディスカッションについては[11]を参照してください。
Soft Errors For IPv4 ICMP, these include: Destination Unreachable -- codes 0, 1, 5; Time Exceeded -- codes 0, 1; and Parameter Problem.
IPv4 ICMPのソフトエラー、これらには次のものが含まれます。時間を超えた - コード0、1;およびパラメーターの問題。
For ICMPv6, these include: Destination Unreachable -- codes 0, 3; Time Exceeded -- codes 0, 1; and Parameter Problem -- codes 0, 1, 2.
ICMPv6の場合、これらには次のものが含まれます。時間を超えた - コード0、1;およびパラメーターの問題 - コード0、1、2。
Since these Unreachable messages indicate soft error conditions, a TCP implementation MUST NOT abort the connection (MUST-56), and it SHOULD make the information available to the application (SHLD-25).
これらの到達不可能なメッセージはソフトエラー条件を示しているため、TCP実装は接続を中止してはなりません（必須56）。アプリケーションで情報を利用できるようにする必要があります（SHLD-25）。
Hard Errors For ICMP these include Destination Unreachable -- codes 2-4.
ICMPのハードエラーこれらには、到達不可能な宛先 - コード2-4が含まれます。
These are hard error conditions, so TCP implementations SHOULD abort the connection (SHLD-26). [35] notes that some implementations do not abort connections when an ICMP hard error is received for a connection that is in any of the synchronized states.
これらはハードエラー条件であるため、TCPの実装は接続を中止する必要があります（SHLD-26）。[35]は、同期された状態のいずれかにある接続に対してICMPハードエラーを受信した場合、一部の実装は接続を中止しないことに注意してください。
Note that [35], Section 4 describes widespread implementation behavior that treats soft errors as hard errors during connection establishment.
[35]、セクション4では、接続確立中にソフトエラーをハードエラーとして扱う広範な実装動作について説明しています。
RFC 1122 requires addresses to be validated in incoming SYN packets:
RFC 1122では、着信シンパケットでアドレスを検証する必要があります。
| An incoming SYN with an invalid source address MUST be ignored
| either by TCP or by the IP layer [(MUST-63)] (see
| Section 3.2.1.3).
|
| A TCP implementation MUST silently discard an incoming SYN segment
| that is addressed to a broadcast or multicast address [(MUST-57)].
This prevents connection state and replies from being erroneously generated, and implementers should note that this guidance is applicable to all incoming segments, not just SYNs, as specifically indicated in RFC 1122.
これにより、接続状態が防止され、返信が誤って生成され、実装者は、RFC 1122で具体的に示されているように、このガイダンスがSynだけでなく、すべての着信セグメントに適用できることに注意する必要があります。
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.
このセクションに描かれている処理は、1つの可能な実装の例です。他の実装にはわずかに異なる処理シーケンスがある場合がありますが、実質的ではなく、このセクションのものとは詳細に異なるはずです。
The activity of the TCP endpoint 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 endpoint does in response to each of the events. In many cases, the processing required depends on the state of the connection.
TCPエンドポイントのアクティビティは、イベントに応答するものとして特徴付けます。発生するイベントは、ユーザー呼び出し、到着セグメント、タイムアウトの3つのカテゴリにキャストできます。このセクションでは、各イベントに応じて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 in this document are identified by 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).
以下では、シーケンス番号、謝辞番号、Windowsなどのすべての算術がModulo 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 connection stays in the same state.
状態の変更が言及されていない場合、TCP接続は同じ状態にとどまることに注意してください。
CLOSED STATE (i.e., TCB does not exist)
閉じた状態（つまり、TCBは存在しません）
* Create a new transmission control block (TCB) to hold connection state information. Fill in local socket identifier, remote socket, Diffserv field, security/compartment, and user timeout information. Note that some parts of the remote 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 Diffserv value requested are allowed for this user, if not, return "error: Diffserv value not allowed" or "error: security/ compartment not allowed". If passive, enter the LISTEN state and return. If active and the remote socket is unspecified, return "error: remote socket unspecified"; if active and the remote 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）を作成します。ローカルソケット識別子、リモートソケット、Diffservフィールド、セキュリティ/コンパートメント、およびユーザータイムアウト情報を入力します。リモートソケットの一部は、受動的なオープンでは不特定であり、着信Synセグメントのパラメーターによって埋められることに注意してください。要求されたセキュリティとdiffservの値が許可されていることを確認します。このユーザーは、「エラー：許可されていないdiffserv値」または「エラー：セキュリティ/コンパートメントが許可されていない」を返します。パッシブの場合は、リスニング状態を入力して戻ります。アクティブおよびリモートソケットが不特定の場合、「エラー：リモートソケットが不特定」を返します。アクティブソケットとリモートソケットが指定されている場合は、Synセグメントを発行します。初期送信シーケンス番号（ISS）が選択されています。フォーム<seq = iss> <ctl = syn>のsynセグメントが送信されます。snd.unaをISSに設定し、snd.nxtをISS 1に設定し、Syn-Sent Stateを入力し、戻ります。
* 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
状態を聞いてください
* If the OPEN call is active and the remote 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 the remote socket was not specified, then return "error: remote socket unspecified".
* オープンコールがアクティブで、リモートソケットが指定されている場合は、接続をパッシブからアクティブに変更します。ISSを選択します。Synセグメントを送信し、snd.unaをISSに、snd.nxtにISS 1に設定します。Syn-Sent Stateを入力します。送信に関連するデータは、Synセグメントで送信されるか、確立された状態に入った後に送信のためにキューに送信される場合があります。コマンドで要求された場合の緊急ビットは、このコマンドの結果として送信されたデータセグメントで送信する必要があります。リクエストをキューする余地がない場合は、「エラー：リソース不足」で応答します。リモートソケットが指定されていない場合は、「エラー：リモートソケットが不特定」を返します。
SYN-SENT STATE
Syn-Sent状態
SYN-RECEIVED STATE
同期された状態
ESTABLISHED STATE
確立された状態
FIN-WAIT-1 STATE
FIN-WAIT-1状態
FIN-WAIT-2 STATE
Fin-Wait-2状態
CLOSE-WAIT STATE
密閉状態
CLOSING STATE
閉鎖状態
LAST-ACK STATE
ラストクック状態
TIME-WAIT STATE
タイムウェイト状態
* Return "error: connection already exists".
* 「エラー：接続は既に存在する」を返します。
CLOSED STATE (i.e., TCB does not exist)
閉じた状態（つまり、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
状態を聞いてください
* If the remote 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 the remote socket was not specified, then return "error: remote socket unspecified".
* リモートソケットが指定されている場合は、接続をパッシブからアクティブに変更します。ISSを選択します。Synセグメントを送信し、snd.unaをISSに、snd.nxtにISS 1に設定します。Syn-Sent Stateを入力します。送信に関連するデータは、Synセグメントで送信されるか、確立された状態に入った後に送信のためにキューに送信される場合があります。コマンドで要求された場合の緊急ビットは、このコマンドの結果として送信されたデータセグメントで送信する必要があります。リクエストをキューする余地がない場合は、「エラー：リソース不足」で応答します。リモートソケットが指定されていない場合は、「エラー：リモートソケットが不特定」を返します。
SYN-SENT STATE
Syn-Sent状態
SYN-RECEIVED STATE
同期された状態
* Queue the data for transmission after entering ESTABLISHED state. If no space to queue, respond with "error: insufficient resources".
* 確立された状態に入った後、送信のデータをキューにします。キューするスペースがない場合は、「エラー：リソース不足」で応答します。
ESTABLISHED STATE
確立された状態
CLOSE-WAIT STATE
密閉状態
* 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 and set the urgent pointer in the outgoing segments.
* 緊急フラグが設定されている場合は、snd.up <-nd.nxtを設定し、発信セグメントに緊急ポインターを設定します。
FIN-WAIT-1 STATE
FIN-WAIT-1状態
FIN-WAIT-2 STATE
Fin-Wait-2状態
CLOSING STATE
閉鎖状態
LAST-ACK STATE
ラストクック状態
TIME-WAIT STATE
タイムウェイト状態
* Return "error: connection closing" and do not service request.
* 「エラー：接続閉鎖」を返し、リクエストをサービスしないでください。
CLOSED STATE (i.e., TCB does not exist)
閉じた状態（つまり、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
状態を聞いてください
SYN-SENT STATE
Syn-Sent状態
SYN-RECEIVED STATE
同期された状態
* Queue for processing after entering ESTABLISHED state. If there is no room to queue this request, respond with "error: insufficient resources".
* 確立された状態に入った後の処理のためのキュー。このリクエストをキューする余地がない場合は、「エラー：リソース不足」で応答します。
ESTABLISHED STATE
確立された状態
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".
* リクエストを満たすために入力セグメントがキューになっていない場合は、リクエストをキューにします。受信を覚えるキュースペースがない場合は、「エラー：リソース不足」で応答します。
* Reassemble queued incoming segments into receive buffer and return to user. Mark "push seen" (PUSH) if this is the case.
* キューのある入っているセグメントを再組み立てして、バッファーを受信してユーザーに戻します。これが当てはまる場合は、「プッシュが見られた」（プッシュ）（プッシュ）をマークしてください。
* 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 endpoint 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
密閉状態
* Since the remote side has already sent FIN, RECEIVEs must be satisfied by data already on hand, but not yet delivered to the user. If no text is awaiting delivery, the RECEIVE will get an "error: connection closing" response. Otherwise, any remaining data can be used to satisfy the RECEIVE.
* リモート側はすでにFINを送信しているため、受信はすでに手元にあるデータによって満たされなければなりませんが、まだユーザーに配信されていません。テキストが配信を待っていない場合、受信は「エラー：接続クロージング」応答を取得します。それ以外の場合、残りのデータを使用して受信を満たすことができます。
CLOSING STATE
閉鎖状態
LAST-ACK STATE
ラストクック状態
TIME-WAIT STATE
タイムウェイト状態
* Return "error: connection closing".
* 「エラー：接続閉鎖」を返します。
CLOSED STATE (i.e., TCB does not exist)
閉じた状態（つまり、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
状態を聞いてください
* Any outstanding RECEIVEs are returned with "error: closing" responses. Delete TCB, enter CLOSED state, and return.
* 未払いの受信は、「エラー：閉じる」応答で返されます。TCBを削除し、閉じた状態を入力して、戻ります。
SYN-SENT STATE
Syn-Sent状態
* Delete the TCB and return "error: closing" responses to any queued SENDs, or RECEIVEs.
* TCBを削除して、「エラー：クロージング」応答を削除します。
SYN-RECEIVED STATE
同期された状態
* 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.
* 送信が発行されておらず、送信する保留中のデータがない場合は、FINセグメントを形成して送信し、Fin-Wait-1状態を入力します。それ以外の場合は、確立された状態に入った後の処理のためのキュー。
ESTABLISHED STATE
確立された状態
* 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.
* 先行するすべての送信がセグメント化されるまでこれをキューにしてから、フィンセグメントを形成して送信します。いずれにせよ、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 an "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).
* 厳密に言えば、これはエラーであり、「エラー：接続クロージング」応答を受信する必要があります。2番目のフィンが放出されない限り、「OK」応答も受け入れられます（ただし、最初のフィンが再送信される場合があります）。
CLOSE-WAIT STATE
密閉状態
* Queue this request until all preceding SENDs have been segmentized; then send a FIN segment, enter LAST-ACK state.
* 先行するすべての送信がセグメント化されるまで、この要求をキューにします。次に、FINセグメントを送信し、Last-ack Stateを入力します。
CLOSING STATE
閉鎖状態
LAST-ACK STATE
ラストクック状態
TIME-WAIT STATE
タイムウェイト状態
* Respond with "error: connection closing".
* 「エラー：接続閉鎖」で応答します。
CLOSED STATE (i.e., TCB does not exist)
閉じた状態（つまり、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
状態を聞いてください
* Any outstanding RECEIVEs should be returned with "error: connection reset" responses. Delete TCB, enter CLOSED state, and return.
* 未払いの受信は、「エラー：接続リセット」応答で返品する必要があります。TCBを削除し、閉じた状態を入力して、戻ります。
SYN-SENT STATE
Syn-Sent状態
* All queued SENDs and RECEIVEs should be given "connection reset" notification. Delete the TCB, enter CLOSED state, and return.
* すべてのキューに送信および受信するには、「接続リセット」通知を指定する必要があります。TCBを削除し、閉じた状態を入力して、戻ります。
SYN-RECEIVED STATE
同期された状態
ESTABLISHED STATE
確立された状態
FIN-WAIT-1 STATE
FIN-WAIT-1状態
FIN-WAIT-2 STATE
Fin-Wait-2状態
CLOSE-WAIT STATE
密閉状態
* 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.
* すべてのキューに送信および受信するには、「接続リセット」通知を指定する必要があります。送信用にキューに巻かれたすべてのセグメント（上記のRSTを除く）または再送信をフラッシュする必要があります。TCBを削除し、閉じた状態を入力して、戻ります。
CLOSING STATE
閉鎖状態
LAST-ACK STATE
ラストクック状態
TIME-WAIT STATE
タイムウェイト状態
* Respond with "ok" and delete the TCB, enter CLOSED state, and return.
* 「OK」で応答し、TCBを削除し、閉じた状態を入力して、返品します。
CLOSED STATE (i.e., TCB does not exist)
閉じた状態（つまり、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
状態を聞いてください
* Return "state = LISTEN" and the TCB pointer.
* 「state = listen」とTCBポインターを返します。
SYN-SENT STATE
Syn-Sent状態
* Return "state = SYN-SENT" and the TCB pointer.
* 「state = syn-sent」とTCBポインターを返します。
SYN-RECEIVED STATE
同期された状態
* Return "state = SYN-RECEIVED" and the TCB pointer.
* 「state = syn-received」とTCBポインターを返します。
ESTABLISHED STATE
確立された状態
* Return "state = ESTABLISHED" and the TCB pointer.
* 「状態=確立」とTCBポインターを返します。
FIN-WAIT-1 STATE
FIN-WAIT-1状態
* Return "state = FIN-WAIT-1" and the TCB pointer.
* 「state = fin-wait-1」とTCBポインターを返します。
FIN-WAIT-2 STATE
Fin-Wait-2状態
* Return "state = FIN-WAIT-2" and the TCB pointer.
* 「state = fin-wait-2」とTCBポインターを返します。
CLOSE-WAIT STATE
密閉状態
* Return "state = CLOSE-WAIT" and the TCB pointer.
* 「state = close-wait」とTCBポインターを返します。
CLOSING STATE
閉鎖状態
* Return "state = CLOSING" and the TCB pointer.
* 「state =閉鎖」とTCBポインターを返します。
LAST-ACK STATE
ラストクック状態
* Return "state = LAST-ACK" and the TCB pointer.
* 「state = last-ack」とTCBポインターを返します。
TIME-WAIT STATE
タイムウェイト状態
* Return "state = TIME-WAIT" and the TCB pointer.
* 「state = time-wait」とTCBポインターを返します。
If the state is CLOSED (i.e., TCB does not exist), then
状態が閉じている場合（つまり、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 endpoint 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
状態が耳を傾けている場合、
First, check for a RST:
まず、最初のことを確認してください：
- 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. An incoming RST should be ignored. Return.
- この接続のこの化身によって送信されたものに応じて送信できなかったため、着信のRSAGEMは有効ではありませんでした。着信Rは無視する必要があります。戻る。
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:
- 承認は、リッスン状態のまだ接続に到着した場合、悪いことです。到着する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=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
- 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 remote 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 data or control:
第四に、その他のデータまたはコントロール：
- This should not be reached. Drop the segment and return. Any other control or data-bearing segment (not containing SYN) must have an ACK and thus would have been discarded by the ACK processing in the second step, unless it was first discarded by RST checking in the first step.
- これに到達しないでください。セグメントをドロップして戻ります。他のコントロールまたはデータベアリングセグメント（Synを含む）にはACKが必要である必要があるため、最初のステップで最初に廃棄されない限り、2番目のステップでACK処理によって破棄されていました。
If the state is SYN-SENT, then
状態がsyn-sentの場合
First, check the ACK bit:
まず、ACKビットを確認してください。
- If the ACK bit is set,
- ACKビットが設定されている場合、
o 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)
o seg.ack = <issまたはseg.ack> snd.nxtの場合、リセットを送信します（RSTビットが設定されていない限り、セグメントをドロップして返す場合）
<SEQ=SEG.ACK><CTL=RST>
o and discard the segment. Return.
o セグメントを破棄します。戻る。
o If SND.UNA < SEG.ACK =< SND.NXT, then the ACK is acceptable. Some deployed TCP code has used the check SEG.ACK == SND.NXT (using "==" rather than "=<"), but this is not appropriate when the stack is capable of sending data on the SYN because the TCP peer may not accept and acknowledge all of the data on the SYN.
o snd.una <seg.ack = <snd.nxtの場合、ACKは許容されます。一部の展開されたTCPコードは、Check seg.ack == snd.nxt（「= <」ではなく「==」を使用）を使用していますが、TCPピアがSynでデータを送信できる場合、これは適切ではありませんSynのすべてのデータを受け入れて確認することはできません。
Second, check the RST bit:
第二に、最初のビットを確認してください：
- If the RST bit is set,
- 最初のビットが設定されている場合、
o A potential blind reset attack is described in RFC 5961 [9]. The mitigation described in that document has specific applicability explained therein, and is not a substitute for cryptographic protection (e.g., IPsec or TCP-AO). A TCP implementation that supports the mitigation described in RFC 5961 SHOULD first check that the sequence number exactly matches RCV.NXT prior to executing the action in the next paragraph.
o 潜在的なブラインドリセット攻撃は、RFC 5961 [9]に記載されています。そのドキュメントで説明されている緩和には、その中で特定の適用可能性が説明されており、暗号化保護（IPSECまたはTCP-AOなど）の代替ではありません。RFC 5961で説明されている緩和をサポートするTCP実装は、最初に次の段落でアクションを実行する前に、シーケンス番号がRCV.NXTと正確に一致することを確認する必要があります。
o If the ACK was acceptable, then signal to the user "error: connection reset", drop the segment, enter CLOSED state, delete TCB, and return. Otherwise (no ACK), drop the segment and return.
o ACKが許容可能な場合は、ユーザー「エラー：接続リセット」に信号を送り、セグメントをドロップし、閉じた状態を入力し、TCBを削除して、戻ります。それ以外の場合は（ACKなし）、セグメントをドロップして戻ります。
Third, check the security:
第三に、セキュリティを確認してください。
- If the security/compartment in the segment does not exactly match the security/compartment in the TCB, send a reset:
- セグメント内のセキュリティ/コンパートメントがTCBのセキュリティ/コンパートメントと正確に一致しない場合は、リセットを送信します。
o If there is an ACK,
o ACKがある場合、
<SEQ=SEG.ACK><CTL=RST>
o Otherwise,
o さもないと、
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
- 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 the segment did not contain a RST.
- この手順は、ACKが問題であるか、ACKがない場合にのみ到達する必要があり、セグメントにはRSTが含まれていません。
- If the SYN bit is on and the security/compartment is 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 that are thereby acknowledged should be removed.
- Synビットがオンで、セキュリティ/コンパートメントが許容される場合、RCV.NXTはSEG.SEQ 1に設定され、IRSはSEG.SEQに設定されます。snd.unaは、seg.ack（ACKがある場合）に等しく進む必要があり、それによって認識される再送信キューのセグメントは削除する必要があります。
- If SND.UNA > ISS (our SYN has been ACKed), change the connection state to ESTABLISHED, form an ACK segment
- and.una> is（私たちの太陽がハッキングされている）、接続状態を確立された状態に変更し、ACKセグメントを形成します
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
- and send it. Data or controls that were queued for transmission MAY be included. Some TCP implementations suppress sending this segment when the received segment contains data that will anyways generate an acknowledgment in the later processing steps, saving this extra acknowledgment of the SYN from being sent. If there are other controls or text in the segment, then continue processing at the sixth step under Section 3.10.7.4 where the URG bit is checked; otherwise, return.
- そしてそれを送ってください。送信のためにキューに入れられたデータまたはコントロールを含めることができます。一部のTCP実装は、受信したセグメントに、とにかく後の処理手順で確認を生成するデータが含まれている場合にこのセグメントの送信を抑制し、Synのこの追加の確認を送信したことから保存します。セグメントに他のコントロールまたはテキストがある場合は、URGビットがチェックされるセクション3.10.7.4の下の6番目のステップで処理を続けます。それ以外の場合は、返します。
- Otherwise, enter SYN-RECEIVED, form a SYN,ACK segment
- それ以外の場合は、syn-receivedを入力し、syn、ackセグメントを形成します
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
- and send it. Set the variables:
- そしてそれを送ってください。変数を設定します。
SND.WND <- SEG.WND
and.and <-set.End
SND.WL1 <- SEG.SEQ
snd.wl1 <-seg.seq
SND.WL2 <- SEG.ACK
snd.wl2 <-seg.ack
If there are other controls or text in the segment, queue them for processing after the ESTABLISHED state has been reached, return.
セグメントに他のコントロールまたはテキストがある場合は、確立された状態に到達した後に処理するためにそれらをキューに戻します。
- Note that it is legal to send and receive application data on SYN segments (this is the "text in the segment" mentioned above). There has been significant misinformation and misunderstanding of this topic historically. Some firewalls and security devices consider this suspicious. However, the capability was used in T/TCP [21] and is used in TCP Fast Open (TFO) [48], so is important for implementations and network devices to permit.
- Synセグメントに関するアプリケーションデータを送信および受信することは合法であることに注意してください（これは上記の「セグメントのテキスト」です）。このトピックの歴史的に大きな誤った情報と誤解がありました。一部のファイアウォールやセキュリティデバイスは、この疑わしいと考えています。ただし、この機能はT/TCP [21]で使用され、TCP Fast Open（TFO）[48]で使用されているため、実装やネットワークデバイスが許可するために重要です。
Fifth, if neither of the SYN or RST bits is set, then drop the segment and return.
5番目、synまたはrstビットのいずれも設定されていない場合、セグメントをドロップして戻ります。
Otherwise,
さもないと、
First, check sequence number:
まず、シーケンス番号を確認します。
- SYN-RECEIVED STATE
- 同期された状態
- ESTABLISHED STATE
- 確立された状態
- FIN-WAIT-1 STATE
- FIN-WAIT-1状態
- FIN-WAIT-2 STATE
- Fin-Wait-2状態
- CLOSE-WAIT STATE
- 密閉状態
- CLOSING STATE
- 閉鎖状態
- LAST-ACK STATE
- ラストクック状態
- TIME-WAIT STATE
- タイムウェイト状態
o 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 are processed.
o セグメントは順番に処理されます。到着時の初期テストは、古い重複を破棄するために使用されますが、さらに処理はSEG.SEQ順序で行われます。セグメントの内容が古いものと新しい間の境界にまたがる場合、新しい部品のみが処理されます。
o In general, the processing of received segments MUST be implemented to aggregate ACK segments whenever possible (MUST-58). For example, if the TCP endpoint is processing a series of queued segments, it MUST process them all before sending any ACK segments (MUST-59).
o 一般に、受信セグメントの処理は、可能な限りACKセグメントを集約するために実装する必要があります（必須58）。たとえば、TCPエンドポイントが一連のキュー型セグメントを処理している場合、ACKセグメントを送信する前にすべて処理する必要があります（必須59）。
o There are four cases for the acceptability test for an incoming segment:
o 着信セグメントの受容性テストには4つのケースがあります。
+=========+=========+======================================+
| 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 |
+---------+---------+--------------------------------------+
Table 6: Segment Acceptability Tests
表6：セグメント許容性テスト
o In implementing sequence number validation as described here, please note Appendix A.2.
o ここで説明するようにシーケンス番号検証の実装では、付録A.2に注意してください。
o If the RCV.WND is zero, no segments will be acceptable, but special allowance should be made to accept valid ACKs, URGs, and RSTs.
o RCV.WNDがゼロの場合、セグメントは受け入れられませんが、有効なACK、URG、RSTSを受け入れるために特別な手当を作成する必要があります。
o 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):
o 着信セグメントが受け入れられない場合は、応答に承認を送信する必要があります（最初のビットが設定されていない限り、セグメントをドロップして返却する場合）：
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
o After sending the acknowledgment, drop the unacceptable segment and return.
o 謝辞を送信した後、容認できないセグメントをドロップして返却します。
o Note that for the TIME-WAIT state, there is an improved algorithm described in [40] for handling incoming SYN segments that utilizes timestamps rather than relying on the sequence number check described here. When the improved algorithm is implemented, the logic above is not applicable for incoming SYN segments with Timestamp Options, received on a connection in the TIME-WAIT state.
o 時間待合状態では、ここで説明するシーケンス番号チェックに依存するのではなく、タイムスタンプを利用する着信シンセグメントを処理するための[40]に記載されている改善されたアルゴリズムがあることに注意してください。改良されたアルゴリズムが実装されている場合、上記のロジックは、タイムワイト状態の接続で受信されたタイムスタンプオプションを使用した入力シンセグメントには適用できません。
o 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 beginning sequence numbers SHOULD be held for later processing (SHLD-31).
o 以下では、このセグメントはRCV.NXTで始まり、ウィンドウを超えない理想的なセグメントであると想定されています。ウィンドウの外側にある部分（synとfinを含む）をトリミングすることにより、この仮定に合わせて実際のセグメントを調整し、セグメントがRCV.NXTで始まる場合にのみさらに処理することができます。より高い開始シーケンス番号を持つセグメントは、後で処理するために保持する必要があります（SHLD-31）。
Second, check the RST bit:
第二に、最初のビットを確認してください：
- RFC 5961 [9], Section 3 describes a potential blind reset attack and optional mitigation approach. This does not provide a cryptographic protection (e.g., as in IPsec or TCP-AO) but can be applicable in situations described in RFC 5961. For stacks implementing the protection described in RFC 5961, the three checks below apply; otherwise, processing for these states is indicated further below.
- RFC 5961 [9]、セクション3では、潜在的なブラインドリセット攻撃とオプションの緩和アプローチについて説明しています。これは暗号化保護を提供するものではありません（例えば、IPSECやTCP-AOなど）が、RFC 5961で説明されている状況で適用できます。RFC5961に記載されている保護を実装するスタックの場合、以下の3つのチェックが適用されます。それ以外の場合、これらの状態の処理は以下にさらに示されています。
1) If the RST bit is set and the sequence number is outside the current receive window, silently drop the segment.
1) 最初のビットが設定され、シーケンス番号が現在の受信ウィンドウの外側にある場合、セグメントを静かにドロップします。
2) If the RST bit is set and the sequence number exactly matches the next expected sequence number (RCV.NXT), then TCP endpoints MUST reset the connection in the manner prescribed below according to the connection state.
2) RSTビットが設定され、シーケンス番号が次の予想シーケンス番号（RCV.NXT）と正確に一致する場合、TCPエンドポイントは、接続状態に従って以下に規定されている方法で接続をリセットする必要があります。
3) If the RST bit is set and the sequence number does not exactly match the next expected sequence value, yet is within the current receive window, TCP endpoints MUST send an acknowledgment (challenge ACK):
3) RSTビットが設定されており、シーケンス番号が次の予想シーケンス値と正確に一致しない場合、現在の受信ウィンドウ内にある場合、TCPエンドポイントは確認（チャレンジACK）を送信する必要があります。
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the challenge ACK, TCP endpoints MUST drop the unacceptable segment and stop processing the incoming packet further. Note that RFC 5961 and Errata ID 4772 [99] contain additional considerations for ACK throttling in an implementation.
チャレンジACKを送信した後、TCPエンドポイントは容認できないセグメントをドロップし、着信パケットの処理をさらに停止する必要があります。RFC 5961およびERRATA ID 4772 [99]には、実装でのACKスロットリングに関する追加の考慮事項が含まれていることに注意してください。
- SYN-RECEIVED STATE
- 同期された状態
o If the RST bit is set,
o 最初のビットが設定されている場合、
+ 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, the retransmission queue should be flushed. And in the active OPEN case, enter the CLOSED state and delete the TCB, and return.
+ この接続がパッシブオープンで開始された場合（つまり、リスニング状態から来た）、この接続を返してリスニング状態と戻ります。ユーザーに通知する必要はありません。この接続がアクティブなオープン（つまり、Syn-Sent Stateから来た）で開始された場合、接続は拒否されました。ユーザーに「接続が拒否された」と信号を送ります。どちらの場合でも、再送信キューをフラッシュする必要があります。アクティブなオープンケースでは、閉じた状態を入力してTCBを削除して戻ります。
- ESTABLISHED STATE
- 確立された状態
- FIN-WAIT-1 STATE
- FIN-WAIT-1状態
- FIN-WAIT-2 STATE
- Fin-Wait-2状態
- CLOSE-WAIT STATE
- 密閉状態
o 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.
o 最初のビットが設定されている場合、未払いの受信と送信は「リセット」応答を受信する必要があります。すべてのセグメントキューはフラッシュする必要があります。ユーザーは、未承諾の一般的な「接続リセット」信号も受信する必要があります。閉じた状態を入力し、TCBを削除して、戻ります。
- CLOSING STATE
- 閉鎖状態
- LAST-ACK STATE
- ラストクック状態
- TIME-WAIT STATE
- タイムウェイト状態
o If the RST bit is set, then enter the CLOSED state, delete the TCB, and return.
o 最初のビットが設定されている場合は、閉じた状態を入力し、TCBを削除して戻ります。
Third, check security:
第三に、セキュリティを確認してください：
- SYN-RECEIVED STATE
- 同期された状態
o If the security/compartment in the segment does not exactly match the security/compartment in the TCB, then send a reset and return.
o セグメント内のセキュリティ/コンパートメントがTCBのセキュリティ/コンパートメントと正確に一致しない場合は、リセットを送信して返します。
- ESTABLISHED STATE
- 確立された状態
- FIN-WAIT-1 STATE
- FIN-WAIT-1状態
- FIN-WAIT-2 STATE
- Fin-Wait-2状態
- CLOSE-WAIT STATE
- 密閉状態
- CLOSING STATE
- 閉鎖状態
- LAST-ACK STATE
- ラストクック状態
- TIME-WAIT STATE
- タイムウェイト状態
o If the security/compartment in the segment does not exactly match the security/compartment 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.
o セグメント内のセキュリティ/コンパートメントがTCBのセキュリティ/コンパートメントと正確に一致しない場合は、リセットを送信します。未払いの受信および送信は、「リセット」応答を受信する必要があります。すべてのセグメントキューはフラッシュする必要があります。ユーザーは、未承諾の一般的な「接続リセット」信号も受信する必要があります。閉じた状態を入力し、TCBを削除して、戻ります。
- Note this check is placed following the sequence check to prevent a segment from an old connection between these port numbers with a different security from causing an abort of the current connection.
- 注意このチェックは、シーケンスチェックに従って配置され、これらのポート番号間の古い接続からのセグメントが、現在の接続の中止を引き起こすのが異なるセキュリティを持つことを防ぎます。
Fourth, check the SYN bit:
第四に、synビットを確認してください：
- SYN-RECEIVED STATE
- 同期された状態
o If the connection was initiated with a passive OPEN, then return this connection to the LISTEN state and return. Otherwise, handle per the directions for synchronized states below.
o 接続がパッシブオープンで開始された場合は、この接続をリスニング状態に戻して戻ります。それ以外の場合は、以下の同期状態の指示ごとに処理します。
- ESTABLISHED STATE
- 確立された状態
- FIN-WAIT-1 STATE
- FIN-WAIT-1状態
- FIN-WAIT-2 STATE
- Fin-Wait-2状態
- CLOSE-WAIT STATE
- 密閉状態
- CLOSING STATE
- 閉鎖状態
- LAST-ACK STATE
- ラストクック状態
- TIME-WAIT STATE
- タイムウェイト状態
o If the SYN bit is set in these synchronized states, it may be either a legitimate new connection attempt (e.g., in the case of TIME-WAIT), an error where the connection should be reset, or the result of an attack attempt, as described in RFC 5961 [9]. For the TIME-WAIT state, new connections can be accepted if the Timestamp Option is used and meets expectations (per [40]). For all other cases, RFC 5961 provides a mitigation with applicability to some situations, though there are also alternatives that offer cryptographic protection (see Section 7). RFC 5961 recommends that in these synchronized states, if the SYN bit is set, irrespective of the sequence number, TCP endpoints MUST send a "challenge ACK" to the remote peer:
o Synビットがこれらの同期された状態で設定されている場合、それは正当な新しい接続の試み（例：Time-Waitの場合）、接続をリセットするエラー、または攻撃の試行の結果、ように攻撃の試行の結果である可能性があります。RFC 5961 [9]に記載されています。タイムウェイト状態では、タイムスタンプオプションが使用され、期待を満たしている場合、新しい接続を受け入れることができます（[40]）。他のすべてのケースについて、RFC 5961は、いくつかの状況への適用性を備えた緩和を提供しますが、暗号化保護を提供する代替手段もあります（セクション7を参照）。RFC 5961は、これらの同期された状態で、Synビットが設定されている場合、シーケンス番号に関係なく、TCPエンドポイントはリモートピアに「チャレンジACK」を送信する必要があることを推奨しています。
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
o After sending the acknowledgment, TCP implementations MUST drop the unacceptable segment and stop processing further. Note that RFC 5961 and Errata ID 4772 [99] contain additional ACK throttling notes for an implementation.
o 確認を送信した後、TCP実装は容認できないセグメントをドロップし、さらに処理を停止する必要があります。RFC 5961およびERRATA ID 4772 [99]には、実装のための追加のACKスロットリングノートが含まれていることに注意してください。
o For implementations that do not follow RFC 5961, the original behavior described in RFC 793 follows in this paragraph. 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.
o RFC 5961に従わない実装の場合、RFC 793で説明されている元の動作はこの段落に続きます。synがウィンドウにある場合、それはエラーです：リセットを送信し、未払いの受信と送信は「リセット」応答を受信する必要があります。すべてのセグメントキューをフラッシュする必要があります。閉じた状態、TCBを削除して、戻ります。
o 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).
o Synがウィンドウにない場合、この手順に到達せず、ACKが最初のステップで送信されていました（シーケンス番号チェック）。
Fifth, check the ACK field:
5番目、ACKフィールドを確認してください：
- if the ACK bit is off, drop the segment and return
- ACKビットがオフの場合は、セグメントをドロップして戻ります
- if the ACK bit is on,
- ACKビットがオンの場合、
o RFC 5961 [9], Section 5 describes a potential blind data injection attack, and mitigation that implementations MAY choose to include (MAY-12). TCP stacks that implement RFC 5961 MUST add an input check that the ACK value is acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) =< SEG.ACK =< SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. The new state variable MAX.SND.WND is defined as the largest window that the local sender has ever received from its peer (subject to window scaling) or may be hard-coded to a maximum permissible window value. When the ACK value is acceptable, the per-state processing below applies:
o RFC 5961 [9]、セクション5では、潜在的なブラインドデータインジェクション攻撃、および実装が含まれることを選択する可能性のある緩和について説明しています（5月12日）。RFC 5961を実装するTCPスタックは、（snd.una -max.snd.wnd）= <seg.ack = <snd.nxt）の範囲にある場合にのみ、ACK値が許容できるという入力チェックを追加する必要があります。ACK値が上記の条件を満たさないすべての着信セグメントは廃棄し、ACKを送り返す必要があります。新しい状態変数max.snd.wndは、ローカル送信者がピア（ウィンドウスケーリングの対象）からこれまでに受け取った最大のウィンドウとして定義されているか、最大許容されるウィンドウ値にハードコーディングされる場合があります。ACK値が許容される場合、以下の州ごとの処理が適用されます。
o SYN-RECEIVED STATE
o 同期された状態
+ If SND.UNA < SEG.ACK =< SND.NXT, then enter ESTABLISHED state and continue processing with the variables below set to:
+ snd.una <seg.ack = <snd.nxtの場合、確立された状態を入力し、以下の変数で処理を続行します。
SND.WND <- SEG.WND
and.and <-set.End
SND.WL1 <- SEG.SEQ
snd.wl1 <-seg.seq
SND.WL2 <- SEG.ACK
snd.wl2 <-seg.ack
+ If the segment acknowledgment is not acceptable, form a reset segment
+ セグメントの確認が受け入れられない場合は、リセットセグメントを形成します
<SEQ=SEG.ACK><CTL=RST>
+ and send it.
+ そしてそれを送ってください。
o ESTABLISHED STATE
o 確立された状態
+ If SND.UNA < SEG.ACK =< SND.NXT, then set SND.UNA <- SEG.ACK. Any segments on the retransmission queue that are thereby entirely acknowledged are removed. Users should receive positive acknowledgments for buffers that 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を設定します。それによって完全に認められている再送信キューのセグメントは削除されます。ユーザーは、送信され、完全に認められたバッファーの肯定的な承認を受け取る必要があります（つまり、「OK」応答で送信バッファーを返す必要があります）。ACKが重複している場合（seg.ack = <snd.una）、無視できます。ACK ACKがまだ送信されていないもの（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の場合、送信ウィンドウを更新する必要があります。if（snd.wl1 <seg.seqまたは（snd.wl1 = seg.seq and snd.wl2 = <seg.ack））、snd.wnd <-seg.wnd、set 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。ここでのチェックは、古いセグメントを使用してウィンドウを更新するのを防ぎます。
o FIN-WAIT-1 STATE
o FIN-WAIT-1状態
+ In addition to the processing for the ESTABLISHED state, if the FIN segment is now acknowledged, then enter FIN-WAIT-2 and continue processing in that state.
+ 確立された状態の処理に加えて、フィンセグメントが認められた場合、Fin-Wait-2を入力し、その状態で処理を続けます。
o FIN-WAIT-2 STATE
o 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.
+ 確立された状態の処理に加えて、再送信キューが空である場合、ユーザーの閉鎖は確認できます（「OK」）が、TCBを削除しないでください。
o CLOSE-WAIT STATE
o 密閉状態
+ Do the same processing as for the ESTABLISHED state.
+ 確立された状態と同じ処理を行います。
o CLOSING STATE
o 閉鎖状態
+ 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.
+ 確立された状態の処理に加えて、ACKが当社のFINを認めた場合、タイムウェイト状態を入力します。それ以外の場合は、セグメントを無視します。
o LAST-ACK STATE
o ラストクック状態
+ 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が確認された場合は、TCBを削除し、閉じた状態を入力して戻ります。
o TIME-WAIT STATE
o タイムウェイト状態
+ The only thing that can arrive in this state is a retransmission of the remote FIN. Acknowledge it, and restart the 2 MSL timeout.
+ この状態に到着できる唯一のことは、リモートフィンの再送信です。それを認め、2 MSLタイムアウトを再起動します。
Sixth, check the URG bit:
6番目、urgビットを確認してください：
- ESTABLISHED STATE
- 確立された状態
- FIN-WAIT-1 STATE
- FIN-WAIT-1状態
- FIN-WAIT-2 STATE
- Fin-Wait-2状態
o 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.
o urgビットが設定されている場合、rcv.up <-max（rcv.up、seg.up）、および緊急ポインター（rcv.up）が消費されるデータの前にリモート側に緊急データがあることをユーザーに信号します。この緊急データの連続シーケンスについて、ユーザーがすでに信号を受けている（またはまだ「緊急モード」）場合は、ユーザーに再度信号を与えないでください。
- CLOSE-WAIT STATE
- 密閉状態
- CLOSING STATE
- 閉鎖状態
- LAST-ACK STATE
- ラストクック状態
- TIME-WAIT STATE
- タイムウェイト状態
o This should not occur since a FIN has been received from the remote side. Ignore the URG.
o これは、リモート側からフィンが受信されているため、発生しないでください。urgを無視してください。
Seventh, process the segment text:
7番目、セグメントテキストを処理します。
- ESTABLISHED STATE
- 確立された状態
- FIN-WAIT-1 STATE
- FIN-WAIT-1状態
- FIN-WAIT-2 STATE
- Fin-Wait-2状態
o Once in the ESTABLISHED state, it is possible to deliver segment data to user RECEIVE buffers. Data from segments can be moved into buffers until either the buffer is full or the segment is empty. If the segment empties and carries a PUSH flag, then the user is informed, when the buffer is returned, that a PUSH has been received.
o 確立された状態に着くと、ユーザー受信バッファーにセグメントデータを配信することができます。セグメントからのデータは、バッファーがいっぱいになるか、セグメントが空になるまでバッファーに移動できます。セグメントが押し出してプッシュフラグを運ぶと、バッファが返されると、プッシュが受信されたことがユーザーに通知されます。
o When the TCP endpoint takes responsibility for delivering the data to the user, it must also acknowledge the receipt of the data.
o TCPエンドポイントがユーザーにデータを配信する責任を負う場合、データの受信も認める必要があります。
o Once the TCP endpoint takes responsibility for the data, it advances RCV.NXT over the data accepted, and adjusts RCV.WND as appropriate to the current buffer availability. The total of RCV.NXT and RCV.WND should not be reduced.
o TCPエンドポイントがデータの責任を負うと、受け入れられたデータに対してRCV.NXTを進め、現在のバッファーの可用性に応じてRCV.WNDを調整します。RCV.NXTとRCV.WNDの合計を削減しないでください。
o A TCP implementation MAY send an ACK segment acknowledging RCV.NXT when a valid segment arrives that is in the window but not at the left window edge (MAY-13).
o TCP実装は、左端の端（5月13日）ではなく、ウィンドウにある有効なセグメントが到着したときにRCV.NXTを認めるACKセグメントを送信する場合があります。
o Please note the window management suggestions in Section 3.8.
o セクション3.8のウィンドウ管理の提案に注意してください。
o Send an acknowledgment of the form:
o フォームの謝辞を送信します。
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
o This acknowledgment should be piggybacked on a segment being transmitted if possible without incurring undue delay.
o この承認は、不当な遅延を発生させることなく、可能であれば送信されるセグメントで豚にぶら下がっている必要があります。
- CLOSE-WAIT STATE
- 密閉状態
- CLOSING STATE
- 閉鎖状態
- LAST-ACK STATE
- ラストクック状態
- TIME-WAIT STATE
- タイムウェイト状態
o This should not occur since a FIN has been received from the remote side. Ignore the segment text.
o これは、リモート側からフィンが受信されているため、発生しないでください。セグメントテキストを無視します。
Eighth, check the FIN bit:
8番目、フィンビットを確認してください：
- 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.
- seg.seqを検証できないため、状態が閉じられている場合はフィンを処理したり、聞いたり、シンセントしたりしないでください。セグメントをドロップして戻ります。
- 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ビットが設定されている場合は、ユーザーの「接続閉鎖」に信号を送り、同じメッセージで保留中の受信を返し、FINでRCV.NXTを進め、FINの確認を送信します。FINは、まだユーザーに配信されていないセグメントテキストをプッシュすることを意味することに注意してください。
o SYN-RECEIVED STATE
o 同期された状態
o ESTABLISHED STATE
o 確立された状態
+ Enter the CLOSE-WAIT state.
+ 密閉状態を入力します。
o FIN-WAIT-1 STATE
o 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.
+ 私たちのフィンが（おそらくこのセグメントで）Ackedされている場合は、時間待ちを入力し、タイムウェイトタイマーを開始し、他のタイマーをオフにします。それ以外の場合は、閉鎖状態を入力します。
o FIN-WAIT-2 STATE
o Fin-Wait-2状態
+ Enter the TIME-WAIT state. Start the time-wait timer, turn off the other timers.
+ タイムウェイト状態を入力します。タイムウェイトタイマーを開始し、他のタイマーをオフにします。
o CLOSE-WAIT STATE
o 密閉状態
+ Remain in the CLOSE-WAIT state.
+ 密閉状態にとどまります。
o CLOSING STATE
o 閉鎖状態
+ Remain in the CLOSING state.
+ 閉鎖状態にとどまります。
o LAST-ACK STATE
o ラストクック状態
+ Remain in the LAST-ACK state.
+ 最後の概要状態にとどまります。
o TIME-WAIT STATE
o タイムウェイト状態
+ Remain in the TIME-WAIT state. Restart the 2 MSL time-wait timeout.
+ 時間待ち国にとどまります。2 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を削除し、閉じた状態を入力して戻ります。
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を削除し、閉じた状態を入力して戻ります。
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.
ACK A Control Bit（Aumpounded）は、シーケンススペースを占有していません。これは、このセグメントの確認フィールドが、このセグメントの送信者が受信すると予想している次のシーケンス番号を指定しているため、以前のすべてのシーケンス番号の受信を確認することを示しています。
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 network-layer address of the endpoint intended to receive a segment.
宛先アドレスセグメントを受け取ることを目的としたエンドポイントのネットワーク層アドレス。
FIN A control bit (finis) occupying one sequence number, which indicates that the sender will send no more data or control occupying sequence space.
FIN A CONTROL BIT（FINIS）1つのシーケンス番号を占有します。これは、送信者がこれ以上のデータを送信しないか、シーケンススペースを占有することを制御しないことを示します。
flush To remove all of the contents (data or segments) from a store (buffer or queue).
ストア（バッファーまたはキュー）からすべてのコンテンツ（データまたはセグメント）を削除するためにフラッシュします。
fragment A portion of a logical unit of data. In particular, an internet fragment is a portion of an internet datagram.
データの論理単位の一部をフラグメントします。特に、インターネットフラグメントは、インターネットデータグラムの一部です。
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.
インターネットプロトコルフィールドを識別します。送信者によって割り当てられたこの識別値は、データグラムの断片を組み立てる際に支援します。
internet address A network-layer address.
インターネットアドレスネットワーク層アドレス。
internet datagram A unit of data exchanged between internet hosts, together with the internet header that allows the datagram to be routed from source to destination.
インターネットデータグラムデータグラムをソースから宛先にルーティングできるようにするインターネットヘッダーとともに、インターネットホスト間で交換されるデータのユニット。
internet fragment A portion of the data of an internet datagram with an internet header.
インターネットフラグメントインターネットヘッダーを備えたインターネットデータグラムのデータの一部。
IP Internet Protocol. See [1] and [13].
IPインターネットプロトコル。[1]および[13]を参照してください。
IRS The Initial Receive Sequence number. The first sequence number used by the sender on a connection.
IRS初期受信シーケンス番号。接続で送信者が使用する最初のシーケンス番号。
ISN The Initial Sequence Number. The first sequence number used on a connection (either ISS or IRS). Selected in a way that is unique within a given period of time and is unpredictable to attackers.
ISN初期シーケンス番号。接続で使用される最初のシーケンス番号（ISSまたはIRS）。特定の期間内にユニークな方法で選択され、攻撃者にとって予測不可能です。
ISS The Initial Send Sequence number. The first sequence number used by the sender on a connection.
ISSIST初期送信シーケンス番号。接続で送信者が使用する最初のシーケンス番号。
left sequence This is the next sequence number to be acknowledged by the data-receiving TCP endpoint (or the lowest currently unacknowledged sequence number) and is sometimes referred to as the left edge of the send window.
左シーケンスこれは、データレシーブTCPエンドポイント（または現在最低の未把握されていないシーケンス番号）によって確認される次のシーケンス番号であり、送信ウィンドウの左端と呼ばれることもあります。
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.
MSL最大セグメント寿命、TCPセグメントがインターネットワークシステムに存在する可能性がある時間。任意に2分であると定義されています。
octet An eight-bit byte.
8ビットバイトをオクテットします。
Options An Option field may contain several options, and each option may be several octets in length.
オプションオプションフィールドにはいくつかのオプションが含まれている場合があり、各オプションは長さが数オクテットになる場合があります。
packet A package of data with a header that may or may not be logically complete. More often a physical packaging than a logical packaging of data.
論理的に完全である場合とそうでない場合があるヘッダーを使用して、データのパッケージをパッケージ化します。多くの場合、データの論理的なパッケージよりも物理的なパッケージング。
port The portion of a connection identifier used for demultiplexing connections at an endpoint.
エンドポイントで接続を非難するために使用される接続識別子の部分をポートします。
process A program in execution. A source or destination of data from the point of view of the TCP endpoint 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.NXT次のシーケンス番号を受信します
RCV.UP receive urgent pointer
rcv.up緊急ポインターを受け取ります
RCV.WND receive window
rcv.および受信ウィンドウ
receive next sequence number This is the next sequence number the local TCP endpoint is expecting to receive.
次のシーケンス番号を受信これは、ローカルTCPエンドポイントが受信する予定の次のシーケンス番号です。
receive window This represents the sequence numbers the local (receiving) TCP endpoint is willing to receive. Thus, the local TCP endpoint 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 this range are considered duplicates or injection attacks and discarded.
受信ウィンドウこれは、ローカル（受信）TCPエンドポイントが受け取る意思があるシーケンス番号を表します。したがって、ローカルTCPエンドポイントでは、rcv.nxtをRCV.NXT RCV.WNDに重複するセグメントが許容データまたはコントロールを携帯するセグメントを考慮します。この範囲外に完全にシーケンス番号を含むセグメントは、重複または注入攻撃と見なされ、廃棄されます。
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を生じさせません。
SEG.ACK segment acknowledgment
seg.ackセグメントの確認
SEG.LEN segment length
seg.lenセグメントの長さ
SEG.SEQ segment sequence
seg.seqセグメントシーケンス
SEG.UP segment urgent pointer field
seg.upセグメント緊急ポインターフィールド
SEG.WND segment window field
seg.wndセグメントウィンドウフィールド
segment A logical unit of data. In particular, a TCP segment is the unit of data transferred 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 that 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 endpoint 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.
SENDシーケンスこれは、ローカル（送信）TCPエンドポイントが接続で使用する次のシーケンス番号です。最初に初期シーケンス数曲線（ISN）から選択され、データのオクテットごとに増加するか、送信されたシーケンスのコントロールが増加します。
send window This represents the sequence numbers that the remote (receiving) TCP endpoint is willing to receive. It is the value of the window field specified in segments from the remote (data-receiving) TCP endpoint. The range of new sequence numbers that may be emitted by a TCP implementation 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.NXT send sequence
SND.NXT SEND SECENCE
SND.UNA left sequence
snd.una左シーケンス
SND.UP send urgent pointer
snd.up緊急ポインターを送信します
SND.WL1 segment sequence number at last window update
最後のウィンドウ更新時のSND.WL1セグメントシーケンス番号
SND.WL2 segment acknowledgment number at last window update
SND.WL2セグメントの確認番号最後のウィンドウアップデート
SND.WND send window
snd.wndはウィンドウを送信します
socket (or socket number, or socket address, or socket identifier) An address that specifically includes a port identifier, that is, the concatenation of an Internet Address with a TCP port.
ソケット（またはソケット番号、またはソケットアドレス、またはソケット識別子）ポート識別子、つまりTCPポートとのインターネットアドレスの連結を特に含むアドレス。
Source Address The network-layer address of the sending endpoint.
ソースアドレス送信エンドポイントのネットワーク層アドレス。
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.
着信セグメントのコントロールビットは、1つのシーケンス番号を占有し、接続の開始時に使用してシーケンス番号が始まる場所を示します。
TCB Transmission control block, the data structure that records the state of a connection.
TCB伝送制御ブロック、接続の状態を記録するデータ構造。
TCP Transmission Control Protocol: a host-to-host protocol for reliable communication in internetwork environments.
TCP伝送制御プロトコル：インターネットワーク環境での信頼できる通信のためのホストからホストまでのプロトコル。
TOS Type of Service, an obsoleted IPv4 field. The same header bits currently are used for the Differentiated Services field [4] containing the Differentiated Services Codepoint (DSCP) value and the 2-bit ECN codepoint [6].
TOSタイプのサービス、廃止されたIPv4フィールド。現在、同じヘッダービットが、差別化されたサービスコードポイント（DSCP）値と2ビットECNコードポイント[6]を含む差別化されたサービスフィールド[4]に使用されています。
Type of Service See "TOS".
サービスのタイプ「TOS」を参照してください。
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 by 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 that indicates the data octet associated with the sending user's urgent call.
緊急のポインタコントロールフィールドは、URGビットがオンの場合にのみ意味があります。このフィールドは、送信ユーザーの緊急の呼び出しに関連付けられているデータOctetを示す緊急ポインターの価値を伝えます。
This document obsoletes RFC 793 as well as RFCs 6093 and 6528, which updated 793. In all cases, only the normative protocol specification and requirements have been incorporated into this document, and some informational text with background and rationale may not have been carried in. The informational content of those documents is still valuable in learning about and understanding TCP, and they are valid Informational references, even though their normative content has been incorporated into this document.
このドキュメントは、RFC 793およびRFCS 6093および6528を廃止し、793を更新しました。すべての場合、このドキュメントには規範的なプロトコルの仕様と要件のみが組み込まれており、背景と根拠を持ついくつかの情報テキストは掲載されていない可能性があります。これらのドキュメントの情報コンテンツは、TCPについて学び、理解する上で依然として価値があり、それらの規範的コンテンツがこのドキュメントに組み込まれているにもかかわらず、それらは有効な情報参照です。
The main body of this document was adapted from RFC 793's Section 3, titled "FUNCTIONAL SPECIFICATION", with an attempt to keep formatting and layout as close as possible.
このドキュメントの本体は、「機能仕様」というタイトルのRFC 793のセクション3から採用され、フォーマットとレイアウトを可能な限り近づけようとしました。
The collection of applicable RFC errata that have been reported and
either accepted or held for an update to RFC 793 were incorporated
(Errata IDs: 573 [73], 574 [74], 700 [75], 701 [76], 1283 [77], 1561
[78], 1562 [79], 1564 [80], 1571 [81], 1572 [82], 2297 [83], 2298
[84], 2748 [85], 2749 [86], 2934 [87], 3213 [88], 3300 [89], 3301
[90], 6222 [91]). Some errata were not applicable due to other
changes (Errata IDs: 572 [92], 575 [93], 1565 [94], 1569 [95], 2296
[96], 3305 [97], 3602 [98]).
Changes to the specification of the urgent pointer described in RFCs 1011, 1122, and 6093 were incorporated. See RFC 6093 for detailed discussion of why these changes were necessary.
RFCS 1011、1122、および6093に記載されている緊急ポインターの仕様の変更が組み込まれました。これらの変更が必要な理由の詳細については、RFC 6093を参照してください。
The discussion of the RTO from RFC 793 was updated to refer to RFC 6298. The text on the RTO in RFC 1122 originally replaced the text in RFC 793; however, RFC 2988 should have updated RFC 1122 and has subsequently been obsoleted by RFC 6298.
RFC 793からのRTOの議論は、RFC 6298を参照するように更新されました。RFC1122のRTOのテキストは、元々RFC 793のテキストを置き換えました。ただし、RFC 2988はRFC 1122を更新し、その後RFC 6298によって廃止されたはずです。
RFC 1011 [18] contains a number of comments about RFC 793, including some needed changes to the TCP specification. These are expanded in RFC 1122, which contains a collection of other changes and clarifications to RFC 793. The normative items impacting the protocol have been incorporated here, though some historically useful implementation advice and informative discussion from RFC 1122 is not included here. The present document, which is now the TCP specification rather than RFC 793, updates RFC 1011, and the comments noted in RFC 1011 have been incorporated.
RFC 1011 [18]には、TCP仕様に必要ないくつかの変更を含む、RFC 793に関する多くのコメントが含まれています。これらはRFC 1122で拡張されています。これには、RFC 793の他の変更と説明のコレクションが含まれています。プロトコルに影響を与える規範的項目はここに組み込まれていますが、RFC 1122からの歴史的に有用な実装アドバイスと有益な議論はここには含まれていません。現在、RFC 793ではなくTCP仕様である現在のドキュメントは、RFC 1011を更新し、RFC 1011に記載されているコメントが組み込まれています。
RFC 1122 contains more than just TCP requirements, so this document can't obsolete RFC 1122 entirely. It is only marked as "updating" RFC 1122; however, it should be understood to effectively obsolete all of the material on TCP found in RFC 1122.
RFC 1122にはTCP要件以上のものが含まれているため、このドキュメントはRFC 1122を完全に廃止することはできません。「更新」RFC 1122としてのみマークされています。ただし、RFC 1122で見つかったTCP上のすべての資料を効果的に廃止することを理解する必要があります。
The more secure initial sequence number generation algorithm from RFC 6528 was incorporated. See RFC 6528 for discussion of the attacks that this mitigates, as well as advice on selecting PRF algorithms and managing secret key data.
RFC 6528のより安全な初期シーケンス数生成アルゴリズムが組み込まれました。これが軽減する攻撃の議論については、PRFアルゴリズムの選択とシークレットキーデータの管理に関するアドバイスについては、RFC 6528を参照してください。
A note based on RFC 6429 was added to explicitly clarify that system resource management concerns allow connection resources to be reclaimed. RFC 6429 is obsoleted in the sense that the clarification it describes has been reflected within this base TCP specification.
RFC 6429に基づいたメモが追加され、システムリソース管理の懸念により、接続リソースを再生することができることを明確に明確にしました。RFC 6429は、それが説明する明確化がこのベースTCP仕様に反映されているという意味で廃止されています。
The description of congestion control implementation was added based on the set of documents that are IETF BCP or Standards Track on the topic and the current state of common implementations.
輻輳制御実装の説明は、IETF BCPまたは標準のトピックを追跡するドキュメントのセットと、共通の実装の現在の状態に基づいて追加されました。
In the "Transmission Control Protocol (TCP) Header Flags" registry, IANA has made several changes as described in this section.
「トランスミッションコントロールプロトコル（TCP）ヘッダーフラグ」レジストリでは、IANAはこのセクションで説明されているようにいくつかの変更を加えました。
RFC 3168 originally created this registry but only populated it with the new bits defined in RFC 3168, neglecting the other bits that had previously been described in RFC 793 and other documents. Bit 7 has since also been updated by RFC 8311 [54].
RFC 3168はもともとこのレジストリを作成しましたが、RFC 3168で定義された新しいビットにのみ入力し、以前にRFC 793およびその他のドキュメントで説明されていた他のビットを無視しました。その後、ビット7はRFC 8311 [54]によって更新されました。
The "Bit" column has been renamed below as the "Bit Offset" column because it references each header flag's offset within the 16-bit aligned view of the TCP header in Figure 1. The bits in offsets 0 through 3 are the TCP segment Data Offset field, and not header flags.
「ビット」列は、図1のTCPヘッダーの16ビットアラインドビュー内の各ヘッダーフラグのオフセットを参照するため、以下に「ビットオフセット」列として名前が変更されています。オフセット0〜3のビットはTCPセグメントデータです。ヘッダーフラグではなくオフセットフィールド。
IANA has added a column for "Assignment Notes".
IANAは「割り当てノート」の列を追加しました。
IANA has assigned values as indicated below.
IANAは、以下に示すように値を割り当てました。
+========+===================+===========+====================+
| Bit | Name | Reference | Assignment Notes |
| Offset | | | |
+========+===================+===========+====================+
| 4 | Reserved for | RFC 9293 | |
| | future use | | |
+--------+-------------------+-----------+--------------------+
| 5 | Reserved for | RFC 9293 | |
| | future use | | |
+--------+-------------------+-----------+--------------------+
| 6 | Reserved for | RFC 9293 | |
| | future use | | |
+--------+-------------------+-----------+--------------------+
| 7 | Reserved for | RFC 8311 | Previously used by |
| | future use | | Historic RFC 3540 |
| | | | as NS (Nonce Sum). |
+--------+-------------------+-----------+--------------------+
| 8 | CWR (Congestion | RFC 3168 | |
| | Window Reduced) | | |
+--------+-------------------+-----------+--------------------+
| 9 | ECE (ECN-Echo) | RFC 3168 | |
+--------+-------------------+-----------+--------------------+
| 10 | Urgent pointer | RFC 9293 | |
| | field is | | |
| | significant (URG) | | |
+--------+-------------------+-----------+--------------------+
| 11 | Acknowledgment | RFC 9293 | |
| | field is | | |
| | significant (ACK) | | |
+--------+-------------------+-----------+--------------------+
| 12 | Push function | RFC 9293 | |
| | (PSH) | | |
+--------+-------------------+-----------+--------------------+
| 13 | Reset the | RFC 9293 | |
| | connection (RST) | | |
+--------+-------------------+-----------+--------------------+
| 14 | Synchronize | RFC 9293 | |
| | sequence numbers | | |
| | (SYN) | | |
+--------+-------------------+-----------+--------------------+
| 15 | No more data from | RFC 9293 | |
| | sender (FIN) | | |
+--------+-------------------+-----------+--------------------+
Table 7: TCP Header Flags
表7：TCPヘッダーフラグ
The "TCP Header Flags" registry has also been moved to a subregistry under the global "Transmission Control Protocol (TCP) Parameters" registry <https://www.iana.org/assignments/tcp-parameters/>.
「TCPヘッダーフラグ」レジストリは、グローバル「伝送制御プロトコル（TCP）パラメーター」レジストリ<https://www.iana.org/assignments/tcp-parameters/>に基づくサブレジストリにも移動されました。
The registry's Registration Procedure remains Standards Action, but the Reference has been updated to this document, and the Note has been removed.
レジストリの登録手順は標準訴訟のままですが、参照はこのドキュメントへの更新されており、メモは削除されています。
The TCP design includes only rudimentary security features that improve the robustness and reliability of connections and application data transfer, but there are no built-in cryptographic capabilities to support any form of confidentiality, authentication, or other typical security functions. Non-cryptographic enhancements (e.g., [9]) have been developed to improve robustness of TCP connections to particular types of attacks, but the applicability and protections of non-cryptographic enhancements are limited (e.g., see Section 1.1 of [9]). Applications typically utilize lower-layer (e.g., IPsec) and upper-layer (e.g., TLS) protocols to provide security and privacy for TCP connections and application data carried in TCP. Methods based on TCP Options have been developed as well, to support some security capabilities.
TCP設計には、接続とアプリケーションデータ転送の堅牢性と信頼性を向上させる初歩的なセキュリティ機能のみが含まれていますが、あらゆる形態の機密性、認証、またはその他の典型的なセキュリティ機能をサポートするための構築された暗号化機能はありません。特定のタイプの攻撃に対するTCP接続の堅牢性を改善するために、非暗号化の強化（[9]）が開発されましたが、非暗号化の強化の適用性と保護は限られています（例：[9]のセクション1.1を参照）。アプリケーションは通常、低層（IPSECなど）および上層層（TLSなど）プロトコルを利用して、TCPで運ばれるTCP接続とアプリケーションデータのセキュリティとプライバシーを提供します。いくつかのセキュリティ機能をサポートするために、TCPオプションに基づく方法も開発されています。
In order to fully provide confidentiality, integrity protection, and authentication for TCP connections (including their control flags), IPsec is the only current effective method. For integrity protection and authentication, the TCP Authentication Option (TCP-AO) [38] is available, with a proposed extension to also provide confidentiality for the segment payload. Other methods discussed in this section may provide confidentiality or integrity protection for the payload, but for the TCP header only cover either a subset of the fields (e.g., tcpcrypt [57]) or none at all (e.g., TLS). Other security features that have been added to TCP (e.g., ISN generation, sequence number checks, and others) are only capable of partially hindering attacks.
TCP接続（制御フラグを含む）に機密性、整合性保護、および認証を完全に提供するために、IPSECは現在の唯一の効果的な方法です。整合性の保護と認証のために、TCP認証オプション（TCP-AO）[38]が利用可能で、セグメントペイロードの機密性も提供する提案された拡張機能があります。このセクションで説明する他の方法では、ペイロードの機密性または整合性保護を提供する場合がありますが、TCPヘッダーの場合、フィールドのサブセット（たとえば、TCPCRYPT [57]）またはまったく（TLSなど）のみをカバーします。TCPに追加された他のセキュリティ機能（ISN生成、シーケンス番号チェックなど）は、攻撃を部分的に妨げることができるだけです。
Applications using long-lived TCP flows have been vulnerable to attacks that exploit the processing of control flags described in earlier TCP specifications [33]. TCP-MD5 was a commonly implemented TCP Option to support authentication for some of these connections, but had flaws and is now deprecated. TCP-AO provides a capability to protect long-lived TCP connections from attacks and has superior properties to TCP-MD5. It does not provide any privacy for application data or for the TCP headers.
長寿命のTCPフローを使用したアプリケーションは、以前のTCP仕様で説明した制御フラグの処理を活用する攻撃に対して脆弱です[33]。TCP-MD5は、これらの接続の一部の認証をサポートするために一般的に実装されているTCPオプションでしたが、欠陥があり、現在は非推奨になっています。TCP-AOは、攻撃から長寿命のTCP接続を保護する機能を提供し、TCP-MD5に優れた特性を持っています。アプリケーションデータやTCPヘッダーにプライバシーは提供されません。
The "tcpcrypt" [57] experimental extension to TCP provides the ability to cryptographically protect connection data. Metadata aspects of the TCP flow are still visible, but the application stream is well protected. Within the TCP header, only the urgent pointer and FIN flag are protected through tcpcrypt.
「TCPCRYPT」[57] TCPの実験的拡張は、接続データを暗号化的に保護する機能を提供します。TCPフローのメタデータの側面はまだ表示されていますが、アプリケーションストリームは十分に保護されています。TCPヘッダー内では、緊急のポインターとフィンフラグのみがTCPCRYPTを介して保護されます。
The TCP Roadmap [49] includes notes about several RFCs related to TCP security. Many of the enhancements provided by these RFCs have been integrated into the present document, including ISN generation, mitigating blind in-window attacks, and improving handling of soft errors and ICMP packets. These are all discussed in greater detail in the referenced RFCs that originally described the changes needed to earlier TCP specifications. Additionally, see RFC 6093 [39] for discussion of security considerations related to the urgent pointer field, which also discourages new applications from using the urgent pointer.
TCPロードマップ[49]には、TCPセキュリティに関連するいくつかのRFCに関するメモが含まれています。これらのRFCが提供する強化の多くは、ISN世代、盲目のウィンドウ攻撃の緩和、ソフトエラーとICMPパケットの取り扱いの改善など、現在のドキュメントに統合されています。これらはすべて、以前のTCP仕様に必要な変更を最初に説明した参照されたRFCで詳細に説明しています。さらに、緊急のポインターフィールドに関連するセキュリティに関する考慮事項の議論については、RFC 6093 [39]を参照してください。
Since TCP is often used for bulk transfer flows, some attacks are possible that abuse the TCP congestion control logic. An example is "ACK-division" attacks. Updates that have been made to the TCP congestion control specifications include mechanisms like Appropriate Byte Counting (ABC) [29] that act as mitigations to these attacks.
TCPはしばしばバルク転送フローに使用されるため、TCPの混雑制御ロジックを乱用する攻撃が可能です。例は、「ACK-Division」攻撃です。TCP混雑制御仕様に加えられた更新には、これらの攻撃の軽減として機能する適切なバイトカウント（ABC）[29]などのメカニズムが含まれます。
Other attacks are focused on exhausting the resources of a TCP server. Examples include SYN flooding [32] or wasting resources on non-progressing connections [41]. Operating systems commonly implement mitigations for these attacks. Some common defenses also utilize proxies, stateful firewalls, and other technologies outside the end-host TCP implementation.
他の攻撃は、TCPサーバーのリソースを使い果たすことに焦点を当てています。例には、Syn Flooding [32]または非進行接続のリソースの浪費[41]が含まれます。通常、オペレーティングシステムは、これらの攻撃に緩和を実装します。一部の一般的な防御は、プロキシ、ステートフルファイアウォール、およびエンドホストTCP実装外のその他のテクノロジーも利用しています。
The concept of a protocol's "wire image" is described in RFC 8546 [56], which describes how TCP's cleartext headers expose more metadata to nodes on the path than is strictly required to route the packets to their destination. On-path adversaries may be able to leverage this metadata. Lessons learned in this respect from TCP have been applied in the design of newer transports like QUIC [60]. Additionally, based partly on experiences with TCP and its extensions, there are considerations that might be applicable for future TCP extensions and other transports that the IETF has documented in RFC 9065 [61], along with IAB recommendations in RFC 8558 [58] and [67].
プロトコルの「ワイヤイメージ」の概念は、RFC 8546 [56]で説明されています。これは、TCPのクリアテキストヘッダーが、パケットを宛先にルーティングするために厳密に必要とされるよりも、パス上のノードにより多くのメタデータをどのように露出させるかを説明しています。パス敵はこのメタデータを活用できる可能性があります。TCPからこの点で学んだ教訓は、QUICのような新しい輸送の設計に適用されています[60]。さらに、TCPとその拡張の経験に部分的に基づいて、IETFがRFC 9065 [61]で文書化した将来のTCP拡張およびその他のトランスポートに適用される可能性のある考慮事項があり、RFC 8558 [58]および[67]。
There are also methods of "fingerprinting" that can be used to infer the host TCP implementation (operating system) version or platform information. These collect observations of several aspects, such as the options present in segments, the ordering of options, the specific behaviors in the case of various conditions, packet timing, packet sizing, and other aspects of the protocol that are left to be determined by an implementer, and can use those observations to identify information about the host and implementation.
ホストTCP実装（オペレーティングシステム）バージョンまたはプラットフォーム情報を推測するために使用できる「フィンガープリント」の方法もあります。これらは、セグメントに存在するオプション、オプションの順序、さまざまな条件の場合の特定の動作、パケットタイミング、パケットサイジング、およびその他のプロトコルの他の側面など、いくつかの側面の観察結果を収集します。実装者、およびそれらの観察結果を使用して、ホストと実装に関する情報を特定できます。
Since ICMP message processing also can interact with TCP connections, there is potential for ICMP-based attacks against TCP connections. These are discussed in RFC 5927 [100], along with mitigations that have been implemented.
ICMPメッセージ処理もTCP接続と相互作用できるため、TCP接続に対するICMPベースの攻撃の可能性があります。これらは、実装された緩和とともに、RFC 5927 [100]で説明されています。
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[1] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487/RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[2] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[2] Mogul、J。and S. Deering、「Path MTU Discovery」、RFC 1191、doi 10.17487/rfc1191、1990年11月、<https://www.rfc-editor.org/info/rfc1191>。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/rfc2119>。
[4] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[4] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487/RFC2474、1998年12月、<https://www.rfc-editor.org/info/rfc2474>。
[5] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.
[5] Floyd、S。、「混雑制御原則」、BCP 41、RFC 2914、DOI 10.17487/RFC2914、2000年9月、<https://www.rfc-editor.org/info/rfc2914>。
[6] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[6] Ramakrishnan、K.、Floyd、S。、およびD. Black、「明示的な混雑通知（ECN）のIPへの追加」、RFC 3168、DOI 10.17487/RFC3168、2001年9月、<https：//www.rfc-editor.org/info/rfc3168>。
[7] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, DOI 10.17487/RFC5033, August 2007, <https://www.rfc-editor.org/info/rfc5033>.
[7] Floyd、S。and M. Allman、「新しい混雑制御アルゴリズムの指定」、BCP 133、RFC 5033、DOI 10.17487/RFC5033、2007年8月、<https://www.rfc-editor.org/info/rfc5033>。
[8] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[8] Allman、M.、Paxson、V.、およびE. Blanton、「TCP混雑制御」、RFC 5681、DOI 10.17487/RFC5681、2009年9月、<https://www.rfc-editor.org/info/rfc5681>>>。
[9] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, <https://www.rfc-editor.org/info/rfc5961>.
[9] Ramaiah、A.、Stewart、R。、およびM. Dalal、「Window In-Window攻撃に対するTCPの堅牢性の向上」、RFC 5961、DOI 10.17487/RFC5961、2010年8月、<https://www.rfc-editor.org/info/rfc5961>。
[10] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[10] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「TCPの再送信タイマー」、RFC 6298、DOI 10.17487/RFC6298、2011年6月、<https://www.rfc-editor.org/info/rfc6298>。
[11] Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, DOI 10.17487/RFC6633, May 2012, <https://www.rfc-editor.org/info/rfc6633>.
[11] Gont、F。、「ICMPソースクエンチメッセージの非推奨」、RFC 6633、DOI 10.17487/RFC6633、2012年5月、<https://www.rfc-editor.org/info/rfc6633>。
[12] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[12] Leiba、B。、「RFC 2119の大文字と小文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https://www.rfc-editor.org/info/rfc8174>
[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[13] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487/RFC8200、2017年7月、<https://www.rfc-editor.org/info/RFC8200>。
[14] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[14] McCann、J.、Deering、S.、Mogul、J.、およびR. Hinden、ed。、「IPバージョン6のPath MTU Discovery」、STD 87、RFC 8201、DOI 10.17487/RFC8201、2017年7月、<https：//www.rfc-editor.org/info/rfc8201>。
[15] Allman, M., "Requirements for Time-Based Loss Detection", BCP 233, RFC 8961, DOI 10.17487/RFC8961, November 2020, <https://www.rfc-editor.org/info/rfc8961>.
[15] Allman、M。、「時間ベースの損失検出の要件」、BCP 233、RFC 8961、DOI 10.17487/RFC8961、2020年11月、<https://www.rfc-editor.org/info/rfc8961>。
[16] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[16] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、DOI 10.17487/RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[17] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, DOI 10.17487/RFC0896, January 1984, <https://www.rfc-editor.org/info/rfc896>.
[17] Nagle、J。、「IP/TCPインターネットワークスの混雑制御」、RFC 896、DOI 10.17487/RFC0896、1984年1月、<https://www.rfc-editor.org/info/rfc896>。
[18] Reynolds, J. and J. Postel, "Official Internet protocols", RFC 1011, DOI 10.17487/RFC1011, May 1987, <https://www.rfc-editor.org/info/rfc1011>.
[18] Reynolds、J。and J. Postel、「公式インターネットプロトコル」、RFC 1011、DOI 10.17487/RFC1011、1987年5月、<https://www.rfc-editor.org/info/rfc1011>。
[19] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[19] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、DOI 10.17487/RFC1122、1989年10月、<https://www.rfc-editor.org/info/rfc1122>。
[20] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992, <https://www.rfc-editor.org/info/rfc1349>.
[20] Almquist、P。、「インターネットプロトコルスイートの種類」、RFC 1349、DOI 10.17487/RFC1349、1992年7月、<https://www.rfc-editor.org/info/rfc1349>。
[21] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, DOI 10.17487/RFC1644, July 1994, <https://www.rfc-editor.org/info/rfc1644>.
[21] Braden、R。、「T/TCP-TCPトランザクションの機能仕様のためのTCP拡張」、RFC 1644、DOI 10.17487/RFC1644、1994年7月、<https://www.rfc-editor.org/info/rfc1644>。
[22] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.
[22] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Auncement Options」、RFC 2018、DOI 10.17487/RFC2018、1996年10月、<https://www.rfc-editor.org/info/rfc2018>。
[23] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known TCP Implementation Problems", RFC 2525, DOI 10.17487/RFC2525, March 1999, <https://www.rfc-editor.org/info/rfc2525>.
[23] Paxson、V.、Allman、M.、Dawson、S.、Fenner、W.、Griner、J.、Heavens、I.、Lahey、K.、Semke、J。、およびB. Volz、「既知のTCP実装問題」"、RFC 2525、doi 10.17487/rfc2525、1999年3月、<https://www.rfc-editor.org/info/rfc2525>。
[24] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, <https://www.rfc-editor.org/info/rfc2675>.
[24] ボーマン、D。、ディアリング、S。、およびR.ヒンデン、「IPv6ジャンボグラム」、RFC 2675、DOI 10.17487/RFC2675、1999年8月、<https://www.rfc-editor.org/info/rfc2675>。
[25] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP Processing of the IPv4 Precedence Field", RFC 2873, DOI 10.17487/RFC2873, June 2000, <https://www.rfc-editor.org/info/rfc2873>.
[25] Xiao、X.、Hannan、A.、Paxson、V.、およびE. Crabbe、「IPv4 PrecensenceフィールドのTCP処理」、RFC 2873、DOI 10.17487/RFC2873、2000年6月、<https：//www.rfc-editor.org/info/rfc2873>。
[26] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, DOI 10.17487/RFC2883, July 2000, <https://www.rfc-editor.org/info/rfc2883>.
[26] Floyd、S.、Mahdavi、J.、Mathis、M。、およびM. Podolsky、「TCPの選択的承認（SACK）オプションの拡張」、RFC 2883、DOI 10.17487/RFC2883、2000年7月、<https：//www.rfc-editor.org/info/rfc2883>。
[27] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, DOI 10.17487/RFC2923, September 2000, <https://www.rfc-editor.org/info/rfc2923>.
[27] Lahey、K。、「Path MTU DiscoveryのTCP問題」、RFC 2923、DOI 10.17487/RFC2923、2000年9月、<https://www.rfc-editor.org/info/rfc2923>。
[28] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, December 2002, <https://www.rfc-editor.org/info/rfc3449>.
[28] Balakrishnan、H.、Padmanabhan、V.、Fairhurst、G。、およびM. Sooriyabandara、「ネットワークパス非対称性のTCPパフォーマンスの影響」、BCP 69、RFC 3449、DOI 10.17487/RFC3449、2002年12月、<https：.rfc-editor.org/info/rfc3449>。
[29] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February 2003, <https://www.rfc-editor.org/info/rfc3465>.
[29] Allman、M。、「適切なバイトカウント（ABC）を備えたTCP混雑制御」、RFC 3465、DOI 10.17487/RFC3465、2003年2月、<https://www.rfc-editor.org/info/rfc3465>。
[30] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, DOI 10.17487/RFC4727, November 2006, <https://www.rfc-editor.org/info/rfc4727>.
[30] Fenner、B。、「IPv4、IPv6、ICMPV4、ICMPV6、ICMPV6、UDP、およびTCPヘッダーの実験値」、RFC 4727、DOI 10.17487/RFC4727、2006年11月、<https：//www.rfc-editor.org/info//RFC4727>。
[31] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[31] Mathis、M。and J. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487/RFC4821、2007年3月、<https://www.rfc-editor.org/info/rfc4821>。
[32] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <https://www.rfc-editor.org/info/rfc4987>.
[32] Eddy、W。、「TCP Syn Flooding Attacks and Common Mitigations」、RFC 4987、DOI 10.17487/RFC4987、2007年8月、<https://www.rfc-editor.org/info/rfc4987>
[33] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007, <https://www.rfc-editor.org/info/rfc4953>.
[33] Touch、J。、「スプーフィング攻撃に対するTCPの防御」、RFC 4953、DOI 10.17487/RFC4953、2007年7月、<https://www.rfc-editor.org/info/rfc4953>。
[34] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. Carrier, "Marker PDU Aligned Framing for TCP Specification", RFC 5044, DOI 10.17487/RFC5044, October 2007, <https://www.rfc-editor.org/info/rfc5044>.
[34] Culley、P.、Elzur、U.、Recio、R.、Bailey、S。、およびJ. Carrier、「TCP仕様のマーカーPDUアライメントフレーミング」、RFC 5044、DOI 10.17487/RFC5044、2007年10月、<https：//www.rfc-editor.org/info/rfc5044>。
[35] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI 10.17487/RFC5461, February 2009, <https://www.rfc-editor.org/info/rfc5461>.
[35] Gont、F。、「ソフトエラーに対するTCPの反応」、RFC 5461、DOI 10.17487/RFC5461、2009年2月、<https://www.rfc-editor.org/info/rfc5461>。
[36] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, DOI 10.17487/RFC5570, July 2009, <https://www.rfc-editor.org/info/rfc5570>.
[36] Stjohns、M.、Atkinson、R.、およびG. Thomas、「Common Architecture Label IPv6 Security Option（Calipso）」、RFC 5570、DOI 10.17487/RFC5570、2009年7月、<https://www.rfc-editor.org/info/rfc5570>。
[37] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10.17487/RFC5795, March 2010, <https://www.rfc-editor.org/info/rfc5795>.
[37] Sandlund、K.、Pelletier、G。、およびL-e。Jonsson、「堅牢なヘッダー圧縮（ROHC）フレームワーク」、RFC 5795、DOI 10.17487/RFC5795、2010年3月、<https://www.rfc-editor.org/info/rfc5795>。
[38] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[38] Touch、J.、Mankin、A。、およびR. Bonica、「TCP認証オプション」、RFC 5925、DOI 10.17487/RFC5925、2010年6月、<https://www.rfc-editor.org/info/rfc5925>。
[39] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, <https://www.rfc-editor.org/info/rfc6093>.
[39] Gont、F。and A. Yourtchenko、「TCP緊急メカニズムの実装について」、RFC 6093、DOI 10.17487/RFC6093、2011年1月、<https://www.rfc-editor.org/info/rfc6093>。
[40] Gont, F., "Reducing the TIME-WAIT State Using TCP Timestamps", BCP 159, RFC 6191, DOI 10.17487/RFC6191, April 2011, <https://www.rfc-editor.org/info/rfc6191>.
[40] Gont、F。、「TCPタイムスタンプを使用して時間待合状態を減らす」、BCP 159、RFC 6191、DOI 10.17487/RFC6191、2011年4月、<https://www.rfc-editor.org/info/rfc6191>。
[41] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender Clarification for Persist Condition", RFC 6429, DOI 10.17487/RFC6429, December 2011, <https://www.rfc-editor.org/info/rfc6429>.
[41] Bashyam、M.、Jethanandani、M.、およびA. Ramaiah、「TCP Sender for Persing Conditionの明確化」、RFC 6429、DOI 10.17487/RFC6429、2011年12月、<https://www.rfc-editor.org/info/RFC6429>。
[42] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 2012, <https://www.rfc-editor.org/info/rfc6528>.
[42] Gont、F。およびS. Bellovin、「シーケンス番号攻撃に対する防御」、RFC 6528、DOI 10.17487/RFC6528、2012年2月、<https://www.rfc-editor.org/info/rfc6528>。
[43] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, DOI 10.17487/RFC6691, July 2012, <https://www.rfc-editor.org/info/rfc6691>.
[43] ボーマン、D。、「TCPオプションと最大セグメントサイズ（MSS）」、RFC 6691、DOI 10.17487/RFC6691、2012年7月、<https://www.rfc-editor.org/info/rfc6691>。
[44] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, DOI 10.17487/RFC6864, February 2013, <https://www.rfc-editor.org/info/rfc6864>.
[44] Touch、J。、「IPv4 IDフィールドの更新された仕様」、RFC 6864、DOI 10.17487/RFC6864、2013年2月、<https://www.rfc-editor.org/info/rfc6864>。
[45] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, <https://www.rfc-editor.org/info/rfc6994>.
[45] Touch、J。、「実験的TCPオプションの共有使用」、RFC 6994、DOI 10.17487/RFC6994、2013年8月、<https://www.rfc-editor.org/info/rfc6994>。
[46] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, <https://www.rfc-editor.org/info/rfc7094>.
[46] McPherson、D.、Oran、D.、Thaler、D.、およびE. Osterweil、「IP Anycastの建築上の考慮事項」、RFC 7094、DOI 10.17487/RFC7094、2014年1月、<https：//www.rfc-editor。org/info/rfc7094>。
[47] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.
[47] Borman、D.、Braden、B.、Jacobson、V。、およびR. Scheffenegger、ed。、「高性能のためのTCP拡張」、RFC 7323、DOI 10.17487/RFC7323、2014年9月、<https：//www.rfc-editor.org/info/rfc7323>。
[48] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[48] Cheng、Y.、Chu、J.、Radhakrishnan、S。、およびA. Jain、「TCP Fast Open」、RFC 7413、DOI 10.17487/RFC7413、2014年12月、<https://www.rfc-editor.org/情報/RFC7413>。
[49] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, <https://www.rfc-editor.org/info/rfc7414>.
[49] Duke、M.、Braden、R.、Eddy、W.、Blanton、E。、およびA. Zimmermann、「伝送制御プロトコル（TCP）仕様文書のロードマップ」、RFC 7414、DOI 10.17487/RFC7414、2015年2月、<https://www.rfc-editor.org/info/rfc7414>。
[50] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.
[50] ブラック、D。、編およびP.ジョーンズ、「差別化されたサービス（DIFFSERV）およびリアルタイム通信」、RFC 7657、DOI 10.17487/RFC7657、2015年11月、<https://www.rfc-editor.org/info/rfc7657>。
[51] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017, <https://www.rfc-editor.org/info/rfc8087>.
[51] Fairhurst、G。and M. Welzl、「明示的な混雑通知（ECN）を使用することの利点」、RFC 8087、DOI 10.17487/RFC8087、2017年3月、<https://www.rfc-editor.org/info/rfc87>。
[52] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.
[52] Fairhurst、G.、ed。、Trammell、B.、ed。、およびM. Kuehlewind、ed。、「IETF輸送プロトコルと混雑制御メカニズムが提供するサービス」、RFC 8095、DOI 10.17487/RFC8095、2017年3月、<https：//www.rfc-editor.org/info/rfc8095>。
[53] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of Transport Features Provided by IETF Transport Protocols", RFC 8303, DOI 10.17487/RFC8303, February 2018, <https://www.rfc-editor.org/info/rfc8303>.
[53] Welzl、M.、Tuexen、M。、およびN. Khademi、「IETF輸送プロトコルが提供する輸送機能の使用に関する」、RFC 8303、DOI 10.17487/RFC8303、2018年2月、<https：//www.rfc-editor.org/info/rfc8303>。
[54] Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, <https://www.rfc-editor.org/info/rfc8311>.
[54] Black、D。、「明示的な混雑通知（ECN）実験に対する緩和制限」、RFC 8311、DOI 10.17487/RFC8311、2018年1月、<https://www.rfc-editor.org/info/rfc8311>。
[55] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[55] Chown、T.、Loughney、J。、およびT. Winters、「IPv6ノード要件」、BCP 220、RFC 8504、DOI 10.17487/RFC8504、2019年1月、<https://www.rfc-editor.org/info/RFC8504>。
[56] Trammell, B. and M. Kuehlewind, "The Wire Image of a Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 2019, <https://www.rfc-editor.org/info/rfc8546>.
[56] Trammell、B。およびM. Kuehlewind、「ネットワークプロトコルのワイヤ画像」、RFC 8546、DOI 10.17487/RFC8546、2019年4月、<https://www.rfc-editor.org/info/rfc8546>。
[57] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, Q., and E. Smith, "Cryptographic Protection of TCP Streams (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, <https://www.rfc-editor.org/info/rfc8548>.
[57] Bittau、A.、Giffin、D.、Handley、M.、Mazieres、D.、Slack、Q.、およびE. Smith、「TCPストリームの暗号化保護（TCPCRYPT）」、RFC 8548、DOI 10.17487/RFC8548、5月2019、<https://www.rfc-editor.org/info/rfc8548>。
[58] Hardie, T., Ed., "Transport Protocol Path Signals", RFC 8558, DOI 10.17487/RFC8558, April 2019, <https://www.rfc-editor.org/info/rfc8558>.
[58] Hardie、T.、ed。、「Transport Protocol Path Signals」、RFC 8558、DOI 10.17487/RFC8558、2019年4月、<https://www.rfc-editor.org/info/rfc8558>。
[59] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, <https://www.rfc-editor.org/info/rfc8684>.
[59] Ford、A.、Raiciu、C.、Handley、M.、Bonaventure、O.、およびC. Paasch、「複数のアドレスを備えたマルチパス操作のためのTCP拡張」、RFC 8684、DOI 10.17487/RFC8684、2020年3月、<https：//www.rfc-editor.org/info/rfc8684>。
[60] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[60] Iyengar、J.、ed。and M. Thomson、ed。、「Quic：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487/RFC9000、2021年5月、<https://www.rfc-editor.org/info/rfc9000>
[61] Fairhurst, G. and C. Perkins, "Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols", RFC 9065, DOI 10.17487/RFC9065, July 2021, <https://www.rfc-editor.org/info/rfc9065>.
[61] Fairhurst、G。およびC. Perkins、「輸送ヘッダーの機密性、ネットワーク操作、インターネット輸送プロトコルの進化に関する考慮事項」、RFC 9065、DOI 10.17487/RFC9065、2021年7月、<https：//www.rfc-editor。org/info/rfc9065>。
[62] IANA, "Transmission Control Protocol (TCP) Parameters", <https://www.iana.org/assignments/tcp-parameters/>.
[62] IANA、「伝送制御プロトコル（TCP）パラメーター」、<https://www.iana.org/assignments/tcp-parameters/>。
[63] Gont, F., "Processing of IP Security/Compartment and Precedence Information by TCP", Work in Progress, Internet-Draft, draft-gont-tcpm-tcp-seccomp-prec-00, 29 March 2012, <https://datatracker.ietf.org/doc/html/draft-gont-tcpm-tcp-seccomp-prec-00>.
[63] Gont、F。、「TCPによるIPセキュリティ/コンパートメントおよび優先情報の処理」、作業中の作業、インターネットドラフト、Draft-Gont-TCPM-TCP-SECCOMP-PREC-00、2012年3月29日、<https：//datatracker.ietf.org/doc/html/draft-gont-tcpm-tcp-seccomp-prec-00>。
[64] Gont, F. and D. Borman, "On the Validation of TCP Sequence Numbers", Work in Progress, Internet-Draft, draft-gont-tcpm-tcp-seq-validation-04, 11 March 2019, <https://datatracker.ietf.org/doc/html/draft-gont-tcpm-tcp-seq-validation-04>.
[64] Gont、F。、およびD. Borman、「TCPシーケンス番号の検証について」、作業中の作業、インターネットドラフト、Draft-Gont-TCP-TCP-Validation-04、2019 3月11日、<https：//datatracker.ietf.org/doc/html/draft-gont-tcpm-tcp-seq-validation-04>。
[65] Touch, J. and W. M. Eddy, "TCP Extended Data Offset Option", Work in Progress, Internet-Draft, draft-ietf-tcpm-tcp-edo-12, 15 April 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-edo-12>.
[65] Touch、J。およびW. M. Eddy、「TCP拡張データオフセットオプション」、作業中の作業、インターネットドラフト、ドラフト-ITF-TCPM-TCP-EDO-12、2022年4月15日、<https://datatracker.ietf.org/doc/html/draft-itf-tcpm-tcp-edo-12>。
[66] McQuistin, S., Band, V., Jacob, D., and C. Perkins, "Describing Protocol Data Units with Augmented Packet Header Diagrams", Work in Progress, Internet-Draft, draft-mcquistin-augmented-ascii-diagrams-10, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-mcquistin-augmented-ascii-diagrams-10>.
[66] McQuistin、S.、Band、V.、Jacob、D。、およびC. Perkins、「プロトコルデータユニットの拡張パケットヘッダー図を記述する」、進行中の作業、インターネットドラフト、ドラフトMcquistin-Assi-diagrams--10、2022年3月7日、<https://datatracker.ietf.org/doc/html/draft-mcquistin-augmented-ascii-diagrams -10>。
[67] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170, December 2021, <https://www.rfc-editor.org/info/rfc9170>.
[67] Thomson、M。and T. Pauly、「プロトコル拡張メカニズムの長期実行可能性」、RFC 9170、DOI 10.17487/RFC9170、2021年12月、<https://www.rfc-editor.org/info/rfc9170>。
[68] Minshall, G., "A Suggested Modification to Nagle's Algorithm", Work in Progress, Internet-Draft, draft-minshall-nagle-01, 18 June 1999, <https://datatracker.ietf.org/doc/html/draft-minshall-nagle-01>.
[68] Minshall、G。、「Nagleのアルゴリズムへの提案された変更」、作業中の作業、Internet-Draft、Draft-Minshall-Nagle-01、1999年6月18日、<https://datatracker.ietf.org/doc/html/draft-minshall-nagle-01>。
[69] Dalal, Y. and C. Sunshine, "Connection Management in Transport Protocols", Computer Networks, Vol. 2, No. 6, pp. 454-473, DOI 10.1016/0376-5075(78)90053-3, December 1978, <https://doi.org/10.1016/0376-5075(78)90053-3>.
[69] Dalal、Y。およびC. Sunshine、「輸送プロトコルにおける接続管理」、コンピューターネットワーク、Vol。2、No。6、pp。454-473、DOI 10.1016/0376-5075（78）90053-3、1978年12月、<https://doi.org/10.1016/0376-5075（78）90053-3>。
[70] Faber, T., Touch, J., and W. Yui, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proceedings of IEEE INFOCOM, pp. 1573-1583, DOI 10.1109/INFCOM.1999.752180, March 1999, <https://doi.org/10.1109/INFCOM.1999.752180>.
[70] Faber、T.、Touch、J。、およびW. Yui、「TCPのタイムウェイト状態と忙しいサーバーへの影響」、IEEE Infocomの議事録、pp。1573-1583、doi 10.1109/infcom.1999.752180、3月1999、<https://doi.org/10.1109/infcom.1999.752180>。
[71] Postel, J., "Comments on Action Items from the January Meeting", IEN 177, March 1981, <https://www.rfc-editor.org/ien/ien177.txt>.
[71] Postel、J。、「1月の会議からのアクションアイテムへのコメント」、Ien 177、1981年3月、<https://www.rfc-editor.org/ien/ien177.txt>。
[72] "Segmentation Offloads", The Linux Kernel Documentation, <https://www.kernel.org/doc/html/latest/networking/ segmentation-offloads.html>.
[72] 「セグメンテーションオフロード」、Linuxカーネルドキュメント、<https://www.kernel.org/doc/html/latest/networking/ segmentation-offloads.html>。
[73] RFC Errata, Erratum ID 573, RFC 793, <https://www.rfc-editor.org/errata/eid573>.
[73] RFC Errata、Erratum ID 573、RFC 793、<https://www.rfc-editor.org/errata/eid573>。
[74] RFC Errata, Erratum ID 574, RFC 793, <https://www.rfc-editor.org/errata/eid574>.
[74] RFC Errata、Erratum ID 574、RFC 793、<https://www.rfc-editor.org/errata/eid574>。
[75] RFC Errata, Erratum ID 700, RFC 793, <https://www.rfc-editor.org/errata/eid700>.
[75] RFC Errata、Erratum ID 700、RFC 793、<https://www.rfc-editor.org/errata/eid700>。
[76] RFC Errata, Erratum ID 701, RFC 793, <https://www.rfc-editor.org/errata/eid701>.
[76] RFC Errata、Erratum ID 701、RFC 793、<https://www.rfc-editor.org/errata/eid701>。
[77] RFC Errata, Erratum ID 1283, RFC 793, <https://www.rfc-editor.org/errata/eid1283>.
[77] RFC Errata、Erratum ID 1283、RFC 793、<https://www.rfc-editor.org/errata/eid1283>。
[78] RFC Errata, Erratum ID 1561, RFC 793, <https://www.rfc-editor.org/errata/eid1561>.
[78] RFC Errata、Erratum ID 1561、RFC 793、<https://www.rfc-editor.org/errata/eid1561>。
[79] RFC Errata, Erratum ID 1562, RFC 793, <https://www.rfc-editor.org/errata/eid1562>.
[79] RFC Errata、Erratum ID 1562、RFC 793、<https://www.rfc-editor.org/errata/eid1562>。
[80] RFC Errata, Erratum ID 1564, RFC 793, <https://www.rfc-editor.org/errata/eid1564>.
[80] RFC Errata、Erratum ID 1564、RFC 793、<https://www.rfc-editor.org/errata/eid1564>。
[81] RFC Errata, Erratum ID 1571, RFC 793, <https://www.rfc-editor.org/errata/eid1571>.
[81] RFC Errata、Erratum ID 1571、RFC 793、<https://www.rfc-editor.org/errata/eid1571>。
[82] RFC Errata, Erratum ID 1572, RFC 793, <https://www.rfc-editor.org/errata/eid1572>.
[82] RFC Errata、Erratum ID 1572、RFC 793、<https://www.rfc-editor.org/errata/eid1572>。
[83] RFC Errata, Erratum ID 2297, RFC 793, <https://www.rfc-editor.org/errata/eid2297>.
[83] RFC Errata、Erratum ID 2297、RFC 793、<https://www.rfc-editor.org/errata/eid2297>。
[84] RFC Errata, Erratum ID 2298, RFC 793, <https://www.rfc-editor.org/errata/eid2298>.
[84] RFC Errata、Erratum ID 2298、RFC 793、<https://www.rfc-editor.org/errata/eid2298>。
[85] RFC Errata, Erratum ID 2748, RFC 793, <https://www.rfc-editor.org/errata/eid2748>.
[85] RFC Errata、Erratum ID 2748、RFC 793、<https://www.rfc-editor.org/errata/eid2748>。
[86] RFC Errata, Erratum ID 2749, RFC 793, <https://www.rfc-editor.org/errata/eid2749>.
[86] RFC Errata、Erratum ID 2749、RFC 793、<https://www.rfc-editor.org/errata/eid2749>。
[87] RFC Errata, Erratum ID 2934, RFC 793, <https://www.rfc-editor.org/errata/eid2934>.
[87] RFC Errata、Erratum ID 2934、RFC 793、<https://www.rfc-editor.org/errata/eid2934>。
[88] RFC Errata, Erratum ID 3213, RFC 793, <https://www.rfc-editor.org/errata/eid3213>.
[88] RFC Errata、Erratum ID 3213、RFC 793、<https://www.rfc-editor.org/errata/eid3213>。
[89] RFC Errata, Erratum ID 3300, RFC 793, <https://www.rfc-editor.org/errata/eid3300>.
[89] RFC Errata、Erratum ID 3300、RFC 793、<https://www.rfc-editor.org/errata/eid3300>。
[90] RFC Errata, Erratum ID 3301, RFC 793, <https://www.rfc-editor.org/errata/eid3301>.
[90] RFC Errata、Erratum ID 3301、RFC 793、<https://www.rfc-editor.org/errata/eid3301>。
[91] RFC Errata, Erratum ID 6222, RFC 793, <https://www.rfc-editor.org/errata/eid6222>.
[91] RFC Errata、Erratum ID 6222、RFC 793、<https://www.rfc-editor.org/errata/eid6222>。
[92] RFC Errata, Erratum ID 572, RFC 793, <https://www.rfc-editor.org/errata/eid572>.
[92] RFC Errata、Erratum ID 572、RFC 793、<https://www.rfc-editor.org/errata/eid572>。
[93] RFC Errata, Erratum ID 575, RFC 793, <https://www.rfc-editor.org/errata/eid575>.
[93] RFC Errata、Erratum ID 575、RFC 793、<https://www.rfc-editor.org/errata/eid575>。
[94] RFC Errata, Erratum ID 1565, RFC 793, <https://www.rfc-editor.org/errata/eid1565>.
[94] RFC Errata、Erratum ID 1565、RFC 793、<https://www.rfc-editor.org/errata/eid1565>。
[95] RFC Errata, Erratum ID 1569, RFC 793, <https://www.rfc-editor.org/errata/eid1569>.
[95] RFC Errata、Erratum ID 1569、RFC 793、<https://www.rfc-editor.org/errata/eid1569>。
[96] RFC Errata, Erratum ID 2296, RFC 793, <https://www.rfc-editor.org/errata/eid2296>.
[96] RFC Errata、Erratum ID 2296、RFC 793、<https://www.rfc-editor.org/errata/eid2296>。
[97] RFC Errata, Erratum ID 3305, RFC 793, <https://www.rfc-editor.org/errata/eid3305>.
[97] RFC Errata、Erratum ID 3305、RFC 793、<https://www.rfc-editor.org/errata/eid3305>。
[98] RFC Errata, Erratum ID 3602, RFC 793, <https://www.rfc-editor.org/errata/eid3602>.
[98] RFC Errata、Erratum ID 3602、RFC 793、<https://www.rfc-editor.org/errata/eid3602>。
[99] RFC Errata, Erratum ID 4772, RFC 5961, <https://www.rfc-editor.org/errata/eid4772>.
[99] RFC Errata、Erratum ID 4772、RFC 5961、<https://www.rfc-editor.org/errata/eid4772>。
[100] Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010, <https://www.rfc-editor.org/info/rfc5927>.
[100] Gont、F。、「TCPに対するICMP攻撃」、RFC 5927、DOI 10.17487/RFC5927、2010年7月、<https://www.rfc-editor.org/info/rfc5927>。
This section includes additional notes and references on TCP implementation decisions that are currently not a part of the RFC series or included within the TCP standard. These items can be considered by implementers, but there was not yet a consensus to include them in the standard.
このセクションには、現在RFCシリーズの一部ではない、またはTCP標準に含まれるTCP実装決定に関する追加のメモと参照が含まれています。これらの項目は実装者が考慮することができますが、標準にそれらを含めるコンセンサスはまだありませんでした。
The IPv4 specification [1] includes a precedence value in the (now obsoleted) Type of Service (TOS) field. It was modified in [20] and then obsoleted by the definition of Differentiated Services (Diffserv) [4]. Setting and conveying TOS between the network layer, TCP implementation, and applications is obsolete and is replaced by Diffserv in the current TCP specification.
IPv4仕様[1]には、（現在は廃止された）サービス（TOS）フィールドに優先値が含まれています。[20]で修正され、差別化されたサービスの定義（diffserv）[4]によって廃止されました。ネットワークレイヤー、TCP実装、およびアプリケーション間のTOSの設定と伝達は時代遅れであり、現在のTCP仕様のdiffservに置き換えられます。
RFC 793 required checking the IP security compartment and precedence on incoming TCP segments for consistency within a connection and with application requests. Each of these aspects of IP have become outdated, without specific updates to RFC 793. The issues with precedence were fixed by [25], which is Standards Track, and so this present TCP specification includes those changes. However, the state of IP security options that may be used by Multi-Level Secure (MLS) systems is not as apparent in the IETF currently.
RFC 793は、接続内およびアプリケーションリクエストを使用して、IPセキュリティコンパートメントと着信TCPセグメントの優先順位をチェックする必要がありました。IPのこれらの各側面は、RFC 793の具体的な更新なしで時代遅れになりました。優先順位の問題は[25]（25]によって修正され、標準の追跡であるため、この現在のTCP仕様にはそれらの変更が含まれています。ただし、Multi-Level Secure（MLS）システムで使用される可能性のあるIPセキュリティオプションの状態は、現在IETFでは明らかではありません。
Resetting connections when incoming packets do not meet expected security compartment or precedence expectations has been recognized as a possible attack vector [63], and there has been discussion about amending the TCP specification to prevent connections from being aborted due to nonmatching IP security compartment and Diffserv codepoint values.
接続のリセット着信パケットが予想されるセキュリティコンパートメントまたは優先順位の期待が攻撃ベクトルとして認識されている[63]として認識されており、IPセキュリティコンパートメントと拡散の不一致のために接続が中止されるのを防ぐためのTCP仕様の修正に関する議論がありましたCodePoint値。
In Diffserv, the former precedence values are treated as Class Selector codepoints, and methods for compatible treatment are described in the Diffserv architecture. The RFC TCP specification defined by RFCs 793 and 1122 included logic intending to have connections use the highest precedence requested by either endpoint application, and to keep the precedence consistent throughout a connection. This logic from the obsolete TOS is not applicable to Diffserv and should not be included in TCP implementations, though changes to Diffserv values within a connection are discouraged. For discussion of this, see RFC 7657 (Sections 5.1, 5.3, and 6) [50].
diffservでは、以前の優先順位値はクラスセレクターのコードポイントとして扱われ、互換性のある治療の方法はdiffservアーキテクチャに記載されています。RFCS 793および1122で定義されたRFC TCP仕様には、いずれかのエンドポイントアプリケーションで要求された最高の優先順位を接続することを意図したロジックが含まれ、接続全体で優先順位を一貫させ続けることが含まれています。時代遅れのTOSからのこのロジックは、DiffServには適用されず、TCP実装に含めるべきではありませんが、接続内のDiffserv値の変更は推奨されません。この議論については、RFC 7657（セクション5.1、5.3、および6）[50]を参照してください。
The obsoleted TOS processing rules in TCP assumed bidirectional (or symmetric) precedence values used on a connection, but the Diffserv architecture is asymmetric. Problems with the old TCP logic in this regard were described in [25], and the solution described is to ignore IP precedence in TCP. Since RFC 2873 is a Standards Track document (although not marked as updating RFC 793), current implementations are expected to be robust in these conditions. Note that the Diffserv field value used in each direction is a part of the interface between TCP and the network layer, and values in use can be indicated both ways between TCP and the application.
TCPの廃止されたTOS処理ルールは、接続で使用される双方向（または対称）の優先値を想定していますが、DiffServアーキテクチャは非対称です。この点で古いTCPロジックの問題は[25]で説明されており、説明されている解決策は、TCPのIP優先順位を無視することです。RFC 2873は標準トラックドキュメントであるため（RFC 793の更新とはマークされていません）、これらの条件では現在の実装が堅牢であると予想されます。各方向で使用されるdifServフィールド値は、TCPとネットワークレイヤーの間のインターフェースの一部であり、使用中の値はTCPとアプリケーションの間で両方の方法を示すことができることに注意してください。
The IP Security Option (IPSO) and compartment defined in [1] was refined in RFC 1038, which was later obsoleted by RFC 1108. The Commercial IP Security Option (CIPSO) is defined in FIPS-188 (withdrawn by NIST in 2015) and is supported by some vendors and operating systems. RFC 1108 is now Historic, though RFC 791 itself has not been updated to remove the IP Security Option. For IPv6, a similar option (Common Architecture Label IPv6 Security Option (CALIPSO)) has been defined [36]. RFC 793 includes logic that includes the IP security/compartment information in treatment of TCP segments. References to the IP "security/compartment" in this document may be relevant for Multi-Level Secure (MLS) system implementers but can be ignored for non-MLS implementations, consistent with running code on the Internet. See Appendix A.1 for further discussion. Note that RFC 5570 describes some MLS networking scenarios where IPSO, CIPSO, or CALIPSO may be used. In these special cases, TCP implementers should see Section 7.3.1 of RFC 5570 and follow the guidance in that document.
[1]で定義されているIPセキュリティオプション（IPSO）とコンパートメントは、RFC 1038で洗練され、後にRFC 1108によって廃止されました。商用IPセキュリティオプション（CIPSO）は、FIPS-188（2015年にNISTによって撤回）で定義され、一部のベンダーとオペレーティングシステムによってサポートされています。 RFC 1108は現在歴史的ですが、RFC 791自体はIPセキュリティオプションを削除するために更新されていません。 IPv6の場合、同様のオプション（一般的なアーキテクチャラベルIPv6セキュリティオプション（CALIPSO））が定義されています[36]。 RFC 793には、TCPセグメントの処理におけるIPセキュリティ/コンパートメント情報を含むロジックが含まれています。このドキュメントのIP「セキュリティ/コンパートメント」への参照は、マルチレベルSecure（MLS）システムの実装者に関連する場合がありますが、インターネット上での実行コードと一致する非MLS実装では無視できます。詳細については、付録A.1を参照してください。 RFC 5570は、IPSO、CIPSO、またはCalipsoを使用する場合があるMLSネットワークシナリオをいくつか説明していることに注意してください。これらの特別なケースでは、TCP実装者はRFC 5570のセクション7.3.1を表示し、そのドキュメントのガイダンスに従う必要があります。
There are cases where the TCP sequence number validation rules can prevent ACK fields from being processed. This can result in connection issues, as described in [64], which includes descriptions of potential problems in conditions of simultaneous open, self-connects, simultaneous close, and simultaneous window probes. The document also describes potential changes to the TCP specification to mitigate the issue by expanding the acceptable sequence numbers.
TCPシーケンス番号検証ルールがACKフィールドの処理を防ぐことができる場合があります。これは、[64]で説明されているように、接続の問題をもたらす可能性があります。これには、同時オープン、セルフ接続、同時閉鎖、および同時ウィンドウプローブの条件における潜在的な問題の説明が含まれます。ドキュメントでは、許容可能なシーケンス番号を拡大することにより、問題を軽減するためのTCP仕様の潜在的な変更についても説明しています。
In Internet usage of TCP, these conditions rarely occur. Common operating systems include different alternative mitigations, and the standard has not been updated yet to codify one of them, but implementers should consider the problems described in [64].
TCPのインターネット使用では、これらの条件はめったに発生しません。一般的なオペレーティングシステムには、さまざまな代替緩和が含まれており、その標準はまだ更新されていませんが、そのうちの1つを成文化していますが、実装者は[64]で説明されている問題を考慮する必要があります。
In common operating systems, both the Nagle algorithm and delayed acknowledgments are implemented and enabled by default. TCP is used by many applications that have a request-response style of communication, where the combination of the Nagle algorithm and delayed acknowledgments can result in poor application performance. A modification to the Nagle algorithm is described in [68] that improves the situation for these applications.
一般的なオペレーティングシステムでは、Nagleアルゴリズムと遅延承認の両方が実装され、デフォルトで有効になります。TCPは、リクエスト応答スタイルの通信を備えた多くのアプリケーションで使用されます。このアプリケーションは、ナグルアルゴリズムと遅延承認の組み合わせにより、アプリケーションのパフォーマンスが低下する可能性があります。これらのアプリケーションの状況を改善するNagleアルゴリズムの変更は[68]で説明されています。
This modification is implemented in some common operating systems and does not impact TCP interoperability. Additionally, many applications simply disable Nagle since this is generally supported by a socket option. The TCP standard has not been updated to include this Nagle modification, but implementers may find it beneficial to consider.
この変更は、一部の一般的なオペレーティングシステムで実装されており、TCPの相互運用性に影響しません。さらに、多くのアプリケーションは、一般的にソケットオプションによってサポートされているため、Nagleを単に無効にします。TCP標準は、このナグルの変更を含めるように更新されていませんが、実装者は考慮することが有益であると感じるかもしれません。
Some operating system kernel TCP implementations include socket options that allow specifying the number of bytes in the buffer until the socket layer will pass sent data to TCP (SO_SNDLOWAT) or to the application on receiving (SO_RCVLOWAT).
一部のオペレーティングシステムカーネルTCP実装には、ソケット層が送信されるデータ（SO_SNDLOWAT）または受信時のアプリケーション（SO_RCVLOWAT）に送信されるまでバッファ内のバイト数を指定できるソケットオプションが含まれています。
In addition, another socket option (TCP_NOTSENT_LOWAT) can be used to control the amount of unsent bytes in the write queue. This can help a sending TCP application to avoid creating large amounts of buffered data (and corresponding latency). As an example, this may be useful for applications that are multiplexing data from multiple upper-level streams onto a connection, especially when streams may be a mix of interactive/real-time and bulk data transfer.
さらに、別のソケットオプション（TCP_NOTSENT_LOWAT）を使用して、書き込みキュー内の無関係なバイトの量を制御できます。これにより、TCPアプリケーションを送信して、大量のバッファーデータ（および対応するレイテンシ）の作成を避けるのに役立ちます。例として、これは、特にストリームがインタラクティブ/リアルタイムとバルクデータ転送の組み合わせである場合、複数の上位レベルのストリームからデータを接続にマルチプレックスするアプリケーションに役立つ場合があります。
This section is adapted from RFC 1122.
このセクションは、RFC 1122から採用されています。
Note that there is no requirement related to PLPMTUD in this list, but that PLPMTUD is recommended.
このリストにはPLPMTUDに関連する要件はありませんが、PLPMTUDが推奨されることに注意してください。
+=================+=========+======+========+=====+========+======+
| Feature | ReqID | MUST | SHOULD | MAY | SHOULD | MUST |
| | | | | | NOT | NOT |
+=================+=========+======+========+=====+========+======+
| PUSH flag |
+=================+=========+======+========+=====+========+======+
| Aggregate or | MAY-16 | | | X | | |
| queue un-pushed | | | | | | |
| data | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Sender collapse | SHLD-27 | | X | | | |
| successive PSH | | | | | | |
| bits | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| SEND call can | MAY-15 | | | X | | |
| specify PUSH | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * If cannot: | MUST-60 | | | | | X |
| sender | | | | | | |
| buffer | | | | | | |
| indefinitely | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * If cannot: | MUST-61 | X | | | | |
| PSH last | | | | | | |
| segment | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Notify | MAY-17 | | | X | | |
| receiving ALP^1 | | | | | | |
| of PSH | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Send max size | SHLD-28 | | X | | | |
| segment when | | | | | | |
| possible | | | | | | |
+=================+=========+======+========+=====+========+======+
| Window |
+=================+=========+======+========+=====+========+======+
| Treat as | MUST-1 | X | | | | |
| unsigned number | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Handle as | REC-1 | | X | | | |
| 32-bit number | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Shrink window | SHLD-14 | | | | X | |
| from right | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Send new | SHLD-15 | | | | X | |
| data when | | | | | | |
| window | | | | | | |
| shrinks | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Retransmit | SHLD-16 | | X | | | |
| old unacked | | | | | | |
| data within | | | | | | |
| window | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Time out | SHLD-17 | | | | X | |
| conn for | | | | | | |
| data past | | | | | | |
| right edge | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Robust against | MUST-34 | X | | | | |
| shrinking | | | | | | |
| window | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Receiver's | MAY-8 | | | X | | |
| window closed | | | | | | |
| indefinitely | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Use standard | MUST-35 | X | | | | |
| probing logic | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Sender probe | MUST-36 | X | | | | |
| zero window | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * First probe | SHLD-29 | | X | | | |
| after RTO | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Exponential | SHLD-30 | | X | | | |
| backoff | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Allow window | MUST-37 | X | | | | |
| stay zero | | | | | | |
| indefinitely | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Retransmit old | MAY-7 | | | X | | |
| data beyond | | | | | | |
| SND.UNA+SND.WND | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Process RST and | MUST-66 | X | | | | |
| URG even with | | | | | | |
| zero window | | | | | | |
+=================+=========+======+========+=====+========+======+
| Urgent Data |
+=================+=========+======+========+=====+========+======+
| Include support | MUST-30 | X | | | | |
| for urgent | | | | | | |
| pointer | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Pointer | MUST-62 | X | | | | |
| indicates first | | | | | | |
| non-urgent | | | | | | |
| octet | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Arbitrary | MUST-31 | X | | | | |
| length urgent | | | | | | |
| data sequence | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Inform ALP^1 | MUST-32 | X | | | | |
| asynchronously | | | | | | |
| of urgent data | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| ALP^1 can learn | MUST-33 | X | | | | |
| if/how much | | | | | | |
| urgent data Q'd | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| ALP employ the | SHLD-13 | | | | X | |
| urgent | | | | | | |
| mechanism | | | | | | |
+=================+=========+======+========+=====+========+======+
| TCP Options |
+=================+=========+======+========+=====+========+======+
| Support the | MUST-4 | X | | | | |
| mandatory | | | | | | |
| option set | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Receive TCP | MUST-5 | X | | | | |
| Option in any | | | | | | |
| segment | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Ignore | MUST-6 | X | | | | |
| unsupported | | | | | | |
| options | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Include length | MUST-68 | X | | | | |
| for all options | | | | | | |
| except EOL+NOP | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Cope with | MUST-7 | X | | | | |
| illegal option | | | | | | |
| length | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Process options | MUST-64 | X | | | | |
| regardless of | | | | | | |
| word alignment | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Implement | MUST-14 | X | | | | |
| sending & | | | | | | |
| receiving MSS | | | | | | |
| Option | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| IPv4 Send MSS | SHLD-5 | | X | | | |
| Option unless | | | | | | |
| 536 | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| IPv6 Send MSS | SHLD-5 | | X | | | |
| Option unless | | | | | | |
| 1220 | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Send MSS Option | MAY-3 | | | X | | |
| always | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| IPv4 Send-MSS | MUST-15 | X | | | | |
| default is 536 | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| IPv6 Send-MSS | MUST-15 | X | | | | |
| default is 1220 | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Calculate | MUST-16 | X | | | | |
| effective send | | | | | | |
| seg size | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| MSS accounts | SHLD-6 | | X | | | |
| for varying MTU | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| MSS not sent on | MUST-65 | | | | | X |
| non-SYN | | | | | | |
| segments | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| MSS value based | MUST-67 | X | | | | |
| on MMS_R | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Pad with zero | MUST-69 | X | | | | |
+=================+=========+======+========+=====+========+======+
| TCP Checksums |
+=================+=========+======+========+=====+========+======+
| Sender compute | MUST-2 | X | | | | |
| checksum | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Receiver check | MUST-3 | X | | | | |
| checksum | | | | | | |
+=================+=========+======+========+=====+========+======+
| ISN Selection |
+=================+=========+======+========+=====+========+======+
| Include a | MUST-8 | X | | | | |
| clock-driven | | | | | | |
| ISN generator | | | | | | |
| component | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Secure ISN | SHLD-1 | | X | | | |
| generator with | | | | | | |
| a PRF component | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| PRF computable | MUST-9 | | | | | X |
| from outside | | | | | | |
| the host | | | | | | |
+=================+=========+======+========+=====+========+======+
| Opening Connections |
+=================+=========+======+========+=====+========+======+
| Support | MUST-10 | X | | | | |
| simultaneous | | | | | | |
| open attempts | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| SYN-RECEIVED | MUST-11 | X | | | | |
| remembers last | | | | | | |
| state | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Passive OPEN | MUST-41 | | | | | X |
| call interfere | | | | | | |
| with others | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Function: | MUST-42 | X | | | | |
| simultaneously | | | | | | |
| LISTENs for | | | | | | |
| same port | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Ask IP for src | MUST-44 | X | | | | |
| address for SYN | | | | | | |
| if necessary | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Otherwise, | MUST-45 | X | | | | |
| use local | | | | | | |
| addr of | | | | | | |
| connection | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| OPEN to | MUST-46 | | | | | X |
| broadcast/ | | | | | | |
| multicast IP | | | | | | |
| address | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Silently | MUST-57 | X | | | | |
| discard seg to | | | | | | |
| bcast/mcast | | | | | | |
| addr | | | | | | |
+=================+=========+======+========+=====+========+======+
| Closing Connections |
+=================+=========+======+========+=====+========+======+
| RST can contain | SHLD-2 | | X | | | |
| data | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Inform | MUST-12 | X | | | | |
| application of | | | | | | |
| aborted conn | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Half-duplex | MAY-1 | | | X | | |
| close | | | | | | |
| connections | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Send RST to | SHLD-3 | | X | | | |
| indicate | | | | | | |
| data lost | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| In TIME-WAIT | MUST-13 | X | | | | |
| state for 2MSL | | | | | | |
| seconds | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Accept SYN | MAY-2 | | | X | | |
| from TIME- | | | | | | |
| WAIT state | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Use | SHLD-4 | | X | | | |
| Timestamps | | | | | | |
| to reduce | | | | | | |
| TIME-WAIT | | | | | | |
+=================+=========+======+========+=====+========+======+
| Retransmissions |
+=================+=========+======+========+=====+========+======+
| Implement | MUST-19 | X | | | | |
| exponential | | | | | | |
| backoff, slow | | | | | | |
| start, and | | | | | | |
| congestion | | | | | | |
| avoidance | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Retransmit with | MAY-4 | | | X | | |
| same IP | | | | | | |
| identity | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Karn's | MUST-18 | X | | | | |
| algorithm | | | | | | |
+=================+=========+======+========+=====+========+======+
| Generating ACKs |
+=================+=========+======+========+=====+========+======+
| Aggregate | MUST-58 | X | | | | |
| whenever | | | | | | |
| possible | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Queue out-of- | SHLD-31 | | X | | | |
| order segments | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Process all Q'd | MUST-59 | X | | | | |
| before send ACK | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Send ACK for | MAY-13 | | | X | | |
| out-of-order | | | | | | |
| segment | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Delayed ACKs | SHLD-18 | | X | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Delay < 0.5 | MUST-40 | X | | | | |
| seconds | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Every 2nd | SHLD-19 | | X | | | |
| full-sized | | | | | | |
| segment or | | | | | | |
| 2*RMSS ACK'd | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Receiver SWS- | MUST-39 | X | | | | |
| Avoidance | | | | | | |
| Algorithm | | | | | | |
+=================+=========+======+========+=====+========+======+
| Sending Data |
+=================+=========+======+========+=====+========+======+
| Configurable | MUST-49 | X | | | | |
| TTL | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Sender SWS- | MUST-38 | X | | | | |
| Avoidance | | | | | | |
| Algorithm | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Nagle algorithm | SHLD-7 | | X | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Application | MUST-17 | X | | | | |
| can disable | | | | | | |
| Nagle | | | | | | |
| algorithm | | | | | | |
+=================+=========+======+========+=====+========+======+
| Connection Failures |
+=================+=========+======+========+=====+========+======+
| Negative advice | MUST-20 | X | | | | |
| to IP on R1 | | | | | | |
| retransmissions | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Close | MUST-20 | X | | | | |
| connection on | | | | | | |
| R2 | | | | | | |
| retransmissions | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| ALP^1 can set | MUST-21 | X | | | | |
| R2 | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Inform ALP of | SHLD-9 | | X | | | |
| R1<=retxs<R2 | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Recommended | SHLD-10 | | X | | | |
| value for R1 | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Recommended | SHLD-11 | | X | | | |
| value for R2 | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Same mechanism | MUST-22 | X | | | | |
| for SYNs | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * R2 at least | MUST-23 | X | | | | |
| 3 minutes | | | | | | |
| for SYN | | | | | | |
+=================+=========+======+========+=====+========+======+
| Send Keep-alive Packets |
+=================+=========+======+========+=====+========+======+
| Send Keep-alive | MAY-5 | | X | | | |
| Packets: | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Application | MUST-24 | X | | | | |
| can request | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Default is | MUST-25 | X | | | | |
| "off" | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Only send if | MUST-26 | X | | | | |
| idle for | | | | | | |
| interval | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Interval | MUST-27 | X | | | | |
| configurable | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Default at | MUST-28 | X | | | | |
| least 2 hrs. | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Tolerant of | MUST-29 | X | | | | |
| lost ACKs | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Send with no | SHLD-12 | | X | | | |
| data | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Configurable | MAY-6 | | | X | | |
| to send | | | | | | |
| garbage | | | | | | |
| octet | | | | | | |
+=================+=========+======+========+=====+========+======+
| IP Options |
+=================+=========+======+========+=====+========+======+
| Ignore options | MUST-50 | X | | | | |
| TCP doesn't | | | | | | |
| understand | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Timestamp | MAY-10 | | X | | | |
| support | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Record Route | MAY-11 | | X | | | |
| support | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Source Route: | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * ALP^1 can | MUST-51 | X | | | | |
| specify | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Overrides | MUST-52 | X | | | | |
| src route | | | | | | |
| in | | | | | | |
| datagram | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Build return | MUST-53 | X | | | | |
| route from | | | | | | |
| src route | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Later src | SHLD-24 | | X | | | |
| route | | | | | | |
| overrides | | | | | | |
+=================+=========+======+========+=====+========+======+
| Receiving ICMP Messages from IP |
+=================+=========+======+========+=====+========+======+
| Receiving ICMP | MUST-54 | X | | | | |
| messages from | | | | | | |
| IP | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Dest Unreach | SHLD-25 | X | | | | |
| (0,1,5) => | | | | | | |
| inform ALP | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Abort on | MUST-56 | | | | | X |
| Dest Unreach | | | | | | |
| (0,1,5) | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Dest Unreach | SHLD-26 | | X | | | |
| (2-4) => | | | | | | |
| abort conn | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Source | MUST-55 | X | | | | |
| Quench => | | | | | | |
| silent | | | | | | |
| discard | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Abort on | MUST-56 | | | | | X |
| Time | | | | | | |
| Exceeded | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Abort on | MUST-56 | | | | | X |
| Param | | | | | | |
| Problem | | | | | | |
+=================+=========+======+========+=====+========+======+
| Address Validation |
+=================+=========+======+========+=====+========+======+
| Reject OPEN | MUST-46 | X | | | | |
| call to invalid | | | | | | |
| IP address | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Reject SYN from | MUST-63 | X | | | | |
| invalid IP | | | | | | |
| address | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Silently | MUST-57 | X | | | | |
| discard SYN to | | | | | | |
| bcast/mcast | | | | | | |
| addr | | | | | | |
+=================+=========+======+========+=====+========+======+
| TCP/ALP Interface Services |
+=================+=========+======+========+=====+========+======+
| Error Report | MUST-47 | X | | | | |
| mechanism | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| ALP can disable | SHLD-20 | | X | | | |
| Error Report | | | | | | |
| Routine | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| ALP can specify | MUST-48 | X | | | | |
| Diffserv field | | | | | | |
| for sending | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| * Passed | SHLD-22 | | X | | | |
| unchanged to | | | | | | |
| IP | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| ALP can change | SHLD-21 | | X | | | |
| Diffserv field | | | | | | |
| during | | | | | | |
| connection | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| ALP generally | SHLD-23 | | | | X | |
| changing | | | | | | |
| Diffserv during | | | | | | |
| conn. | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| Pass received | MAY-9 | | | X | | |
| Diffserv field | | | | | | |
| up to ALP | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
| FLUSH call | MAY-14 | | | X | | |
+-----------------+---------+------+--------+-----+--------+------+
| Optional local | MUST-43 | X | | | | |
| IP addr param | | | | | | |
| in OPEN | | | | | | |
+=================+=========+======+========+=====+========+======+
| RFC 5961 Support |
+=================+=========+======+========+=====+========+======+
| Implement data | MAY-12 | | | X | | |
| injection | | | | | | |
| protection | | | | | | |
+=================+=========+======+========+=====+========+======+
| Explicit Congestion Notification |
+=================+=========+======+========+=====+========+======+
| Support ECN | SHLD-8 | | X | | | |
+=================+=========+======+========+=====+========+======+
| Alternative Congestion Control |
+=================+=========+======+========+=====+========+======+
| Implement | MAY-18 | | | X | | |
| alternative | | | | | | |
| conformant | | | | | | |
| algorithm(s) | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
Table 8: TCP Requirements Summary
表8：TCP要件の概要
FOOTNOTES: (1) "ALP" means Application-Layer Program.
脚注：（1）「ALP」とは、アプリケーション層プログラムを意味します。
Acknowledgments
謝辞
This document is largely a revision of RFC 793, of which Jon Postel was the editor. Due to his excellent work, it was able to last for three decades before we felt the need to revise it.
このドキュメントは、主にRFC 793の改訂版であり、そのうちJon Postelが編集者でした。彼の優れた作品のために、それを修正する必要性を感じる前に30年間続くことができました。
Andre Oppermann was a contributor and helped to edit the first revision of this document.
Andre Oppermannは貢献者であり、このドキュメントの最初の改訂を編集するのを手伝いました。
We are thankful for the assistance of the IETF TCPM working group chairs over the course of work on this document:
このドキュメントの作業中のIETF TCPMワーキンググループチェアの支援に感謝しています。
Michael Scharf
マイケル・シャーフ
Yoshifumi Nishida
ヨシフミ西田
Pasi Sarolahti
Pasi Sarolahti
Michael Tüxen
マイケル・チューセン
During the discussions of this work on the TCPM mailing list, in working group meetings, and via area reviews, helpful comments, critiques, and reviews were received from (listed alphabetically by last name): Praveen Balasubramanian, David Borman, Mohamed Boucadair, Bob Briscoe, Neal Cardwell, Yuchung Cheng, Martin Duke, Francis Dupont, Ted Faber, Gorry Fairhurst, Fernando Gont, Rodney Grimes, Yi Huang, Rahul Jadhav, Markku Kojo, Mike Kosek, Juhamatti Kuusisaari, Kevin Lahey, Kevin Mason, Matt Mathis, Stephen McQuistin, Jonathan Morton, Matt Olson, Tommy Pauly, Tom Petch, Hagen Paul Pfeifer, Kyle Rose, Anthony Sabatini, Michael Scharf, Greg Skinner, Joe Touch, Michael Tüxen, Reji Varghese, Bernie Volz, Tim Wicinski, Lloyd Wood, and Alex Zimmermann.
TCPMメーリングリスト、ワーキンググループミーティング、エリアレビューを介して、この作業の議論の中で、有益なコメント、批評、レビューは（姓ごとにアルファベット順にリストされています）：Praveen Balasubramanian、David Borman、Mohamed Boucadair、Bob Bobから受け取りました。ブリスコー、ニール・カードウェル、ユシュン・チェン、マーティン・デューク、フランシス・デュポン、テッド・フェイバー、ゴリー・フェアハースト、フェルナンド・ゴント、ロドニー・グライムズ、YI Huang、Rahul Jadhav、Markku Kojo、Mike Kosek、Juhamatti Kuusisaariスティーブン・マクキスチン、ジョナサン・モートン、マット・オルソン、トミー・ポーリー、トム・ペッチ、ハーゲン・ポール・ファイファー、カイル・ローズ、アンソニー・サバティーニ、マイケル・シャーフ、グレッグ・スキナー、ジョー・タッチ、マイケル・チューセン、レジ・ヴァルゲーゼ、バーニー・ヴォルツ、ティム・ウィシンキ、ロイド・ウッド、ロイド・ウッド、アレックス・ジマーマン。
Joe Touch provided additional help in clarifying the description of segment size parameters and PMTUD/PLPMTUD recommendations. Markku Kojo helped put together the text in the section on TCP Congestion Control.
Joe Touchは、セグメントサイズのパラメーターとPMTUD/PLPMTUDの推奨事項の説明を明確にするために追加のヘルプを提供しました。Markku Kojoは、TCP混雑制御のセクションにテキストをまとめるのを手伝いました。
This document includes content from errata that were reported by (listed chronologically): Yin Shuming, Bob Braden, Morris M. Keesan, Pei-chun Cheng, Constantin Hagemeier, Vishwas Manral, Mykyta Yevstifeyev, EungJun Yi, Botong Huang, Charles Deng, Merlin Buge.
このドキュメントには、（年代順にリストされている）が報告されたERRATAのコンテンツが含まれています：Yin Shuming、Bob Braden、Morris M. Keesan、Pei-Chun Cheng、Constantin Hagemeier、Vishwas Manral、Mykyta Yevstifeev、Eungjun Yi、Botong Huang、Charles Deng、Merlinバージ。
Author's Address
著者の連絡先
Wesley M. Eddy (editor) MTI Systems United States of America Email: wes@mti-systems.com
Wesley M. Eddy（編集者）MTI Systems United Of America Email：wes@mti-Systems.com