У меня есть веб-приложение, сидящее на IIS и разговаривающее с [remote] Service-Machine. Я не уверен, следует ли выбирать TCP или Http в качестве основного протокола.
подробнее:
Я знаю разницу довольно хорошо, но я ищу хороший тест, который показывает, насколько быстрее TCP?
HTTP - это уровень, построенный на уровне TCP, для некоторых, которые стандартизируют передачу данных. Поэтому, естественно, использование сокетов TCP будет менее тяжелым, чем использование HTTP. Если производительность - это единственное, о чем вы заботитесь, тогда простой TCP - лучшее решение для вас.
Возможно, вы захотите рассмотреть HTTP из-за его простоты использования и простоты, что в конечном итоге сократит время разработки. Если вы делаете то, что может быть непосредственно использовано браузером (через вызов AJAX), вы должны использовать HTTP. Для того, чтобы несовременный браузер напрямую потреблял TCP-соединения без HTTP, вам придется использовать Flash или Silverlight, и это обычно происходит для богатого контента, такого как видео и/или аудио. Однако многие современные браузеры (начиная с 2013 года) поддерживают API для доступа к сетевым, аудио и видео ресурсам напрямую через JavaScript. Единственное, что нужно учитывать, это скорость использования современных веб-браузеров среди ваших пользователей; см. caniuse.com для получения последней информации о совместимости браузера.
Что касается тестов, это, это единственное, что я нашел. См. Стр. 5, он имеет график производительности. Обратите внимание, что на самом деле он не сравнивает яблоки с яблоками, поскольку он сравнивает параметр TCP/Binary data с параметром данных HTTP/XML. Что вызывает вопрос: какие данные вызывают ваши услуги? бинарные (видео, аудио, файлы) или текст (JSON, XML, HTML)?
В общей системе, ориентированной на производительность, например, в военном или финансовом секторах, вероятно, будут использоваться простые TCP-соединения. Где, как компании, ориентированные на общую сеть, предпочитают использовать HTTP и использовать IIS или Apache для размещения своих сервисов.
Вопрос, на который вам действительно нужен ответ, - "Будет ли TCP или HTTP быстрее для моего приложения". Ответ заключается в том, что это зависит от характера вашего приложения и от того, как вы используете TCP и/или HTTP в своем приложении. Общий тестовый протокол HTTP vs TCP не будет отвечать на ваш вопрос, так как вероятность того, что эталонный показатель не будет соответствовать вашему поведению приложения.
Теоретически оптимально разработанное/реализованное решение с использованием TCP будет быстрее, чем приложение, использующее HTTP. Но также может быть значительно больше работы по реализации... в зависимости от деталей вашего приложения.
Существуют и другие проблемы, которые могут повлиять на ваш выбор. Например, у вас меньше шансов столкнуться с проблемами брандмауэра, если вы используете HTTP, чем если вы используете TCP на каком-то случайном порту. Другим является то, что HTTP упростит реализацию балансировки нагрузки между сервером IIS и внутренними системами.
Наконец, в конце дня, вероятно, более важно, чтобы ваша система была надежной, поддерживаемой и (возможно) масштабируемой, чем она быстрая. Разумная стратегия заключается в том, чтобы сначала реализовать простую версию, но у вас есть планы в том, как сделать это быстрее... если простое решение слишком медленно.
Вы всегда можете сравнить его.
В общем, если то, что вы хотите выполнить, можно легко выполнить по HTTP (т.е. единственная причина, по которой вы могли бы подумать об использовании raw TCP, для возможного повышения производительности), вы, вероятно, должны просто использовать HTTP. Конечно, вы можете программировать сокеты, но зачем беспокоиться? Многие люди потратили много времени и усилий на создание клиентских библиотек и серверов HTTP, и они потратили waaaaaay на большее время, оптимизируя и тестируя этот код, чем вы когда-либо сможете потратить на свои сокеты TCP. Существует просто так много возможных ошибок, которые вам придется обрабатывать, крайние случаи и оптимизации, которые могут быть выполнены, что обычно проще и безопаснее использовать библиотечную функцию для HTTP.
Кроме того, спецификации HTTP определяют всевозможные функции (и клиенты/серверы реализуют, что вы можете использовать "бесплатно", т.е. никакой дополнительной работы по внедрению), что значительно облегчает взаимодействие сторонних разработчиков. "Вот мой URL, вот правила для того, что вы отправляете, вот правила для того, что я верну..."
У меня есть собственное серверное приложение с собственными хостами Windows C++, в котором я использую код SDK REST для Casablanca C++. Я могу использовать любые клиентские С#, JavaScript, C++, cURL, в основном все, что может отправлять POST, GET, Сообщение PUT, DEL может использоваться для отправки сообщений о запросах в это приложение для самостоятельного размещения окон. Также я могу использовать адресную строку простого браузера для выполнения запросов, связанных с GET, с использованием различных параметров. В настоящее время я запускаю эту систему только в частной интрасети, поэтому она очень быстрая - я не сравниваю ее с тем, что я делаю только TCP-поток, но в частной интрасети сомневаюсь, что разница в нескольких микросекундах может быть разной? Для удобства и простоты разработки и возможности расширения до полного интернет-приложения это воплощение мечты. Это выделенная система с частным протоколом, использующая небольшие пакеты JSON, поэтому не определенно, соответствует ли это требованиям вашего приложения или нет? Еще одна приятная вещь: этот обычный код приложения C++ для Windows может быть легко перенесен на Linux/MacOS, поскольку Casablanca REST SDK переносится на эти ОС.