stringtranslate.com

QUIC

QUIC ( / k w ɪ k / ) — сетевой протокол [1] транспортного уровня [2] общего назначения, первоначально разработанный Джимом Роскиндом из Google , [3] реализованный и развернутый в 2012 году, [4] публично объявленный в 2013 году как эксперименты расширены, [5] [6] [7] и описаны на встрече IETF . [8] QUIC используется более чем в половине всех подключений веб-браузера Chrome к серверам Google. [9] Microsoft Edge (который после версии серии 1.x является производным браузера Chromium с открытым исходным кодом), [10] [11] Firefox [12] и Safari поддерживают его. [13]

Хотя его название изначально было предложено как аббревиатура от «Быстрые UDP-подключения к Интернету», [3] [8] использование IETF слова QUIC не является аббревиатурой; это просто имя протокола. [1] QUIC повышает производительность веб-приложений , ориентированных на соединение , которые в настоящее время используют TCP . [2] [9] Он делает это путем установления ряда мультиплексированных соединений между двумя конечными точками с использованием протокола пользовательских дейтаграмм (UDP) и предназначен для устаревшего TCP на транспортном уровне для многих приложений, в результате чего протокол иногда получает прозвище «TCP». /2". [14]

QUIC работает рука об руку с мультиплексными соединениями HTTP/2 , позволяя нескольким потокам данных достигать всех конечных точек независимо и, следовательно, независимо от потерь пакетов, связанных с другими потоками. Напротив, HTTP/2, размещенный на протоколе управления передачей (TCP), может страдать от задержек блокировки заголовка всех мультиплексированных потоков, если какой-либо из TCP-пакетов задерживается или теряется.

Вторичные цели QUIC включают снижение задержек соединения и транспорта , а также оценку пропускной способности в каждом направлении во избежание перегрузок . Он также перемещает алгоритмы контроля перегрузки в пространство пользователя на обеих конечных точках, а не в пространство ядра , что, как утверждается, позволит этим алгоритмам совершенствоваться быстрее. Кроме того, протокол может быть расширен за счет прямой коррекции ошибок (FEC) для дальнейшего повышения производительности, когда ожидаются ошибки, и это рассматривается как следующий шаг в развитии протокола. Он был разработан, чтобы избежать закостенения протокола , чтобы он оставался развивающимся, в отличие от TCP, который претерпел значительную закостенелость.

В июне 2015 года интернет-проект спецификации QUIC был представлен в IETF для стандартизации. [15] [16] Рабочая группа QUIC была создана в 2016 году. [17] В октябре 2018 года рабочие группы IETF по HTTP и QUIC совместно решили назвать сопоставление HTTP через QUIC « HTTP/3 », прежде чем сделать его всемирным. стандарт. [18] В мае 2021 года IETF стандартизировала QUIC в RFC  9000, поддержанную RFC  8999, RFC  9001 и RFC  9002. [19] DNS-over-QUIC — еще одно приложение.

Фон

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

Для этого TCP разбивает данные на сетевые пакеты и добавляет небольшие объемы данных в каждый пакет. Эти дополнительные данные включают в себя порядковый номер, который используется для обнаружения пакетов, которые потеряны или прибыли не по порядку, а также контрольную сумму , которая позволяет обнаруживать ошибки в данных пакета. При возникновении любой из проблем TCP использует автоматический запрос повторения (ARQ), чтобы сообщить отправителю повторно отправить потерянный или поврежденный пакет. [20]

В большинстве реализаций TCP рассматривает любую ошибку в соединении как операцию блокировки, останавливая дальнейшую передачу данных до тех пор, пока ошибка не будет устранена или соединение не будет считаться неудачным. Если одно соединение используется для отправки нескольких потоков данных, как в случае с протоколом HTTP/2 , все эти потоки блокируются, хотя только с одним из них может возникнуть проблема. Например, если при загрузке изображения GIF, используемого для значка , произойдет одна ошибка , вся остальная часть страницы будет ждать, пока эта проблема не будет решена. [20] Это явление известно как блокировка начала линии .

