👨‍💻 База Знаний

Search

SearchSearch

Web and Networks

Apr 28, 202420 min read

Web

Что такое CGI

Common Gateway Interface. Соглашение о том, как веб-сервер взаимодействует с программой, написанной на каком-то языке. Веб-сервер запускает программу как исполняемый файл. Параметры запроса, например, метод, путь, заголовки и т.д. передаются через переменные окружения.

Программа должна прочитать эти переменные и записать в стандартный поток вывода HTTP-ответ.

Плюсы:

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

Минусы:

  • Запуск процесса ОС на каждый запрос отрабатывает очень медленно.
  • Передача данных через stdout медленней юникс-сокетов.

Что такое куки. Зачем они, как с ними работать и где они сохраняются

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

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

Куки хранятся в браузере.

С ними можно работать как из Django (request.COOKIES, response.st_cookie) так и из JavaScript (document.cookie) (если не установлен флаг HTTPONLY).

Может ли сервер изменить (добавить, удалить) куки

Да. Значение куки может быть изменено сервером путём отправления новых строк Set-Cookie: name=newvalue. После этого браузер заменяет старое куки с тем же name на новую строку.

Как защитить куки от воровства и от подделки

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

Для платежных систем, сайтов с приватными данными приведенные правила обязательны.

  • Выставлять кукам флаг httponly. Браузер не даст прочесть и изменить такие куки на клиенте Джаваскриптом.
  • Использовать флаг secure. Куки будут переданы только по безопасному соединению.
  • Устанавливать короткий срок жизни куки.
  • Устанавливать короткий срок сессии на сервере.
  • Добавлять в ключ сессии заголовок User-Agent. Тогда если украсть куки и установить на другой машине, ключ сессии будет другим.
  • Аналогично пункту выше, но добавлять IP пользователя.
  • Подписывать куки секретным ключом. Добавлять поле sig, которое равно HMAC-SHA1(cookie-body, secret_key). На сервере проверять, что подпись совпадает.

Какая разница между аутентификацией и авторизацией

Идентификация (от латинского identifico — отождествлять): присвоение субъектам и объектам идентификатора и / или сравнение идентификатора с перечнем присвоенных идентификаторов. Например, представление человека по имени отчеству - это идентификация.

Аутентификация (от греческого: αυθεντικός ; реальный или подлинный): проверка соответствия субъекта и того, за кого он пытается себя выдать, с помощью некой уникальной информации (отпечатки пальцев, цвет радужки, голос и тд.), в простейшем случае - с помощью имени входа и пароля.

Авторизация - это проверка и определение полномочий на выполнение некоторых действий (например, чтение файла /var/mail/eltsin) в соответствии с ранее выполненной аутентификацией.

Все три процедуры взаимосвязаны:

  1. Сначала определяют имя (логин или номер) – идентификация
  2. Затем проверяют пароль (ключ или отпечаток пальца) – аутентификация
  3. И в конце предоставляют доступ – авторизация

Что такое XSS?

XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») — довольно распространенная уязвимость, которую можно обнаружить на множестве веб-приложений. Ее суть довольно проста, злоумышленнику удается внедрить на страницу JavaScript-код, который не был предусмотрен разработчиками. Этот код будет выполняться каждый раз, когда жертвы (обычные пользователи) будут заходить на страницу приложения, куда этот код был добавлен.

REST

REST (Representational state transfer «передача состояния представления») – соглашение о том, как выстраивать сервисы. Архитектурный паттерн.

REST определяет 6 архитектурных ограничений, соблюдение которых позволит создать настоящий RESTful API:

  1. Единообразие интерфейса (Uniform interface). Как только разработчик ознакомится с одним из ваших API, он сможет следовать аналогичному подходу для других API.
  2. Клиент-сервер. Серверы и клиенты также могут заменяться и разрабатываться независимо, если интерфейс между ними не изменяется
  3. Отсутствие состояния (Stateless). Клиентский контекст не должен храниться на сервере между запросами. Клиент отвечает за управление состоянием приложения.
  4. Кэширование (Cacheable). Хорошо настроенное кэширование частично или полностью исключает некоторые взаимодействия клиент-сервер, что еще больше повышает масштабируемость и производительность.
  5. Слои (Layered system). REST позволяет вам использовать многоуровневую архитектуру системы, в которой вы развертываете API-интерфейсы на сервере A, храните данные на сервере B, a запросы аутентифицируете, например, на сервере C.
  6. Код по требованию (необязательное ограничение). Большую часть времени вы будете отправлять статические представления ресурсов в форме XML или JSON. Но когда вам нужно, вы можете вернуть исполняемый код для поддержки части вашего приложения, например, клиенты могут вызывать ваш API для получения кода визуализации виджета интерфейса пользователя. Это разрешено

