-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Вопрос Что стабильнее: ESP8266 или 32?
- Автор темы YDen
- Дата начала
maddogmaycry
New member
Ну вот явно вы защищенных приложений не строили раз подобные предположения делаете.
Как я уже говорил, нужны конкретные примеры.
Вот например.
NXP'шный Desfire EV1, RFID, где запросы к карте не требуют шифрования, а вот при обмене непосредственными данными с карты и на карту оборачиваются через AES 128 битным ключём, кроме того требуется поддерживать сесионный ключ в актуальном режиме. Это обеспечивает промышленный уровень защиты, при этом не требуется шифровать все и вся.
Далее уже мой частный случай. UDP сервер примнимает соединение. Весь трафик ему не требуется шифровать, а вот критические части уже стоит. Экономия питания, ресурса микроконтроллера. Если я буду держать сессию, шифровать весь поток, то от Denide Of Service сервер я все равно не уберегу (это прерогатива сетевого оборудования), до кучи потрачу ресурс на постоянное шифрование.
Зачем?
Вот два частных случая.
Как я уже говорил, нужны конкретные примеры.
Вот например.
NXP'шный Desfire EV1, RFID, где запросы к карте не требуют шифрования, а вот при обмене непосредственными данными с карты и на карту оборачиваются через AES 128 битным ключём, кроме того требуется поддерживать сесионный ключ в актуальном режиме. Это обеспечивает промышленный уровень защиты, при этом не требуется шифровать все и вся.
Далее уже мой частный случай. UDP сервер примнимает соединение. Весь трафик ему не требуется шифровать, а вот критические части уже стоит. Экономия питания, ресурса микроконтроллера. Если я буду держать сессию, шифровать весь поток, то от Denide Of Service сервер я все равно не уберегу (это прерогатива сетевого оборудования), до кучи потрачу ресурс на постоянное шифрование.
Зачем?
Вот два частных случая.
UDP и соединение? Что-то Вы путаетесь в показаниях.
В UDP-протоколе нет понятия "соединение".
maddogmaycry
New member
Охх...UDP и соединение? Что-то Вы путаетесь в показаниях.
В UDP-протоколе нет понятия "соединение".
Вы в данном случае путаете понятия непосредственного протокола, и логики, которую можно создать на его основе.
Сам протокол не обеспечивает, но не отменяет факта создания логики, которая в том числе будет реализовывать соединение. Мне на пример TCP нет смысла использовать, так как все принципы кольцевания, очередей, проверки целостности пакета мне проще реализовать опираясь на примитивный UDP, но она будет заточена под мои задачи а не под универсальные типы что в итоге оказывает положительное влияние на производительность.
Да, именно соединение, и именно на UDP.
По сути соединение на TCP это сохранение состояния предидущих пакетов. Вот и все.
UDP сам по себе не хранит состояния, и не реализует из коробки гарантию доставки пакетов, но вы их можете реализовать сами, и вот пожалуйста - соединение.
Могу описать один из примеров на пальцах.
Один из атрибутов соединения является гарантированная доставка пакета.
Возьмем один поток данных где на каждый пакет нужно получить подтверждение от сервера (как это происходит с TCP).
Вы просто запоминаете порядковый номер пакета, его хеш сумму и отправляете серверу.
Включаете таймер (который вам необходим) и ждете ответа.
Таймер вышел, ответа нет? - Повторяем запрос. И так до тех пор пока от сервера не пришел ответ.
Вот вам и соединение которое вы установили по факту ответа от сервера, вернее вы реализовали самый основной базовый функционал, опираясь на который вы легко создадите полноценное соединение. ASK пакеты с некоторым интервалом, и вот, пожалуйста - соединение.
Аналогичным образом работают базовые принципы установления соединения через TCP.
Последнее редактирование:
Я ничего не путаю. Я знаю что в UDP нет понятия "соединение".
А путаете всех здесь Вы, называя какой-то протокол, ходящий поверх UDP, именем "UDP".
Если один протокол ходит поверх второго, то это не значит что второй протокол имеет свойства первого.
"Смешались в кучу люди кони...".
"Гарантированная доставка" не имеет никакого отношения к соединению. Это вещи абсолютно перпендикулярные друг другу, как мокрое и круглое.
Как видно из отквоченного - Вы совершенно не понимаете как работает и TCP тоже. Читайте доки - TCP работает совсем не так. Не надо тут позориться ещё и поучая кого-то.
TCP - это байт-ориентированный протокол, а не пакетно-ориентированный. Никаких "номеров пакета" там нет. Никакие хеш-суммы тоже нет надобности запоминать. И ждать какого-то ответа в TCP тоже не нужно. За первым сегментом можно сразу отправлять следующий, если позволяет окно.
Да и "запросов" и "ответов" в TCP тоже нет, как понятия. Как и неких мифических ASK-пакетов.
Вобщем - читайте учебники, рано Вам ещё взрослых дядь тут поучать.....
Последнее редактирование:
maddogmaycry
New member
Никого не поучал и "всех тут" в заблуждене не вводил - вел беседу с вами.
Просто хотел для вас на пальцах. И поверьте, о сетевых протоколах я имею достаточно обширные знания как теоретические так и практические, так как это моя основная сфера работы.
Вы хоть способны снизойти до уровня практических каких то примеров, или вы только общими понятиями общаетесь?
Давайте по пунктам. Может тогда поймем друг друга.
Вот вы писали:
Я вам ответил что это заблуждение.
Привел пример, но от вас каких то пояснений к возражениями не увидел. Зато увидел ловкие маневры по общей форме. Как то неуважительно по отношению к человеку который с вами как с человеком общается не находите?
Далее я поясняю как реализуется безопасность критически важных данных, и привел пример. Тот-же промышленный гигант использует данные варианты работы, но вы продолжаете общими формулировками указывать мне на какие то запутанности, что в UDP нет понятия соединения на прмиер.
Я начинаю говорить о том, что у меня в приложении UDP выполняет соединение, вы начинаете тыкать на мою некомпетентность, что я не верен в выводах и формулировках. Это какой то странны формат общения если честно.
Да, UDP крайне близок к IP, и из коробки на нем соединение не реализуется, но то что вы понимаете под словом соединение в отношении TCP/IP можно реализовать на UDP.
Вы в сетевые игры играете? Они все на UDP. Когда к игре подключаетесь там что написано? Connecting to...
UDP с логической обвязкой будет уметь и соединение, и что угодно.
Я вам даже примитивный пример привел как на UDP реализуется гарантия доставки пакета. Но вам мне кажется сама суть вопроса не интересна.
По поводу байт - ориентированности ну это уже ни к чему было. Такое ощущение что я с вами как с человеком общаюсь, а вы просто хам и невежда.
Алексей.
Active member
Поясните пожалуйста что такое синхронизация блоков, лучше ссылкой на rfc.
Хоть что там применяют, но в протоколе UDP подтверждений нет. А какой протокол ходит поверх UDP - там может быть что угодно. Только это уже не UDP.
Или приведите ссылку на RFC где сказано про эти "подтверждения".
Последнее редактирование:
Может не будем передёргивать? Откройте глаза и посмотрите внимательнее кто это писал. И не надо мне приписывать чужих слов!
Товарищ Чайник, идите учите матчасть и хватит тут светить своим невежеством. Ваше невежество видно в каждом посте.
И не надо нести бред про протоколы - Вы в них совершенно не разбираетесь.
Ещё раз: для TCP-сокета пересылаемые через него данные - это поток байт. Ни о каких пакетах он не знает. Если нужна пакетная передача через TCP-сокет, то для этого используют какой-либо протокол поверх TCP, который кодирует последовательность пакетов -> в поток байт на входе в TCP-сокет, и декодирует обратно поток байт на выходе из сокета -> в последовательность пакетов. TCP при этом не знает ни о каких пакетах, для него это просто поток байт. А пакеты есть уже на уровне того, более верхнего протокола.
И что доказывает эта куча вываленного хлама? Вашу некомпетентность разве что? Ну так вы её уже во всей красе очередной раз показали.
Приводить кучу ссылок на всякие блоги школьников как доказательство - это уже верх безграмотности.
Да хотя-бы даже эти ссылки сами и почитайте - в первой же ссылке автор и пишет что в UDP нет ни гарантированной доставки ни гарантированного порядка следования сообщений. И что все это реализуется протоколами поверх UDP.
да уж.... Ещё в доказательство приведите мнение бабок у подъезда.
Нет у вас никакого опыта. Одни бредни. А в ответ на просьбу привести доказательство своим же собственным словам - обиженное надувание щёк и: "я больше с тобой не играю".
Читайте документацию:
RFC 768 - User Datagram Protocol
а не жёлтую прессу. Это вам с вашим товарищем maddogmaycry на пару.
Последнее редактирование:
Алексей.
Active member
Я считал, что немножко имею представление о транспорте tcp и очень удивлен отсутствием “мифических” пакетов, просто решил посмотреть так ли это. Поднял tcp сервер на порту 8888, который просто принимает запросы на соединения и больше ничего не делает.
Посмотрел немножко tcpdump-ом что происходит в сетевом интерфейсе на сервере
tcpdump -i eth0 tcp port 8888 -vv
Код:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:05:36.424182 IP (tos 0x10, ttl 55, id 63910, offset 0, flags [DF], proto TCP (6), length 60)
my-client.ru.47850 > my-server.ru.8888: Flags [S], cksum 0xb2c2 (correct), seq 3257422953, win 29200, options [mss 1338,sackOK,TS val 16100815 ecr 0,nop,wscale 7], length 0
11:05:36.424248 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
my-server.ru.8888 > my-client.ru.47850: Flags [S.], cksum 0x80dc (incorrect -> 0xcd57), seq 815724895, ack 3257422954, win 28960, options [mss 1460,sackOK,TS val 715297072 ecr 16100815,nop,wscale 6], length 0
11:05:36.456545 IP (tos 0x10, ttl 55, id 63911, offset 0, flags [DF], proto TCP (6), length 52)
my-client.ru.47850 > my-server.ru.8888: Flags [.], cksum 0x6c55 (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 16100824 ecr 715297072], length 0
11:06:22.382396 IP (tos 0x10, ttl 55, id 63912, offset 0, flags [DF], proto TCP (6), length 651)
my-client.ru.47850 > my-server.ru.8888: Flags [P.], cksum 0xbec6 (correct), seq 1:600, ack 1, win 229, options [nop,nop,TS val 16112311 ecr 715297072], length 599
11:06:22.382464 IP (tos 0x0, ttl 64, id 26712, offset 0, flags [DF], proto TCP (6), length 52)
my-server.ru.8888 > my-client.ru.47850: Flags [.], cksum 0x80d4 (incorrect -> 0x0f4a), seq 1, ack 600, win 472, options [nop,nop,TS val 715308562 ecr 16112311], length 0
11:06:41.735106 IP (tos 0x10, ttl 55, id 63913, offset 0, flags [DF], proto TCP (6), length 52)
my-client.ru.47850 > my-server.ru.8888: Flags [F.], cksum 0xfd53 (correct), seq 600, ack 1, win 229, options [nop,nop,TS val 16117151 ecr 715308562], length 0
11:06:41.773634 IP (tos 0x0, ttl 64, id 26713, offset 0, flags [DF], proto TCP (6), length 52)
my-server.ru.8888 > my-client.ru.47850: Flags [.], cksum 0x80d4 (incorrect -> 0xe970), seq 1, ack 601, win 472, options [nop,nop,TS val 715313410 ecr 16117151], length 0
11:06:41.821763 IP (tos 0x0, ttl 64, id 26714, offset 0, flags [DF], proto TCP (6), length 52)
my-server.ru.8888 > my-client.ru.47850: Flags [F.], cksum 0x80d4 (incorrect -> 0xe963), seq 1, ack 601, win 472, options [nop,nop,TS val 715313422 ecr 16117151], length 0
11:06:41.854003 IP (tos 0x10, ttl 55, id 41314, offset 0, flags [DF], proto TCP (6), length 52)
my-client.ru.47850 > my-server.ru.8888: Flags [.], cksum 0xea38 (correct), seq 601, ack 2, win 229, options [nop,nop,TS val 16117181 ecr 715313422], length 0В 11:06:22 клиентом отправляю несколько сот байтов, в дампе вижу на эти байты от сервера зачем-то отправляется ack.
В 11:06:41 на клиенте закрываю соединение, в дампе всё как положено, клиент fin, сервер fin/ack, сервер fin и клиент fin/ack
И что? Всё штатно и согласно "Машине состояний TCP". Так и должно быть.
см: TCP/IP Крупным планом - Установление и разрыв TCP соединения
Рисунок 18.12 Диаграмма изменений состояния TCP
Алексей.
Active member
Тогда совсем не понятно что означает
Тайм-ауты и повторные передачи TCP пишут про подтверждение получения данных.
Там куда вы меня направили
Тайм-ауты и повторные передачи TCP пишут про подтверждение получения данных.
И что?
pvvx
Активный участник сообщества
Вам радоваться надо, что ваше соединение не с Google Chrome. На посылку ему FIN/АСК вы получите только ACK, а FIN он не даст очень продолжительное время, пока не сочтет, что тайм-аут Keep-Alive истек и истекло кол-во проб Keep-Alive со своими тайм-аутами проверки (в совокупности это обычно к 2-м часам
). А открытая страница в Chrome плодит от 3-х таких соединений с вашим сервером, пока не закроете Chrome.Как правильно прервать эти открытые соединения до истечения Keep-Alive тайм-аутов с пробами (чтобы быстрее освободить ресурсы web-сервера, оставив только TIME_WAIT)?
Пока применил такой вариант: посылаю HTTP ответ "Connection: close" и закрываю socket - он посылает FIN/ACK, TCP стек Chrome передает ACK, далее Chrome ждет свой тайм-аут Keep-Alive и на проверку от TCP стека сервера получает RST.
* Time указан в дельте между пакетами.
C ssl в HTTP ещё прикольнее. При коннекте к серверу вы должны сделать хендшейк, первым передав всякие Hello … При этом Chrome, на одну страницу, откроет несколько соединений, а работать будет по одному (с HTTP Keep-Alive)
Остальные просто висят и жрут ресурс, переговариваясь АСК-ками пока не выйдут TCP Keep-Alive тайм-ауты или не закроете Chrome…Какая ESP потянет несколько одновременных ssl? (Это к тому, какой нафиг web-сервер на ESP)
Последнее редактирование:
pvvx
Активный участник сообщества
Есть подтверждения, что "недошло" :
Но опять же - как это относится к ESP, в котором всё обрезано? И какой RFC у ESP?
Может вы ещё попробуете найти придерживание RFC в примитивных детсадовских web-серверах на Linux (uhttpd, lhttpd, httpd, …)? Там бардак ещё тот - сплошной SO_REUSEADDR у socket-ов, что есть нарушение RFC и вся имеющаяся RAM системы задействована на структуры с TIME_WAIT.
Последнее редактирование:
pvvx
Активный участник сообщества
А при чем тут HTTP keep-alive и HTTP close? TCP FIN что отменен или полузакрытый TCP для web HTTP соединения - это норма?
C "Connection: keep-alive, close\r\n" у прикольных серверов я знаком
Закрытие соединения HTTP 1.1 сервер передает исключительно при ошибках. Посылать ему ещё что-то уже бесполезно и вредно - может быть нарушен порядок обработки запросов, а синхронизации запросов в HTTP не предусмотрено.
ЗЫЖ: и на данный стек Chrome переезжают все браузеры...
PS2: И время до закрытия соединения я Chrome сообщал, а не просто так разорвал соединение
Но ему до лампочки сообщения вида "Keep-Alive: timeout=%d, max=100\r\n".PS3: При SSL если в пустое открытое соединение Chrom-ом загнать какую пургу, то он разрывает соединение первым - это наверно единственный метод закрыть неиспользуемое соединение, которое Chrome открыл просто так, для якобы увеличения скорости реакции для пользователя...
Последнее редактирование: