今回はプロトコルについて話してみます。

インフラエンジニアをやっていると，「⁠プロトコルを知っているかどうか」というのが他のエンジニアと差がつく部分のひとつになります。

そこで知っておきたいのが，まずtelnetについてです。

「手動でプロトコルを送る道具」としてのtelnet

ssh以前はコンピュータに接続するにはtelnetが多かったわけですが（rloginとかrshとかもありましたけど⁠）⁠，telnet自体はtelnetサーバ（telnetdなど）とやりとりしてコンピュータと接続する（ログインする）ためのコマンドであると同時に，平文を無手順で送受信できるため，平文のプロトコルであれば手入力で再現することができる道具でもあります。

telnetのsyntaxは

$ telnet [option] [host [port]]

です。hostがないとportが書けないので[host] [port]ではないのと，host自体も省略できます（その場合interactiveモードに入ります。helpと打つとコマンド一覧が出ます⁠）⁠。

portを省略すると23/tcp（telnetのwell known port）に接続されますが，ここでSMTPやHTTPなどのwell known port（25や80）を指定して起動すると，それらのサーバと接続することができます。

バイナリプロトコルには使えません

残念ながら平文以外（バイナリプロトコルや暗号化するプロトコル）や，UDP上のプロトコルはtelnetでは扱えませんが，暗号化やUDPとのやり取りは，そういうツールを作れば平文でやりとりすることができるようになります。

バイナリプロトコルは専用のツールを作るしかありません。とはいえ，バイナリプロトコルのためのツールを作るのはさほど難しいことではないので，チャレンジしてみるのもいいと思います。たとえばPerlだとバイナリプロトコルを扱えるCPANモジュールがたくさんあったりしますし，なくてもプロトコルフォーマットさえわかれば作れます。筆者は昔，PerlでNTPを扱えるモジュールがないので，そういうスクリプトを書いたことがあります。Perlの場合は，pack，unpackとビットシフト，あとはsocket操作ができれば自由自在です。

UDPの扱いや暗号化するプロトコル，バイナリプロトコルについてはまた機会があれば紹介するとして，今回はTCP上の平文プロトコルに限定して解説してみます。

まずはプロトコルを知るところからです。

プロトコルの原典「RFC」

プロトコルはRFCに書いてあります。RFCについても近々この連載でとりあげたいと思いますが，RFCは誤解を怖れずに超簡単に言えば「インターネット上の各種の約束について書いてある文書」です。

RFCにはInformationalやDraft，Standardなど各種の「状態」があります。本来であればStandardが「標準の」状態になるわけですが，RFCは法律ではなく「提案された約束事」なので，常にStandardを参考にして実装されているわけではなく，Draft状態で実装されているケースもありますから，そこは適宜使い分けましょう。

RFCの公式な置き場所は以下になります。

Request for Comments （RFC）

URL：http://www.ietf.org/rfc.html

ただ，RFCは各所にコピー（ミラー）されていますので，手に入れやすいところを探しましょう。ミラーポリシー的に許されるのであれば，組織ごとにコピーを置いても良いと思います（いまのミラーポリシーは把握していませんすみません⁠）⁠。

また，RFCは全部英語ですが，有志の方々による日本語化されたRFCもたくさんあります。最新のRFCは訳されていないことも多いので，そういう時は英語を頑張って読みましょう。

RFCの読み方

RFCで最初にぶつかる壁は「どれを読めばいいかわからない」という点です。もちろん検索することもできますが，執筆時点で6000を越えているので，適切なRFCに辿りつけない可能性もあります。

たとえばDNSのRFCといえばまずはRFC1034ですが（筆者的には⁠）⁠，このRFC1034は，“⁠Domain names - concepts and facilities⁠”というタイトルなので，“⁠DNS⁠”で検索しても引っかかりません。このあたりは正直「慣れ」るしかない部分もあります。

以下のURLに全RFCの一覧があるので，このファイルを検索したりざっと眺めてみるのも良いと思います（RFCトップページで検索フォームを使うより速いです⁠）⁠。

RFC INDEX

URL：http://www.ietf.org/rfc/rfc-index.txt

この一覧（そして個々のRFCの文頭にもありますが）には「Status」という部分がありますが，ここがそのRFCの状態を表しています。

もうひとつ見るべきところが，「⁠Obsoletes」もしくは「Obsoleted by」という部分です。このどちらも書いてないRFCもたくさんありますが，「⁠Obsoletes」と書いてあるのは，他のRFCを「時代遅れにしている」という意味─つまり更新版であるということです。「⁠Obsoleted by」はその逆で，他のRFCによって「時代遅れにされている」という意味になります。つまり「Obsoleted by」のRFCは基本読む必要がありません（昔のRFC実装をしているサーバの挙動を調べるときなどは読む必要があるかもしれません⁠）⁠。

またこれとは別に「Updates」と「Updated by」という記述がある場合もあります。「⁠Obsoletes」「⁠Obsoleted by」は文書まるまるについて更新している，されているという場合ですが，「⁠Updates」「⁠Updated by」は文書の一部分について更新している，されているというケースになります。「⁠Updated by」が付いていても，その文書は有効な部分がある（ことがある）ということになります。