クイズ: TCPとUDP

curl 이 'Connection refused' 로 4밀리초 만에 실패했다. 이 사실로부터 확실히 알 수 있는 것은?

• 패킷이 목적지 호스트까지 도달했고 그 호스트가 RST 를 돌려줬다
• 중간 방화벽이 패킷을 차단해 응답이 돌아오지 않았다
• 이름을 주소로 바꾸는 DNS 해석 단계에서 실패했다
• 목적지로 가는 라우팅 경로가 없어 바로 실패했다

리눅스에서 연결 시도가 정확히 127초쯤 뒤에 실패했다. 이것이 뜻하는 바는?

• 커널이 SYN 재전송을 모두 소진하고 포기한 것이며, 그동안 아무 응답도 없었다
• 애플리케이션이 설정한 타임아웃이 127초였다
• 서버가 127초 동안 처리하다 실패했다
• DNS 조회에 127초가 걸렸다

TIME-WAIT 상태가 존재하는 이유로 옳은 것은?

• 연결 종료 절차를 더 빠르게 끝내기 위해 잠시 대기하는 것
• 늦게 도착한 세그먼트가 다음 연결을 오염시키지 않게 하고, 마지막 ACK 유실에 대비하기 위해
• 커널 소켓 구조체의 메모리 누수를 방지하기 위해
• 방화벽이 연결 상태를 정리할 시간을 주기 위해

흐름 제어(rwnd)와 혼잡 제어(cwnd)의 차이를 옳게 설명한 것은?

• 흐름 제어는 TCP 에만, 혼잡 제어는 UDP 에만 있다
• 흐름 제어는 수신자의 처리 능력을, 혼잡 제어는 네트워크의 여유를 반영한다
• 둘은 같은 값을 다르게 부르는 것이다
• 혼잡 제어는 수신자가, 흐름 제어는 송신자가 계산한다

ss -ltn 출력에서 리스닝 소켓의 Recv-Q 가 Send-Q 를 넘고 있다. 무엇을 뜻하는가?

• 수신 버퍼가 가득 차 데이터가 유실되고 있다
• 네트워크 대역폭이 부족해 데이터가 밀리고 있다
• accept 큐가 포화되어 새 연결의 SYN 이 버려지고 있으며, 원인은 애플리케이션 처리량이다
• TIME-WAIT 소켓이 너무 많아 큐를 차지하고 있다

실시간 음성 통화에 TCP 가 부적합한 주된 이유는?

• TCP 헤더가 커서 음성 패킷마다 대역폭을 낭비하기 때문
• TCP 는 여러 참가자에게 한 번에 보내는 멀티캐스트를 지원하지 않기 때문
• 손실된 세그먼트를 재전송하는 동안 이후 데이터를 응용에 넘기지 않아 지연이 누적되기 때문
• TCP 자체는 암호화를 지원하지 않아 음성이 그대로 노출되기 때문

DNS 서버로 가는 TCP 53 포트를 막았을 때 나타나는 전형적인 증상은?

• 도메인과 무관하게 모든 DNS 조회가 곧바로 실패한다
• 평소에는 정상이다가 응답이 512바이트를 넘는 특정 도메인만 해석되지 않는다
• 모든 조회가 UDP 재시도를 거쳐 응답 시간이 두 배가 된다
• 정방향은 되고 IP 를 이름으로 바꾸는 역방향 조회만 실패한다