Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

22.01.2017

Google
WWW CITForum.ru
С Новым годом!

Работа Internet: организация, структура, методы



Введение

Чтобы успешно освоить нечто и затем с ним работать, очень полезно знать, хотя бы в общих чертах, устройство и функционирование этого объекта. Знание это помогает осмысленно воспринимать и систематизировать навыки работы, а не пользоваться предлагаемыми рекомендациями чисто механически. Такое осознание подскажет, что можно ожидать от системы в смысле ее возможностей, поведения, недостатков, и что более важно, поможет ориентироваться в необычной ситуации: в случае поломки, смены сервера, программного обеспечения, появления новых возможностей и т.п.

В этом разделе мы рассмотрим сети с коммутацией пакетов и преимущества построения сети на принципах TCP/IP протоколов. Здесь будут рассмотрены основные принципы управления коммуникациями в : TCP и его бедный родственник UDP. Это основные системообразующие элементы сети. Важным элементом является также региональная система имен (DNS). Более подробно читайте в [7].

Структура функционирования сети

  Современные сети построены по многоуровневому принципу. Чтобы организовать связь двух компьютеров, требуется сначала создать свод правил их взаимодействия, определить язык их общения, т.е. определить, что означают посылаемые ими сигналы и т.д. Эти правила и определения называются протоколом. Для работы сетей необходимо запастись множеством различных протоколов: например, управляющих физической связью, установлением связи по сети, доступом к различным ресурсам и т.д. Многоуровневая структура спроектирована с целью упростить и упорядочить это великое множество протоколов и отношений. Продемонстрируем принципы этой структуры на диаграмме. На рисунке gif показана общепринятая семиуровневая структура согласно ISO. Эта модель известна как ``эталонная модель ISO OSI''. Она позволяет составлять сетевые системы из продуктов -- модулей программного обеспечения - выпущенных разными производителями.

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

Под реальным взаимодействием мы подразумеваем непосредственное взаимодействие, непосредственную передачу информации, например, пересылку данных в оперативной памяти из области, отведенной одной программе, в область другой программы. При непосредственной передаче данные остаются неизменными все время. Под виртуальным взаимодействием мы понимаем опосредованное взаимодействие и передачу данных; здесь данные в процессе передачи могут уже определенным, заранее оговоренным образом видоизменяться.

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

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

Аналогичные связи и процессы имеют место и в эталонной модели ISO OSI. Физическая связь реально имеет место только на самом нижнем уровне (аналог почтовых поездов, самолетов, автомобилей). Горизонтальные связи между всеми остальными уровнями являются виртуальными, реально они осуществляются передачей информации сначала вниз, последовательно до самого нижнего уровня, где происходит реальная передача, а потом, на другом конце, обратная передача вверх последовательно до соответствующего уровня. На рисунке gif показан путь информации на уровне 6.

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

  

=====================================================================            
        Комьпьютер А                               Компьютер В

  +----------------+    Application  protocol    +----------------+ 
  |   Application  | _  _  _  _  _  _  _  _  _   |   Application  |
  |     layer      |                             |     layer      |
  +----------------+   Уровень 7 -прикладной     +----------------+
          |                                              |
          |                                              |
  +----------------+   Presentation  protocol    +----------------+ 
  |  Presentation  | _  _  _  _  _  _  _  _  _   |  Presentation  |
  |   . layer      |                             |     layer .    |
  +---.------------+   Уровень 6 -представления  +-----------.----+
      .   |                        данных                |   .
      .   |                                              |   .
      .   |                                              |   .
  +---.------------+     Session  protocol       +-----------.----+
  |  Presentation  | _  _  _  _  _  _  _  _  _   |  Presentation  |
  |   . layer      |                             |     layer .    |
  +---.------------+   Уровень 5 -сеансовый      +-----------.----+  
      .   |                                              |   .
      .   |                                              |   .
  +---.------------+   Transport  protocol       +-----------.----+
  |  Transport     | _  _  _  _  _  _  _  _  _   |   Transport    |
  |   . layer      |                             |     layer .    |
  +---.------------+   Уровень 4 -транспортный   +-----------.----+
      .   |                                              |   .
      .   |                                              |   .
  +---.------------+   Network    protocol       +-----------.----+
  |  Network       | _  _  _  _  _  _  _  _  _   |   Network .    |
  |   . layer      |                             |     layer .    |
  +---.------------+   Уровень 3 -сетевой        +-----------.----+
      .   |                                              |   .
      .   |                                              |   .
  +---.------------+   Data link  protocol       +-----------.----+
  | Data Link      | _  _  _  _  _  _  _  _  _   |  Data Link     |
  |   . layer      |                             |     layer .    |
  +---.------------+   Уровень 2 -канальный      +-----------.----+
      .   |                                              |   .
      .   |                                              |   .
  +---.------------+   Physical   protocol       +-----------.----+
  |  Physical      | _  _  _  _  _  _  _  _  _   | Physical  .    |
  |   . layer      |                             |     layer .    |
  +---.------------+   Уровень 1 -физический     +-----------.----+
      .   |                                              |   . 
      .   |           **********************             |   .
      .   |           *   Physical media   *             |   .
      .   |           * -физическая среда  *             |   .
      . . |. . . . . .* . . . . . . . . . .* . . . . . . | . .
          |___________*____________________*_____________|
                      **********************


       _ _ _ _ _ Виртуальные соединения
       . . . . . Путь данных, соответствующий связи на уровне 6
       _________ Физическое реальное соединение
       |         
       |         Интерфейс (иерархическое взаимодействие уровней)