SOAP

SOAP (от англ. Simple Object Access Protocol - простой протокол доступа к объектам; вплоть до спецификации 1.2) - протокол обмена структурированными сообщениями в распределённой вычислительной среде.

SOAP является расширением протокола XML-RPC. SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Чаще всего SOAP используется поверх HTTP.

В чем разница между REST и SOAP веб сервисами

Некоторые отличия:

  • REST поддерживает различные форматы: text, JSON, XML; SOAP - только XML,
  • REST работает только по HTTP(S), а SOAP может работать с различными протоколами,
  • REST может работать с ресурсами. Каждый URL это представление какого-либо ресурса. SOAP работает с операциями, которые реализуют какую-либо бизнес логику с помощью нескольких интерфейсов,
  • SOAP на основе чтения не может быть помещена в кэш, а REST в этом случае может быть закэширован,
  • SOAP поддерживает SSL и WS-security, в то время как REST - только SSL, SOAP поддерживает ACID (Atomicity, Consistency, Isolation, Durability). REST поддерживает транзакции, но не один из ACID не совместим с двух фазовым коммитом.

Можем ли мы посылать SOAP сообщения с вложением

Да, это возможно. Можно посылать вложением различные форматы: PDF, изображения или другие двоичные данные. Сообщения SOAP работают вместе с расширением MIME, в котором предусмотрено multipart/related

REST или SOAP

REST и SOAP на самом деле не сопоставимы. REST — это архитектурный стиль. SOAP — это формат обмена сообщениями. То есть приложения REST могут использовать SOAP.

Но если сравнить, то: SOAP → XML, REST → JSON

Что такое CSRF?

Сross Site Request Forgery (межсайтовая подделка запроса). Вид уязвимости, когда сайт А вынуждает пользователя выполнить запрос на сайт Б. Это может быть тег img или script для GET-запроса, или форма со специальным атрибутом target.

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

Например, пользователь должен заполнить форму. В нее помещают скрытое поле token – одноразовую последовательность символов. Этот же токен сохраняют в куки пользователя. При отправке формы поле и куки должны совпасть. Способ не является надежным и обходится скриптом.

Как защитить куки от воровства и от подделки?

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

Для платежных систем, сайтов с приватными данными приведенные правила обязательны.

  • Выставлять кукам флаг httponly. Браузер не даст прочесть и изменить такие куки на клиенте Джаваскриптом.
  • Использовать флаг secure. Куки будут переданы только по безопасному соединению.
  • Устанавливать короткий срок жизни куки.
  • Устанавливать короткий срок сессии на сервере.
  • Добавлять в ключ сессии заголовок User-Agent. Тогда если украсть куки и установить на другой машине, ключ сессии будет другим.
  • Аналогично пункту выше, но добавлять IP пользователя.
  • Подписывать куки секретным ключом. Добавлять поле sig, которое равно HMAC-SHA1(cookie-body, secret_key). На сервере проверять, что подпись совпадает.

Networks

Уровни сетей

network-layers

Для чего подходит каждый из протоколов?

TCP/IP

! Надо еще добавить!

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

Главное отличие датаграмм — в автономности. Каждая датаграмма содержит все необходимые заголовки, чтобы дойти до конечного адресата, поэтому они не зависят от сети, могут доставляться разными маршрутами и в разном порядке. При потере датаграмм или сегментов получаются «битые» куски данных, которые не получится корректно обработать.

UDP

Протокол HTTP

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

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста».

Написать raw запрос главной Яндекса

