컴넷) (11.26)

[  ]nat

[   ]arp과정

[  ]서브넷 할당 문제

[  ]nack중간고사 문제 

[  ]HW3문제 풀이 

 

 

 

 

 

 

IP 주소 블록을 유연하게 나누자

-네트워크 단위의 할당에서 à CIDR

-네트워크 내부의 할당에서 à VLSM

 

 

 

 

 

 

 

 

 

 

 

 

1. 지난 시간 복습 및 기타 이슈 (Intro)

• 네트워크 계층(Network Layer) 마무리:
  • NAT (Network Address Translation): IP 주소 부족 문제를 해결하기 위한 임시방편이었으나, 결과적으로 IPv4 수명을 연장시킴.
    • Dynamic NAT / Static NAT: 기본형.
    • PAT (Port Address Translation): 가정용 공유기 등에서 가장 많이 사용됨. (IP + Port 번호 활용)

---

2. 전송 계층 (Transport Layer) 개요

• 목표: End-to-End(종단 간) Reliable Data Transfer(신뢰성 있는 데이터 전송).
  • 데이터 링크 계층은 '링크'의 신뢰성을 담당하지만, 라우터를 거치는 전체 '경로'의 신뢰성은 보장하지 못함(버퍼 오버플로우 등으로 패킷 유실 가능).
  • 따라서 전송 계층에서 **에러 제어(Error Control), 흐름 제어(Flow Control), 혼잡 제어(Congestion Control)**가 필요함.
• 멀티플렉싱(Multiplexing): 하나의 호스트에서 여러 애플리케이션을 구분하기 위해 포트(Port) 번호를 사용.

---

3. 오류 제어 (Error Control) - RDT 프로토콜의 진화

1단계: rdt 1.0 (이상적인 네트워크)

• 가정: 패킷 깨짐(Bit Error) 없고, 유실(Loss)도 없음.
• 동작: 별도 제어 불필요. 보내면 무조건 도착함.

2단계: rdt 2.0 ~ 2.1 (비트 오류가 있는 네트워크)

• 가정: 패킷이 깨질 수는 있으나, 사라지지는 않음.
• 필요 기능:
  1. Error Detection: CRC 코드 등을 통해 깨졌는지 확인.
  2. Feedback: 수신자가 ACK(잘 받음) 또는 **NAK(깨짐)**를 보냄.
  3. Retransmission (ARQ): NAK 수신 시 재전송.
• 문제점 (rdt 2.0의 결함): 피드백(ACK/NAK) 패킷 자체도 깨질 수 있음.
• 해결책 (rdt 2.1): 피드백이 불분명하면 무조건 재전송(보수적 접근). 이때 중복 수신(Duplicate) 문제가 발생하므로 **Sequence Number(일련번호)**를 도입하여 패킷을 구별함.

3단계: rdt 3.0 (손실이 있는 네트워크 - 현실)

• 가정: 패킷이 깨질 수도 있고, 도중에 사라질(Loss) 수도 있음.
• 문제: 패킷이 사라지면 피드백도 안 오므로 무한 대기 상태에 빠짐.
• 해결책: 타이머(Timer) 도입.
  • 정해진 시간(Timeout) 내에 ACK가 안 오면 손실로 간주하고 재전송.
• 결과: Stop-and-Wait ARQ 방식이 됨.
  • 하나 보내고 ACK 올 때까지 멈춰서 기다림.
  • 동작은 확실하나 성능(Throughput)이 매우 나쁨. (보내는 시간보다 기다리는 시간이 압도적으로 김)

---

4. 성능 개선: 파이프라이닝 (Pipelining)

• 개념: ACK를 기다리지 않고 여러 개의 패킷을 연속으로 전송하는 기법.
• 조건: 송신자와 수신자에 **버퍼(메모리)**가 필요함. (재전송을 위해 보낸 패킷을 기억하고 있어야 하므로)
• 메모리 활용 방식에 따라 Go-Back-N과 Selective Repeat로 나뉨.

A. Go-Back-N (GBN) ARQ

• 특징:
  • 송신자 윈도우(버퍼) 크기 = N: N개까지 연속 전송 가능.
  • 수신자 윈도우 크기 = 1: 순서대로만 받음. (순서가 틀리면 버림)
• 동작 원리:
  • 누적 ACK (Cumulative ACK): "ACK 3"은 "3번까지 모두 잘 받았다(다음은 4번 줘)"는 의미.
  • 오류 발생 시: 만약 0번이 깨지고 1, 2, 3번이 잘 도착해도, 수신자는 0번을 기다리므로 1, 2, 3번을 모두 버림(Discard).
  • 재전송: 송신자는 타임아웃 시 0번부터(Go-Back) N개(그 뒤 패킷 전부)를 다시 보냄.
• 장단점: 구조가 단순하지만, 오류 발생 시 멀쩡한 패킷까지 재전송하여 대역폭 낭비가 심함.

B. Selective Repeat (SR) ARQ

• 특징:
  • 송신자 윈도우 = N, 수신자 윈도우 = N.
  • 수신자가 순서가 뒤바뀐 패킷도 버퍼에 저장해둠.
• 동작 원리:
  • 개별 ACK: 각 패킷마다 별도로 ACK 처리.
  • 오류 발생 시: 0번이 깨지고 1, 2, 3번이 도착하면, 수신자는 **1, 2, 3번을 버퍼에 저장(Keep)**하고 0번 재전송 요청(혹은 Timeout 대기).
  • 재전송: 송신자는 오류가 난(ACK를 못 받은) 0번 패킷만 콕 집어서 재전송.
  • 0번이 도착하면 버퍼에 있던 1, 2, 3번과 합쳐서 상위 계층으로 올림.
• 결론: 메모리가 저렴해진 현대에는 성능 효율이 좋은 SR 방식을(혹은 변형을) 주로 사용함.

---

5. 흐름 제어 (Flow Control) (간단 요약)