=====================================================================  


Рисунок: Эталонная модель ISO OSI

Дадим краткий обзор уровней.  

Уровень 0
связан с физической средой - передатчиком сигнала и на самом деле не включается в эту схему, но весьма полезен для понимания. Этот почетный уровень представляет посредников, соединяющих конечные устройства: кабели, радиолинии и т.д. Кабелей существует великое множество различных видов и типов: экранированные и неэкранированные витые пары, коаксиальные, на основе оптических волокон и т.д. Т.к. этот уровень не включен в схему, он ничего и не описывает, только указывает на среду.
Уровень 1
- физический. Включает физические аспекты передачи двоичной информации по линии связи. Детально описывает, например, напряжения, частоты, природу передающей среды. Этому уровню вменяется в обязанность поддержание связи и прием-передача битового потока. Безошибочность желательна, но не требуется.
Уровень 2 - канальный. Связь данных.   Обеспечивает безошибочную передачу блоков данных (называемых кадрами (frame)) через уровень 1, который при передаче может искажать данные. Этот уровень должен определять начало и конец кадра в битовом потоке, формировать из данных, передаваемых физическим уровнем, кадры или последовательности , включать процедуру проверки наличия ошибок и их исправления. Этот уровень (и только он) оперирует такими элементами, как битовые последовательности, методы кодирования, маркеры. Он несет ответственность за правильную передачу данных (пакетов) на участках между непосредственно связанными элементами сети. Обеспечивает управление доступом к среде передачи. В виду его сложности, канальный уровень подразделяется на два подуровня: MAC (Medium Access Control) - Управление доступом к среде и LLC (Logical Link Control) - Управление логической связью (каналом). Уровень MAC управляет доступом к сети (с передачей маркера в сетях Token Ring или распознаванием конфликтов (столкновений передач) в сетях Ethernet) и управлением сетью. Уровень LLC, действующий над уровнем MAC, и есть собственно тот уровень, который посылает и получает сообщения с данными.
Уровень 3
- сетевой.   Этот уровень пользуется возможностями, предоставляемыми ему уровнем 2, для обеспечения связи двух любых точек в сети. Любых, необязательно смежных. Этот уровень осуществляет проводку сообщений по сети, которая может иметь много линий связи, или по множеству совместно работающих сетей, что требует маршрутизации, т.е. определения пути, по которому следует пересылать данные. Маршрутизация производится на этом же уровне. Выполняет обработку адресов, а также и демультиплексирование.

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

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

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

Уровень 4
- транспортный. Регламентирует пересылку пакетов сообщений между процессами, выполняемыми на компьютерах сети. Завершает организацию передачи данных: контролирует на сквозной основе поток данных, проходящий по маршруту, определенному третьим уровнем: правильность передачи блоков данных, правильность доставки в нужный пункт назначения, их комплектность, сохранность, порядок следования. Собирает информацию из блоков в ее прежний вид. Или же оперирует с дейтаграммами, т.е. ожидает отклика-подтверждения приема из пункта назначения, проверяет правильность доставки и адресации, повторяет посылку дейтаграммы, если не пришел отклик. В рамках транспортного протокола предусмотрено пять классов качества транспортировки и соответствующие процедуры управления. Этот же уровень должен включать развитую и надежную схему адресации для обеспечения связи через множество сетей и шлюзов. Другими словами, задачей данного уровня является довести до ума передачу информации из любой точки в любую во всей сети.

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

Уровень 5
- сеансовый. Координирует взаимодействие связывающихся пользователей: устанавливает их связь, оперирует с ней, восстанавливает аварийно оконченные сеансы. Этот же уровень ответственен за картографию сети - он преобразовывает региональные (доменные) компьютерные имена в числовые адреса , и наоборот. Он координирует не компьютеры и устройства, а процессы в сети, поддерживает их взаимодействие - управляет сеансами связи между процессами прикладного уровня.
Уровень 6
- уровень представления данных. Этот уровень имеет дело с синтаксисом и семантикой передаваемой информации, т.е. здесь устанавливается взаимопонимание двух сообщающихся компьютеров относительно того, как они представляют и понимают по получении передаваемую информацию. Здесь решаются, например, такие задачи, как перекодировка текстовой информации и изображений, сжатие и распаковка, поддержка сетевых файловых систем (NFS), абстрактных структур данных и т.д.
Уровень 7
- прикладной. Обеспечивает интерфейс между пользователем и сетью, делает доступными для человека всевозможные услуги. На этом уровне реализуется, по крайней мере, пять прикладных служб: передача файлов, удаленный терминальный доступ, электронная передача сообщений, служба справочника и управление сетью. В конкретной реализации определяется пользователем (программистом) согласно его насущным нуждам и возможностям его кошелька, интеллекта и фантазии. Имеет дело, например, с множеством различных протоколов терминального типа, которых существует более ста.



    Замечание.
    Следует понимать, что подавляющее большинство современных сетей в силу исторических причин лишь в общих чертах, приближенно, соответствуют эталонной модели ISO OSI.
    Рассмотрим некоторые из указанных уровней в их проекции на Internetподробнее. Не забывайте, что проекция искажена в силу несоответствия технологии internet стандарту эталонной модели - перемешаны некоторые уровни и функции уровней