GET / HTTP/1.1 Host: ya.ru

Из чего состоит HTTP запрос?

HTTP – текстовый протокол, работающий поверх TCP/IP. HTTP состоит из запроса и ответа. Их структуры похожи: стартовая строка, заголовки, тело ответа.

  • Стартовая строка запроса состоит из метода, пути и версии протокола:

    GET /index.html HTTP/1.1

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

    HTTP/1.1 200 OK

  • Заголовки – это набор пар ключ-значение, например, User-Agent, Content-Type. В заголовках передают метаданные запроса: язык пользователя, авторизацию, перенаправление. Заголовок Host должен быть в запросе всегда.

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

Чем отличаются HTTP и HTTPS

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

HTTPS — расширение протокола HTTP, поддерживающее шифрование по протоколам SSL и TLS.

Что нужно отправить браузеру, чтобы перенаправить на другую страницу?

Минимальный ответ должен иметь статус 301 или 302. Заголовок Location указывает адрес ресурса, на который следует перейти.

В теле ответа можно разместить HTML со ссылкой на новый ресурс. Тогда пользователи старых браузеров смогут перейти вручную.

Как управлять кешированием в HTTP?

Существуют несколько способов кешировать данные на уровне протокола.

  • Заголовки Cache и Cache-Control регулируют сразу несколько критериев кеша: время жизни, политику обновления, поведение прокси-сервера, тип данных (публичные, приватные).
  • Заголовки Last-Modified и If-Modified-Since задают кеширование в зависимости от даты обновления документа.
  • Заголовок Etag кеширует документ по его уникальному хешу.

Как кэшируются файлы на уровне протокола?

Когда Nginx отдает статичный файл, он добавляет заголовок Etag – MD5-хеш файла. Клиент запоминает этот хеш. В следующий раз при запросе файла клиент посылает хеш. Сервер проверяет хеш клиента для этого файла. Если хеш не совпадает (файл обновили), сервер отвечает с кодом 200 и выгружает актуальный файл с новым хешем. Если хеши равны, сервер отвечает с кодом 304 Not Modified с пустым телом. В этом случае браузер подставляет локальную копию файла.

Как клиенту понять, удался запрос или нет?

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

  • 1xx: используется крайне редко. В этой группе только один статус 100 Continue.
  • 2xx: запрос прошел успешно (данные получены или созданы)
  • 3xx: перенаправление на другой ресурс
  • 4xx: ошибка по вине пользователя (нет такой страницы, нет прав на доступ)
  • 5xx: ошибка по вине сервера (ошибка в коде, сети, конфигурации)

Что такое ssl/tls?

Существует два типа шифрования: SSL и TLS. Оба обеспечивают безопасное соединение.

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

Что такое ftp/ssh?

FTP и SSH — это сетевые протоколы, которые работают поверх TCP/IP, на подобие HTTP.

FTP – «File Transfer Protocol» (протокол обмена файлами) и буквально означает протокол, который обеспечивает передачу файлов по сети. Обычно применяется для загрузки файлов на хостинг.

SSH – “Secure shell” это протокол, который позволяет не только передавать файлы по защищенному соединению, но и осуществлять удаленное управления операционной системой хостинга.

Какие есть методы запроса и чем они отличаются?

  • GET. Позволяет запросить некоторый конкретный ресурс. Дополнительные данные могут быть переданы через строку запроса (Query String) в составе URL (например ?param=value).О составляющих URL мы поговорим чуть позже.
  • POST. Позволяет отправить данные на сервер. Поддерживает отправку различных типов файлов, среди которых текст, PDF-документы и другие типы данных в двоичном виде. Обычно метод POST используется при отправке информации (например, заполненной формы логина) и загрузке данных на веб-сайт, таких как изображения и документы.
  • HEAD. Здесь придется забежать немного вперед и сказать, что обычно сервер в ответ на запрос возвращает заголовок и тело, в котором содержится запрашиваемый ресурс. Данный метод при использовании его в запросе позволит получить только заголовки, которые сервер бы вернул при получении GET-запроса к тому же ресурсу. Запрос с использованием данного метода обычно производится для того, чтобы узнать размер запрашиваемого ресурса перед его загрузкой.
  • PUT. Используется для создания (размещения) новых ресурсов на сервере. Если на сервере данный метод разрешен без надлежащего контроля, то это может привести к серьезным проблемам безопасности.
  • DELETE. Позволяет удалить существующие ресурсы на сервере. Если использование данного метода настроено некорректно, то это может привести к атаке типа «Отказ в обслуживании» (Denial of Service, DoS) из-за удаления критически важных файлов сервера.
  • OPTIONS. Позволяет запросить информацию о сервере, в том числе информацию о допускаемых к использованию на сервере HTTP-методов.
  • PATCH. Позволяет внести частичные изменения в указанный ресурс по указанному расположению.

