ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 22.11.2023
Просмотров: 18
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Основы надежной передачи данных
7 мин
20K
Сетевые технологии*Go*Учебный процесс в ITКарьера в IT-индустрии
Туториал
Тем, кто стремится разобраться в сетях и протоколах, посвящается.
Кратко
Протокол транспортного уровня
Обеспечивает логическое соединение между прикладными процессами, выполняющимися на разных хостах. Логическое соединение с точки зрения приложений выглядит как канал, непосредственно соединяющий процессы.
Протоколы транспортного уровня поддерживаются конечными системами, но не сетевыми маршрутизаторами (кроме — DPI). На стороне отправителя транспортный уровень преобразует данные прикладного уровня, которые получает от передающего прикладного процесса, в пакеты транспортного уровня, называемые сегментами.
Это делается разбиением (при необходимости) сообщений прикладного уровня на фрагменты и добавлением к каждому из них заголовка транспортного уровня.
Далее транспортный уровень передает сегмент сетевому уровню отправителя, где сегмент инкапсулируется в пакет сетевого уровня (дейтаграмму) и отсылается. На принимающей стороне сетевой уровень извлекает сегмент транспортного уровня из дейтаграммы и передает его вверх транспортному уровню. Далее транспортный уровень обрабатывает полученный сегмент таким образом, чтобы его данные стали доступны приложению-получателю.
Принципы надежной передачи данных
Надежная передача данных по совершенно надежному каналу
Простейший случай. Отправляющая сторона просто принимает данные от верхнего уровня, создает содержащий их пакет и отправляет его в канал.
Сервер
Клиент
package main
import (
"fmt"
"log"
"net"
"time"
)
func main() {
// IP-адрес сервера и порт
serverAddr, err := net.ResolveUDPAddr("udp", "127.0.0.1:12000")
if err != nil {
log.Fatal(err)
}
// локальный IP-адрес и порт
localAddr, err := net.ResolveUDPAddr("udp", "127.0.0.1:0")
if err != nil {
log.Fatal(err)
}
// установка соединения
conn, err := net.DialUDP("udp", localAddr, serverAddr)
if err != nil {
log.Fatal(err)
}
// отложенное закрытие соединения
defer conn.Close()
for {
// получение данных от ВЕРХНЕГО уровня
fmt.Print("Введите строчное предложение > ")
var msg string
_, err := fmt.Scanf("%s", &msg)
if err != nil {
log.Fatal(err)
}
// передается поток байт, а не строка
buf := []byte(msg)
// запись (передача) в соединение
_, err = conn.Write(buf)
if err != nil {
log.Fatal(err)
}
// 1 секундочку
time.Sleep(time.Second * 1)
}
}
Надежная передача данных по каналу с возможными ошибками
Следующим этап — это предположение, что все переданные пакеты получены в том порядке, в котором они были отправлены, но биты в них могут быть повреждены, в связи с тем, что канал иногда передает данные с искажениями.
В таком случае применяются механизмы:
-
обнаружения ошибки; -
обратной связи; -
повторной передачи.
Протоколы надежной передачи данных, обладающие подобными механизмами многократного повторения передачи, называются протоколами с автоматическим запросом повторной передачи (Automatic Repeat reQuest, ARQ).
Дополнительно, стоит предусмотреть возможность ошибок и в квитанциях, когда принимающая сторона не получит никакой информации о результатах передачи последнего пакета.
Решение этой задачи, используемое в том числе в TCP, состоит в добавлении в пакет данных нового поля, содержащего порядковый номер пакета.
Надежная передача данных по ненадежному каналу, допускающему искажение и потерю пакетов
Одновременно с искажениями, к сожалению, в сети присутствует потеря пакетов.
И для решения этой задачи требуются механизмы:
-
определения факта потери пакетов; -
повторной доставки потерянных пакетов принимающей стороне.
Дополнительно, кроме потери пакета, необходимо предусмотреть возможность потери квитанции или, если ничего не потеряно, ее доставки со значительной задержкой. Во всех случаях производится одно и то же: повторная передача пакета. Для контролирования времени в данном механизме используется таймер отсчета, который позволяет определить окончание интервала ожидания. Так в пакете net параметр TCPKeepAlive установлен на 15 секунд по умолчанию:
// defaultTCPKeepAlive is a default constant value for TCPKeepAlive times
// See golang.org/issue/31510
const (
defaultTCPKeepAlive = 15 * time.Second
)
Передающей стороне необходимо запускать таймер каждый раз при передаче пакета (как при первой, так и при повторной), обрабатывать прерывания от таймера и останавливать его.
Итак, мы ознакомились с ключевыми понятиями протоколов надежной передачи данных:
-
контрольными суммами; -
порядковыми номерами пакетов; -
таймерами; -
положительными и отрицательными квитанциями.
Но и это не все!
Протокол надежной передачи данных с конвейеризацией
В том варианте, который мы уже рассмотрели, протокол надежной доставки очень неэфективен. Он начинает «тормозить» передачу, обеспечиваемую каналом связи, при увеличении RTT. Для повышения его эффективности, лучшей утилизации пропускной способности канала связи применяют конвейеризацию.
Применение конвейеризации приводит к:
-
увеличению диапазона порядковых номеров, поскольку все отсылаемые пакеты (за исключением повторных передач) должны быть однозначно идентифицируемы; -
необходимости в увеличении буферов на передающей и принимающей сторонах.
Диапазон порядковых номеров и требования к размерам буферов зависят от действий, предпринимаемых протоколом в ответ на искажение, потерю и задержку пакета. В случае конвейеризации существуют два метода исправления ошибок:
-
возвращение на N пакетов назад; -
выборочное повторение.
Возвращение на N пакетов назад — протокол скользящего окна
Отправитель должен поддерживать три типа событий:
-
вызов протоколом более высокого уровня. Когда «сверху» вызывается функция отправки данных, передающая сторона сначала проверяет степень заполнения окна (то есть наличие N посланных сообщений, ожидающих получения квитанций). Если окно оказывается незаполненным, новый пакет формируется и передается, а значения переменных обновляются. В противном случае передающая сторона возвращает данные верхнему уровню, и это является неявным указанием, что окно заполнено. Обычно верхний уровень предпринимает повторную попытку передачи данных через некоторое время. В реальном приложении отправитель, скорее всего, либо буферизовал бы данные (вместо немедленной отсылки), либо имел механизм синхронизации (например, семафор или флаг), который позволял бы вышестоящему уровню вызывать функцию отправки данных только при незаполненном окне. -
получение подтверждения. В протоколе для пакета с порядковым номером N выдается общая квитанция, указывающая на то, что все пакеты с порядковыми номерами, предшествующими N, успешно приняты. -
истечение интервала ожидания. Для определения фактов потерь и задержек пакетов и квитанций протокол использует таймер. Если интервал ожидания истекает, передающая сторона повторно отправляет все посланные неподтвержденные пакеты.
Выборочное повторение
Когда размер окна и произведение пропускной способности на задержку распространения велики, в конвейере может находиться большое количество пакетов. В таком случае ошибка отдельного пакета может вызвать повторную передачу большого количества пакетов, большинство из которых не требовались.
Пример
Лучшие теоритические практики собраны в практической реализации TCP. А если кто-то знает, как лучше — welcome.
Сервер
Клиент
Вывод
Механизмы, обеспечивающие надежную передачу данных и их использование
| Механизм | Применение, комментарий |
| Контрольная сумма | Используется для обнаружения битовых ошибок в переданном пакете |
| Таймер | Отсчет интервала ожидания и указание на его истечение. Последнее означает, что с высокой степенью вероятности пакет или его квитанция потеряны при передаче. В случае, если пакет доставляется с задержкой, но не теряется (преждевременное истечение интервала ожидания), либо происходит потеря квитанции, повторная передача приводит к дублированию пакета на принимающей стороне |
| Порядковый номер | Используется для порядковой нумерации пакетов данных передаваемых от отправителя к получателю. Разрывы в порядковых номерах полученных пакетов позволяют получателю обнаружить потерю пакета. Одинаковые порядковые номера пакетов означают, что пакеты дублируют друг друга |
| Подтверждение | Генерируется принимающей стороной и указывает передающей стороне на то, что соответствующий пакет или группа пакетов успешно приняты. Обычно подтверждение содержит порядковые номера успешно принятых пакетов. В зависимости от протокола различают индивидуальные и групповые подтверждения |
| Отрицательное подтверждение | Используется получателем для сообщения отправителю, что пакет был получен некорректно. Отрицательное подтверждение обычно включает в себя порядковый номер пакета, который не был корректно получен |
| Окно, конвейеризация | Ограничивают диапазон порядковых номеров, которые могут использоваться для передачи пакетов. Групповая передача и рукопожатие позволяют значительно увеличить пропускную способность протоколов по сравнению с режимом ожидания подтверждений. Как мы увидим, размер окна может быть рассчитан на основе возможностей приема и буферизации принимающей стороны, а также уровня загрузки сети |