Уровни работы сети

Пересылка битов

Пересылка битов происходит на физическом уровне схемы ISO OSI. Увы, здесь всякая попытка краткого и доступного описания обречена на провал. Требуется введение огромного количества специальных терминов, понятий, описаний процессов на физическом уровне и т.д. И потом, существует столь великое разнообразие приемо-передатчиков и передающих сред, - трудно даже и обозреть этот океан технологий. Для понимания работы сетей этого и не требуется. Считайте, что просто имеется труба, по которой из конца в конец перекачиваются биты. Именно биты, безо всякого деления на какие-либо группы (байты, декады и т.п.).

Пересылка данных

Об организации блочной, символьной передачи, обеспечении надежности пересылки поговорим на других уровнях модели ISO OSI. Т.е. функции канального уровня в Internet распределены по другим уровням, но не выше транспортного. В этом смысле Internet не совсем соответствует стандарту ISO. Здесь канальный уровень занимается только разбиением битового потока на символы и кадры и передачей полученных данных на следующий уровень. Обеспечением надежности передачи он себя не утруждает.

Сети коммутации пакетов

Настала пора поговорить об Internet именно как о сети, а не паутине линий связи и множестве приемо-передатчиков. Казалось бы, Internet вполне аналогична телефонной сети, и модель телефонной сети достаточно адекватно отражает ее структуру и работу. В самом деле, обе они электронные, обе позволяют вам устанавливать связь и передавать информацию. И Internet тоже состоит, в первую очередь, из выделенных телефонных линий. Но увы! Картина эта неверна и приводит ко многим заблуждениям относительно работы Internet, ко множеству недоразумений. Телефонная сеть - это так называемая сеть с коммутацией линий, т.е. когда вы делаете вызов, устанавливается связь и на все время сеанса связи имеется физическое соединение с абонентом. При этом вам выделяется часть сети, которая для других уже не доступна, даже если вы молча дышите в трубку, а другие абоненты хотели бы поговорить по действительно неотложному делу. Это приводит к нерациональному использованию очень дорогих ресурсов - линий сети. Internet же является сетью с коммутацией пакетов, что принципиально отличается от сети с коммутацией каналов.

Для Internet более подходит модель, которая поначалу может не внушать доверия: почта, обыкновенная государственная почтовая служба. Почта является сетью пакетной связи. Нет никакой выделенной вам части этой сети. Ваше послание перемешивается с посланиями других пользователей, кидается в контейнер, пересылается в другое почтовое отделение, где снова сортируется. Хотя технологии сильно разнятся, почта является прекрасным и наглядным примером сети с коммутацией пакетов. Модель почты удивительно точно отражает суть работы и структуры Internet. Ею мы и будем пользоваться далее.

Протокол Internet (IP)

По проводу можно переслать биты только из одного его конца в другой. Internet же умудряется аккуратно передавать данные в различные точки, разбросанные по всему миру. Как она это делает? Забота об этом возложена на сетевой (межсетевой) уровень в эталонной модели ISO OSI. О нем и поговорим.

Различные части Internet - составляющие сети - соединяются между собой посредством компьютеров, которые называются ``узлы''; так Сеть связывается воедино. Сети эти могут быть Ethernet, Token Ring, сети на телефонных линиях, пакетные радиосети и т.п. Выделенные линии и локальные сети суть аналоги железных дорог, самолетов почты и почтовых отделений, почтальонов. Посредством их почта движется с места на место. Узлы - аналоги почтовых отделений, где принимается решение, как перемещать данные (``пакеты'') по сети, точно так же, как почтовый узел намечает дальнейший путь почтового конверта. Отделения или узлы не имеют прямых связей со всеми остальными. Если вы отправляете конверт из Долгопрудного (Московская область) в Уфу (Башкирия), конечно же, почта не станет нанимать самолет, который полетит из ближайшего к Долгопрудному аэропорта (Шереметьево) в Уфу, просто местное почтовое отделение отправляет послание на подстанцию в нужном направлении, та в свою очередь, дальше в направлении пункта назначения на следующую подстанцию; таким образом письмо станет последовательно приближаться к пункту назначения, пока не достигнет почтового отделения, в ведении которого находится нужный объект и которое доставит сообщение получателю. Для работы такой системы требуется, чтобы каждая подстанция знала о наличествующих связях и о том, на какую из ближайших подстанций оптимально следует передать адресованный туда-то пакет. Примерно также и в Internet: узлы выясняют, куда следует ваш пакет данных, решают куда его дальше отправить и отправляют.

