+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

tcp window size...

tcp window size..., RouterOS

amode

Guest

23.02.2007 20:07:00

Привет, скажи, пожалуйста, почему совершенно нет информации о том, как настроить размер окна TCP для отправки и приема? Этот «параметр» действительно не пригоден для настройки на RouterOS? Спасибо, если получится тут что-то выяснить.

Ахим

Diganet Guest	#2 0 24.02.2007 14:44:00 Вы не можете изменить размер окна TCP на RouterOS. /Henrik

maximan Guest	#3 0 23.02.2007 21:06:00 Ты уверен?? Проверь руководство по настройке MTU и MSS, Maximiliano.

changeip

Guest

23.02.2007 21:13:00

MTU и MSS — это не то же самое, что размер окна TCP. Размер окна TCP задается на уровне приложения, а не на уровне маршрутизации. Если вы хотите изменить размер окна, то меняйте его на машине, отправляющей данные. (поправьте меня, если я не прав, я просто ориентируюсь на то, что нашел в Google). Было бы неплохо иметь возможность манипулировать/брандмауэрить на основе размера окна (< > =). Сети ботов, кажется, используют размер окна 0, когда занимаются какой-то специфической SMTP-ерундой, и фильтрация их путем поиска tcp/25 с размером окна 0 — отличный способ уничтожить зомби-спам. Сэм

bjohns

Guest

23.02.2007 23:36:00

RFC указывает, что TCP Window Scaling происходит на транспортном уровне. Звучит логично, ведь это протокол транспортного уровня... Расширение Window Scale расширяет определение TCP-окна до 32 бит, а затем использует коэффициент масштабирования, чтобы передать это 32-битное значение в 16-битном поле Window заголовка TCP. Cisco также предоставляет полезную информацию об этом параметре. Window Scaling — это дополнение к существующему методу MSS.

amode

Guest

24.02.2007 08:06:00

Если хочешь изменить размер окна, то меняй его на той машине, которая отправляет данные. Окей, это значит, если я использую http или web-прокси на RouterOS, мне нужно изменить размер окна в системе RouterOS, верно? Это отличается от обычной фильтрации файрвола, которая только «пересылает» пакеты. Так что вопрос остаётся актуальным для меня: если я использую TCP-сервис на RouterOS (например, тест скорости или web/http-прокси), как мне изменить размер tcp-окна? Спасибо за дополнительные сведения. Achim

jerico99

Guest

16.03.2018 17:33:00

Это можно сделать с помощью IPTables в Linux. Достаточно легко интегрировать это в правила mangle в Mikrotik. Это было бы очень удобно для простого механизма оптимизации трафика по каналам WAN. https://serverfault.com/questions/528065/how-to-edit-tcp-window-size-from-iptables

CZFan

Guest

16.03.2018 17:44:00

Почему? Вы не скачиваете/загружаете непосредственно в роутер, вы скачиваете/загружаете через роутер, то есть любые изменения размера окна TCP следует вносить на конечных точках, то есть на вашем компьютере с Windows и т.д.

markmcn

Guest

17.03.2018 00:32:00

@CZFan Согласен, это было бы отлично для работы с длинными и громоздкими ссылками. Упоминалось, что эта функция была бы полезна в таблице "magle", которая используется для изменения трафика, проходящего через роутер. Это может стать реально полезным изменением для трафика по каналам, где произведение пропускной способности и задержки становится ограничивающим фактором. В любом случае, +1 от меня за эту функцию. Гораздо ценнее, чем функция SMB, которая была добавлена.

mkx

Guest

#10

17.03.2018 07:45:00

Не думаю, что безопасно, чтобы устройство где-то посередине манипулировало размером TCP-окна. В большинстве случаев, вероятно, всё будет в порядке, но есть шанс серьезно нарушить соединение. Размер TCP-окна как-то связан с размером буфера получателя, так как получателю потенциально нужно буферизировать весь размер TCP-окна данных в случае повторной передачи или доставке вне порядка. Похоже, что если получатель получил больше данных, чем ожидал, то может произойти что угодно. Размер TCP-окна – это динамичная штука, и в идеале он должен увеличиваться по мере необходимости (это просто занимает некоторое время). Если этого не происходит, то нужно исправить TCP-стек клиента и/или сервера.

pe1chl

Guest

#11

17.03.2018 10:09:00

Конечно, правило mangle в цепочке пересылки должно только УМЕНЬШАТЬ размер окна в TCP-пакетах, которые пересылаются, никогда не увеличивать его. Это как действие adjust-mss, которое тоже должно только УМЕНЬШАТЬ mss. Не думаю, что от уменьшения размера окна в пересылаемом пакете могут быть какие-то негативные последствия. Но это может быть полезно, например, когда нужно дать множеству TCP-соединений справедливую долю пропускной способности на медленном соединении.

mkx

Guest

#12

17.03.2018 11:45:00

Согласен. Но я думаю, что OP и @jerico99 хотели добиться другого. Похоже, им нужно было ускорить отдельные TCP-соединения, которые страдают от задержек, и для этого нужно было увеличить размер окна. Что, конечно, не очень хорошо.

markmcn

Guest

#13

17.03.2018 14:14:00

@mkx & pe1chl Изменение размера окна TCP вверх/увеличение – это не всегда плохо. Мой первый пункт заключается в том, что я согласен с тем, что конечные хосты должны устанавливать размер окна, чтобы заполнить канал, независимо от задержки. Однако я недавно работал над решением проблемы, когда произведение пропускной способности и задержки становилось ограничивающим фактором, и окно TCP не масштабировалось должным образом. В результате трансатлантическое соединение через облако MPLS достигало скорости примерно @~13 Мбит/с, хотя самое слабое звено в пути было 100 Мбит/с. Помимо таких вещей, как дедупликация и увеличение размера окна TCP, оптимизатор WAN оказал огромную помощь. Я не люблю эти устройства, поскольку они могут сильно усложнить поиск неисправностей. Однако, если бы я мог создать правило, которое говорит: «Для этого назначения, если рекламируемое окно меньше x, добавьте фиксированное значение или установите его в фиксированное значение». ДА, это все равно может привести к переполнению хоста при приеме данных, но в этом случае вы начнете видеть потерянные кадры, и принимающая сторона всегда может объявить нулевое окно, чтобы указать, что буфер заполнен. Я не думаю, что MT следует рассматривать дедупликацию, но возможность манипулировать окнами TCP была бы огромной помощью. Однако это инструмент тонкой настройки с огромной мощностью, и поэтому инженер должен понимать, что он будет делать, и использовать его для очень выборочных случаев. Один момент, который следует отметить: для предотвращения переполнения ему действительно необходима возможность связать буфер с правилом настройки окна. В заключение я согласен с тем, что ДА, конечные хосты должны делать это, TCP предназначен для сквозной связи, но когда хосты не масштабируют окно TCP правильно, нам приходится вмешиваться где-то.

pe1chl

Guest

#14

17.03.2018 15:14:00

В большинстве реальных ситуаций (то есть, обычная смесь нескольких сессий через одни и те же ссылки и роутеры), пропускная способность увеличивается больше от уменьшения размера окна TCP, чем от его увеличения! Это потому, что удается избежать ситуации, когда пакеты отбрасываются из-за перегрузки, и всё просто продолжает идти своим чередом. Большинство систем лучше имеют слишком большие каналы, чем слишком маленькие ("buffer bloat"). Невероятно большие окна полезны в основном для тестов производительности, когда кто-то думает, что может измерить скорость ссылки, прогоняя через неё одну TCP-сессию. Это нереалистичная ситуация, но если они хотят это сделать, им стоит использовать современный TCP-стек, который может использовать эти огромные окна с помощью опции масштабирования окна. Люди хотят подобных изменений, потому что слишком много внимания уделяют тестам производительности и следуют авторам сайтов, которые делают то же самое. Изначальные разработчики TCP и те, у кого есть большой опыт в этой области, знают, что это плохая идея.

markmcn

Guest

#15

17.03.2018 20:09:00

Привет, pe1chl, все твои аргументы справедливы. Я просто говорю, что бывают случаи, когда увеличение размера окна действительно полезно. Да, ты прав, это может ставить под угрозу другие соединения по каналу. Как я и упоминал, такая функция должна использоваться очень осторожно, на основе тщательной оценки. К сожалению, в ситуации, в которой я оказался, проблема была с производительностью CIFS/SMB для небольшого офиса, где один и тот же человек был основным пользователем канала. Я не предлагал использовать нереально большие окна. TCP flow control работает отлично. Я просто говорю, что когда операционные системы неправильно выполняют TCP-масштабирование, было бы полезно иметь это как обходной путь. Идеальное решение — чтобы хосты правильно выполняли масштабирование размера окна. Я не хочу никого троллить или спорить, я просто говорю, что эта функция была бы полезной, если бы использовалась с умом. Позволь мне спросить тебя, pe1chl, как бы ты решил проблему, когда CIFS/SMB жалуются на то, что он невыносимо медленный, и при этом он достигает BDP? Я понимаю, что есть варианты, например, Windows DFS, чтобы иметь локальные копии, и это было исследовано, но это не соответствовало рабочему процессу. Изменение рабочего процесса было рассмотрено, и сейчас ведутся обсуждения, чтобы найти более приятное решение для всех. Но поскольку ты говоришь, что возиться с размером окна TCP — это плохо и его следует только уменьшать, мне хотелось бы услышать твоё мнение/идею. Может быть, я что-то упускаю, поэтому я хочу открыть дискуссию вокруг такого варианта использования, ведь это реальный случай.

