Зета-TCP

В этой статье есть несколько проблем. Помогите улучшить ее или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения ) Один из основных авторов этой статьи, по-видимому, тесно связан с ее темой.Может потребоваться очистка для соответствия политике Википедии в отношении контента, в частности нейтральной точки зрения . Пожалуйста, обсудите это подробнее на странице обсуждения . ( Апрель 2018 )( Узнайте, как и когда удалить это сообщение ) Тема этой статьи может не соответствовать правилам Википедии по значимости продуктов и услуг .Пожалуйста, помогите продемонстрировать значимость темы, ссылаясь на надежные вторичные источники , которые независимы от темы и обеспечивают ее значительное освещение, выходящее за рамки простого тривиального упоминания. Если значимость не может быть показана, статья, скорее всего, будет объединена , перенаправлена ​​или удалена . Найти источники:  "Zeta-TCP" – новости  · газеты  · книги  · ученый  · JSTOR ( Апрель 2018 )( Узнайте, как и когда удалить это сообщение ) В статье чрезмерно много ссылок на первоисточники .Пожалуйста, улучшите эту статью, добавив вторичные или третичные источники . Найти источники:  "Zeta-TCP" – новости  · газеты  · книги  · ученый  · JSTOR ( Апрель 2018 )( Узнайте, как и когда удалить это сообщение ) Эта статья может чрезмерно полагаться на источники, слишком тесно связанные с темой , что потенциально делает статью не поддающейся проверке и нейтральной .Пожалуйста, помогите улучшить его, заменив их более подходящими ссылками на надежные, независимые источники . ( Апрель 2018 )( Узнайте, как и когда удалить это сообщение ) ( Узнайте, как и когда удалить это сообщение )

Zeta-TCP ^[1] относится к набору фирменных алгоритмов протокола управления передачей (TCP), направленных на улучшение сквозной производительности TCP, независимо от того, является ли одноранговый узел Zeta-TCP или любым другим стеком протоколов TCP, другими словами, для совместимости с существующими алгоритмами TCP. Он был разработан и реализован корпорацией AppEx Networks.

Zeta-TCP в первую очередь обеспечивает следующие улучшения:

• Предотвращение перегрузок на основе показателей задержки и потерь.
• Улучшен алгоритм обнаружения потерь.
• Обратное управление.

Большинство реализаций стека TCP используют TCP New Reno или его вариации (например, TCP SACK RFC3517) в качестве алгоритма предотвращения перегрузки. Алгоритмы на основе New Reno основаны на потерях. Алгоритмы на основе потерь рассматривают потери пакетов как единственный признак перегрузки в сети. По мере развития Интернета это предположение сегодня часто оказывается излишним. Потери из-за перегрузки постоянно уменьшаются с развитием технологий, в то время как относительно случайные потери из-за свойств среды (например, беспроводных/ затухающих каналов ), шумов проводной линии/перекрестных помех, недостатков подключения, ошибок программного обеспечения и т. д. увеличиваются. После обнаружения (или ложной тревоги) «перегрузки» New Reno резко сжимает окно перегрузки (CWND), вызывая резкое падение скорости отправки. Это одна из основных причин того, что приложения на основе TCP часто едва могут использовать часть подписной полосы пропускания, особенно когда время задержки приема-передачи ( RTT ) велико.

TCP Vegas и его вариации, в частности FAST TCP , основывают свои прогнозы перегрузки только на измерении RTT. Такие алгоритмы на основе задержки преодолевают проблемы алгоритмов на основе потерь и обычно являются более реалистичным отражением перегрузки в сети. Однако алгоритмы на основе задержки имеют свои собственные ограничения .

Zeta-TCP решает эту проблему, объединяя силу алгоритмов на основе задержек и потерь. Он постоянно измеряет вариацию RTT и вариацию скорости потерь и вычисляет вероятность перегрузки. Схемы отсрочки CWND применяются на основе вероятности. При самой высокой вероятности он применяет схему отсрочки New Reno, которая уже доказала свою эффективность и стабильность за многие годы массового развертывания.

Потери пакетов в реальной сетевой среде редко распределяются равномерно; скорее они имеют тенденцию происходить близко друг к другу. RFC, связанные с TCP (New Reno и SACK и т. д.), явно определили, как первая потеря может быть обнаружена с высокой уверенностью. Однако обнаружение потерь после того, как TCP входит в режим быстрого восстановления с разрешенным SACK, неэффективно в RFC3517. Некоторые популярные операционные системы имеют свои собственные реализации, которые также неоптимальны.

Zeta-TCP предоставляет простой алгоритм для расчета вероятности потери для каждого неподтвержденного/неподтвержденного пакета. Пакет передается повторно только тогда, когда вероятность его потери превышает определенный порог. То же правило применяется к решению о повторной передаче каждого пакета. Таким образом, Zeta-TCP минимизирует количество повторно переданных пакетов, еще больше улучшая использование полосы пропускания. Лабораторные испытания подтвердили, что Zeta-TCP повторно передал гораздо меньше пакетов, чем другие реализации TCP при той же скорости потерь.

Zeta-TCP разработала механизм для точного обнаружения потери пакетов на самом раннем этапе, как только она подозревает, что потеря вероятна. Раннее обнаружение обычно может сэкономить один или два RTT на повторной передаче.

В то время как другие алгоритмы фокусируются на ускорении исходящего трафика, Reverse Control пытается решить проблемы входящего трафика. Reverse Control отслеживает качество соединений с входящими данными и выполняет алгоритм, чтобы подсказать одноранговому узлу передавать как можно быстрее, когда качество соединения хорошее. Алгоритм также имеет тенденцию более точно определять реальные потери пакетов из-за других ненормальных ситуаций, чтобы избежать ненужных быстрых восстановлений.

Обратно-управляемое входящее ускорение является эвристическим в том смысле, что входящая скорость контролируется отправителем, т. е. одноранговым узлом. Он может только намекнуть одноранговому узлу, чтобы тот отправлял быстрее. Некоторые стеки TCP принимают намек, а другие нет. Часто сторона отправителя (например, сервер контента) имеет механизм ограничения скорости, который ограничивает ускорение.

В дополнение к ускорению, Reverse Control также может ограничивать входящую скорость. В отличие от ускорения, замедление входящего трафика эффективно и точно с механизмом управления потоком TCP. Ограничение входящей скорости Zeta-TCP закладывает основу управления входящим потоком AppEx IPEQ. ^[2]

На момент написания статьи Zeta-TCP был реализован в виде программных модулей для Linux ( Netfilter Kernel Module), Microsoft Windows 10 вплоть до XP и связанных версий Windows Server ( NDIS IM Filter/NDIS LWF) и WinCE. AppEx не изменяет стек протоколов, а перехватывает потоки TCP и применяет свои алгоритмы на лету. Этот неинтрузивный способ реализации алгоритмов предназначен для более широкого принятия. Недостатком являются дополнительные накладные расходы на обработку, но эти накладные расходы незначительны по сравнению с приростом производительности.