• 목적: **수신자(Receiver)**의 버퍼가 넘치지 않도록 조절.
• 방식:
  1. Window 기반: 수신자가 자신의 남은 버퍼 크기(Receive Window)를 송신자에게 계속 알려줌 (TCP 방식).
  2. On/Off: 수신자가 Pause 프레임을 보냄.

---

6. 혼잡 제어 (Congestion Control) (도입부)

• 목적: 네트워크(Network/Router) 자체가 감당 못 할 정도로 트래픽이 몰리는 것을 방지. (수신자가 아님)
• 현상 (Congestion): 라우터 버퍼 오버플로우 발생 → 패킷 손실(Packet Loss) 및 지연(Delay) 급증.
• 역사: 과거 인터넷 마비 사태(Congestion Collapse) 이후 Van Jacobson이 TCP에 혼잡 제어 알고리즘을 추가하여 해결함.
• 핵심 아이디어:
  • 네트워크 상태를 송신자가 직접 알기 어려움.
  • 따라서 송신자는 **패킷 손실(Loss)**이나 **지연(Delay)**이 감지되면 "아, 네트워크가 혼잡하구나"라고 판단하고 전송 속도를 스스로 줄임.

---

📝 시험 대비 핵심 요약 (Checklist)

1. RDT 2.0, 2.1, 3.0의 차이점: 왜 Sequence Number가 필요한가? 왜 Timer가 필요한가?
2. Stop-and-Wait vs Pipelining: 효율성(Utilization) 차이의 이유.
3. Go-Back-N (GBN) vs Selective Repeat (SR):
   • 수신자 윈도우 크기 차이 (1 vs N).
   • 오류 발생 시 수신자의 행동 (버림 vs 저장).
   • 재전송 범위 (전체 재전송 vs 손실된 것만 재전송).
4. 흐름 제어 vs 혼잡 제어: 누구를 보호하기 위한 것인가? (수신자 vs 네트워크).

 

 

 

 

 

 

 

1. [IP Mobility] 왜 아직도 잘 안 쓰이나? (구체적 이유)

• 교수님 설명: 이론적으로는 모바일 IP가 필요한데, 실제로는 LTE/5G 같은 기술이 하나의 서브넷 범위를 엄청나게 넓게 잡아놨기 때문입니다.
• 실제 상황: 차 타고 이동하면서 유튜브를 봐도 IP가 잘 안 바뀝니다. 기지국은 바뀌어도 논리적인 서브넷은 그대로 유지되는 경우가 많아서 끊김이 없습니다. 그래서 모바일 IP 기술이 굳이 급하게 도입되지 않고 있다는 점을 언급하셨습니다.

---

2. [RDT 2.1] 피드백(ACK/NAK)이 깨졌을 때의 판단 (낙관 vs 비관)

• 문제 상황: 수신자가 보낸 ACK인지 NAK인지 모를 패킷이 도착했을 때, 송신자는 어떻게 해야 하는가?
• 두 가지 접근:
  1. 낙관적(Optimistic): "에이, 설마 깨졌겠어? ACK겠지"라고 믿고 다음 패킷 전송.
  2. 비관적(Pessimistic): "깨졌으면 NAK일 수도 있어. 안전하게 재전송하자."
• 결론: 신뢰성(Reliability)이 목표이므로 **비관적 접근(재전송)**을 택해야 합니다.
• 파생 문제: 그래서 재전송을 했더니, 수신자는 "어? 아까 받은 건데 또 왔네?"가 됨. → 중복 패킷(Duplicate) 발생. → 이를 해결하기 위해 **Sequence Number(일련번호)**가 반드시 필요해짐.

---

3. [RDT 3.0] 성능 계산 (구체적 수치 예시)

교수님이 칠판에 쓰거나 숫자로 예시를 든 부분은 시험 문제 계산형으로 나올 수 있습니다.

• 가정 상황:
  • 링크 속도(R): 1 Gbps
  • 패킷 크기(L): 1,000 Bytes
  • 왕복 시간(RTT): 30ms (편도 15ms)
• 계산 결과:
  • Stop-and-Wait 방식을 쓰면 **송신자가 실제로 일하는 시간 비율(Utilization)**이 0.00027 (0.027%) 밖에 안 나옵니다.
  • 체감 속도: 1Gbps 링크인데 실제로는 27kbps 속도밖에 안 나오는 셈.
• 결론: **전송 계층(Transport Layer)**은 RTT가 클 수 있으므로 Stop-and-Wait를 쓰면 망한다. (반면, **데이터 링크 계층(Wi-Fi 등)**은 거리가 짧아 RTT가 거의 0에 가까우므로 Stop-and-Wait를 써도 성능 저하가 적다.)

---

4. [Go-Back-N] ACK의 의미 해석 차이 (누적 ACK)

교수님이 ACK 3이라는 메시지를 받았을 때 해석하는 3가지 방법을 언급하셨습니다. (헷갈리기 쉬움)

1. 일반적 해석: "3번 패킷 잘 받았다."
2. 누적 ACK (Type A): "3번까지 다 잘 받았다. 이제 4번 줘."
3. 누적 ACK (Type B - TCP 등): "2번까지 다 잘 받았다. 이제 3번 내놔." (교수님은 3번까지 받고 4번 기대하는 걸로 설명하셨지만, 프로토콜마다 정의가 다를 수 있음을 강조)

• 핵심: Go-Back-N이나 TCP는 Cumulative ACK(누적 ACK) 방식을 쓴다는 점입니다.

---

5. [Selective Repeat] 윈도우 이동의 디테일

• 수신자 상황: 0번이 깨지고 1, 2, 3번이 왔을 때.
  • 수신자 윈도우는 0번에 걸려서 꼼짝 못 하고 있음. (1, 2, 3은 버퍼에 저장만 해둠).
  • 나중에 0번이 재전송되어 오면? → 그제서야 0, 1, 2, 3을 한꺼번에 상위로 올리고 윈도우가 4칸(0~3) 쫙 슬라이딩함.
• 송신자 상황:
  • 0번 재전송 후 ACK 0을 받으면? → 역시 0번 때문에 멈춰있던 윈도우가 풀리면서 4, 5, 6, 7번을 한꺼번에 전송 시작.