Cheers,
Mark

pe1chl

Guest

#16

18.03.2018 10:13:00

CIFS обычно используется в Windows и иногда в Linux (SAMBA), и в обоих случаях параметры, такие как размер окна, отлично конфигурируются на конечных системах, где и лучше всего это делать. Насколько я знаю (я не изучал последние версии CIFS, например, используемые в Windows 10), основная проблема с CIFS (и другими сетевыми файловыми системами) — это не размер окна TCP, а размер запроса в сети. При чтении всего файла по сети он обычно читается сравнительно небольшими фрагментами, которые должны быть полностью получены, прежде чем будет отправлена следующая команда чтения. Обычно наблюдаются последовательности вроде: ->> OPEN файл aaaaa <<- OK ->> READ x байт <<- x байт ДАННЫХ ->> READ x байт <<- x байт ДАННЫХ и так далее. Конечно, время ожидания ответа соединения делает это медленным, когда x относительно мало по сравнению со скоростью соединения. И размер окна TCP, вероятно, уже больше, чем x. Протоколы, такие как FTP, RSYNC, SCP и т.д., гораздо более эффективны, потому что они используют последовательность вроде: ->> READ файл aaaaa <<- весь файл aaaaa в виде ДАННЫХ. Тогда размер окна TCP становится определяющим фактором. И всё же, когда много пользователей выполняют тот же вид операции параллельно, может быть лучше ограничить размер окна каждого соединения, чтобы у других тоже был шанс. Особенно, если на интерфейсах не настроена "справедливая очередность", и поток данных от одной TCP-сессии проходит полностью, прежде чем какой-либо другой пользователь на линии получит шанс. Как вы отметили, создание локальных закэшированных или синхронизированных копий файла может быть более эффективным, но это не всегда практично. Некоторые протоколы (например, RSYNC) более эффективны в поддержании копий, но когда файл меняется слишком часто, это становится непрактичным. В этом случае иногда есть возможность запустить приложение удаленно (где находятся данные) и отправлять вывод по соединению (RDP, Citrix, веб-приложение).

markmcn Guest	#17 0 18.03.2018 23:28:00 Привет, Pe1chl! Я знаю, что "болтливость" CIFS может быть проблемой при высокой задержке/длинных связях. И если бы я мог просто сказать им использовать что-то вроде FTP или SFTP, я бы это сделал. Что касается RDP/Citrix, ну, это часть проблемы. Человек генерировал огромный набор данных на удаленном компьютере, но ему нужно было закончить обработку локально. В конечном итоге это проблема рабочего процесса, и такие вещи можно обойти только с помощью технологий/инженеров, которые подкручивают настройки. В данном случае пропускная способность ограничивалась BDP, как и рассчитано. Последняя версия CIFS 3.x от наших друзей из Microsoft внедрила CIFS multichannel, что, похоже, еще один способ решения проблемы. Судя по всему, она открывает несколько параллельных соединений (примечание: я не читал все документы, просто мельком взглянул, возможно, есть какие-то требования, которые я не учитываю, или я просто что-то неправильно понял). Настройки размеров буфера TCP в Windows — это лотерея, я очень открыт к возможности того, что я делал это неправильно. В любом случае, это был интересный разговор. Я все равно думаю, что это была бы полезная функция, но использовать её нужно с большой осторожностью. Да, конечно, будут люди, которые не понимают, как работают скользящие окна, и испорчат свое соединение — ну и что? Как и все продвинутые функции, если использовать их правильно, она может помочь выйти из сложной ситуации. Это был интересный чат по предложению функции/идее, спасибо за это. Позволь мне так сказать: я все еще верю, что это было бы более полезно, чем время, которое MT потратил на добавление CIFS-сервера в операционную систему роутера. Что дальше? Вместо того, чтобы исправить BGP, который является одноядерным процессом, они добавят торрент-клиент в ROS 7? Дрожь пробирает от этой мысли. Прежде чем они начнут что-то подобное, я бы очень хотел, чтобы MT действительно сосредоточился на вещах, которые имеют значение, например, на ограничении процессора для процесса BGP.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры