kantrium.com | E-Norway.ru | HELFI.ru | MySuomi.com

1. Коммуникационные системы

Коммуникационные системы

 

1.1. Обзор

Эту книгу следует рассматривать как техническое введение в общие проблемы Передачи данных. Передача данных связана с проблемой надежной (гарантирующей как от сбоев (разрывов) каналов связи, так и от помех) пересылки информации из одного пункта в другой в соответствии с требованиями пользователей. В этой книге освещены ключевые моменты, связанные собственно с Информацией и ее надежной передачей, удовлетворяющей требованиям пользователей.В последние несколько лет важность связи (коммуникаций) в жизни общества существенно возросла. Часто говорят, что информация — это сила, но на самом деле она становится силой только тогда, когда вы получаете ее в нужном месте в нужное время. Мы намного мобильнее наших предков и, поскольку мы все больше передвигаемся с места на место и занимаемся разнообразной деятельностью на все больших пространствах, потребность в связи постоянно возрастает. С другой стороны, чем более простой и более доступной становится связь, тем большее количество людей хочет ею воспользоваться.Хорошие системы связи основываются на пользующихся большим успехом приложениях. Пользователь в буквальном смысле находится в начале и конце коммуникационной системы. Это можно подтвердить заметным успехом речевых и WAP (Wireless Application Protocol, протокол беспроводных приложений) служб в мобильной телефонии. Произошел беспрецедентный рост пользователей таких служб, и теперь уже больше половины населения Великобритании имеет мобильные телефоны. Подобные устройства очень просты в использовании, удобны и относительно недороги. Разговаривать по ним можно почти везде. С другой стороны, сами WAP-службы довольно сложны, трудны в использовании и дороги для обмена информацией. Кроме того, имеются более простые и дешевые способы получения того же самого результата. Такое положение, однако, может измениться, если больше людей для получения информации во время движения начнут пользоваться PDA -микрокомпьютерами. Впрочем, WAP-протокол на мобильных телефонах оказался менее успешным, чем предполагалось.

 

1.2. Декомпозиция коммуникационных систем

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

pic5

 


 

PDA - Personal Digital Assistant. У нас подобный карманный компьютер принято называть Электронным секретарем. — Пер.

 

Хорошим примером такого подхода является факсимильный аппарат, который .переносит документы по системе связи, разработанной для приложений с голо совым вызовом. Поскольку факсимильные аппараты могут использовать уже существующую инфраструктуру, то их установка не приводит к большим затратам и неудобствам. Это означает, что можно довольно быстро разработать и установить базовую систему факсимильных аппаратов, что в свою очередь подтолкнет многих пользователей к установке новых устройств, и т. д.По этой причине в большинстве коммуникационных систем обеспечен определенный набор интерфейсов для установки необходимых служб. В эти службы приложения и направляют свои запросы на услуги связи. Преимуществом такого подхода является то, что приложение не должно что-либо знать о деталях системы служб связи. Приложению должен быть известен лишь интерфейс службы, к которой оно направляет свои данные. С другой стороны, коммуни кационную систему также не должны беспокоить детали приложения. Еще од но преимущество такой методики состоит в том, что связь возможна между двумя различными приложениями, если оба они используют службы связи ана логичным образом. Например, пользователь программы Microsoft Outlook мо жет посылать электронную почту пользователю обозревателя Netscape Com municator, или пользователь телефона с дисковым номеронабирателем может позвонить пользователю кнопочного аппарата.Телефонная система проектируется так, чтобы посылать изменяющийся элек трический сигнал от одного абонента к другому. Приложением в этом случае  является сам телефон, а интерфейсом службы — настенный телефонный разъем. В розетку можно включать любые телефоны, которые "понимают" интерфейс, обеспечиваемый сетью (в данном случае это переменный электрический сигнал для речи и набора номера). Если вы включите в настенный разъём факсимильный аппарат, то ваше приложение должно измениться, тогда как никакого изменения в системе связи не потребуется, потому что коммуникационная служба останется той же самой. Расширяя этот подход, можно разделить на службы и остальную часть системы связи. Обеспечение прямой коммуникационной связи каждого источника с каждым адресатом было бы непрактично. Чтобы обойти эту проблему, все коммуникационные системы, кроме самых простых, будут состоять из сети — набора переключаемых линий (каналов) связи, соединяющих источники и адресаты.На самом низком уровне в этой иерархии находится связь по индивидуальному каналу. Здесь происходит процесс передачи данных по заданной среде передачи из одного места в другое.Подобная четырехуровневая иерархия, включающая приложения, использующие службы, переключаемые по сети линий связи, каждая из которых транспортирует данные из одного места в другое через среду передачи, называется многоуровневой иерархией потому что на каждом уровне происходит абстра гирование от подробностей нижележащих уровней.

 

