前言：近期根據項目需要，學習了相關802.1x認證方面的內容並通過項目實際開發測試了一輪。再回過頭靜下心來對802.1x認證涉及到的概念、流程、細節再按自己的思路梳理一遍。關於802.1x的基本知識點，互聯網上搜索下便可以瞭解的差不多了，回顧自己在網上學習的這段經歷，發現帶着問題去研究學習，效率會更高，目的性也更強。因此，這邊列出些幾點問題，不管是剛學習此方面知識的，還是溫習知識的小夥伴，可以帶着這幾點問題學習回顧：
-
802.1x認證是用來幹啥子的？
-
802.1x的體系結構爲何樣？
-
802.1x認證與EAP協議、EAPOL協議、PEAP協等認證協議之間的關係是什麼？
-
802.1x認證是誰主動發起認證？
-
802.1x認證是在鏈路層上進行的，當一個設備去對一個接入端口進行認證時，由於不知道雙方的目的MAC地址，如何進行鏈路層通訊？
-
802.1x認證涉及到步驟較多的協議交互，萬一中間步驟由於外部因素中斷了，認證過程將會如何？
接下來讓我們帶着這些問題一步步學習回顧802.1x認證吧。
一、802.1x認證幹啥子用？
較官方的解釋：802.1x協議是基於Client/Server的訪問控制和認證協議。它可以限制未經授權的用戶/設備通過接入端口(access port)訪問LAN/WLAN。在獲得交換機或LAN提供的各種業務之前，802.1x對連接到交換機端口上的用戶/設備進行認證。在認證通過之前，802.1x只允許EAPoL（基於局域網的擴展認證協議）數據通過設備連接的交換機端口；認證通過以後，正常的數據可以順利地通過以太網端口。
通俗易懂的說：不管是有線還是無線的交換機，如果支持802.1x認證並對相應端口（可以是物理上的也可以是邏輯上的）開啓認證的話，我想要通過這個端口進行上網，就要想辦法通過它的認證，讓它知道我是經過你允許的那個他，否則交換機不讓你享受他的上網服務。
二、什麼是802.1x認證的體系結構？
802.1x認證的體系結構簡單的說就是要進行802.1x認證時需要搭建哪些環境。802.1x系統是Client/Server結構，包括三個實體：客戶端（Client）、設備端（Device）和認證服務器（Server），如下圖所示：
客戶端：就是需要通過認證來享受網絡服務的設備，必須要支持EAPOL協議。（Extensible Authentication Protocol over LAN,局域網上的可擴展認證協議）
設備端：對客戶端設備執行認證監測並轉發認證數據的設備，其本身不對客戶端上報的認證信息進行匹配認證，只是一箇中介，用於聯繫客戶端和認證服務器。
認證服務器：是爲客戶端提供認證服務的真傢伙，是設備端背後默默支持的人。用於對設備端實現認證、授權和計費，通常爲RADIUS（Remote Authentication Dial-In User
Service,遠程認證撥號用戶服務）服務器。
三、802.1x認證與EAP協議、EAPOL協議、PEAP協議等認證協議之間的關係是什麼？
也許有些小夥伴在網上查了一堆802.1x認證相關知識點，但是看完也搞不靈清802.1x認證和EAP協議、EAPOL協議等是什麼關係，爲啥有時候可以用EAP協議認證、有時候可以用PEAP認證。這邊先簡單的理一下，關於各個協議的詳細說明打算在後面的章節中詳細概述。
個人認爲，802.1x認證是一個認證體系，包含了所需的體系結構、認證流程、支持的認證協議。其不是一個實際意義上的具體協議，而EAP協議、PEAP協議、EAPOL協議等協議是在802.1x認證時用的到協議。這些協議也可能不是相互獨立的協議，舉個簡單的例子，EAPOL協議僅是規定了一種802.1x協議的一種報文封裝格式，其可以攜帶EAP協議。如果小夥伴想詳細瞭解，可以先去搜索具體的協議說明。總結來說，802.1x認證提供了一種認證方案，而其認證方法的具體實現可以有多種，比如EAP-MD5、EAP-TLS、PEAP(PEAP-EAP-MS-CHAPV2)等。
四、802.1x認證是誰主動發起認證？
既然要認證，就要肯定有人先發起認證請求，那麼是誰先發起這個請求呢？答案是有以下兩種可能：
-
客戶端主動觸發：客戶端主動向設備端發送EAPOL-Start報文來觸發認證。
-
設備端主動觸發：設備端會每隔N秒（比如30s）主動向客戶端發送EAP-Request/Identity報文來觸發認證，此種方式主要用於客戶端不支持主動發送EAPOL-Start報文的情況。
五、802.1x認證如何在鏈路層通訊
由於雙方剛開始都不知道對方的MAC地址，因此雙方都通過將數據發送到一個組播地址：01-80-C2-00-00-03上，這個組播地址是官方保留的（
IEEE Std 802.1X PAE address）。雙方通過解析目的地址爲此組播地址上的數據來進行通訊。
六、802.1x認證涉及到步驟較多的協議交互，萬一中間步驟由於外部因素中斷了，認證過程將會如何？
出現此種情況，一般的思路是等待一段時間，如果對方沒有及時回覆你的請求，就重新發送請求，如果多次沒回復，就當失敗了。802.1x認證就設計了多個定時器用於控制流程的異常問題。一般有以下幾種定時器：
用戶名請求超時定時器（tx-period）、客戶端認證超時定時器（supp-timeout）、認證服務器超時定時器（server-timeout）、握手定時器（handshake-period）、靜默定時器（quiet-period）、週期性重認證定時器（reauth-period）。