Интернет

Сейчас почитал, поразмыслил и начал понимать, что, возможно, я рано сегодня порадовался отличной статистике внедрения RPKI в массы в этом году.

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

Да, внедрение RPKI безусловно можно назвать достижением, но только для определённого круга заинтересованных организаций. Для российского телекома это может стать началом конца.

Суть здесь вот в чём. Внедряемый стандарт подписей рассылок интернет-адресов основывается на иерархической системе сертификатов. То есть это почти та же система, только с дополнениями в виде номеров сетей и анонсов ip-адресов. Данный стандарт предполагает, что ведущие держатели мировых сетевых мощностей будут доверять только анонсам сетевых маршрутов от их непосредственных исполнителей, т.е. тех, кто эти маршруты будет собственно осуществлять, либо их непосредственных начальников. Неформально если - теперь сложно будет ходить "налево".

Проблема вот в чем. Мы, получается, переходим к иерархической схеме управления, к древовидной. И сам протокол, и принципы, на которых он основан, суть древовидные структуры. А это идёт в разрез с философией Интернета, который создавался и, тьфу-тьфу, функционирует в распределённом режиме. Интернет -это структура произвольного графа (за исключением некоторых сервисов типа DNS, уже названной системы сертификатов PKI и той же раздачи адресов), без ориентированности на строгую иерархию, без единственной головы.

Голов у Интернета в этом смысле много - если считать ими точки концентрации трафика. Теперь давайте разберёмся, что же это за "головы" мирового Интернета. Это в первую очередь телеком операторы т.н. бэкбона интернета - самых скоростных и широкополосных каналов связи. (Их принято называть операторами Tier 1, т.е. первого высшего уровня. Эти операторы никому не платят за интернет, поскольку они и являются его основой. К ним подключаются средние операторы Tier 2 и т.д.).

Также в группу голов можно смело заносить крупных поставщиков контента, типа Netflix, Amazon, Vkontakte и Google. А также их крупнейших посредников - точки обмена трафиком, или пиринг-центры, представляющие из себя ассоциации разных интернет- и контент-провайдеров разного уровня. Именно во многом благодаря их существованию Интернет более-менее распределён, а значит устойчив к сбоям и, что немаловажно, к монополиям.

Во многом за счёт последних скорости интернета выше, а цены ниже. Именно они вносят значительный вклад в представление Сети как графовой распределённой структуры, у которой нет основных 3-4 владельцев, в основном американских (хотя надо отдать должное, скандинавская Telia Sonera на первом месте сейчас). Так вот, внедряемый стандарт основан на иерархии подписей маршрутов, аналогично иерархии подписей сертификатов сайтов.

И выдача маршрутов (как мне сейчас представляется) соотносится с современным положением вещей примерно так же как сама нынешняя система сертификатов PKI соотносится с распределёнными системами типа блокчейна. Ну или другая аналогия, политическая - как однополярный мир соотносится с многополярным. Программистская аналогия - как централизованный и распределённый контроли версий ПО. Финансовая: как Бреттон-Вудская, ныне Ямайская, система (золотодолларовый стандарт) соотносится с золотым стандартом начала 20-го века.

Вернёмся к Интернету.

По принятому протоколу доверие маршрутам обеспечивается только согласно иерархическим лицензиям, выданным от основных их владельцев - крупнейших телекомов бэкбона Интернета. То бишь из тех "голов", что я перечислял, влияние перетекает только к первой немногочисленной группе "владельцев" интернета. А различные региональные игроки остаются в стороне. Существующие ассоциации (пиринговые центры) наподобие российских MSK-IX или DATAIX, пока что довольно влиятельные, потеряют возможность обмениваться трафиком, так как их участники не смогут обмениваться маршрутами, нарушая границы своих иерархий, то есть обмен налево будет затруднён. А это и был основной смысл существования этих точек обмена. В результате контроль над трафиком уйдёт к крупнейшим телекомам. Российские телекомы не глобальны и впадут в зависимость от западных. Точки обмена трафиком просто распадутся. Установится монополия (или если хотите олигополия) в сфере коммуникаций, маршруты будут прокидываться через головы, они станут длиннее, а значит связь будет во многих случаях медленнее. Ну и конечно вырастут цены. За большую цену вы получите худшую связь.

И ещё один аспект - в целом под предлогом защиты Интернета зарубят связность и распределённость (свойства графа интернета), количество интерконнектов, что не только скажется на качестве и скорости, но и уменьшит надёжность связи.

Я надеюсь, что на Хабре найдутся специалисты, которые могут развеять мои сомнения и опасения. Или объяснят, что, например преимуществ у новой технологии больше чем недостатков (если они есть).

Удачного всем дня!

Привет! В этой статье я расскажу о ещё двух вариантах VPN, используемых нами для включения клиентов с помощью Мультисим Резервирования, это L2TP иL2-VPN. Первый используется для включения сервисов Интернет, второй для включения каналов L2 MPLS.

Самый первый L2TP

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

Архитектурно схема выглядит так:

Описание:

В роутер устанавливаются две Sim-карты, прописываются APN и настраивается радио-интерфейс, плюс настраивается WAN-интерфейс для входящего проводного канала, если он есть. Sim-карты прописываются в типовые APN, все APN разных операторов связи объединены в один VRF и получают стандартизированные приватные IP-адреса из своих APN.

На нашем RADIUS-сервере при подключении создается сессионный аккаунт для клиента, информация о этом аккаунте будет использована BRAS при построении сессии. Роутер начинает строить L2TP-сессию либо через проводной WAN-интерфейс (интернет-канал), либо через радиоинтерфейс, в зависимости от типа работы (Fix+LTE/3G или "чистый" LTE/3G), сессия терминируется на BRAS с типовыми настройками прописанными на RADIUS сервере.

Также на RADIUS-сервере возможна настройка Framed Route с публичной интернет подсетью, которая настраивается на LAN-интерфейсе роутера и транслируется клиенту. Таким образом, каждый клиент имеет один статический IP-адрес на туннеле с приватной адресацией и NAT на трех LAN-интерфейсах, и дополнительно прописанную публичную подсеть (обычно это /31 или /30 подсеть) на одном LAN-интерфейсе.

Так как туннель может строиться через кабельное подключение (интернет-канал) или Sim-карты, а подсеть маршрутизируется за туннель, клиент получает статичные настройки вне зависимости от используемой транспортной сети.

При пропадании кабельного канала роутер за 10-20 секунд перекидывает трафик на радиоинтерфейс и первую Sim-карту, а в случае проблем и с ней производит смену рабочей Sim-карты на резервную, обычно эта смена занимает 60-90 секунд.

За выбор маршрута трафика между кабелем и радиосетью отвечает встроенный инструмент NQA (Network Quality Analysis) и значения preference route:

#nqa test-instance admin inet test-type icmp destination-address ipv4 4.2.2.2 frequency 20 source-interface GigabitEthernet0/0/4 start now##ip route-static 0.0.0.0 0.0.0.0 Virtual-Template1 preference 40ip route-static 4.2.2.2 255.255.255.255 GigabitEthernet0/0/4 dhcpip route-static 85.21.4.234 255.255.255.255 GigabitEthernet0/0/4 dhcp track nqa admin inetip route-static 85.21.4.235 255.255.255.255 GigabitEthernet0/0/4 dhcp track nqa admin inetip route-static 100.64.0.0 255.255.254.0 Cellular0/0/0 preference 70ip route-static 100.64.0.0 255.255.254.0 NULL0 track nqa admin inet#

А за выбор активных Sim-карт отвечает скрипт автопереключения, написанный на Python.

Схема также имеет свои ограничения: cкорость доступа ограничена 30-50 Мбит/с, а MTU=1450.

Дальнейшее направление развития - это реализация этой же схемы с резервированием проводных каналов, но уже с использованием BGP, для анонса LAN-сети либо через кабель, либо через туннель, это позволит использовать роутер в виде резерва на широкополосных каналах в 100-200 Мбит/с и разделением маршрутов трафика по кабелю и по туннелю. Естественно, это будет работать только на проводных каналах от Билайн, для работы через других провайдеров мы отправляем весь трафик через L2TP-туннель.

Самый трудный L2 MPLS

Этот вариант получился самым последним в наших решениях на сегодняшний день, и был самым тяжелым с точки зрения реализации. Используемый протокол для этого типа подключений на Huawei AR129 SVPN L2TPv2, на ответной части стоит Cisco ASR1001-X, которая является ответной частью туннеля и выводит трафик в MEN сеть.

Архитектурно сеть выглядит так:

Настройка такого режима на роутере Huawei AR129 выглядит так:

#interface Tunnel0/0/0tunnel-protocol svpnencapsulation l2tpv3l2tpv3 local session-id 3l2tpv3 remote session-id 4tunnel-source 100.64.16.63tunnel-destination 100.64.0.43#

Самый трудный для нашей реализации ввиду особенностей работы протокола, сессия для L2 MPLS инициируется с IP-адреса Sim-карты, которая активна в конкретный момент для этого туннеля, и к IP-адресу привязываются значения и на CPE и на ответном узловом PE, а в случае проблем с работающей LTE/3G сетью происходит смена IP на Sim-карте.

У нас были следующие варианты выхода из этой ситуации:

• Использовать GRE-туннель, и уже через этот туннель пускать туннель с L2 MPLS.

• Назначать одинаковые IP-адреса на Sim-карты при настройке.

• Сделать так, чтобы конфигурация туннелей менялась в роутере в зависимости от Sim-карты.

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

Соответственно, пришлось реализовывать реконфигурацию роутера "на лету. Если учесть, что используемый нами Python-скрипт для автоматического переключения Sim-карт и так уже выполнял большую часть логики, нам осталось его немного дополнить парой функций:

При смене Sim-карт нужно было вызвать процесс изменения в параметрах настройки туннеля remote session-id и tunnel-source, и при обратной смене Sim-карт вернуть эти значения:

def l2_sim2(o, cli):log_syslog(o, ops.CRITICAL, "New parameters applied: " + l2_lses2 + " " + l2_rses2 + " " + l2_vcid2 + " " + l2_src2 + " " + l2_dst2)output, n1, n2 = o.cli.execute(cli, "system-view")  output, n1, n2 = o.cli.execute(cli, "interface Vlanif1")output, n1, n2 = o.cli.execute(cli, "undo link-bridge Tunnel0/0/0")output, n1, n2 = o.cli.execute(cli, "quit")output, n1, n2 = o.cli.execute(cli, "quit")result = o.timedelay(seconds=60, milliseconds=0)output, n1, n2 = o.cli.execute(cli, "system-view")  output, n1, n2 = o.cli.execute(cli, "interface Tunnel0/0/0")output, n1, n2 = o.cli.execute(cli, "tunnel-protocol svpn")output, n1, n2 = o.cli.execute(cli, "encapsulation l2tpv3")output, n1, n2 = o.cli.execute(cli, "interface Tunnel0/0/0")output, n1, n2 = o.cli.execute(cli, "l2tpv3 local session-id " + str(l2_lses2))output, n1, n2 = o.cli.execute(cli, "l2tpv3 remote session-id " + str(l2_rses2))output, n1, n2 = o.cli.execute(cli, "tunnel-source " + str(l2_src2))output, n1, n2 = o.cli.execute(cli, "tunnel-destination " + str(l2_dst2))output, n1, n2 = o.cli.execute(cli, "quit")output, n1, n2 = o.cli.execute(cli, "quit")output, n1, n2 = o.cli.execute(cli, "system-view")  output, n1, n2 = o.cli.execute(cli, "interface Vlanif1")output, n1, n2 = o.cli.execute(cli, "link-bridge Tunnel0/0/0 vc-id " + str(l2_vcid2) + " tagged")output, n1, n2 = o.cli.execute(cli, "quit")output, n1, n2 = o.cli.execute(cli, "quit")output, n1, n2 = o.cli.execute(cli, "save", {"continue": "Y"})def l2_sim1(o, cli):log_syslog(o, ops.CRITICAL, "New parameters applied: " + l2_lses1 + " " + l2_rses1 + " " + l2_vcid1 + " " + l2_src1 + " " + l2_dst1)  output, n1, n2 = o.cli.execute(cli, "system-view")  output, n1, n2 = o.cli.execute(cli, "interface Vlanif1")  output, n1, n2 = o.cli.execute(cli, "undo link-bridge Tunnel0/0/0")  output, n1, n2 = o.cli.execute(cli, "quit")output, n1, n2 = o.cli.execute(cli, "quit")result = o.timedelay(seconds=60, milliseconds=0)  output, n1, n2 = o.cli.execute(cli, "system-view")output, n1, n2 = o.cli.execute(cli, "interface Tunnel0/0/0")output, n1, n2 = o.cli.execute(cli, "tunnel-protocol svpn")output, n1, n2 = o.cli.execute(cli, "encapsulation l2tpv3")output, n1, n2 = o.cli.execute(cli, "l2tpv3 local session-id " + str(l2_lses1))output, n1, n2 = o.cli.execute(cli, "l2tpv3 remote session-id " + str(l2_rses1))output, n1, n2 = o.cli.execute(cli, "tunnel-source " + str(l2_src1))output, n1, n2 = o.cli.execute(cli, "tunnel-destination " + str(l2_dst1))output, n1, n2 = o.cli.execute(cli, "quit")output, n1, n2 = o.cli.execute(cli, "quit")output, n1, n2 = o.cli.execute(cli, "system-view")  output, n1, n2 = o.cli.execute(cli, "interface Vlanif1")output, n1, n2 = o.cli.execute(cli, "link-bridge Tunnel0/0/0 vc-id " + str(l2_vcid1) + " tagged")output, n1, n2 = o.cli.execute(cli, "quit")output, n1, n2 = o.cli.execute(cli, "quit")output, n1, n2 = o.cli.execute(cli, "save", {"continue": "Y"})

Какие плюсы у этой схемы работы в режиме L2 MPLS:

• Роутер работает только прозрачным Ethernet до нашего РЕ, схему можно применять еще и как для Интернет, так и для IP VPN-включений.

• MTU стал побольше, чем у варианта с IPSec.

• Можно проводить легкую бесшовную подмену кабельных каналов при авариях.

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

В следующих статьях расскажем про USB Deployment инструмент по простой настройке роутеров, Python-скрипт, который используем для переключения Sim-карт, и интеграцию нашего Мультисим-решения с Облачной АТС (в роутере есть встроенный SIP-клиент и два FXS порта, мы просто не могли не попробовать их использовать).

В одном из комментариев спрашивали про скорости роутера по IPSec.

По результатам наших тестов скорость составляет больше 50 Мбит/с (IPSec в режиме IKEv2, iperf3 - server), то же самое к режиму работы с L2TP-туннелем. Скорости поднимали и выше, но мы и не планировали предлагать клиентам больше 50Мбит/с по нашему решению, т.к. во-первых упираемся в "гигиенический" предел по LTE, во-вторых роутеры планировали использовать вместе с настройкой доп. сервисов типа SIP PBX (расскажем в следующей статье), и в-третьих, на смену Huawei AR129 у нас приходит Huawei AR617, который более производителен, что нам ещё предстоит испытать.

Здравствуй, уважаемый читатель!

Многие из нас слышали о слежке за пользователями в интернете и о сборе персональных данных, некоторые сталкивались с этим не понаслышке.

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

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

Согласно результатам исследованияEFF (Electronic Frontier Foundation), уникальность отпечатка браузера очень высока, и он содержит в себе нижеописанные данные:

• user-agent (включая не только браузер, но и версию ОС, тип устройства, языковые настройки, панели инструментов и т.п.);

• часовой пояс;

• разрешение экрана и глубину цвета;

• supercookies;

• настройки cookie;

• системные шрифты;

• плагины к браузеру и их версии;

• журнал посещений;

• другие данные.

  Если говорить о статистике, то только раз на 286 777 случаев случается полное совпадение отпечатков браузеров двух разных пользователей.

Согласно ещеодному исследованию, точность идентификации пользователя при помощи отпечатка браузера составляет 99,24%.

Рассмотрим вершину айсберга и приведём простые примеры, что может случиться с собираемыми о вас данными:

сбор данных для ведения статистики;

сбор данных для показа рекламы;

сбор данных для продажи организациям;

сбор данных для осуществления незаконных действий;

сбор данных для проведения целенаправленных атак;