1.3. Многоуровневые коммуникационные архитектуры

Многоуровневую структуру можно определить более формально. Коммуникационные системы разделяются на вертикальный набор уровней, в котором каждый уровень выполняет определенным образом связанное подмножество функций, требуемых для связи с другой системой. Функции в пределах уровня собраны в группы, называемые объектами. Объекты одного уровня в разных системах связываются друг с другом, используя один или несколько протоколов. Протокол определяется, как набор правил для передачи информации или команд. Подобную многослойную архитектуру часто называют стеком протоколов. Любой конкретный уровень такой архитектуры зависит от нижележащего уровня (если таковой имеется), выполняющего более примитивные функции и скрывающего детали этих функций. Интерфейсы между уровнями называются точками доступа к службам (Service Access Points, SAP) — рис. 1.2.

pic6

Объекты, связывающиеся на заданном уровне обмениваются сообщениями, которые называют протокольными блоками данных (Protocol Data Units-PDU) — рис. 1.3. Синтаксис протокола определяет формат, а его семантика — значение сообщений. Чтобы избежать беспорядка, синтаксис протокола должен быть точно определен. Блок PDU каждого уровня состоит из протокольной информации этого уровня, а в качестве полезной нагрузки использует PDU-блоки вышележащего уровня.Одноуровневые протоколы используются соответствующими объектами для связи друг с другом с целью реализации определенной службы. Используемый протокол можно изменять при условии, что сама служба, с точки зрения ее пользователя, не изменяется. Таким образом, служба и протокол всегда разделяются.

pic7

 

1.3.1. Потребность в стандартах

Как отмечено раньше, чтобы система работала, протокол должен быть согласован с поддерживающими связь объектами. Так как эти объекты могут располагаться даже в различных странах, то, очевидно, существует потребность в согласованных международных стандартах. Существуют стандарты "де факто", такие как UNIX или IBM PC, или "де юре", формально узаконенные стандарты, принятые полномочными органами, занимающимися стандартизацией. Они могут быть национальными, такими как Американский национальный институт стандартов (ANSI, American National Standards Institute), Британский институт стандартизации (BSI, British Standards Institution), ARIB или международными, управляемыми в соответствии с соглашением национальных правительств, такими как Международный телекоммуникационный союз (ГШ, International Telecommunications Union).К стандартам приходят разными путями, и создаются они разными организациями, включая правительственные, межправительственные и профессиональные, а также промышленные группы.Международная организация по стандартизации (ISO, International Standards Organisation) — это добровольная, не договорная организация, выпускающая широкий диапазон стандартов по самым разным темам. Она имеет почти 90 членов, включая ANSI, BSI, AFNOR (Association Francaise de Normalisasion, Французская организация стандартов) и DIN (Deutsche Industrie-Normen, Немецкие промышленные стандарты), и состоит почти из 200 технических комитетов (ТС, Technical Committee), пронумерованных в порядке их создания и имеющих дело с универсальной тематикой (ТС1), компьютерами и обработкой информации (ТС97) и т. п. Каждый ТС состоит из подкомитетов (SC, Sub-Committee), которые разделены на рабочие группы (WG, Working Groops). Работа выполняется главным образом рабочими группами, которые включают добровольцев из академических кругов, правительственных должностных лиц и представителей промышленности. Чтобы избежать несовместимых стандартов, ISO сотрудничает с ГШ. ГШ, первоначально называвшийся Международным консультативным комитетом по телеграфии и телефонии (CCITT, Consultative Committee on International Telegraph and Telephone ), состоит из сектора радиосвязи (ITU-R) и сектора телекоммуникационных стандартов (ITU-T), а также включает секретариат и сектор разработок.Интересно отметить существенное различие между подходами к проблеме стандартов, принятыми в Соединенных Штатах и Европе. Европа занимает очень активную позицию в области стандартов. Европейский институт телекоммуникационных стандартов (ETSI, European Telecommunications Standards Institute) имеет очень активную программу стандартизации. Европейские правительства часто требуют, чтобы изготовители телекоммуникационного оборудования изготовляли его в соответствии с соответствующими стандартами, прежде чем разрешать его к продаже в Европейском Содружестве. В Соединенных Штатах Америки подход иной, намного более независимый, допускающий рыночные решения. Одним из главных органов, разрабатывающих стандарты США, является Институт инженеров по электротехнике и электронике (IEEE, Institute of Electrical and Electronic Engineers), который является профессиональной организацией, а не правительственным учреждением.

 

