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..."