Ярослав

А всё просто )
Когда Вы работаете с протоколом TCP, вы не оперируете понятием "пакет": TCP скрывает от Вас тот факт, что сообщение при передаче каким-то образом разбивается на отдельно передаваемые фрагменты.
Причём, уровень шифрования, например, SSL/TLS, большинство библиотек реализуют прозрачно и незаметно для Вас, поэтому Ваша программа может и не знать, что в какой-то момент данные на отправке зашифровываются, а на приёме расшифровываются.

Логика отправки или приёма чего-то из TCP-соединения абсолютно такая же, как и при работе с дисковым файлом: есть некоторый поток байт, которые на уровне протокола никак на отдельные сообщения не разделены. Признак "началось новое сообщение" Вам надо придумать самому.

Например, популярной является разметка TLV: Tag-Length-Value
Tag: тип сообщения или некоторый маркер начала нового сообщения. Как правило, это поле фиксированной длины, например, 1 байт.
Length: длина сообщения. Поле фиксированной длины, например, 4 байта.
Value: само передаваемое сообщение переменной длины.

Какое какое именно значение передавать в Length - решать Вам.
Можно сделать так:
Length = длина_поля_в_байтах(Value)
А можно и так:
Length = длина_поля_в_байтах(Tag) + длина_поля_в_байтах(Length) + длина_поля_в_байтах(Value)

Не надо опасаться, что, начав читать из TCP-соединения, Вы начнёте читать его "с середины": протокол гарантирует, что Вы при чтении увидите байты в том же самом порядке, в котором они были отправлены в вашу сторону с той стороны.

Однако, внимание, грабли, на которые часто наступают новички:
1. После того, как Вы прочитали байт из соединения, он пропадает: прочитать его снова Вы уже не сможете. При следующей процедуре чтения Вы прочитаете уже следующий байт, отправленный сразу же после прочитанного Вами в прошлый раз.

2. Будьте готовы к тому, что Вы можете начать читать некоторое сообщение в тот момент, когда его отправка с той стороны уже начата, но ещё не завершена.
Зато, Вы можете в любой момент посмотреть, сколько там байт уже прилетело и накопилось в буфере приёма.

Пример: допустим, Вы ожидаете сообщение длиной 100 байт.
Возможна ситуация, когда Вы прочитали из соединения 50 байт, а затем Вы получаете уведомление "больше данных нет". Это означает, что оставшиеся 50 байт всё ещё где-то в пути; Вам следует периодически повторять процедуру чтения из соединения до тех пор, пока Вы не получите, вероятно, за несколько приёмов, оставшиеся данные.

Получается, на псевдокоде пусть не оптимальная, но зато простейшая логика чтения каждого нового сообщения в разметке TLV может иметь следующий вид:

пока (соединение_не_закрыто):
    подождать_пока_в_буфере_приёма_не_окажется_байт(1)
    tag = прочитать_байт(1)

    подождать_пока_в_буфере_приёма_не_окажется_байт(4)
    length = прочитать_байт(4)

    подождать_пока_в_буфере_приёма_не_окажется_байт(length)
    value = прочитать_байт(length)

    обработать_новое_сообщение(tag, value)

Подобная логика позволит Вам нормально обработать ситуацию, когда кто-то отправил Вам два сообщения подряд, но сразу до Вас первое сообщение долетело целиком, а от второго - только первая половина: столько влезло в один TCP-пакет. Вторая же половина второго сообщения в следующем TCP-пакете может прилететь даже и через полчаса.

Именно для Скайпа использовать несколько модемов разом бесполезно.
Дело в том, что любые доступные вам методы балансировки (т.е. перераспределения) интернет-трафика будут раскидывать между модемами не отдельные ip-пакеты, а установленные соединения.
Сделать так, чтобы половина скайп-трафика шла через модем Зелёный-телеком, а вторая - через Полосатый-телеком, не получится.
Максимум, чего можно добиться: Скайп, допустим, ходит через Зелёный-телеком, а веб-серфинг, торренты и всё остальное - через Полосатый.

Правда, не совсем через сайт, но...
DNS-туннель?
iodine?

Ох, прилетит мне сейчас от МТС ;)

Вопрос в том, насколько глубоко новичок хочет разобраться в теме.
Если вводные статьи, найденные longclaps, кажутся слишком поверхностными...

Слишком много там всего.
Я работаю в мобильном операторе более десяти лет, но работу радио и голосовых сервисов, например, до сих пор знаю достаточно поверхностно.

