2011年架構師考試真題理解（筆記）

1、作業系統為使用者提供了兩類介面：操作一級的介面和程式控制一級的介面。其中操作一級的介面包括控制命令、選單命令、視窗等；程式控制一級的介面包括系統呼叫。
2、3、4、PV操作
5、6、7、關係模式和E-R圖的概念和性質。
8、
9、CISC（Complex Instruction Set Computer，複雜指令集計算機）——基本思想是進一步增強原有指令的功能，用更為複雜的新指令取代原先由子程式完成的功能，實現軟體功能的硬體化，導致機器的指令系統越來越龐大而複雜。CISC計算機一般所含的指令數目至少300條以上，有的甚至超過500條。
RISC（Reduced Instruction Set Computer，精簡指令集計算機）——基本思想是通過減少指令總數和簡化指令功能，降低硬體設計的複雜度，使指令能單週期執行，並通過優化編譯，提高指令的執行速度，採用硬線控制邏輯，優化編譯程式。
10、快取記憶體Cache用來存放當前最活躍的程式和資料，作為主存區域性域的副本，其特點是：容量一般在幾KB到幾MB之間；速度一般比主存快5到10倍，由快速半導體儲存器構成；其內容是主存區域性域的副本，對程式設計師來說是透明的。
替換演算法的目標是使Cache獲得最高的命中率。常用的演算法有隨機替換演算法、先進先出演算法、近期最少使用演算法和優化替換演算法。
Cache的效能是計算機系統效能的重要方面。命中率是Cache的一個重要指標，但不是最主要的指標。Cache設計的目標是在成本允許的條件下達到較高的命中率，使儲存系統具有最短的平均訪問時間。
Cache的命中率與Cache容量的關係是：Cache容量越大，則命中率越高，隨著Cache容量的增加，其命中率逐漸接近100%。但是增加Cache容量意味著增加Cache的成本和增加Cache的命中時間。
11、虛擬儲存器是一個容量非常大的儲存器的邏輯模型，不是任何實際的物理儲存器。它藉助於磁碟等輔助儲存器來擴大主存容量，使之為更大或更多的程式所使用。虛擬儲存器管理方式分為頁式虛擬儲存器、段式虛擬儲存器和段頁式虛擬儲存器。
虛擬儲存器是由硬體和作業系統自動實現儲存資訊排程和管理的。它的工作過程包括6個步驟：
①中央處理器訪問主存的邏輯地址分解成組號a和組內地址b，並對組號a進行地址變換，即將邏輯組號a作為索引，查地址變換表，以確定該組資訊是否存放在主存內。
②如該組號已存在主存內，則轉而執行④；如果該組號不在主存內，則檢查主存中是否有空閒區，如果沒有，便將某個暫時不用的組調出送往輔存，以便將需要訪問的資訊調入主存。
③從輔存讀出所要的組，並送到主存空閒區，然後將那個空閒的物理組號a和邏輯組號a登記在地址變換表中。
④從地址變換表讀出與邏輯組號a對應的物理組號a。
⑤從物理組號a和組內位元組地址b得到實體地址。
⑥根據實體地址從主存中存取必要的資訊。
頁式排程是將邏輯和實體地址空間都分為固定大小的頁。主存按頁順序編號，而每個獨立編址的程式空間有自己的頁號順序，通過排程，輔存中程式的各頁可以離散裝入主存中不同的頁面位置，並根據頁表一一對應檢索。
12、匯流排是一組能為多個部件分時共享的資訊傳送線，用來連線多個部件併為之提供資訊交換通路。所謂共享，指連線到匯流排上的所有部件都可通過它傳遞資訊；分時性指某一時刻只允許一個部件將資料傳送到匯流排上。因此，共享是通過分時實現的。
13、核心層交換機一般都是三層或三層以上的交換機，採用機箱式的外觀，具有很多冗餘的部件。在進行網路規劃設計時，核心層的裝置通常要佔大部分投資，因為核心層是網路的高速主幹，需要轉發非常龐大的流量，對於冗餘的能力、可靠性和傳輸速度方面要求較高。
核心層交換機還需要支援鏈路聚合功能，以確保為分佈層交換機傳送到核心層交換機的流量提供足夠的頻寬。核心層交換機還應支援聚合萬兆連結。這樣可以讓對應的分佈層交換機儘可能高效的向核心層傳送流量。Qos是核心層交換機提供的重要服務之一。
策略路由是一種比基於目標網路進行路由更加靈活的資料包路由轉發機制。應用了策略路由，路由器將通過路由圖決定如何對需要路由的資料包進行處理，路由圖決定了一個資料包的下一跳轉發路由器。
14、結構化佈線系統分為六個子系統：工作區子系統、水平子系統、幹線（垂直）子系統、裝置間子系統、管理子系統和建築群子系統。
幹線（垂直）子系統是由裝置間（如計算機房、程控交換機房等）提供建築中最重要的銅線或光纖線主幹線路構成，是整個建築的資訊交通樞紐。一般它提供位於不同樓層的裝置間和佈線框間的多條連線路徑，也可以連線單層樓的大片區域。
15、一個網路系統從構思開始，到最後被淘汰的過程稱為網路生命週期。一般來說，網路生命週期應該包括系統的構思和計劃、分析和設計、以及執行和維護的全過程。網路系統的生命週期是一個迴圈迭代的過程，每次迭代的動力都來自於網路應用需求的變更。每一個迭代週期都是網路重構的過程。常見的迭代週期可以分為以下五個階段：需求規範、通訊規範、邏輯網路設計、物理網路設計、實施階段。
邏輯網路設計是指根據使用者需要確定網路建設的方案，包括拓撲結構規劃、地址分配、網路技術和伺服器的選擇等。物理網路設計的任務是選擇符合邏輯效能要求的傳輸介質、裝置、部件和場所等，並將他們搭建成一個可以正常執行的網路。
16、負載均衡一般由服務端安裝的附加軟體來實現，通過採用負載均衡技術，系統的吞吐量會得到增加。負載均衡可以在不同地理位置、不同網路結構的伺服器叢集之間進行，採用負載均衡技術，使用者可以僅通過IP地址或域名訪問相應的伺服器。
17、
18、19、關鍵要判斷在進行整合時，需要資料庫中的單表還是多表進行資料整合。如果是單表即可完成整合，則可以將該表包裝為記錄，採用主動記錄的方式進行整合；如果需要多張表進行資料整合，則需要採用資料對映的方式完成資料整合與處理。
20、21、針對題幹描述，該企業進行系統整合時，“業務系統的執行平臺和開發語言差異較大，而且系統所使用的通訊協議和資料格式各不相同”。在這種情況下，需要採用匯流排技術對傳輸協議和資料格式進行轉換與適配。當需要整合並靈活定義系統功能之間的協作關係時，應該採用基於工作流的功能關係定義方式。
22、軟體產品配置是指一個軟體產品在生存週期各個階段所產生的各種形式和各種版本的文件、計算機程式、部件以及資料的集合。該集合的每一個元素稱為該產品配置中的一個配置項。配置項主要有一下兩大類。
屬於產品組成部分的工作成果，如需求文件、設計文件、原始碼和測試用例等。
屬於專案管理和機構支撐過程域產生的文件，如工作計劃、專案質量報告、專案跟蹤報告等。這些文件雖然不是產品的組成部分，但是值得儲存。
23、軟體質量是指反映軟體系統或軟體產品滿足規定或隱含需求的能力的特徵和特性全體。軟體質量管理是指對軟體開發過程進行獨立的檢查活動，由質量保證、質量規劃和質量控制三個主要活動構成。軟體質量保證是指為保證軟體系統或軟體產品滿足使用者要求的質量而進行的有計劃、有組織的活動，其目的是生產高質量的軟體。軟體評審是軟體質量保證的主要活動之一。
24、需求跟蹤包括編制每個需求與系統元素之間的聯絡文件，這些元素包括別的需求、體系結構、其他設計部件、原始碼模組、測試、幫助檔案和文件等。跟蹤能力資訊使變更影響分析十分便利，有利於確認和評估實現某個建議的需求變更所必須的工作。
利用需求跟蹤能力鏈可以跟蹤一個需求使用的全過程，也就是從初始需求到實現的前後生存期。跟蹤能力是優秀需求規格說明書的一個特徵，為了實現跟蹤能力，必須統一地標識出每一個需求，以便能明確的進行查閱。
客戶需求向前追溯到軟體需求。這樣就能區分出開發過程中或者開發結束後，由於客戶需求變更受到影響的軟體需求，這也可以確保軟體需求規格說明包括了所有客戶需求。
從軟體需求回溯相應的客戶需求。這也就是確認每個軟體需求的源頭。如果使用例項的形式來描述客戶需求，那麼客戶需求與軟體需求之間的跟蹤情況就是使用例項和功能性需求。
從軟體需求向前追溯到下一級工作產品。由於開發過程中系統需求轉變為軟體需求、設計、編碼等，所以通過定義單個需求和特定產品元素之間的（聯絡）鏈，可以從需求向前追溯到下一級工作產品。這種聯絡鏈告訴我們每個需求對應的產品部件，從而確保產品部件滿足每個需求。
從產品部件回溯到軟體需求。說明了每個部件存在的原因。如果不能把設計元素、程式碼段或測試回溯到一個需求，可能存在“畫蛇添足”的程式。然而，如果這些孤立的元素表明了一個正當的功能，則說明需求規格說明書漏掉了一項需求。
25、需求定義的過程也就是形成需求說明書的過程，通常有兩種需求定義的方法：嚴格定義方法和原型方法。
嚴格定義方法也稱為預先定義，需求要嚴格建立在以下基本假設之上：
①所有需求都能夠被預先定義。這意味著在沒有實際系統執行經驗的情況下，全部的系統需求均可通過邏輯推斷得到。但這種假設在許多場合是不能成立的。
②開發人員與使用者之間能夠準確而清晰地交流。
③採用圖形（或文字）可以充分體現最終系統。在使用嚴格定義需求的開發過程中，開發人員與使用者之間交流與溝通的主要工具是定義報告，包括文字、圖形、邏輯規則和資料字典等技術工具。
原型化的需求定義過程是一個開發人員與使用者通力合作的反覆過程。從一個能滿足使用者基本需求的原型系統開始，允許在開發過程中提出更好的要求，根據使用者的要求不斷地對系統進行完善，它實質上是一種迭代的迴圈型的開發方式。採用原型方法是需注意以下幾個問題：
①並非所有的需求都能在系統開發前被準確地說明。
②專案干係人之間通常都存在交流上的困難。
③需要實際的、可供使用者參與的系統模型。
④有合適的系統開發環境。
⑤反覆是完全需要和值得提倡的。需求一旦確定，就應該遵從嚴格定義的方法。
26、軟體需求工程是包括建立和維護軟體需求文件所必須的一切活動的過程，可以分為需求開發和需求管理兩大工作。需求開發包括需求獲取、需求分析、編寫需求規格說明書（需求定義）和需求驗證4個階段。在需求開發階段需要確定軟體所期望的使用者型別，獲取各種使用者型別的需求，瞭解實際的使用者任務和目標，以及這些任務所支援的業務需求。
需求管理是一個對系統需求變更、瞭解和控制的過程，通常包括定義需求基線、處理需求變更和需求跟蹤方面的工作。需求管理強調：控制對需求基線的變動；保持專案計劃與需求的一致；控制單個需求和需求文件的版本情況；管理需求和聯絡鏈，或者管理單個需求和其他專案可交付產品之間的依賴關係；跟蹤基線中的需求狀態。
需求開發與需求管理是相輔相成的，需求開發是主線、目標；需求管理是支援、保障。
27、28、RUP（Rational Unified Process，統一軟體開發過程）
RUP軟體開發生命週期是一個二維的軟體開發模型，其中有9個核心工作流，分別為：業務建模、需求、分析與設計、實現、測試部署、配置與變更管理、專案管理以及環境。
RUP把軟體開發生存週期劃分為多個迴圈，每個迴圈生成產品的一個新的版本，每個迴圈依次由4個連續的階段組成，每個階段完成確定的任務。這4個階段分別為：
初始階段：定義最終產品檢視和業務模型，並確定系統範圍。
細化階段：設計及確定系統的體系結構，指定工作計劃及資源要求。
構造階段：構造產品並繼續演進需求、體系結構、計劃，直至產品提交。
移交階段：把產品提交給使用者使用。
每個階段都有一個或多個連續的迭代組成。迭代並不是重複的做相同的事，而是針對不同用例的細化和實現。每一個迭代都是一個完整的開發過程，它需要專案經理根據當前迭代所處的階段以及上次迭代的結果，適當地對工作流中的行為進行裁剪。在每個階段結束前有一個里程碑評估該階段的工作。如果未能通過該里程碑的評估，則決策者應該做出決定，是取消該專案還是繼續該階段的工作。
與其他軟體開發過程相比，RUP具有自己的特點，即RUP是用例驅動的、以體系結構為中心的、迭代和增量的軟體開發過程。
29、30、類封裝了資訊和行為，是物件導向的重要組成部分。設計類是物件導向設計過程中最重要的組成部分，也是最複雜和最耗時的部分。在物件導向設計過程中，類可以分為三種型別：實體類、邊界類和控制類。
實體類對映需求中的每個實體。實體類儲存需要儲存在永久儲存體中的資訊。實體類對使用者來說是最有意義的類，通常採用業務領域術語命名，一般來說是一個名詞，在用例模型向領域模型的轉化中，參與者一般對應於實體類。
控制類是用於控制用例工作的類，一般由動賓結構的短語（“動詞+名詞”或“名詞+動詞”）轉化而來的名詞。控制類用於對一個或幾個用例所特有的控制行為進行建模，控制物件（控制類的例項）通常控制其他物件，因此它們的行為具有協調性。
邊界類用於封裝在用例內、外流動的資訊或資料流。邊界類是一種用於對系統外部環境與其內部運作之間的互動進行建模的類，用於實現目標軟體系統與外部系統或外部裝置之間的資訊交流和互操作。
31、常用的物件導向設計原則包括開閉原則、里氏替換原則、依賴倒置原則、組合/聚合複用原則、介面隔離原則和最少知識原則等。這些設計原則首先都是面向複用的原則，遵循這些設計原則可以有效地提高系統的複用性，同時提高系統的可維護性。
最少知識原則（也稱為迪米特法則）是物件導向設計原則之一，指一個軟體實體應當儘可能少地與其他實體發生相互作用。這樣，當一個實體被修改時，就會盡可能少地影響其他的實體。
最少知識原則主要用於控制資訊的過載。在將最少知識原則運用到系統設計中時，要注意以下幾點：
①在類的劃分上，應當儘量建立鬆耦合的類，類之間的耦合度越低，就越有利於複用。一個處在鬆耦合中的類一旦被修改，不會對關聯的類造成太大波動。
②在類的結構設計上，每個類都應當儘量降低其屬性和方法的訪問許可權。
③在類的設計上，只要有可能，一個型別應當設計成不變類。
④在對其他類的引用上，一個物件對其他物件的引用應當降到最低。
32、結構化方法也稱為生命週期法，是一種傳統的資訊系統開發方法，由結構化分析、結構化設計和結構化程式設計三部分組成，其精髓是自頂向下、逐步求精和模組化設計。
結構化方法的主要特點是：開發目標清晰化、開發工作階段化、開發文件規範化和設計方法結構化。結構化方法特別適合於資料處理領域的問題，但是不適應於規模較大、比較複雜的系統開發。結構化方法的缺點是開發週期長、難以適應需求的變化、很少考慮資料結構。
物件導向方法是目前比較主流的開發方法。物件導向方法是系統的描述及資訊模型的表示與客觀實體相對應，符合人們的思維習慣，有利於系統開發過程中使用者與開發人員的交流和溝通，縮短開發週期，提高系統開發的正確性和效率。可以把結構化方法和麵向物件方法結合起來進行系統開發。首先使用結構化方法進行自頂向下的整體劃分，然後再自底向上地採用物件導向方法開發系統。
敏捷方法是從20世紀90年代開始逐漸引起廣泛關注的一種新型軟體開發方法，以應對快速變化的需求。敏捷方法是一種以人為核心、迭代、循序漸進的開發方法。敏捷方法強調，讓客戶滿意和軟體儘早增量釋出；小而高度自主的專案團隊；非正式的方法；最小化軟體工程工作產品以及整體精簡開發。與傳統方法相比，以它的靈活性來適應需求的變化。
面向服務的方法以粗粒度、鬆散耦合和基於標準的服務為基礎，增強了系統的靈活性、可複用性和可演化性。
33、34、組合（Composite）模式又稱為整體-部分（Part-whole）模式，屬於物件的結構模式。在組合模式中，通過組合多個物件形成樹形結構以表示整體-部分的結構層次。組合模式對單個物件（即葉子物件）和組合物件（即容器物件）的使用具有一致性。Composite模式的結構如下：
類Component為組合中的物件宣告介面，在適當的情況下，實現所有類共有介面的預設行為，宣告一個介面用於訪問和管理Component的子部件；
類Left在組合中表示葉結點物件，葉結點沒有子結點，並在組合中定義圖元物件的行為；
類Composite定義有子部件的那些部件的行為，儲存子部件，並在Component介面中實現與子部件有關的操作；
類Client通過Component介面操縱組合部件的物件。
35、36、企業戰略資料模型可分為資料庫模型和資料倉儲模型，資料庫模型用來描述日常事務處理中的資料及其關係了資料倉儲模型則描述企業高層決策者所需資訊及其關係。在企業資訊化過程中，資料庫模型是基礎，一個好的資料庫模型應該客觀地反映企業生產經營的內在聯絡。
37、企業資訊化建設的核心和本質是企業運用資訊科技，進行知識的挖掘，對業務流程進行管理。企業資訊化的實施，可以沿著兩個方向進行，自上而下方法必須與企業的制度創新、組織創新和管理創新相結合；自下而上方法必須以作為企業主體的業務人員的直接收益和使用水平逐步提高為基礎。
38、企業業務流程重構是利用資訊和網路技術，對企業的組織結構和工作方法進行“徹底的、根本性的”重新設計，以適應當今市場發展和資訊社會的需求。核心業務應用方法是圍繞核心業務應用計算機和網路技術，這是很多企業資訊化成功的祕訣和有效途徑。在業務數量浩繁並且流程錯綜複雜的大型企業裡，建設覆蓋整個企業的資訊系統往往很難成功，各個部門的區域性開發和應用又有很大的弊端，會造成系統嚴重分隔，形成許多“資訊孤島”，造成大量的無效或低效投資。常見的資源管理方法有ERP（企業資源規劃）和SCM（供應鏈管理）。人力資本與人力資源的主要區別是人力資本理論把一部分企業的優秀員工看作是一種投資，能夠取得投資收益。
39、外部設計處於軟體設計的開始階段，主要是按系統需求說明來確定此係統的軟體結構和對應於系統需求說明，設計出各個功能部分的功能和介面。內部設計處於軟體工程中的概要設計階段，按照外部設計中確立的系統軟體結構，來細化此係統各個功能部件以及各個部件介面的設計，並且詳細給出各個功能部件詳細的資料輸入、輸出設計。內部設計細化外部設計中的各種功能。
40、原型是軟體系統的初始版本，用來演示概念並嘗試設計選擇，通常用來發現更多的問題和可能的解決方案。快速迭代式的原型開發能夠有效控制成本，根據原型與最終產品之間的關係，原型開發分為三類：拋棄式原型開發利用原型驗證和澄清系統的需求描述，重新構造系統；演化式原型開發逐步改進和細化原型，將原型進化至產生出目標系統；增量式原型開發在建立軟體總體設計的基礎上，採用增量開發方法，使原型稱為最終系統。
41、靜態分析通過解析程式文字，從而識別出程式語句的各個部分，審查可能的缺陷和異常之處，靜態分析包括五個階段：控制流分析階段找出並突出顯示那些帶有多重出口或入口的迴圈以及不可達到的程式碼段；資料使用分析階段突出程式中變數的使用情況；介面分析階段檢查子程式和過程宣告以及它們使用的一致性；資訊流分析階段找出輸入變數和輸出變數之間的依賴關係；路徑分析階段找出程式中所有可能的路徑並畫出此路徑中執行的語句。
42、確認測試主要用於驗證軟體的功能、效能和其他特性是否與使用者需求一致。根據使用者參與程度，通常包括以下4種型別。
①內部確認測試。內部確認測試主要由軟體開發組織內部按照軟體需求規格說明書進行測試。
②α測試和β測試。對於通用產品型的軟體開發而言，α測試是指由使用者在開發環境下進行測試，通過α測試以後的產品通常稱為α版；β測試是指由使用者在實際使用環境下進行測試，通過β測試的產品通常稱為β版。一般在通過β測試後，才能把產品釋出或交付給使用者。
③驗收測試。驗收測試是指標對軟體需求規格說明書，在交付前以使用者為主進行的測試。其測試物件為完整的、整合的計算機系統。驗收測試的目的是，在真實的使用者工作環境下，檢驗軟體系統是否滿足開發技術合同或軟體需求規格說明書。驗收測試的結論是使用者確定是否接收該軟體的主要依據。
系統測試的目的是在真實系統工作環境下，驗證完整的軟體配置項能否和系統正確連線，並滿足系統/子系統設計文件和軟體開發合同規定的要求。系統測試的主要內容包括功能測試、健壯性測試、效能測試、使用者介面測試、安全性測試、安裝與反安裝測試等。其中效能測試包括負載測試、壓力測試、可靠性測試和併發測試。
43、在系統交付以後，改變系統的任何工作，都可以被稱為維護。在系統執行過程中，軟體需要維護的原因是多樣的，根據維護的原因不同，可以將軟體維護分為以下4種：
①正確性（改正性）維護。改正在系統開發階段已發生而系統測試階段尚未發現的錯誤。
②適應性維護。在使用過程中，外部環境（新的硬、軟體配置）、資料環境（資料庫、資料格式、資料輸入/輸出方式、資料儲存介質）可能發生變化。為使軟體適應這種變化，而去修改軟體的過程就稱為適應性維護。
③完善性維護。在軟體的使用過程中，使用者往往會對軟體提出新的功能與效能要求。維護滿足這些要求，需要修改或再開發軟體，以擴充軟體功能、增強軟體效能、改進加工效率、提高軟體的可維護性。這種情況下進行的維護活動稱為完善性維護。
④預防性維護。這是指為了適應未來的軟硬體環境的變化，應主動增加預防性的新的功能，以使應用系統適應各類變化而不被淘汰。
44、45、架構風格描述了一類軟體架構的特徵，它獨立於實際問題，強調軟體系統中通用的組織結構選擇。垃圾回收機制是Java語言管理記憶體資源時常用的一種設計模式。
46、47、48、“4+1”檢視，用來描述軟體系統的架構。在“4+1”檢視中，邏輯檢視用來描述設計的物件模型和物件之間的關係；開發檢視描述了軟體模組的組織與管理；過程檢視描述設計的併發和同步特徵。
49、基於架構的軟體設計（ABSD）以架構風格和質量屬性為中心，強調由商業、質量和功能需求的組合驅動軟體架構設計。ABSD方法有三個基礎：功能分解、選擇架構風格實現質量及商業需求和軟體模板的使用。
50、黑板架構風格
51、直譯器架構風格
52、資料共享架構風格
53、中介者模式
54、命令模式
55、責任鏈模式
56、57、
58、59、60、架構設計策略和質量屬性的理解。軟體質量屬性通常需要採用特定的設計策略實現，並且設計策略會對其他的質量屬性產生影響。心跳機制策略能提高該系統的可用性，優先順序佇列策略能夠提高該系統的效能，限制訪問策略能夠提高該系統的安全性。
61、架構權衡分析法（ATAM）是一種常用的軟體架構評估方法，該方法強調對軟體的質量屬性進行分析、分類和優先順序排序等工作，在此基礎上構件質量屬性效用樹，並對風險點、非風險點、敏感點和權衡點進行識別和分析。
62、63、一個質量屬性會同時影響另外兩個質量屬性，描述的是一個敏感點；由於某種問題會影響系統的某種質量屬性，這是一個系統的風險點。
64、SNMP（Simple Network Management Protocol，簡單網路管理協議）
SNMPv3把對網路協議的安全威脅分為主要的和次要的兩類。標準規定安全模組必須提供防護的兩種主要威脅是：
①修改資訊（Modification of Information）：就是某些未經授權的實體改變了進來的SNMP報文，企圖實施未經授權的管理操作，或者提供虛假的管理物件。
②假冒（Masquerade）：即未經授權的使用者冒充授權使用者的標識，企圖實施管理操作。
SNMPv3標準還規定安全模組必須對兩種次要威脅提供防護：
①修改報文流（Message Stream Modification）：由於SNMP協議通常是基於無連線的傳輸服務，重新排序報文流、延遲或重放報文的威脅都可能出現。這種威脅的危害性在於通過報文流的修改可能實施非法的管理操作。
②訊息洩露（Disclosure）：SNMP引擎之間交換的資訊可能被偷聽，對這種威脅的防護應採取區域性的策略。
有兩種威脅是安全體系結構不必防護的，因為它們不是很重要，或者這種防護沒有多大作用：
①拒絕服務（Denial of Service）:因為在很多情況下拒絕服務和網路失效是無法區別的，所以可以由網路管理協議來處理，安全子系統不必採取措施。
②通訊分析（Traffic Analysis）：即由第三者分析管理實體之間的通訊規律，從而獲取需要的資訊。由於通常都是由少數管理站來管理整個網路的，所以管理系統的通訊模式是可預見的，防護通訊分析就沒有多大作用了。
65、PGP（Pretty Good Privacy）已經成為使用最廣泛的電子郵件加密軟體。
66、
67、
68、
69、
70、
71、72、73、74、75、