혼자 공부하는 네트워크 복습 DAY7

오늘도 지금까지 공부했던 네트워크 내용을 기반으로 복습을 진행했다.

이번에는 이전 복습에서 같은 문제가 반복되는 것을 줄이고, TCP, DNS, DHCP, NAT/NAPT, HTTP, IPv6, ICMP, TTL 등 여러 범위에서 문제를 골고루 풀어봤다.

총 20문제를 한 문제씩 풀고, 틀렸거나 헷갈린 내용은 바로 다시 정리했다.

---

Q1. TCP Sequence Number와 ACK Number

TCP 연결이 완료된 상태에서 Client가 Server에게 다음과 같이 데이터를 보낸다.

Sequence Number = 1000
Payload = 500 Byte

패킷이 정상적으로 전달되었다면 Server가 보내는 ACK Number는 얼마일까?

또한 데이터가 유실된 경우 TCP에서는 어떤 방식으로 재전송이 발생할 수 있을까?

나의 답

ACK는 다음 세그먼트를 의미하니까 2라고 생각했다.

패킷이 유실되면 Go-Back-N처럼 유실된 지점부터 다시 보내는 방식이라고 생각했다.

풀이

정답은

ACK Number = 1500

이다.

TCP의 Sequence Number와 ACK Number는 패킷의 순번이 아니라 Byte 단위로 동작한다.

현재

Sequence Number = 1000
Payload = 500 Byte

이므로 전송한 데이터의 Byte 범위는

1000 ~ 1499

이다.

따라서 수신 측이 다음으로 받고 싶은 Byte 번호는

1500

이므로

ACK Number = 1500

이 된다.

TCP에서 데이터가 유실된 경우에는 일정 시간 동안 ACK가 오지 않으면 재전송하는 방식이 있다.

RTO
= Retransmission Timeout

또한 동일한 ACK가 반복되는 Duplicate ACK를 통해 특정 TCP Segment가 유실되었을 가능성을 판단할 수도 있다.

일반적으로 Duplicate ACK가 일정 횟수 발생하면 Timeout을 기다리지 않고 재전송하는 Fast Retransmit이 발생할 수 있다.

RTO 주의

정보처리기사에서 공부했던 RTO와 TCP의 RTO는 약자가 같지만 의미가 다르다.

TCP RTO
→ Retransmission Timeout
→ 재전송 타임아웃

재해복구 RTO
→ Recovery Time Objective
→ 목표 복구 시간

RPO
→ Recovery Point Objective
→ 목표 복구 시점

핵심

TCP Sequence / ACK
→ Byte 단위

ACK Number
→ 다음으로 받고 싶은 Byte 번호

---

Q2. DNS, ARP, Default Gateway

PC의 네트워크 설정이 다음과 같다.

IP Address : 192.168.10.25/24
Gateway    : 192.168.10.1
DNS Server : 8.8.8.8

사용자가 브라우저에서

https://example.com

에 접속하려고 한다.

DNS, ARP, Default Gateway는 어떤 순서로 사용될까?

나의 답

DNS Server에게 요청할 때 Default Gateway를 통해 전달한다는 것까지는 알겠는데 이후 과정이 헷갈렸다.

풀이

PC에는 DNS Server가

8.8.8.8

로 설정되어 있다.

따라서 PC는 example.com의 IP 주소를 알아내기 위해 8.8.8.8에게 DNS Query를 보내려고 한다.

그런데 PC의 네트워크는

192.168.10.0/24

이고 DNS Server는

8.8.8.8

이다.

서로 다른 네트워크이다.

따라서 PC는 DNS 패킷을 실제로 보내기 전에 목적지가 자신의 Local Network인지 확인한다.

8.8.8.8
→ Local Network가 아님
→ Default Gateway로 전달

이때 Default Gateway의 MAC Address를 모른다면 ARP를 사용한다.

PC
↓
192.168.10.1의 MAC Address가 누구야?
↓
ARP Request
↓
Default Gateway
↓
ARP Reply

Gateway의 MAC Address를 알아낸 뒤 DNS Query를 전송한다.

