Tubes so fast they’re blurry. Image: Wetsun/Flickr.

The team behind Nginx (pronounced engine-ex) have released version 1.4, which brings a number of new features, most notably support for the SPDY protocol.

SPDY, the HTTP replacement, promises to speed up website load times by up to 40 percent. Given that Nginx is the second most popular server on the web — powering big name sites like Facebook and WordPress — the new SPDY support should prove a boon for the nascent protocol. Apache, still far and away the most popular server on the web, also has a mod_spdy module.

SPDY support should also help make Nginx more appealing, not that it needs much help. Nginx’s winning combination of lightweight and fast have made it the darling of the web in recent years with everyone from Facebook to Dropbox relying on it in one form or another.

Indeed, part of Nginx’s success lies in its versatility. The server can be used for everything from a traditional high performance web server to a load balancer, a caching engine, a mail proxy or an HTTP streaming server.

It’s worth noting that if you’re installing Nginx 1.4 on a Linux server directly from your distro’s repos the new SPDY support may not be enabled. See the Nginx documentation for instructions on building from source with SPDY support enabled.

SPDY isn’t the only thing new in Nginx 1.4, there’s also support for proxying WebSocket connections and a new Gunzip module that decompresses gzip files for clients that do not support gzip encoded files.

For more details and to grab the latest Nginx source, head on over to the Nginx website.

Firefox 13's New Tab page

If you don’t want to wait that long, you can download Firefox 13 from the beta release channel today.

Perhaps the best new feature in Firefox 13 is what’s known as “tabs on demand.” Tabs on demand refers to the way Firefox restarts when you have multiple tabs open. Firefox will now only restore the currently selected tab; background tabs are not loaded. Tabs on demand is a welcome relief for those of us who browse with dozens of tabs open all the time. You no longer need to fear restarting the browser since you won’t have to wait while every tab reloads. Instead, tabs will load only when you select them.

Firefox 13 will bring a slightly new look to some parts of the browser; both the New Tab and the Home Page have been redesigned. The New Tab page now has links to your most recently and frequently visited sites. It looks more or less just like Opera’s Speed Dial, which Chrome also mimics. There’s an option to pin your favorite sites, as well as a button for rejecting sites you don’t want to see.

The default Home Page now has links to menu items like Bookmarks, History, Settings, Add-ons, Downloads and Sync Preferences. There’s nothing here that you can’t access from the menu bar, but it makes frequently used menu items easier for newcomers to find.

Web developers will be glad to know that Firefox 13 introduces support for Google’s not-quite-yet-a-standard SPDY protocol (technically the last two Firefox releases have supported SPDY, but this is the first to have it enabled by default). The SPDY protocol improves on HTTP and in many cases can significantly reduce page load times. SPDY’s other main advantage over HTTP is that all traffic is encrypted. Once Firefox 13 and the Opera 12 preview arrive in final form the majority of desktop browsers on the web will support SPDY.

The Firefox 13 beta also brings a number of improvements to the new Developer Tools. For example, the Page Inspector now allows you to lock in CSS pseudo-classes on inspected page elements — handy for checking out what’s happening in a :hover code block.

For more details on everything that’s new in the developer tools and the rest of Firefox 13, check out Mozilla’s release notes.

Photo: Lindsey Turner/Flickr

Not coincidentally, that standards body, the Internet Engineering Task Force (IETF), is meeting this week to discuss the future of the venerable Hypertext Transfer Protocol, better known as HTTP. On the agenda is creating HTTP 2.0, a faster, modern approach to internet communication.

One candidate for HTTP 2.0 is Google’s SPDY protocol. Pronounced “speedy,” Google’s proposal would replace the HTTP protocol — the language currently used when your browser talks to a web server. When you request a webpage or a file from a server, chances are your browser sends that request using HTTP. The server answers using HTTP, too. This is why “http” appears at the beginning of most web addresses.

The SPDY protocol handles all the same tasks as HTTP, but SPDY can do it all about 50 percent faster. Chrome and Firefox both support SPDY and several large sites, including Google and Twitter, are already serving pages over SPDY where possible.

Part of the IETF’s agenda this week is to discuss the SPDY proposal, and the possibility of turning it into a standard.

But now Microsoft is submitting another proposal for the IETF to consider.

Microsoft’s new HTTP Speed+Mobility lacks a catchy name, but otherwise appears to cover much of the same territory SPDY has staked out. Though details on exactly what HTTP Speed+Mobility entails are thin, judging by the blog post announcing it, HTTP Speed+Mobility builds on SPDY but also includes improvements drawn from work on the HTML5 WebSockets API. The emphasis is on not just the web and web browsers, but mobile apps.

“We think that apps — not just browsers — should get faster,” writes Microsoft’s Jean Paoli, General Manager of Interoperability Strategy.

To do that, Microsoft’s HTTP Speed+Mobility “starts from both the Google SPDY protocol and the work the industry has done around WebSockets.” What’s unclear from the initial post is exactly where HTTP Speed+Mobility goes from that hybrid starting point.

But clearly Microsoft isn’t opposed to SPDY. “SPDY has done a great job raising awareness of web performance and taking a ‘clean slate’ approach to improving HTTP,” writes Paoli. “The main departures from SPDY are to address the needs of mobile devices and applications.”

SPDY co-inventor Mike Belshe writes on Google+ that he welcomes Microsoft’s efforts and looks forward to “real-world performance metrics and open source implementations so that we can all evaluate them.”

