以太网和IEEE 802帧:
帧的目的地址和源地址都是硬件地址(长度为6字节，即48bit)
之后802定义的是后续数据的字节长度，以太网定义的是后续数据的类型（802后面定义了类型，而以太网没有定义长度），这一段可区分出两种帧，因为802定义的有效长度值与以太网的有效类型值无一相同。
之后802经过了LLC和SNAP才到达数据部分，而以太网直接到达了数据部分，由于ARP和RARP协议对32 bit的IP地址和48 bit的硬件地址进行映射，因为数据部分是ARP数据，ARP数据最大长度是28字节,而802数据至少38字节，以太网数据至少46字节，因此在不足的空间用PAD补足。
最后的CRC字段是检验和。
SLIP全称Serial Line IP，是一种在串行线路上对IP数据报进行封装的简单形式，下图是它的帧格式:
帧以特殊字符END(0xc0)开始和结束，结束的END标明帧结束，开始的END作用是如果有线路噪声，那么END将结束这份错误的报文，这样当前的报文得以正确地传输，而前一个错误报文交给上层后，会发现其内容毫无意义而被丢弃。
如果IP报文中有END字符，会连续传输两个字节0xdb和0xdc取代
0xdb被称作SLIP的ESC字符，如果IP报文中有这个字符，会连续传输两个字节0xdb和0xdd取代
这种帧的缺陷:
1.每一端必须知道对方的IP地址，没有办法把本端的IP地址通知给另一端。
2.数据帧中没有类型字段（类似于以太网中的类型字段），这意味着如果一条串行线路用于SLIP，那么它只能用IP协议。
3.数据帧中没有检验和。
因为串行线路的速率通常较低，而且通信经常是交互式的，所以在SLIP线路上会产生许多小的TCP分组(packets)进行交换，为了传送1个字节的数据需要20个字节的IP首部和20个字节的TCP首部，总数超过40个字节。为了弥补这个缺陷产生了CSLIP协议(即压缩的SLIP)
PPP(Point-to-Point)协议修改了SLIP协议中的所有缺陷，帧格式:
PPP包括三个部分:
1.将IP数据报封装到串行链路的方法。
2. 建立、配置和测试数据链路连接的链路控制协议LCP(Link Control Protoco1)。
3. 针对不同网络层协议的网络控制协议族 NCPs (Network Control Protoco1s)。
帧以标志字符0x7e开始和结束，协议字段类似于以太网中类型字段的功能，通过协议字段确定其后是什么数据。帧中有些字符需要转义，同步链路通过硬件技术完成，异步链路将0x7d用作转义字符，紧接着的字符的第6个比特要取其补码，例如:
1. 遇到0x7e，需用两个字符： 0x7d和0x5e转义。
2. 遇到0x7d，需用两个字符： 0x7d和0x5d转义。
3. 默认情况下，如果字符的值小于0x20(16进制20前对应的ASCII都是特殊字符)，一般都要进行转义,原因是它们会被解释成特殊的含义,用链路控制协议可以指定是否需要对这32个字符中的某一些值进行转义。
与SLIP类似，PPP经常用于低速的串行链路，因此减少每一帧的字节数可以降低应用程序的交互时延。这时就可以看出 LCP和 NCP的作用:
利用LCP,大多数的产品通过协商可以省略标志符和地址字段，并且把协议字段由2个字节减少到1个字节。
利用NCP,大多数的产品通过协商可以采用Van Jacobson报文首部压缩方法(和CSLIP一样),减小IP和TCP首部长度。
环回接口（ Loopback Interface），允许运行在同一台主机上的客户程序和服务器程序通过TCP/IP进行通信。大多数系统把IP地址127.0.0.1分配给这个接口，并命名为localhost。环回接口处理IP数据包如下图:
IP输出分两种，一种传到环回接口(目的是127.0.0.1,环回接口可以被看作是网络层下面的另一个链路层)，一种传到以太网接口，传到以太网接口的数据报还要判断如果是广播或多播则复制一份数据报传到环回接口(广播或多播包括本身)，如果目的IP就是本机则把数据报传到环回接口。传给环回接口的数据均作为IP输入。
链路层对数据帧长度都有限制，这个限制称作MTU(最大传输单元)，如果IP层传给链路层的数据报长度比链路层的MTU大，那么IP层就需要进行分片（fragmentation），使每一片都小于MTU。下图列出了一些典型的MTU值:
其中点到点的链路层（如SLIP和PPP）的MTU并非指的是网络媒体的物理特性。相反，它是一个逻辑限制，目的是为交互应用提供足够快的响应时间。
当在同一个网络上的两台主机互相通信时，该网络的MTU是非常重要的。但是如果两台主机之间的通信要通过多个网络，那么重要的就不是两台主机所在网络的MTU的值，而是两台通信主机路径中的最小MTU，称作路径MTU。路径MTU的值取决于当时所选择的路由。而选路不一定是对称的（从A到B的路由可能与从B到A的路由不同），因此路径MTU在两个方向上不一定是一致的。
前面提到了串行线的MTU是一个逻辑限制，下面举个例子讨论一下这个问题。
如果线路速率是9600b/s，而一个字节有8bit，加上一个起始比特和一个停止比特，以这个速率一次传输一个1024字节(一次传输1024字节，意味着MTU最少是这个值)的包需要1066ms。如果用SLIP链接运行一个交互式应用程序，同时还运行另一个应用程序如FTP发送或接收1024字节的数据，那么一般来说就必须等待一半的时间（533 ms）才能把交互式应用程序的分组数据发送出去。
对于交互应用来说，等待533ms是不能接受的。交互响应时间超过100～200ms就被认为是不好的。这是发送一份交互报文出去后，直到接收到响应信息（通常是出现一个回显字符）为止的往返时间。为了解决这个问题，我们把SLIP的MTU缩短到256，这样传输一帧最长需要266ms ，需要等待133ms，如果将MTU缩到更短(64或128)虽然能提供更快的响应时间，但是不能为大块数据提供良好的线路利用率，降低传输大块数据的
最大吞吐量，因此在这二者之间要权衡，所以才说串行线的MTU是一个逻辑限制。
点对点链路的MTU是296个字节。假设数据为256字节，TCP和IP首部占4 0个字节。由于MTU是IP向链路层查询的结果，因此该值必须包括通常的TCP和IP首部。这样就会导致IP分片，因为IP对于CSLIP的压缩情况一无所知。
上面提到的平均等待时间是传输最大数据帧所需时间的一半这个法则只适用于交互通信和大块数据传输都在使用SLIP或PPP的情况下。当只有交互通信时，如果线路速率是9600b/s，那么任何方向上的1字节数据（假设有5个字节的压缩帧头）往返一次都大约需要12.5 ms((1+5)*10/9600*2*1000)。它比前面提到的100~200ms要小得多。需要注意的是，由于帧头从40个字节压缩到5个字节，使得1字节数据往返时间从85 ms((1+40)*10/9600*2*1000) 减到12.5 ms。
