TCP減壓引擎，第一次聽說這個名詞，但是並不是一個新的概念了，若干年前聽說過裝置廠商在研究在FPGA之中實現TCP Stack，但是後來沒有聽到任何的產品出來，應該是路由裝置to host的traffic不多，而對於FW裝置，中間的TCP Proxy實現過於複雜，工程上不可能實現。

現在的所謂TOE實現我理解主要用於host的interface之中，用於為Gbits以及10Gbits介面場景中為CPU減壓，例如部署在資料中心內部的伺服器，CPU雖然越來越快，但是對於洶湧澎湃的Traffic來說，還是有些力不從心。

上面是TOE應用前後協議棧的差別，我覺得畫的有點絕對，TCP Stack不太可能完全實現在interface之中，其實TOE主要實現如下的offload：

1.TCP/IP Checksum offload

CPU可以不用計算checksum而由網絡卡計算

2.CPU不用考慮資料的分段了，估計是直接將socket送過來的buf交給網絡卡。

如果是僅僅實現上述功能TOE是很可能工程化實現的。

在另一篇文件中提到了TOE的一些優勢，但是我的分析，這個可能是要實現TOP替代整個TCP之後的優勢。

1.減少中斷：不用每個報文都產生中斷，如果10G介面這個對於CPU是很大的開銷。

2.減少memory拷貝次數，很多時候網絡卡的buffer和app的可以直接共享。

3.協議處理的節約，這個是當然的了。

顯而易見TOE有一些問題。

1.沒有標準，導致協議棧實現困難，無法標準化的進行剪裁

2.硬體中實現，有bug怎麼辦？

TCP/IP 協議早已是網路的標準語言。隨著Internet SCSI、Remote Diret Memory Access這些網路存貯標準的問世和實用化，從某種意義上說，TCP/IP又成了一種存貯協議。 
　　
　　
　　 
　　　　我們知道，用TCP/IP協議處理網路流量，要佔用大量伺服器資源。為了減輕伺服器的壓力，一種稱為TCP減負引擎（TCP Offload Engine ：TOE）的技術應運而生。TCP減負引擎一般由軟硬兩部分元件構成，將傳統的TIP/IP協議棧的功能進行延伸，把網路資料流量的處理工作全部轉到網絡卡上的整合硬體中進行，伺服器只承擔TCP/IP控制資訊的處理任務。這種為伺服器減輕負擔的技術，得到了大多數廠商的肯定。 
　　
　　　　普通網絡卡用軟體方式進行一系列TCP/IP相關操作，因此，會在三個方面增加伺服器的負擔，這三個方面是：資料複製、協議處理和中斷處理。

　　　　網路上每個應用程式在收發大量資料包時，要引發大量的網路I/O中斷，對這些I/O中斷訊號進行響應，成了伺服器的沉重負擔。比如，一個典型的 64Kbps的應用程式在向網路傳送資料時，為了將這些資料裝配成乙太網的資料包，並對網路接收確認訊號進行響應，要在伺服器和網絡卡間觸發60多箇中斷事件，這麼高的中斷率和協議分析工作量已經是相當可觀的了。雖然某些網路作業系統具有中斷捆綁功能，能夠有效減少中斷訊號的產生，但卻無法減少伺服器和網絡卡間響應事件的處理總量。 
　　
　　　　TCP減負引擎網絡卡的工作原理與普通網絡卡不同。普通網絡卡處理每個資料包都要觸發一次中斷，TCP 減負引擎網絡卡則讓每個應用程式完成一次完整的資料處理程序後才觸發一次中斷，顯著減輕伺服器對中斷的響應負擔。還是以64Kbps的應用程式為例，應用程式向網路傳送資料全部完成後，才向伺服器傳送一個數據通道減負事件中斷，資料包的處理工作由TCP減負引擎網絡卡來做，而不是由伺服器來做，從而消除了過於頻繁的中斷事件對伺服器的過度干擾。網路應用程式在收發資料時，經常是同一資料要複製多份，在這種情形下，TCP減負引擎網絡卡發揮的效益最明顯。 
　　
　　　　普通網絡卡通過採用支援校驗功能的硬體和某些軟體，能夠在一定程度上減少傳送資料的複製量，但卻無法減少接收資料的複製量。對大量接收資料進行復制通常要佔用大量的機器工作週期。普通網絡卡先將接收到的資料在伺服器的緩衝區中複製一份，經系統處理後分配給其中一個TCP連線，然後，系統再將這些資料與使用它的應用程式相關聯，並將這些資料由系統緩衝區複製到應用程式的緩衝區。TCP減負引擎網絡卡在接收資料時，在網絡卡內進行協議處理，因此，它不必將資料複製到伺服器緩衝區，而是直接複製到應用程式的緩衝區，這種“零拷貝”方式避免了網絡卡和伺服器間的不必要的資料往復拷貝。 
　　
　　　　TCP減負引擎網絡卡能顯著減輕由資料大量移動造成的伺服器過載負擔。實測證明，對於檔案伺服器和以內容服務為主的伺服器應用環境來說，如果用TCP減負引擎網絡卡代替普通網絡卡，相當於為伺服器增加了一個CPU

