資料來源：http://www.cnpaf.net/Class/Ethernet/200408/403.html，中國協議分析網
一、什么是網橋？


網橋工作在數據鏈路層，將兩個LAN連起來，根據MAC地址來轉發幀，可以看作一個“低層的路由器”（路由器工作在網絡層，根據網絡地址如IP地址進行轉發）。

　

遠程網橋通過一個通常較慢的鏈路（如電話線）連接兩個遠程LAN，對本地網橋而言，性能比較重要，而對遠程網橋而言，在長距離上可正常運行是更重要的。

網橋與路由器的比較

網橋并不了解其轉發幀中高層協議的信息，這使它可以同時以同種凡是處理IP、IPX等協議，它還提供了將無路由協議的網絡（如NetBEUI）分段的功能。

由于路由器處理網絡層的數據，因此它們更容易互連不同的數據鏈路層，如令牌環網段和以太網段。網橋通常比路由器難控制。象IP等協議有復雜的路由協議，使網管易于管理路由；IP等協議還提供了較多的網絡如何分段的信息（即使其地址也提供了此類信息）。而網橋則只用MAC地址和物理拓撲進行工作。因此網橋一般適于小型較簡單的網絡。

二、使用原因


許多單位都有多個局域網，并且希望能夠將它們連接起來。之所以一個單位有多個局域網，有以下6個原因：

首先，許多大學的系或公司的部門都有各自的局域網，主要用于連接他們自己的個人計算機、工作站以及服務器。由于各系（或部門）的工作性質不同，因此選用了不同的局域網，這些系（或部門）之間早晚需相互交往，因而需要網橋。

其次，一個單位在地理位置上較分散，并且相距較遠，與其安裝一個遍布所有地點的同軸電纜網，不如在各個地點建立一個局域網，并用網橋和紅外鏈路連接起來，這樣費用可能會低一些。

第3，可能有必要將一個邏輯上單一的LAN分成多個局域網，以調節載荷。例如采用由網橋連接的多個局域網，每個局域網有一組工作站，并且有自己的文件服務器，因此大部分通信限于單個局域網內，減輕了主干網的負擔。

第 4，在有些情況下，從載荷上看單個局域網是毫無問題的，但是相距最遠的機器之間的物理距離太遠（比如超過802.3所規定的2.5km）。即使電纜鋪設不成問題，但由于來回時延過長，網絡仍將不能正常工作。唯一的辦法是將局域網分段，在各段之間放置網橋。通過使用網橋，可以增加工作的總物理距離。

第5，可靠性問題。在一個單獨的局域網中，一個有缺陷的節點不斷地輸出無用的信息流會嚴重地破壞局域網的運行。網橋可以設置在局域網中的關鍵部位，就像建筑物內的放火門一樣，防止因單個節點失常而破壞整個系統。

第6，網橋有助于安全保密。大多數LAN接口都有一種混雜工作方式(promiscuousmode)，在這種方式下，計算機接收所有的幀，包括那些并不是編址發送給它的幀。如果網中多處設置網橋并謹慎地攔截無須轉發的重要信息，那么就可以把網絡分隔以防止信息被竊。

三、兼容性問題


有人可能會天真地認為從一個802局域網到另一個802局域網的網橋非常簡單，但實際上并非如此。在802.x到802.y的九種組合中，每一種都有它自己的特殊問題要解決。在討論這些特殊問題之前，先來看一看這些網橋共同面臨的一般性問題。

首先，各種局域網采用了不同的幀格式。這種不兼容性并不是由技術上的原因造成的，而僅僅是由于支持三種標準的公司(Xerox,GM和IBM)，沒有一家愿意改變自己所支持的標準。其結果是：在不同的局域網間復制幀要重排格式，這需要占用CPU時間，重新計算校驗和，而且還有可能產生因網橋存儲錯誤而造成的無法檢測的錯誤。

第二個問題是互聯的局域網并非必須按相同的數據傳輸速率運行。當快速的局域網向慢速的局域網發送一長串連續幀時，網橋處理幀的速度要比幀進入的速度慢。網橋必須用緩沖區存儲來不及處理的幀，同時還得提防耗盡存儲器。即使是10Mb/s的802.4到10Mb/s的 802.3的網橋，在某種程度上也存在這樣的問題。因為802.3的部分帶寬耗費于沖突。802.3實際上并不是真的10Mb/s，而802.4(幾乎) 確實為10Mb/s。

與網橋瓶頸問題相關的一個細微而重要的問題是其上各層的計時器值。假如802.4局域網上的網絡層想發送一段很長的報文(幀序列)。在發出最后一幀之后，它開啟一個計時器，等待確認。如果此報文必須通過網橋轉到慢速的802.5網絡，那么在最后一幀被轉發到低速局域網之前，計時器就有可能時間到。網絡層可能會以為幀丟失而重新發送整個報文。幾次傳送失敗后，網絡層就會放棄傳輸并告訴傳輸層目的站點已經關機。

