ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Стратегия синхронизации данных между frontEnd и backEnd
16 сообщений из 66, страница 3 из 3
  3  все
Стратегия синхронизации данных между frontEnd и backEnd
    #40003558
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Dimitry Sibiryakov
skyANA
Браузер подключается по протоколу TCP на 80 порт сервера и дает немного необычный GET-запрос:

Что в нём необычного?

До конца прочитать сообщение не судьба?
...
Рейтинг: 0 / 0
28.09.2020, 17:08
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003625
Алексей Роза 2020
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей Роза 2020
Гость
вадя
По стандарту, сообщение IRC не может иметь длину больше 510 байтов, из которых собственно на текст приходится никак не больше 499 (по нереалистично завышенной оценке).

Следовательно, отправить в одном сообщении больше 249 русских букв оказывается невозможно.

с пробелами и ASCii знаками препинания ~300+
...
Рейтинг: 0 / 0
28.09.2020, 18:47
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003651
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
skyANA
Если сервер поддерживает ВебСокеты
Я не случайно дал ссылку на трижды устаревший RFC2068 (январь 1997 года). Никаких вебсокетов тогда не было даже в проекте, но Upgrade-механизм там уже определён. То, что Websocket задействовал именно этот механизм - вполне логично, для протокола, работающего поверх HTTP.
Но, в любом случае, работа HTTP поверх TCP определёна, а работа WS поверх TCP - нет: начальное подключение делается к HTTP-серверу.
Принципиальная разница в том, что для WS-over-TCP требуется поддержка WS-протокола не только для целевого сервера, но и для промежуточных узлов, а вот WS-over-HTTP - прозрачно работает поверх уже существующей HTTP/1.1-инфраструктуры. И развёртывать его можно "точечно" - только на конечных узлах.
...
Рейтинг: 0 / 0
28.09.2020, 20:02
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003652
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Anatoly Moskovsky
В HTTP невозможно реализовать p2p протокол такой как вебсокет. Подумайте сами почему.
То, что ограниченность вашего ума не позволяет увидеть вполне очевидное решение - исключительно ваши проблемы.
...
Рейтинг: 0 / 0
28.09.2020, 20:05
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003653
Алексей Роза 2020
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей Роза 2020
Гость
работа через HTTP подразумевает отправку хедеров серверу, чего ws делает только для рукопожатия, а потом работает сам, просто используя канал, чтобы из бекенда напрямую в JS клиенту передать данные.
...
Рейтинг: 0 / 0
28.09.2020, 20:06
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003654
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Anatoly Moskovsky
1 Прозрачный прокси, когда трафик перехватывается на пути к серверу. В этом случае после установки соединения прокси ждет HTTP запрос (по plain TCP), а клиент присылает TLS handshake, прокси видит что это не HTTP и просто устанавливает двусторонний релей по plain TCP между сервером и клиентом.
Вы, эта, спецификацию почитайте ...

P.S.
Прозрачный прокси - некоторый хак и с HTTP он слабо связан. Это даже если забыть, что прозрачное проксирование не всегда возможно.
...
Рейтинг: 0 / 0
28.09.2020, 20:15
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003686
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
Basil A. Sidorov
Вы, эта, спецификацию почитайте ...

P.S.
Прозрачный прокси - некоторый хак и с HTTP он слабо связан. Это даже если забыть, что прозрачное проксирование не всегда возможно.

Я там отвечал чуваку почему у него прокси не HTTP проксировал, как он пытался мне рассказать.
По делу есть что сказать?
...
Рейтинг: 0 / 0
28.09.2020, 21:44
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003708
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
Anatoly Moskovsky
kealon(Ruslan)
2. а вот это уже называется "атака посередине" и к нормальному функционированию прокси отношения не имеет

