Садитесь, вам двойка с минусом. Сначала утрудите себя почитать, что для Windows систем означают следующие ключи реестра (см. ниже), а уже потом мы будем разговаривать "о вопиющей безграмотности, незнании и непонимании простейших законов сетевого взаимодействия".
TcpAckFrequency
TCPNoDelay
TcpWindowSize
GlobalMaxTcpWindowSize
etc..
Мля... и эти люди мнят себя сетевыми специалистами.
Чем интересно поможет изменение значения TcpWindowSize с точки зрения соотношения трафика? Для просто читающих неспецов и для безграмотных умников из онета поясняю: этот параметр управляет размером окна т.е. грубо говоря кл-ва данных, которые могут быть посланы до получения квитанции на первый пакет. Это окно нужно, чтобы не стоять в ожидании квитанции на посланный пакет перед отправкой следующего. НО! Квитанции на эти данные никто не отменял! Просто они придут чуть позже. Увеличение этого окна оптимизирует загрузку канала но увеличивает откаты и перепосылку данных в случае сбоев. Уменьшение окна наоборот, уменьшает откаты, но ухудшает показатель загрузки канала. Но кл-ва квитанций он НЕ МЕНЯЕТ!
TCPNoDelay... ну что сказать. На быстрый Кузин взгляд да! Это замечательный аргумент. Ибо сказано, что эта опция "TCP feature that combines several small packets into a single, larger packet for more efficient transmission". Ключевые слова для Кузи и ему подобных спецов - "a single, larger packet". Вот оно! Однако если бы они еще удосужились последовать совету предыдущего поста и прочесть что такое МТУ... то они бы знали, что в Инете не бывает пакетов длиннее 576 байт, а в обычном эзернете - длинее 1500 (тут они называются фреймами). И это включая служебную инфу. Кстати по дефолту эта опция отключена.
TcpAckFrequency... Вот, вот Кузя нашел то что искал!!! Это действительно может снизить кл-во квитанций TCP! Все, теперь все юзера и уж конечно же я точно полных лохи и ламеры!
Что ж, попробуем рассмотреть этот параметр в доступной не спецам форме.
Считается, что по мере увеличения этого параметра TCP-протокол будет посылать квитанции не на каждый пакет, а на 2-3-4 и т.д. пакетов сразу. Максимальное значение параметра 255. Т.е. одна квитанция на 255 пакетов. Пока теория совпадает с Кузиной мечтой (на то что даже коэффициент 255 не объяснит толком соотношения трафика у ТС мы закроем глаза). Однако есть несколько моментов.
1. Если бы разнообразные Кузи читали документацию до конца, то они бы увидели маленькую приписку "... квитанция посылается после получения определенного параметром числа пакетов ИЛИ если за 200мс не получено ни одного пакета". Т.е. тупо по таймауту, коих в сети общего назначения по кличке Интернет более чем достаточно. Даже на хороших каналах в специально создаваемых условиях опыт показывает, что реально удается добиться 10-15-кратного уменьшения трафика квитирования. Но это же опыт, это же надо не бабки с клиентов тянуть и на форуме чушь нести, а сниффер погонять и головой слегка подумать.
2. Да, можно ждать получения 255 пакетов... но тут БАЦ! Закрывается окно TCP (про него упоминалось в описании предыдщих параметров). Т.е. все, исчерпалось кл-во данных, которые можно было принять без отправки квитанции и система подождав 200 мс опять посылает квитанцию, чтобы открыть это окно.
О да! Продвинутый ТС оттюнинговал систему, он сделал окно больше 1-го мегабайта (что явно не рекомендовано), он поставил TcpAckFrequency равным 255, у него идеальный канал без таймаутов и система работающая согласно теории а не жизненным реалиям... Другими словами ТС сделал все, чтобы добиться такого соотношения трафика и пристебаться провайдеру. Надо же, какой негодяй! Но тут наступает самый интересный Пункт 3.
3. Данный параметр в отличие от окна ТЦП, которое согласовывается, имеет отношение только к системе, на которой он установлен. Т.е. только та система, которая принимает данные и посылает квитанции решает, как часто она будет эти квитанции посылать. В случае ТС-а данные посылает система ТС-а (у него огромный исходящий трафик, "он посылает письма" или "с него тянут файл" по утверждению Кузи), а квитанции (которые будут для ТС-а входящим трафиком) посылает удаленная система!
Все. ТС попал. Совершение преступления в группе всегда считалось отягчающим обстоятельством. В данном случае ТС вступил в сговор с администратором удаленной системы, чтобы он специально оттюнинговал свою систему для минимально генерации исходящего (а для ТС-а входящего) трафика! Кузенька, пожалуйста, смени дату на своем компьютере с 1937-го на 2008-й год.
Итого, я попытался наглядно показать, что Кузьма опять бездарно использовал отрывочные знания без какого-либо понимания происходящего для аргументации позиции "все ламеры а у нас все правильно". И такому "специалисту" люди должны верить на слово, что "все работает идеально и правильно". Блажен кто верует.
Понимаю, что я не самый способный популяризатор, но думаю хоть что-то для не спецов стало понятным. Если кого-то заинтересовали мои пояснения - велкам в личку или аську, подскажу, посоветую, с интересом выслушаю аргументы против и т.д.
Кстати, Кузя, а что это мы уперлись в квитирование ТЦП, в котором Вы и Ваши сторонники явно нифига не понимаете? Давайте перейдем на более простую тему - протоколы прикладного уровня.
Внимание, опять ПРЯМОЙ ЧЕТКО ПОСТАВЛЕННЫЙ ВОПРОС: "Сколько минимум байт прикладного уровня посылает SMTP-сервер принимая письмо для отправки?"
Сразу скажу, что теоретический минимум, которым может обойтись почтовый сервер - это 35 байт протокола прикладного уровня. Это в случае полностью отключенной вербализации чего в жизни не бывает и отсутствия авторизации. Практически там 200-400-600 байт. На каждое письмо. Это только на прикладном уровне, к которому добавится служебная инфа ТЦП и ИП уровней, а еще сопутствующие действия МТА по резолву МХ-сов в адреса ( а в случае спама - как еще назвать такой объем писем - еще и собсно получения самих МХ-сов).
Итак, Кузя, доказываем, что это все херня (точнее показываем свои "знания").
Кстати заодно доказываем, что ТС проспамился минимум 3-5 тысячами писем и не пришло ни одного абуза
Уфф, многа букафф, но я старался для не спецов. Уже не важно даже что глюкануло в случае с ТС, здесь пошло наглядная демонстрация уровня знаний в техслужбе провайдера с активным участием представителей этой техслужбы
ЗЫЖ Кого заинтересовало происходящее в его сетевом кабеле - ищет что такое WireShark, качает, ставит, разбирается (может спросить у меня) и удивляется неизведаному миру
