В нашем приложении сотрудники используют свои телефоны для регистрации действий в рамках компании. В среднем они используют 0,5–2 ГБ данных в месяц.
Я пытаюсь встроить в наше приложение функциональность, которая регистрирует использование данных, чтобы мы могли отправить их обратно в бизнес в виде заявления о расходах.
В приведенном ниже примере кода, как я могу определить, сколько полосы пропускания / данных было использовано устройством, отправляющим сообщение через WebSocket?
var ws = new WebSocket('ws://host.com/path');
ws.onopen = () => {
ws.send('something');
};



![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)


Предполагая, что вы можете идентифицировать сеанс клиента по уникальному IP-адресу (только сеанс, им не всегда нужен этот IP-адрес), я бы рекомендовал использовать инструменты более низкого уровня, которые больше подходят для вашего приложения, в частности коллекторы NetFlow.
NetFlow измеряет «диалог» TCP путем записи IP src, dst и пропускной способности за определенный промежуток времени. Вы можете включить это в ядре Linux или непосредственно в каком-либо сетевом оборудовании. Затем вам понадобится программа для сбора и хранения данных.
Предполагая, что у вас включен сбор NetFlow и вы можете идентифицировать сеансы по IP-адресу, вы можете сделать следующее:
Причина, по которой я предлагаю это вместо какого-то решения для пользовательского пространства, которое может подсчитывать полученные байты (что вы, вероятно, могли бы сделать довольно легко), заключается в том, что библиотеки и ядро абстрагируют много данных. Ядро обрабатывает стек TCP (включая повторную отправку пропущенных пакетов), библиотеки обрабатывают квитирование / шифрование TLS, а также рукопожатие WebSocket. Все эти данные засчитываются в использованные пользователем данные. То, как пользователи используют приложение, повлияет на то, сколько из этих служебных данных будет отправлено (постоянно открывать / закрывать его, а не оставлять открытым).
Версия NetFlow для Google Cloud называется VPC Flow и предоставляет ту же общую идею. cloud.google.com/vpc/docs/using-flow-logs
Зависит от того, какая точность вам нужна. Самый простой способ - это «подклассифицировать» существующие сокеты примерно так:
var inboundTraffic = 0;
var outboundTraffic = 0;
function NewWebSocket(addr) {
var ws = new WebSocket(addr);
var wsSend = ws.send;
ws.send = function(data) {
outboundTraffic += data.length;
return wsSend.call(ws,data);
}
ws.addEventListener("message", function (event) {
inboundTraffic += event.data.length;
});
return ws;
}
Просто и почти ничего не стоит.
Но разве это не просто измерение размера отправленных данных? Как насчет размера фактического запроса / рукопожатий и т. д.? Я предпочитаю этот ответ из-за его простоты, но меня беспокоит точность. Нам нужно иметь точность не менее 95%, например если передается 2 ГБ, необходимо зарегистрировать минимум 1,9 ГБ. Возможна ли потеря 5% без записи фактического размера запроса? Сегодня днем я проведу более глубокое тестирование!
Отправка 200 байтов данных через приложение iOS через веб-сокет использует 8000 байтов мобильных данных. Накладные расходы - это очень много того, что необходимо измерить, поскольку они составляют примерно 97,5% использования данных.
@ jskidd3 Вы ошибаетесь насчет 200/8000. Пока не ясно, что означают эти волшебные «мобильные данные». В любом случае я реализовал собственные веб-сокеты в моем движке Sciter (sciter.com). Да, в каждом сообщении есть данные заголовка, но они минимальны. Все эти накладные расходы точно определены в спецификации WS.
Вот соответствующая часть спецификации WebSocket tools.ietf.org/html/rfc6455#section-5.6 - как видите, накладные расходы минимальны и могут быть точно рассчитаны.
Большое спасибо за это. Это странно, почему iOS сообщает о таком большом использовании ... Я попытаюсь разобраться, почему это может быть. Как вы думаете, можете ли вы использовать эти вычисления, чтобы изменить свой ответ, включив в него накладные расходы? Если вы это сделаете, я выберу лучший ответ, так как это гораздо лучший ответ.
Большое спасибо за ответ, Лиам. Полностью имеет смысл отслеживать эти данные на сервере и сравнивать их с IP от клиента. Мой единственный вопрос: мы используем Node JS в Google Cloud, поэтому не думайте, что мы можем использовать NetFlow, как вы предложили. Я пытаюсь найти похожее решение по мере набора текста. Может быть, вы могли бы направить меня по правильному пути?