Blog | Forest0923's Tech Memo

「RISC-V で学ぶコンピュータアーキテクチャ完全入門」を読んだメモ

2024年12月31日 · 約7分

MEMO

Verilog

RISC-V

RISC-V Technical Specifications

パイプライン

クリティカルパスを分割してクロック周波数を上げる
書籍の実装では Instruction Fetch、Instruction Decode、Execution、Memory Access、Write Back の 5 ステージパイプライン
List of Intel CPU microarchitectures (Wikipedia)
- https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
- 現在の Intel CPU は 10~20 ステージくらいのパイプラインがあるっぽい

分岐予測

本来であれば分岐命令が実行されて次のPCが決まるまで (Execution stage の完了まで) 待たなければならないため、他の pipeline が stall する
- 分岐先を予測すれば stall を回避して先に instruction fetch できる
分岐予測の種類
- ① 分岐命令かどうかの予測
- ② 飛び先アドレスの予測
  - ⇒ Branch Target Buffer (BTB) を用いる
  - 分岐命令のアドレスとジャンプ先のアドレスを保持したテーブルがあればいい ← このテーブルが BTB
  - 実行時に PC の下位ビットをインデックスとして BTB のエントリにアクセス
  - エントリの分岐アドレスが PC と一致すればジャンプ先アドレスを取り出す
- ③ 分岐結果の予測
  - ⇒ Pattern History Table (PHT) を用いる
  - 分岐履歴を保持しておいて，その履歴から分岐の結果を予測
  - BTB と同じように PC の下位ビットをインデックスとして PHT にアクセス
  - PHT には分岐の結果が格納されているため、これをもとに各分岐命令ごとの結果を予測
PHT の履歴をどのように記録していくかのアルゴリズムによって性能は変わる
- PHT が 1 bit で一つ前の結果を記録する
- bimodal 分岐予測
- gshare 分岐予測
bimodal 分岐予測
- 2 bit のカウンタを用いて分岐の結果を記録
  - 00: weak not taken
  - 01: weak taken
  - 10: strong not taken
  - 11: strong taken
- 上位ビットが 1 ならば成立と予測
- 実際に分岐が成立した場合はカウンタをインクリメントし、成立しなかった場合はデクリメント
gshare 分岐予測
- 過去 n 回の分岐履歴を保存して予測する → Branch History Register (BHR)
- PC と n bit の BHR を XOR してインデックスを生成
- そのインデックスを用いて bimoal 分岐予測と同じように予測を行う

キャッシュ

メインメモリへのアクセスはどうしても遅いので、容量は小さくていいので高速なメモリを CPU に持たせる
DRAM を使おうとすると遅延が大きく、読み書きするたびに後続の処理を stall させる必要が出てしまう
ダイレクトマップ方式
- 分岐予測と同じように PC の下位ビットをインデックスとして命令キャッシュにアクセス
- PC とキャッシュのタグが一致 (ヒット) したらメインメモリにアクセスせずに命令を取り出す
キャッシュラインを使用することで空間的局所性を利用
- あるアドレスを読み込んだときにその周辺のアドレスも読み込む
n way セットアソシアティブキャッシュ
- index が衝突した場合にダイレクトマップでは1つしかキャッシュラインを使えないが、n way ならば n 個のキャッシュラインを使える
- n 個のキャッシュテーブルがあるイメージ。n が多すぎると hit 確認でクリティカルパスが長くなり遅延が増える
キャッシュは命令だけでなくデータキャッシュもある
- データキャッシュは読み書きが発生するため、メインメモリとの同期も必要
- Write Through/Write Back
- メインメモリへの書き込みは遅いので書き込みが終わるまで stall するのは避けたい
- Write Buffer に書き込んでおいて、メインメモリへの書き込みはメモリコントローラに任せる
- Write Buffer が溢れた場合やメモリからの読み込みが発生した場合はメモリコントローラがプロセッサを stall させる

Vivado

flatpak で install すると楽

flatpak install com.github.corna.Vivado

