Архитектура сети

Первый наш модуль, который будет посвящен провайдерским сетям, будет рассказывать про то, как устроены провайдерские сети, про какие-то общие концепции, которые есть в провайдерских сетях, и, в частности, про то, в какой логике эти самые сети строятся, почему они строятся таким образом и что в итоге получается. То есть такой достаточно разговорный модуль. Давайте посмотрим, что здесь можно будет встретить. Скорее всего, вы, приходя на этот курс, уже имеете какой-то опыт работы с сетями. Скорее всего, этот опыт работы с сетями подтверждается работой в сети предприятия. То есть вы, допустим, сдали экзамены с сетей роутинга свечинг, и вы примерно представляете, как Cisco предлагает строить сети предприятий или Enterprise Network. Так вот, провайдерские сети даже с точки зрения Cisco заметно отличаются от сетей предприятия. Задачи, которые решает провайдер и задачи, которые решают администраторы сети предприятий,

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

пропусканием трафика через себя. Поэтому, как правило, в провайдерской сети нет особенно большого запаса не хватало soils, чтобы в продажных решений не хотят в каких-то хотите. Мы всегда понимаем, сколько трафика мы должны будем обслуживать, и мы всегда понимаем, какое железо нам нужно под решение конкретной этой задачи. У провайдеров будет сравнительно нормой, когда трафика будет сильно больше, чем математическая сумма скоростей портов, через которые этот трафик будет ходить. То есть у провайдеров будет являться нормой подписка. Когда мы как клиент приходим к провайдеру и говорим, дорогой провайдер, продай нам канал, не знаю, 50 мегабит в секунду, провайдер говорит, я, конечно, тебе продам 50 мегабит в секунду. Только это не означает, что в любой момент времени мы можем использовать все 50 мегабит.

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

У провайдеров может быть полностью загруженная полоса. То есть, опять же, да, переподписка возникает благодаря тому, что мы фактически одну и ту же полосу можем продавать несколько раз. Но мы при этом понимаем, что мы не должны будем особенно наглеть, и мы не должны будем продавать то, чего у нас по факту нет. То есть, если у нас есть 50 пользователей, которым мы продаем по 50 мегабит каждому, то всего получается 2,5 гигабита трафика. И да, мы понимаем, что все 50 пользователей одновременно не будут загружать канал на 50 мегабит, поэтому никогда 2,5 гигабита мы там не увидим. Но в среднем мы понимаем, что загрузка на каждом отдельном порту усредненная нагрузка. Она как бы нам известна. И мы рассчитываем мощности своих каналов таким образом, чтобы мы, с одной стороны, не покупали какие-то излишние мощности, а с другой стороны, чтобы нам этого было достаточно в часы наибольшей нагрузке. Поэтому мы стараемся исходить из того, что у нас оборудование предназначено для решения определенной задачи, и мы не покупаем чего-то более мощного,

потому что это впустую выброшенные деньги, и мы не покупаем чего-то менее мощного, чем нам нужно, потому что это недовольные пользователи. Трафик, который будет бегать в провайдерской сети, он будет предъявлять разные требования к сети. То есть это, с одной стороны, какие-то приложения, которые требуют взаимодействия в реальном времени. Это голос поверх IP, видео поверх IP, только не видео, как ютубчик, а вот там стриминговое видео, например, тот же самый скайп. Видеоконференц-связь, какие-то онлайн-игры, которые могут генерировать достаточно большое количество трафика, и у которых есть определенные требования к качеству работы сети. Могут быть в сети провайдера приложения, которые не требуют взаимодействия в реальном времени, но которые могут достаточно интенсивно пожирать полосы пропускания. Ну, провайдеры такие штуки очень не любят. Это торренты, это онлайн-видео, всякие Netflix, YouTube и прочие радости жизни.

Они могут забить достаточно много полосы пропускания, но особенность таких приложений заключается в том, что им можно немножечко полосу подрезать, и они хоть и прожорливы, но они все равно могут смириться с тем, что мы даем им не всю полосу, которая есть, а там, допустим, чуть-чуть меньше. У этих приложений, на самом деле, вот даже у двух этих классов приложений принципиально разные требования к сети. Одним требуется, чтобы передавалось сравнительно немного трафика, но обязательно максимально быстро, с минимальной задержкой. Другим важно, чтобы была большая полоса пропускания, и неважно, что там с задержками будет. Как следствие, мы должны будем постоянно балансировать между требованиями разных приложений, мы должны будем понимать, что передается в нашей сети, как оно работает, и как мы должны будем реализовать оказание услуги таким образом, чтобы пользователь, который использует и один тип приложения, и другой тип приложения, был всегда бы доволен.

У провайдеров, как правило, основной набор услуг, который будут предоставлять эти провайдеры, будет предполагать использование протокола IP. Ну, то есть в сети предприятия, понятное дело, тоже IP есть, но в сети предприятия довольно часто предполагается, что достаточно обеспечить взаимодействие по Ethernet, а то, что там будет IP сверху бегать, это как бы дело десятое. У провайдеров, как правило, все сервисы, которые они будут предоставлять, работают именно по IP. Доступ в интернет через IP, доступ ко всяким сервисам телефонии через IP, мультикасс телевидения тоже через IP. Соответственно, все вот эти вот IP-сервисы, они требуют работы с большим количеством маршрутов, и как следствие, если у нас есть маршрутизация, если у нас есть большое количество маршрутов, мы должны будем использовать протокол динамической маршрутизации, который может работать с большим количеством маршрутов. Это протокол BGP. BGP в предприятиях встречается не очень часто, а вот у провайдеров это единственный,

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

То есть, если говорить про интерпрайз, как уже было сказано, в интерпрайзе убор идет на то, чтобы связанность просто была. Интерпрайзу, как правило, пофигу, что там внутри сети передается, потому что интерпрайз может купить себе оборудование, которое будет в 10 раз более мощным, чем это реально требуется. Если вам в сети предприятия нужно гонять, не знаю, видеоконференц-связь, проще всего в предприятии сказать, вот там у нас полоса используется на гигабит. Вот если мы проложим гигабитные каналы, нам мощности не хватит. Давайте проложим 10-гигабитные каналы. 10 гигабит не хватает. Давайте проложим 40 гигабит. И у нас заведомо полоса пропускания будет больше, чем это требуется для конкретно нашего приложения. И помните, была в свое время такая шутка, не шутка, новость про Бена Бернанке, который предлагал экономику Соединенных Штатов заваливать долларами, даже если потребуется разбрасывать их с вертолета. Но вот та же самая история и в интерпрайзе, что если вам требуется решить какую-то задачу в части связанности,

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

он далеко не единственный. Поэтому да, в телекоме намного больше будет применяться всяких решений по тому, как более эффективно фарвардить трафик, как более эффективно оказывать услуги. Если можно, оставив условный гигабит полосы пропускания, сделать так, чтобы пользователи были более счастливы, но при этом не покупать новое железо. Понятное дело, что телеком так сделает. В той ситуации, в которой предприятие скажет, ну и нафиг этот киос настраивать. Давайте просто купим более мощное железо. Давайте купим более мощные свечи. В провайдере, в сети провайдера, руководитель, если он грамотный руководитель, скажет, ребята, давайте настроим кулитов сервис. Давайте будем пропускать трафик до, к примеру, bandwidth test, до speedtest.net, до серверов local с более высоким приоритетом, чтобы у нас циферки, которые видит пользователь, когда запускает speedtest, они у него всегда показывали максимальное значение. Да, у нас переподписка есть. Да, если он по факту смотрит YouTube, мы его режем до 10 мегабит. Но по факту, когда он запускает speedtest,

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

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

