通常、ソケット・アプリケーションを開発する際にまず必要となる作業は、ネットワーク環境の信頼性を確立し、必要な条件を整えることです。この記事で紹介する 4つのヒントを実行すれば、最適なソケット・アプリケーションを最初から設計・開発することができます。この記事では、ソケット API の使用法、アプリケーションの機能を拡張するソケット・オプション、ならびに GNU/Linux の調整方法について紹介します。

効率的なアプリケーションを開発するには、以下の 4つのヒントを実行します。

• パケット送信の待ち時間を最小限にする
• システム・コールのオーバーヘッドを最小限にする
• 帯域幅遅延積に対して TCP ウィンドウを調整する
• GNU/Linux の TCP/IP スタックを動的に調整する

ヒント 1. パケット送信の待ち時間を最小限にする

TCP ソケットを使用して通信する場合、やり取りされるデータはブロック単位に分割され、通信用の TCP ペイロードに格納されます。TCP ペイロードのサイズはいくつかの要因 (パスに応じた最大パケット・サイズなど) によって決定されますが、通信が開始されるまでこれらの要因を特定することはできません。最高の性能を実現するには、それぞれのパケットにできるだけ多くの使用可能データを格納することが必要です。ペイロード内に十分なデータがない場合 (ペイロードのサイズが最大セグメント・サイズ (MSS) になります)、TCP は Nagle アルゴリズムにより、複数の小さなバッファーを自動的に連結して 1つのセグメントを作成します。これにより、アプリケーションの処理効率を上げ、小さなパケットの送信数を最小限に抑えてネットワーク全体の混雑を緩和します。

John Nagle が開発したこのアルゴリズムは、小さなパケットを連結してパケット数を最小限に抑える場合には有効ですが、単純に小さなパケットをそのまま送信したい場合もあるでしょう。たとえば Telnet のアプリケーションは、シェルを介してリモート・システムにアクセスできます。これが、パケットを送信する前に文字データを入力してセグメントに格納しなければならないとしたら、使いやすいアプリケーションとはいえないでしょう。

HTTP プロトコルの場合も、クライアント・ブラウザから HTTP 要求メッセージなどの簡単な要求を入力すると、Web サーバーから Web ページなどの複雑な結果が返ってくるのが通常です。

解決策

まず覚えておかなければならないのは、Nagle アルゴリズムは有効であるということです。TCP パケット・セグメントの容量いっぱいにデータを格納しようとするため、パケットの送信までにはどうしても待ち時間が発生してしまいますが、ネットワーク上でのパケット送信数を最小限に抑えるという利点があり、結果的にネットワーク全体の混雑を緩和することができます。

しかし、この送信待ち時間を最小限にしたい場合には、ソケット API を使用するのが有効です。Nagle アルゴリズムを無効にするには、リスト 1 のようにソケット・オプションの TCP_NODELAY を設定します。

int sock, flag, ret;

/* Create new stream socket */
sock = socket( AF_INET, SOCK_STREAM, 0 );

/* Disable the Nagle (TCP No Delay) algorithm */
flag = 1;
ret = setsockopt( sock, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(flag) );

if (ret == -1) {
  printf("Couldn't setsockopt(TCP_NODELAY)\n");
  exit( EXIT_FAILURE );
}

参考: Samba を使用してテストしたところ、Nagle アルゴリズムを無効にした場合、Microsoft Windows サーバー上の Samba ドライブからのデータ読み込み速度がほぼ 2倍に上がることがわかりました。

上に戻る

ヒント 2. システム・コールのオーバーヘッドを最小限にする

ソケットのデータを読み込んだり書き込んだりする際には常にシステム・コールが呼び出されています。読み込みや書き込みといったコールは、ユーザーが使用するアプリケーション領域を超えてカーネルにまで到達します。カーネルに到達する前に、コールは C ライブラリを通ってカーネルの共通機能 (system call()) に送られます。次に、コールは system call() からファイルシステム層に送られ、ユーザーが使用しているデバイスの種類がカーネルによって判断されます。最後に、コールはソケット層に送られ、ここでデータが読み込まれたり、送信用やデータのコピー用としてソケット上の待ち行列に入れられたりします。