1.3.2. Эталонная модель Internet

Четырехуровневая модель — одна из самых простых моделей, которую можно применять к системам связи, но существуют и другие. Хотя полного стандарта для стека Internet-протоколов не существует, архитектура, которая была разработана на основе исходной сети ARPANET, имеет пять уровней: Прикладной, Транспортный, Internet (Межсетевой), Канальный и Физический (рис. 1.4).

pic8

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

 

1.3.3. Эталонная модель взаимодействия открытых систем

Модель Internet имеет довольно прочную основу. Одной из наиболее общих моделей передачи данных является модель взаимодействия открытых систем (OSI, Open Systems Interconnection), которая имеет семь уровней, как показано рис. 1.5. Ее часто называют семиуровневой моделью.Замыслом разработчиков модели OSI было обеспечение всех преимуществ для взаимодействующих сетей. Предполагалось, что если модель OSI используется всеми изготовителями, то любая машина, в которой реализована эта модель, будет "открытой", т. е. способной соединиться со всеми другими подобными системами во всем мире. Разработанная в 1979 году в ISO (International Standartization Organization, Международная организация по стандартизации), модель OSI предназначалась для обеспечения общего базиса с целью координации разработки, стандартов для соединения различных систем и одновременно позволяла включить в полную эталонную модель все существующие стандарты.

Прикладной Прикладной   Прикладной
Служебный Представительский Представительский
Сеансовый Сеансовый
Транспортный Транспортный
Сетевой Сетевой Сетевой Сетевой Сетевой
Канальный Канальный Канальный Канальный
Среды передачи Физический Физический Физический Физический

Рис. 1.5» Стеки протоколов OSI в сравнении с четырехуровневой моделью

 

