AAA服務器技術

一、AAA認證架構

?理解AAA基本概念與架構

  • 先介紹：?AAA是什么（認證、授權、計費）

  • 重點理解：?為什么需要AAA？它的三大功能分別解決什么問題？

  • 關聯后續：?這是所有后續協議（RADIUS/TACACS+）的基礎。

1.基礎概念

AAA是一個安全框架，它包含三個獨立但緊密相關的功能，共同構成了網絡訪問控制的基礎。

功能 (Function)核心問題 (Core Question)關鍵動作 (Key Actions)類比 (Analogy)
認證 (Authentication)“你是誰？”?(Who are you?)驗證用戶/設備的身份。檢查用戶名、密碼、證書等憑據。進入大樓時，保安查看你的工牌（身份標識）。
授權 (Authorization)“你能做什么？”?(What can you do?)決定用戶/設備有權訪問哪些資源和服務。授予特定權限。保安根據你的工牌權限，告訴你能去哪些樓層（權限劃分）。
計費 (Accounting)“你做了什么？”?(What did you do?)記錄用戶/設備使用網絡資源的情況。用于審計、計費、監控。保安在登記本上記錄你進出大樓的時間（行為審計）。

💡關鍵理解：這三個功能是按順序執行的。必須先通過認證（證明你是誰），才能進行授權（決定你能干嘛），同時計費全程記錄你的行為。

2.AAA架構與實現方式

AAA服務可以通過兩種主要方式部署，這是面試中必問的重點。

1. 本地認證?

  • 工作原理：網絡設備（如路由器、交換機）自身扮演AAA服務器的角色。用戶的用戶名和密碼信息直接配置在設備的本地數據庫中。

  • 工作流程：

    1. 用戶嘗試登錄設備。

    2. 設備檢查輸入的用戶名和密碼是否與本地配置的完全匹配。

    3. 設備直接告知用戶成功或失敗。

  • 優點：簡單、快速，不依賴外部網絡和服務。

  • 缺點：用戶信息分散在各個設備上，難以管理和維護，安全性較低。

  • 適用場景：小型網絡、設備管理登錄（如console/SSH）、設備間協議認證（如BGP鄰居認證）。

2. 遠程認證?

  • 工作原理：網絡設備（稱為NAS，網絡接入服務器）作為客戶端，將用戶的認證信息轉發給專門的AAA服務器進行處理。

  • 工作流程：

    1. 用戶嘗試登錄或接入網絡。

    2. NAS（客戶端）將用戶憑證打包成協議報文（如RADIUS）發送給AAA服務器。

    3. AAA服務器查詢中央數據庫，驗證憑證，并將結果（接受/拒絕）返回給NAS。

    4. NAS根據結果允許或拒絕用戶訪問。

  • 優點：集中化管理，安全性高，易于審計，支持復雜策略。

  • 缺點：依賴網絡連通性和服務器性能。

  • 適用場景：中大型企業網絡，需要對大量用戶進行統一接入控制的場景（如Wi-Fi、VPN、網絡登錄）。

3.NAS的關鍵角色

  • 定義：NAS是AAA架構中的客戶端，是用戶進入網絡的“門戶”或“關卡”。

  • 職責：

    • 接收用戶的接入請求（如PPPoE撥號、連接Wi-Fi、發起VPN隧道）。

    • 收集用戶的認證信息（用戶名、密碼）。

    • 與AAA服務器進行通信（使用RADIUS或TACACS+協議）。

    • 執行AAA服務器下發的授權指令（如為用戶分配IP地址、下發ACL訪問策略）。

    • 向AAA服務器發送計費信息。

常見NAS設備：路由器、交換機、無線控制器（AC）、VPN網關、寬帶接入服務器（BRAS）。

4.AAA支持的服務

