Список: сетевые протоколы сети internet

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

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

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

Модель OSI

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

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

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

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

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

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

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

Настройка DNS через терминал Ubuntu

В Ubuntu есть унифицированный интерфейс настройки сети, который настраивается через конфигурационный файл /etc/network/interfaces. Сначала смотрим список сетевых интерфейсов:

Откройте файл для редактирования и найдите в нем имя своего сетевого интерфейса, например, auto enp0s3, если такой секции нет, ее нужно добавить:

Затем, добавьте в эту секцию строчку:

Здесь адрес 8.8.8.8 — это адрес вашего DNS сервера. Но эта настройка сработает, только если ваш DHCP клиент не пытается назначить адрес самостоятельно. Чтобы указать DNS адрес на уровне DHCP сервера нужно добавить такую строчку в конфигурационный файл /etc/dhcp/dhclient.conf:

Здесь тоже адрес 8.8.8.8 означает адрес DNS сервера. Для верности, вы можете добавить свои адреса DNS серверов в файл /etc/resolvconf/resolv.conf.d/base:

Чтобы настройки вступили в силу необходимо перезапустить сеть:

Возможно, даже лучше будет если вы полностью перезагрузите компьютер. Теперь вы можете открыть /etc/resolv.conf и посмотреть применялся ли новый адрес DNS:

Как видите, в моем примере все заработало. Подобно этому выполняется настройка dns linux для любого дистрибутива.

Поддержка поблочного кодирования HTTP

Если определить общую длину сообщения HTTP перед отправкой невозможно, то можно использовать функцию поблочного кодирования для отправки сообщений в виде серий блоков без поля заголовка Content-Length. Эта функция поддерживается во всех сообщениях HTTP-запросов и HTTP-ответов. Эта функция поддерживается на стороне получателя, а заголовок блока автоматически обрабатывается внутренней логикой. На стороне отправителя клиентом и сервером должны вызываться интерфейсы API nx_web_http_client_request_chunked_set и nx_web_http_server_response_chunked_set соответственно.

Дополнительные сведения об использовании этих служб можно найти в главе 3 «Описание служб HTTP».

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

Каждый запрос имеет один и тот же формат:

протокол

Указывает, какая конкретная версия протокола HTTP будет использоваться. Чаще всего 1.0 и 1.1, но могут встречаться устаревшая 0.9 или новая 2.0. Однако, веб-сервер может не поддерживать указанную версию и вернуть ошибку. На практике подавляющее количество веб-серверов поддерживают 1.0 и 1.1.

/путь

Относительный путь (без доменного имени) до документа. В нашем примере указан корень /, но путь может быть любым: /index.php, /catalog/food/milk. Под документом понимаются не только файлы с расширением .html, но и любые другие файлы, например картинки, .css, .js.

метод

Определяет, что веб-сервер должен сделать с документом, найденным по указанному «/пути».

• GET — вернуть документ — GET /messages/1.
• HEAD — вернуть только заголовки без самой страницы. Это подходит для случая, когда мы хотим проверить, что ссылка на документ валидная. Пример: HEAD /messages/1
• POST — отправить данные для создания документа — POST /messages (и детали нового сообщения).
• PUT — заменить документ
• PATCH — частично обновить документ
• DELETE — удалить документ
• TRACE, CONNECT — технические методы, которые можно пропустить.
• OPTIONS — просьба к веб-серверу вернуть разрешённые настройки для запросов к указанному документу. Ответ включает в себя в том числе список разрешённых методов.

На практике примерно 80% запросов приходится на GET, 15% — на POST и 5% — на все остальные методы.

Заголовки

Они опциональны (в нашем примере их не было вовсе) и подсказывают веб-серверу, как именно нужно обработать запрос. Например, что клиент отправляет запрос в виде текста с кодировкой utf-8, а ожидает получить json в кодировке cp1251.

Наиболее частые на практике заголовки:

