Здравствуйте, b0r3d0m, Вы писали:
B>Тут вдруг подумалось.
B>А в чём, собственно, заключается проблема иметь функции для работы с TCP / UDP сокетами в API браузеров? Какие-то security reasons?
B>Да, знаю, что есть WebSockets, но всё же.
Как обычно: хорошая мысля приходит опосля + думали http хватит всем и для всего.
S>Как обычно: хорошая мысля приходит опосля + думали http хватит всем и для всего.
Верно, прошло дофига времени. Так почему же после такого кол-ва времени всё равно решили изобрести абсолютно новый стандарт (WebSockets) вместо добавления уже проверенных временем BSD Sockets? Ну да, они удобны, не спорю, но потребовалось много времени для их стандартизации и внедрения в браузеры. Мне кажется, с BSD Sockets было бы несколько проще.
Здравствуйте, b0r3d0m, Вы писали:
S>>Как обычно: хорошая мысля приходит опосля + думали http хватит всем и для всего.
B>Верно, прошло дофига времени. Так почему же после такого кол-ва времени всё равно решили изобрести абсолютно новый стандарт (WebSockets) вместо добавления уже проверенных временем BSD Sockets? Ну да, они удобны, не спорю, но потребовалось много времени для их стандартизации и внедрения в браузеры. Мне кажется, с BSD Sockets было бы несколько проще.
Про BSD Sockets не скажу (скорее всего секурность, и этим все сказано), а собственно какая разница , если вебсокеты стали уже фактически стали частью стандарта, т.е http 2.0.
Здравствуйте, b0r3d0m, Вы писали:
B>А в чём, собственно, заключается проблема иметь функции для работы с TCP / UDP сокетами в API браузеров? Какие-то security reasons?
Сейчас js может делать http запросы только к своему домену (https://en.wikipedia.org/wiki/Same-origin_policy), если страничка делает запрос к чужому домену, то js не может получить результаты запроса. Еще обязательно возникнут проблемы с web proxy, поэтому те же веб сокеты работают поверх http(s). В общем, BSD сокеты — огромная дырища в безопасности, представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще. В общем, вопрос крайне наивный. Такого не будет никогда.
CK>Сейчас js может делать http запросы только к своему домену (https://en.wikipedia.org/wiki/Same-origin_policy)
Да и ладно, пускай только к своему же домену и разрешили бы.
CK>В общем, BSD сокеты — огромная дырища в безопасности, представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще
В чём проблема ограничить это на уровне браузера? Грубо говоря, запрещать все обращения вне того же домена.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Сейчас js может делать http запросы только к своему домену (https://en.wikipedia.org/wiki/Same-origin_policy), если страничка делает запрос к чужому домену, то js не может получить результаты запроса.
Это связано с тем, что при HTTP-запросах отправляются куки.
> Еще обязательно возникнут проблемы с web proxy, поэтому те же веб сокеты работают поверх http(s).
Ну у кого прокси, у того и проблемы. Некоторые прокси позволяют прокидывать произвольные соединения.
> В общем, BSD сокеты — огромная дырища в безопасности
В чём дырища-то?
> представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще. В общем, вопрос крайне наивный. Такого не будет никогда.
Коннекты на локальные IP-адреса можно запретить, это разумно. А в чём проблема коннектов на внешние адреса?
vsb>Коннекты на локальные IP-адреса можно запретить, это разумно. А в чём проблема коннектов на внешние адреса?
Любая уязвимость типа "внедрение javascript", мгновенно превращает посетителей любого сайта в большой ботнет, которым можно досить, скликивать рекламу, накликивать посещаемость и т.п.
Здравствуйте, hi_octane, Вы писали:
vsb>>Коннекты на локальные IP-адреса можно запретить, это разумно. А в чём проблема коннектов на внешние адреса? _>Любая уязвимость типа "внедрение javascript", мгновенно превращает посетителей любого сайта в большой ботнет, которым можно досить, скликивать рекламу, накликивать посещаемость и т.п.
Это и сейчас можно делать. Добавляешь тег <img src="http://rsdn.ru/"/> на какую-нибудь lenta.ru и получаешь ддос. И рекламу скликивать можно, и POST-ы делать. Нельзя только читать ответ от такого запроса. Но ДДОСу это не мешает.
Здравствуйте, vsb, Вы писали:
>> представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще. В общем, вопрос крайне наивный. Такого не будет никогда. vsb>Коннекты на локальные IP-адреса можно запретить, это разумно. А в чём проблема коннектов на внешние адреса?
1. У IP адресов нет имени хоста (в понимании http) -> same-origin policy едет лесом, как и хостинг нескольких сайтов на одном IP.
2. Кто это такие "внешние адреса"? Например хосты в моем LAN — внешние? Узлы доступные через VPN — внешние? Откуда ты знаешь какой у меня роутинг и кто и по каким маскам в какой интерфейс попадает.
3. (Ну и ещё больше) Допустим, что мой реальный IP адрес находится в белом списке на внешнем хосте. Это в свою очередь просто даёт возможность законнектится на хост через telnet/ssh/whatever. Таким образом теперь к нему уже может законнектится бот. Вместо whatever подставьте например безпарольный dev или что тоже может быть — продакшн сервис. Оно надо?
Здравствуйте, fddima, Вы писали:
>>> представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще. В общем, вопрос крайне наивный. Такого не будет никогда. vsb>>Коннекты на локальные IP-адреса можно запретить, это разумно. А в чём проблема коннектов на внешние адреса?
F> 1. У IP адресов нет имени хоста (в понимании http) -> same-origin policy едет лесом, как и хостинг нескольких сайтов на одном IP.
Ничего не понял. Можно подробней. Я не предлагал ограничивать соединения исходным сайтом. Конечно же любой сайт может коннектиться к любому внешнему IP-адресу.
F> 2. Кто это такие "внешние адреса"? Например хосты в моем LAN — внешние? Узлы доступные через VPN — внешние? Откуда ты знаешь какой у меня роутинг и кто и по каким маскам в какой интерфейс попадает.
Это внутренние. Остальные внешние. Твой роутинг никого не интересует.
F> 3. (Ну и ещё больше) Допустим, что мой реальный IP адрес находится в белом списке на внешнем хосте. Это в свою очередь просто даёт возможность законнектится на хост через telnet/ssh/whatever. Таким образом теперь к нему уже может законнектится бот. Вместо whatever подставьте например безпарольный dev или что тоже может быть — продакшн сервис. Оно надо?
Надуманная проблема. Хочешь ограничить — ставь нормальную защиту. Твоё описание это не защита, а фарс.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Сейчас js может делать http запросы только к своему домену (https://en.wikipedia.org/wiki/Same-origin_policy), если страничка делает запрос к чужому домену, то js не может получить результаты запроса. Еще обязательно возникнут проблемы с web proxy, поэтому те же веб сокеты работают поверх http(s). В общем, BSD сокеты — огромная дырища в безопасности, представь что ты зашел на страничку, на страничке js который может вообще к чему угодно приконнектиться, видит все что находится в твоей сети через твой локальный multicast dns и передает это на сайт или куда-нибудь еще. В общем, вопрос крайне наивный. Такого не будет никогда.
Проснись, тебя уже обокрали — через веб-странички можно взламывать локальные роутеры и т.п.
https://en.wikipedia.org/wiki/Cross-site_request_forgery
Customers of a bank in Mexico were attacked in early 2008 with an image tag in email. The link in the image tag changed the DNS entry for the bank in their ADSL router to point to a malicious website impersonating the bank
Здравствуйте, vsb, Вы писали:
F>> 1. У IP адресов нет имени хоста (в понимании http) -> same-origin policy едет лесом, как и хостинг нескольких сайтов на одном IP. vsb>Ничего не понял. Можно подробней. Я не предлагал ограничивать соединения исходным сайтом. Конечно же любой сайт может коннектиться к любому внешнему IP-адресу.
Виртуальный хостинг. У меня на одном IP — висит 3 веб приложения. Сокеты без выделения портов разумеется прозрачно этого не могут — это банально неудобно. Там где реально нужны сокеты — люди просто делают приложения на сокетах. WebSockets же хватает головой для JS/сайтов, тем более что вся кухня сериализации сообщений уже реализована и спрятана, и не нужно ломать голову.
F>> 2. Кто это такие "внешние адреса"? Например хосты в моем LAN — внешние? Узлы доступные через VPN — внешние? Откуда ты знаешь какой у меня роутинг и кто и по каким маскам в какой интерфейс попадает. vsb>Это внутренние. Остальные внешние. Твой роутинг никого не интересует.
Правильно, мой роутинг — мой — поэтому нечего сайтикам лазить по любым IP адресам, — кто из них кто — он всё равно не знает, но потенциально может соединяться с теми узлами с кем не следует.
F>> 3. (Ну и ещё больше) Допустим, что мой реальный IP адрес находится в белом списке на внешнем хосте. Это в свою очередь просто даёт возможность законнектится на хост через telnet/ssh/whatever. Таким образом теперь к нему уже может законнектится бот. Вместо whatever подставьте например безпарольный dev или что тоже может быть — продакшн сервис. Оно надо? vsb>Надуманная проблема. Хочешь ограничить — ставь нормальную защиту. Твоё описание это не защита, а фарс.
Это вполне обычные правила. Наличие/отсутствие пароля здесь второстепенно. В локальной сети администратор может иметь бОльший прямой доступ по LAN — и банальные коннекты у него работают, когда у других юзеров сети — нет. Таким образом просто произвольный код, о наличии которого при посещении сайта ты даже не знаешь — начинает совершать какие-то коннекты. Криво или нет — это тоже другой вопрос. Такое делают и часто.
Здравствуйте, fddima, Вы писали:
F>>> 1. У IP адресов нет имени хоста (в понимании http) -> same-origin policy едет лесом, как и хостинг нескольких сайтов на одном IP. vsb>>Ничего не понял. Можно подробней. Я не предлагал ограничивать соединения исходным сайтом. Конечно же любой сайт может коннектиться к любому внешнему IP-адресу. F> Виртуальный хостинг. У меня на одном IP — висит 3 веб приложения. Сокеты без выделения портов разумеется прозрачно этого не могут — это банально неудобно. Там где реально нужны сокеты — люди просто делают приложения на сокетах. WebSockets же хватает головой для JS/сайтов, тем более что вся кухня сериализации сообщений уже реализована и спрятана, и не нужно ломать голову.
Яснее мне не стало, почему same-origin policy или хостинг нескольких сайтов едет лесом от этой фичи. Где реально нужны сокеты — сделать ничего нельзя. Попробуй сделать торрент-клиент на JavaScript, работающий в браузере и коннектящийся по стандартному торрент-протоколу к другим клиентам.
F>>> 2. Кто это такие "внешние адреса"? Например хосты в моем LAN — внешние? Узлы доступные через VPN — внешние? Откуда ты знаешь какой у меня роутинг и кто и по каким маскам в какой интерфейс попадает. vsb>>Это внутренние. Остальные внешние. Твой роутинг никого не интересует. F> Правильно, мой роутинг — мой — поэтому нечего сайтикам лазить по любым IP адресам, — кто из них кто — он всё равно не знает, но потенциально может соединяться с теми узлами с кем не следует.
У 99.999% пользователей роутинг соответствует стандартам и этой проблемы нет. Конкретно ты можешь такую фичу отключить или скомпилировать браузер без него. Это не аргумент, чтобы ограничивать функционал.
F> Это вполне обычные правила. Наличие/отсутствие пароля здесь второстепенно. В локальной сети администратор может иметь бОльший прямой доступ по LAN — и банальные коннекты у него работают, когда у других юзеров сети — нет. Таким образом просто произвольный код, о наличии которого при посещении сайта ты даже не знаешь — начинает совершать какие-то коннекты. Криво или нет — это тоже другой вопрос. Такое делают и часто.
LAN это внутренние адреса. Ограничивать доступ к ним можно, проблем нет. Если ты в LAN используешь публичные адреса, проблема тут явно не в браузере.
В целом ради бога, но зачем это надо — неясно. Тот же торрент клиент на яваскрипт — уже требует доступ к фс. JS — нихрена не быстрый. И вообще веббраузер сейчас — песочница какая никакая, сокеты же неконтролируемы без доп средств. Они одним несложным циклом просто закончатся на клиенте. Да еще за прокси не ходит. Легче прикрутить AJAX + Long Polling, WebSockets нежели городить что-то, что изначально обречено на провал в вебе. Кроме того websockets именно как протокол мало чем ограничивает тебя, в смысле — бинарные сообщения — пожалуйста, двунаправленность и т.п. Это же тот же прикладной сокет, но уже с готовыми своими кадрами/сообщениями, и если не путаю мультиплексированием. Для клиентских веб приложений как раз самое оно, но этим не ограничивается же.
В хроме например remote debugging protocol (devtools) как раз на вебсокетах и построен, выбор вполне ясен. При том in-proc использует те же сообщения, но мимо websocket транспорта. Че еще надо-то? В вебе? Торрент?! Хватит ерундой маяться.
Здравствуйте, vsb, Вы писали:
vsb>Яснее мне не стало, почему same-origin policy или хостинг нескольких сайтов едет лесом от этой фичи. Где реально нужны сокеты — сделать ничего нельзя. Попробуй сделать торрент-клиент на JavaScript, работающий в браузере и коннектящийся по стандартному торрент-протоколу к другим клиентам.
Несравненно более сложную вещь, чем торрент-протокол — давно сделали. WebRTC для видео и аудио, p2p. Да, оно не работает без посредника, но и торренту для начала работы требуется некий внешний трекер.
.
Тему ту читал как-то долго и нудно. Хорошие результаты в определенных случаях — не показатель сам по себе. Есть куча JS кода который ставит раком JS оптимизаторы. Они все растут и растут, но как только ты попадешь на честный проперти лукап или сканирование цепочки прототипов — чудеса чудесатые резко и больно закончатся. В последних V8 правда он возможно и это прожует. Кроме того бедная система типов не позволяет нормально работать со многими данными. Конечно, написать/скомпилировать в обфусцированный код (я имею ввиду нецелевые применения всяческих типизированных массивов и прочих конструкций) — это хорошо, но по прежнему не везде все применимо.
Если JS/V8/other работают быстрее нормального C++ кода, то скорее всего проблема в C++ коде.
Здравствуйте, fddima, Вы писали:
F>Есть куча JS кода который ставит раком JS оптимизаторы. Они все растут и растут, но как только ты попадешь на честный проперти лукап или сканирование цепочки прототипов — чудеса чудесатые резко и больно закончатся.
Этого всё не нужно в случае использования JS в качестве "байткода" VM (который и генерируется при компиляции C++ -> JS) — и такой байткод очень быстр (asm.js).
Это я к тому, что JS можно рассматривать как VM/платформу, а не как язык для непосредственного написания кода вручную — и в этом случае результирующее приложение может быть очень быстрым.
F> Если JS/V8/other работают быстрее нормального C++ кода, то скорее всего проблема в C++ коде.
Я сказал что он быстрее аналогичного C# кода, а не C++.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Этого всё не нужно в случае использования JS в качестве "байткода" VM (который и генерируется при компиляции C++ -> JS) — и такой байткод очень быстр (asm.js).
V8 о asm.js вроде ж как продолжает ничего не знать о asm.js. А работает довольно хорошо и без. Но, тут я согласен.
EP>Это я к тому, что JS можно рассматривать как VM/платформу, а не как язык для непосредственного написания кода вручную — и в этом случае результирующее приложение может быть очень быстрым.
Тут — опять да, ты прав. Вместе с тем V8 (я работал только с ним), не такой уж идеальный и не уверен во что именно выльется интероп (мы обсуждали ж это уже?). Не все ж одни числодробилки, да и как он будет себя вести — не знаю. Плюс, хром явно собирается с PGO оптимизациями. Насколько мне известно только это дает прирост в V8 на 10-20%, данные старые. Я к тому, что кусок довольно вылизанный --> дает более хорошие результаты чем в среднем по палате.
Хотя говорить о JS именно как о JS VM мне не кажется корректным. В смысле все же в вебе — пока наверное больше исполняется кода фреймворков. :D
Но я смотрю на это немного по другому: банальная страница (мы ж про веб) — это хрен знает что. 20-30 фреймов от ads, кучи беспорядочных включений и самых замысловатых использований, тут тебе и какие-то загадочные setInterval fn 100ms, где fn через jquery выбирает фантастические селекторы. И таймеров таких — штук 30 и их никто не стопает. Я по долгу службы часто анализирую страницы, поэтому насмотрелся всякого. Я уверен, что у тебя бы на странице такой ерунды не было бы. Но если мы внедряем чужой iframe — мы уже имеем шансы того, что нас прерывают по таймеру на неизвестное время. Я скорее в этом смысле. Бардачище. Правда, что странно — работает.
Ну а для торрента... там даже не знаю чистый или не чистый i/o bound. uTorrent у меня скачивая на скорости 10MBps проц почти не кушает.
На современном компе все быстро. А попадаешь за машину послабее — тормоза ощутимы везде, и торренты в браузерах не кажутся хорошей идеей. Вообще браузеры кажутся хреновой идеей. Хотя как прогреются — так и хороши снова.
EP>Я сказал что он быстрее аналогичного C# кода, а не C++.
Фейспалм мне. Сорри, поздно — затупил.
, если вебсокеты стали уже фактически стали частью стандарта, т.е http 2.0.
