Протокол потоковой передачи передает из одной точки в другую связанную серию элементов, которые могут быть битами, байтами, сегментами или сообщениями, с гарантией, что они будут доставлены получателю в том порядке, в котором отправитель отправил их.
Потоковый протокол обычно (но не всегда) обеспечивает дополнительные гарантии, такие как отсутствие недостающих элементов, отсутствие дублирующих элементов и целостность данных. Поскольку телефонная линия имеет некоторые из этих же свойств, иногда говорят, что протокол потоковой передачи создает виртуальную цепь.
Простой способ доставки вещей для того, чтобы доставить их, заключается в использовании блокирующего пошагового протокола передачи, в котором отправляющая сторона не отправляет следующий элемент, пока принимающая сторона не признает, что предыдущий благополучно прибыл. Однако приложения часто выбирают потоковые протоколы для отправки больших объемов данных, и задержки в обе стороны пути, связанные с протоколом блокировки передачи, являются достаточной проблемой, поскольку потоковые протоколы почти всегда используют некоторую форму перекрытия передачи данных. При добавлении перекрывающейся передачи, несколько одновременно выполняющих маршрутизацию элементов могут попасть на сторону получателя не по назначению. Два совершенно разных события могут привести к тому, что элементы выйдут из строя: различные пакеты могут идти разными путями, которые имеют разное время прохождения, или пакет может быть отброшен, если он проходит через перегруженную часть сети или поврежден шумом. Отброшенный пакет придется пересылать заново, так что его замена почти наверняка придет намного позже, чем его соседние товарищи.
https://pixabay.com/ru/vectors/%D1%81%D0%B5%D1%82%D1%8C-%D0%BF%D0%BE%D0%B4%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B0%D0%B1%D0%BE%D1%87%D0%B8%D0%B5-%D1%81%D1%82%D0%B0%D0%BD%D1%86%D0%B8%D0%B8-150502/
Транспортный протокол может обеспечить доставку элементов данных в надлежащем порядке, добавив в заголовок транспортного уровня серийный номер, указывающий на место в потоке, к которому принадлежит данный элемент или элементы в текущем сегменте данных. На стороне получателя протокол доставляет элементы в приложение и отправляет подтверждение обратно отправителю до тех пор, пока они поступают по порядку. Когда элементы выходят из строя, протокол может следовать одной из двух стратегий:
- Подтверждать только тогда, когда прибывающий элемент является следующим ожидаемым элементом или дубликатом ранее полученного элемента. Избавьтесь от остальных. Эта стратегия проста, но требует ретрансляции элементов, поступающих до их предшественников, впустую потраченной впустую.
- Признавать каждый элемент по мере его поступления и удерживать в буферах любые элементы, которые поступают до их предшественников. Когда, наконец, прибудут предшественники, протокол может доставить элементы в приложение, чтобы упорядочить и освободить буферы. Этот метод более эффективен в использовании сетевых ресурсов, но он требует некоторой осторожности, чтобы избежать использования большого количества буферов в ожидании более раннего элемента, который был в пакете, который был утилизирован или поврежден.
Обе стратегии могут быть объединены путем подтверждения наличия элемента раннего прибытия только при наличии буфера для его хранения и отказа от любых других. При таком подходе возникает вопрос о том, какой объем буферного пространства необходимо выделить. Одним из простых ответов является предоставление по крайней мере достаточного буферного пространства для хранения всех элементов, которые, как ожидается, будут поступать в течение времени, необходимого для решения неупорядоченного состояния. Этот вопрос тесно связан с рассмотренным ранее вопросом о том, сколько буферов необходимо обеспечить для работы с данным размером раздвижного окна. Требование о доставке заказа является одной из причин, по которой полезно провести четкое различие между подтверждением получения данных и открытием окна, позволяющего отправлять больше данных.
Возможно, удастся ускорить повторную отправку потерянных пакетов, воспользовавшись дополнительной информацией, подразумеваемой получением нумерованных элементов потока. Если элементы потока поступают достаточно регулярно, но отсутствует один элемент потока, вместо того, чтобы ждать, пока отправитель выйдет из строя и повторно отправит, получатель может послать явное отрицательное подтверждение (NAK) отсутствия элемента. Если обычная причина отсутствия элемента заключается в том, что он был потерян, отправка NAK может привести к значительному повышению производительности. С другой стороны, если обычная причина заключается в том, что отсутствующий элемент просто перенес небольшую дополнительную задержку на этом пути, то отправка NAK может привести к ненужным ретрансляциям, что приведет к потере пропускной способности сети и ухудшению производительности. Решение об использовании этого метода зависит от конкретных текущих условий работы сети. Можно попытаться разработать алгоритм, который бы выяснил, что происходит (например, если службы NAK вызывают дублирование, прекратите отправку NAK), но он может не стоить того, чтобы усложнять ситуацию.
Как предполагает интерфейс, использование протокола переноса потока подразумевает вызов для открытия потока, серию вызовов для записи в поток или чтения из него, и вызов для закрытия потока. Открытие потока включает в себя создание записи на каждом конце соединения. В этом отчете отслеживается, какие элементы были отправлены, какие получены, а какие признаны. Закрытие русла связано с двумя дополнительными соображениями. Во-первых, после того, как принимающая сторона транспортного протокола доставит последний элемент потока в принимающее приложение, ему нужно будет сообщить в это приложение индикацию конца потока. Во-вторых, оба конца соединения должны согласиться с тем, что сеть доставила последний элемент и поток должен быть закрыт. Для достижения этой договоренности требуется определенная осторожность.
Простой протокол, обеспечивающий согласие, заключается в следующем: Предположим, что Элис открыла ручей к Бобу, и теперь решила, что ручей больше не нужен. Она начинает настойчиво отправляет ближайший запрос Бобу, указывая идентификатор потока. Боб, получив запрос, проверяет, согласен ли он с тем, что поток больше не нужен. Если он согласен, он начинает настойчиво отправлять близкое подтверждение, снова указывая идентификатор потока. Алиса, получив подтверждение, может отключить своего настойчивого отправителя и отказаться от записи потока, будучи уверена, что Боб получил все элементы потока и не будет делать никаких запросов на ретрансляцию. Кроме того, она посылает Бобу одно сообщение "all done", содержащее идентификатор потока. Если она получит дубликат близкого подтверждения, то ее запись потока уже будет удалена, но это не имеет значения; она может предположить, что это дубликат близкого подтверждения из какого-то ранее закрытого потока и из информации в близком подтверждении, она может сфабриковать сообщение "all done" и отправить его Бобу. Когда Боб получит сообщение "все готово", он может отключить своего постоянного отправителя и, будучи уверен, что Элис согласна с тем, что дальнейшая польза от потока не будет иметь места, отбросить свою копию записи потока. Элис и Боб могут в будущем безопасно отбрасывать любые поздние дубликаты, в которых упоминается поток, для которого у них нет записи. (Проблема все еще существует для самого ручья. Было бы неплохо, если бы Боб задержал удаление своей записи до тех пор, пока не появится долгожданный дубликат оригинального запроса Элис на открытие потока).