Статья, которая поможет вам понять протокол «скользящего окна» TCP.

предисловие

Ваши усилия сейчас направлены на то, чтобы иметь больший выбор в будущем.

в предыдущей статьеС помощью метода «признания» давайте быстро разберемся в семиуровневом сетевом протоколе.Понимание семиуровневого сетевого протокола. Далее мы сосредоточимся на надежности передачи по сети. Давайте посмотрим на протокол TCP, как он решает проблему ненадежной сетевой передачи. Очень важной частью этого является нашПротокол скользящего окна.

С инженерной точки зрения давайте посмотрим на протокол скользящего окна, какую проблему он решает?

Протокол скользящего окна:

• Использование протокола TCP
• Поддерживать буферы отправителя/получателя Буфер используется для решения проблемы ненадежных данных между сетями, таких как потеря пакетов, дублирование пакетов, ошибки, не по порядку

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

Вопрос 1: Как обеспечить заказ?

Задайте вопрос: до нашего протокола скользящего окна, как мы можем гарантировать, что каждый пакет будет получен между отправителем и получателем. А по порядку?

Отправитель отправляет пакет 1, который, когда он получает пакеты подтверждения 1. Пакет передачи 2, пакет подтверждения 2. Так что продолжайте, точно знайте, что отправка данных завершена, все кончено. Затем решить некоторые потери пакетов, ошибки, не по порядку и так далее! В то же время есть некоторые проблемы. В: пропускная способность очень низкая. Мы закончили пакет 1, нужно дождаться пакета подтверждения 1. Мы можем отправить второй пакет.

Вопрос 2: Как улучшить пропускную способность?

Задайте вопрос: Так не можем ли мы отправить несколько пакетов подряд и ждать, пока он подтвердит это вместе? В этом случае мы будем быстрее и будем иметь более высокую пропускную способность?

Как показано на рисунке, это то, что мы отправляем два пакета вместе, а затем подтверждаем их вместе. Видно, что наша улучшенная схема намного лучше предыдущей, а время на это уходит как раз туда-обратно. Далее у нас есть еще одна проблема: проблема повышения пропускной способности

Вопрос 3: Как добиться оптимального решения?

Вопрос: Сколько пакетов нам нужно отправлять каждый раз? Сколько пакетов для отправки является оптимальным решением?

Можем ли мы отправить первый и второй пакеты и отправить третий пакет после получения первого пакета подтверждения? Вместо ожидания пакета подтверждения второго пакета отправить третий пакет. Это естественным образом приводит к нашей реализации «скользящего окна».

На картинке мы видим, что серые пакеты №1, №2, №3 отправлены и получен Ack. Эти сумки остались в прошлом. Пакеты 4, 5, 6 и 7 выделены желтым цветом, что указывает на то, что они были отправлены. Но я не получил подтверждение от другой стороны, поэтому я не знаю, получил ли его получатель. Пакеты 8, 9 и 10 зеленого цвета. которые мы еще не отправили. Эти зеленые пакеты, которые мы собираемся отправить дальше. Видно, что в нашем окне ровно 11 сеток. Следующие 11-16 не были считаны в память. Мы должны дождаться следующего действия над 4-10 пакетами, и наши пакеты продолжат отправляться вниз.

нормальная ситуация

Видно, что пакет № 4 был получен другой стороной, поэтому он окрашен в серый цвет. «Окно» перемещается вправо на одну сетку, пока «окно» составляет 7 сеток. Мы только что прочитали пакет 11 в наш кеш. Вошел в состояние "к отправке". Пакеты 8 и 9 стали желтыми, указывая на то, что они были отправлены. Дальнейшая операция аналогична: после подтверждения пакета окно перемещается назад и продолжает считывать неотправленные пакеты в кэш, а статус пакета изменяет статус «для отправки» на «отправлен».

потеря пакетов

Возможно, мы отправили пакет, а акк другой стороны был утерян. Также возможно, что наш пакет не был отправлен. С точки зрения отправителя, мы не получили Ack.

Что произошло: Ждал Акка. Если мы не можем ждать, мы также отправим пакеты для отправки, которые считываются в кэш. Однако в это время наше окно уже заполнено. Поэтому невозможно прочитать 12-й пакет, но всегда ждать подтверждения 5-го пакета.

Что, если наш акк никогда не придет?

тайм-аут повторной передачи

На данный момент у нас есть решение:超时重传Вот одно замечание: этот Ack в порядке. Вы должны подождать, пока не будет получено подтверждение 5, прежде чем отправлять подтверждение 6-11. Это гарантирует порядок раздвижных окон.

В это время видно, что пакет № 5 получил Ack, а следующие пакеты № 6, 7 и 8 также были отправлены в прошлое и были Ack. Окно продолжает двигаться назад.

конец статьи

Поскольку мы хотим отправлять пакеты данных вместе, чтобы увеличить пропускную способность сети, в настоящее время создается протокол «скользящего окна». С концепцией «раздвижных окон» мы решаем некоторые возникающие проблемы. Например, потерю пакетов мы решаем через механизм ретрансляции. Вышеприведенное взято из обучающего видео учителя ccmouse, которое организовано как учебная запись.

Если статья вам полезна, обратите внимание на номер паблика:Программирование кодераПолучайте последние оригинальные технические статьи и соответствующие бесплатные учебные материалы и изучайте технические знания в любое время и в любом месте!