SOCKS(RFC1928) とはさまざまなアプリケーションが間にファイアーウォールを挟んでいても安全に快適にやり取りができるようにすることを目的として作られたプロトコルのことで、SOCKSプロキシはSOCKSプロトコルを受け取りファイアウォール内外との接続を可能にします。 これに関してはIPAのコンテンツに図付きの解りやすい説明があります。参考までに > SOCKS

ちなみにSOCKSプロキシの利点はSOCKS対応のアプリケーションであればSOCKSプロキシ経由でLAN内部のサーバにアクセスが可能なことで、例えばSOCKS対応ブラウザであればSOCKSプロキシ経由でLAN内のコンテンツが閲覧できます。自分はこのSOCKSプロキシ経由でのLAN内ドキュメントのブラウジングは多用してます。

SOCKSプロキシの作成

まずはSOCKSプロキシの立ち上げです。OpenSSHのダイナミックポートフォワード機能を使います。

ダイナミックポートフォワードはsshをSOCKSプロキシとして振舞うことを可能にします。sshでアクセス先ホストと DynamicFoward(-D)でポートを指定することでlocalhostにSOCKSプロキシが立ち上がり指定のTCPポート(SOCKSプロキシサーバは基本的は1080ですが、割り当て可能なポートであればどのポートでもOK)をlocalhost側からログイン先ホストのSSHサーバに転送することができるようになります。もちろん経路は暗号化され、現状のサポートプロトコルはSOCKS4とSOCKS5です。
例えばJumpサーバにDynamicFoward(-D)1080でログインすると、Jumpサーバにポート1080を転送するSOCKSプロキシが localhostに立ち上がり、そのlocalhost:1080に対してSOCKS4またはSOCKS5プロトコルで接続することでJumpサーバを経由して通信を行うことができます。

localhost ポート1080のJumpサーバへのダイナミックフォワードは次のように-Dオプションで行います。

毎回-Dオプション指定が面倒な場合は次のようにconfg(ssh_config)にDynamicForwardの記述しておきましょう。

SOCKSプロキシを使ったSSH接続

次に上で事前に作成したSOCKSプロキシを使ってLAN内のサーバにSSH接続をします。 netcatでSOCKSプロキシを経由してlocalhostから目的のＬＡＮ内サーバ（ServerB）間にnetcat tunnelを作成します。ServerBにはそのnetcat tunnelを通じて接続します。

netcat のプロキシ指定は-xオプションで行います。 ここでは事前に作成したSOCKSプロキシ(localhost:1080)を指定。 netcat tunnelの作成コマンドはおなじみProxyCommandに記述します。こちらも毎回長いオプション入力を避けるために config（ssh_config）設定をしましょう。

注意点
netcatにはGNU本家版とそれ以外にいくつか派生がありますが -x オプションの利用可能なnetcatをインストールしてください。オリジナルのnetcatやGNU netcatには-xオプションはありません。ここで使用しているnetcatはIPv6に対応しているOpenBSD netcatです。

SOCKSプロキシを経由しないでSSH接続

別解としてProxyCommandでJumpからBのnetcat tunnelを作成してServerＡからServerＢにログインする方法があります。詳しくは「DSAS開発者の部屋:OpenSSH クライアントの proxy — 踏み台サーバを経由しての ssh」を参考にしてもらうとしてここでは次のようにログインすることができます。

ProxyCommand でプロキシ設定を行うため事前に別コンソールで何かを用意する必要がなく間違いなく楽。それと比べて事前にSOCKSプロキシを立てる必要がある SOCKSプロキシ経由のログインは面倒です。ではどうしてこんな設定を選んだのか？ 理由は単純で、当初は楽な方法で行く予定でいたものの、結局Jumpサーバがnetcatが使えない(ncはおろかsshコマンド以外ほとんど何も使えない)環境だったからです。そこでいくつか調べて行き着いたのがこのSOCKSプロキシ経由でのSSHログインだったというわけです。まさに苦肉の策。でも回り道した分少しだけOpenSSHに詳しくなりました。

おわり。