• Accept — в каком формате ожидаем ответ: обычный текст, html, xml, json, что угодно ещё.
• Accept-Charset — кодировка тела запроса: utf8, cp1251, koi8.
• Authorization — данные для авторизации между запросами. Здесь чаще всего передаются токены API. Авторизация между запросами будет рассмотрена ниже.
• Accept-Language — список языков, которые нас бы устроили. Например: «Accept-Language: ru».
• Cache-Control — настройки кэширования страниц
• Cookie — известные браузеру куки. В них сохраняются идентификаторы сессий и пользовательские предпочтения.
• Referrer — с какой страницы был сделан текущий запрос. Полезно для аналитики сайта и для возвращения юзера на первоначальную страницу после регистрации, например.
• User-Agent — тип клиента (чаще всего тип вашего браузера). Пример: «Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36». Это поле часто используется на сервере, чтобы отслеживать количество запросов с одного устройства и блокировать их при превышении лимита. Однако это не панацея, ведь после блокировки злоумышленник может поменять User-Agent на любой другой.

Тело

Для GET-запросов тело не имеет смысла, так как всё, что нужно — это путь в стартовой строке и заголовки. Но что происходит, когда мы хотим отправить информацию на сервер? Логин-пароль, форма обратной связи, форма создания поста? Для этого используется POST-запрос.

Каждый элемент формы имеет аттрибут name. В нашем примере страница http://http.maxkuznetsov.ru содержит форму с единственным тегом input, который имеет name=«name». Именно это имя и введённое пользователем в инпут значение будут отправлены на сервер. В консоли такой браузерный запрос будет выглядеть так:

Обратите внимание, что POST запрос очень похож на GET, мы даже обращаемся к тому же документу «/». Однако есть и отличия:

• вместо второй пустой строки в конце запроса содержатся данные: «name=Max»
• эти данные могут быть в разном формате, поэтому мы должны явно указать веб-серверу, что это данные из формы — application/x-www-form-urlencoded
• также мы сообщаем серверу, что в теле запроса содержится ровно 8 символов — «Content-Length: 8». Это техническое поле, которое браузер выполняет на лету, а нам приходится считать самим.

В ответ придёт знакомая страница, но с другим h1 заголовком — php-скрипт, обрабатывающий страницу, подставил вместо «http world» введённое нами имя.

TCP, IP и UDP

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

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

Еще одним механизмом надежности передачи данных является механизм,отслеживающий время жизни пакета. — TTL (Time То Live, время жизни). Если по истечении заданного времени компьютер-получатель не пришлет подтверждение о доставке очередного пакета данных, то компьютер-отправитель перешлет эти данные повторно. Кроме того, данные будут повторно посланы, если пакет оказался поврежденным и компьютер-получатель его отклоняет, о чем сообщает отправителю.

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

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

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

Как ни странно, протокол UDP применяется в сети достаточно часто. Благодарить за это нужно скорость, с которой оп работает. Эта скорость достигается за счет отсутствия необходимости соединения с другими компьютерами, что позволяет использовать трафик сети в нужном направлении. Так. протокол UDP часто используется. например, в сетевых играх или для передачи звуковых данных с интернет- радио (когда надежность доставки пакетов не играет большой роли).

Доставка конечным пользователям

В сегменте доставки видео конечным потребителям протокол UDP/RTP используется достаточно редко. Из распространенных систем, работающих на его основе, можно вспомнить только бесплатную медиаплатформу VLC, включающую медиаредактор и медиаплеер. Она получила популярность в основном потому, что позволяла простыми средствами решать множество насущных задач, таких как ретрансляция видео в локальную сеть, конвертация видеофайлов, просмотр YouTube без Flash-плеера (это было актуально 5—7 лет назад). Некоторые из этих функций востребованы и сейчас, но именно как платформа для получения видео из интернета VLС не слишком удобна и не очень надежна.

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

Эти проблемы в определенной степени можно компенсировать протоколами, работающими поверх TCP/IP. Первым таким решением, получившим реальное распространение, стал протокол RTMP от Adobe, работающий на базе медиаплатформы Flash. Долгое время решение RTMP/Flash оставалось лидером рынка в области интернет-стриминга. Однако на роль по настоящему массовой технологии оно не годилось из-за высокой стоимости, сложности реализации, а также из-за того, что компания Adobe так полностью и не открыла его спецификацию. В результате лидирующие позиции заняли более дешевые технологии на базе стека TCP/IP/HTTP. Этот стек имел еще больше встроенных механизмов для доставки видео, но одновременно создавал еще больше препятствий для обеспечения ее качества.

Емкость и возможности канала

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

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

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

