網絡基礎

本文對工程網絡中的知識點作下總結，基本都是用到的。真實的網絡搭建：https://segmentfault.com/a/11...，二層主要有個VLAN，公司部署網絡基本都是這個。三層主要是路由協議。還介紹了些常見的應用協議。最後介紹了些網絡調式工具。

二層

交換機：硬件，快，端口多。二層/三層（多用於LAN）
數據鏈路地址的目的是在同一網絡中將數據鏈路幀從一個網絡接口發送至另外一個網絡接口,MAC地址是物理植入網卡的48比特意址（路由器也有mac地址）

ARP(根據IP地址獲取mac地址,將ARP請求幀廣播到本地網絡上的全部主機),LAN交換機MAC地址表的動態更新：交換機學習「源地址」(記錄來源端口和mac地址)，基於「目的地址」轉發，沒有在表中找到目的MAC地址，交換機會轉發到除了進入端口之外的全部端口泛洪（flooding）

VLAN

爲什麼要劃分VLAN？防止廣播flooding擴散，廣播只在VLAN上
交換機端口類型：
1.正常只有內部可通訊，accesslink 能夠根據端口固定劃分VLAN，能夠根據mac,ip動態劃分
2.同一VLAN誇交換機：匯聚link。（只對鏈接同一VLAN轉發，同一交換機找不到纔到另外一個）
跨VLAN：三層交換機/路由
對個應公司網絡架構：核心交換機是三層，接入層是二層，中間其實還有個匯聚層能夠作防火牆等

三層

• 路由：軟件實現，功能更多，安全認證等，端口少。三層高
  協議：mac+ip
  轉發過程：PC1經過將本身的IPv4地址與子網掩碼作與操做，來判斷PC 1所屬的網段。接下來，PC 1對目的IPv4地址與PC 1的子網掩碼作一樣的與操做。若是目的網絡地址與PC 1網絡相同，則PC 1不使用默認網關，而是在ARP緩存中查找目的IPv4地址的設備MAC地址。若是MAC地址不在緩存中，則PC 1產生一個ARP請求來獲取地址並將報文發給目的地址。若是目的網絡地址位於另外一網絡，則PC1將報文轉發至默認網關，默認網關的MAC地址同上。
  根據得到路由的方式能夠將其分爲靜態路由和動態路由，靜態路由就是管理員靜態配置的路由，動態路由則是路由器經過算法動態地學習和調整而獲得的路由。而常說的路由協議就是指這些動態路由的學習算法，根據其做用域的不一樣，又可分爲內部網管協議(IGP)和邊界網絡協議(BGP)；內部網絡協議包括RIP，OSPF等。這幾類路由協議，小規模私有網絡IGP(OSPF)，大規模私有網絡IBGP，互聯網EBGP
• IP地址：
  在不考慮子網的狀況下，ip地址分類：
  A，最高位必須是0，由1字節的網絡地址和3字節主機地址組成（數字0和 127不做爲A類地址，數字127保留給內部回送函數，而數字0則表示該地址是本地宿主機，不能傳送，0.0.0.0~126.255.255.255），
  B:最高位10，由2個字節的網絡地址和2個字節的主機（128.0.0.0~191.255.255.255），
  C：110，3字節的網絡地址和1字節的主機地址（192.0.0.0~223.255.255.255），
  D：1110用於廣播，
  E:11110保留
  在IP地址3種主要類型裏，各保留了3個區域做爲私有地址（內網），其地址範圍以下：
  A類地址：10.0.0.0～10.255.255.255
  B類地址：172.16.0.0～172.31.255.255
  C類地址：192.168.0.0～192.168.255.255
  IP地址由此被分爲三個部分：網絡ID，子網ID與主機ID（這兩部分共同爲原來的主機地址），根據子網掩碼來判斷子網ID與主機ID，
  假設將B類網絡154.71.0.0劃分5位爲子網ID，11位爲主機ID。所以，子網掩碼有16個1表明網絡部分（B類網絡），接下來5個1做爲子網部分，11個0用做主機ID。二進制數表示爲11111111 11111111 11111000 00000000，十進制數表示爲255.255.248.0，新的表達法爲154.71.150.42/21。IP地址和子網掩碼作與操做獲取子網地址，以便路由器找到網絡。21意思是子網掩碼爲21個1後面0，即255.255.248.0

