📘 혼자 공부하는 네트워크 — 복습 DAY 6

학습 범위: 네트워크 DAY 1 ~ DAY 11
복습 방식: 20문제 풀이 및 해설
학습 내용: TLS, DNS, Wireshark, IPv4 단편화, HTTP 상태 코드, TCP/UDP, DHCP, Load Balancing, 흐름 제어, 혼잡 제어, ARQ, ARP, CIDR, BGP, HTTP Method, SPoF

이번에도 DAY1~DAY11 범위에서 20문제를 풀면서 이전에 헷갈렸던 개념을 다시 확인했다.

특히 이번 DAY에서는 단순 정답뿐 아니라
왜 그렇게 동작하는지를 설명하는 데 집중했다.

---

Q1. TLS 인증서 검증

HTTPS에서 서버 인증서를 검증할 때 클라이언트가 확인하는 내용으로 가장 적절하지 않은 것은?

① 인증서의 유효기간
② 접속한 도메인과 인증서의 도메인 일치 여부
③ 인증서 체인과 신뢰할 수 있는 CA 여부
④ 서버의 MAC 주소가 인증서에 적힌 MAC 주소와 같은지

풀이

정답은 ④번

서버 인증서 검증에서는 다음과 같은 내용을 확인한다.

인증서 유효기간

접속한 도메인과 인증서의 도메인 일치 여부

신뢰할 수 있는 CA인지

인증서 체인

전자 서명

반면 MAC 주소는 같은 로컬 네트워크 구간에서 사용하는 2계층 주소이므로 인증서 검증과는 관계가 없다.

핵심: 인증서는 서버의 신원과 공개키에 대한 신뢰를 확인하는 데 사용된다.

---

Q2. DNS 조회 순서

DNS Resolver에 캐시가 없는 경우 일반적인 조회 순서는?

① Root → TLD → Authoritative
② TLD → Root → Authoritative
③ Authoritative → Root → TLD
④ Root → Authoritative → TLD

풀이

정답은 ① Root → TLD → Authoritative

이전에는 이 순서를 헷갈렸지만 이번에는 정확하게 맞혔다.

Root
↓
TLD
↓
Authoritative

Root Name Server

어떤 TLD 서버로 가야 하는지 알려준다.

예:

.com은 저쪽 TLD Server로 가세요.

TLD Name Server

해당 도메인의 Authoritative Name Server 위치를 알려준다.

예:

example.com 담당 Authoritative Server는 저쪽입니다.

Authoritative Name Server

실제 DNS Record를 제공한다.

---

TLD란?

TLD는

Top-Level Domain

의 약자이다.

예:

.com
.net
.org
.kr

처럼 도메인 구조에서 가장 위쪽에 있는 최상위 도메인을 의미한다.

---

Q3. Wireshark Display Filter

다음 조건의 패킷만 보고 싶다.

목적지 IP
192.168.100.20

TCP 출발지 Port
443

처음 작성한 답:

tcp.port == 443 ip.dst == 192.168.100.20

풀이

정확한 필터는 다음과 같다.

tcp.srcport == 443 && ip.dst == 192.168.100.20

tcp.port == 443도 TCP 443번 Port가 포함된 패킷을 찾는 데 사용할 수 있지만
출발지와 목적지를 구분하지 않는다.

문제에서는 TCP 출발지 Port를 요구했기 때문에

tcp.srcport

를 사용하는 것이 더 정확하다.

자주 사용하는 필터

ip.src
→ 출발지 IP

ip.dst
→ 목적지 IP

tcp.srcport
→ TCP 출발지 Port

tcp.dstport
→ TCP 목적지 Port

조건을 연결할 때는

&&
→ AND

를 사용한다.

---

Q4. IPv4 단편화

다음 중 올바른 설명은?

① Identification은 단편의 원본 내 위치를 나타낸다.
② Fragment Offset은 같은 원본 패킷인지 구분한다.
③ MF = 1이면 뒤에 단편이 더 존재한다.
④ DF = 1이면 단편화를 허용한다.

풀이

정답은 ③번

각 필드의 역할은 다음과 같다.

Identification
→ 같은 원본 패킷에서 나온 단편인지 구분

