LabHub
배우기 러닝패스 코스

연결 하나가 느려지자 나머지가 전부 멈췄다 · 쓰기 준비인데 접속 실패: 비차단 연결 수립 · 퀴즈

퀴즈: 쓰기 준비인데 접속 실패: 비차단 연결 수립

LabHub 에서 이어서 보기

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

  1. 비차단 TCP 연결에서 WRITE 이벤트가 왔다. 성공 판정에 필요한 것은?

    1. connect_ex를 매번 다시 호출해 시도 횟수를 늘린다
    2. 쓰기 버퍼 크기가 0보다 크면 성공으로 표시한다
    3. 연결 중 상태에서 SO_ERROR를 읽어 실제 결과를 보관한다
    4. 아직 읽은 바이트가 없으면 무조건 실패로 표시한다
  2. 오류 기록기가 SO_ERROR를 읽은 뒤 판정기가 다시 읽었다. 무엇이 위험한가?

    1. 첫 조회가 서버의 listen을 자동으로 중지시킨다
    2. 두 번째 조회가 연결을 자동으로 다시 시도한다
    3. 첫 조회의 오류가 모든 프로세스에 영구 복사된다
    4. 첫 조회가 오류를 지워 두 번째 값이 0일 수 있다
  3. Linux AF_INET 진단기에서 EAGAIN을 AF_UNIX와 동일하게 pending으로 처리해도 되는가?

    1. 주소 계열별 의미가 다르므로 이 TCP 계약에서는 실패로 분류한다
    2. 소켓의 모든 주소 계열에서 EAGAIN은 성공을 의미하므로 괜찮다
    3. 숫자가 같으면 주소 계열과 무관하게 같은 상태 전이를 쓴다
    4. EAGAIN을 받으면 SO_ERROR를 반복 조회해 반드시 0을 기다린다
  4. 소켓을 비차단으로 설정한 뒤 host='localhost'를 받으면 무엇까지 증명되는가?

    1. 이름 해석과 IPv6 후보 경쟁까지 모두 비차단으로 보장된다
    2. 소켓 설정만으로 이름 해석의 비차단 동작까지 보장되지는 않는다
    3. 호스트 이름은 커널이 항상 캐시하므로 별도 단계가 없다
    4. 연결 전에 발생하는 모든 오류가 SO_ERROR에만 기록된다
  5. Dial이 대기열에 있는 동안 절대 마감에 도달했다. 어떻게 처리하는가?

    1. 아직 connect하지 않았으므로 마감을 현재 시각에서 다시 시작한다
    2. 빈 연결은 비용이 없으므로 기한 없이 계속 대기열에 남긴다
    3. 네트워크 시도를 시작하지 않고 timed_out으로 끝낸다
    4. 순서 보존을 위해 일단 연결한 뒤 성공이면 마감을 지운다
  6. 진단 결과가 connected였다. 이 결과가 직접 뒷받침하는 범위는?

    1. 원격 API가 요청을 처리하고 DB에 결과를 저장했다
    2. TLS 인증서의 신뢰성과 호스트 이름 검증이 끝났다
    3. 이후 모든 송수신이 오류 없이 계속될 것이 보장됐다
    4. 관찰한 TCP 연결 수립이 성공했으며 업무 정상 여부는 별도다