но она при этом понимает, что так или иначе в интерпрайзе все равно все сводится к L2. А вот провайдер не может свести все к L2, ему приходится работать с IP. Если говорить про то, какие устройства где будут использоваться в идеальной модели сферического провайдера в вакууме с точки зрения ЦИСКи, то, соответственно, у нас так же, как и в случае с сетью предприятия, будут выделяться совершенно четко несколько уровней сети. И в отличие от модели ЦИСКо Enterprise Architecture, которую мы проходим на роутинге и свитчинге, у провайдерской сети уровней будет больше. То есть в классической модели ЦИСКи для предприятий есть уровень ядра, есть уровень distribution распределения и есть уровень доступа. Вот у провайдерской сети, в принципе, эти уровни тоже есть. Но есть еще один уровень, это уровень IP Edge. Как ни странно, получается, что уровни у нас четыре. Так вот, первый уровень, самый, наверное, жирный, это уровень ядра. Он будет нужен для того,

чтобы обеспечить быструю связь между блоками. То есть у нас сеть строится блоками. Если нам нужно будет достроить сеть, взять, подключить новый район, новый регион, мы, опять же, строим просто новый блок в сети и подключаем его к существующей сети. И вот связь между блоками сети, между регионами, если хотите, будет осуществляться через ядро. В ядре у нас будут работать супер-мега-быстрые, мега-мощные роутеры. Их будет мало, но они будут мощные и они будут быстрые. Ну, и, как следствие, они будут дорогие. Дальше. Уровень, который в сети предприятия назывался уровень распределения, distribution, в модели IP, NGN, SP Network, разделяется на два. То есть то, что у нас раньше в сети предприятия осуществлялось на уровне distribution, это было у нас предоставление пользователям каких-то политик безопасности, предоставление каких-то расширенных услуг.

То есть, например, мы могли сказать, давайте мы хотим, не знаю, выйти в интернет. Вот мы делали в этом случае отдельный блок и говорили, что вот на уровне провайдерской сети у нас есть отдельный блок, который подключается как просто новый distribution блок к сети предприятия. И вот он выходил в интернет. Здесь фактически мы будем делать примерно то же самое, только у нас есть горизонтальное разделение, у нас в каждом нашем блоке будут предоставляться определенные сервисы. И вот место, где начинают работать все наши сервисы IP, будет называться IP Edge. Про каждый из этих уровней буду говорить более детально. Сейчас я просто рамочно обозначаю какие-то свойства каждого из уровней, которые здесь есть. IP Edge — это то место, где у нас начинает работать протокол IP. то, что в сети предприятия тоже происходило на уровне распределения, на уровне distribution, это подключение access-свечей, если хотите. Вот оно в провайдерской модели

Cisco происходит на уровне агрегации. То есть в enterprise, если мы говорим про модель построения сети enterprise, вот эти два уровня — это фактически один уровень распределения. в провайдерской сети эти уровни разнесены на две части. Один уровень IP Edge, где у нас сервисы начинают работать, а другой уровень, уровень агрегации — это то, куда подключаются все access-свечи. Ну и, наконец, сам уровень access, сам уровень доступа, он, в принципе, что там, что там одинаковый. Иногда его называют Edge, то есть пограничный уровень. Это те устройства, куда подключаются сами абоненты. Понятное дело, что устройства на уровне доступа, они самые дешевые, потому что их много. Покупать туда что-то прямо совсем дорогое значит значительно удорожать саму сеть, поэтому здесь реализуются только самые какие-то простые, самые базовые задачи. Уровень доступа защищает сеть от пользователей, если это возможно, на каком-то самом базовом уровне, то есть не позволяет выключиться, допустим,

в чужой порт, не позволяет использовать какие-то неправильные адреса, ну то есть самые-самые простые задачи по защите сети. Да. В итоге получается, что если мы возьмем сеть предприятия, у нее есть три уровня, Core, дальше Distribution и Access. Если мы берем провайдерскую сеть, у нее уровень Distribution разделяется на два подуровня. Уровень IP Edge и уровень агрегации. На IP Edge у нас оказываются сервисы, проверяются политики безопасности, ну на уровне агрегации просто идет физическое соединение между Access-свечами. Давайте поговорим более детально про каждый из этих уровней, что конкретно в провайдерской сети будет где работать, потому что в сети предприятия, как уже говорилось, есть своя специфика, что там все довольно просто. У провайдеров все чуть-чуть посложнее. Если мы говорим про уровень ядра, то в ядре у нас работают специальные быстрые и очень дорогие роутеры.

Эти роутеры связаны между собой с использованием какого-то IGP протокола для внутренней связности. Вот в этом IGP протоколе мы не показываем никакие пользовательские маршруты. Для примера здесь можно, например, OSPF представить себе. Это OSPF специфический для внутренних нужд сети провайдера. То есть там не появляются пользовательские маршруты. Если говорить про то, как это рекомендует делать Cisco, то вы просто берете, на всех роутерах запускаете OSPF, устанавливаете соседские взаимоотношения, анонсируете лупбеки в этот самый OSPF, и у вас все роутеры в ядре могут видеть друг друга по адресам лупбеков. Дальше поверх этих лупбеков вы запускаете протокол BGP. В BGP вы запускаете все маршруты, которые ваши роутеры должны будут знать. Это, соответственно, будет BGP, если вы делаете только для, допустим, IPv4, просто BGP четвертой версии, или если вы хотите в этот BGP загонять маршруты

не только IPv4, но и другие, в этом случае вы запускаете мультипротокол BGP, то есть и IPv4, и IPv6, и какие-то VPN, L2VPN, L3VPN механизмы тоже можно будет реализовать с помощью этого мультипротокола BGP. Не на всех роутерах ядра BGP будет, то есть есть такая штука, как BGP, как называется это, BGP Free Core, то есть у нас на некоторых роутерах ядра BGP будет, которые граничат с уровнем IPv4, на некоторых, которые напрямую не граничат с IPv4, соответственно, BGP может и не быть. Происходит это за счет того, что у нас будет в ядре почти всегда работать протокол MPLS, который будет использоваться как транспорт для работы с MPLS у нас будет использоваться, соответственно, LDP, Label Distribution Protocol, и, ну, иногда будет использоваться, опять же, BGP. Вот. Это такой базовый набор протоколов,

который почти всегда используется в ядре, то есть USPF для внутренней связности, BGP для кастомерских маршрутов, LDP для работы с MPLS, и для того, чтобы обеспечить какие-то требуемые характеристики для пропускания трафика через сеть ядра, мы будем использовать механизмы Quality of Service и механизмы трафика инжиниринга. Что трафик инжиниринг, что Quality of Service находятся за пределами нашего курса, но, безусловно, в сети ядра чаще всего эти штуки можно будет встретить. То есть если вам нужно будет обеспечить для работы какого-то пользовательского приложения какой-то механизм передачи данных с повышенным качеством, чтобы, допустим, трафик телефоней ни в коем случае не терялся, то вот эти вот два товарища, они вам, конечно же, очень пригодятся. Уровень IP Edge — это половинка бывшего уровня distribution. Это, соответственно, там, где у нас идет работа с протоколом IP.

Если взять и представить себе вот ту картинку, которая там была, что вот это Core, это IP Edge, это агрегация и вот это вот Access, то получается, что Core у нас самый, так скажем, маленький уровень, у нас там немного устройств, но эти устройства очень дорогие, очень быстрые. И следующий уровень — это IP Edge. На уровне IP Edge у нас происходит обработка IP. Мы здесь уже, как правило, не работаем напрямую с всякими штуками типа MPLS. То есть мы можем работать с уровнями ядра, мы можем говорить, что дорогое ядро построит, пожалуйста, нам, допустим, туннель между двумя точками присутствия. У нас есть одна точка присутствия в одном районе, другая точка присутствия в другом районе. Нам нужно построить туннель. И мы пользуемся тем, что уровень ядра нам предоставляет такую возможность. Вот IP Edge — это, соответственно, будет тот самый уровень, где идет оказание услуг, где у нас идет работа с сервисами. Если нам нужен стык с интернетом, мы говорим, окей, у нас есть услуга выхода в интернет,

