多播緩存

⑴ tcp協議通過什麼來區分不同的連接

TCP/IP
不同的計算機系統，就好像語言不同的兩個人互相見了面，完全不能交流信息。因而他們需要定義一些共通的東西來進行交流，TCP/IP就是為此而生。TCP/IP不是一個協議，而是一個協議族的統稱。裡麵包括了IP協議，IMCP協議，TCP協議，以及我們更加熟悉的http、ftp、pop3協議等等。電腦有了這些，就好像學會了外語一樣，就可以和其他的計算機終端做自由的交流了。
TCP/IP 層次
應用層(http、ftp、smtp) -->傳輸層(TCP、UDP)-->網路層(IP)-->數據鏈路層
域名系統 :域名系統是一個分布的資料庫，它提供將主機名（就是網址啦）轉換成IP地址的服務。
埠號(port): 注意，這個號碼是用在TCP，UDP上的一個邏輯號碼，並不是一個硬體埠，我們平時說把某某埠封掉了，也只是在IP層次把帶有這個號碼的IP包給過濾掉了而已。
應用編程介面:現在常用的編程介面有socket和TLI。
數據鏈路層
數據鏈路層有三個目的：
為IP模塊發送和 接收IP數據報。
為ARP模塊發送ARP請求和接收ARP應答。
為RARP發送RARP請 求和接收RARP應答
ip大家都聽說過。至於ARP和RARP，ARP叫做地址解析協議，是用IP地址換MAC地址的一種協議，而RARP則叫做逆地址解析協議.
--
IP 、ARP 、RARP 協議
三者都是在網路層 ，ARP協議用來找到目標主機的Ethernet網卡Mac地址，IP則承載要發送的消息。數據鏈路層可以從ARP得到數據的傳送信息，而從IP得到要傳輸的數據信息。
IP 協議
IP協議是TCP/IP協議的核心，所有的TCP，UDP，IMCP，IGCP的數據都以IP數據格式傳輸。要注意的是，IP不是可靠的協議，這是說，IP協議沒有提供一種數據未傳達以後的處理機制－－這被認為是上層協議：TCP或UDP要做的事情。所以這也就出現了TCP是一個可靠的協議，而UDP就沒有那麼可靠的區別。

協議頭
八位的TTL欄位，還記得這個欄位是做什麼的么？這個欄位規定該數據包在穿過多少個路由之後才會被拋棄(這里就體現出來IP協議包的不可靠性，它不保證數據被送達)，某個ip數據包每穿過一個路由器，該數據包的TTL數值就會減少1，當該數據包的TTL成為零，它就會被自動拋棄。這個欄位的最大值也就是255，也就是說一個協議包也就在路由器裡面穿行255次就會被拋棄了，根據系統的不同，這個數字也不一樣，一般是32或者是64，Tracerouter這個工具就是用這個原理工作的，tranceroute的-m選項要求最大值是255，也就是因為這個TTL在IP協議裡面只有8bit。
現在的ip版本號是4，所以也稱作IPv4。現在還有IPv6，而且運用也越來越廣泛了。
IP路由選擇
當一個IP數據包準備好了的時候，IP數據包（或者說是路由器）是如何將數據包送到目的地的呢？它是怎麼選擇一個合適的路徑來"送貨"的呢？
最特殊的情況是目的主機和主機直連，那麼主機根本不用尋找路由，直接把數據傳遞過去就可以了。至於是怎麼直接傳遞的，這就要靠ARP協議了。
稍微一般一點的情況是，主機通過若干個路由器(router)和目的主機連接。那麼路由器就要通過ip包的信息來為ip包尋找到一個合適的目標來進行傳遞，比如合適的主機，或者合適的路由。路由器或者主機將會用如下的方式來處理某一個IP數據包
如果IP數據包的TTL（生命周期）以到，則該IP數據包就被拋棄。
搜索路由表，優先搜索匹配主機，如果能找到和IP地址完全一致的目標主機，則將該包發向目標主機
搜索路由表，如果匹配主機失敗，則匹配同子網的路由器，這需要「子網掩碼(1.3.)」的協助。如果找到路由器，則將該包發向路由器。
搜索路由表，如果匹配同子網路由器失敗，則匹配同網號路由器，如果找到路由器，則將該包發向路由器。
搜索路由表，如果以上都失敗了，就搜索默認路由，如果默認路由存在，則發包
如果都失敗了，就丟掉這個包
這再一次證明了，ip包是不可靠的。因為它不保證送達。
ARP協議
還記得數據鏈路層的乙太網的協議中，每一個數據包都有一個MAC地址頭么？我們知道每一塊乙太網卡都有一個MAC地址，這個地址是唯一的，那麼IP包是如何知道這個MAC地址的？這就是ARP協議的工作。
ARP（地址解析）協議是一種解析協議，本來主機是完全不知道這個IP對應的是哪個主機的哪個介面，當主機要發送一個IP包的時候，會首先查一下自己的ARP高速緩存（就是一個IP-MAC地址對應表緩存），如果查詢的IP－MAC值對不存在，那麼主機就向網路發送一個ARP協議廣播包，這個廣播包裡面就有待查詢的IP地址，而直接收到這份廣播的包的所有主機都會查詢自己的IP地址，如果收到廣播包的某一個主機發現自己符合條件，那麼就准備好一個包含自己的MAC地址的ARP包傳送給發送ARP廣播的主機，而廣播主機拿到ARP包後會更新自己的ARP緩存（就是存放IP-MAC對應表的地方）。發送廣播的主機就會用新的ARP緩存數據准備好數據鏈路層的的數據包發送工作。
arp -a 可以查詢自己的arp緩存
這樣的高速緩存是有時限的，一般是20分鍾（伯克利系統的衍生系統）。
--
ICMP協議
--
UDP 協議
UDP是傳輸層協議，和TCP協議處於一個分層中，但是與TCP協議不同，UDP協議並不提供超時重傳，出錯重傳等功能，也就是說其是不可靠的協議。
1 、UDP 的埠號
由於很多軟體需要用到UDP協議，所以UDP協議必須通過某個標志用以區分不同的程序所需要的數據包。埠號的功能就在於此，例如某一個UDP程序A在系統中注冊了3000埠，那麼，以後從外面傳進來的目的埠號為3000的UDP包都會交給該程序。埠號理論上可以有2^16這么多。因為它的長度是16個bit
2 、UDP 的檢驗和
這是一個可選的選項，並不是所有的系統都對UDP數據包加以檢驗和數據(相對TCP協議的必須來說)，但是RFC中標准要求，發送端應該計算檢驗和。
UDP檢驗和覆蓋UDP協議頭和數據，這和IP的檢驗和是不同的，IP協議的檢驗和只是覆蓋IP數據頭，並不覆蓋所有的數據。UDP和TCP都包含一個偽首部，這是為了計算檢驗和而攝制的。偽首部甚至還包含IP地址這樣的IP協議裡面都有的信息，目的是讓UDP兩次檢查數據是否已經正確到達目的地。如果發送端沒有打開檢驗和選項，而接收端計算檢驗和有差錯，那麼UDP數據將會被悄悄的丟掉（不保證送達），而不產生任何差錯報文。
3 、UDP 的長度
UDP可以很長很長，可以有65535位元組那麼長。但是一般網路在傳送的時候，一次一般傳送不了那麼長的協議（涉及到MTU的問題），就只好對數據分片，當然，這些是對UDP等上級協議透明的，UDP不需要關心IP協議層對數據如何分片。
4 、IP 分片
IP在從上層接到數據以後，要根據IP地址來判斷從那個介面發送數據（通過選路），並進行MTU的查詢，如果數據大小超過MTU就進行數據分片。數據的分片是對上層和下層透明，而數據也只是到達目的地還會被重新組裝，不過不用擔心，IP層提供了足夠的信息進行數據的再組裝。
在IP頭裡面，16bit識別號唯一記錄了一個IP包的ID,具有同一個ID的IP片將會被重新組裝；而13位片偏移則記錄了某IP片相對整個包的位置；而這兩個表示中間的3bit標志則標示著該分片後面是否還有新的分片。這三個標示就組成了IP分片的所有信息，接受方就可以利用這些信息對IP數據進行重新組織（就算是後面的分片比前面的分片先到，這些信息也是足夠了）。
因為分片技術在網路上被經常的使用，所以偽造IP分片包進行流氓攻擊的軟體和人也就層出不窮。
5 、ICMP源站抑制差錯
當目標主機的處理速度趕不上數據接收的速度，因為接受主機的IP層緩存會被占滿，所以主機就會發出一個「我受不了」的一個ICMP報文。
--
單播廣播和多播
單播
單播是說，對特定的主機進行數據傳送。例如給某一個主機發送IP數據包。這時候，數據鏈路層給出的數據頭裡面是非常具體的目的地址，對於乙太網來 說，就是網卡的MAC地址（不是FF-FF-FF-FF-FF-FF這樣的地址）。現在的具有路由功能的主機應該可以將單播數據定向轉發，而目的主機的網 絡介面則可以過濾掉和自己MAC地址不一致的數據。
廣播
廣播是主機針對某一個網路上的所有主機發送數據包。這個網路可能是網路，可能是子網，還可能是所有的子網。如果是網路，例如A類網址的廣播就是 netid.255.255.255，如果是子網，則是netid.netid.subnetid.255；如果是所有的子網（B類IP）則是則是 netid.netid.255.255。廣播所用的MAC地址FF-FF-FF-FF-FF-FF。網路內所有的主機都會收到這個廣播數據，網卡只要把 MAC地址為FF-FF-FF-FF-FF-FF的數據交給內核就可以了。一般說來ARP，或者路由協議RIP應該是以廣播的形式播發的。
多播
可以說廣播是多播的特例，多播就是給一組特定的主機（多播組）發送數據，這樣，數據的播發范圍會小一些(實際上播發的范圍一點也沒有變小)，多播的MAC地址是最高位元組的低位為一，例 如01-00-00-00-00-00。多播組的地址是D類IP，規定是224.0.0.0-239.255.255.255。
雖然多播比較特殊，但是究其原理，多播的數據還是要通過數據鏈路層進行MAC地址綁定然後進行發送。所以一個乙太網卡在綁定了一個多播IP地址之後，必 定還要綁定一個多播的MAC地址，才能使得其可以像單播那樣工作。這個多播的IP和多播MAC地址有一個對應的演算法，在書的p133到p134之間。可以看到 這個對應不是一一對應的，主機還是要對多播數據進行過濾。
--
TCP
TCP和UDP處在同一層---運輸層，但是TCP和UDP最不同的地方是，TCP提供了一種可靠的數據傳輸服務，TCP是面向連接的，也就是說，利用TCP通信的兩台主機首先要經歷一個「撥打電話」的過程，等到通信准備結束才開始傳輸數據，最後結束通話。所以TCP要比UDP可靠的多，UDP是把數據直接發出去，而不管對方是不是在收信，就算是UDP無法送達，也不會產生ICMP差錯報文，這一經時重申了很多遍了。
把TCP保證可靠性的簡單工作原理:
應用數據被分割成TCP認為最適合發送的數據塊。這和UDP完全不同，應用程序產生的 數據報長度將保持不變。由TCP傳遞給IP的信息單位稱為報文段或段
當TCP發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能 及時收到一個確認，將重發這個報文段.
當TCP收到發自TCP連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常將推遲幾分之一秒.
TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸 過程中的任何變化。如果收到段的檢驗和有差錯， T P將丟棄這個報文段和不確認收到此報文段（希望發端超時並重發）。
既然TCP報文段作為IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段 的到達也可能會失序。如果必要， TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層。
TCP還能提供流量控制。TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發送接收端緩沖區所能接納的數據。這將防止較快主機致使較慢主機的緩沖區溢出。
從這段話中可以看到，TCP中保持可靠性的方式就是超時重發，這是有道理的，雖然TCP也可以用各種各樣的ICMP報文來處理這些，但是這也不是可靠的，最可靠的方式就是只要不得到確認，就重新發送數據報，直到得到對方的確認為止。
TCP的首部和UDP首部一樣，都有發送埠號和接收埠號。但是顯然，TCP的首部信息要比UDP的多，可以看到，TCP協議提供了發送和確認所需要的所有必要的信息。可以想像一個TCP數據的發送應該是如下的一個過程。
雙方建立連接
發送方給接受方TCP數據報，然後等待對方的確認TCP數據報，如果沒有，就重新發，如果有，就發送下一個數據報。
接受方等待發送方的數據報，如果得到數據報並檢驗無誤，就發送ACK(確認)數據報，並等待下一個TCP數據報的到來。直到接收到FIN(發送完成數據報)
中止連接
可以想見，為了建立一個TCP連接，系統可能會建立一個新的進程（最差也是一個線程），來進行數據的傳送
--
TCP協議
TCP是一個面向連接的協議，在發送輸送之前 ，雙方需要確定連接。而且，發送的數據可以進行TCP層的分片處理。
TCP連接的建立過程 ，可以看成是三次握手 。而連接的中斷可以看成四次握手 。
1.連接的建立
在建立連接的時候，客戶端首先向伺服器申請打開某一個埠(用SYN段等於1的TCP報文)，然後伺服器端發回一個ACK報文通知客戶端請求報文收到，客戶端收到確認報文以後再次發出確認報文確認剛才伺服器端發出的確認報文（繞口么），至此，連接的建立完成。這就叫做三次握手。如果打算讓雙方都做好准備的話，一定要發送三次報文，而且只需要三次報文就可以了。
可以想見，如果再加上TCP的超時重傳機制，那麼TCP就完全可以保證一個數據包被送到目的地。
2.結束連接
TCP有一個特別的概念叫做half-close，這個概念是說，TCP的連接是全雙工（可以同時發送和接收）連接，因此在關閉連接的時候，必須關閉傳和送兩個方向上的連接。客戶機給伺服器一個FIN為1的TCP報文，然後伺服器返回給客戶端一個確認ACK報文，並且發送一個FIN報文，當客戶機回復ACK報文後（四次握手），連接就結束了。
3.最大報文長度
在建立連接的時候，通信的雙方要互相確認對方的最大報文長度(MSS)，以便通信。一般這個SYN長度是MTU減去固定IP首部和TCP首部長度。對於一個乙太網，一般可以達到1460位元組。當然如果對於非本地的IP，這個MSS可能就只有536位元組，而且，如果中間的傳輸網路的MSS更加的小的話，這個值還會變得更小。
4.客戶端應用程序的狀態遷移圖
客戶端的狀態可以用如下的流程來表示：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
以上流程是在程序正常的情況下應該有的流程，從書中的圖中可以看到，在建立連接時，當客戶端收到SYN報文的ACK以後，客戶端就打開了數據交互地連接。而結束連接則通常是客戶端主動結束的，客戶端結束應用程序以後，需要經歷FIN_WAIT_1，FIN_WAIT_2等狀態，這些狀態的遷移就是前面提到的結束連接的四次握手。
5.伺服器的狀態遷移圖
伺服器的狀態可以用如下的流程來表示：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
在建立連接的時候，伺服器端是在第三次握手之後才進入數據交互狀態，而關閉連接則是在關閉連接的第二次握手以後（注意不是第四次）。而關閉以後還要等待客戶端給出最後的ACK包才能進入初始的狀態。
6.TCP伺服器設計
前面曾經講述過UDP的伺服器設計，可以發現UDP的伺服器完全不需要所謂的並發機制，它只要建立一個數據輸入隊列就可以。但是TCP不同，TCP伺服器對於每一個連接都需要建立一個獨立的進程（或者是輕量級的，線程），來保證對話的獨立性。所以TCP伺服器是並發的。而且TCP還需要配備一個呼入連接請求隊列（UDP伺服器也同樣不需要），來為每一個連接請求建立對話進程，這也就是為什麼各種TCP伺服器都有一個最大連接數的原因。而根據源主機的IP和埠號碼，伺服器可以很輕松的區別出不同的會話，來進行數據的分發。
TCP的交互數據流
對於交互性要求比較高的應用，TCP給出兩個策略來提高發送效率和減低網路負擔：（1）捎帶ACK。(2)Nagle演算法（一次盡量多的發數據）
捎帶ACK的發送方式
這個策略是說，當主機收到遠程主機的TCP數據報之後，通常不馬上發送ACK數據報，而是等上一個短暫的時間，如果這段時間裡面主機還有發送到遠程主機的TCP數據報，那麼就把這個ACK數據報「捎帶」著發送出去，把本來兩個TCP數據報整合成一個發送。一般的，這個時間是200ms。可以明顯地看到這個策略可以把TCP數據報的利用率提高很多。
Nagle演算法
上過bbs的人應該都會有感受，就是在網路慢的時候發貼，有時鍵入一串字元串以後，經過一段時間，客戶端「發瘋」一樣突然回顯出很多內容，就好像數據一下子傳過來了一樣，這就是Nagle演算法的作用。
Nagle演算法是說，當主機A給主機B發送了一個TCP數據報並進入等待主機B的ACK數據報的狀態時，TCP的輸出緩沖區裡面只能有一個TCP數據報，並且，這個數據報不斷地收集後來的數據，整合成一個大的數據報，等到B主機的ACK包一到，就把這些數據「一股腦」的發送出去。雖然這樣的描述有些不準確，但還算形象和易於理解，我們同樣可以體會到這個策略對於低減網路負擔的好處。
在編寫插口程序的時候，可以通過TCP_NODELAY來關閉這個演算法。並且，使用這個演算法看情況的，比如基於TCP的X窗口協議，如果處理滑鼠事件時還是用這個演算法，那麼「延遲」可就非常大了。
2.TCP的成塊數據流
對於FTP這樣對於數據吞吐量有較高要求的要求，將總是希望每次盡量多的發送數據到對方主機，就算是有點「延遲」也無所謂。TCP也提供了一整套的策略來支持這樣的需求。TCP協議中有16個bit表示「窗口」的大小，這是這些策略的核心。
2.1.傳輸數據時ACK的問題
在解釋滑動窗口前，需要看看ACK的應答策略，一般來說，發送端發送一個TCP數據報，那麼接收端就應該發送一個ACK數據報。但是事實上卻不是這樣，發送端將會連續發送數據盡量填滿接受方的緩沖區，而接受方對這些數據只要發送一個ACK報文來回應就可以了，這就是ACK的累積特性，這個特性大大減少了發送端和接收端的負擔。
2.2.滑動窗口
滑動窗口本質上是描述接受方的TCP數據報緩沖區大小的數據，發送方根據這個數據來計算自己最多能發送多長的數據。如果發送方收到接受方的窗口大小為0的TCP數據報，那麼發送方將停止發送數據，等到接受方發送窗口大小不為0的數據報的到來。
2.3.數據擁塞
上面的策略用於區域網內傳輸還可以，但是用在廣域網中就可能會出現問題，最大的問題就是當傳輸時出現了瓶頸（比如說一定要經過一個slip低速鏈路）所產生的大量數據堵塞問題（擁塞），為了解決這個問題，TCP發送方需要確認連接雙方的線路的數據最大吞吐量是多少。這，就是所謂的擁塞窗口。
擁塞窗口的原理很簡單，TCP發送方首先發送一個數據報，然後等待對方的回應，得到回應後就把這個窗口的大小加倍，然後連續發送兩個數據報，等到對方回應以後，再把這個窗口加倍（先是2的指數倍，到一定程度後就變成現行增長，這就是所謂的慢啟動），發送更多的數據報，直到出現超時錯誤，這樣，發送端就了解到了通信雙方的線路承載能力，也就確定了擁塞窗口的大小，發送方就用這個擁塞窗口的大小發送數據。要觀察這個現象是非常容易的，我們一般在下載數據的時候，速度都是慢慢「沖起來的」
--
TCP的超時和重傳
超時重傳是TCP協議保證數據可靠性的另一個重要機制，其原理是在發送某一個數據以後就開啟一個計時器，在一定時間內如果沒有得到發送的數據報的ACK報文，那麼就重新發送數據，直到發送成功為止。
超時
超時時間的計算是超時的核心部分，TCP要求這個演算法能大致估計出當前的網路狀況，雖然這確實很困難。要求精確的原因有兩個：(1)定時長久會造成網路利用率不高。(2)定時太短會造成多次重傳，使得網路阻塞。所以，書中給出了一套經驗公式，和其他的保證計時器准確的措施。
計時器的使用
一個連接中，有且僅有一個測量定時器被使用。也就是說，如果TCP連續發出3組數據，只有一組數據會被測量。
ACK數據報不會被測量，原因很簡單，沒有ACK的ACK回應可以供結束定時器測量。
重傳
前面曾經提到過，數據在傳輸的時候不能只使用一個窗口協議，我們還需要有一個擁塞窗口來控制數據的流量，使得數據不會一下子都跑到網路中引起「擁塞」。也曾經提到過，擁塞窗口最初使用指數增長的速度來增加自身的窗口，直到發生超時重傳，再進行一次微調。但是沒有提到，如何進行微調，擁塞避免演算法和慢啟動門限就是為此而生。
所謂的慢啟動門限就是說，當擁塞窗口超過這個門限的時候，就使用擁塞避免演算法，而在門限以內就採用慢啟動演算法。所以這個標准才叫做門限，通常，擁塞窗口記做cwnd，慢啟動門限記做ssthresh。下面我們來看看擁塞避免和慢啟動是怎麼一起工作的
演算法概要
對一個給定的連接，初始化cwnd為1個報文段，ssthresh為65535個位元組。
TCP輸出常式的輸出不能超過cwnd和接收方通告窗口的大小。擁塞避免是發送方使用 的流量控制，而通告窗口則是接收方進行的流量控制。前者是發送方感受到的網路擁塞的估 計，而後者則與接收方在該連接上的可用緩存大小有關。
當擁塞發生時（超時或收到重復確認），ssthresh被設置為當前窗口大小的一半（cwnd 和接收方通告窗口大小的最小值，但最少為2個報文段）。此外，如果是超時引起了擁塞，則 cwnd被設置為1個報文段（這就是慢啟動）。
當新的數據被對方確認時，就增加cwnd，但增加的方法依賴於我們是否正在進行慢啟 動或擁塞避免。如果cwnd小於或等於ssthresh，則正在進行慢啟動，否則正在進行擁塞避免。 慢啟動一直持續到我們回到當擁塞發生時所處位置的半時候才停止（因為我們記錄了在步驟2 中給我們製造麻煩的窗口大小的一半），然後轉為執行擁塞避免。
快速重傳和快速恢復演算法
這是數據丟包的情況下給出的一種修補機制。一般來說，重傳發生在超時之後，但是如果發送端接受到3個以上的重復ACK的情況下，就應該意識到，數據丟了，需要重新傳遞。這個機制是不需要等到重傳定時器溢出的，所以叫做快速重傳，而重新傳遞以後，因為走的不是慢啟動而是擁塞避免演算法，所以這又叫做快速恢復演算法。流程如下：
當收到第3個重復的ACK時，將ssthresh設置為當前擁塞窗口cwnd的一半。重傳丟失的 報文段。設置cwnd為ssthresh加上3倍的報文段大小。
每次收到另一個重復的ACK時， cwnd增加1個報文段大小並發送1個分組（如果新的 cwnd允許發送）。
當下一個確認新數據的ACK到達時，設置cwnd為ssthresh（在第1步中設置的值）。這個 ACK應該是在進行重傳後的一個往返時間內對步驟1中重傳的確認。另外，這個ACK也應該 是對丟失的分組和收到的第1個重復的ACK之間的所有中間報文段的確認。這一步採用的是擁 塞避免，因為當分組丟失時我們將當前的速率減半。
TCP的其它定時器
堅持定時器
用於防止通告窗口為0以後雙方互相等待死鎖的情況
堅持定時器的原理是簡單的，當TCP伺服器收到了客戶端的0滑動窗口報文的時候，就啟動一個定時器來計時，並在定時器溢出的時候向向客戶端查詢窗口是否已經增大，如果得到非零的窗口就重新開始發送數據，如果得到0窗口就再開一個新的定時器准備下一次查詢。通過觀察可以得知，TCP的堅持定時器使用1，2，4，8，16……64秒這樣的普通指數退避序列來作為每一次的溢出時間。
2.保活定時器
保活定時器更加的簡單，還記得FTP或者Http伺服器都有Sesstion Time機制么？因為TCP是面向連接的，所以就會出現只連接不傳送數據的「半開放連接」，伺服器當然要檢測到這種連接並且在某些情況下釋放這種連接，這就是保活定時器的作用。其時限根據伺服器的實現不同而不通。另外要提到的是，當其中一端如果崩潰並重新啟動的情況下，如果收到該端「前生」的保活探察，則要發送一個RST數據報文幫助另一端結束連接。

