QGrpcHttp2Channel Class

상세 설명

QGrpcHttp2Channel 클래스는 ` QAbstractGrpcChannel` 인터페이스를 구현하여 gRPC™HTTP/2 프레임 구조를 통해 통신할 수 있도록 합니다.

HTTP/2는 이전 버전인 HTTP/1.1에 비해 여러 가지 장점을 제공하므로, QGrpcHttp2Channel은 다중화 된 TCP 연결을 사용하여 보안이나 안정성을 저해하지 않으면서 효율적인 통신이 필요한 고성능 실시간 애플리케이션에 매우 적합합니다.

이 채널은 필요한 사용자 지정이 포함된 ` QGrpcChannelOptions `를 사용하여 생성함으로써, SSL 지원, 사용자 지정 ` serializationFormat` 또는 기타 옵션으로 사용자 지정할 수 있습니다.

전송 방식

QGrpcHttp2Channel 구현체는 제공된 hostUri, scheme 및 옵션에 따라 서로 다른 전송 방식을 우선적으로 선택합니다. 다음 기준이 적용됩니다:

Content-Type

HTTP/2를 통한 gRPC 의 콘텐츠 유형은 메시지 직렬화 형식을 결정합니다. 반드시 application/grpc 으로 시작해야 하며 접미사를 포함할 수 있습니다. 형식은 다음 스키마를 따릅니다:

"content-type": "application/grpc" [("+proto" / "+json" / {custom})]

예를 들어:

• application/grpc+proto Protobuf 인코딩을 지정합니다.
• application/grpc+json JSON 인코딩을 지정합니다.

직렬화 형식은 메타데이터 내의 ` content-type `을 지정하거나 ` serializationFormat `을 직접 설정하여 구성할 수 있습니다. 기본적으로 ` application/grpc ` 콘텐츠 유형이 사용됩니다.

content-type 메타데이터를 사용하여 QGrpcHttp2Channel을 JSON 직렬화 형식으로 구성하려면:

auto jsonChannel = std::make_shared<QGrpcHttp2Channel>(
    QUrl("http://localhost:50051"_L1),
    QGrpcChannelOptions().setMetadata({
        { "content-type"_ba, "application/grpc+json"_ba },
    })
);

사용자 정의 직렬화기와 content-type 을 사용하는 경우, 직렬화 형식을 직접 설정할 수 있습니다:

class DummySerializer : public QAbstractProtobufSerializer
{
    ...
};
QGrpcSerializationFormat dummyFormat("dummy", std::make_shared<DummySerializer>());

auto dummyChannel = std::make_shared<QGrpcHttp2Channel>(
    QUrl("http://localhost:50051"_L1),
    QGrpcChannelOptions().setSerializationFormat(dummyFormat)
);

이 경우 DummySerializer 을 사용하여 dummy 접미사가 붙은 메시지를 인코딩 및 디코딩합니다. HTTP/2 전송 시에는 이로 인해 application/grpc+dummy 콘텐츠 유형이 적용됩니다.

예약된 메타데이터 키

메타데이터는 HTTP/2 헤더로 전송됩니다. 키는 대소문자를 구분하지 않는 ASCII 문자열이며, 값은 ASCII 문자열이나 바이너리 데이터일 수 있습니다. 다음 키들은 HTTP/2 또는 gRPC 프로토콜에 의해 예약되어 있으며, 요청이 구성될 때 사용자 메타데이터에서 제외됩니다:

• HTTP/2 의사 헤더( : 로 시작하는 모든 키).
• grpc- 또는 qtgrpc- 접두사가 붙은 모든 키.
• te, content-type, user-agent.

사용자가 제공한 content-type 는 시리얼라이저 자동 감지를 위해 채널 구축 시 여전히 참조됩니다( Content-Type 참조). 그러나 이는 Custom-Metadata 항목으로 전달되지는 않습니다.

HTTP/2 헤더에 대한 자세한 내용은 RFC 7540, 섹션 8.1.2를 참조하십시오.

수신 윈도우

HTTP/2 흐름 제어는 수신자가 데이터를 확인하기 전에 발신자가 전송할 수 있는 데이터의 양을 제한합니다. 채널은 서버에 이러한 두 가지 제한, 즉 수신 윈도우를 알립니다:

• 스트림 윈도우는 단일 RPC의 미확인 데이터 양을 제한합니다.
• 연결 윈도우는 하나의 연결을 공유하는 모든 RPC의 미확인 데이터를 합산하여 상한을 설정합니다.

윈도우는 전송 중인 데이터의 양을 제한할 뿐, 전송 크기를 제한하지는 않습니다. 확인 응답에는 네트워크 왕복(RTT) 한 번이 소요되므로, 이는 처리량도 제한합니다:

maximum throughput = window / round-trip time

두 윈도우 모두 환경 변수를 통해 바이트 단위로 구성됩니다:

• QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE 스트림 윈도우의 경우; (기본값: 4 MiB)
• QT_GRPC_HTTP2_CONNECTION_RECEIVE_WINDOW_SIZE 연결 윈도우의 경우; (기본값은 스트림 윈도우의 4배, 16 MiB)

QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE 만 설정하면 연결 윈도우가 자동으로 스트림 윈도우의 4배로 조정됩니다. 다른 비율을 사용하려면 QT_GRPC_HTTP2_CONNECTION_RECEIVE_WINDOW_SIZE 를 명시적으로 설정하십시오.

기본값은 로컬 네트워크와 대부분의 인터넷 경로를 포화시킵니다. 왕복 시간이 긴 고속 링크에서는 이 값이 부족합니다. 예를 들어, 애플리케이션이 멀리 떨어진 서버로부터 대용량 메시지를 수신하는 경우:

link: 1 Gbit/s (125 MB/s), 100 ms round-trip time

서버는 스트림 윈도우 하나 분량의 데이터를 전송한 후, 확인 응답을 받기 위해 한 번의 왕복 시간을 기다립니다. 기본 윈도우 설정에서는 100ms마다 최대 4 MiB만 전송됩니다:

4 MiB / 0.1 s = 42 MB/s, 34% of the 125 MB/s the link carries

링크를 포화시키려면, 윈도우가 한 번의 왕복 시간 동안 링크가 전달하는 모든 데이터, 즉 링크의 대역폭-지연 곱 (BDP)을 수용할 수 있어야 합니다:

BDP = 125 MB/s x 0.1 s = 12.5 MB

QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE=12500000
12.5 MB / 0.1 s = 125 MB/s, the link is saturated

동시 실행되는 RPC들은 단일 연결 수신 윈도우를 공유합니다. 모든 스트림이 지속적으로 읽히는 한, 전송 중인 데이터의 총량은 BDP의 한도 내에서 유지됩니다. 그러나 스트림이 읽히지 않으면, 해당 스트림의 버퍼된 데이터가 공유 연결 윈도우의 일부를 차지하여 다른 스트림을 차단할 수 있습니다. 일반적인 경험칙으로는, 연결 윈도우 크기를 동시에 활성화된 모든 스트림 윈도우의 합에 맞춰 설정하는 것이 좋습니다. 위 링크에서 8개의 병렬 전송이 이루어지는 경우:

QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE=12500000       (12.5 MB = BDP)
QT_GRPC_HTTP2_CONNECTION_RECEIVE_WINDOW_SIZE=100000000  (8 x 12.5 MB)

각 RPC는 유일하게 활성화된 전송일 때 125 MB/s의 전체 대역폭을 사용할 수 있습니다. 8개의 RPC가 동시에 실행될 경우, 각 RPC는 대략 15 MB/s씩 링크를 공유하게 됩니다. 최악의 경우, 애플리케이션이 모든 스트림에서 읽기를 중단하면 채널에 최대 100 MB의 데이터가 버퍼링될 수 있습니다.

또는 스트림 윈도우의 크기를 BDP와 동일한 연결 윈도우 내에 모두 들어갈 수 있도록 설정할 수도 있습니다. 이렇게 하면 버퍼링되는 데이터의 최대량을 제한할 수 있지만, 각 RPC가 단독으로 전송할 때조차 할당된 몫으로만 전송이 제한됩니다:

QT_GRPC_HTTP2_STREAM_RECEIVE_WINDOW_SIZE=1562500        (12.5 MB / 8)
QT_GRPC_HTTP2_CONNECTION_RECEIVE_WINDOW_SIZE=12500000   (= BDP)

각 RPC는 단독으로 전송하든 다른 7개의 RPC와 함께 전송하든 상관없이 대략 15 MB/s로 제한됩니다. 이 방식의 장점은 채널에 버퍼링되는 미읽은 데이터가 약 12.5 MB를 초과하지 않는다는 점입니다.

전송 지연 시간을 최소화하는 것이 메모리 사용량보다 더 중요하다면 전체 크기의 스트림 윈도우를 사용하십시오. 메모리 소비를 제한하는 것이 우선순위라면 더 작은 스트림 윈도우를 사용하십시오. 어느 경우든 여러 스트림 윈도우를 수용할 수 있을 만큼 연결 윈도우를 충분히 크게 유지해야 합니다. 그렇지 않으면 단일 미읽은 스트림이 공유 연결 윈도우를 모두 소진하여 다른 모든 RPC를 차단할 수 있습니다.

두 창 모두 최대 2147483647 바이트까지의 값을 허용합니다. 스트림 창의 최소값은 1024 바이트로, 메모리 제약이 있는 수신자가 스트림별 버퍼링을 제한할 수 있게 해줍니다. 연결 창의 최소값은 65535 바이트로, 이는 프로토콜의 초기 창 크기입니다.

환경 변수 대체 설정

일부 채널 설정은 환경 변수를 통해 구성할 수 있습니다. 이러한 설정은 각 채널이 생성될 때 평가됩니다. 환경 변수가 설정되지 않은 경우, 내장된 기본값이 사용됩니다.