|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky Если взять HTTP прокси который не знает про вебсокет ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 04:34 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
skyANA WebSocket - протокол поверх TCP. Читайте спецификацию: https://tools.ietf.org/html/rfc6455 Странно вы как-то её читаете Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 04:36 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Поэтому разбудите меня когда JS через этот ваш уэб-сокет сможет подключаться прямо к серверу IRC, не требуя чтобы кто-то для него работал как прокси. Anatoly Moskovsky он даже уже не текстовый, а бинарный. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 07:38 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky Basil A. Sidorov Метод POST позволяет отправить и получить бинарные данные. Это "100% не HTTP"? В вебсокете нет HTTP заголовков, нет ни POST ни GET. Он в принципе не может быть оберткой над HTTP. Если взять HTTP прокси который не знает про вебсокет, то он не сможет ретранслировать вебсокет - он вернет ошибку клиенту на первом же байте данных после переключения протокола. Что еще не понятно-то? https-прокси не может без злого умысла анализировать трафик, он даже запрос не видит, только адресс сайта по сути дыра в безопасности, от чего уходили с вводом http, к тому и вернулись PS: http-заголовок есть ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 08:08 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Basil A. Sidorov, The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible protocol. Т.е. в в вашей ссылке прямо написано что это уже будет не HTTP )) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 10:15 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
kealon(Ruslan) спокойно проходит, главное что бы прокси поддерживал keep-alive и часто не срывался Это вы с туннелированием через CONNECT путаете. Там кстати тоже уже речь про HTTP не идет после создания туннеля. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 10:25 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Basil A. Sidorov skyANA WebSocket - протокол поверх TCP. Читайте спецификацию: https://tools.ietf.org/html/rfc6455 Странно вы как-то её читаете Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
Я то как раз её нормально читаю, а не только до места, где про handshake. И даже досюда дочитав, можно было обратить внимание на "The protocol has two parts: a handshake and the data transfer." И подумать о том, что же там за вторая часть. И дойти таки до этого: The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 11:06 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky Т.е. в в вашей ссылке прямо написано что это уже будет не HTTP )) Это всё, безусловно не нарушает формальную правильность вашего утверждения, но и смысла в нём не появляется. Ну а WebSocket (с третьей попытки) сделали лентяи, которым лень подумать и понять, что WS-кадрирование можно делать разными способами и что разработка нового протокола - не самый лучший вариант. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 11:32 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
skyANA Я то как раз её нормально читаю, а не только до места, где про handshake. Если описывается инициализация протокола поверх HTTP, то это ещё не означает, что описываемый протокол будет работать поверх TCP. HTTP, если что, требует только "clear 8-bit channel". Over-TCP, Over-Serial или over-Ethernet - дело десятое. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 11:37 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Basil A. Sidorov skyANA Я то как раз её нормально читаю, а не только до места, где про handshake. Если описывается инициализация протокола поверх HTTP, то это ещё не означает, что описываемый протокол будет работать поверх TCP. HTTP, если что, требует только "clear 8-bit channel". Over-TCP, Over-Serial или over-Ethernet - дело десятое. Все начинается так же как в обычном HTTP-запросе. Браузер подключается по протоколу TCP на 80 порт сервера и дает немного необычный GET-запрос: Код: sql 1. 2. 3. 4. 5.
Если сервер поддерживает ВебСокеты, то он отвечает таким образом: Код: sql 1. 2. 3. 4. 5.
Если браузер это устраивает, то он просто оставляет TCP-соединение открытым . Все - «рукопожатие» совершено, канал обмена данными готов. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 11:54 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Basil A. Sidorov Это всё, безусловно не нарушает формальную правильность вашего утверждения, но и смысла в нём не появляется. Смысла там намного больше чем в утверждении что вебсокет работает поверх хттп, которое вы сами же и опровергли )) Basil A. Sidorov Ну а WebSocket (с третьей попытки) сделали лентяи, которым лень подумать и понять, что WS-кадрирование можно делать разными способами и что разработка нового протокола - не самый лучший вариант. В HTTP невозможно реализовать p2p протокол такой как вебсокет. Подумайте сами почему. Уверен, что вы найдете ответ в спеке, как и на предыдущий вопрос )) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 12:14 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky kealon(Ruslan) спокойно проходит, главное что бы прокси поддерживал keep-alive и часто не срывался Это вы с туннелированием через CONNECT путаете. Там кстати тоже уже речь про HTTP не идет после создания туннеля. htеps-прокси НЕ СЛЕДИТ ЗА ТЕМ КТО И ЧТО ОТПРАВЛЯЕТ, он просто поддерживает переброску если ему сказали что нужно держать соедение как можно возможно дольше, он это и будет делать метод Connect к этому отношения не имеет ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 12:59 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
kealon(Ruslan) htеps-прокси НЕ СЛЕДИТ ЗА ТЕМ КТО И ЧТО ОТПРАВЛЯЕТ, он просто поддерживает переброску если ему сказали что нужно держать соедение как можно возможно дольше, он это и будет делать Удачи, вам еще многое предстоит открыть )) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 13:15 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky, вы нормально для себя поделите, о чём вы говорите прокси ничего не реализует кроме авторизации и проксирования обычный древний IIS который, с отключенным CONNECT, свободно тунелит WebSocket вообще о нём ничего не зная - это 7 лет назад я спокойно делал а в веб-сервер естественно надо функционал такой добавлять, сам он не появится ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 13:38 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
kealon(Ruslan) обычный древний IIS который, с отключенным CONNECT, свободно тунелит WebSocket вообще о нём ничего не зная - это 7 лет назад я спокойно делал Потому что большинство прокси умеют переключаться с HTTP на двусторонний бинарный релей при нарушении протокола. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 13:58 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
skyANA Браузер подключается по протоколу TCP на 80 порт сервера и дает немного необычный GET-запрос: Что в нём необычного? HTTP спецификация ЕМНИП допускает в запросе (и ответе) заголовки, не описанные в ней, а сам GET там абсолютно нормальный. Вся "поддержка" от браузера состоит в том, что он передаёт JS принятые данные не буферизуя и не пытаясь их парсить. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 14:29 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Вся "поддержка" от браузера состоит в том, что он передаёт JS принятые данные не буферизуя и не пытаясь их парсить. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 14:43 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky kealon(Ruslan) обычный древний IIS который, с отключенным CONNECT, свободно тунелит WebSocket вообще о нём ничего не зная - это 7 лет назад я спокойно делал Потому что большинство прокси умеют переключаться с HTTP на двусторонний бинарный релей при нарушении протокола. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 15:01 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
kealon(Ruslan) простой вопрос для HTTPS: какого протокола? TLS? как же он должен это сделать? HTTP. Тут два варианта (если отбросить CONNECT). 1 Прозрачный прокси, когда трафик перехватывается на пути к серверу. В этом случае после установки соединения прокси ждет HTTP запрос (по plain TCP), а клиент присылает TLS handshake, прокси видит что это не HTTP и просто устанавливает двусторонний релей по plain TCP между сервером и клиентом. Содержимое соединения ему недоступно. (С CONNECT то же самое происходит явной командой клиента.) 2 Обратный прокси, когда клиент соединяется прямо к прокси, а прокси имеет TLS сертификат сервера и обрабатывает запросы клиента от имени сервера. В этом случае клиент и прокси устанавливают TLS соединение. Прокси при этом читает и выполняет индивидуальные сообщения HTTP over TLS. В случае вебсокета клиент выполняет Upgrade в вебсокет, и если прокси не в курсе про вебсокет то после ответа сервера 101 клиент присылает бинарные данные протокола вебсокет, и в этот момент прокси переключается на двусторонний релей по TLS между сервером и клиентом. В обоих случаях прокси переключается на релей когда обнаруживает что это не протокол HTTP. Просто в первом случае прокси не может видеть трафик, а во втором может. Так что к моменту когда начинаются данные вебсокета, текущий протокол уже не HTTP. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 15:33 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
вадя этого мало? Мало, конечно. Для того чтобы написать уже упомянутый IRC клиент на JS в браузере - тот вообще не должен никак ограничивать соединение и поток, предоставляя тот же интерфейс и возможности, что и BSD сокеты. Вот тогда-то меня и разбудите. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 15:46 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov упомянутый IRC клиент на JS в браузере - ещё в самом начале появления ws было известно, что через старое ПО он не везде проходит, но wss ходит везде. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 15:57 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky, 1. ну и что, это не базовая функция прокси в случае https? с чего ему её блокировать? 2. а вот это уже называется "атака посередине" и к нормальному функционированию прокси отношения не имеет ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 16:02 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
kealon(Ruslan) 2. а вот это уже называется "атака посередине" и к нормальному функционированию прокси отношения не имеет В режиме обратного прокси с TLS работает весь интернет в наше время. Слово CDN надеюсь вам знакомо? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 16:06 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
kealon(Ruslan) 1. ну и что, это не базовая функция прокси в случае https? с чего ему её блокировать? Да пожалуйста не блокируйте. Только не нужно это называть HTTP. Потому что там его нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 16:09 |
|
Стратегия синхронизации данных между frontEnd и backEnd
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov . Вот тогда-то меня и разбудите. По стандарту, сообщение IRC не может иметь длину больше 510 байтов, из которых собственно на текст приходится никак не больше 499 (по нереалистично завышенной оценке). Следовательно, отправить в одном сообщении больше 249 русских букв оказывается невозможно. Ограничение размера сообщений вызывает ещё одну неприятность: при попытке превысить установленный предел сервер обрезает сообщения. Если срез пройдёт посередине русской буквы (то есть будет передан первый её байт, но отброшен второй), то получившаяся последовательность байтов перестанет, с точки зрения UTF-8, быть правильной строкой. кода в ws нет ограничения ни в длине , ни в типе передаваемых данных. так что спи - и не лезь в современную реальность. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 16:20 |
|
|
start [/forum/search_topic.php?author=slider_by&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
161ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
others: | 439ms |
total: | 735ms |
0 / 0 |