На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Использование дуплексност TCP

Как уже было отмечено раньше, TCP-соединение является дуплексным, данные могут идти в обоих направлениях одновременно. Иначе говоря, дан­ные, идущие в одном направлении, не зависят от данных, идущих в обратном направлении. Из-за дуплексности TCP каждая сторона TCP-соединения должна устанавливать два значения последовательности — по одному для каждого на­правления потока данных.
Если вам непонятно, почему в TCP используется два набора идентификацион­ных чисел (значения последовательности и подтверждения), то представьте себе поток данных от одной из сторон соединения. Предположим, что вы рассматриваете поток данных со стороны клиента. С точки зрения клиента, значение последовательности определяет данные, идущие к стороне-серверу.
Кроме того, с точки зрения клиента значения последовательности, располо­женные в сегментах данных, определяют данные, идущие от стороны-сервера. показаны поток данных и значения последовательности с точки зрения клиента.
ЗАКРЫТИЕ TCP-СОЕДИНЕНИЯ
Программы закрывают TCP-соединение, используя квитирование в два этапа (two-way handshake). Для закрытия соединения одна из сторон посылает сооб­щение с установленным флагом окончания (FIN). Однако из-за дуплексности TCP-соединения (данные движутся в двух направлениях) программы должны закрыть каждое направление движения данных независимо.
Если вы работаете в среде Unix, последнее утверждение предыдущего абзаца может показаться вам подозрительным. В среде Unix если вы закрываете какое-либо соединение, то вы уже не можете посылать сообщения по этому соедине­нию. TCP-соединения работают по-другому. Даже после закрытия одного из направлений движения данных (т. е. одна сторона прекращает посылать дан­ные) другая сторона может продолжать отправлять данные, и они будут двигать­ся в другом направлении.
Если мысль о том, что данные могут передаваться по закрытому каналу связи, кажется вам странной, считайте, что флаг окончания является сигналом, посы­лаемым одной стороной другой стороне, который говорит о том, что эта сторо­на закончила отправлять данные. Подтверждение на это сообщение от другой стороны соединения означает, что обе стороны решили прекратить передачу данных в одном направлении. В этот момент ни одна из сторон не может ничего сказать о данных, передаваемых в обратном направлении.
Закрытие TCP-соединения — это процесс, состоящий из двух этапов. Одна сто­рона осуществляет активное закрытие (active close), а другая — пассивное закры­тие (passive close). Сторона, которая предлагает закрытие и первая отправляет флаг окончания, осуществляет активное закрытие.
Обычно сторона, которая получает флаг окончания, начинает пассивное закры­тие. Это означает, что сторона-получатель просто отправляет сообщение с уста­новленным флагом окончания. Другими словами, сторона, которая получает первое сообщение с установленным флагом окончания, как бы говорит: «По­скольку ты не будешь больше передавать данные, я тоже не буду больше переда­вать данные и закрою соединение».
После того как обе стороны TCP-соединения обменяются сообщениями с уста­новленными флагами окончания и подтверждениями, TCP-соединение считает­ся официально закрытым.
SOURCE PORT и DESTINATION PORT
Оба 16-битны> поля Source Port и Destination Port (Порт источника и порт прием­ника) определяют приложение-отправитель и приложение-получатель (или про­токолы приложений). Числа Source Port и Destination Port плюс IP-адреса источ­ника и приемника (в заголовке IP) образуют уникальную комбинацию для опре­деления каждого TCP-соединения. Программисты называют каждую сторону TCP-соединения сокетом (socket).
SEQUENCE NUMBER
32-битное поле Sequence Number (Значение последовательности) определяет пер­вый байт в области данных TCP-сегмента. Этот байт вычисляется как смещение от начала потока данных. С помощью значения последовательности можно оп­ределить каждый байт потока данных.
ACKNOWLEDGMENT
32-битное поле Acknowledgment (Подтверждение) определяет следующий байт дан­ных, который ожидает получатель. Например, если последний байт данных, принятый получателем, был 500, TCP отправляет значение подтверждения 501.
HEADER LENGTH
Как и заголовок IP, поле Header Length (Длина заголовка) протокола TCP ис­пользует 4 бита для определения длины заголовка (измеряется в 32-битных сло-.вах). Аналогично IP-заголовку, размер заголовка TCP обычно равен 20 байт.
Сразу после заголовка TCP начинается область данных. Имея значение, поме­щенное в поле Header Length, получатель может вычислить, где начинается об­ласть данных. Для этого необходимо умножить это значение на 4 — в результате он получит смещение (в байтах) от начала ТСР-сегмента.
ФЛАГИ
Заголовок TCP включает шесть однобитовых полей флагов. Вы уже узнали о назначении трех полей флагов: флага синхронизации флага подтвержде-
ния (АСК) и флага окончания (FIN).
Флаг_Описание_
URG Этот флаг сообщает TCP-модулю получателя, что поле Urgent
Pointer указывает на срочные данные. (TCP-модуль должен обработать срочные данные раньше всех остальных.)
АСК        Этот флаг сообщает получателю, что поле Acknowledgment
Number содержит правильное значение подтверждения. АСК-флаг помогает TCP обеспечивать надежность передачи данных.
PSH Этот флаг запрашивает толчок (push). Он указывает приемному TCP-модулю, что сегменты данных следует немедленно отправить нужному приложению. Обычно TCP-модуль помещает поступившие данные в буфер. Поэтому TCP. не пересылает сегмент данных тому приложению, которому он предназначается, до тех пор, пока содержимое буфера не достигнет определенного значения. Флаг PSH сообщает, _что данные не надо помещать в буфер. Например, приложение
Флаг Описание
Telnet обычно устанавливает этот флаг. Таким путем Telnet заставляет TCP немедленно передавать нажатия клавиш пользователем серверу Telnet. Это помогает избегать задержек большинство пользователей Telnet хотят видеть, что они печатают, сразу же после ввода символов. RST Этот флаг указывает, что приемный модуль должен переустановить (reset) соединение. TCP посылает сообщения с установленным флагом RST, когда обнаруживаются проблемы в соединении. Большинство приложений просто оканчивают работу, когда получают этот флаг. Однако его можно использовать для сложного алгоритма, который поможет вам защитить программы от аппаратных и программных сбоев.SYN Этот флаг указывает TCP-модулю получателя синхронизировать значения последовательности. Как вы уже знаете, TCP использует этот флаг, для того чтобы сказать получателю, что отправитель собирается послать новый поток данных.
FIN        Этот флаг устанавливают, для того чтобы сообщить приемномуTCP-модулю, что отправитель закончил передачу данных. Как вы уже знаете, этот флаг закрывает только поток данных, идущих в одном направлении. Для того чтобы полностью закрыть соединение, приемный TCP-модуль тоже должен _прислать сообщение с установленным флагом F1N._
Поля флагов TCP (окончание).
WINDOW SIZE
16-битное поле Window Size (Размер окна) сообщает TCP-модулю приемника количество байт, которое хочет принять отправитель. Как уже говорилось, для того чтобы улучшить пропускную способность и оптимизировать ширину полосы пропускания сети, в протоколе TCP используются скользящие окна перемен­ной ширины. Значение, помещенное в это поле, определяет ширину скользя­щего окна. Обычно такое окно имеет ширину в несколько тысяч байт.
TCP CHECKSUM
16-битное поле TCP Checksum (Контрольная сумма TCP) содержит контрольную сумму пакета. TCP требует, чтобы отправитель вычислял контрольную сумму и помещал ее значение в это поле. Приемный TCP-модуль должен проверять кон­трольную сумму присланных данных.
Примечание. Сетевое программное обеспечение вычисляет контрольную сумму TCP способом, похожим на тот, который будет описан в разделе этой главы «Конт­роль ошибок и контрольные суммы». Контрольная сумма должна быть обязательно
включена в состав каждого сегмента данных, передаваемого отправителем.
URGENT POINTER
16-битное поле Urgent Pointer (Указатель на срочные данные) определяет распо­ложение определенного байта в области данных TCP. Цель флага URG и срочно­го указателя — сообщить приемному TCP-модулю, что некоторые из переданных данных являются срочными, а также указать, где они находятся. К сожалению, никто не определил точно термин срочные данные. Более того, не существует и определения ответственности приемного TCP-модуля за управление срочными данными. Правильнее будет сказать, что оба этих вопроса находятся в стадии разработки.
Дуглас И. Комер во втором издании своей классической книги Internetworking with TCP/IP - Volume 1, Prientice Hall, 1991, рассказывает о поле Urgent Pointer в разделе 12.12 (Out of Band Data). Однако В. Ричард Стивене в разделе 20.8 книги TCP/IP Illustrated - Volume I, Prientice Hall, 1994, пишет, что «многие приложения ошибочно называют срочный (urgent) режим протокола TCP данными вне диапазона (out-of-band data)».
Стивене считает, что многие приложения ошибочно ассоциируют срочный ре­жим и данные вне диапазона. Он пытается объяснить причины, по которым, как ему кажется, это происходит:
«Путаница в терминах срочный режим и данные вне диапазона происходит из-за того, что преобладающее количество программных интерфейсов, соке-тов API, устанавливают соответствие между срочным режимом и тем,
что в сокетах называют данными вне диапазона».
Относительно точного расположения срочных данных Стивене дает следующие комментарии:
«Споры по поводу того, определяет ли указатель срочности последний байт срочных данных, или байт, следующий за последним, продолжаются. Перво­начальная спецификация TCP позволяет использовать обе интерпретации, но в документе Host Requirements RFC даны четкие указания по этому поводу:
указатель определяет последний байт срочных данных».
«Проблема состоит в том, что большинство приложений продолжают использовать неверную интерпретацию. Приложения, которые используют
спецификацию RFC, могли бы работать верно, но при этом они не взаимо­действуют правильно с остальными».
Стивене и Комер сошлись во мнении, что указатель срочности определяет после­дний байт срочных данных. Стивене утверждает, невозможно определить начало срочных данных. С другой стороны, Смут Карл-Митчелл и Джон С. Кватермен в разделе 4.2 своей книги Practical Internetworking with TCP/IP and Unix, Addison-Wesley, 1993, подливают масла в огонь. Они утверждают, что указатель срочности определяет первый байт срочных данных, и тем самым порождают новую путаницу в определении термина.
Можно поинтересоваться, где же используются срочные данные. Традицион­но, когда приводится пример приложения, использующего срочные данные TCP, вспоминают Telnet. Приложение Telnet могло бы использовать срочные данные для обработки escape- и interrupt-гюследовательностей Скорее всего, вам следует ограничиться в использовании срочного режима TCP. Поскольку вы не сможете точно контролировать структуру всех программ, которые будут использовать ваше приложение, некоторые из них могут неправильно интерпретировать данные срочного режима.
OPTIONS
Как и заголовок заголовок TCP включает в себя поле Options (Дополнитель­ные данные). Во время процесса согласования между двумя сторонами TCP-соединения TCP-модули обычно помещают в поле Options параметр Maximum Segment Size (максимальный размер сегмента). Максимальный размер сегмента TCP напоминает максимальный передаваемый блок данных (MTU — maximum transfer unit) физического уровня — он определяет наибольшее сообщение, ко­торое может принять TCP-модуль.
Как вы уже знаете, TCP оптимизирует ширину полосы пропускания сети увели­чением пропускной способности. Параметр Maximum Segment Size позволяет
TCP-модулям объявить максимальный размер сегмента или сообщения, кото­рый они могут принять. TCP-модули могут использовать этот параметр только вместе с установленным флагом SYN. Однако этот параметр не требует согласо­вания. Одна сторона TCP-соединения просто сообщает другой стороне, что ожидаемый ею максимальный размер сегмента имеет определенное значение. Если TCP-модуль не может передать максимальный размер сегмента, TCP уста­навливает его по умолчанию равным 536 байтам.
ОТ КОНЦЕПЦИИ К РАЗРАБОТКЕ

