Смотреть в Telegram
Ответ:
Основная причина: VPN-трафик есть не что иное, как инкапсуляция всего трафика в VPN-туннель. А туннель должен давать максимальную "прозрачность" и минимальные задержки. То есть:
1. Допустим, мы завернули в туннель некий TCP-трафик. Как будет выглядеть готовый пакет при передаче по VPN:
<real IP header> <real UDP header> ENCRYPTED(<internal IP header> <internal TCP header> <internal payload>)
2. Если в нашем "внутреннем" TCP-трафике произойдет, например, потеря пакетов - это отлично решится на уровне TCP между "внутренними" клиентом и сервером. Если VPN будет сделан на основе TCP, а не UDP, это не сыграет никакой роли, а только добавит задержек.
3. Если наш "внутренний" трафик - это UDP, значит, на это была какая-то причина, например минимизация задержек при допустимых потерях. Если VPN будет пытаться "думать за нас", то а) он все равно не узнает, были бы потери прикладных UDP-пакетов (потому что UDP этого не поддерживает), и б) за счет TCP он даст доп. задержки, которых нам хотелось бы избежать, раз уж приложение by design работает поверх UDP.
4. Лишние пакеты, если VPN реализован поверх TCP - например:
- для "внутреннего" TCP трафика: клиент отправил данные, сервер ответил служебным пакетом ACK. Вместо 2 пакетов (как это было бы с VPN over UDP) получится реальных 4 пакета.
- для "внутреннего" UDP трафика: сервер отправил ответ, клиент не отправил ничего. 1 пакет для VPN over UDP, 2 пакета для VPN over TCP.
Love Center - Dating, Friends & Matches, NY, LA, Dubai, Global
Бот для знакомств