Fragment Offset
→ 원본 데이터에서 이 단편의 위치 표시

MF
→ More Fragments

DF
→ Don't Fragment

MF

MF = 1
→ 뒤에 단편이 더 있음

MF = 0
→ 뒤에 단편이 없음
→ 마지막 단편

DF

DF = 1
→ 단편화 금지

DF = 0
→ 단편화 허용

이번에는 Identification과 Fragment Offset 역할까지 정확히 구분했다.

---

Q5. HTTP 404와 500

다음 상황에 해당하는 상태 코드는?

클라이언트가 존재하지 않는 URL을 요청했다.

① 200 OK
② 301 Moved Permanently
③ 404 Not Found
④ 500 Internal Server Error

풀이

정답은 ③ 404 Not Found

404는 클라이언트가 요청한 리소스를 서버가 찾지 못했을 때 발생한다.

404 Not Found
→ 요청한 리소스를 찾을 수 없음
→ 4xx Client Error

반면

500 Internal Server Error
→ 서버 내부 처리 오류
→ 5xx Server Error

이다.

기억

4xx
→ Client Error

5xx
→ Server Error

---

Q6. TCP와 UDP

다음 중 TCP의 특징으로 올바르지 않은 것은?

① 연결 지향형
② 순서 보장
③ 재전송을 통해 신뢰성 제공
④ 3-Way Handshake 없이 바로 데이터 전송

풀이

정답은 ④번

④번은 UDP 쪽 특징이다.

TCP

연결 지향형

3-Way Handshake

순서 보장

재전송

흐름 제어

혼잡 제어

UDP

비연결형

3-Way Handshake 없음

순서 보장 없음

기본 재전송 없음

핵심: TCP는 연결을 맺고 전송하지만 UDP는 연결 설정 없이 바로 보낼 수 있다.

---

Q7. DNS Cache

DNS Resolver에 example.com 정보가 이미 저장되어 있고 TTL도 아직 유효하다면 어떻게 동작할까?

① Root부터 다시 조회
② TLD부터 다시 조회
③ Cache 정보 사용
④ DHCP Server에 조회

풀이

정답은 ③ Cache 정보 사용

이미 유효한 정보가 Cache에 있다면 굳이 다시

Root
↓
TLD
↓
Authoritative

과정을 반복할 필요가 없다.

Cache를 사용하면

• 불필요한 DNS Query 감소
• Network Traffic 감소
• 응답 속도 향상
• DNS Server 부하 감소

등의 장점이 있다.

---

Q8. DHCP DORA

DHCP의 올바른 순서는?

① Discover → Request → Offer → ACK
② Discover → Offer → Request → ACK
③ Offer → Discover → Request → ACK
④ Request → Offer → Discover → ACK

풀이

정답은 ②번

Discover
→ Offer
→ Request
→ ACK

즉,

DORA

로 기억할 수 있다.

이번에는 순서는 맞았지만 Discover 의미를 조금 잘못 이해했다.

처음에는

Discover
→ 남는 IP를 발견

정도로 생각했다.

하지만 정확히는

Discover
→ Client가 DHCP Server를 찾는 과정

이다.

각 단계 의미

Discover
→ "DHCP Server 있나요?"

Offer
→ "이 IP 사용해볼래?"

Request
→ "그 IP를 사용하겠습니다."

ACK
→ "좋아. 사용해."

---

Q9. Load Balancing Algorithm

다음과 같은 Server가 있다.

Server A : 80 Connections
Server B : 15 Connections
Server C : 47 Connections

현재 연결 수가 가장 적은 Server로 새 연결을 보내는 방식은?

① Round Robin
② Least Connection
③ Active-Standby
④ Failover

풀이

정답은 ② Least Connection

Least Connection은 새로운 요청이 들어올 때마다
현재 연결 수가 가장 적은 Server를 선택한다.

따라서

Server B
15 Connections

가 선택된다.

Round Robin

A
↓
B
↓
C
↓
A

처럼 순서대로 분배한다.

차이

Round Robin
→ 순서 기준

Least Connection
→ 현재 연결 수 기준

---

Q10. 흐름 제어와 혼잡 제어

상황 A

송신자가 너무 빠르게 데이터를 보내
수신자의 Buffer가 감당하지 못한다.

상황 B

수신자는 충분히 받을 수 있지만
중간 Network가 혼잡하여 Packet Loss가 발생한다.

풀이

A
→ 흐름 제어

B
→ 혼잡 제어

처음에는

흐름 제어
→ 수신자 문제

혼잡 제어
→ 송신자 문제

라고 생각했다.

흐름 제어 부분은 맞지만
혼잡 제어는 송신자 자체의 문제가 아니다.

정확하게는

흐름 제어
→ 수신자가 감당 가능한가?

혼잡 제어
→ 네트워크가 감당 가능한가?

로 이해하면 된다.

흐름 제어

수신자의 처리 능력과 Buffer 상태에 맞춰 송신 속도를 조절한다.

혼잡 제어

Network 내부의 트래픽이 너무 많아지는 것을 방지하기 위해 송신량을 조절한다.

---

Q11. Go-Back-N

다음 설명에 해당하는 방식은?

여러 Segment 중 하나가 손실되었을 때
손실된 Segment부터 이후 데이터를 다시 전송한다.

풀이

정답은 Go-Back-N

예를 들어

1 2 3 4 5
    ↑
    3 손실

이라면

3 4 5

를 다시 전송한다.

Selective Repeat와 비교

Go-Back-N
→ 손실된 지점부터 이후 전부 재전송

Selective Repeat
→ 손실된 데이터만 선택적으로 재전송

---

Q12. 같은 네트워크에서 ARP

다음 장치가 있다.

PC A
192.168.1.10/24

PC B
192.168.1.50/24

PC A의 ARP Cache에 PC B의 MAC 주소가 없다.

PC A는 어떻게 할까?

처음 답은

Default Gateway의 MAC 주소를 ARP로 찾는다.

였다.

풀이

정답은 목적지 PC의 MAC 주소를 직접 ARP로 찾는다.

두 장치는 같은

192.168.1.0/24

Network에 있다.

따라서 Default Gateway를 거칠 필요가 없다.

ARP Cache 확인
↓
목적지 MAC 정보 없음
↓
ARP Request Broadcast
↓
192.168.1.50의 MAC 주소 확인

핵심

같은 Network
→ 목적지 Host의 MAC 주소

다른 Network
→ Default Gateway의 MAC 주소

ARP를 사용한다고 무조건 Gateway의 MAC 주소를 찾는 것은 아니다.

---

Q13. 다른 네트워크에서 ARP

이번에는 다음과 같다.

PC A
192.168.1.10/24

PC B
192.168.2.20/24

PC A가 PC B에게 데이터를 보낼 때 ARP를 통해 알아내는 MAC 주소는?

풀이

정답은 Default Gateway의 MAC 주소

두 장치는 서로 다른 Network이다.

따라서

PC A
↓
Default Gateway MAC 확인
↓
Gateway로 Frame 전달
↓
Router가 Routing
↓
PC B 방향으로 전달

하게 된다.

여기서 중요한 점은

IP 주소
→ 최종 목적지 기준

MAC 주소
→ 현재 구간의 다음 전달 대상 기준

이라는 것이다.

---

Q14. CIDR 계산

다음 주소의 정보를 구하자.

10.0.0.70/26

풀이

IPv4는 32bit이므로

32 - 26
= 6bit

Host Bit는 6bit이다.

2^6
= 64

따라서 주소 범위는 64개 단위로 나뉜다.

0 ~ 63

64 ~ 127

128 ~ 191

192 ~ 255

70은

64 ~ 127

범위에 포함된다.

따라서

Network Address
→ 10.0.0.64

Broadcast Address
→ 10.0.0.127

Host Range
→ 10.0.0.65 ~ 10.0.0.126

사용 가능한 Host 수
→ 62개

이다.

이번 문제는 계산 과정까지 정확하게 풀었다.

---

Q15. BGP와 IGP

다음 중 틀린 설명은?

① RIP는 IGP이며 Hop Count를 사용한다.
② OSPF는 같은 AS 내부에서 사용하는 IGP이다.
③ eBGP는 서로 다른 AS 사이에서 사용한다.
④ iBGP는 RIP, OSPF처럼 IGP의 한 종류이다.

풀이

정답은 ④번

