程咬金有三板斧，我們有三招。在這篇博文中我們要出第三招，同時也意味着昨天在“希望的田野”上的第二招失敗了。
前兩招打頭（CPU）不湊效，這一招要換一個部位，但依然要堅持攻擊敵人最弱（最忙最累）部位的原則。那除了CPU，最忙最累的部位是哪里呢？對於Web服務器來說，毫無懸念，當然是網卡。而且阿里雲的雲服務器，所有的網絡負載都集中在一塊內網網卡上，SLB(負載均衡)用它，OCS(緩存服務)用它，RDS(數據庫服務)也用它。所以，就對它出招！
招式受這篇博文（XenServer – Windows 2003 TCP checksum issue）的啟發，博主通過禁用TCP/IP Offload解決了“通過IIS下載文件中途突然卡住”的問題。TCP/IP Offload的初衷就是讓網卡幫CPU分擔一些TCP/IP協議棧的處理工作，比如檢查checksum、發ack包，在物理機環境下，它是提高網絡處理性能的功臣。但是在虛擬機環境下，網卡是虛擬出來的，它的作用就有待商榷與驗證。於是，禁用它成為第三招的招式。
有了目標部位與招式，還等什么，出招！
開始的時候，我們偷了點懶，只出了兩個手指，想點穴取勝——只禁用了網卡的Checksum Offload與Check checksum on RX packets。
結果，“黑色1秒”依舊。
惱火之下，接着干脆南拳北腿一起出，南拳是在注冊表（HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\）中添加DisableTaskOffload=1（禁用TCP/IP Offload），北腿是在同樣的注冊表位置添加EnableRSS＝1（Receive-Side Scaling，充分利用多核CPU的優勢提高網絡處理性能，詳見這里）。
注冊表設置好之后，重啟計算機。。。
結果敵人被成功被擊倒！自13:30左右被擊倒后，到現在（21:20）也沒爬起來（黑色1秒沒出現）。如果明天一天還沒能爬起來，我們就可以宣布獲勝了。
后來，我們在另外一台服務器上發現只要用拳頭（只添加DisableTaskOffload=1）就可以把敵人干倒，到目前也沒爬起來，這還要進一步觀察。
是否真的能三招致勝，明天就會見分曉！
【更新】
結果，第二天早上黑色1秒再次出現。
【第三招增強版】
后來發現北腿出錯了，應該是禁用Receive-Side Scaling。Windows Server 2012中默認就啟用了Receive-Side Scaling，可以通過以下命令查看：
netsh int tcp show global
命令運行結果：
所以第三招增強版就是禁用Receive-Side Scaling，操作命令如下：
netsh int tcp set global rss=disabled
命令運行結果：
禁用Receive-Side Scaling之后有個意外的發現，CPU的8個核的負載分配更均勻了。
第三招增強版的效果還需要一段時間的觀察。
【參考資料】
Windows Server 2008 network speed slow, Xen 3.4.3 HVM ISO
XenServer – Windows 2003 TCP checksum issue（文中有一個地方寫錯了，應該是DisableTaskOffload=1）
Citrix XenServer Slow Network Performance