Improvements In Several Problem Areas Of HTTP 1.1

Introduction

The prototype showed that it is possible to make improvements in several problem areas of HTTP 1.1 and can be done in a way that could lead to the unification of the Web with the related middleware systems COM, CORBA, and Java RMI.

The second part, Protocol Design Group (PDG), ran through late 1998 and produced and measured a prototype to study the feasibility of moving the Web onto an application-independent distributed object system.

Modularity and extensibility

Other applications include those that are closely related (e.g., WebDAV, DASL, and DELTAV), those that are less closely related (e.g., IPP , SWAP ), those that are based on partial clones of HTTP (e.g., SIP [16]), and those that are completely unrelated and based on the layering over HTTP of middleware systems of independent origin (e.g., COM, Java RMI, and some CORBA implementations) and of Web-conscious origin (e.g., XML-RPC, SOAP).

Should the application use a different port than the HTTP default of 80? Should the application use traditional HTTP methods (GET, POST, etc.) or should it define new methods? Should the application use http: URLs or define its own? Should the application define its own MIME types, or use something that already exists? Answering questions like this has been a real issue.

The well-known paradigm of explicit interfaces, as used in modern programming languages and RPC systems, would help manage the co-existence and evolution of the multiplicity of applications of HTTP, but HTTP does not support that paradigm.

The PDG called this application ‘The Classic Web Application’ (TCWA), to distinguish it from the great many other applications now using HTTP.

Networking performance and fairness

While it might appear that there is a viable alternative in using HTTP 1.1’s Range header, there are some problems with that approach: (1) it is relatively recently standardized, so uniform server support cannot be assumed; and (2) the Range header’s interactions with other features of HTTP are unclear or bad (e.g., HTTP=1.1 offers integrity checking on messages, not documents ).

The use of verbose text-based representations for ‘headers’ and other protocol-level data, and the confusion between that layer and human-readable documents and mail messages, leads to unnecessarily high numbers of bytes used for protocol overheads and method parameters.

These include inefficient use of the network, poor latency delivered to the users, and a tendency to abuse the network with multiple parallel TCP streams.

Commonly deployed TCP implementations do not share congestion-avoidance state between parallel streams, leading to less efficient reactions to network conditions.

URIs bound to protocol stacks

Without the possibility of multiple stacks, it is not possible to incrementally move the current Web onto a new transport subtensor offer multiple alternatives for any other reason — except by using mechanisms (such as HTTP redirections or UPGRADE) that cost additional round trips.

Tunneled traffic vs. firewalls

The great variety and obscurity of ways of tunneling general applications through HTTP makes it hard for a firewall to do anything with HTTP traffic.

Nor does a firewall benefit a trusted and trustworthy insider who fully secures his machines

The practice of tunneling general applications through HTTP makes the job of a firewall harder.

Unifying the Web with COM, CORBA, and Java RMI

The prototype solution to the above problem areas is based on factoring HTTP into three layers: (1) transport of opaque byte or message streams; (2) application-independent remote method invocation; and (3) the document fetching storing application.

The lower two layers suffice to serve the needs of the other applications currently being layered over all of HTTP and provide a platform on which to deploy and evolve a large collection of applications.

The prototype design

The lowest layer addresses transport of opaque messages or streams, that allows composition of ‘transport filters’, included is a design of a particular multiplexing filter that addresses some shortcomings of current TCP and provides a service abstraction that can insulate higher layers from certain desirable and expected changes in the lower levels.

The transport layer

The transport layer is very similar to the corresponding layer in ILU and addresses reliable ordered bidirectional transport of opaque byte or message streams.

A transport filter apparatuses reliable ordered bidirectional transport of opaque byte streams or of opaque messages.

This transport layer is modular and offers controlled evolution, its flexibility is part of the solution to the problem of the strong linkage between URIs and protocol stacks.

The transport layer addresses problems with modularity and extensibility, networking performance and fairness, transport flexibility, and even contributes to unifying middleware systems.

The MUX filters

The MUX filter adds: (1) the restricting of messages; (2) the multiplexing of parallel message streams over a single underlying byte stream; (3) the ability of the accepting (server) side of the byte stream connection to initiate message stream connections in the reverse direction.

