為了看清楚ARP的運作過程，我們執行telnet命令與無效的服務器連接。  當我們在另一個系統（sun）上運行帶有-e選項的tcpdump命令時，顯示的是硬件地址（在我們的例子中是48 bit的以太網地址）。 圖4-4中的tcpdump的原始輸出如附錄A中的圖A-3所示。由于這是本書第一個tcpdump輸出例子，你應該去查看附錄中的原始輸出，看看我們作了哪些修改。  我們刪除了tcpdump命令輸出的最后四行，因為它們是結束連接的信息（我們將在第18章進行討論），與這里討論的內容不相關。 在第1行中，源端主機（bsdi）的硬件地址是0:0:c0:6f:2d:40。目的端主機的硬件地址是ff:ff:ff:ff:ff:ff，這是一個以太網廣播地址。電纜上的每個以太網接口都要接收這個數據幀并對它進行處理，如圖4-2所示。 第1行中緊接著的一個輸出字段是arp，表明幀類型字段的值是0x0806，說明此數據幀是一個ARP請求或回答。 在每行中，單詞arp或ip后面的值60指的是以太網數據幀的長度。由于ARP請求或回答的數據幀長都是42字節（28字節的ARP數據，14字節的以太網幀頭），因此，每一幀都必須加入填充字符以達到以太網的最小長度要求： 60字節。 請參見圖1-7，這個最小長度60字節包含14字節的以太網幀頭，但是不包括4個字節的以太網幀尾。有一些書把最小長度定為64字節，它包括以太網的幀尾。我們在圖1-7中把最小長度定為4 6字節，是有意不包括14字節的幀首部，因為對應的最大長度（1500字節）指的是MTU—最大傳輸單元（見圖2-5）。我們使用MTU經常是因為它對I P數據報的長度進行限制，但一般與最小長度無關。大多數的設備驅動程序或接口卡自動地用填充字符把以太網數據幀充滿到最小長度。第3，4和5行中的IP數據報（包含TCP段）的長度都比最小長度短，因此都必須填充到60字節。 第1行中的下一個輸出字段arp who-has表示作為ARP請求的這個數據幀中，目的IP地址是svr4的地址，發送端的IP地址是bsdi的地址。tcpdump打印出主機名對應的默認IP地址（在4.7節中，我們將用-n選項來查看A R P請求中真正的IP地址。）從第2行中可以看到，盡管ARP請求是廣播的，但是ARP應答的目的地址卻是bsdi（0:0:c0:6f:2d:40）。ARP應答是直接送到請求端主機的，而是廣播的。 tcpdump打印出arp reply的字樣，同時打印出響應者的主機名和硬件地址。 第3行是第一個請求建立連接的TCP段。它的目的硬件地址是目的主機(svr4)。我們將在第18章討論這個段的細節內容。 在每一行中，行號后面的數字表示tcpdump收到分組的時間（以秒為單位）。除第1行外，其他每行在括號中還包含了與上一行的時間差異（以秒為單位）。從這個圖可以看出，發送ARP請求與收到ARP回答之間的延時是2.2 ms。而在0.7 ms之后發出第一段TCP報文。在本例中，用ARP進行動態地址解析的時間小于3 ms。 最后需要指出的一點，在tcpdump命令輸出中，我們沒有看到svr4在發出第一段TCP報文（第4行）之前發出的ARP請求。這是因為可能在svr4的ARP高速緩存中已經有bsdi的表項。一般情況下，當系統收到ARP請求或發送ARP應答時，都要把請求端的硬件地址和IP地址存入ARP高速緩存。在邏輯上可以假設，如果請求端要發送IP數據報，那么數據報的接收端將很可能會發送一個應答。