Сравнение приложений TCP / IP и приложений HTTP [закрыто]

13

Я заинтересован в разработке крупномасштабного сайта, ориентированного на пользователя, который написан на Java.

Что касается дизайна, я думаю о разработке независимых модульных сервисов, которые могут выступать в качестве поставщиков данных для моего основного веб-приложения.

Что касается написания этих модульных сервисов (поставщиков данных), я могу использовать существующую инфраструктуру, такую ​​как Spring, и разрабатывать эти сервисы в соответствии с шаблоном проектирования RESTful, а также предоставлять ресурсы через HTTP с форматом сообщений, например JSON ... или я могу использовать существующую сеть. фреймворк, такой как Netty ( http://netty.io/ ) и формат сериализации, такой как Protobufs ( https://developers.google.com/protocol-buffers/docs/overview ), и разработка сервера TCP, который отправляет туда и обратно сериализованный protobuf полезная нагрузка.

Когда вы должны выбрать один над другим? Будет ли какая-то польза от использования формата сериализации, такого как Protobufs, и отправки потока байтов по проводам? Будут ли накладные расходы только при использовании JSON? Сколько накладных расходов между использованием TCP / IP и HTTP? Когда следует использовать Spring поверх Netty и наоборот для создания такого сервиса?

HiChews123
источник
Похоже, вы больше думаете о технологическом стеке, чем о реальных требованиях. Как мог любой из нас ответить на этот вопрос, не зная, что вам нужно делать ? Вы создаете многопользовательскую игру с задержкой, близкой к нулю? Или приложение для социальных закладок, в котором большая часть доступа уже осуществляется через HTTP, и вы, возможно, кешируете данные часами и даже не заботитесь о свежести, не говоря уже о задержке?
Aaronaught
3
Я не думаю, что ОП просит нас сделать выбор за него. Он просто задает вопрос высокого уровня о том, как делается такой выбор и какие факторы учитываются. Не думайте, что есть что-то плохое в том, чтобы дать ответ высокого уровня на это ... и я сделал.
ДХМ
Я вообще против использования бинарных форматов, если вам не нужно. Нет двоичных форматов файлов, нет двоичных сериализаций и т. Д. Например, в Java двоичные сериализации вызывают несовместимости между версиями Java и версиями вашего собственного программного обеспечения, но я считаю, что XML не так уж много. Я думаю, что следующий TCP / IP> HTTP> XML Конечно, это будет зависеть от того, что вы делаете. Я думаю, что JSON является альтернативой XML. Я не знаю много о Spring или Netty, хотя я читаю, что люди используют Spring.
Кейделл
+1 ДХМ, я задаю вопросы высокого уровня как пищу для размышлений, когда думаю о принятии такого решения.
HiChews123

Ответы:

21

Определенно есть плюсы / минусы использования JSON поверх REST по сравнению с прямым TCP / IP с двоичным протоколом, и я думаю, вы уже подозреваете, что двоичный протокол будет быстрее. Я не могу точно сказать, насколько быстрее (и это будет зависеть от множества факторов), но я бы предположил, что разница может быть на 1-2 порядка.

На первый взгляд, если что-то в 10-100 раз медленнее, чем что-либо другое, у вас может быть реакция коленного рефлекса и вы переходите к «быстрой вещи». Однако эта разница в скорости только в самом протоколе. Если есть доступ к базе данных / файлу на стороне сервера, это не повлияет на ваш выбор уровня передачи. В некоторых случаях это может сделать скорость вашего уровня передачи гораздо менее значимой.

HTTP REST и JSON хороши по ряду причин:

  • они легко потребляются кем угодно. Вы можете написать свое веб-приложение, а затем развернуться и опубликовать свой API для использования остальным миром. Теперь любой желающий может попасть в одни и те же конечные точки и получить к вашим услугам
  • они легко отлаживаются, вы можете открыть анализатор пакетов или просто сбросить входящие запросы в текстовые файлы и посмотреть, что происходит. Вы не можете сделать это с бинарными протоколами
  • они легко расширяются. Вы можете добавить больше атрибутов и данных позже, не нарушая совместимость со старыми клиентами.
  • может использоваться клиентами javascript (пока не уверен, что у них есть JS-анализатор protobuf, не верьте, что он есть)

Протобуфы через TCP / IP:

  • они быстрее

Если бы это был мой выбор, я бы предпочел использовать HTTP REST и JSON. Есть причина, по которой многие другие компании и сайты пошли по этому пути. Также имейте в виду, что в будущем вы всегда можете поддержать 2 конечные точки. Если ваш дизайн верен, ваш выбор конечной точки должен быть полностью отделен от вашей бизнес-логики на стороне сервера или базы данных. Поэтому, если вы потом поймете, что вам нужно больше скорости для всех / некоторых запросов, вы сможете добавить protobufs с минимальными усилиями. Однако REST / JSON сразу же приведут вас в чувство быстрее и продвинут вас дальше.

Насколько нетти против весны идет. Я не использовал Netty напрямую, но считаю, что это всего лишь легкий веб-сервер, так как Spring - это фреймворк, который предоставляет вам гораздо больше, чем просто. У него есть уровни доступа к данным, планирование фоновых заданий и (я думаю) модель MVC, так что она намного тяжелее. Какой выбрать? Если вы решили пойти по пути HTTP, то следующий вопрос, вероятно, насколько стандартно ваше приложение? Если вы собираетесь написать какую-то сумасшедшую настраиваемую логику, которая не соответствует стандартной форме, и все, что вам нужно, это просто уровень сервера HTTP, используйте Netty.

Тем не менее, я подозреваю, что ваше приложение не такое уж особенное, и оно может извлечь пользу из множества вещей, которые может предложить Spring. Но это означает, что вы должны структурировать свое приложение на основе среды Spring и делать то, что они ожидают от вас, что будет означать больше узнать о Spring, прежде чем погрузиться в ваш продукт. Фреймворки в целом великолепны, потому что они снова ускоряют процесс, но недостатком является то, что вы должны вписаться в их форму, а не делать свой собственный дизайн, а затем ожидать, что фреймворк просто сработает.

(*) - в прошлом указывалось, что мои посты не отражают мнения всего мира, поэтому я пойду на запись и просто добавлю, что у меня ограниченный опыт работы с любой из Netty (раньше я пользовался платформой Play) который основан на Netty) или Spring (я только читал об этом). Так что возьми то, что я скажу, с крошкой соли.