Поскольку система TCP спроектирована так, чтобы выглядеть как «трубопровод данных» или поток, она намеренно мало что понимает в передаваемых данных. Если к этим данным предъявляются дополнительные требования, например шифрование с использованием TLS , это должно быть настроено системами, работающими поверх TCP, используя TCP для связи с аналогичным программным обеспечением на другом конце соединения. Для каждой из этих задач настройки требуется собственный процесс установления связи . Для этого часто требуется несколько циклов запросов и ответов, пока соединение не будет установлено. Из-за задержки , присущей связи на большие расстояния, это может привести к значительным накладным расходам на общую передачу. [20]

TCP пострадал от окостенения протокола [ 21] из-за того, что его изображение проводов было в открытом тексте и, следовательно, видимо и податливо для промежуточных блоков . [22] Одно измерение показало, что треть путей в Интернете сталкивается как минимум с одним посредником, который изменяет метаданные TCP, а 6,5% путей сталкиваются с вредным закостенением эффектов со стороны посредников. [23] Это повлияло на расширения TCP: конструкция Multipath TCP (MPTCP) была ограничена поведением промежуточного блока, [24] [25] и развертывание TCP Fast Open также было затруднено. [26] [21]

Характеристики

Рукопожатие QUIC по сравнению с TCP с TLS1.2

QUIC стремится быть почти эквивалентным TCP-соединению, но со значительно уменьшенной задержкой . Это достигается главным образом за счет двух изменений, основанных на понимании поведения HTTP- трафика. [20]

Первое изменение заключается в значительном сокращении накладных расходов при установке соединения. Поскольку для большинства HTTP-соединений требуется TLS , QUIC делает обмен ключами настройки и поддерживаемыми протоколами частью первоначального процесса установления связи . Когда клиент открывает соединение, ответный пакет включает в себя данные, необходимые для использования шифрования в будущих пакетах. Это устраняет необходимость устанавливать TCP-соединение, а затем согласовывать протокол безопасности через дополнительные пакеты. Другие протоколы могут обслуживаться таким же образом, объединяя несколько шагов в одну пару запрос-ответ. Эти данные затем можно использовать как для последующих запросов при первоначальной настройке, так и для будущих запросов, которые в противном случае согласовывались бы как отдельные соединения. [20]

Второе изменение заключается в использовании в качестве основы UDP , а не TCP, что не включает восстановление потерь . Вместо этого каждый поток QUIC управляется отдельно, а потерянные данные повторно передаются на уровне QUIC, а не UDP. Это означает, что если в одном потоке возникает ошибка, как в примере с значком выше, стек протоколов может продолжать обслуживать другие потоки независимо. Это может быть очень полезно для повышения производительности на каналах, подверженных ошибкам, поскольку в большинстве случаев значительные дополнительные данные могут быть получены до того, как TCP заметит, что пакет отсутствует или поврежден, и все эти данные блокируются или даже сбрасываются, пока ошибка исправляется. В QUIC эти данные можно обрабатывать бесплатно, пока восстанавливается один мультиплексированный поток. [27]

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

Еще одной целью системы QUIC было повышение производительности во время событий переключения сети, например, что происходит, когда пользователь мобильного устройства перемещается из локальной точки доступа Wi-Fi в мобильную сеть . Когда это происходит в TCP, начинается длительный процесс, в ходе которого каждое существующее соединение истекает одно за другим, а затем восстанавливается по требованию. Чтобы решить эту проблему, QUIC включает идентификатор соединения, позволяющий однозначно идентифицировать соединение с сервером независимо от источника. Это позволяет восстановить соединение, просто отправив пакет, который всегда содержит этот идентификатор, поскольку исходный идентификатор соединения по-прежнему будет действительным, даже если IP-адрес пользователя изменится. [28]

HTTP/1Transport Layer SecurityTransmission Control ProtocolHTTP/2TLS 1.2Transmission Control ProtocolHTTP/3TLS 1.3QUICUser Datagram ProtocolInternet Protocol
Стек протоколов HTTP/3 по сравнению с HTTP/1.1 и HTTP/2

