более новый хром не работает на веб-сокете с использованием сервера haproxy

тестовый сайт http://socket.trailsandtribulations.net

Firefox: v15 работает нормально. (однако, если много трафика и медленная сеть, Firefox также часто будет давать сбои (тихо).)

chrome: раньше работало, но v21 получает Error during WebSocket handshake: 'Connection' header value is not 'Upgrade'

однако, если chrome работает локально, все работает нормально! он ломается на моем клиенте в Таиланде и на сервере в Германии. Опять же, Firefox все время работает правильно, как и более ранние версии Chrome.

используя haproxy для разделения между веб-сокетами через node.js и html через nginx

что-то изменилось, из-за чего это решение не работает?

haproxy.cfg теперь показывает ссылку на тестовый сайт — таким образом, она всегда актуальна.


socket.io google-chrome websocket haproxy
person cc young    schedule 13.09.2012    source источник
comment
какие версии Firefox и Chrome? Было несколько итераций протокола Websocket, и некоторые версии поддерживались и периодически удалялись... так что, возможно, ваша установка работает только для определенных версий. См. en.wikipedia.org/wiki/WebSocket#Browser_support.   -  person abourget    schedule 15.09.2012
comment
@abourget - добавил текущие версии Chrome и Firefox выше. спасибо за ссылку, но не понимаю, что и почему в этой области достаточно, чтобы сделать вмятину, поэтому полагайтесь на большее знание других.   -  person cc young    schedule 15.09.2012

Ответы (2)


arrow_upward
1
arrow_downward

Из вашего сообщения видно, что об ошибке сообщает Chrome, хотя изначально я понял, что об этом сообщает сервер при доступе к Chrome. Я думаю, что в качестве обходного пути, если вы замените «option httpclose» на «option http-server-close», проблема может исчезнуть. Вам также необходимо удалить все «option forceclose». Если есть только «опция http-server-close», haproxy не будет касаться заголовка Connection в пути ответа, что должно порадовать браузер. Однако вы должны иметь в виду, что все еще существует ошибка, при которой отображается ошибка, и о ней следует сообщить авторам программного обеспечения.

Кстати, ваши тайм-ауты слишком велики, в конце дня у вас будет много мертвых соединений, это не имеет смысла. Если вы используете достаточно недавний haproxy, вы можете использовать «туннель тайм-аута», чтобы установить тайм-аут WS, не имея дело с большим тайм-аутом HTTP. Но даже в этом случае 1 день слишком велик для TCP-соединений. Некоторые из ваших пользователей будут использовать смартфоны, где TCP-соединение не может существовать более нескольких минут до передачи обслуживания.

person Willy Tarreau    schedule 13.09.2012
comment
спасибо за ваш ответ - приятно работать с кем-то, кто действительно знает, что происходит. думаю, следовал вашим указаниям, но те же симптомы. можно увидеть текущий haproxy.cfg в ссылке. 1) есть идеи? 2) сообщить авторам софта - вы имеете в виду авторов хрома? - person cc young; 13.09.2012
comment
ваш конфиг выглядит нормально. Ну, есть еще кое-что, что вы можете попробовать, это добавить опцию http-pretend-keepalive в бэкенды. Он сообщит вам, если это сервер недоволен значением закрытия. Что касается авторов программного обеспечения, мне было не совсем понятно, откуда вы взяли сообщение об ошибке, поэтому я говорил о программном обеспечении, выдающем это сообщение об ошибке, которое не соответствует спецификации протокола. - person Willy Tarreau; 15.09.2012
comment
опция http-pretend-keepalive в любом бэкэнде полностью ломает веб-сокеты. Ошибка при рукопожатии Websocket возникла из-за хрома; подали ошибку с ними, но не получил ответа. - person cc young; 15.09.2012

arrow_upward
1
arrow_downward

firefox использует no-cache при запросе обновления веб-сокета; в этой версии хрома нет. см. http://code.google.com/p/chromium/issues/detail?id=148908&thanks=148908&ts=1347523876

для некоторых прокси очевидно это необходимо

также см. https://github.com/sockjs/sockjs-node/pull/88 для связанной проблемы

person cc young    schedule 26.09.2012