Web Services vs Persistent Sockets [closed]_问答_开发者

开发者_运维技巧 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

I plan on doing a little benchmarking around this question, myself. But I thought it would be good to get some initial feedback from "the community". Has anyone out there done any analysis regarding the pros and cons of these two technologies? My thoughts:

Opening and closing TCP/IP connections for web service calls is relatively expensive compared to persistent connections.
Dealing with intermittent connection errors and state, etc... would be easier with a web service based framework.
You don't see World of Warcraft using web services.

One question that I can't seem to find much of answer for anywhere (even on here)... are the limits on the # of persistent connections a single network card can support, etc?

This is a very generic question, and are multiple issues you raise explicitly, and many more issue correlated of which you may be or may not be aware.

One issue is HTTP vs. other protocols (or message exchange patterns, to be accurate). HTTP is request-response and many communication patterns don't fit a request response paradigm. A persisted connection allows for message oriented protocols that are more flexible, like a typical full duplex chat exchange pattern.

Since you mention WOW, they use UDP not TCP. TCP offers stream guarantee semantics, with order guarantee and no duplicates. But to achieve this a heavy price is payed in terms of latency. A game like WOW is much more interested in latency and does not care about order guarantee: latest packet is always the best and supersedes any previous packet information.

There are more issue lurking under the surface:

outbound firewall traversal (almost always allowed for HTTP)
invasive proxies that read and understand HTTP headers
inbound NAT traversal issues

And finally there is the issue you just ask about: TCP socket limits. They depends per OS. For example a typical out-of-the-box Windows Server will choke at around 1000 TCP sockets due to TCP port exhaustion. It has to be specifically tuned for higher numbers. Even tuned, it will hardly approach 64K open, functioning, sockets. For servers that need to connect to millions of clients the connections have to be multiplexed by mid-tiers and the messaging protocols have to be prepared with the issues that arise from forwarding, most importantly message order reversal.

This problem space is vast and there are many dragons under every bridge.

You are clubbing the format of message and mode of delivery together. If you have the kind of message where you economized the number of bits and rearranged pieces so the message can be consumed faster, Web Services is probably not the right choice for you. If I assume that you have relatively large text-based messages, Web Services may fit your needs. With that, this is how I will answer your thoughts:

Opening/Closing TCP connections: Yes, this is relatively expensive. Web Services rely on HTTP (and TCP/IP) to help out in the following ways:
- If A single client has to send a lot of message, they will likely send them over a "keep-alive" HTTP connection.
- You can place a load balancer in front of your web server that will further optimize the TCP layer. It will deal with the TCP/IP level chaos of connections and present only a handful of long term connections to your web server.
Dealing with intermittent connectons: HTTP being stateless makes this easier.
WoW with WS: I am not sure of the kind of messaging involved, but WoW needs to send out a flurry of extremely short messages, the HTTP header itself might be too much of an overhead to warrant Web Services.

I don't know the definitive answer to your last question. You will have one limit imposed by how many connections your web server can handle, then another one by your OS in the form of number of sockets.

Hope this helps. -Raj