Последняя статья, которая представила TCP»Трехстороннее рукопожатие TCP, четыре волны и некоторые детали«Отзывы неплохие, и я вполне доволен. В этот раз расскажу о части про тайм-аут и ретрансляцию.
Все мы знаем, что протокол TCP имеет механизм повторной передачи, то есть, если отправитель считает, что произошла потеря пакетов, он будет повторно передавать эти пакеты. Очевидно, нам нужен способ "догадка"Произошла ли потеря пакетов. Простейшая идея заключается в том, что каждый раз, когда получатель получает пакет, он возвращает пакет отправителю.ACK, указывая, что он получил эти данные, в свою очередь, если отправитель не получил ACK в течение определенного периода времени, он знаетСкорее всегоПакет потерян, а затем повторно отправляется до тех пор, пока не будет получен ACK.
Вы могли заметить, что я использовал «угадывание», потому что даже с тайм-аутом пакет мог не потеряться, просто он долго обходился и пришел с опозданием. Ведь протокол TCP находится втранспортный уровеньпротокола невозможно точно знать, что происходит на канальном уровне и на физическом уровне. Но это не мешает нашему механизму повторной передачи по тайм-ауту, потому что получатель будет автоматически игнорировать дубликаты пакетов.
Концепция тайм-аута и повторной передачи на самом деле так проста, но есть много внутренних деталей.Сколько времени требуется, чтобы истечь время??
Как определяется тайм-аут?
Универсальный подход заключается в том, что яУстановите тайм-аут непосредственно на фиксированное значение, например 200мс, но это однозначно проблема.Наш компьютер взаимодействует со многими серверами.Эти сервера расположены на юге и севере,внутренние и зарубежные,и задержка сильно различается.Например:
- Мой личный блог находится в Китае, и задержка составляет около 30 мс, что означает, что пакеты данных при нормальных обстоятельствах уже могут получить ACK примерно через 60 мс, но согласно нашему методу для определения потери пакета требуется 200 мс (обычно это может быть от 90 до 120 мс), этоЭффективность действительно низкая.
- Предположим, вы посещаете иностранный веб-сайт, а задержка составляет 130 мс, что неудобно,Обычные пакеты данных могут считаться просроченными, что приводит к повторной передаче большого количества пакетов данных.Вполне возможно, что повторно переданные пакеты данных могут быть легко ошибочно приняты за истекшие. . . Ощущение лавинного эффекта
Поэтому установка фиксированного значения очень ненадежна,Нам нужно динамически настроить тайм-аут в соответствии с сетевой задержкой., чем больше задержка, тем больше время ожидания.
Здесь вводятся два понятия:
- RTT (время приема-передачи): задержка приема-передачи, то есть время с момента отправки пакета данных до получения соответствующего ACK. **RTT зависит от соединения, каждое соединение имеет свой собственный независимый RTT.
- RTO (тайм-аут повторной передачи): тайм-аут повторной передачи, который представляет собой период тайм-аута, упомянутый ранее.
Сравните стандартные определения RTT:
Measure the elapsed time between sending a data octet with a particular sequence number and receiving an acknowledgment that covers that sequence number (segments sent do not have to match segments received). This measured elapsed time is the Round Trip Time (RTT).
Классический метод
Оригинальная спецификация"RFC0793” использует следующую формулу для получения сглаженной оценки RTT (называемой SRTT):
SRTT
RTT относится к последнему выборочному значению. Этот метод оценки называется "экспоненциально взвешенное скользящее среднее". Название звучит громко, но всю формулу легче понять. Он заключается в использовании существующего значения SRTT и последнего измеренного значения RTT для получения взвешенное среднее.
С SRTT пора установить значение соответствующего RTO,"RFC0793” рассчитывается так:
RTO = min(ubound, max(lbound, (SRTT)·β))
здесьuboundэто РТОверхняя граница,lboundдля РТОнижняя граница, β называетсякоэффициент дисперсии задержки, рекомендуемое значение 1,3 ~ 2,0. В этой формуле расчета используется значение (SRTT) β в качестве RTO, но, кроме того,Ограничивает верхнюю и нижнюю границы RTO.
На первый взгляд, с этим методом расчета проблем нет (по крайней мере, мне так кажется), но на практике есть два недостатка:
There were two known problems with the RTO calculations specified in RFC-793. First, the accurate measurement of RTTs is difficult when there are retransmissions. Second, the algorithm to compute the smoothed round-trip time is inadequate [TCP:7], because it incorrectly assumed that the variance in RTT values would be small and constant. These problems were solved by Karn's and Jacobson's algorithm, respectively.
Этот отрывок взят из "RFC1122", позволь мне объяснить:
-
когдаПроисходит повторная передача пакетаВ этом случае расчет RTT будет очень "хлопотным", для иллюстрации таких ситуаций я нарисовал картинку:
На рисунке показаны два случая, в которых метод расчета RTT отличается (это так называемая неоднозначность повторной передачи):
- Случай 1: RTT = t2 - t0
- Случай 2: RTT = t2 - t1
Но для клиента он не знает, что произошло, и результатом неправильного выбора является слишком большое/малое значение RTT, что влияет на расчет RTO. (Самое простое и грубое решение —Игнорировать пакеты с повторной передачей и учитывать только те, которые не были переданы повторно, но это может вызвать другие проблемы. . смотрите подробностиKarn's algorithm)
-
Другой вопрос,Этот алгоритм предполагает, что колебания RTT относительно малы., потому что этот алгоритм взвешенного среднего также называетсяфильтр нижних частот, не чувствителен к внезапным колебаниям сети. Если сетевая задержка внезапно увеличится, а фактическое значение RTT будет намного больше расчетного значения, это вызовет ненужные повторные передачи и увеличит нагрузку на сеть. (Увеличение RTT уже указывает на то, что сеть перегружена, и эти ненужные повторные передачи еще больше нагрузят сеть).
стандартный метод
Честно говоря, это стандартный метод сравнения, беда, я вставлю формулу напрямую:
SRTT <- (1 - α)·SRTT + α·RTT// то же, что и базовый метод,Найдите средневзвешенное значение SRTT
rttvar <- (1 - h)·rttvar + h·(|RTT - SRTT |)// вычислитьРазница между SRTT и истинным значением(называется абсолютная ошибка |Err|), также используетсяСредневзвешенное
RTO = SRTT + 4·rttvar// Расчетное новое RTO, коэффициент 4 rttvar регулируется параметром
Вся идея этого алгоритма заключается в объединенииСредняя стоимость(это основной метод) исреднее отклонениеЧтобы сделать оценку, волна настройки метафизических параметров достигла хороших результатов. Если вы хотите узнать больше об этом алгоритме, обратитесь к "RFC6298".
Ретрансляции — важное событие для TCP
ретрансляция по таймеру
В соответствии с этим механизмомКаждый пакет имеет соответствующий таймер, после превышения RTO без получения ACK пакет отправляется повторно. Пакеты, которые не получили ACK, будут сохранены в буфере повторной передачи и будут удалены из буфера после получения ACK.
Прежде всего, ясно, что для TCP повторная передача по тайм-ауту невозможна.довольно важныйсобытий (RTO часто превышает RTT более чем в два раза, тайм-ауты часто означают перегрузку), как только это произойдет,TCP не только повторно передаст соответствующий сегмент данных, но и снизит текущую скорость передачи данных, потому что TCP будет думать, что текущая сеть перегружена.
Простые механизмы повторной передачи тайм-аута часто неэффективны, как в следующих случаях:
Предположим, что пакет данных 5 потерян, а пакеты данных 6, 7, 8 и 9 достигли получателя.В это время клиент может только ждать, пока сервер отправит ACK.Обратите внимание, что для пакетов 6, 7, 8, и 9, сервер не может отправить ACK.Это определяется механизмом скользящего окна, поэтому для клиента он понятия не имеет, сколько пакетов было потеряно, и он может пессимистично относиться к тому, что пакеты после 5 тоже потеряны, поэтому он будет повторно передавать эти 5 пакетов.Это довольно расточительно.
быстрая ретрансляция
Механизм быстрой ретрансляции"RFC5681” Инициировать повторные передачи на основе обратной связи от получателя, а не тайм-аутов таймера повторной передачи.
Только что упоминалось, что повторные передачи на основе таймера имеют тенденцию ждать долгое время, а быстрые повторные передачи используют умный способ решения этой проблемы:Если сервер получает пакеты не по порядку, он также возвращает ACK клиенту., просто повторяющиеся ACK. Возьмем только что пример: при получении неупорядоченных пакетов 6, 7, 8 и 9 сервер все отправляет ACK = 5. Таким образом, клиент знает, что у 5 есть вакансия. В общем, если клиент получает повторные ACK три раза подряд, он будет повторно передавать соответствующий пакет, не дожидаясь истечения таймера.
Но быстрая ретрансляция все равно не решает второй проблемы: сколько пакетов нужно ретранслировать?
ретрансляция с подтверждением выбора
Усовершенствованный метод — это SACK (выборочное подтверждение), который просто основан на быстрой повторной передаче.Возвращает диапазон порядковых номеров последнего полученного сегмента., чтобы клиент знал, какие пакеты достигли сервера.
Вот несколько простых примеров:
-
случай 1: первый пакет потерян, а остальные 7 пакетов получены.
При получении 7 упаковоккто-нибудь, получатель вернет ACK с опцией SACK, чтобы сообщить отправителю, какие неупорядоченные пакеты он получил. Примечание:Левый край, правый край — это левая и правая границы этих неупорядоченных пакетов..
Triggering ACK Left Edge Right Edge
Segment
5000 (lost)
5500 5000 5500 6000
6000 5000 5500 6500
6500 5000 5500 7000
7000 5000 5500 7500
7500 5000 5500 8000
8000 5000 5500 8500
8500 5000 5500 9000
- случай 2: потеряны 2-й, 4-й, 6-й, 8-й пакеты.
-
При получении первого пакета не возникает ситуации нарушения порядка, и обычно возвращается ACK.
-
Когда 3-й, 5-й и 7-й пакеты получены, ACK с SACK возвращается из-за неправильного порядка пакетов.
-
Поскольку в этом случае имеется много сегментов фрагментов, соответствующие сегменты блоков также имеют много групп, и, конечно же, из-за ограничения размера поля опций блок также имеет верхний предел.
-
Triggering ACK First Block 2nd Block 3rd Block
Segment Left Right Left Right Left Right
Edge Edge Edge Edge Edge Edge
5000 5500
5500 (lost)
6000 5500 6000 6500
6500 (lost)
7000 5500 7000 7500 6000 6500
7500 (lost)
8000 5500 8000 8500 7000 7500 6000 6500
8500 (lost)
Однако спецификация SACK "RFC2018«Это немного сложно, получатель может «нарушить свое обещание» после предоставления SACK, чтобы сообщить отправителю эту информацию, то есть получатель может удалить эти (не по порядку) пакеты, а затем уведомить отправителя. Ниже приводится выдержка из «RFC2018»:
Note that the data receiver is permitted to discard data in its queue that has not been acknowledged to the data sender, even if the data has already been reported in a SACK option. Such discarding of SACKed packets is discouraged, but may be used if the receiver runs out of buffer space.
Последнее предложение говорит,Когда буфер приемника почти исчерпан, это действие можно предпринять, конечно, такое поведение не рекомендуется. . .
Из-за этой операции отправитель не может напрямую очистить данные в буфере повторной передачи после получения SACK, пока получатель не отправит обычный номер ACK, превышающий значение его максимального порядкового номера. Кроме того, на таймер повторной передачи также влияет таймер повторной передачи, который должен игнорировать влияние SACK, ведь получатель удаляет данные и теряет пакет.
расширение DSACK
DSACK, то есть повторяющийся SACK, этот механизм основан на SACK, несущем дополнительную информацию,Сообщите отправителю, какие пакеты данных были неоднократно получены им самим. Цель DSACK — помочь отправителю определить, имело ли место нарушение порядка пакетов, потеря ACK, дублирование пакетов или ложная повторная передача. Пусть TCP лучше управляет сетевым потоком.
Что касается DSACK, "RFC2883В книге много примеров, и заинтересованные читатели могут ее прочитать, и я не буду здесь вдаваться в подробности.
Содержимого тайм-аута и повторной передачи, наверное, так много, надеюсь, оно вам поможет.