WO2007000493A1

WO2007000493A1 - Data compression arrangement

Info

Publication number: WO2007000493A1
Application number: PCT/FI2006/050282
Authority: WO
Inventors: Mika Honkanen; Mika Leivo; Juha-Matti Liukkonen; Timo METSÄLÄ
Original assignee: Ascia Oy
Priority date: 2005-06-29
Filing date: 2006-06-27
Publication date: 2007-01-04
Also published as: FI20055357A0; FI20055357L

Abstract

Selective compression in a server device (10) which also controls access of the client devices (15, 16) to the application servers (8, 9, 17, 18), such that upon observing a given connection as a low-rate connection based on identification of the user or the user type, the server activates data compression for the observed low-rate connection. For example, the server device (10) may be arranged to activate data compression for users (15) of a mobile communications system (14), and to not activate data compression for users (16) of a broadband wire-line communications system.

Description

DATA COMPRESSION ARRANGEMENT

FIELD OF THE INVENTION

The invention relates to communications systems, and particularly to data compression.

BACKGROUND OF THE INVENTION

The Internet is a global network of networks of computers. Nodes in the Internet may include routers, gateways and hosts. At the edge of the Internet, there are hosts, end devices, which provide the services and facilities used by other applications and hosts. Typically, a client-server protocol is used between the networked hosts in which one computer (the client) requests the services of the other (the server). The end devices may include, for example, large mainframe computers, personal computers (PCs), laptops, palmtops, personal digital assistants, (PDAs), mobile phones, etc. Routers are machines that forward packets between other machines, and gateways are machines that are typically situated on the boundary between two networks to allow communications to pass between the networks. The core of the Internet is the Transport Control Protocol/Internet Protocol (TCP/IP) technology used for transporting the IP packets. World Wide Web (WWW) is the most widely used service in the Internet. A WWW page (a web page) is an information entity based, for example, on an hypertext markup language (HTML) file or Java file in the Web that can be reproduced with the user's web browser. A web page can contain text, images, animations, sound, moving video images and hypertext links to other web pages.

A typical user wants to access a server, perhaps to browse a web page. The client device is connected to the Internet through an access network. The access network could be any one of many possibilities, including wire-line alternatives like telephone-line modem dial-up, cable modem, or Digital Subscriber Line (DSL). It could also be one of the wireless alternatives, such as wireless LAN and digital mobile networks, such as GPRS that is an enhanced packet service added to GSM systems.

Wire-line modem dial-up provides a relatively low rate connection (up to 56 kbs) which has become insufficient for the increasing data volumes downloaded from the Internet. This problem has been alleviated with a utility program provided both in the client device and the server to compress the data content transferred therebetween. Cable modem and DSL, such as Asymmetric DSL, can provide a high speed, always-on access to the Internet from user's home or business telephone line. Similar broadband always-on Internet access is also available through local area networks. The broadband access has made the data com- pression less important for the wire-line users.

A mobile user uses a mobile communications network as an access network. The data rate in mobile communications networks is relatively low, comparable with the modem dial-up connection in wire-line access networks. In 2^nd generation systems, the basic user data rate is 9,6 kbs, which can be increased up to 56 kbs by means of high-speed multi-channel techniques. Charge of mobile data transmission depends on the transmission rate employed and/or data volume transferred. Thus, data compression in a wireless mobile internet access would offer both performance and monetary advantages. For example, with gzip compression, the reduction in the transferred data volume would be 20-65 % depending on the nature of data material.

One possible way to implement the data compression could be similar utility programs as used for wire-line modem connections. However, it is difficult to provide mobile stations with the utility program needed.

HTTP 1.1 (hypertext transfer protocol) allows compressing the data transmitted to a web browser, and majority of web browsers are able to handle compressed data. Also part of the web servers supports the compression feature but the activation of the feature is server-specific. Generally this feature is not in use in a server, and therefore an insignificant portion of the data traffic in the Internet is compressed today. Compression in servers is not preferred due to the capacity and performance reasons: the compression would slower the operation of the server. Consequently, the present situation is not optimal in the point of view of utilization of the features of servers and browsers, and no extensive solution is not in view due to the variety of server and browser techniques. One approach could be a proxy server that compresses all passing traffic in direction to a browser. In addition to the basic compression process, other data-type specific transformations may be applied to the data traffic, such as reducing the number of colours in image files, or even dropping out certain type of data. Such approach is disclosed in DE10128147 wherein all data to a browser is compressed if the browser supports compression. The advantage of a proxy server approach is that it makes the compression independent from any specific web server. However, this approach does not solve the problem in a rational way: as all data to all browsers is compressed, also data going to a browser behind a high-speed broadband connection is compressed, which is unnecessary in point of view of performance. This is troublesome both techni- cally and economically: the compressing proxy server is not able to offer optimal throughput of data without expensive hardware and software solutions (e.g. load sharing).

