Какой открытый сетевой протокол может использоваться для поиска владельца сайта

Обновлено: 15.05.2024

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

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

Название стека протоколов TCP/IP состоит из названий двух разных протоколов. Протокол IP ( Internet Protocol ) представляет собой протокол нижнего (сетевого) уровня и отвечает за передачу пакетов данных в сети. Он относится к так называемым протоколам датаграмм и работает без подтверждений. Последнее означает, что при его использовании доставка пакетов данных не гарантируется и не подтверждается. Не гарантируется также и то, что пакеты достигнут пункта назначения в той последовательности, в которой они были отправлены.

Очевидно, что намного удобнее передавать данные по каналу, который работает корректно, доставляя все пакеты по порядку. Поэтому над протоколом IP работает протокол передачи данных более высокого (транспортного) уровня — TCP ( Transmission Control Protocol ). Посылая и принимая пакеты через протокол IP , протокол TCP гарантирует доставку всех переданных пакетов данных в правильной последовательности.

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

Для идентификации сетевых интерфейсов используются 3 типа адресов:

аппаратные адреса (или MAC-адреса);
сетевые адреса (IP-адреса);
символьные (доменные) имена.

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

Система доменных имен DNS

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

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

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

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

Корневой домен управляется центральными органами Интернета: IANA и Internic.

Домены верхнего уровня назначаются для каждой страны, а также для различных типов организаций. Имена этих доменов должны следовать международному стандарту ISO 3166. Для обозначения стран используются двухбуквенные аббревиатуры, например ru (Российская Федерация), us (США), it (Италия), fr (Франция).

Для различных типов организаций используются трехбуквенные аббревиатуры:

net – сетевые организации;
org – некоммерческие организации;
com - коммерческие организации;
edu – образовательные организации;
gov – правительственные организации.

Администрирование каждого домена возлагается на отдельную организацию, которая делегирует администрирование поддоменов другим организациям.

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

Регистратором доменных имен в зоне ru до 2005 г. являлся Российский научно-исследовательский институт развития общественных сетей ( РосНИИРОС ). В настоящее время регистрация доменов осуществляется одним из действующих регистраторов.

В TCP/IP сетях соответствие между доменными именами и IP -адресами может устанавливаться как локальными средствами, так и централизованными службами. Первоначально соответствие задавалось с помощью создаваемого вручную на хосте файла hosts.txt, состоящего из строк, содержащих пару вида "доменное имя – IP - адрес ". Однако с активным ростом Интернета такое решение оказалось немасштабируемым.

Альтернативное решение – централизованная служба DNS , использующая распределенную базу отображений "доменное имя – IP - адрес ". Сервер домена хранит только имена, которые заканчиваются на следующем ниже по дереву уровне. Это позволяет распределять более равномерно нагрузку по разрешению имен между всеми DNS -серверами. Каждый DNS - сервер помимо таблицы отображения имен содержит ссылки на DNS -серверы своих поддоменов .

Существуют две схемы разрешения DNS -имен.

Нерекурсивная процедура:

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

Рекурсивная процедура:

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

Структура и принципы WWW

Для идентификации ресурсов (зачастую файлов или их частей) в WWW используются идентификаторы ресурсов URI ( Uniform Resource Identifier ). Для определения местонахождения ресурсов в этой сети используются локаторы ресурсов URL ( Uniform Resource Locator ). Такие URL -локаторы представляют собой комбинацию URI и системы DNS .

Доменное имя (или IP - адрес ) входит в состав URL для обозначения компьютера (его сетевого интерфейса), на котором работает программа веб- сервер .

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

Прокси-серверы

Прокси-сервер (proxy-server) — служба в компьютерных сетях, позволяющая клиентам выполнять косвенные запросы к другим сетевым службам.

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

Чаще всего прокси-серверы применяются для следующих целей:

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

Протоколы Интернет прикладного уровня

Самый верхний уровень в иерархии протоколов Интернет занимают следующие протоколы прикладного уровня:

Рассмотрим более подробно некоторые из этих протоколов.

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

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

