SSLStreamを使用して「大きな」データチャンク（1メガ）を（認証済みの）クライアントに送信する場合、通常のNetworkStreamを使用する場合よりもはるかに大きいパケットの断片化/分解が見られます。
クライアントで非同期読み取り（つまり、BeginRead（））を使用して、ReadCallbackは、最後のパケット（残りのデータ）まで、まったく同じサイズのデータチャンクで繰り返し呼び出されます。私が送信しているデータ（zipファイル）では、セグメントの長さはたまたま16363バイトです。注：受信バッファーはこれよりはるかに大きく、サイズを変更しても効果はありません
SSLは18Kb以下のチャンクでデータを暗号化することを理解していますが、SSLはTCPの上にあるため、SSLチャンクの数はTCPパケットの断片化とは関係がないと思いますか？
基本的に、データがクライアントによって完全に読み取られるまでに、標準のNetworkStream（両方ともローカルホスト上で！）を使用する場合よりも約20倍の時間がかかります。
私は何が欠けていますか？
編集：
SSLStreamの受信（または送信）バッファサイズが制限されているのではないかと思い始めています。同期読み取り（つまりSSLStream.Read（））を使用しても、読み取りを試みる前に待機する時間に関係なく、これ以上データが使用可能になることはありません。これは、受信バッファを16363バイトに制限する場合と同じ動作になります。基になるNetworkStreamのSendBufferSize（サーバー上）およびReceiveBufferSize（クライアント上）を設定しても効果はありません。