Протокол как выглядит: Простым языком об HTTP / Хабр

Содержание

Простым языком об HTTP / Хабр

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

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

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.

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

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

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

Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».

API многих программных продуктов также подразумевает использование HTTP для передачи данных — сами данные при этом могут иметь любой формат, например, XML или JSON.

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

Как отправить HTTP-запрос?

Самый простой способ разобраться с протоколом HTTP — это попробовать обратиться к какому-нибудь веб-ресурсу вручную. Представьте, что вы браузер, и у вас есть пользователь, который очень хочет прочитать статьи Анатолия Ализара.

Предположим, что он ввёл в адресной строке следующее:

http://alizar.habrahabr.ru/

Соответственно вам, как веб-браузеру, теперь необходимо подключиться к веб-серверу по адресу alizar.habrahabr.ru.

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

telnet alizar.habrahabr.ru 80

Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод — это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) — по вкусу.

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

Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок — это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar.habrahabr.ru, habrahabr.ru или m.habrahabr.ru — и во всех этих случаях ответ может отличаться. Однако фактически сетевое соединение во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо доменное имя, то сервер об этом никак не информируется — и именно поэтому этот адрес необходимо передать в заголовке Host.

Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:

Метод URI HTTP/Версия

Например (такая стартовая строка может указывать на то, что запрашивается главная страница сайта):

GET / HTTP/1.1

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

verb — «глагол») представляет собой последовательность из любых символов, кроме управляющих и разделителей, и определяет операцию, которую нужно осуществить с указанным ресурсом. Спецификация HTTP 1.1 не ограничивает количество разных методов, которые могут быть использованы, однако в целях соответствия общим стандартам и сохранения совместимости с максимально широким спектром программного обеспечения как правило используются лишь некоторые, наиболее стандартные методы, смысл которых однозначно раскрыт в спецификации протокола.

URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса). Некоторые запросы могут не относиться к какому-либо ресурсу, в этом случае вместо URI в стартовую строку может быть добавлена звёздочка (астериск, символ «*»). Например, это может быть запрос, который относится к самому веб-серверу, а не какому-либо конкретному ресурсу. В этом случае стартовая строка может выглядеть так:

OPTIONS * HTTP/1.1

Версия определяет, в соответствии с какой версией стандарта HTTP составлен запрос. Указывается как два числа, разделённых точкой (например 1.1).

Для того, чтобы обратиться к веб-странице по определённому адресу (в данном случае путь к ресурсу — это «/»), нам следует отправить следующий запрос:

GET / HTTP/1.1
Host: alizar.habrahabr.ru

При этом учитывайте, что для переноса строки следует использовать символ возврата каретки (Carriage Return), за которым следует символ перевода строки (Line Feed). После объявления последнего заголовка последовательность символов для переноса строки добавляется дважды.

Впрочем, в спецификации HTTP рекомендуется программировать HTTP-сервер таким образом, чтобы при обработке запросов в качестве межстрочного разделителя воспринимался символ LF, а предшествующий символ CR, при наличии такового, игнорировался. Соответственно, на практике бо́льшая часть серверов корректно обработает и такой запрос, где заголовки отделены символом LF, и он же дважды добавлен после объявления последнего заголовка.

Если вы хотите отправить запрос в точном соответствии со спецификацией, можете воспользоваться управляющими последовательностями \r и \n:

echo -en "GET / HTTP/1.1\r\nHost: alizar.habrahabr.ru\r\n\r\n" | ncat alizar.habrahabr.ru 80

Как прочитать ответ?

Стартовая строка ответа имеет следующую структуру:

HTTP/Версия Код состояния Пояснение

Версия протокола здесь задаётся так же, как в запросе.

Код состояния (Status Code) — три цифры (первая из которых указывает на класс состояния), которые определяют результат совершения запроса.

Например, в случае, если был использован метод GET, и сервер предоставляет ресурс с указанным идентификатором, то такое состояние задаётся с помощью кода 200. Если сервер сообщает о том, что такого ресурса не существует — 404. Если сервер сообщает о том, что не может предоставить доступ к данному ресурсу по причине отсутствия необходимых привилегий у клиента, то используется код 403. Спецификация HTTP 1.1 определяет 40 различных кодов HTTP, а также допускается расширение протокола и использование дополнительных кодов состояний.

Пояснение к коду состояния (Reason Phrase) — текстовое (но не включающее символы CR и LF) пояснение к коду ответа, предназначено для упрощения чтения ответа человеком. Пояснение может не учитываться клиентским программным обеспечением, а также может отличаться от стандартного в некоторых реализациях серверного ПО.

После стартовой строки следуют заголовки, а также тело ответа. Например:

HTTP/1.1 200 OK
Server: nginx/1. 2.1
Date: Sat, 08 Mar 2014 22:53:46 GMT
Content-Type: application/octet-stream
Content-Length: 7
Last-Modified: Sat, 08 Mar 2014 22:53:30 GMT
Connection: keep-alive
Accept-Ranges: bytes

Wisdom

Тело ответа следует через два переноса строки после последнего заголовка. Для определения окончания тела ответа используется значение заголовка

Content-Length

(в данном случае ответ содержит 7 восьмеричных байтов: слово «Wisdom» и символ переноса строки).

Но вот по тому запросу, который мы составили ранее, веб-сервер вернёт ответ не с кодом 200, а с кодом 302. Таким образом он сообщает клиенту о том, что обращаться к данному ресурсу на данный момент нужно по другому адресу.

Смотрите сами:

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Sat, 08 Mar 2014 22:29:53 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Keep-Alive: timeout=25
Location: http://habrahabr.ru/users/alizar/

<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h2>302 Found</h2></center>
<hr><center>nginx</center>
</body>
</html>

В заголовке Location передан новый адрес. Теперь URI (идентификатор ресурса) изменился на /users/alizar/, а обращаться нужно на этот раз к серверу по адресу habrahabr.ru (впрочем, в данном случае это тот же самый сервер), и его же указывать в заголовке Host.

То есть:

GET /users/alizar/ HTTP/1.1
Host: habrahabr.ru

В ответ на этот запрос веб-сервер Хабрахабра уже выдаст ответ с кодом 200 и достаточно большой документ в формате HTML.

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

А что с безопасностью?

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

SSL

или

TLS

.

Название этого расширения — HTTPS (HyperText Transfer Protocol Secure). Для HTTPS-соединений обычно используется TCP-порт 443. HTTPS широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.

На данный момент HTTPS поддерживается всеми популярными веб-браузерами.

А есть дополнительные возможности?

Протокол HTTP предполагает достаточно большое количество возможностей для расширения. В частности, спецификация HTTP 1.1 предполагает возможность использования заголовка Upgrade для переключения на обмен данными по другому протоколу. Запрос с таким заголовком отправляется клиентом. Если серверу требуется произвести переход на обмен данными по другому протоколу, то он может вернуть клиенту ответ со статусом «426 Upgrade Required», и в этом случае клиент может отправить новый запрос, уже с заголовком Upgrade.

Такая возможность используется, в частности, для организации обмена данными по протоколу WebSocket (протокол, описанный в спецификации RFC 6455, позволяющий обеим сторонам передавать данные в нужный момент, без отправки дополнительных HTTP-запросов): стандартное «рукопожатие» (handshake) сводится к отправке HTTP-запроса с заголовком Upgrade, имеющим значение «websocket», на который сервер возвращает ответ с состоянием «101 Switching Protocols», и далее любая сторона может начать передавать данные уже по протоколу WebSocket.

Что-то ещё, кстати, используют?

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

SPDY

