TL;DR: from TCP to UDP.
HTTP/3is on top of QUIC / UDP
- no need multi-round handshakes
- does not include error correction
- does not exist in an insecure or unencrypted version
- based on Google's work on QUIC
HTTP/2is on top of TCP
- multiple handshakes
- TCP is like a "data pipe", or stream, it does not understand the data it transmits, so additional security is provided by TLS/SSL
- based on Googles SPDY
- backwards compatible with HTTP/1.1
QUIC(Quick UDP Internet Connections) is Google's TCP replacement.
- Websocket: Say you want to build a Massive Multiplayer Online Game that needs a huge amount of messages from both ends of the connection. In such a case, WebSockets will perform much, much better. In general, use WebSockets whenever you need a truly low-latency, near realtime connection between the client and the server.
- HTTP/2: If your use case requires displaying real-time market news, market data, chat applications, etc., relying on HTTP/2 + SSE (Server-Sent Events) will provide you with an efficient bidirectional communication channel while reaping the benefits from staying in the HTTP world.
HTTP practically only allows one outstanding request per TCP connection. In the past, browsers have used multiple TCP connections to issue parallel requests
"One major goal is to allow the use of a single connection from browsers to a Web site."
- Binary: HTTP/2 is a binary protocol making it a lot more efficient when transferring data; HTTP 1.x is textual.
- Header Compression: HTTP Header size will be greatly reduced
- Single Connection: Only one connection to the server is used to load a website, and that connection remains open as long as the website is open. This reduces the number of round trips needed to set up multiple TCP connections.
- Multiplexing: Multiple requests are allowed at the same time, on the same connection. Previously, with HTTP/1.1, each transfer would have to wait for other transfers to complete. HTTP/2 is especially useful when dealing with TLS connections. The TLS handshake can be quite long but thanks to reduced latency and multiplexing, other requests can do their work without being blocked.
- HTTP/2 Server Push: Resources can be pushed to the client cache(or browser) proactively, but not to the client application itself, i.e. it still need to be processed by the browser. (HTTP/2 + SSE provides efficient HTTP-based bidirectional communication)
- Prioritization: Resources can have dependency levels allowing the server to prioritize which requests to fulfill first
With HTTP/1.1, many techniques were used to speed up websites that are no longer necessary with HTTP/2.
- Domain Sharding. Loading files from multiple subdomains so that more connections may be established. The increase in parallel file transfers adds to server connection overhead.
- Image Sprites. Combining image files to reduce requests. The file must be loaded before any image from the file can be shown, and the large image file ties up RAM.
- dealing with REST APIs, you will no longer have to batch requests.
- Many of the techniques mentioned above by developers placed additional strain on servers due to extra connections opened by browsers. These connection-related techniques are no longer necessary with HTTP/2. The result is lower bandwidth requirements, less network overhead and lower server memory usage.
- On mobile phones, multiple TCP connections could cause issues with the mobile network, causing them to drop packets and resubmit requests. The additional requests just added to the server load.
- HTTP/2 itself brings benefits for a server, as well. Fewer TCP connections are necessary, as stated above. HTTP/2 is easier to parse, more compact and less error-prone.
(Image from this blogpost)
POST: not idempotent, POST for multiple times will add multiple records PUT: idempotent, PUT multiple time the result will be the same
PUT: update full representation PATCH: modify part of data, PATCH is neither safe nor idempotent.
A GET Example
GET http://example.com/foo/bar Host: x Accept: application/xml
A POST Example:
POST /path/script.cgi HTTP/1.0 From: [email protected] User-Agent: HTTPTool/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 32 key1=val1&key2=val2
- Accept: specify the media type of the response content it is expecting
- Content-Type: specify the media type of request entity-body being sent from the client to the server
"please give me a json, not xml, if possible"
"the entity attached is a json, please use the correct parser when you(server) receive it"
Use 400 if the request parameters are wrong. Use 412 if one of the
If-* request headers like
If-Modified-Since, etc are wrong.
Why? That's just what RFC says. See for example this extract of If-Match specification:
If none of the entity tags match, or if "*" is given and no current entity exists, the server MUST NOT perform the requested method, and MUST return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method, such as PUT, from modifying a resource that has changed since the client last retrieved it.
The 502 Bad Gateway: one server on the internet received an invalid response from another server.
- DNS Lookup: URL->IP
- TCP Connection(socket)
- Send HTTP Request
- Server Response