Интернет стал одной из самых грандиозных историй успеха нашей эпохи. Начавшись в 1969 году с четырех узлов, использовавшихся исключительно в исследовательских целях для ограниченного числа применений, связанных с передачей текстовой информации [1], Сеть разрослась до глобальной инфраструктуры, предоставляющей сложные сервисы, которые играют критически важную роль в повседневной жизни миллиардов людей. Оглядываясь на полвека эволюции Интернета, нельзя не поразиться росту Сети и тому, как воплотилась в жизнь амбициозная цель — предоставить доступ к любой информации любым пользователям в любом месте и в любое время. Однако напрашивается вопрос: не выполнена ли до конца задача по проектированию Интернета и не пришло ли время ученым, занимающимся компьютерными сетями, «паковать чемоданы» и искать новую работу? Ответ отрицательный, и в немалой степени потому, что Интернет страдает из-за глубоко укоренившихся проблем, решение которых потребует внушительного объема дальнейшей работы. Более того, как отмечают участники реализуемого Национальным научным фондом США проекта Future Internet Design [2], те же самые структурные элементы Сети, которые обусловили ее успех, являются и первопричиной ее глобальных проблем, а их решение потребует изменения архитектуры Интернета, причем с сохранением совместимости с унаследованными технологиями.

Три проблемы Интернета

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

Спам

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

Приватность и безопасность

Тема приватности и безопасности (а вернее, их отсутствия) в Интернете — весьма обширная, поэтому сосредоточимся лишь на одном ее аспекте, а именно на том, что пакеты, попавшие к провайдеру, могут безнаказанно сохраняться, анализироваться, изменяться, повторно воспроизводиться и теряться. Очевидно, что это негативно влияет на соблюдение конфиденциальности переписки пользователей Интернета.

Если говорить о приватности, то среднестатистический пользователь Сети раскрывает каждому провайдеру как содержимое пакета, так и адрес его назначения на пути к конечной точке. Разумеется, для защиты содержимого можно использовать протоколы TLS и HTTPS, а также виртуальные частные сети и распределенные промежуточные системы вроде Tor для маскировки места назначения. Но все эти дополнительные меры не применяются по умолчанию, в связи с чем происходит нарушение безопасности, открывающее путь доставке персонализированных рекламных объявлений. Но, даже применяя упомянутые защитные средства, приватности можно добиться только ценой существенного ухудшения производительности.

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

Почему Интернет настолько плохо обеспечивает безопасность и приватность?

Качество обслуживания

Господствующая сегодня сфера применения Интернета — доставка неинтерактивного видео от сервисов наподобие NetFlix или YouTube. Здесь не нужно обслуживания на уровне систем реального времени, а достаточно выполнения минимальных требований к пропускной способности, однако Интернет не отвечает даже таким, довольно мягким запросам подобных приложений. О гарантированном выполнении строгих требований к пропускной способности и задержке для двунаправленных интерактивных сервисов голосовой и видеосвязи наподобие Skype и WebEx речи вообще не идет. С учетом того, что телефонная сеть — это сеть связи специального назначения, способная обеспечивать устойчивое качество передачи голоса с использованием технологий еще эпохи 1960-х годов, вызывает недоумение то, что качество той же услуги в современном Интернете нередко хуже, чем в телефонной сети полвека тому назад.

Почему Интернет не способен обеспечить гарантированное качество обслуживания?

Принципы проектирования архитектуры Интернета

Все три перечисленные проблемы обусловлены изначальными принципами проектирования Интернета. Иными словами, если бы Сеть изначально спроектировали по-другому, эти проблемы бы не возникли (хотя появились бы другие). Рассмотрим принципы проектирования Интернета, воспользовавшись их изложением в докладе Дэвида Кларка, опубликованном в 1988 году. В нем говорится, что «главной задачей создания архитектуры Интернета DARPA была разработка эффективного метода использования существующих взаимосоединенных сетей в режиме уплотнения» [3]. Основная задача была подразделена на семь составляющих целей: (1) связь должна сохраняться даже в условиях утраты отдельных сетей и шлюзов; (2) Интернет должен поддерживать различные типы коммуникационных услуг; (3) архитектура должна быть рассчитана на использование сетей различных типов; (4) архитектура должна разрешать распределенное управление ресурсами Сети; (5) архитектура должна быть экономически эффективной; (6) архитектура должна обеспечивать возможность подключения хоста с малыми трудозатратами; (7) для используемых ресурсов должна быть возможность учета. Важно понимать, что эти подзадачи перечислены в порядке значимости, а если бы их порядок был иным, то это привело бы к созданию совершенно другой сетевой архитектуры.

Парадоксы архитектуры Интернета

Компромисс между затратами и производительностью