Почему POST безопаснее GET?

  • Видимость данных: Данные, отправляемые методом GET, добавляются к URL в виде параметров запроса. Это делает их видимыми в адресной строке браузера, истории просмотра, логах сервера и так далее. В отличие от этого, данные, отправляемые методом POST, передаются в теле запроса и не отображаются в URL.
  • Кэширование: Запросы GET могут быть автоматически закэшированы браузерами или прокси-серверами, что может привести к нежелательному раскрытию информации. POST-запросы обычно не кэшируются.

Почему постоянное перенаправление не лучший вариант?

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

HTTP

Структура HTTP запроса

  1. Стартовая строка (Request Line)
  • Метод: Определяет действие, которое нужно выполнить с ресурсом. Например: GET, POST, PUT, DELETE и т. д.
  • URL (или URI): Указывает на ресурс, с которым нужно выполнить действие. Например: /index.html.
  • Версия протокола: Обычно это HTTP/1.1 или HTTP/2.
  1. Заголовки (Headers) Заголовки предоставляют дополнительную информацию о запросе. Они представлены в виде пары “ключ-значение”. Некоторые из наиболее распространенных заголовков:
  • Host: Доменное имя или IP-адрес и порт сервера.
  • User-Agent: Информация о клиенте/браузере, который отправил запрос.
  • Accept: Типы контента, которые клиент может обрабатывать.
  • Content-Type: Тип контента тела запроса.
  • Content-Length: Длина тела запроса в байтах.
  1. Тело запроса (Request Body) Тело запроса содержит данные, отправляемые на сервер. Не все методы HTTP имеют тело запроса. Например, методы GET и HEAD обычно отправляются без тела, в то время как методы POST и PUT могут включать тело с данными.

Преимущества

  • Простота и универсальность. Почти все поддерживают его
  • Совместимость с другими технологиями
  • Держится постоянно TCP коннект

Недостатки

  • Создает новое соединение на запрос
  • Небезопасен, поэтому надо использовать HTTPS. Можно украсть сессию и увести аккаунт.
  • Нет push возможностей.

Принцип работы DNS

Как работает кэширование и в каких случаях помогает?

Авторизация, аутентификация, какие способы есть, как реализовывать

Структура JWT

Действительно ли JWT stateless

Приведи примеры 502 ошибки

Что делает HTTPS безопасным?

GraphQL что это, какие могут быть проблемы, когда использовать

Что на самом деле происходит, когда пользователь вбивает в браузер адрес google.com