⑵ 路由器的各種閾值怎麼設置最合適

首先，這些值都保持默認就好，路由器廠商一般都已經選擇了合理的值；第二，確實影響不大，沒事折騰它大胡幹啥。Beacon時槽：發送beacon幀的間隔，網卡就是通過beacon幀來掃面到SSID的，設置太大掃描的時候會反應遲鈍一點；設置太小的話會對性能有一點影響，不過目前一般都用11n，5G都11ac了，這點影響應該感受不到。默認應該是100.RTS時槽：RTS的作用相當於：要發言之前喊一聲「我要發言了，大家都不要說話了！」，這么形容的話很容易理解了，如果設置的太小，相當於每次說話之前都喊一聲，浪費時間，沒必要；設置太大，就相當於一直不喊，如果你有很多話要說的話，就可能和別人沖突到（因為你不行茄喊別人也能聽到你說話，所以檔仿察不一定沖突），沖突到就要重說。但目前實際干擾並不大，所以一般設成最大值。而且路由器一般都會在一次批量發送數據前發送RTS，並不是完全按照這個閾值，所以這個值的意義不大。

⑶ 問下問題~知道的朋友告訴下

RPR的簡稱Resilient Packet Ring彈性分組環（802.17）, 從字眼我們可以看出這個技術的三個特點，
首先是Resilient(彈性的)，這個比較復雜我們後面慢慢談談這些彈性的優點。
再次是Packet(包),這個技術基於包的傳送。
最後是Ring(環),包的傳送要建立在Ring這種拓撲結構上。而且是一種雙環結構，每個環上最大的帶寬1.25Gbit/s, 雙環最大帶寬2.5Gbit/s. 外環攜帶內環數據包的管理位元組，內環攜帶外環的管理位元組。這樣，雙環互為保護和備份。
我們來談談「彈性」帶來的優點：
1、業務分級，將業務分為A，B，C3級。其中A細分為兩級，B細分為兩級。數據類型實際上被分為5級，每一級有不同的QoS，保證業務的區分度，分別對應實時業務，非實時業務和盡力傳送。
2、拓撲自動發現，保證了對環上新增和移去的節點，動態實現拓撲結構更新。如果要增加或者減少RPR上的總帶寬，則可以結合LCAS功能來實現。使用LCAS可以動態的調整帶寬，而不影響原有業務。
3、空間重用，RPR單播幀在目的節點剝離的機制，實現了環上帶寬的空間重用。環上帶寬可以幾個點的業務共用，帶寬利用率提高。
4、公平演算法，RPR內環和外環都支持獨立的公平演算法。公平演算法保證了低優先順序的B_EIR和C類業務在RPR環上的公平接入。通過設置公平演算法的權重，可以使不同的結點具有不同的接入速率。節點可以分別在外環和內環上設置不同的權重。
5、保護：wrapping+string, wrapping相當於斷纖處環回，倒換時間快，但是路徑不是最優。String保護模式倒換時間慢，但選擇最優路徑老賣。
目前，電信業的開放和互聯網的發展，致使網路與通信正以前所未有的速度迅猛發展。住宅用戶和各類商業用戶對帶寬的要求越來越高，且業務的發展和寬頻的增加之間相輔相成。從網路發展的角度看，乙太網（Ethernet)因其簡單性、易擴展性及其高的性價比，在區域網（LAN）中已佔主導地位。超過95%的用戶用乙太網連接其內部網路，且正以每3-5年10倍的速度增長。10Mbit/s,100Mbit/s,和1Gbit/s的乙太網已廣泛應用，10Gbit/s也即將商用化。同時，在廣域網（WAN）方面，基於同步數字序列（SDH）和密集波分復用（DWDM）的骨幹網傳輸速率已達到Tbit/s。但在城域網（MSN）方面，無論是光纖分布式數字侍則逗介面（FDDI），幀中繼（FR），非同步傳輸模式（ATM），（SDH）等傳輸效率一般都不是很高，無法跟上LAN和WAN的發展，成為整個網路的瓶頸，嚴重阻礙了WAN端到端的服務潛力。同時，這些技術又是基於語音傳輸為基礎的。雖然這些技術具有高可靠性和技術成熟等優點，但它們基於「專線」的方式，需要預先確定所需的帶寬，這與數據業務突發性的特點顯然是相背道的。這樣，就導致了光傳輸帶寬的浪費。許多研究表明，專線帶寬的利用率不足50%，多數情況下不超過20%。其次，原來的傳輸多數是用點到點為基礎的，而數據業務常需要點到多點的傳輸。這種情況下，以前者來適應後者，又必然要浪費大量的帶寬。此外，從提供新業務的角度來看，由於網路下層承載技術往往需要一定時間來提供與管理，由開始計劃到完成一條迴路一般需要幾周甚至幾月的時間，這將嚴重阻礙新數據業務的提供。再有，從成本上考慮，顯而易見，盯野目前的MAN技術也不佔有任何優勢。
建立良好的MAN，首先需要有一個價格合理、擴展性好的解決方案來適應不斷膨脹的IP流量和光纖帶寬的增長，其次要能夠對各種不同的IP業務進行優化，以最少的中間電路層在分組交換網上傳輸IP業務。同時，還必須支持現有的傳統語音業務，因為這仍是運營商的重要收入來源，且來應該在達到可接受的Qos保證時降低系統的復雜性和費用。由於MAN中存在大量的光環形網，充分利用其優點和特點更是非常必要。IP領域很早就認識到了環形網路結構的價值，發展了像令牌環，FDDI等解決方案。但這些方案都無法滿足上述MAN的需要，也無法滿足在擁塞情況下維持高的帶寬利用率和轉發量、保證節點間的平衡、迅速從節點或傳輸媒體故障中恢復、即可插可用等IP傳輸和業務傳遞發展需要。因此，並不適用於新一代的MAN。
為了解決上述MAN存在的問題，在城域范圍內構建新的環形拓撲結構，通過傳輸類似乙太網結構的分組來提供各種增強型業務，在不降低網路性能和可靠性的前提下提供更加經濟的MAN解決方案。2000年11月，IEEE802.17工作組正式成立，目標是開發一個PRP（Resilient Packet Rings)標准，優化在MAN拓撲環上數據包的傳輸。該技術結合了乙太網的實用性和光設備的強大功能，利用空分復用、統計復用和保護環提高了帶寬的利用率，使得協議開銷最小，實現了節點對網路資源的公平利用。同時，還支持業務分級（SLA）以及即插即用等特性。該技術打破了LAN與WAN的接入瓶頸，將MAN轉變為快速、簡單、可靠、能及時提供豐富增值業務的帶寬網路，為運營商、網路服務提供商提供了一種全新、有效的MAN的城域接入網解決方案，並預計到2003年制定出最終協議標准。而目前由於國際上還未形成統一標准，還有許多問題未達成一致意見，本文以下幾部分的內容綜合參考了各種提案中較為一致的意見，同時也闡述了筆者在相關問題上的看法。
RPR關鍵技術
SONET採用了固定時隙分配技術來執行帶寬分配和服務保護，乙太網則依賴於乙太網網橋或IP路由器來實現帶寬分配管理和服務保證。這樣，當使用SONET時，網路使用效率不高。當使用乙太網交換機時，網路的服務質量又得不到保證。考慮到帶寬市場的潛力、兼容性、技術特點、技術可行性和經濟可行性等5個標准，RPR採用了以緩存器插入環（BIR）為基礎的優化的MAC協議來彌補這些缺陷，提供下一代接入網所要求的恢復能力、有保證的服務質量和可管理能力。
1.網路結構與協議分層
網路拓撲基於兩個反方向傳輸的環，相鄰節點通過一對光纖連接。節點間使用光纖連接並可採用WDM進行擴容。節點具有乙太網介面，可直接與路由器相聯。RPR的內環和外環都作為工作信道來傳送簡化的SDH，或者乙太網幀格式和RPR協議封裝的數據幀和控制幀。從網路結構可以看出，RPR支持多播傳輸和點到點的連接，因此更利於數據業務的傳送。此外，當發現節點網元或光纖傳輸失效時，RPR執行快速自動保護倒換機制，數據會在50ms內轉換到無故障通路，這樣就提高了網路的健壯性。
從開放式系統互聯模型（OSI）出發，在總結多種協議 參考模型的基礎上，給出普遍認同的RPR協議參考模型。可以看出。RPR網路必須要完成的功能包括：支持多種物理層（PHY）技術，介質訪問控制（MAC）客戶層處理，MAC與MAC控制技術，運行、管理、維護、與操作（OAM&P），兼容性能考慮等。其中，PHY可採用Ethernet,SDH或WDM,因此對上層也是透明的。而MAC與MAC控制技術是RPR最主要，也是最基本的功能，是標准化組織研究的重點。前者主要內容是數據傳輸操作控制，而後者主要包括流量控制、業務等級支持（SLA）、拓撲自動識別、保護倒換等功能。
2.基本MAC協議
RPR的基本MAC結構是一個BIR，在任何一個節點都存在3個緩存，即發送緩存、接收緩存和轉發緩存。如果目的地不是本地，則通過轉發緩存發出。而本節點的報文則通過發送緩存發送數據。
RPR支持空分復用技術，即傳輸的數據報文在目的節點而不是在源節點被取出。節點11到節點2，以節點3到節點6的報文傳送是完全不影響的。這樣，網路不但能為傳送的報文提供最短的傳輸路徑，且僅佔用戶源和目的站之間的線路，環路上的其他部分可同時供其他站點使用，因此提高了帶寬的利用率。
3.流量控制
由於RPR網路資源是基於共享的，同時目的地取出報文的方式又使得環上有超過一個節點同時傳送信息，這就引發了流量控制的問題。如果不進行節點接入控制，每個節點隨意訪問將會出現網路擁塞，增加端到端的時延和丟幀率。在極端情況下，會出現完全的「飢餓」狀態，即節點的帶寬完全被上游的流量所佔用，而本節點流量無法接入。圖4中，如果節點11流往節點8和節點8流往節點10存在的流量都比較大，節點9可以傳送數據的機會就比較少。如果節點9總是被上游的流量所「覆蓋」，它就會完全「飢餓」。這種情況下，就提出了所謂「公平性」性能問題，即MA應該對環上所有節點支持上層客戶「公平地」接入下層介質。
任何一種公平性的具體的實現都是通過一些接入演算法和一些控制信息協調實現的（如Cisco公司提出的SRP-fa等）。具體演算法的選擇是RPR標准化組織的主要內容之一。
4.SLA支持和帶寬管理
為了適應MAN客戶種類繁多、交換粒度差異大的特點，除流量控制外，RPR還必須有一套靈活的動態帶寬管理和多等級承載業務SLA保證機制，以滿足不同業務對傳輸延時、抖動、、差錯率的不同要求。
雖然已提交的RPR提案中對業務等級的定義與細節描述不盡相同，但總體上看，大致可以歸納為3種：用於業務速率恆定的情況固定帶寬業務，用於有承諾帶寬並且允許一定突發數據的可變帶寬業務，與傳統IP中的業務等級類似的盡力而為的業務。數據流在進入環路時首先被分類、調度，然後根據不同的優先順序標識，被放入不同的緩存區。RPR對於第一種情況一般是採用帶寬預留的方式來保證其傳送，而對後兩種則採用了動態的帶寬分配方式。這樣，不但提高了帶寬的利用率，同時實現了對數據突發業務的語音等其他業務的有效支持。
5.拓撲自動識別
在RPR環結構中，每個節點均有上下兩個相鄰節點，網路結構相當簡單。正常狀態下，節點間沒有任何關於拓撲信息的更新。而當環初始化、新節點加入環中或需環路保護倒換時，RPR進入自動拓撲識別模式。觸發器觸發節點向環上的所有的節點發送第二層消息，節點可根據此消息判斷有哪些節點處於環形拓撲結構中，在環的兩個方向上達到其它節點需要幾跳以及環上每段光纖的狀態。這樣，在網路運行過程中，每個節點都詳細地掌握著網路的拓撲圖和每條鏈路的狀態。
基於此，網路不但實現了即插即用的特點，同時當網路發生故障時，故障點的兩側節點向其他節點廣播故障消息，然後每個節點得知每個節點和每條鏈路的現狀，這樣節點可根據業務服務等級的要求進行基於源路由的業務倒換。
6.保護倒換機制
如上所述，RPR是通過正反傳輸方向兩個光環進行組網的，這種組網方式使得RPR具有很強的健壯性。當一光環切斷或某一網元失效時，RPR可通過第二層的保護機制自動為數據包切換到另一環路上，即使兩個環路都失效，網路仍能工作。
保護倒換機制主要有兩種：採用源路由的保護機制和採用卷繞的保護機制。採用卷繞的保護機制為，當一傳輸光環線路失效時，通過信令通知網路節點，在失效處兩端節點處繞回。因此，業務流要先沿原路到達環回處，才被切換到另一環路去，再環回，最終達到目的節點。採用源路由的保護機制，RPR則不同。當一傳輸光環線路失效時，失效處兩端節點會發出第二層的控制信令沿光纖方向通知各個節點。業務流源節點接受到這個信息後，立即向另一個方向的光纖上發送報文，從而實現保護倒換。同時，在保護切換時，節點會考慮業務流不同的服務等級，根據同一節點的切換原則，依次向反方向環切換業務。兩種機制都能在50ms的時間里完成保護倒換功能。而基於源路由切換保護機制由於不需要「折回」，因此保護倒換時間更短，同時也更能節約帶寬。
RPR特點與發展現狀
綜上所述，通過結合第二層簡單的交換技術和現代光網路設備傳輸能力、帶寬有效性和低的協議開銷等性能，RPR體現出很多的優點。
1.帶寬效率
傳統的SDH網路需要環帶寬的50%作為冗餘，RPR則不然，它把兩個反方向旋轉的環都利用起來，用於傳送和控制數據業務流。此外，RPR還利用目的地報文提取的方式實現了環路帶寬的空間重新利用。這樣，就大大提高了帶寬的利用效率。
2.保護機制
RPR可以提供在故障出先後50ms時間內的自動保護倒換業務，這就與SDH的ASP相類似，為用戶提供了99.999%的服務時間。此外，業務流的優先機制確保了優先順序高的業務流能夠得到適當的處理，以滿足實時性業務的需求。
3.簡單的業務提供 RPR的目標之一是分布式接入、快速保護和業務的自動重建為節點的快速插入和刪除提供了即插即用機制。RPR也是一項在環內使用共享帶寬的分組交換技術，每一個節點都知道環的可用容量。在傳統的電路交換模式下，全網格型連接需要O（n2)個點到點連接，而RPR只需要一個與環的業務連接，這樣就大大簡化了工作。
此外，RPR的數據通信速率可達1-10Gbit/s。RPR網路支持SLA，可滿足用戶對服務等級的嚴格要求，支持端到端的傳輸服務等級。充分簡化了網路層次，消除了功能上的重復性。易管理和操作，對資源和流量都採用分布式的方式進行管理，管理信息豐富。RPR還可以及時提供新服務和迅速對網路進行升級。與現有的技術，如SDH，乙太網，ATM等相比，RPR無疑具有更強的優越性和更廣的應用前景。
目前，雖然IEEE802.17工作組還在進行RPR標准指定和測試工作，RPR的正式商用還要在一年以後，但由於預期的良好市場前景，許多公司都已推出了不同的非標准RPR城域交換產品，以期在激烈的市場競爭中占的先機。最具代表性的產品有Cisco的DPT/SRP，Nortel網路的InterWan,以及Luminous的PacketWave等。相應地，一些大的半導體生產廠商也推出或即將推出RPRMAC層晶元，比如Vitesse與Nortel合作，推出的支持GFP的RPR晶元VSC9129，Conexant推出了CX29950RingMaker環路處理單元。但在正式標准未出台前，以上方案都屬於前瞻性的技術。雖然每個供應商都承諾，一旦802.17標准出台，就改造其產品以符合802.17標准，但在規范形成前造就事實上的工業標准以影響標準的制定也是所有廠商的目的。
RPR是一種新型的網路結構和技術，是應下一代MAN的要求而設計的。RPR一經提出，便受到各方面的青睞。然而，該技術還處於早期研究與探索階段，相關的MAC和PHY還需進一步的標准化。但是由於其集IP的智能化、乙太網的經濟性和光纖環網的高帶寬效率和可靠於一身，業界普遍對它的市場前景表示樂觀。相信隨著標准化工作的進一步開展和市場的進一步擴大，RPR必將成為滿足新一代帶寬IP MAN所採用的最佳技術之一。
1、非梅毒螺旋體抗原血清試驗：用心磷脂做抗原，檢查血清中的抗心磷脂脂抗體，即反應素，屬於這一類的試驗的VDRL試驗，USR試驗及RPR（快血清反應素）試驗，可作定量測定，可用於觀察療效，判斷是否復發及再感染，
2、梅毒螺旋體特異性抗原血清試驗：用活的或死的梅毒螺旋體或其成份來測抗螺旋體抗體，屬於這一類的試驗有熒光螺旋體吸收試驗FTA-ABS;梅毒螺旋體血凝試驗TPHA：這類試驗的特異性強，可用作證實試驗，但不能用作觀察療效，判斷復發及再感染。
梅毒是由梅毒螺旋體引起的一種性病。感染梅毒後，人體內會產生兩類抗體，類是直接針對梅毒螺旋體的抗體，另一類則是針對類脂質的抗體。針對類脂質的抗體因不直接針對梅毒螺旋體，因此無特異性，除感染梅毒外，患另外一些疾病以及生理狀況的改變，體內也可能產生低滴度的抗類脂質抗體。診斷梅毒時，所做的梅毒血清學檢查即檢測這兩類抗體。前面提到的RPR試驗，即為檢測類脂質抗體的實驗；而TPHA則為直接檢測梅毒螺旋體的實驗。因RPR是檢測類脂質抗體，而不是直接檢測抗梅毒螺旋體抗體的實驗，因而無特異性，凡能導致產生類脂質抗體的疾病，均能使RPR陽性。除梅毒外，患上呼吸道感染、肺炎、活動性肺結核、風濕性心臟病、亞急性細菌性心內膜炎、傳染性肝炎、肝硬化、慢性腎炎、鉤端螺旋體病、麻風、瘧疾、類風濕性關節炎、系統性紅斑狼瘡及海洛因成癮等，都可導致RPR陽性。
梅毒以外其他原因造成的RPR陽性有一個特點，滴度一般較低，小於1：8。RPR實驗容易出現假陽性，醫生常同時做特異性較強的TPHA實驗來證實梅毒診斷。值得一提的是，TPHA等直接針對梅毒螺旋體的特異性實驗，在一般人中也有1%的假陽性。國內曾報道某醫院內科住院患者中，TPHA陽性者竟有一半是假陽性。已知可造成TPHA陽性的疾病有：類風濕性關節炎、紅斑狼瘡、糖尿病、結腸癌、淋巴肉瘤、丙型肝炎、肝硬化、AIDS、麻風、生殖器皰疹、海洛因成癮等。
除疾病外，某些生理狀況的改變，如妊娠，也可導致RPR及TPHA陽性。特別值得一提的是，老年人梅毒血清學檢查，假陽性率較一般人高，有報道可達2%。許多老年人患常見的內科疾病，也可導致梅毒化驗陽性。不久前，國內某醫院報道，他們收治的5例63~80歲老年內科疾病患者，分別患冠心病、腦血管疾病、糖尿病及白血病，住院期間，均出現過RPR和TPHA陽性。
梅毒血清學檢查是診斷梅毒的重要依據，但不是唯一依據。診斷梅毒，除依據化驗結果外，更重要的依據是詳細了解患者的生活史和既往病史，以及詳細的體查。綜合分析後慎重作出判斷，才能避免梅毒化驗結果假陽性造成的誤診

