How the Barracuda Server HTTP engine uses sockets

The Barracuda Server HTTP engine is designed to keep memory usage fixed in both the HTTP engine and the TCP/IP stack. By default, the maximum number of sockets used by the HTTP engine is set to a low value, 16, which is sufficient to support one modern browser. At the time of this writing, some browsers use up to 13 concurrent connections. You can change the default value by calling HttpServerConfig::setNoOfHttpConnections.

The HTTP engine is designed to minimize the number of sockets that enter the TCP TIME_WAIT state, since sockets in this state can negatively affect TCP/IP stack performance and resource use. For background, see this article on TIME_WAIT and scalable servers.

The HTTP engine reduces TIME_WAIT usage by avoiding server-side connection closes unless it is forced to close a socket. An HTTP/1.1 socket can be in one of three states: not connected, connected and in use, or connected and idle. Idle HTTP/1.1 connections can be closed, but the server normally leaves that decision to the client. Most HTTP clients close idle connections after a short idle period. A socket ends up in the TIME_WAIT state on the server side if the HTTP engine is forced to close the connection, for example when the HTTP engine's socket pool is exhausted or when socket accept fails because the TCP/IP stack is out of resources.

You can increase the HTTP engine's socket pool size by calling HttpServerConfig::setNoOfHttpConnections; however, you must make sure the TCP/IP stack can handle the configured number of connections. A larger socket pool makes it less likely that the server must close sockets and place them in TIME_WAIT. It also lets the HTTP engine serve more concurrent HTTP clients.

Do not increase the HTTP engine's socket pool beyond what the TCP/IP stack and porting layer can support. In particular, when using the SoDisp Barracuda Server porting layer for BSD, make sure the socket pool size is lower than the maximum number of connections accepted by the BSD select function. The Windows TCP/IP stack's version of select supports a maximum of 64 connections by default, although this can be increased. Linux BSD select supports a maximum of 1024 connections. BAS supports multiple SoDisp porting layers for different operating systems. On Linux, BAS supports both BSD sockets and epoll. The SoDisp epoll socket dispatcher can support up to 212,000 concurrent connections.

When using a TCP/IP stack with limited resources, be careful with socket connections that are not controlled by the HTTP engine, such as sockets created by the high-level Lua socket API, HTTP client connections, WebSocket connections, and EventHandler connections. These connection types are not controlled by the HTTP engine's configurable connection limit. All socket connections used by a Barracuda Server share the same socket dispatcher, SoDisp, and are limited by the selected porting layer and TCP/IP stack.

Note: in many TCP/IP stacks, the time a socket stays in the TIME_WAIT state can be changed. We recommend reducing this time if you run into TCP/IP stack resource issues.