Сходен по функциональности с протоколами telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли. SSH-клиенты и SSH-серверы имеются для большинства операционных систем.

Хотя telnet и FTP были (и остаются) полезными, первым приложением, совершившим переворот в сознании пользователей компьютеров сети ARPANET , стала электронная почта. До сети ARPANET существовали системы электронной почты, но все они были однокомпьютерными системами. В 1972 г. Рэй Томлинсон (Ray Tomlinson) из компании BBN написал первый пакет, предоставляющий распределенные почтовые услуги в компьютерной сети из нескольких компьютеров. Уже к 1973 г. исследования управления ARPA показали, что три четверти всего трафика сети ARPANET составляла электронная почта. Польза электронной почты оказалась столь велика, что все больше пользователей стремилось подключиться к сети ARPANET , в результате чего возрастала потребность в добавлении новых узлов и использовании высокоскоростных линий. Таким образом, появилась тенденция, сохраняющаяся и по сей день.

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

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

Основные сетевые термины

Перед тем как обсуждать основы сети интернет, нам нужно разобраться с некоторыми общими терминами, которые часто используются специалистами и встречаются в документации:

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

Уровни сетей и модель OSI

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

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

Модель OSI

Так сложилось исторически, что когда дело доходит до уровней работы сетей, используется модель OSI или Open Systems Interconnect. Она выделяет семь уровней:

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

Как видите, перед тем, как данные попадут к аппаратному обеспечению им нужно пройти множество слоев.

Модель протоколов TCP/IP

Модель TCP/IP, еще известная как набор основных протоколов интернета, позволяет представить себе уровни работы сети более просто. Здесь есть только четыре уровня и они повторяют уровни OSI:

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

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

Основные протоколы интернета

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

Есть еще очень много других протоколов, но мы рассмотрели только сетевые протоколы, которые больше всего важны. Это даст вам общие понятия того, как работает сеть и интернет в целом.

Выводы

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

На завершение видео про модель OSI:

Меня всегда напрягало то, как навязчиво Google AdSense подсовывал контекстную рекламу в зависимости от моих старых запросов в поисковике. Вроде бы и времени с момента поиска прошло достаточно много, да и куки и кеш браузера чистились не раз, а реклама оставалась. Как же они продолжали отслеживать меня? Оказывается, способов для этого предостаточно.

Небольшое предисловие

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

Явные идентификаторы

Данный подход довольно очевиден, все, что требуется, — сохранить на стороне пользователя какой-то долгоживущий идентификатор, который можно запрашивать при последующем посещении ресурса. Современные браузеры предоставляют достаточно способов выполнить это прозрачно для пользователя. Прежде всего это старые добрые куки. Затем особенности некоторых плагинов, близкие по функционалу к кукам, например Local Shared Objects во флеше или Isolated Storage в силверлайте. HTML5 также включает в себя несколько механизмов хранения на стороне клиента, в том числе localStorage , File и IndexedDB API . Кроме этих мест, уникальные маркеры можно также хранить в кешированных ресурсах локальной машины или метаданных кеша ( Last-Modified , ETag ). Помимо этого, можно идентифицировать пользователя по отпечаткам, полученным из Origin Bound сертификатов, сгенерированных браузером для SSL-соединений, по данным, содержащимся в SDCH-словарях, и метаданным этих словарей. Одним словом — возможностей полно.

Cookies

Local Shared Objects

Удаление данных из localStorage в Firefox

Другие статьи в выпуске:

Изолированное хранилище Silverlight

Где искать изолированное хранилище Silverlight

HTML5 и хранение данных на клиенте

Настройка локального хранилища для Flash Player

Кешированные объекты

ETag и Last-Modified

Сервер возвращает клиенту ETag

HTML5 AppCache

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

SDCH-словари

