tcp的option字段
找到了RFC⽂档中关于tcp报头中option字段的内容，好好阅读⼀下，有时间再给翻成中⽂的。
TCP选项(RFC793和更新的RFC1323)
– 这⾥充满了各种组合的可能性
– 应答⽅式“Query-Reply”，可以把多个选项
放到⼀个包中
– 有些⾼级选项在新的协议栈实现中加⼊
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 op
tions are included in the checksum. An option may begin on any octet boundary. There are two cas for the format of an option:
Ca 1: A single octet of option-kind.
Ca 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 offt 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 Offt field. This is ud at the end of all options, not the end of each option, and need only be ud if the end of the options would not otherwi coincide with the end of the TCP header.
No-Operation
+--------+
|00000001|
+--------+
Kind=1
This option code may be ud between options, for example, to align the beginning of a subquent option on a word boundary. There is no guarantee that nders will u 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 g size |
+--------+--------+---------+--------+
Kind=2 Length=4
Maximum Segment Size Option Data: 16 bits
If this option is prent, then it communicates the maximum receive gment size at the TCP which nds this gment. This field must only be nt in the initial connection , in gments with the SYN control bit t). If this option is not ud, any gment size is allowed.
Padding: variable
The TCP header padding is ud to ensure that the TCP header ends and data begins on a 32 bit boundary. The padding is compod of zeros.
rfc1323
1.3 Using TCP options
The extensions defined in this memo all u new TCP options. We
must address two possible issues concerning the u 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 gment. Every
implementation should (and we expect that most will) ignore
unknown options on SYN gments. However, some buggy TCP
implementation might be crashed by the first appearance of an
option on a non-SYN gment. Therefore, for each of the
extensions defined below, TCP options will be nt on non-SYN
gments only when an exchange of options on the SYN gments has
indicated that both sides understand the extension. Furthermore,
an extension option will be nt in a gment only if
the corresponding option was received in the initial
gment.
A question may be raid about the bandwidth and processing
overhead for TCP options. Tho options that occur on SYN
gments are not likely to cau a performance concern. Opening a
TCP connection requires execution of significant special-ca
code, and the processing of options is unlikely to increa that
cost significantly.
On the other hand, a Timestamps option may appear in any data or
ACK gment, 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 u a fast path. Hosts that u this canonical
layout will effectively u the options as a t 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 par an arbitrary options field, albeit with less
efficiency.
Finally, we obrve 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
u the mechanisms. A TCP vendor concerned about optimal
performance over low-speed paths might consider turning the
extensions off for low-speed paths, or allow a ur 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 |
+---------+---------+---------+
This option is an offer, not a promi; both sides must nd
Window Scale options in their SYN gments to enable window
scaling in either direction. If window scaling is enabled,
then the TCP that nt this option will right-shift its true
receive-window values by '' bits for transmission in
SEG.WND. The value '' may be zero (offering to scale,
while applying a scale factor of 1 to the receive window).
This option may be nt in an initial gment (i.e., a
gment with the SYN bit on and the ACK bit off). It may also
be nt in a gment, but only if a Window Scale op-
tion was received in the initial gment. A Window Scale
option in a gment without a SYN bit should be ignored.
The Window field in a SYN (i.e., a or ) gment
itlf 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 nding the option.
The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is t in the TCP header; if it is valid, it echos a times-
tamp value that was nt 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 nd the Timestamps option (TSopt) in an initial
gment (i.e., gment containing a SYN bit and no ACK
bit), and may nd a TSopt in other gments only if it re-
ceived a TSopt in the initial gment for the connection.
