Коротко о надежности TCP

предисловие

первый изblog.cc1234.cc/

Протокол управления передачей (сокращение: TCP) является ориентированным на соединение, надежным, основанным набайтовый потокизтранспортный уровеньпротокол связи,IETFизRFC 793определение.

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

Доверие принадлежит доверию, но нам еще предстоит его понять, узнать, почему оно заслуживает доверия, и в каких аспектах доверия в основном отражается.

• Что такое надежность TCP
• Как TCP обеспечивает надежность

Вышеупомянутый вопрос является основным пунктом этой статьи

Надежность TCP на самом деле большая тема, и многие детали заслуживают изучения.Из-за моего ограниченного уровня многие описания в тексте не являются подробными и даже могут быть неверными.Если читатели имеют разные мнения, они могут высказать как насколько это возможно.

что такое надежность

по фактуRFC 793из1.5 Operationспециально дляReliability(надежность) объяснил

Подытожено следующим образом

Гарантирует, что поток данных, считанный процессом из своего приемного буфера, является потоком данных без искажений, без пропусков, без избыточности и в порядке; то есть поток байтов точно такой же, как поток байтов, отправленный процессом другая оконечная система соединения

вопросы, требующие решения

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

Ниже приведены некоторые из наиболее типичных проблем.

• вмешательство

  Помехи в сети могут быть вызваны разрушением пакета данных из-за аппаратного сбоя или могут быть вызваны колебаниями сети, которые вызывают изменение некоторых битов пакета данных.

  Не по теме: вмешательство здесь не включает вредоносные атаки.Злонамеренные атаки относятся к категории безопасности передачи.Например, всем известный SSL/TLS является зрелым решением проблем безопасности сетевой передачи.

  Как показано ниже, отправлено111из-за помех101

• не работает

  Отправитель отправляет два пакета данных подряд, и пакеты данных, отправленные позже, могут прийти к получателю первыми.Если получатель обрабатывает пакеты данных в том порядке, в котором они были получены, это приведет к тому, что полученные пакеты данных будут несовместимы с отправленные пакеты данных.

  Причина этого в том, что каждый пакет данных будет выбирать другой маршрут для передачи в соответствии с условиями сети в данный момент времени, точно так же, как существует множество маршрутов на выбор из Шанхая в Пекин на машине, не обязательно, что вы сможете прибыть первым. (я не поехал) Если поедете в Пекин, пожалуйста, не оскорбляйте меня...)

  Как показано на рисунке ниже, отправитель отправляет заказ в порядке A -> B -> Cтри пакета, однако получатель может бытьA -> C -> BДля пакетов, полученных в таком порядке, очевидно, что порядок двух пакетов B и C не соответствует ожиданиям, что приводит к беспорядку.

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

  Потеря сетевых пакетов — очень распространенное явление, и причин этому много, наиболее распространенные из них:

  1. Из-за переполнения буфера приемник больше не может обрабатывать входящие пакеты данных и напрямую отбрасывает их, что приводит к потере пакетов.

  2. Перегрузка сети приводит к потере пакетов

  3. Пакет обнаруживается поврежденным и отбрасывается получателем, что приводит к потере пакета.

  4. ......

  На рисунке ниже показана эта ситуация, данные, отправленныеCBAиз-заAПроисходит потеря пакетов, в результате чего получатель получает толькоCB

• избыточность

  Отправитель может по какой-то причине неоднократно отправлять один и тот же пакет данных, и получатель должен иметь возможность обрабатывать такие избыточные пакеты данных.

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

Прежде чем двигаться дальше, подумайте об этом: как бы вы решили эти проблемы?

0x01 устранить помехи

Чтобы иметь возможность определить, есть ли ошибка при передаче пакета данных, TCP ввелchecksum.

Конкретные сведения о контрольной сумме можно найти вRFC1071

На следующем рисунке показана структура пакета TCP, а синяя часть — контрольная сумма.

checksumЭто поле длиной 16 бит.При вычислении контрольной суммы отправитель сначалаChecksumУстановите в ноль, затем рассчитайте контрольную сумму на основе всего пакета (заголовок + часть данных)

На самом деле будет добавлен 96-битный псевдозаголовок, вы можете обратиться кRFC 793Формат заголовка раздела

Получатель также рассчитает контрольную сумму после получения сообщения.

• Если результат расчета соответствует ожидаемому значению, пакет не нарушен/поврежден.
• Если он не соответствует ожиданиям, пакет обычно сразу отбрасывается.

Контрольная сумма TCP также имеет определенные ограничения, и она может не на 100% обнаруживать ошибки, генерируемые пакетами данных.

Это то же самое, что и подпись, когда мы обычно занимаемся разработкой API.

0x02 устраняет беспорядок и избыточность

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

Есть несколько решений для выхода из строя, например, после отправки части данных, я подтверждаю, что отправленные данные были получены получателем, и я отправляю следующие, которые должны быть в порядке, но такая схема слишком мало для использования сети.

