В UDP тупо перепосылать пакеты нельзя.Про UDP согласен, забудем про него.
В TCP пакеты и так перепосылаются при недоставке.Есть ли тонкие настройки (для ядра Linux и т.п.) параметров TCP, такие, чтобы минимизировать задержки при повторной отправке пакетов, ценой большей утилизации пропускной способности, когда заведомо известно о больших потерях?
sysctl -w net.ipv4.tcp_congestion_control=westwood
что конкретно означает "стучится вниз/вверх"? Ищет службу, которая может обслужить подобный запрос, и связывается с ней через некоторый интерфейс межпроцессного взаимодействия?Часть имплементации сетевого стека содержится в ядре операционной системы, часть - в драйвере сетевого адаптера, часть - в железе сетевого адаптера. Некоторые протоколы вынесены в службы\демоны (ppp, pptp, openvpn,..). Протоколы 6-го и 7-го уровня реализуются либо в службах, либо в прикладных программах.
Например, браузер. Вот мы ввели qna.habr.com, браузер хочет открыть HTTP соединение. Он формирует набор данных для передачи, затем стучится вниз, на уровень TCP, и говорит: "вот у меня пачка данных, передай их серверу на таком-то адресе".Браузер сначала на уровне API операционной системы обращается к резолверу (клиенту DNS), резолвер (сперва проверив свой кэш) берёт адрес DNS-сервера из настроек ОС и стучится на порт 53/UDP с запросом, а не "ищет службу". Получает ответ и передаёт его браузеру. Браузер запоминает IP-адрес хоста qna.habr.com и снова через API операционной системы говорит "хочу установить соединение с хостом, адрес такой-то, порт 443/TCP". ОС устанавливает соединение, сообщает об этом браузеру и передаёт какой-то там хэндлер, через который можно использовать уже готовое TCP-соединение. Дальше браузер просто заливает свои данные в соединение, и читает оттуда же ответы. Более высокий уровень - протокол 7-го уровня http - браузер реализует самостоятельно, вот прямо самостоятельно, никого ни о чём не просит, когда дело в http. Более низкие уровни - как уже сказал, на совести ОС, драйвера, железа. Чтобы обеспечить высокую эффективность, там взаимодействие довольно низкоуровневое, такая каша, что не только в рамках ответа, а даже в рамках статьи не описать, целая книга нужна, а то и не одна. Причём для каждой ОС своя отдельная книга, в Linux сетевой стек будет отличаться от сетевого стека Windows, сетевого стека MacOS, сетевого стека BSD.
и где обычно это все указывается?В Linux есть справочный файл
/etc/services
, в котором перечислены порты tcp/udp, по умолчанию назначенные (но не привязанные намертво) различным протоколам прикладного уровня.C:\Windows\System32\drivers\etc\services
. Получается, что существует некий "большой" маршрутизатор, принадлежащий провайдеру, который поддерживает NATДля этого даже отдельный термин придумали:
на каком-то аппаратном уровне (ниже уровня веб-сервера)Ниже L3 (третьего уровня в модели OSI) только L2 может увидеть ваш провайдер (да и то не при любом способе подключения), и L2 не спалит вас перед вероятным противником, даже если бы тот видел L2 (к вопросу о бессмысленности затирания MAC-адресов на скриншотах).
И да, вы употребили термин «Кванмён»… дело в том, что на Севере это слово практически не используется на практике. Северный кореец при упоминании «Яркого Света» скорее всего даже не поймёт, о чём идёт речь. Основной интранет КНДР именуют «Национальная компьютерная сеть», длинным составным словом. Чаще говорят просто «компьютерная сеть».
может ли США уже со своей стороны блокировать доступ с адресов российского пула?Тогда мы сможем ходить к ним условно через китайский VPN как бы с китайских адресов, ну или им придётся сразу блокировать и Китай, и Венесуэлу, Индию, Армению, Казахстан, Кубу,.. плюс договариваться со всеми остальными, кого не будет в этом списке, чтобы они тоже блокировали весь список стран, поддерживающих Россию.
как это обойти?При полной изоляции (и если она будет реализована грамотно, без ошибок) никак. Но считаю, что вероятность такого сценария пока ещё мала (в ближайший год 1%). Мелкие пакости - да, будут, и уже сейчас есть.