IPv6及TCP协议帧格式.docx
《IPv6及TCP协议帧格式.docx》由会员分享，可在线阅读，更多相关《IPv6及TCP协议帧格式.docx（11页珍藏版）》请在冰豆网上搜索。
IPv6及TCP协议帧格式
一、TCP协议由RFC793定义：
TCP（TransmissionControlProtocol传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。
面向连接：
在应用TCP协议进行通信之前双方通常需要通过三次握手来建立TCP连接，连接建立后才能进行正常的数据传输，因此广播和多播不会承载在TCP协议上。
可靠性：
由于TCP处于多跳通信的IP层之上，而IP层并不提供可靠的传输，因此在TCP层看来就有四种常见传输错误问题，分别是比特错误（packetbiterrors）、包乱序（packetreordering）、包重复（packetduplication）、丢包（packeterasure或称为packetdrops），因此TCP要提供可靠的传输，就需要具有超时与重传管理、窗口管理、流量控制、拥塞控制等功能。
字节流式：
应用层发送的数据会在TCP的发送端缓存起来，统一分片（例如一个应用层的数据包分成两个TCP包）或者打包（例如两个或者多个应用层的数据包打包成一个TCP数据包）发送，到接收端的时候接收端也是直接按照字节流将数据传递给应用层。
作为对比，同样是传输层的协议，UDP并不会对应用层的数据包进行打包和分片的操作，一般一个应用层的数据包就对应一个UDP包。
TCP报文格式：
TCP封装在IP报文中的时候，如下图所示，TCP头紧接着IP头（IPV6有扩展头的时候，则TCP头在扩展头后面），不携带选项（option）的TCP头长为20bytes，携带选项的TCP头最长可到60bytes。
其中headerlength字段由4比特构成，最大值为15，单位是32比特，即头长的最大值为15*32bits=60bytes，因此上面说携带选项的TCP头长最长为60bytes。
TCP的源端口、目的端口、以及IP层的源IP地址、目的IP地址四元组唯一的标识了一个TCP连接
TCP各字段释义：
TCP源端口（SourcePort）：
16位的源端口其中包含发送方应用程序对应的端口。
源端口和源IP地址标示报文发送端的地址。
TCP目的端口（Destinationport）：
16位的目的端口域定义传输的目的。
这个端口指明报文接收计算机上的应用程序地址接口。
TCP序列号（SequenceNumber）：
32位的序列号标识了TCP报文中第一个byte在对应方向的传输中对应的字节序号。
当SYN出现，SN=ISN（随机值）单位是byte。
比如发送端发送的一个TCP包净荷（不包含TCP头）为12byte，SN为5，则发送端接着发送的下一个数据包的时候，SN应该设置为5+12=17。
通过序列号，TCP接收端可以识别出重复接收到的TCP包，从而丢弃重复包，同时对于乱序数据包也可以依靠系列号进行重排序，进而对高层提供有序的数据流。
另外如果接收的包中包含SYN或FIN标志位，逻辑上也占用1个byte，应答号需加1。
TCP应答号（AcknowledgmentNumber简称ACKNumber）：
32位的ACKNumber是期望收到对方下一个报文段的数据的第一个字节的序号。
如果设置了ACK控制位，这个值表示一个准备接收的包的序列码，注意是准备接收的包，比如当前接收端接收到一个净荷为12byte的数据包，SN为5，则会回复一个确认收到的数据包，如果这个数据包之前的数据也都已经收到了，这个数据包中的ACKNumber则设置为12+5=17，表示之前的数据都已经收到了，准备接受SN=17的数据包。
头长（HeaderLength）：
4位包括TCP头大小，指示TCP头的长度，即数据从何处开始。
TCP最多有60（15*4）字节的首部
保留（Reserved）：
4位值域，这些位必须是0。
为了将来定义新的用途所保留，其中RFC3540将Reserved字段中的最后一位定义为Nonce标志。
后续拥塞控制部分的讲解我们会简单介绍Nonce标志位。
标志（CodeBits）：
8位标志位，下面介绍。
窗口大小（WindowSize）：
16位即2个字节，用来控制对方发送的数据量，单位是字节，指明对方发送窗口的上限。
该值指示了从AckNumber开始还愿意接收多少byte的数据量，也即用来表示当前接收端的接收窗还有多少剩余空间，用于TCP的流量控制。
窗口大小最大为65535（2^16-1）。
校验位（Checksum）：
16位TCP头。
发送端基于数据内容计算一个数值，接收端要与发送端数值结果完全一样，才能证明数据的有效性。
接收端checksum校验失败的时候会直接丢掉这个数据包。
CheckSum是根据伪头+TCP头+TCP数据三部分进行计算的。
校验的范围包括首部和数据两个部分，计算校验和时需要在报文段前加上12字节的伪首部。
优先指针（紧急,UrgentPointer）：
16位，指出本报文段中紧急数据最后一个字节的序号。
只有当紧急比特URG=1时才有效。
如果URG标志没有被设置，紧急域作为填充。
选项（Option）：
长度不定，但长度必须以是32bits的整数倍。
常见的选项包括MSS、SACK、Timestamp等等。
八位标志位分别介绍如下：
CWR（CongestionWindowReduce）：
拥塞窗口减少标志setbysender，用来表明它接收到了设置ECE标志的TCP包。
并且sender在收到消息之后已经通过降低发送窗口的大小来降低发送速率。
ECE（ECNEcho）：
ECN响应标志被用来在TCP3次握手时表明一个TCP端是具备ECN功能的。
在数据传输过程中也用来表明接收到的TCP包的IP头部的ECN被设置为11。
注：
IP头部的ECN被设置为11表明网络线路拥堵。
注：
关于CWR和ECE标记为详细信息可参考：
紧急比特URG（Urgent）：
该标志位置位表示紧急（Theurgentpointer）标志有效。
该标志位目前已经很少使用参考后面流量控制和窗口管理部分的介绍。
当URG=1时，表明紧急指针有效。
它告诉系统报文段中有紧急数据，应尽快传送。
确认比特ACK：
取值1代表AcknowledgmentNumber字段有效，这是一个确认的TCP包，取值0则不是确认包。
即ACK=1时确认号字段才有效，ACK=0时确认号字段无效。
当ACK标志位有效的时候我们称呼这个包为ACK包，使用大写的ACK称呼。
推送比特PUSH（Push）：
接收方接收到PUSH=1的报文段时会尽快的将其交付给接收应用进程，而不再等到整个接收缓存都填满后再向上交付，PUSH=0一般是表示发送端缓存中已经没有待发送的数据，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。
在处理telnet或rlogin等交互模式的连接时，该标志总是置位的。
复位比特RST（Reset）：
用于reset相应的TCP连接。
通常在发生异常或者错误的时候会触发复位TCP连接。
当RST=1时，表明TCP连接中出现严重差错，必须释放连接。
复位比特还用来拒绝一个非法的报文段或拒绝打开一个连接。
同步比特SYN：
同步序列编号（SynchronizeSequenceNumbers）有效。
该标志仅在三次握手建立TCP连接时有效，在连接建立时用来同步序号。
当SYN=1而ACK=0时，表明这是一个连接请求报文段，对方若同意建立连接，应在响应的报文段中使SYN=1和ACK=1。
因此，SYN=1就表示这是一个连接请求或连接接收报文。
终止比特FIN（Finish）：
Nomoredatafromsender。
当FIN标志有效的时候我们称呼这个包为FIN包。
当FIN=1时，表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。
二、IPv6协议由RFC2460规范：
ipv6的报文格式如下：
version：
4bits，ipv6版本号为6（0110）
TrafficClass:
8bits,传输类别，可用于源节点或转寄路由器标识和区分IPV6包中的不同类别或优先级；类似于实现IPV4的TOS/DIFF
FlowLabel：
20bits流标签，数据流是指从某特定的源节点向某特定的目的节点发送的数据包序列。
当源节点希望中间的路由器对数据包进行一些特殊处理时，就可以使用数据流标签，不支持数据流标签的可以赋值为0；
PayloadLength:
16bitsunsignedinteger,ipv6的载荷长度，首部以外的长度（包括扩展首部）
NextHeader：
8bits指明紧跟IP首部后面的下一个首部的类型
HopLimit：
8bitsunsignedinteger，在每个传输此包的节点处减1，如果跳数限制减到0，就抛弃此包
SourceAddress：
128bit源地址
DestnationAddress：
128bit目的地址
扩展首部格式：
在IPv6里，可选的网络层信息在一个独立的首部编码，放在包中IPv6首部与上层协议首部之间。
有这样几个为数不多的扩展首部，每个首部由不同的"下一个首部"的值来标识。
一个IPv6首部可以携带零个，一个或者更多的扩展首部，每个扩展首部由前一个首部中的"下一个首部"字段标识。
1、下面是几个扩展首部的例子：
一般情况下（hop-by-hop选项首部例外），扩展首部在数据包的传递过程中，中间的任何节点不会检测和处理，一直到这个ipv6首部中目的地址所标识的那个节点。
特例：
hop-by-hop选项首部，携带了包的传送路径中的每个节点都必须检测和处理的信息。
包括源节点和目的节点。
如果HOP-BY-HOP选项首部存在，就必须紧跟在ipv6首部后面。
2、扩展首部出现的顺序
当在同一个包中使用多个扩展首部时，建议按如下顺序排列这些扩展首部：
ipv6header
hop-by-hopoptionsheader（HOP-BY-HOP首部）
destionaionoptionsheader （目的地址选项首部）
routingheader （路由首部）
fragmentheader （分片首部）
authenticationheader（认证首部）
encapsulatingsecuritypayloadheader封装安全载荷首部
destinationoptionsheader （目的地址选项首部）
upper-layerheader上层协议首部
除了目的地址选项首部最多出现两次（一次在路由首部前，一次在上层协议首部前）以外，每个扩展首部应当只出现一次。
如果上层协议首部是另一个IPv6首部（在使用通道技术或封装在IPv6中的情况下），它后面可以有自己的扩展首部.这些扩展首部以同样的建议顺序独立排列。
如果定义了其他的扩展首部，与上面列出的扩展首部相关的次序限制必须加以说明。
除了Hop-by-Hop选项首部必须紧跟在IPv6首部后面以外,IPv6节点必须接受并且尽量处理任意顺序的，以及在同一个包内出现任意多次的扩展首部。
尽管如此，建议IPv6包的源节点遵守上面的建议顺序，除非后续的协议规范修改这一顺序。
3、选项
在hop-by-hop和目的地址选项首部，包含若干个以类型-长度-值格式进行编码的选项，格式如下：
Optiontype:
8bit，标识选项类型；
Optdatalen：
8位无符号整数。
以八位组为单位的选项数据字段的长度；
Optiondata：
可变长度，依选项类型而不同的数据；
首部中的选项必须严格按照它们在首部中出现的次序来处理；这样，接收方就不能搜索整个首部来寻找某个特定类型的选项，并且在处理所有前面的选项之前处理它。
选项类型标识符以如下规则编码:
其最高两位指定了当IPv6节点无法识别这一选项类型时所必须的反应:
00：
跳过这个选项，继续处理首部
01：
丢弃这个包
10：
丢弃这个包，不管包的目的地址是不是组播地址，并给源地址发送一个“参数错误”的icmp，同时指针指向无法识别的选项类型
11：
丢弃这个包，并且如果目的地址不是组播地址时，给源地址发送一个参数错误的icmp，同时指针指向无法识别的选项类型
选项类型标识符的第三位指明了选项数据是否可以改变到最终目的地址的选路。
若存在认证首部，在包计算或校验认证值时，可改变选路的选项的整个数据字段都必须当作全零的八位组来处理。
选项的第三个比特：
0：
选项数据不会改变选路
1：
选项数据可能改变选路
4、Hop-by-Hop选项头部
用IPV6首部的”下一个首部“为0（0x00）来标识，此选项头部用于传送在数据包的传送路径中每个节点都必须检测的可选信息。
格式如下：
Nextheader:
8bits,紧跟在hop-by-hop选项首部后面的首部类型式
Hdr Ext len：
8bitshop-by-hop选项首部的长度，不包括开始的8个八位组
options：
可变长度字段，其长度须使整个Hop-by-Hop选项首部的长度为8个八位组的整数倍。
包含一个或多个TLV编码的选项
5、路由首部
nextheader=43标识；用于IPV6源节点列出到目的节点的路径中所应"访问"的一个或多个中间节点，格式如下：
Nextheader（下一个首部）：
8bit紧跟在路由首部后面的首部类型
HdrExtLen（首部扩展长度）：
8bit 路由首部长度，不包括开始的8个八位组
RoutingType（路由类型）：
8bit标识路由头部类型
Segementsleft（分段剩余）：
8bit无符号整数。
剩余的路由分段的数量。
也就是在到达最终的目的节点之前仍然应当访问的，明确列出的中间节点的数量。
type-specificdata（特定类型的数据）：
可变长度字段。
其格式由路由类型（routingtype）决定，其长度须使整个路由首部的长度为8个八位组的整数倍。
如果节点在处理收到的包的过程中遇到了含有无法识别的路由类型值的路由首部,节点应根据分段剩余字段中的值进行处理，如下所述:
如果分段剩余值是零，节点必须忽略路由首部，继续处理包中的下一个首部，其类型由路由首部中的"下一个首部"字段中的值来标识。
如果分段剩余值非零，节点必须抛弃这个包，并且给包的源地址发送一个ICMP"参数存在问题"，编码0的报文，指针指向无法识别的路由类型。
如果中间节点在处理路由首部之后，确定应将包传送到一个链路MTU小于此包的大小的链路中去，那么中间节点必须抛弃此包，并且给包的源地址发送一个ICMP"包太大"的报文。
6、分片首部
nextheader=44标识；在ipv6中，只有源节点才可以分片，中间路由器不能分片，当发送的数据包长度大于MTU时，就需要分片，分片首部的格式如下：
nextheader:
8bit 标识原包（后面有定义）中可分片部分的初始首部的类型。
reserved：
8位保留字段。
传输时初始化为零；接收时忽略。
fragmentoffset：
13bit，分片偏移量。
首部后面的数据相对于原包中可分片部分的开始位置处的偏移量
Res：
2bit，保留，传输时初始化为零；接收时忽略。
Mflag：
标识是否还有分片（1=还有分片；0=最后一个分片。
）
Identification：
32bit，标识符
7、目的选项首部
nextheader=60标识，用于携带仅需要目的节点检测的可选信息。
格式如下：
nextheader：
8bit标识紧跟在目的地址选项首部后面的首部的类型。
HdrExtLen:
8bit目的选项首部长度，不包括开始的8个八位组
options：
可变长度。
一个或多个TLV格式的选项
8、无下一个首部：
nextheader=59（0x3b）IPv6首部或者扩展首部中"下一个首部"的值为59表示这个首部后面没有其他的首部了。
如果IPv6首部中的有效数据字段表明最后一个首部（"下一个首部"字段为59的那个首部）后面还有其他的八位组，那么这些八位组将被忽略，并且在传输过程中保持不变。
升级会员 