Уровни на рис. 1.5. нумеруются снизу вверх от 1 до 7, и предполагается, что в диаграмме имеется пользователь А (вверху левого стека), желающий связаться с пользователем В (вверху правого стека). Информация от пользователя А должна быть послана вниз по уровням — к уровню 1, где она передается через сеть уровню 1 пользователя В; затем она перемещается вверх через аналогичные уровни— к пользователю В. На рис. 1.5 показан промежуточный узел между двумя пользовательскими узлами. Этот узел имеет отношение к маршрутизации информации от пользователя А к пользователю Вив обратном направлении, и поэтому выполняет только функции, связанные с первыми тремя уровнями (см. небольшие стеки в центре рис. 1.5). Ситуация, когда четыре верхних уровня существуют только в конечных пунктах, довольно часто происходит в сети. Исключением является случай, когда требуется перекодировка одного типа данных в другой, тогда в промежуточных узлах использовались бы и остальные уровни.Уровни модели OSI можно разделить на три категории. Протоколы четырех верхних уровней выполняют функции организации и представления данных таким способом, который в итоге имеет смысл только для конечного пользователя. Они соответствуют уровню обслуживания и прикладному уровню. Протоколы этих уровней должны быть согласованными для пар связывающихся программ конечных пользователей.

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

  •  Прикладной (Application) уровень (7-й) обеспечивает интерфейс пользователя с коммуникационной системой. В качестве примеров можно привести электронную почту, распределенные базы данных и сетевые операционные системы.
  •  Представительский (Presentation) уровень обеспечивает общий формат представления данных для прикладного уровня. Он позволяет хост2-устройствам связываться между собой, даже если они используют различные представления данных. Например, разные Web-браузеры (программы просмотра) обеспечивают различные пользовательские интерфейсы (то есть являются разными приложениями), но все они понимают формат HTML-страниц, формат изображений JPEG и т. д. Эти файловые форматы являются примерами протоколов представительского уровня, тогда как сами браузеры постоянно находятся на прикладном уровне. Поэтому службы, которые поддерживает представительский уровень, обеспечивают такие услуги, как передача файлов, протоколы виртуальных терминалов, сжатие, преобразование кодов и шифрование.
  • Сеансовый (Session) уровень разделяет поток данных, формируемый  службами представительного уровня на несколько основных потоков — сеансов (связи), которые посылаются через систему и управляют взаимодействиями между парами сообщающихся прикладных процессов. Сеансы могут быть короткими или длинными, включающими одно или несколько взаимодействий с помощью обмена сообщениями, например дозатор наличных денег банка на компьютер; терминал, зарегистрированный в удаленном компьютере. Услуги, предоставляемые представительскому уровню, включают организацию/завершение сеанса, идентификацию/регистрацию, синхронизацию передачи данных и сообщения об исключительных ситуациях.
  • Транспортный (Transport) уровень обеспечивает начальную установку канала связи, передачу данных и заключительное освобождение канала. Для передачи данных он взаимодействует с сетевым уровнем, чтобы гарантировать свободное от ошибок виртуальное прямое соединение, где связь происходит в правильной последовательности. В случае когда компьютеры обладают многозадачными возможностями, транспортный уровень гарантирует, что связь происходит в правильной последовательности и выполняет любое требуемое мультиплексирование или разделение каналов.
  • Сетевой (Network) уровень связывает коммуникационные каналы (звенья) данных в глобальную сеть, которая соединяет все "открытые" системы, т. е. выполняет маршрутизацию передач данных из узла источника к узлу адресата. Он реализует правила маршрутизации пакетов через сеть и, если это необходимо, правила управления потоком данных, гарантирую-щие, чтобы не слишком много пакетов находилось в системе.
  • Канальный (Data Link) уровень. Его иногда называют уровнем канала или звена данных. Он гарантирует надежную связь на физическом уровне. Протокол этого уровня определяет структуру данных, например, размер кадра или пакета, и имеет дело с такими аспектами, как управление потоком данных, обнаружением и устранением ошибок.
  • Физический (Physical) уровень имеет дело с физическими характеристиками линии связи — механическими и электрическими — и обеспечивает средства для передачи битов данных через непрерывный связной путь. Протокол этого уровня оперирует с такими деталями, как размер, потери и частотные характеристики кабеля, тип соединителя, размещение штырьков контактных разъемов, уровни напряжений и кодирование передачи.

 


 

Хост — любое устройство, подключенное к сети и использующее протоколы TCP/IP. — Пер.

 