對於網路安全來說，網路傳輸資料包的捕獲和分析是個基礎工作，綠盟科技研究員在日常工作中，經常會捕獲到一些大小遠大於MTU值的資料包，經過分析這些大包的特性，發現和網絡卡的offload特性有關，本文對網絡卡Offload技術做簡要描述。

網路分片技術

MTU

最大傳輸單元，指一種通訊協議的某一層上面所能通過的最大資料包大小（以位元組為單位）。

在乙太網通訊中，MTU規定了經過網路層封裝的資料包的最大長度。例如，若某個介面的MTU值為1500，則通過此介面傳送的IP資料包的最大長度為1500位元組。

小編注：對於普通使用者來說，如果你優化過迅雷的下載速度，可能通過這篇文章《合理設定MTU，提升下載速度》，對MTU的基礎知識有所瞭解。

IP分片

當IP層需要傳送的資料包長度超過MTU值時，則IP層需要對該資料包進行分片，使每一片的長度小於或等於MTU值。在分片過程中，除了對payload進行分片外，資料包的IP首部也需要進行相應的更改：

• 將identifier欄位的值複製給每個分片；
• 將分片資料包的Flags中的DF位置為0；
• 除最後一個分片之外的其他分片，將MF位置為1；
• 將Fragment Offset欄位設定正確的值。  

MSS

最 大分段長度，TCP資料包每次能夠傳輸的最大資料分段長度，在TCP協議的實際實現中，MSS往往用MTU-(IP Header Length + TCP Header Length)來代替。在TCP通訊建立連線時，取兩端提供的MSS的最小值作為會話的MSS值。由於TCP分段有MSS值的限制，通常情況下TCP資料 包經IP層封裝後的長度不會大於MTU，因此一般情況下，TCP資料包不會進行IP分片。

網絡卡offload機制

早先TCP設計的目標是為了解決低速網路傳輸的不可靠性問題（撥號上網的年代），但隨著網際網路骨幹傳輸速度的提升（光纖、千兆以太、萬兆以太）以及使用者端更可靠的訪問機制的出現（ADSL等），相關的資料中心及客戶端桌面環境上的TCP軟體常常需要面臨大量的計算需求。

當網路速度超過1Gb的時候，這些計算會耗費大量的CPU時間，有資料表明，即便使用千兆全雙工網絡卡，TCP通訊也將消耗CPU的80%的使用率（以2.4GHz奔騰4處理器為例），這樣留給其他應用程式的時間就很少了，表現出來就是使用者可能感覺到很慢。

小編注：當年的蠕蟲病毒對CPU的影響與此近似。

為了解決效能問題，就產生了TOE技術（TCP offload engine），將TCP連線過程中的相關計算工作轉移到專用硬體上（比如網絡卡），從而釋放CPU資源。從2012年開始，這項技術開始在普通使用者的網絡卡上應用。

隨 著技術的日趨成熟，目前越來越多的網絡卡裝置開始支援offload特性，以便提升網路收發和處理的效能。本文所描述的offload特性，主要是指將原本 在協議棧中進行的IP分片、TCP分段、重組、checksum校驗等操作，轉移到網絡卡硬體中進行，降低系統CPU的消耗，提高處理效能。

傳送模式

**TSO （tcp-segmentation-offload） **

從 名字來看很直觀，就是把tcp分段的過程轉移到網絡卡中進行。當網絡卡支援TSO機制時，可以直接把不超過滑動視窗大小的payload下傳給協議棧，即使數 據長度大於MSS，也不會在TCP層進行分段，同樣也不會進行IP分片，而是直接傳送給網絡卡驅動，由網絡卡驅動進行tcp分段操作，並執行checksum 計算和包頭、幀頭的生成工作。例如，

在本地主機上（10.8.55.1）傳送一個超長的HTTP請求，當TSO模式關閉時，10.8.55.1抓包如下

當TSO模式開啟時，10.8.55.1抓包如下：

**UFO（udp-fragmentation-offload） **

是一種專門針對udp協議的特性，主要機制就是將IP分片的過程轉移到網絡卡中進行，使用者層可以傳送任意大小的udp資料包（udp資料包總長度最大不超過64k），而不需要協議棧進行任何分片操作。目前貌似沒找到有支援UFO機制的網絡卡，主要是應用在虛擬化裝置上。

**GSO（generic-segmentation-offload） **

相 對於TSO和UFO，GSO機制是針對所有協議設計的，更為通用。同時，與TSO、UFO不同的是，GSO主要依靠軟體的方式實現，對於網絡卡硬體沒有過多 的要求。其基本思想就是把資料分片的操作儘可能的向底層推遲直到資料傳送給網絡卡驅動之前，並先檢查網絡卡是否支援TSO或UFO機制，如果支援就直接把資料 傳送給網絡卡，否則的話再進行分片後傳送給網絡卡，以此來保證最少次數的協議棧處理，提高資料傳輸和處理的效率。

接收模式

**LRO/GRO（large-receive-offload） **

在網絡卡驅動層面上將接受到的多個TCP資料包聚合成一個大的資料包，然後上傳給協議棧處理。這樣可以減少協議棧處理的開銷，提高系統接收TCP資料的能力和效率。

generic-receive-offload，基本思想和LRO類似，只是改善了LRO的一些缺點，比LRO更加通用。目前及後續的網絡卡都採用GRO機制，不再使用LRO機制。例如，

當本地主機（10.51.19.40）開啟GRO模式時，從主機10.8.55.11向主機10.51.19.40傳送一個超長請求。

10.8.55.11抓包如下：

10.51.19.40抓包如下：

  **RSS（Receive Side Scaling） **

具備多個RSS佇列的網絡卡，可以將不同的網路流分成不同的佇列，再將這些佇列分配到多個CPU核心上進行處理，從而將負荷分散，充分利用多核處理器的能力，提交資料接收的能力和效率。

網絡卡offload模式的設定

Linux

在linux系統下，可以通過ethtool檢視各模式的狀態並進行設定：

**檢視狀態 **

1. ethtool –k 裝置名

  **設定開關狀態 **

1. ethtool –K 裝置名模式名（縮寫）on/off

windows

在windows系統下，可以通過裝置管理器中網絡卡裝置的屬性對網絡卡模式進行檢視和調整。以Intel 82579LM和Intel I217-LM網絡卡為例

• IPv4、TCP、UDP校驗和分載傳輸控制的是在網絡卡中進行checksum的計算和校驗，其中Rx表示接收資料、Tx表示傳送資料。
• 大型傳送分載對應的是前文中提到的TSO模式
• 接收方調整和接收方調整佇列對應的是RRS模式的啟用狀態以及RSS佇列的個數設定。

網絡卡Offload技術給網路資料包分析帶來的影響

目 前常用的抓包工具大部分都是從協議棧中（如資料鏈路層）捕獲資料包，而網絡卡的offload特性會將資料包的分片、重組等工作轉移到協議棧以下的硬體層面 進行，因此在開啟TSO、GRO等機制的情況下，我們使用tcpdump、wireshark等工具抓取到的資料包往往不能真實反應鏈路上實際的資料幀， 給網路流量特徵的分析造成不利影響。