сбор данных для кражи и мошенничества;

многое другое.

А контролируете ли вы передачу этих данных, если да, то как? Какими средствами защиты информации и плагинами вы пользуетесь? На этот вопрос каждый из вас может ответить в комментариях.

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

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

Ряд сотрудников IT, юридического, финансового и других отделов уже понимают, о чём речь. И эту информацию мы тоже отдаем неизвестным нам ресурсам, трекерам и маячкам, не говоря уже о злоумышленниках.

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

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

Многие компании и их сотрудники становятся уязвимыми для целенаправленных ATP-атак, а это уже влечет за собой более крупные риски и ущерб. Готовы ли мы принимать эти риски?

Согласно проведённому мной опросу, многие руководители, специалисты и рядовые граждане не готовы к этим рискам, так как при их возникновении они сталкиваются или могут столкнуться с рядом проблем:

понижение заработной платы;

лишение премии;

увольнение с работы;

финансовые и репутационные риски организации.

На рисунке ниже вы можете ознакомиться с данными компании PositiveTechnologies за 2019 год и сделать выводы о типах украденных данных. Для статистики были взяты данные за 2019 год, так как отчет за весь 2020 год от PositiveTechnologies еще не сформирован.

Этот вопрос мы прояснили, но давайте постараемся ответить на вопрос А как эти данные крадутся ещё?. Для ответа на этот вопрос мы обратимся к статистике от той же организации и рассмотрим ее на рисунке 3.

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

Для решения этих проблем была начата разработка двух версий продукта Nemezida DNT:

Nemezida DNT Enterprise Edition версия продукта, созданная для более глубокой защиты компаний и корпоративного пользователя.

Nemezida DNT Home Edition бесплатная версия для домашнего пользователя с функцией режима защиты Перископная. Начиная с режима защиты Рабочая, продукт будет монетизироваться.

На рисунке 4 вы можете ознакомиться c функциями продукта, которые планируются к реализации, часть из них уже реализованы.

На текущий момент у нас реализован следующий функционал:

подмена Fingerprint;

подмена cookie;

подмена user agent;

VirusTotal;

Cisco Talos.

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

Особенность нашей разработки заключается в мультифункциональности, она показана на рисунке 5.

Нашими дизайнерами было создано несколько тем для нашего плагина, Home Edition и Enterprise Edition. На рисунке 7 Вы можете ознакомиться с Home Edition темой нашего плагина, она будет доступна по умолчанию для всех режимов защиты, но сменить ее можно будет на другую, только имея лицензию с уровня защиты Рабочая.

Для версии Nemezida DNT Enterprise Edition была разработана тема в трех тонах: Белый, Черный, Синий, с которыми вы можете ознакомиться на рисунках 8, 9 и 10.

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

Многие интересовались, на каком стеке мы ведем разработку нашего продукта, ответ на этот вопрос находится на рисунке 11.

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

Выйти в релиз мы планируем через 3-4 месяца благодаря вашей обратной связи о нашем проекте, прохождению опроса и поддержке разработки на платформе Boomstarter.

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

Спасибо за внимание!

Когда мы купили квартиру и делали в ней ремонт, телефоны были еще кнопочными, а Wi-Fi роутеры если и существовали, то в качестве диковинки. Предполагалось, что интернет будет подключен через витую пару к компу, а сам комп будет стоять на балконе, потому что балкон будет теплым и в нем будет кабинет. Квартира была без отделки, и поэтому мы решили сделать умный ход чтобы не тащить провода под плинтусами от коридора до балкона (как обходить двери?) мы заложили гофру в бетонный пол и протащили кабель напрямки. И нет, штробить бетон не пришлось, потому как он и так был снят для монтажа теплого водяного пола. Первые пару лет я даже гордился таким решением. Еще бы! Никаких дыр в стенах, никаких уродских кабель-каналов и интернет где нужно! Но года через 2-3 начали появляться всякие гаджеты, мы купили Wi-Fi роутер и тут появилась проблема.

На схеме роутер отмечен синим крестиком.

Если в кабинете и в соседней комнате все было шикарно, то на кухне (она же зал, где диван и все часто тусят) сигнала почти не было. Мешала несущая кирпичная стена. Для решения вопроса я рассматривал 3 варианта:

1. Купить новый мощный роутер, который будет пробивать все преграды. За и против:

+ Изящное решение: не надо ничего сверлить и переделывать глобально.

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

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

2. Купить повторители.

+ Опять же не надо ничего вскрывать и сверлить и нет минусов предыдущего пункта.

- Учитывая схему нашей квартиры и расположение розеток нужно минимум 2 повторителя, чтобы обойти стену.

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

3. Продырявить стену рядом с роутером и поставить в зале свой роутер.

+ Надежный сигнал

+ Опрятный внешний вид

- Непонятно как это реализовывать и возможно ли это вообще?

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

Зачем ему две антенны? Вот бы взять одну и протащить в соседнюю комнату? Я позвонил в магазин, торгующий железом и спросил:

-Подскажите, у роутера такого-то есть 2 антенны, они обе равноценные? Каждая и передает и принимает? Или одна только передает, а другая только принимает сигнал?

-ХЗ, вежливо ответил продавец и порекомендовал звякнуть производителю.

Я так и сделал.

- ХЗ, вежливо ответил производитель.

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

Тогда я решил рискнуть и купил удлинитель. Вот такой:

Сначала поэкспериментировал так. Выкрутил одну антенну из роутера совсем, а вторую прикрутил через удлинитель и отнес на максимальное расстояние от роутера. Работает! Также проверил другое гнездо роутера работает! После этого пробурил отверстие. Сверлил на уровне около 4 см над полом, предварительно сняв плинтуса.

Самым сложным в этом процессе было найти бур подходящей длинны. Толщина стены оказалась 50 см! Не то, чтобы было легко ее пробить и попасть куда нужно, но найти нужный инструмент (не покупать же из-за одной дырки!) было сложнее.

Решение оказалось идеальным. Обе антенны, как выяснилось опытным путем, равноценны.

В зале антенна просто торчит на проводе (он довольно жесткий) в неприметном месте.

В результате все розетки свободны, сигнал уверенный и при этом не избыточный.

Кстати упомяну еще один лайф-хак запитать роутер через таймер в розетку. Вот такой:

Зачем?

Во-первых, затем, что нет лишнего излучения ночью, когда инетом никто не пользуется.

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

В третьих, ежедневное отключение роутера на 7 часов продлевает ему жизнь, а перезагрузка только на пользу.

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

Вся эта история приключилась со мной уже много лет назад и вероятно сейчас есть более изящные решения вопроса, но возможно кому-то подойдет именно такой вариант. От себя могу сказать, что схема отлично обкатана и 100% рабочая. У меня до сих пор все тот же роутер. Также с годами выяснилось (особенно когда ребенок дорос до личного гаджета), что в вопросе таймера п. 2 стал для нас гораздо более актуальным, чем п.1

Для будущих учащихся на курсе "Java Developer. Basic" подготовили перевод статьи.

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

Насколько быстро работает gRPC? Довольно быстро, если вы понимаете, как построены современные клиенты и серверы. В первой части я показал, как легко добиться улучшения на 60%. В этом посте я покажу, как добиться улучшения в 10 000%.

Как и в первой части, мы начнем с готового сервиса "ключ-значение" на Java. Сервис способен обрабатывать запросы на создание, чтение, изменение, удаление ключей и значений одновременно от нескольких клиентов. Весь код можно посмотреть здесь, если вы хотите с ним поэкспериментировать.

Конкурентность сервера

Давайте посмотрим на класс KvService. Этот сервис обрабатывает RPC, отправленные клиентом, контролируя, чтобы ни один из них случайно не испортил состояние хранилища. Для гарантии этого сервис использует ключевое слово synchronized, чтобы быть уверенным, что одновременно будет активен только один RPC:

private final Map<ByteBuffer, ByteBuffer> store = new HashMap<>();@Overridepublic synchronized void create(    CreateRequest request, StreamObserver<CreateResponse> responseObserver) {  ByteBuffer key = request.getKey().asReadOnlyByteBuffer();  ByteBuffer value = request.getValue().asReadOnlyByteBuffer();  simulateWork(WRITE_DELAY_MILLIS);  if (store.putIfAbsent(key, value) == null) {    responseObserver.onNext(CreateResponse.getDefaultInstance());    responseObserver.onCompleted();    return;  }  responseObserver.onError(Status.ALREADY_EXISTS.asRuntimeException());}

