OpenAI и WebRTC: когда реальное время бьёт по нервам
OpenAI столкнулась с тем, что WebRTC — не панацея, а источник головной боли для real-time приложений.
OpenAI, судя по всему, решила, что WebRTC — это серебряная пуля для real-time коммуникаций. Спойлер: пуля оказалась с рикошетом. В недавнем посте на moq.dev разбирают, почему даже гиганты вроде OpenAI спотыкаются об этот протокол, когда пытаются построить что-то масштабируемое.
WebRTC — как тот самый Wi-Fi у бабушки: вроде работает, но стоит трём устройствам подключиться — начинаются танцы с бубном. OpenAI, видимо, наступила на те же грабли: накладные расходы на сигнализацию, проблемы с NAT traversal и нестабильность при пиковых нагрузках. Особенно больно это бьёт по AI-ассистентам, где каждая миллисекунда задержки превращает диалог в переписку с почтовым голубем.
Конечно, можно сказать: «А давайте заменим WebRTC на что-то новое, например, WebTransport или медиасерверы». Но это как предложить переписать legacy-код на Rust — звучит круто, но в продакшене всё равно вылезут грабли. OpenAI явно ищет баланс между совместимостью и производительностью, и пока что чаша весов склоняется в сторону «надо фиксить, а не менять».
Что особенно забавно: WebRTC позиционировался как решение для real-time, но на практике его часто хватает только для демо-стендов. Как только нагрузка становится реальной — привет, JIRA с багами. Разработчикам, которые планируют использовать WebRTC в AI-продуктах, стоит заранее закладывать время на «танцы с бубном».
Комментарий студии METABYTE: Если ваш проект на WebRTC начал напоминать игру в «сломанный телефон», возможно, пора подумать о кастомном решении. Мы такие головоломки щёлкаем как орешки — и без ночных деплоев, обещаем.