SDCH — это разработанный Google алгоритм компрессии, который основывается на использовании предоставляемых сервером словарей и позволяет достичь более высокого уровня сжатия, чем Gzip или deflate. Дело в том, что в обычной жизни веб-сервер отдает слишком много повторяющейся информации — хидеры/футеры страниц, встроенный JavaScript/CSS и так далее. В данном подходе клиент получает с сервера файл словаря, содержащий строки, которые могут появиться в последующих ответах (те же хидеры/футеры/JS/CSS). После чего сервер может просто ссылаться на эти элементы внутри словаря, а клиент будет самостоятельно на их основе собирать страницу. Как ты понимаешь, эти словари можно с легкостью использовать и для хранения уникальных идентификаторов, которые можно поместить как в ID словарей, возвращаемые клиентом серверу в заголовке Avail-Dictionary , так и непосредственно в сам контент. И потом использовать подобно как и в случае с обычным кешем браузера.

Прочие механизмы хранения

Протоколы

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

Характеристики машины

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

Наиболее простой подход к трекингу — это построение идентификаторов путем объединения набора параметров, доступных в среде браузера, каждый из которых по отдельности не представляет никакого интереса, но совместно они образуют уникальное для каждой машины значение:

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

Поведенческий анализ и привычки

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

И это лишь очевидные варианты, которые лежат на поверхности. Если копнуть глубже — можно придумать еще.

Подытожим

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

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

Существует модель OSI (Open System Interface или модель открытых систем), содержащая 7 уровней протоколов:

Несмотря на, казалось бы, избитость этой темы, все же, некоторые моменты изложены в книгах, интернетных ресурсах как-то туманно. Мы в этой статье постараемся немного прояснить ситуацию.

Модель OSI является семиуровневой. Однако, зачастую, на практике используются не все семь уровней, а меньше. Например, как правило, протоколы сеансового и представительского уровня, в силу небольшого объема выполняемых задач, объединяются с транспортным или прикладным уровнями. Поэтому, фактически, на практике используется 3…5 уровней протоколов.

Что часто интересует программиста, занимающегося сетевыми технологиями?

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

Физический уровень

Так как этот уровень имеет дело с электрическими сигналами в виде битов, соответственно, их источником и адресатом являются соответствующие физические сетевые устройства (например, модемы и/или сетевые карты). Эти физические устройства могут быть связаны друг с другом посредством той или иной среды передачи – USB-кабель, оптоволокно, радиоканал и т.п. На физическом уровне вообще не идет речи об IP-адресах, доменах, URL и т.п. Эти абстракции появляются на более высоких уровнях модели OSI.

Здесь играет роль правильность составления кадра из битов, для чего используются различные способы низкоуровневого или физического кодирования: манчестерский код, дифференциальное, потенциальное кодирование, NRZ, БВН и многие другие способы. Физическое кодирование осуществляется в рамках соответствующих стандартов, например, IEEE 802.3 .

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

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

1101100001 0 011

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

Канальный уровень

На этом уровне происходит контроль правильности составления кадров (фреймов). Типичный размер фрейма – 1 кБ. При разработке стеков протоколов на канальном уровне осуществляется помехоустойчивое кодирование. К таким способам кодирования относится код Хемминга, блочное кодирование, код Рида-Соломона. В программировании этот уровень представляет драйвер сетевой платы, в операционных системах имеется программный интерфейс взаимодействия канального и сетевого уровней между собой. Это не новый уровень, а просто реализация модели для конкретной операционной системы. Здесь, как и на физическом уровне, также пока нет ни байтов, ни файлов, ни т.п.

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

Взаимодействие на канальном уровне осуществляется, также как и на физическом, естественно, между физическими устройствами. Однако, для адресации используются так называемые МАС-адреса (аппаратные адреса). Они имеют следующий примерный вид (в шестнадцатеричном представлении):

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

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

