Игра в безопасность — она такая. Делаешь юзерам удобнее — становится уязвимым для большых вариантов атаки, делаешь безопасным — либо пользователи взвоют, либо просто мало кто будет пользоваться твоим продуктом.
С моей точки зрения клиенты маха — такие же, как и у других клиентов других мессенджеров. Все могут допускать ошибки и ставить удобство в ущерб безопасности. Но нужно не забывать, что в случае с мах, дьявол кроется на серверной стороне.
Да. Токен вполне может быть и рандомной строкой. Сервер сам решает когда токен протух. Тогда интересно, сколько времени проживёт токен. Я бы не давал много времени токенам, что лежат в localStorage. Сам таким пользуюсь, время жизни - пол часа. Если просто украдут, то время на совершение действий не больше этого времени. Дальше надо снова токен добывать, т.е. нужно контролировать устройство всё время. Эта заметка навела меня на мысль переделать всё на httpOnly cookies. Раньше не знал как сделать, а сейчас нашёл.
Если бы был jwt, из него можно было бы извлечь информацию, но тоже не всегда (иногда контент шиыруют, например, ЕСИА). А сервер может проверить валидность такого токена по закрытому ключу. Здесь не так.
Какая-то бредовая статья. У людей стоит старый маршрутизатор с WiFi на 2,4ГГц. Его всё устраивает. это его проблемы. Диапазон забит? Так он пользуется и не собирается ничего менять.
Вот за что стоит реально беспокоиться, так это за то, что устаревшие устройства могут быть подключены к ботнетам. Вот об этом надо думать. Куча устаревшего железа на которое нормальной пошивки не поставить.
Это немного не так работает. Обычно выдаётся короткоживующий токен, очень часто JWT, где прописан срок протухания. Пока он жив, ты можешь обращаться к сервису. Срок его жизни может быть и пол часа и час. Когда токен протухает, в ход идёт рефреш токен, который можно хранить уже в Cookie, которые недоступны из JS, а значит его через JS уже не угнать, только лезть в кишки баузера, а потом также через кишки вставлять эту cookie в другой браузер. Так что угон этой cookie даст тебе доступ к сайту максимум на час, если, конечно, разработчики не идиоты и не выставили время жизни access токена на большой срок. Через час токен протухнет и старый браузер обновит его, а новый браузер обломается, поэтому что у него нет refresh токена.
Жаль автор не глянул хотя бы через jwt.io что там внутри токена. Если это был обычный JWT, то там должна быть информация, когда токен протухает. Если время протухания далеко в будущем, то это точно будет фейл.
Вот паникёров развелось. Будем смотреть как дальше будет всё развиваться. Это вполне разумная реакция Let’s Encrypt на то, что ими воспользовались для того, чтобы заменить ранее отозванный сертификат от другой компании, которая отозвала его по причине санкций.
Не согласен с автором статьи по многим вещам. Например:
cli. Никто не заставляет его использовать. Речь идёт о том, что cli это очень эффективный инструмент. На столько эффективны, что сейчас даже M$ внедряет GNU утилиты в свой Windows. Нативно. Не через WSL. Да и им пришлось полностью переделывать свой cli. В современных версиях есть как его старая версия со времён DOS, в которой толком ничего сделать нельзя, так и PowerShell. cli - это не достоинство Linux - это его фича, доступная из коробки. Если вы писали скрипты под Windows, вы её оцените. Для всех остальных она не нужна. Максимум, вбить уже готовые команды, как это делали люди и в cmd.
vim? Да какой vim? Вы давно ставили какой-нибудь простенький Linux. Из коробки там есть nano, чаще всего. Во FreeBSD из покон веков был ee (хотя FreeBSD не Linux, но несведущие люди не поймут разницы). Наличие vi или vim - это скорее везение. Но его легко поставить, если вы уже зашли в командную строку.
Flatpak/snap хороши для GUI приложений. Когда нужно поставить что-то огромное и не хочется захламлять систему. Я обычно сначала смотрю наличие программы в репозиториях, и если там нет нужной мне версии или нет совсем, тогда использую flatpak. Ну или просто посмотреть, что за программа. Что-то на уровне скачать инсталлятор для Windows и поставить, только без высокого шанса вообще убить систему или заразить какой-нибудь заразой. Как выбирать откуда ставить? KDE Plasma был упомянут. Там есть неплохой для обычных юзеров магазин приложений. Он там позволяет выбирать источник установки. Для примера, если набрать в поиске Blender, то у тебя будет аж 3 варианта, откуда поставить. Чисто для потребителя вообще не важно. Он во всех случаях получит свою программу. А если вы разбираетесь, то вы поймёте, что там можно поставить из репозиториев Fedora Linux, Flathub или собственный репозиторий Fedora с flatpak пакетами.
А вот на что действительно не указал автор, что я сейчас вспомню:
Детская болезнь с переключением раскладок. Очень долго преследует дистрибутивы и нужно исправлять. Что я имею в виду. Ты выбираешь русскую раскладку и, возможно даже кнопки для переключения раскладки, но в самой системе остаёшься только со вводом кириллицей. Это приходится лечить через консоль. Недавно с подобным столкнулся в NixOS. Довольно дружелюбный установщик, но видимо, не выполнил какого-то ритуала обязательного при установке раскладки русской. Вероятно чинится, но я с одной попытки попал именно в эту ситуацию.
Проприетарщина. Увы. Проприетарщина - враг OpenSource. Ты вполне можешь поставить вполне себе дружелюбный к пользователям дистрибутив Fedora, а потом наслаждаться слайдшоу или вообще отсутствием картинки при воспроизведении видео. А вся беда в долбанных лицензиях. Поэтому приходится чинить волшебными командами в cli, после чего всё начинает работать нормально. В суть команд не нужно вникать, но приходится это делать. С другой стороны, чтобы у вас на компьютере заработал тот же драйвер Nvidia в Windows и Ubuntu нужно было тоже поплясать с бубном. В Windows поискать нужный исполняемый файл с установщиком на сайте производителя, в Ubuntu немного поклацать в менюшки (может сейчас и не так, не проверял, как не проверял и на Fedora). В Gentoo вообще часто приходится создавать специальные файлы через cli, возможно даже с правильным содержимым, чтобы поставить некоторые пакеты. Но это не дистрибутив для новичков, поэтому ничего сложного, для тех кто поставил Gentoo. В целом, любые лицензионные ограничения зло и заставляют OpenSource делать всё сложнее, чем могло бы быть.
Часто Linux представляют так, что это такая штука, которая работает даже на тапке. А потом новички ставят это на свой компьютер старый отцовский из 2005 года и плюются, что всё глючит и невозможно пользоваться. Ли берут Raspberry Pi 4 с 1 гигабайтом оперативки… или вообще Zero. В результате этого сравнения, их комп с Windows 11 на их современном Intel с 32 гигами оперативки работает на голову выше Linux на RPi Zero…
Даже читать не стал. Это что-то из прошлого тысячелетия. Магнитофон после 2000 года использовал в основном как усилитель для ПК.
Чисто на своём детском опыте смотрю. Кассеты были для меня интересны больше тем, чтобы там хранить игры и программы для ZX-Spectrum. Да, поскольку сам писал эти кассеты, то я и головку подстраивал и кассету сравнивал. И вот кассеты на базе оксида железа были гораздо хуже, чем на основе оксида хрома. И даже сам магнитофон имел соответствующий переключатель, чтобы правильные уровни выставлять для записи, как минимум. Она основе оксида хрома кассеты, конечно, стоили дороже. Но когда ты записываешь то, что не хочешь потерять, то стоило переплачивать. Да и приятнее лично мне было слушать музыку с кассеты на «хроме», а не на «железе». Но это уже субъективщина.
Опытные разработчики это понимают. Но это не понимает руководство. У них джун написал код за 3 часа, что делает нормальный разработчик неделю. А это высокий KPI.
Прямо в точку. Если минимально погуглить, то можно прямо тут же на Хабре найти статью о том, что был представлен процессор Иртыш. И там чёрным по белому написано, что он на базе той самой китайской архитектуры будет сделан… Но «чукча не читатель, чукча писатель».
Некоторые до сих пор считают, что дополнительные 20 байт заголовка IPv6-пакета приводят к значительным потерям полосы пропускания, более высокой загрузке процессора и другим проблемам.
Теория? Да кому она нужна. Да, длина выросла в 2 раза. Но при этом длина адреса источника и места назначения увеличилась в 4 раза. Чтобы это компенсировать, в протоколе введены изменения, например такие, как отсутствие необходимости фрагментации пакетов. Нужную длину фрагментов подбирает источник пакета. Длину пакетов сделали фиксированной, так что теперь большинство узлов в сети могут упростить обработку. Не нужно проверять и корректировать контрольную сумму пакета, как это было в IPv4, всё равно контроль целостности ведётся на более высоких уровнях. Также в IPv6 нет необходимости в NAT. В конце концов, когда проектировали IPv6 уже знали обо всех проблемах и особенностях IPv4. IPv6 - это работа над ошибками IPv4.
Да. Проблема именно в сливе данных VK. Да ещё каких данных! Множество избыточных данных, которые я бы назвал персональными данными, например, данных о том, с каких IP вы выходите в интернет. Это позволит эффективно блокировать интернет по конкретным спискам адресов. Зарубежные сервисы вряд ли занимаются такой аналитикой и, тем более, не будут так взаимодействовать с государственными органами в РФ.
А ещё с github большая подлянка в том, что он не работает через IPv6 напрямую. Ему нужны костыли. Т.е. ты хочешь развернуть свой проект где-то в облаке, но до необходимых пакетов тебе не достучаться: тебе либо нужно купить IPv4 для сервера, либо городить костыли, чтобы этот IPv4 пробросить через NAT. Перенос репозитория проекта не поможет, потому что он может тянуть зависимости с github.
А что, если эти падения - это как раз подготовка к запуску IPv6 на Github? Всё-таки это один из последних крупнейших проектов, которые до сих пор не перешли на IPv6 для репозиториев! При этом IPv6 есть на Github Pages.
Просто настолько современный редактор плохо работает на старом железе. У меня ноутбук не поддерживает Vulkan и при запуске Zed дичайшие тормоза. То, что описано в этой статье как фича по факту ей не является. VScode на этом компьютере просто летает, ему не нужен Vulkan.
Ну, 22 порт могут и оставить. Только скорость скачивания там ниже плинтуса опустить. Я так бекапы с сервера сливал. Небольшое число файлов, небольшой дамп БД. Всё заскриптовано. От силы работает под минуты… А хрен там плавал - 20 минут. Заливаешь скрипт на сервер и всё происходит ещё быстрее. А дома вообще еле шевелится.
Это совершенно не выглядит как мечта. Это выглядит как огромнейший костыль, который толком ничего не решает. А ещё, это выглядит как нейрослоп.
Что у нас уже есть и что нам предлагают? А есть у нас протокол IPv6, который прекрасно работает в самом ядре интернета и у провайдеров, которые его осилили. Этот протокол может делать всё, что умеет IPv4. Этот протокол совместим с IPv4 и вполне может транспортировать пакеты IPv4 внутри себя. Если у вас есть на устройстве протокол IPv6, то вы можете организовать доступ к любым ресурсам. Для этого нужен модифицированный костыль, который повсеместно применяется для IPv4, даже многоуровневый (NAT). DNS уже давно адаптирован для IPv6. DHCPv6 уже давно существует и при этом не является обязательным условием для автоконфигурирования сети (всё работает и без него, но вы можете его использовать для более сложной конфигурации). Все современные операционные системы поддерживают протокол IPv6, а если есть какие-то проблемы, то это проблемы конкретного софта, а не самой операционной системы. Все мобильные ОС умеют работать в сетях с исключительно IPv6-адресацией и из коробки имеют необходимый костыль — CLAT, для работы с IPv4 сервисами, которые не удаётся обмануть с помощью NAT64+DNS64. Большая часть сервисов работает без CLAT. Из того, что не работает без CLAT, я нашёл толко торрент клиенты и Steam. Точнее, торренты работают, но число пиров на IPv6 значительно меньше, чем IPv4 и часто невозможно скачать некоторые раздачи без доступа к IPv4 пирам. CLAT в настольных ОС из коробки есть только macOS, для Linux есть несколько решений, в будущей версии NetworkManager 1.58 тоже будет поддержка (можно попробовать уже сейчас установить версию 1.57). Для Windows 11 соответствующий патч проходит тестирование.
Производителям маршрутизаторов не нужно изобретать велосипед, так как уже есть, как минимум, OpenSource операционная система OpenWrt, которая поддерживает IPv6 из коробки, настроена по умолчанию безопасно (нужно только задать пароль для входа в интерфейс) и которую производители могут адаптировать под своё железо.
Чего не хватает в IPv6? То, что если вы пользуетесь только IPv4, то вам недоступны ресурсы IPv6. Есть костыльные решения, которые позволяют организовать доступ, но вы становитесь зависимым от туннельного брокера.
Что же нам предлагают по этому документу? Сегментировать интернет. Сделать кучу разных сегментов, которые напрямую друг с другом не связаны. Те устройства, что будут оставаться в сети IPv4 также не будут иметь доступа в сеть IPv8. Для доступа к IPv8 тоже нужен будет аналогичный костыль, как и для доступа к IPv6. Только подобный костыль для доступа к IPv6 уже есть, можно сказать есть даже несколько видов костылей. Т.е. единственная вещь, за что можно поругать IPv6 характерна и для IPv8. Для IPv8 нужно будет изобретать что-то новое, этим кто-то должен будет заниматься. IPv8 частично решает проблему нехватки адресов, но оставляет старые костыли в виде NAT для устройств пользователя, как минимум. Сквозную прозрачность хороним сразу. Более того, связь между устройствами из разных сегментов сети будет идти через устройства с довольно сложной логикой трансляции адресов. Это как NAT, только ещё более сложный. И эти устройства должны быть установлены в самое «ядро» интернета, где идут огромные потоки данных. Сомнительно, что современные технологии позволят обеспечить скорость передачи пакетов, которая сейчас есть в IPv4 и IPv6.
IPv6 создавался с прицелом на устранение выявленных недостатков IPv4, ведь при расширении адресного пространства протокол становился уже несовместим с IPv4 напрямую, поэтому и смысла нести дальше с собой все недостатки IPv4 не было. И именно поэтому протокол так отличается от IPv4 в лучшую сторону, хоть и требует некоторого времени на знакомство и выкидывания из головы «IPv4 головного мозга». IPv8 продолжает тянуть за собой все косяки IPv4 дальше.
Я не вижу никакого смысла во внедрении IPv8, даже если напишут то, чего сейчас не хватает даже для того, чтобы его попробовать. Внедрение IPv8 - это шаг назад. Индустрия уже сделала шаг в сторону внедрения IPv6 и на текущий момент любой провайдер при желании может включить IPv6 на своей сети. «Вой», что железки IPv6 не понимают… где вы нашли современное железо, которое не поддерживает IPv6? Вы до сих пор используете коммутаторы и маршрутизаторы из нулевых годов? Можно я не буду вашим клиентом. Лично мне не хочется, чтобы надёжность сети зависела от явно устаревшего железа, которое к тому же имеет довольно низкую, по современным меркам производительность.
Насколько я знаком с IPv6? Мне интересен этот протокол. В настоящее время я использую его в своей домашней сети. У меня есть устройства, которые работают исключительно на IPv6, в том числе сотовые телефоны у членов семьи и мой личный ноутбук с ОС Linux. Особого смысла так настраивать сеть нет, но лично мне интересно было настроить именно IPv6-only сеть, а не дуалстэк. И, как показала практика, это рабочее решение.
Звучит приятно, но есть одно но. На этот адрес будет литься весь трафик IPv4. Если это будет какой-то публичный шлюз, то по сути туда пойдёт весь IPv4 трафик интернета. Что делать, чтобы не перегружать узел? Использовать не один, а несколько. Но тут мы упираемся в префикс 64:ff9b::/96. Его могут использовать провайдеры на своей сети. В таком случае достаточно клиенту предоставить DNS64, или просто на клиенте указать DNS64 от Google или Cloudflare, и весь его трафик IPv4 польётся на NAT64 шлюз провайдера. Примерно также, как льётся IPv4 трафик сейчас на CGNAT провайдера. Только CGNAT с каждым годом всё больше и больше загружен, а нагрузка на NAT64 будет падать по мере внедрения на интернет сервисах IPv6.
В принципе, провайдеры тоже могут маршрутизировать 64:ff9b::/96 на вышестоящего оператора, который будет на своей сети иметь NAT64.
Игра в безопасность — она такая. Делаешь юзерам удобнее — становится уязвимым для большых вариантов атаки, делаешь безопасным — либо пользователи взвоют, либо просто мало кто будет пользоваться твоим продуктом.
С моей точки зрения клиенты маха — такие же, как и у других клиентов других мессенджеров. Все могут допускать ошибки и ставить удобство в ущерб безопасности. Но нужно не забывать, что в случае с мах, дьявол кроется на серверной стороне.
Да. Токен вполне может быть и рандомной строкой. Сервер сам решает когда токен протух. Тогда интересно, сколько времени проживёт токен. Я бы не давал много времени токенам, что лежат в localStorage. Сам таким пользуюсь, время жизни - пол часа. Если просто украдут, то время на совершение действий не больше этого времени. Дальше надо снова токен добывать, т.е. нужно контролировать устройство всё время. Эта заметка навела меня на мысль переделать всё на httpOnly cookies. Раньше не знал как сделать, а сейчас нашёл.
Если бы был jwt, из него можно было бы извлечь информацию, но тоже не всегда (иногда контент шиыруют, например, ЕСИА). А сервер может проверить валидность такого токена по закрытому ключу. Здесь не так.
Какая-то бредовая статья. У людей стоит старый маршрутизатор с WiFi на 2,4ГГц. Его всё устраивает. это его проблемы. Диапазон забит? Так он пользуется и не собирается ничего менять.
Вот за что стоит реально беспокоиться, так это за то, что устаревшие устройства могут быть подключены к ботнетам. Вот об этом надо думать. Куча устаревшего железа на которое нормальной пошивки не поставить.
Это немного не так работает. Обычно выдаётся короткоживующий токен, очень часто JWT, где прописан срок протухания. Пока он жив, ты можешь обращаться к сервису. Срок его жизни может быть и пол часа и час. Когда токен протухает, в ход идёт рефреш токен, который можно хранить уже в Cookie, которые недоступны из JS, а значит его через JS уже не угнать, только лезть в кишки баузера, а потом также через кишки вставлять эту cookie в другой браузер. Так что угон этой cookie даст тебе доступ к сайту максимум на час, если, конечно, разработчики не идиоты и не выставили время жизни access токена на большой срок. Через час токен протухнет и старый браузер обновит его, а новый браузер обломается, поэтому что у него нет refresh токена.
Жаль автор не глянул хотя бы через jwt.io что там внутри токена. Если это был обычный JWT, то там должна быть информация, когда токен протухает. Если время протухания далеко в будущем, то это точно будет фейл.
Тогда любое государство может создать свой УЦ и подписывать им все домены, которые ты запрашиваешь. Конечно, если у них есть своя реализация ТСПУ.
Вот паникёров развелось. Будем смотреть как дальше будет всё развиваться. Это вполне разумная реакция Let’s Encrypt на то, что ими воспользовались для того, чтобы заменить ранее отозванный сертификат от другой компании, которая отозвала его по причине санкций.
Не согласен с автором статьи по многим вещам. Например:
cli. Никто не заставляет его использовать. Речь идёт о том, что cli это очень эффективный инструмент. На столько эффективны, что сейчас даже M$ внедряет GNU утилиты в свой Windows. Нативно. Не через WSL. Да и им пришлось полностью переделывать свой cli. В современных версиях есть как его старая версия со времён DOS, в которой толком ничего сделать нельзя, так и PowerShell. cli - это не достоинство Linux - это его фича, доступная из коробки. Если вы писали скрипты под Windows, вы её оцените. Для всех остальных она не нужна. Максимум, вбить уже готовые команды, как это делали люди и в cmd.
vim? Да какой vim? Вы давно ставили какой-нибудь простенький Linux. Из коробки там есть
nano, чаще всего. Во FreeBSD из покон веков былee(хотя FreeBSD не Linux, но несведущие люди не поймут разницы). Наличие vi или vim - это скорее везение. Но его легко поставить, если вы уже зашли в командную строку.Flatpak/snap хороши для GUI приложений. Когда нужно поставить что-то огромное и не хочется захламлять систему. Я обычно сначала смотрю наличие программы в репозиториях, и если там нет нужной мне версии или нет совсем, тогда использую flatpak. Ну или просто посмотреть, что за программа. Что-то на уровне скачать инсталлятор для Windows и поставить, только без высокого шанса вообще убить систему или заразить какой-нибудь заразой. Как выбирать откуда ставить? KDE Plasma был упомянут. Там есть неплохой для обычных юзеров магазин приложений. Он там позволяет выбирать источник установки. Для примера, если набрать в поиске Blender, то у тебя будет аж 3 варианта, откуда поставить. Чисто для потребителя вообще не важно. Он во всех случаях получит свою программу. А если вы разбираетесь, то вы поймёте, что там можно поставить из репозиториев Fedora Linux, Flathub или собственный репозиторий Fedora с flatpak пакетами.
А вот на что действительно не указал автор, что я сейчас вспомню:
Детская болезнь с переключением раскладок. Очень долго преследует дистрибутивы и нужно исправлять. Что я имею в виду. Ты выбираешь русскую раскладку и, возможно даже кнопки для переключения раскладки, но в самой системе остаёшься только со вводом кириллицей. Это приходится лечить через консоль. Недавно с подобным столкнулся в NixOS. Довольно дружелюбный установщик, но видимо, не выполнил какого-то ритуала обязательного при установке раскладки русской. Вероятно чинится, но я с одной попытки попал именно в эту ситуацию.
Проприетарщина. Увы. Проприетарщина - враг OpenSource. Ты вполне можешь поставить вполне себе дружелюбный к пользователям дистрибутив Fedora, а потом наслаждаться слайдшоу или вообще отсутствием картинки при воспроизведении видео. А вся беда в долбанных лицензиях. Поэтому приходится чинить волшебными командами в cli, после чего всё начинает работать нормально. В суть команд не нужно вникать, но приходится это делать. С другой стороны, чтобы у вас на компьютере заработал тот же драйвер Nvidia в Windows и Ubuntu нужно было тоже поплясать с бубном. В Windows поискать нужный исполняемый файл с установщиком на сайте производителя, в Ubuntu немного поклацать в менюшки (может сейчас и не так, не проверял, как не проверял и на Fedora). В Gentoo вообще часто приходится создавать специальные файлы через cli, возможно даже с правильным содержимым, чтобы поставить некоторые пакеты. Но это не дистрибутив для новичков, поэтому ничего сложного, для тех кто поставил Gentoo. В целом, любые лицензионные ограничения зло и заставляют OpenSource делать всё сложнее, чем могло бы быть.
Часто Linux представляют так, что это такая штука, которая работает даже на тапке. А потом новички ставят это на свой компьютер старый отцовский из 2005 года и плюются, что всё глючит и невозможно пользоваться. Ли берут Raspberry Pi 4 с 1 гигабайтом оперативки… или вообще Zero. В результате этого сравнения, их комп с Windows 11 на их современном Intel с 32 гигами оперативки работает на голову выше Linux на RPi Zero…
Даже читать не стал. Это что-то из прошлого тысячелетия. Магнитофон после 2000 года использовал в основном как усилитель для ПК.
Чисто на своём детском опыте смотрю. Кассеты были для меня интересны больше тем, чтобы там хранить игры и программы для ZX-Spectrum. Да, поскольку сам писал эти кассеты, то я и головку подстраивал и кассету сравнивал. И вот кассеты на базе оксида железа были гораздо хуже, чем на основе оксида хрома. И даже сам магнитофон имел соответствующий переключатель, чтобы правильные уровни выставлять для записи, как минимум. Она основе оксида хрома кассеты, конечно, стоили дороже. Но когда ты записываешь то, что не хочешь потерять, то стоило переплачивать. Да и приятнее лично мне было слушать музыку с кассеты на «хроме», а не на «железе». Но это уже субъективщина.
У меня почему-то заголовок статьи ассоциируются из-за новостей с песней «Пожар на заводе искусственных кошек».
Опытные разработчики это понимают. Но это не понимает руководство. У них джун написал код за 3 часа, что делает нормальный разработчик неделю. А это высокий KPI.
Прямо в точку. Если минимально погуглить, то можно прямо тут же на Хабре найти статью о том, что был представлен процессор Иртыш. И там чёрным по белому написано, что он на базе той самой китайской архитектуры будет сделан… Но «чукча не читатель, чукча писатель».
Теория? Да кому она нужна. Да, длина выросла в 2 раза. Но при этом длина адреса источника и места назначения увеличилась в 4 раза. Чтобы это компенсировать, в протоколе введены изменения, например такие, как отсутствие необходимости фрагментации пакетов. Нужную длину фрагментов подбирает источник пакета. Длину пакетов сделали фиксированной, так что теперь большинство узлов в сети могут упростить обработку. Не нужно проверять и корректировать контрольную сумму пакета, как это было в IPv4, всё равно контроль целостности ведётся на более высоких уровнях. Также в IPv6 нет необходимости в NAT. В конце концов, когда проектировали IPv6 уже знали обо всех проблемах и особенностях IPv4. IPv6 - это работа над ошибками IPv4.
Да. Проблема именно в сливе данных VK. Да ещё каких данных! Множество избыточных данных, которые я бы назвал персональными данными, например, данных о том, с каких IP вы выходите в интернет. Это позволит эффективно блокировать интернет по конкретным спискам адресов. Зарубежные сервисы вряд ли занимаются такой аналитикой и, тем более, не будут так взаимодействовать с государственными органами в РФ.
А ещё с github большая подлянка в том, что он не работает через IPv6 напрямую. Ему нужны костыли. Т.е. ты хочешь развернуть свой проект где-то в облаке, но до необходимых пакетов тебе не достучаться: тебе либо нужно купить IPv4 для сервера, либо городить костыли, чтобы этот IPv4 пробросить через NAT. Перенос репозитория проекта не поможет, потому что он может тянуть зависимости с github.
А что, если эти падения - это как раз подготовка к запуску IPv6 на Github? Всё-таки это один из последних крупнейших проектов, которые до сих пор не перешли на IPv6 для репозиториев! При этом IPv6 есть на Github Pages.
Видимо, чтобы тормозил на не самом свежем, но вполне приличном железе, где vscode не тормозит.
Просто настолько современный редактор плохо работает на старом железе. У меня ноутбук не поддерживает Vulkan и при запуске Zed дичайшие тормоза. То, что описано в этой статье как фича по факту ей не является. VScode на этом компьютере просто летает, ему не нужен Vulkan.
Ну, 22 порт могут и оставить. Только скорость скачивания там ниже плинтуса опустить. Я так бекапы с сервера сливал. Небольшое число файлов, небольшой дамп БД. Всё заскриптовано. От силы работает под минуты… А хрен там плавал - 20 минут. Заливаешь скрипт на сервер и всё происходит ещё быстрее. А дома вообще еле шевелится.
Это совершенно не выглядит как мечта. Это выглядит как огромнейший костыль, который толком ничего не решает. А ещё, это выглядит как нейрослоп.
Что у нас уже есть и что нам предлагают? А есть у нас протокол IPv6, который прекрасно работает в самом ядре интернета и у провайдеров, которые его осилили. Этот протокол может делать всё, что умеет IPv4. Этот протокол совместим с IPv4 и вполне может транспортировать пакеты IPv4 внутри себя. Если у вас есть на устройстве протокол IPv6, то вы можете организовать доступ к любым ресурсам. Для этого нужен модифицированный костыль, который повсеместно применяется для IPv4, даже многоуровневый (NAT). DNS уже давно адаптирован для IPv6. DHCPv6 уже давно существует и при этом не является обязательным условием для автоконфигурирования сети (всё работает и без него, но вы можете его использовать для более сложной конфигурации). Все современные операционные системы поддерживают протокол IPv6, а если есть какие-то проблемы, то это проблемы конкретного софта, а не самой операционной системы. Все мобильные ОС умеют работать в сетях с исключительно IPv6-адресацией и из коробки имеют необходимый костыль — CLAT, для работы с IPv4 сервисами, которые не удаётся обмануть с помощью NAT64+DNS64. Большая часть сервисов работает без CLAT. Из того, что не работает без CLAT, я нашёл толко торрент клиенты и Steam. Точнее, торренты работают, но число пиров на IPv6 значительно меньше, чем IPv4 и часто невозможно скачать некоторые раздачи без доступа к IPv4 пирам. CLAT в настольных ОС из коробки есть только macOS, для Linux есть несколько решений, в будущей версии NetworkManager 1.58 тоже будет поддержка (можно попробовать уже сейчас установить версию 1.57). Для Windows 11 соответствующий патч проходит тестирование.
Производителям маршрутизаторов не нужно изобретать велосипед, так как уже есть, как минимум, OpenSource операционная система OpenWrt, которая поддерживает IPv6 из коробки, настроена по умолчанию безопасно (нужно только задать пароль для входа в интерфейс) и которую производители могут адаптировать под своё железо.
Чего не хватает в IPv6? То, что если вы пользуетесь только IPv4, то вам недоступны ресурсы IPv6. Есть костыльные решения, которые позволяют организовать доступ, но вы становитесь зависимым от туннельного брокера.
Что же нам предлагают по этому документу? Сегментировать интернет. Сделать кучу разных сегментов, которые напрямую друг с другом не связаны. Те устройства, что будут оставаться в сети IPv4 также не будут иметь доступа в сеть IPv8. Для доступа к IPv8 тоже нужен будет аналогичный костыль, как и для доступа к IPv6. Только подобный костыль для доступа к IPv6 уже есть, можно сказать есть даже несколько видов костылей. Т.е. единственная вещь, за что можно поругать IPv6 характерна и для IPv8. Для IPv8 нужно будет изобретать что-то новое, этим кто-то должен будет заниматься. IPv8 частично решает проблему нехватки адресов, но оставляет старые костыли в виде NAT для устройств пользователя, как минимум. Сквозную прозрачность хороним сразу. Более того, связь между устройствами из разных сегментов сети будет идти через устройства с довольно сложной логикой трансляции адресов. Это как NAT, только ещё более сложный. И эти устройства должны быть установлены в самое «ядро» интернета, где идут огромные потоки данных. Сомнительно, что современные технологии позволят обеспечить скорость передачи пакетов, которая сейчас есть в IPv4 и IPv6.
IPv6 создавался с прицелом на устранение выявленных недостатков IPv4, ведь при расширении адресного пространства протокол становился уже несовместим с IPv4 напрямую, поэтому и смысла нести дальше с собой все недостатки IPv4 не было. И именно поэтому протокол так отличается от IPv4 в лучшую сторону, хоть и требует некоторого времени на знакомство и выкидывания из головы «IPv4 головного мозга». IPv8 продолжает тянуть за собой все косяки IPv4 дальше.
Я не вижу никакого смысла во внедрении IPv8, даже если напишут то, чего сейчас не хватает даже для того, чтобы его попробовать. Внедрение IPv8 - это шаг назад. Индустрия уже сделала шаг в сторону внедрения IPv6 и на текущий момент любой провайдер при желании может включить IPv6 на своей сети. «Вой», что железки IPv6 не понимают… где вы нашли современное железо, которое не поддерживает IPv6? Вы до сих пор используете коммутаторы и маршрутизаторы из нулевых годов? Можно я не буду вашим клиентом. Лично мне не хочется, чтобы надёжность сети зависела от явно устаревшего железа, которое к тому же имеет довольно низкую, по современным меркам производительность.
Насколько я знаком с IPv6? Мне интересен этот протокол. В настоящее время я использую его в своей домашней сети. У меня есть устройства, которые работают исключительно на IPv6, в том числе сотовые телефоны у членов семьи и мой личный ноутбук с ОС Linux. Особого смысла так настраивать сеть нет, но лично мне интересно было настроить именно IPv6-only сеть, а не дуалстэк. И, как показала практика, это рабочее решение.
Звучит приятно, но есть одно но. На этот адрес будет литься весь трафик IPv4. Если это будет какой-то публичный шлюз, то по сути туда пойдёт весь IPv4 трафик интернета. Что делать, чтобы не перегружать узел? Использовать не один, а несколько. Но тут мы упираемся в префикс 64:ff9b::/96. Его могут использовать провайдеры на своей сети. В таком случае достаточно клиенту предоставить DNS64, или просто на клиенте указать DNS64 от Google или Cloudflare, и весь его трафик IPv4 польётся на NAT64 шлюз провайдера. Примерно также, как льётся IPv4 трафик сейчас на CGNAT провайдера. Только CGNAT с каждым годом всё больше и больше загружен, а нагрузка на NAT64 будет падать по мере внедрения на интернет сервисах IPv6.
В принципе, провайдеры тоже могут маршрутизировать 64:ff9b::/96 на вышестоящего оператора, который будет на своей сети иметь NAT64.
А ещё с IPv8 можно легко построить чебурнет. Просто оставляешь нужные ASN. Профит.