iBGP는 같은 AS 내부에서 사용하지만 IGP는 아니다.

IGP
├─ RIP
└─ OSPF

BGP
├─ iBGP
└─ eBGP

iBGP

Internal BGP
→ 같은 AS 내부에서 BGP Route 정보 교환

eBGP

External BGP
→ 서로 다른 AS 사이에서 BGP Route 정보 교환

핵심: iBGP는 내부에서 사용하지만 IGP는 아니다.

---

Q16. PUT과 PATCH

사용자 프로필에서 전화번호 하나만 수정하려고 한다.

① GET
② POST
③ PUT
④ PATCH

풀이

정답은 ④ PATCH

이번에도 정확하게 구분했다.

PUT
→ 전체 교체

PATCH
→ 일부 수정

예를 들어

{
  "name": "pingu",
  "phone": "010-1111-2222",
  "email": "test@example.com"
}

에서 phone만 수정한다면 PATCH가 적절하다.

---

Q17. HTTP 502와 504

Reverse Proxy가 뒤쪽 WAS에게 요청을 보냈다.

WAS가 응답은 했지만 응답이 비정상적이라 Proxy가 정상 처리할 수 없었다.

풀이

정답은

502 Bad Gateway

이다.

502

Upstream Server의 응답이 잘못됨

응답은 왔지만 정상 처리 불가

504

Upstream Server가 제한 시간 안에 응답하지 않음

Timeout

쉽게 기억하면

502
→ 응답은 왔는데 이상함

504
→ 응답이 안 와서 시간 초과

이다.

---

Q18. TLS 대칭키와 공개키

HTTPS/TLS 통신에서 실제 데이터 전송에 주로 대칭키 암호화를 사용하는 이유는?

① 인증서를 사용하지 않아도 서버 인증 가능
② 공개키보다 빠르고 효율적
③ 공개키는 인터넷에서 사용할 수 없음
④ 대칭키는 키 교환이 필요 없음

풀이

정답은 ②번

대칭키 암호화는 공개키 암호화보다 일반적으로 빠르고 효율적이기 때문에 실제 대량 데이터 암호화에 적합하다.

역할을 나누면 다음과 같다.

공개키 기반 기술
→ 서버 인증
→ 안전한 Key 교환

대칭키
→ 실제 데이터 암호화
→ 빠르고 효율적

따라서

공개키
→ 인증 / Key 교환

대칭키
→ 실제 데이터 전송

으로 기억하면 된다.

---

Q19. SPoF와 Load Balancer 이중화

다음 구조가 있다.

Client
   |
   v
Load Balancer 1대
   |
 +---+---+
 |       |
WEB A   WEB B

WEB Server는 2대지만 Load Balancer는 1대이다.

풀이

문제점은

Load Balancer가 SPoF가 될 수 있다는 것

이다.

WEB Server가 아무리 두 대 이상 존재해도
모든 트래픽이 Load Balancer 한 대를 반드시 지나간다면
Load Balancer 장애 시 서비스 전체가 막힐 수 있다.

개선

Load Balancer도 이중화한다.

예:

Client
   |
  VIP
   |
+------+------+
|             |
LB A         LB B
Active      Standby
   |
 +---+---+
 |       |
WEB A   WEB B

또는 Active-Active 구조도 사용할 수 있다.

핵심

WEB만 이중화했다고 끝이 아님

전체 구조에서

• Load Balancer
• Switch
• NIC
• Database
• Gateway

등도 SPoF가 될 수 있는지 확인해야 한다.

---

Q20. 같은 네트워크에서 ARP

다음 중 올바른 설명은?

① 무조건 Default Gateway MAC을 찾는다.
② ARP Cache에 목적지 MAC이 없으면 목적지 IP에 대해 ARP Request를 보낸다.
③ DNS Server에게 목적지 MAC을 물어본다.
④ Router가 먼저 목적지 MAC을 알려준다.

풀이

정답은 ②번

Q12에서 한 번 헷갈렸던 내용이었지만 마지막 문제에서는 정확하게 맞혔다.

같은 네트워크라면

목적지 IP 확인
↓
ARP Cache 확인
↓
MAC 정보가 있으면 사용
↓
없으면 ARP Request
↓
목적지 Host MAC 확인

