処理 - みる会図書館

1. UNIX MAGAZINE 2002年1月号

UNIX Communication Notes 山口英局性能サーバーを目指して ( 3 ) 図 1 トランサクションの構成十分な処理速度が得られるサーバーこのシリーズでは、インターネットにサービスを提供する高性能なサーバーを構成する技術について解説している。 1 回目 ( 2001 年 11 月号 ) で述べたように、高性能サーバーカえるべき要件は以下の 3 点に集約できる。クライアント処理要求サーバー処理結果の返送占郞章に強い。・十分な処珊度か得られる。手間がかからない。今回は、、、十分な処理速度が得られる " サーする技術をとりあげる。里とは何かーを構成技術そのものの説明に入る前に、サーバーにおける処理速度について考えてみよう。インターネットにおける大部分のサーピスは、クライアント・サーバーモテフレにもとづいておこなわれている。つまり、サーーはクライアントからの処理要求を受け付け、なんらかの処理を施し、結果をクライアントに送り返す。一般に、クライアントとサーバーとのあいだのやりとりは、、トランザクション (transaction)" と呼はれる。 WWW システムを例にとると、クライアントからの HTTP GET リクエストの送信と、サーバーから応答として返されるデータの送受信によって 1 つのトランサクションカ材冓成される。トランザクション処理は、大雑把にいえは図 1 のようにおこなわれる。ます、クライアントにおいて日該れ 1 にトランサクションが始まる。これが、サーバーには日該れ 2 に届一一一一一一一一一一一一一いたと - ーしようこの図では、処理要求は 1 バケットになっ UNIX MAGAZINE 2002.1 ているが、複数のバケットから構成される場合もある ) 。の場合、 t2 ー tl はバケットの伝送遅延を表す。サーバーは処理要求を受け取り、処理をおこなって時刻なに返送する。すなわち、 t3 ー t2 がサーノヾーでのトランザクション処王寺間である。そして、日該れ 3 から t4 までのあいだに、処理結果か数のバケットとしてクライアントに送り返される。トランサクション全体の処理には、 t4 ー tl の時間がかかっていることになる。 1 つのトランザクション処理は、以下の要素から友される。 1. 処理要求の伝送 2. サーバーでの処理 3. 処理結果の伝送 1 番目と 3 番目は伝送遅延であり、ネットワークの性能に左右される部分である。 2 番目はサーバーの処理生能そのものを表す。高性能サーバーを構築するには、この 2 つ、すなわちネットワークでの遅延とサーバー本体での処理日判りをま可宿する必要がある。 55

2. UNIX MAGAZINE 2002年1月号

