□ Производится проверка разрешения шлюзования.[87] В случае отрицательного результата хост не может выполнять функции шлюза и данные уничтожаются.
□ Производится проверка адреса получателя. Если адрес датаграммы не принадлежит адресному пространству сетей класса А, В или С, такие данные не могут быть переданы.[88]
□ Определяется дальнейший маршрут передачи датаграммы.
□ Если дальнейший путь датаграммы проходит через тот же интерфейс, с которого она была получена, и хост-отправитель расположен в той же сети, ему отправляется сообщение ICMP REDIRECT.
□ Производится вызов функции ip_output(), выполняющей передачу датаграммы хосту-адресату или соседнему шлюзу для дальнейшей передачи.
При выполнении этих функций модуль IP может обнаружить несколько ошибочных ситуаций, например, отсутствие маршрута для датаграммы или невозможность передачи данных из-за переполнения в сети. В этих случаях модуль формирует соответствующее сообщение ICMP и передает его отправителю датаграммы. Эти сообщения ICMP и причины их отправки приведены в табл. 6.9.
Таблица 6.9. Сообщения ICMP
Сообщение Причина DESTINATION UNREACHABLE Невозможно доставить датаграмму. Причин может быть несколько: 1. Отсутствует маршрут к сети 2. Отсутствует маршрут к хосту 3. Для передачи необходима фрагментация, но в заголовке установлен флаг DF (Don't Fragment) SOURCE QUENCH Переполнение сети. Шлюз передает это сообщение, запрашивая отправителя на уменьшение скорости передачи данных TIME EXCEEDED Тайм-аут. Причины могут быть две: 1. Истекло время жизни датаграммы в сети (TTL=0) 2. Произошел тайм-аут реассемблирования, т.е. через определенный промежуток времени получены не все фрагменты датаграммы
При вызове функции ip_output() ей передается датаграмма, которую необходимо отправить, указатель на маршрут (структура route, хранящаяся в управляющем блоке), а также флаги (например, указание не использовать маршрутизационные таблицы). Передача маршрута не является обязательной. Если функции не передан указатель на маршрут, будет использован маршрут из таблицы маршрутизации. В противном случае будет произведена проверка переданного маршрута, и при необходимости его значение будет обновлено для последующего использования.
Функция ip_output() может быть вызвана и модулем транспортного протокола (UDP или TCP). Каким образом это происходит, описано в следующем разделе.
Модуль UDP
Вернемся к рассмотрению ситуации, когда датаграмма адресована нашему хосту, не содержит ошибок (по крайней мере, с точки зрения IP) и должна быть передана транспортному протоколу. Поскольку целью данного раздела является иллюстрация схемы взаимодействия между модулями, рассмотрим более простой протокол UDP.
Итак, IP-модуль направляет датаграмму модулю UDP, вызывая функцию udp_input(), адрес которой был получен из соответствующего коммутатора протокола. Сначала функция udp_input() проверяет правильность контрольной суммы и допустимость установленных полей заголовка. Если указанные проверки закончились неудачно, пакет "молчаливо" уничтожается. Далее определяется получатель пакета. Для этого на основании адресов и номеров портов отправителя и получателя производится поиск соответствующего управляющего блока протокола.[89] В системе могут существовать несколько управляющих блоков с одинаковым номером локального порта, но с различными адресами и/или номерами портов отправителя. В этом случае выбирается блок, для которого найдено лучшее совпадение по всем четырем параметрам. Конечно, лучшим является точное совпадение, но если такового не найдено, будет выбран блок с совпадающим номером локального порта, но неуказанным адресом и/или номером порта отправителя. Таким образом, управляющий блок, у которого не указаны часть или все четыре параметра, является получателем всех пакетов, для которых не найдено лучшего совпадения.[90]
Если управляющий блок найден, данные и адрес отправителя помещаются в буфер приема сокета, связанного с управляющим блоком. В противном случае генерируется сообщение ICMP PORT UNREACHABLE.
Передача данных от приложения инициируется системным вызовом sendto(2), который на уровне сокета преобразуется в вызов функции udp_usrreq() с запросом PRU_SEND. Если передача инициирована системным вызовом sendto(), то вместе с данными передается адрес получателя. Если же данные были переданы с помощью системного вызова send(2), то адрес получателя определяется из управляющего блока, где он был сохранен предшествующим вызовом connect(2).[91]
Фактическая передача осуществляется функцией udp_output(), которая формирует заголовок пакета, устанавливает значения его полей и вычисляет контрольную сумму. После этого производится вызов уже рассмотренной ранее функции ip_output().
Модуль TCP
Как следует из предшествующего описания TCP, этот транспортный протокол обеспечивает гораздо более высокое качество передачи, чем UDP. Соответственно, его реализация также является гораздо более сложной. В предыдущих разделах уже встречались различные алгоритмы, используемые при реализации протокола. В этом разделе мы остановимся на одном важном механизме TCP — его таймерах.
Поскольку корректное функционирование протокола во многом зависит от порядка обмена управляющими сегментами, каждый канал обслуживается набором таймеров, позволяющих восстановить работу по тайм-ауту в случае потери управляющих пакетов. Эти таймеры хранятся в соответствующем управляющем блоке протокола TCP и, при их установке, обслуживаются[92] каждые 500 миллисекунд функцией tcp_slowtimo().
Для обеспечения передачи данных используются два таймера. Первый из них — таймер повторной передачи (retransmit timer). Этот таймер запускается при передаче сегмента, если он уже не был запущен. Если подтверждение получено, и отсутствуют неподтвержденные данные — таймер останавливается. Если же такие данные существуют, значение таймера присваивается равным начальному, и таймер запускается снова. Если значение таймера становится равным нулю, наиболее старые неподтвержденные данные передаются повторно (как минимум один полный сегмент), а таймер запускается снова, но уже с большим значением. Скорость увеличения значения таймера (timer backoff) определяется по специальной таблице и имеет экспоненциальный характер.
Второй таймер — это persist-таймер (таймер сохранения). Этот таймер обеспечивает защиту от потери управляющих сообщений, содержащих значения окна. В случае, если отправитель готов передать данные, но анонсированное получателем окно слишком мало (равно нулю или меньше определенного значения), и отсутствуют неподтвержденные данные (т. е. таймер повторной передачи не включен), включается таймер сохранения. Если таймер срабатывает (его значение становится равным нулю), а обновленное значение так и не получено, отправитель передает максимально допустимый объем данных, определяемый текущим окном. Если же в этом случае значение текущего окна равно нулю (нулевое окно), то передается пробный сегмент (window probe), содержащий один октет данных, и таймер запускается снова. Если сообщение с обновленным значением окна было утеряно, или получатель по-прежнему отказывается изменить его размер, будет получено подтверждение, содержащее текущее значение окна. Такая ситуация, когда получатель не может принимать дополнительные данные, может продлиться достаточно долго. Например, пользователь может приостановить терминальный вывод и уйти на обед. В этом случае отправитель будет периодически посылать пробные сегменты, а его окно будет по-прежнему закрыто.
Следующий таймер, который мы рассмотрим, — keepalive-таймер. Этот таймер предназначен для мониторинга каналов, по которым не передаются данные, и которые возможно в действительности прекратили свое существование, например, из-за аварийного останова одной из систем. Если за определенный промежуток времени данные по каналу переданы не были, модуль TCP отправляет пробный сегмент keepalive, ожидая в ответ либо подтверждения (это означает, что задержка в передаче данных временная), либо сообщения сброса канала (RST). Если получен сегмент RST, канал будет закрыт. Если после нескольких попыток, не будет получен отклик, канал будет уничтожен.
Последний таймер из рассматриваемых, это 2MSL-таймер (2MSL — двойное максимальное время жизни сегмента в сети). Модуль TCP запускает этот таймер, когда производится завершение связи, и уже отправлено подтверждение полученному сегменту FIN. При этом отправитель не знает, получено ли его подтверждение. Поэтому он некоторое время ждет возможного повторного получения сегмента FIN, чтобы в свою очередь повторить подтверждение. Таймер запускается при переходе коммуникационного узла канала в состояние TIME-WAIT, и после его срабатывания соответствующий управляющий блок удаляется. Заметим, что это ожидание не блокирует процесс, выполнивший системный вызов close(2) сокета, отвечающего за данный канал. Другими словами, управляющий блок может существовать еще некоторое время после закрытия дескриптора сокета.
