По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
gRPC — это мощная платформа для работы с удаленными вызовами процедур (Remote Procedure Calls). RPC позволят писать код так, как будто он будет выполняться на локальном компьютере, даже если он может выполняться на другом компьютере.
Что такое RPC?
RPC — это форма взаимодействия клиент-сервер, в которой используется вызов функции, а не обычный вызов HTTP. Идея в том, что мы можем вызвать и выполнить функцию где-то на удаленной системе, как если бы это была локальная функция.
Он использует IDL (Interface Definition Language - язык описания интерфейса) как форму контракта на вызываемые функции и тип данных.
RPC — это протокол "запрос-ответ", т.е. он следует модели "клиент-сервер":
Клиент делает запрос на выполнение процедуры на удаленном сервере. Как и при синхронном локальном вызове, клиент приостанавливается до тех пор, пока не будут возвращены результаты процедуры. Параметры процедуры передаются по сети на сторону сервера. Процедура выполняется на сервере и, наконец, результаты передаются обратно клиенту.
gRPC воспроизводит этот архитектурный стиль взаимодействия клиент-сервер через вызовы функций.
Таким образом, gRPC технически не является новой концепцией. Скорее, он был заимствован из этой старой техники и улучшен, что сделало ее очень популярной.
Что такое gRPC?
В 2015 году Google открыл исходный код своего проекта, который в конечном итоге получил название gRPC.
Но что на самом деле означает буква «g» в gRPC? Многие люди могут предположить, что это для Google, потому что Google это сделал, но это не так. Google меняет значение «g» для каждой версии до такой степени, что они даже сделали README, чтобы перечислить все значения.
С момента появления gRPC он приобрел довольно большую популярность, и многие компании используют его.
Есть много причин, по которым gRPC так популярен: простая абстракция, он поддерживается во многих языках и он очень эффективный.
И помимо всех вышеперечисленных причин, gRPC популярен потому, что очень популярны микросервисы и имеется большое количество взаимодействий между ними. Именно здесь gRPC помогает больше всего, предоставляя поддержку и возможности для решения типичных проблем, возникающих в таких ситуациях.
А поскольку разные сервисы могут быть написаны на разных языках, gRPC поставляется с несколькими библиотеками для их поддержки.
Архитектура gRPC
Мы сказали что производительность gRPC очень высока, но что делает ее такой хорошей? Что делает gRPC намного лучше, чем RPC, если их дизайн очень похож? Вот несколько ключевых отличий, которые делают gRPC столь эффективным.
HTTP/2
HTTP был с нами очень долго. Сейчас почти все серверные службы используют этот протокол.
HTTP/1.1 долгое время оставался актуальным, затем в 2015 году, появился HTTP/2, который фактически заменил HTTP/1.1 как самый популярный транспортный протокол в Интернете.
Если вы помните, что 2015 год был также годом выхода gRPC, и это было вовсе не совпадение. HTTP/2 также был создан Google для использования gRPC в его архитектуре.
HTTP/2 — одна из важных причин, почему gRPC может работать так хорошо. И в следующем разделе вы поймете, почему.
Мультиплексирование запроса/ответа
В традиционном протоколе HTTP невозможно отправить несколько запросов или получить несколько ответов вместе в одном соединении. Для каждого из них необходимо создать новое соединение.
Такой вид мультиплексирования запроса/ответа стал возможен в HTTP/2 благодаря введению нового уровня HTTP/2, называемого binary framing.
Этот двоичный уровень инкапсулирует и кодирует данные. На этом уровне HTTP-запрос/ответ разбивается на кадры (они же фреймы).
Фрейм заголовков (HEADERS frame) содержит типичную информацию заголовков HTTP, а фрейм данных (DATA frame) содержит полезные данные. Используя этот механизм, можно получить данные из нескольких запросов в одном соединении.
Это позволяет получать полезные данные из нескольких запросов с одним и тем же заголовком, тем самым идентифицируя их как один запрос.
Сжатие заголовка
Вы могли столкнуться со многими случаями, когда заголовки HTTP даже больше, чем полезная нагрузка. И HTTP/2 имеет очень интересную стратегию под названием HPack для решения этой проблемы.
Во-первых, все в HTTP/2 кодируется перед отправкой, включая заголовки. Это помогает повысить производительность, но это не самое важное в сжатии заголовков.
HTTP/2 сопоставляет заголовок как на стороне клиента, так и на стороне сервера. Из этого HTTP/2 может узнать, содержит ли заголовок одно и то же значение, и отправляет значение заголовка только в том случае, если оно отличается от предыдущего заголовка.
Как видно на картинке выше, запрос № 2 отправит только новый путь, так как другие значения точно такие же как и были. И да, это значительно сокращает размер полезной нагрузки и, в свою очередь, еще больше повышает производительность HTTP/2.
Что такое Protocol Buffer (Protobuf)?
Protobuf — это наиболее часто используемый IDL для gRPC. Здесь вы храните свои данные и функциональные контракты в виде так называемого прото-файла. По сути это протокол сериализации данных, такой как JSON или XML.
Выглядит это так:
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
}
Так мы определили сообщение Person с полями name, id и email
Поскольку это форма контракта то и клиент, и сервер должны иметь один и тот же прото-файл. Файл proto действует как промежуточный контракт для клиента, чтобы вызвать любые доступные функции с сервера.
Protobuf также имеет собственные механизмы, в отличие от обычного REST API, который просто отправляет строки JSON в виде байтов. Эти механизмы позволяют значительно уменьшить полезную нагрузку и повысить производительность.
Что еще может предложить gRPC?
Метаданные
Вместо обычного заголовка HTTP-запроса в gRPC есть то, что называется метаданными (Metadata). Метаданные — это тип данных «ключ-значение», которые можно установить как на стороне клиента, так и на стороне сервера.
Заголовок может быть назначен со стороны клиента, в то время как серверы могут назначать заголовок и трейлеры, если они оба представлены в виде метаданных.
Потоковая передача
Потоковая передача (Streaming) — это одна из основных концепций gRPC, когда в одном запросе может выполняться несколько действий. Это стало возможным благодаря упомянутой ранее возможности мультиплексирования HTTP/2.
Существует несколько видов потоковой передачи:
Server Streaming RPC: когда клиент отправляет один запрос, а сервер может отправить несколько ответов. Например, когда клиент отправляет запрос на домашнюю страницу со списком из нескольких элементов, сервер может отправлять ответы по отдельности, позволяя клиенту использовать отложенную загрузку.
Client Streaming RPC: когда клиент отправляет несколько запросов, а сервер отправляет обратно только один ответ. Например, zip/chunk, загруженный клиентом.
Bidirectional Streaming RPC: клиент и сервер одновременно отправляют сообщения друг другу, не дожидаясь ответа.
Перехватчики
gRPC поддерживает использование перехватчиков для своего запроса/ответа. Они перехватывают сообщения и позволяют вам изменять их.
Это звучит знакомо? Если вы работали с HTTP-процессами в REST API, перехватчики очень похожи на middleware (оно же промежуточное ПО).
Библиотеки gRPC обычно поддерживают перехватчики и обеспечивают простую реализацию. Перехватчики обычно используются для:
Изменения запроса/ответа перед передачей. Это можно использовать для предоставления обязательной информации перед отправкой на клиент/сервер.
Позволяет вам манипулировать каждым вызовом функции, например, добавлять дополнительные логи для отслеживания времени отклика.
Балансировки нагрузки
Если вы еще не знакомы с балансировкой нагрузки, это механизм, который позволяет распределять клиентские запросы по нескольким серверам.
Но балансировка нагрузки обычно делается на уровне прокси (например, nginx). Так причем это здесь?
Дело в том, что gRPC поддерживает метод балансировки нагрузки клиентом. Он уже реализован в библиотеке Golang и может быть легко использован.
Хотя это может показаться какой-то магией, это не так. Там есть что-то типа преобразователя DNS для получения списка IP-адресов и алгоритм балансировки нагрузки под капотом.
Отмена вызова
Клиенты gRPC могут отменить вызов gRPC, когда им больше не нужен ответ. Однако откат на стороне сервера невозможен.
Эта функция особенно полезна для потоковой передачи на стороне сервера, когда может поступать несколько запросов к серверу. Библиотека gRPC оснащена шаблоном метода наблюдателя, чтобы узнать, отменен ли запрос, и позволить ей отменить несколько соответствующих запросов одновременно.
Почитать лекцию №20 про протоколы передачи данных нижнего уровня можно тут.
Обычно называется и маркируется как Wi-Fi 802.11, который широко используется для передачи данных по беспроводной сети в радиочастотах 2,4 и 5 ГГц. Микроволновые печи, радиолокационные системы, Bluetooth, некоторые любительские радиосистемы и даже радионяня также используют радиочастоту 2,4 ГГц, поэтому WiFi может создавать помехи и мешать работе другим системам.
Мультиплексирование
Спецификации 802.11 обычно используют форму частотного мультиплексирования для передачи большого количества информации по одному каналу или набору частот. Частота сигнала-это просто скорость, с которой сигнал меняет полярность в течение одной секунды; следовательно, сигнал 2,4 ГГц-это электрический сигнал, передаваемый по проводу, оптическому волокну или воздуху, который меняет полярность с положительной на отрицательную (или отрицательную на положительную) 2,4 × 109 раз в секунду.
Чтобы понять основы беспроводной передачи сигналов, лучше всего начать с рассмотрения идеи несущей и модуляции. Рисунок 1 иллюстрирует эти концепции.
На рисунке 1 выбрана одна центральная частота; канал будет представлять собой диапазон частот по обе стороны от этой центральной частоты. В результирующем канале две несущие частоты выбираются таким образом, чтобы они были ортогональны друг другу-это означает, что сигналы, передаваемые на этих двух несущих частотах, не будут мешать друг другу. Они обозначены на рисунке как OSF 1 и OSF 2. Каждая из этих несущих частот, в свою очередь, фактически является более узким каналом, позволяя модулировать фактический сигнал "0" и "1" на канале. Модуляция, в данном случае, означает изменение фактической частоты сигнала вокруг каждой из частот.
Модуляция просто означает изменение несущей таким образом, чтобы сигнал передавался так, чтобы приемник мог его надежно декодировать.
Таким образом, в спецификации 802.11 используется схема мультиплексирования с ортогональным частотным разделением каналов (Orthogonal Frequency Division Multiplexing- OFDM), а фактические данные кодируются с использованием частотной модуляции (Frequency Modulation-FM).
Важно
Один из сбивающих с толку моментов мультиплексирования заключается в том, что оно имеет два значения, а не одно. Либо это означает размещение нескольких битов на одном носителе одновременно, либо возможность одновременного взаимодействия нескольких хостов с использованием одного и того же носителя. Какое из этих двух значений подразумевается, можно понять только в конкретном контексте. В этой лекции применяется первое значение мультиплексирования, разбиение одного носителя на каналы, чтобы можно было передавать несколько битов одновременно.
Скорость, с которой данные могут передаваться в такой системе (полоса пропускания), напрямую зависит от ширины каждого канала и способности передатчика выбирать ортогональные частоты. Таким образом, для увеличения скорости 802.11 были применены два разных метода. Первый - просто увеличить ширину канала, чтобы можно было использовать больше несущих частот для передачи данных. Второй - найти более эффективные способы упаковки данных в один канал с помощью более сложных методов модуляции. Например, 802.11b может использовать канал шириной 40 МГц в диапазоне 2,4 ГГц, а 802.11ac может использовать канал шириной 80 или 160 МГц в диапазоне 5 ГГц.
Пространственное мультиплексирование
Другие формы мультиплексирования для увеличения пропускной способности между двумя устройствами также используются в серии спецификаций 802.11. Спецификация 802.11n представила Multiple Input Multiple Output (MIMO), которые позволяют сигналу проходить разными путями через единую среду (воздух). Это может показаться невозможным, поскольку в комнате только один "воздух", но беспроводные сигналы фактически отражаются от различных объектов в комнате, что заставляет их проходить через пространство разными путями. Рисунок 2 демонстрирует это.
На рисунке 2, если предположить, что передатчик использует антенну, которая будет передавать во всех направлениях (всенаправленная антенна), есть три пути через одно пространство, помеченные 1, 2 и 3. Передатчик и приемник не могут "видеть" три отдельных пути, но они могут измерять силу сигнала между каждой парой антенн и пытаться посылать различные сигналы между внешне разделенными парами, пока не найдут несколько путей, по которым могут быть отправлены различные наборы данных.
Второй способ использования нескольких антенн - это формирование луча. Обычно беспроводной сигнал, передаваемый от антенны, охватывает круг (3D-шар). При формировании луча, он формируется с помощью одного из различных методов, чтобы сделать его более продолговатым. Рисунок 3 иллюстрирует эти концепции.
В несформированном узоре сигнал представляет собой шар или шар вокруг кончика антенны- нарисованный сверху, он выглядит как простой круг, простирающийся до самой дальней точки в форме шара. С помощью отражателя луч может быть сформирован или сформирован в более продолговатую форму. Пространство позади отражателя и по бокам луча будет получать меньше (или вообще не получать, для очень плотных лучей) мощности передачи. Как можно построить такой отражатель? Самый простой способ - это физический барьер, настроенный на отражение силы сигнала, подобно тому, как зеркало отражает свет или стена отражает звук. Ключ - это точка в сигнале передачи, в которой устанавливается физический барьер. Рисунок 4 будет использоваться для объяснения ключевых моментов в форме сигнала, отражении и гашении.
Типичная форма волны следует за синусоидальной волной, которая начинается с нулевой мощности, увеличивается до максимальной положительной мощности, затем возвращается к нулевой мощности, а затем проходит цикл положительной и отрицательной мощности. Каждый из них представляет собой цикл- частота относится к числу повторений этого цикла в секунду. Вся длина волны в пространстве вдоль провода или оптического волокна называется длиной волны. Длина волны обратно пропорциональна частоте- чем выше частота, тем короче длина волны.
Ключевой момент, который следует отметить на этой диаграмме, - это состояние сигнала в точках четверти и половины длины волны. В четвертьволновой точке сигнал достигает наивысшей мощности; если объект или другой сигнал интерферирует в этой точке, сигнал будет либо поглощен, либо отражен. В точке полуволны сигнал находится на минимальной мощности; если нет смещения или постоянного напряжения на сигнале, сигнал достигнет нулевой мощности. Чтобы отразить сигнал, вы можете расположить физический объект так, чтобы он отражал мощность только в точке четверти волны. Физическое расстояние, необходимое для этого, будет, конечно, зависеть от частоты, так же как длина волны зависит от частоты.
Физические отражатели просты. Что делать, если вы хотите иметь возможность динамически формировать луч без использования физического отражателя? Рисунок 5 иллюстрирует принципы, которые вы можете использовать для этого.
Светло-серые пунктирные линии на рисунке 5 представляют собой маркер фазы; два сигнала находятся в фазе, если их пики выровнены, как показано слева. Два сигнала, показанные в середине, находятся на четверть вне фазы, так как пик одного сигнала совпадает с нулевой точкой или минимумом второго сигнала. Третья пара сигналов, показанная в крайнем правом углу, является комплементарной, или на 180 градусов вне фазы, так как положительный пик одного сигнала совпадает с отрицательным пиком второго сигнала. Первая пара сигналов будет складываться вместе; третья пара сигналов будет погашена. Вторая пара может, если она правильно составлена, отражать друг друга. Эти три эффекта позволяют сформировать пучок, как показано на рисунке 6.
Одна система формирования луча может использовать или не использовать все эти компоненты, но общая идея состоит в том, чтобы ограничить луч в пределах физического пространства в среде - как правило, свободное распространение в воздухе. Формирование луча позволяет использовать общую физическую среду в качестве нескольких различных каналов связи, как показано на рисунке 7.
На рисунке 7 беспроводной маршрутизатор использовал свои возможности формирования луча для формирования трех разных лучей, каждый из которых направлен на другой хост. Маршрутизатор теперь может отправлять трафик по всем трем из этих сформированных лучей с более высокой скоростью, чем если бы он обрабатывал все пространство как единую совместно используемую среду, потому что сигналы для A не будут мешать или перекрываться с информацией, передаваемой в B или C.
Совместное использование канала
Проблема мультиплексирования в беспроводных сигналах связана с совместным использованием одного канала, как в системах проводных сетей. В решениях, разработанных для совместного использования единой беспроводной среды, преобладают две специфические проблемы: проблема скрытого узла и проблема мощности передачи / приема (которую также иногда называют перегрузкой приемника). На рисунке 8 показана проблема со скрытым узлом.
Три круга на рисунке 8 представляют три перекрывающихся диапазона беспроводных передатчиков в точках A, B и C. Если A передает в сторону B, C не может слышать передачу. Даже если C прослушивает свободный канал, A и C могут передавать одновременно, что вызывает конфликт в B.
Проблема скрытого узла усугубляется из-за того, что мощность передачи по сравнению с мощностью принятого сигнала, и реальность воздуха как среды. Главное практическое правило для определения мощности радиосигнала в воздухе - сигнал теряет половину своей мощности на каждой длине волны в пространстве, которое он проходит. На высоких частотах сигналы очень быстро теряют свою силу, что означает, что передатчик должен послать сигнал с мощностью на несколько порядков больше, чем его приемник способен принять.
Очень сложно создать приемник, способный "слушать" локальный передаваемый сигнал в полную силу, не разрушая приемную схему, а также способный "слышать" сигналы очень низкой мощности, необходимые для расширения диапазона действия устройства. Другими словами, передатчик насыщает приемник достаточной мощностью, чтобы во многих ситуациях "уничтожить" его. Это делает невозможным в беспроводной сети для передатчика прослушивать сигнал во время его передачи и, следовательно, делает невозможным реализацию механизма обнаружения коллизий, используемого в Ethernet (как пример).
Механизм, используемый 802.11 для совместного использования одного канала несколькими передатчиками, должен избегать проблем со скрытым каналом и приемником. 802.11 WiFi использует множественный доступ с контролем несущей / предотвращение конфликтов (Carrier Sense Multiple Access/Collision Avoidance -CSMA/CA) для согласования использования канала. CSMA/CA похож на CSMA/CD:
Перед передачей отправитель прослушивает сообщение, чтобы определить, передает ли его другое устройство.
Если слышна другая передача, отправитель "замирает" на определенный случайный период времени перед повторной попыткой- эта отсрочка предназначена для предотвращения того, чтобы несколько устройств, слышащие одну и ту же передачу, не пытались передать данные одновременно.
Если никакой другой передачи не слышно, отправитель передает весь кадр- отправитель не может принять сигнал, который он передает, поэтому в этой точке нет способа обнаружить коллизию.
Получатель отправляет подтверждение кадра при получении; если отправитель не получает подтверждения, он предполагает, что произошла коллизия, отключается на случайное количество времени и повторно отправляет кадр.
Некоторые системы WiFi также могут использовать Request to Send/Clear to Send (RTS / CTS). В таком случае:
Отправитель передает RTS.
Когда канал свободен, и никакая другая передача не запланирована, получатель отправляет CTS.
Получив CTS, отправитель передает данные
Какая система будет обеспечивать более высокую пропускную способность, зависит от количества отправителей и получателей, использующих канал, длины кадров и других факторов.
Маршалинг данных, контроль ошибок и управление потоком данных
Маршалинг данных в 802.11 аналогичен Ethernet; в каждом пакете есть набор полей заголовка фиксированной длины, за которыми следуют транспортируемые данные и, наконец, четыре октетная Frame Check Sequence (FCS), которая содержит CRC для содержимого пакета. Если получатель может исправить ошибку на основе информации CRC, он это сделает, в противном случае получатель просто не подтверждает получение кадра, что приведет к повторной передаче кадра отправителем.
Порядковый номер также включен в каждый кадр, чтобы гарантировать, что пакеты принимаются и обрабатываются в том порядке, в котором они были переданы. Управление потоком обеспечивается в системе RTS / CTS приемником, ожидающим отправки CTS, пока у него не будет достаточно свободного места в буфере для приема нового пакета, чтобы промежуточные системы могли обнаруживать конечные системы; это называется протоколом End System to Intermediate System (ES-IS).
В обычной корпоративной сети доступ к серверам из филиалов организации может осуществляться, чаще всего, подключением к серверам, расположенным в центральном офисе. Но при расположении серверной инфраструктуры в облаке параметры связи рабочих станций с серверами будут зависеть уже не от канала связи от каждого конкретного филиала до центрального офиса, а от канала связи всех отделений организации с ЦОД облачного провайдера, чьими услугами пользуется организация для формирования облачной инфраструктуры.
Переход в облака поставил перед разработчиками ПО и сетевыми инженерами ряд новых условий, вызывающих задержку сигнала, которые им приходится учитывать для формирования качественного доступа к данным в облаке. Например, задержка длительностью 500мс приводит к снижению трафика Google на 20%, а задержка в 100мс сокращает продажи Amazon на 1%.
Время задержки может быть очень важным аспектом во время работы с виртуальными рабочими столами (VDI), потоковым вещанием, трейдингом, передовыми web-сервисами, базами данных, терминальными приложениями. Но задержка не столь критична для таких сервисов как электронная почта или работа с документами.
QoS и SLA
Существует проблема обеспечения необходимого качества обслуживания (QoS). Разные виды трафика имеют различные требования к рабочим характеристикам сети. Чувствительность видов трафика была взята из и показана в таблице 1
Таблица 1. Чувствительность различных приложений сетевым характеристикам
Тип трафика
Уровень чувствительности к сетевым характеристикам
Полоса
пропускания
Потери
Задержка
Джиттер
Голос
Очень низкий
Средний
Высокий
Высокий
Электронная коммерция
Низкий
Высокий
Высокий
Низкий
Транзакции
Низкий
Высокий
Высокий
Низкий
Электронная почта
Низкий
Высокий
Низкий
Низкий
Telnet
Низкий
Высокий
Средний
Низкий
Поиск в сети "от случая
к случаю"
Низкий
Средний
Средний
Низкий
Постоянный поиск в
сети
Средний
Высокий
Высокий
Низкий
Пересылка файлов
Высокий
Средний
Низкий
Низкий
Видеоконференция
Высокий
Средний
Высокий
Высокий
Мультикастинг
Высокий
Высокий
Высокий
Высокий
Рекомендации МСЭ-Т по обеспечению QoS для сетей описываются в рекомендациях Y.1540 - стандартные сетевые характеристики для передачи пакетов в сетях IP, и Y.1541 нормы для параметров, определенных в Y.1540.
Данные рекомендации важны для всех участников сети: провайдеров и операторов, пользователей и производителей оборудования. При создании оборудования, планировании развертывания и оценке сетей IP, оценка качества функционирования сети все будут опираться на соответствие характеристик требованиям потребителей.
Основные характеристики, рассматриваемые в рекомендации Y.1540:
производительность сети;
надежность сети/сетевых элементов;
задержка;
вариация задержки (jitter);
потери пакетов.
Подробнее о данных характеристиках следует прочитать в вышеназванных рекомендациях. В таблице 2 указаны нормы на определенными в Y.1540 характеристики и распределены по классам качества обслуживания (QoS).
Таблица 2 - Нормы для характеристик сетей IP с распределением по классам QoS
Сетевые
характеристики
Классы QoS
0
1
2
3
4
5
Задержка доставки пакета
IP, IPTD
100 мс
400 мс
100 мс
400 мс
1 с
Н
Вариация задержки
пакета IP, IPDV
50 мс
50 мс
Н
Н
Н
Н
Коэффициент потери
пакетов IP, IPLR
1х10 3
1х10 3
1х10 3
1х10 3
1х10 3
Н
Коэффициент ошибок
пакетов IP, IPER
1х10 4
1х10 4
1х10 4
1х10 4
1х10 4
Н
Примечание: Н не нормировано. Рекомендация Y.1541 устанавливает соответствие между классами QoS и приложениями:
Класс 0 приложения реального времени, чувствительные к джиттеру, характеризуемые высоким уровнем интерактивности (VoIP, видеоконференции);
Класс 1 приложения реального времени, чувствительные к джиттеру, интерактивные (VoIP, видеоконференции);
Класс 2 транзакции данных, характеризуемые высоким уровнем интерактивности (например, сигнализация);
Класс 3 транзакции данных, интерактивные;
Класс 4 приложения, допускающие низкий уровень потерь (короткие транзакции, массивы данных, потоковое видео)
Класс 5 традиционные применения сетей IP.
Таким образом некоторые из облачных сервисов вполне могут попадать в классы 0 и 1, а значит следует учитывать время задержки и стараться сделать так, чтобы она не превышала 100 мс.
Задержки в сетях
Подключение к облаку через VPN аналогично подключению к центральному офису организации по VPN, за исключением лишь того, что если в обычной корпоративной сети все филиалы организации подключались к центральному офису, то теперь подключение филиалов и центрального офиса в том числе будет осуществляться к ЦОД облачного провайдера.
Для проверки задержки в большинстве ОС используется команда ping, а для проверки пути прохождения пакета команда tracert, которые подробнее рассмотрим ниже.
Предположим, что домашняя сеть является подобием корпоративной сети малого предприятия. В таблице в приложении А собраны данные из статьи с указанием расположения ЦОД.
Воспользуемся этими данными чтобы проверить задержку сигнала от текущей домашней сети, расположенной в городе Москва, без учета VPN, до web-сервера некоторых компаний, владеющих, ЦОД, расположенных в разных городах, тем самым проверяя разницу в задержке в зависимости от расположения ЦОД облачного провайдера.
Для проверки задержки воспользуемся "Командной строкой" Windows и командами ping и tracert. Команда ping используется для проверки целостности и качества соединения в сети на основе протоколов TCP/IP. Команда tracert строит маршрут через коммутационные узлы между компьютером и конечным сервером и выводит их IP-адреса и время
задержки. На рисунках 1 и 2 представлена системная справка по командам, соответственно, tracert и ping.
Проведем тест проверки задержки до домена DataLine dtln.ru, расположенного ближе всего к домашней сети (рисунки 3 и 4).
Как видно из результатов на рисунке 5.3, было передано и получено 4 пакета объемом 32 байта. Время обмена одним пакетом составило 1 миллисекунду.
Команда tracert вывела следующие данные:
1, 2, 3 - номер перехода;
<1 мс <1 мс <1 мс время ответа для 3-х попыток (в данном случае все попытки менее 1 мс);
185.3.141.232 IP-адреса (в данном случае IP-адрес домена
dtln.ru)
Согласно проверке данного IP на сайте 2ip.ru, данный домен базируется по тому же адресу на карте, что и указано в таблице в приложении Б. Таким образом можно сделать вывод, что web-сервер большинства компаний из списка вероятнее всего находится на территории одного из их ЦОД, но даже если и нет, то позволяет сделать выводы о доступности ресурса.
Аналогично проверим ping для остальных компаний, результаты представим на рисунке 5.5. В качестве опорного времени задержки будет использовано среднее и максимальное время приема-передачи.
Из данных рисунка 5 можно сделать вывод, что среднее значение времени задержки в пределах Москвы из сети, также находящейся в пределах Москвы, чаще всего не превышает 10мс.
Можно сравнить данные значения с ping до серверов Amazon Web Services в разных регионах с сайта cloudping.info (рисунок 6).
VPN без шифрования теоретически позволил бы сократить эту задержку в связи с использованием "прямого туннеля" между "офисом" и ЦОД. Шифрование будет вносить уже свою задержку, проверить которую в данных условиях нет возможности.
В локальных сетях корпоративной сети и сети ЦОД задержка исчисляется в микросекундах. В сети ЦОД предъявляются высокие требования к быстродействию сети, современные решения Ethernet для ЦОД должны быть широкополосными и поддерживать скорости 10, 25, 40, 50, 100 Гбит/с, обеспечивать низкие задержки до 1-2 мкс для связи серверов (через три коммутатора), и многие другие.
Скорость интернет-канала
Передача видео через сети связи, будь то видео с камер наблюдения или же видеоконференции, являются одними из самых требовательных с скорости передачи данных. Если для работы с документами может быт достаточно скорости в 100 Кбит/с, то для передачи видео понадобится уже примерно 2 Мбит/с.
Для некоторых приложений, таких как IP-телефония, желательно, чтобы уровень задержек был низким, а мгновенная пропускная способность канала была больше определенного порогового значения: не ниже 24 Кбит/с для ряда приложений IP-телефонии, не ниже 256 Кбит/с для приложений, обрабатывающих видеопоток в реальном времени. Для некоторых приложений задержки не так критичны, но, с другой стороны, желательна высокая пропускная способность, например, для передачи файлов.
Например, компания Ivideon предлагает услуги облачного видеонаблюдения, и у них на сайте даются следующие требования к интернет-каналу для разного качества видеопотока. Данные представлены в таблице 3.
Таблица 3 Требования к интернет-каналу для одной камеры видеонаблюдения при разных разрешения при частоте 25 кадров/сек
Разрешение Качество изображения
Рекомендуемая скорость
1280х720 (1Mpx) /25к/с
1 Мбит/с
1920x1080 (2Mpx) /25к/с
2 Мбит/с
2048x1536 (3Mpx) /25к/с
2 Мбит/с
2592x1728 (4Mpx) /25к/с
2 Мбит/с
Но для работы с терминальными сессиями достаточно канала в 128-256 Кбит/с на пользователя. Для 50 пользователей понадобится 6.25 Мбит/с.
Компания 1cloud.ru при выборе ширины канала связи предлагает скорость соединения в диапазоне от 10 до 100 Мбит/с для доступа к виртуальному серверу.
Внутри облака сетевые соединения между виртуальными машинами имеют пропускную способность в 1 Гбит/с.
RDP-сессия
Для теста потребления трафика при использовании удаленного подключения RDP был проведен эксперимент.
Два персональных компьютера находятся в одной локальной сети и подключены к интернету. Один выступает сервером удаленного доступа, второй подключается к нему посредством встроенной в Windows программы
"Подключение к удаленному рабочему столу" по протоколу RDP. На сервере запускается видео в интернете. Для захвата трафика и анализа используется ПО Wireshark
Параметры подключения:
размер удаленного рабочего стола 1920х1080
глубина цвета 15 бит
выбранная скорость соединения 56 Кбит/с
дополнительные возможности отключены (рисунок 7)
Wireshark программа для захвата и анализа сетевого трафика. Данная программа работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс, и мощнейшую систему фильтров.
Во время подключения к удаленному рабочему столу программа замеряла отправленные и поступившие пакеты данных. Эти пакеты были отфильтрованы по IP-адресу сервера, а также по протоколу RDP. Интерфейс программы представлен на рисунке 8.
График ввода/вывода данных по IP-адресу сервера по протоколу RDP представлен на рисунке 9.
На графике на рисунке 9 видно два "всплеска" данных, т.е. две сессии подключения к серверу. Во время первой сессии проводилась работа с тяжеловесным графическим приложением. Во время второй сессии было включено видео, затем производился web-серфинг в браузере машины с некоторыми графическими материалами на странице.
Как видно по графику, в пиковый момент была передача данных 5.5 Мбит/с. В последние моменты web-серфинга 0,65 Мбит/с.
Таким образом можем сделать вывод, что протокол RDP не укладывается в ранее заявленный диапазон до 128 Кбит/с. Однако стоит учитывать, что RDP-сессия изначально очень требовательна к сети и является, по сути, передачей видеотрафика.
Общедоступной информации в сети для анализа влияния облачной инфраструктуры на сеть, по крайней мере в русскоязычном сегменте интернета, чрезвычайно мало. Исследований по теме облачных вычислений недостаточно для заключения результата, и, в основном, это анализы финансовых затрат или производительности серверов.
Наиболее подходящей темой для дискуссий на тему влияния облачной инфраструктуры на сеть могут служить только качество обслуживания (QoS) и договор о предоставлении услуг SLA, но данные темы слишком обширны и требует более углубленного внимания, а вопросы, связанные с ними, требуют внимания соответствующих специалистов.