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