62879 (695183), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

TCP-модуль сервера использует номер последовательности, принятый от клиен­та, чтобы сконструировать на его основе собственный номер подтверждения. Номер подтверждения всегда указывает на номер сообщения, которое сервер рассчитывает получить следующим. Таким образом, в начальном сообщении-от­вете сервера содержится номер последовательности клиента, увеличенный на единицу.

Предположим, например, что модуль TCP клиента, запрашивающего соедине­ние, шлет номер последовательности, равный 1000. В ответ от сервера он получит начальное сообщение с числом 1001, установленным в поле подтверждения. Для модуля-клиента это выглядит, как будто сервер сказал: «Кстати, следующее сообщение, которое я от тебя ожидаю, должно иметь номер 1001».

Соединение установлено!

До передачи любых данных модуль TCP клиента, запросивший соединение, должен подтвердить начальное сообщение-ответ, пришедшее от модуля TCP сервера. То есть, когда модуль TCP клиента получает начальное сообщение-ответ от сервера, он должен посылать «подтверждение подтверждения». (На самом деле клиент подтверждает запрос сервера на синхронизацию обмена.)

Сообщение, посланное TCP-модулем клиента, тоже будет содержать установ­ленный флаг «подтверждение». В поле «номер подтверждения» TCP-модуль клиента размещает начальный номер последовательности, принятый от сервера, увеличенный на единицу. (Теперь TCP-модуль клиента не устанавливает флаг синхронизации, так как обе стороны соединения уже синхронизировались, то есть договорились о начальных номерах своих последовательностей.) Другими словами, между TCP-модулями происходит обмен данными, состоящий из трех стадий:

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

2. TCP-модуль сервера подтверждает прием запроса на установление соедине­ния и в свою очередь шлет клиенту запрос на синхронизацию с собственным начальным номером последовательности.

3. TCP-модуль клиента подтверждает прием запроса сервера на синхрони­зацию.

Что такое номер последовательности?

Номер последовательности однозначно идентифицирует байт данных в потоке данных TCP. Как следует из названия, номера последовательности последова­тельны, то есть следуют один за другим. Однако номера последовательности разных соединений TCP необязательно начинаются с одного и того же числа. Номер последовательности, устанавливаемый в каждом сегменте TCP, иденти­фицирует первый байт в сообщении. То есть является смещением относительно начала потока данных. Номер последовательности — то же самое, что счетчик переданных байтов. Он как бы говорит: «Первый байт этого пакета — это номер байта (номер последовательности) в потоке данных».

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

1. Модуль TCP клиента передает сегмент TCP, содержащий байты с 1 по 500. Номер последовательности, записанный в поле «номер последовательности» сегмента, равен 1251.

2. Модуль TCP клиента передает сегмент TCP, содержащий байты с 501 по 1000. Номер последовательности равен 1751.

3. Следующий сегмент, посланный модулем TCP клиента, содержит байты с 1001 по 1500 с номером последовательности, равным 2251.

4. Наконец, модуль TCP клиента передает данные с 1501 байта по 2000 и устанавливает номер последовательности равным 2751.

TCP-модуль сервера в нашем примере шлет следующие сообщения:

1. Приняв первый сегмент от клиента, TCP-модуль сервера отвечает пакетом-подтверждением с номером подтверждения 1751. Сервер как бы говорит:

«Эй, я принял твои данные, и следующий сегмент, который я надеюсь получить, должен содержать номер последовательности 1751».

2. Приняв второй сегмент, TCP-модуль сервера шлет номер подтверждения, установленный в 2251.

3. Приняв третий сегмент, TCP-модуль сервера шлет номер подтверждения, равный 2751.

4. Приняв четвертый сегмент, TCP-модуль сервера шлет номер подтверждения, равный 3251. (В данный момент TCP-модуль сервера не знает, что передача данных окончена — TCP-модуль клиента еще не известил об этом.)

Дуплексные сетевые службы

Как уже отмечалось, соединение TCP является дуплексным. Это значит, что данные следуют одновременно в обоих направлениях. Данные, следующие в одном направлении, совершенно не зависят от данных, следующих в противо­положном. Поскольку обмен данными TCP является дуплексным, TCP-модулям необходимо подсчитывать получаемые и передаваемые данные раздельно, и номера последовательности для обоих потоков будут разными.

Если вышесказанное не произвело на вас впечатления, давайте рассмотрим поток данных с точки зрения одной из сторон соединения. Предположим, что мы рассматриваем поток данных со стороны TCP-модуля клиента. С точки зрения TCP-модуля клиента номер последовательности отсчитывает или идентифици­рует данные, посылаемые клиентом в сторону TCP-модуля сервера. Номер подтверждения в сегментах, посланных TCP-модулем клиента, с его точки зрения идентифицирует данные, принятые от TCP-модуля сервера. На рис. 5.7 изображен поток данных и номера последовательности так, как они выглядят со стопоны TCP-модуля клиента.

Рис. .7. Идентификация данных и их поток с точки зрения TCP-модуля клиента 137

Окончание соединения TCP

Соединение TCP заканчивается обменом пакетами, состоящего из двух стадий. Каждая из сторон, как сервер, так и клиент, может предложить другой закончить соединение. Для этого сторона-инициатор обмена высылает пакет с установлен­ным флагом «окончание обмена» (FIN). В силу дуплексной природы протокола TCP оба потока данных независимы, и должны быть завершены по отдельности. Если вам приходилось программировать в UNIX, последнее утверждение преды­дущего абзаца может показаться подозрительным. Когда в UNIX закрывается соединение, дальнейший обмен по нему становится невозможен. Соединение TCP работает по-другому. Даже после закрытия соединения (завершения пере­дачи данных) одной из сторон соединения она в состоянии продолжать прием данных от другой стороны соединения.

