Port, Socket, Reverse Proxy, JVM, Pod, SIGTERM: Backend Words Before the Deep Dives

October 1, 2026 · How It Actually Works: Real Systems as State Machines (part 1)

▶ Watch on YouTube & subscribe to The Stack Underflow

Your browser asks a small bookstore site for GET /books/42. The request travels to NGINX, which passes it to a Java app running in a container, inside a Kubernetes pod. Every step has a name, and in the deep-dive videos those names come fast. This primer gives you each word once, on one map, with what it is, why it exists, and the word it is most often confused with.

The one-line version: a request finds a device (IP), a service (port), and a waiting socket (bind + listen); a Java process answers it; Kubernetes checks it with probes and stops it with SIGTERM, then SIGKILL.

Last verified against the IETF RFCs, the Linux man pages, the Java specifications, kubernetes.io and nginx.org: 1 October 2026. The video’s definitions were checked on 29 September 2026; the version-sensitive ones (Kubernetes grace period, probe behaviour, NGINX’s default balancing method, Linux backlog semantics) were re-checked today.

One picture, one peg per word

The video hangs every word on one picture: a big office building with a mailroom and phone lines. The pegs are analogies, memory aids, not definitions. The right-hand column is the actual definition, and where a peg breaks down the video says so (we repeat the important limits below).

Reaching the server

An IP address picks the device and a port picks the service on it. You need both, because one machine runs many programs. TCP then sets up a connection before any data moves and gives both sides a reliable, in-order stream of bytes.

The word socket is used two ways, and the video keeps them apart. In the TCP standard (RFC 9293) a socket is an address that includes a port; a connection is identified by a pair of sockets, one at each end. In code, a socket is the file descriptor your program uses for one end, the thing you call bind() on.

TLS protects the connection; SNI tells the server which site the client wants, inside the TLS client hello. The common confusion is SNI vs the HTTP Host header: SNI travels in the handshake, and Host is an HTTP header sent after it.

Where the pegs break: one device can have several IP addresses, and TLS detects and rejects tampering; it can’t make interference physically impossible, which is why the peg says “sealed”, not “tamper-proof”.

Inside an HTTP exchange

A request starts with a method and a target, then headers (name/value pairs), then an optional body. GET asks for a representation of the resource, so it normally has no body; RFC 9110 says a body in a GET has no generally defined meaning. The path (/books/42) is not the URL: the URL also holds the scheme and host.

The response carries the status code, headers and usually a body. The code is a short summary; the body is the content. Error responses can carry a body too, usually explaining the error.

The 4xx/5xx split matters in the NGINX video: a 4xx says the client seems to have erred; a 5xx says the server has erred or cannot perform the request. 502 Bad Gateway and 504 Gateway Timeout come back there.

Keep-alive is the behaviour of reusing one connection, the default in HTTP/1.1, where Connection: close ends it after the response. Don’t confuse it with the Keep-Alive header, an older timeout hint that HTTP/2 and HTTP/3 prohibit.

The proxy and the app’s front door

A reverse proxy is set up by the site, in front of its servers. RFC 9110 calls it a gateway. A forward proxy is the opposite: chosen by the client. A load balancer chooses among several copies of an app. A reverse proxy can forward to just one server; NGINX in the video does both jobs.

For NGINX to connect, the Java app must already be waiting, which takes two system calls:

socket()  → a handle
bind()    → claim port 8080           (name on the door)
listen()  → accept connections        (phone switched on)
            backlog = queue of established, not-yet-accepted connections
accept()  → hand one connection to the app (not covered in the primer)

The usual confusion: backlog vs worker threads. The backlog is a queue in the operating system, before the app accepts. Threads do the work after a connection is accepted. The backlog meaning above is Linux’s (since Linux 2.2, per listen(2)); other systems may differ, and what happens when the queue fills is out of scope for this primer.

Inside the Java app

A process has its own private memory; a thread is a path of execution inside it, sharing memory and open files with the other threads. Two processes are walled off; two threads in one process see the same memory.

The JVM knows nothing of the Java language, only the class file format, which is why other languages can run on it. The java command starts a JVM, loads a class, and calls its main method. A class is the definition; an object is one instance of it, created at run time.

A JAR is a ZIP-based file whose manifest can name the main class. The classpath is the search list. With java -jar, the JAR is the source of all user classes and other classpath settings are ignored. A class loader is the code that does the finding: the JVM supplies the bootstrap loader, and programs can add loaders that fetch classes from other places. Classpath = list of places; class loader = the code that finds and creates the class.

