http, RMI, socket, RPC, hessian comparison
Socket can be used to specify protocol tcp,udp and so on;
RIM: Using the JRMP protocol, JRMP is also based on TCP/IP;
RPC: The bottom layer uses the socket interface, defines a set of remote call methods;
HTTP: is based on TCP, not using the socket interface, the need for the connection to send data to the server, the server can not actively send data client;
You can use the socket to implement HTTP;
In fact, the HTTP specification is the HTTP protocol, no matter what technology.
Hessian: is a simple binary protocol for building Web service that replaces XML-based Web service, which is built on RPC, and Hessian has its own serialization format to serialize data to a stream and then send it to the server via the HTTP protocol. See source discovery is actually using httpurlconnection and servlet to establish a connection, and then send the stream
3.1:rmi VS SOCKET
First. RMI is object-oriented, and the latter is not.
Second. RMI is bound to the language. For example, when you use Java RMI Technology, both the client and server side must use Java development (in the java.rmi.* package). The socket's network programming is used independently of the development language, or even platform-independent. Socket-based network programming allows the client and server to use different development languages and different platforms.
Thirdly, from the point of view of network protocol stack, the network programming of RMI and socket is at different levels. Socket-based network programming is located on the TCP protocol, and RMI is above the TCP protocol and defines its own application protocol, and its transport layer uses the Java Remote Method Protocol (JRMP). It can be seen that on the network protocol stack, RMI-based application location is higher, which also determines that, compared with the socket network programming, RMI will lose some flexibility and controllability, but the advantage is that it gives the application developers more concise, convenient and easy to use. For example, if you are using RMI, you do not need to care about how the message is serialized, you only need to use RMI just like the local method call. The cost is that the application developer does not have a good control over the serialization mechanism of the message.
IV: RMI requires more network bandwidth (Protocoloverhead) than the TCP based socket to transmit the same valid data. From here, we can draw a general conclusion: RMI is mainly used for the "invocation" of the remote method (RMI is so true:), the technical connotation of the emphasis is "call", based on this, I can think of: mobile computing, and remote control, RMI is a good choice when your app doesn't need to transfer large amounts of data between the client and server, and it's simple and easy to develop. However, once your application needs to transfer large amounts of data between the client and server, extreme, such as the FTP application, RMI is not suitable, we should use the socket.
3.2:rmi VS RPC
1. RPC does not support objects, using the HTTP protocol
2. RMI supports the transfer of objects. Using JRMP (Java remote method Protocol) communication protocol is a kind of remote calling method built on TCP/IP protocol.
3. RMI is limited to the Java language, RPC cross-language
Simple comparison of RPC and RMI
The main difference between RMI and RPC is how the method is called. In RMI, the remote interface enables each remote method to have a method signature. If a method executes on the server, but no matching signature is added to the remote interface, the new method cannot be called by the RMI client. In RPC, when a request arrives at the RPC server, the request contains a set of parameters and a literal value, usually in the form of a "classname.methodname". This indicates to the RPC server that the requested method is in the class "ClassName", which is called "MethodName". The RPC server then searches for classes and methods that match it and takes it as input to the type of the method parameter. The parameter type here is matched to the type in the RPC request. Once the match is successful, the method is called, and the result is encoded and returned to the client side.
Distributed computing systems require that objects running on different hosts in different address spaces call each other. Various distributed systems have their own invocation protocols, such as CORBA Iiop (Internetinterorb Protocol), MTS DCOM. So what about EJB components. The complete sockets communication interface is provided in Java, but the sockets requires that the client and the server must have an application-level protocol encoded to exchange data, which is cumbersome to use sockets.
A protocol to replace sockets is RPC (remote Procedure call), which abstracts out the communication interface for procedure calls, making it easy for programmers to invoke a remote procedure and invoke a local procedure. The RPC system uses XDR to encode parameters and return values for remote calls.
But RPC does not support objects, and EJB constructs a fully object-oriented distributed system, so the object-oriented remote invocation of RMI (invocation) is an inevitable choice. With RMI, it is also convenient to invoke remote objects and invoke local objects. RMI uses JRMP (Java Remote method Protocol) communication protocol, which is a kind of remote calling method built on TCP/IP protocol.
RMI invocation mechanism
RMI uses stubs and skeletons to communicate with remote objects (remotely object). The stub acts as the client proxy for the remote object and has the same remote interface as the remote object, and the call to the remote object is actually done by invoking the client proxy object stub of the object.
3.3 HTTP VS SOCKET
1. TCP connection
To understand the socket connection, you need to understand the TCP connection first. Mobile phone can use the network function is because the bottom of the mobile phone implementation of TCP/IP protocol, you can make the mobile phone terminal through the wireless network to establish a TCP connection. TCP protocol can provide an interface to the upper network, so that the transmission of the upper network data is based on the "No Difference" network.
Setting up a TCP connection requires a "three-time handshake":
First handshake: The client sends a SYN packet (SYN=J) to the server and enters the Syn_send state, waiting for the server to confirm;
Second handshake: The server receives the SYN packet, it must confirm the customer's SYN (ACK=J+1), and also send itself a SYN packet (syn=k), that is, the Syn+ack packet, when the server enters the SYN_RECV state;
Third handshake: The client receives the server's Syn+ack packet, sends the acknowledgment packet ack (ACK=K+1) to the server, the packet is sent, the client and the server enter the established state, and the handshake is completed three times.
The data is not included in the packets that are delivered during the handshake, and the client and server formally begin transmitting the data after the three handshake is complete. Ideally, once a TCP connection is established, the TCP connection is maintained until either side of the communication actively closes the connection. When disconnected, both the server and the client can initiate a request to disconnect the TCP connection, and the disconnection process requires a "four handshake" (the process is not fine-grained, that is, the server interacts with the client and finally determines the disconnection)
2. HTTP connection
The HTTP protocol, the Hypertext Transfer Protocol (Hypertexttransfer Protocol), is the foundation of Web networking and one of the most commonly used protocols for mobile networking, an application built on the TCP protocol.
The most notable feature of an HTTP connection is that each request sent by the client requires a server loopback response, and the connection is actively released after the request has ended. The process from establishing a connection to closing a connection is called a "one-time connection."
1) in HTTP 1.0, each request from the client requires a separate connection to be established, and the connection is automatically freed after the request is processed.
2) in HTTP 1.1, multiple requests can be processed in a single connection, and multiple requests can overlap, without waiting for a request to end before sending the next request.
Because HTTP is actively releasing the connection after each request ends, the HTTP connection is a "short connection", which requires constant connection requests to the server to maintain the client program's online status. As a general practice, there is no need to obtain any data immediately, and the client will keep a "keep-connected" request to the server at regular intervals, and the server responds to the client after receiving the request, indicating that the client is "online". If the server can not receive the client's request for a long time, it is considered that the client "offline", if the client cannot receive a reply from the server for a long time, it is considered that the network has been disconnected.
3. Socket principle
3.1 Socket (socket) concept
Socket (socket) is the cornerstone of communication and is the basic operating unit of network communication supporting TCP/IP protocol. It is an abstract representation of the endpoint in the network communication process and contains five kinds of information that must be used for network communication: the protocol that the connection uses, the IP address of the local host, the protocol port of the local process, the IP address of the remote host, and the protocol port of the remote process.
When the application layer communicates data through the transport layer, TCP encounters a problem that provides concurrent services for multiple application processes at the same time. Multiple TCP connections or multiple application processes may require data to be transmitted over the same TCP protocol port. To differentiate between different application processes and connections, many computer operating systems provide a socket (socket) interface for applications interacting with the TCP/IP protocol. The application layer can communicate with the transport layer through the socket interface, differentiate the communication from different application processes or network connections, and realize the concurrent service of data transmission.
3.2 Establishing a socket connection
Establishing a socket connection requires at least one pair of sockets, one running on the client, called Clientsocket, and the other running on the server side, called ServerSocket.
The connection between sockets is divided into three steps: Server listening, client request, connection acknowledgement.
Server monitoring: Server-side sockets do not locate specific client sockets, but are waiting for the status of the connection, real-time monitoring network status, waiting for the client connection request.
Client request: Refers to the client's socket to make a connection request, to connect to the target is the server-side socket. To do this, the client's socket must first describe the socket of the server it is connecting to, indicate the address and port number of the server-side socket, and then make a connection request to the server-side socket.
Connection confirmation: When a server-side socket hears or receives a connection request from a client socket, it responds to a client socket request, establishes a new thread, sends a description of the server-side socket to the client, and once the client confirms the description, the two sides formally establish the connection. While the server-side socket continues to be in the listening state, it continues to receive connection requests from other client sockets.
4. Socket connection and TCP connection
When you create a socket connection, you can specify the transport layer protocol used, which can support different transport layer protocols (TCP or UDP), which is a TCP connection when a connection is made using the TCP protocol.
5. Socket connection and HTTP connection
Since the socket connection is usually a TCP connection, once the socket connection is established, the communication parties can start sending data content to each other until the two sides are disconnected. However, in real network applications, the client-to-server communication often needs to traverse multiple intermediary nodes, such as routers, gateways, firewalls, and so on, most firewalls will turn off long inactive connections and cause the Socket connection to be disconnected, so it needs to be polled to tell the network that the connection is active.
The HTTP connection uses a "request-response" approach, not only to establish a connection at the time of the request, but also to be able to reply to the server after the client has made a request to the server.
In many cases, the server side is required to proactively push data to the client, keeping the client and server data in real time and in sync. At this point, if the two sides established a socket connection, the server can directly transfer the data to the client, if the two sides establish an HTTP connection, the server needs to wait until the client sends a request before the data can be sent back to the client, so the client periodically sends a connection request to the server, not only to remain online, It also asks the server if there is any new data, and if so, it passes the data to the client.