一、TCP/IP參考模型
ISO制定的OSI參考模型的過於龐大、複雜招致了許多批評。與此對照，由技術人員自己開發的TCP/IP協議棧獲得了更爲廣泛的應用。如圖2-1所示，是TCP/IP參考模型和OSI參考模型的對比示意圖。
圖2-1 TCP/IP參考模型
2.1 TCP/IP參考模型的層次結構
TCP/IP協議棧是美國國防部高級研究計劃局計算機網（AdvancedResearch Projects Agency Network，ARPANET）和其後繼因特網使用的參考模型。ARPANET是由美國國防部（U.S．Departmentof Defense，DoD）贊助的研究網絡。最初，它只連接了美國境內的四所大學。隨後的幾年中，它通過租用的電話線連接了數百所大學和政府部門。最終ARPANET發展成爲全球規模最大的互連網絡-因特網。最初的ARPANET於1990年永久性地關閉。
TCP/IP參考模型分爲四個層次：應用層、傳輸層、網絡互連層和主機到網絡層。如圖2-2所示。
圖2-2 TCP/IP參考模型的層次結構
在TCP/IP參考模型中，去掉了OSI參考模型中的會話層和表示層（這兩層的功能被合併到應用層實現）。同時將OSI參考模型中的數據鏈路層和物理層合併爲主機到網絡層。下面，分別介紹各層的主要功能。
1、主機到網絡層
實際上TCP/IP參考模型沒有真正描述這一層的實現，只是要求能夠提供給其上層-網絡互連層一個訪問接口，以便在其上傳遞IP分組。由於這一層次未被定義，所以其具體的實現方法將隨着網絡類型的不同而不同。
2、網絡互連層
網絡互連層是整個TCP/IP協議棧的核心。它的功能是把分組發往目標網絡或主機。同時，爲了儘快地發送分組，可能需要沿不同的路徑同時進行分組傳遞。因此，分組到達的順序和發送的順序可能不同，這就需要上層必須對分組進行排序。
網絡互連層定義了分組格式和協議，即IP協議（Internet Protocol）。
網絡互連層除了需要完成路由的功能外，也可以完成將不同類型的網絡（異構網）互連的任務。除此之外，網絡互連層還需要完成擁塞控制的功能。
3、傳輸層
在TCP/IP模型中，傳輸層的功能是使源端主機和目標端主機上的對等實體可以進行會話。在傳輸層定義了兩種服務質量不同的協議。即：傳輸控制協議TCP（transmissioncontrol protocol）和用戶數據報協議UDP（user datagram protocol）。
TCP協議是一個面向連接的、可靠的協議。它將一臺主機發出的字節流無差錯地發往互聯網上的其他主機。在發送端，它負責把上層傳送下來的字節流分成報文段並傳遞給下層。在接收端，它負責把收到的報文進行重組後遞交給上層。TCP協議還要處理端到端的流量控制，以避免緩慢接收的接收方沒有足夠的緩衝區接收發送方發送的大量數據。
UDP協議是一個不可靠的、無連接協議，主要適用於不需要對報文進行排序和流量控制的場合。
4、應用層
TCP/IP模型將OSI參考模型中的會話層和表示層的功能合併到應用層實現。
應用層面向不同的網絡應用引入了不同的應用層協議。其中，有基於TCP協議的，如文件傳輸協議（File Transfer Protocol，FTP）、虛擬終端協議（TELNET）、超文本鏈接協議（Hyper Text Transfer Protocol，HTTP），也有基於UDP協議的。
2.2 TCP/IP報文格式
1、IP報文格式
IP協議是TCP/IP協議族中最爲核心的協議。它提供不可靠、無連接的服務，也即依賴其他層的協議進行差錯控制。在局域網環境，IP協議往往被封裝在以太網幀中傳送。而所有的TCP、UDP、ICMP、IGMP數據都被封裝在IP數據報中傳送。如圖2-3所示：
圖2-3 TCP/IP報文封裝
圖2-4是IP頭部（報頭）格式：（RFC 791）。
圖2-4 IP頭部格式
其中：
●版本（Version）字段：佔4比特。用來表明IP協議實現的版本號，當前一般爲IPv4，即0100。
●報頭長度（InternetHeader Length，IHL）字段：佔4比特。是頭部佔32比特的數字，包括可選項。普通IP數據報（沒有任何選項），該字段的值是5，即160比特=20字節。此字段最大值爲60字節。
●服務類型（Typeof Service，TOS）字段：佔8比特。其中前3比特爲優先權子字段（Precedence，現已被忽略）。第8比特保留未用。第4至第7比特分別代表延遲、吞吐量、可靠性和花費。當它們取值爲1時分別代表要求最小時延、最大吞吐量、最高可靠性和最小費用。這4比特的服務類型中只能置其中1比特爲1。可以全爲0，若全爲0則表示一般服務。服務類型字段聲明瞭數據報被網絡系統傳輸時可以被怎樣處理。例如：TELNET協議可能要求有最小的延遲，FTP協議（數據）可能要求有最大吞吐量，SNMP協議可能要求有最高可靠性，NNTP（Network News Transfer Protocol，網絡新聞傳輸協議）可能要求最小費用，而ICMP協議可能無特殊要求（4比特全爲0）。實際上，大部分主機會忽略這個字段，但一些動態路由協議如OSPF（Open Shortest Path First Protocol）、IS-IS（Intermediate System to Intermediate System Protocol）可以根據這些字段的值進行路由決策。
●總長度字段：佔16比特。指明整個數據報的長度（以字節爲單位）。最大長度爲65535字節。
●標誌字段：佔16比特。用來唯一地標識主機發送的每一份數據報。通常每發一份報文，它的值會加1。
●標誌位字段：佔3比特。標誌一份數據報是否要求分段。
●段偏移字段：佔13比特。如果一份數據報要求分段的話，此字段指明該段偏移距原始數據報開始的位置。
●生存期（TTL：Time to Live）字段：佔8比特。用來設置數據報最多可以經過的路由器數。由發送數據的源主機設置，通常爲32、64、128等。每經過一個路由器，其值減1，直到0時該數據報被丟棄。
●協議字段：佔8比特。指明IP層所封裝的上層協議類型，如ICMP（1）、IGMP（2） 、TCP（6）、UDP（17）等。
●頭部校驗和字段：佔16比特。內容是根據IP頭部計算得到的校驗和碼。計算方法是：對頭部中每個16比特進行二進制反碼求和。（和ICMP、IGMP、TCP、UDP不同，IP不對頭部後的數據進行校驗）。
●源IP地址、目標IP地址字段：各佔32比特。用來標明發送IP數據報文的源主機地址和接收IP報文的目標主機地址。
可選項字段：佔32比特。用來定義一些任選項：如記錄路徑、時間戳等。這些選項很少被使用，同時並不是所有主機和路由器都支持這些選項。可選項字段的長度必須是32比特的整數倍，如果不足，必須填充0以達到此長度要求。
2、TCP數據段格式
TCP是一種可靠的、面向連接的字節流服務。源主機在傳送數據前需要先和目標主機建立連接。然後，在此連接上，被編號的數據段按序收發。同時，要求對每個數據段進行確認，保證了可靠性。如果在指定的時間內沒有收到目標主機對所發數據段的確認，源主機將再次發送該數據段。
如圖2-5所示，是TCP頭部結構（RFC 793、1323）。
圖2-5 TCP頭部結構
●源、目標端口號字段：佔16比特。TCP協議通過使用"端口"來標識源端和目標端的應用進程。端口號可以使用0到65535之間的任何數字。在收到服務請求時，操作系統動態地爲客戶端的應用程序分配端口號。在服務器端，每種服務在"衆所周知的端口"（Well-KnowPort）爲用戶提供服務。
●順序號字段：佔32比特。用來標識從TCP源端向TCP目標端發送的數據字節流，它表示在這個報文段中的第一個數據字節。
●確認號字段：佔32比特。只有ACK標誌爲1時，確認號字段纔有效。它包含目標端所期望收到源端的下一個數據字節。
●頭部長度字段：佔4比特。給出頭部佔32比特的數目。沒有任何選項字段的TCP頭部長度爲20字節；最多可以有60字節的TCP頭部。
●標誌位字段（U、A、P、R、S、F）：佔6比特。各比特的含義如下：
◆URG：緊急指針（urgent pointer）有效。
◆ACK：確認序號有效。
◆PSH：接收方應該儘快將這個報文段交給應用層。
◆RST：重建連接。
◆SYN：發起一個連接。
◆FIN：釋放一個連接。
●窗口大小字段：佔16比特。此字段用來進行流量控制。單位爲字節數，這個值是本機期望一次接收的字節數。
●TCP校驗和字段：佔16比特。對整個TCP報文段，即TCP頭部和TCP數據進行校驗和計算，並由目標端進行驗證。
●緊急指針字段：佔16比特。它是一個偏移量，和序號字段中的值相加表示緊急數據最後一個字節的序號。
●選項字段：佔32比特。可能包括"窗口擴大因子"、"時間戳"等選項。
3、UDP數據段格式
UDP是一種不可靠的、無連接的數據報服務。源主機在傳送數據前不需要和目標主機建立連接。數據被冠以源、目標端口號等UDP報頭字段後直接發往目的主機。這時，每個數據段的可靠性依靠上層協議來保證。在傳送數據較少、較小的情況下，UDP比TCP更加高效。
如圖2-6所示，是UDP頭部結構（RFC 793、1323）：
●源、目標端口號字段：佔16比特。作用與TCP數據段中的端口號字段相同，用來標識源端和目標端的應用進程。
●長度字段：佔16比特。標明UDP頭部和UDP數據的總長度字節。
●校驗和字段：佔16比特。用來對UDP頭部和UDP數據進行校驗。和TCP不同的是，對UDP來說，此字段是可選項，而TCP數據段中的校驗和字段是必須有的。
2.3 套接字
在每個TCP、UDP數據段中都包含源端口和目標端口字段。有時，我們把一個IP地址和一個端口號合稱爲一個套接字（Socket），而一個套接字對（Socket pair）可以唯一地確定互連網絡中每個TCP連接的雙方（客戶IP地址、客戶端口號、服務器IP地址、服務器端口號）。
如圖2-7所示，是常見的一些協議和它們對應的服務端口號。
圖2-7 常見協議和對應的端口號
需要注意的是，不同的應用層協議可能基於不同的傳輸層協議，如FTP、TELNET、SMTP協議基於可靠的TCP協議。TFTP、SNMP、RIP基於不可靠的UDP協議。
同時，有些應用層協議佔用了兩個不同的端口號，如FTP的20、21端口，SNMP的161、162端口。這些應用層協議在不同的端口提供不同的功能。如FTP的21端口用來偵聽用戶的連接請求，而20端口用來傳送用戶的文件數據。再如，SNMP的161端口用於SNMP管理進程獲取SNMP代理的數據，而162端口用於SNMP代理主動向SNMP管理進程發送數據。
還有一些協議使用了傳輸層的不同協議提供的服務。如DNS協議同時使用了TCP 53端口和UDP 53端口。DNS協議在UDP的53端口提供域名解析服務，在TCP的53端口提供DNS區域文件傳輸服務。
2.4 TCP連接建立、釋放時的握手過程
1、TCP建立連接的三次握手過程
TCP會話通過三次握手來初始化。三次握手的目標是使數據段的發送和接收同步。同時也向其他主機表明其一次可接收的數據量（窗口大小），並建立邏輯連接。這三次握手的過程可以簡述如下：
（1）源主機發送一個同步標誌位（SYN）置1的TCP數據段。此段中同時標明初始序號（Initial Sequence Number，ISN）。ISN是一個隨時間變化的隨機值。（客戶端A發送SYN包（SYN=j）到服務器B，並進入SYN_SEND狀態，等待服務器B確認。）
（2）目標主機發回確認數據段，此段中的同步標誌位（SYN）同樣被置1，且確認標誌位（ACK）也置1，同時在確認序號字段表明目標主機期待收到源主機下一個數據段的序號（即表明前一個數據段已收到並且沒有錯誤）。此外，此段中還包含目標主機的段初始序號。（服務器B收到SYN包，必須確認客戶A的SYN（ACK=j+1），同時自己也發送一個SYN包（SYN=k），即SYN+ACK包，此時服務器B進入SYN_RECV狀態。）
（3）源主機再回送一個數據段，同樣帶有遞增的發送序號和確認序號。 （客戶端A收到服務器B的SYN＋ACK包，向服務器B發送確認包ACK（ACK=k+1），此包發送完畢，客戶端A和服務器B進入ESTABLISHED狀態，完成三次握手。）
至此爲止，TCP會話的三次握手完成。接下來，源主機和目標主機可以互相收發數據。整個過程可用圖2-8表示。
2、TCP釋放連接的四次握手過程
（1）客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送（報文段4）。
（2）服務器B收到這個FIN，它發回一個ACK，確認序號爲收到的序號加1（報文段5）。和SYN一樣，一個FIN將佔用一個序號。
（3）服務器B關閉與客戶端A的連接，發送一個FIN給客戶端A（報文段6）。
（4）客戶端A發回ACK報文確認，並將確認序號設置爲收到序號加1（報文段7）。
TCP採用四次揮手關閉連接如圖2所
圖2 TCP四次揮手關閉連接
TCP連接的釋放：
雖然TCP連接是全雙工的，但是爲了理解TCP連接的釋放過程，最好將TCP連接看成一對單工連接。每個單工連接放單獨釋放，兩個單工連接相互獨立。爲了釋放一個連接，任何一方都可以發送一個設置了FIN位的TCP數據段，這表示它已經沒有數據要發送了。當FIN數據段被確認的時候，這個方向上就停止傳送新數據。然而，另一個方向上可能還在繼續無限制地傳送數據。當兩個方向都停止的時候，連接才被釋放。通常情況下，爲了釋放一個連接，需要4個TCP數據段：每個方向上一個FIN和一個ACK。然而，第一個ACK和第二個FIN有可能被包含在同一個數據段中，從而將總數降低到3個。
如果在兩倍最大分組生存期內FIN的應答沒有到達的話，FIN的發送方就會直接釋放連接。另一方最終也會注意到，好像對方已經不再監聽該連接了，因而也會超時。雖然理論上不完美，但實際中很少出現問題。
TCP連接的
1．爲什麼建立連接協議是三次握手，而關閉連接卻是四次握手呢？
這是因爲服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文裏來發送。但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之後，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這裏的ACK報文和FIN報文多數情況下都是分開發送的。
2．爲什麼TIME_WAIT狀態還需要等2MSL後才能返回到CLOSED狀態？
這是因爲雖然雙方都同意關閉連接了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到ESTABLISH狀態那樣）；但是因爲我們必須要假想網絡是不可靠的，你無法保證你最後發送的ACK報文會一定被對方收到，因此對方處於LAST_ACK狀態下的SOCKET可能會因爲超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。
來源： <http://blog.csdn.net/ysdaniel/article/details/6636687>
來源： <http://www.cnblogs.com/BlueTzar/articles/811160.html>
2MSL
MSL是MaximumSegment Lifetime英文的縮寫，中文可以譯爲“報文最大生存時間”，他是任何報文在網絡上存在的最長時間，超過這個時間報文將被丟棄。因爲tcp報文（segment）是ip數據報（datagram）的數據部分，具體稱謂請參見《數據在網絡各層中的稱呼》一文，而ip頭中有一個TTL域，TTL是time to live的縮寫，中文可以譯爲“生存時間”，這個生存時間是由源主機設置初始值但不是存的具體時間，而是存儲了一個ip數據報可以經過的最大路由數，每經過一個處理他的路由器此值就減1，當此值爲0則數據報將被丟棄，同時發送ICMP報文通知源主機。RFC 793中規定MSL爲2分鐘，實際應用中常用的是30秒，1分鐘和2分鐘等。
2MSL即兩倍的MSL，TCP的TIME_WAIT狀態也稱爲2MSL等待狀態，當TCP的一端發起主動關閉，在發出最後一個ACK包後，即第3次握手完成後發送了第四次握手的ACK包後就進入了TIME_WAIT狀態，必須在此狀態上停留兩倍的MSL時間，等待2MSL時間主要目的是怕最後一個ACK包對方沒收到，那麼對方在超時後將重發第三次握手的FIN包，主動關閉端接到重發的FIN包後可以再發一個ACK應答包。在TIME_WAIT狀態時兩端的端口不能使用，要等到2MSL時間結束纔可繼續使用。當連接處於2MSL等待階段時任何遲到的報文段都將被丟棄。不過在實際應用中可以通過設置SO_REUSEADDR選項達到不必等待2MSL時間結束再使用此端口。
二、IP地址
1． A類IP地址
一個A類IP地址由1字節的網絡地址和3字節主機地址組成，網絡地址的最高位必須是“0”，
地址範圍從1.0.0.0到126.0.0.0。可用的A類網絡有126個，每個網絡能容納1億多個主機。
2． B類IP地址
一個B類IP地址由2個字節的網絡地址和2個字節的主機地址組成，網絡地址的最高位必須是“10”，
地址範圍從128.0.0.0到191.255.255.255。可用的B類網絡有16382個，每個網絡能容納6萬多個主機 。
3． C類IP地址
一個C類IP地址由3字節的網絡地址和1字節的主機地址組成，網絡地址的最高位必須是“110”。
範圍從192.0.0.0到223.255.255.255。C類網絡可達209萬餘個，每個網絡能容納254個主機。
4． D類地址用於多點廣播（Multicast）。
D類IP地址第一個字節以“lll0”開始，它是一個專門保留的地址。它並不指向特定的網絡，目前這一類地址被用在多點廣播（Multicast）中。多點廣播地址用來一次尋址一組計算機，它標識共享同一協議的一組計算機。
5． E類IP地址
以“llll0”開始，爲將來使用保留。
全零（“0．0．0．0”）地址對應於當前主機。全“1”的IP地址（“255．255．255．255”）是當前子網的廣播地址。
在IP地址3種主要類型裏，各保留了3個區域作爲私有地址，其地址範圍如下：
A類地址：10.0.0.0～10.255.255.255
B類地址：172.16.0.0～172.31.255.255
C類地址：192.168.0.0～192.168.255.255
A類地址的第一組數字爲1～126。注意，數字0和 127不作爲A類地址，數字127保留給內部回送函數，而數字0則表示該地址是本地宿主機，不能傳送。
B類地址的第一組數字爲128～191。
C類地址的第一組數字爲192～223。
三、ARP協議
前言：ARP協議的作用：
1. 什麼是ARP?
ARP (Address Resolution Protocol) 是個地址解析協議。最直白的說法是：在IP以太網中，當一個上層協議要發包時，有了該節點的IP地址，ARP就能提供該節點的MAC地址。
2爲什麼要有ARP？
OSI 模式把網絡工作分爲七層，彼此不直接打交道，只通過接口(layre interface). IP地址在第三層, MAC地址在第二層。
協議在發生數據包時，首先要封裝第三層 （IP地址）和第二層（MAC地址）的報頭, 但協議只知道目的節點的IP地址，不知道其物理地址，又不能跨第二、三層，所以得用ARP的服務。
詳細說明：
Ø 在網絡通訊時，源主機的應用程序知道目的主機的IP地址和端口號，卻不知道目的主機的硬件地址，而數據包首先是被網卡接收到再去處理上層協議的，如果接收到的數據包的硬件地址與本機不符，則直接丟棄。因此在通訊前必須獲得目的主機的硬件地址。ARP協議就起到這個作用
Ø 當一臺主機把以太網數據幀發送到位於同一局域網上的另一臺主機時，是根據 48位的以太網地址來確定目的接口的，設備驅動程序從不檢查 IP數據報中的目的IP地址。ARP（地址解析）模塊的功能爲這兩種不同的地址形式提供映射：32位的 IP地址和 48位的以太網地址（也就是MAC地址）
一.ARP報文各字段含義：
ARP報文字段總共有28個字節
1.硬件類型：佔2個字節，表明ARP實現在何種類型的網絡上。
Ø 值爲1：表示以太網。
2.協議類型：佔2個字節表示要映射的協議地址類型。
Ø IP:0800
3.硬件地址長度：佔1個字節，表示 MAC地址長度，其值爲6個字節。
4.協議地址長度：佔1個字節，表示IP地址長度，此處值4個字節
5.操作類型 ：佔2個字節，表示ARP數據包類型。
Ø 值爲1表示ARP請求。
Ø 值2表示ARP應答。
6.源MAC地址：佔6個字節，表示發送端MAC地址
7.源IP地址:佔4個字節，表示發送端IP地址
8.目的以太網地址：佔6個字節，表示目標設備的MAC物理地址
9.目的IP地址：佔4個字節，表示目標設備的IP地址.
注意：在ARP操作中，有效數據的長度爲28個字節，不足以太網的最小長度46字節長度，需要填充字節，填充字節最小長度爲18個字節
二.ARP請求分組或應答分組
以太網首部總共有14字節數據，arp請求報文總共有28字節。所以一個ARP請求分組或應答分組總共有46字節數據。
而以太網數據包的最小數據爲60字節。所以，要對其進行填充。
這裏有一些重複信息
1. 在以太網的數據幀報頭中和ARP請求數據幀中都有發送端的MAC物理地址。
2. 在發送ARP請求時，以太網幀頭中的目的MAC物理地址爲FF-FF-FF-FF-FF-FF,而在ARP幀中的目的MAC處此時爲空。
3. 對一個ARP請求來說，除ARP中目的端MAC硬件地址外的所有其他的字段都有填充值。當系統收到一份目的端爲本地的ARP請求報文後，它就把硬件地址填進去，然後用兩個目的端地址分別替換兩個發送端地址，並把操作字段置爲2，最後發送出去。
三.ARP協議工作過程：
1. 原理：(ARP協議只使用於局域網中)
1> 在局域網中，網絡中實際傳輸的是“幀”，幀裏面是有目標主機的MAC地址的。
2> 在以太網中，一個主機要和另一個主機進行直接通信，必須要知道目標主機的MAC地址。但這個目標MAC地址是如何獲得呢？它就是通過地址解析協議獲得的。所謂“地址解析”就是主機在發送幀前將目標IP地址轉換成目標MAC地址的過程。
3> ARP協議的基本功能就是通過目標設備的IP地址，查詢目標設備的MAC地址，以保證通信的順利進行。
4> 點對點的連接是不需要ARP協議的
2. 工作過程：
1> 當主機A向本局域網上的某個主機B發送IP數據報時，就先在自己的ARP緩衝表中查看有無主機B的IP地址。
2> 如果有，就可以查出其對應的硬件地址，再將此硬件地址寫入MAC幀，然後通過以太網將數據包發送到目的主機中。
3> 如果查不到主機B的IP地址的表項。可能是主機B才入網，也可能是主機A剛剛加電。其高速緩衝表還是空的。在這中情況下，主機A就自動運行ARP。
(1)ARP進程在本局域網上廣播一個ARP請求分組。ARP請求分組的主要內容是表明：我的IP地址是192.168.0.2，我的硬件地址是00-00-C0-15-AD-18.我想知道IP地址爲192.168.0.4的主機的硬件地址。
(2)在本局域網上的所有主機上運行的ARP進行都收到此ARP請求分組。
(3)主機B在ARP請求分組中見到自己的IP地址，就向主機A發送ARP響應分組，並寫入自己的硬件地址。其餘的所有主機都不理睬這個ARP請求分組。ARP響應分組的主要內容是表明：“我的IP地址是192.168.0.4,我的硬件地址是08-00-2B-00-EE-AA”,請注意：雖然ARP請求分組是廣播發送的，但ARP響應分組是普通的單播，即從一個源地址發送到一個目的地址。
(4)主機A收到主機B的ARP響應分組後，就在其ARP高速緩衝表中寫入主機B的IP地址到硬件地址的映射。
3. 事例說明：用ping說明ARP工作的原理
假設我們的計算機IP地址是192.168.1.1，要執行這個命令：ping192.168.1.2。該命令會通過ICMP協議發送ICMP(以太網控制報文協議)數據包
該過程需要經過下面的步驟：
1> 應用程序構造數據包，該示例是產生ICMP包，被提交給內核（網絡驅動程序）；
2> 內核檢查是否能夠轉化該IP地址爲MAC地址，也就是在本地的ARP緩存中查看IP-MAC對應表;
3> 如果存在該IP-MAC對應關係，那麼跳到步驟<7；
如果不存在該IP-MAC對應關係，那麼接續下面的步驟;
4> 內核進行ARP廣播，目的MAC地址是FF-FF-FF-FF-FF-FF，ARP命令類型爲REQUEST（1），其中包含有自己的MAC地址；
5> 當192.168.1.2主機接收到該ARP請求後，就發送一個ARP的REPLY（2）命令，其中包含自己的MAC地址；
6> 本地獲得192.168.1.2主機的IP-MAC地址對應關係，並保存到ARP緩存中；
7> 內核將把IP轉化爲MAC地址，然後封裝在以太網頭結構中，再把數據發送出去；
4. 特殊情況：
ARP是解決同一個局域網上的主機或路由器的IP地址和硬件地址的映射問題。如果所要找的目標設備和源主機不在同一個局域網上。
1>此時主機A就無法解析出主機B的硬件地址（實際上主機A也不需要知道遠程主機B的硬件地址）;
2>此時主機A需要的是將路由器R1的IP地址解析出來，然後將該IP數據報發送給路由器R1.
3>R1從路由表中找出下一跳路由器R2，同時使用ARP解析出R2的硬件地址。於是IP數據報按照路由器R2的硬件地址轉發到路由器R2。
4>路由器R2在轉發這個IP數據報時用類似方法解析出目的主機B的硬件地址，使IP數據報最終交付給主機B.
說明：
Ø 如果你的數據包是發送到不同網段的目的地，那麼就一定存在一條網關的IP-MAC地址對應的記錄。
Ø 知道了ARP協議的作用，就能夠很清楚地知道，數據包的向外傳輸很依靠ARP協議，當然，也就是依賴ARP緩存。要知道，ARP協議的所有操作都是內核自動完成的，同其他的應用程序沒有任何關係。同時需要注意的是，ARP協議只使用於本網絡。
四.ARP緩衝表和TTL
1. ARP緩衝表
1> ARP協議的本質是完成網絡地址到物理地址的映射。從概念上將就是找到一個映射方法f,使得“物理地址 = f(網絡地址)“。物理地址有兩種基本類型：以太網類型和令牌環網類型。網絡地址特指IP地址，對映射方法的要求就是高效。具體到以太網，它使用的是動態綁定轉換的方法。一般是設置ARP高速緩存，通過學習，老化，更新，溢出算法處理ARP映射表來解決這些問題。
Ø 學習指ARP收到任何指向本結點IP地址的ARP/IP包，從中提取出地址對，當ARP緩衝表中無對應項時，由ARP接收部分添加；
Ø 老化指爲每項設置壽命域，以便代謝掉陳舊的地址映射項；
Ø 更新指ARP提取到新的地址對時，用其更新緩存裏已有的對應項；
Ø 溢出算法指當緩存慢時，採取何種方法替代舊有的地址對。
2> ARP緩存表由狀態，壽命，IP地址，MAC地址4個字段組成。狀態字段指示地址對是否有效；壽命字段用於老化操作，初始存入最大值，以後由OS時間函數調用，每秒減1，直至爲0清除；IP地址和MAC地址字段保存網絡地址和物理地址的映射。圍繞ARP緩存表，完成了4種操作：學習，老化，更新，表滿處理。
3> 當ARP被詢問一個已只IP地址節點的MAC地址時，先在ARPcache 查看
l 若存在，就直接返回MAC地址，
l 若不存在，才發送ARP request向局域網查詢。
4> 當主機A向B發送數據報時，很可能以後不久主機B還要向A發送數據報，因而主機B可能要向A發送ARP請求分組。
所以，爲了減少網絡上的通信量，主機A在發送其ARP請求分組時，就將自己的IP地址到硬件地址的寫入主機B自己的ARP高速緩衝表中。這對主機B以後向A發送數據報時就更方便了。
Tiger 說明：
任何事物都有兩面性，如果掌握的好它就是天使，如果掌握的不好它就是Satan,ARP中的緩衝表爲計算機之間的通信效率和減少網絡通信量之間作出了巨大的貢獻，但是它同時爲我們上網時留下了安全隱患；例如交換機嗅探(在下面會有介紹)
2. ARP中的TTL（即上面所說的壽命域）
ARP將保存在高速緩衝表中的每一個映射地址表項都設置了TTL(生存時間)，只要TTL小於0的項目就從高速緩衝表中刪除掉。
(ARP的超時值一般爲20分鐘，對不完整的表項設置爲20分鐘，而對不完整的表項設置爲2分鐘《不完整的表項：即在以太網上對一個不存在的主機發出ARP請求》，當這些表項再次使用時，這些實現一般都把超時值重新設爲20分鐘。)
好處：主機A和B通信。A的ARP高速緩衝表裏保存有B的物理地址。但B的網卡突然壞了，B立即就更換了一塊，因此B的硬件地址就改變了。A還要和B繼續通信。A在其ARP緩衝表中查找到B原先的硬件地址，並使用該硬件地址向B發送數據幀。但B原先的硬件地址已經失效了。因此A無法找到主機B。但是過了一段時間，A的ARP高速緩衝表中已經刪除了B原先的硬件地址（因爲它的生存時間到了），於是A重新光播發送ARP請求分組，又找到了B。
六ARP其他方面
1.交換網絡的嗅探
1>1.ARP協議並不只在發送了ARP請求才接收ARP應答
當計算機接收到ARP應答數據包的時候，就會對本地的ARP緩存進行更新，將應答中的IP和MAC地址存儲在ARP緩存中。
因此，在上面的假設網絡中，B向A發送一個自己僞造的ARP應答，而這個應答中的數據爲發送方IP地址是192.168.10.3（C的IP地址），MAC地址是DD-DD-DD-DD-DD-DD（C的MAC地址本來應該是CC-CC-CC-CC-CC-CC，這裏被僞造了）。當A接收到B僞造的ARP應答，就會更新本地的ARP緩存，將本地的IP-MAC對應表更換爲接收到的數據格式，由於這一切都是A的系統內核自動完成的，A可不知道被僞造了。ARP欺騙的主要用途就是進行在交換網絡中的嗅探。
2.IP地址衝突
1>如果網絡中存在相同IP地址的主機時候，就會報告出IP地址衝突的警告。
2>如何產生？
Ø 比如某主機B規定IP地址爲192.168.0.1，如果它處於開機狀態，那麼其他機器A更該IP地址爲192.168.0.1就會造成IP地址衝突。
Ø 其原理是：主機A在連接網路（或更改IP地址）的時候就會向網絡發送ARP包廣播自己的IP地址，也就是free arp(免費ARP).如果網絡中存在相同IP地址的主機B，那麼B就會通過ARP來reply該地址，當A接收到這個reply後，A就會跳出IP地址衝突的警告，當然B也會有警告。因此用ARP欺騙可以來僞造這個ARPreply，從而使目標一直遭受IP地址衝突警告的困擾。
3.阻止目標的數據包通過網關
1>比如在一個局域網內通過網管上網，那麼連接外部的計算機上的ARP緩存中就存在網管IP-MAC對應記錄
2>如果，該記錄被更改，那麼該計算機向外發送的數據包總是發送到了錯誤的網關硬件地址上，這樣，該計算機就不能上網了。
3>這裏也主要是通過ARP欺騙進行的。有兩種方法達到這樣的目的：
Ø 向目標發送僞造的ARP應答數據包，其中發送方的IP地址爲網管的地址，而MAC地址則爲一個僞造的地址。當目標接收到ARP包，那麼就更新自身的ARP緩存。如果該欺騙一直持續下去，那麼目標的網管緩存一直是一個被僞造的錯誤記錄。不過，如果使用arp –a,就知道問題所在了。
Ø 第二種方法是欺騙網管。向網管發送僞造的ARP應答數據包，其中發送方的IP地址爲目標的IP地址，而MAC地址則爲一個僞造的地址。這樣，網管上的目標ARP記錄就是一個錯誤的，網管發送給目標的數據報都是使用了錯誤的MAC地址。這種情況下，目標能夠發送數據到網管，卻不能接收到網管的任何數據。同時，目標自己查看arp –a卻看不出任何問題來。
四、ICMP協議
ICMP是“Internet Control Message Protocol”的縮寫，中文稱“互聯網控制消息協議”，是用於在 TCP/IP 網絡中發送控制消息，提供可能發生在通信環境中的各種問題反饋，通過這些信息，令管理者可以對所發生的問題作出診斷，然後採取適當的措施去解決它。ICMP 依靠IP來完成它的任務，它是IP的主要部分。
ICMP概述
ICMP協議是一種面向連接的協議，用於傳輸出錯報告控制信息。它是一個非常重要的協議，它對於網絡安全具有極其重要的意義。
它是TCP/IP協議族的一個子協議,屬於網絡層協議,主要用於在主機與路由器之間傳遞控制信息,包括報告錯誤、交換受限控制和狀態信息等。當遇到IP數據無法訪問目標、IP路由器無法按當前的傳輸速率轉發數據包等情況時，會自動發送ICMP消息ICMP提供一致易懂的出錯報告信息。發送的出錯報文返回到發送原數據的設備，因爲只有發送設備纔是出錯報文的邏輯接受者。發送設備隨後可根據ICMP報文確定發生錯誤的類型，並確定如何才能更好地重發失敗的數據報。但是ICMP唯一的功能是報告問題而不是糾正錯誤，糾正錯誤的任務由發送方完成。
每個ICMP消息都是直接封裝在一個IP數據報中的，因此，和UDP一樣，ICMP是不可靠的。雖然ICMP是包含在IP數據報中的，但是對ICMP消息通常會特殊處理，會和一般IP數據報的處理不同，而不是作爲IP的一個子協議來處理。在很多時候，需要去查看ICMP消息的內容，然後發送適當的錯誤消息到那個原來產生IP數據包的程序，即那個導致ICMP訊息被傳送的IP數據包。
我們在網絡中經常會使用到ICMP協議，比如我們經常使用的用於檢查網絡通不通的Ping命令（Linux和Windows中均有），這個“Ping”的過程實際上就是ICMP協議工作的過程。還有其他的網絡命令如跟蹤路由的Tracert命令也是基於ICMP協議的。
一.概述：
1. ICMP允許主機或路由報告差錯情況和提供有關異常情況。ICMP是因特網的標準協議，但ICMP不是高層協議，而是IP層的協議。通常ICMP報文被IP層或更高層協議（TCP或UDP）使用。一些ICMP報文把差錯報文返回給用戶進程。
2. ICMP報文作爲IP層數據報的數據，加上數據報的首部，組成數據報發送出去。
3. ICMP報文的種類有兩種，即ICMP差錯報告報文和ICMP詢問報文。
二.ICMP報文的格式
1. 類型：佔8位
2. 代碼：佔8位
3. 檢驗和：佔16位
說明：ICMP所有報文的前4個字節都是一樣的，但是剩下的其他字節則互不相同。
4. 其它字段都ICMP報文類型不同而不同。
1> ICMP報文的前4個字節是統一的格式，共有三個字段：即類型，代碼和檢驗和。
2> 8位類型和8位代碼字段一起決定了ICMP報文的類型。
類型8，代碼0：表示回顯請求(ping請求)。
類型0，代碼0：表示回顯應答(ping應答)
類型11，代碼0：超時
3>16位的檢驗和字段：包括數據在內的整個ICMP數據包的檢驗和；其計算方法和IP頭部檢驗和的計算方法一樣的。
ICMP報文具體分爲查詢報文和差錯報文(對ICMP差錯報文有時需要做特殊處理，因此要對其進行區分。如：對ICMP差錯報文進行響應時，永遠不會生成另一份ICMP差錯報文，否則會出現死循環)
三.ICMP差錯報文(56字節)
1. ICMP差錯報告報文共有5種
1> 終點不可達：終點不可達分爲:網絡不可達，主機不可達，協議不可達，端口不可達，需要分片但DF比特已置爲1，以及源路由失敗等六種情況，其代碼字段分別置爲0至5。當出現以上六種情況時就向源站發送終點不可達報文。
說明：
端口不可達：UDP的規則之一是：如果收到UDP數據報而且目的端口與某個正在使用的進程不相符，那麼UDP返回一個ICMP不可達報文。
2> 源站抑制：當路由器或主機由於擁塞而丟棄數據報時，就向源站發送源站抑制報文，使源站知道應當將數據報的發送速率放慢。
3> 時間超過：當路由器收到生存時間爲零的數據報時，除丟棄該數據報外，還要向源站發送時間超過報文。當目的站在預先規定的時間內不能收到一個數據報的全部數據報片時，就將已收到的數據報片都丟棄，並向源站發送時間超過報文。
4> 參數問題：當路由器或目的主機收到的數據報的首部中的字段的值不正確時，就丟棄該數據報，並向源站發送參數問題報文。
5> 改變路由（重定向）路由器將改變路由報文發送給主機，讓主機知道下次應將數據報發送給另外的路由器。
說明:
以下幾種情況都不會導致產生ICMP差錯報文
1>ICMP差錯報文（但是，ICMP查詢報文可能會產生ICMP差錯報文）
2>目的地址是廣播地址或多播地址的IP數據報
3>作爲鏈路層廣播的數據報
4>不是IP分片的第一片
5>源地址不是單個主機的數據報。即源地址不能爲零地址、環回地址、廣播地址或多播地址。
這些規則是爲了防止過去允許ICMP差錯報文對廣播分組響應所帶來的廣播風暴。
2.所有的ICMP差錯報告報文中的數據字段都具有同樣的格式。將收到的需要進行差錯報告IP數據報的首部和數據字段的前8個字節提取出來，作爲ICMP報文的數據字段。再加上響應的ICMP差錯報告報文的前8個字節，就構成了ICMP差錯報告報文。提取收到的數據報的數據字段的前8個字節是爲了得到運輸層的端口號（對於TCP和UDP）以及運輸層報文的發送序號（對於TCP）。
注：一下情況不發送ICMP差錯報告報文
三.ICMP詢問報文（40字節）
1.ICMP詢問報文有四種回送請求和回答，時間戳請求和回答，掩碼地址請求和回答，以及路由器詢問和通過。
1>ICMP回送請求報文是由主機或路由器向一個特定的目的主機發出的詢問。收到此報文的機器必須給源主機發送ICMP回送應答報文。這種詢問報文用來測試目的站是否可達以及瞭解其有關狀態。
2>ICMP時間戳請求允許系統向另一個系統查詢當前的時間。該ICMP報文的好處是它提供了毫秒級的分辨率，而利用其他方法從別的主機獲取的時間只能提供秒級的分辨率。請求端填寫發起時間，然後發送報文。應答系統收到請求報文時填寫接收時間戳，在發送應答時填寫發送時間戳。大多數的實現是把後面兩個字段都設成相同的值。
3>主機使用ICMP地址掩碼請求報文可向子網掩碼服務器得到某個接口的地址掩碼。系統廣播它的ICMP請求報文。ICMP報文中的標識符和序列號字段由發送端任意選擇設定，這些值在應答中將被返回，這樣，發送端就可以把應答與請求進行匹配。
4>主機使用ICMP路由器詢問和通過報文可瞭解連接在本網絡上的路由器是否正常工作。主機將路由器詢問報文進行廣播（或多播）。收到詢問報文的一個或幾個路由器就使用路由器通過報文廣播其路由選擇信息
四.Ping程序
1.概述
1>Ping程序是爲了測試另一臺主機是否可達。該程序發送一份ICMP回顯請求報文給主機，並等待返回ICMP回顯應答。
2>Ping程序還能測出到這臺主機的往返時間，以表明該主機離我們有多遠。
2.我們將發送回顯請求的ping程序爲客戶，而稱被ping的主機爲服務器。
3.ICMP回顯請求和回顯應答報文格式：
1>Unix系統在實現ping程序時把ICMP報文中的標識符字段置成發送進程的ID號。這樣即使在同一臺主機上同時運行了多個ping程序實例，ping程序也可以識別出返回的信息。
2>序列號從0開始，每發送一次新的回顯請求就加1。ping程序打印出返回的每個分組的序列號，允許我們查看是否有分組丟失，失序或重複。.
3>ping程序通過在ICMP報文中存放發送請求的時間值來計算往返時間。當應答返回時，用當前時間減去存放在ICMP報文中的時間值，即是往返時間。
4>當返回ICMP回顯應答時，要打印出序列號和TTL，並計算往返時間。TTL位於IP首部的生存時間字段。ping程序通過在ICMP報文數據段中存放發送請求的時間值來計算往返時間。當應答返回時，用當前時間減去存放在ICMP報文中的時間值，即是往返時間。
五、IP分片
在TCP/IP分層中，數據鏈路層用MTU（Maximum Transmission Unit，最大傳輸單元）來限制所能傳輸的數據包大小，MTU是指一次傳送的數據最大長度，不包括數據鏈路層數據幀的幀頭，如以太網的MTU爲1500字節，實際上數據幀的最大長度爲1512字節，其中以太網數據幀的幀頭爲12字節。
當發送的IP數據報的大小超過了MTU時，IP層就需要對數據進行分片，否則數據將無法發送成功。
IP分片發生在IP層，不僅源端主機會進行分片，中間的路由器也有可能分片，因爲不同的網絡的MTU是不一樣的，如果傳輸路徑上的某個網絡的MTU比源端網絡的MTU要小，路由器就可能對IP數據報再次進行分片。而分片數據的重組只會發生在目的端的IP層。
在IP首部有4個字節是用於分片的，如下圖所示。前16位是IP數據報的標識，同一個數據報的各個分片的標識是一樣的，目的端會根據這個標識來判斷IP分片是否屬於同一個IP數據報。中間3位是標誌位，其中有1位用來表示是否有更多的分片，如果是最後一個分片，該標誌位爲0，否則爲1。後面13位表示分片在原始數據的偏移，這裏的原始數據是IP層收到的傳輸的TCP或UDP數據，不包含IP首部。
需要注意的，在分片的數據中，傳輸層的首部只會出現在第一個分片中，如下圖所示。因爲傳輸層的數據格式對IP層是透明的，傳輸層的首部只有在傳輸層纔會有它的作用，IP層不知道也不需要保證在每個分片中都有傳輸層首部。所以，在網絡上傳輸的數據包是有可能沒有傳輸層首部的。
在網絡編程中，我們要避免出現IP分片，那麼爲什麼要避免呢？原因是IP層是沒有超時重傳機制的，如果IP層對一個數據包進行了分片，只要有一個分片丟失了，只能依賴於傳輸層進行重傳，結果是所有的分片都要重傳一遍，這個代價有點大。由此可見，IP分片會大大降低傳輸層傳送數據的成功率，所以我們要避免IP分片。
對於UDP包，我們需要在應用層去限制每個包的大小，一般不要超過1472字節，即
以太網MTU（1500）—UDP首部（8）—IP首部（20）。
對於TCP數據，應用層就不需要考慮這個問題了，因爲傳輸層已經幫我們做了。在建立連接的三次握手的過程中，連接雙方會相互通告MSS（Maximum Segment Size，最大報文段長度），
MSS一般是MTU—IP首部（20）—TCP首部（20），
每次發送的TCP數據都不會超過雙方MSS的最小值，所以就保證了IP數據報不會超過MTU，避免了IP分片。
來源： <http://www.cnblogs.com/glacierh/p/3653442.html>
六、單播、廣播和組播
單播、多播和廣播單播”（Unicast）、“多播”（Multicast）和“廣播”（Broadcast）這三個術語都是用來描述網絡節點之間通訊方式的術語。那麼這些術語究竟是什麼意思？區別何在？
1.單播：網絡節點之間的通信就好像是人們之間的對話一樣。如果一個人對另外一個人說話，那麼用網絡技術的術語來描述就是“單播”，此時信息的接收和傳遞只在兩個節點之間進行。單播在網絡中得到了廣泛的應用，網絡上絕大部分的數據都是以單播的形式傳輸的，只是一般網絡用戶不知道而已。例如，你在收發電子郵件、瀏覽網頁時，必須與郵件服務器、Web服務器建立連接，此時使用的就是單播數據傳輸方式。但是通常使用“點對點通信”（Point to Point）代替“單播”，因爲“單播”一般與“多播”和“廣播”相對應使用。
單播的優點：
1）服務器及時響應客戶機的請求
2）服務器針對每個客戶不通的請求發送不通的數據，容易實現個性化服務。
單播的缺點：
1）服務器針對每個客戶機發送數據流，服務器流量＝客戶機數量×客戶機流量；在客戶數量大、每個客戶機流量大的流媒體應用中服務器不堪重負。
2）現有的網絡帶寬是金字塔結構，城際省際主幹帶寬僅僅相當於其所有用戶帶寬之和的5％。如果全部使用單播協議，將造成網絡主幹不堪重負。現在的P2P應用就已經使主幹經常阻塞。而將主幹擴展20倍幾乎是不可能。
2.多播：“多播”也可以稱爲“組播”，在網絡技術的應用並不是很多，網上視頻會議、網上視頻點播特別適合採用多播方式。因爲如果採用單播方式，逐個節點傳輸，有多少個目標節點，就會有多少次傳送過程，這種方式顯然效率極低，是不可取的；如果採用不區分目標、全部發送的廣播方式，雖然一次可以傳送完數據，但是顯然達不到區分特定數據接收對象的目的。採用多播方式，既可以實現一次傳送所有目標節點的數據，也可以達到只對特定對象傳送數據的目的。 IP網絡的多播一般通過多播IP地址來實現。多播IP地址就是D類IP地址，即224.0.0.0至239.255.255.255之間的IP地址。Windows 2000中的DHCP管理器支持多播IP地址的自動分配。
組播的優點：
1）需要相同數據流的客戶端加入相同的組共享一條數據流，節省了服務器的負載。具備廣播所具備的優點。
2）由於組播協議是根據接受者的需要對數據流進行復制轉發，所以服務端的服務總帶寬不受客戶接入端帶寬的限制。IP協議允許有2億6千多萬個組播，所以其提供的服務可以非常豐富。
3）此協議和單播協議一樣允許在Internet寬帶網上傳輸。
組播的缺點：
1）與單播協議相比沒有糾錯機制，發生丟包錯包後難以彌補，但可以通過一定的容錯機制和QOS加以彌補。
2）現行網絡雖然都支持組播的傳輸，但在客戶認證、QOS等方面還需要完善，這些缺點在理論上都有成熟的解決方案，只是需要逐步推廣應用到現存網絡當中。
3.廣播：“廣播”在網絡中的應用較多，如客戶機通過DHCP自動獲得IP地址的過程就是通過廣播來實現的。但是同單播和多播相比，廣播幾乎佔用了子網內網絡的所有帶寬。拿開會打一個比方吧，在會場上只能有一個人發言，想象一下如果所有的人同時都用麥克風發言，那會場上就會亂成一鍋粥。集線器由於其工作原理決定了不可能過濾廣播風暴，一般的交換機也沒有這一功能，不過現在有的網絡交換機（如全向的QS系列交換機）也有過濾廣播風暴功能了，路由器本身就有隔離廣播風暴的作用。 廣播風暴不能完全杜絕，但是只能在同一子網內傳播，就好像喇叭的聲音只能在同一會場內傳播一樣，因此在由幾百臺甚至上千臺電腦構成的大中型局域網中，一般進行子網劃分，就像將一個大廳用牆壁隔離成許多小廳一樣，以達到隔離廣播風暴的目的。
在IP網絡中，廣播地址用IP地址“255.255.255.255”來表示，這個IP地址代表同一子網內所有的IP地址。
廣播的優點：
1）網絡設備簡單，維護簡單，佈網成本低廉
2）由於服務器不用向每個客戶機單獨發送數據，所以服務器流量負載極低。
廣播的缺點：
1）無法針對每個客戶的要求和時間及時提供個性化服務。
2）網絡允許服務器提供數據的帶寬有限，客戶端的最大帶寬＝服務總帶寬。例如有線電視的客戶端的線路支持100個頻道（如果採用數字壓縮技術，理論上可以提供500個頻道），即使服務商有更大的財力配置更多的發送設備、改成光纖主幹，也無法超過此極限。也就是說無法向衆多客戶提供更多樣化、更加個性化的服務。
3）廣播禁止允許在Internet寬帶網上傳輸。
來源： <http://www.cnblogs.com/rogerroddick/archive/2009/08/31/1557228.html>
四種I P廣播地址
受限的廣播地址是255.255.255.255。該地址用於主機配置過程中IP數據報的目的地址，此時，主機可能還不知道它所在網絡的網絡掩碼，甚至連它的IP地址也不知道。在任何情況下，路由器都不轉發目的地址爲受限的廣播地址的數據報，這樣的數據報僅出現在本地網絡中。
指向網絡的廣播
指向網絡的廣播地址是主機號爲全1的地址。A類網絡廣播地址爲netid.255.255.255，其中netid爲A類網絡的網絡號。一個路由器必須轉發指向網絡的廣播，但它也必須有一個不進行轉發的選擇。
指向子網的廣播
指向子網的廣播地址爲主機號爲全1且有特定子網號的地址。作爲子網直接廣播地址的IP地址需要了解子網的掩碼。例如，如果路由器收到發往128.1.2.255的數據報，當B類網絡128.1的子網掩碼爲255.255.255.0時，該地址就是指向子網的廣播地址；但如果該子網的掩碼爲255.255.254.0，該地址就不是指向子網的廣播地址。
指向所有子網的廣播
指向所有子網的廣播也需要瞭解目的網絡的子網掩碼，以便與指向網絡的廣播地址區分開。指向所有子網的廣播地址的子網號及主機號爲全1。例如，如果目的子網掩碼爲255.255.255.0，那麼IP地址128.1.255.255是一個指向所有子網的廣播地址。然而，如果網絡沒有劃分子網，這就是一個指向網絡的廣播。
來源： <http://blog.sina.com.cn/s/blog_9f488855010183oy.html>
七、IGMP協議
IGMP是Internet組管理協議，它支持主機和路由器進行多播。它讓一個物理網絡上的所有系統知道主機當前所在的多播組。多播路由器需要這些信息以便知道多播數據報應該向哪些接口轉發。和ICMP一樣，IGMP也被當作IP層的一部分。IGMP報文通過IP數據報進行傳輸，有固定的報文長度，沒有可選數據。下圖顯示了IGMP報文如何封裝在IP數據報中，IGMP報文通過IP首部中協議字段值爲2來指明：
*******************************************************************************************
IGMP報文
下圖顯示了長度爲8字節的IGMP報文格式：
（1）IGMP類型爲1說明是由多播路由器發出的查詢報文，類型爲2說明是主機發出的報告報文；
（2）校驗和的計算和ICMP相同；
（3）組地址爲D類地址，查詢報文中設置爲0，報告報文中爲參加的組地址。
*******************************************************************************************
IGMP協議
==========================================================
加入一個多播組
多播的基礎就是一個進程的概念，該進程在一個主機的給定接口上加入了一個多播組。在一個給定接口上的多播組中的成員是動態的---它隨時因進程加入和離開多播組而變化。
這裏所指的進程必須以某種方式在給定的接口上加入某個多播組。進程也能離開先前加入的多播組。這些是一個支持多播主機中任何API所必須的部分。使用限定詞"接口"是因爲多播組中的成員是與接口相關聯的。
這裏暗示一個主機通過組地址和接口來識別一個多播組。主機必須保留一個表，此表中包含所有至少含有一個進程的多播組以及多播組中的進程數量。
==========================================================
IGMP報告和查詢
多播路由器使用IGMP報文來記錄與該路由器相連網絡中組員的變化情況。使用規則如下：
（1）當第一個進程加入一個組時，主機就發送一個IGMP報告。如果一個主機有多個進程加入多播組，只發送一個IGMP報告。這個報告被髮送到進程加入組所在的同一接口上；
（2）進程離開一個組的時候，主機不發送IGMP報文。主機知道在確定的組中已不再有組成員後，在隨後收到的IGMP查詢中不再發送報告報文；
（3）多播路由器定時發送IGMP查詢來了解是否還有任何主機包含屬於多播組的進程。多播路由器必須向每個接口發送一個IGMP查詢。因爲路由器希望主機對它加入的每個多播組均發回一個報告，因此IGMP查詢報文中的組地址被設置爲0；
（4）主機通過發送IGMP報告來響應一個IGMP查詢，對每個至少還包含一個進程的組均要發回IGMP報文。
使用這些查詢和報告報文，多播路由器對每個接口保持一個表，表中記錄接口上至少還包含一個主機的多播組。當路由器收到要轉發的多播數據報時，它只將該數據報轉發到還擁有屬於那個組主機的接口上。
-------------------------------------------
下面顯示了兩個IGMP報文，一個是主機發送的報文，另一個是路由器發送的查詢。該路由器正在要求那個接口上的每個主機說明它加入的每個多播組
===========================================================
實現細節
（1）當一個主機加入多播組時，並不保證它發送的第一個IGMP報告能被可靠的接收。下一個報告將在間隔一段時間後發送。這個時間間隔由主機在0～10s的範圍內隨機選擇；
（2）當一個主機收到一個從路由器發出的查詢後，並不立即響應，而是經過一定的時間間隔後才發出一些響應。因爲報告中的目的地址是組地址，所以在一個物理網絡中的所有主機將收到同組其它主機發送的所有報告。這意味着如果一個主機在等待發送報告的過程中，卻收到了發自其他主機相同的報告，則該主機響應可以不必發送。因爲多播路由器並不關心有多少主機屬於該組，而只關心該組是否還至少擁有一個主機。
===========================================================
生存時間字段
IGMP報告和查詢的TTL均設置爲1，這涉及到IP首部中的TTL字段。一個初始TTL爲0的多播數據報將被限制在同一主機中。默認情況下，待傳多播數據報的TTL被設置爲1，這將使多播數據報僅侷限在同一子網內傳送。更大的TTL值能被多播路由器轉發。
===========================================================
所有主機組
224.0.0.1被稱爲所有主機組地址。它涉及一個物理網絡中的所有具備多播能力的主機和路由器。當接口初始化後，所有具備多播能力接口上的主機均自動加入這個多播組。這個組的成員無需發送IGMP報告。
來源： <http://blog.sina.com.cn/s/blog_ac9fdc0b0101pwlu.html>
八、TCP的瓣關閉
終止一個連接要經過4次握手。這由TCP的半關閉（half-close）造成的。既然一個TCP連接是全雙工（即數據在兩個方向上能同時傳遞，可理解爲兩個方向相反的獨立通道），因此每個方向必須單獨地進行關閉。
這原則就是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向連接。當一端收到一個FIN，內核讓read返回0來通知應用層另一端已經終止了向本端的數據傳送。發送FIN通常是應用層對socket進行關閉的結果。
例如：TCP客戶端發送一個FIN，用來關閉從客戶到服務器的數據傳送。
半關閉對服務器究竟有什麼影響呢？先看看下面的TCP狀態轉化圖
tcp狀態裝換圖
客戶端主動關閉時，發出FIN包，收到服務器的ACK，客戶端停留在FIN_WAIT2狀態。而服務端收到FIN，發出ACK後，停留在COLSE_WAIT狀態。
這個CLOSE_WAIT狀態非常討厭，它持續的時間非常長，服務器端如果積攢大量的COLSE_WAIT狀態的socket，有可能將服務器資源耗盡，進而無法提供服務。
那麼，服務器上是怎麼產生大量的失去控制的COLSE_WAIT狀態的socket呢？我們來追蹤一下。
一個很淺顯的原因是，服務器沒有繼續發FIN包給客戶端。
服務器爲什麼不發FIN，可能是業務實現上的需要，現在不是發送FIN的時機，因爲服務器還有數據要發往客戶端，發送完了自然就要通過系統調用發FIN了，這個場景並不是上面我們提到的持續的COLSE_WAIT狀態，這個在受控範圍之內。
那麼究竟是什麼原因呢，咱們引入兩個系統調用close(sockfd)和shutdown(sockfd,how)接着往下分析。
在這兒，需要明確的一個概念---- 一個進程打開一個socket，然後此進程再派生子進程的時候，此socket的sockfd會被繼承。socket是系統級的對象，現在的結果是，此socket被兩個進程打開，此socket的引用計數會變成2。
繼續說上述兩個系統調用對socket的關閉情況。
調用close(sockfd)時，內核檢查此fd對應的socket上的引用計數。如果引用計數大於1，那麼將這個引用計數減1，然後返回。如果引用計數等於1，那麼內核會真正通過發FIN來關閉TCP連接。
調用shutdown(sockfd，SHUT_RDWR)時,內核不會檢查此fd對應的socket上的引用計數，直接通過發FIN來關閉TCP連接。
現在應該真相大白了，可能是服務器的實現有點問題，父進程打開了socket，然後用派生子進程來處理業務，父進程繼續對網絡請求進行監聽，永遠不會終止。客戶端發FIN過來的時候，處理業務的子進程的read返回0，子進程發現對端已經關閉了，直接調用close()對本端進行關閉。實際上，僅僅使socket的引用計數減1，socket並沒關閉。從而導致系統中又多了一個CLOSE_WAIT的socket。。。
如何避免這樣的情況發生？
子進程的關閉處理應該是這樣的：
shutdown(sockfd,SHUT_RDWR);
close(sockfd);
這樣處理，服務器的FIN會被髮出，socket進入LAST_ACK狀態，等待最後的ACK到來，就能進入初始狀態CLOSED。
補充一下shutdown()的函數說明
linux系統下使用shutdown系統調用來控制socket的關閉方式
int shutdown(intsockfd,int how);
參數 how允許爲shutdown操作選擇以下幾種方式：
SHUT_RD：關閉連接的讀端。也就是該套接字不再接受數據，任何當前在套接字接受緩衝區的數據將被丟棄。進程將不能對該套接字發出任何讀操作。對TCP套接字該調用之後接受到的任何數據將被確認然後被丟棄。
SHUT_WR:關閉連接的寫端。
SHUT_RDWR:相當於調用shutdown兩次：首先是以SHUT_RD,然後以SHUT_WR
注意:
在多進程中如果一個進程中shutdown(sfd, SHUT_RDWR)後其它的進程將無法進行通信. 如果一個進程close(sfd)將不會影響到其它進程.
同時打開和同時關閉狀態的報文段情況
儘管很難，但仍有可能產生一個同時打開的連接。兩端必須幾乎在同時啓動，以便收到彼此的S Y N。只要兩端有較長的往返時間就能保證這一點。
