Перехватывать трафик выше транспортного уровня

Question

Во-первых, я относительно новичок в сетевом программировании.Я хочу перехватывать и задерживать HTTP-трафик до того, как он попадет в серверное приложение.Я углубился в libnetfilter_queue, который дает мне всю необходимую информацию для соответствующей задержки, но на слишком низком уровне.Я могу задержать трафик там, но если я не приму IP-дейтаграммы почти немедленно (поэтому отправляю их вверх по стеку, когда я хочу их задержать), они получат повторную отправку (когда не поступит подтверждение), а это не то, чего я хочу.

Я не хочу и не нуждаюсь в том, чтобы иметь дело с TCP, только с полезной нагрузкой, которую он предоставляет.Итак, мой вопрос заключается в том, как мне перехватить трафик на определенном порту до того, как он достигнет места назначения, но после того, как TCP подтвердит и проверит его?

Спасибо

Редактировать:Надеюсь, это очевидно из тега и libnetfilter_queue - это для Linux

Answer 1

Перехватывайте соединения через HTTP-прокси.Погуглите хороший способ сделать это, если вы не можете просто установить HTTP_PROXY на клиенте или настроить свой фильтр, работающий с IP и номером порта текущего сервера, переместив реальный сервер на другой IP.

Таким образом, фактические TCP-соединения осуществляются между клиентом и вами, а затем от вас к серверу.Тогда вам не придется иметь дело с подтверждениями, потому что TCP всегда видит, что миссия выполнена.

Редактировать:Я вижу, что в комментариях к оригиналу уже появилась эта идея использовать iptables для перенаправления трафика через ваш прозрачный прокси-процесс на том же компьютере.

Answer 2

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

Проблема (или a) заключается в том, что веб-сервер теперь, по понятным причинам, думает, что каждый запрос поступает с localhost.На самом деле я бы хотел, чтобы эта задержка была прозрачной как для клиента, так и для сервера (за исключением времени, конечно!).Могу ли я что-нибудь с этим сделать?

Если нет, то каковы последствия?Каждый HTTP-сеанс происходит через другой порт - достаточно ли этого для того, чтобы они были полностью разделены, как и должно быть?Предположительно, это так, учитывая, что это работает, когда за NAT, где адрес для многих сеансов один и тот же.