Windows TCP Window Scale scaling Cao nguyên quá sớm

Kịch bản: Chúng tôi có một số máy khách Windows thường xuyên tải lên các tệp lớn (FTP / SVN / HTTP PUT / SCP) lên các máy chủ Linux cách đó ~ 100-160ms. Chúng tôi có băng thông đồng bộ 1Gbit / s tại văn phòng và các máy chủ là phiên bản AWS hoặc được lưu trữ vật lý trong các DC của Hoa Kỳ.

Báo cáo ban đầu là việc tải lên một phiên bản máy chủ mới chậm hơn nhiều so với khả năng của chúng. Điều này nhàm chán trong thử nghiệm và từ nhiều địa điểm; khách hàng đã thấy ổn định 2-5Mbit / s đến máy chủ từ hệ thống Windows của họ.

Tôi đã nổ ra iperf -smột ví dụ AWS và sau đó từ một máy khách Windows trong văn phòng:

iperf -c 1.2.3.4

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[  5]  0.0-10.0 sec  6.55 MBytes  5.48 Mbits/sec

iperf -w1M -c 1.2.3.4

[  4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[  4]  0.0-18.3 sec   196 MBytes  89.6 Mbits/sec

Con số thứ hai có thể thay đổi đáng kể trong các thử nghiệm tiếp theo, (Vagaries of AWS) nhưng thường nằm trong khoảng 70 đến 130Mbit / s, quá đủ cho nhu cầu của chúng tôi. Wiresharking phiên, tôi có thể thấy:

• iperf -c Windows SYN - Window 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9 (* 512)
• iperf -c -w1M Windows SYN - Windows 64kb, Tỷ lệ 1 - Linux SYN, ACK: Window 14kb, Tỷ lệ: 9

Rõ ràng liên kết có thể duy trì thông lượng cao này, nhưng tôi phải tự động đặt kích thước cửa sổ để sử dụng nó, điều mà hầu hết các ứng dụng trong thế giới thực sẽ không cho phép tôi làm. Các bắt tay TCP sử dụng cùng một điểm bắt đầu trong mỗi trường hợp, nhưng bắt buộc một thang đo

Ngược lại, từ một máy khách Linux trên cùng một mạng, iperf -c(sử dụng hệ thống mặc định 85kb) mang lại cho tôi:

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[  5]  0.0-10.8 sec   142 MBytes   110 Mbits/sec

Không có bất kỳ sự ép buộc nào, nó có quy mô như mong đợi. Đây không thể là một cái gì đó trong các bước nhảy xen kẽ hoặc các bộ chuyển mạch / bộ định tuyến cục bộ của chúng tôi và dường như ảnh hưởng đến cả máy khách Windows 7 và 8. Tôi đã đọc rất nhiều hướng dẫn về tự động điều chỉnh, nhưng chúng thường là về việc vô hiệu hóa tỷ lệ hoàn toàn để làm việc xung quanh bộ công cụ mạng gia đình tồi tệ.

Bất cứ ai có thể cho tôi biết những gì đang xảy ra ở đây và cho tôi một cách để sửa chữa nó? (Tốt nhất là một cái gì đó tôi có thể dính vào sổ đăng ký thông qua GPO.)

Ghi chú

Ví dụ AWS Linux được đề cập có các cài đặt kernel sau được áp dụng trong sysctl.conf:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

Tôi đã sử dụng dd if=/dev/zero | ncchuyển hướng đến /dev/nullở cuối máy chủ để loại trừ iperfvà loại bỏ bất kỳ tắc nghẽn nào khác có thể xảy ra, nhưng kết quả rất giống nhau. Các thử nghiệm với ncftpquy mô (Cygwin, Windows gốc, Linux) theo cách tương tự như các thử nghiệm iperf ở trên trên các nền tảng tương ứng của chúng.

Biên tập

Tôi đã phát hiện ra một điều phù hợp khác ở đây có thể có liên quan:

Đây là giây đầu tiên của bản chụp 1 MB, được phóng to. Bạn có thể thấy Slow Start hoạt động khi cửa sổ mở rộng và bộ đệm trở nên lớn hơn. Sau đó, cao nguyên nhỏ bé này ~ 0,2s chính xác tại điểm mà cửa sổ mặc định iperf kiểm tra bị san phẳng mãi mãi. Điều này tất nhiên có quy mô đến độ cao chóng mặt hơn nhiều, nhưng điều tò mò là có sự tạm dừng này trong tỷ lệ (Giá trị là 1022byte * 512 = 523264) trước khi thực hiện.

Cập nhật - ngày 30 tháng 6.

Theo dõi các phản ứng khác nhau:

• Kích hoạt CTCP - Điều này không tạo ra sự khác biệt; tỉ lệ cửa sổ là giống hệt nhau. (Nếu tôi hiểu chính xác điều này, cài đặt này sẽ tăng tốc độ mở rộng cửa sổ tắc nghẽn thay vì kích thước tối đa có thể đạt được)
• Kích hoạt dấu thời gian TCP. - Không có thay đổi ở đây.
• Thuật toán của Nagle - Điều đó có ý nghĩa và ít nhất nó có nghĩa là tôi có thể có thể bỏ qua các đốm đặc biệt đó trong biểu đồ như bất kỳ dấu hiệu nào của vấn đề.
• tệp pcap: Tệp zip có sẵn tại đây: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (Được ẩn danh bằng bittwiste, trích xuất ~ 150 MB khi có một từ mỗi máy khách HĐH để so sánh)

Cập nhật ngày 2 - 30 tháng 6

O, vì vậy, theo gợi ý của Kyle, tôi đã kích hoạt ctcp và tắt tải ống khói: Thông số toàn cầu TCP

----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : enabled
Initial RTO                         : 3000
Non Sack Rtt Resiliency             : disabled

Nhưng thật đáng buồn, không có thay đổi trong thông lượng.

Tôi có một câu hỏi về nguyên nhân / hiệu ứng ở đây, mặc dù: Các biểu đồ có giá trị RWIN được đặt trong ACK của máy chủ cho máy khách. Với các máy khách Windows, tôi có đúng không khi nghĩ rằng Linux không mở rộng giá trị này vượt quá điểm thấp đó bởi vì CWIN bị giới hạn của máy khách sẽ ngăn chặn ngay cả bộ đệm đó bị lấp đầy? Có thể có một số lý do khác mà Linux giới hạn một cách giả tạo RWIN?

Lưu ý: Tôi đã thử bật ECN cho địa ngục của nó; Nhưng không có thay đổi, ở đó.

Cập nhật ngày 3 - 31 tháng 6.

Không có thay đổi sau khi vô hiệu hóa heuristic và RWIN autotuning. Đã cập nhật trình điều khiển mạng Intel lên bản mới nhất (12.10.28.0) với phần mềm hiển thị các tinh chỉnh funcioanlity thông qua các tab trình quản lý. Thẻ này là một Chipset 82579V trên bo mạch - (Tôi sẽ thực hiện thêm một số thử nghiệm từ các khách hàng với realtek hoặc các nhà cung cấp khác)

Tập trung vào NIC trong giây lát, tôi đã thử các cách sau (Chủ yếu chỉ loại trừ các thủ phạm không có khả năng):

• Tăng bộ đệm nhận lên 2k từ 256 và truyền bộ đệm lên 2k từ 512 (Cả hai hiện tại tối đa) - Không thay đổi
• Vô hiệu hóa tất cả giảm tải tổng kiểm tra IP / TCP / UDP. - Không thay đổi.
• Vô hiệu hóa Giảm tải lớn - Nada.
• Đã tắt IPv6, lập lịch QoS - Ngay bây giờ.

Cập nhật 3 - 3 tháng 7

Cố gắng loại bỏ phía máy chủ Linux, tôi đã khởi động một phiên bản Server 2012R2 và lặp lại các thử nghiệm bằng cách sử dụng iperf(cygwin binary) và NTttcp .

Với iperf, tôi đã phải xác định rõ ràng -w1mở cả hai bên trước khi kết nối vượt quá ~ 5Mbit / s. (Ngẫu nhiên, tôi có thể được kiểm tra và BDP ~ 5Mbits ở độ trễ 91ms gần như chính xác là 64kb. Phát hiện giới hạn ...)

Các nhị phân ntttcp cho thấy giới hạn như vậy. Sử dụng ntttcpr -m 1,0,1.2.3.5trên máy chủ và ntttcp -s -m 1,0,1.2.3.5 -t 10trên máy khách, tôi có thể thấy thông lượng tốt hơn nhiều:

Copyright Version 5.28
Network activity progressing...


Thread  Time(s) Throughput(KB/s) Avg B / Compl
======  ======= ================ =============
     0    9.990         8155.355     65536.000

#####  Totals:  #####

   Bytes(MEG)    realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
       79.562500      10.001       1442.556            7.955

Throughput(Buffers/s) Cycles/Byte       Buffers
===================== =========== =============
              127.287     308.256      1273.000

DPCs(count/s) Pkts(num/DPC)   Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
     1868.713         0.785        9336.366          0.157

Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
       57833            14664           0      0      9.476

8MB / s đưa nó lên ở mức tôi đã nhận được với các cửa sổ lớn rõ ràng iperf. Mặc dù, kỳ lạ là 80 MB trong bộ đệm 1273 = bộ đệm 64kB một lần nữa. Một dây dẫn tiếp theo cho thấy một RWIN tốt, biến trở lại từ máy chủ (Hệ số tỷ lệ 256) mà máy khách dường như đáp ứng; vì vậy có lẽ ntttcp đang nhập sai cửa sổ gửi.

Cập nhật 4 - 3 tháng 7

Theo yêu cầu của @ karyhead, tôi đã thực hiện thêm một số thử nghiệm và tạo thêm một số ảnh chụp, tại đây: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip

• Hai iperfgiây nữa , cả từ Windows đến cùng một máy chủ Linux như trước (1.2.3.4): Một với kích thước Ổ cắm 128k và cửa sổ 64k mặc định (giới hạn ở ~ 5Mbit / giây một lần nữa) và một với cửa sổ gửi 1 MB và ổ cắm 8kb mặc định kích thước. (thang điểm cao hơn)
• Một ntttcpdấu vết từ cùng một máy khách Windows đến phiên bản Server 2012R2 EC2 (1.2.3.5). ở đây, thông lượng quy mô tốt. Lưu ý: NTttcp thực hiện một số thứ kỳ lạ trên cổng 6001 trước khi mở kết nối thử nghiệm. Không chắc chắn những gì đang xảy ra ở đó.
• Một dấu vết dữ liệu FTP, tải lên 20 MB /dev/urandomđến một máy chủ linux gần giống (1.2.3.6) bằng Cygwin ncftp. Một lần nữa giới hạn là có. Mô hình rất giống nhau khi sử dụng Windows Filezilla.

Thay đổi iperfđộ dài bộ đệm sẽ tạo ra sự khác biệt dự kiến ​​cho biểu đồ trình tự thời gian (nhiều phần dọc hơn nhiều), nhưng thông lượng thực tế không thay đổi.

Bạn đã thử bật Compound TCP (CTCP) trong các máy khách Windows 7/8 chưa.

Xin vui lòng đọc:

Tăng hiệu suất phía người gửi để truyền BDP cao

http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx

...

Các thuật toán này hoạt động tốt cho các BDP nhỏ và kích thước cửa sổ nhận nhỏ hơn. Tuy nhiên, khi bạn có kết nối TCP với kích thước cửa sổ nhận lớn và BDP lớn , chẳng hạn như sao chép dữ liệu giữa hai máy chủ được đặt trên một liên kết WAN tốc độ cao với thời gian khứ hồi 100ms , các thuật toán này không làm tăng cửa sổ gửi đủ nhanh để sử dụng đầy đủ băng thông của kết nối .

Để sử dụng tốt hơn băng thông của các kết nối TCP trong các tình huống này, ngăn xếp TCP / IP thế hệ tiếp theo bao gồm TCP hợp chất (CTCP). CTCP tăng mạnh hơn cửa sổ gửi cho các kết nối có kích thước cửa sổ nhận và BDP lớn . CTCP cố gắng tối đa hóa thông lượng trên các loại kết nối này bằng cách theo dõi các biến thể và tổn thất chậm trễ. Ngoài ra, CTCP đảm bảo rằng hành vi của nó không tác động tiêu cực đến các kết nối TCP khác.

...

CTCP được bật theo mặc định trong các máy tính chạy Windows Server 2008 và bị tắt theo mặc định trong các máy tính chạy Windows Vista. Bạn có thể kích hoạt CTCP bằng netsh interface tcp set global congestionprovider=ctcplệnh. Bạn có thể vô hiệu hóa CTCP bằng netsh interface tcp set global congestionprovider=nonelệnh.

Chỉnh sửa ngày 30 tháng 6 năm 2014

để xem CTCP có thực sự "bật" không

> netsh int tcp show global

I E

PO nói:

Nếu tôi hiểu chính xác, cài đặt này sẽ tăng tốc độ mở rộng cửa sổ tắc nghẽn thay vì kích thước tối đa có thể đạt được

CTCP tăng mạnh cửa sổ gửi

http://technet.microsoft.com/en-us/l Library / bb878127.aspx

TCP hợp chất

Các thuật toán hiện có ngăn chặn việc gửi ngang hàng TCP tràn ngập mạng được gọi là khởi động chậm và tránh tắc nghẽn. Các thuật toán này làm tăng số lượng phân đoạn mà người gửi có thể gửi, được gọi là cửa sổ gửi, khi ban đầu gửi dữ liệu trên kết nối và khi khôi phục từ một phân đoạn bị mất. Khởi động chậm làm tăng cửa sổ gửi bởi một phân đoạn TCP đầy đủ cho từng phân đoạn xác nhận đã nhận (đối với TCP trong Windows XP và Windows Server 2003) hoặc cho từng phân đoạn được thừa nhận (đối với TCP trong Windows Vista và Windows Server 2008). Tránh tắc nghẽn làm tăng cửa sổ gửi bởi một phân đoạn TCP đầy đủ cho mỗi cửa sổ dữ liệu đầy đủ được xác nhận.

Các thuật toán này hoạt động tốt cho tốc độ phương tiện LAN và kích thước cửa sổ TCP nhỏ hơn. Tuy nhiên, khi bạn có kết nối TCP với kích thước cửa sổ nhận lớn và sản phẩm có độ trễ băng thông lớn (băng thông cao và độ trễ cao), chẳng hạn như sao chép dữ liệu giữa hai máy chủ được đặt trên một liên kết WAN tốc độ cao với chuyến đi vòng 100 ms thời gian, các thuật toán này không tăng cửa sổ gửi đủ nhanh để sử dụng đầy đủ băng thông của kết nối. Ví dụ: trên liên kết WAN 1 Gigabit mỗi giây (Gbps) với thời gian khứ hồi 100 ms (RTT), có thể mất đến một giờ để cửa sổ gửi ban đầu tăng lên kích thước cửa sổ lớn được người nhận quảng cáo và để phục hồi khi có những đoạn bị mất.

Để sử dụng tốt hơn băng thông của các kết nối TCP trong các tình huống này, ngăn xếp TCP / IP thế hệ tiếp theo bao gồm TCP hợp chất (CTCP). CTCP tăng mạnh hơn cửa sổ gửi cho các kết nối có kích thước cửa sổ nhận lớn và các sản phẩm trễ băng thông lớn. CTCP cố gắng tối đa hóa thông lượng trên các loại kết nối này bằng cách theo dõi các biến thể và tổn thất chậm trễ . CTCP cũng đảm bảo rằng hành vi của nó không ảnh hưởng tiêu cực đến các kết nối TCP khác.

Trong thử nghiệm được thực hiện nội bộ tại Microsoft, thời gian sao lưu tệp lớn đã giảm gần một nửa cho kết nối 1 Gbps với RTT 50ms. Các kết nối với một sản phẩm trễ băng thông lớn hơn có thể có hiệu suất thậm chí tốt hơn. CTCP và Cửa sổ nhận tự động Điều chỉnh cùng nhau để tăng mức độ sử dụng liên kết và có thể dẫn đến tăng hiệu suất đáng kể cho các kết nối sản phẩm có độ trễ băng thông lớn.

Làm rõ vấn đề:

TCP có hai cửa sổ:

• Cửa sổ nhận: Có bao nhiêu byte còn lại trong bộ đệm. Đây là kiểm soát dòng chảy áp đặt bởi người nhận. Bạn có thể thấy kích thước của cửa sổ nhận trong wireshark vì nó được tạo thành từ kích thước cửa sổ và hệ số tỷ lệ cửa sổ bên trong tiêu đề TCP. Cả hai mặt của kết nối TCP sẽ quảng cáo cửa sổ nhận của họ, nhưng nhìn chung, cửa sổ bạn quan tâm là cửa sổ nhận được phần lớn dữ liệu. Trong trường hợp của bạn, đó là "máy chủ" vì máy khách đang tải lên máy chủ
• Cửa sổ tắc nghẽn. Đây là kiểm soát dòng được áp đặt bởi Người gửi. Điều này được duy trì bởi hệ điều hành và không hiển thị trong tiêu đề TCP. Nó kiểm soát tốc độ dữ liệu sẽ được gửi nhanh như thế nào.

Trong tập tin chụp bạn cung cấp. Chúng ta có thể thấy rằng bộ đệm nhận không bao giờ bị tràn:

Phân tích của tôi là người gửi không gửi đủ nhanh vì cửa sổ gửi (còn gọi là cửa sổ điều khiển tắc nghẽn) không mở đủ để đáp ứng RWIN của người nhận. Vì vậy, trong ngắn hạn, người nhận nói "Hãy cho tôi thêm" và khi Windows là người gửi, nó không gửi đủ nhanh.

Điều này được chứng minh bằng thực tế là trong biểu đồ trên, RWIN vẫn mở và với thời gian khứ hồi là 0,09 giây và RWIN là ~ 500.000 byte, chúng ta có thể mong đợi thông lượng tối đa theo sản phẩm trễ băng thông là (500000 / 0,09) * 8 = ~ 42 Mbit / s (và bạn chỉ nhận được khoảng ~ 5 trong chiến thắng để nắm bắt Linux).

Làm thế nào để khắc phục nó?

Tôi không biết. interface tcp set global congestionprovider=ctcpNghe có vẻ đúng với tôi vì nó sẽ làm tăng cửa sổ gửi (là một thuật ngữ khác cho cửa sổ tắc nghẽn). Bạn nói rằng nó không hoạt động. Vì vậy, chỉ để đảm bảo:

1. Bạn đã khởi động lại sau khi kích hoạt điều này?
2. Là ống khói giảm tải trên? Nếu có thể hãy thử tắt nó đi như một thử nghiệm. Tôi không biết chính xác những gì được giảm tải khi điều này được kích hoạt, nhưng nếu việc kiểm soát cửa sổ gửi là một trong số đó, có thể tắc nghẽn không có tác dụng khi điều này được bật ... Tôi chỉ đoán ...
3. Ngoài ra, tôi nghĩ rằng đây có thể là windows 7 trước, nhưng bạn có thể thử thêm và chơi với hai khóa đăng ký có tên là DefaultSendWindow và DefaultReceiveWindow trong HKEY_LOCAL_MACHINE-System-CurrentControlset-Services-AFD-Paramameter. Nếu những cái này thậm chí hoạt động, có lẽ bạn đã bị tắt ctcp.
4. Còn một phỏng đoán nữa, hãy thử kiểm tra netsh interface tcp show heuristics. Tôi nghĩ rằng đó có thể là RWIN, nhưng nó không nói, vì vậy có thể chơi với việc vô hiệu hóa / cho phép trong trường hợp nó tác động đến cửa sổ gửi.
5. Ngoài ra, đảm bảo trình điều khiển của bạn được cập nhật trên máy khách thử nghiệm của bạn. Có lẽ một cái gì đó chỉ bị hỏng.

Tôi sẽ thử tất cả các thử nghiệm này với tất cả các tính năng giảm tải của bạn để bắt đầu để loại trừ khả năng các trình điều khiển mạng đang thực hiện một số thao tác viết lại / sửa đổi mọi thứ (giữ CPU mắt trong khi tắt tải bị tắt). Các TCP_OFFLOAD_STATE_DELEGATED struct dường như ít nhất ngụ ý rằng CWnd giảm tải là ít nhất có thể.

Có một số thông tin tuyệt vời ở đây bởi @Pat và @Kyle. Chắc chắn chú ý đến lời giải thích của @ Kyle về việc nhận và gửi các cửa sổ TCP, tôi nghĩ đã có một số nhầm lẫn xung quanh vấn đề đó. Để gây nhầm lẫn hơn nữa, iperf sử dụng thuật ngữ "cửa sổ TCP" với -wcài đặt là một thuật ngữ mơ hồ liên quan đến cửa sổ nhận, gửi hoặc trượt tổng thể. Những gì nó thực sự làm là đặt bộ đệm gửi socket cho thể hiện -c(client) và bộ đệm nhận socket trên thể hiện -s(server). Trong src/tcp_window_size.c:

if ( !inSend ) {
    /* receive buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_RCVBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
} else {
    /* send buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_SNDBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
}

Như Kyle đề cập, vấn đề không nằm ở cửa sổ nhận trên hộp Linux, nhưng người gửi không mở đủ cửa sổ gửi. Không phải là nó không mở đủ nhanh, nó chỉ giới hạn ở mức 64k.

Kích thước bộ đệm ổ cắm mặc định trên Windows 7 là 64k. Dưới đây là những gì tài liệu nói về kích thước bộ đệm ổ cắm liên quan đến thông lượng tại MSDN

Khi gửi dữ liệu qua kết nối TCP bằng cách sử dụng ổ cắm Windows, điều quan trọng là phải giữ đủ lượng dữ liệu chưa xử lý (đã gửi nhưng chưa được xác nhận) trong TCP để đạt được thông lượng cao nhất. Giá trị lý tưởng cho lượng dữ liệu chưa xử lý để đạt được thông lượng tốt nhất cho kết nối TCP được gọi là kích thước gửi tồn đọng (ISB) lý tưởng. Giá trị ISB là một chức năng của sản phẩm trì hoãn băng thông của kết nối TCP và cửa sổ nhận được quảng cáo của người nhận (và một phần là lượng tắc nghẽn trong mạng).

Ok, blah blah blah, Bây giờ chúng ta đi:

Các ứng dụng thực hiện một yêu cầu gửi chặn hoặc không chặn tại một thời điểm thường dựa vào bộ đệm gửi nội bộ của Winsock để đạt được thông lượng tốt. Giới hạn bộ đệm gửi cho một kết nối nhất định được kiểm soát bởi tùy chọn ổ cắm SO_SNDBUF. Đối với phương thức gửi chặn và không chặn, giới hạn bộ đệm gửi xác định lượng dữ liệu được giữ trong TCP . Nếu giá trị ISB cho kết nối lớn hơn giới hạn bộ đệm gửi, thì thông lượng đạt được trên kết nối sẽ không tối ưu.

Thông lượng trung bình của thử nghiệm iperf gần đây nhất của bạn bằng cửa sổ 64k là 5,8Mb / giây. Đó là từ Thống kê> Tóm tắt trong Wireshark, tính tất cả các bit. Có khả năng, iperf đang đếm thông lượng dữ liệu TCP là 5,7Mb / giây. Chúng tôi cũng thấy hiệu suất tương tự với thử nghiệm FTP, ~ 5.6Mbps.

Thông lượng lý thuyết với bộ đệm gửi 64k và RTT 91ms là .... 5,5Mbps. Đủ gần cho tôi

Nếu chúng tôi xem xét kiểm tra iperf cửa sổ 1 MB của bạn, thì thông số là 88,2Mbps (86,2Mbps cho chỉ dữ liệu TCP). Thông số lý thuyết với cửa sổ 1MB là 87,9Mbps. Một lần nữa, đủ gần cho công việc của chính phủ.

Điều này chứng tỏ rằng bộ đệm ổ cắm gửi trực tiếp điều khiển cửa sổ gửi và rằng, cùng với cửa sổ nhận từ phía bên kia, điều khiển thông lượng. Cửa sổ nhận được quảng cáo có chỗ, vì vậy chúng tôi không bị giới hạn bởi người nhận.

Giữ lên, những gì về kinh doanh tự động này? Windows 7 không tự động xử lý những thứ đó sao? Như đã đề cập, Windows cũng xử lý tự động mở rộng cửa sổ nhận, nhưng nó cũng có thể tự động xử lý bộ đệm gửi. Hãy quay lại trang MSDN:

Bộ đệm gửi động cho TCP đã được thêm vào Windows 7 và Windows Server 2008 R2. Theo mặc định, bộ đệm gửi động cho TCP được bật trừ khi ứng dụng đặt tùy chọn ổ cắm SO_SNDBUF trên ổ cắm luồng.

iperf sử dụng SO_SNDBUFkhi sử dụng -wtùy chọn, vì vậy bộ đệm gửi động sẽ bị tắt. Tuy nhiên, nếu bạn không sử dụng -wthì nó không sử dụng SO_SNDBUF. Bộ đệm gửi động phải được bật theo mặc định, nhưng bạn có thể kiểm tra:

netsh winsock show autotuning

Tài liệu nói rằng bạn có thể vô hiệu hóa nó với:

netsh winsock set autotuning off

Nhưng điều đó không làm việc cho tôi. Tôi đã phải thực hiện thay đổi sổ đăng ký và đặt giá trị này thành 0:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DynamicSendBufferDisable

Tôi không nghĩ việc vô hiệu hóa điều này sẽ giúp ích; nó chỉ là một FYI.

Tại sao bộ đệm gửi của bạn không mở rộng trên 64k mặc định khi gửi dữ liệu tới hộp Linux có nhiều chỗ trong cửa sổ nhận? Câu hỏi tuyệt vời. Các hạt nhân Linux cũng có một ngăn xếp TCP tự động. Giống như T-Pain và Kanye thực hiện một bản song ca tự động cùng nhau, điều đó nghe có vẻ không hay. Có lẽ có một số vấn đề với hai ngăn xếp TCP tự động nói chuyện với nhau.

Một người khác gặp vấn đề giống như bạn và có thể khắc phục bằng chỉnh sửa sổ đăng ký để tăng kích thước bộ đệm gửi mặc định. Thật không may, điều đó dường như không còn hoạt động nữa, ít nhất là nó đã không cho tôi khi tôi thử nó.

Tại thời điểm này, tôi nghĩ rõ ràng yếu tố giới hạn là kích thước bộ đệm gửi trên máy chủ Windows. Cho rằng nó dường như không phát triển linh hoạt đúng cách, một cô gái phải làm gì?

Bạn có thể:

• Sử dụng các ứng dụng cho phép bạn đặt tùy chọn gửi bộ đệm tức là cửa sổ
• Sử dụng proxy Linux cục bộ
• Sử dụng proxy Windows từ xa?
• Mở một vụ án với microsofhahahahahahaha
• Bia

Tuyên bố miễn trừ trách nhiệm: Tôi đã dành nhiều giờ để nghiên cứu vấn đề này và nó đúng với kiến ​​thức tốt nhất của tôi và google-fu. Nhưng tôi sẽ không thề trên mộ của mẹ tôi (cô ấy vẫn còn sống).

Khi bạn đã điều chỉnh ngăn xếp TCP, bạn vẫn có thể có một nút cổ chai trong lớp Winsock. Tôi đã thấy rằng việc định cấu hình Winsock (Trình điều khiển chức năng phụ trợ trong sổ đăng ký) tạo ra sự khác biệt lớn về tốc độ tải lên (đẩy dữ liệu lên máy chủ) trong Windows 7. Microsoft đã thừa nhận một lỗi trong tự động TCP cho ổ cắm không chặn - chỉ là loại ổ cắm mà trình duyệt sử dụng ;-)

Thêm khóa DWORD cho DefaultSendWindow và đặt nó thành BDP trở lên. Tôi đang sử dụng 256000.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters\DefaultSendWindow

Thay đổi cài đặt Winsock để tải xuống có thể giúp ích - thêm khóa cho DefaultReceiveWindow.

Bạn có thể thử nghiệm với các cài đặt cấp độ ổ cắm khác nhau bằng cách sử dụng Proxy Fiddler và các lệnh để điều chỉnh kích thước bộ đệm ổ cắm máy khách và máy chủ:

prefs set fiddler.network.sockets.Server_SO_SNDBUF 65536 

fiddler.network.sockets.Client_SO_SNDBUF
fiddler.network.sockets.Client_SO_RCVBUF
fiddler.network.sockets.Server_SO_SNDBUF
fiddler.network.sockets.Server_SO_RCVBUF

Đã đọc tất cả các phân tích trong các câu trả lời, vấn đề này nghe có vẻ như bạn đang chạy Windows7 / 2008R2 hay còn gọi là Windows 6.1

Ngăn xếp mạng (TCP / IP & Winsock) trong Windows 6.1 đã bị lỗi một cách khủng khiếp và có một loạt các lỗi và vấn đề về hiệu năng mà Microsoft cuối cùng đã giải quyết trong nhiều năm về bản sửa lỗi kể từ phiên bản 6.1 đầu tiên.

Cách tốt nhất để áp dụng các hotfix này là sàng lọc thủ công tất cả các trang có liên quan trên support.microsoft.com và yêu cầu và tải xuống các phiên bản LDR của các hotfix của ngăn xếp mạng (có rất nhiều hàng chục trong số này).

Để tìm các hotfix có liên quan, bạn phải sử dụng www.bing.com với truy vấn tìm kiếm sau site:support.microsoft.com 6.1.7601 tcpip.sys

Bạn cũng cần hiểu cách các chuỗi hotfix LDR / GDR hoạt động trong Windows 6.1

Tôi thường sử dụng để duy trì danh sách các bản sửa lỗi LDR của riêng tôi (không chỉ các bản sửa lỗi ngăn xếp mạng) cho Windows 6.1 và sau đó chủ động áp dụng các bản sửa lỗi này cho bất kỳ máy chủ / máy khách Windows 6.1 nào tôi gặp. Việc thường xuyên kiểm tra các hotfix LDR mới là một nhiệm vụ rất tốn thời gian.

May mắn thay, Microsoft đã ngừng thực hành các hotfix LDR với các phiên bản hệ điều hành mới hơn và các lỗi sửa lỗi hiện có sẵn thông qua các dịch vụ cập nhật tự động từ Microsoft.

CẬP NHẬT : Chỉ là một ví dụ về nhiều lỗi mạng trong Windows7SP1 - https://support.microsoft.com/en-us/kb/2675785

CẬP NHẬT 2 : Đây là một hotfix khác có thêm công tắc Netsh để buộc chia tỷ lệ Window sau khi truyền lại lần thứ hai của gói SYN (theo mặc định, tỷ lệ cửa sổ bị vô hiệu hóa sau khi 2 gói SYN được truyền lại) https://support.microsoft.com/en- chúng tôi / kb / 2780879

Tôi thấy đây là một bài viết cũ hơn một chút nhưng nó có thể giúp đỡ người khác.

Nói tóm lại, bạn phải bật "Nhận cửa sổ tự động điều chỉnh":

netsh int tcp set global autotuninglevel=normal

CTCP có nghĩa là không có gì mà không kích hoạt ở trên.

Nếu bạn tắt "Nhận cửa sổ tự động điều chỉnh", bạn sẽ bị kẹt ở kích thước gói 64KB, có tác động tiêu cực đến RTT dài trong các kết nối băng thông rộng. Bạn cũng có thể thử nghiệm với tùy chọn "bị hạn chế" và "bị hạn chế".

Tài liệu tham khảo rất tốt: https://www.duckware.com/blog/how-windows-is-killing-iNET-doad-speed/index.html

Tôi đã gặp một vấn đề tương tự với Windows Client (Windows 7). Tôi đã trải qua hầu hết các gỡ lỗi mà bạn đã trải qua, vô hiệu hóa thuật toán Nagle, Giảm tải ống khói TCP và hàng tấn thay đổi cài đặt liên quan đến TCP khác. Không ai trong số họ có bất kỳ ảnh hưởng.

Điều cuối cùng đã sửa nó cho tôi là sửa đổi cửa sổ gửi mặc định trong sổ đăng ký dịch vụ AFD. Vấn đề dường như có liên quan đến tệp afd.sys. Tôi đã thử nghiệm một số khách hàng, một số triển lãm tải lên chậm và một số thì không, nhưng tất cả đều là máy Windows 7. Các máy thể hiện hành vi chậm có cùng phiên bản AFD.sys. Cách giải quyết đăng ký là cần thiết cho các máy tính có phiên bản nhất định của AFD.sys (xin lỗi, không nhớ lại phiên bản # 's).

HKLM \ CurrentControlset \ Services \ AFD \ Tham số

Thêm - DWORD - DefaultSendWindow

Giá trị - Số thập phân - 1640960

Giá trị đó là thứ tôi tìm thấy ở đây: https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-

Tôi nghĩ để sử dụng giá trị phù hợp, bạn nên tự tính toán nó bằng cách sử dụng:

ví dụ. Tải lên được quảng cáo: 15 Mbps = 15.000 Kb / giây

(15000/8) * 1024 = 1920000

Theo những gì tôi hiểu, phần mềm máy khách thường sẽ ghi đè cài đặt này trong sổ đăng ký, nhưng nếu không, giá trị mặc định sẽ được sử dụng và rõ ràng giá trị mặc định rất thấp trong một số phiên bản của tệp AFD.sys.

Tôi nhận thấy rằng hầu hết các sản phẩm MS có vấn đề tải lên chậm (IE, Mini-redirector (WebDAV), FTP thông qua Windows Explorer, v.v.) Khi sử dụng phần mềm của bên thứ 3 (ví dụ: Filezilla) tôi không gặp sự cố chậm .

AFD.sys ảnh hưởng đến tất cả các kết nối Winsock, vì vậy cách khắc phục này nên áp dụng cho FTP, HTTP, HTTPS, v.v ...

Ngoài ra, bản sửa lỗi này cũng được liệt kê ở trên ở đâu đó, vì vậy tôi không muốn lấy tín dụng cho nó nếu nó hiệu quả với bất kỳ ai, tuy nhiên có rất nhiều thông tin trong chủ đề này đến nỗi tôi sợ rằng nó có thể bị che đậy.

Chà, bản thân tôi đã gặp phải một tình huống tương tự (câu hỏi của tôi ở đây ) và cuối cùng tôi đã phải vô hiệu hóa các heuristic mở rộng TCP, tự đặt cấu hình tự động dò và kích hoạt CTCP:

# disable heuristics
C:\Windows\system32>netsh interface tcp set heuristics wsh=disabled
Ok.

# enable receive-side scaling
C:\Windows\system32>netsh int tcp set global rss=enabled
Ok.

# manually set autotuning profile
C:\Windows\system32>netsh interface tcp set global autotuning=experimental
Ok. 

# set congestion provider
C:\Windows\system32>netsh interface tcp set global congestionprovider=ctcp
Ok. 

Tôi không có đủ điểm để bình luận, vì vậy tôi sẽ đăng "câu trả lời" thay thế. Tôi đang gặp phải vấn đề tương tự / giống hệt nhau (xem câu hỏi về serverfault tại đây ). Vấn đề của tôi (và có lẽ là của bạn) là bộ đệm gửi của máy khách iperf trên windows. Nó không phát triển quá 64 KB. Windows được cho là sẽ tự động phát triển bộ đệm khi nó không có kích thước rõ ràng theo quy trình. Nhưng sự tăng trưởng năng động đó không xảy ra.

Tôi không chắc chắn về biểu đồ tỷ lệ cửa sổ của bạn cho thấy cửa sổ mở tối đa 500.000 byte cho trường hợp Windows "chậm" của bạn. Tôi dự kiến ​​sẽ thấy rằng biểu đồ mở chỉ ~ 64.000 byte cho rằng bạn bị giới hạn ở mức 5 Mb / giây.

Đây là một chủ đề hấp dẫn và phù hợp chính xác với các vấn đề tôi đã sử dụng Win7 / iperf để kiểm tra thông lượng trên các ống mỡ dài.

Giải pháp cho Windows 7 là thực thi lệnh sau trên cả máy chủ iperf VÀ máy khách.

Giao diện Netsh tcp thiết lập autotuninglevel toàn cầu = thử nghiệm

NB: Trước khi bạn làm điều này, hãy chắc chắn ghi lại trạng thái hiện tại của tự động dò tìm:

Giao diện Netsh tcp hiển thị toàn cầu

Nhận Cửa sổ Tự động Điều chỉnh Cấp độ: bị vô hiệu hóa

Sau đó chạy máy chủ / máy khách iperf ở mỗi đầu của đường ống.

Đặt lại giá trị tự động dò theo các thử nghiệm của bạn:

Giao diện Netsh tcp thiết lập autotuninglevel toàn cầu =

   autotuninglevel - One of the following values:
                     disabled: Fix the receive window at its default
                         value.
                     highlyrestricted: Allow the receive window to
                         grow beyond its default value, but do so
                         very conservatively.
                     restricted: Allow the receive window to grow
                         beyond its default value, but limit such
                         growth in some scenarios.
                     normal: Allow the receive window to grow to
                         accomodate almost all scenarios.
                     experimental: Allow the receive window to grow
                         to accomodate extreme scenarios.