blocks|key|68850|text|HTTP只是套接字上的协议。如果您使用的是TCP/IP网络，则将使用套接字。HTTP连接初始化和握手并不是最昂贵的部分，真正昂贵的部分是TCP初始化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|68851|如果使用HTTP1.1，则可以使用持久连接(Keep-Alive)，这将极大地降低此成本，更接近于保持持久套接字打开。|68852|这完全取决于您是否想要/需要更高级别的协议。使用HTTP意味着您将能够从更多的客户端使用此服务，而编写的文档要少得多(如果您编写自己的协议，则必须对其进行文档记录)。HTTP服务器还支持开箱即用的身份验证、cookie、日志记录等功能。如果您不需要这些功能，那么HTTP可能是一种浪费。但我看到的项目中，很少有项目至少不需要这些东西。|68853|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

HTTP is just the protocol over the socket. If you are using TCP/IP networks, you are going to be using a socket. The HTTP connection initiation and handshake are not the expensive bits, it's TCP initiation that's really the expensive bit.

If you use HTTP 1.1, you can use persistent connections (Keep-Alive), which drastically reduces this cost, closer to that of keeping a persistent socket open.

It all depends on whether you want/need the higher-level protocol. Using HTTP means you will be able to do things like consume this service from a lot more clients, while writing much less documentation (if you write your own protocol, you will have to document it). HTTP servers also supports things like authentication, cookies, logging, out of the box. If you don't need these sorts of capabilities, then HTTP might be a waste. But I've seen few projects that don't need at least some of these things.

blocks|key|655346|text|补充@Rob的答案，因为问题并不是精确地指向应用程序或性能边界，因此在更广泛的上下文中研究可用选项将是很好的，即Inter+process+communication。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|655347|维基百科页面清楚地列出了可用的选项，这将是一个很好的起点。|655348|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Inter-process_communication^0|1K|R|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Adding to the answer of @Rob, as the question is not precisely pointing to an application or performance boundaries, it would be good to look into the options available in a broader context, which is <a href="https://en.wikipedia.org/wiki/Inter-process_communication" rel="nofollow">Inter process communication</a>. 

The wikipedia page cleanly lists down the options available and would be a good place to start with.

blocks|key|2186427|text|您将使用什么技术？让我来回答Java世界的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2186428|如果你的请求速率低于100次/秒，你不应该关心优化，而应该使用最通用的解决方案-+HTTP。|2186429|像Netty-HTTP这样编写良好的异步服务器可以在中等级别的硬件上轻松地处理每秒1000个请求。|2186430|如果你需要更多或者资源有限，你可以使用二进制格式。最受欢迎的是Google+Protobuf(多语言)%2B+Netty+(Java)。|2186431|关于HTTP性能，您应该知道的是：|2186432|2186433|Http可以使用Keep-Alive，它可以消除每个请求的重新连接成本。|unordered-list-item|2186434|+HTTP会增加每个请求和响应的流量开销-大约50-100个字节。|2186435|HTTP客户端和服务器会消耗额外的CPU来解析HTTP头-这一点在上面提到的100+req/sec之后很明显|2186436|在选择技术时要小心。即使在21世纪，也很难找到编写良好的超文本传输协议服务器和客户端。|2186437|2186438|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|12|8|@]|9|@]|A|$]]|$1|N|3|O|5|M|7|13|8|@]|9|@]|A|$]]|$1|P|3|Q|5|M|7|14|8|@]|9|@]|A|$]]|$1|R|3|S|5|M|7|15|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|V|$]]

What technology are you going to use? Let me answer for Java world.

If your request rate is below 100/sec, you should not care about optimizations and use most versatile solution - HTTP.

Well-written asynchronous server like Netty-HTTP can easily handle 1000 requests per second on medium-level hardware.

If you need more or have constrained resources, you can go to binary format. Most popular one out there is Google Protobuf(multilanguage) + Netty (Java).

What you should know about HTTP performance:

<ul>
<li>Http can use Keep-Alive which removes reconnection cost for every request</li>
<li>Http adds traffic overhead for every request and response - around 50-100 bytes.</li>
<li>Http client and server consumes additional CPU for parsing HTTP headers - that is noticeable after abovementioned 100 req/sec</li>
<li>Be careful when selecting technology. Even in 21 century it is hard to find well-written HTTP server and client.</li>
</ul>

I have a service, foo, running on machine A. I need to access that service from machine B. One way is to launch a web server on A and do it via HTTP; code running under web server on A accesses foo and returns the results. Another is to write socket server on A; socket server access service foo and returns the result. 

HTTP connection initiation and handshake is expensive; sockets can be written, but I want to avoid that. What other options are available for high performance remote calls?

High Performance Options for Remote services access

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有一个服务，foo，在机器A上运行。我需要从机器B访问该服务。一种方法是在A上启动一个web服务器并通过HTTP执行；在A上的web服务器下运行的代码访问foo并返回结果。另一种是在A上编写socket服务器；socket服务器访问服务foo并返回结果。HTTP连接初始化和握手的开销很大；可以写套接字，但我想避免这种...

问用于远程服务访问的高性能选项
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问用于远程服务访问的高性能选项EN