協議

路由相關

• RIP
  典型DV(Distance Vector,距離矢量，基於跳數，UDP之上)協議，其工做原理以下：
  若是更新的某路由表項在路由表中沒有，則直接在路由表中添加該路由表項
  若是路由表中已有相同目的網絡的路由表項，且來源端口相同，那麼無條件根據最新的路由信息更新其路由表（不收斂問題，限制最大跳數16超過刪除鏈路或水平分割更新）
  若是路由表中已有相同目的網絡的路由表項，但來源端口不一樣，則要比較它們的度量值，將度量值較小的一個做爲本身的路由表項
  若是路由表中已有相同目的網絡的路由表項，且度量值相等，保留原來的路由表項
• 等價路由協議ecmp
  若是使用傳統的路由技術，發往該目的地址的數據包只能利用其中的一條鏈路，其它鏈路處於備份狀態或無效狀態，而且在動態路由環境下相互的切換須要必定的時間，而等價多路徑路由協議能夠在該網絡環境下同時使用多條鏈路，不只增長了傳輸帶寬，而且能夠無時延無丟包地備份失效鏈路的數據傳輸。對等價的評估很重要，路由器兩個出口，兩路徑，一個帶寬是100M，一個是2M，若是部署是ECMP，則網絡總帶寬只能達到4M的利用率。
• BGP
  網絡過大的時候，也會致使路由表過大而難以維護，這時候採用分治的方法，將一個大網絡劃分爲若干個小網絡，這些小網絡稱爲自治系統(AS)，BGP的誕生就是用於自治系統間的通訊。每一個記錄全部路徑。能夠經過下發BGP配置實現誇運營商路由，http://wulc.me/2016/12/25/計...
• EBGP
• OSPF
  典型的LS(Link State,鏈路狀態)協議，其思想是經過鄰居的LSA(Link-state advertisement, 鏈路轉態通告)構建整個網絡的拓撲（DR負責創建拓撲，與全部節點創建關係[並不必定直連]，BDR爲其備份，變化時通知DR,DR廣播）,全部路由複製拓撲，並構建以本身爲根節點的最小生成樹，而後經過dijkstra 計算最短路徑，並根據最短路徑修改路由表，基於帶寬等綜合比較，相同權值負載平衡分配。
  1.創建路由器毗鄰關係
  2.選舉DR和BDR
  3.發現路由
  4.選擇最佳路由（最小生成樹）
  5.維護路由信息
  
• anycast
  訪問該地址的報文能夠被IP網絡路由到這一組目標中的任何一臺主機上，它提供的是一種無狀態的、盡力而爲的服務。使用Anycast中的共享單播地址不能做爲客戶端發起請求，由於請求的響應不必定能返回到發起的Anycast單播地址。所以，目前Anycast僅適合一些特定的上層協議，從目前的實際應用來看， Anycast最普遍的應用是DNS的部署。一般使用Anycast的共享單播地址擁有獨立的自治域號，並經過BGP協議與不一樣自治域網絡交換路由，即IP Anycast＋BGP。
• DHCP
  動態主機設置協議， 給內部網絡或網絡服務供應商自動分配IP地址。DHCP從一個IP地址池中提供IP地址，基於UDP協議。配置使用DHCP的客戶端第一次初始化TCP/IP，會廣播一條IP Request,
  
• NAT
  靜態NAT：此類NAT在本地和全局地址之間作一到一的永久映射。須注意靜態NAT要求用戶對每一臺主機都有一個真實的Internet IP地址。 ip nat inside source static 10.1.1.1 170.46.2.2
  動態NAT：容許用戶將一個未登記的IP地址映射到一個登記的IP地址池中的一個。採用動態分配的方法將外部合法地址映射到內部網絡，無需像靜態NAT那樣，經過對路由器進行靜態配置來將內部地址映射到外部地址，可是必須有足夠的真正的IP地址來進行收發包。必定要檢查池中確保有足夠地址提供轉換給內部主機
  ip nat pool todd 170.168.2.3 192.168.2.254 netmask 255.255.255.0
  ip nat inside source list 1 pool todd
• 端口NAT（PAT）
  最爲流行的NAT配置類型。經過多個源端口，將多個未登記的IP地址映射到一個合法IP地址（多到一）。使用PAT可以使上千個用戶僅使用一個全局IP地址鏈接到Internet。
  ip nat pool globalnet 170.168.2.1 170.168.2.1 netmask 255.255.255.0
  ip nat inside source list 1 pool globalnet overload

  