AAA保護的服務類型?

  • FTP: 文件傳輸服務。AAA可以對登錄FTP服務器的用戶進行認證和授權（如允許訪問哪個目錄）。

  • TELNET: 遠程登錄服務。這是最經典的用例，對登錄網絡設備的用戶進行認證和授權（如授予不同操作權限級別）。

  • PPP: 點對點協議（如寬帶撥號上網）。AAA是PPPoE撥號認證的核心（比如ADSL上網需要輸入賬號密碼，那就是AAA在后臺工作）。

  • 端口接入: 如IEEE 802.1X認證。用戶連接交換機的一個端口后，必須通過認證才能讓該端口打開并接入網絡。

🎯 面試重點與理解提示

  • 不要死記硬背服務列表： 關鍵是理解“任何需要驗證身份、控制權限、記錄行為的網絡服務，都可以集成AAA”?這一核心思想。

  • 理解“授權”的靈活性： 授權下發的不僅僅是“通過”或“拒絕”，而是一套精細化的策略（Policy），比如VLAN、ACL、用戶級別、路由策略等。這是AAA功能強大的體現。

  • 計費的目的不僅是收費： “計費”一詞聽起來像是為了賺錢，但在企業網中，它更重要的目的是安全審計（Auditing）和網絡行為分析。記錄“誰在什么時間做了什么”，這對于合規性和故障排查至關重要。

總結：這一頁PPT讓你從抽象概念落地到具體應用，是理論聯系實際的關鍵一環。

二、RADIUS協議

1.協議概述

為什么用UDP而不用TCP？

  • 效率更高：?無連接，開銷小，速度快。對于大規模接入場景，性能至關重要。

  • 簡單：?實現起來比TCP簡單。

  • 重傳機制：?RADIUS在應用層自己實現了重傳機制（通過Identifier字段和超時計時器），彌補了UDP不可靠的缺點。

  • 客戶端/服務器模型 (C/S)：?NAS是客戶端，負責將用戶請求轉發給RADIUS服務器。

  • 共享密鑰 (Shared Secret)：?客戶端和服務器之間配置一個共享的密鑰，用于驗證消息的完整性和加密密碼（使用MD5哈希）。注意：?僅密碼被加密，報文頭和其他屬性是明文傳輸的。

  • 協議效率高：?基于無連接的UDP，開銷小，速度快，適合大規模用戶接入場景。

  • 基本報文類型：

    • Access-Request?(認證請求)

    • Access-Accept?(認證接受)

    • Access-Reject?(認證拒絕)

    • Accounting-Request?(計費請求)

    • Accounting-Response?(計費響應)

2.?安全機制：共享密鑰

  • 作用：

    1. 加密密碼：?用于加密User-Password屬性。

    2. 驗證消息完整性：?用于生成Response Authenticator，防止數據篡改。

    3. 身份驗證：?確保消息來自合法的客戶端或服務器。

  • 密碼是如何加密的？?使用共享密鑰和Request Authenticator，通過MD5算法生成一個16字節的散列值，與密碼進行異或操作。（不是直接加密，而是混淆）

  • 哪些信息被加密？?只有User-Password等極少數敏感屬性被加密，其他報文頭部和屬性都是明文傳輸的。這是RADIUS的一個安全弱點。

3.報文結構

Authenticator (16字節)：?驗證器，有兩種類型：

  • Request Authenticator:?在Access-Request中，是一個隨機數，用于加密密碼。

  • Response Authenticator:?在響應報文中，是一個MD5散列值，由Code+ID+Length+Request Auth+共享密鑰+Attributes計算得出，用于驗證響應是否合法。

3.1?屬性 (Attributes) - TLV結構

1 - User-Name： 用戶名

2 - User-Password： 加密后的密碼

4 - NAS-IP-Address： NAS的IP地址

8 - Framed-IP-Address： 下發分配給用戶的IP地址

11 - Filter-Id： 下發給NAS的ACL名稱

26 - Vendor-Specific：?廠商特定屬性 (VSA)，是RADIUS強大擴展性的基石。

31 - Calling-Station-ID： 主叫號碼/用戶MAC地址

4.交互流程