Одним из главных факторов успеха Интернета была гораздо меньшая стоимость для пользователя, чем у телефонии, поскольку пакетная связь в Сети обеспечивает возможность статистического уплотнения каналов, что снижает стоимость передачи сообщения (согласно цели № 5). Однако снижение затрат, обусловленное статистическим уплотнением, имеет свою цену: при коммутации каналов после того, как вызов принят, пропускная способность гарантирована и задержка передачи по всему маршруту жестко ограничивается. При коммутации же пакетов, особенно в пакетных сетях без контроля установления соединения, к которым и относится Интернет, гарантированной пропускной способности нет, а единственное (слабое) ограничение задержки сквозной передачи обусловлено размером буфера маршрутизаторов. В связи с этим практически отсутствует возможность ограничения задержки, когда сетевые каналы перегружены (то есть темпы поступления пакетов превышают возможности канала). На сегодня проведены тысячи исследований, в которых предпринимались попытки обеспечить гарантии качества обслуживания в сетях с коммутацией пакетов. Все эти проекты можно разделить на четыре категории.

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

2. Контроль допуска. Перегруженные каналы отвергают дальнейшие «вызовы» (соединения TCP или пакеты UDP), однако реализовать контроль за загрузкой в нынешней Сети невозможно, поскольку TCP-соединение не указывает расчетный объем трафика, который через него может проходить. Протокол IntServ RSVP это предусматривал, но его широкомасштабное внедрение потребовало бы тесного взаимодействия провайдеров и наличия механизма взаиморасчетов. Однако это противоречит цели № 4, ради достижения которой Интернет был разделен на набор минимально сотрудничающих автономных систем.

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

4. Избирательное качество обслуживания. В отличие от IntServ, суть метода состоит в том, чтобы повышать производительность некоторых передач за счет снижения скорости других. Реализовать это несложно, но при этом возникает та же проблема, что и с RSVP, — у автономных систем нет причины выполнять запросы других автономных систем (autonomous system, AS) на приоритетное обслуживание, если такие запросы не сопровождаются платежом. Ввиду отсутствия надежной системы учета (цель № 7 была признана нереализуемой даже в докладе Кларка), идея провалилась.

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

Автономные системы с узкими интерфейсами

Для достижения четвертой цели (распределенное управление ресурсами) Интернет физически разделен на автономные системы, имеющие различные принципы работы. Более того, с точки зрения третьей цели (поддержка сетей различных типов) от AS требуется лишь минимум — доставить пакеты по мере возможности. Таким образом, интерфейс между двумя автономными системами должен выполнять только функции адресации и передачи пакетов (определенных в протоколах IPv4 и IPv6), а также передачи информации о маршрутизации (определена протоколом Border Gateway Protocol, BGP). В остальном автономные системы не имеют возможности делать какие-либо предположения друг о друге. В результате этих двух проектных решений Интернет состоит из слабо связанных, по-разному управляемых автономных систем, что и стало ключевым фактором быстрого роста Интернета. Сети присуща высокая масштабируемость благодаря распределенному принятию управленческих решений и отсутствию строгих требований по координации работы автономных систем (кроме слабого контроля, осуществляемого организациями типа ICANN и IANA). Эти решения также позволили с самого начала присоединить к Интернету уже существовавшие сети — например, подконтрольные Европе почту, телеграф и электросвязь. Кроме того, это дало возможность постепенного включения в Интернет целого ряда разнородных низкоуровневых сетевых технологий. Что менее очевидно, принцип выполнения минимума требований также позволяет автономным системам независимо развиваться. И даже если одна AS основана на спутниковых каналах с большой задержкой, а другая — на высокоскоростной волоконно-оптической сети со спектральным уплотнением, они все равно смогут взаимодействовать. Даже ранняя реализация IPv4 эпохи середины 1970 -х годов, скорее всего, смогла бы работать в современном Интернете.

Однако архитектура, для которой характерны принципы децентрализованности и выполнения требований по мере возможности, имеет определенные недостатки. Она не позволяет предоставлять гарантии качества обслуживания на всем маршруте. Более острая проблема состоит в том, что такая архитектура допускает произвольный уровень сложности автономной системы при условии сохранения функции доставки пакетов. Таким образом, в AS могут применяться сложные наслоения (например, IP поверх VPN поверх MPLS поверх ATM поверх протоколов физического уровня). Это сильно затрудняет отладку системы в целом. Сеть изначально создавалась неуправляемой в том смысле, что никакой отдельный объект «не знает» общей топологии и ее физической реализации. Кроме того, у автономных систем нет ограничений на захват, модификацию и повторное воспроизведение пакетов при условии, что они обеспечивают их транспортировку.

Именно поэтому спам останется одной из наиболее разрушительных проблем Интернета. Интерфейс между автономными системами передает только пакеты и сведения о маршрутизации, так что если вы и пожалуетесь провайдеру на спам, у того нет способа потребовать от какой-то другой AS отследить спамера. Еще хуже ситуация с DDoS-атаками: даже если известны IP-адреса всех ботов, ввиду децентрализованной природы Интернета практически невозможно выяснить личность того, кто ими управляет, — ботмастера, который может находиться в нескольких транзитных участках от объекта атаки и, возможно, в недружественной политической юрисдикции.

