«ускоритель» TCP при forwarding
сап лор, есть несколько вопросов по сетям которые я не смог нагулить (плохо искал похоже).
а) есть ли готовые tcp «прокси» которые терминируют tcp с одного конца, кладут даныне в очередь, пересылают даныне через новый tcp connection по адресу, при этом пересылая и icmp т.е. полностью прозрачны? б) можно ли это сделать силами только лишь iptables?
Зачем нужно. Есть моя рабочая станция в г. СтандартЗажопинск и есть сервер скажем в московском дц. И станция и сервер имеют линк 100Mbit, но если я делаю пайкеджманаджер_name update из дому это занимает n минут, а на сервере выполняется почти мгновенно. Оно и логично, в дц там пару хопов до магистрали, можно считать что почти локалка, tcp в таких условиях работает крайне хорошо. Фаст опен вся фигня, cubic чувствует себя как дома. Из моего зажопинска, через кривой шейпер провайдера, через двадцатку хопов до магистрали, через подлагивающую вафлю, конечно скорость так себе.
Вот и пришла мысля запустить tcp «прокси» на сервере. В этом случае запрашиваеммый хост крайне быстро и охотно отдает пакеты, а уж опосля, меееедленно, я перешлю их в свой зажопинск. Ускорение состоит в том, что практически все веб серверы + стек tcp/ip не стремятся выжать из канала максимум и крайне консервативны в количестве пакетов в еденицу времени исходя из способности клиента. Ды и уравниловку ни кто не отменял, в итоге «забитые» страдают в двойне. С точки зрения сongestion сontrol благодать, cubic для господ (tier1), westwood для крестьянорабочих. + разные там MTU и т.д., уменьшение RTT т.к. бьем маршрут на 2…
в) что по пропорциональному уменьшению буфера tcp по мере заполнения очереди? Экспоненцальное уменьшение после некоторого лимита?
г) локальный tcp proxy в домашней сети. Зачем ходить за тридевять земель перезапрашивая утеренный/побитый в радиоэфире драгоценный пакет (тем он и драгоценен что иноморский, накладные расходы на доставку высокие), когда можно запомнить его на домашнем тазике и втолковывать рабочей станции пока до той не дойдет.
д) qos и ip path constant heat. Возможности канала известны заранее или могут обновляться динамически. Если мы имеем любой tunel через tcp (или для raw ip или udp это тоже актуально). То можно в нем создать «служебное» соединение ,которое гоняет одинаковые пакеты, трафик по которому будет регулироватся по закону s(t) = const - tunel_data(t) где const верхний лимит канала. Т.е. тунель будет в независимости от тунелированнго трафика в нем всегда поддерживать один и тотже rate. Верхний лимит можно подстраивать в зависимости от патерь пакетов. Подстройка одного connection видится мне более практичной чем крутить множество tcp. Абузинг факта point2point. +сетевое оборудование нынче достаточно интелектуальное и тоже трафик считает, зная от кого что ждать, тут и для клиента хорошо и для сетей предсказуемо. +ещё кто то знает тот знает - кореляционный анализ.
е) kernel или юзерспейс реализация fake tcp (юзерспейс наверное). Нынче с нашем буйствующем RosPlugНадзором актуально. tcp in tcp всегда плохо. Но все идет к тому что только tcp будет ходить, причем только кашерные протоколы. на dtls надежды нет. Вопрос знатоком - есть ли решение которое маскируется под tcp, но при этом позволяет out of order доставку? Вернее это и есть реализация tcp только с возможностью читать сырые пакеты.
ё) есть ли наработки по tls preopen? Сделать mitm на машине локльно и заранее открывать 10-20 tls соедененй для самых частых sni за все время или за окно. Ну через n времени если не нужны отсылать http options, закрывать, открывать опять. Перспективным видится soks5 proxy для этого.
ж) в природе не существует ни какого хитрого http header compression над tls трафиком? ну мало ли можно заранее заготовить кусок. как сделать это через mitm понятно, но тут mitm должен быть на граничном узле что не очень секьюрно.
оригинальная орфаграция и пунктуация сохранена, спасибо!
