网络引导技术PXE浅析

所谓网络引导，指的是在服务器端的协助下，客户机在启动的过程中，通过在网络端口接收指令和数据的方式来完成机器启动的引导过程。

网络引导技术的作用在于，相关通过网络启动方式启动的节点可以依据服务器端节点的参数完成机器的启动过程，而不受本地外设相关数据和参数的影响。网络引导技术的引入，大大降低了集群系统的维护成本。

目前，PXE凭借其低廉的实现成本及其易用性，成为应用最为广泛的网络引导技术。

1        PXE技术简介

PXE(Preboot eXecute Environment)是由Intel公司开发的最新技术，工作于Client/Server的网络模式，支持工作站通过网络从远端服务器下载映像，并由此支持来自网络的操作系统的启动过程，其启动过程中，终端要求服务器分配IP地址，再用TFTP（Trivial File Transfer Protocol）或MTFTP(Multicast Trivial File Transfer Protocol)协议下载一个启动软件包到本机内存中并执行，由这个启动软件包完成终端基本软件设置，从而引导预先安装在服务器中的终端操作系统。 PXE可以引导多种操作系统，如：Windows 95/98/2000,Linux等。

PXE技术的实现要求三个模块的协同运作，分别是带有PXE支持的DHCP(Dynamic Host Configuration Protocol)服务器、M/TFTP (Multicast / Trivial File Transfer Protocol)服务器以及网络引导程序。带有PXE扩展支持的DHCP服务器用于为客户端分配IP，以及为客户端指明引导服务器的地址。M/TFTP在整个引导流程中担当了引导服务器(Boot Server)的角色，用于存放引导程序以及其它在客户端启动时所要用到的文件。而网络引导程序，则用于完成客户端机器的引导工作。

2        DHCP服务器

DHCP协议为因特网客户机提供了配置参数。DHCP包括了两个组件：一个从DHCP服务器往客户机发送特定客户端配置参数的协议，一个为客户机分配网络地址的机制。

DHCP基于C/S模型，服务器端分配网络地址并传送配置参数至动态配置的客户机。客户机通过服务器得到IP的过程如下：

1)      若客户机设置使用DHCP协议取得网络参数，则客户机在开机时或重新启动网卡时，会自动发出DHCP Client的请求给网段内的每台计算机：这时，由于发出的信息希望每台计算机都可以接受，所以该信息除了网卡的硬件地址(MAC)外，还要将该信息的来源软件地址设置为0.0.0.0，而目的地址则为255.255.255.255。这时，网段内的其他没有提供DHCP服务的计算机，受到这个数据包之后会自动将该数据包丢弃而不回应。

2)      DHCP主机响应信息：如果是DHCP主机收到这个客户机的DHCP请求，那么DHCP主机首先会针对该次请求的信息所携带的MAC与DHCP主机本身的设置值进行对比，如果DHCP主机的设置中有针对该MAC提供的静态IP（每次都给予一个固定IP），则提供给客户端相关的固定IP与相关的网络参数；如果该信息的MAC并不在DHCP主机的设置中，则DHCP主机会选取当前网段内没有使用的IP（这个IP与设置值有关）将其发放给客户使用。此外，在DHCP主机发放给客户端的信息中，会附带一个“租约期限”信息，告诉客户端这个IP可以使用的期限。

3)      客户端接受来自DHCP主机的网络参数，并设置客户机自己的网络环境：当客户端接收到响应信息之后，首先会以ARP数据包在网段内发出信息，以确定来自DHCP主机发放的IP没有被占用。如果该IP已经被占用，那么客户机对于这次的DHCP信息将不接受，而将再次向网段内发出DHCP的请求广播数据包；若该IP没有被占用，则客户机可以接受DHCP主机所给的网络参数，那么这些参数将被用于客户端的网络设置中，同时客户端也会对DHCP主机发出确认数据包，告诉服务器这次的请求已经确认，而服务器也会将该信息记录下来；

4)      客户端结束该IP的使用权：当客户端开始使用这个DHCP发放的IP之后，在下面几种情况下，他可能失去这个IP的使用权：

·　客户端的离线：关闭网络接口、重启计算机、关机等行为，都算是离线状态，这时服务器端将该IP回收，并放到Server自己的备用区中，以备将来使用；