이때 중요한 점은 다음과 같다.

Destination IP
→ 8.8.8.8

Destination MAC
→ Default Gateway의 MAC Address

즉,

IP Address
→ 최종 목적지

MAC Address
→ 현재 네트워크에서 다음으로 전달할 대상

DNS 응답을 통해 example.com의 IP 주소를 알아낸 뒤 실제 웹 서버와 통신을 시작한다.

핵심

다른 네트워크로 통신
→ Default Gateway 사용

Gateway MAC을 모름
→ ARP 사용

IP
→ 최종 목적지

MAC
→ 현재 Link에서의 다음 전달 대상

---

Q3. Load Balancer와 Health Check

Web Server A와 B가 Load Balancer 뒤에서 서비스를 제공하고 있다.

그런데 Web Server A가 장애가 발생했는데도 Load Balancer가 계속 A로 요청을 보내고 있다.

이 문제를 방지하기 위해 사용하는 기능은 무엇일까?

나의 답

Load Balancer라고 생각했다.

트래픽을 여러 서버로 분산해서 성능을 향상시키는 역할이라고 생각했다.

풀이

정답은

Health Check

이다.

Load Balancer는 여러 서버로 Traffic을 분산하는 장비 또는 기능이고,

Health Check는 Load Balancer가 Backend Server의 상태를 주기적으로 확인하는 기능이다.

Load Balancer
↓
Server A 상태 확인
Server B 상태 확인
↓
정상 Server에게만 요청 전달

만약 Server A가 응답하지 않는다면

Server A
→ Unhealthy

Server B
→ Healthy

로 판단하고 A에게 요청을 보내지 않을 수 있다.

핵심

Load Balancer
→ Traffic 분산

Health Check
→ Server 상태 확인
→ 장애 Server를 Traffic 대상에서 제외

---

Q4. RIP, OSPF, BGP

RIP, OSPF, BGP는 각각 어디에서 사용되는 Routing Protocol일까?

그리고 RIP과 OSPF 중 Link State 방식을 사용하는 것은 무엇일까?

나의 답

RIP
→ Routing Information Protocol
→ IGP
→ Distance Vector
→ Hop Count 사용

OSPF
→ Open Shortest Path First
→ IGP
→ Link State

BGP
→ Border Gateway Protocol
→ 서로 다른 AS 간 사용

풀이

전체적으로 맞았다.

RIP과 OSPF는 대표적인 IGP이다.

IGP
= Interior Gateway Protocol

하나의 AS 내부에서 Routing 정보를 주고받을 때 사용한다.

RIP

RIP
→ Distance Vector
→ Hop Count를 주요 Metric으로 사용

OSPF

OSPF
→ Link State
→ 네트워크 전체의 Link 정보를 기반으로 경로 계산

BGP

BGP
→ Border Gateway Protocol

대표적으로 서로 다른 AS 간 Routing 정보를 교환할 때 사용한다.

eBGP
→ 서로 다른 AS 간

iBGP
→ 같은 AS 내부에서 BGP Route 전달

따라서 BGP가 무조건 서로 다른 AS 사이에서만 사용되는 것은 아니다.

핵심

RIP
→ IGP
→ Distance Vector

OSPF
→ IGP
→ Link State

BGP
→ AS 간 Routing에 대표적으로 사용

---

Q5. DHCP DORA

새로운 PC가 네트워크에 연결되었지만 아직 IP Address가 없다.

DHCP를 통해 IP Address를 할당받는 과정인 DORA를 설명해보자.

나의 답

Discover
→ DHCP가 사용할 IP를 찾는 과정

Offer
→ IP를 제안

Request
→ 제안받은 IP를 사용하겠다고 요청

ACK
→ 최종 승인

풀이

Offer, Request, ACK의 개념은 맞았지만 Discover의 주체가 반대였다.

정확한 과정은 다음과 같다.

D
Discover

O
Offer

R
Request

A
ACK

Discover

DHCP Client가 DHCP Server를 찾는다.

Client
→ "DHCP Server 있나요?"

아직 IP Address가 없기 때문에 Broadcast를 이용한다.