На каждой почтовой подстанции определяется следующая подстанция, куда будет далее направлена корреспонденция, т.е. намечается дальнейший путь (маршрут) - этот процесс называется маршрутизацией. Для осуществления маршрутизации каждая подстанция имеет таблицу, где адресу пункта назначения (или индексу) соответствует указание почтовой подстанции, куда следует посылать далее этот конверт (бандероль, ). Их сетевые аналоги называются таблицами маршрутизации. Эти таблицы рассылаются почтовым подстанциям централизовано соответствующим почтовым подразделением. Время от времени рассылаются предписания по изменению и дополнению этих таблиц. В Internet, как и любые другие действия, составление и модификация, таблиц маршрутизации (этот процесс тоже является частью маршрутизации и называется так же) определяются соответствующими правилами - протоколами ICMP (Internet Control Message Protocol), RIP (Routing Internet Protocol) и OSPF (Open Shortest Path First). Узлы, занимающиеся маршрутизацией, называются маршрутизаторами.

А откуда сеть знает, куда назначен ваш пакет данных? От вас. Если вы хотите отправить письмо и хотите, чтобы ваше письмо достигло места назначения, вы не можете просто кинуть листочек бумаги в ящик. Вам следует уложить его в стандартный конверт и написать на нем не ``на деревню дедушке'', как Ванька Жуков, а адрес получателя в стандартной форме. Только тогда почта сможет правильно обработать ваше письмо и доставить его по назначению. Аналогично в Internet имеется набор правил по обращению с пакетами - протоколы. Протокол Internet (IP) берет на себя заботы по адресации или по подтверждению того, что узлы понимают, что следует делать с вашими данными по пути их дальнейшего следования. Согласно нашей аналогии, протокол Internet работает также как правила обработки почтового конверта. В начало каждого вашего послания помещается заголовок, несущий информацию об адресате, сети. Чтобы определить, куда и как доставить пакет данных, этой информации достаточно.

Адрес в Internet состоит из 4 байтgif. При записи байты отделяются друг от друга точками: 123.45.67.89 или 3.33.33.3 . (Не пугайтесь, запоминать эти цифры вам не придется !) В действительности адрес состоит из нескольких частей. Так как Internet есть сеть сетей, начало адреса говорит узлам Internet, частью какой из сетей вы являетесь. Правый конец адреса говорит этой сети, какой компьютер или хост должен получить пакет (хотя реально не все так просто, но идея такова). Каждый компьютер в Internet имеет в этой схеме уникальный адрес, аналогично обычному почтовому адресу, а еще точнее - индексу. Обработка пакета согласно адресу также аналогична. Почтовая служба знает, где находится указанное в адресе почтовое отделение, а почтовое отделение подробно знает подопечный район. Internet знает, где искать указанную сеть, а эта сеть знает, где в ней находится конкретный компьютер. Для определения, где в локальной сети находится компьютер с данным числовым IP-адресом, локальные сети используют свои собственные протоколы сетевого уровня. Например, Ethernet для отыскания Ethernet-адреса по IP-адресу компьютера, находящегося в данной сети, использует протокол ARP - протокол разрешения(в смысле различения) адресов. (См. документацию по ARP: RFC 826, 917, 925, 1027)

Числовой адрес компьютера в Internet аналогичен почтовому индексу отделения связи. Первые цифры индекса говорят о регионе (например, 45 - это Башкирия, 141 - подмосковье и т.д.), последние две цифры - номер почтового отделения в городе, области или районе. Промежуточные цифры могут относиться как к региону, так и к отделению, в зависимости от территориального деления и вида населенного пункта. Аналогично существует несколько типов адресов Internet (типы: A, B, C, D, E), которые по-разному делят адрес на поля номера сети и номера узла, от типа такого деления зависит количество возможных различных сетей и машин в таких сетях.

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

Протокол IP является дейтаграммным протоколом, т.е. IP-пакет является дейтаграммой. Это совершенно не укладывается в модель ISO OSI, в рамках которой уже сетевой уровень способен работать по методу виртуальных каналов.

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

  • Б´ольшая часть пересылаемой информации длиннее 1500 символов. Eсли бы почта пересылала только почтовые карточки и отказывалась бы от пересылки чего-либо большего, мы бы, например, лишились увлекательнейшего литературного жанра - эпистолярного. Не говоря уже о том, что практической пользы от такой почты было бы очень немного;
  • Возможны и неудачи. Почта, нередко бывает, письма теряет; сеть тоже, бывает, теряет пакеты или искажает в пути информацию в них. В отличие от почты, Internet может с честью выходить из таких затруднительных положений;
  • Пакеты могут приходить в последовательности, отличной от начальной. Пара писем, отправленных друг за другом на днях, не всегда приходит к получателю в том же порядке; то же верно и для Internet.

Таким образом, следующий уровень Internet должен обеспечить способ пересылки больших массивов информации и позаботиться об ``искажениях'', которые могут возникать по вине сети.

Протокол управления передачей (TCP) и протокол пользовательских дейтаграмм (UDP)