第三，在所有的問題中，可能最為嚴重的問題是三種802LAN有不同的最大幀長度。對于802.3，最大幀長度取決于配置參數，但對標準的10M/bs系統最大有效載荷為1500字節。802.4的最大幀長度固定為8191字節。802.5沒有上限，只要站點的傳輸時間不超過令牌持有時間。如果令牌時間缺省為10ms，則最大幀長度為5000字節。一個顯而易見的問題出現了：當必須把一個長幀轉發給不能接收長幀的局域網時，將會怎么樣？在本層中不考慮把幀分成小段。所有的協議都假定幀要么到達要么沒有到達，沒有條款規定把更小的單位重組成幀。這并不是說不能設計這樣的協議，可以設計并已有這種協議，只是 802不提供這種功能。這個問題基本上無法解決，必須丟棄因太長而無法轉發的幀。其透明程度也就這樣了。

由于各種802LAN的特殊性，如：802.4幀帶有優先權位、802.5幀字節中有A和C位等，九種網橋都有其特殊的問題，見下表：

　　目的LAN
　　802.3(CSMA/CD)802.4(令牌總線)802.5(令牌環)
源LAN802.3　1,41,2,4,8
802.41,5,8,9,1091,2,3,8,9,10
802.51,2,5,6,7,101,2,3,6,76,7

1、重新格式化幀，并計算新的校驗和。
2、反轉比特順序。
3、復制優先權值，不管有無意義。
4、產生一個假想的優先權。
5、丟棄優先權。
6、流向環（某種程度上）。
7、設置A位和C位。
8、擔心擁塞（快速LAN至慢速LAN）。
9、擔心令牌因為交換ACK延遲或不可能而脫手。
10、如果幀對目的LAN太長，則將其丟棄。

設定的參數：
802.3：1500字節幀10Mb/s(減去碰撞次數)
802.4：8191字節幀10Mb/s
802.5：5000字節幀4Mb/s

當 IEEE802委員會開始制訂LAN標準時，未能商定一個統一的標準，卻產生了3個互不兼容的標準，這一失策已受到了嚴厲的抨擊。后來，在制定互聯這3種 LAN的網橋的標準時，該委員會決心干得好一些。這一次確實較為成功，他們提出了2種互不兼容的網橋方案。直到目前為止，還無人要求該委員會制訂連接它的 2個不兼容網橋的網關標準。

四、兩種網橋

1、透明網橋


第一種802網橋是透明網橋 (transparentbridge)或生成樹網橋(spanningtreebridge)。支持這種設計的人首要關心的是完全透明。按照他們的觀點，裝有多個LAN的單位在買回IEEE標準網橋之后，只需把連接插頭插入網橋，就萬事大吉。不需要改動硬件和軟件，無需設置地址開關，無需裝入路由表或參數?？傊裁匆膊桓?，只須插入電纜就完事，現有LAN的運行完全不受網橋的任何影響。這真是不可思議，他們最終成功了。

透明網橋以混雜方式工作，它接收與之連接的所有LAN傳送的每一幀。當一幀到達時，網橋必須決定將其丟棄還是轉發。如果要轉發，則必須決定發往哪個LAN。這需要通過查詢網橋中一張大型散列表里的目的地址而作出決定。該表可列出每個可能的目的地，以及它屬于哪一條輸出線路(LAN)。在插入網橋之初，所有的散列表均為空。由于網橋不知道任何目的地的位置，因而采用擴散算法(floodingalgorithm)：把每個到來的、目的地不明的幀輸出到連在此網橋的所有 LAN中（除了發送該幀的LAN）。隨著時間的推移，網橋將了解每個目的地的位置。一旦知道了目的地位置，發往該處的幀就只放到適當的LAN上，而不再散發。

透明網橋采用的算法是逆向學習法(backwardlearning)。網橋按混雜的方式工作，故它能看見所連接的任一LAN上傳送的幀。查看源地址即可知道在哪個LAN上可訪問哪臺機器，于是在散列表中添上一項。

當計算機和網橋加電、斷電或遷移時，網絡的拓撲結構會隨之改變。為了處理動態拓撲問題，每當增加散列表項時，均在該項中注明幀的到達時間。每當目的地已在表中的幀到達時，將以當前時間更新該項。這樣，從表中每項的時間即可知道該機器最后幀到來的時間。網橋中有一個進程定期地掃描散列表，清除時間早于當前時間若干分鐘的全部表項。于是，如果從LAN上取下一臺計算機，并在別處重新連到LAN上的話，那么在幾分鐘內，它即可重新開始正常工作而無須人工干預。這個算法同時也意味著，如果機器在幾分鐘內無動作，那么發給它的幀將不得不散發，一直到它自己發送出一幀為止。

到達幀的路由選擇過程取決于發送的LAN(源LAN)和目的地所在的LAN(目的LAN)，如下所示：

1、如果源LAN和目的LAN相同，則丟棄該幀。
2、如果源LAN和目的LAN不同，則轉發該幀。
3、如果目的LAN未知，則進行擴散。

為了提高可靠性，有人在LAN之間設置了并行的兩個或多個網橋，但是，這種配置引起了另外一些問題，因為在拓撲結構中產生了回路，可能引發無限循環。其解決方法就是下面要講的生成樹(spanningtree)算法。

生成樹網橋

