Власть, над которой безнаказанно глумятся, близка к гибели.

Дед мороз пролетая над бедными африканскими странами видит голодных негретят, ...

Релиз десктоп-окружения Trinity R14.0.5, продолжающего развитие KDE 3.5
Sat, 18 Aug 2018 19:59:09 +0300

Microsoft Research открыл код быстрого хранилища в формате ключ/значение
Sat, 18 Aug 2018 12:04:32 +0300

Выпуск Wine 3.14
Sat, 18 Aug 2018 11:11:42 +0300

Lubuntu переходит на Wayland
Fri, 17 Aug 2018 13:17:30 +0300

Компания Mozilla заблокировала 23 дополнения, отсылающих данные о посещениях
Fri, 17 Aug 2018 12:36:21 +0300

Выпуск KDE Applications 18.08
Thu, 16 Aug 2018 20:48:39 +0300

Выпуск браузера Pale Moon 28.0
Thu, 16 Aug 2018 18:57:52 +0300

Дополнение из состава 3D-фреймворка Verge3D опубликовано под свободной лицензией
Thu, 16 Aug 2018 11:56:06 +0300

В Firefox-дополнении Web Security выявлена отправка информации о посещениях
Thu, 16 Aug 2018 08:41:01 +0300

Уязвимость в OpenSSH, позволяющая определить наличие пользователей
Thu, 16 Aug 2018 08:04:45 +0300

Debian GNU/Linux исполнилось 25 лет
Thu, 16 Aug 2018 07:51:55 +0300

Выявлены следы работы Valve над инструментарием для запуска Windows игр в Linux
Thu, 16 Aug 2018 07:42:23 +0300

Выявлен ещё один метод удалённой DoS-атаки на ядро Linux и FreeBSD
Wed, 15 Aug 2018 13:26:03 +0300

Релиз системы виртуализации VirtualBox 5.2.18
Wed, 15 Aug 2018 12:45:58 +0300

Релиз эмулятора QEMU 3.0
Wed, 15 Aug 2018 09:55:14 +0300

L1TF - три новые уязвимости в механизме спекулятивного выполнения CPU Intel
Tue, 14 Aug 2018 23:07:47 +0300

47 уязвимостей в Android-прошивках и новый вид атак Man-in-the-Disk
Tue, 14 Aug 2018 20:44:09 +0300

Обновление Samba 4.8.4, 4.7.9 и 4.6.16 с устранением уязвимостей
Tue, 14 Aug 2018 20:22:28 +0300

Новый стабильный релиз открытой биллинговой системы Ubilling 0.9.1
Tue, 14 Aug 2018 14:36:18 +0300

Релиз профессионального видеоредактора DaVinci Resolve 15
Mon, 13 Aug 2018 23:46:51 +0300

Выпуск Launchpad Daemon 1.5, программного аналога MIDI-контроллера
Mon, 13 Aug 2018 23:16:18 +0300

Опубликован RFC для TLS 1.3
Mon, 13 Aug 2018 20:41:22 +0300

Релиз ядра Linux 4.18
Mon, 13 Aug 2018 07:20:37 +0300

Компания Tesla намерена открыть код систем обеспечения безопасности
Mon, 13 Aug 2018 07:13:08 +0300

Представлен порт Qt 1 для современных систем
Mon, 13 Aug 2018 07:06:50 +0300

Новая техника атаки на беспроводные сети с WPA2
Sun, 12 Aug 2018 12:05:04 +0300

Dropbox прекращает поддержку всех ФС в Linux, за исключением Ext4
Sun, 12 Aug 2018 08:45:31 +0300

Заявлено об обнаружении бэкдора в процессорах VIA C3
Sat, 11 Aug 2018 10:52:44 +0300

Инициатива по развитию открытого ПО для киноиндустрии
Fri, 10 Aug 2018 23:12:43 +0300

Выпуск децентрализованного коммуникационного клиента Ring-KDE 3.0.0
Fri, 10 Aug 2018 15:08:54 +0300

Разработчики bzip2 потеряли контроль над доменом bzip.org
Fri, 10 Aug 2018 10:00:02 +0300

Увидел свет язык программирования Julia 1.0
Thu, 09 Aug 2018 20:38:20 +0300

Выпуск PostgreSQL 10.5, 9.6.10, 9.5.14, 9.4.19, 9.3.24
Thu, 09 Aug 2018 19:00:46 +0300

Поддержка openSUSE Leap 42.3 продлена до июля 2019 года
Thu, 09 Aug 2018 18:45:29 +0300

Обновление DNS-сервера BIND 9.9.13-P1, 9.10.8-P1, 9.11.4-P1, 9.12.2-P1 с устранением уязвимости
Thu, 09 Aug 2018 18:29:48 +0300

Выпуск LibreSSL 2.8.0
Thu, 09 Aug 2018 18:18:35 +0300

Сформированы сборки KDE Neon на базе Ubuntu 18.04
Wed, 08 Aug 2018 23:52:22 +0300

Обновление Firefox 61.0.2
Wed, 08 Aug 2018 23:43:45 +0300

Google назвал нового руководителя Android Open Source Project
Wed, 08 Aug 2018 23:28:27 +0300

Доступен Whonix 14, дистрибутив для обеспечения анонимных коммуникаций
Wed, 08 Aug 2018 18:43:04 +0300

Модель OSI Модель TCP/IP Порты Протоколы
Эталонные модели

Рассмотрим эталонную модель, использовавшуюся в компьютерной сети ARPANET, которая является бабушкой нынешних сетей, а также в ее наследнице, всемирной сети Интернет. ARPANET была исследовательской сетью, финансируемой Министерством обороны США. В конце концов она объединила сотни университетов и правительственных зданий при помощи выделенных телефонных линий. Когда впоследствии появились спутниковые сети и радиосети, возникли большие проблемы при объединении с ними других сетей с помощью имеющихся протоколов. Понадобилась новая эталонная архитектура. Таким образом, возможность объединять различные сети в единое целое являлась одной из главных целей с самого начала. Позднее эта архитектура получила название эталонной модели TCP/IP в соответствии со своими двумя основными протоколами. Первое ее описание встречается в книге Cerf и Kahn (1974). Из более поздних описаний можно выделить книгу, написанную Leiner и др. в 1985 году. Конструктивные особенности модели обсуждаются в издании Clark, 1988.

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

Интернет-уровень

Все эти требования обусловили выбор модели сети с коммутацией пакетов, в основе которой лежал не имеющий соединений межсетевой уровень. Этот уровень, называемый интернет-уровнем или межсетевым уровнем, является основой всей архитектуры. Его задача заключается в обеспечении возможности для каждого хоста посылать в любую сеть пакеты, которые будут независимо двигаться к пункту назначения (например, в другой сети). Они могут прибывать не в том порядке, в котором были отправлены. Если требуется соблюдение порядка отправления, эту задачу выполняют более верхние уровни. Обратите внимание, что слово «интернет» здесь используется в своем первоначальном смысле несмотря на то, что этот уровень присутствует в сети Интернет.

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

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

Транспортный уровень

Уровень, расположенный над межсетевым уровнем модели TCP/IP, как правило, называют транспортным. Он создан для того, чтобы одноранговые сущности на приемных и передающих хостах могли поддерживать связь, подобно транспортному уровню модели OSI. На этом уровне должны быть описаны два сквозных протокола. Первый, TCP (Transmission Control Protocol — протокол управления передачей), является надежным протоколом с установлением соединений, позволяющим без ошибок доставлять байтовый поток с одной машины на любую другую машину объединенной сети. Он разбивает входной поток байтов на отдельные сообщения и передает их межсетевому уровню. В пункте назначения получающий TCP-процесс собирает из полученных сообщений выходной поток. Кроме того, TCP осуществляет управление потоком, чтобы быстрый отправитель не завалил информацией медленного получателя.

Второй протокол этого уровня, UDP (User Data Protocol — пользовательский протокол данных), является ненадежным протоколом без установления соединения, не использующим последовательное управление потоком протокола TCP, а предоставляющим свое собственное. Он также широко используется в одноразовых клиент-серверных запросах и приложениях, в которых оперативность важнее аккуратности, например, при передаче речи и видео. Взаимоотношения протоколов IP, TCP и UDP показаны на рис. 1.18. Со времени создания протокола IP этот протокол был реализован во многих других сетях.

Прикладной уровень

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

Над транспортным уровнем располагается прикладной уровень. Он содержит все протоколы высокого уровня. К старым протоколам относятся протокол виртуального терминала (TELNET), протокол переноса файлов (FTP) и протокол электронной почты (SMTP), как показано на схеме. Протокол виртуального терминала позволяет пользователю регистрироваться на удаленном сервере и работать на нем. Протокол переноса файлов предоставляет эффективный способ перемещения информации с машины на машину. Электронная почта изначально представляла собой разновидность переноса файлов, однако позднее для нее был разработан специальный протокол. С годами было добавлено много других протоколов, таких как DNS (Domain Name Service — служба имен доменов), позволяющая преобразовывать имена хостов в сетевые адреса, NNTP (Network News Transfer Protocol — сетевой протокол передачи новостей), HTTP, протокол, используемый для создания страниц на World Wide Web, и многие другие.

