Optimizing Proxies – Protocol Performance

The importance of the data transport protocol is of course crucial to a global information network like the world wide web.  Unfortunately the HTTP/1.0 protocol has some inherent issues which are directly related to performance which have been largely addressed in version 1.1 of the protocol.  It is expected that future developments will further improve the performance of the protocol.

One issue is related to the three way handshake that is required by TCP before it can establish the connection. It is important to remember that during this handshake phase that no application data is transferred at all.  from the user perspective the delay will simply appear as latency in getting the initial connection established.   This three way handshake involves a considerable overhear preceding data transfer and has a noticeable effect on performance particularly in busy networks.

This problem is made worse by using the HTTP 1.0 protocol which makes extensive use of new connections.  In fact every new request requires a new TCP connection to be established, complete with a new three way handshake.  This was originally implemented as a measure to boost performance because it was thought that it would avoid long lived idle connections being left dormant.  The reasoning was that it was more efficient to establish new connections when required as the data burst would be small and frequent.

However the web has not developed like this and it’s is much more than a series of short html files quickly downloaded.  Instead the web is full of large documents and pages embedded with videos and images.  Add to the the multitude of applets, code and other embedded objects and this soon adds up.  What’s more each of these objects usually has it’s own URL and so requires a separate HTTP request for each.    Even if you invest in a high quality US proxy you’ll find some impact on speed using HTTP 1.0 simply due ti the huge number of connection requests it generates.

There were modifications made to increase the perceived performance from the user perspective.  For one, the use of multiple simultaneous connections was allowed and this would allow client software like browsers to download and render multiple components on a page.  This meant that the user wasn’t left waiting as individual components were loaded separately.  However although parallel connections increase performance on an individual level, they generally have a very negative impact on the network as a whole.   The process is still inefficient and allowing parallel connections does little to mitigate this situation.

As any network administrator knows, focussing on a single aspect of network performance is rarely a good idea and will almost never improve overall network performance.    The persistent connection feature was introduced to help solve this, and was added as a non-standard extension to HTPP 1.0 and included by default with HTTP 1.1.

Further Reading: Proxies Blocked by BBC Abroad

Remote Login Methods

The ability to remotely login to a machine that’s miles away from you is perhaps one of the internet’s most popular applications.  It might not seem so, but being able to access a remote host without a hard wire connection has transformed many areas of IT particularly in support and development.   Obviously you need an account on the host that you are trying to login to, but actually using the machine as if you are at the console is extremely useful in many situations.

Two of the most famous applications for remote login access when using a TCP/IP based network (e.g like the internet) are Telnet and Rlogin.   The most famous and probably used by every IT support technician over the age of 25 is Telnet, installed as standard in almost every TCP/IP implementation.   It seems relatively simple but this actually hides some great functionality not least the ability to Telnet from one operating system to another.  It’s incredibly useful to be able to sit at a Microsoft Windows machine with multiple command interfaces open in separate windows to Unix and Linux machines at the same time.

Remember these terminal windows are actually like physically sitting at the remote host’s console.  This is is completely different from just using a web session or using something like an Italian to stream RAI player abroad like this.  Each individual character that you type is entered into the remote host, there’s no streaming, no relaying or filtering.  Obviously there are some restrictions about running a terminal windows on a completely different systems.  However Telnet does an option negotiation phase between the client and server to ensure that only services which are supported at both ends are available.

The other famous remote login application is called Rlogin which was developed from Berkeley Unix.   This application was initially only available on Unix Systems however it has been ported to most other operating systems now and you can Rlogin between Windows and Linux.  Both of these applications use the Client/Server configuration – the client is the system where the initial connection is established to the remote server which is the target.

Nowadays, the most popular of the two application – Telnet has become much more sophisticated.  Over the years lots of functionality has been added to Telnet whereas Rlogin remains quite simple and unmodified.  However it should be noted that although Rlogin lacks features, it is a simple and stable remote access application.

The author – John Herrington has worked in IT for over thirty years in a variety of roles from support to latterly Network manager at a large bank.   He now works for himself and runs one of the largest paid VPN services on the West Coast of America. He obviously works remotely a lot of the time but will rarely use Telnet as it’s too insecure!