A Simple NIO-based HTTP/HTTPS Server Example

INTRODUCTION

This directory contains a simple HTTP/HTTPS server. HTTP/HTTPS are two common network protocols that provide for data transfer, and are more fully described in RFC 2616 and RFC 2818 (Available at http://www.ietf.org ). HTTPS is essentially HTTP after the connection has been secured with SSL/TLS. TLS is the successor to SSL, and is described in RFC 2246.

This server was written to demonstrate some of the functionality new to the Java 2 platform. The demo is not meant to be a full tutorial, and assumes the reader has some familiarity with the subject matter.

In particular, it shows:

New I/O (java.nio, java.nio.channels, java.util.regex, java.nio.charset)

    Introduced in version 1.4 of the platform, NIO was designed to
    overcome some of the scalability limitations found in the
    existing blocking java.net.* API's, and to address other
    concepts such as Regular Expression parsing and Character
    Sets.

    This server demonstrates:

        ByteBuffer
        Blocking and Non-Blocking I/O
        SocketChannel
        ServerSocketChannel
        Selector
        CharacterSet
        Pattern matching using Regular Expressions

JSSE (javax.net.ssl)

Introduced in version 1.4 of the platform, JSSE provides
network security using SSL/TLS for java.net.Socket-based
traffic.  In version 1.5, the SSLEngine API was introduced
which separates the SSL/TLS functionality from the underlying
I/O model.  By making this separation, applications can adapt
I/O and compute strategies to best fit their circumstances.

    This server demonstrates:

        Using SSLEngine to create a HTTPS server
    Creating simple key material for use with HTTPS

Concurrency Library (java.util.concurrent)

    Introduced in version 1.5 of the platform, the concurrency
    library provides a mechanism which decouples task submission
    from the mechanics of how each task will be run.

    This server demonstrates:

        A ThreadPool with a fixed number of threads, which is
        based on the number of available processors.

SETUP

The server must be built on version 1.5 (or later) of the platform. Invoking the following should be sufficient:

% mkdir build
% javac -source 1.5 -target 1.5 -d build *.java

The following creates the document root:

% mkdir root

All documents should be placed in this directory.

For HTTPS, the server authenticates itself to clients by using simple Public Key Infrastructure (PKI) credentials in the form of X509Certificates. You must create the server's credentials before attempting to run the server in "-secure" mode. The server is currently hardcoded to look for its credentials in a file called "testkeys".

In this example, we'll create credentials for a fictional widget web site owned by the ubiquitous "Xyzzy, Inc.". When you run this in your own environment, replace "widgets.xyzzy.com" with the hostname of your server.

The easiest way to create the SSL/TLS credentials is to use the java keytool, by doing the following:

    (<CR> represents your end-of-line key)

% keytool -genkey -keyalg rsa -keystore testkeys -alias widgets
Enter keystore password:  passphrase
What is your first and last name?
[Unknown]:  widgets.xyzzy.com<CR>
What is the name of your organizational unit?
[Unknown]:  Consumer Widgets Group<CR>
What is the name of your organization?
[Unknown]:  Xyzzy, Inc.<CR>
What is the name of your City or Locality?
[Unknown]:  Arcata<CR>
What is the name of your State or Province?
[Unknown]:  CA<CR>
What is the two-letter country code for this unit?
[Unknown]:  US<CR>
Is CN=widgets.xyzzy.com, OU=Consumer Widgets Group, O="Xyzzy, Inc.",
L=Arcata, ST=CA, C=US correct?
[no]:  yes<CR>

Enter key password for <mykey>
(RETURN if same as keystore password):  <CR>

This directory also contain a very simple URL reader (URLDumper), which connects to a specified URL and places all output into a specified file.

SERVER EXECUTION

% java -classpath build Server N1

Usage:  Server <type> [options]
    type:
            B1      Blocking/Single-threaded Server
            BN      Blocking/Multi-threaded Server
            BP      Blocking/Pooled-thread Server
            N1      Nonblocking/Single-threaded Server
            N2      Nonblocking/Dual-threaded Server

    options:
            -port port                port number
                default:  8000
            -backlog backlog          backlog
                default:  1024
            -secure                   encrypt with SSL/TLS
	    default is insecure

"http://" URLs should be used with insecure mode, and "https://" for secure mode.

The "B*" servers use classic blocking I/O: in other words, calls to read()/write() will not return until the I/O operation has completed. The "N*" servers use non-blocking mode and Selectors to determine which Channels are ready to perform I/O.

B1: A single-threaded server which completely services each connection before moving to the next.

B2: A multi-threaded server which creates a new thread for each connection. This is not efficient for large numbers of connections.

BP: A multi-threaded server which creates a pool of threads for use by the server. The Thread pool decides how to schedule those threads.

N1: A single-threaded server. All accept() and read()/write() operations are performed by a single thread, but only after being selected for those operations by a Selector.

N2: A dual-threaded server which performs accept()s in one thread, and services requests in a second. Both threads use select().

CLIENT EXECUTION

You can test the server using any standard browser such as Internet Explorer or Mozilla, but since the browser will not trust the credentials you just created, you may need to accept the credentials via the browser's pop-up dialog box.

Alternatively, to use the certificates using the simple included JSSE client URLDumper, export the server certificate into a new truststore, and then run the application using the new truststore.

% keytool -export -keystore testkeys -alias widgets -file widgets.cer
Enter keystore password:  passphrase<CR>
Certificate stored in file <widgets.cer>

% keytool -import -keystore trustCerts -alias widgetServer \
        -file widgets.cer
Enter keystore password:  passphrase<CR>
Owner: CN=widgets.xyzzy.com, OU=Consumer, O="xyzzy, inc.", L=Arcata,
ST=CA, C=US
Issuer: CN=widgets.xyzzy.com, OU=Consumer, O="xyzzy, inc.",
L=Arcata, ST=CA, C=US
Serial number: 4086cc7a
Valid from: Wed Apr 21 12:33:14 PDT 2004 until: Tue Jul 20 12:33:14
PDT 2004
Certificate fingerprints:
    MD5:  39:71:42:CD:BF:0D:A9:8C:FB:8B:4A:CD:F8:6D:19:1F
    SHA1: 69:5D:38:E9:F4:6C:E5:A7:4C:EA:45:8E:FB:3E:F3:9A:84:01:6F:22
Trust this certificate? [no]:  yes<CR>
Certificate was added to keystore

% java -classpath build -Djavax.net.ssl.trustStore=trustCerts \
    -Djavax.net.ssl.TrustStorePassword=passphrase \
    URLDumper https://widgets.xyzzy.com:8000/ outputFile

NOTE: The server must be run with "-secure" in order to receive "https://" URLs.

WARNING: This is just a simple example for code exposition, you should spend more time understanding PKI security concerns.

SOURCE CODE OVERVIEW

The main class is Server, which handles program startup, and is subclassed by the "B*" and "N*" server classes.

Following a successful accept(), the "B*" variants each create a RequestServicer object to perform the actual request/reply operations. The primary differences between the different "B*" servers is how the RequestServicer is actually run:

B1:	RequestServicer.run() is directly called.
BN:	A new thread is started, and the thread calls RequestServicer.run().
BP:	A ThreadPool is created, and the pool framework is given Runnable
tasks to complete.

In the "N*" variations, a Dispatcher object is created, which is responsible for performing the select, and then issuing the corresponding handler:

N1:	A single thread is used for all accept()/read()/write() operations
N2:	Similar to N1, but a separate thread is used for the accept()
operations.

In all cases, once the connection has been accepted, a ChannelIO object is created to handle all I/O. In the insecure case, the corresponding SocketChannel methods are directly called. However in the secure case, more manipulations are needed to first secure the channel, then encrypt/decrypt the data, and finally properly send any shutdown messages. ChannelIOSecure extends ChannelIO, and provides the secure variants of the corresponding ChannelIO calls.

RequestServicer and RequestHandler are the main drivers for the blocking and non-blocking variants, respectively. They are responsible for:

Performing any initial handshaking

Reading the request data
    All data is stored in a local buffer in the ChannelIO
    structure.

Parsing the request
    The request data is obtained from the ChannelIO object, and
    is processed by Request class, which represents the
    parsed URI address.

Locating/preparing/sending the data or reporting error conditions.
    A Reply object is created which represents the entire object to send,
    including the HTTP/HTTPS headers.

Shutdown/closing the channel.

CLOSING THOUGHTS

This example represents a simple server: it is not production quality. It was primarily meant to demonstrate the new APIs in versions 1.4 and 1.5 of the platform.

This example could certainly be expanded to address other areas of concern: for example, assigning multiple threads to handle the selected Channels, or delegating SSLEngine tasks to multiple threads. There are so many ways to implement compute and I/O strategies, we encourage you to experiment and find what works best for your situation.

To steal a phrase from many textbooks:

"It is left as an exercise for the reader..."