the controlling terminal and a process group / session
When you type a shell pipeline like cat file | grep error | wc -l, you launch three processes at once - but you think of them as one job. Press Ctrl-C and all three stop together; that is not a coincidence. Unix groups related processes so that signals and terminal control can be applied to the whole bunch at once. Two layers of grouping make this work: the process group and the session, both tied to a controlling terminal.
Walk up the layers. A process group is a small set of related processes (typically the processes of one shell pipeline) that share a process-group ID. You can signal an entire group at once - that is exactly what Ctrl-C does: it sends an interrupt signal to every process in the foreground group, which is why all three commands in the pipeline die together. A session is a larger collection - usually all the process groups started from one login or one terminal window - identified by a session ID and led by a session leader (typically the shell). A session can have a controlling terminal: the keyboard-and-screen device that delivers keystrokes and signals to it. Within a session, exactly one process group is the foreground group (it gets your keystrokes and terminal-generated signals); the others run in the background. The shell's job control - typing fg, bg, Ctrl-Z - is precisely the shell rearranging which process group is in the foreground and sending stop/continue signals to background groups. A process can break away from its session entirely with setsid(), becoming a new session leader with no controlling terminal - which is exactly what a daemon does to detach from any terminal.
Why it matters: this grouping is why job control works, why closing a terminal can kill everything you started in it (a hang-up signal goes to the session), and why a long-running server must escape its session to survive your logout. The single most useful takeaway: Ctrl-C is not magic aimed at one program - it is a signal to a whole foreground process group, which is why it cleans up an entire pipeline, and why a background job ignores it. And detaching from the controlling terminal (via setsid) is the first thing a daemon does so it is no longer at the mercy of the terminal that started it.
In a shell, run sleep 100 | cat & then jobs -l and ps -o pid,pgid,sid,comm. The two piped commands share one PGID (the job); both share the session's SID with the shell. Pressing Ctrl-C on a foreground pipeline sends SIGINT to the whole foreground PGID, stopping all of them at once.
A pipeline shares one process-group ID; Ctrl-C signals the whole foreground group, not one process.
Ctrl-C does not target one program - it signals the entire foreground process group, which is why a whole pipeline dies together and a background job is unaffected. Signals as a mechanism are covered in depth in Field o.