Rtsp через http через прокси
Я пытаюсь получить поток RTSP через HTTP с помощью прокси. Поведение настоящего клиента кажется немного беспокойным: он пробует сразу все возможные порты, методы и протоколы. Единственное, что должно работать, - это HTTP GET через порт 80. Такой запрос действительно выдается и принимается на сервере. Вот как выглядит запрос, когда он отправляется прокси на сервер:
GET /SmpDsBhgRl83c52ef2-d0f4-41ac-bada-93e5350f67d1?1 = "1" HTTP/1.0\r\n
Connection: Keep-Alive\r\n
Host: 10.194.5.162:80\r\n
Pragma: no-cache\r\n
User-Agent: RealPlayer G2\r\n
Expires: Mon, 18 May 1974 00:00:00 GMT\r\n
Accept: application/x-rtsp-tunnelled, */*\r\n
ClientID: WinNT_5.1_6.0.14.806_RealPlayer_R41UKD_en-GB_686\r\n
X-Actual-URL: rtsp://10.194.5.162:554/01.mp3\r\n
\r\n
Вот ответ сервера:
HTTP/1.0 200 OK\r\n
Server: RMServer 1.0\r\n
Expires: Mon, 18 May 1974 00:00:00 GMT\r\n
Pragma: no-cache\r\n
x-server-ipaddress: 10.194.5.162\r\n
Content-type: audio/x-pn-realaudio\r\n
\r\n
В этот момент от сервера приходит еще 4 байта (их значения 48 02 02 00) - и все, не более того. Ожидает ли сервер чего-либо от клиента в этот момент, и если да, то что? Этот режим работы вообще работает?
Еще немного информации по этой проблеме: очевидно, предполагаемый механизм работы с RTSP через HTTP, встроенный в RealPlayer, выглядит следующим образом:
- Попробуйте подключиться к следующим портам: 80, 8080, 554, 7070. (Попробуйте также загрузить файл напрямую, просто на всякий случай, выполнив GET http: // имя хоста: порт / имя медиафайла на порту 80)
- Для каждого из указанных выше портов создайте по 2 подключения.
- Отправьте запрос GET на одно из подключений по URL-адресу http: // имя хоста: порт / SmpDsBhgRl
<guid>? 1 = "1", где<guid>- это, да, только что созданный GUID. Добавьте к этому запросу заголовок X-Actual-URL, содержащий исходный URL-адрес RTSP. - Отправьте запрос POST на другом подключении по URL-адресу http: // имя хоста: порт / SmpDsBhgRl с указанным выше идентификатором GUID как часть тела запроса. Отправьте заголовок Content-Length размером 32767 байт, чтобы предотвратить преждевременное закрытие соединения прокси-сервером.
- Начните отправлять команды серверу через запрос POST и получите соответствующий поток RTSP как часть ответа GET.
Странная вещь (если вышесказанное не кажется достаточно странным) заключается в том, что, например, он работает со Squid, но не с портами 3128 или 8080! Каким-то образом клиент использует порт, к которому он подключается, чтобы решить, в каком порядке запросы или когда запрос должен быть отменен, но в любом случае, как бы трудно это ни было поверить, он работает с прокси-портом 9090, 3129, 8081, но не с 3128 или 8080.
Обновление №2: Здесь - источник RealPlayer с объяснением вышеуказанного поведения. Однако решения по-прежнему нет.
Обновление №3: Хорошо, в свете вышеизложенного, магическое значение 48 02 02 00 ясно: 48 == 'h' для HTTP_RESPONSE, следующий 02 - длина следующих данных, следующий 02 вызывается POST_NOT_RECEIVED (это означает, что запрос POST не достиг сервера в течение секунды после соответствующего запроса GET).
Обновление №4: такое поведение (например, запросы POST с огромной длиной содержимого) также характерно для ActiveX, используемого WebEx (и, возможно, многими другими веб-приложениями, которым требуется открытый канал для сервера).
Ответы 2
- Посмотрите, приводит ли отправка того же запроса, но в обход прокси-сервера (например, повторное воспроизведение отправленного вами выше запроса с помощью Netcat) к потоку более четырех байтов в теле ответа.
- Посмотрите, какие TCP-пакеты получает прокси, например, перехватывая TCP. трафик на машине, на которой запущен прокси, скажем, с помощью Wireshark.
Во-первых, вы можете прочитать это:
http://developer.apple.com/quicktime/icefloe/dispatch028.html
Во-вторых, HTTP-запросы (как GET, так и POST) должны быть отформатированы так, чтобы они правильно проксировались. Я видел прокси, которые настаивают на кешировании слишком большого количества запросов POST, не позволяя им добраться до сервера. В этих прокси-серверах есть ошибки, но вы ничего не можете с этим поделать, и мне не удалось обойти эту проблему. В основном я видел это с антивирусным программным обеспечением, которое пытается сделать прозрачное проксирование POST-запросов, поступающих из браузера, для сканирования их на предмет личной информации, такой как номера социального страхования. Возможно, вы столкнулись с той же проблемой.
Вы случайно не используете антивирус McAfee?
Кроме того, похоже, что Real изобрела свой собственный способ сделать то же самое, но базовая конструкция очень похожа - GET для нисходящей ссылки, POST для восходящей, с каким-то волшебным файлом cookie (в данном случае GUID) для привязки двое вместе на сервере. В любом случае POST должен попасть на сервер, а в вашем случае кажется, что это не так.
Кстати, поскольку проблема, похоже, заключается в том, что запрос POST не проходит через прокси-сервер, как насчет публикации этого запроса в дополнение к GET?
Верен ли ответ сервера HTTP 200 OK ?! Мой сервер раньше отвечал так же, как ваш, но RealPlayer перестал отвечать после открытия соединений GET и POST. Затем я добавил к телу ответа 48 02 00 00 и атрибут Content-Length: 4, и это сработало ... Возможно, вам нужно изменить ответ HTTP OK и отправить его после получения POST-соединения, а не до этого.