我們將一個完整的用戶會話（如PPP撥號或Wi-Fi連接）分為兩個完全獨立的階段：

  1. 認證與授權階段（使用UDP端口1812）

  2. 計費階段（使用UDP端口1813）

🔍 流程步驟詳解

階段一：認證與授權（端口 1812）

第1步：用戶發起連接

  • 用戶在網絡接入點（如撥號連接、Wi-Fi認證頁面）輸入用戶名和密碼。

  • NAS?接收到這些憑證。

第2步：NAS發送 Access-Request

  • NAS?扮演RADIUS客戶端角色，將用戶信息打包成一個?Access-Request?報文。

  • 關鍵字段和操作：

    • Code = 1?(Access-Request)

    • Identifier: 生成一個隨機數（例如X），用于匹配請求和響應。

    • Request Authenticator: 生成一個16字節的隨機數。

    • 加密密碼：使用共享密鑰和Request Authenticator，通過MD5算法對用戶密碼進行加密，填入?User-Password?屬性。

    • 添加其他屬性，如?User-Name、NAS-IP-Address、NAS-Port、Called-Station-ID（AP MAC地址）等。

  • 將此報文發送給RADIUS服務器（1812端口）。

第3步：RADIUS服務器處理并響應

  • RADIUS服務器?收到請求后：

    1. 驗證客戶端：根據NAS的源IP地址查找配置的共享密鑰。

    2. 驗證密碼：使用查到的共享密鑰和收到的?Request Authenticator，用相同的算法解密?User-Password?屬性，得到明文密碼。

    3. 認證查詢：將?User-Name?和解密后的密碼與用戶數據庫（如LDAP、本地文件）進行比對。

    4. 授權查詢：如果認證成功，服務器會查詢該用戶的授權策略。

  • 服務器返回三種響應之一：

    • Access-Accept?(Code=2): 認證成功。該報文內直接包含授權屬性，如：

      • Framed-IP-Address: 分配給用戶的IP地址。

      • Filter-Id: 下發給NAS的訪問控制列表（ACL）名稱，用于控制用戶訪問權限。

      • Session-Timeout: 會話超時時間（秒）。

    • Access-Reject?(Code=3): 認證失敗（密碼錯誤、用戶不存在等）。

    • Access-Challenge?(Code=11): 請求挑戰（用于更復雜的多因子認證，如SMS驗證碼。本次討論暫不展開）。

  • Identifier字段必須與請求報文中的完全相同（即X）。

第4步：NAS執行操作

  • NAS收到響應后，根據?Code?執行操作：

    • Access-Accept: 允許用戶接入，并根據報文中的授權屬性為用戶配置網絡參數（如分配IP、應用ACL）。

    • Access-Reject: 拒絕用戶接入，斷開連接。

階段二：計費（端口 1813）

第5步：NAS發送計費開始請求

  • 一旦用戶會話被建立，NAS會立即向RADIUS服務器發送一個?Accounting-Request?報文。

  • 關鍵字段和操作：

    • Code = 4?(Accounting-Request)

    • Status-Type = Start?(1): 表示這是一個“開始”計費記錄。

    • Acct-Session-ID: 一個唯一的會話標識符，用于將開始和結束記錄關聯起來。

    • 包含用戶和會話信息，如?User-Name、Framed-IP-Address、NAS-Port。

  • 使用一個新的?Identifier?(例如Y)，通過1813端口發送。

第6步：服務器確認計費開始

  • RADIUS服務器收到后，會記錄會話開始事件（通常寫入數據庫或日志文件）。

  • 回復一個?Accounting-Response?(Code=5)?作為確認。Identifier?同樣為Y。

第7&8步：（可選）臨時更新

  • 對于長會話，NAS可能會定期（如每30分鐘）發送?Status-Type = Interim-Update?(3) 的?Accounting-Request，上報截至當前的使用量（流量、時長）。

  • 服務器每次都會回復?Accounting-Response。