UDP

• 特色：
  1.無鏈接
  2.不可靠
  3.面向報文，無邊界的，添加首部後直接交付給IP層，不合並也不拆分。因此報文太長後，IP層在傳輸時會分片，下降效率，過短，IP數據報的首部相對長度太大，也下降IP層效率
  4.沒有擁塞控制
  5.支持一對一，一對多，多對一，多對多的交互通訊
  6.首部開銷小，只有8字節
• UDP首部：源端口號，目的端口號，長度，校驗和，各2字節
  計算校驗和方法：在首部前臨時增長一個僞首部：源IP地址(4)目的IP地址(4)0(1)17(1)UDP長度(2)，將僞首部，首部，數據(非偶數字節則補0)按二進制運算求和，反碼做爲校驗和

TCP

• 特色
  1.面向鏈接
  2.可靠
  3.只能一對一鏈接
  4.全雙工通訊，通訊雙方在任什麼時候候均可以發送數據，設有發送緩存和接受緩存
  5.面向字節流，先把字節寫入緩存，一次發送一個數據塊（加TCP首部），一塊包含多少字節受窗口值和網絡擁塞程度決定

• TCP首部：20B~60B，固定部分：

  源端口號(2),目的端口號(2);
    序號(4)每一個字節都按順序編號，首部中的序號字段值指的是本報文段所發送的數據的第一個字節的序號;
    確認號(4)但願收到對方下一個報文段的第一個數據字節的序號，若確認號\=N,表示N-1爲止的全部數據都已正確收到
    數據偏移(4bit)首部長度，以4字節長度爲計算單位，最多可表示15*4\=60B
    保留(6)
    緊急URG(1bit)高優先級數據，不安排隊順序傳送
    確認ACK
    PUSH,發送端 : TCP將數據包置上PUSH標誌時，表示這個數據應該被當即發送，而不要等待額外的數據。 接收端 : 接收端接受到帶有PUSH標誌的數據時，應該接接受緩存中收到的全部數據（包含當前帶PUSH標示的數據包）應該當即提交到應用層。當前沒有API通知TCP哪些數據須要被設置PUSH標示，徹底由TCP自行判斷決定。
    復位RST,必須釋放鏈接
    同步SYN
    終止FIN
    窗口(2)指該方接收窗口的窗口值，容許對方發送的數據量
    校驗和(2)計算方法和UDP同樣，僞首部中17改爲6便可
    緊急指針(2)當URG=1時，指出緊急數據的字節數

• 可靠傳輸實現
  滑動窗口，發送方：通過確認的就往前移動窗口，超時重傳，接收方：非按序到達的暫存，確認的都達到後發送確認信息（積累確認），窗口前移。
  TCP流量控制：利用滑動窗口實現，接收方給發送方規定窗口大小。
  TCP擁塞控制：發送方維持一個擁塞窗口，只要網絡沒出現擁塞，擁塞窗口就再增大一些，出現擁塞，就減少一些
  慢開始（由小到大逐漸增大發送窗口，指的是開始很小，增加速率不慢），擁塞避免（線性增加），快重傳，快恢復（當連續收到三個重複確認，將慢開始門限執行乘法減少，而後開始執行擁塞避免）
  發送方的窗口大小=min(擁塞窗口大小，接收方窗口)
  
• TCP鏈接管理
  1.三次握手創建鏈接：
  
  這裏爲何要再發一次ACK=1的確認呢？若是B應答就創建鏈接，可能出現這種狀況：A發送一次請求後延遲，從新發送一次，B接受一個後創建了鏈接，傳完以後，B又收到了以前延遲的請求，又創建了鏈接，可是A並無數據要傳，浪費了B的資源。發送SYN不能攜帶數據，可是會消耗一個序號，ACK若是不攜帶數據就不會消耗序號，因此下一個報文段seq=x+1。
  2.四次揮手釋放鏈接：
  
  A收到第一次B的確認後就不能傳數據了，A要等待2MSL的緣由：一爲了保證最後一條確承認以到達B，由於若A發完就關閉了，若此確認丟失，A也收不到B的丟失確認也沒法從新發送。二是爲了再此時間段內讓以前丟失重發的報文都從網絡中消失，再開始下一次鏈接。
  在沒有數據發送的狀況下。直接發送FIN/ACK四次變三次。
  TIME_WAIT是確定必不可少的
  3.socket狀態

  

