1、IETF简介
html
研究网络的人必定要知道IETF这道这个组织,IETF(互联网工程任务组),成立于1985年末,是全球互联网最具权威的技术标准化组织,主要任务是负责互联网相关技术规范的研发和制定,当前绝大多数国际互联网技术标准出自IETF。android
如下内容引自百度百科(特此申明):
算法
互联网工程任务组是bootstrap
松散的、自律的、志愿的民间学术组织。架构
IETF是一个由为互联网技术发展作出贡献的专家自发参与和管理的国际民间机构。它聚集了与互联网架构演化和互联网稳定运做等业务相关的网络设计者、运营者和研究人员,并向全部对该行业感兴趣的人士开放。任何人均可以注册参加IETF的会议。IETF大会每一年举行三次,规模均在千人以上。dom
2、IETF与互联网技术人员的关系tcp
相信搞Internet的技术人员都会常常登陆tools.ietf.org/html,在这里你能够查看不少网络技术规范,以及新老版本之间的差别。前一段时间搞DHCP时就须要时不时上去看看。ide
3、简单介绍下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 v
2.再次链接该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 rfc791tcp rc793udp rfc768icmp rfc792ftp rfc959http1.1 rfc2616