[Network] 네트워크 총정리

NETWORK

네트워크 총정리

목차

1. 네트워크 계층 구조 (OSI 7계층, TCP/IP 4계층)
2. 패킷과 캡슐화
3. 물리 계층과 데이터 링크 계층
4. 네트워크 계층 (IP, 라우팅, NAT)
5. 전송 계층 (TCP, UDP)
6. TCP 3-way handshake와 4-way handshake
7. 흐름 제어와 혼잡 제어
8. 응용 계층 (HTTP, HTTPS)
9. 대칭키, 공개키와 TLS handshake
10. 브라우저에 naver.com을 치면 일어나는 일
11. 로드 밸런싱과 서버 확장
12. Blocking, Non-blocking과 Synchronous, Asynchronous
13. 면접 예상 질문 40선

1. 네트워크 계층 구조

OSI 7계층을 나누는 이유

가장 중요한 목적은 표준화와 학습 도구입니다. 표준화를 통해 이질적인 포트나 프로토콜 때문에 생기는 호환성 문제를 해결해 비용을 절감했습니다. 또한 계층별 기능과 통신 과정을 단계로 나누면 흐름을 이해하기 쉽고, 특정 지점에 이상이 생겼을 때 그 계층만 수정하면 되기 때문에 유지보수가 편리합니다.
각 계층이 독립적으로 동작하도록 관심사를 분리해서, 문제 발생 지점을 특정하고 특정 계층만 교체할 수 있게 하기 위해서입니다.

계층별 정리

계층	이름	데이터 단위	주소	대표 프로토콜, 장비
7	응용(Application)	메시지(Message)	:	HTTP, FTP, DNS, SMTP
6	표현(Presentation)	메시지	:	JPEG, MPEG, SSL/TLS, 인코딩
5	세션(Session)	메시지	:	API, Socket, RPC
4	전송(Transport)	세그먼트(Segment)	포트 번호	TCP, UDP
3	네트워크(Network)	패킷(Packet)	IP 주소	IP, ICMP, 라우터, L3 스위치
2	데이터 링크(Data Link)	프레임(Frame)	MAC 주소	Ethernet, 스위치, 브릿지
1	물리(Physical)	비트(Bit)	:	케이블, 리피터, 허브

1) 물리 계층

리피터, 허브, 케이블이 여기에 속합니다. 전기적, 기계적 특성을 이용해 비트 단위 신호를 전송하는 역할만 담당합니다. 데이터가 무엇인지는 전혀 모릅니다.

2) 데이터 링크 계층

같은 네트워크 안에서 인접한 장비끼리의 전달을 책임집니다. MAC 주소를 이용해 통신하며, 프레임에 MAC 주소를 붙이고 에러 검출, 재전송, 흐름 제어를 수행합니다. 스위치가 대표 장비입니다.

3) 네트워크 계층

서로 다른 네트워크 사이의 경로를 찾아 목적지까지 데이터를 전달합니다. IP 주소를 지정하고 라우터가 경로를 선택해 패킷을 전달합니다. 라우팅, 단편화(fragmentation), 오류 제어를 수행합니다.

4) 전송 계층

포트 번호로 프로세스를 식별해서, 양 끝단 애플리케이션끼리 데이터를 주고받게 해줍니다. TCP는 신뢰성 있는 연결 지향, UDP는 비신뢰성 비연결형입니다.

5) 세션 계층

양 끝단 응용 프로세스의 연결을 생성, 유지, 종료하는 논리적 연결을 담당합니다.

6) 표현 계층

데이터 표현 형식의 차이를 흡수합니다. 인코딩, 압축, 암호화가 여기에 해당합니다.

7) 응용 계층

사용자와 가장 가까운 계층으로, HTTP나 DNS처럼 실제 서비스를 제공합니다.

OSI 7계층과 TCP/IP 4계층

실제 인터넷은 OSI가 아니라 TCP/IP 모델로 동작합니다. OSI는 이론적 참조 모델, TCP/IP는 실제 구현 모델이라고 답하면 됩니다.

TCP/IP 4계층	대응하는 OSI 계층
애플리케이션	응용 + 표현 + 세션
전송	전송
인터넷	네트워크
네트워크 액세스	데이터 링크 + 물리

---

2. 패킷과 캡슐화

패킷이란

패킷은 네트워크에서 출발지와 목적지 사이를 라우팅되는 데이터의 단위입니다. 패키지(package)와 덩어리를 뜻하는 버킷(bucket)을 합친 말로, 통신망을 통해 전송하기 쉽도록 자른 데이터의 전송 단위입니다.

패킷의 구조

+----------------------------------------+
|              헤더 (Header)              |
|   패킷 길이, 프로토콜, 출발지/목적지 IP    |
+----------------------------------------+
|            페이로드 (Payload)            |
|            실제 전송되는 데이터            |
+----------------------------------------+
|            트레일러 (Trailer)            |
|      오류 검출 코드 (CRC, 체크섬 등)       |
+----------------------------------------+

헤더 : 패킷 길이, 프로토콜, 보내는 쪽과 받는 쪽의 IP 주소

페이로드 : 실제 전송되는 데이터의 내용

트레일러 : 패킷의 끝을 표시하고 오류 검출, 정정 정보를 담습니다

캡슐화와 역캡슐화

송신 측에서는 상위 계층에서 내려올 때마다 각 계층의 헤더가 하나씩 붙습니다. 이것을 캡슐화라고 합니다.

데이터
→ [TCP 헤더 | 데이터]                          세그먼트
→ [IP 헤더 | TCP 헤더 | 데이터]                 패킷
→ [Ethernet 헤더 | IP 헤더 | TCP 헤더 | 데이터 | FCS]   프레임

수신 측은 반대로 아래 계층부터 헤더를 하나씩 벗겨내며 올라갑니다. 이것이 역캡슐화입니다. 데이터를 전송할 때 오버헤드가 생기는 이유가 바로 이 헤더들 때문입니다.