Хотя этот код является потокобезопасным, но он очень дорогой: активным может быть только один RPC! Нам нужен способ, позволяющий безопасно выполнять несколько операций одновременно. В противном случае программа не сможет использовать все доступные процессоры.

Убираем блокировки

Чтобы решить эту проблему, нам нужно немного больше знать о семантике наших RPC. Чем больше мы знаем о том, как должны работать RPC, тем больше оптимизаций мы сможем сделать. Для сервиса ключ-значение можно заметить, что операции с разными ключами не мешают друг другу. Когда мы обновляем ключ "foo", это не имеет никакого отношения к ключу "bar". Но наш сервер написан таким образом, что операции с любыми ключами синхронизированы относительно друг друга. Если бы мы могли выполнять операции с разными ключами одновременно, то наш сервер справился бы с гораздо большей нагрузкой.

Давайте подумаем, как реализовать эту идею. Ключевое слово synchronized заставляет Java получить блокировку на объекте, которым в данном случае будет экземпляр KvService. Блокировка устанавливается при входе в метод create и снимается при возврате из метода. Синхронизация нам нужна для защиты Map. Мы используем HashMap и, если она не будет правильно синхронизирована, то внутреннее состояние HashMap может быть повреждено. Поэтому нельзя просто удалить synchronized у метода.

Однако Java предлагает здесь решение: ConcurrentHashMap. Этот класс предлагает возможность безопасного конкурентного доступа к содержимому Map. Например, в нашем случае мы хотим проверить наличие ключа. Если ключа нет, мы его добавляем, иначе возвращаем ошибку. Метод putIfAbsent атомарно проверяет наличие значения, добавляет его, в случае отсутствия, и сообщает нам, удалось ли это сделать.

ConcurrentMap обеспечивает более сильные гарантии безопасности putIfAbsent, поэтому мы можем заменить HashMap на ConcurrentHashMap и убрать synchronized:

private final ConcurrentMap<ByteBuffer, ByteBuffer> store = new ConcurrentHashMap<>();@Overridepublic void create(    CreateRequest request, StreamObserver<CreateResponse> responseObserver) {  ByteBuffer key = request.getKey().asReadOnlyByteBuffer();  ByteBuffer value = request.getValue().asReadOnlyByteBuffer();  simulateWork(WRITE_DELAY_MILLIS);  if (store.putIfAbsent(key, value) == null) {    responseObserver.onNext(CreateResponse.getDefaultInstance());    responseObserver.onCompleted();    return;  }  responseObserver.onError(Status.ALREADY_EXISTS.asRuntimeException());}

Продолжаем оптимизацию

Улучшить create было довольно просто. Сделать то же самое для retrieve и delete также сложностей не представляет. Однако метод update немного сложнее. Давайте посмотрим, что он делает:

@Overridepublic synchronized void update(    UpdateRequest request, StreamObserver<UpdateResponse> responseObserver) {  ByteBuffer key = request.getKey().asReadOnlyByteBuffer();  ByteBuffer newValue = request.getValue().asReadOnlyByteBuffer();  simulateWork(WRITE_DELAY_MILLIS);  ByteBuffer oldValue = store.get(key);  if (oldValue == null) {    responseObserver.onError(Status.NOT_FOUND.asRuntimeException());    return;  }  store.replace(key, oldValue, newValue);  responseObserver.onNext(UpdateResponse.getDefaultInstance());  responseObserver.onCompleted();}

Обновление ключа до нового значения требует двух взаимодействий со store:

1. Проверить существование ключа.

2. Изменить предыдущее значение на новое.

К сожалению, у ConcurrentMap нет прямого метода для этого. Поскольку мы можем быть не единственными, кто изменяет Map, нам нужно учитывать это. Мы прочитаем прежнее значение, но к моменту, когда мы его заменим, оно может быть уже удалено.

Чтобы справится с этой ситуацией, давайте попробуем повторить попытку, если replace не удастся выполнить. Метод replace возвращает true, если все прошло успешно. (ConcurrentMap гарантирует, что операции не повредят внутреннюю структуру, но не то, что они будут успешными!) Мы будем использовать цикл do-while:

@Overridepublic void update(    UpdateRequest request, StreamObserver<UpdateResponse> responseObserver) {  // ...  ByteBuffer oldValue;  do {    oldValue = store.get(key);    if (oldValue == null) {      responseObserver.onError(Status.NOT_FOUND.asRuntimeException());      return;    }  } while (!store.replace(key, oldValue, newValue));  responseObserver.onNext(UpdateResponse.getDefaultInstance());  responseObserver.onCompleted();}

Следует отметить, что если другой RPC изменит значение между store.get() и store.replace(), то будет ошибка. Но для нас это некритично, поэтому мы просто пробуем еще раз. После успешного сохранения нового значения сервис отправляет ответ пользователю.

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

Измеряем производительность

В прошлом посте мы модифицировали клиент, сделав его асинхронным и использовали ListenableFuture. Чтобы избежать нехватки памяти мы ограничили до 100 количество одновременно активных RPC. Как мы видим, на стороне сервера узкое место это блокировки. И поскольку мы избавились от них, то ожидаем увидеть значительное улучшение производительности. Для обработки одного RPC выполняется все та же работа, но выполняя ее параллельно, можно сделать гораздо больше. Давайте проверим, верна ли наша гипотеза:

До изменения:

$ ./gradlew installDist$ time ./build/install/kvstore/bin/kvstoreApr 16, 2018 10:38:42 AM io.grpc.examples.KvRunner runClientINFO: Did 24.067 RPCs/sreal1m0.886suser0m9.340ssys0m1.660s

После изменения:

Apr 16, 2018 10:36:48 AM io.grpc.examples.KvRunner runClientINFO: Did 2,449.8 RPCs/sreal1m0.968suser0m52.184ssys0m20.692s

Вау! Было 24 RPC в секунду, а стало 2400. И нам не пришлось менять ни API, ни клиента. Вот почему важно понимать ваш код и семантику API. Благодаря использованию особенностей сервиса ключ-значение, а именно независимости операций с различными ключами, код теперь работает намного быстрее.

Одним из примечательных артефактов этого кода является время user в результатах. Первоначальное значение было только 9 секунд, то есть процессор использовался только 9 секунд из 60 секунд. После наших изменений время увеличилось более чем в 5 раз, до 52 секунд. Причина в том, что ядра процессора использовались больше. KvServer эмулирует работу, засыпая на несколько миллисекунд. В реальном приложении он выполнял бы полезную работу, но каких-то кардинальных изменений не было. Вместо масштабирования по количеству RPC, он будет масштабироваться по количеству ядер. Таким образом, если бы у машины было 12 ядер, то можно ожидать 12-кратное улучшение. Весьма неплохо!

Больше ошибок

Если вы запустите этот код, то в логах увидите намного больше подобных сообщений:

Apr 16, 2018 10:38:40 AM io.grpc.examples.KvClient$3 onFailureINFO: Key not foundio.grpc.StatusRuntimeException: NOT_FOUND

Причина в том, что новая версия кода делает состояние гонки более вероятным. Если выполняется в 100 раз больше RPC, то вероятность коллизий обновления и удаления выше. Чтобы решить эту проблему, нам нужно будет изменить API. Следите за постами, и увидите, как это исправить.

Выводы

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

Узнать подробнее о курсе "Java Developer. Basic".

Смотреть открытый вебинар Как работает Интернет.

C апреля 2021 Cloud4Y отменил тарификацию интернет-канала пропускной способностью 100Mbps при расчёте стоимости виртуальных мощностей.

Ранее, в качестве бесплатной базовой опции, Cloud4Y предлагал интернет-канал 5Mbps.

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

Почему это важно?

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

Вы можете бесплатно протестировать облачный сервис Cloud4Y, оставив заявку на сайтe.

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

Все знают, что раньше интернет был попроще. Но часто ли вы вспоминаете, что во время его использования вся семья оставалась без телефонной связи? Помните ли встроенный в Opera баннер? Программы FlashGet и eMule? Вёрстку сайтов таблицами и фреймами? Штурмовые корабли в огне на подступах к Ориону? (Извините, увлёкся.)

Мне кажется, около 2000-го произошёл прорыв: в 90-х интернет был ещё гиковской историей, а в нулевых стал мейнстримом. Как можно сегодня ощутить времена этого прорыва? Увидеть старые сайты помогает Wayback Machine, но если делаешь это в свежем браузере через современное подключение, то собираешь лишь половину паззла. Поэтому сделал подборку из информации, ссылок и советов, которые дополнят опыт. Те, кто постарше, ощутят ностальгию, а те, кто помладше, узнают что-то новое.

Подключение

Конечно, начать надо с этих звуков:

Запустите ролик, отвлекитесь от текста и прослушайте эти полминуты целиком, прежде чем продолжать читать. Потому что в 2000-м, чтобы выйти в интернет и что-то там читать, большинству людей требовалось сначала послушать это.

Ах да, было же само понятие выйти в интернет! Сейчас так уже не говорят: мы привыкли, что он доступен по умолчанию и лишь временно пропадает, когда едешь в лифте. Но тогда было иначе:

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

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

• И главное. Оплаты домашнего интернета чаще всего была почасовая (можно было купить карточку, например, на 10 часов). И это было недешёво, так что время подключения попросту приходилось экономить. Карточки выглядели так:

^{Фото взято отсюда, там ещё много}

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

А необходимость экономить приводила к ухищрениям: в онлайне открываешь сразу несколько разных интересных текстов, сохраняешь их на диск, а потом отключаешься и уже в офлайне спокойно читаешь когда удобно. Но тогда, если при офлайн-чтении в тексте обнаруживалась интересная ссылка, то её не откроешь. Конечно, можно снова подключиться, но это же ещё раз слушать модемные скрежетания...

Кстати, а что это вообще были за звуки, которые можно принять за неизданный трек Афекса Твина? Модем пользователя звонил по телефонной линии провайдеру (кстати, не факт, что дозвонишься с первого раза), после чего звуками здоровался с оборудованием провайдера, договариваясь о деталях взаимодействия. На Хабре переводили пост по этому поводу, вот познавательная схема из него:

Штуки вроде люди сохраняли страницы на диск для чтения в офлайне через Wayback Machine не поймёшь. Поэтому, если хотите прочувствовать интернет 2000-го попробуйте убрать подальше смартфон, отключить Wi-Fi на компьютере и включать его на очень ограниченные промежутки времени. И посмотрите, как изменятся ваши паттерны поведения. Как вы начнёте записывать так, вот это надо будет погуглить.

Скорость

Только позавчера все обсуждали замедление Твиттера в России. Сообщается, что замедлили до 128 кбит/сек.

И тут получается наглядное сравнение. Сегодня такая скорость это жёсткое замедление и наказание, ужасно, когда простые картинки грузятся не сразу! А если бы вы в 2000-м году вы сказали о такой скорости, вас назвали бы буржуем. 128 кбит это уже времена ADSL, середина нулевых. У модемов, использовавших телефонные линии, пределом были 56 кбит/сек (а реальные показатели оказывались и того ниже).

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

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

Если просто открыть через Wayback Machine старые сайты, этот факт пройдёт мимо. Будешь смотреть на сайты с картинками и думать, что все их тогда так и видели. Нет, далеко не все.

Как ощутить тогдашние скорости, если сегодня даже замедленный твиттер гораздо быстрее? Может помочь инструмент из Chrome DevTools. Откройте там вкладку Network. В ней есть возможность целенаправленно троттлить скорость:

По умолчанию представлены несколько пресетов вроде "Fast 3G", но даже "Slow 3G" слишком быстрый. Поэтому создайте собственный пресет в пределах 56 кбит. И попробуйте с ним открыть, например, новостной сайт (то есть чтобы текст + картинки, без хитрых интерфейсов). Получите интересные впечатления.

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

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

Браузеры

До этого момента нас заботило то, что происходило внутри окна браузера. Но само это окно тоже имеет значение. Мне кажется, мы стали забывать некоторые вещи:

• Сегодня кажется само собой разумеющимся, что браузер бесплатный софт. Но так было не всегда. Netscape был платным для корпоративного использования, а Opera предлагала пользователям либо заплатить, либо получить встроенный баннер прямо в интерфейсе браузера. И одна из причин победы Internet Explorer на том витке истории его бесплатность. А одна из причин тогдашнего успеха Opera в России тут использовали взломанную Оперу с отключенным баннером.

• Сегодня кажется само собой разумеющимся, что у браузера есть вкладки. Но так было не всегда. В Internet Explorer они появились только в 2006 году. Если вы сейчас посмотрели на свои сто открытых вкладок и ужаснулись мысли это ж было бы сто отдельных окон, можно отчасти успокоить: во времена интернет медленный, выходят туда ненадолго, оперативки мало никто не держал открытыми сто сайтов. Паттерны поведения и здесь изменились.

• Сегодня кажется само собой разумеющимся, что браузер сразу открывает страницы в читаемом виде. Но так было не всегда. До повсеместного распространения юникода русскоговорящие пользователи сталкивались с тем, что сайт или письмо отображаются в неправильной кодировке (в народе это называли крякозябры). Поэтому популярной функцией в меню браузеров был выбор кодировки, а на сайте Артемия Лебедева до сих пор доступен Декодер, автоматически исправляющий кодировку произвольного текста.

Как сегодня ощутить старые браузеры без визита в музей ретро-компьютеров? Тут отчасти помогает проект OldWeb.Today, эмулирующий ряд этих браузеров. Окно браузера демонстрируется ещё и в интерфейсе своей ОС, что способствует погружению. Правда, всё глючит и тормозит (не только загрузка страниц, открыть новое окно тоже небыстрый процесс). Но это в целом тоже работает на атмосферу вспомним, что в 2000-м компьютеры были нерасторопными по нынешним меркам.

Большинство современных сайтов там либо разъедется по швам, либо вообще не откроется: веб изменился и использует теперь много вещей, которые старые браузеры просто не поддерживали. Если интересна эволюция веб-стандартов, можно разбираться, где именно всё разваливается.

А если хочется прочувствовать интернет 2000-го, то открывать в этих браузерах надо не современные сайты, а олдскульный контент (о нём ниже).

Кстати, видите справа внизу в статусбаре Internet Explorer синюю полоску загрузки страницы? В те медленные времена люди с придыханием следили за тем, как она ползёт. Правда, она всё равно была малоинформативной: могла долго пробыть в самом начале, а потом резко скакнуть.

А ещё, открыв на современном ретиновом экране одну и ту же страницу в старом браузере и новом, легко заметить разницу типографики. Казалось бы, просто тексты всегда выглядели одинаково но нет, в буквах разница тоже ощутима.

Веб-дизайн

Послушав модемные трели и запустив браузер без вкладок, можно было наконец узреть сайты. Какими они были и где теперь такое увидеть? Главный помощник по вопросу где сокровищница Wayback Machine с архивами громадной части интернета. А по вопросу какими распишу здесь главные тренды:

1. Тексты

Поскольку интернет был медленным и не особо интерактивным (никакого там обновления страницы на лету), в него шли за текстами: новостями, письмами, рефератами.

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

Текстом тогда решались и задачи, для которых сейчас часто используют другие форматы. Для социализации вместо всяких инстаграмов с клабхаусами можно было использовать форумы и чаты. За юмором вместо Тиктока и мем-пабликов шли на сайт anekdot.ru (кстати, он жив и не сильно изменился). И даже порно многие тогда потребляли в виде рассказов на сайте Стульчик.нет (а то с этими JPG-файлами долго ждать: они же сверху вниз загружаются, а самое интересное внизу).

2. Минимализм

Если всё начиналось с текстов, неудивительно, что дизайн зачастую был предельно аскетичен: чёрные символы с синими ссылками на белом фоне. Сейчас сайты вроде Motherfucking Website делают только как ироничный аргумент в пользу легковесных подходов. В 2000-м такой дизайн хоть уже и не был пределом мечтаний (Артемий Лебедев вовсю демонстрировал, что можно иначе), но никого не смущал.

Главная онлайн-библиотека того времени lib.ru в 2021-м выглядит почти так же, как десятилетия назад так что можете даже без Wayback Machine сделать выводы по ней.

3. Пестрота

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

Какие средства для этого были? Гифки: пусть на главной странице куча всего двигается! Бегущая строка: пусть даже текст на месте не стоит! Разные цвета и шрифты: чем больше, тем лучше! Музыка: MP3 были слишком тяжёлыми, а вот писклявый MIDI-формат подходил. То есть можно было, зайдя на чью-то страницу, быть атакованным в глаза и уши одновременно.

В фильме Капитан Марвел (2019) действие происходит в 90-х, и к его выходу сделали сайт, иронично воссоздающий такую эстетику. По-моему, справились прекрасно. Поэтому в качестве примера ссылаюсь не на реальный сайт из 2000-го (уже не вспомню адреса таких), а на эту недавнюю стилизацию, она даёт близкое к реальности впечатление. Счётчик просмотров, гостевая книга, шрифт Comic Sans да-да, это всё было.

4. Золотая середина

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

Поразительно, но спустя 25 лет после выхода фильма его сайт всё ещё доступен, так что увидеть легко. Что мы можем увидеть там показательного для тех лет?

• Компромисс между текстами и гифками: элементами навигации служат статичные картинки.

• Вёрстку таблицами и фреймами. Тогда миром ещё не завладели div, и всё возможное обычно делали через table. А ещё порой делили фреймами окно браузера на части и подгружали в них разные HTML-страницы (в одной могло быть меню, в другой основной контент) на этом сайте они тоже присутствуют.

• Простой HTML-код без всех этих ваших реактов. В те времена, нажив view page source на сайте, даже не слишком опытный человек мог разбираться в происходящем. Можно было учиться делать сайты, ходя по разным и смотря, как всё сделано у них.

• Во многих разделах сайта для навигации используется картинка, кликая по разным участкам которой, попадаешь на разные страницы. Это модный тогда изыск: интереснее простых текстовых ссылок, напоминает навигацию в adventure-играх. На таком основан например, сайт city.cyberpunk.ru, который тоже жив спустя все эти годы там это очень кстати, киберпанк же про киберпространство, и в каком-то смысле оно и воплощалось, захватывая дух.

Контекст

Ранние сайты не существовали в пустоте что тогда происходило вокруг них? И в смысле сетевых штук (не всё, что требует подключения, происходит в браузере), и в офлайне?

Например, что было со скачиванием контента вне браузера? Конечно, видео для 2000-го ещё было слишком тяжёлый, а вот с музыкой как раз разворачивался экшен. Первый популярный peer-2-peer-сервис Napster набирал обороты, Metallica подала на него в суд, и человечество чесало голову, пытаясь сформулировать позицию по онлайн-пиратству.

Конкретно Napster из-за иска был закрыт, но вслед за ним появился Soulseek, а в 2002-м eMule так что ещё до расцвета торрентов люди активно скачивали файлы друг у друга. Конкуренцию таким сервисам составляли локальные сети и FTP-сервера с загрузкой по прямой ссылке.

Когда по прямой ссылке скачивали в браузере, был нюанс. Модемная связь была не самой надёжной и в любой момент могла прерваться. И при дисконнекте требовалось перекачать файл заново. На медленном интернете это было больно. Этому посвящена популярная серия Масяни. Кстати, Масяня тоже важный феномен ранних нулевых: когда обычное видео ещё было слишком тяжёлым для интернета, на помощь пришла Flash-анимация, где выпуск мультика мог весить около мегабайта.

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

А что тем временем происходило в офлайне? Поскольку люди всё чаще замечали интернет и осмысляли новое явление, всё чаще возникали и офлайновые штуки, связанные с этим. Кажется, точкой всенародного единства стал суперхит Ленинград WWW (2002), а за годы до него были более локальные штуки например, выходил журнал Мир Интернет. То есть вдумайтесь: бумажное издание, где на печатных страницах рассказывали о том, что происходит в интернете. Сегодня звучит странно если это издание для людей, которым важен интернет, зачем ему физическая форма? Но тогда в этом была логика: например, бумажное издание тогда можно было почитать в метро, не то что сайты.

Статьи выкладывали и на сайт этого журнала iworld.ru, так что с помощью Wayback Machine можно ознакомиться с чаяниями того времени. Например, что с платёжными системами в интернете всё грустно. Мол, какие-то западные уже появились, но они хотят данные кредитной карточки, а откуда ж у обычного россиянина такая карточка?

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

Или вот заголовки из женского мартовского номера 2000 года, когда в интернете можно найти рецепты ещё было значимым событием:

Конечно, для атмосферы было бы клёво не только почитать тексты, но и увидеть сканы хотя бы одного номера целиком. К сожалению, они вроде бы практически не сохранились. Издательство Питер активно присутствует на Хабре, поэтому обращусь: @piter, может, поделитесь архивами?

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

А я закончу минуткой рекламы. Во-первых, 27 марта мы проводим бесплатный онлайн-фестиваль TechTrain там будет несколько докладов для самых разных айтишников.

А во-вторых, TechTrain станет разогревом перед нашим новым конференционным сезоном. Если старые сайты интересны вам, потому что вы фронтендер вам будет интересно на HolyJS. А кроме этого, проведём мероприятия по Java, .NET, тестированию, мобильной разработке увидеть все эти пять можно на общем сайте.

Многие могут рассказать такую историю :
- Алло, техподдержка провайдера? У меня плохо открывается сайт aaaaaa.com.
- С нашей стороны пули вылетели, проблема в мишени у сайта - пишите туда.

- Привет. Это сайт aaaaaa.com? У меня плохо открывается ваш сайт.
- У нас всё хорошо, пишите провайдеру.

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

Disclaimer : автор знает, что

1. Traceroute не всегда покажет проблемы, что маршруты больше про BGP и AS-PATH.

2. Автор в курсе про пиринг, асимметрию, MPLS, BGP Communities и что килобайт это 1024 байта.

3. Маршрут туда и обратно - два разных маршрута и traceroute разницы не покажет.

4. Матерые сетевики могут найти очень много неточностей. Эти неточности допущены специально, для облегчения понимания материала не-сетевиками. :D

За чей счет банкет?

Интернет в России гораздо дешевле интернета, например в Америке или в Германии. Дешевле в несколько раз. Vodafone Kabel в Германии стоит 45 евро в месяц за 500 мегабит. Это 4000 рублей на момент написания текста. В России, например, у РосТелеком я плачу 1050 рублей в месяц за оптику, по которой приходит 600 мегабит.

Так как в России не производится коммутационное оборудование, то казалось бы - за чей счет банкет? Ведь железо стоит столько же сколько и в Германии. Попробуем в этом разобраться.

Путь от пользователя до сервера выглядит, обычно, следующим образом:

Городской роутер провайдера.

Я плачу 1050 рублей в месяц за 600 мегабит. На телеком-рынке стоимость 1 мегабита составляет от 6 до 30 рублей в зависимости от города. Это значит, что 600 мегабит интернета стоит от 3600 рублей. Как же мне РосТелеком продает всего за 1050? Этому есть несколько причин. Одна из ключевых он продает не только мне. Пользователь обычно не использует интернет на полную катушку 24х7. Поэтому, в тарифе написано - ДО 600 мегабит. С точки зрения математики это выглядит следующим образом:

В городском роутере есть 10 гигабит интернета. Этот интернет продали 500 пользователям. При этом, каждому продали по 1 гигабиту. И того продали 500 гигабит. А всего 10. Так как не все пользователи и не всегда качают фильмы с торрентов, то и проблем обычно нет.Это называется oversell.

Вечер пятницы.

В пятницу вечером проблемы, впрочем, могут начаться. В 17:00 школьники приходят домой с улицы, родители приходят домой с работы. Все садятся за компьютеры и начинают смотреть YouTube/Тикток и так далее. В этот момент как раз и получается, что 10 гигабит на город перестает хватать.

Для пользователя это выражается в следующем:

1. Ухудшается пинг (иногда в несколько раз).

2. Падает скорость.

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

Однако, если вы пользуетесь удаленным рабочим столом или ssh - разница ощущается. А в сервисах типа GFN.RU 4мс и 20мс input-лага это не только гораздо хуже картинка, но и разница между жизнью и смертью в Rainbow Six Siege.

Если со скоростью всё понятно, то на пинге стоит остановиться отдельно. Трафик в интернете движется со скоростью света. Независимо от загрузки магистрали, расстояние между пользователем и сайтом не поменялось почему же пинги стали хуже?

На сетевом оборудовании могут использоваться очереди (PBQ/QoS). Если пакет ушел в сеть, а канал загружен, то он может попасть в очередь и будет там болтаться либо пока не устареет, либо пока у него не появится возможность попасть в канал (пока не рассосется более приоритетный трафик).

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

Тем не менее, не стоит беспокоиться TCP/IP (который используется при взаимодействии с сайтами) протокол с подтверждением доставки. Если что-то по пути потеряется, то потеря будет отправлена еще раз. Для пользователя это будет выглядеть как снижение скорости, которое он не заметит.

UDP (используется обычно для видео/голоса) более быстрый, но без контроля доставки, данные и правда могут потеряться по пути. Эти потери обслуживаются на более высоком уровне, по сравнению с TCP. В стриминговых сервисах потери UDP-пакетов приводят к снижению битрейта до тех пор, пока потери не прекратятся.

Стоит так же обратить внимание, что:

1. Скорость у пользователя ДО 600 мегабит.

2. Пинг в договоре не прописывается.

3. Сайт может отдавать пользователю 20 мегабит вместо 600 даже при хорошей скорости от пользователя до сайта. Например, с помощью https://www.nginx.com/blog/dynamic-bandwidth-limits-nginx-plus-key-value-store/. И чтоб защититься от DDoS и краулинга.

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

Вывод в обычной ситуации, доказать провайдеру, что между вами и сайтом проблема где-то у провайдера практически невозможно.

Маршруты в большом интернете.

После того, как трафик прошел городской роутер и дошел до магистрального роутера, он попадает в интернет.

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

BGP

Для выбора по какому маршруту отправить трафик, используется протокол BGP. С его помощью определяется количество узлов между двумя точками. Трафик может быть направлен по маршруту с меньшим количеством узлов (самый короткий AS-PATH). Однако, данный метод не учитывает такой метрики, как расстояние между узлами. Вполне может произойти, и происходит, что между двумя точками есть, например, два маршрута:

1. AS123 <--1000km--> AS456 <--50км--> AS888

2. AS123 <--5000км--> AS888

Как видим, ASPATH у второго маршрута короче (на нем меньше промежуточных точек) и трафик вполне может пойти по нему. Хотя, напомню, скорость света указывает на то, что первый маршрут будет быстрее.

Загрузка канала и экономика.

Обратимся к первой картинке. Видим, что у провайдера есть 3 магистральных канала:

Оранжевый, синий и зеленый.

Синий самый жирный. Например, 8 гигабит. Оранжевый чуть менее жирный. Например, 4 гигабита. И зеленый самый тонкий: 2 гигабита.

При этом, синий самый короткий, оранжевый чуть длиннее и зеленый самый длинный.

Казалось бы - всегда используй жирный и короткий, не ходи тонкими и длинными. Но, в реальности, это происходит не всегда.

Канал между двумя точками всегда стоит денег. С точки зрения экономики это выглядит следующим образом:

1. Арендуется оптическое волокно. В зависимости от ДЦ и жадности владельца оптики волокно стоит по-разному. Иногда, ОЧЕНЬ по-разному. Если на входе в ДЦ есть оптика только от одного владельца, которому, в том числе принадлежит ДЦ, то цена может быть сильно негуманной. Альтернатив-то нет.

2. По этому волокну организовывается сетевая связь между двумя точками.

3. Приобретается предоплаченная полоса трафика. Например, 3 гигабита.

4. Договариваются о цене на Берсты: когда вместо оплаченных 3 гигабит по каким-то причинам наливается 5 гигабит. Обычно, берсты стоят дороже предоплаченной полосы и их стараются не использовать.

Берст (burst): кратковременное (или не кратковременное) превышение. В данном случае предоплаченной полосы. Провайдер в канале 10 гигабит купил всего 1 гигабит. Он может на самом деле использовать все десять. Всё, что выше купленого - называется берстом или превышением.

95 персентиль (95th percentile, MRTG95). Напоминает медиану (50th percentile). Как считается : берется отрезок времени, например 100 секунд. Разбивается на 100 отрезков по 1 секунде. В каждом отрезке определяется максимальная загрузка канала. Отбрасывается 5 отрезков с самой большой загрузкой. Из оставшихся отрезков находят отрезок с самой высокой загрузкой - это и будет 95 персентиль.

Нюанс с берстами. Загрузка канала считается по 95 персентилям. Это значит, что если в течение месяца канал более чем 32 часа загружен на 10 гигабит, даже если выкуплен 1 гигабит, и средняя загрузка 0.5 гигабит, то арендатору приходит счет за 10 гигабит. Поэтому, арендаторы стараются избегать берстов и загружать все свои каналы равномерно.

Всё вышесказанное напрямую влияет как именно ваш трафик пойдет от вас до сервера:

1. Во-первых, по самому дешевому каналу.

2. Во-вторых по тому, где есть неиспользованная предоплаченная полоса.

3. В-третьих, если какой-то канал мигнул бёрстами, то их потом могут добивать: залил в какой-то резервный канал 10 гигабит в результате аварии на основном канале - значит, до конца месяца можно спокойно в резервный канал лить все 10 гигабит. Счет-то все равно уже придет за 10 гигабит.

4. И уже на последнем месте будет учитываться скорость и комфорт пользователя.

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

В интерактивных стриминг-сервисах, увы, это чувствуется инпут-лаг, рассыпающаяся картинка.

А еще, магистральное оборудование, может и не понимать, что бюджет канала исчерпан. Если маршруты говорят, что эти 12 гигабит стоит заливать в канал, в котором всего 10 гигабит полосы, то туда Nexus и попробует залить.

Всё вышесказанное говорит о том, что: когда вечером все начинают смотреть YouTube, то может как падать скорость, так и появляться потери пакетов. А трафик может ходить очень странными путями.

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

Хороший товар, не надо брать. Этой фразой, кажется, можно охарактеризовать весь спектр претензий к одном маленькому, но важному нововведению Яндекс.Маркета отзывам, написанным искусственным интеллектом. Хотя лучше будет звучать классическое "хотели как лучше". Мы, конечно, надеемся, что со временем ИИ станет работать лучше и яснее изъясняться. Но это со временем, а пока пользователи и продавцы не в восторге. И вот почему.

Что это за умные отзывы?

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

Замысле был прекрасный. Чтобы покупателям не приходилось рыться среди тысячи отзывов, искусственному интеллекту от Яндекс было поручено вычитывать их и обобщать в одну короткую карточку. Искусственный интеллект, якобы, изучает все мнения о товаре, оставленные реальными покупателям и пишет усредненный обзор пересказывает наиболее частые плюсы и минусы. Фактически, ИИ упрощает для покупателям жизнь они могут не перечитывать сотни комментариев в карточках товаров. Если хотите сами взглянуть на нововведение, то "умные" отзывы доступны сразу под фото товара на Маркете.

По сути, это такой словесный рейтинг как и бальная оценка быстро смотришь и все понимаешь о товаре. В итоге же все звучит как краткий пересказ "Войны и мир" от заядлого двоечника. Возможно, Яндекс и не двоечник, а только начинает учиться. Сегодня на Маркете уже оставлено 14 миллионов отзывов из 500 миллионов слов. При этом "умные" отзывы можно встретить только под 50 тысячами товаров. Но надо ли?

А у тебя не слипнется?

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

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

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

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

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

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

Закон о праве на забвение, по которому любой гражданин имеет право требовать скрыть в поисковой выдаче ложную или устаревшую информацию о себе, действует в России с 2016 года. Но действительно ли реально почистить за собой все интернет-следы, и не пора ли поменять практику применения закона?

Каждый из нас, регистрируясь на тех или иных сайтах, социальных сетях или агрегаторах, совершая покупки в интернет-магазинах, ежедневно оставляет во всемирной сети сотни и тысячи байтов своих персональных данных - имя, телефон, фотографии, паспортные данные, номера ИНН, СНИЛС и т.п. И в итоге о человеке можно создать целое досье, причем без его желания. Налицо ситуация, об опасности которой на днях говорил президент РФ Владимир Путин, выступая с онлайн-обращением на форуме Давосская повестка дня 2021: Все более значимую роль в жизни общества стали играть современные технологические и прежде всего цифровые гиганты по отдельным направлениям они де-факто конкурируют с государствами. Их аудитория исчисляется миллиардами пользователей, которые проводят в рамках этих экосистем значительную часть своей жизни у общества возникает вопрос: насколько такой монополизм соответствует именно общественным интересам? Где грань между успешным глобальным бизнесом, востребованными услугами и сервисами, консолидацией больших данных и попытками грубо, по своему усмотрению управлять обществом, подменять легитимные демократические институты, по сути, узурпировать или ограничивать естественное право человека самому решать, как жить, что выбирать, какую позицию свободно высказывать?

Как справедливо отмечает кандидат юридических наук Е.М. Подрабинок в своей статье Особенности осуществления права на забвение в эпоху цифровизации общества, появление и осуществление права на забвение (right to be forgotten) стало возможным только с возникновением и распространением интернета, поскольку получение информации практически любого рода стало простым и легкодоступным. При этом далеко не вся информация о человеке в сети может являться правдивой или актуальной на определенный момент времени, и индивид должен иметь право потребовать ее удаления, если сочтет это необходимым для себя. Для этого он может обратиться к оператору поисковой системы и потребовать ограничения или запрета выдачи подобной информации третьим лицам. Собственно, в этом и состоит юридическая суть права на забвение.

Впервые о нем заговорили в мае 2014 года, когда Европейский суд по правам человека, рассмотрев дело Марио Контеха Гонсалеса против Google, в итоге обязал поисковик редактировать определенные результаты поиска по запросу частных лиц. При принятии решения ЕСПЧ сослался на действовавшую в то время Директиву 95/46/EC о защите персональных данных, расценив сбор и хранение информации поисковыми интернет-системами как ее обработку.

В России институт права на забвение появился пять лет назад 1 января 2016 года, когда вступил в силу Федеральный закон от 13.07.2015 г. 264-ФЗ

О внесении изменений в Федеральный закон Об информации, информационных технологиях и о защите информации и статьи 29 и 402 Гражданского процессуального кодекса Российской Федерации. Согласно п. 1 ст. 10.3 Закона об информации человек может предъявить требования об удалении тех или иных ссылок о себе при наличии следующих оснований: 1) информация распространяется с нарушением законодательства РФ; 2) информация является недостоверной; 3) информация является неактуальной; 4) информация является утратившей значение для заявителя в силу последующих событий или действий заявителя.