The ability of a byte stream connection receiver to initiate message stream connections in the reverse direction may be useful both (1) to solve the same performance problems mentioned above and (2) to enable callbacks from servers to clients behind firewalls.

For the ability to initiate message stream connections in the reverse direction to be useful, it is helpful to allow the byte stream initiator to give the acceptor some identification of what services can be reached at the initiator side.

The multiplexing of parallel message streams into a single byte stream addresses some of the net- work performance problems of HTTP.

The remote invocation layers

The middle layer’s design may be organized into three parts: (1) a type system for the data passed in the calls; (2) a way of encoding those data in serial bytes; and (3) the call framing and other conventions needed to implement remote invocations in terms of opaque messages.

The middle layer addresses problems of modularity and extensibility, network performance, the binding of object identifiers to protocol stacks, the opacity of tunneled traffic to firewalls, and the unification of the Web with related middleware systems.

The data type system

The problems for the data type system to solve are: (1) be enough for good expression of TCWA as well as other applications being layered on HTTP; and (2) unify the type systems of COM, CORBA, and Java RMI.

In this report, the term ‘object’ is used consistently for the level of software organization known as an ‘object’ in CORBA and Java RMI, and the term ‘object type’ for a type for objects (both when typing objects passed by reference and objects passed by value).

In Java RMI, every type for objects passed by reference is an ‘interface’; both ‘interfaces’ and ‘classes’ may be used as types for objects to be passed by value.

One of the biggest areas of difference among the type systems to be unified is in the question of multiple inheritance for object reference types.

In addition to differing over the preservation of pointer equality, the type systems to be unified differ on the question of whether objects passed by reference have meaningful identities.

Memory management is implicitly present for all object reference types in CORBA and Java RMI, and it is handled in a similar way (reference counting) for the programming language mappings in common with COM, so there is no real difference there.

In CORBA and Java RMI, every object type is implicitly ‘optional’, meaning that the null value is included in the type.

For the sake of type system modularity, this is broken out as part of a separate ‘reference’ constructor: a pointer-equality- preserving type can be constructed from any ‘base’ type; non-reference types do not promise any pointer equality preservation.

The data encoding

The data encoding defines how data of types de- scribed above are encoded into bytes for transport and does so in a way that addresses network performance problems and the rigid binding between object identities and transport stacks.

The encoding of an object reference has a structure like that in CORBA; this structure includes separate places for the object’s (1) identity, (2) type information, and (3) contact information.

The RPC protocols

The message formats facilitate modularity extensibility by having an application-independent section of protocol extensions, analogous to ‘service con- texts’ in CORBA’s GIOP.

The RPC headers in a request message improve network performance by using sender-managed ta- bles to reduce the bytes needed to transmit common values.

The RPC protocol defines the formats of the messages exchanged to effect RPCs and does so in a way that addresses modularity=extensibility and net- work performance.

The Web application layer

At the base we can start with a very simple version of the application, which could be rendered in OMG IDL as follows: module TCWA { interface Resource { status code GET ; status code PUT; status code POST ; }; }; More sophisticated versions are rendered as sub- types with cloned operations with added parameters relevant to the various advanced features of HTTP, such as caching, content negotiation, and so on.

Experimental results

ILU also supports alternatives at the RPC layer, and the main comparisons were done using ILU implementations of the middle layer of HTTP-NG as well as the corresponding parts of HTTP=1.0 and HTTP=1.1. For the tests reported here, a network interface that supports the caching and content negotiation features of HTTP was used, although those features were not specifically measured.

To get an idea of how well that would work, we took the ‘test1’ test case from the ILU system, and ran the ANSI C client from that test against the ANSI C server from that test, using both the CORBA IIOP 1.0 protocol and the HTTP-NG protocol.

Future and related work

However, these fail to address the underlying problems with HTTP, and make only a limited contribution to unifying COM with the other popular middleware systems (the biggest limit is that no attention is paid to object types from the other systems).

The unification of the Web with other middleware systems would profit from further work on the middle layer of HTTP-NG as well as on the other systems, to help them all converge.

Conclusion

Janssen / Computer Networks all the addressed problem areas simultaneously, and that suggests that unification of the Web with COM, CORBA, and Java RMI is possible.