·　客户端租约到期：前面提到的DHCP服务器端发放的IP有使用期限，客户机使用这个IP到达期限规定的时间后，需要将IP缴回去。这时就会造成断线，而客户机也可以再向DHCP主机请求再次分配IP。

3        TFTP/MTFTP服务器

TFTP（Trivial File Transfer Protocol,简单文件传输协议）是TCP/IP协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议，提供不复杂、开销不大的文件传输服务。

TFTP是一个传输文件的简单协议，它其于UDP协议而实现，但是我们也不能确定有些TFTP协议是基于其它传输协议完成的。此协议设计的时候是进行小文件传输的。因此它不具备通常的FTP的许多功能，它只能从文件服务器上获得或写入文件，不能列出目录，不进行认证，它传输8位数据。传输中有三种模式：netascii，这是8位的ASCII码形式，另一种是octet，这是8位源数据类型；最后一种mail已经不再支持，它将返回的数据直接返回给用户而不是保存为文件。

任何传输起自一个读取或写入文件的请求，这个请求也是连接请求。如果服务器批准此请求，则服务器打开连接，数据以定长512字节传输。每个数据包包括一块数据，服务器发出下一个数据包以前必须得到客户对上一个数据包的确认。如果一个数据包的大小小于512字节，则表示传输结构。如果数据包在传输过程中丢失，发出方会在超时后重新传输最后一个未被确认的数据包。通信的双方都是数据的发出者与接收者，一方传输数据接收应答，另一方发出应答接收数据。大部分的错误会导致连接中断，错误由一个错误的数据包引起。这个包不会被确认，也不会被重新发送，因此另一方无法接收到。如果错误包丢失，则使用超时机制。错误主要是由下面三种情况引起的：不能满足请求，收到的数据包内容错误，而这种错误不能由延时或重发解释，对需要资源的访问丢失（如硬盘满）。TFTP只在一种情况下不中断连接，这种情况是源端口不正确，在这种情况下，指示错误的包会被发送到源机。这个协议限制很多，这是都是为了实现起来比较方便而进行的。

初始连接时候需要发出WRQ（请求写入远程系统）或RRQ（请求读取远程系统），收到一个确定应答，一个确定可以写出的包或应该读取的第一块数据。通常确认包包括要确认的包的包号，每个数据包都与一个块号相对应，块号从1开始而且是连续的。因此对于写入请求的确定是一个比较特殊的情况，因此它的包的包号是0。如果收到的包是一个错误的包，则这个请求被拒绝。创建连接时，通信双方随机选择一个TID，因此是随机选择的，因此两次选择同一个ID的可能性就很小了。每个包包括两个TID，发送者ID和接收者ID。这些ID用于在UDP通信时选择端口，请求主机选择ID的方法上面已经说过了，在第一次请求的时候它 会将请求发到TID 69，也就是服务器的69端口上。应答时，服务器使用一个选择好的TID作为源TID，并用上一个包中的TID作为目的ID进行发送。这两个被选择的ID 在随后的通信中会被一直使用。下例是一个写入的例子，其中WRQ，ACK和DATA代表写入请求，确认和数据。

1)      主机A向主机B发出WRQ，其中端口为69

2)      B机向A机发出ACK，块号为0，包括B和A的TID

此时连接建立，第一个数据包以序列号1从主机开始发出。以后两台主机要保证以开始时确定的TID进行通信。如果源ID与原来确定的ID不一样，这个包会被认识为发送到了错误的地址而被抛弃。错误的包是被发送到正确端口的，但是包本身有错误。设想发送方发出一个请求，这个请求在网络的那个设备中被复制成两个包，接收方先后接收到两个包。接收方会认为为这是两个独立的请求，会返回两个应答。当这两个应答其中之一被接收到时，连接已经建立。第二个应答再到达时， 这个包会被抛弃，而不会因为接收到第二个应答包而导致第一个建立的连接失败。

