Комментарии 12
>Однако, стоит проверять заголовок referrer, чтобы убедиться, что именно ваш клиент осуществляет такие запросы, для безопасности вашего сайта.
Под стулом
Под стулом
Voxlite является веб 2.0 приложение
приложением
"Преимущества балансировки на стороне клиента..."
По-моему все это применительно и к серверу, только геморроя меньше по той причине, что давно существуют готовые решения, вроде того же nginx, как конечного продукта.
Почему нет минусов?
Балансировка на стороне клиента требует доп. кода, доп. времени ожидания для клиента (если произошел таймаут, и запрос должен идти на другой сервер) + хаки с кросс-доменностью.
В итоге платим ту же цену, если не больше...
Или может я что-то пропустил, и в этом все-таки есть рациональное зерно?
По-моему все это применительно и к серверу, только геморроя меньше по той причине, что давно существуют готовые решения, вроде того же nginx, как конечного продукта.
Почему нет минусов?
Балансировка на стороне клиента требует доп. кода, доп. времени ожидания для клиента (если произошел таймаут, и запрос должен идти на другой сервер) + хаки с кросс-доменностью.
В итоге платим ту же цену, если не больше...
Или может я что-то пропустил, и в этом все-таки есть рациональное зерно?
Большое спасибо за перевод. Посмотрел оригинал, почитал комменты. Автор признает, что есть проверенные временем server-side решения, и они обкатаны, и они работают. У меня сложилось впечатление, что ему эта тема интересна как фича ради фичи. Т.е. раз есть теоретическая (а местами даже практическая, как видно из примеров) возможность сделать такую реализацию, значит надо ее сделать. Похоже, что реально он не имел дела с большими системами, и готов поменять единообразное и подконтрольное server-side решение на зоопарк клиентского софта, приперченный хаками. Иногда энтузиасты с горящими глазами могут быть опасны :))
За статью спасибо, но перевод "кривоват", очень тяжело читать.
Литературное терпение переводчика закончилось примерно в этом месте: "Хотя сервер обеспечивает такие ресурсы, как картинки, в современным веб-технологиях и этот факт существенно меняется"
Литературное терпение переводчика закончилось примерно в этом месте: "Хотя сервер обеспечивает такие ресурсы, как картинки, в современным веб-технологиях и этот факт существенно меняется"
сухо, бредово. Балансировка должна осуществляться на стороне сервера.
мда. А как же DDOS? Если клиенты будут иметь доступ к каждому серверу - каждый сервер может быть сломан. Злоумышленник вообще может отдосить все сервера один за другим.. =).
Несмотря на то, что сложновато было читать, было достаточно интересно, спасибо. По этой теме встречал мало обзоров.
P.S.: У вас ошибка в коде (<server> s1.myloadbalancedwebsite.com >/server<), закрывающий тег не совсем валиден :)
P.S.: У вас ошибка в коде (<server> s1.myloadbalancedwebsite.com >/server<), закрывающий тег не совсем валиден :)
по-моему это все глупо по одной лишь причине:
клиентское приложение нужно изначально загрузить с сервера, и уж если он лежит, то все труды по клиентской балансировке до этого самого клиента просто не дойдут.
а если серверная балансировка нужна обязательно, то необходимость балансировки клиентской уже ставится под сомнение...
зы: сорри за поднятие старой темы
клиентское приложение нужно изначально загрузить с сервера, и уж если он лежит, то все труды по клиентской балансировке до этого самого клиента просто не дойдут.
а если серверная балансировка нужна обязательно, то необходимость балансировки клиентской уже ставится под сомнение...
зы: сорри за поднятие старой темы
:) как показал Client Side, проблема актуальна
Все сложности начинаются там, где за первой страницей/картинкой клиент захочет увидеть десятую, а потом и сотую. А если у вас веб-приложение, а не веб-сайт, там число запросов вообще тысячами можно измерять
Все сложности начинаются там, где за первой страницей/картинкой клиент захочет увидеть десятую, а потом и сотую. А если у вас веб-приложение, а не веб-сайт, там число запросов вообще тысячами можно измерять
нет, нет, я понимаю. пожалуй, слишком резко сказал, признаю
однако использование клиентского баланса как полного решения проблемы нагрузок (автор как раз на этом настаивает, как мне кажется) слишком самоуверенно )
и минусы в статье указать действительно стоит.
а как идея - хорошо; может придется использовать, надо смотреть на нагрузки
однако использование клиентского баланса как полного решения проблемы нагрузок (автор как раз на этом настаивает, как мне кажется) слишком самоуверенно )
и минусы в статье указать действительно стоит.
а как идея - хорошо; может придется использовать, надо смотреть на нагрузки
Если вы хоть сколько-нибудь работали с AJAX, то, наверное, подумали: «Это не будет работать по причине кросс-доменной безопасности» (прим.: для предотвращения XSS-атак). Давайте рассмотрим и этот вопрос.
Применение техники Dynamic script Tag для осуществления запросов позволяет обойти ограничения по безопасности, ибо разрешает кросс-доменные вызовы.Можно разрешить проблему намного проще. Информация с http://xmlhttprequest.ru :
Кросс-доменные запросы между наддоменами httр://a.site.com, httр://b.site.com на httр://site.com допустимы, через свойство document.domain, которое надо установить в site.com
// на странице a.site.com
...
document.domain='site.com'
...
// все, теперь могу делать XmlHttpRequest на site.com
req.open("POST", 'http://site.com/giveme.php')
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практический JS: балансировка на стороне клиента