連載 /UNIX Communication Notes—O との受信侍ち状態に戻り、もう 1 つのプロセスは処理をおこなうかたちになっていた。これを擬似コードて表現すると、次のようになる。 main() 初期処理 ; socket() ; S bind(s, listen(s) ; while ( 1 ) { / * socket の生成 * / / * s 。 cket に対する設定 * / accept(s, C S exit(O) ; close(cs) ; 実際の処理 ; close(s) ; / * 子プロセス * / if ((pid = fork() / * 受信待ちでプロックこのコードからも分かるように、子プロセスがクライア / * 親プロセスは実際に接続されたソケットをクローズ * / / * 受信待ちに戻る * / close(cs) ; システムコールを用いて起動するかたちにした。 inetd に理するプログラムを inetd が fork() し、さらに exec( 特定のポートへのアクセスがあった場合、そのポートを処をしなければならない複数のポートを監視する。そして、 inetd は、 select() システムコールを使って、受信待ち UNIX で標準的に使われるようになった。 inetd (lnternet super daemon) が開発され、 4.3BSD せておかなけれはならないという間題を解決するために上記の間題のうち、あまり使われないデーモンも不力さ inetd の登場かった。・プロセスを複製する fork() システムコールの実行が遅った。モリしかなかった衫琪月の UNIX システムには重荷となとして、プロセステープルか増えてしまい、わずかなメめ、デーモンとして稼動させるプロセスか増える。結果・ふだん利用しないサーバーもデーモンとして起動けるたこの方式には、以 - ドのような間題があった。のソケット接続要求だけを処理する構造になっている。ントからの要求を処理し、親プロセスはクライアントから 64 よって起動される処理プログラムは、標準入力からデータを読み込むと socket に届いたデータを読むことができ、標準出力に書き出すと相手にデータか送られるような形式 UNIX MAGAZINE 2002.1 グラムのなかでうまく処理できるようにすれはよい。このきなオーバーヘッドをともなう実装ではなく、 1 つのプロだけに fork() でプロセスを複製している。このように大さきはど窈疑似コードでは、処理をおこなう部分のためラムが考案された。 fork() によるプロセスの複製はしないサーバー・プログ間で通常のデーモン・プログラムとして実行されるが、その後カーネルに組み込むのではなく、ユーサー空ユーサー空間で作るネルに組み込まれることはあまりなかった。くい。そのため、 NFS 以外のサーバー・プログラムがカーへの糾込みは、作業か難しいだけでなく、デバッグもしにしかし、一殳的な処理をおこなうプログラムのカーネルていた。ファイルシステムを扱う NFS はカーネルへの実装に適しロセスの複製というオーバーヘッドを軽減した。しかも、常駐スレッド (thread) をカーネルに組み込むことで、プしようと考えたわけである。 NFS では、処理をおこなうるプロセスの複製はしないように実装し、処理性能を改善変わりはなかった。そこで、常駐はしても、 fork() によって複製される状況は、 inetd かイ吏われるようになってもサーバーへのアクセスがあるとプロセスが fork() によこれは、 NFS サーバーの実装の際に採られた方法である。次に考えられたのが kernel resident thread である。 kernel resident thread えなかった。にデーモンとして起動さ常駐するという形態をとらざるをなどの常駐すべきサーバーは、依然としてシステムのプート時けではない。たとえば、 UDP を用いたサービスや、 sendmail しかし、すべてのデーモンが inetd の管理下に置かれたわノート 5 わすかながら改善された。状態にしておくという間題カ黝夬さシステムの性能がきる。これにより、起動された大量のデーモンを受信待ち peername() などのライプラリ関数を用いて知ることがでの API が定められた。相手のアドレスなどの情報は、 get-

3. UNIX MAGAZINE 2002年1月号

図 3 /etc/exports 列 /usr/local /usr/local /home —maproot=O : 0 —ro —network —network 192. 168. 1 . 0 —mask 255 .255.255.0 192. 168.1 . 0 —mask 255.255.255.0 myp c NFS サーバーの設定ファイルのロックを別にすると、 NFS サーノヾーでおこなわれる処理は、以下の 2 つに分かれます。・マウント要求の処理 UNIX MAGAZINE 2002.1 デモン、プログラムです。共有されたファイルに対するロック機溝を寒見するため・ rpc. lockd の起重丿時の引数で変史できます ) 。います ( 多くの場合、同時に起重丿けるプロセス数は nfsd 起動され、複数の要求を並列に処理できるようになってれるのに対し、 nfsd は通常 4 ~ 6 個のプロセスか 1 司時にデーモン・プログラムです。 mountd が 1 つだけ起動さ NFS クライアントからのファイル操作要求を処理する・ nfsd モン・プログラムです。 NFS クライアントからのマウント要求を処理するデー・ m011 ⅲ d は、名前が異なることもあります ) 。があります ( これは FreeBSD の場合です。はかの OS でて起動されるデーモン・プログラムには以下のようなものデーモンがおこないます。これらも含め、 NFS サーほとんどの OS では、これらの処理はそれぞれ独立した移動などが含まれます。操作と同様、読出し、書込み、ファイルの作成・削除・す。ファイル操作には、ローカルなファイルに対する NFS クライアントからのファイル操作要求を処理しま・ファイル操作要求の処理マウントの可否を決定します。し、あらかじめ設定されたアクセス制御リストに従ってーは NFS クライアントからのマウント要求を処理レクトリをマウントしなければなりません。 NFS サー有するためには、ます NFS サーノヾー上の特定のディ NFS クライアントが NFS サーバー上のファイルを共・ rpc. statd コンピュータの状態を監視するためのデーモン・プログラムで、 rpc. lockd や、ほかのコンピュータの rpc. statd と叫して重川します。 nfsd や rpc. lockd 、 rpc. statd は、起重圻は自動的に処理をおこなってくれます。したがって、 NFS サーバーに対して管理者がおこなう設疋は mountd の動作、つまり NFS サーノヾーの、・どのディレクトリを・どの NFS クライアントに対して・どのようにマウントさせるかを決めることです。 /etc/exports 多くの UNIX では、これらの設定は /etc/exports というファイルに言当します 7 。基本的には、一ド記の情報の組を 1 行すっ列挙します。・エクスポートするディレクトリ・マウントを許可する NFS クライアント・マウント広 ) オフションたとえは、 /usr/local と /home を工クスポートする場合、 FreeBSD の /etc/exports ファイルは図 3 のようになります。 1 行目では、 NFS サーバーの /usr/local を、 mypc という NFS クライアントにェクスポートしています。 mypc からは読み書き可能であり、 mypc のスーパーユーサーは、共有したファイルを NFS サーバーのスーパーューザーと同し権限で操作できます (-maproot オプション ) 。 2 行目は、ローカル・ネットワーク ( 192.168.1.0 ) 内のすべての NFS クライアントに対して (-network オプション ) 、 /usr/local を言蒄呂し専用 (-ro オプション ) で 7 NFS サーバーが NFS クライアントに対してディレクトリを公開することを、、、ェクスポートする " といいます。 39

4. UNIX MAGAZINE 2002年1月号

連載 UNIX Communication N0tes—O ために利用できるのが、 select() システムコールである。 select() は、複数のファイル識別子で指定される入力ソケットを監視し、カーネル内でプロックする。読み出せるようになった ( 到着した ) ソケットがあるとプロックか外れ、処理ルーチンを同一プログラム内でおこなうようにするコードか書ける。これにより、複数のソケットを監視しながら処理を夫行するルーチンか書けるようになった。しかし、この実装には大きな問題がある。プログラムを実行しているコンテキストは 1 つしかないので、リクエスト処理ルーチンを実行しているあいだは、ほかのソケットに到着したデータや新たな接続要求はすべてカーネル内にイ尉寺される。けっきよく、 fork() は使わなくても、すべての処理がシリアライズされるため、高い性能か得にくくなった。もちろん、リクエスト処理ルーチンの処理量が大きいと、処理待ちになるリクエストも増えることになってしまう。そこで、登場するのがスレッドである。その考え方は実装により多少異なるが、おおまかには次のようなもので・スレッドを利用するプログラムでは、その実行時に複数のスレッドを起動することができる。・ 1 つのスレッドは、実行を管理するためのコンテキストをもつ。ここには、プログラム・カウンタとスタックだけが用意されている。つまり、現在、どの部分を実行しているかという情報と局所変数だけが各スレッドに割り当てられている。大域変数は、すべてのスレッドて共有される。したがって、或変数を使えばスレッド間での通信カそきる。・スレッドの生成や消去などは、プログラムで明カ勺に記述できる。スレッドを利用すると、ユーサー空間て稼動するプログラムで並列処理を簡単に記主できる。描丘の生能サーバーの世界では、スレッドの利用を目指す開発か続けられている。現在のスレッドの実装には、 BSD 系の pthread や Linux の linux pthread などがある。これらはそれぞれに実装形態か違い、長所もあれば短所もある。また、 BSD の pthread の実装のように、システムコールとの親和がやや悪いという欠点は解消されつつあるが、完全、解決されたわけではない。スレッドを利用するサーバー UNIX MAGAZIN E 2002 ユはまだ少ないが、高性能サ→ヾーの世界ではスレッドを用いた開発が一殳的になり始めている。 WWW サーバーの Apache 2.0 系列がその一例である。今後、高生能サーーを構築する際には、使用されるプログラム自体がスレノ、ッドを使う実装になると思われる。 ☆ 今回は、十分な処理性能が得られるサーバーの構築方法について述べた。むろん、厳選された性能のよいパーツを用いて高生能サーバーを構築するガ去もあるが、レイヤ 4 / 7 スイッチを使ったクラスタ化によって実現することも増えてきている。とくに、商用 WWW サービスを提供するサイトなどでは、常識といってもよいはどクラスタ化サーバーの利用が進んでいる。高生能サーバーを導入する場合は、レイヤ 4 / 7 スイツチを用いたサーバー構成のノウハウを応用するとよい。最近は、サーバー・プログラムそのものの高性能化もスレッドを用いた並列処理によって見されようとしている。スレッドを用いた処理は SMP 型システムとの整合生もよく、今後、高性能サーバー・プログラムの実装手法として普及する可能性がある。サーバーの実装を目指すソフトウェア技術者は、スレッドを用いたプログラム開発の腕を磨くべきであろう。 ( やまぐち・すぐる奈良先立斗 ! 物支彳大芋ギ完大学 ) [ 文献 ] [ 1 ] Lawrence S. Brakmo and Larry L. Peterson, "TCP Vegas: End t0 End Congestion Avoidance on a Global lnternet ” IEEE ノ 0 社ロ田 1 0 れ Selected Areas をれ Comm 社れを ca 0 れ , V01.13 , NO. 8 , Oct0ber 1995 (ftp: //ftp.cs.arizona.edu/xkernel/Papers/jsac.ps. Z) 65

5. UNIX MAGAZINE 2002年1月号

表 1 VMware 、 vorkstation 2.0 でのネットワーク送言 CPU の分布ート合言カテゴリー VM M 日 VMNet 経由での送信 Lance ステータス・レジスタのエミュレホスト IRQ ( テパイス割込み ) の処理 Lance のエミュレート VMNet 経由での受信 VMM カテゴリー VMApp への切替えを要求する IN/OUT イ瓦想北を要求しない命令イ瓦想北を要求する - ヨ殳命令 VMM て処理される IN/OUT Lance アドレスポートへの IN/OUT イ瓦想コードへ ( から ) の移行 IRET 命令のイ瓦想化イ瓦想 IRQ ( テパイス割込み ) の伝土俿冾 0.8 % 3.3 % 3.4 % 4.0 % 8.7 % 77.3 % 4.6 % 4.8 % 4.8 % 8.1 % 8.3 % 11.6 % 22.0 % 26.8 % 日の害冾平均日繝なし 3.93 s なし 0.74 卩 s 1.36 ″ s なしなし 7.45 ″ s 平均日鋿 1.8 s 5.2 s なし 3.1 / ↓ s 13.8 ″ s なし最大のオーバーヘッドは、 VMApp , ) 鼬或切替えか要求される I/O 空間へ、のアクセスと、それを VMApp で処理する時間である。くとも 2 倍は遅くなる引算である。オーバーヘッドのおもな要因としては、このほかに表 1 中の複数のカテゴリーで必要な IRQ の処理か挙げられる。 AMD Lance の一反想 NIC は、 lntel EtherExpress の物理 NIC と同様に、バケットの送受信のたびに IRQ ( テンヾイス割込み ) を発行する。したがって、ネットワークの利用率か高いワークロードではマシンの割込み率がきわめて高くなる。ホスト協調型アーキテクチャでは、 VMM 領域の実行中に受信される IRQ ごとに VMM の割込みハンドラか実行さホスト領域への切替えが発生する。ホスト領域では、 IRQ に対応するホスト OS の割込みハンドラを実行し、 VMApp に制御を渡してその結果の動作が処理される。 IRQ がゲスト OS に関係するものである場合 ( ゲスト宛のバケットが受信されたことを示すなど ) 、 VMApp はイ廨課 IRQ をゲスト OS に伝える必喫がある。これには、 VMM 領域への切替え、イ瓦想マシンへの IRQ のイ幻土、ゲスト OS の割込みハンドラの実行がともなう。 VMM とホスト OS の割込みハンドラのはかにゲスト OS の割込みハンドラが実行されるため、 IRQ のコストは増大する。また、イ反想割込み処理のルーチンは、イ廨当ヒにコストがかかる牛罸雀モードの命令を実行する。表 1 を見ると、 VMM が処理するはとんどの IN/OUT は仮想割込みコントローラへのアクセスである。また、ほとんどの 166 IRET 命令はゲスト OS の割込みハンドラの最後で実行される。そして、 VMM 領域でおこなわれる割込み処理は、ホスト領域でおこなわれる割込み処理とくらべてはるかにコストか高い。これは、 VMM の割込みハンドラとホスト領域への領域切替えか原因である。ホスト協調型アーキテクチャには、この分析結果からは分からないもう 1 つのオーバーヘッドがある。 VMApp と VMM は、イ廨課マシン用のイベントを生成するハウェア割込み ( ゲスト OS 宛のノヾケットが受信されるなど ) と、仮想マシンとは関係のないハードウェア割込みを区別できないのである。これを区別できるのは、ホスト OS とそのドライバだけである。そこで、バランスをとるための工夫をした。つまり、 VMApp は IRQ に応して、 VMM が VMApp に制御を戻したときに何もしないか、あるいは VMApp から select() を呼び出す。 select() を頻繁に呼び出しても無駄になるが、適度に呼び出さないとネットワークの I/O イベントの処理リな遅れが生しる可能生がある。 3.3 ネットワークの仮想化によるオーバーヘッドの軽減領域切替えがオーバーヘッドの最大の要因だとした前節の糸喆侖を踏まえ、ホスト協調型の I/O アーキテクチャを UNIX MAGAZINE 2002.1

6. UNIX MAGAZINE 2002年1月号

図 3 連載 /UNIX Communication Notes—O レイヤ 4 / 7 スイッチによる WYVW サーパーのクラスタ化 WWW要素サーバーレイヤ 4 / 7 スイッチレイヤ 4 / 7 べしスイッチレイヤ 4 / 7 スイッチハブ CGI-bin 要素サーバー・ TCP コネクションの送信ホストアドレスと受信ホストアドレスの組でフローを識別し、それにもとづいて要素サーバーにフローを振り分ける。・サーバーの下丿獻態を定期的にチェックし、問題が発生したサーバーを自重加勺にクラスタから切り離す。・ WWW アクセスの場合は、障害がしているサーバーに振り分けられた HTTP リクエストをほかのサーバーにリダイレクトする。・ Cookie を用いて、クラスタ内のどのサーバーを使うかを制御する。・ HTTP リクエストの内容を角斤し、 URL に応して使用するサーバーを切り替える。とくに、後半の 3 つの機能はアプリケーションに依存するものであり、これらをまとめて、、レイヤ 7 スイッチ機能 " と呼ふ合もある。これらの機能をうまく組み合わせてクラスタを構成すオ L ばよい。うまく構成するには、前回説明した、、処理の副作用 " を十分に検詞するのがコツである。たとえば、 WWW サーバーであ川ま、 HTML ファイルなどの通常のファイルへの単純な読出しアクセスの場合には副作用がないので、単純なクラスタリングで対応できる。一方、 CGI プログラムの処理は副作用が多いので、レイヤ 7 スイッチ機能を用いて別のサーバーに振り向けるしかない。これらの点を考え合わせると、図 3 のような構成のシステムを作ること 60 HTML 文書管理用バックエンド・システム UNIX MAGAZINE 2002.1 受け持っ処理の内容 ( この例ではデータベース ) によっ能性か咼い。その場合も、バックエンド・サーバーがこのバックエンド・サーバーがポトルネックになる可ような形態にしている。このような構成にしたときは、処理を完全にバックエンドのサーバー 1 台に集約する処理の根にあることが分かる。そのため、副作用のあるば去絲冬的にデータベース・サーバーが副作用をともなうる処理といっても、その内容をよくみていくと、たとえとするものを専用のクラスタへ振り向ける。副作用のあは HTTP リクエストのなかで副作用のある処理を必喫・同しく 2 段目のレイヤ 4 / 7 スイッチのうち、下の C ディスクに一尉寺する。 HTML ファイルなどの読出しのみのデータをローカルサーバーに平均化して振り向ける。各要素サーバーは、としての機能をもち、 HTTP リクエストを複数の要素・ 2 段目のレイヤ 4 / 7 スイッチのうち、上の B は SLB セスをうける。 HTTP アクセスと、副作用をともなう CGI-bin アクチ A のレイヤ 7 スイッチ機能により、副作用のない・インターネット側仏 }) に設置したレイヤ 4 / 7 スイツなアイデアにもとづいて構築されている。単に復習しておこう。この WWW システムは、次のようこの構成については 2001 年 11 月号で紹介したが、簡になるだろう。バックエンド・システムテータベース用

7. UNIX MAGAZINE 2002年1月号

連載 /UNIX Communication Notes—O って、トランスポート層とアプリケーション層でのプロトコルに起因する遅延は、プロトコルそのものを変えないかぎり去宿できない。ただし、・カーネル内に実装されたプロトコル処理自体は、サーバーやクライアントの匪能に左右される。プロトコルの構造に起因する遅延の典型は、 TCP のウインドウフロー制御によって発生するものだろう。 TCP のパラメータ設定によって去噌できる可能性はあるが、根本的に解決するには、 TCP においてウインドウフロー制御の代わりにより性能の高い制御方式を導入するしかない。たとえは、 TCP Vegas[I] と呼はれる制御方式は、レート制御 (rate control) の概念を採り入れ、広帯域ネットワークにおける TCP の能を改善しようという試みである。この分野の研究は現在も活発に進められており、とくに、山も匠のネットワークの広或化に対応するさまざまな方式が考案されている。アプリケーション層での遅延を矢可宿するには、アプリケーションごとに対応するしかない。 HTTP であれは、 HTTP 1.1 てラ尊入された persistent connection や、データ転却芋の gzip 日引彡式の選択などが代表的な手法である。これらの改善手法は、アプリケーション・プロトコルごとに検言寸されている。一方、プロトコル処理そのものの遅延は、カーネルにおけるプロトコルの実装やシステムの性能に左右される。たとえは、 80486 DX2 66MHz を用いた PC UNIX サーーは、現在のシステムと上交して明らかにプロトコル処理か遅くなる。このような場合は、高速な CPU を使って処理速度を高めれは、カーネル内でのプロトコル処理にともなう遅延をまできる。しかし、山も匠のシステムでは CPU がポトルネックになっていることは少ないので、システムの単純なアップグレードによって性能か劇的に改善されるわけではない。これは、サーバーでの処理によってける遅延にも当てはまる。サーパーて、の里による過匡サーバーでの処理による遅延をいかに矢聾宿するかは、サーバーの友を考えるうえでもっとも重要な譏題である。サーバーにおける処理の性能改善を考えるうえで重要なのは、何がポトルネックとなっているかを把握することを一一 ~ これさえ分かれば、その要素を高性能なものに交 UNIX MAGAZINE 2002.1 換することでシステム性能の改善か図れる。 1 つのポトルネックを改善しても、今度は別の要素がポトルネックになることもある。このようなときは、ポトルネックを毆亦しながら性能を改善する作業が必要になる。単一のサーバーでは、次のような要素がポトルネックになりうる。最初に考えなけれはならないのは、ハードディスクとファイルシステムである。とくにハードディスクは要注意である。ハードディスクの性能は、ハードディスク自体とその上に実装されるファイルシステムの 2 つに分けて考える必要がある。前者については、たとえはディスク回転数の遅いドライプはディスクアクセスか遅く、性能力咄ない。とくに、ディスク I/O カ噸発する処理ではその傾向か顕著になる。実際、ラップトップ PC の内蔵ディスクは、デスクトップ PC のそれと上交して回転数が遅いのか通である。これを回転数の高いものに交換するだけで、性能か劇的に改善される場合がある。サーバーのような大規模なシステムであれば、前回説明した RAID 技術の導入により、アクセス性能の改善を図る場合が多い。一方、ファイルシステムについては、その構造によって処理のオーバーヘッドが変わるので、それぞれに性能が大きく異なる。たとえは、同し BSD FFS (Fast File Sys- tem) であっても、カーネル内の実装は OS ごとにかなり違う。そのため、 FreeBSD と NetBSD を上交した場合、前者の他のほうか圧倒的に性能がよい。また、異なるファイルシステムである FreeBSD の ffs と Linux の ext2fs では、一殳に後者のほうか高速である。このように、ファイルシステムの実装の違いによって性能が大きく変わることもある。このため、高性能サーバーを設計する場合は、とくにアプリケーションの特生や、使用する OS 上て利用可能なファイルシステムの機能を勘案し、どれを使うかを寸分に考える必喫がある。さらに、ファイルシステムには性能を左右するパラメータがあり、たいていはカーネルのコンパイル時のオプションでチューニングできる。この点についても、十分に検討すべきであろう。処珊生能を決める大きな要因の 1 つに CPU がある。最近の CPU はかなり高性能なうえに、続々と高速な CPU が発表されている。このため、数 - I ・年前のシステムならともかく、山も丘は CPU がポトルネックになることはあまりない。事実、クロックの高い CPU に交換しても、まったく性能が改善されない場合も少なくない。ただし、スト 57

8. UNIX MAGAZINE 2002年1月号

旧 v6 ヘッダ始点アドレス終点アドレス旧 v6 ヘッダ始点アドレス終点アドレス旧 v6 ヘッダ始点アドレス終点アドレス旧 v6 ヘッダ始点アドレス終点アドレス = 旧旧 v6 ヘッダ始点アドレス終点アドレスノード S ノードにノード旧ノード D 図 12 終点オプションヘッタ終点オプションヘッダ番号 : 60 = に連載 / 旧 v6 の実装ー 0 図 11 IPv6 ヘッダの終点アドレスの変化 = S = D = S = S = S = S = D 経路制御ヘッダ Segments Left = 3 Add ress[ 1 ] = Address[2] = に Address[3] = 13 経路制御ヘッダ Segments Left = 3 Address[1] = Address[2] = 13 Address[3] = D 経路制御ヘッダ Segments Left = 2 Address[1] = Address[2] = 旧 Address[3] = D 経路制御ヘッダ Segments Left = 1 Add ress[ 1 ] = Address[2] = に Address[3] = D 経路制御ヘッダ Segments Left = 0 Address[1] = Add ress[2] = に Add ress[3] = 旧 / ヾケット初期状態ノード S : 終点アドレスを経路制御ヘッダの末尾に追加し、最初の中継ノードを終点アドレスに設定して送信・・・・① ノー日 1 : 次の中継ノードのアドレスと現在の終点アドレスの値を入れ替え、 Segments Le 代を 1 減じて送信・・・② ノード 12 : 以下同様 Segments Le 負が 0 なので、自分宛の / ヾケットとして処理・ 3 Next Header 旧 d 「 Ext Len Options (variable) バケットは、 IPv6 ネットワークの糸各情報に従って ll へ酉占されます。 II は、バケットの終点アドレスとして自分自身カ甘旨定されているのでバケットの処理を始めますが、拡リ、ツダを処理している途中で、糸翻雅卩ヘッダが存在することを発見します。経路制笹いッダを処理した結果、 II は自分が最終的な宛先ではないことを認識します。そこで、 ll は次の中継ノード 12 と点での終点アドレス II を入れ替え、 Segments Left の値を減らしたあと、再度 IPv6 ネットワークへバケットを送信します ( 図 11 ー 2 ) 。以後同様に 12 、 13 でバケットか処理さ最終的にノード D に到達します。ノード D は Segments Left が 0 であることから自分か最終宛先であると認識し、通常 72 のバケット処理をおこないます ( 図 11 ー 3 ) 。終点オプションヘッダ UNIX MAGAZINE 2002.1 ダは、糸各制御ヘッダに指定された各中継ノードと最糸勺ります。経各制御ヘッダよりも前の終点オプションヘッヘッダの前、暗号化へッダの後ろ ) に出現する可能性があプションヘッダは IPv6 バケット中で 2 カ所 ( 糸各制御刻、ツダの推奨国のところで説明したように、終点オ tions の形式も中点オプションヘッダの場合と同様です。形式的には中継点オプションヘッダと同しです。 Op- プションかオ褓内されます ( 図 12 ) 。ケットの終点アドレスに指定されたノードて処理されるオ終点オプションヘッダは才比、ツダの 1 つで、 IPv6 パ

9. UNIX MAGAZINE 2002年1月号

プログラミング・テクニックしかし、接続するのが echo サーバーではない、つまり複数の入力行を読み込んでから数行ぶんの応答をまとめて返すサーバーの場合、このプログラムでは対応することができません。どの程度の入力をサーバーに送れは応答が返ってくるかカ吩からないため、標準入力からの入力を読み込みつつ、それをサ→ヾーに送る必要があります。さらに、サーバーからの返答を監視しなければなりません。そのためにおこなうのか非期の入出力てす。・ファイル言当子の複製・ close-on-exec フラグの取彳等と疋・ステータスフラグの取得と設定・入出力関連シグナルの受信プロセスの取得と設定・レコードロックの取得と解除があります。非プロッキング入出力は、ステータスフラグて蒲衂されています。実際の処理は次のようになります。 fcntl(fd, F—GETFL, 0 ) ) perror("fcntl") ; exit(l); if (fcntl (fd, F—SETFL , f ー O—NONBLOCK) perror("fcntl") ; exit(l); if ( (f = 非プロッキング入出力ます、実際に入出力をおこなっている process 関数が呼び出される状況と、この関数の重川乍について石忍しておきましよう。ます、 fcntl に対して F-GETFL コマンドを実行し、この関数か呼び出されるときには、 TCP を利用していファイル・ディスクリプタの現在のステータスフラグを取る場合はすでに接続か確立した TCP のソケットが引数得します。続いて、 F-SETFL コマンドによりステータとして渡されます。 UDP の場合には、接続という念はスフラグを設定します。このとき引数として、最初に取得ありませんが、バケットの送出先があらかじノ旨定されたしたフラグの値と非プロッキング入出力を示す O-NON- 状態て呼び出されます。つまり、いすれも read や write BLOCK とのビットごとの論理和をとった値を指定しまなどのシステムコールを使ってデータを読み書きできるよす。この処理により、もとのステータスフラグから非プロうになっています。ただし、相手側とのやりとりのなかッキング入出力のフラグのみを変更したものを設定するこで、ネットワークからの入力と標準入力の両方を順番に読とかできます。値を取得迂すに O-NONBLOCK だけをみ書きしていては正しく重川乍しなくなってしまいます。そ引数として F-SETFL を実行すると、ほかのフラグか設こで、ネットワークからの入力でも標準入力でも、言も囚み定されていた場合にこれらがクリアされてしまいます。上か可能になった段階で読み込んで対応する出力先に出力し己の処理は、このような問題を避けるための工夫です。ようとします。上に示したコードでは fd を非プロッキング入出力に設言ムみが可能かどうかを調べるのは、ネットワークや標定しました。次に、標準入力についても非プロッキング入準入力から読み込むべきデータがない場合にプロセスカワ・出力の設定をしたあと、サンプル・プログラムのような入ロック ( 入力待ちで停止 ) してしまうからです。逆にいえ出力に関するループを実行すればよいのですが、ループのば、プロックさえしなければいつ読み込んでもかまわない内部をすこし変更する必要があります。非プロッキング入はすです。そのためには、 fcntl システムコールを使って、出力をおこなうファイル・ディスクリプタは、読み出すファイル・ディスクリプタか非プロッキング入出力をおデータがないか書き込む準備ができていない場合にエラーこなうように設定します。を返し、 errno を EAGAIN に設定するためです。これ fcntl システムコールは次のような形式でイ吏います。は実際にエラーが発生したわけではなく、一日勺に実行で fcntl ()d , command, arg) きないことを表すのですから、エラーを無視しなけれはなりません。そのためのコードは次のようになります。 fd には処理の対象となるファイル・ディスクリプタを、 command にはおこないたい処理を表すマクロを指定しま for ( ; / * 端末から入力 * / す。さらに処理に対する引数を arg に指定します。 if ((len = read(), buf , BUFSIZ)) く 0 ) { if (errno ! = EAGAIN) { fcntl で可能な処理としては、 perror("read") ; 1 三ロ 77 UNIX MAGAZINE 2002.1

10. UNIX MAGAZINE 2002年1月号

連載 / lPv6 の実装ー 0 図 4 中点オプションヘッダオプションヘッダ番号 : 0 Next Header Hdr Ext Len Options (variable) 1. 中点オプションヘッダ 2. 終点オプションヘッダ 1 3. 糸各制御ヘッダ 4. 断片ヘッダ 6. 暗号化へッダ 7. 終点オプションヘッダ 2 注目すべき点は、終点オプションヘッダが 2 回登場していることです。最初の終点オプションヘッダは、経路缶雅卩ヘッダよりも前に配置されます。この位置の終点オプションヘッダは、 IPv6 ヘッダて指定された最終的な終点ノードに加え、糸各制徊ヘッダて指定された各中継ノードでも処理されます。 2 つ目の終点オプションヘッダは、暗号化へッダより後ろに配置されます。この位置にある終点オプションヘッダは、終点ノードにおいてのみ処理されます。さらに、必要であれ ( 部号化へッダを用いて隠蔽することもできます。中系点オプションヘッダには、 IPv6 バケットを転送する中継ノード ( ルータ ) で処理されるオプションかオ褓内されます。このヘッダの形式を図 4 に示します。 Next Header には、次に続く刻に、ツダ番号か上イ立層プロトコル番号が入ります。 Hdr Ext Len には、中点オプションヘッダ本のオクテット数を 8 て割った値から 1 を引いたものかオ絲タされます。たとえば、 Hdr Ext Len の値が 0 の場合には中点オプションヘッダの全長は 8 オクテット、 1 であ川ま 16 オクテットとなります。中継点オプション、終点オプションの書式中点オプションヘッダと終点オプションヘッダには、一一一一一一一一さまざまなオプシーヨンかオ絲タされます。これらのオプショ中継点オプションヘッタ UNIX MAGAZINE 2002.1 ンは、オプション型、オプションの長さ、オフションの値のいわゆる TLV (Type 、 Length 、 Value) 形式で指定します。オフションの形式を図 5 に示します。 Option Type はオプションの不鶤頁を示す値で、各オプションごとに固有の値をもっています。 Opt Data Len では、 Option Data の長さ ( 単位はオクテット ) を指定します。 Opt Data Len には、 Option Type と Opt Data Len 自身の長さは含まれないので注意が必要です。 Option Type の上位 3 ピットには特別な意味があります。ます、先頭 2 ピットで、不明なオプションの処理ガ去を決定します。 IPv6 ノードは、オプションの処理中に未知のオプション型を発見した場合、以下の規則に従って処理を進めます。 00 : このオプションを無見し、以後の処理を続ける。 01 : バケットを破棄する。 10 : このオプションを含む IPv6 バケットの始点アドレスに対して、不明なオプションを示す ICMP ェラーをする。 11 : このオプションを含む IPv6?S ケットの終点アドレスがマルチキャスト・アドレスでない場合に限り、始占アドレスに向けて不明なオプションを示す ICMP ェラーを返送する。 3 ビット目では、オプションの値カ云送中に変更されるかどうかを指定します。 0 : オプションの値は転送中に変更されない。 1 : オプションの値は転送中に変更される場合がある。バケットの改竄を防ぐために認証ヘッダなどを用いている場合、転送中 : ンヾケットのオプション部分か変更されると、終点ノードがバケットを石忍したときにエラーになってしまいます。したがって、変更される可能生のあるオフションについては、事前に指定しておかなければなりません。 69