解決上面所說的無限循環問題的方法是讓網橋相互通信，并用一棵到達每個LAN的生成樹覆蓋實際的拓撲結構。使用生成樹，可以確保任兩個LAN之間只有唯一一條路徑。一旦網橋商定好生成樹，LAN間的所有傳送都遵從此生成樹。由于從每個源到每個目的地只有唯一的路徑，故不可能再有循環。

為了建造生成樹，首先必須選出一個網橋作為生成樹的根。實現的方法是每個網橋廣播其序列號（該序列號由廠家設置并保證全球唯一），選序列號最小的網橋作為根。接著，按根到每個網橋的最短路徑來構造生成樹。如果某個網橋或LAN故障，則重新計算。

網橋通過BPDU(BridgeProtocolDataUnit)互相通信，在網橋做出配置自己的決定前，每個網橋和每個端口需要下列配置數據：

網橋：ID(唯一的標識)
端口：端口ID(唯一的標識)
端口相對優先權
各端口的花費(高帶寬=低花費)


配置好各個網橋后，網橋將根據配置參數自動確定生成樹，這一過程有三個階段：

1、選擇根網橋
具有最小網橋ID的網橋被選作根網橋。網橋ID應為唯一的，但若兩個網橋具有相同的最小ID，則MAC地址小的網橋被選作根。

2、在其它所有網橋上選擇根端口
除根網橋外的各個網橋需要選一個根端口，這應該是最適合與根網橋通信的端口。通過計算各個端口到根網橋的花費，取最小者作為根端口。

3、選擇每個LAN的“指定(designated)網橋”和“指定端口”
如果只有一個網橋連到某LAN，它必然是該LAN的指定網橋，如果多于一個，則到根網橋花費最小的被選為該LAN的指定網橋。指定端口連接指定網橋和相應的LAN(如果這樣的端口多于一個，則低優先權的被選)。

一個端口必須為下列之一：

1、根端口
2、某LAN的指定端口
3、阻塞端口

當一個網橋加電后，它假定自己是根網橋，發送出一個CBPDU(ConfigurationBridgeProtocolDataUnit)，告知它認為的根網橋ID。一個網橋收到一個根網橋ID小于其所知ID的CBPDU，它將更新自己的表，如果該幀從根端口(上傳)到達，則向所有指定端口(下傳)分發。當一個網橋收到一個根網橋ID大于其所知ID的CBPDU，該信息被丟棄，如果該幀從指定端口到達，則回送一個幀告知真實根網橋的較低ID。

當有意地或由于線路故障引起網絡重新配置，上述過程將重復，產生一個新的生成樹。

2、源路由選擇網橋


透明網橋的優點是易于安裝，只需插進電纜即大功告成。但是從另一方面來說，這種網橋并沒有最佳地利用帶寬，因為它們僅僅用到了拓撲結構的一個子集(生成樹)。這兩個（或其他）因素的相對重要性導致了802委員會內部的分裂。支持CSMA/CD和令牌總線的人選擇了透明網橋，而令牌環的支持者則偏愛一種稱為源路由選擇(sourcerouting)的網橋（受到IBM的鼓勵）。

源路由選擇的核心思想是假定每個幀的發送者都知道接收者是否在同一LAN上。當發送一幀到另外的LAN時，源機器將目的地址的高位設置成1作為標記。另外，它還在幀頭加進此幀應走的實際路徑。

源路由選擇網橋只關心那些目的地址高位為1的幀，當見到這樣的幀時，它掃描幀頭中的路由，尋找發來此幀的那個LAN的編號。如果發來此幀的那個LAN編號后跟的是本網橋的編號，則將此幀轉發到路由表中自己后面的那個LAN。如果該LAN編號后跟的不是本網橋，則不轉發此幀。這一算法有3種可能的具體實現：軟件、硬件、混合。這三種具體實現的價格和性能各不相同。第一種沒有接口硬件開銷，但需要速度很快的CPU處理所有到來的幀。最后一種實現需要特殊的 VLSI芯片，該芯片分擔了網橋的許多工作，因此，網橋可以采用速度較慢的CPU，或者可以連接更多的LAN。

源路由選擇的前提是互聯網中的每臺機器都知道所有其他機器的最佳路徑。如何得到這些路由是源路由選擇算法的重要部分。獲取路由算法的基本思想是：如果不知道目的地地址的位置，源機器就發布一廣播幀，詢問它在哪里。每個網橋都轉發該查找幀(discoveryframe)，這樣該幀就可到達互聯網中的每一個LAN。當答復回來時，途經的網橋將它們自己的標識記錄在答復幀中，于是，廣播幀的發送者就可以得到確切的路由，并可從中選取最佳路由。

雖然此算法可以找到最佳路由（它找到了所有的路由），但同時也面臨著幀爆炸的問題。透明網橋也會發生有點類似的狀況，但是沒有這么嚴重。其擴散是按生成樹進行，所以傳送的總幀數是網絡大小的線性函數，而不象源路由選擇是指數函數。一旦主機找到至某目的地的一條路由，它就將其存入到高速緩沖器之中，無需再作查找。雖然這種方法大大遏制了幀爆炸，但它給所有的主機增加了事務性負擔，而且整個算法肯定是不透明的。