通常N個のリクエストを処理する際はN個ソケットがオープンされOPEN → REQUEST → RESPONSE → CLOSEなサイクルがN回行われる。Multiインターフェースによる並列処理の場合はOPEN → REQUEST → RESPONSE → CLOSEが並列に行われる。 またこれがkeep-aliveな接続であればOPEN → (REQUEST → RESPONSE) x N → CLOSEのようにクローズされるまで１ソケットが再利用される。 そしてHTTP Pipeliningはkeep-aliveな接続で使うテクニックであり、これが有効な場合は1ソケットオープン後にOPEN → (REQUEST x N) → (RESPONSE x N) → CLOSEのようにリクエストN個をレスポンスを待つことなく1ソケットに書き込むことができる。 まとめて送信される分パケット効率がアップし全体的なネットワークを流れるパケットの数を減らすことができ、 さらにまとめてリクエスト送信するので高レイテンシーなネットワークにおいては速度面で効果的といえる。 see also 「Mozilla HTTP/1.1 パイプライン化 FAQ」。

というわけでいつものようにテストプログラムを作ってMultiインターフェースによる並列処理をHTTP Pipeliningありとなしで実行してみる。
(環境 libcurl-7.19.5、httpd-2.2.2 on Debian-5.0.1 )

テストツールとそのコンパイル

cURL CAPIのMultiインターフェースを使って複数URLからfetchしてくるツールを作成した。

http://github.com/yokawasa/any/blob/master/libcurl/multi_fetch.cpp

標準的なcurl Multiインターフェースを使ったコードであるがポイントは次の部分。各リクエスト用のCURLハンドルでソケットの送信待ち時間を最小限にするCURLOPT_TCP_NODELAYオプション（詳しくは「Linuxにおけるソケット機能の向上」を参照ください）と挙動把握のためにlibcurlのINFO情報を出力するCURLOPT_VERBOSEオプションを有効にしている。またHTTP Pipeliningモード指定のときにMulti用ハンドルでCURLMOPT_PIPELININGオプションを有効にしている。　以下該当箇所のコード断片。

上記URLのソースコードを取得して次のようにコンパイルを行う。

使い方は次のように複数URLの書かれたファイルを指定する。-pオプションを加えてやることでHTTP Pipeliningモードでリクエスト送信を行う。 これはオプショナル。

NON HTTP Pipelining リクエスト送信

テスト用にホストfooとWebサーバ（apache）のあるホストbarを用意する。まずはHTTP Pipeliningオプションをはずした通常のmultiインターフェースによる並列実行を行う。リクエスト用CURLハンドルでCURLOPT_VERBOSEオプションが有効になっているので実行結果にlibcurlのINFO 情報も一緒に出力される。出力内容を全てここに貼り付けるには量が多すぎるので内容を簡略化してHTTP接続部分と各リクエストとそのレスポンスの最初の一行だけに絞る。

これを見ると並列にConnection #[0-3]の4つのソケットがオープンしてそれぞれにリクエスト、レスポンスが書き出され終了していることが分かる。 「(2)NOT keep-alive, multi」のパターンになっているといえる。想定どおり。

HTTP Pipeliningリクエスト送信

次に前テストと同様にホストfooからホストbar(Webサーバ)の4ファイル対してにHTTP Pipeliningなリクエストを送信してみる。

出力結果から、1つのソケットオープン(Connection #0)後に他のリクエスト達はConnectoin#0を 再利用しているのが分かる。 またtest1.htmlをGETするためのリクエスト送信後に「HTTP/1.1 200 OK….」とレスポンスを受け、次にtest2.html～test4.html GETの3リクエストがレスポンスを待つことなく連続で送られ、その後それらのレスポンスを受けている。 「(4) keep-alive, Pipelining」のパターンになると予想していたのだが１つ目のリクエスト（REQUEST-a）だけがPipeliningではない。 試しにリクエスト数を増やしてみても同じ、１つ目のリクエストがPipeliningではなく、2番目以降のリクエストはPipeliningになっている。 今一理由がわからない。 ひょっとして実際の処理とは別にログ出力に問題があるのではないかと思いtcpdumpで実際のTCPパケットのやりとり確認してみる。

tcpdumpの結果も変わらず同じ。 ログを見る限りオープン処理（SYNフラグの出力部分、いわゆる3way handshake）が行われた後、１つ目のリクエスト直後にレスポンスを受け、その後2番目以降のリクエストはレスポンスを待つことなくソケット書き込み、つまりPipeliningリクエスト送受信が行われている。　どうして１つ目だけがダメで、２つ目以降からうまくいくのだろう？？ (T . T)

細かくlibcurlのコードを追えばよいのだろうがこれ以上調査する気持ちにならないので取り敢えずここで終えておく。 続きはいつか。

おわり。