このプロセスから、システム・コールはアプリケーション領域やカーネル領域だけでなく、各領域のさまざまな階層で機能していることがわかります。このプロセスは複雑であるため、システム・コールの数が増えるほどコールの処理にかかる時間も長くなり、その結果、アプリケーションの処理能力も下がってしまいます。

システム・コールをなくすことはできないため、残された選択肢はシステム・コールの回数を最小限に抑えることになります。これを制御する方法を以下に説明します。

解決策

ソケットにデータを書き込む際には、データの書き込みを複数回に分けるのではなく、書き込み可能なデータをすべて同じタイミングで書き込むようにします。データを読み込む際には、できるだけ大きなバッファーに読み込むようにします。これは、十分な読み込みデータがある場合、カーネルは TCP の告知ウィンドウを開いたまま、バッファーをデータでいっぱいにしようとするためです。こうすることにより、システム・コールの回数を最小限にし、アプリケーション全体の性能を高めることができます。

上に戻る

ヒント 3. 帯域幅遅延積に対して TCP ウィンドウを調整する

TCP の性能は、いくつかの要因によって変わってきます。もっとも重要な要因は、リンク帯域幅 (ネットワーク上でパケットが送信されるレート) と往復遅延時間 (セグメントが送信されてから、相手の確認応答が戻ってくるまでの遅延時間。RTT ともいう) の 2つです。この 2つの値によって、帯域幅遅延積 (BDP) と呼ばれる値が決定されます。

リンク帯域幅の割合と RTT がわかれば BDP を算出することができますが、実際には何に使用するのでしょうか。BDP を使用すると、TCP ソケット・バッファーの理論上の最適サイズを簡単に算出できることがわかっています (このバッファーには、送信待ちと複製待ちの両方のデータが入ります)。バッファーのサイズが小さすぎる場合、TCP ウィンドウが完全には開かず、アプリケーションの機能が制限されてしまいます。逆にサイズが大きすぎる場合は、貴重なメモリーのリソースが無駄に消費されてしまいます。バッファーを最適なサイズに設定することにより、使用可能な帯域幅を最大限に活用することができます。以下に例を示します。

BDP ＝ リンク帯域幅 × RTT

50ミリ秒の RTT で 100MBps を超える速度の LAN 環境でアプリケーションが通信する場合、BDP は以下のようになります。

100MBps * 0.050 sec / 8 = 0.625MB = 625KB

100MBps × 0.050秒 ÷ 8 ＝ 625KB

注: ビットをバイトに変換するため、8 で割っています。

ここで TCP ウィンドウのサイズをこの BDP 値 (625KB) に設定するわけですが、Linux 2.6 での TCP ウィンドウのデフォルト・サイズは 110KB であるため、接続に使用される帯域幅は以下に示すように 2.2MBps に制限されてしまいます。

スループット ＝ ウィンドウのサイズ ÷ RTT

110KB / 0.050 = 2.2MBps

110KB ÷ 0.050 ＝ 2.2MBps

この値の代わりに上で算出した 625KB というウィンドウ・サイズを使用した場合、以下のように 12.5MBps という非常に大きなスループットを得ることができます。

625KB / 0.050 = 31.25MBps

625KB ÷ 0.050 ＝ 12.5MBps

これは非常に大きな違いで、ソケットのスループットが劇的に大きくなります。これでソケットの最適なバッファー・サイズの算出方法がわかりました。では、どうすればこのように変更できるでしょうか。

解決策

ソケット API にはいくつかのオプションがありますが、そのうちの 2つのオプションを使用して、ソケットが送受信に使用するバッファーのサイズを変更することができます。リスト 2 では、SO_SNDBUF オプションと SO_RCVBUF オプションを使用して、ソケットが送受信に使用するバッファーのサイズを変更する方法を示しています。

注: ソケットのバッファー・サイズによって TCP の告知ウィンドウのサイズが決まりますが、告知ウィンドウ内には輻輳 (ふくそう) ウィンドウも配置されるため、ネットワークの混み具合によっては、特定のソケットが最大サイズの告知ウィンドウを使用できない場合があります。

int ret, sock, sock_buf_size;