В режиме обратного прокси с TLS работает весь интернет в наше время.
Слово CDN надеюсь вам знакомо?
это путанье тёплого с мягким
если у прокси-сервера нету "доверительных отношений" с "интересным мне сервером", то он не может легально лезть в мой трафик
и либо он пропускает в соответствии со стандартом, либо обрезает на основании своих предпочтений - т.е. https просто тупо не работает
...
Рейтинг: 0 / 0
28.09.2020, 23:43
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003710
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
kealon(Ruslan),

Ну, то есть понимания как работают CDN нет. ОК)
...
Рейтинг: 0 / 0
28.09.2020, 23:53
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003730
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Anatoly Moskovsky
По делу есть что сказать?
Да. Вы отвечали на совершенно другой вопрос, которого вам никто не задавал.
"Прямое" проксирование TLS (уже давно) делается в рамках RFC2817.
"Прозрачное" и "обратное" проксирование - два совершенно других режима для несколько других задач.
...
Рейтинг: 0 / 0
29.09.2020, 05:40
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003754
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
Anatoly Moskovsky
kealon(Ruslan),

Ну, то есть понимания как работают CDN нет. ОК)
ну давайте блесните, расскажите как CDN-сервер закешируют инфу с любого https-сайта:-)
...
Рейтинг: 0 / 0
29.09.2020, 08:39
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003842
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
Basil A. Sidorov
"Прямое" проксирование TLS (уже давно) делается в рамках RFC2817.

Вот этот RFC это устаревший костыль, который не применяется с тех пор как в SSL появился SNI и ALPN, т.е. оно умерло почти сразу при рождении.
...
Рейтинг: 0 / 0
29.09.2020, 10:47
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003847
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
kealon(Ruslan)
как CDN-сервер закешируют инфу с любого https-сайта

Я же говорю, нет понимания.
У CDN-сервера нет задачи кешировать любой сайт.
Это просто кластер обратных прокси для набора конкретных доменов, и каждый из этих доменов полностью под контролем CDN (включая SSL сертификаты), пока DNS делегирует обслуживание этих доменов в эту CDN.
...
Рейтинг: 0 / 0
29.09.2020, 10:57
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40003959
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Anatoly Moskovsky
Только не нужно это называть HTTP. Потому что там его нет.

Если что-то выглядит как утка, крякает как утка и ходит как утка, то это утка.
Если в протоколе прикладного уровня засветился заголовок, соответствующий спецификации HTTP и обойтись без него нельзя, то это HTTP.
...
Рейтинг: 0 / 0
29.09.2020, 13:55
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40004068
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
Anatoly Moskovsky
kealon(Ruslan)
как CDN-сервер закешируют инфу с любого https-сайта

Я же говорю, нет понимания.
У CDN-сервера нет задачи кешировать любой сайт.
Это просто кластер обратных прокси для набора конкретных доменов, и каждый из этих доменов полностью под контролем CDN (включая SSL сертификаты), пока DNS делегирует обслуживание этих доменов в эту CDN.
это его основная задача вообще-то.
...
Рейтинг: 0 / 0
29.09.2020, 17:02
| Ответить | Цитировать | Написать  
Стратегия синхронизации данных между frontEnd и backEnd
    #40004116
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Anatoly Moskovsky
Вот этот RFC это устаревший костыль, который не применяется с тех пор как в SSL появился SNI и ALPN, т.е. оно умерло почти сразу при рождении.
Опять вы про Ерёму ...
Есть выделенный для SSL (TLS) подключений порт (443 и https-схема) и есть проблема организации виртуального хостинга для https.
А есть проблема переключения с http на https или любой другой (прикладной) протокол.
А у вас люди с конями на Бородинской битве.
...
Рейтинг: 0 / 0
29.09.2020, 19:04
| Ответить | Цитировать | Написать  
16 сообщений из 66, страница 3 из 3
  3  все
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Стратегия синхронизации данных между frontEnd и backEnd
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=16&msg=40003686&tid=1339735]:
 0ms
get settings:
 11ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 162ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 53ms
get tp. blocked users:
 1ms
others: 16ms
total:  278ms
созд. / загр.: 278ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]