Connection Conditioning: Architecture-Independent 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 • Moore’s 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. That’s 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 that’s 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: < 50 lines (of 6000+) • Flash: < 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 fork+send • 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. 94 us 34 us 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