事前にアカウントの作成はする必要がある
バージョンによって名前が違いそうだが、ML edition は特定のボードを除いて無料で使用できる
flatpak はサンドボックス環境で動作していてアクセス権限が絞られている
home ディレクトリはアクセス権があったほうがいいので設定を変更する

flatpak override com.github.corna.Vivado --filesystem=home

% flatpak info --show-permissions com.github.corna.Vivado
[Context]
shared=network;ipc;
sockets=x11;
devices=all;
filesystems=xdg-documents;xdg-desktop;home;xdg-download;~/.Xilinx:create;
persistent=.;

[Session Bus Policy]
org.gnome.SessionManager=talk

[Environment]
LD_LIBRARY_PATH=/app/lib
TERMINFO=/app/share/terminfo
LC_ALL=en_US.UTF-8

board の driver がない場合に Hardware Manager の auto connect ができないので、下記でドライバをインストールする

cd $HOME/.var/app/com.github.corna.Vivado/data/xilinx-install/Vivado/2024.2/data/xicom/cable_drivers/lin64/install_script/install_drivers
sudo ./install_drivers

% sudo ./install_drivers
[sudo] password for mmori:
INFO: Installing cable drivers.
INFO: Script name = ./install_drivers
INFO: HostName = strix
INFO: RDI_BINROOT= .
INFO: Current working dir = /home/mmori/.var/app/com.github.corna.Vivado/data/xilinx-install/Vivado/2024.2/data/xicom/cable_drivers/lin64/install_script/install_drivers
INFO: Kernel version = 6.6.64-1-lts.
INFO: Arch = x86_64.
Successfully installed Digilent Cable Drivers
--File /etc/udev/rules.d/52-xilinx-ftdi-usb.rules does not exist.
--File version of /etc/udev/rules.d/52-xilinx-ftdi-usb.rules = 0000.
--Updating rules file.
--File /etc/udev/rules.d/52-xilinx-pcusb.rules does not exist.
--File version of /etc/udev/rules.d/52-xilinx-pcusb.rules = 0000.
--Updating rules file.

INFO: Digilent Return code = 0
INFO: Xilinx Return code = 0
INFO: Xilinx FTDI Return code = 0
INFO: Return code = 0
INFO: Driver installation successful.
CRITICAL WARNING: Cable(s) on the system must be unplugged then plugged back in order for the driver scripts to update the cables.

その他参考
- https://www.acri.c.titech.ac.jp/wordpress/

「入門監視 ― モダンなモニタリングのためのデザインパターン」を読んだメモ

2024年3月21日 · 約19分

Memo

アンチパターン・デザインパターン

監視設定の自動化
json などの構造化ログでメトリクスを収集すれば、その後の自動化が楽になる（場合による）
高い SLA を守るためにはその分高頻度のメトリクス収集が必要
- 標本化定理
ユーザ視点の監視
可能な限り SaaS を使う。コスト・効果ともに優れている場合が多い

アラート

敏感すぎる・鈍感すぎるアラートにならないようにアラートの削除とチューニング
自動復旧できないか？
インシデント対応の役割分担
- 現場指揮官、起こったことの記録者、調整役、インシデント対応者
- （実際にこれを分けるのは難しそう）
PagerDuty Incident Response

統計

パーセンタイルの理解が間違ってた…

ビジネスの監視

16 Startup Metrics
16 More Startup Metrics
ビジネスKPI （key performance indicator）
- 担当プロダクトの KPI は何？

フロントエンド監視・アプリケーション監視

ページロード時間とビジネスの関係について
Navigation timing API のタイムライン
https://sentry.io/welcome/
アプリケーションのヘルスチェック
StatsD
分散トレーシング
- マイクロサービスアーキテクチャの監視をするための方法論とツールのこと？
  - マイクロサービス: 機能を小さなサービスに分割して API で連携する
  - どこのリクエストから始まってどこで終わるかなどがわかりにくい
- リクエストにタグをつけてトレースする
- https://github.com/openzipkin/zipkin
- 分散トレーシングシステムのZipkinを使ってみた話

サーバ監視

メトリクス収集ツールについて

紹介されていた中では collectd, telegraf あたりが良さそう
collectd
- プラグインでカスタムメトリクスを収集できるが、telegraf などのほうが柔軟？
- パフォーマンスは良さそう
telegraf
- プラグインが豊富で様々なデータソースからメトリクスを収集できる
- リソース消費が多い？
Diamond
- カスタムメトリクスを収集できる
- Python 製でパフォーマンスが若干劣る？
- あまりメンテナンスされていなさそう

CPU

top などで確認できる
内部的には /proc/stat からのデータ取得

cat /proc/stat

cpu  33413 59 13366 2018394 1458 2262 687 0 0 0
cpu0 1973 2 801 126259 81 91 66 0 0 0
cpu1 2106 3 711 126291 104 68 37 0 0 0
cpu2 2189 5 806 126152 102 65 29 0 0 0
cpu3 1875 1 791 126367 134 69 35 0 0 0
cpu4 2452 22 930 126026 69 69 29 0 0 0
cpu5 2173 0 773 126261 66 60 26 0 0 0
cpu6 2029 4 669 126380 67 89 59 0 0 0
cpu7 2005 0 780 126315 114 76 57 0 0 0
cpu8 1655 1 1575 124644 93 1199 160 0 0 0
cpu9 2204 0 1125 125957 70 70 28 0 0 0
cpu10 1919 4 705 126452 62 65 28 0 0 0
cpu11 2151 0 847 126234 103 70 26 0 0 0
cpu12 1979 3 674 126485 97 66 26 0 0 0
cpu13 2756 1 684 125664 119 65 25 0 0 0
cpu14 2115 3 697 126376 73 64 24 0 0 0
cpu15 1826 1 790 126523 96 70 25 0 0 0
intr 2023571 14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 3805 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 45306 60782 0 0 0 0 0 0 0 0 0 45 16562 587 133165 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ctxt 5771496
btime 1713664320
processes 16869
procs_running 2
procs_blocked 0
softirq 1061126 57397 66610 143 41034 44699 0 7992 508718 45 334488

Memory

free などで確認
- buff は FS のメタデータのキャッシュ
- cache はデータ本体のキャッシュ
- shared は多分共有ライブラリなど

% free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       3.6Gi        24Gi       106Mi       3.0Gi        27Gi
Swap:          4.0Gi          0B       4.0Gi

内部的には /proc/meminfo からのデータ取得

cat /proc/meminfo

MemTotal:       32676436 kB
MemFree:        26243212 kB
MemAvailable:   28892088 kB
Buffers:            3212 kB
Cached:          3081776 kB
SwapCached:            0 kB
Active:          4194420 kB
Inactive:        1483412 kB
Active(anon):    2706408 kB
Inactive(anon):        0 kB
Active(file):    1488012 kB
Inactive(file):  1483412 kB
Unevictable:        3136 kB
Mlocked:              48 kB
SwapTotal:       4194300 kB
SwapFree:        4194300 kB
Zswap:                 0 kB
Zswapped:              0 kB
Dirty:               272 kB
Writeback:             0 kB
AnonPages:       2585280 kB
Mapped:           960064 kB
Shmem:            113560 kB
KReclaimable:      85464 kB
Slab:             231872 kB
SReclaimable:      85464 kB
SUnreclaim:       146408 kB
KernelStack:       18544 kB
PageTables:        44560 kB
SecPageTables:         0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    20532516 kB
Committed_AS:   12818284 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      170084 kB
VmallocChunk:          0 kB
Percpu:            12352 kB
HardwareCorrupted:     0 kB
AnonHugePages:    712704 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:    374784 kB
FilePmdMapped:     18432 kB
CmaTotal:              0 kB
CmaFree:               0 kB
Unaccepted:            0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      959096 kB
DirectMap2M:     8284160 kB
DirectMap1G:    25165824 kB

OOMKiller のログを監視するのも大切

Network の監視

ifconfig や ip コマンドで確認
/proc/net/dev からのデータ取得

Disk の監視

iostat や df などで確認

iostat

Linux 6.8.6-arch1-1 (strix) 	04/21/2024 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.71    0.00    0.74    0.05    0.00   97.50

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
sda              27.38      1172.47       534.96       197.67    2230709    1017793     376084
zram0             0.03         0.62         0.00         0.00       1180          4          0

/proc/diskstats からのデータ取得

cat /proc/diskstats

     0 sda 18834 2018 4461434 26986 34351 23700 2080266 16927 0 24827 46864 228 0 774072 471 4649 2478
     1 sda1 129 1053 8442 50 12 0 10 1 0 64 52 0 0 0 0 0 0
     2 sda2 18599 965 4448448 26912 34338 23700 2080256 16925 0 24787 44309 228 0 774072 471 0 0
     0 zram0 54 0 2360 0 1 0 8 0 0 10 0 0 0 0 0 0 0
    16 sdb 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Load average の監視

CPU の処理待ちをしているプロセスの指標
- 1分、5分、15分の平均
- cf. https://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html
uptime などで確認

uptime

 11:27:17 up 35 min,  1 user,  load average: 0.54, 0.57, 0.48

/proc/loadavg からのデータ取得

cat /proc/loadavg

0.63 0.58 0.49 2/1168 22514

SSL 証明書の監視

有効期限の監視と通知

Web サーバの監視

レスポンスのステータスコードを監視する

DB の監視

スレッド数（コネクション数）の監視
cf. 実践ハイパフォーマンス MySQL

MQ の監視

queue の長さの監視 => ConsumerLag?
consumption ratio
- consume のスピード

cache

hit/miss ratio

DNS

qps の監視
BIND の場合はメトリクスを収集するためのオプションがある
- collectd のプラグインと組み合わせて監視できる

NTP

kerberos の認証などで問題になりうる
ntpstat

Logging

収集
- syslog
保存
- SaaS を使用？
分析
- 目的、用途に応じて使い分ける
  - Splunk
  - grep などのコマンドラインツール
  - ELK スタック (Elasticsearch, Logstash, Kibana)

セキュリティ監視

cf. The Practice of Network Security Monitoring
auditd
- sudo のログなどを収集できる
- audisp-remote プラグインでリモートにログを送信できるので改ざんされにくい
- syslog に依存せずにログ収集できるので syslog を攻撃者に停止されたりしてもログが残る
rkhunter
- rootkit の検出
- https://www.kali.org/tools/rkhunter/

etc

nagios
zabbix

「Rust で始める TCP 自作入門」を読んだメモ

2024年3月7日 · 約5分

TCP・ネットワーク関連

Socket

stream socket: TCP
datagram socket: UDP
raw socket: データリンク層のフレームを直接操作する
packet socket: ネットワーク層のパケットを直接操作する

TCP header

alt text

TCP header は 20 バイト
Data offset は 4 bit で TCP header の長さを示す。最小値は 5 で 20 バイト(Options がない場合)、最大値は 15 で 60 バイト
URG (urgent)
- 緊急のデータであることを示して先に処理させる
ACK (acknowledgment)
PSH (push)
- データをバッファリングせずに送信させる
RST (reset)
- 予期しない状況やエラー時に接続をリセットする
SYN (synchronize)
FIN (finish)
Window size は受信側のバッファサイズを通知する
Checksum はヘッダとデータの整合性を確認するためのもので計算には送信元 IP と宛先 IP も必要
Urgent pointer は URG フラグが立っている場合に使用されるもので、緊急のデータの位置を示す
Options は可変長で window scale や timestamp などが含まれる
Padding は Options の長さが 32 bit の倍数になるように埋めるためのもの

スライディングウィンドウ

ある程度のセグメントを ACK を待たずに送信することで効率的に通信を行う仕組み
- 制限なしにパケットを送信し続けてしまうと受信側のバッファがオーバーフローしてしまう
- しかし、ACK を毎回待っていると通信効率が悪くなる
データ送信したらその分 Window を消費し、ACK を受け取ったら Window を回復する

TCP の問題点、QUIC

HoL (Head of Line) Blocking
- パケットロスが発生した場合にその後のパケットも待たされてしまう問題
シーケンス番号の使い回し
- パケットロスが発生したときに再送されたパケットは同じシーケンス番号を持つため、確認応答がもとのパケットと紛らわしい
- 再送タイムアウト時間の推定に悪影響（←あまり良くわかってない）
QUICK
- 一つのコネクションで複数のストリームを扱うため、HoL Blocking を回避できる
- 扱うデータごとにストリームを分けることで再送によるブロッキングを回避
- セグメントのID とシーケンス番号を分けることでシーケンス番号の使い回しを回避

Rust 関連

ツール関連

WireShark

Install

paru -S wireshark-qt

sudo usermod -aG wireshark $USER

loop back デバイスの 5000 番ポートへの TCP 通信をキャプチャする

tshark -i lo -f "tcp port 5000"

キャプチャ例: nc で 5000 番ポートに接続

% tshark -i lo -f "tcp port 5000"
Capturing on 'Loopback: lo'
    1 0.000000000          ::1 → ::1          TCP 94 45276 → 5000 [SYN] Seq=0 Win=33280 Len=0 MSS=65476 SACK_PERM TSval=1034799462 TSecr=0 WS=128
    2 0.000007955          ::1 → ::1          TCP 74 5000 → 45276 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
    3 0.000057822    127.0.0.1 → 127.0.0.1    TCP 74 52950 → 5000 [SYN] Seq=0 Win=33280 Len=0 MSS=65495 SACK_PERM TSval=2869984391 TSecr=0 WS=128
    4 0.000068765    127.0.0.1 → 127.0.0.1    TCP 54 5000 → 52950 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

nc

リスニング状態で待機

nc -l 5000

5000 番ポートに接続

nc localhost 5000

% nc -l 5000
hello

% nc localhost 5000
hello

ポートスキャン

nc -zv localhost <port>-<port>

% nc -zv localhost 22
Connection to localhost (::1) 22 port [tcp/ssh] succeeded!

ip

Network namespace の作成

sudo ip netns add host0
sudo ip netns add host1

Virtual Ethernet Device の作成
- veth type のデバイスを作成し、veth0 と veth1 という名前でペアを作成する
- 仮想的に 2 つのネットワークインタフェースが接続された状態になる
- veth のドライバが必要

sudo ip link add name veth0 type veth peer name veth1

namespace に作成したネットワークインタフェースを割り当てる
- veth1 を host1 という namespace に割り当てる

sudo ip link set veth1 netns host1

namespace 内でのコマンド実行

sudo ip netns exec host1 <command>

ネットワークインタフェースを有効にする

sudo ip netns exec host1 ip link set veth1 up

MEMO​

Verilog​

RISC-V​

パイプライン​

分岐予測​

キャッシュ​

Vivado​

Memo​

アンチパターン・デザインパターン​

アラート​

統計​

ビジネスの監視​

フロントエンド監視・アプリケーション監視​

サーバ監視​

メトリクス収集ツールについて​

CPU​

Memory​

Network の監視​

Disk の監視​

Load average の監視​

SSL 証明書の監視​

Web サーバの監視​

DB の監視​

MQ の監視​

cache​

DNS​

NTP​

Logging​

セキュリティ監視​

etc​

TCP・ネットワーク関連​

Socket​

TCP header​

スライディングウィンドウ​

TCP の問題点、QUIC​

Rust 関連​

Error Handling​

thread​

Arc​

ツール関連​

WireShark​

nc​

ip​

ethtool​

iptables​

MEMO

Verilog

RISC-V

パイプライン

分岐予測

キャッシュ

Vivado

Memo

アンチパターン・デザインパターン

アラート

統計

ビジネスの監視

フロントエンド監視・アプリケーション監視

サーバ監視

メトリクス収集ツールについて

CPU

Memory

Network の監視

Disk の監視

Load average の監視

SSL 証明書の監視

Web サーバの監視

DB の監視

MQ の監視

cache

DNS

NTP

Logging

セキュリティ監視

etc

TCP・ネットワーク関連

Socket

TCP header

スライディングウィンドウ

TCP の問題点、QUIC

Rust 関連

Error Handling

thread

Arc

ツール関連

WireShark

nc

ip

ethtool

iptables