Offer

DHCP Server가 사용할 수 있는 IP Address를 제안한다.

Server
→ "이 IP 사용하는 건 어때?"

Request

Client가 제안받은 IP Address를 사용하겠다고 요청한다.

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

ACK

DHCP Server가 최종적으로 사용을 승인한다.

Server
→ "확인. 사용해."

핵심

Discover
→ Client가 DHCP Server를 찾음

Offer
→ Server가 IP 제안

Request
→ Client가 IP 사용 요청

ACK
→ Server가 최종 승인

---

Q6. NAT, NAPT, Port Forwarding

내부 네트워크에 다음 두 PC가 존재한다.

PC A
192.168.0.10

PC B
192.168.0.20

두 PC가 하나의 Public IP Address를 공유해 동시에 인터넷에 접속한다.

Public IP
203.0.113.10

Router는 돌아오는 Traffic이 PC A의 것인지 PC B의 것인지 어떻게 구분할까?

나의 답

Port Forwarding이라고 생각했다.

풀이

정답은

NAPT

이다.

NAPT
= Network Address Port Translation

NAPT는 IP Address뿐만 아니라 Port Number까지 함께 변환하고 기록한다.

예를 들어

192.168.0.10:50001
→ 203.0.113.10:40001

192.168.0.20:50001
→ 203.0.113.10:40002

처럼 하나의 Public IP Address를 사용하더라도 Port Number를 다르게 사용한다.

따라서 응답이

203.0.113.10:40001

로 들어오면 Router는 NAT/NAPT Table을 확인해서

192.168.0.10:50001

로 전달할 수 있다.

Port Forwarding과 차이

Port Forwarding은 외부에서 내부 Host로 통신을 시작할 때 특정 Port를 내부 Host와 연결해 두는 방식이다.

예를 들어

203.0.113.10:8080
→ 192.168.0.10:80

처럼 설정할 수 있다.

핵심

NAPT
→ 여러 Private IP가 하나의 Public IP 공유
→ Port Number로 각각의 Connection 구분

Port Forwarding
→ 특정 외부 Port를 내부 Host:Port와 연결

---

Q7. HTTP 502와 504

다음 두 상황의 HTTP Status Code를 구분해보자.

A.
Reverse Proxy가 Backend Server에 연결했지만
정상적인 응답을 받지 못함

B.
Backend Server에게 요청을 전달했지만
정해진 시간 안에 응답이 오지 않음

나의 답

A
→ 502

B
→ 504

풀이

정답이다.

502 Bad Gateway

Gateway 또는 Proxy가 Upstream Server로부터 정상적인 응답을 받지 못한 경우이다.

Client
↓
Reverse Proxy
↓
Backend Server

Backend 응답 이상
→ 502 Bad Gateway

504 Gateway Timeout

Upstream Server로부터 정해진 시간 안에 응답이 오지 않은 경우이다.

Backend Server
→ 응답 지연
→ Timeout

504 Gateway Timeout

핵심

502
→ Backend 응답 자체에 문제

504
→ Backend 응답 Timeout

---

Q8. IPv4 Fragmentation Header

IPv4 단편화와 관련된 다음 Header Field의 역할을 설명해보자.

Identification
Fragment Offset
MF
DF

나의 답

Identification
→ 같은 원본 Packet인지 확인

Fragment Offset
→ 원본 Packet에서의 위치

MF
→ 뒤에 Fragment가 더 존재하는지 확인

DF
→ Fragmentation 허용 여부

풀이

정답이다.

Identification

같은 원본 IP Packet에서 만들어진 Fragment인지 식별할 때 사용한다.

같은 Identification
→ 같은 원본 Packet의 Fragment

Fragment Offset

현재 Fragment가 원래 데이터에서 어느 위치에 있었는지 나타낸다.

MF

MF
= More Fragments

MF = 1
→ 뒤에 Fragment가 더 있음

MF = 0
→ 마지막 Fragment

DF

DF
= Don't Fragment

DF = 1
→ Fragmentation 금지

DF = 0
→ Fragmentation 가능

핵심

Identification
→ 같은 원본 Packet 식별

Fragment Offset
→ 원본에서의 위치

MF
→ 뒤에 Fragment가 더 있는가?

DF
→ Fragmentation을 허용하는가?

---

Q9. TCP와 UDP

다음 서비스에 TCP와 UDP 중 어떤 Protocol이 일반적으로 더 적합할까?

A. 파일 다운로드
B. 실시간 음성 통화
C. 웹 페이지 전송
D. 온라인 게임의 실시간 위치 정보

나의 답

A
→ TCP

B
→ UDP

C
→ TCP

D
→ UDP

파일 다운로드와 웹 페이지는 신뢰성이 중요하고,

실시간 음성이나 게임은 빠른 응답이 더 중요하다고 생각했다.

풀이

정답이다.

TCP

Connection 설정
재전송
순서 보장
Flow Control
Congestion Control

등을 제공한다.

따라서 일반적으로 데이터의 정확한 전달이 중요한 경우에 적합하다.

UDP

Connection 설정 없음
기본 재전송 없음
순서 보장 없음
Overhead가 상대적으로 작음

따라서 일부 데이터가 유실되더라도 실시간성이 중요한 서비스에 활용할 수 있다.

핵심

TCP
→ 신뢰성 중심

UDP
→ 실시간성 / 낮은 Overhead 중심

---

Q10. Wireshark Display Filter

다음 조건을 만족하는 Wireshark Display Filter를 작성해보자.

Source IP
192.168.10.20

Destination TCP Port
443

나의 답

ip.src == 192.168.10.20 && tcp.dstport == 443

풀이

정답이다.

ip.src
→ Source IP Address

tcp.dstport
→ TCP Destination Port

&&
→ AND

따라서

ip.src == 192.168.10.20 && tcp.dstport == 443

는

Source IP = 192.168.10.20

그리고

Destination TCP Port = 443

인 Packet만 표시한다.

---

Q11. HTTP PUT과 PATCH

Server에 다음과 같은 사용자 정보가 저장되어 있다.

{
    "name": "pingu",
    "age": 28,
    "job": "engineer"
}

여기서 age 값만 29로 변경하려고 한다.

PUT과 PATCH 중 어떤 Method가 더 적절할까?

나의 답

PATCH

PUT은 전체 Resource를 변경하는 것이라고 기억했다.

풀이

정답이다.

PUT
→ Resource 전체 수정 / 대체

PATCH
→ Resource 일부 수정

현재는

age

값 하나만 변경하려고 하기 때문에 PATCH가 더 적절하다.

예를 들면

PATCH /users/1

{
    "age": 29
}

와 같은 방식이다.

핵심

PUT
→ 전체

PATCH
→ 일부

---

Q12. IPv6 주소의 ::

IPv6 주소에서 ::는 왜 사용할까?

또 하나의 IPv6 주소에서 ::를 두 번 사용할 수 없는 이유는 무엇일까?

나의 답

잘 모르겠다.

풀이

IPv6 Address는 128bit 크기이며 일반적으로 16진수 4자리씩 8개의 Group으로 표현한다.

예를 들어

2001:0db8:0000:0000:0000:ff00:0042:8329

와 같이 표현할 수 있다.

주소가 길기 때문에 연속된 0000 Group을 ::로 줄여서 표현할 수 있다.

예를 들어

26f7:f750:2ffb:53df:0000:0000:0000:1001

은

26f7:f750:2ffb:53df::1001

로 표현할 수 있다.

그런데 ::는 하나의 IPv6 주소에서 한 번만 사용할 수 있다.

예를 들어

2001::1234::5678

처럼 두 번 사용하면

첫 번째 ::가 몇 개의 0000 Group을 의미하는지,

두 번째 ::가 몇 개의 0000 Group을 의미하는지 알 수 없기 때문이다.

핵심

::
→ 연속된 0000 Group 생략

하나의 IPv6 Address에서 한 번만 사용
→ 생략된 Group의 수를 정확히 판단하기 위해

---

Q13. HTTP Stateless

HTTP의 Stateless는 무슨 의미일까?

