常用判斷網(wǎng)絡是否中斷的方法：
1.Traceroute,Tracert
traceroute命令用于追蹤數(shù)據(jù)包在網(wǎng)絡上的傳輸時的全部路徑，它默認發(fā)送的數(shù)據(jù)包大小是40字節(jié)。traceroute 的第一個作用就是故意設置特殊的 TTL，來追蹤去往目的地時沿途經(jīng)過的路由器。
它們用于顯示數(shù)據(jù)包在IP網(wǎng)絡中經(jīng)過的路由器的IP地址，是利用IP數(shù)據(jù)包的存活時間（TTL）值來實現(xiàn)其功能的。
基于UDP實現(xiàn)
在基于UDP的實現(xiàn)中，客戶端發(fā)送的數(shù)據(jù)包是通過UDP協(xié)議來傳輸?shù)?，使用了一個大于30000的端口號，服務器在收到這個數(shù)據(jù)包的時候會返回一個端口不可達的ICMP錯誤信息，客戶端通過判斷收到的錯誤信息是TTL超時還是端口不可達來判斷數(shù)據(jù)包是否到達目標主機，具體的流程如圖：
基于UDP實現(xiàn)的traceroute
客戶端發(fā)送一個TTL為1，端口號大于30000的UDP數(shù)據(jù)包，到達第一站路由器之后TTL被減去1，返回了一個超時的ICMP數(shù)據(jù)包，客戶端得到第一跳路由器的地址。
客戶端發(fā)送一個TTL為2的數(shù)據(jù)包，在第二跳的路由器節(jié)點處超時，得到第二跳路由器的地址。
客戶端發(fā)送一個TTL為3的數(shù)據(jù)包，數(shù)據(jù)包成功到達目標主機，返回一個端口不可達錯誤，traceroute結(jié)束。
Linux和macOS系統(tǒng)自帶了一個traceroute指令，可以結(jié)合Wireshark抓包來看看它的實現(xiàn)原理。首先對百度的域名進行traceroute：traceroute www.baidu.com，每一跳默認發(fā)送三個數(shù)據(jù)包，我們會看到下面這樣的輸出：
traceroute.png
對該域名的IP：115.239.210.27進行traceroute，此時Wireshark抓包的結(jié)果如下：
抓包結(jié)果
注意看紅框處的內(nèi)容，跟第一張圖對比，可以看到traceroute程序首先通過UDP協(xié)議向目標地址115.239.210.27發(fā)送了一個TTL為1的數(shù)據(jù)包，然后在第一個路由器中TTL超時，返回一個錯誤類型為Time-to-live exceeded的ICMP數(shù)據(jù)包，此時我們通過該數(shù)據(jù)包的源地址可知第一站路由器的地址為10.242.0.1。之后只需要不停增加TTL的值就能得到每一跳的地址了。
然而一直跑下去會發(fā)現(xiàn)，traceroute并不能到達目的地，當TTL增加到一定大小之后就一直拿不到返回的數(shù)據(jù)包了：
結(jié)果全是丟失
其實這個時候數(shù)據(jù)包已經(jīng)到達目標服務器了，但是因為安全問題大部分的應用服務器都不提供UDP服務（或者被防火墻擋掉），所以我們拿不到服務器的任何返回，程序就理所當然的認為還沒有結(jié)束，一直嘗試增加數(shù)據(jù)包的TTL。
目前在網(wǎng)上找到許多開源iOS traceroute實現(xiàn)大多都是基于UDP的方案，實際用起來并不能達到想要的效果，所以我們需要采用另一種方案來實現(xiàn)。
-I???? 使用ICMP ECHO進行探測。
?????? -T??? 使用TCP SYN進行探測。
?????? -U???? 使用UDP報文進行探測（默認情況）。對于無特權(quán)用戶來說，只允許使用UDP報文進行探測。
?????? -d???? 允許進行socket級別的調(diào)試（當Linux kernel支持它的時候）Enable socket level debugging (when the Linux kernel supports it)
基于ICMP實現(xiàn):Tracert
Tracert 命令用 IP 生存時間 (TTL) 字段和 ICMP 錯誤消息來確定從一個主機到網(wǎng)絡上其他主機的路由。
首先，tracert送出一個TTL是1的IP 數(shù)據(jù)包到目的地，當路徑上的第一個路由器收到這個數(shù)據(jù)包時，它將TTL減1。此時，TTL變?yōu)?，所以該路由器會將此數(shù)據(jù)包丟掉，并送回一個「ICMP time exceeded」消息（包括發(fā)IP包的源地址，IP包的所有內(nèi)容及路由器的IP地址），tracert?收到這個消息后，便知道這個路由器存在于這個路徑上，接著tracert?再送出另一個TTL是2 的數(shù)據(jù)包，發(fā)現(xiàn)第2 個路由器...... tracert?每次將送出的數(shù)據(jù)包的TTL 加1來發(fā)現(xiàn)另一個路由器，這個重復的動作一直持續(xù)到某個數(shù)據(jù)包 抵達目的地。當數(shù)據(jù)包到達目的地后，該主機則不會送回ICMP time exceeded消息，一旦到達目的地，由于tracert通過UDP數(shù)據(jù)包向不常見端口(30000以上)發(fā)送數(shù)據(jù)包，因此會收到「ICMP port unreachable」消息，故可判斷到達目的地。
上述方案失敗的原因是由于服務器對于UDP數(shù)據(jù)包的處理，所以在這一種實現(xiàn)中我們不使用UDP協(xié)議，而是直接發(fā)送一個ICMP回顯請求（echo request）數(shù)據(jù)包，服務器在收到回顯請求的時候會向客戶端發(fā)送一個ICMP回顯應答（echo reply）數(shù)據(jù)包，在這之后的流程還是跟第一種方案一樣。這樣就避免了我們的traceroute數(shù)據(jù)包被服務器的防火墻策略墻掉。
采用這種方案的實現(xiàn)流程如下：
基于ICMP實現(xiàn)的traceroute
客戶端發(fā)送一個TTL為1的ICMP請求回顯數(shù)據(jù)包，在第一跳的時候超時并返回一個ICMP超時數(shù)據(jù)包，得到第一跳的地址。
客戶端發(fā)送一個TTL為2的ICMP請求回顯數(shù)據(jù)包，得到第二跳的地址。
客戶端發(fā)送一個TTL為3的ICMP請求回顯數(shù)據(jù)包，到達目標主機，目標主機返回一個ICMP回顯應答，traceroute結(jié)束。
可以看出與第一種實現(xiàn)相比，區(qū)別主要在發(fā)送的數(shù)據(jù)包類型以及對于結(jié)束的判斷上，大體的流程還是一致的。
traceroute是檢測到目的主機路由的工具，它并不能保證從本機發(fā)出的兩個IP數(shù)據(jù)報有相同的路由。
traceroute 默認發(fā)送的是 UDP 包，而非 ICMP，可以通過 -I 參數(shù)來使 traceroute 發(fā)送 ICMP 包，另外還可以使用 -T 參數(shù)來測試 syn 握手。
另外使用 -p 參數(shù)可以指定端口，對于 UDP 而言，每進行一個 probe 端口就會在原來的基礎上加 1；而對于 ICMP 而言，可以用來初始化 icmp sequence 值，同樣的，每進行一次 probe，sequence 會加 1。
對于 TCP 而言則指定發(fā)送的端口
主要原因是traceroute的運行方式。它向第一臺主機發(fā)送TTL為1的UDP（或Windows上的ICMP）數(shù)據(jù)包，并在收到超時答復（或通過內(nèi)部超時）后，為具有TTL的下一臺主機生成下一個數(shù)據(jù)包。 2個，依此類推（以此類推（將每個主機的TTL加1）。因此，traceroute的總時間包括依次發(fā)送和接收每個主機的數(shù)據(jù)包。
mtr在確定數(shù)據(jù)包采用的路徑后，并行發(fā)送所有ICMP ECHO數(shù)據(jù)包。
簡單總結(jié)一下 linode 那邊文檔的表述，traceroute 的那篇類似。如果只是某一個節(jié)點出現(xiàn)丟包，可能是由于路由限制了 ICMP 的流量；如果是從某個點開始接下去的幾個點都出現(xiàn)不同程度的丟包，這個就可能是真正意義上的丟包了，可能是由于路由器撐不住了，或者直接把這部分包給過濾掉了，當然，由于去的包跟回來的包走的路由可能不一樣，丟包可能是發(fā)生在回來的路上。因此最好的辦法是 srs/dst 兩邊同時 mtr，不過這個一般情況下只有一方能實現(xiàn)，而另一方的控制權(quán)不在自己的手上。
盡管 TCP 有重傳機制，當丟包達到一定的程度的時候還是會影響網(wǎng)路的性能，尤其在 latency 比較大的時候，如果 latency 比較小，比如在幾ms之內(nèi)，出現(xiàn)小部分的丟包也可以接受，但是如果 latency 本身就達到了 3,400ms，再來個 10% 的丟包，效果可想而知了?；揪褪?latency 可以接受但是丟包律高就不可以接受了。
2.TCPdump
Linux抓包是通過注冊一種虛擬的底層網(wǎng)絡協(xié)議來完成對網(wǎng)絡報文(準確的說是網(wǎng)絡設備)消息的處理權(quán)。當網(wǎng)卡接收到一個網(wǎng)絡報文之后，它會遍歷系統(tǒng)中所有已經(jīng)注冊的網(wǎng)絡協(xié)議，例如以太網(wǎng)協(xié)議、x25協(xié)議處理模塊來嘗試進行報文的解析處理，這一點和一些文件系統(tǒng)的掛載相似，就是讓系統(tǒng)中所有的已經(jīng)注冊的文件系統(tǒng)來進行嘗試掛載，如果哪一個認為自己可以處理，那么就完成掛載。
當抓包模塊把自己偽裝成一個網(wǎng)絡協(xié)議的時候，系統(tǒng)在收到報文的時候就會給這個偽協(xié)議一次機會，讓它來對網(wǎng)卡收到的報文進行一次處理，此時該模塊就會趁機對報文進行窺探，也就是把這個報文完完整整的復制一份，假裝是自己接收到的報文，匯報給抓包模塊。
tcpdump采用命令行方式對接口的數(shù)據(jù)包進行篩選抓取，其豐富特性表現(xiàn)在靈活的表達式上。
tcpdump
tcpdump -i 網(wǎng)卡
tcpdump -nn 數(shù)字的方式顯示IP和端口。一個n是ip
tcpdump -c x 抓包數(shù)量，x為數(shù)字
tcpdump port xx 抓指定端口的包，xx為端口號
tcpdump tcp and port xx 指定協(xié)議和端口，xx為端口號，and可以省略不寫
tcpdump host xx.xx.xx.xx 指定來源IP或目標IP的包 xx.xx.xx.xx為IP地址。
tcpdump -w xx.txt 把抓的包寫入一個文件，xx.txt為文件名
tcpdump -s0 -w xx.txt ?抓包時防止包截斷，s0的0為數(shù)字0，抓一個完整的包必須加s0。
tcpdump -r xx.txt 用戶查看-w抓的包，xx.txt為文件名
-w抓的包實際是包的內(nèi)容，非簡單的流向。如果訪問一張圖片，用-w可以把這張圖片抓出來。只看流向的話，可以使用重定向。
tcpdump 的各種參數(shù)
option 可選參數(shù)：將在后邊一一解釋，對應本文第四節(jié)：可選參數(shù)解析
proto 類過濾器：根據(jù)協(xié)議進行過濾，可識別的關(guān)鍵詞有：upd, udp, icmp, ip, ip6, arp, rarp,ether,wlan, fddi, tr, decnet
type 類過濾器：可識別的關(guān)鍵詞有：host, net, port, portrange，這些詞后邊需要再接參數(shù)。
direction 類過濾器：根據(jù)數(shù)據(jù)流向進行過濾，可識別的關(guān)鍵字有：src, dst，同時你可以使用邏輯運算符進行組合，比如 src or dst
若你的ip范圍是一個網(wǎng)段，可以直接這樣指定：
tcpdump net192.168.10.0/24
抓取DNS端口數(shù)據(jù)
DNS 的默認端口是 53，因此可以通過端口進行過濾
$ tcpdump-i any-s0 port53
控制詳細內(nèi)容的輸出
-v：產(chǎn)生詳細的輸出. 比如包的TTL，id標識，數(shù)據(jù)包長度，以及IP包的一些選項。同時它還會打開一些附加的包完整性檢測，比如對IP或ICMP包頭部的校驗和。
-vv：產(chǎn)生比-v更詳細的輸出. 比如NFS回應包中的附加域?qū)淮蛴? SMB數(shù)據(jù)包也會被完全解碼。（摘自網(wǎng)絡，目前我還未使用過）
-vvv：產(chǎn)生比-vv更詳細的輸出。比如 telent 時所使用的SB, SE 選項將會被打印, 如果telnet同時使用的是圖形界面，其相應的圖形選項將會以16進制的方式打印出來（摘自網(wǎng)絡，目前我還未使用過）
-A：以ASCII碼方式顯示每一個數(shù)據(jù)包(不顯示鏈路層頭部信息). 在抓取包含網(wǎng)頁數(shù)據(jù)的數(shù)據(jù)包時, 可方便查看數(shù)據(jù)
-l: 基于行的輸出，便于你保存查看，或者交給其它工具分析
-q: 簡潔地打印輸出。即打印很少的協(xié)議相關(guān)信息, 從而輸出行都比較簡短.
-c: 捕獲 count 個包 tcpdump 就退出
-s:? tcpdump 默認只會截取前96字節(jié)的內(nèi)容，要想截取所有的報文內(nèi)容，可以使用-s number，number就是你要截取的報文字節(jié)數(shù)，如果是 0 的話，表示截取報文全部內(nèi)容。
-S: 使用絕對序列號，而不是相對序列號
-C：file-size，tcpdump 在把原始數(shù)據(jù)包直接保存到文件中之前, 檢查此文件大小是否超過file-size. 如果超過了, 將關(guān)閉此文件,另創(chuàng)一個文件繼續(xù)用于原始數(shù)據(jù)包的記錄. 新創(chuàng)建的文件名與-w 選項指定的文件名一致, 但文件名后多了一個數(shù)字.該數(shù)字會從1開始隨著新創(chuàng)建文件的增多而增加. file-size的單位是百萬字節(jié)(nt: 這里指1,000,000個字節(jié),并非1,048,576個字節(jié), 后者是以1024字節(jié)為1k, 1024k字節(jié)為1M計算所得, 即1M=1024 ＊ 1024 ＝ 1,048,576)
-F：使用file 文件作為過濾條件表達式的輸入, 此時命令行上的輸入將被忽略.
-D: 顯示所有可用網(wǎng)絡接口的列表
-e: 每行的打印輸出中將包括數(shù)據(jù)包的數(shù)據(jù)鏈路層頭部信息
-E: 揭秘IPSEC數(shù)據(jù)
-L：列出指定網(wǎng)絡接口所支持的數(shù)據(jù)鏈路層的類型后退出
-Z：后接用戶名，在抓包時會受到權(quán)限的限制。如果以root用戶啟動tcpdump，tcpdump將會有超級用戶權(quán)限。
-d：打印出易讀的包匹配碼
-dd：以C語言的形式打印出包匹配碼.
-ddd：以十進制數(shù)的形式打印出包匹配碼
=：判斷二者相等
==：判斷二者相等
!=：判斷二者不相等
當你使用這兩個符號時，tcpdump 還提供了一些關(guān)鍵字的接口來方便我們進行判斷，比如
if：表示網(wǎng)卡接口名、
proc：表示進程名
pid：表示進程 id
svc：表示 service class
dir：表示方向，in 和 out
eproc：表示 effective process name
epid：表示 effective process ID
提取 HTTP 請求的 URL
tcpdump-s0-v-n-l|egrep-i"POST /|GET /|Host:"
提取 HTTP 的 User-Agent
tcpdump-nn-A-s1500-l|egrep-i'User-Agent:|Host:'
找出發(fā)包數(shù)最多的 IP
tcpdump-nnn-t-c200|cut-f1,2,3,4-d'.'|sort|uniq-c|sort-nr|head-n20
cut -f 1,2,3,4 -d '.'?: 以?.?為分隔符，打印出每行的前四列。即 IP 地址。
sort | uniq -c?: 排序并計數(shù)
sort -nr?: 按照數(shù)值大小逆向排序
?提取 HTTP 請求的 URL
tcpdump-s0-v-n-l|egrep-i"POST /|GET /|Host:"
3.Ping
Ping的原理?
ping程序是用來探測主機到主機之間是否可通信，如果不能ping到某臺主機，表明不能和這臺主機建立連接。
ping使用的是ICMP協(xié)議，它發(fā)送icmp回送請求消息給目的主機。ICMP協(xié)議規(guī)定：目的主機必須返回ICMP回送應答消息給源主機。如果源主機在一定時間內(nèi)收到應答，則認為主機可達。
ICMP協(xié)議通過IP協(xié)議發(fā)送的，IP協(xié)議是一種無連接的，不可靠的數(shù)據(jù)包協(xié)議。在Unix/Linux，序列號從0開始計數(shù)，依次遞增。而Windowsping程序的ICMP序列號是沒有規(guī)律。
ICMP協(xié)議在實際傳輸中數(shù)據(jù)包：20字節(jié)IP首部 + 8字節(jié)ICMP首部+ 1472字節(jié)<數(shù)據(jù)大小>38字節(jié)????
ICMP報文格式:IP首部(20字節(jié))+8位類型+8位代碼+16位校驗和+(不同的類型和代碼，格式也有所不同)
Ping工作過程
Ping 使用ICMP協(xié)議，工作在第三層，命令在應用層
假定主機A的IP地址是192.168.1.1，主機B的IP地址是192.168.1.2，都在同一子網(wǎng)內(nèi)，則當你在主機A上運行“Ping192.168.1.2”后，都發(fā)生了些什么呢?
首先，Ping命令會構(gòu)建一個固定格式的ICMP請求數(shù)據(jù)包，然后由ICMP協(xié)議將這個數(shù)據(jù)包連同地址“192.168.1.2”一起交給IP層協(xié)議（和ICMP一樣，實際上是一組后臺運行的進程），IP層協(xié)議將以地址“192.168.1.2”作為目的地址，本機IP地址作為源地址，加上一些其他的控制信息，構(gòu)建一個IP數(shù)據(jù)包，并在一個映射表中查找出IP地址192.168.1.2所對應的物理地址（也叫MAC地址，熟悉網(wǎng)卡配置的朋友不會陌生，這是數(shù)據(jù)鏈路層協(xié)議構(gòu)建數(shù)據(jù)鏈路層的傳輸單元——幀所必需的），一并交給數(shù)據(jù)鏈路層。后者構(gòu)建一個數(shù)據(jù)幀，目的地址是IP層傳過來的物理地址，源地址則是本機的物理地址，還要附加上一些控制信息，依據(jù)以太網(wǎng)的介質(zhì)訪問規(guī)則，將它們傳送出去。其中映射表由ARP實現(xiàn)。ARP(Address Resolution Protocol)是地址解析協(xié)議,是一種將IP地址轉(zhuǎn)化成物理地址的協(xié)議。ARP具體說來就是將網(wǎng)絡層（IP層，也就是相當于OSI的第三層）地址解析為數(shù)據(jù)連接層（MAC層，也就是相當于OSI的第二層）的MAC地址。
主機B收到這個數(shù)據(jù)幀后，先檢查它的目的地址，并和本機的物理地址對比，如符合，則接收；否則丟棄。接收后檢查該數(shù)據(jù)幀，將IP數(shù)據(jù)包從幀中提取出來，交給本機的IP層協(xié)議。同樣，IP層檢查后，將有用的信息提取后交給ICMP協(xié)議，后者處理后，馬上構(gòu)建一個ICMP應答包，發(fā)送給主機A，其過程和主機A發(fā)送ICMP請求包到主機B一模一樣。即先由IP地址，在網(wǎng)絡層傳輸，然后再根據(jù)mac地址由數(shù)據(jù)鏈路層傳送到目的主機。
ICMP主要的功能包括：確認 IP 包是否成功送達目標地址、報告發(fā)送過程中 IP 包被廢棄的原因和改善網(wǎng)絡設置等。
ARP是地址解析協(xié)議，是根據(jù)IP地址獲取物理地址的一個TCP、IP協(xié)議。主機發(fā)送信息時將包含目標IP地址的ARP請求廣播到網(wǎng)絡上的所有主機，并接收返回消息，以此確定目標的物理地址。
在IP通信中如果某個IP包因為某種原因未能達到目標地址，那么這個具體的原因?qū)?b>由 ICMP 負責通知。
ICMP 目標不可達消息
如上圖例子，主機A向主機B發(fā)送了數(shù)據(jù)包，由于某種原因，途中的路由器2未能發(fā)現(xiàn)主機B的存在，這時，路由器2就會向主機A發(fā)送一個ICMP目標不可達數(shù)據(jù)包，說明發(fā)往主機B的包未能成功。
回送消息用于進行通信的主機或路由器之間，判斷所發(fā)送的數(shù)據(jù)包是否已經(jīng)成功到達對端的一種消息，ping?命令就是利用這個消息實現(xiàn)的。
IP 路由器無法將 IP 數(shù)據(jù)包發(fā)送給目標地址時，會給發(fā)送端主機返回一個目標不可達的 ICMP 消息，并在這個消息中顯示不可達的具體原因，原因記錄在 ICMP 包頭的代碼字段。
由此，根據(jù) ICMP 不可達的具體消息，發(fā)送端主機也就可以了解此次發(fā)送不可達的具體原因。
舉例 6 種常見的目標不可達類型的代碼：
附TCP/IP模型
我們重點來看?ping?的發(fā)送和接收過程。同個子網(wǎng)下的主機 A 和 主機 B，主機 A 執(zhí)行ping?主機 B 后的過程
4.MTR
mtr在單個網(wǎng)絡診斷工具中結(jié)合了traceroute和ping程序的功能。當mtr啟動時，它調(diào)查運行在主機mtr和主機名之間的網(wǎng)絡連接。traceroute默認使用UDP數(shù)據(jù)包探測，而mtr默認使用ICMP報文探測，ICMP在某些路由節(jié)點的優(yōu)先級要比其他數(shù)據(jù)包低，所以測試得到的數(shù)據(jù)可能低于實際情況。
通過發(fā)送有目的的低TTL的包。它繼續(xù)以較低的TTL發(fā)送數(shù)據(jù)包，記錄中間路由器。這允許MTR打印Internet路由的響應百分比和響應時間。到主機名。包丟失或響應時間的突然增加通常是壞的（或僅僅是過度的）跡象。已加載）鏈接。結(jié)果通常以往返響應時間（毫秒）和包丟失百分比報告。
mtr -Trwc 300 web14-tzzj.gtarcade.com
mtr -r 202.108.33.94 使用-c參數(shù)設置每秒發(fā)送數(shù)據(jù)包數(shù)量：
mtr -r -c 30 202.108.33.94 使用-s參數(shù)指定ping數(shù)據(jù)包的大?。?/p>
mtr -r -c 30 -s 1024 202.108.33.94 mtr -s 用來指定ping數(shù)據(jù)包的大小
mtr -n no-dns不對IP地址做域名解析
mtr -a 來設置發(fā)送數(shù)據(jù)包的IP地址 這個對一個主機由多個IP地址是有用的
mtr -i 使用這個參數(shù)來設置ICMP返回之間的要求默認是1秒
MTR qq.com 測試界面
具體輸出的參數(shù)含義為：
第一列是IP地址 丟包率：Loss
已發(fā)送的包數(shù)：Snt
最后一個包的延時：Last
平均延時：Avg
最低延時：Best
最差延時：Wrst
方差（穩(wěn)定性）：StDev
使用 mtr -r qq.com 來打印報告，如果不使用 -r or --report 參數(shù) mtr 會不斷動態(tài)運行。使用 report 選項， mtr 會向 qq.com 主機發(fā)送 10 個 ICMP 包，然后直接輸出結(jié)果。通常情況下 mtr 需要幾秒鐘時間來輸出報告。mtr 報告由一系列跳數(shù)組成，每一跳意味著數(shù)據(jù)包通過節(jié)點或者路由器來達到目的主機。
一般情況下 mtr 前幾跳都是本地 ISP，后幾跳屬于服務商比如 騰訊數(shù)據(jù)中心，中間跳數(shù)則是中間節(jié)點，如果發(fā)現(xiàn)前幾跳異常，需要聯(lián)系本地 ISP 服務提供上，相反如果后幾跳出現(xiàn)問題，則需要聯(lián)系服務提供商，中間幾跳出現(xiàn)問題，則需要聯(lián)系運營商進行處理
默認使用 -r 參數(shù)來生成報告，只會發(fā)送10個數(shù)據(jù)包，如果想要自定義數(shù)據(jù)包數(shù)量，可以使用 -c 參數(shù)
MTR結(jié)果分析
當我們分析 MTR 報告時候，最好找出每一跳的任何問題。除了可以查看兩個服務器之間的路徑之外，MTR 在它的七列數(shù)據(jù)中提供了很多有價值的數(shù)據(jù)統(tǒng)計報告。Loss% 列展示了數(shù)據(jù)包在每一跳的丟失率。Snt 列記錄的多少個數(shù)據(jù)包被送出。使用 –report 參數(shù)默認會送出10個數(shù)據(jù)包。如果使用 –report-cycles=[number-of-packets] 選項，MTR 就會按照 [number-of-packets] 指定的數(shù)量發(fā)出 ICMP 數(shù)據(jù)包。
Last, Avg, Best 和 Wrst 列都標識數(shù)據(jù)包往返的時間，使用的是毫秒（ ms ）單位表示。Last 表示最后一個數(shù)據(jù)包所用的時間， Avg 表示評價時間， Best 和 Wrst 表示最小和最大時間。在大多數(shù)情況下，平均時間（ Avg）列需要我們特別注意。
最后一列 StDev 提供了數(shù)據(jù)包在每個主機的標準偏差。如果標準偏差越高，說明數(shù)據(jù)包在這個節(jié)點的延時越不相同。標準偏差會讓您了解到平均延時是否是真的延時時間的中心點，或者測量數(shù)據(jù)受到某些問題的干擾。
例如，如果標準偏差很大，說明數(shù)據(jù)包的延遲是不確定的。一些數(shù)據(jù)包延遲很?。ɡ纾?5ms），另一些數(shù)據(jù)包延遲很大（例如：350ms）。當10個數(shù)據(jù)包全部發(fā)出后，得到的平均延遲可能是正常的，但是平均延遲是不能很好的反應實際情況的。如果標準偏差很高，使用最好和最壞的延遲來確定平均延遲是一個較好的方案。
在大多數(shù)情況下，您可以把 MTR 的輸出分成三大塊。根據(jù)配置，第二或第三跳一般都是您的本地 ISP，倒數(shù)第二或第三跳一般為您目的主機的ISP。中間的節(jié)點是數(shù)據(jù)包經(jīng)過的路由器。
當分析 MTR 的輸出時，您需要注意兩點：loss 和 latency。
網(wǎng)絡丟包
如果在任何一跳上看到 loss 的百分比，這就說明這一跳上可能有問題了。當然，很多服務提供商人為限制 ICMP 發(fā)送的速率，這也會導致此問題。那么如何才能指定是人為的限制 ICMP 傳輸 還是確定有丟包的現(xiàn)象？此時需要查看下一跳。如果下一跳沒有丟包現(xiàn)象，說明上一條是人為限制的。如下示例：
MTR丟包截圖
從下面的圖中，您可以看從第14跳和第17跳都有 10% 的丟包率，從接下來的幾跳都有丟包現(xiàn)象，但是最后15,16跳都是100%的丟包率，我們可以猜測到100%的丟包率除了網(wǎng)絡糟糕的原因之前還有人為限制 ICMP。所以，當我們看到不同的丟包率時，通常要以最后幾跳為準。
還有很多時候問題是在數(shù)據(jù)包返回途中發(fā)生的。數(shù)據(jù)包可以成功的到達目的主機，但是返回過程中遇到“困難”了。所以，當問題發(fā)生后，我們通常需要收集反方向的 MTR 報告。
此外，互聯(lián)網(wǎng)設施的維護或短暫的網(wǎng)絡擁擠可能會帶來短暫的丟包率，當出現(xiàn)短暫的10%丟包率時候，不必擔心，應用層的程序會彌補這點損失。
網(wǎng)絡延遲
除了可以通過MTR報告查看丟包率，我們也還可以看到本地到目的之間的時延。因為是不通的位置，延遲通常會隨著條數(shù)的增加而增加。所以，延遲通常取決于節(jié)點之間的物理距離和線路質(zhì)量。
從上面的MTR報告截圖中，我們可以看到從第11跳到12跳的延遲猛增，直接導致了后面的延遲也很大，一般有可能是11跳到12跳屬于不通地域，物理距離導致時延猛增，也有可能是第12條的路由器配置不當，或者是線路擁塞。需要具體問題進行具體的分析。
然而，高延遲并不一定意味著當前路由器有問題。延遲很大的原因也有可能是在返回過程中引發(fā)的。從這份報告的截圖看不到返回的路徑，返回的路徑可能是完全不同的線路，所以一般需要進行雙向MTR測試。
注：ICMP 速率限制也可能會增加延遲，但是一般可以查看最后一條的時間延遲來判斷是否是上述情況。
根據(jù)MTR結(jié)果解決網(wǎng)絡問題
MTR 報告顯示的路由問題大都是暫時性的。很多問題在24小時內(nèi)都被解決了。大多數(shù)情況下，如果您發(fā)現(xiàn)了路由問題，ISP 提供商已經(jīng)監(jiān)視到并且正在解決中了。當您經(jīng)歷網(wǎng)絡問題后，可以選擇提醒您的 ISP 提供商。當聯(lián)系您的提供商時，需要發(fā)送一下 MTR 報告和相關(guān)的數(shù)據(jù)。沒有有用的數(shù)據(jù)，提供商是沒有辦法去解決問題的。
然而大多數(shù)情況下，路由問題是比較少見的。比較常見的是因為物理距離太長，或者上網(wǎng)高峰，導致網(wǎng)絡變的很慢。尤其是跨越大西洋和太平洋的時候，網(wǎng)絡有時候會變的很慢。這種情況下，建議就近接入客戶的節(jié)點。
5.DIG
dig?最基本的功能就是查詢域名信息，因此它的名稱實際上是“?域名信息查詢工具(Domain Information Groper)”的縮寫。dig?向用戶返回的內(nèi)容可以非常詳盡，也可以非常簡潔，展現(xiàn)內(nèi)容的多少完全由用戶在查詢時使用的選項來決定。
在查詢的時候發(fā)現(xiàn)有的域名會指向多個 IP 地址？這其實是網(wǎng)站提高其可用性的一種措施。
查詢過程
雖然只需要返回一個IP地址，但是DNS的查詢過程非常復雜，分成多個步驟。
工具軟件dig可以顯示整個查詢過程。
$ dig math.stackexchange.com
上面的命令會輸出六段信息。
第一段是查詢參數(shù)和統(tǒng)計。
第二段是查詢內(nèi)容。
上面結(jié)果表示，查詢域名math.stackexchange.com的A記錄，A是address的縮寫。
第三段是DNS服務器的答復。
上面結(jié)果顯示，math.stackexchange.com 有四個A記錄，即四個IP地址。600是TTL值（Time to live 的縮寫），表示緩存時間，即600秒之內(nèi)不用重新查詢。
第四段顯示stackexchange.com的NS記錄（Name Server的縮寫），即哪些服務器負責管理stackexchange.com的DNS記錄。
上面結(jié)果顯示stackexchange.com共有四條NS記錄，即四個域名服務器，向其中任一臺查詢就能知道m(xù)ath.stackexchange.com的IP地址是什么。
第五段是上面四個域名服務器的IP地址，這是隨著前一段一起返回的。
第六段是DNS服務器的一些傳輸信息。
上面結(jié)果顯示，本機的DNS服務器是192.168.1.253，查詢端口是53（DNS服務器的默認端口），以及回應長度是305字節(jié)。
# 分級查詢的實例
dig命令的+trace參數(shù)可以顯示DNS的整個分級查詢過程。
$ dig +trace math.stackexchange.com
上面命令的第一段列出根域名.的所有NS記錄，即所有根域名服務器。
根據(jù)內(nèi)置的根域名服務器IP地址，DNS服務器向所有這些IP地址發(fā)出查詢請求，詢問math.stackexchange.com的頂級域名服務器com.的NS記錄。最先回復的根域名服務器將被緩存，以后只向這臺服務器發(fā)請求。
接著是第二段。
上面結(jié)果顯示.com域名的13條NS記錄，同時返回的還有每一條記錄對應的IP地址。
然后，DNS服務器向這些頂級域名服務器發(fā)出查詢請求，詢問math.stackexchange.com的次級域名stackexchange.com的NS記錄。
上面結(jié)果顯示stackexchange.com有四條NS記錄，同時返回的還有每一條NS記錄對應的IP地址。
然后，DNS服務器向上面這四臺NS服務器查詢math.stackexchange.com的主機名。
上面結(jié)果顯示，math.stackexchange.com有4條A記錄，即這四個IP地址都可以訪問到網(wǎng)站。并且還顯示，最先返回結(jié)果的NS服務器是ns-463.awsdns-57.com，IP地址為205.251.193.207。
# NS 記錄的查詢
$ dig ns com
$ dig ns stackexchange.com
+short參數(shù)可以顯示簡化的結(jié)果。
$ dig +short ns com $ dig +short ns stackexchange.com
1. $ dig networkworld.com +short
151.101.2.165
151.101.66.165
151.101.130.165
151.101.194.165
2. dig @serverip 指定dns服務器進行解析
[root@basic harbor]# dig @8.8.8.8 www.mikezhu.tech
; <<>> DiG 9.9.4-RedHat-9.9.4-74.el7_6.2 <<>> @8.8.8.8 www.mikezhu.tech
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57221
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.mikezhu.tech. IN A
;; ANSWER SECTION:
www.mikezhu.tech. 599 IN A 192.168.137.10
;; Query time: 87 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Aug 05 10:41:48 CST 2019
;; MSG SIZE rcvd: 61
3.?直接dig域名，根據(jù)自身網(wǎng)絡的dns獲取域名解析信息
root@basic harbor]# dig www.mikezhu.tech
; <<>> DiG 9.9.4-RedHat-9.9.4-74.el7_6.2 <<>> www.mikezhu.tech
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33969
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.mikezhu.tech. IN A
;; ANSWER SECTION:
www.mikezhu.tech. 600 IN A 192.168.137.10
;; Query time: 347 msec
;; SERVER: 202.96.209.133#53(202.96.209.133)
;; WHEN: Mon Aug 05 10:39:59 CST 2019
;; MSG SIZE rcvd: 61
批量查詢域名
如果你要查詢多個域名，可以把這些域名寫入到一個文件內(nèi)（domains），然后使用下面的?dig?命令遍歷整個文件并給出所有查詢結(jié)果。
$ dig +noall +answer -f domains
networkworld.com.? ? ? 300? ? IN? ? ? A? ? ? 151.101.66.165
networkworld.com.? ? ? 300? ? IN? ? ? A? ? ? 151.101.2.165
networkworld.com.? ? ? 300? ? IN? ? ? A? ? ? 151.101.130.165
networkworld.com.? ? ? 300? ? IN? ? ? A? ? ? 151.101.194.165
world.std.com.? ? ? ? ? 77972? IN? ? ? A? ? ? 192.74.137.5
uushenandoah.org.? ? ? 1982? ? IN? ? ? A? ? ? 162.241.24.209
amazon.com.? ? ? ? ? ? 18? ? ? IN? ? ? A? ? ? 176.32.103.205
amazon.com.? ? ? ? ? ? 18? ? ? IN? ? ? A? ? ? 176.32.98.166
amazon.com.? ? ? ? ? ? 18? ? ? IN? ? ? A? ? ? 205.251.242.103
Command Test for SNI,Normally used the first one
(1) openssl s_client -servername?www.lizhou.fun?-connect lizhou.fun:443
(2) openssl s_client -connect 69.164.193.227:443 -tls1
(3) openssl s_client -connect?www.lizhou.fun:443?| openssl x509 -noout -text | grep DNS
(4) openssl s_client -connect 69.164.193.227:443 -servername?www.lizhou.fun?-tls1 (Specify the hostname)
什么是SNI協(xié)議？
服務器名稱指示（英語：Server Name Indication，簡稱SNI）是一個擴展的TLS計算機聯(lián)網(wǎng)協(xié)議，在該協(xié)議下，在握手過程開始時通過客戶端告訴它正在連接的服務器的主機名稱。這允許服務器在相同的IP地址和TCP端口號上呈現(xiàn)多個證書，因此允許在相同的IP地址上提供多個安全HTTPS網(wǎng)站（或其他任何基于TLS的服務），而不需要所有這些站點使用相同的證書
為什么需要使用SNI協(xié)議？
基于名稱的虛擬主機允許多個DNS主機名由同一IP地址上的單個服務器（通常為Web服務器）托管。為了實現(xiàn)這一點，服務器使用客戶端提供的主機名作為協(xié)議的一部分（對于HTTP，名稱顯示在主機頭中）。但是，當使用HTTPS時，TLS握手發(fā)生在服務器看到任何HTTP頭之前。因此，服務器不可能使用HTTP主機頭中的信息來決定呈現(xiàn)哪個證書，并且因此只有由同一證書覆蓋的名稱才能由同一IP地址提供。
了解SNI協(xié)議可以用來做什么？
如果我們要對流量進行識別，做流量檢測等，HTTPS流量是加密的，很難檢測其內(nèi)部的具體內(nèi)容。SNI協(xié)議給出了一個切入點，在HTTPS協(xié)議建立加密連接的開始階段檢測出訪問的域名信息
常規(guī)TLS/SSL握手失敗
TLS/SSL版本不匹配
自從TLS 1.2版本在2008年發(fā)布以來，絕大部分HTTPS流量都跑在TLS 1.2上。服務器處于安全性考慮通常也只支持較高版本TLS，比如TLS1.0及以上。但是仍然有一些版本比較舊的操作系統(tǒng)和瀏覽器存在，如果這些客戶端用低版本TLS/SSL向服務器發(fā)起握手，會因為服務器不支持而直接失敗。
比如淘寶網(wǎng)只支持TLS 1.0及以上版本，用openssl發(fā)起SSL 3版本的握手，就會出現(xiàn)handshake failure。
# openssl s_client -connect www.taobao.com:443 -ssl3 -msg
140191222585232:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1493:SSL alert number 40
140191222585232:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:659:
no peer certificate available
No client certificate CA names sent
TLS/SSL cipher suite不匹配
在握手的前兩個ClientHello和ServerHello包中有一個重要的任務就是協(xié)商cipher。客戶端在ClientHello中會帶上所有支持的cipher suite, 服務器在收到ClientHello中的cipher suite后，會和自己支持的cipher suite一一匹配，如果沒有可以匹配的就會握手失敗。
服務器出于安全性考慮通常只會支持安全性較高的cipher，所以當客戶端發(fā)過去的cipher suite安全性都比較低時會造成握手失敗。
例如用openssl向淘寶網(wǎng)發(fā)起握手，客戶端的ClientHello中只有一個安全性較低的DHE-RSA-AES128-SHA256 cipher，會出現(xiàn)handshake failure。
openssl s_client -connect www.taobao.com:443 -cipher DHE-RSA-AES128-SHA256 -msg
139737777813392:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:no peer certificate available，No client certificate CA names sent
TLS/SSL握手Warning
在握手過程中，客戶端對服務器證書會做驗證，驗證不過時會出現(xiàn)Warning。瀏覽器可以選擇忽略，用curl也可以使用-k參數(shù)來忽略。嚴格來說并不算Failure，這里歸類成Warning，不做詳細討論。例如如下幾種比較常見的情況：
訪問的域名不在服務器證書的CN(Common Name)和SAN(Subject Alternative Name)中。服務器證書被吊銷，導致驗證不通過。
現(xiàn)象如下是一個例子。客戶端訪問阿里云的一個公網(wǎng)IP地址TLS/SSL握手失敗。先來看下現(xiàn)象，在客戶端的抓包如下
可以看到前面的TCP三次握手和一些數(shù)據(jù)交互(特定協(xié)議相關(guān)，正常情況在TCP三次握手后直接開始TLS/SSL握手)都沒有問題。但是開始TLS/SSL握手交互過程客戶端發(fā)出第一個報文，馬上收到一個TCP RESET。這個和上面提到的常規(guī)握手失敗很不一樣， TCP RESET報文通常是設備或者主機協(xié)議棧主動發(fā)出，符合一定場景或者有一定網(wǎng)絡管理含義。
根本原因
云盾根據(jù)訪問的目的域名有沒有備案做執(zhí)行相關(guān)動作。云盾并沒有在TCP建連時就針對源目IP做阻斷，而是提取ClientHello中的SNI(Servername Indication)域名信息判斷是否備案而做阻斷，返回TCP RESET。
SNI是ClientHello中的一個擴展字段，帶有要訪問的目標域名，讓同一個IP上托管多個HTTPS站點的服務器知道客戶端訪問的是哪個目標域名，以便使用對應的證書進行交互。在ClientHello報文的如下位置
客戶端證書問題導致TLS/SSL握手失敗
在雙向驗證的場景中，不僅僅客戶端要驗證服務器證書，服務器也需要驗證客戶端證書。在服務器驗證客戶端證書的過程中，由于客戶端證書的安全性較低，可能會直接產(chǎn)生Fatal Alert，導致握手直接中斷。
現(xiàn)象
如下是一個手機App訪問服務器的例子。72號報文報出了Bad Certificate的Fatal Alert，從上下文看，這里是客戶端向服務器端發(fā)送完Certificate, Client Key Exchange等消息后，服務器返回給客戶端的報錯。
在手機App中的報錯如下：
SSL handshake aborted: ssl=0x7c1bbf6e88: Failure in SSL library, usually a protocol error
error:10000412:SSL routines:OPENSSL_internal:SSLV3_ALERT_BAD_CERTIFICATE (external/boringssl/src/ssl/http://tls_record.cc:592?0x7c6c627e48:0x00000001)
無法提取SNI導致TLS/SSL握手失敗
在某些場景中，需要獲取ClientHello中的SNI字段來作為一個必要條件, 比如用NGINX stream對HTTPS流量做4層代理時?？蛻舳薈lientHello中沒有攜帶SNI，則會造成一個通過代理握手失敗的局面。
現(xiàn)象
和上面?zhèn)€握手失敗的現(xiàn)象如出一轍，在客戶端發(fā)出ClientHello后，馬上被代理服務器FIN掉，唯一不同的是這里的ClientHello并沒有帶上SNI字段。
根本原因
在利用NGINX stream做正向代理時，NGXIN服務器需要獲取客戶端想要訪問的目的域名。利用ngx_stream_ssl_preread_module模塊在不解密的情況下拿到ClientHello報文中SNI才能實現(xiàn)代理的正常功能。
6. iperf使用方法
Iperf是一個網(wǎng)絡性能測試工具。Iperf可以測試TCP和UDP帶寬質(zhì)量。Iperf可以測量最大TCP帶寬，具有多種參數(shù)和UDP特性。Iperf可以報告帶寬，延遲抖動和數(shù)據(jù)包丟失。利用Iperf這一特性，可以用來測試一些網(wǎng)絡設備如路由器，防火墻，交換機等的性能。
Iperf的主要功能如下：
測量網(wǎng)絡帶寬,報告MSS/MTU值的大小和觀測值,支持TCP窗口值通過套接字緩沖
當P線程或Win32線程可用時，支持多線程?？蛻舳伺c服務端支持同時多重連接
客戶端可以創(chuàng)建指定帶寬的UDP流,測量丟包,測量延遲,支持多播
當線程可用時，支持多線程?？蛻舳伺c服務端支持同時多重連接（不支持Windows）
?iperf如何使用
4.1 TCP性能測試
服務器端命令：iperf3 -s
客戶端命令：iperf3 -c 192.168.1.5 -b 200M
測試結(jié)果：
從圖中可以看出測試的吞吐量、丟包率等參數(shù)。
服務器端：
iperf -s
客戶端：
iperf -c 192.168.1.1 -t 60
在tcp模式下，客戶端到服務器192.168.1.1上傳帶寬測試，測試時間60秒。
iperf -c 192.168.1.1 -P 30 -t 60
客戶端同時向服務器端發(fā)起30個連接線程。
iperf -c 192.168.1.1 -d -t 60
進行上下行帶寬測試。
4.2 UDP性能測試
帶寬測試通常采用UDP模式，因為能測出極限帶寬、時延抖動、丟包率。在進行測試時
step1：以鏈路理論帶寬作為數(shù)據(jù)發(fā)送速率進行測試，例如，從客戶端到服務器之間的鏈路的理論帶寬為100Mbps，先用-b 100M進行測試
step2：根據(jù)測試結(jié)果（包括實際帶寬，時延抖動和丟包率），再以實際帶寬作為數(shù)據(jù)發(fā)送速率進行測試，會發(fā)現(xiàn)時延抖動和丟包率比第一次好很多，重復測試幾次，就能得出穩(wěn)定的實際帶寬。
服務端命令：iperf3 -s
客戶端命令：iperf3 -u -c 192.168.1.5 -b 200M
測試結(jié)果：
從測試結(jié)果可以看出吞吐量Bitrate、抖動jitter、丟包率
UDP模式
服務器端：
iperf -u -s
客戶端：
iperf -u -c 192.168.1.1 -b 100M -t 60
在UDP模式下，以100Mbps為數(shù)據(jù)發(fā)生速率，客戶端到服務器192.168.1.1上傳帶寬測試，測試時間為60s
iperf -u -c 192.168.1.1 -b 50M -P 30 -t 60
客戶端同時向服務器端發(fā)起30個連接線程，以5Mbps為數(shù)據(jù)發(fā)生速率
iperf -u -c 192,168.1.1 -b 100M -d -t 60
以100M為數(shù)據(jù)發(fā)生速率，進行上下行帶寬測試。
7. SS命令
ss是Socket?Statistics的縮寫。顧名思義，ss命令可以用來獲取socket統(tǒng)計信息，它可以顯示和netstat類似的內(nèi)容。但ss的優(yōu)勢在于它能夠顯示更多更詳細的有關(guān)TCP和連接狀態(tài)的信息，而且比netstat更快速更高效。
當服務器的socket連接數(shù)量變得非常大時，無論是使用netstat命令還是直接cat?/proc/net/tcp，執(zhí)行速度都會很慢。可能你不會有切身的感受，但請相信我，當服務器維持的連接達到上萬個的時候，使用netstat等于浪費?生命，而用ss才是節(jié)省時間。
天下武功唯快不破。ss快的秘訣在于，它利用到了TCP協(xié)議棧中tcp_diag。tcp_diag是一個用于分析統(tǒng)計的模塊，可以獲得Linux?內(nèi)核中第一手的信息，這就確保了ss的快捷高效。當然，如果你的系統(tǒng)中沒有tcp_diag，ss也可以正常運行，只是效率會變得稍慢。（但仍然比?netstat要快。）
ss(Socket?Statistics的縮寫)命令可以用來獲取?socket統(tǒng)計信息，此命令輸出的結(jié)果類似于?netstat輸出的內(nèi)容，但它能顯示更多更詳細的?TCP連接狀態(tài)的信息，且比?netstat?更快速高效。它使用了?TCP協(xié)議棧中?tcp_diag（是一個用于分析統(tǒng)計的模塊），能直接從獲得第一手內(nèi)核信息，這就使得?ss命令快捷高效。在沒有?tcp_diag，ss也可以正常運行。
[root@localhost?~]#?ss?-t?-aState??????Recv-Q?Send-Q????????????????????????????????Local?Address:Port????????????????????????????????????Peer?Address:Port???
LISTEN?????0??????0?????????????????????????????????????????127.0.0.1:smux???????????????????????????????????????????????*:*???????
LISTEN?????0??????0?????????????????????????????????????????????????*:3690???????????????????????????????????????????????*:*???????
LISTEN?????0??????0?????????????????????????????????????????????????*:ssh????????????????????????????????????????????????*:*???????
ESTAB??????0??????0???????????????????????????????????192.168.120.204:ssh????????????????????????????????????????10.2.0.68:49368???
8. NC命令
nc的作用
（1）實現(xiàn)任意TCP/UDP端口的偵聽，nc可以作為server以TCP或UDP方式偵聽指定端口
（2）端口的掃描，nc可以作為client發(fā)起TCP或UDP連接
（3）機器之間傳輸文件
（4）機器之間網(wǎng)絡測速 ?
nc的控制參數(shù)不少，常用的幾個參數(shù)如下所列：
1) -l 用于指定nc將處于偵聽模式。指定該參數(shù)，則意味著nc被當作server，偵聽并接受連接，而非向其它地址發(fā)起連接。
2) -p <port> 暫未用到（老版本的nc可能需要在端口號前加-p參數(shù)，下面測試環(huán)境是centos6.6，nc版本是nc-1.84，未用到-p參數(shù)）
3) -s 指定發(fā)送數(shù)據(jù)的源IP地址，適用于多網(wǎng)卡機?
4) -u? 指定nc使用UDP協(xié)議，默認為TCP
5) -v 輸出交互或出錯信息，新手調(diào)試時尤為有用
6）-w 超時秒數(shù)，后面跟數(shù)字?
7）-z 表示zero，表示掃描時不發(fā)送任何數(shù)據(jù)
nc用法1，網(wǎng)絡連通性測試和端口掃描
nc可以作為server端啟動一個tcp的監(jiān)聽（注意，此處重點是起tcp，下面還會講udp）
nc -l 9999
nc作為server端啟動一個udp的監(jiān)聽（注意，此處重點是起udp，上面主要講了tcp）
啟動一個udp的端口監(jiān)聽
nc ?-ul ?9998
9. Shell 三劍客
awk：AWK一次處理是一行, 而一次中處理的最小單位是一個區(qū)域
sed: (關(guān)鍵字: 編輯) 以行為單位的文本編輯工具
grep: (關(guān)鍵字: 截取) 文本搜集工具, 結(jié)合正則表達式非常強大
grep
是一種強大的文本搜索工具，它能使用正則表達式搜索文本，并把匹配的行打印出來
sed
sed 是一種在線編輯器，它一次處理一行內(nèi)容 。處理時，把當前處理的行存儲在臨時緩沖區(qū)中，稱為“模式空間”（pattern space），接著用sed命令處理緩沖區(qū)中的內(nèi)容，處理完成后，把緩沖區(qū)的內(nèi)容送往屏幕。接著處理下一行，這樣不斷重復，直到文件末尾。文件內(nèi)容并沒有 改變，除非你使用重定向存儲輸出。
awk
相較于sed 常常作用于一整個行的處理，awk 則比較傾向于一行當中分成數(shù)個『字段』來處理。 因此，awk 相當?shù)倪m合處理小型的數(shù)據(jù)數(shù)據(jù)處理
grep（文本生成器）
grep是一種強大的文本搜索工具，他能使用正則表達式搜索文本，并把匹配的行統(tǒng)計出來
命令：grep [選項] [–color=auto] ”搜索字符串” filename
輸出匹配行的前后N行（會包括匹配行）
使用-A參數(shù)輸出匹配行的后一行：grep -A 1 “huangxiaoming” grep.txt
使用-B參數(shù)輸出匹配行的前一行：grep -B 1 “huangxiaoming” grep.txt
使用-C參數(shù)輸出匹配行的前后各一行：grep -C 1 “huangxiaoming” grep.txt
sed（流編輯器）
sed叫做流編輯器，在shell腳本和Makefile中作為過濾一使用非常普遍，也就是把前一個程序的輸出引入sed的輸入，經(jīng)過一系列編輯命令轉(zhuǎn)換成為另一種格式輸出。sed是一種在線編輯器，它一次處理一行內(nèi)容，處理時，把當前處理的行存儲在臨時緩沖區(qū)中，稱為"模式空間",接著用sed命令處理緩沖區(qū)中的內(nèi)容，處理完成后，把緩沖區(qū)的內(nèi)容送往屏幕。接著處理下一行，這樣不斷重復，直到文件末尾。文件內(nèi)容并沒有改變，除非你使用重定向存儲輸出。
sed 's/hello/hi/2' sed.txt
##? 此種寫法表示只替換每行的第2個hello為hi
sed 's/hello/hi/2g' sed.txt
##? 此種寫法表示只替換每行的第2個以后的hello為hi（包括第2個
awk（報表生成器）
Awk是一個強大的處理文本的編程語言工具，其名稱得自于它的創(chuàng)始人Alfred Aho、Peter Weinberger和Brian Kernighan 姓氏的首個字母，相對于grep的查找，sed的編輯，awk在其對數(shù)據(jù)分析并生成報告時，顯得尤為強大。AWK 提供了極其強大的功能：可以進行樣式裝入、流控制、數(shù)學運算符、進程控制語句甚至于內(nèi)置的變量和函數(shù)。簡單來說awk就是掃描文件中的每一行，查找與命令行中所給定內(nèi)容相匹配的模式。如果發(fā)現(xiàn)匹配內(nèi)容，則進行下一個編程步驟。如果找不到匹配內(nèi)容，則繼續(xù)處理下一行
[root@localhost ~]# last -n 5 | awk '{print $1}'
root
reboot
root
root
root
awk工作流程是這樣的：讀入有’\n’換行符分割的一條記錄，然后將記錄按指定的域分隔符劃分域，填充域，$0則表示所有域,1表示第一個域,1表示第一個域,1表示第一個域,n表示第n個域。默認域分隔符是"空白鍵" 或 “[tab]鍵”,所以$1表示登錄用戶，$3表示登錄用戶ip,以此類推