QUIC может быть реализован в пространстве приложения, а не в ядре операционной системы . Обычно это приводит к дополнительным накладным расходам из-за переключения контекста при перемещении данных между приложениями. Однако в случае QUIC стек протоколов предназначен для использования одним приложением, причем каждое приложение, использующее QUIC, имеет свои собственные соединения, размещенные на UDP. В конечном итоге разница может быть очень небольшой, поскольку большая часть общего стека HTTP/2 уже находится в приложениях (или, чаще, в их библиотеках). Размещение остальных частей в этих библиотеках, по сути, исправление ошибок, мало влияет на размер стека HTTP/2 или общую сложность. [8]

Такая организация упрощает внесение будущих изменений, поскольку для обновлений не требуется вносить изменения в ядро . Одной из долгосрочных целей QUIC является добавление новых систем прямого исправления ошибок (FEC) и улучшенного контроля перегрузок. [28]

Одна из проблем, связанных с переходом от TCP к UDP, заключается в том, что TCP широко распространен, и многие «промежуточные устройства» в инфраструктуре Интернета настроены на TCP и ограничивают скорость или даже блокируют UDP. Google провел ряд исследовательских экспериментов, чтобы охарактеризовать это явление, и обнаружил, что таким образом блокируется лишь небольшое количество соединений. [3] Это привело к использованию системы быстрого перехода на TCP; Сетевой стек Chromium одновременно открывает как QUIC, так и традиционное TCP-соединение, что позволяет ему вернуться с незначительной задержкой. [29]

QUIC был специально разработан с возможностью развертывания, развития и обеспечения свойств, препятствующих оссификации; [30] это первый транспортный протокол IETF , который намеренно минимизировал образ проводной связи для этих целей. [31] Помимо зашифрованных заголовков, он «смазан» [32] и имеет явно указанные инварианты протокола. [33]

Google QUIC (gQUIC)

Протокол, созданный Google и переданный в IETF под названием QUIC (уже в 2012 году, в версии QUIC 20), сильно отличается от QUIC, который продолжает развиваться и совершенствоваться в рамках IETF. Оригинальный Google QUIC был разработан как протокол общего назначения, хотя изначально он был развернут как протокол для поддержки HTTP(S) в Chromium. Текущая эволюция протокола IETF QUIC представляет собой транспортный протокол общего назначения. Разработчики Chromium продолжали отслеживать эволюцию усилий IETF QUIC по стандартизации, направленных на принятие и полное соответствие самым последним интернет-стандартам QUIC в Chromium.

Приложения

QUIC был разработан с учетом HTTP, и HTTP/3 был его первым применением. [34] [35] DNS-over-QUIC — это применение QUIC для разрешения имен, обеспечивающее безопасность данных, передаваемых между преобразователями, аналогично DNS-over-TLS . [36] IETF также разрабатывает приложение QUIC для создания протокола безопасного туннелирования . [35] XMPP был экспериментально адаптирован для использования QUIC. [37] Еще одно приложение — SMB over QUIC, которое, по словам Microsoft, может предложить «SMB VPN», не влияя на удобство работы пользователя. [38] Клиенты SMB по умолчанию используют TCP и будут пытаться использовать QUIC, если попытка TCP не удалась или если QUIC намеренно требуется.

Принятие

Поддержка браузера

Код QUIC экспериментально разрабатывался в Google Chrome , начиная с 2012 года [4] и был анонсирован как часть Chromium версии 29 (выпущенной 20 августа 2013 года). [18] В настоящее время он включен по умолчанию в Chromium и Chrome. [39]

Поддержка в Firefox появилась в мае 2021 года. [40] [12]

Apple добавила экспериментальную поддержку в движок WebKit через Safari Technology Preview 104 в апреле 2020 года. [41] Официальная поддержка была добавлена ​​в Safari 14, включена в macOS Big Sur и iOS 14 , [42] но эту функцию нужно было включить вручную. . [43] Позже эта функция была включена по умолчанию в Safari 16. [13]

Поддержка клиентов

Библиотека cronet для QUIC и других протоколов доступна для приложений Android в виде модуля, загружаемого через Сервисы Google Play . [44]

cURL 7.66, выпущенный 11 сентября 2019 г., поддерживает HTTP/3 (и, следовательно, QUIC). [45] [46]

