Протокол MPTCP (Multipath TCP) устроен довольно сложно. Главным образом это так из-за того, что он должен нормально работать в интернете, где промежуточные устройства (middlebox), такие как NAT, файрволы, IDS или прокси, способны модифицировать части TCP-пакетов. Если что-то помешает нормальной работе MPTCP, то, в худшем случае, MPTCP-соединение должно иметь возможность «откатиться» к резервному варианту — к «обычному» TCP. В наши дни подобные «откаты» случаются реже, чем прежде. Вероятно — это так из-за того, что MPTCP используется во всём мире с 2013 года на миллионах смартфонах Apple. Но проблемы с передачей MPTCP-трафика всё ещё возможны. Например — в некоторых мобильных сетях, в которых применяются PEP (Performance Enhancing Proxy, прокси-сервер, предназначенный для улучшения производительности сетевых соединений), где MPTCP-соединения не могут обойти эти прокси-серверы, не подвергнувшись их воздействию. В подобных случаях можно продолжать пользоваться MPTCP и его полезными возможностями, прибегнув к туннелированию MPTCP-соединений. Тут существуют разные решения, но обычно они добавляют в систему дополнительные уровни абстракции и требуют настройки VPN (Virtual Private Network, виртуальная частная сеть) с применением частных IP-адресов между клиентом и сервером.Здесь вашему вниманию предлагается решение этой проблемы, которое устроено проще, чем остальные: TCP-in-UDP (встраивание TCP-пакетов в UDP-датаграммы). Это решение основано на eBPF, оно не добавляет к пакетам дополнительных данных и не требует использования VPN. Читать далее