DISCLOSURE OF THE INVENTION

An object of the invention to provide an alternative way to provide data compression for a low-rate connection.

This achieved by a server device, a method and a program product which are characterized by what is stated in the independent claims. The preferred embodiments of the invention are disclosed in the dependent claims.

The invention is based on the idea of implementing the selective compression in a server device which also controls access of the client devices to the application servers, such that upon observing a given connection as a low-rate connection based on identification of the user or the user type, the server activates data compression for the observed low-rate connection. For example, the server device may be arranged to activate data compression for users of a mobile communications system, and to not activate data compression for users of a broadband wire-line communications system.

The invention enables to selectively apply compression to a specific browser of a specific user, so that only traffic transferred over low-rate connections is compressed. The invention also allows a user change his/her com- pression settings. The invention further allows customized compression policy for a group of users, such personnel of a company, and/or for certain type of users, such as mobile users. The compression policy may be defined to optimize the amount of data transferred, and thereby the traffic cost, as an additional advantage to the higher effective data rate.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following the invention will be described in greater detail by means of example embodiments with reference to the attached drawings, in which

Figure 1 is a block diagram showing an example of an arrangement according to the present invention; and Figures 2 and 3 depict scenarios where the access control server is used to perform access control on a web server.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS OF THE INVENTION

Terms And Abbreviations

IETF Internet Engineering Task Force.

IEEE Institute of Electrical and Electronics Engineers. RFC Request For Comments. IETF document defining a standard or proposed standard.

IPv4 Internet Protocol, version 4, defined in http://www.ietf.org/rfc/rfc791.txt

IPv6 Internet Protocol, version 6, defined in http://www.ietf.org/rfc/rfc2460.txt

VLAN Virtual LAN. A method of multiplexing several independent virtual

LANs on one physical LAN, defined in http://standards.ieee.org/getieee802/download/802.1Q-2003.pdf

DHCP Dynamic Host Configuration Protocol, defined in , http://www.ietf.org/rfc/rfc2131.txt and http://www.ietf.org/rfc/rfc2132.txt.

HTTP Hyper-Text Transfer Protocol, defined in http://www.ietf.org/rfc/rfc2616.txt

HTTPS Secure HTTP, or HTTP over SSL, defined in http://www.ietf.org/rfc/rfc2660.txt

URL Uniform Resource Locator. Defines a protocol, address, parameters triple. See http://www.ietf.org/rfc/rfc2616.txt

Cookie A mechanism for storing server or transaction state in a HTTP client application, defined in http://www.ietf.org/rfc/rfc2109.txt. NTP Network Time Protocol.

DNS Domain Name System.

SNMP Simple Network Management Protocol. XML Extended Markup Language.

PEM Portable Email Format. A text-only format commonly used to store

X.509 certificate and key data.

DER Distinguished Encoding Rules, an encoding format of ASN.1 data. ASN.1 Abstract Syntax Notation One. An abstract language for describing messages exchanged between distributed computing systems.

Figure 1 shows an example of a communication arrangement which contains an access control server device 10 implementing the present invention. In the example arrangement the authentication is distributed to a separate login server 11 but all login functions may also be built in the access server 10. The access control server 10 may be an HTTP proxy that can be used to implement access control into one or several web applications 17 and 18, and/or to non-web applications 8 and 9. The access control server 10 may be implemented by a computer program designed to be run on most PC-compatible hardware, supporting tagged VLAN, IPv4, IPSEC, and a selected set of network adapters. Example of a hardware is a PC-compatible computer equipped with an IDE hard disk, 16 MB or more of memory, and a 386 or compatible CPU. A common control unit 103 in Figure 1 represents various intelligent features of the server 10 described below. Main features of the access control server 10 may include remote control via a simple network protocol, transparent HTTP proxying with URL rewrite, SSL acceleration, pluggable authentication modules, and embedded IP firewall and routing functionality. Multiple access control servers can be connected together to form a transparently load-balancing, fault-tolerant clus- ter.

The access control server 10 may perform access control on HTTP/HTTPS protocols by using embedded authentication tokens in the requests, or on arbitrary TCP/IP connections based on IP addresses by using its IP firewall functionality. The access control server 10 may be controlled via a simple remote control protocol. The protocol is used to register authorized users, and configure the behaviour of the authentication engine on a per-session basis.