Хост-сетевой уровень

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

Сравнение эталонных моделей OSI и TCP

У моделей OSI и TCP имеется много общих черт. Обе модели основаны на концепции стека независимых протоколов. Функциональность уровней также во многом схожа. Например, в обеих моделях уровни, начиная с транспортного и выше, предоставляют сквозную, не зависящую от сети транспортную службу для процессов, желающих обмениваться информацией. Эти уровни образуют поставщика транспорта. Также в каждой модели уровни выше транспортного являются прикладными потребителями транспортных сервисов.

Несмотря на это фундаментальное сходство, у этих моделей имеется и ряд отличий. В данном разделе мы обратим внимание на ключевые различия. Обратите внимание на то, что мы сравниваем именно эталонные модели, а не соответствующие им стеки протоколов. Сами протоколы будут обсуждаться несколько позднее. Существует книга (Piscitello и Chapin, 1993), которая целиком посвящена сравнению моделей TCP/IP и OSI.

Для модели OSI центральными являются три концепции:

1. Службы.

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

3. Протоколы.

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

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

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

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

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

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

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

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

С моделью TCP/IP было все наоборот: сначала появились протоколы, а уже затем была создана модель, описывающая существующие протоколы. Таким образом, не было проблемы с соответствием протоколов модели. Они ей соответствовали прекрасно. Единственной проблемой было то, что модель не соответствовала никаким другим стекам протоколов. В результате она не использовалась для описания каких-нибудь других сетей, отличных от TCP/IP.

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

Еще одно различие между моделями лежит в сфере возможности использования связи на основе соединений и связи без установления соединения. Модель OSI на сетевом уровне поддерживает оба типа связи, а на транспортном уровне — только связь на основе соединений (поскольку транспортные службы являются видимыми для пользователя). В модели TCP/IP на сетевом уровне есть только один режим связи (без установления соединения), но на транспортном уровне он поддерживает оба режима, предоставляя пользователям выбор. Этот выбор особенно важен для простых протоколов «запрос — ответ».

Критика эталонной модели TCP/IP

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

Во-вторых, модель TCP/IP отнюдь не является общей и довольно плохо описывает любой стек протоколов, кроме TCP/IP. Так, например, описать технологию Bluetooth с помощью модели TCP/IP совершенно невозможно.

В-третьих, хост-сетевой уровень в действительности не является уровнем в том смысле, который обычно используется в контексте уровневых протоколов. Это скорее интерфейс между сетью и уровнями передачи данных. Различие между интерфейсом и уровнем является чрезвычайно важным, и здесь не следует быть небрежным.

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

И наконец, хотя протоколы IP и TCP были тщательно продуманы и неплохо реализованы, многие другие протоколы были созданы несколькими студентами, работавшими над ними, пока это занятие им не наскучило. Реализации этих протоколов свободно распространялись, в результате чего они получили широкое признание, глубоко укоренились, и теперь их трудно заменить на что-либо другое. Некоторые из них в настоящее время оказались серьезным препятствием на пути прогресса. Например, протокол виртуального терминала TELNET, созданный еще для механического терминала типа Teletype, работавшего с огромной скоростью 10 символов в секунду. Ему ничего не известно о графических интерфейсах пользователя и о мышках. Тем не менее сейчас, почти 30 лет спустя, он все еще широко используется.

Несмотря на все недостатки, модель OSI (кроме сеансового уровня и уровня представления) показала себя исключительно полезной для теоретических дискуссий о компьютерных сетях. Протоколы OSI, напротив, не получили широкого распространения. Для TCP/IP верно обратное: модель практически не существует, тогда как протоколы чрезвычайно популярны.

НОВОСТИ: Выявлен ещё один метод удалённой DoS-атаки на ядро Linux и FreeB ... Wed, 15 Aug 2018 13:26:03 +0300

Следом за выявленной на прошлой неделе DoS-уязвимости SegmentSmack в TCP-стеках различных операционных систем, опубликована информация о другой похожей уязвимости (CVE-2018-5391, кодовое имя FragmentSmack), которая также позволяет организовать отказ в обслуживании через отправку специально оформленного набора сетевых пакетов, при обработке которого будут заняты все реcурсы CPU. Если первая уязвимость была связана с неэффективностью алгоритма обработки TCP-сегментов, то новая проблема затрагивает алгоритм пересборки фрагментированных IP-пакетов.

???????@Mail.ru Opera Firefox INFOBOX - хостинг Google Chrome