Remote Procedure Calls (RPC) is not a protocol, it's a principle that is also used in SOAP. SOAP is an application protocol that uses HTTP for transport. HTTP (Hypertext Transfer Protocol) is the most popular client-server application-level protocol used in the Internet. As from RFC2616: "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers".
Being stateless, the new request doesn't know what has been sent in the previous request. It is purely based on pull model, which means server will only share that information what is being requested by client. It negotiates of data type and it's representation, so as to allow systems to be built independently of the data being transferred.
It typically runs over a TCP/IP connection and requires a reliable transport. But any transport protocols that provide such reliable delivery can be used.
There are 2 classes of HTTP Protocol. HTTP/1.0 is the initial major version of HTTP network protocol. HTTP/2 (originally names HTTP/2.0) is subsequent major version of HTTP. HTTP 1.0 was sensitive to high latency connections, as every request had to be made sequentially. If two requests made simultaneously, you had to wait until the first was completed before making the second.
HTTP 1.1 improved this, by enabling pipelining. If the user wanted to make simultaneously two requests, they could send off both requests and then receive the responses back in order. However this suffered from head-of-line blocking problem, consequences intensive or slow request completed.
HTTP/2 aims to address these issues by changing how the client and server communicate over the wire. To do this it introduces two new concepts: frames and streams:
Frames: The smallest unit of communication in HTTP/2, each containing a frame header, which at a minimum identifies the stream to which the frame belongs.
Stream: A bidirectional flow of bytes within an established connection, which may carry one or more messages.
Message: A complete sequence of frames that map to a logical request or response message.
The utmost focus of HTTP/2 is performance, especially latency as perceived by the end-user while using a browser, with a secondary focus on network and server resource usage. One large benefit of HTTP/2 is the ability to use a single TCP connection from a browser to a website as compared to multiple TCP connections in HTTP/1.1. HTTP/2 uses push model as compared to pull model used by HTTP/1.1. A single TCP connection is all that’s required because HTTP/2 leverages multiplexing and allows asynchronous (parallel) requests. Image credit goes to stackoverflow.
Excerpt from High Performance Browser Networking: HTTP/2 does not modify the application semantics of HTTP in any way. All the core concepts, such as HTTP methods, status codes, URIs, and header fields, remain in place. Instead, HTTP/2 modifies how the data is formatted (framed) and transported between the client and server, both of which manage the entire process, and hides all the complexity from our applications within the new framing layer. As a result, all existing applications can be delivered without modification. It is important to note that HTTP/2 is extending, not replacing, the previous HTTP standards. The application semantics of HTTP are the same without having any changes in the core HTTP concept. While the high-level API remains the same, it is important to understand how the low-level changes address the performance limitations of the previous protocols. Let’s take a brief tour of the binary framing layer and its features.
No comments:
Post a Comment