Wireshark 25周年：すべての始まりとなったメールと、そこから得た教訓
(blog.wireshark.org)- Gerald Combsが1998年7月14日に Ethereal 0.2.0 の公開メールを送ったことが、25年後のWiresharkへとつながり、個人用ツールが長寿のオープンソースプロジェクトへと成長した
- 当時のGUIプロトコルアナライザーは 高価な商用製品 に近く、無料の選択肢はtcpdumpやsnoopのようなコマンドラインツールだったため、自作したアナライザーをオープンソースとして公開した
- 公開から数日後にはパッチが届き始め、開発者コミュニティが形成され、Wiresharkはネットワークの 性能・信頼性・セキュリティ 改善や教育に使われるようになった
- 長期運営には、ユーザー、教育者、開発者だけでなく、法務・会計やインフラ支援まで必要であり、プロジェクトの規模によって必要な支援範囲は変わる
- CACE Technology、Riverbed、Sysdigの支援を受けてきたWiresharkは、最近 Wireshark Foundation へ移管され、独立して成長するための基盤を整えた
Etherealの公開からWireshark 25周年まで
- Gerald Combsは25年前、
ANNOUNCE: Ethereal 0.2.0という件名のメールを送った- Etherealは、Ethernetフレームの内容をキャプチャし、インタラクティブに探索できる ネットワークアナライザー だった
- パケットデータはファイルから読み込むことも、ローカルネットワークインターフェイスからリアルタイムで読み込むこともできた
- ソース配布版と追加情報を提供し、意見やパッチを歓迎すると案内した
- プロジェクト名は最初からWiresharkだったわけではなく、2006年 にWiresharkへ変更された
- 公開当時、プロトコルアナライザーは珍しく、GUIアナライザーは高価な製品であることが多かった
- ネットワークの状況を確認するには、tcpdumpやsnoopのような無料のコマンドラインツールを使うことができた
- GUIアナライザーが必要なら、高価な商用製品を購入する必要があった
- 業務に必要なアナライザーがなかったGerald Combsは、簡単なツールを自作し、それを オープンソース として公開した
コミュニティが生んだ成長
- Ethereal公開から数日後、最初の パッチ が届き、その後も貢献は続いた
- 小さなツールとして始まったプロジェクトは、活発な開発者コミュニティと出会い、予想をはるかに超えて大きく成長した
- Wiresharkは現在、世界中のユーザーによって、ネットワークをより高速で、安定し、安全なものにするために活用されている
- 教育者たちはWiresharkを使い、次世代の セキュリティおよびネットワークエンジニア にネットワークの低レベルな動作を教えている
長く続くオープンソースプロジェクトに必要なもの
- オープンソースプロジェクトが成長し、持続するには、複数の種類のニーズを同時に満たす必要がある
-
ユーザー支援
- 実際のユーザーは、熟練した日常利用者から初心者までさまざまだ
- ユーザーは時に助けを必要とし、必要な支援もそれぞれ異なる
-
教育者支援
- 専門家や熟練ユーザーは、他の人がプロジェクトをよりうまく活用できるよう教えることができる
- 教育者にも継続的な支援が必要だ
-
開発者支援
- コードを貢献したりプロジェクトを改善したりしやすいほど、プロジェクトとコミュニティは健全になる
-
法務・会計支援
- 知的財産権法、出張費精算のような規制・法務・財務領域では外部の助けが必要になる
- GitHubやGitLabだけでは、こうした領域は解決できない
-
インフラ
- オンラインでの存在感と協働を可能にするサーバー、コンテナ、サービスが必要だ
- GitHubやGitLabで十分かどうかは、プロジェクトの具体的なニーズによって変わる
プロジェクト規模によって変わる支援構造
- この5つのカテゴリーは、オープンソース版のマズロー的欲求段階と完全に同じではないが、似た構造を持っている
- ユーザー、教育者、開発者の境界はあいまいな場合がある
- 一般に、ユーザーと教育者は開発者が作った成果物に依存する
- プロジェクト全体には、全員が協働できる 堅牢なインフラ が必要だ
- すべてのプロジェクトに同じ支援モデルが必要なわけではない
- 小規模で単一目的の画像処理ライブラリなら、インフラと開発者だけで足りるかもしれない
- この場合、ユーザーコミュニティも他の開発者である可能性が高く、GitHubやGitLabで十分かもしれない
- 機能の多い大規模な画像編集アプリケーションでは、5つのカテゴリー全般のニーズと、それを支える ビジネスモデル が必要になるかもしれない
Wiresharkの運営モデルとFoundationへの移管
- Wiresharkは大規模アプリケーションに近いプロジェクトであり、多くの管理と支援を必要とする
- 最近まで、必要なリソースはGerald Combsの雇用主にプロジェクトのホスティングを依頼する形で確保していた
- CACE Technology、Riverbed、Sysdigは、GitHubやGitLabを超えるリソースをWiresharkに提供した
- 例として、プロトコル解析専門カンファレンスである SharkFest がある
- ここ数年で、プロジェクトが自立する必要性が高まり、Sysdigの助けを受けて今年初めに Wireshark Foundation へ移管された
- Foundationへの移管は、Wiresharkが成長を続け、コミュニティを支援するための基盤となった
25年後に残った助言
- Gerald Combsは25年前にメールを送った当時、今このプロジェクトについてブログを書くことになるとは思っていなかった
- Wiresharkを支援し管理してきた経験は、素晴らしいキャリアと、優れた人々に出会い共に働く機会をもたらした
- オープンソースプロジェクトを始めたいなら、ためらわないでほしいというメッセージを残している
- コミュニティが持つ 価値ある洞察 を共有できるようにすることが重要だ
- 新しいことを始めるのを恐れなければ、25年後にどこへ到達しているかは分からない
1件のコメント
Hacker Newsのコメント
Wireshark は、あらゆるネットワーク問題を釘に見せてしまう、ことわざのハンマーのようなツール
もっと特化したツールがあっても、Wiresharkを当てればたいてい原因を突き止められる
ネットワークの専門家を名乗りながら、Wiresharkを使ったことがない、あるいは理解していない人がこんなに多いことには今でも驚かされるし、実際のネットワークで何が起きているかを理解するうえで最も重要なツールかもしれない
つい昨日も、アップグレードされた Asterisk/FreePBX システムの異常動作をパケットキャプチャで追跡したが、これがなければ何日も推測するしかなかった問題を、ネットワーク上で起きていることを見てすぐに絞り込めた
ネットワークの専門家ではないが関連する仕事でたまに使ったことがあり、強力さは感じるものの、ごく小さく具体的な問題がないと最初の入り口で圧倒されるツールでもある
必要になったときにその都度学ぶタイプのツールなのかも気になる
ブログ記事にしてもとても面白そう
2013年ごろ、Amazonでレガシーな Spring/Java アプリ／サービスを Node.js の概念実証として1週間で作らなければならず、サービス間認証と Tibco メッセージングが絡んでいた
公開された Tibco クライアント実装が見つからず、節約を重視するリーダーシップ原則のせいで公式仕様を手に入れるのもほぼ不可能だったが、必要だったのは一部リクエストのパケット構造の詳細だけだった
結局どのツールが助けてくれたかは想像がつくだろうし、当時の Principal Engineer もこんなツールがあることに驚いていた
1983年、Ethernetがまだ 太い同軸ケーブル と vampire tap を使っていたころ、シリコンバレーの防衛企業で働いていた
世界中の DSCS(Defense Satellite Communications System) 地上局の DECnet LAN を 9600bps の暗号化回線で接続する Ethernet ブリッジ製品を作っていて、コードの一部として Ethernet カードを promiscuous mode にするパケットダンパーを書いた
Wiresharkのようなデコーダーはなかったが、生のパケットを16進数でターミナルにダンプできるだけでも、ネットワークデバッグにはものすごい利点だった
新しいシステムをインストールするとき、Wiresharkは最初に入れるツールの1つ
当時と今でまったく同じプロトコルなのか、そもそもプロトコルという呼び方が正しいのかもわからない
もっと深くネットワーキングを掘ってみたくなる
Wiresharkを作った本人です
みんなの温かい言葉や思い出を見て、朝からとてもいい気分になった
解析はシングルスレッドのようだし、キャッシュもないように見えるし、10Gbpsリンクでは、たった数秒分の「わずか」数GBのキャプチャでも重すぎる
最初から仕事に欠かせないツールだった
tcpdump も悪くなかったが、パケットを右クリックして follow TCP stream を押すと会話全体を1秒で見られるのは、流れを変える機能だった
「right click->filter out this stream」も同様で、Ethereal/Wiresharkが tcpdump の保存ファイルを読めたので、リモートサーバーに ssh で入って tcpdump を走らせ、クライアント側で Wireshark を使って両方向のネットワークストリームを確認できた
怪しい ISP NAT は一目でわかったし、設定ミスのある MPLS ネットワークも証拠として示せたので、ルーティングチームは「うちの側は問題なさそうです」とだけは言えなかった
ただし記事の1点は訂正したい。Etherealは最初の無料GUIネットワークパケットアナライザではなく、Windows NT 時代にも Microsoft の netmon のようなツールはあった
文書化された API もあり、サポートは曖昧だったが組み込みやすかったので、Ethereal以前にその上で tcpdump ラッパーを作ったことがある
Longhorn/Vista の「次世代」TCPスタックが出たことで、その API と netmon は無効になった
その後 Microsoft Message Analyzer が登場し、ETW ベースでネットワークやほかの ETW トレースを解析でき、サポート用 DSL で任意のプロトコルハンドラを書けた
ログファイルをパースしてデータをフィルタ／分析させることもできたが、あまりに強力で Windows 開発者に有用すぎたのか、結局 Microsoft はそれを廃止してしまった
結局はお金を払って買ったOSに含まれていたツールということになる
Wiresharkは電子工学における マルチメーター のようなもの
なくても世の中は回るが、何か壊れたときにないと詰む
当時まだ Ethereal だったこのツールは、WebLogic 製品群の Senior Tech Support の仕事で本当に貴重だった
顧客に直接実行してもらって、「大規模な JDBC 接続プール の全接続が、顧客自身も把握していなかったネットワークファイアウォールによって静かに切断され、そのせいで朝一番のトランザクションが1時間遅延する。プール内の全接続がタイムアウトして再設定される必要があった」といった答えを返せた
「Internet Explorer がすでにキャッシュされたリソースの TCP 接続を切断することで、IBM サーバー上の WebLogic インストールで非標準のネットワークレベルエラーが起きる」といった問題も突き止められた
その仕事で髪の半分を失ったが、Ethereal がなければ全部と正気まで、もっと失っていただろう
顧客ネットワークの ロードバランサー をサポートしながら、10年以上 Wireshark を毎日使っていた
pcap とコアダンプは扱うデータとして最も面白く、libpcap を学び、最終的には自分でバージョンまで作るようになって、製品技術サポートから開発へ移ることができた
サポートエンジニアとして入社し、以前は自分がサポートしていたコードを自ら書く Principal Software Engineer として退職したが、Wireshark と gdb のおかげで大学に行かなくても本当に多くのことを独学できた
本当に素晴らしいツールで、完全無料
ネットワーク問題のデバッグや、デバイスがどこにつながっているかを見るときによく使うし、誰かが言っていたようにネットワーク用マルチメーターのようなもの
WiFi アクセスポイントとの接続確立を学ぶのにも使ったし、beacon パケットも WiFi パケットも見られる
チームには Sniffer PC があったが、誰かが使っていたり、プロトコル解析が十分でなかったりすることが多かった
本当に優れたソフトウェア
20年前、顧客先で自社ネットワーク機器の相互運用性問題の原因究明に行き詰まっていたとき、2週間かけて プロトコルデコーダープラグイン を書いたら、かなり簡単に役立ったことを覚えている
結局は自分たちのバグで、実装を select() から epoll() に切り替えた際に、select() 用のビットマスク処理を削除していなかったのが原因だった
本質的には1ビットのメモリ破損バグで、結果がかなり遅れて表れることもあり得た
不思議とこういう記憶は長く残る
キャリア初期に、セキュリティ施設で wireshark のインストールが許可されず、tcpdump だけで厄介なネットワークバグを1週間掘り下げたことがある
結局、10年前の GNAT(Ada ライブラリ) 標準ライブラリの最悪のバグと ARP 設定ミスが組み合わさった問題で、そのライブラリバグ自体は実は7年前にすでに修正されていた
あの1週間はあまりにもひどく、もっと良い職場へ移る大きなきっかけになったし、これを楽しむには特別な気質が必要だと思う
人はよく世界を変えることを夢想するが、実際に 世界を変える人たち もいる