參考資料： http://ke..com/view/898392.htm?fr=ala0_1

⑷ linux /proc/net/dev裡面都是什麼意思

/proc目錄
Linux 內核提供了一種通過 /proc 文件系統，在運行時訪問內核內部數據結構、改變內核設置的機制。proc文件系統是一個偽文件系統，它只存在內存當中，而不佔用外存空間。它以文件系統的方式為訪問系統內核數據的操作提供介面。用戶和應用程序可以通過
proc得到系統的信息，並可以改變內核的某些參數。由於系統的信息，如進程，是動態改變的，所以用戶或應用程序讀取proc文件時，proc文件系統是
動態從系統內核讀出所需信息並提交的。下面列出的這些文件或子文件夾，並不是都是在你的系統中存在，這取決於你的內核配置和裝載的模塊。另外，在
/proc下還有三個很重要的目錄：net，scsi和sys。
Sys目錄是可寫的，可以通過它來訪問或修改內核的參數，而net和scsi則依賴於內核配置。例如，如果系統不支持scsi，則scsi
目錄不存在。
除了以上介紹的這些，還有的是一些以數字命名的目錄，它們是進程目錄。系統中當前運行的每一個進程都有對應的一個目錄在/proc下，以進程的 PID號為目錄名，它們是讀取進程信息的介面。而self目錄則是讀取進程本身的信息介面，是一個link。
2. 子文件或子文件夾
/proc/buddyinfo 每個內存區中的每個order有多少塊可用，和內存碎片問題有關
/proc/cmdline 啟動時傳遞給kernel的參數信息
/proc/cpuinfo cpu的信息
/proc/crypto 內核使用的所有已安裝的加密密碼及細節
/proc/devices 已經載入的設備並分類

