Tcp против udp или будущее сетевых протоколов

How to get 3WiFi to your computer

You cannot download the 3WiFi database. Attempts to pump out the database will lead to the ban of your account and the ban of all invited by you and further along the chain. No merit will not remove the ban.

However, you can organize your own 3WiFi on your computer or on your server, since the Source code for 3WiFi is hosted on GitHub: https://github.com/binarymaster/3WiFi

Therefore, you need a web server, and you also have to scan the ranges you need to have your search information in your 3WiFi database.

Steps for installing 3WiFi:

1. Copy all required files to your /www directory
2. Create database (execute 3wifi.sql to create tables)
3. Copy config.php-distr to config.php
4. Edit config.php (DB_SERV, DB_NAME, DB_USER, DB_PASS etc)
5. (optional) Turn on memory tables (in the config.php define TRY_USE_MEMORY_TABLES as true)
6. (optional) Use import.free.php once to import old format database
7. Start all background daemons:

# Upload routine loads data into database

php -f 3wifid.php uploads

# Finalize routine prepares tasks for finalization

php -f 3wifid.php finalize

# Geolocate routine locates new added BSSIDs on map

php -f 3wifid.php geolocate

# Stats routine caches statistics (use only when stats caching enabled)

php -f 3wifid.php stats

# Memory table manager (use only with memory tables enabled)

php -f 3wifid.php memory

Database maintenance:

# Recheck not found BSSIDs in the database

php -f 3wifid.php recheck

Before running the daemons, make sure that php-cli interpreter is accessible from your directory.

Кодирование/декодирование видео

• I-frame — это просто jpg. По сути, это опорный кадр, он ни от кого не зависит и содержит четкую картинку.
• P-frame зависит исключительно от предыдущих кадров.
• Хитрые B-frame могут зависеть от будущего. Это означает, что чтобы посчитать b-frame, нужно, чтобы с камеры пришли еще и будущие кадры. Только тогда с некоторой задержкой можно декодировать b-frame.

B-кадры вредны

1. Если вы стримите с мобильного устройства, можно попробовать включить профайл baseline. Он отключит B-frame.
2. Можно попробовать настроить кодек и уменьшить задержку на будущие кадры, чтобы кадры приходили быстрее.
3. Еще одна важная штука в тюнинге кодека — это включение CBR (константного битрейта).

Надо включать CBRzerolatency

Выполняем атаку TCP reset против себя

Примечание: я тестировал этот процесс на OSX, но получил несколько комментариев, что в Linux он не работает нужным образом.

