目前，大多數路由器均采用分布式轉發、集中式路由處理的體系結構^[1]。該結構方式使主處理單元與各從處理單元可以根據所處位置及執行任務的不同采用不同的處理方式，但也使頂層管理軟件對底層各從處理單元難以進行協調統一的管理。硬件抽象層HAL(Hardware Abstraction Layer)在邏輯上介于底層硬件與上層協議軟件之間，維護兩者之間的數據傳遞，并對底層各接口模塊進行管理，屏蔽底層硬件細節，使得應用軟件可以通過控制HAL達到操縱底層硬件的目的。高性能路由器硬件抽象層的提出^[2]成功解決了分布式路由器面臨的通用性支撐軟件系統結構的設計問題，為構建開放通用的路由器軟件基礎平臺提供了保證。
　　隨著路由器承載業務能力的不斷增強，大規模接入匯聚路由器的設計與實現也被提上了議事日程。ACR(大規模接入匯聚路由器)是3Tnet(高性能寬帶網)網絡的關鍵設備。該設備采用ACR寬帶接入方式，即通過帶有遠端用戶接口單元(RIU)、基于以太網傳輸接口的分合路器(EMDi)組成樹形分叉地域分布式系統構架，保證大規模的用戶直接接入骨干高速網絡，實現視頻點播、網絡電視、IP電話等寬帶業務，從而更加減化了網絡拓撲結構，使業務引入更加快速，運營策略更加多樣化。
　　大規模用戶接入方式也給路由器硬件抽象層的實現方式及信息的實時、高速傳輸提出了新的挑戰，主要表現在以下幾個方面：首先，承載業務量的數量及種類的增多對路由器內部通信的實時性、高效性提出了更多的要求；其次，大規模用戶接入方式增加了路由器對外接口的數量，從而帶來了設備管理上的難度；再次，從系統的通用性及可擴展性考慮，要求構建一種具有可擴展性且不依賴于硬件具體實現方式的軟件體系結構，方便路由軟件的移植和應用。由此可見，硬件抽象層的高度穩定性、可擴展性及可靠性將直接影響路由器的各項性能指標。
　　由于大規模用戶接入方式的特性，使得以前基于IPv6路由器的硬件抽象層的實現方式已經不適應數據高速傳輸及多用戶接入的管理方式。本文將在討論硬件抽象層基本結構的基礎上，提出一種適用于大規模接入匯聚路由器的HAL的通用性軟件結構設計及實現方式，提供高效、可靠的內部通信，并針對多用戶接入數量不確定的情況，提出動態加載" title="加載">加載虛擬驅動模塊" title="驅動模塊">驅動模塊的實現方法，增強路由器面向ACR接入方式的可用性。
1 硬件抽象層基本結構及功能實現
　　根據文獻^[2]提出的方案，高性能路由器硬件抽象層可分為內部通信、虛擬驅動及設備管理三大模塊，這三部分模塊相互配合，共同完成面向實際的用戶設備接口的功能模擬及硬件細節的屏蔽，并對其進行統一協調的管理。硬件抽象層對用戶設備接口的功能模擬主要由虛擬驅動模塊完成，包括數據包的收發及協議報文的預處理等工作，為上層協議軟件提供標準的API函數；而對用戶設備的接口管理則由上層網絡管理軟件通過設備管理模塊對其進行管理配置及監控；內部通信模塊" title="通信模塊">通信模塊運行于內部以太網絡，協調各模塊之間的功能接口，保證各從處理單元與主處理單元之間實時可靠的數據傳輸。其基本結構如圖1所示。

