SSHで1文字送信に100パケットが必要な理由とは？Claude Codeで調査
SSH通信の仕組みを調査し、1文字送信に多数のパケットが必要な理由をClaude Codeを使って分析した技術記事。
キーポイント
SSHでは1文字のキー入力でも多数のパケット（例：270パケット）が発生し、その多くが36バイトの小さなメッセージであること
この現象はSSHの暗号化と認証、TCPの信頼性確保（ACK）などのプロトコルオーバーヘッドに起因していること
Claude CodeなどのAI支援ツールを活用してネットワークトラフィックの詳細な分析・デバッグが可能であること
高パフォーマンスが求められるリアルタイムアプリケーション（例：ゲームのTUI）では、SSHのオーバーヘッドがボトルネックになる可能性があること
技術的な「当たり前」を深掘りし、実証的に検証する姿勢の重要性を示していること
影響分析・編集コメントを表示
影響分析
この記事は、日常的に使われる技術（SSH）の内部動作を実証的に分析し、そのオーバーヘッドが特定のユースケース（高頻度更新が必要なアプリケーション）で問題となり得ることを示唆している。AIツール（Claude Code）を活用した技術調査の実例として、実践的なデバッグ手法の参考となる。
編集コメント
「当たり前」を疑い、AIツールで深掘りする姿勢が光る技術ブログ。ネットワークやインフラに携わるエンジニアの実務的な気付きを与える内容。
こんにちは、ABEJA Platform に搭載しているアプリケーション、「ABEJA Insight for Retail」の開発と運用を担当している森永です。
みなさんは普段 SSH を使っていますか？
私は元々 Vimmer だったこともあり (最近は機能面で楽なので VSCode を使用しておりますが...笑) 、SSH には非常にお世話になっており、現在でも直接叩くことは減りましたが、 VSCode やその他の便利なツールの裏で動く縁の下の力持ちとしてお世話になっています。
とあるテックブログで公開されていた『 Why does SSH send 100 packets per keystroke? · eieio.games 』という記事が Claude Code を有効に使ってかなり興味深いデバッグを行なっていたので、要点の翻訳もかねつつ、コメントを行なっていければと思います。
SSHセッションでたった1回のキーストロークを送信した際の、tcpdump
$ ./first_lines_of_pcap.sh single-key.pcap 1 0.000s CLIENT->SERVER 36 bytes 2 0.007s SERVER->CLIENT 564 bytes 3 0.015s CLIENT->SERVER 0 bytes 4 0.015s CLIENT->SERVER 36 bytes 5 0.015s SERVER->CLIENT 36 bytes 6 0.026s CLIENT->SERVER 0 bytes 7 0.036s CLIENT->SERVER 36 bytes 8 0.036s SERVER->CLIENT 36 bytes 9 0.046s CLIENT->SERVER 0 bytes 10 0.059s CLIENT->SERVER 36 bytes
first_lines_of_pcap.sh tshark -r "$1" \ -T fields -e frame.number -e frame.time_relative -e ip.src -e ip.dst -e tcp.len | \ awk 'NR<=10 {dir = ($3 ~ /71\.190/ ? "CLIENT->SERVER" : "SERVER->CLIENT"); printf "%3d %6.3fs %-4s %3s bytes\n", $1, $2, dir, $5}'
『数行』という表現を使っているのは、実際にはこのような行が大量にあるからです。
実際に統計値を取ってみると、以下のようになります。
$ ./summarize_pcap.sh single-key.pcap 合計パケット数: 270 36 バイトのメッセージ : 179 packets ( 66.3%) 6444 bytes その他のデータ: 1 packet ( 0.4%) 564 bytes TCP ACKs: 90 packets ( 33.3%) 送信データ量: 6444 bytes in 36-byte messages, 564 bytes in other data データ比率: 11.4x more data in 36-byte messages than other data データパケット レート: ~90 パケット/秒 (データパケットの間隔の平均 11.1 ms)
summarize_pcap.sh tshark -r "$1" -Y "frame.time_relative <= 2.0" -T fields -e frame.time_relative -e tcp.len | awk ' { count++ payload = $2 if (payload == 0) { acks++ } else if (payload == 36) { mystery++ if (NR > 1 && prev_data_time > 0) { delta = $1 - prev_data_time sum_data_deltas += delta data_intervals++ } prev_data_time = $1 } else { game_data++ game_bytes = payload if (NR > 1 && prev_data_time > 0) { delta = $1 - prev_data_time sum_data_deltas += delta data_intervals++ } prev_data_time = $1 } } END { print "Total packets:", count print "" printf " 36-byte msgs: %3d packets (%5.1f%%) %5d bytes\n", mystery, 100*mystery/count, mystery*36 printf " Other data: %3d packet (%5.1f%%) %5d bytes\n", game_data, 100*game_data/count, game_bytes printf " TCP ACKs: %3d packets (%5.1f%%)\n", acks, 100*acks/count print "" printf " Data sent: %d bytes in 36-byte messages, %d bytes in other data\n", mystery*36, game_bytes printf " Ratio: %.1fx more data in 36-byte messages than other data\n", (mystery*36)/game_bytes print "" avg_ms = (sum_data_deltas / data_intervals) * 1000 printf " Data packet rate: ~%d packets/second (avg %.1f ms between data packets)\n", int(1000/avg_ms + 0.5), avg_ms }'
たった1回のキー入力にしては、あまりにもパケットが多すぎます (特に 36 バイトのパケット)。一体何が起きているのでしょうか？また、元ブログの筆者はどうして事象が気になったのでしょうか？
元ブログの筆者 (以降、「筆者」と記述) は、SSH上で動作する高パフォーマンスなゲームを開発中でした。ゲームのTUI（テキストユーザインターフェース）は bubbletea
このゲームは 80x60 のウィンドウでプレイでき、秒間 10 回更新されます。少なくとも 2,000 人の同時接続プレイヤーを目標としており、これは毎秒約 1 億セルということになり、パフォーマンスが非常に重要になります。
そこで筆者は、数百のボットをSSH経由で接続させ、1秒に1回動作させるスクリプトを用意し、Go言語のプロファイリングツールを使って何が起きているかを観察したそうです。
色々と変更を加えている内にバグが入ってしまい、筆者はうっかりテストハーネス（テスト環境）を壊してしまったそうです。サーバーはボットに定期的にゲームデータを送信する代わりに、「画面が小さすぎます」という単一のメッセージを送るようにしてしまっていたのだそうです。
このバグにより、ゲームの CPU 使用率と帯域幅の使用量は半分になりました。
筆者は最初はがっかりしたそうです。手軽に大幅な高速化ができたかと思ったものが、実際にはテストのミスだったからです。
しかし、そこで疑問が湧いたそうです。
もしボットに有用なゲームデータを送り返していないのなら、なぜ CPU 使用率は 0% 近くに落ちず、 半分ほどにしか 下がらなかったのでしょうか？
調査 (Investigation)
テストハーネスの問題をデバッグする一環として、破壊的な変更を加えた場合と加えていない場合のゲームトラフィックを記録するために tcpdump
ゲームはポート22で動作中 timeout 30s tcpdump -i eth0 'port 22' -w with-breaking-change.pcap # 変更を元に戻す timeout 30s tcpdump -i eth0 'port 22' -w without-breaking-change.pcap
混入したバグにより、SSH 上でのゲームのレンダリングが停止しました。つまり、with-breaking-change.pcap
Claude Code に pcap ファイルで見た内容の要約を依頼すると...
Claude Code: うわっ！これを見てください：
パケットサイズ分布 (合計 413,703 パケット):
274,907 パケット (66%): 36バイトのデータ
138,778 パケット (34%): 0バイト (TCP ACK)
18 パケット (<0.1%): 72バイトのデータ
66 % のもパケットを謎の 36 バイトのデータを運んでいるパケットで占めていることが分かります。
より小さな pcap ファイルを作って分析を進めたところ、この謎パケットが約20ミリ秒間隔で到着していることがわかりました。
これは筆者にとっても（そして一緒にデバッグしていた Claude Code にとっても）不可解だったそうです。ここで原因として考えられるものをいくつか出し合ったそうです：
SSHのフロー制御メッセージ？
PTYサイズのポーリングやその他のステータスチェック？
ただ、一つ際立っていたのはこれらのやり取りが筆者のサーバーからではなく、筆者が利用していた SSH クライアント（ MacOS にインストールされている標準の ssh ）によって送信されていた、という点でした。
そこで勘を頼りに、通常の SSH セッションの tcpdump
Mac上の1つのタブで実行 sudo tcpdump -ien0 'port 22' # Mac上の別のタブで実行 ssh $some_vm_of_mine
初期接続の通信が落ち着くのを待ち、リモート VM に 1 回だけキーストロークを送信して、tcpdump
全く同じパターンが見られたそうでした！あとはこの現象の原因を探っていくだけですね。
根本原因 (Root cause)
これが標準の SSH の挙動起因であると気づいて調査範囲を絞れたので、デバッグはだいぶ容易になったようです。
SSH コマンドをデバッグ出力するために ssh -vvv
debug3: obfuscate_keystroke_timing: starting: interval ~20ms debug3: obfuscate_keystroke_timing: stopping: chaff time expired (49 chaff packets sent) debug3: obfuscate_keystroke_timing: starting: interval ~20ms debug3: obfuscate_keystroke_timing: stopping: chaff time expired (101 chaff packets sent)
前述した『20ms』と一致する記述が含まれる行が決定的証拠ですね。これは先ほど見た謎のパターンと完全に一致するのが分かるかと思います！
そしてメッセージの残りの部分も非常に役立ちます。最初のキーストロークに対して49個の「チャフ（おとり）」パケットを送信し、2回目あたりでは101個の「チャフ」を送信しています。
実は別途調査すると、SSH には 2023 年に「キーストロークタイミングの難読化（keystroke timing obfuscation） *4 」機能が追加されたみたいです。これは、異なる文字をタイプする速度で、どの文字をタイプしているかという情報を推測できてしまうという考えに基づいています。そのため、SSH はキーストロークと一緒に大量の「チャフ」パケットを送信し、攻撃者がいつ実際にキーを入力しているか特定するのを困難にしています。
確かに、通信の秘匿性を保つことが重要な通常のSSHセッションにおいては非常に理にかなっていますね。しかし、今回のようにレイテンシ（遅延）が重要で、インターネット全体に公開されているゲームにとっては、多大なオーバーヘッドとなります。
修正 (Remediation)
実はキーストロークの難読化はクライアント側で無効にできます。筆者は元の破壊的な変更を元に戻した後、SSH セッションを開始する際に ObscureKeystrokeTiming=no
これはうまくいきました。CPU 使用率は劇的に低下し、ボットは依然として有効なデータを受け取りました。
ただし、これは現実的な解決策になりません。なぜなら筆者は ssh mygame
試しに Claude Code に相談してみても、この機能をサーバー側で無効にできないと言われたそうです。
でも粘り強く調査してみると幸運なことに、筆者がとあるサイト上 SSH のキーストローク難読化の説明 をで見つけたおかげで、依存していた Go の SSH ライブラリ内の関連コードを簡単に調べることができたそうです。
(下記は当該サイト上からの引用)
ログメッセージ: トランスポートレベルのping機能を導入 これは、ping機能を実装するために、SSHトランスポートプロトコルメッセージ SSH2_MSG_PING
ping@openssh.com
Introduce a transport-level ping facility
This adds a pair of SSH transport protocol messages SSH2_MSG_PING/PONG to implement a ping capability. These messages use numbers in the "local extensions" number space and are advertised using a "ping@openssh.com" ext-info message with a string version number of "0".
上記のログから、 SSH がキーストロークを隠蔽するために使用する「チャフ」メッセージは、SSH2_MSG_PING
そしてそのメッセージは、ping@openssh.com
ここで、「もし ping@openssh.com
筆者は、Go の SSH ライブラリで ping@openssh.com
また幸いにも、そのコミットは非常に小さかったので、修正するのはとても簡単そうにみえたそうです。
そこで、試しに Go の crypto リポジトリをクローンし、この変更を revert するよう Claude Code に指示、依存関係を更新してローカルの crypto リポジトリのクローンを使用して自作ゲームを再構成してみたそうです (Goの replace
その後、テストハーネスを再実行したところ、 CPU 負荷や利用する帯域幅の低減等、適切に対処ができていそうな結果が得られたそうです：
合計 CPU 使用率: 29.90% -> 11.64%
システムコール: 3.10s -> 0.66s
暗号化処理: 1.6s -> 0.11s
帯域幅: ~6.5 Mbit/sec -> ~3 Mbit/sec
(余談ですが) Claude Code もかなり興奮していまたようです：
Claude Code: なんてこった（HOLY COW）！この CPU 使用率を見てくださいよ
合計のサンプル数: 3.51 秒 (11.64 %)
ただ明らかに、Go の crypto ライブラリをフォークして修正したものを利用し続けるのは少々セキュリティの観点で怖いので、筆者は自分が適用した小さなパッチを安全に維持して適用する方法についてはまだ考慮する点があると言うことについて留意して記事を締め括っています。
パケットキャプチャを取られ、そのバイトサイズから送信文字列を推測される可能性があること考慮してパッチが当てられているのには、「ここまでするのか...」と個人的に驚きました。
SSH が現在でもアップデートされ続け、現役でも使われ続ける理由に納得が行きました。
もし SSH を経由した通信が遅いと感じたら、セキュリティ的に安全な範囲 (ローカルネット内での作業等) で該当のオプションを無効化を検討して見るのもありですね。
また、SSH ライブラリのデバッグでも Claude Code を活用してかなり有益なデバッグが行えることを実際に確認できた例かと思います。
*1:https://github.com/charmbracelet/bubbletea
*2:https://github.com/charmbracelet/wish
*3: 「-vvv」は最も詳細な verbose 出力を指定できるオプション。 パケットレベルのやり取りまで含めた、SSHクライアントの内部動作のほぼ全てが表示されます。
*4:https://marc.info/?l=openbsd-cvs&m=169319335902218&w=2
原文を表示
こんにちは、ABEJA Platform に搭載しているアプリケーション、「ABEJA Insight for Retail」の開発と運用を担当している森永です。
みなさんは普段 SSH を使っていますか？
私は元々 Vimmer だったこともあり (最近は機能面で楽なので VSCode を使用しておりますが...笑) 、SSH には非常にお世話になっており、現在でも直接叩くことは減りましたが、 VSCode やその他の便利なツールの裏で動く縁の下の力持ちとしてお世話になっています。
とあるテックブログで公開されていた『 Why does SSH send 100 packets per keystroke? · eieio.games 』という記事が Claude Code を有効に使ってかなり興味深いデバッグを行なっていたので、要点の翻訳もかねつつ、コメントを行なっていければと思います。
SSHセッションでたった1回のキーストロークを送信した際の、tcpdump
$ ./first_lines_of_pcap.sh single-key.pcap 1 0.000s CLIENT->SERVER 36 bytes 2 0.007s SERVER->CLIENT 564 bytes 3 0.015s CLIENT->SERVER 0 bytes 4 0.015s CLIENT->SERVER 36 bytes 5 0.015s SERVER->CLIENT 36 bytes 6 0.026s CLIENT->SERVER 0 bytes 7 0.036s CLIENT->SERVER 36 bytes 8 0.036s SERVER->CLIENT 36 bytes 9 0.046s CLIENT->SERVER 0 bytes 10 0.059s CLIENT->SERVER 36 bytes
first_lines_of_pcap.sh tshark -r "$1" \ -T fields -e frame.number -e frame.time_relative -e ip.src -e ip.dst -e tcp.len | \ awk 'NR<=10 {dir = ($3 ~ /71\.190/ ? "CLIENT->SERVER" : "SERVER->CLIENT"); printf "%3d %6.3fs %-4s %3s bytes\n", $1, $2, dir, $5}'
『数行』という表現を使っているのは、実際にはこのような行が大量にあるからです。
実際に統計値を取ってみると、以下のようになります。
$ ./summarize_pcap.sh single-key.pcap 合計パケット数: 270 36 バイトのメッセージ : 179 packets ( 66.3%) 6444 bytes その他のデータ: 1 packet ( 0.4%) 564 bytes TCP ACKs: 90 packets ( 33.3%) 送信データ量: 6444 bytes in 36-byte messages, 564 bytes in other data データ比率: 11.4x more data in 36-byte messages than other data データパケット レート: ~90 パケット/秒 (データパケットの間隔の平均 11.1 ms)
summarize_pcap.sh tshark -r "$1" -Y "frame.time_relative <= 2.0" -T fields -e frame.time_relative -e tcp.len | awk ' { count++ payload = $2 if (payload == 0) { acks++ } else if (payload == 36) { mystery++ if (NR > 1 && prev_data_time > 0) { delta = $1 - prev_data_time sum_data_deltas += delta data_intervals++ } prev_data_time = $1 } else { game_data++ game_bytes = payload if (NR > 1 && prev_data_time > 0) { delta = $1 - prev_data_time sum_data_deltas += delta data_intervals++ } prev_data_time = $1 } } END { print "Total packets:", count print "" printf " 36-byte msgs: %3d packets (%5.1f%%) %5d bytes\n", mystery, 100*mystery/count, mystery*36 printf " Other data: %3d packet (%5.1f%%) %5d bytes\n", game_data, 100*game_data/count, game_bytes printf " TCP ACKs: %3d packets (%5.1f%%)\n", acks, 100*acks/count print "" printf " Data sent: %d bytes in 36-byte messages, %d bytes in other data\n", mystery*36, game_bytes printf " Ratio: %.1fx more data in 36-byte messages than other data\n", (mystery*36)/game_bytes print "" avg_ms = (sum_data_deltas / data_intervals) * 1000 printf " Data packet rate: ~%d packets/second (avg %.1f ms between data packets)\n", int(1000/avg_ms + 0.5), avg_ms }'
たった1回のキー入力にしては、あまりにもパケットが多すぎます (特に 36 バイトのパケット)。一体何が起きているのでしょうか？また、元ブログの筆者はどうして事象が気になったのでしょうか？
元ブログの筆者 (以降、「筆者」と記述) は、SSH上で動作する高パフォーマンスなゲームを開発中でした。ゲームのTUI（テキストユーザインターフェース）は bubbletea
このゲームは 80x60 のウィンドウでプレイでき、秒間 10 回更新されます。少なくとも 2,000 人の同時接続プレイヤーを目標としており、これは毎秒約 1 億セルということになり、パフォーマンスが非常に重要になります。
そこで筆者は、数百のボットをSSH経由で接続させ、1秒に1回動作させるスクリプトを用意し、Go言語のプロファイリングツールを使って何が起きているかを観察したそうです。
色々と変更を加えている内にバグが入ってしまい、筆者はうっかりテストハーネス（テスト環境）を壊してしまったそうです。サーバーはボットに定期的にゲームデータを送信する代わりに、「画面が小さすぎます」という単一のメッセージを送るようにしてしまっていたのだそうです。
このバグにより、ゲームの CPU 使用率と帯域幅の使用量は半分になりました。
筆者は最初はがっかりしたそうです。手軽に大幅な高速化ができたかと思ったものが、実際にはテストのミスだったからです。
しかし、そこで疑問が湧いたそうです。
もしボットに有用なゲームデータを送り返していないのなら、なぜ CPU 使用率は 0% 近くに落ちず、 半分ほどにしか 下がらなかったのでしょうか？
調査 (Investigation)
テストハーネスの問題をデバッグする一環として、破壊的な変更を加えた場合と加えていない場合のゲームトラフィックを記録するために tcpdump
ゲームはポート22で動作中 timeout 30s tcpdump -i eth0 'port 22' -w with-breaking-change.pcap # 変更を元に戻す timeout 30s tcpdump -i eth0 'port 22' -w without-breaking-change.pcap
混入したバグにより、SSH 上でのゲームのレンダリングが停止しました。つまり、with-breaking-change.pcap
Claude Code に pcap ファイルで見た内容の要約を依頼すると...
Claude Code: うわっ！これを見てください：
パケットサイズ分布 (合計 413,703 パケット):
274,907 パケット (66%): 36バイトのデータ
138,778 パケット (34%): 0バイト (TCP ACK)
18 パケット (<0.1%): 72バイトのデータ
66 % のもパケットを謎の 36 バイトのデータを運んでいるパケットで占めていることが分かります。
より小さな pcap ファイルを作って分析を進めたところ、この謎パケットが約20ミリ秒間隔で到着していることがわかりました。
これは筆者にとっても（そして一緒にデバッグしていた Claude Code にとっても）不可解だったそうです。ここで原因として考えられるものをいくつか出し合ったそうです：
SSHのフロー制御メッセージ？
PTYサイズのポーリングやその他のステータスチェック？
ただ、一つ際立っていたのはこれらのやり取りが筆者のサーバーからではなく、筆者が利用していた SSH クライアント（ MacOS にインストールされている標準の ssh ）によって送信されていた、という点でした。
そこで勘を頼りに、通常の SSH セッションの tcpdump
Mac上の1つのタブで実行 sudo tcpdump -ien0 'port 22' # Mac上の別のタブで実行 ssh $some_vm_of_mine
初期接続の通信が落ち着くのを待ち、リモート VM に 1 回だけキーストロークを送信して、tcpdump
全く同じパターンが見られたそうでした！あとはこの現象の原因を探っていくだけですね。
根本原因 (Root cause)
これが標準の SSH の挙動起因であると気づいて調査範囲を絞れたので、デバッグはだいぶ容易になったようです。
SSH コマンドをデバッグ出力するために ssh -vvv
debug3: obfuscate_keystroke_timing: starting: interval ~20ms debug3: obfuscate_keystroke_timing: stopping: chaff time expired (49 chaff packets sent) debug3: obfuscate_keystroke_timing: starting: interval ~20ms debug3: obfuscate_keystroke_timing: stopping: chaff time expired (101 chaff packets sent)
前述した『20ms』と一致する記述が含まれる行が決定的証拠ですね。これは先ほど見た謎のパターンと完全に一致するのが分かるかと思います！
そしてメッセージの残りの部分も非常に役立ちます。最初のキーストロークに対して49個の「チャフ（おとり）」パケットを送信し、2回目あたりでは101個の「チャフ」を送信しています。
実は別途調査すると、SSH には 2023 年に「キーストロークタイミングの難読化（keystroke timing obfuscation） *4 」機能が追加されたみたいです。これは、異なる文字をタイプする速度で、どの文字をタイプしているかという情報を推測できてしまうという考えに基づいています。そのため、SSH はキーストロークと一緒に大量の「チャフ」パケットを送信し、攻撃者がいつ実際にキーを入力しているか特定するのを困難にしています。
確かに、通信の秘匿性を保つことが重要な通常のSSHセッションにおいては非常に理にかなっていますね。しかし、今回のようにレイテンシ（遅延）が重要で、インターネット全体に公開されているゲームにとっては、多大なオーバーヘッドとなります。
修正 (Remediation)
実はキーストロークの難読化はクライアント側で無効にできます。筆者は元の破壊的な変更を元に戻した後、SSH セッションを開始する際に ObscureKeystrokeTiming=no
これはうまくいきました。CPU 使用率は劇的に低下し、ボットは依然として有効なデータを受け取りました。
ただし、これは現実的な解決策になりません。なぜなら筆者は ssh mygame
試しに Claude Code に相談してみても、この機能をサーバー側で無効にできないと言われたそうです。
でも粘り強く調査してみると幸運なことに、筆者がとあるサイト上 SSH のキーストローク難読化の説明 をで見つけたおかげで、依存していた Go の SSH ライブラリ内の関連コードを簡単に調べることができたそうです。
(下記は当該サイト上からの引用)
ログメッセージ: トランスポートレベルのping機能を導入 これは、ping機能を実装するために、SSHトランスポートプロトコルメッセージ SSH2_MSG_PING
ping@openssh.com
Introduce a transport-level ping facility
This adds a pair of SSH transport protocol messages SSH2_MSG_PING/PONG to implement a ping capability. These messages use numbers in the "local extensions" number space and are advertised using a "ping@openssh.com" ext-info message with a string version number of "0".
上記のログから、 SSH がキーストロークを隠蔽するために使用する「チャフ」メッセージは、SSH2_MSG_PING
そしてそのメッセージは、ping@openssh.com
ここで、「もし ping@openssh.com
筆者は、Go の SSH ライブラリで ping@openssh.com
また幸いにも、そのコミットは非常に小さかったので、修正するのはとても簡単そうにみえたそうです。
そこで、試しに Go の crypto リポジトリをクローンし、この変更を revert するよう Claude Code に指示、依存関係を更新してローカルの crypto リポジトリのクローンを使用して自作ゲームを再構成してみたそうです (Goの replace
その後、テストハーネスを再実行したところ、 CPU 負荷や利用する帯域幅の低減等、適切に対処ができていそうな結果が得られたそうです：
合計 CPU 使用率: 29.90% -> 11.64%
システムコール: 3.10s -> 0.66s
暗号化処理: 1.6s -> 0.11s
帯域幅: ~6.5 Mbit/sec -> ~3 Mbit/sec
(余談ですが) Claude Code もかなり興奮していまたようです：
Claude Code: なんてこった（HOLY COW）！この CPU 使用率を見てくださいよ
合計のサンプル数: 3.51 秒 (11.64 %)
ただ明らかに、Go の crypto ライブラリをフォークして修正したものを利用し続けるのは少々セキュリティの観点で怖いので、筆者は自分が適用した小さなパッチを安全に維持して適用する方法についてはまだ考慮する点があると言うことについて留意して記事を締め括っています。
パケットキャプチャを取られ、そのバイトサイズから送信文字列を推測される可能性があること考慮してパッチが当てられているのには、「ここまでするのか...」と個人的に驚きました。
SSH が現在でもアップデートされ続け、現役でも使われ続ける理由に納得が行きました。
もし SSH を経由した通信が遅いと感じたら、セキュリティ的に安全な範囲 (ローカルネット内での作業等) で該当のオプションを無効化を検討して見るのもありですね。
また、SSH ライブラリのデバッグでも Claude Code を活用してかなり有益なデバッグが行えることを実際に確認できた例かと思います。
*1:https://github.com/charmbracelet/bubbletea
*2:https://github.com/charmbracelet/wish
*3: 「-vvv」は最も詳細な verbose 出力を指定できるオプション。 パケットレベルのやり取りまで含めた、SSHクライアントの内部動作のほぼ全てが表示されます。
*4:https://marc.info/?l=openbsd-cvs&m=169319335902218&w=2
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み