车载以太网之 DHCP协议「建议收藏」
大家好，又见面了，我是你们的朋友全栈君。
车载以太网与传统以太网的主要区别在于二者的物理层，前者的物理层采用一对双绞线的100BASE-T1，而后者的物理层采用两对双绞线的方式，比如100BASE-TX。而二层以上的协议栈，车载网络则基本借鉴传统网络，区别并不大。
下图是基于车载以太网的车载网络所使用的各种通信协议，在这篇文章中我将简要介绍一下位于7层上的DHCP协议。
车载以太网涉包含的各种协议
DHCP的全称是Dynamic Host Configuration Protocol，翻译作动态主机配置协议。它的用途是为网络节点自动配置IP地址。DHCP协议已经在传统网络中应用得非常成熟，但是我们汽车行业的工程师以前可能并不太关注这种协议，所以我把自己的总结跟同行们也分享一下。
WIN10中对IP进行设置的界面
当我们的网络设备（比如笔记本、平板、手机）进入公共网络或者家庭网络中时，我们很少需要对设备的IP地址进行配置，这是因为我们的这些设备的IP设置都选择了以DHCP协议自动配置IP地址的方式。该协议使得我们免去配置IP地址的麻烦。
DHCP是一个局域网应用层协议，使用UDP协议工作，用于在局域网内自动分配IP地址。
该协议基于Client / Server模式工作（Server一般由路由器担任），
•DHCP Server端，使用UDP端口：67 (0x43)
•DHCP Client端，使用UDP端口：68 (0x44)
基于Client / Server模式工作的DHCP协议
DHCP的三种机制分配IP地址：
1)自动分配方式（Automatic Allocation），DHCP服务器为客户端指定一个永久性的IP地址，一旦DHCP客户端第一次成功从DHCP服务器端租用到IP地址后，就可以永久性的使用该地址。
2)动态分配方式（Dynamic Allocation），DHCP服务器给客户端指定一个具有时间限制的IP地址，时间到期或主机明确表示放弃该地址时，该地址可以被其他主机使用。
3)手工分配方式（Manual Allocation），客户端的IP地址是由网络管理员指定的，DHCP服务器只是将指定的IP地址告诉客户端主机。
其中我们最常使用的是第二种，即动态分配方式。
上面提到，DHCP基于UDP协议工作，DHCP在封装到UDP包之前的格式如下图所示：
DHCP数据格式（图片来源于网络）
各个字段的含义和如途介绍如下：
OP：
若是 client 送给 server 的封包，设为 1 ，反向为 2。
HTYPE：
硬件类别，Ethernet 为 1。
HLEN：
硬件地址长度，ethernet为6。
HOPS:
若封包需经过 router 传送，每站加 1 ，若在同一网内，为 0。
SECONDS:
Client 端启动时间（秒）。
Transaction ID：
一个随机数，用于客户和服务器之间匹配请求和相应消息。
Flags：
从0-15bits，最左一bit为1时表示server将以广播方式传送封包给 client，其余尚未使用。
ciaddr:
要是 client 端想继续使用之前取得之 IP 地址，则列于这里。
yiaddr:
在 server 送回 client 的 DHCP OFFER 与 DHCPACK封包中，此栏填写分配给 client 的 IP 地址。
siaddr:
若 client 需要通过网络开机，从 server 送出之 DHCP OFFER、DHCPACK、DHCPNACK封包中，此栏填写开机程序代码所在 server 之地址。
giaddr：
若需跨网域进行 DHCP 发放，此栏为 relay agent 的地址，否则为 0。
chaddr：
Client 之硬件地址。（包括6字节MAC和10字节padding）
sname:
Server 之名称字符串，以 0x00 结尾。
file:
若 client 需要通过过网络开机，此栏将指出开机程序名称，稍后以 TFTP 传送。
options：
允许厂商定议选项。每个option项由Type（1字节）、Length（1字节）、Value（长度由Length决定）三部分组成。在https://blog.csdn.net/hansel/article/details/7754606 这个链接中，有所有option的定义。当当option TYPE等于35时，该option用于描述DHCP Message type。
options字段举例
当option TYPE等于35时，用于描述DHCP Message type的定义
DHCP协议通信过程（图片来源于网络）
上图描述了DHCP协议自动配置地址的过程，我在下面简要描述一下这4个步骤。
第一步： DHCP客户端主动发送DHCP Discover包，用来寻找DHCP服务器，其中：
源MAC是自己的MAC地址，目的MAC是FF:FF:FF:FF:FF:FF的广播；
源IP是0.0.0.0（现在还没有IP，就用全0地址），目的IP是255.255.255.255的三层广播地址。
因为此时客户端还不知道DHCP服务器在哪里，所以使用广播来寻找，请求会被广播到整个网段中。
第二步：
DHCP服务器收到客户端发的DHCP Discover之后，会在自己的地址池中拿出一个没有分配的地址以及配套的参数（如：掩码、DNS、网关、域名、租期……），然后以一个DHCP Offer包发送出去。这个DHCP Offer数据包的地址如下：
源MAC是DHCP服务器的MAC，目的MAC是DHCP客户端的MAC地址；
源IP是DHCP服务器的IP，目的IP是即将分配给客户端使用的IP地址。
因为客户端目前还没有IP地址，所以在这个单播IP发送之前，服务器会使用客户端的MAC地址与之通信，如果MAC地址通信失败，那么服务器会使用广播的方式提供（Offer）数据包 。
第三步：
客户端收到这个DHCP Offer后，会再发出一个DHCP Request给服务器来申请这个Offer中包含的地址。此时客户端还没有正式拿到地址，所以还需要向DHCP服务器申请。
这个DHCP Request数据包的地址如下：
这时客户端的源IP还是0.0.0.0，目的IP还是255.255.255.255
源MAC是客户端的MAC，目的MAC是FFFF.FFFF.FFFF广播包
第四步：
服务器收到客户端的请求后，会发出一个DHCP ACK用来确认这个IP地址可以分配给这个客户端。
客户端收到这个DHCP ACK数据包才算正式拿到了这个IP。
关于DHCP租约内续租：
DHCP服务器向DHCP客户机出租的IP地址有一个租借期限，期满后DHCP服务器便会收回出租的IP地址。如果DHCP客户端要延长其IP租约，则必须更新其IP租约。IP租约期限过一半时，DHCP客户机都会自动向DHCP服务器发送更新其IP租约的信息。
在租约内续租的时候，发现（ Discovery ）和提供（Offer）数据包就变得没有必要了，只需要完成请求和确认两个步骤就可以。
下图是我截取的这4个步骤的报文，由于trace内容太多，不方便粘贴，我只截取了关键信息来说明这几个步骤。第一列是时间戳，第二列是协议，第三列和第四列分别是源IP和目的IP，第五列和第六列分别是源端口和目的端口（这里的44和43是十六进制，换算为十进制就是我们前面提到的68和67），第七列是消息类型。其中192.168.1.2是DHCP server的IP地址，192.168.1.100是这个server要为这个发起请求的client分配的地址，从offer报文展开的详细内容也可以看出来这一点。
Discovery
Offer
Request
ACK
offer报文展开
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/142584.html原文链接：https://javaforall.cn