В данной статье речь пойдет о Wi-Fi мини видеокамере из семейства А9 от китайских производителей. Цель исследования этих камер – расширить возможность их применения, которая ограничена использованием только стандартных приложений для мобильных устройств на базе Android или iOS.

О камерах семейства А9

Стоимость данных видеокамер варьируется от 2$ до 4$ (в зависимости от производителя, типа процессора, наличия ИК подсветки и др.). На известной экспресс торговой площадке её можно найти по запросу «мини-камера A9». Ссылка на англоязычный форум по теме разбора камер А9.

Внешний вид моих подопытных камер представлен на фотографии ниже (и, да, внутри они немного разные).

Типовая видеокамера А9 имеет встроенный аккумулятор, а внешнее питание подается через разъем microUSB. Она может обеспечивать два режима работы с сетью: как точка доступа (AP), и как клиент сети (STA). Режим работы настраивается через стандартное приложение на смартфоне. По умолчанию всегда включен режим АР. IP адрес для камеры в режиме АР может отличаться в зависимости от производителя, у моих подопытных – 192.168.1.1. При проведении исследований этих камер использовалось приложение FtyCamPro рекомендованное производителем, хотя в «интернетах» пишут, что работают эти камеры и с более известным приложением Little Stars. Пользовательский обзор в достаточном объеме представлен на YouTube по запросу «Подключение китайской камеры А9».

Рассматриваемые здесь дешевые видеокамеры построены на основе процессора TXW806-840. Ссылка на сайт производителя чипа TWX806 (только китайский язык) https://www.taixin-semi.com/. В продаже имеются также и аналоги с процессором BK7231, которые несколько дороже. Электронная часть камеры выглядит вот так:

Структурная схема процессора, взятая из официального даташита показана ниже.

Согласно данным от производителя TXW806 — это высокоинтегрированный небольшой многорежимный чип для IoT с частотой 2,4 ГГц. Чип включает в себя 32-битный микроконтроллер, встроенный MJPEG (поддерживает VGA/720P), имеет DVP интерфейс, высокоскоростной хост USB2.0, хост SDMMC, ведомое устройство SDIO2.0, интерфейс RMII MAC, ведущее устройство SPI, UART, IIC, IIS, IR Send/Receive, PWM, GPIO и ADC/DAC, поддерживают запуск программ на SPI Flash. Базовый модуль Wi-Fi TXW806 реализует технологию мультиплексирования с ортогональным частотным разделением каналов (OFDM), обратно совместима с технологией расширения спектра прямой последовательностью (DSSS), дополнительной кодовой манипуляцией (CCK) и поддерживает протокол IEEE 802.11 b/g/n. Wi-Fi поддерживает стандартную полосу пропускания 20 МГц и узкую полосу пропускания 5 МГц/10 МГц, обеспечивая скорость физического уровня 72,2 Мбит/с. Имеет усилитель мощности, малошумящий усилитель LNA, радиочастотный балун, антенный переключатель, модуль управления питанием и т. д. Поддерживает RTOS и сторонние операционные системы, а также предоставляет открытую и простую в использовании среду разработки и отладки.

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

Безоперационное определение сознания камеры

До препарирования камеры было проведено сканирование доступных портов утилитой nmap в Ubuntu, при этом камера была подключена к роутеру в режиме STA. По результатам сканирования, были определены открытые порты камеры:

7070/tcp open rtsp
| fingerprint-strings:
| RTSPRequest:
| RTSP/1.0 200 OK
|_ Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