Belshe also notes that Microsoft’s implication that SPDY is not optimized for mobile “is not true.” Belshe says that the available evidence suggests that developers are generally happy using SPDY in mobile apps, “but it could always be better, of course.”

The process of creating a faster HTTP replacement will not mean simply picking any one vendor’s protocol and standardizing it. Hopefully the IETF will take the best ideas from all sides and combine them into a single protocol that can speed up the web. The exact details — and any potential speed gains — from Microsoft’s HTTP Speed+Mobility contribution remain to be seen, but the more input the IETF gets the better HTTP 2.0 will likely be.

Photo: dark_ghetto28/Flickr

Twitter has embraced Google’s vision of a faster web and is now serving webpages over the SPDY protocol to browsers that support it.

SPDY, pronounced “speedy,” is a replacement for the HTTP protocol — the language currently used when your browser talks to a web server. When you request a webpage or a file from a server, chances are your browser sends that request using HTTP. The server answers using HTTP, too. This is why “http” appears at the beginning of most web addresses.

The SPDY protocol handles all the same tasks as HTTP, but SPDY can do it all about 50 percent faster.

SPDY started life as a proprietary protocol at Google and worked only in the company’s Chrome web browser. SPDY has since won support elsewhere. Firefox will have SPDY support when version 11 hits prime time in the near future [Update: As Mozilla's Chris Blizzard points out, SPDY is disabled by default in Firefox 11. If you're using the beta and want to give it a try, you'll need to visit about:config, search for network.http.spdy.enabled and set the value to true. If all goes well SPDY will be turned on by default in Firefox 13.]. Amazon also baked SPDY support into its Silk browser for the Kindle.

The IETF’s HTTPbis Working Group — the standards body charged with creating and maintaining the HTTP specification — is now considering adding SPDY to HTTP 2.0, which will improve the speed of HTTP connections.

Despite the web standards backing, SPDY still has a long way to go before it’s an everyday part of the web. With only Chrome and Firefox behind it, SPDY is still only available for about 40 percent of desktop users. But with large services like Twitter throwing their weight behind it, SPDY may well start to take the web by storm — the more websites that embrace SPDY the more likely it is that other browsers will add support for the faster protocol.

If you’d like to follow Twitter’s lead and get your own site serving over SPDY, check out mod_spdy, a SPDY module for the Apache server (currently a beta release).

As part of Google’s continuing quest to dole out web pages ever more quickly, the search giant has proposed a number of changes to Transmission Control Protocol (TCP), the ubiquitous Internet protocol used to reliably deliver HTTP and HTTPS data (and much more besides) over the ‘net.

Google’s focus is on reducing latency between client machines and servers, and in particular, reducing the number of round trips (either client to server and back to client, or vice versa) required. When data is sent over a TCP connection, its receipt must be acknowledged by the receiving end. The sending end can only send a certain number of packets before it must wait for an acknowledgement. The time taken to receive an acknowledgement is governed by the round-trip time (RTT). With high bandwidth, high latency connections, clients and servers can end up spending most of their time waiting for acknowledgements, rather than sending packets.

When a new connection is made, a computer may initially send three packets before acknowledgement is required. Google wants to increase this to 10. With 10 packets, a browser can typically deliver an entire HTTP request to a server before it has to stop and wait for a reply.

TCP connections require a certain amount of negotiation between client and server, requiring a round trip, before data can be sent. Google is proposing to modify TCP so that some data can be sent during that negotiation, so that the server will have it on hand already, and can start processing it straight away.

TCP waits a predetermined time (the RTO or retransmission timeout) for acknowledgments to arrive. If the RTO expires, unacknowledged packets are assumed lost and retransmitted. This ensures that if the data has been lost in transmission that the sender is never waiting for an acknowledgement that will never arrive. This timeout value varies according to the network conditions and RTT, with a default of three seconds. Google wants to reduce this default to 1 second, so that if data has been lost, neither end needs to wait so long before it has another go.

Finally, Google wants to use a new algorithm to adjust how TCP connections react to packet loss. Packet loss can indicate networks that are congested, and TCP reacts by reducing the rate at which data is sent when this congestion is detected. The company claims that the algorithms currently used to respond to this packet loss can exact too great a penalty, making connections slow down too much and for too long, and that its new algorithm is better.

In addition to these proposed changes, Google is also suggesting other modifications, especially to make TCP recover better on mobile networks.

Changing TCP is not to be taken lightly. The protocol is already suffering due to buffer bloat undermining its built-in handling of network congestion. While Google’s proposed changes are well intentioned and might improve network performance, they come with the risk that an overlooked problem or a bad interaction with other traffic could cause widespread damage to the internet.

The proposed changes to TCP to reduce latencies and start sending data sooner are a continuation of previous work Google has done to try to make web serving, in particular, faster. The company has previously proposed other modifications to protocols such as SSL to similarly accelerate data transmission.

More far-reaching than these SSL tweaks is Google’s proposed alternative to the HTTP protocol that underpins the web: SPDY.

Initially, SPDY was a proprietary Google protocol implemented only in Google’s Chrome browser. That’s changing, however. Amazon’s Silk browser includes SPDY support, and Firefox 11 will include preliminary SPDY support. Partially motivated by SPDY’s uptake, the IETF’s HTTPbis Working Group — the team of industry experts tasked with maintaining and developing the HTTP specification — is considering the development of a new specification, HTTP/2.0, with the goal of improving the performance of HTTP connections. The working group will solicit suggestions from the industry, and with two, soon to be three implementations already, SPDY is likely to be well placed among those suggestions.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Photo: Ariel Zambelich/Wired.com