The access control server 10 may include a HTTP/HTTPS authenti- cator that may support the HTTP/1.1 protocol, HTTP session management extensions, SSLv2, SSLv3, and TLS/1.0. The HTTP/HTTPS authenticator may offer rich services for virtual server configuration and redirection. The authenti- cator may map requests for different URLs in one virtual server to configurable locations in multiple target servers. A virtual host defines a public name the control access server 10 is seen as from the public network. This typically re- quires a valid address-name mapping to exist in the public DNS. When requests for this public name are received, the access control server 10 authenticates and serves them according to the virtual host configuration 104. A virtual host may define a login URI, where unauthenticated clients are redirected to obtain valid authentication. A virtual host configuration may define map rules to transform request URLs. For example, authenticated requests to http:://server1 :80/directory1 can be mapped to go to https:://server2:443/otherplace. The access control server performs the reverse mapping on the response data, making the mapping fully transparent to the client. The number of virtual hosts and request mappings is limited only by available memory. The HTTP/HTTPS authenticator may add cookies or URL parameters to authenticated requests. It may also perform HTTP basic authentication to the protected servers on behalf of the user. There may be rich services for logging elements of authenticated requests, as well as all authenticated and rejected requests. The HTTP/HTTPS authenticator may also be used to offer a HTTPS service to the public network, and use the lighter HTTP protocol to access the protected servers in the internal network, thus reducing load from the protected servers.

Regarding the HTTP/HTTPS Access Control, HTTP (and by extension, HTTPS) are connectionless protocols and typically transferred through a proxy server. These properties imply two things: one "access", e.g. access of a web site, consists of a series of TCP connections; and the connections do not originate from the user's real IP address. In order to perform access control on such a protocol, the access control preferably authenticate every individual TCP connection, and it cannot rely on the originating IP address. Since the TCP connections cannot be authenticated based on IP addresses, the request content is examined for authentication tokens. The user is first expected to go to a login server 11 , e.g. via a virtual host public rule, to obtain the authentication token. The login server 11 authenticates the user by any means, e.g. using CallSign. If the built-in authentication method is used, the login server 11 may give the authenticated user a cookie with an encrypted secret, and register the cookie with the matching decryption key and user-specific session target server to the access control server 10. When the user sends requests to a virtual host in the control access server, the request is examined for an authentication cookie. The cookie may be given as a normal RFC2109 cookie, or as an URL name=value parameter. The access control server 10 decrypts the cookie with the key registered by the login application for this user, and checks if the revealed secret matches. If it matches, the request is allowed through to the registered target server; if it does not, the user is redirected to the virtual host login URI. Other authentication mechanisms can be used with different authentication plugins (such as X.509 client certificate based authentication with the clientcert plugin).

For protocols other than HTTP/HTTPS, plain IP address based access control may be employed. IP based access control is suitable for connection-oriented protocols such as RDP (used with Microsoft Windows Terminal Services), SSH and I MAP/I MAPS. Due to the nature of modern Internet, many networks utilize Network Address Translation (NAT). NAT makes all connections from the network to appear to come from a single source address (or a small set of shared source addresses). IP based access control is reliable only when it is known that the clients do not connect to the service from a NATed network, or when the entire NATed client network can be trusted. IP based access control requires that the access control server functions as a router between client networks and the protected server. Connection redirection may be configured, in order to allow connections made to the address of the access control server 10 be redirected to internal network servers transparently. The user is first expected to go to a login server, e.g. via a virtual host public rule. The login server may authenticate the user by any means, e.g. using CallSign security server from Fujitsu Ltd. The login server 11 may then use the control access server remote control interface to register the user's IP address to the access control server, together with the allowed target server address and session parameters. When the user connects to the target server, the access control server 10 allows the connection based on the session parameters. The session parameters may define that only a single TCP connection is allowed, or multiple TCP connections are allowed over a span of time. The session is preferably defined a maximum duration, and length of time until an idle session is automatically removed. In an embodiment of the present invention, a virtual host configuration 104 also defines whether compression is used for the authenticated con- nection, and optionally the compression parameters to be used. There may be different virtual host configurations 104 for user/users with a low-rate connection, such as mobile users 15 in a mobile communications network, and user/users 16 with high-rate or broadband connection. A user may have dif- ferent user identities for low-rate connection (such as mobile access) and other connections. In that case the authentication itself may define the virtual host to be used and thereby the need for compression. In an embodiment of the invention the compression parameters are given from the login server 11 when the login server register 11 the user to the control access server 10. In an em- bodiment of the invention the access control server 10 obtains compression parameters from a user profile database 13.