• Наблюдать за сетевым трафиком («сниффить» его), передаваемым между двумя жертвами
• Сниффить TCP-сегмент со включенным флагом и считать его подтверждённый номер
• Изготовить ложный TCP-сегмент со включенным флагом и порядковым номером, равным подтверждённому номеру перехваченного сегмента (стоит учесть, что это предполагает медленную передачу, иначе выбранный порядковый номер быстро устареет. (Чтобы повысить шансы на успех, можно передать несколько сегментов с большим интервалом порядковых номеров.)
• Отправить фальшивые сегменты одной или обеим жертвам, надеясь, что это приведёт к разрыву их TCP-соединения

1. Настроить TCP-соединение между двумя окнами терминала
2. Написать атакующую программу, которая будет заниматься сниффингом трафика
3. Модифицировать программу так, чтобы она изготавливала и отправляла фальшивые сегменты .

2. Сниффинг трафика

• — приказывает слушать сетевой интерфейс , или localhost
• — функция фильтра, приказывающая игнорировать все пакеты, не являющиеся частью соединения двух IP-адресов localhost на порте сервера. Эта фильтрация необходима, потому что на машине есть множество других программ, использующих интерфейс . Мы хотим игнорировать все пакеты, не являющиеся частью нашего эксперимента.
• — функция, которую должна выполнять для каждого пакета, соответствующего требованиям функции . Функция в показанном выше примере просто выводит пакет на терминал. На следующем этапе мы изменим эту функцию, чтобы она также передавала сегменты .
• — количество пакетов, которое должна сниффить до выхода.

3. Отправка фальшивых пакетов

• Меняем местами IP-адреса отправителя и получатели, а также их порты. Это необходимо, потому что наш пакет будет ответом на перехваченный пакет. Исходная точка нашего пакета должна быть конечной точкой исходного пакета, и наоборот.
• Включаем флаг сегмента, потому что именно он сообщает, что сегмент является
• Присваиваем порядковому номеру точное значение номера подтверждения перехваченного пакета, так как это следующий порядковый номер, который ожидает получить отправитель
• Вызываем метод библиотеки для отправки сегмента жертве — источнику перехваченного пакета.

Дальнейшая работа

1. Продолжите эксперименты с инструментом для атак. Проследите, что происходит, если прибавить или вычесть 1 из порядкового номера пакета . Убедитесь, что он должен быть точно равен значению перехваченного пакета.
2. Скачайте Wireshark и используйте его для прослушивания интерфейса во время проведения атаки. Это позволит вам увидеть подробности о каждом из передаваемых по соединению TCP-сегментов, в том числе и о ложном . Используйте фильтр для фильтрации всего излишнего трафика других программ.
3. Усложните проведение атаки, передавая по соединению непрерывный поток данных. Это затруднит выбор скриптом правильного порядкового номера для его сегментов , потому что ко времени прибытия сегмента к жертве та уже может получить дальнейшие истинные данные, увеличив таким образом следующий порядковый номер. Чтобы противодействовать этому, мы можем передавать несколько пакетов , каждый из которых имеет свой порядковый номер.

Раскрытие модели роутера из Vendor Specific: Microsof: WPS

Я несколько минут захватывал фреймы Wi-Fi, а затем стал искать по фильтрам, начал с фильтра frame contains «». Для ТД D-Link Systems DIR-615 раскрывалась модель роутера, поэтому я присмотрелся к фреймам, содержащим этот текст:

frame contains "D-Link Systems DIR-615"

Как можно увидеть, в тэге Tag: Vendor Specific: Microsof: WPS в полях Model Name, Model Number, Device Name раскрывается точная информация о модели роутера:

• Model Name: D-Link Router
• Model Number: DIR-615
• Device Name: D-Link Systems DIR-615

Дальнейшее изучение фреймов, содержащих информацию о модели роутера показало, что полезная информация также может находиться в полях:

• Manufacturer
• Serial Number

С помощью фильтров

wps.device_name != ""

или

wps.model_name != ""

можно вывести все фреймы, в которых поля «Имя устройство» или «Имя модели» являются не пустыми.

Следующий фильтр покажет фреймы, в которых поле ИЛИ «Имя устройства», ИЛИ «Имя модели», ИЛИ «Номер модели» являются не пустыми:

wps.device_name != "" || wps.model_name != "" || wps.model_number != ""

Следует помнить о фильтрах wps.serial_number и wps.manufacturer – из них также можно извлечь информацию.

Для моих данных фильтр wps.new_device_name не показывал никакой информации – у меня в радиусе доступности отсутствуют ТД с фреймами с какой-либо информацией в этом поле.

Если мы хотим посмотреть фреймы с информацией о версии для конкретной точки доступа, то можно использовать фильтр wlan.ssid:

(wps.device_name != "" || wps.model_name != "" || wps.model_number != "") && wlan.ssid == "ESSID"

Вместо ESSID вставьте имя интересующей сети, например, я хочу посмотреть для сети Ivan S., тогда:

(wps.device_name != "" || wps.model_name != "" || wps.model_number != "") && wlan.ssid == "Ivan S."

Запись Device Name: RT-N10P говорит о том, что модель роутера RT-N10P.

Вместо имени сети можно использовать BSSID (MAC-адрес), для этого имеются фильтры wlan.addr и wlan host, например:

wlan.addr==08.00.08.15.ca.fe
wlan host 08:00:08:15:ca:fe

Обзор беспроводных сетей в Router Scan

В Router Scan начиная с версии v2.60 появилась вкладка Wireless Networks:

В поле Interface выберите ту Wi-Fi карту, которую вы хотите использовать для аудита Wi-Fi сетей. Если вы поставите галочку на Enable discovery, то начнётся сбор данных о доступных в радиусе досягаемости точках доступа. Чтобы точки доступа не пропадали из списка, поставьте галочку Cumulative mode:

Поле Active отмечает (вроде бы) сети, к которым вы подключены в данный момент.

Обратите внимание, что нам доступна расширенная информация о точках доступа. В том числе, можно увидеть точную модель (поля WSC Name и Model) для ТД с WPS.

TCP vs self-made UDP

• С перегрузками, когда пакетов очень много и некоторые из них дропаются из-за перегрузки каналов или оборудования.
• Высокоскоростные с большими round-trip (например когда сервер располагается относительно далеко).
• Странные — когда в сети вроде бы ничего не происходит, но пакеты все равно пропадают просто потому-что Wi-Fi точка доступа находится за стенкой.

• Профиль Видео, когда вы подключаетесь и стримите тот или иной контент. Скорость соединения увеличивается, как на верхнем графике. Требования к этому протоколу: низкие задержки и адаптация битрейта.
• Вариант просмотра Ленты: импульсная загрузка данных, фоновые запросы, промежутки простоя. Требования к этому протоколу: получаемые данные мультиплексируются и приоритизируются, приоритет пользовательского контента выше фоновых процессов, есть отмена загрузки.

Отличия HTTP 2.0

• бинарный, сжатие заголовков;
• мультиплексирование данных;
• приоритизация;
• возможна отмена загрузки;
• server push

Высокоприоритетный контент загружается раньше.Server pushReset stream

• Профилях сети: Wi-Fi, 3G, LTE.
• Профилях потребления: cтриминг (видео), мультиплексирование и приоритизация с отменой загрузки (HTTP/2) для получения контента ленты.

Размер буфера

• пакеты 1 и 2 уже отправлены, для них получено подтверждение;
• пакеты 3, 4, 5, 6 отправлены, но результат доставки неизвестен (on-the-fly packets);
• остальные пакеты находятся в очереди.

Вывод:

Congestion control

• Flow control — это некий механизм защиты от перегрузки. Получатель говорит, на какое количество данных у него реально есть место в буфере, чтобы он был готов их принять. Если передать сверх flow control или recv window, то эти пакеты просто будут выкинуты. Задача flow control — это back pressure от нагрузки, то есть просто кто-то не успевает вычитывать данные.
• У congestion control совершенно другая задача. Механизмы схожие, но задача — спасти сеть от перегрузки.

• Если TCP window = 1, то данные передаются как на схеме слева: дожидаемся acknowledgement, отправляем следующий пакет и т.д.
• Если TCP window = 4, то отправляем сразу пачку из четырех пакетов, дожидаемся acknowledgement и дальше работаем.

• На верхней схеме сеть, в которой все хорошо. Пакеты отправляются с заданной частотой, с такой же частотой возвращаются подтверждения.
• Во второй строке начинается перегруз сети: пакеты идут чаще, acknowledgements приходят с задержкой.
• Данные копятся в буферах на маршрутизаторах и других устройствах и в какой-то момент начинают пропускать пакеты, acknowledgements на эти пакеты не приходят (нижняя схема).

• Cubic — дефолтный Congestion Control с Linux 2.6. Именно он используется чаще всего и работает примитивно: потерял пакет — схлопнул окно.
• BBR — более сложный Congestion Control, который придумали в Google в 2016 году. Учитывает размер буфера.

BBR Congestion Control

• BBR понимает, что идет переполнение буфера, и пытается схлопнуть окно, уменьшить нагрузку на маршрутизатор.
• Cubic дожидается потери пакета и после этого схлопывает окно.

jitterHighLoad++

Какой Congestion control выбрать

Выводы про congestion control:

• Для видео всегда хорош BBR.
• В остальных случаях, если мы используем свой UDP-протокол, можно взять congestion control с собой.
• С точки зрения TCP можно использовать только congestion control, который есть в ядре. Если хотите реализовать свой congestion control в ядро, нужно обязательно соответствовать спецификации TCP. Невозможно раздуть acknowledgement, сделать изменения, потому что просто их нет на клиенте.

TCP vs self-made UDP

• С перегрузками, когда пакетов очень много и некоторые из них дропаются из-за перегрузки каналов или оборудования.
• Высокоскоростные с большими round-trip (например когда сервер располагается относительно далеко).
• Странные — когда в сети вроде бы ничего не происходит, но пакеты все равно пропадают просто потому-что Wi-Fi точка доступа находится за стенкой.

• Профиль Видео, когда вы подключаетесь и стримите тот или иной контент. Скорость соединения увеличивается, как на верхнем графике. Требования к этому протоколу: низкие задержки и адаптация битрейта.
• Вариант просмотра Ленты: импульсная загрузка данных, фоновые запросы, промежутки простоя. Требования к этому протоколу: получаемые данные мультиплексируются и приоритизируются, приоритет пользовательского контента выше фоновых процессов, есть отмена загрузки.

Отличия HTTP 2.0

• бинарный, сжатие заголовков;
• мультиплексирование данных;
• приоритизация;
• возможна отмена загрузки;
• server push

Высокоприоритетный контент загружается раньше.Server pushReset stream

• Профилях сети: Wi-Fi, 3G, LTE.
• Профилях потребления: cтриминг (видео), мультиплексирование и приоритизация с отменой загрузки (HTTP/2) для получения контента ленты. 

Размер буфера

• пакеты 1 и 2 уже отправлены, для них получено подтверждение;
• пакеты 3, 4, 5, 6 отправлены, но результат доставки неизвестен (on-the-fly packets);
• остальные пакеты находятся в очереди.

Вывод:

Congestion control

• Flow control — это некий механизм защиты от перегрузки. Получатель говорит, на какое количество данных у него реально есть место в буфере, чтобы он был готов их принять. Если передать сверх flow control или recv window, то эти пакеты просто будут выкинуты. Задача flow control — это back pressure от нагрузки, то есть просто кто-то не успевает вычитывать данные.
• У congestion control совершенно другая задача. Механизмы схожие, но задача — спасти сеть от перегрузки.

• Если TCP window = 1, то данные передаются как на схеме слева: дожидаемся acknowledgement, отправляем следующий пакет и т.д. 
• Если TCP window = 4, то отправляем сразу пачку из четырех пакетов, дожидаемся acknowledgement и дальше работаем.

• На верхней схеме сеть, в которой все хорошо. Пакеты отправляются с заданной частотой, с такой же частотой возвращаются подтверждения. 
• Во второй строке начинается перегруз сети: пакеты идут чаще, acknowledgements приходят с задержкой. 
• Данные копятся в буферах на маршрутизаторах и других устройствах и в какой-то момент начинают пропускать пакеты, acknowledgements на эти пакеты не приходят (нижняя схема).

• Cubic — дефолтный Congestion Control с Linux 2.6. Именно он используется чаще всего и работает примитивно: потерял пакет — схлопнул окно.
• BBR — более сложный Congestion Control, который придумали в Google в 2016 году. Учитывает размер буфера.

BBR Congestion Control

• BBR понимает, что идет переполнение буфера, и пытается схлопнуть окно, уменьшить нагрузку на маршрутизатор. 
• Cubic дожидается потери пакета и после этого схлопывает окно.

jitter

Какой Congestion control выбрать

Выводы про congestion control:

• Для видео всегда хорош BBR. 
• В остальных случаях, если мы используем свой UDP-протокол, можно взять congestion control с собой.
• С точки зрения TCP можно использовать только congestion control, который есть в ядре. Если хотите реализовать свой congestion control в ядро, нужно обязательно соответствовать спецификации TCP. Невозможно раздуть acknowledgement, сделать изменения, потому что просто их нет на клиенте.

Настройка переадресации портов

В зависимости от модели роутера эта вкладка может называться

• Forwarding
• Port Forwarding
• Port mapping
• Переадресация портов
• другие варианты

Например, на рассматриваемом роутере эту вкладку я нашёл по пути Application → Port Forwarding:

Всего портов 1-65535 и роутеры позволяют делать переадресацию диапазонов, то есть 65 тысяч портов не придётся настраивать по одному.

Но есть очень важное замечание — мы не можем настроить переадресацию того порта, на котором работает веб-сервер роутера. То есть если роутер открывается на 80 порту, то этот порт должен стать исключением. Иначе произойдёт следующее: ни мы, ни даже владелец роутера больше не сможем попасть в панель администрирования роутера пока не будут сброшены настройки на заводские.

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

Обратите внимание, что некоторые роутеры работают не на 80, а на 8080 или 443 порте.

Итак, если веб-интерфейс роутера работает на 80 порту и мы хотим получить доступ к локальным ресурсам устройства с IP 192.168.1.2, то нам нужно установить следующие три правила:

• Переадресацию портов 1-79 на 1-79 порты адреса 192.168.1.2
• Переадресацию портов 81-65534 на 81-65534 порты адреса 192.168.1.2
• Переадресацию порта 65535 на 80 порт адреса 192.168.1.2

Первые два правила с диапазонами (надеюсь) очевидны. Третьим правилом мы перенаправляем запросы, пришедшие на порт 65535, на 80 порт локального компьютера, поскольку там может быть веб-сервер или что-то другое интересное.

Начнём с того, что сделаем контрольный замер, какие именно порты открыты:

sudo nmap 100.69.64.23

Эта команда покажет открытые порты на роутере:

Добавляем первое правило:

Второе:

Третье:

Получаем:

Заново сканируем порты:

sudo nmap 100.69.64.23

Констатируем — нас постигла неудача. 80-й порт — это порт самого роутера, а на устройстве с IP 192.168.1.2 просканированные порты закрыты.

Не отчаиваемся — переделываю все правила на переадресацию портов на IP 192.168.1.3:

И опять сканируем порты:

sudo nmap 100.69.64.23

Поясню, хотя команда Nmap одна и та же, но на самом деле в предыдущий раз мы сканировали порты устройства в локальной сети с IP 192.168.1.2. А последняя команда уже сканирует порты на 192.168.1.3.

А вот здесь нам повезло:

Starting Nmap 7.80 ( https://nmap.org ) at 2019-09-29 09:08 MSK
Nmap scan report for 100.69.64.23
Host is up (0.017s latency).
Not shown: 993 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
23/tcp   open  telnet
80/tcp   open  http
443/tcp  open  https
515/tcp  open  printer
631/tcp  open  ipp
9100/tcp open  jetdirect

Nmap done: 1 IP address (1 host up) scanned in 5.83 seconds

Напомню, что все эти порты, кроме 80, открыты на устройстве, у которого даже нет белого IP адреса, у него IP адрес 192.168.1.3.

А как проверить 80 порт на 192.168.1.3? Делаем это так:

sudo nmap -p 65535 100.69.64.23

Порт оказался закрыт.

Чтобы собрать информацию об отрытых портах, изучим их :

sudo nmap -sV --script=banner 100.69.64.23

Получаем:

PORT     STATE SERVICE    VERSION
21/tcp   open  ftp        Brother/HP printer ftpd 1.13
| banner: 220 FTP print service:V-1.13/Use the network password for the I
|_D if updating.
23/tcp   open  telnet     Brother/HP printer telnetd
|_banner: \x1B[2J\x1B[1;1f
80/tcp   open  http       GoAhead WebServer 2.5.0 (PeerSec MatrixSSL 3.4.2)
|_http-server-header: GoAhead-Webs/2.5.0 PeerSec-MatrixSSL/3.4.2-OPEN
443/tcp  open  ssl/http   Debut embedded httpd 1.20 (Brother/HP printer http admin)
515/tcp  open  printer
631/tcp  open  ipp?
9100/tcp open  jetdirect?
Service Info: Device: printer

Не очень интересно — видимо, это всё функции связанные с принтером.

Чтобы подключиться к HTTPS порту, достаточно открыть ссылку в веб-браузере: https://100.69.64.23:443

А там мы видим интерфейс многофункционального устройства (принтер-копер-сканер) MFC-J5910DW:

Ещё раз для тех, кто потерялся, это устройство с IP адресом 192.168.1.3!

Также я сумел подключиться к FTP:

UDP протокол — что это

UDP — это транспортный протокол пользовательских датаграмм из набора правил TCP/IP. Позволяет отправлять информацию (датаграммы) по IP-сети без предварительного установления соединения и создания специального виртуального канала или путей данных. Официально был разработан в 1 980 году человеком по имени Дэвид П. Рид. Полностью расшифровывается как — User Datagram Protocol.

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

Заголовок UDP весит 8 байтов и состоит всего из четырех значений:

Это порты отправителя и получателя, длина датаграммы и контрольная сумма. Поля, которые помечены на скриншоте желтым цветом — необязательны к использованию в сетях IPv4.

Плюсы UDP протокола — кому он полезен?

Доставка пакетов происходит гораздо быстрее, т.к. он просто не тратит время на все те проверки, установку соединения и т.д., как это делает TCP.

Благодаря этому он так популярен на серверах, которые отвечают на небольшие вопросы от большого количества клиентов, те же DNS сервера, онлайн игры, потоковое видео, например, IPTV, приложения видео/аудио связи.

Отличие UDP от TCP — сравнение

Как вы уже знаете, есть два основных протокола в стеке TCP/IP — это TCP и UDP. Многие задаются в чем между ними разница, а разница по большому счету в «гарантии доставки» данных. Так, TCP требует от получателя подтверждения того, что он получил пакеты данных, а для этого необходимо изначально установленное соединение между узлами. Также, он исключает потерю данных, задержки, использует логическое соединение и т.д. А вот ЮДП этого не делает, поэтому его еще часто называют — «протокол ненадежных датаграмм».

Недостатки:

1. Ненадежный протокол. Не контролирует передачу и соответственно целостность данных, а просто передает их, так данные могут прийти битыми или с дубликатом, или потеряться.
2. Отправляет данные не упорядоченно. Если отправить данные нескольким адресатам, то неизвестно кому первому они придут. В тисипи все это контролируется и нумеруется по порядку.
3. Без проверки доставки, в отличие от своего собрата тисипи.
4. Проверка целостности пакета осуществляется только если он был доставлен и проверяет ее получатель, а в отправитель даже не будет знать доставлен ли пакет.
5. Плохая безопасность. Многие файрволы просто блокируют UDP пакеты, т.к. злоумышленники могут воспользоваться его портами, не устанавливая явных соединений.

Преимущества:

1. Легковесный — быстрая передача. Не нужно предварительно соединение, никаких проверок доставки, упорядочивания, отслеживания соединения. А в TCP все это есть — поэтому он тяжеловесный, еще ему нужно аж три пакета для установления сокет-соединения.
2. Разные соединения. Может быть связь — «один с одним», а может и «один со многими». А вот TCP позволяет только первый вариант.
3. Нагрузка и расходы. Т.к. ЮДП требует куда меньше ресурсов — система грузится куда меньше и покупать более дорогое оборудование нет смысла.
4. Размер заголовка. У UDP заголовок весит всего 8 байтов, а в TCP — 20 байтов, что означает что ему нужна меньшая пропускная способность.

В заключение

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

Как настроить WiFi на «Малине» через консоль?

Другой вариант – это конфигурирование подключения через консоль. Настройка WiFi на Raspberry Pi 3 в терминале не отличается трудоемкостью. Следует отметить, что данный способ даже более быстрый, чем тот, который предполагает использование графического интерфейса.

Для начала следует при помощи nano (конечно, из-под sudo) открыть файл /etc/wpa_supplicant/wpa_supplicant.conf.

В его конец следует дописать несколько строк:

network={

ssid=»NAME_WIRELESS_NETWORK»

psk=»PASSWORD»

}

Значение ssid должно быть таким, какое название имеет беспроводная сеть. Следует отметить, что его нужно указывать без каких-либо искажений. Значение psk, в свою очередь, – это просто пароль от WiFi.

Если вы по какой-то причине не знаете свой SSID, тогда можете воспользоваться специальной утилитой, которая называется iwlist. Для поиска доступных сетей ее следует запускать из-под sudo командой iwlist wlan0 scan.

После того, как написанное было сохранено, система совершит попытку подключения и, если все нормально, та завершится удачей. Затем можно будет применить изменения. Для этого от суперпользователя следует поочередно указать пару команд: ifdown wlan0 и ifup wlan0.

На этом этапе важно знать, что после применения новой конфигурации имя wlan0 станет некорректным. Новое же название интерфейса, в свою очередь, возможно увидеть в листинге ifconfig

Там же напротив пункта inet addr будет присутствовать и IP-адрес, который в текущий момент «Малина» имеет в локальной сети.

Как это выглядит у нас внутри?

• Пользователи по одному из протоколов загружают оригинал видео на наши upload-сервера.
• Там мы разворачиваем протокол.
• По RTMP отправляем на один из серверов трансформации видео.
• Оригинал всегда сохраняем в распределенное хранилище, чтобы ничего не пропало.
• После этого все видео поступают на сервер раздачи.

• Upload-сервера распределены по разным дата-центрам, стоят за разными IP.
• Пользователи приходят, по DNS получают IP.
• Upload-сервер отправляет видео на серверы нарезки, те нарезают и отдают серверам раздачи.
• Под более популярные трансляции мы начинаем добавлять большее количество серверов раздачи.
• Все, что пришло от пользователя, сохраняем в хранилище, чтобы потом создать архив трансляций и ничего не потерять.
• Хранилище отказоустойчивое, распределенное по трем дата-центрам.

ZooKeeperЧто при этом произойдет?

• Пользователь на DNS возьмет следующий IP другого upload-сервера.
• К этому времени ZooKeeper поймет, что сервер в том дата-центре умер, и выберет для другой сервер нарезки.
• Download-серверы узнают, кто теперь отвечает за трансформацию этого стрима и будут это раздавать.

Советы по эффективному использованию VeraCrypt

• После загрузки установщика VeraCrypt проверьте целостность файла с помощью его цифровых подписей, чтобы убедиться, что загруженный файл не был изменен злоумышленником.
• Не забудьте сделать резервную копию ваших файлов перед процессом шифрования (особенно в случае шифрования раздела на месте), чтобы избежать потери данных в случае каких-либо сбоев.
• Создайте загрузочный диск в случае шифрования системного раздела, поскольку это помогает восстановиться в случае сбоя системы.
• Используйте надежные пароли, состоящие из нескольких комбинаций букв, цифр и символов, и аккуратно сохраняйте их, поскольку потеря пароля означает потерю данных.
• Выбирайте алгоритмы хеширования и шифрования в соответствии с вашими требованиями безопасности – чем сложнее алгоритм, тем выше безопасность, но меньше скорость.
• Избегайте монтирования/использования зашифрованных томов на ноутбуках или портативных компьютерах при низком энергопотреблении, поскольку VeraCrypt может не отключать тома автоматически в случаях спящего режима или аналогичных системных методов во время отключения электроэнергии.

Надеюсь, что с помощью приведённых выше руководств вы сможете легко шифровать ваши данные. И да, не забудьте сначала сделать резервную копию своих данных.

Атрибуты

UDP — это простой протокол транспортного уровня, ориентированный на сообщения , который задокументирован в RFC   . Хотя UDP обеспечивает проверку целостности (с помощью контрольной суммы ) заголовка и полезной нагрузки, он не дает никаких гарантий протоколу верхнего уровня для доставки сообщений, а уровень UDP не сохраняет состояние отправленных сообщений UDP. По этой причине UDP иногда называют протоколом ненадежных датаграмм . Если требуется надежность передачи, она должна быть реализована в приложении пользователя.

Ряд атрибутов UDP делают его особенно подходящим для определенных приложений.

• Он ориентирован на транзакции и подходит для простых протоколов запроса-ответа, таких как система доменных имен или протокол сетевого времени .
• Он предоставляет дейтаграммы , подходящие для моделирования других протоколов, таких как IP-туннелирование или удаленный вызов процедур, а также сетевая файловая система .
• Он прост , подходит для начальной загрузки или других целей без полного стека протоколов , таких как DHCP и Trivial File Transfer Protocol .
• Он не имеет состояния , подходит для очень большого числа клиентов, например, в приложениях потокового мультимедиа, таких как IPTV .
• Отсутствие задержек ретрансляции делает его пригодным для приложений реального времени , таких как Voice Over IP , онлайн — игр , и многие протоколы с использованием Real Time Streaming Protocol .
• Поскольку он поддерживает многоадресного , он подходит для широковещательной информации , таких , как во многих видах обнаружения службы и общей информации , такие как Time Protocol Precision и Протокол информации о маршрутизации .

Как работает TCP соединение

Соединение отправителя и получателя (два узла) происходит так:

1. Отправитель отсылает получателю специальный пакет, именуемый SYN, т.е. пригашает к соединению2. Получатель отвечает уже пакетом SYN-ACK, т.е. соглашается3. Отправитель отсылает спец. пакет ACK, т.е. подтверждает, что согласие получено

На этом TCP-соединение успешно установлено и получатель с отправителем могут спокойно обмениваться информацией. При передаче все пакеты данных нумеруются, отсылаются подтверждения о получении каждого из них, а потерянные пересылаются заново.

TCP порты

На каждом компьютере установлено, как минимум несколько программ. И сразу несколько из них могут обмениваться информацией, как же их различать? Именно для этого и были придуманы TCP порты, это по сути уникальный идентификатор соединения между двумя программами.

Номер порта — это число от 0 до 65535 в 16 битном формате, оно указывает какому именно приложению предназначается определенный пакет данных. Т.е. позволяет различным программам, работающим на одном компьютере, независимо друг от друга отправлять и получать информацию.

Есть целый ряд уже зарезервированных портов, которые являются стандартом:

Также, стоит отметить, что порты данного протокола никак не пересекаются с такими же, но у UDP. Так, например, порт: 1234 не пересечется с таким же, но у UDP.

В заключение

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

Зачем сравнивать TCP или что с ним не так

• packet loss — примерно 0,6% пакетов, которые мы отправляем, теряются по пути;
• reordering — перестановка пакетов местами, в реальной жизни довольно редкое явление, но случается в 0,2% случаев;
• jitter — когда пакеты отправляются равномерно, а приходят очередями с задержкой примерно в 50 мс.

Как вычислить RTT

беспроводные сети популярны и нестабильны

• Более 80% пользователей используют беспроводной интернет;
• Параметры беспроводных сетей динамично меняются в зависимости, например, от того, что пользователь повернул за угол;
• Беспроводные сети имеют высокие показатели packet loss, jitter, reordering;
• Фиксированный ассиметричный канал, смена IP-адреса.

TCP в нестабильных сетях

меньше половины канала

• Беспроводные мобильные сети победили и нестабильны.
• TCP не до конца утилизирует канал в нестабильных сетях.
• Потребление контента зависит от скорости интернета: чем выше скорость интернета, тем больше пользователи смотрят, а мы очень любим наших пользователей и хотим, чтобы они смотрели больше.

Зачем сравнивать TCP или что с ним не так

• packet loss — примерно 0,6% пакетов, которые мы отправляем, теряются по пути;
• reordering — перестановка пакетов местами, в реальной жизни довольно редкое явление, но случается в 0,2% случаев;
• jitter — когда пакеты отправляются равномерно, а приходят очередями с задержкой примерно в 50 мс.

Как вычислить RTT

RIPE Atlasбеспроводные сети популярны и нестабильны

• Более 80% пользователей используют беспроводной интернет;
• Параметры беспроводных сетей динамично меняются в зависимости, например, от того, что пользователь повернул за угол;
• Беспроводные сети имеют высокие показатели packet loss, jitter, reordering;
• Фиксированный ассиметричный канал, смена IP-адреса.

TCP в нестабильных сетях

меньше половины канала

• Беспроводные мобильные сети победили и нестабильны.
• TCP не до конца утилизирует канал в нестабильных сетях.
• Потребление контента зависит от скорости интернета: чем выше скорость интернета, тем больше пользователи смотрят, а мы очень любим наших пользователей и хотим, чтобы они смотрели больше.