у нас есть какой-то пользователь, который приходит, который посылает трафик в устройство, которое находится на уровне IP Edge. Мы говорим, окей, этот трафик предназначен для интернета. У нас точка выхода в интернет где-то вот здесь. И мы пробрасываем, опять же, трафик между двумя этими самыми точками присутствия. Мы это делаем с использованием протокола IP. Здесь напрямую работа с MPLS не идет. Здесь могут быть построены какие-то туннели. Это туннели могут быть, опять же, заказанные со стороны ядра с помощью MPLS, или может быть построены с помощью L2TP, или, может быть, здесь просто напрямую будет идти IP трафик. То есть, как вы захотите, так это и будет осуществляться. Но вы на этом уровне работаете именно с привычными нам правилами обработки IP. Хотите использовать access control list, хотите использовать механизмы просто обычной маршрутизации, ну, то есть, здесь идет просто обычный IP. На уровне агрегации мы будем связывать

между собой наши куски сети. То есть, это то самое место, куда стекаются все физические каналы. Если мы говорим, что у нас сеть строится блоками, то есть, у нас есть какой-то один блок, один регион, допустим, второй регион, третий регион, и эти регионы между собой связываются через сеть ядра. Вот здесь у нас ядро. То обеспечение физической связанности внутри блока у нас идет как раз на устройствах уровня агрегации. Здесь есть возможные варианты того, как строить сеть внутри региона. Это либо строить сеть на основе топологии звезда, либо строить сеть на основе топологии кольцо. То есть, если мы строим кольцо, то оно будет выглядеть как-то вот таким вот образом. У нас устройство формирует действительно физическое кольцо, и трафик всегда имеет два варианта, как можно выйти из одной точки сети в другую. То есть, если нам нужно обеспечить подключение пользователя, который находится где-то здесь, чтобы он мог выйти в сеть ядра, то он может пойти либо по одной стороне кольца,

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

на уровне агрегации? Они выполняют задачи по безопасности. Здесь у нас будут работать привычные нам на дистрибьюшн уровне механизмы защиты. То есть будут здесь работать IP Source Guard, будет работать Storm Control, будет, возможно, работать какой-то механизм, который защитит нашу сеть от случайной петли, если мы используем сеть с петлей. То есть подозрительно здесь все похоже на Spanning 3, да? Вот. Но Spanning 3 это в сети Ethernet, естественно говоря. Не всегда у нас будет физическая инфраструктура предполагать, что у нас строится сеть на основе Ethernet. Вы можете построить сеть на, не знаю, на санете, на чем угодно, и у вас там будет работать TDM, может быть, у вас будет, не знаю, ATM сеть. То есть что здесь будет использоваться зависит от конкретного вашего оборудования, от конкретного вашей сети. возможно, вы купили какую-то сеть другой компании и пытаетесь интегрировать ее в свою сеть. В этом случае, да, у вас получается,

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

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

расстояния, протянуть канал на большие расстояния, то есть, он и в сегменте LAN-сетей работает, и в MAN-сетях работает. Но, когда-то, давным-давно, Ethernet все-таки была технология сугубо для построения LAN-сетей, и для того, чтобы обеспечить пользователей доступом к сети провайдера, использовались технологии, ну, либо на основе механизма DSL, Digital Subscriber Line, либо ADSL, SDSL, ну, там, варианты есть, мы про них будем отдельно говорить, либо сравнительно новая вещь, это пассивные сети оптические, Passive Optical Network, есть просто PON, есть Gigabit PON, есть Gigabit Ethernet PON, там, есть чем поживиться. Может быть, это будут какие-то базовые станции, то есть, опять же, вот мобильная связь, например, это все равно же доступ к провайдерской сети, и, соответственно, вот у вас есть мобильный телефон, он подключается по радио к мобильной станции провайдера. Это вот в этом случае мобильная станция будет уровнем доступа. Задача, которую можно будет решить

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

решить какую-то простую задачу по классификации и маркировке. Опять же, учитывая, что на уровне доступа, как правило, железки максимально тупые и максимально дешевые, они, как правило, не могут какую-то продвинутую классикацию выполнить, но даже с использованием каких-то простых механизмов мы можем сделать что-то совсем примитивное. Мы можем сказать, что у нас, например, есть пользователи, которые подключаются по одному тарифу, а есть пользователи, которые подключаются по другому тарифу. И мы можем там в 802.1.p 3 битика приоритета указать. Вот мы можем взять и на пользователя, подключающихся по разным тарифам, проставить разные вот эти вот меточки их данных. Ну и здесь же могут работать какие-то простые механизмы защиты сети. Ну, опять же, да, если у нас оборудование позволяет это сделать, мы можем защититься от каких-то атак со стороны пользователя, чтобы пользователь там MAC-адрес не поменял или не попытался устроить атаку на наши свечи. Ну, то есть, в принципе, здесь в сети предприятия все то же самое будет работать. За исключением того, что в сети предприятия у нас почти всегда Ethernet на аксессе,

а в сети провайдера не всегда Ethernet у нас будет работать на уровне доступа. Так, далее. Когда мы говорим про провайдерскую сеть, на самом деле чаще всего мы говорим не про какую-то единую монолитную организацию. Чаще всего провайдер, даже не провайдер, а услуги, которые оказывает провайдер, это услуга достаточно комплексная. Если пользователь приходит к провайдеру и говорит, дорогой провайдер, я хочу подписать с тобой контракт, да, пользователь, кастомер подписывает контракт на оказание определенных услуг связи, но по факту взаимодействие, которое будет обеспечивать оказание этой услуги, будет происходить между несколькими разными организациями чаще всего. Так, да. Соответственно, у нас встречаются несколько различных типов организаций, каждый из которых будет иметь свое собственное название.

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

с которой пользователь подписал договор. Классический пример — это в Европе очень частая популярная вещь подключения пользователя с использованием технологий на основе DSL. То есть это ADSL, VDSL и так далее. В этом случае, как правило, телефонная компания, которая принадлежит все провода, она оказывает услугу подключения пользователя физически. Дальше она говорит, окей, мы предоставляем услугу пользователю, но мы делаем это абсолютно прозрачно для конечного пользователя и действуем от имени компании интернет-сервис-провайдера. Но при этом, по факту, это совершенно другая, совершенно независимая сущность. И вот компания, которая обеспечивает физическое подключение пользователя, будет называться Network Service Provider. А дальше уже провайдер интернета, подключающийся к сети Network Service Provider в какой-то точке, получает трафик пользователя и направляет его в интернет. То есть в какой-то момент получается, что есть две разные организации, которые занимаются разными вещами. То есть одна организация — это NSP, Network Service Provider. Другая организация — это ASP, Internet Service Provider.

Есть пользователь, который подключается к Network Service Provider. По его сети трафик доходит до точки стыка. И дальше в точке стыка у нас, соответственно, уже происходит переход трафика в зону ответственности провайдера, провайдера интернета. Дальше провайдер интернета куда-то должен этот трафик девать. То есть он в какой-то момент должен будет сказать, окей, у меня моя сеть стыкуется с еще одной сетью моего, допустим, оплинка магистрального провайдера. И, соответственно, трафик проходит дальше куда-то в другую сеть, там дальше в третью сеть и так далее. То есть трафик по факту перекладывается между сетями разных организаций. Internet Service Provider — это организация, которая обеспечивает услугу доступа в интернет. То есть она в какой-то момент подписала договор с неким оплинком и оказывает услугу пропускания трафика в сторону этого самого оплинка. Network Service Provider — это тот, кто провод фактически предоставляет. Ну, чаще всего это телефонная компания, у которых этих проводов много. Но бывает так, что одна и та же организация и доступ в интернет продает, и сами провода прокладывает. Ну, тогда это будет просто удобно,