Transmission Control Protocol - это протокол, тесно связанный с IP, который используется в аналогичных целях, но на более высоком уровне - транспортном уровне эталонной модели ISO OSI. Часто эти протоколы, по причине их тесной связи, именуют вместе, как TCP/IP. Термин ``TCP/IP'' обычно означает все, что связано с протоколами TCP и IP. Он охватывает целое семейство протоколов, прикладные программы и даже саму сеть. В состав семейства входят протоколы TCP, UDP, ICMP, telnet, FTP и многие другие. Иерархия протоколов семейства TCP/IP показанаgif на рисунке gif. TCP/IP - это технология межсетевого взаимодействия, технология internet. Сеть, которая использует технологию internet, называется internet.

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

TCP делит информацию, которую надо переслать, на несколько частей. Нумерует каждую часть, чтобы позже восстановить порядок. Чтобы пересылать эту нумерацию вместе с данными, он обкладывает каждый кусочек информации своей обложкой - конвертом, который содержит соответствующую информацию. Это и есть TCP-конверт. Получившийся TCP-пакет помещается в отдельный IP-конверт и получается IP-пакет, с которым сеть уже умеет обращаться.

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

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

  
Рисунок: Иерархия протоколов семейства IP

Для ясности и полноты картины, необходимо сделать здесь важное замечание: Модуль 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, а вам нужно передавать записи, то прикладная программа должна вставлять метки в поток байтов так, чтобы можно было различить записи.

Примечание.

  Дадим краткие разъяснения к рисунку gif заинтересовавшимся. На этом рисунке представлены для примера следующие протоколы из великого семейства IP:

FTP
- протокол пересылки файлов. С помощью этого протокола организовывается пересылка файлов по сети. Технические подробности можно узнать из RFC-документации, а именно: RFC 114, 172, 265, 354, 542, 959;
TELNET
- протокол эмуляции терминала удаленной машины. С помощью этого протокола организовываются сеансы работы на удаленных машинах сети - эмулируется терминал далекого компьютера. NIC просто изобилует информацией в виде RFC-документов по этому протоколу. Вот лишь некоторые из этих документов: RFC 854, 764, 818, 562, 513, 495, 393, 340, 318;
SMTP
- протокол пересылки простой почты - протокол, обеспечивающий работу e-mail. См. техническую документацию в RFC 788, 821, 822, 1123;
TFTP
- протокол простейшей (тривиальной) пересылки файлов. Осуществляет дейтаграммную пересылку файлов. Получается медленнее и дороже, чем по FTP. См. RFC 764, 768, 783;
DNS
- протокол доменной (региональной) системы имен - протокол запросов на преобразование имен из доменной формы в машинную - числовую. См. RFC 1101, 974, 883 и т.д. ;
Служба времени
- служба синхронизации разнесенных в сети часов. Это протокол сетевого времени - NTP. См. RFC 1129, 1119, 1059, 956-958 и т.д. ;
Эхо
- протокол для обратной передачи передаваемых по сети символов, служит, например, для подтверждения. См. документы RFC 347, 361, 862;
GGP
- протокол ``шлюз - шлюз'' - протокол сквозных сетевых проводок. См. RFC 823;
HMP
- протокол мониторинга хоста - протокол непрерывного слежения (контроля) за хостом (сетевым рабочим компьютером). См. RFC 869;
EGP
- протокол внешнего шлюза. См. RFC 827, 888, 890, 904;
ICMP
- протокол межсетевых управляющих сообщений - сетевой протокол, предоставляющий процессам в сети возможность предпочтительного выбора в своем множестве маршрутов пересылки и других подобных вещей. См. документы RFC 777, 792.

RFC - это документация представленная в виде файлов. Она включает описание различных стандартов, устройств, протоколов, предложения новых стандартов и т.д. RFC документы распространяются DDN NIC. Многие сетевые машины имеют у себя наборы RFC различной полноты и свежести. Существуют несколько ``официальных'' распространителей этой документации, у которых всегда имеются полные наборы RFC-документации самой последней редакции, получаемыми ими непосредственно от DDN NIC.

Полный каталог RFC и сами документы можно получить по e-mail, обратившись по адресу servicenic.ddn.mil. Поле ``Subject:'' (``Тема:'')в вашем запросе должно содержать название желаемого документа или команду этого сервера. Само послание должно быть пустым. Например, для получения дополнительной информации пошлите письмо, указав ``Subject: help''; для получения полного каталога - ``Subject: index''; для получения, например, RFC 822 вы должны указать ``Subject: RFC 822'' .

Создание сети с человеческим лицом. Прикладное обеспечение

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

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

Прикладное обеспечение разнится очень сильно. Приложения могут быть от самодельной программы до патентованных продуктов, поставляемых различными фирмами (DEC, Microsoft и т.п.). Существует три стандартных Internet -приложения: удаленный доступ, передача файлов, электронная почта (e-mail); наряду с ними используются другие широко распространенные нестандартные приложения.