을 수행한다.

반면 다른 Network라면

목적지 IP
→ 원격 Host

목적지 MAC
→ Default Gateway

가 된다.

---

📌 DAY 6 — 오답 및 헷갈렸던 개념

문제	개념	핵심 복습
Q3	Wireshark	tcp.port보다 문제 조건에 맞게 tcp.srcport 사용
Q8	DHCP	Discover는 빈 IP를 찾는 것이 아니라 DHCP Server를 찾는 단계
Q10	혼잡 제어	송신자 문제가 아니라 Network 혼잡을 제어
Q12	ARP	같은 Network에서는 Gateway가 아니라 목적지 MAC을 직접 확인

---

🔥 오늘 특히 기억해야 할 내용

DNS

Root
↓
TLD
↓
Authoritative

TLD:

Top-Level Domain

예:

.com
.net
.org
.kr

---

Wireshark

ip.src
→ Source IP

ip.dst
→ Destination IP

tcp.srcport
→ TCP Source Port

tcp.dstport
→ TCP Destination Port

예:

tcp.srcport == 443 && ip.dst == 192.168.100.20

---

IPv4 단편화

Identification
→ 같은 원본 Packet 구분

Fragment Offset
→ 원본 내 위치

MF = 1
→ 뒤에 Fragment 있음

DF = 1
→ 단편화 금지

---

TCP / UDP

TCP
→ 연결 지향
→ 3-Way Handshake
→ 순서 보장
→ 재전송

UDP
→ 비연결
→ Handshake 없음
→ 빠르고 단순

---

DHCP

Discover
→ DHCP Server 찾기

Offer
→ IP 제안

Request
→ IP 사용 요청

ACK
→ 최종 승인

---

Load Balancing

Round Robin
→ 순서대로 분배

Least Connection
→ 현재 연결 수가 가장 적은 Server

---

흐름 제어와 혼잡 제어

흐름 제어
→ 수신자가 감당 가능한가?

혼잡 제어
→ Network가 감당 가능한가?

---

Go-Back-N / Selective Repeat

Go-Back-N
→ 손실 지점부터 이후 전부

Selective Repeat
→ 손실된 것만

---

ARP

같은 Network
→ 목적지 Host MAC

다른 Network
→ Default Gateway MAC

그리고

IP
→ 최종 목적지 기준

MAC
→ 현재 구간의 다음 전달 대상

---

BGP

IGP
├─ RIP
└─ OSPF

BGP
├─ iBGP
└─ eBGP

iBGP
→ 같은 AS 내부의 BGP 정보 교환

eBGP
→ 서로 다른 AS 사이

주의:

iBGP ≠ IGP

---

HTTP

404
→ 요청한 Resource 없음

500
→ Server 내부 오류

502
→ Upstream 응답 이상

504
→ Upstream Timeout

---

TLS

공개키 기반 기술
→ 인증 / Key 교환

대칭키
→ 실제 데이터 암호화

---

SPoF

Single Point of Failure

Server뿐 아니라

Load Balancer
Switch
Database
Gateway
NIC

등 전체 경로를 보고 SPoF가 있는지 확인해야 한다.

---

🎯 다음 복습 목표 — DAY 7

다음 복습에서는 오늘 한 번 헷갈렸던 부분을 다시 문제로 확인한다.

• 같은 Network에서 ARP 동작 다시 확인
• 다른 Network에서 Gateway MAC을 사용하는 이유
• DHCP Discover 의미 다시 확인
• 흐름 제어와 혼잡 제어 구분
• Wireshark src / dst Filter 직접 작성
• DNS Root / TLD / Authoritative 역할 구분
• IPv4 단편화 Field 역할
• TCP 재전송 방식 비교
• SPoF가 발생할 수 있는 위치 찾기
• BGP / IGP 관계 복습
• DAY1~DAY11 전체 범위에서 새로운 문제 추가

---

DAY 6 복습 완료! ✅

#네트워크 #혼자공부하는네트워크 #네트워크공부 #TCP #UDP #ARP #DNS #DHCP #HTTP #TLS #Wireshark #IPv4 #CIDR #BGP #로드밸런싱 #SPoF #정보보안 #복습