또 HTTP가 Stateless인데도 웹사이트에서 로그인 상태를 유지할 수 있는 이유는 무엇일까?

나의 답

Stateless는 상태가 지속적이지 않다는 의미이다.

로그인 상태를 유지하려면 Cache를 사용하는 것이라고 생각했다.

풀이

Stateless의 의미는 맞았다.

HTTP는 기본적으로 각각의 Request를 독립적으로 처리한다.

Request 1
→ 독립적으로 처리

Request 2
→ 독립적으로 처리

Request 3
→ 독립적으로 처리

즉 HTTP 자체는 이전 Request의 상태를 기본적으로 기억하지 않는다.

하지만 실제 Web Service에서는 로그인 상태와 같이 사용자의 상태를 유지해야 하는 경우가 있다.

이때 대표적으로

Cookie
Session

등을 사용한다.

Cache는 로그인 상태를 유지하기 위한 핵심 기술이라기보다 Resource를 재사용하여 성능을 향상하거나 Server 요청을 줄이는 목적에 가깝다.

핵심

Stateless
→ HTTP 자체가 이전 Request의 상태를 기억하지 않음

로그인 상태 유지
→ Cookie / Session 등을 사용

---

Q14. DNS Record

다음 설명에 해당하는 DNS Record를 매칭해보자.

1. Domain Name을 IPv4 Address와 연결
2. Domain Name을 IPv6 Address와 연결
3. Mail Server 정보 지정
4. 다른 Domain Name의 별칭으로 연결

나의 답

1. A
2. AAAA
3. MX
4. CNAME

풀이

모두 정답이다.

A
→ IPv4 Address

AAAA
→ IPv6 Address

MX
→ Mail Exchange
→ Mail Server

CNAME
→ Canonical Name
→ Domain Alias

핵심

A
→ IPv4

AAAA
→ IPv6

MX
→ Mail Server

CNAME
→ Alias

---

Q15. Flow Control과 Congestion Control

TCP에는 Flow Control과 Congestion Control이 있다.

둘의 차이는 무엇일까?

나의 답

Flow Control
→ 수신자가 감당 가능한가?

Congestion Control
→ 네트워크가 감당 가능한가?

풀이

정답이다.

Flow Control

수신 Host의 처리 능력을 고려한다.

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

따라서

"수신자가 이 정도의 Data를 받을 수 있는가?"

를 기준으로 전송량을 조절한다.

Congestion Control

Network 전체의 혼잡 상태를 고려한다.

"현재 Network가 이 정도의 Traffic을 감당할 수 있는가?"

를 판단하여 전송량을 조절한다.

핵심

Flow Control
→ Receiver

Congestion Control
→ Network

---

Q16. Forward Proxy와 Reverse Proxy

다음 상황에서 어떤 Proxy가 사용되는지 구분해보자.

A.
회사 직원들이 Internet에 접속할 때
Proxy Server가 직원들을 대신하여 외부 Web Server에 요청

B.
외부 사용자의 요청을 Proxy Server가 먼저 받고
내부 Web Server에게 전달

나의 답

A
→ Forward Proxy

B
→ Reverse Proxy

풀이

정답이다.

Forward Proxy

Client를 대신한다.

Client
↓
Forward Proxy
↓
Internet Server

Client의 Internet 접근 제어, 접속 기록, Cache 등에 사용할 수 있다.

Reverse Proxy

Server를 대신한다.

Client
↓
Reverse Proxy
↓
Internal Server

외부 Client에게 내부 Server의 구조를 직접 노출하지 않고 요청을 전달할 수 있다.

Load Balancing이나 Cache 등에 활용할 수도 있다.

핵심

Forward Proxy
→ Client를 대신

Reverse Proxy
→ Server를 대신

---

Q17. TCP 3-Way Handshake

TCP Connection을 설정하는 순서를 작성해보자.

Client                Server

   ? -------------------->

     <-------------------- ?

   ? -------------------->

그리고 두 번째 단계에서 SYN과 ACK를 함께 보내는 이유는 무엇일까?

나의 답

SYN
SYN + ACK
ACK

