Надежный поток байтов — это распространенная парадигма обслуживания в компьютерных сетях ; он относится к потоку байтов , в котором байты , выходящие из канала связи у получателя, являются точно такими же и находятся в точно таком же порядке, какими они были, когда отправитель вставил их в канал.
Классическим примером надежного протокола передачи данных с помощью потока байтов является протокол управления передачей , один из основных компонентов Интернета .
Однако надежный поток байтов — это не единственная надежная парадигма обслуживания , которую предоставляют протоколы компьютерной сетевой связи; другие протоколы (например, SCTP ) обеспечивают надежный поток сообщений, т. е. данные разделяются на отдельные блоки, которые предоставляются потребителю данных в виде дискретных объектов.
Протоколы связи, реализующие надежные потоки байтов, как правило, на некотором ненадежном нижнем уровне, используют ряд механизмов для обеспечения этой надежности. Протоколы автоматического запроса на повторение (ARQ) играют важную роль в достижении надежности.
Все элементы данных идентифицируются порядковым номером , который используется как для того, чтобы убедиться, что данные доставлены сущности на другом конце в правильном порядке, так и для проверки потерянных элементов данных. Получатель отправляет обратно подтверждения для элементов данных, которые были успешно получены; таймер на отправителе вызовет тайм-аут , если подтверждение не получено в течение разумного времени приема-передачи , и (предположительно потерянные) данные будут затем повторно переданы . Чтобы проверить, что никакие элементы данных не повреждены, используется контрольная сумма ; она вычисляется на отправителе для каждого блока данных перед его отправкой и проверяется на получателе. Ошибочные или отсутствующие данные сообщаются отправителю, чтобы он мог повторно передать их. Любые дублированные элементы данных отбрасываются.
Блокировка начала очереди может возникнуть в надежных потоках байтов: если пакеты переупорядочены или потеряны и должны быть переданы повторно (и, таким образом, прибыть не по порядку), данные из последовательно более поздних частей потока могут быть получены до последовательно более ранних частей потока; однако более поздние данные обычно не могут быть использованы до тех пор, пока не будут получены более ранние данные, что приводит к задержке в сети . Если несколько независимых сообщений более высокого уровня инкапсулируются и мультиплексируются в один надежный поток байтов, то блокировка начала очереди может привести к обработке полностью полученного сообщения, которое было отправлено позже, для ожидания доставки сообщения, которое было отправлено ранее. [1] Это влияет, например, на HTTP/2 , который кадрирует несколько пар запрос-ответ в один поток; HTTP/3 , который имеет конструкцию кадрирования на уровне приложений и использует датаграмму , а не потоковый транспорт, избегает этой проблемы. [2] [3] Ухудшение задержки из-за блокировки начала очереди зависит от базовой скорости потери пакетов и времени приема-передачи , при этом более высокие потери приводят к большей задержке. [4] [5] Без изменения абстракции потока, уменьшение потери пакетов может уменьшить вред от блокировки начала очереди; альтернативой является реализация надежного потока байтов с использованием прямого исправления ошибок для отправки избыточных данных, чтобы можно было допустить определенную потерю без повторных передач. [1]