　　根據各模塊的功能可知，硬件抽象層內部通信模塊是各分處理單元與主處理單元信息交互的重要傳輸通道。內部通信模塊匯集各底層設備的數據并根據類型分流至各上層處理模塊，同時，數據維護模塊對虛擬設備及各處理單元的維護信息也需要通過內部通信模塊進行。因此，內部通信模塊采用何種基于內部以太網的數據傳輸實現方式，對路由器內部數據的實時、有效、可靠傳輸起著至關重要的作用。當前內部通信模塊采用基于分隔符的TCP傳輸方式，在應用層數據包的起始部分附加有特定格式的分隔符和數據長度域，解決了由于Nagle算法產生的包粘滯問題^[3]。但該方式沒能解決TCP傳輸方式的消耗過大、實時性不強的問題^[4]。同時，消除分割符恢復報文的完整性也增加了應用程序的處理復雜度，從而不可避免地增加系統的開銷并降低系統的實時性。系統的實時性對于用戶業務急劇增多的ACR路由器而言是一個迫切需要解決的問題。UDP是一個面向消息的傳輸協議^[5]，其最大數據緩沖區長度為8192～65536字節，滿足一次傳輸一個完整報文的條件。在內部以太網中采用UDP傳輸方式具有明顯的優勢。但由于UDP協議的無連接性，導致它是一個不可靠傳輸，文中第二部分將討論如何實現一種基于UDP的內部通信的可靠性傳輸機制。
　　硬件抽象層對用戶設備接口的功能模擬主要通過虛擬驅動進行，路由器業務類型的擴展使得用戶接口數量增多并呈現接入時間的不確定性，從而帶來用戶設備管理上的難度。針對此種情況，文中第三部分提出動態加載虛擬驅動模塊的實現方法，增強路由器面向多用戶接入方式的可用性。
2 基于UDP傳輸方式的內部通信的可靠性實現
　　內部通信模塊處于硬件抽象層的底層，運行于內部交換網絡，完成底層硬件與上層控制軟件的數據傳輸，實現對底層硬件的初步屏蔽分離；針對分布式體系結構特點及多用戶接入的業務需求，內部通信模塊以Client\Server的方式分別運行于主處理單元模塊及各線路接口單元模塊上，采用UDP傳輸協議進行通信，主要基于以下幾點考慮：
　　首先，UDP協議是一個無連接協議，傳輸數據之前源端與終端不需建立連接，因此不需維護連接狀態。這樣服務器端可以使用一個或幾個端口同時向多個客戶端發送消息，符合分布式結構體系的要求。
　　其次，UDP信息包很短，只有8個字節，相對于TCP的20個字節的信息包的額外開銷很小，便于數據的快速傳遞。
　　再次，吞吐量不受擁塞控制算法的調節，只受應用軟件生成數據的速率、傳輸帶寬和計算機性能的影響，適用于內部以太網絡的數據傳輸。
　　但由于UDP方式的無連接性，使得UDP傳輸的可靠性不強。而可靠性是內部通信模塊所必須具有的性能，因此考慮在應用軟件中實現UDP傳輸方式的可靠性保證，主要采用以下方式：
2.1 多線程無連接的C/S通信方式
　　服務器端運行在Linux操作系統下，采用多線程方式收發各類數據；客戶端運行在Vxworks操作系統，采用多任務方式收發各類數據。這樣由于多線程及多任務并行運行的特性，在內部以太網的傳輸條件下，使得收發數據的速率可以滿足系統的要求?；镜幕赨DP協議的無連接客戶端/服務器端通信程序如圖2所示。

　　該通信過程采用多個客戶端(各從處理單元)對一個服務器端(主處理單元)的方式，使多個用戶接口模塊可以在不同時間接入主控。內部通信根據所傳遞數據的不同類型，采用相對固定的不同的端口號，不同的客戶端采用不同的IP地址，從相同的端口收發同類數據。在服務器端通過select()系統調用，既可以輪詢各個socket端口以便及時接收不同端口的數據，又起到定時器的作用。當規定時間內收不到數據時，能夠及時返回繼續在阻塞模式下等待，從而既能及時收發數據，又降低資源消耗。
2.2 三次握手過程
　　每個客戶端與服務器端進行真正的數據傳輸之前，首先要進行一個握手的建立過程，如圖3所示。握手過程成功后則表示雙方通信通道正常，只有在得知握手成功后雙方才可以正常地收發報文，從而克服了UDP協議方式的面向無連接性。為了隨時檢測和維護雙方鏈路的通連性，每個客戶端與服務端在一定的間隔時間內要互發KEEPALIVE報文。如果在規定的時間內收不到對方的KEEPALIVE報文，說明斷鏈，要進行相應的斷鏈處理。

2.3 接收端丟失確認及滑動窗口
　　發送UDP報文時在自定義的內部數據頭中加入所發送數據的序號，接收端收到后發送確認信息，如果發送方在規定時間內沒有收到確認信息，則認為該包丟失，會連同原包的序號重新發送。
　　滑動窗口的目的主要是為了實現流量控制，防止擁塞。每個發送方維護一個重發隊列，保存著一定數量的發送而沒被確認的報文，該隊列剩余空間的大小可以限制應用部分發包的速率。由于UDP協議是基于消息的傳輸協議而非基于流的，因此不必考慮發送端可以接收多少數據，只需知道能否接收數據即可。
　　總之，采用UDP傳輸控制方式主要考慮到其傳輸簡單快速、額外開銷較小的特點，但這是以犧牲一定的可靠性為前提的，因此必須在應用程序中增加可靠性保護機制。在實際應用中證明上述方法可靠高效，能夠維護內部通信有序、快速的數據傳輸。
3 基于多用戶的用戶接入管理
　　在Linux操作系統下，系統把設備映射為一個特殊的設備文件，用戶程序可以像對其他文件一樣對該設備文件進行讀寫操作。虛擬驅動模塊運行在Linux操作系統下，模擬從處理單元上的接口單元，形成收發協議報文功能和數量與此一致的硬件抽象層虛擬接口單元。因此，每個實際的接口單元都在內核中對應一個注冊的虛擬設備，以便于上層控制軟件對數據平面的管理與數據交互。
3.1 多用戶虛擬設備驅動程序的動態加載
　　虛擬驅動在內核中的功能通過動態加載方式實現。通常的動態加載方式是將驅動程序作為一個整體模塊，在需要時再加入內核^[6]；由于多用戶接入方式使得在某一時刻內核中注冊的接口單元數量不確定，如果實施一次性加載會冗余太多，不利于資源的有效利用。因此，在內核中加載一個基本模塊的前提下，實現各虛擬設備的動態加載過程，達到以一個基本的虛擬設備控制多個設備驅動模塊的功能。
　　如圖4所示，對虛擬驅動設備的控制由內部通信模塊與設備管理模塊共同完成。設備管理模塊通過內部通信模塊下達加載、卸載虛擬驅動的命令，通過內部通信模塊與虛擬驅動的控制通道進行。內部通信模塊通過調用ioctl()采用不同的命令字完成對虛擬驅動模塊的控制過程。