• TCP窗口與重傳機制
  發送方窗口快照：C3可能爲0
  
  假設已發送未確認字節（32至45）分爲4段傳輸：32-34，35-36，37-41，42-45。第1，2，4已經到達，而3段沒有收到。接收方只會發回32-36的確認信息。接收方會保留42-45但不會確認

  
  發送設備以後會中止發送，窗口停留在37-41。TCP包括一個傳輸及重傳的計時機制。TCP會重傳丟失的片斷。對於42-45的處理看SCAK。
  1.基於定時器的重傳(timeout or timer-based retransmission)，這種重傳方式是發出去的數據在RTO超時後尚未收到對應的ACK就會進行超時重傳。
  2.另外TCP還有一種基於ACK報文結構順序的重傳，這種重傳叫作快速重傳(fast retransmission或者fast retransmit)，當TCP注意到累計ack(即TCP頭中的ack number)再也不推動（當收到p1,p3,p4時都會回p1的ack）或者接收端經過SACK信息指示發送端接收端存在洞(hole)時候就會觸發發送端的重傳，一般來講快速重傳比超時重傳更高效
  對於1：

  每一個片斷在發送是都啓動重傳計時，當超過這個RTO尚未確認就重傳，確認則<=該序號的都移出窗口。
  RTO(Retransmission Timeout)，RTO應該根據環回時間RTT(round-trip-time)來估計。環回時間應該包括三部分：數據包傳送過的時間，接收端處理這個數據包併產生ACK的時間，ACK確認包返回的時間。RTO計算：https://www.cnblogs.com/lshs/...
  SACK的選擇重傳機制：鏈接的兩方設備必須同時支持這一功能，經過鏈接時使用的SYN片斷來協商是否容許SACK
  在4個片斷的狀況下，若是客戶端接收到片斷4而沒有接收到片斷3，當它發回確認號爲201（片斷1和片斷2）的確認信息，其中包含一個SACK選項指明：「已接收到字節361至500，但還沒有確認」。若是片斷4在片斷1和2以後到達，上述信息也能夠經過第二個確認片斷來完成。服務器確認片斷4的字節範圍，併爲片斷4打開SACK位。當片斷3重傳時，服務器看到片斷4的SACK位爲1，就不會對其重傳。
  在片斷3重傳以後，片斷4的SACK位被清除。這是爲了防止客戶端出於某種緣由改變片斷4已接收的想法。客戶端應當發送確認號爲501或更高的確認信息，正式確認片斷3和4接收到。若是這一狀況沒有發生，服務器必須接收到片斷4的另外一條選擇確認信息才能將它的SACK位打開，不然，在片斷3重傳時或計時器超時的狀況下會對其自動重傳。

• 提高效率
  對於ack(1.累計【累計發送連續順序接收最大的】2.延時【與數據一塊兒發送，最長等待時間通常200ms】)。對於數據1.等大包，2。擁塞控制
  Nagle算法，任意時刻，最多隻能有一個未被確認的小段（對於發送數據包）。

  Nagle算法的規則（可參考tcp_output.c文件裏tcp_nagle_check函數註釋）：
  （1）若是包長度達到MSS，則容許發送；
  （2）若是該包含有FIN，則容許發送；
  （3）設置了TCP_NODELAY選項，則容許發送；
  （4）未設置TCP_CORK選項時，若全部發出去的小數據包（包長度小於MSS）均被確認，則容許發送；
  （5）上述條件都未知足，但發生了超時（通常爲200ms），則當即發送。

  delayed ack算法：ACK響應，等待一個超時或者知足特殊條件時再發送。對於Linux實現，這些特殊條件以下：

  1）收到的數據已經超過了full frame size
  2）或者處於快速回復模式
  3）或者出現了亂序的包
  4）或者接收窗口的數據足夠多

  默認狀況下，發送數據採用Nagle 算法。這樣雖然提升了網絡吞吐量，可是實時性卻下降了，在一些交互性很強的應用程序來講是不容許的，使用TCP_NODELAY選項能夠禁止Nagle 算法。此時，應用程序向內核遞交的每一個數據包都會當即發送出去。須要注意的是，雖然禁止了Nagle 算法，但網絡的傳輸仍然受到擁塞控制和delay ack的影響。delay ack能夠經過TCP_QUICKACK使得機內快速回復模式
  Nagle算法徹底不受用戶socket的控制，你只能簡單的設置TCP_NODELAY而禁用它
  CORK算法經過設置或者清除TCP_CORK使能或者禁用之，內核會盡力把小數據包拼接成一個大的數據包（一個MTU）再發送出去

