Вы говорите о двух совершенно разных подходах: TCP - это протокол транспортного уровня, а HTTP - протокол прикладного уровня. HTTP (обычно) работает по TCP, поэтому, какой бы вариант вы ни выбрали, он все равно будет работать по TCP.
Вопрос эффективности является своего рода спорным вопросом, потому что вы говорите о разных слоях OSI . Если бы вы выбрали необработанные сокеты TCP, ваше решение, вероятно, было бы более эффективным - по крайней мере, в полосе пропускания - поскольку HTTP содержит целую кучу дополнительных данных (заголовков), которые, вероятно, не будут иметь отношения к вашим целям (в зависимости от масштаба чата программа). То, о чем вы говорите, это собственный протокол прикладного уровня.
Вы можете отправлять все что угодно через TCP - ведь HTTP может отправлять вложения, и это работает через TCP. FTP также работает по протоколу TCP и предназначен исключительно для передачи «вложений». Для этого вам нужно написать свой протокол, чтобы он мог сообщить удаленной стороне, что следующие данные были файлом, затем отправить данные файла, а затем сообщить удаленной стороне, что передача завершена. Реализации этого многочисленны и разнообразны (подход HTTP полностью отличается от подхода FTP), и ваши варианты в значительной степени бесконечны.
Я не знаю наверняка об ограничении соединения node.js, но могу с достаточной уверенностью сказать, что оно ограничено операционной системой. Это может помочь вам справиться с ответом на этот вопрос.
Это спорно, является ли она больше работы, чтобы сделать это с TCP или HTTP - это много работы, чтобы сделать это в обоих. Я бы, вероятно, больше склонялся к тому, чтобы вариант TCP был вашей лучшей ставкой. В то время как TCP потребует от вас разработки протокола, а не / или приложения, HTTP не особенно подходит для живых, двусторонних приложений, таких как серверы чата. Существует много реализаций чата по HTTP, в которых используется AJAX, но я могу вам сказать из мучительного опыта, что это полная боль в тыловой части.
Я бы сказал, что вы должны смотреть на HTTP только в том случае, если вы хотите, чтобы конечная точка (т. Е. Клиент) была браузером. Если вы собираетесь написать настольное приложение для конечной точки, прямая TCP-связь определенно будет подходящим вариантом. Основная причина этого заключается в том, что HTTP работает в режиме запрос-ответ, когда клиент отправляет запрос на сервер, а сервер отвечает. Через TCP вы можете открыть один поток TCP, который можно использовать для двунаправленной связи. Это означает, что сервер может мгновенно передать событие клиенту, в то время как по HTTP вы должны ждать, пока клиент отправит запрос, чтобы вы могли ответить событием. Если вы намеревались использовать браузер в качестве клиента, он значительно усложнит передачу файлов (по крайней мере, отправку).
Существуют способы реализовать это через HTTP с использованием длинного опроса и проталкивания сервера ( прочитайте это ), но реализовать это может быть реальной проблемой.
Если вы собираетесь реализовать это в локальной сети (или, возможно, даже через Интернет), стоит рассмотреть UDP по TCP - в приложении чата обычно не является абсолютно критически важным, чтобы сообщения приходили в правильном порядке, и даже если бы это было так, пользователи, вероятно, не смогли бы печатать быстрее, чем изменения в задержке сети (вероятно, <100 мс). Затем для передачи файлов вы можете договориться об отдельном сокете TCP для обмена данными (например, FTP) или внедрить какую-либо систему UDP ACK (например, TFTP). </p>
Я чувствую, что по этому вопросу можно сказать гораздо больше, но сейчас я не могу выразить это словами - я могу в какой-то момент расширить этот ответ.