http://blog.csdn.net/jnu_simba/article/details/8957242
一、ISO/OSI參考模型
OSI（open system interconnection）開放系統互聯模型是由ISO（International Organization for Standardization）
國際標准化組織定義的網絡分層模型，共七層，如下圖。
物理層(Physical Layer)：物理層定義了所有電子及物理設備的規范，為上層的傳輸提供了一個物理介質，本層中數據傳輸的單位為比特（bit）。
屬於本層定義的規范有EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45等，實際使用中的設備如網卡等屬於本層。
數據鏈路層（Data Link Layer）：對物理層收到的比特流進行數據成幀。提供可靠的數據傳輸服務，實現無差錯數據傳輸。
在數據鏈路層中數據的單位為幀（frame）。屬於本層定義的規范有SDLC、HDLC、PPP、STP、幀中繼等，實際使用中的設備如switch交換機屬於本層。
網絡層（Network Layer）：網絡層負責將各個子網之間的數據進行路由選擇，分組與重組。本層中數據傳輸的單位為數據包（packet）
（This packet can be either an IP datagram or a fragment of an IP datagram）。
屬於本層定義的規范有IP、IPX、RIP、OSPF、ICMP、IGMP等。實際使用中的設備如路由器屬於本層。
注：可能大家經常被數據包還是數據報的名詞混淆，下面給出較准確的定義：
an IP datagram is the unit of end-to-end transmission at the IP layer (before fragmentation and after reassembly),
and a packet is the unit of data passed between the IP layer and the link layer.
A packet can be a complete IP datagram or a fragment of an IP datagram.
an IP datagram = packet + packet + packet + ... + packet
傳輸層（Transport Layer）：提供可靠的數據傳輸服務，它檢測路由器丟棄的包，然后產生一個重傳請求，
能夠將亂序收到的數據包重新排序。在傳輸層數據的傳輸單位是段（segment）。
會話層（Session Layer）：管理主機之間會話過程，包括會話建立、終止和會話過程中的管理。
表示層（Presentation Layer）：表示層對網絡傳輸的數據進行變換，使得多個主機之間傳送的信息能夠互相理解，
包括數據的壓縮、加密、格式轉換等。
應用層（Application Layer）：應用層與應用程序界面溝通，以達至展示給用戶的目的。
在此常見的協定有: HTTP，HTTPS，FTP，TELNET，SSH，SMTP，POP3等
二、TCP/IP協議四層模型
TCP/IP網絡協議棧分為應用層（Application）、傳輸層（Transport）、網絡層（Network）和鏈路層（Link）四層。
如下圖所示，如果沒有特別說明，一般引用的圖都出自《TCP/IP詳解》。
兩台計算機通過TCP/IP協議通訊的過程如下所示：
傳輸層及其以下的機制由內核提供，應用層由用戶進程提供，應用程序對通訊數據的含義進行解釋，
而傳輸層及其以下處理通訊的細節，將數據從一台計算機通過一定的路徑發送到另一台計算機。
應用層數據通過協議棧發到網絡上時，每層協議都要加上一個數據首部（header），稱為封裝（Encapsulation），如下圖所示：
不同的協議層對數據包有不同的稱謂，在傳輸層叫做段（segment），在網絡層叫做數據包（packet），在鏈路層叫做幀（frame）。
數據封裝成幀后發到傳輸介質上，到達目的主機后每層協議再剝掉相應的首部，最后將應用層數據交給應用程序處理。
上圖對應兩台計算機在同一網段中的情況，如果兩台計算機在不同的網段中，
那么數據從一台計算機到另一台計算機傳輸過程中要經過一個或多個路由器，如下圖所示：
其實在鏈路層之下還有物理層，指的是電信號的傳遞方式，比如現在以太網通用的網線（雙絞線）、
早期以太網采用的的同軸電纜（現在主要用於有線電視）、光纖等都屬於物理層的概念。
物理層的能力決定了最大傳輸速率、傳輸距離、抗干擾性等。
集線器（Hub）是工作在物理層的網絡設備，用於雙絞線的連接和信號中繼（將已衰減的信號再次放大使之傳得更遠）。
鏈路層有以太網、令牌環網等標准，鏈路層負責網卡設備的驅動、幀同步（就是說從網線上檢測到什么信號算作新幀的開始）、
沖突檢測（如果檢測到沖突就自動重發）、數據差錯校驗等工作。交換機是工作在鏈路層的網絡設備，
可以在不同的鏈路層網絡之間轉發數據幀（比如十兆以太網和百兆以太網之間、以太網和令牌環網之間），
由於不同鏈路層的幀格式不同，交換機要將進來的數據包拆掉鏈路層首部重新封裝之后再轉發。
網絡層的IP協議是構成Internet的基礎。負責點到點（point-to-point）的傳輸（這里的“點”指主機或路由器）
Internet上的主機通過IP地址來標識，Internet上有大量路由器負責根據IP地址選擇合適的路徑轉發數據包，
數據包從Internet上的源主機到目的主機往往要經過十多個路由器。
路由器是工作在第三層的網絡設備，同時兼有交換機的功能，可以在不同的鏈路層接口之間轉發數據包，
因此路由器需要將進來的數據包拆掉網絡層和鏈路層兩層首部並重新封裝。
IP協議不保證傳輸的可靠性，數據包在傳輸過程中可能丟失，可靠性可以在上層協議或應用程序中提供支持。
網絡層負責點到點（point-to-point）的傳輸（這里的“點”指主機或路由器），而傳輸層負責端到端（end-to-end）的傳輸（這里的“端”指源主機和目的主機）。
傳輸層可選擇TCP或UDP協議。負責端到端（end-to-end）的傳輸（這里的“端”指源主機和目的主機）。
TCP是一種面向連接的、可靠的協議，有點像打電話，雙方拿起電話互通身份之后就建立了連接，然后說話就行了，
這邊說的話那邊保證聽得到，並且是按說話的順序聽到的，說完話掛機斷開連接。
也就是說TCP傳輸的雙方需要首先建立連接，之后由TCP協議保證數據收發的可靠性，丟失的數據包自動重發，
上層應用程序收到的總是可靠的數據流，通訊之后關閉連接。
UDP協議不面向連接，也不保證可靠性，有點像寄信，寫好信放到郵筒里，既不能保證信件在郵遞過程中不會丟失，
也不能保證信件是按順序寄到目的地的。使用UDP協議的應用程序需要自己完成丟包重發、消息排序等工作。
目的主機收到數據包后，如何經過各層協議棧最后到達應用程序呢？整個過程如下圖所示：
以太網驅動程序首先根據以太網首部中的“上層協議”字段確定該數據幀的有效載荷（payload，指除去協議首部之外實際傳輸的數據）是
IP、ARP還是RARP協議的數據報，然后交給相應的協議處理。
假如是IP數據報，IP協議再根據IP首部中的“上層協議”字段確定該數據報的有效載荷是
TCP、UDP、ICMP還是IGMP，然后交給相應的協議處理。
假如是TCP段或UDP段，TCP或UDP協議再根據TCP首部或UDP首部的“端口號”字段
確定應該將應用層數據交給哪個用戶進程。
IP地址是標識網絡中不同主機的地址，而端口號就是同一台主機上標識不同進程的地址，
IP地址和端口號合起來標識網絡中唯一的進程。
注意，雖然IP、ARP和RARP數據報都需要以太網驅動程序來封裝成幀，但是從功能上划分，
ARP和RARP屬於鏈路層，IP屬於網絡層。
雖然ICMP、IGMP、TCP、UDP的數據都需要IP協議來封裝成數據報，
但是從功能上划分，ICMP、IGMP與IP同屬於網絡層，TCP和UDP屬於傳輸層。
IP協議--IP數據報格式
http://yin123.blog.51cto.com/882581/461436
IP協議特點
IP協議位於網絡層，是因特網的核心協議，除了ARP和RARP報文外，幾乎所有的數據都要經過IP協議進行發送。
由於IP協議在網絡層中具有重要地位，人們又將TCP/IP協議的網絡層稱為IP層。
IP協議是不可靠的無連接數據報協議，提高盡力而為的傳輸服務，具有一下特點：
① 是點對點協議，雖然IP數據報攜帶源IP和目的IP地址，但進行數據傳輸時的對等實體一定相鄰設備（同一網絡中）的對等實體。
② IP協議不保證傳輸的可靠性，不對數據進行差錯校驗和跟蹤，可靠性有IP的上層TCP協議加以保證。
③ IP協議提供無連接數據報服務，各個數據報獨立傳輸，可能沿着不同路徑到達目的地，也可能不按序到達目的地。
正因為IP協議采用盡力傳輸的思想，所以IP協議的效率非常高，實現也簡單。
IP層向下要面對各種不同的物理網絡，向上卻提供一個同一的數據傳輸服務。
通過IP數據報實現了物理數據幀的同一，IP層達到了向上屏蔽底層差異的目的。
IP數據報
IP協議所處理的數據單元稱為IP數據報。其格式如下：
IP數據報由首部和數據兩部分組成，首部又分為定長部分和變長部分。
版本(VER)：4位，表示數據報的IP協議版本，
當前的IP協議版本號為4，即IPv4;
下一代網絡協議IPv6，版本號為6.
首部長度（HLEN）:4位，表示以字長（4字節）為單位的數據報首部長度。
服務類型（SERVICE TYPE）: 8位，規定本數據報的處理方式。
前三位是優先級，0-7，0表示最低，7最高（最重要），但目前的IPv4沒有使用優先級。
后4位是TOS，表示本數據報在傳輸過程中所希望得到的服務，
D--最小延遲（minimize delay）；T--最大吞吐率（maximize throughout）；
R--最高可靠性（maximize reliability）；C--最低成本（minimize cost）。
值得注意的有2點：
①服務類型代表用戶的希望，並不具有強制性，目前許多設備TCP/IP中不支持服務類型特性。
②在D、T、R、C這4個參數中只能設置其中一個。
數據報總長度： 在IP數據報封裝到以太網幀中進行傳輸時很有用.
標識（IDENTIFICATION）：16位每個IP數據報都有一個本地唯一的標識符，它由信源機賦予IP數據報。每次自動加1.
標志（FLAGS）：3位，表示該IP數據報是否允許分片以及是否最后一片。
片偏移（FRAGMENTATION OFFSET）：表示本片數據在他所屬原始數據報數據區的偏移量。
生存時間（time to live,TTL）: 8位，
協議（PROTOCOL）：8位，指明被IP數據報封裝的協議:
ICMP=1,IGMP=2,TCP=6,EGP=8,UDP=17,OSPF=89.
首部校驗和（HEADER CHECKSUM）：16位，保證首部數據完整性。
源IP地址（SOURCE ADDRESS）：32位（IPv4中），發送方源地址。
目的地址（DESTINATION ADDRESS）: 32位（IPv4中），最總接收方IP地址。
IP選項（IP OPTIONS）：變長字段，傳輸數據報時的附加功能。
http://blog.pfan.cn/xman/44383.html
版本字段長度為4，用來表明建立數據報的IP版本，
目前的IP版本是IPv4,IPv6正在發展中。IPv4的字段為0100 。
首部長度（報頭長度）指的是首部占32 bit字的數目，包括任何選項。
由於它是一個4比特字段，因此首部最長為60個字節。
15x32/8=60字節.
IP首部始終是32 bit的整數倍.IP數據報報頭的最小長度為20個字（不含填充字段和IP選項字段的IP報頭是最常見的IP報頭，為20個字節）
服務類型TOS（Type Of Service）總長度字段是指整個I P數據報的長度，以字節為單位.由於該字段長16比特，
所以I P數據報最長可達6 5 5 3 5字節(64KB).總長度字段是I P首部中必要的內容。數據長度＝總長－報頭長度。
標識符長16比特。標志位長度為3比特，用於分段控制：
第0位為預留位，第1位表示可否分段。當該位的值為0時，表示數據報不可分段，值為1時，表示數據報可被分段。
第2位為段是否結束位，當該位的值為0時，表示該段是原數據報的最后一段，值為1時，表示后面不有更多的分段。
當網絡設備要發送的數據報長度比所在網絡的最大傳輸單元（MTU，Max Transfer United）大，
並且標志位的第1位設置為不能分段（0）時，網絡設備會向發送方返回一個因特網控制消息協議ICMP錯誤消息，
並丟棄該數據報。除了最后一個分段外，其余分段的第2位均設置為1。
段偏移13比特長度，用於指定分段在原始數據報中的位置,以8個字節為單位.
生存時間TTL長度為8比特，用於指定數據報允許保留在網絡上的時間。
協議字段長度為8比特，用於指定數據報數據區中攜帶的消息是由哪種高級協議建立的。
ICMP為1,TCP為6，UDP為17。 協議號分配RFC790.
報頭校驗和16比特，僅用於IP報頭校驗和。
源IP地址及目的IP地址。
選項，填充字段用於確保將選項字段填充為最少32個比特位，以保證IP報頭以32位結束。
分段：分段是將一個大的IP數據報分解成幾個較小的數據報段的過程。
當IP模塊需要通過一個具有較小MTU的網絡傳送較大的數據包時，就必須將其分段。
//定義ip報頭數據結構 typedef struct _iphdr { byte ver_len; //版本4位,頭長度4位,報頭長度以32位為一個單位 byte type; //類型8位 byte length[2]; //總長度,16位,指出報文的以字節為單位的總長度 //報文長度不能超過65536個字節，否則認為報文遭到破壞 byte id[2]; //報文標示,用於多於一個報文16位 byte flag_offset[2];//標志,3位 數據塊偏移13位 byte time; //生存時間,8位 byte protocol; //協議,8位 byte crc_val[2]; //頭校驗和，16位 byte src_addr[4]; //源地址,32位 byte tar_addr[4]; //目標地址,32位 byte options[4]; //選項和填充,32位 }IP_HEADER;
TCP報文格式
傳輸控制協議（TCP）向上與用戶應用程序進程接口，向下與網絡層協議IP接口。
用戶應用程序采用首先調用TCP（或UDP），然后將應用程序數據遞交給TCP這一方式，
在IP網絡上傳送數據。TCP將這些數據打包分段並調用IP模塊向目的主機傳送每個數據段。
接收方的TCP將段中的數據放入接收緩沖器，然后將段重裝為應用程序數據，
再將這些數據發送到目的的應用程序進程。盡管TCP和UDP都使用相同的網絡層（IP），
TCP卻向應用層提供與UDP完全不同的服務。TCP提供一種面向連接的、可靠的字節流服務。
源端口號（16位），標識主機上發起傳送的應用程序；
目的端口（16位）標識主機上傳送要到達的應用程序。
源端和目的端的端口號，用於尋找發端和收端應用進程。
這兩個值加上I P首部中的源端I P地址和目的端I P地址唯一確定一個T C P連接。
一個I P地址和一個端口號有時也稱為一個插口（socket），
插口對（socket pair）(包含客戶I P地址、客戶端口號、服務器 I P地址和服務器端口號的四元組 )
可唯一確定互聯網絡中每個T C P連接的雙方。
IP+TCP端口唯一確定一個TCP連接。
TCP協議通過使用"端口"來標識源端和目標端的應用進程。
端口號可以使用0到65535之間的任何數字。
在收到服務請求時，操作系統動態地為客戶端的應用程序分配端口號。
在服務器端，每種服務在"眾所周知的端口"（Well-Know Port）為用戶提供服務。
順序號字段：占32比特。用來標識從TCP源端向TCP目標端發送的數據字節流，它表示在這個報文段中的第一個數據字節。
確認號字段：占32比特。只有ACK標志為1時，確認號字段才有效。它包含目標端所期望收到源端的下一個數據字節。
頭部長度字段：占4比特。給出頭部占32比特的數目。沒有任何選項字段的TCP頭部長度為20字節；最多可以有60字節的TCP頭部。
預留：由跟在數據偏移字段后的6位構成，預留位通常為0.
標志位字段（U、A、P、R、S、F）：占6比特。各比特的含義如下：
URG：緊急指針（urgent pointer）有效。
ACK：確認序號有效。
PSH：接收方應該盡快將這個報文段交給應用層。
RST：重建連接。
SYN：發起一個連接。
FIN：釋放一個連接。
窗口大小字段：占16比特。此字段用來進行流量控制。單位為字節數，這個值是本機期望一次接收的字節數。
TCP校驗和字段：占16比特。對整個TCP報文段，即TCP頭部和TCP數據進行校驗和計算，並由目標端進行驗證。
緊急指針字段：占16比特。它是一個偏移量，和序號字段中的值相加表示緊急數據最后一個字節的序號。
選項字段：占32比特。可能包括"窗口擴大因子"、"時間戳"等選項。
數據： TCP 報文段中的數據部分是可選的。在一個連接建立和一個連接終止時，雙方交換的報文段僅有 TCP 首部。
如果一方沒有數據要發送，也使用沒有任何數據的首部來確認收到的數據。
在處理超時的許多情況中，也會發送不帶任何數據的報文段。
//定義TCP報頭 typedef struct _tcphdr { byte source_port[2]; //發送端端口號,16位 byte dest_port[2]; //接收端端口號,16位 byte sequence_no[4]; //32位，標示消息端的數據位於全體數據塊的某一字節的數字 byte ack_no[4]; //32位，確認號,標示接收端對於發送端接收到數據塊數值 byte offset_reser_con[2];//數據偏移4位，預留6位，控制位6為 byte window[2]; //窗口16位 byte checksum[2]; //校驗碼,16位 byte urgen_pointer[2]; //16位，緊急數據指針 byte options[3]; //選祥和填充,32位 }TCP_HEADER;
UDP協議及包格式
http://yin123.blog.51cto.com/882581/461450
1.無連接，不可靠；
2.出錯（通過校驗和檢查）就丟掉此包，丟失不重傳，只是給個警告；
3.包的格式，有源端口和目的端口，校驗和等；
4.端口號，根據應用層服務的不同，可以是默認的端口，也可以自己設定。
UDP是一種無連接的、不可靠的傳輸層協議；
在完成進程到進程的通信中提供了有限的差錯檢驗功能；
設計比較簡單的UDP協議的目的是希望以最小的開銷來達到網絡環境中的進程通信目的；
進程發送的報文較短，同時對報文的可靠性要求不高，那么可以使用UDP協議。
源端口號和目的端口號如上和TCP的相同。
UDP長度：UDP報文的字節長度（包括首部和數據）。
UDP校驗和: 檢驗UDP首部和數據部分的正確性。
http://www.cw.njupt.edu.cn/shenjl/frame/wlkj/ch8/chapter83.htm
用戶數據報UDP有兩個字段：數據字段和首部字段。首部字段有8個字節，由4個字段組成，每個字段都是兩個字節。
在計算檢驗和時，臨時把“偽首部”和UDP用戶數據報連接在一起。偽首部僅僅是為了計算檢驗和。
UDP用戶數據報的首部中長度字段定義了數據報的總長度，即首部加數據部分。
UDP用戶數據報的首部中檢驗和用來檢驗整個用戶數據報（首部加數據部分）出現的差錯。計算偽首部可以增加可靠性。
( 4 + 4 + 1 + 1 + 2 ) + (2 + 2 + 2 + 2 ）= 20
偽首部的作用是用於檢驗UDP數據報已經到達正確的目的地，即正確的主機和協議端口。
盡管IP數據報首部已經包含了必要的校驗和，但是，它並不能保證檢驗出所有的首部錯誤，
因此，為了確保數據傳輸的正確性，在UDP的報文驗證時，通過增加偽首部信息校驗，
再次對IP數據報中的源IP地址、目的IP地址、協議類型和數據長度等信息進行校驗。
需要注意的是，偽首部的內容在報文的傳輸中是不需要傳送的，
即報文中並不安排專門的位置存放偽首部內容，只是在發送報文時計算校驗和，
以及接收報文時驗證校驗和時，需要將偽首部定義的內容納入校驗和計算和驗證的范疇
偽首部包含IP首部一些字段。其目的是讓UDP兩次檢查數據是否已經正確到達目的地，只是單純為了做校驗用的。
還有一個概念十分重要，那就是16位UDP總長度，請注意該長度不是報文的總長度，
而只是UDP（包括UDP頭和數據部分）的總長度
互聯網通訊協議知識講座
http://www.itokit.com/2012/0830/74714.html
最底下的一層叫做"實體層"（Physical Layer），最上面的一層叫做"應用層"（Application Layer），
中間的三層（自下而上）分別是"鏈接層"（Link Layer）、"網絡層"（Network Layer）和"傳輸層"（Transport Layer）。
越下面的層，越靠近硬件；越上面的層，越靠近用戶。
層與協議
每一層都是為了完成一種功能。為了實現這些功能，就需要大家都遵守共同的規則。
大家都遵守的規則，就叫做"協議"（protocol）。
互聯網的每一層，都定義了很多協議。這些協議的總稱，就叫做"互聯網協議"（Internet Protocol Suite）。
它們是互聯網的核心，下面介紹每一層的功能，主要就是介紹每一層的主要協議。
實體層
它就是把電腦連接起來的物理手段。它主要規定了網絡的一些電氣特性，作用是負責傳送0和1的電信號。
以太網協議
早期的時候，每家公司都有自己的電信號分組方式。逐漸地，一種叫做"以太網"（Ethernet）的協議，占據了主導地位。
以太網規定，一組電信號構成一個數據包，叫做"幀"（Frame）。每一幀分成兩個部分：標頭（Head）和數據（Data）
標頭"包含數據包的一些說明項，比如發送者、接受者、數據類型等等；"數據"則是數據包的具體內容。
"標頭"的長度，固定為18字節。"數據"的長度，最短為46字節，最長為1500字節。
因此，整個"幀"最短為64字節，最長為1518字節。如果數據很長，就必須分割成多個幀進行發送。
網卡的地址，就是數據包的發送地址和接收地址，這叫做MAC地址。
每塊網卡出廠的時候，都有一個全世界獨一無二的MAC地址，長度是48個二進制位，通常用12個十六進制數表示。
前6個十六進制數是廠商編號，后6個是該廠商的網卡流水號。有了MAC地址，就可以定位網卡和數據包的路徑了。
網絡層的由來
以太網協議，依靠MAC地址發送數據。理論上，單單依靠MAC地址，上海的網卡就可以找到洛杉磯的網卡了，技術上是可以實現的。
但是，這樣做有一個重大的缺點。以太網采用廣播方式發送數據包，所有成員人手一"包"，不僅效率低，而且局限在發送者所在的子網絡。
也就是說，如果兩台計算機不在同一個子網絡，廣播是傳不過去的。
這種設計是合理的，否則互聯網上每一台計算機都會收到所有包，那會引起災難。
互聯網是無數子網絡共同組成的一個巨型網絡，很像想象上海和洛杉磯的電腦會在同一個子網絡，這幾乎是不可能的。
因此，必須找到一種方法，能夠區分哪些MAC地址屬於同一個子網絡，哪些不是。
如果是同一個子網絡，就采用廣播方式發送，否則就采用"路由"方式發送。
（"路由"的意思，就是指如何向不同的子網絡分發數據包，這是一個很大的主題，本文不涉及。）
遺憾的是，MAC地址本身無法做到這一點。它只與廠商有關，與所處網絡無關。
這就導致了"網絡層"的誕生。它的作用是引進一套新的地址，使得我們能夠區分不同的計算機是否屬於同一個子網絡。
這套地址就叫做"網絡地址"，簡稱"網址"。
於是，"網絡層"出現以后，每台計算機有了兩種地址，一種是MAC地址，另一種是網絡地址。
兩種地址之間沒有任何聯系，MAC地址是綁定在網卡上的，網絡地址則是管理員分配的，它們只是隨機組合在一起。
網絡地址幫助我們確定計算機所在的子網絡，MAC地址則將數據包送到該子網絡中的目標網卡。
因此，從邏輯上可以推斷，必定是先處理網絡地址，然后再處理MAC地址。
協議
規定網絡地址的協議，叫做IP協議。它所定義的地址，就被稱為IP地址。
目前，廣泛采用的是IP協議第四版，簡稱IPv4。這個版本規定，網絡地址由32個二進制位組成。
習慣上，我們用分成四段的十進制數表示IP地址，從0.0.0.0一直到255.255.255.255。
互聯網上的每一台計算機，都會分配到一個IP地址。
這個地址分成兩個部分，前一部分代表網絡，后一部分代表主機。
比如，IP地址172.16.254.1，這是一個32位的地址，
假定它的網絡部分是前24位（172.16.254），那么主機部分就是后8位（最后的那個1）。
處於同一個子網絡的電腦，它們IP地址的網絡部分必定是相同的，
也就是說172.16.254.2應該與172.16.254.1處在同一個子網絡。
但是，問題在於單單從IP地址，我們無法判斷網絡部分。
還是以172.16.254.1為例，它的網絡部分，到底是前24位，還是前16位，甚至前28位，從IP地址上是看不出來的。
那么，怎樣才能從IP地址，判斷兩台計算機是否屬於同一個子網絡呢？這就要用到另一個參數"子網掩碼"（subnet mask）。
所謂"子網掩碼"，就是表示子網絡特征的一個參數。
它在形式上等同於IP地址，也是一個32位二進制數字，它的網絡部分全部為1，主機部分全部為0。
比如，IP地址172.16.254.1，如果已知網絡部分是前24位，主機部分是后8位，
那么子網絡掩碼就是11111111.11111111.11111111.00000000，寫成十進制就是255.255.255.0。
知道"子網掩碼"，我們就能判斷，任意兩個IP地址是否處在同一個子網絡。
方法是將兩個IP地址與子網掩碼分別進行AND運算（兩個數位都為1，運算結果為1，否則為0），然后比較結果是否相同，
如果是的話，就表明它們在同一個子網絡中，否則就不是。
比如，已知IP地址172.16.254.1和172.16.254.233的子網掩碼都是255.255.255.0，請問它們是否在同一個子網絡？
兩者與子網掩碼分別進行AND運算，結果都是172.16.254.0，因此它們在同一個子網絡。
總結一下，IP協議的作用主要有兩個，一個是為每一台計算機分配IP地址，另一個是確定哪些地址在同一個子網絡。
IP數據包
根據IP協議發送的數據，就叫做IP數據包。不難想象，其中必定包括IP地址信息。
但是前面說過，以太網數據包只包含MAC地址，並沒有IP地址的欄位。那么是否需要修改數據定義，再添加一個欄位呢？
回答是不需要，我們可以把IP數據包直接放進以太網數據包的"數據"部分，因此完全不用修改以太網的規格。
這就是互聯網分層結構的好處：上層的變動完全不涉及下層的結構。
具體來說，IP數據包也分為"標頭"和"數據"兩個部分。
"標頭"部分主要包括版本、長度、IP地址等信息，"數據"部分則是IP數據包的具體內容。
它放進以太網數據包后，以太網數據包就變成了下面這樣。
P數據包的"標頭"部分的長度為20到60字節，整個數據包的總長度最大為65,535字節。
因此，理論上，一個IP數據包的"數據"部分，最長為65,515字節。
前面說過，以太網數據包的"數據"部分，最長只有1500字節。
因此，如果IP數據包超過了1500字節，它就需要分割成幾個以太網數據包，分開發送了。
ARP協議
關於"網絡層"，還有最后一點需要說明。
因為IP數據包是放在以太網數據包里發送的，所以我們必須同時知道兩個地址，
一個是對方的MAC地址，另一個是對方的IP地址。
通常情況下，對方的IP地址是已知的（后文會解釋），但是我們不知道它的MAC地址。
所以，我們需要一種機制，能夠從IP地址得到MAC地址。
這里又可以分成兩種情況。
第一種情況，如果兩台主機不在同一個子網絡，那么事實上沒有辦法得到對方的MAC地址，
只能把數據包傳送到兩個子網絡連接處的"網關"（gateway），讓網關去處理。
第二種情況，如果兩台主機在同一個子網絡，那么我們可以用ARP協議，得到對方的MAC地址。
ARP協議也是發出一個數據包（包含在以太網數據包中），其中包含它所要查詢主機的IP地址，
在對方的MAC地址這一欄，填的是FF:FF:FF:FF:FF:FF，表示這是一個"廣播"地址。
它所在子網絡的每一台主機，都會收到這個數據包，從中取出IP地址，與自身的IP地址進行比較。
如果兩者相同，都做出回復，向對方報告自己的MAC地址，否則就丟棄這個包。
總之，有了ARP協議之后，我們就可以得到同一個子網絡內的主機MAC地址，
可以把數據包發送到任意一台主機之上了。
傳輸層的由來
有了MAC地址和IP地址，我們已經可以在互聯網上任意兩台主機上建立通信。
接下來的問題是，同一台主機上有許多程序都需要用到網絡，比如，你一邊瀏覽網頁，一邊與朋友在線聊天。
當一個數據包從互聯網上發來的時候，你怎么知道，它是表示網頁的內容，還是表示在線聊天的內容？
也就是說，我們還需要一個參數，表示這個數據包到底供哪個程序（進程）使用。
這個參數就叫做"端口"（port），它其實是每一個使用網卡的程序的編號。
每個數據包都發到主機的特定端口，所以不同的程序就能取到自己所需要的數據。
"端口"是0到65535之間的一個整數，正好16個二進制位。
0到1023的端口被系統占用，用戶只能選用大於1023的端口。
不管是瀏覽網頁還是在線聊天，應用程序會隨機選用一個端口，然后與服務器的相應端口聯系。
"傳輸層"的功能，就是建立"端口到端口"的通信。
相比之下，"網絡層"的功能是建立"主機到主機"的通信。
只要確定主機和端口，我們就能實現程序之間的交流。
因此，Unix系統就把主機+端口，叫做"套接字"（socket）。有了它，就可以進行網絡應用程序開發了。
UDP協議
現在，我們必須在數據包中加入端口信息，這就需要新的協議。
最簡單的實現叫做UDP協議，它的格式幾乎就是在數據前面，加上端口號。
UDP數據包，也是由"標頭"和"數據"兩部分組成。
"標頭"部分主要定義了發出端口和接收端口，"數據"部分就是具體的內容。
然后，把整個UDP數據包放入IP數據包的"數據"部分，而前面說過，
IP數據包又是放在以太網數據包之中的，所以整個以太網數據包現在變成了下面這樣：
UDP數據包非常簡單，"標頭"部分一共只有8個字節，總長度不超過65,535字節，正好放進一個IP數據包。
TCP協議
UDP協議的優點是比較簡單，容易實現，但是缺點是可靠性較差，一旦數據包發出，無法知道對方是否收到。
為了解決這個問題，提高網絡可靠性，TCP協議就誕生了。這個協議非常復雜，但可以近似認為，
它就是有確認機制的UDP協議，每發出一個數據包都要求確認。
如果有一個數據包遺失，就收不到確認，發出方就知道有必要重發這個數據包了。
因此，TCP協議能夠確保數據不會遺失。它的缺點是過程復雜、實現困難、消耗較多的資源。
TCP數據包和UDP數據包一樣，都是內嵌在IP數據包的"數據"部分。
TCP數據包沒有長度限制，理論上可以無限長，但是為了保證網絡的效率，
通常TCP數據包的長度不會超過IP數據包的長度，以確保單個TCP數據包不必再分割。
應用層
應用程序收到"傳輸層"的數據，接下來就要進行解讀。
由於互聯網是開放架構，數據來源五花八門，必須事先規定好格式，否則根本無法解讀。
"應用層"的作用，就是規定應用程序的數據格式。
舉例來說，TCP協議可以為各種各樣的程序傳遞數據，比如Email、WWW、FTP等等。
那么，必須有不同協議規定電子郵件、網頁、FTP數據的格式，這些應用程序協議就構成了"應用層"。
這是最高的一層，直接面對用戶。它的數據就放在TCP數據包的"數據"部分。
因此，現在的以太網的數據包就變成下面這樣。
至此，整個互聯網的五層結構，自下而上全部講完了。這是從系統的角度，解釋互聯網是如何構成的。
下一篇，我反過來，從用戶的角度，自上而下看看這個結構是如何發揮作用，完成一次網絡數據交換的。
DHCP協議
首先，它是一種應用層協議，建立在UDP協議之上，所以整個數據包是這樣的：
1）最前面的"以太網標頭"，設置發出方（本機）的MAC地址和接收方（DHCP服務器）的MAC地址。
前者就是本機網卡的MAC地址，后者這時不知道，就填入一個廣播地址：FF-FF-FF-FF-FF-FF。
2）后面的"IP標頭"，設置發出方的IP地址和接收方的IP地址。這時，對於這兩者，本機都不知道。
於是，發出方的IP地址就設為0.0.0.0，接收方的IP地址設為255.255.255.255。
3）最后的"UDP標頭"，設置發出方的端口和接收方的端口。
這一部分是DHCP協議規定好的，發出方是68端口，接收方是67端口。
這個數據包構造完成后，就可以發出了。以太網是廣播發送，同一個子網絡的每台計算機都收到了這個包。
因為接收方的MAC地址是FF-FF-FF-FF-FF-FF，看不出是發給誰的，所以每台收到這個包的計算機，
還必須分析這個包的IP地址，才能確定是不是發給自己的。
當看到發出方IP地址是0.0.0.0，接收方是255.255.255.255，
於是DHCP服務器知道"這個包是發給我的"，而其他計算機就可以丟棄這個包。
接下來，DHCP服務器讀出這個包的數據內容，分配好IP地址，發送回去一個"DHCP響應"數據包。
這個響應包的結構也是類似的，以太網標頭的MAC地址是雙方的網卡地址，
IP標頭的IP地址是DHCP服務器的IP地址（發出方）和255.255.255.255（接收方），
UDP標頭的端口是67（發出方）和68（接收方），分配給請求端的IP地址和本網絡的具體參數則包含在Data部分。
新加入的計算機收到這個響應包，於是就知道了自己的IP地址、子網掩碼、網關地址、DNS服務器等等參數。
DNS協議
我們知道，發送數據包，必須要知道對方的IP地址。
但是，現在，我們只知道網址www.google.com，不知道它的IP地址。
DNS協議可以幫助我們，將這個網址轉換成IP地址。
已知DNS服務器為8.8.8.8，於是我們向這個地址發送一個DNS數據包（53端口）。
然后，DNS服務器做出響應，告訴我們Google的IP地址是172.194.72.105。於是，我們知道了對方的IP地址。
子網掩碼
接下來，我們要判斷，這個IP地址是不是在同一個子網絡，這就要用到子網掩碼。
已知子網掩碼是255.255.255.0，本機用它對自己的IP地址192.168.1.100，
做一個二進制的AND運算（兩個數位都為1，結果為1，否則為0），計算結果為192.168.1.0；
然后對Google的IP地址172.194.72.105也做一個AND運算，計算結果為172.194.72.0。
這兩個結果不相等，所以結論是，Google與本機不在同一個子網絡。
因此，我們要向Google發送數據包，必須通過網關192.168.1.1轉發，
也就是說，接收方的MAC地址將是網關的MAC地址。
應用層協議
瀏覽網頁用的是HTTP協議，它的整個數據包構造是這樣的：
假定這個部分的長度為4960字節，它會被嵌在TCP數據包之中。
TCP協議
TCP數據包需要設置端口，接收方（Google）的HTTP端口默認是80，
發送方（本機）的端口是一個隨機生成的1024-65535之間的整數，假定為51775。
TCP數據包的標頭長度為20字節，加上嵌入HTTP的數據包，總長度變為4980字節。
IP協議
然后，TCP數據包再嵌入IP數據包。IP數據包需要設置雙方的IP地址，這是已知的，
發送方是192.168.1.100（本機），接收方是172.194.72.105（Google）。
IP數據包的標頭長度為20字節，加上嵌入的TCP數據包，總長度變為5000字節。
以太網協議
最后，IP數據包嵌入以太網數據包。
以太網數據包需要設置雙方的MAC地址，發送方為本機的網卡MAC地址，接收方為網關192.168.1.1的MAC地址（通過ARP協議得到）。
以太網數據包的數據部分，最大長度為1500字節，而現在的IP數據包長度為5000字節。
因此，IP數據包必須分割成四個包。因為每個包都有自己的IP標頭（20字節），
所以四個包的IP數據包的長度分別為1500、1500、1500、560。
服務器端響應
經過多個網關的轉發，Google的服務器172.194.72.105，收到了這四個以太網數據包。
根據IP標頭的序號，Google將四個包拼起來，取出完整的TCP數據包，
然后讀出里面的"HTTP請求"，接着做出"HTTP響應"，再用TCP協議發回來。
本機收到HTTP響應以后，就可以將網頁顯示出來，完成一次網絡通信。
802.11 WLAN Packets and Protocols
http://www.wildpackets.com/resources/compendium/wireless_lan/wlan_packets
802.11 WLAN overview
This section presents a detailed overview of the 802.11 WLAN standards.
The information is presented under general functional headings.
A detailed breakdown of 802.11 WLAN packet headers and of 802.2 LLC headers is presented after the overview.
Development of the IEEE 802.11 WLAN standards
In 1997, IEEE approved 802.11, the first internationally sanctioned wireless LAN standard.
This first standard proposed any of three (mutually incompatible) implementations for the physical layer:
infrared (IR) pulse position modulation, or radio frequency (RF) signalling in the 2.4 GHz band
using either frequency hopping spread spectrum (FHSS) or direct sequence spread spectrum (DSSS).
The IR method was never commercially implemented.
The RF versions suffered from low transmission speeds (2 Mbps).
In an effort to increase throughput, IEEE established two working groups (A and B) to explore alternate implementations of 802.11.
A third group, Working Group G, was set up after these two.
Packet structure and packet types
Like the rest of the 802 family of LAN protocols, 802.11 WLAN sends all network traffic in packets.
There are three basic types:
data packets,
network management packets and
control packets.
The first section describes the basic structure of 802.11 WLAN data packets
and the information they provide for network analysis.
The second section describes the management and control packets,
their functions and the role they play in network analysis.
Packet structure
All the functionality of the protocol is reflected in the packet headers.
RF technology and station mobility impose some complex requirements on 802.11 WLAN networks.
This added complexity is reflected in the long physical layer convergence protocol (PLCP) headers
as well as the data-rich MAC header.
Because 802.11 WLANs must be able to form and re-form their membership constantly,
and because radio transmission conditions themselves can change, coordination becomes a large issue in WLANs.
Management and control packets are dedicated to these coordination functions.
In addition, the headers of ordinary data packets contain a great deal more information about network conditions and topology than,
for example, the headers of Ethernet data packets would contain.
WLAN frames and packet headers
This section describes the various layers of 802.11 WLAN packet headers and
the clues they contain to the protocols found in the network data which they frame.
The typical 802.11 packet frames the network data inside a physical layer header,
followed by a MAC layer header with a FCS trailer for error control.
All versions of 802.11 support use of the 802.2 standard for Logical Link Control or LLC.
As Figure C.12 above shows, the hardware preamble,
packet start delimiter and end delimiter bytes are not captured by OmniPeek.
The PLCP header is used by network hardware to control the transmission and
maintain the physical (in this case, radio wave) link between stations.
Higher layers in the packet, beginning with the MAC header,
are captured by OmniPeek and presented both as raw data and as decoded data.
PLCP
802.11 WLAN protocols permit negotiation of transmission rates for each session.
They also permit changes in packet fragmentation to improve overall throughput under changing conditions.
To support these functions, they use a physical layer header called the PLCP (Physical Layer Convergence Protocol),
consisting of a PLCP preamble and the PLCP header.
The physical layers of the 802.11a WLAN and the 802.11b WLAN are different,
and so the PLCP is distinct for each. Even so, they have important similarities.
In both standards, the PLCP header is transmitted immediately after an initial synchronization or training sequence,
and immediately before the MAC header.
In both standards, the PLCP header contains information on the rate and length of the rest of the packet.
Whether the packet length is expressed in bytes or as a unit of time, receiving stations can use the PLCP header to determine
how much time should be allowed for transmission of this packet.
Even if a receiver does not support the data rate requested in the packet, it knows how long to wait before the channel will again be clear.
PLCP header also contains error correction and information on the encoding scheme (related to data rate) used in the remainder of the packet.
The PLCP portion of the transmission is always sent at the lowest commonly supported data rate,
to insure maximum reliability and compatibility with other stations.
802.11 MAC header
The particular format of the 802.11 MAC header depends on the type of packet:
data packets, network management packets or control packets.
The description which follows (based on Figure C.13) is for an 802.11 WLAN data packet.
Management and control packets have only the first three of the four address fields.
They may also contain information in the frame body in fields of fixed or
variable length which are specific to that particular type and subtype of packet.
802.2 headers
Like all LAN protocols in the IEEE 802 family, 802.11 permits the use of the 802.2 protocol for Logical Link Control (LLC).
The 802.2 header, usually called the LLC, contains information about the protocol type of the packet.
These 802.2 headers are either 3 bytes or 8 bytes long.
The first section of the LLC header is 3 bytes long and contains two LSAP values and one LSAP command.
These LSAP values can either contain information about the protocol of the packet,
or they can point to the optional 5 byte SNAP section that follows.
If they point to the SNAP section of the header then the protocol is described by this 5 byte Protocol Discriminator or SNAP ID.