FY2025: Apache/Nginx 研修の更新 (#195)

matsui-shin · web-flow · commit 25bcd21c6ab1 · 2025-07-30T10:50:07.000+09:00
* Apache/Nginx 2025: 座学部分の更新

- 調査結果のリンクを最新のものに更新
- 古くなっている言い回しを微調整

* Apache/Nginx 2025: curl 対応

- 足元でない場合などブラウザでアクセスしづらい環境もあるため、curl
  で確認できるようにする

* Apache/Nginx 2025: telnetでHTTPを直接喋る課題の追加
diff --git a/src/web-server/apache_nginx/README.md b/src/web-server/apache_nginx/README.md
@@ -46,7 +46,7 @@ Building dependency tree... Done
 Reading state information... Done
 10 packages can be upgraded. Run 'apt list --upgradable' to see them.
 
-root@a0da070e286f:/# apt install -y apache2 apache2-dev nginx neovim
+root@a0da070e286f:/# apt install -y apache2 apache2-dev nginx telnet neovim
 Reading package lists... Done
 Building dependency tree... Done
 Reading state information... Done
@@ -101,6 +101,7 @@ Webサーバのシンプルな機能は前述の通りですが、実際には
 - nginx
 
 あたりでしょうか。Linuxサーバー上で動かすのであればほぼApacheとnginxの2択になると思います。
+(参考: [June 2025 Web Server Survey](https://www.netcraft.com/blog/june-2025-web-server-survey/))
 
 また最近ではenvoyやtraefikなど、クラウドやKubernetesという文脈ではプロキシ機能に特化したソフトウェアが使われることも多くなりました。
 
@@ -110,12 +111,11 @@ Webサーバのシンプルな機能は前述の通りですが、実際には
 
 「Apache HTTP Server」はnginxと並んで2大勢力を誇っているWebサーバソフトウェアのひとつです。 CentOSではhttpdという名前になっていたり、単にApacheと呼ばれます。
 
-「Apache HTTP Server」は「Apacheソフトウェア財団」によって管理されるOSSで、20年以上の歴史を持ちます。 世界的にもっとも普及したWebサーバで、LAMP（Linux, Apache, MySQL, PHP）環境のひとつにも挙げられ、nginxと並んで2大勢力を誇ります。
-(参考: [June 2024 Web Server Survey](https://www.netcraft.com/blog/june-2024-web-server-survey/))
+「Apache HTTP Server」は「Apacheソフトウェア財団」によって管理されるOSSで、20年以上の歴史を持ちます。 世界的にもっとも普及したWebサーバで、Webサイトの定番OSS構成としてLAMP（Linux, Apache, MySQL, PHP）があげられる時期もあり、nginxと並んで2大勢力を誇っていました。
 
 正式名称は「Apache HTTP Server」ですが、歴史的経緯などからCentOSではhttpdという名前になっていたり、単にApacheと呼ばれたりします。
 
-以前は大量のリクエストを受けた際にプロセスをforkできず、リクエストを捌き切れなくなる（いわゆるC10K問題）ことが問題視されました。 その際nginxをはじめとして新しいWebサーバーソフトウェアが登場しましたが、Apache自体もworkerやevent MPMといった新しい仕組みを導入し、動作も安定していることからいまだに高いシェアを占めています。
+以前は大量のリクエストを受けた際にプロセスをforkできず、リクエストを捌き切れなくなる（いわゆるC10K問題）ことが問題視されました。 その際nginxをはじめとして新しいWebサーバーソフトウェアが登場しましたが、Apache自体もworkerやevent MPMといった新しい仕組みを導入し、多機能で動作も安定していることからいまだに高いシェアを占めています。
 
 ### nginx
 
@@ -132,13 +132,33 @@ nginxは2004年頃、当時のWebサーバーが抱えていたパフォーマ
 
 ### HTMLファイルの配信(check1)
 
-まずはApacheを起動しましょう。
+まずはApacheを起動してデフォルトのページを見てみましょう。
+ページの確認には、CLIでの定番であるcurlコマンドを使ってみるのがよいでしょう
 
 ```shell-session
 root@a0da070e286f:/# service apache2 start
+root@a0da070e286f:/# curl http://localhost
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+    <title>Apache2 Debian Default Page: It works</title>
+    <style type="text/css" media="screen">
+
+(中略)
+
+      </div>
+    </div>
+    <div class="validator">
+    </div>
+  </body>
+</html>
 ```
 
-ブラウザを開いて[localhost:8080](http://localhost:8080)にアクセスしてみてください。以下のような画面が表示されれば成功です。
+docker を手元で動かしている環境の場合は、ブラウザで開いて[localhost:8080](http://localhost:8080)にアクセスしてみることでも確認可能です。
+コンテナの中からは80番ポート、外からは8080番ポートからアクセスできるように設定されています。
+以下のような画面が表示されれば成功です。
 
 ![apache-start](./image/apache-start.png)
 
@@ -153,23 +173,27 @@ Document RootはApacheが静的ファイルを配信するためのroot director
 ```shell-session
 root@a0da070e286f:/# mv /var/www/html/index.html /var/www/html/_index.html
 root@a0da070e286f:/# echo 'Hello Bootcamp!!' > /var/www/html/index.html
+root@a0da070e286f:/# curl http://localhost
+Hello Bootcamp!!
 ```
 
-再び`http://localhost:8080/`を開くと`Hello Bootcamp!!`が表示されるのを確認してください。
+`Hello Bootcamp!!`が帰ってくるのを確認してください。
 
 ::: tip
-`http://localhost:8080/` のようにファイル名を指定せずディレクトリ（この場合はルートディレクトリ）を指定した場合、Apacheは`index.html`を返すようにデフォルトで設定されています。
+`http://localhost/` のようにファイル名を指定せずディレクトリ（この場合はルートディレクトリ）を指定した場合、Apacheは`index.html`を返すようにデフォルトで設定されています。
 この設定は変更できます。
 :::
 
-Document Root配下にディレクトリを作成するとブラウザからも同様にアクセスできます。
+Document Root配下にディレクトリを作成すると対応するパスを指定することで同様にアクセスできます。
 
 ```shell-session
 root@a0da070e286f:/# mkdir /var/www/html/hoge
-root@a0da070e286f:/# echo 'Hello HUGA!!' > /var/www/html/hoge/huga.txt
+root@a0da070e286f:/# echo 'Hello FUGA!!' > /var/www/html/hoge/fuga.txt
+root@a0da070e286f:/# curl http://localhost/hoge/fuga.txt
+Hello FUGA!!
 ```
 
-`http://localhost:8080/hoge/huga.txt` にアクセスすると追加したファイルが表示されます。
+ブラウザからの場合は、`http://localhost:8080/hoge/fuga.txt` にアクセスすると追加したファイルが表示されます。
 
 アクセスログも確認してみましょう。
 
@@ -258,7 +282,16 @@ CentOSなど他のディストリビューションでは、これらのコマ
 root@a0da070e286f:/# service apache2 reload
 ```
 
-`localhost:8080`と`localhost:8082`にアクセスしてみてください。意図通りの挙動になっているでしょうか。
+それでは、アクセスしてみましょう。意図通りの挙動になっているでしょうか。
+
+```sh
+root@a0da070e286f:/# curl http://localhost:80
+This is site 80!
+root@a0da070e286f:/# curl http://localhost:82
+This is site 82!
+```
+
+ブラウザからの場合は、`localhost:8080`と`localhost:8082`にアクセスしてみてください。
 
 | ![site-80](./image/site-80.png) |
 | ------------------------------- |
@@ -302,7 +335,14 @@ root@a0da070e286f:/# service nginx start
 [ ok ] Starting nginx: nginx.
 ```
 
-[localhost:8088](http://localhost:8088) にアクセスしてみてください。さっき作った`Hello Bootcamp!!`のHTMLが見えていれば成功です。
+それではアクセスしてみましょう。さっき作った`Hello Bootcamp!!`のHTMLが見えていれば成功です。
+
+```sh
+root@a0da070e286f:/# curl http://localhost:88
+Hello Bootcamp!!
+```
+
+ブラウザからの場合は、[localhost:8088](http://localhost:8088) にアクセスしてみてください。
 
 ![nginx_html](./image/nginx_html.png)
 
@@ -349,9 +389,18 @@ root@a0da070e286f:/# service nginx restart
 [ ok ] Restarting nginx: nginx.
 ```
 
-[http://localhost:8089/](http://localhost:8089/) にアクセスしてみてください。
+それでは、確認です。
 site-80とsite-82がランダムで表示されたでしょうか。
 
+```sh
+root@a0da070e286f:/# curl http://localhost:89
+This is site 80!
+root@a0da070e286f:/# curl http://localhost:89
+This is site 82!
+```
+
+ブラウザからの場合は、[http://localhost:8089/](http://localhost:8089/) にアクセスしてみてください。
+
 ### コンテンツをキャッシュしてみる(check5)
 
 Webサーバを多段で使う目的の一つとして、キャッシュを行う、というのもあります。
@@ -406,16 +455,87 @@ root@a0da070e286f:/# service nginx restart
 [ ok ] Restarting nginx: nginx.
 ```
 
-[http://localhost:8089/](http://localhost:8089/) にアクセスしてみてください。
-ブラウザの開発者モードなどでヘッダを覗いてみると、X-Nginx-CacheにMISS、あるいはHITが入っています。
+それでは、確認です。
+キャッシュの状態については、デフォルトではレスポンスヘッダにX-Nginx-Cacheの形で付与されます。
+curl に-vオプションをつけてみて、ヘッダを確認してみましょう
+
+ブラウザの場合は、開発者モードなどでヘッダを覗くことができます(通常、F12で開発者モードを起動できます)。
+
+```sh
+root@a0da070e286f:/# curl -v http://localhost:89
+*   Trying 127.0.0.1:89...
+* Connected to localhost (127.0.0.1) port 89 (#0)
+> GET / HTTP/1.1
+> Host: localhost:89
+> User-Agent: curl/7.88.1
+> Accept: */*
+>
+< HTTP/1.1 200 OK
+< Server: nginx/1.22.1
+< Date: Tue, 29 Jul 2025 11:29:33 GMT
+< Content-Type: text/html
+< Content-Length: 17
+< Connection: keep-alive
+< Last-Modified: Tue, 29 Jul 2025 11:27:56 GMT
+< ETag: "11-63b0fb32120e5"
+< X-Nginx-Cache: HIT
+< Accept-Ranges: bytes
+<
+This is site 80!
+```
+
+X-Nginx-CacheにMISS、あるいはHITが入っていることが確認できましたでしょうか。
 今回、わざとキャッシュの保持期間を1分と短くしていますが、2分ほど待った後で改めてアクセスしてみると、MISSが入っているものが観測できるかと思います。
 
 キャッシュが利用できた場合、裏のapacheへのアクセスも省略されたことをログから確認できるはずです。
 
 キャッシュの実体はこの設定だと/var/cache/nginx 下に置かれます。
-catしてみてどういうものがキャッシュされているのかも見てみましょう。
+catしてみてどういうものがキャッシュされているのかも見てみるとよいでしょう。
 
 ## 追加課題（時間の余った人用）
+### HTTP を直接喋ってみる
+HTTPは割とシンプルなテキストプロトコルなので、比較的簡単に直接やり取りを行えます。
+直接やり取りをするには、telnetを使うのがよいでしょう。
+
+```shell-session
+root@a0da070e286f:/# telnet 127.0.0.1 80
+Trying 127.0.0.1...
+Connected to 127.0.0.1.
+Escape character is '^]'.
+=== ここから入力 ===
+GET / HTTP/1.0
+User-Agent: hogehoge
+(Enterを2回)
+=== ここまで入力 ===
+HTTP/1.1 200 OK
+Date: Tue, 29 Jul 2025 10:45:22 GMT
+Server: Apache/2.4.62 (Debian)
+Last-Modified: Tue, 29 Jul 2025 10:31:40 GMT
+ETag: "11-63b0ee9e7ab92"
+Accept-Ranges: bytes
+Content-Length: 17
+Connection: close
+Content-Type: text/html
+
+Hello Bootcamp!!
+Connection closed by foreign host.
+```
+
+入力したのは、リクエスト行とヘッダ。ヘッダフィールドには複数行入れられますが、その終了は空行をもって宣言するため、2回改行を入れました。
+今回は、HTTP1.0のGETのため、リクエストボディは省略されすぐさまレスポンスが返ってきます。
+
+アクセスログを見てみると、User-Agent が確かに渡されたことも確認できます。
+
+```sh
+root@a0da070e286f:/# tail /var/log/apache2/access.log
+127.0.0.1 - - [29/Jul/2025:10:45:22 +0000] "GET / HTTP/1.0" 200 263 "-" "hogehoge"
+```
+
+User-Agentの値を変えてみるとログの記録も変わります。
+リクエストヘッダは簡単に捏造できるものであることは覚えておきましょう。
+Webサーバ任せで静的なファイルを配信する分には、捏造されたヘッダで悪影響を及ぼすことはWebサーバ側で対策されているのでまずないですが、
+CGIやアプリサーバなどでヘッダ情報を利用する場合は十分に気を付ける必要があります。
+
 ### サーバ側でキャッシュを制御してみる
 
 本編では、nginxに施した設定に従ってキャッシュを行っていました。
