序言
对常见的一些协议类型，比如RTP/TCP/UDP/IP/MAC等协议类型报头格式做一些总结。
1. RTP
1.1 RTP协议简介
(1) 实时传输协议RTP提供带有实时特性的端到端数据传输服务，如在单播或组播网络服务下的交互式视频音频或模拟数据。
(2) RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。
(3) RTP 本身并不提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置。
(4) rtp协议提供了时间标签，序列号以及其它的结构用于控制适时数据流的播放。发送端依照即时的采样在数据包里设置了时间标签，在接受端收到数据包后，就依照时间标签按照正确的速率恢复成原始的适时的数据。在rtp协议中，一帧数据被分割成几个包，这几个包具有相同的时间标签，但是每一个包又具有不同的序号。
1.2 RTP报头结构
- 版本（V，2bits）：RTP版本
- 填充标识（P，1bit）：如设置填充位，在包尾将包含附加填充字，它不属于有效载荷。填充的最后一个字节count字段指明可以忽略多少个填充比特。某些加密算法需要固定大小的填充字，或为在底层协议数据单元中携带几个RTP包
- 扩展（X，1bit）：如设置扩展位，固定头后跟一个头扩展
- CSRC计数（CC，4bits）：CSRC计数包括紧接在固定头后CSRC标识符个数
- 标记（M，1bit）：标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标示位，或通过改变位数量来指定没有标记位
- 载荷类型（PT，7bits）：记录后面资料使用哪种编解码方式，接收端找出相应的解码方式解码
| Payload Type | Codec |
|---|---|
| PCM μ-Law | |
| 8 | PCM A-Law |
| 9 | G..722 audio codec |
| 4 | G..723 audio codec |
| 15 | G..728 audio codec |
| 18 | G..729 audio codec |
| 34 | G..763 audio codec |
| 31 | G..761 audio codec |
- 序列号（SN，16bits）：系列号随每个RTP数据包而增加1，由接收者用来探测包丢失。系列号初值是随机的，使对加密的文本攻击更加困难
- 时间戳（TS，32bits）：时间戳反映RTP数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟（比如NTP参考时钟）导出，以允许同步与抖动计算。时间戳可以让接收端知道在正确的时间将资料播放出来。
- 不同媒体流的 RTP 时间戳可能以不同的速率增长，而且会有独立的随机偏移量。
- 因此，虽然这些时间戳足以重构一个单独的流的时间，但直接比较不同的媒体流的时间戳不能进行同步。
-
对于每一个媒体，我们把与采样时刻相关联的RTP时间戳与来自于参考时钟上的时间戳(NTP)相关联。
采样时刻的时间戳就是数据的采样时间。
-
(即：RTP 时间戳可用来实现不同媒体流的同步，NTP 时间戳解决了 RTP 时间戳有随机偏移量的问题)
参考时钟用于同步所有媒体的共同时间。
- 这一时间戳对(RTP 时间戳和 NTP 时间戳)，用于判断 RTP 时间戳和 NTP 时间戳的对应关系，以进行媒体流的同步。
- 该时间对不是在每一个数据包中都被发送，而在发送速率更低的 RTCP 的 SR(发送者报告)中。
- 同步源标识（SSRC，32bits）：此标识不是随机选择的，目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识，使其不依赖于网络地址。
- 一个同步源的所有包构成了相同计时和序列号空间的一部分，这样接收方就可以把一个同步源的包放在一起，来进行重放。
- 尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决冲突。如果源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。
- 同步源的例子，来自同一信号源的包流的发送方，如麦克风、摄影机、RTP混频器就是同步源，一个同步源可能随着时间变化而改变其数据格式，如音频编码。
- 参与者并不需要在一个多媒体会议的所有 RTP 会话中，使用相同的 SSRC 标识符；如果参与者在一个 RTP 会话中生成了多个流，例如来自多个摄影机，则每个摄影机都必须标识成单独的同步源。
- SSRC标识符的绑定通过RTCP。
- 贡献源列表（CSRC，32bits）：0 到 15 项，每项 32 比特，CSRC 列表识别在此包中负载的所有贡献源。
- 识别符的数目在 CC 域中给定。
- 若有贡献源多于 15 个，仅识别 15 个。
- CSRC 识别符由混合器插入，并列出所有贡献源的 SSRC 识别符。例如语音包，混合产生新包的所有源的 SSRC 标识符都被列出，以在接收端处正确指示参与者。
1.3 RTP扩展头结构
(1) 若RTP固定头部的扩展字段（X）置1，则一个长度可变的头扩展部分被加到 RTP 固定头部之后，如果有CSRC列表，则在CSRC列表之后
(2) RTP固定头部之后只允许有一个头扩展
-
前16 比特用以识别标识符或参数。
允许多个互操作实现独立生成不同的头扩展，或某种特定实现有多种不同的头扩展。这16比特的格式由具体实现的上层协议定义
-
16 比特的长度域。
指示扩展项中 32 比特字的个数，不包括 4 个字节头扩展（因此零是有效值）
RTP提供扩展机制以允许实现个性化：某些新的与负载格式独立的功能要求的附加信息在RTP 数据包头中传输。设计此方法可以使其它没有扩展的交互忽略此头扩展。
2. UDP
2.1 UDP报头结构
- 源端口（16bits）：用来标识源端应用进程
- 目的端口（16bits）：用来标识目的端应用进程
- 长度字段（16bits）：标明UDP头部和UDP数据的总长度，字节计
- 校验和（16bits）：用来对UDP头部和UDP数据进行校验，需要添加UDP伪头部参与计算
3. TCP
3.1 TCP报头结构
- 源端口(Source Port，16bits)：源端口字段包含初始化通信的端口号。源端口和IP地址的作用是标识报文的返回地址。
- 目的端口(Destination Port，16bits)：目的端口字段定义传输的目的地。这个端口指明接收方计算机上的应用程序接口。
- 序列号（Sequence Number，32bits）：该字段用来标识TCP源端设备向目的端设备发送的字节流，它表示在这个报文段中的第几个数据字节。
- 确认号（Acknowledge Number，32bits）：TCP使用32位的确认号字段标识期望收到的下一个段的第一个字节，并声明此前的所有数据已经正确无误地收到。因此，确认号应该是上次已成功收到的数据字节序列号加1。收到确认号的源计算机会知道特定的段已经被收到。确认号的字段只在ACK标志被设置时才有效。
- 数据偏移（Data Offset，4bits）：该字段字段表示TCP头部大小，以4字节为单位，最长60字节。
- 保留字段（Reserved，6bits）：为将来定义新的用途保留，均置0。
- 控制位(Control Bits，6bits)：共6位，每一位标志可以打开一个控制功能。
- URG(Urgent Pointer Field Significant，1bit)：紧急指针字段标志，与紧急指针字段配合使用。表示TCP包的紧急指针字段有效，用来保证TCP连接不被中断，并且督促中间齐备尽快处理这些数据。
- ACK（Acknowledgement field significant，1bit）：确认字段标志。取1时表示应答字段有效，也即TCP应答号将包含在TCP段中，为0无效。
- PSH(Push Function，1bit)：推功能。Push操作指在数据包到达接收端以后，立即送给应用层/应用程序，而不是在缓冲区中排队，等填满之后再向上交付。
- RST（Reset the connection，1bit）：重置连接。这个标志表示表示连接复位请求，用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包。当RST=1时，表示呈现严重错误，必须断开连接，然后再重建传输连接。
- SYN（Synchronize sequence numbers，1bit）：同步序列号。表示同步序号，用来建立连接。
- FIN（No more data from sender，1bit）：表示发送端已经发送到数据末尾，数据传送完成，发送FIN标志位的TCP段，连接将被断开。
- 窗口（Window，16bits）：默示报文段发送方的接管窗口，单位为字节。此窗口告诉对方，“在未收到我的确认时，你可以发送的数据的字节数至多是此窗口的大小“。
- 校验和（Checksum，16bits）：TCP头包括16位的校验和字段用于错误检查。源主机基于部分IP头信息，TCP头和数据内容计算一个校验和，目的主机也要进行相同的计算，如果收到的内容没有错误，两个计算应该完全一样，从而证明数据的有效性。
- 紧急指针（Urgent Pointer，16bits）：紧急指针字段是一个可选的16位指针，指向段内的最后一个字节位置，这个字段只在URG标志被设置时才有效。
- 选项（Option，长度不定）：至少1字节的可变长字段，标识哪个选项（有多种选项类型，比如”窗口扩大因子”、”时间戳”等选项）有效。如果没有选项，这个字节等于0，说明选项的结束。这个字节等于1表示无需再有操作；等于2表示下四个字节包括源机器的最大长度（Maximum Segment Size，MSS）等。
- 填充（Padding，长度不定）：这个字段中加入额外的零，以保证TCP头是32比特的整数倍。
4. IP
4.1 IP报头结构
- 版本（Version, 4bit）：为4代表ipv4, 为6代表ipv6。
- 报头长度（Header Length，4bit）：以4字节为单位，一般为5, 代表IP首部一共占用20个字节。
- 服务类型（Type of Service，）：用来指定特殊的数据包处理方式。服务类型字段实际上被划分为2个子字段：优先权和ToS。优先权用来设置数据包的优先级；ToS允许按照吞吐量、时延、可靠性和费用方式选择传输服务。Tos通常不用所有位都被设置为0，在OSPF路由协议的早期规范中还称为ToS路由选择，优先级偶尔在服务质量（QoS）应用中使用。
- Bits 0-2：Precedence. （优先权）
- Bit 3：0 = Normal Delay, 1 = Low Delay. （延迟）
- Bits 4：0 = Normal Throughput, 1 = High Throughput. （吞吐量）
- Bits 5：0 = Normal Relibility, 1 = High Relibility. （可靠性）
- Bit 6：0 = Normal Cost, 1 = High Cost. （开销）
- Bit 7：Reserved for Future Use. （保留）
Precedence
000 - Routine 路由
001 - Priority 优先级
010 - Immediate 立即
011 - Flash 火速
100 - Flash Override 火速覆盖
101 - CRITIC/ECP 紧急
110 - Internetwork Control 互联网控制
111 - Network Control 网络控制
优先级0为默认标记值
优先级1和2给数据业务使用
优先级3给语音控制数据使用
优先级4由视频会议和视频流使用
优先级5推荐给语音数据使用
优先级6和7一般保留给网络控制数据使用，如路由。
但是随着网络的发展 ToS字段已经作为区分服务架构的一部分被重新定义了。
DSCP：开始的6个位（0-5）现在构成了区分代码点（Differentiated Services Code Point，DSCP），利用这6位我们可以使用任意数值或根据在区分服务体系结构中预先定义的服务类别，最多可以定义64个不同服务类别，并可以整理到PHB中。
PHB：在Diff-serv中，能够在一台路由器定义服务分类，将数据包归类到这些分类中去。路由器可以根据它们的分类使用不同的优先级对数据包进行排序和转发。每一个排序和处理被称为Per-Hop Behavior(逐跳行为PHB）是由Diff-serv定义的这个机制本身称为区分服务类别（Class of Service，CoS）。
ECN：显示拥塞通知（Explicit Congestion Notification，ECN）在上图中显示拥塞通知是某些路由器支持显示拥塞通知的。当路由器支持该特性时，这些位可用于拥塞信号（ECN = 11）
- 报文长度（Length, 16bit）：IP首部 + 数据部分的总长度。
- 标识符（Identification，16bits）：通常与标记字段和分片字段一起用于数据包的分段和重组，唯一地标识主机发送的每一份数据报。通常每发送一份IP报文它的值就会加1。
- 标记字段（Flags，3bits）：用于IP数据包分段标记使用；一共3位，第1位不使用，第2位是DF位，当DF为1时，表示路由器不允许分段处理，为0时，表示允许分段。第3位是MF位，当MF为1时，表示不是最后一个分段，为0时，表示是最后一个分段。
- Bit 0：reserved, must be zero
- Bit 1：(DF) 0 = May Fragment, 1 = Don’t Fragment
- Bit 2：(MF) 0 = Last Fragment, 1 = More Fragments
- 分段偏移(Fragment Offset，13bits)：本数据包的数据在分段中的偏移用于指明分段起始点相对于报头起始点的偏移量，可以使接受者按照正确的顺序重组数据包。长度13位，以8个字节为单位。
- 生存时间(Time To Live，8bits)：用于防止数据包在网络上无休止地被传输；最大值255，每经过一台路由器，TTL值减1。
- 用户协议(Protocol, 8bits)：确定在数据包内传送的上层协议，和端口号类似，IP 协议用协议号区分上层协议。
| Protocol Number | Host-to-Host Layer Protocol |
|---|---|
| 1 | ICMP：Internet Control Message Protocol |
| 2 | IGMP：Internet Group Management Protocol |
| 4 | IP in IP (encapsulation) |
| 6 | TCP：Transmission Control Protocol |
| 17 | UDP：User Datagram Protocol |
| 45 | IDRP：Inter-Domain Routing Protocol |
| 46 | RSVP：Resource Reservation Protocol |
| 47 | GRE：Generic Routing Encapsulation |
| 54 | NHRP：NBMA Next Hop Resolution Protocol |
| 88 | IGRP：Cisco Internet Gateway Routing Protocol |
| 89 | OSPF：Open Shortest Path First |
- 报头校验和（Header Checksum，16bits）：计算IP 头部的校验和，检查报文头部的完整性。
- 源IP地址和目的IP地址（各32bits）：标识数据包的源端设备和目的端设备。
-
选项（Options，长度可变）：主要用于测试。一般格式为”1字节的代码 + 1字节的长度 + 1字节的指针“，指针的值从1开始计数，指向IP选项的内容，一般其值为4(跳过了前面的代码&长度&指针的三个字节)，长度包括前面3个字节在内的整个IP选项，最大值为40。
可选项如下：
- 松散源路由选择（loose source routing）：它给出了一连串路由器接口的IP地址序列。数据包必须沿着IP地址序列传送，但是允许相继的2个地址之间可跳过多台路由器。
- 严格源路由选择（strict source routing）：也给出了一连串路由器接口的IP地址序列，不同于松散源路由选择的是，数据包必须按照路由转发。如果下一条不在路由表，就将会发生错误。
- 记录路由（Record Router）：当数据包离开时为每台路由器提供空间记录数据包的出站接口地址。
- 时间戳（timestamp）：时间戳相当于路由记录选项，这样数据包不仅可以知道自己到过那里。而且还可以记录到达的时间。
- 填充（Padding，长度可变）：通过在可选字段后面添加0来补足32位，为了确保报头长度是32的倍数。
5. MAC
5.1 MAC/以太网V2标准MAC帧结构
- 前同步码
- 说明：802.3协议的帧的第一个字段
- 作用：提醒接收系统有帧到来,使帧与输入定时同步，由物理层添加进MAC帧
- 长度：7个字节,56比特
- 内容：交替出现的0和1
- 帧首定界符SFD
- 作用：作为帧开始的信号，SFD提醒接收站，这是最后一次进行同步的机会，最后两个比特提醒接收方，接下来的字段是目的地址，由物理层加入帧
- 长度：1个字节
- 内容：10101011
- DA：目的MAC地址
- 内容：接收方的物理地址
- 长度：6个字节
- 补充：一个MAC帧的源地址只能是单播地址，任何一个帧只可能来自一个站点，目的地址有可能是单播地址、多播地址、广播地址
- SA：源MAC地址
- 内容：发送方的物理地址
- 长度：6个字节
- 长度或类型：
- 作用：以太网V2标准将此字段用作类型字段，定义使用改MAC帧的上层协议。IEEE标准定义为长度字段，用来指明在数据字段中包含的字节数目
- 长度：2个字节
- 数据域：
- 长度：46~1500字节
- FCS：帧检验序列(使用CRC检验)
- 内容：差错检验信息，检验范围不包括前同步码和帧前定界符
- 作用：差错校验
- 长度：4个字节
注：
(1) 数据域限制最小长度46字节是为了CSMA/CD。
最小数据帧的设计原因和以太网电缆长度有关，为的是让两个相距最远的站点能够感知到双方的数据发生了碰撞；最远两端数据的往返时间就是争用期，以太网的争用期是51.2us（传输512bit time，位时），正好发送64byte数据。
(2) 什么以太网的争用期是51.2us
在极限条件下，一个局域网中两个收发器间（允许接4个中继器）的最大距离为2500m，往返5000m，同轴电缆的时延特性为5us/km，即如遇冲突，端到端往返时延为25us。然而这是理想的时延，考虑到中继器的额外时延，最坏情况下取估计时延为45us，再加上强化冲突需发送48bit，接受方要接受到48bit后才确认冲突，即在增加4.8us，共49.8us，所以通常以太网取51.2us为争用期的时间长度(传输512bit，即64字节时间)，即帧的长度至少为64字节。
Acknowledgements：
http://blog.chinaunix.net/uid-23215128-id-2521326.html
http://www.360doc.com/content/17/0423/16/42247516_647893783.shtml
http://www.cnblogs.com/xinyuyuanm/archive/2013/04/17/3026279.html
http://www.360doc.com/content/12/1218/10/3405077_254722699.shtml
http://www.cnblogs.com/shuiyonglewodezzzzz/p/6216510.html
http://www.cnblogs.com/demonxian3/p/6259755.html
2017.04.23