Can Google make the web faster?
 

See Google's initiative on making the Web much faster through SSL: http://sites.google.com/a/chromium.o...pdy-whitepaper

The SPDY project defines and implements an application-layer protocol for the web which greatly reduces latency. The high-level goals for SPDY are:

* To target a 50% reduction in page load time. Our preliminary results have come close to this target (see below).
* To minimize deployment complexity. SPDY uses TCP as the underlying transport layer, so requires no changes to existing networking infrastructure.
* To avoid the need for any changes to content by website authors. The only changes required to support SPDY are in the client user agent and web server applications.
* To bring together like-minded parties interested in exploring protocols as a way of solving the latency problem. We hope to develop this new protocol in partnership with the open-source community and industry specialists.

THE PROBLEMS OF HTTP:

Unfortunately, HTTP was not particularly designed for latency. Furthermore, the web pages transmitted today are significantly different from web pages 10 years ago such and demand improvements to HTTP that could not have been anticipated when HTTP was developed. The following are some of the features of HTTP that inhibit optimal performance:

* Single request per connection. Because HTTP can only fetch one resource at a time (HTTP pipelining helps, but still enforces only a FIFO queue), a server delay of 500 ms prevents reuse of the TCP channel for additional requests. Browsers work around this problem by using multiple connections. Since 2008, most browsers have finally moved from 2 connections per domain to 6.
* Exclusively client-initiated requests. In HTTP, only the client can initiate a request. Even if the server knows the client needs a resource, it has no mechanism to inform the client and must instead wait to receive a request for the resource from the client.
* Uncompressed request and response headers. Request headers today vary in size from ~200 bytes to over 2KB. As applications use more cookies and user agents expand features, typical header sizes of 700-800 bytes is common. For modems or ADSL connections, in which the uplink bandwidth is fairly low, this latency can be significant. Reducing the data in headers could directly improve the serialization latency to send requests.
* Redundant headers. In addition, several headers are repeatedly sent across requests on the same channel. However, headers such as the User-Agent, Host, and Accept* are generally static and do not need to be resent.
* Optional data compression. HTTP uses optional compression encodings for data. Content should always be sent in a compressed format.

What would the urls look like?

Interesting ideas...

the internet belong to google.

I usually can't fucking stand big ass companies that rake in billions a year. But I love Google. They do so much shit that costs them money that they'll never make back. A while ago some article said that Google loses nearly a billion dollars a year on Youtube, yet the keep it going. On top of that, they'll pay people for ad's on videos that are getting mad hits... No company would do that, they'd take all the revenue themselves.

Then they have Google earth, which so far as I can tell, has no advertisements anywhere on it. They drive around in cars all day on every single street in every single city and get 360 pictures, again, losing money.

And now they want to make my internet's faster? FUCK YEA.