SslStream.read () возвращает с первым байтом один раз пакет

Я хочу прочитать пакеты из моего SslStream.

я отправляю пакеты с помощью websocket. Кроме того, эта функция запускается после завершения рукопожатия WS, поэтому она предназначена для чтения фреймов данных.

Это функция для чтения:

byte[] buffer = new byte[16 * 1024];
int read;
while (true) {
    read = input.Read(buffer, 0, buffer.Length);

    Console.WriteLine("Length: " + read + " Buffer: " + GetNumberOfSlotsUsed(buffer));

    if (read <= 0) {
        ...
    } else if (read < 3) {
        ...
    } else {
        ...
    }
}

как только я получаю пакет, это то, что печатается на консоли:

Length: 1 Buffer: 1
Length: 57 Buffer: 57

может быть проблема в этой функции, или это браузер, который отправляет пакеты?

Я использую "розетка.read () " функция в моем сервере Websocket написана на Java, и нет никаких проблем, поэтому это должен быть C# правильно?

правка #1:

код Javascript для отправки: 

var socket = new WebSocket(serviceUrl, protocol);
socket.onopen = function () {
    socket.send(omeString);
}
6
c# sockets websocket

3 ответов

для будущих людей, ищущих эту же самую проблему:

Я нашел статью, объясняющую, что это странное явление является особенностью.

это кажется странной вещью для вызова "функции"."В основном (как я понимаю) это изменение состояло в том, чтобы заставить SslStream читать и писать первый байт, а затем нажимать остальные. Лично я считаю, что это странная перемена. Немного странно заставлять несколько пакетов передачи. (Я полностью осознаю, что это может произойти, это просто странно принудительно дополнительный пакет поверх возможности того, что пакеты могут быть сегментированы.)

ссылка на статью

сообщение от нимб.Hex

When ran on machine updated with KB3147458, this output is produced:
BytesRead => 1
BytesRead => 40
BytesRead => 1
BytesRead => 40
BytesRead => 1
BytesRead => 40
BytesRead => 1
BytesRead => 40
BytesRead => 1
BytesRead => 40

When ran on a machine without KB3147458, this output is produced:
BytesRead => 41
BytesRead => 41
BytesRead => 41
BytesRead => 41
BytesRead => 41

сообщение от Илья Jerebtsov

Я бы предположил, что это более конкретно вызвано KB3142037, это обновление для системы безопасности MS16-065. Вопросы здесь и несколько решения подробно изложены в https://support.microsoft.com/en-us/kb/3155464 . Есть реестр ключи, которые можно использовать для отключения этой "функции".

сообщение от Microsoft:

Привет Нимб.Гекс, да, Айлия права. Это изменение поведения сделано для обновления безопасности для MS16-065. Больше деталей вокруг доступные изменения в https://support.microsoft.com/en-us/kb/3155464 . Я решение это, как "по Дизайн " С Уважением, Химадри

3

TCP не позволяет читателю определить, какие размеры куска были отправлены. Эта информация отсутствует на записи. Протокол приложения должен иметь возможность обрабатывать тот факт, что данные могут и будут поступать произвольными кусками.

1

Это довольно старый вопрос, но все же хотелось бы внести свой вклад.

эта проблема возникает, если вы войдете в свой поток с ТЛС(TLS в 1 если быть точным). Если вы следовали руководству microsoft(https://msdn.microsoft.com/en-us/library/system.net.security.sslstream(v=vs. 110).aspx) вы, вероятно, используете следующий код для аутентификации.

поток.AuthenticateAsServer (serverCertificate, false, SslProtocols.Tls, false);

Как пояснили в https://support.microsoft.com/en-us/kb/3155464 из-за уязвимости в TLS 1 поток сначала получит 1 байт, а затем остальные байты. Чтобы противостоять этому, программа должна иметь маркер, чтобы определить, когда сообщение останавливается .

другой способ-использовать TLS 1.2, вы можете использовать stream.AuthenticateAsServer (serverCertificate, false, SslProtocols.Tls12, false);

используя это, вы получите полное сообщение.

0