Эндрю Уэзеролл - Компьютерные сети. 5-е издание

Хотя такого протокола обычно бывает вполне достаточно, теоретически он может ошибиться, если потеряются начальный запрос разъединения DR и все N повторных попыток. Отправитель сдается и разрывает соединение, тогда как другая сторона ничего не знает о попытках разорвать связь и сохраняет активность. В результате получается полуоткрытое соединение.

Рис. 6.11.Четыре сценария разрыва соединения: а — нормальный случай «тройного рукопожатия»; б — потеряно последнее подтверждение; в — потерян ответ; г — потерян ответ и последующие запросы

Этой ситуации можно было бы избежать, если не позволять отправителю сдаваться после N повторных попыток, а заставить его продолжать попытки, пока не будет получен ответ. Однако, если другой стороне будет разрешено разрывать связь по таймеру, тогда отправитель действительно будет вечно повторять попытки, так как ответа он не получит никогда. Если же получающей стороне также не разрешать разрывать соединение по таймеру, тогда протокол зависнет в ситуации, изображенной на рис. 6.11, г.

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

На этом мы заканчиваем обсуждение данного вопроса, но теперь должно быть ясно, что разорвать соединение без потери данных не так просто, как это кажется на первый взгляд. Из всего сказанного выше можно сделать вывод, что потребитель транспортных услуг должен принимать участие в решении вопроса о разрыве соединения — транспортная подсистема не может сама с этим справиться. Обратите внимание на то, что хотя TCP обычно использует симметричный разрыв связи (при этом каждая сторона независимо прерывает свое соединение, отправляя пакет FIN после окончания передачи данных), веб-серверы часто передают клиентам специальный пакет RST, сообщающий о мгновенном разрыве соединения — что больше похоже на асимметричный разрыв. Это возможно только благодаря тому, что веб-сервер знаком с процедурой обмена данными. Сначала он получает запрос от клиента (единственное, что отправляет клиент), а затем отсылает клиенту ответ. Таким образом, после отправки этого ответа обмен данными завершен: каждая сторона передала другой то, что требовалось. Поэтому сервер может резко разорвать соединение, отправив клиенту предупреждение. Получив это предупреждение, клиент сразу же разорвет соединение. Если предупреждение не дойдет до клиента, он через какое-то время поймет, что сервер с ним больше не общается, и также разорвет соединение. В любом случае данные будут успешно переданы.

6.2.4. Контроль ошибок и управление потоком данных

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

Оба этих вопроса мы уже обсуждали, когда говорили о канальном уровне. На транспортном уровне используются те же механизмы, которые описаны в главе 3. Вкратце они выглядят так.

1. Фрейм содержит код с обнаружением ошибок (например, CRC-код или контрольную сумму), с помощью которого проверяется, правильно ли была доставлена информация.

2. Фрейм содержит идентифицирующий порядковый номер и передается отправителем до тех пор, пока не придет подтверждение об успешной доставке. Это называется ARQ( Automatic Repeat reQuest— автоматический запрос повторной передачи).

3. Число кадров, передаваемых отправителем в любой момент времени, обычно ограничено: передача приостанавливается, если подтверждения приходят недостаточно быстро. Если этот максимум равен одному пакету, протокол называется протоколом с остановкой и ожиданием подтверждения( stop-and-wait). Окна большего размера позволяют использовать конвейерную обработку, а также улучшить производительность при работе с длинными и быстрыми линиями.

4. Протокол скользящего окна( sliding window) сочетает в себе все эти возможности, а также поддерживает двунаправленную передачу данных.

Если эти механизмы применяются к кадрам на канальном уровне, то возникает логичный вопрос: как это можно перенести на сегменты транспортного уровня? На практике оказывается, что канальный и транспортный уровни во многом копируют друг друга. Но хотя к ним и применимы одинаковые механизмы, существуют различия в их функционировании и качестве.

Чтобы проиллюстрировать различие в функционировании, обратимся к обнаружению ошибок. Контрольная сумма канального уровня защищает кадр, пока он передается по одному каналу. Контрольная сумма транспортного уровня защищает сегмент, пока он передается по всему пути. Это сквозная проверка, отличная от проверки в каждом канале. Существуют примеры повреждения пакетов даже внутри маршрутизаторов (Saltzer и др., 1984): контрольные суммы канального уровня обеспечивали защиту пакетов, пока они передвигались по каналу, но не тогда, когда они были внутри маршрутизатора. В результате мы имеем дело с некорректной доставкой, хотя проверка на каждом канале не выявила ошибок.

Этот и другие примеры позволили ученым (Slatzer и др.) сформулировать «сквозной» принцип( end-to-end argument). Согласно этому принципу, сквозная проверка, выполняемая на транспортном уровне, является необходимой для корректной передачи данных; проверка, выполняемая на канальном уровне, не является необходимой, но позволяет существенно улучшить производительность (так как иначе поврежденный пакет будет все равно проходить весь путь, что приведет к лишней нагрузке на сеть).