Client

At the socket level the client is the active opener. With the Berkeley/POSIX sockets API a TCP client calls socket() and connect(); the kernel picks an ephemeral source port and sends a SYN to the server's address and port, whereas the server has called bind(), listen() and accept() and is waiting passively. The connection is identified by the 5-tuple (protocol, source IP, source port, destination IP, destination port), and it is the client's ephemeral port that lets one host keep many simultaneous connections to the same server port. UDP has no connection, but the convention is the same: the client sends the first datagram, and the server replies to whatever source address and port it observed.

The role is defined per protocol exchange, not per machine. A reverse proxy is a server towards browsers and a client towards the origin; a recursive DNS resolver is a server to the stub resolvers on laptops and a client to authoritative name servers; a mail server relaying outbound mail acts as an SMTP client. In peer-to-peer protocols every node plays both roles. HTTP (RFC 9110) calls the originating client program a user agent, and the User-Agent header it sends is self-declared and trivially spoofed, so it is useful for statistics but worthless as an authentication signal.

The initiator role has direct security consequences. Stateful firewalls and NAT normally permit outbound connections and their replies while dropping unsolicited inbound traffic, so malware deliberately behaves as a client: reverse shells and command-and-control implants beacon outwards over HTTPS or DNS to pass perimeters that would block an inbound connection. Server-side request forgery (SSRF, OWASP Top 10:2021 A10) is the mirror image, where an attacker makes a server act as an unwitting client of internal systems. Client software is also a large attack surface in its own right: browsers, mail clients, PDF readers and VPN clients parse untrusted data returned by servers, and a malicious or compromised server can exploit that parsing.

The basic design rule is that a server must never trust the client. Input validation, price calculation or authorization logic implemented only in JavaScript or in a mobile app can be bypassed with a modified client or an intercepting proxy, so it has to be enforced again on the server. In ordinary TLS only the server is authenticated; the client proves its identity at the application layer with passwords or tokens or, in mutual TLS, with its own X.509 certificate. Operationally, governing clients means keeping them patched, inventorying the client software in use (CIS Controls v8, Control 2) and, in Zero Trust designs, checking device posture before a client is allowed to reach a service.