日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。
4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K, 12.1-RELEASE-K は、 プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K から 12.3-RELEASE-K, 13.0-RELEASE-K から 13.2-RELEASE-K は、全翻訳済み)
13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。
Table of Contents
SIFTR(4) FreeBSD カーネルインタフェースマニュアル SIFTR(4)
名称
SIFTR -- TCP 調査のための統計情報
書式
実行時にモジュールとしてドライバをロードするためには、root として次のコマ
ンドを実行します:
kldload siftr
もう一つの方法として、ブート時にモジュールとしてドライバをロードするため
には、次の行を loader.conf(5) ファイルに追加します:
siftr_load="YES"
解説
SIFTR (Statistical Information For TCP Research) カーネルモジュールは、ア
クティブな TCP 接続での一連の統計をログファイルにログ記録します。それは、
システム管理者、開発者と研究者を対象にした、TCP 接続状態の極めて粒度の細
かい測定を行う能力を提供します。
コンパイル時の設定
SIFTR のデフォルト動作は、IPv4 TCP/IP パケットをキャプチャすることです。
次を非コメント化して再コンパイルすることによって IPv4 と IPv6 をサポート
するための SIFTR を設定することができます:
CFLAGS+=-DSIFTR_IPV6
これは、<sys/modules/siftr/Makefile> にあります。
IPv4 だけ (デフォルト) のモードで、標準のドット付き 10 進記法 (例えば、
"136.186.229.95") は、ログ記録のために IPv4 アドレスを書式化するために使
用されます。IPv6 モードで、標準のドット付き 10 進記法は、IPv4 アドレスを
書式化するために使用され、標準のコロンで区切られた 16 進記法 (RFC 4291 参
照) は、ログ記録のために IPv6 アドレスを書式化するために使用されます。
SIFTR は、IPv6 アドレスを書式化するために圧縮復元された記法を使用すること
に注意してください。例えば、アドレス "fe80::20f:feff:fea2:531b" は、
"fe80:0:0:0:20f:feff:fea2:531b" としてログ記録されます。
実行時の設定
SIFTR は、ユーザ空間に設定変数をエクスポートするために sysctl(8) インタ
フェースを利用します。次の変数が利用可能です:
net.inet.siftr.enabled
モジュールが測定を実行するかどうかを制御します。デ
フォルトで、値は、モジュールが任意の測定値も取らない
ことを意味する、0 に設定されます。0 に設定された
net.inet.siftr.enabled でロードされたモジュールを得る
ためには、net.inet.siftr.enabled が 1 に設定されると
きだけ、パケットフィルタリングフックが挿入されるよう
に、ネットワークスタックの性能に影響されません。
net.inet.siftr.ppl
与えられた TCP 接続のための着信/発信パケットが接続の
ために生成されるログメッセージをどのくらいもたらすか
を制御します。デフォルトで、値は、モジュールがすべて
の TCP 接続のあらゆるパケットに対してメッセージをログ
記録することを意味する、1 に設定されます。値は、範囲
[1,2^32] の任意の整数を設定でき、モジュールが有効にさ
れている間でも、いつでも変更することができます。
net.inet.siftr.logfile
モジュールがログメッセージを書き込むファイルのパスを
制御します。デフォルトで、ファイル /var/log/siftr.log
が使用されます。モジュールが有効にされている間でも、
いつでも、パスを変更することができます。
net.inet.siftr.genhashes
ハッシュが SIFTR によって見られる各 TCP パケットのた
めに生成されるかどうかを制御します。デフォルトで、値
は、ハッシュが生成されないことを意味する、0 に設定さ
れます。ハッシュは、特定のログメッセージの生成の引き
金となった TCP パケットを相互に関連付けるために役に立
ちますが、それらを計算することは、追加のコンピュータ
のオーバヘッドを速いパスに加えます。訳注: 意味不明。
ログ形式
代表的な SIFTR ログファイルは、3 つの異なったタイプのログメッセージを含み
ます。すべてのメッセージは、平板な ASCII テキストで書き込まれます。
注意: このセクションの例のログメッセージの "\" 表現は、行の継続を示してい
て、実際のログメッセージの一部ではありません。
最初のログメッセージのタイプは、モジュールが有効にされるとき、ファイルに
書き込まれ、実行しているカーネルからデータの収集を開始します。下記のテキ
ストは、例のモジュールがログを有効にすることを示しています。フィールド
は、システムに関する何らかの基本情報について説明している、タブで区切られ
たキーと値の組です。
enable_time_secs=1238556193 enable_time_usecs=462104 \
siftrver=1.2.2 hz=1000 tcp_rtt_scale=32 \
sysname=FreeBSD sysver=604000 ipmode=4
フィールドの説明は、次の通りです:
enable_time_secs
UNIX 基準時点からの秒単位のモジュールが有効にされた時
間。
enable_time_usecs
enable_time_secs 以来のマイクロ秒単位のモジュールが有
効にされた時間。
siftrver SIFTR のバージョン。
hz 1 秒毎の tick (刻) 単位のカーネルの tick レート。
tcp_rtt_scale
平滑化した RTT の見積りスケールファクタ。
sysname オペレーティングシステム名。
sysver オペレーティングシステムのバージョン。
ipmode コンパイル時に定義される IP モード。"4" の ipmode
は、IPv6 がサポートされず、IP アドレスが通常のドット
付き 4 つ組形式でログインされることを意味します。"6"
の ipmode は、IPv6 がサポートされ、"コンパイル時の設
定" サブセクションで説明されるように、IP アドレスが
ドット付き 4 つ組または 16 進数形式でログインされるこ
とを意味します。
ログメッセージの 2 番目のタイプは、データログメッセージが生成されるとき、
ファイルに書き込まれます。下記のテキストは、IPv4 TCP/IP パケットによって
引き金となった例のデータログを示しています。データは、書式化された CSV で
す。
o,0xbec491a5,1238556193.463551,172.16.7.28,22,172.16.2.5,55931, \
1073725440,172312,6144,66560,66608,8,1,4,1448,936,1,996,255, \
33304,208,66608,0,208,0
フィールドの説明は、次の通りです:
1 ログメッセージの引き金となったパケットの方向。入力の
ための "i" または出力のための "o" のいずれかです。
2 ログメッセージの引き金となったパケットのハッシュ。
3 ログメッセージの引き金となったパケットが、pfil(9)
フック関数によって処理された、UNIX 基準時点からの秒と
マイクロ秒単位の時間。
4 ドット付き 4 つ組 (IPv4 パケット) またはコロンで区切
られた 16 進数 (IPv6 パケット) 記法での、ローカルホス
トの IPv4 または IPv6 アドレス。
5 ローカルホストが通信している TCP ポート。
6 ドット付き 4 つ組 (IPv4 パケット) またはコロンで区切
られた 16 進数 (IPv6 パケット) 記法での、外部ホストの
IPv4 または IPv6 アドレス。
7 外部ホストが通信している TCP ポート。
8 バイト単位のフローのための遅く開始した閾値。
9 バイト単位のフローのための現在の混雑状態のウィンド
ウ。
10 バイト単位のフローのための現在の帯域幅で制御された
ウィンドウ。
11 バイト単位のフローのための現在の送信ウィンドウ。ポス
ト scaled 値は、unscaled 値が、報告される時間の間に初
期のハンドシェイク (最初のわずかなパケット) の間を除
いて、報告されます。
12 バイト単位のフローのための現在の受信ウィンドウ。ポス
ト scaled 値は、常に報告されます。
13 送信ウィンドウのための現在のウィンドウのスケールファ
クタ。
14 受信ウィンドウのための現在のウィンドウのスケールファ
クタ。
15 <netinet/tcp_fsm.h> で定義されるような TCP の有限な状
態マシンの現在の状態。
16 バイト単位のフローのための最大のセグメントサイズ。
17 TCP_RTT_SCALE * HZ の単位のフローのための現在の平滑化
した RTT 見積り、ここで、TCP_RTT_SCALE は、tcp_var.h
に定義されていて、HZ は、カーネルの tick タイマです。
秒単位の RTT を取得するために、TCP_RTT_SCALE * HZ で
割られます。TCP_RTT_SCALE と HZ は、有効にされたログ
メッセージで報告されます。
18 有効にされた SACK インジケータ。SACK が有効にされるな
ら、1、そうでなければ、0 です。
19 フローのための TCP フラグの現在の状態。様々なフラグの
情報については、<netinet/tcp_var.h> を参照してくださ
い。
20 HZ の単位のフローのための現在の再送タイムアウトの長
さ、ここで、HZ は、カーネルの tick タイマです。秒単位
のタイムアウトの長さを取得するるために HZ で割られま
す。HZ は、有効にされたログメッセージで報告されます。
21 バイト単位のソケット送信バッファの現在のサイズ。
22 ソケット送信バッファの現在のバイト数。
23 バイト単位のソケット受信バッファの現在のサイズ。
24 ソケット受信バッファの現在のバイト数。
25 送信中 (in-flight) 応答されていない現在のバイト数。
SACK を通して肯定応答されたバイトは、このカウントから
排除されません。
26 再構築キューのセグメントの現在の番号。
27 接続のための flowid。警告: それが設定されていないと
き、有効な flowid またはデフォルト値を表している
'0'。使用されている実際のネットワークインタフェース
カードとドライバを見ずに区別する簡単な方法は、ありま
せん。
28 接続のための flow タイプ。flow タイプは、flowid を生
成するために、どのようなプロトコルフィールドがハッ
シュされるかを定義します。完全なリストは、
M_HASHTYPE_* の下の sys/mbuf.h で利用可能です。
ログメッセージの 3 番目のタイプは、モジュールが無効にされるとき、ファイル
に書き込まれ、実行しているカーネルからデータを収集することを停止します。
下記のテキストは、ログを無効にされた例のモジュールを示しています。フィー
ルドは、モジュールがごく最近有効にされてから操作に関する統計を提供してい
る、タブで区切られたキーと値の組です。
disable_time_secs=1238556197 disable_time_usecs=933607 \
num_inbound_tcp_pkts=356 num_outbound_tcp_pkts=627 \
total_tcp_pkts=983 num_inbound_skipped_pkts_malloc=0 \
num_outbound_skipped_pkts_malloc=0 num_inbound_skipped_pkts_mtx=0 \
num_outbound_skipped_pkts_mtx=0 num_inbound_skipped_pkts_tcb=0 \
num_outbound_skipped_pkts_tcb=0 num_inbound_skipped_pkts_icb=0 \
num_outbound_skipped_pkts_icb=0 total_skipped_tcp_pkts=0 \
flow_list=172.16.7.28;22-172.16.2.5;55931,
フィールドの説明は、次の通りです:
disable_time_secs
UNIX 基準時点からの秒単位のモジュールが無効にされた時
間。
disable_time_usecs
disable_time_secs からのマイクロ秒単位のモジュールが
無効にされた時間。
num_inbound_tcp_pkts
ネットワークスタックを上方に横断する TCP パケットの
数。これは、SIFTR が有効にされた期間に、着信の TCP パ
ケットのみを含んでいます。
num_outbound_tcp_pkts
ネットワークスタックを下方に横断する TCP パケットの
数。これは、SIFTR が有効にされた期間に、発信の TCP パ
ケットのみを含んでいます。
total_tcp_pkts
num_inbound_tcp_pkts と num_outbound_tcp_pkts の合
計。
num_inbound_skipped_pkts_malloc
失敗した malloc() 呼び出しのために、処理されなかった
着信パケットの数。
num_outbound_skipped_pkts_malloc
失敗した malloc() 呼び出しのために、処理されなかった
発信パケットの数。
num_inbound_skipped_pkts_mtx
失敗したパケット処理キューへのパケットの追加のため
に、処理されなかった着信パケットの数。
num_outbound_skipped_pkts_mtx
失敗したパケット処理キューへのパケットの追加のため
に、処理されなかった発信パケットの数。
num_inbound_skipped_pkts_tcb
失敗したパケットに関連している TCP 制御ブロックの検索
のために、処理されなかった着信パケットの数。
num_outbound_skipped_pkts_tcb
失敗したパケットに関連している TCP 制御ブロックの検索
のために、処理されなかった発信パケットの数。
num_inbound_skipped_pkts_icb
失敗したパケットに関連している IP 制御ブロックの検索
のために、処理されなかった着信パケットの数。
num_outbound_skipped_pkts_icb
失敗したパケットに関連している IP 制御ブロックの検索
のために、処理されなかった発信パケットの数。
total_skipped_tcp_pkts
すべてのスキップされたパケットカウンタの合計。
flow_list モジュールがロードされてから生成されるデータログメッ
セージの引き金となった TCP フローの CSV リスト。CSV
リストの各フローエントリは、"local_ip;local_port
foreign_ip;foreign_port" として書式化されます。リスト
にエントリがない (すなわち、データログメッセージが生
成されなかった) なら、値は、空白となります。リストに
少なくとも 1 つのエントリがあるなら、後続するコンマ
は、常に存在します。
total_tcp_pkts - total_skipped_tcp_pkts と同じであるべきサイクルを有効に
するか、または無効にするモジュールのためのログファイル中に見つけられる
データログメッセージの合計数。
実装に関する注
SIFTR は、pfil(9) インタフェースを使用してネットワークスタックに接続しま
す。現在の生まれ変わりでは、ネットワークスタックの IP 層でパケットを見る
ことを意味する、AF_INET/AF_INET6 (IPv4/IPv6) pfil(9) フィルタリングポイン
トに接続します。これは、TCP 層によって処理される前に、スタックに着信する
TCP パケットがインタセプトされることを意味します。スタックから発信される
パケットは、TCP 層によって処理された後に、インタセプトされます。
下記のダイヤグラムは、SIFTR がどのようにそれ自体をスタックに挿入するかを
図解しています。
----------------------------------
Upper Layers
----------------------------------
^ |
| |
| |
| v
TCP in TCP out
----------------------------------
^ |
|________ _________|
| |
| v
---------
| SIFTR |
---------
^ |
________| |__________
| |
| v
IPv{4/6} in IPv{4/6} out
----------------------------------
^ |
| |
| v
Layer 2 in Layer 2 out
----------------------------------
Physical Layer
----------------------------------
SIFTR は、ディスクへのデータの書き込みを管理するために alq(9) インタ
フェースを使用します。
一見したところでは、利用者は、SIFTR が個々の TCP パケットから情報を抽出し
ていると誤って考えるかもしれません。これは、そうではありません。SIFTR
は、そのフローのための TCP 制御ブロックの状態のダンプの引き金となるシステ
ムから起こる各 TCP フローのための (着信と発信) の TCP パケットイベントを
使用します。PPL は、1 に設定された状態で、私たちはフローパケットがシステ
ムに入るか、または出るのと同じくらいの頻度で各 TCP フローの制御ブロック状
態を抽出することは有効です。例えば、PPL を 2 に設定すると、標本抽出率は、
半分にされます、すなわち、あらゆる 2 番目のフローパケット (着信または発
信) によって、制御ブロック状態のダンプを引き起こします。
SIFTR が、tcpdump(1) のようなパケットキャプチャ (捕獲) ツールの必要性を取
り除かないので、個々のパケットの問い合わせに対して制御ブロックの問い合わ
せの区別は、重要です。SIFTR によって、利用者は、(tcpdump(1) のようなツー
ルを使用してキャプチャされる) ワイヤ上に見るものと、興味があるフローに対
応する TCP 制御ブロックの変更の間の原因と影響 (cause-and-affect) の関係を
相互に関連付けて、観測することができます。したがって、完全な絵のようにつ
なぎ合わせる必要なデータを集めるのに SIFTR と tcpdump(1) のようなツールを
使用するのは、役に立ちます。それ自体でいずれかのツールを使用することは、
必要なデータのすべてを提供できません。
TCP 制御ブロックを問い合わせるために必要な結果として、接続のライフサイク
ルの間の特定のパケットは、SIFTR ログメッセージの引き金となることができま
せん。初期のハンドシェイクは、制御ブロックの存在なしで行われ、最終的な
ACK は、接続が TIMEWAIT 状態であるとき、交換されます。
SIFTR は、ネットワークスタックを横断するパケットに導入された遅延を最小と
なるように設計されました。この設計は、高度に最適化され、パケットを保持し
て、これらの詳細を実際の処理とログ記録のための別のスレッドに渡している間
に必要な最小の詳細を抽出する最小のフック関数を要求しました。
このマルチスレッド化された設計は、スレッドの動作の間に共有されたデータ構
造にアクセスするとき、いくつかの競合問題を持ち込みます。フック関数が構造
体の詳細を認識するとき、最初に、排他的なロックを獲得しなければなりませ
ん。同様に、処理スレッドが構造体から詳細を読み込もうとするとき、そうする
ために排他的なロックも獲得しなければなりません。1 つのスレッドがロックを
保持するなら、それを取得できる前に、他方は、待た (ウェートし) なければな
りません。これは、カーネルのパケット処理コードパスに何らかの追加の境界の
遅延を持ち込みます。
ある場合には (例えば、少ない記憶、接続の終了)、SIFTR pfil(9) フック関数に
入る TCP パケットは、生成されるログメッセージの引き金となりません。SIFTR
は、"スキップされたパケット" としてこの効果を言及します。SIFTR は、たと
え、それらが、データログメッセージの引き金となることが成功できなくても、
常にパケットがスタックを通して継続できることを確実にすることに注意してく
ださい。したがって、SIFTR は、ネットワークスタックを横断する TCP/IP パ
ケットのための少しのパケットの損失も起こりません。
重要な振る舞い
モジュールが有効にされる間のログファイルのパスの変更の振る舞いは、次の通
りです:
1. 書き込みのために新しいファイルのパスをオープンすることを試みます。こ
れが失敗するなら、パスの変更は、失敗し、既存のパスが、引続き使用され
ます。
2. 新しいパスは、有効で、成功してオープンされたと仮定します:
- すべての保留中 (pending) のログメッセージを古いファイルのパスに
フラッシュします。
- 古いファイルのパスをクローズします。
- アクティブなログファイルのポインタを新しいファイルのパスを指すよ
うにスイッチします。
- 新しいファイルにログ記録を開始します。
保留中のログメッセージを古いファイルにフラッシュし、新しいファイルにログ
記録を開始する間の期間に、新しいログメッセージは、生成され、バッファリン
グされます。新しいファイルに書き込む準備ができるとすぐに、蓄積されたログ
メッセージは、ファイルに書き込まれます。
使用例
モジュールの動作を有効にするには、root として次のコマンドを実行します:
sysctl net.inet.siftr.enabled=1
1 つのログメッセージが 1 つの接続あたり 10 の TCP パケット毎のために生成
されるような、ログメッセージの精度を変更するには、root として次のコマンド
を実行します: sysctl net.inet.siftr.ppl=10
ログファイル位置を /tmp/siftr.log に変更するには、root として次のコマンド
を実行します: sysctl net.inet.siftr.logfile=/tmp/siftr.log
関連項目
tcpdump(1), tcp(4), sysctl(8), alq(9), pfil(9)
謝辞
このソフトウェアの開発は、Community Foundation Silicon Valley の Cisco
University Research Program Fund と FreeBSD Foundation からの補助金によっ
て部分的に可能となりました。
歴史
SIFTR は、FreeBSD 7.4 と FreeBSD 8.2 ではじめて登場しました。
SIFTR は、Community Foundation Silicon Valley の Cisco University
Research Program Fund からの補助金によって部分的に可能となった、Advanced
Internet Architectures, Melbourne, Australia のために Swinburne Univer
sity of Technology の Centre で NewTCP 研究プロジェクトで、仕事をしている
間に、Lawrence Stewart と James Healy によって、2007 年に最初にリリースさ
れました。その他の詳細については、次で利用可能です:
http://caia.swin.edu.au/urp/newtcp/
SIFTR v1.2.x の取り組みは、"Enhancing the FreeBSD TCP Implementation" プ
ロジェクト 2008-2009 の一環として FreeBSD 財団によって資金提供されまし
た。その他の詳細については、次で利用可能です:
http://www.freebsdfoundation.org/
http://caia.swin.edu.au/freebsd/etcp09/
作者
SIFTR は、Lawrence Stewart <lstewart@FreeBSD.org> と James Healy
<jimmy@deefa.com> によって書かれました。
このマニュアルページは、Lawrence Stewart <lstewart@FreeBSD.org> によって
書かれました。
バグ
現在の知られている制限といくつかの関連する回避策は、以下に概説されます:
- スレッドの動作の間に情報を渡すために使用される内部のキューは、現在、
バインドされていません。これによって、SIFTR は、爆発的なネットワーク
トラフィックに対処することができますが、処理しているスレッドがパケッ
トレートを維持することができないなら、持続している高い 1 秒あたりのパ
ケットのトラフィックは、カーネルメモリの消耗を引き起こすかもしれませ
ん。
- また pfil(9) フレームワーク、例えば、dummynet(4), ipfw(8), pf(4) を利
用する他のモジュールを実行するマシンで SIFTR を使用するなら、モジュー
ルをロードする順序は、重要です。利用者は、SIFTR がそれらを "見て、"
処理する前に、TCP パケットが任意の必要な操作も受けることを確実にすよ
うに、最初に他のモジュールを kldload するべきです。
- SIFTR が witness(4) サポートでコンパイルされたカーネルで有効にされる
とき、witness(4) によって報告された pfil(9) ミューテックスと tcbinfo
TCP ロックの間で知られていて、無害なロック順序逆転の警告があります。
- 利用者がデータを得たい TCP フローをフィルタリングする方法はありませ
ん。後処理は、関心がある特定のフローに属すデータを分離するために必要
です。
- モジュールは、ログファイルのパスの削除を検出しません。新しいログメッ
セージは、モジュールがファイルを使用するように設定される間に、SIFTR
によって使用されているログファイルが、削除されるなら、単に失われま
す。net.inet.siftr.logfile 変数を使用する新しいログファイルに切り替え
ることは、新しいファイルを作成して、ログメッセージを再びディスクに書
き込み始めることができます。新しいログファイルのパスは、パスから削除
されたファイルまで異ならなければなりません。
- コード中で使用されるハッシュテーブルは、65536 のフローを保持するため
に大きさです。チェーン構造がハッシュテーブル構造内で衝突を取り扱うた
めに使用されるので、これは、厳しい制限ではありません。しかしながら、
私たちは、性能 (と、したがって、モジュールのパケット処理性能) を検索
するハッシュテーブルが、サイクルのアプローチを有効/無効にし、65536 を
上回るモジュールで扱われたユニークなフローの数として指数関数的な方法
でデグレードされると (他のハッシュテーブル性能データとの類推に基づい
て) 疑います。
- フローハッシュテーブルで実行されるガーベージコレクションは、ありませ
ん。現在、それをフラッシュする唯一の方法は、SIFTR を無効にすることで
す。
- PPL 変数は、フック関数で受信された合計パケットではなく、処理している
スレッドにそれを行うパケットに適用されます。パケットは、PPL 変数が適
用される前に、スキップされます、それは、ログメッセージの引き金となる
ことでわずかな不一致となるかもしれないことを意味します。例えば、PPL
が 10 に設定されていたなら、最後のログメッセージから 8 番目のパケット
は、スキップされ、11 番目のパケットは、実際に生成されるログメッセージ
の引き金となります。これは、CAIA 技術報告書 070824A でさらに深く議論
されています。
- これを書いている時点で、パケットをインタセプトするために TCP 層に接続
する簡単な方法はありませんでした。IP 層のフックポイントの SIFTR の使
用は、すべての IP トラフィックが、マイナですが、それでも同様に、TCP
でないパケットのためにシステムで不要なパケット遅延と処理のオーバヘッ
ドを取り入れる、SIFTR pfil(9) フック関数によって処理されることを意味
します。また、IP 層でのフッキングは、データ収集の観点から望ましくあり
ません。スタックを横断するパケットは、インタセプトされ、同じくらい正
確に着信イベントと対応する TCP 制御ブロックの間の原因と影響 (cause
and-affect) の関係を観測できないことを意味する、TCP 層によって処理さ
れる「前に」、ログメッセージの生成を引き起こします。理想としては、
SIFTR は、パケットが TCP 層によって処理された後に、それらをインタセプ
トするべきです、すなわち、tcp_input() によって処理された後に、スタッ
クから上がってくるパケットをインタセプトし、tcp_output() によって処理
された後に、スタックに落されるパケットをインタセプトします。現在の
コードは、着信イベントが、発信イベントの引き金となる傾向があり、原因
と影響 (cause-and-affect) を、同様に発信イベントの状態を捕獲すること
によって間接的に観測できるように、まだ満足できる精度を与えています。
- SIFTR によってログ記録された "inflight bytes" (飛行中のバイト) 値は、
受信ホストによって SACK されているバイトを考慮に入れません。
- パケットのハッシュ生成は、現在、IPv6 ベースの TCP パケットにはうまく
いきません。
- 圧縮された記法は、IPv6 アドレス表現には使用されません。これは、ログ出
力で必要とするより多くのバイトを消費します。
FreeBSD 11.2 March 18, 2015 FreeBSD 11.2