我应该在客户端/服务器应用程序中使用套接字？

Question

Similar: Socket vs HTTP based communication for a mobile client/server application

I'm currently working on a Java client-server based program (with the intention to turn it into an Android app). I've successfully implemented the server engine, and the clients beautifully connects and exchange data. My implementation is base upon this answer of mine.

The drawback is, all communication is done directly with sockets, no protocol at all. Is this the accepted, secure - or professional - way of client-server communication?

Even further, in case I want to accept credit cards, PayPal or Google Wallet, will my app be compliant with their security standards as I don't use SSL? What about if I'll use my own level of security, say javax.crypto.CipherOutputStream ?

Answer 1

Your question is on the verge of being too broad, but anyway ;-) As we don't know the "quality" and depth of your own socket based communication protocol it is hard to tell if it is able to "compete" with other protocols. So lets just assume that you took care of the necessary stuff and your server is able to handle many parallel connections and follows "best-practice".

I see advantages in implementing ones own protocol, you already mentioned them:

• it is based on something you already know and feel comfortable with (sockets)
• you have full control and don't depend on any framework
• you know the "guts" of your implementation and are the first authority when questions arise

But there are certainly disadvantages and risks:

• not only can you do everything, this can soon become a must
• your protocol needs to work well outside laboratory conditions. In the real world you won't see the quality of wired or Wifi networks. 2G/3G/4G networks can be unstable, interruptions occur and transfer speeds can be slow
• Some environments might have problems with non-http(s) traffic

If your reason for implementing your own socket based protocol was efficiency there are other protocols that are not "chatty" and work on a bytelevel. You could have a look at MQTT for example if you really consider a replacement.

If you are not allergic to http you can have a look at REST over https.

But no matter which protocol you consider "fit" for the main communication of your application: you can always mix in http(s) for services that demand for this.

Answer 2

WebSocket is a low-level protocol, think of it as a socket on the web. Every thing, including a simple request/response design pattern, how to create/update/delete resources need, status codes etc to be build on top of it. All of these are well defined for HTTP.

WebSocket is a stateful protocol where as HTTP is a stateless protocol.

WebSocket connections are know to scale vertically on a single server where as HTTP can scale horizontally. There are some proprietary solutions for WebSocket horizontal scaling, but they are not standards-based. HTTP comes with a lot of other goodies such as caching, routing, multiplexing, gzipping and lot more. All of these need to be defined on top of WebSocket. How will Search Engine Optimization (SEO) work with WebSocket ? Works very well for HTTP URLs. All proxy, DNS, firewalls are not yet fully aware of WebSocket traffic. They allow port 80 but might restrict traffic by snooping on it first. Security with WebSocket is all-or-nothing approach.

Answer 3

A better approach might be to replace the sockets based connection with a RESTFul API that performs the same functions. Using that approach you will be able to use PayPal and accept credits. Also, you can more standard methods, like Ouath2, to handle authentication. It also works well with Android, to have a RESTful api to communicate with the server component.