Модель OSI четко определяет службы, интерфейсы и протоколы. Архитектура Internet очень проста. Она была разработана с позиций передачи данных, тогда как в действительности идея Internet-модели базируется на компьютерах. Она имеет большое количество уровней, роли которых не всегда четко определены. Другие же уровни, такие, например, как уровень канала данных (канальный), являются неуправляемыми и часто разбиваются на подуровни. Он проектировался для решения общих проблем связи и был разрабоган прежде, чем были разработаны протоколы. Отсутствие опыта работы с протоколами и работа на крупные корпорации привели к сверхсложному решению для этого уровня. С другой стороны, модель Internet в действительности не является формальной моделью, она просто устанавливается вокруг работающих протоколов. Она имеет меньшее количество уровней, но не очень хороша для описания вещей, отличных от TCP/IP. Модель OSI популярна, но ее протоколы не используются так широко, как Internet. Протоколы TCP/IP более популярны.

 

1.4. Структура книги

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

pic9

Многоуровневая модель немного абстрактна, так что лучший способ увидеть, что происходит, — привести пример. Превосходным примером системы связи является Internet, обеспеченный различными инструментальные средствами, которые можно использовать для того, чтобы видеть, что же фактически в этой системе происходит.Чтобы показать различные принципы в действии, возьмем случай просмотра домашней страницы Института телекоммуникационных исследований (Institute for Telecommunication Research) Университета Южной Австралии. Его домашняя страница дана на рис. 1.7. Здесь показано ее представление в браузерах только одного типа. Браузеры других типов могут отображать ее несколько иначе. Сами Web-браузеры находятся на прикладном (7-м) уровне модели OSI.Web-браузер интерпретирует HTML-страницу, которая является примером Протокола 6-го уровня.Web-страница, которая выглядит так, как показано на рис. 1.7, кодируется (на языке HTML) следующим образом:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<html>

<head>

<title>Welcome to the ITR web site

</title>

</head>

<body link-"#OOOOFF" alink-"#800080" vlink="#FFOOOO" text="#000000" leftmargin-"0" topmargin="0" bgcolor="#FFFFFF">
</body>

</html>

 

pic10

Вначале отметим, что, т. к. этот пример пользуется в Internet, где четко определенный сеансовый уровень отсутствует, то взаимодействие приложения с сетевыми программами компьютера работает следующим образом (Протокол 1.1). Сначала наш компьютер соединяется с компьютером ITR и запрашивает файл http://www.itr.unisa.edu.au. По строке 3-ей (сверху) листинга видно, что протокол, который в нем используется— это НТТР/1.1, что наш компьютер может принимать все что угодно (строка 4), что он использует английский язык (строка 5), определенный тип браузера (строка 7) и т. д. Компьютер ITR отвечает, посылая код результата 200, в котором говорится, что запрос принят и дальше последует файл. Затем он посылает этот файл. Однако во время получения файла, браузер замечает, что тот содержит изображение, и открывает второе соединение, чтобы получить это изображение. Так как это довольно медленное соединение, то данные поставляются приложению "кусками". Эти куски в общем случае кратны 536 байтам, что и определяет размер используемых здесь ТСР-сегментов.

Протокол 1.1

CONNECTION 1: Connecting to server

CONNECTION 1: Client to Server (250 bytes)

GET  http://www.itr.unisa.edu.au/ НТТР/1.1

Accept: */*

Accept-Language: en-gb

Accept-Encoding: gzip, deflateUser-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

Host: www.itr.unisa.edu.au

Proxy-Connection: Keep-Alive\ Pragma: no—cache

CONNECTION 1: Server to Client (536 bytes)

HTТР/1.1 200 OK

Date: Sun, 29 Jul 2001 16:38:27 GMT

Server: Apache/1.3.9 (Unix)

Transfer-Encoding: chunked

Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EM">

<html>

<head>

<title>Welcome to the ITR web site</title>

</head>

<body link="#0000FF" alink="#800080" vlink="#FT0000" text="#000000" leftmargin="0" topmargin="0" bgcolor="#FFFFFF">

<div align="center">

<center>

<table BORDER="0" CELLPADDING="0" CELLSPACING="0" WIDTH="100%" height="100%">

<tr>

<td valign="center" al

CONNECTION 1: Server to Client (1072 bytes)

Align="center"><1--webbot bot="ImageMap" startspan

......


CONNECTION 1: Server to Client (1608 bytes)

HREF="tech__res/tech_res.html"><AREA SHAPE="RECT" COORDS="140, 106, 208, 124"

HREF="about_us/about .html"x/MAP>

<img src="/ images/itr_new.gif" width <font face="verdana, arial, helvetica" size="2"><form action=../cgi-bin/htsearch" methods="post">

.......

CONNECTION 2; Connecting to server

CONNECTION 2: Client to Server (307 bytes)

GET http://www-itr.unisa.edu.au/images/itr_new.gif HTTP/1.1

Accept: */*

