Сети и протоколы
Физический канал: аудит и укрощение реального линка
Читать про полы задержки и bufferbloat — не то же, что измерить их на линке, которым ты владеешь. Возьми реальное соединение — домашний роутер, облачную VM или лабораторный линк — отдели физику от инженерии, загони его в bufferbloat и верни задержку с доказательством на каждом шаге.
Преврати ментальную модель юнита в воспроизводимый цикл измерений: посчитай пол распространения, измерь реальный RTT и разложи избыток, вскрой bufferbloat под насыщением, примени AQM и подтверди фикс числами до/после.
Возьми реальный линк, которым управляешь (домашний аплинк, облачную VM или лабораторный линк), охарактеризуй его физические пределы, вскрой и почини bufferbloat под нагрузкой и докажи каждое утверждение измерениями, а не маркетинговыми числами.
- Таблица до/после: пол распространения, idle RTT, RTT под нагрузкой (до SQM), RTT под нагрузкой (после SQM) и измеренная полоса вверх/вниз — всё измерено, а не оценено.
- Короткое разложение ближнего и дальнего RTT: сколько мс — это пол распространения против избытка маршрут/очереди, с процентом над полом.
- Доказательство, что link-уровень чистый: счётчики CRC/ошибок на нуле и линк согласован на ожидаемой скорости/дуплексе, снятые из ethtool / ip -s link.
- Абзац-разбор: какие числа — физика, которую нельзя изменить, а какие были инженерией, которую ты починил, и чем пожертвовал (пиковый throughput) ради выигрыша по задержке.
- Добавь Shannon-проверку для беспроводного линка: считай ширину канала и SNR (iw / вендорские тулзы), посчитай теоретический потолок ёмкости и сравни с реально измеренным throughput — объясни разрыв.
- Заскриптуй весь аудит так, чтобы он шёл без присмотра и выдавал таблицу до/после как JSON или график — переиспользуемый зонд здоровья линка, который можно поставить на расписание.
- Сравни два транспорта на дальнем пути: дефолтный loss-based-отправитель против BBR (sysctl net.ipv4.tcp_congestion_control=bbr) и измерь throughput и задержку-под-нагрузкой на каждом.
- Напиши одностраничный on-call runbook: как отличить физику от бага на link-уровне, числа пола для частых маршрутов, процедуру теста bufferbloat и настройки SQM, которые починили проблему.
Это цикл, который ты запускаешь на любом реальном инциденте линка: посчитай пол, измерь реальность, разложи избыток на физику против инженерии, вскрой bufferbloat, пингуя под нагрузкой (никогда на idle-линке), подтверди, что link-уровень чист, затем примени AQM, зашейпленный ниже line rate, и проверь числами до/после. Сделав это раз на своём линке, ты превращаешь числа пола и сигнатуру bufferbloat в инстинкт, к которому потянешься в production.