adron2 Posted November 18, 2015 · Report post Приветствую. Есть некий ЦОД в котором крутятся 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. Может в этом дело? Но все равно непонятно что так криво можно было настроить на стороне ЦОДа чтобы вызвать такой эффект. Может у уважаемого сообщества форумчан есть идеи? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted November 18, 2015 · Report post Попробовал еще у видны сделать netsh int tcp se gl cong=ctcp - не помогло. У Linux-а в качестве tcp congestion control используется cubic а у винды или вообще его нет или ctcp. Может в этом дело? На линухе я попробовал hybla или htcp, ещё посмотреть на различие в опциях и на то как происходят ретрансмиты. Те то что у вас запрос типа туда ушёл ещё не значит что там его получили. Крутить на винде СС смысла нет. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vlad11 Posted November 18, 2015 · Report post В ЦОД скорее всего используется DPI для экономии канала. Огласите ASN ЦОД и можно будет поискать, что там у них стоит. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
adron2 Posted November 18, 2015 · Report post В ЦОД скорее всего используется DPI для экономии канала. Огласите ASN ЦОД и можно будет поискать, что там у них стоит. К сожалению ЦОД для внутренних нужд и у него используется 10.x.x.x адресация. Из интернета его не видно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Tau Posted November 19, 2015 · Report post tcpdump/wireshark-ом собирали дамп с win и lin? Ничего подозрительного не заметили? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
adron2 Posted November 19, 2015 · Report post tcpdump/wireshark-ом собирали дамп с win и lin? Ничего подозрительного не заметили? собирал. много ретрансмитов идет с винды. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
paradox_ Posted November 19, 2015 (edited) · Report post если пинг от точки к точке больше 5 мс, то винда не включает tcp mss scale, соответсвенно скорость будет хреновая никакие алгосы ничего не поможет, для винды нужно сооружать линукс tcp тунель, линукс кладет болт на время в задержке tcp, и умеет разганять скорость как вариант, устанавливать tcp акселераторы для винды, есть такие в гугле помогают поднять во много раз стандартную скорость tcp стека в винде, но до гигабита в гигабитной сети конечно недотягивают все равно Edited November 19, 2015 by paradox_ Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
adron2 Posted November 19, 2015 · Report post если пинг от точки к точке больше 5 мс, то винда не включает tcp mss scale, соответсвенно скорость будет хреновая никакие алгосы ничего не поможет, для винды нужно сооружать линукс tcp тунель, линукс кладет болт на время в задержке tcp, и умеет разганять скорость как вариант, устанавливать tcp акселераторы для винды, есть такие в гугле помогают поднять во много раз стандартную скорость tcp стека в винде, но до гигабита в гигабитной сети конечно недотягивают все равно у меня проблема не в низкой скорости а именно в затупах при отправке запросов. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
paradox_ Posted November 19, 2015 · Report post большое количество ретрансмитов и есть та проблема которую я описал еще есть у винды проблема медленного старта, можно пробовать тюнить, но был еще и какойто патч фикс Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
adron2 Posted November 19, 2015 · Report post большое количество ретрансмитов и есть та проблема которую я описал еще есть у винды проблема медленного старта, можно пробовать тюнить, но был еще и какойто патч фикс Странно почему тогда в интернете винды нормально работают? Допустим если с винды веб мылом рулить или каким нибудь phpmyadmin-ом то все летает. Для интернета 0.5-1% потерь считай норма. Отличие лишь в том, что работа идет с "нормальным" сервером в интернете а не со "странными" серверами в ЦОДе. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted November 19, 2015 · Report post если пинг от точки к точке больше 5 мс, то винда не включает tcp mss scale, соответсвенно скорость будет хреновая никакие алгосы ничего не поможет, для винды нужно сооружать линукс tcp тунель, линукс кладет болт на время в задержке tcp, и умеет разганять скорость Чушь. Она не будет его отключать, ей нахер оно не надо, она может уменьшить окно передачи, но скорее всего этим будет заниматся передающая сторона в соответствии с её СС. Я на семёрке спокойно смотрю SD видео 500-600 килоБайт/сек через 5 часовых поясов с пингом 70-100 мс. собирал. много ретрансмитов идет с винды. Очень похоже на нехватку mss fix по пути. А может какой то рейтлимит на коммутаторах... Можете по пути подебажить с tcpdump чтобы понять в каком месте дропы? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
paradox_ Posted November 19, 2015 · Report post Ivan как всегда лучше всех знает как работет tcp, только ни одной проблемы никогда не пофиксил? пойдите в гугл ком, всем расскажите что они ничего не знают :) а про проблемы винды и скорости все знают https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html кому интересны ваши 500кб/c ? когда есть гигабит между дц, и винда сливает не разогнав между собой больше 2мбита, при пинге между ними 33 мс Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted November 20, 2015 · Report post Ivan как всегда лучше всех знает как работет tcp, только ни одной проблемы никогда не пофиксил? Тупой наезд. пойдите в гугл ком, всем расскажите что они ничего не знают :) Гугл знает то что знают пользователи, а они нихера не знают. Крупицы полезной инфы тонут во всяких перепостах шаманских советов. а про проблемы винды и скорости все знают https://www.duckware...eeds/index.html Впервые слышу. Знаю что у тупых вебмастеров не хватает мозгов чтобы заюзать htcp/hybla, они сидят на дефолтном cubic/newreno и ваще не в курсе что там творится ибо у них в офисе по локалочке всё супер. Даже увеличить дефолтные буфера сокетов и прочие советы Сысоева 2007 года и то не могут осилить. кому интересны ваши 500кб/c ? когда есть гигабит между дц, и винда сливает не разогнав между собой больше 2мбита, при пинге между ними 33 мс Это легко опровергается банальным пидтестом: всегда можно найти пару точек до которых RTT большой а скорость всяко выше 2 мегабит. С аплоадом история немного другая, но опять же часто дело в настройках сервера а не клиента. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vlad11 Posted November 22, 2015 · Report post Знаю что у тупых вебмастеров не хватает мозгов чтобы заюзать htcp/hybla, они сидят на дефолтном cubic/newreno и ваще не в курсе что там творится ибо у них в офисе по локалочке всё супер. А что модно юзать при линке 10Gb? Ближайшие ipef3 сервера в радиусе 600км, на них скорость разгоняется до 3,5Гб. На американские сервера iprf3 вообще жопа со скоростью. Кто виноват и как исправить? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tartila Posted November 22, 2015 · Report post Приветствую. Есть некий ЦОД в котором крутятся 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 есть таймаут на сборку пакета. Таким образом, вы и наблюдаете дикие дропы. Отключите все разгрузки и будет вам счастье. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted November 22, 2015 · Report post А что модно юзать при линке 10Gb? Ближайшие ipef3 сервера в радиусе 600км, на них скорость разгоняется до 3,5Гб. На американские сервера iprf3 вообще жопа со скоростью. Кто виноват и как исправить? Я бы выставил cc=htcp и убедился что опции типа rfc1323 и sack включены на концах. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tehmeh Posted November 23, 2015 · Report post Может там сочетание TCP_NODELAY на винде и delayed ACKs на линухе? : ) http://jvns.ca/blog/2015/11/21/why-you-should-understand-a-little-about-tcp/ Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
EugeneP Posted November 24, 2015 · Report post Вероятно у вас проблема с net.ipv4.tcp_timestamps=1, на стороне линуха. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vlad11 Posted November 24, 2015 · Report post А что модно юзать при линке 10Gb? Ближайшие ipef3 сервера в радиусе 600км, на них скорость разгоняется до 3,5Гб. На американские сервера iprf3 вообще жопа со скоростью. Кто виноват и как исправить? Я бы выставил cc=htcp и убедился что опции типа rfc1323 и sack включены на концах. Переключил cubic на htcp. Посмотрим. На Centos рекомендуют отключать rp_filter (RFC1812). Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dgan_87 Posted November 25, 2015 · Report post Может там сочетание TCP_NODELAY на винде и delayed ACKs на линухе? : ) http://jvns.ca/blog/2015/11/21/why-you-should-understand-a-little-about-tcp/ будет сочетаться Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
