少なくとも256バイトのSO_RCVBUFはパケットの保存を許可されていませんか?

少なくとも256バイトのSO_RCVBUFはパケットの保存を許可されていませんか?

man mount

SO_RCVBUF

最大ソケット受信バッファをバイト単位で設定または取得します。値がsetockopt(2)を使用して設定されている場合、カーネルは値を2倍に(長くオーバーヘッドするためのスペースを確保するために)増加し、2倍の値はgetsockopt(2)によって返されます。デフォルトは /proc/sys/net/core/rmem_default ファイルで設定され、最大許容値は /proc/sys/net/core/rmem_max ファイルで設定されます。このオプションの最小(二重)値は256です。

しかし、私の考えでは、そのようなバッファはどんなパケットも入れることができないと思います。

LinuxでデフォルトのUnixソケットバッファサイズとして使用できる値は何ですか?

...

パケットあたりのオーバーヘッドはstruct sk_buffとstruct skb_shared_infoの組み合わせなので、これらの構造の正確なサイズによって異なります(ソートのためにわずかに丸められます)。たとえば、上記の64ビットカーネルでは、パケットあたりのオーバーヘッドは576バイトです。

上記の内容は正しいですか?カーネルが最小ソケットバッファサイズを256に強制する妥当な理由はありますか?

ベストアンサー1

以前に質問した内容を見る「SO_RCVBUFの最小値はいくらですか?」そしてこのネットワークプログラミングガイド、あなたの疑いが正しいようです。 UDPおよびIPパケットは、パケットを格納するのに十分なスペースがないため自動的に破棄され、(私が知る限り)最小転送ウィンドウサイズがバッファより大きいため、TCP接続は機能しません。何も受けられません。

最小ソケットバッファサイズがなぜそんなに小さいのかは、おそらくドキュメントの歴史的遺物です。見ているLinuxソースv4.0(linux/include/net/sock.h)、実際の最小サイズははるかに大きいようです(2048 + sk_buffのソートサイズ)非常に長い時間。私の考えでは、記録された最小値がそんなに低い理由は、ATMセルパケットへの生のアクセスを許可するためであるようです。48~53バイトしかし、これは単なる推測です。

おすすめ記事