и не нужно будет взаимодействовать с какой-то другой сторонней организацией. Если у вас достаточно много своих монтажников, если у вас технология доступа предусматривает, что вы можете для абонента проложить провод самостоятельно, ну, окей, прекрасно. Далее. Что еще бывает? Бывают компании, которые оказывают услуги связи специфически, например, услуги телефонии. В этом случае, соответственно, будет компания, которая оказывает услуги телефонии, будет называться Telecommunication Service Provider или TSP. На экзамене все вот эти вот аббревиатуры могут встретиться, поэтому имеет смысл их, ну, как минимум, да, посмотреть, что они существуют. Вот TSP – Telecommunication Service Provider. Сюда будет относиться и телефония аналоговая, и аналоговое телевидение. Если речь идет про именно IP-телефонию, то в этом случае есть специальные отдельные аббревиатуры ITSP – Internet Telephony Service Provider. это компания, ну, которую, например, можно взять и подключиться через интернет

с помощью SIP-софтфона и получить доступ к телефонии. Часто довольно будет компания, которая оказывает услуги доступа в интернет, заниматься и предоставлением услуг телефонии тоже. Достаточно популярный набор услуг будет называться TriplePlay, когда конечному абоненту, физическому лицу, провайдер будет предоставлять одновременно три услуги. Первый – доступ в интернет, чтобы можно было в ВКонтакте потупить. Второй – это доступ к телефонии. То есть у пользователя, получается, телефонный аппарат, который подключает к своему абонентскому устройству. И этот абонентский аппарат, у него есть свой городской номер, с него можно звонить, на него можно тоже звонить. Ну, и в этом случае тогда Internet Service Provider будет одновременно и Internet Telephony Service Provider тоже. Есть компании, которые занимаются предоставлением определенных услуг, но не телефонии, не телевидения. В этом случае они могут называться Application Service Provider. В русскоязычном интернете часто для таких компаний

есть еще специальный термин Content Provider. Ну, вот это компания, которая дает доступ к какому-то ресурсу, ну, например, вот ВКонтакте или Яндекс. Это компании, которые дают доступ к своим, допустим, базам. Так или иначе, когда вы в ВКонтакте сидите, все, что вы делаете, вы заполняете базу ВКонтакте, и вы получаете какой-то материал из базы ВКонтакте. Ну, вот ВКонтакте фактически предоставляет своим пользователям доступ к своей базе, и в этом случае он является по-русски контент-провайдером, а по-английски в терминах экзамена он будет называться Application Service Provider. Точки стыка между сетями разных организаций будут называться Exchange Point. И если мы говорим про интернет-провайдер, который хочет стыковаться с другими организациями, с другими сетями именно для предоставления услуг интернета, то такие стыки, как правило, происходят в специально выделенных местах.

Они будут называться Internet Exchange Point или IXP. И, соответственно, это, как правило, специальные отдельные машинные залы, куда любая организация, которая хочет обмениваться трафиком между разными сетями, заходит, запускает свой провод, ставит нам свое оборудование. И дальше вот сама площадка Internet Exchange Point будет уже обеспечивать взаимодействие между этими самыми сетями. Если говорить про Россию, во многих крупных городах в мире, ну, в частности, в Москве, есть такие точки стыка. Если говорить про Москву, там, M9, например, Moscow IXP, иногда ее называют MSK IX, MSK IX, Internet Exchange Point. Ну, и иногда ее называют M9, потому что вот это вот IX похоже на латинское... простите, да, на римскую цифру 9.

Ну, и получается M9. Так, далее. Если говорить про сеть провайдера, скорее всего, интернет-провайдера, потому что вот мы сейчас все-таки рассматриваем сценарий с построением все-таки интернет-провайдера, не всякого там Яндекса или чего-то еще, а вот именно интернет-провайдера там, где у нас есть пользователи, которые платят деньги за выход в интернет. Соответственно, выход в интернет, мы чаще всего говорим просто интернет какой-то абстрактный, на самом деле интернета сейчас есть два. Есть интернет IPv4, есть интернет IPv6. Ну, и естественно, что в IPv4 интернете ресурсов пока что намного больше, и поэтому, если мы не специфицируем, какой именно интернет мы имеем в виду, мы чаще всего имеем в виду интернет IPv4. Так вот, для доступа в IPv4 интернет пользователь отправляет IP-пакеты, и эти пакеты надо как-то будет куда-то девать, то есть надо в какой-то момент будет обработать. Понятное дело, что происходить это будет на уровне устройства, которое относится к уровню IP Edge,

и, соответственно, устройство, которое будет со стороны провайдера заниматься обработкой таких пакетов, будет называться BRAS, Broadband Remote Access Server. Этот сервер, BRAS, он будет заниматься тем, что будет принимать пакеты от пользователя практически напрямую, и, соответственно, с этим пакетом что-то делать. То есть это будет первое устройство в сети, которое будет работать с трафиком пользователя именно на уровне IP. Соответственно, здесь у нас появляется проверка на соответствие присылаемого трафика определенному набору политик. То есть мы должны будем сказать, что у нас пользователь отправляет пакеты только из-под своего IP-адреса. Он не может брать и подставлять чужие IP-адреса в качестве адреса источника. Мы здесь должны будем проверить, что пользователь, допустим, не нарушает параметры своего тарифного плана. То есть все политики, которые нам нужно будет реализовать, мы должны будем сделать именно на нем. И если необходимо, будет quality of service какой-то настроить, допустим, выделить какой-то трафик, который для этого пользователя будет более приоритетный

или менее приоритетный, соответственно, тоже это все можно здесь будет сделать. Можно будет проклассифицировать трафик, промаркировать, и какие-то возможные механизмы quality of service, как, например, полисинг и шейпинг, сразу здесь же и реализовать. Здесь же будет происходить учет пользовательских услуг. То есть если у нас, например, есть ограничения для пользователя по тарифу, что пользователь получает там не больше, к примеру, 5 гигабайт трафика, то в какой-то момент мы должны будем трафик посчитать. Вот, как правило, именно на брасе будет уйти учет трафика. Соответственно, нам нужно будет посчитать, сколько ресурсов потребил пользователь и отправить полученную статистику на какой-то внешний сервер, ну, например, на биллинг. Может быть такое, что у пользователя будет также предусмотрена политика, что если он скачал больше, чем нужно, то, соответственно, мы должны будем его отключить. Ну, то есть если у нас по тарифу пользователь купил 5 гигабайт трафика,

и вот он уже 5 высосал и начинает скачать 6, мы должны будем в какой-то момент сказать, что дорогой пользователь, извини, у тебя интернет кончился. Вот. Здесь можно будет встретить терминирование пользовательского канала в том смысле, что если у нас есть сеть провайдера, то есть вот у нас уровень Core, дальше у нас здесь у нас IP Edge, и, соответственно, дальше там у нас уровень агрегации и уровень доступа. Я не буду рисовать агрегацию и доступ, но у нас есть пользователь, который подключается к сети, и дальше мы его, соответственно, доводим до устройства, которое у нас находится на уровне IP Edge. Все промежуточные устройства, которые есть на уровне доступа, на уровне агрегации, они не работают с IP, или, по крайней мере, они, если работают с IP, то они работают, не обращая внимания на IP-заголовок, который проставил сам пользователь. Мы стремимся к тому, чтобы первое устройство, которое начинает обращать внимание на пользовательские IP-пакеты,

был как раз вот этот вот самый Brass. Он же будет смотреть, соответственно, что пакеты приходят именно от того пользователя, от которого они как бы заявлены. И фактически мы можем сказать, что вот здесь вот у нас между пользователем и этим самым Brass-сервером получается такая своего рода труба. И вот в этой вот трубе у нас будет идти как раз и учет трафика, и проверка трафика на соответствие политикам, и все-все-все-все. Ну все. Если говорить про какие-то примеры того, как это может быть реализовано, ну, например, провайдер может сказать, давайте мы будем подключать пользователей с использованием PPPoE. Вот. У нас будет вот эта вот PPPoE-шная труба. Она будет строить физический канал, ну, не физический, виртуальный канал между Brass'ом и абонентским устройством. И, соответственно, весь трафик, который будет направлять пользователя, он будет направлять в эту самую трубу PPPoE-шную. А дальше из Brass'а будет эта труба вытаскивать трафик, и Brass'у будет его уже обрабатывать. Он сразу будет видеть, какие пакеты пришли от какого пользователя.

