연결 하나가 느려지자 나머지가 전부 멈췄다 · 쓰기 준비인데 접속 실패: 비차단 연결 수립 · 퀴즈
퀴즈: 쓰기 준비인데 접속 실패: 비차단 연결 수립
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
비차단 TCP 연결에서 WRITE 이벤트가 왔다. 성공 판정에 필요한 것은?
- connect_ex를 매번 다시 호출해 시도 횟수를 늘린다
- 쓰기 버퍼 크기가 0보다 크면 성공으로 표시한다
- 연결 중 상태에서 SO_ERROR를 읽어 실제 결과를 보관한다
- 아직 읽은 바이트가 없으면 무조건 실패로 표시한다
오류 기록기가 SO_ERROR를 읽은 뒤 판정기가 다시 읽었다. 무엇이 위험한가?
- 첫 조회가 서버의 listen을 자동으로 중지시킨다
- 두 번째 조회가 연결을 자동으로 다시 시도한다
- 첫 조회의 오류가 모든 프로세스에 영구 복사된다
- 첫 조회가 오류를 지워 두 번째 값이 0일 수 있다
Linux AF_INET 진단기에서 EAGAIN을 AF_UNIX와 동일하게 pending으로 처리해도 되는가?
- 주소 계열별 의미가 다르므로 이 TCP 계약에서는 실패로 분류한다
- 소켓의 모든 주소 계열에서 EAGAIN은 성공을 의미하므로 괜찮다
- 숫자가 같으면 주소 계열과 무관하게 같은 상태 전이를 쓴다
- EAGAIN을 받으면 SO_ERROR를 반복 조회해 반드시 0을 기다린다
소켓을 비차단으로 설정한 뒤 host='localhost'를 받으면 무엇까지 증명되는가?
- 이름 해석과 IPv6 후보 경쟁까지 모두 비차단으로 보장된다
- 소켓 설정만으로 이름 해석의 비차단 동작까지 보장되지는 않는다
- 호스트 이름은 커널이 항상 캐시하므로 별도 단계가 없다
- 연결 전에 발생하는 모든 오류가 SO_ERROR에만 기록된다
Dial이 대기열에 있는 동안 절대 마감에 도달했다. 어떻게 처리하는가?
- 아직 connect하지 않았으므로 마감을 현재 시각에서 다시 시작한다
- 빈 연결은 비용이 없으므로 기한 없이 계속 대기열에 남긴다
- 네트워크 시도를 시작하지 않고 timed_out으로 끝낸다
- 순서 보존을 위해 일단 연결한 뒤 성공이면 마감을 지운다
진단 결과가 connected였다. 이 결과가 직접 뒷받침하는 범위는?
- 원격 API가 요청을 처리하고 DB에 결과를 저장했다
- TLS 인증서의 신뢰성과 호스트 이름 검증이 끝났다
- 이후 모든 송수신이 오류 없이 계속될 것이 보장됐다
- 관찰한 TCP 연결 수립이 성공했으며 업무 정상 여부는 별도다