1. DNS-запрос

  • Проверка кэша браузера: Сначала браузер проверяет, есть ли в его кэше недавняя копия DNS-записи для введенного домена.
  • Обращение к DNS-серверу: Если нужной записи в кэше нет, браузер отправляет запрос на DNS-сервер для разрешения доменного имени в IP-адрес. 2. Процесс DNS-разрешения
  • Запрос отправляется на локальный DNS-резольвер, который может обратиться к корневому серверу имён, затем к серверу верхнего уровня (TLD), и далее к авторитативному серверу имён для получения IP-адреса. 3. Установление TCP/IP-соединения
  • Ваш браузер использует протоколы TCP и IP для установления соединения с сервером, который хостит веб-сайт. Это включает в себя процесс “рукопожатия” для подтверждения соединения. 4. Проверка брандмауэром
  • Если ваш компьютер защищен брандмауэром, он проверяет, разрешен ли запрос, прежде чем отправить его. Аналогичная проверка происходит и на серверной стороне. 5. HTTPS/SSL-шифрование
  • Браузер устанавливает защищенное соединение с сервером с использованием протоколов SSL или TLS, обеспечивая шифрование данных. 6. Использование балансировщика нагрузки
  • В случае с сайтами с большим трафиком, такими как Google, запрос сначала попадает на балансировщик нагрузки, который распределяет его между серверами. 7. Взаимодействие с веб-сервером
  • Веб-сервер обрабатывает запрос и возвращает ответ, обычно включающий HTML, CSS и JavaScript файлы, формирующие веб-страницу. 8. Сервер приложений и база данных (при необходимости)
  • Для динамического контента, такого как результаты поиска Google, запрос может обрабатываться сервером приложений, который может запросить данные из базы данных. 9. Рендеринг страницы
  • Браузер обрабатывает полученные HTML, CSS и JavaScript файлы для визуализации веб-страницы, отображая текст, изображения и выполняя JavaScript-код.

А если K8s еще дополнительно?

После номера 2 выше (DNS):

1. Балансировщик нагрузки / Ingress Controller

  • В Kubernetes запрос сначала попадает на балансировщик нагрузки или Ingress Controller. Это компонент, который управляет входящим трафиком и направляет его на соответствующие поды (контейнеры). 2. Сервисы Kubernetes
  • После прохождения через Ingress запрос направляется на Kubernetes Service. Сервис - это абстракция, которая определяет логический набор подов и политику доступа к ним. Он действует как внутренний балансировщик нагрузки. 3. Поды и контейнеры
  • Сервис перенаправляет запрос в один из подов, в которых запущен контейнер с вашим веб-приложением. Поды - это минимальные развертываемые единицы, созданные и управляемые Kubernetes. 4. Контейнеризированное приложение
  • Внутри пода контейнер с веб-приложением обрабатывает запрос. Здесь происходят все обычные действия, связанные с обработкой веб-запросов (например, взаимодействие с веб-сервером, сервером приложений, базами данных и т.д.). 5. Сеть Kubernetes и Политики безопасности
  • Kubernetes предоставляет собственную сетевую инфраструктуру, которая обеспечивает связь между подами и с внешним миром. Возможно использование Сетевых Политик для управления доступом к подам.

Статус коды HTTP

1xx: Информационные

  • 100 Continue: Сервер принял начальную часть запроса и клиент может продолжить отправку оставшейся части.
  • 101 Switching Protocols: Сервер подтверждает запрос на смену протокола.

2xx: Успешно

  • 200 OK: Запрос успешно обработан.
  • 201 Created: Запрос был успешно обработан, и в результате был создан новый ресурс.
  • 202 Accepted: Запрос принят, но ещё не обработан.
  • 204 No Content: Запрос успешно обработан, но в ответе нет содержимого.

3xx: Перенаправление

  • 300 Multiple Choices: Для запрошенного URL есть несколько вариантов выбора.
  • 301 Moved Permanently: Запрошенный ресурс был окончательно перемещен на другой URL.
  • 302 Found: Запрошенный ресурс временно находится по другому URL.
  • 304 Not Modified: Ресурс не был изменен с момента последнего запроса.

4xx: Ошибки клиента

  • 400 Bad Request: Сервер не понимает запрос из-за неверного синтаксиса.
  • 401 Unauthorized: Для доступа к ресурсу требуется аутентификация.
  • 403 Forbidden: У клиента нет прав на доступ к ресурсу.
  • 404 Not Found: Запрошенный ресурс не найден на сервере.
  • 405 Method Not Allowed: Метод, указанный в запросе, не поддерживается для данного ресурса.
  • 429 Too Many Requests: Клиент отправил слишком много запросов за короткий промежуток времени.

5xx: Ошибки сервера

  • 500 Internal Server Error: На сервере произошла ошибка, и он не может выполнить запрос.
  • 501 Not Implemented: Сервер не поддерживает функциональность, необходимую для обработки запроса.
  • 502 Bad Gateway: Один сервер на сетевом пути получил недействительный ответ от другого сервера.
  • 503 Service Unavailable: Сервер временно не может обработать запрос из-за временной перегрузки или технического обслуживания.
  • 504 Gateway Timeout: Один сервер на сетевом пути не дождался ответа от другого сервера и вернул ошибку.

