分散式快速埠掃描的任務調度演算法與協議研究

摘要：隨著埠掃描技術的發展，一些如ZMap、MASSCAN等的單節點快速埠掃描工具相繼被提出，從而最大限度地利用帶寬資源進行埠掃描。然而，這些工具的性能受制於單節點的帶寬，提升空間較為有限。為了進一步提升這些工具的性能，提出了一種分散式任務調度演算法及其配套協議，可用於實現一套分散式的快速埠掃描系統。該演算法將目標地址進行分片後，下發給所有可用的掃描節點同時進行埠掃描，理論上能夠利用所有節點的帶寬資源。此外，該演算法還具備一些異常處理機制，用於保證系統的可用性和結果的準確性。

正文內容：

0 引言

隨著互聯網的蓬勃發展，接入互聯網的設備數量呈現快速增長趨勢，其中不乏一些關鍵基礎設施（Critical Infrastructure，CI）[1]。互聯網的接入固然帶來了效率提升，但也為原來的系統引入新的攻擊。一些高級持續性威脅（Advanced Persistent Threat，APT）[2]往往利用其中一些存在脆弱性（Vulnerability）的網路設備進行初步攻擊。此外，一部分網路設備可能還將淪落為攻擊者的利用工具，如2016年爆發的Mirai殭屍網路事件[3]等。如果受攻擊的對象為一些關鍵基礎設施，社會的運行秩序必定受到威脅。

在日益增長的網路空間安全需求下，快速採集這些網路設備的基本信息成為具有特殊意義的事情。一般情況下，相關維護人員可通過採集到的網路設備信息，對當前網路的安全性進行有數據支撐的評估；在重大漏洞被披露時，安全響應人員也能通過這些信息快速定位受影響的設備，並根據影響範圍制定針對性的修復方案，將影響降至最低。為了滿足快速採集信息的要求，本文提出一種用於適用於分散式快速埠掃描的任務調度演算法與協議，結合現有的無狀態埠掃描技術，能夠大幅度提升埠掃描的效率，進而提升網路設備信息採集的速度。

1　背景介紹

為了面向整個互聯網進行信息探測，首先需要對互聯網中的網路設備進行快速埠掃描。傳統的TCP埠掃描由於需要完成完整的TCP握手過程，系統內核中也需要維護當前的TCP連接的一些狀態，導致其進行埠掃描時速度較慢，內存消耗也比較明顯。由於這些缺陷，一些不需要系統內核維持TCP狀態的掃描工具相繼被設計。其中，最具代表性的有：在1 Gb帶寬下，能夠在45 min內完成整個IPv4地址空間掃描的ZMap[4]；在10 Gb帶寬環境下，能夠在6 min內進行全網埠掃描的MASSCAN[5]。然而，這些工具的缺點也較為明顯，主要體現在以下兩點：

（1）這些工具的掃描速率受限於帶寬，而帶寬與成本的關係並不是線性的，而是較高的掃描速率意味著更高的成本。

（2）頻繁掃描某個目標網段，可能會觸發目標網路的邊界防火牆，影響結果。ZMap通過偽隨機的方式避免在較短時間內連續掃描通過網段[6]，但由於ZMap為單節點掃描器，在掃描速率過高時仍然可能導致出口IP被目標網段的防火牆所封禁。

為了解決上述兩個問題，本文採用一種分散式的埠掃描架構。該架構採用多節點共同掃描，增加節點數，即可接近線性地提升整個架構的掃描效率。此外，由於採用多節點機制，可通過一些調度演算法，將連續網段的掃描任務分攤給多個節點，降低被目標網段封禁的概率。為了使得該分散式架構能夠高效工作，本文研究並提出了與之相匹配的一套任務調度演算法與通信協議。該演算法與協議具備以下優點：

（1）調度演算法將連續IP地址的埠掃描通過任務分割下發給不同的節點執行，避免單節點因為掃描速率過高而受到封禁。此外，該演算法生成的任務數據非常小。

（2）通信協議能夠將構造儘可能小的數據包用於傳遞下發任務數據、任務執行結果以及其他的一些輔助數據包。

2　任務調度演算法

2.1　整體架構

