Транспортный уровень. Протокол управления передачей (Transmission Control Protocol — TCP)

Нумерация байт

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

Номера байтов

TCP нумерует все байты данных, которые передаются в соединении. Нумерация зависит от каждого направления. Когда TCP получает байты данных от процесса и накапливает их в буферах передачи, он нумерует их. Нумерация не обязательно начинается от 0 — она начинается со случайного числа. TCP генерирует случайный номер между 0 и 2^32-1 для номера первого байта. Например, если выпадает случайный номер 1 057 и всего посылается 6000 байт, байты нумеруются от 1 057 до 7 056.

После того как байты пронумерованы, TCP назначает порядковый номер для каждого сегмента, который посылается. Порядковый номер для каждого сегмента – это номер первого байта, переносимого в этом сегменте.

Пример 1

Представим себе, что TCP-соединение передает файл объемом 6000 байт. Первый байт пронумерован 10010. Каким будет порядковый номер для каждого сегмента, если данные посылаются в пяти сегментах, в первых четырех сегментах переносится 1000 байт, а в последнем — 2 000 байт?

Решение

Нижеследующее показывает порядковые номера всех сегментов:

Номер подтверждения

TCP обеспечивает дуплексную связь. Когда соединение установлено, обе стороны могут передавать и принимать данные одновременно. Каждая сторона нумерует байты, обычно с различными начальными номерами. Порядковый номер в каждом направлении показывает первый байт, переносимый в сегменте. Каждая сторона использует номер подтверждения, чтобы подтвердить полученные ей байты. Однако номер подтверждения определяет номер следующего байта, который каждая сторона ожидает получить. Кроме того, номер подтверждения является интегральным — это означает, что сторона приняла номер последнего байта, что он получен в сохранности и нормально, добавляет к нему 1 и устанавливает эту сумму как номер подтверждения. Термин "интегральная" здесь означает, что если сторона использует 5 643 как номер подтверждения, она получила все байты, начиная с 5 642 и ниже. Заметим, что это не означает, что сторона получила 5 642 байта, потому что первый байт может не иметь начального номера 0.

Управление потоком

Управление потоком — определение количества данных, которое может послать источник, прежде чем получить подтверждение от пункта назначения. В крайнем случае, протокол транспортного уровня мог бы послать 1 байт данных и ждать подтверждение, прежде чем послать следующий байт. Но это чрезвычайно медленный процесс. Если данные проходят большое расстояние, источник свободен, пока он ждет подтверждение.

Другой крайний случай — транспортный протокол посылает все данные, не беспокоясь о подтверждении. Это наиболее быстрый процесс, но он может нарушить работу приемника. Помимо того что некоторая часть данных теряется, дублируется, получается в беспорядке или искажается, источник не будет знать об этом, пока все не будет проверено пунктом назначения.

Для TCP выбрано решение, которое лежит где-то между этими крайностями. Протокол определяет окно, которое устанавливает ограничение на буфер доставки данных от прикладных программ и готовность к посылке. TCP посылает столько данных, сколько определено протоколом "скользящего окна" (sliding window).

Протокол "скользящего окна"

Для достижения управления потоком TCP использует протокол "скользящего окна". При таком методе оба хоста используют окно для каждого соединения. Окно выделяет небольшую часть буфера, содержащую байты, которые буфер может передать, прежде чем беспокоиться о подтверждении от другого хоста. Окно называется "скользящим окном", потому что оно может скользить как по буферу данных, так и по буферу подтверждения — изменяя при этом величину байтов, которые можно посылать и принимать без принятия или посылки сигнала подтверждения.

Рис. 10.4 показывает буфер передачи, определенный ранее на Рис. 10.1 и 10.2. Однако вместо буфера с обратной связью для упрощения показан простой буфер.

Рис. 10.4. Буфер передатчика

На рис. 10.4 байты перед 200 посланы и подтверждены. Передатчик может снова использовать эти места. Байты с 200 до 202 посланы, но не подтверждены.

Передатчик должен сохранить эти байты в буфере, на случай если они потеряны или искажены. Байты с 203 до 211 — в буфере (поставлены процедурой), но еще не переданы.

Давайте проанализируем ситуацию, в которой имеется протокол без скользящего окна. В этом случае передатчик может продвигаться вперед и посылать все байты (до 211 в его буфере), не заботясь о состоянии приемника. Если процесс приема идет не достаточно быстро, буфер приемника с его ограниченным размером может окончательно заполниться. Избыточные байты удаляются приемником, после чего приемник запросит повторную передачу. Поэтому передатчик должен сам регулировать число доступных мест в приемнике.

Окно приемника

Рис. 10.5 показывает буфер приемника. Заметим, что следующий байт, который будет принят процессом, – 194. Приемник ожидает получения от передатчика байта 200 (который послан, но не получен). Сколько байт может накопить приемник? Если общий размер буфера приемника N, а M мест уже занято, то может быть получено не только N-M байт. Например, на Рис. 10.5 N = 13, а M = 6, это означает, что может быть получено еще 7 байт. Это значение называется текущим окном приемника.

Рис. 10.5. Окно приемника

Создадим окно передатчика с размером менее и равным размеру окна приемника. Окно включает посланные байты и байты не подтвержденные, а также те, которые могут быть посланы. Рис. 10.6 показывает буфер передатчика с окном передатчика, равным размеру окна приемника. На рисунке показано, что это окно равно 7. Серым цветом показаны переданные байты, на которые не поступило подтверждение.

Рис. 10.6. Буфер передачи и окно передатчика

Передатчик не может послать количество байтов, равное размеру окна, поскольку он уже послал 3 байта. Он может посылать только 4 байта. Заметим также, что хотя байты от 207 до 211 находятся в буфере передачи, они также не могут быть посланы, пока еще не прибыло от приемника подтверждение уже посланных байтов.