sock = socket( AF_INET, SOCK_STREAM, 0 );

sock_buf_size = BDP;

ret = setsockopt( sock, SOL_SOCKET, SO_SNDBUF,
                   (char *)&sock_buf_size, sizeof(sock_buf_size) );

ret = setsockopt( sock, SOL_SOCKET, SO_RCVBUF,
                   (char *)&sock_buf_size, sizeof(sock_buf_size) );

Linux 2.6 のカーネルにおいては、送信用バッファー用のウィンドウのサイズにはユーザーが setsockopt コールで定義したサイズが使用されますが、受信用バッファーのサイズには自動的にその倍の値が設定されます。getsockopt コールを使用して、それぞれのバッファー・サイズを確認することができます。

ウィンドウ・スケーリングについてですが、当初 TCP は最大 64KB のウィンドウをサポートしていました (16ビット値がウィンドウ・サイズの定義に使用されていました)。ウィンドウ・スケーリング・オプション (RFC 1323) を組み込むことにより、ウィンドウ・サイズの定義に 32ビット値を使用できるようになりました。このオプションは、GNU/Linux で提供されている TCP/IP スタックでサポートされています (この他にも多くのオプションがサポートされています)。

参考: Linux のカーネルにはこうしたソケットのバッファーを自動的に調整する機能も含まれていますが (下に示した表 1 の tcp_rmem および tcp_wmem を参照)、これらのオプションを使用すると、スタック全体に影響を与えることになります。1つの接続のみ、または 1種類の接続のみに対してウィンドウを調整する必要がある場合にこの機能を使用すると便利です。

上に戻る

ヒント 4. GNU/Linux の TCP/IP スタックを動的に調整する

標準的な GNU/Linux 配布パッケージは、さまざまなアプリケーションを最適化の対象としています。そのため、システムの環境によっては、標準配布パッケージがその環境では最適でない場合があります。

解決策

GNU/Linux にはユーザーが変更することができるさまざまなカーネル・パラメータがあります。このパラメータを使用し、特定の目的にあわせてオペレーティング・システムを動的に設定することができます。ソケットの性能に影響を与える重要なオプションをいくつか見てみましょう。

変更可能なカーネル・パラメータは、/proc 仮想ファイルシステム内に存在しています。このファイルシステム内の各ファイルが 1つまたは複数のカーネル・パラメータにあたり、cat ユーティリティを介して読み込んだり、echo コマンドを使用して変更したりすることができます。リスト 3 では、変更可能なパラメータをクエリーする方法と有効にする方法を示しています (この例の場合、TCP/IP スタック内で IP フォワーディングを有効にする方法を示しています)。

[root@camus]# cat /proc/sys/net/ipv4/ip_forward
0
[root@camus]# echo "1" > /proc/sys/net/ipv4/ip_forward
[root@camus]# cat /proc/sys/net/ipv4/ip_forward
1
[root@camus]#

表 1 は、Linux TCP/IP スタックの性能を向上させる変更可能なパラメータ (一部) の一覧です。

他の設定を調整する場合にも同じことが言えますが、パラメータの調整で一番大事なことは、いろいろな設定で試してみるということです。アプリケーションの動作、プロセッサの速度、メモリーの使用率によって、これらのパラメータがシステムの性能をどう変えるかが決まります。システムの性能を上げるつもりが、逆に下げてしまう場合があるかもしれません (またはその逆の場合もあるかもしれません)。ですから、オプションを 1つずつ実行し、その結果を確認するのが一番確実な方法です。この表を基にして検証を重ねてください。

参考: パラメータの保存方法について説明します。設定を変更したカーネル・パラメータは、GNU/Linux システムを再起動すると元のデフォルト値に戻ってしまうことに注意してください。変更したパラメータをデフォルト値として設定する場合、/etc/sysctl.conf ファイルを使用してシステムの起動時にカーネル・パラメータを設定してください。

上に戻る

GNU/Linux ツール

GNU/Linux には便利なツールが数多くあります。コマンドライン・ツールが圧倒的に多いのですが、これは非常に便利でわかりやすいツールです。ネットワーク・アプリケーションのデバッグ・ツール、帯域幅/スループットの測定ツール、リンク稼働率のチェック・ツールなどがあります。これらのツールは、ネイティブ環境またはオープン・ソース環境で実行します。