SYN + ACK에서 ACK는 Client가 보낸 SYN을 잘 받았다는 의미이고,

Server도 Client에게 Connection을 설정하기 위해 SYN을 보낸다고 생각했다.

풀이

정답이다.

TCP의 3-Way Handshake는

Client                 Server

SYN
---------------------->

              SYN + ACK
<----------------------

ACK
---------------------->

TCP Connection 완료

의 순서로 진행된다.

첫 번째 SYN

Client가 Server에게 Connection을 요청한다.

"TCP 연결하고 싶어."

두 번째 SYN + ACK

ACK는

Client의 SYN을 정상적으로 받았다.

는 의미이다.

SYN은

Server도 Connection 설정에 참여하고
자신의 Sequence Number를 동기화한다.

는 의미이다.

세 번째 ACK

Client가 Server의 SYN을 정상적으로 받았음을 알려준다.

핵심

TCP 3-Way Handshake

SYN
→ SYN + ACK
→ ACK

---

Q18. Encapsulation

Wireshark에서 HTTP Packet을 확인했을 때 다음과 같은 구조가 보였다.

Ethernet II
→ IPv4
→ TCP
→ HTTP

이 구조는 무엇을 의미할까?

그리고 Encapsulation이란 무엇일까?

나의 답

캡슐화는 하위 계층부터 상위 계층까지 Header에 Packet을 담아 합쳐서 전송하는 과정이라고 생각했다.

풀이

캡슐화의 개념은 알고 있었지만 방향이 반대였다.

송신 측에서는

상위 계층
↓
하위 계층

방향으로 데이터가 내려간다.

예를 들어 HTTP Data를 전송한다면

HTTP Data
↓
TCP Header 추가
↓
IP Header 추가
↓
Ethernet Header 추가

순서로 Encapsulation이 이루어진다.

따라서 Wireshark의

Ethernet II
→ IPv4
→ TCP
→ HTTP

구조는

HTTP Data가 TCP에 포함되고,

TCP Segment가 IP Packet에 포함되고,

IP Packet이 Ethernet Frame에 포함되어 있다는 것을 의미한다.

수신 측에서는 반대로

Ethernet
→ IP
→ TCP
→ HTTP

순서로 Header를 확인하고 제거한다.

이를

Decapsulation

이라고 한다.

핵심

송신
→ 상위 계층 → 하위 계층
→ Encapsulation

수신
→ 하위 계층 → 상위 계층
→ Decapsulation

---

Q19. ICMP

PC가 다른 Network의 Server로 Packet을 보내려고 한다.

그런데 중간 Router가 목적지까지 갈 수 있는 Route를 찾지 못했다.

Router가 송신자에게

"목적지에 도달할 수 없습니다."

라는 정보를 알려주기 위해 사용하는 Protocol은 무엇일까?

또 이 Protocol이 IP 통신의 신뢰성을 보장해줄까?

나의 답

ICMP

라고 답했고,

ICMP가 신뢰성을 보장한다고 생각했다.

풀이

Protocol은 맞다.

ICMP
= Internet Control Message Protocol

ICMP는 IP Packet의 전송 과정에서 발생한 문제를 알려주거나 Network 상태를 진단하는 데 사용한다.

대표적으로

Destination Unreachable

같은 오류 메시지를 전달할 수 있다.

하지만 ICMP가 IP 통신의 신뢰성을 보장하는 것은 아니다.

ICMP 자체도 반드시 상대방에게 도착한다고 보장되는 Protocol은 아니다.

따라서 ICMP의 역할은

오류 보고
네트워크 진단
제어 정보 전달

로 이해하는 것이 좋다.

핵심

ICMP
→ IP 통신 과정의 오류 보고 및 진단

신뢰성 보장
→ X

---

Q20. TTL

IP Packet의 TTL 값이 다음과 같다.

TTL = 3

Router를 통과할 때마다 TTL이 1씩 감소한다.

1. 세 번째 Router까지 이동하면 TTL은 얼마가 될까?
2. TTL이 0이 되면 Packet은 어떻게 처리될까?
3. TTL이 존재하는 이유는 무엇일까?

