Quando si utilizza un SSLStream per inviare una "grande" porzione di dati (1 meg) a un client (già autenticato), la frammentazione/il disassemblaggio dei pacchetti che sto vedendo è FAR maggiore di quando si utilizza un normale NetworkStream.Frammentazione del pacchetto durante l'invio di dati via SSLStream
Utilizzando una lettura asincrona sul client (cioè BeginRead()), il ReadCallback è ripetutamente detto con esattamente lo stesso pezzo dimensione dei dati entro il pacchetto finale (il resto dei dati). Con i dati che sto inviando (è un file zip), i segmenti sono lunghi 16363 byte. Nota: Il mio buffer di ricezione è molto più grande di questo e cambiare la sua dimensione non ha alcun effetto
Capisco che SSL crittografa i dati in blocchi non più grande di 18Kb, ma dal momento che SSL si trova sulla cima del protocollo TCP, non penserebbe che il numero di blocchi SSL avrebbe rilevanza per la frammentazione dei pacchetti TCP?
In sostanza, il dato è in corso circa 20 volte più a lungo di essere pienamente leggere da parte del cliente che con uno standard NetworkStream (entrambi su localhost!)
Che cosa mi manca?
EDIT:
Sto cominciando a sospettare che la ricevono (o inviare) dimensione del buffer di uno SslStream è limitata. Anche se utilizzo le letture sincrone (ad esempio SSLStream.Read()), non ci sono più dati disponibili, a prescindere dal tempo che aspetto prima di tentare di leggere. Questo sarebbe lo stesso comportamento come se dovessi limitare il buffer di ricezione a 16363 byte. L'impostazione del valore SendBufferSize (sul server) di NetworkStream sottostante e ReceiveBufferSize (sul client) non ha alcun effetto.
Stai parlando di frammentazione IP o di quante letture devi eseguire sul ricevitore? –
Il numero di letture effettuate – Ive
Come si invia? Se non si utilizzano i buffer attorno agli stream SSL, è possibile ottenere un'esplosione di dati superiore a 40x a causa della codifica di un byte alla volta nel proprio record SSL. – EJP