📄 Table of Contents
◉ What is Http ?
Hypertext Transfer Protocol (HTTP) is the de-facto application protocol that is, currently, the foundation of data communication for the World Wide Web.
HTTP is based on the Client/Server model. Client/Server model can be explained as two computers, Client (receiver of service) and Server (provider of service) that are communicating via requests and responses.
A simple and abstract example would be a restaurant guest and a waiter. The guest (Client) asks (sends request) waiter (Server) for a meal, then the waiter gets the meal from the restaurant chef (your application logic) and brings the meal to the guest.
◉ What is Https?
HTTPS, the lock icon in the address bar, an encrypted website connection — it’s known as many things. While it was once reserved primarily for passwords and other sensitive data, the entire web is gradually leaving HTTP behind and switching to HTTPS.
The “S” in HTTPS stands for “Secure”. It’s the secure version of the standard “hypertext transfer protocol” your web browser uses when communicating with websites.
How HTTP Puts You At Risk
When you connect to a website with regular HTTP, your browser looks up the IP address that corresponds to the website, connects to that IP address, and assumes it’s connected to the correct web server. Data is sent over the connection in clear text. An eavesdropper on a Wi-Fi network, your internet service provider, or government intelligence agencies like the NSA can see the web pages you’re visiting and the data you’re transferring back and forth.
There are big problems with this. For one thing, there’s no way to verify you’re connected to the correct website. Maybe you think you accessed your bank’s website, but you’re on a compromised network that’s redirecting you to an impostor website. Passwords and credit card numbers should never be sent over an HTTP connection, or an eavesdropper could easily steal them.
These problems occur because HTTP connections are not encrypted. HTTPS connections are.
How HTTPS Encryption Protects You
HTTPS is much more secure than HTTP. When you connect to an HTTPS-secured server — secure sites like your bank’s will automatically redirect you to HTTPS — your web browser checks the website’s security certificate and verifies it was issued by a legitimate certificate authority. This helps you ensure that, if you see “https://bank.com” in your web browser’s address bar, you’re actually connected to your bank’s real website. The company that issued the security certificate vouches for them. Unfortunately, certificate authorities sometimes issue bad certificates and the system breaks down. Although it isn’t perfect, though, HTTPS is still much more secure than HTTP.
When you send sensitive information over an HTTPS connection, no one can eavesdrop on it in transit. HTTPS is what makes secure online banking and shopping possible.
It also provides additional privacy for normal web browsing, too. For example, Google’s search engine now defaults to HTTPS connections. This means that people can’t see what you’re searching for on Google.com. The same goes for Wikipedia and other sites. Previously, anyone on the same Wi-Fi network would be able to see your searches, as would your Internet service provider.
◉ What is Http/2?
In 2015, Internet Engineering Task Force (IETF) release HTTP/2, the second major version of the most useful internet protocol, HTTP. It was derived from the earlier experimental SPDY protocol.
Main goals of developing HTTP/2 was:
- Request multiplexing over a single TCP connection
- Compression of request headers
- Binary protocol
- HTTP/2 Server Push
- Protocol negotiation mechanism — protocol electing, eg. HTTP/1.1, HTTP/2 or other.
- Page load speed improvements through
- High-level compatibility with HTTP/1.1 — methods, status codes, URIs and header fields.
- Request pipelining
- HOL blocking (Head-of-line) — Package blocking
HTTP/2 can send multiple requests for data in parallel over a single TCP connection. This is the most advanced feature of the HTTP/2 protocol because it allows you to download web files asynchronously from one server. Most modern browsers limit TCP connections to one server.
This reduces additional round trip time (RTT), making your website load faster without any optimization, and makes domain sharding unnecessary.
HTTP/2 compress a large number of redundant header frames. It uses the HPACK specification as a simple and secure approach to header compression. Both client and server maintain a list of headers used in previous client-server requests.
HPACK compresses the individual value of each header before it is transferred to the server, which then looks up the encoded information in a list of previously transferred header values to reconstruct the full header information.
The latest HTTP version has evolved significantly in terms of capabilities and attributes such as transforming from a text protocol to a binary protocol. HTTP1.x used to process text commands to complete request-response cycles. HTTP/2 will use binary commands (in 1s and 0s) to execute the same tasks. This attribute eases complications with framing and simplifies implementation of commands that were confusingly intermixed due to commands containing text and optional spaces.
Browsers using HTTP/2 implementation will convert the same text commands into binary before transmitting it over the network.
- Low overhead in parsing data — a critical value proposition in HTTP/2 vs HTTP1.
- Less prone to errors.
- Lighter network footprint.
- Effective network resource utilization.
- Eliminating security concerns associated with the textual nature of HTTP1.x such as response splitting attacks.
- Enables other capabilities of the HTTP/2 including compression, multiplexing, prioritization, flow control and effective handling of TLS.
- Compact representation of commands for easier processing and implementation.
- Efficient and robust in terms of processing of data between client and server.
- Reduced network latency and improved throughput.
HTTP/2 Server Push
This capability allows the server to send additional cacheable information to the client that isn’t requested but is anticipated in future requests. For example, if the client requests for the resource X and it is understood that the resource Y is referenced with the requested file, the server can choose to push Y along with X instead of waiting for an appropriate client request.
- The client saves pushed resources in the cache.
- The client can reuse these cached resources across different pages.
- The server can multiplex pushed resources along with originally requested information within the same TCP connection.
- The server can prioritize pushed resources — a key performance differentiator in HTTP/2 vs HTTP1.
- The client can decline pushed resources to maintain an effective repository of cached resources or disable Server Push entirely.
- The client can also limit the number of pushed streams multiplexed concurrently.
If you remember the story about a guest in a restaurant and waiter, that would be an example
for HTTP/1.1 and HTTP/2 protocol with a slight difference. Imagine that waiters are TCP connections and you want to order your meal and a bottle of water. For HTTP/1.1 that would mean that you ask one waiter for your meal and another one for water, hence you would allocate two TCP connections. For HTTP/2 that would mean that you ask only one waiter for both, but he brings them separately. You only allocate one TCP connection and that will already result with lower server load, plus the server would have one extra free connection (waiter) for the next client (guest).
The real difference between HTTP/1.1 and HTTP/2 comes with server push example.
Imagine that the guest (Client) asks (sends request) waiter (Server) for a meal, then the waiter gets the meal from the restaurant chef (your application logic), but the waiter also thinks you would need a bottle of water so he brings that too with your meal. The end result of this would be only one TCP connection and only one request that will significantly lower the server load.
Most of the modern browser fully support HTTP/2 protocol with an exception (red) of Opera mini (all versions) and UC Browser for Android. There are also the ones that have partial support (light green) like IE11.
You can find more details on browser support on this link https://caniuse.com/#feat=http2
Use HTTP/2 and speed up your site
HTTP/2 provides us with many new mechanics that will mitigate HTTP/1.1 issues and ones that will boost your web page performance. Currently, it is widely supported by web clients so its implementation is painless. Although implementation of HTTP/2 protocol is easy you should have in mind that with it you will probably have to change the mechanics (like serving assets to the client) to use the full potential of this protocol.
If you have some other information and experience about this theme feel free to share it and also share this article if you think it would help out your fellow colleagues or friends.
◉ HTTP Caching
You might have heard about caching. We have several types of caching database caching, CDN caching, DNS caching etc.. However, web caching or HTTP caching which occurs at application level is what we are going to discuss in this article.
Caching, in general is a mechanism to prevent fetching the same resource, if unchanged again and again costing data and affecting performance. The retrieval of previously fetched resource can be prevented by storing the data locally and verifying the presence of a resource locally before making any other request.
This can be achieved by passing some special cache directives in the response headers of an HTTP request.
Cache-control: This is the caching directive that is used to specify who can cache a resource and how long one can cache it. This takes the values
- max-age: This takes the value of the time period for which the resource is valid and can be reused from the cache.
- public or private: “public” lets the resource to be cached even if it has HTTP authentication associated with it. A resource with “private” in the cache-control directive prevents intermediate caching and allows only the end user to cache it.
- no-cache or no-store: “no-cache”means the client must validate the freshness of a resource even though the resource is cached. “no-store” disallows the browser and all intermediate caches from storing any response.
◉ TCP/IP vs. HTTP
TCP/IP made the internet, and HTTP made the web. There would be no web without HTTP and no internet without TCP and IP.
Using a web browser to retrieve information from a web server may seem like a simple process, but it requires a full stack of network protocols operating at different network abstraction layers to deliver web content.
Simply put, HTTP — the Hypertext Transfer Protocol — is the set of rules defining how a web browser and web server communicate by exchanging requests and responses to those requests. HTTP operates at the application layer of the TCP/IP networking model, meaning it defines the exchange of requests and replies to enable an end user to access data and services from a server. There is no choice to be made when considering TCP/IP vs. HTTP — both are necessary for the web to work.
Where HTTP refers to a single protocol, TCP/IP names two protocols: the Transmission Control Protocol and the Internet Protocol. However, the acronym is often used to refer to the entire suite of internetworking protocols that use or depend on TCP and IP to operate, including application protocols, such as Telnet/Secure Socket Shell (SSH), File Transfer Protocol and HTTP. While the acronym is often used to refer to just TCP and IP, it can also refer to all the protocols that support or supplement TCP/IP, including IPsec and IPv6.
similarities of TCP/IP vs. HTTP?
When comparing TCP/IP vs. HTTP, the most important similarities are that they are networking protocols that are defined and documented by the Internet Engineering Task Force (IETF) for use on the global public internet. In the case of HTTP, the specification is coordinated by the IETF and the World Wide Web Consortium.
differences between TCP/IP vs. HTTP?
The primary differences of TCP/IP vs. HTTP relate to the abstraction layers at which they operate.
HTTP operates at the application layer of the TCP/IP networking model, and it implements communication between a client and a server. HTTP messages are, ultimately, delivered through TCP/IP connections. But the lower layers are obscured, and HTTP itself defines how commands and responses are formatted and delivered. An HTTP exchange might consist of a request from a browser to view content on a particular URL and a response from the server containing the data on the requested webpage.
How does TCP/IP work with HTTP?
The application layer is the highest layer in the TCP/IP model; TCP operates at the transport layer, which enables communication between processes. HTTP depends on TCP to format and deliver the HTTP commands and responses in a form that the web server, which is running as a program on some computer, can understand and a form that the web browser, also running as a program, can use as output to the application layer.
And while TCP mediates communication between processes running on hosts, it is IP itself that makes it possible for transport layer data to be transmitted across the internet for delivery of data between the client and server. IP operates at the network layer, and it defines how network traffic of all types can be exchanged between hosts located anywhere on the global internet.
While HTTP specifies how a browser and a client interact, all application layer protocols depend on protocols at the transport layer, and all transport layer protocols depend on IP. For HTTP, that means protocol messages are incorporated in TCP segments, which, in turn, are encapsulated or wrapped up into IP packets. Other applications may have the option to use either TCP or UDP, the User Datagram Protocol.
Why is TCP used with HTTP?
Internet applications use protocols at every layer of the TCP/IP network model, with protocols at each layer encapsulating the data related to the protocols used in the layer above. All internet applications need to use a transport layer protocol. Interactive internet applications that require guaranteed, in-order delivery of data — like browsing the web or doing terminal emulation or remote desktop access — use TCP. Other applications that can operate with simple request/reply interactions — like DNS — can use the simpler UDP.