TCP选项
每个选项的开始是1字节的kind字段，说明选项的类型。
Kind=0:选项表结束（1字节）
Kind=1:无操作（1字节）
Kind=2：最大报文段长度（4字节）
Kind=3:窗口扩大因子（4字节）
Kind=8:时间戳（10字节）
3、窗口扩大选项：
窗口扩大选项使TCP的窗口定义从16位增加到32位，这并不是通过修改TCP首部来实现的，TCP首部仍然使用16位，而是通过定义一个选项实现对16位的扩大操作来完成的。
4、时间戳选项：
时间戳选项使发送方在每个报文段中放置一个时间戳值。接收方在确认中返回这个数值，从而允许发送方为每一个收到的ACK计算RTT。
rfc793
Options: variable
Options may occupy space at the end of the TCP header and are a multiple of 8 bits in length. All options are included in the checksum. An option may begin on any octet boundary. There are two cases for the format of an option:
Case 1: A single octet of option-kind.
Case 2: An octet of option-kind, an octet of option-length, and
the actual option-data octets.
The option-length counts the two octets of option-kind and option-length as well as the option-data octets.
Note that the list of options may be shorter than the data offset field might imply. The content of the header beyond the End-of-Option option must be header padding (i.e., zero).
A TCP must implement all options.
Currently defined options include (kind indicated in octal):
Kind Length Meaning
---- ------ -------
0 - End of option list.
1 - No-Operation.
2 4 Maximum Segment Size.
Specific Option Definitions
End of Option List
+--------+
|00000000|
+--------+
Kind=0
This option code indicates the end of the option list. This might not coincide with the end of the TCP header according to the Data Offset field. This is used at the end of all options, not the end of each option, and need only be used if the end of the options would not otherwise coincide with the end of the TCP header.
No-Operation
+--------+
|00000001|
+--------+
Kind=1
This option code may be used between options, for example, to align the beginning of a subsequent option on a word boundary. There is no guarantee that senders will use this option, so receivers must be prepared to process options even if they do not begin on a word boundary.
Maximum Segment Size 即MSS选项
+--------+--------+---------+--------+
|00000010|00000100| max seg size |
+--------+--------+---------+--------+
Kind=2 Length=4
Maximum Segment Size Option Data: 16 bits
If this option is present, then it communicates the maximum receive segment size at the TCP which sends this segment. This field must only be sent in the initial connection request(i.e., in segments with the SYN control bit set). If this option is not used, any segment size is allowed.
Padding: variable
The TCP header padding is used to ensure that the TCP header ends and data begins on a 32 bit boundary. The padding is composed of zeros.
rfc1323
1.3 Using TCP options
The extensions defined in this memo all use new TCP options. We
must address two possible issues concerning the use of TCP
options: (1) compatibility and (2) overhead.
We must pay careful attention to compatibility, i.e., to
interoperation with existing implementations. The only TCP option
defined previously, MSS, may appear only on a SYN segment. Every
implementation should (and we expect that most will) ignore
unknown options on SYN segments. However, some buggy TCP
implementation might be crashed by the first appearance of an
option on a non-SYN segment. Therefore, for each of the
extensions defined below, TCP options will be sent on non-SYN
segments only when an exchange of options on the SYN segments has
indicated that both sides understand the extension. Furthermore,
an extension option will be sent in a segment only if
the corresponding option was received in the initial
segment.
A question may be raised about the bandwidth and processing
overhead for TCP options. Those options that occur on SYN
segments are not likely to cause a performance concern. Opening a
TCP connection requires execution of significant special-case
code, and the processing of options is unlikely to increase that
cost significantly.
On the other hand, a Timestamps option may appear in any data or
ACK segment, adding 12 bytes to the 20-byte TCP header. We believe that the bandwidth saved by reducing unnecessary
retransmissions will more than pay for the extra header bandwidth.
There is also an issue about the processing overhead for parsing
the variable byte-aligned format of options, particularly with a
RISC-architecture CPU. To meet this concern, Appendix A contains
a recommended layout of the options in TCP headers to achieve
reasonable data field alignment. In the spirit of Header
Prediction, a TCP can quickly test for this layout and if it is
verified then use a fast path. Hosts that use this canonical
layout will effectively use the options as a set of fixed-format
fields appended to the TCP header. However, to retain the
philosophical and protocol framework of TCP options, a TCP must be
prepared to parse an arbitrary options field, albeit with less
efficiency.
Finally, we observe that most of the mechanisms defined in this
memo are important for LFN's and/or very high-speed networks. For
low-speed networks, it might be a performance optimization to NOT
use these mechanisms. A TCP vendor concerned about optimal
performance over low-speed paths might consider turning these
extensions off for low-speed paths, or allow a user or
installation manager to disable them.
2. TCP WINDOW SCALE OPTION
TCP Window Scale Option (WSopt):
Kind: 3 Length: 3 bytes
+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+
This option is an offer, not a promise; both sides must send
Window Scale options in their SYN segments to enable window
scaling in either direction. If window scaling is enabled,
then the TCP that sent this option will right-shift its true
receive-window values by 'shift.cnt' bits for transmission in
SEG.WND. The value 'shift.cnt' may be zero (offering to scale,
while applying a scale factor of 1 to the receive window).
This option may be sent in an initial segment (i.e., a
segment with the SYN bit on and the ACK bit off). It may also
be sent in a segment, but only if a Window Scale op-
tion was received in the initial segment. A Window Scale
option in a segment without a SYN bit should be ignored.
The Window field in a SYN (i.e., a or ) segment
itself is never scaled.
3.2 TCP Timestamps Option
TCP Timestamps Option (TSopt):
Kind: 8
Length: 10 bytes
+-------+-------+---------------------+---------------------+
|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
+-------+-------+---------------------+---------------------+
1 1 4 4
The Timestamps option carries two four-byte timestamp fields.
The Timestamp Value field (TSval) contains the current value of
the timestamp clock of the TCP sending the option.
The Timestamp Echo Reply field (TSecr) is only valid if the ACK
bit is set in the TCP header; if it is valid, it echos a times-
tamp value that was sent by the remote TCP in the TSval field
of a Timestamps option. When TSecr is not valid, its value
must be zero. The TSecr value will generally be from the most
recent Timestamp option that was received; however, there are
exceptions that are explained below.
A TCP may send the Timestamps option (TSopt) in an initial
segment (i.e., segment containing a SYN bit and no ACK
bit), and may send a TSopt in other segments only if it re-
ceived a TSopt in the initial segment for the connection.
3499
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