Если это PPPoE-шная труба, там будет происходить аутентификация пользователя, авторизация и, естественно, учет. Кроме Brass'а в сети будут и другие устройства, и нам будет нужно знать их название. Давайте пробежимся по этим самым названиям, начиная с уровня ядра. То есть в ядре у нас есть роутеры. Это роутеры достаточно мощные, они работают с IP MPLS. И, соответственно, в ядре у нас будут роутеры, которые граничат с уровнем IP Edge, и поэтому они должны работать и с IP тоже. И такие роутеры будут называться PE-роутеры. И, соответственно, они будут как раз работать с уровнем IP, будут принимать трафик пользователей, будут понимать, что этот трафик пользователей не просто какой-то трафик, а именно IP-шный трафик. И вот PE-роутер — это Provider Edge. Provider Edge. Это вот трафик именно IP-шный.

Они будут видеть, и они будут находиться где-то рядом с ядром. То есть, скорее всего, они будут находиться на стыке уровня ядра и уровня IP Edge. И, соответственно, есть роутеры, которые чисто PE-роутеры. Они находятся внутри уровня ядра. Они не видят пользовательский трафик в виде IP-пакетов. То есть, чаще всего они будут видеть этот трафик, уже обернутый в MPLS-ной заголовкой, и они будут работать только с MPLS. Соответственно, вот этот чистый PE-роутер — это роутер, который находится целиком в уровне ядра. Если говорить про работу, соответственно, туннеля нашего пользователя, который пересылает трафик на Brass, дальше Brass понимает, что это за трафик, перекладывает его в уровень ядра, и дальше в уровне ядра он уже начинает свое путешествие в виде MPLS до тех пор, пока не закончит путешествие по ядру, и не должен будет в какой-то момент выйти обратно уже в уровень Edge. И, соответственно, из-за уровня Edge он обратно дальше уже куда-то выйдет в другую сеть. Опять же, у нас здесь будет стык с чужой другой сетью. И здесь у них тоже свои будут такие же уровни.

Соответственно, мы из одного уровня IP Edge перегложим трафик в другой уровень IP Edge, другой уже компания. Ну, в какой-то момент, да, нам придется отправить трафик в другую сеть. Устройства, которые будут находиться в нашей сети, это будут P-роутеры и P-е-роутеры в сети ядра. Это будут, соответственно, вот эти вот Brass, Broadband Remote Access Server со стороны пользователей, которые принимают трафик от пользователей. И со стороны самого пользователя будет находиться устройство, которое называется CE — Customer Edge. Иногда же здесь будет эта же железка, называться Customer Premises Equipment, CPE. Это устройство, которое физически расположено со стороны клиента, со стороны кастомера. То есть, если, например, вы подключаете пользователя, предоставляя пользователю просто обычный шнурок, то вот то, что пользователь воткнет в этот самый шнурок, это будет CPE. Если вы предоставляете пользователю не просто шнурок, а шнурок, на конце которого стоит какая-то железочка, ну, например, не знаю, вы предоставляете доступ с помощью ADSL,

вы в этом случае пользователю, ну, должны будете поставить ADSL модем, правда? Вот этот вот ADSL модем в современных сетях провайдерских, он, как правило, устройство, которое занимается всем. То есть он и Wi-Fi роутер, он же там на самом деле и маленький свитчик, в нем четыре порта чаще всего есть, он же еще и FXS, то есть позволяет подключить аналоговый телефон. То есть это такой универсальный робот, который может делать вообще все. И вот в этом случае CPE, это Customer Premises Equipment, будет железочка вот эту, которую вы поставили со стороны пользователя, которая подключается к вашей сети напрямую. Как правило, по вот этой самой CPE будет проходить граница зоны ответственности. Это очень важный параметр. В какой момент заканчивается ваша ответственность и начинается ответственность чата еще. В случае, если вы работаете через Internet Exchange Point между двумя компаниями, которые оказывают услуги связи, там все понятно. Там вы притаскиваете свой хвостик в Internet Exchange Point,

ваша соседняя организация притаскивает такой же хвостик в Internet Exchange Point, и дальше вы уже фактически там варитесь внутри этой самой IXP. Там уже зона ответственности, понятно, где заканчивается одна и начинается другая. А вот в случае, когда у вас есть клиент, который пытается подключиться к вашей сети, и он говорит, а у меня ничего не работает. Вот очень сложно иногда бывает пользователю доказать, что действительно это в вашей сети какая-то проблема, а не пользователь со своей стороны что-то сделал. То есть, например, если пользователь вытащил из розетки вот этот вот самый шнур питания модема, кто виноват в этом, пользователь или вы? То есть у вас должна быть прописана ответственность каждой стороны, что конкретно делает каждая страна для того, чтобы канал работал. Так, далее. Что еще тут стоит заметить? Про границу зоны ответственности. Да, чаще всего прописывается граница зоны ответственности по порту CPE.

То есть вы говорите, что вот у вас, если CPE-шка работает, если с ней все хорошо, если она запитана, если она корректно подключена к сети, то вот трафик, который выплевывается в патч-корд, который идет, допустим, в компьютер, который подключен непосредственно к модему, за него уже отвечает конечный пользователь. А вот за работу самого порта отвечаете вы. Так, PGE-роутер и Brass — это одно и то же или не всегда? Это немножко разные вещи. То есть это не то, чтобы они были прям разные устройства. Это разные классификации. Brass — это та самая железка, которая обеспечивает подключение пользователей. APE — это та самая железка, которая еще работает с IP, но уже понимает, что такое MPLS. Это может быть одно и то же устройство, вполне. И даже часто бывает одно и то же устройство. То есть вы принимаете трафик от пользователя, вы понимаете, что это IP-трафик, вы проверяете, что у этого IP-пакета, который пользователь сформировал, допустим, корректно IP-заголовки, что там прописаны правильные IP-адреса.

И после чего вы его заворачиваете в MPLS и отправляете в ядро. Никаких проблем, так можно делать. Так, так, так, так. Если говорить про то, как устроен современный интернет, то вы, да, я вам буду рассказывать про то, что примерно изображено на картинке. Тут хаос. Каждая сеть, каждая компания — это, соответственно, свое ядро, свое IP-эдж, свои Brass, свои стыки между сетями. Иногда это будет происходить на интернет-экшенчпоинтах, иногда это будет происходить просто где попало. То есть взяли две компании и обнаружили внезапно, что у них в одном кондиционном люйке оптика проходит. Но они могут вполне взять, договориться и сказать, давайте мы возьмем и бросим просто друг другу прямое оптовое окно. Вот. Так что стыки между сетями, они бывают разные, они бывают как бы гламурные, красивые через экшенчпоинты, или бывают негламурные.

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

чтобы, ну, как-то не хамить, для того, чтобы не перегружать сеть соседа, вы отправляете по каналу связи между двумя вашими сетями только тот трафик, который из вашей сети должен пройти в сеть соседа. То есть вот тот трафик, который вот так по такому пути пойдет, он пойдет по короткому стыку между двумя сетями. В то же время вы не передаете в сторону сети соседа тот трафик, который предназначен для какой-то совершенно другой, третьей сети. То есть, например, наша сеть, это мы назовем «мы», сосед 1 или сосед 2. Вот. У нас есть прямой канал как соседу 1, так как соседу 2, и будет, наверное, некрасиво, если мы на соседа 1 будем передавать трафик, чтобы он передал его дальше для соседа 2. Потому что, ну, а что это вообще такое? Почему мы не должны нагружать его сеть трафиком, который вообще к нему, вообще говоря, отношения не имеет? Если мы договоримся с ним об этом, мы скажем, дорогой соседушка, мы тебе будем передавать трафик, который не для тебя,

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

