Сервер для проверки замедления доменов t.co который сделал Леонид Евдокимов. Обсуждение здесь.

https://speed.gulag.link/

Снизу и сверху тесты скорости до одного и то же сервера, разница только в доменах:

Первый t.co.speed.gulag.link
Второй speed.gulag.link

UPD: Если вы видите значительную разницу в скоростях, значит вас тоже опустили. Обычно если проблема есть, то сверху будут значения около 0.1 а снизу >1. Не смотрите на абсолютные значения скорости, значение имеет только разница. Это дешевый сервер в Scaleway с узким каналов.

​HTTP/3 vs. HTTP/2 vs. HTTP/1.1 под разными углами в картинках.

Лучший способ понять как работает сеть, тот или иной протокол, это написать собственный клиент или сервер. Можно смотреть и в дампы конечно, но сделать своё работает лучше когда становишься непосредственным участником процесса. Тем более в первом приближении это не так уж и сложно. Серия из нескольких постов, начиная с теории до реализации простейшего TCP SYN сканера на Python используя модуль socket. С ручной генерацией нужных пакетов с заполнением всех полей. Бонусом то же для ICMP.
Тут даже не важен язык и даже результат, процесс строительства позволяет узнать больше, чем простое созерцание.

​Эволюция Интернет 1997-2021 в одном видео, как карта BGP соседств. Очень красиво, есть исходники, можно картинок на рабочий стол надёргать.

Помимо пути "туда" есть путь "обратно" и часто это не одно и то же. Если это становится важным то обычные утилиты вам могут уже не помочь, ping - бессилен, покажет только суммарное время туда+обратно. Написать корректную реализацию подобного инструмента, учитывающего асимметричность маршрутов совсем не просто, в дело вмешивается время, его синхронизация. И поэтому, например, встроенный в ICMP Timestamp Requests, будет работать не всегда достаточно точно.

Однако всегда можно что-то придумать, особенно если это Ben Cox. То что получилось забираем на GitHub, реализация с ICMP там же.

P.S. Не забываем и про Record Route, правда применимо это далеко не всегда.

​DNS over TLS пока всё ещё не очень. Помимо этого в работе представлена интересная статистика и по обычным широко известным провайдерам публичных DNS, включая Yandex DNS - надёжности и задержкам. Делаем скидку на распространение RIPE Atlas по миру, не на каждом континенте их одинаково много.

Этот вечный вопрос курицы и яйца, на этот раз для современного подхода к сетям. Мы хотим избавиться от ручного конфигурирования устройств и вообще от устройств, а рассматривать сеть как единое целое, задавая высокоуровневые параметры (намерения), а всё остальное за нас сделает автоматика. Для этого надо написать спецификацию того чего мы хотим и формализовать свою сеть. А если у нас уже есть сеть? Тогда мы можем эту спецификацию построить по текущей сети, автоматически. Главное при этом не притащить с собой старые подходы и вовремя остановиться в этом цикле.

И ещё из блога APNIC: 50 летняя история развития архитектуры маршрутизаторов - выученные и ещё не выученные уроки.

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

DoH в dig 9.17.11. Сервер был чуть раньше. DoT ещё раньше.

Path MTU discovery сломан в Интернет и сломан основательно, просто потому что в большинстве случаев вы не дождётесь нужного ICMP и уже не важно является ли это намеренным действием, опечаткой, незнанием, особенность подхода который применяется. Это данность. И единственный выход сделать хорошо для многих, но не для всех - это экспериментируя с TCP MSS и MTU на своей стороне, пытаясь найти баланс.

Утилита, которая пытается справится с этой проблемой в конкретном архитектурном решении балансировки в дата центрах, основываясь на информационном черновике IETF. Почитайте его обязательно, там, как раз, есть и про костыли TCP MSS. Cloudflare делал подобную реализацию несколько лет назад для одного Ethernet сегмента, эта утилита чуть более универсальная. В любом случае, Cloudflare реалисты и тоже играют в игру угадай нужное MTU.

За ссылку огромное спасибо нашему подписчику, очень рад что не забываете про меня. Спасибо.

Своеобразная реализация a'la Port knocking - ShieldWall. Заходим на веб интерфейс, открываем себе доступ, попадаем на ресурс. Не знаю, может удобно, я себе делал просто на iptables/ipset, в текущем виде это точно не лучше.
Забираем на Github и обязательно поднимаем свой сервер для управления.

Самое главное в процессе отладки - придерживаться выбранного метода, стратегии, тактики. Педантично и досконально, по другому не работает. Например, можно двигаться снизу вверх по уровням OSI ничего не пропуская.

А это уже про стратегию. Как быть уверенным в своей сети настолько, чтобы не растеряться и знать что ответить на вопрос: "Моё приложение не работает, может дело в сети?"

Пока многие из вас спят, а я нет. 23 марта 18:00 UTC опубликовано RFC8996, которое формально запрещает использование TLSv1.0 и 1.1. Не используйте, даже несмотря на то, что это всего лишь RFC.

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

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

Whois к РАНР (реестр адресно-номерных ресурсов сети Интернет) - https://w.ranr.noc.gov.ru, можно и из консоли whois -h. Теоретически должно находить все ресурсы Интернет в российской принадлежности.
Работавшим с Whois RIPEDB должно быть знакомо.

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