MTU와 단편화

MTU(Maximum Transmission Unit)는 한 번에 전송할 수 있는 최대 크기이고 이더넷 기준 보통 1500바이트입니다. 이보다 큰 데이터는 잘려서 전송되는데, 이 과정을 IP 단편화라고 합니다. 단편화가 일어나면 조각 하나만 유실돼도 전체를 재전송해야 하므로 성능이 떨어집니다. 그래서 TCP는 MSS(Maximum Segment Size)를 협상해 애초에 단편화가 생기지 않는 크기로 보냅니다.

---

3. 물리 계층과 데이터 링크 계층

MAC 주소

48비트, 16진수로 표기되는 물리 주소입니다. 제조 단계에서 NIC(네트워크 인터페이스 카드)에 부여되며 원칙적으로 전 세계에서 유일합니다. IP 주소가 논리 주소로 바뀔 수 있는 반면, MAC 주소는 장비에 고정된 주소입니다.

ARP (Address Resolution Protocol)

IP 주소는 아는데 MAC 주소를 모를 때, IP 주소로 MAC 주소를 알아내는 프로토콜입니다.

동작 순서는 이렇습니다. 같은 네트워크 안에 브로드캐스트로 "이 IP를 쓰는 장비의 MAC 주소가 무엇인가"를 묻고, 해당 IP를 가진 장비만 유니캐스트로 자기 MAC 주소를 응답합니다. 응답 결과는 ARP 캐시에 일정 시간 저장됩니다.

왜 둘 다 필요한가가 단골 질문입니다. IP는 네트워크와 네트워크 사이를 건너가기 위한 논리 주소이고, MAC은 최종 구간에서 실제 장비를 특정하기 위한 물리 주소입니다. 목적지 IP는 끝까지 변하지 않지만, 목적지 MAC은 라우터를 하나 지날 때마다 다음 홉의 MAC으로 계속 바뀝니다.

스위치와 허브의 차이

허브는 들어온 신호를 모든 포트로 그대로 뿌립니다(1계층). 스위치는 MAC 주소 테이블을 보고 목적지 포트로만 전달합니다(2계층). 그래서 허브는 충돌 도메인이 하나지만, 스위치는 포트마다 충돌 도메인이 분리됩니다.

---

4. 네트워크 계층

IP 주소

인터넷에 연결된 장비를 식별하는 번호입니다.

IPv4 : 32비트, 8비트씩 4개로 나누어 10진수 표기 (예: 192.168.0.1). 약 43억 개로 고갈 문제가 있습니다.

IPv6 : 128비트, 사실상 고갈 걱정이 없습니다.

IPv4 고갈에 대응하기 위해 사내망에서는 사설 IP를 쓰고, 인터넷 경계에서 NAT 장비가 공인 IP와 사설 IP를 변환합니다.

구분	공인 IP	사설 IP
할당	ISP가 부여	라우터가 내부에서 부여
범위	전 세계 유일	내부망 안에서만 유일
외부 접근	가능	불가 (NAT 필요)

서브넷과 게이트웨이

서브넷은 하나의 IP 대역을 더 작은 네트워크로 나눈 단위입니다. 서브넷 마스크로 네트워크 부분과 호스트 부분을 구분합니다. 192.168.0.0/24라면 앞 24비트가 네트워크, 뒤 8비트가 호스트입니다.

게이트웨이는 네트워크와 네트워크를 연결해주는 출입구이고, 실무에서는 라우터가 가지는 사설 IP를 가리킵니다. 목적지가 같은 서브넷 안에 있으면 직접 보내고, 밖에 있으면 게이트웨이로 보냅니다.

라우팅

패킷이 목적지까지 갈 경로를 결정하는 과정입니다. 라우터는 라우팅 테이블을 보고 다음 홉을 정합니다. 정적 라우팅은 관리자가 직접 지정하고, 동적 라우팅은 RIP, OSPF, BGP 같은 프로토콜로 경로를 학습합니다.

DHCP

호스트의 IP 주소와 TCP/IP 기본 설정을 클라이언트에 자동으로 제공하는 프로토콜입니다. PC는 DHCP 서버로부터 자신의 IP 주소, 가장 가까운 라우터의 IP 주소, DNS 서버의 IP 주소를 받습니다. 그 후 ARP로 라우터의 MAC 주소를 알아냅니다.

☕ 인프라와의 연결

쿠버네티스의 Service ClusterIP는 실제 장비가 없는 가상 IP이고, kube-proxy가 iptables 규칙으로 파드 IP로 전달합니다. 도커의 브릿지 네트워크에서 컨테이너가 외부로 나갈 때도 호스트가 NAT를 수행합니다. ping은 되는데 서비스 접속이 안 된다면, ICMP(3계층)는 살아 있고 포트(4계층)나 방화벽 문제라는 뜻이므로 계층을 나눠서 원인을 좁힐 수 있습니다.

---

5. 전송 계층

TCP와 UDP

구분	TCP	UDP
연결 방식	연결 지향 (handshake 필요)	비연결형
신뢰성	보장 (재전송, 순서 보장)	보장하지 않음
순서	순서대로 도착 보장	순서 뒤바뀔 수 있음
흐름, 혼잡 제어	있음	없음
헤더 크기	20바이트 이상	8바이트
전송 단위	바이트 스트림	데이터그램
속도	상대적으로 느림	빠름
용도	HTTP, 파일 전송, 메일	DNS, 스트리밍, 실시간 게임, VoIP

UDP를 쓰는 이유

신뢰성이 없다는 것이 무조건 단점은 아닙니다. 실시간 영상이나 음성은 조금 유실되더라도 계속 흘러가는 것이 중요하지, 지난 프레임을 재전송받아봐야 이미 의미가 없습니다. DNS 질의는 데이터가 작아서 연결을 맺는 비용이 질의 자체보다 크기 때문에 UDP를 씁니다.