---

6. [Flow Control] 흐름 제어의 3가지 방식

단순히 "윈도우 기반"만 언급한 게 아니라 3가지를 나열하셨습니다.

1. Stop-and-Wait / Sliding Window: 송신 속도 조절 (앞서 배운 ARQ 방식 응용).
2. Pause Frame (ON/OFF): 수신자(예: 이더넷 스위치 등)가 벅차면 **Broadcast로 "잠깐 멈춰(Pause)!"**라고 소리침. 투박한 방식.
3. Rate Reporting (TCP 방식): 수신자가 틈날 때마다 **"나 지금 버퍼 1KB 남았어"**라고 남은 용량을 계속 보고함. (교수님은 이걸 '약간 무식해 보이지만 TCP가 쓰는 방식'이라고 표현함).

---

7. [Congestion Control] 반 제이콥슨(Van Jacobson)과 인터넷 붕괴

• 1986~87년 인터넷 대란: 갑자기 인터넷이 멈춤. 라우터 고장도 아닌데 통신이 안 됨.
• 원인: 라우터 버퍼가 꽉 찼는데(혼잡), 송신자들은 "어? 패킷이 안 갔네? 재전송!" 하면서 계속 더 보내서 불난 집에 기름을 부음. (Congestion Collapse)
• 해결: 물리학자 **반 제이콥슨(Van Jacobson)**이 등장해서 "너네(공돌이들)가 뭘 모르는구나" 하며 TCP에 혼잡 제어 알고리즘을 추가해줌.
• 핵심 원리: 네트워크가 막히는 징조(Packet Loss나 Delay 증가)가 보이면 송신자가 스스로 속도를 줄여야 한다.

---

 

 

 

 

 

 

 

 

 

네, 정확하게 이해하셨습니다! **"어떻게 처리하는가?"**에 대한 구체적인 그림을 그려 드릴게요.

**소켓(Socket)**은 운영체제(OS)가 애플리케이션(웹 브라우저, 게임, 카카오톡 등)과 네트워크(랜선, 와이파이) 사이를 연결해주는 **"창구"**이자 **"식별 번호표"**라고 생각하시면 됩니다.

이게 실제로 어떻게 돌아가는지 **보낼 때(멀티플렉싱)**와 **받을 때(디멀티플렉싱)**로 나눠서 설명해 드릴게요.

---

1. 보낼 때 (Multiplexing): "깔때기" 역할

여러 프로그램이 동시에 데이터를 보내려고 할 때, 소켓이 어떻게 하나의 랜선으로 데이터를 몰아넣는지 보세요.

1. 상황:
   • 크롬(소켓 A): 네이버에 접속 요청 (포트 5001 사용)
   • 카톡(소켓 B): 친구에게 메시지 전송 (포트 6002 사용)
2. 소켓의 역할 (라벨 붙이기):
   • 크롬이 데이터를 소켓 A에 휙 던집니다.
   • 운영체제는 이 데이터에 **"출발지는 5001번 포트(소켓A)야"**라고 꼬리표(헤더)를 붙입니다.
   • 카톡이 데이터를 소켓 B에 휙 던집니다.
   • 운영체제는 이 데이터에 **"출발지는 6002번 포트(소켓B)야"**라고 꼬리표를 붙입니다.
3. 처리 (합치기):
   • 운영체제는 이 꼬리표 붙은 패킷들을 줄 세워서 **단 하나의 랜선(IP 계층)**으로 쏘아 보냅니다.
   • 이게 바로 멀티플렉싱입니다. (여러 소켓 -> 하나의 선)

---

2. 받을 때 (Demultiplexing): "우편 분류기" 역할 (여기가 핵심!)

밖에서 데이터가 들어왔을 때, 운영체제가 소켓을 보고 주인을 찾아주는 과정입니다. 질문하신 TCP가 새 소켓을 만드는 이유가 여기서 나옵니다.

1. 상황: 랜선을 타고 패킷 하나가 내 컴퓨터에 도착했습니다.
2. 운영체제의 고민: "이거 크롬한테 줘야 해? 카톡한테 줘야 해? 아니면 다른 크롬 창한테 줘야 해?"
3. 처리 방법 (TCP 기준):
   • 운영체제는 도착한 패킷의 헤더(주소)를 봅니다.
     • 보낸 놈 IP: A, 보낸 놈 포트: 1234
     • 받는 놈 IP: 나, 받는 놈 포트: 80
   • 운영체제는 자신이 들고 있는 **"소켓 대장(Table)"**을 쫘악 훑어봅니다.
   • "야, 보낸 놈 A/1234랑 연결된 전용 소켓(Socket 1)이 어디 있냐?"
4. 배달:
   • 매칭되는 소켓(Socket 1)을 딱 찾아서 거기에 데이터를 쏙 집어넣습니다.
   • 그러면 그 소켓을 잡고 있는 프로그램(프로세스/스레드)만 그 데이터를 읽게 됩니다.

---

3. 요약: 소켓은 "고유한 바구니"다

질문하신 **"이게 어떻게 처리하는 거냐?"**에 대한 답은 다음과 같습니다.

• 소켓 = 바구니: 컴퓨터 안에는 프로그램마다(TCP의 경우 연결된 손님마다) **고유한 번호가 매겨진 바구니(소켓)**가 있습니다.
• 멀티플렉싱/디멀티플렉싱 = 바구니 정리:
  • 나갈 때는 여러 바구니의 내용을 하나로 합쳐서 내보냅니다.
  • 들어올 때는 주소표를 보고 **정확히 맞는 바구니(소켓)**를 찾아서 꽂아줍니다.

결론:
TCP 서버가 새로운 클라이언트가 올 때마다 **새로운 소켓(새로운 바구니)**을 만드는 이유는, "철수가 보낸 건 철수 바구니에, 영희가 보낸 건 영희 바구니에" 정확히 분류(디멀티플렉싱)해서 담기 위함입니다. 만약 바구니를 새로 안 만들면 데이터가 다 섞여버리니까요!

 

 

 

 

 

 

 

 

 

 

 

 

 