К недостаткам принятого закона эксперты, в частности, относят то, что закон 264-ФЗ не вводит четких и понятных критериев актуальности или неактуальности информации, об удалении которой просит заявитель, а также ни слова не говорит о том, является ли или нет такая информация общественно значимой. Например, из апелляционного определения Мосгорсуда от 22 мая 2017 года по делу 33-14853/2017 следует, что поисковая система (в данном конкретном случае Яндекс) не может нести ответственность за распространение информации, если оператор не знал о незаконности такого распространения. Кроме того, отметил суд, оператор поисковика не отвечает за размещение информации третьими лицами, поскольку основная его задача предоставить услуги по поиску информации, а не ее распространению. Наконец, по мнению апелляционной инстанции, что при подаче заявления в адрес ООО Яндекс, истец сам должен был указать, какая информация о нем на обжалуемой в заявлении интернет-странице распространяется с нарушением законодательства (помимо необходимости доказывания недостоверности и неактуальности такой информации).

В целом нужно отметить, что в Европе и России, несмотря на схожесть подходов к праву на забвение, все же существуют достаточно серьезные различия в этом плане. В частности, в Евросоюзе данные о запросах граждан можно раскрывать, если они не содержат их персональных данных скажем, если речь идет о предоставлении статистической информации (преамбула 65 GDPR общеевропейского регламента о защите данных). В России же операторам поисковых систем в принципе запрещено раскрывать информацию о сделанных запросах, кого бы и чего бы они ни касались, если иное прямо не установлено действующим законодательством (п.8 ст. 10.3 Федерального закона Об информации, информационных технологиях и о защите информации от 27.07.2006 N 149-ФЗ).

