DNS and HTTP are Killing The Web
/ / / DNS and HTTP are Killing The Web

THE WEB NEEDS MODERN SOLUTIONS

DNS & HTTP ARE KILLING THE WEB

A NEW DATA TRANSPORT PROTOCOL & ROBUST DOMAIN INFORMATION SYSTEM

HTTP wasn't built for the increasing needs of the modern web. HTTP is bloated, slow, chatty, and isn't capable of handling the bandwidth crisis. The modern demands of the web have drastically changed since HTTP was invented. New features require real-time change feeds, more bandwidth, speed, security, and bi-directional communication. The inadequacies of HTTP costs companies, (such as Amazon, Netflix, and Hulu), billions of dollars. Companies that depend on purchasing bandwidth from Network service providers will see a continual rise in bandwidth costs as this problem continues to go unchecked. All your favorite cryptocurrencies and their application layer fat protocols all sit on-top of HTTP. Tons of products and services that we use on a daily basis rely on this very protocol and it's slowly suffocating the web. If we don't fix this protocol problem there soon won't be a web to reasonable utilize. The web is going to be more expensive to use and increasingly slower as more devices come online. This is a huge problem that has gone unchecked and it's playing out on a global scale with global consequences.

Let's analyze the case of Amazon.

  1. A one second delay could cost Amazon 1.6BB in sales.
  2. "10 years ago,  Amazon found that every 100ms of latency cost them 1% in sales"
  3. "Fast forward 10 years later, a 2017 Akamai study shows that every 100-millisecond delay in website load time can hurt conversion rates by 7% – that is a significant drop in sales – 6% – from the time when Amazon first talked about latency in seconds and milliseconds. This goes to show that things aren’t getting any easier for online retailers as user experience is becoming critical to e-commerce success."

HTTP is based on an outdated network protocol called TCP. We have been advocating for a custom UDP based protocol and to our amazement HTTP3 was announced. This is how we know we are on the right track. HTTP3 drops TCP for UDP, bluntly speaking HTTP3 is a mixture of HTTP and QUIC. This is their last major effort at saving the web from itself. This will only buy us more time but it doesn't address the root of the problem. We have designed UDSP from scratch on-top of UDP and it was built with the needs of the modern web in mind.

Now let's look at Google.

Google invented a custom UDP based protocol QUIC which was being used to transport HTTP packets instead of HTTP. The same data was transferred but the amount of data sent back and forth including acknowledgements was noticeably less. This noteworthy increase in performance, was enough to keep Google using it. They quietly installed QUIC into Google browsers and Google services. Anyone using a Chrome browser was unknowingly utilizing QUIC. The result was QUIC saved Google and its users time & money. "1 packet (QUIC) can be up to 300ms of saved time for that initial connection" For any large company that in and of itself is a ton of overhead money saved.

HTTP

User's demands are becoming more and more time constrained. They expect instant gratification in milliseconds. As technology advances the expectations of the services we use increase. A modern web application utilizes both HTTP and WebSockets. Developers need to push all mission critical assets to their client in under a second and setup a real-time stream for further live updates. Applications will be opening and closing multiple connections throughout their life cycle. With this in mind we created a protocol that is better at doing both at the same time under a single connection, UDSP.

UDSP also doubles as a single sign-on for the entire Universal Web. When you establish a UDSP stream you are also logging into the service. All within the same packet in a 0-RTT handshake. Imagine not having to remember a username or password and not have to click a login button. Services could also instantly create an account for new users based on their ephemeral keypair being used to establish a UDSP connection. No signups, logins, and remembering passwords or usernames. This is the future of the web, it's the only logical conclusion forward.

DNS

HTTP costs companies time and money but that's not the only problem. DNS can drastically speed up the efficiency of connections. Our DIS provides cryptographic parameters in addition to traditional routing information in the form of a verifiable certificate. The DIS can return all this required data at a single point in time to establish a 0-RTT connection. In today's web a client must of visited a website before it could establish a 0-RTT connection on the next visit. This small feature eliminates drastic amounts of needless packets and bandwidth. Little things on a grand scale have drastic implications on network congestion, performance, overhead, user experience, and profits.

Another long standing issue with DNS is it's lack of trust and lack on consensus. We can see DNS servers go rogue, be used to censor speech, operate unencrypted, and compromising it's users. DNS has a multitude of security issues and a drastic lack of features. Sentivate's replacement of DNS is called a Domain Information System. The DIS returns a full cryptographic certificate with all required details to establish a connection in addition to other secondary certificates if requested. For those looking to dive into the technical issues with DNS we suggest first reviewing the Minimalt papers.

Imagine how much time & money Sentivate could save companies and users

when it doesn't have to worry about all the shortcomings of HTTP & DNS

SOURCES