XMLHttpRequest используется для поиска более быстрого сервера

У меня возникла ситуация, когда моему веб-сайту необходимо быстро получить данные с моего сервера через AJAX.

Мой веб-сайт работает на порту 80 и обслуживает обычные веб-страницы. Обычно я запускаю свой сервер AJAX через порт 8001 (я использую JSONP, и это работает нормально). Это работает для большинства пользователей. Тем не менее, некоторые пользователи заблокированы от высоких портов своими локальными брандмауэрами.

Чтобы позволить людям, у которых исходящие соединения на порту 8001 заблокированы, использовать мой веб-сайт, я хочу вернуться к порту 80 на случай, если пользователь не сможет получить ответ на порту 8001.

Причина, по которой я не использую порт 80 все время, заключается в том, что иногда у людей есть «умные» антивирусные шлюзы или другие брандмауэры уровня приложений, которые перехватывают исходящие соединения через порт 80. Это добавляет пару сотен миллисекунд к моему времени приема-передачи. Моя служба AJAX должна минимизировать время отклика туда и обратно.

Я использую jQuery, чтобы упростить работу с XMLHttpRequest. Я использую вариант JSONP, и эта часть работает — получение запросов AJAX с другого IP-адреса или порта само по себе не является проблемой.

У меня есть идея, что когда страница загружается впервые, она запускает 2 вызова getJSON. Один на порт 8001, а другой на порт 80. В обоих вызовах используется один и тот же обработчик ответов.

Первый вызов обработчика ответа устанавливает мою переменную «portToUse», а затем продолжает работать в обычном режиме.

Это работает, когда порт 8001 не заблокирован. Если порт 8001 заблокирован, это тоже работает. Однако есть задержка около 5 секунд, прежде чем мой ответ от порта 80 вернется. Это не вызвано серверной стороной. Я хотел бы устранить эту задержку.

Моя теория заключается в том, что хотя getJSON является асинхронным, браузер запускает только один XMLHttpRequest за раз. Он ждет, прежде чем первый вернется или истечет время ожидания перед отправкой следующего.

Я не уверен, прав ли я. Если да, то есть ли способ обойти эту функцию и одновременно отключить оба XMLHttpRequest? Если я ошибаюсь, у вас есть предложение относительно того, что может быть причиной задержки получения моего второго ответа (от порта 80 на моем сервере)? Любые другие предложения также приветствуются.

РЕДАКТИРОВАТЬ: такое поведение происходит только в Firefox 3 и Opera 9.63. В IE7 и Chrome такой задержки нет.


person Krystian Cybulski    schedule 21.11.2009    source источник


Ответы (1)


Вызовы AJAX происходят одновременно.

Я бы установил глобальный var portToUse = 80 (по умолчанию) и настроил функцию, которая вызывает порт 8001 для получения очень небольшого количества данных. Если запрос ajax успешно возвращается на 8001, измените portToUse = 8001;

Запросы, которые вы начнете делать немедленно, будут отправляться на 80, пока вы не узнаете, что 8001 открыт. Затем он переключится и все будущие запросы будут делаться на 8001.

Вы также можете сделать это:

var request = $.ajax({ 
                      type: 'POST', 
                      url: 'test.html:8001',
                      success: function(){ portToUse = 8001; }
                     });

setTimeout(function(){

    request.abort();

}, 1000);

Поэтому, если запрос занимает больше секунды, мы отменяем запрос полностью, и ваши запросы продолжают использовать порт 80. Вы можете установить любое значение времени ожидания, в зависимости от того, сколько времени вы хотите разрешить попытку запроса. 500 будет 500 мс и так далее...

person a432511    schedule 21.11.2009
comment
Это может сработать. Однако, если задержка, которую я испытываю в FF, все еще происходит, у меня будет такое поведение: req-> 80: 20 мс, req-> 8001-> никогда не возвращается, 2nd req-> 80: 5020 мс (потому что он был задержан истекло время запроса до 8001), 3-е требование->80:20 мс и т. д. Это тоже было бы неприемлемо. - person Krystian Cybulski; 22.11.2009
comment
тайм-аут в запросе на 8001 не должен влиять на другие ваши запросы. Я собираюсь отредактировать свой ответ и предложить другой подход... - person a432511; 22.11.2009