以太网协议封装格式
一、以太网链路层协议封装格式
以太网数据在网络介质上传输需要遵循一定的机制，其中CSMA/CD介质访问控制机制约定了以太网在传输数据时，两帧之间需要等待一个帧间隙时间（IFG或IPG），为以太网接口提供了帧接收之间的恢复时间，该恢复时间最小值为传输96bit所花费的时间，对于10M线路，该时间为9.6uS，100M线路为960nS，1G的线路为96nS。同时以太网数据帧在传输时还需要有7byte的前导字段和1byte的定界符。因此以太网数据在传输过程中是由以下部分组成的：7byte（前导）＋1byte（定界符）＋以太网数据帧＋12byte（IPG）。
在全双工工作模式下，如果CSMA/CD介质访问控制机制发现传输冲突时，则会放弃当前帧发送，改为发送一个48比特的噪声帧。
其中以太网数据帧限制为最小长度为64byte，最大长度为1518byte，其格式为：6byte（目的MAC地址）＋6byte（源MAC地址）＋2byte（类型字段）＋数据字段＋4byte（FCS校验字段）。其中帧类型字段标识其后的数据类型。
这里值得注意的是区分Ethernet II帧格式和802.3帧格式的不同，我们有时可能会混用了这两个术语。
Ethernet II帧是最常见的一种以太网帧格式，也是今天以太网的事实标准，由DEC，Intel和Xerox在1982年公布标准，Ethernet II可以支持TCP/IP，Novell IPX/SPX，Apple Talk Phase I等协议，其比较常见的类型字段为：0X0800（IP帧），0X0806（ARP请求/应答帧），0X8035（PARP请求/应答帧），0X8137（Novell IPX），0X809b（Apple Talk）。RFC 894定义了IP报文在Ethernet II上的封装格式。
802.3帧将Ethernet II帧头中的类型字段替换为帧长度字段（取值范围为0X0000-0X05dc，不包括CRC检验码），因此对于接收到的帧，如果类型字段取值范围为0X0000－0X05dc，则可以判断其为802.3帧，而非Ethernet II帧。其中RAW 802.3是1983年Novell发布Netware/86网络套件时采用的私有以太网帧格式，只支持IPX/SPX一种协议；802.3/802.2 LLC是IEEE 公布的正式802.3标准，它加入了3byte的LLC字段， 其中SAP值用以标志上层应用，每个SAP字段为8bits，其中只有6bit用于标识上层协议，因此所能标识的协议数不超过32种，导致802.3/802.2 LLC的使用有很大局限性；802.3/802.2 SNAP是IEEE为保证在802.2 LLC上支持更多的上层协议同时更好的支持IP协议而发布的标准，在802.3/802.2 LLC基础上添加了5byte的SNAP字段，从而使其可以标识更多的上层协议类型，OUI字段用于代表不同的组织（一般置为0），在802.3/802.2 SNAP基础上RFC1042定义了IP报文在802.2网络中的封装方法和ARP协议在802.2 SANP中的实现。
目前实际环境中大多数TCP/IP设备都使用Ethernet II格式的帧，它采用了RFC 894的实现标准。从上述帧格式中可以看出，Ethernet II格式帧数据段的长度限制在46byte－1500byte之间，当数据段长度小于46个字节时，加填充字段（PAD）补足。Ethernet II和802.3对数据帧的长度限制，其最大值分别是1500和1492字节，这一特性称作最大传输单元（MTU）。
二、以太网IP层协议封装格式
在TCP/IP协议族中基于链路层以上的协议主要有三种：IP协议、ARP协议和RARP协议，其中在IP数据报中又额外封装了ICMP协议和IGMP协议。IP层协议也就是通常的网络层协议，它提供点到点的服务（不同于传输层TCP/UDP协议提供端到端的服务）。
IP包封装格式
版本号：IP包的版本，当前一般为IPv4，即0100。
首部长度：IP包头长度（Internet Header Length，IHL），是一个4bit字段，是头部占32比特的数字，包括可选项。普通IP数据报（没有任何选项），该字段的值是5，即160比特=20字节。此字段最大值为60字节，表示头部报文中没有发送可选部分数据。
服务类型（TOS）：其中前3比特为优先权子字段（Precedence，现已被忽略）。第8比特保留未用。第4至第7比特分别代表延迟、吞吐量、可靠性和花费。当它们取值为1时分别代表要求最小时延、最大吞吐量、最高可靠性和最小费用。这4比特的服务类型中只能置其中1比特为1。可以全为0，若全为0则表示一般服务。服务类型字段声明了数据报被网络系统传输时可以被怎样处理。例如：TELNET协议可能要求有最小的延迟，FTP协议（数据）可能要求有最大吞吐量，SNMP协议可能要求有最高可靠性，NNTP（Network News Transfer Protocol，网络新闻传输协议）可能要求最小费用，而ICMP协议可能无特殊要求（4比特全为0）。实际上，大部分主机会忽略这个字段，但一些动态路由协议如OSPF（Open Shortest Path First Protocol）、IS-IS（Intermediate System to Intermediate System Protocol）可以根据这些字段的值进行路由决策。
总长度：头部及数据项长度，最大长度为65535bytes。
标识：当IP包较大需要进行分段时，用于标识该段所属的分组。通常每发一份报文，它的值会加1。
标志：构成为[0][D][M]，其中D为1表示不分段，M为0表示为最后分段，为1表示非最后分段。
片偏移：即分段偏移。如果一份数据报要求分段的话，此字段指明该段偏移距原始数据报开始的位置。
生存时间（TTL）：表示一个IP数据流的生命周期，由发送数据的源主机设置，通常为32、64、128等。每次IP数据包经过一个路由器的时候TTL就减一，当减到0时，这个数据包就消亡了。
协议：传输层的协议类型。
| 协议代码 |
协 议 名 称 |
| 1 |
ICMP (Internet Control Message Protocol) |
| 2 |
IGMP (Internet Group Management Protocol) |
| 3 |
GGP (Gateway-to-Gateway Protocol) |
| 4 |
IP (IP in IP encapsulation) |
| 6 |
TCP (Transmission Control Protocol) |
| 8 |
EGP (Exterior Gateway Protocol) |
| 17 |
UDP (User Datagram Protocol |
首部校验和：根据IP头部计算得到的校验和码。计算方法是：对头部中每个16比特进行二进制反码求和。（和ICMP、IGMP、TCP、UDP不同，IP不对头部后的数据进行校验）。
选项：占32比特。用来定义一些任选项：如记录路径、时间戳等。这些选项很少被使用，同时并不是所有主机和路由器都支持这些选项。可选项字段的长度必须是32比特的整数倍，如果不足，必须填充0以达到此长度要求。
数据：IP包携带的各种传输层报文。
IP报文头部实例：45 00 00 30 52 52 40 00 80 06 2c 23 c0 a8 01 01 d8 03 e2 15
[经验之谈] 由于IP长度字段有16比特，所以IP数据报最长可以达到65535字节，但是大多的数据链路层会对它进行分段,而且主机也要求不能接收超过576字节的数据报。由于TCP把用户数据分成若干段，因此一般来说这个限制不会影响TCP。udp的应用（如TFTP、DNS、SNMP等）都限制用户数据报长度为512字节，小于576字节。但是，事实上现在大多数的实现允许超过8192字节的IP数据报。
总长度字段是IP首部必须的内容，因为一些数据链路需要填充一些数据以达到最小长度，尽管以太网最小帧为46个字节，但是IP数据可能会更短，如果没有总长度字段，那么IP层就不知道46字节中有多少是IP数据报的内容。
三、传输层协议封装格式
1．TCP协议
TCP是一种可靠的、面向连接的字节流服务。源主机在传送数据前需要先和目标主机建立连接。然后，在此连接上，被编号的数据段按序收发。同时，要求对每个数据段进行确认，保证了可靠性。如果在指定的时间内没有收到目标主机对所发数据段的确认，源主机将再次发送该数据段。
源、目标端口号字段：占16比特。TCP协议通过使用"端口"来标识源端和目标端的应用进程。端口号可以使用0到65535之间的任何数字。在收到服务请求时，操作系统动态地为客户端的应用程序分配端口号。在服务器端，每种服务在"众所周知的端口"（Well-Know Port）为用户提供服务。
顺序号字段：占32比特。用来标识从TCP源端向TCP目标端发送的数据字节流，它表示在这个报文段中的第一个数据字节。
确认号字段：占32比特。只有ACK标志为1时，确认号字段才有效。它包含目标端所期望收到源端的下一个数据字节。
数据偏移量：实际上是TCP首部长度，用来标识数据段的起始位置。给出头部占32比特的数目。没有任何选项字段的TCP头部长度为20字节；最多可以有60字节的TCP头部。
控制标识（U、A、P、R、S、F）：：TCP协议中的六个重要的标志。是两个计算机数据交流的信息标志。接收和发送断根据这些标志来确定信息流的种类。
URG：（Urgent Pointer field significant）紧急指针。用到的时候值为1，用来处理避免TCP数据流中断。
ACK：（Acknowledgment fieldsignificant）置1时表示确认号（AcknowledgmentNumber）为合法，为0的时候表示数据段不包含确认信息，确认号被忽略。
PSH：（Push Function），PUSH标志的数据，置1时请求的数据段在接收方得到后就可直接送到应用程序，而不必等到缓冲区满时才传送。
RST：（Reset the connection）用于复位因某种原因引起出现的错误连接，也用来拒绝非法数据和请求。如果接收到RST位时候，通常发生了某些错误。
SYN：（Synchronize sequence numbers）用来建立连接，在连接请求中，SYN=1，ACK=0，连接响应时，SYN=1，ACK=1。即，SYN和ACK来区分Connection Request和Connection Accepted。
FIN：（No more data from sender）用来释放连接，表明发送方已经没有数据发送了。
滑动窗口：控制报文流量，用来告诉对方目前接收端缓冲器大小。当为0时标识缓冲器已满，需要停止发包，单位为byte。
TCP校验和字段：占16比特。对整个TCP报文段，即TCP头部和TCP数据进行校验和计算，并由目标端进行验证。
紧急指针字段：占16比特。它是一个偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。
选项字段：占32比特。可能包括"窗口扩大因子"、"时间戳"等选项。
TCP协议头部实例：0d 28 00 15 50 5f a9 06 00 00 00 00 70 02 40 00 c0 29 00 00
TCP建立连接的三次握手过程
TCP会话通过三次握手来初始化。三次握手的目标是使数据段的发送和接收同步。同时也向其他主机表明其一次可接收的数据量（窗口大小），并建立逻辑连接。这三次握手的过程可以简述如下：
1、源主机发送一个同步标志位（SYN）置1的TCP数据段。此段中同时标明初始序号（Initial Sequence Number，ISN）。ISN是一个随时间变化的随机值。
2、目标主机发回确认数据段，此段中的同步标志位（SYN）同样被置1，且确认标志位（ACK）也置1，同时在确认序号字段表明目标主机期待收到源主机下一个数据段的序号（即表明前一个数据段已收到并且没有错误）。此外，此段中还包含目标主机的段初始序号。
3、源主机再回送一个数据段，ACK=1，同样带有递增的发送序号和确认序号。
至此为止，TCP会话的三次握手完成。接下来，源主机和目标主机可以互相收发数据。
建立一个连接需要三次握手，而终止一个连接要经过4次握手。这由T C P的半关闭（h a l f -c l o s e）造成的。既然一个T C P连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。这原则就是当一方完成它的数据发送任务后就能发送一个F I N来终止这个方向连接。当一端收到一个F I N，它必须通知应用层另一端几经终止了那个方向的数据传送。发送F I N通常是应用层进行关闭的结果。
2．UDP协议
UDP是一种不可靠的、无连接的数据报服务。源主机在传送数据前不需要和目标主机建立连接。数据被冠以源、目标端口号等UDP报头字段后直接发往目的主机。这时，每个数据段的可靠性依靠上层协议来保证。在传送数据较少、较小的情况下，UDP比TCP更加高效。
UDP包封装格式
源、目标端口号字段：16比特。作用与TCP数据段中的端口号字段相同，用来标识源端和目标端的应用进程。
长度字段：占16比特。标明UDP头部和UDP数据的总长度字节。
校验和字段：占16比特。用来对UDP头部和UDP数据进行校验。和TCP不同的是，对UDP来说，此字段是可选项，而TCP数据段中的校验和字段是必须有的。
最大UDP数据报长度
我们将遇到两个限制因素。第一，应用程序可能会受到其程序接口的限制。socket API提供了一个可供应用程序调用的函数，以设置接收和发送缓存的长度。 对于UDP socket，这个长度与应用程序可以读写的最大UDP数据报的长度直接相关。现在的大部分系统都默认提供了可读写大于8192字节的UDP数据报（使用这个默认值是因为8192是NFS读写用户数据数的默认值）。
第二个限制来自于TCP/IP的内核实现。可能存在一些实现特性（或差错），使IP数据报长度小于65535字节。
作者使用sock程序对不同UDP数据报长度进行了试验。在SunOS 4.1.3下使用环回接口的最大IP数据报长度是3276 7字节。比它大的值都会发生差错。但是从BSD/386到SunOS 4.1.3的情况下，Sun所能接收到最大IP数据报长度为32786字节（即32758字节用户数据）。在Solaris 2.2下使用环回接口，最大可收发IP数据报长度为65535字节。从Solaris 2.2到AIX 3.2.2，发送的最大IP数据报长度可以是65535字节。很显然，这个限制与源端和目的端的实现有关。
我们在3.2节中提过，要求主机必须能够接收最短为576字节的IP数据报。在许多UDP应用程序的设计中，其应用程序数据被限制成512字节或更小，因此比这个限制值小。例如，我们在10.4节中看到，路径信息协议总是发送每份数据报小于512字节的数据。我们还会在其他UDP应用程序如DNS（第14章）、TFTP（第15章）、BOOTP（第16章）以及SNMP（第25章）中遇到这个限制。
数据报截断
由于IP能够发送或接收特定长度的数据报并不意味着接收应用程序可以读取该长度的数据。因此， UDP编程接口允许应用程序指定每次返回的最大字节数。如果接收到的数据报长度大于应用程序所能处理的长度，那么会发生什么情况呢？
不幸的是，该问题的答案取决于编程接口和实现。
典型的Berkeley版socket API对数据报进行截断，并丢弃任何多余的数据。应用程序何时能够知道，则与版本有关（4.3BSD Reno及其后的版本可以通知应用程序数据报被截断）。
SVR4下的socket API(包括Solaris 2.x) 并不截断数据报。超出部分数据在后面的读取中返回。它也不通知应用程序从单个UDP数据报中多次进行读取操作。
TLI API不丢弃数据。相反，它返回一个标志表明可以获得更多的数据，而应用程序后面的读操作将返回数据报的其余部分。
在讨论TCP时，我们发现它为应用程序提供连续的字节流，而没有任何信息边界。TCP以应用程序读操作时所要求的长度来传送数据，因此，在这个接口下，不会发生数据丢失。