在某些情況下，例如分片攻擊等攻擊方式，甚至可能會因為網絡卡裝置的offload機制處理，而規避防火牆、IDS以及人工的檢查。針對這些情況，可以選擇關閉網絡卡offload的相關選項，或者在鏈路的其他節點進行抓包。

TSO（TCP Segment Offload）技術是一種利用網絡卡的少量處理能力，降低CPU傳送資料包負載的技術，需要網絡卡硬體及驅動的支援。

  在不支援TSO的網絡卡上，TCP層向IP層傳送資料會考慮mss，使得TCP向下傳送的資料可以包含在一個IP分組中而不會造成分片， mss是在TCP初始建立連線時由網絡卡MTU確定並和對端協商的，所以在一個MTU＝1500的網絡卡上，TCP向下傳送的資料不會大於min(mss_local, mss_remote)-ip頭-tcp頭。

  而當網絡卡支援TSO時，TCP層會逐漸增大mss（總是整數倍數增加），當TCP層向下傳送大塊資料時，僅僅計算TCP頭，網絡卡接到到了IP層傳下的大數 據包後自己重新分成若干個IP資料包，新增IP頭，複製TCP頭並且重新計算校驗和等相關資料，這樣就把一部分CPU相關的處理工作轉移到由網絡卡來處理。 核心TCP／IP協議棧也必須考慮下發包數和實際包數不一致的情況，例如處理擁塞控制演算法時必須做一些特殊的處理等等。

  注：參考核心版本為2.6.9；
1 TCP/IP協議棧對TSO的支援
1.1 逐漸增大mss（offload）

  在不支援TSO的網絡卡 上，TCP層向IP層傳送資料會考慮mss，使得TCP向下傳送的資料可以包含在一個IP分組中而不會造成分片， mss是在TCP初始建立連線時根據網絡卡MTU確定並和對端協商的，所以在一個MTU＝1500的網絡卡上，TCP向下傳送的資料不會大於min (mss_local, mss_remote)-ip頭-tcp頭。

在應用層向傳輸層傳輸資料時，對於TCP協議，最終會呼叫如下函式：

  檔案 net/ipv4/tcp.c

  int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, size_t size)

該函式會呼叫如下函式 

  檔案 net/ipv4/tcp.c 

  unsigned int tcp_current_mss(struct sock *sk, int large) 

  獲得當前的mss值，如果網絡卡不支援TSO，則該函式返回的mss值將和原來相同，否則如果當前不是一個MSG_OOB型別的訊息，核心將嘗試增大 mss值，注意： 最大的mss值不會大於65535-ip頭-tcp。 核心根據/proc變數tcp_tso_win_divisor決定增大後的mss佔當前擁塞控制視窗的比率（snd_cwnd）。最終的效果是：增大的mss總是原有mss值的整數倍，但是不會超過snd_cwnd/tcp_tso_win_divisor。  
1.2 對skb計數的修正

  在啟用TSO時，由於TCP層向下傳送一個skb， 有可能最終會發出n個IP資料包，即一個skb和一個IP packet可能不是一一對應的關係，而我們都知道，TCP擁塞控制演算法需要精確跟蹤當前傳送、接收以及擁塞控制視窗來決定最終傳送多少資料包，TSO的 存在給計算帶來了一定的複雜性，所以核心在每一個skb的末尾維護了額外的資料（struct skb_shared_info，通過skb_shinfo取出），表示該skb包含多少個packet。核心提供下列函式操作這塊資料： 

  tcp_skb_pcount 

  tcp_skb_mss

  tcp_inc_pcount

  tcp_inc_pcount_explicit

  tcp_dec_pcount_explicit

  tcp_dec_pcount

  tcp_dec_pcount_approx

  tcp_get_pcount

  tcp_set_pcount

  tcp_packets_out_inc

  tcp_packets_out_dec

  tcp_packets_in_flight

  最終，當TCP協議棧在呼叫tcp_snd_test決定是否可以傳送當前skb時，會呼叫上述函式修正計算結果。