В октябре 2020 года Facebook объявил [47] , что успешно перенес свои приложения, включая Instagram , и серверную инфраструктуру на QUIC, при этом уже 75% интернет-трафика использует QUIC. Все мобильные приложения Google поддерживают QUIC, включая YouTube и Gmail . [48] ​​[49] Мобильное приложение Uber также использует QUIC . [49]

Поддержка сервера

По состоянию на 2017 год существует несколько активно поддерживаемых реализаций. Серверы Google поддерживают QUIC, и Google опубликовал прототип сервера. [50] Akamai Technologies поддерживает QUIC с июля 2016 года. [51] [52] Также доступна реализация Go под названием quic-go [53], которая обеспечивает экспериментальную поддержку QUIC на сервере Caddy . [54] 11 июля 2017 года компания LiteSpeed ​​Technologies официально начала поддерживать QUIC в своих продуктах балансировщика нагрузки (WebADC) [55] и LiteSpeed ​​Web Server . [56] По состоянию на октябрь 2019 года 88,6% веб-сайтов QUIC использовали LiteSpeed ​​и 10,8% использовали Nginx . [57] Хотя сначала только серверы Google поддерживали соединения HTTP-over-QUIC, Facebook также запустил эту технологию в 2018 году, [18] а Cloudflare предлагает поддержку QUIC на бета-версии с 2018 года. [ 58] Добавлен балансировщик нагрузки HAProxy . экспериментальная поддержка QUIC в марте 2022 года [59] и объявлена ​​о его готовности к производству в марте 2023 года. [60] По состоянию на апрель 2023 года 8,9% всех веб-сайтов используют QUIC, [61] по сравнению с 5% в марте 2021 года. Microsoft Windows Server 2022 поддерживает протоколы HTTP/3 [62] и SMB over QUIC [63] [10] через MsQuic . Контроллер доставки приложений Citrix (Citrix ADC, NetScaler) может функционировать как прокси-сервер QUIC, начиная с версии 13. [64] [65]

Кроме того, существует несколько устаревших проектов сообщества: libquic [66] был создан путем извлечения реализации QUIC в Chromium и ее модификации для минимизации требований к зависимостям, а goquic [67] предоставляет привязки libquic к Go . Наконец, quic-reverse-proxy [68] — это образ Docker , который действует как обратный прокси- сервер, преобразуя запросы QUIC в простой HTTP, понятный исходному серверу.

В .NET 5 представлена ​​экспериментальная поддержка QUIC с использованием библиотеки MsQuic . [69]

Исходный код

Смотрите также

