Description
See discussion here: #51060
Currently we do two things:
(1) Add a fixed FrameOverhead (now 64 bytes, previously 32) to the input size when allocating a buffer to encrypt into;
(2) Later, in SslStreamPal.EncryptMessage, we will detect a buffer that is too small and allocate a new, temporary buffer to use instead.
This results in two problems:
(1) We are often allocating more than we need to, since the actual header/trailer size is usually less than 64 bytes.
(2) If 64 bytes is not enough, we will silently fall back to a much less performant path, i.e. allocating lots of unpooled buffers. We saw this previously when FrameOverhead was 32 bytes, which is why we changed it to 64.
We know the exactly header and trailer size before we actually do the encryption. We should be able to allocate the exact size needed and remove the unperformant fallback in SslStreamPal.EncryptMessage. This is slightly complicated by renegotiation, but we should be able to just make this work.