Подключение и идентификация

Достижение цели № 6 (обеспечение возможности подключения хостов к сети с малыми трудозатратами) позволит ускорить процесс развертывания инфраструктуры. Уместно сравнить трудозатраты на подключение хоста к Интернету с усилиями, потраченными на подключение мобильного телефона к телефонной сети. В первом случае все, что нужно хосту, — это IP-адрес, маска сети и IP-адрес маршрутизатора, готового принять соединение с хостом. Все эти сведения могут быть предоставлены автоматически с помощью технологий нулевой настройки, например протокола DHCP. В случае мобильного телефона требуется обязательное получение защищенного от вмешательства идентификатора (номера IMEI), а также в большинстве случаев — предоставление надежного подтверждения личности абонента.

Очевидно, что именно простота подключения к Сети во многом обеспечивает ее успех. С другой стороны, стремление снизить трудозатраты на подключение привело к тому, что конечные точки Интернета не имеют привязки к каким-либо идентификационным сведениям. В результате вредоносные действия, исходящие из конечных точек, нельзя связать с объектами, подлежащими юридическим ограничениям. Это еще одна причина изобилия спама и DDoS-атак в Интернете в отличие от сетей мобильной связи, в которых есть возможность принять меры против личности, замеченной в отправке спама. В Интернете это невозможно выполнить, особенно учитывая масштабы подключения конечных точек без ведома их владельцев к бот-сетям. Отсутствие надежного механизма идентификации также делает практически невозможным предоставление гарантий качества обслуживания на всем маршруте, поскольку конечному пользователю невозможно выставить счет за более высокий уровень сервиса.

На пути к новой архитектуре Интернета

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

Уже больше десятка лет идет работа над вариантами будущей архитектуры Интернета [2], в том числе инициативами, фактически предлагающими переделать все с нуля. Все такие проекты занимаются основами: системой имен, адресацией, маршрутизацией, а также до некоторой степени приватностью и безопасностью. Затрагиваются и проблемы отсутствия поддержки гарантированного качества обслуживания Quality of Service (QoS) и господства коммуникационного спама. Ранние примеры разработок в этой области — I3 и Plutarch.

Возможно, самый амбициозный проект по изменению архитектуры Сети ведется исследовательской группой SCION (Scalability, Control, and Isolation on Next-Generation Networks) из Швейцарской высшей технической школы Цюриха. В рамках инициативы предлагается новая архитектура, целиком построенная на принципах безопасности и обеспечения доверия, которая позволяет отслеживать маршруты пакетов, но без компрометации безопасности конечного пользователя. Она также совместима с унаследованными технологиями, а расширение SIBRA (Scalable Internet Bandwidth Reservation Architecture) позволяет хостам выполнять резервирование пропускной способности на всем маршруте передачи, что обеспечивает гарантии качества обслуживания и защиту от DDoS-атак.

Дэвид Кларк, помимо упомянутого здесь доклада 1988 года об основах проектирования архитектуры Сети, опубликовал книгу на ту же тему [4], которая непременно вдохновит сетевых архитекторов на решение сложных проблем, обусловленных статистическим уплотнением, узкими интерфейсами между автономными системами и отсутствием идентификаторов конечной точки.

Сейчас основные исследовательские усилия направлены на создание интерфейса между автономными системами в точке доступа к сети (Network Access Point, NAP), позволяющего метаданным QoS, информации о взаиморасчетах и идентификаторам пересекать границу между автономными системами. Например, два географически близких провайдера, у которых уже есть связи между конечными точками и идентификационными сведениями, могли бы наладить взаимный обмен идентификационными сведениями и информацией о QoS для улучшения эксплуатационной безопасности и качества обслуживания, предоставляемого абонентам. Эту взаимно полезную основу можно было бы расширять, подключая к ней со временем другие AS и NAP. Разумеется, это лишь высокоуровневая зарисовка, но в целом данное направление весьма перспективно.

***

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

Литература

  1. B.M. Leiner et al. A brief history of the Internet // ACM SIGCOMM Computer Communication Review.— 2009. Vol. 39, N. 5. — P. 22–31.
  2. NETs FIND Project. National Science Foundation. — 2009. URL: http://www.netsfind.net/index.php (дата обращения: 23.04.2018).
  3. D.D. Clark. The Design Philosophy of the DARPA Internet Protocols // ACM SIGCOMM Computer Communication Review. — 1988. Vol. 18, N. 4. — P. 106–114.
  4. D.D. Clark. Designs for an Internet.— 2017. URL: https://groups.csail.mit.edu/ana/People/DDC/ebook-arch.pdf (дата обращения: 23.04.2018).

Сринивасан Кешав (keshav@uwaterloo.ca) — профессор, Университет Ватерлоо.

Srinivasan Keshav, Paradoxes of Internet Architecture. IEEE Internet Computing, January/February 2018, All rights reserved. Reprinted with permission.