Названия слоев и количество слоев в литературе

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

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

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

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

• MAC или (Media Access Control) — это протокол низкого уровня, который используется для идентификации устройств в локальной сети. У каждого устройства, подключенного к сети есть уникальный MAC адрес, заданный производителем. В локальных сетях, а все данные выходят из локальной сети и попадают в локальную сеть перед тем, как попасть к получателю, используются физические MAC адреса для обозначения устройств. Это один из немногих протоколов уровня соединения, с которым довольно часто приходится сталкиваться.
• IP ( Internet Protocol) — расположен уровнем выше, за MAC. Он отвечает за определение IP адресов, которые будут уникальными для каждого устройства и позволяют компьютерам находить друг друга в сети. Он относится к сетевому уровню модели TCP/IP. Сети могут быть связанны друг с другом в сложные структуры, с помощью этого протокола компьютеры могут определить несколько возможных путей к целевому устройству, причем во время работы эти пути могут меняться. Есть несколько реализаций протокола, но наиболее популярной на сегодняшний день является IPv4 и IPv6.
• ICMP (Internet control message protocol) — используется для обмена сообщениями между устройствами. Это могут быть сообщения об ошибках или информационные сообщения, но он не предназначен для передачи данных. Такие пакеты используются в таких диагностических инструментах, как ping и traceroute. Этот протокол находится выше протокола IP;
• TCP (Transmission control protocol) — это еще один основной сетевой протокол, который находится на том же уровне, что и ICMP. Его задача — управление передачей данных. Сети ненадежны. Из-за большого количества путей пакеты могут приходить не в том порядке или даже теряться. TCP гарантирует, что пакеты будут приняты в правильном порядке, а также позволяет исправить ошибки передачи пакетов. Информация приводится к правильному порядку, а уже затем передается приложению. Перед передачей данных создается соединение с помощью так называемого алгоритма тройного рукопожатия. Он предусматривает отправку запроса и подтверждение открытия соединения двумя компьютерами. Множество приложений используют TCP, это SSH, WWW, FTP и многие другие.
• UDP (user datagram protocol) — это популярный протокол, похожий на TCP, который тоже работает на транспортном уровне. Отличие между ними в том, что здесь используется ненадежная передача данных. Данные не проверяются при получении, это может выглядеть плохой идеей, но во многих случаях этого вполне достаточно. Поскольку нужно отправлять меньше пакетов, UDP работает быстрее, чем TCP. Поскольку соединение устанавливать не нужно, то этот протокол может использоваться для отправки пакетов сразу на несколько машин или IP телефонии.
• HTTP (hypertext transfer protocol) — это протокол уровня приложения, который лежит в основе работы всех сайтов интернета. HTTP позволяет запрашивать определенные ресурсы у удаленной системы, например, веб страницы, и файлы;
• FTP (file transfer protocol) — это протокол передачи файлов. Он работает на уровне приложений и обеспечивает передачу файла от одного компьютера к другому. FTP — не безопасный, поэтому не рекомендуется его применять для личных данных;
• DNS (domain name system) — протокол того же уровня, используемый для преобразования понятных и легко читаемых адресов в сложные ip адреса, которые трудно запомнить и наоборот. Благодаря ему мы можем получить доступ к сайту по его доменному имени;
• SSH (secure shell) — протокол уровня приложений, реализованный для обеспечения удаленного управления системой по защищенному каналу. Многие дополнительные технологии используют этот протокол для своей работы.

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

Общие сведения

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

Для описания и деления протоколов используется семиуровневая модель OSI (Open System Interconnection — взаимодействие открытых систем, ВОС). В этой классификации описываются все формы взаимодействия необходимые для полноценной работы оборудования:
• Приложение;
• Представление;
• Сеанс;
• Транспорт;
• Сеть;
• Передача данных;
• Физическое воплощение.

Библиография

