ProxySG replaces legacy software proxies with appliances that not only secure Web communications but also expedite the delivery of business applications. ProxySG is built on a robust, scalable platform architecture they call SGOS, an object-based operating system that enables flexible policy control over content, users, applications and protocols.

SGOS, this purpose-built microkernel operating system, behaves as a proxy server for 15 protocols, including HTTP, FTP, SSL (forward and reverse), CIFS, MAPI, Telnet, SOCKS, P2P, Microsoft Media Services, RTSP, QuickTime, AOL IM, Yahoo IM, MSN Messenger, and TCP-Tunnel.

A sophisticated multi-protocol caching hierarchy streamlines WAN traffic through bandwidth management, protocol optimization (e.g., CIFS proxy), object caching, byte caching (of file components) and data compression.

Bandwidth Management/Traffic Shaping
This technique assigns a priority to a particular application’s (or user’s) traffic. Prioritizing designates which streams get right-of-way and assigns the amount of bandwidth the traffic receives. While this doesn’t make traffic go any faster on the network, it does ensure that the network is available first for the highest priority traffic.

Protocol Optimization
Protocol optimization takes protocols that are inefficient over the WAN (e.g., CIFS, MAPI, HTTP, TCP, HTTPS) and makes them more efficient – typically making what are traditionally serialized communications parallel. There are other optimizations, depending on the protocol (e.g., TCP session reuse) that can make starting up and tearing down flows faster. These optimizations don’t reduce the amount of bandwidth an application consumes, but can significantly reduce latency and speed application performance. The longer the WAN link, the greater the improvement.  Protocol optimizations have an enormous impact over satellite links, for example.

Byte Caching/Dictionary Compression
Byte caching is as it sounds – a low-level cache of small sub-application-object pieces of information. Typically, byte caching/dictionary compression schemes observe repetitive patterns moving between two caches in application traffic, symbolize those patterns with a token, and send the token in lieu of the bulky traffic – tokens being typically a byte or two, symbolizing large blocks (e.g., 64KB). The cache on the far end matches the token with the original block of data, reconstitutes the traffic, and sends it on to the application or user.

Rarely application-specific, byte caching/dictionary compression operates at a lower level, reducing bandwidth of all TCP traffic. Of course it has limitations: it can never reduce bandwidth as much as object caching (because some data must be transmitted), doesn’t reduce latency much, and doesn’t offload source servers.

Object Caching
Object caching is very different from byte caching. It’s protocol and application specific and it’s an all-or-nothing event. If the cache contains the object, the user is immediately served the object from a local store. A transmitted object that has been previously cataloged by the cache (a “cache hit”) essentially reduces bandwidth used and latency to zero. If the cache doesn’t contain the object (or contains an outdated version of the object), object caching does nothing for the immediate transaction but stores it for the next time that object is requested.

Compression
This technique uses a common algorithm (gzip, lz compression) to remove extraneous and/or predictable information from the traffic before transmission. The information gets reconstituted at its destination based on that same algorithm. Note that the two ends don’t synchronize. The first time something goes through travels at the same speed as the second. Compression reduces the data transmitted over the WAN link, but is limited in its ability to reduce bandwidth use and latency.

Learn more about the security features of the ProxySG.