Предоставление услуг Internet построено по схеме ``клиент - сервер''. Предоставление услуг осуществляется совместной работой двух процессов: на компьютере пользователя и на компьютере-сервере. Процесс на компьютере пользователя называется клиентом, а на компьютере-сервере - сервером. Клиент и сервер являются, по сути, частями одной программы, взаимодействующие по виртуальной связи в сети. Сервер по указаниям клиента выполняет соответствующие действия, например, пересылает клиенту файл. Для предоставления услуги совершенно необходимо наличие двух этих модулей - клиента и сервера, и их одновременная согласованная работа. Взаимодействие клиента и сервера описывается соответствующими стандартными протоколами, поэтому клиент и сервер могут быть выпущены совершенно разными производителями и работать на разнородных компьютерах. Поэтому же существует небольшая проблема нестандартности интерфейса клиента непосредственно уже с пользователем. Это взаимодействие может иметь совершенно различную форму: интерактивную, командную и т.д. Системы команд могут различаться. Но от этого сами возможности не изменяются, поскольку клиент и сервер всегда взаимодействуют одинаково - согласно протоколу.

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

Системы сетевых адресов

Региональная Система Имен

Числовые адреса хороши для связи машин, люди же предпочитают имена. Очень непросто разговаривать, используя машинную адресацию (как бы это звучало: ``192.112.36.5 обещает вскоре...''?), еще труднее запомнить эти адреса. Поэтому компьютерам в Internet для удобства пользователей были присвоены собственные имена. Тогда описанный разговор принимает вид: ``NIC обещает вскоре...''. Все приложения Internet позволяют пользоваться системными именами вместо числовых адресов.

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

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

В начале Internet размерами напоминала курилку, и иметь дело с именами было довольно просто. NIC создал регистратуру. Можно было послать запрос и в ответ высылали список имен и адресов. Этот файл, называется ``host file'' (файл рабочих ЭВМ), регулярно распространялся по всей сети - рассылался всем машинам. Имена были простыми словами, все были единственными. Если вы использовали имя, ваш компьютер просматривал этот файл и подставлял вместо имени реальный числовой адрес. Так же, как работает телефонный аппарат со встроенным списком абонентов. Все было легко, просто и замечательно. Всем хватало простых имен, в курилке был один Джон, один Пит, один Патермуфий.

Но по мере развития и расширения Internet возрастало количество пользователей, хостов, а потому увеличивался и упомянутый файл. Возникали значительные задержки при регистрации и получении имени новым компьютером, стало затруднительно изыскивать имена, которые еще никто не использовал, слишком много сетевого времени затрачивалось на рассылку этого огромного файла всем машинам, в нем упомянутым. Стало очевидно, - чтобы справиться с такими темпами изменений и роста сети, нужна распределенная оперативная система, опирающаяся на новый принцип. Таковая была создана, ее назвали ``доменной системой имен'' - DNS, а способ адресации - способом адресации по доменному принципу. DNS иногда еще называют региональной системой наименований.

Структура региональной системы имен

Доменная система имен - это метод назначения имен путем передачи сетевым группам ответственности за их подмножество имен. Каждый уровень этой системы называется доменом. Домены в именах отделяются друг от друга точками: inr.msk.su, nusun.jinr.dubna.su, arty.bashkiria.su, vxcern.cern.ch, nic.ddn.mil. В имени может быть различное количество доменов, но практически их не больше пяти. По мере движения по доменам слева направо в имени, количество имен, входящих в соответствующую группу возрастает.

Первым в имени стоит название рабочей машины - реального компьютера с IP адресом. Это имя создано и поддерживается группой (например, компьютер nusun (это SUN sparc) в группе jinr (ОИЯИ)), к которой он относится. Группа входит в более крупное подразделение (например, городское объединение - сеть города Дубны), которое в свою очередь, является частью национальной сети (например, сети стран бывшего СССР, домен su). Для США наименование страны по традиции опускается, там самыми крупными объединениями являются сети образовательных (edu), коммерческих (com), государственных (gov), военных (mil) учреждений, а также сети других организаций (org) и сетевых ресурсов (net).

Группа может создавать или изменять любые ей подлежащие имена. Если jinr решит поставить другой компьютер, например, VAX 11/780, и назвать его mainx, он ни у кого не должен спрашивать разрешения, все, что от него требуется, - это добавить новое имя в соответствующую часть соответствующей всемирной базы данных, и, рано или поздно, каждый, кому потребуется, узнает об этом имени. Аналогично, если в Дубне решат создать новую группу, например, schools, они (домен dubna) могут это сделать также, ни у кого на то не спрашивая никакого соизволения. И тогда, если каждая группа придерживается таких простых правил и всегда убеждается, что имена, которые она присваивает, единственны во множестве ее непосредственных подчиненных, то никакие две системы, где бы те ни были в сети Internet, не смогут заиметь одинаковых имен.

