クイズ: 向こうの問題か、こちらの問題か

우리 쪽은 연결 타임아웃으로 실패하는데 상대는 자기 로그에 아무 기록이 없다고 한다. 가장 정확한 해석은?

• 상대가 로그 수준을 낮게 잡아 실패한 요청이 기록되지 않았을 가능성이 크다
• 손잡기가 끝나지 않았으므로 요청이 상대 애플리케이션까지 가지 않았고, 경로나 방화벽을 먼저 본다
• 상대 서버가 요청을 받고 즉시 버렸으므로 상대의 수신 큐 설정을 먼저 본다
• 우리 쪽 클라이언트가 요청을 만들지 못한 것이므로 우리 코드를 먼저 본다

결제 요청이 읽기 타임아웃으로 실패했다. 같은 요청을 그대로 다시 보내도 되는가?

• 보내도 된다. 타임아웃이 났다는 것은 요청이 처리되지 않았다는 뜻이다
• 보내도 된다. HTTP 는 실패한 요청을 서버가 자동으로 되돌리도록 규정한다
• 보내면 안 된다. 손을 잡은 뒤의 실패라 이미 처리됐을 수 있고, 멱등 보호 없이는 두 번 청구가 된다
• 보내면 안 된다. 읽기 타임아웃 뒤에는 연결이 오염되어 같은 주소로는 다시 붙을 수 없다

requests 에 timeout=3 처럼 한 값만 준 것과 timeout=(1, 3) 처럼 둘을 준 것의 차이는?

• 한 값은 전체 요청의 상한이고 튜플은 연결에만 적용되므로 본문 수신에는 상한이 없다
• 한 값은 연결과 읽기에 각각 그 값이 쓰이고, 튜플은 둘을 따로 주어 실패 얼굴이 갈려서 온다
• 차이는 없다. requests 는 두 경우 모두 같은 예외를 같은 조건에서 던진다
• 한 값은 재시도까지 포함한 총 시간이고, 튜플은 시도 하나의 시간이다

인터넷이 없는 실습 환경에서 연결 타임아웃을 재현하려 한다. 가장 정직한 방법은?

• 존재하지 않는 사설 IP 주소로 요청을 보내 커널이 포기할 때까지 기다린다
• 서버 코드에 sleep 을 넣어 응답을 늦춘 뒤 짧은 타임아웃으로 요청한다
• 대기열을 채운 뒤 accept 하지 않는 소켓을 세워 손잡기 자체가 끝나지 않게 한다
• 방화벽 규칙으로 해당 포트의 패킷을 버린다

상대가 Content-Length 를 400 이라고 적고 40바이트만 보낸 뒤 연결을 끊었다. 이 사건을 어떻게 기록해야 하는가?

• JSON 파싱 오류로 기록한다. 우리 파서가 처리하지 못한 것이 사실이기 때문이다
• 본문이 약속한 길이보다 짧게 끊긴 부분 응답으로 기록한다. 상대나 중간 장비가 끊은 것이다
• 읽기 타임아웃으로 기록한다. 나머지 360바이트를 기다리다 실패했기 때문이다
• 성공으로 기록한다. 상태 코드가 200 이고 헤더까지 정상적으로 받았기 때문이다

느린 상대에게 타임아웃 없이 요청하고, 실패하면 세 번까지 재시도하도록 만들었다. 가장 큰 위험은?

• 한 번의 시도가 끝나지 않으므로 작업 스레드가 돌아오지 않고, 상대의 느림이 우리 장애가 된다
• 재시도 사이에 지연을 두지 않아 상대에게 순간적으로 세 배의 부하가 몰린다
• 세 번의 시도가 각각 다른 서버로 가면서 세션이 끊겨 인증이 풀린다
• 재시도 횟수가 로그에 남지 않아 사후에 원인을 재구성할 수 없다