HTTP/3가 UDP 기반인 이유도 자주 물어봅니다. TCP는 세그먼트 하나가 유실되면 뒤에 온 데이터가 멀쩡해도 전부 대기하는 HOL(Head of Line) 블로킹이 발생합니다. HTTP/3의 QUIC은 UDP 위에서 스트림별로 독립적인 재전송을 처리해 이 문제를 해결했습니다.

TCP 헤더의 핵심 필드

Sequence Number : 보낸 데이터의 순서 번호. 순서 보장과 중복 제거의 기준

Acknowledgement Number : 다음에 받기를 기대하는 순서 번호

Window Size : 수신 측이 받을 수 있는 여유 버퍼 크기. 흐름 제어의 핵심

Flags : SYN, ACK, FIN, RST, PSH, URG

---

6. TCP 3-way handshake와 4-way handshake

3-way handshake (연결 수립)

Client                          Server
  |  --- SYN (seq=x) --------->  |   CLOSED → LISTEN
  |  <-- SYN+ACK (seq=y,ack=x+1) |   SYN_RECEIVED
  |  --- ACK (ack=y+1) ------->  |   ESTABLISHED

SYN : 클라이언트가 연결 요청과 함께 자신의 초기 시퀀스 번호를 보냅니다.

SYN + ACK : 서버가 요청을 수락하고 자신의 초기 시퀀스 번호를 함께 보냅니다.

ACK : 클라이언트가 서버의 시퀀스 번호를 확인했다고 응답합니다.

왜 3번인가가 핵심 질문입니다. 양방향 통신이므로 클라이언트에서 서버로, 서버에서 클라이언트로 두 방향 모두 정상인지 확인해야 합니다. 2번이면 서버는 자기가 보낸 응답이 도착했는지 알 수 없고, 4번은 서버의 ACK와 SYN을 하나로 합칠 수 있어서 불필요합니다.

4-way handshake (연결 종료)

Client                          Server
  |  --- FIN --------------->    |   CLOSE_WAIT
  |  <-- ACK ---------------     |
  |  <-- FIN ---------------     |   LAST_ACK
  |  --- ACK --------------->    |   TIME_WAIT → CLOSED

1. 클라이언트가 FIN을 보내 더 보낼 데이터가 없음을 알립니다.
2. 서버는 일단 ACK만 보냅니다.
3. 서버가 남은 데이터를 모두 보낸 뒤 FIN을 보냅니다.
4. 클라이언트가 ACK를 보내고 TIME_WAIT 상태로 들어갑니다.

왜 종료는 4번인가: 연결은 양방향이고, 한쪽이 끝났다고 반대 방향까지 끝난 것은 아니기 때문입니다. 서버는 FIN을 받아도 아직 보낼 데이터가 남아 있을 수 있어서 ACK와 FIN을 한 번에 합칠 수 없습니다. 이 구간을 Half-Close라고 합니다.

TIME_WAIT이 필요한 이유

마지막 ACK가 유실되면 서버가 FIN을 재전송하는데, 클라이언트가 즉시 소켓을 닫아버리면 이 FIN에 응답할 주체가 사라집니다. 또 같은 포트를 바로 재사용했을 때 이전 연결의 지연된 패킷이 새 연결로 섞여 들어오는 것도 막아야 합니다. 그래서 MSL의 2배 동안 기다립니다.

실무에서는 트래픽이 많은 서버에서 TIME_WAIT 소켓이 수만 개씩 쌓여 포트가 고갈되는 문제가 생깁니다. Keep-Alive로 연결을 재사용하거나 커널 파라미터를 조정해 대응합니다.

☕ 실무와의 연결

TCP 소켓으로 데이터를 계속 흘려보내는 프로그램을 만들 때는, 상대가 죽었는데도 소켓이 열려 있는 것처럼 보이는 상황이 문제가 됩니다. TCP는 데이터를 보내기 전까지 상대의 죽음을 알 수 없기 때문입니다. 그래서 애플리케이션 레벨의 하트비트를 주기적으로 주고받거나 SO_KEEPALIVE를 켜서 죽은 연결을 감지하고, 끊기면 재연결하는 로직을 반드시 넣어야 합니다.

---

7. 흐름 제어와 혼잡 제어

둘 다 "보내는 속도를 조절한다"는 점은 같지만 누구를 배려하는가가 다릅니다.

구분	흐름 제어	혼잡 제어
목적	수신 측 버퍼 오버플로 방지	네트워크 과부하 방지
대상	송신자와 수신자 (1:1)	네트워크 전체
기준	수신 윈도우(rwnd)	혼잡 윈도우(cwnd)

실제 전송량은 두 값 중 작은 쪽으로 결정됩니다.

흐름 제어 기법

Stop and Wait : 하나 보내고 ACK를 받아야 다음을 보냅니다. 단순하지만 매우 비효율적입니다.

Sliding Window : 수신 측이 알려준 윈도우 크기만큼은 ACK 없이 연속으로 보냅니다. ACK가 오면 윈도우가 앞으로 밀리면서 새 데이터를 보낼 공간이 생깁니다. TCP가 실제로 쓰는 방식입니다.

혼잡 제어 기법

AIMD (Additive Increase Multiplicative Decrease) : 문제없으면 윈도우를 1씩 더하고, 혼잡이 감지되면 절반으로 줄입니다. 공평하지만 초기 속도가 느립니다.

Slow Start : 윈도우를 1부터 시작해 ACK를 받을 때마다 2배씩 지수적으로 늘립니다. 이름은 느리게 시작한다는 뜻이지만 증가 속도 자체는 지수적입니다. 임계값(ssthresh)에 도달하면 선형 증가로 전환합니다.

Fast Retransmit : 중복 ACK가 3번 오면 타임아웃을 기다리지 않고 즉시 재전송합니다.

Fast Recovery : 혼잡 발생 시 윈도우를 1이 아니라 절반으로만 줄이고 선형 증가를 이어갑니다.

