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

Обновлено: 16.05.2024

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

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

Сколько плоскостей предусматривается в эталонной архитектуре Softswitch, разработанной консорциумом IPCC?

(2) Softswitch может получать от сервера приложений информацию, необходимую для выполнения логики услуги

(2) в обеспечении гарантированного и дифференцированного обслуживания сетевого трафика путем передачи контроля за использованием ресурсов и загруженностью сети ее оператору

Какие протоколы в MPLS распространяют по сети информацию о номинальной и незарезервированной (доступной для потоков TE) пропускной способности каждой связи?

Какой уровень позволяет реализовать специфику услуг и применять одну и ту же программу логики услуг вне зависимости от типа транспортной сети и способа доступа?

Как правило, к какому устройству в помещении абонентов подключаются аналоговые телефоны и любые устройства локальной сети Ethernet?

(1) резервирование сетевых ресурсов с целью удовлетворения специфических требований к обслуживанию со стороны потоков трафика

(3) обеспечение связности узлов сети без гарантии времени и самого факта доставки пакета в пункт назначения

(3) возможность применения "масштабируемых" технических решений при минимальной стартовой стоимости оборудования

Какой домен транспортной плоскости поддерживает магистральную сеть и маршрутизацию для транспортировки пакетов через сеть IP-телефонии?

(2) создание сетевой инфраструктуры, которая может стать основой для организации распределенной станции коммутации и платформы для предоставления дополнительных услуг

(2) для описания номинальной пропускной способности среды передачи информации, протокола или соединения

(3) для описания времени, которое требуется устройству на передачу пакета при заданной ширине полосы пропускания

(2) применяется в тех приложениях, в которых несколько источников данных могут отправлять информацию одновременно

(3) применяется в тех приложениях, в которых несколько источников данных не склонно передавать информацию одновременно

(2) передавать от одного BGP-маршрутизатора другим BGP-маршрутизаторам информацию о наличии других автономных сетей и об их структуре

(1) преобразование речевой информации в пакеты IP / ячейки ATM и маршрутизации пакетов IР / ячеек ATM

(3) функции преобразования систем межстанционной сигнализации сети ОКС7 в системы сигнализации пакетной сети

Какая функциональная плоскость управляет основными элементами сети и в первую очередь теми, которые принадлежат транспортной плоскости?

Кто обеспечивает функции по управлению вызовом в случае применения Softswitch в качестве распределенной оконечной станции коммутации?

(2) только отделение друг от друга функций переноса и коммутации, функций управления вызовом и функций управления услугами

Как называется совокупность функций IMS, которые осуществляют все действия по управлению сеансами связи?

(1) терминальные устройства, используемые для предоставления мультимедийных услуг связи и предназначенные для работы в пакетных сетях

(2) терминальные устройства, используемые для предоставления голосовых услуг и предназначенные для работы в сетях с КК

(3) терминальные устройства, используемые для предоставления голосовых и мультимедийных услуг связи и предназначенные для работы в пакетных сетях

(4) терминальные устройства, используемые для предоставления голосовых и мультимедийных услуг связи и предназначенные для работы в сетях с КК

Какая функциональная плоскость содержит логику выполнения услуг и/или приложений в сети и управляет этими услугами путем взаимодействия с устройствами, находящимися в других плоскостях?

Эта статья о протоколах, составляющих архитектуру Интернета. Только для сетевого протокола IP см. Протокол Интернета .

Набор протоколов Интернета - это концептуальная модель и набор протоколов связи, используемых в Интернете и подобных компьютерных сетях . Он широко известен как TCP / IP, потому что основными протоколами в наборе являются протокол управления передачей (TCP) и Интернет-протокол (IP). В ходе своего развития, версии его были известны как министерства обороны ( МО ) модель , так как развитие метода сетевого финансировались Министерством обороны США через DARPA. Его реализация представляет собой стек протоколов .

Набор интернет-протоколов обеспечивает сквозную передачу данных, определяющую, как данные должны быть пакетированы, адресованы, переданы, маршрутизированы и получены. Эта функциональность организована в четыре уровня абстракции , которые классифицируют все связанные протоколы в соответствии с областью задействованной сети. [1] [2] Уровни от самого низкого до самого высокого являются канальным уровнем , содержащим методы передачи данных, которые остаются в пределах одного сетевого сегмента (ссылки); уровень Интернета , обеспечивающий межсетевое взаимодействие между независимыми сетями; транспортный уровень , обработки хост-хост связи; иприкладной уровень , обеспечивающий межпроцессный обмен данными для приложений.

В технические стандарты , лежащие в основе набора протоколов Интернет и его составные протоколы поддерживается Engineering Task Force Internet (IETF). Набор Интернет-протоколов предшествовал модели OSI , более всеобъемлющей эталонной структуре для общих сетевых систем.

