По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Новое в IPv6-это автоконфигурация, которая является почти "мини-DHCP" - сервером, и некоторые протоколы были удалены или изменены. Точно так же, как IPv4, хосты, настроенные на IPv6, должны узнать MAC-адрес других устройств, но мы больше не используем ARP, он был заменен протоколом под названием NDP (Neighbour Discovery Protocol).
Теоретические основы
Помимо изучения MAC-адресов, NDP используется для решения ряда задач:
Router Discovery (обнаружение маршрутизаторов): NDP используется для изучения всех доступных маршрутизаторов IPv6 в подсети.
Обнаружение MAC-адресов: после того, как хост выполнил проверку DAD и использует IPv6 адрес он должен будет обнаружить MAC адреса хостов с которыми он хочет общаться.
DAD (обнаружение дубликатов адресов): каждый хост IPv6 будет ждать, чтобы использовать свой адрес, если только он не знает, что ни одно другое устройство не использует тот же адрес. Этот процесс называется DAD, и NDP делает это за нас.
SLAAC: NDP используется, чтобы узнать, какой адрес и длину префикса должен использовать хост.
Мы рассмотрим все задачи, чтобы увидеть, как они работают. Начнем с обнаружения маршрутизатора. Когда хост настроен на IPv6, он автоматически обнаруживает маршрутизаторы в подсети.
Хост IPv6 может использовать NDP для обнаружения всех маршрутизаторов в подсети, которые могут использоваться в качестве шлюза по умолчанию. В принципе, хост отправляет сообщение с запросом, есть ли там какие-либо маршрутизаторы, и маршрутизаторы ответят. Используются два сообщения:
RS (Router Solicitation), который отправляется на "все маршрутизаторы ipv6" FF02::2 multicast адрес.
RA (Router Advertisement) отправляется маршрутизатором и включает в себя его link-local IPv6 адрес.
Когда хост отправляет запрос маршрутизатору, маршрутизатор будет отвечать на одноадресный адрес хоста. Маршрутизаторы также будут периодически отправлять рекламные объявления маршрутизаторов для всех заинтересованных сторон, они будут использовать для этого адрес FF02:: 1 "все узлы".
Большинство маршрутизаторов также будут иметь global unicast адрес, настроенный на интерфейсе, в этом случае хосты будут узнавать не только о link-local адресе, но и о префиксе, который используется в подсети.
Этот префикс можно использовать для SLAAC. NPD также используется в качестве замены ARP. Для этого он использует два вида сообщений:
NS (Neighbor Solicitation)
NA (Neighbor Advertisement)
Запрос соседа работает аналогично запросу ARP, он запрашивает определенный хост для своего MAC-адреса, и объявление соседа похоже на ответ ARP, поскольку оно используется для отправки MAC-адреса. В основном это выглядит так:
Всякий раз, когда хост посылает запрос соседу, он сначала проверяет свой кэш, чтобы узнать, знает ли он уже MAC-адрес устройства, которое он ищет. Если его там нет, он пошлет соседу запрос. Эти соседние запрашивающие сообщения используют solicited-node multicast адрес запрашиваемого узла.
Помимо обнаружения MAC-адресов, сообщения NS и NA также используются для обнаружения дубликатов IPv6-адресов. Прежде чем устройство IPv6 использует одноадресный адрес, оно выполнит DAD (обнаружение дубликатов адресов), чтобы проверить, не использует ли кто-то другой тот же IPv6-адрес. Если адрес используется, хост не будет его использовать. Вот как это выглядит:
Host1 был настроен с IPv6-адресом 2001:1:1:1::2, который уже используется Host2. Он будет посылать запрос соседства, но поскольку host2 имеет тот же IPv6-адрес, он ответит объявлением соседа. Host1 теперь знает, что это дубликат IPv6-адреса. Эта проверка выполняется для всех одноадресных адресов, включая link-local адреса. Это происходит, когда вы настраиваете их и каждый раз, когда интерфейс находится в состоянии "up".
Последний NPD, который мы рассмотрим, - это SLAAC, которая позволяет хостам автоматически настраивать свой IPv6-адрес. Для IPv4 мы всегда использовали DHCP для автоматического назначения IP-адреса, шлюза по умолчанию и DNS-сервера нашим хостам, и эта опция все еще доступна для IPv6 (мы рассмотрим ее ниже).
DHCP прекрасная "вещь", но недостатком является то, что вам нужно установить DHCP-сервер, настроить пул с диапазонами адресов, шлюзами по умолчанию и DNS-серверами.
Когда мы используем SLAAC, наши хосты не получают IPv6-адрес от центрального сервера, но он узнает префикс, используемый в подсети, а затем создает свой собственный идентификатор интерфейса для создания уникального IPv6-адреса. Вот как работает SLAAC:
Хост сначала узнает о префиксе с помощью сообщений NDS RS RA.
Хост принимает префикс и создает идентификатор интерфейса, чтобы создать уникальный IPv6-адрес.
Хост выполняет DAD, чтобы убедиться, что IPv6-адрес не используется никем другим.
Маршрутизаторы Cisco будут использовать EUI-64 для создания идентификатора интерфейса, но некоторые операционные системы будут использовать случайное значение. Благодаря SLAAC хост будет иметь IPv6-адрес и шлюз, но один элемент все еще отсутствует...DNS-сервер. SLAAC не может помочь нам с поиском DNS-сервера, поэтому для этого шага нам все еще требуется DHCP.
DHCP для IPv6 называется DHCPv6 и поставляется в двух формах:
Stateful
Stateless
Мы рассмотрим DHCPv6 чуть позже, но для SLAAC нам нужно понять, что такое stateless DHCPv6. Обычно DHCP-сервер отслеживает IP-адреса, которые были арендованы клиентами, другими словами, он должен сохранять "состояние" того, какие IP-адреса были арендованы и когда они истекают.
Сервер stateless DHCPv6 не отслеживает ничего для клиентов. Он имеет простую конфигурацию с IPv6-адресами нескольких DNS-серверов. Когда хост IPv6 запрашивает у сервера DHCPv6 IPv6-адрес DNS-сервера, он выдает этот адрес, и все.
Поэтому, когда вы используете SLAAC, вам все еще нужен stateless DHCPv6, чтобы узнать о DNS-серверах.
Теперь вы узнали все задачи, которые NPD выполняет для нас:
Router Discovery
MAC Address Discovery
Duplicate Address Detection
Stateless Address Autoconfiguration
Настройка на Cisco
Давайте посмотрим на NPD на некоторых маршрутизаторах, чтобы увидеть, как он работает в реальности. Будет использоваться следующая топология для демонстрации:
Будем использовать OFF1 в качестве хоста, который будет автоматически настраиваться с помощью SLAAC и OFF2 в качестве маршрутизатора. 2001:2:3:4//64 это префикс, который мы будем использовать. Давайте сначала настроим OFF2:
OFF2(config)#ipv6 unicast-routing
Прежде чем OFF2 будет действовать как маршрутизатор, нам нужно убедиться, что включена одноадресная маршрутизация IPv6. Теперь давайте настроим IPv6 адрес на интерфейсе:
OFF2(config)#interface fa0/0
OFF2(config-if)#no shutdown
OFF2(config-if)#ipv6 address 2001:2:3:4::1/64
Перед настройкой OFF1 мы включим отладку NPD на обоих маршрутизаторах, чтобы могли видеть различные сообщения:
OFF1#debug ipv6 nd
ICMP Neighbor Discovery events debugging is on
OFF2#debug ipv6 nd
ICMP Neighbor Discovery events debugging is on
Команда debug ipv6 nd очень полезна, так как она будет показывать различные сообщения, которые использует NPD.
Давайте теперь настроим OFF1:
OFF1(config)#interface fa0/0
OFF1(config-if)#no shutdown
OFF1(config-if)#ipv6 address autoconfig
OFF1 будет настроен для использования SLAAC с командой ipv6 address autoconfig. При включенной отладке вы увидите на своей консоли следующие элементы:
OFF1#
ICMPv6-ND: Sending NS for FE80::C000:6FF:FE7C:0 on FastEthernet0/0
ICMPv6-ND: DAD: FE80::C000:6FF:FE7C:0 is unique.
Он посылает NS для своего собственного IPv6-адреса, и когда никто не отвечает, он понимает, что это единственный хост, использующий этот адрес. Вы также можете видеть, что OFF1 отправляет объявление соседства в сторону OFF2:
OFF1#
ICMPv6-ND: Sending NA for FE80::C000:6FF:FE7C:0 on FastEthernet0/0
OFF2#
ICMPv6-ND: Received NA for FE80::C000:6FF:FE7C:0 on FastEthernet0/0 from FE80::C000:6FF:FE7C:0
Мы можем просмотреть базу данных с информацией L2 и L3 следующим образом:
OFF2#show ipv6 neighbors
IPv6 Address Age Link-layer Addr State
Interface
FE80::C000:6FF:FE7C:0 21 c200.067c.0000 STALE Fa0/0
show ipv6 neighbors покажет вам IPv6-адреса и MAC-адреса. OFF1 также отправит запрос маршрутизатора, а OFF2 в ответ отправит объявление маршрутизатора:
OFF1#
ICMPv6-ND: Sending RS on FastEthernet0/0
OFF2#
ICMPv6-ND: Received RS on FastEthernet0/0 from FE80::C000:6FF:FE7C:0
ICMPv6-ND: Sending solicited RA on FastEthernet0/0
ICMPv6-ND: Sending RA from FE80::C001:6FF:FE7C:0 to FF02::1 on FastEthernet0/0
ICMPv6-ND: MTU = 1500
ICMPv6-ND: prefix = 2001:2:3:4::/64 onlink autoconfig
ICMPv6-ND: 2592000/604800 (valid/preferred)
OFF1#
ICMPv6-ND: Received RA from FE80::C001:6FF:FE7C:0 on FastEthernet0/0
ICMPv6-ND: Selected new default router FE80::C001:6FF:FE7C:0 on FastEthernet0/0
Если вы хотите увидеть все маршрутизаторы, о которых знает ваш хост, вы можете использовать следующую команду:
OFF1#show ipv6 routers
Router FE80::C001:6FF:FE7C:0 on FastEthernet0/0, last update 0 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 msec, Retransmit time 0 msec
Prefix 2001:2:3:4::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Поскольку OFF1 настроен для SLAAC он будет использовать префикс в объявлении маршрутизатора для настройки самого себя:
OFF1#
ICMPv6-ND: Prefix Information change for 2001:2:3:4::/64, 0x0 - 0xE0
ICMPv6-ND: Adding prefix 2001:2:3:4::/64 to FastEthernet0/0
ICMPv6-ND: Sending NS for 2001:2:3:4:C000:6FF:FE7C:0 on FastEthernet0/0
ICMPv6-ND: Autoconfiguring 2001:2:3:4:C000:6FF:FE7C:0 on FastEthernet0/0
ICMPv6-ND: DAD: 2001:2:3:4:C000:6FF:FE7C:0 is unique.
Он будет использовать префикс и автоматически настраивать IPv6-адрес. Прежде чем он использует адрес, он будет использовать DAD, чтобы убедиться, что адрес уникален. Давайте посмотрим IPv6-адрес:
OFF1#show ipv6 int brief
FastEthernet0/0 [up/up]
FE80::C000:6FF:FE7C:0
2001:2:3:4:C000:6FF:FE7C:0
Как вы видите, OFF1 использовал 2001:2:3:4::/64 префикс для настройки самого себя.
Это вся информация о NPD для вас сейчас, давайте продолжим изучение материала обратив подробное внимание на DHCPv6! Статусный DHCPv6 работает аналогично DHCP для IPv4. Мы все еще используем его для предоставления адресов, шлюзов по умолчанию, DNS-серверов и некоторых других опций клиентам, но одним из ключевых отличий являются сообщения, которые мы теперь используем.
DHCP для IPv4 использует сообщения Discover, Offer, Request и ACK. DHCPv6 использует Solicit, Advertise, Request и Reply message.
Время получения сообщения, похожие на сообщения обнаружения. Хост будет использовать это сообщение, когда он ищет IPv6-адрес сервера DHCPv6. Сообщение advertise используется для предоставления хосту IPv6-адреса, шлюза по умолчанию и DNS-сервера. Сообщение запроса используется хостом, чтобы спросить, можно ли использовать эту информацию, и ACK отправляется сервером для подтверждения этого.
Аналогично, как и для DHCP IPv4, когда ваш DHCP-сервер не находится в той же подсети, вам потребуется DHCP relay для пересылки сообщений DHCP на центральный DHCP-сервер.
Протоколы API, как и все в этом мире, активно развиваются. Многие компании, включая GraphQL, gRPC и Thrift, пользуются классическими API SOAP и REST. В списке этих API есть и JSON-RPC.
JSON-RPC, созданный для быстрой разработки многофункциональных сайтов, быстро стал лучшим другом разработчиков.
Давайте разберемся, что это такое, и в чем оно полезно специалистам по разработке приложений и API. Знакомство с JSON-RPC начинается с азов JSON. Так что первая глава данной статьи посвящена общей информации о JSON.
JSON – что это такое, и как оно работает
JSON – это легковесный формат обмена сообщениями, который подходит для более быстрой передачи данных. Именно поэтому он так активно используется в современной разработке.
JSON (JavaScript Object Notation, или нотация объектов JavaScript) производит многократную разбивку данных до тех пор, пока они не примут удобный для обработки вид. В основе JSON лежит JavaScript, поэтому просматривая элементы данных, вы не раз встретите строки, нулевые символы, объекты и бинарные переменные.
JSON разбивает сложные сопоставленные данные на управляемые структуры, облегчая обработку данных на многих языках программирования, и считается независимым от языка ресурсом. Его придумал Дуглас Крокфорд в 2000 году с целью упрощения взаимодействия между веб-приложениями и сервером.
Что такое JSON RPC?
JSON-RPC – это не что иное, как преемник JSON, повсеместно признанный протокол для удаленного вызова процедур (RPC - Remote Procedure Calls). Работая на уровне разработки, JSON-RPC запускает различную структуру данных, определяя задачи для приложений. Это сравнительно новый протокол с узкой областью применения.
Наборы команд, гибкость и сценарии развертывания – все работает с ограничениями. Но, тем не менее, разработчики видят в нем идеальный вариант для простой и быстрой разработки. В простых сценариях данные ограничения не являются помехой и побуждают разработчиков переходить с REST на JSON-RPC. Стоит также добавить, что:
JSON-RPC определяет сетевые ограничения, связанные с обработкой данных.
Легкая конструкция и быстрая обработка – все это подходит для инициации передачи данных с узлами Ethereum.
Будучи транспортно-независимым протоколом, JSON-RPC может использовать для взаимодействия сокеты и HTTP.
Это отличное решение для разработки решений на базе Ethereum с использованием блокчейн.
В настоящий момент предлагается 2 стандарта JSON-RPC: JSON-RPC 1.0 и JSON-RPC 2.0:
JSON-RPC 1.0 не хватает возможностей сразу по нескольким пунктам. Отсутствие названий параметров и пояснений к ошибкам вызывает куда больше проблем, чем кажется. Скорее уж, это метод для одноранговой передачи данных.
Обновленный JSON RPC 2.0 значительно доработали, заполнив ряд пробелов предыдущей версии. Версию 1.0. заменили клиент-серверной 2.0. Кроме того, в 2.0. появились транспортные зависимости.
Разумеется, со временем добавили именованные параметры. Поля урезали. Нет ID для уведомлений; в качестве ответа отправляется только результат/ошибка. В обновленной версии есть дополнительные расширения с информацией об ошибках.
Как пользоваться JSON RPC?
Главная функция протокола заключается в отправке клиентских запросов на сервер (при поддержке JSON-RPC). Здесь под клиентом мы подразумеваем общепринятые приложения, которые развертываются для получения запроса от удаленной системы на консолидированный метод.
Введенные параметры передаются удаленной системе в формате массива или объекта. В зависимости от используемой версии JSON-RPC, удаленная система будет отправлять в источник запроса разные итоговые значения.
Все веб-передачи через JSON-RPC унифицированы и сериализированы с помощью JSON. Запрос JSON-RPC – это вызов удаленного метода. Он состоит из 3 элементов:
Метод. Указывает на строку, которая будет запрашиваться при вызове метода. Существует набор зарезервированных имен с префиксом ‘rpc’ – они предназначаются для внутренних вызовов RPC.
Параметры. Второй элемент JSON-RPC (объект или массив) со значением параметра, который будет переноситься. Параметры не вызываются в каждом вызове.
ID. Целое или строковое число, которое регулярно используется для поддержания баланса между запросами и ответами. Если на запрос нет ответа, то ID автоматически удаляется.
В запросе JSON-RPC получатель обязан вернуться к проверенному ответу на каждый полученный запрос. Добавляются 3 компонента:
Результат – первая и важнейшая часть запроса, передающая данные, которые возвращает вызываемый метод. Его часто называют JSON-stat, и при ошибке он остается пустым.
Ошибка – второй компонент. Появляется, если в процессе вызова что-то идет не так. В ошибке отображаются код и сообщение.
ID ответа указывает на запрос, по которому приходит ответ. Если ответов не требуется, то JSON-RPC использует уведомление, в котором написано, что запрос был без ID. В версии 1.0 ID уведомление приходит пустым, а в версии 2.0. оно полностью отсутствует.
Плюсы от использования JSON-RPC
JSON-RPC – это довольно «умный» протокол, который предлагает своим клиентам множество плюсов:
Простая обработка
JSON-RPC намного проще, чем REST. Его легко понимают люди и машины. Здесь нет сложных команд и наборов данных, так что JSON-RPC идеально подходит для начинающих разработчиков. Этот протокол Unicode предлагает компактную командную строку. Кроме того, он способен обрабатывать данные с именованными фразами или отдельными ключевыми словами. Таким образом, JSON-RPC считается простым и понятным инструментом для работы.
Быстрое время разработки
С JSON-RPC не надо ничего придумывать. Все источники доступны и понятны. Такая простота сокращает время разработки и сроки выхода на рынок. Это самое подходящее решение для разработки приложений в сжатые сроки.
Качественный обмен информацией
JSON-RPC гарантирует своевременный, быстрый и точный обмен данными, поскольку может обрабатывать уведомления и несколько вызовов. Чтобы продолжить свою работу, ему не нужно ждать ответа от сервера или клиента. Если сделан запрос сообщения, то JSON-RPC гарантированно доставит его «адресату». Не важно, насколько сложные компоненты приложения входят в цепочку коммуникации, JSON-RPC обеспечит должный обмен информацией.
Улучшенная производительность API
С помощью JSON-RPC можно создавать API, которые не зависят от развертываемого протокола. Такая возможность крайне важна для улучшения производительности API, т.к. заменяет HTTP и TCP, а также снижает рабочую нагрузку.
Описание результатов
JSON-RPC выдает понятные результаты запроса, которые легко прочитать и обработать. Создание пакетных запросов, объяснение body в HTTP и передача параметров – все это гораздо проще реализовать через JSON-RPC.
Улучшенная передача
JSON-RPC – это очень удобный для передачи инструмент, ведь поддерживает такие платформы, как XMPP, WebSockets, SFTP, SSH и SCP. Данное разграничение позволяет разрабатывать быстрые, простые в отладке и удобные для пользователя API. Кроме того, этот протокол полностью отделяет запрошенный контент от используемого процесса передачи. А любые ошибки в запросах, данные и предупреждения передаются через полезную информацию запроса.
REST и JSON-RPC: что выбрать для разработки API?
Богатый выбор API-ресурсов – это всегда хорошо, но остановиться на каком-то одном варианте бывает не так просто. Ниже мы постараемся помочь разработчикам и объясним ключевые особенности популярных протоколов.
JSON-RPC подходит для начинающих разработчиков с ограниченным количеством ресурсов. JSON-RPC – это очень ограниченный в ресурсах протокол, который отлично выполняет свою функцию. Кроме того, если цель разработчика хоть как-то связана с технологией распределенных реестров, то единственным жизнеспособным решением станет именно JSON-RPC. С таким развертыванием не сможет справиться ни один другой протокол.
Для разработки приложений, использующих технологии распределенных реестров, требуется независимый от протокола API, и JSON-RPC отлично подходит. Он позволяет разработчикам создавать API, которые могут взаимодействовать друг с другом с помощью любого протокола.
Есть еще одна область, в которой JSON-RPC превосходит REST. В REST доступен ограниченный набор глаголов, что приводит к ошибкам при выполнении операции. При использовании REST необходимо подробно описать HTTP-метод, и на это тратится много времени. Кроме того, в REST доступны только CRUD-операции. Так что лучше отдавать предпочтение JSON-RPC.
Тем не менее JSON-RPC нельзя назвать универсальным решением для всего. Его проблема заключается во взаимозависимости. Клиенты должны быть тесно связаны с реализацией служб, поэтому вносить изменения в эту реализацию довольно сложно. При попытке изменить что-то, клиенты чаще всего ломаются.
REST решает такие задачи намного лучше. Например, API на базе REST мало того, что легко создаются, так еще и не отслеживают состояния. Этот протокол совместим с HTTP и предлагает огромное множество HTTP-библиотек. REST позволяет создавать гибкие API. Это идеальное решение для CRUD-операций.
Оба протокола имеют свои плюсы и минусы. Разработчикам необходимо принять взвешенное решение, исходя из главной цели разработки. Например, если разработчику нужны высокопроизводительные вычисления, то стоит остановиться на JSON-RPC.
Если требуется независимая разработка приложения с удобным интерфейсом, то смело выбирайте REST. Не стоит также забывать о безопасности API.
JSON-RPC, graphql, grpc
Два самых известных аналога JSON-RPC – это GraphQL и gRPC. GraphQL – это полностью адаптивная система. Она используется для точной локализации данных запроса и получения только необходимых запрашиваемых данных. Основная черта – ориентация на клиента. Сервер практически никак не участвует в веб-передаче. Клиент сам устанавливает правила для обработки запрошенных данных.
GraphQL относится к языкам запросов, а JSON-RPC относится к удаленному вызову процедур.
Еще есть gRPC – легковесный протокол с акцентом на производительность. Это обновленная версия RPC. В JSON-RPC серверы и клиенты договариваются о запрашиваемых данных, а архитектура не важна. А в gRPC, наоборот, запросы обрабатываются по готовой схеме. Этот протокол может выполняться в любой экосистеме.
JSON-RPC интегрируется с MQTT, Python и Kallithea. Для gRPC доступны такие ресурсы, как .NET, JavaScript, C++, Swift и многие другие.
Главные отличия между всеми решениями заключаются в открытости кода и удобстве для клиентов.
ICMP, который расшифровывается как Internet Control Message Protocol это протокол третьего уровня модели OSI, который используется для диагностики проблем со связностью в сети. Говоря простым языком, ICMP помогает определить может ли достичь пакет адреса назначения в установленные временные рамки. Обычно, ICMP “юзают" маршрутизаторы и устройства третьего уровня.
Для чего используется ICMP?
Основная цель ICMP это отчетность об ошибках. При соединении двух девайсов в сети, если часть данных не доходит до адреса назначения, теряется или превышает допустимые таймауты - ICMP генерирует ошибки.
Второе, и, пожалуй, одно из самых популярных применений ICMP это утилиты ping и traceroute. Термин “пинговать" как - раз связан с протоколом ICMP и “пинговать" хост - означает отправлять ICMP пакеты с целью понять, отвечает ли на них целевое устройство.
Про трассировку
Так и с “трассировкой". Когда говорят “сделайте трассировку маршрута" это означает, что мы хотим увидеть полный маршрут между хостом, на котором выполняется трассировка до хоста назначения. Трассировка покажет каждый из маршрутизаторов на пути до цели и время обработки и прохождения каждого из участков маршрута. Кстати, такой маршрут называется “хопом". Часто говорят: если от узла отправления до узла назначения на пути встретиться 7 маршрутизаторов, то говорят на пути будет 7 хопов. А если на 6 маршрутизаторе пакет обрабатывается дольше обычного, то в среде инженеров говорят “на 6 хопе повышенная задержка". Это один из базовых инструментов того, как можно понять, какой из сетевых узлов на маршруте пакет “сбоит". Именно в этом нам помогает протокол ICMP.
Про пинг
Теперь про ping. Можно сказать, это самый базовый инструмент инженера, который позволяет понять “"А жив ли хост?"
Помимо прочего, пинг поможет понять как долго пакет доходит до адреса назначения и, соответственно, поможет измерить задержку.
Работает ping предельно просто:
Источник отправляет запрос вида ICMP echo request. Это выглядит как вопрос “бро, ты живой?"
Получатель отправляет ответ источнику ICMP echo reply. Это звучит как ответ вида “да, бро, я жив, спасибо!"
Время с момента отправки вопроса до получения ответа суммируется и считается за время пинга
Темная сторона ICMP
На самом деле, с помощью ICMP можно провести атаки на сеть. Эти атаки связаны с отказом устройства в обслуживании (denial-of-service, DoS). Например “флуд - атака", суть которой заключается в отправке огромного количества пинг (ICMP) - запросов на хоста назначения с разных источников. В итоге устройство отвечает кучей пакетов на разные адреса и перегружает собственные мощности и сетевой адаптер.
Так же, раньше была популярна атака Ping of Death. Если кратко, ее суть заключалась в следующем: злоумышленник намеренно отправляет пакет больше максимального размера. Такой пакет фрагментируется на сети на несколько частей, прилетает в буфер устройства и попадает в очередь на сборка пакета “воедино". Переполнение этой очереди приводило к подвисанию хоста и полному отказу в работе.
Что же, теперь вы знаете, что такое ICMP, почему и как он используется в утилитах ping и трассировке, а так же, какие виды атак можно выполнить с помощью ICMP.
Keep calm and Merion!