第9&10&11步：用戶斷開，NAS發送計費結束請求

  • 用戶主動斷開或超時斷開連接。

  • NAS發送一個?Status-Type = Stop?(2) 的?Accounting-Request。

  • 此報文中包含最終的會話統計數據，如：

    • Acct-Session-Time: 會話總時長（秒）。

    • Acct-Input-Octets: 用戶接收的總字節數。

    • Acct-Output-Octets: 用戶發送的總字節數。

  • 服務器記錄最終數據并回復?Accounting-Response。會話生命周期結束。

三、TACACS 協議詳解

1.基本概念

核心特性：

  • 模塊化設計：?將認證、授權、計費三個功能完全分離，每個功能都使用獨立的報文類型和會話。

  • 增強的安全性：?加密整個報文載荷（除頭部）。

  • 精細化的控制 ：?支持極其細致的命令行授權。

1. 傳輸層協議與端口

  • 協議：?TCP

  • 端口：?49

  • 面試重點：為什么用TCP？

    • 可靠性：?確保管理配置命令等關鍵消息不丟失、不亂序。

    • 復雜交互：?TACACS+的交互可能是多回合的（挑戰-應答），TCP的面向連接特性更適合這種長對話。

    • 安全性：?為整個報文加密提供了穩定的傳輸基礎。

2. 安全機制：加密整個報文正文

  • 加密方式：?使用MD5算法和共享密鑰，對整個報文正文（Payload）?進行加密。

  • 對比RADIUS：

    RADIUSTACACS+
    加密范圍僅加密?User-Password?等少數屬性加密整個報文正文
    報文頭明文明文
    安全性較低，易被嗅探高，防止流量分析

3. 模塊化設計：認證、授權、計費分離

這是TACACS+最核心、最區別于RADIUS的特性。

功能RADIUSTACACS+
認證 (AuthN)與授權捆綁在?Access-Request/Accept?中完成獨立流程，使用?START,?CONTINUE,?REPLY?報文
授權 (AuthZ)隨認證響應一并下發獨立流程，使用?REQUEST,?RESPONSE?報文
計費 (Acct)獨立，但功能相對簡單獨立流程，記錄更詳細的管理操作日志

這種分離使得每個過程可以獨立進行，非常靈活。例如，一個用戶可以通過一種方式認證（如LDAP），但授權信息卻來自另一個數據庫。

2.報文結構

  • major/minor version:?版本號。

  • type (1字節):?定義報文的主要類型，這是最重要的字段。

    • 0x01?-?Authentication?(認證)

    • 0x02?-?Authorization?(授權)

    • 0x03?-?Accounting?(計費)

  • seq_no (1字節):?序列號。指示當前會話中的報文序號。第一個請求報文為1，后續每次發送加1。用于管理多回合交互。

  • flags:?標志位，如UNENCRYPTED位（不建議使用）。

  • session_id:?會話ID，用于唯一標識一個會話。

  • length (4字節):?被加密的正文字段的長度。

報文正文 (Body)

  • 頭部之后的部分。

  • 整個正文部分都被加密。

  • 正文的具體格式和含義由type字段決定。

3.交互流程?

以最經典的用戶通過Telnet/SSH登錄網絡設備為例，展示了一個完整的、成功的交互過程：

?? 4.TACACS+ vs. RADIUS 核心對比總結

特性維度RADIUSTACACS+
傳輸協議UDP?(無連接，高效)TCP?(面向連接，可靠)
加密方式僅加密密碼加密整個報文正文
協議設計認證 & 授權 合并認證、授權、計費 完全分離
交互特性簡單，通常1-2回合復雜，支持多回合挑戰應答
控制粒度較粗，基于用戶組極細，可控制到單條命令
主要場景用戶網絡接入?(IP級)網絡設備管理?(字符型CLI)
標準性開放標準 (IETF RFC)Cisco私有?(事實標準)

四、典型應用案例

1.AAA技術最主要的三大應用場景