3、兩種網橋的比較

透明網橋一般用于連接以太網段，而源路由選擇網橋則一般用于連接令牌環網段。

五、遠程網橋


網橋有時也被用來連接兩個或多個相距較遠的LAN。比如，某個公司分布在多個城市中，該公司在每個城市中均有一個本地的LAN，最理想的情況就是所有的LAN均連接起來，整個系統就像一個大型的LAN一樣。

該目標可通過下述方法實現：每個LAN中均設置一個網橋，并且用點到點的連接（比如租用電話公司的電話線）將它們兩個兩個地連接起來。點到點連線可采用各種不同的協議。辦法之一就是選用某種標準的點到點數據鏈路協議，將完整的MAC幀加到有效載荷中。如果所有的LAN均相同，這種辦法的效果最好，它的唯一問題就是必須將幀送到正確的LAN中。另一種辦法是在源網橋中去掉MAC的頭部和尾部，并把剩下的部分加到點到點協議的有效載荷中，然后在目的網橋中產生新的頭部和尾部。它的缺點是到達目的主機的校驗和并非是源主機所計算的校驗和，因此網橋存儲器中某位損壞所產生的錯誤可能不會被檢測到。 資料來源：http://www.cnpaf.net/Class/Ethernet/200512/10646.html，中國協議分析網

用過NetXray之類的抓包軟件的人，可能經常會被一些  不同的Frame Header搞糊涂，為何用的Frame的Header
 是這樣的，而另外的又不一樣。這是因為在Ethernet  中存在幾種不同的幀格式，下面我就簡單介紹一下幾種
 不同的幀格式及他們的差異。

 一。Ethernet幀格式的發展

 1980 DEC,Intel,Xerox制訂了Ethernet I的標準
 1982 DEC,Intel,Xerox又制訂了Ehternet II的標準
 1982 IEEE開始研究Ethernet的國際標準802.3
 1983 迫不及待的Novell基于IEEE的802.3的原始版開發了專用的Ethernet幀格式
 1985 IEEE推出IEEE 802.3規范
      后來為解決EthernetII與802.3幀格式的兼容問題推出折衷的Ethernet SNAP格式

 (其中早期的Ethernet I已經完全被其他幀格式取代了所以現在Ethernet只能見到后面幾種Ethernet的幀格式現在大部分的網絡設備都支持這幾種Ethernet的幀格式如:cisco的路由器再設定Ethernet接口時可以指定不同的以太網的幀格式:arpa,sap,snap,novell-ether)

 二.各種不同的幀格式
 下面介紹一下各個幀格式  

•  Ethernet II
     就是DIX以太網聯盟推出的，它由6個字節的目的MAC地址，6個字節的源MAC地址，2個字節的類型域（用于標示封裝在這個Frame、里面數據的類型)以上為Frame Header,接下來是46--1500 字節的數據，和4字節的幀校驗）
• Novell Ethernet
     它的幀頭與Ethernet有所不同其中EthernetII幀頭中的類型域變成了長度域，后面接著的兩個字節為0xFFFF
     用于標示這個幀是Novell Ether類型的Frame 由于前面的0xFFFF站掉了兩個字節所以數據域縮小為44-1498個字節,幀校驗不變。
• IEEE 802.3/802.2
     802.3的Frame Header和Ethernet II的幀頭有所不同EthernetII類型域變成了長度域。其中又引入802.2協議(LLC)在802.3幀頭后面添加了一個LLC首部,由 DSAP(Destination Service Access Point)
     1 byte,SSAP(Source SAP),一個控制域--1 byte!
     SAP用于標示幀的上層協議
• Ethernet SNAP
     SNAP Frame與802.3/802.2 Frame的最大區別是增加了一個5 Bytes的SNAP ID其中前面3個byte通常與源mac地址的前三個bytes相同為廠商代碼！有時也可設為0,后2 bytes 與Ethernet II的類型域相同。。。

 
 三.如何區分不同的幀格式
  
   Ethernet中存在這四種Frame那些網絡設備又是如何識別的呢? 如何區分EthernetII與其他三種格式的Frame 如果幀頭跟隨source mac地址的2 bytes的值大于1500 則此Frame為EthernetII格式的。
   
   接著比較緊接著的兩bytes如果為0xFFFF則為Novell Ether 類型的Frame
   如果為0xAAAA則為Ethernet SNAP格式的Frame ，如果都不是則為Ethernet 802.3/802.2格式的幀