СОДЕРЖАНИЕ

  • 1 История
    • 1.1 Ранние исследования
    • 1.2 Ранняя реализация
    • 1.3 Принятие
    • 1.4 Официальные спецификации и стандарты

    Пакет Интернет-протокола явился результатом исследований и разработок, проведенных Агентством перспективных исследовательских проектов Министерства обороны США ( DARPA ) в конце 1960-х годов. [3] После создания новаторской ARPANET в 1969 году DARPA начало работу над рядом других технологий передачи данных. В 1972 году Роберт Э. Кан присоединился к Отделу технологий обработки информации DARPA , где он работал как над спутниковыми пакетными сетями, так и над наземными пакетными сетями радиосвязи, и осознал ценность возможности связи между ними. Весной 1973 года Винтон Серф , который помогал разработать существующий протокол программы управления сетью ARPANET (NCP), присоединился к Кану для работы надмодели взаимодействия с открытой архитектурой с целью разработки следующего поколения протоколов для ARPANET. [ необходима цитата ] Они основывались на опыте исследовательского сообщества ARPANET и Международной сетевой рабочей группы , которую возглавлял Серф. [4]

    К лету 1973 года Кан и Серф разработали фундаментальную переформулировку, в которой различия между протоколами локальной сети были скрыты за счет использования общего межсетевого протокола , и вместо того, чтобы сеть отвечала за надежность, как в существующих протоколах ARPANET , эта функция была делегирована хостам. Серф благодарит Юбера Циммермана и Луи Пузена , дизайнера сети CYCLADES , которые оказали большое влияние на этот дизайн. [5] [6] Новый протокол был реализован как Программа управления передачей в 1974 году. [7]

    DARPA заключило контракт с BBN Technologies , Стэнфордским университетом и Университетским колледжем Лондона на разработку операционных версий протокола на нескольких аппаратных платформах. [13] В процессе разработки протокола номер версии уровня маршрутизации пакетов увеличился с версии 1 до версии 4, последняя из которых была установлена ​​в ARPANET в 1983 году. В качестве протокола он стал известен как Интернет-протокол версии 4 (IPv4). который до сих пор используется в Интернете вместе с его нынешним преемником, Internet Protocol версии 6 (IPv6).

    В 1975 году между Стэнфордом и Университетским колледжем Лондона был проведен тест связи TCP / IP с двумя сетями. В ноябре 1977 г. был проведен тест TCP / IP для трех сетей между узлами в США, Великобритании и Норвегии. Несколько других прототипов TCP / IP были разработаны в нескольких исследовательских центрах между 1978 и 1983 годами.

    Компьютер, называемый маршрутизатором, имеет интерфейс для каждой сети. Он пересылает сетевые пакеты туда и обратно между ними. [14] Первоначально маршрутизатор назывался шлюзом , но этот термин был изменен, чтобы избежать путаницы с другими типами шлюзов . [15]

    В марте 1982 года Министерство обороны США объявило TCP / IP стандартом для всех военных компьютерных сетей. [16] В том же году НОРСАР и исследовательская группа Питера Кирстайна в Университетском колледже Лондона приняли протокол. [13] [17] [18] Переход ARPANET на TCP / IP был официально завершен в день флага 1 января 1983 г., когда новые протоколы были окончательно активированы. [19]

    В 1985 году Консультативный совет Интернета (позже Совет по архитектуре Интернета ) провел трехдневный семинар по TCP / IP для компьютерной индустрии, на котором присутствовало 250 представителей поставщиков, которые продвигали протокол и привели к его расширению коммерческого использования. В 1985 году первая конференция Interop была посвящена сетевой совместимости за счет более широкого внедрения TCP / IP. Конференция была основана Дэном Линчем, одним из первых активистов Интернета. С самого начала на встрече присутствовали крупные корпорации, такие как IBM и DEC. [20]

    IBM, AT&T и DEC были первыми крупными корпорациями, принявшими TCP / IP, несмотря на наличие конкурирующих проприетарных протоколов . В IBM с 1984 года разработкой TCP / IP занималась группа Барри Аппельмана . Они сориентировались в корпоративной политике, чтобы получить поток продуктов TCP / IP для различных систем IBM, включая MVS , VM и OS / 2 . В то же время несколько небольших компаний, таких как FTP Software и Wollongong Group , начали предлагать стеки TCP / IP для DOS и Microsoft Windows . [21] Первый стек TCP / IP VM / CMS был разработан Университетом Висконсина. [22]

    Некоторые из ранних стеков TCP / IP были написаны в одиночку несколькими программистами. Джей Элински и Олег Вишнепольский [ ru ] из IBM Research написали стеки TCP / IP для VM / CMS и OS / 2 соответственно. [ необходима цитата ] В 1984 году Дональд Гиллис из Массачусетского технологического института написал протокол TCP с несколькими подключениями ntcp, который работал поверх уровня IP / PacketDriver, поддерживаемого Джоном Ромки из Массачусетского технологического института в 1983–1994 годах. Ромки использовал этот протокол TCP в 1986 году, когда была основана компания FTP Software. [23] [24] Начиная с 1985 года Фил Карн создал приложение TCP с несколькими подключениями для систем любительской радиосвязи (KA9Q TCP). [25]

    Распространение TCP / IP получило дальнейшее развитие в июне 1989 года, когда Калифорнийский университет в Беркли согласился передать код TCP / IP, разработанный для BSD UNIX, в общественное достояние. Различные корпоративные поставщики, включая IBM, включили этот код в коммерческие выпуски программного обеспечения TCP / IP. Microsoft выпустила / стек нативный TCP IP в Windows 95. Это событие доминирование помогло цементного TCP / IP над другими протоколами в сетях Microsoft на базе, в которую вошли компании IBM Systems Network Architecture (SNA), так и на других платформах , таких как Digital Equipment Corporation «с DECnet , взаимодействие открытых систем (OSI) и Xerox Network Systems (XNS).

    Тем не менее, в течение периода в конце 1980-х - начале 1990-х инженеры, организации и нации были поляризованы по вопросу о том, какой стандарт , модель OSI или набор протоколов Интернета приведут к созданию лучших и наиболее надежных компьютерных сетей. [26] [27] [28]

    В технические стандарты , лежащие в основе набора протоколов Internet и его составляющие протоколы были делегированы Engineering Task Force Интернет (IETF).

    Характерной архитектурой Internet Protocol Suite является его широкое разделение на рабочие области для протоколов, составляющих его основную функциональность. Определяющей спецификацией пакета является RFC 1122, который в общих чертах описывает четыре уровня абстракции . [1] Они выдержали испытание временем, поскольку IETF никогда не изменяла эту структуру. Как такая модель сети, Internet Protocol Suite предшествует модели OSI, более всеобъемлющей эталонной структуре для общих сетевых систем.

    Принцип конца до конца развивался с течением времени. Его первоначальное выражение ставило поддержание состояния и общего интеллекта на грани и предполагало, что Интернет, соединяющий грани, не сохраняет состояния и сосредоточен на скорости и простоте. Реальные потребности в брандмауэрах, трансляторах сетевых адресов, кэшах веб-контента и т. П. Вызвали изменения в этом принципе. [29]

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

    Протоколы канального уровня работают в рамках локального сетевого подключения, к которому подключен хост. Этот режим на языке TCP / IP называется каналом и представляет собой самый нижний компонентный уровень пакета. Ссылка включает все хосты, доступные без прохождения через маршрутизатор. Таким образом, размер канала определяется конструкцией сетевого оборудования. В принципе, TCP / IP разработан как независимый от оборудования и может быть реализован поверх практически любой технологии канального уровня. Это включает не только аппаратные реализации, но и уровни виртуальных каналов, такие как виртуальные частные сети и сетевые туннели .

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

    Канальный уровень в модели TCP / IP имеет соответствующие функции на уровне 2 модели OSI.

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

    Интернет-уровень не делает различий между различными протоколами транспортного уровня. IP передает данные для множества различных протоколов верхнего уровня . Каждый из этих протоколов идентифицируется уникальным номером протокола : например, Internet Control Message Protocol (ICMP) и Internet Group Management Protocol (IGMP) - это протоколы 1 и 2, соответственно.

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

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

    TCP - это протокол с установлением соединения, который решает многочисленные проблемы надежности при обеспечении надежного потока байтов :

    • данные поступают по порядку
    • данные имеют минимальную ошибку (т.е. правильность)
    • повторяющиеся данные отбрасываются
    • потерянные или отброшенные пакеты повторно отправляются
    • включает контроль заторов на дорогах

    Надежность также может быть достигнута за счет использования IP по надежному протоколу передачи данных, например, высокоуровневому управлению каналом передачи данных (HDLC).

    Приложения на любом заданном сетевом адресе различаются по TCP или UDP-порту. По соглашению, некоторые хорошо известные порты связаны с конкретными приложениями.

    Транспортный уровень модели TCP / IP или уровень хост-хост примерно соответствует четвертому уровню в модели OSI, также называемому транспортным уровнем.

    Модель TCP / IP не учитывает специфику форматирования и представления данных и не определяет дополнительные уровни между прикладным и транспортным уровнями, как в модели OSI (уровни представления и сеанса). Согласно модели TCP / IP, такие функции являются областью библиотек и интерфейсов прикладного программирования .

    Протоколы прикладного уровня часто связаны с конкретными клиент-серверными приложениями, а общие службы имеют хорошо известные номера портов, зарезервированные Internet Assigned Numbers Authority (IANA). Например, протокол передачи гипертекста использует порт сервера 80, а Telnet использует порт сервера 23. Клиенты, подключающиеся к службе, обычно используют временные порты., т. е. номера портов, назначаемые только на время транзакции случайным образом или из определенного диапазона, настроенного в приложении. Хотя приложения обычно осведомлены о ключевых качествах соединения транспортного уровня, таких как IP-адреса конечных точек и номера портов, протоколы прикладного уровня обычно рассматривают протоколы транспортного уровня (и более низких уровней) как черные ящики, которые обеспечивают стабильное сетевое соединение, через которое общаться.

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

    Прикладной уровень в модели TCP / IP часто сравнивают как эквивалент комбинации пятого (сеанс), шестого (презентация) и седьмого (приложение) уровней модели OSI.

    Кроме того, модель TCP / IP различает пользовательские протоколы и протоколы поддержки . [35] Протоколы поддержки предоставляют услуги системе сетевой инфраструктуры. Пользовательские протоколы используются для реальных пользовательских приложений. Например, FTP - это протокол пользователя, а DNS - протокол поддержки.

    В следующей таблице показаны различные сетевые модели. Количество слоев варьируется от трех до семи.

    Некоторые сетевые модели взяты из учебников, которые являются вторичными источниками, которые могут противоречить цели RFC 1122 и других первичных источников IETF . [43]

    Три верхних уровня в модели OSI, т. Е. Прикладной уровень, уровень представления и уровень сеанса, не различаются отдельно в модели TCP / IP, которая имеет только прикладной уровень над транспортным уровнем. Хотя некоторые приложения с чистым протоколом OSI, такие как X.400 , также комбинируют их, нет требования, чтобы стек протоколов TCP / IP налагал монолитную архитектуру над транспортным уровнем. Например, протокол приложения NFS работает поверх протокола представления внешних данных (XDR), который, в свою очередь, работает через протокол, называемый удаленным вызовом процедур (RPC). RPC обеспечивает надежную передачу записей, поэтому может безопасно использовать максимально эффективный транспорт UDP.

    Различные авторы интерпретировали модель TCP / IP по-разному и расходятся во мнениях относительно того, покрывает ли канальный уровень или вся модель TCP / IP проблемы уровня 1 OSI ( физического уровня ), или же аппаратный уровень предполагается ниже канального уровня.

    Несколько авторов попытались включить уровни 1 и 2 модели OSI в модель TCP / IP, поскольку они обычно упоминаются в современных стандартах (например, IEEE и ITU ). Это часто приводит к модели с пятью уровнями, где уровень канала или уровень доступа к сети разделен на уровни 1 и 2 модели OSI.

    Протоколы IETF могут быть рекурсивно инкапсулированы, что демонстрируется протоколами туннелирования, такими как Generic Routing Encapsulation (GRE). GRE использует тот же механизм, который OSI использует для туннелирования на сетевом уровне.

    Прикладных программистов обычно интересуют только интерфейсы на прикладном уровне, а часто и на транспортном уровне, в то время как нижележащие уровни представляют собой услуги, предоставляемые стеком TCP / IP в операционной системе. Большинство реализаций IP доступны программистам через сокеты и API .

    Уникальные реализации включают облегченный TCP / IP , стек с открытым исходным кодом , разработанный для встраиваемых систем , и KA9Q NOS , стек и связанные протоколы для любительских систем пакетной радиосвязи и персональных компьютеров, подключенных через последовательные линии.

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


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

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

    Блок данных транспортного уровня называется сегментом (segment), либо дейтаграммой

    Блок данных сетевого уровня называется пакетом (packet). Блок данных канального уровня называется кадром (frame). Единица данных физического уровня – бит (bit).

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

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

    привела к возможности независимой разработки оборудования и программного обеспечения, к независимости разработчиков ПО от производителей оборудования и наоборот.

    Теперь перейдем к рассмотрению протоколов.

    Ясно, что на каждом уровне функционирует свой протокол. Следовательно, для обеспечения передачи информации, эти протоколы должны быть соответствующим образом согласованы друг с другом, то есть, нужно рассматривать не каждый протокол в отдельности, а некий набор взаимодействующих протоколов. Для таких наборов существует свое определение – стек протоколов. (CCNA1 2.3.x.x)

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

    В качестве примеров стеков протоколов можно привести стеки TCP/IP, IPX/SPX, NetBIOS/SMB. Примерами базовых сетевых технологий могут являться технологии Ethernet, PPP, Frame Relay, ATM и многие другие. В этом курсе мы с вами займемся рассмотрением базовых сетевых технологий локальных сетей, но предварительно обзорно рассмотрим некоторые популярные стеки протоколов.

    Начнем со стека протоколов TCP/IP. (CCNA1 2.4.3.x, 2.4.8.x)

    коммутацией пакетов, обеспечивающей обмен данными между разнородными вычислительными системами, установленными в исследовательских институтах. Для разработки обеспечения связи между неоднородными сетями DARPA финансировало исследования Стэндфордского университета, а так же компании Bolt, Beranek and Newman (BBN). Результатом этих исследований стал набор протоколов Internet.

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

    Значительный вклад в развитие стека TCP/IP внес университет Беркли, реализовав протоколы стека в своей версии ОС UNIX. Широкое распространение ОС UNIX привело и к широкому распространению протокола IP и других протоколов стека. На этом же стеке работает глобальная сеть Internet.

    Чем же можно объяснить широкое распространение и лидирующую роль стека TCP/IP?

    В первую очередь, это объясняется следующими его свойствами:

    9 это наиболее завершенный стандартный стек сетевых протоколов, имеющий многолетнюю

    9 этот стек представляет собой набор открытых стандартов, которые могут быть свободно

    использованы любым разработчиком;

    9 практически все сети передают основную часть своего трафика с помощью протокола

    TCP/IP, кроме того, это метод получения доступа к самой большой глобальной сети – Internet, то есть, этот стек является стандартом де-факто;

    9 все современные операционные системы поддерживают стек TCP/IP.

    Так как стек TCP/IP был разработан до появления модели OSI, то, хотя он также имеет многоуровневую структуру, соответствие уровней стека TCP/IP уровням модели OSI достаточно условно (не в последнюю очередь потому, что количество уровней в моделях различается) и в разных источниках может быть представлено по-разному.


    Протоколы TCP/IP делятся на 4 уровня.

    Самый нижний, четвертый уровень, условно соответствует физическому и канальному уровням модели OSI. Этот уровень в протоколах TCP/IP не регламентируется, но поддерживает все популярные стандарты физического и канального уровня, другими словами – любую Базовую Сетевую Технологию. Обычно при появлении новой технологии локальных или глобальных сетей она быстро включается в стек TCP/IP за счет разработки соответствующего RFC, определяющего метод инкапсуляции пакетов IP в ее кадры. Существует также мнение, что этот уровень можно ассоциировать с интерфейсом между вторым и третьим уровнем модели OSI, то есть, с единственным стандартизованным интерфейсом. На самом деле, в зависимости от точки зрения, оба взгляда можно считать верными, поскольку вопрос соответствия уровней – в значительной степени терминологический.

    доставку пакетов до узла назначения, но старается это сделать (этот метод доставки называется

    Далее давайте составим графическое представление различных версий проекций уровней модели TCP/IP на уровни модели OSI.




    Также может существовать модификация проекции, при которой уровень сетевых интерфейсов модели TCP/IP будет соответствовать интерфейсу между вторым и третьим уровнями модели OSI:

    Теперь рассмотрим следующий стек протоколов, который в свое время занимал доминирующее положение среди остальных. Это стек IPX/SPX.

    Этот стек является оригинальным стеком протоколов фирмы Novell, который она разработала для своей сетевой операционной системы NetWare еще в начале 80-х годов. Протоколы Internetwork Packet Exchange (IPX) и Sequenced Packet Exchange (SPX), которые дали имя стеку, являются прямой адаптацией протоколов XNS фирмы Xerox, которые были распространены в гораздо меньше степени, чем IPX/SPX. В 80-е годы и в начале 90-х протоколы IPX/SPX лидировали по количеству установок. Это было обусловлено тем, что сама ОС Novell NetWare занимала лидирующее положение с долей установок в мировом масштабе превышавшей

    80%. В связи с тем, что стек IPX/SPX являлся проприетарным (собственностью разработчика) его использование сторонними разработчиками было ограничено и от разработчиков требовалось приобретение лицензии. В это время на рынок вышел мощный конкурент – стек TCP/IP, который кроме открытости стандартов обладал еще рядом преимуществ, и популярность стека IPX/SPX пошла на убыль. В настоящее время этот стек практически не используется.

    Семейство протоколов фирмы Novell и их соответствие модели OSI представлено на рисунке.


    На верхнем уровне, соответствующем прикладному, представительному и сеансовому уровням OSI, работают протоколы NCP и SAP. Протокол NCP (NetWare Core Protocol) является протоколом взаимодействия сервера NetWare и оболочки рабочей станции.

    C помощью этого протокола рабочая станция производит подключение к серверу, отображает каталоги сервера на локальные буквы дисководов, просматривает файловую систему сервера, копирует удаленные файлы, изменяет их атрибуты и т.п., а также осуществляет разделение сетевого принтера между рабочими станциями. SAP (Service Advertising Protocol) – протокол объявления о сервисе – дает возможность сетевым устройствам обмениваться информацией об имеющихся сетевых сервисах. Серверы и маршрутизаторы используют SAP для объявления о своих сервисных услугах и сетевых адресах. Протокол SAP позволяет сетевым устройствам постоянно корректировать данные о том, какие сервисные услуги имеются сейчас в сети. При старте серверы используют SAP для оповещения оставшейся части сети о своих услугах. Когда сервер завершает работу, то он использует SAP для того, чтобы известить сеть о прекращении действия своих услуг.

    Особенности стека IPX/SPX обусловлены особенностями ОС NetWare, а именно ориентацией ее ранних версий (до 4.0) на работу в локальных сетях небольших размеров, состоящих из персональных компьютеров со скромными ресурсами. Поэтому Novell нужны были протоколы, на реализацию которых требовалось минимальное количество оперативной памяти (ограниченной в IBM-совместимых компьютерах под управлением MS-DOS 640 Кбайтами) и которые бы быстро работали на процессорах небольшой вычислительной мощности. В результате, ранние протоколы стека IPX/SPX хорошо работали в небольших локальных сетях, и значительно хуже – в глобальных сетях, так как слишком перегружали медленные связи широковещательными пакетами, которые интенсивно используются несколькими протоколами этого стека (например, для установления связи между клиентами и серверами). Этот недостаток стека также повлиял на его распространенность наряду с необходимостью получения лицензии на использование.

    Перейдем к рассмотрению следующего популярного стека, который продолжает использоваться в наше время.

    Стек NetBIOS/SMB появился в 1984 г., благодаря разработкам фирмы IBM, которая спустя три года после выпуска первого компьютера IBM PC, в целях расширения стандартных функций базовой системы ввода/вывода (BIOS) разработала программный интерфейс (API) NetBIOS – Network Basic Input/Output System. Это расширение применялось для взаимодействия между сетевыми ресурсами, но не предусматривало низкоуровневого протокола для передачи данных по сети. Такой протокол появился в 1985 г. и был объединен с NetBIOS в связке NetBEUI (NetBIOS Extended User Interface).

    NetBEUI создавался в расчете на небольшие рабочие группы (до 255 узлов) и не имел функций маршрутизации.

    Протокол SMB используется в операционных системах Windows. Он является проприетарным (закрытым) стандартом, и Microsoft предоставляет спецификации SMB только сертифицированным партнерам. SMB постоянно дорабатывается (обновления выходят с каждой новой версией Windows).

    Стек NetBIOS/SMB и его проекцию на модель OSI можно изобразить так:


    Протокол NetBIOS работает на двух уровнях модели OSI: транспортном и сеансовом. NetBIOS может обеспечить сервис более высокого уровня, чем протоколы IPX и SPX, однако не обладает способностью к маршрутизации. NetBIOS не относится к сетевым протоколам в строгом смысле этого слова, хотя и содержит много полезных сетевых функций, которые можно отнести к сетевому уровню. Однако с его помощью невозможна маршрутизация пакетов, так как в протоколе обмена кадрами NetBIOS не вводится такое понятие как сеть.

    Протокол SMB, соответствующий прикладному и представительному уровням модели OSI, регламентирует взаимодействие рабочей станции с сервером. В функции SMB входят следующие операции:

    9 Управление сессиями. Создание и разрыв логического канала между рабочей станцией и сетевыми ресурсами файлового сервера.

    9 Файловый доступ. Рабочая станция может обратиться к файл-серверу с запросами на

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

    9 Сервис печати. Рабочая станция может ставить файлы в очередь для печати на сервере и

    получать информацию об очереди печати.

    Несмотря на коммерческий статус протокола SMB, существует свободно распространяемый программный пакет Samba, обеспечивающий ограниченную поддержку сервисов SMB для ОС Unix/Linux. Поскольку основными протоколами Unix-систем являются протоколы стека TPC/IP, то в Samba для совместимости применяется NetBIOS over TCP/IP.

    Автора: © Виталий Бочаров, Владимир Недеркин, Александр Трофимов

    image_print

    Этот документ содержит спецификацию стандарта DoD 1 для протокола Internet (IP 2 ). Документ основан на 6 предварительных вариантах спецификации протокола ARPA Internet и содержит фрагменты этих спецификаций. В разработке используемых в документе концепций и терминологии принимало участие множество людей. В данной редакции пересмотрены вопросы адресации, обработки ошибок, кодирования опций, приоритетов, изоляции (compartments) и ограничений протокола Internet.

    Jon Postel,

    редактор

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

    Термин gateway (шлюз) в исходном документе использовался для обозначения устройств, которые сегодня называют маршрутизаторами (router), а термином шлюз сегодня обозначают обычно устройства (программы), обеспечивающие преобразование протоколов на более высоких уровнях модели ISO/OSI (например, почтовые шлюзы).

    Николай Малых,

    переводчик

    Исключено в версии HTML.

    1. Введение

    1.1. Мотивация

    Протокол IP предназначен для использования в соединенных между собой компьютерных сетях обмена данными на основе коммутации пакетов. Такие системы получили название catenet [1]. Протокол обеспечивает передачу блоков данных, называемых дейтаграммами, между отправителем и получателем, хосты которых идентифицируются адресами фиксированного размера. Протокол также обеспечивает фрагментацию и сборку дейтаграмм большого размера, если сеть не позволяет передать дейтаграмму целиком.

    1.2. Сфера действия протокола

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

    1.3. Интерфейсы

    Этот протокол вызывается протоколами взаимодействия “хост-хост” 3 и сам вызывает функции локальных сетевых протоколов 4 для передачи дейтаграмм следующему маршрутизатору или хосту-получателю.

    Например, модуль TCP будет вызывать модуль IP для размещения сегмента TCP (заголовок TCP и пользовательские данные) в качестве объекта данных дейтаграммы IP. Модуль TCP будет указывать адреса и другие параметры заголовка IP в качестве аргументов при вызове функции IP. Модуль IP будет создавать дейтаграмму IP и обращаться к локальному сетевому интерфейсу 5 для передачи дейтаграммы.

    1.4. Работа протокола

    Протокол IP выполняет две основных функции – адресацию и фрагментацию/сборку дейтаграмм.

    Модули IP используют адреса из заголовков IP для передачи дейтаграмм в направлении получателя. Процесс выбора пути к адресату называется маршрутизацией.

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

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

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

    Для обеспечения сервиса протокол IP использует 4 ключевых механизма – ToS (тип обслуживания), TTL (время жизни), Options (опции) и Header Checksum (контрольная сумма заголовка).

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

    Время жизни TTL определяет максимальный срок существования дейтаграмм IP. Это значение устанавливается отправителем и уменьшается в каждой точке на пути доставки, где дейтаграмма подвергается обработке. Если значение TTL становится нулевым до того, как дейтаграмма будет доставлена адресату, такая дейтаграмма просто уничтожается. Можно рассматривать TTL как время саморазрушения дейтаграмм.

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

    Контрольная сумма заголовка обеспечивает возможность проверки корректности передачи дейтаграмм IP. Если при передаче дейтаграмма была повреждена и вычисленная заново при обработке контрольная сумма не совпадет с содержащимся в дейтаграмме значением контрольной суммы, такая дейтаграмма отбрасывается как ошибочная.

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

    При обнаружении ошибок информация о них может передаваться с помощью протокола ICMP (Internet Control Message Protocol) [3], реализуемого в модуле IP.

    2. Обзор

    2.1. Связь с другими протоколами

    Рисунок 1. Связь с другими протоколами.

    На рисунке 1 показаны связи IP с другими протоколами.

    Протокол IP взаимодействует с протоколом вышележащего уровня (протокол взаимодействия между хостами 6 ) и с нижележащим протоколом локальной сети 7 (в этом контексте локальной сетью может считаться небольшая сеть в одном здании или распределенная сеть типа ARPANET).

    2.2. Модель работы протокола

    Модель передачи дейтаграмм от одной прикладной программы к другой можно проиллюстрировать описанным ниже сценарием.

    Будем предполагать, что передача включает лишь один промежуточный шлюз.

    Передающая программа готовит свои данные и вызывает локальный модуль IP для передачи этих данных как дейтаграммы, указывая адрес получателя и другие параметры в качестве аргументов.

    Модуль IP готовит заголовок дейтаграммы и присоединяет к нему данные. После этого модуль IP определяет локальный сетевой адрес для указанного получателя (в данном случае это адрес шлюза).

    Модуль передает дейтаграмму и локальный адрес локальному сетевому интерфейсу 8 .

    Интерфейс канального уровня создает заголовок и присоединяет к нему дейтаграмму IP, после чего пакет передается в локальную сеть.

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

    Интерфейс канального уровня создает заголовок и, добавив к нему дейтаграмму, передает пакет хосту-адресату.

    На хосте получателя дейтаграмма выделяется из пакета интерфейсом канального уровня и передается модулю IP.

    Модуль IP определяет по заголовку, что дейтаграмма адресована приложению на данном хосте и передает программе данные из дейтаграммы вместе с адресом отправителя и другими параметрами в ответ на системный вызов.

    Рисунок 2. Путь передачи данных.


    2.3. Функциональное описание

    Задачей протокола IP является перемещение дейтаграмм через множество соединенных между собою сетей. Эта задача решается путем передачи дейтаграмм от одного модуля IP к другому, пока дейтаграмма не будет доставлена адресату. Модули IP размещаются на хостах и шлюзах (маршрутизаторах) Internet. Дейтаграммы маршрутизируются от одного модуля IP к другому через промежуточные сети на основе интерпретации адресов IP. Таким образом, одним из важнейших механизмов IP является адресация.

    Адресация

    Следует различать имена, адреса и маршруты [4]. Имя указывает объект, адрес показывает местонахождение объекта, а маршрут говорит, как до него добраться. Протокол IP имеет дело преимущественно с адресами. Отображение адресов на имена и обратно (преобразование) является задачей протоколов более высоких уровней (т. е., транспортного и сеансового 9 ). Модуль IP преобразует адреса IP в адреса локальной сети. Отображение адресов локальной сети на маршруты является задачей процедур нижележащего уровня (т. е.. локальной сети или шлюзов) 10 .

    Адреса IP имеют фиксированную длину – 4 октета (32 бита). Адрес начинается с номера сети, за которым следует локальный адрес 11 (его называют полем rest – остаток). Существует три класса адресов IP – класс A, в котором старший бит имеет значение 0, остальные 7 битов старшего октета задают номер сети, а 24 младших бита – номер хоста, класс B, в котором два старших бита имеют значения 10, следующие 14 битов определяют номер сети, а последние 16 битов – номер хоста и класс C, в котором три старших бита имеют значения 110, следующие 21 – образуют номер сети, а последние 8 битов определяют номер хоста 12 .

    Следует с осторожностью относиться к преобразованию адресов IP в адреса локальной сети, поскольку один физический хост может функционировать как несколько различных хостов, использующих разные адреса IP. Некоторые хосты могут использовать множество физических интерфейсов (многодомные хосты – multi-homing).

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

    Фрагментация

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

    Допускается использование невидимой для модуля IP фрагментации 13 , передачи и сборки дейтаграмм в локальной сети [6].

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

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

    Эту процедуру легко обобщить на случай разбиения дейтаграммы на n фрагментов, где n > 2.

    Рисунок 3. Протоколы шлюзов.

    Для сборки фрагментов дейтаграммы модуль IP (например, на хосте адресата) объединяет дейтаграммы IP с совпадающими значениями полей идентификации, адресов отправителя и получателя, а также протокола. Объединение осуществляется путем размещения данных из каждой дейтаграммы в позицию буфера, указанную полем смещения фрагмента в заголовке IP. Первый фрагмент будет иметь нулевое смещение, а для последнего фрагмента флаг more-fragments будет иметь нулевое значение.

    2.4. Шлюзы

    Шлюзы 16 выполняют пересылку дейтаграмм IP между сетями, обеспечивая также поддержку протокола GGP 17 [7] для обмена данными маршрутизации и другой управляющей информацией.

    В шлюзах реализация протоколов вышележащих уровней не обязательна и функции GGP могут быть реализованы в модуле IP.

    3. Спецификация

    3.1. Формат заголовка

    Рисунок 4. Формат заголовка дейтаграммы IP.


    Формат з аголовка дейтаграмм IP показан на рисунке 4.

    Version – 4 бита

    Указывает номер версии протокола и определяет формат заголовка. Данная спецификация описывает версию 4 18 .

    IHL 19 – 4 бита

    Это поле содержит размер заголовка IP в 32-битовых словах и указывает начало данных в пакете. Отметим, что минимальное значение этого поля для корректного заголовка составляет 5.

    ToS 20 – 8 битов

    Поле ToS 21 обеспечивает индикацию абстрактных параметров желаемого качества обслуживания. Это значение используется при выборе реальных параметров обслуживания в процессе передачи дейтаграммы через отдельную сеть. Некоторые сети предлагают приоритетный сервис, который тем или иным способом трактует трафик с большим уровнем предпочтения как более важный, нежели трафик другого типа (обычно при высокой загрузке просто воспринимается только трафик с уровнем предпочтения выше некоторого порога). Основной выбор осуществляется между тремя вариантами – малая задержка, высокая надежность, высокая пропускная способность.

    биты 0-2: предпочтения.

    бит 3: 0 = обычная задержка, 1 = малая задержка.

    бит 4: 0 = обычная пропускная способность, 1 = высокая пропускная способность.

    бит 5: 0 = обычная надежность, 1 = высокая надежность.

    Биты 6-7: зарезервированы для использования в будущем.

    111 – управление сетью

    110 – межсетевое управление

    Использование флагов Delay (D), Throughput (T), Reliability 22 (R) может увеличивать стоимость обслуживания (в том или ином смысле). Во многих сетях предпочтение по одному из этих параметров может быть связано с потерями по другому. За исключением специальных случаев следует использовать не более двух флагов из трех возможных.

    Значение ToS служит для задания способа обработки дейтаграмм в процессе их передачи через internet. Например, отображение значений ToS на реальные параметры обслуживания в сетях AUTODIN II, ARPANET, SATNET, PRNET описано в работе Service Mappings [8].

    Уровень предпочтения Network Control (управление сетью) означает, что дейтаграмма предназначена для использования внутри сети. Реальная трактовка этого обозначения определяется местными условиями сети. Значение Internetwork Control (межсетевое управление) показывает дейтаграммы, предназначенные только для управления шлюзами. Если та или иная сеть использует значение уровня предпочтения, она берет на себя ответственность за доступ к этому полю и его использование.

    Total Length – 16 битов

    Это поле указывает общий размер (в октетах) дейтаграммы с учетом заголовка и данных. Размер этого поля позволяет создавать дейтаграммы размером до 65 535 октетов. Столь большие дейтаграммы неприемлемы для большинства хостов и сетей. Все хосты должны быть готовы к восприятию дейтаграмм размером до 576 октетов (целиком или в виде фрагментов). Хостам рекомендуется передавать дейтаграммы, размер которых превышает 576 октетов, только в тех случаях, когда есть уверенность, что адресат может принимать такие дейтаграммы.

    Значение 576 выбрано для того, чтобы дейтаграммы могли кроме заголовка содержать блок данных разумного размера. Например, такой размер позволяет передавать блок данных в 512 октетов с 64-октетным заголовком. Максимальный размер заголовка IP составляет 60 октетов, а размер типичного заголовка IP – 20 октетов, что оставляет достаточно места для заголовков вышележащих уровней.

    Identification – 16 битов

    Значение поля идентификации присваивается отправителем для обеспечения корректной сборки фрагментов дейтаграммы.

    Читайте также: