네트워크 — 백엔드 면접 (실제 기출 기반·심화)

한국 백엔드 면접 CS 빅3. "TCP와 UDP 차이", "3-way handshake", "TIME_WAIT는 왜", "HTTP 버전 차이", "HTTPS 동작 원리", "쿠키와 세션" — 단골이고, 면접관은 흐름/혼잡 제어·HOL Blocking·CLOSE_WAIT·TLS·QUIC까지 파고든다(VSFe 패턴).

네트워크는 checksum은 정정 가능?, HTTP/2가 HOL을 완전히 해결? 같은 미묘한 함정이 많다.

---

1. TCP vs UDP (★★★ 최다 단골)

실제 질문: "TCP와 UDP의 차이는?" · "Checksum이 무엇이고, Checksum으로 오류를 정정할 수 있나요?" · "TCP가 신뢰성을 보장하는 방법은?" · "왜 HTTP는 TCP를 쓰고 HTTP/3는 UDP를 쓰나요?" (VSFe·WeareSoft)

깊이 — TCP 신뢰성: 시퀀스 번호(순서·중복 제거)·ACK(수신 확인)·재전송(타임아웃·중복 ACK)·체크섬(오류 검출)·흐름/혼잡 제어.

꼬리질문: "checksum으로 오류 정정?" → 불가(★). checksum은 검출만 → TCP는 재전송으로, UDP는 폐기. / "UDP는 언제?" → 실시간성이 신뢰성보다 중요(스트리밍·게임). / "HTTP/3가 UDP인 이유?" → TCP의 경직된 순서보장이 HOL Blocking 원인이라 UDP 위 QUIC로(5절).

함정: ❌ "checksum으로 오류를 고친다" → 검출만. ❌ "UDP는 checksum이 없다" → IPv4 옵션·IPv6 필수.

---

2. 3-way / 4-way Handshake (★★ 단골)

실제 질문: "3-way handshake를 설명하라." · "2-way로 안 하는 이유는?" · "왜 종료 후 바로 안 끝나고 TIME_WAIT으로 대기하나요?" · "ISN을 난수로 두는 이유는?" (VSFe·WeareSoft)

연결: SYN(seq=x) → SYN+ACK(seq=y, ack=x+1) → ACK(ack=y+1)
종료: FIN → ACK → (CLOSE_WAIT) FIN → ACK → (TIME_WAIT)

깊이: 3-way는 양방향 송수신 능력을 상호 확인(2-way면 한쪽의 초기 seq를 못 확정). 4-way는 서버가 보낼 데이터가 남아 ACK를 먼저(CLOSE_WAIT) 보내고 나중에 FIN → 단계가 하나 더.

꼬리질문: "TIME_WAIT 이유?" → ① 마지막 ACK 유실 대비(재전송 수신) ② 뒤늦은 패킷이 새 연결에 섞이는 것 방지. 보통 2×MSL. / "CLOSE_WAIT vs TIME_WAIT?" → CLOSE_WAIT(서버, FIN 받고 close 안 함 → 쌓이면 앱 버그), TIME_WAIT(클라, 정상). / "ISN 난수 이유?" → 이전 연결 잔존 패킷·시퀀스 예측 공격 방지. / "FIN vs RST?" → 정상 종료 vs 강제 종료.

함정: ❌ "CLOSE_WAIT가 쌓이는 건 정상" → close() 누락 버그 신호.

---

3. 흐름제어 vs 혼잡제어 (★★ 단골)

실제 질문: "TCP의 혼잡 제어 방법을 설명하라." · "흐름제어와 혼잡제어의 차이는?" (VSFe·gyoogle)