1.1 用戶接入認證授權

  1. 一個用戶通過多種方式發起連接：“用戶直接發起VPN連接”?和?“LAN或wlan接入”。
  2. 用戶的請求到達一臺路由器（ROUTER，它在此處扮演NAS的角色）。
  3. 路由器將用戶的認證信息（如用戶名密碼）發送給后端的?RADIUS?服務器進行驗證。
  4. 驗證通過后，用戶被允許接入“總部”網絡。

1.2登錄設備認證授權

1.3設備間協議認證

應用場景首選協議原因備選方案
用戶接入網絡?(VPN, WiFi)RADIUS高效、標準，適合處理大量用戶和網絡層授權本地認證 (小規模)
用戶登錄設備?(SSH, Telnet)TACACS+提供最精細的命令級授權和完整的審計日志RADIUS (基本認證)、本地認證 (備用)
設備間協議認證?(BGP, OSPF)本地認證簡單、可靠、不依賴外部服務無?(幾乎不使用遠程認證)

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/diannao/96791.shtml
繁體地址，請注明出處：http://hk.pswp.cn/diannao/96791.shtml
英文地址，請注明出處：http://en.pswp.cn/diannao/96791.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

客戶生命周期價值幫助HelloFresh優化其營銷支出

客戶生命周期價值幫助HelloFresh優化其營銷支出

1 引言 了解客戶的長期價值對HelloFresh至關重要。客戶生命周期價值（CLV）代表了客戶與公司關系的整個過程中所產生的總價值。通過預測這一指標，我們可以更明智地決定如何分配營銷資源，以獲得最大的影響。 在本文中，我…
閱讀更多...
Vue 2 中的 v-model和Vue3中的v-model

Vue 2 中的 v-model和Vue3中的v-model

你問的是 v-model&#xff08;不是 v-modal 吧 &#x1f604;&#xff09;&#xff0c;我來幫你梳理一下 Vue2 和 Vue3 的 v-model 區別。&#x1f539; Vue 2 中的 v-model語法<input v-model"msg">v-model 本質上是 語法糖&#xff0c;等價于&#xff1a;<…
閱讀更多...
樸素貝葉斯算法學習總結

樸素貝葉斯算法學習總結

一、貝葉斯理論基礎 1. 貝葉斯思想的核心 貝葉斯算法由 18 世紀英國數學家托馬斯?貝葉斯提出&#xff0c;其核心是解決 “逆概” 問題 —— 區別于 “正向概率” 已知條件求結果概率的思路&#xff0c;逆概是通過觀測到的結果&#xff0c;反推導致該結果的原因概率。比如在日常…
閱讀更多...
【Protues仿真】基于AT89C52單片機的舵機和直流電機控制

【Protues仿真】基于AT89C52單片機的舵機和直流電機控制

目錄 1 PWM信號 1.1 三個最基本的量 1.1.1 周期 T&#xff08;Period&#xff09; 1.1.2脈沖寬度 Th&#xff08;High Time&#xff09; 1.1.3占空比 D&#xff08;Duty Cycle&#xff09; 1.2 為什么要用 PWM 1.3 關鍵參數對照表 1.4單片機里產生 PWM 的四種套路 1.4…
閱讀更多...
vue家教預約平臺設計與實現（代碼+數據庫+LW）

vue家教預約平臺設計與實現（代碼+數據庫+LW）

摘要 隨著互聯網技術的不斷發展&#xff0c;在線家教平臺逐漸成為家長和學生選擇教育服務的重要途徑。尤其在現代社會中&#xff0c;個性化教育需求日益增多&#xff0c;傳統的線下家教形式已無法完全滿足廣大家長和學生的需求。在線家教平臺不僅能為學生提供更多選擇&#xf…
閱讀更多...
AI系列 - Claude 與 Qwen 模型自動補全對比：誰更勝一籌？

AI系列 - Claude 與 Qwen 模型自動補全對比：誰更勝一籌？

