Основы работы в Internet

Страница 7

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

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

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

Таким образом, протокол TCP обеспечивает гарантированную доставку с установлением логического соединения в виде байтовых потоков. Он освобождает прикладные процессы от необходимости использовать ожидания и повторные передачи для обеспечения надежности. Наиболее типичными прикладными процессами, использующими TCP, являются ftp и telnet. Кроме того, TCP использует система X-Windows (стандартный многооконный графический интерфейс с пользователем), ``r-команды'.

Большие возможности TCP даются не бесплатно, реализация TCP требует большой производительности процессора и большой пропускной способности сети. Когда прикладной процесс начинает использовать TCP, то начинают общаться модуль TCP на машине пользователя и модуль на машине сервера. Эти два оконечных модуля TCP поддерживают информацию о состоянии соединения - виртуального канала. Этот виртуальный канал потребляет ресурсы обоих оконечных модулей TCP. Канал этот, как уже указывалось, является дуплексным. Один прикладной процесс пишет данные в TCP-порт, откуда они модулями соответствующих уровней по цепочке передаются по сети и выдаются в TCP-порт на другом конце канала, и другой прикладной процесс читает их отсюда - из своего TCP-порта. эмулирует (создает видимость) выделенную линию связи двух пользователей. Гарантирует неизменность передаваемой информации. Что входит на одном конце, выйдет с другого. Хотя в действительности никакая прямая линия отправителю и получателю в безраздельное владение не выделяется (другие пользователи могут пользовать те же узлы и каналы связи в сети в промежутках между пакетами этих), но извне это, практически, именно так и выглядит.

Как бы хорошо это не звучало, но это не панацея. Как уже отмечалось, установка TCP-виртуального канала связи требует больших расходов на инициирование и поддержание соединения и приводит к задержкам передачи. Если вся эта суета - излишество, лучше обойтись без нее. Если все данные, предназначенные для пересылки, умещаются в одном пакете, и если вас не особенно заботит надежность доставки (? - читайте дальше, - поймете), то можно обойтись без TCP.

Имеется другой стандартный протокол транспортного уровня, который не отягощен такими накладными расходами. Этот протокол называется UDP - User Datagram Protocol - протокол пользовательских дейтаграмм. Он используется вместо TCP. Здесь данные помещаются не в TCP, а в UDP-конверт, который также помещается в IP-конверт. Этот протокол реализует дейтаграммный способ передачи данных.

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

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

В отличие от TCP, данные, отправляемые прикладным процессом через модуль UDP, достигают места назначения как единое целое. Например, если процесс-отправитель производит 3 записи в UDP-порт, то процесс-получатель должен будет сделать 3 чтения. Размер каждого записанного сообщения будет совпадать с размером соответствующего прочитанного. Протокол UDP сохраняет границы сообщений, определяемые прикладным процессом. Он никогда не объединяет несколько сообщений в одно целое и не делит одно сообщение на части.

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