Рекомендации

  1. ^ ab RFC 9000 - QUIC: мультиплексированная и безопасная транспортировка на основе UDP. IETF . дои : 10.17487/RFC9000 . РФК 9000 . Проверено 08 февраля 2022 г.
  2. ^ аб Натан Уиллис. «Подключение по QUIC». Еженедельные новости Linux . Проверено 16 июля 2013 г.
  3. ^ abc «QUIC: Проектная документация и обоснование спецификаций». Джим Роскинд, участник Chromium.
  4. ^ ab «Первая посадка кода Chromium: CL 11125002: добавьте QuicFramer и друзей» . Проверено 16 октября 2012 г.
  5. ^ «Эксперименты с QUIC» . Официальный блог Chromium . Проверено 16 июля 2013 г.
  6. ^ «QUIC, Google хочет сделать Интернет быстрее» . Франсуа Бофор, евангелист хрома.
  7. ^ «QUIC: мультиплексированная транспортировка следующего поколения через UDP» . YouTube . Проверено 4 апреля 2014 г.
  8. ^ abcd «QUIC: Презентация области TSV IETF-88» (PDF) . Джим Роскинд, Google . Проверено 7 ноября 2013 г.
  9. ^ Аб Лардинуа, Фредерик (18 апреля 2015 г.). «Google хочет ускорить работу Интернета с помощью протокола QUIC». ТехКранч . Проверено 25 октября 2016 г.
  10. ^ аб Маки, Курт; 26 августа 2021 г. «Microsoft использует встроенный QUIC в новых ОС Windows и браузере Edge». Журнал Редмонд . Проверено 8 мая 2022 г.{{cite web}}: CS1 maint: numeric names: authors list (link)
  11. ↑ Кристофер Фернандес (3 апреля 2018 г.). «Microsoft добавит поддержку протокола быстрого Интернета QUIC от Google в Windows 10 Redstone 5» . Проверено 8 мая 2020 г.
  12. ^ аб Драгана Дамьянович (16 апреля 2021 г.). «Поддержка QUIC и HTTP/3 теперь в Firefox Nightly и бета-версии». Мозилла . Проверено 11 октября 2021 г.
  13. ^ Аб Белсон, Дэвид; Пардью, Лукас (6 июня 2023 г.). «Изучение использования HTTP/3 год спустя». Облачная вспышка . Проверено 22 октября 2023 г.
  14. ^ Тацухиро Цудзикава. «нгткп2». Гитхаб . Проверено 17 октября 2020 г.
  15. ^ «Google предложит QUIC в качестве стандарта IETF» . ИнфоQ . Проверено 25 октября 2016 г.
  16. ^ «Действие по идентификатору: черновик-tsvwg-quic-protocol-00.txt» . id-announce (список рассылки). 17 июня 2015 г.
  17. ^ «QUIC — Рабочая группа IETF» . datatracker.ietf.org . Проверено 25 октября 2016 г.
  18. ↑ abc Cimpanu, Каталин (12 ноября 2018 г.). «HTTP-over-QUIC будет переименован в HTTP/3». ЗДНет .
  19. ^ «QUIC теперь RFC 9000» . www.fastly.com . 27 мая 2021 г. Проверено 28 мая 2021 г.
  20. ^ abcdef Брайт, Питер (12 ноября 2018 г.). «Следующая версия HTTP не будет использовать TCP». Арстехника .
  21. ^ ab Thomson & Pauly 2021, A.5. ПТС.
  22. ^ Fairhurst & Perkins 2021, 4. Шифрование и аутентификация транспортных заголовков.
  23. ^ Эделин и Доннет 2019, с. 175–176.
  24. ^ Райчиу и др. 2012, с. 1.
  25. ^ Хесманс и др. 2013, с. 1.
  26. ^ Рыбчинская 2020.
  27. ^ Бер, Майкл; Светт, Ян. «Представляем поддержку QUIC для балансировки нагрузки HTTPS». Блог об облачной платформе Google . Проверено 16 июня 2018 г.
  28. ^ аб Саймон, Клейтон (май 2021 г.). «QUIC: мультиплексированная и безопасная транспортировка на основе UDP». IETF.org .
  29. ^ «Применимость транспортного протокола QUIC». Рабочая группа сети IETF . 22 октября 2018 г.
  30. ^ Корбет 2018.
  31. ^ Траммелл и Кюлевинд 2019, стр. 2.
  32. ^ Томсон и Поли 2021, 3.3. Фальсификация активного использования.
  33. ^ Thomson 2021, 2. Исправлены свойства всех версий QUIC.
  34. ↑ Бишоп, Майк (21 июня 2021 г.). «HTTP/3 и QUIC: прошлое, настоящее и будущее». Акамай .
  35. ^ аб Дюк, Мартин; Саркер, Захедузаман; Вестерлунд, Магнус (3 июня 2021 г.). «Новая эра в интернет-транспорте». IETF .
  36. ^ Хуитема, Кристиан ; Дикинсон, Сара; Мэнкин, Эллисон (май 2022 г.). DNS через выделенные соединения QUIC. дои : 10.17487/RFC9250 . РФК 9250.
  37. ↑ Буртрум, Трэвис (13 июля 2022 г.). «XEP-0467: XMPP через QUIC».
  38. ^ Пайл, Нед (27 июня 2023 г.). «SMB через QUIC». Learn.microsoft.com . Проверено 29 июня 2023 г.
  39. ^ Либетрау, Этьен (22 июня 2018 г.). «Как протокол Google QUIC влияет на сетевую безопасность и отчетность». Fastvue — Простая отчетность об использовании Интернета . Проверено 2 апреля 2022 г.
  40. Рианна Чимпану, Каталин (26 сентября 2019 г.). «Cloudflare, Google Chrome и Firefox добавляют поддержку HTTP/3». ЗДНет . Проверено 27 сентября 2019 г.
  41. ^ «Примечания к выпуску предварительной версии Safari Technology 104» . вебкит.орг . 8 апреля 2020 г. Проверено 7 августа 2020 г.
  42. ^ «Примечания к выпуску Safari 14» . разработчик.apple.com . Проверено 4 декабря 2020 г.
  43. ^ «Как включить HTTP3 в Chrome/Firefox/Safari». bram.us. _ 8 апреля 2020 г.
  44. ^ «Выполнение сетевых операций с помощью Cronet» . Android-разработчики . Проверено 20 июля 2019 г.
  45. ^ «завиток – Изменения» . Curl.haxx.se. _ Проверено 30 сентября 2019 г.
  46. ^ «curl 7.66.0 – будущее параллельного HTTP/3 уже здесь | daniel.haxx.se» . 11 сентября 2019 года . Проверено 30 сентября 2019 г.
  47. ^ «Как Facebook приносит QUIC миллиардам» . Фейсбук Инжиниринг . 21 октября 2020 г. Проверено 23 октября 2020 г.
  48. ^ «Как протокол Google QUIC влияет на сетевую безопасность и отчетность» . Фаствью . 21 октября 2020 г. Проверено 26 июня 2021 г.
  49. ↑ Аб Грин, Эмили (30 сентября 2020 г.). «Это то, что вам нужно знать о новом протоколе QUIC». НордВПН . Проверено 26 июня 2021 г.
  50. ^ "QUIC-сервер". 2012 . Проверено 17 августа 2022 г.
  51. ^ Поддержка QUIC со стороны Akamai, дата обращения 20 мая 2020 г.
  52. ^ Рют, Ян; Поезе, Ингмар; Дитцель, Кристоф; Холфельд, Оливер (2018). «Первый взгляд на QUIC в дикой природе». Пассивное и активное измерение . Конспекты лекций по информатике. Том. 10771. стр. 255–268. arXiv : 1801.05168 . дои : 10.1007/978-3-319-76481-8_19. ISBN 978-3-319-76480-1. S2CID  3631501.
  53. ^ "Лукас-Клементе/быстро" . 7 августа 2020 г. Получено 7 августа 2020 г. - через GitHub.
  54. ^ Поддержка QUIC в Caddy, дата обращения 13 июля 2016 г.
  55. ^ «LiteSpeed ​​Web ADC – Балансировщик нагрузки – LiteSpeed ​​Technologies» . www.litespeedtech.com . Проверено 7 августа 2020 г.
  56. ^ Сообщение в блоге LiteSpeed ​​Technologies QUIC, получено 11 июля 2017 г.
  57. ^ «Распределение веб-серверов между веб-сайтами, использующими QUIC». w3techs.com . Проверено 7 августа 2020 г.
  58. ^ «Начните с QUIC» . 25 сентября 2018 г. Проверено 16 июля 2019 г.
  59. ^ «Анонс HAProxy 2.6» . HAProxy Technologies . Проверено 16 сентября 2023 г.
  60. ^ "[ОБЪЯВЛЕНИЕ] haproxy-2.8.0" . www.mail-archive.com . Проверено 16 сентября 2023 г.
  61. ^ «Статистика использования QUIC для веб-сайтов, апрель 2023 г.» . w3techs.com . Проверено 03 апреля 2023 г.
  62. ^ «Включение поддержки HTTP/3 в Windows Server 2022» . 24 августа 2021 г.
  63. ^ «SMB через QUIC» . 27 июня 2023 г.
  64. ^ «Конфигурация политики для трафика HTTP/3 | Citrix ADC 13.0» .
  65. ^ «Жажда скорости? - Еще один блог Citrix ADC» .
  66. ^ "Сестры разработчиков/libquic". 5 августа 2020 г. Получено 7 августа 2020 г. - через GitHub.
  67. ^ "Сестры разработчиков/гокик". 5 августа 2020 г. Получено 7 августа 2020 г. - через GitHub.
  68. ^ "Докер-Хаб". Hub.docker.com . Проверено 7 августа 2020 г.
  69. ^ «Улучшения сети .NET 5» . .NET-блог . 11 января 2021 г. Проверено 26 января 2021 г.

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

Внешние ссылки