radius（remote authentication dial in user service）協議最初是由livingston公司提出的，原先的目的是為撥號使用者進行認證和計費。後來經過多次改進，形成了一項通用的認證計費協議。
radius是一種c/s結構的協議，它的客戶端最初就是nas（net access server）伺服器，現在任何執行radius客戶端軟體的計算機都可以成為radius的客戶端。radius協議認證機制靈活，可以採用pap、chap或者unix登入認證等多種方式。radius是一種可擴充套件的協議，它進行的全部工作都是基於attribute-length-value的向量進行的。
radius的基本工作原理。使用者接入nas，nas向radius伺服器使用access-require資料報提交使用者資訊，包括使用者名稱、密碼等相關資訊，其中使用者密碼是經過md5加密的，雙方使用共享金鑰，這個金鑰不經過網路傳播；radius伺服器對使用者名稱和密碼的合法性進行檢驗，必要時可以提出乙個challenge，要求進一步對使用者認證，也可以對nas進行類似的認證；如果合法，給nas返回access-accept資料報，允許使用者進行下一步工作，否則返回access-reject資料報，拒絕使用者訪問；如果允許訪問，nas向radius伺服器提出計費請求account-require，radius伺服器響應account-accept，對使用者的計費開始，同時使用者可以進行自己的相關操作。
radius還支援**和漫遊功能。簡單地說，**就是一台伺服器，可以作為其他radius伺服器的**，負責**radius認證和計費資料報。所謂漫遊功能，就是**的乙個具體實現，這樣可以讓使用者通過本來和其無關的radius伺服器進行認證。
radius伺服器和nas伺服器通過udp協議進行通訊，radius伺服器的1812埠負責認證，1813埠負責計費工作。採用udp的基本考慮是因為nas和radius伺服器大多在同乙個區域網中，使用udp更加快捷方便。
radius協議還規定了重傳機制。如果nas向某個radius伺服器提交請求沒有收到返回資訊，那麼可以要求備份radius伺服器重傳。由於有多個備份radius伺服器，因此nas進行重傳的時候，可以採用輪詢的方法。如果備份radius伺服器的金鑰和以前radius伺服器的金鑰不同，則需要重新進行認證。
radius協議應用範圍很廣，包括普通**、上網業務計費，對vpn的支援可以使不同的撥入伺服器的使用者具有不同許可權。最近ieee提出了802.1x標準，這是一種基於埠的標準，用於對無線網路的接入認證，在認證時也採用radius協議。
常見的認證計費機制與系統：
當前常見的認證機制主要有以下幾種：
● 基於dce/kerberos的認證機制；
● 基於公鑰的認證機制；
● 基於挑戰/應答（challenge/response）的認證機制。
當前常見的計費系統有以下幾種：
● ip**計費：採用radius協議進行計費，對協議本身進行了比較小的改動。由於radius協議本來就是為撥號使用者進行認證計費服務的，所以在ip**業務方面，它基本可以勝任。
● 根據流量進行的網路服務計費：在很多大學中都對校園網使用者採用了這樣的計費方式。這種計費方式的特點是對計費沒有實時性的要求、時間粒度大、計費方式相對單一。
在實際進行流**點播收費時會遇到很多問題，對現有的計費協議和解決方案提出了挑戰。隨著接入網發展的進一步加快，寬頻ip網將承載豐富的資料、語音、影象等多**綜合業務，作為流**業務支撐平台的使用者管理和計費系統，有其自身的新業務特點，如時間、流量、多種計費規則、多種**格式等，在選擇性、高效性、實時性、可靠性及安全性方面將會提出比電信業務的使用者管理和計費系統更高的要求。其中最主要的一點是，流**支援多種**格式，並且可以支援多種不同位元速率，甚至可以在傳輸的時候根據網路條件來自適應地調整位元速率，這就給實時流量計費帶來了困難，當前的協議不支援實時流量資訊。
對於流**點播系統的使用者認證和計費，現有的電信系統的管理經驗有借鑑意義，但簡單生硬地把電信業務的使用者管理和計費系統照搬到流**系統中是不可取的，只能在吸收電信系統成熟經驗的基礎上，根據流**業務的自身特點，量身定做使用者管理和計費系統，才能真正成為流**增值業務有效的支撐平台，使得流**的商業運營成為可能，幫助運營商在激烈的競爭中處於有利地位。
我準備開發一套基於radius協議的使用者認證和計費系統，執行在linux系統上，並可以完成多種使用者型別、多種計費策略的認證計費方式。
該計費系統的核心是基於oracle或mysql資料庫。在資料庫裡實現對使用者的分類和不同計費費率以及計費策略。通訊的核心是radius協議。認證計費分別在兩台伺服器上實現，前台伺服器主要負責認證工作，與linux流**伺服器之間採用radius協議進行通訊。前台的另一項工作就是作為radius的**，給後台伺服器**前台傳來的計費資料報。由於radius協議對計費和認證的工作沒有更多的規定，其核心就是對資料適當封裝，並進行安全、保密的傳送，所以關於radius協議方面的程式通訊部分就採用普通的socket程式設計。
由於要處理多使用者併發，所以需要產生多個子程序，對多個使用者同時登入的資訊進行處理，並且，在函式中要實現乙個程序僅處理乙個請求，如果登入資料報的ip和會話id是相同的，則radius伺服器要比較它們請求attribute中的向量，如果相同則過濾掉乙個，通過這種方式來防止重複處理。
前台要完成的另乙個任務就是給後台**計費資料報。這裡主要應用了radius的**協議。前台後台分別放在兩台伺服器上的乙個基本考慮是因為後台伺服器需要對某些使用者進行實時計費，這樣就要經常訪問資料庫，而訪問資料庫需要大量的系統資源，為了提高系統效能，所以把它們放在兩台伺服器上實現。
後台的計費伺服器可以實現不同的計費策略。根據使用者的型別，可以分為普通和預付費使用者兩種，在這些使用者中，根據消費情況，還可以分成不同的等級。對於節目來說，可以根據流量或者點播的時間進行計費，還可以根據不同的節目內容進行計費，每個節目都有其相應的費率。
radius協議：缺陷
radius是目前最常用的認證計費協議之一，它簡單安全，易於管理，擴充套件性好，所以得到廣泛應用。但是由於協議本身的缺陷，比如基於udp的傳輸、簡單的丟包機制、沒有關於重傳的規定和集中式計費服務，都使得它不太適應當前網路的發展，需要進一步改進。
當前ietf成立了專門的工作組討論關於認證、授權和計費（authentication, authorization and accounting, aaa）的問題，他們認為，乙個良好的aaa協議必須具有如下特點：
● 協議必須對典型的資訊和協同工作的需求進行明確的規定。
● 協議必須定義錯誤資訊類別,並且可以正確地根據錯誤類別返回。錯誤資訊類別必須覆蓋所有的操作錯誤。
● 計費操作模型必須描述所有的上網方式。
● 協議必須能夠在ip v6上正常執行。
● 協議應該能夠在傳輸過程中正確處理擁塞問題。
● 支援**。
● 與radius相容。
● 協議應該定義輕量級資料物件,以便於nas實現。
● 協議應該提供協議本身和資料模型的邏輯區別，並且支援更多的資料型別。
● 必須定義mib，支援ip v4和ip v6操作。
基於上述考慮，ietf的aaa工作組在2023年3月提出了乙個被稱為diameter的認證計費協議草案。diameter協議支援移動ip、nas請求和移動**的認證、授權和計費工作，協議的實現和radius類似，也是採用attribute-length-value三元組來實現，但是其中詳細規定了錯誤處理等內容。
Radius配置例項
1.配置shiva模板 huawei radius server template shiva 配置 radius 伺服器模板 shiva huawei radius shiva radius server authentication 129.7.66.66 1812 weight 80 huaw...
H3C裝置AAA和RADIUS協議配置
aaa是authentication，authorization and accounting 認證 授權和計費 的簡稱，它提供了乙個用來對認證 授權和計費這三種安全功能進行配置的一致性框架，實際上是對網路安全的一種管理。這裡的網路安全主要是指訪問控制，包括 l 哪些使用者可以訪問網路伺服器 l 具...
radius系列 freeradius測試
常用工具 radclient radtest radeapclient eapol test jradius simulator jradius編碼 先簡單備註下測試配置，後期再作說明 伺服器端配置如下 etc raddb users 使用者配置 madding cleartext password...