А что насчёт жидкостей с сахарозаменителями (всякие колы Зеро и прочие)? Слышал варианты вида: они вредные, потому что после них хочется ЖРАТ, и они вредные, потому что всё равно идёт выброс инсулина, который будет ЖРАТ организм.
Ага. Так IPv6 постепенно вводят, а там с этим гораздо лучше. Никак ввести не могут. Всё очень сложно. Например, весь интернет живёт на L3 и иногда L4, т.е. ему аппаратные ограничения вроде бы не нужны. А дома уже L2 вылезает в полной красе, и там стандарты прибиты и просто так их не изменить. Есть Ethernet, есть Wifi, у всех свои правила. И в локальной сети всё идёт мимо маршрутизатора. Так что, надо MTU увеличивать у всех устройств, иначе будут проблемы (пакет не пролезет). И какой-нибудь умный холодильник всё испортит.
Получается, что надо:
1. Обновить абсолютно все устройства дома (компьютеры, ноутбуки, телефоны, телевизоры, роутеры и т.д.)
2. Обновить операционные системы на компьютерах
3. Обновить всё оборудование у провайдера
4. Обновить все магистрали
И всё ради того, чтобы увеличить MTU, и чуть-чуть выиграть в скорости. Куча работы, любой баг может привести к частичной неработоспособности сети и прочее.
Но есть всеми ненавистный IPv6, у которого эти проблемы постарались решить (там встроенный MTU Discovery, нормально с номерами и размерами пакетов). Можно просто выпустить оборудование с поддержкой IPv6 и будет всё проще. Но только как-то с 1996-ого года прогресс не очень.
На самом деле всё ещё сложнее и запутаннее. Например, в реальности очень часто MTU меньше 1500 байт. Причина: VPN, PPPoE, IPSec, т.е. любой туннель откуда-то должен брать информацию о самом себе и тем самым уменьшать полезную нагрузку. Спрашивается, как же всё работает так, что нет постоянной фрагментации. А работает оно следующим подлым образом (есть другие способы, но этот самый надёжный): При установлении TCP соединения каждый из хостов указывает свой максимальный размер пакета (MSS), выбирается минимальный и дальше всё работает с таким размером. Т.е. это уже 4-ый уровень (а Ethernet — второй). Так вот, маршрутизаторы просто ловят данные пакеты и уменьшают MSS на своей стороне. Таким образом получается, что виртуальный MTU — 1500, а реальный — может быть гораздо меньше.
И если мы попытаемся увеличить где-то MTU, то скорее всего один из узлов всё равно подрежет его до своего значения и смысла в увеличенном размере не будет никакого.
Вначале подумал, что это стёб с генерацией текста через нейросеть, потом подумал, что вроде бы нет. Прочитал дальше и стал думать, что это какой-то эксперимент по обучению нейросети и lair c fougasse участвуют в нём с покерфейсом.
Но вроде бы для первого апреля рано, поэтому чувствую непонятки. Извините, если раскрыл тонкий троллинг над пользователями хабра.
Меня на мелком сайте, где реклама была как раз «на пиво» гугл забанил на месяц со статусом — «от тебя мусорный трафик, разбирайся с ним сам, или забаним навечно». Предупреждений и вымогательств от мошенников не было. В итоге тупо убрал рекламу. Поведение гугла уж очень хамское.
> Нет никаких 10+. Насколько я понимаю функционал Windows 10 уже не будет обновляться, она перешла в стадию поддержки, то есть через 5 лет перестанут приходить патчи безопасности
Обновляется каждые полгода. 1703, 1709, 1803, 1809 и т.д. По факту — это не просто обновление или сервис пак, это полностью переустановка системы с сохранением настроек. Т.е. всё у Microsoft выходит и продолжает выходить.
А можно отключение жестов добавить в настройки хоткеев, чтобы для какого-то сайта вырубать? (где активно используются кнопки мышиные) Или отрубать per вкладка.
Но ведь WireGuard это ближе к туннелю, чем к VPN. Что в принципе обходится, но всё-таки немного другая концепция. С IPSec его сравнивать можно, но OpenVPN гораздо развесистее.
Ну и про удобство для пользователей так себе идея. Логины с паролями — это понятно, а длинющий ключ вводить — то ещё заняте.
Ну, в темах про IPv6 часто поднимаются вопросы вида — зачем такое сложное придумали. Да и развитие IPv6 идёт странными шагами, вначале решили, что DHCP не нужен, а достаточно SLAAC, потом провайдеры начали по одному адресу выдавать вместо 64-ой сетки. К тому же, когда он проектировался — были совершенно другие практики в работе с сетью.
Т.е., может вообще придумают какой-то аналог Mesh, или что-то типа Tor'а/I2P будет, что приведёт не к просто изменению длины IP, а изменению концепции адресации. В любом случае, гадание на кофейной гуще, у нас сейчас ничего подобного на примете нет.
Думаю, что замена на беззнаковый не особо легче чем нормальная переделка под 64 бита. Потому что банально можно делать математику с датами, типа сколько дней между двумя датами. И тут запросто получаются отрицательные числа. Что будет с беззнаковыми и конвертацией туда-сюда, страшно даже представить.
Неможко постебусь, но IPv8 через 18 лет — это фантастика. IPv6 был придуман в 1996-ом году. Т.е. уже прошло 23 года, а он ещё не особо шевелится. Так что дай бог, через 18 лет хотя бы 80% компьютеров будут на IPv6 :)
А ещё были ситуации, что некоторые из подобных роутеров при начальном включении слали пакет с оригинальным MAC-адресом, а потом клонированным. Что ловилось провайдером, и если он блокировал не на MAC-адреса, а на количество устройств, то роутер блокировался и пользователь долго чесал репу, что же не так.
По поводу одинаковых MAC-адресов: поимели много веселья, когда два виртуалочных хоста решили своим виртуалкам раздавать одинаковые адреса (как я понимаю, префикс там генерируется при установке, а дальше просто счётчик). Так что, тема с виртуалками (особенно с бекапом-рестором и клонированием) может хорошо помочь в понимании проблем работы сети с одинаковыми адресами.
Классическая поговорка из IT: «Представьте, мы берём на работу студента, учим его, а он уходит в другое место. А теперь представьте, мы его не учим, а он остаётся». Кто-то уедет, а кто-то останется, но он будет хорошим специалистом, а не посредственностью, которая всё равно может подучиться и уехать.
Там автор больше напирает на .NET Framework и Windows, там утечки нет, потому что под капотом у HttpClient находится банальный HttpWebRequest, со своими тараканами, но без утечек. Утечки именно появились в .NET Core 2.2, где сделали свою реализацию работы с HTTP (быстрее, выше, сильнее). Поэтому многие очень удивились проблемам, когда просто обновили фреймворк, не меняя ни строчки в приложении и получили подобное поведение.
HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads.
Ну и про один запрос оттуда же
The HttpClient class instance acts as a session to send HTTP requests. An HttpClient instance is a collection of settings applied to all requests executed by that instance. In addition, every HttpClient instance uses its own connection pool, isolating its requests from requests executed by other HttpClient instances.
В реальности, мне писали, что получали SocketException, у нас было веселее — приложение чем дольше работало, тем больше процессора использовало. Т.е. после пары недель работы 100%. А при подключении к нему отладчика — всё сбрасывалось и опять типа норма. Приятного анализа, блин.
Да, и работает это именно под Core 2.2 и выше. В более старых версиях — используется другая реализация, а в большом .NET — тот же HttpWebRequest, который не страдает этой проблемой.
Тогда стоит использовать фабрику, но ни в коем случае не обычный диспозабельный HttpClient, иначе у вас будут утекать ресурсы, с весьма неприятными последствиями. Если что, в Microsoft после нескольких пинков поправили документацию, так что там теперь это указано.
Думаю, есть человеческая задача: «развернуть односвязный список», но т.к. в реальности двусвязные обычно удобнее и реализованы в языках, задача сформировалась в такого Франкенштейна.
Получается, что надо:
1. Обновить абсолютно все устройства дома (компьютеры, ноутбуки, телефоны, телевизоры, роутеры и т.д.)
2. Обновить операционные системы на компьютерах
3. Обновить всё оборудование у провайдера
4. Обновить все магистрали
И всё ради того, чтобы увеличить MTU, и чуть-чуть выиграть в скорости. Куча работы, любой баг может привести к частичной неработоспособности сети и прочее.
Но есть всеми ненавистный IPv6, у которого эти проблемы постарались решить (там встроенный MTU Discovery, нормально с номерами и размерами пакетов). Можно просто выпустить оборудование с поддержкой IPv6 и будет всё проще. Но только как-то с 1996-ого года прогресс не очень.
И если мы попытаемся увеличить где-то MTU, то скорее всего один из узлов всё равно подрежет его до своего значения и смысла в увеличенном размере не будет никакого.
Но вроде бы для первого апреля рано, поэтому чувствую непонятки. Извините, если раскрыл тонкий троллинг над пользователями хабра.
Обновляется каждые полгода. 1703, 1709, 1803, 1809 и т.д. По факту — это не просто обновление или сервис пак, это полностью переустановка системы с сохранением настроек. Т.е. всё у Microsoft выходит и продолжает выходить.
Ну и про удобство для пользователей так себе идея. Логины с паролями — это понятно, а длинющий ключ вводить — то ещё заняте.
Т.е., может вообще придумают какой-то аналог Mesh, или что-то типа Tor'а/I2P будет, что приведёт не к просто изменению длины IP, а изменению концепции адресации. В любом случае, гадание на кофейной гуще, у нас сейчас ничего подобного на примете нет.
Ну и про один запрос оттуда же
В реальности, мне писали, что получали SocketException, у нас было веселее — приложение чем дольше работало, тем больше процессора использовало. Т.е. после пары недель работы 100%. А при подключении к нему отладчика — всё сбрасывалось и опять типа норма. Приятного анализа, блин.
Да, и работает это именно под Core 2.2 и выше. В более старых версиях — используется другая реализация, а в большом .NET — тот же HttpWebRequest, который не страдает этой проблемой.