Claude 與 Qwen 模型自動補全對比&#xff1a;誰更勝一籌&#xff1f; 導讀&#xff1a;隨著大語言模型的快速發展&#xff0c;自動補全功能在代碼編寫、文本生成等領域變得越來越重要。本文將對比 Anthropic 的 Claude 系列模型與 Alibaba 的 Qwen 系列模型在自動補全任務中的…
閱讀更多...
【ARM】MDK在debug模式下斷點的類型

【ARM】MDK在debug模式下斷點的類型

1、 文檔目標本文旨在深入探討嵌入式開發環境中&#xff08;以MDK為例&#xff09;調試模式下的斷點類型&#xff0c;幫助開發者全面了解不同斷點的工作原理及其應用場景。通過掌握這些知識&#xff0c;開發者可以更高效地進行代碼調試&#xff0c;快速定位和解決問題。2、 問題…
閱讀更多...
CF2133C 下界（The Nether）

CF2133C 下界（The Nether）

CF2133C 下界&#xff08;The Nether&#xff09; 洛谷題目傳送門 題目描述 這是一道交互題。 最近發現下界&#xff08;The Nether&#xff09;后&#xff0c;Steve 在他的世界中建造了一個由 nnn 個下界傳送門組成的網絡&#xff0c;每個傳送門位于不同的位置。 每個傳送…
閱讀更多...
無線USB轉換器TOS-WLink網盤更新--TOS-WLink使用幫助V1.0.pdf

無線USB轉換器TOS-WLink網盤更新--TOS-WLink使用幫助V1.0.pdf

1&#xff0c;編寫原因 隨著當前視頻越來越多&#xff0c;對于首次接觸到WLink的朋友、首次開箱使用的朋友不夠友好&#xff0c;常常感覺無從下手&#xff0c;為此編寫了TOS-WLink使用幫助V1.0.pdf&#xff1b;按照文檔進行一步一步驅動安裝&#xff0c;配網&#xff1b;文檔中…
閱讀更多...
Redis面試精講 Day 29：Redis安全防護與最佳實踐

Redis面試精講 Day 29：Redis安全防護與最佳實踐

【Redis面試精講 Day 29】Redis安全防護與最佳實踐 在“Redis面試精講”系列的第29天&#xff0c;我們聚焦于一個在生產環境中至關重要、卻常被開發者忽視的核心主題——Redis的安全防護與最佳實踐。隨著Redis廣泛應用于高并發、分布式系統中&#xff0c;其暴露在公網或內網中…
閱讀更多...
【數據結構】LeetCode160.相交鏈表 138.隨即鏈表復制 牛客——鏈表回文問題

【數據結構】LeetCode160.相交鏈表 138.隨即鏈表復制 牛客——鏈表回文問題

文章目錄一、相交鏈表問題問題描述解題思路分析思路一&#xff1a;暴力遍歷法思路二&#xff1a;雙指針對齊法&#xff08;最優解&#xff09;二、鏈表的回文結構問題描述解題思路完整代碼三、 隨即鏈表的復制問題描述解題思路復雜度分析一、相交鏈表問題 問題描述 給定兩個單…
閱讀更多...
Mysql InnoDB 底層架構設計、功能、原理、源碼系列合集【四、事務引擎核心 - MVCC與鎖機制】

Mysql InnoDB 底層架構設計、功能、原理、源碼系列合集【四、事務引擎核心 - MVCC與鎖機制】

Mysql InnoDB 底層架構設計、功能、原理、源碼系列合集 一、InnoDB 架構先導。【模塊劃分&#xff0c;各模塊功能、源碼位置、關鍵結構體/函數】 二、內存結構核心 - 緩沖池與性能加速器 三、日志系統 - 事務持久化的基石 四、事務引擎核心 - MVCC與鎖機制 五、InnoDB 高階…
閱讀更多...
[ pytorch ] 基于CLIP的zero-shot圖像分類

[ pytorch ] 基于CLIP的zero-shot圖像分類

論文&#xff1a;Learning Transferable Visual Models From Natural Language Supervision 地址&#xff1a;Learning Transferable Visual Models From Natural Language Supervision 一、關于CLIP 基于圖文匹配的特征學習&#xff1a;該論文證明了預測哪個標題與哪個圖像…
閱讀更多...
SP95N65CTO：一款高性能650V SiC MOSFET的全面解析