Эта ситуация совершенно аналогична ситуации с присвоением географических названий - организацией почтовых адресов. Названия всех стран различаются. Различаются названия всех областей, республик в Федерации, и эти названия утверждаются в государственном масштабе из центра (конечно, обычно сами регионы заботятся об уникальности своих названий, поэтому здесь царит полная демократия: как республика хочет, так она и называется)gif. В республиках - субъектах федерации - решают вопросы о названиях районов и округов, в пределах одной республики они различаются. Аналогично далее с городами и улицами городов. В разных городах могут быть улицы с одинаковыми названиями: почему бы не быть во всех городах Cоюза по улице Ленина или Мира? Это улицы разных городов, и их не перепутать (помня о городах! Не напоминайте ``С легким паром!''). В пределах же одного населенного пункта улицы всенепременно имеют разные названия, причем именование этих улиц целиком и полностью под ответственностью и началом соответствующего центрального органа данного населенного пункта (мэрии, сельсовета, горсовета). Таким образом, почтовый адрес на основе географических и административных названий однозначно определяет точку назначения.

Поскольку Internet - сеть мировая, требовался также способ передачи ответственности за имена внутри стран им самим. Сейчас принята двухбуквенная кодировка государств. Это оговорено в RFC 822. Так, например, домен Канада называется ca, бывший СССР - su, США - us и т.д. США также включили в эту систему структурирования для всеобщности и порядка. Всего же кодов стран почти 300, из которых около 100 имеет компьютерную сеть того или иного рода. Единый каталог Internet находится у SRI International (Менло-Парк, Калифорния, США) - государственной организации.

Поиск адреса по доменному имени

Теперь вы знаете, как соотносятся домены и создаются имена. Возможно, вы теперь озадачены: а как использовать эту замечательную систему? Автоматически. Вам надо лишь употребить имя на компьютере, который понимает, как обращаться с DNS. Вам никогда не придется самим разыскивать адрес, соответствующий этому имени, или подавать специальную команду для его поиска (в UNIX - команда nslookup). Вы, конечно, можете это проделать - для собственного удовольствия, но зачем, ведь этого совсем не требуется. Все компьютеры Internet способны пользоваться доменной системой. И работающий в сети компьютер всегда знает свой собственный сетевой адрес.

Когда вы пользуетесь именем, например, mx.ihep.su, компьютер должен преобразовать его в адрес. Для этого он начинает запрашивать помощь у DNS-серверов. Это узлы, рабочие машины, обладающие соответствующей базой данных, в число обязанностей которых входит обслуживание такого рода запросов. DNS-сервер начинает обработку имени с правого его конца и двигается по нему влево, т.е. сначала производится поиск адреса в самой большой группе (домене), потом постепенно сужает поиск. Но для начала опрашивается на предмет наличия у него нужной информации местный узел. Здесь возможны три случая:

-
Местный сервер знает адрес, потому, что этот адрес содержится в его части всемирной базы данных. Например, если вы подсоединены к сети Института Физики Высоких Энергий (IHEP), то ваш местный сервер должен обладать информацией о всех компьютерах локальной сети этого института (mx, desert, ixwin и т.д.);
-
Местный сервер знает адрес, потому, что кто-то недавно уже запрашивал тот же адрес. Когда запрашивается адрес, сервер DNS придерживает его у себя в памяти некоторое время, как раз на случай, если кто-нибудь еще захочет попозже того же адреса - это повышает эффективность системы;
-
Местный сервер адрес не знает, но знает как его выяснить.

Как местный сервер может разузнать запрошенный адрес? В его прикладном или системном программном обеспечении имеется информация о том, как связаться с корневым сервером. Это сервер, который знает адреса серверов имен высшего уровня (самых правых в имени), здесь это уровень государств (ранга домена su). У него запрашивается адрес компьютера, ответственного за зону su. Местный DNS-сервер связывается с этим более общим сервером и запрашивает у него адрес сервера, ответственного за домен ihep.su. Теперь уже запрашивается этот сервер и у него запрашивается адрес рабочей машины mx.

На самом деле, для повышения эффективности, поиск начинается не с самого верха, а с наименьшего домена, в который входите и вы, и компьютер, имя которого вы запросили. Например, если ваш компьютер имеет имя nonlin.mipt.su, то опрос начнется (если имя не выяснится сразу) не со всемирного сервера, чтобы узнать адрес сервера группы su, а сразу с группы su, что сразу сокращает поиск и по объему, и по времени.

Этот поиск адреса совершенно аналогичен поиску пути письма без надписанного почтового индекса. Как определяется этот индекс? Все регионы пронумерованы - это первые цифры индекса. Письмо пересылается на центральный почтамт этого региона, где имеется справочник с нумерацией районов этого региона - это следующие цифры индекса. Теперь письмо идет на центральный почтамт соответствующего района, где уже знают все почтовые отделения в подопечном районе. Таким образом по географическому адресу определяется почтовый индекс, ему соответствующий. Также определяется и адрес компьютера в Internet, но путешествует не послание, а запрос вашего компьютера об этом адресе. И в отличие от случая с почтой, информация об адресе доходит до вас, как если бы районный почтамт места назначения отправлял вам письмо, любезно уведомляя вас на будущее об индексе, которого вы не изволили знать.

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

Замечания по региональной системе имен

Распространено несколько заблуждений, с которыми вы можете столкнуться, имея дело с именами. Приведем несколько верных утверждений в качестве опорных, чтобы вывести вас из заблуждений, или предостеречь от них:

