運行Telnet這樣的普通TCP工具軟件ARP會做些什么

為了看清楚ARP的運作過程，我們執行telnet命令與無效的服務器連接。

當我們在另一個系統（s u n）上運行帶有-e選項的t c p d u m p命令時，顯示的是硬件地址（在我們的例子中是48 bit 的以太網地址）。圖4 - 4中的t c p d u m p的原始輸出如附錄A中的圖A - 3所示。由于這是本書第一個t c p d u m p 輸出例子，你應該去查看附錄中的原始輸出，看看我們作了哪些修改。

圖4-4 TCP連接請求產生的ARP請求和應答
我們刪除了t c p d u m p命令輸出的最后四行，因為它們是結束連接的信息
在第1行中，源端主機（b s d i）的硬件地址是0 : 0 : c 0 : 6 f : 2 d : 4 0。目的端主機的硬件地址是ff : ff : ff : ff : ff : ff ，這是一個以太網廣播地址。電纜上的每個以太網接口都要接收這個數據幀并對它進行處理，如圖4 - 2所示。
第1行中緊接著的一個輸出字段是a r p，表明幀類型字段的值是0 x 0 8 0 6，說明此數據幀是一個A R P請求或回答。
在每行中，單詞a r p或i p后面的值6 0指的是以太網數據幀的長度。由于A R P請求或回答的數據幀長都是4 2字節（2 8字節的A R P數據，1 4字節的以太網幀頭），因此，每一幀都必須加入填充字符以達到以太網的最小長度要求：6 0字節。
這個最小長度6 0字節包含1 4字節的以太網幀頭，但是不包括4個字節的以太網幀尾。有一些書把最小長度定為6 4字節，它包括以太網的幀尾。我們把最小長度定為4 6字節，是有意不包括1 4字節的幀首部，因為對應的最大長度（1 5 0 0字節）指的是M T U—最大傳輸單元（見圖2 - 5）。我們使用M T U經常是因為它對I P數據報的長度進行限制，但一般與最小長度無關。大多數的設備驅動程序或接口卡自動地用填充字符把以太網數據幀充滿到最小長度。第3，4和5行中的I P數據報（包含T C P段）的長度都比最小長度短，因此都必須填充到6 0字節。
第1行中的下一個輸出字段arp who-has 表示作為A R P請求的這個數據幀中，目的I P地址是s v r 4的地址，發送端的I P地址是b s d i的地址。t c p d u m p打印出主機名對應的默認I P地址（在4 . 7節中，我們將用-n選項來查看A R P請求中真正的I P地址。） 從第2 行中可以看到，盡管A R P 請求是廣播的，但是A R P 應答的目的地址卻是b s d i（0 : 0 : c 0 : 6 f : 2 d : 4 0）。A R P應答是直接送到請求端主機的，而是廣播的。t c p d u m p打印出arp reply的字樣，同時打印出響應者的主機名和硬件地址。第3行是第一個請求建立連接的T C P段。它的目的硬件地址是目的主機(s v r 4)。
在每一行中，行號后面的數字表示t c p d u m p收到分組的時間（以秒為單位）。除第1行外，其他每行在括號中還包含了與上一行的時間差異（以秒為單位）。從這個圖可以看出，發送A R P請求與收到A R P回答之間的延時是2.2 ms。而在0.7 ms之后發出第一段T C P報文。在本例中，用A R P進行動態地址解析的時間小于3 ms 。
最后需要指出的一點，在t c p d u m p命令輸出中，我們沒有看到s v r 4在發出第一段T C P報文（第4行）之前發出的A R P請求。這是因為可能在s v r 4的A R P高速緩存中已經有b s d i的表項。一般情況下，當系統收到A R P請求或發送A R P應答時，都要把請求端的硬件地址和I P地址存入A R P高速緩存。在邏輯上可以假設，如果請求端要發送I P數據報，那么數據報的接收端將很可能會發送一個應答。

原文轉自：http://www.kjueaiud.com