네트워크 시니어 기술면접
새 면접Q. 대규모 트래픽을 처리하는 서비스에서 TIME_WAIT 소켓이 과도하게 쌓여 새로운 연결 수립이 어려워지는 상황이 발생했습니다. TIME_WAIT 상태의 존재 이유와 이 문제를 해결하기 위한 아키텍처 레벨의 접근 방법을 설명해주세요.
TCP 연결 종료 과정에서 TIME_WAIT가 필요한 이유와 커널 파라미터 튜닝, 연결 재사용 전략을 고려해보세요.
TIME_WAIT는 TCP 연결 종료 시 지연된 패킷이나 재전송 패킷을 처리하고, 이전 연결의 패킷이 새 연결에 영향을 주지 않도록 2MSL(Maximum Segment Lifetime) 동안 유지됩니다. 해결 방법으로는 첫째, SO_REUSEADDR 소켓 옵션과 tcp_tw_reuse 커널 파라미터를 활성화하여 TIME_WAIT 소켓을 안전하게 재사용할 수 있습니다. 둘째, HTTP Keep-Alive나 Connection Pooling을 통해 연결을 재사용하여 새로운 연결 생성 자체를 줄입니다. 셋째, 로드밸런서나 리버스 프록시를 두어 클라이언트 연결을 집약하고 백엔드와는 소수의 지속 연결을 유지하는 아키텍처로 개선합니다. 마지막으로 포트 범위 확장(ip_local_port_range)을 통해 사용 가능한 포트 수를 늘리는 방법도 고려할 수 있습니다.
- • TIME_WAIT는 지연 패킷 처리와 연결 격리를 위해 2MSL 동안 유지됨
- • tcp_tw_reuse, SO_REUSEADDR을 통한 소켓 재사용
- • Connection Pooling과 Keep-Alive로 연결 재사용
- • 로드밸런서를 통한 연결 집약 아키텍처
고트래픽 API 서버나 마이크로서비스 간 통신에서 연결 고갈 문제를 해결할 때 필수적으로 고려해야 합니다.
tcp_tw_recycle 파라미터는 왜 사용하면 안 되는지, NAT 환경에서 어떤 문제가 발생하는지 설명해주세요.
Q. L4와 L7 로드밸런서의 동작 원리 차이를 OSI 모델 관점에서 설명하고, 각각의 장단점과 적합한 사용 사례를 비교해주세요. 특히 대규모 트래픽 환경에서의 성능 차이를 중심으로 설명해주세요.
각 레이어에서 접근 가능한 정보와 그에 따른 라우팅 결정의 정교함, 그리고 처리 오버헤드를 비교해보세요.
L4 로드밸런서는 전송 계층에서 동작하며 IP 주소와 포트 정보만으로 라우팅을 결정하고, DSR(Direct Server Return)이나 NAT 방식으로 패킷을 전달합니다. 반면 L7 로드밸런서는 응용 계층에서 동작하여 HTTP 헤더, URL, 쿠키 등의 콘텐츠 정보를 분석해 정교한 라우팅이 가능하지만 패킷을 파싱하고 재조립하는 오버헤드가 있습니다. L4는 초당 수백만 연결을 처리할 수 있어 성능이 중요한 환경에 적합하며, L7는 MSA 환경에서 URL 기반 라우팅, A/B 테스트, SSL Termination이 필요할 때 유용합니다. 대규모 환경에서는 L4를 앞단에 두고 L7를 뒷단에 배치하는 하이브리드 구성을 통해 성능과 유연성을 모두 확보하는 것이 일반적입니다. L7는 세션 어피니티와 헬스체크를 애플리케이션 레벨에서 수행할 수 있다는 장점도 있습니다.
- • L4는 IP/Port 기반, L7는 애플리케이션 콘텐츠 기반 라우팅
- • L4가 성능 우수, L7가 라우팅 정교함
- • 하이브리드 구성으로 성능과 유연성 확보
- • 사용 사례에 따른 적절한 선택 필요
마이크로서비스 아키텍처에서 서비스 메시나 API Gateway 선택 시 L4/L7 특성을 이해해야 적절한 설계가 가능합니다.
클라우드 환경에서 ALB와 NLB의 차이점과 각각을 선택하는 기준은 무엇인가요?
Q. DNS의 계층적 구조와 재귀적 질의(Recursive Query)와 반복적 질의(Iterative Query)의 차이를 설명하고, 대규모 서비스에서 DNS 장애가 전체 시스템에 미치는 영향을 최소화하기 위한 전략을 제시해주세요.
DNS 조회 과정에서 각 주체(클라이언트, 리졸버, 네임서버)의 역할과 캐싱 전략을 고려해보세요.
DNS는 루트, TLD, 권한 네임서버로 이루어진 계층 구조를 가지며, 재귀적 질의는 리졸버가 최종 답을 찾아 반환하고, 반복적 질의는 각 단계의 네임서버 주소만 알려줘 클라이언트가 직접 탐색합니다. 일반적으로 클라이언트-리졸버 간은 재귀적, 리졸버-네임서버 간은 반복적 질의를 사용합니다. DNS 장애 대응을 위해서는 첫째, 애플리케이션 레벨에서 DNS 캐싱(TTL 존중)과 Connection Pooling으로 조회 빈도를 줄이고, 둘째, 다중 DNS 서버 구성과 헬스체크를 통한 자동 페일오버를 구현합니다. 셋째, 서비스 디스커버리 패턴(Consul, etcd)을 도입해 DNS 의존도를 낮추고, 넷째, 긴 TTL과 짧은 TTL의 트레이드오프를 고려해 적절한 값을 설정합니다.
- • 재귀적 질의는 리졸버가 최종 답 반환, 반복적 질의는 단계별 참조 반환
- • 애플리케이션 레벨 DNS 캐싱으로 조회 빈도 감소
- • 다중 DNS 서버와 서비스 디스커버리 패턴 활용
- • TTL 설정의 트레이드오프 이해
글로벌 서비스에서 DNS 장애 시 전체 서비스가 다운되는 것을 방지하기 위해 DNS 캐싱과 폴백 전략이 필수적입니다.
DNS 기반 로드밸런싱(Round-Robin DNS)의 한계점과 이를 극복하기 위한 대안은 무엇인가요?
Q. HTTP/2와 HTTP/3(QUIC)의 주요 개선사항을 설명하고, 각각이 해결하려는 HTTP/1.1의 근본적인 문제점을 Head-of-Line Blocking 관점에서 분석해주세요. 또한 실제 프로덕션 환경에 HTTP/3를 도입할 때 고려해야 할 사항을 설명해주세요.
각 프로토콜이 동작하는 전송 계층의 차이와 멀티플렉싱 구현 방식을 비교해보세요.
HTTP/1.1은 하나의 TCP 연결에서 순차적으로 요청을 처리하여 HOL Blocking이 발생하며, 이를 우회하기 위해 다중 연결을 사용해 리소스 낭비가 큽니다. HTTP/2는 단일 TCP 연결에서 스트림 기반 멀티플렉싱을 도입해 애플리케이션 레벨 HOL Blocking은 해결했지만, TCP 레벨에서 패킷 손실 시 모든 스트림이 대기하는 TCP HOL Blocking은 여전히 존재합니다. HTTP/3는 UDP 기반 QUIC 프로토콜을 사용해 스트림 단위로 독립적인 재전송을 수행하여 TCP HOL Blocking까지 완전히 해결했으며, 0-RTT 연결 재개와 연결 마이그레이션(IP 변경 시에도 연결 유지)을 지원합니다. 프로덕션 도입 시에는 UDP 트래픽 허용을 위한 방화벽 정책 변경, CDN과 로드밸런서의 QUIC 지원 여부, 모바일 환경에서의 배터리 소모 증가, 그리고 폴백 메커니즘(HTTP/2로 자동 전환) 구현을 고려해야 합니다.
- • HTTP/2는 애플리케이션 레벨 HOL Blocking 해결, TCP 레벨은 미해결
- • HTTP/3(QUIC)는 UDP 기반으로 TCP HOL Blocking까지 완전 해결
- • 0-RTT, 연결 마이그레이션 등 추가 이점 제공
- • 방화벽, 인프라 지원, 폴백 전략 필요
모바일 앱이나 실시간 스트리밍 서비스에서 네트워크 전환 시에도 끊김 없는 경험을 제공하기 위해 HTTP/3를 도입합니다.
QUIC의 연결 마이그레이션 기능이 모바일 환경에서 어떤 이점을 제공하는지 구체적으로 설명해주세요.
Q. TLS 1.2와 TLS 1.3의 핸드셰이크 과정 차이를 설명하고, TLS 1.3가 어떻게 레이턴시를 줄였는지 설명해주세요. 또한 대규모 서비스에서 SSL/TLS Termination을 어디에 배치할지 결정할 때 고려해야 할 아키텍처 요소들을 제시해주세요.
핸드셰이크 라운드트립 횟수와 암호화 스위트 협상 방식의 변화, 그리고 종단 간 암호화와 성능의 트레이드오프를 생각해보세요.
TLS 1.2는 2-RTT 핸드셰이크를 수행하며 클라이언트와 서버가 암호화 스위트를 협상한 후 키 교환을 진행하지만, TLS 1.3는 1-RTT로 단축하여 클라이언트가 첫 메시지에 키 공유 정보를 포함시키고 서버가 즉시 응답합니다. 또한 0-RTT 재개를 지원해 이전 세션 정보로 즉시 암호화 통신이 가능하며, 취약한 암호화 알고리즘을 제거하고 forward secrecy를 필수화했습니다. SSL Termination 배치는 여러 요소를 고려해야 하는데, 로드밸런서에서 처리하면 백엔드 서버의 CPU 부하를 줄이고 인증서 관리가 중앙화되지만 내부 네트워크 구간이 평문 노출됩니다. 반면 백엔드까지 종단 암호화하면 보안은 강화되지만 성능 오버헤드와 인증서 관리 복잡도가 증가합니다. 일반적으로 신뢰할 수 있는 내부 네트워크에서는 로드밸런서에서 Termination하고, 컴플라이언스 요구사항이 있거나 멀티테넌시 환경에서는 종단 암호화를 선택합니다.
- • TLS 1.3는 1-RTT 핸드셰이크와 0-RTT 재개로 레이턴시 감소
- • 취약 알고리즘 제거와 forward secrecy 필수화
- • SSL Termination 위치는 보안과 성능의 트레이드오프
- • 인증서 관리, 컴플라이언스, 네트워크 신뢰도 고려
글로벌 서비스에서 사용자 체감 속도 개선을 위해 TLS 1.3 도입과 SSL Termination 최적화는 필수적인 성능 튜닝 항목입니다.
0-RTT의 보안 취약점(replay attack)과 이를 완화하기 위한 방법은 무엇인가요?
Q. CDN의 동작 원리와 캐싱 전략을 설명하고, Origin Shield와 Multi-tier CDN 아키텍처의 개념과 이것이 오리진 서버 부하를 줄이는 원리를 설명해주세요. 또한 동적 콘텐츠에 대한 CDN 활용 방안을 제시해주세요.
엣지 로케이션의 계층 구조와 캐시 히트율을 높이는 전략, 그리고 동적 콘텐츠 가속 기법을 생각해보세요.
CDN은 지리적으로 분산된 엣지 서버에 콘텐츠를 캐싱하여 사용자와 가까운 위치에서 제공함으로써 레이턴시를 줄이고 오리진 부하를 분산시킵니다. Origin Shield는 엣지 서버와 오리진 사이에 추가 캐시 계층을 두어, 여러 엣지에서 동시에 같은 콘텐츠를 요청해도 Origin Shield가 단일 요청으로 집약해 오리진 부하를 크게 줄입니다. Multi-tier 구조에서는 Regional Edge와 Origin Shield를 조합해 캐시 히트율을 극대화하고, Cache-Control 헤더와 Vary 헤더를 적절히 설정해 캐싱 정책을 제어합니다. 동적 콘텐츠는 전통적으로 CDN에 부적합하지만, Edge Computing을 통해 엣지에서 간단한 로직을 실행하거나, 개인화되지 않은 부분만 캐싱하고 ESI(Edge Side Includes)로 조합하거나, TCP/TLS 최적화와 라우팅 최적화를 통한 동적 가속(Dynamic Site Acceleration)을 활용할 수 있습니다.
- • CDN은 엣지 캐싱으로 레이턴시 감소와 오리진 부하 분산
- • Origin Shield로 오리진 요청 집약화
- • Cache-Control 헤더로 캐싱 정책 제어
- • Edge Computing과 ESI로 동적 콘텐츠 가속
글로벌 서비스 런칭 시 특정 지역의 트래픽 급증에 대비해 CDN 아키텍처를 설계하고 오리진 보호 전략을 수립해야 합니다.
CDN 캐시 무효화(purge/invalidation) 전략과 대규모 배포 시 캐시 워밍은 어떻게 수행하나요?
Q. DDoS 공격의 주요 유형(Volumetric, Protocol, Application Layer)을 설명하고, 각 계층별 공격에 대응하기 위한 방어 전략과 아키텍처 설계 원칙을 제시해주세요. 특히 L7 DDoS 방어의 어려움과 해결 방법을 중심으로 설명해주세요.
각 계층 공격의 특징과 탐지 방법, 그리고 정상 트래픽과 공격 트래픽을 구분하는 어려움을 고려해보세요.
Volumetric 공격(UDP Flood, DNS Amplification)은 대역폭을 포화시키며 ISP 레벨이나 CDN의 트래픽 스크러빙 센터에서 차단하고, Protocol 공격(SYN Flood, ACK Flood)은 서버 리소스를 고갈시키므로 SYN Cookie, Connection Limiting, Rate Limiting으로 대응합니다. L7 공격(HTTP Flood, Slowloris)은 정상 트래픽처럼 보이면서 애플리케이션 리소스를 소진시켜 가장 방어가 어렵습니다. L7 방어를 위해서는 첫째, WAF와 Bot Detection을 통해 비정상 패턴을 분석하고, 둘째, CAPTCHA나 JavaScript Challenge로 봇을 필터링하며, 셋째, Rate Limiting을 IP, 세션, API 엔드포인트 단위로 세밀하게 적용합니다. 아키텍처적으로는 Auto-scaling으로 일시적 부하를 흡수하고, 핵심 서비스와 부가 서비스를 분리해 부분 장애를 격리하며, Anycast 라우팅으로 트래픽을 분산시키고, 다층 방어(Defense in Depth)로 여러 계층에서 필터링합니다.
- • Volumetric은 대역폭, Protocol은 연결 리소스, L7은 애플리케이션 리소스 공격
- • L7 공격은 정상 트래픽 구분이 어려워 방어 복잡
- • WAF, Bot Detection, Rate Limiting 조합 필요
- • Auto-scaling, 서비스 격리, Anycast, 다층 방어
대규모 이커머스 이벤트나 선착순 프로모션 시 정상 트래픽과 DDoS를 구분하여 서비스 가용성을 유지해야 합니다.
Slowloris 공격의 원리와 이를 방어하기 위한 웹 서버 설정과 타임아웃 전략을 설명해주세요.
Q. BGP(Border Gateway Protocol)의 동작 원리와 AS(Autonomous System) 개념을 설명하고, BGP Hijacking 공격과 이를 방어하기 위한 RPKI(Resource Public Key Infrastructure)의 역할을 설명해주세요. 클라우드 환경에서 BGP가 어떻게 활용되는지도 함께 설명해주세요.
인터넷의 라우팅이 어떻게 분산되어 있고, 경로 정보의 신뢰성을 어떻게 검증하는지 생각해보세요.
BGP는 인터넷의 AS 간 라우팅 프로토콜로, 각 AS는 자율적으로 관리되는 네트워크 집합이며 고유한 AS 번호를 가집니다. BGP는 경로 벡터 프로토콜로 AS 경로 정보를 교환하며, 정책 기반 라우팅으로 최단 경로가 아닌 비즈니스 관계에 따라 경로를 선택할 수 있습니다. BGP Hijacking은 악의적으로 타인의 IP 프리픽스를 자신의 것으로 광고해 트래픽을 가로채는 공격이며, RPKI는 암호화 서명으로 IP 프리픽스와 AS 번호의 소유권을 검증해 정당한 광고인지 확인합니다. 클라우드 환경에서는 Anycast IP를 여러 리전에 광고해 가장 가까운 엔드포인트로 라우팅하거나, Direct Connect나 전용선을 BGP로 연결해 온프레미스와 통합하며, Multi-cloud 환경에서 BGP 피어링으로 클라우드 간 직접 연결을 구성합니다.
- • BGP는 AS 간 경로 벡터 프로토콜로 정책 기반 라우팅
- • BGP Hijacking으로 트래픽 가로채기 가능
- • RPKI로 IP 프리픽스 소유권 암호학적 검증
- • 클라우드에서 Anycast, Direct Connect, Multi-cloud 연결에 활용
글로벌 서비스에서 지역별 최적 라우팅과 장애 시 자동 경로 전환을 위해 BGP 기반 Anycast를 구성합니다.
BGP의 경로 선택 알고리즘에서 AS Path Length 외에 고려되는 속성들과 우선순위를 설명해주세요.
Q. VXLAN과 같은 오버레이 네트워크의 동작 원리를 설명하고, 언더레이 네트워크와의 관계를 설명해주세요. 컨테이너 환경에서 CNI(Container Network Interface)가 어떻게 Pod 간 통신을 구현하는지, 그리고 Network Policy를 통한 마이크로세그멘테이션 구현 방법을 설명해주세요.
캡슐화를 통한 네트워크 확장과 논리적 격리, 그리고 컨테이너 네트워크의 계층 구조를 생각해보세요.
VXLAN은 L2 프레임을 UDP 패킷으로 캡슐화하여 L3 네트워크 위에 오버레이 네트워크를 구성하며, 24비트 VNI로 최대 1600만 개의 논리 네트워크를 생성해 VLAN의 4096개 제한을 극복합니다. 언더레이는 물리적 네트워크 인프라로 VXLAN 패킷을 전달하고, 오버레이는 그 위에 구성된 논리적 네트워크로 테넌트 격리와 유연한 네트워크 토폴로지를 제공합니다. CNI는 컨테이너 런타임과 네트워크 플러그인 간 표준 인터페이스로, Calico나 Flannel 같은 플러그인이 각 Pod에 IP를 할당하고 veth pair로 호스트 네트워크와 연결하며, 라우팅 테이블이나 BGP로 Pod 간 통신을 구현합니다. Network Policy는 Pod 셀렉터와 규칙으로 ingress/egress 트래픽을 제어하며, CNI 플러그인이 이를 iptables나 eBPF 규칙으로 변환해 커널 레벨에서 강제하여 마이크로세그멘테이션을 구현합니다.
- • VXLAN은 L2 over L3 캡슐화로 오버레이 네트워크 구성
- • VNI로 대규모 테넌트 격리, VLAN 한계 극복
- • CNI는 컨테이너 네트워킹 표준 인터페이스
- • Network Policy를 iptables/eBPF로 변환해 마이크로세그멘테이션
Kubernetes 클러스터에서 수천 개의 Pod를 안전하게 격리하고 세밀한 접근 제어를 구현할 때 필수적인 개념입니다.
Service Mesh의 사이드카 프록시가 네트워크 레벨에서 어떻게 트래픽을 가로채고 제어하는지 설명해주세요.
Q. TCP의 혼잡 제어 알고리즘(Slow Start, Congestion Avoidance, Fast Retransmit, Fast Recovery)을 설명하고, 고대역폭-고지연(high bandwidth-delay product) 환경에서 TCP 성능 저하 문제와 이를 개선하기 위한 BBR(Bottleneck Bandwidth and RTT) 알고리즘의 접근 방식을 설명해주세요.
패킷 손실을 혼잡의 신호로 보는 전통적 방식의 한계와, 대역폭과 RTT를 직접 측정하는 방식의 차이를 생각해보세요.
TCP 혼잡 제어는 Slow Start에서 지수적으로 윈도우를 증가시키다가 임계값에 도달하면 Congestion Avoidance로 전환해 선형 증가하며, 패킷 손실 감지 시 Fast Retransmit으로 즉시 재전송하고 Fast Recovery로 윈도우를 절반으로 줄입니다. 전통적 알고리즘(Reno, Cubic)은 패킷 손실을 혼잡 신호로 간주하지만, 고BDP 환경에서는 버퍼가 커서 손실이 늦게 감지되고 RTT가 길어 윈도우 증가가 느려 대역폭을 충분히 활용하지 못합니다. BBR은 패킷 손실 대신 실제 병목 대역폭과 RTT를 주기적으로 측정해 최적의 전송률을 계산하며, ProbeBW와 ProbeRTT 상태를 순환하며 네트워크 상태를 탐색합니다. BBR은 버퍼 팽창(bufferbloat)을 줄이고 일정한 RTT를 유지하면서도 높은 처리량을 달성하며, 위성 통신이나 장거리 해저 케이블 같은 고BDP 환경에서 특히 효과적입니다.
- • 전통적 TCP는 패킷 손실 기반 혼잡 제어
- • 고BDP 환경에서 대역폭 활용 비효율
- • BBR은 병목 대역폭과 RTT 직접 측정
- • 버퍼 팽창 감소와 처리량 개선
글로벌 CDN이나 클라우드 간 대용량 데이터 전송 시 BBR 적용으로 전송 시간을 크게 단축할 수 있습니다.
BBR의 fairness 문제와 기존 Cubic과 공존할 때 발생할 수 있는 이슈는 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!