• 흐름제어(Flow Control): 수신자 버퍼 오버플로 방지. 슬라이딩 윈도우(수신 윈도우 광고).
• 혼잡제어(Congestion Control): 네트워크(라우터) 혼잡 방지. 혼잡 윈도우(cwnd):
  • Slow Start: ACK 1개당 cwnd +1 MSS → RTT마다 2배(지수)·임계값(ssthresh)까지.
  • AIMD(혼잡 회피): 가산 증가(1)·곱셈 감소(절반).
  • Fast Retransmit: 중복 ACK 3개 → 타임아웃 안 기다리고 즉시 재전송.
  • Fast Recovery: cwnd를 1이 아닌 절반으로.

꼬리질문: "둘의 주체가 다른가?" → 흐름=수신자(수신 윈도우), 혼잡=네트워크(cwnd). 실제 송신량 = min(수신 윈도우, cwnd). / "혼잡을 어떻게 감지?" → 타임아웃·중복 ACK.

함정: ❌ 흐름제어와 혼잡제어를 섞어 답하기(가장 흔한 감점). "윈도우"가 둘 다 나오지만 수신 윈도우 vs cwnd로 주체가 다르다.

---

4. HTTP / HTTPS (★★ 단골)

실제 질문: "HTTP와 HTTPS 차이는?" · "공개키/대칭키를 설명하고, 왜 HTTPS는 둘 다 쓰나요?" · "SSL과 TLS의 차이는?" · "GET과 POST의 차이는?" (VSFe·gyoogle)

• HTTP(80·평문) vs HTTPS(443·TLS 암호화). 무상태(Stateless)·비연결(Connectionless).
• HTTPS 동작: ① 비대칭키로 대칭키(세션키)를 안전하게 교환 ② 이후 빠른 대칭키로 데이터 암호화. 비대칭만 쓰면 느려서. CA 인증서로 서버 신원 검증(위장 방지).
• SSL vs TLS: SSL이 전신, TLS가 표준화된 후속(SSL 3.0 → TLS 1.0~1.3).

깊이 — GET vs POST: GET은 안전(safe)·멱등·캐싱·URL 공유, POST는 본문·비멱등·생성. "조회는 GET"인 이유 = 캐싱·북마크·멱등성.

꼬리질문: "HTTPS면 100% 안전?" → 신뢰 CA 발급분만·자체서명은 MITM 검증 불가. / "왜 비대칭+대칭 혼합?" → 비대칭은 느려 키 교환만. / "개인키는 어디?" → 서버에만(클라는 공개키).

함정: ❌ "HTTPS는 대칭키만 쓴다" / "비대칭키로 전부 암호화한다" → 키 교환만 비대칭.

---

5. HTTP/1.1 vs HTTP/2 vs HTTP/3 (★★ 단골)

실제 질문: "HTTP/1.1과 HTTP/2의 차이는?" · "HOL(Head-of-Line) Blocking을 설명하라." · "HTTP/3의 주요 특징은?" (VSFe)

깊이 — HOL Blocking(★): HTTP/1.1은 앱 레벨 HOL(앞 요청이 막으면 뒤가 대기). HTTP/2는 멀티플렉싱으로 앱 레벨은 해결했으나, 하나의 TCP 위라 한 패킷 손실 시 TCP 재전송 동안 모든 스트림이 멈춤(TCP 레벨 HOL 잔존). HTTP/3는 **QUIC(UDP)**로 스트림이 독립적이라 한 스트림 손실이 남을 안 막음 + TLS 1.3 통합(0-RTT)·Connection Migration(IP 변경에도 연결 유지).

꼬리질문: "HTTP/2가 HOL을 완전히 해결?" → 아니다(★). 앱 레벨만·TCP 레벨은 잔존 → HTTP/3가 해소. / "왜 HTTP/3가 UDP를?" → TCP의 순서보장이 HOL 원인이라 UDP 위 QUIC가 스트림별 독립 제어.

함정: ❌ "HTTP/2 멀티플렉싱으로 HOL 완전 해결" → TCP 레벨 잔존.

---

6. 쿠키·세션·DNS·로드밸런서·OSI (★ 단골)