• Дуглас Э. Комер . Межсетевое взаимодействие с TCP / IP — принципы, протоколы и архитектура . ISBN  86-7991-142-9
• Джозеф Г. Дэвис и Томас Ф. Ли. Протоколы и службы TCP / IP Microsoft Windows Server 2003 . ISBN  0-7356-1291-9
• Форузан, Бехруз А. (2003). Пакет протоколов TCP / IP (2-е изд.). Макгроу-Хилл. ISBN 978-0-07-246060-5.
• Крейг Хант Сетевое администрирование TCP / IP . О’Рейли (1998) ISBN  1-56592-322-7
• Мафер, Томас А. (1999). Основы интеллектуальной собственности . Прентис Холл. ISBN 978-0-13-975483-8.
• Ян Маклин. Windows (R) 2000 TCP / IP Черная книга . ISBN  1-57610-687-X
• Ajit Mungale Pro .NET 1.1 Сетевое программирование . ISBN  1-59059-345-6
• В. Ричард Стивенс . Иллюстрированный TCP / IP, Том 1: Протоколы . ISBN  0-201-63346-9
• В. Ричард Стивенс и Гэри Р. Райт. Иллюстрированный TCP / IP, Том 2: Реализация . ISBN  0-201-63354-X
• В. Ричард Стивенс . Иллюстрированный TCP / IP, Том 3: TCP для транзакций , HTTP , NNTP и протоколы домена UNIX . ISBN  0-201-63495-3
• Эндрю С. Таненбаум . Компьютерные сети . ISBN  0-13-066102-3

Виды сетевых протоколов и их сравнение

1. Физический уровень – проще говоря, физическая среда, в которой происходит обмен информацией. На этом уровне происходит преобразование электрических импульсов в бинарный код (нули и единицы), и передача их по проводам на более высокий уровень. На этом уровне работают хабы, ретрансляторы сигналов и медиаконверторы.
2. Канальный уровень – здесь информация поступает на хост для ее обработки. Для однозначной идентификации устройства используется так называемый MAC адрес, состоящий из 12 шестнадцатеричных знаков, поделенных на 6 октетов. Второй подуровень LLC отвечает за обслуживание сетевого уровня.
3. Сетевой уровень – здесь полноправным хозяином является IP-адрес, идентифицирующий уже пользователя в глобальной сети Internet. Информация сюда поступает в виде пакетов, которые после коммутации и маршрутизации переходят на следующий уровень.
4. Транспортный уровень – если на сетевом уровне происходи обязательная доставка пакетов до адресата, то протокол этого уровня следит за тем, чтобы информация дошла в целом и удобоваримом виде. Для этого он фрагментирует большие блоки данных или, наоборот, объединяет их. Взаимодействие данных на этом уровне регулируется такими протоколами как TCP по принципу «точка-точка».
5. Сессионный уровень – протоколы этого уровня отвечают за поддержание сеанса связи, синхронизацию начала и конца сеанса, проверку прав доступа.
6. Уровень представления – здесь поступившие данные декодируются/кодируются, а также сжимаются/распаковываются. В общем-то, на этом уровне происходит перевод информации на понятный браузеру или приложению язык или, наоборот, криптографические преобразования данных для их отправки на более низкий уровень.
7. Прикладной уровень – протоколы данного уровня регулируют взаимодействие сети и пользователя, разрешают приложениям доступ к обработчику запросов БД, файлам и сетевым службам. Здесь в силу вступают протоколы верхнего уровня, такие как HTTP, FTP, POP3, Telnet и др. Подробнее о них.

HTTP – протокол передачи данных в сети Internet. Он использует клиент-серверную модель, то есть существует клиент, передающий запрос серверу, который, в свою очередь, отвечает на этот запрос. На прикладном уровне, поддерживаемом этим протоколом, в качестве клиентов используются, как правило, браузеры, а в качестве серверов выступают Apache, Microsoft IIS и др.

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

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

SMTP — почтовый протокол, предназначенный для обмена электронными письмами. Работает аналогично другим популярным почтовым протоколам POP3 и IMAP, но для передачи информации использует 25 порт.

Назначения других протоколов

Работа интернета — это совместное использование множества протоколов. Чтобы понять, по какому протоколу осуществляется передача файлов в сети интернет, необходимо ознакомиться с кратким списком инструментов для глобальной сети:

MAC (Media Access Control) — необходим для идентификации устройств в локальной сети, получая от каждого из них уникальный MAC-адрес, который есть у каждого компьютера, телефона; ICMP (Internet Control Message Protocol) — благодаря нему устройства могут обмениваться друг с другом информационными сообщениями и ошибками, используется для диагностики, данные не передает; TCP (Transmission Control Protocol) — работает аналогично ICMP, но передает именно данные, отличается высокой надежностью, несмотря на большое количество доступных путей, ведь после передачи информации она приводится к правильному порядку, только после этого отправляется в приложение; UDP (User Datagram Protocol) — похож на TCP, также является частью транспортного уровня, но предусматривает ненадежную передачу данных, при которой может быть потеряна часть данных, но отличается высокой скорость работы; HTTP (Hypertext Transfer Protocol) — запрашивает определенные ресурсы у удаленной системы, после чего формирует код в текст, понятный человеку, стандартный протокол сети интернет, обязательный на всех сайтах в интернете; FTP (File Transfer Protocol) — используется для передачи данных, работает с приложениями, отличается низкой безопасностью, поэтому не применяется для передачи важной личной информации; DNS (Domain Name System) — преобразует IP-адреса в простые для человеческого понимания доменные имена и наоборот, за счет чего можно ввести в поисковую строку адрес сайта и перейти на желаемую страницу; SSH (Secure Shell) — обеспечивает удаленное управление системой с использование защищенного канала. Адресная строка начинается с названия протокола http или https

Адресная строка начинается с названия протокола http или https

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

Последнее обновление — 23 сентября 2021 в 13:42

Все о IT
Самое интересное и полезное. информационно-коммуникационные технологии Ежедневно новое ПЕРЕЙТИ телеграмм канал ITUMNIK

Оптимизация

Оптимизация с помощью HTTP keep-alive

Протокол HTTP работает поверх протокола TCP («Transmission Control Protocol»). TCP — это надёжный протокол двусторонней передачи потока данных. TCP работает, пересылая пакеты данных от клиента к серверу и обратно. TCP-пакет состоит из заголовка и данных. В заголовке указаны, помимо прочего, IP-адреса клиента и сервера, номера TCP-портов, используемых на клиенте и сервере, и набор флагов. Для HTTP на сервере обычно используется стандартный TCP-порт номер 80.

TCP-соединение между клиентом и сервером устанавливается с помощью классического «TCP three-way handshake». Сначала клиент посылает серверу пакет с флагом SYN. В ответ сервер посылает пакет с флагами SYN+ACK. Наконец, клиент посылает ещё один пакет, с флагом ACK и с этой минуты соединение считается установленным, и клиент может посылать свои данные, в нашем случае — HTTP-запрос.
Понятно, что если десяток тысяч браузеров установит с сервером keep-alive соединение, то они достаточно быстро исчерпают его ресурсы. Поэтому во всех серверах есть конфигурируемый тайм-аут, по истечении которого keep-alive соединение разрывается, если на нём не было никакой активности.

Клиент может запросить разрыв соединения после ответа, передав в запросе заголовок Connection: close. Аналогично, сервер может сообщить в ответе, что не желает поддерживать keep-alive соединение, передав точно такой же заголовок: Connection: close. Вообще говоря, все эти расшаркивания с взаимным уведомлением, строго говоря, не налагают никаких обязанностей. И сервер, и клиент должны быть полностью готовы к тому, что соединение прервётся в любой момент времени по инициативе другой стороны без каких-либо уведомлений.

Для того, чтобы соблюсти целостность keep-alive соединения, сервер должен знать длину ответа. Самый простой способ — указать её в заголовке Content-Length. Если длина ответа не указана обработчиком, то сервер вынужден перед отправкой ответа установить заголовок Connection: close и закрыть соединение со своей стороны после отправки ответа.

Оптимизация с помощью компрессии

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

Способность принимать компрессированное содержимое клиент анонсирует серверу с помощью заголовка Accept-Encoding: gzip. Если сервер настроен на сжатие соответствующего контента, то он может добавить заголовок ответа Content-Encoding: gzip (не путать с Transfer-Encoding) и отправить клиенту сжатое содержимое.

Оптимизация с помощью HTTP-pipelining

Когда мы делаем серию запросов и ответов в рамках одного keep-alive соединения, важную роль в производительности играет время задержки (latency) между запросом и ответом. Задержка может быть вызвана как высокой задержкой на канале, так и большим временем обработки запросов на сервере. Перед посылкой очередного запроса мы должны дождаться завершения обработки следующего. Чтобы справиться с этой проблемой, может использоваться технология HTTP-pipelining.

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