LabHub
배우기 러닝패스 코스

필드 번호를 바꿨더니 옛 클라이언트가 조용히 틀린 값을 읽었다 · 호출 네 가지와 죽는 방법 열여섯 가지 · 퀴즈

퀴즈: 호출 네 가지와 죽는 방법

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. `rpc Chat (stream Msg) returns (stream Msg);` 에서 gRPC 가 보장하는 것은?

    1. 클라이언트가 보낸 순서대로 서버가 응답을 하나씩 돌려준다
    2. 각 스트림 안의 메시지 순서는 지켜지지만 두 스트림 사이의 순서는 없다
    3. 서버는 클라이언트 메시지를 전부 받은 뒤에만 쓰기 시작할 수 있다
    4. 양쪽 스트림의 메시지 개수가 같아야 호출이 OK 로 끝난다
  2. 클라이언트가 `INVALID_ARGUMENT` 를 받았다. 확실히 말할 수 있는 것은?

    1. 네트워크가 끊겨 gRPC 라이브러리가 만든 코드다
    2. 서버가 내려가는 중이라 라이브러리가 대신 돌려준 것이다
    3. 잠시 뒤 같은 요청을 다시 보내면 성공할 가능성이 높다
    4. 라이브러리는 이 코드를 만들지 않으므로 서버 애플리케이션 코드가 돌려준 것이다
  3. 읽고-고치고-쓰기 순서에서 테스트-앤드-셋이 실패해 클라이언트가 처음부터 다시 해야 할 때 문서가 권하는 코드는?

    1. ABORTED — 상위 수준에서 재시도하라는 뜻
    2. UNAVAILABLE — 이 호출만 다시 하면 된다는 뜻
    3. FAILED_PRECONDITION — 상태를 고치기 전엔 재시도하지 말라는 뜻
    4. RESOURCE_EXHAUSTED — 동시성 한도에 걸렸다는 뜻
  4. 사용자 서버가 클라이언트에게 받은 데드라인을 과금 서버로 전파할 때 gRPC 가 시각 대신 타임아웃으로 바꿔 넘기는 이유는?

    1. HTTP/2 헤더에는 정수만 실을 수 있어서
    2. 두 서버의 시계가 어긋나도 남은 시간이 정확하도록
    3. 과금 서버가 데드라인을 다시 계산하지 않도록 하는 성능 최적화
    4. 타임아웃이 짧을수록 재시도 토큰을 아낄 수 있어서
  5. 채널에 재시도 정책을 전혀 적지 않았을 때 UNAVAILABLE 로 실패한 호출에 일어나는 일은?

    1. 기본 정책대로 최대 4 번까지 지수 백오프로 재시도한다
    2. 서버가 처리했을 가능성이 있으면 재시도하지 않고, 투명 재시도만 제한적으로 한다
    3. 재시도가 기본으로 꺼져 있어 어떤 경우에도 다시 보내지 않는다
    4. UNAVAILABLE 은 항상 안전하므로 성공할 때까지 무한히 재시도한다
  6. gRPC 메타데이터 키의 규칙으로 맞는 것은?

    1. 대소문자를 구별하며 `grpc-` 로 시작해야 gRPC 가 전달한다
    2. UTF-8 어떤 문자든 되고 값은 항상 base64 로 인코딩된다
    3. ASCII 이고 대소문자를 구별하지 않으며 `grpc-` 로 시작할 수 없고 바이너리 값 키는 `-bin` 으로 끝난다
    4. 숫자로만 이루어져야 하며 HTTP/2 헤더와 별도 채널로 전송된다