「telnetでWebサーバと喋ってみる」というタイトルで社内勉強会を開催しました。ネットワークまわりの知識の確認と、Webアプリケーション作成時にリクエストやレスポンスを覗き見る方法について紹介しました。
ムービー
発表資料
内容の補足など
この回は社内でたくさんツッコミをもらいました。以下、補足です。
PHPのheader関数で指定するのはレスポンスヘッダです。ボケてて言い間違えました。
IPアドレスとIP(プロトコル)は違います。IPアドレスを略してIPと言っている個所があると思いますが、今回はプロトコルの話をしてるんだから注意すべきでした。
サービス名とポート番号の対応が/etc/servicesに書いてあります。ポート番号の代わりにサービス名を書くこともできます。
$ telnet www.dino.co.jp http
「TELNETプロトコルは簡単、というのは本当なのか?telnetでも端末制御してるし、そこまで簡単なはずがないよね」と言われました。TELNETプロトコルの中で、一番簡単なモード(低機能端末用)が単純ということらしいです。よく知らずに言ってました。
「どうせ遊ぶならSMTPの方が楽しくない?」とも言われました。多分そうですね。ただ、勉強会は1枠30分くらいを目指しているので、個別のプロトコルの説明をしちゃうと終わらないかなーと思ったわけです…。まあこれは宿題ということにして、各自SMTPやらESMTPやらについて、RFCを見ながらメールサーバと会話してみてください。
持続的接続
持続的接続(persistent connection)に関して補足します。
-
持続的接続で必要な回数だけ通信したらコネクションを切るような図を示しましたが、実際にはどちらかがコネクションを切らないと切れません。
- ブラウザを終了させない限り、ブラウザが自分からコネクションを切ることは無いような気がします(確信はありませんが、どう調べりゃいいんですかね?)
- サーバはタイムアウトの設定があるはずです。普通はこれで切れるってことでしょう。
- Apacheの関連する設定
- 「KeepAlive On」で持続的接続を有効にします。
- 「KeepAliveTimeout」の設定は、持続的接続でパケットが何秒間流れなかったらコネクションを切るかの設定です。
- 「MaxKeepAliveRequests」ってのがあるみたいですが、僕はこの数字をいじった記憶がないです。MaxClientsと同じ数字にしておけばいいんですかね?
http-relay.sh
プレゼンの最後の方、資料で言うと34ページ目で紹介しましたが、http-relay.shというスクリプトを書きました。普段のブラウザを使い、Webサーバへのリクエスト、およびWebサーバからのレスポンスをそれぞれファイルに保存するものです。
何に使うの?というとあまり役には立たない気がします。学習用とか趣味とかでしょう。リクエストヘッダやレスポンスヘッダの改行がHTTPの仕様通りCRLFになっているか確認したい、といった非常にマニアックな状況でのみ有用だと思います。
これは、下記のツールを呼びつつ標準入力を少し加工しているだけです。
これは、簡易サーバ的なものを作るツール(tcpserverに似てるかな?)と、低機能なクライアント(telnetみたいなものだけど、きっと telnetより低機能)と、パケットフォワーダー的なツール(stoneの超簡易版)の3つのツールを提供するパッケージです。もっとメジャーなツールで実現し直そうかと思っていたのですが、「こんなこともできるよ」を示したかっただけなので、このまま公開することにしました。

コメント / トラックバック 2 件
RFC1945と2616を見る限り”Header Field Definitions”で”Host”があるのはHTTP/1.1のみで1.0では使えないと思います。Section1.1に”HTTP/1.0 does
not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. “とあり1.1での実装と思われますが・・
RFC1945のSection 5.2に「However, new or experimental header fields may be given the semantics of request header fields if all parties in the communication recognize them to be request header fields. 」という記述がありますから、HTTP/1.0で使っていけないわけではないと思います。また、今我々の身近にあるWebサーバ実装に関して言うと、HTTP/1.0でHostリクエストヘッダを解釈しないものは皆無だろうと思います。更に、RFC2616のSection 5.2で「Recipients of an HTTP/1.0 request that lacks a Host header field MAY attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine what exact resource is being requested.」とHostヘッダが無い場合の心配をしているので、HTTP/1.0でHostリクエストヘッダが付いている場合には適切に解釈してくれそうな気がします。
RFC2616のSection1.1で言っているのはRFC1945が不十分だったと言っているだけで、RFC2616に従って作られたサーバでのHTTP/1.0での通信に関して同じ問題があるとは限らないのではないでしょうか。
詳しい人の意見が聞きたいところですね…
コメントする