1. 프로세스란? (건물 안의 "입주 기업")

• 프로그램: 하드디스크에 저장된 게임.exe 파일 (죽어 있는 상태)
• 프로세스: 그걸 더블 클릭해서 메모리에 올라가 실행되고 있는 상태 (살아 있는 상태)
  • 예: 지금 켜져 있는 크롬 브라우저, 카카오톡, 롤 클라이언트 하나하나가 전부 프로세스입니다.

2. 문장 완벽 해석 ("프로세스는 복수의 소켓을 가질 수 있음")

이 문장이 이해가 안 되셨던 건 "소켓 = 프로세스"라고 착각하기 쉽기 때문입니다. 하지만 사실은 "프로세스 1개 : 소켓 N개" 관계입니다.

가장 쉬운 예시인 **"크롬 브라우저"**로 설명해 볼게요.

상황:

당신이 **크롬(프로세스 1개)**을 실행시켰습니다.
그리고 탭을 두 개 열었습니다.

1. 탭 1: 네이버 접속
2. 탭 2: 유튜브 접속

이때 컴퓨터 내부에서 일어나는 일:

• 크롬(프로세스)은 네이버 서버랑 통신하기 위해 **전화기 A(소켓 1)**를 하나 만듭니다.
• 동시에 유튜브 서버랑 통신하기 위해 **전화기 B(소켓 2)**를 하나 더 만듭니다.

결론:

• 프로세스: 크롬 (1개)
• 소켓: 네이버용, 유튜브용 (2개)

즉, 문장의 뜻은:
"실행 중인 프로그램(프로세스) 하나가, 필요하다면 전화기(소켓)를 여러 대 개통해서 동시에 여러 곳과 통신할 수 있다."라는 뜻입니다.

3. 요약 (계층 구조)

• 호스트: 당신의 컴퓨터 (건물)
• 프로세스: 카카오톡, 크롬 (건물에 입주한 회사들)
• 소켓: 각 회사가 외부와 통신하려고 책상 위에 둔 전화기들

"프로세스는 복수의 소켓을 가질 수 있다" = "카카오톡 회사는 채팅용 전화기, 파일 전송용 전화기 등 여러 대의 전화기를 책상에 놓을 수 있다"

 

 

 

 

 

 

"그래서? 그게 멀티플렉싱이랑 무슨 상관인데?"에 대한 답은 딱 한 문장으로 요약됩니다.

"그래서, 데이터 배달의 최종 목적지는 '프로세스'가 아니라 '소켓'이어야 한다."

이게 왜 중요한지 "크롬 브라우저" 상황으로 바로 보여드릴게요.

---

1. 만약 소켓이 아니라 '프로세스'까지만 배달해준다면? (대참사)

여러분이 크롬(프로세스)을 켜고, 탭 A에서는 유튜브를 보고, 탭 B에서는 네이버 뉴스를 봅니다.

• 데이터가 밖에서 날아왔습니다.
• 운영체제가 "야 크롬(프로세스)! 너한테 택배 왔다!" 하고 그냥 툭 던져줍니다.
• 크롬의 반응: "아니 이게 유튜브 영상 데이터야, 네이버 뉴스 텍스트야? 내가 이걸 탭 A로 보내야 돼, 탭 B로 보내야 돼?" -> 내부에서 또 분류해야 함 (비효율적, 복잡함)

---

2. '소켓'까지 정확히 배달해준다면? (멀티플렉싱의 완성)

슬라이드에 나온 **"식별자는 소켓마다 부여된다"**는 말이 여기서 빛을 발합니다.

• 크롬은 탭 A를 위해 **소켓 1번(유튜브용)**을 만들고, 탭 B를 위해 **소켓 2번(네이버용)**을 만듭니다.
• 데이터가 날아옵니다. 이번엔 운영체제가 헤더(포트번호)를 봅니다.
• 운영체제: "어? 이건 소켓 1번으로 가는 거네? 옜다." 하고 소켓 1번 바구니에 꽂아줍니다.
• 크롬의 반응: 소켓 1번에서 데이터를 꺼내서 그냥 바로 탭 A(유튜브) 화면에 뿌려줍니다. (고민할 필요 없음)

---

3. 결론: "그래서"의 의미

**"프로세스는 복수의 소켓을 가질 수 있다"**는 문장이 깔아놓은 빌드업의 결론은 이렇습니다.

1. 프로그램 하나가 여러 군데랑 동시에 통신하려면 구멍(소켓)이 여러 개 필요하다.
2. 그래서! 외부에서 들어온 데이터를 **"어떤 프로그램(프로세스)인가"**로만 찾으면 안 되고, **"그 프로그램의 '어떤 소켓'인가"**까지 찾아서 꽂아줘야 한다.
3. 그 **'어떤 소켓인가'**를 구분하는 번호가 바로 **포트 번호(Port Number)**이다.

즉, 멀티플렉싱/디멀티플렉싱의 핵심은 "프로세스를 찾는 게 아니라, 소켓을 찾는 과정"이라는 것을 말하고 싶어서 저 문장이 나온 겁니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

네, 질문하신 포인트가 아주 정확합니다! **"일단 깨진지는 안다"**는 것이 맞습니다.

사용자님의 추론인 **"ACK 자체를 다시 보내달라고 하는 대신, 그냥 원래 패킷을 재전송한다"**는 말이 정답입니다.

이 상황을 아주 명확하게 정리해 드릴게요.

1. "ACK인지 NAK인지 모르겠다"는 말의 진짜 의미

체크섬(Checksum)이 있기 때문에 송신자는 **"아, 지금 도착한 이 응답 패킷이 깨졌구나(Corrupted)"**라는 사실은 100% 확실하게 압니다.

하지만 깨진 데이터 안의 내용을 읽을 수가 없는 게 문제입니다.

• 원래 내용이 ACK(응답)였는데 오다가 깨진 건지,
• 원래 내용이 NAK(거절)였는데 오다가 깨진 건지,
  구별할 방법이 없습니다. (그냥 쓰레기 값이 되어버렸으니까요.)