Другое очень простое решение состоит в том, чтобы пометить каждое сообщение порядковым номером, чтобы получателю нужно было только отсортировать сообщения в соответствии с порядковым номером после получения сообщения, а затем можно было получить упорядоченные сообщения.Процесс показан ниже. фигура.

На самом деле, протокол TCP используется для сообщения плюс количество таких методов

Структура сообщений TCP поддерживаетSequence Number(именуемый в дальнейшемseq), как показано в красной области на рисунке ниже

Отправитель и получатель TCP поддерживают отдельныеseq, seqНачальное значение инициализируется при создании соединения (значение является случайным)

имеет контрольный битSYNОн специально используется для синхронизации отправителя и получателя.seq(Под синхронизацией здесь понимается сообщение другой стороне начального значения их последовательности)

Для получения дополнительной информации см. 3.3 Порядковые номера RFC 793.

Каждый пакет после установления соединения будет содержатьseq

Как показано на рисунке ниже, при исходномseq=1, первое сообщение отправленоAДлина 12, затем отправить второе сообщениеBизseq=1+12=13

После того, как получатель получит несколько пакетов, он может отсортировать их в порядке возрастания на основе последовательностей нескольких пакетов и пройти проверку.seqПо значению можно судить о том, есть ли пропуски в полученных данных и в порядке ли данные.

Помимо,seqДелает TCP способным справляться с проблемой дублирования пакетов, поскольку получатель можетseqОпределить, был ли получен пакет данных, что также решает проблему избыточности данных.

0x03 решает проблему потери пакетов

Причины потери пакетов могут быть разные, начнем с простого сценария.

Предполагая, что потери пакетов нет, как сообщить отправителю, что получатель успешно получил пакет данных?

Это похоже на разговор между людьми, как вы можете сказать, слышал ли это другой человек?

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

TCP также использует аналогичный механизм, который мы обычно называемACK(Подтверждение): получатель ответит отправителю определенным пакетом после получения пакета.

Продолжайте смотреть на структурную схему TCP, обратите внимание на зеленую областьAcknowledgment Number(именуемый в дальнейшемack)

Обратите внимание, что есть разница между ACK в верхнем регистре и ACK в нижнем регистре.

ACK в верхнем регистре обычно относится к типу сообщения

Подтверждение нижнего регистра относится к этому 32-битному длинному номеру.

ackа такжеseqВсе они имеют длину 32 бита Ранее мы упоминали, что сообщения, отправленные после установления TCP-соединения, будут перенесены с ними.seq, получатель ответит сообщением типа ACK после получения сообщения

телеграммаacknowledgment numberЗначение — это сообщение, которое получатель ожидает получить в следующий раз.seqстоимость

На самом деле на значение ack будут влиять многие ситуации, такие как кумулятивный механизм подтверждения TCP, выбор механизма повторной передачи и т. д., что повлияет на значение ack ответа.RFC 793

имеютACKПосле этого отправитель может узнать, правильно ли получено сообщение.

Пожалуйста, посмотрите на картинку ниже, это простое взаимодействие, отправитель отправляет данные, а получатель отвечает после подтверждения данных

Ранее мы анализировали ситуацию на основании отсутствия потери пакетов.ACKЭто не решает проблему потери пакетов, как показано на рисунке ниже, если отправленные данные потеряны, потери пакетов не будет.ACK,ACKЕсли пакет потерян, неизвестно, правильно ли были получены данные.

В этот момент мы вводимтайм-аута такжеРетрансляция, в сочетанииACKмеханизм решения проблемы потери пакетов

• Отправитель запускает таймер после отправки неподтвержденного пакета
• Если не получен в указанный срокACK, отправитель может повторно передать сообщение

тайм-аут повторной передачи + ACKСуществует также небольшая проблема, а именно проблема избыточности данных, упомянутая в начале.

Повторная передача пакетов может привести к тому, что получатель получит несколько дубликатов пакетов. Если вы не забыли, это можно сделать в предыдущем разделе.seqрешать

Собственно ПТСконтроль перегрузкиЭто также один из эффективных механизмов борьбы с потерей пакетов, о котором могут узнать заинтересованные студенты.

0x04 В основном надежный

При рассмотрении наших первоначальных требований к надежности

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

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

Поскольку до сих пор наши сценарии были относительно простыми, мы упускали из виду многие переменные и детали.

Например, мы не упомянули очень важные滑动窗口,拥塞控制算法и т.д., но по сути это тоже вещи, которые нельзя получить по TCP для достижения надежности в сложной сетевой среде

0x05 Дополнительная история

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

1. каждыйseqобоим нужен одинack?

   конечно, нет

   Отправитель может сразу отправить несколько сообщений, а получатель не спешит отвечать после получения сообщенияack, так как последующие пакеты могут приходить немедленно, чтоACK延迟确认

   Отложенное подтверждение позволяет нам подтверждать несколько полученных сообщений одновременно, что также называется累计确认

   Таким образом, получатель не должен подтверждать каждое сообщение.После получения нескольких сообщений, если сообщение не приходит в течение времени задержки, он отправит следующее сообщение, которое ожидает получить сообщение.ack, Как показано ниже

   

