What the BEEP do we know!?

Cisco Systems

Unfortunately, most application protocol design has not enjoyed as excellent a history as TCP. Engineers design protocols the way monkeys try to get to the moon—that is, by climbing a tree, looking around, and finding another tree to climb. Perhaps this is because there are more distractions at the application layer. For example, as far as TCP is concerned, its sole reason for being is to provide a full-duplex octet-aligned pipe in a robust and network-friendly fashion. The natural result is that while TCP’s philosophy is built around “reliability through retransmission,” there isn’t a common mantra at the application layer.a

The Blocks Extensible Exchange Protocol (BEEP) is something like “the missing link between the application layer and the Transmission Control Protocol (TCP).”

Compared to SPDY – Google addresses the question like:

Q: What about BEEP?
A: While BEEP is an interesting protocol which offers a similar grab-bag of features, it doesn’t focus on reducing the page load time. It is missing a few features that make this possible. Additionally, it uses text-based framing for parts of the protocol instead of binary framing. This is wonderful for a protocol which strives to be as extensible as possible, but offers some interesting security problems as it is more difficult to parse correctly.

Good or Bad – I actually do not care – important for me would be to fix the Session Layer and Application Layer in combination with the way the world wide web is working – so get the work done and update the applications using those protocols.

SPDY: An experimental protocol for a faster web

SPDY Whitepaper Executive Summary

As part of the “Let’s make the web faster” initiative, we are experimenting with alternative protocols to help reduce the latency of web pages. One of these experiments is SPDY (pronounced “SPeeDY”), an application-layer protocol for transporting content over the web, designed specifically for minimal latency.  In addition to a specification of the protocol, we have developed a SPDY-enabled Google Chrome browser and open-source web server. In lab tests, we have compared the performance of these applications over HTTP and SPDY, and have observed up to 64% reductions in page load times in SPDY. We hope to engage the open source community to contribute ideas, feedback, code, and test results, to make SPDY the next-generation application protocol for a faster web.

Few months ago I stumbled over SPDY and was wondering if the known proxy implementations will ever be able to handle this protocol. Now, it is getting more and more interesting for products like Ironport’s Web Proxy to handle SPDY (somehow). Google is going to switch theire protocol handling for Google Apps in combination with Google Chrome to the faster and more secure SPDY protocol in the near future.

At Let’s make the web faster you can find lots of articles and user discussions about several things Google uses to fix the slow HTTP handling. From my point of view – it is necessary to exchange the HTTP(s) paradigm with a better one, which fits the needs of the internet we know!

And you would be surprised how easy it is to extend your WebApp to support SPDY besides the traditional HTTP(s) handling.

htsh: http shell

Adeel Khan hat eine weitere HTTP shell mit dem Namen HTSH der weiten Welt vorgestellt. Genutzt wird PHP und jQuery. Es unterstützt einige Shell Commands wie cd, chmod, cp, edit, exit, ls, mkdir, mv, rm, rmdir, touch, unzip und zip. Das schöne jedoch ist, dass man einfach neue Kommandos hinzuzufügen kann und das es Tab-Completion gibt.

Es ist ein Demo verfügbar und alle anderen installieren es sich auf dem eigenen Server.