혼잡을 감지하는 두 가지 신호를 구분해서 답하면 좋습니다. 타임아웃은 상황이 심각하다고 보고 윈도우를 1로 되돌리며, 중복 ACK 3번은 그래도 패킷이 흐르고 있다는 뜻이므로 절반으로만 줄입니다.

---

8. 응용 계층 (HTTP, HTTPS)

HTTP의 특징

비연결성(Connectionless) : 요청과 응답을 주고받으면 연결을 끊습니다. 서버 자원을 아낄 수 있습니다.

무상태(Stateless) : 서버가 클라이언트의 이전 상태를 기억하지 않습니다. 덕분에 서버를 자유롭게 확장(Scale-out)할 수 있지만, 로그인 상태 유지를 위해 쿠키, 세션, 토큰이 필요해집니다.

무상태가 곧 확장성의 전제라는 점이 백엔드 면접의 핵심 포인트입니다. 서버가 상태를 들고 있으면 로드 밸런서가 같은 서버로만 요청을 보내야 하고(Sticky Session), 그 서버가 죽으면 세션이 통째로 날아갑니다. 그래서 세션을 Redis 같은 외부 저장소로 빼거나 JWT처럼 상태를 클라이언트가 들고 있게 만듭니다.

HTTP 메서드와 상태 코드

메서드	용도	멱등성	안전성
GET	조회	O	O
POST	생성, 처리	X	X
PUT	전체 수정, 대체	O	X
PATCH	부분 수정	X	X
DELETE	삭제	O	X

코드	의미
2xx	성공 (200 OK, 201 Created, 204 No Content)
3xx	리다이렉션 (301 영구, 302 임시, 304 Not Modified)
4xx	클라이언트 오류 (400, 401 인증 필요, 403 권한 없음, 404, 429)
5xx	서버 오류 (500, 502 Bad Gateway, 503 Service Unavailable, 504 Timeout)

401과 403의 차이는 단골입니다. 401은 네가 누군지 모르겠다(인증), 403은 누군지는 알지만 권한이 없다(인가) 입니다.

HTTP 버전별 차이

버전	핵심
HTTP/1.0	요청마다 연결을 새로 맺음
HTTP/1.1	Keep-Alive로 연결 재사용, 파이프라이닝. 다만 응답은 순서대로 와야 해서 HOL 블로킹 존재
HTTP/2	바이너리 프레이밍, 멀티플렉싱, 헤더 압축(HPACK), 서버 푸시. TCP 레벨 HOL 블로킹은 남음
HTTP/3	UDP 기반 QUIC 사용. TCP HOL 블로킹 해결, 연결 수립 지연 감소

HTTPS

HTTP에 SSL/TLS 암호화를 더한 것입니다. 기본 포트는 HTTP 80, HTTPS 443입니다.

HTTPS가 보장하는 것은 세 가지입니다.

1. 기밀성 : 중간에서 훔쳐봐도 내용을 알 수 없습니다.

2. 무결성 : 중간에서 변조하면 감지할 수 있습니다.

3. 인증 : 접속한 서버가 진짜 그 서버인지 인증서로 확인합니다.

---

9. 대칭키, 공개키와 TLS handshake

대칭키 암호화

암호화와 복호화에 같은 키를 사용합니다. 연산이 빠르고 대용량 데이터에 적합하지만, 키를 상대에게 전달하는 과정 자체가 위험하다는 근본적인 문제(키 배송 문제)가 있습니다. AES가 대표적입니다.

공개키(비대칭키) 암호화

공개키와 개인키 한 쌍을 사용합니다. 공개키로 암호화한 것은 개인키로만 풀 수 있습니다. 키 배송 문제가 없지만 연산이 무겁습니다. RSA가 대표적입니다.

구분	대칭키	공개키
키	하나 (양쪽 공유)	공개키 + 개인키
속도	빠름	느림
문제	키 배송	연산 비용
용도	실제 데이터 암호화	키 교환, 전자 서명

HTTPS가 둘을 섞어 쓰는 이유가 정확히 이 표에서 나옵니다. 공개키로는 대칭키를 안전하게 주고받는 것까지만 하고, 실제 데이터는 빠른 대칭키로 암호화합니다. 이 방식을 하이브리드 암호화라고 합니다.

인증서와 CA

서버가 보내준 공개키가 진짜 그 서버의 것인지 어떻게 믿을까요. 여기서 CA(Certificate Authority)가 등장합니다. CA는 서버의 공개키와 도메인 정보를 담은 인증서에 CA의 개인키로 서명합니다. 브라우저는 이미 신뢰하는 CA들의 공개키를 내장하고 있어서, 그 공개키로 서명을 검증하면 인증서가 위조되지 않았음을 확인할 수 있습니다.

TLS handshake 흐름

Client                                 Server
  |  Client Hello (지원 암호 스위트, 랜덤값)  →  |
  |  ←  Server Hello (선택된 스위트, 랜덤값)     |
  |  ←  Certificate (인증서 = 서버 공개키)      |
  |  인증서 검증 (CA 공개키로 서명 확인)          |
  |  Pre-Master Secret을 서버 공개키로 암호화 →  |
  |                    서버가 개인키로 복호화     |
  |  양쪽이 동일한 세션키(대칭키) 생성            |
  |  ←  Finished  /  Finished  →                |
  |  이후 대칭키로 암호화된 통신                  |

정리하면 협상 → 인증서 검증 → 키 교환 → 세션키 생성 → 대칭키 통신 순서입니다.

주의할 점은 TCP 3-way handshake가 끝난 뒤에 TLS handshake가 시작된다는 것입니다. 그래서 HTTPS는 첫 연결 지연이 HTTP보다 큽니다. TLS 1.3은 왕복 횟수를 1-RTT로 줄이고 세션 재개 시 0-RTT까지 지원해 이 문제를 개선했습니다.

---

10. 브라우저에 naver.com을 치면 일어나는 일

