[adron2]

Приветствую.

Есть некий ЦОД в котором крутятся web2.0 приложения. Структура(маршрутизаторы, ОС, серверы) ЦОДа неизвестна. В этот ЦОД клиенты попадают через внутреннюю сеть. Задержка до ЦОДа в среднем 60-100 мсек и 0.5-1% потерь. Клиентская часть(веб страничка) общается с серверами ЦОДа посредством http и использует для этого Ajax. Страницы веб приложений почти не содержат графики и очень мало занимают по объему. Запросы делаются через Ajax в виде JSON-а. аналогично получаются и ответы от сервера(тоже в виде JSON-а).

Проблема в том что это жутко тупит. При нажатии на какой-нибудь кнопке которая отправляет копеечный JSON запрос и получает ответ из 1-2kbait JSON данных можно ждать 30-50 секунд! Или вообще до бесконечности. Иногда запрос проскакивает быстро. Но чаще всего получается жуткий затуп. Причем профилировщик Хромиума показывает что запрос ушел и ожидается ответ...Проблема во всех браузерах. Опера, Хром, Фаерфокс. Операционки: Windows XP, Windows 7.

Методом тыка было выяснено что на Linux-е в качестве клиента такой проблемы нет! Все летает! Запросы проходят мгновенно. Сегодня попробовали поднять проксю(Сквид) на Linux-е и пустить через нее виндовые машины. У них тоже все начало летать. Затыки пропали! То есть проблема где то во внутрях TCP, когда идет соединение с винды на сервера ЦОД-а.

 

Сразу скажу что с MTU проблем нет. Я уже пробовал MSS ужимать и до 1400 и даже до 1000. Так же пингом видно что по 1472 байта пакеты проходят с флагом DF.

 

Попробовал еще у видны сделать netsh int tcp se gl cong=ctcp - не помогло. У Linux-а в качестве tcp congestion control используется cubic а у винды или вообще его нет или ctcp. Может в этом дело?

 

Но все равно непонятно что так криво можно было настроить на стороне ЦОДа чтобы вызвать такой эффект.

 

Может у уважаемого сообщества форумчан есть идеи?

[Ivan_83]

Попробовал еще у видны сделать netsh int tcp se gl cong=ctcp - не помогло. У Linux-а в качестве tcp congestion control используется cubic а у винды или вообще его нет или ctcp. Может в этом дело?

На линухе я попробовал hybla или htcp, ещё посмотреть на различие в опциях и на то как происходят ретрансмиты.

Те то что у вас запрос типа туда ушёл ещё не значит что там его получили.

Крутить на винде СС смысла нет.

[vlad11]

В ЦОД скорее всего используется DPI для экономии канала.

Огласите ASN ЦОД и можно будет поискать, что там у них стоит.

[adron2]

В ЦОД скорее всего используется DPI для экономии канала.

Огласите ASN ЦОД и можно будет поискать, что там у них стоит.

 

К сожалению ЦОД для внутренних нужд и у него используется 10.x.x.x адресация. Из интернета его не видно.

[Tau]

tcpdump/wireshark-ом собирали дамп с win и lin? Ничего подозрительного не заметили?

[adron2]

tcpdump/wireshark-ом собирали дамп с win и lin? Ничего подозрительного не заметили?

 

собирал. много ретрансмитов идет с винды.

[paradox_]

если пинг от точки к точке больше 5 мс, то винда не включает tcp mss scale, соответсвенно скорость будет хреновая

никакие алгосы ничего не поможет, для винды нужно сооружать линукс tcp тунель, линукс кладет болт на время в задержке tcp, и умеет разганять скорость

 

как вариант, устанавливать tcp акселераторы для винды, есть такие в гугле

помогают поднять во много раз стандартную скорость tcp стека в винде, но до гигабита в гигабитной сети конечно недотягивают все равно

Edited November 19, 2015 by paradox_

[adron2]

если пинг от точки к точке больше 5 мс, то винда не включает tcp mss scale, соответсвенно скорость будет хреновая

никакие алгосы ничего не поможет, для винды нужно сооружать линукс tcp тунель, линукс кладет болт на время в задержке tcp, и умеет разганять скорость

 

как вариант, устанавливать tcp акселераторы для винды, есть такие в гугле

помогают поднять во много раз стандартную скорость tcp стека в винде, но до гигабита в гигабитной сети конечно недотягивают все равно

 

у меня проблема не в низкой скорости а именно в затупах при отправке запросов.

[paradox_]

большое количество ретрансмитов и есть та проблема которую я описал

еще есть у винды проблема медленного старта, можно пробовать тюнить, но был еще и какойто патч фикс

[adron2]

большое количество ретрансмитов и есть та проблема которую я описал

еще есть у винды проблема медленного старта, можно пробовать тюнить, но был еще и какойто патч фикс

 

Странно почему тогда в интернете винды нормально работают? Допустим если с винды веб мылом рулить или каким нибудь phpmyadmin-ом то все летает. Для интернета 0.5-1% потерь считай норма. Отличие лишь в том, что работа идет с "нормальным" сервером в интернете а не со "странными" серверами в ЦОДе.

[Ivan_83]

если пинг от точки к точке больше 5 мс, то винда не включает tcp mss scale, соответсвенно скорость будет хреновая никакие алгосы ничего не поможет, для винды нужно сооружать линукс tcp тунель, линукс кладет болт на время в задержке tcp, и умеет разганять скорость

Чушь.

Она не будет его отключать, ей нахер оно не надо, она может уменьшить окно передачи, но скорее всего этим будет заниматся передающая сторона в соответствии с её СС.

Я на семёрке спокойно смотрю SD видео 500-600 килоБайт/сек через 5 часовых поясов с пингом 70-100 мс.

 

собирал. много ретрансмитов идет с винды.

Очень похоже на нехватку mss fix по пути.

А может какой то рейтлимит на коммутаторах...

Можете по пути подебажить с tcpdump чтобы понять в каком месте дропы?

[paradox_]

Ivan как всегда лучше всех знает как работет tcp, только ни одной проблемы никогда не пофиксил?

пойдите в гугл ком, всем расскажите что они ничего не знают :)

а про проблемы винды и скорости все знают

https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

кому интересны ваши 500кб/c ? когда есть гигабит между дц, и винда сливает не разогнав между собой больше 2мбита, при пинге между ними 33 мс

[Ivan_83]

Ivan как всегда лучше всех знает как работет tcp, только ни одной проблемы никогда не пофиксил?

Тупой наезд.

 

пойдите в гугл ком, всем расскажите что они ничего не знают :)

Гугл знает то что знают пользователи, а они нихера не знают.

Крупицы полезной инфы тонут во всяких перепостах шаманских советов.

 

а про проблемы винды и скорости все знают https://www.duckware...eeds/index.html

Впервые слышу.

Знаю что у тупых вебмастеров не хватает мозгов чтобы заюзать htcp/hybla, они сидят на дефолтном cubic/newreno и ваще не в курсе что там творится ибо у них в офисе по локалочке всё супер.

Даже увеличить дефолтные буфера сокетов и прочие советы Сысоева 2007 года и то не могут осилить.

 

кому интересны ваши 500кб/c ? когда есть гигабит между дц, и винда сливает не разогнав между собой больше 2мбита, при пинге между ними 33 мс

Это легко опровергается банальным пидтестом: всегда можно найти пару точек до которых RTT большой а скорость всяко выше 2 мегабит.

С аплоадом история немного другая, но опять же часто дело в настройках сервера а не клиента.

[vlad11]

 

Знаю что у тупых вебмастеров не хватает мозгов чтобы заюзать htcp/hybla, они сидят на дефолтном cubic/newreno и ваще не в курсе что там творится ибо у них в офисе по локалочке всё супер.

 

А что модно юзать при линке 10Gb? Ближайшие ipef3 сервера в радиусе 600км, на них скорость разгоняется до 3,5Гб. На американские сервера iprf3 вообще жопа со скоростью.

 

