最近碰到詭異的現象，某種機型的機器在Gigabit Ethernet的環
境下，若使用「網路磁碟」模式複製資料會異常的緩慢，切換回
100BASE Ethernet 即恢復正常傳輸速度。
平台：Windows XP 64bit SP2
網卡：Intel 1000 Pro EB、D-Link DGE-530T
【實際狀況】
上圖顯示該牌機器，在「網路磁碟」掛載的狀態下，對 A Server
無法使用 Gigabit 網卡「正常」速度傳輸檔案，若使用 CIFS
格式連線則「沒有」傳輸緩慢的狀況。
若按照以上推斷，應該可以判斷 A Server 的 Samba 可能問題，
不幸的是其他機種(五六種機型)，連結 A Server 完全沒有問題
，怪的是 100BASE 連結 A Server 皆正常。
【測試流程】
1) 重新安裝作業系統，登入網域透過 Samba 測試。(無效)
2) Disable OnBoard NIC，改用 D-Link 測試。(無效)
3) 切換不同網域，連結相同的 Server 測試。(無效)
【解決方法】
這方案是無意間想到的，透過系統優化軟體，針對網路連線優化
修改登錄檔後，即排除以上「網路磁碟複製檔案緩慢」的狀況，
再透過 Regshot 比對優化前後的差別，測出原來在 Gigabit 的
環境下，可透過 RFC 1323 提高 TCP High Performance。
將以下內容複製到筆記本，另存 xxx.reg，執行即可！
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters]
"Tcp1323Opts"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"Tcp1323Opts"=dword:00000001
實測發現，之前發生的狀況只需將該筆 Registry Key 匯入即可
解決此項問題，若各位還有興趣，還有其他網路優化的功能可參
考，詳情如下：
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\VxD\MSTCP]
"NameSrvQueryTimeout"=dword:00000bb8
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VxD\MSTCP]
"NameSrvQueryTimeout"=dword:00000bb8
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters]
"DefaultTTL"=dword:00000080
"EnablePMTUBHDetect"=dword:00000000
"EnablePMTUDiscovery"=dword:00000001
"GlobalMaxTcpWindowSize"=dword:0005ae4c
"TcpMaxDupAcks"=dword:00000002
"SackOpts"=dword:00000001
"Tcp1323Opts"=dword:00000001
"TCPWindowSize"=dword:0005ae4c
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"DefaultTTL"=dword:00000080
"EnablePMTUBHDetect"=dword:00000000
"EnablePMTUDiscovery"=dword:00000001
"GlobalMaxTcpWindowSize"=dword:0005ae4c
"TcpMaxDupAcks"=dword:00000002
"SackOpts"=dword:00000001
"Tcp1323Opts"=dword:00000001
"TCPWindowSize"=dword:0005ae4c
[HKEY_CURRENT_USER\SessionInformation]
"ProgramCount"=dword:00000007
【TCP‧Window Size】
TCP Header (20 Bytes)
複習一下網路概論之前提到 Window Size，此欄位用來控制流量
，表示資料緩衝區的大小，當 TCP Process 啟動時，會同時產
生兩個緩衝區(Buffer)，分別為 Receive buffer & Send buffer
，Receive buffer用來儲存對方傳送過來的資料，並等待上層的
應用層程序提取。Send buffer則是用來儲存準備要送出的資料。
因TCP符合可信賴的傳輸協定，必須確認對方已正確收到資料後，
才可將 Receive buffer 的資料刪除，因此「Window Size」欄位
是用來通知對方目前 Receive buffer 空間大小為何，避免對方
送出 Receive buffer 所能接受的資料量，造成資料流失。
【TCP RFC1323】
透過網路查詢才發現，預設 TCP header 規範的 Windows Size
為 16bits (2^16 = 0~65535 bytes)，當使用高速網路的環境，
則會超過 65535，如此一來，若未使用 TCP Extensions RFC1323
Window scaling 的功能，則會導致傳輸檢核時間變長的狀況。
For a transmission below 1 megabit per second (Mbps), 8 KB.
For a 1-100 Mbps transmission, 17 KB.
For a transmission greater than 100 Mbps, 64 KB.
Note:
For 10 and 100 Mbps Ethernet connections,
the receive window is usually set to 17,520 bytes.
(17 KB rounded up to 12 1460-byte segments).
TCP Receive Window Size and Window Scaling
以上可證明，為什麼在 100BASE 的環境下，Copy 檔案正常，在
Gigabit 的環境會有問題，一開始我也想不通明明 Window Size
只有 16bits 該如何使用超過 65535 bytes 長度的資料？
所幸剛好有網友也碰到相同情形，寫了篇完整的說明，以下內容
部份引述「ccie11440‧TCP window scale option」該篇文章。
原來 RFC 1323 已定義 TCP Window Scale Option 的功能，除
了原有的 16bits 外，還可將 TCP Option 欄位中的 14bits 當
成延伸的 Window Size，因此 TCP Window Size 則可達到 30bits。
2^(16+14) = 1GB (1,073,741,824 bytes)
Wiki‧TCP window scale option
How to Calculate TCP throughput for long distance WAN links
若網路環境還是在 100BASE 的話，則無需修改相關設定值。
【作業系統支援 RFC 1323】
Windows 平台：
修改「TcpWindowSize」、「Tcp1323Opts」、「GlobalMaxTcpWindowSize」三個登錄檔數值。
TCP 的效能取決於緩衝器與 RTT(Round Trip Time)。
緩衝區可以協調兩端不同的速度，使兩端的工作可以順利進行。
而 RTT 則影響傳輸的時間。因此 Tcp1323Opts 便是針對緩衝區
與 RTT 而出現的系統參數。此系統參數決定是否要開啟時間戳
記(Timestamps)及視窗伸縮(Window scaling)。
Linux 平台：
/etc/sysctl.conf 加入以下數值，sysctl -p 立即生效！
net.core.rmem_default = 256960
net.core.rmem_max = 256960
net.core.wmem_default = 256960
net.core.wmem_max = 256960
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
這幾天測試下來發現，在 Gigabit Ethernet 的環境，Windows
作業系統，僅需修改「Tcp1323Opts」該項數值，即可解決傳輸緩
慢的問題，且會有明顯的差別，建議若網路環境為 Gigabit Ethernet
請將該數值加入，對於網路會有某種程度的提升。Linux 平台有
文件建議將「tcp_window_scaling」&「tcp_sack」&「tcp_timestamps」
開啟，實測後卻沒有太顯著的效能，Linux TCP/IP 優化的文章
請參考以下內容：
IBM‧提高 Linux 上 socket 性能
sysctl 參數設定
Linux Tweaking
至於為什麼會寫這篇「落落長」的文章，原因只出自於「為什麼
對 A Server 複製資料如此緩慢？」
呼，IT 人員真是辛苦哩。Orz...
Paul
境下，若使用「網路磁碟」模式複製資料會異常的緩慢，切換回
100BASE Ethernet 即恢復正常傳輸速度。
平台：Windows XP 64bit SP2
網卡：Intel 1000 Pro EB、D-Link DGE-530T
【實際狀況】
| 網路磁碟 | 100M NIC | 1G NIC |
| A Server | v | x |
| B Server | v | v |
上圖顯示該牌機器，在「網路磁碟」掛載的狀態下，對 A Server
無法使用 Gigabit 網卡「正常」速度傳輸檔案，若使用 CIFS
格式連線則「沒有」傳輸緩慢的狀況。
若按照以上推斷，應該可以判斷 A Server 的 Samba 可能問題，
不幸的是其他機種(五六種機型)，連結 A Server 完全沒有問題
，怪的是 100BASE 連結 A Server 皆正常。
【測試流程】
1) 重新安裝作業系統，登入網域透過 Samba 測試。(無效)
2) Disable OnBoard NIC，改用 D-Link 測試。(無效)
3) 切換不同網域，連結相同的 Server 測試。(無效)
【解決方法】
這方案是無意間想到的，透過系統優化軟體，針對網路連線優化
修改登錄檔後，即排除以上「網路磁碟複製檔案緩慢」的狀況，
再透過 Regshot 比對優化前後的差別，測出原來在 Gigabit 的
環境下，可透過 RFC 1323 提高 TCP High Performance。
將以下內容複製到筆記本，另存 xxx.reg，執行即可！
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters]
"Tcp1323Opts"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"Tcp1323Opts"=dword:00000001
實測發現，之前發生的狀況只需將該筆 Registry Key 匯入即可
解決此項問題，若各位還有興趣，還有其他網路優化的功能可參
考，詳情如下：
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\VxD\MSTCP]
"NameSrvQueryTimeout"=dword:00000bb8
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VxD\MSTCP]
"NameSrvQueryTimeout"=dword:00000bb8
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters]
"DefaultTTL"=dword:00000080
"EnablePMTUBHDetect"=dword:00000000
"EnablePMTUDiscovery"=dword:00000001
"GlobalMaxTcpWindowSize"=dword:0005ae4c
"TcpMaxDupAcks"=dword:00000002
"SackOpts"=dword:00000001
"Tcp1323Opts"=dword:00000001
"TCPWindowSize"=dword:0005ae4c
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"DefaultTTL"=dword:00000080
"EnablePMTUBHDetect"=dword:00000000
"EnablePMTUDiscovery"=dword:00000001
"GlobalMaxTcpWindowSize"=dword:0005ae4c
"TcpMaxDupAcks"=dword:00000002
"SackOpts"=dword:00000001
"Tcp1323Opts"=dword:00000001
"TCPWindowSize"=dword:0005ae4c
[HKEY_CURRENT_USER\SessionInformation]
"ProgramCount"=dword:00000007
【TCP‧Window Size】
TCP Header (20 Bytes)
複習一下網路概論之前提到 Window Size，此欄位用來控制流量
，表示資料緩衝區的大小，當 TCP Process 啟動時，會同時產
生兩個緩衝區(Buffer)，分別為 Receive buffer & Send buffer
，Receive buffer用來儲存對方傳送過來的資料，並等待上層的
應用層程序提取。Send buffer則是用來儲存準備要送出的資料。
因TCP符合可信賴的傳輸協定，必須確認對方已正確收到資料後，
才可將 Receive buffer 的資料刪除，因此「Window Size」欄位
是用來通知對方目前 Receive buffer 空間大小為何，避免對方
送出 Receive buffer 所能接受的資料量，造成資料流失。
【TCP RFC1323】
透過網路查詢才發現，預設 TCP header 規範的 Windows Size
為 16bits (2^16 = 0~65535 bytes)，當使用高速網路的環境，
則會超過 65535，如此一來，若未使用 TCP Extensions RFC1323
Window scaling 的功能，則會導致傳輸檢核時間變長的狀況。
For a transmission below 1 megabit per second (Mbps), 8 KB.
For a 1-100 Mbps transmission, 17 KB.
For a transmission greater than 100 Mbps, 64 KB.
Note:
For 10 and 100 Mbps Ethernet connections,
the receive window is usually set to 17,520 bytes.
(17 KB rounded up to 12 1460-byte segments).
TCP Receive Window Size and Window Scaling
以上可證明，為什麼在 100BASE 的環境下，Copy 檔案正常，在
Gigabit 的環境會有問題，一開始我也想不通明明 Window Size
只有 16bits 該如何使用超過 65535 bytes 長度的資料？
所幸剛好有網友也碰到相同情形，寫了篇完整的說明，以下內容
部份引述「ccie11440‧TCP window scale option」該篇文章。
原來 RFC 1323 已定義 TCP Window Scale Option 的功能，除
了原有的 16bits 外，還可將 TCP Option 欄位中的 14bits 當
成延伸的 Window Size，因此 TCP Window Size 則可達到 30bits。
2^(16+14) = 1GB (1,073,741,824 bytes)
Wiki‧TCP window scale option
How to Calculate TCP throughput for long distance WAN links
若網路環境還是在 100BASE 的話，則無需修改相關設定值。
【作業系統支援 RFC 1323】
Windows 平台：
修改「TcpWindowSize」、「Tcp1323Opts」、「GlobalMaxTcpWindowSize」三個登錄檔數值。
TCP 的效能取決於緩衝器與 RTT(Round Trip Time)。
緩衝區可以協調兩端不同的速度，使兩端的工作可以順利進行。
而 RTT 則影響傳輸的時間。因此 Tcp1323Opts 便是針對緩衝區
與 RTT 而出現的系統參數。此系統參數決定是否要開啟時間戳
記(Timestamps)及視窗伸縮(Window scaling)。
Linux 平台：
/etc/sysctl.conf 加入以下數值，sysctl -p 立即生效！
net.core.rmem_default = 256960
net.core.rmem_max = 256960
net.core.wmem_default = 256960
net.core.wmem_max = 256960
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
這幾天測試下來發現，在 Gigabit Ethernet 的環境，Windows
作業系統，僅需修改「Tcp1323Opts」該項數值，即可解決傳輸緩
慢的問題，且會有明顯的差別，建議若網路環境為 Gigabit Ethernet
請將該數值加入，對於網路會有某種程度的提升。Linux 平台有
文件建議將「tcp_window_scaling」&「tcp_sack」&「tcp_timestamps」
開啟，實測後卻沒有太顯著的效能，Linux TCP/IP 優化的文章
請參考以下內容：
IBM‧提高 Linux 上 socket 性能
sysctl 參數設定
Linux Tweaking
至於為什麼會寫這篇「落落長」的文章，原因只出自於「為什麼
對 A Server 複製資料如此緩慢？」
呼，IT 人員真是辛苦哩。Orz...
Paul
全站熱搜
留言列表
攝影記事 (6)