　　基本驅動模塊的加載采用通常的驅動模塊加載方式，即調用module_init()函數進行基本模塊的初始化及在內核中的注冊過程。以該基本驅動模塊為基礎，當內部通信模塊收到加載某個用戶設備接口的命令后，通過調用該基本模塊的Base_ioctl()在內核中注冊一個新的驅動設備，該注冊設備才是與實際接口單元相對應的虛擬驅動模塊，應用程序對用戶設備數據的讀寫都是通過這些注冊的接口設備而非基本設備提供的標準函數進行。這樣的動態加載過程使得當沒有設備加載時在內核中只存在一個基本的虛擬驅動模塊，只有需要注冊的用戶才將其對應的設備接口的虛擬驅動模塊加載到內核中，從而減少系統冗余，便于管理。
　　各用戶接口單元與虛擬驅動的數據交互通過內部通信模塊與虛擬驅動的數據通道進行，所對應的系統調用為該注冊設備的dev_ioctl()。在該功能函數中，實現用戶空間與內核空間的數據交互。
3.2 對多用戶接口設備虛擬驅動的管理
　　為實現內核虛擬驅動模塊與實際接口單元的一一對應，必須解決各驅動模塊的命名原則問題。將每個實際接口單元在接入段拓撲中的位置設置為不同的參數，在內部通信中這些參數作為傳輸數據的報頭信息出現，根據它們可以生成一個唯一的字符串作為對應該接口單元的虛擬驅動設備名稱，而且根據設備名稱亦可還原出實際接口單元的拓撲信息，以供內部通信使用。在內核中維護一個由各注冊設備名稱所組成的動態鏈表，每個鏈表節點維護一個收發報文的數據隊列，虛擬驅動與其他模塊的數據交互都通過該鏈表進行。
3.3 對虛擬設備數據讀寫過程
　　對數據的讀寫過程主要是在虛擬驅動模塊、內部通信模塊及上層控制軟件之間進行。虛擬驅動模塊運行在內核空間，而內部通信模塊運行在用戶空間，因此，主要解決用戶空間與內核空間的數據傳遞問題。通過memcpy_tofs()及memcpy_fromfs()系統調用用戶空間與內核空間的數據交互。
　　在內核中維護一個由各注冊設備名稱所組成的動態鏈表，每個鏈表節點維護一個收發報文的數據隊列，虛擬驅動與其他模塊的數據交互都通過該鏈表進行。接收報文過程：內部通信模塊將從接口單元接收的報文通過ioctl()調用傳給虛擬驅動。該函數通過struct net_device *dev結構找到對應的虛擬設備的dev_ioctl()功能函數，調用memcpy_fromfs()將數據拷貝至內核空間，經過處理后通過netif_rx()函數通知上層協議有數據傳入。發送報文過程：虛擬驅動將從上層軟件取出的數據放至自身維護的通過虛擬接口設備名稱維護的數據隊列中，內部通信模塊通過ioctl()論詢各接口設備數據隊列是否有數據可讀，如果有數據，虛擬驅動通過memcpy_tofs()調用將數據拷貝至用戶空間提供的緩沖區中。
　　文中針對大規模用戶接入方式的特性，討論了一種基于ACR/Tbit路由器的硬件抽象層的通用性軟件結構設計及實現方式，并研究了其關鍵技術，包括基于UDP傳輸方式的內部通信的可靠性實現及基于多用戶的動態模塊加載技術，適用于路由器承載業務量的擴展和多用戶接入特性，并且在上層軟件實現中，基本上可以不考慮底層硬件細節，增強了路由器的開放性及可擴展性。