Окно, посылаемое в каждом сегменте, указывает диапазон номеров последовательности, которые готов принять в данный момент отправитель окна (получатель данных). Существует допущение, что это связано с доступным в этот момент пространством буфера данных для соединения.
Указание большого окна ускоряет передачу. Если поступает больше данных, чем может быть принято, они будут отбрасываться. Это приведет к излишним повторным передачам, создающим дополнительную нагрузку на сеть и TCP. Указание маленького окна может ограничить передачу данных до появления задержки прохода туда и обратно перед передачей каждого нового сегмента.
Предоставленные механизмы позволяют TCP объявлять большое окно, а потом сообщать, что оно значительно меньше, не принимая слишком много данных. Это так называемое "сжатие окна", очень обескураживает. Принцип надежности диктует, что TCP не будет сжимать окно самостоятельно, но будет готов к такому поведение со стороны другого TCP.
Посылающий TCP должен быть готов принять от пользователя и послать по крайней мере один октет новых данных, даже если окно отправки равно нулю. Посылающий TCP должен регулярно повторно посылать кадры получающему TCP, даже когда окно равно нулю. Для интервала повторной передачи рекомендуется использовать две минуты, когда размер окна равен нулю. Эта повторная передача является существенной для гарантии, что в том случае, когда оба TCP имеют нулевое окно, повторное открытие окна будет обязательно сообщено другому.
Если сегмент прибывает, когда получающий TCP имеет нулевое окно, он все равно должен послать подтверждение, показывающее его следующий ожидаемый номер последовательности и текущее окно (ноль). Посылающий TCP упаковывает данные для передачи в сегменты, которые соответствуют текущему окну, и может перепаковывать сегменты в очереди повторной передачи. Такая перепаковка не обязательна, но может оказаться полезной.
При соединении с однонаправленным потоком данных информация об окне будет переноситься в сегментах подтверждения, которые все имеют одинаковый номер, поэтому не существует способа переупорядочить их, если они приходят в беспорядке. Это не является серьезной, но позволит информации окна при случае временно основываться на старых отчетах получателя данных. Избежать этой проблемы можно, действуя на основе информации окна из сегментов, которые несут самые большие номера подтверждения (т.е. сегменты с номером подтверждения, равным или большим, чем самый большой из полученных ранее).
Процедура управления окном имеет существенное влияние на производительность коммуникации. Следующие комментарии являются предложениями для реализации.
Предложения по управлению окном Выделение очень маленького окна приводит к тому, что данные будут передаваться во множестве мелких сегментов, в то время как лучшая производительность достигается с помощью меньшего числа больших сегментов.
Одним из предложений по избавлению от маленьких окон для получателя является задержка обновления окна, пока дополнительное выделение не составит по крайней мере X процентов максимально возможного выделения для соединения (где X может быть от 20 до 40).
Другое предложение для отправителя с целью избежать отправки маленьких сегментов состоит в ожидании, пока окно не станет достаточно большим, прежде чем посылать данные. Если пользователь дает сигнал функции push, то данные должны быть отправлены, даже если это маленький сегмент.
Отметим, что подтверждения не должны задерживаться, так как это может привести к ненужным повторным передачам. Одной из стратегий является отправка подтверждения, когда прибывает маленький сегмент (не обновляя информацию об окне), и затем отправка другого подтверждения с новой информацией об окне, когда окно станет больше. Сегмент, посылаемый для проверки нулевого окна, может также начать разбиение передаваемых данных в сегменты все меньшего размера. Если сегмент, содержащий единственный октет данных, посланный для проверки нулевого окна, принимается, он поглощает один октет доступного в данный момент окна.
Если посылающий TCP просто посылает столько, сколько может, когда окно ненулевое, то передаваемые данные будут разбиты на чередующиеся большие и маленькие сегменты. Со временем случайные паузы у получателя, делающие доступным распределение окна, приведут к разбиению больших сегментов на более мелкие. Через какое-то время передача данных будет осуществляться в основном маленькими сегментами.
Суть вышеизложенного в том, что реализации TCP активно пытаются комбинировать выделение маленьких окон с большими окнами, так как механизмы управления окном ведут к появлению множества маленьких окон в простейших реализациях.
Интерфейс пользователь/ТСР
Следующее ниже функциональное описание команд TCP является в ка-кой-го степени общим, однако весь TCP должен предоставить некоторый минимальный набор служб для гарантии, что все реализации TCP могут поддерживать одну и ту же иерархию протоколов. Этот раздел определяет функциональные интерфейсы, встречающиеся во всех реализациях TCP.
Модель TCP/интерфейс пользователя является моделью, где команды пользователя получают немедленный ответ и, возможно, ответ с задержкой с помощью события или псевдопрерывания. В следующих описаниях термин "сигнал" означает "причина задержанного ответа". Ответы об ошибках предоставляются как строки символов. Например, пользовательские команды, обращающиеся к соединениям, которые не существуют, получают в ответ сообщение "Ошибка: соединение не открыто" ("error: connection not open").
Отметим, что в последующем все арифметические операции с номерами последовательности, номерами подтверждений, окнами и т.д. выполняются по модулю 2 ', так как это размер пространства номеров последовательности. Отметим также, что "=<" означает "меньше или равно (по модулю 232)". Обработка входящих сегментов состоит в том, что они сначала проверяются на правильный номер последовательности (т.е. содержатся в диапазоне ожидаемого "окна получения" в пространстве номеров последовательности), а затем обычно выстраиваются в очередь и обрабатываются в порядке номеров последовательности. Когда сегмент перекрывает другие уже полученные сегменты, он реконструируется, чтобы содержать только новые данные, и соответствующим образом изменяются поля заголовка. Обратите внимание, что если не упомянуто никакое изменение, TCP остается в том же состоянии (т.е. ТСВ не существует). Создайте новый блок управления передачей (ТСВ) для хранения информации о состоянии соединения. Запишите информацию об идентификаторе локального сокета, внешнем сокете, приоритете, безопасности/ячейке и времени ожидания пользователя. Некоторые части внешнего сокета могут быть не определены при пассивном OPEN и должны заполняться параметрами входящего сегмента SYN. Проверьте, что апрошенные безопасность и приоритет допустимы для этого пользователя; если нет, верните "ошибка: приоритет недопустим" или "ошибка: защита/ячейка недопустимы". Если соединение активно, введите состояние LISTEN и вернитесь. Если в активном состоянии и определен внешний сокет, пошлите сегмент SYN. Выбирается начальный номер посылаемой последовательности (ISS). Сегмент SYN посылается в форме <SEQ=ISS><CTL=SYN>. Задайте SND.UNA как ISS, SND.NXT как ISS+1, введите состояние SYN-SENT и вернитесь. Если вызывающая сторона не имеет доступа к указанному локальному сокету, возвращается "ошибка: соединение недопустимо для этого процесса". Если нет места для создания нового соединения, возвращается "ошибка: недостаточно ресурсов".
Состояние прослушивания
Если текущее состояние соединения ACTTV и определен внешний сокет, то измените состояние на активное и выберите ISS. Пошлите сегмент SYN, задайте SND.UNA как ISS, SND.NXT как ISS+1.Введите состояние SYN-SENT. Данные, связанные с SEND, могут быть посланы с сегментом SYN или выстроены в очередь для передачи после ввода состояния ESTABLISHED. Бит срочности (если запрошен в команде) должен посылаться с сегментами данных, посланными в результате этой команды. Если для занесения запроса в очередь нет места, возвращается сообщение "ошибка: недостаточно ресурсов". Если внешний сокет не определен, возвращается сообщение "ошибка: внешний сокет не определен".
Модель работы при передаче дейтаграмм из одной прикладной программы в другую иллюстрирует следующий сценарий. Предположим, что эта передача будет включать один промежуточный шлюз. Передающая прикладная программа готовит свои данные, вызывает свой локальный модуль IР для отправки этих данных в виде дейтаграммы и передает адрес места назначения и другие параметры в качестве аргументов вызова. Модуль IР готовит заголовок дейтаграммы и присоединяет к нему данные. Модуль определяет адрес локальной сети для этого адреса IР; в данном случае это адрес шлюза. Он посылает эту дейтаграмму и адрес локальной сети в локальный сетевой интерфейс. Локальный сетевой интерфейс создает локальный сетевой заголовок и присоединяет к нему дейтаграмму, а затем посылает результат через локальную сеть. Дейтаграмма прибывает на хост шлюза в оболочке заголовка локальной сети, интерфейс локальной сети удаляет этот заголовок и передает дейтаграмму модулю IР. Модуль определяет из адреса IР, что дейтаграмма должна быть передана на другой хост во второй сети. Модуль определяет адрес локальной сети для хоста назначения. Он обращается к интерфейсу локальной сети, чтобы послать ей дейтаграмму. Интерфейс локальной сети создает заголовок локальной сети и присоединяет дейтаграмму, посылая результат хосту назначения. На хосте назначения дейтаграмма освобождается от заголовка локальной сети интерфейсом локальной сети и передается модулю IР.
Модуль IР определяет, что дейтаграмма предназначена для прикладной программы на этом хосте. Он передает данные прикладной программе в ответ на системный вызов, передавая адрес источника и другие параметры, как результат вызова.
Функция или назначение протокола IР состоит в переносе дейтаграмм в пределах объединенной сети, или сетевого комплекса. Это реализуется путем передачи дейтаграмм из одного модуля IР в другой, пока не будет достигнуто место назначения. Модули IР располагаются на хостах и шлюзах в системе Интернет. Дейтаграммы маршрутизируются из одного модуля IР в другой через отдельные сети на основе интерпретации адреса IР. Таким образом, одним из важных механизмов протокола IР является IР-адрес.
При маршрутизации сообщений из одного модуля IР в другой дейтаграммам может понадобиться пересекать сеть, максимальный размер пакета в которой меньше размера дейтаграммы. Чтобы преодолеть эту трудность, в протоколе IР предоставлен механизм фрагментации.
Существует различие между именами, адресами и маршрутами. Имя указывает, что мы ищем. Адрес указывает, где это находится. Маршрут указывает, как туда попасть. Протокол IР имеет дело прежде всего с адресами. Задача протоколов высокого уровня (т.е. протокола хост-хост или приложения) — выполнить отображение из имен в адреса. Модуль IР отображает IР-адреса в адреса локальной сети. Задача низкоуровневых процедур (т.е. локальной сети или шлюзов) — выполнить отображение из адресов локальной сети или маршрутов.
Адреса имеют фиксированную длину из четырех октетов (32 бита). Адрес начинается с номера сети, за которым следует локальный адрес (называемый "собственным" полем). Есть три формата классов адресов IР: в классе (а) старший бит равен нулю, следующие семь битов определяют сеть, а последние 24 бита являются локальным адресом; в классе (Ь) старшими двумя битами будут один-ноль, следующие 14 битов определяют сеть, а последние 16 битов являются локальным адресом; в классе (с) старшими тремя битами будут один-один-ноль, следующие 21 бита определяют сеть, а последние восемь битов являются локальным адресом.
При отображении адресов IР в адреса локальной сети должна быть проявлена осторожность; в ряде случаев единственный физический хост должен действовать как несколько различных хостов за счет использования нескольких различных адресов IР. Некоторые хосты будут также иметь несколько физических интерфейсов (мультихост). Должно быть предусмотрено существование хоста с несколькими физическими сетевыми интерфейсами, каждый из которых может иметь несколько логических адресов IР.
Трансляционный перенос (translational bridging) используется для соединения сетей со смешанной средой передачи, таких как сеть Token Ring и Ethernet. При этом может возникнуть проблема, связанная с тем, что MTU двух сетей существенно различаются. В сегменте Token Ring допустимо MTU от 4464 до 17914, в то время как в сегменте Ethernet MTU ограничено 1500. Если два сегмента соединены мостом, то может возникнуть ситуация, когда пакеты отбрасываются, потому что мост не может фрагментировать данные, как это делает маршрутизатор. Одно из решений — задать MTU на серверах NT, соединенных с сетью Token Ring, равным 1500, для гарантии, что пакеты не будут отброшены в связи с чрезмерным размером. Конечно, прежде чем это сделать, необходимо выполнить мониторинг сети, чтобы увидеть, были ли отброшены пакеты. Если это так, то может помочь следующая запись в реестре.
Поле времени жизни (TTL — time-to-live) имеет восемь битов в длину и следует за полем сдвига фрагмента. Это поле указывает максимальное время, в течение которого дейтаграмма может оставаться в Интернете. Если это поле содержит значение ноль, то дейтаграмма должна быть разрушена. Это поле изменяется при обработке заголовка IР. Время измеряется в единицах секунд, но так как каждый модуль, обрабатывающий дейтаграмму, должен уменьшить ТТL по крайней мере на единицу, даже если он занят этим менее секунды, TTL должно рассматриваться только как верхняя граница времени, в течение которого сможет существовать дейтаграмма. Цель состоит в том, чтобы отбрасывать дейтаграммы, которые невозможно доставить, связав это с максимальным временем жизни дейтаграммы. По умолчанию TTL в Windows NT версии 3.5Х равно 32 секундам; в Windows NT 4.0 оно было поднято до 128 секунд. Это значение по сути является пределом того, сколько маршрутизаторов может пройти дейтаграмма IP, прежде чем будет отброшена. Это значение можно изменить в реестре, как показано дальше:
Далее следует поле протокола, указывающее на протокол следующего уровня, используемый данными дейтаграммы IP. Для переноса этой информации используется восемь битов. Значения для различных протоколов определены в "Assigned Numbers" (Присвоенных номерах).
Потом идет поле контрольной суммы заголовка с 16 битами, выделенными для контрольной суммы только заголовка. Так как некоторые поля заголовка изменяются (например, время жизни), то она вычисляется повторно и проверяется в каждой точке, в которой обрабатывается заголовок IP. Для вычисления контрольной суммы суммируются дополнения до единиц всех 16-битных слов в заголовке, и к полученной сумме применяется операция 16-битного дополнения до единиц. Значение поля контрольной суммы задается равным нулю.
Следующие два поля являются адресом IP источника и адресом IP места назначения. Каждое из них имеет четыре октета. Именно здесь адреса IP включаются в обмен данными. Хотя это и важное поле, мы не собираемся тратить на него много времени, так как это может легко привести к обсуждению маршрутизации, широковещания и т.п. Эти вопросы будут рассмотрены позже, при обсуждении сетевого трафика.
Затем следует поле параметров, которое может появиться или не появиться в дейтаграммах. Они должны быть реализованы всеми модулями IP (хостом и шлюзами). Необязательным моментом является их передача в каждой конкретной дейтаграмме, а не их реализация. В некоторых средах параметр безопасности может потребоваться во всех дейтаграммах. Поле параметров имеет переменную длину. Параметры IP будут иметь размер от одного до 40 октетов. Это будет давать максимальный размер заголовка IP в 60 байтов. Может быть ноль или большее количество параметров. Каждый параметр начинается с кода типа параметра. Этот код делится на три поля, первое из которых является полем копирования. Если это поле задано как 1, то параметр должен быть скопирован во все фрагменты. Если оно задано как 0, то он используется только в первом фрагменте. Следующие два бита в октете кода параметра используются для указания класса используемого параметра. Если он задан как 0, то это управление дейтаграммой или сетью, если как 2, то он используется для отладки или измерения. Другие являются зарезервированными. Следующие пять битов используются для указания номера параметра в классе параметров.
Второй октет является длиной параметра, которая включает код типа параметра и октет длины, октет указателя и длину трех байтов данных о маршруте. Третий октет является указателем на данные о маршруте, указывающим октет, где начинается адрес следующего источника, который будет обрабатываться. Указатель связан с этим параметром, наименьшее законное значение для него равно 4. Некоторые из этих параметров перечислены в таблице 2.2.
Тип потока данных (DataStream) сообщает, какой тип данных переносится внутри пакета. Он может быть задан как специальное число, определенное приложением через Winsock. Самой важной функцией этого поля является обеспечение аккуратного разъединения сеанса. По умолчанию это будет одно из двух следующих сообщений:
• Конец соединения (End-of-Connection). Если тип потока данных задан как OxFE, то партнер по сеансу хочет прекратить сеанс.
• Конец соединения (End-of-Connection). Если тип потока данных задан как OxFF, то пакет передается, так как был получен запрос конца соединения.
Некоторые из других записей, встречающиеся в этом поле, включают числа, перечисленные в таблице
Идентификатор соединения источника и места назначения Это третье и четвертое поля из семи полей заголовка SPX. Поля идентификаторов сое динения источника и места назначения занимают два байта и используются для демультиплексирования сеансов SPX через единственный сокет на уровне IPX. Если идентификатор соединения места назначения задан как 0XFFFF, значит, это пакет начального соединения.
Порядковый номер Пятое поле в заголовке SPX является полем порядкового номера. Это двухбайтовое поле, содержащее счетчик переданных пакетов данных. Это число будет увеличиваться после получения подтверждения о передаче пакета данных.
Номер подтверждения Шестое поле является полем номера подтверждения, сообщающим номер последовательности следующего пакета SPX, который ожидается от партнера SPX.
Номер размещения Последнее поле заголовка SPX является полем номера размещения. Это поле сообщает номер буфера получения, который доступен на рабочей станции. Этот номер почти всегда больше, чем номер подтверждения. Доступность свободных буферов вычисляется, как размер окна, который равен номеру размещения минус номер подтверждения плюс один. Это поле используется как механизм управления потоком. Он работает следующим образом. Когда получающая сторона посылает номер размещения меньше номера подтверждения, отправитель не будет больше посылать данные, пока получающая сторона не пошлет пакет с номером размещения больше номера подтверждения.
Пример создания соединения Трассировка сетевого монитора, приведенная ниже, показывает последовательность успешной инициализации сеанса. Отметим, что идентификатор соединения места назначения задан как OxFFFF, а номер размещения как OxFFFF. Эта последовательность пакетов называется квитированием SPX.