면접에서 가장 많이 나오는 질문이자, 네트워크 전체를 꿰는 질문입니다.

1) URL 파싱

브라우저가 입력값을 URL로 해석해 프로토콜, 도메인, 경로를 분리합니다.

2) DNS 조회

도메인 네임은 사람이 외우기 쉽도록 IP 주소를 문자로 표현한 주소입니다. 컴퓨터가 이해할 수 있는 IP로 바꿔야 하고, 그 매핑을 관리하는 것이 DNS입니다.

조회 순서는 캐시부터입니다. 브라우저 캐시 → OS 캐시 → hosts 파일 → 로컬 DNS 서버 순으로 찾고, 없으면 계층적으로 질의합니다.

로컬 DNS 서버 → Root 네임서버      : ".com 네임서버 주소는 여기"
             → .com 네임서버       : "naver.com 네임서버 주소는 여기"
             → naver.com 네임서버  : "www.naver.com의 IP는 이것"

이렇게 여러 번 오가는 이유는 도메인이 계층 구조이고 DNS 서버도 그에 맞춰 계층화되어 있기 때문입니다. 최상위를 담당하는 Root 네임서버는 전 세계에 13개 그룹뿐입니다.

DNS는 기본적으로 UDP 53번 포트를 사용합니다. 응답이 512바이트를 넘거나 영역 전송(Zone Transfer)을 할 때는 TCP를 씁니다.

3) ARP로 다음 홉 MAC 주소 확인

목적지 IP를 알아도 실제로 프레임을 내보내려면 다음 홉(보통 게이트웨이)의 MAC 주소가 필요합니다. ARP로 알아냅니다.

4) TCP 3-way handshake

443 포트로 소켓을 열고 연결을 수립합니다.

5) TLS handshake

HTTPS라면 인증서를 검증하고 세션키를 만듭니다.

6) HTTP 요청과 응답

HTTP 요청 메시지가 TCP 세그먼트, IP 패킷, 이더넷 프레임으로 캡슐화되어 전송됩니다. 중간에 로드 밸런서가 요청을 실제 웹 서버로 분배하고, WAS가 처리한 결과가 응답 메시지로 돌아옵니다.

7) 렌더링

브라우저가 HTML을 파싱해 DOM을 만들고, CSS로 CSSOM을 만들어 렌더 트리를 구성한 뒤 화면에 그립니다. 중간에 이미지나 JS 같은 정적 리소스를 위한 추가 요청이 발생하며, 이 부분은 보통 CDN이 응답합니다.

이 흐름을 답할 때는 각 단계에서 어떤 프로토콜과 어떤 계층이 동작하는지를 붙여서 말하면 훨씬 좋은 인상을 줍니다.

---

11. 로드 밸런싱과 서버 확장

서버를 확장하는 두 가지 방법

Scale-up : 서버 자체 사양을 높입니다. CPU, RAM 업그레이드. 단순하지만 물리적 한계와 단일 장애점 문제가 있습니다.

Scale-out : 서버 대수를 늘립니다. 무한히 확장 가능하지만 분산 처리와 세션 관리가 필요합니다.

로드 밸런서

클라이언트와 서버 사이에 위치해 트래픽을 여러 서버로 분산시키는 하드웨어 또는 소프트웨어입니다.

구분	L4 로드 밸런서	L7 로드 밸런서
기준	IP, 포트 (전송 계층)	URL, HTTP 헤더, 쿠키 (응용 계층)
속도	빠름	상대적으로 느림
기능	단순 분산	경로별 라우팅, 캐싱, 압축, SSL 종료

분산 알고리즘

정적 알고리즘 (서버 상태와 무관)

라운드 로빈 : 순서대로 A, B, C, A, B, C. 구현이 쉽고 고르게 분산되지만 서버 성능이 다르면 비효율적입니다.

가중치 라운드 로빈 : 서버 성능에 비례해 더 많은 요청을 배분합니다.

IP 해시 : 클라이언트 IP의 해시값으로 서버를 결정합니다. 같은 클라이언트가 항상 같은 서버로 가서 세션 유지에 유리하지만, 부하가 균등하지 않을 수 있습니다.

동적 알고리즘 (서버 상태를 검사)

최소 연결 : 활성 연결이 가장 적은 서버로 보냅니다.

가중치 최소 연결 : 여기에 서버 성능 가중치를 더합니다.

최소 응답 시간 : 응답이 가장 빠른 서버로 보냅니다.

리소스 기반 : 서버의 실제 리소스 사용량을 보고 가장 여유 있는 곳으로 보냅니다.

API Gateway와 로드 밸런서

API Gateway는 요청 자체에 관심을 둡니다. 요청 형식이 올바른지, 어느 마이크로서비스로 라우팅할지, 인증과 규정 준수는 되었는지를 처리합니다.

로드 밸런서는 네트워크 트래픽에 관심을 둡니다. 요청을 처리할 여유가 있는 서버가 어디인지, 과부하는 없는지를 봅니다.

둘은 함께 씁니다. API Gateway가 요청을 관리하고 적절한 서비스로 라우팅하며, 로드 밸런서가 그 서비스의 인스턴스들로 트래픽을 분산합니다. Amazon API Gateway, Kong, Zuul과 AWS ELB, Nginx가 대표 조합입니다.

헬스 체크

로드 밸런서는 주기적으로 각 서버에 헬스 체크 요청을 보내 죽은 서버를 대상에서 제외합니다. 스프링에서 Actuator의 /health 엔드포인트를 열어두는 이유가 여기에 있습니다. 이때 DB 연결까지 확인하는 헬스 체크를 쓰면, DB 장애 시 모든 인스턴스가 동시에 제외되어 서비스가 완전히 죽을 수 있으므로 주의해야 합니다.

---

12. Blocking, Non-blocking과 Synchronous, Asynchronous

가장 헷갈리는 주제이고, 그래서 면접에서 자주 나옵니다. 두 개념은 관점이 다른 축입니다.