나의 답

1. TTL = 0
2. Packet 폐기
3. 통신 지연 문제 방지?

라고 생각했다.

풀이

1번과 2번은 맞았다.

TTL 3
↓
Router
TTL 2
↓
Router
TTL 1
↓
Router
TTL 0
↓
Packet 폐기

TTL은

Time To Live

의 약자이다.

Router를 하나 통과할 때마다 TTL 값이 감소하고,

TTL이 0이 되면 해당 Router는 Packet을 폐기한다.

TTL이 존재하는 가장 중요한 이유는

Routing Loop

가 발생했을 때 Packet이 Network 안에서 무한히 돌아다니는 것을 방지하기 위해서이다.

예를 들어 Routing Table이 잘못 설정되어

Router A
→ Router B
→ Router C
→ Router A
→ Router B
→ ...

처럼 Packet이 계속 순환할 수 있다.

TTL이 없다면 Packet이 계속 Network를 돌아다니면서 불필요한 Traffic을 발생시킬 수 있다.

TTL을 사용하면 일정한 Hop 수를 초과한 Packet은 자동으로 폐기된다.

핵심

TTL
= Time To Live

Router를 지날 때마다
→ 1 감소

TTL = 0
→ Packet 폐기

목적
→ Routing Loop로 인한 Packet 무한 순환 방지

---

DAY7 오답 및 헷갈린 내용 정리

오늘은 단순히 정답을 맞히는 것보다 기존에 애매하게 알고 있던 개념들을 다시 정리하는 데 의미가 있었다.

1. TCP ACK는 Segment 번호가 아니다

처음에는 ACK Number를 다음 Segment의 번호처럼 생각했다.

하지만 TCP의 Sequence Number와 ACK Number는 Byte 단위이다.

Sequence = 1000
Payload = 500 Byte

전송 Byte
1000 ~ 1499

다음으로 받을 Byte
1500

ACK = 1500

---

2. TCP RTO와 재해복구 RTO는 다르다

약자는 같지만 의미가 전혀 다르다.

TCP RTO
→ Retransmission Timeout

재해복구 RTO
→ Recovery Time Objective

RPO
→ Recovery Point Objective

---

3. 다른 Network로 보낼 때 ARP 대상

다른 Network에 있는 Server에게 통신한다고 해서 해당 Server의 MAC Address를 ARP로 알아내는 것이 아니다.

다른 Network 목적지
↓
Default Gateway로 전달
↓
Gateway MAC Address를 ARP로 확인

따라서

Destination IP
→ 최종 Server

Destination MAC
→ Default Gateway

가 될 수 있다.

---

4. Load Balancer와 Health Check 구분

Load Balancer
→ Traffic 분산

Health Check
→ Server 상태 확인

Load Balancer가 있다고 해서 장애 Server를 자동으로 정확하게 구분하는 것이 아니라 Backend 상태를 확인하는 Health Check가 중요하다.

---

5. DHCP Discover의 주체

Discover는 DHCP Server가 IP를 찾는 과정이 아니다.

Discover
→ DHCP Client가 DHCP Server를 찾음

전체 과정은

Discover
→ Offer
→ Request
→ ACK

이다.

---

6. NAPT와 Port Forwarding

이번 복습에서 가장 확실히 구분해야 할 부분 중 하나였다.

NAPT
→ 내부 여러 Host가 하나의 Public IP 공유
→ Port Number까지 변환하여 Connection 구분

Port Forwarding
→ 외부의 특정 IP:Port를 내부 Host:Port와 연결

---

7. IPv6의 ::

IPv6에서는 연속된 0000 Group을

::

로 줄여서 표현할 수 있다.

하지만 한 Address에서 한 번만 사용할 수 있다.

이유
→ 두 번 사용하면 각각 몇 개의 0000 Group이 생략된 것인지 알 수 없음

---

8. HTTP Stateless

Stateless
→ HTTP 자체는 이전 요청의 상태를 기억하지 않음

로그인 상태 유지에는 Cache가 아니라 대표적으로

Cookie
Session

등을 사용한다.

