[要約] RFC 6691は、TCPオプションと最大セグメントサイズ（MSS）に関するガイドラインです。その目的は、TCP通信の効率とパフォーマンスを向上させるために、MSSの適切な設定方法を提供することです。
Internet Engineering Task Force (IETF) D. Borman
Request for Comments: 6691 Quantum Corporation
Updates: 879, 2385 July 2012
Category: Informational
ISSN: 2070-1721
TCP Options and Maximum Segment Size (MSS)
TCPオプションと最大セグメントサイズ（MSS）
Abstract
概要
This memo discusses what value to use with the TCP Maximum Segment Size (MSS) option, and updates RFC 879 and RFC 2385.
このメモでは、TCP最大セグメントサイズ（MSS）オプションで使用する値について説明し、RFC 879およびRFC 2385を更新します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6691.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6691で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
There has been some confusion as to what value to use with the TCP MSS option when using IP and TCP options. RFC 879 [RFC879] states:
IPおよびTCPオプションを使用する場合、TCP MSSオプションでどの値を使用するかについていくつかの混乱がありました。 RFC 879 [RFC879]は次のように述べています：
The MSS counts only data octets in the segment, it does not count the TCP header or the IP header.
MSSはセグメント内のデータオクテットのみをカウントし、TCPヘッダーまたはIPヘッダーはカウントしません。
This statement is unclear about what to do about IP and TCP options, since they are part of the headers. RFC 1122 [RFC1122] clarified the MSS option, which is discussed in Appendix A, but there still seems to be some confusion.
IPおよびTCPオプションはヘッダーの一部であるため、このステートメントはIPおよびTCPオプションについて何をするかについては不明です。 RFC 1122 [RFC1122]は、付録Aで説明されているMSSオプションを明確にしましたが、依然として混乱があるようです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
When calculating the value to put in the TCP MSS option, the MTU value SHOULD be decreased by only the size of the fixed IP and TCP headers and SHOULD NOT be decreased to account for any possible IP or TCP options; conversely, the sender MUST reduce the TCP data length to account for any IP or TCP options that it is including in the packets that it sends. The rest of this document just expounds on that statement, and the goal is to avoid IP-level fragmentation of TCP packets.
TCP MSSオプションに入れる値を計算するとき、MTU値は固定IPおよびTCPヘッダーのサイズだけ減らす必要があり（SHOULD）、可能なIPまたはTCPオプションを考慮して減らす必要はありません。逆に、送信者は、送信するパケットに含まれているIPまたはTCPオプションを考慮して、TCPデータ長を削減する必要があります。このドキュメントの残りの部分では、そのステートメントについて詳しく説明します。目標は、TCPパケットのIPレベルの断片化を回避することです。
The size of the fixed TCP header is 20 bytes [RFC793], the size of the fixed IPv4 header is 20 bytes [RFC791], and the size of the fixed IPv6 header is 40 bytes [RFC2460]. The determination of what MTU value should be used, especially in the case of multi-homed hosts, is beyond the scope of this document.
固定TCPヘッダーのサイズは20バイト[RFC793]、固定IPv4ヘッダーのサイズは20バイト[RFC791]、固定IPv6ヘッダーのサイズは40バイト[RFC2460]です。使用するMTU値の決定は、特にマルチホームホストの場合は、このドキュメントの範囲外です。
RFC 879 [RFC879] discusses the MSS option and other topics. In the Introduction, it states:
RFC 879 [RFC879]では、MSSオプションとその他のトピックについて説明しています。はじめに、それは述べています：
THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS FORTY.
TCPの最大セグメントサイズは、IPの最大データグラムサイズから40を引いたものです。
In Section 13, it states:
セクション13では、次のように述べています。
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.
IPヘッダーオプションのないIPデータグラムで送信されるTCPヘッダーオプションのないTCPセグメントで、このTCPオプションの送信者が受信できるデータオクテットの最大数。
These are both correct. However, in the next paragraph -- in Section 14 -- it then confuses this by stating that the consequence is:
これらはどちらも正しいです。ただし、次の段落（セクション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ヘッダーのいずれかが最小ではなく、受信可能な最大IPデータグラムが576オクテットのままである状況でTCPを使用する場合、TCP最大セグメントサイズオプションを使用して、データで許可されるデータオクテットの制限を減らす必要があります。 TCPセグメント。
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).
たとえば、IPセキュリティオプション（11オクテット）が使用されていて、IP最大データグラムサイズが576オクテットのままである場合、TCPはMSSを525（536-11）の値で送信する必要があります。
That is incorrect. The simpler and more correct statement would be:
不正解です。よりシンプルでより正しいステートメントは次のようになります。
When TCP is used in a situation where either the IP or TCP headers are not minimum, 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.
IPヘッダーまたはTCPヘッダーが最小ではない状況でTCPが使用される場合、送信者は、IPおよびTCPオプションで使用されるオクテットの数だけ、特定のパケットのTCPデータの量を減らす必要があります。
RFC 2385 [RFC2385] incorrectly states, in Section 4.3:
RFC 2385 [RFC2385]は、セクション4.3で誤って述べています。
As with other options that are added to every segment, the size of the MD5 option must be factored into the MSS offered to the other side during connection negotiation. Specifically, the size of the header to subtract from the MTU (whether it is the MTU of the outgoing interface or IP's minimal MTU of 576 bytes) is now at least 18 bytes larger.
すべてのセグメントに追加される他のオプションと同様に、MD5オプションのサイズは、接続ネゴシエーション中に相手側に提供されるMSSに考慮される必要があります。具体的には、MTUから差し引くヘッダーのサイズ（発信インターフェイスのMTUであるか、IPの最小MTUである576バイトであるか）は、少なくとも18バイト大きくなっています。
This is incorrect. The value for the MSS option is only adjusted by the fixed IP and TCP headers.
これは誤りです。 MSSオプションの値は、固定IPおよびTCPヘッダーによってのみ調整されます。
The initial clarification was sent to the TCP Large Windows mailing list in 1993 [Borman93]; this section is based on that message.
最初の説明は、1993年にTCP Large Windowsメーリングリストに送信されました[Borman93]。このセクションはそのメッセージに基づいています。
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. The reason for this can be seen in the following table:
MSSオプションで送信されるMSS値は、実効MTUから固定IPおよびTCPヘッダーを差し引いたものと等しくなければなりません。 MSSオプションの値を計算するときにIPオプションとTCPオプションの両方を無視することにより、パケットで送信するIPまたはTCPオプションがある場合、送信者はそれに応じてTCPデータのサイズを減らす必要があります。この理由は、次の表で確認できます。
+--------------------+--------------------+
| MSS is adjusted | MSS isn't adjusted |
| to include options | to include options |
+--------------------+--------------------+--------------------+
| Sender adjusts | Packets are too | Packets are the |
| packet length | short | correct length |
| for options | | |
+--------------------+--------------------+--------------------+
| Sender doesn't | Packets are the | Packets are too |
| adjust packet | correct length | long |
| length for options | | |
+--------------------+--------------------+--------------------+
The goal is to not send IP datagrams that have to be fragmented, and packets sent with the constraints in the lower right of this grid will cause IP fragmentation. Since the sender doesn't know if the received MSS option was adjusted to include options, the only way to guarantee that the packets are not too long is for the data sender to decrease the TCP data length by the size of the IP and TCP options. It follows, then, that since the sender will be adjusting the TCP data length when sending IP and TCP options, there is no need to include the IP and TCP option lengths in the MSS value.
目的は、フラグメント化する必要のあるIPデータグラムを送信しないことです。このグリッドの右下にある制約で送信されたパケットは、IPフラグメント化を引き起こします。送信者は受信したMSSオプションがオプションを含むように調整されたかどうかを知らないため、パケットが長すぎないことを保証する唯一の方法は、データ送信者がIPおよびTCPオプションのサイズによってTCPデータ長を減らすことです。したがって、IPおよびTCPオプションを送信するときに送信側がTCPデータ長を調整するため、MSS値にIPおよびTCPオプションの長さを含める必要はありません。
Another argument against including IP or TCP options in the determination of the MSS value is that the MSS is a fixed value, and by their very nature the lengths of IP and TCP options are variable, so the MSS value can never accurately reflect all possible IP and TCP option combinations. The only one that knows for sure how many IP and TCP options are in any given packet is the sender; hence, the sender should be doing the adjustment to the TCP data length to account for any IP and TCP options.
MSS値の決定にIPまたはTCPオプションを含めることに対するもう1つの議論は、MSSは固定値であり、その性質上、IPおよびTCPオプションの長さは可変であるため、MSS値がすべての可能なIPを正確に反映することはあり得ないということです。およびTCPオプションの組み合わせ。特定のパケットに含まれるIPおよびTCPオプションの数が確実にわかるのは送信者だけです。したがって、送信者は、IPおよびTCPオプションを考慮して、TCPデータ長を調整する必要があります。
The TCP MSS option specifies an upper bound for the size of packets that can be received. Hence, setting the value in the MSS option too small can impact the ability for Path MTU Discovery to find a larger path MTU. For more information on Path MTU Discovery, see:
TCP MSSオプションは、受信できるパケットのサイズの上限を指定します。したがって、MSSオプションの値の設定が小さすぎると、パスMTUディスカバリーがより大きいパスMTUを検出する機能に影響を与える可能性があります。パスMTUディスカバリーの詳細については、以下を参照してください。
o "Path MTU Discovery" [RFC1191]
o 「パスMTUディスカバリー」[RFC1191]
o "TCP Problems with Path MTU Discovery" [RFC2923]
o 「パスMTUディスカバリに関するTCPの問題」[RFC2923]
o "Packetization Layer Path MTU Discovery" [RFC4821]
o 「パケット化層パスMTU発見」[RFC4821]
The effective MTU can sometimes vary, as when used with variable compression, e.g., RObust Header Compression (ROHC) [RFC5795]. It is tempting for TCP to want 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は、たとえばRObust Header Compression（ROHC）[RFC5795]などの可変圧縮で使用される場合とは異なります。圧縮されたペイロードの最も効率的な使用をサポートするために、TCPが可能な限り最大のMSSをアドバタイズしたくなるのは魅力的です。残念ながら、一部の圧縮方式では、エンドポイントのコンプレッサー/デコンプレッサーで状態を再同期するために、完全なヘッダー（したがってより小さなペイロード）を送信する必要がある場合があります。最大のMTUを使用してMSSオプションでアドバタイズする値を計算する場合、TCP再送信がコンプレッサーの再同期を妨げる可能性があります。
As a result, when the effective MTU of an interface varies, TCP SHOULD use the smallest effective MTU of the interface to calculate the value to advertise in the MSS option.
その結果、インターフェイスの有効MTUが異なる場合、TCPはインターフェイスの最小有効MTUを使用して、MSSオプションでアドバタイズする値を計算する必要があります（SHOULD）。
In order to support TCP over IPv6 jumbograms, implementations need to be able to send TCP segments larger than 64K. RFC 2675 [RFC2675] defines that a value of 65,535 is to be treated as infinity, and Path MTU Discovery [RFC1981] is used to determine the actual MSS.
TCP over IPv6ジャンボグラムをサポートするために、実装は64Kより大きいTCPセグメントを送信できる必要があります。 RFC 2675 [RFC2675]は、値65,535が無限大として扱われることを定義し、Path MTU Discovery [RFC1981]を使用して実際のMSSを決定します。
Packets that are too long will either be fragmented or dropped. If packets are fragmented, intermediary firewalls or middle boxes may drop the fragmented packets. In either case, when packets are dropped, the connection can fail; hence, it is best to avoid generating fragments.
長すぎるパケットは、フラグメント化されるかドロップされます。パケットがフラグメント化されている場合、中間ファイアウォールまたはミドルボックスがフラグメント化されたパケットをドロップする可能性があります。どちらの場合も、パケットがドロップされると、接続が失敗する可能性があります。したがって、フラグメントの生成を避けるのが最善です。
This document clarifies how to determine what value should be used for the MSS option and does not introduce any new security concerns.
このドキュメントでは、MSSオプションに使用する値を決定する方法を明確にし、新しいセキュリティ上の懸念を紹介しません。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC879] Postel, J., "The TCP Maximum Segment Size and Related Topics", RFC 879, November 1983.
[RFC879] Postel、J。、「TCPの最大セグメントサイズと関連トピック」、RFC 879、1983年11月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC2675] Borman、D.、Deering、S。、およびR. Hinden、「IPv6 Jumbograms」、RFC 2675、1999年8月。
[Borman93] Borman, D., "TCP MSS & Timestamps", Message to the tcplw mailing list, January 7, 1993.
[Borman93] Borman、D。、「TCP MSS＆Timestamps」、tcplwメーリングリストへのメッセージ、1993年1月7日。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のパスMTUディスカバリ」、RFC 1981、1996年8月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU Discoveryに関するTCPの問題」、RFC 2923、2000年9月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.
[RFC5795] Sandlund、K.、Pelletier、G。、およびL-E。ジョンソン、「RObustヘッダー圧縮（ROHC）フレームワーク」、RFC 5795、2010年3月。
RFC 793 [RFC793] defines the MSS option as follows:
RFC 793 [RFC793]では、MSSオプションを次のように定義しています。
Maximum Segment Size Option Data: 16 bits
最大セグメントサイズオプションデータ：16ビット
If this option is present, then it communicates the maximum receive segment size at the TCP which sends this segment. This field must only be sent in the initial connection request (i.e., in segments with the SYN control bit set). If this option is not used, any segment size is allowed.
このオプションが存在する場合、このセグメントを送信するTCPで最大受信セグメントサイズを通知します。このフィールドは、最初の接続要求（つまり、SYN制御ビットが設定されたセグメント）でのみ送信する必要があります。このオプションを使用しない場合、任意のセグメントサイズが許可されます。
RFC 1122 [RFC1122] provides additional clarification in Section 4.2.2.6, on pages 85-86. First, it changes the default behavior when the MSS option is not present:
RFC 1122 [RFC1122]は、セクション4.2.2.6の85-86ページに追加の説明を提供します。まず、MSSオプションが存在しない場合のデフォルトの動作を変更します。
If an MSS option is not received at connection setup, TCP MUST assume a default send MSS of 536 (576-40) [TCP:4].
MSSオプションが接続セットアップで受信されない場合、TCPはデフォルトの送信MSSを536（576-40）[TCP：4]と想定しなければなりません（MUST）。
Then, it clarifies how to determine the value to use in the MSS option:
次に、MSSオプションで使用する値を決定する方法を明確にします。
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). TCP obtains MMS_R and MMS_S from the IP layer; see the generic call GET_MAXSIZES in Section 3.4.
ここで、MMS_Rは、受信（および再構成）できるトランスポート層メッセージの最大サイズです。 TCPはIP層からMMS_RとMMS_Sを取得します。セクション3.4の総称呼び出しGET_MAXSIZESを参照してください。
What is implied in RFC 1122, but not explicitly stated, is that the 20 is the size of the fixed TCP header. The definition of MMS_R is found in Section 3.3.2, on page 57:
RFC 1122で暗示されていますが、明示的には述べられていませんが、20は固定TCPヘッダーのサイズです。 MMS_Rの定義は、57ページの3.3.2項にあります。
MMS_R is given by:
MMS_Rは次のように与えられます。
MMS_R = EMTU_R - 20
since 20 is the minimum size of an IP header.
20はIPヘッダーの最小サイズだからです。
and on page 56 (also Section 3.3.2):
および56ページ（セクション3.3.2も）：
We designate the largest datagram size that can be reassembled by EMTU_R ("Effective MTU to receive"); this is sometimes called the "reassembly buffer size". EMTU_R MUST be greater than or equal to 576, SHOULD be either configurable or indefinite, and SHOULD be greater than or equal to the MTU of the connected network(s).
EMTU_R（「受信する有効なMTU」）で再構成できる最大のデータグラムサイズを指定します。これは、「再構成バッファーサイズ」と呼ばれることもあります。 EMTU_Rは576以上である必要があり、SHOULDは構成可能または無期限である必要があり、接続されているネットワークのMTU以上である必要があります（SHOULD）。
What should be noted here is that EMTU_R is the largest datagram size that can be reassembled, not the largest datagram size that can be received without fragmentation. Taking this literally, since most modern TCP/IP implementations can reassemble a full 64K IP packet, implementations should be using 65535 - 20 - 20, or 65495, for the MSS option. But there is more to it than that. RFC 1122 also states, on page 86:
ここで注意すべきことは、EMTU_Rは再構成できる最大のデータグラムサイズであり、断片化せずに受信できる最大のデータグラムサイズではないということです。これを文字通り解釈すると、ほとんどの最新のTCP / IP実装は完全な64K IPパケットを再構成できるため、実装ではMSSオプションに65535-20-20、または65495を使用する必要があります。しかし、それだけではありません。 RFC 1122には、86ページにも記載されています。
The choice of TCP segment size has a strong effect on performance. Larger segments increase throughput by amortizing header size and per-datagram processing overhead over more data bytes; however, if the packet is so large that it causes IP fragmentation, efficiency drops sharply if any fragments are lost [IP:9].
TCPセグメントサイズの選択は、パフォーマンスに大きな影響を与えます。セグメントを大きくすると、ヘッダーサイズとデータグラムごとの処理オーバーヘッドがより多くのデータバイトに分散されるため、スループットが向上します。ただし、パケットが大きすぎてIPフラグメンテーションが発生する場合、フラグメントが失われると効率が大幅に低下します[IP：9]。
Since it is guaranteed that any IP datagram that is larger than the MTU of the connected network will have to be fragmented to be received, implementations ignore the "greater than or" part of "SHOULD be greater than or equal to the MTU of the connected network(s)". Thus, the MSS value to be sent in an MSS option must be less than or equal to:
接続されたネットワークのMTUよりも大きいIPデータグラムは、受信するためにフラグメント化する必要があることが保証されているため、実装では、「接続されたMTU以上である必要があります」の「以上」の部分を無視しますネットワーク」。したがって、MSSオプションで送信されるMSS値は次の値以下でなければなりません。
EMTU_R - FixedIPhdrsize - FixedTCPhdrsize
EMTU_R-FixedIPhdrsize-FixedTCPhdrsize
where FixedTCPhdrsize is 20, and FixedIPhdrsize is 20 for IPv4 and 40 for IPv6.
ここで、FixedTCPhdrsizeは20、FixedIPhdrsizeはIPv4の場合は20、IPv6の場合は40です。
Author's Address
著者のアドレス
David Borman Quantum Corporation Mendota Heights, MN 55120
David Borman Quantum Corporation Mendota Heights、MN 55120
EMail: david.borman@quantum.com