/proc/dma 已注冊使用的ISA DMA頻道列表
/proc/execdomains Linux內核當前支持的execution domains
/proc/fb 幀緩沖設備列表，包括數量和控制它的驅動
/proc/filesystems 內核當前支持的文件系統類型
/proc/interrupts x86架構中的每個IRQ中斷數
/proc/iomem 每個物理設備當前在系統內存中的映射
/proc/ioports 一個設備的輸入輸出所使用的注冊埠范圍
/proc/kcore 代表系統的物理內存，存儲為核心文件格式，里邊顯示的是位元組數，等於RAM大小加上4kb
/proc/kmsg 記錄內核生成的信息，可以通過/sbin/klogd或/bin/dmesg來處理
/proc/loadavg 根據過去一段時間內CPU和IO的狀態得出的負載狀態，與uptime命令有關
/proc/locks 內核鎖住的文件列表
/proc/mdstat 多硬碟，RAID配置信息(md=multiple disks)
/proc/meminfo RAM使用的相關信息
/proc/misc 其他的主要設備(設備號為10)上注冊的驅動
/proc/moles 所有載入到內核的模塊列表
/proc/mounts 系統中使用的所有掛載
/proc/mtrr 系統使用的Memory Type Range Registers (MTRRs)
/proc/partitions 分區中的塊分配信息
/proc/pci 系統中的PCI設備列表
/proc/slabinfo 系統中所有活動的 slab 緩存信息
/proc/stat 所有的CPU活動信息
/proc/sysrq-trigger

使用echo命令來寫這個文件的時候，遠程root用戶可以執行大多數的系統請求關鍵命令，就好像在本地終端執行一樣。要寫入這個文件，需要把/proc
/sys/kernel/sysrq不能設置為0。這個文件對root也是不可讀的
/proc/uptime 系統已經運行了多久
/proc/swaps 交換空間的使用情況
/proc/version Linux內核版本和gcc版本
/proc/bus 系統匯流排(Bus)信息，例如pci/usb等
/proc/driver 驅動信息
/proc/fs 文件系統信息
/proc/ide ide設備信息
/proc/irq 中斷請求設備信息
/proc/net 網卡設備信息
/proc/scsi scsi設備信息
/proc/tty tty設備信息
/proc/net/dev 顯示網路適配器及統計信息
/proc/vmstat 虛擬內存統計信息
/proc/vmcore 內核panic時的內存映像
/proc/diskstats 取得磁碟信息
/proc/schedstat kernel調度器的統計信息
/proc/zoneinfo 顯示內存空間的統計信息，對分析虛擬內存行為很有用
以下是/proc目錄中進程N的信息
/proc/N pid為N的進程信息
/proc/N/cmdline 進程啟動命令
/proc/N/cwd 鏈接到進程當前工作目錄
/proc/N/environ 進程環境變數列表
/proc/N/exe 鏈接到進程的執行命令文件
/proc/N/fd 包含進程相關的所有的文件描述符
/proc/N/maps 與進程相關的內存映射信息
/proc/N/mem 指代進程持有的內存，不可讀
/proc/N/root 鏈接到進程的根目錄
/proc/N/stat 進程的狀態
/proc/N/statm 進程使用的內存的狀態
/proc/N/status 進程狀態信息，比stat/statm更具可讀性
/proc/self 鏈接到當前正在運行的進程

⑸ coherence緩存支持排序嗎

1.2.1 分布式集群緩存
Coherence是一個分布式的緩存方案，並且通過集群為應用提供強大的緩存後備支持。Coherence主要是內存緩存，即存儲區域主要在內存當中。
與一般的分布式緩存方案如JBossCache, Memcache 等相同，分布式緩存的價值基於網路IO性能高於DB查詢的磁碟IO性能這樣一個特點。
Coherence所有的設計都是基於多個（可以是非常多）的JVM，很多Coherence的測試都是使用幾十甚至上百個節點來進行的。
下圖展示了一個典型的WAS項目架構：WAS集群 + Near型Coherence集群架構。對於大型Web2.0網站(PHP或其他)，集成Coherence也是類似的。

1.2.2自管理
Coherence使用的網路協議是TCMP ，是對UDP，TCP/IP的組合使用。Coherence能將啟動的實例節點(Node)自動組成為集群(Cluster)。在一個區域網環境中，通過多播(Multicast)機制，第1個啟動的Node能自動發現後啟動的Node，第1，2個Node同樣能發現之後啟動的其他Node，依次類推，自動組成集群； 並且也能自動檢測到死亡節點。集群各節點間通過單播(Unicast)機制進行數據復制，同步及發送通知消息。拍脊
Coherence集群以統一的邏輯試圖對外提供緩存的讀寫介面，看起來使用Coherence Client就像在使用一個緩存一樣。

1.2.3 自動容錯和恢復
基於自管理的特點，一個Node掛掉後，集群能自動監測到，並做好死亡節點的數據恢復機制，客戶端依然能正確的讀出在死亡節點上存儲的數據，容錯和恢復對客戶端來說是透明的。