-
Части доменного имени говорят о том, кто ответственен за поддержку этого имени, то есть в чьем подчинении-ведении оно находится. Они могут вообще ничего не сообщать о владельце компьютера, соответствующего этому IP-адресу, или даже (несмотря на коды стран), где же эта машина находится. Вполне можно иметь в Антарктиде машину с именем inr.msk.su (ИЯИ РАН, г.Троицк под Москвой). Это совершенно ненормально, но никаким законам не противоречит.

Вот реально существующий пример: в Институте Химической Физики (пос. Черноголовка Московской области) стоит машина с именем lle.icp.chg.free.net, относящимся к домену net, расположенному, по идее, в США.
Примечание:
Когда уже была готова WWW-версия этой книги, один из авторов (В.У.) сообщил мне:
"В Черноголовке перетрясли имена, теперь такого имени уже нет. У них теперь домен ac.ru ."
М.В.

-
Части доменного имени даже не всегда указывают локальную сеть, в которой расположен компьютер. Часто доменные имена и сети перекрываются, и жестких связей между ними нет: две машины одного домена могут не принадлежать одной сети. Например, системы mx.decnet.ihep.su и ms.decnet.ihep.su могут находиться в совершенно разных сетях. И еще раз: доменные имена указывают на ответственного за домен.
-
У машины может быть много имен. В частности, это верно для машин, предоставляющих какие-либо услуги, которые в будущем могут быть перемещены под опеку другой машины. Когда эти службы будут перемещены, то имя, под которым эта машина выступала в качестве такого сервера, будет передано новой машине-серверу вместе с услугами, - для внешних пользователей ничего не изменится. Т.е. они будут продолжать пользоваться этой службой, запрашивая ее по тому же имени, независимо от того, какой компьютер на самом деле занимается обслуживанием. Имена, по смыслу относящиеся к службе, называются ``каноническими именами'' или ``кименами'' (cnames). В Internet они встречаются довольно часто.
-
Для связи имена необязательны. Как-нибудь вам придет сообщение: ``адресат неизвестен'', что означает, что Internet не может преобразовать использованное вами имя в число, - имя более недееспособно в том виде, в котором его знает ваш компьютер. Однажды заполучив числовой эквивалент имени, ваша система перестает использовать для связи на машинном уровне доменную форму адреса.
-
Запоминать лучше имена, а не числовые адреса. Некоторым кажется, что система имен это ``еще одно звено в цепи, которое может выйти из строя''. Но адреса привязаны к конкретным точкам сети. Если компьютер, предоставляющий некие услуги, переносится из одного здания в другое, его сетевое расположение, а значит и адрес, скорее всего изменятся. Имя же менять не надо и не следует. Когда администратор присваивает новый адрес, ему нужно только обновить запись имени в базе данных так, чтобы имя указывало на новый адрес. Так как имя работает по-прежнему, вас совершенно не должно заботить то, что компьютер расположен уже в другом месте.

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

Система адресов X.400

X.400 - общий стандарт, разработанный ISO и CCITT, для управления сообщениями. Этот стандарт планируют принять многие сети. Некоторые уже используют его.

Дополнительно к обычному тексту, сообщения X.400 могут содержать и другие форматы (факсы, записи звуков речи, музыки, различные изображения и т.д.). Адресация в пользовании также очень проста, слегка напоминает своей идеей DNS. Только здесь используются не названия групп, сетей, но более привычные в обиходе понятия:

Код страны -тот же, что в RFC822;

ADMD - Administration Management = домен административного управления . Определяет общественный носитель X.400.Владельцем ADMD обычно является компания по предоставлению услуг дальней связи или государственное учреждение связи. Для соединения ADMD друг с другом их владельцы заключают двусторонние соглашения, и, естественно, не все ADMD соединены между собой. Самые крупные владельцы ADMD: AT&T, MCI, Sprint

PRMD -Private Management Domain = домен частного управления. Определяет используемый частный носитель X.400. Это может быть EUnet, BITN и т.д. или же частная организация;

Организация - Указывает организацию получателя. Ею может быть, например, компания или учебное заведение МФТИ Oxford, Cambridge, MIT и т.д.;

Орг.единица - Определяет подразделение. Их может быть несколько. Например не просто physics, но lab_1 или lab_2;

Фамилия - Плотников;

Имя - Олег. Требуется, если фамилия достаточно распространЈнная.

Можно преобразовать старый адрес в X.400 формат, но не всегда это будет просто. Тем не менее, вполне может статься, что вас осчастливят письмом в формате X.400 . Чтобы послать ответ отправителю, просто возьмите его адрес из поля ``From:''полученного письма. Соответствующий шлюз с этим разберется.

К счастью имеется инструкция (RFC 987) по переводу адресов и текстовых сообщений X.400 в формат RFC 822, имеется соответствующее программное обеспечение. Но, увы, единой системы картографирования таких адресов не существует; разные почтовые станции работают с ними немножко по-разному, что может приводить к недоразумениям. Также не существует единого стандарта для записи X.400 адреса, поэтому пока невозможно единообразно и ясно надписать таковой, например, на бизнес-карте.

Заинтересовавшихся пользователей отсылаем к [9].

[Предыдущая глава] [Содержание] [Следующая глава]

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...