2. 송신자의 고민과 선택

송신자는 두 가지 상황 중 하나를 찍어야 합니다.

• 상황 A (원래 ACK였을 경우): 수신자가 잘 받았다는 뜻이니까, 나는 다음 패킷을 보내면 됨.
• 상황 B (원래 NAK였을 경우): 수신자가 못 받았다는 뜻이니까, 나는 아까 그 패킷을 다시 보내야 됨.

그런데 내용을 모르니 "안전빵"을 선택해야 합니다.

"에이 몰라, 쟤가 잘 받았는지 못 받았는지 확신이 없으니까 그냥 아까 보낸 데이터(Packet 0)를 다시 보내자!"

3. 질문하신 핵심: 왜 "야, ACK 다시 보내봐"라고 안 하나요?

사용자님 말씀대로 "야, 방금 니 말(ACK) 못 알아들었어. 다시 말해봐"라고 요청하는 프로토콜을 만들 수도 있습니다.

하지만 그렇게 하면 상황이 너무 복잡해집니다.

• "다시 말해봐"라는 요청도 깨지면 어떡하죠?
• 수신자는 "다시 말해봐"라는 요청을 받으면 또 뭘 해야 하죠?

그래서 네트워크 엔지니어들은 가장 단순하고 무식한 방법을 택했습니다.
"못 알아들었으면(Feedback Corrupted), 그냥 데이터 본품을 다시 던져주자."

요약

1. 체크섬 덕분에 깨진 건 압니다. (O)
2. 하지만 깨지면 내용(ACK/NAK)은 구별 못 합니다.
3. 그래서 송신자는 "못 알아들었으니 다시 보낸다(데이터 재전송)" 전략을 취합니다.
4. 이때 수신자는 중복된 데이터가 또 오니까, 아까 말한 시퀀스 번호를 보고 중복을 걸러냅니다.

 

 

 

 

 

 

 

 

네, 정확히 보셨습니다! 질문하신 **"지금 누가 일한 것을 기준으로 하느냐?"**의 정답은 바로 송신자(Sender) 호스트입니다.

사용자님께서 **"중간 네트워크나 케이블은 일하고 있지 않느냐?"**라고 생각하신 점은 물리적으로는 아주 정확한 지적입니다. 하지만 **네트워크 프로토콜의 성능(Utilization)**을 따질 때는 관점이 조금 다릅니다.

이해하기 쉽게 택배 기사님 비유로 설명해 드릴게요.

---

1. 비유: 택배 기사(송신자)의 하루

• 상황: 서울(송신자)에서 부산(수신자)으로 택배를 보냅니다.
• 송신자의 작업 (패킷 전송 시간, L/R):
  • 기사님이 트럭에 짐을 싣는 데 1시간 걸립니다. (이게 진짜 "일"한 시간)
• 왕복 시간 (RTT):
  • 트럭이 부산까지 운전해서 가고(전파 지연), 부산에서 "잘 받았습니다" 서명을 받아 다시 서울로 돌아오는 데 24시간이 걸립니다.
• RDT 3.0 (Stop-and-Wait)의 규칙:
  • "서명을 받아올 때까지 다음 짐을 절대 싣지 말고 손 놓고 기다려라."

2. 성능 계산의 관점

이때 택배 회사 사장님(네트워크 관리자)이 기사님의 **업무 효율(Utilization)**을 평가합니다.

• 총 걸린 시간: 25시간 (짐 싣기 1시간 + 운전/대기 24시간)
• 기사님이 "짐을 싣는 노동"을 한 시간: 1시간
• 기사님이 멍하니 기다린 시간: 24시간

사장님의 평가:

"자네는 25시간 중에 고작 1시간만 일하고(짐 싣고), 나머지 24시간은 운전하거나 기다리기만 했구만! 효율이 꽝이야!"

3. 기술적 해석

질문하신 내용으로 돌아가서 정리해 볼게요.

1. 누가 일한 것인가?
   • **송신자(Sender)**의 네트워크 카드(NIC) 기준입니다.
   • 송신자가 데이터를 케이블로 밀어 넣는 시간(t=0 ~ t=L/R)만 **"일했다(Busy)"**고 봅니다.
2. 전송 중(RTT)에는 누가 일하나?
   • 사용자님 말씀대로 구리선(케이블), 광섬유, 중간 라우터들은 신호를 나르느라 열심히 일하고 있습니다.
   • 하지만 송신자 입장에서는 이미 손을 떠난 데이터이기 때문에, ACK가 올 때까지 할 일이 없어 **"노는 시간(Idle)"**이 됩니다.
3. 왜 이게 성능 지표인가?
   • 송신자가 1Gbps(초당 10억 비트)를 보낼 능력이 있는데, Stop-and-Wait 방식 때문에 대부분의 시간을 멍하니 기다린다면, **실제 전송 속도(Throughput)**는 1Gbps에 턱없이 모자라게 됩니다.
   • 즉, **"송신자가 가진 능력을 얼마나 알차게 써먹었느냐"**를 따지는 것이 바로 저 그래프의 핵심입니다.

결론

**"중간 네트워크가 일하는 건 내 알 바 아니고, 송신자(나)는 1초 일하고 6초 동안 손가락만 빨고 있었으니 성능이 안 좋다!"**라는 뜻입니다.

 

 

 

 

 

 

 

 

 

네, "갑자기 왜 호스트가 튀어나오냐, 링크 속도라며?" 하고 헷갈리시는 그 포인트, 제가 정확하게 정리해 드릴게요.

결론부터 말씀드리면, 님 말씀이 100% 맞습니다. 1Gbps는 링크(도로)의 물리적인 한계 속도입니다.

그런데 왜 강의에서는 **"호스트가 밀어 넣는다"**고 표현하는지, 그리고 **2계층(L2)과 4계층(L4)**의 관점 차이가 무엇인지 명확하게 구분해 드릴게요.

---