• setsockopt選項
  TCP_NODELAY禁用nagle，不會有小包等待，提升吞吐量，下降延遲。
  TCP_CORK 儘量多的發送數據，與TCP_NODELAY相反，適用文件服務。
  TCP_QUICKACK 快速回復模式，AACK不累計
  SO_LINGER做用於TCP close，默認close會當即返回，將丟棄緩存區內的全部數據而且當即終止鏈接（即發送RST數據包）。設置該選項，只關閉寫，不關閉讀，保證讀Buffer沒了，就不會發RST，而是正常的四次揮手。
  SO_KEEPALIVE 沒有數據時按期發送探測包。
  SO_REUSEADDR 重用處於TIME_WAIT狀態的socket。
  TCP_MAXSEG 設置MSS，即通告對方的窗口大小。
  TCP_DEFER_ACCEPT 防止accept以後馬上讀數據，而要等client發過來數據再去讀

HTTP

內容比較多，參考http權威讀書指南。講一些實際上應用中會用到和注意的
協議格式響應略

• HTTP依賴TCP性能
  TCP創建鏈接創建握手，TCP慢啓動擁塞機制，數據彙集的Nagle算法，用於捎帶確認的TCP延遲確認算法，TIME_WAIT時延和端口耗盡
  延遲確認：因爲確認報文很小，TCP容許在輸出數據分組捎帶確認報文，延時確認算法會在一個特定的窗口時間（一般是100-200毫秒）內將輸出確認存放在緩衝區中，以尋找可以捎帶他的輸出數據分組，若是在該時間段內沒有輸出數據分組，確認信息再單獨發送。可是HTTP具備雙峯特性的請求，當但願有反方向回傳時，恰恰沒有那麼多分組
  慢啓動：新創建鏈接發送報文數量慢啓動過程
  Nagle算法：TCP至少40字節頭，Nagle算法鼓勵發送全尺寸段，只有當全部其餘分組都被確認或者緩存中積累了足夠發送一個全尺寸分組的數據時，纔會將緩存數據發送出去。與延遲確認交互存在問題，確認分組自身會被延遲100-200毫秒，http小報文沒法填滿一個分組。HTTP嚐嚐會設置TCP_NODELAY禁用Nagle算法
  TIME_WAIT:關閉鏈接時，會在內存中記錄最近關閉鏈接的IP地址和端口號，一般會維持2MSL，以確保這段時間內部會建立具備相同地址和端口號的新鏈接。一般不會有什麼問題，可是在單臺機器上測試時，只有源端口號可變，會出現端口號耗盡狀況，測試中須要注意。
• 鏈接
  connection首部的值：只與本鏈接有關的首部（發往下一跳要刪除）；任意本鏈接有關的非標準選項，close（關閉持久鏈接），在到達一跳時要刪除全部的值再自行處理。
  持久鏈接：1.1，默認開啓，除非Connection: Close;
  管道：在1.1keep-alive基礎上，第一個發送以後就能夠不等響應發送第二個，要求服務端響應保持按順序，客戶端重傳處理。不能用於POST非冪等（必定要等響應才決定是否重發）方法。
  關閉鏈接：當一端關閉輸入鏈接，另外一端又發來消息，操做系統會發送一個錯誤信息，並刪除對端還未讀取的全部緩存，對於管道，可能會由於一個新鏈接刪除不少緩存未讀取的鏈接數據。應該雙方否只關閉輸出鏈接，收到雙方關閉信息後再徹底關閉。
  並行鏈接：在客戶端帶寬不足時沒有提高；消耗更多內存資源；服務端壓力大。通常瀏覽器會限制最多併發4個，服務端能夠隨意關閉特定客戶端超過鏈接數的請求。