SP95N65CTO：一款高性能650V SiC MOSFET的全面解析

碳化硅&#xff08;SiC&#xff09;功率器件因其優異的性能&#xff0c;在高頻、高溫、高效率的應用中越來越受到重視。本文將以SP95N65CTO為例&#xff0c;詳細介紹這款650V SiC MOSFET的關鍵特性、電氣參數與應用場景。一、產品概述SP95N65CTO是一款采用TOLI&#xff08;TO-2…
閱讀更多...
week4-[二維數組]平面上的點

week4-[二維數組]平面上的點

week4-[二維數組]平面上的點 題目描述 有 NNN 個二維平面上的點&#xff0c;每個點的坐標都是整數且坐標范圍都在 0～9990\sim 9990～999 之間&#xff0c;求其中出現最頻繁的點的出現次數及其坐標。 輸入格式 第一行有一個整數 NNN&#xff0c;表示平面上點的個數。 接下來 NN…
閱讀更多...
領域專用AI模型訓練指南：醫療、法律、金融三大垂直領域微調效果對比

領域專用AI模型訓練指南：醫療、法律、金融三大垂直領域微調效果對比

領域專用AI模型訓練指南&#xff1a;醫療、法律、金融三大垂直領域微調效果對比 &#x1f31f; Hello&#xff0c;我是摘星&#xff01; &#x1f308; 在彩虹般絢爛的技術棧中&#xff0c;我是那個永不停歇的色彩收集者。 &#x1f98b; 每一個優化都是我培育的花朵&#xff0…
閱讀更多...
在自動駕駛中ESKF實現GINS時，是否將重力g作為變量考慮進去的目的是什么？

在自動駕駛中ESKF實現GINS時，是否將重力g作為變量考慮進去的目的是什么？

在自動駕駛的ESKF中&#xff0c;是否將重力 g 作為估計變量&#xff0c;可以從多個維度來比較這兩種方法的差異。對比維度不將重力 g 作為變量將重力 g 作為變量核心假設重力矢量 g 是已知且恒定的完美參考量。重力矢量 g 是需要被估計或校準的量&#xff0c;其值可能存在不確定…
閱讀更多...
Dify 從入門到精通（第 55/100 篇）：Dify 的模型微調（進階篇）

Dify 從入門到精通（第 55/100 篇）：Dify 的模型微調（進階篇）

Dify 從入門到精通&#xff08;第 55/100 篇&#xff09;&#xff1a;Dify 的模型微調 Dify 入門到精通系列文章目錄 第一篇《Dify 究竟是什么&#xff1f;真能開啟低代碼 AI 應用開發的未來&#xff1f;》介紹了 Dify 的定位與優勢第二篇《Dify 的核心組件&#xff1a;從節點…
閱讀更多...
《Password Guessing Using Large Language Models》——論文閱讀

《Password Guessing Using Large Language Models》——論文閱讀

1.研究背景LLM在文本生成和理解方面表現出色&#xff0c;但直接用于密碼猜測存在以下問題&#xff1a;密碼與自然語言的差異&#xff08;短、無語法、需精確匹配&#xff09;生成效率低、重復率高倫理限制&#xff08;如GPT-4拒絕生成大量密碼&#xff09;2.本文研究提出PASSLL…
閱讀更多...
C# 使用OPCUA 與CODESYS進行標簽通訊

C# 使用OPCUA 與CODESYS進行標簽通訊

目錄 1.導出的標簽 識別標簽名稱 2.引用OPCUA的包 3.讀寫方法的封裝 4.完整的業務模塊封裝 1.導出的標簽 識別標簽名稱 從CODESYS導出使用標簽通訊的模塊文檔 大概是這樣子的 <?xml version"1.0" encoding"utf-8"?> <Symbolconfiguratio…
閱讀更多...
最新文章

Copyright @ 2022~2023