---

9. Encapsulation 방향

처음에는 하위 계층에서 상위 계층으로 올라가면서 Header가 추가된다고 생각했다.

정확히는 송신 측에서

상위 계층
↓
하위 계층

으로 내려가면서 Header가 추가된다.

HTTP
↓
TCP
↓
IP
↓
Ethernet

수신 측에서는 반대로 Header를 제거한다.

---

10. ICMP는 신뢰성 보장 Protocol이 아니다

ICMP
→ 오류 보고
→ Network 진단
→ 제어 정보 전달

IP 통신의 성공적인 전달 자체를 보장하는 Protocol은 아니다.

---

11. TTL의 목적

TTL은 단순히 통신 지연을 막기 위한 값이 아니다.

가장 중요한 목적은

Routing Loop에 의해
Packet이 Network에서 무한히 순환하는 것을 방지

하는 것이다.

Router 통과
→ TTL 감소

TTL = 0
→ Packet 폐기

---

DAY7 최종 핵심 정리

TCP ACK
→ 다음으로 받고 싶은 Byte Number

TCP RTO
→ Retransmission Timeout

다른 Network 통신
→ Default Gateway 사용
→ Gateway MAC을 ARP로 확인

Health Check
→ Backend Server 상태 확인

RIP
→ Distance Vector

OSPF
→ Link State

BGP
→ AS 간 Routing에 대표적으로 사용

DHCP
→ Discover → Offer → Request → ACK

NAPT
→ IP + Port 변환
→ 하나의 Public IP를 여러 Private IP가 공유

502
→ Bad Gateway

504
→ Gateway Timeout

IPv4 Fragmentation
→ Identification / Fragment Offset / MF / DF

TCP
→ 신뢰성 중심

UDP
→ 실시간성 및 낮은 Overhead 중심

Wireshark
→ ip.src
→ tcp.dstport

PUT
→ 전체 대체

PATCH
→ 일부 수정

IPv6 ::
→ 연속된 0000 Group 생략
→ 한 Address에서 한 번만 사용

HTTP
→ Stateless

로그인 상태 유지
→ Cookie / Session

DNS Record
A     → IPv4
AAAA  → IPv6
MX    → Mail Server
CNAME → Alias

Flow Control
→ Receiver 상태 고려

Congestion Control
→ Network 혼잡 상태 고려

Forward Proxy
→ Client를 대신

Reverse Proxy
→ Server를 대신

TCP 3-Way Handshake
→ SYN → SYN+ACK → ACK

Encapsulation
→ 상위 계층 → 하위 계층
→ Header 추가

Decapsulation
→ 하위 계층 → 상위 계층
→ Header 제거

ICMP
→ 오류 보고 및 Network 진단
→ 신뢰성 보장 X

TTL
→ Router 통과 시 감소
→ 0이면 Packet 폐기
→ Routing Loop에 의한 무한 순환 방지

---

오늘의 복습 결과

총 20문제를 풀었다.

전체적으로 TCP/UDP, Routing Protocol, DNS Record, HTTP Method, Proxy 등의 개념은 잘 기억하고 있었다.

반면 다음 내용은 다시 복습할 필요가 있다.

TCP Sequence / ACK의 Byte 단위 계산
DNS + ARP + Default Gateway의 실제 동작 순서
Health Check
NAPT와 Port Forwarding 차이
IPv6 주소 축약
HTTP Stateless와 Cookie / Session
Encapsulation 방향
ICMP의 역할
TTL의 존재 이유

특히 단순 용어 암기보다

"실제로 Packet이 어떤 순서로 이동하는가?"

를 생각하면서 공부해야 할 것 같다.

네트워크 개념들이 하나씩 연결되기 시작하면서 이전에 따로 외웠던

ARP
IP
MAC
Gateway
DNS
TCP
Routing

등이 실제 통신 과정에서 어떻게 같이 사용되는지 조금씩 이해되고 있다.

DAY8 복습에서도 단순히 같은 문제를 반복하기보다는 지금까지 공부한 전체 범위에서 다양한 형태의 문제를 풀어볼 예정이다.