• web的結構組件：代理（轉發全部web流量的可信任中間節點，via），緩存，網關（將HTTP流量轉化爲其餘協議），隧道（在HTTP鏈接中轉發非HTTP數據好比在ssl應用上以下圖），agent代理（發起HTTP請求瀏覽器等），web服務器
• content相關：
  分塊編碼chunked：把報文分割爲若干個大小已知的塊，塊之間是緊挨着發送的，這樣就不須要在發送以前知道整個報文的大小了。
  範圍請求Range,響應Accept-ranges代表接收範圍請求，值爲單位，若一個請求包含多個範圍，響應有Content-Type: multipart/byteranges.
• HTTP2.0
  在底層傳輸協議之上分爲三層：報文傳輸，遠程操做調用，web應用功能。
  報文傳輸：對報文進行管道話和批量化傳輸，以下降往返時延；重用鏈接，以下降時延，提升傳輸帶寬；在同一條鏈接上並行的複用多個報文流，在防止報文流餓死的同事優化共享鏈接；對報文進行有效的分段，使報文邊界的肯定更加容易。
  webmux：一個複雜的高性能報文系統，能夠在一個複用的TCP鏈接上並行傳輸報文，能夠對以不一樣速度產生和消耗獨立報文流進行高效的分組，並將其複用到一條或少數幾條TCP鏈接上去。
  遠程調用：二進制連接協議

• HTTPS
  SSL 基於TCP，SSL不是簡單地單個協議，而是兩層協議；SSL記錄協議（SSL Record Protocol）爲多種高層協議（SSL握手協議，SSL修改密碼參數協議，SSL報警協議）提供基本的安全服務。
  0x01 對對稱加密的通俗理解

  即通訊的雙方都使用同一個祕鑰進行加解密

  0x02 對非對稱加密算法的通俗理解 [ RSA ]

  私鑰 + 公鑰= 密鑰對
  即用私鑰加密的數據,只有對應的公鑰才能解密,用公鑰加密的數據,只有對應的私鑰才能解密
  其實這個很容易理解,由於通訊雙方的手裏都有一套本身的密鑰對,通訊以前雙方會先把本身的公鑰都先發給對方
  而後對方再拿着這個公鑰來加密數據響應給對方,等到到了對方那裏,對方再用本身的私鑰進行解密,就這麼簡單

  0x03 非對稱加密所形成的速度慢的問題解決辦法

  (1) 先生成一個對稱加密算法的密鑰,用RSA的方式先安全的發給對方  
  (2) 隨後就再也不用RSA了,只用這個對稱加密的密鑰來互相通訊

  

  -> 客戶端向服務端發送請求 
     -> 服務端返回數字證書 
      -> 客戶端用本身的CA[主流的CA機構證書通常都內置在各個主流瀏覽器中]公鑰去解密證書,若是證書有問題會提示風險 
          -> 若是證書沒問題客戶端會生成一個對稱加密的隨機祕鑰而後再和剛剛解密的服務器端的公鑰對數據進行加密,而後發送給服務器端 
            -> 服務器端收到之後會用本身的私鑰對客戶端發來的對稱祕鑰進行解密

THRIFT

Thrift是一個跨語言的服務部署框架。支持協議：只關心TBinaryProtocol。傳輸層支持：只關心TFramedTransport，服務模型：用這個TNonblockingServer，TProcessor 服務調用組件，單獨將框架時講解，這裏說下協議。
TBinaryProtocol的實現。

writeMessgeBegin方法寫了消息頭，包括4字節的版本號和類型信息，字符串類型的方法名，４字節的序列號seqId
writeFieldBegin，寫了１個字節的字段數據類型，和2個字節字段的順序號
writeI32，寫了４個字節的字節數組
writeString,先寫４字節消息頭表示字符串長度，再寫字符串字節
writeBinary,先寫４字節消息頭表示字節數組長度，再寫字節數組內容
readMessageBegin時，先讀４字節版本和類型信息，再讀字符串，再讀４字節序列號
readFieldBegin，先讀1個字節的字段數據類型，再讀2個字節的字段順序號
readString時，先讀４字節字符串長度，再讀字符串內容。字符串統一採用UTF-8編碼

故障排查

tcpdumpwiresharkping經過netstat進行流量測量，netstat -i（獲取快照），spray -c1000 205.153.63.239（模擬發送數據），netstat -p tcp -s -s（-s輸出詳細信息）ttcpnetperfiperftreno