一、IETF简介
研究网络的人一定要知道IETF这道这个组织，IETF(互联网工程任务组)，成立于1985年底，是全球互联网最具权威的技术标准化组织，主要任务是负责互联网相关技术规范的研发和制定，当前绝大多数国际互联网技术标准出自IETF。
以下内容引自百度百科(特此申明)：
松散的、自律的、志愿的民间学术组织。
IETF是一个由为互联网技术发展做出贡献的专家自发参与和管理的国际民间机构。它汇集了与互联网架构演化和互联网稳定运作等业务相关的网络设计者、运营者和研究人员，并向所有对该行业感兴趣的人士开放。任何人都可以注册参加IETF的会议。IETF大会每年举行三次，规模均在千人以上。
二、IETF与互联网技术人员的关系
相信搞Internet的技术人员都会经常登录tools.ietf.org/html，在这里你可以查看很多网络技术规范，以及新老版本之间的差异。前一段时间搞DHCP时就需要时不时上去看看。
三、简单介绍下DHCP协议
DHCP(Dynamic Host Configuration Protocol)动态主机配置协议(RFC2131)，前身是BOOTP，是一个不太完善的网络应用层协议，主要提供路由动态给各Host(在Android上也可叫Station)分配地址的协商机制，我们知道在日常生活我们经常采用有线会无线网络上网，特别是智能机时代的到来使得我们更加紧密的和网络绑定在一起特别是WLAN网络，日益普及的Android只能时代，我们能够更加方便快捷的网上冲浪、享受微薄、QQ、各种小游戏的快乐，大都会选择WLAN网络。
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCPIP network.
DHCP is based on the Bootstrap Protocol (BOOTP)在WLAN技术中有一个关键技术技术DHCP，并且我们日常在Android设备上使用的也是动态主机分配IP，很当便。当然Android设备上也支持静态IP方式。
鄙人曾经也在Android平板/电视上开发过有线局域网，但不管那种方式目前IP分配机制分三种：动态主机分配、静态分配、自动分配(这种方式大多会用在公司集群网络中)，动态主机分配和自动分配的显著区别是后者具用永久性，前者具有周期性，存在一定的租赁周期，租赁周期到了要么续约要么释放，其它主机可以在IP池中抢占。
下面就DHCP的交互流程做简单介绍，具体内容请上http://tools.ietf.org/html/rfc2131.html仔细研读；
（一）DHCP报文格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1) | hlen (1) | hops (1) |
+---------------+---------------+---------------+---------------+
| xid (4) |
+-------------------------------+-------------------------------+
| secs (2) | flags (2) |
+-------------------------------+-------------------------------+
| ciaddr (4) |
+---------------------------------------------------------------+
| yiaddr (4) |
+---------------------------------------------------------------+
| siaddr (4) |
+---------------------------------------------------------------+
| giaddr (4) |
+---------------------------------------------------------------+
| |
| chaddr (16) |
| |
| |
+---------------------------------------------------------------+
| |
| sname (64) |
+---------------------------------------------------------------+
| |
| file (128) |
+---------------------------------------------------------------+
| |
| options (variable) |
+---------------------------------------------------------------+名词解释：
FIELD OCTETS DESCRIPTION
----- ------ -----------
op 1 Message op code / message type.
1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Hardware address type, see ARP section in "Assigned
Numbers" RFC; e.g., '1' = 10mb ethernet.
hlen 1 Hardware address length (e.g. '6' for 10mb
ethernet).
hops 1 Client sets to zero, optionally used by relay agents
when booting via a relay agent.
xid 4 Transaction ID, a random number chosen by the
client, used by the client and server to associate
messages and responses between a client and a
server.
secs 2 Filled in by client, seconds elapsed since client
began address acquisition or renewal process.
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; only filled in if client is in
BOUND, RENEW or REBINDING state and can respond
to ARP requests.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK by server.
giaddr 4 Relay agent IP address, used in booting via a
relay agent.
chaddr 16 Client hardware address.
sname 64 Optional server host name, null terminated string.
file 128 Boot file name, null terminated string; "generic"
name or null in DHCPDISCOVER, fully qualified
directory-path name in DHCPOFFER.
options var Optional parameters field. See the options
documents for a list of defined options.（二）完整的交互流程
1.第一次连接该ap时的流程
Server Client Server
(not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/ |
| \________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\____________ |
|/ DHCPREQUEST | DHCPREQUEST\ |
| | |
| | Commits configuration
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\ ____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v2.再次连接该ap的流程
Server Client Server
v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| _________ __/ | \__________ |
| /DHCPREQU EST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \ _______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v v以上图表很清楚得表达了DHCP的一个完整的交互过程，开发人员可以tcpdump工具抓取网络数据包进行分析，为了从诺大的数据报文中只匹配出DHCP报文，请在wireshark搜索条件中输入BOOTP进行匹配，从中可以清楚的看到交互的流程和每帧数据报文。这些对于想优化DHCP很有帮助，我曾经在一个Android手机项目中遇到一个问题：我们的机器比对比机在连接同一ap时概率性的慢几秒，起初怀疑是ip地址池已耗尽，但是登录路由后发现ip表未分配还很多，最后我们发现为了省电手机功率教对比机低，所以距离稍远时较差，同时我们通过分析空口数据报文和DHCP报文时发现我们会多次发送DHCPDISCOVER给路由器，都未获的应答，timeout时间时30s，所以我们优化了发送DHCPDISCOVER间隔时次数的算法，对比结果要强于对比机，
后续有时间的话，后续章节会从android WLAN和DHCP代码的角度来分析下Android 4.4 （KatKit）上的流程，并且多附图和例子。
ps:
日常我们常用到的网络协议如下
ip rfc791
tcp rc793
udp rfc768
icmp rfc792
ftp rfc959
http1.1 rfc2616
3172
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
