Beast'тин CONNECT буферин TLS кол кармоого өткөрүү

CONNECT жообунан кийин калган байттарды Asio'нун буфердүү TLS кол кармоосуна өткөрүп, анан ал колдонгон көлөмдү так ошончо керектеңиз.

Beast проксинин CONNECT жооп баштыгын окугандан кийин жооптун абалын жана динамикалык буферди текшериңиз. Окуу операциясы баштыктын аякташынан ары жаткан байттарды алып, аларды берилген буферде сакташы мүмкүн. TLS'ти бир гана сокетти окуган вариант менен баштасаңыз, ошол сакталган байттар TLS кирүү жолунун сыртында калат.

Кийинки катмары SSL агымы болгон WebSocket агымы үчүн буфердүү кол кармоо вариантын колдонуңуз. Бар yield_context сессиясында buffer бардык операциялар бою тирүү кармап:

http::response_parser<http::empty_body> response;
http::async_read_header(
    beast::get_lowest_layer(ws), buffer, response, yield[ec]);
if (ec) return;

auto status = response.get().result_int();
if (status < 200 || status >= 300) return;

std::size_t used = ws.next_layer().async_handshake(
    ssl::stream_base::client, buffer.data(), yield[ec]);
if (ec) return;
buffer.consume(used);

Эрте кайтуулар сессиянын ийгиликсиздик чыгуулары; ал жерге кадимки ката эсебин жана тазалоону тиркеңиз. Туннелди так ийгиликтүү CONNECT жообу гана түзөт. Баш тартуу баракчасы TLS кирүүсүнө айланбашы керек.

Буфердүү вариант ката коду жана байт саны менен аякталат. Бул сан берилген буферлерден канча байт керектелгенин сүрөттөйт. Аяктагандан кийин так ошол префиксти consume(used) аркылуу алып салыңыз. Операция башталганга чейин буферди тазалабаңыз, кол кармоо күтүп турганда анын сактагычын өзгөртпөңүз жана операция берилген ар бир байтты керектеди деп ойлобоңуз.

CONNECT'тен кийин дароо клиент баштаган кадимки TLS'те буфер бош болушу мүмкүн. Вариант бул учурду да иштетет. Анын максаты агым чегин сактоо; ал каалаган кийинки прокси маалыматтарын жарактуу TLS кылбайт. Кол кармоодон мурун SSL катмарында максаттуу хост атын текшерүүнү жана SNI конфигурациясын кармаңыз, WebSocket жаңыртуусун TLS ийгиликтүү болгондон кийин гана баштаңыз.

Тектеш макалалар