Краткие выводы

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

TCP рассчитывает время возврата и затем использует полученные значения, чтобы поддерживать и обновлять значение хэшированной оценочной функции RTT и хэшированной оценочной функции среднего отклонения. Эти два показателя затем используются при расчете следующего значения тайм-аута для повторной передачи. Большинство реализаций рассчитывают только один RTT на окно. Алгоритм Карна снимает проблему двусмысленной повторной передачи, поэтому не приходится рассчитывать RTT в случае потери пакета.

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

Мы закончили рассмотрением влияния различных ICMP ошибок на TCP соединение, и как TCP позволено перестраивать порядок движения данных. Мы видели, что "мягкие" ICMP ошибки не приводят к разрыву соединения, однако запоминаются таким образом, что когда соединение разрывается по каким-либо причинам, ошибка может быть выведена в виде сообщения.

Краткие выводы

Устойчивый таймер TCP устанавливается одним концом соединения, когда у него есть данные, которые необходимо отправить, однако отправка была остановлена, потому что другой конец соединения объявил окно нулевого размера. Отправитель отправляет пробы окна, при этом интервал повторной передачи рассчитывается так, как это делалось в главе 21. Отправка проб закрытого окна продолжается постоянно.

С помощью примеров, работы устойчивого таймера, мы видели, как TCP борется с синдромом глупого окна. Это необходимо для того, чтобы предотвратить объявление маленьких окон или отправку маленьких пакетов. В примерах мы видели, как происходит предотвращение синдрома глупого окна на обоих концах, то есть у отправителя и получателя.

Упражнения

На рисунке 22.3 обратите внимание на моменты времени соответствующие подтверждениям (сегменты 5, 7, 9, 11, 13, 15 и 17): 0,170; 5,170; 10,170; 15,170; 15,370; 20,170 и 25,170. Также обратите внимание на разницу во времени между получением данных и отправкой подтверждений: 164,5; 18,5; 18,7; 18,8; 198,3; 18,5 и 19,1 миллисекунды. Объясните, что бы это могло означать.
На рисунке 22.3 в момент времени 25,174 объявляется окно размером 767, однако в приемном буфере есть место для 768 байт. Чем объясняется разница в 1 байт?

Краткие выводы

Как мы говорили ранее, характеристика "оставайся в живых" довольно спорная. Эксперты, работающие с протоколами, продолжают дебаты по поводу того, принадлежит ли она транспортному уровню или должна должна быть реализована непосредственно в приложении.

Она функционирует посредством отправки пробных пакетов по соединению, после того как соединение не использовалось в течение 2 часов. Могут возникнуть четыре различных сценария: удаленный конец функционирует и откликается, удаленный конец вышел из строя, удаленный конец вышел из строя и перезагрузился и удаленный конец в настоящее время недоступен. В нашем примере мы рассмотрели все эти сценарии и видели различные ошибки, возвращаемые для последних трех условий.

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

Краткие выводы

В этой главе рассмотрено пять новых характеристик TCP: определение транспортного MTU, опция масштабирования окна, опция временной марки, защита от перехода через 0 номера последовательности и улучшенная обработка транзакций с использованием TCP. Мы видели, что три средние опции требуются для оптимальной производительности в каналах с повышенной пропускной способностью - в сетях с большой емкостью.

Определение транспортного MTU позволяет TCP использовать окна больше, чем окно по умолчанию равное 536, для нелокальных соединений, когда транспортный MTU больше. Это может улучшить производительность.

Опция масштабирования окна воспринимает максимальный размер TCP окна от 65535 байт до сверх 1 гигабайта. Опция временной марки позволяет аккуратно засечь время для нескольких сегментов и также позволяет получателю предоставить защиту против перехода номера последовательности через 0 (PAWS). Это очень важно для высокоскоростных соединений. Эти новые опции TCP обсуждаются хостами при установлении соединения и игнорируются более старыми системами, которые не понимают их, позволяя более новым системам нормально функционировать с более старыми системами.