Мысль принимать данные после закрытия соединения кажется странной на первый взгляд. На самом деле, установленный в пакете флаг FIN является сигналом, означающим, что одна сторона прекратила передачу данных. Приход сообщения-подтверждения от другой стороны означает, что обе стороны догово­рились прекратить обмен данными в одном направлении. Начиная с этого момента одна из сторон соединения будет молчаливо принимать данные, не делая никаких замечаний по их поводу, а другая молчаливо посылать, не ожидая никаких комментариев. Окончание (закрытие) TCP-соединения — двухступен­чатый процесс. Одна сторона выполняет активное закрытие, а другая — пассивное. Закрытие активно, если вызвано по инициативе данной стороны, и, наоборот, пассивно, если вызвано противоположной стороной соединения. Сто­рона, первой высылающая пакет с установленным флагом «окончание соедине­ния», является активной. Как правило, модуль TCP, принявший пакет с установленным флагом «окончание соединения», инициирует пассивное окон­чание соединения. Это просто значит, что пассивная сторона также посылает сообщение с установленным флагом окончания. Другими словами, сторона, принявшая сообщение об окончании первой, отвечает: «Хорошо, если тебе нечего больше послать, то и мне тоже нечего послать тебе». После того как обе стороны выслали друг другу сообщения об окончании и получили подтверждения о доставке этих сообщений, соединение TCP считается действительно закончен­ным (закрытым).

Что такое закрытие «наполовину»?

Вы уже знаете, что в силу дуплексной природы TCP-соединения, в то время как поток данных в одну из сторон закончен, он может сохраняться в обратном направлении. Такое окончание лишь одного потока называется закрытием «наполовину» (half-close). Лишь очень немногие приложения TCP нуждаются или используют закрытие «наполовину». Однако если в ваши планы входит разработка приложений Интернет, эта возможность может когда-нибудь и пригодиться.

Что такое заголовок TCP?

Из рис. 5.8 видно, что структура TCP-заголовка намного сложнее, нежели у UDP. В следующих абзацах изучается назначение полей, составляющих TCP-заголовок.

Рис. 8. Структура сегмента (сообщения) TCP

Порт источника и порт получателя

16-битные поля источника и получателя однозначно определяют посылающие и Принимающие данные приложения или прикладные протоколы. Номера портов источника и получателя в совокупности с IP-адресами сетевых компьютеров (в IP-заголовке) однозначно идентифицируют любое TCP-соединение. Каждая из сторон TCP-соединения называется сокетом (socket). \

Номер последовательности

32-битное поле номера последовательности обозначает первый байт данных из области данных сегмента TCP. Оно соответствует смещению этого байта отно­сительно начала потока данных. Каждый байт в потоке данных может быть идентифицирован при помощи номера последовательности.

Номер подтверждения

32-битное поле номера подтверждения обозначает байт данных, который прини­мающая сторона рассчитывает получить следующим в потоке данных. Напри­мер, если последний принятый байт имел номер 500, модуль TCP установит номер подтверждения равным 501.

Длина заголовка

Как и в заголовке IP, поле длины заголовка TCP состоит из четырех битов, обозначающих длину заголовка, измеренную в 32-битных словах. Как и заголо­вок IP, заголовок TCP обычно имеет длину в 20 байтов. Область данных начинается сразу после заголовка TCP. Таким образом, модуль TCP определяет место, где начинаются данные и кончается заголовок, просто прибавляя поле «длина заголовка», умноженное на четыре байта (32 бита), к первому байту сегмента данных.

Флаги

Заголовок TCP содержит шесть однобитных полей флагов. С тремя из них мы уже встречались. Это флаги синхронизации (SYN), подтверждения (АСК) и флаг окончания соединения (FIN). Следующие абзацы описывают оставшиеся три.

Флаг URG

Данный флаг сообщает принимающему модулю TCP о том, что. указатель на данные, требующие немедленной обработки, в поле «неотложные данные» установлен, то есть указывает на них. (Модуль TCP должен обработать неот­ложные данные до того, как обрабатывать что-либо еще.)

Флаг АСК

Установленный флаг сообщает принимающему модулю TCP, что поле «номер подтверждения» содержит правильный номер подтверждения. Вы знаете, что данный флаг служит обеспечению надежной передачи данных.

Флаг PSH

Установленный флаг PUSH требует от принимающего модуля TCP вытолкнуть (push), то есть немедленно выслать принятый сегмент данных приложению-по­лучателю. Как правило, модуль TCP буферизует принимаемые данные. То есть он не доставляет каждый сегмент по отдельности, а ждет, пока его буфер наполнится, а затем доставляет все принятые сегменты за один раз. Флаг PSH запрещает размещать сегменты данных в буфере. Telnet, например, устанавли­вает этот флаг. Нажатия на клавиши пользователем незамедлительно попадают на сервер Telnet, с которым он работает. Такое поведение устраняет возможные задержки в выдаче эха от сервера — большинство пользователей Telnet желают сразу видеть на экране то, что они печатают.

Флаг RST

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

Флаг SYN

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

Характеристики

Список файлов реферата