完整版协议分析数据报格式.docx
《完整版协议分析数据报格式.docx》由会员分享，可在线阅读，更多相关《完整版协议分析数据报格式.docx（11页珍藏版）》请在冰豆网上搜索。
完整版协议分析数据报格式
●两种不同的MAC帧格式
常用的以太网MAC帧格式有两种标准，一种是DIXEthernetV2标准，另一种是IEEE的802.3标准。
如下图所示，为便于理解，图中假定网络层使用的是IP协议。
实际上使用其他的协议也是可以的。
现在MAC帧最常用的是以太网V2的格式，它较为简单，由5个字段组成。
前两个字段分别为6字节长的目的地址和源地址字段。
第三个字段是2字节的类型宇段，用来标志上一层使用的是什么协议，以便把收到的MAC帧的数据上交给上一层的这个协议。
施乐公司负责管理这个类型字段的代码分配。
例如，当类型字段的值是0x0800时，就表示上层使用的是IP数据报。
若类型字段的值为0x8137，则表示该帧是由NovellIPX发过来的。
第四个字段是数据字段，但它的正式名称是MAC客户数据宇段，其长度在46到1500字节之间。
最后一个字段是4字节的帧检验序列FCS。
当数据字段的长度小于46字节时，MAC子层就会在数据字段的后面加入一个整数字节的填充字段，以保证以太网的MAC帧长不小于64字节。
我们应当注意到，MAC帧的首部并没有指出数据字段的长度是多少。
在有填充字段的情况下，接收端的MAC子层在剥去首部和尾部后就将数据字段和填充字段一起交给上层协议。
然而IEEE802.3标准规定的MAC帧则较为复杂。
它和以太网V2的MAC帧的区别是：
（1）第三个字段是长度/类型字段。
根据长度/类型字段的数值大小，这个字段可以表示MAC帧的数据字段长度（请注意：
不是整个MAC帧的长度），也可以等同于以太网V2的类型字段。
具体地讲：
若长度/类型字段的数值小于MAC帧的数据字段的最大值1500（字节），这个字段就表示MAC帧的数据字段长度。
若长度/类型字段的数值大于0x0600（相当于十进制的1536），那么这个数值就不可能表示以太网有效的数据字段长度，因而这个字段就表示类型。
当长度/类型字段表示类型时，802.3的MAC帧和以太网V2的MAC帧一样。
当长度/类型字段表示长度时，MAC帧就必须装入802．2标准定义的LLC子层的LLC帧。
从图中可看出，在传输媒体上实际传送的要比MAC帧还多8个字节。
这是因为当一个站在刚开始接收MAC帧时，由于尚未与到达的比特流达成同步，因此MAC帧的最前面的若干个比特就无法接收，结果使整个的MAC成为无用的帧。
为了达到比特同步，从MAC子层向下传到物理层时还要在帧的前面插入8字节（由硬件生成），它由两个字段构成。
第一个字段共7个字节，称为前同步码（1和0交替的码）。
前同步码的作用是使接收端在接收MAC帧时能够迅速实现比特同步。
第二个字段是帧开始定界符，定义为10101011，表示在这后面的信息就是MAC帧了。
在MAC子层的FCS的检验范围不包括前同步码和帧开始定界符。
顺便指出，在广域网点对点通讯中使用同步传输的HDLC规程时则不需要用前同步码，因为在同步传输时收发双方的比特同步总是一直保持着的。
802.3标准规定凡出现下列情况之一的即为无效的MAC帧：
（1）MAC客户数据字段的长度与长度字段的值不一致；
（2）帧的长度不是整数个字节；
（3）用收到的帧检验序列FCS查出有差错；
（4）收到的帧的MAC客户数据字段的长度不在46—1500字节之间。
考虑到MAC帧首部的长度是18字节，可以得出有效的MAC帧长度为64～1518字节之间。
对于检查出的无效MAC帧就简单地丢弃。
以太网不负责重传丢弃的帧。
当MAC客户数据字段的长度小于46字节时，则应加以填充（内容不限）。
这样，整个MAC帧（包含14字节首部和4字节尾部）的最小长度是64字节，或512bit。
MAC子层的标准还规定了帧间最小间隔为9.6us，相当于96bit的发送时间。
这就是说，一个站在检测到总线开始空闲后，还要等待9.6us才能发送数据。
这样做是为了使刚刚收到数据帧的站的接收缓存来得及清理，做好接收下一帧的准备。
1）
IP分组格式分析
IP数据报的格式能够说明IP协议都具有什么功能。
在TCP/IP的标准中，各种数据格式常常以32bit（即4字节）为单位来描述。
下图是IP数据报的完整格式。
一个IP数据报由首部和数据两部分组成。
首部的前一部分是固定长度，共20字节，是所有IP数据报必须具有的。
在首部的固定部分的后面是一些可选字段，其长度是可变的。
首部各字段的意义如下：
（1）IP数据报首部的固定部分中的各字段
a）版本占4bit，指IP协议的版本。
通信双方使用的IP协议的版本必须一致。
目前广泛使用的IP协议版本号为4（即IPv4）。
以前的3个版本目前已不使用。
（2）首部长度占4bit可表示的最大数值是15个单位（一个单位为4字节），因此IP的首部长度的最大值是60字节。
当IP分组的首部长度不是4字节的整数倍时，必须利用最后一个填充字段加以填充。
因此数据部分永远在4字节的整数倍时开始，这样在实现IP协议时较为方便。
最常用的首部长度值就是20字节，即不使用任何选项。
（3）服务类型占8bit，用来获得更好的服务，其意义见图的上面部分所示。
a）前三个比特表示优先级，它可使数据报具有8个优先级中的一个。
b）第4个比特是D比特，表示要求有更低的时延。
c）第5个比特是T比特，表示要求有更高的吞吐量。
d）第6个比特是R比特，表示要求有更高的可靠性（即在数据报传送的过程中，被路由器丢弃的概率要更小些）。
e）第7个比特是C比特，是新增加的，表示要求选择代价更小的路由。
f）最后一个比特目前尚未使用。
（4）总长度总长度指首部和数据之和的长度，单位为字节。
总长度字段为16bit，因此数据报的最大长度为65535字节（即64KB）。
在IP层下面的每一种数据链路层都有其自己的帧格式，其中包括帧格式中的数据宇段的最大长度MTU。
当一个IP数据报封装成链路层帧时，此数据报的总长度（即首部加上数据部分）一定不能超过下面的数据链路层的MTU值.虽然使用尽可能长的数据报会使传输效率提高，但由于以太网的普遍应用，所以实际上使用的数据报长度很少有超过1500字节的，而有时数据报长度还被限制在576字节。
当数据报长度超过网络所容许的最大传送单元MTU时，就必须将过长的数据报进行分片后才能在网络上传送（见后面的“片偏移”字段）。
这时，数据报首部中的“总长度”字段不是指未分片前的数据报长度，而是指分片后每片的首部长度与数据长度的总和。
（5）标识（identification）占16bit，它是一个计数器，用来产生数据报的标识。
但这里的“标识”并没有序号的意思，因为IP是五连接服务，数据报不存在按序接收的问题。
当IP协议发送数据报时，它就将这个计数器的当前值复制到标识字段中。
当数据报由于长度超过网络的MTU而必须分片时，这个标识字段的值就被复制到所有的数据报片的标识字段中。
相同的标识字段的值使分片后的各数据报片最后能正确地重装成为原来的数据报。
（6）标志（flag）占3bit目前只有前两个比特有意义。
a）标志字段中的最低位记为MF（MoreFragment）。
MF=1即表示后面“还有分片’的数据报。
MF=0表示这已是若干数据报片中的最后一个。
b）标志字段中间的一位记为DF（Don'tFragment），意思是“不能分片”。
只有当DF=0时才允许分片。
（7）片偏移较长的分组在分片后，某片在原分组中的相对位置。
也就是说，相对于用户数据字段的起点，该片从何处开始。
片偏移以8个字节为偏移单位。
这就是说，每个分片的长度一定是8字节（64bit）的整数倍。
[例]一数据报的数据部分为3800字节长（使用固定首部），需要分片为长度不超过1420字节的数据报片。
因固定首部长度为20字节，因此每个数据报片的数据部分长度不能超过1400字节。
于是分为3个数据报片，其数据部分的长度分别为1400，1400和1000字节。
原始数据报首部被复制为各数据报片的首部，但必须修改有关字段的值。
可能的分片按总长，标识，MF，DF，片偏移顺序排列如下：
原始数据报：
3820,12345,0,0,0
分片1：
1420，12345，1，0，0
分片2：
1420，12345，1，0，175
分片3：
1020，12345，0，0，350
标识字段的值是任意给定的。
具有相同标识的数据报片在目的站就可无误地重装成原来的数据报。
现在假定数据报片2经过某个网络时还要再进行分片，即划分为数据报片2-1（携带数据800字节）和数据报片2-2（携带数据600字节）。
那么这两个数据报片的总长度、标识、MF、DF和片偏移分别为：
820，12345，1，0，175；620，12345，1，0，275。
（8）生存时间生存时间字段记为TTL（TimeToLive），即数据报在网络中的寿命，其单位为秒。
生存时间的建议值是32秒。
但也可设定为3～4秒，甚至255秒。
例：
tracert命令的分析，利用TTL检测网络节点
（9）协议占8bit，协议字段指出此数据报携带的数据是使用何种协议，以便使目的主机的IP层知道应将数据部分上交给哪个处理过程。
（10）首部检验和此字段只检验数据报的首部，不包括数据部分。
这是因为数据报每经过一个结点，结点处理机都要重新计算一下首部检验和（一些字段，如生存时间、标志、片偏移等都可能发生变化）。
如将数据部分一起检验，计算的工作量就太大了。
（11）源地址占4字节。
（12）目的地址占4字节。
（13）可变部分：
取决于需要。
2）
TCP报文段的格式
一个TCP报文段分为首部和数据两部分。
应当指出，TCP的全部功能都体现在它首部中各字段的作用。
因此，只有弄清TCP首部各字段的作用才能掌握TCP的工作原理。
TCP报文段首部的前20个字节是固定的，后面有4N字节是根据需要而增加的选项（N必须是整数）。
因此TCP首部的最小长度是20字节。
首部固定部分各字段的意义如下：
（1）源端口和目的端口各占2个字节。
前面已讲过，端口是运输层与应用层的服务接口。
运输层的复用和分用功能都要通过端口才能实现。
（2）序号占4字节。
TCP是面向数据流的。
TCP传送的报文可看成为连续的数据流。
TCP把在一个TCP连接中传送的数据流中的每一个字节都编上一个序号。
整个数据的起始序号在连接建立时设置。
首部中的序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。
例如，一报文段的序号字段的值是301，而携带的数据共有100字节。
这就表明：
本报文段的数据的最后一个字节的序号应当是400。
我们还可看到，下一个报文段的数据序号应当从401开始，因而下一个报文段的序号字段值应为401。
（3）确认号占4字节，是期望收到对方的下一个报文段的数据的第一个字节的序号，也就是期望收到的下一个报文段首部的序号字段的值。
例如，A正确收到了B发送过来的一个报文段，其序号字段的值是501，而数据长度是200字节，这就表明A已正确收到了B发送的序号在501至700之间的数据。
因此，A期望收到B的下一个报文段的首部中的序号字段应为701，于是A在发送给B的响应报文段中将首部中的确认号置为701。
由于序号字段有32bit长，可对4GB（即4千兆字节）的数据进行编号。
这样就可保证当序号重复使用时，旧序号的数据早已在网络中消失了。
（4）数据偏移占4bit，它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。
这实际上就是TCP报文段首部的长度。
由于首部长度不固定（因首部中还有长度不确定的选项字段），因此数据偏移字段是必要的。
但应注意，“数据偏移”的单位不是字节而是32bit字（即以4字节长的字为计算单位）。
由于4bit能够表示的最大十进制数字是15，因此数据偏移的最大值是60字节，这也是TCP首部的最大长度。
（5）保留占6bit，保留为今后使用，但目前应置为0。
下面有6个比特是说明本报文段性质的控制比特。
（6）紧急比特URG（URGent）当URG=1时，表明紧急指针字段有效。
它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据），而不要按原来的排队顺序来传送。
例如，已经发送了很长的一个程序要在远地的主机上运行。
但后来发现了一些问题，需要取消该程序的运行。
因此用户从键盘发出中断命令（Control+C）。
如果不使用紧急数据，那么这两个字符将存储在接收TCP缓存的末尾。
只有在所有的数据被处理完毕后这两个字符才交付到接收应用进程。
这样做就浪费了许多时间。
当使用紧急比特并将URG置1时，发送应用进程就告诉发送TCP这两个字符是紧急数据。
于是发送TCP就将这两个字符插入到报文段的数据的最前面，其余的数据都是普通数据。
这时要与首部中第5个32bit字中的一半“紧急指针”（UrgentPointer）字段配合使用。
紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。
紧急指针使接收方知道紧急数据共有多少个字节。
紧急数据到达接收端后，当所有紧急数据都被处理完时，TCP就告诉应用程序恢复到正常操作。
值得注意的是，即使窗口为零时也可发送紧急数据。
（7）确认比特ACK只有当ACK=1时确认号字段才有效。
当ACK=0时，确认号无效。
（8）推送比特PSH（PuSH）当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。
在这种情况下，TCP就可以使用推送（push）操作。
这时，发送端TCP将推送比特PSH置1，并立即创建一个报文段发送出去。
接收TCP收到推送比特置1的报文段，就尽快地（即“推送”向前）交付给接收应用进程，而不再等到整个缓存都填满了后再向上交付。
PSH比特也可叫做急迫比特。
虽然应用程序可以选择推送操作，但推送操作还是往往不被人们使用。
TCP可以选择或不选择这个操作。
（9）复位比特RST（ReSeT）当RST=1时，表明TCP连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。
复位比特还用来拒绝一个非法的报文段或拒绝打开一个连接。
复位比特也可称为重建比特或重置比特。
（10）同步比特SYN在连接建立时用来同步序号。
当SYN=1而ACK=0时，表明这是一个连接请求报文段。
对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。
因此，同步比特SYN置为1，就表示这是一个连接请求或连接接受报文。
（11）终止比特FIN（FINal）用来释放一个连接。
当FIN=1时，表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。
（12）窗口占2字节。
窗口字段用来控制对方发送的数据量，单位为字节。
计算机网络经常是用接收端的接收能力的大小来控制发送端的数据发送量。
TCP也是这样。
TCP连接的一端根据设置的缓存空间大小确定自己的接收窗口大小，然后通知对方以确定对方的发送窗口的上限。
将TCP连接的两端分别记为A和B。
若A确定自己的接收窗口为WIN，则A发送给B的TCP报文段的窗口字段中写入WIN的数值。
这就是告诉B的TCP，“你（b）在未收到我（a）的确认时所能够发送的数据量的上限就是从本首部中的确认号开始的WIN个字节。
”所以A所设定的WIN既是A的接收窗口，同时也就是B的发送窗口的上限值。
例如，A在发送给B的报文段的首部中将窗口字段的值WIN置为500，将确认号置为201。
这就是告诉B：
“你（b）在未收到确认的情况下，最多可向我（a）发送序号从201开始到700共500字节的数据”。
B在收到此报文段后，就用此窗口数值500作为B的发送窗口的上限值。
但应注意，B向A发送的报文段的首部也有一个窗口字段，但这是根据B的接收能力来确定A的发送窗口上限，一定不要弄混。
（13）检验和占2字节。
检验和字段检验的范围包括首部和数据这两部分。
和UDP用户数据报一样，在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。
伪首部的格式与UDP用户数据报的伪首部一样。
但应将伪首部第4个字段中的17改为6（TCP的协议号是6），将第5字段中的UDP长度改为TCP长度。
接收端收到此报文段后，仍要加上这个伪首部来计算检验和。
（14）选项长度可变。
TCP只规定了一种选项，即最大报文段长度MSS（MaximumSegmentSize）。
MSS告诉对方TCP：
“我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节。
”当没有使用选项时，TCP的首部长度是20字节。
MSS的选择并不太简单。
若选择较小的MSS长度，网络的利用率就降低。
设想在极端的情况下，当TCP报文段只含有1字节的数据时，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。
这样，对网络的利用率就不会超过1／41。
到了数据链路层还要加上一些开销。
但反过来，若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。
在目的站要将收到的各个短数据报片装配成原来的TCP报文段。
当传输出错时还要进行重传。
这些也都会使开销增大。
一般认为，MSS应尽可能大些，只要在IP层传输时不需要再分片就行。
在连接建立的过程中，双方都将自己能够支持的MSS写入这一字段。
在以后的数据传送阶段，MSS取双方提出的较小的那个数值。
若主机未填写这项，则MSS的默认值是536字节长。
因此，所有在因特网上的主机都应能接受的报文段长度是536+20=556字节。
3）TCP的数据编号与确认
TCP协议是面向字节的。
TCP将所要传送的整个报文（这可能包括许多个报文段）看成是一个个字节组成的数据流，并使每一个字节对应于一个序号。
在连接建立时，双方要商定初始序号。
TCP每次发送的报文段的首部中的序号字段数值表示该报文段中的数据部分的第一个字节的序号。
TCP的确认是对接收到的数据的最高序号（即收到的数据流中的最后一个序号）表示确认。
但接收端返回的确认号是已收到的数据的最高序号加1。
也就是说，确认号表示接收端期望下次收到的数据中的第一个数据字节的序号。
TCP传输的可靠是由于使用了序号和确认。
当TCP发送一报文段时，它同时也在自己的重传队列中存放一个副本。
若收到确认，则删除此副本。
若在计时器时间到之前没有收到确认，则重传此报文段的副本。
TCP的确认并不保证数据已由应用层交付给了端用户，而只是表明在接收端的TCP收到了对方所发送的报文段。
由于TCP连接能提供全双工通信，因此通信中的每一方都不必专门发送确认报文段，而可以在传送数据时顺便把确认信息捎带传送。
这样做可以提高传输效率。
TCP有三种基本机制来控制报文段的发送。
第一种机制是TCP维持一个变量，它等于最大报文段长度MSS。
只要发送缓存从发送进程得到的数据达到MSS字节时，就组装成一个CP报文段，然后发送出去。
第二种机制是发送端的应用进程指明要求发送报文段，即TCP支持的推送（push）操作。
第三种机制是发送端的一个计时器时间到了，这时就把当前已有的缓存数据装入报文段发送出去。
但是，如何控制TCP发送报文段的时机仍然是一个较为复杂的问题。
例如，一个交互式用户使用一条TELNET连接（运输层为TCP协议）。
设用户只发一个字符。
加上20字节的首部后，得到21字节长的TCP报文段。
再加上20字节的IP首部，形成41字节长的IP数据报。
在接收端TCP立即发出确认，构成的数据报是40字节长（假定没有数据发送）。
若用户要求远地主机回送这一字符，则又要发回41字节长的IP数据报和40字节长的确认IP数据报。
这样，用户仅发一个字符时线路上就需传送总长度为162字节共4个报文段。
当线路带宽并不富裕时，这种传送方法的效率的确不高。
因此应适当推迟发回确认报文，并尽量使用捎带确认的方法。
若发送方在规定的设置时间内没有收到确认，就要将未被确认的报文段重新发送。
接收方若收到有差错的报文段，则丢弃此报文段（不发送否认信息）。
若收到重复的报文段，也要将其丢弃，但要发回（或捎带发问）确认信息。
这与数据链路层的情况相似。
若收到的报文段无差错，只是未按序号，那么应如何处理?
TCP对此未作明确规定，而是让TCP的实现者自行确定。
或者将不按序的报文段丢弃，或者先将其暂存于接收缓存内，待所缺序号的报文段收齐后再一起上交应用层。
如有可能，采用后一种策略对网络的性能会更好些。
4）流量/拥塞控制与滑动窗口
为了提高报文段的传输效率，TCP采用大小可变的滑动窗口进行流量控制。
窗口大小的单位是字节。
在TCP报文段首部的窗口字段写入的数值就是当前给对方设置的发送窗口数值的上限。
发送窗口在连接建立时由双方商定。
但在通信的过程中，接收端可根据自己的资源情况，随时动态地调整对方的发送窗口上限值（可增大或减小）。
这种由接收端控制发送端的做法，在计算机网络中经常使用。
下面通过图示说明利用可变窗口大小进行流量控制。
设主机A向主机B发送数据。
双方确定的窗口值是400。
再设每一个报文段为100字节长，序号的初始值为1（见图中第一个箭头上的SEQ=1。
图中右边的注释可帮助理解整个的过程）。
我们应注意到，主机B进行了三次流量控制。
第一次将窗口减小为300字节，第二次又减为200字节，最后一次减至零，即不允许对方再发送数据了。
这种暂停状态将持续到主机B重新发出一个新的窗口值为止。
发送端利用发送窗口（这个窗口取决于对方的接收窗口）调节向网络注入分组的速率不仅仅是为了使接收端来得及接收，而且还是为了对网络进行拥塞控制。
我们知道，拥塞发生在通过网络传输的分组数量开始接近网络对分组的处理能力时。
从这个角度看，拥塞控制的目标就是将网络中的分组数量维持在一定的水平之下。
若网络中的分组数量超过这个水平，网络的性能就会急剧恶化。
拥塞控制也是运输层必须解决的一个非常复杂的问题。
5）TCP的运输连接管理
（1）运输连接的三个阶段
TCP是面向连接的协议。
运输连接是用来传送TCP报文的。
TCP的运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。
因此，运输连接就有三个阶段，即：
连接建立、数据传送和连接释放。
运输连接的管理就是使运输连接的建立和释放都能正常地进行。
在连接建立过程中要解决以下三个问题：
（1）要使每一方能够确知对方的存在。
（2）要允许双方协商一些参数（如最大报文段长度，最大窗口大小，服务质量等）。
（3）能够对运输实体资源（如缓存大小，连接表中的项目等）进行分配。
TCP的连接和建立都是采用客户服务器方式。
主动发起连接建立的应用进程叫做客户（client），而被动等待连接建立的应用进程叫做服务器（server）。
设主机B中运行一个服务器进程，它先发出一个被动打开（passiveopen）命令，告诉它的TCP要准备接受客户进程的连接请求。
然后服务器进程就处于“听”（listen）的状态，不断检测是否有客户进程要发起连接请求。
如有，即作出响应。
设客户进程运行在主机A中。
它先向其TCP发出主动打开（activeopen）命令，表明要向某个IP地址的某个端口建立运输连接。
主机A的TCP向主机B的TCP发出连接请求报文段，其首部中的同步比特SYN应置1，同时选择一个序号x，表明在后面传送数据时的第一个数据字节的序号是x+l。
主机B的TCP收到连接请求报文段后，如同意，则发问确认。
在确认报文段中应将SYN和ACK都置1，确认号应为x+1，同时也为自己选择一个序号y。
主机A的TCP收到B的确认后，要向B给出确认，其ACK置1，确认号为y+1，而自己的序号为x+1。
TCP的标准规定，SYN置1的报文段要消耗掉1个序号。
运行客户进程的主机A的TCP通知上层应用进程，连接已经建立。
当主机A向B发送第一个数据报文段时，其序号仍为x+1，因为前一个确认报文段并不消耗序号。
当运行服务器进程的主机B的TCP收到主机A的确认后，也通知其上层应用进程，连接已经建立。
连接建立采用的这种过程叫做三次握手（three-wayhandshake），或
升级会员 