실제 질문: "쿠키와 세션의 차이는?" · "HTTP Stateless를 설명하라(쿠키/세션이 왜 필요)." · "DNS의 Recursive/Iterative Query는?" · "L4와 L7 로드밸런서의 차이는?" · "OSI 7계층에서 전송 계층과 네트워크 계층의 차이는?" (VSFe·WeareSoft)

• 쿠키 vs 세션: 쿠키(클라 저장·4KB·보안 약함) vs 세션(서버 저장·세션ID만 쿠키로 전달). HTTP가 Stateless라 상태 유지를 위해 필요. → 서버 여러 대면 Redis 세션 스토어·Sticky Session.
• DNS: 도메인→IP. 재귀 질의(리졸버가 끝까지 대신) vs 반복 질의(네임서버가 다음 주소만). A(IPv4)·AAAA(IPv6)·CNAME(별칭). 응용계층·주로 UDP 53.
• 로드밸런서: L4(IP/Port·빠름) vs L7(URL/헤더/쿠키 기반 라우팅·유연). 알고리즘 RR·Least Connections·IP Hash.
• OSI: 전송(TCP/UDP·포트·end-to-end) vs 네트워크(IP·라우팅·host-to-host). PDU: 비트→프레임→패킷→세그먼트.

꼬리질문: "세션도 쿠키를 쓰나?" → 예(세션ID 운반). / "JWT는 세션과 뭐가 다른가?" → 서버 상태 없음(인증 편). / "L4 vs L7 선택?" → 단순 분산 L4·콘텐츠 기반 라우팅 L7.

함정: ❌ "세션은 쿠키를 안 쓴다" → 세션ID는 보통 쿠키. ❌ "L7이 항상 낫다" → 오버헤드·L4가 빠름.

---

흔한 오답·함정 정리

• checksum으로 오류 정정 → 검출만(재전송으로 복구).
• HTTP/2가 HOL 완전 해결 → TCP 레벨 잔존(HTTP/3 해소).
• 세션은 쿠키 안 씀 → 세션ID를 쿠키로.
• CLOSE_WAIT 쌓임이 정상 → close() 누락 버그.
• HTTPS는 대칭/비대칭 중 하나만 → 키 교환 비대칭 + 데이터 대칭.

한국 면접 단골 Q&A (답변 골격)

꼬리질문 대비 (상 난이도)

• "TIME_WAIT이 너무 많다?" → 짧은 연결 폭주·서버가 먼저 close → keep-alive·재사용.
• "HTTP/3 장점 추가?" → 0-RTT 핸드셰이크·Connection Migration(IP 변경 유지).
• "DNS 질의 흐름?" → 캐시→Root→TLD→Authoritative·재귀/반복.
• "세션 서버가 여러 대면?" → Redis 세션 스토어·Sticky Session·JWT.
• "혼잡 시 cwnd?" → 타임아웃이면 1로(slow start)·3 dup ACK면 절반(fast recovery).

한 줄 요약 — TCP(연결·신뢰성·흐름/혼잡)↔UDP(비연결·빠름). checksum은 검출만. 3-way(양방향 확인)·TIME_WAIT(ACK 유실·잔존 패킷)·CLOSE_WAIT 누적은 버그. 흐름(수신 윈도우)↔혼잡(cwnd·slow start·AIMD·3 dup ACK). HTTPS=비대칭 키교환+대칭 암호화·CA. HTTP/2는 TCP HOL 잔존, HTTP/3(QUIC)가 해소. 쿠키(클라)↔세션(서버·세션ID 쿠키)·DNS(재귀/반복)·L4/L7.

(출처 — 한국 면접 기출·교차검증 2026-06: VSFe/Tech-Interview — Network·WeareSoft — network·gyoogle — Network · RFC 9293(TCP)·RFC 9110(HTTP)·APNIC — HTTP/3·QUIC·HOL 교차검증.)