SSLStream経由でデータを送信するときのパケットの断片化

Question

SSLStreamを使用して（大量の）データ（1メガ）を（すでに認証された）クライアントに送信すると、表示されるパケットの断片化/解体はFAR通常のNetworkStreamを使用している場合

クライアント（つまりBeginRead（））で非同期読み取りを使用すると、ReadCallbackはと全く同じサイズのデータ​​チャンク（データの残り）までで繰り返し呼び出されます。送信しているデータ（zipファイル）では、セグメントの長さは16363バイトになります。 注：私の受信バッファは、これよりもはるかに大きいであり、それは大きさの変化することは何の効果

を持っていない私は、SSLが18KBよりも大きなチャンクでデータを暗号化しませんが、SSLはTCPの上に座っているので、私は考えていないだろうことを理解しますSSLチャンクの数がTCPパケットの断片化に関連することはありますか？

基本的に、データが完全に標準NetworkStreamを持つよりも、クライアントによって読み取られるように、約20倍の時間がかかっている（ローカルホスト上の両方！）

私は何をしないのですか？

---

EDIT：

私はSSLStreamの受信（または送信）バッファサイズが限られていることを疑うに始めています。同期読み取り（SSLStream.Read（））を使用しても、読み取りを試みる前にどれくらい待っているかに関係なく、これ以上のデータは使用できなくなります。これは、受信バッファを16363バイトに制限した場合と同じ動作になります。下にあるNetworkStreamのSendBufferSize（サーバー上）とReceiveBufferSize（クライアント上）を設定しても効果はありません。

Answer 1

これは、民間のメンバーによって定義されたSslStreamによって適用されるパケット・データ・サイズ制限のようになります。

SSLStream._SslState.MaxDataSize 

私はこの制限が適用された理由を理解するために苦労してる、またはそれを変更することができるならば、質問に答えましたhere