#websocket #tcp #udp #system #system-design
#websocket #tcp #udp #система #system-design
Вопрос:
Типичные схемы проектирования системы для внутренних сервисов, таких как Uber, включают прокси-сервер и подключение сервера веб-сокетов к клиенту.
Мне любопытно, почему для этих современных веб-дизайнов рассматриваются только веб-сокеты (и длительный опрос). Если требуется служба обновления местоположения из мобильного приложения, которое постоянно отправляет обновления местоположения на сервер, почему люди не блокируют пользовательское соединение tcp или udp между клиентом iOS и сервером, например?
Tcp-соединение — это действительно то, что websockets использует под капотом, но с необработанным TCP-соединением у вас есть гораздо более зрелые библиотеки, которые вы можете использовать (Netty, обход ядра, FPGA)
Udp кажется еще лучше, поскольку он не имеет состояния и может быть восстановлен при отключениях. Если это односторонний поток обновлений местоположения, похоже, он отлично подходит для этой цели.
Мысли?
Комментарии:
1. Может заключаться в том, чтобы иметь единый серверный интерфейс для веб- и нативных приложений.
Ответ №1:
Основной момент использования Websockets заключается в том, что он хорошо сочетается с существующими брандмауэрами, прокси-серверами и другими ограничениями. Нередко устройства используются в сетях с ограниченным доступом, которые разрешают доступ только к Интернету и почте. Также приятно, что он также предоставляет семантику сообщений (TCP — это всего лишь поток байтов) и что поддержка TLS также хорошо интегрирована. В то время как «сырой» TCP может иметь меньшие накладные расходы, фактические накладные расходы на Websockets довольно малы. И часто накладные расходы на недвоичные полезные нагрузки (т. Е. JSON, XML) намного выше, что делает дополнительные небольшие накладные расходы на Websockets неуместными.
Комментарии:
1. Интересно. Можете ли вы использовать двоичный протокол через веб-сокеты, если хотите? Есть ли какая-то причина, по которой вы должны придерживаться JSON или XML?
2. @FredWang: Можно использовать двоичные протоколы через веб-сокеты. Нет никаких причин придерживаться JSON или XML. Но многие разработчики, тем не менее, делают это, поскольку они чувствуют себя более комфортно с этими протоколами и знают, как использовать инструменты и библиотеки для обработки этих форматов.
3. @SteffenUllrich Есть много причин придерживаться JSON и XML, а не использовать двоичный протокол. JSON и XML более удобны, требуют меньше кода и проще в отладке. По сути, разработка и обслуживание займет меньше времени. Применять двоичный протокол до смешного сложно. Необходимость определять отдельные схемы для каждой конечной точки API как на сервере, так и на клиенте нелепа. На мой взгляд, мы должны использовать двоичный протокол только тогда, когда пропускная способность является реальной проблемой. В противном случае, оно того не стоит.