# CRXN, GRE, fastd як альтернатива крипто-садомазохізму

В пошуках економічного (на end-to-end компах) способу передачі UDP/TCP трафіку, поліз курити CRXN, суто за прикладами реалізації маршрутів на базі якогось реєстру типу Git:

=> https://codeberg.org/CRXN/docs/src/branch/master/docs

Відкрив там для себе два нові рішення легкого тунелювання: GRE і fastd. Тепер думаю: якщо я збільшу розмір пакету даними маршрутизації, то чи не відтяпає цей аналіз стільки ж енергії, скільки на декодування підписаних даних.

Тим не менше, консенсус - він всюди. Різниця крипти лише в тому, що її важко моніторити, від того легше ганяти нею не модерований траф. По великому рахунку, будь які рішення можуть бути легко заблоковані, тому я думаю що вони працюють рівно доти, допоки їм дають можливість працювати центральні регулятори.

Проблема відомих мені криптографічних маршрутизаторів полягає у тому, що вони фактично декодують увесь мережний шум, відбираючи тільки частку корисного трафіку. Найпростіший приклад тому - BitMessage, коли до рою DHT потрапляє увесь трафік переписок, а вузол намагається відшукати у ньому валідний підпис. Це працює, допоки в рої десяток користувачів, але росте мережа - падає коефіцієнт корисної дії, майже у всіх без виключеннях "автоматах" P2P. Досі живий приклад - IPFS, де системний трафік зашкалює за 1 Мбіт на пустому локальному сховищі.

Мораль у тому, що мені не подобається розкидатись часом CPU для цілком відкритих задач. Для прикладу, передача публічних файлів засобами FTP і sFTP має колосальну різницю в продуктивності. Те само з медіа-потоками або ігровими стрімами. Я зовсім не хочу відкусувати ядро на 4 гравця халфи, тоді як не шифровані дані - можуть тягнути тисячі онлайну. Мене тупо душить жаба давати стрім на одного слухача радіо, який відбирає 25%.

P.S. Поліз читати доки для самих маленьких, і зрозумів що мережного сіса - мені ще як до неба рачки. Але я не здамся, бо вже не вперше тікаю з іги (як і P2P в цілому, що по суті є голодним авто-пілотом) через усвідомлення її марнотратства та ілюзії свободи.

P.P.S. Ці висновки в мене формуються, виходячи з енергетичних реалій, де усі ці іграшки що звичайно вісять на фоні - в "бойових" умовах, не витримують жодного краш-тесту, не кажучи вже про якийсь там пост-апокаліпсис, де працювати нормально зможе тільки макро / лампова електроніка.

P.P.P.S. Опинившись якось в умовах повної заборони радіо-сигналу (привіт, Reticulum) я в серйоз задумувався про оптичні канали на базі імпульсного генератора фотонів з підручних засобів, на рівні Морзе. Еволюція складних рішень - має критичну точку свого розвитку, і сучасні експериментальні роутери перебувають десь близько неї. В мене є певні сподівання на пост-квантові / спінові рішення, але в цій сфері я ще більший нуб, аніж в технологіях 50-річної давнини.

## Посилання

=> https://soc.ua-fediland.de/@ps/116188217945307931

### Дивіться також

=> thoughts-on-tls-on-yggdrasil-and-mycelium-networks.gmi Думки стосовно TLS в мережах Yggdrasil та Mycelium
=> power-optimization-on-linux.gmi Оптимізація енергоспоживання в GNOME / Linux
=> gemini://gemini.ctrl-c.club/~stack/gemlog/2022-02-13.notls.gmi A Call for a Gemini Without TLS
=> gemini://station.martinrue.com/audacityplatypus/c965bae452864452add5d53ba6c18a56 TOFU makes Gemini inappropriate for sharing software in-band
=> gemini://bbs.geminispace.org/s/Gemini/24266 Thoughts on geminict://