Из доступных для чтения видеопотока оказался порт 7070 по которому предоставляется потоковое видео и аудио по RTSP. Первые попытки получить видео посредством ПО работающего с протоколом RTSP не принесли успеха. Для этого использовались VLC player и openRTSP под Ubuntu (http://www.live555.com/openRTSP/).
На запрос: /home/live/testProgs# ./openRTSP ‑T 7070 rtsp://192.168.1.1:7070
Камера отвечала:

Итогом такого общения был ответ от камеры:
Failed to get a SDP description for the URL «rtsp://192.168.1.1:7070»: 404 Not Found
При использовании VLC результат был примерно такой же.

Еще отмечу, что камера в режиме STA интенсивно соединялась со сторонними серверами по UDP, IP которых: 170.106.50.82, 146.56.226.66 и 35.156.204.247. Это общение пришлось закрыть фаерволом, на всякий случай. Кстати, фаервол был включен на эти IP уже после тестирования с помощью утилиты openRTSP, на случай если при отсутствии соединения с этими серверами камера будет уходить в глухую оборону и в полное молчание.
P.S. Печально конечно, но IP адреса сторонних серверов потом меняются.

Вскрытие

Следующим шагом исследования было вскрытие корпуса и привлечение паяльника. На фотографиях ниже представлены PCB двух моих камер. Слева уже распаянная для работы, справа – новая, не тронутая. Обратите внимание на контактные площадки.

Да, и давайте камеру слева назовем FTYB, а камеру справа – BATC. Не спрашивайте почему. Дальше, надеюсь, будет понятно.

Контакты на плате слева имеют следующие обозначения: RX_PA9, TX_PA10, PA8, GND и CEN (chip enable). На плате справа аналогичные контакты обозначены несколько иначе: HCK, без обозначения, HDA, GND и nRST. В даташите на процессор TXW806 есть следующая информация:

И таблица о порядке подключения чипа к программатору:

Кроме того, производитель сообщает, что имеется два интерфейса отладки: PA9 (DebugIO) и PA10 (DebugCLK) с внутренним сопротивлением подтягивающего резистора 10 кОм. Когда функция отладки не используется, интерфейс отладки можно использовать как обычный GPIO, и его необходимо настроить с помощью программного обеспечения. Во время компоновки печатной платы должны быть зарезервированы контрольные точки на плате, чтобы облегчить отладку. В то же время PA8, CHIP_EN также необходимо зарезервировать для вспомогательного тестирования.

С помощью переходника USB-TTL (в моем случае на микросхеме CP2102) камера была подключена к последовательному порту компьютера. Кстати! Контакт TX на плате это PA8, а на другой камере TX это HDA! Общение с платой осуществлялось посредством Putty с настройкой COM порта на скорость 1 000 000 (10⁶) бот, все остальные параметры по умолчанию. Было задействовано три точки: GND, PA8 и PA9. Скорость взаимодействия определена опытным путем. На стандартной максимальной скорости 512 000 бот и менее в терминал сыпались нечитаемые знаки. Думаю, что весь лог загрузки приводить не целесообразно, здесь акцентирую внимание лишь на некоторых моментах. В логах загрузки и работы камеры содержатся наименование сборки и дата сборки ПО, наименование клиента (станции), пароль, наименование прошивки, калибровочные параметры для видео сенсора, настройки для АЦП, для TF (SD) карты памяти (пытается ее найти, создать там рабочие папки для записи видео и фото), настройки сети Wi-Fi (MAC, FLAGS, UP LINK_UP ETHARP IGMP, ip address 192.168.1.1, gateway, net mask), информация о состоянии системы (температура чипа, рабочая частота, свободная память, работающие процессы и уровни загрузки ими ЦП), например:

• начало загрузки, с наименованием сборки ПО выглядит так:

• сообщение о разрешении матрицы сенсора:

•  информация о том, что открытым является порт 7070:

Соответственно, полный путь к устройству для приема потокового видео будет rtsp://192.168.1.1:7070/webcam
• данные о соединении с сетью:

• данные о состоянии системы:

• данные о запущенных процессах:

При подключении смартфона и открытии приложения FtyCamPro:
• настройка соединения со смартфоном:

• вход пользователя и начало передачи видео:

• запрос на синхронизацию времени:

Ну, наверное, это все что мне показалось понятным и интересным. Далее камера была протестирована на предмет приема информации по линии RX камеры, и, о чудо, она откликалась на нажатие кнопок на клавиатуре ПК. Изучение даташитов сильно не помогло, разве что в описании для платы разработчика (development board) для TXW806 было вскользь отмечено об АТ командах. На простой запрос к камере «AT+» (через «ctrl+c – ctrl+v») камера выдала список из 40 возможных команд:

Конечно, из любопытства пришлось немного с ними побаловаться, так как поиск смысла этих команд по просторам сети ничего путного не дал. В результате опытов было выявлено несколько интересных (но не сильно полезных) команд. Вот некоторые из них:
AT+PRINT_PERIOD=1000 – установка задержки по времени выдачи в терминал информации, единица измерения – мс. Если установить значение 0, печать отключается;
AT+REG_RD= 0x01 – чтение данных из регистра 0x01;
AT+REG_WT=0x20001000, 0x123 – запись 0x123 в регистр 0x20001000;
AT+BSS_BW=20 – изменение полосы пропускания Wi-Fi.
В общем, для выполнения задачи по трансляции видео выявить пользу АТ команд мне не удалось.

Результаты перехвата потока информации по беспроводной сети

Для перехвата сетевого трафика между камерой и смартфоном использовалось приложение PCAPdroid (установленное на смартфоне), для перехвата трафика между ПК и камерой – Wireshark. Для анализа шестнадцатеричного кода использовался HxD Hex Editor. (https://mh-nexus.de/en/hxd/ редактор hex, https://www.wireshark.org Wireshark).
По умолчанию номер порта на моих подопытных камерах для обмена по UDP был постоянный – 32108 (см. выше результаты nmap), номер порта на смартфоне назначался автоматически и отличался в зависимости от сессии. Из полученных данных выделялись только UDP пакеты, а из них бралась только часть пакета с данными.

Полный дамп трафика, наверное, приводить не имеет смыла, здесь приведу только анализ части дампа общения камеры со смартфоном.

Обозначения: # – пакет от смартфона, @ – пакет от камеры. Данные представлены в шестнадцатеричном виде.

Номера пакетов Wireshark естественно будут отличаться от ваших. В первой группе данных (выделено желтым цветом) первый байт всегда f1, это так называемый «magic number». Второй байт этой группы идентифицирует запрос, следующим образом:
42 – «приветствие», P2pRdy
e0 – «запрос проверки состояния», P2PAlive
e1 – «ответ на запрос проверки состояния», P2PAliveAck
Вторая группа данных (выделено голубым цветом) это два байта обозначающие размер основных данных:

Порядок байт в группе – big endian, то есть 0x0014 – 20 байт, 0х0123 – 291 байт
В третьем (от смартфона) и седьмом (от камеры) пакетах, обозначающих, в моем понимании, обмен «приветствиями», в основных данных содержится наименование камеры или сети FTYB931188RLTOV, где цифры указаны в hex (0x0E3574 – 931188).

Наименование второй подопытной камеры BATC-185207-YDEIB и соответствующая часть дампа пакета UDP.

Ну и наконец, проверка состояния f1e0: пакет 4 от смартфона это запрос, пакет 9 от камеры f1e1 – ответ, и наоборот пакет 6 – запрос от камеры, пакет 8 – ответ смартфона. В пакетах с запросом проверки состояния передаются только заголовки, данные отсутствуют.
Следующие после пакетов «приветствия» и опроса состояния идут пакеты авторизации.

В пакете 10 от смартфона сообщается:
f1d0 (поз. группы 1) – данные необходимо принять и на них ответить;
00b0 (поз. гр. 2) – размер основных данных 176 байт;
d100 (поз. гр. 3) – маркер;
0000 (поз. гр. 4) – номер отправляемого пакета, который необходимо будет подтвердить при ответе;
110a (поз. гр. 5) – стартовые байты;
2010 (поз. гр. 6) – байты, сообщающие что будет проводиться авторизация пользователя
Байты 6065 6c68 6f01 (выделены песочным цветом, поз. 12,13,14) это ничто иное как логин и пароль (они между собой совпадают, см. выше логи с последовательного порта). Обратите внимание, что тут применяется простой метод шифрования:
my_byte=(my_byte%2==0)?my_byte+1:my_byte-1 и наш «’elho» становится «admin»:

В пакете 11 содержится ответ камеры, что она приняла пакет с номером 0000 от смартфона, поэтому и размер основных данных 0х0006, куда входят 0000 (позиция 5 группы данных). В пакете 12 камера отправляет запрос (f1d0) смартфону с данными о том, что пользователь авторизован (2011 поз. 6) и «выдаёт» смартфону «ticket» (см. выше логи последовательного порта) – «7669 3942» (поз.11, 12, выделено розовым цветом). «Ticket» зашифрован тем же методом что и имя пользователя и выдается один раз на всю сессию, но каждый раз новый. В пакете 13 смартфон отвечает камере (f1d1), что принял пакет с номером 0000 (поз. 5) от камеры.

Пакет 14 от смартфона к камере как раз и отличает одну камеру от другой. Этот дамп для камеры FTYB. В пакете содержится xsecret_key=AIzaSyB-boxOG5n6AbKMLAOwmm1PZzqPkyZjMwc (см. выше дамп последовательного порта). Этот «секретный ключ» выделен шрифтом красного цвета. В пакете 14 он представлен в зашифрованном виде. Камера BATC не имеет xsecret_key и поэтому в дампах трафика сетевого обмена между камерой и смартфоном такой пакет отсутствует. Желтым выделено название камеры/сети – FTYB931188RLTOV, часть, содержащая цифры теперь представлена как текстовая в формате UTF-8. Также в пакете 14 указан расшифрованный ticket – «7768 3843» (выделено коричневым цветом, первая строка 9 и 10 группы), в формате UTF-8 это текст «wh8C».

В пакете 15 смартфон в запросе (f1d0) сообщает, что приложение пытается синхронизировать время для камеры на сайте time.windows.com (зашифрованные байты, выделены красным), но смартфон подключен к камере как к AP, и поэтому попасть туда никак не может! Следовательно, время на камере не синхронизируется.
В пакете 16 смартфон делает запрос на соединение уже имея при себе билет (0810, поз. 6) и его указывая (поз.9 и 10). Пакет 17 от смартфона дублирует пакет 15 только уже без ссылки на time.windows.com.
Пакетом 18 камера «отчитывается» перед смартфоном, что получила все его пакеты (номера полученных пакетов показаны красным цветом, поз. 5-8).
В общем-то дальше уже не важно что отправляет нам камера, главное перед ней отчитываться, что получены все ее пакеты и на вопрос «как дела? – f1e0», всегда отвечать «все отлично» – f1e1. Это будет понятно из кода на Python представленного далее.
В определенный момент камера перестанет присылать вопросы «как дела?». Это видно по логам с любой камеры и будет ожидать от смартфона «серьезных» предложений. Которые выглядят следующим образом:

После чего камера подтвердит их получение, пришлёт пару «ненужных» запросов, на которые также надо будет просто отчитаться о получении. А затем камера пришлет первый пакет, в котором так называемый маркер измениться. Это и будет пакет с полезными данными!

Маркер (поз. 3, показано красным) с d100 сменился на d101, что говорит о пакете с полезной для нас информацией (аудио или видео). В данном случае, в пакете 59 передан фрагмент звука 55aa 15a8 (выделено желтым, поз. 5 и 6) – AUDIO_HEADER.

И в пакете 60 смартфон отвечает, что принял пакет 0001 (показано желтым, поз. 5) от камеры. При этом маркер у него будет d201 (поз. 3). Дальше камера беспрерывно начнет присылать jpeg и звук. А смартфону важно отчитываться за полученные пакеты.

Видно, что в пакете 61 размером 1028 байт с маркером d101 есть заголовок jpeg – ffd8. Пакеты с jpeg идут с размером 1028 байт и только у пакета, завершающего полный видеокадр, размер может быть меньше (в конце пакета должно быть ffd9).
Для примера, восстановленный (путем копирования пакетов из Wireshark в редактор HxD) фрагмент видео с моей кошкой!

Подробнее о структуре jpeg файла можно почитать на https://habr.com/ru/articles/454944/ (автор @SLY_G)

Реализация на Python

Программа имитирует общение камеры BATC с приложением на смартфоне по логике обмена пакетами описанной выше. Камера включена в режиме AP. В программе не предусмотрена отправка пакета с xsecret_key. Полученные кадры потока MJPEG сохраняются в локальную папку на ПК. Звук игнорируется. Для завершения работы программы используется магическое сочетание клавиш «ctrl+Break». Вот сам текст программы:

Hidden text

import socket
from PIL import Image, ImageDraw, ImageFont
import time, io
def pack_size(mydata) :
    #преобразуем размер данных в 2 байта hex для вставки в пакет
    return (len(bytes.fromhex(mydata)).to_bytes(2, byteorder='big'))
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
BROADCAST_CAM_PORT = 32108
cam_name='42415443000000000002d3775944454942000000' # имя камеры/сети BATC185207YDEIB, 185207 в hex
MSG_HELLO=bytes.fromhex('f1420014')+bytes.fromhex(cam_name)
MSG_E0_Q=b'xf1xe0x00x00' # Ты как? Q-question
MSG_E1_ANSW=b'xf1xe1x00x00' # Норм! ANSW - answer
HDR_D0=b'xf1xd0' # принимай!
HDR_D1=b'xf1xd1' # принял!
data_login='d100'+'0000'+'110a2010a400ff'+'00'*5+'6f'+'01'*27+'60656c686f'+'01'*123+'60656c68'
MSG_LGN_ADMIN=HDR_D0+pack_size(data_login)+bytes.fromhex(data_login)
MSG_TICKET_TIME_START=HDR_D0+bytes.fromhex('0060'+'d100'+'0001'+'110a'+'401054000000')
MSG_TICKET_TIME_END=bytes.fromhex('d1d4fefe'+'01'*8+'75686c642f76686f656e76722f626e6c'+
'01'*48+'230e0e67')
MSG_TICKET_START=HDR_D0+bytes.fromhex('0010'+'d100'+'0002'+'110a'+'081004000000')
##########################
MSG_TICKET_START_2=HDR_D0+bytes.fromhex('0018d1000003'+'110a18300c000000')
MSG_TICKET_END_2=bytes.fromhex('0301010100010101')
MSG_TICKET_LONG_START=HDR_D0+bytes.fromhex('0114d1000004'+'110a103008010000')
MSG_TICKET_LONG_END=bytes.fromhex('01'*260)
MSG_TICKET_TIME_START_2=HDR_D0+bytes.fromhex('0060'+'d100'+'0005'+'110a'+'401054000000')
MSG_TICKET_TIME_END_2=bytes.fromhex('d1d4fefe'+'01'*8+'75686c642f76686f656e76722f626e6c'+
'01'*48+'240e0e67')
###########################
def take_ticket (indata):
    ticket=indata.hex(' ').split(' ')
    hex_numbers = [ticket[len(ticket)-8], ticket[len(ticket)-7], ticket[len(ticket)-6], ticket[len(ticket)-5]]
    dec_numbers = [int(hex, 16) for hex in hex_numbers]
    for i in range(0, len(dec_numbers)):
        if dec_numbers[i]%2==0:
            dec_numbers[i]=(dec_numbers[i]+1)
        else:
            dec_numbers[i]=(dec_numbers[i]-1)
    return (bytearray(dec_numbers)) # да, можно было бы напрямую работать с hex
def my_send (mybyte):
    s.sendto(mybyte, ('192.168.1.1', BROADCAST_CAM_PORT))
    print ('I SEND: ', mybyte)
fnum=0 # счетчик для кадров MJPEG
def take_full_jpeg (jpeg_data):
    jpeg_return=bytes.fromhex(''.join(jpeg_data[4:]))
    data_send=['d201','0001']
    data_send.append(jpeg_data[3])
    my_send (HDR_D1+pack_size(''.join(data_send))+bytes.fromhex(''.join(data_send)))
    jpeg_recvdata=s.recvfrom(4096)[0]
    while jpeg_recvdata.find(b'xffxd9') == -1 :
        jpeg_return=jpeg_return+jpeg_recvdata[8:]
        data_send.clear()
        data_send=['d201','0001']
        data_send.append(jpeg_recvdata[6:8].hex())
        my_send (HDR_D1+pack_size(''.join(data_send))+bytes.fromhex(''.join(data_send)))
        if (jpeg_recvdata[4:6]!= b'xd1x01') :
            tmp=s.recvfrom(4096)[0]
            recive_explain(tmp)
        jpeg_recvdata=s.recvfrom(4096)[0]
    if jpeg_recvdata.find(b'xffxd9') != -1 :
        print ('This is the end!')
        jpeg_return=jpeg_return+jpeg_recvdata[8:]
    global fnum
    fnum=fnum+1
    t = time.localtime()
    current_time = time.strftime("%D %H:%M:%S", t) # на каждый кадр наносим метку с датой и временем
    myfont = ImageFont.truetype("arial.ttf", 20)
    try:
        io_bytes = io.BytesIO(jpeg_return)
        im = Image.open(io_bytes)
        draw_text = ImageDraw.Draw(im)
        draw_text.text((10,10),current_time,fill=('#1C0606'), font=myfont)
        im.save('D:pywrkcammy_jpegpic'+str(fnum)+'.jpeg')
    except:
        pass
pac_num=list() # список с номерами полученных от камеры пакетов
def answer_to_cam(datinlist):
    k='d200'
    global pac_num
    if datinlist[2] == 'd101' :
        k='d201'
        pac_num.clear()
        if (datinlist[4]=='ffd8') : take_full_jpeg(datinlist)
    if datinlist[3] in pac_num :
        pac_num.clear()
        pac_num.append (datinlist[3])
    else :
        pac_num.append (datinlist[3])
    data_send=[k,'0001']
    for x in range(0, len(pac_num)):data_send.append(pac_num[x])
    my_send (HDR_D1+pack_size(''.join(data_send))+bytes.fromhex(''.join(data_send)))
def recive_explain(mydata):
    partion=mydata.hex()
    data_in_list=[]
    for x in range (0, len (partion), 4) :
        if (x>len (partion)) : break
        data_in_list.append(partion[x:x+4])
    if data_in_list[0]=='f1d0' :
        answer_to_cam(data_in_list)
    if data_in_list[0]=='f1d1' :
        print ('')
    if data_in_list[0]=='f1e0' :
        my_send (MSG_E1_ANSW)
        my_send (MSG_E0_Q)
    if data_in_list[0]=='f1e1' :
        print ('#cam answer tel - Fine!')
    if data_in_list[0]=='f142' :
        print ('#cam send to tel MSG_HELLO')
    return (data_in_list[0])
def main():
    i=0
    my_send (MSG_HELLO)
    my_send (MSG_E0_Q)
    while (recive_explain(s.recvfrom(4096)[0])) != 'f1e1' : print ('In while f1e0')
    my_send (MSG_LGN_ADMIN)
    data=s.recvfrom(4096)
    while data[0].find(b'xf1xd0x00x18') != 0 :
        data=s.recvfrom(4096)
        recive_explain(data[0])
    my_ticket=take_ticket(data[0])
    print(f"my_ticket - {my_ticket}")
    my_send (MSG_E0_Q)
    recive_explain(s.recvfrom(4096)[0])
    my_send (MSG_TICKET_TIME_START+my_ticket+MSG_TICKET_TIME_END)
    my_send (MSG_TICKET_START+my_ticket)
    while (recive_explain(s.recvfrom(4096)[0])) != 'f1d0' : print ('In while d0')
    for i in range(0, 15):
        what_rec=recive_explain(s.recvfrom(4096)[0])
        if what_rec == 'f1e0' : break
    my_send (MSG_TICKET_START_2+my_ticket+MSG_TICKET_END_2) #то, самое "серьезное" предложение
    my_send (MSG_TICKET_LONG_START+my_ticket+MSG_TICKET_LONG_END)
    my_send (MSG_TICKET_TIME_START_2+my_ticket+MSG_TICKET_TIME_END_2)
    while True:
        tt=recive_explain(s.recvfrom(4096)[0]) #получаем постоянный поток кадров в формате jpeg
if __name__ == "__main__":
    main()

Результат работы программы, мой Кадр – кошка Фрося.

P.S. 2
Нашёл это https://github.com/DavidVentura/cam-reverse «сокровище» уже после своих мучений.

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

Иногда может понадобиться настроить собственную сеть доставки контента. Давайте рассмотрим, для чего это нужно и как это сделать.

^{Это наша будущая CDN из 5 серверов, которая будет раздавать контент на весь мир}

Зачем настраивать собственный CDN

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

• расходы на услуги стороннего CDN сервиса существенно превышают затраты на создание своего
• когда хотим иметь гарантированный канал и фиксированное дисковое пространство для постоянного кэша, а не разделять их с другими клиентами
• если необходимы особые настройки хранения и доставки контента
• в случае размещения нескольких production-серверов в разных регионах для ускорения доставки динамических данных
• если не хотим, чтобы сторонние сервисы собирали и хранили данные о наших пользователях, например: IP адрес, запрашиваемые URL, и т.п.
• когда в нужном нам регионе у других сервисов нет точек присутствия

В большинстве других случаев лучше воспользоваться услугами платного CDN сервиса.

Готовимся к запуску

Для реализации задуманного нам понадобится:

1. Несколько серверов в разных регионах, можно виртуальных (VPS)
2. Отдельный субдомен. В нашем примере это будет cdn.nashsait.org
3. geoDNS сервис, с помощью которого пользователь, обращаясь к субдомену, будет направлен на ближайший в его регионе сервер

Арендуем сервера и настраиваем geoDNS

Сперва определимся, где преимущественно находится основная пользовательская аудитория. В нашем примере это Казахстан, поэтому мы определенно должны иметь точку присутствия в этом регионе, чтобы у большинства пользователей всё работало максимально быстро. Остальные сервера будут «разбросаны» по миру. Арендовать их удобнее всего у хостинг-провайдеров, предлагающих сразу несколько локаций для размещения.

Мы закажем 5 виртуальных серверов с 25GB диска, безлимитным трафиком и последним Debian или Ubuntu:

Казахстан, ip: 86.104.73.235

Нидерланды, ip: 94.232.245.17

США, ip: 45.89.53.214

Бразилия, ip: 95.164.5.110

Япония, ip: 5.253.41.115

Чтобы пользователь при обращении к cdn.nashsait.org направлялся на ближайший для него сервер, нам нужен рабочий DNS с функцией geoDNS. Его можно настроить самому или использовать готовый сервис, например СlouDNS.

Мы будем использовать СlouDNS: регистрируемся, выбираем тариф GeoDNS и в личном кабинете добавляем новую DNS-зону, указав наш главный домен nashsait.org. В процессе создания зоны будет предложено выбрать для домена будущие NS-сервера. Отметим все доступные и на будущее скопируем их себе в отдельный текстовый файлик.

Если главный домен уже нами используется (например, на нем размещен сайт или работает электронная почта), то сразу после создания зоны нужно добавить существующие рабочие DNS-записи.

Затем для субдомена cdn.nashsait.org нужно создать несколько A-записей, каждая из которых в зависимости от региона пользователя будет указывать на один из наших CDN серверов. В качестве регионов можно указывать континенты, страны или отдельные штаты (для США и Канады). Начнем с Южной Америки и направим все запросы оттуда на сервер в Бразилии:

Сделаем то же самое для других регионов, при этом один из них рекомендуется добавить как регион «по умолчанию». В итоге список A-записей будет выглядеть так:

Самая нижняя запись «Default» означает, что все остальные, не указанные в других записях регионы (Европа, Африка, спутниковый интернет и т.п.), будут направляться на сервер в Нидерландах.

На этом настройка geoDNS завершена, осталось зайти на сайт регистратора нашего домена и изменить NS-сервера для nashsait.org на те, что мы ранее скопировали в отдельный текстовый файл.

Добавление SSL сертификатов

Чтобы CDN работал по протоколу HTTPS, мы установим бесплатный SSL сертификат от Let’s Encrypt. Это удобно делать с помощью ACME Shell скрипта, который позволяет валидировать домен по DNS через ClouDNS API.

Достаточно установить acme.sh на одном из серверов, а затем скопировать полученный сертификат на все остальные. Выполним установку на сервере в Нидерландах:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

Стоит заметить, что во время установки создается отдельная CRON задача для автоматического обновления сертификатов в будущем.

При выдаче сертификата проверка домена будет происходить через DNS, а необходимые для этого записи будут автоматически добавлены на ClouDNS через их API. Поэтому в учетной записи на ClouDNS в меню «API&Resellers» нам нужно создать нового API пользователя, придумав для него пароль. Полученный <auth-id> с паролем укажем в файле ~/.acme.sh/dnsapi/dns_cloudns.sh (не перепутайте с похожим dns_clouddns.sh). Вот строки файла, которые нужно раскоментировать и отредактировать:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"

Далее запустим получение SSL сертификата для cdn.nashsait.org

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.nashsait.org --server letsencrypt --reloadcmd "service nginx reload"

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

Запомним эти пути, они будут нужны при копировании сертификата на другие CDN локации и для настройки веб-сервера. Ошибка «Reload error for» не существенна и при дальнейшем обновлении сертификатов на полностью настроенном сервере ее не будет.

Войдем на четыре других сервера и скопируем на каждый полученный сертификат, создав соответствующие директории, чтобы пути к файлам были везде одинаковы:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.nashsait.org_ecc/
root@cdn:~# scp -r root@94.232.245.17:/root/.acme.sh/cdn.nashsait.org_ecc/* /root/.acme.sh/cdn.nashsait.org_ecc/

Это копирование нужно сделать регулярным, поэтому на этих же четырех серверах в CRON добавляем ежедневный запуск команды:

scp -r root@94.232.245.17:/root/.acme.sh/cdn.nashsait.org_ecc/* /root/.acme.sh/cdn.nashsait.org_ecc/ && service nginx reload

Чтобы всё работало, доступ нидерландскому серверу со всех остальных четырех должен быть настроен по ключу, без необходимости ввода пароля. Обязательно сделайте это.

Настройка Nginx

На всех пяти CDN точках, в качестве веб-сервера для раздачи контента мы установим Nginx и настроим его как кэширующий proxy-сервер:

root@cdn:~# apt update
root@cdn:~# apt install nginx

Дефолтный файл конфига /etc/nginx/nginx.conf заменим на приведенный ниже:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
events {
    worker_connections 4096;
    multi_accept on;
}
http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    types_hash_max_size 2048;
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    access_log off;
    error_log /var/log/nginx/error.log;
    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_vary on;
    gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml;
    gunzip on;
    proxy_temp_path    /var/cache/tmp;
    proxy_cache_path   /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=14d;
    proxy_cache_bypass $http_x_update;
server {
  listen 443 ssl;
  server_name cdn.nashsait.org;
  ssl_certificate /root/.acme.sh/cdn.nashsait.org_ecc/fullchain.cer;
  ssl_certificate_key /root/.acme.sh/cdn.nashsait.org_ecc/cdn.nashsait.org.key;
  location / {
    proxy_cache cdn;
    proxy_cache_key $uri$is_args$args;
    proxy_cache_valid 90d;
    proxy_pass https://nashsait.org;
    }
  }
}

В этом конфиге отредактируем:

• max_size — размер кэша, не больше доступного на диске места
• inactive — срок хранения кэшированных файлов, к которым не было обращений
• ssl_certificate и ssl_certificate_key — абсолютные пути к файлам SSL сертификата
• proxy_cache_valid — срок хранения кэшированных файлов
• proxy_pass — URL сайта, с которого CDN загружает и кэширует файлы. У нас это nashsait.org

Обратите внимание на схожесть директив inactive и proxy_cache_valid. Чтобы не запутаться, рассмотрим их на простом примере. Вот что происходит при inactive=14d и proxy_cache_valid 90d:

• если файл не будет запрошен в течение 14 дней, то он удаляется
• если файл будет запрашиваться хотя бы раз в 14 дней, то он начнет считаться устаревшим только по истечении 90 дней, и после этого срока при очередном запросе Nginx загрузит его по новой с оригинального сервера

Указав нужные значения в nginx.conf, применим их:

root@cdn:~# service nginx reload

Обратите внимание, что Nginx не будет кэшировать данные, если они получены с оригинального сервера с какими-либо cookies (заголовок «Set-Cookie»). Игнорировать это условие можно, добавив в конфиг следующие директивы:

proxy_ignore_headers "Set-Cookie";
proxy_hide_header "Set-Cookie";

На этом настройка завершена. Дополнительно можно создать bash-скрипт для очищения кэша:

#!/bin/bash
if [ -z "$1" ]
then
    echo "Purging all cache"
    rm -rf /var/cache/cdn/*
else
    echo "Purging $1"
    FILE=`echo -n "$1" | md5sum | awk '{print $1}'`
    FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE}
    rm -f "${FULLPATH}"
fi

Запуск этого скрипта удалит весь кэш, отдельный файл удаляется так:

root@cdn:~# ./purge.sh /test.jpg

Тестируем наш CDN

С помощью онлайн ping-сервисов можно проверить пинги к нашей сети доставки контента из разных мест:

Пинг хороший, теперь разместим в корне основного сайта картинку test.jpg и на сервисе Ping-Admin посмотрим на скорость ее загрузки через CDN:

Всё работает, контент раздается быстро. Теперь у нас есть собственный рабочий CDN с безлимитным трафиком и точками присутствия на всех континентах.
 

Гайд по настройке деплоя через ssh и docker контейнеры в github. Развертывать будем на сервер под управлением Ubuntu 23.04.

Предустановка сервера

Нам понадобится docker-compose.

Настроим доступы к нашему серверу

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

sudo adduser smith

Разрешим для нашего юзера выполнять docker команды без пароля

sudo usermod -aG docker smith

Для доступа из github, создадим ssh ключ и его же добавим в авторизованные ключи:

ssh-keygen
cp .ssh/id_rsa.pub .ssh/authorized_keys

Настройка github

Создадим PAT (персональный токен доступа) на странице — Personal Access Tokens (Classic) (github.com) . Важно его сохранить на время куда-нибудь. Если делаете для организации, то у неё другая страница.

Добавляем секреты в репу (settings -> Secrets -> Actions):

• PAT — персональный токен

• SSH_HOST — хост машины, на которой будем разворачивать контейнер

• SSH_PRIVATE_KEY — приватный ключ юзера smith

• SSH_USER — имя юзера, smith

Создаем в репе файл docker-compose.yml с нашим сервисом:

services:
  example_app:
    container_name: example_app
    image: ghcr.io/your_nick/example_app:latest
    volumes:
      - ~/data:/app/data

Настраиваем github workflow, файл .github/workflow/deploy.yml:

name: deploy
on:
  pull_request:
    types:
      - closed
    branches: [ "main" ]
jobs:
    build:
        name: Build
        runs-on: ubuntu-latest
        steps:
        - uses: actions/checkout@v3
        - name: Login
          run: |
            echo ${{ secrets.PAT }} | docker login ghcr.io -u ${{ github.actor }} --password-stdin
        - name: Build and Publish
          run: |
            docker build . --tag ${{ env.DOCKER_TAG }}
            docker push ${{ env.DOCKER_TAG }}
    deploy:
        name: Deploy
        runs-on: ubuntu-latest
        steps:
        - uses: actions/checkout@v4
        - name: install ssh keys
          # check this thread to understand why its needed:
          # <https://stackoverflow.com/a/70447517>
          run: |
            install -m 600 -D /dev/null ~/.ssh/id_rsa
            echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
            ssh-keyscan -H ${{ secrets.SSH_HOST }} > ~/.ssh/known_hosts
        - name: create docker compose config
          run: |
            cat docker-compose.yml | envsubst > docker-compose-secret.yml
        - name: copy docker compose config
          run: scp docker-compose-secret.yml ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }}:docker-compose.yml
        - name: connect and pull
          run: ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "docker-compose pull && docker-compose up -d && exit"
        - name: cleanup config
          if: always()
          run: ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "rm docker-compose.yml"
        - name: cleanup keys
          if: always()
          run: rm -rf ~/.ssh docker-compose-secret.yml

В данном случае сборка и деплой будет при мёрже пул-реквеста.

Docker-compose будет скачивать образ из ghcr.io без кредов, по этому нужно сделать наш пакет публичным. На странице профиля github смотрим вкладку packages. Выбираем пакет и в разделе Package settings открываем доступ.

Есть опция сделать работу с приватным пакетом, тогда нужно PAT везде использовать, будет чуть сложнее конфиг workflow.

P.S.:

На этом всё. Напишите, как вы разворачиваете с помощью github свои проекты. Вероятно мой вариант не самый удобный.

Про Jetpack Compose на сегодняшний день слышал, пожалуй, каждый android-разработчик. Некоторым уже удалось «затащить его в прод», кто-то пробовал его в своих пет-проектах, а кто-то до сих пор сомневается в его целесообразности. Ведь на первый взгляд мы имеем все тоже самое: <TextView> заменили на Text(), Box() очень похож на <FrameLayout>  и др. Единственное, что сразу произвело впечатление — новые Lazy-списки, которые являются заменой привычного RecyclerView и позволяют писать меньше кода. Но, опять же, скопировать и подправить адаптер под очередной экран это уже привычное действие и оно не занимает много времени, а само действие отработано до автоматизма. К числу сомневающихся и, возможно совсем немного lazy, можно было отнести и меня. Но несколько задач, отличных от рутинного перекрашивания кнопок, заставили меня пересмотреть свое отношение к Compose. 

Случай первый. Дано: макет в фигме следующего вида

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

Как такое делать я не знал. Stackoverflow выдал несколько решений, от которых я начал нервничать. В одном из них была реализация через <Table>. Когда про него вспоминали последний раз? Другие решения были на базе RecyclerView (уже лучше) — кастомные LayoutManager или декораторы. Но главная причина, по которой я отверг эти решения, — ячейки имели статические размеры, а в моем случае высота зависит от текста в первой колонке. Желания прокидывать размеры и пересчитывать высоты ячеек в списке у меня не было, и я снова вернулся к гуглу.

На этом этапе я решил не игнорировать ссылки, которые вели на статьи с Jetpack Compose. Оказывается в LazyColumn/LazyRow помимо item-элементов были добавлены (пока еще Experimental) stickyHeaders (https://developer.android.com/jetpack/compose/lists#sticky-headers). 

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

Тогда начало нашей Compose-функции (назовем ее по-простому DataTable) будет выглядеть так:

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

Время строить таблицу:

Используется LazyRow, так как нужен именно горизонтальный скролл. В stickyHeader задаем фиксированный столбец. В itemsIndexed будем отрисовывать остальные столбцы с «галочками». Если запустить наш код на данном этапе, то экран будет выглядеть вот так:

Некрасиво.

Как видно, изначальная проблема с высотами ячеек при таком подходе все равно остается, поэтому поищем способ ее решения. У Modifier в доступных функциях есть колбэк onGloballyPositioned. Он возвращает координаты элемента на экране после его отрисовки и через них мы будем находить высоту. Для «прокидывания» высот в другие ячейки я использовал mutableState:

Ключ — индекс элемента(можно позволить, поскольку кол-во ячеек во всех столбцах одинаково), значение — высота.

Конечный код LazyRow элемента будет иметь вид: 

Первым создается stickyHeader. После заполнения ячеек контентом, высчитываются высоты и сохраняются в mutableState. 

После отрисовываются столбцы с «галочками». Из mutableState берутся высоты. В верху столбца (для index == 0) ставится картинка.

Запускаем, получаем такой экран, радуемся результату:

Вот так ленивый список сэкономил кучу времени ленивому разработчику и дал мощный пинокзаряд мотивации для изучения Jetpack Compose.

Посмотреть как работает можно тут: https://play.google.com/store/apps/details?id=su.art.spbrealty&hl=ru 

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

В stickyHeader можно поместить любую @Composable — функцию, а значит подход из первого случая будет работать и здесь. Список будет иметь вид:

Сначала размещаем элементы, которые будут скрываться под тулбаром, затем stickyHeader, после — все остальное.

По итогу имеем такой экран:

Посмотреть можно здесь : https://play.google.com/store/search?q=мой%20теле2&c=apps&hl=ru

Случай третий. Кнопка. В данном случае было необходимо разработать экран объявления. При создании макета дизайнеры вдохновлялись Авито, в частности поведением кнопки «написать автору объявления»:

Длинный экран со скроллом. У кнопки «Написать» есть свое место на этом экране. Но если пользователь не дошел до этого места,  то кнопка должна быть видна поверх контента. 

Первой мыслью было поискать в документации stickyFooter, поскольку это как stickyHeader, но внизу. Но, к сожалению, разработчики Google не посчитали нужным такой элемент. И тут у меня появилась безумная идея. 

Что будет, если у LazyColumn задать параметр reverseLayout = true? Будет ли stickyHeader «липнуть» к низу экрана? Как оказалось — будет. Дело за малым: переворачиваем порядок в списке задом наперед и получаем желаемый вид экрана:

Если вы еще не используете Compose в своих проектах, то определенно стоит подумать о том, что бы начать, поскольку он позволяет делать сложные вещи простыми и, что самое главное, экономит время (и нервы).

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

Статью подготовил Илья Кубышкин, Android- разработчик в e-legion

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

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

Ключевой аспект использования Монте-Карло в финансах — это его способность учитывать и анализировать волатильность и дрейф курсов валют. Для повышения точности моделирования и реалистичности получаемых данных часто применяется ГАРЧ модель (Generalized Autoregressive Conditional Heteroskedasticity). ГАРЧ помогает адекватно оценить и моделировать изменчивость волатильности, что является критичным при анализе финансовых временных рядов.

Идейно код выполнялся без готовых реализованных методов из различных либ, такое решение было принято для ознакомления с данным математическим аппаратом.

Проект использует следующие библиотеки и инструменты:

• yfinance для загрузки финансовых данных.

• numpy и pandas для обработки данных.

• matplotlib для визуализации данных.

• scipy и arch для статистического анализа и моделирования.

Импорт и подготовка данных

Для анализа и симуляции курса валют мы используем исторические данные по валютным парам USD/RUB и EUR/RUB, загруженные через библиотеку yfinance. Эти данные обеспечивают основу для нашего стохастического моделирования, начиная с 2013 года и заканчивая апрелем 2023 года. Сей временной промежуток был выбран, для того чтобы при сравнении сгенерированных значений с реальным учитывалось меньше дискретных значений из «линейного» поведения курса и моделировалось наиболее волатильное поведение курса.

Я брал отрезки [2004;2023], [2008;2020], [2010;2023]и т.д, и каждый раз у меня получался схожий временной ряд с временным рядом «спокойного» поведения доллара. Надеюсь, объяснил. Продолжим!

Анализируемые данные включают закрытие дня для каждой валюты, что позволяет вычислить дневные возвраты и волатильность.

Коротко о данных

# Загрузка исторических данных о валютных курсах
data = yf.download("USDRUB=X EURRUB=X", start="2013-01-01", end="2023-04-13")

Из этих данных мы выбираем курс на закрытии

usd_rates = data['Close']['USDRUB=X'].dropna()
eur_rates = data['Close']['EURRUB=X'].dropna()

Описание функций для симуляции

1. Функция simulate_exchange_rates

Эта функция предназначена для симуляции будущих курсов валют на основе заданных параметров дрейфа и волатильности для каждой валюты. Она использует модель геометрического броуновского движения (GBM), которая часто применяется в финансовом моделировании для описания временных рядов цен или индексов.

Математическое описание GBM:

где:

• ( St ) — цена актива в момент времени ( t ),

• ( S0 ) — начальная цена актива,

• ( μ ) — ожидаемый дрейф (среднее значение логарифмической доходности),

• ( σ ) — стандартное отклонение логарифмической доходности (волатильность),

• ( Wt ) — винеровский процесс (или стандартное броуновское движение).

В контексте симуляции валютных курсов:

• Дневные возвраты рассчитываются как

где ( Z ) — значения из стандартного нормального распределения.

• Эти возвраты затем умножаются на последнее известное значение курса валюты для получения симулированных курсов на каждый из дней.

def simulate_exchange_rates(historical_rates, days, simulations, drifts, volatilities):
    dt = 1 / days
    simulated_rates = {}
    for currency, rates in historical_rates.items():
        drift = drifts[currency]
        volatility = volatilities[currency]
        daily_returns = np.exp((drift - 0.5 * volatility**2) * dt +
                               volatility * np.random.normal(0, np.sqrt(dt), (days, simulations)))
        simulation = rates.iloc[-1] * np.cumprod(daily_returns, axis=0)
        simulated_rates[currency] = simulation
    return simulated_rates

2. Функция portfolio_value

Функция portfolio_value рассчитывает стоимость портфеля в рублях, учитывая симулированные курсы валют и количество каждой валюты в портфеле. Стоимость портфеля определяется как:

где:

• ( xi ) — количество валюты ( i ) в портфеле,

• ( Si(T) ) — симулированный курс валюты ( i ) на конец периода ( T ),

• ( n ) — количество различных валют в портфеле.

def portfolio_value(simulated_rates, portfolio):
    simulations = next(iter(simulated_rates.values())).shape[1]
    values = np.full(simulations, portfolio.get('RUB', 0), dtype=float)
    for currency, amount in portfolio.items():
        if currency != 'RUB':
            values += amount * simulated_rates[currency][-1, :]
    return values

3. Функции calculate_var и calculate_cvar

• Функция calculate_var оценивает Value at Risk (VaR) портфеля, который представляет собой потенциальную максимальную потерю в стоимости портфеля на заданном уровне доверия (например, 95%). VaR рассчитывается как:

где V (α) — квантиль распределения стоимости портфеля на уровне α.

def calculate_var(portfolio_values, confidence_level=0.95):
    sorted_values = np.sort(portfolio_values)
    index = int((1 - confidence_level) * len(sorted_values))
    return sorted_values[index]

• Функция calculate_cvar рассчитывает Conditional Value at Risk (CVaR), который представляет среднюю потерю, превышающую VaR:

где ( Vu) — значение портфеля в точке квантиля (u).

def calculate_cvar(portfolio_values, confidence_level=0.95):
    var = calculate_var(portfolio_values, confidence_level)
    cvar = portfolio_values[portfolio_values <= var].mean()
    return cvar

4. Функция calculate_confidence_interval

Функция calculate_confidence_interval предназначена для расчета доверительного интервала значений на основе симулированных данных. Доверительный интервал дает представление о том, в каком диапазоне могут колебаться значения с заданной вероятностью.

Математическое описание:

Для расчета доверительного интервала используется метод перцентилей. Он основан на следующих шагах:

• Сначала симулированные данные сортируются по возрастанию.

• Затем выбираются значения, соответствующие перцентилям, рассчитанным на основе заданного уровня доверия ( α ).

Этот метод позволяет оценить, например, верхнюю и нижнюю границу ожидаемых значений курса валюты с вероятностью ( α ).

def calculate_confidence_interval(simulated_data, confidence_level=0.95):
    lower_percentile = (1 - confidence_level) / 2 * 100
    upper_percentile = (1 - (1 - confidence_level) / 2) * 100
    lower_bound = np.percentile(simulated_data, lower_percentile)
    upper_bound = np.percentile(simulated_data, upper_percentile)
    return lower_bound, upper_bound

5. Функция calculate_drift_volatility

Функция calculate_drift_volatility предназначена для расчета дрейфа и волатильности на основе исторических данных о курсах валют. Эти параметры критично важны для моделирования будущих цен по модели геометрического броуновского движения.

Процесс расчета:

• Из исторических данных сначала рассчитываются логарифмические доходности:

• Дрейф ( μ ) определяется как среднее значение этих доходностей.

• Волатильность (σ) — это стандартное отклонение доходностей.

Обычно для расчета этих параметров используется скользящее окно (например, 252 дня, что соответствует количеству торговых дней в году), что позволяет учитывать последние изменения на рынке и делает модель более адаптивной к текущим условиям.

def calculate_drift_volatility(rates, lookback_period=252):
    log_returns = np.log(rates / rates.shift(1)).dropna()
    rolling_mean = log_returns.rolling(window=lookback_period).mean()
    rolling_std = log_returns.rolling(window=lookback_period).std()
    drift = rolling_mean.iloc[-1]
    volatility = rolling_std.iloc[-1]
    return drift, volatility

6. Функция fit_garch_model

Функция fit_garch_model применяется для моделирования и оценки волатильности с использованием ГАРЧ модели. ГАРЧ модель особенно полезна для финансовых временных рядов, где волатильность не является постоянной, а изменяется со временем.

Процесс подгонки модели:

• Входные данные для модели — это логарифмические доходности.

• Модель ГАРЧ параметризуется значениями ( p ) и ( q ), которые представляют собой порядки модели для условной дисперсии и скользящего среднего соответственно.

• Результат подгонки модели включает оценки долгосрочной волатильности и условного математического ожидания, что критично для точного прогнозирования будущих колебаний курсов валют.

ГАРЧ модель позволяет более точно оценить риск и управлять им, поскольку принимает во внимание изменчивость волатильности, что является стандартным явлением для финансовых рынков.

Инициализация и выполнение модели Монте-Карло для валютных курсов

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

Расчет дрейфа и волатильности

1. Извлечение логарифмических доходностей: Используя исторические данные курсов USD и EUR, рассчитываются ежедневные логарифмические доходности. Это первый шаг в процессе определения дрейфа и волатильности, которые понадобятся для симуляций.

   

2. Расчет скользящих средних и стандартных отклонений: На основе логарифмических доходностей с помощью скользящего окна в 252 дня (примерно количество торговых дней в году) рассчитываются скользящие средние и стандартные отклонения. Эти значения представляют собой дрейф и волатильность каждой валюты.

Подгонка ГАРЧ модели

3. Подгонка ГАРЧ модели: Для каждой валюты подгоняется ГАРЧ модель к логарифмическим доходностям. Модель ГАРЧ помогает оценить долгосрочную волатильность и условное среднее, что важно для точности симуляций.

Симуляция валютных курсов

4. Инициализация симуляций: С использованием полученных параметров дрейфа и волатильности запускаются симуляции курсов валют для заданного количества дней (252 дня в примере) и количества симуляций (1,000,000 в примере). Каждая симуляция представляет возможное будущее состояние курса валюты.

   • Симуляции проводятся по модели геометрического броуновского движения, описанного выше.

Ввод данных пользователем

5. Получение данных портфеля от пользователя: Запрашивается у пользователя ввод данных о количестве рублей, долларов и евро в его портфеле. Эти данные необходимы для дальнейшего расчета стоимости портфеля.

historical_rates = {'USD': usd_rates, 'EUR': eur_rates}
days = 252
simulations = 1000000
# Расчет дрейфа и волатильности для Моделирования
# через calculate_drift_volatility
drifts = {}
volatilities = {}
for currency, rates in historical_rates.items():
    drifts[currency], volatilities[currency] = calculate_drift_volatility(rates)
# Расчет дрейфа и волатильности для Моделирования via garch
usd_log_returns = np.log(usd_rates / usd_rates.shift(1)).dropna()
eur_log_returns = np.log(eur_rates / eur_rates.shift(1)).dropna()
usd_drift_garch, usd_volatility_garch = fit_garch_model(usd_log_returns)
eur_drift_garch, eur_volatility_garch = fit_garch_model(eur_log_returns)
# Обновление словарей дрейфов и волатильности для использования в симуляции Монте-Карло
drifts['USD'] = usd_drift_garch
drifts['EUR'] = eur_drift_garch
volatilities['USD'] = usd_volatility_garch
volatilities['EUR'] = eur_volatility_garch
# Моделирование курсов валют
simulated_rates = simulate_exchange_rates(historical_rates, days, simulations, drifts, volatilities)
# Ввод данных пользователем
rub_amount = float(input("Введите количество рублей: "))
usd_amount = float(input("Введите количество долларов: "))
eur_amount = float(input("Введите количество евро: "))
# Получение данных пользователя
portfolio = {'RUB': rub_amount, 'USD': usd_amount, 'EUR': eur_amount}
# Расчет стоимости портфеля
portfolio_values = portfolio_value(simulated_rates, portfolio)

Расчет стоимости портфеля и рисков

6. Расчет стоимости портфеля и рисков: Используя симулированные курсы валют и данные о количестве валют в портфеле пользователя, рассчитывается стоимость портфеля и ключевые показатели риска (VaR и CVaR).

cvar = calculate_cvar(portfolio_values)
print(f"Максимальный риск портфеля (95% довер): {cvar}")

Анализ и визуализация результатов

7. Статистический анализ и визуализация: Проводится сравнение исторических и симулированных данных с помощью статистических тестов, таких как Колмогорова-Смирнова тест и t-тест для независимых выборок. Результаты визуализируются, чтобы наглядно показать реальные и симулированные данные по курсам валют.

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

data_recent = yf.download("USDRUB=X EURRUB=X", start="2023-04-12", end="2024-04-13")['Close'].dropna()
data_recent_usd = data_recent['USDRUB=X'].dropna()
data_recent_eur = data_recent['EURRUB=X'].dropna()

real_data_last_year = data_recent_usd[-days:]
simulated_data_first_path = simulated_rates['USD'][:, 0]
ks_stat, p_value_ks = ks_2samp(real_data_last_year, simulated_data_first_path)
t_stat, p_value_t = ttest_ind(real_data_last_year, simulated_data_first_path, equal_var=False)
print(f"KS Statistic: {ks_stat}, P-value (KS-test): {p_value_ks}")
print(f"T-statistic: {t_stat}, P-value (T-test): {p_value_t}")

usd_confidence_interval = calculate_confidence_interval(simulated_rates['USD'][-1, :])
eur_confidence_interval = calculate_confidence_interval(simulated_rates['EUR'][-1, :])
print(f"Доверительный интервал 95% для курса доллара: {usd_confidence_interval}")
print(f"Доверительный интервал 95% для курса евро: {eur_confidence_interval}")

Визуализация

# Визуализация исторических и симулированных данных
plt.figure(figsize=(14, 7))
plt.plot(usd_rates.index, usd_rates,
         label='Реальные данные(2013-01-01 - 2023-04-12)')
plt.plot(data_recent_usd.index, data_recent_usd,
         label='Реальные данные (2023-04-13 - 2024-04-13)', color='green', alpha=0.7)
plt.plot(pd.date_range(start=usd_rates.index[-1], periods=days, freq='B'),
         simulated_rates['USD'][:, 0], label='Смоделированные данные', color='orange', alpha=0.7)
plt.legend()
plt.title('Реальные vs Смоделированные USD/RUB курсы')
plt.xlabel('Дата')
plt.ylabel('Курс')
plt.savefig('RUBUSD.png')
plt.show()

# Визуализация исторических и симулированных данных
plt.figure(figsize=(14, 7))
plt.plot(eur_rates.index, eur_rates,
         label='Реальные данные(2013-01-01 - 2023-04-12)')
plt.plot(data_recent_eur.index, data_recent_eur,
         label='Реальные данные (2023-04-13 - 2023-04-13)', color='green', alpha=0.7)
plt.plot(pd.date_range(start=eur_rates.index[-1], periods=days, freq='B'),
         simulated_rates['EUR'][:, 0], label='Смоделированные данные', color='orange', alpha=0.7)
plt.legend()
plt.title('Реальные vs Смоделированные EUR/RUB курсы')
plt.xlabel('Дата')
plt.ylabel('Курс')
plt.savefig('RUBEUR.png')
plt.show()

plt.figure(figsize=(10, 6))
for i in range(15):
    plt.plot(simulated_rates['USD'][:, i], linewidth=1, alpha=0.8)
plt.title('Моделирование траекторий обменного курса доллара к рублю')
plt.xlabel('Дни')
plt.ylabel('Курс')
plt.show()

plt.figure(figsize=(10, 6))
for i in range(15):
    plt.plot(simulated_rates['EUR'][:, i], linewidth=1, alpha=0.8)
plt.title('Моделирование траекторий обменного курса евро к рублю')
plt.xlabel('Дни')
plt.ylabel('Курс')
plt.show()

Бонус

Смоделируем поведение доллара на год вперед (04.2024 — 04.2025]

Прогноз на год вперед

historical_rates_pred = {'USD': data_recent_usd, 'EUR': data_recent_eur}
days_pred= 252
simulations_pred = 1000000
# Расчет дрейфа и волатильности для Моделирования
drifts_pred = {}
volatilities_pred = {}
for currency_pred, rates_pred in historical_rates_pred.items():
    drifts_pred[currency_pred], volatilities_pred[currency_pred] = calculate_drift_volatility(rates_pred)
usd_log_returns_pred = np.log(usd_rates / usd_rates.shift(1)).dropna()
eur_log_returns_pred = np.log(eur_rates / eur_rates.shift(1)).dropna()
usd_drift_garch_pred, usd_volatility_garch_pred = fit_garch_model(usd_log_returns_pred)
eur_drift_garch_pred, eur_volatility_garch_pred = fit_garch_model(eur_log_returns_pred)
# Обновление словарей дрейфов и волатильности для использования в симуляции Монте-Карло
drifts_pred['USD'] = usd_drift_garch_pred
drifts_pred['EUR'] = eur_drift_garch_pred
volatilities_pred['USD'] = usd_volatility_garch_pred
volatilities_pred['EUR'] = eur_volatility_garch_pred
# Моделирование курсов валют
simulated_rates_pred = simulate_exchange_rates(historical_rates_pred, days_pred, simulations_pred, drifts_pred, volatilities_pred)
# Ввод данных пользователем
rub_amount_pred = float(input("Введите количество рублей: "))
usd_amount_pred = float(input("Введите количество долларов: "))
eur_amount_pred = float(input("Введите количество евро: "))
# Получение данных пользователя
portfolio_pred = {'RUB': rub_amount_pred, 'USD': usd_amount_pred, 'EUR': eur_amount_pred}
# Расчет стоимости портфеля
portfolio_values_pred = portfolio_value(simulated_rates_pred, portfolio_pred)

Тут я создал портфель с 1000 USD

cvar_pred = calculate_cvar(portfolio_values_pred)
print(f"Максимальный риск портфеля (95% довер): {cvar_pred}")

Максимальный риск портфеля (95% довер): 71827.22023513853

usd_confidence_interval_pred = calculate_confidence_interval(simulated_rates_pred['USD'][-1, :])
eur_confidence_interval_pred = calculate_confidence_interval(simulated_rates_pred['EUR'][-1, :])
print(f"Доверительный интервал 95% для курса доллара: {usd_confidence_interval_pred }")
print(f"Доверительный интервал 95% для курса евро: {eur_confidence_interval_pred }")

Доверительный интервал 95% для курса доллара: (72.63404780533205, 116.80234915827717)

Доверительный интервал 95% для курса евро: (94.25965585147713, 104.5288904591821)

plt.figure(figsize=(14, 7))
plt.plot(pd.date_range(start=data_recent_usd.index[-1], periods=days, freq='B'),
         simulated_rates_pred['USD'][:, 0], label='Смоделированные данные', color='blue', alpha=0.7)
plt.legend()
plt.title('Смоделированные USD/RUB курс на год')
plt.xlabel('Дата')
plt.ylabel('Курс')
plt.grid()
plt.savefig('RUBUSD_pred.png')
plt.show()

Этот прогноз представляет собой обобщенный анализ на основе модели Монте-Карло и не учитывает все возможные будущие условия и изменения. Он демонстрирует потенциал метода для создания информированных и обоснованных прогнозов, подкрепленных статистическим анализом и симуляцией данных.

Заключение

В данной статье мы провели обширный анализ временных рядов курсов валют с использованием метода Монте-Карло, обогащенного моделями ГАРЧ для уточнения параметров дрейфа и волатильности. Доверять полученным значениям курсов не стоит — определенно, об этом говорит разность графиков, значения к-с и t тестов, но всё же для понимания принципов вышло очень хорошо.

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