DXM
источник
1
+1, особенно для того, что «эта разница в скорости есть только в самом протоколе. Если есть доступ к базе данных / файлу на стороне сервера, это не повлияет на ваш выбор уровня передачи». 99% именно так и будет, и преждевременная оптимизация (в неправильном месте) совсем не поможет.
Shivan Dragon
Спасибо за ваш длинный ответ и глубокий анализ по сравнению двух. Я понимаю преимущества создания приложения RESTful, потому что оно легко доступно общедоступным клиентам. Однако в том случае, если я хочу сохранить все внутри и не хочу предоставлять сервис (я забочусь о сериализации / десериализации), я не могу понять, почему не использование собственного двоичного протокола не было бы первым выбором. Да, вы можете быстрее начать работу с существующими средами, но за счет того, что они заблокированы в их API и менее детализированном управлении.
HiChews123
REST легко использовать ВСЕ клиенты, не только публичные, но они, безусловно, включены. У моей компании есть продукт, который мы выпускаем уже около года. У нас был «проприетарный» протокол, который оказался отдыхающим. Мы просто открыли это для других. Одной из вещей, которой вас учат в бизнес-школе, является «выбор вариантов», принятие решений, чтобы оставить вам как можно больше вариантов, чтобы вы могли принимать решения позднее. Таким образом, при всех равных условиях я бы выбрал REST не потому, что у меня есть клиенты JS или доступ к API сегодня, а в том, что у меня есть возможность получить его в будущем, если он мне понадобится. Опять же, если ...
ДХМ
... вы настроены на использование двоичного протокола, пойти на это. 96% вероятности того, что ваш выбор протокола не повлияет на ваше окончательное приложение, поэтому я бы не стал слишком сильно волноваться по поводу этого решения. И, как я сказал в ответе, при достойном дизайне вы все равно сможете поменять протоколы позже. Еще одна вещь, которую мне нравится делать, - это попробовать оба случая: если я нахожусь на грани принятия решения, я подбрасываю монету и выбираю вариант А. В следующий раз, когда я делаю аналогичный проект, я выбираю вариант Б, просто чтобы потом вернуться и сравните / сопоставьте мой опыт. Иногда это единственный способ решить для себя, что лучше
ДХМ
@DXM, отличные отзывы, браво!
HiChews123
0

Это на самом деле не вопрос. Согласно пакету интернет-протоколов tcp - это протокол на транспортном уровне, а http - это протокол на прикладном уровне. Вы сравниваете абсолютно разные вещи друг с другом. (Подробнее здесь: http://en.wikipedia.org/wiki/Internet_protocol_suite )

На самом деле, большинство http более tcp / ip. Итак, чтобы ответить на ваш вопрос, да, вы должны использовать tcp / ip. Затем вы хотите добавить протокол уровня приложения поверх этого (например, http), а затем формат данных (например, json, xml, html). Netty позволяет использовать http, а protobuff равен json, xml, html.

Все зависит от ваших требований и типа данных, которые вам нужно будет перенести. Вам нужны сеансы в вашем протоколе, может ли рукопожатие улучшить конфигурацию протокола, сколько данных вы отправите за раз, вам нужно шифрование? Это вопросы, на которые вы должны ответить при выборе протокола приложения.

Выбор формата представления данных (json, xml, html, protobuff и т. Д.) Зависит от вашей пропускной способности, читабельности, поддержки языка / инструмента и т. Д.

Вы не можете сравнить http с tcp.

Помните, что скорость не все. Скорость бесполезна, если вы не можете выразить себя разумным способом.

iveqy
источник
5
В его вопросе нет ничего, что наводит на мысль, что он не знает разницы между уровнями сетевого стека. Он спросил, должен ли он использовать HTTP (предполагается, что HTTP - это уровень выше TCP / IP) или использовать TCP / IP с собственным протоколом. В его вопросе нет ничего плохого.
Майкл
Я не согласен, конечно. Это не то, как я его понял
iveqy
1
Да, я понимаю, что HTTP находится на уровне выше TCP / IP, мой вопрос действительно о том, чтобы подумать о принятии решения с точки зрения компромиссов - задержка, скорость разработки и т. Д. Спасибо за то, что задали вопросы для меня, чтобы подумать, хотя!
HiChews123
2
@ acspd7 Я бы не стал создавать свой собственный протоколл, там уже есть множество уже проверенных протоколлов, и если ваш протоколл не даст вам преимущества перед конкурентами, вам, вероятно, лучше использовать стандартный протоколл. Я реализовал собственный протокол, это было очень весело! Тем не менее, шифрование, пробивание дырок, сохранение живого образа, рукопожатие (разные сети требуют разной длины кадров) и т. Д. Это много работы для того, чтобы делать что-то хорошее. Не говоря уже о всей документации, которая вам понадобится. Подумайте, что вам действительно нужно в функциях, прежде чем делать что-то индивидуальное.
13
1
GPB хорошо документированы, используются многими другими, поэтому я не вижу никаких проблем с его использованием. Быть более лаконичным, чем XML и JSON, должно быть здорово! (вам может не хватать читабельности, но если это не является обязательным требованием ...). Тем не менее, вы не пропустите слой? Обычно у вас есть слой между tcp и xml, json, protobuff. Что-то вроде http, ssh и т. Д.
iveqy