2 網絡卡驅動層對TSO的支援

  如果skb_shinfo(skb）->tso_size不為0，則表明網絡卡需要對這樣的skb作特殊的處理（而只有當網絡卡驅動初始化時宣告自己支援TSO，才可能出現這樣的skb），以e1000網絡卡驅動為例： 

  函式e1000_tso，在檔案drivers/net/e1000/e1000_main.c，被e1000_xmit_frame (即hard_start_xmit服務函式)呼叫

if(skb_shinfo(skb)->tso_size) {

…

  // 計算頭部偏移

  ipcss = skb->nh.raw - skb->data;

  ipcso = (void *)&(skb->nh.iph->check) - (void *)skb->data;

  tucss = skb->h.raw - skb->data;

  tucso = (void *)&(skb->h.th->check) - (void *)skb->data;

  tucse = 0;

……

  //把頭部偏移放入context，最終寫入暫存器

  context_desc = E1000_CONTEXT_DESC(adapter->tx_ring, i);

  context_desc->lower_setup.ip_fields.ipcss = ipcss;

  context_desc->lower_setup.ip_fields.ipcso = ipcso;

  context_desc->lower_setup.ip_fields.ipcse = cpu_to_le16(ipcse);

  context_desc->upper_setup.tcp_fields.tucss = tucss;

  context_desc->upper_setup.tcp_fields.tucso = tucso;

  context_desc->upper_setup.tcp_fields.tucse = cpu_to_le16(tucse);

  context_desc->tcp_seg_setup.fields.mss = cpu_to_le16(mss);

  context_desc->tcp_seg_setup.fields.hdr_len = hdr_len;

  context_desc->cmd_and_length = cpu_to_le32(cmd_length);

……

}

……

  //設定TSO標誌

  if (likely(tso))

  tx_flags |= E1000_TX_FLAGS_TSO;

……

  //傳送“大”的skb資料

e1000_tx_queue(adapter,

  e1000_tx_map(adapter, skb, first, max_per_txd, nr_frags, mss),

  tx_flags);

即驅動需要告訴網絡卡硬體（設定E1000_TX_FLAGS_TSO標誌），讓網絡卡對這個skb重新分塊，對每一個分塊計算TCP頭和IP頭校驗和，為此需要告訴網絡卡對應欄位的偏移。
3 TSO對基於 RAW_SOCKET的抓包工具的影響

  當傳送資料包時，skb經過如下路徑發向網絡卡驅動 

net_tx_action->dev_queue_xmit()-> 驅動的hard_start_xmit服務函式 

  在函式dev_queue_xmit()中，如果有抓包工具開啟了RAW_SOCKET，則該函式會在呼叫hard_start_xmit之前呼叫 dev_queue_xmit_nit clone一份skb交給抓包工具。如果skb是一個TSO-enable的特殊skb，抓包工具將會看到這個長度大於MTU的“特殊”skb。 而且，由於TCP、IP的校驗和與長度欄位將由網絡卡重新計算，一些版本的核心有可能為了優化而不去計算填寫這些數值，所以除了會出現大資料包、校驗和與長 度錯誤的現象。  

例如：使用tcpdump在支援TSO的網絡卡抓取外出資料包可能會出現如下3種錯誤，其中第一種一般出現在使用e1000網絡卡驅動的2.6.9核心上，第2種出現在使用bnx2網絡卡驅動的2.6.9核心上，第3種出現在2.6.23+版本後的核心上：

  * ip bad len = 0

000001 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 4345 win 32768 <nop,nop,timestamp 945581949 19361257>

000145 IP bad-len 0

000229 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 8689 win 32768 <nop,nop,timestamp 945581949 19361257>

000011 IP bad-len 0

  * bad csum

16:29:32.561407 IP (tos 0x60, ttl 48, id 14116, offset 0, flags [DF], length:

80) 69.42.67.34.2612 > 81.13.94.6.1234: . [bad cksum 0 (->2610)!] ack 93407

win 9821

<nop,nop,timestamp 1046528205 5497679,nop,nop,sack sack 3

{122367:127103}{128551:129572}{122367:127103} >

  * “包合併”

在MTU＝1500的網絡卡上抓包，出現了比1500還大的IP包 

21:58:36.691026 IP (tos 0x0, ttl 64, id 38181, offset 0, flags [DF], proto 6, length: 52) 10.13.100.34.45043 > 10.1

3.100.102.34476: . [tcp sum ok] 1:1(0) ack 482281 win 16664 <nop,nop,timestamp 2304130362 99107965>

21:58:36.691029 IP (tos 0x0, ttl 64, id 10688, offset 0, flags [DF], proto 6, length: 23220) 10.13.100.102.34476 >

10.13.100.34.45043: . 525769:548937(23168) ack 1 win 1448 <nop,nop,timestamp 99107965 2304130362>

21:58:36.691031 IP (tos 0x0, ttl 64, id 38183, offset 0, flags [DF], proto 6, length: 52) 10.13.100.34.45043 > 10.1

3.100.102.34476: . [tcp sum ok] 1:1(0) ack 485177 win 16664 <nop,nop,timestamp 2304130362 99107965>

21:58:36.691033 IP (tos 0x0, ttl 64, id 38185, offset 0, flags [DF], proto 6, length: 52) 10.13.100.34.45043 > 10.1

3.100.102.34476: . [tcp sum ok] 1:1(0) ack 488073 win 16664 <nop,nop,timestamp 2304130362 99107965> 

根據上面的分析，可以知道這些現象本質都是TSO造成的假象，即TCPDUMP抓取的*外出*資料包並不能真實反應鏈路上實際的資料幀， 解決辦法有兩種：

  1. 關閉網絡卡的TSO選項

[xxx]#ethtool -K eth0 tso off

  2. 使用其他的旁路鏈路層的抓包工具

2010年09月06日 19:03| 155,863 次瀏覽| 釋出者 強伊文| 395 評論

　　可能很少有雷友注意過“本機、網路”的“MTU”值對自己網路效能產生的影響。對於追求更快的下載速度來說，MTU值設定不當，就彷彿穿著高跟鞋跑步一般。

MTU是什麼？

　　“MTU=最大傳輸單元　單位：位元組”

　　我們在使用網際網路時進行的各種網路操作，都是通過一個又一個“資料包”傳輸來實現的。而MTU指定了網路中可傳輸資料包的最大尺寸，在我們常用的乙太網中，MTU是1500位元組。超過此大小的資料包就會將多餘的部分拆分再單獨傳輸。

為什麼MTU影響網路效能？

　　讓我們看看這個情況，在Windows系統中，預設MTU值也是1500位元組，但是“不同的接入方式、不同地區的網路運營商、不同的路由器”有著不同的MTU設定。

　　例如：ADSL接入時MTU為1492位元組，假設A需要給B傳輸3000位元組資料，如果整個傳輸過程中各個環節的MTU都是1500，那麼2個數據包就可以傳輸完成。可是偏偏這時ADSL接入方式的MTU是1492位元組，資料包就因為這個MTU差異額外拆分為3個（為了便於理解，暫時不將“資料包報頭”納入考慮範圍）

　　顯然這額外增加了需要傳輸的資料包數量，而且拆包組包的過程也浪費了時間。如果從本地到網路採用一致的MTU就可以避免額外拆包。

對下載速度的影響會有多大？

　　就拿伊文家裡的線路質量不太好的電信4M頻寬為例，將作業系統的MTU值改為1492，再將路由器的MTU值從1460改為1492後，下載速度從原本的435KB/s提升到了450KB/s，提升了15KB/s。電信的頻寬檢測工具的檢測結果也從4.09M提升到了4.19M。

我該如何合理設定MTU呢？

　　更快的下載速度，對於迅雷的使用者來說，顯然很有意義。可是MTU設定不能一個值天下通用，所以我們講究合理設定MTU。

　　那麼什麼情況下的MTU值才是合理的呢？

我們先看看什麼是不合理的：

1、本地MTU值大於網路MTU值時，本地傳輸的資料包過大導致網路會拆包後傳輸，不但產生額外的資料包，而且消耗了“拆包、組包”的時間。

2、本地MTU值小於網路MTU值時，本地傳輸的資料包可以直接傳輸，但是未能完全利用網路給予的資料包傳輸尺寸的上限值，傳輸能力未完全發揮。

　　這樣我們就知道，所謂合理的設定MTU值，就是讓本地的MTU值與網路的MTU值一致，既能完整發揮傳輸效能，又不讓資料包拆分。

　　接下來最重要的就是要找出對於你的網路環境來說MTU多少才是合理的。

方法如下：

1、按Win+R組合鍵，調出“執行”選單，輸入“cmd”然後回車

2、在出現的“命令提示符”視窗中輸入“ping -l 1472 -f www.baidu.com”然後回車

含義：

ping：發起一個探測請求；

-l（L的小寫）：限制探測包大小；

1472：包大小為1472位元組；

-f：禁止路由器拆分資料包

www.baidu.com：設百度為探測目標

（你問我為什麼不用Google做目標？考慮到Google時不時被牆，還是算了吧。。）

3、這時有2種情況：

（1）、如果收到了回覆，那麼說明你的網路允許最大MTU值就是1500位元組，與系統預設值相同，只需要將路由器的MTU值也設定為1500即可；

（2）、如果出現需要拆分資料包但是設定 DF。或是Packer needs to be fragmented but DF set.的提示，那就說明資料包大小超過了網路限定的MTU大小。需要減小探測包大小再次嘗試。（為了截效果圖，我將探測包改為1473了）

4、按“上箭頭”恢復剛才輸入的命令，然後以5為跨度減小包大小為1467位元組，再次回車探測。

5、這時同樣也有兩種可能：

（1）、如果有返回，說明資料包小於MTU限制，就將包大小+3再次探測，如果+3之後沒有返回，那就以1為跨度降低資料包大小進行探測。

（2）、如果還是沒有返回，就繼續以5為跨度減小包大小，直至有返回後進行5（1）中的操作。

6、直至你發現數據包-1後，有了返回，就說明你探測到了MTU允許的準確資料包大小。（例如從1465降低到1464就有了返回，那麼允許的資料包大小就是1464）

7、不過上面得到的值還不能設定為作業系統或路由器的MTU，你找到的資料包大小需要加上28位元組的“資料包報頭”，才是完整的資料包尺寸。

（例如：探測到的資料包大小是1464，那麼加上28位元組，最終MTU=1492位元組）

8、最後，只需要將路由器和作業系統中的MTU值設定為你得出的結果即可。

　　路由器設定方法見路由器說明書！建議使用“Windows優化大師、超級兔子魔法設定、魯大師”等軟體修改作業系統的MTU。

以下是較複雜的方法：

（1）、XP作業系統設定方法：

1、 按Win+R組合鍵，調出“執行”選單，輸入regedit，然後回車； 

2、 選擇“HKEY_Local_Machine>SYSTEM>CurrentControlSet>Services>Tcpip>Parameters>interface”；

3、在 interface 中下可能有很多項，需要逐個觀察鍵值，會有一個項與你的網絡卡IP一致，選中該項；

4、然後在該項上點選右鍵，選擇“編輯>新建>DWORD值”，然後在右側將其命名為“MTU”；

5、右鍵點選MTU，選擇“修改”，在彈出的視窗中選擇“十進位制”，填入你得出的合理MTU值即可。

（2）、Vista、Win7作業系統設定方法：

1、進入系統盤:\Windows\System32\找到cmd.exe，右鍵“以管理員身份執行”；

2、在出現的“命令提示符”視窗中輸入“netsh interface ipv4 show subinterfaces”並回車來檢視當前的MTU值

3、接下來輸入“netsh interface ipv4 set subinterface "需修改的連線名" mtu=你得出的合理值 store=persistent”並回車即可

例如：“netsh interface ipv4 set subinterface "本地連線" mtu=1492 store=persistent”