In an embodiment of the invention, the access control server is provided with a traffic analyser 105 analysing a data traffic from a browser of a client device 15/16 so as to determine whether the client device is accessing through a low-rate connection. The analyser 105 may be in use for all connections, or for certain virtual hosts, or when defined in the parameters given by the login server or user information from a database. When analyser 105 observers a low-rate connection, it triggers a compression.

The access control server 102 comprises a data compressor and decompressor 102. The traffic to be sent a client device 15 over a low-rate connection is compressed with an appropriate compression method. The traffic received from the client device 15 is decompressed. The data compressor and decompressor 105 can be implemented by any means compatible with the compression used in client devices 15 and/or browsers. In an embodiment of the invention the compression includes preventing transmission of a predetermined type of data, such as images, over a low-rate connection based on the identification of user or user type, such as a mobile user 15.

Figures 2 and 3 depict scenarios where the access control server 10 is used to perform access control on a HTTP/HTTPS application server 17 or 18. The client 15/16 first connects to the login web server 11 and authenticates him/herself (step 20). In Figure 2, the login web server 17 is located in the public network, and is accessed directly by clients 15/16. In Figure 3, the login web server 18 is located in the intranet, and is accessed by the clients 15/16 via virtual host and public URL of the access control server 10. The client's connection to the login web server 10 may be HTTPS for security reasons. If the login web server 11 is accessed via virtual host public URL of the access control server 10, the access control server 10 may provide SSL acceleration for the login web server 11 itself.

The login web server 11 generates an encrypted authentication to- ken, gives the token to the client 15/16 (step 21), and uses the remote control interface (addresses 10.0.1.1 and 10.0.2.2) via the control network to register the token to the access control server 10 (step 22). At the same time, information relating to the compression may be provided to the access control server 10. SSL acceleration is used for the protected application servers if the access control virtual host is defined to serve HTTPS, and the session registration performed by the login web server 11 defines the target server protocol as "http:". When the client 15/16 opens a connection to a virtual host of the access control server 10 and sends a request (step 23), the access control server 10 allows or denies the connection based on the authentication tokens included in the request. If the authentication is valid, the connection is forwarded to the protected application server 17; if the authentication is not valid, the client 15/16 is redirected back to the login server 11.

The access control server 10 applies data compression and decompression to a data traffic sent to and received from the client, if access control server 10 observers that the client device 15/16 is behind a low-rate connection, e.g. based on one or more of the ways described in the above example embodiments, or in another way. If the client device 15/16 is not behind a low-rate connection, or compression is not defined for the client, no compression is applied to the connection. It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.

Claims

1. A server device, comprising means for selective compressing data received from application servers and forwarded to client devices, characterized in that the server device comprises means for controlling access of the client devices to the application servers, and means for observing a given connection as a low-rate connection based on identification of the user or the user type, and means for activating data compression for the observed low-rate connection.

2. A device according to claim 1, characterized in that the server device is arranged to activate data compression for users of a mobile communications system, and to not activate data compression for users of a broadband wire-line communications system.

3. A device according to claim 1 or 2, characterized in that the server device has an access to a user profile database containing informa- tion for deciding whether a data compression is activated for a given connection or not, and optionally information on the compression method and/or compression parameters to be used for the given connection.

4. A device according to claim 3, characterized in that the server device is able retrieve from the user profile database containing infor- mation for deciding whether a data compression is activated for a given connection or not.

5. A device according to claim 1, characterized in that the server device comprises means for analysing a data traffic from a browser of a client device so as to determine whether the client device is accessing through a low-rate connection.

6. A device according to any one of claims 1-5, characterized in that the server device is arranged to prevent transmission of a predetermined type of data over a low-rate connection based on the identification of user or user type.

7. A data compression method, comprising selective compressing of data received from application servers and forwarded to client devices, characterized by controlling access of the client devices to the application servers, and means for observing a given connection as a low-rate connection based on identification of the user or the user type, and activating data compression for the observed low-rate connection.

8. A method according to claim 7, characterized by activating data compression for users of a mobile communications system, and forwarding non-compressed data to users of a broadband wire-line communications system.

9. A method according to claim 7 or 8, characterized by accessing a user profile database containing information for deciding whether a data compression is activated for a given connection or not, and optionally information on the compression method and/or compression parameters to be used for the given connection.

10. A method according to claim 9, characterized by retrieving from the user profile database containing information for deciding whether a data compression is activated for a given connection or not.

11. A method according to claim 7, characterized by analysing a data traffic from a browser of a client device so as to determine whether the client device is accessing through a low-rate connection.

12. A method according to any one of claims 7-11, character- i zed by preventing transmission of a predetermined type of data over a low- rate connection based on the identification of user or user type.

13. A program product comprising program code means which, when run on a computing device, implements the steps of any one of claims 7- 12.