以太網和IEEE 802幀:
幀的目的地址和源地址都是硬件地址(長度爲6字節，即48bit)
之後802定義的是後續數據的字節長度，以太網定義的是後續數據的類型（802後面定義了類型，而以太網沒有定義長度），這一段可區分出兩種幀，因爲802定義的有效長度值與以太網的有效類型值無一相同。
之後802經過了LLC和SNAP纔到達數據部分，而以太網直接到達了數據部分，由於ARP和RARP協議對32 bit的IP地址和48 bit的硬件地址進行映射，因爲數據部分是ARP數據，ARP數據最大長度是28字節,而802數據至少38字節，以太網數據至少46字節，因此在不足的空間用PAD補足。
最後的CRC字段是檢驗和。
SLIP全稱Serial Line IP，是一種在串行線路上對IP數據報進行封裝的簡單形式，下圖是它的幀格式:
幀以特殊字符END(0xc0)開始和結束，結束的END標明幀結束，開始的END作用是如果有線路噪聲，那麼END將結束這份錯誤的報文，這樣當前的報文得以正確地傳輸，而前一個錯誤報文交給上層後，會發現其內容毫無意義而被丟棄。
如果IP報文中有END字符，會連續傳輸兩個字節0xdb和0xdc取代
0xdb被稱作SLIP的ESC字符，如果IP報文中有這個字符，會連續傳輸兩個字節0xdb和0xdd取代
這種幀的缺陷:
1.每一端必須知道對方的IP地址，沒有辦法把本端的IP地址通知給另一端。
2.數據幀中沒有類型字段（類似於以太網中的類型字段），這意味着如果一條串行線路用於SLIP，那麼它只能用IP協議。
3.數據幀中沒有檢驗和。
因爲串行線路的速率通常較低，而且通信經常是交互式的，所以在SLIP線路上會產生許多小的TCP分組(packets)進行交換，爲了傳送1個字節的數據需要20個字節的IP首部和20個字節的TCP首部，總數超過40個字節。爲了彌補這個缺陷產生了CSLIP協議(即壓縮的SLIP)
PPP(Point-to-Point)協議修改了SLIP協議中的所有缺陷，幀格式:
PPP包括三個部分:
1.將IP數據報封裝到串行鏈路的方法。
2.建立、配置和測試數據鏈路連接的鏈路控制協議LCP(Link Control Protoco1)。
3.針對不同網絡層協議的網絡控制協議族NCPs(Network Control Protoco1s)。
幀以標誌字符0x7e開始和結束，協議字段類似於以太網中類型字段的功能，通過協議字段確定其後是什麼數據。幀中有些字符需要轉義，同步鏈路通過硬件技術完成，異步鏈路將0x7d用作轉義字符，緊接着的字符的第6個比特要取其補碼，例如:
1. 遇到0x7e，需用兩個字符： 0x7d和0x5e轉義。
2. 遇到0x7d，需用兩個字符： 0x7d和0x5d轉義。
3. 默認情況下，如果字符的值小於0x20(16進制20前對應的ASCII都是特殊字符)，一般都要進行轉義,原因是它們會被解釋成特殊的含義,用鏈路控制協議可以指定是否需要對這32個字符中的某一些值進行轉義。
與SLIP類似，PPP經常用於低速的串行鏈路，因此減少每一幀的字節數可以降低應用程序的交互時延。這時就可以看出LCP和NCP的作用:
利用LCP,大多數的產品通過協商可以省略標誌符和地址字段，並且把協議字段由2個字節減少到1個字節。
利用NCP,大多數的產品通過協商可以採用Van Jacobson報文首部壓縮方法(和CSLIP一樣),減小IP和TCP首部長度。
環回接口（ Loopback Interface），允許運行在同一臺主機上的客戶程序和服務器程序通過TCP/IP進行通信。大多數系統把IP地址127.0.0.1分配給這個接口，並命名爲localhost。環回接口處理IP數據包如下圖:
IP輸出分兩種，一種傳到環回接口(目的是127.0.0.1,環回接口可以被看作是網絡層下面的另一個鏈路層)，一種傳到以太網接口，傳到以太網接口的數據報還要判斷如果是廣播或多播則複製一份數據報傳到環回接口(廣播或多播包括本身)，如果目的IP就是本機則把數據報傳到環回接口。傳給環回接口的數據均作爲IP輸入。
鏈路層對數據幀長度都有限制，這個限制稱作MTU(最大傳輸單元)，如果IP層傳給鏈路層的數據報長度比鏈路層的MTU大，那麼IP層就需要進行分片（fragmentation），使每一片都小於MTU。下圖列出了一些典型的MTU值:
其中點到點的鏈路層（如SLIP和PPP）的MTU並非指的是網絡媒體的物理特性。相反，它是一個邏輯限制，目的是爲交互應用提供足夠快的響應時間。
當在同一個網絡上的兩臺主機互相通信時，該網絡的MTU是非常重要的。但是如果兩臺主機之間的通信要通過多個網絡，那麼重要的就不是兩臺主機所在網絡的MTU的值，而是兩臺通信主機路徑中的最小MTU，稱作路徑MTU。路徑MTU的值取決於當時所選擇的路由。而選路不一定是對稱的（從A到B的路由可能與從B到A的路由不同），因此路徑MTU在兩個方向上不一定是一致的。
前面提到了串行線的MTU是一個邏輯限制，下面舉個例子討論一下這個問題。
如果線路速率是9600b/s，而一個字節有8bit，加上一個起始比特和一個停止比特，以這個速率一次傳輸一個1024字節(一次傳輸1024字節，意味着MTU最少是這個值)的包需要1066ms。如果用SLIP鏈接運行一個交互式應用程序，同時還運行另一個應用程序如FTP發送或接收1024字節的數據，那麼一般來說就必須等待一半的時間（533 ms）才能把交互式應用程序的分組數據發送出去。
對於交互應用來說，等待533ms是不能接受的。交互響應時間超過100～200ms就被認爲是不好的。這是發送一份交互報文出去後，直到接收到響應信息（通常是出現一個回顯字符）爲止的往返時間。爲了解決這個問題，我們把SLIP的MTU縮短到256，這樣傳輸一幀最長需要266ms ，需要等待133ms，如果將MTU縮到更短(64或128)雖然能提供更快的響應時間，但是不能爲大塊數據提供良好的線路利用率，降低傳輸大塊數據的
最大吞吐量，因此在這二者之間要權衡，所以才說串行線的MTU是一個邏輯限制。
點對點鏈路的MTU是296個字節。假設數據爲256字節，TCP和IP首部佔4 0個字節。由於MTU是IP向鏈路層查詢的結果，因此該值必須包括通常的TCP和IP首部。這樣就會導致IP分片，因爲IP對於CSLIP的壓縮情況一無所知。
上面提到的平均等待時間是傳輸最大數據幀所需時間的一半這個法則只適用於交互通信和大塊數據傳輸都在使用SLIP或PPP的情況下。當只有交互通信時，如果線路速率是9600b/s，那麼任何方向上的1字節數據（假設有5個字節的壓縮幀頭）往返一次都大約需要12.5 ms((1+5)*10/9600*2*1000)。它比前面提到的100~200ms要小得多。需要注意的是，由於幀頭從40個字節壓縮到5個字節，使得1字節數據往返時間從85 ms((1+40)*10/9600*2*1000) 減到12.5 ms。
