Java Networking Introduction

Networking is how a Java program talks to another program — across the room or across the world. The JDK ships a complete, batteries-included stack for it in two packages: the long-standing java.net (URLs, sockets, addresses) and the modern java.net.http (the HttpClient introduced in Java 11). This part of the book tours that stack from the high-level conveniences down to raw sockets.

The layers, from high to low

Java's networking APIs form a ladder. Pick the highest rung that does the job:

Rung	API	Use it for
Highest	`HttpClient` (`java.net.http`)	Modern HTTP/HTTPS: REST calls, downloads, async
	`URL` / `URLConnection` / `HttpURLConnection`	Legacy HTTP and other URL protocols
	`Socket` / `ServerSocket`	Custom TCP protocols, your own client/server
Lowest	`DatagramSocket`	Connectionless UDP messaging
Support	`InetAddress`	Resolving and representing IP addresses

The rule of thumb: if you are calling an HTTP API, reach for HttpClient. Drop to sockets only when you are speaking a non-HTTP protocol or building a server of your own.

TCP vs. UDP

Two transport protocols underlie almost everything:

TCP (Socket, ServerSocket) is a connection: reliable, ordered, stream-based. Bytes you write arrive intact and in order, or you get an error. HTTP, databases, and most application protocols ride on TCP.
UDP (DatagramSocket) is connectionless: you fire independent packets ("datagrams") with no handshake, no ordering, and no delivery guarantee. It trades reliability for low latency — used for DNS, video streaming, and games.

Client vs. server

A client initiates a connection to a known address and port. A server binds to a port and waits to accept incoming connections. The same Socket class represents the live connection on both ends; the asymmetry is only in who starts the conversation. Later chapters build both sides.

Blocking by default

The classic java.net APIs are blocking: socket.getInputStream().read() parks the calling thread until data arrives, and serverSocket.accept() parks until a client connects. That is simple to reason about but means one thread per connection. (java.nio channels and virtual threads address scaling; this part stays on the blocking APIs, which are the right starting point.)

A worked example: the whole stack in one file

To make the pieces concrete, this program starts a tiny HTTP server on the loopback interface, then calls it with the modern HttpClient — a complete client/server round trip in a single JVM, no external network required.

java— editable, runs on the server

import com.sun.net.httpserver.HttpServer;
import java.net.InetSocketAddress;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.io.OutputStream;
import java.nio.charset.StandardCharsets;

public class NetworkingIntroDemo {
  public static void main(String[] args) throws Exception {
    // 1. A minimal server, bound to loopback on an OS-chosen (port 0) port
    HttpServer server = HttpServer.create(new InetSocketAddress("127.0.0.1", 0), 0);
    server.createContext("/hello", exchange -> {
      byte[] body = "Hello from the server".getBytes(StandardCharsets.UTF_8);
      exchange.sendResponseHeaders(200, body.length);
      try (OutputStream os = exchange.getResponseBody()) { os.write(body); }
    });
    server.start();
    int port = server.getAddress().getPort();
    System.out.println("server listening on 127.0.0.1:" + port);

// 2. The client: build a request and send it with HttpClient
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest request = HttpRequest.newBuilder()
        .uri(URI.create("http://127.0.0.1:" + port + "/hello"))
        .GET()
        .build();
    HttpResponse<String> response =
        client.send(request, HttpResponse.BodyHandlers.ofString());

System.out.println("status      : " + response.statusCode());
    System.out.println("body        : " + response.body());
    System.out.println("http version: " + response.version());

server.stop(0);
    System.out.println("server stopped");
  }
}

What to take from the run:

A working client and server fit in one short file. Real applications split them across machines, but the API is identical — HttpServer accepted a connection and HttpClient opened one, meeting over TCP on the loopback interface (127.0.0.1). This is the shape of every networked program: one side waits, one side calls.
Binding to port 0 let the OS pick a free port, which server.getAddress().getPort() reported back. Hard-coding a port risks "address already in use"; port 0 is the standard trick for tests and demos that just need a port.
The client never touched a socket directly. HttpClient handled the connection, the HTTP request line, headers, and response parsing — that is the value of climbing to the highest rung of the ladder. The socket chapters later show what it hid.
The response carried structured metadata: a statusCode() (200), a body(), and a version(). HTTP responses are more than text; the client modelled them as a typed HttpResponse object so you read fields rather than parse a stream.
server.stop(0) released the port. Network resources — sockets, server ports, connections — are scarce OS handles; every chapter in this part closes them explicitly (or with try-with-resources) so they are not leaked.

What the rest of this part covers

URL and its connection classes, the modern HttpClient in depth, raw TCP with Socket and ServerSocket, connectionless UDP with DatagramSocket, and address resolution with InetAddress. The next chapter starts at the most familiar networking object of all: the URL.

Practice

You are writing a Java service that calls a third-party REST API over HTTPS and needs both synchronous and asynchronous requests on a modern JDK. Which API is the most appropriate first choice?

'java.net.http.HttpClient', the modern high-level HTTP API that supports synchronous 'send', asynchronous 'sendAsync', HTTP/2, and HTTPS out of the box
A raw 'Socket' connection on port 443, writing the HTTP request line and headers by hand
'DatagramSocket', because UDP is faster and REST APIs are stateless
'ServerSocket', since calling an API means accepting the API server's connection