Server

At the operating-system level a TCP server creates a socket, bind()s it to an address and port, calls listen() with a backlog, and then loops on accept(), which returns a new socket for each established connection while the listening socket keeps waiting. On Linux the kernel keeps separate queues for half-open connections (SYN received) and fully established connections waiting to be accepted; a SYN flood targets the former, and SYN cookies let the kernel answer without storing state. The bind address matters for security: a service bound to 127.0.0.1 is reachable only locally, whereas one bound to 0.0.0.0 or :: listens on every interface, which is how development databases and admin consoles end up exposed to the internet by accident.

Servers handle concurrency in a few classic ways: a process per connection (traditional inetd services, Apache's prefork model), a pool of threads, or an event loop over non-blocking sockets using I/O multiplexing such as epoll on Linux, kqueue on BSD and macOS, or I/O completion ports on Windows, as in nginx and Node.js. Dan Kegel's "C10k problem" (1999) described why the older models struggled with ten thousand simultaneous clients. Each model has its own exhaustion attacks: slowloris-style clients hold connections open with incomplete requests to tie up worker slots, which event-driven servers resist better than thread-per-connection designs.

In modern architectures a server is usually a role rather than a box: a virtual machine, a container or a serverless function behind a load balancer. Stateless application servers keep session data in a shared database or cache so that any instance can answer any request and instances can be added or replaced freely; health checks remove failed instances, and redundancy is organised as active-active or active-passive across sites, as in the two-data-centre example. A server is the process or host that answers; a service is the capability it offers, and one server can host many services while one service can span many servers.

Securing servers is largely configuration discipline. CIS Benchmarks and vendor baselines describe a minimal installation with unneeded services disabled, daemons running under dedicated low-privilege accounts rather than root or SYSTEM, current patches, restricted administrative access, and logging forwarded to central collection. The server must treat everything received from clients as untrusted and enforce authentication, authorization and input validation itself. Version banners and verbose error pages help attackers fingerprint software, and because servers are reachable around the clock and hold shared data, they are usually classed as critical assets in risk assessments and asset inventories.