資料來源：http://baike.baidu.com/view/750250.htm。
1.UAC(User Account Control : 用戶帳戶控制)是微軟為提高系統安全而在Windows Vista中引入的新技術，它要求用戶在執行可能會影響計算機運行的操作或執行更改影響其他用戶的設置的操作之前，提供權限或管理員‌密碼。
　　通過在這些操作啟動前對其進行驗證，UAC 可以幫助防止惡意軟件和間諜軟件在未經許可的情況下在計算機上進行安裝或對計算機進行更改。
　　當需要權限或密碼才能完成任務時，UAC 會用下列消息之一警告用戶：
Windows 需要您的許可才能繼續
　　可能會影響本計算機其他用戶的 Windows 功能或程序需要您的許可才能啟動。請檢查操作的名稱以確保它正是您要運行的功能或程序。
　　程序需要您的許可才能繼續
　　不屬于 Windows 的一部分的程序需要您的許可才能啟動。它具有指明其名稱和發行者的有效的數字簽名，該數字簽名可以幫助確保該程序正是其所聲明的程序。確保該程序正是您要運行的程序。
　　一個未能識別的程序要訪問您的計算機
　　未能識別的程序是指沒有其發行者所提供用于確保該程序正是其所聲明程序的有效數字簽名的程序。這不一定表明有危險，因為許多舊的合法程序缺少簽名。但是，應該特別注意并且僅當其獲取自可信任的來源（例如原裝 CD 或發行者網站）時允許此程序運行。
　　此程序已被阻止
　　這是管理員專門阻止在您的計算機上運行的程序。若要運行此程序，必須與管理員聯系并且要求解除阻止此程序。
　　建議您大多數情況下使用標準用戶帳戶登錄計算機。可以瀏覽 Internet，發送電子郵件，使用字處理器，所有這些都不需要管理員帳戶。當您要執行管理任務（如安裝新程序或更改會影響其他用戶的設置）時，不必切換到管理員帳戶。在執行該任務之前，Windows 會提示您進行許可或提供管理員密碼。
　　為了幫助保護計算機，可以為共享該計算機的所有用戶創建標準用戶帳戶。當擁有標準帳戶的人試圖安裝軟件時，Windows 會要求輸入管理員帳戶的密碼，以便在您不知情和未經您許可的情況下無法安裝軟件。
　　2.UAC(User Agent Client) 用戶代理客戶端

資料來源：http://blog.chinaunix.net/u1/38576/showart_367985.html。
內核同步措施

    為了避免并發，防止競爭。內核提供了一組同步方法來提供對共享數據的保護。 我們的重點不是介紹這些方法的詳細用法，而是強調為什么使用這些方法和它們之間的差別。
    Linux 使用的同步機制可以說從2.0到2.6以來不斷發展完善。從最初的原子操作，到后來的信號量，從大內核鎖到今天的自旋鎖。這些同步機制的發展伴隨 Linux從單處理器到對稱多處理器的過度；伴隨著從非搶占內核到搶占內核的過度。鎖機制越來越有效，也越來越復雜。
    目前來說內核中原子操作多用來做計數使用，其它情況最常用的是兩種鎖以及它們的變種:一個是自旋鎖，另一個是信號量。我們下面就來著重介紹一下這兩種鎖機制。


自旋鎖
------------------------------------------------------
    自旋鎖是專為防止多處理器并發而引入的一種鎖，它在內核中大量應用于中斷處理等部分(對于單處理器來說，防止中斷處理中的并發可簡單采用關閉中斷的方式，不需要自旋鎖)。
    自旋鎖最多只能被一個內核任務持有，如果一個內核任務試圖請求一個已被爭用(已經被持有)的自旋鎖，那么這個任務就會一直進行忙循環——旋轉——等待鎖重新可用。要是鎖未被爭用，請求它的內核任務便能立刻得到它并且繼續進行。自旋鎖可以在任何時刻防止多于一個的內核任務同時進入臨界區，因此這種鎖可有效地避免多處理器上并發運行的內核任務競爭共享資源。
    事實上，自旋鎖的初衷就是：在短期間內進行輕量級的鎖定。一個被爭用的自旋鎖使得請求它的線程在等待鎖重新可用的期間進行自旋(特別浪費處理器時間)，所以自旋鎖不應該被持有時間過長。如果需要長時間鎖定的話, 最好使用信號量。
自旋鎖的基本形式如下：
    spin_lock(&mr_lock);
    //臨界區
    spin_unlock(&mr_lock);

    因為自旋鎖在同一時刻只能被最多一個內核任務持有，所以一個時刻只有一個線程允許存在于臨界區中。這點很好地滿足了對稱多處理機器需要的鎖定服務。在單處理器上，自旋鎖僅僅當作一個設置內核搶占的開關。如果內核搶占也不存在，那么自旋鎖會在編譯時被完全剔除出內核。
    簡單的說，自旋鎖在內核中主要用來防止多處理器中并發訪問臨界區，防止內核搶占造成的競爭。另外自旋鎖不允許任務睡眠(持有自旋鎖的任務睡眠會造成自死鎖——因為睡眠有可能造成持有鎖的內核任務被重新調度，而再次申請自己已持有的鎖)，它能夠在中斷上下文中使用。
    死鎖：假設有一個或多個內核任務和一個或多個資源，每個內核都在等待其中的一個資源，但所有的資源都已經被占用了。這便會發生所有內核任務都在相互等待，但它們永遠不會釋放已經占有的資源，于是任何內核任務都無法獲得所需要的資源，無法繼續運行，這便意味著死鎖發生了。自死瑣是說自己占有了某個資源，然后自己又申請自己已占有的資源，顯然不可能再獲得該資源，因此就自縛手腳了。