Кроме того, ЕС устанавливает общее исключение из права на забвение, в первую очередь если дело касается выполнения задачи, осуществляемой в публичном интересе (т.е. когда субъекты персональных данных, которые необходимо удалить, играют заметную роль в жизни общества политики, звезды шоу-бизнеса, олигархи, и т.д.), или ввиду публичного интереса в области здравоохранения, или же в целях архивирования в публичном интересе, в целях научных или исторических исследований или в статистических целях (параграф 3 статьи 17 GDPR), в то время как в РФ это исключение является частным (оператор поисковика, согласно п.1 все той же статьи 10.3 закона 149-ФЗ, не имеет права удалять только лишь ссылки о преступлениях, по которым не истекли сроки давности, или по которым с гражданина не снята или не погашена судимость).

Возникает, как пишет Е.М. Подрабинок, и вопрос о том, как соотносится с правом на забвение информация, которая непосредственно на момент ее размещения в сети была и достоверной, и законной, и не нарушающей чьих-либо прав: Подобные вопросы могут возникнуть в связи со множеством произошедших действий или событий. А аналогичных примеров может быть бесчисленное множество. В связи с этим в юридической литературе поднимается вопрос о том, что право на забвение дает возможность лицам фактически переписывать, искажать историю. К схожим выводам пришел и все тот же Мосгорсуд, но уже в другом своем апелляционном определении по делу 33-10390/2017 от 20 марта 2017 года. В своем решении судьи, в частности, указали, что оператор поисковой системы не вправе безосновательно и бездоказательно по произвольному требованию гражданина, который может преследовать различные цели, в том числе для сокрытия находящейся в свободном доступе в сети Интернет достоверной и объективной информации о себе, прекращать поисковую выдачу ссылок на такую информацию, поскольку в противном случае будут нарушены указанные конституционные принципы, а деятельность оператора поисковой системы потеряет всякий смысл.

