📘 혼자 공부하는 네트워크 — 복습 DAY 2
학습 범위: 네트워크 DAY 1 ~ DAY 11
복습 방식: 20문제 풀이 및 해설
학습 내용: HTTP, TCP/UDP, DNS, ARP, 서브넷, Wireshark, 이중화, 로드 밸런싱, 프록시, TLS, BGP
Q1. HTTP의 Stateless와 로그인 상태 유지
문제: HTTP는 Stateless 프로토콜인데, 웹사이트에서 로그인 상태를 계속 유지할 수 있는 이유는 무엇일까?
정답: 쿠키와 세션 ID를 이용하기 때문이다.
해설
HTTP는 기본적으로 각 요청을 독립적으로 처리하며 이전 요청의 상태를 기억하지 않는다.
하지만 서버에 로그인 세션을 생성하고, 브라우저에 세션 ID를 전달하면 로그인 상태를 유지할 수 있다.
동작 과정
- 사용자가 아이디와 비밀번호로 로그인한다.
- 서버가 인증 정보를 확인하고 세션을 생성한다.
- 서버가 세션 ID를 브라우저에 전달한다.
- 브라우저가 세션 ID를 보통 쿠키에 저장한다.
- 이후 요청에서 세션 ID를 서버에 전달한다.
- 서버는 세션 ID를 이용해 저장된 세션 정보를 조회한다.
핵심: HTTP는 Stateless지만, 쿠키와 세션을 활용하면 로그인 상태를 유지할 수 있다.
Q2. TCP 3-Way Handshake
문제: TCP 연결을 설정할 때 메시지를 주고받는 순서는?
정답
클라이언트 서버
| |
| ---------- SYN ------------> |
| |
| <------ SYN + ACK ----------- |
| |
| ---------- ACK ------------> |
| |
TCP 연결 수립 완료해설
- SYN: 클라이언트가 서버에 연결을 요청한다.
- SYN + ACK: 서버가 요청을 확인하고 자신도 연결을 요청한다.
- ACK: 클라이언트가 서버의 응답을 확인한다.
3-Way Handshake를 통해 양쪽은 통신 준비 상태를 확인하고 초기 순서 번호를 교환한다.
참고로 TCP 연결을 정상적으로 종료할 때는 일반적으로 4-Way Handshake를 수행한다.
Q3. Active-Active와 Active-Standby
문제: 주 서버가 서비스를 제공하고 대기 서버가 장애에 대비하는 이중화 방식은?
정답: Active-Standby
| 구분 | Active-Active | Active-Standby |
|---|---|---|
| 평상시 | 두 서버 모두 서비스 제공 | 주 서버가 서비스 제공 |
| 장애 발생 시 | 정상 서버가 서비스 처리 | 대기 서버가 서비스 인계 |
| 특징 | 서버 자원을 함께 활용 | 장애에 대비한 대기 서버 운영 |
Failover(페일오버)는 주 서버에 장애가 발생했을 때 대기 서버가 서비스를 이어받는 과정을 의미한다.
핵심: 이중화가 구성되어 있어도 자동 장애 감지 및 전환 기능이 없다면 서비스 중단이 발생할 수 있다.
Q4. Wireshark 디스플레이 필터
문제: 출발지 IP가 192.168.10.100이고 TCP 목적지 포트가 443인 패킷만 표시하는 필터는?
정답
ip.src == 192.168.10.100 && tcp.dstport == 443| 필터 | 의미 |
|---|---|
ip.src | 출발지 IP |
ip.dst | 목적지 IP |
tcp.srcport | TCP 출발지 포트 |
tcp.dstport | TCP 목적지 포트 |
== | 값이 같음 |
&& | AND 조건 |
| ` |
tcp.dstport 조건은 TCP 프로토콜과 목적지 포트를 함께 지정한다.
핵심: Wireshark의 디스플레이 필터는 src_ip가 아니라 ip.src와 같은 문법을 사용한다.
Q5. HTTP PUT과 PATCH
문제: 기존 프로필에서 나이만 변경하려고 할 때 적합한 HTTP 메서드는?
정답: PATCH
| 구분 | PUT | PATCH |
|---|---|---|
| 주요 용도 | 리소스 전체 대체 | 리소스의 일부 수정 |
| 요청 데이터 | 일반적으로 전체 리소스 | 변경할 항목만 |
| 멱등성 | 보장 | 반드시 보장하지는 않음 |
PATCH 요청 예시
PATCH /users/1 HTTP/1.1
Content-Type: application/json
{
"age": 26
}핵심: PUT은 전체 대체, PATCH는 부분 수정이다.
Q6. TLS와 대칭 키 암호화
문제: TLS에서 실제 애플리케이션 데이터를 주고받을 때 대칭 키 암호화 방식을 사용하는 이유는?
정답: 공개 키 암호화보다 일반적으로 처리 속도가 빠르기 때문이다.
| 구분 | 대칭 키 암호화 | 공개 키 암호화 |
|---|---|---|
| 사용하는 키 | 같은 키 | 공개 키와 개인 키 |
| 처리 속도 | 일반적으로 빠름 | 상대적으로 느림 |
| TLS에서의 역할 | 실제 데이터 암호화 | 인증 및 키 교환 과정 등에 활용 |
TLS는 핸드셰이크 과정에서 세션 키를 안전하게 마련하고, 실제 애플리케이션 데이터는 대칭 키 방식으로 암호화한다.
TLS 1.3에서는 일반적으로 (EC)DHE 키 교환으로 공유 비밀을 만들고 인증서와 전자 서명 등을 통해 서버를 인증한다.
핵심: 공개 키 기술은 인증과 안전한 키 교환을 지원하고, 대칭 키는 효율적인 데이터 암호화에 사용된다.
Q7. ARP와 기본 게이트웨이
문제: 서로 다른 네트워크에 있는 PC B로 패킷을 보내려면 PC A는 누구의 MAC 주소를 알아내야 할까?
정답: 기본 게이트웨이의 MAC 주소
네트워크 구성
PC A
IP: 192.168.1.10
|
| ARP를 통해 게이트웨이 MAC 확인
v
라우터
IP: 192.168.1.1
|
| 라우팅 후 다음 구간으로 전달
v
PC B
IP: 192.168.2.10동작 과정
- PC A는 목적지 IP가 다른 네트워크에 있다는 것을 확인한다.
- ARP를 이용해 기본 게이트웨이의 MAC 주소를 알아낸다.
- 목적지 IP는 PC B의 IP로 유지하고, 목적지 MAC 주소는 기본 게이트웨이의 MAC 주소로 지정한다.
- 라우터는 라우팅 테이블을 확인한 후 패킷을 다음 구간으로 전달한다.
- PC B가 직접 연결된 네트워크에 있다면 라우터는 필요할 때 ARP로 PC B의 MAC 주소를 확인한다.
핵심: IP 주소는 최종 목적지를 나타내고, MAC 주소는 현재 구간에서 프레임을 전달할 대상을 나타낸다.
Q8. L4와 L7 로드 밸런서
문제: /images 요청은 이미지 서버로, /api 요청은 API 서버로 전달하려면 어떤 로드 밸런서를 사용해야 할까?
정답: L7 로드 밸런서
| 계층 | 주요 정보 |
|---|---|
| L2 | MAC 주소 |
| L3 | IP 주소 |
| L4 | IP 주소, TCP/UDP 포트 |
| L7 | HTTP URL, 헤더, 쿠키 등 |
L7 로드 밸런서 구성 예시
클라이언트
|
v
L7 로드 밸런서
|
+---------+---------+
| |
v v
/images /api
| |
v v
이미지 서버 API 서버L4는 주로 IP 주소와 TCP/UDP 포트 등 전송 계층의 정보를 이용해 트래픽을 분산한다.
L7은 HTTP 요청의 URL 경로나 헤더 등 애플리케이션 계층의 정보를 분석해 트래픽을 분산할 수 있다.
핵심: HTTP 요청의 내용에 따라 서버를 선택해야 한다면 L7 로드 밸런서를 활용할 수 있다.
Q9. DNS 조회 과정
문제: DNS 재귀 리졸버가 도메인의 IP 주소를 찾기 위해 조회하는 서버의 순서는?
정답: 루트 네임 서버 → TLD 네임 서버 → 권한 있는 네임 서버
DNS 재귀 리졸버
|
v
루트 네임 서버
|
v
TLD 네임 서버
(.com)
|
v
권한 있는 네임 서버
(example.com)
|
v
DNS 레코드
|
v
IP 주소 확인각 서버의 역할
- 루트 네임 서버: 해당 TLD 네임 서버의 위치를 안내한다.
- TLD 네임 서버: 해당 도메인을 담당하는 권한 있는 네임 서버의 위치를 안내한다.
- 권한 있는 네임 서버: 해당 도메인의 DNS 레코드를 제공한다.
실제 조회에서는 DNS 캐시가 존재하면 일부 단계를 생략할 수 있다.
핵심: 루트 → TLD → 권한 있는 네임 서버 순서로 기억한다.
Q10. TCP와 UDP
문제: 실시간 음성 통화에서 일반적으로 UDP가 활용되는 이유는?
정답: UDP는 별도의 연결 설정 과정이 없고 TCP처럼 기본적으로 재전송이나 순서 보장을 수행하지 않기 때문이다.
| 구분 | TCP | UDP |
|---|---|---|
| 연결 방식 | 연결 지향형 | 비연결형 |
| 연결 설정 | 3-Way Handshake | 별도의 연결 설정 없음 |
| 전달 보장 | 제공 | 기본적으로 제공하지 않음 |
| 순서 보장 | 제공 | 제공하지 않음 |
| 활용 | 웹 통신, 파일 전송 등 | 실시간 음성·영상, DNS 등 |
UDP는 TCP보다 오버헤드가 작고 지연을 줄이는 데 유리하지만 반드시 전송 속도가 더 빠른 것은 아니다.
실제 성능은 네트워크 상태와 애플리케이션 구현에 따라 달라진다.
핵심: TCP는 신뢰성 있는 전송을 제공하고, UDP는 단순한 전송 방식으로 실시간 통신에 유리할 수 있다.
Q11. HTTP 502 Bad Gateway
문제: HTTP 502 Bad Gateway는 어떤 상황에서 발생할까?
정답: 게이트웨이나 프록시 서버가 상위 서버로부터 유효하지 않은 응답을 받았을 때 발생한다.
클라이언트
|
v
리버스 프록시
|
| 상위 서버 응답 문제
v
WAS
=> 클라이언트에 502 응답실무 점검 항목
- WAS 프로세스가 정상적으로 실행 중인지 확인
- 프록시에서 WAS의 IP와 포트로 접속할 수 있는지 확인
- 프록시의 상위 서버 설정 확인
- 프록시 및 WAS 오류 로그 확인
관련 상태 코드
| 상태 코드 | 의미 |
|---|---|
| 200 | OK |
| 401 | Unauthorized |
| 404 | Not Found |
| 502 | Bad Gateway |
| 504 | Gateway Timeout |
502는 유효하지 않은 응답을 받았을 때 발생하며, 504는 제한 시간 내에 상위 서버의 응답을 받지 못했을 때 발생한다.
Q12. HTTP 캐시와 304 Not Modified
문제: 브라우저가 304 Not Modified 응답을 받으면 어떻게 동작할까?
정답: 기존에 저장된 캐시 데이터를 재사용한다.
동작 과정
- 브라우저가 이전에 다운로드한 리소스를 캐시에 저장한다.
- 캐시가 만료되면 서버에 리소스의 변경 여부를 확인한다.
- 변경되지 않았다면 서버가
304 Not Modified를 응답한다. - 브라우저가 기존 캐시 데이터를 재사용한다.
캐시의 장점
- 불필요한 네트워크 트래픽 감소
- 리소스 응답 속도 향상
- 서버의 데이터 전송 부담 감소
캐시가 아직 유효하다면 서버에 재검증 요청을 보내지 않고 바로 사용할 수도 있다.
핵심: 304는 리소스가 변경되지 않았다는 의미이며, 캐시를 재사용할 수 있다.
Q13. 단일 장애점(SPoF)
문제: WEB 서버 두 대를 이중화했지만 로드 밸런서는 한 대만 운영하는 경우, 로드 밸런서에 장애가 발생하면 어떻게 될까?
정답: 서버 두 대가 모두 정상이더라도 클라이언트가 서비스에 접근하지 못할 수 있다.
이처럼 한 구성 요소의 장애가 전체 서비스에 영향을 줄 수 있는 지점을 단일 장애점(SPoF, Single Point of Failure)이라고 한다.
클라이언트
|
v
로드 밸런서
(장애 발생)
X
|
+-------+-------+
| |
v v
WEB 서버 A WEB 서버 B
정상 정상
서버는 정상이지만 요청이 전달되지 않음대응 방안
로드 밸런서도 이중화하고 장애 감지 및 자동 전환 기능을 구성할 수 있다.
핵심: 일부 장비를 이중화했다고 해서 전체 시스템의 단일 장애점이 사라지는 것은 아니다.
Q14. Forward Proxy와 Reverse Proxy
문제: 회사 직원의 인터넷 요청을 대신 외부 서버에 전달하고 접속 기록 및 접근을 관리하는 프록시는?
정답: Forward Proxy
① Forward Proxy
클라이언트를 대신해 외부 서버에 요청을 전달한다.
클라이언트
|
v
Forward Proxy
|
v
외부 웹 서버주요 활용 사례는 인터넷 접근 제어, 접속 기록 관리, 캐싱 등이다.
② Reverse Proxy
외부에서 들어온 요청을 받아 내부 서버에 전달한다.
외부 클라이언트
|
v
Reverse Proxy
|
+---+---+
| |
v v
서버 A 서버 B주요 활용 사례는 내부 서버 보호, 로드 밸런싱, 캐싱 등이다.
핵심
- Forward Proxy: 클라이언트 측에서 클라이언트를 대신한다.
- Reverse Proxy: 서버 측에서 서버를 대신한다.
Q15. CIDR과 서브넷 계산
문제: 192.168.10.130/26의 네트워크 주소, 브로드캐스트 주소, 사용 가능한 호스트 범위는?
정답
| 항목 | 값 |
|---|---|
| IP 주소 | 192.168.10.130/26 |
| 서브넷 마스크 | 255.255.255.192 |
| 네트워크 주소 | 192.168.10.128 |
| 브로드캐스트 주소 | 192.168.10.191 |
| 호스트 범위 | 192.168.10.129 ~ 192.168.10.190 |
| 사용 가능한 호스트 수 | 62개 |
계산 과정
IPv4는 총 32비트이고, /26은 네트워크 비트가 26비트라는 의미다.
호스트 비트 = 32 - 26 = 6비트
전체 IP 주소 수 = 2^6 = 64개
사용 가능한 호스트 수 = 64 - 2 = 62개서브넷 구간
192.168.10.0 ~ 192.168.10.63
192.168.10.64 ~ 192.168.10.127
192.168.10.128 ~ 192.168.10.191 ← 해당 구간
192.168.10.192 ~ 192.168.10.255일반적인 IPv4 서브넷에서는 네트워크 주소와 브로드캐스트 주소를 제외하고 호스트에 IP를 할당한다.
Q16. TCP 흐름 제어와 혼잡 제어
문제: 수신자의 버퍼를 보호하는 제어와 네트워크의 혼잡을 방지하는 제어는 각각 무엇일까?
정답: 흐름 제어와 혼잡 제어
| 구분 | 흐름 제어 | 혼잡 제어 |
|---|---|---|
| 영어 | Flow Control | Congestion Control |
| 목적 | 수신자의 처리 능력 초과 방지 | 네트워크 혼잡 방지 |
| 고려 대상 | 수신자의 버퍼 | 네트워크의 혼잡 상태 |
| 주요 메커니즘 | 수신 윈도우(rwnd) | 혼잡 윈도우(cwnd) |
① 흐름 제어
송신자가 데이터를 너무 빠르게 보내면 수신자의 버퍼가 가득 찰 수 있다.
수신자가 처리할 수 있는 양을 고려해 송신량을 조절하는 것이 흐름 제어다.
② 혼잡 제어
네트워크에 패킷이 지나치게 많이 몰리면 지연과 패킷 손실이 발생할 수 있다.
네트워크의 혼잡 징후를 고려해 송신량을 조절하는 것이 혼잡 제어다.
핵심
- 흐름 제어: 수신자가 감당할 수 있는가?
- 혼잡 제어: 네트워크가 감당할 수 있는가?
Q17. TCP 빠른 재전송
문제: 동일한 ACK 번호를 반복해서 받은 송신자가 재전송 타이머가 만료되기 전에 손실된 것으로 추정하는 세그먼트를 다시 보내는 기법은?
정답: 빠른 재전송(Fast Retransmit)
동작 예시
송신자 수신자
| |
| -------- 데이터 1 ---------> |
| -------- 데이터 2 ---------> |
| -------- 데이터 3 --- X | 손실
| -------- 데이터 4 ---------> |
| -------- 데이터 5 ---------> |
| |
| <------ 중복 ACK ----------- |
| <------ 중복 ACK ----------- |
| <------ 중복 ACK ----------- |
| |
| ---- 데이터 3 재전송 ------> |TCP는 일반적으로 동일한 ACK 번호를 3번 중복해서 받으면 손실 가능성을 판단해 빠른 재전송을 수행한다.
다만 패킷의 도착 순서가 바뀌었을 때도 중복 ACK가 발생할 수 있다.
| 구분 | 빠른 재전송 | 슬로 스타트 |
|---|---|---|
| 영어 | Fast Retransmit | Slow Start |
| 목적 | 손실된 데이터 재전송 | 혼잡 윈도우 증가 |
| 관련 기능 | 손실 복구 | 혼잡 제어 |
핵심: 빠른 재전송은 손실 복구, 슬로 스타트는 혼잡 제어와 관련된 기능이다.
Q18. 디지털 인증서와 CA
문제: CA(Certificate Authority)의 주요 역할은?
정답: 디지털 인증서를 발급하고 전자 서명해 공개 키와 인증서에 기재된 신원 정보를 연결한다.
HTTPS 인증서 검증 과정
웹 서버
|
| 디지털 인증서 전달
v
클라이언트
|
| 유효기간 및 도메인 확인
v
인증서 체인 검증
|
| 신뢰할 수 있는 CA 확인
v
전자 서명 검증
|
v
서버 인증 확인CA는 서버의 신원을 검증할 수 있도록 신뢰 체계를 제공한다.
클라이언트는 인증서의 유효기간과 도메인 일치 여부, 인증서 체인, 전자 서명 등을 확인한다.
CA가 클라이언트와 서버 사이의 모든 HTTPS 데이터를 직접 암호화하는 것은 아니다.
핵심: CA는 디지털 인증서의 신뢰성을 검증할 수 있도록 지원하는 인증 기관이다.
Q19. MTU와 IPv4 단편화
문제: 크기가 2,000바이트인 IPv4 패킷이 MTU 1,500바이트인 구간을 통과해야 할 때, DF 비트가 0이면 어떻게 처리할까?
정답: MTU에 맞게 패킷을 단편화할 수 있다.
MTU(Maximum Transmission Unit)는 네트워크 구간에서 한 번에 전송할 수 있는 패킷의 최대 크기를 의미한다.
단편화 개념도
원본 IPv4 패킷
2,000바이트
|
v
MTU 1,500바이트
|
v
단편화
|
+-----+-----+
| |
v v
단편 1 단편 2
MTU 이하 MTU 이하단편화된 각 패킷에는 별도의 IPv4 헤더가 붙으며, 최종 목적지에서 재조립한다.
DF(Don't Fragment) 비트
| 값 | 의미 |
|---|---|
| DF = 0 | 단편화 허용 |
| DF = 1 | 단편화 금지 |
DF가 1인 패킷이 MTU보다 크면 라우터는 해당 패킷을 단편화하지 못하므로 폐기하고 일반적으로 ICMP Fragmentation Needed 메시지를 보낸다.
DF 비트는 경로 MTU 탐색(Path MTU Discovery)에도 활용된다.
핵심: DF는 Don't Fragment, 즉 단편화하지 말라는 의미다.
Q20. BGP와 AS
문제: AS 65001과 AS 65002처럼 서로 다른 AS 사이에서 라우팅 정보를 교환할 때 사용하는 BGP는?
정답: eBGP(External BGP)
| 구분 | iBGP | eBGP |
|---|---|---|
| 정식 명칭 | Internal BGP | External BGP |
| 통신 대상 | 같은 AS의 BGP 라우터 | 서로 다른 AS의 BGP 라우터 |
| 예시 | AS 65001 ↔ AS 65001 | AS 65001 ↔ AS 65002 |
AS(Autonomous System)는 공통된 라우팅 정책에 따라 관리되는 네트워크의 집합이다.
BGP는 AS 사이에서 라우팅 정보를 교환하는 데 사용하는 프로토콜이며, iBGP와 eBGP라는 동작 방식이 있다.
핵심
- iBGP: 같은 AS 내부
- eBGP: 서로 다른 AS 사이
📌 DAY 2 — 오답 및 헷갈렸던 개념
| 문제 | 개념 | 핵심 복습 |
|---|---|---|
| Q4 | Wireshark | ip.src, tcp.dstport |
| Q5 | HTTP 메서드 | PUT은 전체 대체, PATCH는 부분 수정 |
| Q9 | DNS | 루트 → TLD → 권한 있는 네임 서버 |
| Q10 | TCP/UDP | UDP가 반드시 더 빠른 것은 아님 |
| Q13 | SPoF | 장비 하나의 장애가 전체 서비스에 영향을 줄 수 있음 |
| Q14 | 프록시 | Forward는 클라이언트 측, Reverse는 서버 측 |
| Q16 | TCP 제어 | 흐름 제어는 수신자, 혼잡 제어는 네트워크 |
| Q17 | TCP 재전송 | 중복 ACK와 빠른 재전송 |
🎯 다음 복습 목표 — DAY 3
- Wireshark 디스플레이 필터 직접 작성하기
- PUT과 PATCH의 차이 복습하기
- TCP 흐름 제어와 혼잡 제어 구분하기
- 중복 ACK와 빠른 재전송 이해하기
- Forward Proxy와 Reverse Proxy 구분하기
- 앞서 학습한 내용과 새로운 범위를 섞어 총 20문제 풀이하기
DAY 2 복습 완료! ✅
#네트워크 #혼자공부하는네트워크 #네트워크공부 #TCP #UDP #HTTP #Wireshark #DNS #정보보안 #복습