Blocking, Non-blocking : 제어권을 넘기고 기다리는가. 호출한 함수가 바로 리턴하는가의 문제

Synchronous, Asynchronous : 작업의 완료를 누가 신경 쓰는가. 결과와 순서에 관심이 있는가의 문제

조합	설명	예시
Sync + Blocking	호출하고 멈춰 서서 결과가 올 때까지 기다림	전통적인 소켓 read(), JDBC
Sync + Non-blocking	바로 리턴받지만 완료됐는지 계속 물어봄 (폴링)	논블로킹 소켓 반복 확인
Async + Blocking	결과는 콜백으로 받지만 호출부는 대기	드문 조합
Async + Non-blocking	바로 리턴하고 완료되면 콜백, 이벤트로 통지	Node.js, WebFlux, CompletableFuture

I/O 멀티플렉싱

Non-blocking에서 소켓 하나하나를 계속 확인하면 CPU가 낭비됩니다. 그래서 여러 소켓을 한 번에 감시하다가 준비된 것만 알려주는 방식이 나왔습니다.

select, poll : 감시할 fd 목록을 매번 커널에 전달하고, 이벤트가 오면 전체를 순회하며 확인합니다. O(n)입니다.

epoll (리눅스), kqueue (BSD) : 감시 대상을 커널에 등록해두고 이벤트가 발생한 fd만 돌려받습니다. O(1)에 가깝습니다.

Nginx가 적은 프로세스로 수만 연결을 감당하는 이유, 자바 NIO의 Selector와 Netty의 EventLoop가 동작하는 원리가 모두 이것입니다.

☕ 자바, 스프링과의 연결

스프링 MVC는 요청 하나당 스레드 하나를 잡고 I/O가 끝날 때까지 대기하는 Sync-Blocking 모델입니다. 톰캣 기본 최대 스레드가 200개이므로, 외부 API 응답이 3초 걸린다면 201번째 요청부터는 큐에서 대기합니다.

WebFlux는 Async-Non-Blocking 모델이라 적은 스레드로 많은 요청을 처리할 수 있습니다. 다만 중간에 JDBC 같은 블로킹 라이브러리가 하나라도 끼면 이벤트 루프 스레드가 막혀서 전체 처리량이 오히려 MVC보다 나빠집니다. 전 구간이 논블로킹일 때만 의미가 있다는 것이 핵심입니다.

---

13. 면접 예상 질문 40선

계층 구조와 기본 개념

Q1. OSI 7계층을 나누는 이유는 무엇인가요?

표준화를 통해 서로 다른 제조사의 장비와 프로토콜이 호환되게 하기 위해서이고, 통신 과정을 단계로 나누면 문제가 생겼을 때 해당 계층만 확인하고 수정하면 되기 때문입니다. 관심사 분리로 계층 간 독립성을 확보하는 것이 본질입니다.

Q2. OSI 7계층과 TCP/IP 4계층의 차이는?

OSI는 통신 과정을 설명하기 위한 이론적 참조 모델이고, TCP/IP는 실제 인터넷에서 구현되어 동작하는 모델입니다. TCP/IP는 OSI의 응용, 표현, 세션을 애플리케이션 계층 하나로 묶고, 데이터 링크와 물리를 네트워크 액세스 계층으로 묶습니다.

Q3. 각 계층의 데이터 단위를 말해보세요.

응용, 표현, 세션은 메시지, 전송 계층은 세그먼트, 네트워크 계층은 패킷, 데이터 링크 계층은 프레임, 물리 계층은 비트입니다.

Q4. 캡슐화란 무엇인가요?

상위 계층에서 하위 계층으로 데이터가 내려갈 때 각 계층의 헤더를 붙여 나가는 과정입니다. 수신 측은 반대로 헤더를 벗겨내며 올라가는데 이것이 역캡슐화입니다. 이 헤더들이 네트워크 전송 오버헤드의 원인입니다.

Q5. 패킷이란 무엇이고 어떤 구조로 되어 있나요?

네트워크에서 출발지와 목적지 사이를 라우팅되는 데이터의 전송 단위입니다. 출발지와 목적지 정보를 담은 헤더, 실제 데이터인 페이로드, 오류 검출 코드를 담은 트레일러로 구성됩니다.

Q6. MTU와 단편화에 대해 설명해주세요.

MTU는 한 번에 전송 가능한 최대 크기로 이더넷은 보통 1500바이트입니다. 이보다 큰 IP 패킷은 조각으로 나뉘는데, 조각 하나만 유실돼도 전체 재전송이 필요해 비효율적입니다. TCP는 MSS 협상으로 애초에 단편화가 나지 않는 크기로 보냅니다.

물리, 데이터 링크, 네트워크 계층

Q7. IP 주소와 MAC 주소가 둘 다 필요한 이유는?

IP는 네트워크 간 경로를 찾기 위한 논리 주소이고, MAC은 같은 네트워크 안에서 실제 장비를 특정하는 물리 주소입니다. 목적지 IP는 끝까지 변하지 않지만 목적지 MAC은 홉을 지날 때마다 다음 장비의 것으로 바뀝니다.

Q8. ARP는 무엇인가요?

IP 주소로 MAC 주소를 알아내는 프로토콜입니다. 브로드캐스트로 해당 IP의 주인을 묻고, 그 장비가 유니캐스트로 자기 MAC을 응답하며, 결과는 ARP 캐시에 저장됩니다.

Q9. 라우터와 스위치의 차이는?

스위치는 2계층 장비로 MAC 주소를 보고 같은 네트워크 안에서 프레임을 전달하고, 라우터는 3계층 장비로 IP 주소를 보고 서로 다른 네트워크 사이의 경로를 결정합니다.

Q10. 공인 IP와 사설 IP의 차이는?