2. На приведенном выше рисунке, если несколько пакетов seq отправляются одновременно, как ответит ack, если один из пакетов потерян?

   Как правило, получатель будет иметь приемный буфер, который будет буферизовать полученные сообщения.Эти сообщения сортируются в соответствии со значением последовательности.Если в середине отсутствует сообщение, получатель будет реагировать на значение последовательности сообщения.

   Как показано на рисунке ниже, отправитель отправилseq=1,seq=2,seq=3сообщение,seq=2Потеря пакетов, но получатель кэширует 1 и 3,

   Итак, я знаю, что эта часть сообщения не является непрерывной, и в середине не хватает 2, поэтому он отвечаетack=2(обычно называется наименьшим акком)

   Отправитель повторно отправляет сообщение с seq=2, а получатель узнает1,2,3был полностью получен, он отвечает на следующее ожидаемое значение, то есть на ответack=4

3. Вы запускаете таймер каждый раз, когда отправляется сообщение?

   Для обеспечения надежности TCP добавляеттайм-аут повторной передачимеханизм, чтобы каждыйне подтверждено(ACK) сообщения могут быть повторно отправлены через определенный период времени

   Одна из реализаций заключается в настройке отдельного таймера для каждого неподтвержденного сообщения, но это слишком дорого.

   существуетRFC 6298изManaging the RTO Timerупоминается водиночный таймерспособ управления (подробности см. в документации)

   Каждый отправленный, но неподтвержденный пакет помещается в очередь с отдельным таймером.

   Когда первый пакет попадает в очередь, запускается таймер

   Если время таймера истечет, пакет в начале очереди будет отправлен повторно, и таймер переустановит отметку.

   Таймер также перезапускается при получении ACK.

   Если все данные в очереди подтверждены, закрыть таймер

4. Как установить время ожидания?

   Время ожидания повторной передачи, обычно называемоеRTO, это время не может быть ни слишком длинным, ни слишком коротким.

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

   • Если оно слишком короткое, пакет данных может еще не прийти, а в это время происходит повторная передача, что приводит к трате ресурсов.

   задержка туда и обратноRTT(время приема-передачи) — важный показатель для настройки RTO, но, поскольку сквозное RTT между сетями не является фиксированным, TCP использует адаптивный метод для расчета RTT и настраивает RTO в соответствии с рассчитанным значением.

   Весь процесс является динамическим, а это означает, что при изменении RTT RTO также может соответствующим образом корректироваться.

   Для получения более подробной информации см.RFC 6298изThe Basic Algorithm

5. Должен ли он истечь перед повторной передачей?

   TCP имеетбыстрая ретрансляциямеханизм, когда приемник получает более трех повторенийack, приемник будет напрямуюackзначение для повторной передачи соответствующего сообщения без ожидания тайм-аута

   На изображении ниже показан простой пример

   1. 发送方发送了seq=1, seq=2, seq=3, seq=4的报文
   
   2. seq=1的报文发送了丢包
   
   3. 接收方分别接受到了`2,3,4`的报文，接收方缓存收到的报文，然后检查seq知道报文不连续，缺少`seq=1`的报文， 所以每次都响应`ack=2`
   （为了简化描述，我们不考虑延迟确认和缓冲区大小）
   
   4. 发送方连续收到了3个`ack=2`的报文，所以认为`seq=1`的报文丢包了，重传`seq=1`
   
   5. 接收方收到`seq=1`的报文后，发现seq=2，seq=3,seq=4已经接收过了，直接响应`ack=5`

Суммировать

Мы видим, что TCP реализуетнадежностьВ Интернете было сделано множество изысканных дизайнов. Эти проекты стремятся к простоте в больших аспектах и ​​стремятся к крайности в деталях. Они определенно стоят того, чтобы их изучить и обдумать.

Вы также можете увидеть его тень в текущей системе программного обеспечения этих конструкций TCP.

• Например, очередь сообщений имеет аналогичный механизм подтверждения, чтобы гарантировать, что сообщение было доставлено.
• Например, чтобы обеспечить упорядоченность асинхронных сообщений, будут подобныеseqМеханизмы

Как сказано в предисловии,可靠性На самом деле это большая тема, и неизбежно я оставил много ям.Если есть ошибки, я надеюсь указать.

Ссылаться на

1. Джеймс Ф. Куросе, Кейт В. Росс, перевод Чен Мин. Нисходящие подходы к компьютерным сетям (шестое издание)
2. Википедия TCP
3. RFC 793
4. RFC 1071
5. RFC 6298
6. дополнение
7. дополнение до двух
8. задержка туда и обратно
9. Механизм повторной передачи тайм-аута TCP
10. контроль перегрузки