Referer: http://www.itr.unisa.edu.au/

Accept-Language: en-gb

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

Host: www.itr.unisa.edu.au

Proxy-connection: Keep-Alive

Pragma: no-cache

 

CONNECTION 1: Server to Client (450 bytes)

type="hidden" name="config" value="itr"xinput type="hidden"

name="method" value="or"xinput type="hidden" name="format" value=»builtin-long">

<font face="verdana, arial, helvetica" size="lnxbxp>Search:</b>

<input type="Text" name="words" size="20">

<input type="Submif name="submit" value="go"> </fontx/fontx/p>

</form>

/td>

</tr>

</table>

</centerx/divx! —crc_sat_sys .html—>

</body>

</html>

 

CONNECTION 2: Server to Client (536 bytes)

HTTP/1.1 200 OK

 

CONNECTION 2: Server to Client (1072 bytes)

CONNECTION 2: Server to Client (1608 bytes)

CONNECTION 2: Server to Client (1608 bytes)

CONNECTION 2: Server to Client (1072 bytes)

CONNECTION 2: Server to Client .(1608 bytes)

CONNECTION 2: Server to Client (1608 bytes)

CONNECTION 2: Server to Client (1072 bytes)

CONNECTION 2: Server to Client (536 bytes)

CONNECTION 2: Server to Client (536 bytes)

CONNECTION 2: Server to Client (8040 bytes)

CONNECTION 2: Server to Client (3752 bytes)

CONNECTION 2: Server to Client (4824 bytes)

CONNECTION 2: Server to Client (4824 bytes)

CONNECTION 2: Server to Client (4589 bytes)

CONNECTION 2: Server to Client (3216 bytes)

CONNECTION 2: Server to Client (3405 bytes)

CONNECTION 1: Server disconnected

CONNECTION 2: Server disconnected

 

Следующим, более низким уровнем, является транспортный с протоколом TCP (Transmission Control Protocol, протокол управления передачей). В TCP/IP (Internet Protocol, межсетевой протокол) каждый TCP-сегмент размещается в двух IP-пакетах, так что два таких пакета оказываются связанными.работа на этом уровне начинается так, как показано в приведенном ниже дисплейном протоколе 1.2. Каждая строка представляет IP-пакет, и большинство пакетов содержит TCP-сегменты, хотя некоторые содержат дей-Таграммные UDP-пакеты (см. разд. "Протокол пользовательских дейтаграмм" гл. 4) для запроса сервера имен hestia.clara.net. Это локальный Сервер имен, который наш компьютер (me) использует для запроса адресов. Первая проблема, с которой приходится сталкиваться компьютеру, это контакт с сервером имен. В строке 1 выдается ARP-пакет, закрашивающий адрес локальной сети, где может находиться сервер имен. |1олучив его, компьютер посылает на сервер имен (соединение через порт ЯЗОО) пакет (строка 2), запрашивающий адрес http://www.itr.unisa.edu.au. Сервер имен отвечает, что каноническим именем является http://www.itr.unisa.edu.au, а реальным — charii.ievels.unisa.edu.au. Запросы сервера имен приведены в разд. 4.13.5. Затем посылается другой ARP-запрос, чтобы найти узел, к которому нужно посылать запросы для charli.levels.unisa.edu.au. Конечно, этот адрес находится не в нашей сети, НО маршрутизатор нашей сети, ответственный за организацию трафика к Другим сетям, выдаст ответ с этим адресом. До этого момента вся деятельность была направлена только на установку соединения, а не на посылку Самих данных. Имея необходимый адрес, компьютер посылает его в виде сегмента в порт 80 (порт Web-сервера), требуя, чтобы было установлено соединение (строка 5). Web-сервер отвечает (строка 6) подтверждением на запрос и разрешает соединение, а наш компьютер подтверждает это (строка 7). Это трехкратное подтверждение (квитирование) связи и устанавливает TCP-соединение. Наконец, в строке 8, выполняется посылка данных, которые содержат описанный выше запрос. Сервер отвечает (строка 9) подтверждением, но еще не посылает каких-либо данных. Данные следуют в строке 10, что наш компьютер (те) и подтверждает в строке 11. Это соединение имеет, по предварительной договоренности, максимальный размер сегмента 536 байтов, так что TCP-сегменты имеют этот же размер. Затем от сервера следуют еще два таких сегмента с подтверждением, выдаваемым в строке 14. Остальные данные следуют в сегментах строк 15, 16, 18 и 21 с подтверждениями в строках 17 (двух сегментов), 19 и 22. Строки 20, 23 и 24 — трехкратное подтверждение второго соединения, организуемого для получения изображения.

 

Протокол 1.2

 

1 arp request for hestia.clara.net

2 me.1300 > hestia.clara.net.53 1+ A? vjww.itr.unisa.edu.au. (38)

3 hestia.clara.net.53 > me.1300: 1 2/3/3 CNAME cha (201)

4 arp request for charli.levels.unisa.edu.au

5 me.1305 > charli.levels.unisa.edu.au.80: S 5637114:5637114(0) win 8192<lriss 536,sackOK>

6 charli.levels.unisa.edu.au.80 > me.1305: S 2454387047:2454387047(0) ack 5637115win 9112 <mss 536>

7 me.1305 > charli.levels.unisa.edu.au.80: . ack 1 win 8576

8 me.1305 > charli.levels.unisa.edu.au.80: P 1:286(285) ack 1 win 8576

9 charli.levels.unisa.edu.au.80 > me.1305: . ack 286 win 9112

10 charli.levels.unisa.edu.au.80 > me.1305: P 1:537(536) ack 286 win 9112

11 me.1305 > charli.levels.unisa.edu.au.80: . ack 537 win 8576

12 charli.levels.unisa.edu.au.80 > me.1305: . 537:1073(536) ack 286 win 9112

13 charli.levels.unisa.edu.au.80 > me.1305; P 1073:1609(536) ack 286 win 9112

14 me.1305 > charli.levels.unisa.edu.au.80: . ack 1609 win 8576

15 charli.levels.unisa.edu.au.80 > me.1305: . 1609:2145(536) ack 286 win 9112

16 charli.levels.unisa.edu.au.80 > me.1305: . 2145:2681(536) ack 286 win 9112

17 me.1305 > charli.levels.unisa.edu.au.80: . ack 2681 win 8576

18 charli.levels.unisa.edu.au.80 > me.1305: P 2681:3217(536) ack 286 win 9112

19 me.1305 > charli.levels.unisa.edu.au.80: . ack 3217 win 8576

20 me.1308 > charli.levels.unisa.edu.au.80: S 5641262:5641262(0) win 8192<mss 536,sackOK>

21 charli.levels.unisa.edu.au.80 > me.1305: P 3217:3667(450) ack 286 win 9112

22 me.1305 > charli.levels.unisa.edu.au.80: . ack 3667 win 8126

23 charli.levels.unisa.edu.au.80 > me.1308: S 2455265723:2455265723(0) ack 5641263win 9112 <mss 536>

24 me.1308 > charli.levels.unisa.edu.au.80: . ack I win 8576