(произносится как английское слово

speedy

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

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

Опубликованный в ноябре 2012 года черновик спецификации протокола HTTP 2.0 (следующая версия протокола HTTP после версии 1.1, окончательная спецификация для которой была опубликована в 1999) базируется на спецификации протокола SPDY.

Многие архитектурные решения, используемые в протоколе SPDY, а также в других предложенных реализациях, которые рабочая группа httpbis рассматривала в ходе подготовки черновика спецификации HTTP 2.0, уже ранее были получены в ходе разработки протокола HTTP-NG, однако работы над протоколом HTTP-NG были прекращены в 1998.

На данный момент поддержка протокола SPDY есть в браузерах Firefox, Chromium/Chrome, Opera, Internet Exporer и Amazon Silk.

И что, всё?

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

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

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

Удачи и плодотворного обучения!

Пишем свой протокол поверх UDP / Хабр

Первые прямые трансляции с места событий появились в России почти 70 лет назад и вели их из передвижной телевизионной станции (ПТС), которая внешне походила на «троллейбус» и позволяла вести эфиры не из студии. А всего лишь три года назад Periscope позволил вместо «троллейбуса» использовать мобильный телефон.

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


Еще через полгода, летом 2016, Одноклассники запустили свое мобильное приложение OK Live для стриминга, в котором постарались решить эти проблемы.

Александр Тоболь отвечает за техническую часть видео в Одноклассниках и на Highload++ 2017 рассказал про то, как писать свой UDP протокол, и зачем это может потребоваться.

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

Говорят, что надо всегда начинать с архитектуры и ТЗ — якобы без этого нельзя! Так и сделаем.



Архитектура и ТЗ

На слайде ниже схема архитектуры любого стримингового сервиса:

видео подается на вход, преобразуется и передается на выход

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


Дальше переходим к техническому заданию. Если у вас есть заказчик, у вас есть ТЗ. Если вы — социальная сеть, ТЗ у вас нет. Как его составить?

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

Мы решили пойти методом от противного и посмотрели, что пользователи НЕ хотят видеть от сервиса трансляции.

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

Так выглядит обычный стриминговый сервис. Посмотрим, что можно сделать, чтобы вместо обычного сделать — крутой стриминговый сервис.


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

Что у конкурентов?

Мы начали с изучения сервисов конкурентов.

Открываем Periscope — что у них?

Как всегда, главное — архитектура.


Сара Хайдер, ведущий инженер Periscope, пишет, что для бэкенда они используют Wowza. Если еще немножко почитать статьи, то мы увидим, что стрим они делают с использованием протокола RTMP, а раздают его либо в RTMP, либо в HLS. Посмотрим, что это за протоколы и как они работают.

Протестируем Periscope на три наших главных требования.

Скорость старта у них приемлемая (меньше секунды на хороших сетях), постоянноекачество порядка 600 px (не HD) и при этом задержки могут составлять до 12 секунд.

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

Это фотография измерения задержки. Есть мобильный телефон с таймером. Мы включаем трансляцию и видим изображение этого телефона на экране. За 0,15 миллисекунд изображение попало на сенсор камеры и вывелось из видеопамяти на экран телефона. После этого мы включаем браузер и смотрим трансляцию.

Ой! Она немножко отстала — примерно на 12 секунд.

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

Итак, есть мобильный телефон, видео идет с камеры и попадает в видеобуфер. Тут задержки минимальны (≈0,15 мс). Потом кодировщик кодирует сигнал, упаковывает в пакет и отправляет в socket-буфер. Это все летит в сеть. Дальше на принимающем устройстве происходит все то же самое.

В принципе, есть две основные трудные точки, которые нужно рассмотреть:

  • кодирование/декодирование видео;
  • сетевые протоколы.

Кодирование/декодирование видео

Немного расскажу про кодирование. Вы все равно с ним столкнетесь, если будете делать Low Latency Live Streaming.


Что такое видео? Это набор кадров, но не совсем простых. Кадры бывают трех типов: I, P и B-frame:

  • I-frame — это просто jpg. По сути, это опорный кадр, он ни от кого не зависит и содержит четкую картинку.
  • P-frame зависит исключительно от предыдущих кадров.
  • Хитрые B-frame могут зависеть от будущего. Это означает, что чтобы посчитать b-frame, нужно, чтобы с камеры пришли еще и будущие кадры. Только тогда с некоторой задержкой можно декодировать b-frame.

Отсюда видно, что

B-кадры вредны

. Попробуем их убрать.

  1. Если вы стримите с мобильного устройства, можно попробовать включить профайл baseline. Он отключит B-frame.
  2. Можно попробовать настроить кодек и уменьшить задержку на будущие кадры, чтобы кадры приходили быстрее.
  3. Еще одна важная штука в тюнинге кодека — это включение CBR (константного битрейта).

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

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

Надо включать CBR. Не все кодеки на Android будут его корректно поддерживать, но они будут к этому стремиться. То есть нужно понимать, что с CBR идеальной картины мира, как на нижней картинке, вы не получите, но включить его все-таки стоит.

  4. А на бэкенде необходимо добавить к h364 кодеку zerolatency — это позволит как раз не делать зависимости в кадрах на будущее.

Протоколы передачи видео

Рассмотрим, какие протоколы стриминга предлагает индустрия. Я их условно разбил на два типа:

  1. потоковые протоколы;
  2. cегментные протоколы.


Потоковые протоколы

 — это протоколы из мира p2p звонков:

RTMP, webRTC, RTSP/RTP

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

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

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

Потоковые протоколы

Periscope использует RTMP. Этот протокол появился в 2009 году, и Adobe сначала не полностью его специфицировал. Потом у него были определенного рода трудности с тем, что Adobe хотел продавать исключительно свой сервер. То есть RTMP развивался довольно трудно. Его основная проблема в том, что

он использует TCP

, но почему-то именно его выбрал Periscope.

Если почитать детально, то оказывается, что Periscope использует RTMP для трансляции с малым количеством зрителей. Как раз такие трансляции, если у вас недостаточный канал, скорее всего, вы не сможете посмотреть.

Рассмотрим на конкретном примере. Есть пользователь с узким каналом связи, который смотрит вашу трансляцию. Вы с ним договариваетесь по RTMP о низком битрейте и начинаете персонально для него стримить.

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

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

Здорово!

Но все равно RTMP у нас поверх TCP, и никто нас от блокировки начала очереди не застраховал.

На рисунке это проиллюстрировано: к нам поступают аудио и видео фреймы, RTMP их пакует, возможно их как-то перемешивает, и они улетают в сеть.

Но допустим, мы теряем один пакет. Возможно, что тот самый желтый потерянный пакет — это вообще P-frame от какого-то предыдущего — его можно было бы дропнуть. Возможно, как минимум, можно было бы играть аудио. Но TCP нам не отдаст остальные пакеты, так как он гарантирует доставку и последовательность пакетов. С этим надо как-то бороться.


Существует еще одна проблема использования протокола TCP в стриминге.

Допустим, у нас есть буфер и высокая пропускная способность сети. Мы генерируем туда из нашего кодека пакеты в высоком разрешении. Потом — оп! — сеть стала работать хуже. На кодеке мы уже указали, что битрейт нужно понизить, но готовые пакеты уже в очереди и никаким образом изъять их оттуда нельзя. TCP отчаянно пытается пропихнуть HD-пакеты через наш 3G.

У нас нет никакого управления буфером, нет приоритезации, поэтому TCP крайне не подходит для стриминга.

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

  • 1,1 Мбит/с трафика;
  • 0,1% packet loss;
  • 300 мс средний RTT.

А если посмотреть некоторые регионы и конкретных операторов, то у них

среднедневной процент потери пакетов более 3%

, а RTT от 600 мс — это нормально.

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

Потеря даже 0,001% пакетов приводит к снижению пропускной способности на 30%. То есть наш пользователь не доутилизирует канал на 30% из-за неэффективности работы TCP протокола в сетях со случайной потерей пакетов.

В определенных регионах packet loss доходит до 1%, тогда у пользователя остается порядка 10% процентов пропускной способности.

Поэтому на TCP делать не будем.

Посмотрим, что есть еще в мире стриминга из UDP.

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

Его основная проблема в том, что он пренебрегает потерями. При всех непонятных ситуациях он просто дропает.

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

RTP-стриминг — это базовый протокол передачи данных по UDP. Ниже на слайде справа приведен набор расширений и RFC, которые пришлось реализовать в WebRTC для того, чтобы адаптировать этот протокол для звонков. В принципе, можно попробовать сделать что-то подобное — набрать набор расширений к RTP и получить UDP стриминг. Но это очень сложно.

Вторая проблема в том, что если кто-то из ваших клиентов не поддерживает какой-либо extension, то протокол не заработает.

Сегментные протоколы

Хорошим примером сегментного протокола видео является

MPEG-Dash

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

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

Еще одним примером сегментного стриминга является HLS.

MPEG-Dash — решение от Google, оно хорошо работает в Android, а Apple-решение более старое, у него есть ряд определенных недостатков.

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

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

На самом деле это трудно не только серверам, которые для того, чтобы обработать 40 Гб трафика должны собрать 26 млн пакетов, но это еще трудно и на клиенте. Поэтому, когда мы переписали iOS плеер на MPEG-Dash, мы даже увидели некоторый прирост производительности.

Но Apple не стоит на месте. В 2016 году они наконец-то анонсировали, что у них есть возможность запихнуть фрагмент от MPEG4 в HLS. Тогда они обещали это добавить только для разработчиков, но вроде бы сейчас должна появиться поддержка на macOS и iOS.

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

Минус: понятно, что опорный кадр, с которого вы стартовали — это не тот кадр, который сейчас у того, кто стримит. Поэтому всегда появляется задержка.

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

Сложность vs задержка

Посмотрим на все имеющиеся протоколы и рассортируем их по двум параметрам:

  • latency, который они дают между трансляцией и смотрящим;
  • complexity (сложность).

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

Что мы хотим?

Мы хотим сделать UDP-протокол для стриминга от 1 к N с задержкой, сравнимой с p2p связью, с возможностью опционального шифрования пакетов в зависимости от того, приватная или публичная трансляция.

Какие есть еще варианты? Можно подождать, например, когда Google выпустит свой QUIC.

Расскажу немного, что это такое. Google позиционирует Google QUIC, как замену TCP — некий TCP 2.0. Его разрабатывают с 2013 года, сейчас спецификации у него нет, зато он полностью доступен в Google Chrome, и мне кажется, что они иногда включают его некоторым пользователям для того, чтобы посмотреть, как он работает. В принципе, можно зайти в настройки, включить себе QUIC, зайти на любой Google сайт и получить этот ресурс по UDP.

Мы решили не ждать, пока они все специфицируют, и запилить свое решение.

Требования к протоколу:

  1. Многопоточность, то есть мы имеем несколько потоков — управляющий, видео, аудио.
  2. Опциональная гарантия доставки — управляющий поток имеет 100% гарантию, видео нам нужно меньше всего — мы там можем дропать фрейм, аудио нам все-таки бы хотелось.
  3. Приоритезация потоков — чтобы аудио уходило вперед, а управляющий вообще летел.
  4. Опциональное шифрование: или все данные, или только заголовки и критичные данные.

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

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

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

Разработка

Давайте уже начнем писать UDP протокол, но сначала посмотрим на статистику.

Это наша статистика по мобильным сетям. Тут видно, что средний интернет чуть больше мегабита, packet loss около 1% — это нормально, и RTT в районе 600 мс — на 3G это просто средние величины.

Будем на это ориентироваться при написании протокола — поехали!

UDP-протокол

Открываем socket UDP, забираем данные, упаковываем, отправляем. Берем вторую пачку от кодека, еще отправляем. Вроде бы все здорово!

Но мы получим такую картину: если мы начинаем беспорядочно слать UDP пакеты в socket, то по статистике к 21-му пакету вероятность того, что он дойдет, будет всего лишь 85%. То есть packet loss уже будет 15%, что никуда не годится. Это нужно исправлять.

Исправляется это стандартно. На рисунке проиллюстрирована жизнь без Pacer и жизнь с Pacer.

Pacer — это такая штука, которая раздвигает пакеты во времени и контролирует их потерю; смотрит, какой сейчас packet loss, в зависимости от этого адаптируется под скорость канала.

Как мы помним, для мобильных сетей 1-3% packet loss — это норма. Соответственно, надо с этим как-то работать. Что делать, если мы теряем пакеты?

Retransmit


В TCP, как известно, есть алгоритм fast retransmit: мы отправляем один пакет, второй, если пакет потеряли, то через некоторое время (retransmit period) отправляем этот же пакет.

Какие здесь плюсы? Никаких проблем, никакой избыточности, но есть минус — некоторый retransmit period.

Кажется, что очень просто: через какое-то время нужно повторить пакет, если вы не получили на него подтверждение. Логично, что это может быть время равное времени пинга. Но ping — это величина не стабильная, и поэтому точно через средний RTT time определить, что потерян пакет, мы не можем.

Для того, чтобы это оценить можно, например, использовать такую величину, как jitter: мы считаем разницу между всеми нашими ping-пакетами. Например, в примере выше, средняя величина равна 46 мс. На нашем портале средний jitter — 50.

Посмотрим на распределение вероятности приходов пакетов ко времени. Есть некоторый RTT и некоторая величина, после которой мы можем действительно понять, что acknowledge не пришел и повторить отправку пакета. В принципе, есть RFC6298, который в TCP говорит, как это можно хитро посчитать.

Мы это делаем через jitter. На портале у нас jitter по ping примерно 15%. Понятно, что retransmit period должен быть, как минимум, на 20% больше, чем RTT.

Еще один кейс с retransmit. С прошлого раза у нас был acknowledge на второй пакет. Мы отправляем третий пакет, который теряется, другие пакеты пока ходят. После этого наступает retransmit period, и мы отправляем третий пакет еще раз. Он еще раз дропнулся, и мы еще раз отправляем его.

Если у нас случается двойная потеря пакета, то на retransmit появляется новая проблема. Если у нас, например, packet loss 5%, и мы отправляем 400 пакетов, то на 400 пакетов у нас 1 раз точно будет ситуация двойного packet-drop, то есть, когда мы через retransmit period отправили пакет, и он еще раз не дошел.

Эту ситуацию можно исправить, добавив некоторую избыточность. Можно начать отправлять пакет, например, если мы получили acknowledge от другого пакета. Считаем, что опережение — это редкая ситуация, можем начать отправку третьего пакет в момент, обозначенный speculative retransmit на слайде выше.

Можно еще пошаманить со спекулятивным retransmit, и все будет неплохо работать.

Но тут мы заговорили про избыточность. А что, если добавить Forward Error Correction? Давайте просто все наши пакеты снабдим, например, XOR. Если мы точно знаем, что в мобильных сетях все так печально, то давайте просто добавим еще один пакетик.

Здорово! Нам не нужны никакие round trip, но у нас уже появилась избыточность.

А что, если пропадет не один пакет, а сразу два? Давайте вместо XOR возьмем другое решение — например, есть код Reed-Solomon, Fountain codes и т.д. Идея такая: если есть K пакетов, можно добавить к ним N пакетов так, что любые N можно было потерять.

Вроде бы классно!

Хорошо, если у нас такая плохая сеть, что пропали просто все пакеты, то к нашему Forward Error Correction очень удобно добавляется negative acknowledgement.

NACK


Если мы потеряли столько пакетов, что наш parity protection (назовем его так) нас уже не спасает, запрашиваем этот пакет дополнительно.

Плюсы NACK:

  • Простой в реализации, правда можно потерять и сам negative acknowledgement, но это мелкая проблема.
  • Хорошо совместим с FEC.

Итого, есть два интересных решения:

  1. С одной стороны, FEC + NACK;
  2. С другой стороны, Fast retransmit.

Посмотрим, как распределены потери пакетов.

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

В среднем на нашем портале теряется по 6 пакетов.

Детальное рассмотрение по сетям показывает, что чем хуже сеть, тем больше это количество. В таблице указано время, которое сеть была недоступна. Например, Wi-Fi недоступен 22 мс и теряет 5 пакетов, 3G может за 34 мс потерять 8 пакетов.

Вопрос: если мы знаем, что у нас 90% packet loss на портале укладывается в 10 пакетов, и при этом средний gap равен 25 мс, что будет работать лучше — FEC + NACK или Fast retransmit?

Тут, наверное, надо рассказать, что Google, когда делал свой протокол QUIC в 2013 году, ставил Forward Error Correction во главу, думая, что он решит все проблемы. Но в 2015 они его отключили.

Мы протестировали оба варианта и у нас не получилось завести FEC + NACK, но мы еще пытаемся и не отчаиваемся.

Рассмотрим, как он работает.

Это цифры, близкие к средней сети, проcто чтобы было удобно считать:

  • 1 Мб/с сеть;
  • 1% packet loss;
  • 300 мс RTT;
  • 1 000 байт — размер пересылаемых пакетов;
  • 1 000 пакетов в секунду уходит.

Мы хотим справляться с потерей сразу до 10 пакетов. Соответственно при packet loss в 1% нам нужно к 1 000 пакетов добавлять 10. Логично — почему нельзя к 100 пакетам добавлять 1 — потому что, если мы потеряли интервал хотя бы в 2 пакета, мы не восстановимся.

Мы начинаем делать такие добавки, и вроде бы все здорово. И тут на 500-м пакете, теряем ту самую пачку из 10 штук.

У нас есть варианты:

  • Дождаться оставшиеся 500 пакетов и восстановить данные через Forward Error Correction. Но на это у нас потратится примерно полсекунды, а пользователь эти данные ждет.
  • Можно воспользоваться NACK, причем это дешевле, чем дожидаться кодов коррекции.
  • А еще можно просто взять Fast Retransmit, не добавлять никаких кодов коррекции и получить тот же самый результат.

Поэтому Forward Error Correction действительно работает, но работает на очень узком диапазоне — когда gap небольшой и можно раз в 200-300 пакетов вставлять это избыточное кодирование.

Fast Retransmit

Это работает так: после того, как мы потеряли пачку в 10 пакетов, отправив пока другие пакеты, понимаем, что у нас retransmit period прошел, и отправляем эти пакеты заново.

Самое интересное в том, что retransmit period на такой сети будет 350 мс, а средняя длительность этого packet gap — 25-30 мс, пусть даже 100. Это означает, что к моменту, когда retransmit начнет обрабатывать пакеты, в большинстве случаев сеть уже восстановится и они уйдут.

У нас получилось, что эта штука работает лучше и быстрее.

Дополнительные опции

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

Есть буфер отправки, в нем лежит опорный кадр, к нему p/b-кадры. Они равномерно уходят в сеть. Тут они перестали уходить в сеть, а в очередь прилетели еще пакеты.

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

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

MTU

Так как мы сами пишем протокол, то придется столкнуться с IP fragmentation. Думаю, многие про это знают, но на всякий случай вкратце расскажу.

У нас есть сервер, он отправляет какие-то пакеты в сеть, они приходят к маршрутизатору и на его уровне MTU (maximum transmission unit) становится ниже, чем размер пакета, который пришел. Он дробит пакет на большой и маленький (здесь 1100 и 400 байт) и отправляет.

В принципе, проблемы нет, это все соберется на клиенте и будет работать. Но если мы теряем 1 пакет, мы дропаем все пакеты, плюс получаем дополнительные издержки на header’ы пакетов. Поэтому, если вы пишете свой протокол, идеально работать в размере MTU.

Как его посчитать?

На самом деле Google не заморачивается, ставит порядка 1200 байт в своем QUIC и не занимается его подбором, потому что IP фрагментация потом все пакетики соберет.

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

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

Таким образом, имея MTU интернет интерфейса, который есть на устройстве, и какое-то минимальное MTU, просто одномерным поиском подбираем правильный MTU. После этого корректируем размер пакета в протоколе.

На самом деле, он иногда меняется. Мы были удивлены, но в процессе переключения Wi-Fi и пр. MTU меняется. Этот параллельный процесс лучше не останавливать и время от времени подправлять MTU.

Выше распределение MTU в мире. У нас на портале получилось около 1100 байт.

Шифрование

Мы говорили, что мы хотим опционально управлять шифрованием. Делаем самый простой вариант — Diffie-Hellman на эллиптических кривых. Делаем его опционально — шифруем только управляющие пакеты и заголовки, чтобы man-in-the-middle не мог получить ключ трансляции, перехватить и так далее.

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

Пакеты шифруем AES-256 независимо, чтобы packet drop никак не влиял на дальнейшее шифрование пакетов.

Приоритезация

Помните, мы хотели от протокола еще приоритезацию.

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

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

Дополнительная плюшка по поводу UDP

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

На слайде как раз времена, когда не удалось достучаться до клиента с сервера по UDP.

Многие скептики говорят, что маршрутизаторы устроены так, что NAT Unbinding вытесняет в первую очередь именно UDP маршруты. Но выше видно, что если Keep-Alive или ping будет меньше 30 секунд, то с вероятностью 99% будет возможно достичь клиента.

Доступность UDP на мобильных устройствах в мире


Google говорит, что 6%, но у нас получилось, что 7% мобильных пользователей не могут пользоваться UDP. В этом случае мы оставляем наш прекрасный протокол с приоритезацией, шифрованием и всем, только на TCP.

На UDP сейчас работает VOIP по WebRTC, Google QUIC, и многие игры работают по UDP. Поэтому верить, что UDP на мобильных устройствах закроют, я бы не стал.

В итоге мы:

  • Снизили задержку между стримером и смотрящим до 1 с.
  • Избавились от накопительного эффекта в буферах, то есть трансляция не отстает.
  • Снизилось количество stall’ов у зрителей.
  • Смогли поддержать на мобильных устройствах FullHD стриминг.


  • Задержка в нашем мобильном приложении OK Live 25 мс — на 10 мс дольше, чем работает сканер камеры, но это не так страшно.
  • Трансляция на Web показывает задержку всего 690 мс — космос!

Что еще умеет стриминг на Одноклассниках

  • Принимает наш протокол OKMP с мобильных устройств;
  • может принимать RTMP и WebRTC;
  • выдает на выходе HLS, MPEG-Dash и т. д.

Если вы были внимательны, то заметили, что я сказал, что мы можем взять у пользователя, например, WebRTC и сконвертировать его в RTMP.

Тут есть нюанс. На самом деле WebRTC — протокол, ориентированный на дроп пакетов, и у него используется аудио кодек OPUS. В RTMP использовать OPUS нельзя.

На серверах бэкенда мы везде используем RTMP. Поэтому нам пришлось сделать еще некоторый фикс в FF MPEG, который позволяет запихнуть OPUS в RTMP, его сконвертировать в AAC и отдать пользователям уже в HLS или еще в чем-то.

Как это выглядит у нас внутри?

  • Пользователи по одному из протоколов загружают оригинал видео на наши upload-сервера.
  • Там мы разворачиваем протокол.
  • По RTMP отправляем на один из серверов трансформации видео.
  • Оригинал всегда сохраняем в распределенное хранилище, чтобы ничего не пропало.
  • После этого все видео поступают на сервер раздачи.

По железу у нас получилось следующее:


Расскажу еще немного про отказоустойчивость:

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

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

ZooKeeper

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

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

Что при этом произойдет?

  • Пользователь на DNS возьмет следующий IP другого upload-сервера.
  • К этому времени ZooKeeper поймет, что сервер в том дата-центре умер, и выберет для другой сервер нарезки.
  • Download-серверы узнают, кто теперь отвечает за трансформацию этого стрима и будут это раздавать.

В принципе, все это произойдет с минимальными задержками.

Использование протокола в продукте

Мы сделали мобильное приложение для стриминга OK Live. Оно полностью интегрировано с порталом. Пользователи там могут общаться, вести прямые эфиры, есть карта эфиров, список популярных эфиров — в общем, все, что можно хотеть.

Также мы добавили возможность вести эфиры в FullHD. К Android-устройству можно подключать action-камеру на Android.

Теперь у нас есть механизм, который позволяет вести прямые трансляции. Например, мы проводили прямую линию с Президентом через OK Live и транслировали ее на всю страну. Пользователи смотрели и через встречный стрим могли попадать в эфир и задавать свои вопросы.

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

На самом деле мы уложились где-то в 2 секунды — секунда туда и секунда обратно. Помните тот «троллейбус», про который я рассказывал в начале статьи — он сейчас выглядит как 2 огромных грузовика. Для ТВ эфира снять с камеры и просто все смикшировать с задержкой в порядка 1-2 с совершенно нормально.

В действительности нам удалось у себя воспроизвести что-то сравнимое с текущими современными ПТС.

Прямые эфиры — это текущий тренд. За последние полтора года на портале ОК они выросли в три раза (не без помощи приложения OK Live).

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

Что получили мы:

  • Смогли гарантировать длительность задержки между стримером и зрителями.
  • Сделали первое мобильное FullHD приложение для стриминга на динамично меняющемся мобильном интернет-канале.
  • Получили возможность терять дата-центры и при этом не прерывать трансляции

Что узнали вы:

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

На Highload++ Siberia Александр Тоболь обещает рассказать про сервис звонков на ОК, будет интересно узнать, что из рассмотренного в этой статье удалось применить, а что пришлось реализовывать совершенно заново.

В этой же секции на узкоспециальные темы планируются доклады:


Что такое IP-адреса и для чего они используются?

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

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

Что такое IP-адрес?

IP-адрес – это строка чисел, разделенных точками. IP-адреса представляют собой набор из четырех чисел, например, 192.158.1.38. Каждое число в этом наборе принадлежит интервалу от 0 до 255. Таким образом, полный диапазон IP-адресации – это адреса от 0. 0.0.0 до 255.255.255.255.

IP-адреса не случайны. Они рассчитываются математически и распределяются Администрацией адресного пространства Интернета (Internet Assigned Numbers Authority, IANA), подразделением Корпорации по присвоению имен и номеров в Интернете (Internet Corporation for Assigned Names and Numbers, ICANN). ICANN – это некоммерческая организация, основанная в США в 1998 году с целью поддержки безопасности интернета и обеспечения его доступности для всех пользователей. Каждый раз, когда кто-либо регистрирует домен в интернете, он пользуется услугами регистратора доменных имен, который платит ICANN небольшой сбор за регистрацию домена.

Как работают IP-адреса

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

Использование IP-адресов обычно происходит незаметно. Процесс работает следующим образом:

  1. Устройство подключается к интернету не напрямую: сначала оно подключается к сети, подключенной к интернету, а сеть, в свою очередь, предоставляет устройству доступ к интернету.
  2. Если вы находитесь дома, скорее всего, этой сетью является сеть вашего интернет-провайдера. В офисе это будет сеть вашей компании.
  3. IP-адрес назначается устройству вашим интернет-провайдером.
  4. Ваша интернет-активность проходит через интернет-провайдера, а он перенаправляет вам ответы на запросы, используя ваш IP-адрес. Поскольку провайдер предоставляет доступ в Интернет, его роль заключается в назначении IP-адрес вашему устройству.
  5. Однако ваш IP-адрес может измениться, например, при включение или выключение модема или маршрутизатора. Можно также связаться с интернет-провайдером, чтобы он изменил IP-адрес.
  6. Если вы находитесь вне дома, например, путешествуете, и берете с собой устройство, домашний IP-адрес не закрепляется за устройством. Это связано с тем, что устройство будет использовать другую сеть (Wi-Fi в отеле, аэропорту, кафе) для доступа в интернет и другой временный IP-адрес, назначенный интернет-провайдером в отеле, аэропорту или кафе.

Как следует из этого процесса, существуют различные типы IP-адресов, которые будут описаны ниже.

Типы IP-адресов

Существуют разные категории IP-адресов, и в каждой категории имеются разные типы.

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

Частные IP-адреса

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

Общедоступные IP-адреса

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

Общедоступные IP-адреса

Общедоступные IP-адреса бывают двух видов: динамические и статические.

Динамические IP-адреса

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

Статические IP-адреса

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

В результате возникла классификация по типам IP-адресов веб-сайтов.

Два типа IP-адресов веб-сайтов

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

Общие IP-адреса

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

Выделенные IP-адреса

Как выполняется поиск IP-адресов

Самый простой способ выяснить общедоступный IP-адрес маршрутизатора – выполнить поиск в Google по словам «What is my IP address?» (Какой у меня IP-адрес?). Ответ отобразится в Google вверху страницы.

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

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

Выяснение частного IP-адреса зависит от платформы:

Windows:

  • Используйте командную строку.
  • В строке поиска Windows укажите cmd (без кавычек).
  • В появившемся окне введите ipconfig (без кавычек), чтобы отобразилась информация об IP-адресе.

Mac:

  • Перейдите в Системные настройки.
  • Выберите сеть, и отобразится требуемая информация.

iPhone:
  • Перейдите в настройки.
  • Выберите Wi-Fi и щелкните значок «i» в кружочке рядом с названием используемой сети. IP-адрес отобразится на закладке DHCP.

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

Угрозы безопасности IP-адресов

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

Социальная инженерия

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

Интернет-преследование

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

Если преследователь из Facebook использует фишинговую атаку по установке шпионских программ против людей с вашим именем, он сможет подтвердить вашу личность по IP-адресу вашей системы.

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

Загрузка нелегального контента с вашего IP-адреса

Отслеживание местоположения

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


Прямая атака на вашу сеть

Взлом устройства

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

Как защитить и скрыть свой IP-адрес

Скрытие IP-адреса – это способ защитить персональные данные и свою личность в интернете. Два основных способа скрыть IP-адрес:

  1. Использование прокси-сервера.
  2. Использование виртуальной частной сети (VPN).

Прокси-сервер – это промежуточный сервер, через который перенаправляется трафик.

  • Интернет-серверы, которые вы посещаете, видят только IP-адрес этого прокси-сервера, а не ваш IP-адрес.
  • Когда эти серверы передают вам ответную информацию, она направляется на прокси-сервер, который затем направляет ее вам.

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

VPN является лучшим решением.

  • Когда вы подключаете компьютер, смартфон или планшет к VPN, устройство работает так, будто оно находится в той же локальной сети, что и VPN.
  • Весь сетевой трафик передается через безопасное соединение с VPN.
  • Компьютер работает так, будто он находится в сети, обеспечивая безопасный доступ к ресурсам локальной сети, даже если вы находитесь в другой стране.
  • Вы также можете использовать интернет, как если бы вы находились в местоположении VPN. Это позволяет безопасно использовать общедоступный Wi-Fi и получить доступ к веб-сайтам с географической блокировкой.

Когда нужно использовать VPN

При использовании VPN ваш IP-адрес будет скрыт, а трафик перенаправляется через отдельный сервер, что обеспечивает безопасность работы в сети. Ситуации, когда целесообразно использовать VPN:

При использовании общедоступной сети Wi-Fi

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

Использование VPN повышает уровень безопасности ваших данных, обеспечивает обход провайдера общедоступного Wi-Fi и шифрует все ваши сообщения.

В путешествии

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

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

При удаленной работе

Это особенно актуально во время эпидемии COVID, когда многие работают удаленно. Часто работодатели требуют использования VPN для удаленного доступа к сервисам компании из соображений безопасности. При подключении к серверу вашего офиса, VPN предоставляет вам доступ к внутренним сетям и ресурсам компании, когда вы не в офисе. Такое же подключение возможно к вашей домашней сети, если вы не дома. 

Когда хочется конфиденциальности

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

Не забывайте и о мобильных устройствах. У них тоже есть IP-адреса и, вероятно, они используются в большем количестве мест, чем домашний компьютер, включая общие точки доступа Wi-Fi. Рекомендуется использовать VPN на мобильном устройстве при подключении к сети, которая не является полностью доверенной.

Другие способы защиты конфиденциальности

Изменение параметров конфиденциальности в приложениях для обмена мгновенными сообщениями

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

Использование уникальных паролей

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

Внимательность к фишинговым письмам и вредоносному контенту

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

Надежное регулярно обновляемое антивирусное решение

Установите комплексное антивирусное решение и поддерживайте его в актуальном состоянии. Например, Антивирусные программы «Лаборатории Касперского» обеспечивают защиту от вирусов для компьютеров и Android-устройств, защищают и хранят пароли и личные документы, шифруют данные, отправляемые и получаемые по сети, с помощью VPN.

Защита IP-адреса – важный аспект защиты вашей личности в интернете. Обеспечение безопасности с помощью описанных выше шагов – это способ обезопасить себя от самых разных кибератак.

Статьи по теме:

Документы

Протокол КК от 09112021 4. pdf

172 КБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 09 ноября 2021 года № 4

Координационный комитет

Оценка результатов

Инструкция по заполнению заявки 2022-1.pdf

1 МБ

инструкция (методические рекомендации) по заполнению заявки на участие во втором конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества в 2022 году

Методические материалы

Первый конкурс 2022

Рекомендации по подготовке бюджета 2022-1.pdf

369 КБ

методические рекомендации по подготовке бюджета проекта в составе заявки на участие во втором конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества в 2022 году

Методические материалы

Первый конкурс 2022

Шаблон заявки 2022-1. docx

134 КБ

шаблон заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (редакция от 31 августа 2021 года)

Методические материалы

Первый конкурс 2022

Положение о конкурсе 11062021.pdf

260 КБ

положение о первом конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества в 2022 году

Первый конкурс 2022

Положения

Конкурсная документация

Объявление 11062021.pdf

130 КБ

объявление о проведении конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества в 2022 году

Конкурсная документация

Первый конкурс 2022

Протокол КК от 11062021 3.pdf

1 МБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 11 июня 2021 года № 3

Второй конкурс 2021

Координационный комитет

Протокол ОЭС от 07062021 2. pdf

179 КБ

протокол заседания объединенного экспертного совета от 7 июня 2021 года № 2

Второй конкурс 2021

Объединенный экспертный совет

Протокол ОЭС от 25032021 1.pdf

160 КБ

протокол заседания объединенного экспертного совета от 25 марта 2021 года № 1

Второй конкурс 2021

Объединенный экспертный совет

Протокол КК от 03032021 2.pdf

92 КБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 3 марта 2021 года № 2

Координационный комитет

Рекомендации по подготовке бюджета 2021-2.pdf

394 КБ

методические рекомендации по подготовке бюджета проекта в составе заявки на участие во втором конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества в 2021 году

Второй конкурс 2021

Методические рекомендации по оценке заявок. pdf

358 КБ

методические рекомендации по оценке заявок на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (редакция от 24 декабря 2020 года)

Независимая экспертиза

Шаблон заявки 2021-2.docx

123 КБ

шаблон заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (редакция от 31 января 2021 года)

Второй конкурс 2021

Инструкция по заполнению заявки 2021-2.pdf

857 КБ

инструкция (методические рекомендации) по заполнению заявки на участие во втором конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества в 2021 году

Второй конкурс 2021

Положение о конкурсе 14012021.pdf

274 КБ

положение о втором конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества в 2021 году

Положения

Второй конкурс 2021

Протокол КК от 14012021 1. pdf

1 МБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 14 января 2021 года № 1

Координационный комитет

Первый конкурс 2021

Протокол ОЭС от 24122020 7.pdf

184 КБ

протокол заседания объединенного экспертного совета от 24 декабря 2020 года № 7

Первый конкурс 2021

Объединенный экспертный совет

Протокол ОЭС от 26102020 6.pdf

156 КБ

протокол заседания объединенного экспертного совета от 26 октября 2020 года № 6

Первый конкурс 2021

Объединенный экспертный совет

Рекомендации по подготовке бюджета 2021-1.pdf

390 КБ

методические рекомендации по подготовке бюджета проекта в составе заявки на участие в первом конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества в 2021 году

Первый конкурс 2021

Инструкция по заполнению заявки 2021-1. pdf

700 КБ

инструкция (методические рекомендации) по заполнению заявки на участие в первом конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества в 2021 году

Первый конкурс 2021

Шаблон заявки 2021-1.docx

89 КБ

шаблон заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (редакция от 31 августа 2020 года)

Первый конкурс 2021

Форма договора 11012021.pdf

300 КБ

форма договора о предоставлении гранта Президента Российской Федерации на развитие гражданского общества (редакция от 11 января 2021 года)

Первый конкурс 2021

Методические материалы

Второй конкурс 2021

Первый конкурс 2022

Положение о конкурсе 28082020.pdf

279 КБ

положение о первом конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества в 2021 году

Первый конкурс 2021

Положения

Объявление 28082020. pdf

132 КБ

объявление о проведении конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества в 2021 году

Первый конкурс 2021

Второй конкурс 2021

Протокол КК от 28082020 3.pdf

867 КБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 28 августа 2020 года № 3

Координационный комитет

Специальный конкурс 2020

Протокол ОЭС от 21082020 5.pdf

75 КБ

протокол заседания объединенного экспертного совета от 21 августа 2020 года № 5

Объединенный экспертный совет

Специальный конкурс 2020

Протокол ОЭС от 23072020 4.pdf

69 КБ

протокол заседания объединенного экспертного совета от 23 июля 2020 года № 4

Объединенный экспертный совет

Специальный конкурс 2020

Положение о конкурсе 25032020. pdf

271 КБ

положение о конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (втором в 2020 году, с изменением, внесённым 25 марта 2020 года)

Положения

Второй конкурс 2020

Логотип фонда для СМИ и контрагентов.zip

6 МБ

логотип фонда для СМИ и контрагентов

Фирменный стиль для СМИ

Руководство по использованию логотипа для СМИ и контрагентов.pdf

368 КБ

руководство по использованию логотипа для СМИ и контрагентов

Фирменный стиль для СМИ

Логотип фонда для победителей.zip

6 МБ

логотип фонда для победителей

Фирменный стиль

Руководство по использованию логотипа для победителей.pdf

2 МБ

руководство по использованию логотипа для победителей

Фирменный стиль

Протокол КК от 15062020 2. pdf

1 МБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 15 июня 2020 года № 2

Координационный комитет

Второй конкурс 2020

Протокол ОЭС от 09062020 3.pdf

189 КБ

протокол заседания объединенного экспертного совета от 9 июня 2020 года № 3

Объединенный экспертный совет

Второй конкурс 2020

Протокол ОЭС от 15042020 2.pdf

159 КБ

протокол заседания объединенного экспертного совета от 15 апреля 2020 года № 2

Второй конкурс 2020

Объединенный экспертный совет

Положение о конкурсе 15062020.pdf

220 КБ

положение о специальном конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (в 2020 году)

Положения

Специальный конкурс 2020

Шаблон заявки специальный конкурс 2020. docx

77 КБ

шаблон заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (редакция от 15 июня 2020 года)

Специальный конкурс 2020

Форма договора 31082020.pdf

242 КБ

форма договора о предоставлении гранта Президента Российской Федерации на развитие гражданского общества (редакция от 31 августа 2020 года)

Специальный конкурс 2020

Рекомендации по подготовке бюджета специальный конкурс 2020.pdf

382 КБ

методические рекомендации по подготовке бюджета проекта в составе заявки на участие в специальном конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (2020 года)

Специальный конкурс 2020

Объявление 15062020.pdf

125 КБ

объявление о проведении в 2020 году специального конкурса на предоставление грантов Президента Российской Федерации на развитие гражданского общества

Специальный конкурс 2020

Инструкция по заполнению заявки специальный конкурс 2020. pdf

605 КБ

инструкция (методические рекомендации) по заполнению заявки на участие в специальном конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (2020 года)

Специальный конкурс 2020

распоряжение Президента Российской Федерации от 6 мая 2020 г. № 120-рп

Специальный конкурс 2020

Решения Президента

Изменение в положение о конкурсе.pdf

100 КБ

изменение в положение о конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (втором в 2020 году)

Второй конкурс 2020

Шаблон заявки 2020-2.docx

82 КБ

шаблон заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (редакция от 26 февраля 2020 года)

Второй конкурс 2020

Инструкция по заполнению заявки 2020-2. pdf

724 КБ

инструкция (методические рекомендации) по заполнению заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (второй конкурс 2020 года)

Второй конкурс 2020

Форма договора 25022020.pdf

233 КБ

форма договора о предоставлении гранта Президента Российской Федерации на развитие гражданского общества (редакция от 25 февраля 2020 года)

Второй конкурс 2020

Рекомендации по подготовке бюджета 2020-2.pdf

397 КБ

методические рекомендации по подготовке бюджета проекта в составе заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (второй конкурс 2020 года)

Второй конкурс 2020

Объявление 21022020.pdf

128 КБ

объявление о проведении в 2020 году второго конкурса на предоставление грантов Президента Российской Федерации на развитие гражданского общества

Второй конкурс 2020

Положение о конкурсе 21022020. pdf

271 КБ

положение о конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (втором в 2020 году)

Положения

Второй конкурс 2020

Протокол КК от 21022020 1.pdf

1 МБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 21 февраля 2020 года № 1

Координационный комитет

Первый конкурс 2020

Протокол ОЭС от 17022020 1.pdf

182 КБ

протокол заседания объединенного экспертного совета от 17 февраля 2020 года № 1

Объединенный экспертный совет

Первый конкурс 2020

Протокол ОЭС от 10122019 5.pdf

159 КБ

протокол заседания объединенного экспертного совета от 10 декабря 2019 года № 5

Объединенный экспертный совет

Первый конкурс 2020

Протокол КК от 14102019 3. pdf

1 МБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 14 октября 2019 года № 3

Второй конкурс 2019

Координационный комитет

Протокол ОЭС от 07102019 4.pdf

188 КБ

протокол заседания объединенного экспертного совета от 7 октября 2019 года № 4

Второй конкурс 2019

Объединенный экспертный совет

Протокол ОЭС от 13082019 3.pdf

170 КБ

протокол заседания объединенного экспертного совета от 13 августа 2019 года № 3

Второй конкурс 2019

Объединенный экспертный совет

Объявление 14102019.pdf

131 КБ

объявление о проведении в 2020 году конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества

Первый конкурс 2020

Рекомендации по подготовке бюджета 2020-1. pdf

397 КБ

методические рекомендации по подготовке бюджета проекта в составе заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (первый конкурс 2020 года)

Первый конкурс 2020

Форма договора 14102019.pdf

221 КБ

форма договора о предоставлении гранта Президента Российской Федерации на развитие гражданского общества (редакция от 14 октября 2019 года)

Первый конкурс 2020

Положение о конкурсе 14102019.pdf

270 КБ

положение о конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (первом в 2020 году)

Положения

Первый конкурс 2020

Шаблон заявки 2020-1.docx

77 КБ

шаблон заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (редакция от 14 октября 2019 года)

Первый конкурс 2020

Инструкция по заполнению заявки 2020-1. pdf

777 КБ

инструкция (методические рекомендации) по заполнению заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (первый конкурс 2020 года)

Первый конкурс 2020

Протокол КК от 31052019 2.pdf

1 МБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 31 мая 2019 года № 2

Первый конкурс 2019

Координационный комитет

Шаблон заявки 2019-2.docx

76 КБ

шаблон заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (редакция от 10 июня 2019 года)

Второй конкурс 2019

Форма договора 01062019.pdf

236 КБ

форма договора о предоставлении гранта Президента Российской Федерации на развитие гражданского общества (редакция от 1 июня 2019 года)

Второй конкурс 2019

Рекомендации по подготовке бюджета 2019-2. pdf

402 КБ

методические рекомендации по подготовке бюджета проекта в составе заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (второй конкурс 2019 года)

Второй конкурс 2019

Инструкция по заполнению заявки 2019-2.pdf

804 КБ

инструкция (методические рекомендации) по заполнению заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (второй конкурс 2019 года)

Второй конкурс 2019

Положение об оценке.pdf

177 КБ

Положение о порядке оценки результатов проектов победителей конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества

Оценка результатов

Протокол ОЭС от 24052019 2.pdf

173 КБ

протокол заседания объединенного экспертного совета от 24 мая 2019 года № 2

Первый конкурс 2019

Объединенный экспертный совет

Положение о конкурсе 31052019. pdf

264 КБ

положение о конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (втором в 2019 году)

Положения

Второй конкурс 2019

Протокол ОЭС от 25032019 1.pdf

176 КБ

протокол заседания объединенного экспертного совета от 25 марта 2019 года № 1

Объединенный экспертный совет

Первый конкурс 2019

Протокол КК от 30012019 1.pdf

287 КБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 30 января 2019 года № 1

Координационный комитет

Первый конкурс 2019

Протокол ОЭС от 20122018 6.pdf

66 КБ

протокол заседания объединенного экспертного совета от 20 декабря 2018 года № 6

Объединенный экспертный совет

Второй конкурс 2018

Порядок экспертизы 25032019. pdf

132 КБ

положение о порядке проведения независимой экспертизы проектов, представленных на конкурс на предоставление грантов Президента Российской Федерации на развитие гражданского общества (редакция от 25 марта 2019 года)

Независимая экспертиза

Инструкция по заполнению заявки 2019-1.pdf

784 КБ

инструкция (методические рекомендации) по заполнению заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (первый конкурс 2019 года)

Первый конкурс 2019

Шаблон заявки 2019-1.docx

54 КБ

шаблон заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (редакция от 31 января 2019 года)

Первый конкурс 2019

Рекомендации по подготовке бюджета 2019-1. pdf

402 КБ

методические рекомендации по подготовке бюджета проекта в составе заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (первый конкурс 2019 года)

Первый конкурс 2019

Объявление 30012019.pdf

129 КБ

объявление о проведении в 2019 году конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества

Первый конкурс 2019

Второй конкурс 2019

Презентация первый конкурс 2019.pdf

1 МБ

презентация «Гранты Президента Российской Федерации на развитие гражданского общества: первый конкурс 2019 года»

Первый конкурс 2019

Положение о конкурсе 30012019.pdf

257 КБ

положение о конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (первом в 2019 году)

Положения

Первый конкурс 2019

Указ Президента Российской Федерации от 30 января 2019 года № 30 «О грантах Президента Российской Федерации, предоставляемых на развитие гражданского общества»

Конкурсная документация

Документы фонда

Решения Президента

Форма договора 30012019. pdf

239 КБ

форма договора о предоставлении гранта Президента Российской Федерации на развитие гражданского общества (редакция от 30 января 2019 года)

Первый конкурс 2019

Приказ от 15062020 № 10.pdf

75 КБ

Приказ от 15 июня 2020 года № 10 о внесении изменений в приказы Фонда президентских грантов от 30 января 2019 года № 1, от 31 мая 2019 года № 6 и от 14 октября 2019 года № 9

Второй конкурс 2019

Первый конкурс 2020

Первый конкурс 2019

Протокол КК от 31102018 3.pdf

1 МБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 31 октября 2018 года № 3

Координационный комитет

Второй конкурс 2018

Протокол ОЭС от 25102018 5.pdf

283 КБ

протокол заседания объединенного экспертного совета от 25 октября 2018 года № 5

Объединенный экспертный совет

Второй конкурс 2018

Протокол ОЭС от 20092018 4. pdf

272 КБ

протокол заседания объединенного экспертного совета от 20 сентября 2018 года № 4

Объединенный экспертный совет

Второй конкурс 2018

Инструкция 13072018.pdf

891 КБ

инструкция (методические рекомендации) по заполнению заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (второй конкурс 2018 года)

Второй конкурс 2018

Рекомендации по подготовке бюджета.pdf

403 КБ

методические рекомендации по подготовке бюджета проекта в составе заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (второй конкурс 2018 года)

Второй конкурс 2018

Изменения 25062018.pdf

102 КБ

основные изменения условий конкурса на предоставление грантов Президента Российской Федерации на развитие гражданского общества (второго в 2018 году)

Второй конкурс 2018

Положение о конкурсе 25062018. pdf

245 КБ

положение о конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (втором в 2018 году)

Положения

Второй конкурс 2018

Объявление 25062018.pdf

128 КБ

объявление о проведении второго в 2018 году конкурса на предоставление грантов Президента Российской Федерации на развитие гражданского общества

Второй конкурс 2018

Форма договора 25062018.pdf

239 КБ

форма договора о предоставлении гранта Президента Российской Федерации на развитие гражданского общества (редакция от 25 июня 2018 года)

Второй конкурс 2018

Шаблон заявки 13072018.doc

316 КБ

шаблон заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (редакция от 13 июля 2018 года)

Второй конкурс 2018

Презентация 2018. pdf

593 КБ

презентация 2018

Второй конкурс 2018

распоряжение Президента Российской Федерации от 3 апреля 2017 года № 93-рп (с изменением, внесенным распоряжением Президента Российской Федерации от 26 июля 2017 года № 272-рп)

Второй конкурс 2017

Первый конкурс 2017

Решения Президента

Инструкция 20022018.pdf

811 КБ

инструкция (методические рекомендации) по заполнению заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (первый конкурс 2018 года)

Первый конкурс 2018

Объявление о проведении конкурсов 2017.pdf

70 КБ

объявление о проведении в 2017 году конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества

Второй конкурс 2017

Первый конкурс 2017

Положение о конкурсе 14042017.pdf

130 КБ

положение о конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (первом в 2017 году)

Положения

Первый конкурс 2017

Положение о конкурсе 15082017.pdf

132 КБ

положение о конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (втором в 2017 году)

Положения

Второй конкурс 2017

Объявление 19022018.pdf

128 КБ

объявление о проведении в 2018 году конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества

Первый конкурс 2018

Требования к использованию гранта.pdf

284 КБ

требования, предъявляемые Фондом президентских грантов к использованию гранта Президента Российской Федерации на развитие гражданского общества (редакция от 06 ноября 2020 года)

Методические материалы

Форма договора 19022018.pdf

262 КБ

форма договора о предоставлении гранта Президента Российской Федерации на развитие гражданского общества (редакция от 19 февраля 2018 года)

Первый конкурс 2018

Положение о конкурсе 19022018.pdf

244 КБ

положение о конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (первом в 2018 году)

Первый конкурс 2018

Положения

Рекомендации по подготовке бюджета.pdf

403 КБ

методические рекомендации по подготовке бюджета проекта в составе заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (первый конкурс 2018 года)

Первый конкурс 2018

Протокол КК от 31052018 2.pdf

1 МБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 31 мая 2018 года № 2

Первый конкурс 2018

Координационный комитет

Протокол ОЭС от 23052018 3.pdf

153 КБ

протокол заседания объединенного экспертного совета от 23 мая 2018 года № 3

Первый конкурс 2018

Объединенный экспертный совет

Протокол ОЭС от 03042018 2.pdf

174 КБ

протокол заседания объединенного экспертного совета от 3 апреля 2018 года № 2

Первый конкурс 2018

Объединенный экспертный совет

Протокол КК от 15022018 1.pdf

157 КБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 15 февраля 2018 года № 1

Координационный комитет

Первый конкурс 2018

Устав фонда.pdf

2 МБ

устав Фонда президентских грантов

Документы фонда

распоряжение Президента Российской Федерации от 19 февраля 2018 г. № 32-рп

Первый конкурс 2018

Второй конкурс 2018

Решения Президента

Шаблон заявки 19022018.doc

294 КБ

шаблон заявки на участие в конкурсе на предоставление грантов Президента Российской Федерации на развитие гражданского общества (редакция от 19 февраля 2018 года)

Первый конкурс 2018

Порядок обработки персональных данных.pdf

138 КБ

положение о порядке обработки и защиты персональных данных

Документы фонда

Протокол ОЭС от 02022018 1.pdf

69 КБ

протокол заседания объединенного экспертного совета от 2 февраля 2018 года № 1

Первый конкурс 2018

Объединенный экспертный совет

Протокол ОЭС от 20122017 7.pdf

68 КБ

протокол заседания объединенного экспертного совета от 20 декабря 2017 года № 7

Объединенный экспертный совет

Протокол КК от 22112017 3.pdf

1 МБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 22 ноября 2017 года № 3

Координационный комитет

Второй конкурс 2017

Протокол ОЭС от 14112017 6.pdf

80 КБ

протокол заседания объединенного экспертного совета от 14 ноября 2017 года № 6

Объединенный экспертный совет

Протокол ОЭС от 09102017 5.pdf

73 КБ

протокол заседания объединенного экспертного совета от 9 октября 2017 года № 5

Второй конкурс 2017

Объединенный экспертный совет

Протокол ОЭС от 28092017 4.pdf

163 КБ

протокол заседания объединенного экспертного совета от 28 сентября 2017 года № 4

Объединенный экспертный совет

Второй конкурс 2017

Протокол КК от 31072017 2.pdf

1 МБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 31 июля 2017 года № 2

Координационный комитет

Первый конкурс 2017

Протокол ОЭС от 26072017 3.pdf

74 КБ

протокол заседания объединенного экспертного совета от 26 июля 2017 года № 3

Объединенный экспертный совет

Протокол ОЭС от 20072017 2.pdf

81 КБ

протокол заседания объединенного экспертного совета от 20 июля 2017 года № 2

Первый конкурс 2017

Объединенный экспертный совет

Протокол ОЭС от 09062017 1.pdf

166 КБ

протокол заседания объединенного экспертного совета от 9 июня 2017 года № 1

Первый конкурс 2017

Объединенный экспертный совет

Протокол КК от 12042017 1.pdf

159 КБ

протокол заседания Координационного комитета по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества от 12 апреля 2017 года № 1

Координационный комитет

Первый конкурс 2017

Положение об ОЭС.pdf

70 КБ

положение об объединенном экспертном совете

Объединенный экспертный совет

Положение о КК.pdf

187 КБ

положение о Координационном комитете по проведению конкурсов на предоставление грантов Президента Российской Федерации на развитие гражданского общества

Координационный комитет

Решения Президента

Протокол правонарушения. Как он выглядит и что с ним делать

Протокол правонарушения. Как он выглядит и что с ним делать

 

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

Протокол правонарушения. Что с ним делать.

A — ИДП (инспектор дорожной полиции) должен указать должность и Ф.И.О.

B — Обязательно сверьте номера авто, двигателя, кузова

C — Попросите ИДП показать расшифровку указанной статьи в протоколе

D — Внимательно читаем пояснения ИДП, если они не соответствуют тому, что было, в объяснительной пишем об этом

E — Если не было досмотра автомобиля делаем соответствующую запись «Досмотра автомобиля не производилось».

F — В этих 4-х строчках, что-либо описать трудно. Поэтому просим бланк жалобы а если его нет просто бумагу формата А4 и пишем объяснительную. Здесь указываем, что «Объяснительная на отдельном листе».

G — Если не было свидетелей, то в этих строчках делаем запись: «Свидетелей (понятых) не присутствовало». Везде где делаем запись, ставим свою подпись. Свидетелей в ехавших в вашей машине вписываем в эти же строки.

H — Статью 584 как правило не разъясняют, поэтому пишем «Права не разъяснены».

I — Подчеркиваем, что защитник нужен. В последствии от него всегда можно отказаться

J — Можно продублировать то что прилагается к протоколу (объяснительная, схема, показания свидетелей и  и пр.)

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


Протокол разногласий по договору | Образец — бланк — форма

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

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

  • полное наименование участников переговоров,
  • наименования представителей сторон,
  • дата переговоров,
  • место составления протокола,
  • подписи сторон.

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

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

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

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

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

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

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

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

Поиск параметров сервера почтовых ящиков Exchange

Если вы подключаетесь к почтовому ящику Exchange и не используете службу электронной почты Microsoft 365 или не знаете, используете ли службу Microsoft 365, выполните указанные ниже действия, чтобы получить нужные сведения.

  1. Войдите в свою учетную запись, используя Outlook Web App. Соответствующие инструкции см. в статье Выполнение входа в Outlook Web App.

  2. В Outlook Web App на панели инструментов выберите пункты «Параметры»   > Почта > POP и IMAP.

  3. Имена серверов POP3, IMAP4 и SMTP, а также другие параметры, которые могут потребоваться, находятся на странице параметров POP и IMAP.

Какие параметры сервера требуется узнать у поставщика услуг электронной почты?

Чтобы помочь вам в этом, мы составили удобный список параметров сервера электронной почты, которые нужно узнать. Скорее всего, вам потребуется также настроить учетную запись POP или IMAP. Что такое POP и IMAP? Обратитесь к поставщику, если вы не знаете, какой протокол использовать.

Примечание: Если настроить учетную запись POP или IMAP, с устройством будет синхронизироваться только электронная почта. Все элементы календаря и контакты, связанные с учетной записью, будут храниться только на локальном компьютере.

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

  1. Распечатайте эту страницу, чтобы обращаться к ней при необходимости.

  2. Позвоните поставщику электронной почты и узнайте у него параметры, указанные в таблице.

  3. Запишите параметры почтового сервера в пустой столбец.

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

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

Общие параметры почты

Параметр

Описание

Значение

Пример

Адрес электронной почты

Адрес электронной почты, который вы хотите настроить.

ваше_имя@contoso.com

Пароль

Пароль, связанный с вашей учетной записью электронной почты.

———

Отображаемое имя

Имя, которое будут видеть получатели сообщений.

Глеб Селезнев

Описание

Описание учетной записи электронной почты.

Личная, рабочая и т. д.

Параметры сервера входящей почты

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

Параметр

Описание

Значение

Пример

Имя узла

Имя сервера входящей почты.

outlook.office365.com

Имя пользователя

Адрес электронной почты, который вы хотите настроить.

ваше_имя@contoso.com

Порт

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

Большинство серверов используют порт 143 или 993 для IMAP и 110 или 995 для POP.

Сервер или домен

Это ваш поставщик электронной почты.

ваш_поставщик.com, gmail.com и т. д.

SSL?

Шифруется ли почта с использованием протокола SSL?

(SSL включен по умолчанию в мобильном приложении Outlook)

Протокол SSL включен

Параметры сервера исходящей почты (SMTP)

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

Параметр

Описание

Значение

Пример

Имя узла SMTP

Имя сервера исходящей почты. Чаще всего это smtp.ваш_поставщик.com

smtp.office365.com

Имя пользователя SMTP

Адрес электронной почты, который вы хотите настроить.

ваше_имя@contoso.com

Пароль SMTP

Пароль, связанный с вашей учетной записью электронной почты.

———

SSL?

Шифруется ли почта с использованием протокола SSL?

(SSL включен по умолчанию в мобильном приложении Outlook)

Протокол SSL включен

Возникают проблемы? Поделитесь ими с нами.

Как выглядит протокол (например, TCP/IP)? : AskTechnology

В качестве конкретного примера рассмотрим HTTP-запрос по кабелю Ethernet.

На самом деле существует как минимум четыре «слоя», один за другим.

  • Первый Физический уровень . Это обрабатывает получение данных между двумя устройствами, которые напрямую связаны друг с другом. Например, компьютер и маршрутизатор. Какой протокол используется, зависит от того, как подключены устройства (802.3 для Ethernet, 802.11 для беспроводной связи и т. д.).

  • Второй уровень IP . Это обрабатывает получение данных между двумя устройствами, которые находятся в одной сети. Например, ваш компьютер и Reddit. Обычно используется IPv4, но мир движется к IPv6 (больше адресов).

  • Третьим является Транспортный уровень . Это обрабатывает передачу данных в определенное приложение на компьютере и гарантирует, что данные не были повреждены при передаче. TCP и UDP являются распространенными протоколами.TCP будет повторно отправлять данные до тех пор, пока они не будут отправлены правильно, чтобы обеспечить надежную доставку. UDP просто отправляет данные в пустоту.

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

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

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

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

Основы ИТ, часть 2. Что такое протокол?

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

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

Протоколы

являются стандартами, и как таковые они часто разрабатываются и документируются известными организациями по стандартизации, такими как Институт инженеров по электротехнике и электронике (IEEE) или Инженерная рабочая группа Интернета (IETF).Часто протоколы обозначаются их стандартными номерами IEEE, такими как 802.3 (Ethernet) или 802.11 (беспроводная локальная сеть / WiFi).

Протоколы

также часто ассоциируются с уровнями, которые, как вы знаете из предыдущей публикации «Основы ИТ» о сетях, являются еще одной излюбленной концепцией ИТ-специалистов.

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

Когда протоколы накладываются друг на друга, мы называем это стеком протоколов. А поскольку протоколы часто связаны с сетями, мы часто видим, что различные уровни OSI сети соответствуют различным протоколам в стеке.

Неизбежные и вездесущие протоколы окружают нас повсюду, и мы постоянно с ними взаимодействуем. Наши мобильные телефоны используют целый ряд протоколов вверх и вниз по сетевому стеку, от GSM и LTE на стороне беспроводной связи до TCP/IP в сетевом стеке и шифровании TLS, которое обертывает наше HTTP-соединение с приложениями, которые мы используем каждый день.

Еще одна область ИТ, где протоколы распространены, — это хранение. Непосредственно подключенное хранилище использует такие протоколы, как SATA, SAS или NVMe, в то время как сети хранения данных обычно используют протоколы iSCSI, Fibre Channel или FCoE (Fiber Channel over Ethernet).

На самом деле, я думаю, можно с уверенностью сказать, что мы можем винить протоколы в большинстве запутанных ИТ-аббревиатур. Некоторые из них даже являются аббревиатурами внутри аббревиатур — например, SAS — это «Serial Attached SCSI». (Мы, айтишники, тоже любим рекурсию, но это уже другая история).Столкнувшись с градом незнакомых ИТ-аббревиатур, можно сознательно кивать и бормотать что-то о протоколах в ответ.

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

Точно так же, как язык объединяет людей и образует сообщества, протоколы объединяют электронные устройства и образуют сети.

Типы интернет-протоколов

« предыдущая Страница 3 из 10 следующая »

В Интернете есть нечто большее, чем Всемирная паутина

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

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

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

Пример окна протокола FTP:

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

Пример окна Gopher:

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

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

FTP
Пример протокола FTP: TUCOWS. Сайты загрузки программного обеспечения, музыки, тем и игр.

Gopher
Пример протокола Gopher: Университет Миннесоты

telnet
Hytelnet — Архив сайтов Telnet

« предыдущая Страница 3 из 10 следующая »

%PDF-1.3 % 1056 0 объект > эндообъект внешняя ссылка 1056 141 0000000016 00000 н 0000003176 00000 н 0000003397 00000 н 0000003430 00000 н 0000003489 00000 н 0000004812 00000 н 0000005013 00000 н 0000005082 00000 н 0000005186 00000 н 0000005288 00000 н 0000005471 00000 н 0000005639 00000 н 0000005803 00000 н 0000005919 00000 н 0000006086 00000 н 0000006252 00000 н 0000006373 00000 н 0000006483 00000 н 0000006619 00000 н 0000006782 00000 н 0000006896 00000 н 0000007000 00000 н 0000007118 00000 н 0000007236 00000 н 0000007361 00000 н 0000007512 00000 н 0000007671 00000 н 0000007793 00000 н 0000007907 00000 н 0000008017 00000 н 0000008146 00000 н 0000008250 00000 н 0000008370 00000 н 0000008486 00000 н 0000008615 00000 н 0000008745 00000 н 0000008884 00000 н 0000009059 00000 н 0000009198 00000 н 0000009356 00000 н 0000009528 00000 н 0000009654 00000 н 0000009767 00000 н 0000009879 00000 н 0000009977 00000 н 0000010076 00000 н 0000010234 00000 н 0000010352 00000 н 0000010459 00000 н 0000010578 00000 н 0000010683 00000 н 0000010803 00000 н 0000010940 00000 н 0000011065 00000 н 0000011184 00000 н 0000011313 00000 н 0000011473 00000 н 0000011581 00000 н 0000011695 00000 н 0000011862 00000 н 0000012002 00000 н 0000012159 00000 н 0000012327 00000 н 0000012472 00000 н 0000012565 00000 н 0000012677 00000 н 0000012779 00000 н 0000012882 00000 н 0000013002 00000 н 0000013158 00000 н 0000013268 00000 н 0000013382 00000 н 0000013482 00000 н 0000013591 00000 н 0000013734 00000 н 0000013907 00000 н 0000013996 00000 н 0000014081 00000 н 0000014230 00000 н 0000014330 00000 н 0000014429 00000 н 0000014526 00000 н 0000014623 00000 н 0000014721 00000 н 0000014819 00000 н 0000014917 00000 н 0000015015 00000 н 0000015113 00000 н 0000015212 00000 н 0000015311 00000 н 0000015410 00000 н 0000015509 00000 н 0000015608 00000 н 0000015707 00000 н 0000015806 00000 н 0000015905 00000 н 0000016004 00000 н 0000016103 00000 н 0000016202 00000 н 0000016301 00000 н 0000016400 00000 н 0000016499 00000 н 0000016598 00000 н 0000016697 00000 н 0000016796 00000 н 0000016895 00000 н 0000016994 00000 н 0000017093 00000 н 0000017192 00000 н 0000017291 00000 н 0000017390 00000 н 0000017489 00000 н 0000017588 00000 н 0000017687 00000 н 0000017786 00000 н 0000017885 00000 н 0000017984 00000 н 0000018083 00000 н 0000018182 00000 н 0000018281 00000 н 0000018380 00000 н 0000018650 00000 н 0000019360 00000 н 0000020150 00000 н 0000020193 00000 н 0000020236 00000 н 0000020557 00000 н 0000021154 00000 н 0000021883 00000 н 0000022332 00000 н 0000025368 00000 н 0000350079 00000 н 0000350219 00000 н 0000350357 00000 н 0000350498 00000 н 0000353477 00000 н 0000358149 00000 н 0000364403 00000 н 0000685747 00000 н 0000003532 00000 н 0000004788 00000 н трейлер ] >> startxref 0 %%EOF 1057 0 объект > эндообъект 1058 0 объект [ 1059 0 Р ] эндообъект 1059 0 объект > /Ф 1134 0 Р >> эндообъект 1060 0 объект > эндообъект 1195 0 объект > ручей HU]L[[email protected] ŹI&nv0V29V; m(9C0gd7FB»hĘHtF7^{ڞRPo4M{}};=

12 распространенных сетевых протоколов и объяснение их функций

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

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

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

Протокол разрешения адресов . ARP преобразует IP-адреса в адреса управления доступом к среде (MAC) и наоборот, чтобы конечные точки локальной сети могли взаимодействовать друг с другом.ARP необходим, потому что IP- и MAC-адреса имеют разную длину: адреса IP версии 4 (IPv4) имеют длину 32 бита, адреса IPv6 — 128 бит, а MAC-адреса — физический аппаратный номер устройства — представляют собой 12 шестнадцатеричных цифр, разделенных на шесть пар. Переводы должны выполняться для правильной связи устройства.

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

Узнайте, как работает ARP.

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

Внешний BGP направляет сетевой трафик из различных AS в Интернет и наоборот.Кроме того, внутренний BGP направляет сетевой трафик между конечными точками в пределах одной AS.

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

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

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

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

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

Квитирование DHCP происходит, когда устройство первоначально подключается к сети.

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

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

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

Другой формой HTTP является HTTPS, что означает HTTP over Secure Sockets Layer или HTTP Secure. HTTPS может шифровать HTTP-запросы и веб-страницы пользователя. Это обеспечивает большую безопасность для пользователей и может предотвратить распространенные угрозы кибербезопасности, такие как атаки «человек посередине».

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

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

IP обычно сочетается с TCP для формирования TCP/IP, общего набора интернет-протоколов.Вместе IP отправляет пакеты адресатам, а TCP упорядочивает пакеты в правильном порядке, поскольку IP иногда отправляет пакеты не по порядку, чтобы обеспечить максимально быстрое перемещение пакетов.

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

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

RIP помогает определить, что путь через маршрутизатор C приводит к меньшему количеству переходов к месту назначения трафика.RIP и OSPF функционируют аналогично друг другу.

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

Тем не менее, SMTP требует других протоколов для правильной отправки и получения сообщений электронной почты.SMTP может работать с почтовым протоколом 3 или протоколом доступа к сообщениям в Интернете, которые контролируют, как сервер электронной почты получает сообщения электронной почты.

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

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

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

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

Откройте для себя ключевые различия между распространенными сетевыми протоколами TCP и UDP.

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

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

Интернет-протокол — обзор

Интернет-протокол (IP) — это протокол без установления соединения, который управляет адресацией данных из одной точки в другую и разбивает большие объемы данных на более мелкие пакеты, которые можно передавать.Основные компоненты дейтаграмм Интернет-протокола:

Идентификация IP (IPID) Используется для уникальной идентификации дейтаграмм IP и для повторной сборки фрагментированных пакетов.

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

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

IP-адрес источника IP-адрес хоста, на котором была создана дейтаграмма.

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

Заметки из подполья …

Подмена источника IP-адреса

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

Спуфинг также может использоваться как часть DoS-атаки. Если сеть A отправляет дейтаграмму в сеть B с поддельным IP-адресом хоста источника в сети C, сеть C увидит идущий к ней трафик, исходящий из сети B, возможно, без каких-либо указаний на то, что сеть A вообще задействована.Этот тип спуфинга распространен в атаках Smurf и Fraggle.

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

Что такое модель TCP/IP протокола управления передачей?

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

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

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

В результате все протоколы высокого уровня, которым необходимо передавать данные, используют протокол TCP. Примеры включают методы однорангового обмена, такие как протокол передачи файлов (FTP), Secure Shell (SSH) и Telnet.Он также используется для отправки и получения электронной почты через протокол доступа к сообщениям в Интернете (IMAP), протокол почтового отделения (POP) и простой протокол передачи почты (SMTP), а также для доступа в Интернет через протокол передачи гипертекста (HTTP).

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

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

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

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

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

 

TCP и IP: в чем разница?

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

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

Модель TCP/IP является методом передачи данных в Интернете по умолчанию. Он был разработан Министерством обороны США для обеспечения точной и корректной передачи данных между устройствами. Он разбивает сообщения на пакеты, чтобы избежать повторной отправки всего сообщения в случае возникновения проблемы во время передачи. Пакеты автоматически пересобираются, как только они достигают места назначения. Каждый пакет может проходить по другому маршруту между исходным и конечным компьютером, в зависимости от того, становится ли исходный маршрут перегруженным или недоступным.

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

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

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

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

.

Добавить комментарий

Ваш адрес email не будет опубликован.