信號量
------------------------------------------------------
    Linux中的信號量是一種睡眠鎖。如果有一個任務試圖獲得一個已被持有的信號量時，信號量會將其推入等待隊列，然后讓其睡眠。這時處理器獲得自由去執行其它代碼。當持有信號量的進程將信號量釋放后，在等待隊列中的一個任務將被喚醒，從而便可以獲得這個信號量。
    信號量的睡眠特性，使得信號量適用于鎖會被長時間持有的情況；只能在進程上下文中使用，因為中斷上下文中是不能被調度的；另外當代碼持有信號量時，不可以再持有自旋鎖。

信號量基本使用形式為：
static DECLARE_MUTEX(mr_sem);//聲明互斥信號量
if(down_interruptible(&mr_sem))
    //可被中斷的睡眠，當信號來到，睡眠的任務被喚醒
    //臨界區
up(&mr_sem);


信號量和自旋鎖區別
------------------------------------------------------
    雖然聽起來兩者之間的使用條件復雜，其實在實際使用中信號量和自旋鎖并不易混淆。注意以下原則:
    如果代碼需要睡眠——這往往是發生在和用戶空間同步時——使用信號量是唯一的選擇。由于不受睡眠的限制，使用信號量通常來說更加簡單一些。如果需要在自旋鎖和信號量中作選擇，應該取決于鎖被持有的時間長短。理想情況是所有的鎖都應該盡可能短的被持有，但是如果鎖的持有時間較長的話，使用信號量是更好的選擇。另外，信號量不同于自旋鎖，它不會關閉內核搶占，所以持有信號量的代碼可以被搶占。這意味者信號量不會對影響調度反應時間帶來負面影響。


自旋鎖對信號量
------------------------------------------------------
需求                     建議的加鎖方法

低開銷加鎖               優先使用自旋鎖
短期鎖定                 優先使用自旋鎖
長期加鎖                 優先使用信號量
中斷上下文中加鎖          使用自旋鎖
持有鎖是需要睡眠、調度     使用信號量

資料來源：http://cisco.chinaitlab.com/Cisco/38689.html。
　　網絡互連設備可以將網絡劃分為不同的沖突域、廣播域。但是，由于不同的網絡互連設備可能工作在OSI模型的不同層次上。因此，它們劃分沖突域、廣播域的效果也就各不相同。如中繼器工作在物理層，網橋和交換機工作在數據鏈路層，路由器工作在網絡層，而網關工作在OSI模型的上三層。而每一層的網絡互連設備要根據不同層次的特點完成各自不同的任務。
　　
　　下面我們討論常見的網絡互連設備的工作原理以及它們在劃分沖突域、廣播域時各自的特點。
　　
　　1、傳統以太網操作
　　
　　傳統共享式以太網的典型代表是總線型以太網。在這種類型的以太網中，通信信道只有一個，采用介質共享（介質爭用）的訪問方法（第1章中介紹的 CSMA/CD介質訪問方法）。每個站點在發送數據之前首先要偵聽網絡是否空閑，如果空閑就發送數據。否則，繼續偵聽直到網絡空閑。如果兩個站點同時檢測到介質空閑并同時發送出一幀數據，則會導致數據幀的沖突，雙方的數據幀均被破壞。這時，兩個站點將采用"二進制指數退避"的方法各自等待一段隨機的時間再偵聽、發送。
　　
　　在圖1中，主機A只是想要發送一個單播數據包給主機B。但由于傳統共享式以太網的廣播性質，接入到總線上的所有主機都將收到此單播數據包。同時，此時如果任何第二方，包括主機B也要發送數據到總線上都將沖突，導致雙方數據發送失敗。我們稱連接在總線上的所有主機共同構成了一個沖突域。
　　
　　當主機A發送一個目標是所有主機的廣播類型數據包時，總線上的所有主機都要接收該廣播數據包，并檢查廣播數據包的內容，如果需要的話加以進一步的處理。我們稱連接在總線上的所有主機共同構成了一個廣播域。
　　
　　 　
　　圖1　 傳統以太網
　　
　　2、中繼器（Repeater）
　　
　　中繼器（Repeater）作為一個實際產品出現主要有兩個原因：
　　
　　第一，擴展網絡距離，將衰減信號經過再生。
　　
　　第二，實現粗同軸電纜以太網和細同軸電纜以太網的互連。
　　
　　通過中繼器雖然可以延長信號傳輸的距離、實現兩個網段的互連。但并沒有增加網絡的可用帶寬。如圖2所示，網段1和網段2經過中繼器連接后構成了一個單個的沖突域和廣播域。
　　
　　 　
　　圖2　 中繼器連接的網絡
　　
　　3、集線器（HUB）
　　
　　集線器實際上相當于多端口（在本章，我們常用"端口"一詞代替"接口"這個術語）的中繼器。集線器通常有8個、16個或24個等數量不等的接口。
　　
　　集線器同樣可以延長網絡的通信距離，或連接物理結構不同的網絡，但主要還是作為一個主機站點的匯聚點，將連接在集線器上各個接口上的主機聯系起來使之可以互相通信。
　　
　　如圖3所示，所有主機都連接到中心節點的集線器上構成一個物理上的星型連接。但實際上，在集線器內部，各接口都是通過背板總線連接在一起的，在邏輯上仍構成一個共享的總線。因此，集線器和其所有接口所接的主機共同構成了一個沖突域和一個廣播域。
　　
　　 　
　　圖3　 集線器連接的網絡
　　
　　4、網橋（Bridge）
　　
　　網橋（Bridge）又稱為橋接器。和中繼器類似，傳統的網橋只有兩個端口，用于連接不同的網段。和中繼器不同的是，網橋具有一定的"智能"性，可以"學習"網絡上主機的地址，同時具有信號過濾的功能。
　　
　　如圖4所示，網段1的主機A發給主機B的數據包不會被網橋轉發到網段2。因為，網橋可以識別這是網段1內部的通信數據流。同樣，網段2的主機X發給主機 Y的數據包也不會被網橋轉發到網段1。可見，網橋可以將一個沖突域分割為兩個。其中，每個沖突域共享自己的總線信道帶寬。
　　
　　 　
　　圖4　 網橋連接的網絡
　　
　　但是，如果主機C發送了一個目標是所有主機的廣播類型數據包時，網橋要轉發這樣的數據包。網橋兩側的兩個網段總線上的所有主機都要接收該廣播數據包。因此，網段1和網段2仍屬于同一個廣播域。
　　
　　5、交換機（Switch）
　　
　　交換機（Switch）也被稱為交換式集線器。它的出現是為了解決連接在集線器上的所有主機共享可用帶寬的缺陷。
　　
　　交換機是通過為需要通信的兩臺主機直接建立專用的通信信道來增加可用帶寬的。從這個角度上來講，交換機相當于多端口網橋。
　　
　　如圖5所示，交換機為主機A和主機B建立一條專用的信道，也為主機C和主機D建立一條專用的信道。只有當某個接口直接連接了一個集線器，而集線器又連接了多臺主機時，交換機上的該接口和集線器上所連的所有主機才可能產生沖突，形成沖突域。換句話說，交換機上的每個接口都是自己的一個沖突域。
　　
　　 　
　　圖5　 交換機連接的網絡
　　
　　但是，交換機同樣沒有過濾廣播通信的功能。如果交換機收到一個廣播數據包后，它會向其所有的端口轉發此廣播數據包。因此，交換機和其所有接口所連接的主機共同構成了一個廣播域。
　　
　　我們將使用交換機作為互連設備的局域網稱為交換式局域網。
　　
　　6、路由器（Router）
　　
　　路由器工作在網絡層，可以識別網絡層的地址-IP地址，有能力過濾第3層的廣播消息。實際上，除非做特殊配置，否則路由器從不轉發廣播類型的數據包。因此，路由器的每個端口所連接的網絡都獨自構成一個廣播域。如圖6所示，如果各網段都是共享式局域網，則每網段自己構成一個獨立的沖突域。
　　
　　 　
　　圖6　 路由器連接的網絡
　　
　　7、網關（Gateway）
　　
　　網關工作在OSI參考模型的高三層，因此，并不使用沖突域、廣播域的概念。網關主要用來進行高層協議之間的轉換。例如，充當LOTUS 1-2-3郵件服務和Microsoft Exchange郵件服務之間的郵件網關。
　　
　　注意，這里網關的概念完全不同于PC主機以及路由器上配置的默認網關（default gateway）。 前兩天看到一個故事——
有一天，一位其貌不揚的男士，帶著一位十分艷麗的OL，來到Causeway Bay一家LV店。他為OL選了一價值6萬5元的LV handbag。
　　付款時，男士掏出支票本，十分瀟灑地簽了一張支票。店員有些為難，因為這對夫婦是第一次來店購物。
　　男士看穿了店員的心思，十分冷靜地對店員說： "我感覺到，您擔心這是一張是空頭支票，對嗎？今天是周六，銀行關門。我建議您把支票和handbag都留下。等到星期一支票兌現之后，再請你們把 handbag 送到這位小姐的府上。您看這樣行不行？"
　　店員放了下心來，欣然地接受了這個建議，并且大方的承諾，遞送handbag的費用由該店承擔，他本人將會親自把這件事情給辦妥。
　　星期一，店員拿著支票去銀行入賬，支票果真是張空頭支票！憤怒的店員打電話給那位顧客，客戶對他說： "這沒有什么要緊?。∧愫臀叶紱]有損失。上星期六的晚上我已經同那個女孩上床了！哦，多謝您的合作。"


這 個故事揭示了次貸危機的本質。人們在對未來收益充滿良好預期的時候，對于可能加大風險缺乏防范意識。美女認為周一六萬多LV就到家了，自然也就放松了警 惕，認為ONS的投資是值得的，對于投入產出的預期是建立在一個具有巨大不確定風險的情況下的。而對未來收益預期的包裝則是這些投資機構最擅長的事情。中 國的股民大多跟這個美女一樣，所以虧錢基本上是活該，沒有這些人，股市賺誰的錢呢。而媒體和分析家們，往往在其中扮演了LV店員的配合角色。         QoS的英文全稱為"Quality of Service"，中文名為"服務質量"。QoS是網絡的一種安全機制, 是用來解決網絡延遲和阻塞等問題的一種技術。
　　在正常情況下，如果網絡只用于特定的無時間限制的應用系統，并不需要QoS，比如Web應用，或E-mail設置等。但是對關鍵應用和多媒體應用就十分必要。當網絡過載或擁塞時，QoS 能確保重要業務量不受延遲或丟棄，同時保證網絡的高效運行。
資料來源：http://baike.baidu.com/view/20897.htm

