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

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

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

Флаг FIN

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

Размер окна

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

Контрольная сумма TCP

Как и в случае UDP, 16-битное поле контрольной суммы TCP содержит сумму, вычисленную по области данных. Протокол требует от передатчика, чтобы он включил вычисленную контрольную сумму в поле, а от приемника — чтобы он вычислил ее повторно и сравнил результаты.

Примечание: Контрольные суммы UDP и TCP вычисляются похожим образом. Одна­ко в случае UDP включать контрольную сумму в датаграмму не обяза­тельно. Напротив, протокол TCP обязывает вставлять контрольную сумму в каждый переданный сегмент данных.

Указатель неотложных данных

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

Дуглас Камер во втором издании классического труда «Межсетевое взаимодей­ствие сетей на базе TCP/IP* (Internetworking with TCP/IP, Volume 1, Prentice Hall, 1991) обсуждает поле «неотложные данные» в разделе 12.12, < Данные вне основной полосы пропусканиям (Out of Band Data). С другой стороны, Ричард Стивене в разделе 20.8 своей замечательной книги ^TCP/IP в иллюстрациях^ (TCP/IP Illustrated, Volume 1, Prentice Hall, 1994) пишет следующее:

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

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

^Путаница в связи с неотложными данными TCP и данными вне основной полосы пропускания возникает из-за того, что предпочита­емый большинством интерфейс прикладного программирования (API) сам по себе относит данные ^для неотложной обработким к категории данных <вне основного диапазонам,

Относительно точного местоположения данных для неотложной обработки Стивене делает следующий комментарий:

<Идет продолжительный спор о том, должен ли указатель неотлож­ных данных указывать на последний байт этих данных или на байт, следующий за последним. Первоначальный стандарт TCP позволял толковать это двояким образом, однако RFC, посвященный обяза­тельным рекомендациям для сетевых компьютеров, вносит ясность в это дело, утверждая, что указатель все-таки указывает на последний байт данных для немедленной обработки.

Проблема, однако, в том, что большинство реализации сетевых операционных систем (т. н. производные операционной системы Бер­кли) продолжают использовать неверное представление. Получает­ся, что вполне лояльное по отношению к стандарту TCP сетевое приложение не сможет работать с большинством остальных сете­вых компьютеров^.

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

Так же как и у IP, заголовок TCP содержит необязательное поле «опции» (options). В ходе установления соединения модули TCP договариваются о максимальной длине сегмента (MSS) и устанавливают соответствующую опцию. Смысл максимальной длины сегмента тот же, что и у максимальной длины передаваемого блока (MTU) физического уровня сети. Максимальная длина сегмента определяет максимальный размер сегмента, который может быть передан по соединению TCP. TCP оптимизирует пропускную способность сети, увеличивая ее производительность. Опция максимальной длины сегмента поз­воляет воспользоваться самым большим размером блока данных, который еще можно передать. Опция MSS устанавливается только в тех сообщениях, в которых уже установлен флаг SYN. Однако опция MSS не является предметом обсуждения между обоими модулями. Каждый из модулей TCP просто сообщает другому тот MSS, который он в состоянии принять. Если модуль TCP по каким-либо причинам не передает MSS, его партнер считает, что нужно пользо­ваться MSS, равным по умолчанию 536 байтам.

Что такое инкапсуляция?

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

Эта и две предыдущие главы познакомили вас с различными уровнями сети на базе TCP/IP. В этих главах также описываются интерфейсы между сетевыми уровнями и протоколами TCP/IP. Процесс перемещения данных сквозь стек протоколов на самом деле представляет собой их инкапсуляцию. Инкапсуляция данных — это их форматирование таким образом, чтобы они удовлетворяли тому или иному протоколу. По мере прохождения сквозь стек протоколов данные инкапсулируются в тот формат, с которым умеет работать очередной сетевой уровень. На рис. 5.9 процесс прохождения данных сквозь стек прото­колов изображен целиком.

Разработка структуры и функций приложения Интернет практически не отли­чается от разработки любого другого приложения. Решив передать информацию по Интернет, вы сначала решаете, каким протоколом удобнее воспользоваться. Данные будут инкапсулированы в выбранный протокол, отвечающий вашим требованиям. Для правильного выбора протокола необходимо знать, какие из них есть в вашем распоряжении и какими особенностями они обладают. Чтобы правильно инкапсулировать данные, необходимо представлять структуру дан­ных выбранного протокола. Надеемся, что три последние прочитанные главы помогут вам понять этот процесс и все детали, необходимые для выполнения поставленных задач.

Рис. .9- Инкапсуляция данных по мере их прохождения сквозь стек протоколов

Что такое прикладной уровень?

Вам наверное уже понятно, что именно происходит на прикладном сетевом уровне. Он включает в себя все, касающееся непосредственно решаемой при­кладной задачи. Другими словами, в качестве программиста приложений Ин-тернет вы, разрабатывая программу, вместе с тем конструируете и прикладной уровень.

Являясь прикладным программистом, вы, по определению, занимаетесь разра­боткой прикладных программ. Конструирование программы тесно связано с выполняемыми функциями. Например, коль скоро вам необходимо написать сетевую программу, вам требуется обменяться данными с другим приложением Интернет. Для успешной разработки приложения Интернет необходимо знать, как принимать и посылать сетевые данные. Приступая к написанию, задайте себе вопрос: «Каким образом моя программа будет обмениваться данными с Интернет?» И вы уже знаете ответ: просто посылая информацию вниз по стеку протоколов.

Ваша ответственность за доставку данных заканчивается, как только прикладная программа передаст их низлежащему протоколу. Далее каждый последующий уровень в стеке протоколов, сквозь который пойдут данные, будет выполнять свою собственную функцию: определять адрес, маршрут и транспортировать данные по Интернет. Чтобы задействовать определенный протокол, необходимо для начала знать, какие из них доступны в вашей системе. Также необходимо знать, где именно в стеке они находятся и понимать выполняемые ими функции. Как правило, прикладные программы взаимодействуют с протоколами UDP и TCP.

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

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