<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>opentime_kr.log</title>
        <link>https://velog.io/</link>
        <description>버그와 싸우며 성장 중인 IT 공대생</description>
        <lastBuildDate>Tue, 02 Jun 2026 10:54:16 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <image>
            <title>opentime_kr.log</title>
            <url>https://velog.velcdn.com/images/opentime_kr/profile/1ea7cbc5-a101-426f-a992-3d8b3fac2a13/social_profile.jpeg</url>
            <link>https://velog.io/</link>
        </image>
        <copyright>Copyright (C) 2019. opentime_kr.log. All rights reserved.</copyright>
        <atom:link href="https://v2.velog.io/rss/opentime_kr" rel="self" type="application/rss+xml"/>
        <item>
            <title><![CDATA[# [개발일지] useEffect 지옥에서 TanStack Query v5까지, AI 에듀테크 플랫폼 AI ExamGenerator 빌드 및 튜닝 기록]]></title>
            <link>https://velog.io/@opentime_kr/%EA%B0%9C%EB%B0%9C%EC%9D%BC%EC%A7%80-useEffect-%EC%A7%80%EC%98%A5%EC%97%90%EC%84%9C-TanStack-Query-v5%EA%B9%8C%EC%A7%80-AI-%EC%97%90%EB%93%80%ED%85%8C%ED%81%AC-%ED%94%8C%EB%9E%AB%ED%8F%BC-AI-ExamGenerator-%EB%B9%8C%EB%93%9C-%EB%B0%8F-%ED%8A%9C%EB%8B%9D-%EA%B8%B0%EB%A1%9D</link>
            <guid>https://velog.io/@opentime_kr/%EA%B0%9C%EB%B0%9C%EC%9D%BC%EC%A7%80-useEffect-%EC%A7%80%EC%98%A5%EC%97%90%EC%84%9C-TanStack-Query-v5%EA%B9%8C%EC%A7%80-AI-%EC%97%90%EB%93%80%ED%85%8C%ED%81%AC-%ED%94%8C%EB%9E%AB%ED%8F%BC-AI-ExamGenerator-%EB%B9%8C%EB%93%9C-%EB%B0%8F-%ED%8A%9C%EB%8B%9D-%EA%B8%B0%EB%A1%9D</guid>
            <pubDate>Tue, 02 Jun 2026 10:54:16 GMT</pubDate>
            <description><![CDATA[<ul>
<li><strong>서비스 URL</strong>: <a href="https://ai-examgenerator.co.kr/">https://ai-examgenerator.co.kr/</a></li>
<li><strong>운영 인프라</strong>: Naver Cloud Platform (VPC, s2-g3a 인스턴스) 기반 무중단 운영</li>
<li><strong>기술 스택 총괄</strong>: FastAPI + React 19 (TypeScript) + Redis Queue + PostgreSQL</li>
</ul>
<h2 id="1-들어가며-왜-프로덕션을-다시-뜯어고쳤는가">1. 들어가며: 왜 프로덕션을 다시 뜯어고쳤는가</h2>
<p>기존에 가동되던 MVP(최소 기능 제품) 모델은 &#39;기능의 작동&#39; 측면에서는 문제가 없었다. PDF를 올리면 문제가 추출되었고, 버튼을 누르면 시험지가 만들어졌다. 하지만 실제 유저(학원 강사 및 교육자)들이 유입되어 장시간 화면 체류를 하며 수십 개의 시험지를 동시에 편집하고, AI 변형 문제를 대량으로 생성하기 시작하자 숨겨져 있던 아키텍처적 한계와 병목이 무더기로 쏟아졌다.</p>
<p>가장 큰 문제는 장시간 텍스트와 지문을 읽어야 하는 교육 플랫폼의 도메인 특성을 간과한 다크 네이비 테마(#050A14)였다. 개발자에게는 익숙할지 몰라도, 한밤중에 문제 출제를 위해 화면을 째려봐야 하는 강사들에게는 눈의 피로도를 극대화하는 주범이었다. </p>
<p>여기에 프론트엔드 컴포넌트 곳곳에 하드코딩된 상태 관리와 <code>useEffect</code> 기반의 무분별한 API 요청은 서버 가용 자원을 갉아먹고 있었다. 단순한 코드 쪼개기 식의 리팩토링이 아니라, 사용자가 비용을 지불하고 쓸 만한 &#39;프리미엄 상용 서비스(Production Ready)&#39; 수준으로 인프라와 프론트엔드 데이터 흐름을 끌어올리기 위해 밤새며 진행했던 대대적인 구조 개편과 디버깅의 기록을 기술 덤프 형태로 담백하게 남겨둔다.</p>
<hr>
<h2 id="2-phase-1-비주얼-프리미엄-리디자인-및-레이아웃-패러다임-변화">2. Phase 1: 비주얼 프리미엄 리디자인 및 레이아웃 패러다임 변화</h2>
<h3 id="21-하드코딩된-스타일의-부채와-tailwind-v4-시스템화">2.1 하드코딩된 스타일의 부채와 Tailwind v4 시스템화</h3>
<ul>
<li><p><strong>문제 상황 (Problem):</strong>
초기 코드 베이스는 빠르게 화면을 뽑아내기 위해 디자인 시스템 정의 없이 작업을 진행했다. 그 결과 컴포넌트 내부 곳곳에 인라인 스타일이나 파편화된 색상값들이 무차별적으로 흩어져 있었다. 전면적인 라이트 테마(White Theme) 리뉴얼이 결정되었을 때, 이 하드코딩된 값들이 전방위적인 발목을 잡았다. 배경색 하나를 바꾸기 위해 수십 개의 파일 내부 인라인 스타일을 수동으로 전수조사해야 하는 전형적인 &#39;디자인 기술 부채&#39;였다.</p>
</li>
<li><p><strong>해결 채널 (Solution):</strong>
기존의 어두운 테마를 완전히 배제하고, 교육 플랫폼 특유의 깨끗하고 명확한 인상을 주기 위해 화이트(White) 배경과 Premium Blue (#0064FF)를 메인 브랜드 컬러로 낙점했다. 코드의 지속 가능성을 위해 Tailwind CSS v4의 @theme 지시어를 도입하여 파편화된 디자인 리소스를 전역에서 선언적으로 자산화했다.
```
[테마 선언 세부 구조]</p>
</li>
<li><p>brand-50: #EFF6FF (연한 블루 강조 배경)</p>
</li>
<li><p>brand-100: #DBEAFE (배지 및 컴포넌트 아웃라인)</p>
</li>
<li><p>brand-600: #0064FF (브랜드 메인 컬러)</p>
</li>
<li><p>brand-700: #0050CC (버튼 호버 및 액션 상태)</p>
</li>
<li><p>주 그라디언트: 135도 각도의 #0064FF에서 #7C3AED(바이올렛) 연동</p>
<pre><code>인라인으로 박혀있던 하드코딩 색상들을 bg-brand-50, text-brand-600 형태의 시맨틱 클래스로 전면 전환했다. 라이트 테마가 자칫 심심하고 평면적인 인상을 주는 문제를 해결하기 위해 UI 디테일에 입체감을 더했다. 
</code></pre></li>
</ul>
<p>주요 대시보드 카드 상단에는 h-0.5 규격의 수평 그라디언트 액센트 라인을 심어 시선이 분산되는 것을 막았고, 로그인 및 회원가입 피처 패널 배경에는 radial-gradient와 blur-3xl, opacity-40 효과를 유기적으로 조합한 배경 글로우 오브(Glow Orb) 아트를 은은하게 깔아 유저가 시각적으로 프리미엄 대시보드에 진입했다는 공간감을 연출했다.</p>
<h3 id="22-공간-확보를-위한-sidebar-제거-및-top-nav-아키텍처-전환">2.2 공간 확보를 위한 Sidebar 제거 및 Top Nav 아키텍처 전환</h3>
<ul>
<li><strong>의사결정 배경 (Background):</strong>
수능형 출제 툴의 프론트엔드가 가진 가장 독특한 제약 조건은 바로 &#39;지문(Passage)과 문항(Question)의 비대칭적 레이아웃 보장&#39;이다. 장문의 영어 독해 지문이나 복잡한 국어 비문학 지문 하나가 좌측에 배치되면, 우측에는 그 지문에 종속된 새끼 문제 2~3개가 묶음 형태로 나열되어야 한다. </li>
</ul>
<p>기존의 고정형 좌측 사이드바(Sidebar) 구조는 데스크톱 가로 화면 영역 중 무려 260px 이상을 무조건 선점하고 시작했기에, 정작 중요한 시험지 편집기(ExamBuilderPage) 화면에서 지문 카드와 문제 카드가 가로로 찌그러지며 극심한 레이아웃 붕괴를 유발했다. 강사들은 지문을 읽기 위해 마우스 스크롤을 끝없이 내려야 했다.</p>
<ul>
<li><strong>리팩토링 방향:</strong>
콘텐츠 가로폭의 한계를 깨부수기 위해 기존 좌측 사이드바 구조를 도끼로 찍어내듯 전면 제거하고, 모든 메인 메뉴를 상단 헤더 영역으로 통합하는 상단 네비게이션(Top Nav) 패러다임으로 대대적인 뼈대 공사를 진행했다. </li>
</ul>
<p>그 결과 가로 가용 영역이 100% 온전히 확보되면서 좌측 지문 스트림 pool과 우측 문항 스트림 pool이 황금 비율로 유연하게 늘어나는 반응형 2단 레이아웃을 완성했다.</p>
<ul>
<li><strong>사용자 경험(UX) 마이크로 튜닝:</strong>
플랫폼의 브랜딩 퀄리티를 디테일하게 조정하기 위해 유저와의 소통 어조를 시스템적으로 분리했다. 사용자가 직관적으로 가이드를 받고 액션을 취하는 프론트엔드 UI 컴포넌트와 모달 안내 구문에는 다정하고 자연스러운 &#39;해요체&#39;(&quot;문제를 분석하고 있어요. 잠시만 기다려 주세요.&quot;)를 일관되게 적용했다. </li>
</ul>
<p>반면, 예외 처리 팝업, 보안 가드레일 경고, 토스페이먼츠 결제 승인 확인 등 시스템의 무결성과 신뢰성이 최우선으로 담보되어야 하는 핵심 커널 레이어에는 엄격한 &#39;합쇼체&#39;(&quot;인증에 실패하였습니다. 관리자에게 문의하십시오.&quot;)를 구분 사용하여 유저가 플랫폼에 느끼는 무의미한 불확실성을 미세한 수준까지 정제했다.</p>
<hr>
<h2 id="3-phase-2-비동기-데이터-관리-및-네트워크-요청-제어-고도화">3. Phase 2: 비동기 데이터 관리 및 네트워크 요청 제어 고도화</h2>
<h3 id="ai-examgenerator-전역-인프라-아키텍처-및-비동기-job-queue-토폴로지">[AI ExamGenerator 전역 인프라 아키텍처 및 비동기 Job Queue 토폴로지]</h3>
<blockquote>
<p><strong>💡 사용 가이드:</strong> 이 아키텍처는 NCP Private Subnet에 격리된 FastAPI 앱 서버와 Redis 큐, 그리고 Heavy/Middle 워커 풀이 데이터 스토리지 및 외부 Gemini API와 상호작용하는 물리적 흐름을 명시합니다.</p>
</blockquote>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/8d15b527-9298-4a3c-a1eb-f4875641f44b/image.png" alt=""></p>
<h3 id="31-useeffect-기반-데이터-패칭의-한계와-tanstack-query-v5-전면-도입">3.1 useEffect 기반 데이터 패칭의 한계와 TanStack Query v5 전면 도입</h3>
<ul>
<li><strong>직면한 구조적 병목 (Challenge):</strong>
초기 대시보드와 세션 상세 화면은 21개가 넘는 라우팅 페이지 내부에서 비동기 데이터를 가져오기 위해 커스텀 상태와 useEffect 훅을 복잡하게 난사하고 있었다. </li>
</ul>
<p>당시 소스 코드는 컴포넌트 내부에서 비동기 fetch가 발생할 때 컴포넌트 상태에 데이터 의존성이 결합되어 있었다. 이 방식은 컴포넌트가 사소한 로컬 state 변경으로 인해 재렌더링될 때마다 무의미한 중복 HTTP 요청을 서버로 날렸고, 프론트엔드 단에 캐싱 레이어가 아예 없다 보니 페이지를 이동할 때마다 화면 전체가 하얗게 깜빡거리며 덜컹거리는 플리커링(Flickering) 현상이 심각했다. 데이터 소유권과 정합성이 컴포넌트 생명주기에 완전히 종속되어 있어 데이터가 조금만 꼬여도 디버깅이 불가능한 임계점에 부딪혔다.</p>
<ul>
<li><strong>구조적 개선 (Solution):</strong>
과감하게 모든 비동기 상태 코드를 걷어내고 React Query (TanStack Query v5)로 전면 마이그레이션을 단행했다. 우선 데이터 캐시 상태의 무결성을 격리하기 위해 src/lib/queryClient.ts와 캐시 키를 중앙 제어하는 src/lib/queryKeys.ts 팩토리를 신설했다.</li>
</ul>
<pre><code>[중앙화 캐시 키 구조 설계 명세]
- sessionKeys.all: [&#39;sessions&#39;] 고정 레이어
- sessionKeys.lists: [&#39;sessions&#39;, &#39;list&#39;] 배열 매핑
- sessionKeys.detail(id): [&#39;sessions&#39;, &#39;detail&#39;, id] 1대1 매핑 구조화</code></pre><p>전역에 일관된 캐싱 정책을 주입하여 한 번 가져온 세션 목록과 시험지 리스트는 메모리에 안전하게 유지되도록 구조화했고, 유저가 페이지를 이동하더라도 깜빡임 없이 즉시 스냅샷 데이터를 보여주어 체감 렌더링 속도를 극대화했다.</p>
<ul>
<li><strong>스마트 폴링 최적화 (Polling Optimization):</strong>
유저가 업로드한 PDF 기출문제 데이터는 백엔드 내부에서 Redis Queue를 거쳐 Heavy Worker 프로세스들이 백그라운드로 소화하는 구조다. 따라서 프론트엔드는 워커의 연산이 끝날 때까지 서버의 세션 상태가 ANALYZING에서 DONE으로 바뀌는지 지속적으로 체크해야 하는 숙명이 있었다.</li>
</ul>
<p>기존 브라우저의 setInterval 타이머 기반 폴링은 컴포넌트가 언마운트되거나 예기치 못한 네트워크 단절(401 Unauthorized, 503 Service Unavailable 등)이 터져도 타이머 객체가 브라우저 메모리에 좀비처럼 살아남아 서버로 무차별 쿼리를 연사하는 결함이 있었다.</p>
<p>이 문제를 해결하기 위해 useQuery의 선언적 옵션인 refetchInterval 매커니즘을 적극 활용하여 폴링 파이프라인을 완전히 지능화했다. queryFn 내부에 수동 타이머 가동 로직을 전부 걷어내는 대신, 수신된 세션 데이터 모델 구조 내부의 status 필드값이 정확히 &#39;ANALYZING&#39;일 때만 3000ms(3초) 주기로 자동 리페치 오퍼레이션을 트리거하도록 설계하고, staleTime을 5000ms로 조율했다.</p>
<p>이 패턴 도입 후, 작업이 진행 중일 때만 네트워크 파이프라인이 정밀하게 가동되고, 작업 완수(DONE) 혹은 에러 처리 시 즉시 백엔드 트래픽 링크가 차단되어 무의미한 DB 데드락 및 커널 소켓 고갈 부하를 완전히 차단할 수 있었다.</p>
<h3 id="32-abortcontroller-스키마를-활용한-데이터-경쟁-상태race-condition-방지">3.2 AbortController 스키마를 활용한 데이터 경쟁 상태(Race Condition) 방지</h3>
<ul>
<li><strong>잠재적 결함 발견 (Edge Case):</strong>
유저의 네트워크 레이턴시가 요동치는 실서버 상용 인프라 환경에서 심각한 상태 꼬임 버그가 제보되었다. 사용자가 대시보드 화면에서 네트워크 응답 속도가 느린 &#39;세션 전체 목록&#39; 메뉴를 클릭한 직후, 서버 응답이 미처 오기 전에 재빨리 바로 아래에 있는 &#39;시험지 전체 목록&#39; 메뉴를 연속으로 타다닥 클릭했을 때 발생했다.</li>
</ul>
<p>브라우저 네트워크 스레드는 뒤늦게 도착한 &#39;세션 전체 목록&#39;의 HTTP 응답 객체를 수신하고 프론트엔드 상태(State)를 뒤늦게 업데이트해 버렸다. 결과적으로 주소창과 화면 헤더는 &#39;시험지 목록&#39; 페이지를 가리키고 있는데, 정작 본문 데이터 카드는 &#39;세션 목록&#39;의 내용이 출력되어 버리는 치명적인 데이터 경쟁 상태(Race Condition) 현상이었다.</p>
<ul>
<li><strong>해결 메커니즘 (Cancellation Pattern):</strong>
React Query v5 레이어로 진입하면서 모든 백엔드 API 통신 전용 Axios 함수가 웹 표준 인터페이스인 AbortSignal을 필수적으로 주입받아 하부 네트워크 소켓에 바인딩하도록 시그니처 아키텍처를 강제했다.</li>
</ul>
<p>데이터를 호출하는 통신 컨텍스트 함수에 인자로 signal 객체를 열어두고, axios.get 요청 구조의 옵션 프로퍼티 필드에 { signal } 인스턴스를 다이렉트로 바인딩 결합을 명시했다.</p>
<p>이 구조 하에서는 유저가 특정 메뉴를 클릭해 비동기 요청을 발생시킨 후, 응답이 완료되기 전에 다른 페이지로 넘어가거나 컴포넌트를 이탈(언마운트)하는 순간 React Query가 자동으로 해당 단계를 인지하고 하부 브라우저 소켓 단에 AbortController.abort() 인스턴스 시그널을 즉시 날려버린다.</p>
<p>네트워크 레벨에서 뒤늦게 날아오는 낙오 응답 패킷들을 브라우저가 수신 단계에서 다이렉트로 폐기(Cancel) 처리함으로써 상태 꼬임 현상을 완벽히 방어해 냈고, 서버 자원의 불필요한 IO 대기 병목까지 우아하게 해결하는 성과를 거두었다.</p>
<hr>
<h2 id="4-phase-3-ai-파이프라인-및-문서-렌더링-혁신-수식-및-레이아웃과의-전쟁">4. Phase 3: AI 파이프라인 및 문서 렌더링 혁신 (수식 및 레이아웃과의 전쟁)</h2>
<h3 id="41-웹-렌더링의-한계와-latex-수식-디버깅-the-png-bridge-아키텍처">4.1 웹 렌더링의 한계와 LaTeX 수식 디버깅 (The PNG Bridge 아키텍처)</h3>
<ul>
<li><p><strong>직면한 장애 (Problem):</strong>
우리 서비스의 핵심 가치는 AI가 수능 및 모의고사 기출 PDF를 완벽하게 분석하고, 문맥과 난이도를 보존한 채 신규 변형 문제를 생성하는 것이다. 하지만 수학, 과학, 경제 지문에 필수적으로 포함되는 LaTeX 수식 기호($\sum, \int, \alpha, \beta$ 등)가 가장 거대한 기술적 장벽이었다. 
웹 화면에서는 KaTeX 라이브러리를 통해 실시간으로 수식이 미려하게 렌더링되었지만, 유저가 시험지 편집을 모두 마치고 &#39;Microsoft Word(.docx) 파일로 내보내기&#39;를 실행하는 순간 대형 결함이 터졌다. Word 문서 내부에서 수식 전체가 깨진 외계어 문자열이나 가공되지 않은 생형태의 텍스트 코드(<code>\frac{a}{b}</code> 등)로 노출되는 현상이었다. Word 파일 표준 포맷(OpenXML)은 웹 표준 CSS나 브라우저 기반의 수학 렌더링 엔진을 전혀 인지하지 못하기 때문에 발생하는 고질적인 인프라 불일치 문제였다.</p>
</li>
<li><p><strong>아키텍처적 해결 기법 (Solution - Hybrid Rendering):</strong>
텍스트 포맷으로 수식을 전달하는 방식을 과감히 포기하고, 수식 영역만 고해상도 투명 PNG 이미지 바이너리로 동적 가공하여 Word 문서 내부에 바이너리 스트림으로 직접 이식하는 하이브리드 렌더링 아키텍처, 일명 <strong>&#39;The PNG Bridge&#39;</strong> 메커니즘을 고안하고 구현했다.</p>
</li>
</ul>
<p>[The PNG Bridge 파이프라인 제어 단계]</p>
<ol>
<li>정규식 기반 수식 적출: 백엔드 파이프라인 내부에서 지문과 문제 오프셋을 파싱하여 달러 기호로 감싸진 LaTeX 문장 영역만 정밀하게 정규식 스캔으로 추출한다.</li>
<li>Headless Chromium 이미지화: 백엔드 워커 풀 하부에 Puppeteer(Headless Chromium)와 경량화된 KaTeX 자산만 탑재한 독립 렌더링 프로세스를 가동했다. 적출된 수식 문자열을 이 미니멀 렌더러에 통과시켜, 글자 배경이 투명하게 처리된 300dpi 이상의 고해상도 수식 PNG 이미지를 동적으로 추출해 낸다.</li>
</ol>
<ul>
<li><strong>결정적 블라인드 스팟 디버깅 (Redis Binary Corruption):</strong>
매번 사소한 수식 하나를 새로 그릴 때마다 Puppeteer 프로세스를 대기 상태에서 깨워 연산하는 것은 극심한 CPU 오버헤드와 자원 병목을 유발했다. 이를 방지하기 위해 수식 원문 문자열을 MD5 해시 토큰으로 치환하여, 한 번 생성된 수식 PNG 바이너리를 Redis에 24시간 동안 보관하는 캐시 레이어를 추가했다. </li>
</ul>
<p>그러나 캐시 레이어 도입 직후 특정 수식 이미지들이 엑스박스로 뜨며 바이너리가 통째로 깨지는 장애를 마주했다. 원인을 패턴 인식으로 역추적한 결과, 백엔드 전역에서 Redis 연결 시 사용하던 <code>decode_responses=True</code> 옵션이 주범이었다. Redis 클라이언트가 수식 이미지용 <strong>순수 PNG 바이너리 데이터까지 UTF-8 문자열로 강제 디코딩을 시도</strong>하면서 바이트 스트림이 왜곡되어 깨지는 현상이었다.</p>
<p>이를 해결하기 위해 일반 텍스트 및 세션 상태용 Redis 클라이언트와 별개로, 바이너리 전용 데이터 처리를 위해 <code>decode_responses=False</code> 옵션을 부여한 <strong>바이너리 전용 Redis 클라이언트 인스턴스를 엄격히 분리 운영</strong>하도록 서버 소켓 레이어를 수정했다. 이후 수식 이미지 로딩 레이턴시가 획기적으로 제거되며 Cache Hit 시 완전히 0ms에 수렴하는 극적인 성능 개선을 달성했다.</p>
<h3 id="42-수능-표준-인프라-규격-구현-2단2-column-레이아웃-밸런서-알고리즘">4.2 수능 표준 인프라 규격 구현: 2단(2-Column) 레이아웃 밸런서 알고리즘</h3>
<ul>
<li><p><strong>도전 과제 (Challenge):</strong>
실제 상용 환경에서 유저들이 편집 툴에 기대하는 결과물의 퀄리티는 단순히 줄글로 정렬된 문서가 아니었다. 실제 한국교육과정평가원 모의고사나 수능 시험지와 완벽하게 동일한 구조를 가진 좌/우 2단(2-Column) 레이아웃 출력을 필수적으로 요구했다. 웹 화면의 유연한 반응형 배치를 엄격한 인쇄 여백 규격 및 단 구분에 맞춰 통제해야 하는 고난도 레이아웃 제어 알고리즘이 필요했다.</p>
</li>
<li><p><strong>알고리즘 반영 및 트레이드오프:</strong>
Puppeteer의 프린트 미디어 쿼리와 CSS Paged Media 표준 스펙을 서비스 커스텀 형태로 확장 가공하여 두 가지 핵심 문제를 격파했다.</p>
</li>
</ul>
<p>첫 번째는 단절 방지(<code>keepNext</code> 매커니즘) 구현이다. 문제 컨테이너가 좌측 단 맨 아래 경계선에 애매하게 걸칠 경우, 지문 텍스트는 좌측 단 맨 밑에 남고 ①~⑤번 정답 선택지는 우측 단 맨 위로 강제 분할되어 가독성이 심각하게 깨지는 현상이 발생했다. 이를 해결하기 위해 개별 문항 카드에 <code>break-inside: avoid</code> 속성을 엄격히 바인딩하고, 상위 지문과 하위 문항 번호 그룹의 픽셀 높이를 커널 내부에서 동적으로 연산하여 단 경계 영역의 임계치를 침범하는 즉시 그룹 전체를 우측 단 혹은 다음 페이지의 시작점으로 통째로 밀어버리는 높이 계산 분기 알고리즘을 구축했다.</p>
<p>두 번째는 선택지 문항 오토 밸런싱(Auto Balancing)이다. 수학 수식이나 영어 보기 문장의 길이는 문항마다 완전히 다르다. 이를 고정된 가로폭에 가두면 텍스트가 겹치거나 깨진다. 선택지 문장의 문자열 길이를 바이트(Byte) 수 기준으로 실시간 연산하여, 길이가 매우 짧은 단어 형태면 1열 5행(가로로 촘촘히 배치) 구조로 축을 짜고, 중간 길이면 2열 구조, 문장 형태로 길어지면 5열(한 행에 보기 하나씩 세로 배치)로 CSS Grid 아키텍처 축을 실시간 가변 전환하는 자동 밸런서 알고리즘을 반영하여 실제 배포 인쇄물의 외관 완성도를 수능 규격과 완벽히 일치시켰다.</p>
<hr>
<h2 id="5-phase-35-상용-결제-및-크레딧-원장-관리를-위한-데이터-모델링-erd">5. Phase 3.5: 상용 결제 및 크레딧 원장 관리를 위한 데이터 모델링 (ERD)</h2>
<p>AI 변형 문항 생성 서비스는 AI 추론비용(토큰 소모)과 Puppeteer 커널 렌더링 비용이 지속적으로 발생하는 고비용 비즈니스 구조를 가진다. 따라서 데이터베이스 설계 단계에서부터 <strong>사용자 인증, AI 콘텐츠 스트림, 구독 결제 및 크레딧 원장(Ledger)</strong> 간의 정밀한 참조 무결성과 트랜잭션 정합성이 담보되어야 했다. </p>
<p>[데이터베이스 스키마 핵심 도메인 분기 구조]</p>
<ul>
<li>Identity &amp; Access: users ↔ user_settings, user_credit_wallets (1:1 강제 분리)</li>
<li>Content &amp; Automation: sessions ↔ questions ↔ generated_exams ↔ generated_pdfs (1:N 체인 구조)</li>
<li>Billing Ledger: payment_customers ↔ payment_methods ↔ subscriptions ↔ billing_attempts (멱등성 보안 구조)</li>
</ul>
<h3 id="51-크레딧-차감-멱등성-및-원장-관리-정책-wallet--transactions">5.1 크레딧 차감 멱등성 및 원장 관리 정책 (wallet &amp; transactions)</h3>
<p>사용자가 AI 변형 생성을 트리거할 때, 크레딧 차감과 AI 작업 승인은 단 하나의 트랜잭션 오류도 허용하지 않는 엄격한 금융 서비스의 규칙을 따라야 한다. 이를 위해 잔액을 실시간으로 캐싱 제어하는 <code>user_credit_wallets</code> 테이블과 모든 입출금 변경 이력을 영구 보관하는 원장 테이블인 <code>credit_transactions</code> 구조를 완전히 이중화하여 결합했다.</p>
<p>유저가 작업을 요청하면 시스템은 먼저 <code>user_credit_wallets</code>에서 <code>remaining_credit</code> 잔액을 사전 체크(Pre-check)하여 부족할 경우 비동기 큐 진입을 원천 차단한다. 작업이 성공적으로 완수되면, 원장 테이블에 <code>DEDUCT</code> 트랜잭션을 삽입하고 동시에 지갑의 잔액을 감산 처리한다. </p>
<p>만약 AI 워커 풀 내부에서 예기치 못한 에러나 타임아웃이 발생해 Job이 최종 실패(<code>FAILED</code>)하는 상황이 터지면, 원장에 <code>REFUND</code> 로그를 즉시 생성하고 잔액을 복구하는 트랜잭션 롤백 매커니즘을 적용했다. 모든 거래 이력에는 유저 브라우저 세션의 고유 <code>request_id</code>를 외래키 수준으로 연동하여 데이터 중복 차감(Double Spending) 버그를 원천 봉쇄했다.</p>
<h3 id="52-토스페이먼츠-빌링키billingkey-보안-암호화-적재-database-privacy">5.2 토스페이먼츠 빌링키(BillingKey) 보안 암호화 적재 (Database Privacy)</h3>
<p>토스페이먼츠의 빌링키 기반 정기 자동결제 시스템을 구축할 때 가장 중요한 보안 원칙은 구매자의 민감한 카드 정보(카드번호, 유효기간, CVC 원문 등)를 서버에 절대 저장하지 않는 것이다. 대행사로부터 안전하게 발급받은 문자열 토큰인 <code>billingKey</code>만을 저장 운영하되, 이 역시 평문 데이터로 적재하는 위험을 회피하고자 애플리케이션 커널 단에서 복합 암호화 스펙을 적용했다.</p>
<p><code>payment_methods</code> 테이블을 설계할 때 빌링키 필드를 <code>billing_key_encrypted</code>, <code>billing_key_iv</code>, <code>billing_key_tag</code> 3가지 필드로 쪼개어 배치했다. 서버는 <code>.env</code> 환경 변수로 격리된 32바이트의 <code>TOSS_BILLING_AES_KEY</code>를 기반으로 암호화 강도가 가장 우수한 <strong>AES-256-GCM 알고리즘</strong>을 호출하여 소스 데이터를 암호화한 뒤 인스턴스 형태로 데이터베이스에 밀어 넣는다. </p>
<p>정기 스케줄러 배치 장비가 작동할 때만 이 대칭키를 복사해 메모리 상에서만 일시 복호화하여 토스 결제 API 엔드포인트와 통신하므로, 설령 DB 인스턴스가 통째로 스냅샷 덤프 유출 공격을 당하는 최악의 장애 시나리오가 발발하더라도 암호화 키 없이는 빌링키 탈취 및 복호화가 원천적으로 불가능하도록 강력한 보안 무결성 가드레일을 완성했다.</p>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/94b60513-9ac0-4d23-bce9-bdc2355b411a/image.png" alt=""></p>
<hr>
<h2 id="6-phase-4-운영-안정성-및-상용-전환-production-ready">6. Phase 4: 운영 안정성 및 상용 전환 (Production Ready)</h2>
<h3 id="61-실서비스-관측성-인프라-수립-sentry-전역-연동">6.1 실서비스 관측성 인프라 수립 (Sentry 전역 연동)</h3>
<ul>
<li><strong>구현 세부:</strong>
사용자가 대량의 비동기 AI 문제 생성 태스크를 백그라운드 워커 큐에 적재하고 브라우저를 이탈하는 구조 특성상, 운영자가 인지하지 못하는 커널 내부의 예외 발생(Gemini API Rate Limit 429 에러, 타임아웃 등)을 실시간으로 추적해야 했다. 프론트엔드 대역에는 <code>@sentry/react</code> 인터페이스를, FastAPI 백엔드에는 <code>sentry-sdk</code> 레이어를 동시에 연동하여 전역 예외 캡처 시스템을 완벽히 안착시켰다.</li>
</ul>
<p>개발 단계 환경에서는 신속한 트러블슈팅을 위해 상세 로직 에러 스택을 리턴하도록 설정했지만, 실서비스 프로덕션 환경에서는 내부 스키마 및 보안 자산 노출을 완벽하게 격리 차단하기 위해 유저에게는 사전에 정의된 직관적인 에러 코드 필드만 안전하게 송출하고, 구체적인 원인 분석 Trace 로그는 Sentry 관리자 대시보드와 Slack Webhook 감사 채널로 즉시 릴레이 분기되도록 데이터 차단벽을 공고히 다졌다.</p>
<h3 id="62-토스페이먼츠-정기-결제-웹훅webhook-유실-대응-및-멱등성-보장">6.2 토스페이먼츠 정기 결제 웹훅(Webhook) 유실 대응 및 멱등성 보장</h3>
<ul>
<li><strong>장애 예방 설계:</strong>
정기 구독 과금 비즈니스를 유기적으로 제어하기 위해 사용자가 결제수단을 등록하고 스케줄러가 자동결제를 트리거하는 구조를 도입했다. 이때 유저 카드의 순간적인 한도 초과, 통신사 망 불안정 등으로 인해 결제 대행사(PG) 측에서 발송하는 비동기 결제 완료 신호가 유실되거나 중복 유입될 치명적인 금융 리스크가 상존했다.</li>
</ul>
<p>백엔드 내부에 <code>POST /billing/webhook/toss</code> 보안 수신 엔드포인트를 개설하고, 수신되는 헤더의 <code>Toss-Signature</code> 서명 값을 HMAC-SHA256 알고리즘으로 엄격히 상호 검증하도록 가드레일을 짰다. </p>
<p>특히 웹훅 수신 원본 이벤트를 데이터베이스에 적재할 때, 결제사에서 부여한 고유 이벤트 식별자를 <code>dedupe_key</code> 필드로 삼아 유니크 인덱스(Unique Index) 제약 조건을 걸었다. 이 설계 덕분에 결제사 내부 허브 장비의 일시적 결함으로 인해 동일한 결제 성공 신호가 1초 내에 중복으로 2번 유입되더라도, 데이터베이스 테이블 레벨에서 최초 1회 요청만 유효하게 정산 처리하고 두 번째 인스턴스는 조용히 차단(Ignore)함으로써 중복 크레딧 지급이나 원장 데이터 손상 금융 사고 리스크를 시스템적으로 완벽히 예방했다.</p>
<h3 id="63-pg_dump-기반의-무중단-일일-백업-인프라-구축">6.3 pg_dump 기반의 무중단 일일 백업 인프라 구축</h3>
<ul>
<li><strong>인프라 자동화:</strong>
VPC 가상 인스턴스의 하드웨어 결함이나 예기치 못한 스토리지 손상 등 재해 복구(DR) 시나리오의 골든타임을 확보하기 위해 백엔드 핵심 코어 단에 데이터 자동 백업 스크립트(<code>scripts/db_backup.sh</code>)를 심었다. </li>
</ul>
<p>유저 트래픽 유입이 거의 없는 매일 새벽 3시에 시스템 크론탭(Cron) 데몬이 깨어나 PostgreSQL 가동 엔진 전체를 <code>pg_dump</code> 지시어로 안전하게 추출한 뒤, <code>gzip</code>으로 압축하여 별도의 보호 디렉토리로 격리 이전한다. </p>
<p>서버의 내부 스토리지 용량 고갈을 막기 위해 14일 보존 정책(14 Days Rotation)을 코딩하여, 보관 주기를 초과한 구형 압축 파일은 리눅스 커널 명령어가 자동으로 탐색하여 파기하도록 일련의 인프라 파이프라인 무중단 자동화를 완성했다.</p>
<hr>
<h2 id="배포-일주일-전에-터진-버그-두-개">배포 일주일 전에 터진 버그 두 개</h2>
<p>프로덕션 안정화를 어느 정도 마무리하고 실사용 트래픽을 지켜보고 있었는데, 배포까지 딱 일주일 남은 시점에 꽤 골치 아픈 버그를 두 개 연달아 밟았다.</p>
<p>시작은 시험지 검수였다. 실제 수능 영어 PDF(45문항)를 올려서 변형 시험지를 뽑고, 원본이랑 한 문항씩 대조해보고 있었는데 이상한 걸 발견했다. 원본 21번(디지털 플랫폼 지문)이 결과물에서 완전히 똑같은 지문으로 두 번, 서로 다른 문항 번호에 들어가 있었다. 33번은 아예 세 번, 매번 다르게 paraphrase된 채로 나왔다. 처음엔 &quot;AI가 같은 청크 안에서 헷갈려서 중복 생성했나보다&quot; 하고 넘기려 했는데, 전체를 대조해보니 원본 28문항 중 9개가 중복이었고 결과 시험지 40문항 중 12개(30%)가 그냥 순수 복제였다.</p>
<p>원인을 찾아 들어가보니 추출 단계에 있었다. PDF에서 문항을 뽑을 때 목표 개수를 못 채우면 recovery pass라고, 놓친 문항을 찾으려고 한 번 더 훑는 과정이 있는데, 이 재추출 과정에서 같은 문항을 또 뽑아오면서 지문 텍스트가 아주 미세하게(공백 하나, 구두점 하나) 다르게 나오는 경우가 있었다. 그런데 중복인지 판별하는 기준이 &quot;지문 텍스트가 정확히 같은가&quot;였다. 텍스트가 한 글자만 달라도 완전히 다른 문항 취급을 해버리니, 문항 번호는 시험지 안에서 절대 안 겹친다는 뻔한 사실을 무시하고 애먼 지문 문자열 매칭에 기대고 있었던 셈이다.</p>
<p>고치는 건 오래 안 걸렸다. 판별 기준을 지문 텍스트에서 문항 번호로 바꾸면 끝이었다. 근데 고치고 나서 신나서 재테스트했는데 결과가 하나도 안 바뀌어서 당황했다. 알고 보니 예전에 이미 업로드해둔 세션을 재사용해서 테스트한 거였다. 추출은 세션 업로드할 때 딱 한 번만 실행되고 DB에 저장되니까, 버그 고치기 전에 이미 중복으로 박힌 데이터는 당연히 그대로 남아있을 수밖에. PDF를 완전히 새 세션으로 다시 올려서 돌리고 나서야 28문항 대 28문항, 중복 0건으로 딱 맞아떨어지는 걸 확인했다. 덤으로 예전엔 40문항 만드느라 AI를 그만큼 더 호출했는데 이제 28개만 정확히 만드니 체감 속도도 눈에 띄게 빨라졌다.</p>
<p>같은 로직이 다른 과목에서도 버티는지 궁금해서 일부러 파싱이 까다로운 걸 하나 골랐다. 경희대 편입학 수학 시험지였는데, PDF 텍스트 레이어 자체가 적분, 행렬, 급수 기호로 범벅이 돼서 추출된 원문이 꽤 지저분했다. 30문항을 선택해서 변형을 돌렸는데 결과물이 딱 15문항만 나왔다. 한 번 더 돌려봤더니 이번에도 정확히 1번부터 15번까지만, 16번부터 30번(선형대수 파트)은 통째로 없었다. 이렇게 깔끔하게 재현되는 걸 보고 운이 나쁜 게 아니라 뭔가 구조적으로 막히고 있다는 확신이 들었다.</p>
<p>세션 업로드 화면에서 문항 선택할 땐 30개가 다 보였으니 추출 자체는 문제가 없었고, 생성/복구 단계에서 뒤쪽 문항들이 유독 못 버티고 있었다. 코드를 다시 열어봤다. 문항 하나가 완성도 문제(선택지 누락, 해설이 placeholder로 남는 등)로 걸리면 그 문항 하나만 따로 다시 생성해서 복구하는 함수가 있는데, 이 함수가 AI를 호출할 때 토큰 예산을 아예 안 넘기고 있었다. 기본값 4000으로 고정. 지문 기반 청크 생성 쪽은 예전에 청크 크기에 비례해서 토큰 예산을 늘리도록 이미 고쳐놨었는데, 정작 단건 복구 경로는 그 수정에서 빠져 있었다.</p>
<p>문제는 4000토큰이 영어 지문 문제엔 충분해도 선형대수 뒷부분(고윳값, 수반행렬, column space, 최소제곱법 같은)처럼 해설이 여러 단계로 길게 이어지는 문항엔 부족했다는 거다. 답이 잘리고, 잘린 채로 복구를 네 번 재시도해도 매번 같은 이유로 또 잘리니 결국 드롭될 수밖에 없었다. 하필 뒤로 갈수록 문제 난이도와 해설 길이가 늘어나는 구조라 정확히 절반 지점부터 무너진 거였다. repair 함수에 토큰 예산을 명시적으로 늘려서 지정하도록 고쳤다. 이건 실제 API 호출 비용이 들어가는 부분이라 로컬에서 바로 재현 검증은 못 했고, 배포해서 같은 PDF로 다시 돌려보는 걸로 검증을 이어가는 중이다.</p>
<p>두 버그 다 패턴이 비슷했다. 예전에 비슷한 걸 이미 한 번 고쳤는데, 그 수정이 커버 못 한 경로가 하나씩 더 있었던 거다. 파이프라인이 추출, 생성, 검증, 복구로 여러 단계 나뉘어 있다 보니 한 곳을 고쳐도 같은 유형의 구멍이 다른 단계에 그대로 남아있는 일이 계속 생긴다. 배포 전에 원본이랑 결과물을 문항 단위로 하나하나 대조해보는 걸 안 했으면 둘 다 그냥 모르고 넘어갔을 것 같다.</p>
<hr>
<h2 id="7-주요-성과-및-엔지니어링-스토리를-마치며">7. 주요 성과 및 엔지니어링 스토리를 마치며</h2>
<p>이번 상용화 고도화 단계를 정면으로 통과하며 얻은 가장 큰 엔지니어링적 소득은 <strong>&quot;돌아가는 쓰레기 코드를 비즈니스가 지속 가능한 견고한 아키텍처로 전환할 때의 트레이드오프&quot;</strong>를 온전히 내 손으로 겪어냈다는 점이다.</p>
<p>단순히 <code>useEffect</code>와 <code>useState</code>를 난사하며 화면에 데이터를 띄우고 상태 결함에 허덕이던 과거의 패러다임에서 벗어나, <strong>TanStack Query v5</strong> 캐싱 레이어를 전역에서 유기적으로 제어하고 비동기 Job 상태에 따라 폴링 주기를 유연하게 조율하여 백엔드 소켓 자원 트래픽을 획기적으로 경감시키는 성능 최적화를 일구어낼 수 있었다.</p>
<p>또한, 가상 도메인 표준 명세와 문서 포맷의 한계를 극복하기 위해 백엔드 하부에 Puppeteer 기반 고해상도 수식 이미지 캐싱 브릿지(<code>The PNG Bridge</code>)를 아키텍처링하고, 수능 규격의 2단 출력 레이아웃 시스템을 설계해 나간 과정은 에듀테크 도메인이 마주하는 고유의 난제들을 공학적으로 정면 돌파해 낸 매우 값진 시간이었다. 이 날것의 기록이 나처럼 비슷한 화면과 인프라 인스턴스를 붙잡고 밤을 지새우는 수많은 풀스택 엔지니어들에게 자그마한 힌트와 뼈대가 되기를 바란다.</p>
<hr>
<h2 id="프로젝트-관련-자산-및-라이브-링크">프로젝트 관련 자산 및 라이브 링크</h2>
<p>더 자세한 아키텍처 명세나 실서비스의 프로덕션 환경이 궁금하신 분들은 아래 링크를 참고해 주세요. 주니어 엔지니어의 치열한 삽질이 담긴 프로젝트입니다. 자유로운 피드백이나 기술적 논의는 언제나 환영합니다!</p>
<ul>
<li><strong>공식 웹 서비스</strong>: <a href="https://ai-examgenerator.co.kr/">AI ExamGenerator 바로가기</a></li>
<li><strong>GitHub 레포지토리</strong>: <a href="https://github.com/Seongwonp/CSAT_Forge.git">CSAT_Forge(AI ExamGenerator) 소스 코드 원본</a></li>
<li><strong>개발자 포트폴리오</strong>: <a href="https://seongwonp-portfolio.vercel.app/">Seongwon Park Portfolio</a></li>
<li><strong>문의 및 피드백 이메일</strong>: <a href="mailto:swp20138993@gmail.com">swp20138993@gmail.com</a></li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[# [컴퓨터 네트워크] 11장- 응용층]]></title>
            <link>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-11%EC%9E%A5-%EC%9D%91%EC%9A%A9%EC%B8%B5</link>
            <guid>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-11%EC%9E%A5-%EC%9D%91%EC%9A%A9%EC%B8%B5</guid>
            <pubDate>Tue, 02 Jun 2026 07:35:47 GMT</pubDate>
            <description><![CDATA[<h2 id="111-응용-계층의-개요-및-서비스">11.1 응용 계층의 개요 및 서비스</h2>
<p>응용 계층(Application Layer)은 OSI 7계층 및 TCP/IP 모델의 최상위 계층으로, 사용자가 자원과 상호작용할 수 있도록 인터페이스를 제공하고 응용 프로세스 간의 논리적 연결(Logical Connection)을 수립하여 서비스를 수행한다. </p>
<h3 id="1111-응용-프로세스-간-논리적-연결">11.1.1 응용 프로세스 간 논리적 연결</h3>
<ul>
<li><strong>논리적 연결의 정의:</strong> 하위 계층(물리, 링크, 네트워크, 전송 계층)의 복잡한 패킷 라우팅, 흐름 제어, 에러 복구 매커니즘을 추상화하여, 종단의 두 응용 프로그램이 마치 하나의 가상 파이프로 직접 연결되어 1대1로 데이터를 송수신하는 것처럼 간주하는 구조이다.</li>
<li><strong>응용층 프로토콜의 역할:</strong> 교환되는 메시지의 유형(요청/응답), 메시지의 구문(Syntax), 각 필드의 의미(Semantics), 프로세스가 메시지를 전송하고 응답하는 규칙(Timing)을 명확하게 규정한다.</li>
</ul>
<hr>
<h2 id="112-네트워크-애플리케이션-패러다임">11.2 네트워크 애플리케이션 패러다임</h2>
<p>네트워크 응용 아키텍처는 제어 권한과 자원 분산 방식에 따라 클라이언트/서버 패러다임과 Peer-to-Peer(P2P) 패러다임으로 양분된다.</p>
<h3 id="1121-클라이언트서버clientserver-패러다임">11.2.1 클라이언트/서버(Client/Server) 패러다임</h3>
<p>중앙 집중식 자원 관리 구조로, 서비스를 요청하는 시스템과 서비스를 전담 제공하는 시스템의 역할이 명확하게 고정 분리된 구조이다.</p>
<ul>
<li><strong>서버 (Server):</strong><ul>
<li><strong>대기 상태 (Passive Open):</strong> 클라이언트의 접속 요청을 수용하기 위해 고정된 Well-known 포트 번호를 열고 항상 가동(Always-on) 상태로 대기한다.</li>
<li><strong>주소 체계:</strong> 클라이언트가 언제든 접근할 수 있도록 영구적이고 고정된 정적 IP 주소(Static IP)를 보유해야 한다.</li>
<li><strong>자원 확장성 한계:</strong> 클라이언트의 요청 수가 폭증할 경우 대역폭 고갈 및 서버 하드웨어 자원의 병목 현상이 발생하므로, 인프라 확장을 위해 데이터센터 내부에 로드 밸런서와 다중 복제 서버 풀을 운영해야 한다.</li>
</ul>
</li>
<li><strong>클라이언트 (Client):</strong><ul>
<li><strong>요청 주체 (Active Open):</strong> 필요할 때만 서버에 접속하여 세션을 동기화하고 서비스를 요청한다.</li>
<li><strong>주소 체계:</strong> 대개 유동 IP 주소(Dynamic IP)를 사용하며, 다른 클라이언트 시스템과 직접적으로 통신하지 않는다. 클라이언트 프로그램 간의 직접 통신은 원천적으로 불가능하다.</li>
</ul>
</li>
</ul>
<h3 id="1122-p2ppeer-to-peer-패러다임">11.2.2 P2P(Peer-to-Peer) 패러다임</h3>
<p>중앙의 고성능 전용 서버에 의존하지 않고, 네트워크에 참여하는 개별 노드(Peer)들이 <strong>클라이언트인 동시에 서버의 역할(Servent: Server+Client)</strong>을 동시에 수행하는 분산형 구조이다.</p>
<ul>
<li><strong>자가 확장성 (Self-Scalability):</strong> 새로운 피어(Peer)가 자율적으로 가입할 때마다 네트워크에 새로운 서비스 요청 트래픽이 추가되지만, 동시에 해당 피어가 가진 저장 공간과 업로드 대역폭이 전체 시스템의 공급 자원으로 추가되므로 피어 수가 늘어날수록 전체 시스템 용량이 자동으로 확장되는 특성을 가진다.</li>
<li><strong>장단점:</strong> 중앙 서버 구축 비용이 없어 인프라 유지 비용이 저하되며 결함 감내 능력이 우수하다. 그러나 각 피어의 유동적인 접속 온/오프 상태로 인해 자원의 가용성 보장이 어렵고, 중앙 통제가 불가능하여 저작권 관리 및 정보보호 격리 관점에서 취약성이 존재한다.</li>
</ul>
<hr>
<h2 id="113-가상-도메인-주소-변환-프로토콜-dns">11.3 가상 도메인 주소 변환 프로토콜: DNS</h2>
<p>인터넷망 상에서 호스트를 식별하기 위해 사용하는 논리 주소는 32비트(IPv4) 또는 128비트(IPv6) 이진수 주소 체계이다. 사람이 읽고 기억하기 쉬운 가상 문자열 주소인 <strong>도메인 네임(Domain Name)</strong>을 시스템이 파싱할 수 있는 실제 기계식 <strong>IP 주소로 일대일 매핑 및 변환</strong>해 주는 전 세계 분산 데이터베이스 시스템이 DNS(Domain Name System)이다.</p>
<h3 id="1131-계층적-도메인-네임-스페이스-hierarchical-name-space">11.3.1 계층적 도메인 네임 스페이스 (Hierarchical Name Space)</h3>
<p>전 세계의 도메인 주소 체계는 관리를 효율화하기 위해 역트리(Inverted Tree) 형태의 계층적 구조를 가진다. 최상위 루트 노드부터 하위 노드로 내려가며 점(<code>.</code>)으로 구분하여 표기한다.</p>
<pre><code class="language-code">[ Root Level ( . ) ]
/           │            
[ .com ]      [ .org ]       [ .kr ]       &lt;--- TLD (Top-Level Domain)
│              │             │
[ google ]     [ wikipedia ]  [ ac ]        &lt;--- SLD (Second-Level Domain)
│
[ suwon ]      &lt;--- Third-Level Domain
</code></pre>
<ul>
<li><strong>Root Zone:</strong> 계층 구조의 최상위이며 주소의 맨 오른쪽 명시되지 않는 점(<code>.</code>)에 해당한다. 전 세계에 루트 힌트 네임 서버 인프라가 분산 배치되어 있다.</li>
<li><strong>TLD (Top-Level Domain):</strong> 도메인의 목적이나 국가를 분류하는 최상위 영역이다.<ul>
<li><strong>gTLD (일반 최상위 도메인):</strong> <code>.com</code> (상업용), <code>.org</code> (비영리기관), <code>.net</code> (네트워크 인프라) 등</li>
<li><strong>ccTLD (국가 최상위 도메인):</strong> <code>.kr</code> (대한민국), <code>.jp</code> (일본), <code>.us</code> (미국) 등</li>
</ul>
</li>
<li><strong>FQDN (Fully Qualified Domain Name):</strong> 호스트 이름부터 최상위 루트 도메인까지 전체 경로를 생략 없이 명시한 절대 도메인 네임 주소이다. (예: <code>www.suwon.ac.kr.</code>)</li>
</ul>
<h3 id="1132-분산-네임-서버-시스템-distributed-name-servers">11.3.2 분산 네임 서버 시스템 (Distributed Name Servers)</h3>
<p>하나의 중앙 서버에 전 세계 도메인 매핑 데이터를 저장하는 것은 물리적으로 불가능하므로, 계층 구조에 따라 전 세계에 네임 서버를 분산 운영한다.</p>
<ul>
<li><strong>루트 네임 서버 (Root Name Server):</strong> TLD 주소를 관리하는 네임 서버들의 IP 주소 목록을 보유하며, 질의 요청 시 해당 TLD 서버로 포인팅해 준다.</li>
<li><strong>TLD 네임 서버 (Top-Level Domain Server):</strong> 해당 최상위 도메인(예: <code>.com</code> zone) 하위에 등록된 수많은 하위 도메인들의 책임 네임 서버 주소를 관리한다.</li>
<li><strong>책임 네임 서버 (Authoritative Name Server):</strong> 특정 조직이 운영하는 실제 호스트들의 도메인명과 IP 주소 간의 실질적인 매핑 레코드를 최종 보유하고 있는 최종 권한 서버이다. (예: 수원대학교 도메인을 최종 관리하는 네임 서버)</li>
<li><strong>로컬 네임 서버 (Local Name Server / Recursive Resolver):</strong> ISP(통신사)나 내부 네트워크 기관이 운영하는 네임 서버로, 사용자의 호스트 단말이 최초로 DNS 질의 패킷을 던지는 대상이다. 직접 레코드를 보유하지 않아도 다른 상위 네임 서버들에게 대리 질의를 수행하여 최종 결과를 알아낸 뒤 클라이언트에게 캐싱하여 전달하는 브릿지 역할을 수행한다.</li>
</ul>
<h3 id="1133-도메인-주소-해석resolution-매커니즘">11.3.3 도메인 주소 해석(Resolution) 매커니즘</h3>
<p>도메인 조회를 수행할 때 전송층 프로토콜은 기본적으로 오버헤드가 적고 신속한 <strong>UDP 포트 53번</strong>을 사용하여 요청 및 응답 패킷을 교환한다. 주소 해석 방식은 크게 반복적 질의와 재귀적 질의로 나뉜다.</p>
<h4 id="1-반복적-질의-iterative-query">1) 반복적 질의 (Iterative Query)</h4>
<p>로컬 네임 서버(Resolver)가 상위 네임 서버들에게 직접 단계별로 질문을 던져 최종 주소를 추적해 나가는 방식이다. 상위 네임 서버는 정답 IP를 모를 경우, &quot;나는 모르니 다음 계층의 이 서버에게 물어보라&quot;며 하위 네임 서버의 주소를 반환하고, 로컬 서버는 그 주소를 받아 다음 단계로 직접 재질의를 반복한다.</p>
<pre><code class="language-code">[클라이언트] ──(1) www.google.com 조회 요청──&gt; [로컬 네임 서버 (Resolver)]
│
┌──────(2) 루트 서버에 질의 ───────────────────┤ (루트 왈: .com 서버로 가라)
├──────(3) .com TLD 서버에 질의 ───────────────┤ (.com 왈: google 책임 서버로 가라)
└──────(4) google 책임 네임 서버에 질의 ─────────┘ (책임 서버 왈: 실제 IP는 X.X.X.X 다)
│
[클라이언트] &lt;──(5) 최종 IP 주소 결과 반환 ──────────────┘
</code></pre>
<h4 id="2-재귀적-질의-recursive-query">2) 재귀적 질의 (Recursive Query)</h4>
<p>질의를 받은 네임 서버가 자신이 직접 상위 서버에게 다시 물어보고 그 상위 서버가 또 상위 서버에게 물어보며, 최종 결과가 나올 때까지 질의 체인을 형성하여 역순으로 정답을 하위 서버에게 완전히 토스해 주는 방식이다. 라우터나 루트 네임 서버에 가해지는 연산 및 트래픽 부하가 극심하여 실무 인터넷망 인프라 환경에서는 루트 및 TLD 장비들이 재귀적 질의 요청을 거부(Refuse)하도록 차단 설정하는 것이 일반적이다.</p>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/2f327233-3ba7-432e-b3e5-adf1fc401c45/image.png" alt=""></p>
<h3 id="1134-dns-자원-레코드-resource-records-rr">11.3.4 DNS 자원 레코드 (Resource Records, RR)</h3>
<p>네트워크 데이터베이스 테이블에 저장되는 개별 도메인 매핑 정보의 명세 포맷이다. 구조는 <strong>(Name, Value, Type, TTL)</strong> 4가지 필드로 구성되며, <code>Type</code> 필드 값에 따라 데이터의 성격이 결정된다.</p>
<ul>
<li><strong>A 레코드 (Address):</strong> 표준 IPv4 주소 매핑 레코드이다. 호스트 도메인 이름에 대응하는 32비트 IP 주소를 매핑한다. (Name = 도메인명, Value = IPv4 주소)</li>
<li><strong>AAAA 레코드:</strong> 표준 차세대 IPv6 주소 매핑 레코드이다. 호스트 도메인 이름에 대응하는 128비트 IP 주소를 매핑한다.</li>
<li><strong>CNAME 레코드 (Canonical Name):</strong> 특정 도메인명에 대한 별칭(Alias)을 지정할 때 사용한다. (예: <code>test.com</code>을 조회하면 실제 정식 원본 도메인명인 <code>www.test.com</code>으로 리다이렉트 파싱되도록 유도)</li>
<li><strong>MX 레코드 (Mail Exchanger):</strong> 해당 도메인 도메인 영역으로 유입되는 이메일 트래픽을 실제 수용하여 처리할 메일 서버(SMTP)의 주소와 우선순위 정보를 명시한다.</li>
<li><strong>NS 레코드 (Name Server):</strong> 특정 도메인 영역(Zone)의 도메인 질의를 전담 처리해 줄 책임 네임 서버의 도메인 주소를 명시하여 경로 권한을 위임한다.</li>
</ul>
<h2 id="114-월드-와이드-웹과-http-www-and-http">11.4 월드 와이드 웹과 HTTP (WWW and HTTP)</h2>
<p>월드 와이드 웹(WWW)은 인터넷 상에서 텍스트, 이미지, 멀티미디어 등 다양한 자원을 유기적으로 공유할 수 있도록 설계된 분산 정보 시스템이다. 이를 구동하는 핵심 프로토콜이 HTTP(HyperText Transfer Protocol)이다.</p>
<h3 id="1141-자원-식별자-url-uniform-resource-locator">11.4.1 자원 식별자: URL (Uniform Resource Locator)</h3>
<p>웹 상의 고유한 자원을 포인팅하기 위해 사용하는 표준 주소 체계이다. 구조는 크게 프로토콜 식별자, 호스트 도메인/IP 주소, 포트 번호, 자원의 경로(Path) 명세로 구성된다.</p>
<pre><code class="language-code">http://www.suwon.ac.kr:80/index.html
└─┬─┘  └──────┬──────┘ └┬┘ └────┬────┘
프로토콜    호스트명     포트    경로(Path)
</code></pre>
<h3 id="1142-http-프로토콜의-특성">11.4.2 HTTP 프로토콜의 특성</h3>
<ul>
<li><strong>비상태성 (Stateless):</strong> 서버는 클라이언트의 상태를 별도로 보존하지 않는다. 각 요청은 이전 요청과 완전히 독립된 객체로 처리된다. 이로 인해 서버의 메모리 부하가 낮아지지만, 로그인 세션 유지 등을 처리하기 위해 응용층 수준에서 <strong>쿠키(Cookie)</strong> 및 <strong>세션(Session)</strong> 메커니즘을 상위에 덧씌워 보완한다.</li>
<li><strong>전송층 매핑:</strong> 데이터의 유실 없는 정확한 전송을 보장하기 위해 기본적으로 <strong>TCP 포트 80번</strong>을 사용하여 상호 작용한다. (보안이 강화된 HTTPS는 TLS 암호화 레이어를 거쳐 <strong>TCP 포트 443번</strong>을 전담 사용한다.)</li>
</ul>
<h3 id="1143-http-메시지-포맷-및-상태-코드">11.4.3 HTTP 메시지 포맷 및 상태 코드</h3>
<ul>
<li><strong>요청 메시지 (Request Message):</strong> 첫 번째 라인인 <strong>요청 라인(Request Line)</strong>에 Method(GET, POST, PUT, DELETE), URL 경로, HTTP 버전을 기록한 후 헤더 필드들과 본문(Body)을 구성하여 전송한다.</li>
<li><strong>응답 메시지 (Response Message):</strong> 첫 번째 라인인 <strong>상태 라인(Status Line)</strong>에 HTTP 버전과 함께 처리 결과를 나타내는 <strong>상태 코드(Status Code)</strong>를 실어 보낸다.</li>
</ul>
<h4 id="주요-http-응답-상태-코드-분류">주요 HTTP 응답 상태 코드 분류</h4>
<ul>
<li><strong>200 OK:</strong> 클라이언트의 요청이 서버에서 성공적으로 처리되었음을 명시한다.</li>
<li><strong>301 Moved Permanently:</strong> 요청한 자원이 완전히 새로운 URL 주소로 영구 이동(Redirection)했음을 알린다.</li>
<li><strong>400 Bad Request:</strong> 클라이언트가 송신한 요청 구문 자체에 오류가 있어 서버가 파싱할 수 없는 상태이다.</li>
<li><strong>401 Unauthorized:</strong> 해당 자원에 접근하기 위해 필수적인 클라이언트 인증 자격 증명이 누락되었거나 실패했음을 뜻한다.</li>
<li><strong>404 Not Found:</strong> 요청한 URL에 해당하는 자원을 서버 내부에서 찾을 수 없음을 선언한다.</li>
<li><strong>500 Internal Server Error:</strong> 클라이언트의 요청은 정상이나, 서버 내부에서 로직 처리 중 예기치 못한 예외나 결함이 발생했음을 고지한다.</li>
</ul>
<hr>
<h2 id="115-전통적-표준-응용-프로토콜-ftp-전자우편-ssh">11.5 전통적 표준 응용 프로토콜 (FTP, 전자우편, SSH)</h2>
<h3 id="1151-ftp-file-transfer-protocol">11.5.1 FTP (File Transfer Protocol)</h3>
<p>네트워크 상에서 호스트 간 파일 전송을 전담하는 전통적인 프로토콜로, 두 개의 독립된 TCP 연결을 비대칭적으로 분리하여 사용하는 대역폭 분리 제어 특성을 가진다.</p>
<ul>
<li><strong>제어 연결 (Control Connection - TCP 21번 포트):</strong> 클라이언트와 서버 간의 명령어(Command) 송신 및 서버의 응답(Response) 코드를 교환하기 위한 제어 채널이다. 세션이 시작될 때 열려 종료될 때까지 반영구적으로 유지된다.</li>
<li><strong>데이터 연결 (Data Connection - TCP 20번 포트):</strong> 실제 디렉토리 리스트나 파일 데이터를 실질적으로 스트리밍 전송하는 채널이다. 파일 전송 요청이 들어올 때마다 동적으로 개설되며, 해당 파일 전송이 완료되는 즉시 자동으로 폐기(Teardown)된다.</li>
</ul>
<h3 id="1152-전자우편-시스템-e-mail-프로토콜-구조">11.5.2 전자우편 시스템 (E-mail 프로토콜 구조)</h3>
<p>메일 시스템은 메일을 작성 및 열람하는 <strong>UA(User Agent)</strong>, 메일을 서버 간에 릴레이 중계하는 <strong>MTA(Mail Transfer Agent)</strong>, 최종 사서함에서 클라이언트로 가져오는 <strong>MAA(Mail Access Agent)</strong>의 결합 구조이다.</p>
<pre><code class="language-code">[송신 UA] ──(SMTP)──&gt; [송신 메일 서버 (MTA)] ──(SMTP)──&gt; [수신 메일 서버 (MTA)] ──(POP3/IMAP)──&gt; [수신 UA]</code></pre>
<ul>
<li><strong>SMTP (Simple Mail Transfer Protocol):</strong> 메일을 송신 호스트에서 메일 서버로 업로드하거나, 메일 서버와 메일 서버 간에 인터넷망을 거쳐 메일을 라우팅 중계할 때 사용하는 푸시(Push) 방식의 프로토콜이다. <strong>TCP 포트 25번</strong>을 사용하며, 오직 7비트 ASCII 텍스트 구조만 지원하므로 멀티미디어 첨부파일 전송을 위해 <strong>MIME(Multipurpose Internet Mail Extensions)</strong> 인코딩 표준을 연동한다.</li>
<li><strong>POP3 (Post Office Protocol version 3):</strong> 수신 메일 서버의 사서함으로부터 클라이언트의 UA로 메일을 다운로드하는 팝(Pull) 방식의 프로토콜이다. <strong>TCP 포트 110번</strong>을 사용하며, 기본적으로 메일을 로컬로 가져오는 즉시 서버 사서함에서 데이터를 자동 삭제하는 단방향 동기화 특성을 가진다.</li>
<li><strong>IMAP (Internet Message Access Protocol):</strong> POP3의 단점을 보완한 최신 메일 액세스 프로토콜이다. <strong>TCP 포트 143번</strong>을 전담하며, 메일을 로컬로 내려받아도 서버 사서함에 원본 데이터가 그대로 잔존한다. 서버 내에 사용자 정의 폴더를 구성하고 여러 단말(스마트폰, PC 등)에서 접속해도 사서함 보관 상태가 실시간으로 동기화된다.</li>
</ul>
<h3 id="1153-secure-shell-ssh">11.5.3 Secure Shell (SSH)</h3>
<p>보안 기능이 없는 기존의 텔넷(Telnet, TCP 23번 포트)을 대체하여, 암호화되지 않은 네트워크망 상에서도 원격지의 서버를 안전하게 제어하고 명령을 실행할 수 있도록 지원하는 암호화 세션 프로토콜이다. 기본적으로 <strong>TCP 포트 22번</strong>을 사용한다.</p>
<ul>
<li><strong>SSH의 3대 핵심 보안 계층 아키텍처:</strong><ol>
<li><strong>SSH-TRANS (Transport Layer Protocol):</strong> 공개키 암호화(RSA 등)를 기반으로 서버의 신원을 인증(MITM 공격 방지)하고, 세션에 사용할 대칭키를 안전하게 교환하여 통신 전 구간에 대한 <strong>기밀성(Confidentiality)</strong>과 데이터 <strong>무결성(Integrity)</strong> 레이어를 수립하는 하부 물리적 보안 채널이다.</li>
<li><strong>SSH-AUTH (Authentication Protocol):</strong> TRANS 계층 상에 보안 터널이 수립된 후, 서버가 접속하려는 클라이언트(사용자)의 계정 권한 정당성을 검증하는 프로토콜이다. 패스워드 방식이나 클라이언트의 공개키/개인키 쌍을 활용해 사용자 인증을 수행한다.</li>
<li><strong>SSH-CONN (Connection Protocol):</strong> 클라이언트 인증이 최종 완료되면, 수립된 단일 보안 터널 내부를 논리적으로 쪼개어 가상 <strong>다중 채널(Logical Channels)</strong>들을 개설 및 관리하는 계층이다.</li>
</ol>
</li>
<li><strong>SSH-CONN이 생성하는 주요 논리 채널 서비스:</strong><ul>
<li><strong>Interactive Shell:</strong> 원격 명령행 터미널 환경에 다이렉트로 접속해 원격 제어 명령 실행</li>
<li><strong>포트 포워딩 (Port Forwarding):</strong> 보안 기능이 없는 다른 애플리케이션의 일반 트래픽을 SSH의 강력한 암호화 터널 내부로 통과시켜 우회 중계하는 터널링 기능</li>
<li><strong>SFTP / SCP:</strong> 안전하게 암호화된 채널 구조를 활용해 원격 호스트 간 파일을 송수신하는 보안 파일 전송 체계</li>
</ul>
</li>
</ul>
<hr>
<h2 id="116-소켓-인터페이스-프로그래밍-socket-interface">11.6 소켓 인터페이스 프로그래밍 (Socket Interface)</h2>
<p>소켓(Socket)은 응용 프로그램 레이어와 전송 계층 커널 레이어 사이의 데이터 입출력을 중계하는 추상화된 핵심 API 인터페이스 인프라이다. 응용 프로그램 입장에서는 파일 디스크립터(File Descriptor)와 동일하게 취급되어 읽기/쓰기 연산으로 통신을 수행한다.</p>
<h3 id="1161-tcp-연결-지향형-소켓-통신-시퀀스">11.6.1 TCP 연결 지향형 소켓 통신 시퀀스</h3>
<p>TCP 통신은 사전에 3-Way Handshake가 완벽히 수립되어야 하므로 서버와 클라이언트 간의 시스템 콜(System Call) 함수 시퀀스가 정교하게 맞물려 구동된다.</p>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/c9f3c395-158f-4684-94f0-b24bebfcdbf0/image.png" alt=""></p>
<h4 id="서버-측-실행-함수-흐름-passive-open">서버 측 실행 함수 흐름 (Passive Open)</h4>
<ol>
<li><strong><code>socket()</code></strong>: 통신 종단점인 소켓 객체를 메모리에 최초로 생성한다. (프로토콜 패밀리 및 소켓 타입 정의)</li>
<li><strong><code>bind()</code></strong>: 생성된 소켓에 실제 통신 인터페이스 인프라의 논리 주소 정보인 <strong>[IP 주소 + 포트 번호] 구조체(sockaddr_in)</strong>를 커널 단에 결합 및 등록한다.</li>
<li><strong><code>listen()</code></strong>: 클라이언트의 Active Open 접속 요청을 수용하기 위해 해당 포트를 열고 연결 요청 대기 큐(Queue)의 크기를 지정하여 수동 대기 상태로 진입한다.</li>
<li><strong><code>accept()</code></strong>: 연결 대기 큐에서 대기 중인 클라이언트의 SYN 패킷을 확인하고 요청을 꺼내어 승인한다. 내부적으로 <strong>3-Way Handshake 연산이 완료되는 지점</strong>이며, 커널은 실제 응용 데이터 송수신만을 전담할 <strong>새로운 통신 전용 소켓(Connected Socket)</strong>을 복제하여 반환한다. (기존 Listen 소켓은 계속 다음 클라이언트 대기 업무 수행)</li>
<li><strong><code>read() / write()</code></strong> 또는 <code>recv() / send()</code>: 연결이 수립된 복제 소켓의 버퍼를 통해 실질적인 애플리케이션 데이터를 입출력한다.</li>
<li><strong><code>close()</code></strong>: 데이터 송수신 완료 시 세션을 종료하고 소켓 자원을 커널 메모리에 반환한다. (4-Way Handshake 유발)</li>
</ol>
<h4 id="클라이언트-측-실행-함수-흐름-active-open">클라이언트 측 실행 함수 흐름 (Active Open)</h4>
<ol>
<li><strong><code>socket()</code></strong>: 클라이언트 전용 소켓을 생성한다.</li>
<li><strong><code>connect()</code></strong>: 서버의 IP 주소와 수신 대기 중인 Well-known 포트 주소를 기재하여 <strong>서버 측의 <code>accept()</code>를 향해 명시적인 연결 요청 패킷(SYN)</strong>을 송신한다. 이 시점에 클라이언트 커널은 Ephemeral 포트 대역에서 비어있는 포트 번호 하나를 임시로 자동 할당(Auto-binding)한다.</li>
<li><strong><code>write() / read()</code></strong>: 서버의 승인을 받아 핸드셰이크가 완벽히 수립되면 데이터를 송수신한다.</li>
<li><strong><code>close()</code></strong>: 세션을 먼저 닫으며 Active Close 주체가 된다.</li>
</ol>
<hr>
<h2 id="스스로-확인해보기">스스로 확인해보기</h2>
<h3 id="-웹-및-표준-응용-프로토콜-">[ 웹 및 표준 응용 프로토콜 ]</h3>
<p><strong>Q1. HTTP 프로토콜의 &#39;비상태성(Stateless)&#39; 특성을 정의하고, 이를 극복하여 상위 웹 응용 계층에서 로그인 세션을 유지하기 위해 도입한 상호 보완 메커니즘을 기술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 비상태성이란 서버가 클라이언트의 이전 상태나 요청 이력을 기억하지 않고 모든 요청을 독립된 개체로 처리하는 특성이다. 이를 보완하여 상태를 유지하기 위해, 클라이언트 브라우저에 상태 값을 저장하는 <strong>쿠키(Cookie)</strong>와 서버 메모리 버퍼 상에 사용자 정보를 매핑하여 저장하는 <strong>세션(Session)</strong> 메커니즘을 연동하여 관리한다.</li>
</ul>
<p><strong>Q2. FTP 프로토콜이 가동하는 두 가지 독립된 TCP 연결의 명칭과 각각의 기본 포트 번호 및 역할을 서술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 1. <strong>제어 연결 (TCP 21번 포트):</strong> 클라이언트와 서버 간의 명령어 전송 및 응답 코드 교환을 전담하며 세션 동안 유지된다.<ol start="2">
<li><strong>데이터 연결 (TCP 20번 포트):</strong> 실제 파일 데이터 및 디렉토리 리스트의 실질적 스트리밍 전송을 담당하며, 전송 요청 시마다 생성되었다가 전송 완료 즉시 폐기된다.</li>
</ol>
</li>
</ul>
<p><strong>Q3. 전자우편 시스템에서 메일 서버 간에 메일을 중계 라우팅할 때 사용하는 프로토콜의 명칭과 전송층 포트 번호를 쓰고, 최종 수신 호스트가 자신의 메일 서버 사서함에서 메일을 읽어올 때 다중 단말 간의 실시간 보관 상태 동기화를 지원하는 최신 액세스 프로토콜의 명칭을 쓰시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 메일 서버 간 중계 프로토콜은 <strong>SMTP (TCP 25번 포트)</strong>이며, 다중 단말 간 실시간 상태 동기화를 완벽히 지원하는 수신 액세스 프로토콜은 <strong>IMAP (TCP 143번 포트)</strong>이다.</li>
</ul>
<p><strong>Q4. SSH 보안 아키텍처 중, 하부의 TRANS 보안 터널이 수립된 직후 가동되어 다중 쉘 터미널 세션, SFTP 파일 전송, 타 응용 트래픽 암호화 터널링(포트 포워딩) 등의 가상 논리 채널들을 생성 및 제어하는 계층 프로토콜의 명칭을 쓰시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> SSH-CONN (SSH Connection Protocol)</li>
</ul>
<h3 id="-소켓-프로그래밍-">[ 소켓 프로그래밍 ]</h3>
<p><strong>Q5. TCP 연결 지향형 소켓 통신 환경에서 서버 측 라우터 및 호스트가 특정 포트 번호를 열고 대기하다가, 클라이언트와의 3-Way Handshake 동기화가 완벽히 완료되는 순간 커널이 호출을 해제하며 실질적인 데이터 송수신만을 전담할 &#39;새로운 복제 소켓&#39;을 반환하는 시스템 콜 함수의 명칭을 쓰시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> <code>accept()</code> 함수</li>
</ul>
<hr>
<h2 id="핵심-요약">핵심 요약</h2>
<ul>
<li><strong>HTTP 프로토콜:</strong> TCP 80번(HTTPS는 TLS 결합 443번) 포트 기반. 비상태성(Stateless) 구조를 가지며 쿠키와 세션으로 한계를 보완. 200(성공), 301(이동), 404(자원 없음), 500(서버 내부 오류) 등의 상태 코드로 응답 제어 명시.</li>
<li><strong>FTP 분리 제어:</strong> L4 단에서 TCP 21번(명령어 제어 채널)과 TCP 20번(순수 데이터 스트리밍 채널)을 이중 분리 분배하여 대역폭 간섭 배제.</li>
<li><strong>이메일 메커니즘:</strong> 서버 간 푸시 및 업로드는 SMTP(TCP 25번, 7비트 ASCII 규격 제한으로 MIME 연동)가 전담. 클라이언트의 사서함 팝 다운로드는 POP3(TCP 110번, 단방향 삭제) 또는 IMAP(TCP 143번, 다중 단말 실시간 양방향 동기화)가 전담 수행.</li>
<li><strong>SSH 아키텍처:</strong> TCP 22번 포트 가동. SSH-TRANS(암호화/기밀성/무결성 터널 수립) $\rightarrow$ SSH-AUTH(사용자 인증) $\rightarrow$ SSH-CONN(쉘 세션 및 암호화 포트 포워딩 다중 채널 운영)의 3단계 레이어 구조 확립.</li>
<li><strong>TCP 소켓 시퀀스:</strong> 서버는 <code>socket()</code> $\rightarrow$ <code>bind()(주소 바인딩)</code> $\rightarrow$ <code>listen()(대기)</code> $\rightarrow$ <code>accept()(핸드셰이크 완료 및 통신 소켓 복제 반환)</code> 순서로Passive Open 수행. 클라이언트는 <code>socket()</code> 생성 후 서버 주소를 명시한 <code>connect()</code> 호출을 통해 Active Open을 유발하여 세션 동기화.</li>
</ul>
<hr>
<h2 id="참고문헌">참고문헌</h2>
<ul>
<li>Forouzan, B. A. (2013). Data Communications and Networking (6th ed.). McGraw-Hill.</li>
<li>번역: 이재광, 김중규, 이경현, 홍충선. 데이터 통신과 네트워킹 TCP/IP 프로토콜 기반 (개정 6 수정판). 퍼스트북.</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[# [컴퓨터 네트워크] 10장 - 전송층 ]]></title>
            <link>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-10%EC%9E%A5-%EC%A0%84%EC%86%A1%EC%B8%B5</link>
            <guid>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-10%EC%9E%A5-%EC%A0%84%EC%86%A1%EC%B8%B5</guid>
            <pubDate>Tue, 02 Jun 2026 07:19:47 GMT</pubDate>
            <description><![CDATA[<h2 id="101-전송층-서비스-개요">10.1 전송층 서비스 개요</h2>
<p>전송층(Transport Layer)은 네트워크층이 제공하는 호스트 간(Host-to-host) 통신 서비스를 확장하여, 최종 종단 시스템 내에서 실행 중인 <strong>프로세스 간(Process-to-process) 통신</strong>을 책임지는 계층이다.</p>
<pre><code class="language-code">[ Application Layer: Processes ]  &lt;--- 포트 / 소켓 인터페이스
│
( Transport Layer )         &lt;--- 프로세스 간 신뢰성/비신뢰성 제어 (L4)
│
[ Network Layer: Hosts ]       &lt;--- 호스트 간 패킷 라우팅 (L3)</code></pre>
<h3 id="1011-다중화-및-역다중화-multiplexing--demultiplexing">10.1.1 다중화 및 역다중화 (Multiplexing / Demultiplexing)</h3>
<ul>
<li><strong>다중화 (Multiplexing):</strong> 송신 호스트의 여러 응용 프로세스로부터 나오는 데이터 조각들을 수집하여, 각각 전송층 헤더(포트 번호 등)를 부착하고 하위 계층인 네트워크층으로 단일 스트림 형태로 밀어내는 과정이다.</li>
<li><strong>역다중화 (Demultiplexing):</strong> 수신 호스트의 전송층이 네트워크층으로부터 세그먼트를 받아 헤더의 목적지 포트 번호를 파싱한 뒤, 상위 계층의 정확한 소켓(Socket) 인터페이스를 거쳐 해당 프로세스에게 전달하는 과정이다.</li>
</ul>
<h3 id="1012-포트port와-소켓socket-주소-체계">10.1.2 포트(Port)와 소켓(Socket) 주소 체계</h3>
<ul>
<li><strong>포트 번호 (16비트):</strong> 응용 프로세스를 식별하는 논리적 주소로, $0 \sim 65,535$ 범위를 가진다.<ul>
<li><strong>Well-known Ports ($0 \sim 1,023$):</strong> IANA에서 지정한 범용 공공 서비스 포트 (예: HTTP=80, HTTPS=443, FTP=21, SSH=22, DNS=53)</li>
<li><strong>Registered Ports ($1,024 \sim 49,151$):</strong> 특정 벤더나 응용 프로그램이 등록하여 사용하는 포트</li>
<li><strong>Dynamic/Private Ports ($49,152 \sim 65,535$):</strong> 클라이언트가 서버에 접속할 때 임시로 할당받는 동적 에페메럴(Ephemeral) 포트</li>
</ul>
</li>
<li><strong>소켓 주소 (Socket Address):</strong> <strong>[IP 주소 + 포트 번호]</strong>의 조합으로 정의되며, 인터넷 상에서 통신하는 프로세스의 유일한 종단점(Endpoint)을 명시한다.<ul>
<li><strong>UDP 소켓 식별 기준:</strong> 2-Tuple [목적지 IP, 목적지 포트]를 기준으로 역다중화 수행. 출발지가 달라도 목적지 포트가 같으면 동일한 UDP 소켓 버퍼로 유입된다.</li>
<li><strong>TCP 소켓 식별 기준:</strong> 4-Tuple [출발지 IP, 출발지 포트, 목적지 IP, 목적지 포트]의 조합이 완전히 일치해야 단 하나의 고유 소켓으로 맵핑된다.</li>
</ul>
</li>
</ul>
<hr>
<h2 id="102-udp-user-datagram-protocol">10.2 UDP (User Datagram Protocol)</h2>
<p>UDP는 RFC 768에 정의된 비연결형(Connectionless), 비신뢰성(Unreliable) 전송 프로토콜이다. 흐름 제어, 혼잡 제어, 순서 보장 기능이 없으며 최소한의 기능인 다중화와 체크섬 오류 검출만 수행하는 오버헤드 최소화 구조를 가진다.</p>
<h3 id="1021-udp-헤더-구조-8바이트-고정-헤더">10.2.1 UDP 헤더 구조 (8바이트 고정 헤더)</h3>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/4a62fa8b-2a10-43a8-ab8e-acd20cb4136e/image.png" alt=""></p>
<ul>
<li><strong>Source Port (16비트):</strong> 송신 프로세스의 포트 번호. 응답이 필요 없는 경우 전부 0으로 채울 수 있다.</li>
<li><strong>Destination Port (16비트):</strong> 수신 프로세스의 목적지 포트 번호.</li>
<li><strong>Length (16비트):</strong> UDP 헤더와 페이로드(데이터)를 합산한 <strong>UDP 세그먼트 전체의 길이</strong>를 바이트 단위로 표시한다. 최소값은 헤더만 존재할 때의 <code>8</code>이다.</li>
<li><strong>Checksum (16비트):</strong> 전송 중 세그먼트의 비트 오염 여부를 검출하는 필드이다. <ul>
<li><strong>의무 사항 아님:</strong> IPv4 환경에서 UDP 체크섬은 선택 사항(Optional)이므로 사용하지 않을 경우 전부 <code>0</code>으로 채운다. (단, IPv6에서는 상위 계층 체크섬 검출이 필수이므로 의무 사항으로 변경됨)</li>
<li><strong>의사 헤더 (Pseudo Header):</strong> 체크섬을 계산할 때 세그먼트 오류뿐만 아니라 패킷이 잘못된 호스트로 전달되는 오라우팅을 방지하기 위해 네트워크층 IP 헤더의 일부 정보(송신 IP, 수신 IP, 프로토콜 번호=17, UDP 길이)를 임시로 가져와 <strong>의사 헤더</strong>를 구성한 뒤 데이터 영역과 합산하여 1의 보수 연산을 수행한다.</li>
</ul>
</li>
</ul>
<hr>
<h2 id="103-tcp-transmission-control-protocol">10.3 TCP (Transmission Control Protocol)</h2>
<p>TCP는 RFC 793에 정의된 연결지향형(Connection-oriented), 신뢰성(Reliable) 전송 프로토콜이다. 가상 회선 스타일의 전이중(Full-Duplex) 바이트 스트림 서비스를 제공하며, 데이터 유실이나 순서 역전 현상을 하위 계층의 불완전성에도 불구하고 완벽히 복구 및 제어한다.</p>
<h3 id="1031-tcp-헤더-구조-2060-바이트-가변-헤더">10.3.1 TCP 헤더 구조 (20~60 바이트 가변 헤더)</h3>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/7f9d8961-5bd7-4e4d-8c40-b91372cbcbc6/image.png" alt=""></p>
<ul>
<li><strong>Source / Destination Port (각 16비트):</strong> 송수신 프로세스 식별 포트.</li>
<li><strong>Sequence Number (32비트):</strong> 송신자가 전송하는 바이트 스트림 중 <strong>해당 세그먼트에 실려가는 데이터의 첫 번째 바이트에 부여된 고유 번호</strong>이다. 초기 연결 시 난수로 초기 순서 번호(ISN: Initial Sequence Number)를 설정하여 보안성을 확보한다.</li>
<li><strong>Acknowledgment Number (ACK, 32비트):</strong> 수신측이 송신측으로 보내는 응답 번호이다. TCP는 <strong>누적 ACK(Cumulative ACK)</strong> 방식을 사용하므로, 수신자가 다음에 받기를 기대하는 &quot;직전 수신 완료 바이트 번호 + 1&quot;을 기록하여 전송한다. (예: 100번 바이트까지 성공적으로 받았다면 ACK 번호는 101이 된다.)</li>
<li><strong>HLEN (Header Length, 4비트):</strong> TCP 헤더의 총 길이를 4바이트 워드 단위로 표시한다. 옵션이 없으면 <code>5</code> (<code>20바이트</code>), 최대로 포함되면 <code>15</code> (<code>60바이트</code>)이다.</li>
<li><strong>제어 플래그 (Flags, 6비트 / 최근 혼잡제어 플래그 확장 시 9비트):</strong><ul>
<li><strong>SYN:</strong> 연결 수립 및 순서 번호 동기화를 요청하는 플래그</li>
<li><strong>ACK:</strong> 수신 완료 확인 응답 필드가 유효함을 지시하는 플래그 (첫 SYN 패킷을 제외한 모든 패킷에 기본 활성화)</li>
<li><strong>FIN:</strong> 송신 데이터가 종료되었으며 연결을 해제하고자 함을 알리는 플래그</li>
<li><strong>RST:</strong> 연결 관계의 비정상적 가동 중단이나 재설정을 강제 트리거하는 플래그</li>
</ul>
</li>
<li><strong>Window Size (16비트):</strong> 수신자가 현재 자신의 수신 버퍼 여유 공간 크기를 송신자에게 알려주는 필드로, <strong>흐름 제어(Flow Control)</strong>의 핵심 지표가 된다. 바이트 단위를 사용한다.</li>
</ul>
<hr>
<h3 id="1032-연결-수립-및-해제-메커니즘">10.3.2 연결 수립 및 해제 메커니즘</h3>
<h4 id="1-3-way-handshake-연결-설정">1) 3-Way Handshake (연결 설정)</h4>
<p>송신자와 수신자가 논리적인 연결을 맺고 호스트 가동 버퍼 공간 및 ISN을 동기화하는 과정이다.</p>
<pre><code class="language-code">Client (Active Open)                           Server (Passive Open)
│                                                  │
│ --------- [ SYN, Seq=x ] ----------------------&gt; │ (SYN_RCVD)
│                                                  │
│ &lt;-------- [ SYN+ACK, Seq=y, Ack=x+1 ] ---------- │
│                                                  │
│ --------- [ ACK, Seq=x+1, Ack=y+1 ] -----------&gt; │ (ESTABLISHED)</code></pre>
<h4 id="2-4-way-handshake-연결-해제">2) 4-Way Handshake (연결 해제)</h4>
<p>전이중 통신 관계를 안전하게 닫기 위해 상호 간에 FIN과 ACK를 개별적으로 교환하는 구조이다.</p>
<pre><code class="language-code">Client (Active Close)                          Server (Passive Close)
│                                                  │
│ --------- [ FIN, Seq=u ] ----------------------&gt; │ (CLOSE_WAIT)
│ &lt;-------- [ ACK, Ack=u+1 ] --------------------- │
│                                                  │ (상위 응용 데이터 전송 마무리 후)
│ &lt;-------- [ FIN, Seq=v ] ----------------------- │ (LAST_ACK)
│ --------- [ ACK, Ack=v+1 ] --------------------&gt; │
(TIME_WAIT)                                        │ (CLOSED)</code></pre>
<ul>
<li><strong>TIME_WAIT 상태의 필요성:</strong> Active Close를 수행한 주체는 마지막 ACK를 전송한 후 즉시 CLOSED 상태로 가지 않고, <strong>2 * MSL (Maximum Segment Lifetime)</strong> 시간 동안 수신 대기 상태를 유지한다. <ol>
<li>수신 측이 마지막 ACK를 받지 못해 FIN을 재전송할 경우 정상적으로 재응답을 처리하기 위함이다.</li>
<li>이전 연결 세션에서 네트워크에 지연되어 잔존하던 패킷이 연결 종료 후 새로 열린 동일 포트의 신규 세션에 유입되어 데이터 오염을 일으키는 것을 방지하기 위해 완전히 소멸할 시간을 벌어주는 목적이다.</li>
</ol>
</li>
</ul>
<hr>
<h2 id="104-슬라이딩-윈도우와-흐름-제어-flow-control">10.4 슬라이딩 윈도우와 흐름 제어 (Flow Control)</h2>
<p>송신자는 수신자의 수신 버퍼 오버플로우를 막기 위해 데이터 전송량을 제어해야 한다. 이를 <strong>흐름 제어(Flow Control)</strong>라 하며 TCP는 <strong>슬라이딩 윈도우(Sliding Window)</strong> 알고리즘을 사용한다.</p>
<ul>
<li><strong>동작 원리:</strong> 송신자는 수신자가 광고한 <code>Window Size</code>를 상한선으로 설정하여, ACK 응답을 받지 않고도 한 번에 연속으로 전송할 수 있는 데이터 바이트 한계 범위를 지정한다. 수신측으로부터 새로운 누적 ACK를 수신하면 윈도우의 시작점이 오른쪽으로 슬라이딩하며 전송 가능 범위를 갱신한다.</li>
<li><strong>전송 수식:</strong> 송신자가 보낼 수 있는 남은 가용 윈도우 크기는 다음과 같이 계산된다.
$$\text{EffectiveWindow} = \text{WindowSize} - (\text{LastByteSent} - \text{LastByteAcked})$$</li>
</ul>
<hr>
<h2 id="105-tcp-혼잡-제어-congestion-control">10.5 TCP 혼잡 제어 (Congestion Control)</h2>
<p>흐름 제어가 종단 간 수신자의 처리 능력을 맞추는 기법이라면, <strong>혼잡 제어(Congestion Control)</strong>는 네트워크 내부 링크의 트래픽 포화 및 라우터 버퍼 고갈(혼잡 현상)을 감지하고 전체 전송률을 조절하여 네트워크 붕괴를 막는 메커니즘이다. 송신자는 최종적으로 흐름제어 윈도우($rwnd$)와 혼잡제어 윈도우($cwnd$) 중 작은 값을 기준으로 전송량을 확정한다.</p>
<p>$$\text{MaxWindow} = \min(rwnd, cwnd)$$</p>
<h3 id="1051-제어-페이즈-tahoe-및-reno-표준-규격">10.5.1 제어 페이즈 (Tahoe 및 Reno 표준 규격)</h3>
<h4 id="1-느린-시작-slow-start">1) 느린 시작 (Slow Start)</h4>
<ul>
<li><strong>동작 매커니즘:</strong> 연결 초기 또는 타임아웃 이후 혼잡 상태를 탈출했을 때 적용된다. $cwnd$ 크기를 <code>1 MSS</code>에서 시작하여, 매 라운드(RTT)마다 수신되는 정상 ACK의 개수만큼 전송량을 누적 증폭시킨다. 즉, RTT마다 <strong>윈도우 크기가 2배씩 지수 함수 형태(Exponential)로 급격히 증가</strong>한다.</li>
<li><strong>임계치 조건:</strong> $cwnd$가 혼잡 임계치인 임계값(<strong>ssthresh</strong>: Slow Start Threshold)에 도달하면 선형 증가 페이즈인 혼잡 회피 단계로 전환된다.</li>
</ul>
<h4 id="2-혼잡-회피-congestion-avoidance">2) 혼잡 회피 (Congestion Avoidance)</h4>
<ul>
<li><strong>동작 매커니즘:</strong> 혼잡 임계치($ssthresh$) 이상으로 전송량이 커지면 급격한 오버플로우를 막기 위해 매 RTT마다 $cwnd$ 크기를 <strong>선형적으로 단 <code>1 MSS</code>씩만 가산 증가</strong> 시킨다. 이를 <strong>AIMD (Additive Increase, Multiplicative Decrease)</strong> 방식의 가산 증가 구간이라 한다.</li>
</ul>
<h4 id="3-빠른-재전송-및-빠른-회복-fast-retransmit--fast-recovery">3) 빠른 재전송 및 빠른 회복 (Fast Retransmit &amp; Fast Recovery)</h4>
<ul>
<li><strong>3개의 중복 ACK (3 Duplicate ACKs):</strong> 송신자가 타임아웃 타이머가 만료되기 전이라도, 수신측으로부터 완전히 동일한 번호의 중복 ACK 메시지를 연속으로 3번 수신(<code>총 4번의 동일 ACK</code>)하면 해당 번호의 세그먼트가 중간에 유실되었음을 인지하고 즉시 재전송을 수행하는 기법이다.</li>
<li><strong>버전별 제어 분기 동작:</strong><ul>
<li><strong>TCP Tahoe:</strong> 패킷 유실(타임아웃 및 중복 ACK 모두 포함) 감지 시 $ssthresh$ 값을 현재 $cwnd$ 크기의 절반($\frac{cwnd}{2}$)으로 깎고, $cwnd$를 다시 <code>1 MSS</code>로 완전 초기화한 후 Slow Start를 강제 재시작한다.</li>
<li><strong>TCP Reno (현대 표준 인프라 방식):</strong> 3개의 중복 ACK를 만나면 타임아웃보다 경미한 혼잡으로 판단하여 <strong>빠른 회복(Fast Recovery)</strong> 단계를 밟는다. $ssthresh$와 $cwnd$를 동시에 현재 윈도우의 절반 크기로 동일하게 절감시키고($cwnd = \frac{cwnd}{2}$), 1부터 시작하지 않고 절반 크기 지점부터 곧바로 혼잡 회피(선형 증가) 페이즈로 돌입한다. (타임아웃 발생 시에는 Reno도 완전히 1로 초기화함)</li>
</ul>
</li>
</ul>
<hr>
<h2 id="106-차세대-전송-계층-프로토콜">10.6 차세대 전송 계층 프로토콜</h2>
<h3 id="1061-quic-quick-udp-internet-connections">10.6.1 QUIC (Quick UDP Internet Connections)</h3>
<p>구글이 개발하고 RFC 9000으로 표준화된, UDP 인터페이스를 기반으로 하는 최신 차세대 전송 계층 프로토콜이다. (HTTP/3의 근간 인프라 기술)</p>
<ul>
<li><strong>도입 배경:</strong> 현대 웹 환경에서 TCP의 구조적 노후화로 인한 지연과 미들박스(방화벽 등) 간섭에 따른 경직화(Ossification) 문제를 해결하기 위해 도입되었다.</li>
<li><strong>핵심 기술 스펙:</strong><ol>
<li><strong>연결 수립 지연 단축 (0-RTT / 1-RTT):</strong> TCP의 3-Way Handshake와 TLS 암호화 핸드셰이크 과정을 단 하나의 결합된 레이어로 통합 처리하여 연결 설정 지연을 획기적으로 낮춘다. 이전 접속 이력이 있는 경우 0-RTT 전송도 가능하다.</li>
<li><strong>HOL (Head-of-Line) 차단 근본 해소:</strong> TCP는 단 하나의 패킷만 유실되어도 스트림 전체 버퍼가 정지되지만, QUIC는 단일 UDP 소켓 연결 내부에 독립적인 가상 <strong>다중 스트림(Multi-streaming)</strong>들을 운영하므로, 특정 스트림 조각이 유실되어도 나머지 스트림의 데이터 전송은 차단 없이 정상 처리된다.</li>
<li><strong>연결 이동성 (Connection Migration):</strong> IP 주소를 기준으로 세션을 식별하지 않고 고유한 <strong>Connection ID</strong>를 헤더에 박아 전송하기 때문에 사용자가 와이파이(Wi-Fi)망에서 셀룰러(LTE/5G)망으로 물리적 네트워크 IP가 바뀌어도 끊김 없이 기존 전송 세션을 투명하게 유지할 수 있다.</li>
</ol>
</li>
</ul>
<h3 id="622-sctp-stream-control-transmission-protocol">6.2.2 SCTP (Stream Control Transmission Protocol)</h3>
<p>RFC 4960에 정의된 프로토콜로, TCP의 신뢰성 높은 연결 제어 특성과 UDP의 독립적 메시지 경계 지향 장점을 결합한 전송층 프로토콜이다.</p>
<ul>
<li><strong>핵심 기능:</strong><ul>
<li><strong>멀티스트리밍 (Multi-streaming):</strong> 단일 결합 연결(Association) 내부에 독립 순서가 보장되는 다중 스트림을 형성하여 HOL 차단 현상을 방지한다.</li>
<li><strong>멀티호밍 (Multi-homing):</strong> 하나의 종단 호스트가 여러 개의 IP 주소 인터페이스를 동시에 가질 수 있도록 지원하여, 메인 물리 경로에 네트워크 장애가 발생하더라도 백업 IP 경로로 데이터 흐름을 자동 우회시켜 높은 고가용성(High Availability) 신뢰성을 보장한다. 통신사 시그널링망 및 서비스 인프라 제어 평면에서 주로 활성 운영된다.</li>
</ul>
</li>
</ul>
<hr>
<h2 id="스스로-확인해보기">스스로 확인해보기</h2>
<h3 id="-전송층-일반론-및-udp-">[ 전송층 일반론 및 UDP ]</h3>
<p><strong>Q1. TCP 소켓을 고유하게 식별하기 위해 커널 헤더 파싱 시 반드시 참조해야 하는 4-Tuple의 구성 요소를 기술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 출발지 IP 주소, 출발지 포트 번호, 목적지 IP 주소, 목적지 포트 번호의 4가지 조합이다.</li>
</ul>
<p><strong>Q2. UDP 헤더 체크섬(Checksum) 연산 시, 하위 네트워크층인 IP 헤더 영역의 주소 정보를 임시로 수집하여 결합 연산하는 의사 헤더(Pseudo Header)의 도입 목적을 서술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 전송 중 세그먼트 자체의 비트 변형 검출뿐만 아니라, IP 패킷 전달 과정의 결함으로 인해 잘못된 수신 호스트로 데이터그램이 잘못 도달하는 오라우팅(Misrouting) 오류 상황까지 네트워크층 경계를 넘어 상호 검증하여 완벽히 차단하기 위함이다.</li>
</ul>
<h3 id="-tcp-메커니즘-">[ TCP 메커니즘 ]</h3>
<p><strong>Q3. TCP 연결 해제 절차(4-Way Handshake) 중 Active Close를 수행한 호스트가 마지막 ACK를 송신한 직후 즉시 CLOSED 상태로 가지 않고 &#39;TIME_WAIT&#39; 상태를 일정 시간 동안 의무적으로 유지하는 전공적 이유 2가지를 기술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 1. 수신 측이 보낸 마지막 FIN 프레임에 대한 최종 ACK 응답 패킷이 중간에 유실되었을 경우, 상대방이 재전송한 FIN 패킷을 정상 수용하여 재응답을 처리하기 위함이다.<ol start="2">
<li>이전 세션 경로 상에 지연되어 잔존해 있던 낙오 패킷들이 완전히 소멸(MSL 시간 경과)하기 전에 동일한 포트로 신규 연결 세션이 수립되어 데이터가 왜곡 오염되는 것을 방지하기 위함이다.</li>
</ol>
</li>
</ul>
<p><strong>Q4. TCP 흐름 제어(Flow Control)에서 송신자가 현재 수신자의 수신 버퍼 여유 상태에 맞춰 보낼 수 있는 잔여 가용 윈도우 크기를 계산하는 수학적 상태 방정식을 관련 바이트 지표 변수명들을 포함하여 제시하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> $\text{EffectiveWindow} = \text{WindowSize} - (\text{LastByteSent} - \text{LastByteAcked})$</li>
</ul>
<p><strong>Q5. TCP Reno 혼잡제어 버전 환경에서 송신자가 3개의 중복 ACK를 연속 수신했을 때 실행하는 빠른 회복(Fast Recovery) 단계의 $cwnd$ 및 $ssthresh$ 임계치 제어 변화 수식을 기술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 현재 혼잡 감지 시점의 $cwnd$ 크기를 기준으로, $ssthresh = \frac{cwnd}{2}$, $cwnd = \frac{cwnd}{2}$ 로 동시에 절반으로 감소시킨 후 1부터 시작하지 않고 절반 크기 상태 지점에서 곧바로 혼잡 회피(선형 증가) 페이즈를 시작한다.</li>
</ul>
<h3 id="-차세대-프로토콜-">[ 차세대 프로토콜 ]</h3>
<p><strong>Q6. QUIC 프로토콜이 TCP의 고질적 한계인 HOL(Head-of-Line) 차단 현상을 구조적으로 해결하기 위해 단일 UDP 바인딩 연결 내부에 도입한 가상 채널 구조의 명칭과 동작 방식을 서술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 독립적인 <strong>다중 스트림(Multi-streaming)</strong> 구조를 사용한다. 하나의 UDP 연결 내부에 가상 채널들을 독립 병렬 운영하므로, 특정 스트림의 패킷 유실로 인해 버퍼가 정지되더라도 나머지 다른 스트림의 데이터 포워딩과 상위 응용 계층으로의 수신 전달은 차단 없이 정상 진행된다.</li>
</ul>
<hr>
<h2 id="핵심-요약">핵심 요약</h2>
<ul>
<li><strong>다중화 / 역다중화:</strong> L4 헤더 포트 주소를 기반으로 단일 프로세스 버퍼 채널을 통합 전송하고 분리 분배하는 커널 핵심 연산.</li>
<li><strong>UDP 스펙:</strong> 8바이트 고정 헤더, 체크섬 선택적 적용(의사 헤더 결합), 흐름 및 혼잡 제어가 없는 경량 전송 최적화 구조.</li>
<li><strong>3-Way / 4-Way 핸드셰이크:</strong> SYN/ACK 플래그 기반 제어 동기화. TIME_WAIT 상태 보장을 통한 가상 세션의 신뢰성 최종 검증.</li>
<li><strong>흐름 제어:</strong> Receiver Window($rwnd$) 광고 크기 한도 내에서 슬라이딩 윈도우 이동을 통해 종단 간 데이터 속도 조절.</li>
<li><strong>혼잡 제어:</strong> AIMD 구조를 채택. Slow Start(지수 증가) $\rightarrow$ ssthresh 도달 $\rightarrow$ 혼잡 회피(선형 증가) 단계를 거침. Reno 표준은 3개 중복 ACK 발생 시 윈도우를 1로 꺾지 않고 절반으로 감산하는 빠른 회복(Fast Recovery) 실행.</li>
<li><strong>차세대 프로토콜:</strong> QUIC는 UDP 기반의 0-RTT 연결과 ID 식별 기반 Connection Migration을 통해 인프라 이동성 확보. SCTP는 멀티호밍과 멀티스트리밍 기술을 구현하여 고가용성 네트워크 백본 제어 평면 장악.</li>
</ul>
<hr>
<h2 id="참고문헌">참고문헌</h2>
<ul>
<li>Forouzan, B. A. (2013). Data Communications and Networking (6th ed.). McGraw-Hill.</li>
<li>번역: 이재광, 김중규, 이경현, 홍충선. 데이터 통신과 네트워킹 TCP/IP 프로토콜 기반 (개정 6 수정판). 퍼스트북.</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[[컴퓨터 네트워크] 9장 - 네트워크층 패킷의 라우팅]]></title>
            <link>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-9%EC%9E%A5-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC%EC%B8%B5-%ED%8C%A8%ED%82%B7%EC%9D%98-%EB%9D%BC%EC%9A%B0%ED%8C%85</link>
            <guid>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-9%EC%9E%A5-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC%EC%B8%B5-%ED%8C%A8%ED%82%B7%EC%9D%98-%EB%9D%BC%EC%9A%B0%ED%8C%85</guid>
            <pubDate>Sun, 31 May 2026 06:25:33 GMT</pubDate>
            <description><![CDATA[<h1 id="컴퓨터-네트워크-9장---네트워크층-패킷의-라우팅">[컴퓨터 네트워크] 9장 - 네트워크층 패킷의 라우팅</h1>
<h2 id="91-라우팅-개요-및-알고리즘-분류">9.1 라우팅 개요 및 알고리즘 분류</h2>
<p>라우팅(Routing)은 송신지 네트워크 호스트에서 수신지 호스트까지 패킷이 이동할 최적의 경로를 결정하는 분산 알고리즘 매커니즘이다. 라우팅 알고리즘의 연산 결과물이 포워딩의 기준이 되는 자료구조인 <strong>라우팅 테이블(Routing Table)</strong>이 된다. 네트워크 토폴로지는 노드(라우터)와 엣지(링크 및 비용)를 가진 그래프 $G = (V, E)$로 표현된다.</p>
<h3 id="911-정보-관리-범위에-따른-분류">9.1.1 정보 관리 범위에 따른 분류</h3>
<ul>
<li><strong>글로벌 라우팅 알고리즘 (링크 상태 알고리즘):</strong> 모든 라우터가 네트워크의 완전한 토폴로지와 각 링크의 비용(Cost) 정보를 동시에 확보한 상태에서 연산을 수행한다. 전체 노드가 동일한 전체 맵을 기반으로 경로를 계산하며, 대표적으로 다익스트라(Dijkstra) 알고리즘이 이에 속한다.</li>
<li><strong>분산 라우팅 알고리즘 (거리 벡터 알고리즘):</strong> 각 라우터가 자신과 물리적으로 직접 연결된 이웃 라우터의 정보만을 교환하며, 반복적인 연산을 통해 점진적으로 최적 경로를 수렴해 나간다. 독립적으로 계산을 수행하며, 대표적으로 벨만-포드(Bellman-Ford) 알고리즘이 이에 속한다.</li>
</ul>
<hr>
<h2 id="92-라우팅-알고리즘-상세-dijkstra-vs-bellman-ford">9.2 라우팅 알고리즘 상세 (Dijkstra vs Bellman-Ford)</h2>
<h3 id="921-링크-상태link-state-라우팅-다익스트라-알고리즘">9.2.1 링크 상태(Link State) 라우팅: 다익스트라 알고리즘</h3>
<p>중앙 집중식 구조로, 모든 노드가 전체 토폴로지 맵을 공유하기 위해 <strong>링크 상태 패킷(LSP: Link State Packet)</strong>을 전체 네트워크에 플러딩(Flooding)한다. 이를 통해 모든 라우터는 완벽하게 일치하는 네트워크 지도(맵)를 동기화하여 보유하게 된다.</p>
<ul>
<li><strong>동작 원리:</strong> 특정 시작 노드로부터 다른 모든 노드까지의 최단 경로를 반복적으로 탐색하여 최단 경로가 완벽히 확정된 노드들의 집합인 확정 집합($N&#39;$)을 한 단계씩 넓혀간다.</li>
<li><strong>연산 매커니즘:</strong><ul>
<li>$D(v)$: 시작 노드로부터 목적지 노드 $v$까지의 현재 최단 경로 비용</li>
<li>$p(v)$: 최단 경로 상에서 노드 $v$의 바로 직전 노드(부모 노드)</li>
<li>$c(u,v)$: 노드 $u$와 $v$ 간의 직접적인 링크 비용 (연결되지 않은 이종 노드 간의 경우는 $\infty$)</li>
</ul>
</li>
<li><strong>반복 수식:</strong> 확정 집합 $N&#39;$에 속하지 않은 노드 중 $D(v)$가 최소인 노드 $w$를 선택하여 집합에 추가하고, $w$와 인접한 모든 이웃 노드들의 비용을 아래 수식으로 비교 및 갱신(Relaxation)한다.
$$D(v) = \min(D(v), D(w) + c(w,v))$$</li>
</ul>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/7e7dca7c-f29e-499b-9b0a-0fb91c613206/image.png" alt=""></p>
<h3 id="922-거리-벡터distance-vector-라우팅-벨만-포드-알고리즘">9.2.2 거리 벡터(Distance Vector) 라우팅: 벨만-포드 알고리즘</h3>
<p>분산형 및 반복형 구조로, 각 노드는 네트워크 전체 지도를 그리지 않는 대신 자신의 이웃 노드들과만 <strong>거리 벡터(Distance Vector)</strong> 정보를 주기적으로 비동기 교환한다.</p>
<ul>
<li><strong>동작 원리:</strong> 목적지까지 가는 최단 경로를 구하기 위해 벨만-포드 방정식(Bellman-Ford Equation)을 기반으로 자신의 테이블을 지속적으로 갱신한다. 이웃 라우터가 보낸 거리 벡터 값이 변경되거나 링크 비용이 변할 때만 국소적 갱신 연산이 트리거된다.</li>
<li><strong>수식 구조:</strong> 노드 $x$에서 목적지 $y$까지 가는 최단 경로 비용 $d_x(y)$는 다음과 같이 정의된다.
$$d_x(y) = \min_{v} { c(x,v) + d_v(y) }$$
<em>(여기서 $v$는 노드 $x$와 물리적으로 직접 연결된 모든 이웃 라우터들을 의미한다.)</em></li>
</ul>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/14f37b6f-27f6-46b7-89b6-9cdfdaeaa522/image.png" alt=""></p>
<h4 id="거리-벡터의-한계점과-해결책">거리 벡터의 한계점과 해결책</h4>
<ul>
<li><strong>Count-to-Infinity (무한대 수렴 문제):</strong> 네트워크 상에서 특정 링크의 비용이 감소하는 좋은 소식(Good News)은 전 네트워크에 즉시 반영되지만, 링크가 완전히 단절되거나 비용이 대폭 증가하는 나쁜 소식(Bad News)은 라우터 간의 잘못된 경로 정보가 서로 메아리처럼 순환 참조되면서 비용이 무한대로 커질 때까지 수렴하지 않고 패킷 루프를 유발하는 현상이 발생한다.</li>
<li><strong>포이즌 리버스 (Poison Reverse / Split Horizon):</strong> 무한 루프 문제를 완화하기 위한 경로 광고 제어 기술이다. 만약 노드 $Z$가 노드 $Y$를 거쳐서 목적지 $X$로 가고 있다면, $Z$는 $Y$에게 목적지 $X$까지의 거리 정보를 보낼 때 의도적으로 값을 무한대($\infty$)로 속여서 전달한다 ($d_Z(X) = \infty$). 이를 통해 $Y$가 $Z$의 정보를 신뢰하여 $Z$를 거쳐 다시 $X$로 가는 잘못된 경로 루프(양방향 경로 루프)를 형성하는 것을 사전에 완전히 차단한다.</li>
</ul>
<hr>
<h2 id="93-자율-시스템as과-라우팅-프로토콜">9.3 자율 시스템(AS)과 라우팅 프로토콜</h2>
<p>인터넷은 전 세계 모든 라우터를 단 하나의 알고리즘과 거대 테이블로 제어할 수 없기 때문에, 단일 관리 도메인 및 동일한 라우팅 정책 체제 하에 묶인 라우터 집합인 <strong>자율 시스템(AS: Autonomous System)</strong> 단위로 계층화하여 운영한다.</p>
<ul>
<li><strong>내부 라우팅 프로토콜 (IGP: Interior Gateway Protocol):</strong> 동일한 자율 시스템(AS) 내부의 라우터들끼리 경로 정보를 교환하기 위해 사용하는 프로토콜이다. 단일 관리 도메인 내부이므로 메트릭 최적화에 중점을 둔다. (예: RIP, OSPF)</li>
<li><strong>외부 라우팅 프로토콜 (EGP: Exterior Gateway Protocol):</strong> 서로 다른 독립된 AS 간의 도메인 연결 및 패킷 중계를 위해 사용하는 프로토콜이다. (예: BGP)</li>
</ul>
<hr>
<h3 id="931-rip-routing-information-protocol">9.3.1 RIP (Routing Information Protocol)</h3>
<ul>
<li><strong>기반 알고리즘:</strong> 거리 벡터(Distance Vector) 알고리즘 기반</li>
<li><strong>경로 결정 메트릭:</strong> <strong>홉 카운트(Hop Count)</strong>만을 유일한 경로 비용 기준으로 삼는다. 패킷이 통과하는 라우터의 개수만 단순 계산하기 때문에 링크의 실제 대역폭이나 속도, 전송 지연을 전혀 반영하지 못하는 한계가 있다.</li>
<li><strong>네트워크 크기 제한:</strong> 최대 홉 카운트는 <strong>15</strong>로 제한된다. 홉 카운트 <code>16</code>은 도달 불가능(Unreachable)한 유효하지 않은 경로를 의미하므로 대규모 백본 네트워크에는 적용이 전면 불가능하다.</li>
<li><strong>주기적 업데이트:</strong> 라우터들은 매 30초마다 자신의 전체 라우팅 테이블 내용을 이웃 라우터에게 UDP 포트 520번을 통해 브로드캐스트 또는 멀티캐스트 방식으로 전송한다. 만약 180초 동안 특정 경로에 대한 업데이트가 없으면 해당 경로는 무효화되며, 추가로 120초(Garbage Collection)가 지나면 테이블에서 완전히 삭제된다.</li>
</ul>
<h3 id="932-ospf-open-shortest-path-first">9.3.2 OSPF (Open Shortest Path First)</h3>
<ul>
<li><strong>기반 알고리즘:</strong> 링크 상태(Link State) 알고리즘 기반 (Dijkstra 알고리즘 사용)</li>
<li><strong>경로 결정 메트릭:</strong> 링크의 표준 대역폭을 기반으로 계산되는 <strong>비용(Cost)</strong>을 메트릭으로 사용한다. 수식은 다음과 같으며 속도가 빠른 고대역폭 링크일수록 메트릭 값이 작아져 최적 경로로 선택된다.
$$\text{Cost} = \frac{10^8}{\text{Bandwidth (bps)}}$$</li>
<li><strong>계층적 라우팅 지원:</strong> 자율 시스템을 내부적으로 다시 여러 개의 <strong>Backbone Area (Area 0)</strong>와 이와 직접 연결되는 일반 Area로 쪼개어 관리할 수 있다. 이 구조는 링크 상태 패킷(LSP)의 플러딩 범위를 특정 영역 내부로 국한시켜 대규모 네트워크 환경에서도 전체 토폴로지 변경에 따른 트래픽 과부하 없이 안정적으로 동작하도록 돕는다.</li>
<li><strong>보안 및 전송 특성:</strong> 라우팅 정보 교환 시 해시 기반 인증(Authentication) 매커니즘을 지원하며, TCP/UDP 상위 프로토콜을 거치지 않고 IP 페이로드 상에 프로토콜 번호 89번을 달고 직접 인캡슐화되어 전송된다. 멀티캐스트 주소(<code>224.0.0.5</code>, <code>224.0.0.6</code>)를 사용하여 효율적으로 동기화한다.</li>
</ul>
<h3 id="933-bgp-border-router-protocol">9.3.3 BGP (Border Router Protocol)</h3>
<ul>
<li><strong>기반 알고리즘:</strong> <strong>경로 벡터(Path Vector)</strong> 알고리즘 기반</li>
<li><strong>핵심 특성:</strong> 단순한 링크 비용이나 홉 카운트 계산을 넘어, 각 AS 관리자가 독립적으로 설정한 국가 간 조약, 비용 정책, 특정 국가 및 기관 장비 경유 금지 등의 <strong>정치적/경제적 정책(Policy-based Routing)</strong>을 기준으로 최적의 도메인 간 경로를 결정한다. 라우팅 정보 교환의 신뢰성을 위해 L4 TCP 프로토콜의 179번 포트를 사용하여 피어 간 반영구적인 세션을 유지한다.</li>
<li><strong>루프 방지 매커니즘:</strong> BGP 라우팅 정보 전송 시, 해당 경로 패킷이 거쳐온 자율 시스템 번호의 진행 리스트인 <strong>AS-PATH</strong> 속성을 헤더 명세에 담아 보낸다. 만약 수신한 AS-PATH 목록에 자신의 AS 번호가 이미 포함되어 있다면 루프가 발생한 것으로 판단하고 해당 라우팅 경로 정보를 즉시 폐기한다.</li>
<li><strong>세부 연결 구조:</strong><ul>
<li><strong>eBGP (External BGP):</strong> 서로 물리적으로 직접 연결된 다른 AS의 경계 라우터(Border Router) 간에 BGP 경로 정보를 교환하는 세션이다.</li>
<li><strong>iBGP (Internal BGP):</strong> 동일한 AS 내부의 라우터들끼리 AS 외부에 대한 라우팅 주소 정보를 공유하고 동기화하기 위해 내부에서 맺는 BGP 세션이다.</li>
</ul>
</li>
</ul>
<hr>
<h2 id="94-멀티캐스트-라우팅-multicast-routing">9.4 멀티캐스트 라우팅 (Multicast Routing)</h2>
<p>단일 송신자가 네트워크 상의 지정된 특정 그룹 수신자들(1-to-Many)에게 동시에 패킷을 한 번만 전송하여 대역폭 효율을 극대화하는 기술이다. 수신 호스트들은 멀티캐스트 IP 주소 클래스 D 대역($224.0.0.0 \sim 239.255.255.255$)을 목적지 주소로 활용한다.</p>
<h3 id="941-최적-트리-구축-매커니즘">9.4.1 최적 트리 구축 매커니즘</h3>
<p>멀티캐스트 패킷이 중복 복제되어 루프를 도는 것을 막고 모든 그룹 멤버에게 최소 경로로 도달하기 위해 그래프 상에 가상 트리를 형성한다.</p>
<ul>
<li><strong>RPF (Reverse Path Forwarding):</strong> 멀티캐스트 패킷의 무한 루프를 방지하는 근본 검증 기술이다. 라우터가 멀티캐스트 패킷을 수신하면 패킷의 목적지가 아닌 <strong>출발지 IP 주소</strong>를 역으로 확인한다. 만약 패킷이 들어온 입력 인터페이스가 유니캐스트 라우팅 테이블 상에서 해당 출발지 소스까지 가기 위해 사용하는 출력 인터페이스와 정확히 일치할 경우에만 정상 패킷으로 인정하여 포워딩(복제 및 전송)하고, 인터페이스가 일치하지 않으면 소스가 조작되었거나 루프된 패킷으로 판단하여 즉시 폐기(Drop)한다.</li>
</ul>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/3584752c-60b0-4c56-b2bd-ba1fb4723dd6/image.png" alt=""></p>
<ul>
<li><strong>송신자 기반 트리 (Source-Based Tree):</strong> 각 멀티캐스트 송신자(Source) 노드를 트리의 루트(Root)로 삼아 개별적으로 최단 경로 트리(SPT: Shortest Path Tree)를 형성하는 방식이다. 대표적인 프로토콜로 DVMRP, MOSPF가 있으며, 밀집 모드인 PIM-DM에서 활용된다. 라우터는 그룹당 소스별로 정보를 따로 관리해야 하므로 각 소스마다 독립적인 $(S, G)$ 상태 정보를 유지한다.</li>
<li><strong>공유 트리 (Shared Tree):</strong> 네트워크 내부에 <strong>랑데부 포인트(RP: Rendezvous Point)</strong> 혹은 코어(Core)라고 불리는 공용 중심 라우터를 하나 지정해 두고, 모든 송신자와 수신자가 이 RP를 중심으로 하나의 거대한 트리를 공유하여 통신하는 구조이다. 소스 개수와 관계없이 그룹별로 단 하나의 트리만 관리하면 되므로 라우터의 메모리 부담이 적다. 수신 단말이 적고 넓은 영역에 분산된 환경(Sparse Mode)에 적합하며 PIM-SM에서 이 방식을 채택한다. 상태 정보는 소스에 관계없이 $(*, G)$로 표기한다.</li>
</ul>
<hr>
<h2 id="95-그룹-멤버십-관리-프로토콜-igmp">9.5 그룹 멤버십 관리 프로토콜: IGMP</h2>
<p>IGMP(Internet Group Management Protocol)는 <strong>호스트와 로컬 라우터 간</strong>에 동작하며, 호스트가 어떤 멀티캐스트 그룹에 가입(Join)하거나 탈퇴(Leave)하려는지 서브넷 내부의 로컬 라우터에게 알려 브로드캐스트 도메인 내부의 그룹 멤버십 리스트를 동적으로 관리하는 프로토콜이다.</p>
<h3 id="951-igmp-버전별-특징-및-개선점">9.5.1 IGMP 버전별 특징 및 개선점</h3>
<ul>
<li><strong>IGMPv1:</strong> 가장 기본적인 구조로, 라우터가 그룹 가입 여부를 주기적으로 묻는 General Query를 전송하면 호스트가 가입 보고서(Membership Report)를 전송한다. 명시적인 탈퇴 메시지가 헤더 구조에 없기 때문에 호스트가 말없이 세션을 종료하면 라우터는 타임아웃이 발생할 때까지 불필요한 멀티캐스트 트래픽을 세그먼트에 계속 전송하는 대역폭 낭비가 생긴다.</li>
<li><strong>IGMPv2:</strong> <strong>명시적 그룹 탈퇴(Leave Group) 메시지가 신설</strong>되었다. 호스트가 그룹을 나갈 때 탈퇴 메시지를 보내면 라우터는 해당 링크에 그룹의 다른 수신자가 남아 있는지 최종 확인하기 위해 특정 그룹 전용 질의인 <strong>Group-Specific Query</strong>를 전송한다. 호스트는 Max Response Time 필드값 이내에 응답해야 하며, 이를 통해 자원 회수 대기 시간을 대폭 단축한다. 또한, 동일 서브넷 내에 여러 라우터가 존재할 때 쿼리를 총괄할 하나의 라우터만 남기는 <strong>Querier 선출 매커니즘</strong>이 추가되었다.</li>
<li><strong>IGMPv3 (송신자 필터링 지원):</strong> 멀티캐스트 소스 기반 필터링 기능이 도입되어, 호스트가 특정 그룹 가입 시 &quot;특정 송신자 $S$가 보내는 멀티캐스트 트래픽만 받겠다(<strong>INCLUDE</strong>)&quot; 혹은 &quot;특정 송신자 $S$가 보내는 트래픽만 제외하고 다 받겠다(<strong>EXCLUDE</strong>)&quot;를 리포트에 명시할 수 있다. 이를 통해 원치 않는 트래픽 유입을 물리적으로 사전 차단하여 대역폭 보안 및 라우터 자원 절약을 달성하고 <strong>SSM(Source-Specific Multicast)</strong> 환경을 완벽하게 지원한다.</li>
</ul>
<hr>
<h2 id="스스로-확인해보기">스스로 확인해보기</h2>
<h3 id="-라우팅-알고리즘-및-프로토콜-">[ 라우팅 알고리즘 및 프로토콜 ]</h3>
<p><strong>Q1. 다익스트라(Dijkstra)와 벨만-포드(Bellman-Ford) 알고리즘의 최적 경로 연산 범위 및 정보 교환 대상의 차이점을 기술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 다익스트라는 글로벌 링크 상태 알고리즘으로 모든 라우터가 플러딩을 통해 네트워크 전체 토폴로지 정보를 공유한 상태에서 최단 경로를 연산한다. 반면 벨만-포드는 분산형 거리 벡터 알고리즘으로 전체 토폴로지 맵 없이 물리적으로 인접한 이웃 라우터들과만 주기적으로 거리 벡터 정보를 교환하며 점진적으로 수렴한다.</li>
</ul>
<p><strong>Q2. 거리 벡터 라우팅에서 발생하는 &#39;Count-to-Infinity&#39; 장애 현상의 원인과 이를 완화하기 위한 &#39;포이즌 리버스(Poison Reverse)&#39;의 동작 원리를 서술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 나쁜 경로 비용 정보가 라우터 간에 순환 참조되면서 무한대로 커지는 현상이다. 포이즌 리버스는 노드 $Z$가 목적지 $X$로 가기 위해 이웃 노드 $Y$를 경유 경로로 선택한 경우, $Z$가 $Y$에게 경로 정보를 광고할 때 의도적으로 최단 거리 비용을 무한대($\infty$)로 선언하여 $Y$가 자신을 역참조하는 루프를 차단한다.</li>
</ul>
<p><strong>Q3. OSPF 프로토콜이 대규모 엔터프라이즈 네트워크 환경에서 라우팅 트래픽 폭증 문제를 해결하기 위해 지원하는 계층 구조의 명칭과 동작 상의 이점을 서술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 자율 시스템을 계층적 영역인 <strong>Area</strong> 단위로 분할하여 운영한다. 최상위 백본 영역(Area 0)과 일반 영역을 분리함으로써, 링크 상태 패킷(LSP)의 플러딩 범위를 전체 망이 아닌 개별 Area 내부로만 국한시켜 전체 네트워크의 트래픽 오버헤드를 획기적으로 줄여준다.</li>
</ul>
<p><strong>Q4. BGP 프로토콜에서 인터넷 라우팅 루프를 감지하고 원천 차단하기 위해 패킷 헤더 내에 삽입하여 전파하는 핵심 속성(Attribute)의 명칭과 판정 기준을 쓰시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> <strong>AS-PATH</strong> 속성이다. 경로 정보가 통과해 온 자율 시스템 번호(ASN)의 리스트를 기록하여 전송하며, 라우터가 수신한 AS-PATH 목록 내에 자신의 AS 번호가 이미 포함되어 있으면 루프 경로로 판단하고 해당 경로 정보를 즉시 폐기한다.</li>
</ul>
<h3 id="-멀티캐스트-및-igmp-">[ 멀티캐스트 및 IGMP ]</h3>
<p><strong>Q5. 멀티캐스트 라우팅에서 패킷의 네트워크 루프 및 중복 복제를 방지하기 위해 입력 인터페이스의 정당성을 검증하는 RPF(Reverse Path Forwarding)의 동작 매커니즘을 출발지 주소 관점에서 설명하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 멀티캐스트 패킷이 유입되었을 때, 패킷의 &#39;출발지 IP 주소&#39;를 확인한다. 유니캐스트 라우팅 테이블 상에서 해당 출발지 주소까지 도달하기 위해 사용하는 출력 인터페이스와 현재 패킷이 유입된 입력 인터페이스가 정확히 일치할 때만 패킷을 정상 수용하여 포워딩하고, 일치하지 않으면 폐기한다.</li>
</ul>
<p><strong>Q6. IGMPv2에서 호스트가 가상 그룹을 나갈 때 전송하는 메시지와, 이에 대응하여 로컬 라우터가 해당 링크에 그룹 수신 단말이 최종적으로 잔존하는지 파악하기 위해 전송하는 특수 제어 쿼리의 명칭을 쓰시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 호스트는 <strong>Leave Group(그룹 탈퇴)</strong> 메시지를 전송하고, 라우터는 이에 대응하여 <strong>Group-Specific Query(특정 그룹 전용 질의)</strong>를 전송하여 멤버십 잔존 여부를 확인한다.</li>
</ul>
<p><strong>Q7. IGMPv3가 이전 버전들과 차별화되는 가장 핵심적인 기능적 발전 요소를 필터 모드 키워드를 포함하여 서술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> <strong>송신자 필터링(Source Filtering)</strong> 기능이 도입되었다. 호스트가 멀티캐스트 그룹 가입 보고서를 보낼 때 특정 송신자 소스 주소 목록을 지정하여, 원하는 소스만 수신하는 <strong>INCLUDE</strong> 모드와 특정 소스를 차단하는 <strong>EXCLUDE</strong> 모드를 명시할 수 있어 대역폭 효율과 보안성이 비약적으로 향상되었다.</li>
</ul>
<hr>
<h2 id="핵심-요약">핵심 요약</h2>
<ul>
<li><strong>다익스트라(Dijkstra):</strong> 링크 상태 알고리즘, LSP 플러딩을 통한 전체 토폴로지 공유, 글로벌 최단 경로 수립.</li>
<li><strong>벨만-포드(Bellman-Ford):</strong> 거리 벡터 알고리즘, 이웃 간 국소적 정보 교환. 나쁜 소식의 느린 전파로 인한 Count-to-Infinity 루프 문제는 Split Horizon 및 Poison Reverse 기술로 차단.</li>
<li><strong>RIP:</strong> 거리 벡터 기반 IGP, 홉 카운트(최대 15홉 제한) 메트릭 사용, 대규모 망 적용 불가, 30초 주기 업데이트.</li>
<li><strong>OSPF:</strong> 링크 상태 기반 IGP, 대역폭 비용 메트릭 사용, 계층적 Area 분할 구조 지원을 통한 확장성 확보.</li>
<li><strong>BGP:</strong> 경로 벡터 기반 EGP, AS-PATH 속성을 통한 인터넷 인터-도메인 루프 완벽 방지, 정책/규약 기반 최적 경로 라우팅 수행.</li>
<li><strong>멀티캐스트 트리:</strong> RPF(역경로 검증) 매커니즘을 통과한 패킷만 전송. 소스 기반 트리(SPT, PIM-DM)와 공용 트리(RP 중심 공유 트리, PIM-SM) 구조로 세분화.</li>
<li><strong>IGMP 진화:</strong> v1(기본 가입) → v2(Leave 메시지와 Group-Specific Query 신설로 자원 고갈 최소화) → v3(INCLUDE/EXCLUDE 송신자 필터링 제어를 통한 SSM 아키텍처 완성).</li>
</ul>
<hr>
<h2 id="참고문헌">참고문헌</h2>
<ul>
<li>Forouzan, B. A. (2013). Data Communications and Networking (6th ed.). McGraw-Hill.</li>
<li>번역: 이재광, 김중규, 이경현, 홍충선. 데이터 통신과 네트워킹 TCP/IP 프로토콜 기반 (개정 6 수정판). 퍼스트북.</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[# [컴퓨터 네트워크] 7장 - 네트워크층: 데이터 전송]]></title>
            <link>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-7%EC%9E%A5-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC%EC%B8%B5-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%A0%84%EC%86%A1</link>
            <guid>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-7%EC%9E%A5-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC%EC%B8%B5-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%A0%84%EC%86%A1</guid>
            <pubDate>Sun, 31 May 2026 05:55:40 GMT</pubDate>
            <description><![CDATA[<h2 id="71-네트워크층-서비스-services">7.1 네트워크층 서비스 (Services)</h2>
<p>네트워크층은 송신 호스트로부터 수신 호스트까지 종단 간(End-to-end) 패킷 전달을 담당하는 계층이다. 상위 계층인 전송 계층(Transport Layer)이 프로세스 간(Process-to-process) 통신을 담당한다면, 네트워크층은 장치 간(Node-to-node) 통신을 책임진다.</p>
<h3 id="711-주요-기능-및-부가-기능">7.1.1 주요 기능 및 부가 기능</h3>
<ul>
<li><strong>패킷화 (Packetizing):</strong> 송신 측에서는 상위 계층의 데이터(페이로드)를 받아 네트워크층 헤더를 추가하는 캡슐화(Encapsulation)를 수행한다. 수신 측에서는 역캡슐화(Decapsulation)를 통해 상위 계층으로 페이로드를 전달한다. 이 과정에서 라우터는 패킷 내부의 페이로드를 변경하지 않고 헤더 정보만 참조하여 중계한다.</li>
<li><strong>라우팅 (Routing):</strong> 전체 네트워크 토폴로지를 기반으로 패킷이 송신지에서 목적지까지 이동할 최적의 경로를 백그라운드 알고리즘을 통해 결정하는 과정이다.</li>
<li><strong>포워딩 (Forwarding):</strong> 라우터의 입력 인터페이스로 유입된 패킷을 라우팅 테이블(Routing Table)을 참조하여 적절한 출력 인터페이스로 이동시키는 라우터 내부의 로컬 동작이다.</li>
<li><strong>오류 제어 및 기타 제어:</strong> IP 프로토콜 자체는 오류 검출 시 패킷을 단순히 폐기하는 비신뢰성 서비스이지만, 보완 프로토콜인 ICMP를 활용하여 송신 측에 오류 알림 메시지를 전송한다. 흐름 제어(Flow Control)와 혼잡 제어(Congestion Control)는 주로 전송 계층(TCP)에서 전담하지만, 네트워크층에서도 패킷 폐기나 명시적 혼잡 알림을 통해 일부 관여한다.</li>
</ul>
<hr>
<h2 id="72-패킷-교환-packet-switching">7.2 패킷 교환 (Packet Switching)</h2>
<p>네트워크층은 완벽한 패킷 교환(Packet-Switched) 방식을 채택하고 있다. 데이터는 패킷 단위로 분할되어 전송되며, 크게 비연결형인 데이터그램 방식과 연결지향형인 가상 회선 방식으로 나뉜다.</p>
<h3 id="721-데이터그램-네트워크-datagram-networks">7.2.1 데이터그램 네트워크 (Datagram Networks)</h3>
<p>인터넷(IP)의 기반이 되는 비연결형(Connectionless) 서비스 구조이다.</p>
<ul>
<li><strong>동작 특성:</strong> 데이터 송신 전에 경로를 설정하는 예약 과정이 전혀 없다. 각 패킷은 서로 독립된 객체로 취급되며, 동일한 목적지로 향하는 패킷이라도 네트워크 혼잡도에 따라 유동적으로 서로 다른 경로를 통해 전송될 수 있다.</li>
<li><strong>헤더 정보:</strong> 라우터가 독자적으로 경로를 찾아야 하므로, 데이터그램 헤더에는 항상 최종 목적지의 논리 주소(Destination IP Address)가 온전하게 포함되어야 한다.</li>
<li><strong>장단점:</strong> 특정 링크나 라우터에 장애가 발생해도 동적으로 다른 경로를 탐색하므로 결함 감내(Fault Tolerance) 능력이 뛰어나다. 그러나 패킷이 송신된 순서와 다르게 수신측에 도착하는 역전 현상(Out-of-order)이 발생하므로, 상위 계층(TCP)에서 재정렬 및 재조립을 수행해야 한다.</li>
</ul>
<h3 id="722-가상-회선-네트워크-virtual-circuit-networks">7.2.2 가상 회선 네트워크 (Virtual-Circuit Networks)</h3>
<p>과거 ATM, Frame Relay 등에서 주로 사용되던 연결지향형(Connection-oriented) 서비스 구조이다.</p>
<ul>
<li><strong>동작 특성:</strong> 데이터를 전송하기 전에 송수신 호스트 간에 논리적인 전용 경로인 가상 회선을 먼저 수립(Setup)한다. 설정된 경로가 유지되는 동안 모든 패킷은 반드시 동일한 물리적 라우터 경로를 순서대로 통과한다.</li>
<li><strong>헤더 정보 및 자원 관리:</strong> 패킷 헤더에 전체 목적지 IP 주소 대신 짧은 크기의 <strong>가상 회선 식별자(VCI: Virtual Circuit Identifier)</strong>를 삽입하여 전송한다. 라우터는 유입된 포트 번호와 VCI의 조합을 기반으로 다음 출력 포트와 변경될 가상 회선 식별자(VCI)를 레이블 스위칭 방식으로 맵핑하여 포워딩한다. 데이터 전송이 끝나면 설정된 회선을 명시적으로 해제(Teardown)해야 한다.</li>
<li><strong>장단점:</strong> 패킷이 항상 송신된 순서대로 정확히 도착하며 대역폭 예약이 가능하여 품질(QoS) 보장에 유리하다. 반면, 경로 상의 라우터 하나만 고장 나도 가상 회선 전체가 끊어지며 연결 수립에 따른 지연(Delay)이 필수적으로 발생한다.</li>
</ul>
<hr>
<h2 id="73-네트워크층의-성능-performance">7.3 네트워크층의 성능 (Performance)</h2>
<p>네트워크층의 성능지표는 크게 지연, 처리율, 패킷 손실률로 정량화된다.</p>
<h3 id="731-지연-유형-types-of-delay">7.3.1 지연 유형 (Types of Delay)</h3>
<p>하나의 패킷이 라우터를 통과하여 목적지에 도달할 때까지 발생하는 총 지연 시간은 다음 4가지 요소의 합으로 계산된다.</p>
<p>$$D_{\text{total}} = D_{\text{trans}} + D_{\text{prop}} + D_{\text{proc}} + D_{\text{queue}}$$</p>
<ul>
<li><strong>전송 지연 (Transmission Delay, $D_{\text{trans}}$):</strong> 패킷의 모든 비트를 물리적 매체(링크)로 밀어내는 데 걸리는 시간이다. 패킷의 길이($L$, bits)와 링크의 대역폭($B$, bps)에 의해 결정된다.
$$D_{\text{trans}} = \frac{L}{B}$$</li>
<li><strong>전파 지연 (Propagation Delay, $D_{\text{prop}}$):</strong> 신호가 물리적 매체를 통해 한 노드에서 다음 노드까지 이동하는 데 걸리는 시간이다. 두 노드 간의 거리($D$, m)와 매체 내에서의 전파 속도($V$, m/s)에 의해 결정된다.
$$D_{\text{prop}} = \frac{D}{V}$$</li>
<li><strong>처리 지연 (Processing Delay, $D_{\text{proc}}$):</strong> 라우터가 패킷을 수신한 후 헤더의 오류 검출(Checksum)을 수행하고, 라우팅 테이블을 검색하여 출력 인터페이스를 결정하는 데 소요되는 고정적 시간이다.</li>
<li><strong>큐잉 지연 (Queuing Delay, $D_{\text{queue}}$):</strong> 패킷이 출력 인터페이스 선택을 마치고 실제로 링크로 전송되기 전, 라우터 내부의 출력 큐(Buffer)에서 앞선 패킷들이 처리되기를 기다리는 대기 시간이다. 네트워크의 트래픽 밀도에 따라 가변적이며, 유입량이 처리량을 초과하면 무한정 늘어나다 결국 손실을 유발한다.</li>
</ul>
<hr>
<h2 id="74-ipv4-프로토콜">7.4 IPv4 프로토콜</h2>
<p>IPv4(Internet Protocol version 4)는 인터넷에서 가장 널리 사용되는 비연결형, 비신뢰성 패킷 전송 프로토콜이다. 시스템은 오류 제어나 흐름 제어 없이 최선형(Best-effort)으로만 패킷을 전달하며, 헤더의 크기는 옵션을 제외하면 고정 20바이트이다.</p>
<h3 id="741-ipv4-데이터그램-헤더-구조-2060-바이트">7.4.1 IPv4 데이터그램 헤더 구조 (20~60 바이트)</h3>
<ul>
<li><strong>Version (4비트):</strong> IP 프로토콜의 버전을 명시한다. IPv4이므로 <code>4</code> (<code>0100</code>)로 고정된다.</li>
<li><strong>IHL (Internet Header Length, 4비트):</strong> 헤더의 총 길이를 4바이트(32비트 워드) 단위로 나타낸다. 옵션이 없을 때 고정 헤더가 20바이트이므로 IHL 필드값은 최소 <code>5</code> (<code>0101</code>)이며, 옵션이 최대로 포함될 때(60바이트)는 <code>15</code> (<code>1111</code>)가 된다.</li>
<li><strong>Total Length (16비트):</strong> 헤더와 페이로드(데이터)를 합한 데이터그램 전체 길이를 바이트 단위로 표시한다. 최대 전송 가능한 데이터그램의 크기는 $2^{16} - 1 = 65,535$ 바이트이다.</li>
<li><strong>Time to Live (TTL, 8비트):</strong> 패킷이 네트워크 루프에 갇혀 무한히 순환하는 것을 방지하는 수명 필드이다. 라우터를 하나 통과(1 홉)할 때마다 이 값이 1씩 감소하며, <code>0</code>이 되는 순간 라우터는 패킷을 폐기하고 송신자에게 ICMP Time Exceeded 메시지를 전송한다.</li>
<li><strong>Protocol (8비트):</strong> IP 페이로드에 담긴 상위 계층 프로토콜이 무엇인지 정의한다. (예: ICMP = 1, TCP = 6, UDP = 17)</li>
<li><strong>Header Checksum (16비트):</strong> 데이터 영역을 제외한 오직 <strong>IP 헤더 영역의 오류</strong>만 검출하는 필드이다. 라우터를 통과할 때마다 TTL 필드가 변경되므로, 모든 라우터는 이 Checksum 값을 매 홉마다 재계산해야 한다.</li>
<li><strong>Source IP Address (32비트):</strong> 송신자의 IPv4 논리 주소이다.</li>
<li><strong>Destination IP Address (32비트):</strong> 최종 수신자의 IPv4 논리 주소이다.</li>
</ul>
<h3 id="742-단편화-및-재조립-fragmentation-and-reassembly">7.4.2 단편화 및 재조립 (Fragmentation and Reassembly)</h3>
<p>각 물리 네트워크 링크는 한 번에 전송할 수 있는 프레임의 최대 데이터 크기인 <strong>MTU(Maximum Transmission Unit)</strong> 한계치를 가진다. 유입된 IP 패킷의 크기가 출력 링크의 MTU보다 클 경우 라우터는 패킷을 쪼개는 단편화(Fragmentation)를 수행한다.</p>
<ul>
<li><strong>Identification (16비트):</strong> 동일한 원본 데이터그램에서 쪼개진 단편 패킷들이라는 것을 식별하기 위해 부여되는 고유 일련번호이다. 재조립 시 이 값이 같은 것끼리 묶는다.</li>
<li><strong>Flags (3비트):</strong> 단편화 제어를 위한 상태 플래그이다.<ul>
<li><strong>D비트 (Don&#39;t Fragment):</strong> 이 값이 <code>1</code>이면 라우터는 패킷을 단편화할 수 없다. 만약 MTU가 패킷보다 작은 링크를 만나면 패킷을 폐기하고 ICMP 오류를 반환한다.</li>
<li><strong>M비트 (More Fragments):</strong> 이 값이 <code>1</code>이면 뒤에 단편 패킷이 더 남아있음을 뜻하고, <code>0</code>이면 해당 패킷이 마지막 단편 조각임을 의미한다.</li>
</ul>
</li>
<li><strong>Fragment Offset (13비트):</strong> 원본 데이터그램의 전체 페이로드에서 해당 단편 조각의 데이터가 시작되는 상대적 위치를 나타낸다. 단위를 맞추기 위해 <strong>8바이트 단위</strong>의 오프셋 배수로 기록한다. 따라서 실제 바이트 위치를 구하려면 이 필드 값에 8을 곱해야 한다.</li>
</ul>
<blockquote>
<p><strong>단편화 계산 예제</strong></p>
<ul>
<li>원본 데이터그램: 전체 길이(Total Length) = 4020바이트 (헤더 20B + 데이터 4000B), Identification = 999</li>
<li>출력 링크의 MTU가 1420바이트일 때 (단편 패킷당 최대 데이터 크기는 $1420 - 20 = 1400$바이트이며, 1400은 8의 배수이므로 단편화 가능)</li>
</ul>
<ol>
<li><strong>첫 번째 단편:</strong> Total Length = 1420B (데이터 1400B), Flags(M=1), <strong>Offset = 0</strong> ($0 \div 8$)</li>
<li><strong>두 번째 단편:</strong> Total Length = 1420B (데이터 1400B), Flags(M=1), <strong>Offset = 175</strong> ($1400 \div 8$)</li>
<li><strong>세 번째 단편:</strong> Total Length = 1220B (데이터 1200B), Flags(M=0), <strong>Offset = 350</strong> ($2800 \div 8$)</li>
</ol>
<ul>
<li><strong>재조립의 주체:</strong> 단편화는 경로 상의 어떤 라우터에서든 일어날 수 있지만, <strong>재조립은 중간 라우터에서 절대 수행하지 않고 최종 목적지 호스트에서만 수행</strong>한다. 라우터의 연산 부담을 줄이고 패킷들이 서로 다른 경로로 이동할 수 있기 때문이다.</li>
</ul>
</blockquote>
<hr>
<h2 id="75-ipv6-프로토콜">7.5 IPv6 프로토콜</h2>
<p>IPv4의 32비트 주소 고갈 문제를 근본적으로 해결하기 위해 제정된 차세대 인터넷 프로토콜이다. 주소 공간을 <strong>128비트</strong>로 확장하여 사실상 무한대에 가까운 IP 주소를 제공한다.</p>
<h3 id="751-ipv6의-특징-및-개선점">7.5.1 IPv6의 특징 및 개선점</h3>
<ul>
<li><strong>기본 헤더 크기 고정:</strong> 헤더 구조를 단순화하여 옵션 필드를 기본 헤더에서 분리하고, <strong>40바이트 고정 크기 헤더</strong>를 채택하였다. 이로 인해 라우터의 패킷 처리 속도가 비약적으로 향상되었다.</li>
<li><strong>단편화 매커니즘의 변화:</strong> IPv6 환경에서는 <strong>중간 라우터가 패킷 단편화를 절대 수행하지 않는다.</strong> 송신 호스트가 데이터를 보내기 전 경로 상의 최소 MTU를 파악하는 <strong>Path MTU Discovery</strong>를 사전에 수행하여 링크 크기에 맞게 패킷을 생성해야 한다. 만약 라우터가 자신의 MTU보다 큰 IPv6 패킷을 만나면 즉시 패킷을 폐기하고 송신자에게 ICMPv6 &quot;Packet Too Big&quot; 메시지를 보낸다.</li>
<li><strong>체크섬 제거:</strong> 데이터 링크 계층(L2)과 전송 계층(L4)에서 오류 검출을 중복 수행하므로 라우터의 연산 오버헤드를 줄이기 위해 네트워크층 헤더 체크섬을 완전히 삭제했다.</li>
</ul>
<h3 id="752-ipv6-기본-헤더-구조-40-바이트-고정">7.5.2 IPv6 기본 헤더 구조 (40 바이트 고정)</h3>
<ul>
<li><strong>Version (4비트):</strong> IP 프로토콜 버전 번호이다. IPv6이므로 <code>6</code> (<code>0110</code>)이 기록된다.</li>
<li><strong>Traffic Class (8비트):</strong> IPv4의 Type of Service(ToS) 필드에 대응하며, 패킷의 클래스나 우선순위를 지정하여 서비스 품질(QoS) 차등화에 사용된다.</li>
<li><strong>Flow Label (20비트):</strong> 특정 송수신 간의 패킷 흐름(Flow)을 식별하기 위해 신설된 필드이다. 실시간 멀티미디어 트래픽 등 동일한 흐름에 속한 패킷들을 라우터가 내부적으로 동일 경로 및 동일 가상 회선처럼 신속하게 포워딩할 수 있도록 라우팅 효율을 극대화한다.</li>
<li><strong>Payload Length (16비트):</strong> 고정 헤더 40바이트를 <strong>제외한</strong> 뒤따르는 확장 헤더 및 상위 계층 데이터(페이로드)의 총 길이를 바이트 단위로 나타낸다.</li>
<li><strong>Next Header (8비트):</strong> IPv4의 Protocol 필드와 유사한 기능을 수행한다. 기본 헤더 바로 뒤에 이어지는 헤더가 어떤 유형(확장 헤더 또는 TCP/UDP 전송 계층 헤더)인지 지시한다. (예: Hop-by-Hop 옵션 헤더 = 0, TCP = 6, UDP = 17, Fragmentation 확장 헤더 = 44)</li>
<li><strong>Hop Limit (8비트):</strong> IPv4의 TTL 필드와 완전히 동일한 역할을 수행한다. 라우터를 거칠 때마다 1씩 감소하며 <code>0</code>이 되면 패킷이 폐기된다.</li>
<li><strong>Source Address (128비트):</strong> 송신자의 IPv6 논리 주소이다.</li>
<li><strong>Destination Address (128비트):</strong> 최종 수신자의 IPv6 논리 주소이다.</li>
</ul>
<hr>
<h2 id="76-보완-프로토콜-icmp--icmpv6">7.6 보완 프로토콜 (ICMP &amp; ICMPv6)</h2>
<p>IP 프로토콜은 에러를 보고하거나 복구하는 능력이 없다. 이를 보완하여 네트워크 상의 에러 상황을 인지하고 진단하기 위해 ICMP(Internet Control Message Protocol)가 함께 동작한다.</p>
<h3 id="761-icmpv4-메시지-분류">7.6.1 ICMPv4 메시지 분류</h3>
<p>ICMP 메시지는 네트워크 계층 패킷 내부에 캡슐화되어 전송되며 크게 두 범주로 나뉜다.</p>
<ul>
<li><strong>오류 보고 메시지 (Error-Reporting Messages):</strong> 라우터나 목적지 호스트가 패킷 처리 중 문제를 발견했을 때 송신 호스트에게 이를 보고하는 메시지이다. (절대 ICMP 메시지 자체에 대해서는 에러 보고 메시지를 중복 생성하지 않는다.)<ul>
<li><strong>Destination Unreachable (Type 3):</strong> 라우팅 테이블에 경로가 없거나 포트가 닫혀 있어 패킷을 최종 목적지에 전달할 수 없을 때 발생한다.</li>
<li><strong>Source Quench (Type 4):</strong> 네트워크 혼잡으로 인해 라우터 큐가 포화되어 패킷이 폐기되었으니 송신 속도를 줄이라고 경고하는 메시지이다.</li>
<li><strong>Time Exceeded (Type 11):</strong> 패킷의 TTL 값이 <code>0</code>이 되어 패킷을 폐기했음을 알리거나, 단편화된 조각들이 제한 시간 내에 모두 도착하지 못해 재조립에 실패했을 때 발생한다.</li>
<li><strong>Parameter Problem (Type 12):</strong> IP 헤더 자체에 변형이나 심각한 매개변수 오류가 발견되어 패킷을 폐기했음을 통보한다.</li>
<li><strong>Redirection (Type 5):</strong> 호스트가 패킷을 보낼 때 더 최적화된 경로의 라우터가 존재함을 인지시키고 라우팅 테이블을 갱신하도록 유도한다.</li>
</ul>
</li>
<li><strong>질의 메시지 (Query Messages):</strong> 네트워크 상태를 진단하거나 호스트 정보를 획득하기 위해 쌍으로 주고받는 메시지이다.<ul>
<li><strong>Echo Request (Type 8) / Echo Reply (Type 0):</strong> 대상 노드의 활성화 여부 및 왕복 시간(RTT)을 측정하는 질의 구조이다. (대표적 유틸리티: <code>ping</code>)</li>
</ul>
</li>
</ul>
<h3 id="762-icmpv6의-통합">7.6.2 ICMPv6의 통합</h3>
<p>IPv6로 넘어오면서 과거 IPv4에서 개별적으로 동작하던 주소 변환 프로토콜(ARP)과 그룹 관리 프로토콜(IGMP)의 기능이 <strong>ICMPv6 하나로 통합 및 흡수</strong>되었다.</p>
<ul>
<li><strong>이웃 탐색 프로토콜 (NDP, Neighbor Discovery Protocol):</strong> IPv4의 ARP 역할을 대체한다. 동일 링크 상의 다른 장치의 MAC 주소를 찾기 위해 <strong>Neighbor Solicitation</strong> 메시지를 멀티캐스트하고, 대상 장치가 <strong>Neighbor Advertisement</strong> 메시지로 자신의 MAC 주소를 응답한다.</li>
<li><strong>그룹 멤버십 관리 (MLD):</strong> IPv4의 IGMP 기능을 대체하여 호스트가 특정 멀티캐스트 그룹에 참여(Join)하거나 탈퇴(Leave)함을 라우터에 알리는 처리를 수행한다.</li>
</ul>
<hr>
<h2 id="77-ipv4에서-ipv6로의-천이-transition">7.7 IPv4에서 IPv6로의 천이 (Transition)</h2>
<p>전 세계 모든 라우터와 호스트의 IP 버전을 동시에 변환하는 것은 불가능하므로, 두 버전이 안전하게 공존하며 점진적으로 전환할 수 있도록 세 가지 마이그레이션 기술을 지원한다.</p>
<h3 id="771-이중-스택-dual-stack">7.7.1 이중 스택 (Dual Stack)</h3>
<p>하나의 호스트나 라우터에 <strong>IPv4와 IPv6 프로토콜 스택을 동시에 모두 탑재</strong>하는 방식이다. 패킷을 송수신할 때 목적지 주소의 유형에 따라 적절한 주소 체계와 헤더 포맷을 동적으로 선택하여 처리한다. DNS 질의를 통해 IPv4 주소(A 레코드)와 IPv6 주소(AAAA 레코드)를 모두 조회할 수 있어야 한다.</p>
<h3 id="772-터널링-tunneling">7.7.2 터널링 (Tunneling)</h3>
<p>IPv6를 지원하는 두 노드가 중간에 <strong>IPv4 전용 라우터들로만 구성된 네트워크 영역을 통과해야 할 때</strong> 사용하는 기술이다.</p>
<ul>
<li><strong>동작 원리:</strong> IPv6 패킷 전체를 하나의 순수한 데이터(페이로드) 취급하여, 그 외부에 <strong>IPv4 헤더를 추가로 씌우는 캡슐화(Encapsulation)</strong>를 진행한다. 중간의 IPv4 라우터들은 패킷 내부의 IPv6 내용은 보지 못하고 외측 IPv4 헤더만 보고 포워딩을 수행한다. 터널의 종단에 있는 IPv6 라우터가 외측 IPv4 헤더를 떼어내는 역캡슐화(Decapsulation)를 수행하여 원래의 IPv6 패킷을 복원한다.</li>
</ul>
<h3 id="773-헤더-변환-header-translation">7.7.3 헤더 변환 (Header Translation)</h3>
<p>네트워크 상의 송신자는 IPv6만 사용하고 수신자는 IPv4만 사용하여, 두 장치 간에 프로토콜 버전이 직접적으로 호환되지 않을 때 중간 게이트웨이에서 헤더 구조 자체를 변환하는 기법이다. IPv6 헤더의 필드들을 그에 상응하는 IPv4 헤더 필드로 일대일 매핑 및 갱신(주소 변환 포함)하여 패킷 구조를 완전히 재빌드한다.</p>
<hr>
<h2 id="스스로-확인해보기">스스로 확인해보기</h2>
<h3 id="-패킷-교환-및-성능-">[ 패킷 교환 및 성능 ]</h3>
<p><strong>Q1. 데이터그램 네트워크와 가상 회선 네트워크의 패킷 포워딩 기준(헤더 참조 필드)의 차이점을 서술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 데이터그램 네트워크는 패킷이 독립적으로 라우팅되므로 패킷 헤더에 포함된 최종 <strong>목적지 논리 주소(Destination IP Address)</strong>를 참조하여 포워딩한다. 반면 가상 회선 네트워크는 설정된 고정 경로를 따라 이동하므로 헤더에 삽입된 짧은 크기의 <strong>가상 회선 식별자(VCI)</strong>를 참조하여 포워딩한다.</li>
</ul>
<p><strong>Q2. 어떤 패킷의 크기가 2000바이트이고 링크의 대역폭이 10Mbps일 때, 이 링크에서 발생하는 전송 지연(Transmission Delay)을 계산하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 전송 지연은 패킷 길이($L$)를 대역폭($B$)으로 나눈 값이므로, $\frac{2000 \text{ bytes} \times 8 \text{ bits/byte}}{10,000,000 \text{ bps}} = \frac{16,000}{10,000,000} = 0.0016 \text{ 초} = 1.6 \text{ ms}$이다.</li>
</ul>
<h3 id="-ipv4--ipv6-스펙-">[ IPv4 &amp; IPv6 스펙 ]</h3>
<p><strong>Q3. IPv4 헤더의 IHL 필드 값이 <code>6</code> (<code>0110</code>)으로 설정되어 있다면, 이 IP 헤더의 총 바이트 크기는 얼마이며 옵션 필드는 몇 바이트를 차지하는지 계산하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> IHL 필드는 4바이트 워드 단위를 나타내므로 헤더의 총 크기는 $6 \times 4 = 24$ 바이트이다. IPv4의 기본 고정 헤더 크기가 20바이트이므로, 옵션 필드는 총 $24 - 20 = 4$ 바이트를 차지하고 있음을 알 수 있다.</li>
</ul>
<p><strong>Q4. IPv4 패킷 단편화 시, 중간 라우터에서 단편화 조각들의 재조립을 수행하지 않고 오직 최종 목적지 호스트에서만 재조립을 수행하는 이유를 원인 측면에서 서술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 인터넷은 데이터그램 방식을 취하므로 쪼개진 단편 패킷들이 서로 다른 경로를 통해 목적지로 이동할 수 있다. 따라서 중간 라우터는 모든 조각을 수집할 수 없으며, 라우터에 재조립 오버헤드가 가해지는 것을 방지하고 패킷 처리 효율을 높이기 위해 최종 목적지에서만 재조립을 수행한다.</li>
</ul>
<p><strong>Q5. IPv4 단편화 헤더 필드 중 Fragment Offset 필드 값이 <code>200</code>일 때, 이 단편 조각의 데이터가 원본 데이터그램 페이로드에서 실제로 시작하는 위치는 몇 번째 바이트인지 구하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> Fragment Offset 필드는 8바이트 단위를 기준으로 오프셋을 기록하므로, 실제 원본 데이터에서의 시작 바이트 위치는 $200 \times 8 = 1600$ 번째 바이트이다.</li>
</ul>
<p><strong>Q6. IPv6 프로토콜이 중간 라우터에서의 단편화(Fragmentation)를 전면 금지한 방식과, 이로 인해 라우터가 자신의 MTU보다 큰 IPv6 패킷을 수신했을 때의 처리 메커니즘을 서술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> IPv6는 라우터의 패킷 처리 지연을 최소화하기 위해 라우터 단편화를 금지했다. 라우터가 자신의 출력 링크 MTU보다 큰 IPv6 패킷을 수신하면 해당 패킷을 즉시 폐기하고, 송신 호스트에게 ICMPv6 &quot;Packet Too Big&quot; 오류 메시지를 보내 송신측이 Path MTU Discovery를 통해 패킷 크기를 스스로 줄여서 재송신하도록 유도한다.</li>
</ul>
<p><strong>Q7. IPv6 기본 헤더에서 패킷 흐름을 식별하여 실시간 트래픽 처리 효율을 높이고, 라우터가 테이블 검색 없이 신속한 가상 회선 스타일의 포워딩을 수행할 수 있도록 돕는 필드의 명칭을 쓰시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 플로우 레이블 (Flow Label) 필드</li>
</ul>
<h3 id="-보완-프로토콜-및-천이-기법-">[ 보완 프로토콜 및 천이 기법 ]</h3>
<p><strong>Q8. IPv4 환경에서 수신측으로 가던 패킷의 TTL 필드가 <code>0</code>이 되어 라우터가 이를 폐기했을 때, 송신측으로 장애 유발 사실을 알리기 위해 전송하는 ICMP 메시지의 명칭을 쓰시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> ICMP Time Exceeded (Type 11) 메시지</li>
</ul>
<p><strong>Q9. IPv6 네트워크에서 동일 링크 상에 존재하는 인접 장비의 하드웨어 주소를 알아내기 위해 ARP 대신 사용하는 ICMPv6 내부 프로토콜 및 해당 메시지 쌍의 명칭을 서술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 이웃 탐색 프로토콜(NDP)을 사용하며, 주소 확인을 요청하는 <strong>Neighbor Solicitation</strong> 메시지와 이에 응답하여 MAC 주소를 알려주는 <strong>Neighbor Advertisement</strong> 메시지 쌍을 사용한다.</li>
</ul>
<p><strong>Q10. IPv6 전용 노드 간에 통신할 때, 중간 경로에 IPv4 전용 라우터들로만 구성된 네트워크 영역이 존재할 경우 이 영역을 통과하기 위해 IPv6 패킷 외부에 IPv4 헤더를 덧씌워 중계하는 천이 기술의 명칭을 쓰시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 터널링 (Tunneling)</li>
</ul>
<hr>
<h2 id="핵심-요약">핵심 요약</h2>
<ul>
<li><strong>네트워크층 서비스:</strong> 종단 간 패킷화, 라우팅, 포워딩 담당. IP는 비연결형 최선형 서비스를 제공.</li>
<li><strong>데이터그램 vs 가상회선:</strong> 데이터그램은 독립 경로 라우팅 및 목적지 IP 주소 기반 포워딩 수행. 가상회선은 수립된 고정 경로 사용 및 VCI 기반 레이블 교환 포워딩 수행.</li>
<li><strong>총 지연 시간:</strong> 전송 지연($L/B$), 전파 지연($D/V$), 처리 지연, 큐잉 지연의 합산으로 구성.</li>
<li><strong>IPv4 단편화 수치 계산:</strong> 고정 헤더 20B 기준. Identification으로 식별하며, Fragment Offset 필드 값에 8을 곱해 원본 바이트 위치 산출. 최종 수신지 호스트에서만 재조립.</li>
<li><strong>IPv6 설계 혁신:</strong> 128비트 주소 체계, 40B 고정 헤더 구성으로 체크섬 제거. 라우터 단편화 완전 금지 및 송신측 Path MTU Discovery 의무화. Flow Label(20비트)을 통한 품질 고도화.</li>
<li><strong>보완 및 통합:</strong> ICMPv4는 에러 보고와 질의 기능 수행. ICMPv6로 발전하며 ARP(→NDP)와 IGMP(→MLD) 기능을 내부에 완전 흡수 통합.</li>
<li><strong>IPv6 전환 기술:</strong> Dual Stack(프로토콜 공존), Tunneling(IPv4망 내 IPv6 패킷 캡슐화 포장), Header Translation(헤더 구조 일대일 변환 가공).</li>
</ul>
<hr>
<h2 id="참고문헌">참고문헌</h2>
<ul>
<li>Forouzan, B. A. (2013). Data Communications and Networking (6th ed.). McGraw-Hill.</li>
<li>번역: 이재광, 김중규, 이경현, 홍충선. 데이터 통신과 네트워킹 TCP/IP 프로토콜 기반 (개정 6 수정판). 퍼스트북.</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[[컴퓨터 네트워크] 6장 - 연결 장치와 가상 LAN]]></title>
            <link>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-6%EC%9E%A5</link>
            <guid>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-6%EC%9E%A5</guid>
            <pubDate>Sun, 31 May 2026 05:44:49 GMT</pubDate>
            <description><![CDATA[<h2 id="61-연결-장치-connecting-devices">6.1 연결 장치 (Connecting Devices)</h2>
<p>연결 장치는 서로 다른 독립된 네트워크를 연결하여 단말 간 데이터 전달 및 경로 선택을 가능하게 하는 핵심 인프라 요소이다. 동작하는 주된 OSI 계층에 따라 허브, 스위치, 라우터의 세 가지로 분류된다.</p>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/82e7f33b-2705-4e88-aea9-ac375768666f/image.png" alt=""></p>
<ul>
<li><strong>물리 계층(Layer 1):</strong> 데이터의 의미나 주소를 해석하지 못하고 단순히 전기적 신호를 증폭하고 중계하는 허브(Hub)와 중계기(Repeater)가 속한다.</li>
<li><strong>데이터 링크 계층(Layer 2):</strong> 프레임의 헤더 정보를 파싱하여 48비트 MAC 주소를 기반으로 동일 네트워크 내에서 필터링 및 포워딩을 수행하는 링크 계층 스위치(Link-Layer Switch)가 속한다.</li>
<li><strong>네트워크 계층(Layer 3):</strong> 패킷의 IP 헤더를 확인하고 최적의 경로(Metric)를 연산하여 논리적으로 분리된 이기종 네트워크 간 통신을 제어하는 라우터(Router)가 속한다.</li>
</ul>
<hr>
<h3 id="611-허브-hub">6.1.1 허브 (Hub)</h3>
<p>허브는 여러 장치를 트리나 성형(Star) 구조로 연결하는 가장 단순한 물리 계층(Layer 1) 장치이다.</p>
<ul>
<li><strong>동작 특성:</strong> 한 포트로 들어온 전기 신호를 목적지 구분 없이 자신에게 연결된 모든 포트(송신 포트 제외)로 그대로 복제하여 전달한다. 이를 <strong>플러딩(Flooding)</strong> 또는 브로드캐스트 전송 방식이라 한다. 허브 자체에는 프레임을 저장하고 제어할 수 있는 버퍼 메모리가 존재하지 않기 때문에 신호가 들어오는 즉시 실시간으로 모든 포트에 전달된다.</li>
<li><strong>한계점:</strong> 연결된 모든 단말이 하나의 <strong>충돌 도메인(Collision Domain)</strong>을 공유한다. 즉, 반이중(Half-Duplex) 통신을 전제로 하기 때문에 두 개 이상의 단말이 동시에 데이터를 송신하면 무조건 충돌이 발생한다. 프레임을 수신한 단말들은 자신의 MAC 주소와 비교하여 일치하지 않으면 폐기해야 하므로 시스템 리소스와 대역폭의 비효율성이 존재한다.</li>
<li><strong>중계기(Repeater)의 역할:</strong> 신호 감쇄를 보완하기 위해 신호를 수신하여 증폭 및 재생성(Regeneration)한 후 전달하는 기능을 포함한다. 물리적 거리가 멀어져 왜곡된 감쇄 신호를 정상 비트 스트림으로 복원하는 역할을 담당하며, 허브 내부에 기본적으로 이 기능이 포함되어 있다.</li>
</ul>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/33176879-5214-45ab-aec2-ddb67641d7b1/image.png" alt=""></p>
<hr>
<h3 id="612-링크-계층-스위치-link-layer-switch">6.1.2 링크 계층 스위치 (Link-Layer Switch)</h3>
<p>데이터 링크 계층(Layer 2)에서 동작하는 장치로, 프레임의 MAC 주소를 기반으로 목적지 장치에게만 데이터를 필터링하고 포워딩한다.</p>
<ul>
<li><strong>충돌 도메인 격리:</strong> 스위치의 각 포트는 독립된 충돌 도메인을 형성한다. 스위치는 포트별로 독립된 버퍼 메모리를 가지고 있어 수신된 프레임을 임시 저장한 후 전달할 수 있다. 이를 통해 동시 송수신이 가능한 전이중 모드(Full-Duplex)로 동작하므로 데이터 링크 계층에서의 충돌이 발생하지 않는다. 단, 모든 포트는 여전히 하나의 동일한 <strong>브로드캐스트 도메인(Broadcast Domain)</strong>에 속하게 된다.</li>
</ul>
<h4 id="1-투명-스위치-transparent-switch">1) 투명 스위치 (Transparent Switch)</h4>
<p>단말들이 스위치의 존재 여부를 알지 못하도록 투명하게 동작하는 스위치이다. 스위치는 네트워크에 연결되는 순간 아무런 정보가 없지만, 유입되는 트래픽을 관찰하며 <strong>주소 학습(Address Learning)</strong> 기능을 통해 MAC 주소 테이블을 스스로 구축한다.</p>
<ul>
<li><strong>동작 원리 (3단계 루프):</strong><ol>
<li><strong>학습 (Learning):</strong> 들어오는 프레임의 <strong>출발지 MAC 주소(Source MAC)</strong>와 해당 프레임이 유입된 <strong>입력 포트 번호</strong>를 MAC 주소 테이블(동적 매핑 테이블)에 매핑하여 기록한다.</li>
<li><strong>포워딩 (Forwarding) / 필터링 (Filtering):</strong> 프레임의 <strong>목적지 MAC 주소(Destination MAC)</strong>가 테이블에 존재할 때, 입력 포트와 출력 포트가 다르면 지정된 출력 포트로만 프레임을 전달(Forwarding)한다. 만약 입력 포트와 출력 포트가 같다면(이미 해당 세그먼트에 목적지가 존재하므로) 프레임을 차단(Filtering)한다.</li>
<li><strong>플러딩 (Flooding):</strong> 목적지 MAC 주소가 테이블에 존재하지 않는 <strong>미확인 유니캐스트(Unknown Unicast)</strong>이거나 브로드캐스트 프레임일 경우, 프레임이 유입된 송신 포트를 제외한 모든 활성 포트로 프레임을 복제하여 전송한다.</li>
</ol>
</li>
<li><strong>에이징 타임 (Aging Time):</strong> 네트워크 토폴로지의 동적 변화(단말의 이동 또는 전원 차단 등)를 반영하기 위해, 학습된 테이블의 각 엔트리에는 타이머가 부여된다. 일정 시간 동안 해당 출발지 MAC 주소로부터 프레임이 유입되지 않으면 주소 테이블에서 자동으로 삭제하여 메모리를 최적화한다. 보통 엔터프라이즈 장비의 기본값은 300초(5분) 내외이다.</li>
</ul>
<blockquote>
<p><strong>MAC 테이블 고갈 공격과 보안 대책</strong>
스위치의 한정된 메모리 자원을 노린 대표적인 Layer 2 공격으로, 공격자가 임의로 조작된 수많은 출발지 MAC 주소를 스위치에 지속적으로 유입시키는 방식이 있다. 스위치의 MAC 주소 테이블이 거짓 정보로 고갈되면 스위치는 더 이상 새로운 정상 주소를 학습하지 못하고, 이후 유입되는 모든 프레임을 허브처럼 플러딩(Flooding)하게 된다. 이를 통해 공격자는 유니캐스트 트래픽을 스니핑할 수 있게 되며, 이를 방지하기 위해 실무에서는 포트별로 허용 가능한 최대 MAC 주소 개수를 제한하는 포트 보안(Port Security) 설정을 적용한다.</p>
</blockquote>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/331301a5-f6c1-4b4f-904f-14844666e40d/image.png" alt=""></p>
<h4 id="2-루프-문제와-스패닝-트리-알고리즘-sta">2) 루프 문제와 스패닝 트리 알고리즘 (STA)</h4>
<p>네트워크의 가용성을 높이기 위해 스위치 간에 이중화 경로(Redundant Link)를 구성하면, 결함 감내(Fault Tolerance) 능력은 향상되지만 데이터 링크 계층에서 루프(Loop) 현상이 발생한다.</p>
<ul>
<li><strong>루프의 폐해:</strong> 브로드캐스트 프레임이 스위치 사이를 영원히 순환하면서 대역폭을 고갈시키는 <strong>브로드캐스트 스톰(Broadcast Storm)</strong>이 발생하고, MAC 주소 테이블의 내용이 계속 번복되는 MAC 테이블 불안정화 현상이 일어난다. Layer 2 프레임 헤더에는 Layer 3 IP 헤더의 TTL(Time to Live) 같은 수명 필드가 없기 때문에 수동으로 제어하지 않으면 네트워크가 완전히 다운된다.</li>
<li><strong>스패닝 트리 알고리즘 (IEEE 802.1D):</strong> 루프 구조를 감지하고 논리적으로 특정 포트를 차단하여 토폴로지를 하나의 트리(Tree) 구조로 변환하는 알고리즘이다. 이를 위해 스위치들은 2초마다 <strong>BPDU(Bridge Protocol Data Unit)</strong>라는 제어 프레임을 교환한다.</li>
<li><strong>STA의 핵심 동작 절차:</strong><ol>
<li><strong>루트 브리지(Root Bridge) 선출:</strong> 전체 네트워크에서 브리지 ID(우선순위 2바이트 + MAC 주소 6바이트) 값이 가장 낮은 스위치를 대장 스위치인 &#39;루트 브리지&#39;로 선출한다.</li>
<li><strong>루트 포트(Root Port) 선정:</strong> 루트 브리지가 아닌 모든 스위치(Non-Root Bridge)에서 루트 브리지까지 가는 링크 비용(Cost)의 합이 가장 적은 최단 경로 포트를 스위치당 하나씩 지정한다.</li>
<li><strong>지정 포트(Designated Port) 선정:</strong> 각 세그먼트(네트워크 링크)별로 루트 브리지까지 가는 비용이 가장 저렴한 스위치의 포트를 지정 포트로 선출하여 활성화한다. 루트 브리지의 모든 포트는 항상 지정 포트가 된다.</li>
<li><strong>비지정 포트 차단(Alternate/Blocking Port):</strong> 루트 포트도 아니고 지정 포트도 아닌 나머지 포트는 논리적으로 데이터를 차단(Block)하여 루프를 원천 제거한다.</li>
</ol>
</li>
<li><strong>포트의 상태 천이:</strong> 경로 변화 발생 시 루프를 방지하기 위해 포트는 다음과 같은 단계적 상태 전환을 거친다.</li>
</ul>
<p>$$\text{Blocking} \longrightarrow \text{Listening} \longrightarrow \text{Learning} \longrightarrow \text{Forwarding}$$</p>
<ul>
<li><strong>Blocking (차단):</strong> 데이터 전송 및 주소 학습이 불가하며, 오직 루프 감지를 위한 BPDU 수신만 가능하다. 청취 상태로 넘어가는 데 약 20초(Max Age)가 소요된다.</li>
<li><strong>Listening (청취):</strong> 루프 여부를 확인하는 단계로, 데이터 전송과 주소 학습 없이 BPDU를 송수신하며 토폴로지를 계산한다. 기본 유지 시간은 15초(Forward Delay)이다.</li>
<li><strong>Learning (학습):</strong> 데이터 전송은 여전히 차단되나, 유입되는 프레임의 출발지 주소를 보고 MAC 주소 테이블을 미리 빌드하기 시작한다. 기본 유지 시간은 15초(Forward Delay)이다.</li>
<li><strong>Forwarding (전송):</strong> 정상적으로 데이터 프레임을 포워딩하고 수신하는 완성된 상태이다. 차단 상태에서 전송 상태까지 도달하는 데는 총 30~50초의 수렴 시간(Convergence Time)이 필요하다.</li>
</ul>
<hr>
<h3 id="613-라우터-router">6.1.3 라우터 (Router)</h3>
<p>네트워크 계층(Layer 3)에서 동작하는 장치로, 서로 다른 독립된 네트워크(서브넷) 간의 통신을 가능하게 한다.</p>
<ul>
<li><strong>핵심 기능:</strong> IP 주소를 기반으로 최적의 경로를 설정하는 <strong>라우팅(Routing)</strong>과, 유입된 패킷을 적절한 출력 인터페이스로 밀어주는 <strong>포워딩(Forwarding)</strong>을 수행한다.</li>
<li><strong>브로드캐스트 차단:</strong> 라우터는 브로드캐스트 프레임을 기본적으로 다른 인터페이스로 넘기지 않고 차단한다. 즉, 브로드캐스트 도메인을 물리적으로 격리하는 경계선 역할을 수행하여 불필요한 트래픽 유출을 막는다. 스위치가 나누지 못하는 브로드캐스트 영역을 라우터가 최종적으로 분할하는 역할을 담당한다.</li>
</ul>
<hr>
<h2 id="62-가상-lan-vlan">6.2 가상 LAN (VLAN)</h2>
<p>VLAN(Virtual Local Area Network)은 물리적인 네트워크 토폴로지에 종속되지 않고, 스위치 소프트웨어를 설정하여 논리적으로 브로드캐스트 도메인을 분할하는 기술이다.</p>
<ul>
<li><strong>도입 배경:</strong> 물리적으로 장치들을 격리하려면 별도의 스위치와 라우팅 장비가 추가로 필요하므로 비용과 관리 효율성이 저하된다. 가상 LAN을 사용하면 단 하나의 고성능 스위치만으로도 여러 개의 독립된 가상 네트워크를 구축할 수 있다.</li>
<li><strong>보안성 및 성능 향상:</strong> 불필요한 브로드캐스트 트래픽이 다른 부서나 그룹으로 유입되는 것을 차단하므로 대역폭 낭비를 막고, 부서 간 불필요한 접근을 원천 차단하여 정보보호 관점에서의 격리 보안을 달성할 수 있다. 서로 다른 VLAN 간 통신은 데이터 링크 계층에서 불가능하며, 반드시 Layer 3 라우터나 Inter-VLAN 라우팅 기능을 거쳐야만 한다.</li>
</ul>
<hr>
<h3 id="621-소속원-구성-및-설정">6.2.1 소속원 구성 및 설정</h3>
<p>VLAN 그룹을 정의하고 단말을 할당하는 기준은 여러 가지가 존재한다.</p>
<ul>
<li><strong>포트(Interface) 기준:</strong> 스위치의 특정 물리적 포트 번호(예: 1<del>5번 포트는 VLAN 10, 6</del>10번 포트는 VLAN 20)를 지정하는 방식이다. 이를 <strong>Access 포트</strong>라고도 부르며, 구조가 단순하고 직관적이어서 실무 및 엔터프라이즈 환경에서 가장 많이 쓰인다.</li>
<li><strong>MAC 주소 기준:</strong> 단말의 고유 MAC 주소를 기반으로 가상 LAN 멤버십을 할당한다. 사용자가 자리를 이동하여 다른 포트에 선을 꽂아도 스위치가 MAC 주소를 식별해 지정된 가상 LAN을 유연하게 유지해 준다.</li>
<li><strong>IP 주소 기준:</strong> 네트워크 계층의 서브넷 IP 대역별로 가상 LAN을 구성하여 매핑한다. 단말의 IP가 속한 대역에 따라 가상 LAN이 유동적으로 결정된다.</li>
<li><strong>설정 방식:</strong> 관리자가 CLI 콘솔을 통해 포트별로 하드코딩하는 <strong>수동 설정(Static)</strong>과, 사용자 인증 정보나 IP 등을 감지해 서버가 자동으로 규칙을 적용하는 <strong>자동 설정(Dynamic)</strong> 방식으로 나뉜다.</li>
</ul>
<hr>
<h3 id="622-교환기-간-통신-trunk--tagging">6.2.2 교환기 간 통신 (Trunk &amp; Tagging)</h3>
<p>여러 대의 스위치가 연결된 대규모 환경에서 각 스위치에 분산되어 있는 동일 가상 LAN 멤버들끼리 통신하기 위해 인터페이스를 효율화하는 기법이 필요하다.</p>
<ul>
<li><strong>트렁크(Trunk) 링크:</strong> 스위치와 스위치 간을 연결할 때 모든 가상 LAN 트래픽이 단 하나의 물리적 결선(케이블)을 통해 동시에 이동할 수 있도록 설정한 공용 링크이다. 각 가상 LAN별로 케이블을 따로 연결해야 하는 포트 낭비를 획기적으로 줄여준다.</li>
<li><strong>프레임 태깅 (IEEE 802.1Q):</strong> 트렁크 링크로 프레임을 내보낼 때, 이 프레임이 어느 가상 LAN 소속인지 식별할 수 있도록 원래의 표준 이더넷 프레임 중간에 <strong>4바이트 크기의 가상 LAN 태그(Tag)</strong>를 삽입하는 프로토콜 규격이다. 트렁크 링크를 통과한 후 목적지 스위치에 도달하면 이 태그를 떼어내고(Untagging) 원래의 이더넷 프레임 상태로 해당 가상 LAN 포트에만 전달한다.</li>
<li><strong>VLAN 태그의 세부 구조:</strong><ul>
<li><strong>TPID (Tag Protocol Identifier):</strong> 값은 <code>0x8100</code> 고정이며, 해당 프레임이 802.1Q 태그가 삽입된 특수 프레임임을 전송 스트림에 명시한다.</li>
<li><strong>Priority (PCP):</strong> QoS(서비스 품질) 구현을 위해 데이터의 우선순위를 3비트(0~7 단계)로 세분화하여 처리한다. 보이스 트래픽 등 실시간성이 중요한 데이터에 높은 우선순위를 부여할 수 있다.</li>
<li><strong>CFI (Canonical Format Indicator):</strong> 토큰링 네트워크와의 호환성을 식별하기 위한 1비트 필드이다. 이더넷 환경에서는 기본적으로 0으로 설정된다.</li>
<li><strong>VID (VLAN Identifier):</strong> 가상 LAN을 식별하는 핵심 식별 번호 필드로 <strong>12비트</strong>가 할당된다.</li>
<li><strong>계산량적 한계:</strong> VID가 12비트이므로 논리적으로 구별 가능한 최대 가상 LAN의 개수는 $2^{12} = 4,096$개이다. 이 중 0번과 4095번은 예약되어 있으므로 실제 사용 가능한 가상 LAN ID는 1번부터 4094번까지이다.</li>
</ul>
</li>
</ul>
<blockquote>
<p><strong>클라우드 대규모 환경에서의 가상 LAN 확장 (VXLAN)</strong>
현대 퍼블릭 클라우드 데이터센터 가상화 환경에서는 이 4,096개라는 식별자 한계가 네트워크 세그먼트 분할의 치명적인 병목이 된다. 수많은 고객(테넌트)들에게 각각 격리된 가상 네트워크 인프라를 제공하기에는 ID 개수가 부족하기 때문이다. 이를 해결하기 위해 실제 클라우드 아키텍처에서는 표준 이더넷 프레임을 L4 UDP 패킷 내부에 캡슐화하고, 24비트 ID 체계를 사용하는 <strong>VXLAN(Virtual Extensible LAN)</strong> 표준을 상위 계층에 오버레이 형태로 도입하여 최대 1,600만 개의 논리적 가상 네트워크 영역을 확보하여 운영한다.</p>
</blockquote>
<hr>
<h2 id="스스로-확인해보기">스스로 확인해보기</h2>
<h3 id="-연결-장치-">[ 연결 장치 ]</h3>
<p><strong>Q1. 허브(Hub)와 스위치(Switch)의 데이터 전달 방식 차이점을 도메인 관점에서 설명하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 허브는 물리 계층 장치로 유입된 신호를 모든 포트로 플러딩하므로 연결된 모든 단말이 하나의 충돌 도메인을 공유한다. 반면 스위치는 데이터 링크 계층 장치로 MAC 주소 테이블을 참조하여 목적지 포트로만 프레임을 포워딩하므로 포트별로 충돌 도메인이 격리된다.</li>
</ul>
<p><strong>Q2. 투명 스위치(Transparent Switch)가 MAC 주소 테이블에 정보가 없는 &#39;Unknown Unicast&#39; 프레임을 수신했을 때 어떻게 처리하는가?</strong></p>
<ul>
<li><strong>모범 답안:</strong> 목적지 MAC 주소가 주소 테이블에 등록되어 있지 않으므로, 프레임이 유입된 입력 포트를 제외한 모든 활성 포트로 프레임을 복제하여 전송하는 플러딩(Flooding)을 수행한다.</li>
</ul>
<p><strong>Q3. 스위치가 MAC 주소 테이블을 구축할 때, 유입된 프레임의 어떤 주소를 참조하여 학습(Learning)하는가?</strong></p>
<ul>
<li><strong>모범 답안:</strong> 유입된 프레임의 헤더에 기록된 <strong>출발지 MAC 주소(Source MAC Address)</strong>와 해당 프레임이 들어온 입력 포트 번호를 매핑하여 테이블에 기록한다.</li>
</ul>
<p><strong>Q4. L2 스위치 환경에서 이중화 경로(Redundant Link)를 구성했을 때 발생하는 대표적인 네트워크 장애 현상 2가지를 서술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 브로드캐스트 프레임이 무한 루프를 돌며 대역폭을 고갈시키는 &#39;브로드캐스트 스톰(Broadcast Storm)&#39;과, 동일한 출발지 주소가 서로 다른 포트에서 반복 감지되어 테이블이 깨지는 &#39;MAC 주소 테이블 불안정화&#39; 현상이 발생한다.</li>
</ul>
<p><strong>Q5. 스패닝 트리 알고리즘(STA)에서 스위치들이 토폴로지 변경 및 경로 계산을 위해 서로 주고받는 제어 프레임의 명칭은 무엇인가?</strong></p>
<ul>
<li><strong>모범 답안:</strong> BPDU (Bridge Protocol Data Unit)</li>
</ul>
<p><strong>Q6. STA 포트 상태 천이 단계 중, 데이터 프레임 전송은 하지 않지만 유입 프레임의 출발지 주소를 기반으로 MAC 테이블을 채우기 시작하는 단계를 제시하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 러닝 (Learning, 학습) 상태</li>
</ul>
<p><strong>Q7. 라우터가 물리적 또는 논리적으로 완벽하게 차단하여 다른 인터페이스로 전달하지 않는 트래픽의 종류는 무엇인가?</strong></p>
<ul>
<li><strong>모범 답안:</strong> 브로드캐스트 트래픽 (프레임 목적지 주소가 FF:FF:FF:FF:FF:FF인 데이터)</li>
</ul>
<h3 id="-가상-lan-vlan-">[ 가상 LAN (VLAN) ]</h3>
<p><strong>Q8. 가상 LAN(VLAN)을 정의하고, 이를 도입함으로써 얻을 수 있는 대표적인 성능 및 보안상의 이점을 서술하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 가상 LAN은 물리적 위치와 관계없이 소프트웨어 설정을 통해 논리적으로 브로드캐스트 도메인을 분할하는 기술이다. 불필요한 브로드캐스트 트래픽의 전파 범위를 제한하여 대역폭 효율을 높이고, 부서 간 비인가 접근을 원천 차단하여 보안성을 향상시킨다.</li>
</ul>
<p><strong>Q9. 가상 LAN을 설정하는 기준 중 단말의 물리적 이동이 잦은 환경에서 가장 유연하게 대처할 수 있는 매핑 방식은 무엇인가?</strong></p>
<ul>
<li><strong>모범 답안:</strong> MAC 주소 기준 가상 LAN 설정 방식</li>
</ul>
<p><strong>Q10. 하나의 물리적 케이블을 통해 여러 가상 LAN의 데이터를 동시에 전송할 수 있도록 스위치 간을 연결하는 링크의 명칭은 무엇인가?</strong></p>
<ul>
<li><strong>모범 답안:</strong> 트렁크(Trunk) 링크</li>
</ul>
<p><strong>Q11. IEEE 802.1Q 프레임 태깅 규격에서 추가되는 가상 LAN 태그 헤더의 총 크기는 몇 바이트인가?</strong></p>
<ul>
<li><strong>모범 답안:</strong> 4바이트 (32비트)</li>
</ul>
<p><strong>Q12. 이더넷 프레임 내에 삽입되는 가상 LAN 태그 내부 구조 중, 가상 LAN의 식별 코드를 나타내는 필드의 명칭과 할당 비트 수를 쓰시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> VID (VLAN Identifier), 12비트</li>
</ul>
<p><strong>Q13. IEEE 802.1Q 표준 규격 하에서 이론적으로 생성 및 구별할 수 있는 최대 가상 LAN의 개수를 계산 과정을 포함하여 제시하시오.</strong></p>
<ul>
<li><strong>모범 답안:</strong> 가상 LAN 식별자인 VID가 12비트로 구성되어 있으므로 표현 가능한 수의 범위는 $2^{12} = 4,096$개이다. (실제 0과 4095는 예약용이므로 실질 사용은 4094개)</li>
</ul>
<hr>
<h2 id="핵심-요약">핵심 요약</h2>
<ul>
<li><strong>허브(L1):</strong> 물리 계층 동작, 전 포트 플러딩, 단일 충돌 도메인 형성으로 충돌 위험 상존.</li>
<li><strong>스위치(L2):</strong> 데이터 링크 계층 동작, MAC 테이블 기반 필터링/포워딩, 포트별 충돌 도메인 격리.</li>
<li><strong>투명 스위치 메커니즘:</strong> 출발지 MAC으로 학습(Learning), 목적지 MAC으로 포워딩/필터링, 테이블에 없으면 플러딩.</li>
<li><strong>루프 방지:</strong> 이중화 경로 시 브로드캐스트 스톰 발생 위험, IEEE 802.1D 스패닝 트리 알고리즘(STA)을 통해 차단 포트 지정으로 해결.</li>
<li><strong>가상 LAN 기술:</strong> 소프트웨어적 세그멘테이션을 통한 브로드캐스트 도메인 가상 분할 및 격리 보안 달성.</li>
<li><strong>802.1Q 태깅:</strong> 트렁크 링크 통신 시 4바이트 태그 삽입, VID 12비트 구조로 인해 최대 4,096개의 가상 LAN 지원 가능.</li>
</ul>
<hr>
<h2 id="참고문헌">참고문헌</h2>
<ul>
<li>Forouzan, B. A. (2013). Data Communications and Networking (6th ed.). McGraw-Hill.</li>
<li>번역: 이재광, 김중규, 이경현, 홍충선. 데이터 통신과 네트워킹 TCP/IP 프로토콜 기반 (개정 6 수정판). 퍼스트북.</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[[컴퓨터 네트워크] 4장 - 근거리 통신망 (LAN)]]></title>
            <link>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-4%EC%9E%A5-%EA%B7%BC%EA%B1%B0%EB%A6%AC-%ED%86%B5%EC%8B%A0%EB%A7%9D-LAN</link>
            <guid>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-4%EC%9E%A5-%EA%B7%BC%EA%B1%B0%EB%A6%AC-%ED%86%B5%EC%8B%A0%EB%A7%9D-LAN</guid>
            <pubDate>Tue, 21 Apr 2026 23:00:32 GMT</pubDate>
            <description><![CDATA[<h2 id="41-이더넷-ethernet">4.1 이더넷 (Ethernet)</h2>
<p>이더넷은 IEEE 802.3 기반의 유선 LAN 기술 표준이고, 현재 가장 널리 사용되는 근거리 네트워크 기술이다. 1970년대 Robert Metcalfe와 David Boggs가 개발했고 이후 계속 발전해왔다.
<img src="https://velog.velcdn.com/images/opentime_kr/post/6d131ea2-378f-4a77-802c-57fb63f748e0/image.png" alt=""></p>
<p><strong>이더넷 세대별 발전</strong></p>
<table>
<thead>
<tr>
<th>세대</th>
<th>속도</th>
<th>연도</th>
</tr>
</thead>
<tbody><tr>
<td>표준 이더넷</td>
<td>10 Mbps</td>
<td>1983</td>
</tr>
<tr>
<td>고속 이더넷</td>
<td>100 Mbps</td>
<td>1995</td>
</tr>
<tr>
<td>기가비트 이더넷</td>
<td>1 Gbps</td>
<td>1998</td>
</tr>
<tr>
<td>10기가비트 이더넷</td>
<td>10 Gbps</td>
<td>2002</td>
</tr>
</tbody></table>
<p><strong>IEEE 802 표준 구조</strong>
데이터링크층을 두 개의 부계층으로 나눈다.</p>
<ul>
<li><strong>LLC (Logical Link Control)</strong>: 상위 계층과 인터페이스, 흐름/오류 제어</li>
<li><strong>MAC (Media Access Control)</strong>: CSMA/CD 기반 매체 접근 제어, MAC 주소 기반 프레임 전송</li>
</ul>
<blockquote>
<p>IEEE 프로젝트 802 (<a href="https://www.ieee802.org/">https://www.ieee802.org/</a>) 참고</p>
</blockquote>
<hr>
<h2 id="411-표준-이더넷-10mbps">4.1.1 표준 이더넷 (10Mbps)</h2>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/7aaf8bf6-5755-4c67-b267-841d06e9415f/image.png" alt=""></p>
<p><strong>이더넷 프레임 구조</strong></p>
<table>
<thead>
<tr>
<th>필드</th>
<th>크기</th>
<th>설명</th>
</tr>
</thead>
<tbody><tr>
<td>Preamble</td>
<td>7바이트</td>
<td>수신 측 동기화 (0,1 반복 패턴)</td>
</tr>
<tr>
<td>SFD</td>
<td>1바이트</td>
<td>프레임 시작 알림 (10101011)</td>
</tr>
<tr>
<td>목적지 주소</td>
<td>6바이트</td>
<td>수신자 MAC 주소</td>
</tr>
<tr>
<td>출발지 주소</td>
<td>6바이트</td>
<td>송신자 MAC 주소</td>
</tr>
<tr>
<td>유형(Type)</td>
<td>2바이트</td>
<td>상위 계층 프로토콜 식별</td>
</tr>
<tr>
<td>데이터</td>
<td>46~1500바이트</td>
<td>실제 페이로드</td>
</tr>
<tr>
<td>CRC</td>
<td>4바이트</td>
<td>오류 검출 (CRC-32)</td>
</tr>
</tbody></table>
<ul>
<li>최소 프레임 크기: <strong>64바이트</strong> (512비트)</li>
<li>최대 프레임 크기: <strong>1518바이트</strong></li>
<li>비연결형, 비신뢰성 전송 (신뢰성은 상위 계층인 TCP가 담당)</li>
</ul>
<p><strong>최소 프레임 크기 계산 예제</strong></p>
<pre><code>대역폭 10Mbps, 최대 전파 시간 25.6μs일 때
최소 프레임 전송 시간 = 2 × 25.6μs = 51.2μs
최소 프레임 크기 = 10Mbps × 51.2μs = 512bits = 64bytes</code></pre><p><strong>MAC 주소 유니캐스트 vs 멀티캐스트 구별</strong>
첫 번째 바이트의 마지막 비트(LSB)로 구별한다.</p>
<ul>
<li>LSB = 0 → 유니캐스트 (짝수)</li>
<li>LSB = 1 → 멀티캐스트 (홀수)</li>
<li>전체 FF:FF:FF:FF:FF:FF → 브로드캐스트</li>
</ul>
<p><strong>Manchester Encoding</strong>
표준 이더넷(10Mbps)에서 사용하는 인코딩 방식이다. 1비트를 두 구간으로 나눠서 중간에 항상 전압 변화가 생기도록 한다.</p>
<ul>
<li>0: 비트 중간에서 High → Low</li>
<li>1: 비트 중간에서 Low → High</li>
</ul>
<hr>
<h2 id="412-고속-이더넷-100mbps">4.1.2 고속 이더넷 (100Mbps)</h2>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/8e5936f9-ea24-4341-a43f-211f8bd85a5a/image.png" alt=""></p>
<p>표준 이더넷과 호환성을 유지하면서 속도를 10배 올린 버전이다. MAC 주소 체계, 프레임 구조, CSMA/CD 방식을 그대로 유지했다.</p>
<p><strong>자동 협상 (Auto-negotiation)</strong>
10Mbps / 100Mbps 속도와 전이중 / 반이중 모드를 장치 간에 자동으로 협상하는 기능이다.</p>
<table>
<thead>
<tr>
<th>구현</th>
<th>매체</th>
<th>최대 길이</th>
<th>부호화</th>
</tr>
</thead>
<tbody><tr>
<td>100Base-TX</td>
<td>STP</td>
<td>100m</td>
<td>4B/5B + MLT-3</td>
</tr>
<tr>
<td>100Base-FX</td>
<td>광섬유</td>
<td>185m</td>
<td>4B/5B + NRZ-I</td>
</tr>
<tr>
<td>100Base-T4</td>
<td>UTP</td>
<td>100m</td>
<td>8B/6T</td>
</tr>
</tbody></table>
<blockquote>
<p><strong>TMI</strong>: 지금 우리가 쓰는 인터넷 랜선(Cat5e, Cat6)이 100Base-TX 또는 1000Base-T 기반이다. 서버 개발할 때 NCP에 올린 서버가 기가비트 이더넷으로 연결된 것도 이 맥락이다.</p>
</blockquote>
<hr>
<h2 id="413-기가비트-이더넷-1gbps">4.1.3 기가비트 이더넷 (1Gbps)</h2>
<p>전송 속도를 1Gbps로 올렸고, 이전 이더넷과 완전히 호환된다. 실제 환경에서는 <strong>전이중(Full-Duplex) 모드</strong>로만 운영하기 때문에 충돌이 발생하지 않아서 CSMA/CD가 사실상 사용되지 않는다.</p>
<p><strong>4D-PAM5</strong>
UTP 기반 기가비트 이더넷(1000Base-T)에서 사용하는 인코딩 방식이다.</p>
<ul>
<li>4D: 4쌍의 선을 동시에 사용</li>
<li>PAM5: 각 선에서 -2, -1, 0, +1, +2 다섯 단계 전압 사용</li>
<li>4개 선 × 5단계 = 5⁴ = 625가지 조합 → 한 번에 약 8비트 전송 가능</li>
</ul>
<hr>
<h2 id="414-10기가비트-이더넷-10gbps">4.1.4 10기가비트 이더넷 (10Gbps)</h2>
<p>IEEE 802.3ae 표준으로, LAN에서 MAN(도시 규모) 영역으로 이더넷을 확장했다. <strong>전이중 모드에서만 동작</strong>하고, CSMA/CD를 완전히 사용하지 않는다.</p>
<table>
<thead>
<tr>
<th>구현</th>
<th>매체</th>
<th>최대 길이</th>
<th>부호화</th>
</tr>
</thead>
<tbody><tr>
<td>10GBase-SR</td>
<td>MMF (다중모드)</td>
<td>~300m</td>
<td>64B/66B</td>
</tr>
<tr>
<td>10GBase-LR</td>
<td>SMF (단일모드)</td>
<td>~10km</td>
<td>64B/66B</td>
</tr>
<tr>
<td>10GBase-ER</td>
<td>SMF</td>
<td>~40km</td>
<td>64B/66B</td>
</tr>
<tr>
<td>10GBase-T</td>
<td>UTP</td>
<td>~100m</td>
<td>PAM-16</td>
</tr>
</tbody></table>
<hr>
<h2 id="42-wifi-ieee-80211">4.2 WiFi (IEEE 802.11)</h2>
<p>무선 LAN 표준이다. IEEE 802.11이 기술 표준이고, WiFi는 Wi-Fi Alliance가 붙인 인증 브랜드 이름이다.</p>
<h3 id="네트워크-구조">네트워크 구조</h3>
<p><strong>BSS (Basic Service Set)</strong>
하나의 AP를 중심으로 구성된 최소 단위 무선 네트워크다.</p>
<ul>
<li><strong>Ad hoc BSS</strong>: AP 없이 단말끼리 직접 통신 (임시 네트워크)</li>
<li><strong>Infrastructure BSS</strong>: AP 중심 구조, 모든 통신이 AP를 통해 이루어짐</li>
</ul>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/b47349c1-51f3-4907-a82b-366560185601/image.png" alt=""></p>
<p><strong>ESS (Extended Service Set)</strong>
여러 BSS를 유선망(Distribution System)으로 연결한 구조다. BSS 간 이동 시에도 끊김 없이 통신 가능 (로밍).</p>
<h3 id="mac-접근-방식">MAC 접근 방식</h3>
<p><strong>DCF (Distributed Coordination Function)</strong>
WiFi의 기본 방식이고, CSMA/CA 기반이다.</p>
<pre><code>채널 감지 → Idle → DIFS 대기 → 랜덤 백오프
→ 전송 → ACK 수신 (없으면 재전송)</code></pre><p><strong>NAV (Network Allocation Vector)</strong>
채널이 앞으로 사용될 시간을 알려주는 가상 캐리어 감지 정보다. 송신 노드가 프레임에 Duration 정보를 포함하면 주변 노드들이 그 시간 동안 전송을 금지한다.</p>
<p><strong>RTS/CTS 메커니즘</strong>
Hidden node 문제를 해결하기 위한 방식이다.</p>
<pre><code>송신자 → RTS → 수신자
수신자 → CTS → 모든 주변 노드 (NAV 설정)
송신자 → Data → 수신자
수신자 → ACK → 송신자</code></pre><p><strong>인터프레임 간격 우선순위</strong>
SIFS &lt; PIFS &lt; DIFS 순서로, 값이 작을수록 채널 접근 우선순위가 높다.</p>
<h3 id="ieee-80211-프레임-구조">IEEE 802.11 프레임 구조</h3>
<table>
<thead>
<tr>
<th>필드</th>
<th>크기</th>
<th>설명</th>
</tr>
</thead>
<tbody><tr>
<td>FC (Frame Control)</td>
<td>2바이트</td>
<td>프레임 종류, 방향, 암호화 여부 등</td>
</tr>
<tr>
<td>Duration/ID</td>
<td>2바이트</td>
<td>NAV 설정용 채널 점유 시간</td>
</tr>
<tr>
<td>Address 1~4</td>
<td>각 6바이트</td>
<td>수신자/송신자/BSSID/WDS</td>
</tr>
<tr>
<td>Sequence Control</td>
<td>2바이트</td>
<td>순서 번호, 단편화 번호</td>
</tr>
<tr>
<td>Frame Body</td>
<td>0~2312바이트</td>
<td>실제 데이터</td>
</tr>
<tr>
<td>FCS</td>
<td>4바이트</td>
<td>CRC 오류 검출</td>
</tr>
</tbody></table>
<p><strong>802.11 주소 체계 (To DS / From DS)</strong></p>
<table>
<thead>
<tr>
<th>To DS</th>
<th>From DS</th>
<th>Address 1</th>
<th>Address 2</th>
<th>Address 3</th>
<th>Address 4</th>
</tr>
</thead>
<tbody><tr>
<td>0</td>
<td>0</td>
<td>목적지</td>
<td>출발지</td>
<td>BSSID</td>
<td>-</td>
</tr>
<tr>
<td>0</td>
<td>1</td>
<td>목적지</td>
<td>AP</td>
<td>출발지</td>
<td>-</td>
</tr>
<tr>
<td>1</td>
<td>0</td>
<td>AP</td>
<td>출발지</td>
<td>목적지</td>
<td>-</td>
</tr>
<tr>
<td>1</td>
<td>1</td>
<td>수신 AP</td>
<td>송신 AP</td>
<td>목적지</td>
<td>출발지</td>
</tr>
</tbody></table>
<p>핵심 규칙: Address 1은 항상 현재 수신자(RA), Address 2는 항상 현재 송신자(TA).</p>
<h3 id="물리층-기술-비교">물리층 기술 비교</h3>
<table>
<thead>
<tr>
<th>IEEE</th>
<th>기술</th>
<th>주파수</th>
<th>속도</th>
</tr>
</thead>
<tbody><tr>
<td>802.11</td>
<td>FHSS/DSSS</td>
<td>2.4GHz</td>
<td>1~2Mbps</td>
</tr>
<tr>
<td>802.11a</td>
<td>OFDM</td>
<td>5GHz</td>
<td>6~54Mbps</td>
</tr>
<tr>
<td>802.11b</td>
<td>DSSS</td>
<td>2.4GHz</td>
<td>5.5~11Mbps</td>
</tr>
<tr>
<td>802.11g</td>
<td>OFDM</td>
<td>2.4GHz</td>
<td>22~54Mbps</td>
</tr>
<tr>
<td>802.11n</td>
<td>OFDM</td>
<td>5GHz</td>
<td>600Mbps</td>
</tr>
</tbody></table>
<hr>
<h2 id="43-블루투스">4.3 블루투스</h2>
<p>IEEE 802.15.1 기반의 WPAN(Wireless Personal Area Network)이다. 근거리(10m 내외)에서 저전력 무선 통신을 지원한다.</p>
<p><strong>네트워크 구조</strong></p>
<ul>
<li><strong>피코넷(Piconet)</strong>: 1개의 Primary + 최대 7개의 Secondary로 구성. Primary가 타이밍과 주파수 호핑 순서를 결정한다.</li>
<li><strong>스캐터넷(Scatternet)</strong>: 여러 피코넷이 연결된 구조. 한 피코넷의 Secondary가 다른 피코넷에서 Primary가 될 수 있다.</li>
</ul>
<p><strong>블루투스 계층 구조</strong></p>
<table>
<thead>
<tr>
<th>계층</th>
<th>역할</th>
</tr>
</thead>
<tbody><tr>
<td>Radio Layer</td>
<td>물리층 유사. 2.4GHz ISM 대역, FHSS 방식 (초당 1600번 도약)</td>
</tr>
<tr>
<td>Baseband Layer</td>
<td>MAC 계층 유사. 주소 지정, 슬롯 기반 전송, 오류 제어</td>
</tr>
<tr>
<td>L2CAP</td>
<td>LLC 부계층 유사. 다중화, 분할/재조립, 그룹 관리</td>
</tr>
</tbody></table>
<p>블루투스는 TDD-TDMA 방식을 사용한다. 시간을 625μs 슬롯으로 나눠서 Primary는 짝수 슬롯에, Secondary는 홀수 슬롯에 전송한다.</p>
<hr>
<h2 id="스스로-확인해보기">스스로 확인해보기</h2>
<p>이 섹션을 읽고 아래 질문들에 바로 대답할 수 있으면 완벽하게 이해한 거다.</p>
<p><strong>[ 이더넷 ]</strong></p>
<blockquote>
<p>Q1. 이더넷 최소 프레임 크기가 64바이트인 이유는 무엇인가?</p>
</blockquote>
<blockquote>
<p>Q2. 표준 이더넷, 기가비트 이더넷, 10기가비트 이더넷에서 각각 CSMA/CD를 사용하는지 안 하는지 설명해보자.</p>
</blockquote>
<blockquote>
<p>Q3. MAC 주소 <code>4A:30:10:21:10:1A</code>는 유니캐스트인가, 멀티캐스트인가? 어떻게 구별하는가?</p>
</blockquote>
<blockquote>
<p>Q4. Manchester Encoding에서 0과 1을 각각 어떻게 표현하는가?</p>
</blockquote>
<hr>
<p><strong>[ WiFi ]</strong></p>
<blockquote>
<p>Q5. BSS와 ESS의 차이를 설명해보자.</p>
</blockquote>
<blockquote>
<p>Q6. DCF에서 DIFS, 랜덤 백오프, ACK의 역할을 각각 설명해보자.</p>
</blockquote>
<blockquote>
<p>Q7. RTS/CTS 메커니즘이 필요한 이유는 무엇인가? (Hidden node 문제)</p>
</blockquote>
<blockquote>
<p>Q8. SIFS &lt; PIFS &lt; DIFS 순서가 의미하는 것은 무엇인가?</p>
</blockquote>
<blockquote>
<p>Q9. 802.11 프레임에서 To DS=1, From DS=0일 때 Address 1, 2, 3에 각각 무엇이 들어가는가?</p>
</blockquote>
<hr>
<p><strong>[ 블루투스 ]</strong></p>
<blockquote>
<p>Q10. 피코넷에서 Primary와 Secondary의 역할 차이는 무엇인가?</p>
</blockquote>
<blockquote>
<p>Q11. 스캐터넷이란 무엇인가?</p>
</blockquote>
<blockquote>
<p>Q12. 블루투스가 FHSS를 사용하는 이유는 무엇인가?</p>
</blockquote>
<hr>
<p><strong>[ 연결 장치 비교 ]</strong></p>
<blockquote>
<p>Q13. 허브, 스위치, 라우터를 동작 계층과 사용 주소 기준으로 비교해보자.</p>
</blockquote>
<blockquote>
<p>Q14. Transparent Switch에서 목적지 MAC 주소를 모를 때 어떻게 동작하는가?</p>
</blockquote>
<blockquote>
<p>Q15. 스패닝 트리 알고리즘이 필요한 이유는 무엇인가?</p>
</blockquote>
<blockquote>
<p>Q16. VLAN 태그(IEEE 802.1Q)가 필요한 상황은 언제인가? VID는 몇 비트이고 최대 몇 개의 VLAN을 구분할 수 있는가?</p>
</blockquote>
<hr>
<h2 id="핵심-요약">핵심 요약</h2>
<ul>
<li>이더넷 발전: 10M → 100M → 1G → 10Gbps, 프레임 구조와 MAC 주소 체계는 동일 유지</li>
<li>이더넷 최소 프레임 64바이트, 최대 1518바이트</li>
<li>기가비트 이더넷부터 전이중 모드 중심 → CSMA/CD 사실상 미사용</li>
<li>WiFi = IEEE 802.11, BSS(단일 AP) / ESS(여러 BSS 연결)</li>
<li>WiFi MAC 기본 방식 = DCF (CSMA/CA)</li>
<li>NAV = 가상 캐리어 감지, RTS/CTS = Hidden node 문제 해결</li>
<li>SIFS &lt; PIFS &lt; DIFS (값 작을수록 우선순위 높음)</li>
<li>블루투스 = IEEE 802.15.1, Piconet(1:7) + Scatternet 구조, FHSS 초당 1600번 도약</li>
<li>허브(Layer 1, 플러딩) → 스위치(Layer 2, MAC) → 라우터(Layer 3, IP)</li>
<li>VLAN 태그 VID = 12비트 → 최대 4096개 VLAN 구분 가능</li>
</ul>
<hr>
<h2 id="참고문헌">참고문헌</h2>
<blockquote>
<p>Forouzan, B. A. (2013). <em>Data Communications and Networking</em> (6th ed.). McGraw-Hill.
번역: 이재광, 김중규, 이경현, 홍충선. <em>데이터 통신과 네트워킹 TCP/IP 프로토콜 기반</em> (개정 6 수정판). 퍼스트북.</p>
</blockquote>
]]></description>
        </item>
        <item>
            <title><![CDATA[[컴퓨터 네트워크] 3장 - 데이터링크층 (Data Link Layer)]]></title>
            <link>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-3%EC%9E%A5-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%A7%81%ED%81%AC%EC%B8%B5-Data-Link-Layer</link>
            <guid>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-3%EC%9E%A5-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%A7%81%ED%81%AC%EC%B8%B5-Data-Link-Layer</guid>
            <pubDate>Sat, 18 Apr 2026 14:58:56 GMT</pubDate>
            <description><![CDATA[<h2 id="데이터링크층이란">데이터링크층이란?</h2>
<p>OSI 7계층 중 2계층이고, 물리층 바로 위에 있다. 물리층이 비트를 전송하는 역할이라면, 데이터링크층은 <strong>인접한 노드 간(Hop-to-Hop)</strong> 데이터를 안정적으로 전달하는 역할이다.</p>
<p>핵심 기능은 네 가지다.</p>
<ul>
<li><strong>프레이밍(Framing)</strong>: 데이터를 프레임 단위로 구분</li>
<li><strong>오류 제어(Error Control)</strong>: 오류 검출 및 재전송</li>
<li><strong>흐름 제어(Flow Control)</strong>: 송수신 속도 조절</li>
<li><strong>매체 접근 제어(MAC)</strong>: 공유 매체에서 충돌 방지</li>
</ul>
<blockquote>
<p><strong>Hop-to-Hop vs End-to-End</strong></p>
<ul>
<li>Hop-to-Hop: 바로 옆 노드까지만 전달 (데이터링크층)</li>
<li>End-to-End: 최종 목적지까지 전달 (전송층)</li>
</ul>
</blockquote>
<hr>
<h2 id="31-링크의-두-가지-유형">3.1 링크의 두 가지 유형</h2>
<p><strong>점-대-점 링크 (Point-to-Point)</strong>
두 노드 간 1:1 전용 연결이다. 전송 대상이 명확하고, PPP나 전용 회선이 이 방식이다.</p>
<p><strong>브로드캐스트 링크 (Broadcast)</strong>
여러 노드가 하나의 매체를 공유하는 방식이다. 충돌 가능성이 있어서 MAC 제어가 필요하다. Ethernet, Wi-Fi가 대표적이다.</p>
<hr>
<h2 id="32-데이터링크-제어-dlc">3.2 데이터링크 제어 (DLC)</h2>
<p>데이터링크층은 두 개의 부계층으로 나뉜다.</p>
<table>
<thead>
<tr>
<th>부계층</th>
<th>역할</th>
<th>핵심 기능</th>
</tr>
</thead>
<tbody><tr>
<td>DLC (Data Link Control)</td>
<td>데이터를 정확하게 보내는 것</td>
<td>프레이밍, 오류 제어, 흐름 제어</td>
</tr>
<tr>
<td>MAC (Media Access Control)</td>
<td>매체 접근 경쟁 해결</td>
<td>충돌 방지, MAC 주소 기반 전달</td>
</tr>
</tbody></table>
<hr>
<h2 id="321-프레이밍-framing">3.2.1 프레이밍 (Framing)</h2>
<p>비트 스트림을 프레임 단위로 잘라서 시작과 끝을 표시하는 과정이다. 프레임에는 송신자 MAC, 수신자 MAC, 데이터(payload), 오류 검출 정보(CRC)가 들어간다.</p>
<p><strong>바이트 기반 방식 (Byte Stuffing)</strong>
특정 Flag 문자로 프레임 시작/끝을 표시한다. 데이터 안에 Flag와 같은 문자가 있으면 Escape 처리를 한다.</p>
<pre><code>Flag: 0x7E, Escape: 0x5E
원본: 0x12 0x7E 0x34 0x5E
전송: 0x12 0x5E 0x7E 0x34 0x5E 0x5E</code></pre><p><strong>비트 기반 방식 (Bit Stuffing)</strong>
Flag 비트 패턴(01111110)으로 경계를 표시한다. 데이터에서 1이 5개 연속으로 나오면 0을 삽입한다.</p>
<pre><code>원본: 00011111 1110011111 01000
전송: 0001111101110011111001000</code></pre><hr>
<h2 id="322-오류-제어-error-control">3.2.2 오류 제어 (Error Control)</h2>
<p><strong>오류 종류</strong></p>
<ul>
<li>단일 비트 오류: 한 비트만 반전. 드물게 발생.</li>
<li>폭주 오류(Burst Error): 연속된 여러 비트 오류. 실제 통신에서 더 흔함.</li>
</ul>
<p>오류를 검출하려면 데이터에 <strong>중복 비트(Redundant bits)</strong> 를 추가해서 함께 전송한다.</p>
<p><strong>CRC (Cyclic Redundancy Check)</strong> — 가장 강력한 방식</p>
<pre><code>송신: 데이터 ÷ g(x) → 나머지 = CRC → 전송 = 데이터 + CRC
수신: (데이터+CRC) ÷ g(x) → 나머지 = 0이면 정상, ≠ 0이면 오류</code></pre><table>
<thead>
<tr>
<th>방식</th>
<th>검출 능력</th>
<th>주요 사용처</th>
</tr>
</thead>
<tbody><tr>
<td>패리티 검사</td>
<td>단일 비트만</td>
<td>메모리</td>
</tr>
<tr>
<td>블록 검사</td>
<td>다수 비트</td>
<td>과거 통신</td>
</tr>
<tr>
<td>CRC</td>
<td>매우 강력</td>
<td>Ethernet, ZIP</td>
</tr>
<tr>
<td>체크섬</td>
<td>중간</td>
<td>TCP/IP</td>
</tr>
</tbody></table>
<p><strong>해밍 거리 (Hamming Distance)</strong>
두 코드워드 간 다른 비트 수다. XOR 연산 후 1의 개수를 세면 된다.</p>
<pre><code>000 ⊕ 011 = 011 → 해밍 거리 = 2
10101 ⊕ 11110 = 01011 → 해밍 거리 = 3</code></pre><hr>
<h2 id="323-dlc-프로토콜">3.2.3 DLC 프로토콜</h2>
<h3 id="hdlc">HDLC</h3>
<p>비트 기반 데이터링크 프로토콜이다. WAN, 라우터 간 링크에서 사용한다.</p>
<p>전송 모드 두 가지.</p>
<ul>
<li><strong>NRM</strong>: 주국이 제어, 종국은 요청받을 때만 응답. 중앙 집중 구조.</li>
<li><strong>ABM</strong>: 모든 노드 동등하게 통신. 어느 노드든 먼저 전송 가능.</li>
</ul>
<table>
<thead>
<tr>
<th>프레임</th>
<th>역할</th>
</tr>
</thead>
<tbody><tr>
<td>I-frame</td>
<td>실제 데이터 전달, 순서 번호 포함</td>
</tr>
<tr>
<td>S-frame</td>
<td>오류/흐름 제어 (ACK, NAK)</td>
</tr>
<tr>
<td>U-frame</td>
<td>연결 설정/해제</td>
</tr>
</tbody></table>
<p><strong>피기백킹 (Piggybacking)</strong>: 데이터 프레임에 ACK를 함께 실어 보내서 전송 효율을 높이는 방식이다.</p>
<h3 id="ppp-point-to-point-protocol">PPP (Point-to-Point Protocol)</h3>
<p>바이트 기반 데이터링크 프로토콜이다. 가정용 인터넷 접속, 라우터 간 WAN 연결에서 사용한다. 순서번호/흐름 제어/오류 재전송이 없고 단순 전달에 집중한다.</p>
<p><strong>PPP 연결 단계</strong></p>
<pre><code>Dead → Establish(LCP) → Authenticate(PAP/CHAP) → Network(NCP) → Open → Terminate</code></pre><ul>
<li><strong>LCP</strong>: 링크 설정/유지/종료</li>
<li><strong>PAP</strong>: 평문 인증 (보안 취약)</li>
<li><strong>CHAP</strong>: 챌린지-응답 인증 (재전송 공격 방어)</li>
<li><strong>NCP</strong>: IP 주소 할당 등 네트워크 계층 설정</li>
</ul>
<blockquote>
<p><strong>TMI</strong>: 특히 JWT 토큰 인증 방식이 PPP의 CHAP처럼 챌린지-응답 기반으로 설계하면 더 안전하다.</p>
</blockquote>
<hr>
<h2 id="33-매체-접근-프로토콜-mac-protocol">3.3 매체 접근 프로토콜 (MAC Protocol)</h2>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/c8f66b89-ebfe-4756-b967-1bfd7eba301c/image.png" alt=""></p>
<h3 id="임의-접근-random-access">임의 접근 (Random Access)</h3>
<p>중앙 제어 없이 노드가 자율적으로 전송하는 방식이다.</p>
<p><strong>CSMA/CD (Collision Detection)</strong> — 유선 Ethernet</p>
<pre><code>채널 감지 → Idle이면 전송 → 전송 중 충돌 감지 → 즉시 중단 → Backoff → 재전송</code></pre><p><strong>CSMA/CA (Collision Avoidance)</strong> — 무선 Wi-Fi</p>
<pre><code>채널 감지 → Idle이면 IFS 대기 후 전송 → ACK로 성공 확인
Busy이면 랜덤 Backoff → 재시도</code></pre><table>
<thead>
<tr>
<th></th>
<th>CSMA/CD</th>
<th>CSMA/CA</th>
</tr>
</thead>
<tbody><tr>
<td>환경</td>
<td>유선 (Ethernet)</td>
<td>무선 (Wi-Fi)</td>
</tr>
<tr>
<td>방식</td>
<td>충돌 <strong>감지</strong> 후 처리</td>
<td>충돌 <strong>회피</strong> 사전 예방</td>
</tr>
<tr>
<td>충돌 감지</td>
<td>가능</td>
<td>어려움</td>
</tr>
</tbody></table>
<p><strong>CSMA 지속 방식</strong></p>
<table>
<thead>
<tr>
<th>방식</th>
<th>동작</th>
<th>특징</th>
</tr>
</thead>
<tbody><tr>
<td>1-persistent</td>
<td>Idle이면 즉시 전송</td>
<td>충돌 확률 높음</td>
</tr>
<tr>
<td>Nonpersistent</td>
<td>Busy면 랜덤 대기</td>
<td>충돌 감소, 지연 증가</td>
</tr>
<tr>
<td>p-persistent</td>
<td>확률 p로 전송</td>
<td>충돌과 지연의 절충</td>
</tr>
</tbody></table>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/659d2277-39f4-41b5-b136-372d48839d35/image.png" alt=""></p>
<h3 id="제어-접근-controlled-access">제어 접근 (Controlled Access)</h3>
<p>충돌 없이 전송 권한을 얻은 노드만 전송하는 방식이다.</p>
<ul>
<li><strong>예약(Reservation)</strong>: 미리 슬롯 예약 후 순서대로 전송</li>
<li><strong>폴링(Polling)</strong>: 주국이 순서대로 종국에게 전송 기회 부여</li>
<li><strong>토큰 전달(Token Passing)</strong>: 토큰 가진 노드만 전송, 다음 노드에 넘김</li>
</ul>
<hr>
<h2 id="34-링크-계층-주소-지정">3.4 링크 계층 주소 지정</h2>
<h3 id="ip-주소-vs-mac-주소">IP 주소 vs MAC 주소</h3>
<table>
<thead>
<tr>
<th></th>
<th>IP 주소</th>
<th>MAC 주소</th>
</tr>
</thead>
<tbody><tr>
<td>역할</td>
<td>최종 목적지 식별</td>
<td>인접 노드 식별</td>
</tr>
<tr>
<td>범위</td>
<td>End-to-End</td>
<td>Hop-to-Hop</td>
</tr>
<tr>
<td>변경</td>
<td>네트워크 이동 시 변경</td>
<td>고정 (48bit)</td>
</tr>
<tr>
<td>예시</td>
<td>192.168.0.1</td>
<td>AA:BB:CC:DD:EE:FF</td>
</tr>
</tbody></table>
<h3 id="세-가지-주소-유형">세 가지 주소 유형</h3>
<ul>
<li><strong>유니캐스트</strong>: 1:1 통신</li>
<li><strong>멀티캐스트</strong>: 1:그룹 통신 (IPv4: 01:00:5E:xx:xx:xx)</li>
<li><strong>브로드캐스트</strong>: 1:전체 통신 (FF:FF:FF:FF:FF:FF)</li>
</ul>
<h3 id="arp-address-resolution-protocol">ARP (Address Resolution Protocol)</h3>
<p>IP 주소는 알지만 MAC 주소를 모를 때 MAC 주소를 알아내는 프로토콜이다.</p>
<pre><code>1. ARP Request (브로드캐스트): &quot;192.168.0.5 MAC 주소 가진 사람 누구?&quot;
2. ARP Reply (유니캐스트): &quot;나야! 내 MAC은 AA:BB:CC:DD:EE:FF&quot;
3. ARP Cache 저장: 다음엔 다시 물어보지 않아도 됨</code></pre><p><img src="https://velog.velcdn.com/images/opentime_kr/post/d6681f74-a96e-44a5-8aca-2c18006dea2a/image.png" alt=""></p>
<blockquote>
<p><strong>TMI</strong>: 터미널에서 <code>arp -a</code> 명령어로 현재 ARP 캐시 테이블을 직접 확인할 수 있다. 같은 네트워크 안에서 어떤 IP가 어떤 MAC 주소와 매핑되어 있는지 볼 수 있다.</p>
</blockquote>
<hr>
<h2 id="핵심-요약">핵심 요약</h2>
<ul>
<li>데이터링크층 = 인접 노드(Hop-to-Hop) 간 안정적 전달 담당</li>
<li>DLC: 프레이밍, 오류 제어(CRC), 흐름 제어</li>
<li>MAC: 충돌 방지, 전송 순서 결정</li>
<li>오류 검출: 패리티 &lt; 블록 검사 &lt; CRC 순으로 강력</li>
<li>Random Access: CSMA/CD(유선), CSMA/CA(무선)</li>
<li>Controlled Access: 폴링, 토큰 전달, 예약</li>
<li>IP 주소 = End-to-End, MAC 주소 = Hop-to-Hop</li>
<li>ARP = IP → MAC 주소 변환</li>
</ul>
<hr>
<h2 id="참고문헌">참고문헌</h2>
<blockquote>
<p>Forouzan, B. A. (2013). <em>Data Communications and Networking</em> (6th ed.). McGraw-Hill.
번역: 이재광, 김중규, 이경현, 홍충선. <em>데이터 통신과 네트워킹 TCP/IP 프로토콜 기반</em> (개정 6 수정판). 퍼스트북.</p>
</blockquote>
]]></description>
        </item>
        <item>
            <title><![CDATA[[컴퓨터 네트워크] 2장 - 물리층 (Physical Layer)]]></title>
            <link>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-2%EC%9E%A5-%EB%AC%BC%EB%A6%AC%EC%B8%B5-Physical-Layer</link>
            <guid>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-2%EC%9E%A5-%EB%AC%BC%EB%A6%AC%EC%B8%B5-Physical-Layer</guid>
            <pubDate>Sun, 12 Apr 2026 01:43:41 GMT</pubDate>
            <description><![CDATA[<p><em>데이터 통신과 네트워킹</em> (Forouzan, 6판) 2장 학습 내용 정리.
물리층은 TCP/IP 5계층 중 가장 하위 계층으로, 이 장에서는 신호의 종류와 특성, 전송 중 발생하는 장애, 디지털 변환 방식, 다중화, 전송 매체까지 물리층 전반을 다룬다.</p>
<hr>
<h2 id="물리층이란">물리층이란?</h2>
<p>OSI 7계층 중 가장 하위 계층이고, 실제로 비트(0과 1)를 물리적 신호로 바꿔서 전송 매체를 통해 전달하는 역할을 한다. 쉽게 말하면 데이터를 실제로 선 위에 올려서 보내는 계층이다.</p>
<hr>
<h2 id="21-신호-signal">2.1 신호 (Signal)</h2>
<p>데이터를 전송할 때 물리층은 신호를 주고받는다. 신호란 정보 전달을 위한 물리적 파형으로, 시간에 따라 변화하는 전압이나 전류, 빛의 세기 같은 것들이다.</p>
<p>신호는 크게 두 가지 형태로 나뉜다.</p>
<p><strong>아날로그 신호 (Analog)</strong>
시간에 따라 연속적으로 변화하는 신호다. 무한한 값 범위를 표현할 수 있고, 음성이나 라디오 같은 자연 신호 표현에 적합하다. 단점은 잡음(noise)에 의해 신호가 왜곡될 수 있다는 것이다.</p>
<p><strong>디지털 신호 (Digital)</strong>
0과 1 두 가지 이산적인 값만 표현하는 신호다. 오류 검출과 복구가 상대적으로 쉽고, 컴퓨터 네트워크 데이터 전송에 주로 사용한다.</p>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/c96e9bc9-32ca-4041-9df8-4d7f59aefc12/image.png" alt=""></p>
<p><em>아날로그는 연속적인 사인파, 디지털은 High(1)/Low(0)로만 표현한다</em></p>
<hr>
<h2 id="211-아날로그-신호-특성">2.1.1 아날로그 신호 특성</h2>
<p>아날로그 신호, 특히 사인파(sine wave)는 세 가지 특성으로 표현된다.</p>
<table>
<thead>
<tr>
<th>특성</th>
<th>설명</th>
<th>단위</th>
</tr>
</thead>
<tbody><tr>
<td>진폭 (Amplitude)</td>
<td>신호의 최대 세기 (파형의 높이)</td>
<td>Volt</td>
</tr>
<tr>
<td>주파수 (Frequency)</td>
<td>1초 동안 반복되는 사이클 수</td>
<td>Hz</td>
</tr>
<tr>
<td>위상 (Phase)</td>
<td>파형의 시작 위치 (기준 대비 이동량)</td>
<td>도(°)</td>
</tr>
</tbody></table>
<p>주파수와 주기는 역수 관계다. 주파수가 60Hz면 주기는 1/60초다.</p>
<p><strong>복합 신호와 대역폭</strong>
실제 통신에서 단순 사인파 하나로는 데이터를 충분히 표현하기 어렵다. 그래서 실제 통신 신호는 여러 개의 사인파가 합쳐진 <strong>복합 신호</strong> 형태로 구성된다. 이때 신호가 포함하는 주파수 범위를 <strong>대역폭(Bandwidth)</strong> 이라고 한다.</p>
<hr>
<h2 id="212-디지털-신호">2.1.2 디지털 신호</h2>
<p>디지털 신호는 높은 전압(1)과 낮은 전압(0)으로 데이터를 표현한다. 레벨 수를 늘리면 하나의 신호 변화로 더 많은 비트를 표현할 수 있다.</p>
<ul>
<li>2레벨 신호: 한 번의 변화로 1비트 표현</li>
<li>4레벨 신호: 한 번의 변화로 2비트 표현 (log₂4 = 2)</li>
</ul>
<p><strong>기저대역 전송 vs 광대역 전송</strong></p>
<table>
<thead>
<tr>
<th></th>
<th>기저대역 (Baseband)</th>
<th>광대역 (Wideband)</th>
</tr>
</thead>
<tbody><tr>
<td>방식</td>
<td>변조 없이 원본 신호 그대로 전송</td>
<td>변조 기법으로 특정 주파수에 실어 전송</td>
</tr>
<tr>
<td>특징</td>
<td>단순, 단거리에 적합</td>
<td>복잡, 장거리/다중 사용자 가능</td>
</tr>
<tr>
<td>예시</td>
<td>Ethernet (Cat5e, Cat6)</td>
<td>Wi-Fi, LTE, 5G</td>
</tr>
</tbody></table>
<hr>
<h2 id="22-신호-장애">2.2 신호 장애</h2>
<p>신호가 전송 매체를 통해 이동하면서 세 가지 장애가 발생할 수 있다.</p>
<p><strong>감쇠 (Attenuation)</strong>
신호가 매체를 통해 이동할수록 에너지가 점점 줄어드는 현상이다. 거리가 멀어질수록 신호가 약해진다. 이걸 해결하기 위해 <strong>증폭기(Amplifier)</strong> 를 중간에 설치해서 신호를 다시 키운다.</p>
<p><strong>왜곡 (Distortion)</strong>
복합 신호는 여러 주파수 성분으로 이루어져 있는데, 각 주파수 성분이 매체를 통과할 때 속도가 달라서 수신 측에 도착하는 시간이 달라진다. 이로 인해 신호 모양이 원래와 다르게 변형된다.</p>
<p><strong>잡음 (Noise)</strong>
전송 중에 외부에서 원치 않는 신호가 섞이는 현상이다. 열잡음, 유도잡음, 충격잡음 등 여러 종류가 있다.</p>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/50b647c9-bfae-45cb-9473-12353d27e6c4/image.png" alt=""></p>
<p><em>원본 신호에서 감쇠(진폭 감소), 왜곡(형태 변형), 잡음(불규칙 간섭)이 각각 어떻게 나타나는지 비교</em></p>
<hr>
<h2 id="223-데이터-전송률의-한계">2.2.3 데이터 전송률의 한계</h2>
<p>채널이 전송할 수 있는 최대 비트율을 결정하는 두 가지 이론적 공식이 있다.</p>
<p><strong>나이퀴스트 비트율 (Nyquist Bit Rate)</strong> — 잡음이 없는 이상적인 채널</p>
<pre><code>Bit Rate = 2 × B × log₂L</code></pre><ul>
<li>B: 채널 대역폭 (Hz)</li>
<li>L: 신호 준위의 수 (Signal Levels)</li>
</ul>
<p>예시: 채널 대역폭이 10kHz이고 신호 준위가 256(= 2⁸)이면
→ Bit Rate = 2 × 10,000 × 8 = <strong>160,000 bps</strong></p>
<p>신호 준위(L)를 높이면 비트율을 높일 수 있지만, 준위가 많아질수록 신호 간 간격이 좁아져 잡음에 의한 오류가 증가한다는 trade-off가 있다.</p>
<p><strong>섀넌 용량 (Shannon Capacity)</strong> — 잡음이 있는 실제 채널</p>
<pre><code>C = B × log₂(1 + SNR)</code></pre><ul>
<li>B: 채널 대역폭 (Hz)</li>
<li>SNR: 신호 대 잡음 비율 (Signal-to-Noise Ratio)</li>
<li>C: 채널 용량 (bps)</li>
</ul>
<p>SNR이 0에 가까우면(잡음이 신호만큼 강하면) C = 0이 된다. 즉 대역폭이 있어도 데이터를 전송할 수 없다.</p>
<p>예시: 일반 전화선 (B = 3,000Hz, SNR = 35dB ≈ 3162)
→ C = 3000 × log₂(1 + 3162) ≈ <strong>34,881 bps</strong></p>
<p>두 공식의 차이를 정리하면, 나이퀴스트는 잡음이 없는 이상적인 환경에서의 이론상 최대치고, 섀넌은 잡음까지 고려한 실질적인 한계다. 실제 시스템 설계에서는 두 값을 모두 계산한 뒤 낮은 쪽이 실제 제한이 된다.</p>
<hr>
<h2 id="224-성능-지표">2.2.4 성능 지표</h2>
<p><strong>지연 (Latency)</strong>
데이터가 출발지에서 목적지까지 걸리는 총 시간이다.</p>
<pre><code>지연 = 전파시간 + 전송시간 + 큐시간 + 처리시간</code></pre><ul>
<li><strong>전파시간</strong>: 신호가 물리 매체를 따라 이동하는 시간 (거리/속도)</li>
<li><strong>전송시간</strong>: 데이터를 링크에 밀어 넣는 시간 (데이터크기/전송속도)</li>
<li><strong>큐시간</strong>: 네트워크 장비 큐에서 기다리는 시간</li>
<li><strong>처리시간</strong>: 패킷 오류 검사, 경로 결정 등에 걸리는 시간</li>
</ul>
<p><strong>대역폭-지연 곱 (Bandwidth-Delay Product, BDP)</strong>
링크를 파이프라고 생각하면, 파이프 단면이 대역폭이고 파이프 길이가 지연이다. 이 둘을 곱하면 파이프 안에 동시에 존재할 수 있는 데이터 양이 나온다.</p>
<ul>
<li>BDP가 작은 경우 (LAN): ACK가 빠르게 돌아와서 관리가 쉬움</li>
<li>BDP가 큰 경우 (위성통신): 링크 안에 데이터가 많아서 TCP Window를 크게 잡아야 함</li>
</ul>
<hr>
<h2 id="23-디지털-전송">2.3 디지털 전송</h2>
<p>데이터를 신호로 변환해서 전송하는 과정이다.</p>
<h3 id="digital-to-digital-변환">Digital-to-Digital 변환</h3>
<p><strong>회선 부호화 (Line Coding)</strong>
디지털 데이터를 전송용 디지털 신호로 변환하는 과정이다. 수신 측 동기화, DC 성분 제어, 대역폭 관리 등을 위해 변환한다.</p>
<p><strong>블록 부호화 (Block Coding)</strong>
데이터에 여분의 비트를 추가해서 오류 검출 능력을 높이는 기법이다. 4B/5B처럼 4비트를 5비트로 변환하는 방식이 대표적이다.</p>
<p><strong>스크램블링 (Scrambling)</strong>
긴 0이나 1의 연속이 발생하면 수신 측에서 동기화가 어려워진다. 이를 방지하기 위해 데이터 패턴을 특정 규칙에 따라 바꾸는 기법이다. 블록 부호화와 달리 비트를 추가하지 않는다.</p>
<h3 id="analog-to-digital-변환-adc">Analog-to-Digital 변환 (ADC)</h3>
<p><strong>PCM (Pulse Code Modulation)</strong> — 가장 많이 쓰이는 방식</p>
<p>아날로그 신호를 디지털로 변환하는 3단계 과정이다.</p>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/6456a104-25e1-4299-a2e3-d8189c1de10e/image.png" alt=""></p>
<p><em>아날로그 신호 → 샘플링(점 추출) → 양자화(단계 근사) → 부호화(비트열 변환)</em></p>
<p>나이퀴스트 정리에 따르면 샘플링 주파수는 원본 신호 최대 주파수의 2배 이상이어야 한다.</p>
<pre><code>예시: 사람 음성 (0~4000Hz)
샘플링 주파수 = 4000 × 2 = 8000 samples/s
비트율 = 8000 × 8bit = 64,000 bps = 64 kbps

CD 음질 (44.1kHz, 16bit, 스테레오)
비트율 = 44,100 × 16 × 2 = 1,411,200 bps ≈ 1.4 Mbps</code></pre><p><strong>델타 변조 (Delta Modulation)</strong>
PCM보다 단순한 방식이다. 이전 샘플과 비교해서 신호가 올라가면 1, 내려가면 0만 전송한다. 구조가 단순한 대신 급격한 변화에서 오차가 생길 수 있다.</p>
<hr>
<h2 id="24-아날로그-전송-변조-방식">2.4 아날로그 전송 (변조 방식)</h2>
<p>디지털 데이터를 아날로그 신호로 변환해서 전송하는 방식이다. 반송파(carrier signal)의 특성을 변화시켜 데이터를 싣는다.</p>
<table>
<thead>
<tr>
<th>변조 방식</th>
<th>변화시키는 특성</th>
<th>특징</th>
</tr>
</thead>
<tbody><tr>
<td>ASK (진폭 편이 변조)</td>
<td>진폭</td>
<td>구현 단순, 잡음에 취약</td>
</tr>
<tr>
<td>FSK (주파수 편이 변조)</td>
<td>주파수</td>
<td>잡음에 강함, 대역폭 많이 사용</td>
</tr>
<tr>
<td>PSK (위상 편이 변조)</td>
<td>위상</td>
<td>효율적, Wi-Fi 등에서 사용</td>
</tr>
<tr>
<td>QAM (직교 진폭 변조)</td>
<td>진폭 + 위상 동시</td>
<td>고속 전송 가능, 복잡</td>
</tr>
</tbody></table>
<hr>
<h2 id="25-다중화-multiplexing">2.5 다중화 (Multiplexing)</h2>
<p>하나의 전송 링크를 여러 신호가 공유해서 동시에 전송하는 기술이다.</p>
<p><strong>FDM (주파수 분할 다중화)</strong>
전체 주파수 대역을 여러 개로 쪼개서 각 신호를 동시에 전송한다. 인접 채널 간 간섭을 막기 위해 보호 대역(Guard Band)이 필요하다.</p>
<p><strong>TDM (시분할 다중화)</strong>
시간을 여러 슬롯으로 나눠서 각 장치가 자신의 시간 슬롯에만 데이터를 전송한다. 주로 디지털 통신에서 사용한다.</p>
<p><strong>WDM (파장 분할 다중화)</strong>
광섬유 통신에서 서로 다른 파장의 빛을 사용해서 여러 신호를 동시에 전송한다.</p>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/bc06911b-9186-46d7-afac-ae2adbb7ee1f/image.png" alt=""></p>
<p><em>FDM은 주파수 축을 나누고, TDM은 시간 축을 나눈다 — 둘 다 하나의 링크를 여러 채널이 공유하는 방식</em></p>
<hr>
<h2 id="26-전송-매체">2.6 전송 매체</h2>
<h3 id="유도-매체-유선">유도 매체 (유선)</h3>
<p><strong>꼬임쌍선 (Twisted-Pair Cable)</strong>
두 개의 구리선을 꼬아서 만든 케이블이다. UTP(비차폐)와 STP(차폐) 두 종류가 있고, 우리가 흔히 쓰는 랜선이 바로 UTP 케이블이다.</p>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/7ee4ebe7-693e-4bdd-80f3-69a6f17f9d1b/image.png" alt="꼬임쌍선 케이블 단면"></p>
<p><strong>동축 케이블 (Coaxial Cable)</strong>
중심 도체를 절연체, 외부 도체, 외부 피복으로 감싼 구조다. 꼬임쌍선보다 대역폭이 넓고 잡음에 강하다. 케이블 TV나 케이블 인터넷에 사용한다.</p>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/932f2343-cc52-4992-847c-ffab12c1518f/image.png" alt="동축 케이블 단면"></p>
<p><strong>광섬유 케이블 (Optical Fiber)</strong>
빛 신호로 데이터를 전송하는 매체다.</p>
<ul>
<li>엄청나게 높은 대역폭 (이론상 200 THz)</li>
<li>신호 감쇠가 매우 작아서 장거리 전송 가능</li>
<li>전자기 간섭에 영향을 받지 않음</li>
</ul>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/4a380a8e-056f-4d4f-9026-ea3c7e145894/image.png" alt="광섬유 케이블 단면"></p>
<p><strong>유선 매체 성능 비교</strong></p>
<table>
<thead>
<tr>
<th>매체</th>
<th>대역폭</th>
<th>감쇠</th>
<th>간섭</th>
<th>주요 용도</th>
</tr>
</thead>
<tbody><tr>
<td>꼬임쌍선 (UTP)</td>
<td>낮음</td>
<td>높음 (20~30 dB/km)</td>
<td>취약</td>
<td>LAN, 전화선</td>
</tr>
<tr>
<td>동축 케이블</td>
<td>중간</td>
<td>중간 (5~10 dB/km)</td>
<td>보통</td>
<td>케이블 TV</td>
</tr>
<tr>
<td>광섬유</td>
<td>매우 높음</td>
<td>매우 낮음 (0.2 dB/km)</td>
<td>없음</td>
<td>백본, 해저</td>
</tr>
</tbody></table>
<h3 id="비유도-매체-무선">비유도 매체 (무선)</h3>
<table>
<thead>
<tr>
<th>종류</th>
<th>주파수 범위</th>
<th>특징</th>
<th>용도</th>
</tr>
</thead>
<tbody><tr>
<td>라디오파</td>
<td>3kHz ~ 1GHz</td>
<td>전방향, 장거리 가능</td>
<td>AM/FM 방송</td>
</tr>
<tr>
<td>마이크로파</td>
<td>1GHz ~ 300GHz</td>
<td>지향성, 가시선 필요</td>
<td>이동통신, 위성</td>
</tr>
<tr>
<td>적외선</td>
<td>300GHz ~ 400THz</td>
<td>단거리, 장애물 통과 불가</td>
<td>리모컨, 실내</td>
</tr>
</tbody></table>
<hr>
<h2 id="핵심-요약">핵심 요약</h2>
<ul>
<li>물리층 = 비트를 실제 신호로 바꿔서 전송하는 계층</li>
<li>신호는 아날로그(연속)와 디지털(이산) 두 종류</li>
<li>신호 장애: 감쇠(에너지 손실) / 왜곡(형태 변형) / 잡음(외부 간섭)</li>
<li>전송률 한계: 나이퀴스트(잡음 없음, <code>2Blog₂L</code>) / 섀넌(잡음 있음, <code>Blog₂(1+SNR)</code>)</li>
<li>변환 방식: Digital→Digital(회선부호화) / Analog→Digital(PCM) / Digital→Analog(ASK, FSK, PSK, QAM)</li>
<li>다중화: FDM(주파수) / TDM(시간) / WDM(파장)</li>
<li>전송 매체: 꼬임쌍선 &lt; 동축 케이블 &lt; 광섬유 순으로 성능 향상</li>
</ul>
<hr>
<h2 id="참고문헌">참고문헌</h2>
<blockquote>
<p>Forouzan, B. A. (2013). <em>Data Communications and Networking</em> (6th ed.). McGraw-Hill.
번역: 이재광, 김중규, 이경현, 홍충선. <em>데이터 통신과 네트워킹 TCP/IP 프로토콜 기반</em> (개정 6 수정판). 퍼스트북.</p>
</blockquote>
<p>본 글은 위 교재의 내용을 바탕으로 학습하면서 개인적으로 이해한 내용을 정리한 것입니다.</p>
]]></description>
        </item>
        <item>
            <title><![CDATA[[컴퓨터 네트워크] 1장 - 네트워크 개요]]></title>
            <link>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-1%EC%9E%A5-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EA%B0%9C%EC%9A%94</link>
            <guid>https://velog.io/@opentime_kr/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-1%EC%9E%A5-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EA%B0%9C%EC%9A%94</guid>
            <pubDate>Sun, 12 Apr 2026 01:00:47 GMT</pubDate>
            <description><![CDATA[<p><img src="https://velog.velcdn.com/images/opentime_kr/post/3ba0d9f2-cf73-4412-a4db-da6ef70e491b/image.png" alt=""></p>
<p>데이터 통신과 네트워킹 (Forouzan, 6판)을 공부하면서 챕터별로 핵심 개념을 정리해두려 한다. 이 글은 그 첫 번째로, 네트워크의 기본 개념과 구조를 다룬다.
이론적인 내용이 많아서 처음엔 딱딱하게 느껴질 수 있는데, 나중에 각 계층 세부 내용을 공부할 때 이 개념들이 기반이 되므로 제대로 짚고 넘어가는 게 중요하다.</p>
<hr>
<h2 id="네트워크란">네트워크란?</h2>
<p>네트워크는 데이터 교환을 위해 연결된 컴퓨터, 서버, 라우터, 스위치 등 장치들의 집합이다. 쉽게 말하면 서로 데이터를 주고받을 수 있도록 연결된 시스템이다.</p>
<p>통신의 기본 구성 요소는 크게 네 가지가 있다.</p>
<table>
<thead>
<tr>
<th>구성 요소</th>
<th>설명</th>
<th>예시</th>
</tr>
</thead>
<tbody><tr>
<td>메시지(Message)</td>
<td>전달하려는 데이터</td>
<td>문자, 숫자, 영상, 소리</td>
</tr>
<tr>
<td>송신자(Sender)</td>
<td>데이터를 보내는 장치</td>
<td>컴퓨터, 휴대폰</td>
</tr>
<tr>
<td>수신자(Receiver)</td>
<td>데이터를 받는 장치</td>
<td>컴퓨터, TV</td>
</tr>
<tr>
<td>전송매체(Medium)</td>
<td>데이터가 이동하는 경로</td>
<td>케이블, 광섬유, 무선</td>
</tr>
</tbody></table>
<p>그리고 이 모든 걸 통제하는 규칙이 <strong>프로토콜(Protocol)</strong> 이다. HTTP, TCP/IP, SMTP 같은 것들이 바로 프로토콜이다.</p>
<hr>
<h2 id="데이터는-어떻게-표현될까">데이터는 어떻게 표현될까?</h2>
<p>컴퓨터는 모든 데이터를 <strong>비트(0과 1)</strong> 로 표현한다. 종류별로 어떻게 표현하는지 간단하게 보면 이렇다.</p>
<ul>
<li><strong>문자(Text)</strong>: 비트 패턴으로 표현. ASCII(7bit), 확장 ASCII(8bit), 유니코드(32bit) 같은 코드 체계를 사용한다.</li>
<li><strong>숫자(Number)</strong>: 비트 패턴으로 직접 표현.</li>
<li><strong>이미지(Image)</strong>: 화소(pixel) 단위로 나뉘고, 흑백은 1~2bit, 컬러는 RGB 방식으로 표현한다.</li>
<li><strong>오디오(Audio)</strong>: 연속 신호(아날로그)를 디지털로 변환해서 표현한다.</li>
<li><strong>비디오(Video)</strong>: 여러 이미지를 연속으로 이어붙인 것이다.</li>
</ul>
<hr>
<h2 id="데이터-전송-방향">데이터 전송 방향</h2>
<p>데이터를 주고받는 방식은 크게 세 가지가 있다.</p>
<p><strong>단방향(Simplex)</strong> — 한쪽 방향으로만 전송 가능하다. 키보드나 모니터처럼 한쪽은 보내고, 한쪽은 받기만 한다.</p>
<p><strong>반이중(Half-Duplex)</strong> — 양쪽 모두 송수신이 가능하지만 동시에는 안 된다. 워키토키가 대표적인 예인데, 한 명이 말하는 동안 상대방은 들어야 한다.</p>
<p><strong>전이중(Full-Duplex)</strong> — 양쪽이 동시에 송수신 가능하다. 우리가 쓰는 전화가 이 방식이고, 서로 동시에 말할 수 있다.</p>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/4ac7efa4-ac0a-4811-8e20-66ec686c5ea9/image.png" alt=""></p>
<hr>
<h2 id="네트워크-성능-평가-기준">네트워크 성능 평가 기준</h2>
<p>네트워크를 평가할 때는 크게 세 가지 기준으로 본다.</p>
<p><strong>성능(Performance)</strong></p>
<ul>
<li><strong>Bandwidth(대역폭)</strong>: 초당 전송할 수 있는 최대 데이터 양</li>
<li><strong>Throughput(처리량)</strong>: 실제로 전송된 데이터 양 (대역폭 ≠ 처리량)</li>
<li><strong>Latency(지연시간)</strong>: 출발지에서 목적지까지 걸리는 시간</li>
<li><strong>Jitter(지터)</strong>: 지연시간이 얼마나 들쑥날쑥한지</li>
<li><strong>Packet Loss</strong>: 전송 중 사라진 패킷 비율</li>
</ul>
<p><strong>신뢰성(Reliability)</strong></p>
<ul>
<li>Availability(가용성): 네트워크가 정상 작동하는 시간 비율</li>
<li>MTTR(장애복구시간), MTBF(고장 간 평균 시간)</li>
</ul>
<p><strong>보안(Security)</strong></p>
<ul>
<li>암호화, 접근 제어(방화벽 등)</li>
</ul>
<blockquote>
<p><strong>TMI</strong>: CSAT Forge 개발할 때 OpenAI API 응답 속도가 느려서 답답했던 적이 있는데, 그게 바로 Latency 문제였다. Bandwidth는 충분해도 API 서버 응답 지연이 생기면 사용자 경험이 확 떨어진다.</p>
</blockquote>
<hr>
<h2 id="네트워크-토폴로지-접속-형태">네트워크 토폴로지 (접속 형태)</h2>
<p>네트워크에서 장치들을 어떻게 연결하느냐를 <strong>토폴로지(Topology)</strong> 라고 한다.</p>
<h3 id="그물형-mesh">그물형 (Mesh)</h3>
<p>모든 장치가 서로 직접 연결된 형태다. n개 장치를 연결하려면 <strong>n(n-1)/2개의 채널</strong>이 필요하다.</p>
<ul>
<li><strong>장점</strong>: 안정성 높음, 보안 우수, 결함 분리 쉬움</li>
<li><strong>단점</strong>: 케이블 많이 필요, 설치 복잡</li>
</ul>
<h3 id="성형-star">성형 (Star)</h3>
<p>중앙 허브(Hub)를 통해 모든 장치가 연결되는 구조다. 현재 가장 많이 쓰이는 방식이다.</p>
<ul>
<li><strong>장점</strong>: 설치/재구성 쉬움, 비용 적음</li>
<li><strong>단점</strong>: 허브 고장 시 전체 네트워크 마비</li>
</ul>
<h3 id="버스형-bus">버스형 (Bus)</h3>
<p>하나의 공유 케이블에 모든 장치가 연결되는 구조다.</p>
<ul>
<li><strong>장점</strong>: 케이블 적게 사용, 설치 쉬움</li>
<li><strong>단점</strong>: 중추 케이블 고장 시 전체 영향, 재구성 어려움</li>
</ul>
<h3 id="링형-ring">링형 (Ring)</h3>
<p>각 장치가 양옆 장치하고만 연결돼서 원형으로 이어지는 구조다. 각 장치는 중계기(Repeater)를 포함하고 있다.</p>
<ul>
<li><strong>장점</strong>: 설치/재구성 쉬움</li>
<li><strong>단점</strong>: 단방향 링 결함 시 전체 마비 → 이중 링으로 해결</li>
</ul>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/3f5f4b23-ec4a-4814-8703-a744796c8771/image.png" alt=""></p>
<hr>
<h2 id="네트워크-규모별-분류">네트워크 규모별 분류</h2>
<p><strong>LAN(근거리 통신망)</strong>: 건물, 학교 캠퍼스 같은 단일 공간 안의 네트워크다. 버스형/링형/성형을 주로 쓴다.</p>
<p><strong>WAN(광역 통신망)</strong>: 국가, 대륙 규모의 네트워크다. 거리 제한이 없고, 통신사(KT, SKT 등)가 운영한다.</p>
<ul>
<li>점-대-점 WAN: 전용선 방식</li>
<li>교환형 WAN: 여러 경로를 공유하는 방식</li>
</ul>
<p><strong>Internet</strong>: 수천 개의 네트워크가 상호 연결된 거대한 네트워크다. 백본(Sprint, KT, SKT 등) → 제공자 네트워크(ISP) → 소비자 네트워크 구조로 계층화되어 있다.</p>
<hr>
<h2 id="왜-계층을-나눌까--프로토콜-계층화">왜 계층을 나눌까? — 프로토콜 계층화</h2>
<p>통신이 복잡해질수록 모든 걸 하나의 규칙으로 처리하기가 어렵다. 그래서 역할을 나눠서 각 계층이 자기 임무만 담당하도록 설계한 게 <strong>프로토콜 계층화</strong>다.</p>
<p>편지를 보내는 과정을 생각해보면 쉽다. 편지 쓰기 → 봉투 작성 → 우체통 투함 → 우체국 → 우편집중국 → 배달. 각 단계가 자기 역할만 하고, 다음 단계에 넘기는 구조다. 네트워크도 똑같다.</p>
<p>계층화의 핵심 원칙은 두 가지다.</p>
<ul>
<li>양방향 통신이라면, 각 계층은 상반되는 두 가지 작업을 수행할 수 있어야 한다. (보내기/받기, 암호화/복호화)</li>
<li>같은 계층끼리는 동일한 객체를 다뤄야 한다.</li>
</ul>
<hr>
<h2 id="tcpip-프로토콜-계층-구조">TCP/IP 프로토콜 계층 구조</h2>
<p>현재 인터넷 표준 모델이고, 5개 계층으로 이루어져 있다.</p>
<table>
<thead>
<tr>
<th>계층</th>
<th>이름</th>
<th>역할</th>
<th>단위</th>
</tr>
</thead>
<tbody><tr>
<td>5</td>
<td>응용층(Application)</td>
<td>프로세스 간 통신 (HTTP, DNS, FTP 등)</td>
<td>메시지</td>
</tr>
<tr>
<td>4</td>
<td>전송층(Transport)</td>
<td>종단-대-종단 논리 연결 (TCP, UDP)</td>
<td>세그먼트</td>
</tr>
<tr>
<td>3</td>
<td>네트워크층(Network)</td>
<td>호스트-대-호스트 연결, 경로 선택</td>
<td>패킷/데이터그램</td>
</tr>
<tr>
<td>2</td>
<td>데이터링크층(Data Link)</td>
<td>링크를 통한 프레임 전달</td>
<td>프레임</td>
</tr>
<tr>
<td>1</td>
<td>물리층(Physical)</td>
<td>비트를 물리 신호로 변환, 전송</td>
<td>비트</td>
</tr>
</tbody></table>
<br/>

<h3 id="tcpip-계층별-데이터-단위-흐름">TCP/IP 계층별 데이터 단위 흐름</h3>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/71c78281-bc40-424e-87b0-19404a718928/image.png" alt=""></p>
<hr>
<h2 id="osi-7계층-모델">OSI 7계층 모델</h2>
<p>ISO에서 1970년대 후반에 만든 표준 모델이다. TCP/IP가 5계층인 것과 달리 7계층으로 나뉜다.</p>
<table>
<thead>
<tr>
<th>계층</th>
<th>이름</th>
<th>역할</th>
</tr>
</thead>
<tbody><tr>
<td>7</td>
<td>응용층(Application)</td>
<td>사용자 인터페이스</td>
</tr>
<tr>
<td>6</td>
<td>표현층(Presentation)</td>
<td>암/복호화, 데이터 변환</td>
</tr>
<tr>
<td>5</td>
<td>세션층(Session)</td>
<td>세션 관리</td>
</tr>
<tr>
<td>4</td>
<td>전송층(Transport)</td>
<td>종단 간 신뢰성 있는 전송</td>
</tr>
<tr>
<td>3</td>
<td>네트워크층(Network)</td>
<td>경로 선택, 라우팅</td>
</tr>
<tr>
<td>2</td>
<td>데이터링크층(Data Link)</td>
<td>프레임 전송, 오류 제어</td>
</tr>
<tr>
<td>1</td>
<td>물리층(Physical)</td>
<td>비트 전송</td>
</tr>
</tbody></table>
<blockquote>
<p><strong>TCP/IP vs OSI</strong></p>
</blockquote>
<ul>
<li>실제 인터넷은 TCP/IP 모델을 쓴다.</li>
<li>OSI는 이론적 참조 모델이다.</li>
<li>OSI의 세션층 + 표현층 + 응용층이 TCP/IP의 응용층 하나로 합쳐진 거라고 보면 된다.</li>
</ul>
<hr>
<h2 id="핵심-요약">핵심 요약</h2>
<ul>
<li>네트워크 = 장치들의 연결 집합, 프로토콜 = 통신 규칙</li>
<li>모든 데이터는 결국 비트(0,1)로 표현된다</li>
<li>전송 방향: 단방향 / 반이중 / 전이중</li>
<li>토폴로지: Mesh(안정적) / Star(현재 주류) / Bus(단순) / Ring(순환)</li>
<li>계층화: 복잡한 통신을 역할별로 나눠서 관리하는 것</li>
<li>TCP/IP 5계층이 실제 인터넷 표준, OSI 7계층은 이론 참조 모델</li>
</ul>
<hr>
<h2 id="참고문헌">참고문헌</h2>
<blockquote>
<p>Forouzan, B. A. (2013). <em>Data Communications and Networking</em> (6th ed.). McGraw-Hill.
번역: 이재광, 김중규, 이경현, 홍충선. <em>데이터 통신과 네트워킹 TCP/IP 프로토콜 기반</em> (개정 6 수정판). 퍼스트북.</p>
</blockquote>
<p>본 글은 위 교재의 내용을 바탕으로 학습하면서 개인적으로 이해한 내용을 정리한 것입니다.</p>
]]></description>
        </item>
        <item>
            <title><![CDATA[나는 멈추지 않기로 했다]]></title>
            <link>https://velog.io/@opentime_kr/%EC%A7%80%EA%B8%88%EC%97%90%EC%84%9C%EC%95%BC-%EA%B3%B5%EB%B6%80-%EB%B8%94%EB%A1%9C%EA%B7%B8%EB%A5%BC-%EC%8B%9C%EC%9E%91%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0</link>
            <guid>https://velog.io/@opentime_kr/%EC%A7%80%EA%B8%88%EC%97%90%EC%84%9C%EC%95%BC-%EA%B3%B5%EB%B6%80-%EB%B8%94%EB%A1%9C%EA%B7%B8%EB%A5%BC-%EC%8B%9C%EC%9E%91%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0</guid>
            <pubDate>Sat, 11 Apr 2026 08:09:36 GMT</pubDate>
            <description><![CDATA[<p>나는 딱히 <strong>대단한 꿈이 있어서 컴공에 온 게 아니었다.</strong> 형들이 갔으니까, 자연스럽게 흘러들어왔고, <strong>&#39;코딩만 잘하면 되겠지&#39;</strong> 라는 막연한 생각 하나를 들고 1학년을 시작했다. 그때는 그게 전부였고, 그걸로 충분한 줄 알았다.</p>
<p>그리고 코로나가 심할 시기였다. 강의실 대신 모니터 앞에 앉아서 온라인 수업을 듣는 날들이 이어졌고, 학생회를 하면서 버텨보려 했지만 어느 순간 이런 생각이 머릿속을 떠나지 않았다.</p>
<blockquote>
<p><strong>&quot;이럴려고 학교에 온 건가...&quot;</strong></p>
</blockquote>
<hr>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/f2c14a27-513d-4278-ae74-4400bec0d23f/image.png" alt=""></p>
<hr>
<p>말로 표현하기 애매한 종류의 현타였는데, 조용하고 깊고, 그러면서도 꽤 오래 남는 그런 감정이었다. 결국 <strong>군대를 갔다.</strong></p>
<p>이후 <strong>23년 9월에 복학했다.</strong> 1학년 때부터 같이 다니던 친구가 있었는데, 둘이서 모르는 게 생기면 서로 붙잡고 밤새 파고들었고, 말도 안 되는 소리처럼 들리겠지만 <strong>과탑을 찍겠다는 목표를 세우고 진짜 그걸 향해 달렸다.</strong> 전공 학점 4.1, 나쁘지 않았다.</p>
<p>근데 뭔가 계속 이상한 느낌이 들었다. 주변은 자꾸 술 먹자고 했고, 공부하는 분위기는 점점 옅어졌으며, 교수님들도 학생들한테 별로 관심이 없는 것 같다는 느낌이 자꾸 들었다. 그리고 <strong>결정적인 순간이 찾아왔다.</strong> 자바 수업 실습 시간이었는데, 나는 문제를 다 풀고 검사를 기다리고 있었다. 그때 옆 친구가 교수님한테 질문을 했고, 교수님이 같이 들여다보더니 그 문제를 못 푸셨다. <strong><em>자기가 낸 문제를!!!!!!</em></strong> 그러고는 나한테 돌아서서 물어봤다.</p>
<blockquote>
<p><strong>&quot;학생, 어떻게 풀었어요?&quot;</strong></p>
</blockquote>
<p>그 순간 뭔가 무너지는 것 같았고, 동시에 이상하게도 <strong>지금까지 여기서 열심히 한 게 허탈하게 느껴지는 기분이 들었다.</strong> 가톨릭 재단이라 종교 수업도 강요처럼 느껴졌고, 교양 학점은 그 영향으로 확 떨어졌다. 77학점을 들어서 전체 평점은 3.85로 마무리됐다. 2학년 2학기가 끝났고, <strong>이제 뭘 해야 하나</strong> 싶었다.</p>
<hr>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/a4368f05-fa23-4dc9-a163-4e51fe40f69e/image.png" alt=""></p>
<hr>
<p>그때 <strong>편입이라는 걸 알게 됐다.</strong> 동시에 근처에 국비 부트캠프가 있다는 것도 알았는데, 코리아IT아카데미에서 진행하는 공공데이터 기반 풀스택 개발 양성과정이었고, 6개월짜리였다. <strong>일단 해보자는 마음으로 신청했다.</strong></p>
<p><strong>오전 9시부터 저녁 6시까지 부트캠프를 하고, 6시부터 밤 10시까지는 편입 영어 학원을 다니는 게 그때 하루의 전부였다.</strong> 처음에 JSP 서블릿을 배울 때는 뭔가 불편하다는 느낌이 들었는데, MyBatis를 배우면서 <em>오,</em> 하는 순간이 왔고, <strong>Spring Boot에 JPA, React까지 넘어오니까 이상하게 재밌어졌다.</strong> JFrame 할 때랑은 분명히 다른 느낌이었고, <em>아 나는 웹이 맞나 보다</em> 싶었다.</p>
<p>그렇게 <strong>부트캠프 900시간을 마쳤다.</strong> 9월이었다. 그제야 편입 수학을 시작했는데, 지금도 그게 제일 후회된다. 더 일찍 했어야 했는데. 편입 시험을 쳤고, 결과가 나왔다. <strong>많이 우울했다.</strong> 근데 한 학교에서 연락이 왔다. <strong>정보보호학과, 합격이었다.</strong></p>
<hr>
<p><img src="https://velog.velcdn.com/images/opentime_kr/post/c03710c5-dac1-467e-8d9b-a64cd9603313/image.png" alt=""></p>
<hr>
<p>처음 학교에 와서 교수님들을 만났을 때 <strong>느낌이 달랐다.</strong> 학생을 진짜로 생각하는 느낌이 났고, 편입생인 나한테도 공모전 기회를 열어주셨다. 덕분에 공모전도 나가게 됐고, 같이 팀플 하는 친구들도 열심히 하는 애들이라서 다행이다 싶었다. <strong>지금은 그렇게 3학년을 살고 있다.</strong></p>
<p>이 블로그를 시작하는 이유는 단순하다. 편입으로 왔으니 남들보다 쌓아온 시간이 짧고, <strong>그 부족한 부분을 채워가는 과정을 기록하고 싶었다.</strong> 공부한 것들, 만들고 있는 것들, 매달 어떻게 살았는지. 누군가에게 보여주려는 목적보다는, 나중에 내가 돌아봤을 때 <em>그때 이랬구나</em> 할 수 있는 흔적을 남기고 싶다.</p>
<p><strong>나도 꼭 성공한 사람이 되기까지 끝까지 노력할 것이다. 나는 멈추지 않을 것이다.</strong></p>
]]></description>
        </item>
    </channel>
</rss>