Перехват трафика над транспортным уровнем - PullRequest
3 голосов
/ 01 декабря 2009

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

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

Спасибо

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

Ответы [ 2 ]

2 голосов
/ 05 декабря 2009

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

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

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

1 голос
/ 01 декабря 2009

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

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

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

...