Web サーバーを一言でいうと
Web サーバーは、
「ブラウザ（クライアント）からの HTTP リクエストを受け取り、HTTP レスポンスを返す“受付兼配達係”」
です。
ブラウザが「このページください」「このデータください」とお願いすると、
Web サーバーがそれを受け取り、
必要ならアプリ（Java）に処理を依頼し、
結果を HTML や JSON としてブラウザに返します。
あなたが Java で Web アプリを書くとき、
そのアプリは Web サーバーの“中”で動いている と考えるとイメージしやすいです。
静的ファイルを返す Web サーバー
「ただのファイル配達屋」としての Web サーバー
一番シンプルな Web サーバーは、
「指定されたファイルをそのまま返すだけ」 の存在です。
例えば、/index.html にアクセスが来たら、
サーバーのディスク上の index.html を読み込んで、そのまま返します。
GET /index.html HTTP/1.1
Host: example.com
に対して、
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
<html>...</html>
という感じで返すだけ。
この段階では、
「中でプログラムが動いているわけではない」
「ただのファイルサーバー」
というイメージです。
動的な処理をする Web サーバー＋アプリケーション
「リクエスト内容に応じて、その場で中身を作る」
Web アプリになると、
「毎回同じ HTML を返す」のではなく、
リクエストの内容やユーザーごとに結果が変わる 必要があります。
例えば、ログインしているユーザー名を表示したり、
データベースからユーザー一覧を取ってきて表示したり。
ここで登場するのが、
Web サーバー＋アプリケーション（Java） という構成です。
流れとしてはこうです。
ブラウザが /users にアクセス
Web サーバーが「これはアプリに渡すべきリクエストだな」と判断
Java アプリ（Spring など）が処理を行う
結果の HTML や JSON を Web サーバーに返す
Web サーバーがそれを HTTP レスポンスとしてブラウザに返す
Web サーバーは、
「どのリクエストをどのアプリに渡すか」
「レスポンスを HTTP として正しく返す」
という“交通整理役”を担っています。
Java と Web サーバーの関係
Tomcat や Jetty は「Java 用の Web サーバー」
Java の世界では、
Tomcat、Jetty、Undertow などがよく使われます。
これらは、
「HTTP をしゃべれるサーバー」＋「Java のアプリを動かす仕組み」
をセットで持っている存在です。
Spring Boot を使うと、
Tomcat などがアプリに「組み込み」で入っていて、java -jar app.jar と起動するだけで、
Web サーバー＋アプリが一体となって動きます。
あなたが書くのは主に「アプリ側のコード」ですが、
そのコードは必ず Web サーバーの上で動いている という意識を持つと、
HTTP やリクエスト／レスポンスの流れが理解しやすくなります。
Web サーバーがやってくれていること
1. ポートを開いてリクエストを待ち受ける
Web サーバーは、
例えばポート 80 や 8080 などを開いて、
「ここに来る HTTP リクエストを全部受け取る」
という役割を持ちます。
あなたの Java コードが直接ソケットを開いて待ち受けているわけではありません。
Web サーバーがそれを代わりにやってくれているのです。
2. HTTP をパースしてくれる
ブラウザから来るのは、
生のテキストとしての HTTP リクエストです。
GET /users?id=1 HTTP/1.1
Host: example.com
User-Agent: ...
Web サーバーはこれを解析して、
「パスは /users」
「クエリパラメータは id=1」
「メソッドは GET」
などの情報に分解し、
Java の世界では HttpServletRequest や、
Spring なら @RequestParam, @PathVariable といった形で扱えるようにしてくれます。
3. アプリケーションに処理を渡す
Web サーバーは、
「この URL はこのアプリに渡す」といったルールに従って、
リクエストを Java アプリに渡します。
Java 側では、@GetMapping("/users") のような形で、
「この URL が来たらこのメソッドを呼んでほしい」と宣言しておきます。
Web サーバーはその宣言をもとに、
適切なメソッドを呼び出してくれます。
4. レスポンスを HTTP にして返す
Java アプリが
「この文字列を返したい」「この JSON を返したい」
といった結果を返すと、
Web サーバーはそれを HTTP レスポンスの形に整えて、
ブラウザに送り返します。
HTTP/1.1 200 OK
Content-Type: application/json
{"id":1,"name":"Alice"}
この「HTTP としての体裁を整える」部分も、
Web サーバーが全部やってくれています。
Web サーバーとアプリケーションサーバーの違い（ざっくり）
厳密な用語としては、
「Web サーバー」と「アプリケーションサーバー」を分けて説明することもあります。
Web サーバー
静的ファイル配信がメイン
HTTP の入り口として動く
アプリケーションサーバー
ビジネスロジックやトランザクション管理など、
アプリケーションの実行環境を提供
Java の世界では、
Tomcat などは「Servlet コンテナ」と呼ばれ、
Web サーバーとアプリケーション実行環境の中間のような存在です。
初心者のうちは、
「ブラウザからの HTTP を受けて、Java のコードを呼び出してくれる“土台”が Web サーバー」
くらいの理解で十分です。
初心者がまず押さえるべき Web サーバーのイメージ
あなたの言葉で整理すると、こうなります。
ブラウザは「URL を叩く人」。
Web サーバーは「そのリクエストを受け取って、どのアプリに渡すか決め、結果を HTTP として返す人」。
Java の Web アプリは、その Web サーバーの中で動いていて、
「リクエストを受けて処理し、HTML や JSON を返す中身のロジック」を担当している。
このイメージが腹に落ちると、
Spring Boot の「組み込み Tomcat」とか、
「ポート 8080 で待ち受ける」といった言葉が、
一気に意味を持ち始めます。