Connection Conditioning: ArchitectureIndependent Support for Simple, Robust Servers

1
Connection Conditioning Architecture-Independent
Support for Simple, Robust Servers

• KyoungSoo Park
• Vivek S. Pai
• Princeton University

2
Server Performance Is Great

• Most Web servers generally perform well
• Many contributors
• Moores law processors memory
• OS timing wheels, hashed PCB, zero copy
• Load balancers clusters, data centers
• Poor performance outside server software
• CGIs, database access, network access, etc

3
What About Research InServer Software
Architectures?

• 10 years of progress
• NCSA/Apache (just processes)
• Events (Harvest, Zeus)
• Events helpers (Flash)
• Events threads (JAWS, Haboob)
• Events threads compilers (Knot)
• Has it mattered?

4
Netcraft Web Server Survey
Apache
NCSA
Microsoft
5
Thats Not Quite Fair

• Robustness/scalability work
• Handling large s connections
• Tolerating long delays
• Detecting/mitigating attacks
• Generally in context of event-driven servers
• Users love multi-process servers
• Easier to add features, modules
• Apache very successful

6
Should We Care?

• Keep going this route
• Becomes a boutique research area
• Discover/invent the next Apache
• Some servers still benefit
• Go with the flow
• Bring research benefits to Apache
• Focus on what matters for most people
• New constraints ? new research

7
Why Push Comes to Shove

• Walmart Linux machine 400 total
• Microtel AMD 1.5 GHz
• 1GB memory
• Intel GigE
• HP DL320 List under 3000
• Intel 2.8 GHz dual-core
• 2 GB memory
• Built-in GigE
• 100 Mbps WAN 30,000/month

8
New Approach

• Can we make servers simpler robust-ier
• Easier to program, defend, share
• Possibly slower, but thats OK
• Programming-style (architecture) neutral
• Old idea Unix pipes
• Good for text processing
• Bad for servers?

9
Connection Conditioning
10
Salient Features

• Filters are separate processes
• Internally threads, processes, events, ???
• Communicate via Unix domain sockets
• Allows passing socket/request bundle
• Server sees TCP sockets
• Responses via client socket
• No outbound overheads
• Filters tied to protocol, not clients

11
Why Filters?

• Reuse across apps/protocols
• Beck attack Apache 98, Flash 02, thttpd ??
• Another layer of defense
• Works before application API (or even no API)
• Decoupled from application structure
• Can codify best practices
• Simplifies re-use
• But not a panacea

12
How Many Filters?

• In general, for most servers four
• Manage connections wait for request
• Probably event-driven
• Separate multiple requests, re-present
• Eases persistent connection use
• Reject malformed requests
• Prioritize

13
Connection Conditioning Library

• 9 functions, 2 nonstandard
• Most are cc_accept, cc_read, etc.
• Trivial to modify existing servers
• cc_close specifies local or global
• One new function, cc_createlsock
• Offloads the socket/bind/listen process
• Easier than doing it transparently
• Library is 89 lines

14
Modify or Start Fresh

• Modify existing servers
• Apache lt 50 lines (of 6000)
• Flash lt 30 lines (of 2500)
• New CC-aware server 80 lines
• Filters
• Framework 152 lines
• Connections 98 lines
• Persistence 76 lines
• Priority 59 lines

15
CCServer Operation Rationale

• Straightforward server
• One request at a time
• No caching
• Open file, send it if small, else forksend
• Rely on filters for heavy lifting
• Model for simple servers
• Small footprint environments
• Sensors
• Not going to replace Apache

16
Performance Tests

• Every paper needs performance tests
• Single-file tests
• Some idea of baseline performance
• File mix
• File set from SpecWeb99
• Chained filters
• Throughput latency of multiple filters

17
Single File Test Request Rates
18
Single File Test Request Rate
19
Single File Test Throughput
20
File Mix Throughput (Microtel)
21
File Mix Throughput (HP)
22
Chained Filters Latency
23
Chained Filters Throughput
24
Robustness Tests

• Incomplete connections
• Client opens socket, but no request
• Very low-rate DoS if server limits connections
• Quality of service
• High-priority client mixed with low-priority
• High-rate DoS, but filterable
• Persistent connection test
• Connection persists, but no follow-up request
• Low-rate DoS, easy to mask

25
Incomplete Connections
26
Incomplete Connections

• Much higher rate to DoS
• Brings event-driven benefits to Apache
• Implement policies across connections

27
Quality of Service
28
Idle Persistent Connections

• Persistent connections become cheap
• Easier to provide client benefits
• Lazy closing ? better performance

29
Summary Connection Conditioning

• Applying Unix pipes to servers allows
• Decompose processing into filters
• Compose filters as needed
• Design filters as you like
• Protect existing new servers
• At a modest performance cost

30
(No Transcript)