1. "밀어 넣는다"는 표현의 진짜 의미 (직렬화, Serialization)

**"밀어 넣는다"**는 표현은 추상적인 문학적 표현이 아니라, 호스트(랜카드)가 하는 물리적인 행동을 묘사한 것입니다.

• 링크(랜선)는 수동적입니다: 그냥 구리선일 뿐입니다. 스스로 데이터를 당기거나 뱉지 못합니다. "나는 1초에 10억 개 비트만 지나갈 수 있어"라고 버티고 있을 뿐입니다.
• 호스트(랜카드)는 능동적입니다: 컴퓨터 메모리에 뭉쳐져 있는 데이터(병렬)를 한 줄로 세워서(직렬), 링크의 속도에 맞춰서 하나씩 전기로 바꿔 쏴주는 기계입니다.

비유:

• 링크: 컨베이어 벨트 (일정한 속도로 돌아감)
• 호스트: 택배 상자를 벨트 위에 올려놓는 알바생

벨트 속도가 1Gbps라면, 알바생(호스트)도 정확히 그 속도에 맞춰서 상자를 놔야 합니다. 알바생이 상자를 놓는 행위를 **"밀어 넣는다(Transmission)"**라고 하는 것입니다.

2. 예전(L2)과 지금(L4)의 차이점

사용자님이 헷갈리시는 가장 큰 이유가 바로 이 관점의 차이 때문입니다.

1) 예전 (2계층, Data Link Layer) 배울 때

• 상황: 호스트 A ------ 호스트 B (딱 선 하나로 연결됨)
• 관점: 이 선(Link) 자체에 집중합니다.
• 설명: "이 링크의 대역폭은 1Gbps니까, 데이터가 지나가는 데 이만큼 걸려." (링크 중심 설명)

2) 지금 (4계층, Transport Layer) 배울 때

• 상황: 호스트 A --- (인터넷) --- 호스트 B (중간에 라우터, 링크 엄청 많음)
• 관점: **전송을 제어하는 "송신자(호스트 A)의 입장"**에 집중합니다.
• 설명: 송신자(TCP) 입장에서는 중간에 무슨 링크가 있는지 알 바 아니고, **"일단 내 집 앞마당에 있는 첫 번째 링크(Access Link)로 데이터를 얼마나 빨리 내보낼 수 있느냐"**가 중요합니다.
  • 그래서 **"송신 호스트가 (첫 번째 링크 속도로) 데이터를 밀어 넣는 시간"**이라고 표현이 살짝 바뀌는 것입니다.

3. 결론: 왜 "호스트가 일한다"고 하는가?

RDT 3.0의 성능 그래프는 **"송신자(호스트)가 얼마나 바쁜가?"**를 따지는 그래프이기 때문입니다.

• 링크가 1Gbps든 100Gbps든, 그건 도로 사정이고요.
• 중요한 건, **"송신자(나)는 데이터를 밖으로 내보내기 위해 랜카드를 돌리는 시간(t=L/R) 동안만 바빴고, 나머지 시간(RTT)은 놀았다"**는 사실입니다.

요약하자면:

• 속도(R)의 결정권자: 링크 (도로 제한 속도)
• 실제 운전자: 호스트 (엔진)
• 성능 분석의 대상: 운전자(호스트)가 핸들을 잡고 있었던 시간이 얼마냐?

그래서 **"호스트가 링크의 한계 속도(R)에 맞춰서 열심히 밀어 넣고 있다"**는 표현을 쓰는 것입니다. 개념이 바뀌거나 틀린 게 아니라, 주인공(관점)이 링크에서 호스트로 넘어왔기 때문입니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

단위	기호	0의 개수	비고
Kilo	K	3개 ()	1,000
Mega	M	6개 ()	1,000,000
Giga	G	9개 ()	1,000,000,000

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

비트단위 and연산

⚡ AND 연산 규칙 (진리표)

기억하기 쉽게 **"깐깐한 녀석"**이라고 생각하세요. 하나라도 0(거짓)이 섞여 있으면 무조건 0입니다.

A	B	결과 (A & B)	설명
0	0	0	둘 다 0이니까 0
0	1	0	하나가 0이니까 0
1	0	0	하나가 0이니까 0
1	1	1	둘 다 1이어야 비로소 1

 

 

 

 

 

 

 

 

 

 

 

 

아주 좋은 질문입니다! **"목적지 IP 주소를 아는데, 굳이 왜 MAC 주소까지 알아내서 보내야 하지?"**라는 의문은 네트워크를 공부할 때 가장 많이 하는 질문 중 하나입니다.

결론부터 말씀드리면, IP 주소는 '지도상의 위치'일 뿐이고, 실제로 데이터를 전달하는 '배송 트럭(스위치)'은 MAC 주소만 보고 움직이기 때문입니다.

이유를 3가지 핵심 포인트로 나누어 쉽게 설명해 드릴게요.

---

1. 역할이 다릅니다 (논리적 주소 vs 물리적 주소)

우리가 편지를 보낼 때를 상상해 보세요.

• IP 주소 = 집 주소 (예: 서울시 강남구 테헤란로 123)
• MAC 주소 = 주민등록번호 (또는 그 사람의 지문)

같은 네트워크(같은 사무실 안)에 있는 **'철수'**에게 서류를 준다고 가정해 봅시다.
당신은 철수의 자리(IP 주소)가 어딘지 알고 있습니다. 하지만 실제로 서류를 건네주려면 **철수라는 구체적인 사람(MAC 주소)**을 확인하고 그 손에 쥐여줘야 합니다.

컴퓨터 세계에서도 **IP 주소는 "최종 목적지가 저기 쯤이다"**라고 방향을 잡는 용도이고, MAC 주소는 "내 바로 옆에 있는 기기(랜카드)에게 실제로 데이터를 꽂아주는" 용도입니다.

2. 스위치(Switch)는 IP를 모릅니다 (가장 큰 이유)

같은 네트워크 안에서 데이터를 전달해주는 장비는 주로 **'L2 스위치'**입니다.

