Zeta-TCP - Zeta-TCP

Эта статья поднимает множество проблем. Пожалуйста помоги Улучши это или обсудите эти вопросы на страница обсуждения. (Узнайте, как и когда удалить эти сообщения-шаблоны) Похоже, что один из основных авторов этой статьи тесная связь со своим предметом. Может потребоваться очистка для соответствия политике содержания Википедии, в частности нейтральная точка зрения. Пожалуйста, обсудите подробнее страница обсуждения. (Апрель 2018 г.) (Узнайте, как и когда удалить этот шаблон сообщения) Тема этой статьи может не соответствовать Википедии рекомендации по продуктам и услугам. Пожалуйста, помогите установить известность, указав надежные вторичные источники которые независимый темы и обеспечить ее подробное освещение, помимо банального упоминания. Если известность не может быть установлена, статья, вероятно, будет слился, перенаправлен, или же удалено. Найдите источники: «Зета-ТКП»  – Новости  · газеты  · книги  · ученый  · JSTOR (Апрель 2018 г.) (Узнайте, как и когда удалить этот шаблон сообщения) Эта статья слишком полагается на Рекомендации к основные источники. Пожалуйста, улучшите это, добавив вторичные или третичные источники. (Апрель 2018 г.) (Узнайте, как и когда удалить этот шаблон сообщения) Эта статья может чрезмерно полагаться на источники слишком тесно связан с предметом, потенциально препятствуя публикации статьи проверяемый и нейтральный. Пожалуйста помоги Улучши это заменив их более подходящими цитаты к надежные, независимые сторонние источники. (Апрель 2018 г.) (Узнайте, как и когда удалить этот шаблон сообщения) Эта статья содержит контент, который написан как Реклама. Пожалуйста помоги Улучши это путем удаления рекламный контент и неуместно внешняя ссылка, а также путем добавления энциклопедического содержания, написанного с нейтральная точка зрения. (Июнь 2011 г.) (Узнайте, как и когда удалить этот шаблон сообщения) (Узнайте, как и когда удалить этот шаблон сообщения)

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

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

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

Предотвращение перегрузки

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

TCP Vegas и его вариации, в первую очередь БЫСТРЫЙ TCP, основывают свои прогнозы перегрузки только на измерении RTT. Такие алгоритмы, основанные на задержке, преодолевают проблемы алгоритмов, основанных на потерях, и обычно более реалистично отражают перегрузки в сети. Но у алгоритмов, основанных на задержках, есть свои ограничения, тоже.

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

Обнаружение потерь

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

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

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

Обратный контроль

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

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

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

Выполнение

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

Рекомендации