Поэтому КАЖДЫЙ, кто выходит в интернет со своего компьютера, на котором установлена стандартная операционная система, типа Windows, Linux, MacOS, Android и т.п., неважно, через прокси-сервер или напрямую, должен ясно понимать, что МАС-адрес его компьютера может быть известен серверу-адресату . Если только, повторимся, он не использует такой прокси-сервер, который способен сделать подмену МАС-адреса. В общем же случае ЛЮБОЙ сервер способен точно идентифицировать пользователя - именно по его MAC-адресу. Кстати, этот аргумент когда-нибудь вполне сможет использовать Раскомнадзор, если ему будет дана команда - заблокировать интернет. Тут же в СМИ возникнут статьи на тему: "А Вы знаете, что любой сервер знает о ВАС ВСЁ?". Вот, мол, Раскомнадзор стал настолько заботлив о пользователях интернета, что решил защитить их от него. Причем, отметим, что Яндекс- и Google-метрики - это сущий пустяк по сравнению с этим. Ни Google, ни Яндекс не собирают информацию о МАС-адресах посетителей сайтов. Ну, по крайней мере, с их слов.

Аналогию можно привести в отношении сотовых телефонов. Ведь любой сотовый телефон представляет собой устройство, подключенное к внешней сети (через ближайшую вышку сотовой связи). КАЖДЫЙ сотовый телефон имеет уникальный МАС-адрес, как и компьютер, ноутбук и т.д. Поэтому ЛЮБОЙ сотовый оператор способен в течение нескольких секунд идентифицировать, с какого именно телефона производится звонок (вызов) на конкретную вышку. А телефонный номер здесь, по идее, и не столь важен, сим-карта может быть вообще любая, это не имеет значения. Может возникнуть вопрос: почему же тогда так называемые "правоохранительные" органы зачастую утверждают, что, якобы, "не могут найти" краденые сотовые телефоны? Ответ: потому, что не хотят или не имеют полномочий. Впрочем, может и хотят, и имеют полномочия, но кто-то вышестоящий запрещает им это делать. Другое дело, что ряд сотовых телефонов можно перепрошить, т.е. подменить в них МАС-адрес. Но, разве те, кто воруют телефоны, а также те, кто покупает краденые телефоны - это всегда делают? Как правило, нет. Ибо и те, и другие прекрасно осведомлены о том, что ни с какими такими МАС-адресами никто дела иметь не будет. Ну, за исключением особо важных случаев, конечно (точнее, "особо важных персон"). Там-то, да, будут смотреть не только МАС-адреса, а и многое другое.

Сетевой уровень

На этом уровне протоколов появляется такая сетевая абстракция, как IP-адрес узла сети. Придумана она исключительно для того, чтобы компьютерам (точнее, пользователям компьютеров) проще было взаимодействовать друг с другом. Чтобы на основе IP-адресов можно было выделять классы сетей, осуществлять защиту от доступа и т.п. Хотя, повторимся, все это вполне можно было бы осуществить, используя исключительно МАС-адреса, не пользуясь технологией IP-адресов.

Т.е. еще раз следует подчеркнуть: фактически, связь осуществляется на основе МАС-адресов. Тогда как IP-адреса используются больше для организации сетевого взаимодействия, понятного не только для компьютеров, но и для людей.

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

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

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

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

В общем, дело обстоит следующим образом:

Клиент (например, браузер) начинает открывать страницу, URL которой введен, к примеру, в его адресной строке. Для начала, браузер будет делать запрос в сеть на предмет того – какому IP-адресу соответствует сервер с доменными именем, содержащимся в открываемом URL. Далее, делается запрос (см. выше) о том, каков МАС-адрес узла сети, соответствующий этому IP-адресу. И только после этого, когда браузер получает в свое распоряжение MAC-адрес искомого узла, он и может выполнить запрос к нему.

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

Инкапсуляция протоколов

В связи с этим предлагаем взглянуть на схему инкапсуляции протоколов:

или, отображая в виде рисунка:

Для большей полноты изображения, покажем место IPv4-протокола в кадре канального протокола:

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

Гриша, если еще актуально: данные протокола НТТР вложены внутрь ТСР-пакетов. Порты разные у НТТР и ТСР и независимые друг от друга.

* тогда на какой МАС-адрес будет отправлять ответ адресат? Для ответа нам не нужен МАК отправителя для этого у нас есть его IP. Мы отправляем ответ в дефолтный шлюз (если для сети отправителя нет особых маршрутов).

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