Настройка сетей Microsoft дома и в офисе. Учебный курс

Ранее уже упоминалось, что проблема выбора оптимального размера сегмента данных TCP достаточно сложна, поскольку пропускная способность сети падает при передаче как очень больших, так и слишком малых сегментов. При небольшом размере сегмента эффективность сети будет невысокой. Следует помнить, что сегменты данных TCP в процессе передачи встраиваются в 1Р-дейтаграммы, а они, в свою очередь инкапсулируются во фреймы данных, передаваемые в сети. Поэтому, помимо раздела данных, каждый сегмент содержит, как минимум еще 40 байтов для заголовков TCP-сегмента и IP-дейтаграммы. Из-за этого при передаче дейтаграммы, содержащей только один байт данных, передача пользовательских данных занимает незначительную часть выделенной полосы пропускания сети. А если учесть минимальный межпакетный промежуток и биты синхронизации фреймов, автоматически добавляемые сетевым оборудованием, то это соотношение будет еще меньше.

Чересчур большие сегменты данных тоже вредны, поскольку их использование приводит к падению пропускной способности сети. Это связано с тем, что большие сегменты данных приводят к формированию громоздких 1Р-дейтаграмм. В процессе передачи подобной дейтаграммы в сети с малым значением коэффициента MTU происходит ее фрагментация при помощи протокола IP. В отличие от TCP-сегментов, подтверждение получения каждого фрагмента на уровне протокола не выполняется, а отдельные фрагменты дейтаграммы при необходимости не могут быть повторно переданы независимо от всей дейтаграммы. Таким образом, в случае утери или повреждения одного из фрагментов данных повторно должна быть передана вся дейтаграмма. Поскольку отдельные фрагменты время от времени теряются, увеличение размеров сегмента больше порога фрагментации уменьшает вероятность успешного приема дейтаграммы и, следовательно, ведет к уменьшению пропускной способности сети.

Теоретически оптимальный размер сегмента определяется максимально возможным размером формируемых IP-дейтаграмм, которые на протяжении маршрута от компьютера-отправителя до конечного получателя не фрагментируются. На практике определение этого значения затруднено в силу нескольких причин. Во-первых, в большинстве реализаций протокола TCP не используется механизм определения оптимального размера сегмента. Во-вторых, поскольку маршрутизаторы могут динамически изменять маршруты дейтаграмм, возможно изменение пути их следования между двумя взаимодействующими компьютерами. Следовательно, величина MTU в любой момент может измениться, после чего неминуемо последует фрагментация дейтаграммы. В-третьих, оптимальный размер сегмента зависит от длины заголовков протоколов более низкого уровня. Кроме того, при использовании параметров протокола IP размер сегмента должен быть еще меньше. Поэтому проблема определения оптимального размера сегментов протокола TCP до сих пор не разрешена.

ПРИМЕЧАНИЕ

Подробное рассмотрение принципов функционирования маршрутизаторов производится в следующей главе.

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

Перед вычислением контрольной суммы к началу сегмента добавляется псевдозаголовок, а конец сегмента дополняется требуемым количеством нулевых битов. После выполнения описанных подготовительных действий вычисляется значение 16-разрядной контрольной суммы. Длина псевдозаголовка и битов, добавленных в процессе заполнения, не учитывается в общей длине TCP-сегмента, поскольку они не передаются получателю. Кроме того, при вычислении само значение поля контрольной суммы TCP-заголовка полагается равным нулю.

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

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

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

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

Принятую в протоколе TCP систему подтверждения приема называют накопительной, поскольку она отражает количество байтов потока данных, накопленных получателем. Следует отметить, что накопительная система подтверждения приема имеет как преимущества, так и недостатки. Одно из преимуществ заключается в том, что сигналы подтверждения приема легко генерируются и являются однозначными. Их просто невозможно истолковать неправильно. Еще одно преимущество заключается в том, что в случае утери сигналов подтверждения приема не требуется повторно передавать ни сами сигналы, ни соответствующие им сегменты данных. Недостатком накопительного метода является то, что отправитель не обладает сведениями о том, что передача данных завершилась успешно. Ему только известно, какая часть потока данных была успешно доставлена получателю.

Описанную технологию может иллюстрировать простой пример. Предположим, имеется окно, расположенное в потоке данных начиная с позиции 201 и включающее 3000 байтов. Предположим также, что отправитель передал все находящиеся в окне данные в виде трех сегментов. Что произойдет в том случае, когда первый сегмент в процессе передачи данных был утерян, а остальные успешно достигли места назначения? Во время получения сегментов, получатель будет отсылать сигналы подтверждения. В каждом из них будет указан порядковый номер байта (201), то есть номер следующего по порядку старшего байта, относящегося к непрерывному потоку данных, который ожидает получить принимающая сторона. При этом получатель лишен возможности сообщить отправителю, что большая часть данных, принадлежащих текущему окну, уже получена.

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