TCP头部选项功能预案.docxVIP

TCP 头部选项功能详解 TCP头部的选项部分是TCP为了适应复杂的网络环境和更好的服务应用层而进行设计的。TCP选项部分最长可以达到40byte，再加上TCP选项外的固定的20byte字节部分，TCP的最长头部可达60byte。TCP头部长度可以通过TCP头部中的“数据偏移”位来查看。（值得注意的是TCP偏移量的单位是32位，也就是4byte。而TCP偏移量共占4bit位，取最大的?1111?计算也就是十进制的15。15*4byte=60byte，这个也是TCP的首部不超过60byte的原因。）? 大多数的TCP选项部分出现在TCP连接建立阶段，也就是TCP的三次握手数据包中。当然有些选项也会出现在已经建立连接的 session中，不过此种情况较少出现。 TCP选项部分占有的位数必须是8bit的倍数，这也就是说，即使出现我们应用的选项部分为4bit，但也必须使用4bit的垫片。这样才符合RFC的要求。 TCP选项部分实际运用的有以下几种： 最大报文传输段（Maximum Segment Size ---MSS） 窗口扩大选项（window scaling ） 选择确认选项（Selective Acknowledgements --SACK） 时间戳选项（timestamps） Nop 下面是一个实际网络中选项部分使用齐全的一个数据包，如图解码部分： 使用wireshark 做出解码的解释： MSS MSS是TCP选项中最经常出现，也是最早出现的选项。MSS选项占4byte。MSS是每一个TCP报文段中数据字段的最大长度，注意：只是数据部分的字段，不包括TCP的头部。TCP在三次握手中，每一方都会通告其期望收到的MSS（MSS只出现在SYN数据包中）如果一方不接受另一方的MSS值则定位默认值536byte。 MSS值太小或太大都是不合适。太小，例如MSS值只有1byte，那么为了传输这1byte数据，至少要消耗20字节IP头部+20字节TCP头部=40byte，这还不包括其二层头部所需要的开销，显然这种数据传输效率是很低的。MSS过大，导致数据包可以封装很大，那么在IP传输中分片的可能性就会增大，接受方在处理分片包所消耗的资源和处理时间都会增大，如果分片在传输中还发生了重传，那么其网络开销也会增大。因此合理的MSS是至关重要的。MSS的合理值应为保证数据包不分片的最大值。对于以太网MSS可以达到1460byte。与MSS相似的在IP层也有一个类似的概念---MTU（Maximum Transfer Unit）下图可以清晰翻译MSS与MTU 的关系： MTU=MSS+TCP Header+IP Header 窗口扩大选项（windows Scaling） 我们知道TCP最大的窗口大小为64Kb，在早期网络这是够用的，但随着各种复杂网络的产生，特别是类似卫星通信这种时延和带宽都比较大的通信而产生，需要更大窗口来满足性能和高吞吐率，于是窗口扩大选项便产生了。 我们用下图一些图来说明为什么需要这个选项，和其主要功能： 我们假设 Host A—B 是一条高速的WAN链路。通信距离较远，延时也由于距离的原因变大。A向B发送大量数据，由于有足够带宽，那么A在很短时间内就可以发送完64Kb的数据，而由于窗口过小，A只能停止发送，直到B对A发送的数据进行ACK确认。上面我们可以推算，在time 2-3 和后面的 time 5-6 之间 A-B是没有实际数据发送的。而大量的时间被浪费在了等待对方回应上。 现象我们改进我们的窗口大小，使之变的更大，如下图： 现在我们把窗口扩大到256kb ，我们看到，由于窗口足够大，A可以发送大量的数据报，在其还在忙着发送报文的时间内，对A数据的ACK就已经可以返回了。（黄色的部分可以想象成一个个数据包，大量的数据包排长队在网络中传输）。这样，A-B的通信就避免了消耗大量的等待时间。对TCP的性能改善是巨大的。 Windows scaling 占3个byte，其中的一个字节表示移位值S。新的窗口值等于TCP首部的窗口位数从16增大到（16+S）。这相当于把窗口值向左移动S位后获得实际的窗口大小。移位值准许使用的最大值是14，相当于窗口最大值增大到65535*2^14 也就是 1GB。 窗口扩大选项在TCP建立之初进行协商，如果已经实现了窗口扩大，当不再需要其扩大窗口时，发送S=0选项就可以恢复到窗口大小16。 选择确认选项（Selective Acknowledgements --SACK） 我们假设TCP传输中有这种情况出现：收到的报文无差错，只是未按序列号，中间还缺少一些序列号，那么能能否只传输缺少的数据，而不重传已经正确到达的数据？这就是选择确认的技术。用下列例子来说