Ну, вот если сходу и крупными мазками, то современная мобильная сеть это:
- радио трёх разных поколений: GERAN (GSM), UTRAN (3G), EUTRAN (LTE) и механизмы взаимодействия между поколениями
- классическая голосовая подсистема 2G/3G, костыль CSFB/RIM для выталкивания абонента в сеть GSM/3G из LTE для совершения звонка, и вообще ни на что не похожий VoLTE/IMS
- свои заморочки в мобильном интернете 2G/3G/LTE, включая экзотику вроде мобильного мультикаста MBMS
- интегрированный Wi-Fi
- онлайн-биллинг
- DPI

Из протоколов сигнализации, придётся понять:
- SS7 (для 2G/3G)
- Diameter (биллинг/DPI/LTE)
- RADIUS
- всякая портящая жизнь мелочь вроде BSSAP, S1AP, GTP-C/GTP-U )

В общем, одной книжки про всё разом, скорее всего, в природе нет в силу слишком большого охвата. Да и, вообще, мобильные сети связи - это университетская специальность на четыре года обучения )

Предлагаю начать с обзорных статей, понять, что Вам ближе, и уже затем начать углубляться в интересующее направление.

Ещё мне очень хвалили за глубокий подход к теории читаемые инженерам операторов связи курсы от Хуавея.

Ну да, именно что отдельная сетевая инфраструктура.
Местами поверх существующей, местами вообще отдельное оборудование.

Входящее в состав этой сети оборудование не участвует в глобальной ip-маршрутизации.

Там свои, независимые от интернета планы адресации: свои принципы выделения ip-адресации, свои организации, отвечающие за выделение BGP AS.
В общем, это свой маленький отдельный интернетик - только для своих.
А протоколы все те же, дабы ничего нового не придумывать.

Примером много: и тот же Swift, ГАС Выборы, и ведомственные сети, и связывающая мобильных операторов связи друг с другом сеть IPX/GRX.

Собственно, это - в широком смысле огромный, как гоеграфически, так и топологически, VPN с многими тысячами узлов.
А что тут удивительного?

Вообще, в Казахстане, говорят, HTTPS MITM есть:
https://habrahabr.ru/post/303736/
Было бы интересно пообщаться с казахскими коллегами - чем там всё кончилось?

Но в данном конкретном случае, полагаю, всё проще:
Из казахского чегототамнадзора во Вконтакте приходит требование заблокировать некую группу на территории Республики Казахстан.
Вконтакте ссориться с казахами по такому мелкому поводу не хочет, и где-то в глубине настроек Вконтакта напротив этой группы ставится метка "Если GeoIP покажет, что пользователь зашёл с казахского ip-адреса, группу ему не показывать".

Через Тор же всё работает потому, что в таком случае Вконтакте увидит Ip-адрес абстрактного Зимбабве, а из Зимбабве таких запросов не приходило.

Здесь, всё-таки, придётся лезть теорию.

В общем виде, технология называется TCP Hole Punching: https://en.wikipedia.org/wiki/TCP_hole_punching

Работает она так:
Есть маршрутизатор с внешним ip-адресом 1.2.3.4 и спрятанной за ним сетью 192.168.0.0/24.
Допустим, находящееся за NAT устройство с Ip-адресом 192.168.0.100 решило вылезти в Интернет и подключиться к серверу с ip-адресом 5.6.7.8 к порту 8080.
Устройство поднимает TCP-соединение: со стороны устройства пара ip-адрес:порт будет, допустим, 192.168.0.100: 1111, а со стороны принимающей стороны 5.6.7.8:8080.
Маршрутизатор, пропуская сквозь себя эти пакеты, подменяем ip-адрес и, что важно, порт спрятанного за ним устройства: на, предположим, 1.2.3.4:7890.

Если на маршрутизаторе включен TCP Hole Punching, то он начинает преобразовывать пары адрес-порт 192.168.0.100: 1111 -> 1.2.3.4:7890 не только для соединений, исходящих изнутри, но и для входящих соединений снаружи.
Это значит, что, начиная с момента установки соединения "изнутри наружу", запрос на TCP-соединение из интернета к 1.2.3.4:7890 будет прокинут маршрутизатором до спрятанного устройства, и дойдёт до 192.168.0.100: 1111.

Получается, клиентская сторона для приёма соединений из-за NAT должна подготовиться следующим образом:
1. Установить соединение с каким-то узлом в Интернет. Вообще неважно с кем: нам надо просто "пробить дырку" в NAT для приёма входящих соединений. Установив соединение, мы запоминаем source port.
2. Создаём Listening socket на порту, запомненном в предыдущем шаге. Теперь мы можем принимать входящие соединения из интернет!

И всё бы здорово, но возникает следующий вопрос: номер порта, на котором мы слушаем, маршрутизатор подменит совершенно непредсказуемым образом.
Если мы хотим установить прямое соединение с устройством, которое тоже находится за NAT, как нам узнать, к какой публичной паре Ip-адрес:порт нам цепляться? Ведь каждый раз номер порта может непредсказуемо меняться!

Ответ здесь один: нужен посредник - что-то типа каталога. Сервер с публичным ip-адресом, на котором можно зарегистрироваться. Ну никак без него!

Работать это может так:
1. Есть каталог с ip-адресом, допустим, 11.12.13.14, принимающий входящие соединения на порту 80.

2. Устройство А с ip-адресом 192.168.0.100, находящееся за NAT 1.2.3.4, готовится к приёму входящих соединений. Оно устанавливает TCP-соединение с каталогом:
192.168.0.100:1111 ===> 11.12.13.14:80.
NAT A в проходящих сквозь него ip-пакетах преобразует ip-адрес и номер порта для спрятанного за ним устройства, и запоминает это соответствие:
192.168.0.100:1111 <-> 1.2.3.4:1112.
С точки зрения каталога, он принял такое входящее TCP-соединение:
1.2.3.4:1112 ===> 11.12.13.14:80, ибо реальную адресацию устройства A ему узнать просто неоткуда. Ну и ладно: всё и так прекрасно работает!

3. Устройство B с ip-адресом 192.168.2.200, находящееся за NAT 5.6.7.8, устанавливает TCP-соединение с каталогом:
192.168.2.200:2221 ===> 11.12.13.14:80.
NAT B в проходящих сквозь него ip-пакетах преобразует ip-адрес и номер порта для спрятанного за ним устройства, и запоминает это соответствие:
192.168.2.200:2221 <-> 5.6.7.8:2222.

4. Устройство B спрашивает у каталога: "А кто к тебе ещё подключен?"
Каталог ответчает: "Да вот есть один такой, 1.2.3.4:1112"

5. Устройство B устанавливает TCP-соединение с полученным от каталога ресурсом:
192.168.2.200:9876 ===> 1.2.3.4:1112

NAT B подменяет и запоминает ip-адрес и номер порта устройства B: 192.168.2.200:9876 -> 5.6.7.8:4321

Соответственно, на NAT A прилетает запрос на установление соединения:
5.6.7.8:4321 ===> 1.2.3.4:1112

NAT A смотрит в таблицу NAT-трансляций, видит там знакомый номер порта, и подставляет из таблицы ip-адрес и номер порта устройства A: 1.2.3.4:1112 -> 192.168.0.100:1111

6. Устройство A получает запрос на подключение:
5.6.7.8:4321 ===> 192.168.0.100:1111

Собственно, в зависимости от требований, сервер каталога можно:
1. Написать самому
2. А можно не изобретать велосипед, и воспользоваться готовыми реализациями того же протокола STUN

Забрать обратно - уже никак. Как минимум, придётся ждать, пока истечёт срок жизни.

Если важно, чтобы конкретный ip-адрес назначался конкретному устройству, можно:
1. Посмотреть MAC-адрес устройства и в настройках DHCP-сервера явно прописать соответствие MAC -> IP, или
2. В настройках DHCP-сервера изменить диапазон автоматически выдаваемых ip-адресов так, чтобы желаемый IP-адрес в него не попадал, и на устройстве прописать желаемый IP-адрес вручную

Поскольку резолвинг DNS происходит корректно, промышленно готовых вариантов остаётся три:

1. Провайдерский DPI: наверняка он уже есть у всех провайдеров в том или ином виде.
Логически DPI обычно включается в разрыв линка между ядром и NAT.
Физически зачастую тоже.
Кроме обычных шейпинга и подсчёта трафика per-subscriber, там реализован набор ALG (Application Layer Gateway), которые представляют из себя, фактически, прозрачные прокси для типичных протоколов: HTTP, FTP, DNS и т.д.
Как правило, ALG умеют не только реагировать на определённые значения полей, но и вмешиваться в процесс передачи данных.
Количество ALG зависит от навороченности DPI; в Procera даже World of Warcraft есть )
Ну а уж подмена HTTP-страницы - пожалуй, самая используемая функция HTTP ALG.