本文任務調度演算法面向的架構如圖1所示。該架構通過使用一個任務調度節點進行統一的任務調度工作，並負責將任務信息與任務執行結果存入資料庫中。該架構的掃描節點僅需與任務調度節點建立通信。該架構的優點在於實現簡單，只有兩種類型的節點，且掃描節點之間是解耦和的。

一個埠掃描任務在該分散式系統中的執行可簡化為如圖2所示的流程。用戶在通過任務調度節點下發一個掃描任務後，任務調度系統會使用本文所提出的演算法切割該任務，並將切割後的子任務存入資料庫中。在有空閑的掃描節點上線後，任務調度節點會將一部分子任務下發給這些節點，並由這些節點進行埠掃描任務。在掃描節點完成埠掃描後，掃描結果會重新經由任務調度節點存入資料庫中。

由該系統的架構可看出，任務調度演算法主要包含任務切割和任務調度兩部分。

2.2　任務切割

任務切割指將待掃描的CIDR地址切割成若干個子集，主要作用是使多個掃描節點具備同時執行同一個掃描任務的能力，並且避免單個節點連續地、高頻率地掃描同一個目標網段。定義待掃描的IPv4地址空間為集合A ，通過任務切割可生成i 個子集，第個子集記為Ai ，那麼應滿足：

條件一：且；

條件二：為了避免連續掃描某個網段的頻率過高，Ai 還應滿足其成員在A 中的分布足夠均勻；

條件三：由於Ai 最終需要下發給掃描節點，而對於埠掃描任務而言，帶寬是一類核心資源。承載Ai 的數據包如果太大，不但增加了節點的網路負擔，而且更長的任務傳輸時間也嚴重影響整個系統的掃描效率。因此，承載Ai 的數據包應當是高度可壓縮的，即應滿足Ai 的熵足夠低，可使用極少的數據單位表示。

如果採用隨機化演算法，即從A 從隨機挑選一些成員用於構成Ai ，那麼將不能滿足條件一和條件三。

2.2.1　地址分片

ZMap的研究人員在一篇關於提升ZMap速度的論文中提出了地址生成分片（Address Generation Sharding）技術[6]。定義集合A 的大小為m ，其成員為a1,a2,…,am ，那麼該技術切割出來的子集滿足Ai= ，其中。該技術的初衷在於簡化地址生成的計算量，消除ZMap內部的一個互斥鎖。雖然它的主要目的是為了提升單節點掃描時的性能，但經過分析不難發現，該方法同時滿足了條件一、條件二以及條件三的前半部分。如果能使得該方法滿足所有條件，那麼其將是一個非常好的適用於分散式的任務切割演算法。

根據IANA發布的特殊用途IPv4地址[7]，一部分IPv4地址被作為內網地址。該系統應具備由用戶設定IPv4地址黑名單的功能，用於過濾特定IPv4地址的掃描結果。定義這些地址的集合為E ，那麼在執行埠掃描時應排除E ，以提升掃描速度。為了達到此目的，下發給掃描節點i 進行掃描探測的實際任務數據應當為Ai-E ，難以使用極少的數據單位進行表示。

注意到，在進行任務下發時，下發給不同掃描節點的E 實際上一致的。當且僅當用戶設定新的黑名單時，E 才會改變。因此，可設計一種機制，在用戶設定新黑名單時，預先將E 推送給掃描節點。在該機制下，調度節點每次下發給任務節點的數據僅需包含Ai 。又因為Ai 僅需要第一個成員、成員的間隔與成員上限即可還原所有成員，那麼該任務數據僅需3個數據單位 即可表示，滿足條件三後半部分。調度節點進行地址分片與掃描節點進行掃描地址還原的偽代碼如下：

function split_address(task_id,cidr,n):

first_addr,last_addr←cidr_to_integer(cidr)

for i←0…n-1:

task←

store_task(task)

function generate_addresses(task):

current_addr,last_addr,n←task

while current_addr≤last_addr:

yield integer_to_ipv4(current_addr)

current_addr←current_addr+n

2.2.2　分片優化

解決地址分片問題後，還得考慮分片數量n 的取值問題。n 如果比掃描節點的數量小，那麼部分掃描節點可能無法分配到掃描任務，浪費了一部分節點的掃描能力；如果n 取值過大，那麼將導致下發任務中的目標較少，掃描節點頻繁與從調度節點請求任務數據，將浪費部分帶寬資源。

為了充分利用各個掃描節點，可以將 設置成活躍掃描節點的數量。每當一個新的掃描節點連接調度節點時，n 的值加一。這樣在不考慮其他印象因素的前提下，最終的地址分片數與節點的數量一致，保證了每個節點均能分配到相應的掃描任務。然而，這種方法仍有較大缺陷。考慮到兩個掃描節點的帶寬不可能完全一致，某些掃描節點的出口帶寬可能有1 Gb/s，而另外一個節點僅有100 Mb/s，顯然分配同樣數量的IPv4地址是不合理的。為了解決這個問題，本文使用了一種加權分片的演算法。

對於任意一個掃描節點Si ，其在連接調度節點前可預先被賦予一個權值

。當Si 連接調度節點時，Wi 被發送到調度節點並被後者所記錄。調度節點在進行地址分片時，取n=W1+ W2+ W3+… ，並最終產生n 個IPv4的地址分片。向Si 下發掃描任務時，調度節點挑選出Wi 個地址分片，並將其組合成一個任務數據包，一次性推送給Si 。由於本演算法中表示一個地址分片只需3個數據單位，則該任務數據包總共只需使用3xWi 個數據單位。

2.3　任務調度

為了實現分散式快速埠掃描，任務調度節點應當具備與所有可用的節點建立通信能力，並在有新任務時，將切割後的地址分片下發給各個掃描節點。為了保證掃描結果的準確性，當一個掃描節點出現異常時，任務調度節點應當具備某種機制，重新掃描受影響的地址分片。上述流程涉及到節點管理、任務通信與異常處理三個部分。

2.3.1　節點管理

掃描節點在開始工作前，首先會向任務調度節點建立一條TCP鏈路，並發送一個上線數據包，表明當前節點可以正常工作。上線數據包主要包含掃描節點Si 的ID與權值Wi 等信息。任務調度節點接收到上線數據包後，會將數據包中的信息和當前TCP鏈路保存在內存中的線性表Lstatus 中。這樣一旦有新的掃描任務，任務調度節點便可通過遍歷Lstatus 的方式尋找可用節點，並將地址分片通過對應的TCP鏈路推送給掃描節點。整個節點上線的過程由掃描節點主動發起，任務調度節點自動處理。因此，增刪掃描節點的過程不影響其他掃描節點和任務調度節點。

網路通信並不是絕對可靠的，掃描節點也存在宕機的可能性。一旦某個掃描節點不可用，繼續將地址分片下發給該節點顯然是無意義的。因此，任務調度節點必須維護掃描節點的可用狀態。為了反饋可用狀態，掃描節點會每隔一段時間（記為Td ）向任務調度節點發送一個心跳包，表明該節點一切正常。如果任務調度節點在一定時間（記為Tover ）內未收到掃描節點Si 的心跳包，那麼可認為Si 不可用。考慮到網路的時延、抖動等因素，Tover 的值應當大於Td 。本文中，取Tover =2.5xTd 。

如果一個掃描節點正在執行掃描任務，那麼任務調度節點在進行任務下發時，應優先忽略這些節點。為了達成該目的，掃描節點發送給任務調度節點的心跳包中，還包含當前節點的忙碌狀態。任務調度節點在接收到掃描節點Si 的心跳包後，會主動更新節點Lstatus 中對應的狀態值，供任務下發過程參考。綜上所述，線性表Lstatus 的關鍵結構如圖3所示。

注意到，由於所有掃描節點的權值的總和n 決定了地址分片的數量，每當一個新掃描節點連接任務調度節點或一個既有的掃描節點出現宕機等狀況時，n 的取值需要進行適當變更。

2.3.2　任務通信

進行任務下發時，任務調度節點知道目標掃描節點的權值Wi ，會直接從資料庫中挑選Wi 個地址分片，與待掃描的埠號組合成一個數據包發送給掃描節點。掃描節點在完成這些分片的掃描探測任務後，情況略微有點區別。定義掃描節點Si 最終產生的掃描結果為Ri ，由於Si 掃描的地址分片不一定會產生掃描結果，Ri 可能是空的，也有可能包含若干條記錄。

由於Ri 是變長的，存在兩種特殊情況，一是Ri 為空集，二是Ri 的記錄數非常大。對於第一種情況，掃描節點仍然需要向任務調度節點發送一個數據包，告訴後者當前掃描任務已經完成。對於第二種情況，如果將Ri 一次性返回給任務調度節點，那麼網路傳輸時間相對較長。網路通信並不是絕對可靠的，掃描節點也並非絕對穩定。如果發生網路暫時不可用或節點宕機等情況，那麼將導致所有的掃描結果丟失。此外，在第二種情況下，由於Ri 的體積較大，伺服器在進行數據包構造或解析時，可能需要消耗大量的內存資源。為了解決上述問題，本文為每個回傳給任務調度節點的數據包所包含的記錄數設置一個上限，Ri 會被切割成若干個不超過該上限的子集分別發送給任務調度節點。該過程的偽代碼如下：

function process_task(task):

Port←resolve_task_port(task)

while ipv4←generate_addresses(task):

result←scan(ipv4, port)

if result=?:

continue

put_into_buffer(result)

if buffer_reach_limit():

send_and_clear_buffer()

send_and_clear_buffer()

該過程的優勢主要在於部分掃描結果可以預先返回給任務調度節點，掃描節點只需要維護一個相對較小的用於容納掃描結果的緩衝區，有效降低了數據包在構造或解析時所需使用的內存資源。

2.3.3　異常處理

分散式快速埠掃描中可能出現的異常主要有兩類，一類是因臨時性通信問題引發的異常，另一類則是因節點宕機引發的異常。

對於第一類異常，由於臨時性通信問題，掃描結果可能無法返回給任務調度節點。注意到，掃描節點Si 返回結果Ri 的過程時冪等的，即多次返回Ri 並不會影響最終結果的準確性。因此，處理該異常方式也較為簡單，即發現異常時重新返回 Ri。掃描節點在回傳結果數據包時，任務調度節點會返回一個確認數據包。如果掃描節點沒有接收到對應的確認數據包，那麼說明任務調度節點沒有接收到對應的掃描結果，或者確認數據包在傳輸途中因為某種原因丟失。此時，掃描節點會重新發送該掃描結果，直到接收到對應的確認數據包。當然，掃描節點不會無限次重發該掃描結果，當重試次數超過一個預設的值時，該掃描結果即被丟棄。

對於第二類異常，掃描節點宕機將會導致下發給當前節點的掃描任務永遠不會返回掃描結果。由於本文的任務調度演算法中，掃描節點每隔一定的時間Td 就會向任務調度節點發送一個心跳包，當超過Tover 後仍未接收到節點的心跳包，即可認為節點宕機。因此，任務調度節點會不斷檢查線性表Lstatus 中上次心跳包的時間戳，一旦發現其與當前系統的時間戳的差值超過Tover 且對應節點處於忙碌狀態，那麼將其視為宕機，並將下發給對應節點的地址分片重新進行下發操作。

第二類異常中還存在一種特殊情況，如掃描節點在發送完一個心跳包後宕機，重啟後又發送了一個心跳包，且兩個心跳包的間隔不超過Tover 。這種情況下，上文中提及的異常處理機制不會被觸發，之前下發給當前節點的掃描任務同樣不會返回任何掃描結果。為了解決該問題，掃描節點在發送上線數據包時，任務調度節點會首先檢查之前是否給當前節點下發過掃描任務，若是，則同樣重新下發該掃描任務涉及的地址分片。

3　通信協議

提出的任務調度演算法依賴於節點間的通信，因此與任務調度演算法對應的，本文提出了一種基於TCP的通信協議。該通信協議在滿足任務調度基本需求的基礎上，著重於提升通信效率、保密性。此外，該通信協議還預留了一些用於版本兼容的特性。

3.1　通信協議的封裝

TCP是一類數據流傳輸協議，而任務調度演算法中發送數據以包為單位，因此本文提供了一種應用層的封裝協議。該協議結構如圖4所示。其中，版本號部分用於表示當前協議的版本號，當前協議中版本號為1；屬性部分則用於表示當前數據包的一些屬性，擁有4 bits的空間。由於任務調度演算法中，不同的掃描節點擁有不同的ID，此處使用3 Bytes用於容納客戶端ID；時間戳與內容長度部分均為4 Bytes的無符號整數，分別用於表示發包時的Unix時間戳與數據部分的內容長度。

由於系統的迭代開發可能導致通信協議的變更，數據包頭部定義了版本號部分可用於滿足協議的向前、向後兼容性方面的需求。此外，屬性部分目前只使用了3 bits，預留了1 bits用於未來增加一些新的數據包屬性。這樣即使未來增加了一些新屬性，整個數據包的結構也不會發生較大變化。

當前協議版本中，屬性部分的第1個比特位用於表示數據部分是否被壓縮過。一些諸如掃描結果之類的數據包，數據部分體積可能相對較大，進行壓縮後可以大幅度降低數據包的大小；而另外一些如用於下發任務數據的數據包，原始數據可能只需要十幾個位元組，壓縮後的數據大小甚至可能超過原數據的體積，進行壓縮顯然沒有必要。考慮到上述兩種情況，數據部分可根據實際情況選擇壓縮與否。因此，本通信協議中使用了一個單獨的屬性位用於表示數據部分是否被壓縮。當屬性部分的第一個比特位為1時，表示數據部分使用GZIP[8]演算法壓縮過，在進行解析操作前，必須先對數據部分進行解壓縮。

屬性部分的第2個比特位目前恆置為0，為未來版本的新屬性做預留。屬性的最後兩個位元組用於表示數據包類型。目前，該任務調度演算法中存在4種類型的單向數據包，分別為上線數據包、心跳包、任務數據包以及掃描結果數據包。為了區分不同的數據包，本協議將其嚴格按照上述順序從0開始編號，故使用2個比特位即可區分4種數據包。若未來的協議版本中擁有更多類型的數據包，可考慮使用屬性的第2個比特位。由於任務調度演算法中的異常處理機制，正常情況下，每種數據包在發送後均會接收到一個與之相對應的確認數據包。為了區分不同的確認數據包，本協議嚴格遵循確認數據包的類型編號與原數據包始終一致的原則。以心跳包為例，其類型編號為1，掃描節點將心跳包發送給任務調度節點後，將接收到一個類型編號同樣為1的確認數據包。

為了區分不同的掃描節點，每個掃描節點擁有一個與眾不同的客戶端ID。本協議中，使用單獨的3位元組表示該客戶端ID。對於任務調度節點而言，本身不需要客戶端ID，故客戶端ID始終代表通信雙方中掃描節點的ID。此外，數據包中還使用了一個單獨的欄位指明了發包時的時間戳。本協議依賴上述兩個欄位實現數據包的保密性與客戶端的身份認證。本協議要求每個客戶端ID對應不同的預置共享密鑰（Pre-Shared Key，PSK），在進行數據傳輸時，必須使用PSK對原始數據進行AES加密。為了實現客戶端的身份認證，本協議還要求原始數據的前4個位元組必須與數據包頭部中的時間戳部分完全一致。這樣當接受數據包的一方使用PSK進行數據解密時，可通過前4個位元組對發送方身份進行驗證。

由於TCP是一類數據流傳輸協議，本協議在數據包頭部設置了一個內容長度部分，用於確定當前數據包的邊界。內容長度部分的取值即為數據部分的長度，單位為位元組。一個合法的數據包中，數據部分的長度應與數據包頭部中的內容長度完全一致。

3.2　數據包格式

通過應用層協議的封裝，任務調度演算法已經能夠使用TCP鏈路發送數據包。出於保密性與身份認證考慮，應用層協議要求原始數據部分的前4個位元組必須為一個Unix時間戳，後續位元組則可根據實際數據包的類型採用不同的數據格式。為了適應不同數據包的不同格式，並最大限度地利用帶寬資源，此處可以採用一些緊湊小巧的通用數據格式，如Apache Thrift[9]、Protocol Buffers[10]等。本協議採用相對小巧的Protocol Buffers。定義Unix時間戳為Dtimestamp ，實際承載數據的通用數據格式部分為Dprotobuf ，最終附加到圖4中數據部分的數據為Data ，那麼有：

特別地，如果屬性部分的第一個比特位為1，那麼還需要對Data 進行GZIP壓縮。對於不同的數據包，其構造過程一致，唯一的區別在於Dprotobuf 部分。以任務數據包為例，由於其目的是從任務調度節點向掃描節點單向地傳遞任務數據，其Dprotobuf 的結構如下所示：

message AddressesShard{

fixed32 first_addr=1;

fixed32 last_addr=2;

uint32 n=3;

}

message TaskPackage{

uint32 port=1;

repeated AddressesShard shards=2;

}

特別地，所有類型的數據包均有與之對應的確認數據包，其作用完全一致，故確認數據包可採用相同的數據格式。格式如下，其中acknowledged用於指明數據是否被正常接收，msg則用於附加一些調試信息。

message AcknowledgePackage{

bool acknowledged=1;

string msg=2;

}

4　演算法與協議評估

本文提出的演算法能夠利用所有可用的掃描節點對用戶下發的目標進行快速埠掃描，且各個節點掃描的目標IPv4地址互不相同，最大限度地利用了所有掃描節點的掃描能力。此外，本文設計了一些異常處理機制，當掃描節點出現異常時，任務調度節點會自動進行任務的重下發，既保證了整個系統的可用性，也提升了掃描結果的準確性。

顯然，由於演算法本身的特性，掃描效率可以隨著掃描節點的增加而提升。為了驗證系統與通信協議的可用性、異常處理機制的有效性，本文基於上述演算法與協議，使用Go語言實現了一個原型系統。該原型系統具備1個任務調度節點與2個掃描節點。其中，掃描節點接收到掃描任務後，會在一段隨機時間後返回隨機數量的掃描結果，用於模擬真實的埠掃描行為；當掃描節點完成當前掃描任務並接收到任務調度節點返回的確認數據包，掃描節點會將當前任務中所有的地址分片（記為）記錄到一個日誌文件中，用於驗證分散式調度演算法的準確性。

該原型系統的三個節點位於同一個路由器下邊。該路由器會定期重啟，用於模擬網路通信的不穩定性。在系統運行過程中，其中一個掃描節點會被人為地重啟，用於模擬宕機行為。如果上述演算法中的異常處理機制和通信協議能夠正常工作，那麼在上述環境下，用戶下發的掃描任務應當能夠正常完成，且滿足：

本文使用該原型系統進行了10次獨立實驗，發現10次實驗結果均滿足上述條件，本文演算法與協議的可用性、異常處理機制的有效性以及掃描結果的準確性得證。

5　結　語

本文提出了一套適用於分散式快速埠掃描的任務調度演算法與協議。該演算法與協議效率高，且具備一定的異常處理機制，保證了整個系統的可用性和準確性。該演算法與協議實現簡單，實證有效，對工程化實現有很高的參考價值。下一步研究將使用本文提出的演算法與協議實現一個分散式的插件式快速埠掃描系統。

參考文獻：

[1] Rinaldi S M,Peerenboom J P,Kelly T K.Identifying,Understanding,and Analyzing Critical Infrastructure Interdependencies[J].IEEE Control Systems,2001,21(06):11-25.

[2] 徐遠澤,張文科,尹一樺等.APT攻擊及其防禦研究[J].通信技術,2015,48(06):740-745.

[3] Antonakakis M,April T,Bailey M,et al.Understanding the Mirai Botnet[C].26th USENIX Security Symposium,2017:1093-1110.

[4] Durumeric Z,Wustrow E,Halderman J A.ZMap:Fast Internet-wide Scanning and Its Security Applications[C].USENIX Security Symposium,2013(08):47-53.

[5] Graham R D.MASSCAN:Mass IP Port Scanner[EB/OL].[2017-07-22].http://github. com/robertdavidgraham/masscan.

[6] Adrian D,Durumeric Z,Singh G,et al.Zippier ZMap:Internet-Wide Scanning at 10 Gbps[C].WOOT,2014.

[7] IANA.IANA IPv4 Address Space Registry[EB/OL].[2017-07-22].http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml.

[8] Gailly J L,Adler M.The Gzip Home Page[EB/OL].[2017-07-22].http://www.gzip.org/.

[9] Apache Software Foundation.Apache Thrift[EB/OL].[2017-07-22].https://thrift.apache.org/.

[10]Varda K.Protocol Buffers:Google』s Data Interchange Format[J].Google Open Source Blog,2008(07):72.

作者：林培勝，王軼駿，薛　質

單位：上海交通大學 網路空間安全學院，上海 200240

作者簡介：林培勝，男，碩士，主要研究方向為網路攻防技術；

王軼駿，男，碩士，講師，主要研究方向為網路攻防及系統安全；

薛　質，男，博士，教授，主要研究方向為計算機通信網及信息安全。

本文刊登在《通信技術》第12期（轉載請註明出處，否則禁止轉載）

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！