И действительно, удаление оператором той или иной поисковой системы таких ссылок на информацию, которые имеют явный общественный интерес и общественную значимость, знаменовало бы собой явное отступление от конституционного принципа гласности и свободы слова. Любой гражданин мог бы затруднить доступ третьих лиц к абсолютно любого рода информации о себе, на недопустимость чего обращает внимание, в том числе, и Конституционный Суд Российской Федерации в своем Постановлении от 09.07.2013 N 18-П.

Так можно ли удалить о себе любую информацию из интернета, ликвидировав, таким образом, свой цифровой след? До недавнего времени, если исходить из непосредственного толкования норм закона 264-ФЗ, можно было сказать, что определенные ограничения в этом отношении все же существовали. Но вот в начале декабря 2020 года, Российская газета сообщила о том, что Госдума приняла в первом чтении законопроект, который позволяет пользователям самостоятельно распоряжаться своими персональными данными. В частности, будет создана специальная система Роскомнадзора, с помощью которой можно будет как отзывать согласие на размещение своих персональных данных в интернете (образно говоря, убирать галочку в соответствующем пользовательском соглашении), так и требовать их удаления и/или опровержения.

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

Пока обсуждается, будет ли предлагаемая система каким-то образом охватывать согласия, данные до вступления закона в силу, сообщили в Роскомнадзоре. Возможно, как заявил Антон Горелкин, владельцев интернет-ресурсов, в том числе социальных сетей, попросят пересмотреть и переподписать уже заключенные пользовательские соглашения. Кроме того, известно, что действие законопроекта не будет распространяться на информацию, которая предоставляется государственным и муниципальным органам (включая полицию, суды и прокуратуру), а также банкам и страховым компаниям. Однако уже сейчас представляется, что подобное расширение права на забвение может повлечь за собой не расширение права на защиту частной жизни человека, а угрозу для прозрачности и открытости информационной системы общества.

И тогда перед нами вновь встанет извечный вопрос: должна ли свобода каждого отдельного индивида быть безусловным приматом его юридического статуса? Или ей все-таки долженствует реально заканчиваться там, где начинается свобода другого человека? Ответ, как представляется, уже не за горами.