Изменить HTTP-URL на лету
Можно ли изменить HTTP-запрос пользователя на
www.example.com/options
вместо
www.example.com/options_and_params
Мой сценарий заключается в том, что около 30000 пользователей подключаются к сетевой магистрали моей компании, и я хочу добавить один или несколько серверов (с кодом, над которым я сейчас работаю) между магистральными коммутаторами и Radware LoadProof для выполнения этой работы.
После того, как я погуглил всю ночь, у меня не осталось никаких следов, но есть еще вопросы:
- Мне не нужно перехватывать каждый пакет через сеть. С помощью некоторых подсказок, таких как iptables, я могу отфильтровать нужный пакет. Я сделал это, прежде чем использовать iptables. Однако пакет не равен потоку HTTP. Нужно ли делать HTTP-перестройку?
- Если я успешно найду способ изменить содержимое URL-адреса HTTP-запроса, я все равно должен вернуть его в сетевой поток. Как я знаю, TCP-пакеты имеют контрольную сумму, и после того, как я изменяю содержимое, это должно быть неправильно. Как рассчитать новую контрольную сумму и вернуть пакет в сеть?
Я впервые занимаюсь сетевым программированием или обработкой пакетов. Любое предложение ценится.
2 ответа
Это зависит от того, выполняете ли вы HTTP/1.0 или HTTP/1.1 и является ли это первоначальным запросом, который нужно изменить, или всеми запросами в одном сеансе HTTP 1.1.
Если у вас есть пакет, и вы можете изменить его до того, как он будет отправлен, и вы пытаетесь изменить только запрос, то с учетом длины типичного пакета и расположения URL-адреса в потоке HTTP-запросов (в самом начале) и факт, что это будет первое, что будет отправлено в потоке TCP, я думаю, вы можете с уверенностью предположить, что он будет присутствовать в первых N байтах первого отправленного пакета и, следовательно, не будет разделен на несколько пакетов.
Однако, если это поток HTTP/1.1, то через одно и то же TCP-соединение будут отправляться несколько запросов, и в этом случае в будущих запросах URL-адрес может быть разделен на два TCP-пакета.
Если вы можете принудительно установить HTTP/1.0 или, возможно, измените первоначальный или все запросы на HTTP/1.0, то вы можете быть совершенно уверены, что первый пакет будет соответствовать первому пакету потока TCP и что вы вряд ли увидеть URL-адрес, разделенный на несколько пакетов, что означает отсутствие реконструкции и возможность просто заменить.
Однако это будет стоить новых TCP-соединений, что довольно неэффективно.
Если вы этого не сделаете и оставите его как HTTP/1.1, тогда URL-адрес может быть в любой случайной точке в любом будущем запросе и, следовательно, разделен на несколько пакетов TCP (два реально заданных размера URL-адреса).
Если я правильно понял ваш вопрос, то, вероятно, это можно сделать с помощью некоторого быстрого обратного прокси-сервера, такого как nginx.