공인 IP는 ISP가 부여하는 전 세계에서 유일한 주소이고, 사설 IP는 내부망에서만 유효한 주소입니다. IPv4 고갈에 대응하기 위한 방식이며, 외부와 통신할 때 NAT가 두 주소를 변환합니다.

Q11. DHCP는 무엇인가요?

호스트에 IP 주소와 TCP/IP 기본 설정을 자동으로 할당해주는 프로토콜입니다. 클라이언트는 자신의 IP, 게이트웨이 주소, DNS 서버 주소를 받습니다.

Q12. 서브넷 마스크는 왜 필요한가요?

IP 주소에서 네트워크 부분과 호스트 부분을 구분하기 위해서입니다. 이 구분이 있어야 목적지가 같은 네트워크 안에 있는지, 게이트웨이로 보내야 하는지 판단할 수 있습니다.

TCP와 UDP

Q13. TCP와 UDP의 차이를 설명해주세요.

TCP는 연결 지향이고 handshake로 연결을 맺은 뒤 순서 보장, 재전송, 흐름 제어, 혼잡 제어를 통해 신뢰성을 보장합니다. UDP는 비연결형으로 이런 기능이 없어 신뢰성은 낮지만 헤더가 작고 지연이 적습니다. 신뢰성이 필요하면 TCP, 실시간성이 중요하면 UDP를 씁니다.

Q14. 신뢰성이 없는 UDP를 왜 쓰나요?

실시간 스트리밍이나 게임에서는 지난 데이터를 재전송받는 것이 의미가 없고 오히려 지연만 늘립니다. DNS처럼 데이터가 작은 경우에는 연결 수립 비용이 질의 자체보다 커서 UDP가 효율적입니다.

Q15. TCP 3-way handshake를 설명해주세요.

클라이언트가 SYN으로 연결을 요청하고, 서버가 SYN+ACK로 수락과 자신의 요청을 함께 보내고, 클라이언트가 ACK로 확인하면 연결이 수립됩니다. 각자 초기 시퀀스 번호를 교환하는 과정이기도 합니다.

Q16. 왜 3-way인가요? 2번이나 4번이면 안 되나요?

양방향 통신이므로 양쪽 방향이 모두 정상인지 확인해야 합니다. 2번이면 서버는 자신의 SYN이 클라이언트에 도달했는지 확인할 수 없습니다. 4번은 서버의 ACK와 SYN을 하나로 합칠 수 있으므로 불필요합니다.

Q17. 4-way handshake를 설명하고, 왜 4번인지 말해주세요.

클라이언트 FIN, 서버 ACK, 서버 FIN, 클라이언트 ACK 순서입니다. 서버는 FIN을 받아도 아직 전송할 데이터가 남아 있을 수 있어 ACK와 FIN을 동시에 보낼 수 없기 때문에 4단계가 됩니다. 이 구간을 Half-Close라고 합니다.

Q18. TIME_WAIT은 왜 필요한가요?

마지막 ACK가 유실되면 서버가 FIN을 재전송하는데 이에 응답할 주체가 필요하고, 이전 연결의 지연 패킷이 같은 포트를 쓰는 새 연결로 섞이는 것도 막아야 하기 때문입니다. 트래픽이 많으면 TIME_WAIT 소켓이 쌓여 포트가 고갈될 수 있어 Keep-Alive로 연결을 재사용합니다.

Q19. SYN Flooding 공격은 무엇인가요?

SYN만 계속 보내고 ACK를 보내지 않아 서버의 백로그 큐를 SYN_RECEIVED 상태로 가득 채우는 공격입니다. 정상 요청이 연결을 맺지 못하게 됩니다. SYN Cookie나 백로그 큐 크기 조정으로 대응합니다.

Q20. TCP는 데이터 경계를 보장하나요?

보장하지 않습니다. TCP는 바이트 스트림이라 send를 두 번 해도 한 번에 뭉쳐서 도착할 수 있습니다. 그래서 애플리케이션 프로토콜에서 길이 필드를 헤더에 두거나 구분자를 정해서 직접 메시지 경계를 나눠야 합니다. UDP는 데이터그램 단위라 경계가 유지됩니다.

흐름 제어와 혼잡 제어

Q21. 흐름 제어와 혼잡 제어의 차이는?

흐름 제어는 수신자의 버퍼가 넘치지 않도록 송신 속도를 조절하는 1대1 문제이고, 혼잡 제어는 네트워크 전체가 과부하되지 않도록 조절하는 문제입니다. 실제 전송량은 수신 윈도우와 혼잡 윈도우 중 작은 값으로 결정됩니다.

Q22. Sliding Window를 설명해주세요.

수신 측이 알려준 윈도우 크기만큼은 ACK를 기다리지 않고 연속으로 전송하는 방식입니다. ACK를 받으면 윈도우가 앞으로 이동하며 새로 보낼 공간이 생깁니다. Stop and Wait의 비효율을 해결한 방식입니다.

Q23. Slow Start는 왜 느리게 시작한다고 하나요?

윈도우 크기를 1부터 시작하기 때문입니다. 다만 증가 자체는 ACK를 받을 때마다 2배씩 지수적으로 이루어지며, 임계값에 도달하면 선형 증가로 전환합니다.

Q24. 혼잡을 감지하는 방법과 그에 따른 대응 차이는?

타임아웃과 중복 ACK 3회 수신 두 가지입니다. 타임아웃은 상황이 심각하다고 보고 윈도우를 1로 되돌리고, 중복 ACK는 그래도 패킷이 흐르고 있다는 뜻이므로 절반으로만 줄이고 선형 증가를 이어갑니다.

HTTP와 HTTPS

Q25. HTTP가 무상태(Stateless)인 이유와 그 장단점은?

서버가 클라이언트 상태를 기억하지 않아 어떤 서버가 요청을 받아도 동일하게 처리할 수 있고, 덕분에 수평 확장이 자유롭습니다. 대신 로그인 상태 같은 것을 유지하려면 쿠키, 세션, 토큰이 필요합니다.