朋友帖了如下一段代碼：
　　#pragma pack(4)
　　class TestB
　　{
　　public:
　　　　int aa;
　　　　char a;
　　　　short b;
　　　　char c;
　　};
　　int nSize = sizeof(TestB);
　　這里nSize結果為12，在預料之中。

　　現在去掉第一個成員變量為如下代碼：
　　#pragma pack(4)
　　class TestC
　　{
　　public:
　　　　char a;
　　　　short b;
　　　　char c;
　　};
　　int nSize = sizeof(TestC);
　　按照正常的填充方式nSize的結果應該是8，為什么結果顯示nSize為6呢？

事實上，很多人對#pragma pack的理解是錯誤的。
#pragma pack規定的對齊長度，實際使用的規則是：
結構，聯合，或者類的數據成員，第一個放在偏移為0的地方，以后每個數據成員的對齊，按照#pragma pack指定的數值和這個數據成員自身長度中，比較小的那個進行。
也就是說，當#pragma pack的值等于或超過所有數據成員長度的時候，這個值的大小將不產生任何效果。
而結構整體的對齊，則按照結構體中最大的數據成員 和 #pragma pack指定值 之間，較小的那個進行。

具體解釋
#pragma pack(4)
　　class TestB
　　{
　　public:
　　　　int aa; //第一個成員，放在[0,3]偏移的位置，
　　　　char a; //第二個成員，自身長為1，#pragma pack(4),取小值，也就是1，所以這個成員按一字節對齊，放在偏移[4]的位置。
　　　　short b; //第三個成員，自身長2，#pragma pack(4)，取2，按2字節對齊，所以放在偏移[6,7]的位置。
　　　　char c; //第四個，自身長為1，放在[8]的位置。
　　};
這個類實際占據的內存空間是9字節
類之間的對齊，是按照類內部最大的成員的長度，和#pragma pack規定的值之中較小的一個對齊的。
所以這個例子中，類之間對齊的長度是min(sizeof(int),4)，也就是4。
9按照4字節圓整的結果是12，所以sizeof(TestB)是12。

如果
#pragma pack(2)
    class TestB
　　{
　　public:
　　　　int aa; //第一個成員，放在[0,3]偏移的位置，
　　　　char a; //第二個成員，自身長為1，#pragma pack(4),取小值，也就是1，所以這個成員按一字節對齊，放在偏移[4]的位置。
　　　　short b; //第三個成員，自身長2，#pragma pack(4)，取2，按2字節對齊，所以放在偏移[6,7]的位置。
　　　　char c; //第四個，自身長為1，放在[8]的位置。
　　};
//可以看出，上面的位置完全沒有變化，只是類之間改為按2字節對齊，9按2圓整的結果是10。
//所以 sizeof(TestB)是10。

最后看原貼：
現在去掉第一個成員變量為如下代碼：
　　#pragma pack(4)
　　class TestC
　　{
　　public:
　　　　char a;//第一個成員，放在[0]偏移的位置，
　　　　short b;//第二個成員，自身長2，#pragma pack(4)，取2，按2字節對齊，所以放在偏移[2,3]的位置。
　　　　char c;//第三個，自身長為1，放在[4]的位置。
　　};
//整個類的大小是5字節，按照min(sizeof(short),4)字節對齊，也就是2字節對齊，結果是6
//所以sizeof(TestC)是6。

感謝Michael 提出疑問，在此補充：

當數據定義中出現__declspec( align() )時，指定類型的對齊長度還要用自身長度和這里指定的數值比較，然后取其中較大的。最終類/結構的對齊長度也需要和這個數值比較，然后取其中較大的。

可以這樣理解， __declspec( align() ) 和 #pragma pack是一對兄弟，前者規定了對齊的最小值，后者規定了對齊的最大值，兩者同時出現時，前者擁有更高的優先級。
__declspec( align() ) 的一個特點是，它僅僅規定了數據對齊的位置，而沒有規定數據實際占用的內存長度，當指定的數據被放置在確定的位置之后，其后的數據填充仍然是按照#pragma pack規定的方式填充的，這時候類/結構的實際大小和內存格局的規則是這樣的：
在 __declspec( align() )之前，數據按照#pragma pack規定的方式填充，如前所述。當遇到__declspec( align() )的時候，首先尋找距離當前偏移向后最近的對齊點（滿足對齊長度為 max(數據自身長度,指定值) )，然后把被指定的數據類型從這個點開始填充，其后的數據類型從它的后面開始，仍然按照#pragma pack填充，直到遇到下一個__declspec( align() )。
當所有數據填充完畢，把結構的整體對齊數值和__declspec( align() )規定的值做比較，取其中較大的作為整個結構的對齊長度。
特別的，當__declspec( align() )指定的數值比對應類型長度小的時候，這個指定不起作用。