表 2 は、最も便利な GNU/Linux ツールとその使用目的についての一覧です。表 3 は、GNU/Linux 配布パッケージには通常含まれない便利なツールの一覧です。この表のツールの詳細については、「参考文献」のセクションを参照してください。

上に戻る

まとめ

この記事では、ソケット・アプリケーションの性能を高めるヒントとテクニックについて見てきました。Nagle アルゴリズムを無効にして転送待ち時間を最小限にする方法、バッファー・サイズを変更してソケットの帯域幅の稼働率を上げる方法、システム・コールの数を少なくしてシステム・コールのオーバーヘッドを減らす方法、カーネル・パラメータを変更して Linux TCP/IP スタックを調整する方法などを実際に試してみてください。

アプリケーションの設定を調整する場合、常にそのアプリケーションの性質を考慮しなければなりません。たとえば、そのアプリケーションは LAN 環境で稼働するのか、あるいはインターネットを介して稼働するのか、といったことを考慮する必要があります。LAN 環境だけで稼働するアプリケーションの場合、ソケットのバッファー・サイズを大きくしてもあまり効果は期待できませんが、ジャンボ・フレームを有効にした場合は高い効果が得られるはずです。

最後になりましたが、設定を調整した場合は、tcpdump や Ethereal といったツールを使用して必ず結果を確認してください。調整の結果をパケットのレベルで確認することにより、ここで紹介したテクニックをどのように応用すればよいのかがわかってくるはずです。

参考文献

学ぶために

• 2回シリーズのチュートリアル、「Programming Linux sockets」 (developerWorks, 2003年 10月と2004年 1月) は、ソケット・アプリケーションを書くために役立つでしょう。
  
  
• 他にも、Pittsburgh Supercomputing Center が、TCP に有利な輻輳制御アルゴリズムを紹介しています、
  
  
• MTU を増加することによって、パフォーマンスを大幅に改善することができます。ジャンボ・フレームと、その利点について学んでください。
  
  
• ICSI Center for Internet Research による、肯定応答に関する資料を読んでください。
  
  
• TCP Westwood home page を見て、TCP Westwoodアルゴリズムの詳細を学んでください。
  
  
• North Carolina State University による、Binary Increase Congestion TCP について調べてください。
  
  
• trafshow ユーティリティーは、IP 通信のトラフィック監視に便利です。
  
  
• developerWorks Linux ゾーンには、Linux 開発者のための資料が他にも豊富に用意されています。
  
  
• developerWorks technical events and Webcasts を利用して、最新技術を学んでください。
  
  

製品や技術を入手するために

• Ethereal は、プロトコル構文解析用のプラグイン・アーキテクチャーを持った、グラフィカルなネットワーク・プロトコル・アナライザーです。
  
  
• National Laboratory for Applied Network Research で、Iperf tool について学んでください。
  
  
• developerWorks から直接ダウンロードできる IBM ソフトウェア試用版を使って、皆さんの次期 Linux 開発プロジェクトを革新してください。
  
  

議論するために

• developerWorks blogs を見てください。そして developerWorks のコミュニティーに加わってください。
  
  

著者について

M. Tim Jones は、埋め込みソフトウェアのエンジニアであり、GNU/Linux Application Programming, AI Application Programming と BSD Sockets Programming from a Multilanguage Perspective の著者でもあります。エンジニアとして経歴は幅広く、静止衛星用のカーネル開発から埋め込みシステム・アーキテクチャー、そしてネットワーク・プロトコル開発まで経験しています。現在は Emulex Corp. のシニア主席エンジニアです。

この記事を評価する

コメント

上に戻る

目次

• ヒント 1. パケット送信の待ち時間を最小限にする
• ヒント 2. システム・コールのオーバーヘッドを最小限にする
• ヒント 3. 帯域幅遅延積に対して TCP ウィンドウを調整する
• ヒント 4. GNU/Linux の TCP/IP スタックを動的に調整する
• GNU/Linux ツール
• まとめ
• 参考文献
• 著者について
• コメント