tcp-ip协议-3

udp协议：

dhcp,dns,QICQ,TFTP

1:DHCP协议
动态主机配置协议，用于实现终端设备的动态ip信息分布，包括IP地址，网关地址，dns服务器等

DHCP协议处在应用层，进行动态ip信息分布。
基本原理：
pc和server之间将合计发送四个dhcp包，主要过程如下

  1：pc：discover包

  2：server：offer包

  3：pc：request包

  4：server：ack包

通过抓包软件可以清楚的看到分发ip地址以及dns服务器，网关的过程，而这一切，都是通过dhcp协议完成的
如下图所示（值的注意的是，由于缓存等原因，我们通常抓取不到前两个包，但是我们可以解除之前的缓存）：
通过如下指令：ipconfig /release

下面我们简单看一下这些包的结构
1：pc机发送的discover包，包结构如下

可以看到这个discover的包的ip地址是0.0.0.0,这并不奇怪，因为它确实没有ip地址，所以用这种方式发一个广播
通过图二可以看出目标mac地址是255.255.255.255，他发送了一个广播包，因为我们的pc机也不知谁是dhcp服务器
所以干脆全都发送一遍，这个包称之为发现包，即discover包

2：当这个区域内的其中一个dhcp接受到这个特殊的广播包之后，对其进行了反馈，这时候dhcp发送一个offer包
包结构如下：


可以看到这个offer包不但提供了ip地址，在这个包中还提供了dhcp服务器ip，路由服务器ip，以及域名服务器ip

我们还看上面这个包，第二个包我们观察到，这是目标地址就被分配到我们的pc机器上，按道理说。这里我们就可以结束了
这个协议的任务已经完成了，ip地址，dns服务器，以及网关地址都已经分配完成，这个协议的使命不是已经应该完成了？
为什么还会有接下来的两个request包以及ack包呢？

有一个很重要的原因，我们观察到第一步可以知道discover包是通过广播的形式发出去的，当流入到某个网络区域（含有dhcp服务器的环境）
的时候，有多个dhcp服务器接受到了我们pc机器发送的discover包，那么他们在地位上是平等的，所以他们应该是都能返回offer响应包，
这些offer包我们的pc机器应该都能接收到，但是我们的pc机器不能把接受的offer包都使用，而且我们的server机器也不能接受你们脚踏几条船，
所以我们这里需要一个确认机制，一方面是为了确认使用这个dhcp offer，另一方面也让dhcp不认为我们是“渣男”！

3：pc机器发送request包 数据包如下图所示

这里我们发现一个搞笑的现象，通过图二的第三个数据包可以看到，这是pc机器仍然是使用0.0.0.0来发送数据包
而且是通过广播255.255.255.255的广播的形式发送，但是这时我们看图一中的option50 可以看到，这个request
数据包是携带具体的ip地址的。也就是说，这个request包仍然通过广播的方式来寻找已知的这个dhcp服务器，来告诉他
我确定要使用你的offer了！
不过可以理解，毕竟pc和服务器并没有确定关系，所以直接通过指定的方式来寻找是不是显得不太绅士，或者是为了更加安全？
emmmm。。。。。。。

4：当我们的dhcp收到携带着指定ip的request包的以后，出于礼貌就会发送一个和offer大差不差的ack包，如下图

至此：dhcp才完成了他的使命，光荣结束了。
可以看出来：
pc端一直通过广播和使用默认的ip 发送discover 和request数据包到dhcp服务器上，这两个数据包的区别可能
是后者携带option 50 的分配的ip用来与dhcp服务器进行确认
而dhcp服务器通过返回offer和ack的两个相同回应包的方式作为回复，两者都携带了dhcp协议要解决的问题答案！