У нас возникают некоторые проблемы с несколькими клиентами, работающими под управлением Windows 10, загружающими файлы с нашего сервера доставки файлов HTTP.
Мы не можем воспроизвести ошибку со своей стороны, но заметим, что масштабирование окна TCP не «нарастает» и пропускная способность между сервером Linux и клиентом Windows 10 остается низкой.
Мы запустили TCPDUMP на сервере, захватывающем пакеты от клиента, и видим небольшой размер окна:
Пример:
00:00:00.321292 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:564401}], length 0
00:00:00.321348 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:565761}], length 0
00:00:00.321359 IP 195.224.144.66.80 > 85.144.19.44.58799: Flags [.], seq 590241:591601, ack 702, win 30, length 1360: HTTP
00:00:00.322417 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:572561}], length 0
00:00:00.322482 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:573921}], length 0
00:00:00.322497 IP 195.224.144.66.80 > 85.144.19.44.58799: Flags [.], seq 595681:597041, ack 702, win 30, length 1360: HTTP
00:00:00.322528 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:575281}], length 0
00:00:00.322559 IP 195.224.144.66.80 > 85.144.19.44.58799: Flags [.], seq 597041:598401, ack 702, win 30, length 1360: HTTP
00:00:00.322570 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:576641}], length 0
00:00:00.322983 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:578001}], length 0
00:00:00.323007 IP 195.224.144.66.80 > 85.144.19.44.58799: Flags [.], seq 598401:599761, ack 702, win 30, length 1360: HTTP
00:00:00.323015 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:579361}], length 0
00:00:00.323026 IP 195.224.144.66.80 > 85.144.19.44.58799: Flags [.], seq 599761:601121, ack 702, win 30, length 1360: HTTP
00:00:00.323268 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 587521, win 1025, length 0
00:00:00.332204 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 591601, win 1025, length 0
00:00:00.332242 IP 195.224.144.66.80 > 85.144.19.44.58799: Flags [.], seq 606561:609281, ack 702, win 30, length 2720: HTTP
Обратите внимание на небольшой размер окна (1025).
Мы протестировали пропускную способность клиента Windows 10, используя другой сервер в нашей сети (macOS), и можем получить полную пропускную способность вместе с увеличенными размерами окна масштабирования, поэтому проблема, похоже, специфична для этого сервера Linux.
Мы внесли некоторые изменения в сетевой стек на этом конкретном сервере Linux, который мы включили в sysctl.conf:
kernel.panic = 3
net.core.somaxconn = 1024
net.ipv4.tcp_ecn = 0
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_mtu_probing = 1
vm.swappiness = 1
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv6.route.flush = 1
Есть ли у кого-нибудь идеи относительно того, почему Windows 10 не может согласовывать лучшие размеры окон TCP с нашей машиной Linux? Это не проблема промежуточных ящиков, как указано выше, мы можем достичь полной пропускной способности, протестировав другой сервер в нашей сети доставки. Это просто конкретная машина.
Любые мысли, отзывы, советы и советы приветствуются заранее.
Большое спасибо.