ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

12 минут чтени€

¬ 2012 году ƒжим –оскинд разработал новый транспортный протокол, основной целью которого было увеличение скорости, с которой данные могут передаватьс€ по относительно стабильным высокоскоростным сет€м. ¬ частности:

  • —окращение трехстороннего рукопожати€ до запуска одного пакета (нулевое рукопожатие)
  • ”меньшение количества повторно передаваемых пакетов, необходимых дл€ передачи данных
  • ”меньшение блокировки заголовка между несколькими потоками данных в пределах одного потока TCP, вызванной потерей пакетов

”меньшение рукопожати€ при запуске

 ак правило, значение rtt нельз€ изменить, поскольку оно обычно ограничено физическим рассто€нием и скоростью соединени€ между отправителем и получателем. “аким образом, один из лучших способов сократить общее врем€ передачи данных - просто уменьшить количество циклов обмена, необходимых между отправителем и получателем дл€ передачи заданного потока или блока данных. QUIC разработан дл€ сокращени€ количества циклов приема-передачи, необходимых дл€ установки нового соединени€, от трехстороннего подтверждени€ TCP до процесса запуска с нулевым временем приема-передачи. ƒл€ этого QUIC использует серию криптографических ключей и хэшей; процесс состоит из:

  1.  лиент отправл€ет серверу приветствие (CHLO), содержащее требование подтверждени€, которое представл€ет собой список типов сертификатов, которые клиент примет дл€ проверки идентичности сервера; набор сертификатов, к которым у клиента есть доступ; и хэш сертификата, который клиент намереваетс€ использовать в этом соединении. ќдно конкретное поле, маркер адреса источника (STK) будет оставлено пустым, потому что раньше с этим сервером не было св€зи.
  2. —ервер будет использовать эту информацию дл€ создани€ STK на основе информации, предоставленной в первоначальном приветствии клиента и исходном IP-адресе клиента. —ервер отправл€ет отклонение (REJ), которое содержит этот STK.

 ак только клиент получает STK, он включает его в будущие пакеты приветстви€. ≈сли STK совпадает с ранее использованным STK с этого IP-адреса, сервер примет приветствие.

ѕримечание: Ёта пара IP-адрес / STK может быть украдена, и, следовательно, исходный IP-адрес может быть подменен злоумышленником с доступом к любой св€зи с этой парой. Ёто известна€ проблема в QUIC, котора€ рассматриваетс€ в документации QUIC.

ƒл€ сравнени€, TCP требует, как минимум полтора rtts дл€ создани€ нового сеанса:

SYN, SYN-ACK, а затем следующий ACK. —колько времени экономит при переходе на одно соединение rtt?  онечно, это зависит от реализации клиентского и серверного приложений. ќднако многие веб-страницы и приложени€ дл€ мобильных устройств должны подключатьс€ к множеству разных серверов (возможно, к сотн€м) дл€ создани€ единой веб-страницы. ≈сли каждое из этих подключений уменьшить с полутора до одного RTT, это может значительно снизить производительность.


—окращение повторных передач

QUIC использует р€д различных механизмов дл€ уменьшени€ количества повторно передаваемых пакетов:

  • ¬ключа€ Forward Error Correction (FEC) во все пакеты; это позвол€ет получателю (часто) восстанавливать поврежденную информацию, а не запрашивать ее повторно.
  • »спользование отрицательных подтверждений (NACK) вместо SACK или механизма тройного ACK дл€ запроса повторной передачи определенных пор€дковых номеров; это предотвращает неоднозначность между запросом на повторную передачу и услови€ми сети, которые вызывают отправку нескольких подтверждений.
  • »спользование быстрых подтверждений, как описано ранее дл€ TCP.
  • »спользование управлени€ окном предотвращени€ перегрузки CUBIC.

ћеханизм предотвращени€ перегрузки CUBIC - самый интересный из них. CUBIC пытаетс€ выполнить двоичный поиск между последним размером окна перед отбрасыванием пакета и некоторым меньшим размером окна, рассчитанным с использованием множительного коэффициента.  огда обнаруживаетс€ потер€ пакета (либо через тайм-аут RTO, либо через NACK), максимальный размер окна (WMAX) устанавливаетс€ равным текущему размеру окна, и вычисл€етс€ новый минимальный размер окна (WMIN).