а предназначен для передачи данных куда-то дальше, в этом случае вы, как правило, будете платить за это деньги. И в этой ситуации у вас появляется термин оплинг. Это компания, которая согласна принимать трафик ваш для того, чтобы передавать его куда-то дальше, ну, за это берет какую-то свою копеечку. И современный интернет устроен как раз с помощью вот таких взаимоотношений. То есть кто-то дружит с кем-то бесплатно, кто-то с кем-то дружит за деньги. Если говорить про то, что можно, скажем, увидеть, если вы просто обычная компания, обычное предприятие, то вы, как правило, ни с кем не договариваетесь бесплатно. Вы приходите к провайдеру, говорите, дорогой провайдер, я тебе буду передавать трафик, который предназначен просто для всего интернета. Я тебе буду платить деньги, и, соответственно, ты передавай этот трафик дальше. А в этом случае appetite and пользовалась вашей пром栃, компанией, или двум разным провайдерам, или двум разным провайдерам, но очень редко бывает так, чтобы компания

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

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

Понятное дело, что если у вас есть такой вот крупный-крупный провайдер, который никому за что не платит, в этом случае он должен действительно иметь доступ со всеми-всеми-всеми остальными такими же провайдерами, которые тоже никому не платят. Поэтому вот такие вот особенные игроки, магистральные игроки рынка интернет-услуг, они будут называться специальным словом — tier 1. Провайдеры первого уровня — это вот провайдеры, которые никому не платят за оплинки. Они только и исключительно дружат между собой бесплатно. Соответственно, не может быть такое, что какие-то два провайдера между собой, такие крупные, не дружат, потому что тогда трафик от одного такого провайдера до другого пройти не сможет никаким образом. Он физически мог бы пройти через третьего провайдера, но третий провайдер, который дружит с первым и со вторым, он не будет пропускать транзитный трафик через себя бесплатно. Он за это захочет денег. Tier 1 провайдеры — это те провайдеры, которые не платят денег за транзит своего трафика в другие сети.

Количество провайдеров, которые относятся к этому уровню, таких супермагистральных провайдеров ограничено. Они все дружат между собой. Еще раз подчеркну, что у них обязательно есть стыки между всеми вот такими вот крупными провайдерами. Некоторое время назад был своего рода скандал, когда два таких крупных провайдера поссорились, и, соответственно, их клиенты не могли передавать трафик друг к другу. Ну, понятное дело, что это скандал уровня всея интернета, поэтому этим компаниям ничего не осталось сделать, кроме как помириться. Запоминать этих провайдеров не обязательно, но, тем не менее, как бы примерный список знать надо. Это американский AT&T, CenturyLink. Недавно с ним был смешной случай, когда у них вся сеть упала из-за того, что весь менеджмент трафик у них был в одном Вилане. Deutsche Telekom, НТТ японский. Orange французский, Telekom Italia,

телефоника испанская, TeleSNR финская, ну, Verizon, да. Можно иногда встретить специфический термин, который называется TR1 региональный. То есть если у нас есть провайдер, который внутри своего региона со всеми только пирится бесплатно, и никому не платит за транзит в пределах своего региона, но дальше за транзит иностранного трафика ему приходится платить. Ну, в этом случае, да, есть такой вот термин региональный TR1. Есть провайдеры TR2. Это те провайдеры, которые хотят стать на уровень выше и хотят пириться со всеми бесплатно, но из-за того, что они все-таки не настолько крупные и не со всеми могут договориться о бесплатной передаче трафика, они кому-то вынуждены платить деньги. То есть за какой-то транзит они вынуждены платить. Из крупных провайдеров, которые здесь стоит попянуть, это Hurricane Electric. Иногда их называют провайдером TR1,

но на самом деле нет, они платят за транзит. У них есть Vodafone, крупный провайдер, который действительно хочет стать TR1, но пока еще не стал. British Telecom. Ну, да, то есть это действительно крупные сети. Они достойны того, чтобы считаться магистральными игроками, но немножко не вышли по уровню, потому что с кем-то у них все-таки есть соглашение о платной передаче трафика. TR3 — это провайдеры, которые платят за почти весь свой транзитный трафик. То есть они могут немножко с кем-то попериться бесплатно, но основную часть трафика они, соответственно, передают за деньги. Если говорить про провайдеров в целом, то, как правило, набор услуг у всех провайдеров более-менее похожий. То есть понятное дело, что есть какие-то компании, которые специализируются на чем-то конкретном. Но если говорить просто про абстрактного сферического провайдера в Вакууме, то мы будем встречать следующее обозначение.

Следующие услуги чаще всего в прайсе, если можно так выразиться. Первое, основное, с чем сталкиваются физические лица, это услуга TriplePlay. Это доступ в интернет, просто чтобы браузер открывал нужные соэтики. Это телефония. Если мы говорим про IP-телефонию, то, соответственно, да, представляется пользователем какой-то, не знаю, софтфон или что-то еще, или IP-телефон. Либо если мы говорим про сценарий, в котором пользователю ставится ЦПЕшка, то устройство, которое ставится пользователем, в нем будет порт аналогового телефона, и в него можно подключить, не знаю, дек-трубку или даже просто аналоговый аппарат с кнопками или с диском, и у вас будет работать городской телефон. В последнее время эта штука все менее и менее популярна, то есть провайдеры все еще ее предлагают, но, тем не менее, на этом рынке наблюдается определенный спад, и, скорее всего, в ближайшие лет 10 телефония, вот как отдельная прямо услуга,

за которую можно брать серьезные деньги, практически вымрет. То есть на этом рынке идет действительно серьезная деградация. Количество денег, которое в этой отрасли крутится, оно падает очень и очень значительно. И есть еще, соответственно, услуга телевидения. Это как видеостриминговые всякие сервисы, так и видеон-деманд. То есть если мы говорим про телевизор в том виде, в котором просто воспринимается обывателем, то там есть первый канал, второй канал, там Россия 24, НТВ. Ну вот это стриминговое телевидение, когда у нас есть какой-то источник вещательного трафика, и вот он показывает на всех телевизорах одинаковую картинку. Ну и видео-он-деманд – это видео, при котором пользователь может заказывать определенные программы, определенные записи, фильмы. Тоже по сути своей примерно то же самое. То есть нагрузка на сеть примерно такая же получается. И вот традиционные провайдеры, они, как правило, для физлиц предоставляют все эти три услуги.

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

в одном офисе и в другом офисе, и все, что отправлено в этот провод с одной стороны, вылезало бы с другой стороны. И вот этот вот тип соединения, VPN, тип услуги, скажем, он довольно популярен, он довольно дорогой по сравнению с обычным доступом в интернет. Так что если вдруг вы как физлицо говорите, да блин, я сейчас то же самое сделаю, я сейчас возьму, там с одной стороны микротик поставлю, с другой стороны микротик поставлю, и там IP-секом все это дело наверну сверху, и пущу через интернет. Да, действительно, через интернет пустить трафик будет сильно дешевле, чем использовать услугу MPLS-VPN. Но с VPN-ом провайдерским, вот этим самым бизнес-VPN, история заключается в том, что трафик, который идет по сети провайдера в случае подписки на услугу VPN, он будет передаваться контролируемо, и, соответственно, провайдер будет нести ответственность за то, как он этот трафик передает. У провайдера будут соглашения о качестве обслуживания, и провайдер должен будет действовать в соответствии с такими соглашениями.

Так, далее, далее, далее. Есть дополнительный рынок, скажем, для зарабатывания денег у провайдеров. Это всякие managed services, как это называется, управляемые услуги, не по-русски звучит. Но судя по тому, что я его не перевел на слайде, назовем это просто managed services. В России штука не очень популярная за рубежом, однако она очень и очень популярная. Это фактически, когда компания сдает часть своей сети, часть оборудования, которое формирует внутреннюю сеть предприятия под управление своему провайдеру. То есть этот провайдер управляет внутренними железками предприятия. Если, например, у вас есть роутер, который выходит в интернет, в предприятии 2 роутера, вы даете на них логин и пароль своему провайдеру, и ваш провайдер рулит вашими железками для того, чтобы обеспечить вам выход в интернет. А вы за это платите ему какую-то копеечку. Вот такого рода услуга, на самом деле, как я уже сказал, довольно популярная за рубежом,

