RFC879 日本語訳
0879 TCP maximum segment size and related topics. J. Postel. November 1983. (Format: TXT=22024 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Postel Request for Comments: 879 ISI November 1983
コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 879 ISI1983年11月
The TCP Maximum Segment Size and Related Topics
TCPの最大のセグメントサイズと関連した話題
This memo discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers".
このメモはTCP Maximum Segment Size Optionと関連した話題について議論します。 目的はTCPのいくつかの局面とIPとのその相互作用をはっきりさせることです。 このメモは、TCP仕様への明確化であり、「implementersへのアドバイス」であるとみなされるかもしれない情報を含んでいます。
1. Introduction
1. 序論
This memo discusses the TCP Maximum Segment Size and its relation to the IP Maximum Datagram Size. TCP is specified in reference [1]. IP is specified in references [2,3].
このメモはIP MaximumデータグラムSizeとのTCP Maximum Segment Sizeとその関係について議論します。 TCPは参照[1]で指定されます。 IPは参照[2、3]で指定されます。
This discussion is necessary because the current specification of this TCP option is ambiguous.
このTCPオプションの現在の仕様があいまいであるので、この議論が必要です。
Much of the difficulty with understanding these sizes and their relationship has been due to the variable size of the IP and TCP headers.
これらのサイズとそれらの関係を理解する困難の多くがIPとTCPヘッダーの可変サイズのためです。
There have been some assumptions made about using other than the default size for datagrams with some unfortunate results.
いくつかの不幸な結果があるデータグラムのためのデフォルトサイズを除いて、使用に関してされたいくつかの仮定がありました。
HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO ACCEPT LARGER DATAGRAMS.
それらにあて先ホストが、より大きいデータグラムを受け入れる用意ができているという特定の知識がないなら、ホストは576の八重奏より大きいデータグラムを送ってはいけません。
This is a long established rule.
これは長い定則です。
To resolve the ambiguity in the TCP Maximum Segment Size option definition the following rule is established:
TCP Maximum Segment Sizeオプション定義におけるあいまいさを取り除くために、以下の規則は確立されます:
THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS FORTY.
TCPの最大のセグメントサイズはIPの最大のデータグラムサイズマイナスFORTYです。
The default IP Maximum Datagram Size is 576. The default TCP Maximum Segment Size is 536.
デフォルトIP MaximumデータグラムSizeは576歳です。 デフォルトTCP Maximum Segment Sizeは536歳です。
Postel [Page 1]
ポステル[1ページ]
RFC 879 November 1983 TCP Maximum Segment Size
RFC879の1983年11月のTCPの最大のセグメントサイズ
2. The IP Maximum Datagram Size
2. IPの最大のデータグラムサイズ
Hosts are not required to reassemble infinitely large IP datagrams. The maximum size datagram that all hosts are required to accept or reassemble from fragments is 576 octets. The maximum size reassembly buffer every host must have is 576 octets. Hosts are allowed to accept larger datagrams and assemble fragments into larger datagrams, hosts may have buffers as large as they please.
ホストは大きいIPデータグラムを無限に組み立て直す必要はありません。すべてのホストが断片から受け入れるか、または組み立て直すのに必要である最大サイズデータグラムは576の八重奏です。 すべてのホストが持たなければならない最大サイズ再アセンブリバッファは576の八重奏です。 ホストは、より大きいデータグラムを受け入れて、より大きいデータグラムに断片を組み立てることができて、ホストは好きなようにバッファを大きくするかもしれません。
Hosts must not send datagrams larger than 576 octets unless they have specific knowledge that the destination host is prepared to accept larger datagrams.
それらにあて先ホストが、より大きいデータグラムを受け入れる用意ができているという特定の知識がないなら、ホストは576の八重奏より大きいデータグラムを送ってはいけません。
3. The TCP Maximum Segment Size Option
3. TCPの最大のセグメントサイズオプション
TCP provides an option that may be used at the time a connection is established (only) to indicate the maximum size TCP segment that can be accepted on that connection. This Maximum Segment Size (MSS) announcement (often mistakenly called a negotiation) is sent from the data receiver to the data sender and says "I can accept TCP segments up to size X". The size (X) may be larger or smaller than the default. The MSS can be used completely independently in each direction of data flow. The result may be quite different maximum sizes in the two directions.
TCPは接続が確立されて、(単に、)その接続のときに受け入れることができる最大サイズTCPセグメントを示すとき使用されるかもしれないオプションを提供します。 このMaximum Segment Size(MSS)発表(しばしば誤って交渉と呼ばれる)は、データ受信装置からデータ送付者に送られて、「私はTCPセグメントをサイズXまで受け入れることができます。」と言います。 サイズ(X)は、デフォルトよりさらに大きいか、または小さいかもしれません。 独自にデータフローの各方向にMSSを完全に使用できます。 結果は2つの方向への全く異なった最大サイズであるかもしれません。
The MSS counts only data octets in the segment, it does not count the TCP header or the IP header.
MSSはセグメントでデータ八重奏だけを数えて、それはTCPヘッダーかIPヘッダーを数えません。
A footnote: The MSS value counts only data octets, thus it does not count the TCP SYN and FIN control bits even though SYN and FIN do consume TCP sequence numbers.
脚注: MSS値はデータ八重奏だけを数えます、その結果、SYNとFINはTCP一連番号を消費しますが、それはTCP SYNとFINコントロールビットを数えません。
4. The Relationship of TCP Segments and IP Datagrams
4. TCPセグメントとIPデータグラムの関係
TCP segment are transmitted as the data in IP datagrams. The correspondence between TCP segments and IP datagrams must be one to one. This is because TCP expects to find exactly one complete TCP segment in each block of data turned over to it by IP, and IP must turn over a block of data for each datagram received (or completely reassembled).
TCPセグメントはデータとしてIPデータグラムで伝えられます。TCPセグメントとIPデータグラムとの通信は、1〜1であるに違いありません。 これがTCPが、まさにそれがIPによって引き渡されたそれぞれのブロックのデータの1つの完全なTCPセグメントを見つけると予想するからであるIPは各データグラムのための1ブロックのデータの上で受け取られているのと(完全に組み立て直されます)であるのにターンしなければなりません。
Postel [Page 2]
ポステル[2ページ]
RFC 879 November 1983 TCP Maximum Segment Size
RFC879の1983年11月のTCPの最大のセグメントサイズ
5. Layering and Modularity
5. レイヤリングとモジュール方式
TCP is an end to end reliable data stream protocol with error control, flow control, etc. TCP remembers many things about the state of a connection.
TCPは誤り制御、フロー制御などで確実な資料ストリームプロトコルを終わらせる終わりです。 TCPは接続の状態に関して多くのことを覚えています。
IP is a one shot datagram protocol. IP has no memory of the datagrams transmitted. It is not appropriate for IP to keep any information about the maximum datagram size a particular destination host might be capable of accepting.
IPは1つのショットデータグラムプロトコルです。 IPはデータグラムに関するメモリを全く伝えさせません。 IPが、最大のデータグラムサイズのどんな情報も特定のあて先ホストであることを保つのが受け入れることができるのは、適切ではありません。
TCP and IP are distinct layers in the protocol architecture, and are often implemented in distinct program modules.
TCPとIPはプロトコルアーキテクチャの異なった層であり、異なったプログラムモジュールでしばしば実装されます。
Some people seem to think that there must be no communication between protocol layers or program modules. There must be communication between layers and modules, but it should be carefully specified and controlled. One problem in understanding the correct view of communication between protocol layers or program modules in general, or between TCP and IP in particular is that the documents on protocols are not very clear about it. This is often because the documents are about the protocol exchanges between machines, not the program architecture within a machine, and the desire to allow many program architectures with different organization of tasks into modules.
人々の中にはプロトコル層かプログラムモジュールの間には、コミュニケーションが全くあるはずがないと思うように思える人もいます。 層とモジュールとのコミュニケーションがあるに違いありませんが、それは、慎重に指定されて、制御されるべきです。 中で特にプロトコル層か一般に、プログラムモジュールか、TCPとIPとのコミュニケーションの正当な見解を理解することにおける、ある問題はプロトコルのドキュメントがそれに関してそれほど明確でないということです。 これはドキュメントがしばしばマシン、およびタスクの異なった組織との多くのプログラムアーキテクチャをモジュールに許容する願望の中のプログラムアーキテクチャではなく、マシンの間のプロトコル交換に関するものであるからです。
6. IP Information Requirements
6. IP情報必須条件
There is no general requirement that IP keep information on a per host basis.
IPがホスト基礎あたりのaの情報を保つというどんな一般的な要件もありません。
IP must make a decision about which directly attached network address to send each datagram to. This is simply mapping an IP address into a directly attached network address.
IPはどの直接添付のネットワーク・アドレスに各データグラムを送るかに関して決定しなければなりません。 これは単に直接添付のネットワーク・アドレスにIPアドレスを写像しています。
There are two cases to consider: the destination is on the same network, and the destination is on a different network.
考える2つのケースがあります: 目的地が同じネットワークにあります、そして、目的地が異なったネットワークにあります。
Same Network
同じネットワーク
For some networks the the directly attached network address can be computed from the IP address for destination hosts on the directly attached network.
いくつかのネットワークにおいて、あて先ホストのために直接付属しているネットワークでIPアドレスから直接添付のネットワーク・アドレスを計算できます。
For other networks the mapping must be done by table look up (however the table is initialized and maintained, for example, [4]).
テーブルでマッピングをしなければならない他のネットワークのために、見上げてください。(しかしながら、例えば、テーブルは、初期化されて、維持されます、[4])。
Postel [Page 3]
ポステル[3ページ]
RFC 879 November 1983 TCP Maximum Segment Size
RFC879の1983年11月のTCPの最大のセグメントサイズ
Different Network
異なったネットワーク
The IP address must be mapped to the directly attached network address of a gateway. For networks with one gateway to the rest of the Internet the host need only determine and remember the gateway address and use it for sending all datagrams to other networks.
ゲートウェイの直接添付のネットワーク・アドレスにIPアドレスを写像しなければなりません。 ホストがそうするだけでよいインターネットの残りへの1門があるネットワークには、ゲートウェイアドレスを決定して、覚えていてください、そして、すべてのデータグラムを他のネットワークに送るのにそれを使用してください。
For networks with multiple gateways to the rest of the Internet, the host must decide which gateway to use for each datagram sent. It need only check the destination network of the IP address and keep information on which gateway to use for each network.
インターネットの残りへの複数のゲートウェイがあるネットワークのために、ホストは、それぞれのデータグラムの使用へのどのゲートウェイが発信したかを決めなければなりません。 それは、IPアドレスの送信先ネットワークをチェックするだけであり、各ネットワークにどのゲートウェイを使用したらよいかの情報を保たなければなりません。
The IP does, in some cases, keep per host routing information for other hosts on the directly attached network. The IP does, in some cases, keep per network routing information.
いくつかの場合、IPは他のホストのために直接付属しているネットワークにホストルーティング情報単位で維持されます。 いくつかの場合、IPはネットワークルーティング情報単位で維持されます。
A Special Case
特別なケース
There are two ICMP messages that convey information about particular hosts. These are subtypes of the Destination Unreachable and the Redirect ICMP messages. These messages are expected only in very unusual circumstances. To make effective use of these messages the receiving host would have to keep information about the specific hosts reported on. Because these messages are quite rare it is strongly recommended that this be done through an exception mechanism rather than having the IP keep per host tables for all hosts.
特定のホストに関して情報を伝達する2つのICMPメッセージがあります。 これらはDestination UnreachableとRedirect ICMPメッセージの血液型亜型です。 これらのメッセージは非常に珍しい事情だけで予想されます。 これらのメッセージをうまく利用するために、受信ホストはオンであると報告された特定のホストの情報を保たなければならないでしょう。 これらのメッセージがかなりまれであるので、IPをすべてのホストのためにホストテーブル単位で維持させるより例外メカニズムを通してむしろこれをすることが強く勧められます。
7. The Relationship between IP Datagram and TCP Segment Sizes
7. IPデータグラムとTCPセグメントサイズとの関係
The relationship between the value of the maximum IP datagram size and the maximum TCP segment size is obscure. The problem is that both the IP header and the TCP header may vary in length. The TCP Maximum Segment Size option (MSS) is defined to specify the maximum number of data octets in a TCP segment exclusive of TCP (or IP) header.
最大のIPデータグラムサイズの値と最大のTCPセグメントサイズとの関係は不鮮明です。 問題はIPヘッダーとTCPヘッダーの両方が長さにおいて異なるかもしれないということです。 TCP Maximum Segment Sizeオプション(MSS)は、TCP(または、IP)ヘッダーを除いてTCPセグメントのデータ八重奏の最大数を指定するために定義されます。
To notify the data sender of the largest TCP segment it is possible to receive the calculation of the MSS value to send is:
受けるのが可能である中で最も大きいTCPセグメントについてデータ送付者に通知するために、送るMSS価値の計算は以下の通りです。
MSS = MTU - sizeof(TCPHDR) - sizeof(IPHDR)
MSSはMTU--sizeof(TCPHDR)--sizeofと等しいです。(IPHDR)
On receipt of the MSS option the calculation of the size of segment that can be sent is:
MSSオプションを受け取り次第、送ることができるセグメントのサイズの計算は以下の通りです。
SndMaxSegSiz = MIN((MTU - sizeof(TCPHDR) - sizeof(IPHDR)), MSS)
SndMaxSegSiz=分((MTU--sizeof(TCPHDR)--sizeof(IPHDR))、MSS)
Postel [Page 4]
ポステル[4ページ]
RFC 879 November 1983 TCP Maximum Segment Size
RFC879の1983年11月のTCPの最大のセグメントサイズ
where MSS is the value in the option, and MTU is the Maximum Transmission Unit (or the maximum packet size) allowed on the directly attached network.
MSSがオプションで値であり、MTUが直接付属しているネットワークに許容されたMaximum Transmission Unit(または、最大のパケットサイズ)であるところ。
This begs the question, though. What value should be used for the "sizeof(TCPHDR)" and for the "sizeof(IPHDR)"?
もっとも、これは論点を巧みに避けます。 どんな値が「sizeof(TCPHDR)」と「sizeof(IPHDR)」に使用されるべきですか?
There are three reasonable positions to take: the conservative, the moderate, and the liberal.
取る3つの妥当な立場があります: 保守的な人、中道主義者、および自由主義者。
The conservative or pessimistic position assumes the worst -- that both the IP header and the TCP header are maximum size, that is, 60 octets each.
保守的であるか悲観的な立場は最悪を仮定します--IPヘッダーとTCPヘッダーの両方が最大サイズ(すなわち、それぞれ60の八重奏)です。
MSS = MTU - 60 - 60 = MTU - 120
MSS=MTU--60--60=MTU--120
If MTU is 576 then MSS = 456
MTUが456 576当時のMSS=歳であるなら
The moderate position assumes the that the IP is maximum size (60 octets) and the TCP header is minimum size (20 octets), because there are no TCP header options currently defined that would normally be sent at the same time as data segments.
適度の位置が仮定する、IPが最大サイズ(60の八重奏)とTCPヘッダーであることは最小規模(20の八重奏)です、現在定義されている通常、データ・セグメントと同時に送られるTCPヘッダーオプションが全くないので。
MSS = MTU - 60 - 20 = MTU - 80
MSS=MTU--60--20=MTU--80
If MTU is 576 then MSS = 496
MTUが496 576当時のMSS=歳であるなら
The liberal or optimistic position assumes the best -- that both the IP header and the TCP header are minimum size, that is, 20 octets each.
寛容であるか楽観的な立場はベストを仮定します--IPヘッダーとTCPヘッダーの両方が最小規模(すなわち、それぞれ20の八重奏)です。
MSS = MTU - 20 - 20 = MTU - 40
MSS=MTU--20--20=MTU--40
If MTU is 576 then MSS = 536
MTUが536 576当時のMSS=歳であるなら
If nothing is said about MSS, the data sender may cram as much as possible into a 576 octet datagram, and if the datagram has minimum headers (which is most likely), the result will be 536 data octets in the TCP segment. The rule relating MSS to the maximum datagram size ought to be consistent with this.
何もMSSに関して言われないなら、データ送付者は576八重奏データグラムをできるだけ詰め込むかもしれません、そして、データグラムに最小のヘッダーがあると(最もありそうです)、結果はTCPセグメントで536のデータ八重奏になるでしょう。 最大のデータグラムサイズにMSSに関連する規則はこれと一致しているべきです。
A practical point is raised in favor of the liberal position too. Since the use of minimum IP and TCP headers is very likely in the very large percentage of cases, it seems wasteful to limit the TCP segment data to so much less than could be transmitted at once, especially since it is less that 512 octets.
現実的な利点は寛容な位置もを支持して上げられます。 最小のIPとTCPヘッダーの使用は非常に大きい百分率の場合において非常に傾向があるので、TCPセグメントデータをとてもそれほど多くに制限するのはすぐに伝えることができたより無駄に思えます、それが特に少ないので。その512の八重奏。
Postel [Page 5]
ポステル[5ページ]
RFC 879 November 1983 TCP Maximum Segment Size
RFC879の1983年11月のTCPの最大のセグメントサイズ
For comparison: 536/576 is 93% data, 496/576 is 86% data, 456/576 is 79% data.
比較のために: 536/576が93%のデータである、496/576が86%のデータである、456/576は79%のデータです。
8. Maximum Packet Size
8. 最大のパケットサイズ
Each network has some maximum packet size, or maximum transmission unit (MTU). Ultimately there is some limit imposed by the technology, but often the limit is an engineering choice or even an administrative choice. Different installations of the same network product do not have to use the same maximum packet size. Even within one installation not all host must use the same packet size (this way lies madness, though).
各ネットワークには、何らかの最大のパケットサイズ、またはマキシマム・トランスミッション・ユニット(MTU)があります。 結局、技術で課された何らかの限界がありますが、しばしば、限界は、工学選択か管理選択になりさえします。 同じネットワーク製品の異なったインストールは同じ最大のパケットサイズを使用する必要はありません。 すべてのホストが同じパケットサイズに使用しなければならないというわけではない1つのインストールの中で同等である、(この道、偽りの狂気、もっとも)
Some IP implementers have assumed that all hosts on the directly attached network will be the same or at least run the same implementation. This is a dangerous assumption. It has often developed that after a small homogeneous set of host have become operational additional hosts of different types are introduced into the environment. And it has often developed that it is desired to use a copy of the implementation in a different inhomogeneous environment.
いくつかのIP implementersが、直接付属しているネットワークのすべてのホストが同じであるか、または同じ実装を少なくとも実行すると仮定しました。 これは危険な仮定です。 小さい均質のセットのホストが操作上になった後に異なったタイプの追加ホストが環境に取り入れられるのはしばしば展開しました。 そして、異なったinhomogeneous環境で実装のコピーを使用するのが必要であることはしばしば展開しました。
Designers of gateways should be prepared for the fact that successful gateways will be copied and used in other situation and installations. Gateways must be prepared to accept datagrams as large as can be sent in the maximum packets of the directly attached networks. Gateway implementations should be easily configured for installation in different circumstances.
ゲートウェイのデザイナーは、うまくいっているゲートウェイがコピーされるという事実のために用意ができていて、他の状況とインストールに使用されるべきです。 データグラムが極めて大きいと直接付属しているネットワークの最大のパケットで送った状態で受け入れるようにゲートウェイを準備しなければなりません。 ゲートウェイ実装は異なった事情におけるインストールのために容易に構成されるべきです。
A footnote: The MTUs of some popular networks (note that the actual limit in some installations may be set lower by administrative policy):
脚注: いくつかのポピュラーなネットワーク(いくつかのインストールにおける実際の限界が施政方針で、より低く設定されるかもしれないことに注意する)のMTUs:
ARPANET, MILNET = 1007 Ethernet (10Mb) = 1500 Proteon PRONET = 2046
1500 1007のアルパネット、MILNET=イーサネット(10Mb)=Proteon PRONET=2046
9. Source Fragmentation
9. ソース断片化
A source host would not normally create datagram fragments. Under normal circumstances datagram fragments only arise when a gateway must send a datagram into a network with a smaller maximum packet size than the datagram. In this case the gateway must fragment the datagram (unless it is marked "don't fragment" in which case it is discarded, with the option of sending an ICMP message to the source reporting the problem).
通常、送信元ホストはデータグラム・フラグメントを作成しないでしょう。 ゲートウェイがデータグラムより小さい最大のパケットサイズと共にデータグラムをネットワークに送らなければならないときだけ、通常の状況下でデータグラム・フラグメントは起こります。 この場合、ゲートウェイはデータグラムを断片化しなければなりません(その場合、それが「断片化しないでください」というマークされて、ことでないなら捨てられます、ICMPメッセージをソースに送るオプションが問題を報告していて)。
It might be desirable for the source host to send datagram fragments
送信元ホストがデータグラム・フラグメントを送るのは、望ましいかもしれません。
Postel [Page 6]
ポステル[6ページ]
RFC 879 November 1983 TCP Maximum Segment Size
RFC879の1983年11月のTCPの最大のセグメントサイズ
if the maximum segment size (default or negotiated) allowed by the data receiver were larger than the maximum packet size allowed by the directly attached network. However, such datagram fragments must not combine to a size larger than allowed by the destination host.
データ受信装置によって許容された最大のセグメントサイズ(デフォルトの、または、交渉された)が直接付属しているネットワークによって許容された最大のパケットサイズより大きいなら。 しかしながら、そのようなデータグラム・フラグメントはあて先ホストによって許されているより大きいサイズに結合してはいけません。
For example, if the receiving TCP announced that it would accept segments up to 5000 octets (in cooperation with the receiving IP) then the sending TCP could give such a large segment to the sending IP provided the sending IP would send it in datagram fragments that fit in the packets of the directly attached network.
例えば、受信TCPが、セグメントを5000の八重奏(受信IPと提携した)まで受け入れると発表するなら、送付IPが直接付属しているネットワークのパケットをうまくはめ込むデータグラム・フラグメントでそれを送るなら、発信しているTCPはそのような大きいセグメントを送付IPに与えるかもしれないでしょうに。
There are some conditions where source host fragmentation would be necessary.
いくつかの状態が送信元ホスト断片化が必要であるところにあります。
If the host is attached to a network with a small packet size (for example 256 octets), and it supports an application defined to send fixed sized messages larger than that packet size (for example TFTP [5]).
ホストがaに付けられるなら、小型小包でサイズ(例えば、256の八重奏)をネットワークでつないでください。そうすれば、それはそのパケットサイズより大きい固定大きさで分けられたメッセージを送るために定義されたアプリケーションをサポートします。(例えば、TFTP[5])。
If the host receives ICMP Echo messages with data it is required to send an ICMP Echo-Reply message with the same data. If the amount of data in the Echo were larger than the packet size of the directly attached network the following steps might be required: (1) receive the fragments, (2) reassemble the datagram, (3) interpret the Echo, (4) create an Echo-Reply, (5) fragment it, and (6) send the fragments.
ホストがデータでICMP Echoメッセージを受け取るなら、それが、同じデータがあるICMP Echo-応答メッセージを送るのに必要です。 Echoのデータ量が直接付属しているネットワークのパケットサイズより多くであるなら、以下のステップが必要でしょうに: (1) (6) 断片を受けてください、そして、(2) データグラムを組み立て直してください、そして、(3) Echoを解釈してください、そして、(4) Echo-回答を作成してください、そして、(5) それを断片化してください、そして、断片を送ってください。
10. Gateway Fragmentation
10. ゲートウェイ断片化
Gateways must be prepared to do fragmentation. It is not an optional feature for a gateway.
断片化するようにゲートウェイを準備しなければなりません。 それはゲートウェイのためのオプション機能ではありません。
Gateways have no information about the size of datagrams destination hosts are prepared to accept. It would be inappropriate for gateways to attempt to keep such information.
ゲートウェイには、目的地ホストが受け入れる用意ができているデータグラムのサイズの情報が全くありません。 ゲートウェイが、そのような情報を保つのを試みるのは、不適当でしょう。
Gateways must be prepared to accept the largest datagrams that are allowed on each of the directly attached networks, even if it is larger than 576 octets.
それぞれの直接付属しているネットワークに許容されている中で最も大きいデータグラムを受け入れるようにゲートウェイを準備しなければなりません、それが576の八重奏よりさらに大きいなら。
Gateways must be prepared to fragment datagrams to fit into the packets of the next network, even if it smaller than 576 octets.
次のネットワークのパケットに収まるようにデータグラムを断片化するようにゲートウェイを準備しなければならない、それ、576より小さい八重奏。
If a source host thought to take advantage of the local network's ability to carry larger datagrams but doesn't have the slightest idea if the destination host can accept larger than default datagrams and expects the gateway to fragment the datagram into default size
送信元ホストが、より大きいデータグラムを運ぶ企業内情報通信網の能力を利用すると思いますが、あて先ホストが、デフォルトより大きいデータグラムを受け入れることができて、ゲートウェイがデータグラムをデフォルトサイズに断片化すると予想するならまるで見当がつかないなら
Postel [Page 7]
ポステル[7ページ]
RFC 879 November 1983 TCP Maximum Segment Size
RFC879の1983年11月のTCPの最大のセグメントサイズ
fragments, then the source host is misguided. If indeed, the destination host can't accept larger than default datagrams, it probably can't reassemble them either. If the gateway either passes on the large datagram whole or fragments into default size fragments the destination will not accept it. Thus, this mode of behavior by source hosts must be outlawed.
断片であり、そして、送信元ホストは見当違いです。 あて先ホストは、デフォルトデータグラムより大きいと本当にならたぶんそれらを組み立て直すことができないと受け入れることができません。 ゲートウェイが大きいデータグラム全体か断片をデフォルトサイズ断片に伝えると、目的地はそれを受け入れないでしょう。 したがって、送信元ホストによる振舞いのこの方法を禁止しなければなりません。
A larger than default datagram can only arrive at a gateway because the source host knows that the destination host can handle such large datagrams (probably because the destination host announced it to the source host in an TCP MSS option). Thus, the gateway should pass on this large datagram in one piece or in the largest fragments that fit into the next network.
送信元ホストが、あて先ホストがそのような大きいデータグラムを扱うことができるのを知っているので(たぶんあて先ホストがTCP MSSオプションでそれを送信元ホストに発表したので)、デフォルトより大きいデータグラムはゲートウェイに届くことができるだけです。 したがって、ゲートウェイは無事にか次のネットワークに収まる最も大きい断片でこの大きいデータグラムを伝えるはずです。
An interesting footnote is that even though the gateways may know about know the 576 rule, it is irrelevant to them.
ゲートウェイは知るかもしれませんが、576はそこで知っています。おもしろい脚注がそれである、規則、それらに、それは無関係です。
11. Inter-Layer Communication
11. 相互層のコミュニケーション
The Network Driver (ND) or interface should know the Maximum Transmission Unit (MTU) of the directly attached network.
Network Driver(ノースダコタ)かインタフェースが直接付属しているネットワークについてMaximum Transmission Unit(MTU)を知るべきです。
The IP should ask the Network Driver for the Maximum Transmission Unit.
IPはNetwork DriverにMaximum Transmission Unitを求めるべきです。
The TCP should ask the IP for the Maximum Datagram Data Size (MDDS). This is the MTU minus the IP header length (MDDS = MTU - IPHdrLen).
TCPはMaximumデータグラムData Size(MDDS)をIPに求めるはずです。 これはIPヘッダ長(MDDS=MTU--IPHdrLen)を引いたMTUです。
When opening a connection TCP can send an MSS option with the value equal MDDS - TCPHdrLen.
開くとき、接続TCPは値の等しいMDDSとのMSSオプションを送ることができます--TCPHdrLen。
TCP should determine the Maximum Segment Data Size (MSDS) from either the default or the received value of the MSS option.
TCPはMSSオプションのデフォルトか容認された値のどちらかからMaximum Segment Data Size(MSDS)を決定するはずです。
TCP should determine if source fragmentation is possible (by asking the IP) and desirable.
TCPは、ソース断片化が可能であって(IPに尋ねるのによる)、望ましいかどうか決定するはずです。
If so TCP may hand to IP segments (including the TCP header) up to MSDS + TCPHdrLen.
そうだとすれば、TCPはセグメント(TCPヘッダーを含んでいる)をIPにMSDS+TCPHdrLenまで手渡すかもしれません。
If not TCP may hand to IP segments (including the TCP header) up to the lesser of (MSDS + TCPHdrLen) and MDDS.
そうでなければ、TCPはセグメント(TCPヘッダーを含んでいる)をIPに(MSDS+TCPHdrLen)とMDDSについて、より少ないまで手渡すかもしれません。
IP checks the length of data passed to it by TCP. If the length is less than or equal MDDS, IP attached the IP header and hands it to the ND. Otherwise the IP must do source fragmentation.
IPはTCPによってそれに通過されたデータの長さをチェックします。 長さが以下か等しいMDDSであるなら、IPはIPヘッダーを取り付けて、ノースダコタを尊敬します。 さもなければ、IPはソースに断片化しなければなりません。
Postel [Page 8]
ポステル[8ページ]
RFC 879 November 1983 TCP Maximum Segment Size
RFC879の1983年11月のTCPの最大のセグメントサイズ
12. What is the Default MSS ?
12. Default MSSは何ですか?
Another way of asking this question is "What transmitted value for MSS has exactly the same effect of not transmitting the option at all?".
この質問をする別の方法は「MSSのために値を送ったことが全くオプションを伝えないというまさに同じ効果を持っていますか?」です。
In terms of the previous section:
前項で:
The default assumption is that the Maximum Transmission Unit is 576 octets.
デフォルト仮定はMaximum Transmission Unitが576の八重奏であるということです。
MTU = 576
MTU=576
The Maximum Datagram Data Size (MDDS) is the MTU minus the IP header length.
MaximumデータグラムData Size(MDDS)はIPヘッダ長を引いたMTUです。
MDDS = MTU - IPHdrLen = 576 - 20 = 556
MDDSはMTU--IPHdrLen=576--20 = 556と等しいです。
When opening a connection TCP can send an MSS option with the value equal MDDS - TCPHdrLen.
開くとき、接続TCPは値の等しいMDDSとのMSSオプションを送ることができます--TCPHdrLen。
MSS = MDDS - TCPHdrLen = 556 - 20 = 536
MSSはMDDS--TCPHdrLen=556--20 = 536と等しいです。
TCP should determine the Maximum Segment Data Size (MSDS) from either the default or the received value of the MSS option.
TCPはMSSオプションのデフォルトか容認された値のどちらかからMaximum Segment Data Size(MSDS)を決定するはずです。
Default MSS = 536, then MSDS = 536
デフォルトMSSは536、当時のMSDS=536と等しいです。
TCP should determine if source fragmentation is possible and desirable.
TCPは、ソース断片化が可能であって、望ましいかどうか決定するはずです。
If so TCP may hand to IP segments (including the TCP header) up to MSDS + TCPHdrLen (536 + 20 = 556).
そうだとすれば、TCPはセグメント(TCPヘッダーを含んでいる)をIPにMSDS+TCPHdrLen(536+20 = 556)まで手渡すかもしれません。
If not TCP may hand to IP segments (including the TCP header) up to the lesser of (MSDS + TCPHdrLen (536 + 20 = 556)) and MDDS (556).
そうでなければ、TCPはセグメント(TCPヘッダーを含んでいる)をIPに(MSDS+TCPHdrLen(536+20 = 556))とMDDS(556)について、より少ないまで手渡すかもしれません。
Postel [Page 9]
ポステル[9ページ]
RFC 879 November 1983 TCP Maximum Segment Size
RFC879の1983年11月のTCPの最大のセグメントサイズ
13. The Truth
13. 真実
The rule relating the maximum IP datagram size and the maximum TCP segment size is:
最大のIPデータグラムサイズと最大のTCPセグメントサイズを関係づける規則は以下の通りです。
TCP Maximum Segment Size = IP Maximum Datagram Size - 40
IPの最大のデータグラムTCPの最大のセグメントサイズ=サイズ--40
The rule must match the default case.
規則は不履行格に合わなければなりません。
If the TCP Maximum Segment Size option is not transmitted then the data sender is allowed to send IP datagrams of maximum size (576) with a minimum IP header (20) and a minimum TCP header (20) and thereby be able to stuff 536 octets of data into each TCP segment.
TCP Maximum Segment Sizeオプションが伝えられないなら、データ送付者は、最小のIPヘッダー(20)と最小のTCPヘッダー(20)と共に最大サイズ(576)のIPデータグラムを送って、その結果、それぞれのTCPセグメントにデータの536の八重奏を詰めることができるのが許容されています。
The definition of the MSS option can be stated:
MSSオプションの定義を述べることができます:
The maximum number of data octets that may be received by the sender of this TCP option in TCP segments with no TCP header options transmitted in IP datagrams with no IP header options.
TCPヘッダーオプションなしでTCPセグメントでこのTCPオプションの送付者によって受けられるかもしれないデータ八重奏の最大数はIPデータグラムをIPヘッダーオプションなしで伝わりました。
14. The Consequences
14. 結果
When TCP is used in a situation when either the IP or TCP headers are not minimum and yet the maximum IP datagram that can be received remains 576 octets then the TCP Maximum Segment Size option must be used to reduce the limit on data octets allowed in a TCP segment.
IPかTCPヘッダーが最小でないときに、TCPが状況で使用されて、しかし、受け取ることができる最大のIPデータグラムがその時576の八重奏のままで残っているとき、TCPセグメントで許容されたデータ八重奏における限界を抑えるのにTCP Maximum Segment Sizeオプションを使用しなければなりません。
For example, if the IP Security option (11 octets) were in use and the IP maximum datagram size remained at 576 octets, then the TCP should send the MSS with a value of 525 (536-11).
例えば、最大のデータグラムサイズが576の八重奏に残っていた使用とIPにIP Securityオプション(11の八重奏)があるなら、TCPは525(536-11)の値があるMSSを送るでしょうに。
Postel [Page 10]
ポステル[10ページ]
RFC 879 November 1983 TCP Maximum Segment Size
RFC879の1983年11月のTCPの最大のセグメントサイズ
15. References
15. 参照
[1] Postel, J., ed., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, USC/Information Sciences Institute, September 1981.
[1] ポステル、J.、教育、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC793、USC/情報Sciences Institute、9月1981日
[2] Postel, J., ed., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, USC/Information Sciences Institute, September 1981.
[2] ポステル、J.、教育、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC791、USC/情報Sciences Institute、9月1981日
[3] Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification", RFC 792, USC/Information Sciences Institute, September 1981.
[3] ポステル、J.、「インターネットはメッセージプロトコルを制御します--DARPAインターネットはプロトコル仕様をプログラムする」RFC792、科学が1981年9月に設けるUSC/情報。
[4] Plummer, D., "An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48-bit Ethernet Addresses for Transmission on Ethernet Hardware", RFC 826, MIT/LCS, November 1982.
[4] プラマー、D.、「イーサネットアドレス解決プロトコルかネットワーク・プロトコルを変換すると、トランスミッションのためのアドレスはイーサネットハードウェアの上で48ビットのイーサネットに扱われます」、RFC826、MIT/LCS、1982年11月。
[5] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, MIT/LCS, June 1981.
[5]Sollins、K.、「TFTPプロトコル(改正2)」、RFC783、MIT/LCS、1981年6月。
Postel [Page 11]
ポステル[11ページ]
一覧
スポンサーリンク