1.2.4 分區緩存(Partitioned Cache)
這是Coherence與眾不同的地方。一般集群如：JBossCache, Websphere 集群等，每余飢個Node都有數據的完整拷貝，Node間通過復制來實現數據同步和一致性，一般來說採用全復制模式，即一份數據在各節點上都有一份拷貝。這種模式下，節點要存儲了較多的數據，同步復制時比較消耗網路帶寬。
而Coherence的分區緩存只將一個Node上的數據在另一節點上做1個備份，有效降低復制的消耗好時間，並節省內存總需求，只需復制模式的1/N (N為緩存節點個數)。

1.2.5 線性擴展
假如你的Coherence集群已經有4個Node，當系統數據量過大引起Cache容量滿員，導致緩存性能下降時，可以通過啟動新的Node來擴容，改善集群的性能。
這一點也是源自分區緩存技術，集群有N個Node，每個Node只存放1/N的數據，這種設計讓Coherence能夠處理非常多的數據，只需要通過增加節點的數量，就可以處理更多的數據。
下圖為例，當兩台機器，4個存儲Node不夠用時，通過新增機器，新增Node實例即可自動加入集群，提升Coherence緩存性能。

線性擴展更重要體現在性能上，下圖展示了，Coherence集群通過增加機器，增加Node實例使得交易耗時大幅降低，而且隨著集群規豎賀返模呈線性下降。

1.2.6易用性
雖然上述特點看起來似乎很復雜，但那都是Coherence自己內部的事兒。對於客戶端來說，與最簡單的Map 操作一樣，僅僅是 put(key,value), get(key) 等。
java代碼
Java代碼
<span style="font-size: small;"> NamedCache cache = CacheFactory.getCache("dist-cache");
cache.put(key, value);
Object value = cache.get(key);</span>

⑹ java web開發緩存方案，ehcache和redis哪個更好

其實沒有好與不好的絕對
給你知乎上的介紹：
ehcache直接在jvm虛擬機中緩存，速度快，效率高；但是緩存共享麻煩，集群分布式應用不方便。
redis是通過socket訪問到緩存服務，效率比ecache低，比資料庫要快很多，處理集群和分布式緩存唯雹方便，有成熟的方案。

如果是單個應用或者對緩存訪問要求很高的應用，用ehcache。
如果是大型系統，存在緩激粗存共享、分布式部署、緩存內容很大的，建議用redis。

補充下：ehcache也有緩存共享方案，不過是通過RMI或者Jgroup多播方式進行廣播緩存通知更新，緩存共享復雜，維護不方便；簡單的共享可以，但是涉及到緩存恢復，大數據緩存，則不合適。明山鎮

⑺ python 實現udp組播

有關知識
基本概念
單播：兩個主機間單對單的通信
廣播：一個主機對整個區域網上所有主機上的數據通信（網路地址全1）
單播和廣播是兩個極端，要麼對一個主機進行通信，要麼對整個區域網的主機進行通信

組播：實際情況下，經常需要對一組特定的主機進行通信，而不是所有區域網上的主機
IP組播（也稱多址廣播或多播），是一種允許一台或多台主機發送數據包到多台主機的TCP/IP網路技術。

多播是 IPv6 數據包的 3 種基本目的地址類型之一，多播是一點對多點的通信,IPv6 沒有採用 IPv4 中的組播術語，而是將廣播看成是多播的一個特殊例子。

多播組只能用UDP 或者原始套接字實現，不能用TCP。

廣播地址
在使用TCP/IP 協議的網路中，主機標識段host ID 為全1 的IP 地址為廣播地址，廣播的分組傳送給host ID段所涉及的所有計算機。

傳輸層只有UDP可以廣播 。

組播地址
IP 組播通信必須依賴於 IP 多播地址，在 IPv4 中它是一個 D 類 IP 地址，范圍從 224.0.0.0 到 239.255.255.255，並被劃分為局部鏈接多播地址、預留多播地址和管理許可權多播地址3類：

局部鏈接多播地址范圍在 224.0.0.0~224.0.0.255，這是為路由協議和其它用途保留的地址，路由器並不轉發屬於此范圍的IP包；

預留多播地址為 224.0.1.0~238.255.255.255，可用於全球范圍（如Internet）或網路協議；

管理許可權多播地址為 239.0.0.0~239.255.255.255，可供組織內部使用，類似於私有 IP 地址，不能用於 Internet，可限制多播范圍。

組播地址與MAC地址的映射
使用同一個 IP 多播地址接收多播數據包的所有主機構成了一個主機組，也稱為多播組。一個多播組的成員是隨時變動的，一台主機可以隨時加入或離開多播組，多播組成員的數目和所在的地理位置也不受限制，一台主機也可以屬於幾個多播組。

這個我們可以這樣理解，多辯宏鄭播地址就類似於 QQ 群號，多播組相當於 QQ 群，一個個的主機就相當於群裡面的成員。

設備驅動程序就必須接收所有多播數據幀，然後對它們進行過濾，這個過濾過程是網路驅動或IP層自動完成。（設備驅動程序會對多播數據進行過濾，將其發到相應的位置）

組播應用
單點對多點應用
點對多點應用是指一個發送者，多個接收者的應用形式，這是最常見的多播應用形式。典型的攜頌應用包括：媒體廣播、媒體推送、信息緩存、事件通知和狀態監視等。

多點對單點應用
多點對點應用是指多個發送者，一個接收者的應用形式。通常是雙向請求響應應用，任何一端（多點或點）都有可能發起請求。典型應用包括：資源查找、數據收集、網路競拍、信息詢問等。

多點對多點應用
多點對多點應用是指多個發送者和多個接收者的應用形式。通常，每個接收者可以接收多個發送者發送的數據，同時，每個發送者可以把數據發送給多個接收者。典型應用包括：多點會議、資源同步、並行處理、協同處理、遠程學習、討論組、分布式交互模擬（DIS）、多人游戲等。
參考的文章 https://www.cnblogs.com/schips/p/12552534.html

下面實現一個python（3.8）的演示原理的版本
功能：1.每個客戶端隨機生成一個id當做標識
2.每個客戶端綁定本機一個Ip的埠（在同一台機器上面可以啟動多個腳本）
3. 加入同一網段的一個組播地址
4. 啟動後，發送一個消息
5. 收到消息後，根據id判斷絕襲消息是否是自己發出的，其它客戶端的時候回一個消息

啟動兩個腳本以後效果如下：

ps:在相同網段可以很容易實現組播。跨網段組播必須打開三層交換機的組播路由協議，一般是PIM 稀疏模式，一般三層交換機的默認配置是沒有打開組播路由的。（待實踐）

⑻ 數據鏈路層（二）

廣播信道可以進行一對多的通信，因此使用廣播信道的區域網被稱為共享式區域網。現在具有更高性能的使用點對點鏈路和鏈路交換機的交換式局迅培域網在有線領域已完全取代了共享式區域網。但無線區域網仍然使用的是共享畝喚唯媒體技術。

使用廣播信道連接多個站點，必須解決如果同時有兩個以上的站點在發送數據時共享信道上的信號沖突的問題。因此共享信道要著重考慮的一個問題就是如何協調多個發送和接收站點對一個共享傳輸媒體的佔用，即媒體訪問/接入控制(MAC) Medium Access Control 或 多點接入、多址訪問 Multiple Access，媒體接入控制技術主要分為以下兩大類：

區域網最主要的特點是： 網路為一個單位所擁有，且地理范圍和站點數目均有限。
區域網具有如下的一些主要優點：
1、具有廣播功能，從一個站點可很方便地訪問全網。區域網上的主機可共享連接在區域網上的各種硬體和軟體資源。
2、便於系統的擴展和逐漸地演變，各設備的位置可靈活調整和改變。
3、提高了系統的可靠性、可用性和殘存性。

現在乙太網已經在區域網市場上占據了絕對優勢，雙絞線是區域網中的主流傳輸媒體，數據率很高時則使用光纖。
為了使數據鏈路層能更好地適應多種區域網標准，802 委員會就將區域網的數據鏈路層拆成兩個子層：
1、邏輯鏈路控制 LLC (Logical Link Control)子層
2、媒體接入控制 MAC (Medium Access Control)子層。

與接入到傳輸媒體有關的內容都放在 MAC子層，而 LLC 子層則與傳輸媒體無關，不管採用何種協議的區域網對 LLC 子層來說都是透明的

由於 TCP/IP 體系經常使用的區域網是 DIX Ethernet V2 而不是 802.3 標准中的幾種區域網，因此現在 802 委員會制定的邏輯鏈路控制子層 LLC（即 802.2 標准）的作用已經不大了。
很多廠商生產的適配器上就僅裝有 MAC 協議而沒有 LLC 協議。

網路介面板又稱為通信適配器(adapter)或網路介面卡 NIC (Network Interface Card)，或「網卡」。
適配器的重要功能：
1、進行串列/並行轉換。
2、對數據進行緩存。
3、在計算機的操作系統安裝設備驅動程序。
4、實現乙太網協議。

乙太網採用的協調方式即使用一種特殊協議CSMA/CD，即 載波監聽多點接入/碰撞檢測 ，全稱為Carrier Sense Multiple Access with Collision Detection。

重要特性：使用 CSMA/CD 協議的乙太網不能進行全雙工通信而只能進行 雙向交替通信（半雙工通信） 。
每個站在發送數據之後的一小段時間內，存在著遭遇碰撞的可能性。
這種發送的不確定性使整個乙太網的平鏈握均通信量遠小於乙太網的最高數據率。
最先發送數據幀的站，在發送數據幀後至多經過時間 2τ（兩倍的端到端往返時延）就可知道發送的數據幀是否遭受了碰撞。
乙太網的端到端往返時延 2τ 稱為 爭用期 ，或碰撞窗口。
經過爭用期這段時間還沒有檢測到碰撞，才能肯定這次發送不會發生碰撞。

最短有效幀長 ： 如果發生沖突，就一定是在發送的前 64 位元組之內
由於一檢測到沖突就立即中止發送，這時已經發送出去的數據一定小於 64 位元組。
乙太網規定了最短有效幀長為 64 位元組，凡長度小於 64 位元組的幀都是由於沖突而異常中止的無效幀。
因此， 如果發送的幀太短，有可能檢測不到發生的碰撞

強化碰撞：當發送數據的站一旦發現發生了碰撞時，立即停止發送數據；
再繼續發送若干比特的人為干擾信號(jamming signal)，以便讓所有用戶都知道現在已經發生了碰撞。