Q26. 쿠키와 세션의 차이는?

쿠키는 클라이언트에 저장되고 세션은 서버에 저장됩니다. 쿠키는 탈취와 변조에 취약하고, 세션은 안전하지만 서버 메모리를 사용하고 서버가 여러 대일 때 공유 문제가 생깁니다. 그래서 실무에서는 Redis에 세션을 두거나 JWT를 사용합니다.

Q27. GET과 POST의 차이는?

GET은 조회 목적으로 파라미터가 URL에 노출되고 캐싱되며 멱등합니다. POST는 생성이나 처리 목적으로 본문에 데이터를 담고 멱등하지 않습니다. 보안 때문에 POST를 쓴다는 답은 정확하지 않습니다. 암호화되지 않으면 본문도 그대로 보입니다.

Q28. 멱등성이란 무엇인가요?

같은 요청을 여러 번 보내도 서버 상태가 동일하게 유지되는 성질입니다. GET, PUT, DELETE는 멱등하고 POST와 PATCH는 그렇지 않습니다. 네트워크 오류로 재시도가 발생할 수 있기 때문에 API 설계에서 중요한 개념입니다.

Q29. 401과 403의 차이는?

401은 인증되지 않아 누구인지 알 수 없는 상태이고, 403은 인증은 되었지만 해당 리소스에 대한 권한이 없는 상태입니다.

Q30. 502와 504의 차이는?

502 Bad Gateway는 게이트웨이가 뒷단 서버로부터 잘못된 응답을 받은 경우이고, 504 Gateway Timeout은 뒷단 서버가 시간 안에 응답하지 않은 경우입니다. 502는 서버가 죽었거나 응답이 깨진 상황, 504는 살아 있지만 느린 상황으로 원인 추적 방향이 다릅니다.

Q31. HTTP/1.1, HTTP/2, HTTP/3의 차이는?

1.1은 Keep-Alive로 연결을 재사용하지만 응답 순서 때문에 HOL 블로킹이 있습니다. 2는 멀티플렉싱과 헤더 압축으로 이를 개선했지만 TCP 레벨 HOL 블로킹은 남습니다. 3은 UDP 기반 QUIC을 사용해 스트림별로 독립 재전송하며 이 문제를 해결했습니다.

Q32. HTTP와 HTTPS의 차이는?

HTTPS는 HTTP에 TLS 암호화를 더한 것으로 기밀성, 무결성, 서버 인증을 제공합니다. 기본 포트는 80과 443이며, HTTPS는 handshake 때문에 첫 연결 지연이 조금 더 큽니다.

보안

Q33. 대칭키와 공개키의 차이는?

대칭키는 암복호화에 같은 키를 써서 빠르지만 키를 안전하게 전달하기 어렵습니다. 공개키는 키 쌍을 사용해 배송 문제가 없지만 연산이 무겁습니다.

Q34. HTTPS는 왜 두 방식을 함께 쓰나요?

공개키 방식으로는 대칭키를 안전하게 교환하는 것까지만 하고, 실제 데이터는 빠른 대칭키로 암호화합니다. 보안성과 성능을 모두 확보하기 위한 하이브리드 방식입니다.

Q35. TLS handshake 과정을 설명해주세요.

Client Hello와 Server Hello로 암호 스위트와 랜덤값을 교환하고, 서버가 인증서를 보내면 클라이언트가 CA 공개키로 서명을 검증합니다. 이후 Pre-Master Secret을 서버 공개키로 암호화해 전달하고, 양쪽이 동일한 세션키를 만든 뒤 대칭키 통신으로 전환합니다.

Q36. 인증서를 왜 CA가 발급하나요?

서버가 보낸 공개키가 진짜 그 서버의 것인지 증명할 제3자가 필요하기 때문입니다. CA가 자신의 개인키로 인증서에 서명하고, 브라우저는 내장된 CA 공개키로 그 서명을 검증합니다. 이 신뢰 사슬이 없으면 중간자 공격을 막을 수 없습니다.

실무와 아키텍처

Q37. 브라우저에 naver.com을 입력하면 무슨 일이 일어나나요?

URL 파싱 후 DNS로 IP를 조회하고, ARP로 게이트웨이 MAC을 확인한 뒤 TCP 3-way handshake로 연결합니다. HTTPS라면 TLS handshake로 세션키를 만들고, HTTP 요청을 보내면 로드 밸런서를 거쳐 서버가 응답합니다. 브라우저는 응답을 파싱해 DOM과 CSSOM을 만들고 렌더링합니다.

Q38. L4와 L7 로드 밸런서의 차이는?

L4는 IP와 포트를 기준으로 분산해 빠르지만 단순합니다. L7은 URL이나 헤더, 쿠키까지 보고 분산해서 경로별 라우팅이나 SSL 종료 같은 세밀한 제어가 가능하지만 상대적으로 부하가 큽니다.

Q39. Blocking과 Synchronous의 차이는?

블로킹은 호출한 쪽이 제어권을 넘기고 기다리는지의 문제이고, 동기는 작업의 완료와 결과 순서에 관심이 있는지의 문제입니다. 관점이 다른 축이라 네 가지 조합이 모두 존재합니다. 스프링 MVC는 Sync-Blocking, WebFlux는 Async-Non-Blocking에 가깝습니다.

Q40. 서비스가 느리다는 제보를 받으면 어디부터 확인하시겠어요?

계층을 나눠서 좁혀 들어갑니다. 먼저 DNS 조회가 느린지, ping으로 3계층 연결과 RTT가 정상인지 확인하고, telnet이나 nc로 해당 포트가 열려 있는지 봅니다. 네트워크가 정상이면 애플리케이션 쪽으로 넘어가 커넥션 풀 고갈, 스레드 풀 대기, 외부 API 지연, 슬로우 쿼리 순으로 확인합니다. 계층 모델의 실질적인 쓸모가 바로 이 원인 격리에 있다고 생각합니다.