Сообщение Re[6]: tcp сокет - протоколы от 07.12.2019 9:09
Изменено 07.12.2019 9:18 netch80
Re[6]: tcp сокет - протоколы
Здравствуйте, vsb, Вы писали:
N>>Например, проблема серверного сокета. В случае TCP отцепить сокет на соединение — штатная операция (собственно, accept() это делает). Что делать в случае UDP? Даже если гугл завтра запилит соответствующее решение в своей версии Linux и Fuchsia, то это будет какая-то форма костыля.
vsb>Я может чего-то не понимаю. Но сейчас же UDP-серверы прекрасно работают.
Это не "прекрасно", когда часть соединений нельзя отделить в другой тред/процесс.
На TCP это перебрасывается запросто в пределах одного IP.
Можно исхитриться сделать это на разделении IP, например. Но опять же это статика, если в протоколе нет явных
команд "переключись на другой ремотный адрес", то управление нагрузкой резко усложняется.
N>>Дальше, что делать, если не предполагается шифрование (оно не нужно вообще или обеспечено внешними средствами, типа IPSec)?
vsb>Угу, IPSec: https://www.zdnet.com/article/new-vulnerability-lets-attackers-sniff-or-hijack-vpn-connections/ даже если вы думаете, что вам не нужно шифрование, оно всё равно вам нужно.
Закроют. Но на прошлой работе, например, получалось местами, что шифрование в само соединение не вворачивается принципиально — существующие средства это не вытягивают функционально. Поэтому строились туннели.
N>>Например, проблема серверного сокета. В случае TCP отцепить сокет на соединение — штатная операция (собственно, accept() это делает). Что делать в случае UDP? Даже если гугл завтра запилит соответствующее решение в своей версии Linux и Fuchsia, то это будет какая-то форма костыля.
vsb>Я может чего-то не понимаю. Но сейчас же UDP-серверы прекрасно работают.
Это не "прекрасно", когда часть соединений нельзя отделить в другой тред/процесс.
На TCP это перебрасывается запросто в пределах одного IP.
Можно исхитриться сделать это на разделении IP, например. Но опять же это статика, если в протоколе нет явных
команд "переключись на другой ремотный адрес", то управление нагрузкой резко усложняется.
N>>Дальше, что делать, если не предполагается шифрование (оно не нужно вообще или обеспечено внешними средствами, типа IPSec)?
vsb>Угу, IPSec: https://www.zdnet.com/article/new-vulnerability-lets-attackers-sniff-or-hijack-vpn-connections/ даже если вы думаете, что вам не нужно шифрование, оно всё равно вам нужно.
Закроют. Но на прошлой работе, например, получалось местами, что шифрование в само соединение не вворачивается принципиально — существующие средства это не вытягивают функционально. Поэтому строились туннели.
Re[6]: tcp сокет - протоколы
Здравствуйте, vsb, Вы писали:
N>>Например, проблема серверного сокета. В случае TCP отцепить сокет на соединение — штатная операция (собственно, accept() это делает). Что делать в случае UDP? Даже если гугл завтра запилит соответствующее решение в своей версии Linux и Fuchsia, то это будет какая-то форма костыля.
vsb>Я может чего-то не понимаю. Но сейчас же UDP-серверы прекрасно работают.
Это не "прекрасно", когда часть соединений нельзя отделить в другой тред/процесс.
На TCP это перебрасывается запросто в пределах одного экземпляра стека (контейнера, хоста).
Можно исхитриться сделать это на разделении IP, например. Но опять же это статика, если в протоколе нет явных
команд "переключись на другой ремотный адрес", то управление нагрузкой резко усложняется.
N>>Дальше, что делать, если не предполагается шифрование (оно не нужно вообще или обеспечено внешними средствами, типа IPSec)?
vsb>Угу, IPSec: https://www.zdnet.com/article/new-vulnerability-lets-attackers-sniff-or-hijack-vpn-connections/ даже если вы думаете, что вам не нужно шифрование, оно всё равно вам нужно.
Закроют. Но на прошлой работе, например, получалось местами, что шифрование в само соединение не вворачивается принципиально — существующие средства это не вытягивают функционально. Поэтому строились туннели.
N>>Например, проблема серверного сокета. В случае TCP отцепить сокет на соединение — штатная операция (собственно, accept() это делает). Что делать в случае UDP? Даже если гугл завтра запилит соответствующее решение в своей версии Linux и Fuchsia, то это будет какая-то форма костыля.
vsb>Я может чего-то не понимаю. Но сейчас же UDP-серверы прекрасно работают.
Это не "прекрасно", когда часть соединений нельзя отделить в другой тред/процесс.
На TCP это перебрасывается запросто в пределах одного экземпляра стека (контейнера, хоста).
Можно исхитриться сделать это на разделении IP, например. Но опять же это статика, если в протоколе нет явных
команд "переключись на другой ремотный адрес", то управление нагрузкой резко усложняется.
N>>Дальше, что делать, если не предполагается шифрование (оно не нужно вообще или обеспечено внешними средствами, типа IPSec)?
vsb>Угу, IPSec: https://www.zdnet.com/article/new-vulnerability-lets-attackers-sniff-or-hijack-vpn-connections/ даже если вы думаете, что вам не нужно шифрование, оно всё равно вам нужно.
Закроют. Но на прошлой работе, например, получалось местами, что шифрование в само соединение не вворачивается принципиально — существующие средства это не вытягивают функционально. Поэтому строились туннели.