Сергей Протько

Чем отличаются TCPсокеты (которые я сейчас использую) от WebSockets,что лучше?

websockets - это протокол, который позволяет вам организовать соединение с сервером. websockets работают поверх TCP и это единственный способ открыть двусторонний канал с сервером (ну как... еще WebRTC предоставляет P2P каналы, но это чуть другая плюшка).

откуда мы аяксом дергаем данные в скрипт.

смысл тогда в сокетах?

Можно ли обойтись без аякса,реализовать это через сокеты?

websockets и есть ответ на ваш вопрос.

Все просто, пусть nginx проксирует все websockets запросы с 80-ого порта на порт вашего приложения. Забрать значение из ENV вы можете. Так же вы можете сделать запрос на сервер что бы забрать порт.

В примере же порт не указывается потому что на этом же порту работает и приложение. Оно просто берет текущий хост (доменное имя + порт).

профилирование и нагрузочные тесты!

Вы же понимаете что все от реализации зависит.

Faye насколько я помню для pub/sub между ruby и node.js используют, нет? То есть чатик у вас будет на node.js а на ruby аутентификация и авторизация?

Вообще 100 человек онлайн на websockets даже на ruby осилит простенькая VPS баксов за 5 спокойно. Но все можно запороть заблокировав сервак проверкой на авторизацию или еще каким бредом.

Если вы знаете как работают websockets, знакомы с понятием tcp-соединение, умеете работать с асинхронными сокетами через epoll/select, то реализовать чатик на рубях без всяких там node.js не проблема.

Пройдемся по пунктам:
1) WebSockets
2) Все что касается авторизации не относится конкретно к задаче чатика. Можно конечно замарачиваться, и выносить функционал авторизации в отдельный демон или поток и общаться через Pub/Sub (например ZeroMQ). По сути главное что бы во время верификации пользователя мы могли обрабатывать другие соединения
3) Если вы хотите p2p доставку сообщений с WebRTC, то сервер вам нужен будет только для авторизации и аунтефикации клиентов, ну и что бы клиенты могли найти собеседников. В этом плане серверная часть упрощается и снижаются требования по нагрузкам, но усложняется клиентская часть.
4) К сожалению вы не можете отправлять бродкастом сообщения, так как используется TCP. Можно конечно организовать что-то типа очереди, но я не вижу причин для выйгрыша в производительности. Тут больше вопрос архитектуры и каким образом вы синхронизируете списки пользователей.
5) Ну... тут не вижу проблемы. Если вы хотите иметь один сервер для всех виджетов, то просто добавить поддержку CORS и токены для запросов (в заголовках) что бы разграничивать по доменам.
6) А что именно вам надо хранить в базе? Сообщения у вас на сервере, как вы сказали, не хранятся... Пользователи - любой вариант, тот же MySQL (а лучше PostgreSQL, для которого есть возможность использовать асинхронные запросы в базу, что бы было интереснее). Текущих пользователей и прочее можно хранить в Reddis и т.д. Главное что бы хранилище было быстрым.

Вообще задумка интересная, вариантов реализации масса. Это можно спокойно и на PHP написать, есть ReactPHP + Ratchet для организации сети пользователей, а для доставки сообщений вы и так хотите использовать WebRTC. Просто на сервере в супервизор надо поставить парочку демонов (по одному на ядро) и сверху поставить nginx, который будет балансировщиком и проксей. Учитывая что вы нехило можете за счет WebRTC и каких-нибудь архитектурных трюков уменьшить итоговую нагрузку на сервер, проблем с производительностью быть не должно. Так же для ReactPHP было бы неплохо поставить libev/libeven, словом там по документации можно пройтись и почитать что да как.

Update:
отстал я от жизни, как раз таки UDP можно использовать в браузерах (во всяком случае в последних билдах хрома), в частности для передачи информации между браузерами (а не аудио и видио) можно использовать datachannels. Так что тут все упирается в то, как доставлять сообщения между клиентами. Остальное уже зависит от того, как вы все же решите все делать.