Фактические данные, посылаемые на канальном уровне для транспортировки этих IP-пакетов, будут зависеть от используемой технологии. Они изменяются во время своего путешествия по узлам сети. Путь из Лондона в австралийский город Аделаида имеет 23 транзитных участка. Начало — в портативном компьютере в Глазго с телефонным подключением через модем к поставщику услуг (провайдеру) Claranet Internet Service Provider. Следующий ниже список направляет эти сообщения на Web-сервер в Австралии. Довольно замысловатый маршрут этого путешествия показан на рис. 1.8.

  1.  ftr-rk-35.access.clara.net (195.8.83.35) в Лондоне
  2.  access-fe-0-0-0-banner-starbuck.router.clara.net(195.8.83.128)    в    Лондоне (Claranet)
  3.  ge-5-0-0-banner-bildad.router.clara.net (195.8.68.62) в Лондоне (Claranet)
  4.  atm-6-0-0-telee-peleg.router.clara.net (195.8.68.158) в Лондоне
  5.  fastethernetl-0.1th-icr-02.carrierl .net в Лондоне (Carrierl AG, Цюрих)
  6.  fastethemet4-0-0.lth-bir-01.carrierl.net (212.4.203.209) в Лондоне
  7.  pos!3-0.1on-bbr-02.carrierl.net(212.4.200.121) в Лондоне
  8.  posl3-0.nyc-bbr-02.carrierl.net (213.239.20.254)
  9.  gigabitethernet2-0.nyc-pni-03.carrierl .net (212.4.193.202)
  10.  p4-l.nycmnyl-cr7.bbnplanet.net(4.24.163.17) в Нью-Йорке (BBN Planet) 
  11.  p2-0.nycmnyl-nbrl.bbnplanet.net(4.24.7.1) в Нью-Йорке 
  12.  pl-0.nycmnyl-brl.bbnplanet.net(4.24; 10.82) в Нью-Йорке 
  13.  pl-0.nycmnyl-bal.bbnplanet.net(4.24.6.230) в Нью-Йорке 
  14.  pl-0.xnycl-mci.bbnplanet.net (4.24.7.70) в Нью-Йорке
  15.  acrl-loopback.SantaClara.cw.net (208.172.146.61) в Сан-Франциско (кабель и беспроводная линия)
  16. (208.172.147.210)
  17.  optus-networks.Sydney.cw.net (166.63.225.166) в Сиднее
  18.  GigEthl2-0-0.ia4.optus.net.au (202.139.191.18) в Сиднее (CWO Infrastructure Network)
  19.  SA-RNO-Int.ia4.optus.net.au (202.139.32.206) в Сиднее
  20.  ethernetl.city-east.unisa.gw.saard.net  (203.21.37.110)  в  Аделаиде  (South Australian Academic, Research and Development Network)
  21.  MLgate.levels.unisa.edu.au (130.220.10.2) в Аделаиде (Uni of South Australia)
  22.  MLCamp.levels.unisa.edu.au (130.220.2.106) в Аделаиде
  23.  www.itr.unisa.edu.au (130.220.36.143) в Аделаиде

pic11

Основная работа IP состоит в изоляции верхних уровней от деталей работы сети так, чтобы невозможно было сказать, какие типы передач фактически используются. Начальное соединение выполняется по телефонному проводу с использованием модема и РРР-протокола (протокол "точка—точка", см. разд. 5.9.1), а имена различных компьютеров вдоль маршрута говорят, что используют ATM (см. разд. 5.8.2), быстрый Ethernet (см. разд. "Быстрый Ethernet", гл. 5), гигабитовый Ethernet (см. разд. "Гигабитовый Ethernet, гл. 5) и, почти определенно, — американскую синхронную оптическую сеть SONET (см. разд. 5.8.1). Трафик к Австралии часто проходит через Америку, тогда как имеются много резервных мощностей через Атлантику. Каналы, проходящие через Тихий океан, часто прокладываются через спутник, но данное соединение использует кабель и оптоволоконную линию. Вы можете просматривать маршрут Internet-соединения с помощью программы traceroute (UNIX) или tracert (DOS).

ПечатьE-mail

Яндекс.Метрика