传输的结束由DATA数据标记，其包括0-511个字符。这个包可以被其它数据包确认。接收方在发出对最后数据包的确认后可以断开连接，当然，适当的等待是比较好的，如果最后的确定包丢失可以再次传输。如果发出确认后仍然收到最后数据包，可以确定最后的确认丢失。发送最后一个DATA包的主机必须等待对此包的确认或超时。如果响应是ACK，传输完成。如果发送方超时并不准备重新发送并且接收方有问题或网络有问题时，发送也正常结束。当然实现时也可以是非正常结束，但无论如何连接都将被关闭。

如果请求不能被满足，或者在传输中发生错误，需要发送ERROR包。这仅是一种传输友好的方式，这种包不会被确认也不会被重新传输，因此这种包可能永远不会被接收到。因此需要用超时来侦测错误。

因为TFTP没有安全控制机制，因此安全问题应该多加考虑。通常TFTP允许下载数据而不允许上传数据。

MTFTP协议是TFTP协议在多重播送上的一个扩展。

4        PXE技术下网络引导的流程

PXE技术下网络引导的流程如图 1‑1所示。具体步骤如下：

图 1-1 PXE引导流程

第1步：客户端向标准DHCP端口(67)广播DHCPDISCOVER信息。在此包中的选项域中包含以下信息：

·  客户端标识(UUID)标签

·  客户端UNDI版本标签

·  客户端系统体系结构

·  DHCP选项60，类ID，设置至“PXEClient:Arch:xxxxx:UNDI:yyyzzz”

第2步：DHCP或者代理DHCP服务响应，并发送DHCPOFFER消息到客户端的标准DHCP回复端口(68)。如果这是代理DHCP服务，客户段IP地址域为空(0.0.0.0)。如果这是DHCP服务，那么返回的客户端IP地址域是有效的。在这点上，其它DHCP服务和BOOTP服务也以发送至68端口的DHCP offer或BOOTP回复消息响应。每个消息包含标准的DHCP参数：为客户端分配的IP地址，以及任何其它管理员为DHCP或代理DHCP服务指定的参数。DHCP服务器回复的时限是规范的。重广播以接收包含PXE扩展的DHCPOFFER或代理DHCPOFFER的时限，依据于标准DHCP时限，但远短于此，从而允许在并不提供带有PXE扩展DHCPOFFER的标准BOOTP或DHCP环境下客户端合法的操作。

第3步：通过所接收到的DHCPOFFER，客户端记录以下信息：

·  标准DHCP或BOOTP服务所提供的客户端IP地址（以及其它参数）。

·  在DHCPOFFER PXE标签下引导服务器域上的引导服务器列表。

·  发现控制选项(Discovery Control Options)，如果有提供的话。

·  多重发现(Multicast Discovery)IP地址，如果有提供的话。

第4步：如果客户端选择了DHCP服务所分发的IP，那么它必须向服务送回一个地址请求，然后等待来自服务的确认，从而完成标准DHCP协议流程。如果客户端从BOOTP回复中选择IP地址，它可以直接使用该地址。

第5步：客户端选择并发现引导服务器。该包可以通过广播(67端口)、多播(4011端口)或者单播(4011端口)进行发送，具体采用何种方式由包含PXE服务扩展标签的先前的DHCPOFFER内控制选项决定。这个包与第1步中初始DHCPDISCOVER包基本相同，除了它编码为一个DHCPREQUEST，现在包含以下信息：

·  客户端标识(UUID)标签

·  客户端UNDI版本标签

·  客户端系统体系结构

·  DHCP选项60，类ID，设置至“PXEClient:Arch:xxxxx:UNDI:yyyzzz”

·  PXE选项域中引导服务器类型。

第6步：引导服务器往客户端源端口单播DHCPACK包。该回复包包括：

·  引导文件名。

·  MTFTP配置参数。

·  任何其它NBP成功启动之前所必须的参数。

第7步：客户端通过标准TFTP(69端口)或MTFTP(端口由引导服务器ACK包所指定)下载可执行文件。文件的下载以及下载代码在内存中的具体放置由客户端CPU体系结构而定。

第8步：PXE客户端决定是否需要对下载文件进行正确性测试。如果需要该测试，客户端往引导服务器发送另一个DHCPREQUEST消息，请求之前下载引导文件的相应认证文件，通过TFTP或MTFTP下载该认证文件，然后执行正确性测试。

　　第9步：最后，如果正确性测试成功，或者不要求测试，PXE客户端开始运行刚才下载的代码。