Расширение TCP для транзакций, T/TCP, позволяет ограничить общение клиент-сервер запрос-отклик всего тремя сегментами. Это позволяет избежать трехразового рукопожатия и уменьшить продолжительность состояния TIME_WAIT с помощью кэширования небольшого количества информации для каждого хоста, с которым установлено соединение. При этом флаги SYN и FIN передаются в сегментах данных.

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

Краткие выводы

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

Все переменные идентифицируются идентификаторами объекта, используется иерархическая схема присвоения имен, которая состоит из длинных строк чисел, которые обычно сокращаются в простые имена, для простоты чтения. Конкретные переменные строятся с помощью добавления переменной к идентификатору объекта.

Большинство SNMP переменных содержится в таблицах, с фиксированными номерами колонок, однако с переменными номерами строк. Фундаментальным для SNMP является схема идентификации, используемая для того, чтобы идентифицировать каждую строку в таблице (в том случае, когда мы не знаем, сколько строк содержится в таблице), и лексикографический порядок (порядок колонка-строка). SNMP оператор get-next является основным для любого SNMP менеджера.

Мы описали следующие группы SNMP переменных: система, интерфейс, трансляция адресов, IP, ICMP, TCP и UDP. Затем показали два примера, один из которых позволил определить MTU интерфейса, а другой - просмотреть таблицу маршрутизации маршрутизатора.

Мы завершили главу рассмотрением SNMP ловушек. Это способ, предоставляющий агенту возможность уведомить менеджера о том, что произошло какое-либо событие, которое будет интересно менеджеру. Здесь же кратко описаны ASN.1 и BER. Две последние темы, скорее всего, являются наиболее сложными аспектами SNMP, однако они необходимы только для разработчиков.

Упражнения

Мы сказали, что использование двух различных портов (161 и 162) позволяет системе запускать как менеджера, так и агента. Что произойдет, если будет использоваться один и тот же порт?
Как Вы можете получить полный список таблицы маршрутизации с использованием get-next?

Назад

На главную

Краткие выводы

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

Между этими приложениями существуют отличия. Rlogin подразумевает, что на обоих концах соединения присутствуют Unix хосты, поэтому существует только одна опция. Это простой протокол. Telnet не ограничивает, какая операционная система используется на обоих концах соединения. Telnet разработан для того, чтобы функционировать между различными операционными системами.

Чтобы поддерживать разнородное окружение, Telnet предоставляет обсуждение опций между клиентом и сервером. Это позволяет общаться клиентам и серверам, а также позволяет добавлять новые опции.

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

На рисунке 26.18 сравниваются различные характеристики, предоставляемые Rlogin и Telnet.

Характеристика	Rlogin	Telnet
транспортный протокол	Одно TCP соединение. Используется режим срочности.	Одно TCP соединение. Используется режим срочности.
пакетный режим	Всегда символ за один раз, удаленное эхо.	Общий режим по умолчанию - символ за один раз, удаленное эхо. Поддерживается режим строки за раз с эхом от клиента. Новые опции для реального линейного режима с эхом от клиента. Если приложение на сервере требует режим символ за один раз - он поддерживается всегда.
управление потоком данных	Обычно осуществляется клиентом, однако может быть выключено сервером.	Обычно осуществляется сервером, иногда позволяется делать клиенту.
тип терминала	Присутствует всегда.	Опционально, обычно поддерживается.
скорость терминала	Присутствует всегда.	Опционально.
размер окна	Опционально поддерживается большинством серверов.	Опционально.
переменные окружения	Не поддерживается.	Опционально.
автоматический login	По умолчанию. Может появиться приглашение ввести пароль, который посылается в виде открытого текста. Более новые версии поддерживают Kerberos.	По умолчанию необходимо ввести имя и пароль, который отправляется в виде открытого текста. Более новыми версиями предоставляется опция аутентификации.

Краткие выводы

FTP это стандарт, признанный в Internet, для передачи файлов. В отличие от большинства других TCP приложений, он использует два TCP соединения между клиентом и сервером - управляющее соединение, которое существует в течение всего продолжения сессии клиент-сервер, и соединение данных, которое создается и удаляется по необходимости.

Управление соединением, которое осуществляется FTP, позволило нам увидеть, какие требования выдвигает TCP к управлению соединением. Мы видели состояние ожидания 2MSL на клиенте, который не выдает команды PORT.

FTP использует формат NVT ASCII для всех команд и откликов, которые передаются по управляющему соединению. Режим передачи данных по умолчанию это, как правило, также NVT ASCII. Мы видели, что более новые Unix клиенты автоматически посылают команду, чтобы убедиться в том, что сервер это Unix хост с 8-битными байтами, и если так, используют двоичный режим для передачи всех файлов, которые являются более эффективными.

Также мы показали пример анонимного FTP, популярного способа распространения программного обеспечения по Internet.

Краткие выводы

В работе электронной почты принимают участие пользовательские агенты на обоих концах (отправитель и получатель), а также два или несколько агентов передачи сообщения. Мы можем поделить почтовое сообщение на три части: конверт, заголовки и тело сообщения. Мы видели, как происходит обмен этими частями с использованием SMTP, который является стандартом в Internet. Все три состоят из символов NVT ASCII.

Также мы рассмотрели новые расширения этих трех частей: расширенный SMTP для конверта, не-ASCII заголовки и дополнительная структура для тела сообщения с использованием MIME. Структура и кодирование, используемые MIME, позволяют обмениваться двоичными данными с использованием существующих 7-битных MTA SMTP.

Краткие выводы

RPC это способ построить приложение клиент-сервер таким образом, что клиент просто вызывает процедуры на сервере. Все сетевые детали спрятаны в stubах клиента и сервера, которые генерируются для приложений пакетом RPC и в подпрограммах библиотеки RPC. Мы показали формат RPC сообщений вызова и отклика и упомянули, что XDR используется, чтобы кодировать значения, что позволяет RPC клиентам и серверам работать на машинах с различной архитектурой.

Одно из наиболее широко используемых приложений RPC это Sun NFS, протокол доступа к разнородным файлам, который широко используется на хостах практически всех размеров. Мы рассмотрели NFS и то, как он использует UDP или TCP. В протоколе NFS версии 2 (NFS Version 2) определено 15 процедур.

Доступ клиента к NFS серверу начинается с протокола монтирования, после чего клиенту возвращается описатель файла. Затем клиент может получить доступ к файлам в файловой системе сервера с использованием этого описателя файла. Имена файлов просматриваются на сервере по одному элементу имени за раз, при этом для каждого элемента возвращается новый описатель файла. Конечный результат это описатель того файла, к которому было осуществлено обращение, и который используется при последовательных чтениях и записях.

NFS старается сделать все свои процедуры независимыми от количества исполнений таким образом, чтобы клиент мог просто повторно выдать запрос, если отклик был потерян. Мы видели примеры этого: в случае, когда клиент читал файл, пока сервер вышел из строя и перезагружался.

Краткие выводы

Первые два приложения, которые мы рассмотрели, Finger и Whois, предназначены для получения информации о пользователях. Клиент Finger запрашивает сервер, чаще всего для того, чтобы найти какое-либо имя (например, чтобы отправить пользователю почту) или для того чтобы посмотреть, зашел ли кто-либо в систему терминалом в настоящий момент. Клиент Whois обычно общается с сервером, запущенным от InterNIC, в поисках информации о человеке, организации, домене или номере сети.

Другие сервисы, позволяющие более эффективно работать с ресурсами Internet, это Archie, WAIS, Gopher, Veronica и WWW. Они помогают найти в Internet файлы и документы. В настоящее время разрабатываются и другие средства определения ресурсов.

Эта глава закончена кратким рассмотрением системы X Window System, еще одного очень "серьезного" приложения, работающего с TCP/IP. Мы видели, что X сервер обслуживает несколько окон на дисплее и обеспечивает общение клиента с его окном. С помощью программы Xscope мы видели, как существует возможность поместить еще одну программу между клиентом и сервером, чтобы получить информацию о том, с помощью каких сообщений осуществляется обмен.

Содержание раздела