
- •Глава 14 – Транспортный уровень.
- •14.0 Введение.
- •14.0.1 Почему я должен выполнить этот модуль?
- •14.0.2 Что я буду изучать в этом модуле?
- •14.1 Передача данных
- •14.1.1 Роль транспортного уровня
- •14.1.2 Функции транспортного уровня
- •14.1.3 Протоколы транспортного уровня
- •14.1.4 Протокол управления передачей (tcp)
- •14.1.5 Протокол пользовательских датаграмм (udp)
- •14.1.6 Соответствующий протокол транспортного уровня для соответствующего приложенияНачало формы
- •14.1.7 Проверьте ваше понимание темы - Передача данныхНачало формы
- •14.2 Обзор протокола tcp
- •14.2.1 Функции протокола tcp
- •14.2.2 Заголовок протокола tcp
- •14.2.3 Поля заголовка tcp
- •14.2.4 Приложения, использующие протокол tcp
- •14.2.5 Проверьте свое понимание темы - Обзор tcp
- •14.3 Обзор протокола udp
- •14.3.1 Функции протокола udp
- •14.3.2 Заголовок протокола udp
- •14.3.3 Поля заголовка udp
- •14.3.4 Приложения, использующие протокол udp
- •14.3.5 Проверьте свое понимание темы - Обзор udp
- •14.4 Номера портов
- •14.4.1 Несколько отдельных сеансов передачи данных
- •14.4.2 Пары сокетов
- •14.4.3 Группы номеров портов
- •14.4.4 Команда netstat
- •14.4.5 Проверить ваше понимание темы - Номера портов
- •14.5 Обмен данными по протоколу tcp
- •14.5.1 Процессы tcp-сервера
- •14.5.2 Установление tcp-соединения
- •14.5.3 Прекращение tcp-соединения
- •14.5.4 Анализ трехстороннего квитирования tcp
- •14.5.5 Видеоролик. Трехэтапное квитирование tcp
- •14.5.6 Проверьте ваше понимание темы - Процесс связи tcp
- •14.6 Надежность и управление потоком передачи данных
- •14.6.1 Надежность tcp - гарантированная и упорядоченная доставка
- •14.6.2 Видеоролик. Надежность tcp: порядковые номера и подтверждения
- •14.6.3 Надежность tcp: потеря данных и повторная передача
- •14.6.4 Видеоролик. Надежность tcp: потеря данных и повторная передача
- •14.6.5 Управление потоком tcp. Размер окна и подтверждения
- •14.6.6 Управление потоком tcp - максимальный размер сегмента (mss)
- •14.6.7 Управление потоком tcp. Предотвращение перегрузок
- •14.6.8 Проверьте свое понимание темы — надежность и управление потоком
- •14.7 Обмен данными по протоколу udp
- •14.7.1 Udp: низкие накладные расходы или надежность?
- •14.7.2 Сборка датаграмм udp
- •14.7.3 Процессы и запросы udp-сервера
- •14.7.4 Процессы udp-клиента
- •14.7.5 Проверьте ваше понимание темы - Процесс связи udp
- •14.8 Практика и контрольная работа модуля
- •14.8.1 Packet Tracer. Обмен данными с использованием tcp и udp
- •14.8.2 Что я изучил в этом модуле?
- •14.8.3 Контрольная по модулю - Транспортный уровень
14.6.3 Надежность tcp: потеря данных и повторная передача
Независимо от того, насколько хорошо разработана сеть, иногда происходит потеря данных. Протокол TCP обеспечивает возможности для управления потерянными сегментами. Среди них — механизм повторной передачи сегментов с данными, получение которых не было подтверждено.
До последующих усовершенствований, TCP мог подтвердить только ожидаемый следующий байт. Например, на рисунке, используя номера сегментов для простоты, узел A отправляет сегменты с 1 по 10 на узел B. Если все сегменты прибывают, за исключением сегментов 3 и 4, узел B отвечает с подтверждением, указав, что следующим сегментом является сегмент 3. Хост А понятия не имеет, прибыли ли какие-либо другие сегменты или нет. Таким образом, узел A будет повторно переслать сегменты 3-10. Если все повторные сегменты переданы успешно, сегменты с 5 по 10 будут дубликатами. Это может привести к задержкам, перегрузкам и неэффективности.
В настоящее время серверные операционные системы обычно используют опциональную функцию TCP, называемую выборочным подтверждением (SACK), согласованную во время трехстороннего рукопожатия. Если оба узла поддерживают SACK, принимающее устройство может явно определить, какие сегменты (байты) были получены, включая любые сегменты прерывания. Поэтому отправляющему хосту нужно будет только повторно передать недостающие данные. Например, на следующем рисунке, снова используя номера сегментов для простоты, узел A отправляет сегменты с 1 по 10 на узел B. Если все сегменты прибывают, кроме сегментов 3 и 4, узел B может подтвердить, что он получил сегменты 1 и 2 (ACK 3), и выборочно подтвердить сегменты с 5 по 10 (SACK 5-10). Хост A должен будет только повторно отправить сегменты 3 и 4.
Примечание: TCP обычно отправляет ACK для каждого следующего пакета, но другие факторы, выходящие за рамки данного раздела, могут изменить это поведение.
TCP использует таймеры, чтобы узнать, сколько времени ждать перед повторной отправкой сегмента. Нажмите кнопку «Воспроизведение» на рисунке, чтобы посмотреть видео, а затем щелкните ссылку для загрузки PDF-файла. Из этого видеоролика и PDF-файла вы узнаете о потерях данных и повторной передаче сегментов.
14.6.4 Видеоролик. Надежность tcp: потеря данных и повторная передача
Нажмите кнопку Play (Воспроизведение) на рисунке, чтобы ознакомиться с учебным материалом, посвященным повторной передаче TCP.
14.6.5 Управление потоком tcp. Размер окна и подтверждения
Протокол TCP обеспечивает механизмы для управления потоком данных. Управление потоком данных - это объем данных, которые получатель может получить и надежно обработать. Управление потоком позволяет поддерживать надежность передачи по протоколу TCP, регулируя скорость потока данных между узлами источника и назначения в течение определенного сеанса. Для этого, в заголовке TCP имеется 16-битное поле, которое называется размером окна.
На рисунке приведен пример размера окна и подтверждений.
показывает, что PCB отправляет PCA согласованный размер окна 10 000 байт и максимальный размер сегмента 1 460 байт. PCA начинает отправку сегментов, начиная с порядкового номера 1. Подтверждение от печатной платы может быть отправлено, не дожидаясь достижения размера окна и размер окна может быть скорректирован PCA, создавая скользящее окно
Пример размера окна TCP
Размер окна определяет количество байтов, которые могут быть отправлены до ожидания подтверждения. Номер подтверждения — номер следующего ожидаемого байта.
Размер окна — это количество байтов, которое устройство назначения способно принять и обработать за один раз во время сеанса TCP. В этом примере первоначальный размер окна узла PC B для представленного сеанса TCP установлен равным 10 000 байт. Начиная с первого байта (с порядковым номером 1), последним байтом, который узел PC A может отправить без получения подтверждения, будет 10 000-й байт. Это называется окном отправки ПК А. Размер окна включен в каждый сегмент TCP, поэтому получатель может изменить размер окна в любое время в зависимости от доступности буфера.
Изначальный размер окна согласуется во время установления сеанса TCP в процессе трехстороннего квитирования. Устройство источника должно ограничить количество байтов данных, отправленных устройству назначения, в соответствии с размером окна последнего. Только после получения подтверждения приема байтов устройством источника оно может продолжить отправку остальных данных в этом сеансе. Обычно узел назначения не дожидается получения всех байтов для заданного размера окна, чтобы отправить подтверждение. По мере получения и обработки байтов узел назначения отправляет подтверждения, чтобы сообщить узлу источника о возможности продолжать отправку дополнительных байтов.
Например, ясно, что ПК B не будет ждать, пока все 10000 байтов будут получены, прежде чем отправлять подтверждение. Это означает, что ПК A может настраивать свое окно отправки, когда он получает подтверждения от ПК B. Как показано на рисунке, когда ПК A получает подтверждение с номером подтверждения 2921, который является следующим ожидаемым байтом. Окно отправки ПК A будет увеличиваться 2 920 байт. Это изменит окно отправки с 10 000 байт до 12 920. После этого узел PC A может продолжить отправку следующих 10 000 байт на узел PC B, пока на 12 920-м байте не будет достигнуто новое окно отправки.
Процесс отправки подтверждений узлом назначения по мере обработки полученных байтов и непрерывная регулировка окна отправки источника называются скользящими окнами. В предыдущем примере, окно отправки ПК A увеличивается или перемещается на 2 921 байт от 10 000 до 12 920.
Когда доступное пространство в буфере узла назначения снижается, он может уменьшить размер окна и сообщить узлу источника о том, сколько байт теперь источнику следует отправлять без получения подтверждения.
Примечание: Устройства обычно используют протокол скользящих окон. Получатель обычно отправляет подтверждение после получения каждых 2 сегментов. Количество таких сегментов, после которых отправляется подтверждение, может варьироваться. Преимущество скользящих окон состоит в том, что этот протокол позволяет отправителю передавать сегменты непрерывно в том случае, если получатель подтверждает получение предыдущих сегментов. Подробные сведения о скользящих окнах не рассматриваются в этой учебной программе.