ќкно отправител€ устанавливаетс€ на WMIN, а затем быстро увеличиваетс€ до размера окна посередине между WMIN и WMAX.  ак только окно достигает этой средней точки, размер окна очень медленно увеличиваетс€ при так называемом зондировании, пока не встретитс€ следующий сброс пакета. Ётот процесс позвол€ет CUBIC находить максимальную скорость передачи чуть ниже точки, в которой сеть начинает довольно быстро отбрасывать пакеты.


»сключение блокировки начала строки

"≈дина€ транзакци€" в »нтернете часто €вл€етс€ не "отдельной транзакцией", а скорее большим набором транзакций на нескольких разных серверах. Ќапример, чтобы создать единую веб-страницу, сотни элементов, таких как изображени€, скрипты, элементы каскадной таблицы стилей (CSS) и файлы €зыка гипертекстовой разметки (HTML), должны быть переданы с сервера на клиент. Ёти файлы можно передавать двум€ способами: последовательно или параллельно. –исунок 1 иллюстрирует это.

Ќа рисунке 1 показаны три варианта передачи нескольких элементов от сервера к клиенту:

  • ¬ serialized варианте элементы передаютс€ по одному в течение одного сеанса. Ёто самый медленный из трех возможных вариантов, так как вс€ страница должна быть построена поэлементно, при этом меньшие элементы ждут передачи больших, прежде чем их можно будет отобразить.
  • ¬ варианте с несколькими потоками (multiple streams) каждый элемент передаетс€ через отдельное соединение (например, сеанс TCP). Ёто намного быстрее, но требует создани€ нескольких подключений, что может негативно повли€ть на ресурсы клиента и сервера.
  • ¬ мультиплексном (multiplexed) варианте каждый элемент передаетс€ отдельно через одно соединение. Ёто позвол€ет передавать каждый элемент с его собственной скоростью, но с дополнительными расходами ресурсов из-за опции нескольких потоков.
–ис. 1 ¬арианты передачи нескольких элементов

Ќекоторые формы механизма мультиплексной передачи имеют тенденцию обеспечивать максимальную скорость передачи при наиболее эффективном использовании ресурсов, но как это мультиплексирование должно быть реализовано? ѕротокол передачи гипертекста версии 2 (HTTPv2) позвол€ет веб-серверу мультиплексировать несколько элементов в одном сеансе HTTP; поскольку HTTP работает поверх TCP, это означает, что один поток TCP может использоватьс€ дл€ параллельной передачи нескольких элементов веб-страницы. ќднако один отброшенный пакет на уровне TCP означает, что кажда€ параллельна€ передача в потоке HTTP должна быть приостановлена на врем€ восстановлени€ TCP.

QUICK решает эту проблему, позвол€€ нескольким потокам HTTP v2 находитьс€ в одном быстром соединении. Ёто уменьшает транспортные издержки на клиенте и сервере, обеспечива€ при этом оптимальную доставку элементов веб - страницы.


ќбнаружение MTU пути

ќдним из основных вопросов спора между асинхронным режимом передачи (ATM) и интернет-протоколом (IP) был фиксированный размер €чейки. ¬ то врем€ как IP-сети полагаютс€ на пакеты переменной длины, ATM, чтобы обеспечить более высокую скорость коммутации и улучшить взаимодействие с множеством различных физических уровней Time Division Multiplexing (TDM), задал €чейки фиксированной длины. ¬ частности, IPv4 обеспечивает не только пакет переменной длины, но и фрагментацию в процессе передачи. –исунок 2 иллюстрирует это.

–ис. 2 ѕример фрагментации пакета

Ќа рис. 2 показано, что если A посылает пакет в направлении E, то какого размера он должен быть? ≈динственный канал, о котором действительно знает ј, - это канал между собой и ¬, которое помечено как имеющее максимальный размер блока передачи 1500 октетов (Maximum Transmission Unit- MTU). ќднако если A отправл€ет пакет длиной 1500 октетов, то этот пакет не сможет пройти через канал [C,D]. ≈сть два способа решить эту проблему.

ѕервый заключаетс€ в том, что C фрагментирует пакет на два меньших пакета. Ёто возможно в IPv4; C может определить, что пакет не поместитс€ на следующем канале, по которому пакет должен быть передан, и разбить пакет на два меньших пакета.  онечно, с этим решением есть р€д проблем. Ќапример, процесс фрагментации пакета требует гораздо больше работы со стороны C, возможно, даже перемещение пакета из аппаратного пути коммутации в программный путь коммутации.