в России не очень, но, в принципе, наверное, можно предположить, что через некоторое время что-то подобное появится у нас. Кроме того, можно представить себе всякие смежные услуги в сети провайдера. То есть из того, что я сам видел, это услуга по видеонаблюдению, когда провайдер обеспечивает доступ к видеокамерам, которые подключаются к его сети напрямую. То есть, если, например, у вас есть какой-то коттеджный поселок, провайдер заключает договор с этим самым коттеджным поселком на видеонаблюдение. Провайдер монтирует камеры, подключает эти камеры к своей сети, возможно, ставит какое-то хранилище, к которому можно подключиться и посмотреть записи. Ну и, соответственно, связь этих камер с сетью провайдера, она как раз обеспечивается сотрудником провайдера и само подключение, оно физически принадлежит провайдеру, сами линии. Для поселков такая услуга, на самом деле,

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

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

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

передаваемые другими приложениями. Да, он будет бегать, да, он будет занимать большую полосу пропускания, но проблемы будут вам создавать именно игры, именно приложения, основные на взаимодействии в реальном времени. Это телефонии, это всякие системы видеоконференций, Skype, Facebook Messenger, что там еще бывает, которые позволяют общаться по видео. То есть, если у вас в сети начинаются какие-то лаги, начинаются потери пакетов, то и телефонии, и видеосвязь начинает деградировать моментально. Сюда же будут относиться игрушки. Как ни странно, это индустрия, которая продвигает отрасль связи вперед семимильными шагами, и трафик игрушек может занимать весьма и весьма заметную долю от общего трафика. Причем игрушки, они точно так же, как и телефонии, точно так же, как и видео, они требуют высокого качества связи, они не допускают потерь пакетов, и если у вас начинаются потери, то, соответственно, игровое качество, качество экспириенса начинает резко падать.

Из того, что стоит упомянуть, в России вот очень популярная игра World of Tanks, она хорошо может, соответственно, как сказать, она может довольно сильно загрузить, загрузить вам сеть при определенных обстоятельствах, не в смысле полосы пропускания, а в смысле, если вдруг у вас начинаются какие-то проблемы с сети, то вот она может вам создать много проблем, именно потому, что нестабильный канал для нее будет являться определенной проблемой. В случае с американским рынком, вот из того, что примерно на уровне World of Tanks находится, можно вспомнить League of Legends, это игра компании Riot Games, и эти ребята, которые построили, которые создали эту игру, они для того, чтобы минимизировать проблемы, возникающие в сетях провайдеров,

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

они могут создать нагрузку на сеть весьма значительную. Как правило, такие приложения в современном мире будут основаны на протоколе HTTP. То есть сюда будут относиться те порталы, которыми мы пользуемся ежедневно. Это Google, Facebook, YouTube, что там еще бывает, ВКонтакте. У таких приложений, как правило, нет никаких специальных требований. Если вдруг потеряется один пакетик Facebook, да ничего страшного, Facebook работает плохо, который поверх TCP работает чаще всего. И потерялся один пакет не страшно, он перезагрузится, его переотправят, и взаимодействие будет практически таким же, как в случае, если пакет бы не потерялся. Но есть нюанс. Такие приложения, они могут быть очень и очень прожорливы. Особенно, если мы говорим про YouTube. У него, соответственно, требования к полосе пропускания могут быть настолько большими, что Google для того, чтобы, скажем, обойти проблему,

что один банальный сервис YouTube может сажать всю полосу пропускания у всех провайдеров, он даже ставит специальные контент-сервера. То есть у Google есть такая штука, которая называется Google Cache Server. GCC, как? Google Cache. Не важно, что. GCC, короче. И, соответственно, Google ставит свои кэширующие сервера в сети провайдера. То есть вы, как провайдер, получаете коробку от Google, ставите ее в свою сеть, и пользователи, которые будут находиться внутри вашей сети, они будут подключаться через этот кэширующий сервер. И, соответственно, если у вас два пользователя будут смотреть одновременно один и тот же ролик с YouTube, он у вас прокачиваться по сети будет только один раз. Он дальше будет кэшироваться на этом сервере GCC. И таким образом вы можете экономить полосу пропускания, вы можете экономить ресурсы своего апплинга. Вот. Что еще здесь можно будет встретить? Есть специфическая нагрузка, которая, скажем, не встречается в сетях зарубежных,

но в России, тем не менее, сплошь рядом приходится иметь дело с подобными приложениями. Я сейчас говорю о приложениях, контролирующих качество сети. То есть понятное дело, что если у нас есть пользователь, который периодически ходит на спид-тест и проверяет, насколько вы сильно его обманываете, когда он платит вам за 50 мегабит, а по факту вы ему даете 10, то вы будете видеть, что пользователь ходит на спид-тест, он нажимает кнопку, и вы очень сильно хотите, чтобы цифра, которую видел пользователь, там всегда, независимо от того, что у вас с сетью происходит, соответствовала тому, что пользователь законтрактовал. Поэтому для таких приложений, которые используются для контроля, вы хотите, как правило, обеспечить максимальное качество работы. Если мы говорим про тот же самый спид-тест, вот даже если у вас идет, не знаю, чемпионат мира, вы видите, что у вас все каналы оплинки забиты по максимуму видео, стриминговым видео, потому что идет вот финал чемпионата мира по футболу, или там, не знаю, олимпиады, или что-то еще, но кто-то запускает спид-тест.

Вы очень сильно хотите в этот момент пожертвовать какими-то пакетами видео, но пропустить спид-тест с максимальным качеством. Да, он отожрет 50 мегабит от вашего оплинка, но при этом пользователь увидит, что у него 50 мегабит есть, и он не будет вам звонить и надоедать вашему колл-центру криками, что ж выгоды такие, я вам плачу за 50 мегабит, а вы мне даете только 5. Поэтому для того, чтобы избавиться от подобных проблем, вы всегда хотите подобные приложения пропускать с максимальным качеством. Ревизор — это приложение, которое работает немножко в другую сторону. Если мы говорим про спид-тест, спид-тест всегда должен работать хорошо, а вот ревизор — это такая штука, которая должна скорее работать плохо. Если вы не знаете, Роскомнадзор предоставляет список заблокированных ресурсов, которые не должны открываться у провайдеров, в сети провайдера. И поэтому для того, чтобы проконтролировать, насколько качественно провайдеры исполняют волю Роскомнадзора,

Роскомнадзор в обязательном порядке в сети провайдера ставит свои коробочки, вот эти вот самые ревизоры системы. И эта коробочка по своему какому-то известному ей алгоритму периодически ломится на запрещенные ресурсы, и она должна будет, соответственно, не получить к ним доступ. Если в случае со спид-тестом мы говорим, что спид-тест гарантированно должен работать хорошо всегда, то вот ревизор должен плохо работать всегда в обратном смысле, чтобы он всегда видел, что все заблокировано достаточно качественно. Обычно для того, чтобы не сильно пугать пользователей, потому что если вы слишком сильно начнете блокировать все ресурсы, у вас пользователи будут очень сильно обижаться. Вот для того, чтобы обеспечить корректную работу, в кавычках корректную работу ревизора, обычно создают специальную песочницу, то есть такую среду, в которой все заблокированные ресурсы будут действительно заблокированы по-честному. А самих пользователей в эту песочницу не пускают, потому что если вы начнете все по-честному блокировать, у вас отвалится PlayStation Network,

у вас отвалятся, как правило, какие-то банки, у вас отвалятся половины Amazon Web Services. Ну то есть, да, вот с такими приложениями, как ревизор, лучше дружить специальным образом, вот именно в отдельной песочнице, и никому про это не говорить. То есть у вас пользователи живут отдельно, и блокировка в их компьютерах происходит по одному алгоритму, а у ревизора блокировка происходит по другому алгоритму. Еще здесь можно будет вспомнить некие проблемные приложения, в кавычках проблемные, в том смысле, что вы должны будете знать, что некоторые приложения в определенных ситуациях могут вызывать больше проблем, чем если бы они вообще не работали. Например, есть такой протокол, SMTP называется, протокол передачи электронной почты. Вот. Этот протокол очень часто используется для рассылки спама. Ну то есть для рассылки спама он и используется. И если говорить про количество писем, которые отправляются каждый день, то мне встречалась цифра,

