Перейти к содержимому
Калькуляторы

затыки в tcp из под винды

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

Есть некий ЦОД в котором крутятся 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. Может в этом дело?

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Изменено пользователем paradox_

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Чушь.

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

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

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Тупой наезд.

 

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

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

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

 

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

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Есть некий ЦОД в котором крутятся 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 есть таймаут на сборку пакета. Таким образом, вы и наблюдаете дикие дропы. Отключите все разгрузки и будет вам счастье.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.