Как браузер определяет, будет ли прокси-сервер «не доступен» при использовании PAC файл

Question

У меня есть следующий PAC код файла:

function FindProxyForURL(url, host) 
{ 
    return "PROXY proxy1:8080" + "PROXY proxy2:8080; "; 
}; 

Согласно Java это должно работать следующим образом (https://docs.oracle.com/cd/E19575-01/821-0053/adyrr/index.html):

В следующем примере возвращаемое значение указывает браузеру использовать прокси с именем w3proxy.example.com на порту 8080. Если этот прокси недоступен, браузер использует прокси proxy1.example.com на порт 8080 :

PROXY w3proxy.example.com:8080; PROXY proxy1.example.com:8080

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

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

Заранее благодарен.

Answer 1

Здоровый пользовательский агент просто заберет первый прокси-сервер, возвращенный файлом PAC, и попробует перенаправить трафик на IP-адрес, возвращаемый для своего доменного имени.

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

• Для первого примера вы можете попробовать использовать 4.2.2.2:80 в качестве первого прокси-сервера и наблюдать. Это NTP-сервер, и он не прослушивает 80, поэтому вы скоро выберете время.

• Для второго примера вы можете попробовать использовать purple.com:80 в качестве первого прокси-сервера. Это обычный веб-сервер. Независимо от того, какие запросы вы отправляете, он будет обслуживать собственную страницу, но средство визуализации файлов PAC не будет пытаться использовать вторичный прокси-сервер, потому что он получает ответ.

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

• Прокси-сервер будет отвечать клиенту и попытаться установить соединение с предполагаемым веб-сервером, и сервер не ответит. Количество попыток, которые прокси-сервер делает для доступа к рассматриваемому веб-ресурсу, и время, в течение которого он поддерживает соединение с клиентом, зависит от реализации прокси-сервиса.

• По истечении определенной продолжительности соединение будет отключено, и пользовательский агент клиента попробует следующий оператор прокси, доступный в файле PAC.

Это был ответ на то, как пользовательский агент, обычно веб-браузер, определяет, жив ли прокси-сервер.

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

HTH!