傳統乙太網採用星形拓撲，在星形的中心則增加了一種可靠性非常高的設備，叫做集線器(hub) ，每個站需要用兩對無屏蔽雙絞線，分別用於發送和接收。

1990年，IEEE制定出星形乙太網10BASE-T 的標准802.3i。10BASE-T 的通信距離稍短，每個站到集線器的距離不超過 100 m。
10BASE-T 雙絞線乙太網的出現，是區域網發展史上的一個非常重要的里程碑，它為乙太網在區域網中的統治地位奠定了牢固的基礎。 它的一些特點如下：

在使用點對點信道的數據鏈路中不需要使用地址，而當多個站點連接在同一個廣播信道上想要實現兩個站點的通信則每個站點就要有唯一的標識，即一個 數據鏈路層地址 ，在每個發送的幀中必須攜帶標識接受站點和發送站點的地址，由於該地址用於媒體接入控制，因此稱為MAC地址，在區域網中，稱為硬體地址或物理地址。

IEEE 的注冊管理機構 RA 負責向廠家分配地址欄位的前三個位元組(即高位 24 位)。
地址欄位中的後三個位元組(即低位 24 位)由廠家自行指派，稱為擴展標識符，必須保證生產出的適配器沒有重復地址。
一個地址塊可以生成2^24個不同的地址。這種 48 位地址稱為 MAC-48，它的通用名稱是EUI-48。「MAC地址」實際上就是適配器地址或適配器標識符EUI-48。

適配器從網路上每收到一個 MAC 幀就首先用硬體檢查 MAC 幀中的 MAC 地址.如果是發往本站的幀則收下，然後再進行其他的處理。否則就將此幀丟棄，不再進行其他的處理。
「發往本站的幀」包括以下三種幀：
1、單播(unicast)幀（一對一）
2、廣播(broadcast)幀（一對全體）
3、多播(multicast)幀（一對多）

常用的乙太網MAC幀格式有兩種標准 ：
1、DIX Ethernet V2 標准 （最常用，下文介紹這種幀）
2、IEEE 的 802.3 標准

無效的 MAC 幀 ：
1、幀的長度不是整數個位元組；
2、用收到的幀檢驗序列 FCS 查出有差錯；
3、數據欄位的長度不在 46 ~ 1500 位元組之間。
4、有效的 MAC 幀長度為 64 ~ 1518 位元組之間。
5、對於檢查出的無效 MAC 幀就簡單地丟棄。乙太網不負責重傳丟棄的幀。

在數據鏈路層擴展區域網是使用 網橋 。
網橋工作在數據鏈路層，它根據 MAC 幀的目的地址對收到的幀進行轉發。
網橋具有 過濾幀 的功能。當網橋收到一個幀時，並不是向所有的介面轉發此幀，而是先檢查此幀的目的 MAC 地址，然後再確定將該幀轉發到哪一個介面

目前使用得最多的網橋是 透明網橋(transparent bridge) 。
「透明」是指區域網上的站點並不知道所發送的幀將經過哪幾個網橋，因為網橋對各站來說是看不見的。 透明網橋是一種即插即用設備，其標準是 IEEE 802.1D

透明網橋使用了 生成樹演算法 ：這是為了避免產生轉發的幀在網路中不斷地兜圈子

1、源路由(source route)網橋在發送幀時將詳細的路由信息放在幀的首部中。
2、源站以廣播方式向欲通信的目的站發送一個發現幀，每個發現幀都記錄所經過的路由。
3、發現幀到達目的站時就沿各自的路由返回源站。源站在得知這些路由後，從所有可能的路由中選擇出一個最佳路由。凡從該源站向該目的站發送的幀的首部，都必須攜帶源站所確定的這一路由信息。

1990 年問世的交換式集線器(switching hub)，可明顯地提高區域網的性能。交換式集線器常稱為乙太網交換機(switch)或第二層交換機（表明此交換機工作在數據鏈路層）。乙太網交換機通常都有十幾個介面。因此，乙太網交換機實質上就是一個多介面的網橋，可見交換機工作在 數據鏈路層 。

虛擬區域網 VLAN 是由一些區域網網段構成的與物理位置無關的邏輯組。這些網段具有某些共同的需求。
每一個 VLAN 的幀都有一個明確的標識符，指明發送這個幀的工作站是屬於哪一個 VLAN。虛擬區域網其實只是區域網給用戶提供的一種服務，而並不是一種新型區域網。

1、當 B1 向 VLAN2 工作組內成員發送數據時，工作站 B2 和 B3 將會收到廣播的信息。
2、B1 發送數據時，工作站 A1, A2 和 C1都不會收到 B1 發出的廣播信息。
3、虛擬區域網限制了接收廣播信息的工作站數，使得網路不會因傳播過多的廣播信息(即「廣播風暴」)而引起性能惡化。

虛擬區域網協議允許在乙太網的幀格式中插入一個 4 位元組的標識符，稱為 VLAN 標記(tag)，用來指明發送該幀的工作站屬於哪一個虛擬區域網。

速率達到或超過 100 Mb/s 的乙太網稱為高速乙太網。
在雙絞線上傳送 100 Mb/s 基帶信號的星型拓撲乙太網，仍使用 IEEE 802.3 的CSMA/CD 協議。100BASE-T 乙太網又稱為快速乙太網(Fast Ethernet)。
1、可在全雙工方式下工作而無沖突發生。因此，不使用 CSMA/CD 協議。
2、MAC 幀格式仍然是 802.3 標准規定的。
3、保持最短幀長不變，但將一個網段的最大電纜長度減小到 100 m。
4、幀間時間間隔從原來的 9.6 μs 改為現在的 0.96 μs。

允許在 1 Gb/s 下全雙工和半雙工兩種方式工作。使用 802.3 協議規定的幀格式。
在半雙工方式下使用 CSMA/CD 協議（全雙工方式不需要使用 CSMA/CD 協議）。
與 10BASE-T 和 100BASE-T 技術向後兼容。

全雙工方式：當吉比特乙太網工作在全雙工方式時（即通信雙方可同時進行發送和接收數據），不使用載波延伸和分組突發。

10 吉比特乙太網與 10 Mb/s，100 Mb/s 和 1 Gb/s 乙太網的幀格式完全相同。
10 吉比特乙太網還保留了 802.3 標准規定的乙太網最小和最大幀長，便於升級。
10 吉比特乙太網不再使用銅線而只使用光纖作為傳輸媒體。
10 吉比特乙太網只工作在全雙工方式，因此沒有爭用問題，也不使用 CSMA/CD 協議

區域網物理層 LAN PHY。區域網物理層的數據率是 10.000 Gb/s。
可選的廣域網物理層 WAN PHY。廣域網物理層具有另一種數據率，這是為了和所謂的「Gb/s」的 SONET/SDH（即OC-192/STM-64）相連接。
（為了使 10 吉比特乙太網的幀能夠插入到 OC-192/STM-64 幀的有效載荷中，就要使用可選的廣域網物理層，其數據率為 9.95328 Gb/s。）

乙太網已成功地把速率提高到 1 ~ 10 Gb/s ，所覆蓋的地理范圍也擴展到了城域網和廣域網，因此現在人們正在嘗試使用乙太網進行寬頻接入。
乙太網接入的重要特點是它可提供雙向的寬頻通信，並且可根據用戶對帶寬的需求靈活地進行帶寬升級。
採用乙太網接入可實現端到端的乙太網傳輸，中間不需要再進行幀格式的轉換。這就提高了數據的傳輸效率和降低了傳輸的成本。

⑼ linux下配置網路連接