2. Наколенное решение раз:
Описано у none7
Завести у себя в сети сервер с ip-адресами, совпадающими с Ip-адресами Вконтакта (ну, или NAT'ить все запросы к нему на сервер-заглушку, что примерно то же самое) - вполне себе решение, если надо заблокировать сервис целиком, а не отдельные страницы на нём.
Но если вдруг ваши политики наберутся дурости у наших, и список блокируемых ресурсов начнёт расти, провайдеры взвоют этот вариант поддерживать )

3. Наколенное решение два:
На самом деле, в России есть свой список блокируемых ресурсов (т.н. список Роскомнадзора) с сотнями тысяч URL.

Выяснилось, что таким количеством записей множество провайдерских DPI попросту давится, поэтому эта задача зачастую решается следующим образом: заводятся отдельные серверы, подключаемые непосредственно к провайдерским BR (Border router'ам).

Задачи серверов:
- заглотить список блокируемых ресурсов, выдрать оттуда имена доменов и разрезолвить их в ip-адреса; адресов получается несколько десятков тысяч
- полученные адреса через OSPF или BGP сливаются в BR. BR - он большой, спокойно держит BGP Full View, поэтому 10-20-50k лишних префиксов для него - капля в море

Получается, что весь трафик в сторону ip-адресов, на которых находится хотя бы одна заблокированная страница, теперь льётся на эти серверы.
Казалось бы, фиг какой сервер всё это переварит, но их можно плодить десятками: срабатывает ECMP/Load Balancing на уровне маршрутизации, и трафик размазывается между серверами примерно поровну.

На самих серверах Linux, а в Linux - squid в transparent mode и iptables )
Соответственно:
- tcp port 80 силами iptables отправляется в сквид, где каждый запрошенный абонентом URL ищется в списке блокированных ресурсов
- в tcp port 443 проверяется SNI чтобы понять, пропускать трафик дальше, или резать к такой-то матери
- весь остальной трафик (и пинги, угу) пропускается насквозь без изменения

Предлагаю посмотреть:
1. Как настроена балансировка?
2. Как замерялась скорость?

Эти вопросы связаны, на самом деле: для того, чтобы понять, в какой порт LAG засунуть Ethernet-кадр, коммутатор вычисляет хэш-функцию от выбранных при настройке полей кадра и берёт остаток от деления хэша на количество линков в LAG.

По умолчанию, как правило, хэш считается от Source MAC + Destination MAC.
Также, обычно можно руками включить использование для вычисления хэша:
- Source ip/Destination ip
- Source port/Destination port

На практике же это означает, что:
1. Чем больше _разных_ MAC/ip-адресов проходит через LAG, там равномернее распределяется трафик
2. А вот установленное TCP-соединение не "размажется" по линкам и при, например, загрузке файла по FTP скорость всё равно упрётся в скорость одного-единственного линка, будь их там хоть все восемь

CIDR - это один из способов записи диапазонов ip-адресов, не более того.
Просто способ написать, что "ip-адреса компьютеров бухгалтерии лежат в диапазоне 172.16.0.0-172.16.255.255": 172.16.0.0/16

Если уж подходить к понятию автономной системы абстрактно, то автономная система - это ip-транспортная инфраструктура некоторого состоящего из множества отделов и, соответственно, ip-подсетей предприятия целиком либо, как минимум, изолированного филиала, поскольку:
- там свой отдельный план выделения ip-адресов
- там свой отдельный администратор сети

Для того, чтобы различать принадлежность ip-адресов на уровне организаций, в некоторых протоколах маршрутизации, например, BGP, принято каждому предприятию выделять свой идентификатор - т.н. ASN, Autonomous System Number.

Надо понимать, что ASN - это чисто BGP-шный термин.
Если организация подключена к Интернет через единственный стык единственного провайдера, то необходимости в BGP у неё нет.
Соответственно, получается, что автономная система формально у неё всё равно есть (как совокупность используемых в организации ip-сетей и механизмов управления ими), просто номер ASN ей не присвоен.

В реальной жизни, как правило, понятие автономной системы фигурирует не в описании сетевой инфраструктуры организации, а в правилах обмена трафиком между двумя различными организациями:
- параметры физического и ip-стыков двух автономных систем
- какие принадлежащие каждой АС ip-подсети должны быть доступны партнёру по стыку