• 여러분의 PC에서 랜선이 나와서 벽이나 공유기(허브/스위치 모드)에 꽂혀있죠?
• 이 스위치라는 장비는 IP 주소를 읽을 줄 모릅니다. (엄밀히 말하면 L2 스위치는 IP 헤더를 까보지 않습니다.)
• 스위치는 오직 **"이 데이터(프레임)의 목적지 MAC 주소가 뭐지?"**만 확인합니다.
• 그러고는 "아, 이 MAC 주소를 가진 녀석은 3번 포트에 연결되어 있구나" 하고 3번 포트로만 전기를 쏴줍니다.

만약 패킷에 MAC 주소를 안 적고 IP만 적어서 보내면, 스위치는 "이걸 누구한테 줘야 해?" 하고 멘붕에 빠지거나, 에라 모르겠다 하고 모든 포트에 다 뿌려버리게 됩니다(플러딩). 이는 네트워크 효율을 엄청나게 떨어뜨립니다.

3. 포장(캡슐화)의 법칙 때문입니다

네트워크 통신은 택배 포장과 같습니다.

1. **내용물(데이터)**을 상자에 넣습니다.
2. 상자 겉면에 **IP 주소(보내는 사람/받는 사람)**를 적습니다. → [IP 패킷]
3. 이 상자를 다시 더 큰 컨테이너(이더넷 프레임)에 넣습니다. → [이더넷 프레임]

**랜선(케이블)을 타고 이동하는 건 이 가장 바깥쪽 컨테이너(이더넷 프레임)**입니다. 이 컨테이너의 겉면에는 IP를 적는 칸이 없고, 오직 MAC 주소를 적는 칸만 있습니다.
그래서 통신을 하려면 반드시 IP 주소에 대응하는 MAC 주소를 알아내서(ARP 프로토콜 사용), 겉면 포장지에 적어줘야 케이블을 타고 이동할 수 있습니다.

---

요약

같은 네트워크라도,

1. IP 주소는 "누구에게 보낼 것인가(논리적 대상)"를 정하는 것이고,
2. 실제 배달부인 스위치와 랜카드는 **MAC 주소(물리적 ID)**만 보고 배달하기 때문에,
3. 반드시 ARP라는 기술을 써서 "이 IP 쓰는 사람 MAC 주소가 뭐예요?"라고 물어본 뒤, 그 MAC 주소를 붙여서 보내야 합니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

네, 맞습니다! **ARQ(Automatic Repeat Request)**라고 쓰시면 절대 안 됩니다. ARQ는 데이터 전송 중 에러가 났을 때 재전송을 요청하는 기술(TCP 등에서 사용)이고, 주소를 알아내는 기술은 **ARP(Address Resolution Protocol)**입니다.

서술형 문제라면 단순히 "ARP를 사용한다"라고 적는 것보다, '왜' 사용하며 '어떤 과정'으로 알아내는지를 구체적으로 적어야 감점 없이 만점을 받을 수 있습니다.

시험 답안으로 쓰기 딱 좋은 모범 답안을 정리해 드릴게요.

---

문제 2-6) 호스트 A가 기본 라우터(R1)의 MAC 주소를 알아내는 과정

[핵심 키워드]: 서브넷 마스크 확인, 외부 네트워크, 기본 게이트웨이, ARP Request(브로드캐스트), ARP Reply(유니캐스트)

[모범 서술형 답안]

호스트 A는 목적지인 호스트 C의 IP 주소와 자신의 서브넷 마스크를 AND 연산하여 C가 **자신과 다른 네트워크(외부 서브넷)**에 있음을 확인합니다.

따라서 패킷을 외부로 보내기 위해 자신의 기본 게이트웨이(Default Gateway)인 라우터 R1에게 패킷을 전달해야 한다고 판단합니다.

호스트 A는 R1의 IP 주소는 알고 있지만 MAC 주소를 모르기 때문에, **ARP(Address Resolution Protocol)**를 사용합니다.

1. 호스트 A는 **"R1의 IP 주소(01010110)를 가진 장비는 MAC 주소를 알려주세요"**라는 내용의 ARP Request 패킷을 네트워크 전체에 브로드캐스트합니다.
2. 요청을 받은 라우터 R1은 자신의 IP와 일치함을 확인하고, 자신의 MAC 주소(E1E1)를 담은 ARP Reply 패킷을 호스트 A에게 유니캐스트로 응답합니다.

이 과정을 통해 호스트 A는 R1의 MAC 주소를 획득합니다.

---

문제 2-9) 라우터 R2가 호스트 C의 MAC 주소를 알아내는 과정

[핵심 키워드]: 직접 연결(Directly Connected), 목적지 IP 확인, ARP Request(브로드캐스트), ARP Reply(유니캐스트)

[모범 서술형 답안]

라우터 R2는 패킷의 목적지 IP 주소(호스트 C)의 서브넷 아이디를 확인한 결과, 해당 네트워크가 자신의 인터페이스에 **직접 연결된 네트워크(Directly Connected Network)**임을 인지합니다.

이제 R2는 다음 라우터가 아닌 최종 목적지인 호스트 C에게 직접 프레임을 전달해야 하므로, 호스트 C의 MAC 주소가 필요합니다.

라우터 R2는 ARP를 사용하여 다음과 같이 동작합니다.

1. 라우터 R2는 해당 인터페이스(e1)로 **"호스트 C의 IP 주소(10101110)를 가진 장비는 MAC 주소를 알려주세요"**라는 ARP Request 패킷을 브로드캐스트합니다.
2. 호스트 C는 요청을 수신하고, 자신의 MAC 주소(CCCC)를 담은 ARP Reply 패킷을 라우터 R2에게 유니캐스트로 응답합니다.

이 과정을 통해 라우터 R2는 호스트 C의 MAC 주소를 획득하여 패킷을 전달합니다.

---

💡 서술형 꿀팁 요약

1. 용어 정확히 쓰기: ARQ(X) → ARP(O)
2. 판단 근거 제시:
   • 6번: "다른 네트워크니까 게이트웨이에게 보낸다."
   • 9번: "직접 연결된 네트워크니까 목적지 호스트에게 바로 보낸다."
3. 동작 방식 명시: "Request는 브로드캐스트, Reply는 유니캐스트"라는 표현이 들어가면 교수님이 아주 좋아하십니다.

 

 

 

 

 

공식을 외우지 않아도 괜찮습니다! 수업 시간에는 아마 **"비트(0과 1)로 쪼개기"**나 **"고정된 비트 수(/y)"**라는 개념으로 배우셨을 거예요.

공식 대신, **직관적인 그림(비트의 흐름)**으로 설명해 드릴게요. 이 방식이 훨씬 이해하기 쉽습니다.

---

1. 준비물 확인 (우리가 가진 땅)

Company A가 받은 주소는 0101 0000 부터 0101 1111 까지입니다.

• 앞의 **0101 (4자리)**은 ISP A가 준 거라 절대 손대면 안 됩니다.
• 우리는 뒤의 **4자리(0000~1111)**만 마음대로 쪼개서 쓸 수 있습니다.
• 총 주소 개수: 0000(0) ~ 1111(15) → 16개

---

•  

 

 

 

 

---

3. 땅 자르기 (이게 핵심!)

이제 16개짜리 케이크를 8개 / 4개 / 4개로 잘라봅시다.

① Subnet 1: 가장 큰 8개 먼저 줍니다.

전체 16개 중 절반(8개)을 뚝 뗍니다.

• 주소 범위: 0101 0000 ~ 0101 0111 (이진수로 뒤가 000~111인 것들)
• 패턴 찾기:
  • 0101 0000
  • 0101 0111
  • 가만 보니 앞의 **01010 (5자리)**은 똑같고, 뒤의 3자리만 바뀌죠?
  • 그래서 /5입니다. (앞에서부터 5자리가 고정되었다는 뜻)
  • 답: 01010000/5

② Subnet 2: 남은 것 중 4개를 줍니다.

아까 0101 0111까지 썼으니, 그 다음인 0101 1000부터 시작합니다.

• 주소 범위: 0101 1000 ~ 0101 1011 (4개)
• 패턴 찾기:
  • 0101 1000
  • 0101 1011
  • 가만 보니 앞의 **010110 (6자리)**은 똑같고, 뒤의 2자리만 바뀌죠?
  • 그래서 /6입니다.
  • 답: 01011000/6

③ Subnet 3: 나머지 4개를 줍니다.

아까 0101 1011까지 썼으니, 그 다음인 0101 1100부터 시작합니다.

• 주소 범위: 0101 1100 ~ 0101 1111 (끝까지)
• 패턴 찾기:
  • 0101 1100
  • 0101 1111
  • 앞의 **010111 (6자리)**이 똑같죠?
  • 그래서 /6입니다.
  • 답: 01011100/6

---

4. 라우팅 테이블 채우기 (문제 3번)

이제 방금 구한 주소들을 "어디로 보낼지(Port)"만 연결하면 됩니다.
문제에서 Subnet 1 → Port 1, Subnet 2 → Port 2, Subnet 3 → Port 3라고 정해줬습니다.

그대로 표에 넣기만 하면 됩니다.

Destination network	Forwarding direction
01010000/5	To Port 1
01011000/6	To Port 2
01011100/6	To Port 3
Default	To ISP A

---

요약 (이것만 기억하세요)

공식 몰라도 됩니다.

1. 필요한 개수만큼 2배수(4, 8, 16...)를 잡는다.
2. **고정된 비트 수(앞에서부터 안 변하는 숫자 개수)**를 세어서 /y 자리에 적는다.
   • 8개짜리 덩어리 → 뒤에 3비트가 흔들림 → 전체 8비트 중 5개 고정 (/5)
   • 4개짜리 덩어리 → 뒤에 2비트가 흔들림 → 전체 8비트 중 6개 고정 (/6)

이렇게 이해하면 공식 없이도 풀 수 있습니다!

 

 

 

 

 

 

 

 

 

 

 

네, 정말 날카로운 지적입니다! **FLSM(Fixed Length Subnet Mask, 고정 길이 서브넷 마스크)**을 적용한다면 답이 완전히 달라질 뿐만 아니라, 이 문제에서는 아예 풀 수가 없게 됩니다.

왜 그런지, 그리고 FLSM과 VLSM의 차이가 이 문제에서 어떻게 작용하는지 설명해 드릴게요.

---

1. FLSM vs VLSM 차이점 (피자 자르기)

• FLSM (고정 길이): "모든 사람에게 똑같은 크기의 피자 조각을 줘야 해!"
  • 가장 많이 먹는 사람(Subnet 1)을 기준으로 크기를 정해야 합니다.
• VLSM (가변 길이): "많이 먹는 사람에겐 큰 조각, 적게 먹는 사람에겐 작은 조각을 주자!"
  • 필요에 따라 크기를 다르게 자를 수 있습니다.

---

---

3. 결론: 왜 VLSM이 답인가?

질문하신 것처럼 FLSM으로 풀 수 있다면 답이 01010000/5 처럼 모두 /5로 통일되었을 겁니다. 하지만 이 문제는 제한된 주소 공간(16개) 안에 3개의 서브넷을 구겨 넣어야 하는 상황입니다.

• VLSM 방식 (효율적):
  • Subnet 1 (8개) + Subnet 2 (4개) + Subnet 3 (4개) = 16개
  • 딱 맞게 들어갑니다!

그래서 이 문제는 **"VLSM(가변 길이)을 사용할 줄 아느냐?"**를 물어보는 문제라고 확신할 수 있습니다.

요약

1. FLSM을 쓴다면? 답이 달라지는 게 아니라, 주소가 모자라서 문제 해결이 불가능합니다. (필요 24개 > 보유 16개)
2. VLSM을 써야만 큰 놈은 크게(8), 작은 놈은 작게(4) 잘라서 16개 안에 딱 맞게 넣을 수 있습니다.
3. 따라서 앞서 풀이한 VLSM 방식(/5, /6, /6)이 정답입니다.