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 구성을 유지하고, TLS가 성공한 뒤에만 WebSocket 업그레이드를 시작하십시오.

관련 글