¬о-вторых, A никогда не отправл€ет пакет, превышающий минимальный MTU, по всему пути к E. ƒл€ этого A должен определить минимальный MTU на пути, и он должен иметь возможность фрагментировать информацию, отправл€емую из протоколов верхнего уровн€ на несколько пакетов перед передачей. IPv6 выбирает этот последний вариант, полага€сь на обнаружение Path MTU (PMTU), чтобы найти минимальный MTU на пути (при условии, что PMTU действительно работает), и позвол€€ процессу IPv6 в A фрагментировать информацию из протоколов верхнего уровн€ на несколько пакетов, которые затем повторно собираютс€ в исходный блок данных верхнего уровн€ в приемнике.

Ёто решение, однако, также €вл€етс€ проблемным. ¬ недавней работе с системой доменных имен (DNS) исследователи обнаружили, что около 37% всех DNS- resolvers отбрасывают фрагментированные пакеты IPv6. ѕочему это происходит? —амый простой способ пон€ть это-рассмотреть структуру фрагментированного пакета, а также природу DoS и DDoS атак.

ѕри передаче пакета, в пакет помещаетс€ заголовок, указывающий принимающую услугу (номер сокета или протокола какого-либо рода), а также информацию о передаваемой услуге. Ёта информаци€ важна дл€ фильтрации пакета на основе различных политик безопасности, особенно если политика безопасности гласит: "разрешать только пакеты инициации сеанса в сеть, если пакет не принадлежит существующему сеансу." ƒругими словами, типичный фильтр с отслеживанием состо€ни€, защищающий сервер, будет иметь некоторые основные правила, которым он следует:

  • ≈сли пакет инициирует новый сеанс, пересылайте его и создайте новую запись сеанса.
  • ≈сли пакет €вл€етс€ частью существующего сеанса, перенаправьте его и сбросьте таймер сеанса.
  • ≈сли пакет не €вл€етс€ частью существующего сеанса, отбросьте его.
  • ¬рем€ от времени очищайте старые сеансы.

¬озможно подделать пакет, похожий на насто€щий, но это очень сложно, т.к. используютс€ различные nonce и другие методы, чтобы преп€тствовать подобному поведению. Ќо фрагментаци€ пакета удал€ет заголовок из второй половины пакета, что фактически означает, что второй пакет во фрагментированной паре может быть присоединен только к определенному сеансу или потоку, отслежива€ часть пакета, котора€ имеет полный заголовок.

 ак маршрутизатор или middlebox могут выполнить это? ќн должен каким-то образом хранить копию каждого фрагмента пакета с заголовком где-нибудь в пам€ти, чтобы на пакет с заголовком можно было ссылатьс€ дл€ обработки любых будущих фрагментов.  ак долго он должен хранить эти фрагменты с заголовками? Ќа это нет ответа. ѕроще просто отбросить любые фрагменты, чем поддерживать состо€ние, необходимое дл€ их обработки.

 аков результат? ѕохоже, что даже фрагментаци€ на основе исходного кода не очень полезна на уровне IP.

Ёто должно напомнить об одном из основополагающих принципов пакета »нтернет-протоколов: end-to-end принципе. End-to-end принцип гласит, что сеть не должна измен€ть трафик, передаваемый между двум€ оконечными устройствами; или, скорее, сеть должна работать как черный €щик, соедин€ющий два устройства, никогда не измен€€ данные, полученные от конечного хоста.

ќзначает ли это, что вс€ фильтраци€ трафика должна быть запрещена в общедоступном »нтернете, всерьез нав€зыва€ end-to-end правило, оставл€€ всю безопасность конечным хостам?

Ёто представл€ет собой первоначальное обсуждени€ фильтрации пакетов в IPv6 с отслеживанием состо€ни€. ќднако это менее реалистичный вариант; более сильна€ защита - это не один идеальный файрволл, а скорее сери€ неидеальных файрволлов.

ƒруга€ альтернатива - прин€ть еще одну частичку реальности, о которой часто забывают в мире сетевой инженерии: утечка абстракций. —квозной принцип описывает идеально абстрактную систему, способную передавать трафик от одного хоста к другому, и совершенно абстрагированный набор хостов, между которыми переноситс€ трафик. Ќо утекают все нетривиальные абстракции; проблема MTU и фрагментации - это просто утечка состо€ни€ из сети в хост, а система на хосте пытаетс€ абстрагировать эту утечку в приложение, отправл€ющее трафик по сети. ¬ такой ситуации лучше всего просто признать утечку и официально отправить информацию в стек, чтобы приложение могло лучше прин€ть решение о том, как отправл€ть трафик.

ƒруга€ альтернатива-прин€ть еще одну частицу реальности, часто забываемую в мире сетевой инженерии: утечку абстракций. —квозной принцип описывает идеально абстрагированную систему, способную передавать трафик от одного хоста к другому, и идеально абстрагированный набор хостов, между которыми осуществл€етс€ трафик. Ќо все нетривиальные абстракции протекают; проблема MTU и фрагментации-это просто утечка состо€ни€ из сети в хост, и система на хосте пытаетс€ абстрагировать эту утечку в приложение, отправл€ющее трафик по сети. ¬ такой ситуации, возможно, лучше всего просто признать утечку и официально продвинуть информацию вверх по стеку, чтобы приложение могло прин€ть лучшее решение о том, как отправл€ть трафик.

Ќо это приводит к еще одному интересному вопросу дл€ размышлени€: €вл€етс€ ли описанна€ здесь фильтраци€ состо€ний предательством end-to-end принципа? ќтвет зависит от того, считаете ли вы протокол верхнего уровн€, отправл€ющий данные, конечной точкой, или систему, на которой работает приложение (следовательно, включа€ сам стек IP), конечной точкой. “ак или иначе, эта двусмысленность преследовала »нтернет с самых ранних дней, хот€ мир сетевой инженерии не всегда серьезно задумывалс€ о разнице между этими двум€ точками зрени€.


ICMP

’от€ транспортные протоколы, такие как TCP и QUIC, обычно привлекают наибольшее внимание среди протоколов среднего уровн€, существует р€д других протоколов, которые не менее важны дл€ работы сети на основе IP. —реди них - протокол ICMP, который, можно сказать, предоставл€ет метаданные о самой сети. ICMP - это простой протокол, который используетс€ дл€ запроса информации о конкретном состо€нии или дл€ отправки сетевыми устройствами информации о том, почему определенный пакет отбрасываетс€ в какой-либо точке сети. ¬ частности:

  • ICMP может использоватьс€ дл€ отправки эхо-запроса или эхо-ответа. Ёта функци€ используетс€ дл€ проверки св€зи с конкретным адресом назначени€, который можно использовать дл€ определени€ доступности адреса без использовани€ слишком большого количества ресурсов на приемнике.
  • ICMP можно использовать дл€ отправки уведомлени€ об отброшенном пакете из-за того, что он слишком велик дл€ передачи по каналу (слишком большой пакет).
  • ICMP может использоватьс€ дл€ отправки уведомлени€ о том, что пакет был отброшен, поскольку его врем€ жизни (TTL) достигло 0 (срок действи€ пакета истек при передаче).

ќтвет на слишком большой пакет можно использовать дл€ определени€ максимального размера передаваемого блока (MTU) в сети; отправитель может передать большой пакет и дождатьс€, чтобы увидеть, не отправит ли какое-либо устройство в сети уведомление о слишком большом пакете через ICMP. ≈сли такое уведомление приходит, отправитель может попробовать постепенно уменьшать пакеты, чтобы определить самый большой пакет, который может быть передан из конца в конец по сети.

ќтвет с истекшим транзитом может использоватьс€ дл€ отслеживани€ маршрута от источника до пункта назначени€ в сети (это называетс€ трассировкой маршрута). ќтправитель может передать пакет в конкретное место назначени€, использу€ любой протокол транспортного уровн€ (включа€ TCP, UDP или QUIC), но с TTL равным 1. —етевое устройство первого перехода должно уменьшить TTL и отправить обратно ICMP-сообщение с истекшим сроком действи€ в транзитном уведомлении отправителю. ќтправл€€ серию пакетов, каждый с TTL на один больше, чем предыдущий, каждое устройство на пути может быть вынуждено передать отправителю сообщение ICMP с истекшим сроком действи€ в транзитном уведомлении, открыва€ весь путь пакета.