Running it on Kubernetes

An image packages the app with everything it needs; a container is an isolated process started from it. Images are immutable: to change the app, build a new image and recreate the container. Unlike real flat-pack, one image can build many containers.

A pod is the smallest unit Kubernetes deploys and manages: one or more containers sharing storage and network, always scheduled together. Containers in a pod share one IP address and port space, which is why the peg says “shared suite”: one street address, so each office needs its own room number. One container per pod is the most common case.

The kubelet, the agent on each node, runs the probes:

When a pod is deleted, the container runtime sends TERM to process 1 in each container (many runtimes send the image’s STOPSIGNAL instead, if one is defined). The default terminationGracePeriodSeconds is 30 seconds; once it expires, KILL goes to any remaining processes. SIGTERM can be caught, so a Java app can run its shutdown steps; SIGKILL cannot be caught, blocked or ignored, so no cleanup runs.

Exit codes: 0 means success. By shell convention, a process ended by signal N is reported as 128 + N, so SIGTERM (15) shows as 143 and SIGKILL (9) as 137. The signal is what was sent; the exit code is what is reported afterwards.

Pause & Prove

1. Your pod’s readiness probe keeps failing, but its liveness probe passes. Does Kubernetes restart the container, and what happens to its traffic?

• A. It restarts the container. Tempting, because “probe failing” sounds like “broken”. Restarts come only from too many liveness failures.
• B. No restart; the pod stops receiving Service traffic. ✓ A failing readiness probe removes the pod’s IP from the EndpointSlices of matching Services. The container keeps running and can come back once readiness passes.
• C. Kubernetes deletes the pod. Neither probe deletes pods.
• D. Nothing changes until liveness also fails. Readiness acts on its own: traffic stops as soon as it fails.

2. Kubernetes stops your pod. Which signal can your Java app catch to run its shutdown steps? (Community poll)

• SIGTERM ✓ Kubernetes sends it first, and it can be caught, so the JVM’s shutdown sequence runs.
• SIGKILL. Sent after the grace period (30 s by default) to anything still running. It cannot be caught, blocked or ignored.
• Both. Only SIGTERM can be caught.
• Neither. SIGTERM is exactly the signal meant to let a process clean up.

3. Peg drill

Say the peg before reading it: port → the room number · backlog → callers on hold · SIGTERM → closing time · class loader → the librarian · pod → the shared suite.

Before / after this video

• This is the first video in the series. No prerequisites.
• Next, the deep dives that use these words: What Spring Boot Actually Does After java -jar (read Spring Boot words first if beans and auto-configuration are new), How Apache Tomcat Handles a Request, and How NGINX Handles a Request: 502 vs 504.

Sources

• RFC 9110, HTTP Semantics: client/server roles, default port 443, Host header, fields, GET, status code classes, 502/504, gateway (reverse proxy) vs proxy
• RFC 9112, HTTP/1.1: request line, persistent connections, Connection: close
• RFC 9293, TCP: ports, reliable in-order byte stream, socket and connection definitions
• RFC 8446, TLS 1.3 and RFC 6066, SNI: TLS goals; server_name in the client hello
• MDN, Keep-Alive header: the header is a hint and is prohibited in HTTP/2 and HTTP/3
• nginx.org, Using nginx as HTTP load balancer: round-robin is the default method (re-checked 1 Oct 2026)
• bind(2), listen(2), signal(7): bind, listen, Linux backlog semantics, SIGKILL cannot be caught, signal numbers (re-checked 1 Oct 2026)
• Oracle, Processes and Threads: process memory, threads share it
• JVM Specification, SE 21 and chapter 5: abstract machine, class files, loading, bootstrap loader
• The java command and JAR file specification: classpath, -jar ignores other classpath settings, Main-Class
• Kubernetes, Containers and Pods: images, containers, pods, shared network
• Kubernetes, Liveness, Readiness and Startup Probes: restart vs removal from EndpointSlices (re-checked 1 Oct 2026)
• Kubernetes, Pod Lifecycle: termination: TERM to process 1, STOPSIGNAL, 30 s default grace period, KILL afterwards (re-checked 1 Oct 2026)
• GNU Bash manual, Exit Status: 0 = success, 128 + N for a fatal signal

Change notes

• 1 Oct 2026: first published.

Not affiliated with or endorsed by F5 (NGINX), Oracle, the Cloud Native Computing Foundation or any other company or project named here. Found a mistake? Tell us in the video’s comments and we’ll correct this page.