一、ARP/RARP協議
1.ARP
地址解析協議，即ARP（Address Resolution Protocol），是根據IP地址獲取物理地址的一個TCP/IP協議。主機發送信息時將包含目標IP地址的ARP請求廣播到網絡上的所有主機，並接收返回消息，以此確定目標的物理地址；收到返回消息後將該IP地址和物理地址存入本機ARP緩存中並保留一定時間，下次請求時直接查詢ARP緩存以節約資源。地址解析協議是建立在網絡中各個主機互相信任的基礎上的，網絡上的主機可以自主發送ARP應答消息，其他主機收到應答報文時不會檢測該報文的真實性就會將其記入本機ARP緩存；由此攻擊者就可以向某一主機發送僞ARP應答報文，使其發送的信息無法到達預期的主機或到達錯誤的主機，這就構成了一個ARP欺騙。ARP命令可用於查詢本機ARP緩存中IP地址和MAC地址的對應關係、添加或刪除靜態對應關係等。
ARP工作流程舉例：
主機A的IP地址爲192.168.1.1，MAC地址爲0A-11-22-33-44-01；
主機B的IP地址爲192.168.1.2，MAC地址爲0A-11-22-33-44-02；
當主機A要與主機B通信時，地址解析協議可以將主機B的IP地址（192.168.1.2）解析成主機B的MAC地址，以下爲工作流程：
（1）根據主機A上的路由表內容，IP確定用於訪問主機B的轉發IP地址是192.168.1.2。然後A主機在自己的本地ARP緩存中檢查主機B的匹配MAC地址。
（2）如果主機A在ARP緩存中沒有找到映射，它將詢問192.168.1.2的硬件地址，從而將ARP請求幀廣播到本地網絡上的所有主機。源主機A的IP地址和MAC地址都包括在ARP請求中。本地網絡上的每臺主機都接收到ARP請求並且檢查是否與自己的IP地址匹配。如果主機發現請求的IP地址與自己的IP地址不匹配，它將丟棄ARP請求。
（3）主機B確定ARP請求中的IP地址與自己的IP地址匹配，則將主機A的IP地址和MAC地址映射添加到本地ARP緩存中。
（4）主機B將包含其MAC地址的ARP回覆消息直接發送回主機A。
（5）當主機A收到從主機B發來的ARP回覆消息時，會用主機B的IP和MAC地址映射更新ARP緩存。本機緩存是有生存期的，生存期結束後，將再次重複上面的過程。主機B的MAC地址一旦確定，主機A就能向主機B發送IP通信了。
2.ARRP
逆地址解析協議，即RARP，功能和ARP協議相對，其將局域網中某個主機的物理地址轉換爲IP地址 ，比如局域網中有一臺主機只知道物理地址而不知道IP地址，那麼可以通過RARP協議發出徵求自身IP地址的廣播請求，然後由RARP服務器負責回答。
RARP協議工作流程：
（1）給主機發送一個本地的RARP廣播，在此廣播包中，聲明自己的MAC地址並且請求任何收到此請求的RARP服務器分配一個IP地址；
（2）本地網段上的RARP服務器收到此請求後，檢查其RARP列表，查找該MAC地址對應的IP地址；
（3）如果存在，RARP服務器就給源主機發送一個響應數據包並將此IP地址提供給對方主機使用；
（4）如果不存在，RARP服務器對此不做任何的響應；
（5）源主機收到從RARP服務器的響應信息，就利用得到的IP地址進行通訊；如果一直沒有收到RARP服務器的響應信息，表示初始化失敗。
二、路由選擇協議（IGP）
常見的路由選擇協議有：RIP協議、OSPF協議。
RIP協議 ：底層是貝爾曼福特算法，它選擇路由的度量標準（metric)是跳數，使用的是距離矢量協議，最大跳數是15跳。如果大於15跳，它就會丟棄數據包。
OSPF協議 ：Open Shortest Path First開放式最短路徑優先，底層是迪傑斯特拉算法，是鏈路狀態路由選擇協議，它選擇路由的度量標準是帶寬，延遲。
三、TCP/IP協議
TCP/IP協議是Internet最基本的協議、Internet國際互聯網絡的基礎，由網絡層的IP協議和傳輸層的TCP協議組成。通俗而言：TCP負責發現傳輸的問題，一有問題就發出信號，要求重新傳輸，直到所有數據安全正確地傳輸到目的地。而IP是給因特網的每一臺聯網設備規定一個地址。
IP層接收由更低層（網絡接口層例如以太網設備驅動程序）發來的數據包，並把該數據包發送到更高層—TCP或UDP層；相反，IP層也把從TCP或UDP層接收來的數據包傳送到更低層。IP數據包是不可靠的，因爲IP並沒有做任何事情來確認數據包是否按順序發送的或者有沒有被破壞，IP數據包中含有發送它的主機的地址（源地址）和接收它的主機的地址（目的地址）。
TCP是面向連接的通信協議，通過三次握手建立連接，通訊完成時要拆除連接，由於TCP是面向連接的所以只能用於端到端的通訊。TCP提供的是一種可靠的數據流服務，採用“帶重傳的肯定確認”技術來實現傳輸的可靠性。TCP還採用一種稱爲“滑動窗口”的方式進行流量控制，所謂窗口實際表示接收能力，用以限制發送方的發送速度。
TCP報文首部格式：
TCP三次握/四次揮手
seq:"sequance"序列號；
ack:"acknowledge"確認號；
SYN:"synchronize"請求同步標誌；
ACK:“acknowledge"確認標誌”；
FIN："Finally"結束標誌。
TCP連接建立過程：首先Client端發送連接請求報文，Server段接受連接後回覆ACK報文，併爲這次連接分配資源。Client端接收到ACK報文後也向Server段發生ACK報文，並分配資源，這樣TCP連接就建立了。
TCP連接斷開過程：假設Client端發起中斷連接請求，也就是發送FIN報文。Server端接到FIN報文後，意思是說"我Client端沒有數據要發給你了"，但是如果你還有數據沒有發送完成，則不必急着關閉Socket，可以繼續發送數據。所以你先發送ACK，“告訴Client端，你的請求我收到了，但是我還沒準備好，請繼續你等我的消息”。這個時候Client端就進入FIN_WAIT狀態，繼續等待Server端的FIN報文。當Server端確定數據已發送完成，則向Client端發送FIN報文，“告訴Client端，好了，我這邊數據發完了，準備好關閉連接了”。Client端收到FIN報文後，"就知道可以關閉連接了，但是他還是不相信網絡，怕Server端不知道要關閉，所以發送ACK後進入TIME_WAIT狀態，如果Server端沒有收到ACK則可以重傳。“，Server端收到ACK後，“就知道可以斷開連接了”。Client端等待了2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，我Client端也可以關閉連接了。Ok，TCP連接就這樣關閉了！
爲什麼要三次揮手？
在只有兩次“握手”的情形下，假設Client想跟Server建立連接，但是卻因爲中途連接請求的數據報丟失了，故Client端不得不重新發送一遍；這個時候Server端僅收到一個連接請求，因此可以正常的建立連接。但是，有時候Client端重新發送請求不是因爲數據報丟失了，而是有可能數據傳輸過程因爲網絡併發量很大在某結點被阻塞了，這種情形下Server端將先後收到2次請求，並持續等待兩個Client請求向他發送數據…問題就在這裏，Cient端實際上只有一次請求，而Server端卻有2個響應，極端的情況可能由於Client端多次重新發送請求數據而導致Server端最後建立了N多個響應在等待，因而造成極大的資源浪費！所以，“三次握手”很有必要！
爲什麼要四次揮手？
試想一下，假如現在你是客戶端你想斷開跟Server的所有連接該怎麼做？第一步，你自己先停止向Server端發送數據，並等待Server的回覆。但事情還沒有完，雖然你自身不往Server發送數據了，但是因爲你們之前已經建立好平等的連接了，所以此時他也有主動權向你發送數據；故Server端還得終止主動向你發送數據，並等待你的確認。其實，說白了就是保證雙方的一個合約的完整執行！
使用TCP的協議：
FTP（文件傳輸協議）
Telnet（遠程登錄協議）
SMTP（簡單郵件傳輸協議）
POP3（和SMTP相對，用於接收郵件）
HTTP協議等。
四、UDP協議
UDP用戶數據報協議，是面向無連接的通訊協議，UDP數據包括目的端口號和源端口號信息，由於通訊不需要連接，所以可以實現廣播發送。UDP通訊時不需要接收方確認，屬於不可靠的傳輸，可能會出現丟包現象，實際應用中要求程序員編程驗證。
UDP與TCP位於同一層，但它不管數據包的順序、錯誤或重發。因此，UDP不被應用於那些使用虛電路的面向連接的服務，UDP主要用於那些面向查詢—應答的服務，例如NFS。相對於FTP或Telnet，這些服務需要交換的信息量較小。
每個UDP報文分UDP報頭和UDP數據區兩部分。報頭由四個16位長（2字節）字段組成，分別說明該報文的源端口、目的端口、報文長度以及校驗值。UDP報頭由4個域組成，其中每個域各佔用2個字節，具體如下：
（1）源端口號；
（2）目標端口號；
（3）數據報長度；
（4）校驗值。
使用UDP協議包
TFTP（簡單文件傳輸協議）
SNMP（簡單網絡管理協議）
DNS（域名解析協議）
NFS
BOOTP。
TCP 與 UDP 的區別：
TCP是面向連接的，可靠的字節流服務；
UDP是面向無連接的，不可靠的數據報服務。