來源：公眾號【網絡技術干貨圈】

作者：圈圈

ID：wljsghq

PPPoe的報文結構

可以看出PPPoe的報文結構其實很簡單，只不過是將PPPoe的報文塞到以太網的載荷中，而且它的頭部字段也十分的簡單，TLV就不說了，code字段表示了PPPoe不同的報文類型，比較常見的就是上面的五個報文了，PPPoe的報文類型其實還蠻多的。session ID主要的作用就是標識一段會話，因為使用PPPoe的最主要作用就是使得多臺設備可以借助以太網多點接入多點訪問的特點去和一臺設備做上網認證請求，這樣運營商一臺認證設備就可以滿足多個用戶的認證請求，這和PPP相比起來好的不止一點。雖然傳統的廣域網鏈路的傳輸距離比較長，但是速率低是它的痛點，而且隨著以太網的發展和光纖的發展，用戶連接到運營商的介質不僅僅局限于雙絞線，所以像傳統的廣域網鏈路在用戶于運營商之間也越來越少了。

PPPoe的頭部后面就是PPP的報文了，因為我們需要的是ppp協議中的認證功能，所以自然需要有完整的ppp報文去完成這一部分的功能。

1、PPPoe的發現階段

因為是將ppp在以太網上實現，所以在一個廣播鏈路上可能有多個相關的PPPoe服務端，所以PPPoe的發現階段和DHCP的發現階段十分的相似

我們現在來抓包分析一下它的發現過程：

1、首先發送Init的初始報文去尋找PPPoe的服務端，下面是init初始報文

可以看到初始報文比較簡潔，在以太網載荷部分，也就是PPPoe的有效內容部分，存在的只有PPPoe的頭部，我們現在可以看到Session ID此時是全0，因為此時我們還沒有和服務端取得聯系，還沒有建立會話。

2、服務端回送一個offer報文，表示它可以提供一個PPPoe的服務

可以看到offer報文的內容也是十分的簡潔，PPPoe的有效內容部分僅僅包含著PPPoe的包頭，其實我們也能夠理解，因為PPPoe的會話發現階段并不需要其他的內容，我們只要通過init和offer報文互相發現，互相確認即可。

3、客戶端發送request報文，表示希望請求該服務端的PPPoe服務

同樣request報文也很簡潔，我就不贅述了

4、服務端發送session-confirm表示對建立的會話的確認

這個報文同樣很簡潔，我們還可以發現上面三個報文的session-ID都是0，但是因為最后一個報文是服務器端確定了客戶端要使用自己的PPPoe的服務，所以它就生成了PPPoe的session-ID填入到session-confirm中表示我已經將會話建立起來了，你后面使用這個session-ID就好。

5、正常的PPP鏈路協商

審核編輯：湯梓紅