что 90% писем, которые присылаются, это спам. Особенно если они присылаются по публичным сетям. Поэтому если вдруг вы видите какую-то активность на порту, характерную для работы SMTP, то есть это 25-й порт, как правило, TCP-шный, то вы должны будете подумать, что с этим портом имеет смысл сделать. Может быть, вы хотите пропускать его через какую-то систему анализа трафика, и если вы будете видеть, что пользователь, например, подхватил какой-то сифилис и начинает рассылать спам, ну вы тогда 25-й портом пристрелите. Может быть, вы просто скажете, что любая рассылка по 25-му порту возможна только через наш собственный сервер, ну и дальше вы там, не знаю, transparent proxy сделаете на этот сервер. Или просто пользователю скажете, что 25-й порт у нас в сети не работает, ходите вот через вот этот вот кэширующий сервер SMTP, который заведомо рабочий всегда. То есть как работать с такими приложениями, вы должны будете решить сами для себя, хотите ли вы пользователям разрешить делать все, что угодно, даже если это заведомо нездоровая какая-то активность,

и потом словить кучу жалоб на абьюз ящик. Ну или каким-то образом ограничить пользователя в его правах и получить кучу жалоб на колл-центр. Еще одна проблема — это, соответственно, SMB. Это штатный сервис по шарингу файлов, который есть в Windows. Если у вас пользователь получает белый IP-шник и публикует на нем Windows сервер или Windows клиент, там может быть доступен SMB. В последних версиях Windows сервер или Windows клиентов даже штатно работает Windows Firewall, но тем не менее пользователи имеют тенденцию его отключать, и если у вас голая винда начинает смотреть в 139-м портом и 135-м портом в интернет, то это вопрос времени, как скоро ее поломают. Поэтому, как правило, вот такие хорошо известные порты сервисов, которые имеют ряд, ну, опять же, хорошо известных уязвимостей, может быть, имеет смысл их, опять же, каким-то образом ограничивать. Намного проще сказать, что, ребята,

наш штатно по умолчанию не работает там 135-й, 139-й порт через наш сервис, если вам надо, обращайтесь, мы его вам включим вручную, но под вашу ответственность, чем ловить ежедневно поток пользователей, которые взяли и с белым IP-шником выпустили в Windows интернет и немедленно схлопотали вирус, начали рассылать все подряд. И Gluster, и Petio, и кто там только еще в OneKai. Ну, вот, так что знаете, что у вас в сети бегает, понимаете, какой профиль характерен именно для вашей сети, какие приложения в вашей сети присутствуют и какие требования к работе сети они проявляют и адаптируете работу вашей сети именно под эти приложения. Причем, естественно, нельзя сказать, что у нас есть одно ключевое приложение, которое работает, а все остальные типа неважно. Они все важны. То есть, если у вас пользователи знают, что в сети есть IP-телефония, и они пытаются воспользоваться IP-телефонией и начинают там все квакать, плюкать, они будут недовольны. Если вы говорите, окей, у нас телефония начинает работать, но неважно, как начинает работать, там, не знаю, условный спидтест, то

опять же, да, пользователи будут недовольны, потому что они будут проверять скорость работы сети и будут видеть там совершенно произвольную цифру. Поэтому вы должны закладываться под все ключевые приложения, которые у вас есть. Вы должны будете вести обратную связь от ваших сотрудников колл-центра, ну или первой линии поддержки, по каким приложениям пользователи чаще всего обращаются. Ну и, соответственно, для этих приложений обеспечивают нормальную работу сети. Если мне память не изменяет, это последний слайд, да, это последний слайд, который в общем показывает, как распределяется трафик в современном интернете. И здесь, на самом деле, интересная картинка, которая не очень характерна для России, может быть, но, тем не менее, для всего остального мира она актуальна. И 15% всего трафика в интернете генерирует сервис Netflix. Это, на самом деле, катастрофический объем трафика. Если вы провайдер и вы будете смотреть на то, что в вашей сети происходит, вы увидите, что да, что 15% это у вас Netflix. Это видеокартинка. Да, у Netflix есть хорошие механизмы,

которые позволяют им подстроиться под нестабильные работающие каналы, но, тем не менее, чем лучше качество картинки, тем, естественно, сеть у вас должна работать для него лучше. А когда 15% всего трафика требует какой-то привилегированную обработку, вы возникаете, соответственно, у вас возникает вопрос, на какие шиши нам это делать. То есть нам нужно будет тогда ни про какие оверсубскрипшены не говорить, нам нужно будет прям по-честному выделять под это дело полосу. Второй видеостриминговый сервис YouTube. Он тоже, соответственно, предоставляет схожую услугу, как и Netflix, но так же, как и Netflix, он предоставляет механизмы адаптации под каналы произвольного качества. Опять же, YouTube предоставляет Google кэш-сервера, GCC, поэтому, если вы понимаете, что у вас трафика YouTube слишком много, вы можете к Google обратиться и сказать, дорогой Google, поставь нам, пожалуйста, свой контент кэш-сервера. Далее из того, что еще стоит упомянуть.

Quick — это протокол, который использует HTTP-шные вложения, но традиционные HTTP используют вложения в TCP, а Quick использует HTTP-шные вложения в UDP. И эта штука, она может быть очень прожорливая. То есть он имеет те же самые особенности, что и любой UDP. Он может вам сожрать абсолютно любой канал, он может выжрать всю полосу пропускания, которая у вас есть, и он работает реально быстро. Поэтому все современные сервисы, они так или иначе адаптируются под этот самый Quick. И если у вас используется в сети адаптация под этот самый протокол, вы, возможно, захотите в какой-то момент его аппетиты подурезать. Здесь показано, что количество трафика PlayStation в зарубежных сетях небольшое, порядка 2,7%. И сюда же можно отнести на самом деле и Microsoft-овские Xbox-сервера.

Но тем не менее, да, доля этого трафика достаточно заметная. И сюда можно же еще также отнести все вот эти вот игрушки, которые я упомянул, всякие World of Tanks, League of Legends. Количество игрового трафика, оно тоже большое. И игровой трафик, он, как уже говорилось, весьма и весьма критичен. Если у вас геймер, который играет в какую-то игрушку, видит, что у него начинает все рассыпаться, разваливаться, картинка лагает, игрушка перестает нормально играться, он будет звонить и донимать в ваш колл-центр и будет говорить, что вы же такие нехорошие люди, берете денег, ну и дальше вспоминается старый добрый ролик про не единого разрыва. Поэтому для некоторых приложений вы должны будете понимать, что ваша сеть должна будет быть адаптирована именно под них. То есть это сразу вот эти вот 15% тут, 12% здесь, там 4% игрового трафика, ну то есть достаточно много. А, амазоновский сервис, да, действительно еще забыл про него совсем,

то же самое, видеосервис, то есть количество трафика, который вы должны будете в явном виде учитывать и под который вы должны будете в явном виде адаптировать свою сеть и строить правильно политики обработки этого трафика для того, чтобы именно этот трафик обрабатывался приоритетно по сравнению со всем остальным, ну и будет достаточно много таких приложений и вы должны будете их все знать. Понятное дело, что сюда еще не включены всякие бизнес-приложения типа PLS VPN, которые должны быть еще более приоритетны по сравнению со всем этим. Но, к счастью, для него не требуются ваши оплинки. То есть это все, в общем, про оплинки. Так, ну, разговорная часть нашего модуля закончена. Давайте дальше перейдем к следующей теме. Следующая тема, если меня память не изменяет, канала связи. человека не матчем. То есть we filmed по-пр置а, а где самого к 귀여zer Hmm, не умICK. ら доле ikkeling новое