Мы можем посмотреть, как ICMP ошибка о недоступности хоста обрабатывается на нашем SLIP канале, когда он погашен в середине соединения. Мы установили соединение с хоста slip на хост aix. (На рисунке, находящемся на внутренней стороне обложки, мы видим, что это соединение проходит через SLIP канал.) После установления соединения и передачи какого-то количества данных, SLIP канал между маршрутизаторами sun и netb погашен. При этом запись, соответствующая маршруту по умолчанию в sun (которую мы показывали на рисунке 9.2), будет удалена. Ожидается, что sun затем будет отвечать на IP датаграммы, направляемые в Ethernet сеть 140.252.1, ошибкой ICMP о недоступности хоста. Мы хотим посмотреть, как TCP обрабатывает эти ICMP ошибки.
Здесь приведена интерактивная сессия на хосте slip:
slip % sock aix echo запускаем программу sock test line вводим эту строку test line она отображается эхом в этом месте SLIP канал выключен another line затем вводим эту строку и смотрим повторные передачи здесь SLIP канал восстановлен another line и происходит обмен строкой и ее эхом line number 3 line number 3 the last line SLIP канал погашен и не восстановлен read error: No route to host TCP в конце концов закрывает соединение
На рисунке 21.12 показан соответствующий вывод команды tcpdump, полученный на маршрутизаторе bsdi. (Установление соединения и все объявления окна удалены.) Мы подсоединились к эхо серверу на хосте aix и напечатали "test line" (строка 1). Она отразилась эхом (строка 2), и эхо было подтверждено (строка 3). Затем мы погасили SLIP канал.
Затем ввели "another line" (строка 3) и ожидаем, что TCP отработает тайм-аут и повторно передаст сообщение. И действительно, эта строка отправляется шесть раз перед тем, как будет получен отклик. Строки 4-13 показывают первую передачу и следующие четыре повторные передачи, каждая из которых генерирует ICMP ошибку о недоступности хоста с маршрутизатора sun. Это как раз то, что мы ожидали: IP датаграммы, двигаются от slip к маршрутизатору bsdi (который имеет маршрут по умолчанию, указывающий на sun) и затем на sun, где и находится поврежденный канал.
Пока происходят эти повторные передачи, SLIP канал восстанавливается, и повторная передача в строке 14 достигают пункта назначения. Строка 15 это эхо от aix, а строка 16 - подтверждение на эхо.
Можно сделать вывод, что TCP игнорирует ICMP ошибку о недоступностии хоста и продолжает осуществлять повторные передачи. Мы также видим ожидаемое экспотенциальное наращивание времени в каждом тайм-ауте при повторной передаче: первый возникает через 2,5 секунды, затем умножается на 2 (при этом длительность тайм-аута составляет 5 секунд), затем на 4 (10 секунд), затем на 8 (20 секунд) и затем на 16 (40 секунд).
После чего мы напечатали третью строку ввода ("line number 3") и увидели, что она отправлена в строке 17, отражена эхом в строке 18, и эхо подтверждено в строке 19.
Сейчас мы хотим посмотреть, что произойдет, когда TCP осуществляет повторную передачу, а затем прекращает попытки после получения ICMP ошибки о недоступности хоста. Для этого мы снова выключаем SLIP канал. После того как канал выключен, мы печатаем "the last line" и видим, что она передается 13 раз перед тем, как TCP прекращает попытки. (Строки 30-43 удалены из вывода. В них показаны дополнительные повторные передачи.)
Необходимо обратить внимание на одну деталь которая, заключается в том, что сообщение об ошибке печатается нашей программой sock, когда она в конце концов прекращает работу: "No route to host". (Нет маршрута к хосту.) Это соответствует ошибке операцинной системы Unix, которая, в свою очередь соответствует ICMP ошибке о недоступности хоста (рисунок 6.12). Значит, TCP сохраняет ICMP ошибку, которую он получил по соединению, и когда он в конце концов прекращает свою работу, то печатает эту ошибку вместо "Connection timed out" (соединение закрыто по тайм-ауту).
И в заключение, обратите внимание на то, что временные промежутки между повторными передачами в строках 22-46 сравнимы с промежутками в строках 6-14. Это происходит из-за того, что TCP обновил свои оценочные функции, когда третья строка, которую мы напечатали, была отправлена и подтверждена без повторных передач в строках 17-19. Исходный тайм-аут повторной передачи в настоящее время равен 3 секундам, при этом последующие значения будут равны 6, 12, 24, 48 и затем верхний предел 64.