linux 命令配置網路連接首先,先了解傳統的網路設置命令:
1. 使用ifconfig命令設置並查看網路介面情況
示例1: 設置eth0的IP，同時激活設備:
# ifconfig eth0 192.168.4.1 netmask 255.255.255.0 up
示例2: 設置eth0別名設備 eth0:1 的IP，並添加路由
# ifconfig eth0:1 192.168.4.2
# route add ?host 192.168.4.2 dev eth0:1
示例3:激活（禁用）設備
# ifconfig eth0:1 up(down)
示例4:查看所有（指定）網路介面設置
# ifconfig (eth0)
2. 使用route 命令設置路由表
示例1:添加到主機路由
# route add ?host 192.168.4.2 dev eth0:1
# route add ?host 192.168.4.1 gw 192.168.4.250
示例2:添加到網路的路由
# route add ?net IP netmask MASK eth0
# route add ?net IP netmask MASK gw IP
# route add ?net IP/24 eth1
示例3:添加默認網關
# route add default gw IP
示例4:刪除路由
# route del ?host 192.168.4.1 dev eth0:1
示例5:查看路由信息
# route 或 route -n (-n 表示不解析名字,列出速度會比route 快)
3.ARP 管理命令
示例1:查看ARP緩存
# arp
示例2: 添加
# arp ?s IP MAC
示例3: 刪除
# arp ?d IP
4. ip是iproute2軟體包裡面的一個強大的網路設置工具，他能夠替代一些傳統的網路管理工具。例如：ifconfig、route等,
上面的示例完萬能用下面的ip命令實現,而且ip命令能實現更多的功能.下面介紹一些示例:
4.0 ip命令的語法
ip命令的用法如下：
ip [OPTIONS] OBJECT [COMMAND [ARGUMENTS]]
4.1 ip link set--改動設備的屬性. 縮寫：set、s
示例1：up/down 起動／關閉設備。
# ip link set dev eth0 up
這個等於傳統的 # ifconfig eth0 up(down)
示例2：改動設備傳輸隊列的長度。
參數:txqueuelen NUMBER或txqlen NUMBER
# ip link set dev eth0 txqueuelen 100
示例3：改動網路設備MTU(最大傳輸單元)的值。
# ip link set dev eth0 mtu 1500
示例4： 修改網路設備的MAC地址。
參數: address LLADDRESS
# ip link set dev eth0 address 00:01:4f:00:15:f1
4.2 ip link show--顯示設備屬性. 縮寫：show、list、lst、sh、ls、l
-s選項出現兩次或更多次，ip會輸出更為周詳的錯誤信息統計。
示例:
# ip -s -s link ls eth0
eth0: mtu 1500 qdisc cbq qlen 100
link/ether 00:a0:cc:66:18:78 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
2449949362 2786187 0 0 0 0
RX errors: length crc frame fifo missed
0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
178558497 1783946 332 0 332 35172
TX errors: aborted fifo window heartbeat
0 0 0 332
這個命令等於傳統的 ifconfig eth0
5.1 ip address add--添加一個新的協議地址. 縮寫：add、a
示例1：為每個地址設置一個字元串作為標簽。為了和Linux-2.0的網路別名兼容，這個字元串必須以設備名開頭，接著一個冒號，
# ip addr add local 192.168.4.1/28 brd + label eth0:1 dev eth0
示例2: 在乙太網介面eth0上增加一個地址192.168.20.0，掩碼長度為24位(155.155.155.0)，標准廣播地址，標簽為eth0:Alias：
# ip addr add 192.168.4.2/24 brd + dev eth1 label eth1:1
這個命令等於傳統的: ifconfig eth1:1 192.168.4.2
5.2 ip address delete--刪除一個協議地址. 縮寫：delete、del、d
# ip addr del 192.168.4.1/24 brd + dev eth0 label eth0:Alias1
5.3 ip address show--顯示協議地址. 縮寫：show、list、lst、sh、ls、l
# ip addr ls eth0
5.4.ip address flush--清除協議地址. 縮寫：flush、f
示例1 : 刪除屬於私網10.0.0.0/8的所有地址：
# ip -s -s a f to 10/8
示例2 : 取消所有乙太網卡的IP地址
# ip -4 addr flush label "eth0"
6. ip neighbour--neighbour/arp表管理命令
縮寫 neighbour、neighbor、neigh、n
命令 add、change、replace、delete、fulsh、show(或list)
6.1 ip neighbour add -- 添加一個新的鄰接條目
ip neighbour change--修改一個現有的條目
ip neighbour replace--替換一個已有的條目
縮寫：add、a；change、chg；replace、repl
示例1: 在設備eth0上，為地址10.0.0.3添加一個permanent ARP條目：
# ip neigh add 10.0.0.3 lladdr 0:0:0:0:0:1 dev eth0 nud perm
示例2:把狀態改為reachable
# ip neigh chg 10.0.0.3 dev eth0 nud reachable
6.2.ip neighbour delete--刪除一個鄰接條目
示例1:刪除設備eth0上的一個ARP條目10.0.0.3
# ip neigh del 10.0.0.3 dev eth0
6.3.ip neighbour show--顯示網路鄰居的信息. 縮寫：show、list、sh、ls
示例1: # ip -s n ls 193.233.7.254
193.233.7.254. dev eth0 lladdr 00:00:0c:76:3f:85 ref 5 used 12/13/20 nud reachable
6.4.ip neighbour flush--清除鄰接條目. 縮寫：flush、f
示例1: (-s 能顯示周詳信息)
# ip -s -s n f 193.233.7.254
7. 路由表管理
7.1.縮寫 route、ro、r
7.5.路由表
從Linux-2.2開始，內核把路由歸納到許多路由表中，這些表都進行了編號，編號數字的范圍是1到255。另外，
為了方便，還能在/etc/iproute2/rt_tables中為路由表命名。
默認情況下，所有的路由都會被插入到表main(編號254)中。在進行路由查詢時，內核只使用路由表main。
7.6.ip route add -- 添加新路由
ip route change -- 修改路由
ip route replace -- 替換已有的路由
縮寫：add、a；change、chg；replace、repl
示例1: 設置到網路10.0.0/24的路由經過網關193.233.7.65
# ip route add 10.0.0/24 via 193.233.7.65
示例2: 修改到網路10.0.0/24的直接路由，使其經過設備mmy
# ip route chg 10.0.0/24 dev mmy
示例3: 實現鏈路負載平衡.加入預設多路徑路由，讓ppp0和ppp1分擔負載(注意：scope值並非必需，他只不過是告訴內核，
這個路由要經過網關而不是直連的。實際上，如果你知道遠程端點的地址，使用via參數來設置就更好了)。
# ip route add default scope global nexthop dev ppp0 nexthop dev ppp1
# ip route replace default scope global nexthop dev ppp0 nexthop dev ppp1
示例4: 設置NAT路由。在轉發來自192.203.80.144的數據包之前，先進行網路地址轉換，把這個地址轉換為193.233.7.83
# ip route add nat 192.203.80.142 via 193.233.7.83
示例5: 實現數據包級負載平衡,允許把數據包隨機從多個路由發出。weight 能設置權重.
# ip route replace default equalize nexthop via 211.139.218.145 dev eth0 weight 1 nexthop via 211.139.218.145 dev eth1 weight 1
7.7.ip route delete-- 刪除路由
縮寫：delete、del、d
示例1:刪除上一節命令加入的多路徑路由
# ip route del default scope global nexthop dev ppp0 nexthop dev ppp1
7.8.ip route show -- 列出路由
縮寫：show、list、sh、ls、l
示例1: 計算使用gated/bgp協議的路由個數
# ip route ls proto gated/bgp |wc
1413 9891 79010
示例2: 計算路由緩存裡面的條數，由於被緩存路由的屬性可能大於一行，以此需要使用-o選項
# ip -o route ls cloned |wc
159 2543 18707
示例3: 列出路由表TABLEID裡面的路由。預設設置是table main。TABLEID或是個真正的路由表ID或是/etc/iproute2/rt_tables文件定義的字元串，
或是以下的特別值：
all -- 列出所有表的路由；
cache -- 列出路由緩存的內容。
ip ro ls 193.233.7.82 tab cache
示例4: 列出某個路由表的內容
# ip route ls table fddi153
示例5: 列出默認路由表的內容
# ip route ls
這個命令等於傳統的: route
7.9.ip route flush -- 擦除路由表
示例1: 刪除路由表main中的所有網關路由（示例：在路由監視程式掛掉之後）：
# ip -4 ro flush scope global type unicast
示例2:清除所有被克隆出來的IPv6路由：
# ip -6 -s -s ro flush cache
示例3: 在gated程式掛掉之後，清除所有的BGP路由：
# ip -s ro f proto gated/bgp
示例4: 清除所有ipv4路由cache
# ip route flush cache
*** IPv4 routing cache is flushed.
7.10 ip route get -- 獲得單個路由 .縮寫：get、g
使用這個命令能獲得到達目的地址的一個路由及他的確切內容。
ip route get命令和ip route show命令執行的操作是不同的。ip route show命令只是顯示現有的路由，而ip route get命令在必要時會派生出新的路由。
示例1: 搜索到193.233.7.82的路由
# ip route get 193.233.7.82
193.233.7.82 dev eth0 src 193.233.7.65 realms inr.ac cache mtu 1500 rtt 300
示例2: 搜索目的地址是193.233.7.82，來自193.233.7.82，從eth0設備到達的路由（這條命令會產生一條非常有意思的路由，這是一條到193.233.7.82的回環路由）
# ip r g 193.233.7.82 from 193.233.7.82 iif eth0
193.233.7.82 from 193.233.7.82 dev eth0 src 193.233.7.65 realms inr.ac/inr.ac
cache mtu 1500 rtt 300 iif eth0
8. ip route -- 路由策略資料庫管理命令
命令add、delete、show(或list)
注意：策略路由(policy routing)不等於路由策略(rouing policy)。
在某些情況下，我們不只是需要通過數據包的目的地址決定路由，可能還需要通過其他一些域：源地址、IP協議、傳輸層埠甚至數據包的負載。
這就叫做：策略路由(policy routing)。
8.5. ip rule add -- 插入新的規則
ip rule delete -- 刪除規則
縮寫：add、a；delete、del、d
示例1: 通過路由表inr.ruhep路由來自源地址為192.203.80/24的數據包
ip ru add from 192.203.80/24 table inr.ruhep prio 220
示例2:把源地址為193.233.7.83的數據報的源地址轉換為192.203.80.144，並通過表1進行路由
ip ru add from 193.233.7.83 nat 192.203.80.144 table 1 prio 320
示例3:刪除無用的預設規則
ip ru del prio 32767
8.7. ip rule show -- 列出路由規則
縮寫：show、list、sh、ls、l
示例1: # ip ru ls
0: from all lookup local
32762: from 192.168.4.89 lookup fddi153
32764: from 192.168.4.88 lookup fddi153
32766: from all lookup main
32767: from all lookup 253
9. ip maddress -- 多播地址管理
縮寫：show、list、sh、ls、l
9.3.ip maddress show -- 列出多播地址
示例1: # ip maddr ls mmy
9.4. ip maddress add -- 加入多播地址
ip maddress delete -- 刪除多播地址
縮寫：add、a；delete、del、d
使用這兩個命令，我們能添加／刪除在網路介面上監聽的鏈路層多播地址。這個命令只能管理鏈路層地址。
示例1: 增加 # ip maddr add 33:33:00:00:00:01 dev mmy
示例2: 查看 # ip -O maddr ls mmy
2: mmy
link 33:33:00:00:00:01 users 2 static
link 01:00:5e:00:00:01
示例3: 刪除 # ip maddr del 33:33:00:00:00:01 dev mmy
10.ip mroute -- 多播路由緩存管理
10.4. ip mroute show -- 列出多播路由緩存條目
縮寫：show、list、sh、ls、l
示例1:查看 # ip mroute ls
(193.232.127.6, 224.0.1.39) Iif: unresolved
(193.232.244.34, 224.0.1.40) Iif: unresolved
(193.233.7.65, 224.66.66.66) Iif: eth0 Oifs: pimreg
示例2:查看 # ip -s mr ls 224.66/16
(193.233.7.65, 224.66.66.66) Iif: eth0 Oifs: pimreg
9383 packets, 300256 bytes
11. ip tunnel -- 通道設置
縮寫tunnel、tunl
11.4.ip tunnel add -- 添加新的通道
ip tunnel change -- 修改現有的通道
ip tunnel delete -- 刪除一個通道
縮寫：add、a；change、chg；delete、del、d
示例1:建立一個點對點通道，最大TTL是32
# ip tunnel add Cisco mode sit remote 192.31.7.104 local 192.203.80.1 ttl 32
11.4.ip tunnel show -- 列出現有的通道
縮寫：show、list、sh、ls、l
示例1: # ip -s tunl ls Cisco
12. ip monitor和rtmon -- 狀態監視
ip命令能用於連續地監視設備、地址和路由的狀態。這個命令選項的格式有點不同，命令選項的名字叫做monitor，接著是操作對象：
ip monitor [ file FILE ] [ all | OBJECT-LIST ]
示例1: # rtmon file /var/log/rtmon.log
示例2: # ip monitor file /var/log/rtmon.log r