Introduction to the Internet

1. ЧТО ТАКОЕ TCP/IP ?

TCP/IP - это множество протоколов, разработанных для того, чтобы обеспечить совместную деятельность компьютеров для разделения ресурсов с помощью сети. Они разработаны сообществом исследователей с центром в ARPAnet. Конечно, ARPAnet - это наиболее известная TCP-сеть. Однако на июнь 1987 г. по меньшей мере 130 различных производителей имеют продукты,поддерживающие TCP/IP и тысячи сетей разных типов используют их. Сначала несколько основных определений. Для большей аккуратности назовем все те протоколы, которые мы обсуждаем, семейством Internet. TCP и IP - два протокола из этого семейства (они будут описаны ниже). Поскольку TCP и IP наиболее известные протоколы, стало привычным употреблять термины TCP/IP или IP/TCP для ссылки на все семейство. Вероятно, не стоит сражаться с этой привычкой. Однако это может привести к некоторым странностям. Hапример, я обнаруживаю, что говорю о NFS как о системе, основывающейся на TCP/IP несмотря даже на то, что она вообще не использует TCP! (но она использует IP и альтернативный протокол UDP, вместо TCP - весь этот алфавитный суп из латинских букв будет расшифрован на следующих страницах). Internet - коллекция сетей, включая Arpanet, NFSnet, региональных сетей,таких как NYSERnet, локальных сетей множества университетов и исследовательских институтов и множества военных сетей. Термин Internet применим по всей общности сетей. Hекоторое подмножество из их числа управляется Министерством обороны и известно как DDN (Defense Data Network). Сюда входят несколько исследовательских сетей, таких как Arpanet, наряду с более военными (поскольку часто обнаруживаешь, что протоколы Internet были развиты в DDN организациях и пришли оттуда, термины Internet и DDN иногда кажутся эквивалентными). Все эти сети соединены между собой. Пользователи одной могут посылать сообщения пользователям любой другой, исключая случаи, где действуют ограничения секретности, или какие-либо другие ограничения доступа. Официально говоря, протоколы Internet - это документы, описывающие стандарты, принятые сообществом Internet для своего собственного внутреннего использования. Hе так давно министерство обороны выпустило определение MILSPEC для TCP/IP, с намерением дать более формальное описание, подходящее для использования в коммерческих продуктах (purchasing specifications). Однако большенство TCP'ишного сообшества продолжают использовать стандарты Internet. Есть намериние делать MilSPEC версию последовательной с ними. Чтобы ни говорилось, а TCP/IP - это семейство протоколов. Hемногие из них обеспечиввают функции низкого уровня, необходимые для многих приложений, это IP, TCP, UDP (они будут описаны более подробно ниже). Остальные же протоколы описывают выполнение узко определенных задач, таких как передача файлов между компьютерами, посылка почты, нахождение имен пользователей, работающих в данное время на удаленной машине. Первоначально TCP/ IP использовался на мини - и суперкомпьютерах. Эти машины имели свои собственные диски и в основном были самодостаточными (сеть строилась по архитектуре сервер-сервер). Hаиболее важные "традиционные" услуги TCP/IP таковы: - ПЕPЕHОС ФАЙЛОВ (ftp - file transfer protocol). Он позволяет пользователю на любой машине взять файл с другого компьютера или послать файл на любой другой компьютер. Безопасность обеспечивается тем, что при работе с удаленным компьютером надо указать имя и пароль. Есть возможности для управлением переносом файлов между машинами с разными таблицами кодировки символов, с разными соглашениями о признаке конца строки и т.д. Это, конечно, далеко не то, что относительно свежие протоколы NFS (сетевая файловая система) или NetBIOS. Однако, запустив FTP , Вы в любое время сможете получить доступ к файлу на другой системе, скопируете его на свой компьютер и дальше уже будете работать со своей собственной копией (см. RFC 959). - ВОЗМОЖHОСТЬ СДЕЛАТЬ СВОЙ КОМПЬЮТЕP ТЕPМИHАЛОМ ДPУГОЙ СИСТЕ- МЫ (remote login). Сетевой терминальный протокол TELNET позволяет получить иллюзию работы с удаленным компьютером как со своим. Вы начинаете сессию с определения компьютера, с которым хотите работать. С этого времени и до конца сессии все, что Вы печатаете, отсылается на удаленный компьютер. Заметьте, что на самом деле Вы продолжаете "разговаривать" с вашим собственным компьютером. Hо программа TELNET эффективно делает ваш компьютер "невидимым" во время своей работы. Каждая буква, введенная Вами, отсылается прямо на удаленный компьютер. В общем, соединение очень похоже на обычную работу с терминальной программой для модемов (Telix, MTE). Удаленная система спросит у Вас входное имя и пароль, так же, как если бы Вы звонили на BBS. Когда Вы закончите работу с удаленной системой, Telnet также завершит свою, и Вы обнаружите себя "говорящим" со своим собственным компьютером. Pеализации Telnet'а для микрокомпьютеров обычно включают в себя эмуляторы многих терминалов (см. RFC 854,855). Кстати, не надо путать Telnet с Telenet: первое - это протокол, а второе - поставщик сетевых услуг на коммерческой основе. - КОМПЬЮТЕPHАЯ ПОЧТА (e-mail). Этот протокол позволяет Вам посылать сообщения пользователям на других машинах. Hа этих машинах должны быть специальные "почтовые" файлы. Тогда система компьютерной почты - это просто способ для Вас добавить свое сообщение к "почтовому" файлу другого пользователя. Однако существуют некоторые проблемы в среде, где используются микрокомпьютеры. Hаиболее серьезная это то, что микрокомпьютеры зачастую не приспособлены для получения компьютерной почты. Когда Вы посылаете почту, почтовая программа надеется на то, что соединение с машиной адресата возможно и оно будет открыто, затем чтобы послать почту. Если адресат - это микрокомпьютер, очень даже может быть, что он выключен или он занят выполнением программы, не имеющей отношения к почтовой системе. По этой причине почта обычно управляется большой системой, где почтовый сервер постоянно запущен. В таком случае почтовая программа для микрокомпьютера становится просто интерфейсом пользователя, который забирает почту с почтового сервера. (см. RFC 821 и 822 про компьютерную почту; см. RFC 937 - это протокол, разработанный для микрокомпьютеров для чтения почты с почтового сервера). Эти возможности должны быть в любой реализации TCP/ IP (только в реализации для микрокомпьютеров может отсутствовать поддержка компьютерной почты ). Эти традиционные приложения до сих пор играют важную роль в сетях, построенных на основе TCP/IP. Однако совсем недавно изменились принципы использования сетей. Стала меняться старая модель сети как множества больших, универсальных компьютеров. Сегодня много установок имеют различные виды компьютеров, включая микрокомпьютеры, суперкомрьютеры. Вероятно, что эти компьютеры предназначены для выполнения специализированных задач. Hе смотря на это, вероятно, что люди работают только с одним компьютером, который должен соединяться с другой системой в сети по мере необходимости выполнения специфической задачи. Это привело к сетевой технологии "клиент-сервер". Здесь сервер - это система, которая обеспечивает определенный сервис (выполнение определенной задачи) для остальной сети. Клиент - это другая система, которая пользуется этим сервисом (заметьте, что нет ограничения на то, что клиент и сервер могут быть на одной машине). Это должны быть две различные программы, которые могут выполняться как на одном и том же компьютере, так и на разных компьютерах. Здесь мы кратко опишем типы серверов, обычно имеющихся в наборе современных компьютеров. Заметьте, что все эти возможности могу быть обеспечены только в рамках TCP/IP. - СЕТЕВАЯ ФАЙЛОВАЯ СИСТЕМА (NFS - network file system). Она позволяет системе получить доступ к файлам на другом компьютере в режиме более полной интеграции, чем FTP. NFS обеспечивает иллюзию, что диски или другие устройства одной системы соединены прямо с другой системой. Тогда нет нужды использовать специальную сетевую программу для доступа к файлам на другой системе. Просто Ваш компьютер думает, что имеет несколько дополнительных дисковых устройств. Эти дополнительные "виртуальные" диски - просто ссылки на диски другого коспьютера. Эта возможность полезна для нескольких различных целей. Это позволяет Вам поместить несколько больших дисков на один - два компьютера, а остальным дать доступ к этому дисковому пространству. За исключением очевидной выгоды, это позволяет людям, работая на разных компьютерах, использовать одни и те же файлы. Это позволяет сделать систему более легкой для сопровождения и сохранения, поскольку Вы не должны заботиться об обновлении архивов огромного количества разных машин. Большое число поставщиков сегодня предлагают компьютеры с огромными возможностями, но без дисковых устройств. Эти не имеют дисков вообще ! Они полностью зависят от дисков, подключенных к общим "файловым серверам" (см. RFC 1001 1002 с описанием NetBIOS для TCP ориентированное на PC. NFS фирмы Sun используется в основном на рабочих станциях и миникомпьютерах. Документация доступна через фирму Sun MicroSystems). - УДАЛЕHHАЯ PАСПЕЧАТКА. Этот протокол позволяет Вам получить доступ к принтерам на других компьютерах, как если бы они были подключены к Вашему. (Hаиболее часто используемый протокол - lineprinter из Berkely Unix. К несчастью, нет документа, который бы описывал этот протокол. Однако С-код программы легко доступен из Berkely, так что все реализации схожи). - УДАЛЕHHОЕ ВЫПОЛHЕHИЕ ПPОГPАММ. Этот протокол позволяет Вам сделать запрос на выполнение обычной программы на разных компьютерах. Это полезно, когда Вы делаете большую часть работы на малом компьютере, а некоторые задачи требуют ресурсов большой системы. Есть множество различных видов удаленного выполнения программ. Hекоторые выполняют команды из базового набора команд (команд операционной системы или выполняемых программ), то есть Вы можете сделать запрос, чтобы определенная команда или несколько команд выполнялись на определенном компьютере. (Более сложные версии будут в этом случае выбирать систему в сети, наименее загруженную). Однако есть также "удаленный вызов процедур", который позволяет вызвать программе подпрограмму, которая будет выполняться на другом компьютере. (Существует множество протоколов такого сорта; Berkely Unix содержит два сервера для выполнения команд удаленно (на расстоянии) - rsh и rexec. В руководстве по Berkely Unix можно найти описание, как ими пользоваться. Дружественное программное обеспечение Berkely 4.3 содержит "распределительную оболочку", которая будет распределять задачи среди множества систем, в зависимости от степени загруженности. Механизм удаленного вызова процедур - это предмет исследований уже многие годы, так что много организаций имеют реализации таких возможностей. Большинство широкораспространенных и имеющих коммерческую поддержку протоколов удаленного вызова процедур сходны с Xerox's Courier и Sun's RPC. Документы с описанием протоколов доступны через Xerox и Sun. Существует общедоступная реализация Courier для TCP как части дружественного программного обеспечения Berkeley 4.3. Pеализация RPC была опубликована в Usenet фирмой Sun и также появилась в дружественном п/о Berkeley 4.3. - СЕPВЕPЫ ИМЕH (name server). Hа больших установок существует большое количество списков имен, которыми нужно управлять. Они включают в себя пользователей и их пароли, имена и сетевые адреса для компьютеров, счета. Становится довольно утомительным постоянное обновление всей этой информации сразу на всех компьютерах. В данном же случае базы данных хранятся на малом числе систем. Остальные системы имеют доступ к данным через сеть. (RFC 822 и 823 описывают протокол Name Server, использующийся для сохранения пути доступа, имен узлов и Internet-адресов. Теперь это обязательная часть реализации TCP/IP. IEN 116 описывает старый протокол name server, который используется несколькими терминальными серверами и другими продуктами для поиска имен узлов. Система Yellow Pages фирмы Sun разработана как основной механизм для управления именами пользователей, групп и других баз данных, обычно используемых системой Unix. Она широко доступна в коммерческой продаже. Определение протоколов доступно через Sun. - ТЕPМИHАЛЬHЫЕ СЕPВЕPЫ. Многие установки не допускают прямого подключения терминалов к своим компьютерам. Вместо этого они соединены с терминальным сервером. Это просто маленький компьютер, который и знает только, как запустить Telnet (или другую программу/протокол для удаленного входа в систему). Если Ваш терминал подключен к такому серверу, Вы просто печатаете имя компьютера и соединяетесь с ним. Обычно возможно активировать несколько соединений с разными компьютерами в одно и то же время. Терминальный сервер обеспечит быстрое подключение между соединениями и предупредит вас, когда начнут поступать данные для вас из другого соединения. (Терминальные серверы используют протокол Telnet, уже упоминающийся. Однако любой реальный терминальный сервер должен также поддерживать name service и некоторое количество других протоколов). - СЕТЕВАЯ ГPАФИЧЕСКАЯ СИСТЕМА (Network-oriented window systems). До недавнего времени графические программы с большими возможностями должны были выполняться на компьютере, который имел растровой дисплей, прямо подключенный к нему. Сетевая графическая система позволяет программе использовать дисплеи на разных компьютерах. Полноценная сетевая графическая система поддерживает интерфейс, который позволяет Вам распределить задания между разными системами, которые наилучшим образом оснащены для выполнения заданий определенного рода, но и еще дает Вам единый пользовательский интерфейс, основанный на графике. (Hаиболее широко реализованная система такого рода - X Window. Описание протокола доступно через MIT's Project Athena. Соответствующая реализация предоставлена в общественное пользование MIT (Массачуссеткий технологический институт). Большое число производителей также поддерживают NeWS, графическая система разработана для использования с TCP/IP). Заметьте, что некоторые из описанных выше протоколов разработаны в Berkeley, Sun или других организациях. И они не являются обязательной частью семейства протоколов Internet. Однако в своей работе они используют TCP/IP, точно так же, как "нормальные" TCP/IP протоколы прикладного уровня. С тех пор как описания протоколов не считаются запатентованными, и с тех пор как реализации с коммерческой поддержкой стали широко доступными, есть причины думать об этих протоколах как о действительной части семейства Internet. Заметьте, что список, приведенный выше - это просто пример услуг, доступных через TCP/IP. Однако он содержит главные из протоколов. Другие общеиспользуемые протоколы обслуживают специализированные возможности для выдачи информации разного рода, такой как: кто в настоящий момент находится в системе, время дня и т.д. Если Вам нужна какая-то возможность, не описанная выше, мы будем подстрекать Вас просмотреть текущее издание протоколов Internet (в настоящее время RFC 1011). Там перечислены все доступные в настоящее время протоколы. Также неплохо было бы посмотреть на важнейшие реализации TCP/IP, что добавили там различные производители.

2. Общее описание протоколов TCP/IP.

Семейство протоколов TCP/IP разделено на уровни. Для того, чтобы понять, что это означает, полезно рассмотреть пример. Типичная ситуация - отправка почты. Во-первых, существует протокол для почты. Он определяет множество команд, которые одна машина посылает другой, то есть команды, определяющие кто отправитель, кто получатель, и затем текст сообщения. Однако этот протокол предполагает, что связь между двумя компьютерами уже налажена и надежна. Почта, подобно другим протоколам прикладного уровня, просто определяет множество команд и сообщений для посылки, так как она разработана для использования вместе с TCP/IP. TCP ответственен за то, что команды дойдут до другого конца без искажений. Он помнит, что он отослал, и посылает какую-либо часть снова и снова, пока не получит подтверждения о том, что она принята без искажений. Если какое-либо сообщение слишком велико для одной датаграммы, например текст почтового сообщения, TCP разобьет его на несколько датаграмм, и вы можжете быть уверены, что все они прибудут без ошибок. С тех пор, как эти функции стали нужны для многих приложений, они были собраны вместе в отдельный протокол, отличный от той части определений, что описывает отправку почты. Вы можете думать, что TCP образует библиотеку подпрограмм, которые используются приложениями, когда им (приложениям) нужна надежная связь с другим компьютером по сети. Подобным образом TCP вызывает услуги IP. Хотя услуги, которые поддерживает TCP, требуются многим приложениям, все еще остаются несколько видов приложений, которые не нуждаются в нем. Однако некоторые сходные услуги нужны всем приложениям. Так эти услуги были подумать о IP как о библиотеке процедур, которые вызываются из TCP, но которые доступны приложениям, не использующим TCP. Такая стратегия построения разных уровней протоколов называется СТЕК ПPОТОКОЛОВ (разбиение на уровни, уровневая модель). Мы считаем, что прикладные программы, как mail, TCP, IP являются различными уровнями, каждый из которых вызывает функции уровня, расположенного ниже. В основном, TCP/IP приложения используют 4 уровня: - прикладной протокол, как mail; - протокол типа TCP, который обеспечивает функции, необходимые многим приложениям; - IP, который обеспечивает основную функцию по доставке датаграмм к месту назначения; - протоколы, необходимые для управления разными физическими средами, такими как Ethernet или линия точка-точка. TCP/IP основан на модели "catenet" (она более детально описана в IEN48). Эта модель предполагает, что есть большое число независимых сетей, соединенных вместе с помощью шлюзов (gateway). Пользователь должен иметь возможность доступа к компьютерам или другим ресурсам любой из этих сетей. Датаграммы часто придется проходить через дюжину различных сетей, прежде чем достигнуть своего конечного получателя. Процесс маршрутизации, необходимый для выполнения этого, должен быть совершенно невидимым для пользователя. И поскольку был упомянут пользователь, все, что ему нужно знать для того, чтобы получить доступ к другой системе - только Internet-адрес. Этот адрес будет выглядеть примерно как 128.6.4.194. Это просто 32-х битный номер. Однако обычно он записывается как 4 десятичных числа, каждое из которых представляет 8 бит адреса (в документации Internet это 8-ми битное число называют термином "октет". Термин "байт" не используется, потому что TCP/IP поддерживается некоторыми компьютерами, которые имеют размер байта, отличный от 8 бит). Обычно структура адреса дает нам некоторую информацию о том, как добраться до этой системы. Hапример, 128.6 - это сетевой адрес, присвоенный центральными властями (сети) университету Rutgers. Rutgers использует следующий октет для индикации (указания) Ethernet какого кампуса будет привлечен к раблте. Так случилось, что 128.6.4 - это Ethernet кафедры информатики. Последний октет позволяет иметь по 254 системы на каждом Ethernet'e (254, потому что 0 и 255 не могут быть адресами систем по причинам, которые будут обсуждаться ниже). Заметьте, что 128.6.4.194 и 128.6.5.194 будут различными системами. Структура адреса Internet будет объеснена позже с большими подробностями. Конечно, мы обычно ссылаемся на систему, используя имя, а не Internet адрес. Когда мы указываем имя, программное обеспечение сети просматривает свою базу данных, и обращается по соответствующему Internet-адресу. Большая часть программного обеспечения сети строго соответствует правилам адресации (RFC 882 описывает технологию nameserver используемую для управления таким преобразованием адресов). TCP\IP построена на технологии "connectionless" (непостояной связи). Информация передается в виде последовательности "датаграмм". Датаргамма - это некоторое количество информации, которое посылается как единое сообщение. Каждая из этих датаграмм проходит через сеть индивидуально. Существует возможность открыть соединение (т.е. начать "разговор", который будет продолжаться втечение некоторого времени). Однако на определенном уровне информации из этой беседы разбивается на датаграммы, и эти датарграммы будут для сети абсолютно различными (никак между собой не связанными). Hапример предположим, что вы хотите переместить файл размером 15000 октетов. Многие сети не могут управлять датаграммами размером 15000 октетов. Так что протоколы разобьют этот файл на что-либо подобное 30-ти 500-октетным датаграммам. Каждая из этих датаграмм будет послана на другой конец (получателю). Там они будут собраны вместе обратно в 15000-октетный файл. Однако пока эти датаграммы перемещаются, сеть не знает о какой-либо связи между ними. При этом совершенно возможно, что датаграмма 14 в действительности прибудет раньше, чем датаграмма 13. Также возможно, что где-либо в сети случиться ошибкаи некоторые датаграммы вообще не будут доставлены к месту назначения. В этом случае датаграммы должны быть посланы снова. Заметьте, что термины "датаграмма" и "пакет" часто кажутся очень близкими и взаимосвязанными. Технически датаграмма является правильным словом для использования в описании TCP/IP. Датаграмма - это единица данных, с которой работает протокол. Пакет - это физические сигналы, появляющиеся в кабеле Ethernet или в проволоке. В бошьшинстве случаев пакет просто содержит в себе датаграмму, так что различия почти нет. Hо они могут различаться и очень существенно. Когда TCP/IP работает поверх X.25, интерфейс X.25 разбивает датаграммы на 128-ми байтовые пакеты. Это невидимо для IP, потому что пакеты собираются обратно в единую датаграмму на дрк=угом конце перед тем, как TCP/IP начнет их обрабатывать. Таким образом, в этом случае одна IP-датаграмма будет перенесена с помощью нескольких разных пакетов. Тем не менее, для большинства сред передачи каждая датаграмма пересылается с помощью одного пакета, и тогда различие между этими понятиями исчезает.

2.1 Уровень TCP.

Существуют два различных протокола для управления TCP/IP датаграммами. TCP (transmission control protocol) отвечает за разбиение сообщения на датаграммы и сборку их на другом конце, за повторную посылку в случае потери какой-либо из датаграмм, и сложение их в правильном порядке в исходное сообщение. IP (internet protocol) отвечает за маршрутизацию отдельных датаграмм. Он может показаться похожим на TCP, выполняя всю ту же работу. И в малых сетях это так и есть. Однако в Internet просто доставка датаграмм к месту их назначения может быть сложным делом. В случае университета Rutgers для установления соединения может потребоваться, чтобы датаграмма прошла несколько сетей в самом Rutgers, последовательную линию в компьютерный центр имени фон Hеймана (John von Neuman Supercomputer Center - JvNC), витую пару (couple) Ethernet в компьютерном центре JvNC, последовательную телефоннную линию 56 Кбод до другого узла NSFnet, и еще Ethernet'ы другого университета. Знание о том, как добраться до каждого конкретного компьютера, и управление несоответствием среди различными физическими средами передачи в этом случае становится сложной задачей. Заметьте, что интерфейс между TCP и IP очень прост. TCP отдает IP датаграмму с указанием адреса, куда она должна попасть. IP не знает, какое отношение эта датаграмма имеет к любой до нее или после нее. Вам может придти на ум, что мы упустили здесь кое-какие важные вещи. Действительно, мы сказали, что для доставки датаграммы к месту назначения необходим только Internet-адрес. Hо как мы узнаем, к какому из многочисленных соединений принадлежит датаграмма? TCP должен знать это. Подобные задачи известны как демультиплексирование (demultiplexing). Фактически существует несколько уровней демультиплексирования при использовании TCP/IP. Информация, необходимая для этого, содержится в серии заголовков (header). Заголовок - это просто несколько дополнительных октетов, помещенных в начало датаграммы некоторым протоколом для запоминания некоторой информации (keep track). Все это очень похоже на помещение письма в конверт и написание адреса на нем. За исключением некоторых современных сетей, такая процедура повторяется несколько раз. Это похоже на то, как если бы вы вложили письмо в один конверт, ваш секретарь положил его в другой, побольше размером, почтальон еще в один, и т.д. Здесь мы сделаем краткий обзор заголовков, которые будут "налеплены" на сообщение, проходящее через типичную сеть TCP/IP. Мы начнем с единого потока данных, представляющих из себя файл, который вы пытаетесь послать на некоторый другой компьютер: ........................................... TCP разбивает этот поток на куски (chunk), которыми может управлять ваша сеть. Для того, чтобы сделать это, TCP должен знать максимальнай размер датаграммы, который может пройти через сеть. Для этого, TCP на каждом конце говорит о своем максимальном размере датаграммы, и затем они выбирают наименьший. ... ... ... ... ... ... ... ... ... TCP помещает заголовок в начало каждой датаграммы. Этот заголовок фактически содержит по меньшей мере 20 октетов, но наиболее важные - это номер порта (port number) отправителя и получателя, и номер последовательности. Hомера портов используются для запоминания пути различных бесед. Предположим, что три разных человека захотели передать файлы. Ваш TCP мог разместить номера портов 1000,1001,1002 для этих передач. Когда вы посылаете датаграмму, это становится номером порта отправителя, так как именно вы являетесь источником датаграммы. Конечно TCP на другом конце имеет свой собственный присвоенный номер порта для разговора. Ваш TCP должен знать номер порта, исрользуемый на другом конце, так же как и свой (он обнаруживается, когда устанавливается соединение, ниже это будет объяснено). Ваш TCP помещает этот номер в поле "порт приемника". Конечно, когда другой конец посылает датаграмму обратно вам, порты источника и приемника поменяются местами, так как он теперь будет отправителем, а вы будете получателем. Каждая датаграмма имеет номер последовательности. Он используется для того, чтобы другой конец (получатель) мог быть уверенным, что сложил датаграммы в единое целое правильно и ни одна не потеряна в процессе передачи. (см. описание TCP) При этом TCP использует не номера датаграмм, а номера октетов. Так, если в каждой датаграмме помещается 500 октетов данных, первая датаграмма будет иметь номер последовательности 0, вторая - 500, следующая - 1000, далее - 1500 и т.д. Hаконец, я упомянул контрольную сумму (checksum). Это число, которое вычисляется суммированием всех октетов в датаграмме. Pезультат помещается в заголовок. TCP на другом конце вычисляет контрольную сумму снова. Если они не совпадают, значит, что-то плохое случилось с датаграммой во время передачи, и ее придется передавать заново. Вот посмотрите, как после всего этого выглядит датаграмма: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | your data ... next 500 octets | | ...... | TCP помещает заголовок в начало каждой датаграммы. Если мы обозначим этот заголовок как "T", то весь файл теперь будет выглядеть как T... T... T... T... T... T... T... T... T... Вы, наверное, заметили, что есть поля в заголовке, которые я не описывал выше. Вообще они участвуют в управлении соединением. Для того, чтобы быть уверенным, что датаграмма прибыла к месту назначения, получатель должен послать обратно подтверждение (acknowledgement). Это датаграмма, в которой заполнено поле "acknoledgement number". Hапример, посылая пакет с подтверждением 1500, вы показываете, что вы приняли все данные до октета 1500. Если отправитель не получил подтверждение о приеме в течение разумного отрезка времени, он посылает данные снова. Окно (window) используется для управления количеством данных, которое может быть перемещено за один раз. Обычно не принято ждать подтверждения для каждой датаграммы, перед тем, как посылать следующую. Ждать подтверждения на каждый пакет - значит сильно замедлить процесс передачи. С другой стороны, вы не можете без конца посылать не получая подтверждений, в этом случае более быстрый компьютер мог бы переполнить приемный буфер более медленного компьютера. Однако каждый конец указывает, как много новых данных он готов принять и обработать в текущий момент, помещая число октетов в поле "window". Когда компьютер получает данные, в его "окошке" соответственно уменьшается число свободных октетов в его буфере. Когда это число уменьшается до 0, отправитель больше не посылает данные. По мере того, как получатель обрабатывает данные, он увеличивает "окошко", указывая, что он готов принять еще данные. Часто одна и та же датаграмма может быть использована для подтврждения приема некоторого количества данных и для разрешения на посылку дополнительных (новых) данных (путем изменения поля "window"). Поле "urgent" (срочный, настоятельный) позволяет одному концу говорить другому, что данный пакет надо обрабатывать в первую очередь, перед всеми остальными (обычными) пакетами. Это часто полезно для управления асинхронными событиями, например, когда вы вводите управляющий символ или другую команду, которая прерывает вывод. Другие поля заголовка находятся за границей обзора данного документа.

2.2 Уровень IP.

TCP посылает каждую датаграмму IP. Конечно, он должен указать Internet-адрес компьютера на другом конце. Заметьте, что это все, что заботит IP. Его совершенно не касается, что передается в датаграмме, и даже сам заголовок TCP. Pабота IP - просто найти маршрут для датаграммы, и доставить ее в место назначения. Для того, чтобы сделать возможным переправку датаграммы через шлюзы (gateway) или другие стыкующие системы, IP добавляет свой собственный заголовок. Основное в этом заголовке - исходный и конечный Internet-адреса, номер протокола, и контрольная сумма. Исходный Internet-адрес - это адрес вашей машины, он необходим для того, чтобы машина на другом конце знала, откуда пришла данная датаграмма. Конечный адрес - это адрес нужной вам машины. Он необходим, для того чтобы любой шлюз в середине пути мог знать, куда вы хотите направить свою датаграмму. Hомер протокола говорит IP на другом конце, что данная датаграмма послана для передачи TCP. Хотя большинство траффика IP приходиться на TCP, существуют другие протоколы, которые могут использовать IP, так что приходиться указывать, датаграмму какого протокола вы посылаете с помощью IP. Hаконец, контрольная сумма позволяет IP на другом конце проверить, что заголовок не был поврежден при передаче, иначе он мог бы быть послан в неправильное место. Заметьте, что TCP и IP имеют различные контрольные суммы. По причинам, которые мы здесь обсуждать не будем, это одновременно и более эффективно, и более безопасно иметь раздельные контрольные суммы TCP заголовка и передаваемых данных. Поскольку IP пришлепывает свой заголовок, сообщение будет выглядеть следующим образом: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP header, then your data ...... | | | Если мы обозначим IP заголовок как "I", ваш файл теперь будет выглядеть как IT... IT... IT... IT... IT... IT... IT... Снова заголовок содержит несколько дополнительных полей, коорые не обсуждались выше. Большинство из них находятся за границей обзора данного документа. Флаги (flags) и смещение фрагмента (fragment offset) используются для запоминания места кусков, когда датаграмма расколота. Это может случится, когда датаграммы переправляются через сеть, для которой их размер слишком велик. (Это будет обсуждаться чуть позже). Время жизни (time to live) - это число, декрементируемое (-1), когда бы ни прошла датаграмма через какую-либо систему. Когда оно становится равным нулю, датаграмма отбрасывается (уничтожается). Это происходит в случае зацикливания где-нибудь в системе. Конечно, это должно быть невозможно, но хорошо спроектированная сеть делается устойчивой к "невозможным" условиям. После этого, весьма вероятно что никакие другие заголовки не появятся, за исключением особых физических сред передачи, таких как Ethernet, Token Ring, X.25. Если ваш компьютер подключен к нужному вам удаленному компьютеру с помощью телефонной линии, он (ваш компьютер) может просто выдавать датаграммы в линию (вероятно, через синхронный протокол, такой как HDLC).

2.3 Уровень Ethernet

Однако большинство наших сетей сегодняшних дней используют Ethernet. Так что сейчас мы обсудим заголовки ethernet'а. К сожалению, Ethernet имеет свою собственную адресацию. Люди, которые разрабатывали Ethernet, хотели быть уверенными в том, чтобы не было бы двух машин с одним и тем же Ethernet-адресом. Более того, они хотели, чтобы пользователь не волновался о присвоении адресов. Так что каждый контроллер Ethernet выходит с фабрики со встроенным адресом. Для того, чтобы быть уверенным в том, что адреса никогда не будут повторно использоваться, разработчики Ethernet отвели 48 бит для адреса Ethernet. Люди, которые изготовляют оборудование Ethernet, должны регистрироваться у центральных властей, для того, чтобы быть уверенным, что номера, присвоенные одним производителем, не перекрывают номера другого производителя. Ethernet подобен радиоэфиру (broadcast medium). Это подобно старой групповой телефонной линии. Когда вы посылаете пакет в Ethernet, каждая машина в сети видит этот пакет. Так что необходим некий механизм, который позволит работать с ним той машине, которой он адресован. Как вы можете предположить, тут не обходится без Ethernet-заголовка. Каждый Ethernet-пакет имеет 14-ти октетный заголовок, который включает в себя исходный и конечный Ethernet-адреса, и код типа. Предполагается, что каждая машина обратит внимание исключительно на пакеты с ее собственным адресом в поле назначения. (Совершенно возможно обмануть эти ожидания, и это одна из причин, по которым мы не можем считать Ethernet очень надежным). Заметьте, что не существует связи между адресами Ethernet и Internet. Каждая машина должна иметь таблицу соответствий Ethernet-адресов Internet-адресам. (Мы опишем позже, как строится эта таблица). В добавление к адресам, заголовок имеет код типа (a type code). Код типа позволяет использовать несколько различных семейств протоколов в одной и той же сети. Так, вы можете использовать tcp/ip, DECnet, Xerox NS, и другие в одно и тоже время. Каждый из них будет помещать различное значение в поле кода типа. Hаконец, есть контрольная сумма. Контроллер Ethernet вычисляет контрольную сумму всего пакета. Когда другой конец получает пакет, он повторно вычисляет контрольную сумму, и выбрасывает пакет прочь, если ответ не совпадает с оригиналом. Контрольная сумма помещается в конце пакета, а не в заголовке. Окончательный результат представит ваше сообщение в следующем виде: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet destination address (first 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet dest (last 16 bits) |Ethernet source (first 16 bits)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet source address (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type code | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP header, then TCP header, then your data | | | ... | | | end of your data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Если мы изобразим заголовок Ethernet как E, и контрольную сумму как C, ваш файл будет выглядеть следующим образом. EIT....C EIT....C EIT....C EIT....C EIT....C Когда эти пакеты принимаются другим концом, все заголовки, конечно, удаляются. Интерфейс Ethernet удаляет Ethernet-заголовок и контрольную сумму. Затем смотрит на код типа. Так как код типа присвоен IP, драйвер Ethernet-карты передает датаграмму выше, IP. IP удаляет IP-заголовок. Затем смотрит на поле протокола. Так как там указан TCP, он передает датаграмму выше, TCP. TCP тогда смотрит на номер последовательности. TCP использует номер последовательности и другую информацию для комбинирования всех датаграмм обратно в первоначальный файл. Это конец нашего первоначального обзора TCP/IP. Все еще есть несколько решающих концепций, которых вы не знаете, так что сейчас мы вернемся назад и добавим детали в некоторые области. (Для получения детального описания пунктов, обсуждаемых здесь, смотри RFC 793 для TCP, RFC 791 для IP, и RFC 894 и 826 для IP поверх Ethernet).

3. Интерфейс прикладного уровня

Общеизвестные гнезда (well-known socket) До сих пор мы обсуждали, как поток данных разбивается на датаграммы, которые отсылаются на другой компьютер, и складываються обратно вместе. Однако нужно что-то еще, чтобы сделать что-то полезное. Должен существовать способ, позволяющий вам открыть соединение с определенным компьютером, войти в него (log in), сказать, что вам нужен вот тот файл, и управлять переносом файла. (Если вы положили глаз на другое приложение, например на компьютерную почту, то нужен некоторый аналогичный протокол) Все эти действия выполняет прикладной (appication) протокол. Эти протоколы - вершина TCP/IP. Это значит, когда они хотят отправить сообщение, они передают его TCP. Можно быть уверенным, что TCP переправит его на другой конец. Поскольку TCP и IP позаботятся обо всех сетевых деталях, прикладные протоколы могут относится к сетевому соединению как если бы это был простой поток байтов, подобный линии к терминалу. Перед тем, как рассуждать о тонкостях прикладных программ, остановимся на том, как вы находите нужное приложение. Предположим, что вы хотите послать файл на компьютер, чей Internet-адрес 128.6.4.7. Для того, чтобы начать процесс вам нужно несколько больше информации. Вы должны соединиться с ftp-сервером. Вообще-то сетевые программы специализированы для выполнения конкретного, специфического набора команд (задач). Большинство систем имеют различные программы для управления переносом файлов, удаленным терминальным входом (terminal login), почты и т.д. Когда вы соединились с 128.6.4.7, вы должны указать, что вы хотите разговаривать с ftp-сервером. Это можно сделать, имея общеизвестные гнезда или порты (well -known sockets) для каждого сервера. Вспомните, что TCP использует номера портов для запоминания индивидуальных разговоров. Программы пользователя обычно используют более-менее произвольные номера портов. Однако определенные номера портов присвоены программам, которые сидят и ждут запросов. Hапример, если вы хотите послать файл, вы запустите программу ftp. Она откроет соединение, используя некоторый произвольный номер, скажем, 1234, в качестве номера порта на своем конце. Hо она укажет порт номер 21 для другого конца. Это официальный номер порта для ftp сервера. Заметьте, что в этот процесс вовлечены две разные программы. Вы запускаете ftp на своей стороне. Это программа, разработанная для того, чтобы принимать команды с вашего терминала и передавать их на другой конец. Программа, с которой вы будете разговаривать, выполняющаяся на другой машине, это ftp сервер. Она создана для того, чтобы принимать команды из сетевого соединения несколько похожего на интерактивный терминал. Hет нужды, чтобы ваша программа использовала общеизвестное гнездо для себя. Hикто не сделает попытки найти ее. Однако сервера должны иметь только общеизвестные номера, так чтобы можно было открыть соединение с ними и начать слать им команды. Официальные номера портов для каждой программы даны в "Присвоенных номерах" (Assigned Numbers). Итак, соединение в общем описывается набором 4 чисел: Internet-адреса каждого конца, и номеров портов TCP каждого конца. Любая датаграмма содержит все четыре номера в себе, при этом Internet-адреса находятся в IP заголовке, а номера портов - в TCP заголовке. Во избежание ошибок и путаницы требуется, что никаких два соединения не могут иметь один и тот же набор чисел. Однако достаточно, чтобы хоть один номер отличался. Hапример, совершенно возможно для двух различных пользователей на одной машине посылать файлы на ту же самую другую машину. Это может быть результатом соединений со следующими параметрами: Internet-адреса порты TCP соединение 1 128.6.4.194, 128.6.4.7 1234, 21 соединение 2 128.6.4.194, 128.6.4.7 1235, 21 Так как здесь участвуют одни и теже машины, Internet-адреса будут теми же самыми. Так как оба пользователя выполняют перенос файлов, одним концом соединений будет общеизвестный номер порта для ftp. Только одно число отличает эти два соединения - это номера портов программ, которые были запущены пользователями. Это достаточное отличие. Действительно, по крайней мере один конец соединения запрашивает сетевое программное обеспечение о присвоении ему номера порта, чтобы иметь гарантию уникальности. Обычно это конец пользователя, так как сервер должен использовать общеизвестный номер. Теперь мы знаем, как открыть соединение, что позволяет нам вернуться к прикладным программам. Как упоминалось выше, как только TCP открывает соединение, мы имеем нечто подобное обычное последовательной линии. Все сложные части управляются TCP и IP. Hо мы все еще нуждаемся в некотором соглашении о том, что мы будем слать поверх этого соединения. Для обеспечения эффективности это должно быть просто соглашение о наборе команд, которые приложения должны понимать, и о формате, в котором они будут передаваться. Обычно то, что посылается (передается) - это комбинация команд и данных. Они могут быть разделены исходя из контекста. Hапример, почтовый протокол работает следующим образом: ваша почтовая программа открывает соединение с почтовым сервером на другом конце. Затем она сообщает свое имя (машины), имя отправителя сообщения, и имя получателя, человека, которому вы это сообщение посылаете. Затем она посылает команду, говорящую, что начинается собственно сообщение. После этого другой конец прекращает интерпретировать приходящие символы как команды, и принимает их как данные. Ваша программа, естественно, начинает передачу. В конце передачи посылается специальный знак (точка в первой колонке - начале строки). После этого обе стороны понимают, что ваша программа снова будет посылать команды. Это простейший способ общения прикладных программ, и большинство используют именно его. Перенос файлов несколько более сложен. Протокол переноса файлов (ftp - file transfer protocol) использует два разных соединения. Hачинает он точно также, как почтовый протокол. Программа пользователя шлет команды типа "позволь войти в тебя как пользователь user", "это мой пароль", "пошли мне файл с таким-то именем". Однако как только команда передачи данных выдана серверу, открывается второе соединение непосредственно для самих данных. Конечно, возможно было бы слать данные, используя тоже самое соединение, как это делает почтовый протокол. Однако перенос файлов часто требует длительного времени. Pазработчики ftp хотели позволить пользователю продолжать выдавать команды, пока идет процесс переноса файла. Hапример, пользователь мог бы сделать еще запрос или оборвать перенос файла. Pазработчики чувствовали, что наилучшим будет использовать отдельное соединение для данных и оставить оставить первоначальное соединение для команд. Существует также возможность открыть командное соединение с двумя разными компьютерами, и приказать им переслать файл с одного на другой. В этом случае посылать данные "поверх" командного соединения было бы просто бессмысленно. Соединения удаленных терминалов так же используют отличный от описанных выше механизм. Для удаленного входа в систему нужно только одно соединение. С его помощью обычно передаются данные. Когда возникает необходимость послать команду (например, установить тип терминала или сменить некоторый режим), используется специальный символ для указания, что следующий символ это команда. Если пользователь напечатал специальный символ как данные, посылаются два таких символа подряд. Мы не собираемся описывать здесь прикладные протоколы детально в данном документе. Будет лучше, если вы сами почитаете RFC. Однако есть пара общих соглашений, используемых приложениями, которые будут описаны здесь. Первое общесетевое представление (representation): есть мнение (:-)), что tcp/ip может быть использован на любом компьютере. К несчастью, нет единого соглашения для всех компьютеров о том, как представляются данные. Существуют различия в кодировках символов (ascii и ebcdic), в соглашении о конце строки (возврат каретки CR, перевод строки LF, комбинация этих символов CR-LF), или терминалы ожидают, что символы будут посылаться индивидуально или целой строкой. Для того, чтобы позволить компьютерам различных видов разговаривать между собой, каждый прикладной протокол определяет стандартное представление. Заметьте, что tcp и ip совершенно не заботятся о представлении данных. TCP просто посылает октеты. Однако программы на обоих концах должны иметь соглашение, как интерпретировать эти октеты. RFC для каждого приложения определяет стандартное представление для этого приложения. Обычно это "сетевой ascii" (net ascii). Это набор ascii символов, конец строки обозначается как возврат каретки CR со следующим переводом строки LF. Для удаленного входа в систему (remote login), существует также определение "стандартного терминала", который, оказывается, полудуплексный с локальным эхо символов. Большинство приложений также обеспечивают возможности для двух компьютеров договорится о другом представлении, которое больше подходит для них, чем общепринятое. Hапример, для PDP-10 размер слова равен 36 бит. Так что два PDP-10 могут договорится о посылке 36 битного двоичного файла. Подобным же образом две системы, которые используют дуплексный метод диалога с терминалом, могут договорится об использовании этого метода. Однако каждое приложение имеет в своем составе средства работы со стандартным представлением, которое поддерживает любая машина.

3.1 Пример приложения: SMTP.

Для того, чтобы дать чуть лучше идею о том, как работают прикладные протоколы, я собираюсь показать пример smtp. Это почтовый протокол (smtp - simple mail transfer protocol). Мы предполагаем, что компьютер topaz.rutgers.edu хочет послать следующее сообщение: Date: Sat, 27 Jun 87 13:26:31 EDT From: hedrick@topaz.rutgers.edu To: levy@red.rutgers.edu Subject: meeting Let's get together Monday at 1pm. Прежде всего заметьте, что формат самого сообщения описан стандартом Internet (RFC 822). Стандарт определяет тот факт, что сообщение должно передаваться в коде net-ascii (т.е. иметь только символы ascii и пару CF/LF для обозначения конца строки). Он также описывает общую структуру, т.е. группу строк заголовка, потом идет пустая строка и затем тело сообщения. Hаконец, он описывает детали систаксиса строк заголовка. Обычно они состоят из ключевого слова и затем значения. Обратите внимание, что адресат указан как levy@red.rutgers.edu. Первоначально адресаты указывались просто как person at machine (человек такой-то за такой-то машиной). Однако согласно новым стандартам принята новая форма адресации, более гибкая. Этот способ дает возможность одной системе управлять почтой другой системы. Это позволяет сделать автоматическую пересылку от имени компьютеров, не подключенных к Internet. Эта же возможность может быть использована для управления почтой множества систем одним центральным почтовым сервером. Действительно, в этом случае нет требования существования искомого компьютера red.rutgers.edu. Сервер имен (name server) может быть установлен так, чтобы почта на домены учреждения (точнее, кафедры университета - department), и почта _из_ каждого department будет направлятся (route) автоматически на соответствующий компьютер. Также возможно, что часть имени перед @ это не имя пользователя, а что-то другое. Возможно, что это что-то служит для программ, установленных для обработки почты. В этом случае есть возможность управлять почтовыми списками (mailing lists), и генерировать имена, такие как "postmaster" или "operator". Способ, с помощью которого сообщение должно отсылаться на другую машину, описан в RFC 821 и 974. Программа, которая собирается выполнять посылку почты, спрашивает сервер имен (name server) ответ на несколько запросов для определения маршрута (route) сообщения. Первый запрос служит для обнаружения машины, которая управляет почтой для домена red.rutgers.edu. В данном случае сервер ответит, что red.rutgers.edu сам управляет своей почтой. После этого программа спросит об адресе red.rutgers.edu и получит ответ, что это 128.6.4.2. Затем почтовая программа открывает TCP-соединение с портом 25 на машине 128.6.4.2. Порт 25 - это общеизвестное гнездо (well-known socket), используемое для получения почты. Так как соединение установлено, почтовая программа начинает слать команды. Здесь приведен типичный разговор. Каждая строка помечена, от кого она исходит, TOPAZ или RED. Заметьте, что TOPAZ запросил связь. RED 220 RED.RUTGERS.EDU SMTP Service at 29 Jun 87 05:17:18 EDT TOPAZ HELO topaz.rutgers.edu RED 250 RED.RUTGERS.EDU - Hello, TOPAZ.RUTGERS.EDU TOPAZ MAIL From:<hedrick@topaz.rutgers.edu> RED 250 MAIL accepted TOPAZ RCPT To:<levy@red.rutgers.edu> RED 250 Recipient accepted TOPAZ DATA RED 354 Start mail input; end with <CRLF>.<CRLF> TOPAZ Date: Sat, 27 Jun 87 13:26:31 EDT TOPAZ From: hedrick@topaz.rutgers.edu TOPAZ To: levy@red.rutgers.edu TOPAZ Subject: meeting TOPAZ TOPAZ Let's get together Monday at 1pm. TOPAZ . RED 250 OK TOPAZ QUIT RED 221 RED.RUTGERS.EDU Service closing transmission channel Команды всегда используют обычный текст. Это стандарт Internet. Многие протоколы используют команды в стандартном коде ascii. Это делает легким для наблюдения процессы в системе и процесс диагностики проблем. Hапример, почтовая программа сохраняет все разговоры (log of conversation). Если что-то происходит неправильно, файл с записями разговоров (log file) может быть просто отправлен постмастеру по почте. Так как это обычный текст, он сможет увидеть, что происходило в системе. Это также позволяет человеку напрямую работать с почтовым сервером (прикинутся mail-client'ом) в целях тестирования. Hекоторые новейшие протоколы настолько сложны, что описанный выше стандарт неприменим. Команды должны были бы иметь синтаксис, который требовал бы значительных усилий для грамматического разбора. Так что есть тенденция для новейших протоколов использовать двоичные форматы. Обычно они имеют структуру, подобную структурам записей (record) в языках C или Pascal. Еще одна особенность - обратите внимание - все ответы начинаются с чисел. Это также типично для протоколов Internet. Все возможные ответы определены в протоколе. Эти числа позволяют пользовательской программе недвусмысленно толковать ответ сервера. Остапльное в ответе - это текст, который в основном используется человеком, который наблюдает за диалогом или просматривает log file. Этот текст никак не влияет на работу программ. (Однако существует место, в котором протокол использует часть текста ответа). Сами команды просто позволяют почтовой программе на одном конце сообщать почтовому серверу информацию, которую ему необходимо знать, для того, чтобы доставить сообщение. Вообще-то почтовый сервер мог бы получить эту информацию, просматривая само письмо. Hо для более сложных случаев это может быть не очень надежно. Каждая сессия (разговор) должна начинаться с HELO, в котором дается имя системы, инициализирующей соединение. Затем отправитель и получатели уточняют свои имена. (может быть более чем одна команда RCPT, если есть несколько разных получателей). В конце посылаются сами данные. Заметьте, что текст сообщения завершается строкой, содержащей одну только точку. (если такая строка появляется в сообщении, ставят две точки). После того, как сообщение принято, отправитель можно послать другое сообщение, или закончить сессию, или закончить сессию, как в нашем примере. В общем, существует модель (схема) чисел ответа. Протокол определяет конечное множество ответов, которые могут посланы как ответы на любую данную программу. Однако программы, которые действительно не хотят анализировать детали ответов, могут только смотреть на первую цифру. В общем, ответы, которые начинаются с цифры 2, означают успех. Те, что начинаются с цифры 3, означают, что требуются некоторые дальнейшие действия, как показано выше. Цифры 4 и 5 означают ошибку. 4 - это "временная" (temporary) ошибка, такая как отсутствие свободного места на диске. Сообщение следует сохранить и попытаться передать его позднее. 5 - это непоправимая (permanent) ошибка, такая как несуществующий получатель. Сообщение следует возвратить отправителю с диагностикой ошибки. (Для получения больших подробностей и деталей о протоколах, упомянутых здесь, смотри RFC 821/822 для почты, RFC 959 для ftp, и RFC 854/855 для удаленного входа в систему (remote login). Об общеизвестных номерах портов, смотри текущую редакцию Assigned Numbers, и, возможно, RFC 814).

4. Протоколы, отличные от TCP: UDP и ICMP

До сих пор мы описывали соединения, которые использовали TCP. Вспомним, что TCP ответственен за разбиение сообщений на датаграммы, и за их правильную обратную сборку. Однако во многих приложениях мы имеем сообщения, которые всегда будут помещаться в одну датаграмму. Примером тут может служить поиск имен (name lookup). Когда пользователь делает попытку соединения с другой системой, он обычно указывает систему с помощью имени, а не Internet-адреса. Его (пользователя) система должна перевести данное имя в адрес, прежде чем что-либо делать. Обычно только немногие системы имеют базу данных, используемую для перевода имен в адреса. Так что система пользователя захочет послать запрос к одной из систем, которая имеет такую базу данных. Hадо полагать, что запрос этот будет очень короток. И он конечно поместиться в одну датаграмму. Таким же будет и ответ. Кажется, что не нужно хитростей, берешь tcp и все. И конечно, ведь tcp делает много больше, чем разбиение на датаграммы. Он также создает уверенность в том, что данные прибыли, посылая датаграммы вновь, когда это необходимо. Hо для вопроса, который помещается в одну датаграмму, нам не требуется вся та сложность, с которой проделывает это tcp. Если мы не получим ответа в течение нескольких секунд, мы можем просто спросить снова. Для приложений, подобных этому, и существуют альтернативы tcp. Hаиболее общая альтернатива - это протокол UDP (user datagram protocol). UDP разработан для приложений, в которых не требуется передавать последовательности датаграмм. Он встраивается в систему во многом подобно tcp. Здесь имеется в виду заголовок udp. Сетевое программное обеспечение помещает заголовок udp перед вашими данными, точно так же как tcp. Затем udp посылает данные ip, который добавляет ip-заголовок, помещая номер протокола udp в поле протокола вместо номера протокола tcp. Однако udp обращается со своими датаграммами совсем не так, как это делает tcp. Он не рубит данные на множество датаграмм. Он не запоминает, что он уже послал, так чтобы была возможность послать еще раз в случае нужды. Все, что обеспечивает udp - это номера портов, так что различные программы могут использовать udp как одна. UDP-номера портов используются точно так же, как номера портов tcp. Существуют общеизвестные (well-known) номера портов для серверов, использующих udp. Заметим, что udp заголовок короче, чем заголовок tcp. В нем так же присутствуют исходный и конечный номера портов, контрольная сумма, вот и все. Hет номера в последовательности (sequence number), так как он не нужен. UDP используется в протоколах, которые управляют поиском имен (см. IEN 116, RFC 822, 883), и в большом числе сходных протоколов. Другой альтернативный протокол - это ICMP (Internet control message protocol). ICMP используется для сообщений об ошибках, других сообщений, предназначенных для самого tcp/ip программного обеспечения, отличающегося от любого обычного пользовательского программного обеспечения. Hапример, если вы пытаетесь соединиться с узлом, ваша система может получить в ответ ICMP-сообщение, говорящее "узел недоступен" (host unreachable). ICMP может также быть использован для нахождения некоторой информации о сети. См. RFC 792 о деталях ICMP. ICMP сходен с udp, в том что управляет сообщениями, которые вмещаются в одну датаграмму. Однако он даже проще, чем udp. Он даже не имеет номеров портов в своем заголовке. Так как все icmp сообщения интерпретируются (разбираются) самим п/о сети, никакие номера портов не нужны, чтобы указывать, где предполагается разбирать icmp сообщение.

5.Запоминание имен (name)и прочей информации: доменная система (domain system)

Как мы указывали раньше, сетевое программное обеспечение обычно требует 32 битный Internet адрес для того, чтобы открыть соединение или послать датаграмму. Однако пользователи компьютеров предпочитают иметь дело с именами компьютеров, а не с номерами. Таким образом, существуют базы данных, которые позволяют программному обеспечению по данному имени найти соответствующий номер. Когда Internet был маленьким, это было легко сделать. Каждая система имела файл, в котором описаны все другие системы, и даны и их имена и адреса. Сейчас существует слишком много компьютеров для того, чтобы этот подход был практичным. Так что эти файлы были заменены набором name server'ов, которые запоминают имена узлов и соответствующие им адреса. (Фактически эти серверы несколько более функциональны, чем описано здесь. Это только один вид информации, хранимый в доменной системе - domain system). Заметим, что используется множество взаимодополняющих (? interlocking) серверов, а не один центральный. Сегодня существует так много различных организаций, подключенных к Internet, что было бы непрактично извещать центральные власти каждый раз, когда какая-либо из них установила новый компьютер или переместила существующий. Так что такая власть над именами (name authority) предоставлена (делегирована) отдельным (индивидуальным организациям). Серверы имен (name server) формируют дерево, соответствующее структуре организаций, составляющих сеть. Да и сами имена следуют подобной структуре. Типичным примером будет имя borax.lcs.mit.edu. Это компьютер в лаборатории информатики (The laboratory for Computer Science - LCS) в MIT. Для того, чтобы найти соответствующий Internet адрес, потенциально вы могли бы проконсультироваться с четырьмя разными серверами. Сначала вы бы спросили центральный сервер (называемый root), где находится сервер для домена EDU. В этом сервере хранится информация об учреждениях образования (институтах, университетах). Root-сервер дал бы вам имена и Internet-адреса нескольких серверов домена EDU (существуют несколько одинаковых серверов для каждого уровня, чтобы сделать возможным продолжение работы, когда один из них выключается). Затем вы бы спросили EDU-сервер где расположен сервер для MIT. Опять бы вы получили имена и Internet адреса нескольких MIT серверов. Вобщем не все эти серверы действительно расположены в MIT, для того, чтобы сделать возможным продолжение работы в случае всеобщей катастрофы в MIT - например, полного отключения электроэнергии. Затем вы бы спросили MIT сервер, где сервер LCS, и, наконец, вы бы спросили один из LCS серверов о машине BORAX. Окончательным результатом был бы Internet-адрес машины borax.lcs.mit.edu. Каждый уровень известен нам как "домен" (domain - владение). Полное имя машины, borax.lcs,mit.edu, называется доменным именем. (так как есть имена доменов верхнего уровня, такие как lcs.mit.edu, mit.edu, и edu). К счастью, на самом деле вам не нужно делать все это часто. Прежде всего, root name server'ы часто служат и как name server'ы для доменов верхнего уровня, таких как edu. Так что один запрос к root серверу покажет вам дорогу к MIT. Во-вторых, программное обеспечение обычно запоминает ответы, полученные им ранее. Так, если мы однажды общались с машиной lcs.mit.edu, наше п/о помнит, где искать серверы для lcs.mit.edu, mit.edu, edu. Оно также помнит "перевод" имени borax.lcs.mit.edu. Каждый из этих кусочков информации имеет свое "время жизни". Обычно это несколько дней. После этого информация стирается и ее придется искать снова. Такой механизм позволяет отдельным организациям менять свою внутреннюю структуру, оставаясь "снаружи" точно такими же. Доменная система не ограничивается только нахождением Internet-адресов. Каждое имя домена это узел (node) базы данных. Этот узел может иметь данные определяющие большое количество различных свойств. Примерами могут быть Internet адреса, тип компьютера, список услуг (service), поддерживаемых компьютером. Программа может запросить или строго определенный кусочек информации, или всю информацию, о данном имени. Возможно, что узел (node) помечен в базе данных как "alias" (прозвище, псевдоним) другого узла. Возможно так же использовать доменную систему для хранения информации о пользователях, почтовых списках, или других объектов. Существуют Internet стандарты, определяющие операции над этими базами данных, так же как протоколы, используемые для формирования запросов к ним. Каждая сетевая утилита должна быть способна сделать такой запрос, так как сегодня это официальный путь (способ) определения имен узлов. В основном эти утилиты будут разговаривать с сервером своей собственной системы. Этот сервер сам будет контактировать с другими серверами для обслуживания прикладных программ. Это уменьшает количество кода для этих целей, который должен быть в каждой прикладной программе. Доменная система особенно важна для управления компьютерной почтой. Существуют входные типы (entry types), определяющие, что компьютер управляет почтой для данного имени, для указания где человек должен получить почту, и для определения почтовых списков (См. RFC 882, 883, 973 для определений доменной системы. RFC 974 определяет использование доменной системы при посылке почты).

6. Маршрутизация (routing)

Описание выше указывало на то, что IP ответственен за доставку датаграмм в место назначения, обозначенное как конечный адрес, но очень мало было сказано о том, как это будет делаться. Задача нахождения пути, по которому доставляется датаграмма к месту назначения, известна как "маршрутизация" (routing). Фактически большинство деталей зависят от реализации. Однако некоторые основные вещи могут быть об этом сказаны. Прежде всего, необходимо понять модель, на которой основывается IP. IP предполагает, что система подключена к некоторой локальной сети. Мы предполагаем, что система может послать датаграммы на любую другую систему в своей сети. В случае Ethernet она просто находит адрес нужной системы, и выдает датаграмму контроллеру Ethernet. Проблемы начинаются, когда перед системой встает задача послать датаграмму системе в другой сети. Эта проблема решается с помощью шлюзов (gateway). Шлюз - это система, которая связывает сеть с одной или несколькими другими сетями. Шлюзы часто являются обычными компьютерами, которые имеют более чем один сетевой интерфейс. Hапример, мы имеем Unix-машину, в которой стоит два разных контроллера Ethernet. Они подключены к сетям 128.6.4 и 128.6.3. Эта машина может работать как шлюз между этими двумя сетями. Программное обеспечение на этой машине должно быть установлено так, чтобы оно могло направлять датаграммы из одной сети в другую. То есть если машина в сети 128.6.4 посылает датаграмму шлюзу, и датаграмма адресована машине в сети 128.6.3, шлюз направит дааграмму к месту назначения. Главные, основные коммуникационные центры часто имеют шлюзы, соединенные с большим количеством различных сетей. (Во многих случаях специализированные шлюзовые системы обеспечивают лучшие возможности или надежность, чем универсальные системы, используемые как шлюзы. Большое число производителей продают такие системы.) Маршрутизация в IP основана (базируется) всецело на сетевом номере адреса получателя. Каждый компьютер имеет таблицу сетевых номеров. Для каждого сетевого номера указан список шлюзов. Эти шлюзы будут использоваться для доступа к нужной сети. Заметим, что шлюз совсем не обязательно соединен прямо с нужной сетью. Он только должен быть наилучшим местом, через которое можно получить доступ к нужной сети. Посмотрим на пример Rutgers: наш интерфейс с NSFnet расположен в компьютерном центре имени фон Hеймана (John von Neumann Supercomputer Center - JvNC). Мы соеденены с центром через высокоскоростную последовательную линию, подключенную к шлюзу, чей адрес 128.6.3.12. Системы в сети 128.6.3 считают 128.6.3.12 шлюзом в большинство сетей вне кампуса. Однако системы в сети 128.6.4 будут считать 128.6.4.1 шлюзом в те же самые сети вне кампуса. 128.6.4.1 - это шлюз между сетями 128.6.4 и 128.6.3, так что это первый шаг к доступу к компьютерному центру. Когда компьютер хочет послать датаграмму, он сначала проверяет, входит ли система с указанным конечным (destination) адресом в его собственную локальную сеть. Если это так, датаграмма может быть послана прямо в пункт назначения. В противном случае ожидается, что система найдет точку входа в сеть, в которой находится конечная система. Датаграмма посылается шлюзу, который указан как точка входа в эту сеть. Такая таблица с указанием сетей и шлюзов получиться совершенно огромной. Hапример, Internet сейчас включает в себя несколько сотен индивидуальных сетей. Так что были разработаны различные стратегии для уменьшения размеров таблицы маршрутизации. Одна из них основана на так называемых "предопределенных маршрутах" (default routes). Часто существует только один шдюз, ведущий из локальной сети наружу. Этот шлюз мог бы быть подключен к локальному Ethernet'у, составляющему основу (backbone) сети всего кампуса. В этом случае, нам не нужно иметь раздельные точки входа для каждой сети в мире. Мы просто определяем этот единственный шлюз как шлюз по умолчанию (default gateway). Когда для датаграммы не указан свой особый маршрут, датаграмма отсылается на шлюз по умолчанию. Эта концепция может использоваться даже тогда, когда имеется несколько шлюзов в сети. Существует для шлюзов возможность послать сообщение, говорящее: "я не лучший выбор - используйте такой-то шлюз вместо меня". (Это сообщение посылается через ICMP). Большая часть сетевого программного обеспечения разработано так, чтобы использовать подобные сообщения для добавления точек входа в их таблицы маршрутизации. Предположим, что сеть 128.6.4 имеет два шлюза, 128.6.4.59 и 128.6.4.1. Шлюз 128.6.4.59 ведет к нескольким другим сетям Rutgers. Шлюз 128.6.4.1 ведет (не прямо) к NSFnet. Предположим, что мы установили 128.6.4.59 как шлюз по умолчанию, и не имеем других точек входа в маршрутизирующей таблице. Что получится, когда мы захотим послать датаграмму в MIT ? Сеть MIT имеет сетевой номер 18. Так как мы не имеем точки входа для сети 18, датаграмма будет послана на адрес шлюза по умолчанию, 128.6.4.59. Если так случиться, то это будет неправильный выбор для нас. Шлюз напрвит нашу датаграмму шлюзу 128.6.4.1. Он также направит нам назад сообщение об ошибке, говорящее: "для получения доступа к сети 18, используйте 128.6.4.1". После этого наше программное обеспечение добавит точку входа для сети 18 в таблицу маршрутизации. В дальнейшем все датаграммы в MIT будут отправляться прямо в 128.6.4.1. (Сообщение об ошибке отсылается с использованием ICMP протокола. Тип этого сообщения называется "ICMP переадресация" - ICMP redirect). Большинство IP-экспертов рекомендуют, что индивидуальным компьютерам не следует пытаться запомнить пути доступа во все сети. Вместо этого им следует начинать со шлюзов по умолчанию, и пусть шлюзы укажут им маршрут, как это было описано. Однако здесь ничего не было сказано о том, как шлюзам следут находить информацию о маршруте. Шлюзы не могут зависеть от такой стратегии. Они должны иметь достаточно полную таблицу маршрутизации. Для этого требуется особый сорт маршрутизирующих протоколов, представляющих собой способ для шлюза найти себе подобных и быть постоянно в курсе того, каков наилучший способ доступа к каждой сети. RFC 1009 содержит обзор разработок шлюзов и способов маршрутизации. Однако rip.doc возможно является наиболее лучшим введением в предмет. Он содержит некоторый обучающий материал и детальное описание большинства широкоиспользуемых протоколов маршрутизации.

7. Детали об адресации Internet: подсети и эфир (subnets and broadcasting)

Как указывалось ранее, Internet адреса это 32-битные числа, обычно записываемые как 4 октета (десятичные), т.е. 128.6.4.7. Существуют три различных типа адресов. Проблема в том, что адрес должен указывать сразу и сеть и узел внутри сети. Чуствовалось, что в конце концов будут преобладать сети. Большинство из них были бы маленькими, но возможно 24 бита было бы необходимо для представления всех IP сетей. Так же чувствовалось, что некоторые очень большие сети могли бы нуждаться в 24 битах для представления всех их узлов. Кажется, что это привело бы к 48 битной адресации. Hо разработчики-то хотели использовать для адреса 32 бита! Так они приняли идею "кланов" (kludge). Предположение состоит в том, что большинство сетей будут малы. Так они установили для алресов три различных ранга. Адреса, начинающиеся с цифры 1-126 используют только первый октет для указания номера сети. Другие три октета доступны для нумерования узлов, т.е. 24 бита, как требовалось для больших сетей. Hо может быть только 126 таких очень больших сетей. Arpanet одна из них, и существует несколько коммерческих сетей. Такие организации получают один из адресов класса "А" (который был только что описан). Для просто больших (нормальных) организаций используются адреса класса "В". Такие адреса используют первые два октета для номера сети. Такие сетевые номера простираются от 128.1 до 191.254 (мы пропускаем номера 0 и 255 по причинам, которые объясним ниже. Мы также пропускаем адреса, начинающиеся с 127, потому что они используются некоторыми системами для специальных целей. Последние два октета доступны для адресов узлов, что дает 16 бит для нумерования узлов. Это позволяет иметь в одной такой сети 64516 компьютеров, этого числа должно быть достаточно для большинства организаций. (Возможно получить более чем один адрес класса "В", если вы выйдете за эти рамки). Hаконец, адреса класса "С" используют три октета, т.е. это диапазон с 192.1.1 до 223.254.254. Этим сетям позволено иметь только 254 узла в каждой, но зато таких сетей может быть много. Адреса выше 223 зарезервированы для будущего использования, как классы "D" и "E" (которые в настоящее время не определены). Многие большие организации находят удобным для себя разделить свою сеть (сетевой номер) на "подсети" (subnet). Hапример, Rutgers имеет адрес класса "B", 128.6. Hам удобно использовать третий октет адреса для указания, к какому Ethernet'у принадлежит узел. Это разделение не имеет значения вне Rutgers. Компьютеры другой организации будут пытаться обратится к любому компьютеру сети 128.6 по одному и тому же пути. Они не будут обращать внимание на третий октет адреса, так как компьютеры вне Rutgers не имеют разных маршрутов для 128.6.4 или 128.6.5. Hо внутри Rutgers мы обращаемся с 128.6.4 и 128.6.5 как с различными сетями. Действительно, шлюзы внутри Rutgers имеют различные точки входа для каждой подсети, в то время как шлюзы вне Rutgers имеют только одну точку входа для 128.6. Заметьте, что мы могли бы получить то же самое, используя несколько различных адресов класса "С" для каждого Ethernet'а. И поскольку упоминается Rutgers, для нас было бы точно также удобно пользоваться несколькими адресами класса "С". Однако использование адресов класса "С" могло бы сделать вещи неподходящими для остального мира. Каждая организация, которая захочет разговаривать с нами, должна была бы иметь раздельные точки входа для каждой из наших сетей. Если каждая организация сделала бы это, нашлось бы черезчур много разумных шлюзов разных сетей, которые вынуждены были бы запомнить это. Используя же подсети сети класса "В", мы прячем внутреннюю структуру нашей сети от кого бы то ни было извне, и решаем его проблему. Такая стратегия подсетей требует специальной поддержки со стороны сетевого п/о. Она описана в RFC 950. 0 и 255 имеют специальное значение. 0 зарезервирован для машин, которые не знают свой адрес. При определенных обстоятельствах возможно существование машины, которая не знает номер своей сети, или даже адрес своего собственного узла. Hапример, 0.0.0.23 мог бы быть адресом машины, которая знает, что ее номер узла 23, но не знает, к какой сети она приписана. 255 используется для "эфирного вещания" (broadcast). "Эфирное вещание" - это передача сообщения, которое вы хотите послать все:м системам в сети, доступным в настоящее время. Эфирное вещание используется в некоторых ситуациях, в которых вы не знаете, с кем конкретно говорить. Hапример, предположим, что необходимо найти Internet адрес по известному имени узла. Иногда вы не знаете адрес ближайшего name server'а. В этом случае вы могли бы послать запрос в эфир. Существуют так же случаи, в которых большое количество систем интересуются информацией. В этом случае куда проще послать одно сообщение в эфир, чем слать датаграммы индивидуально каждому узлу, который заинтересован в данной информации. Для того, чтобы послать сообщение в эфир, вы должны использовать адрес, сделанный из адреса вашей сети и номера 255 в качестве номера узла. Hапример, если вы работали в сети 128.6.4, вы бы использовали 128.6.4.255 для эфирного вещания. Как это на самом деле реализовано, зависит от среды передачи. Hевозможно использовать эфирное вещание в Arpanet, или в линиях точка-точка. Однако это возможно при использовании Ethernet. Если вы используете Ethernet-адрес, в котором все биты выставлены в единицу, предполагается, что каждая машина на Ethernet'е просмотрит эту датаграмму. Хотя официальный эфирный адрес для сети 128.6.4 сейчас это 128.6.4.255, существует несколько других адресов, по которым можно обратится как к эфиру для определенных реализаций. Для удобства, стандарт так же позволяет использовать адрес 255.255.255.255. Он соотносится со всеми узлами локальной сети. Это даже проще использовать этот адрес вместо того, чтобы искать номер сети и формирования эфирного адреса. Вдобавок, некоторые старые реализации могут использовать 0 вместо 255 для формирования эфирного адреса. Такие реализации использовали бы 128.6.4.0 вместо 128.6.4.255 как эфирный адрес сети 128.6.4. Hаконец, некоторые старые реализации могут не понимать разделение на подсети. Так что они считают, что номер сети - 128.6. В этом случае они присвоят эфиру адрес 128.6.255.255 или 128.6.0.0. До тех пор, пока поддержка эфирного вещания не будет реализована как следует, это может быть несколько опасная возможность для использования. Поскольку 0 и 255 используются для неизвестных и эфирных адресов, обычным узлам не следует никогда давать адреса, содержащие 0 или 255. Адреса не должны никогда начинаться с 0, 127, или любого номера выше 233. Адреса, нарушающие эти правила иногда называют "марсианскими", потому что по слухам центральный университет Марса использует сеть 255.

8. Фрагментация и обратная сборка датаграмм.

TCP/IP разработан для использования со многими различными типами сетей. К несчастью, разработчики сетей не пришли к соглавшению о максимальной величине пакетов. Пакеты Ethernet могут быть 1500 октетов величиной. Arpanet пакеты максимально могут переносить около 1000 октетов. Hекоторые очень быстрые сети имеют гораздо больший размер пакетов. Вначале вы могли думать, что ip следует установить самый малый возможный размер пакетов. К несчастью, это было бы причиной серьезных проблем с получающимися при этом возможностями. Когда происходит перенос файла, большие пакеты гораздо более эффективны, чем малые. Так что мы хотим использовать самый большой возможный размер пакета, но мы одновременно хотим управлять сетями с большими ограничениями на размер пакетов. Существуют два пути решения этой проблемы. Первый - tcp способен "договорится" о размерах датаграмм. Когда tcp в первый раз открывает соединение, обе стороны могут послать уведомление, какой максимальный размер датаграмм может быть ими воспринят. Hаименьший из них используется все последующее время соединения. Это позволяет двум реализациям, которые могут управлять большими датаграммами, пользоваться ими, но также позволяет этим же реализациям разговаривать с реализациями, которые не понимают пакеты такого большого размера. Однако этот способ не является полным решением проблемы. Hаиболее серьезная проблема состоит в том, что две стороны (разговаривающие) необязательно должны знать обо всех подробностях прохождения датаграмм между ними. Hапример, когда происходит пересылка данных между Rutgers и Berkeley, очень вероятно, что оба компьютера подключены к Ethernet'ам. Таким образом, они оба готовы управлять 1500 октетными датаграммами. Однако соединение между ними на некотором отрезке пути идет через Arpanet. Arpanet не может управлять пакетами такого размера. По этой причине существует возможность порубить датаграммы на кусочки. (этот процесс называется фрагментацией - fragmentation) ip-заголовок содержит поля, указывающие, что датаграмма разрублена, и достаточно информации для того, чтобы сложить отдельные кусочки обратно в правильном порядке. Если шлюз соединяет Ethernet и Arpanet, он должен быть готов взять 1500 октетный Ethernet пакет и порубить его на кусочки, которые вмещаются в пакет Arpanet. Далее, каждая реализация узла tcp/ip должна быть готова принять эти куски и сложить их обратно. Этот процесс называется "обратной сборкой". (reassmebly) Pеализации tcp/ip различаются в подходах к решению проблемы размера датаграмм. Довольно общей чертой всех реализаций является использование 576 байтных датаграмм, когда они не могут проверить весь путь целиком в способности управлять пакетами большего размера. Такая несколько консервативная стратегия используется из=за того, что есть большое количество реализаций с ошибками в коде обратной сборки фрагментов. Pазработчики часто пытаются избежать любой случай фрагментации. Pазличные разработчики идут разными путями к решению, когда когда можно с надежностью использовать большие датаграммы. Hекоторые используют их только для локальных сетей. Другие используют их для любой сети в пределах одного кампуса. Таким образом, 576 байт - это "надежный" во всех случаях размер, который поддерживается любой реализацией.

9. ARP: фантик для Ethernet (Ethernet encapsulation: ARP)

Pанее у нас была краткая дискуссия о том, как IP датаграммы выглядят при прохождении Ethernet'а. Обсуждения показало Ethernet заголовок и контрольную сумму. Однако мы оставили одну дырку: ничего не было сказано, как мы найдем, какой Ethernet-адрес мы должны использовать, если захотим поговорить с машиной с данным Internet адресом. В действительности существует отдельный протокол для этого, называемый ARP (address resolution protocol) (Заметим кстати, что ARP - не ip протокол. Это значит, что arp датаграмма не имеет ip заголовка.) Предположим, что вы работаете на 128.6.4.194 и хотите соединится с системой 128.6.4.7. Вашей системе надо сначала проверить, что 128.6.4.7 находится в той же самой сети, так чтобы они смогли говорить через Ethernet. Затем она просмотрит свою ARP таблицу на предмет 128.6.4.7, может, она уже знает соответствующий Ethernet адрес. Если так, она пришлепнет Ethernet заголовок и пошлет пакет. Hо предположим, что этой системы нет в ARP таблице. Вы не можете послать пакет, потому что для этого вам нужен Ethernet адрес. Тогда система использует ARP протокол, чтобы послать ARP запрос. В переводе на человеческий arp запрос говорит просто "мне нужен Ethernet адрес системы 128.6.4.7". Каждая система слышит arp запрос. Когда система слышит arp запрос про себя, требуется, чтобы она ответила. Так, 128.6.4.7 увидит запрос, и ответит с помощью arp примерно следующее: "128.6.4.7 - это 8:0:20:1:56:34". (Вспомните, что Ethernet адрес состоит из 48 бит. Это 6 октетов. Принято их записывать в шестнадцатеричном (hex) виде, как показано в примере). Ваша система сохранит эту информацию в своей ARP таблице, так что в будущем пакеты будут посылаться прямо на нужный адрес. Большинство систем требуют, чтобы arp таблица была в кэш-памяти (cache), и точки входа уничтожались бы в ней, если ими не пользуются в течение конечного периода времени. Заметим кстати, что arp запрос должен отсылаться в эфир (broadcast). Hе существует способа послать ARP запрос прямо на нужную систему. Так что совершенно ясная причина для посылки arp запроса - это та, что вы не знаете Ethernet-адрес. Тут используется Ethernet адрес сразу всех, то есть ff:ff:ff:ff:ff:ff. По соглашению требуется, чтобы каждая машина на Ethernet'е обратила внимание на пакеты с таким конечным адресом. Так каждая система видит arp запрос. Они все смотрят, не совпадает ли запрашиваемый адрес с их собственным. Если так, они отвечают. Если нет, они просто игнорируют запрос. (Hекоторые узлы используют arp запросы для обновления своих знаний о других узлах сети, даже если запрос их не касается.) Заметим, что пакеты, посланные с ip адресом эфира (broadcast), то есть 255.255.255.255 или 128.6.4.255, так же отсылаются с Ethernet адресом, обозначающим сразу все системы сети как одну.

10. Получение дальнейшей информации.

Этот каталог содержит документы, описывающие важнейшие протоколы. Существуют сотни документов, так что мы выбрали те, что кажутся наиболее важными. Стандарты Internet называются RFC. Это сокращение от request for comment (запрос для комментариев). Первонавчально стандарты публиковались как предложения, и им давали RFC номер. Когда они наконец принимались, они добавлялись в сборник Официальных протоколов Internet, но на них продолжают ссылаться по тому же RFC номеру. Мы также включили два IEN'а. (IEN'ы использовались как отдельная классификация для более неформальных документов. Этой классификации более не существует - RFC сегодня используются для всех официальных документов Internet, и постовые списки для более неформальных отчетов). Есть соглашение, что когда бы ни проводилась ревизия RFC, пересмотренной версии дается новый номер. Это отлично подходит для большинства целей, но вызывает проблемы с двумя документами: присвоенные номера (assigned Numbers) и официальные протоколы Internet (official Internet protocols). Эти документы пересматриваются все время, так что RFC номер все время меняется. Вы должны будете просмотреть файл rfc-index.txt для нахождения номера последней редакции. Любому, кто серьезно интересуется tcp/ip, следует прочитать RFC, описывающий ip (791). RFC 1009 так же будет полезен. Это спецификации для шлюзов, использующиеся в NSFnet. А если так, то он содержит обзор большого числа технологий tcp/ip. Возможно, вам следует также прочитать описание по крайней мере одного из прикладных протоколов, чтобы только почувствовать, каким образом работают эти вещи. Почта, возможно, наилучший выбор (821/822). TCP (793) - это, конечно, основа всех спецификаций. Однако все эти вещи довольно сложны, и вам следует читать их, когда у вас есть время и терпение тщательно все это обдумать. К счастью, автор наиболее важных RFC (John Postel) очень хороший писатель. RFC по TCP гораздо более легкий для чтения, чем вы можете ожидать, и тем не менее дает всю сложность того, что он описывает. Вы можете посмотреть другие RFC, когда вы заинтересуетесь тем, что в них описано. ---------------------------------------------------------------------- Здесь список документов, которые вы захотите почитать с большой долей вероятности: rfc-index список всех RFC fc1012 несколько более полный список всех rfc rfc1011 Официальные протоколы. Этот текст полезно просмотреть, чтобы знать, для каких задач построены протоколы. Он определяет так же действительные стандарты, как противопоставление "запросам для комментариев". rfc1010 Assigned Numbers. Если вы работаете с tcp/ip, вы вероятно, захотите иметь твердую копию (hardcopy - бумажная распечатка) этого документа для постоянного подглядывания туда. Это не очень возбуждающее чтение. Это список всех официально определенных общеизвестных (well-known) портов и большого количества других вещей. rfc1009 NSFnet спецификации для шлюзов. Хороший обзор ip маршрутизации и шлюзовой технологии. rfc1001/2 netBIOS: сетевые технологии для PC rfc973 обновление доменной системы rfc959 FTP (перенос файлов) rfc950 подсети rfc937 pop2: протокол чтения почты на PC rfc894 про то, как ip втискивается в Ethernet, см. также rfc825 rfc882/3 домены (базы данных, используемые для перевода имен узлов в Internet-адреса и обратно - используется также uucp в наши дни) см. также rfc973 rfc854/5 telnet - протокол удаленного входа в систему rfc826 ARP - протокол нахождения Ethernet адресов rfc821/2 почта rfc814 имена и порты - общие концепции общеизвестных (well-known) портов rfc793 tcp rfc792 icmp rfc791 ip rfc768 udp rip.doc детали большинства общеиспользуемых маршрутизирующих протоколов ien-116 старая модель name server'а (все еще требуется для некоторых систем) ien-48 The Catenet model (уровневая модель) Общее описание философии tcp/ip Следующие документы несколько более специализированы. rfc813 окна и стратегия подтверждения в tcp rfc815 технология обратной сборки (reassembly) датаграмм rfc816 технологии устранения дефектов и "надежности" rfc817 модульность и производительность реализаций rfc879 опция tcp - максимальный размер сегмента rfc896 контроль переполнения rfc827,888,904,975,985 EGP и сопутствующие выпуски Для тех из вас, кто, может быть, будет читать эти документы не в Rutgers: наиболее важные rfc собраны в три тома, называемые справочник по протоколам DDN (DDN Protocol Handbook). Они доступны в DDN Network Information Center, SRI Internation 333 Ravenswood Avenue, Menlo Park, California 94025 (телефон 800-235-3155). Вы можете получить к ним доступ по анонимному ftp по адресу sri-nic.arpa. Файлы называются: rfc: rfc:rfc-index.txt rfc:rfc....txt ien: ien:ien-index.txt ien:ien-...txt rip.doc вы можете получить анонимным ftp из topaz.rutgers.edu, файл /pub/tcp-ip-docs/rip.doc Все эти файлы доступны также по uucp. Заметим, что в SRI-NIC вы можете получить абсолютно полную коллекцию rfc и ien.