протокол прикладного уровня - разный размер пакетов

Question

Предположим, что я определил свой собственный протокол уровня приложений поверх TCP для мгновенных сообщений. Я использовал структуру пакетов для сообщений. Поскольку я использую симметричное (AES) и асимметричное (RSA) шифрование, я получаю другой размер пакета для разных типов сообщений. Теперь на мои вопросы.

Как читать из сокета, что я получаю один пакет прикладного уровня? Какой размер следует указывать?

Заранее спасибо.

У меня есть два подхода в виду.

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

2. Прочитайте максимальный размер пакета из потока. Проверьте фактический размер полученных байтов и определите, какой тип сообщения он был.

Теперь более общий вопрос. Должен ли я предоставлять метаданные, такие как размер пакета, метод шифрования, приемник, отправитель и т. Д.? Если да, должен ли я также шифровать эти метаданные?

Answer 1

Помните, что при чтении из сети TCP не гарантируется количество байтов, полученных в этот момент времени. То есть клиент может отправить полный пакет в свои write(), , но, что не означает, что ваш read() получит такое же количество байтов. Таким образом, вашему коду всегда нужно будет прочитать количество байтов из сети, затем проверить (на основе накопленных данных), что вы получили необходимое количество байтов, а затем вы можете проверить пакет (тип, содержимое, и т.п) оттуда.

В некоторых приложениях используются кодировщики/декодеры конечных автоматов и буферы фиксированного размера для чтения/записи их сетевых данных; другие приложения динамически выделяют буферы, достаточно большие для «полного пакета», а затем продолжают чтение байтов из сети до тех пор, пока не будет заполнен буфер «полный пакет». Какой подход вы используете, зависит от вашего приложения. Таким образом, размер, который вы используете для чтения, не так важен, как ваш код гарантирует, что он получил полный пакет.

Что касается ли вы должны зашифровать дополнительные метаданные, которые в значительной степени зависит от модели угроз (т.е. какие угрозы ваш протокол хочет защититься от, какие гарантии ваш протокол должен предоставлять своим клиентам/пользователям). Нет простого способа ответить на этот вопрос без дополнительного контекста/деталей.

Надеюсь, это поможет!