Кто виноват и как исправить?

[tartila]

Приветствую.

Есть некий ЦОД в котором крутятся web2.0 приложения. Структура(маршрутизаторы, ОС, серверы) ЦОДа неизвестна. В этот ЦОД клиенты попадают через внутреннюю сеть. Задержка до ЦОДа в среднем 60-100 мсек и 0.5-1% потерь. Клиентская часть(веб страничка) общается с серверами ЦОДа посредством http и использует для этого Ajax. Страницы веб приложений почти не содержат графики и очень мало занимают по объему. Запросы делаются через Ajax в виде JSON-а. аналогично получаются и ответы от сервера(тоже в виде JSON-а).

Проблема в том что это жутко тупит. При нажатии на какой-нибудь кнопке которая отправляет копеечный JSON запрос и получает ответ из 1-2kbait JSON данных можно ждать 30-50 секунд! Или вообще до бесконечности. Иногда запрос проскакивает быстро. Но чаще всего получается жуткий затуп. Причем профилировщик Хромиума показывает что запрос ушел и ожидается ответ...Проблема во всех браузерах. Опера, Хром, Фаерфокс. Операционки: Windows XP, Windows 7.

Методом тыка было выяснено что на Linux-е в качестве клиента такой проблемы нет! Все летает! Запросы проходят мгновенно. Сегодня попробовали поднять проксю(Сквид) на Linux-е и пустить через нее виндовые машины. У них тоже все начало летать. Затыки пропали! То есть проблема где то во внутрях TCP, когда идет соединение с винды на сервера ЦОД-а.

 

Сразу скажу что с MTU проблем нет. Я уже пробовал MSS ужимать и до 1400 и даже до 1000. Так же пингом видно что по 1472 байта пакеты проходят с флагом DF.

 

Попробовал еще у видны сделать netsh int tcp se gl cong=ctcp - не помогло. У Linux-а в качестве tcp congestion control используется cubic а у винды или вообще его нет или ctcp. Может в этом дело?

 

Но все равно непонятно что так криво можно было настроить на стороне ЦОДа чтобы вызвать такой эффект.

 

Может у уважаемого сообщества форумчан есть идеи?

 

 

Думаю, что ваша проблема в LargeReceiveOffload (LRO)\GenericSegmentationOffload(GSO). Сетевая карта на Windows пытается собрать большой блок данных без участия CPU/сетевого стека, а в транспорте есть потери. А в LRO есть таймаут на сборку пакета. Таким образом, вы и наблюдаете дикие дропы. Отключите все разгрузки и будет вам счастье.

[Ivan_83]

А что модно юзать при линке 10Gb? Ближайшие ipef3 сервера в радиусе 600км, на них скорость разгоняется до 3,5Гб. На американские сервера iprf3 вообще жопа со скоростью. Кто виноват и как исправить?

Я бы выставил cc=htcp и убедился что опции типа rfc1323 и sack включены на концах.

[tehmeh]

Может там сочетание TCP_NODELAY на винде и delayed ACKs на линухе? : )

http://jvns.ca/blog/2015/11/21/why-you-should-understand-a-little-about-tcp/

[EugeneP]

Вероятно у вас проблема с net.ipv4.tcp_timestamps=1, на стороне линуха.

[vlad11]

А что модно юзать при линке 10Gb? Ближайшие ipef3 сервера в радиусе 600км, на них скорость разгоняется до 3,5Гб. На американские сервера iprf3 вообще жопа со скоростью. Кто виноват и как исправить?

Я бы выставил cc=htcp и убедился что опции типа rfc1323 и sack включены на концах.

 

Переключил cubic на htcp. Посмотрим.

На Centos рекомендуют отключать rp_filter (RFC1812).

[dgan_87]

Может там сочетание TCP_NODELAY на винде и delayed ACKs на линухе? : )

http://jvns.ca/blog/2015/11/21/why-you-should-understand-a-little-about-tcp/

будет сочетаться