Protobuf, gRPC

Protobuf

Protocol Buffers — протокол сериализации структурированных данных, предложенный Google как эффективная бинарная альтернатива текстовому формату XML.

gRPC

gRPC (gRPC Remote Procedure Call) - это высокопроизводительный протокол удаленного вызова процедур, разработанный компанией Google. Он представляет собой современную альтернативу для традиционных протоколов удаленного вызова, таких как SOAP или REST.

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

Построен на основе HTTP 2.

Преимущества

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

Недостатки

  • дольше внедрять
  • (возможно) HTTP2, на котором он построен, поддерживают не все браузеры

WebSockets

Как работают вебсокеты?

Как гарантировать доставку сообщений с вебсокетом?

Модель OSI (Open Systems Interconnection)

Сетевая модель OSI имеет 7 уровней, иерархически расположенных от большего к меньшему. Cамым верхним является седьмой (прикладной), а самым нижним — первый (физический).

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

osi-7l

L1 – physical layer

Отвечает за обмен физическими сигналами между физическими устройствами, «железом».

Устройства физического уровня оперируют битами. Они передаются по кабелям (например, через оптоволокно) или без — например, через Bluetooth или IRDA, Wi-Fi, GSM, 4G и так далее.

L2 – data link layer

Решает проблему адресации при передаче информации. Канальный уровень получает биты и превращает их в кадры. Задача здесь — сформировать кадры с адресом отправителя и получателя, после чего отправить их по сети.

У канального уровня есть два подуровня — это MAC и LLC.

  • MAC (Media Access Control, контроль доступа к среде) отвечает за присвоение физических MAC-адресов
  • LLC (Logical Link Control, контроль логической связи) занимается проверкой и исправлением данных, управляет их передачей.

Для упрощения LLC на втором уровне модели, но, если быть точными, LLC нельзя отнести полностью ни к первому, ни ко второму уровню — он между.

На втором уровне OSI работают коммутаторы, их задача — передать сформированные кадры от одного устройства к другому, используя в качестве адресов только физические MAC-адреса.

На канальном уровне активно используется протокол ARP (Address Resolution Protocol — протокол определения адреса). С помощью него 64-битные MAC-адреса сопоставляются с 32-битными IP-адресами и наоборот, тем самым обеспечивается инкапсуляция и декапсуляция данных.

L3 – network layer

Маршрутизаторы получают MAC-адрес от коммутаторов с предыдущего уровня и занимаются построением маршрута от одного устройства к другому с учетом всех потенциальных неполадок в сети.

L4 – transport layer

Все семь уровней модели OSI можно условно разделить на две группы:

  • Media layers (уровни среды),
  • Host layers (уровни хоста).

Четвертый уровень — это посредник между Host Layers и Media Layers, относящийся скорее к первым, чем к последним. Его главной задачей является транспортировка пакетов.

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

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

L5 – session layer

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

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

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

L6 – presentation layer

Шестой уровень отвечает за преобразование протоколов и кодирование/декодирование данных. Шестой уровень также занимается представлением картинок (в JPEG, GIF и т.д.), а также видео-аудио (в MPEG, QuickTime). А помимо этого → шифрованием данных, когда при передаче их необходимо защитить.

L7 – application layer

Прикладной уровень — это то, с чем взаимодействуют пользователи, своего рода графический интерфейс всей модели OSI, с другими он взаимодействует по минимуму.

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

Критика модели OSI

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

Какие есть альтернативы модели OSI?

Ранее использовались такие сетевые модели, как протокол последовательного или межсетевого обмена пакетами (Sequenced Packet Exchange / Internet Packet Exchange, SPX/IPX) и сетевая базовая система ввода-вывода (Network Basic Input Output System, NetBIOS). Сегодня основной альтернативой модели взаимосвязи открытых систем (Open Systems Interconnection, OSI) является модель TCP/IP.

На каком уровне работает HTTP?

На прикладном.