Вы уже знаете, как работает набор протоколов TCP/IP, на чем основана модель ISO/OSI и какая адресация используется компьютерами для сообщения друг с другом.  Короче говоря, вы узнали основы работы сетей с точки зрения программного обеспечения. Однако одного программного обеспечения недостаточно для создания сети. Сеть должна иметь в своей основе аппаратное обеспечение. Сетевое программное обеспечение работает благодаря наличию ап­паратного соединения. Теперь вы узнаете о том, как должны быть соединены компьютеры. Такое соединение называется сетью. Существуют различные виды соединений, называемые топологиями сети (network topology).
ТОПОЛОГИИ СЕТИ
Топология сети — это форма и конфигурация сети. Другими словами, это гео­метрическое расположение соединенных компьютеров. Проектировщики сетей наиболее часто используют следующие виды топологий: «звезда» (star), «кольцо» (ring) и «шина» (bus).
ТОПОЛОГИЯ «ЗВЕЗДА»
Как следует из названия, компьютеры в подобной сети соединены в виде звез­ды. Один сетевой центральный компьютер, называемый концентратором (hub) является сердцем сети, а все остальные компьютеры, которые часто называют клиентами (client) или узлами (node) связаны с концентратором (или серве­ром). Узлы не имеют непосредственной связи друг с другом. Все движение данных по сети происходит через центральный компьютер. по­казано, как соединяются компьютеры в топологии «звезда».
узел 1
узел 4 узел
При использовании топологии «звезда» все компьютеры соединены с центральным компьютером.
Основным преимуществом этой топологии является то, что сеть продолжает функционировать даже в том случае, если один или даже несколько узлов пере­стают действовать. Поскольку все узлы связаны только с концентратором, он продолжает обеспечивать движение данных между узлами, продолжающими фун­кционировать. Главным недостатком соединения в виде звезды является то, что вместе с концентратором перестает работать и вся сеть. Поскольку все обслужи­вание сети производится центральным компьютером, его неисправная работа стопорит все функционирование сети. Так как движение данных в сети происхо­дит через концентратор, обеспечение его безопасности является очень важной задачей при использовании этой топологии.
ТОПОЛОГИЯ «КОЛЬЦО»
Как видно из названия, «кольцо» — это соединение компьютеров, в котором нет центра. При применении этой топологии один узел соединяется со следую­щим, затем со следующим и т.д., пока, наконец, цепь компьютеров не замк­нется на первом узле, образуя кольцо. Как показано 15 и как сле­дует из самой топологии, данные движутся только в одном направлении.
Основным недостатком этой топологии является то, что если произойдет разрыв в каком-либо соединении между соседними компьютерами или аппаратное обес­печение одного из них выйдет из строя, то это остановит работу всей сети. Если даже один узел прекратит функционировать, вся сеть не будет работать, несмот­ря на то что остальные компьютеры будут функционировать по отдельности. Важно заметить, что сеть «кольцо» передает данные через каждый компьютер сети, находящийся между компьютером-отправителем и компьютером-получа­телем. Поскольку каждое сообщение проходит через множество компьютеров, вопросы безопасности играют большую роль в этой сетевой топологии.
сервер
При соединении «кольцо» компьютеры передают данные в одном направлении.
ТОПОЛОГИЯ «ШИНА»
В топологии «шина» используется одна передающая среда — обычно коаксиаль­ный кабель, — называемая шиной. Все компьютеры в такой сети подключены непосредственно к шине.
Я:
Сеть, использующая соединение «шина».
В сети, использующей соединение «шина», данные движутся в обоих направле­ниях по сети (другими словами, по шине). Как и при использовании топологии «кольцо», физическое повреждение шины вызывает общий сбой работы в сети. Однако, в отличие от «кольца», «шина» требует специальных концевых элемен­тов (терминаторов), которые проектировщики сети должны размещать на обоих концах шины. Как и в топологии «кольцо», при движении по сети данные про­ходят через каждый компьютер сети. Поэтому при использовании топологии «шина» риск нарушения безопасности значительно увеличивается.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика