기록을 남기자

PR Agent 아키텍처, 명령어별 세부 동작 흐름, 환경 세팅

ssun_bear — Sun, 4 May 2025 15:21:03 +0900

PR Agent는 GitHub, GitLab, Bitbucket과 같은 플랫폼에서 Pull Request(이하 PR)의 생성부터 병합까지 과정을 자동화하고, 코드 리뷰 품질과 일관성을 높여주는 오픈소스 AI 도구입니다.

이 글에서는 PR Agent의 전체 아키텍처 구조, 명령어별 세부 동작 흐름(예: /pr_add_docs, /pr_analyze 등), 그리고 로컬 또는 서버 환경에서의 세팅 방법까지 단계별로 정리합니다.

PR Agent를 활용해 자동화된 코드 리뷰 파이프라인을 구축하거나, 팀 내 리뷰 효율을 높이고 싶은 개발자라면 이 글을 통해 핵심 개념부터 실전 적용까지 한눈에 확인할 수 있습니다.

PR Agent 아키텍처 및 주요 기능

PR Agent의 아키텍처는 다음과 같은 구성으로 이뤄져 있습니다.
> 1. Digest Request → 2. Planning → 3. Execution (function)

1. 전체 구성요소 설명

1.1 Digest Request

PR 상태 탐지: 오픈 PR인지, 업데이트된 PR인지 등 유형 파악
Hunk 탐지& 우선순위화: 변경된 파일의 패치 단위(hunk) 인식, 코드 추가(addition)위주로 우선순위 설정
PR Compression: 긴 diff를 토큰 예산에 맞춰 최적화 — 삭제-only hunk 제거, 추가 위주 병합, tiktoken 기반 토큰 카운팅 및 적응적 분할 기법 적용 (공식 문서 참조)

1.2 Planning

토큰 인식 압축 & 우선순위화: 모델 최대 입력 길이를 고려해 핵심 정보만 선별, 덜 중요한 내용은 생략 혹은 후순위로 조정
사용자 요청 분석: PR 코멘트로 받은 명령어(/review, /ask 등)를 LLM에 전달하기 전 사전처리(reflect)수행
Questioning 단계: 필요 시 추가 정보(예: 어떤 파일에 대해 질문할지)를 사용자에게 재질문하여 맥락 보완

PR Agent의 토큰 인식 압축 및 우선순위화 과정 도식화

1.3 Tool Execution

모듈별 기능 (참고 링크)
- /review : 자동 코드 리뷰 (버그, 보안 취약점, 스타일 위반)
- /describe : PR 제목·요약·코드 워크스루·라벨 자동 생성
- /ask : PR 전반에 대한 Q&A
- /improve : 코드 개선 제안
- /add_docs : 변경된 메서드·클래스 문서 자동 생성
- /update_changelog : CHANGELOG.md 업데이트
- /generate_labels : 커스텀 라벨링
- /analyze : PR 구성 요소별 테스트·문서·코드 제안 보조
- /find_similar_component : 내부 코드베이스 유사 컴포넌트 검색
- 그외 상세한 명령어는 아래의 공식 문서 링크에서 자세히 확인할 수 있습니다.

pr-agent/docs/docs/tools/ask.md at main · qodo-ai/pr-agent

PR-Agent (Qodo Merge open-source): An AI-Powered Tool for Automated Pull Request Analysis, Feedback, Suggestions and More! - qodo-ai/pr-agent

github.com

단일 LLM 호출: 각 기능은 JSON 프롬프트 1회 호출로 설계되어 응답 시간을 단축하고 API 호출 횟수 최소화
멀티 프로바이더 지원: GitHub, GitLab, Bitbucket, Azure DevOps 등 다양한 플랫폼에서 동일 동작 보장
RAG Context Implement: 구성된 저장소에서 상황에 맞는 코드 세그먼트를 검색하여 풀 리퀘스트(PR) 통찰력을 풍부하게 하고 검토 정확도를 높임, Enterprise Plan에서 사용가능 (공식 문서)

모듈별 자세한 기능

1. Review

PR Agent : /review 명령어

review : PR을 철저하고 포괄적으로 검토할 수 있는 기능

개요 : 코드의 전반적인 품질에 대한 귀중한 피드백을 제공하고 개선 방안을 제시하여 전체 코드베이스를 개선하고 더 높은 품질의 코드에 기여
기능 : PR Analysis와 PR Feedback으로 이뤄져있다.

	PR Analysis	PR Feedback
기능	- PR의 유형, 요약, 종류 분석 - 관련테스트의 존재여부 - PR 검토에 필요한 예상 노력 (1~5점) - 보안 문제 파악	- PR에 대한 제안 및 상세 피드백 → General suggestions : 전체 PR의 평가 → Code Feedback : 유관 파일 및 문제점 → 제안 → 예시

목적 : PR을 빠르게 초기 검토하여 가장 중요한 측면에 집중하고 주요 PR 문제를 신속하게 해결

review의 PR Analysis

review의 PR Feedback

2. Describe

PR Agent의 describe 명령어

describe : 풀 리퀘스트(PR) 설명 방식을 크게 개선할 수 있는 강력한 도구

개요: 원본 설명이 명확하지 않거나 세부 사항이 부족한 경우, 이 명령을 사용하면 PR에 대한 포괄적이고 표준화된 설명 제공
기능: PR 제목이 자동으로 생성되고, PR 유형(예: 버그 수정, 기능 추가, 문서 업데이트)을 정확하게 식별하며, 변경 사항에 대한 간결하면서도 유익한 설명 작성
목적: 관련 파일 목록을 레이블별로 정리하여 제공하여 검토자가 변경 사항을 쉽게 탐색하고 범위를 파악

3. Ask

PR Agent의 Ask 명령어

ask "질문": PR 관련 구체적인 질문을 할 수 있고, 댓글로 정확한 답변을 제공

기능 : PR 테스트 중 버그나 오류가 발생할 때무엇이 잘못되었는지 알아내려고 몇 시간을 허비할 필요 없이, 직접 문제에 대해 문의하면 문제 해결 방법에 대한 적절한 제안을 제공
목적 : 프로젝트의 특정 측면에 대한 명확한 설명이나 통찰력을 얻고 싶을 때 질문
질문 : 새로운 MultiLayerPerceptron에서 학습 데이터에 필요한 입력 크기를 확인
답변 : X → (n_samples, n_features), y → (n_samples) 형태뿐 아니라
- train 메서드 내부에서 (n_features, n_samples)로 전치(transpose) 후 처리된다는 점까지 짚음
- 데이터의 transpose는 사실은 코드 흐름을 깊이 분석하지 않으면 놓치기 쉬운 디테일
평가
- 1. 정밀 답변 제공: 간단한 shape 확인을 넘어 내부 로직(전치 처리)까지 분석
- 2. 코드 리뷰 강화: 사람이 미처 체크하지 못하는 숨은 가정(hidden assumption)까지 짚어줌

PR Agent의 ask기능을 통해 생성한 질문에 대한 답변 예시

4. Improve

PR Agent의 Improve 명령어

improve : PR 내의 코드를 분석하고 코드의 품질과 가독성을 향상시키기 위한 유용한 제안을 제공

개요 : 코드 성능 향상을 위한 권장 사항을 제공할 뿐만 아니라, 이 명령을 사용하면 제안된 변경 사항을 PR 환경 내에서 직접 쉽게 커밋 가능
기능 : Commit Suggestion의 간소화된 프로세스를 통해 코드 베이스를 수동으로 풀하고 로컬에서 수정한 후 변경 사항을 다시 푸시할 필요가 없음
목적 : 상당한 시간과 노력을 절약하는 동시에 코드가 최고 수준의 품질과 효율성을 충족하도록 보장

5. Add docs

PR Agent의 add_docs 명령어를 통해 생성한 문서 예시

add_docs : PR 코드를 검토하여 함수와 클래스 설명에 대한 유용한 docstring을 생성

기능 : 실행하기만 하면 자동으로 PR 코드를 검토하여 함수와 클래스 설명에 대한 유용한 문서를 생성
목적 : 코드에 너무 많은 시간을 들이지 않고도 고품질 문서를 작성

명령어별 세부 동작 흐름

명령어	입력 예시	내부 처리	결과 출력
/review	@CodiumAI-Agent /review	PR Compression → /review JSON 프롬프트 생성→ LLM 호출	PR 코멘트(리뷰)
/describe	@CodiumAI-Agent /describe	Diff 요약 → PR 설명용 텍스트 패키징 → LLM 호출	PR 설명(코멘트)
/ask	@CodiumAI-Agent /ask “질문”	사용자 질문 파싱 → 관련 hunk 컨텍스트 매핑 → LLM 호출	PR 코멘트(Q&A)
/improve	@CodiumAI-Agent /improve	코드 스니펫 분석 → 개선 제안 프롬프트 → LLM 호출	인라인 제안
/update_changelog	@CodiumAI-Agent /update_changelog	변경 내역 분석 → changelog 템플릿 적용 → LLM 호출	CHANGELOG 업데이트
/add_docs	@CodiumAI-Agent /add_docs	변경된 코드 식별 → docstring 프롬프트 생성→ LLM 호출	인라인 문서 제안
/generate_labels	@CodiumAI-Agent /generate_labels	PR 메타분석 → 라벨링 가이드라인 적용→ LLM 호출	PR 라벨

참고
: 각 명령어는 단일 기능 단위로 모듈화되어 있으며, pr_agent.toml을 통해 세부 동작을 커스터마이징할 수 있습니다.

환경 세팅

# git clone 및 이동
git clone https://github.com/Codium-ai/pr-agent.git
cd pr-agent

# 가상환경 설치 및 실행
python3 -m venv venv # venv 가상 환경 폴더 생성
source venv/bin/activate # Linux 가상 환경 활성화

# 모듈 설치
pip install -e .

# .secrets.toml 파일 생성 (템플릿 파일 pr_agent/settings/.secrets_template.toml 활용)
cp pr_agent/settings/.secrets_template.toml pr_agent/settings/.secrets.toml
chmod 600 pr_agent/settings/.secrets.toml # 읽기, 쓰기 권한 부여

# pr_agent/settings/.secrets.toml에서 API Key 편집
gemini_api_key = <api-key> # 사용할 AI 모델의 API Key ex.Gemini
user_token = <github-user-token> # GitHub 사용자 토큰

# pr_agent/settings/configuration.toml에서 AI 모델 편집
# 가능한 모델명은 pr_agent/algo/__init__.py에서 확인 가능 (default는 gpt-4)

[config]
# models
model=<ai-model>
fallback_models=[<ai-model>]

# <pr_url> : pull request를 요청한 링크
# <command> : review, improve 등의 PR Agent 명령어 - 예시 describe
python3 -m pr_agent.cli --pr_url <pr_url> <command>

아래의 공식문서를 참고하여 세팅하는 것도 좋다!

Configuration File - Qodo Merge (and open-source PR-Agent)

None

qodo-merge-docs.qodo.ai

PR Agent를 세팅하여 PR Suggestion을 받을 수 있었다!

Gemini-1.5-flash를 사용한 이유는 무료였기에,,

대형 언어 모델(LLM)과 ChatGPT의 작동 원리

ssun_bear — Sun, 27 Apr 2025 12:57:18 +0900

해당 영상을 보고 정리한 내용입니다.

LLM의 정의와 ChatGPT의 역할

LLM은 인터넷상의 방대한 텍스트 데이터를 학습하여 인간 언어의 패턴을 익힌 거대 신경망 모델이다.
LLM은 주어진 이전 단어들의 문맥을 바탕으로 다음에 올 단어를 예측하도록 훈련되며, 이렇게 학습된 모델은 번역, 요약, 질의응답 등 다양한 언어 업무를 수행할 수 있다.
ChatGPT는 이러한 LLM 기술을 기반으로 만들어진 대화형 인공지능으로, OpenAI의 GPT 계열 모델에 사용자의 지시에 따라 응답하도록 추가 훈련(미세조정)된 사례이다.
간단히 말해 ChatGPT는 LLM에 대화 및 명령 수행 능력을 덧붙인 것으로 볼 수 있다. 이를 통해 ChatGPT는 단순한 언어 예측을 넘어, 사용자와 대화하고 유용한 정보를 제공하는 AI 어시스턴트의 역할을 수행한다.

Base Model vs. Instruction Tuning

LLM 개발에서는 base model과 instruction-tuned model(지시/명령 조정된 모델)을 구분한다.

Base model은 방대한 텍스트 코퍼스로 사전 학습된 순수 언어 모델로서, 어떤 입력에 대해 다음 토큰을 예측하는 것만을 학습한다. 특별한 지시 없이 그저 통계적으로 그럴듯한 문장을 만들어낼 뿐이다.
Instruction tuned model은 인간이 주는 지시나 질문에 유용하게 답하도록 추가 훈련된 LLM이다. 예를 들어 ChatGPT의 경우 대화 형식의 지도학습과 사용자 피드백에 기반한 강화학습을 거쳐 사용자의 의도를 따라 응답하는 법을 배우게 된다.

즉, base model이 언어의 일반적 패턴을 학습한 상태라면, instruction-tuned model은 그 위에 “사용자 지시에 따른 답변 능력”을 갖추도록 미세하게 튜닝된 모델이라고 할 수 있다.

LLM 사전 훈련 (Pretraining) 과정

LLM의 성능은 사전 훈련 단계에서 어떻게 방대한 지식을 습득하였는지에 달려 있다. 이 단계에서는 인터넷상의 텍스트로부터 데이터를 모으고, 신경망이 언어 패턴을 학습하도록 거대한 base model을 만들어낸다.

사전 훈련 과정의 주요 요소는 다음과 같다

데이터 수집 : Common Crawl과 같은 프로젝트를 통해 전 세계 웹페이지를 크롤링하여 방대한 말뭉치 수집
- 정제 단계 : 유해/스팸/저품질 콘텐츠 필터링, HTML, 스크립트 제거 및 본문 추출, 언어 분류 후 주요 언어(예: 영어) 중심 필터링, 개인정보(PII) 제거 등
- 정제단계를 거쳐 고품질의 텍스트 데이터셋 확보 → LLM 사전학습 데이터로 사용
토큰화 : 텍스트를 BPE(Byte Pair Encoding) 방식 등으로 분할
- 텍스트 데이터를 신경망에 넣을수는 없기에 토큰화 기법 (글자를 토큰 단위의 숫자 시퀀스로 변환) 사용
- 목표 : 텍스트를 일정한 크기의 vocabulary 목록으로 분할
  - 목록이 너무 작으면 매우 많은 토큰으로 쪼개고, 너무 크면 드물게 쓰이는 거대한 사전 관리가 비효율
  - 약 10만개 내외의 어휘 집합이 토큰화 효율과 모델 효율의 균형을 맞추는 적정선으로 알려짐
- Byte Pair Encoding : 모든 문자를 UTF-8 바이트 시퀀스로 변형 후, 빈번한 바이트 조합을 하나의 단위로 묶는 토큰화 방법 (링크 참조 : 자세한 설명)
  - 철자 단위의 단어 목록을 만든다
  - 가장 빈도수가 높은 단어 Pair를 Token으로 추가한다 → 유의미한 단어로 추정
- 토큰화 결과 예시 : 문장 - ChatGPT is amazing → 정수 ID 시퀀스 [Chat, GPT, is, ama, ##zing]
Transformer 구조 기반 학습 : Self-attention으로 문맥내 단어간 관계 학습 → 전체 문장을 한번에 처리해 멀리떨어진 단어 간의 의존성(장기의존성)까지 포착하여 일관된 문맥 이해 가능
학습 목표 : Cross-Entropy Loss 기반으로 모델의 오차를 최소화하여 모델 최적화 → 주어진 문맥 다음 등장할 토큰 예측
- 모델의 오차 : 모델의 출력 확률 분포와 정답 토큰(훈련 데이터에서 다음에 나온 실제 단어) 사이의 차이
- 모델은 오차를 줄이는 방향으로 파라미터를 조정하며, 이러한 최적화 과정을 역전파 알고리즘으로 수행

LLM의 추론 단계 (Inference)

사전 학습을 마친 LLM은 이제 새로운 입력에 대해 언어 생성을 할 수 있다. 이 사용 단계(inference)에서, 모델은 사용자의 입력(prompt)을 토큰화된 형태로 받아들인 뒤, 그에 이어질 적절한 출력 텍스트를 한 토큰씩 생성한다.

추론 과정은 다음과 같이 이루어진다

시작 토큰 추가: 모델은 일반적으로 문장의 시작을 알리는 <BOS> (Beginning Of Sequence)와 같은 특수 시작 토큰을 먼저 입력받아 생성을 개시한다.
토큰별 다음 단어 예측: 현재까지 생성된 모든 토큰(초기에는 사용자의 입력 토큰들 plus 시작 토큰)을 고려하여 다음에 올 토큰의 확률 분포를 계산한다. 트랜스포머 모델은 지금까지의 문맥을 바탕으로 각 어휘 항목에 대한 출현 확률을 출력하며, 이 확률분포에서 가장 그럴듯한 후보를 선택하거나 무작위 샘플링한다.
1. Greedy Decoding : 확률이 높은 단어를 선택
2. 확률적 샘플링 : Temperature 조절 및 Top-K 샘플링의 방식으로 창의성이 높은 다양한 답변 생성가능
토큰 추가 및 반복: 선택된 단어를 출력 문장에 추가한 뒤, 그 문장을 다시 모델의 입력 컨텍스트에 포함시켜 다음 토큰을 예측한다. 이렇게 생성-예측 과정을 반복하면서 모델은 토큰을 하나씩 이어붙여 문장을 만들어간다.
종료 조건: 모델이 특별한 종료 토큰 <EOS>(End Of Sequence)를 출력하거나, 사전에 정해둔 최대 생성 길이에 도달하면 문장 생성을 멈춘다. 완성된 출력 문장은 사용자가 읽을 수 있는 형태로 디코딩되어 제공된다.

이러한 추론 메커니즘은 확률적 예측에 기반하고 있으므로, 동일한 입력도 매번 조금씩 다른 출력을 낼 수 있다.

특히 확률적 샘플링을 도입하면 창의적인 답변을 얻는 대신 출력의 일관성이 떨어질 수 있고, 반대로 항상 최고 확률 토큰만 고르면 문장이 반복되거나 상투적인 응답이 생길 수 있다.
따라서 실제 ChatGPT와 같은 서비스는 샘플링 기법 조정이나 반복 억제 알고리즘 등을 활용하여 응답의 품질과 다양성 사이 균형을 맞추고 있다.

대화형 어시스턴트로의 후속 학습 (Post-training)

기본 사전 학습만 거친 LLM은 언어 생성 능력은 뛰어나지만, 곧바로 사람과 상호작용하는 어시스턴트 역할을 하기에는 부족하다. 예컨대, 질문을 하면 엉뚱한 방향으로 중언부언하거나, 사용자의 의도를 제대로 반영하지 못할 수 있다. 따라서 ChatGPT와 같은 모델을 만들려면 사전 학습된 기반 모델을 사람에게 유용한 형태로 추가 훈련하는 후속 학습 단계가 필요하다.

이 단계에서 모델은 대화 능력과 지시 이행 능력을 얻게 되며, 주요 절차는 다음과 같다

대화 데이터셋 구축 및 지도 학습
- 먼저 사람의 질문-답변 쌍, 명령-응답 쌍 등으로 이루어진 고품질 대화형 데이터셋을 준비한다. 이 데이터는 사용자의 입력에 대해 모범적인 답변(예: 인간 전문가가 작성한 정답이나 바람직한 응답)을 포함하며, 모델이 어떻게 대화하고 문제를 풀어야 하는지 직접 학습할 수 있는 교본 역할을 한다.
- 이렇게 구축된 데이터셋을 활용하여 지도 학습(Supervised Fine-Tuning, SFT)을 진행하는데, 이는 기존의 기반 모델이 해당 질문들에 대해 정답과 유사한 출력을 내도록 파인튜닝하는 과정이다.
- 예를 들어 “사용자: … 질문” -> “모델: … 답변” 형식의 대화 예시들을 모델에 보여주고, 모델이 답변을 생성하면 정답과의 오차를 계산하여 모델 파라미터를 조정한다.
- 이처럼 인스트럭션 튜닝(instruction tuning)을 거친 모델은 이전보다 사용자 명령을 따르는 성향이 크게 향상된다. 이 단계만으로도 모델은 질문에 보다 직접적으로 답하고, 대화의 형식을 갖추는 등 어시스턴트로서의 기본기를 갖추게 된다.

인간 피드백을 활용한 강화 학습(RLHF)
- 인간과 상호작용하는 AI의 특성상, 단순 지도학습만으로는 해결하기 어려운 영역들이 남아 있다. 특히 정답이 정해져있지 않은 주관적인 요청들에 대응하는 품질을 높이기 위해 도입된 방법이 인간 피드백을 통한 강화학습(Reinforcement Learning from Human Feedback)이다.
- 이 절차에서는 실제 사람 평가자가 모델이 만들어낸 여러 답변을 비교하여 어느 쪽이 더 나은지 표시하는 방식으로 데이터를 생성한다 . 예를 들어 모델에게 동일한 질문에 대해 약간씩 다른 답변을 여러 개 생성하게 한 뒤, 사람이 가장 만족스러운 답변순으로 순위를 매긴다.
- 그 결과를 활용하여 보상 모델(Reward Model)이라는 별도의 신경망을 훈련하는데, 이 보상 모델은 어떤 답변이 사람 선호도가 높을지를 예측하도록 학습된다. 마지막으로, 이 보상 모델이 높은 점수를 주는 방향으로 LLM의 출력을 향상시키도록 강화 학습 알고리즘(예: Proximal Policy Optimization 등)을 적용하여 LLM 자체를 다시 훈련시킨다.

[부스트캠프 AI Tech] 문장 간 유사도(STS) 측정 프로젝트 회고

ssun_bear — Thu, 12 Dec 2024 02:35:57 +0900

너무나도 늦은 회고록이지만 뒤늦게라도 Boostcamp STS 프로젝트를 회고하려 합니다.

최종 성적

- Public 2위 : 0.9378

- Private 3위 : 0.9417

프로젝트 시작 전

인생에서의 첫 캐글형식의 순위형 프로젝트였다.
리더보드형 프로젝트를 함에 앞서 의욕도 많이 앞섰고, 잘 하고 싶은 마음이 가득했었다.

높은 순위를 프로젝트하면서 한번은 가지고 싶었고 추후 팀을 자유롭게 꾸릴때 높은 성적은 도움이 될 것이라고 생각했다.

프로젝트 진행

3주간 진행된 프로젝트에서 추석이라는 기간이 포함되어있었고 실질적으로는 약 2주 정도의 기간동안 프로젝트를 집중할 수 있었다.

이 글을 찾아서 들어오시는 분들은 부스트캠프 사람들로 예상이 되기에 프로젝트의 소개는 넘어가도록 하겠습니다.

위 그림은 프로젝트의 타임라인이다.
약 두달이 지나서야 쓰는 회고지만 지금 보면 다음과 같은 타임라인은 정말 잘못 되었다고 생각한다.

EDA 와 앙상블을 동시에 진행하다니,,,

우리팀이 범했던 실수에 대해서 먼저 말하고자 한다.

1. EDA의 중요성 간과

Boostcamp에서 프로젝트를 마칠 때 마다 2팀 정도 발표를 자원하거나
지원자가 없다면 Private 높은 순위의 팀이 발표를 맡아서 하게 된다.

이번 프로젝트에서는 Public에서 3등 팀이 Private에서 1위를 하게 된 것을 보고 저팀의 노하우가 궁금했다.

1위의 비결은 바로 EDA였다. 우리팀의 패착은 모델의 성능에만 집중을 했었다.

그 어떤 팀보다 모델 탐색과 실험은 잘했다라고 생각하고 그것이 높은 순위를 얻게된 비결이라고 생각했다.

그렇지만 1등팀은 데이터셋의 모든 문장들을 일일히 수동으로 Quality check를 했다고 발표에서 전달해줬다.

(여기서 우리팀이 졌다고 생각했다)

EDA라는 것을 처음해본 우리팀은 사실 라벨의 분포정도 확인을 해보았고, 분포를 맞춰주자.. 라는 결론을 내고

Undersampling, Oversampling, Swap등의 방식을 적용해보고 해당 증강데이터셋을 학습데이터셋으로 사용해본 결과
모델별로 성능이 아주 소폭 상승하거나 대부분 하락했었다.
그렇지만 데이터 셋 내에서 오라벨 등, 노이즈가 껴있을 것이라는 상상을 하진 않았다.

왜 성능이 오르지 않지라는 분석을 하지 않았다. 그렇기에 데이터 셋을 뜯어볼 생각조차 없었다.

그 이후에 어느정도 앙상블의 성능향상이 더뎌지자 KoEDA나 다른 방식의 증강을 뒤늦게 생각한 것이 정말 아쉽다.

STS와 같은 단순 태스크들에서는 EDA에 조금 더 시간을 투자할 수 있었을 텐데와 같은 생각을 지금에서야 한다.

2. 무모한 모델 탐색

아까 위에서도 말했듯, 거의 모델 탐색과 동시에 앙상블을 진행했다.

아무래도 첫 프로젝트고, 관련 지식이 없던 나는 어떤 것이 좋은 모델이지 라는 인사이트가 전혀없었다.

사실 그렇기에 모델을 무작위로 시간을 투자해서 많이 실험을 했고, 리더보드에 제출하는 형식으로 성능을 평가했었다.

모델에 대한 이해없이, 높은 순위만을 찾기 위해서 모델 선정의 기준도 없이 실험한 것은 반성해야 한다고 생각한다.

벤치마크라는 것을 뒤늦게 알았고 이 이후 앞으로의 순위형 프로젝트에서 벤치마크를 기준으로 높은 성능의 모델을 먼저 실험해봐야 하겠다는 간단한 생각을 갖게 되었다.

(지금 두세달 전의 나는 무모했다. 거의 30개가 넘는 모델들을 주구장창 돌려봤다)

무모한 도전 (Hoxy 이거 아시나요)

3. 무지성 앙상블

1등 방법론에 대해 들으면서 앙상블을 마지막날 하루 정도만 투자하였고,
그외에는 계속 단일모델로 성능을 높이는 실험을 했다고 전달 받았다.

우리팀, 아니 거의 내가 모델실험을 주로했었는데 높은 성능의 모델들을 계속 무지성으로 앙상블을 진행했다.
앙상블에 사용된 모델의 개수가 16개인가 (다 많아서 읊지도 못한다)

LV 2에서 Data-Centric 프로젝트를 하는데 해당 프로젝트는 모델의 변경없이 데이터 셋만 변경시켜서 성능을 높이는 프로젝트다.

우리팀은 LV 1때 데이터셋을 하나도 건드리지 않고 모델링 + 앙상블로만 성능을 높이는 프로젝트를 했던 것 같다.

EDA에 대한 고찰이 필요하다. 정말 우리팀에게 필요하다고 생각했다.

추가적으로 단순히 순위를 높이는 프로젝트를 하는 것 보다 어떤 논리적인 흐름으로 실험을 진행했는지,

그 실험에서 얻을 수 있는 것과 그 결과를 분석하고 정리하는 것이 앞으로의 프로젝트에서 도움이 되리라 생각했다.

앙상블로 좋은 결과를 냈지만, 다른 팀들이 프라이빗에서 대부분 Private 점수가 많이 오르는데 우리팀만 소폭 상승했고,
그 원인을 중첩 앙상블의 과적합이 일어났다고 생각한다.

아쉬웠던 점도 말했으면 잘했던 점도 정리하고자 한다.

1. 허깅페이스 사용 익히기

컴공 전공이라고 말하기 아쉬울 정도로 사실 인공지능을 알지 못했고, 웹개발은 더군다나 더 모른다.

생각보다 컴공 출신의 사람들을 만나면 어느정도 인공지능에 대한 공부도 하고오고, Transformer가 뭔지 대략적으로 알고 오는 것 같다.

다만 나는 그런 것들을 전혀 몰랐고, LV 1에서의 강의들이 솔직히 지금도 어렵고, 이해가 다 되는 것은 아니다.

그런 점에서 Hugging Face에 대해 익히는 시간을 많이 가졌고,
단순히 모델을 바꿔가며 실험을 했지만 Hugging Face에는 많이 익숙해졌다.
추가적으로 다양한 기능들을 탐구하게 된 시간이라고 생각한다.

2. 베이스라인 이해하기

파이썬에 대해서는 잘 알았지만 개념이 부족해서인가 파이토치와 관련한 코드는 이해가 잘 되지 않았다.

이를 어떻게 극복했냐 하면은 그냥 뚫어지게 쳐다봤다.

사실 프로젝트에 쏟는 시간이 정말 많았다고 생각한다.
코드를 단순히 돌리는 게 아니라 이코드가 왜 나왔지라는 주석을 달아보며 이해하려 했다.
이런 시간들이 정말 추후 LV 2에서도 도움이 많이 됐다고 생각한다.

3. 깃 사용법 익히기, 협업 툴 적응하기

노션 사용도 익숙하지 않고, 깃 사용도 거의 처음이라 Git Flow에 대한 이해가 부족했는데 사용하면서 Git에 대한 기초를 다졌다.

추후 부스트캠프에서 개발자스럽게 GitHub 사용하기 강의가 있어서 그 때 많은 공부를 했었다.

깃허브와 랩업리포트를 확인 할수 있게 GitHub 링크를 남겨두겠습니다.

GitHub - boostcampaitech7/level1-semantictextsimilarity-nlp-15: level1-semantictextsimilarity-nlp-15 created by GitHub Classroom

level1-semantictextsimilarity-nlp-15 created by GitHub Classroom - boostcampaitech7/level1-semantictextsimilarity-nlp-15

github.com

7기 이후 다음 기수분들이 저의 글들을 본다면, 당장 순위에 연연해하지 않고 팀의 실험을 이어나간다면 좋을 것 같습니다~

+ 전 기수의 실험들을 너무 쫓지말기!

네이버 부스트캠프 AI Tech 7기 합격 후기

ssun_bear — Fri, 20 Sep 2024 14:56:09 +0900

아주 살짝 늦었지만,

네이버 부스트캠프 AI Tech 7기 합격 후기를 남기려고 합니다.

네이버 부스트캠프는 워낙 유명한 부트캠프 중 하나라 전공생이라면 한번 쯤 들어보고싶은 교육 중 하나이다.

작년에 웹모바일을 지원했는데 코테가 어렵기도했고 2차 코테에서 떨어진 기억이 있었다.

찾아보니 이런 메일을 발견

워낙 경쟁률이 빡세다는 것도 알고 있고, 떨어져도 더 열심히 공부해서 붙으면 된다는 생각으로 지원했다.
(1년전 23년에는 알고리즘 더 꾸준히 공부해야지 이런 마음이 있었지만, 이 이후로는 사실 알고리즘을 꾸준히 하지는 못했다)

이번 기수에도 웹모바일을 쓸까 고민을 했는데, 졸업프로젝트를 인공지능 CV파트를 하기도 했어서 인공지능 쪽이 재밌어보이기도하고,

흥미가 생겨서 AI Tech를 지원했다.

사실 가산점을 주는 네이버 부스트캠프 AI Tech 부스트 클래스를 신청하고 하나도 듣지를 못했다.

부스트클래스 : 부스트코스

더 높이 오르기 위한 성장 사다리 부스트클래스 부스트클래스 부스트클래스는 개인 맞춤형 교육으로 직무 스킬을 업그레이드하고 싶은 분들을 위한 온라인 단기 학습 프로그램입니다. 도움닫

www.boostcourse.org

다음 기수에서 희망하시는 분들은 부스트 클래스에서 신청하시고 수료하신 후 부스트캠프를 지원하시면 가산점을 준다고 합니다.
가산점때문은 아니라 사실 캡스톤디자인에서 인공지능 파트를 처음 맡게되서 기초가 너무 부족한거 같아서 들으려고 했지만,
워낙 캡스톤 디자인 수업이 빡세기도 했고 시간이 잘 나지 않아서 제대로 수료를 하지 못했다.

(이런거 다 핑계겠죠? 하지만,, 뭐 이미 지나간거 붙잡지 않습니다)

모집 요강도 변화가 생겼다.
6기 까지는 코딩테스트가 2번이었는데, 이번에는 1번으로 바뀐것,,

공지를 6월 30일쯤 발견하고 사실 지원서를 7월 2일에 제출하고,

급하게 포트폴리오 정리와 깃허브, 노션 세팅을 시작했다.

지원서에 포트폴리오 넣는 링크나 첨부파일이 준비되어있으니
지원서 작성하실 분들은 미리 준비를 하시기를,,

급하게 준비한다고 전 6월 30일부터 7월 11일까지 세팅을 했습니다.
깃허브, 노션 하나도 쓸줄도 몰랐는데, 급하게 익혔습니다..

(제 플래너도 일부 공개합니다)

클릭하시면 링크로 넘어갑니당

진짜 6월 말~ 7월부터 깃허브 채웠어요.
(진짜 황급하게 세팅하면 링크를 일단 남기시고, 얼른 채워가세요!)

제 깃허브와 노션도 첨부할게요.

ssunbear - Overview

ssunbear has 9 repositories available. Follow their code on GitHub.

github.com

윤선웅 | Notion

@ssun_bear

ssunbear.notion.site

자기소개서랑 포트폴리오를 제출하면 코딩테스트와 AI 기초 테스트가 남아있습니다.

개인적으로 코딩테스트의 난이도는 그렇게 어렵지 않았습니다.

백준 기준 실버 상위 정도의 문제들이 나왔다고 생각합니다.
대신 문제가 10문제였습니다.

6기는 프로그래머스에서 7기는 구름에서 코딩테스트를 진행했고,
AI 테스트는 프리코스 온라인 자율학습을 듣고 수강하시면 거의 대부분 무난하게 맞추실수 있는 문제들이
준비되어있습니다. 20문제 모두 객관식이었습니다.

제 기억으로는 3시간 정도의 시간이 주어졌던걸로 기억하고,
저는 개인적으로 2시간정도 후에 퇴실했습니다.

코딩테스트 인증 샷
(남기려고한게 아니라 주변 환경 모니터링 세팅할때 카메라버튼 눌려져서 캡처 된듯)

코테 끝나고 포트폴리오 빠르게 채워나가시고
합격날짜가 오면 합격했습니다 라고 메일이 옵니다.

저는 NLP에 지원해서 합격했습니다
정확한 인원은 말씀드리기가 어렵지만 약 100명 정도가 같이 듣는것 같습니다.

다른 도메인은 각 몇명인지 정확히는 알지 못하지만
CV > NLP > RecSys 이 순서대로 인원이 듣는 것 같습니다.

이후 합격하면 온보딩 키트가 배송됩니다.
(감사합니다 운영진 분들)

플래너, 보조배터리, 노트북받침대, 키링, 스티커 등등
너무 이쁘게 받아서 쓰고 있습니다.

요근래 저의 일상들,, 이것도 좀 많이 지난 저의 일상입니다.
아직 LEVEL 1임에도 너무 바쁩니다.
LEVEL 1 마지막 프로젝트 한주 남았는데,, busy 합니다.

절대 강의 밀리지 마세요..
나중은 없습니다. 주말에 들어야지, 연휴에 들어야지 이런생각이 드는 순간,
거의 못듣고 넘어간다고 보면 됩니다 ㅠ
주어진 스케줄에 맞춰서 꼭 들으세요!

새로운 한주가 오지 않기를,, 늘 바라는 저의 마음,,

[백준] 1111번: IQ Test - [Python]

ssun_bear — Fri, 12 Jul 2024 18:51:45 +0900

문제

https://www.acmicpc.net/problem/1111

IQ Test의 문제 중에는 공통된 패턴을 찾는 문제가 있다. 수열이 주어졌을 때, 다음 수를 찾는 문제이다.

예를 들어, 1, 2, 3, 4, 5가 주어졌다. 다음 수는 무엇인가? 당연히 답은 6이다. 약간 더 어려운 문제를 보면, 3, 6, 12, 24, 48이 주어졌을 때, 다음 수는 무엇인가? 역시 답은 96이다.

이제 제일 어려운 문제를 보자.

1, 4, 13, 40이 주어졌을 때, 다음 수는 무엇일까? 답은 121이다. 그 이유는 항상 다음 수는 앞 수*3+1이기 때문이다.

은진이는 위의 3문제를 모두 풀지 못했으므로, 자동으로 풀어주는 프로그램을 작성하기로 했다. 항상 모든 답은 구하는 규칙은 앞 수*a + b이다. 그리고, a와 b는 정수이다.

수 N개가 주어졌을 때, 규칙에 맞는 다음 수를 구하는 프로그램을 작성하시오.

입력

첫째 줄에 N이 주어진다. N은 50보다 작거나 같은 자연수이다. 둘째 줄에는 N개의 수가 주어진다. 이 수는 모두 절댓값이 100보다 작거나 같은 정수이다.

출력

다음 수를 출력한다. 만약 다음 수가 여러 개일 경우에는 A를 출력하고, 다음 수를 구할 수 없는 경우에는 B를 출력한다.

아이디어

y=ax+b 꼴이므로 입력값의 개수가 세 개 이상이면 a,b를 구하여 예측값과 비교를 하면 된다.

입력값의 개수가 한개라면 A를 출력

만약 두개라면 공차가 0인 등차수열인지 (두개의 값이 같다면) 값을 출력해주고, 다르다면 등차수열인지 등비수열인지 알수 없으므로 B를 출력한다.

코드

n=int(input())
arr=list(map(int, input().split()))

if n==1: print('A')
elif n==2:
    if arr[0]==arr[1]: print(arr[0])
    else: print('A')
else:
    # y = ax + b , 기울기랑 상수값 찾자
    if arr[1]-arr[0]!=0:
        a=(arr[2]-arr[1]) // (arr[1]-arr[0])
    else: 
        a=0

    b=arr[1]-a*arr[0]
    flag=0
    for j in range(n-1):
        tmp=a*arr[j]+b
        if arr[j+1]==tmp:
            continue
        else:
            print('B')
            flag=1
            break
    
    if flag!=1:
        print(arr[n-1]*a+b)

[프로그래머스] LV. 3. 연속 펄스 부분 수열의 합 - [Python]

ssun_bear — Fri, 12 Jul 2024 15:05:05 +0900

프로그래머스

코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요.

programmers.co.kr

문제설명

어떤 수열의 연속 부분 수열에 같은 길이의 펄스 수열을 각 원소끼리 곱하여 연속 펄스 부분 수열을 만들려 합니다. 펄스 수열이란 [1, -1, 1, -1 …] 또는 [-1, 1, -1, 1 …] 과 같이 1 또는 -1로 시작하면서 1과 -1이 번갈아 나오는 수열입니다.
예를 들어 수열 [2, 3, -6, 1, 3, -1, 2, 4]의 연속 부분 수열 [3, -6, 1]에 펄스 수열 [1, -1, 1]을 곱하면 연속 펄스 부분수열은 [3, 6, 1]이 됩니다. 또 다른 예시로 연속 부분 수열 [3, -1, 2, 4]에 펄스 수열 [-1, 1, -1, 1]을 곱하면 연속 펄스 부분수열은 [-3, -1, -2, 4]이 됩니다.
정수 수열 sequence가 매개변수로 주어질 때, 연속 펄스 부분 수열의 합 중 가장 큰 것을 return 하도록 solution 함수를 완성해주세요.

제한 사항

1 ≤ sequence의 길이 ≤ 500,000
-100,000 ≤ sequence의 원소 ≤ 100,000
- sequence의 원소는 정수입니다.

아이디어

부분수열 관련 문제는 accumulate()를 사용하면 편하게 풀릴수 있다고 했는데 이 문제가 바로 그 문제이다.

일단 pulse와 repulse를 [1,-1,1,-1 ...]*sequence , [-1,1,-1,1...]*sequence로 설정하고

각각의 부분수열의 합을 계산하여 최댓값을 출력하는 것이다.

accumulate(pulse, lambda x, y:max(y,x+y))

코드를 보다보면 이 코드가 나오는데, 하나씩 뜯어보면 금방 이해가 될 것이다.

그럼에도 모르겠다면 댓글 달아주세요.

(시작값과 그 다음까지 더한 값을 기준으로 최댓값만 센다는 아이디어.. 이것이 힌트입니다.)

코드

from itertools import accumulate

def solution(sequence):
    n = len(sequence)
    pulse = [((-1)**(i%2))*sequence[i] for i in range(n)]
    repulse = [i*(-1) for i in pulse]
    print(pulse)
    print(repulse)
    arr = []
    arr.append(list(accumulate(pulse, lambda x, y:max(y,x+y))))
    arr.append(list(accumulate(repulse, lambda x, y:max(y, x+y))))
    print(arr)
    
    answer = max(max(arr[0]), max(arr[1]))
    return answer

[프로그래머스] LV. 2. 요격 시스템 - [Python]

ssun_bear — Fri, 12 Jul 2024 14:57:08 +0900

프로그래머스

programmers.co.kr

문제 설명

A 나라가 B 나라를 침공하였습니다. B 나라의 대부분의 전략 자원은 아이기스 군사 기지에 집중되어 있기 때문에 A 나라는 B 나라의 아이기스 군사 기지에 융단폭격을 가했습니다.
A 나라의 공격에 대항하여 아이기스 군사 기지에서는 무수히 쏟아지는 폭격 미사일들을 요격하려고 합니다. 이곳에는 백발백중을 자랑하는 요격 시스템이 있지만 운용 비용이 상당하기 때문에 미사일을 최소로 사용해서 모든 폭격 미사일을 요격하려 합니다.
A 나라와 B 나라가 싸우고 있는 이 세계는 2 차원 공간으로 이루어져 있습니다. A 나라가 발사한 폭격 미사일은 x 축에 평행한 직선 형태의 모양이며 개구간을 나타내는 정수 쌍 (s, e) 형태로 표현됩니다. B 나라는 특정 x 좌표에서 y 축에 수평이 되도록 미사일을 발사하며, 발사된 미사일은 해당 x 좌표에 걸쳐있는 모든 폭격 미사일을 관통하여 한 번에 요격할 수 있습니다. 단, 개구간 (s, e)로 표현되는 폭격 미사일은 s와 e에서 발사하는 요격 미사일로는 요격할 수 없습니다. 요격 미사일은 실수인 x 좌표에서도 발사할 수 있습니다.
각 폭격 미사일의 x 좌표 범위 목록 targets이 매개변수로 주어질 때, 모든 폭격 미사일을 요격하기 위해 필요한 요격 미사일 수의 최솟값을 return 하도록 solution 함수를 완성해 주세요.

제한 사항

1 ≤ targets의 길이 ≤ 500,000
targets의 각 행은 [s,e] 형태입니다.
- 이는 한 폭격 미사일의 x 좌표 범위를 나타내며, 개구간 (s, e)에서 요격해야 합니다.
- 0 ≤ s < e ≤ 100,000,000

아이디어

사실 관련 문제를 너무 많이 풀어서 풀이가 저절로 생각나긴 했다.

구름 Level - 구름 스퀘어

구름LEVEL

난이도별 다양한 문제를 해결함으로써 SW 역량을 향상시킬 수 있습니다.

level.goorm.io

백준도 같은 방식의 문제를 몇개 풀었는데 번호를 못찾겠다.

핵심 아이디어는 다음과 같다.

시작이 아닌 종료시간을 기준으로 정렬을 먼저 하는 것이다.

종료값을 기준으로 정렬을 하면 같은 시작값이어도 최대 길이의 종료값을 먼저 나타낼수 있기때문이다.

코드

def solution(targets):
    
    target=sorted(targets, key=lambda x: x[1])
    
    #print(target)
    answer, end= 0,0
    for s, e in target:
        if s>=end:
            answer+=1
            end=e
    return answer

[프로그래머스] LV. 2. 연속된 부분 수열의 합 - [Python]

ssun_bear — Fri, 12 Jul 2024 14:47:47 +0900

프로그래머스

programmers.co.kr

문제 설명

비내림차순으로 정렬된 수열이 주어질 때, 다음 조건을 만족하는 부분 수열을 찾으려고 합니다.

기존 수열에서 임의의 두 인덱스의 원소와 그 사이의 원소를 모두 포함하는 부분 수열이어야 합니다.
부분 수열의 합은 k입니다.
합이 k인 부분 수열이 여러 개인 경우 길이가 짧은 수열을 찾습니다.
길이가 짧은 수열이 여러 개인 경우 앞쪽(시작 인덱스가 작은)에 나오는 수열을 찾습니다.

수열을 나타내는 정수 배열 sequence와 부분 수열의 합을 나타내는 정수 k가 매개변수로 주어질 때, 위 조건을 만족하는 부분 수열의 시작 인덱스와 마지막 인덱스를 배열에 담아 return 하는 solution 함수를 완성해주세요. 이때 수열의 인덱스는 0부터 시작합니다.

제한사항

5 ≤ sequence의 길이 ≤ 1,000,000
- 1 ≤ sequence의 원소 ≤ 1,000
- sequence는 비내림차순으로 정렬되어 있습니다.
5 ≤ k ≤ 1,000,000,000
- k는 항상 sequence의 부분 수열로 만들 수 있는 값입니다.

아이디어

- accumulate() 함수를 사용한다 -> 시간복잡도가 복잡 ->실패

- 투포인터를 사용한다.

부분수열 관련 문제는 두가지 아이디어가 있다. 일반적으로 투포인터를 주로 사용하면 원하는 조건에 맞는 값을 출력할수 있다.

부분수열을 구하라라는 문제가 있다면 accumulate()를 사용하면 편리한 경우도 있기에 문제에 따른 시간복잡도에 따라 선택하는 것이 좋다.

틀린 코드 (44.1/100)

from itertools import accumulate

def solution(sequence, k):
    s,e=0,0
    n=len(sequence)
    answer=[]
    empty=[]
    for i in range(n):
        empty.append(list(accumulate(sequence[i::])))
        
    #print(empty)
    for i in range(n):
        for j in range(len(empty[i])):
            if empty[i][j]==k:
                answer.append([i,j+i])

    answer.sort(key = lambda x: (x[1]-x[0]))
    
    return answer[0]

accumulate() 함수를 이용하여 부분수열을 모두 구하고, 합을 만족하는 부분수열을 찾고 길이가 가장 짧은 것을 출력했다.

시간복잡도가 굉장히 높아서 대부분이 시간초과로 뜨게 되었다.

O(n^3)의 최악의 시간복잡도로 예상한다.

정답 코드

def solution(sequence, k):
    s,e=0,0
    n=len(sequence)
    answer=[]
    
    for i in range(n):
        while s<k and e<n:
            s+=sequence[e]
            e+=1
        if s==k:
            answer.append([i,e-1])
        s-=sequence[i]
        
    answer.sort(key=lambda x: x[1]-x[0])
    
    return answer[0]

투포인터를 이용하여 풀이하면 편리하다.

부분수열의 문제는 주로 투포인터라는 전형적인 풀이가 있다. 이를 활용하면 잘 풀린다.

이번 문제는 부분수열의 합이 주어진 값과 같은지 보는 것이기에,

만약 [s,e]구간에서의 합이 주어진 값보다 크다면 s값을 늘려주고 합보다 작다면 e값을 늘리면서 비교하는 것이다.

이렇게 풀이하면 시간복잡도가 O(n^2) 정도 나온다.

[프로그래머스] LV. 2. 과제진행하기 - [Python]

ssun_bear — Fri, 12 Jul 2024 14:20:44 +0900

프로그래머스

programmers.co.kr

문제 설명

과제를 받은 루는 다음과 같은 순서대로 과제를 하려고 계획을 세웠습니다.

과제는 시작하기로 한 시각이 되면 시작합니다.
새로운 과제를 시작할 시각이 되었을 때, 기존에 진행 중이던 과제가 있다면 진행 중이던 과제를 멈추고 새로운 과제를 시작합니다.
진행중이던 과제를 끝냈을 때, 잠시 멈춘 과제가 있다면, 멈춰둔 과제를 이어서 진행합니다.
- 만약, 과제를 끝낸 시각에 새로 시작해야 되는 과제와 잠시 멈춰둔 과제가 모두 있다면, 새로 시작해야 하는 과제부터 진행합니다.
멈춰둔 과제가 여러 개일 경우, 가장 최근에 멈춘 과제부터 시작합니다.

과제 계획을 담은 이차원 문자열 배열 plans가 매개변수로 주어질 때, 과제를 끝낸 순서대로 이름을 배열에 담아 return 하는 solution 함수를 완성해주세요.

제한사항

3 ≤ plans의 길이 ≤ 1,000
- plans의 원소는 [name, start, playtime]의 구조로 이루어져 있습니다.
  - name : 과제의 이름을 의미합니다.
    - 2 ≤ name의 길이 ≤ 10
    - name은 알파벳 소문자로만 이루어져 있습니다.
    - name이 중복되는 원소는 없습니다.
  - start : 과제의 시작 시각을 나타냅니다.
    - "hh:mm"의 형태로 "00:00" ~ "23:59" 사이의 시간값만 들어가 있습니다.
    - 모든 과제의 시작 시각은 달라서 겹칠 일이 없습니다.
    - 과제는 "00:00" ... "23:59" 순으로 시작하면 됩니다. 즉, 시와 분의 값이 작을수록 더 빨리 시작한 과제입니다.
  - playtime : 과제를 마치는데 걸리는 시간을 의미하며, 단위는 분입니다.
    - 1 ≤ playtime ≤ 100
    - playtime은 0으로 시작하지 않습니다.
  - 배열은 시간순으로 정렬되어 있지 않을 수 있습니다.
진행중이던 과제가 끝나는 시각과 새로운 과제를 시작해야하는 시각이 같은 경우 진행중이던 과제는 끝난 것으로 판단합니다.

아이디어

일단 입력된 plans의 구조를 바꾸려고 한다.

문자형으로 입력된 "06:30"등의 형식을 모두 분, 정수형으로 변환시켜서 비교하는 것이 좋다.

이때 리스트 슬라이싱을 이용하여 정수형으로 바꾸는 것이 좋고, 이후 변환된 분을 기준으로 오름차순 정렬을 진행한다.

이후 스택 자료구조를 사용하여 진행중인 과제에 넣고 다음과제와 현재과제의 시간차이를 계산한다.

만약 시간차이가 현재 과제 진행하는 시간보다 적다면 완료리스트에 현재과제를 추가하고, 진행중인 과제를 pop한다.

반대로 현재 과제를 진행하는 시간이 많이 걸린다면, 앞으로 과제 수행하는데 걸리는 시간을 업데이트해주고 시간차이를 0으로 초기화 해준다.

마지막으로 마지막 과제와 남아있는 진행중인 과제는 역순으로 저장하여 출력한다.

코드

def solution(plans):
    answer=[]
    now=[]
    #배열 시간순으로 정렬
    #배열 수정: 시간을 모두 분으로 수정, 문자형 정수를 정수형으로 수정
    plans.sort(key=lambda x:x[1])
    for i in range(len(plans)):
        plans[i][1]=int(plans[i][1][0:2])*60+int(plans[i][1][3:])
        plans[i][2]=int(plans[i][2])
    
    for i in range(len(plans)-1):
        #현재과제와 다음과제 차이 계산
        now.append(plans[i])
        diff=plans[i+1][1]-plans[i][1]
        
        #시간차이가 업거나 진행중인 과제가 없을때까지 반복
        while now and diff:
            #현재과제 해결 가능: 완료리스트(answer)에 추가, 진행중과제 pop
            if now[-1][2]<=diff:
                diff-=now[-1][2]
                answer.append(now[-1][0])
                now.pop()
            #현재과제 해결 불가능: 진행중인 과제에 시간차이 업데이트
            else: 
                now[-1][2]-=diff
                diff=0
    
    #마지막과제와 남아있는 진행중인 과제 역순으로 저장
    answer.append(plans[-1][0])
    while now:
        answer.append(now[-1][0])
        now.pop(-1)
    
    return answer

# 약 한시간 정도 소요
# 시간복잡도 O(n*logn)

[프로그래머스] LV. 2. 광물 캐기 - [Python]

ssun_bear — Fri, 12 Jul 2024 14:07:30 +0900

프로그래머스

programmers.co.kr

문제 설명

마인은 곡괭이로 광산에서 광석을 캐려고 합니다. 마인은 다이아몬드 곡괭이, 철 곡괭이, 돌 곡괭이를 각각 0개에서 5개까지 가지고 있으며, 곡괭이로 광물을 캘 때는 피로도가 소모됩니다. 각 곡괭이로 광물을 캘 때의 피로도는 아래 표와 같습니다.

예를 들어, 철 곡괭이는 다이아몬드를 캘 때 피로도 5가 소모되며, 철과 돌을 캘때는 피로도가 1씩 소모됩니다. 각 곡괭이는 종류에 상관없이 광물 5개를 캔 후에는 더 이상 사용할 수 없습니다.

마인은 다음과 같은 규칙을 지키면서 최소한의 피로도로 광물을 캐려고 합니다.

사용할 수 있는 곡괭이중 아무거나 하나를 선택해 광물을 캡니다.
한 번 사용하기 시작한 곡괭이는 사용할 수 없을 때까지 사용합니다.
광물은 주어진 순서대로만 캘 수 있습니다.
광산에 있는 모든 광물을 캐거나, 더 사용할 곡괭이가 없을 때까지 광물을 캡니다.

즉, 곡괭이를 하나 선택해서 광물 5개를 연속으로 캐고, 다음 곡괭이를 선택해서 광물 5개를 연속으로 캐는 과정을 반복하며, 더 사용할 곡괭이가 없거나 광산에 있는 모든 광물을 캘 때까지 과정을 반복하면 됩니다.

마인이 갖고 있는 곡괭이의 개수를 나타내는 정수 배열 picks와 광물들의 순서를 나타내는 문자열 배열 minerals가 매개변수로 주어질 때, 마인이 작업을 끝내기까지 필요한 최소한의 피로도를 return 하는 solution 함수를 완성해주세요.

제한사항

picks는 [dia, iron, stone]과 같은 구조로 이루어져 있습니다.
- 0 ≤ dia, iron, stone ≤ 5
- dia는 다이아몬드 곡괭이의 수를 의미합니다.
- iron은 철 곡괭이의 수를 의미합니다.
- stone은 돌 곡괭이의 수를 의미합니다.
- 곡괭이는 최소 1개 이상 가지고 있습니다.
5 ≤ minerals의 길이 ≤ 50
- minerals는 다음 3개의 문자열로 이루어져 있으며 각각의 의미는 다음과 같습니다.
- diamond : 다이아몬드
- iron : 철
- stone : 돌

아이디어

한번에 캘수 있는 광물은 5개이기에 5개씩 일단 minerals를 분할합니다.

이후 diamond, iron, stone으로 채굴할 수 있는 비용을 계산합니다.

costs가 적게드는 순서대로 정렬

이후 주어진 pick 개수 내에서 최소비용으로 채굴한다.

코드 - 틀린 코드 (97.1/100)

def solution(picks, minerals):
    answer = 0
    mineral_list=[]
    for i in range(0, len(minerals), 5):
        mineral_list.append(minerals[i:i+5])

    costs = []
    for mineral in mineral_list:
        cost = [0, 0, 0] 
        for mine in mineral:
            if mine == 'diamond':
                cost[0], cost[1], cost[2] = cost[0]+1, cost[1]+5, cost[2]+25
            elif mine == 'iron':
                cost[0], cost[1], cost[2] = cost[0]+1, cost[1]+1, cost[2]+5
            elif mine == 'stone':
                cost[0], cost[1], cost[2] = cost[0]+1, cost[1]+1, cost[2]+1
        costs.append(cost)
    
    costs.sort(key=lambda x: (-x[2]))
    
    # 주어진 픽 개수 내에서 최소 비용으로 채굴
    for cost in costs:
        if picks[0] > 0:
            picks[0] -= 1
            answer += cost[0]
            continue
        if picks[1] > 0:
            picks[1] -= 1
            answer += cost[1]
            continue
        if picks[2] > 0:
            picks[2] -= 1
            answer += cost[2]
            continue
    
    return answer

# 소요시간 40분
# 시간복잡도 O(nlogn)

코드 - 정답 코드

def solution(picks, minerals):
    answer = 0
    # 미네랄 5개씩 쪼개기
    
    mineral_list=[]
    for i in range(0, len(minerals), 5):
        mineral_list.append(minerals[i:i+5])

    # 각 미네랄 묶음의 채굴 비용 계산
    costs = []
    for mineral in mineral_list:
        cost = [0, 0, 0] 
        for mine in mineral:
            if mine == 'diamond':
                cost[0], cost[1], cost[2] = cost[0]+1, cost[1]+5, cost[2]+25
            elif mine == 'iron':
                cost[0], cost[1], cost[2] = cost[0]+1, cost[1]+1, cost[2]+5
            elif mine == 'stone':
                cost[0], cost[1], cost[2] = cost[0]+1, cost[1]+1, cost[2]+1
        costs.append(cost)
    else:
        # 곡갱이 수보다 많은 광물캐는 것 불가능
        while len(costs)>sum(picks): costs.pop()
    
    # 비용이 가장 적게 드는 순서대로 정렬
    costs.sort(key=lambda x: (-x[2]))
    
    # 주어진 픽 개수 내에서 최소 비용으로 채굴
    for cost in costs:
        if picks[0] > 0:
            picks[0] -= 1
            answer += cost[0]
            continue
        if picks[1] > 0:
            picks[1] -= 1
            answer += cost[1]
            continue
        if picks[2] > 0:
            picks[2] -= 1
            answer += cost[2]
            continue
    
    return answer

틀린 이유로는 mineral이 5개 단위로 쪼갰지만, 5의 배수 단위로 존재하지 않기때문에 costs가 곡갱이 수보다 많아지는 경우가 생기기 때문이다. 그래서 코드를 수정하였다.

[프로그래머스] LV. 1. 달리기 경주 - [Python]

ssun_bear — Fri, 12 Jul 2024 02:41:22 +0900

프로그래머스

programmers.co.kr

문제 설명

얀에서는 매년 달리기 경주가 열립니다. 해설진들은 선수들이 자기 바로 앞의 선수를 추월할 때 추월한 선수의 이름을 부릅니다. 예를 들어 1등부터 3등까지 "mumu", "soe", "poe" 선수들이 순서대로 달리고 있을 때, 해설진이 "soe"선수를 불렀다면 2등인 "soe" 선수가 1등인 "mumu" 선수를 추월했다는 것입니다. 즉 "soe" 선수가 1등, "mumu" 선수가 2등으로 바뀝니다.

선수들의 이름이 1등부터 현재 등수 순서대로 담긴 문자열 배열 players와 해설진이 부른 이름을 담은 문자열 배열 callings가 매개변수로 주어질 때, 경주가 끝났을 때 선수들의 이름을 1등부터 등수 순서대로 배열에 담아 return 하는 solution 함수를 완성해주세요.

제한사항

5 ≤ players의 길이 ≤ 50,000
- players[i]는 i번째 선수의 이름을 의미합니다.
- players의 원소들은 알파벳 소문자로만 이루어져 있습니다.
- players에는 중복된 값이 들어가 있지 않습니다.
- 3 ≤ players[i]의 길이 ≤ 10
2 ≤ callings의 길이 ≤ 1,000,000
- callings는 players의 원소들로만 이루어져 있습니다.
- 경주 진행중 1등인 선수의 이름은 불리지 않습니다.

아이디어

리스트의 문자열과 해당 인덱스를 딕셔너리로 선언해서 이름과 그 순위를 나타낸다.

이때 enumerate()를 사용하면 편리하다.

이후 calling에서 이름을 부르면 앞순위 사람과 스왑을 진행해주면 된다.

딕셔너리는 in의 기능이 O(1)이기에 시간복잡도도 좋게 구현할 수 있다.

코드

def solution(players, callings):
    dic={player: idx for idx, player in enumerate(players)}
    
    for name in callings:
        index=dic[name]
        players[index], players[index-1]=players[index-1], players[index]
        dic[players[index]], dic[players[index-1]]=index,index-1
    
    return players

시간복잡도 O(N)

[프로그래머스] LV. 1. 추억 점수 - [Python]

ssun_bear — Fri, 12 Jul 2024 02:35:40 +0900

프로그래머스

programmers.co.kr

문제 설명

사진들을 보며 추억에 젖어 있던 루는 사진별로 추억 점수를 매길려고 합니다. 사진 속에 나오는 인물의 그리움 점수를 모두 합산한 값이 해당 사진의 추억 점수가 됩니다. 예를 들어 사진 속 인물의 이름이 ["may", "kein", "kain"]이고 각 인물의 그리움 점수가 [5점, 10점, 1점]일 때 해당 사진의 추억 점수는 16(5 + 10 + 1)점이 됩니다. 다른 사진 속 인물의 이름이 ["kali", "mari", "don", "tony"]이고 ["kali", "mari", "don"]의 그리움 점수가 각각 [11점, 1점, 55점]]이고, "tony"는 그리움 점수가 없을 때, 이 사진의 추억 점수는 3명의 그리움 점수를 합한 67(11 + 1 + 55)점입니다.

그리워하는 사람의 이름을 담은 문자열 배열 name, 각 사람별 그리움 점수를 담은 정수 배열 yearning, 각 사진에 찍힌 인물의 이름을 담은 이차원 문자열 배열 photo가 매개변수로 주어질 때, 사진들의 추억 점수를 photo에 주어진 순서대로 배열에 담아 return하는 solution 함수를 완성해주세요.

제한사항

3 ≤ name의 길이 = yearning의 길이≤ 100
- 3 ≤ name의 원소의 길이 ≤ 7
- name의 원소들은 알파벳 소문자로만 이루어져 있습니다.
- name에는 중복된 값이 들어가지 않습니다.
- 1 ≤ yearning[i] ≤ 100
- yearning[i]는 i번째 사람의 그리움 점수입니다.
3 ≤ photo의 길이 ≤ 100
- 1 ≤ photo[i]의 길이 ≤ 100
- 3 ≤ photo[i]의 원소(문자열)의 길이 ≤ 7
- photo[i]의 원소들은 알파벳 소문자로만 이루어져 있습니다.
- photo[i]의 원소들은 중복된 값이 들어가지 않습니다.

아이디어

name과 yearning을 딕셔너리로 묶어주고 photo에 해당하는 점수들을 return 하는 간단한 구현 문제

코드

def solution(name, yearning, photo):
    dic = {name[i]: yearning[i] for i in range(len(name))}
    answer = []
    for case in photo:
        score = 0
        for person in case:
            if person in dic:
                score += dic[person]
        answer.append(score)
    return answer

시간복잡도 O(N^2)

[프로그래머스] LV. 1. 공원 산책 - [Python]

ssun_bear — Fri, 12 Jul 2024 02:32:03 +0900

프로그래머스

programmers.co.kr

문제 설명

지나다니는 길을 'O', 장애물을 'X'로 나타낸 직사각형 격자 모양의 공원에서 로봇 강아지가 산책을 하려합니다. 산책은 로봇 강아지에 미리 입력된 명령에 따라 진행하며, 명령은 다음과 같은 형식으로 주어집니다.

["방향 거리", "방향 거리" … ]

예를 들어 "E 5"는 로봇 강아지가 현재 위치에서 동쪽으로 5칸 이동했다는 의미입니다. 로봇 강아지는 명령을 수행하기 전에 다음 두 가지를 먼저 확인합니다.

주어진 방향으로 이동할 때 공원을 벗어나는지 확인합니다.
주어진 방향으로 이동 중 장애물을 만나는지 확인합니다.

위 두 가지중 어느 하나라도 해당된다면, 로봇 강아지는 해당 명령을 무시하고 다음 명령을 수행합니다.
공원의 가로 길이가 W, 세로 길이가 H라고 할 때, 공원의 좌측 상단의 좌표는 (0, 0), 우측 하단의 좌표는 (H - 1, W - 1) 입니다.

공원을 나타내는 문자열 배열 park, 로봇 강아지가 수행할 명령이 담긴 문자열 배열 routes가 매개변수로 주어질 때, 로봇 강아지가 모든 명령을 수행 후 놓인 위치를 [세로 방향 좌표, 가로 방향 좌표] 순으로 배열에 담아 return 하도록 solution 함수를 완성해주세요.

제한사항

3 ≤ park의 길이 ≤ 50
- 3 ≤ park[i]의 길이 ≤ 50
  - park[i]는 다음 문자들로 이루어져 있으며 시작지점은 하나만 주어집니다.
    - S : 시작 지점
    - O : 이동 가능한 통로
    - X : 장애물
- park는 직사각형 모양입니다.
1 ≤ routes의 길이 ≤ 50
- routes의 각 원소는 로봇 강아지가 수행할 명령어를 나타냅니다.
- 로봇 강아지는 routes의 첫 번째 원소부터 순서대로 명령을 수행합니다.
- routes의 원소는 "op n"과 같은 구조로 이루어져 있으며, op는 이동할 방향, n은 이동할 칸의 수를 의미합니다.
  - op는 다음 네 가지중 하나로 이루어져 있습니다.
    - N : 북쪽으로 주어진 칸만큼 이동합니다.
    - S : 남쪽으로 주어진 칸만큼 이동합니다.
    - W : 서쪽으로 주어진 칸만큼 이동합니다.
    - E : 동쪽으로 주어진 칸만큼 이동합니다.
  - 1 ≤ n ≤ 9

아이디어

쉬운 그래프 탐색 구현 문제, 시작점 찾은 이후 routes의 방향과 이동칸수 만큼 이동, 경로에 X가 있다면 이동하지 않는다.

코드

시간복잡도 O(N^2)

def solution(park, routes):
    answer=[]
    #시작점 찾기
    for i in range(len(park)):
        for j in range(len(park[0])):
            if park[i][j]=='S':
                sx,sy=i,j
                break
               
    op=[[-1,0],[0,1],[0,-1],[1,0]] #NEWS
  
    for route in routes:
        news,n=route.split(' ')
        n=int(n)
        nx,ny=sx,sy
        
        if news=='N': idx=0
        elif news=='E': idx=1
        elif news=='W':idx=2
        else: idx=3
        
        print(nx,ny)
        for i in range(n):
            dx,dy=op[idx][0],op[idx][1]
            if 0<=sx+dx<len(park) and 0<=sy+dy<len(park[0]) and park[sx+dx][sy+dy]!='X':
                sx,sy=sx+dx,sy+dy
            else:
                sx,sy=nx,ny
                break
                
    answer.append([sx,sy])

딕셔너리를 활용해 {N:[-1,0], E:[0,1], W:[0,-1], S:[1,0]}으로 작성했다면 코드가 더 간결했을 것으로 생각된다.

[프로그래머스] LV. 1. 덧칠하기 - [Python]

ssun_bear — Fri, 12 Jul 2024 02:23:32 +0900

프로그래머스

programmers.co.kr

문제 설명

코딩테스트를 준비하는 머쓱이는 프로그래머스에서 문제를 풀고 나중에 다시 코드를 보면서 공부하려고 작성한 코드를 컴퓨터 바탕화면에 아무 위치에나 저장해 둡니다. 저장한 코드가 많아지면서 머쓱이는 본인의 컴퓨터 바탕화면이 너무 지저분하다고 생각했습니다. 프로그래머스에서 작성했던 코드는 그 문제에 가서 다시 볼 수 있기 때문에 저장해 둔 파일들을 전부 삭제하기로 했습니다.

컴퓨터 바탕화면은 각 칸이 정사각형인 격자판입니다. 이때 컴퓨터 바탕화면의 상태를 나타낸 문자열 배열 wallpaper가 주어집니다. 파일들은 바탕화면의 격자칸에 위치하고 바탕화면의 격자점들은 바탕화면의 가장 왼쪽 위를 (0, 0)으로 시작해 (세로 좌표, 가로 좌표)로 표현합니다. 빈칸은 ".", 파일이 있는 칸은 "#"의 값을 가집니다. 드래그를 하면 파일들을 선택할 수 있고, 선택된 파일들을 삭제할 수 있습니다. 머쓱이는 최소한의 이동거리를 갖는 한 번의 드래그로 모든 파일을 선택해서 한 번에 지우려고 하며 드래그로 파일들을 선택하는 방법은 다음과 같습니다.

드래그는 바탕화면의 격자점 S(lux, luy)를 마우스 왼쪽 버튼으로 클릭한 상태로 격자점 E(rdx, rdy)로 이동한 뒤 마우스 왼쪽 버튼을 떼는 행동입니다. 이때, "점 S에서 점 E로 드래그한다"고 표현하고 점 S와 점 E를 각각 드래그의 시작점, 끝점이라고 표현합니다.
점 S(lux, luy)에서 점 E(rdx, rdy)로 드래그를 할 때, "드래그 한 거리"는 |rdx - lux| + |rdy - luy|로 정의합니다.
점 S에서 점 E로 드래그를 하면 바탕화면에서 두 격자점을 각각 왼쪽 위, 오른쪽 아래로 하는 직사각형 내부에 있는 모든 파일이 선택됩니다.

예를 들어 wallpaper = [".#...", "..#..", "...#."]인 바탕화면을 그림으로 나타내면 다음과 같습니다.

이러한 바탕화면에서 다음 그림과 같이 S(0, 1)에서 E(3, 4)로 드래그하면 세 개의 파일이 모두 선택되므로 드래그 한 거리 (3 - 0) + (4 - 1) = 6을 최솟값으로 모든 파일을 선택 가능합니다.

(0, 0)에서 (3, 5)로 드래그해도 모든 파일을 선택할 수 있지만 이때 드래그 한 거리는 (3 - 0) + (5 - 0) = 8이고 이전의 방법보다 거리가 늘어납니다.

머쓱이의 컴퓨터 바탕화면의 상태를 나타내는 문자열 배열 wallpaper가 매개변수로 주어질 때 바탕화면의 파일들을 한 번에 삭제하기 위해 최소한의 이동거리를 갖는 드래그의 시작점과 끝점을 담은 정수 배열을 return하는 solution 함수를 작성해 주세요. 드래그의 시작점이 (lux, luy), 끝점이 (rdx, rdy)라면 정수 배열 [lux, luy, rdx, rdy]를 return하면 됩니다.

제한사항

1 ≤ wallpaper의 길이 ≤ 50
1 ≤ wallpaper[i]의 길이 ≤ 50
- wallpaper의 모든 원소의 길이는 동일합니다.
wallpaper[i][j]는 바탕화면에서 i + 1행 j + 1열에 해당하는 칸의 상태를 나타냅니다.
wallpaper[i][j]는 "#" 또는 "."의 값만 가집니다.
바탕화면에는 적어도 하나의 파일이 있습니다.
드래그 시작점 (lux, luy)와 끝점 (rdx, rdy)는 lux < rdx, luy < rdy를 만족해야 합니다.

아이디어

# 위치들의 (x,y)좌표의 최소에 해당하는 x,y값과 (x+1,y+1)의 좌표의 최대에 해당하는 x,y값을 찾아서 return 하는 구현문제

코드

def solution(wallpaper):
    n=len(wallpaper)
    m=len(wallpaper[0])
    #print(n,m)
    check1=[]
    check2=[]
    for i in range(n):
        for j in range(m):
            if wallpaper[i][j]=='#':
                check1.append(i)
                check1.append(i+1)
                check2.append(j)
                check2.append(j+1)
                

    answer = []
    answer.append(min(check1))
    answer.append(min(check2))
    answer.append(max(check1))
    answer.append(max(check2))
    return answer

[프로그래머스] LV. 1. 덧칠하기 - [Python]

ssun_bear — Fri, 12 Jul 2024 02:17:05 +0900

프로그래머스

programmers.co.kr

문제 설명

어느 학교에 페인트가 칠해진 길이가 n미터인 벽이 있습니다. 벽에 동아리 · 학회 홍보나 회사 채용 공고 포스터 등을 게시하기 위해 테이프로 붙였다가 철거할 때 떼는 일이 많고 그 과정에서 페인트가 벗겨지곤 합니다. 페인트가 벗겨진 벽이 보기 흉해져 학교는 벽에 페인트를 덧칠하기로 했습니다.

넓은 벽 전체에 페인트를 새로 칠하는 대신, 구역을 나누어 일부만 페인트를 새로 칠 함으로써 예산을 아끼려 합니다. 이를 위해 벽을 1미터 길이의 구역 n개로 나누고, 각 구역에 왼쪽부터 순서대로 1번부터 n번까지 번호를 붙였습니다. 그리고 페인트를 다시 칠해야 할 구역들을 정했습니다.

벽에 페인트를 칠하는 롤러의 길이는 m미터이고, 롤러로 벽에 페인트를 한 번 칠하는 규칙은 다음과 같습니다.

롤러가 벽에서 벗어나면 안 됩니다.
구역의 일부분만 포함되도록 칠하면 안 됩니다.

즉, 롤러의 좌우측 끝을 구역의 경계선 혹은 벽의 좌우측 끝부분에 맞춘 후 롤러를 위아래로 움직이면서 벽을 칠합니다. 현재 페인트를 칠하는 구역들을 완전히 칠한 후 벽에서 롤러를 떼며, 이를 벽을 한 번 칠했다고 정의합니다.

한 구역에 페인트를 여러 번 칠해도 되고 다시 칠해야 할 구역이 아닌 곳에 페인트를 칠해도 되지만 다시 칠하기로 정한 구역은 적어도 한 번 페인트칠을 해야 합니다. 예산을 아끼기 위해 다시 칠할 구역을 정했듯 마찬가지로 롤러로 페인트칠을 하는 횟수를 최소화하려고 합니다.

정수 n, m과 다시 페인트를 칠하기로 정한 구역들의 번호가 담긴 정수 배열 section이 매개변수로 주어질 때 롤러로 페인트칠해야 하는 최소 횟수를 return 하는 solution 함수를 작성해 주세요.

제한사항

1 ≤ m ≤ n ≤ 100,000
1 ≤ section의 길이 ≤ n
- 1 ≤ section의 원소 ≤ n
- section의 원소는 페인트를 다시 칠해야 하는 구역의 번호입니다.
- section에서 같은 원소가 두 번 이상 나타나지 않습니다.
- section의 원소는 오름차순으로 정렬되어 있습니다.

입출력 예

아이디어

페인트를 section 구간 시작부터 m칸 만큼 채우는 구현 문제

코드 - 시간복잡도 : O(N^2)

def solution(n, m, section):
    answer = 0
    while section:
        if len(section) > 0:
            next_pos = section[0] + m
            while section and section[0] < next_pos:
                section.pop(0) # O(N)
            answer += 1
    return answer

처음에 코드를 작성할 때 시간복잡도를 고려하지 않고 section.pop(0)를 사용하였다.

section을 만약에 deque()로 선언해주고 section.popleft()를 해주었다면 O(1)의 시간복잡도가 형성되었을 것이다.

다만, section은 리스트로 선언되어있어 section.pop(0)는 O(N)의 시간복잡도를 가지게 되었다.

N=1,000,000이라 통과하지 않을 것으로 예상하였으나 통과를 하게 되서 코드를 제출하고 다시볼때 의문이 들었다.

시간복잡도를 고려해서 코드를 짜도록 하자.

(이후 정리할 겸 아래의 글을 작성하였다.)

파이썬 - 리스트, 집합, 딕셔너리 시간복잡도 정리

알고리즘을 풀면서 문제를 맞추어도 효율이 안좋은 경우가 종종 있다.시간복잡도를 최대한 줄여 효율을 끌어올려야 겠다고 생각이 들어 시간복잡도를 정리해본다.삽입(insert,pop), 제거(delete, remo

define-me.tistory.com

코드 - 시간복잡도 : O(N)

from collections import deque

def solution(n, m, section):
	section=deque(section)
    answer = 0
    while section:
        if len(section) > 0:
            next_pos = section[0] + m
            while section and section[0] < next_pos:
                section.popleft() # O(1)
            answer += 1
    return answer

[프로그래머스] LV. 1. 대충 만든 자판 - [Python]

ssun_bear — Fri, 12 Jul 2024 02:05:48 +0900

프로그래머스

programmers.co.kr

문제 설명

휴대폰의 자판은 컴퓨터 키보드 자판과는 다르게 하나의 키에 여러 개의 문자가 할당될 수 있습니다. 키 하나에 여러 문자가 할당된 경우, 동일한 키를 연속해서 빠르게 누르면 할당된 순서대로 문자가 바뀝니다.

예를 들어, 1번 키에 "A", "B", "C" 순서대로 문자가 할당되어 있다면 1번 키를 한 번 누르면 "A", 두 번 누르면 "B", 세 번 누르면 "C"가 되는 식입니다.

같은 규칙을 적용해 아무렇게나 만든 휴대폰 자판이 있습니다. 이 휴대폰 자판은 키의 개수가 1개부터 최대 100개까지 있을 수 있으며, 특정 키를 눌렀을 때 입력되는 문자들도 무작위로 배열되어 있습니다. 또, 같은 문자가 자판 전체에 여러 번 할당된 경우도 있고, 키 하나에 같은 문자가 여러 번 할당된 경우도 있습니다. 심지어 아예 할당되지 않은 경우도 있습니다. 따라서 몇몇 문자열은 작성할 수 없을 수도 있습니다.

이 휴대폰 자판을 이용해 특정 문자열을 작성할 때, 키를 최소 몇 번 눌러야 그 문자열을 작성할 수 있는지 알아보고자 합니다.

1번 키부터 차례대로 할당된 문자들이 순서대로 담긴 문자열배열 keymap과 입력하려는 문자열들이 담긴 문자열 배열 targets가 주어질 때, 각 문자열을 작성하기 위해 키를 최소 몇 번씩 눌러야 하는지 순서대로 배열에 담아 return 하는 solution 함수를 완성해 주세요.

단, 목표 문자열을 작성할 수 없을 때는 -1을 저장합니다.

제한사항

1 ≤ keymap의 길이 ≤ 100
- 1 ≤ keymap의 원소의 길이 ≤ 100
- keymap[i]는 i + 1번 키를 눌렀을 때 순서대로 바뀌는 문자를 의미합니다.
  - 예를 들어 keymap[0] = "ABACD" 인 경우 1번 키를 한 번 누르면 A, 두 번 누르면 B, 세 번 누르면 A 가 됩니다.
- keymap의 원소의 길이는 서로 다를 수 있습니다.
- keymap의 원소는 알파벳 대문자로만 이루어져 있습니다.
1 ≤ targets의 길이 ≤ 100
- 1 ≤ targets의 원소의 길이 ≤ 100
- targets의 원소는 알파벳 대문자로만 이루어져 있습니다.

아이디어

keymap에서의 알파벳과 해당 최소 인덱스를 각각 dic에 키, 값으로 넣어주기

targets에서 해당하는 점수 answer에 넣어주기

파이썬 딕셔너리를 이용한 구현 문제

시간복잡도는 O(N^2)이다.

코드

def solution(keymap, targets):
    dic={}
    for i in range(len(keymap)):
        for j in range(len(keymap[i])):
            alphabet=keymap[i][j]
            if alphabet in dic.keys():
                dic[alphabet]=min(dic[alphabet], j+1)
            else:
                dic[alphabet]=j+1
         
    answer = []
    for i in range(len(targets)):
        total=0
        for j in range(len(targets[i])):
            if targets[i][j] in dic.keys():
                total+=dic[targets[i][j]]
            else:
                total=-1
                break
        answer.append(total)
    
    return answer

[프로그래머스] LV. 1. 카드뭉치 - [Python]

ssun_bear — Fri, 12 Jul 2024 02:00:05 +0900

프로그래머스

programmers.co.kr

문제 설명

코니는 영어 단어가 적힌 카드 뭉치 두 개를 선물로 받았습니다. 코니는 다음과 같은 규칙으로 카드에 적힌 단어들을 사용해 원하는 순서의 단어 배열을 만들 수 있는지 알고 싶습니다.

원하는 카드 뭉치에서 카드를 순서대로 한 장씩 사용합니다.
한 번 사용한 카드는 다시 사용할 수 없습니다.
카드를 사용하지 않고 다음 카드로 넘어갈 수 없습니다.
기존에 주어진 카드 뭉치의 단어 순서는 바꿀 수 없습니다.

예를 들어 첫 번째 카드 뭉치에 순서대로 ["i", "drink", "water"], 두 번째 카드 뭉치에 순서대로 ["want", "to"]가 적혀있을 때 ["i", "want", "to", "drink", "water"] 순서의 단어 배열을 만들려고 한다면 첫 번째 카드 뭉치에서 "i"를 사용한 후 두 번째 카드 뭉치에서 "want"와 "to"를 사용하고 첫 번째 카드뭉치에 "drink"와 "water"를 차례대로 사용하면 원하는 순서의 단어 배열을 만들 수 있습니다.

문자열로 이루어진 배열 cards1, cards2와 원하는 단어 배열 goal이 매개변수로 주어질 때, cards1과 cards2에 적힌 단어들로 goal를 만들 있다면 "Yes"를, 만들 수 없다면 "No"를 return하는 solution 함수를 완성해주세요.

제한사항

1 ≤ cards1의 길이, cards2의 길이 ≤ 10
- 1 ≤ cards1[i]의 길이, cards2[i]의 길이 ≤ 10
- cards1과 cards2에는 서로 다른 단어만 존재합니다.
2 ≤ goal의 길이 ≤ cards1의 길이 + cards2의 길이
- 1 ≤ goal[i]의 길이 ≤ 10
- goal의 원소는 cards1과 cards2의 원소들로만 이루어져 있습니다.
cards1, cards2, goal의 문자열들은 모두 알파벳 소문자로만 이루어져 있습니다.

아이디어 설명

덱 구조를 활용하여 card1, card2 자료구조 변경 -> 시간복잡도 낮은 popleft쓰기 위해

goal의 첫 원소부터 card1[0], cards2[0]가 있는지 확인

있다면 해당 cards의 첫 원소 popleft()

없다면 answer=NO 이후 탈출시켜준다.

시간복잡도 O(N)

코드

from collections import deque

def solution(cards1, cards2, goal):
    answer="Yes"
    cards1=deque(cards1)
    cards2=deque(cards2)

    for i in range(len(goal)):
        if cards1 and cards1[0]==goal[i]:
            cards1.popleft()
        elif cards2 and cards2[0]==goal[i]:
            cards2.popleft()
        else:
            answer="No"
            break
    
    return answer

분할 정복(Divide and Conquer)

ssun_bear — Thu, 11 Jul 2024 23:58:48 +0900

1. 분할 정복(Divide and Conquer)

큰 문제를 작은 부분 문제로 분할하고, 각각의 작은 부분 문제를 해결하여 전체 문제의 해답을 구하는 알고리즘

문제의 크기가 커서 직접적인 해결이 어려운 경우 유용하다.

대표적인 예로, 정렬 알고리즘인 병합 정렬(Merge Sort)과 퀵 정렬(Quick Sort)이 있다.

2. 동작 방식

문제를 작은 부분 문제들로 분할한다.
분할된 부분 문제들을 각각 재귀적으로 해결한다.
부분 문제들의 해답을 결합하여 전체 문제의 해답을 얻는다.

3. 시간 복잡도

시간 복잡도는 일반적으로 부분 문제의 개수, 분할된 문제의 크기, 분할과정의 복잡도에 따라 결정된다.

대부분의 경우, 분할 정복 알고리즘은 재귀적인 방법으로 문제를 해결하므로, 재귀 호출의 깊이에 따라 시간 복잡도가 결정된다.

분할된 문제들의 크기가 일정하다면, 재귀 호출의 깊이는 로그 시간 복잡도에 비례한다.

분할된 문제의 개수가 N이라면, 시간 복잡도는 O(N*logN)

그러나 분할된 문제의 개수가 지수적으로 증가하거나 분할된 문제들이 크기가 일정하지 않은 경우, 시간 복잡도가 지수적으로 증가할 수 있다.

이 경우에는 다른 알고리즘을 고려해야 한다.

4. 병합 정렬(Merge Sort)

분할과 정복을 모두 사용하여 리스트를 반으로 나누어 각각을 재귀적으로 정렬하고, 정렬된 두 개의 부분 리스트를 합쳐 전체 리스트를 정렬하는 방식

1. 동작 과정

분할: 입력 리스트를 반으로 나눕니다.
정복: 각각의 부분 리스트를 재귀적으로 병합 정렬합니다.
결합: 정렬된 부분 리스트를 합쳐 전체 리스트를 정렬합니다.

2. 파이썬 구현 코드

def merge_sort(arr):
    if len(arr) <= 1:
        return arr
    
    # Divide
    mid = len(arr) // 2
    left = arr[:mid]
    right = arr[mid:]
    
    # Conquer
    left_sorted = merge_sort(left)
    right_sorted = merge_sort(right)
    
    # Combine
    return merge(left_sorted, right_sorted)
    
    
def merge(left, right):
    result = []
    i, j = 0, 0
    
    while i < len(left) and j < len(right):
        if left[i] <= right[j]:
            result.append(left[i])
            i += 1
        else:
            result.append(right[j])
            j += 1
    
    result += left[i:]
    result += right[j:]
    
    return result

merge_sort 함수 :
- 입력 리스트를 반으로 나누고 재귀적으로 호출하여 각각을 정렬
- 마지막으로 merge 함수를 사용하여 두 정렬된 리스트를 합병하여 전체 리스트를 정렬
merge 함수 :
- 두 개의 정렬된 리스트를 인수로 받아, 두 리스트를 비교하여 작은 순서대로 result 리스트에 삽입하고, 남은 요소를 추가하여 반환

5. 퀵 정렬(Quick Sort)

분할과 정복을 사용하여 리스트를 분할하고, 각각을 재귀적으로 정렬한 다음, 전체 리스트를 합치지 않고 원래 위치에 놓여있는 것을 기준으로 정렬

특히, 정렬을 위해 별도의 저장 공간을 필요로 하지 않아 메모리 사용량이 적다는 특징이 있다.

1. 동작과정

기준점(pivot) 선택: 리스트에서 하나의 원소를 기준점으로 선택한다.
분할: 기준점을 기준으로 리스트를 두 개로 분할한다. 분할된 두 개의 리스트는 각각 기준점보다 작은 값과 큰 값으로 이루어져 있다.
정복: 각각의 부분 리스트를 재귀적으로 퀵 정렬한다.
결합: 정렬된 부분 리스트를 합쳐 전체 리스트를 정렬한다.

2. 파이썬 구현 코드

def quick_sort(arr):
    if len(arr) <= 1:
        return arr
    
    # Divide
    pivot = arr[0]
    left = []
    right = []
    
    for i in range(1, len(arr)):
        if arr[i] < pivot:
            left.append(arr[i])
        else:
            right.append(arr[i])
    
    # Conquer
    left_sorted = quick_sort(left)
    right_sorted = quick_sort(right)
    
    # Combine
    return left_sorted + [pivot] + right_sorted

quick_sort 함수 :
- 입력 리스트의 첫 번째 요소를 기준으로 왼쪽과 오른쪽 부분 리스트를 나눔
- 재귀적으로 각각을 정렬하여 마지막으로 합쳐서 반환

입력 리스트의 첫 번째 요소를 기준으로 나누기 때문에, 최악의 경우(이미 정렬된 리스트, 피벗이 가장 작거나 큰 수 등)에는 분할이 제대로 이루어지지 않아 시간 복잡도가 O(n^2)에 근접해질 수 있다.

이를 방지하기 위해서는 피벗을 무작위로 선택하거나, 미리 섞어서 평균적인 경우를 대응하는 방법 등이 있다.

탐색 알고리즘 - 완전 탐색

ssun_bear — Thu, 11 Jul 2024 23:56:21 +0900

완전 탐색

알고리즘에서 사용되는 기법 중 하나로 '모든 가능한 경우의 수를 탐색'하여 '최적의 결과를 찾는 방법'을 의미합니다.

  미 완전 탐색은 무엇일까?
- 모든 경우의 수를 고려하지 더 이상 탐색이 필요 없는 경우 그 루트를 끊어버리는 것을 의미합니다.
- 예를 들어서 재귀함수가 함수를 모든 경우의 수를 탐색하다 결과를 찾아서 탐색을 중지하는 경우 루트를 끊는 경우를 자치기(Pruning)라고 합니다. 이를 수행하면 불필요한 탐색을 줄일 수 있습니다.

1. 브루트 포스(Brute-Force)

난폭한 힘, 폭력 => 무식하지만 확실한 방식을 의미
이는 수행하는데 오래걸리는 데다 자원이 많이 소요되지만 이론적으로 가능한 수를 모두 검색하기에 예상된 결과를 얻을 수 있습니다.
'모든 경우를 다 탐색'하면서 결과를 얻는 알고리즘을 의미합니다.
해당 알고리즘은 경우의 수가 작을 때 사용하는 것이 일반적입니다. 대표적인 예시로는 자물쇠의 비밀번호를 알 수 없는 경우 모든 경우를 대입하여 비밀번호를 찾아가는 경우가 있습니다.

  완전 탐색에서 브루트 포스란?
모든 경우의 수를 탐색하여 최적의 결과를 찾아가는 완전탐색에서 브루트 포스는 모든 경우를 다 검사하여 원하는 값을 탐색하는 방법입니다.

  브루트 포스를 이용한 공격방식이란?
해커들은 이 알고리즘을 이용하여 다양한 공격을 시도합니다. 예를 들어, 로그인 페이지에서 사용자 이름과 비밀번호를 입력하여 로그인하는 경우 해커들은 브루트 포스 알고리즘을 이용하여 가능한 모든 비밀번호를 시도하면서 로그인을 시도합니다. 이러한 공격을 방지하기 위해서는 강력한 비밀번호를 사용하고 로그인 시도 횟수를 제안하는 등의 보안 조치를 취해야 합니다.

브루터 포스 사용 예시

배열 탐색
- 배열에서 특정 값을 찾는 문제에서 브루트 포스 알고리즘은 배열을 모두 탐색하여 값을 찾는 방식으로 문제를 해결합니다.
문자열 비교
- 문자열 비교 문제에서 브루트 포스 알고리즘은 가능한 모든 문자열 쌍을 비교하여 최소값 또는 최대값을 찾는 방식으로 문제를 해결합니다

2. 비트마스크(Bitmask)

'이진수'를 '비트 연산'을 통해 경우의 수를 줄여가며 탐색하는 방식을 의미합니다.
모든 경우의 수(상태)를 이진수로 표현
비트 마스크를 사용하면 하나의 변수에 여러개의 상태정보를 저장할 수 있으며 이를 통해 복잡한 조건문을 간단하게 처리할 수 있습니다.
이 방법은 비트 연산을 사용하기 때문에 빠르게 계산할 수 있어서, 경우의 수가 많은경우에 유용합니다.
완전 탐색에서 비트마스크란? 모든 경우의 수를 탐색하여 최적의 결과를 찾아가는 완전탐색에서 비트마스크는 모든 경우의 수를 이진수로 표현하여 빠르게 계산을 해 나아가는 방식입니다.

간단한 연산

a = 10 #1010
b = 12 #1100

result = a & b
result = a | b
result = a ^ b # XOR 연산
result = a << 1
result = a >> 1

비트마스크 사용 예시

권한 관리

PERMISSION_READ = 0b0001 << 0; # 0001
PERMISSION_WRITE = 0b0001 << 1; # 0010
PERMISSION_DELETE = 0b0001 << 2; # 0100
PERMISSION_EXECUTE = 0b0001 << 3; # 1000

print(PERMISSION_EXECUTE)
userPermission = PERMISSION_READ | PERMISSION_WRITE
print(userPermission)
groupPermission = PERMISSION_READ | PERMISSION_EXECUTE

hasReadPermission = (userPermission & PERMISSION_READ) != 0
print(hasReadPermission)
hasDeletePermission = groupPermission & PERMISSION_DELETE != 0
print(hasDeletePermission)

#출력문
#8
#3
#True
#False

보통 권한은 4가지 이상으로 구분되어 있는 경우가 많습니다. 이때 각 권한을 비트로 표현하여 하나의 정수값으로 나타내면 매우 간편해집니다.

집합 관리

set = (1 << 3) | (1 << 5) | (1 << 7) #0010 1010 1000
hasElement5 = (set & (1 << 5)) != 0; #True
hasElement6 = (set & (1 << 6)) != 0; #False

집합을 비트로 표현하여 메모리를 절약할 수 있습니다. 예를들어, 0부터 31까지의 정수 중에서 3, 5, 7번째 원소를 포함하는 집합을 나타내면 다음과 같이 표현할 수 있습니다.

상태 플래그 관리

FLAG_POWER_OF_TWO = 1 << 0; #0001
FLAG_NEGATIVE = 1 << 1; #0010

number = 8; # 2의 거듭제곱
flags = 0;

if number & (number-1) == 0 :
    flags |= FLAG_POWER_OF_TWO


if (number < 0):
    flags |= FLAG_NEGATIVE
    print(flags)


if ((flags & FLAG_POWER_OF_TWO) != 0):
    print(number, " is power of two") #1

if ((flags & FLAG_NEGATIVE != 0)):
    print(number, "is negaive") # 2

여러 상태를 하나의 정수값으로 나타내어 관리할 수 있다. 예를 들어, 주어진 수가 2의 거듭제곱인지 여부를 판단할 때 다음과 같은 방법을 사용할 수 있습니다.

3. 백트래킹(Backtracking)

해결책으로 가는 도중에 막히게 되면 그 지점으로 다시 돌아가서 다른 경로를 탐색하는 방식을 의미합니다. 이를 통해 모든 가능한 경우의 수를 탐색하여 해결책을 찾습니다.
해당 알고리즘을 사용할 때 주로 재귀함수를 사용하여 구현하며 스택을 이용하여서 사용하는 경우도 있습니다.
재귀함수를 이용하는 경우 해결책을 찾기 위해 생성, 검사, 선택, 이동, 되돌아가기 등 과정이 재귀적으로 수행됩니다.
완전탐색에서 백트래킹이란 - 모든 경우의 수를 탐색하여 최적의 결과를 찾아가는 완전탐색에서 백트래킹은 해결책을 찾아가는 도중에 막히게 되면 다시 돌아가서 다른 경로로 탐색을 하여 결국 모든 가능한 경우의 수를 탐색하여 해결책을 찾아가는 방식으로 사용됩니다. - 주로 재귀함수, 스택이 이용됩니다.

4. 순열 탐색

'순열'을 이용하여 모든 경우의 수를 탐색하는 방법입니다. 순열은 서로 다른 서로 다른 n개 중에서 r개를 선택하여 숫자를 모든 순서대로 뽑는 경유를 말합나다.
순열의 예
- 1, 2, 3, 세 숫자 중 '2개를 선택' 하여 숫자를 모든 순서대로 뽑는 경우입니다.
```
 [1,2] [1,3] [2,1] [2,3] [3.1] [3,2]
```

1. Swap 배열을 이용한 순열

Swap 배열
- 배열에서 두 요소의 위치를 바꿔가며 순열을 생성하는 방법입니다. 배열의 인덱스 0 부터 순서대로 선택하면 다음 인덱스와 위치를 바꾸고 이를 마지막 인덱스 까지 반복합나다.
- 이 방법은 쉽게 구현할 수 있지만, 큰 데이터셋에서는 비효율적일 수 있습니다.
- [1, 2, 3]배열에서 순열을 모두 구하는 예시입니다.
  1. 메인함수에서 permute메서드에 파라미터로 배열과 0개를 선택합니다.
  2. permute메서드는 재귀적으로 호출하면서 swap 메서드를 이용하여 배열의 원소를 순서대로 바꾸면서 모든 순열을 생성합니다.
  3. 이때, k는 순열을 생성할 위치를 의미합니다. 만약 k가 arr의 길이와 같아지면, 모든 원소에 대한 순열이 생성되었다는 것을 의미하므로 순열을 출력합니다.
즉, 순열에서 특정 값을 fix 시키고 이후의 값들을 swap 하면서 순열을 생성한다.
완전 탐색에서 순열은? - 모든 경우의 수를 탐색하여 최적의 결과를 찾아가는 완전탐색에서 순열은 서로 다른 n개 중에서 r개를 선택해서 나열하면서 모든 경우의 수를 탐색하는 방식으로 사용이 됩니다.
파이썬에서는 itertools의 permutation()을 사용하는 방법이 더 편하다.

2. Visited 배열을 이용한 순열

배열에서 '현재 인덱스의 값을 선택한 후' 해당 인덱스를 visited라는 배열에 체크합니다. 이후, 다음 인덱스로 넘어가기 전 visited 배열에서 체크되지 않은 가장 작은 인덱스를 선택합니다. 이를 마지막 인덱스까지 반복합니다.
이 방법은 swap을 이용한 배열보다 효율적입니다.
즉, 한 loop내에서 해당 인덱스가 Visited이면 다음 최소 인덱스로 넘어간다.

5. 재귀 함수(Recursion Function)

함수 내부에서 ‘자기 자신을 호출’하는 함수를 의미합니다.
이를 통해서 함수가 자신을 반복적으로 호출하면서 원하는 결과를 도출할 수 있습니다.
완전 탐색에서 재귀함수는? - 모든 경우의 수를 탐색하여 최적의 결과를 찾아가는 완전탐색에서 재귀함수는 자기 자신을 호출하며 모든 가능한 경우를 체크하면서 최적의 해답하는 방법으로 사용이 됩니다.
재귀함수는 미 완전 탐색일 수도 있다? - 재귀함수는 모든 경우의 수를 다 탐색하지 않고도 원하는 결과를 얻을 수 있는 경우도 있습니다. 따라서, 재귀함수는 미완전탐색의 일종이라고는 할 수 있지만, 항상 미완전탐색이라고 할 수는 없습니다. (뿌리 자르기)

6. 깊이 우선 탐색(DFS) / 너비 우선 탐색(BFS)

아래의 게시물을 통해 자세히 설명을 해두었으니 참조하는 것이 좋을 것 같다.

탐색 알고리즘 - DFS와 BFS

BFS와 DFS는 모두 그래프를 탐색하는 방법이다. 그래프는 Node와 Node를 연결하는 Edge로 이루어진 자료구조이고 그래프를 탐색하는 것은 하나의 정점으로부터 연결된 모든 정점들을 한 번씩 차례대

define-me.tistory.com

탐색 알고리즘 - 이진 탐색

ssun_bear — Thu, 11 Jul 2024 23:45:20 +0900

1. 이진 탐색

이진 탐색은 탐색의 범위를 절반씩 좁혀가며 데이터를 탐색하는 알고리즘입니다.

이진탐색 알고리즘은 리스트 내 데이터가 어느 정도 정렬되어 있어야만 사용 가능하며 데이터가 무작위로 정렬되어 있다면 사용할 수 없습니다.

이진 탐색 알고리즘은 입력 데이터가 많거나(e.g., 1,000만 개 이상) 탐색 범위의 크기가 매우 넓을 때(e.g., 1,000억 이상) 효과적으로 문제를 해결할 수 있습니다.

2. 이진 탐색의 동작 과정

이진 탐색은 특정 데이터를 찾기 위해 리스트 내 기준점으로서 시작 인덱스, 중간 인덱스, 마지막 인덱스를 사용합니다.

이진 탐색의 동작 순서는 아래와 같습니다.

1️⃣ 시작 인덱스와 마지막 인덱스 사이의 중간 값에서 소수점 이하를 버려 중간 인덱스를 정합니다.

2️⃣ 중간 인덱스에 해당하는 데이터와 현재 찾으려는 데이터가 같은지 비교합니다.

3️⃣ 중간 값이 더 크면 중간 인덱스 이후의 값은 확인하지 않고, 마지막 인덱스를 중간 인덱스로부터 한 칸 앞으로 옮깁니다.

반대로, 중간 값이 더 작다면 시작 인덱스를 중간 인덱스로부터 한 칸 뒤로 옮깁니다.

4️⃣ 중간 인덱스의 값과 찾으려는 값이 같아질 때까지 2️⃣ 과정과 3️⃣ 과정을 반복합니다.

이제 구체적인 예시를 통해 동작 과정을 알아보겠습니다. 아래와 같이 리스트 내 10개의 데이터 중에서 값이 4인 원소를 이진 탐색을 통해 찾아보겠습니다.

편의상 찾고자 하는 데이터(target data)는 파란색으로 표현하고, 탐색할 필요가 없는 데이터는 회색으로 채우겠습니다.

(1) 리스트 내 원소가 총 10개이므로 시작 인덱스는 [0]이고 마지막 인덱스는 [9]입니다. 중간 인덱스는 시작 인덱스와 마지막 인덱스의 중간 지점인 [4]가 됩니다. [4.5]에서 소수점 이하를 버리기 때문이죠.

(2) 중간 인덱스의 값인 8은 찾으려는 값 4보다 크기 때문에, 중간 인덱스 이후의 값은 이제 따로 탐색하지 않습니다. 이제 마지막 인덱스를 중간 인덱스 한 칸 앞으로 옮깁니다. 즉, 기존 중간 인덱스가 [4]였기 때문에 마지막 인덱스는 [3]이 됩니다. 중간 인덱스는 [0]과 [3] 중간 값인 [1]이 됩니다(실제 중간 값인 [1.5]에서 소수점 이하를 제거하였습니다).

(3) 중간 인덱스의 값인 2는 찾으려는 데이터 4보다 작기 때문에 2 이하의 데이터는 탐색할 필요가 없습니다. 따라서 시작 인덱스를 중간 인덱스의 한 칸 뒤인 [2]로 옮깁니다. 이제 새로운 중간 인덱스는 [2]와 [3] 사이의 [2]가 됩니다([2.5]에서 소수점 이하 절사). 중간 인덱스에 위치한 데이터 4는 찾으려는 데이터 4와 같기 때문에 이 시점에서 탐색을 종료합니다.

3. 이진 탐색의 구현(Python)

파이썬 기반에서 이진 탐색은 2가지 방법으로 구현이 가능합니다. 첫 번째는 재귀 함수를 사용하는 것이고, 다른 한 가지 방법은 반복문을 이용하는 것입니다. 각 방법별로 구현 방법을 알아보도록 하겠습니다.

3.1. 재귀 함수를 활용한 구현

# 재귀함수를 활용한 이진 탐색 구현
def binary_search (arr, target, start, end):
    
    if start > end:
        return None
    
    # 중간 인덱스는 시작 인덱스와 마지막 인덱스 사이의 중간 인덱스
    # 몫만 구하기 위해 // 연산자 활용
    mid = (start + end) // 2
    
    # 중간 인덱스의 값이 타겟 데이터와 같은 경우 탐색 종료
    if arr[mid] == target:
        return mid
        
    # 중간 인덱스의 값이 타겟 데이터보다 큰 경우
    # 마지막 인덱스를 중간 인덱스의 한 칸 앞으로 이동
    elif arr[mid] > target:
        return binary_search(arr, target, start, mid-1)
        
    # 중간 인덱스의 값이 타겟 데이터보다 작은 경우
    # 시작 인덱스를 중간 인덱스의 한 칸 뒤로 이동
    else:
        return binary_search(arr, target, mid+1, end)

arr = [0, 2, 4, 6, 8, 10, 12, 14, 16, 18]
n = len(arr)
# 찾으려는 값으로서 임의로 4로 설정
target = 4

# 시작 인덱스 및 마지막 인덱스를 전달인자로 할당
res = binary_search(arr, target, 0, n-1)
print("{}번째에서 타겟 확인.".format(res + 1))

3.2. 반복문을 활용한 구현

# 반복문을 활용한 이진 탐색 구현
def binary_search (arr, target, start, end):
    while start <= end:
        # 중간 인덱스는 시작 인덱스와 마지막 인덱스 사이의 중간 인덱스
        # 몫만 구하기 위해 // 연산자 활용
        mid = (start + end) // 2
    
        # 중간 인덱스의 값이 타겟 데이터와 같은 경우 탐색 종료
        if arr[mid] == target:
            return mid
        
        # 중간 인덱스의 값이 타겟 데이터보다 큰 경우
        # 마지막 인덱스를 중간 인덱스의 한 칸 앞으로 이동
        elif arr[mid] > target:
            end = mid - 1
        
        # 중간 인덱스의 값이 타겟 데이터보다 작은 경우
        # 시작 인덱스를 중간 인덱스의 한 칸 뒤로 이동
        else:
            start = mid + 1
            
    return None

arr = [0, 2, 4, 6, 8, 10, 12, 14, 16, 18]
n = len(arr)
# 찾으려는 값으로서 임의로 4로 설정
target = 4

# 시작 인덱스 및 마지막 인덱스를 전달인자로 할당
res = binary_search(arr, target, 0, n-1)
print("{}번째에서 타겟 확인.".format(res + 1))

4. 이진 탐색의 시간 복잡도

앞서 살펴본 예시에서는 리스트 내 데이터가 총 10개였지만, 이진 탐색을 이용하면 총 3회의 탐색을 통해 원하는 데이터를 찾을 수 있었습니다. 이진 탐색은 탐색 횟수별로 확인하는 데이터의 개수가 절반씩 줄어들기 때문에 시간 복잡도가 O(log N) 입니다. 이처럼 확인하는 데이터의 개수가 절반씩 줄어드는 특징은 퀵 정렬과 동일합니다.

그렇다면 이진 탐색은 언제 사용하면 좋을까요?

탐색해야 하는 데이터의 개수나 값이 1,000만 단위 이상일 경우 이진 탐색과 같이 시간 복잡도가 O(log N) 수준으로 빠른 속도를 낼 수 있는 알고리즘을 활용하는 것이 좋습니다.

최단 경로 문제 - 플로이드 워셜(Floyd-Warshall) 알고리즘

ssun_bear — Thu, 11 Jul 2024 23:12:54 +0900

플로이드 워셜

플로이드 워셜 알고리즘을 쓰는 문제의 경우, 노드의 개수가 500개 이하일 경우가 많다.
하지만 노드가 500개라고 해도 500 * 500 * 500 은 1억이 넘어가기 때문에 시간제한이 넉넉하지 않다면 시간초과에 걸릴 수도 있다.

1. 플로이드 워셜 알고리즘 개요

모든 노드에서 다른 모든 노드까지의 최단 경로를 모두 계산한다.
플로이드 워셜(Floyd-Warshall) 알고리즘은 다익스트라 알고리즘과 마찬가지로 단계별로 거쳐 가는 노드를 기준으로 알고리즘을 수행한다.
- 다만 매 단계마다 방문하지 않은 노드 중에 최단 거리를 갖는 노드를 찾는 과정이 필요하지 않다.
플로이드 워셜은 2차원 테이블에 최단 거리 정보를 저장한다.
플로이드 워셜 알고리즘은 다이나믹 프로그래밍 유형에 속한다.

2. 플로이드 워셜 알고리즘

각 단계마다 특정한 노드 k를 거쳐 가는 경우를 확인한다.
- a에서 b로 가는 최단 거리보다 a에서 k를 거쳐 b로 가는 거리가 더 짧은지 검사한다.
점화식은 다음과 같다.

3. 플로이드 워셜 알고리즘: 동작 과정 살펴보기

4. 플로이드 워셜 알고리즘 구현 (Python)

INF = int(1e9)  # 무한을 의미하는 값으로 10억을 설정

# 노드의 개수 및 간선의 개수를 입력받기
n = int(input())
m = int(input())
# 2차원 리스트(그래프 표현)를 만들고, 무한으로 초기화
graph = [[INF] * (n + 1) for _ in range(n + 1)]

# 자기 자신에게 자기 자신으로 가는 비용은 0으로 초기화
for a in range(1, n + 1):
	for b in range(1, n + 1):
		if a == b:
			graph[a][b] = 0

# 각 간선에 대한 정보를 입력 받아, 그 값으로 초기화
for _ in range(m):
	# A에서 B로 가는 비용은 C라고 설정
	a, b, c = map(int, input().split())
	graph[a][b] = c

# 점화식에 따라 플로이드 워셜 알고리즘을 수행
for k in range(1, n + 1):
	for a in range(1, n + 1):
		for b in range(1, n + 1):
			graph[a][b] = min(graph[a][b], graph[a][k] + graph[k][b])

# 수행된 결과를 출력
for a in range(1, n + 1):
	for b in range(1, n + 1):
		# 도달할 수 없는 경우, 무한(INFINITY)이라고 출력
		if graph[a][b] == INF:
			print("INFINITY", end=" ")
		# 도달할 수 있는 경우 거리를 출력
		else:
			print(graph[a][b], end=" ")
    print()

5. 플로이드 워셜 알고리즘 성능 분석

노드의 개수가 N개일 때 알고리즘 상으로 N번의 단계를 수행한다.
- 각 단계마다 O(N^2)의 연산을 통해 현재 노드를 거쳐 가는 모든 경로를 고려한다.
따라서 플로디으 워셜 알고리즘의 총 시간 복잡도는 O(N^3)이다.

최단 경로 문제 (이코테 ch7. 최단 경로 알고리즘 예시)

1. <문제> 전보: 문제 설명

2. <문제> 전보: 문제 조건

3. <문제> 전보: 문제 해결 아이디어

4. <문제> 전보: 답안 예시(Python)

import heapq
import sys
input = sys.stdin.readline
INF = int(1e9)  # 무한을 의미하는 값으로 10억을 설정

# 노드의 개수, 간선의 개수, 시작 노드를 입력받기
n, m, start = map(int, input().split())
# 각 노드에 연결되어 있는 노드에 대한 정보를 담는 리스트를 만들기
graph = [[] for i in range(n + 1)]
# 최단 거리 테이블을 모두 무한으로 초기화
distance = [INF] * (n + 1)

# 모든 간선 정보를 입력받기
for _ in range(m):
	x, y, z = map(int, input().split())
	# X번 노드에서 Y번 노드로 가는 비용이 Z라는 의미
	graph[x].append((y, z))

def dijkstra(start):
	q = []
	# 시작 노드로 가기 위한 최단 거리는 0으로 설정하여, 큐에 삽입
	heapq.heappush(q, (0, start))
	distance[start] = 0
	while q:  # 큐가 비어있지 않다면
		# 가장 최단 거리가 짧은 노드에 대한 정보를 꺼내기
		dist, now = heapq.heappop(q)
		if distance[now] < dist:
			continue
		# 현재 노드와 연결된 다른 인접한 노드들을 확인
		for i in graph[now]:
			cost = dist + i[1]
			# 현재 노드를 거쳐서, 다른 노드로 이동하는 거리가 더 짧은 경우
			if cost < distance[i[0]]:
				distance[i[0]] = cost
				heapq.heappush(q, (cost, i[0]))

# 다익스트라 알고리즘을 수행
dijkstra(start)

# 도달할 수 있는 노드의 개수
count = 0
# 도달할 수 있는 노드 중에서, 가장 멀리 있는 노드와의 최단 거리
max_distance = 0
for d in distance:
	# 도달할 수 있는 노드인 경우
	if d != INF:
		count += 1
		max_distance = max(max_distance, d)

# 시작 노드는 제외해야 하므로 count - 1을 출력
print(count - 1, max_distance)

최단 경로 문제 - 다익스트라(Dijkstra) 알고리즘

ssun_bear — Thu, 11 Jul 2024 22:55:08 +0900

최단 경로 문제

최단 경로 알고리즘은 가장 짧은 경로를 찾는 알고리즘을 의미한다.

cf. 다양한 문제 상황

한 지점에서 다른 한 지점까지의 최단 경로
한 지점에서 다른 모든 지점까지의 최단 경로
모든 지점에서 다른 모든 지점까지의 최단 경로

각 지점은 그래프에서 노드로 표현한다.

지점 간 연결된 도로는 그래프에서 간선으로 표현한다.

방향그래프 예시

1. 다익스트라 최단 경로 알고리즘 개요

특정한 노드에서 출발하여 다른 모든 노드로 가는 최단 경로를 계산한다.
다익스트라 최단 경로 알고리즘은 음의 간선이 없을 때 정상적으로 동작한다.
- 현실 세계의 도로(간선)은 음의 간선으로 표현되지 않는다.
다익스트라 최단 경로 알고리즘은 그리디 알고리즘으로 분류된다.
- 매 상황에서 가장 비용이 적은 노드를 선택해 임의의 과정을 반복한다.

2. 다익스트라 최단 경로 알고리즘

알고리즘의 동작 과정은 다음과 같다.

출발 노드를 설정한다.
최단 거리 테이블을 초기화한다. (cf. 모든 노드까지 가기 위한 비용을 무한으로 설정하고 자기 자신에 대한 노드는 0으로 설정한다.)
방문하지 않은 노드 중에서 최단 거리가 가장 짧은 노드를 선택한다.
해당 노드를 거쳐 다른 노드로 가는 비용을 계산하여 최단 거리 테이블을 갱신한다.
위 과정에서 3번과 4번을 반복한다.

알고리즘 동작 과정에서 최단 거리 테이블은 각 노드에 대한 현재까지의 최단 거리 정보를 가지고 있다.

처리 과정에서 더 짧은 경로를 찾으면 '이제부터는 이 경로가 제일 짧은 경로야'라고 갱신한다.

3. 다익스트라 알고리즘: 동작 과정 살펴보기

cf) 이미 방문처리된 노드라면, 그 노드까지 최단거리값이 결정되어 바뀌지 않기 때문에 무시하는 방법을 사용할 수도 있다.
여기에서 4번 노드는 이미 방문했기 때문에 무시할 수도 있다.

앞서 확인했던 다른 노드까지의 최단 경로는 바뀌지 않기때문에 마지막 노드에 대해선 처리하지 않아도 된다.

4. 다익스트라 알고리즘의 특징

그리디 알고리즘: 매 상황에서 방문하지 않은 가장 비용이 적은 노드를 선택해 임의의 과정을 반복한다.
단계를 거치며 한 번 처리된 노드의 최단 거리는 고정되어 더 이상 바뀌지 않는다.
- 한 단계당 하나의 노드에 대한 최단 거리를 확실히 찾는 것으로 이해할 수 있다.
다익스트라 알고리즘을 수행한 뒤에 테이블에 각 노드까지의 최단 거리 정보가 저장된다.
- 완벽한 형태의 최단 경로를 구하려면 소스코드에 추가적인 기능을 더 넣어야 한다.

다익스트라 알고리즘 구현(Python) - 개선 전

1. 다익스트라 알고리즘: 간단한 구현 방법(Python)

단계마다 방문하지 않은 노드 중에서 최단 거리가 가장 짧은 노드를 선택하기 위해 매 단계마다 1차원 테이블의 모든 원소를 확인(순차 탐색)한다.

import sys
input = sys.stdin.readline
INF = int(1e9)  # 무한을 의미하는 값으로 10억을 설정

# 노드의 개수, 간선의 개수를 입력받기
n , m = map(int, input().split())
# 시작 노드 번호를 입력받기
start = int(input())
# 각 노드에 연결되어 있는 노드에 대한 정보를 담는 리스트를 만들기
graph = [[] for i in range(n + 1)]
# 방문한 적이 있는지 체크하는 목적의 리스트를 만들기
visited = [False] * (n + 1)
# 최단 거리 테이블을 모두 무한으로 초기화
distance = [INF] * (n + 1)

# 모든 간선 정보를 입력받기
for _ in range(m):
	a, b, c = map(int, input().split())
	# a번 노드에서 b번 노드로 가는 비용이 c라는 의미
	graph[a].append((b, c))

# 방문하지 않은 노드 중에서, 가장 최단 거리가 짧은 노드의 번호를 반환
def get_smallest_node():
	min_value = INF
	index = 0  # 가장 최단 거리가 짧은 노드(인덱스)
	for i in range(1, n + 1):
		if distance[i] < min_value and not visited[i]:
			min_value = distance[i]
			index = i
	return index

def dijkstra(start):
	# 시작 노드에 대해서 초기화
	distance[start] = 0
	visited[start] = True
	for j in graph[start]:
		distance[j[0]] = j[1]
	# 시작 노드를 제외한 전체 n - 1개의 노드에 대해 반복
	for i in range(n - 1):
		# 현재 최단 거리가 가장 짧은 노드를 꺼내서, 방문처리
		now = get_smallest_node()
		visited[now] = True
		# 현재 노드와 연결된 다른 노드를 확인
		for j in graph[now]:
			cost = distance[now] + j[1]
			# 현재 노드를 거쳐서 다른 노드로 이동하는 거리가 더 짧은 경우
			if cost < distance[j[0]]:
				distance[j[0]] = cost

# 다익스트라 알고리즘을 수행
dijkstra(start)

# 모든 노드로 가기 위한 최단 거리를 출력
for i in range(1, n + 1):
	# 도달할 수 없는 경우, 무한(INFINITY)이라고 출력
	if distance[i] == INF:
		print("INFINITY")
	# 도달할 수 있는 경우 거리를 출력
	else:
		print(distance[i])

2. 다익스트라 알고리즘: 간단한 구현 방법 성능 분석

총 O(V)번에 걸쳐서 최단 거리가 가장 짧은 노드를 매번 선형 탐색해야 한다.
따라서 전체 시간 복잡도는 O(V^2)이다.
일반적으로 코딩 테스트의 최단 경로 문제에서 전체 노드의 개수가 5,000개 이하라면 이 코드로 문제를 해결할 수 있다.
- 하지만 노드의 개수가 10,000개를 넘어가는 문제라면 어떻게 해야할까?
  - 따라서 우선순위 큐(Priority Queue) 자료구조를 알아야할 필요가 있다.

다익스트라 알고리즘 구현(Python) - 개선한 버전 (우선순위 큐)

1. 우선순위 큐(Priority Queue)

우선순위가 가장 높은 데이터를 가장 먼저 삭제하는 자료구조이다.

예를 들어 여러 개의 물건 데이터를 자료구조에 넣었다가 가치가 높은 물건 데이터부터 꺼내서 확인해야하는 경우 우선순위 큐를 이용할 수 있다.

Python, C++, Java를 포함한 대부분의 프로그래밍 언어에서 표준 라이브러리 형태로 지원한다.

1-1. 힙(Heap)

우선순위 큐(Priority Queue)를 구현하기 위해 사용하는 자료구조 중 하나이다.

최소 힙(Min Heap)과 최대 힙(Max Heap)이 있다.

(cf. 최소 힙은 값이 낮은 값부터 꺼내는 방식, 최대 힙은 높은 값부터 꺼내는 방식으로 동작)

다익스트라 최단 경로 알고리즘을 포함해 다향한 알고리즘에서 사용된다.

1-1-1. 힙 라이브러리 사용 예제: 최소 힙

heapq 라이브러리는 데이터를 꺼낼 때 우선순위가 높은 데이터부터 차례대로 나온다는 특징때문에, 이러한 heapq 자료구조의 특성을 이용해서 정렬을 수행할 수 있다.

기본적으로 파이썬은 heapq 라이브러리를 그대로 사용하게 되면 최소 힙(min heap)으로 구현되어있다.

즉, 우선순위가 낮은 데이터부터 차례대로 꺼내지게 된다(오름차순 정렬).

import heapq

# 오른차순 힙 정렬(Heap Sort)
def heapsort(iterable):
	h = []
	result = []
	# 모든 원소를 차례대로 힙에 삽입
	for value in iterable:
		heapq.heappush(h, value)
	# 힙에 삽입된 모든 원소를 차례대로 꺼내어 담기
	for i in range(len(h)):
		result.append(heapq.heappop(h))
	return result

result = heapsort([1, 3, 5, 7, 9, 2, 4, 6, 8, 0])

1-1-2. 힙 라이브러리 사용 예제: 최대 힙

파이썬에서는 별도로 최대 힙을 지원해주지 않는다.

따라서 데이터를 힙에 넣을 때 마이너스(-)를 붙여서 넣고 데이터를 꺼낼 때 마이너스(-)를 붙여서 꺼내면 최대 힙과 같은 효과를 볼 수 있다(내림차순 정렬).

import heapq

# 내림차순 힙 정렬(Heap Sort)
def heapsort(iterable):
	h = []
	result = []
	# 모든 원소를 차례대로 힙에 삽입
	for value in iterable:
		heapq.heappush(h, -value)
	# 힙에 삽입된 모든 원소를 차례대로 꺼내어 담기
	for i in range(len(h)):
		result.append(-heapq.heappop(h))
	return result

result = heapsort([1, 3, 5, 7, 9, 2, 4, 6, 8, 0])
print(result)  # [9, 8, 7, 6, 5, 4, 3, 2, 1, 0]

2. 다익스트라 알고리즘: 개선된 구현 방법

단계마다 방문하지 않은 노드 중에서 최단 거리가 가장 짧은 노드를 선택하기 위해 힙(Heap) 자료구조를 이용한다.
다익스트라 알고리즘이 동작하는 기본 원리는 동일하다.
- 현재 가장 가까운 노드를 저장해놓기 위해서 힙 자료구조를 추가적으로 이용한다는 점이 다른다.
- 현재의 최단 거리가 가장 짧은 노드를 선택해야 하므로 최소 힙을 사용한다.

3. 다익스트라 알고리즘: 동작 과정 살펴보기 (우선순위 큐)

4. 다익스트라 알고리즘: 개선된 구현 방법(Python)

import heapq
import sys
input = sys.stdin.readline
INF = int(1e9)  # 무한을 의미하는 값으로 10억을 설정

# 노드의 개수, 간선의 개수를 입력받기
n, m = map(int, input().split())
# 시작 노드 번호를 입력받기
start = int(input())
# 각 노드에 연결되어 있는 노드에 대한 정보를 담는 리스트 만들기
graph = [[] for i in range(n + 1)]
# 최단 거리 테이블을 모두 무한으로 초기화
distance = [INF] * (n + 1)

# 모든 간선 정보를 입력받기
for _ in range(m):
	a, b, c = map(int, input().split())
	# a번 노드에서 b번 노드로 가는 비용이 c라는 의미
	graph[a].append((b, c))

def dijkstra(start):
	q = []
	# 시작 노드로 가기 위한 최단 경로는 0으로 설정하여, 큐에 삽입
	heapq.heappush(q, (0, start))
	distance[start] = 0
	while q:  # 큐가 비어있지 않다면
		# 가장 최단 거리가 짧은 노드에 대한 정보 꺼내기
		dist, now = heapq.heappop(q)
		# 현재 노드가 이미 처리된 적이 있는 노드라면 무시
		if distance[now] < dist:
			continue
		# 현재 노드와 연결된 다른 인접한 노드들을 확인
		for i in graph[now]:
			cost = dist + i[1]
			# 현재 노드를 거쳐서, 다른 노드로 이동하는 거리가 더 짧은 경우
			if cost < distance[i[0]]:
				distance[i[0]] = cost
				heapq.heappush(q, (cost, i[0]))

# 다익스트라 알고리즘을 수행
dijkstra(start)

# 모든 노드로 가기 위한 최단 거리를 출력
for i in range(1, n + 1):
	# 도달할 수 없는 경우, 무한(INFINITY)이라고 출력
	if distance[i] == INF:
		print("INFINITY")
	# 도달할 수 ㅇ있는 경우 거리를 출력
	else:
		print(distance[i])

5. 다익스트라 알고리즘: 개선된 구현 방법 성능 분석

힙 자료구조를 이용하는 다익스트라 알고리즘의 시간 복잡도는 O(ElogV)이다.
노드를 하나씩 꺼내 검사하는 반복문(while문)은 노드의 개수 V 이상의 횟수로는 처리되지 않는다.
- 결과적으로 현재 우선순위 큐에서 꺼낸 노드와 연결된 다른 노드들을 확인하는 총횟수는 최대 간선의 개수(E)만큼 연산이 수행될 수 있다.
직관적으로 전체 과정은 E개의 원소를 우선순위 큐에 넣었다가 모두 빼내는 연산과 매우 유사하다.
- 시간 복잡도를 O(ElogE)로 판단할 수 있다.
- 중복 간선을 포함하지 않는 경우에 이를 O(ElogV)로 정리할 수 있다.
  - O(ElogE) → O(ElogV^2) → O(2ElogV) → O(ElogV)

동적계획법 - DP (Dynamic Programming)

ssun_bear — Thu, 11 Jul 2024 22:27:08 +0900

DP

다이나믹 프로그래밍은 다음 조건을 만족할 때 사용할 수 있다.

최적 부분 구조(Optimal Substructure): 큰 문제를 작은 문제로 나눌 수 있다.
중복되는 부분 문제(Overlapping Subproblem): 동일한 작은 문제를 반복적으로 해결한다.

DP 예시

대표적인 문제로는 피보나치 수열이 있다.

(cf. 점화식: 인접항들의 관계식을 의미한다.)

// 피보나치 수열
1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 ...

* 피보나치 수열의 점화식

단순 재귀를 통한 피보나치 수열 구현

* [Python] 단순 재귀를 통한 피보나치 수열

# 피보나치 함수를 재귀함수로 구현
def fibo(x):
	if x == 1 or x == 2:
    	return 1
    return fibo(x-1) + fibo(x-2)
    
print(fibo(4))  # 3

단순 재귀함수로 피보나치 수열을 해결하면 지수 시간 복잡도를 가지게 된다.

아래 이미지와 같이 f(2)가 중복 호출되는 문제가 발생한다.

(cf. 빅오표기법 기준으로 f(30)을 계산하기 위해 약 10억 가량 연산을 수행해야한다.)

메모이제이션(Memoization) - 하향식(Top Down) 방식

메모이제이션은 DP를 구현하는 방법 중 하나이다.
한 번 계산한 결과를 메모리 공간에 메모하는 기법이다.
- 같은 문제를 다시 호출하면 메모했던 결과를 그대로 가져온다.
- 값을 기록해놓는다는 점에서 캐싱(Caching)이라고도 한다.

[Python] Top-Down DP

# 한 번 계산된 결과를 메모이제이션하기 위한 리스트 초기화
d = [0] * 100

# 피보나치 함수를 재귀함수로 구현(탑다운 DP)
def fibo(x):
	# 종료 조건
    if x == 1 or x == 2:
    	return 1
    # 이미 계산한 적 있는 문제라면 그대로 반환
    if d[x] != 0:
    	return d[x]
    # 아직 계산하지 않은 문제라면 점화식에 따라서 피보나치 결과 반환
    d[x] = fibo(x-1) + fibo(x-2)
    return d[x]
    
print(fibo(99))  # 218922995834555169026

[Python] Bottom-UP DP

# 앞서 계산된 결과를 저장하기 위한 DP 테이블 초기화
d = [0] * 100

# 첫번째 피보나치 수와 두번째 피보나치 수는 1
d[1] = 1
d[2] = 1
n = 99

# 피보나치 함수 반복문으로 구현(바텀업 다이나믹 프로그래밍)
for i in range(3, n+1):
	d[i] = d[i-1] + d[i-2]
    
print(d[n])  # 218922995834555169026

DP vs 분할정복

DP와 분할정복은 모두 최적 부분 구조를 가질 때 사용할 수 있다.
- 즉, 큰 문제를 작은 문제로 나눌 수 있으며 작은 문제의 답을 모아서 큰 문제를 해결할 수 있는 상황

DP와 분할정복의 차이점은 부분 문제의 중복이다.
- DP 문제에서는 각 부분 문제들이 서로 영향을 미치며 부분 문제가 중복된다.
- 분할 정복 문제에서는 동일한 부분 문제가 반복적으로 계산되지 않는다.

DP 문제 접근방법

주어진 문제가 DP 유형임을 파악하는 것이 중요하다.
가장 먼저 그리디, 구현, 완전 탐색 등의 아이디어로 문제를 해결할 수 있는지 검토할 수 있다.
- 다른 알고리즘으로 풀이방법이 떠오르지 않는다면 DP를 고려해보자.
일단 재귀함수로 비효율적인 완전 탐색 프로그램을 작성한 뒤에 (탑다운) 작은 문제에서 구한 답이 큰 문제에서 그대로 사용될 수 있으면 코드를 개선하는 방법을 사용할 수 있다.
일반적인 코테 수준에서는 기본 유형의 DP 문제가 출제되는 경우가 많다.

DP 구현 예시

개미전사: 문제설명 (이코테 2021 ch 6. DP 문제 예시)

개미전사는 부족한 식량을 충당하고자 메뚜기 마을의 식량창고를 몰래 공격하려고 한다. 메뚜기 마을에는 여러 개의 식량창고가 있는데 식량창고는 일직선으로 이어져있다.

각 식량창고에는 정해진 수의 식량을 저장하고 있으며 개미전사는 식량창고를 선택적으로 약탈하여 식량을 빼앗을 예정이다.

이때 메뚜기 정찰병들은 일직선상에 존재하는 식량창고 중에서 서로 인접한 식량창고가 공격받으면 바로 알아챌 수 있다.

따라서 개미전사가 정찰병에게 들키지않고 식량창고를 약탈하기 위해서는 최소한 한 칸 이상 떨어진 식량창고를 약탈해야한다.

개미전사: 문제해결 아이디어

예시를 확인해 보자. N = 4일때, 다음과 같은 경우들이 존재할 수 있다.
- 식량을 선택할 수 있는 경우의 수는 다음과 같이 8가지다.
- 7번째 경우에서 8만큼의 식량을 얻을 수 있으므로 최적의 해는 8이다.

[Python] 답안예시

import sys

input = sys.stdin.readline
# 정수 N을 입력받기
n = int(input())
# 모든 식량 정보 입력받기
array = list(map(int, input().split()))

# 앞서 계산된 결과를 저장하기 위한 DP 테이블 초기화
d = [0] * 100

# DP 진행(바텀업)
d[0] = array[0]
d[1] = max(array[0], array[1])
for i in range(2, n):
	d[i] = max(d[i-1], d[i-2] + array[i])
    
# 계산된 결과 출력
print(d[n-1])

파이썬 - 리스트, 집합, 딕셔너리 시간복잡도 정리

ssun_bear — Thu, 11 Jul 2024 17:41:37 +0900

알고리즘을 풀면서 문제를 맞추어도 효율이 안좋은 경우가 종종 있다.

시간복잡도를 최대한 줄여 효율을 끌어올려야 겠다고 생각이 들어 시간복잡도를 정리해본다.

삽입(insert,pop), 제거(delete, remove) , 탐색(check ==,≠) 포함여부 확인( containment(in, not in))의 경우 List는 전부 O(N)이다. Set,Dict은 O(1)혹은 O(len)의 시간을 가지고 있다.

-> 삽입,삭제,탐색,포함여부 확인등의 문제는 list보다 set,dict을 사용하는게 효율면에서 뛰어나다고 생각한다.

List

Set

Dictionary

Chapter 11. 보안과 권한 관리

ssun_bear — Wed, 10 Jul 2024 18:38:37 +0900

보안

비인가자가 데이터베이스에 침입하여 데이터를 유출하거나 손상한다면 조직에 치명적인 손실이 발생함
인가자만 데이터베이스에 접근할 수 있도록 통제하여 보안을 유지하는 일이 무척 중요

보안의 유형

물리적 환경에 대한 보안 - 자연 재해 등으로부터 보호
권한 관리를 통한 보안 - 권한이 없는 사용자로부터 보호
운영 관리를 통한 보안 - 권한이 있는 사용자로부터 보호

권한 관리

DBMS는 보안을 유지하기 위해, 계정이 발급된 사용자가 로그인에 성공했을 경우에만 데이터베이스에 접근이 가능하도록 하는 접근 제어(access control)기능을 기본으로 제공
계정을 생성, 변경, 제거하는 사용자 계정 관리는 DBA가 담당
데이터베이스에 존재하는 모든 객체는 기본적으로 해당 객체를 생성한 사용자만 사용 권한을 지님
필요에 따라 공유할 목적으로 다른 사용자에게 권한을 부여, 취소할 수 있음

권한의 부여

GRANT 권한 ON 객체 TO 사용자 [WITH GRANT OPTION];

일반적으로 테이블에 권한을 부여하는 경우가 많음
주요 권한으로 INSERT, DELETE, UPDATE, SELECT, REFERENCES 가 존재
REFERENCES 권한을 부여 받은 사용자는 대상 테이블의 기본키를 참조하는 외래키를 자신의 테이블에 포함할 수 있음
UPDATE, SELECT는 일부 속성에 대한 권한 부여 가능
모든 사용자들에게 똑같이 부여하고 싶다면 PUBLIC 키워드 이용

※ WITH GRANT OPTION을 포함하여 부여 받은 사용자는 다른 사용자에게도 권한 부여 가능

보안을 강화하기 위해 뷰를 이용할 수 있음
테이블 일부분을 뷰로 생성한 후, 사용자에게 이 뷰에 대한 권한을 부여하는 것도 보안을 유지하는 데 도움이 됨

객체에 대한 권한과 달리 시스템 권한은 DBA가 부여
시스템 권한은 데이터베이스 관리와 관련된 작업 대한 권한, DDL과 관련된 작업에 대한 권한
(객체를 지정할 필요가 없음) - ex) GRANT CREATE TABLE TO mhgo;

권한의 취소

REVOKE 권한 ON 객체 FROM 사용자 CASCADE : RESTRICT;

사용자가 WITH GRANT OPTION으로 인한 추가적인 권한 부여가 되었다면 이를 처리하는 방법이 필요 → 연쇄적으로 취소하고자 하면 CASCADE, 취소하지 않도록 하려면 RESTRICT를 사용
DBA는 각 테이블의 소유주가 사용자들에게 어떤 권한을 부여했는지, WITH GRANT OPTION을 포함하여 권한을 부여했는지 등 권한 목록을 작성해두고 관리하는 것이 필요
DBA가 시스템 권한을 취소할 때도 REVOKE문을 이용
ex)REVOKE CREATE TABLE FROM mhgo;

역할(role)

여러 사용자에게 동일한 권한들을 부여하고 취소하는 번거로운 작업을 편리하게 수행할 수 있도록 도움을 주는 것
새로운 역할을 생성하는 기능은 DBA가 담당 / CREATE ROLE 롤이름;
역할에 필요한 권한들을 넣을 떄는 GRANT 이용 - 테이블 소유자가 수행
역할에 사용자에게 부여, 취소하는 것은 DBA가 담당 / GRANT/REVOKE 롤이름 TO/FROM 사용자;
역할 제거는 DBA가 담당 / DROP ROLE 롤이름;

Chapter 10. 회복과 병행 제어

ssun_bear — Wed, 10 Jul 2024 17:58:01 +0900

회복과 병행 제어

DBMS는 데이터베이스가 항상 정확하고 일관된 상태를 유지할 수 있도록 하는데, 그 중심에는 트랜잭션이 있음
트랜잭션을 관리함으로써 데이터베이스의 회복과 병행 제어가 가능

트랜잭션(transaction)

하나의 작업을 수행하는 데 필요한 데이터베이스의 연산들을 모아놓은 것
데이터베이스에서 논리적인 작업의 단위 (데이터베이스에 장애가 발생했을 때 데이터를 복구하는 작업의 단위)
트랜잭션의 모든 명령문이 완벽하게 처리되거나 하나도 처리되지 않아야 데이터베이스가 모순이 없는 일관된 상태를 유지할 수 있음
데이터베이스의 무결성과 일관성을 보장하려면 필요한 연산들을 하나의 트랜잭션으로 제대로 정의하고 관리해야 함
일반적으로 데이터베이스를 변경하는 INSERT문, DELETE문, UPDATE문의 실행을 트랜잭션으로 관리

트랜잭션의 4가지 특성

ACID - 원자성, 일관성, 격리성, 지속성

원자성(atomicity)

트랜잭션을 구성하는 연산들이 모두 정상적으로 실행되거나 하나도 실행되지 않아야 함
(all or nothing)
원자성을 보장하면 트랜잭션을 구성하는 연산 중 일부만 처리한 결과를 데이터베이스에 반영하는 일이 없게 됨

일관성(consistency)

트랜잭션이 성공적으로 수행된 후에도 데이터베이스가 일관된 상태를 유지해야 함

격리성(isolation) / 고립성

수행 중인 트랜잭션이 완료될 때까지 트랜잭션이 생성한 중간 연산 결과에 다른 트랜잭션들이 접근할 수 없음을 의미함

지속성(durability) / 영속성

트랜잭션이 성공적으로 완료된 후 반영한 수행 결과는 어떠한 경우에도 손실되지 않고 영구적이어야 함을 의미함
시스템에 장애가 발생하더라도 트랜잭션 작업 결과는 없어지지 않고 데이터베이스에 그대로 남아 있어야 한다는 의미

트랜잭션의 특성을 지원하는 DBMS의 기능

트랜잭션의 연산
commit 연산 - 트랜잭션이 성공적으로 수행되었음을 선언 (작업 완료)
rollback 연산 - 트랜잭션을 수행하는 데 실패했음을 선언 (작업 취소)

트랜잭션의 상태

트랜잭션은 다섯 가지 상태 중 하나에 속하게 됨
활동 상태, 부분 완료 상태, 완료 상태, 실패 상태, 철회 상태

활동 상태

트랜잭션이 수행되기 시작하여 현재 수행 중인 상태, 상황에 따라 부분 완료 상태나 실패 상태가 됨

부분 완료 상태

트랜잭션의 마지막 연산이 실행된 직후의 상태, 이는 트랜잭션의 모든 연산을 처리한 상태이며 아직 최종 결과를 데이터베이스에 반영하지 않은 상태, 상황에 따라 완료 상태나 실패 상태가 됨

완료 상태

트랜잭션이 성공적으로 완료되어 commit 연산을 실행한 상태, 트랜잭션이 수행한 최종 결과를 데이터베이스에 반영하고, 데이터베이스가 새로운 일관된 상태가 되면서 트랜잭션이 종료

실패 상태

하드웨어나 소프트웨어의 문제, 트랜잭션 내부의 오류 등 여러 이유로 인해 장해가 발생하여 트랜잭션의 수행이 중단된 상태, 트랜잭션을 더는 정상적으로 수행할 수 없을때 실패 상태가 됨

철회 상태

트랜잭션을 수행하는 데 실패하여 rollback 연산을 실행한 상태, 트랜잭션의 연산을 모두 취소하고 트랜잭션이 수행되기 전의 데이터베이스 상태로 되돌리면서 트랜잭션이 종료, 철회 상태로 종료된 트랜잭션은 상황에 따라 다시 수행되거나 폐기

장애와 회복

데이터베이스가 조직의 주요한 데이터를 저장하고 있는 만큼 데이터베이스 관리 시스템의 회복 기능은 매우 중요
회복은 장애가 발생했을 때 데이터베이스를 장애가 발생하기 전의 일관된 상태로 복구시키는 것장애
시스템이 제대로 동작하지 않는 상태

장애의 유형

트랜잭션 장애

의미 - 트랜잭션 수행 중 오류가 발생하여 정상적으로 수행을 계속할 수 없는 상태
원인 - 트랜잭션의 논리적 오류, 잘못된 데이터 입력,시스템 자원의 과다 사용 요구, 처리 대상 데이터의 부재 등

시스템 장애

의미 - 하드웨어 결함으로 정상적으로 수행을 계속할 수 없는 상태
원인 - 하드웨어 이상으로 메인 메모리에 저장된 정보가 손실되거나 교착 상태가 발생한 경우

미디어 장애

의미 - 디스크 장치의 결합으로 디스크에 저장된 데이터베이스의 일부 혹은 전체가 손상된 상태
원인 - 디스크 헤드의 손상이나 고장 등

데이터베이스의 저장 연산

데이터베이스는 기본적으로 비휘발성 저장 장치인 디스크에 상주
트랜잭션이 데이터베이스의 데이터를 처리하려면, 데이터를 디스크에서 휘발성 저장 장치인 메인 메모리로 가져와 이를 처리한 후 그 결과를 다시 디스크로 보내는 작업이 필요
디스크와 메인 메모리 간의 데이터 이동은 대개 블록(block) 단위로 수행
디스크 블록(디스크), 버퍼 블록(메인 메모리)
디스크와 메인 메모리 간의 데이터 이동은 input(X)(디스크 블록 > 버퍼 블록), output(X)(버퍼 블록 > 디스크 블록) 두 연산으로 수행
메인 메모리와 응용 프로그램 간의 데이터 이동은 read(X)(버퍼 블록 > 변수), write(X)(변수 > 버퍼 블록) 두 연산으로 수행

회복 기법

회복

데이터베이스에 장애가 발생했을 때 장애가 발생하기 전의 모순이 없고 일관된 상태로 복구시키는 것이며, DBMS의 회복관리자가 담당
장애가 일어난 데이터베이스를 복구하는 동안에는 데이터베이스에 접근하여 업무를 처리할 수 없으므로, 회복시키는 작업은 빠른 시간 내에 이루어져야 함

회복을 위한 연산

데이터베이스 회복의 핵심 원리는 데이터 중복
데이터를 별도의 장소에 미리 복사해두고, 장애로 문제가 발생했을 때 복사본을 이용해 원래의 상태로 복원하는 것
덤프나 로그 방법을 사용해 데이터를 복사해두었다가 회복시킬 때 사용
덤프(dump) - 데이터베이스 전체를 다른 저장 장치에 주기적으로 복사하는 방법
로그(log) - 데이터베이스에서 변경 연산이 실행될 때마다 데이터를 변경하기 이전 값과 변경한 이후의 값을 별도의 파일에 기록하는 방법
장애가 발생했을 때, 덤프나 로그 방법으로 데이터베이스를 복구하는 가장 기본적인 방법은 redo나 undo 연산을 실행하는 것
redo(재실행) - 가장 최근에 저장한 데이터베이스 복사본을 가져온 후 로그를 이용해 복사본이 만들어진 이후에 실행된 모든 변경 연산을 재실행 > 장애 발생 직전까지 복구, 전반적으로 손상된 경우에 주로 사용
undo(취소) - 로그를 이용해 지금까지 실행된 모든 변경 연산을 취소하여 데이터베이스 복구, 변경 중이었거나 이미 변경된 내용만 신뢰성을 잃은 경우에 주로 사용
redo와 undo를 실행하는 데는 로그가 중요하게 사용됨
로그를 저장한 파일을 로그 파일이라 하며 로그 파일은 레코드 단위로 기록됨

데이터베이스 회복 기법

로그 회복 기법, 검사 시점 회복 기법, 미디어 회복 기법이 존재

로그 회복 기법

데이터를 변경한 연산 결과를 데이터베이스에 반영하는 시점에 따라 즉시 갱신 회복 기법과 지연 갱신 회복 기법으로 나눔

즉시 갱신 회복 기법 (immediate update)

트랜잭션 수행 중에 데이터를 변경한 연산의 결과를 데이터베이스에 즉시 반영하고 데이터 변경에 대한 내용을 로그 파일에도 기록
데이터베이스 회복 시 로그를 정상적으로 사용하려면, 트랜잭션에서 데이터 변경 연산이 실행되었을 때 로그 파일에 로그 레코드를 먼저 기록한 후 데이터베이스 변경 연산을 반영
로그 파일에 기록된 내용을 참조하여, 장애 발생 시점에 따라 redo나 undo 연산을 실행하여 데이터베이스를 복구
commit 이전 > undo연산 / commit 이후 > redo연산
redo와 undo가 모두 필요할 때는 undo를 먼저 실행한 후 redo를 실행

지연 갱신 회복 기법 (deferred update)

트랜잭션이 수행되는 동안에는 데이터 변경 연산의 결과를 데이터베이스에 즉시 반영하지 않고 로그 파일에만 기록해두었다가, 트랜잭션이 부분 완료된 후에 로그에 기록된 내용을 이용해 데이터베이스에 한 번에 반영
트랜잭션이 수행되는 동안 장애가 발생할 경우 로그에 기록된 내용을 버리기만 하면 됨
undo연산은 필요 없고 redo연산만 필요하므로 로그 레코드에 변경 이전 값을 기록할 필요가 없음

검사 시점 회복 기법의 등장 배경
로그 회복 기법은 로그 전체를 분석하여 로그에 기록된 모든 트랜잭션을 대상으로 적용할 회복 연산을 결정
데이터베이스 회복에 많은 시간이 걸리고 redo를 수행할 필요가 없는 트랜잭션에도 redo를 실행하는 일이 발생
이런 비효율성을 해결하기 위해 제안된 방법 > 검사 시점 회복 기법

검사 시점 회복 기법

로그 회복 기법과 같은 방법으로 로그 기록을 이용하되, 일정 시간 간격으로 검사 시점(check point)을 제작, 장애가 발생하면 가장 최근 검사 시점 이후의 트랜잭션만 회복 작업을 수행
회복 작업의 범위가 검사 시점으로 정해지므로 데이터베이스 회복 시간이 단축된다는 장점 존재
검사 시점을 표시하는 <checkpoint L> 형식의 로그 레코드를 기록하고 이를 이용해 회복 작업의 범위가 정해지면 즉시 갱신 회복 기법이나 지연 갱신 회복 기법을 이용해 회복 작업 수행

미디어 회복 기법

데이터베이스는 디스크에 저장되는데 디스크 헤더의 고장과 같은 원인으로 장애가 발생할 수 있음
이에 대비한 회복 기법이 미디어 회복 기법
전체 데이터베이스의 내용을 일정 주기마다 다른 안전한 저장 장치에 복사해두는 덤프를 이용, 장애가 발생하면 가장 최근에 복사해둔 덤프를 이용해 복구
전체 데이터베이스를 다른 저장 장치에 복사하는 것은 비용이 많이 들고, 복사하는 동안 트랜잭션 수행이 중단되기에 CPU가 낭비된다는 단점 존재

병행 수행(concurrency)

여러 개의 트랜잭션이 동시에 수행되는 것, 인터리빙(interleaving) 방식으로 진행
인터리빙 - 트랜잭션이 번갈아가며 조금씩 처리를 수행하는 것
병행 수행되는 트랜잭션들이 동시에 같은 데이터에 접근하여 변경 연산을 실행하려고 하면 예상치 못한 결과가 발생 가능
병행 수행을 하더라도 각 트랜잭션이 다른 트랜잭션의 방해를 받지 않고 정확한 수행 결과를 얻을 수 있도록 제어해야 함

병행 수행의 문제

병행 수행을 특별한 제어 없이 진행하면 갱신 분실, 모순성, 연쇄 복귀의 문제가 발생할 수 있음

갱신분실(lost update)

하나의 트랜잭션이 수행한 데이터 변경 연산의 결과를 다른 트랜잭션이 덮어써 변경 연산이 무효화되는 것

모순성(inconsistency)

하나의 트랜잭션이 여러 개의 데이터 변경 연산을 수행할 때 일관성 없는 상태의 데이터베이스에서 데이터를 가져와 연산을 실행함으로써 모순된 결과가 발생하는 것

연쇄 복귀(cascading rollback)

트랜잭션이 완료되기 전에 장애가 발생하여 rollback연산을 수행하면, 이 트랜잭션이 장애 발생 전에 변경한 데이터를 가져가 사용한 다른 트랜잭션에도 rollback연산을 연쇄적으로 실행해야 한다는 것

트랜잭션 스케줄

트랜잭션이 인터리빙 방식으로 진행되는데 이는 트랜잭션에 있는 연산을 실행하는 순서에 따라 트랜잭션들의 수행 결과가 달라지기도 하고, 병행 수행에 따른 문제가 발생하기도 하기에 트랜잭션 스케줄이 필요트랜잭션 스케줄 - 트랜잭션에 포함되어 있는 연산들을 수행하는 순서

트랜잭션 스케줄의 유형

직렬 스케줄 - 인터리빙 방식을 이용하지 않고 각 트랜잭션별로 연산을 순차적으로 실행
비직렬 스케줄 - 인터리빙 방식을 이용하여 트랜잭션들을 병행해서 수행
직렬 가능 스케줄 - 직렬 스케줄과 같이 정확한 결과를 생성하는 비직렬 스케줄

직렬 스케줄

직렬 스케줄의 수행 순서에 따라 최종 수행 결과가 달라질 수 있음
모든 트랜잭션이 완료될 때까지 다른 트랜잭션의 방해를 받지 않고 독립적으로 수행, 모순이 없는 정확한 결과
트랜잭션을 독립적으로 수행하기 때문에 병행 수행이라 할 수 없고 일반적으로 잘 사용하지 않음

비직렬 스케줄

트랜잭션이 돌아가면서 연산을 실행, 여러 트랜잭션을 병행 수행하기에 최종 수행 결과의 정확성을 보장할 수 없음
어떤 비직렬 스케줄을 선택하여 트랜잭션들을 수행하느냐가 중요

직렬 가능 스케줄

비직렬 스케줄 중에서 결과가 동일한 직렬 스케줄이 없는 것은 결과의 정확성을 보장할 수 없기에 직렬 가능 스케줄이 아님
직렬 가능 스케줄인지 여부를 판단하는 일은 쉽지 않기에 대부분 DBMS에서는 직렬 가능성을 보장하는 병행 제어 기법을 사용

병행 제어(concurrency control), 동시성 제어

여러 개의 트랜잭션이 병행 수행되더라도, 문제 없이 정확한 수행 결과를 얻을 수 있도록 트랜잭션의 수행을 제어하는 것

병행 제어 기법

여러 트랜잭션을 병행 수행하면서도 정확한 결과를 얻을 수 있는 직렬 가능성을 보장받기 위해 사용
모든 트랜잭션이 원리를 따르면 직렬 가능성이 보장되는 규약을 정의하고 트랜잭션들이 이 규약을 따르도록 하는 것병행 제어 기법 중 로킹 기법이 가장 많이 사용된다

로킹 기법(locking)

병행 수행되는 트랜잭션들이 동일한 데이터에 동시에 접근하지 못하도록 lock과 unlock이라는 연산을 이용해 제어
트랜잭션 간 상호 배제하여 직렬 가능성을 보장하는 것
사용하는 연산
- lock - 데이터에 대한 독점권 보장
- unlock - 데이터에 대한 독점권 포기

기본 로킹 규약

반드시 read 또는 write 연산을 실행하기 전에 lock 연산을 실행해야 함
다른 트랜잭션이 이미 lock 연산을 실행한 데이터에는 다시 lock 연산이 실행될 수 없음
모든 연산을 수행하고 나면 unlock 연산을 실행해서 독점권을 반납해야 함

lock 연산은 다양한 크기의 데이터를 대상으로 실행할 수 있음
전체 데이터베이스에 lock 연산을 실행하면 제어가 간단하지만 하나의 트랜잭션만 수행되므로 병행 수행이라 할 수 없음
속성에 lock 연산을 하면 많은 수의 트랜잭션이 병행 수행할 수 있지만 제어가 복잡함
즉, 시스템에 따라 적절한 로킹 단위를 선택하는 것이 중요

기본 로킹 기법

병행 수행을 제어, 엄격한 제약으로 어떤 순간이든 데이터 독점을 하나의 트랜잭션만 가능
write는 엄격해야 함, read는 동시에 실행해도 문제가 없음 -> 공용, 전용 lock
- 공용 lock – read는 가능하지만 write는 불가(데이터에 대한 사용권을 여러 트랜잭션이 지님)
- 전용 lock – read, write 가능, 다른 트랜잭션은 접근 불가
하지만 이러한 기본 로킹 규약만으로는 트랜잭션 스케쥴의 직렬 가능성을 완벽히 보장할 수 없음

2단계 로킹 규약(2PLP)

트랜잭션 스케줄의 모든 트랜잭션이 2단계 로킹 규약을 준수하면 해당 스케줄은 직렬 가능성이 보장됨
확장단계(lock만 가능), 축소단계(unlock만 가능)로 나누어 실행
교착 상태(deadlock)가 발생할 수 있음
교착 상태는 처음부터 발생하지 않도록 사용자가 예방하거나, 발생했을 때 빨리 탐지하여 필요한 조치를 취하는 방법으로 해결해야 함

Chapter 9. 정규화

ssun_bear — Wed, 10 Jul 2024 16:52:07 +0900

정규화의 개념과 이상 현상

정규화(normalization)

데이터베이스를 잘못 설계하면 데이터의 삽입, 수정, 삭제 연산을 수행할 때 부작용(이상현상 (anomaly))이 발생
정규화는 이상 현상이 발생하지 않도록 릴레이션을 분해(decomposition)하는 과정을 의미
데이터베이스를 설계한 후 설계 결과물을 검증하기 위해 사용하기도 함

이상 현상의 종류

삽입 이상(insertion anomaly) - 새 데이터를 삽입하기 위해 불필요한 데이터도 함께 삽입해야 하는 문제
갱신 이상(update anomaly) - 중복 투플 중 일부만 변경되어 데이터가 불일치하게 되는 모순의 문제
삭제 이상(deletion anomaly) - 투플을 삭제하면 필요한 다른 데이터까지 함께 삭제되는 데이터 손실의 문제

정규화의 필요성

관련 없는 속성들을 하나의 릴레이션에 모아두고 있으면 여러 이상 현상이 발생
정규화를 수행하기 위해선 속성들 간의 관련성인 함수적 종속성(Functional Dependency)을 판단해야 함
일반적으로 릴레이션에 함수적 종속성이 하나 존재하도록 정규화를 통해 릴레이션을 분해

함수 종속

하나의 릴레이션을 구성하는 속성들의 부분 집합을 X와 Y라 할 때, 어느 시점에서든 릴레이션 내의 모든 투플에서 하나의 X의 값에 대한 Y의 값이 항상 하나면'X가 Y를 함수적으로 결정한다' 또는 'Y가 X에 함수적으로 종속되어 있다' 라고 함
X -> Y (X는 결정자, Y는 종속자)
함수 종속 관계는 현재 시점에 릴레이션에 포함된 속성 값만으로 판단하면 안 된다는 것을 유의해야 함
릴레이션에서 속성 값은 계속 변할 수 있기 때문에 속성 자체가 가지고 있는 특성과 의미를 기반으로 판단해야 함
- 완전 함수 종속 (Full Functional Dependency)
  릴레이션에서 속성 집합 Y가 속성 집합 X에 종속되어 있지만, 속성 집합 X의 일부분에 종속된 것이 아님을 의미
- 부분 함수 종속 (Partial Functional Dependency)
  속성 집합 Y가 속성 집합 X의 전체가 아닌 일부분에도 함수적으로 종속됨을 의미
  일반적으로 함수 종속이라고 하면 완전 함수 종속을 의미

정규형의 종류

릴레이션이 정규화된 정도는 정규형(Normal Form)으로 표현
정규형은 크게 기본 정규형과 고급 정규형으로 나뉨
- 기본 정규형 - 제1정규형, 제2정규형, 제3정규형, 보이스/코드 정규형
- 고급 정규형 - 제4정규형, 제5정규형
각 정규형마다 만족시켜야 하는 제약조건이 존재
릴레이션이 특정 정규형의 제약조건을 만족하면 릴레이션이 해당 정규형에 속한다고 표현
정규형의 차수가 높아질수록 요구되는 제약조건이 많아지고 엄격해짐
일반적으로 차수가 높은 정규형에 속하는 릴레이션일수록 바람직한 릴레이션이나, 모든 릴레이션이 제5정규형에 속해야 되는 것은 아니기에 릴레이션의 특성을 고려해서 적합한 정규형을 선택

제1정규형(1NF)

릴레이션에 속한 모든 속성의 도메인이 원자 값으로만 구성되어 있어야 함
최소한 제1정규형을 만족해야 관계 데이터베이스의 릴레이션이 될 자격이 있음
삽입 이상, 갱신 이상, 삭제 이상 발생
릴레이션이 부분 함수 종속을 포함하고 있기 때문

제2정규형(2NF)

릴레이션이 제1정규형에 속하고, 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속되야 함

정규화 과정에서 릴레이션을 분해할 때 주의할 점
분해된 릴레이션들을 자연 조인하여 분해 전의 릴레이션으로 다시 복원할 수 있어야 한다는 것
- 무손실 분해(nonloss decomposition)
릴레이션을 분해했을 때 정보 손실이 발생하지 않아야 함

삽입 이상, 갱신 이상, 삭제 이상 발생
릴레이션이 함수적 종속 관계를 여러 개 포함하고 있어 이행적 함수 종속이 존재하기 때문

제3정규형(3NF)

릴레이션이 제2정규형에 속하고, 기본키가 아닌 모든 속성이 기본키에 이행적 함수 종속이 되지 않아야 함

이행적 함수 종속(transitive FD)
속성집합 X, Y, Z가 존재하고 X->Y, Y->Z 일때, 논리적으로 X->Z가 성립
이때 Z가 X에 이행적으로 함수 종속 되었다고 함
함수 종속 관계가 하나의 릴레이션에 여러 개 존재하면 이행적 함수 종속이 나타남

후보키를 여러 개 가지고 있는 릴레이션의 경우 이상현상 발생할 수 있음 따라서 제3정규형도 이상 현상이 발생하는 경우 존재

보이스/코드 정규형(BCNF)

릴레이션의 함수 종속 관계에서 모든 결정자가 후보키가 되어야 함 (강한 제3정규형)
보이스/코드 정규형에 속하는 모든 릴레이션은 제3정규형에 속하지만, 제3정규형에 속한다고 보이스/코드 정규형에 속하는 것은 아님

3NF → BCNF

제4정규형(4NF)

릴레이션이 보이스/코드 정규형을 만족하면서, 다치 종속(Multi Valued Dependency)을 제거해야 만족

제5정규형(5NF)

릴레이션이 제4정규형을 만족하면서 후보키를 통하지 않는 조인 종속(Join Dependency)을 제거해야 만족

실제로 설계 시 무조건 제5정규형에 속하도록 분해해야 하는 것은 아니며, 오히려 제5정규형까지 분해하면 비효율적이고 바람직하지 않은 경우가 존재
일반적으로 제3정규형이나 보이스/코드 정규형에 속하도록 릴레이션을 분해하여 데이터 중복을 줄이고 이상 현상을 해결함

Chapter 8. 데이터베이스 설계

ssun_bear — Wed, 10 Jul 2024 16:15:33 +0900

다양한 요구 사항을 모두 만족시키는 데이터베이스를 구축하는 일은 어려움
저장해야 하는 데이터의 양이 많고 사용자 수가 많은 조직일수록 어렵고 복잡
사용자들의 요구 사항을 잘 분석하고, 분석한 결과를 바탕으로 데이터베이스의 논리적, 물리적 구조를 제대로 설계해야할 필요성 존재

데이터베이스 설계

사용자들의 요구 사항을 고려하여 데이터베이스를 생성하는 과정
데이터베이스는 구조를 변경하기 어렵기 때문에 설계 과정에서부터 품질 좋은 데이터베이스를 생성해야 됨품질 기준
사용하는 구성원들의 요구 사항을 만족하는지, 데이터의 일관성과 무결성, 사용자가 이해하기 쉽고 접근성이 좋은지 ... etc

데이터베이스 설계 방식

E-R모델과 릴레이션 변환 규칙을 이용한 데이터베이스 설계와 정규화를 이용한 데이터베이스 설계

데이터베이스 설계 과정

요구 사항 분석 > 개념적 설계 > 논리적 설계 > 물리적 설계 > 구현

요구 사항 분석

조직의 구성원들이 데이터베이스를 사용하는 용도를 파악
수집한 다양한 요구 사항을 분석하여 그 결과를 요구 사항 명세서로 작성하는 것이 주요 작업
먼저 데이터베이스를 사용할 주요 사용자의 범위부터 결정하여 불필요한 요구 사항을 수집하지 않도록 함
요구 사항 분석이 잘못되면 사용자가 원치 않는 데이터베이스가 개발되어, 고치거나 다시 개발하는 수고가 뒤따를 수 있음 (신중하고 꼼꼼하게 작업해야 함)

개념적 설계

요구 사항 분석 단계의 결과물인 명세서를 바탕으로 개념적 구조를 설계
사용자의 요구 사항을 개념적 데이터 모델을 이용해 표현 / 일반적으로 E-R모델로 설계하며 E-R 다이어그램으로 표현하는 것이 주요 작업
요구 사항 명세서 → 개념적 데이터 모델 = 개념적 모델링개체와 속성 추출 - 일반적으로 요구 사항의 문장에서 명사
관계 추출 - 일반적으로 요구 사항을 표현한 문장에서 동사

논리적 설계

개발에 사용할 DBMS에 적합한 논리적 데이터 모델을 이용해 개념적 구조를 기반으로 논리적 구조를 설계
일반적으로 관계 데이터 모델을 사용하며, E-R 다이어그램을 릴레이션 스키마로 변환하는 것이 주요 작업
변환 시 고려할 사항이 많음
개념적 데이터 모델 → 논리적 데이터 모델 = 논리적 모델링
1. 모든 개체는 릴레이션으로 변환한다
2. 다대다 관계는 릴레이션으로 변환한다
3. 일대다 관계는 외래키로 표현한다
  3-1 일반적인 일대다 관계는 외래키로 표현한다
  3-2 약한 개체가 참여하는 일대다 관계는 외래키를 포함해서 기본키로 지정한다
4. 일대일 관계는 외래키로 표현한다
  4-1 일반적인 일대일 관계는 외래키를 서로 주고받는다
  4-2 일대일 관계에 필수적으로 참여하는 개체의 릴레이션만 외래키를 받는다
  4-3 모든 개체가 일대일 관계에 필수적으로 참여하면 릴레이션 하나로 합친다
5. 다중 값 속성은 릴레이션으로 변환한다
6. 기타 고려 사항
  - 속성이 많은 관계는 관계 유형에 상관없이 릴레이션으로 변환하는 것을 고려할 수 있음
  다만 릴레이션의 개수가 많으면 DBMS의 부담이 커짐, 릴레이션의 개수가 불필요하게 늘어나지 않도록 관리
릴레이션 스키마 변환 규칙

물리적 설계

논리적 구조를 기반으로 물리적 구조를 설계
저장 장치에 적합한 저장 레코드와 인덱스의 구조 등을 설계하고, 저장된 데이터와 인덱스에 빠르게 접근하게 할 수 있는 탐색 기법 등을 정의
데이터베이스를 실제로 구축할 컴퓨터 시스템의 저장 장치와 운영체제의 특성을 고려하여 물리적인 구조를 설계하는 것이 주요 작업
응답 시간을 최소화하고 저장 공간을 효율적으로 활용하면서 데이터베이스 시스템의 처리 능력을 향상시킬 수 있도록 설계

구현

이전 설계 단계의 결과물을 기반으로 DBMS에서 SQL로 작성한 명령문을 실행하여 데이터베이스를 실제로 생성
데이터 정의어(DDL) 사용

※ 모든 단계가 중요하지만, 그 중에서 데이터베이스의 개념적 구조와 논리적 구조를 설계하는 요구 사항 분석, 개념적 설계, 논리적 설계 단계가 핵심

Chapter 7. 데이터베이스 언어 SQL

ssun_bear — Wed, 10 Jul 2024 15:39:42 +0900

SQL

관계 데이터베이스를 위한 표준 질의어로 많이 사용되는 언어
사용자가 처리를 원하는 데이터가 무엇인지만 제시하고 어떻게 처리해야 하는지 절차를 언급할 필요가 없음 (비절차)
DBMS에 직접 접근하여 대화식으로 질의를 작성, C나 Java 같은 언어로 작성한 응용 프로그램에 삽입하여 사용

SQL의 분류

데이터 조작어, 데이터 정의어, 데이터 제어어

모든 SQL 문은 ;으로 문장 끝을 표시, SQL 문에 사용되는 키워드는 대소문자를 구분하지 않음

SQL을 이용한 데이터 정의

테이블 생성, 생성된 테이블 구조의 변경, 테이블 삭제로 분류

테이블 생성 - CREATE TABLE

생성할 테이블을 구성하는 속성들의 이름, 데이터 타입 및 제약 사항에 대한 정의, 기본키/대체키/외래키의 정의, 데이터 무결성을 위한 제약조건의 정의 등을 포함
1)은 테이블을 구성하는 각 속성의 이름과 데이터 타입, 기본적인 제약 사항을 정의
2)는 기본키로 테이블에 하나만 존재
3)은 대체키로 테이블에 여러 개 존재 가능
4)는 외래키로 테이블에 여러 개 존재 가능
5)는 데이터 무결성을 위한 제약조건으로 여러 개 존재 가능

CREATE TABLE 테이블_이름 (
1) 속성_이름 데이터_타입 [NOT NULL] [DEFAULT]
2) [PRIMARY KEY (속성_리스트)]
3) [UNIQUE (속성_리스트)]
4) [FOREIGN KEY (속성_리스트) REFERENCES 테이블_이름(속성_리스트)] [ON DELETE 옵션] [ON UPDATE 옵션]
5) [CONSTRAINT 이름] [CHECK (조건)]
);

속성의 정의

CREATE TABLE 문으로 생성되는 테이블을 구성하는 속성은 기본적으로 널 값이 허용, 허용하지 않는 속성을 정의하려면 NOT NULL 명시 (기본키 - 개체 무결성 제약조건, 꼭 입력해야 된다고 판단되는 속성)
DEFAULT로 기본 값을 지정 가능, 숫자는 그대로 표현, 문자열이나 날짜는 작은따옴표 내에 표기

키의 정의

기본키, 대체키, 외래키를 지정할 수 있음
- PRIMARY KEY로 기본키 설정(없어도 가능하나 선택하는 것이 좋음)
- UNIQUE로 대체키 설정(여러 개 가능)
- FOREIGN KEY로 외래키 설정(지정할 때는 출처를 분명히 해야함 REFERENCES를 제시 - 참조 무결성 제약조건을 유지하기 위함)
참조되는 테이블에서 투플을 삭제하거나 변경할 때 처리하는 방식
NO ACTION - 기본 설정, 투플을 삭제/변경하지 못하게 함
CASCADE - 관련 투플을 함께 삭제/변경
SET NULL - 관련 투플의 외래키 값을 NULL로 변경
SET DEFAULT - 관련 투플의 외래키 값을 미리 지정한 기본 값으로 변경
데이터 무결성 제약조건의 정의
CHECK를 사용해 특정 속성에 대한 제약조건을 지정할 수 있음 (CHECK로 지정한 제약조건을 만족하는 투플만 존재)
CONSTRAINT로 CHECK에 고유한 명칭 부여 가능, 이후에 제약조건을 수정하거나 제거할 때 식별하기가 쉬움

테이블 변경 - ALTER TABLE

새로운 속성 추가, 기존 속성 삭제, 새로운 제약조건 추가, 기존 제약조건 삭제 등이 가능

새로운 속성 추가

ALTER TABLE 테이블_이름 ADD 속성_이름 데이터_타입 [NOT NULL] [DEFAULT];

기존 속성 삭제

ALTER TABLE 테이블_이름 DROP COLUMN 속성_이름;

새로운 제약조건 추가

ALTER TABLE 테이블_이름 ADD CONSTRAINT 제약조건_이름 제약조건_내용;

기존 제약조건 삭제

ALTER TABLE 테이블_이름 DROP CONSTRAINT 제약조건_이름;

테이블 삭제 - DROP TABLE

삭제할 테이블을 참조하는 테이블이 있다면 삭제가 수행되지 않음, 삭제하고자 하는 테이블을 참조하는 외래키 제약조건을 먼저 삭제해야 함

SQL을 이용한 데이터 조작

데이터 검색, 새로운 데이터 삽입, 데이터 수정, 데이터 삭제로 분류

데이터 검색 - SELECT

다양한 검색 유형을 지원하며, 일반 사용자들이 가장 많이 사용

기본검색

SELECT [ALL or DISTINCT] 속성_리스트
FROM 테이블_리스트;

테이블과 속성 모두 여러 개를 검색하고 싶을 경우 ,로 구분하여 나열
테이블에 존재하는 모든 속성을 검색하기 위해 SELECT *를 사용할 수 있음
ALL은 기본 설정이지만 명시적 표시 가능, 중복 제거를 위해 DISTINCT 사용
AS 키워드를 통해 출력되는 결과 테이블의 이름 수정 가능

산술식을 이용한 검색

SELECT 키워드와 함께 산술식을 제시할 수 있지만 실제로 값이 변경되는 것은 아니며 결과 테이블만 변경돼서 출력

조건검색

SELECT [ALL or DISTINCT] 속성_리스트
FROM 테이블_리스트
[WHERE 조건];

WHERE절 안에 비교 연산자와 논리 연산자를 이용한 검색 조건 제시

LIKE를 이용한 검색

검색 조건을 부분적으로만 알 경우 LIKE 키워드를 이용해 검색, 단 문자열을 이용하는 조건에서만 사용
- % - 0개 이상의 문자, _ - 1개의 문자
  LIKE 'DATA%' - DATA로 시작하는 문자열
  LIKE '__A%' - 세 번째 글자가 'A'인 문자열

NULL을 이용한 검색

검색 조건에서 특정 속성의 값이 널 값인지를 비교하려면 IS NULL 사용
반대의 경우엔 IS NOT NULL / '이름 = NULL' 형태로 표현하면 안됨

정렬 검색

SELECT [ALL or DISTINCT] 속성_리스트
FROM 테이블_리스트
[WHERE 조건]
[ORDER BY 속성_리스트 [ASC or DESC] ];

일반적으로 SELECT를 통한 결과 테이블은 DBMS가 정한 순서로 출력되기에 사용자가 원하는 순서로 출력하기 위해선 ORDER BY를 사용함
- 오름차순 정렬 - ASC (기본 정렬)
- 내림차순 정렬 - DESC

집계 함수를 이용한 검색

특정 속성 값을 통계적으로 계산한 결과를 검색하기 위해 이용
열 함수라고도 하며 개수, 합계, 평균, 최댓값, 최솟값 계산 기능 제공
SUM, AVG는 숫자 데이터 타입만 COUNT, MAX, MIN 모든 데이터(MAX, MIN에서 문자열은 사전의 역/정순서와 같은 방식으로 비교)COUNT 함수 - 테이블의 모든 속성에 적용하여 개수를 계산할 수 있음
개수를 정확히 계산하려면 널 값이 없는 속성에 COUNT 함수를 적용하는 것이 좋기에 기본키 속성이나 *를 이용
DISTINCT를 사용하여 특정 속성 값의 중복 제거 가능
※주의 사항 - 널인 속성 값은 제외하고 계산, WHERE절에서는 사용할 수 없고 SELECT절이나 HAVING절에서만 사용
집계 함수를 이용해 계산된 결과 값을 출력할 때는 AS 키워드를 사용해 새 이름을 부여하는게 좋음

그룹별 검색

테이블에서 특정 속성의 값이 같은 투플을 모아 그룹을 만들고, 그룹별로 검색을 하기 위해 GROUP BY를 사용
그룹에 대한 조건을 추가하려면 GROUP BY와 HAVING을 함께 사용
GROUP BY가 없는 SELECT문은 테이블 전체를 하나의 그룹으로 간주

SELECT [ALL or DISTINCT] 속성_리스트
FROM 테이블_리스트
[WHERE 조건]
[GROUP BY 속성_리스트 [HAVING 조건] ]
[ORDER BY 속성_리스트 [ASC or DESC] ];

그룹을 나누는 기준이 되는 속성을 SELECT절에 작성하지 않으면 어떤 그룹에 대한 검색 결과인지 확인하기 어려움
그룹별 검색할 때 집계 함수나 GROUP BY절에 있는 속성 외의 속성은 SELECT절에 사용할 수 없음
여러 그룹으로 나눌 경우 기준이 되는 속성을 GROUP BY절에 순서대로 작성

여러 테이블에 대한 조인 검색

여러 개의 테이블을 연결하여 데이터를 검색하는 것
조인 검색을 하려면 테이블을 연결해주는 속성이 필요 > 조인 속성(일반적으로 외래키를 사용) 도메인은 반드시 같아야 함
조인 검색을 위한 SQL문은 FROM절에서 검색에 필요한 모든 테이블을 나열, WHERE절에는 조인 속성의 값이 같아야 함을 의미하는 조인 조건을 제시
테이블 이름이 길면 속성 이름 앞에 소속 테이블을 표기하는 일이 번거로울 수 있음 따라서 FROM절에 테이블 이름과 별명을 함께 제시 가능 (AS생략 가능)

서브쿼리(부속 질의문)를 이용한 검색

SELECT문 안에 또 다른 SELECT문 - 부속 질의문(sub query)
서브쿼리는 괄호로 묶어 작성하고, ORDER BY절을 사용할 수 없으며, 상위 질의문보다 먼저 수행
단일 행 서브쿼리(결과 값을 하나만 반환), 다중 행 서브쿼리(결과 값을 여러 개 반환) 존재
단일 행 서브쿼리는 일반 비교 연산자를 사용할 수 있으나 다중 행 서브쿼리는 사용할 수 없음
다중 행 서브쿼리와 함께 사용할 수 있는 연산자
- IN - 서브쿼리의 결과 값 중 일치하는 것이 있으면 검색 조건이 참
- NOT IN - 서브쿼리의 결과 값 중 일치하는 것이 없으면 검색 조건이 참
- EXISTS - 서브쿼리의 결과 값이 하나라도 존재하면 검색 조건이 참
- NOT EXISTS - 서브쿼리의 결과 값이 하나라도 존재하지 않으면 검색 조건이 참
- ALL - 서브쿼리의 결과 값 모두와 비교한 결과가 참이면 검색 조건을 만족
  (비교 연산자와 함께 사용)
- ANY or SOME - 서브쿼리의 결과 값 중 하나라도 비교한 결과가 참이면 검색 조건을 만족
  (비교 연산자와 함께 사용)

데이터 삽입 - INSERT

데이터 삽입은 직접 삽입과 서브쿼리를 이용해 삽입하는 방식으로 나뉨

데이터 직접 삽입

INSERT
INTO 테이블_이름[(속성_리스트)]
VALUES (속성값_리스트);

INTO 절에서 속성 이름의 리스트는 생략 가능하지만 생략한 경우 테이블을 정의할 때 지정한 속성의 순서대로 VALUES 절의 속성 값이 삽입됨
VALUES절에 나열되는 속성 값은 문자나 날짜 타입의 데이터인 경우 작은따옴표로 묶음

서브쿼리를 이용한 데이터 삽입

INSERT
INTO 테이블_이름[(속성_리스트)]
SELECT 문;

데이터 수정 - UPDATE

UPDATE 테이블_이름
SET 속성_이름1 = 값1, 속성_이름2 = 값2, ...
[WHERE 조건];

WHERE절을 생략하면 테이블에 존재하는 모든 투플을 대상
UPDATE문에 서브쿼리가 포함되는 경우도 존재

데이터 삭제 - DELETE

DELETE
FROM 테이블_이름
[WHERE 조건];

WHERE절을 생략하면 테이블에 존재하는 모든 투플을 삭제하여 빈 테이블이 됨
(DROP TABLE과 다름)

뷰

뷰는 다른 테이블을 기반으로 만들어진 가상 테이블
일반 테이블과 달리 데이터를 실제로 저장하고 있지 않음
일반적으로 뷰는 기본 테이블을 기반으로 만들어지지만 다른 뷰를 기반으로 만들 수 있음
동일한 테이블도 어떤 뷰로 보느냐에 따라 보이는 부분이 달라짐
뷰를 통해 내용을 쉽게 검색할 수는 있지만 기본 테이블의 내용을 바꾸는 작업은 제한적

뷰 생성

CREATE VIEW 뷰_이름[(속성_리스트)]
AS SELECT 문
[WITH CHECK OPTION];

AS SELECT문은 생성하고자 하는 뷰의 정의를 지니며, ORDER BY를 제외한 일반 SELECT문과 동일
속성의 이름 리스트는 생략 가능하며 생략 시 기존의 이름을 그대로 사용, 하지만 AS SELECT문에서 집계함수를 이용할 경우 속성의 이름을 생략할 수 없음
WITH CHECK OPTION은 생성한 뷰에 삽입이나 수정 연산을 할 때 SELECT문에서 제시한 뷰의 정의 조건을 위반하면 수행되지 않도록 하는 제약조건을 의미

뷰 활용

일반 테이블처럼 원하는 데이터를 검색할 수 있음
뷰에 대한 SELECT문이 내부적으로 기본 테이블에 대한 SELECT문으로 변환되어 수행되기 때문
뷰에 대한 삽입, 수정, 삭제 연산도 기본 테이블에 수행되기에 기본 테이블이 변함
그러나 모든 뷰에 허용되는 것은 아니며 뷰를 통한 기본 테이블의 변화는 제한적※ 변경이 되더라도 뷰에 대한 연산은 결과적으로 기본 테이블의 내용을 자동으로 바꾸기 때문에 주의해야 함
기본 테이블의 기본키를 지닌 뷰는 INSERT, UPDATE, DELETE가 가능하지만 기본키를 지니지 않은 뷰는 오류가 발생
why? 기본키가 없는 뷰는 어떤 투플에 대한 삽입, 수정, 삭제 연산인지 명확히 구분되지 않음 그리고 집계 함수로 계산된 값은 기본 테이블이 원래 지닌 값이 아니기에 변경을 할 수 없음

변경이 불가능한 뷰의 특징

기본 테이블의 기본키를 구성하는 속성이 포함되어 있지 않은 뷰
기본 테이블에 있던 내용이 아니라 집계 함수로 새로 계산된 내용을 포함하고 있는 뷰
DISTINCT를 포함하여 정의한 뷰
GROUP BY절을 포함하여 정의한 뷰
여러 개의 테이블을 조인하여 정의한 뷰 (변경이 불가능한 경우가 많음)

뷰의 장점

질의문을 좀 더 쉽게 작성할 수 있다. (특정 조건을 만족하는 투플들로 뷰를 만들어놓으면 WHERE절 없이 쉽게 검색)
데이터의 보안 유지에 도움이 된다. (뷰에 포함되지 않은 데이터를 사용자로부터 보호)
데이터를 좀 더 편리하게 관리할 수 있다. (제공된 뷰에 포함되지 않은 기본 테이블의 다른 부분은 사용자가 신경 쓸 필요가 없음)

뷰 삭제

DROP VIEW 뷰_이름;

뷰를 삭제하더라도 기본 테이블은 영향을 받지 않음

삽입 SQL(임베디드 SQL)

프로그래밍 언어로 작성된 응용 프로그램 안에 삽입하여 사용하는 SQL문
삽입SQL문은 프로그램 안에서 일반 명령문이 위치할 수 있는 곳이면 어디든 삽입 가능
프로그램 안의 일반 명령문과 구별하기 위해 앞에 EXEC SQL을 붙임
프로그램에 선언된 일반 변수를 사용할 수 있으나 앞에 :를 붙여 테이블 이름이나 속성의 이름과 구분함
여러 개의 행을 반환하는 SELECT문을 사용할 경우 커서라는 도구가 필요

커서

수행 결과로 반환된 여러 행을 한 번에 하나씩 가리키는 포인터 역할

커서가 필요 없는 삽입 SQL

CREATE문, INSERT문, DELETE문, UPDATE문, 결과로 행 하나만 반환하는 SELECT문

커서가 필요한 삽입 SQL

여러 행을 결과로 반환하는 SELECT문

자료구조 - 해시 테이블, 트리, 힙, 그래프 정리

ssun_bear — Wed, 10 Jul 2024 14:24:32 +0900

1. 해시테이블

해시테이블이란 해시함수를 이용해 키를 값에 매핑하는 자료구조

구현

충돌

아무리 좋은 해시 함수라도 충돌을 피하기는 어렵다.
예측 가능한 범위 내에서 해시값이 나오고, 데이터와 짝지어지는 것이기 때문에 해시값이 중복될 수 있다.
입력값이 달라도 똑같은 결과가 나오면 충돌
이를 다루는 방식은 체이닝(Chaining), 오픈 어드레싱(Open Addressing) 이 있다.
오픈 어드레싱은 탐사를 통해 ‘빈 공간을 찾아나서는’ 방식
체이닝은 충돌 발생 시 ‘연결’해가는 것
오픈 어드레싱 O(1)
체이닝 O(n)
오픈 어드레싱은 값이 뭉치는 클러스터링이 발생할 수 있고,
체이닝은 메모리 오버헤드와 길어질 경우 탐색이 느려진다는 단점
그래서 각 언어 별로 해시테이블의 구현 방식이 다른데요. C++, Java, Go는 체이닝을 택하고 Python, Ruby는 오픈 어드레싱을 택하고 있다.

구현 (Python)

체이닝 방식의 해시테이블

# structures.py


class HashTable:
    def __init__(self):
        self.size = 10 # 해시테이블의 사이즈 (10으로 나눈 나머지이기떄문에 10으로 설정)
        self.table = [None] * self.size

    def _hash_function(self, key):
        return key % self.size

    def put(self, key, value):

        index = self._hash_function(key) # 키를 넣었을 때 결과값

        if self.table[index] is None: # 값이 없을 때 (푸시한적이 없는 해싱값일 때)
            self.table[index] = HashNode(key, value)#next=None

        else: # 이미 값이 있을 때 (푸시한적이 있는 해싱값일 때) - 체이닝방식이므로 같은 값은 맨 끝에 계속 붙여주면 됨
            node = self.table[index]
            while node.next is not None: # 다음 노드가 없을 때 까지(맨끝까지)
                node = node.next
            node.next = HashNode(key, value)

    def get(self, key):

        index = self._hash_function(key)
        node = self.table[index]

        while node is not None: #노드에 배정된 키가 있을 동안
            if node.key == key: #내가 원하는 값(내가 넣은 키라면)
                return node.value #값 반환
            node = node.next #원하는 노드가 아니면 옮기자
        return -1 # 배정된 게 없다면 -1 반환하자

    def remove(self, key):

        index = self._hash_function(key)
        node = self.table[index]
        prev_node = None

        while node is not None:
            if node.key == key:

                if prev_node is None: # 이전 노드가 없다 - 첫번째꺼다 - 지금거를 다음걸로 바꾼다
                    self.table[index] = node.next
                else:
                    prev_node.next = node.next # 이전 노드의 next를 지금거의 다음걸로 넘긴다 (가운데를 빼는 느낌)
                return

            prev_node = node # 이전 노드를 지금 노드로 넘긴다
            node = node.next

# test.py

ht = HashTable()

ht.put(1, 1)
ht.put(2, 2)
assert ht.get(1) == 1
assert ht.get(2) == 2
assert ht.get(3) == -1

ht.put(12, 1)
ht.put(22, 2)
ht.put(32, 3)
assert ht.get(12) == 1
assert ht.get(22) == 2
assert ht.get(32) == 3

ht.remove(12)
assert ht.get(2) == 2
assert ht.get(12) == -1
assert ht.get(22) == 2
assert ht.get(32) == 3

ht.get(2)

2. 트리

큐 (Queue), 스택 (Stack) -> 선형 구조 : 데이터들을 순차적으로 나열 / 자료를 저장하고 꺼내는 것에 초점
트리 (Tree) -> 비선형 구조 : 데이터가 계층, 망으로 구성 / 표현에 초점

트리 용어

Node: 트리에서 데이터를 저장하는 기본 요소
Root Node: 트리 맨 위에 있는 노드
Level: 최상위 노드를 Level 0으로 하였을 때, 하위 Branch로 연결된 노드의 깊이를 나타냄
Parent Node: 어떤 노드의 상위 레벨에 연결된 노드
Child Node: 어떤 노드의 하위 레벨에 연결된 노드
Leaf Node(Terminal Node): Child Node가 하나도 없는 노드 (제일 끝)
Sibling: 동일한 Parent Node를 가진 노드
Depth: 트리에서 Node가 가질 수 있는 최대 Level

트리의 종류

이진트리

각 노드가 최대 두 개의 자식을 가지는 트리
하위 노드가 3개 이상일 수 없다. 무조건 0,1,2개

      o      Level 0
    o o o    Level 1
   o  o  o   Level 2 # 이진 트리(X)

      o      Level 0
    o   o    Level 1
   o o o     Level 2 # 이진 트리(O)

완전 이진 트리 (Complete Binary Tree)

노드를 삽입할 때 최하단 왼쪽 노드부터 차례대로 삽입해야 한다

      o      Level 0
    o   o    Level 1
     o o     Level 2  # -> 이진 트리 O 완전 이진 트리 X

      o      Level 0
    o   o    Level 1
   o o o     Level 2  # -> 이진 트리 O 완전 이진 트리 O

완전 이진 트리를 배열로 표현

트리 구조를 표현하는 방법

직접 클래스 구현
배열로 표현 -> 완전 이진 트리를 쓰는 경우에 가능!
- 왼쪽부터 데이터가 쌓이므로, 이를 순서대로 배열에 쌓으면서 표현

완전 이진 트리 배열로 표현하기

트리를 구현할 때는 편의성을 위해 0번째 인덱스는 사용되지 않음
그래서 None 값을 배열에 넣고 시작한다. [None]
8의 자식 6,3 / 6의 자식 4,2 / 3의 자식 5

      8      Level 0 -> [None, 8] 첫번째 레벨의 8을 넣고,
    6   3    Level 1 -> [None, 8, 6, 3] 다음 레벨인 6, 3을 넣고
   4 2 5     Level 2 -> [None, 8, 6, 3, 4, 2, 5] 다음 레벨인 4, 2, 5를 넣으면 됩니다!

배열 = [None, 8, 6, 3, 4, 2, 5]

왼쪽에 있는 자식의 인덱스 : 현재 인덱스 * 2
- 8 : 1번 / 6 : 1 * 2 = 2번
- 6 : 2번 / 4 : 2 * 2 = 4번
오른쪽 자식의 인덱스 : 현재 인덱스 * 2 + 1
- 8 : 1번 / 3 : 1 * 2 + 1 = 3번
- 6 : 2번 / 2 : 2 * 2 + 1 = 5번
부모 인덱스 : 현재 인덱스 // 2
- 3 : 3번 / 3 // 2 = 1번 : 8
- ==부모를 찾을 수 있다!==

완전 이진 트리의 높이

트리의 높이

루트 노드부터 가장 아래 리프 노드까지의 길이

높이가 2인 트리

      o      Level 0  # 루트 노드
    o   o    Level 1
   o o o     Level 2  # 가장 아래 리프 노드

이 트리의 높이는 ? 2 - 0 = 2!

각 레벨에 노드가 꽉 차 있는 경우

      1            Level 0 -> 1개
    2   3          Level 1 -> 2개
   4 5 6 7         Level 2 -> 4개
 8 9....... 14 15  Level 3 -> 8개
                   Level k -> 2^k 개

레벨이 k라면, 각 레벨에 최대로 들어갈 수 있는 노드의 개수는 2^k이다.

노드가 꽉 찬 완전 이진 트리의 모든 노드 개수

높이 h
각 레벨k 의 노드 2^k개

레벨은 1, 2, 3, ... , h 이므로 모든 노드의 개수는
1 + 2^1 + 2^2 + 2^3 + 2^4 + ... + 2^h
=  2^(h+1) - 1

높이가 h라면, 최대 노드 개수는 2^(h+1) -1개가 된다.

[!최대 노드 개수가 N이라면 h는?]
2^(h+1) -1 = N
→ h = log_2(N+1)-1

완전 이진 트리 노드의 갯수가 N일 때, 높이는 최대 O(logN)

3. 힙 (Heap)

힙은 데이터에서 최대값과 최소값을 빠르게 찾기 위해 고안된 완전 이진 트리 (Tree)(Complete Binary Tree)

최대/최소의 값들이 필요한 연산에 사용
Max 힙 : 최댓값이 맨 위
Min 힙 : 최솟값이 맨 위

      8      Level 0
    6   3    Level 1
     2 1     Level 2  # -> 이진 트리 O 완전 이진 트리 X 이므로 힙이 아닙니다!

      8      Level 0
    6   3    Level 1  # -> 이진 트리 O 완전 이진 트리 O 인데 모든 부모 노드의 값이
   4 2 1     Level 2  # 자식 노드보다 크니까 힙이 맞습니다!


      8      Level 0
    6   3    Level 1  # -> 이진 트리 O 완전 이진 트리 O 인데 모든 부모 노드의 값이
   4 2 5     Level 2  # 자식 노드보다 크지 않아서 힙이 아닙니다..!

최대 힙 - 삽입 알고리즘

원소를 맨 마지막에 넣는다.
부모 노드와 비교, 더 크면 자리 바꾸기
부모 노드보다 작거나 가장 위에 도달하지 않을 때 까지 반복

이 맥스 힙에서 9를 추가해보겠습니다!
      8      Level 0
    6   3    Level 1
   4 2 1     Level 2

1. 맨 마지막에 원소를 넣습니다.

      8      Level 0
    6   3    Level 1
   4 2 1 9   Level 2

2-1. 부모 노드와 비교합니다. 3보다 9가 더 크니까! 둘의 자리를 변경합니다.

      8      Level 0
    6   3    Level 1
   4 2 1 9   Level 2

      8      Level 0
    6   9    Level 1
   4 2 1 3   Level 2

2-2. 다시 부모 노드와 비교합니다. 8보다 9가 더 크니까! 둘의 자리를 변경합니다.

      8      Level 0
    6   9    Level 1
   4 2 1 3   Level 2

      9      Level 0
    6   8    Level 1
   4 2 1 3   Level 2

3. 가장 위에 도달했으므로 멈춥니다. 힙의 특성을 그대로 유지해 데이터를 삽입했습니다!

      9      Level 0
    6   8    Level 1
   4 2 1 3   Level 2

최대 힙 - 삽입 시간 복잡도

완전 이진트리 최대 높이 : O(log(N))
-> 반복하는 최대 횟수 : O(log(N))
-> Max 힙의 원소 추가는 O(log(N)) 의 시간 복잡도

최대 힙 - 삽입 구현

class BinaryMaxHeap:
    def __init__(self):
        # 계산 편의를 위해 0이 아닌 1번째 인덱스부터 사용한다.
        self.items = [None]

    def insert(self, k):
        self.items.append(k)
        self._percolate_up()

    def _percolate_up(self):
        # percolate: 스며들다.
        cur = len(self.items) - 1
        # left 라면 2*cur, right 라면 2*cur + 1 이므로 parent 는 항상 cur // 2
        parent = cur // 2

        while parent > 0:
            if self.items[cur] > self.items[parent]:
                self.items[cur], self.items[parent] = self.items[parent], self.items[cur]

            cur = parent
            parent = cur // 2

최대 힙 - 추출

최대 힙에서 원소를 추출하는 방법 : 루트 노드(최댓값) 삭제 맨 위 원소만 삭제 가능

이 맥스 힙에서 원소를 제거해보겠습니다! (항상 맨 위의 루트 노드가 제거 됩니다.)
      8      Level 0
    6   7    Level 1
   2 5 4 3   Level 2

1. 루트 노드와 맨 끝에 있는 원소를 교체한다.

      8      Level 0
    6   7    Level 1
   2 5 4 3   Level 2

      3      Level 0
    7   6    Level 1
   2 5 4 8   Level 2

2. 맨 뒤에 있는 원소를 삭제합니다.
이 값이 기존 맥스힙에 있던 가장 큰 값입니다. 따라서 이 값을 마지막에는 반환해줘야 합니다!

      3      Level 0
    6   7    Level 1
   2 5 4 X   Level 2

3-1. 변경된 노드를 더 큰 자식 노드와 비교해야 합니다.
우선 부모와 왼쪽 자식을 비교합니다. 그리고 부모와 오른쪽 자식을 비교합니다.
그리고 부모 보다 큰 자식 중, 더 큰 자식과 변경해야 합니다.
왼쪽 자식인 6과 오른쪽 자식인 7 중에서 7이 더 크고, 부모인 3보다 크니까 둘의 자리를 변경합니다.

      3      Level 0
    6   7    Level 1
   2 5 4     Level 2

      7      Level 0
    6   3    Level 1
   2 5 4     Level 2

3-2. 다시 자식 노드와 비교합니다.
우선 부모와 왼쪽 자식을 비교합니다.
왼쪽 자식인 4는 부모인 3보다 더 크니까 둘의 자리를 변경합니다.

      7      Level 0
    6   3    Level 1
   2 5 4     Level 2

      7      Level 0
    6   4    Level 1
   2 5 3     Level 2


4. 가장 아래 레벨에 도달했으므로 멈춥니다. 힙의 특성을 그대로 유지해 데이터를 삭제했습니다!

      7      Level 0
    6   4    Level 1
   2 5 3     Level 2

5. 그리고, 아까 제거한 원래 루트 노드, 8을 반환하면 됩니다!

최대 힙 - 추출 시간 복잡도

O(log(N))

최대 힙 - 구현

class BinaryMaxHeap:
    def __init__(self):
        # 계산 편의를 위해 0이 아닌 1번째 인덱스부터 사용한다.
        self.items = [None]

    def insert(self, k):
        self.items.append(k)
        self._percolate_up()

    def _percolate_up(self):
        # percolate: 스며들다.
        cur = len(self.items) - 1
        # left 라면 2*cur, right 라면 2*cur + 1 이므로 parent 는 항상 cur // 2
        parent = cur // 2

        while parent > 0:
            if self.items[cur] > self.items[parent]:
                self.items[cur], self.items[parent] = self.items[parent], self.items[cur]

            cur = parent
            parent = cur // 2

    def extract(self):
        if len(self.items) - 1 < 1:
            return None

        root = self.items[1]
        self.items[1] = self.items[-1]
        self.items.pop()
        self._percolate_down(1)

        return root

    def _percolate_down(self, cur):
        biggest = cur
        left = 2 * cur
        right = 2 * cur + 1

        if left <= len(self.items) - 1 and self.items[left] > self.items[biggest]:
            biggest = left

        if right <= len(self.items) - 1 and self.items[right] > self.items[biggest]:
            biggest = right

        if biggest != cur:
            self.items[cur], self.items[biggest] = self.items[biggest], self.items[cur]
            self._percolate_down(biggest)

4. 그래프 (Graph)

큐 (Queue), 스택 (Stack) -> 선형 구조 : 데이터들을 순차적으로 나열 / 자료를 저장하고 꺼내는 것에 초점
트리 (Tree) -> 비선형 구조 : 데이터가 계층, 망으로 구성 / 표현에 초점
그래프 : 연결 관계에 초점

노드(Node): 연결 관계를 가진 각 데이터, 정점(Vertex)
간선(Edge): 노드 간의 관계를 표시한 선
인접 노드(Adjacent Node): 간선으로 직접 연결된 노드(또는 정점)

유방향 그래프 (Directed Graph)

방향이 있는 간선
간선은 단방향 관계를 나타내며, 각 간선은 한 방향으로만 진행 가능

무방향 그래프 (Undirected Graph)

방향이 없는 간선

그래프의 표현 방법

인접 행렬(Adjacency Matrix): 2차원 배열로 그래프의 연결 관계를 표현
인접 리스트(Adjacnecy List): 연결리스트 (Linked List)로 그래프의 연결 관계를 표현
제니 : 0 , 르탄 : 1 , 로제 : 2 , 사나 : 3

	  로제 - 사나
	   ⎜
제니 - 르탄

          2 - 3
          ⎜
      0 - 1

이를 인접 행렬, 2차원 배열로 나타내면

          2 - 3
          ⎜
      0 - 1

  0  1  2  3
0 X  O  X  X
1 O  X  O  X
2 X  O  X  O
3 X  X  O  X

이를 배열로 나타내면

graph = [
    [False, True, False, False],
    [True, False, True, False],
    [False, True, False, True],
    [False, False, True, False]
]

인접 리스트로 표현

인접 리스트는 모든 노드에 연결된 노드에 대한 정보를 차례대로 다음과 같이 저장

          2 - 3
          ⎜
      0 - 1

0 -> 1
1 -> 0 -> 2
2 -> 1 -> 3
3 -> 2

이를 딕셔너리로 표현하면

graph = {
    0: [1],
    1: [0, 2]
    2: [1, 3]
    3: [2]
}

이 두 방식의 차이?

시간 VS 공간

인접 행렬으로 표현 : 연결 여부를 즉각적으로 알 수 있다.
- 모든 조합의 연결 여부를 저장해야 되기 때문에 O(노드^2) 만큼의 공간 사용
인접 리스트로 표현 : 연결 여부를 알기 위해선 각 리스트를 돌아야 함
- 연결되었는지 여부를 알기 위해서 최대 O(간선) 만큼의 시간 사용
- 대신 모든 조합의 연결 여부를 저장할 필요가 없으니 O(노드 + 간선) 만큼의 공간만 사용

자료구조 - 배열, 연결리스트, 스택, 큐 정리

ssun_bear — Wed, 10 Jul 2024 14:02:27 +0900

자료구조에 대해 알아보자.

배열

동일한 데이터 타입의 요소들을 연속된 메모리 공간에 순서대로 저장하는 자료구조
데이터 조회에서 O(1)의 시간 복잡도를 가진다.

장점

연속된 메모리 공간을 사용하므로 처음 데이터의 주소를 알면 나머지도 쉽게 찾을 수 있다.

단점

크기가 고정되어 추가/삭제에 제약이 있다.

연결리스트

각각의 데이터가 메모리 공간 상에 고유한 노드로 존재하며, 해당 노드에 앞과 뒤의 메모리 주소를 기억하고 있는 형태
즉, 노드들이 서로 연결되어 있는 구조
데이터 조회 시 순차적으로 탐색하기 때문에 O(N)의 시간 복잡도
데이터 추가와 삭제에는 O(1)의 시간 복잡도

Array vs Linked List

배열 (Array): 파이썬의 리스트. 접근 쉬움, 삽입 어려움. (파이썬의 리스트)
연결리스트: 직접 구현. 접근 어려움, 삽입 쉬움. 상자랑 화살표 포함해서 노드라고 함

구현

# structures.py

'''
O -> O -> O -> O -> O -> O -> O 형태이다.
'''
class ListNode:
    def __init__(self, val=0, next=None):
        self.val = val # 상자
        self.next = next # 화살표


class LinkedList:
    def __init__(self):
        self.head = None # 제일 첫 요소

    def append(self, val):
        if not self.head: # 헤드가 없다면
            self.head = ListNode(val, None) # 헤드 노드를 하나 만들고 다음거는 없다
            return

        node = self.head # 제일 앞을 노드로 설정
        while node.next: # 다음 요소가 있을 동안 (없을 때 까지)
            node = node.next # 노드를 다음걸로 업데이트

        node.next = ListNode(val, None) # 다음 요소 없으면 새로 만들기!

예제

  주어진 리스트가 팰린드롬인지 판별하는 프로그램을 작성하세요.
(팰린드롬 : 읽는 순서가 바뀌어도 똑같은 것)

예시1) [1, 2, 2, 1] ⇒ True
예시2) [1, 2] ⇒ FalseContent

isPalindrome : 팰린드롬인지 확인하는 함수는 어떻게 만들까?

연결리스트를 리스트로 만든 후,
리스트의 첫번째 요소와 마지막 요소를 꺼내서 같은 지를 확인한다.

#prac.py

def isPalindrome(ln): # 연결리스트를 전달받아서
    arr = []
    head = ln.head #헤드를 꺼내

    if not head: #헤드가 없으면 비어있으므로
        return True

	# 헤드가 있으면
    node = head
    while node: # 노드를 옮겨가며 연결리스트의 모든 값을 리스트에 넣는다.
        arr.append(node.val)
        node = node.next

    while len(arr) > 1: # 길이가 1이 될 때 까지
	    # 첫 번째 요소와 마지막 요소를 꺼낸다.
        first = arr.pop(0)
        last = arr.pop()
        if first != last: # 다르면 팰린드롬이 아님
            return False

    return True

파이썬 배열로 활용한다면

def isPelindrome(arr):
	if arr==arr[-1::]:
    	return True
    else:
    	return False

(배열이 파이썬에서 구현하기는 더 쉽다)

위에서 만든 펠린드롬 검사 함수를 test.py에서 사용하기

# test.py

from structures import LinkedList
from prac import isPalindrome

l1 = LinkedList() # 1->2->2->1
for num in [1, 2, 2, 1]:
    l1.append(num)

l2 = LinkedList()
for num in [1, 2]:
    l2.append(num)


assert isPalindrome(l1) # assert 뒤의 값을 true로 확언하겠다 (true가 맞는지 test하는 것)
assert not isPalindrome(l2) # assert not 뒤의 값을 false로 확언하겠다 (false 가 맞는지 test하는 것)

스택(Stack)

후입선출의 원칙을 따르는 자료구조로 차곡차곡 쌓아올리는(Stack) 것
삽입과 삭제시에 O(1), 탐색에는 O(n)의 시간 복잡도

사용 예

브라우저의 뒤로가기
실행 취소 (Ctrl + z)
재귀 함수
역순 문자열 (문자열 거꾸로 뒤집기)

구현

# structures.py

'''
연결리스트를 응용해서, 대신 제일 앞이 아니라 제일 위여야 하므로 가장 처음 걸 top으로 한다.
O
↓
O
↓
O
↓
O
↓
O
형태가 된다.
'''
class Node:
    def __init__(self, val = 0, next = None):
        self.val = val #상자
        self.next = next

class Stack:
    def __init__(self):
        self.top = None

    '''
    스택은 쌓으므로 append가 아닌 push,
    연결리스트와 다른 점 : 새로 들어온 게 항상 top
    '''
    def push(self, val):
        # node = Node(val,None) : 새로 들어오면
        # node.next = self.top : 기존에 가장 위에(top)였던 애를 다음 노드로
        # self.top = node : 그리고 지금 새로 만든 노드를 top으로
        # 결국 val,next 에서 top 이었던 것을 next로 만드는 것이므로 한줄로 표현하면
        self.top = Node(val,self.top)

    def pop(self):
        if not self.top: # 없을 때
            return None # None을 넣어준다
        # pop 이므로 top 을 위에서 두번째걸로, 즉 다음걸로 바꿔줘야 함
        node = self.top
        self.top = node.next
        # 그리고 선택된 노드(아직 제일 위에거이지만 top은 다음으로 넘겨준)를 반환한다.
        return node.val
    def is_empty(self):
        return self.top is None # pop 에서 넣어준 None 이 리턴되었다면 -> 없다면!

# test.py

def test_stack():
    stack = Stack()

    stack.push(1)
    stack.push(2)
    stack.push(3)
    stack.push(4)
    stack.push(5)
    '''
    현재 스택
    5
    4
    3
    2
    1
    '''
	# 스택에서 pop 하면 제일 위에 거 (마지막 거이기 때문에)
    assert stack.pop() == 5
    assert stack.pop() == 4
    assert stack.pop() == 3
    assert stack.pop() == 2
    assert stack.pop() == 1
    assert stack.pop() is None
    assert stack.is_empty()

예제

  '(', ')', '{', '}', '[' 및 ']' 만 포함된 문자열이 주어졌을 때 입력 문자열이 유효한지 확인하는 프로그램을 작성하세요.

열린 괄호가 제대로 닫혔는지 확인 -> 내가 연 순서의 반대로 닫으면 됨 ex) ({[]})
여는 괄호가 나올 때 마다 스택에 담고, 여는 게 끝나면 스택 제일 위부터 꺼내서 짝을 비교하면(딕셔너리 사용) 제대로 닫혔는지 확인할 수 있다.
실제 문제풀이 할 때는 리스트를 스택처럼 써서 푼다.

#prac.py

def test_problem_stack(s):
    pair = {
        '}': '{',
        ')': '(',
        ']': '[',
    }
    opener = "({["
    stack = []

    for char in s:
        if char in opener: # 여는 거일 때
            stack.append(char)
        else: # 닫는 거일 때
            if not stack: # 여는 게 끝났는데 닫는 게 남아있다면
                return False
            top = stack.pop()
            if pair[char] != top:
                return False

    return not stack

큐 (Queue)

선형 큐, 우선순위 큐, 원형 큐, 덱 4가지로 나눠서 살펴보겠다.

1. 선형 큐(Linear Queue)

한 쪽에서는 데이터 삽입, 다른 한 쪽에서는 데이터의 삭제만 가능한, 선입선출 원칙을 따르는 자료구조
삽입과 삭제에는 O(1), 탐색에는 O(n) 의 시간 복잡도

구현

스택처럼 쌓기 때문에 넣을 땐 똑같지만
뺄 때는 맨 뒤에서, 즉 처음 넣은 것을 뺀다. front를 빼는 게 아니다.

# structures.py

'''
노드 클래스는 연결리스트, 스택과 동일하다.
class Node:
    def __init__(self, val=0, next=None):
        self.val = val # 상자
        self.next = next # 화살표
'''

'''
가장 앞에 있는 게 중요하므로 front
'''
class Queue:
    def __init__(self):
        self.front = None

    def push(self, value):
        if not self.front: # 맨 앞에가 없으면
            self.front = Node(value) # 노드 만들어서 front로
            return

		#맨 앞이 있으면
        node = self.front # 제일 앞 노드를 잡아서
        while node.next: # 다음 노드가 있는 동안 (다음 노드가 없을 때 까지)
            node = node.next # 다음 노드를 계속 잡는다.
	    '''
	    다음 노드가 없으면 새로 상자를 만들어서 들어온 value를 대입,
	    그리고 다음 노드로 가리키게 해준다(화살표를 만든다. next는 화살표를 의미함)
	    '''
        node.next = Node(value)

    def pop(self):
        if not self.front: # 꺼낼 게 없으면
            return None

        node = self.front # 꺼낼 게 있으면
        self.front = self.front.next # 맨 앞부터 (처음 넣은 것 부터) 꺼낸다.
        return node.val

    def is_empty(self):
        return self.front is None

# test.py

def test_queue():
    queue = Queue()

    queue.push(1)
    queue.push(2)
    queue.push(3)
    queue.push(4)
    queue.push(5)

    assert queue.pop() == 1
    assert queue.pop() == 2
    assert queue.pop() == 3
    assert queue.pop() == 4
    assert queue.pop() == 5
    assert queue.pop() is None
    assert queue.is_empty()

2. 우선순위 큐

우선순위 큐의 각 요소는 값과 우선순위, 총 2개의 데이터를 가지고 있습니다.
따라서 선형 큐 (Linear Queue)와는 달리 우선순위가 높은 요소일수록 먼저 삭제되는 특징을 가지고 있으며 우선순위가 같은 데이터일 경우 삽입순서를 따릅니다.
삽입 및 삭제 시 우선순위에 따라 요소들을 정렬 해야하기 때문에 주로 힙 (Heap)이라는 자료구조로 구현
우선순위 큐는 어떻게 구현하느냐에 따라 시간 복잡도가 달라지지만 힙 (Heap)을 기준으로 한다면 삽입과 삭제에는 O(logn), 우선순위가 가장 높은 요소를 탐색할 때는 O(1)만큼의 시간 복잡도를 가진다.

3. 원형 큐 (Circular Queue)

원형 큐는 선형 큐 (Linear Queue)의 단점을 보완하기 위해 나왔습니다.
큐는 사이즈가 고정되어있고 데이터의 삽입과 삭제시 나머지 요소들은 이동하지 않습니다.
따라서 데이터의 삽입과 삭제가 반복되면 언젠가 Rear는 큐의 마지막 인덱스를 가르키게 되고 이전에 삭제 작업을 진행하여 앞에 빈 공간이 있더라도 활용하지 못하게 됩니다.
따라서 선형 큐는 빈 공간을 활용하기 위해 현재 요소들을 앞으로 재배치하는 별도의 작업이 필요합니다.

하지만 원형큐의 경우 Front와 Rear가 아래 그림처럼 순환하기 때문에 빈 공간을 사용하기 위한 별도의 작업이 필요하지 않습니다.

위의 사진에서 Front와 Rear의 움직임을 보면 Front와 Rear가 계속해서 돌고 있는 모습을 볼 수 있습니다.
이러한 움직임을 만들어내기 위해서 원형 큐에서는 Enqueue 및 Dequeue시에 아래와 같은 작업을 합니다.

function enqueue() {
  // ...
  rear = (rear + 1) % queue_size;
}

function dequeue() {
  // ...
  front = (front + 1) % queue_size;
}

예를 들어, 큐의 전체 사이즈가 5이고 현재 Rear가 마지막 인덱스인 4를 가르키고 있다고 가정해보겠습니다.
여기서 Enqueue를 하게되면 Rear의 인덱스는 5가 될텐데 여기에 큐의 전체사이즈를 나눈 나머지를 구합니다.
5 % 5 = 0이므로 이 값을 Rear에 할당하여 인덱스가 다시 0을 가르킬 수 있도록 합니다.
이렇게 하면 정렬과정 없이 Front와 Rear가 순환하는 형태를 만들 수 있습니다.

4. 덱 (Deque, Double-ended Queue)

덱은 큐 (Queue) 2개를 겹쳐 놓은 것과 같기 때문에 Double ended Queue라고 부르며 Deque이라는 명칭은 이를 축약형으로 부르는 것입니다.
이 자료구조는 이름처럼 양쪽에서 데이터의 입, 출력이 모두 가능한 자료구조입니다.
JS에서는 배열의 내장메소드로 모두 구현되어있으며
스택, 큐와 마찬가지로 front와 rear라는 포인터가 있으며 이들은 각각 가장 앞, 뒤에 있는 데이터를 가르킵니다.
다만, 스택과 큐의 Rear는 다음 요소가 삽입 될 위치를 가르키는 반면
덱의 Rear는 마지막 요소를 가리키고 있게 됩니다.
스택, 큐와 같이 데이터의 삽입과 삭제에 O(1)의 시간 복잡도를 가집니다.

예제 (deque)

  1부터 N까지 차례대로 줄을 섰을 때, 맨 앞에 선 사람만 들여보내주고 그 다음 순서인 사람은 제일 뒤로 보내는 특이한 줄서기가 있습니다.

예를 들어 N=6인 경우, 123456 이 순서대로 줄을 서있을 것입니다. 이때 제일 먼저 1이 입장하고 남은 순서는 23456이 됩니다. 2는 두 번째 순서이므로 제일 뒤로 보내서 34562가 됩니다. 다시 3이 입장하여 4562가 되고, 4가 두 번째 순서이므로 5624가 되빈다. 5가 입장하고 246, 2가 입장하고 64, 6이 입장하여 4, 마지막으로 4가 입장하게 됩니다.

N이 주어질 때 제일 마지막으로 입장하는 숫자를 계산하는 프로그램을 작성하세요.

# prac.py
from collections import deque

def test_problem_queue(n):
    deq = deque([i for i in range(1, num + 1)])

    while len(deq) > 1: # 요소가 2개 이상 남아있는 동안 (하나 남을 때 까지)
        deq.popleft() # deque의 앞에서 꺼낸다.
        deq.append(deq.popleft()) # 두번째는 앞에서 꺼내서 맨뒤에 붙인다.
    return deq.popleft()

# test.py

assert test_problem_queue(2) == 2
assert test_problem_queue(3) == 2
assert test_problem_queue(4) == 4
assert test_problem_queue(5) == 2
assert test_problem_queue(6) == 4
assert test_problem_queue(7) == 6

Chapter 3 - 6. 혼잡 제어의 원리, 7. TCP 혼잡 제어, 8. 트랜스포트 계층 기능의 발전

ssun_bear — Wed, 10 Jul 2024 00:51:15 +0900

3.6 혼잡 제어의 원리

네트워크 혼잡의 원인 : 너무 많은 출발지가 너무 높은 속도로 데이터를 보내려고 시도

→ 이를 처리하기 위해서는 네트워크 혼잡을 일으키는 송신자들을 억제하는 매커니즘이 필요하다.

3.6.1 혼잡의 원인과 비용

시나리오 1 : 2개의 송신자와 무한 버퍼를 갖는 하나의 라우터

두 호스트 A와 B가 각각 출발지와 목적지 사이에서 단일 홉을 공유하는 연결을 갖는다.
호스트 A와 B의 애플리케이션이 λin 바이트/초의 평균 전송률로 데이터를 전송하고 있다.
라우터 버퍼의 양은 무한하다고 가정한다.

아래 그래프들은 A의 연결 성능을 나타낸다.

연결당 처리량(per-connection throughput) : 수신자 측에서의 초당 바이트 수
- 0 ~ R/2 사이의 전송률 : 수신자 측의 처리량은 송신자의 전송률과 같다.
- R/2 이상의 전송률 : 처리량은 R/2
- 즉, 호스트 A와 B가 전송률을 아무리 높게 설정하더라도 각자 R/2보다 높은 처리량을 얻을 수 없다.

평균 지연
- 전송률이 R/2에 근접할 경우 : 평균 지연은 점점 커진다.
- 전송률이 R/2를 초과할 경우 : 무제한 (무한한 사용 가능한 버퍼링을 가정)

패킷 도착률이 링크 용량에 근접함에 따라 큐잉 지연이 커진다.

시나리오 2 : 2개의 송신자, 유한 버퍼를 가진 하나의 라우터

라우터 버퍼의 양이 유한하다고 가정한다. → 버퍼가 가득 찼을 때 도착하는 패킷들은 버려진다.
각 연결은 신뢰적이라고 가정한다. → 패킷이 라우터에 버려지면 송신자에 의해 재전송될 것이다.
애플리케이션이 원래의 데이터를 소켓으로 보내는 송신율 : λin 바이트/초
네트워크 안으로 세그먼트를 송신하는 트랜스포트 계층에서의 송신율(제공된 부하, offered load)
: λ'in 바이트/초 = 최초의 데이터 전송과 재전송 합의 속도

a. 어떠한 손실도 발생하지 않는 경우 (버퍼가 비어 있을 때만 패킷을 송신)

연결의 처리량 = λin
평균 호스트 송신율은 R/2를 초과할 수 없다.

b. 패킷이 확실히 손실된 것을 알았을 때만 송신자가 재전송하는 경우

제공된 부하 λ'in이 R/2일 경우 : 데이터의 전송률은 R/3
전송된 데이터의 R/2 중
- 0.333R 바이트/초는 원래의 데이터
- 초당 0.166R 바이트/초(평균)는 재전송 데이터

송신자는 버퍼 오버플로 때문에 버려진 패킷을 보상하기 위해 재전송을 수행해야 한다.

c. 송신자에서 너무 일찍 타임아웃되어 패킷이 손실되지 않았지만, 큐에서 지연되고 있는 패킷을 재전송하는 경우

원래의 데이터 패킷과 재전송 패킷 둘 다 수신자에게 도착한다.
각 패킷이 라우터에 의해 두 번씩 전달된다고 가정했을 때, 제공된 부하가 R/2일 때의 처리량은 R/4

커다란 지연으로 인한 송신자의 불필요한 재전송은 라우터가 패킷의 불필요한 복사본들을 전송하는 데 링크 대역폭을 사용하는 원인이 된다.

시나리오 3 : 4개의 송신자와 유한 버퍼를 갖는 라우터, 그리고 멀티홉 경로

4개의 호스트는 겹쳐지는 2홉 경로를 통해 패킷을 전송한다.
각각의 호스트가 타임아웃/재전송 매커니즘을 사용한다.
모든 호스트는 λin의 동일한 값을 가진다.
모든 라우터 링크는 R 바이트/초 옹량을 갖는다.

라우터 R2는 λin과 관계없이, R1에서 R2까지의 링크 용량, 최대 R인 도착률을 가질 수 있다.
A ~ C와 B ~ D의 트래픽은 버퍼 공간을 라우터 R2에 경쟁해야 한다.
→ R2를 성공적으로 통과하는 A ~ C의 트래픽의 양은 B ~ D에서 제공된 부하가 크면 클수록 더 작아진다.

트래픽이 많은 경우 A~C 종단 간 처리율이 0이 된다.

즉, 아래 그래프처럼 제공된 부하와 처리량 간의 tradeoff가 발생한다.

패킷이 경로상에서 버려질 때, 버려지는 지점까지 패킷을 전송하는 데 사용된 상위 라우터에서 사용된 전송 용량은 낭비된 것이다.

3.6.2 혼잡 제어에 대한 접근법

종단 간의 혼잡 제어

네트워크 계층은 혼잡 제어 목적을 위해 트랜스포트 계층에게 어떤 직접적인 지원도 제공하지 않는다.

따라서 네트워크에서 혼잡의 존재는 단지 관찰된 네트워크 동작(패킷 손실 및 지연)에 기초하여 종단 시스템이 추측해야 한다.

이는 TCP가 혼잡 제어를 위해 취하는 방식이다.

TCP 세그먼트 손실과 증가하는 왕복 지연값을 네트워크 혼잡의 발생 표시로 간주한다.
TCP는 그에 따라서 윈도 크기를 줄인다.

네트워크 지원 혼잡 제어

라우터들은 네트워크 안에서 혼잡 상태와 관련하여 송신자나 수신자 또는 모두에게 직접적인 피드백을 제공한다.

ATM ABR(Available Bite Rate) 혼잡 제어에서
라우터는 자신이 출력 링크(outgoing link)에 제공할 수 있는 전송률을 송신자에게 명확히 알릴 수 있게 해준다.
최근 IP와 TCP가 이 방식을 선택적으로 구현할 수 있다.

혼잡 정보가 전달되는 두 가지 방법 → 둘 중 하나로 네트워크에서 송신자에게 피드백된다.

직접 피드백
- 네트워크 라우터 → 송신자
- 알림의 형태 : 초크 패킷(choke packet)
송신자에서 수신자에게로 흐르는 패킷 안에 특정 필드에 표시/수정
- 수신자가 표시된 패킷을 수신했을 때, 혼잡 상태를 송신자에게 알린다.
- 완전한 왕복 시간이 걸린다.

3.7 TCP 혼잡 제어

IP 계층은 네트워크 혼잡에 관해 종단 시스템에게 어떠한 직접적인 피드백도 제공하지 않는다.

3.7.1 전통적인 TCP의 혼잡 제어

네트워크의 혼잡에 따라 연결에 트래픽을 보내는 전송률을 각 송신자가 제한하도록 한다.

TCP 송신자가 자신과 목적지 간의 경로에서 혼잡이 없음을 감지 → 송신율을 높인다.
TCP 송신자가 경로 사이에 혼잡을 감지 → 송신율을 줄인다.

1. TCP 송신자는 자신의 연결에 송신자 전송 트래픽 전송률을 어떻게 제한하는가?

송신 측에서 동작하는 TCP 혼잡 제어 메커니즘은 추가적인 변수인 혼잡 윈도(congestion window)를 추적한다.

cwnd로 표시
TCP 송신자가 네트워크로 트래픽을 전송할 수 있는 속도에 제약을 가한다.

송신하는 쪽에서 확인응답이 안 된 데이터의 양은 cwnd와 rwnd(수신 윈도 = 버퍼의 여유 공간)의 최소값을 초과하지 않을 것이다.

LastByteSent - LastByteAcked ≤ min{cwnd, rwnd}

→ 따라서 cwnd의 값을 조절하여 송신자는 링크에 데이터를 전송하는 속도를 조절할 수 있다.

2. TCP 송신자는 자신과 목적지 사이 경로의 혼잡을 어떻게 감지하는가?

1️⃣ 손실 이벤트(loss event)가 발생한 경우

과도한 혼잡이 발생하면

경로에 있는 하나 이상의 라우터 버퍼들이 오버플로되고
그 결과 데이터그램이 버려진다.
버려진 데이터그램은 송신 측에서 손실 이벤트를 발생시킨다.
(e.g., 타임아웃 또는 3개의 중복된 ACK의 수신)

이를 통해 송신자는 송신자와 수신자 사이의 경로상의 혼잡이 발생했음을 알게 된다.

2️⃣ 손실 이벤트가 발생하지 않은 경우

자체 클로킹(self-clocking)
TCP는 확인응답을 혼잡 윈도 크기의 증가를 유발하는 트리거(trigger)또는 클록(clock)으로 사용한다.

확인응답이 늦은 속도로 도착한다면 → 혼잡 윈도는 상대적으로 낮은 속도로 증가
확인응답이 높은 속도로 도착한다면 → 혼잡 윈도는 더 빨리 증가

3. TCP 송신자는 송신율을 변화시키기 위해 어떤 알고리즘을 사용해야 하는가?

전송률을 제어하는 cwnd 값을 조정하는 매커니즘은 무엇인가?

TCP 송신자들이 너무 빠르게 송신하면 → 혼잡 붕괴가 나타날 것이다.
TCP 송신자들이 너무 천천히 송신한다면 → 네트워크 내의 대역폭을 충분히 활용하지 못할 것이다.

TCP는 다음과 같은 3가지 처리 원칙에 따라 자신이 송신할 속도를 결정하게 된다.

1️⃣ TCP 전송률은 한 세그먼트를 손실했을 때 줄여야 한다.

손실된 세그먼트 = 혼잡을 의미

손실 세그먼트의 재전송을 야기하는 이벤트는 다음과 같다.

타임아웃 이벤트
4개의 확인응답 수신 (하나의 원래의 ACK + 3개의 중복된 ACK)

2️⃣ 확인응답되지 않은 세그먼트에 대해 ACK가 도착하면 송신자의 전송률은 증가할 수 있다.

확인응답의 도착 = 네트워크가 송신자의 세그먼트를 수신자에게 성공적으로 전송하였다.

즉, 네트워크는 혼잡하지 않다는 묵시적 표시로 받아들여진다.

3️⃣ 대역폭 탐색

혼잡이 없는 출발지에서 목적지까지의 경로를 표시하는 ACK와 혼잡한 경로를 표시하는 손실 이벤트가 주어지면,

TCP 송신자로 하여금 손실 이벤트가 발생할 때까지는 ACK가 도착함에 따라 전송률을 증가시킨다.
손실 이벤트가 발생한 시점에서 전송률을 줄인다.

그러므로

TCP 송신자는 혼잡이 발생하는 시점까지 전송률을 증가시키고
그 시점 이후로부터는 줄인 후,
다시 혼잡 시작이 발생했는지를 보기 위한 탐색을 시작한다.

TCP 혼잡 제어 알고리즘(TCP congestion-control algorithm)

세 가지 구성요소

슬로 스타트(slow start)
혼잡 회피(congestion avoidance)
빠른 회복(fast recovery) → 권고, 필수사항은 아니다.

TCP 혼잡 제어의 FSM

슬로 스타트(slow start)

TCP 연결 시작 시, cwnd의 값은 일반적으로 1 MSS로 초기화된다.
→ 초기 전송률은 대략 MSS/RTT
TCP 송신자에게 가용 대역폭은 MSS/RTT보다 훨씬 크기 때문에 TCP 송신자는 가용 대역폭 양을 조속히 찾고자 한다.

슬로 스타트 상태에서는 cwnd 값을 1 MSS에서 시작하여,
한 전송 세그먼트가 첫 번째로 확인응답을 받을 때마다 1 MSS 씩 증가한다.

아래 그림처럼 TCP 전송률은 지수적으로 증가하게 된다.

슬로스타트의 종료 조건

이 지수적 증가는 언제 끝나는 것인가?

아래와 같이 3가지 경우가 존재한다.

1️⃣ 타임아웃으로 표시되는 손실 이벤트(혼잡)가 있을 경우

TCP 송신자는 cwnd 값을 1로 설정
새로운 슬로 스타트를 시작한다.

2️⃣ cwnd 값이 ssthreah 값과 같을 경우

슬로 스타트는 종료되고
TCP는 혼잡 회피 모드로 전환한다.

ssthreah(slow start threshold, 슬로 스타트 임곗값)는 두 번째 상태 변수로, cwnd/2로 정한다.
(= 혼잡이 검출되었을 시점에서의 혼잡 윈도 값의 반)
TCP는 혼잡 회피 모드에서는 cwnd를 좀 더 조심스럽게 증가시킨다.

3️⃣ 중복 ACK가 검출되는 경우

TCP는 빠른 재전송을 수행하여 빠른 회복 상태로 들어간다.

혼잡 회피

혼잡 회피 상태로 들어가는 시점에서 cwnd의 값은 대략 혼잡이 마지막으로 발견된 시점에서의 값의 반이 된다.

혼잡 회피 상태에서 일반적으로 TCP는 RTT마다 하나의 MSS만큼 cwnd를 증가시킨다.

즉, 새로운 승인이 도착할 때마다 cwnd를 MSS 바이트(MSS/cwnd)만큼 증가시킨다.

혼잡 회피 상태의 종료 조건

언제 혼잡 회피의 (RTT당 1 MSS) 선형 증가가 끝날 것인가?

TCP 혼잡 회피 알고리즘은 타임아웃이 발생했을 때 슬로 스타트의 경우와 같이,

cwnd의 값은 1 MSS로 설정하고, ssthreash의 값은 손실 이벤트가 발생할 때의 cwnd 값의 반으로 설정한다.

그러나 손실 이벤트는 3개의 중복된 ACK 이벤트에 의해 야기되며,
이 경우 네트워크는 송신자로부터 세그먼트를 수신자에게 계속 전달하고 있는 중이다.

따라서 이러한 타입의 손실 이벤트에 대해서 TCP는

3개의 중복 ACK를 수신한 시점에서 cwnd의 값을 반으로 줄이고
ssthresh 값을 cwnd 값의 반으로 기록한다.
이후 빠른 회복 상태로 들어간다.

빠른 회복

빠른 회복 상태에서는 cwnd 값을 손실된 세그먼트에 대해 수신된 모든 중복된 ACK에 대해 1 MSS 만큼씩 증가시킨다.

이때 손실된 세그먼트는 TCP를 빠른 회복 상태로 들어가게 했던 세그먼트를 말한다.

손실된 세그먼트에 대한 ACK가 도착하면 TCP는 cwnd 혼잡 회피 상태로 들어간다.
만약 타임아웃 이벤트가 발생한다면 빠른 회복은 슬로 스타트 및 혼잡 회피에서와 같은 동작을 수행한 후 슬로 스타트로 전이한다.
즉, cwnd 값은 1 MSS로 하고, ssthresh 값은 손실 이벤트가 발생할 때의 cwnd 값의 반으로 한다.

빠른 회복은 구성요소의 권고사항이며, 필수는 아니다.

TCP 타호(TCP Tahoe, 초기 TCP 버전)
: 타임아웃으로 표시되거나 3개의 중복 ACK로 표시되는 손실이 발생하면
1. 무조건 혼잡 윈도를 1 MSS로 줄이고
2. 슬로 스타트 단계로 들어간다.
TCP 리노(TCP Reno, 새로운 TCP 버전)는 빠른 회복을 채택했다.

아래는 리노와 타노에 대한 TCP의 혼잡 윈도 변화를 나타낸 그래프이다.

손실 이벤트가 발생했을 때

TCP 리노
1. 혼잡 윈도가 9•MSS로 설정되고
2. 선형적으로 증가한다.
TCP 타호
1. 혼잡 윈도는 1 MSS로 설정되고
2. ssthreash에 도달할 때까지 지수적으로 증가하며
3. 그 이후에는 선형적으로 증가한다.

TCP 혼잡 제어: 복습

연결이 시작되고 초기 슬로 스타트 기간을 무시하고,
손실이 타임아웃이 아니라 3개의 중복 ACK로 표신된다고 가정한다면,

TCP의 혼잡 제어는
RTT마다 1 MSS씩 cwnd의 선형(가법적인) 증가와
3개의 중복 ACK 이벤트에서 cwnd의 절반화(승법적 감소)로 구성된다.

→ TCP의 혼잡 제어는 가법적 증가, 승법적 감소(additive-increase, multiplicative decrease, AIMD)의 혼잡 제어 형식이라고 불린다.

TCP는 3개의 중복 ACK 이벤트가 발생할 때까지 선형으로 그 혼잡 윈도 크기(결국 전송률)를 증가시킨다.
그러고 나서는 혼잡 윈도 크기를 감소시키지만,
다시 추가적인 가용 대역폭이 있는지를 탐색하기 위해 선형으로 증가시키기 시작한다.

TCP 큐빅(CUBIC)

패킷 손실이 발생한 혼잡한 링크의 상태가 많이 변경되지 않은 경우
전송 속도를 더 빠르게 높여 손실 전 전송 속도에 근접한 다음 대역폭을 신중하게 조사한다.

ACK 수신 시에만 혼잡 윈도를 늘리고 슬로 스타트 단계와 빠른 복구 단계는 TCP 리노와 동일하지만,
아래의 혼잡 회피 단계가 수정되었다.

✅ 몇 가지 조율 가능한 큐빅 매개변수들이 프로토콜의 혼잡 윈도 크기가 얼마나 빨리 Wmax에 도달하는가(K)를 결정한다.

Wmax : 손실이 마지막으로 감지되었을 때 TCP의 혼잡 제어 윈도 크기
K 시각 : 손실이 없다고 가정할 때 TCP 큐빅의 윈도 크기가 다시 Wmax에 도달하는 미래 시점

✅ 큐빅은 혼잡 윈도를 현재 시각 t와 K 시각 사이 거리의 세제곱 함수로 증가시킨다.

→ t가 K에 가까울 때보다 멀리 떨어졌을 때 혼잡 윈도 크기 증가가 훨씬 더 커진다.

즉,

큐빅은 손실 전 속도인 Wmax에 가까워지도록 TCP의 전송 속도를 빠르게 증가시킨 다음,
Wmax에 가까워지면 대역폭을 조심스럽게 탐지한다.

✅ 손실을 유발한 링크의 수준이 크게 변경된 경우 큐빅이 새 작동 지점을 더 빨리 찾을 수 있다.

t가 K에 가까울 때는 큐빅의 혼잡 윈도 증가가 작다.
(이는 손실을 유발하는 링크의 혼잡 수준이 많이 변경되지 않은 경우 좋음)
t가 K를 크게 초과함에 따라 혼잡 윈도가 급격히 증가한다.

아래 그래프는 TCP 리노와 TCP 큐빅의 이상적인 성능 비교를 나타낸 것이다.

슬로 스타트 단계는 t0에서 끝나며,
t1, t2, t3에서 혼잡 손실이 발생하면 큐빅은 Wmax에 가깝게 더 빠르게 증가한다.

→ 따라서 TCP 큐빅이 더 많은 전체 처리량을 누린다.

TCP 큐빅은 혼잡 임곗값 바로 아래에서 가능한 한 오랫동안 흐름을 유지하려고 시도한다.

3.7.2 네트워크 지원 명시적 혼잡 알림과 지연 기반 혼잡 제어

1980년대 후반 슬로 스타트와 혼잡 회피의 초기 표준화 이후, TCP는 종단 끝 혼잡 제어 형식을 구현했다.

하지만 최근에는 네트워크가 TCP 송신자와 수신자에게 명시적으로 혼잡 신호를 보낼 수 있도록
IP 및 TCP에 대한 확장이 제안, 구현 및 배포되었다. (네트워크 지원 혼잡 제어 방식)

또한 측정된 패킷 지연을 사용하여 혼잡을 추론하는 TCP 혼잡 제어 프로토콜의 일부 변형이 제안되었다.

명시적 혼잡 알림(Explicit Congestion Notification, ECN)

인터넷 내에서 수행되는 네트워크 지원 혼잡 제어의 한 형태이다.

네트워크 계층에서 IP 데이터그램 헤더의 서비스 유형(Type of Service) 필드에 있는 2비트가 ECN에 사용된다.

손실이 발생하기 전에 혼잡 시작을 송신자에게 알리기 위해 혼잡 알림 비트를 설정한다.

ECN 비트의 설정

ECN 비트의 한 설정은 라우터가 정체를 겪고 있음을 나타내기 위해 라우터에서 사용된다.

→ 이 혼잡 표시는 표시된 IP 데이터그램에서 목적지 호스트로 전달되어 위의 그림처럼 송신 호스트에게 알린다.

ECN 비트의 두 번째 설정은 발신 호스트가 라우터에게 다음의 정보를 알리는 데에 사용된다.

송신자와 수신자가 ECN을 사용할 수 있다.
이에 따라 ECN으로 표시된 네트워크 혼잡에 대한 응답으로 조취할 수 있다.

과정

혼잡해지는 라우터는 그 라우터에서 버퍼가 가득 차서 패킷들이 삭제되기 전에
송신자에게 혼잡 시작을 알리는 혼잡 알림 비트를 설정할 수 있다.

수신 호스트의 TCP가 수신 데이터그램을 통해 ECN 혼잡 알림 표시를 수신하면,
수신 호스트의 TCP는 수신자-송신자 TCP ACK 세그먼트의
ECE(Explicit Congestion Notification Echo, 명시적 혼잡 알림 에코) 비트를 설정하여
송신 호스트의 TCP에 혼잡 표시를 알린다.
TCP 송신자는 혼잡 윈도를 절반으로 줄여 혼잡 알림 표시가 있는 ACK에 반응하고,
다음 전송되는 TCP 수신자 세그먼트 헤더에 CWR(Congestion Window Reduced) 비트를 1로 설정한다.

지연 기반 혼잡 제어

패킷 손실이 발생하기 전에 혼잡 시작을 사전에 감지

TCP 베가스(Vegas)는 TCP 송신자가 파이프를 가득 채우되 그 이상으로 채우지 않도록 해야 한다는 원칙하에 동작한다.

즉, 파이프가 가득 찬 상태에서는 큰 큐가 쌓이도록 허용되는 경우가 좋을 게 없다는 것을 의미한다.

TCP 베가스는 모든 확인응답된 패킷에 대한 출발지에서 목적지까지 경로의 RTT를 측정한다.
RTTmin : 송신자에서 측정한 RTT 값 중 최솟값

실제 송신자가 측정한 처리량이 cwnd/RTTmin에 가깝다면
- 경로가 아직 정체되지 않았고,
- 따라서 TCP 전송 속도가 증가할 수 있다는 것이다.
실제 송신자가 측정한 처리량이 혼잡하지 않을 때의 처리율보다 현저히 낮다면
- 경로가 혼잡하고
- TCP 베가스 송신자는 전송 속도를 낮추게 된다.

3.7.3 공평성

각각 다른 종단 간의 경로를 갖지만, 모두 R bps의 전송률인 병목 링크(bottleneck link)를 지나는 K개의 TCP 연결을 생각해보자.

각 연결은 큰 파일을 전송하고 있고, 병목 링크를 통과하는 UDP 트래픽은 없다고 가정했을 때,

각 연결의 평균 전송률이 R/K에 가깝다면 혼잡 제어는 메커니즘이 공평하다고 한다.
즉, 각 연결은 링크 대역폭을 동등하게 공유한다.

아래 그림처럼 전송률이 R인 링크 하나를 공유하는 2개의 TCP 연결을 살펴보자.

가정

두 연결이 같은 MSS와 RTT를 가진다.
→ 그들이 같은 혼잡 윈도우 크기를 갖는다면 같은 처리율을 가질 것이다.
송신할 많은 양의 데이터가 있다.
TCP의 슬로 스타트 현상을 무시한다.
TCP 연결이 언제나 혼잡 회피 방식으로 동작한다.

TCP 연결 1과 2에 의해 실현되는 처리율은 다음과 같이 나타낼 수 있다.

만약 TCP가 두 연결 사이에서 링크 대역폭을 똑같이 공유한다면,
실제 처리율은 원점에서부터 발산하면서 45º 각도의 화살표(동등한 대역폭 공유)를 따라야 한다.
이상적으로는 두 처리율의 합이 R과 같아야 한다.

→ 목적 : 동등한 대역폭 공유 선과 완전한 대역폭 이용선의 교차 지점 가까운 곳의 처리율을 얻는 것

1️⃣ TCP 윈도 크기가 어느 주어진 시점에서 연결 1과 2가 A 지점으로 나타내는 처리율을 실현한다고 하자.

두 연결에 의해 공동으로 소비되는 링크 대역폭의 양이 R보다 적기 때문에
어떠한 손실도 발생하지 않을 것이다.
양 연결은 TCP 혼잡 회피 알고리즘의 결과로서 RTT당 1 MSS씩 이들의 윈도우를 증가시킬 것이다.

따라서 두 연결의 공동 처리율은 A 지점에서 시작하는 45º 각도의 선을 따라서 계속되며,

2️⃣ 결국 두 연결에 의해 공동으로 소비되는 링크 대역폭은 R보다 커질 것이다. → 패킷 손실이 발생

(B 지점에 의해 나타내는 처리율을 실현할 때 패킷 손실을 경험한다고 하자)

그러므로 연결 1과 2는 반으로 그들의 윈도를 감소시킨다.

3️⃣ 결과적으로 실현된 처리율은 C 지점에 있게 되는데, 이는 B와 원점의 중간이다.

공동 대역폭 사용이 C 지점에서 R보다 낮으므로,
두 연결은 다시 C로부터 시작하는 45º 각도의 선을 따라 처리율을 증가시킨다.

4️⃣ 결국 손실은 다시 발생할 것이고(D 지점), 두 연결은 다시 반으로 윈도 크기를 감소시킨다.

즉, 두 연결에 의해 실현되는 대역폭은 동등한 대역폭 공유선을 따라서 결국에는 변동하며
2차원 공간 어디에 있든지 간에 상관없이 수렴한다.

→ 왜 TCP가 연결 사이에서 대역폭을 똑같이 공유하는지에 대한 직관적 느낌

위의 이상적인 시나리오와는 다르게,
현실에서는 클라이언트-서버 애플리케이션들은 링크 대역폭의 각기 다른 양을 얻을 수 있다.

특히 여러 연결이 공통의 병목 링크를 공유할 때,

더 작은 RTT를 갖는 세션은 대역폭이 좀 더 빠르게 비워지므로 링크에서 가용한 대역폭을 점유할 수 있고,
그래서 큰 RTT를 갖는 연결보다 더 높은 처리율을 갖는다.

공평성과 UDP

UDP는 혼잡 제어를 갖고 있지 않는다.

TCP의 관점에서 보면 UDP 상에서 수행되는 멀티미디어 애플리케이션은 공평하지 못하다.

즉, 다른 연결들과 협력하지도 않으며, 그들의 전송률을 적당하게 조절하지도 않는다.

TCP 혼잡 제어는 혼잡(손실) 증가에 대해 전송률을 감소시키므로,
그럴 필요가 없는 UDP 송신자들이 TCP 트래픽을 밀어낼 가능성이 있다.

→ UDP 트래픽으로 인해 인터넷이 마비되는 것을 방지하는 인터넷을 위한 혼잡 제어 방식의 개발이 필요하다.

공평성과 병렬 TCP 연결

UDP 트래픽이 공평하게 행동하도록 강요하더라도,
TCP 기반 애플리케이션의 다중 병렬 연결의 사용을 막을 방법이 없기 때문에 공평성 문제는 여전히 완전하게 해결되지 않는다.

애플리케이션이 다중 병렬 연결을 사용할 때는 혼잡한 링크 대역폭의 더 많은 부분을 차지한다.

3.8 트랜스포트 계층 기능의 발전

앞서 언급된 TCP들 뿐만 아니라, 더 많은 버전의 TCP가 존재한다.

여러 TCP 변형 프로토콜의 유일한 공통 특징은

TCP 세그먼트 포맷을 사용하고
네트워크 혼잡에 직면하여 서로 ‘공정하게’ 경쟁해야 한다는 점이다.

QUIC: 빠른 UDP 인터넷 연결

애플리케이션에서 필요로 하는 트랜스포트 서비스는

UDP가 제공하는 것보다 더 많은 서비스가 필요하지만,
TCP와 함께 제공되는 특정 기능들을 모두 원하지는 않거나 다른 서비스를 원할 수 있다.

애플리케이션 설계자는 애플리케이션 계층에 항상 ‘자신의 프로토콜을 확장’할 수 있다.

e.g., QUIC(Quic UDP Internet Connections) = 빠른 UDP 인터넷 연결

특히 QUIC은 보안 HTTP를 위한 트랜스포트 계층 서비스의 성능을 향상하기 위해
처음부터 새롭게 설계된 애플리케이션 계층 프로토콜이다.
오늘날 인터넷의 7% 이상이 QUIC이다.
신뢰적인 데이터 전송, 혼잡 제어 및 연결 관리를 위한 많은 접근 방식을 사용한다.

아래 그림을 통해 볼 수 있듯, QUIC은 UDP를 하위 트랜스포트 계층 프로토콜로 사용하는 애플리케이션 계층 프로토콜이며,
HTTP/2 버전 위에서 인터페이스되도록 설계되었다.

왼쪽 : 전통적인 보안 HTTP 프로토콜 스택 / 오른쪽 : 보안 QUIC 기반 HTTP/3 프로토콜 스택

가까운 장래에 HTTP/3은 기본적으로 QUIC을 통합할 것이다.

QUIC의 주요 기능

✅ 연결지향적이고 안전함

QUIC은 두 종단 간의 연결지향 프로토콜이다.

QUIC 연결 상태를 설정하기 위해 종단 간에 핸드셰이크가 필요
연결 상태의 두 부분 : 출발지와 목적지 연결 ID

QUIC은 연결 상태를 설정하는 데 필요한 핸드셰이크와 인증 및 암호화에 필요한 핸드셰이크를 결합하여,

먼저 TCP 연결을 설정한 다음
TCP 연결을 통해 TLS 연결을 설정하여

여러 RTT가 필요한 전통적인 보안 HTTP 프로토콜 스택보다 더 빠른 설정을 제공한다.

✅ 스트림

단일 QUIC 연결을 통해 여러 애플리케이션 레벨의 ‘스트림’들을 다중화할 수 있다.
QUIC 연결이 설정되면 새 스트림을 빠르게 추가할 수 있다.

✅ 신뢰적이고 TCP 친화적인 혼잡 제어 데이터 전송

QUIC은 각 QUIC 스트림에 대해 독립적으로 신뢰적인 데이터 전송을 제공한다.

이는 아래 그림에서 확인할 수 있다.

(a) HTTP/1.1

TCP의 RDT(신뢰적인 데이터 전송) 및 CC(혼잡 제어)상에서
애플리케이션 프로그램 레벨의 TLS 암호화를 사용하는 단일 연결 클라이언트 및 서버

TCP는 신뢰적이고 순서대로 바이트 전달을 제공하므로 여러 HTTP 요청이 목적지 HTTP 서버에서 순서대로 전달되어야 한다.

따라서 한 HTTP 요청의 바이트가 손실되면
나머지 HTTP 요청들은 손실된 바이트가 재전송되어 HTTP 서버에서 TCP가 올바르게 수신할 때까지 전달될 수 없다.
(= HOL 차단 문제)

(b) HTTP/3

UDP의 비신뢰적인 데이터그램 서비스상에서
QUIC의 암호화, 신뢰적인 데이터 전송 및 혼잡 제어를 사용하는 멀티스트림 클라이언트 및 서버

QUIC은 스트림별로 신뢰적이고 순서대로 전달하기 때문에
손실된 UDP 세그먼트는 해당 세그먼트에서 데이터가 전달된 스트림에만 영향을 준다.

즉, 다른 스트림의 HTTP 메시지는 계속 수신되어 애플리케이션에 전달될 수 있다.

QUIC은 TCP와 유사한 확인응답 메커니즘을 사용하여 신뢰적인 데이터 전송을 제공한다.

QUIC의 혼잡 제어는 TCP 리노 프로토콜을 약간 수정한 TCP 뉴리노(NewReno)를 기반으로 한다.

QUIC은 두 종단 사이에 신뢰적이고 혼잡 제어된 데이터 전송을 제공하는 애플리케이션 계층 프로토콜이다.

이는 ‘애플리케이션 프로그램 업데이트 시간 척도’면에서 QUIC으로 변경될 수 있음을 의미하며,

이는 TCP 또는 UDP 업데이트 시간 척도보다 훨씬 빠르다는 뜻이다.

Chapter 8 - 4. 종단점 인증, 5. 전자메일의 보안, 6. TCP 연결의 보안

ssun_bear — Wed, 10 Jul 2024 00:10:55 +0900

8.4 종단점 인증

종단점 인증이란 하나의 통신 개체가 다른 개체에게 자신의 신원을 컴퓨터 네트워크상으로 증명하는 작업이다.

예를 들어, 전자 메일 사용자가 서버에 신원을 입증할 수 있다.

서로 간의 인증은 인증 프로토콜의 한 부분으로서 교환된 메시지와 데이터만을 기반으로 수행되어야 한다.

대부분의 인증 프로토콜은 다른 프로토콜을 수행하기 전에 수행된다.

즉, 인증 후에 작업을 수행한다.

인증 프로토콜 ap(authentication protocol) 2.0

송신자가 이미 알려진 네트워크 주소(IP 주소)를 가지고 통신을 한다면 수신자는 인증 메시지를 가지고온 IP 데이터 그램 출발지 주소가 송신자의 IP 주소와 일치하는지 확인함으로써 앨리스를 인증할 수 있다.

그러나 IP 데이터그램을 생성해서 원하는 출발지 IP 주소를 넣고 그 데이터그램을 라우터로 보낼 수 있으므로 이는 안전하지 못하다.

예를 들어, 침입자가 가짜 출발지 주소를 쓰고 데이터를 보낼 수 있는데 이 방법은 IP 스푸핑의 한 형태이다.

침입자가 출발지 주소를 바꾸지 못하게 하면 되겠지만, 이는 강제할 수 없다.

인증 프로토콜 ap(authentication protocol) 3.0

인증자와 인증 받는 사람 간에 공유된 비밀번호를 사용할 수 있다.

지메일, 페이스북 등 많은 서비스가 비밀번호 인증을 사용한다.

그러나 이 프로토콜은 안전하지 못하다.

침입자가 송신자의 통신을 도청한다면 송신자의 비밀번호를 알아낼 수 있고, 이후 송신자인 척 할 수 있다.

인증 프로토콜 ap(authentication protocol) 3.1

비밀번호를 암호화하여 비밀번호를 엿듣는 것을 막을 수 있다.

송신자와 수신자는 대칭 비밀키를 공유하여 비밀번호를 암호화 복호화할 수 있다.

그러나 수신자는 재생 공격(playback attack)의 위험에 노출되어 있다.

침입자는 도청하여 송신자의 암호화된 비밀번호를 저장했다가 나중에 그대로 수신자에게 보낸다.

즉, 송신자인 척 할 수 있다.

인증 프로토콜 ap(authentication protocol) 4.0

넌스(nonce)는 프로토콜이 평생에 단 한 번만 사용하는 숫자를 뜻한다.

시나리오

송신자는 메시지를 보낸다.
수신자는 넌스 R을 선택하고 그것을 송신자에게 보낸다.
송신자는 대칭 비밀키를 이용하여 그 넌스를 암호화하고, 암호화된 넌스 K(R)을 수신자에게 보낸다.
- 해당 송신자가 다음에 또 통신을 하면 R이 바뀌어도 비밀키를 알고 있으므로 또 인증을 받을 수 있다.
- 그러나 침입자라면 비밀키를 모르고 있으므로 암호화할 수 없다.

8.5 전자메일의 보안

보안은 인터넷 프로토콜 스택 위쪽 4개 계층의 어느 곳에서나 보안 서비스를 제공할 수 있다.

보안이 특정 애플리케이션 계층 프로토콜을 위해 제공되면 그 프로토콜을 사용하는 애플리케이션은 보안 서비스를 사용할 수 있게 된다.

보안 기능이 하나 이상의 계층에서 제공되는 이유

보안은 네트워크 계층에서 제공하는 것으로 충분하지 않을까?

네트워크 계층에서 데이터그램의 모든 데이터를 암호화하고 IP 주소를 인증함으로써 ‘전면적 범위’의 보안을 제공하더라도 사용자 레벨의 보안은 제공할 수 없다.
- 예를 들어, 인터넷 상거래 사이트는 물건을 구입하려는 고객을 인증하는 데 IP 계층 보안에만 의존할 수는 없다.
프로토콜 상위 계층에서 보안 서비스를 포함한 새로운 인터넷 서비스를 구현하는 일이 점차 쉬워지고 있다.

8.5.1 보안 전자메일

보안 전자메일 시스템을 만들기 위해 암호화 원리들을 이용해보자.

기밀성

메시지를 대칭키 기술(AES,DES 등)으로 암호화 복호화하여 기밀성을 얻을 수 있다.

그러나 송수신자만 대칭키를 알기에 어렵기 때문에 공개키 암호화(RSA)를 고려하게 된다.

그러나 RSA를 통해 메시지를 암호화 복호화 한다면 계산 부하가 너무 심해서 실질적으로 쓸 수 없다.

이를 위해 세션키를 사용한다.

송신자는 임의의 대칭 세션키 Ks를 선택한다.
- 이 대칭 세션키는 AES나 DES에 사용된다.
Ks로 메시지 m을 암호화하여 암호문 1을 얻는다.
Ks는 송신자의 공개키로 암호화하여 암호문 2를 얻는다.
이 두개의 암호문을 수신자에게 보낸다.
수신자는 자신의 개인키로 암호문 1을 복호화하여 Ks를 얻을 수 있다.
얻은 Ks로 암호문 2를 복호화하여 m을 얻을 수 있다.

이렇게 기밀성을 얻을 수 있다.

송신자 인증과 메시지 무결성

이 둘을 얻기 위해 전자서명과 해시 알고리즘을 이용한다.

송신자는 메시지 요약문을 얻기 위해 m에 해시함수를 적용하여 H(m)을 얻는다.
전자 서명을 만들기 위해 해시의 결과를 자신의 개인키로 암호화한다.
메시지 m과 전자서명을 수신자에게 보낸다.
수신자는 송신자의 공개키로 전자서명을 복호화한다.
메세지 m에 해시 알고리즘을 적용한 결과와 4의 결과를 비교하여 같으면 보낸 사람을 확인할 수 있고, 메시지의 무결성을 확인할 수 있다.

통합

먼저 송신자 인증과 무결성 과정을 통해 얻은 메시지와 전자서명 꾸러미를 만든다.
이 꾸러미를 메시지 취급하여 기밀성 과정을 통해 수신자에게 전달한다.
수신자는 순서대로 복호화하여 확인한다.

그러나 수신자는 송신자의 공개키를 알아야하고, 송신자는 수신자의 공개키를 알아야 하므로 CA를 통해 공개키를 인증 받아야한다.

8.5.2 PGP(Pretty Good Privacy)

PGP는 암호화 기법의 좋은 예로 본질적으로 위 통합과 동일하다.

PGP가 설치되면 소프트웨어는 사용자를 위한 공개키 쌍을 만든다.
- 공개키는 사용자 웹사이트에 게시되거나 공개키 서버에 놓인다.
- PGP 공개키는 사용자간 신뢰의 그물(web of trust) 속에서 인증된다.
- 어떤 PGP 사용자들은 키 서명을 위한 모임을 열어 같은 물리적 공간에 모여서 공개키를 교환하고 그들의 개인키로 서명하는 것으로 서로의 키를 보증한다.
개인키는 비밀번호로 보호된다.
- 개인키를 사용하려면 사용자는 비밀번호로 인증해야한다.
PGP는 전자메일과 같은 방식으로 사용자에게 메시지를 전자서명하거나 암호화하거나 둘다 하거나 하는 선택지를 제공한다.
- 개인키, 공개키, 해시 알고리즘, RSA가 있으니 모두 가능하다.

8.6 TCP 연결의 보안: TLS

보안 서비스가 추가되어 향상된 TCP 버전을 흔히 TLS(Transport Layer Security) 라고 부른다.

TLS는 기밀성, 데이터 무결성, 서버인증과 클라이언트 인증을 통해 TCP를 향상하여 보안 서비스를 제공한다.

TLS는 TCP를 보호하기 때문에 TCP 상에서 일어나는 어떠한 애플리케이션에든 사용될 수 있다.

TLS는 소켓을 사용하는 간단한 API를 제공하는데, TCP의 API와 유사하다.

TLS는 애플리케이션 계층에 존재하나 개발자의 관점에서는 보안 서비스로 강화된 TCP 서비스를 제공하는 트랜스포트 프로토콜이다.

8.6.1 TLS 개요: almost TLS

TLS를 이해하기 위해 TLS의 단순화된 버전인 almost-TLS를 먼저 설명한다.

almost-TLS 는 핸드셰이크, 키 유도, 데이터 전송이라는 세 단계로 되어 있다.

핸드셰이크

클라이언트는 서버와 TCP 연결을 설립한다.
서버가 진짜 서버인지 확인한다.
- 클라이언트는 hello 메시지를 보내고, 서버는 CA로부터 인증된 인증서를 보내어 클라이언트는 인증서 내의 공개키가 서버의 것이라는 것을 믿을 수 있다.
TLS 세션에 필요한 모든 대칭키를 생성하기 위해 서버와 클라이언트가 사용할 주 비밀키(Master Secret, MS)를 생성하여 전송한다.
- MS를 보낼 때, 서버의 공개키로 암호화하여 EMS(Encrypted Master Secret)를 만든다.
- 서버는 자신의 개인키로 EMS를 복호화 하여 MS를 얻는다.
- 즉, 둘은 둘만 아는 MS를 알게 된다.

키 유도

공유한 MS는 모든 암호화와 데이터 무결성 검사를 위한 대칭 세션키로 사용될 수 있으나 일반적으로 각각 다른 암호화 키를 사용하는 것이 좀 더 안전하다.

따라서 MS를 이용하여 4개의 키를 만든다.

E(b) = 클라이언트가 서버에 보내는 데이터에 대한 세션 암호화 키
M(b) = 클라이언트가 서버에 보내는 데이터에 대한 세션 HMAC(메시지 인증 코드) 키
E(a) = 서버가 클라이언트에 보내는 데이터에 대한 세션 암호화 키
M(a) = 서버가 클라이언트에 보내는 데이터에 대한 세션 HMAC(메시지 인증 코드) 키

이는 단순히 MS를 4개의 키를 쪼개어 이루어진다.

2개의 암호화 키는 데이터를 암호화하고, 2개의 HMAC 키는 데이터 무결성을 확인하는 데 사용된다.

데이터 전송

TCP는 바이트 스트림 프로토콜이므로, TLS가 애플리케이션 데이터를 끊임없이 암호화하고 암호화된 데이터를 TCP에 쉴 새 없이 전달하는 것이 자연스럽다.

그렇다면 HMAC은 언제 해야할까?

분명한건 전체 세션 시간 동안 전송된 모든 데이터의 무결성을 확인하는 일이 TCP 세션이 종료될 때까지 미뤄둘 수 없다는 것이다.

TLS는 데이터 스트림을 레코드로 쪼개고 각 레코드에 무결성 검사를 위한 HMAC을 덧붙인 후 이 레코드+HMAC을 암호화한다.

HMAC을 생성하기 위해 클라이언트는 레코드 데이터와 키 M(b)를 해시 함수에 넣는다.

레코드+HMAC 꾸러미를 암호화 하기위해 E(b) 를 사용하여 TCP로 전송한다.

그러나 만약 침입자가 TCP 세그먼트 스트림에서 스트림을 삽입, 삭제, 교환할 수 있다면 위 방법은 안전하지 않다.

예를들어, 침입자가 2개의 세그먼트 순서를 바꾼 후 TCP 세그먼트 번호까지 그에 맞게 변경하여 서버에 보낸다면 서버의 TLS는 문제 없이 이를 애플리케이션 계층에 넘겨준다.

TLS는 순서번호를 이용해서 이 문제를 해결한다.

클라이언트는 순서 번호 카운터를 유지하며 TLS 레코드를 보낼 때마다 하나씩 증가시킨다.

HMAC을 계산할 때 HMAC 키 M(b)와 레코드 데이터와 순서 번호를 합친 결과의 해시로 사용한다.

서버는 클라이언트의 순서번호를 추적해서 자신의 HMAC 계산을 할 때 적절한 순서 번호를 포함시켜 레코드의 데이터 무결성을 확인한다.

TLS 레코드

첫 세 필드는 암호화되지 않는다.

타입 필드는 핸드셰이크 메시지인지 데이터를 담은 메시지인지 나타낸다.

8.6.2 TLS의 완전한 개념 : TLS

이제 완전한 버전의 TLS를 살펴보자.

TLS 핸드셰이크

TLS는 서버와 클라이언트에게 특정 대칭키 알고리즘이나 공개키 알고리즘을 사용하도록 강제하지 않는다.

대신 핸드셰이크 과정에서 암호화 알고리즘을 합의하고, 서로에게 넌스를 보내 세션키를 생성한다.

시나리오

클라이언트는 넌스와 함께 자신이 지원하는 암호화 알고리즘의 목록을 보낸다.
- 넌스를 사용하는 이유는 만약 침입자가 모든 메시지를 엿들은 후 그대로 서버에게 보내게 된다면, 순서번호를 둔다고 하더라도 그것 또한 그대로 일치하므로 서버에서는 똑같은 메시지를 한번 더 들은 것으로 인지하기 때문이다.
- 넌스를 포함하면 모든 메시지는 유일성을 가지게 되므로 보안에 안전해진다.
목록으로부터 서버는 대칭키 알고리즘, 공개키 알고리즘, HMAC 키와 함께 HMAC 알고리즘을 선택한다.
선택 결과와 인증서, 서버 넌스를 클라이언트에게 보낸다.
클라이언트는 인증서를 확인하고 서버의 공개키를 알아낸 후 PMS(Pre-Master-Secret)을 생성한다. 이 PMS를 서버의 공개키로 암호화한 후 서버에게 보낸다.
클라이언트와 서버는 같은 키 유도 함수를 사용하여 PMS와 넌스로부터 MS를 계산한다.
이 MS는 2개의 암호화 키와 2개의 HMAC 키를 생성하기 위해 분할된다.
이후 모든 메시지는 암호화되고 인증된다.
클라이언트는 모든 핸드셰이크 메시지의 HMAC을 전송한다.
서버는 모든 핸드셰이크 메시지의 HMAC을 전송한다.
- 8, 9번 과정은 처음 암호화되지 않은 메시지에 대한 침입자의 수정을 대비해서 지금까지 주고 받은 메시지의 일치 불일치를 확인하는 것이다.

연결 종료

단순히 바로 TCP FIN 세그먼트를 보내 종료시키면 문제를 발생시킬 수도 있다.

침입자가 임의로 TCP FIN 세그먼트를 보내 종료시키는 절단 공격 문제가 발생한다.

이를 해결하기 위해 레코드의 타입 필드에 그 레코드가 TLS 세션 종료를 수행할 것인지를 표시한다.

Chapter 8 - 7. 네트워크 계층 보안, 8. 무선 랜과 4G,5G 셀룰러 네트워크 보안, 9. 운영 보안

ssun_bear — Wed, 10 Jul 2024 00:10:38 +0900

8.7 네트워크 계층 보안: IPsec과 가상 사설 네트워크

IPsec이라고 알려진 IP 보안 프로토콜은 네트워크 계층의 보안을 제공한다.

IPsec 특징

호스트나 라우터 같은 네트워크 계층의 어떤 두 개체 사이에서 IP 데이터그램을 보호한다.
- 데이터그램의 페이로드 부분을 암호화하여 TCP 세그먼트 등이 암호화된다.
위의 기밀성을 제공하는 것처럼 출발지 인증, 데이터 무결성, 재생 공격 방지 같은 보안 서비스를 제공할 수 있다.

8.7.1 IPsec과 가상 사설 네트워크

흩어져있는 기관들은 그들의 호스트와 서버가 기밀성을 유지하며 안전하게 서로에게 데이터를 전송할 수 있도록 종종 자신만의 IP 네트워크를 갖기를 원한다.

이를 위해 공공 인터넷과 완전히 분리된 라우터, 링크, DNS 시스템을 포함하는 물리적으로 독립된 네트워크를 실제로 설치할 수 있고, 이러한 네트워크를 사설 네트워크(private network)라고 한다.

큰 유지 비용이 드는 사설 네트워크 대신 오늘날에는 기존 공공 인터넷 상에 VPN을 설치한다.

VPN 을 이용하면 기관의 사무실간 트래픽은 공공 인터넷을 통해 전송된다.

그러나 기밀성을 제공하기 위해 이 트래픽들은 공공 인터넷에 들어가기 전에 암호화된다.

공공 인터넷을 통과하지 않을 때는 평범한 IPv4 데이터그램이 사용되고, 통과해야할 때는 IPsec을 지원하는 라우터가 IPv4 데이터그램을 IPsec 데이터그램으로 바꾼 후 인터넷으로 전송한다.

IPsec 데이터그램은 전형적인 IPv4 헤더를 가지고 있어 공공 인터넷의 라우터는 IPv4 데이터그램과 똑같이 이를 전달한다.

실질적으로는 IPsec 데이터그램의 페이로드는 IPsec헤더를 포함하고, 이는 IPsec 처리를 위해 사용된다.

8.7.2 AH와 ESP 프로토콜

출발지 IPsec 개체가 보안 데이터그램을 목적지 개체에 보낼 때 AH 프로토콜이나 ESP 프로토콜을 사용한다.

AH프로토콜
- 출발지 인증과 데이터 무결성을 제공하지만, 기밀성을 제공하지 않는다.
ESP 프로토콜
- 출발지 인증과 데이터 무결성, 기밀성을 제공한다.
- 대부분 기밀성을 필요로 하여 널리 사용된다.

8.7.3 SA

IPsec 데이터그램을 전송하기전 출발지 개체와 목적지 개체는 네트워크 계층에서 논리적 연결을 설립하는데 이것이 바로 SA(security association)이다.

SA는 단방향이어서 서로에게 데이터를 보내기 위해서는 두개의 SA가 필요하다.

기관 내에 n개의 호스트가 있다면, SA는 2n개 그리고 지점의 라우터가 m개가 있다면 추가로 2m개 즉, 2n + 2m개 필요하다.

게이트웨이 라우터나 랩톱이 인터넷으로 보내는 모든 트래픽이 IPsec 방식으로 보호되지는 않는다.

예를 들어, 보안이 필요한 기관 내의 호스트가 아닌 구글 등의 공공 인터넷의 웹서버에 접속할 수도 있기 때문에 라우터나 랩톱은 IPv4 데이터그램과 IPsec 모두를 전송한다.

R1은 SA에 대해 다음과 같은 상태 정보를 포함한다.

SA에 대한 32 비트 식별자 SPI
SA 시작점의 인터페이스(200.168.1.100)와 최종점의 인터페이스(193.68.2.23)
사용되는 암호화 타입 (AES, DES 등)
암호화 키
무결성 검사 타입 (MD5, SHA 등)
인증키

이들을 사용해 암호화하고, 인증을 하며 R2도 마찬가지로 같은 상태정보를 유지한다.

SA가 많을 수 있어 그 상태정보를 유지해야하는데 IPsec 개체는 모든 SA에 대한 상태 정보를 그 개체의 OS 커널에 있는 SAD(security association Database)라는 데이터 구조에 저장한다.

8.7.4 IPsec 데이터그램

라우터 R1은 원본 IPv4 데이터그램을 IPsec 데이터그램으로 변환하기 위해 다음 과정을 이용한다.

원래 IPv4 데이터그램의 뒤에 ESP 트레일러를 덧붙인다.
- 원래 IPv4 데이터그램에 원래 목적지 IP 주소, 출발지 IP 주소가 들어가 있다.
- ESP 트레일러는 패딩, 패딩 길이, 다음 헤더라는 3개의 필드로 이루어져 있다.
  - 패딩 : 원래 데이터그램에 덧붙어 최종 메시지가 정수개의 고정 길이 블록으로 분할될 수 있게 한다.
  - 패딩 길이 : 패딩 비트가 얼마나 삽입되었는지 알려주고, 이를 이용해 패딩을 삭제한다.
  - 다음 : 페이로드에 포함된 데이터의 타입(ex: UDP)을 지시한다.
SA에 의해 지정된 알고리즘과 키를 이용하여 위 결과를 암호화한다.
암호화된 결과의 앞에 ESP 헤더 필드를 덧붙인다. 결과로 나온 패키지를 엔칠라다라고 부르자.
- ESP 헤더에는 SPI와 순서번호를 포함한다.
  - SPI : 수신 개체에게 데이터그램이 어느 SA에 속해 있는지 지시한다. 이 SPI를 가지고 자신의 SAD를 검색하여 알맞은 인증 및 복호화 알고리즘과 키를 결정한다.
  - 순서 번호 : 재생 공격을 막기 위해 새용된다.
SA가 지정한 알고리즘과 키를 이용하여 전체 엔칠라다에 대한 인증 MAC을 생성한다.
엔칠라다 뒤에 MAC을 붙여 페이로드를 만든다.
- 비밀 MAC 키를 엔칠라다에 붙이고 그 결과에 대해 고정 길이의 해시를 계산한다.
전형적인 IPv4 헤더 필드를 가지고 완전히 새로운 IP 헤더를 만들어 위의 페이로드 앞에 붙인다.
- 새로운 IP 헤더에는 출발지와 목적지 주소는 전달될 라우터 인터페이스의 주소가 들어간다.
- 헤더 필드의 상위 프로토콜 값으로는 TCP,UDP 등을 나타내지 않고 이것이 ESP 프로토콜을 사용하는 IPsec임을 나타내는 값을 사용한다.

결과로 나온 IPsec 데이터그램은 전형적인 IPv4 헤더를 가지고 페이로드가 따라오는 진짜 IPv4 데이터그램이다.

전달하는 라우터들은 IPsec으로 암호화된 정보라는 것을 모른체 목적지 라우터 인터페이스로 이를 전달한다.

라우터 R2는 IPsec 데이터 그램을 받으면 다음과 같은 과정을 수행한다.

IP 헤더를 보고 IPsec ESP 프로토콜을 적용해야함을 알게된다.
엔칠라다를 들여다보고 R2는 SPI를 이용하여 데이터그램이 어느 SA에 속한것인지 알아낸다.
엔칠라다의 MAC을 계산하여 ESP MAC 필드의 값과 일치하는지 확인한다.
- 일치하여야 조작되지 않은 것이다.
데이터그램이 재생된 것이 아닌지 순서 번호 필드를 검사한다.
SA와 관련된 복호화 알고리즘과 키를 이용하여 암호화된 부분을 복호화한다.
원래의 IP 데이터그램을 최종 목적지로 전송하기 위해 지점 네트워크로 전달한다.

IPsec 개체는 SAD와 함께 SPD(security policy database)라 불리는 자료구조를 유지한다.

SPD는 어떤 형태의 데이터그램(출발지 IP 주소, 목적지 IP 주소, 프로토콜 타입으로 결정)이 IPsec으로 처리되어야 하는지와 그때 사용될 SA를 지시한다.

즉, SPD의 정보는 도착한 데이터그램으로 무엇을 할지 알려주고, SAD의 정보는 어떻게 할 것인지를 알려준다.

8.7.5 IKE : IPsec에서의 키 관리

수백 수천 개의 IPsec 라우터와 호스트로 이루어진 큰 VPN에서는 종단점의 SAD에 직접 SA 정보를 입력 하는 방법은 불가능하다.

즉, SA를 생성하는 자동화된 방법이 필요한데 이 방법으로 IKE 프로토콜을 이용한다.

각 IPsec 개체는 그 개체의 공개키가 포함된 인증서를 갖는다.

SSL 에서와 마찬가지로 IKE 프로토콜은 두 개체가 인증서를 교환하고 인증과 암호화 알고리즘에 대한 협상을 하게 하며 IPsec SA의 세션키를 생성하기 위한 중요한 자료를 안전하게 교환할 수 있게 한다.

IKE는 이러한 작업을 수행하기 위해 두단계를 거친다.

첫번째 단계

R1과 R2는 메시지 쌍을 두 번 교환한다.

첫 번째 메시지 교환시에는 양측이 라우터 사이의 IKE SA를 설립하기 위해 디피-헬만 알고리즘을 사용한다.
- IKE SA는 IPsec SA와는 완전히 다르다.
- IKE SA는 두 라우터 사이에 인증되고 암호화된 채널을 제공한다.
- 이 첫 번째 메시지를 교환하는 동안 IKE SA의 암호화와 인증을 위한 키가 설립된다.
- 또한, 두번째 단계에서 IPsec SA 키를 계산하기 위해 사용될 주 비밀키도 만들어진다.
- 첫번째에서는 누구도 비밀키로 서명함으로써 자신의 신분을 드러내지 않는다.
두번째 교환에서는 양측이 메시지에 서명하여 서로에게 신분을 드러낸다.
- 그러나 메시지가 보안 처리된 IKE SA 채널을 통해 전송되므로 단순한 도청자에게는 신분이 누설되지 않는다.
- 양측이 IPsec SA에 의해 사용될 IPsec 암호화 및 인증 알고리즘에 대해 협의한다.

두번째 단계

양측이 각 방향으로 하나씩 SA를 설립한다.

이 단계를 마칠 때는 이 2개의 SA에 대한 암호화 및 인증 세션키가 양측에 만들어져있다.

이후 보안 처리된 데이터그램을 만들기 위해 SA를 사용할 수 있다.

8.8 무선 랜과 4G/5g 셀룰러 네트워크 보안

8.8.1 802.11(와이파이) 무선 랜의 인증키와 키 합의

802.11 네트워크에서 다루어야 할 핵심적인 보안 관심사

상호인증
- 이동 장치가 AP에 접속하여 데이터그램을 외부에 전송하기 전에, 네트워크는 접속하는 이동 장치의 신원을 확인하고, 그 장치의 접속 권한을 점검하기 위해 장치를 인증하기를 원한다.
- 이동장치의 경우도 접속하는 네트워크가 진짜 접속을 원하는 네트워크가 맞는지 인증하기를 원한다.
- 이런 양방향 인증을 상호 인증이라고 한다.
암호화
- 802.11 프레임은 무선 채널을 통해 교환되기 때문에, 이동 장치와 AP 간에 교환되는 사용자 레벨 데이터를 지니고 있는 링크 레벨 프레임의 암호화가 중요하다.
- 높은 속도를 요해 대칭키 암호화가 사용된다.

상호 인증과 암호화 키 생성 및 사용 절차

발견
- AP는 자신의 존재와 함께 이동 장치에게 제공될 수 있는 인증과 암호화 형식을 알린다.
- 이동 장치는 원하는 인증과 암호화 형식을 요청한다.
상호 인증과 공유 대칭키 생성
- 인증 서버와 이동 장치 간에 이미 공유된 공통의 비밀을 갖고 있다고 가정한다.
- 이동 장치와 인증 서버는 서로 간의 인증에 넌스와 암호화 해싱 등과 함께 공유 비밀을 이용하게 된다.
- 이동 장치와 AP 간의 무선 링크를 통해 전송될 프레임의 암호화에 사용될 공유 세션키를 생성한다.
공유 대칭 세션키 분배
- 대칭 비밀키는 이동 장치와 인증 서버에서 생성되기에, 인증 서버가 AP에게 공유 대칭 세션키를 알려주기 위한 프로토콜이 필요하다.
AP를 통한 이동 장치와 원격 호스트 간의 암호 통신
- 2단계와 3단계에서 생성되고 분배된 세션키를 사용하여 암호화된 링크 계층 프레임을 가지고 통신이 이루어 진다.
- 프레임 데이터를 암호화 복호화하기 위해 AES 대칭키 알고리즘을 사용한다.

상호 인증과 공유 대칭키 생성

초기 802.11 보안 규정 WEP은 심각한 보안 오류가 있었고, 이를 극복하기위해 WPA1이 개발되었다.

WPA1은 메시지 동질성 검사와 사용자가 일정 기간 암호화된 메시지 스트림을 관찰하여 암호화 키를 추측하게 하는 공격을 피하는 것을 도입하였다.

WPA2는 AES 대칭키 암호화를 의무화하여 WPA1을 개선했다.

위 그림은 간략한 네 방향 핸드셰이크 프로토콜을 보여준다.

공유 비밀키(ex 비밀번호)를 서로 알고 시작한다.

인증 서버는 넌스를 생성하여 이동 장치로 전송한다.
이동 장치는 넌스를 AS로부터 전송받고 자신의 넌스를 생성한다. 이동 장치는 자신의 넌스, 받은 넌스, 최초 공유 비밀 키, 이동 장치의 MAC 주소, AS의 MAC 주소를 사용하여 대칭형 공유 세션키를 생성해낸다. 그런 후 자신의 넌스그리고 받은 넌스와 원래의 공유 비밀을 암호화한 HMAC-signed 값을 전송한다.
인증 서버는 최근에 전송한 넌스의 HMAC-signed 버전을 보아 이동 장치가 공유 비밀키로 암호화를 할 수 있었고, 인증 서버 또한 이동 장치가 주장하는 본인이라는 것을 알게되어 이동 장치를 인증하게 된다. 자신의 넌스, 받은 넌스, 최초 공유 비밀 키, 이동 장치의 MAC 주소, AS의 MAC 주소를 사용하여 대칭형 공유 세션키를 사용해 똑같은 대칭형 공유 세션키를 만들 수 있다.

만든 대칭형 공유 세션키를 AP에 공유하여 이동 장치와 AP는 서로 데이터를 주고 받을 수 있다.

802.11 보안 메시징 프로토콜

위 그림은 802.11 보안 프레임워크를 구현하기 위해 사용된 확장 인증 프로토콜(Extensible Authentication Protocol, EAP)를 보여준다.

이 프로토콜은 종단 간의 메시지 포멧을 정의한다.

EAP 메시지들은 EAPoL을 사용하여 캡슐화되어 무선 링크로 전송된다.

이러한 EAP 메시지들은 AP에서 역캡슐화되며, RADIUS 프로토콜을 사용하여 재캡슐화되어 UDP/IP를 통해 인증 서버로 전송된다.

8.8.2 4G/5G 셀룰러 네트워크에서의 인증과 키 동의

4G/5G 환경에서의 상호 인증과 키 생성의 목적들은 802.11 환경에서와 동일하다.

4G 인증과 키 동의 프로토콜

HSS에 인증 요청
- 이동 장치가 기지국을 경유하여 네트워크에 처음으로 접속 요청을 할 때, 이동성 관리 개체로 전달되는 기기의 국제 이동 가입자 식별자(IMSI)를 포함하는 접속 메시지를 보낸다.
- MME는 IMSI와 방문지 네트워크 관련 정보를 HSS로 보낸다.
HSS로부터의 인증 응답
- HSS는 사전 공유 비밀키를 사용하여 인증토큰인 auth_token과 예상되는 인증 응답인 xres를 유도하기 위해 암호화 동작을 수행한다.
- auth_token은 이동 장치로 하여금 auth_token을 계산한 누구든지 비밀키를 알고 있다는 사실을 인지하게 하는 사전 공유 비밀키를 사용하여 HSS가 암호화한 정보를 포함한다.
- 즉, auth_token은 사전공유키 K(IMSI)이고, 같은 사전 공유키를 가지고 있으면 IMSI를 알 수 있어 HSS가 비밀키를 알고 있음을 인지하고, 이동장치는 인증된다.
- xres는 이동 장치가 계산에 필요해지는 값을 포함하고 있으며 MME에게 이동 장치가 비밀키를 알고 있음을 증빙하여 MME에게 이동 장치가 인증된다.
- MME만이 인증 응답 메시지를 받고, 향수 사용을 위해 xres를 저장하고, 인증 토큰을 추출하여 이동 장치에 전송하는 중간자 역할을 한다.
이동 장치로부터의 인증 응답
- 이동 장치는 auth_token을 사전 공유키로 복호화하여 IMSI를 얻어 HSS를 인증한다.
- 이동 장치는 res값을 계산하여(자신의 비밀키를 활용하여) 그 값을 MME에게 보낸다.
이동장치 인증
- MME는 이동 장치가 계산한 res와 HSS가 계산한 xres를 비교하여 일치하면 모두 공통 비밀키를 갖고 있음을 증빙한 것이므로 이동 장치가 인증된다.
- MME는 기지국과 이동 장치에게 상호 인증이 완료되었음을 알리고, e단계에서 사용할 기지국 키를 보낸다.
데이터 평면과 제어 평면 키 도출
- 이동 장치와 기지국은 무선 채널을 통해 프레임 전송에 사용될 암/복호화 키들을 각자 결정한다.

8.9 운영 보안: 방화벽과 침입 탐지 시스템

8.9.1 방화벽

방화벽(firewall)은 전체 인터넷으로부터 기관의 내부 네트워크를 분리시킨 하드웨어와 소프트웨어의 조합으로, 어떤 패킷은 통과가 허용되나 어떤 패킷은 차단된다.

네트워크 관리자가 해당 네트워크에 대한 트래픽 출입을 관리하여 접속을 제어한다.

방화벽의 목표

외부와 내부를 오가는 모든 트래픽은 방화벽을 거친다.
로컬 보안 정책에 정의된 대로 승인된 트래픽만이 통과가 허용된다.
방화벽 자체가 침입 시도에 안전해야 한다.

전통적인 패킷 필터

기관은 일반적으로 내부의 네트워크를 ISP에 연결하는 게이트웨이 라우터를 갖는다.

외부와 내부를 오가는 모든 트래픽은이 라우터를 지나야만 하고, 이 라우터에서 패킷 필터링이 일어난다.

필터링 결정의 근거

IP 출발지 또는 목적지 주소
- 불행히 출발지 주소를 위장한 데이터그램을 막을 수 없다.
IP 데이터그램 내의 프로토콜 타입 : TCP,UDP OSPF 등
TCP 또는 UDP 출발지와 목적지 포트
TCP 플래그 비트 : SYN, ACK
- ACK 비트가 0인 입력 세그먼트를 거른다면 외부에서 오는 모든 TCP 연결은 거부하고, 내부에서 나가는 건 허락한다.
ICMP 메시지 타입
네트워크에서 나가는 데이터그램과 들어오는 데이터그램에 대한 서로 다른 규칙들
서로 다른 라우터 인터페이스에 대한 서로 다른 규칙들

네트워크 관리자는 기관의 정책에 기초해서 방화벽을 설정한다.

예를 들어, 공개 웹 서버 접속 목적을 제외한 어떠한 TCP 연결도 받고 싶지 않다면, 목적지 포트 80번과 웹 서버에 해당하는 목적지 주소를 가진 TCP SYN 세그먼트를 제외한 모든 TCP SYN 세그먼트를 막을 수 있다.

방화벽의 규칙은 접속 제어 목록과 함께 라우터에 구현된다.

상황 고려 패킷 필터

상황 고려 필터는 TCP 연결을 추적하여 이 정보를 패킷 차단 결정을 하는 데 이용한다.

상황 고려 필터는 연결 고려 테이블에 있는 진행 중인 모든 TCP 연결을 추적함으로써 전통적인 패킷 필터에서 통과되던 패킷도 관리한다. (관리하지 않는다면 Dos 공격 등을 막을 수 없다.)

예를들어, SYN,SYNACK,ACK,FIN을 관찰하여 연결이 60초 동안 사용되지 않는다면 그 연결은 이미 종료되었다고 가정할 수 있다.

상황 고려 필터는 접속 제어 목록에 연결 검사라는 새로운 열을 포함한다.

예를 들어, 외부에서 조작된 패킷을 TCP 출발지 포트 80번, ACK 플래그를 1로 설정하여 내부로 보내려고 한다고 해보자.

전통적인 패킷 필터는 이를 막을 수 없지만 상황 고려 필터는 연결 검사를 열을 통해 외부에서 들어오는 패킷을 연결 검사 테이블에서 연결된 상태인지 확인하고 조작된 패킷은 연결 검사 테이블에 없으므로 필터링된다.

애플리케이션 게이트웨이

좀 더 세밀한 수준의 보안을 위해 방화벽은 패킷 필터를 애플리케이션 게이트웨이와 결합해야 한다.

애플리케이션 게이트웨이는 모든 애플리케이션 데이터가 반드시 통과해야 하는 애플리케이션 맞춤 서버다.

다수의 애플리케이션 게이트웨이가 같은 호스트에서 실행될 수 있으나 각 게이트웨이는 자신만의 프로세스들을 가진 분리된 서버다.

제한된 내부 사용자만 외부로의 텔넷이 가능하게 하고 모든 외부 클라이언트는 내부로 텔넷을 수행하지 못하게 하는 방화벽을 설계해보자.

애플리케이션 게이트웨이의 IP주소로부터 시작된 텔넷 연결을 제외하고 모든 텔넷 열결 시도를 막도록 라우터의 필터를 설정한다.
- 이는 외부로의 모든 텔넷 연결이 애플리케이션 게이트웨이를 통과하게 한다.
사용자는 먼저 애플리케이션 게이트웨이와 텔넷 세션을 설정한다.
게이트웨이에는 입력되는 텔넷 세션 요청을 듣고 있는 애플리케이션이 있어서 사용자에게 ID와 비밀번호를 요구한다.
사용자가 입력하면, 애플리케이션 게이트웨이는 그 사용자가 외부로의 텔넷 연결이 효용되어있는지 검사한다.
- 허가되지 않았다면, 게이트웨이에 의해 종료된다.
- 허가되었다면, 사용자가 원하는 외부 호스트의 이름을 묻고, 게이트웨이와 외부 호스트 간의 텔넷 연결을 설정한 후 내부 사용자에게서 오는 데이터를 외부 호스트에게 전달한다.
- 즉, 애플리케이션 게이트웨이는 인증 뿐만 아니라 데이터 전달도 수행한다.

단점

각 애플리케이션마다 서로 다른 애플리케이션 게이트웨이를 필요로 한다.
모든 데이터가 게이트웨이를 경유하여 중계되므로 성능상의 손실이 있다.
클라이언트 소프트웨어는 사용자가 요구할 때 어떻게 게이트웨이와 통신할 수 있는지 알아야 하며, 어떤 외부 서버에 연결할지 애플리케이션 게이트웨이에게 알려줄 수 있어야 한다.

익명성과 사생활 보호

자신의 IP 주소를 웹사이트에 남기고 싶지 않고 지역 ISP에 그 웹사이트에 방문한 사실을 남기고 싶지 않은 익명성을 원한다면 어떻게 해야할까?

신뢰할 수 있는 프록시 서버와 SSL의 조합을 사용할 수 있다.

프록시와 SSL 연결을 설립한 후 이 연결을 통해 희망하는 사이트에 대한 HTTP 요청을 전송한다.
프록시가 SSL로 암호화된 HTTP 요청을 복호화 해서 평문 형식의 HTTP 요청을 웹사이트로 전송한다.
웹사이트는 프록시로 응답을 보내고, 프록시는 SSL을 통해 응답을 호스트에게 보낸다.

그러나 프록시는 결국 모든 것을 알고 있으므로 신뢰할 수 있는 프록시 서버를 사용하는 것이 중요하다.

8.9.2 침입 탐지 시스템

통과하려는 패킷 헤더를 살펴볼 뿐만 아니라 자세한 패킷 관찰을 수행하는 새로운 틈새 장치에 대한 요구가 있다.

악의적일 수 있는 트래픽을 발견했을 때 경고를 발생시키는 장치를 침입 탐지 시스템(intrusion detection system,IDS)이라고 한다.

의심스러운 트래픽을 걸러내는 장치는 침입 방지 시스템(intrusion prevention system ,IPS)이라고 한다.

이 둘의 중요한 점은 어떻게 의심스러운 트래픽을 발견하느냐 이므로 두 시스템을 통틀어 IDS 시스템으로 호칭한다.

한 기관에서 IDS는 여러개일 수 있는데, 서로 협조하며 의심스러운 트래픽이 있을 땐 중앙 IDS 프로세서에 전달되어 네트워크 관리자에게 전달된다.

위 그림은 패킷 필터와 애플리케이션 게이트웨이에 의해 보호되고 IDS에 의해 감시되는 높은 보호 구역과 패킷 필터와 IDS만을 사용하는 낮은 구역으로 나눌 수 있다.

IDS는 지나가는 각각의 패킷을 수만 개의 시그니처와 비교해야하기 때문에 많은 연산이 필요하고 IDS를 안쪽에 위치시켜 전체 트래픽 중 일부만 관찰하면 되도록 한다.

시그니처 기반 시스템

시그니처 기반 IDS는 공격 시그니처에 대한 방대한 데이터베이스를 유지한다.

각 시그니처는 침입 행위에 관련된 규칙들의 집합이다.

시그니처는 단순히 단일 패킷에 대한 특징의 목록일 수도 있고, 연속된 일련의 패킷들에 관련한 것일 수도 있다.

네트워크 관리자는 시그니처를 자신에 맞게 수정하고 그것을 데이터베이스에 추가할 수 있다.

시그니처 기반 IDS는 지나가는 모든 패킷을 읽어 데이터베이스 내의 시그니처들과 비교한다.

만일 어떤 패킷이 데이터베이스 내의 시그니처와 일치하면 경고를 발생시킨다.

그러나 이 방법은 새로운 공격에 대해 대비할 수 없고, 모든 패킷이 데이터베이스와 비교되어야하므로 성능이 좋지 않다.

이상 기반 IDS

트래픽을 관찰할 때 트래픽 분석표를 만든다.

그 후 ICMP 패킷의 빈도가 지나치게 높다든지 포트 정보 수집과 ping 메시지가 갑자기 증가하는 등 통계학적으로 비정상적인 패킷의 스트림을 찾는다.

Chapter 7 - 1. 개요, 2. 무선 링크와 네트워크의 특징, 3. 와이파이

ssun_bear — Wed, 10 Jul 2024 00:00:51 +0900

무선 네트워크의 요소

무선 네트워크는 다음과 같은 구성 요소로 이루어진다.

무선 호스트

무선 호스트(wireless host)는 유선 네트워크의 경우처럼 애플리케이션을 실행하는 종단 시스템 장치다.

e.g., 스마트폰, 태블릿, 랩톱, 센서 등의 IoT(Internet of Things) 장치, 가전제품, 자동차, 그 외 인터넷에 연결된 무수히 많은 장치

무선 링크

호스트는 무선 통신 링크(wireless communication link)를 통해 기지국(base station)이나 다른 무선 호스트에 연결된다.

위 그림에서 무선 링크는 네트워크 가장자리에 있는 호스트를 코어에 있는 네트워크 인프라스트럭처로 연결해준다.

무선 링크는 때로는 네트워크 코어에서도 라우터, 스위치 등 네트워크 장치들 사이를 연결해주는 데 사용될 수 있다.

기지국

기지국(base station)은 기지국에 결합된 무선 호스트와의 데이터(e.g., 패킷) 송수신에 대한 책임을 진다.

즉, 자신과 결합되어 있는 다수의 무선 호스트들 사이의 전송을 중재하고 조정한다.

무선 호스트가 어떤 기지국에 ‘결합(association)되어 있다’는 것은 아래 두 가지를 의미한다.

호스트가 해당 기지국의 무선 통신 영역 안에 있다.
호스트가 자신과 네트워크 간의 데이터 중계(relay)를 위해 해당 기지국을 사용한다.

기지국의 예

셀룰러 네트워크에서의 셀 타워(cell tower)
무선 네트워크에서의 AP(access point)

인프라스트럭처 방식

기지국에 접속된 호스트는 인프라스트럭처 방식(infrastructure mode)으로 동작한다고 한다.

이는 주소 할당이나 라우팅 등 기존의 모든 네트워크 서비스가 기지국을 통해 네트워크에 연결된 호스트에게 제공되기 때문이다.

이에 반해 애드혹 네트워크(ad hoc network)의 경우 무선 호스트는 연결할 수 있는 이런 인프라스트럭처가 없다.

이때 호스트는 스스로 라우팅, 주소 할당, DNS 방식의 이름-주소 변환 등의 서비스를 수행해야 한다.

핸드오프 (핸드오버)

이동 호스트가 한 기지국 영역을 벗어나 다른 기지국 영역으로 이동하는 경우, 중심부에 있는 큰 네트워크로의 접속점을 변경(결합된 기지국을 변경)해야 한다.

이 과정을 핸드오프(handoff) 또는 핸드오버(handover)라고 한다.

네트워크 인프라스트럭처

무선 호스트가 통신하고자 하는 큰 네트워크다.

무선 네트워크의 종류

무선 네트워크를 이루는 요소들은 다양한 방식으로 결합되어 여러 가지 형태의 무선 네트워크를 형성할 수 있다.

우리는 다음의 두 가지 기준에 따라 무선 네트워크를 크게 몇 종류로 분류할 수 있다.

무선 네트워크 내의 패킷이 하나의 홉만을 거치는가 여러 홉을 거치는가?
기지국과 같은 네트워크 인프라스트럭처가 있는가, 없는가?

단일 홉, 인프라스트럭처 존재

좀 더 큰 유선 네트워크와 연결된 기지국을 갖고 있다.
모든 통신은 이 기지국과 무선 호스트 사이에 단일 무선 홉으로 이루어진다.
e.g.,
- 802.11 네트워크 : 교실, 음식점, 도서관 등에서 사용
- 4G LTE 네트워크

단일 홉, 인프라스트럭처 없음

유선 네트워크가 연결된 기지국이 없다.
단일 홉 네트워크 안의 하나의 노드가 다른 노드들의 전송을 중재, 조정할 수 있다.
e.g., 블루투스 네트워크 : 키보드, 스피커, 헤드셋 등 작은 무선 장비들을 연결

다중 홉, 인프라스트럭처 존재

좀 더 큰 네트워크와 연결된 기지국이 존재해야 한다.
일부 노드들은 기지국와 통신하기 위해 다른 무선 노드들의 중계를 거쳐야 한다.
e.g.,
- 일부 무선 센터 네트워크(wireless sensor network)
- 무선 메시 네트워크(wireless mesh network)

다중 홉, 인프라스트럭처 없음

기지국이 없다.
노드들은 메시지를 목적지에 보내기 위해 여러 노드들의 중계를 거칠 수 있다.
노드들은 이동성이 있어 노드들 간의 연결성이 변화할 수 있다.
이러한 형태의 네트워크는 이동 애드혹 네트워크(mobile ad hoc network, MANET)라고 한다.

책에서는 주로 단일 홉 네트워크와 인프라스트럭처가 있는 네트워크에 논의를 한정한다.

7.2 무선 링크와 네트워크의 특징

무선 링크는 유선 링크와 다르게 추가로 고려해야 하는 것들이 존재한다.

신호 세기의 감소, 경로 손실

전자기파는 물체를 통과함에 따라 약화된다.
자유 공간에서도 전자기파 신호는 분산되고,
송신자와 수신자 사이의 거리가 증가함에 따라 신호의 세기가 감소한다.

이런 현상을 경로 손실(path loss)이라고도 한다.

다른 출발지로부터의 간섭

동일 주파수 대역으로 전송되는 무선 신호들은 서로 간섭하게 된다.
이러한 송신자 간의 간섭 외에 주변의 전자기 잡음(e.g., 근처의 모터 또는 전자레인지로 인한) 등도 간섭을 일으킬 수 있다.

이런 이유로 최근의 802.11 표준들은 5 GHz 대역에서 동작한다.

다중 경로 전파

송신자와 수신자 간에 전송되는 전자기파의 일부가 물체나 지표에 부딪혀서
서로 길이가 다른 여러 개의 경로를 겨처갈 때 다중 경로 전파(multipath propagation) 현상이 생긴다.

이는 수신 측에서 감지되는 신호를 또렷하지 않게 만든다.

이들을 통해 알 수 있듯이, 유선 링크보다는 무선 링크에서 비트 오류가 더 자주 발생한다.

따라서 802.11을 포함한 무선 링크 프로토콜은 강력한 CRC 오류 검출 코드를 사용할 뿐만 아니라
손상된 프레임을 재전송해주는 링크 레벨의 신뢰성 있는 데이터 전송 프로토콜을 사용한다.

SNR, BER

SNR(signal-to-noise ratio)

측정된 수신 신호의 세기와 잡음의 상대적인 비율

단위 : 데시벨(dB)
(수신 신호의 진폭과 잡음의 진폭에 각각 밑이 10인 로그함수를 취한 비율의 20배)
SNR 값이 커질수록 수신 측에서는 잡음에도 불구하고 원하는 신호를 추출하기 쉬워진다.

비트 오류율, BER(bit error rate)

송신된 비트가 수신 측에서 오류로 검출될 확률

아래 그림은 이상적인 무선 채널에서 세 가지 변조(modulation) 기법의 비트 오류율을 나타내는 BER 값과 SNR 값의 관계를 보여준다.

동일한 변조 기법 내에서는 SNR 값이 높을수록 BER 값이 낮아진다

이는 송신자가 출력 세기를 높이면 SNR 값이 커지고,
동시에 수신된 비트에서 오류가 발생할 확률은 낮아지기 때문이다.

그러나 출력 세기를 어느 임계점 이상으로 높이는 것은 이득이 없다.

출력 세기를 높이는 것의 단점은 다음과 같다.

출력 세기를 높일수록 송신 장치에서 더 많은 에너지가 소모되며, 이는 배터리를 사용하는 이동 통신 사용자에게는 중요한 문제다.
출력 세기를 높이면 다른 송신자의 전송과 더 많은 간섭이 생길 수 있다.

동일한 SNR 값에서는 높은 전송률을 갖는 변조 기법이 더 높은 BER 값을 갖는다

위 그림에서 SNR 값이 10 dB일 때를 보자.

1 Mbps 전송률의 BPSK 변조 기법의 BER 값 = 10^(-7) 이하
4 Mbps 전송률의 QAM16 변조 기법의 BER 값 = 10^(-1)

10^(-1)는 실제 사용하기에는 지나치게 높은 오류율이기 때문에, 이 환경에서는 BPSK 변조 기법이 더 선호된다.

반대로, SNR 값이 20 dB일 때를 보자.

1 Mbps 전송률의 BPSK 변조 기법의 BER 값은 표시되지도 않을 정도로 낮다.
4 Mbps 전송률의 QAM16 변조 기법의 BER 값 = 10^(-7)

만약 10^(-7) 정도의 BER 값이 별문제가 없다면 이 환경에서는 높은 전송률을 갖는 QAM16 변조 기법이 더 선호된다.

이러한 고찰을 기반으로 다음에 기술한 마지막 특성이 도출된다.

변조 기술을 채널의 조건에 적합하도록 유연하게 적응시키기 위해 물리 계층 변조 기법의 동적인 선택이 사용될 수 있다

SNR 및 BER 값은 이동성의 결과 또는 환경의 변화로 인해 바뀔 수 있다.

따라서 802.11 와이파이 또는 4G/5G 네트워크 기반의 셀룰러 데이터 전송 시스템에서는
주어진 채널 환경에서 적당한 BER를 만족하는 동시에 최고의 전송률을 제공하는 적응적인 변조 기법을 선택할 수 있도록 허용한다.

숨은 터미널 문제(hidden terminal problem)

아래의 상황에서 A가 B로, C가 B로 데이터를 전송한다고 가정하자.

이때 A와 C의 전송 신호가 실제로 목적지 B에서 간섭됨에도 불구하고
산이나 건물 등의 환경적인 장애물로 인해 A와 C는 서로 상대방의 전송을 인지하지 못하는 일이 생긴다.

이를 숨은 터미널 문제(hidden terminal problem)한다.

페이딩(fading) 현상

신호가 무선 매체를 통과함에 따라 신호 세기가 약해지는 현상을 말한다.

위 그림에서 A와 C가 서로의 전송을 검출하기에는 충분하지 않은 세기의 신호를 수신하는 거리에 있으나,
이들 신호가 중간에 있는 B에서는 간섭된다.

7.2.1 CDMA

코드 분할 다중 접속(code division multiple access, CDMA)은 채널 분할 접속 프로토콜의 하나로서,
무선 랜 및 셀룰러 기술에서 아주 많이 사용되고 있다.

채널 분할 접속 프로토콜

CDMA 프로토콜에서는 송신자가 전송하는 각 비트를 확장해서
애초의 데이터 비트열보다 훨씬 빠른 속도(칩 속도(chipping rate))로 변화되도록 하는 신호(코드)를 곱하는 방식으로 인코딩한다.

아래의 간단하고 이상적인 CDMA 인코딩/디코딩 시나리오를 보자.

데이터 비트들이 CDMA 인코더에 도착하는 속도에 의해 시간의 단위가 정의된다고 가정하자.

즉, 전송되는 각각의 원래 데이터 비트는 한 비트 슬롯 시간이 필요하다.

i번째 비트 슬롯의 데이터 비트값을 di라고 하자.

계산의 편의상, 1 값을 갖는 데이터 비트는 1로, 0 값을 갖는 데이터 비트는 -1로 표시한다.

각 비트 슬롯은 M개의 미니슬롯들로 더 분할된다. (그림에서는 M = 8)

송신자가 사용하는 CDMA 코드는 일련의 연속된 M개의 값, Cm(m = 1, … , M)으로 구성된다.
각각의 Cm 값은 1 또는 - 1 값을 갖는다.

✅ 간섭하는 송신자가 없는 단순한 환경에서의 CDMA 동작

CDMA의 동작을 구체적으로 알아보기 위해, i번째 데이터 비트인 di에 대해 살펴보자.

수신자는 인코딩된 바이트열 Zi,m을 수신해서 다음과 같이 합성함으로써 원래의 데이터 비트 di를 생성한다.

위의 시나리오 그림에서 해당 식을 통해 원래 데이터 비트가 수신자에 의해 정확히 얻어지는 것을 확인할 수 있다.

✅ 간섭하는 송신자가 존재하는 환경에서의 CDMA 동작

현실에서는 서로 간섭하는 다수의 송신자가 존재한다.

이 경우, CDMA 수신자는 다른 송신자들이 전송한 비트들과 섞여 있는 상황에서 내 송신자의 원래 데이터 비트를 어떻게 다시 생성할 수 있을까?

CDMA는 동시에 전송되어 간섭하는 비트 신호들을 더할 수 있다는 전제하에 동작한다.

e.g., 같은 미니슬롯에서 3명의 송신자가 1의 값을 전송하고 4번째 전송자가 -1의 값을 전송한다면,
그 미니슬롯에서 모든 수신자가 수신하는 신호는 2(= 1+1+1-1)가 된다.

다수의 송신자가 있는 경우에도 송신자 s는 아래 식을 사용해서 자신의 인코딩된 전송 비트열을 정확히 계산한다.
(위에서의 식과 동일)

i번째 비트 슬롯의 m번째 미니슬롯은 그 미니슬롯 동안 모든 N개의 송신자가 전송한 비트들의 합이 된다.

만약 송신자의 코드가 조심스럽게 선택되었다면,
수신자는 다수 송신자로부터의 혼합된 신호로부터 원하는 송신자가 전송한 데이터만을 아래 식과 같이 특정 송신자 코드를 사용해서 쉽게 추출해낼 수 있다.

아래는 두 송신자가 존재할 때, 수신자가 위쪽 송신자로부터의 원래 데이터 비트열을 구하는 과정을 나타낸다.

수신자는 아랫쪽 송신자의 간섭에도 불구하고 첫 번째 송신자의 데이터를 추출할 수 있다.

CDMA는 (시간이나 주파수가 아닌) 코드를 분할(partitioning)해서 각 노드에게 적당한 코드를 할당하는 분할 프로토콜이다.

위에서는 CDMA에 대한 필수적인 설명만 했지만, 실제로는 많은 어려운 문제들이 있다.

CDMA 수신자가 특정 송신자의 신호를 추출해낼 수 있도록 CDMA 코드를 조심스럽게 선택해야 한다.
앞에서는 여러 송신자로부터의 신호 세기가 수신자 쪽에서 동일하다고 가정했으나, 실제 상황에서 이런 경우는 드물다.

7.3 와이파이: 802.11 무선 랜

1990년대 다양한 무선 랜(wireless LAN) 관련 기술 및 표준이 개발되었으나
그중 가장 성공적인 기술, 와이파이(WiFi)라고 알려진 IEEE 802.11 무선 랜이 관련 기술들을 통합하게 되었다.

IEEE 802.11 표준안

802.11b, g, n, ac, ax 표준

일반적으로 거리가 70m 미만인 영역에서 동작하는 WLAN 용도
이전 표준과의 역방향 호환성을 갖는다.
즉, 802.11g 기능만을 갖는 이동 단말도 802.11ac 또는 802.11ax 기지국과의 상호작용이 가능하다.
모두 CSMA/CA라는 동일한 매체 접속 프로토콜을 사용한다.

802.11af, ah 표준

IoT, 센서 네트워크, 측정 애플리케이션을 활용하기 위한 용도 (좀 더 먼 거리에서 동작)

주파수 영역

802.11 무선 랜 장치들은 두 종류의 주파수 영역에서 동작한다.

2.4 GHz 대역

5.1~5.8 GHz 주파수 영역
비허가(unlicensed) 주파수 대역
이 영역에서 802.11 장치들은 2.4 GHz 무선 전화 및 가전제품과 주파수 경쟁을 하게 된다.

5 GHz 대역

전력 수준이 동일할 경우 전송 거리가 더 짧고 다중 경로 전파의 영향을 더 많이 받는다.

안테나

802.11n, 802.11ac, 802.11ax 표준은 MIMO(multiple input multiple-output) 안테나를 사용한다.

이는 송신과 수신 측에 각각 2개 이상의 안테나가 있어 각기 다른 신호를 송수신하는 방식이다.

802.11ac, 802.11ax 기지국은 여러 개의 스테이션을 동시에 전송할 수 있으며,
목적지에 따라 동적으로 수신자의 방향을 향해 전송할 수 있는 스마트 안테나를 사용한다.

이는 간섭을 줄이고, 동일한 데이터 전송률에서의 도달 거리를 향상하는 기능을 한다.

7.3.1 802.11 WLAN 구조

다음은 802.11 무선 랜 구조의 핵심적인 구성요소를 보여준다.

BSS(basic service set)

802.11 구조의 가장 근본적인 구성 단위
구성
- 하나 이상의 무선 단말기
- 하나의 기지국(base station) 즉, AP(access point)
전형적인 홈 네트워크에서는 BSS를 인터넷으로 연결하는 AP와 라우터가 각각 필요하다.

MAC 주소

802.11 무선 기지국은 6바이트의 MAC 주소를 가진다.
- MAC 주소는 스테이션의 어댑터(802.11 네트워크 인터페이스 카드) 펌웨어에 저장되어 있다.
각각의 AP도 자신의 무선 인터페이스에 대한 MAC 주소를 갖는다.
MAC 주소는 IEEE에 의해 관리되며, 이론적으로는 전 세계에서 유일성을 갖는다.

인프라스트럭처 무선 랜(infrastructure wireless LAN)

AP를 가진 무선 랜
네트워크 인프라스트럭처 : AP, 그리고 AP를 인터넷 라우터와 연결해주는 유선 이더넷 구조를 통칭한다.

애드혹 네트워크

중앙 제어나 외부 네트워크로의 연결 인프라가 없는 경우를 말한다.
- e.g., 랩톱을 가진 사람들이 중앙 제어되는 AP가 없는 환경(회의실, 기차, 자동차 등)에서 만나 데이터를 교환할 때
네트워크는 근접한 이동 장치들 사이의 연결을 통해 즉흥적으로 형성된다.
- 이미 존재하는 다른 네트워크 인프라스트럭처에 기댈 수가 없고 따라서 가까이 있는 장치들이 서로 찾아서 통신해야 하기 때문이다.

아래 그림은 IEEE 802.11 스테이션들이 애드혹 네트워크를 형성하기 위해 서로를 그룹으로 연결하는 상황을 보여준다.

채널과 결합

802.11에서 개별 무선 단말기는 네트워크 계층 데이터를 송신 또는 수신하기 전에 하나의 AP와 결합(association)되어 있어야 한다.

모든 802.11 표준에서 결합을 사용하고 있지만, 특히 IEEE 802.11 b, g, n, ac, ax 환경에서 이 주제를 논의하겠다.

네트워크 관리자가 AP를 설치할 때 AP에서 하나 또는 두 단어로 된 SSID(Service Set Identifier)를 할당한다.
관리자는 AP에게 채널 숫자를 할당해야 한다.
- 802.11은 2.4~2.4835 GHz 주파수 범위에서 동작한다.
- 이 80여 MHz 주파수 대역에서 11개의 일부가 겹치는 채널들을 정의하고 있기에
  서로 다른 2개의 채널은 4개 채널 이상의 간격으로 분리되어 있어야만 겹치지 않는다.

와이파이 정글(WiFi jungle)

무선 스테이션이 둘 이상의 AP로부터 충분히 강한 신호를 받을 수 있는 모든 지역

이러한 AP들은 각기 다른 IP 서브넷에 있을 수 있고, 독립적으로 채널을 할당했을 수도 있다.

무선 스테이션이 인터넷에 접속하기 위해서는 정확히 하나의 서브넷에 들어가야 하므로 단 하나의 AP와 결합되어야 한다.

(결합 = 무선 스테이션이 AP와 가상 회선을 만드는 것)

802.11 표준은 AP가 주기적으로 비컨 프레임(beacon frame)을 전송할 것을 요구한다.
- 비컨 프레임(beacon frame)에는 AP의 SSID와 MAC 주소가 포함된다.
무선 스테이션은 주변 AP로부터의 비컨 프레임을 찾기 위해 11개 채널을 살펴본다.
비컨 프레임으로부터 사용 가능한 AP들의 정보를 얻은 무선 스테이션은 결합을 맺을 AP를 하나 선택한다.
- 802.11 표준은 사용 가능한 AP 중 어떤 것을 선택할 것인지를 정하는 알고리즘을 정의하지 않고 있으며,
  이는 무선 스테이션의 펌웨어 또는 소프트웨어 설계자에 의해 결정된다.
- 일반적으로는 비컨 시그널의 세기가 가장 강한 AP를 선택한다.

수동적 스캐닝과 능동적 스캐닝

수동적 스캐닝(passive scanning) : 비컨 프레임의 수신을 통해 채널을 찾는 과정

AP들로부터 비컨 프레임이 전송된다.
H1에서 선택된 AP로 결합 요청 메시지를 전송한다.
선택된 AP에서 H1으로 결합 수락 메시지를 전송한다.

무선 호스트는 능동적 스캐닝 과정을 수행할 수 있다.

능동적 스캐닝(active scanning) : 무선 스테이션이 영역 안에 있는 AP들에게 탐사용 프로브(probe) 프레임을 방송하는 방식

탐사용 프로브 프레임이 H1으로부터 방송된다.
AP들로부터 프로브 응답 메시지가 도착한다.
H1에서 선택된 AP로 결합 요청 메시지를 전송한다.
선택된 AP에서 H1으로 결합 수락 메시지를 전송한다.

스테이션의 첫 번째 프로브 요청에 응답한 AP는 여러 개의 응답한 AP 중 어떤 것이 선택될지 모르기 때문에 두 번째 요청/수락 핸드셰이킹 통신이 필요하다.

AP와의 결합 단계가 끝난 후, 무선 스테이션은 AP의 서브넷 IP 주소를 얻기 위해서 결합된 AP를 통해 서브넷으로 ‘DHCP 발견 메시지’를 전송한다.

서브넷 주소를 얻으면 인터넷의 나머지 노드는 이 무선 스테이션을 선택된 AP의 서브넷 내부의 IP 주소를 지닌 한 호스트로 여기게 된다.

무선 스테이션이 특정 AP와 결합하기 위해서는 해당 AP에게 자신을 인증(authentication)해야 할 때도 있다.

e.g., 스테이션의 MAC 주소를 기반으로 무선 네트워크로의 접근을 허용 / 사용자 이름과 암호를 입력
AP는 인증 서버와 통신하며, 무선 종단 스테이션과 인증 서버 사이에서 RADIUS DIAMETER 같은 프로토콜을 사용해서 정보를 중계한다.

7.3.2 802.11 MAC 프로토콜

무선 스테이션이 AP와 결합되면 AP와 데이터 프레임을 송수신할 수 있다.

그러나 AP 자신을 포함한 여러 스테이션이 동시에 동일한 채널로 데이터 프레임을 전송할 수 있으므로 전송을 조정하기 위해 다중 접속 프로토콜이 필요하다.

다중 접속 프로토콜은 크게 세 가지 방법으로 분류된다.

채널 분할 (e.g., CDMA)
랜덤 접속
순번제

이더넷에서 랜덤 접속 프로토콜이 커다란 성공을 함에 따라 무선 랜에서도 랜덤 접속 프로토콜이 사용된다.

802.11 무선 랜에서 사용되는 랜덤 접속 프로토콜은 CSMA/CA(carrier sense multiple access with collision avoidance)다.

즉, 스테이션이 전송하기 전에 채널 상태를 감지하고(sense), 만일 채널이 사용 중이면 전송하지 않는다.

이더넷과 802.11 모두 채널을 감지하는 랜덤 접속 프로토콜을 사용하지만,
이들 MAC(Medium Access Control, 매체 접속 제어) 프로토콜에는 차이가 있다.

802.11은 충돌 검출(collision detection)을 사용하지 않고 충돌 회피(collision avoidance) 기술을 사용한다.
- 이유
  - 충돌 검출을 하려면 (스테이션 자신의 신호) 송신과 (다른 스테이션의 전송 여부 결정을 위한) 수신이 동시에 가능해야 한다.
    일반적으로 802.11 어댑터에서 수신 신호의 세기는 송신 신호의 세기에 비해 아주 약하므로, 송수신을 모두 고려하여 충돌을 검출할 수 있는 하드웨어를 만드는 데는 많은 비용이 든다.
  - 동시에 송수신이 가능하고 다른 스테이션에 의한 채널 사용을 감지했을 때 전송을 중단할 수 있다고 하더라도,
    숨은 터미널 문제와 페이딩 때문에 충돌을 검출하지 못할 수도 있다.
- 따라서 802.11 무선 랜은 일단 스테이션이 프레임을 전송하기 시작하면 그 프레임을 모두 전송하고, 이를 중단할 수 없다.
  - 충돌이 빈번할 때 프레임 전체를 전송하면 다중 접속 프로토콜의 성능이 상당히 저하될 수 있기 때문에 몇 가지 충돌 회피 기술을 사용한다.
802.11에서는 링크 계층 ARQ(ACK/재전송) 방식을 사용한다.

링크 계층 ACK(link-layer acknowledgment)

무선 랜에서 송신 스테이션이 전송한 프레임은 여러 가지 이유(숨은 터미널 문제, 페이딩 등)로 목적지 스테이션에 제대로 도달하지 못할 수 있으며,
이를 해결하기 위해 802.11 MAC에서는 링크 계층 ACK(link-layer acknowledgment)를 사용한다.

목적지 스테이션은 CRC 검사를 통과한 프레임을 수신하면
SIFS(Short Inter-Frame Spacing)라는 짧은 시간을 기다린 후에 ACK 프레임을 송신 스테이션에게 보낸다.
(1) 만일 송신 스테이션이 주어진 시간 동안에 ACK를 수신하지 못하면, 송신 스테이션은 오류가 발생했다고 가정한다.
(2) 송신 스테이션은 다시 CSMA/CA 프로토콜을 사용해서 채널 접속을 한 후 프레임을 재전송한다.
일정 횟수만큼의 재전송 후에도 ACK를 수신하지 못하면, 송신 스테이션은 포기하고 프레임을 폐기한다.

802.11 CSMA/CA 프로토콜

스테이션(무선 장치나 AP)이 전송할 프레임을 갖고 있다고 가정하자.

스테이션은 채널이 사용되지 않음을 감지하면 DIFS(Distributed Inter-frame Space)라는 짧은 시간 동안 기다린 후에 프레임을 전송한다.
그렇지 않고 채널이 사용 중이면 스테이션은 백오프 방식에 따라 선택된 임의의 시간 동안 대기한다. (6.3.2절 참고)
- DIFS 시간 이후에 채널이 사용되지 않음을 감지하면 선택된 시간의 카운터값은 감소하며,
  채널 사용이 감지되면 카운터값을 그대로 고정한다.
카운터가 0에 도달하면 스테이션은 프레임 전체를 전송한 후에 ACK를 기다린다.
- 카운터가 0에 도달하는 것은 채널이 사용되지 않을 때만 가능하다.
(1) ACK를 수신하면 송신 스테이션은 프레임이 목적지 스테이션에 의해 제대로 수신되었음을 알게 된다.
→ 만일 스테이션에 전송할 프레임이 또 있다면 2단계의 CSMA/CA 프로토콜을 수행한다.
(2) ACK를 수신하지 못하면 송신 스테이션은 좀 더 증가된 임의의 시간값을 선택한 후, 2단계의 백오프 과정을 수행한다.

이더넷의 CSMA/CD(collision detection) 다중 접속 프로토콜
: 채널이 사용되지 않는 유휴 상태임을 감지한 스테이션은 바로 전송을 시작한다.
802.11의 CSMA/CA(collision avoidance) 프로토콜
: 채널이 사용되지 않는 상태임을 감지하더라도 스테이션은 임의의 백오프값을 선택하여 카운트다운 과정을 거치므로 전송을 지연시킨다.

각각 전송할 프레임을 가진 2개의 스테이션이 또 다른 제3의 스테이션이 이미 전송하고 있음을 감지했기 때문에 바로 전송하지 않는 상황을 생각해보자.

이더넷 CSMA/CD에서는 전송 중이었던 스테이션이 전송을 마치면 이 두 스테이션이 바로 전송을 시작한다.

이 경우에 충돌이 발생하며, CSMA/CD에서는 두 스테이션 모두 전송을 즉시 중단한다.
충돌을 겪은 프레임의 나머지 부분을 전송하지 않음으로써 불필요한 전송을 피하므로 문제가 심각해지지 않는다.

802.11은 충돌을 검출하지 않으며 전송을 중단하지도 않는다.

이에 충돌을 겪은 프레임이라도 전체를 다 전송하기 때문에, 802.11의 목표는 가능한 한 충돌을 회피하는 것이다.
두 스테이션이 채널이 현재 사용 중임을 감지하면 아래와 같은 방식으로 충돌을 회피한다.
1. 이들은 랜덤 백오프(random backoff) 기법을 수행하여 임의의 백오프값을 선택한다.
2. 선택된 백오프 시간이 다른 경우, 채널이 사용되지 않는 유휴 상태에 도달했을 때
  1. 경쟁 중인 두 스테이션 중 하나가 다른 스테이션보다 먼저 전송을 시작하며,
  2. ‘경쟁에서 진 스테이션’은 ‘이긴 스테이션’의 신호를 감지하고 자신의 카운터를 멈춘 후
  3. 경쟁에서 이겨 전송 기회를 획득한 스테이션이 전송을 완료할 때까지 기다린다.
이 상황에서도 두 스테이션이 서로 숨은 터미널이거나 두 스테이션이 선택한 임의의 백오프값이 너무 가까울 경우 충돌이 생길 수 있다.

숨은 터미널 해결방안: RTS와 CTS

802.11 MAC 프로토콜은 숨은 터미널이 존재하더라도 충돌을 회피할 수 있는 예약 방법을 선택할 수 있도록 제공한다.

아래의 상황에서는 2개의 무선 스테이션(H1, H2)과 하나의 AP가 있다.

두 무선 스테이션은 동일한 AP의 영역 내에 있으며 이 AP와 결합되어 있는데,
페이딩 때문에 각 무선 스테이션은 AP로부터는 잘 보이지만 그들 서로 간에는 숨어 있다.

숨은 터미널이 왜 문제일까?

스테이션 H1이 프레임을 AP로 전송하고 있고, H1이 전송하는 도중에 스테이션 H2가 AP로의 전송을 원한다고 가정하자.

H1의 전송을 듣지 못한 H2는 임의의 시간(DIFS)을 기다린 후에 DATA 프레임을 전송하며 충돌이 발생하게 되고,
이에 H1의 전체 전송 시간과 H2의 전체 전송 시간 동안 채널이 낭비된다.

이 문제를 해결하기 위해 IEEE 802.11 프로토콜에서는
스테이션들이 짧은 RTS(Request to Send) 제어 프레임과 짧은 CTS(Clear to Send) 제어 프레임을 주고받게 함으로써 채널 접속을 예약할 수 있게 한다.

송신자는 DATA 프레임을 전송하고 싶으면, 먼저 RTS 프레임을 AP에게 보냄으로써
DATA 프레임과 ACK 프레임을 전송하는 데 필요한 전체 시간을 알려준다.
AP가 RTS를 수신하면 이에 대한 응답으로 CTS 프레임을 영역 내의 모든 스테이션에게 전송한다. (송신 스테이션 포함)
- 송신자에게는 전송할 수 있다는 허가를 알려준다.
- 다른 스테이션들에게는 예약된 시간 동안 전송하지 못하게 한다.

RTS와 CTS 프레임을 사용하면 다음과 같이 두 가지 측면에서 성능이 향상된다.

채널을 예약한 다음에만 길이가 긴 DATA 프레임을 전송하기 때문에 숨은 스테이션 문제가 완화될 수 있다.
RTS와 CTS 프레임은 길이가 짧으며, RTS/CTS 프레임에 의한 충돌은 짧은 RTS/CTS 프레임이 전송되는 동안에만 발생한다.
일단 RTS와 CTS 프레임이 제대로 전송되면, 그 뒤에 오는 DATA와 ACK 프레임은 충돌 없이 전송된다.

하지만 이들로 인해 지연과 채널 자원의 낭비가 생긴다.

따라서 실제로 무선 스테이션에서는 RTS 임계치를 설정하여,
임계치보다 긴 DATA 프레임을 전송할 때만 RTS/CTS 교환을 통해 채널을 예약할 수 있도록 한다.

점대점 링크로서의 802.11 사용

만일 두 노드가 지향성 안테나(directional antenna)를 갖고 있다면
지향성 안테나로 상대방을 가리킴으로써 지점 간의 링크를 형성하고, 이 링크에 대해 802.11 프로토콜을 실행할 수 있다.

비용이 저렴한 802.11 하드웨어에 지향성 안테나와 증가된 전송 전력(power)을 사용함으로써
802.11은 수십 km 거리의 무선 지점 사이에 연결을 제공하는 저렴한 수단으로 사용될 수 있다.

7.3.3 IEEE 802.11 프레임

802.11 프레임은 이더넷 프레임과 유사하지만, 무선 링크 사용에 특화된 몇 개의 필드를 갖고 있다.

아래 그림은 802.11 프레임을 표시한 것인데,
프레임의 각 필드 위의 숫자는 필드 길이를 바이트 단위로 나타낸 것이다.

Frame Control 필드의 서브필드(subfield) 위의 숫자는 서브필드의 길이를 비트 단위로 나타낸 것이다.

Payload, CRC 필드

페이로드(payload)는 보통 하나의 IP 데이터그램이나 ARP 패킷이다.
(최대 2,312바이트까지 허용, 하나의 데이터그램이나 ARP 패킷을 포함함)
32비트의 CRC를 통해 802.11 프레임은 수신자가 수신한 프레임의 비트 오류를 검출할 수 있다.
(비트 오류는 유선 랜보다 무선 랜에서 훨씬 많이 발생하므로 CRC 기법은 무선 랜에서 더 유용함)

주소 필드

802.11 프레임의 가장 큰 차이점은 4개의 주소 필드를 갖고 있다는 것이다.

각 주소 필드는 6바이트의 MAC 주소를 포함할 수 있다.

왜 주소 필드가 4개나 필요할까?

네트워크 연동(internetworking)을 위해서는 3개의 주소가 필요하다.
- e.g., 무선 스테이션에서 AP를 통해 라우터 인터페이스로 네트워크 계층 데이터그램을 전송하는 경우
네 번째 주소는 애드혹 네트워크 모드에서 사용된다.

802.11 표준에서는 처음 3개의 주소 필드를 다음과 같이 정의한다.

Address 2

프레임을 전송하는 스테이션의 MAC 주소
e.g.,
- 무선 스테이션이 프레임을 전송하면 그 스테이션의 MAC 주소가 이 필드에 삽입된다.
- AP가 프레임을 전송하면 AP의 MAC 주소가 이 필드에 삽입된다.

Address 1

프레임을 수신하는 무선 스테이션의 MAC 주소다.
e.g.,
- 이동 무선 스테이션이 프레임을 전송하면 Address 1에는 목적지 AP의 MAC 주소가 삽입된다.
- AP가 프레임을 전송하면 Address 1에 목적지 무선 스테이션의 MAC 주소가 삽입된다.

Address 3

AP와 무선 기지국들로 구성된 BSS는 서브넷의 일부이고, 이 서브넷은 라우터 인터페이스를 통해 다른 서브넷으로 연결된다.
Address 3은 이 라우터 인터페이스의 MAC 주소를 포함한다.

Address 3은 BSS를 유선 랜과 연동하는 데 핵심적인 역할을 한다.

아래의 예시를 보자.

2개의 AP가 있으며, 각 AP는 다수의 무선 스테이션들을 책임진다.
각 AP는 라우터에 직접 연결되어 있으며, 라우터는 글로벌 인터넷에 연결되어 있다.
AP는 링크 계층 장치이기에 네트워크 계층인 IP 기능을 갖지 않으며, IP 주소를 이해하지도 못한다.

1️⃣ 라우터 인터페이스 R1로부터 무선 스테이션 H1로 데이터그램을 전달한다고 하자.

라우터는 자신과 H1 사이에 AP가 존재한다는 사실을 알지 못하며, H1을 자신에게 연결된 서브넷 중 하나에 대한 호스트 정도로 생각한다.

(1) 데이터그램의 목적지 주소로부터 H1의 IP 주소를 알게 된 라우터는 ARP를 사용해서 H1의 MAC 주소를 결정한다.
- 출발지 주소 필드 : R1의 MAC 주소
- 목적지 주소 필드 : H1의 MAC 주소
(2) H1의 MAC 주소를 획득한 라우터 인터페이스 R1은 이더넷 프레임 내에 데이터그램을 캡슐화한다.
이더넷 프레임이 AP에 도착하면
AP는 이 프레임을 무선 채널로 전송하기 전에 802.3 이더넷 프레임을 802.11 프레임으로 변환한다.
- Address 1 필드 : H1의 MAC 주소
- Address 2 필드 : AP 자신의 MAC 주소
- Address 3 필드 : R1의 MAC 주소

따라서 H1은 Address 3으로부터 데이터그램을 서브넷으로 전송한 라우터 인터페이스의 MAC 주소를 알 수 있다.

2️⃣ 무선 기지국 H1이 응답으로 R1에게 데이터그램을 전송한다고 하자.

H1은 802.11 프레임을 생성한다.
- Address 1 필드 : AP의 MAC 주소
- Address 2 필드 : H1의 MAC 주소
- Address 3 필드 : R1의 MAC 주소
AP가 이 802.11 프레임을 수신하면 이것을 이더넷 프레임으로 변환한다.
- 출발지 주소 필드 : H1의 MAC 주소
- 목적지 주소 필드 : R1의 MAC 주소

따라서 AP가 이더넷 프레임을 구성할 때 Address 3으로부터 목적지 MAC 주소를 결정할 수 있게 해준다.

Sequence Number, Duration, Frame Control 필드

802.11에서는 한 스테이션이 다른 스테이션으로부터 프레임을 제대로 수신할 때마다 ACK를 보낸다.

ACK가 손실될 수 있으므로 송신 스테이션은 같은 프레임을 여러 번 보낼 수도 있는데,
Sequence Number 필드로 순서 번호를 사용함으로써 수신자는 새로 전송된 프레임과 재전송된 프레임을 구분할 수 있다.

802.11 프로토콜에서 송신 스테이션은 데이터 프레임을 전송하는 시간과 ACK를 전송하는 시간을 포함한 시간 동안 채널을 예약할 수 있다.

데이터 프레임과 RTS 및 CTS 프레임 모두에 대해 이 시간값은 해당 프레임의 Duration 필드에 포함된다.

Frame Control 필드는 여러 개의 서브필드로 구성된다.

Type 필드와 Subtype 필드 : 결합, RTS, CTS, ACK, 데이터 프레임을 구분하는 데 사용된다.
To 필드와 From 필드 : 주소 필드들의 의미를 정의하는 데 사용된다.
- 주소 필드가 갖는 의미는
  (1) 애드혹 또는 인프라스트럭처 방식의 사용 여부에 따라서,
  (2) 인프라스트럭처 방식의 경우는 프레임을 무선 기지국이 전송하는지, AP가 전송하는지 여부에 따라서 달라진다.
WEB 필드 : 암호화 사용 여부를 나타낸다.

7.3.4 동일한 IP 서브넷 내에서의 이동성

무선 랜의 물리적 영역을 증가시키기 위해 동일한 IP 서브넷에 여러 개의 BSS를 설치하기도 한다.

따라서 무선 스테이션이 기존 TCP 세션을 유지한 채로 어떻게 한 BSS에서 다른 BSS로 매끄럽게 이동할 수 있는가 하는 이동성 문제가 발생한다.

위 그림에서 두 BSS를 연결하는 장치는 라우터가 아니며, 두 BSS에 있는 AP를 포함한 모든 기지국은 동일한 IP 서브넷에 속한다.

따라서 호스트 H1이 BSS1에서 BSS2로 이동할 때 H1의 IP 주소는 동일하게 유지되며, 현재 진행 중인 TCP 연결도 유지될 수 있다.

만약 연결 장치가 라우터인 경우, H1은 자신의 IP 주소를 새로 진입한 서브넷에 맞게 변경하기 위해
현재 진행 중인 TCP 연결을 잠시 중단하거나 종료해야할 수도 있다.

→ 이동 IP(mobile IP)와 같은 네트워크 계층의 이동성 프로토콜을 사용

호스트와 AP의 관점

H1은 AP1에서 떠나면서 그의 신호가 약해지는 것을 감지하고, 더 강한 신호를 찾기 시작한다.
H1은 AP2로부터 비컨 프레임을 수신하면, 자신의 IP 주소와 진행 중인 TCP 세션을 유지한 채로 AP1과의 결합을 끊고 AP2와 새로운 결합을 만든다.

스위치의 관점

스위치는 ‘자가학습’을 하고 자동으로 포워딩 테이블을 구성할 수 있지만,
TCP 연결을 유지한 채로 BSS들 사이의 이동을 하는 사용자는 지원하지 못한다.

H1이 BSS1에 있으면 H1의 데이터그램은 AP1로 전달되어야 한다.
H1이 BSS2에 있으면 H1의 데이터그램은 AP2로 전달되어야 한다.

H1이 BSS2와 결합을 새로 설정한 다음에
AP2로 하여금 출발지 주소가 H1인 이더넷 프레임을 스위치로 브로드캐스트하게 만든다.
이 프레임을 수신한 스위치는 포워딩 테이블을 갱신함으로써 AP2를 통해 H1에 도달할 수 있다.

7.3.5 802.11의 고급 특징

802.11 전송률 적응

앞서 보았듯이, 상이한 SNR 환경에 따라 전송률의 차이가 있는 각각 다른 변조 기법이 적합할 수 있다.

기지국으로부터 20 m 떨어져 있고 높은 SNR을 갖는 802.11 이동 사용자를 가정해보자.

빠른 전송률을 갖는 물리 계층 변조 기법을 사용하면서도 BER를 낮게 유지할 수 있다.
하지만 사용자가 기지국으로부터 멀어지는 방향으로 걸어감에 따라 SNR가 낮아지는 경우라면 BER가 허용할 수 없을 만큼 높아질 것이다.

따라서 일부 802.11 구현은 전송률 적응(rate adaptation) 기능을 갖고 있다.

이는 현재 또는 최근의 채널 상황에 맞추어 물리 계층 변조 기법을 적응적으로 선택할 수 있게 한다.

(TCP 혼잡 제어 기법과 유사)

전력 제어

802.11 표준은 노드가 신호 감지와 송수신 기능 및 다른 전력 소모가 많이 필요한
기능을 수행하는 데 사용되는 시간을 최소화할 수 있도록 하는 전원 제어 방법을 제공한다.

노드는 명시적으로 수면 상태(sleep state)와 동작 상태(wake state)를 오가며 상태를 변화시킨다.
노드는 802.11 프레임의 전력 제어 비트를 1로 세팅함으로써 AP에게 자신이 수면 모드로 돌입할 것임을 알린다.
이때 노드 내의 타이머가 AP가 비컨 신호를 보내기 직전에 노드가 깨어날 수 있도록 설정된다.
AP는 수면 상태의 노드로 프레임을 전송하지 않으며, 해당 호스트에게 향하는 프레임을 나중에 전송하기 위해 버퍼에 저장한다.
수면 상태의 노드는 AP로부터 비컨 신호가 전송되기 직전에 깨어나 재빨리(250 µs) 완전한 활성 상태(active state)로 전환한다.
- AP로부터 전송되는 비컨 신호에는 AP에 버퍼링 되어 있는 프레임들을 전달받아야 할 노드 목록이 포함되어 있다.
- 만약 깨어난 노드가 버퍼링 목록상에 없다면 그 노드는 다시 수면 상태로 들어갈 수 있다.
- 그렇지 않다면 해당 노드는 AP에게 폴링(polling) 메시지를 전송함으로써 저장되어 있는 프레임의 전송을 요구하게 된다.

7.3.6 PAN(Personal Area Network): 블루투스

블루투스(Bluetooth) 네트워크는 수십 미터 이하의 단거리에서 저전력, 저비용으로 동작한다.

따라서 WPAN(wireless personal area network) 또는 피코넷(piconet)이라고도 한다.

블루투스 네트워크에는 많은 링크 레벨 네트워킹 기술로 가득 차 있다.

시분할 다중화(TDM) 및 주파수 분할
랜덤 백오프
폴링
오류 검출과 정정
ACK/NAK을 이용한 신뢰성 있는 전송

주파수 대역

무선 ISM(Industrial, Scientific, Medical) 밴드로서, 허가가 필요 없는 2.4 GHz 대역에서 동작한다.

즉, 같은 주파수 대역을 사용하는 가전제품들(전자레인지, 가정용 무선전화 등)과 경쟁하기 때문에 명시적으로 소음과 간섭 현상을 염두에 두고 설계되었다.

시분할 다중화(TDM)

블루투스 무선 채널은 625마이크로초의 시간 슬롯을 가진 TDM 방식으로 동작한다.

각 시간 슬롯마다 송신자는 79개 채널 중의 하나로 전송하며 슬롯마다 주파수 채널을 변경한다.
변경할 주파수 채널 선택은 난수에 의한 의사 무작위 추출(pseudo-random) 방식을 사용한다.

이런 형태의 주파수 변경 또는 주파수 도약 기법은 주파수 도약 확산 스펙트럼(frequency-hopping spread spectrum, FHSS) 방식으로 알려져 있다.

이를 통해 ISM 대역을 사용하는 다른 장치나 가전과의 간섭 현상이 일부 시간 슬롯으로 한정될 수 있다.

애드혹 네트워크

블루투스 네트워크는 인프라스트럭처(e.g., AP)가 없는 애드혹 네트워크다.

대신에 이들은 아래 그림과 같이 그들 스스로 최대 8개의 활성화된 노드로 구성된 피코넷을 형성해야 한다.

노드들 중 1개의 장치가 중앙 집중형 제어 노드로 지정되며, 나머지 장치들은 클라이언트가 된다.
피코넷 안에는 8개의 활성화된 장치 외로, 최대 255개의 ‘주차’된 장치가 있을 수 있다.
- 이들은 절전을 위해 수면 상태인 경우가 많다.
- 수면 상태의 장치들은 스케줄링에 따라 중앙 집중형 제어 노드로부터의 비컨 메시지를 수신하기 위해 주기적으로 깨어난다.
- 중앙 집중형 제어 노드에 의해 활성화된 장치로 변경되기 전에는 통신을 할 수 없다.

중앙 집중형 제어 노드

피코넷 내부의 다른 노드들을 제어한다.
- 시간 슬롯의 경게를 결정하는 클록의 관리
- 주파수 도약 순서 제공
- 피코넷으로의 클라이언트 진입 제어
- 클라이언트 장치의 전송 전력 제어(100 mW, 2.5 mW, 1 mW)
네트워크 진입이 허용된 클라이언트에게 폴링 방식을 사용하여 전송 권한을 부여한다.

이웃 탐색(neighbor discovery) 문제

블루투스 애드혹 네트워크는 AP 없이 스스로 네트워크를 구성해야 한다.

중앙 집중형 제어 노드가 블루투스 네트워크를 형성하려면 먼저 영역 내에 다른 어떤 블루투스 노드가 존재하는지 결정해야 한다.
- 중앙 집중형 제어 노드는 연속적인 32개의 조회 메시지를 각기 다른 채널을 통해 브로드캐스트함으로써 이를 수행한다.
- 클라이언트 장치는 이 조회 메시지를 수신하기 위해 주파수 중 하나를 선택해 수신을 기다린다.
(1) 클라이언트 장치가 조회 메시지를 수신하면
(2) 다른 응답 노드와의 충돌을 피하기 위해 0~0.3초 사이의 임의의 시간 동안 대기한 후
(3) 자신의 ID를 포함하는 응답 메시지를 중앙 집중형 제어 노드에게 전송한다.
블루투스 페이징(Bluetoothe paging)
- 중앙 집중형 제어 노드가 주변의 가능한 클라이언트 노드들을 모두 발견했다면, 그중 피코넷에 가입을 원하는 클라이언트 노드들을 초대한다.
- 과정
  1. 중앙 집중형 제어 노드는 또다시 32개의 동일한 페이징 초대 메시지를 각각의 클라이언트 주소로 전송하는 것으로 페이징 단계를 시작한다.
    - 아직 클라이언트가 주파수 도약을 배우지 않았기 때문에, 메시지는 각기 다른 주파수를 통해 전송된다.
  2. 클라이언트가 초대 메시지에 대해 ACK로 응답하면 중앙 집중형 제어 노드는 아래의 정보들을 클라이언트들에게 전송한다.
    - 주파수 도약 정보
    - 클록 동기화 정보
    - 활성화된 멤버의 주소
  3. 이후 중앙 집중형 제어 노드는 각 클라이언트를 폴링하여 클라이언트가 네트워크에 연결되어 있음을 확인하고
    주파수 도약 패턴을 사용한 통신을 시작한다.

Chapter 7 - 4. 셀룰러 네트워크, 5. 이동성 관리, 6. 실전에서의 이동성 관리, 7. 무선과 이동성

ssun_bear — Wed, 10 Jul 2024 00:00:39 +0900

7.4 셀룰러 네트워크: 4G, 5G

셀룰러(cellular) 네트워크

셀룰러(cellular)라는 용어는 셀룰러 네트워크의 영역이 전파 도달 능력에 따라 여러 개의 지리적 영역, 즉 셀(cell)로 나뉜다는 사실에서 비롯되었다.
각각의 셀은 셀 영역 안의 이동 장치(mobile device)와 신호를 주고받는 기지국(base station)을 갖고 있다.
하나의 셀이 담당하는 영역의 넓이는 여러 요소에 의해 영향을 받는다.
- 기지국과 단말기의 송신 강도
- 셀 내의 방해가 되는 건물
- 기지국 안테나의 설치 높이와 종류

7.4.1 4G LTE 셀룰러 네트워크: 구조 및 요소

아래 그림은 4G LTE(Long-Term Evolution) 네트워크 구조의 주요 요소를 보여준다.

이동 장치(mobile device)

셀룰러 통신 사업자의 네트워크에 연결되는 스마트폰, 태블릿, 랩톱 또는 IoT 장치 등이며, (고정된 온도 세선 또는 감시 카메라도 포함)
웹 브라우저, 지도 앱, 음성 및 화상회의 앱, 모바일 결제 앱 등이 실행되는 곳이다.

UE(User Equipment)
전체 5계층 인터넷 프로토콜 스택을 구현한다.
NAT을 통해 얻을 수 있는 IP 주소를 갖고 있는 네트워크의 종단점이다.
전 세계적으로 고유한 IMSI(International Mobile Subscriber Identity)라는 64비트의 식별자가 있다.
- 가입자가 속한 국가 및 홈 네트워크를 포함하여 전 세계의 셀룰러 사업자 시스템에서 가입지를 식별한다. (MAC 주소와 유사함)
- 이는 SIM(Subscriber Identity Module) 카드에 저장된다.
  - SIM 카드는 가입자가 접속할 수 있는 서비스에 대한 정보와 해당 가입자의 키 정보를 암호화한다.

기지국(base station)

셀룰러 통신 사업자 네트워크의 가장자리에 위치하며, 무선 전파 자원 및 담당 영역에 속한 이동 장치를 관리할 책임이 있다.

이동 장치는 기지국과 상호작용함으로써 사업자의 네트워크에 접속된다.
무선 접속 네트워크에서 장치의 인증 및 자원(무선 채널)의 할당 기능을 조정한다.
무선 랜의 AP와는 다르게, 셀룰러 기지국에서만 수행하는 역할들은 다음과 같다.
- AP 이동 장치에서 게이트웨이까지 장치 고유의 IP 터널을 생성하고, 셀 간의 장치 이동성을 처리하기 위해 상호작용한다.
- 인접한 기지국들은 셀 사이의 간섭을 최소화하기 위해 무선 스펙트럼을 관리하기 위한 상호 조정 기능을 수행한다.

홈 가입자 서버(Home Subscriber Server, HSS)

HSS의 네트워크를 홈 네트워크로 사용하는 이동 장치에 대한 정보를 저장하는 데이터베이스

제어 평면의 요소
이동 장치의 인증을 위해 이동성 관리 개체(MME)와 함께 사용된다.

S-GW(Serving Gateway), P-GW(Packet data Network Gateway)

S-GW와 PDN 게이트웨이(P-GW)는 이동 장치와 인터넷 사이에 위치하는 2개의 라우터다.

PDN 게이트웨이(P-GW)

이동 장치에 NAT IP 주소를 제공하고 NAT 기능을 수행한다.
외부 세계에서 P-GW는 다른 게이트웨이 라우터와 마찬가지로 보인다.
셀룰러 사업자의 LTE 네트워크 안에서의 이동 노드의 이동성은 P-GW 뒤에 있는 바깥 세상에는 감추어진다.

이러한 게이트웨이 라우터 외에도 셀룰러 사업자의 all-IP 코어에는 전통적인 라우터 기능을 수행하는 라우터들이 존재한다.

이동성 관리 개체(Mobility Management Entity, MME)

제어 평면의 요소
HSS와 함께 네트워크에 접속하려는 장치를 인증하는 데 중요한 기능을 수행한다.
이동 장치와 PDN 인터넷 게이트웨이 간의 데이터 경로에 터널을 설정하고, 사업자의 셀룰러 네트워크 안에서 활성화된 이동 장치의 셀 위치 정보를 유지 관리한다.
그러나 이동 장치의 데이터그램이 인터넷으로 전송되거나 들어오는 전달 경로상에 있지 않다. (아래 그림에서 확인 가능)

LTE 데이터 평면과 제어 평면의 요소

인증(authentication)

네트워크와 네트워크에 부착된 이동 장치 간의 상호 인증
- 네트워크는 부착된 장치가 실제로 주어진 IMSI와 연관된 장치라는 것을 알아야 한다.
- 이동 장치는 자신이 부착하고 있는 네트워크가 또한 합법적인 셀룰러 사업자 네트워크라는 것을 알아야 한다.
MME가 이동 홈 네트워크에서 이동 장치와 홈 가입자 서버 HSS 사이의 중재자 역할을 한다.
1. 로컬 MME는 이동 장치로부터 접속 요청을 수신하고, 이동 장치의 홈 네트워크 HSS에 접촉한다.
2. 이동 장치의 홈 HSS는 로컬 MME에 암호화된 정보를 충분히 반환한다.

경로 설정(path setup)

이동 장치로부터 게이트웨이 라우터로의 데이터 경로는
이동 장치와 기지국 사이의 무선 첫 번째 홉(first hop), 기지국과 서빙 게이트웨이(S-GW) 사이의 연결된 IP 터널, 서빙 게이트웨이, PDN 게이트웨이로 구성된다.

터널은 MME의 제어하에 설정된다.
장치가 다른 기지국으로 이동했을 때에 기지국에서 종료하는 터널 종단점만 변경되며, 다른 터널 종단점 및 터널과 관련된 서비스 품질은 변경되지 않는다.

셀 위치 추적(cell location tracking)

이동 장치가 셀들 사이를 이동함에 따라, 기지국들은 이동장치의 위치에서 MME를 갱신할 것이다.

하지만 이동 장치가 수면 모드에 있지만 그럼에도 불구하고 셀 사이를 이동하는 경우, 기지국은 더 이상 해당 장치의 위치를 추적할 수 없다.

이 경우 페이징이라고 하는 프로세스를 통해 깨어난 장치를 찾는 것은 MME의 책임이다.

2G에서 3G, 그리고 4G로의 네트워크 구조 변화

2G 셀룰러 구조

통신 사업자 코어 네트워크를 통한 회선 교환 음성 서비스를 지원

3G 시스템 구조

통신 사업자 코어 네트워크를 통해 회선 교환 음성 서비스와 패킷 교환 데이터 서비스를 별도로 지원

4G 시스템 구조

7.4.2 LTE 프로토콜 스택

4G LTE는 all-IP 네트워크 구조이다.

따라서 LTE 프로토콜 스택의 상위 계층은 IP, TCP, UDP, 그리고 다양한 애플리케이션 계층 프로토콜들로 구성된다.

아래 그림은 LTE 이동 노드, 기지국, 서빙 게이트웨이에서의 사용자 평면 프로토콜 스택을 보여준다.

여기서 볼 수 있듯, 사용자 평면 프로토콜 활동의 대부분은 이동 장치와 기지국 사이의 무선 링크에서 발생한다.

LTE는 이동 장치의 링크 계층을 3개의 부계층으로 나눈다.

1️⃣ 패킷 데이터 융합(Packet Data Convergence)

PDCP(Packet Data Convergence Protocol)는 무선 링크를 통해 전송되는 비트 수를 줄이기 위해 IP 헤더 압축을 수행한다.
LTE 이동 장치가 네트워크에 처음 연결될 때
이동 장치와 이동성 관리 개체(MME) 사이의 시그널링 메시지 교환을 통해 설정된 키를 사용한 암호화/복호화 기능을 수행한다.

2️⃣ 무선 링크 제어(Radio Link Control, RLC)

링크 계층 프레임에 적용하기에는 너무 큰 IP 데이터그램의 송신 시 단편화 및 수신시 재조립을 수행한다.
ACK/NAK 기반 ARQ 프로토콜의 사용을 통한 링크 계층에서의 신뢰성 있는 데이터 전송을 수행한다.

3️⃣ 매체 접속 제어(Medium Access Control, MAC)

전송 스케줄링을 수행한다. 이는 무선 전송 슬롯의 요청 및 사용 제어를 의미한다.
MAC 부계층은 추가적인 오류 감지/정정 기능을 수행하는데, 여기에는 중복 비트 사용을 통한 순방향 오류 정정 기능이 포함된다.

위의 그림은 또한 사용자 데이터 경로에서 터널의 사용을 보여준다.

터널은 MME 제어하에 이동 장치가 처음으로 네트워크에 연결될 때 설정된다.
두 종단점 사이의 각 터널에는 고유한 터널 종단점 식별자(tunnel endpoint identifier, TEID)가 있다.
(1) 기지국은 이동 장치에서 데이터그램을 수신하면 TEID를 포함한 GPRS 터널링 프로토콜을 사용하여 데이터그램을 캡슐화하고
(2) UDP 세그먼트로 터널의 다른 쪽 끝에 있는 서빙 게이트웨이로 보낸다.
(1) 수신 측에서 기지국은 터널링된 UDP 데이터그램을 캡슐 해제하고
(2) 이동 장치로 향하는 IP 데이터그램을 추출하여
(3) 무선 홉을 통해 해당 IP 데이터그램을 이동 장치로 전달한다.

7.4.3 LTE 무선 접속 네트워크

LTE는 다운스트림 채널에서 주파수 분할 다중화와 시분할 다중화를 조합한 기술을 사용하는데,
이 기술은 직교 주파수 분할 다중화(frequency division multiplexing, OFDM)로 알려져 있다.

LTE에서 활성화된 각 이동 장치에는 하나 이상의 채널 주파수에서 / 하나 이상의 0.5 ms 시간 슬롯이 할당된다.

아래 그림은 4개의 주파수에서 8개의 시간 슬롯을 할당한 것을 보여준다.

각 주파수마다 10 ms 프레임 안에 구조화된 20개의 0.5 ms 슬롯
음영 표시 : 20 개의 슬롯 중 8개 슬롯의 할당된 모습

동일한 주파수에 있든 다른 주파수에 있든, 점점 더 많은 시간 슬롯을 할당함으로써 이동 장치는 점점 더 높은 전송 속도를 달성할 수 있다.
이동 장치 간의 슬롯 (재)할당은 밀리초마다 한 번씩 수행될 수 있다.
다른 변조 방식을 사용하면 전송률을 변경할 수도 있다.

이동 장치에 대한 특정 타임 슬롯의 할당은 LTE 표준에 의해 의무화되어 있지 않으나,
어떤 이동 장치가 주어진 주파수에서 주어진 시간 슬롯에 전송하도록 허용될 것인지에 대한 결정은 LTE 장비 공급자 또는 네트워크 운영자가 제공하는 스케줄링 알고리즘에 의해 결정된다.

7.4.4 추가적인 LTE 기능: 네트워크 접속과 전원 관리

네트워크 접속

이동 장치가 셀룰러 사업자의 네트워크의 접속하는 절차는 세 단계로 나뉜다.

1️⃣ 기지국과의 접속

이동 장치는 초기에 모든 주파수 대역의 모든 채널에서 기지국에 의해 5 ms마다 주기적으로 보로드캐스트되는 기본 동기화 신호를 검색한다.
기본 동기화 신호가 발견되면 이동 장치는 해당 주파수를 유지하고 보조 동기화 신호를 찾는다.
- 보조 동기화 신호에서 찾은 정보와 몇 가지 추가 단계를 거쳐서
  이동 장치는 채널 대역폭, 채널 구성 및 해당 기지국의 셀룰러 사업자 정보화 같은 추가 정보를 찾을 수 있다.
위 과정에서 찾은 정보로 무장한 이동 장치는 연결한 기지국을 선택하고, 해당 기지국과의 무선 홉을 통해 제어 평면의 신호 연결을 설정할 수 있다.

2️⃣ 상호 인증

기지국이 MME(Mobility Management Entity)에 접속하여 상호 인증을 수행한다. (이는 8.8.2절에서 자세히 살펴봄)
상호 인증을 통해 네트워크는 접속하려는 장치가 실제로 주어진 IMSI와 연관된 장치이며,
이동 장치는 접속 시도 중인 네트워크가 합법적인 셀룰러 사업자 네트워크임을 알 수 있다.
상호 인증 단계가 완료되면 MME와 이동 장치가 서로 상호 인증되고, MME도 이동 장치가 연결된 기지국의 ID를 알게 된다.

3️⃣ 매체 이동 장치와 PDN 게이트웨이 간 경로 구성

MME는 PDN 게이트웨이(이동 장치에 대한 NAT 주소도 제공함), 서빙 게이트웨이, 기지국에 연결하여 아래 그림에 포시된 2개의 터널을 설정한다.
이 단계가 완료되면 이동 장치는 기지국과 연결된 이 터널을 통해 인터넷과 IP 데이터그램을 송수신할 수 있다.

전력 관리: 수면 모드

무선 장치는 전력 소모를 최소화하기 위해 (= 데이터 송수신 및 채널 감지를 위해 이동 장치의 회로가 켜져 있어야 하는 시간을 최소화하고자)
송수신하지 않을 때는 수면 상태로 들어갈 수 있다.

4G LTE에서 잠자고 있는 이동 장치는 두 가지 수면 상태 중 하나에 있을 수 있다.

불연속 수신 상태(discontinuous reception state)
유휴 상태(idle state)

불연속 수신 상태(discontinuous reception state)

‘약한 수면’
일반적으로 수백 밀리초의 비활성 기간 이후에 시작되는 단계이다.
이동 장치와 기지국은 이동 장치가 깨어나기 위한 주기적인 시간을 미리 예약한 후,
주기적으로 기지국에서 이동 장치로의 다운스트림 전송을 위해 채널을 능동적으로 모니터링한다.
- 그러나 이 예정된 스케줄링 시간과는 별개로 이동 장치의 무선 부분은 수면 상태일 수 있다.

유휴 상태(idle state)

‘깊은 수면’
이 상태의 잠은 너무 깊어, 이동 장치가 수면 상태인 동안 통신 사업자 네트워크의 새로운 셀로 이동하는 경우 이전에 결합되었던 기지국에 알릴 필요가 없다.
따라서 이 깊은 잠에서 깨어날 때 이동 장치는
MME가 이동 장치가 과거에 마지막으로 결합했던 기지국 근처의 다른 기지국들로 브로드캐스트하는 페이징 메시지를 확인하기 위해 (잠재적으로 새로운) 기지국과의 결합을 재설정해야 한다.
- 이러한 제어 평면 페이징 메시지는 기지국에 의해 해당 셀 내의 모든 이동 장치로 브로드캐스트된다.
- 이는 어떤 이동 장치가 패킷을 수신하기 위해 완전히 깨어나야 하고 기지국에 대한 새로운 데이터 평면 연결을 재성정해야 하는지를 나타낸다.

7.4.5 글로벌 셀룰러 네트워크: 네트워크들의 네트워크

‘네트워크들의 네트워크’인 글로벌 셀룰러 네트워크는 어떻게 구성될까?

아래 그림은 사용자의 스마트폰이 4G 기지국을 통해 홈 네트워크(home network)에 연결되는 모습을 보여준다.

사용자 홈 네트워크는 홈 네트워크에 있는 하나 이상의 게이트웨이 라우터를 통해 다른 셀룰러 통신 사업자들의 네트워크와 글로벌 인터넷으로 연결된다.
모바일 네트워크 자체는 공용 인터넷 또는 IPX(Internet Protocol Packet eXchange) 네트워크를 통해 상호연결된다.
- IPX는 특히 ISP 간 네트워크를 연결하고 데이터를 교환하는 피어링을 위한 인터넷 교환 지점과 유사하게
  셀룰러 통신 사업자를 상호연결하기 위한 관리 네트워크다.

7.4.6 5G 셀룰러 네트워크

궁극적인 광역 데이터 서비스는 모든 지역에서 지원되며 유비쿼터스, 기가비트 연결 속도, 초저지연, 사용자 및 장치 수에 대한 제한 없는 서비스가 될 것이다.

5G는 4G에 비해 대략 10배의 최대 비트 전송률, 10배 빠른 지연 시간, 그리고 100배 이상의 트래픽 용량을 제공할 것으로 예측된다.
사용 주파수
- FR1(450 MHz~6 GHz)
- FR2(24 GHz~52 GHz) : 밀리미터파 주파수(millimeter wave frequency)
  - 장점 : 훨씬 빠른 데이터 속도를 허용한다.
  - 단점
    - 기지국에서 수진기까지의 도달 범위가 훨씬 짧기에 농촌 지역에 부적합하며, 도시 지역에는 더 밀집된 기지국 배치를 필요로 한다.
    - 대기 간섭에 매우 취약하다.
5G의 물리 계층(즉, 무선) 측면은 LTE와 같은 4G 이동 통신 시스템과 역방향 호환이 되지 않는다.
- 기지국 업그레이드나 소프트웨어 업그레이드를 통해 기존 스마트폰을 지원할 수가 없어,
  5G로의 전환을 위해 이동 통신 사업자는 물리적 인프라에 상당한 투자를 해야 한다.

표준

eMBB(Enhanced Mobile Broadband)

증가된 대역폭과 적당한 지연 시간 감소를 제공한다. (4G LTE와 비교할 때 더 높은 다운로드 및 업로드 속도를 위함)

URLLC(Ultra Reliable Low-Latency Communications)

지연 시간에 매우 민감한 애플리케이션을 대상으로 한다. (e.g., 공장 자동화 및 자율 주행)
1 ms의 지연 시간을 목표로 한다.

mMTC(Massive Machine Type Communications)

감지, 측정 및 모니터링 애플리케이션을 위한 협대역 접속 유형이다.
IoT 장치의 네트워크 연결 장벽을 낮추기 위해 전력 요구사항을 줄이는 데 중점을 두고 있다.

5G와 밀리미터파 주파수

24 GHz~52 GHz 대역의 밀리미터파 주파수는 4G에 비해 데이터 용량이 100배 증가할 수 있는 잠재력을 제공한다.

데이터 용량(capacity)
= 셀 밀도(cell density, 셀/km^2 단위)
× 가용 스펙트럼(available spectrum, Hz 단위)
× 스펙트럼 효율(spectral efficiency, 각 기지국이 사용자와 얼마나 효율적으로 통신할 수 있는지, bps/Hz/셀 단위)

밀리미터 주파수는 4G LTE 주파수보다 범위가 훨씬 짧기에 더 많은 기지국이 필요하다. → 셀 밀도 증가
5G FR2는 4G LTE(최대 약 2 GHz)보다 훨씬 더 큰 주파수 대역(52 - 24 = 24 GHz)에서 작동하기 때문에 사용 가능한 스펙트럼이 더 많다.
스펙트럼 효율성을 두 배 늘리기 위해 17배의 전력 증가가 필요하지만, 5G는 그 대신 각 기지국에서 다중 안테나를 사용하는 MIMO 기술을 사용한다.
- 신호를 모든 방향으로 브로드캐스트하는 대신, 각 MIMO 안테나는 빔 형성을 통해 사용자에게 신호를 직접 전송한다.
- 이를 통해 동일한 주파수 대역에서 동시에 10~20명의 사용자에게 전송할 수 있다.

그러나 밀리미터파 신호는 건물과 나무에 의해 쉽게 차단되기 때문에
기지국과 사용자 간의 범위 간격을 메우기 위해서 스몰 셀 스테이션(small cell station)이 필요하다.

5G 코어 네트워크(5G Core network)

5G 모바일 음성, 데이터 및 인터넷 연결을 모두 관리하는 데이터 네트워크

인터넷 및 클라우드 기반 서비스와 더 잘 통합되도록 재설계되었다.
네트워크 전체에 분산 서버와 캐시를 포함하여 지연 시간을 줄였다.
새로운 5G 코어 사양은 모바일 네트워크가 다양한 성능으로 다양한 서비스를 지원하는 방식에 주요한 변화를 도입했다.
- 종단점 장비로부터의 데이터 트래픽을 중계
- 장치를 인증
- 장치의 이동성을 관리
모든 네트워크 요소(이동 장치, 셀, 기지국, MME, HSS, 서빙 게이트웨이, PDN 게이트웨이)를 포함한다.

5G 코어 아키텍처

5G 코어는 제어 평면과 사용자 평면의 완전한 분리를 위해 설계되었고, 이는 순전히 가상화된 소프트웨어 기반 네트워크 기능으로 구성된다.

따라서 사업자가 다양한 5G 애플리케이션의 다양한 요구사항을 충족할 수 있는 유연성을 제공한다.

5G 핵심 네트워크 기능들

사용자 평면 기능(User-Plane Function, UPF)

제어와 사용자 평면 분리를 통해 패킷 처리를 네트워크 가장자리로 보내 분산시킬 수 있다.

접속 및 이동성 관리 기능(Access and Mobility Management Function, AMF)

5G 코어는 기본적으로 4G MME를 AMF와 SMF의 두 가지 기능 요소로 분리한다.

AMF는 최종 사용자 장치로부터 모든 연결 및 세션 정보를 수신하지만, 연결 및 이동성 관리 작업만 처리한다.

세션 관리 기능(Session Management Function, SMF)

세션 관리는 SMF에 의해 처리된다.

제어와 분리된 데이터 평면과의 상호작용을 담당하며, IP 주소 관리를 담당하고 DHCP 역할을 수행한다.

2020년을 기준으로, 5G는 적용 초기 단계이며 많은 5G 표준들이 아직 확정되지 않았다.

5G가 궁극의 광역 무선 서비스를 향한 커다란 발걸음이 될지는 시간이 지나야 알 수 있을 것이다.

7.5 이동성 관리: 원칙

이동 장치 = 시간에 따라 네트워크로의 접속점을 변경하는 노드

7.5.1 장치 이동성: 네트워크 계층의 관점

네트워크 계층의 관점에서 본 다양한 이동성 스펙트럼

물리적인 이동 장치가 네트워크 접속점을 이동할 때 그 장치가 얼마나 활성화된 상태인가에 따라 다양한 문제들을 네트워크 계층에 제기한다.

(a) 접속 네트워크 간 장치 이동성, 이동 중에는 전원을 끔

이곳에는 네트워크 사이를 물리적으로 이동하지만 이때 이동 장치의 전원을 끄고 움직이는 이동 사용자가 위치한다.

전원이 켜져 있는 동안 하나의 네트워크에만 접속하며 이동하지 않고 머물기 때문에, 네트워킹 관점에서 이 장치는 이동 중인 것, 즉 모바일이 아니다.

(b) 하나의 동일한 무선 접속 네트워크 안에서의 장치 이동성

이동 장치는 물리적으로 이동 가능하지만 동일한 접속 네트워크에 연결된 상태를 유지한다.

이러한 장치도 네트워크 계층 관점에서는 모바일이 아니다.

또한 장치가 동일한 802.11 AP 또는 LTE 기지국과 연결된 상태로 유지되는 경우, 해당 장치는 링크 계층 관점에서도 모바일이 아니다.

네트워크 관점에서 장치 이동성에 대한 관심은 여기서부터 시작한다.

(c) 진행중인 연결을 유지하며 동일 통신 사업자 네트워크 내에서의 장치 이동성

이동 장치는 TCP와 같은 상위 레벨 연결을 유지하고, IP 데이터그램을 계속 보내고 받는 상태에서
접속 네트워크(802.11 WLAN 또는 LTE 셀)를 변경한다.

여기서 네트워크는 장치가 WLAN 또는 LTE 셀 간에 이동할 때 핸드오버(handover)를 제공해야 한다.
(하나의 AP/기지국에서 다른 AP/기지국으로 데이터그램을 책임지고 전달하는 것)

(d) 진행 중인 연결을 유지하며 여러 통신 사업자 네트워크 간의 장치 이동성

이동 장치가 여러 사업자 네트워크들 사이를 로밍하는 경우이다.

이때 사업자들은 핸드오버를 함께 협력해서 처리해야 하므로 핸드오버 절차가 상당히 복잡해진다.

7.5.2 홈 네트워크 및 방문 네트워크로의 로밍

모든 셀룰러 사용자는 자신이 가입한 통신 사업자라는 '집'이 있으며,
HSS(Home Subscriber Service)가 아래와 같은 가입자들에 대한 다양한 정보들을 저장하고 있음을 앞서 배웠다.

가입자가 접속할 수 있는 서비스에 대한 정보
통신에 사용되는 암호화 키
요금 청구 및 과금 정보

이동 장치가 홈 네트워크(home network)가 아닌 다른 셀룰러 네트워크와 연결되면,
그 장치는 방문 네트워크(visited network)에서 로밍(roaming) 중이라고 한다.

이때 홈 네트워크와 방문 네트워크 간의 조정 작업이 필요하다.

이동 장치가 홈 네트워크를 갖는다는 개념은 중요한 장점 두 가지를 제공한다.

홈 네트워크는 해당 장치에 대한 정보를 제공할 수 있는 단일한 위치를 제공한다.
로밍 중인 이동 장치와의 통신을 위한 조정 지점의 역할을 수행할 수 있다.

7.5.3 이동 장치로의 직접 라우팅과 간접 라우팅

이동 네트워크 구조의 요소는 다음과 같다.

이를 통해 인터넷에 연결된 한 호스트가 직면한 난제를 살펴보자.
(장치 이동성을 지원하기 위한 근본적인 문제와 기본적인 해결방안들은 셀룰러 네트워크와 인터넷 모두에 동일하게 적용할 수 있음)

호스트는 통신자(correspondent)라고 불리며,
홈 네트워크에 있거나 방문 네트워크에 로밍 중인 어떤 이동 장치와 통신하기를 원한다.

모든 이동 장치에는 고유한 식별자가 있다고 가정한다.

4G LTE 셀룰러 네트워크에서 이 식별자는 IMSI(International Mobile Subscriber Identity)와 관련 전화번호가 될 것이고,
이 정보는 SIM 카드에 저장된다.
인터넷 사용자의 경우 이 식별자는 이동 IP 구조와 마찬가지로 홈 네트워크의 주소 범위에 있는 영구적인 IP 주소가 될 것이다.

통신자가 보낸 데이터그램이 해당 이동 장치에 도달할 수 있도록 하기 위해서 네트워크 구조에서는 세 가지의 기본적인 접근 방법이 있다.

이 중 후자의 두 가지 방법은 실제로 채택되어 사용되고 있다.

기존 IP 주소 인프라 활용
이동 장치로의 간접 라우팅
이동 장치로의 직접 라우팅

1️⃣ 기존 IP 주소 인프라 활용

과정

방문 네트워크에 있는 이동 장치로 라우팅하는 가장 간단한 방법은 기존의 IP 주소체계를 사용하는 것이다.

방문 네트워크는 이동 장치의 영구적인 32비트 IP 주소를 광고하여
데이터그램을 해당 이동 장치로 전달하는 데 사용할 경로가 있음을 다른 네트워크들에게 알린다.
- ISP는 BGP를 통해 도달 가능한 네트워크의 CIDR화된 주소 범위를 열거하여 목적지 네트워크에 대한 경로를 광고한다.
- 이때 방문 네트워크는 매우 구체적인 주소를 광고함으로써 특정 이동 장치가 자신의 네트워크에 존재한다는 사실을 다른 모든 네트워크에게 알릴 수 있다.
인접 네트워크들은 라우팅 정보 및 포워딩 테이블을 갱신하는 일반적인 BGP 절차를 사용해 네트워크 전체에 이 정보를 전파한다.

장점

네트워크 계층 인프라를 전혀 변경할 필요가 없다.

다른 네트워크들은 이동 장치의 위치를 알고 있으며,
포워딩 테이블들이 데이터그램을 방문 네트워크로 안내하기 때문에 데이터그램을 그 이동 장치로 쉽게 라우팅할 수 있다.

단점

확장성

네트워크 라우터는 잠재적으로 수십억 개의 이동 장치에 대한 포워딩 테이블 항목을 유지 관리해야 하고,
다른 네트워크로 로밍할 때마다 장치 관련 항목을 갱신해야 한다.

대안

좀 더 실용적이며 실제로 채택되고 있는 접근 방법은
이동 장치의 홈 네트워크를 통하여 이동성 관리 기능을 네트워크 코어에서 네트워크 가장자리로 밀어내어 옮기는 것이다.

이동 장치의 홈 네트워크에 있는 이동성 관리 개체인 MME는 이동 장치가 위치한 방문 네트워크를 추적할 수 있다.
(이 정보는 HSS의 데이터베이스에 있을 수 있음)

이동 장치가 위치한 네트워크를 갱신하기 위해서는 방문 네트워크와 홈 네트워크 사이에서 동작하는 프로토콜이 필요하다.

이동 장치는 방문 네트워크의 IP 주소가 필요하다.

여기에는
(1) 이동 장치의 홈 네트워크와 연결된 영구적인 IP 주소,
(2) 방문 네트워크의 주소 범위에서 새로운 주소의 할당
(3) NAT를 통한 IP 주소의 제공 등이 포함된다.

(2), (3)의 경우, 이동 장치는 홈 네트워크의 HSS에 저장된 영구적인 식별자 외에 임시 식별자(새로 할당된 IP 주소)를 갖게 된다.
NAT 주소를 사용하는 경우,
이동 장치로 향하는 데이터그램은 방문 네트워크의 NAT 게이트웨이 라우터에 도달하게 되면 NAT 주소 변환을 거쳐 해당 이동 장치로 전달된다.

그렇다면 데이터그램은 어떻게 주소를 찾아서 이동 장치로 전달될 수 있을까?

네트워크의 모든 라우터가 아닌 홈 네트워크의 HSS만이 이동 장치의 위치를 알고 있기 때문에,
단순히 목적지 이동 장치의 영구 주소를 데이터그램의 목적지로 지정하는 것은 안 된다.

이것에 대한 해결책으로는 직접 라우팅과 간접 라우팅이 있다.

2️⃣ 이동 장치로의 간접 라우팅

간접 라우팅(indirect routing) 방식에서 통신자는 이동 노드가 홈 네트워크에 있는지 또는 방문 네트워크에 있는지 모르는 상태로
데이터그램의 목적지 주소를 단순히 이동 노드의 영구적인 주소로 설정한 후 네트워크로 전송한다.

즉, 송신하는 통신자는 이동 장치의 현재 이동 상태를 몰라도 되며, 이는 통신자에게 이동성에 대한 완전한 투명성을 제공한다.

홈 네트워크를 통한 재라우팅(rerouting)

데이터그램은 이동 장치의 홈 네트워크로 전달된다.
(1) 홈 네트워크 게이트웨이는 데이터그램을 가로채서 HSS와 상의하여 이동 장치가 있는 방문 네트워크를 결정한 후
(2) 해당 데이터그램을 방문 네트워크의 게이트웨이 라우터로 전달한다.
- HSS : 방문 네트워크와 상호작용하여 이동 장치의 위치를 추적하고 홈 네트워크의 게이트웨이 라우터를 관리한다.
- 게이트웨이 라우터 : 해당 네트워크에 집이 있지만 현재 방문 네트워크에 위치해있는 장치를 목적지 주소로 하는 데이터그램이 도착하는지 확인한다.
방문 네트워크의 게이트웨이 라우터는 데이터그램을 이동 장치로 전달한다.
- NAT 변환이 사용된다면 방문 네트워크 게이트웨이 라우터가 NAT 변환을 수행한다.

아래의 두 가지 목표는 홈 네트워크 게이트웨이가 통신자의 원래 데이터그램을 캡슐화하여 더 큰 데이터그램에 넣게 함으로써 충족될 수 있다.

홈 네트워크 게이트웨이는 도착한 데이터그램을 방문 네트워크 게이트웨이 라우터에게 전달해야 한다.
데이터그램을 수신하는 애플리케이션 입장에서는 데이터그램이 홈 네트워크를 통해 전달되었다는 사실을 인식하지 않는 것이 좋기에
통신자의 데이터그램을 원래 그대로 두는 것이 바람직하다.

더 큰 데이터그램은 주소가 지정된 방문 네트워크의 게이트웨이 라우터에 전달되고,
이후 캡슐화를 해제하여 더 큰 데이터그램 내에서 원래의 데이터그램을 복원하여 이동 장치로 전달된다. (이는 위 3단계에서 진행됨)

이동 장치가 통신자에게 데이터그램을 보내는 것을 고려해보자.

그림의 맥락에서 이동 장치는 NAT 변환을 수행하기 위해 방문 게이트웨이 라우터를 통해 데이터그램을 전달해야 하는데,
방문 게이트웨이 라우터는 어떻게 데이터그램을 통신자에게 전달할까?

여기에는 아래처럼 두 가지 옵션(4a, 4b)가 있다.

4a : 데이터그램을 홈 게이트웨이 라우터로 다시 터널링하여 거기에서 다시 통신자에게 전달할 수 있다.
4b : 데이터그램은 방문 네트워크에서 통신자로 직접 전달될 수 있다. (로컬 브레이크 아웃(local breakout))

이동성 지원에 필요한 네트워크 계층의 기능

✅ 이동 장치에서 방문 네트워크로의 프로토콜

이동 장치는 방문 네트워크와 결합해야 하며, 마찬가지로 방문 네트워크를 떠날 때 결합을 해제해야 한다.

✅ 방문 네트워크에서 홈 네트워크로의 HSS 등록 프로토콜

방문 네트워크는 홈 네트워크의 HSS에 이동 장치의 위치를 등록해야 하며,
HSS에서 얻은 정보를 장치 인증을 수행하는 데 사용해야 한다.

✅ 홈 네트워크 게이트웨이와 방문 네트워크 게이트웨이 라우터 사이의 데이터그램 터널링 프로토콜

송신 측은 통신자의 원래 데이터그램을 새로운 데이터그램 내에 캡슐화한 후 목적지로 전달한다.

수신 측에서는 게이트웨이 라우터에서 캡슐화 해제 및 NAT 변환을 거쳐 원래 데이터그램을 이동 장치로 전달하는 작업을 수행한다.

삼각 라우팅 문제(triangle routing problem)

간접 라우팅 방식은
이동 장치를 목적지로 하는 데이터그램은 통신자와 로밍 중인 이동 장치 사이에 훨씬 더 효율적인 경로가 있는 경우에도
일단 먼저 홈 네트워크로 전달된 다음 방문 네트워크로 전달되어야 하기 때문에 비효율성을 가지고 있다.

3️⃣ 이동 장치로의 직접 라우팅

직접 라우팅(direct routing) 방식은 간접 라우팅 방식의 삼각 라우팅 문제를 해결할 수 있으나, 추가적인 복잡도가 발생한다.

1, 2단계 : 통신자는 먼저 이동 장치가 위치해 있는 방문 네트워크를 발견한다.
- 이는 이동 장치의 홈 네트워크 HSS에 질의함으로써 수행되고,
  이동 장치의 방문 네트워크가 HSS에 등록되어 있는 것으로 가정한다.
3단계 : 통신자는 데이터그램을 이동 장치의 방문 네트워크로 직접 터널링해서 전달한다.

문제점

통신자가 HSS에게 이동 장치의 방문 네트워크를 질의하기 위해서(1, 2단계), 이동 사용자 위치 파악 프로토콜이 필요하다.
이동 장치가 이동할 때마다 통신자를 미리 갱신해주려면 추가적인 프로토콜 매커니즘이 필요하다.
- 간접 라우팅에서는 홈 네트워크 HSS를 갱신하고, 터널의 종단점을 새로운 방문 네트워크의 게이트웨이 라우터로 변경함으로써 문제를 쉽게 해결한다.
- 직접 라우팅에서 통신자는 세션이 시작될 때 HSS에게 단 한 차례만 문의하며 이후에 변화된 정보를 알기 어렵기에 문제의 해결이 쉽지 않다.
이동 장치가 한 방문 네트워크에서 다른 방문 네트워크로 이동하면
통신자는 데이터그램을 새로운 방문 네트워크로 전달해야 한다는 것을 어떻게 알 수 있을까?

7.6 실전에서의 이동성 관리

7.6.1 4G/5G 네트워크에서의 이동성 관리

오늘날의 4G/5G 네트워크에서의 이동성을 지원하기 위해 어떤 요소들이 어떻게 상호 협력하면서 동작하는지 알아보자.

차량에 탑승한 이동 사용자가 스마트폰으로 4G/5G 방문 네트워크에 접속하여 원격 서버로부터 HD 비디오 스트리밍을 시작한 후,
하나의 4G/5G 기지국 셀 영역으로부터 다른 셀 영역으로 이동하는 시나리오를 생각해보자.

이동 장치와 기지국 결합
- 이동 장치는 방문 네트워크의 기지국과 결합한다.
이동 장치에 대한 네트워크 요소의 제어 평면 구성
- 방문 네트워크 및 홈 네트워크는 이동 장치가 방문 네트워크에 존재함을 나타내는 제어 평면 상태를 설정한다.
이동 장치에 대한 포워딩 터널의 데이터 평면 구성
- 방문 네트워크와 홈 네트워크는 홈 네트워크의 PDN 게이트웨이를 통한 간접 라우팅을 사용하여,
  이동 장치와 스트리밍 서버가 IP 데이터그램을 송수신할 수 있는 터널을 설정한다.
한 기지국에서 다른 기지국으로의 이동 장치 핸드오버
- 이동 장치는 한 기지국에서 다른 기지국으로 핸드오버를 통한 방문 네트워크 결합 지점을 변경한다.

1️⃣ 기지국 결합

이동 장치는 점차 이러한 기지국에 대한 더 많은 정보를 획득한다.
- 이동 장치는 해당 지역의 기지국에서 전송되는 기본 신호에 대해 모든 주파수 영역에서 수신한다.
이동 장치는 궁극적으로 결합할 기지국을 선택하고, 해당 기지국과 제어 신호 채널을 초기 설정한다.
- 결합의 일부로서 이동장치는 홈 네트워크 및 다른 가입자 정보, IMSI(고유 식별자)를 기지국에 제공한다.

2️⃣ 이동 장치에 대한 네트워크 요소의 제어 평면 구성

이동 장치와 기지국 간 신호 채널이 설정되면 기지국은 방문 네트워크의 MME와 접촉할 수 있다.

MME는 이동 노드를 대신하여 상태를 설정하기 위해 홈 네트워크 및 방문 네트워크 모두에서 여러 가지 4G/5G 요소들을 참고하고 구성한다.

MME는 IMSI 및 이동 장치에서 제공한 다른 정보를 사용하여 해당 가입자에 대한 인증, 암호화, 가용한 네트워크 서비스 정보를 검색한다.
- 해당 정보는 MME의 로컬 캐시에 있거나, 이동 장치가 최근에 접속한 다른 MME에서 검색되거나, 이동 장치의 홈 네트워크에 있는 HSS에서 검색될 수 있다.
MME는 이동 장치가 현재 방문 네트워크에 존재함을 홈 네트워크에 있는 HSS에 알리고, HSS는 데이터베이스를 갱신한다.
기지국과 이동 장치는 둘 사이에 설정될 데이터 평면 채널에 대한 매개변수를 선택한다. (제어 평면 시그널링 채널이 이미 작동 중임)

3️⃣ 이동 장치에 대한 포워딩 터널의 데이터 평면 구성

MME는 아래 그림과 같은 이동 장치에 대한 데이터 평면을 구성한다.

2개의 터널

기지국과 방문 네트워크의 서빙 게이트웨이 사이
해당 서빙 게이트웨이와 이동 장치의 홈 네트워크에 있는 PDN 게이트웨이 라우터 사이

→ 4G LTE는 이런 형태의 대칭 간접 라우터를 구현한다.

이동 장치에서 들어오고 나가는 모든 트래픽은 장치의 홈 네트워크를 통해 터널링된다.

4G/5G 터널은 GPRS 터널링 프로토콜(GPRS Tunneling Protocol, GTP)를 사용한다.

GTP 헤더의 TEID(Tunnel Endpoint ID)는 데이터그램이 속한 터널을 나타내므로, 터널 종단점 간에 GTP에 의해 여러 개의 흐름이 다중화 및 역다중화될 수 있다.

4️⃣ 한 기지국에서 다른 기지국으로의 이동 장치 핸드오버

핸드오버(handover)는 이동 장치가 한 기지국에서 다른 기지국으로 결합을 변경할 때 발생한다.

이동 장치가 송수신하는 데이터그램은 초기에(핸드오버 전에) 연결된 현 기지국(출발지 기지국)을 통해 이동장치로 전달된다.
핸드오버 이후에는 또 다른 기지국(목적지 기지국)을 통해 이동 장치로 라우팅된다.

기지국 간의 핸드오버는 이동 장치가 새로운 기지국과 송수신하게 될 뿐만 아니라
기지국 축면에서 서빙 게이트웨이-기지국 간 터널의 변경을 초래한다.

이동 장치는 주기적으로 현재 기지국의 비컨 신호와 들을 수 있는 주변 기지국의 신호 특성을 측정한다.

측정 결과는 이동 장치의 현 기지국(출발지 기지국)에 초당 한 번 또는 두 번 보고되는데,
측정 결과와 주변 셀의 이동 통신 부하 및 기타 요인에 기초하여 현재 기지국은 핸드오버를 시작하도록 요구할 수 있다.

아래 그림은 이동 장치의 출발지 기지국에서 목적지 기지국으로의 핸드오버 절차를 나타낸다.

현 기지국(출발지 기지국)은 목적지 기지국을 선택하고, 목적지 기지국으로 핸드오버 요청 메시지를 보낸다.
(1) 목적지 기지국은 해당 이동 장치와 그 서비스 품질 요구사항을 지원하기 위한 충분한 자원이 있는지 확인한다.(3) 목적지 기지국은 출발 기지국에게 핸드오버 요청 승인 메시지로 응답하는데, 여기에는 이동 장치가 새로운 기지국과 결합하는 데 필요한 모든 정보가 포함되어 있다.
(2) 존재한다면 해당 이동 장치를 위한 무선 접속 네트워크의 채널 자원(e.g., 시간 슬롯) 및 기타 자원을 미리 할당한다.
출발지 기지국은 핸드오버 요청 승인 메시지를 수신하고, 목적지 기지국의 ID 및 채널 접속 정보를 이동 장치에게 알려준다.
- 이 시점에서 이동 장치는 새로운 목적지 기지국과 데이터그램을 송수신하기 시작할 수 있다. (즉, 이동 장치의 입장에서는 핸드오버가 완료된 것)
- 네트워크 입장에서는 해야 할 일이 좀 더 남아 있다.
(1) 출발지 기지국은 데이터그램을 이동 장치로 전송하는 것을 중지하고, 대신 수신한 터널링된 데이터그램을 목적지 기지국으로 전달한다.
(2) 목적지 기지국은 이들 데이터그램을 나중에 이동 장치로 전달한다.
(1) 목적지 기지국은 MME에게 자신이 이동 장치를 서비스하는 새로운 기지국이 될 것임을 알린다.
(2) MME는 다시 서빙 게이트웨이와 목적지 기지국에 차례로 신호를 보내
이전 기지국(출발지 기지국)이 아닌 새로운 기지국(목적지 기지국)에서 종료하도록 서빙 게이트웨이-기지국 터널 종단점을 재설정한다.
목적지 기지국은 터널이 재구성되었음을 이전 기지국(출발지 기지국)으로 다시 확인해주어,
이전 기지국이 해당 이동 장치와 관련된 자원을 해제할 수 있게 한다.
이 시점에서 목적지 기지국도 이동 장치에 데이터그램 전달을 시작할 수 있다.
(핸드오버 기간에 출발지 기지국에서 목적지 기지국으로 전달된 데이터그램을 포함함)
또한 이동 장치로부터 외부로 나가는 데이터그램을 수신하여 이를 터널을 통해 서빙 게이트웨이로 보낼 수 있다.

오늘날의 4G LTE 네트워크의 로밍 구성은 미래의 5G 네트워크에서도 사용될 전망이지만,
5G 네트워크는 훨씬 더 작은 셀 크기로 조밀해질 것이다.

따라서 많은 실시간 5G 애플리케이션에서 작은 핸드오버 시간이 매우 중요해질 것이다.

셀룰러 네트워크 제어 평면을 SDN 프레임워크(5장)로 변경한다면 고용량, 저지연의 5G 네트워크 제어 평면을 구현할 수 있을 것으로 믿어진다.

7.6.2 이동 IP

오늘날의 인터넷에는 4G/5G 셀룰러 네트워크에서 접했던 것 같은 ‘이동 중인’ 사용자를 위한 서비스 유형을 제공하는 널리 사용되는 인프라는 없다.

그러나 이동 IP 구조 및 프로토콜은 20년 이상 인터넷 RFC로서 표준화되어 왔으며, 새롭고 더 안전하며 일반화된 이동성 지원에 대한 연구가 계속되고 있다.

4G/5G와 이동 IP 구조의 유사성

이동 IP 표준의 세 가지 주요 부분

✅ 에이전트 발견

이동 IP는 외부 에이전트가 네트워크에 결합하려는 이동 장치에게 이동성 지원 서비스를 광고하는 데 사용하는 프로토콜을 정의한다.

이러한 서비스에는 이동 장치가 외부 네트워크에서 사용하기 위한 COA(care-of-address) 제공,
이동 장치의 홈 네트워크에 있는 홈 에이전트에 이동 장치 등록, 이동 장치로의 데이터그램 송수신 등과 기타 서비스가 포함된다.

✅ 홈 에이전트와의 등록

이동 IP는 이동 장치의 홈 에이전트에 COA를 등록 및 취소하기 위해 이동 장치 및 외부 에이전트에서 사용하는 프로토콜을 정의한다.

✅ 데이터그램의 간접 라우팅

이동 IP는 데이터그램이 홈 에이전트에 의해 이동 장치로 전달되는 방식을 정의한다.

여기에는 데이터그램을 전달하고 오류를 처리하기 위한 규칙과 여러 형태의 터널링이 포함된다.

7.7 무선과 이동성: 상위 계층 프로토콜에의 영향

이 장에서는 링크 계층(페이딩이나 다중 경로, 숨은 터미널 등과 같은 무선 채널의 특성)과
네트워크 계층(네트워크 접속점이 동적으로 바뀌는 이동 사용자의 존재)에서 무선 네트워크와 유선 네트워크 간에 상당한 차이가 있음을 알았다.

그렇다면 트랜스포트 계층과 애플리케이션 계층에도 차이가 있을까?

트랜스포트 계층 프로토콜: TCP

어떤 면에서는 무선 링크가 존재하는 네트워크에서 TCP와 UDP가 사용될 수 있다는 생각이 맞을 수도 있다.

그러나 특히 TCP 트랜스포트 프로토콜은 유선 네트워크와 무선 네트워크에서 전혀 다른 성능을 보이는 경우가 많으며, 성능 면에서 그 차이가 뚜렷하다.

TCP는 송신자와 수신자 간의 경로에서 손실되거나 오류가 생긴 세그먼트를 재전송한다.

이동 사용자의 경우 아래의 상황 때문에 손실을 겪을 수 있다.

네트워크 혼잡 (라우터의 버퍼 오버플로)
핸드오프 (이동 노드의 새 네트워크 접속점으로 세그먼트를 재라우팅해주기 위한 지연 때문)

어떤 경우든지 간에 TCP의 수신자에서 송신자로 전송되는 ACK는 세그먼트가 성공적으로 수신되었는지 여부만을 알리며,
세그먼트가 손실된 경우에는 그것이 어떤 이유 때문인지 송신자는 알지 못한다.

어떤 이유든 송신자는 해당 세그먼트를 재전송한다.

TCP의 혼잡 제어 메커니즘도 이유와는 관계없이, 무조건 혼잡 윈도를 감소시키는 것으로 반응한다.

하지만 무선 네트워크에서는 비트 오류가 훨씬 많이 발생하는데,
비트 오류나 핸드오프로 인해 손실이 생겼을 경우 TCP 송신자는 혼잡 윈도를 감소(즉, 송신율 감소)시킬 필요가 없다.

실제로는 패킷이 혼잡을 겪지 않고 종단 간의 경로를 따라 여유 있는 라우터 버퍼를 이용해 제대로 전달되고 있을 수도 있다.

따라서 1990년대 초중반에 연구자들은 무선 링크의 높은 비트 오류율과 핸드오프로 인해
무선 환경에서는 혼잡 제어와 관련된 TCP의 무조건적인 반응이 문제가 될 수 있음을 알게되었다.

이 문제를 해결하기 위해 다음 세 가지 접근 방법을 사용할 수 있다.

✅ 지역 복구(local recovery)

비트 오류가 발생했을 때 오류 발생 지점(e.g., 무선 링크)에서 복구해주는 것이다.

이런 방법으로는 802.11 ARQ 프로토콜 또는 ARQ와 FEC를 모두 사용하는 방법이 있다.

하지만 이 방식에서 TCP 송신자는 세그먼트가 무선 링크를 거쳐서 전달되고 있음을 전혀 알지 못한다는 문제점이 있다.

✅ TCP 송신자의 무선 링크 인지

지역 복구에서의 문제점을 해결하기 위한 한 가지 대안으로서 TCP 송신자와 수신자가 무선 링크를 인지하게 해서
유선 네트워크에서의 혼잡으로 인한 손실과 무선 링크에서의 오류나 핸드오프로 인한 손실을 구분하게 하는 방법이 있다.

즉, 유선 네트워크에서의 혼잡으로 인한 손실에 대해서만 혼잡 제어를 하는 것이다.

✅ 연결 분리 방법(split-connection approach)

무선 사용자의 종단 간 연결을 2개의 트랜스포트 계층 연결(하나는 무선 사용자와 AP 간에, 다른 하나는 AP와 목적지 종단점 간에 설정)로 분리한다.

따라서 종단 간 연결은 무선 부분과 유선 부분으로 분리된다.

무선 구간의 트랜스포트 프로토콜은 표준 TCP 연결 또는 UDP 위에서 동작하도록 고안된 복구용 프로토콜일 수 있다.

이 방법은 셀룰러 네트워크에서 널리 사용되고 있고, 이 방법을 통해 많은 성능 향상이 있었다.

애플리케이션 계층 프로토콜

무선 스펙트럼의 공유 특성으로 인해
무선 링크(특히 셀룰러 무선 링크)를 통해 동작하는 응용에게 대역폭은 매우 부족한 자원이다.

비록 무선 링크 환경이 애플리케이션 계층의 개발에 해결해야 할 어려운 문제를 주기는 하지만,
무선 링크가 제공하는 이동성 덕분에 다양한 종류의 위치 인식 또는 문맥 인식 애플리케이션이 가능해졌다.

또한 무선 이동 네트워크는 향후 유비쿼터스 컴퓨팅 환경 실현에서 아주 핵심적인 역할을 하게 될 것이다.

Chapter 8 - 1. 네트워크 보안, 2. 암호의 원리, 3. 메시지 무결성과 전자서명

ssun_bear — Wed, 10 Jul 2024 00:00:21 +0900

8.1 네트워크 보안이란 무엇인가?

안전한 통신에 요구되는 특성

기밀성
- 송신자와 지정된 수신자만이 전송되는 메시지 내용을 이해할 수 있어야 한다.
- 도청자가 메시지를 가로챌 수도 있으므로 도청자가 해석할 수 없도록 메시지를 어떠한 방식으로 암호화해야한다.
메시지 무결성
- 통신하는 내용이 전송 도중에 변경되지 않아야 한다.
종단점 인증
- 통신에 참여하는 상대방이 누구인지 확인하기 위해 상대방의 신원을 확인할 수 있어야 한다.
운영 보안
- 오늘날 대부분 기관들의 네트워크는 공공 인터넷에 연결되어 있다.
- 따라서 외부로부터의 공격을 받을 수 있는 위험을 갖고 있고 대비하여 방화벽이나 보안 체계를 갖고 있어야 한다.

보안 시나리오

송신자와 수신자
- 데이터 일부 혹은 전부를 암호화하여 안전한 통신을 하려고 할 것이다.
침입자
- 채널상의 제어 메시지 및 데이터 메시지를 스니핑하거나 기록
- 메시지 혹은 메시지 내용의 조작, 삽입 혹은 삭제

8.2 암호의 원리

송신자가 보내는 원래 형태의 메시지를 평문 또는 원문이라고 한다.

송신자는 평문을 암호화 알고리즘을 사용해서 암호화하며, 암호화된 메시지인 암호문은 다른 침입자가 해석할 수 없다.

이 암호화 알고리즘은 모든이에게 알려져있고, 누구나 쉽게 사용할 수 있다.

즉, 전송한 데이터를 침입자가 복원할 수 없게 해주는 비밀 정보가 필요한데 이것이 바로 키이다.

시나리오

앨리스는 숫자나 문자의 열인 키 A를 암호화 알고리즘의 입력값으로 사용하여 암호화된 메시지 A(m)을 완성한다.
밥은 키 B와 암호문 A(m)을 복호화 알고리즘에 입력값으로 넣어 B(A(m)) = m 의 출력을 받는다.

대칭키 시스템

앨리스와 밥의 키가 동일하며 이 키는 둘만의 비밀이다.

공개키 시스템

키 중 하나는 세상 모두에게 알려져있고 다른 키는 앨리스 밥 중 한명만 알고 있다.

8.2.1 대칭키 암호화

카이사르 암호

영어로된 원문에 대해 평문의 각 철자를 알파벳 순서로 k번째 뒤에 오는 철자로 대치한다. (철자들의 순환을 가정. z의 1번째 뒤에 오는 철자는 a다.)

여기서는 k의 값이 암호화 키가 된다.

하지만 카이사르 암호인 것을 알고 있다면 금방 암호문을 복호화할 수 있을 것이다.

단일 문자 대응 암호

카이사르 암호처럼 일정한 규칙에 따라 대치하는 대신 아무 규칙 없이 각 철자들을 고유한 대응 글자로 변환한다.

26! 정도의 문자 대응쌍이 가능하여 더 안전하다.

그러나 e나 t가 흔하게 나타나거나 3개 혹은 3개의 특정 문자가 함께 나오거나 하는 특성 탓에 암호를 해독하기 쉬워진다.

예를들어 암호문을 사용하는 사람의 이름이 평문에 들어가있다는 것을 안다면 즉시 알파벳 중 몇쌍을 확정 지을 수 있다.

침입자가 갖고 있는 정보에 따른 시나리오

암호문만을 이용한 공격
- 평문 메시지에 대한 어떠한 정보도 없는 경우
알려진 평문 공격
- 침입자가 평문과 암호문에 나올 단어(이름 등)를 미리 알고 있는 경우 해당 단어에 대한 단어 쌍을 알 수 있다.
선택 평문 공격
- 침입자가 특정 평문 메시지를 선택하여 송신자에게 보내게 하고 이에 대응하는 암호문의 형태를 얻을 수 있다.

다중 문자 대응 암호화

여러 개의 단일 문자 대응법을 가지고 평문 메시지에서의 위치에 따라 서로 다른 단일 문자 대응 암호법을 사용한다.

즉, 같은 문자라도 평문 메시지에서의 위치에 따라 다르게 암호화 된다.

예를 들어, 단일 문자 대응법 첫번째를 C1, 단일 문자 대응법 두번째를 C2라고 해보자.

평문의 첫번째 메시지는 C1, 두번째는 C2, 세번째는 C1 … 식으로 평문 메시지의 위치에 따라 단일 문자 대응법을 달리 한다.

블록 암호화

현재 TLS, PGP, IPsec 등에 사용되는 암호화 기법이다.

오늘날 널리 활용되는 블록 암호화 방법에는 AES, DES, 3DES 등이 있다.

블록 암호화에서는 메시지가 k 비트의 블록 단위로 쪼개어져 암호화 된다.

k 비트의 평문은 k 비트 블록의 평문을 k비트 블록의 암호문으로 일대일 사상 시킨다.

위 표와 같이 사상한다면 010110001111은 101000111001 로 암호화 된다.

k 비트에 대해서 총 (2^k)! 로 사상의 수가 천문학적으로 커진다.

그러나 k=64라고하면 송신자와 수신자 모두 2^64개의 입력 테이블에 대한 테이블을 유지해야하는데 이는 실행이 거의 불가능 하고, 키가 바뀌면 큰 테이블을 재생성해야 하기 때문에 실제 사용은 불가능 하다.

대신 블록 암호화 기법은 입출력 블록의 순열 테이블을 임의로 모방 생성하는 함수를 사용한다.

위 그림은 k=64일 때의 예시를 나타낸다.

시나리오

64 비트의 블록을 8 비트씩 8개의 청크로 나눈다.
각 8 비트 청크는 관리 가능한 크기인 8비트 입력 블록에 대응하는 8비트 출력 블록을 가진 테이블에 의해 처리된다.
각 청크는 관리 가능한 크기인 8 비트 입력 블록에 대응하는 8 비트 출력 블록을 가진 테이블에 의해 처리된다.
암호화된 청크는 하나의 64 비트 블록으로 다시 합쳐진다.
- 각각의 위치는 뒤섞여서 합쳐진다.
64 비트 블록을 다시 입력부로 넣는다.
이 사이클을 n번 반복한다.
- 각 입력 비트가 대부분의 최종 출력 바트들에 영향을 미치게 하기 위해서이다.
- 라운드를 한번만 수행하면 하나의 입력 비트는 8개의 출력 비트에만 영향을 끼친다.

이 블록 암호화 알고리즘의 키는 블록을 뒤섞는 규칙이 알려져있다면 8개의 순열 테이블이다.

암호 블록 체이닝

네트워크 애플리케이션에서는 일반적으로 긴 메시지를 암호화할 필요가 있는데, 블록 암호화를 이용하면 미묘하지만 중요한 문제가 발생한다.

2개 이상의 평문 블록이 동일하다면 같은 암호문을 생성해내고, 공격자는 동일한 암호문으로 원문을 추측해낼 수 있는 가능성이 생긴다.

여기에 하위 프로토콜에 대한 지식까지 활용하면 전체 메시지를 복호화할 수 있다.

이를 해결하기 위해 같은 평문 블록에 대해 다른 암호문 블록이 생성될 수 있도록 임의성을 추가할 수 있다.

시나리오

송신자는 i번째 평문 블록 m(i)를 위해 k비트 길이의 임의의 수 r(i)를 생성한다.
K(r(i) xor m(i)) = c(i) 암호문을 만든다.
- r(i)로 인해 m(i)와 m(j)가 같아도 암호문은 달라지게 된다.
수신자는 r(i)와 c(i)를 받아서 m(i) = K(c(i)) xor r(i) 를 수행한다.
- 침입자는 암호화되지 않은 r(i)를 볼수는 있지만 키를 알지 못하므로 평문 m(i)를 복호화할 수 없다.

그러나 송신자는 2배의 비트를 더 보내야 하고 2배의 대역폭을 필요로 한다.

이 문제를 해결하기 위해 암호 블록 체이닝(Cipher Block Chaining, CBC) 기법을 사용한다.

시나리오

메시지를 암호화하기 전에 송신자는 초기화 벡터라 불리는 임의의 k 비트열 c(0)을 생성한다.
송신자는 c(0)를 수신자에게 보낸다.
첫번째 블록에 대해 송신자는 c(1)= K(m(1) xor c(0)) 을 계산한다.
암호화된 c(1)을 수신자에게 보낸다.
송신자는 이를 계속 c(i)= K(m(i) xor c(i-1)) 암호문 블록을 생성하고 보낸다.
- 수신자는 c(i-1)을 알고 있으므로 계속 복호화할 수 있다.
- 마찬가지로 같은 평문을 가지고 있어도 다른 암호문을 갖게 된다.
- 침입자는 암호화되지 않은 c(0)을 볼수는 있지만 키를 알지 못하므로 평문 m(i)를 복호화할 수 없다.
- 송신자는 하나의 초기화 벡터만 더 전송하면 되므로 대역폭 증가량이 미미하다.

8.2.2 공개키 암호화

공개키 암호화에서는 송수신자가 각각 키를 갖는다기보다 수신자가 2개의 키를 갖는다.

하나는 세상 모두에게 알려진 공개키이고, 다른 하나는 수신자만 아는 개인키이다.

시나리오

송신자는 수신자에게 메시지를 보내기 위해 수신자의 공개키를 확인한다.
수신자의 공개키로 메세지를 암호화하고 송신한다.
수신자는 자신의 개인키로 암호문을 복호화 알고리즘을 사용하여 복호화한다.

RSA

RSA는 모듈로 n 연산(나머지)을 많이 사용한다.

모듈로 연산의 유용한 성질

[(a mod n)+(b mod n)]mod n=(a+b)mod n
[(a mod n)−(b mod n)]mod n=(a−b)mod n
[(a mod n)⋅(b mod n)]mod n=(a⋅b)mod n

// 3번째 성질로부터 나오는 식
(a mod n)^d mod n = a^d mod n

공개키와 개인키의 선택

2개의 큰 소수 p와 q를 선택한다.
- 값이 클수록 RSA를 깨기가 어려워지지만 암호화 복호화를 수행하는데 시간이 더 걸린다.
n = pq, z =(p-1)(q-1) 식을 계산한다.
1을 제외하고 z의 서로소 n보다 작은 e를 선택한다.
- 암호화 encryption의 e를 따왔다.
ed-1이 z로 정확히 나누어 떨어지는 숫자 d를 찾는다.
- 복호화 decryption의 d를 따왔다.
- 이 말은 즉슨, ed mod z = 1이 성립하도록 d를 선택한다와 같다.
공개키는 숫자쌍 (n,e) 이다. 그의 개인키는 (n,d)이다.

큰 p와 q를 고르는 방법, 지수 연산 방법, e와 d를 고르는 방법 등은 이 책의 범위에서 벗어나므로 생략한다.

알고리즘 시나리오

암호화를 위해 공개키 (n,e)를 활용한다. 메세지에 e승을 하고 이를 n으로 나눈 나머지를 계산한 값이 암호문 c가 된다.
- 메세지는 k 비트열로 하나의 정수와 같아서 e의 제곱을 할 수 있다.
- c = m^e mod n
수신된 암호 메시지 c를 복호화 하기 위해 개인키 (n,d)를 활용한다.
- m = c^d mod n = m^ed mod n 을 수행하여 복호화한다.

e.g.

수신자가 p=5 , q=7로 선택한다.

이때 n = 35, z = 24가 된다.

5와 z가 공통인수가 없으므로 e = 5 를 선택한다.

5x29-1 (즉, ed-1) 이 24로 나누어떨어지므로 d= 29를 선택한다.

이제 공개키 (35,5)와 비밀키 (35,29)가 완성되었다.

이제 평문 m을 암호화 복호화 해보자.

m은 비트열 1100으로 숫자 12에 대응된다고 가정하자.

암호화 : m^e = 248832, 17(c) = 248832(m^e) mod 35(n)

복호화 : 12(m) = 4819685721067509150915091411825223071697(c^d) mod 68(n)

세션키

RSA에 필요한 지수 연산은 시간이 많이 필요하여 실제로 종종 대칭키 암호화와 함께 사용된다.

시나리오

송신자는 데이터 암호화에 사용할 세션키를 고른다.
- 세션키는 대칭키 암호화에 사용된다. 즉, 밥에게 세션키를 알려야 한다.
송신자는 수신자의 공개키로 세션키를 RSA 암호화한다.
수신자는 암호문을 받고 자신의 개인키로 복호화한다.
수신자는 세션키를 얻고, 송신자가 보낸 데이터를 복호화할 수 있다.

RSA가 동작하는 이유

m = m mod n= m^ed mod n 임을 증명하면 된다.

정수론에 의하면 p와 q가 소수이고 n = pq, z = (p-1)(q-1)이면, x^y mod n 이 x^(y mod z) mod n과 같다.

즉, 다음과 같은 식을 얻을 수 있다.

m^ed mod n = m^(ed mod z) mod n

ed mod z = 1이 되도록 e와 d를 선택하였으므로, m = m mod n= m^ed mod n 이다.

여기서 e와 d는 단순 제곱이므로 둘을 바꿔도 정상 동작한다.

8.3 메시지 무결성과 전자서명

메시지 무결성

메시지가 정말 해당 출발지로부터 왔는가?
메시지가 전달되는 도중 변경되지는 않았는가?

8.3.1 암호화 해시 함수

해시 함수는 입력 m을 받아서 해시라 불리는 고정된 크기의 문자열 H(m)을 계산해낸다.

암호화 해시 함수는 H(x) = H(y)가 되는 서로 다른 두 메시지 x와 y를 찾는 일이 산술적으로 실행 불가능하다.

즉, (m, H(m))이 원래 메시지와 그 메시지에 대해 송신자가 만들어낸 해시값이라고 할 때, 침입자가 원래 메시지와 동일한 해시값을 갖는 다른 메시지 y를 위조해낼 수 없다.

인터넷 체크섬과 같은 간단한 체크섬은 같은 값을 만들기 쉬워 암호화 해시 함수로 사용하기에는 너무 허술하다.

MD5, SHA

MD5 해시 알고리즘이 오늘날 널리 쓰이고 있다.

덧붙이는 단계
- 하나의 1을 메시지 뒤에 붙이고 충분히 많은 0을 뒤에 덧붙여서 메시지 길이가 단위 길이 조건을 만족시킨다.
추가 단계
- 덧붙이기 전 메시지 길이를 64비트로 표현하여 추가
어큐뮬레이터 초기화
루프 단계
- 메시지를 16워드 길이의 단위 블록들로 나누어 4개 라운드로 처리한다.

SHA 알고리즘은 MD4에 사용된 원리와 유사한 원리를 사용하여 널리 사용된다.

8.3.2 메시지 인증 코드(MAC)

메시지 무결성을 얻는 과정

송신자는 메시지 m을 생성하고 해시값 H(m)을 만든다.
- 이때 SHA 등이 사용된다.
송신자는 메시지 m에 H(m)을 첨부하여 확장 메시지 (m, H(m))을 생성한 후 수신자에게 보낸다.
(수신자의 입장에서는 (m, h)로 보임)
(m, h)를 받은 수신자는 H(m)을 계산하고 이것이 h와 같다면 문제 없이 처리되었음을 확인한다.

이때, 침입자가 (m’, H(m’))을 자신이 수신자라고 주장하며 보내면 위 단계를 통과하고 부적절한지 알 수 없다.

인증키를 사용한 메시지 무결성

송신자를 확인하기 위해 송신자 수신자는 비트열 형태의 인증키인 비밀키를 공유하여야 한다.

송신자는 메시지 m을 생성하고 인증키 s와 합하여 m+s를 만들고, H(m+s)를 생성한다.
- H(m+s)를 메시지 인증 코드(message authentication code, MAC 이는 링크 계층의 메시지와는 다르다.)라고 부른다.
송신자는 (m, H(m+s))를 보낸다. (수신자의 입장에서는 (m, h)로 보임)
수신자는 (m, h)를 받으면 H(m+s)를 계산하고 값이 h와 같다면 문제가 없다고 결론 짓는다.

메시지 인증 코드는 복잡한 암호화 알고리즘을 필요로하지 않는다.

MD5와 SHA와 함께 사용되는 메시지 인증코드는 HMAC으로 가장 많이 사용되는 표준이다.

통신 개체들에게 인증키를 전달하는 방법은 네트워크 관리자가 각각의 라우터에 직접 접근하거나 인증키를 각 라우터의 공개키로 암호화하여 네트워크를 통해 전달할 수 있다.

8.3.2 전자 서명

디지털 세계에서 문서의 소유자를 명시하거나 어떤 사람이 문서의 내용에 동의했다는 것을 표시하길 원하고, 전자 서명은 디지털 세계에서 이러한 목적으로 사용된다.

서명 시 실제로 그 사람이 서명했다는 사실, 그리고 오직 그 사람만이 문서에 서명할 수 있었다는 사실을 증명할 수 있어야 한다.

공개키 암호화 방법은 개인키와 공개키를 따로 가지고 있어 전자 서명에 효과적이다. (다른 사람은 개인키로 서명할 수 없다.)

시나리오

서명자는 문서 m을 서명하려한다.
서명자는 자신의 개인키로 K(m)을 만든다. 이것이 바로 전자 서명이다.
- 전자서명 K(m)은 서명자의 개인키로 만들어져 서명자만 만들 수 있다.
전자서명 K(m)을 받은 사람들은 서명자의 공개키를 사용해 원래의 m을 다시 확인할 수 있다.
- 즉, 공개키의 주인인 서명자가 쓴 서명이라는 것이 확인된다.
- 어느 한 사람이 중간에 문서를 조작해 m’을 만들었어도 m과 같지 않으므로 유효하지 않음을 알 수 있다. 즉, 메시지 무결성을 확인할 수 있다.

자신의 개인키로 먼저 암호화하고 공개키로 복호화해도 되는 이유는, m^ed mod n = m^de mod n = m mod n 이기 때문이다.

m 자체에 암호화 복호화를 하면 계산의 부하가 심하다.

이때, 해시 알고리즘을 사용하여 해결할 수 있다.

즉, m을 H(m)으로 표현되는 고정 길이의 지문을 계산해내고, K(H(m))을 계산하여 계산의 부하를 줄인다.

서명자 시나리오

메시지 m을 해시 알고리즘을 이용하여 고정 길이로 바꿔 H(m)을 만든다.
H(m)을 자신의 개인키로 암호화 한다.
(m,K(H(m)))을 보낸다.

수신 시나리오

서명자로 부터 (m,K(h))를 받는다.
서명자의 공개키로 K(h)를 복호화하여 h를 알아낸다.
m을 해시 알고리즘을 이용하여, H(m)으로 만들고 h와 일치하는지 알아낸다.

MAC vs 전자서명

전자 서명은 인증기관과 함께 공개키 하부 구조를 요구하기 때문에 MAC에 비해 더 무거운 기술이다.

많은 프로토콜에서는 MAC이 사용된다.

공개키 인증

전자 서명에서는 공개키가 특정 통신 개체에 속한다는 것을 보증하여야 한다. (IPsec과 TSL를 포함한 많은 보안 네트워킹 프로토콜에서 사용된다.)

중간에 침입자가 자신이 서명자라고 주장하며 메시지를 보내는데, 이때 공개키를 자신의 공개키를 담아 보낸다.

수신자는 침입자의 공개키를 사용해 메세지를 복호화 할 것이고, 수신자는 서명자가 쓴 서명임을 확신할 것이다.

즉, 공개키 암호를 사용하려면 서명자의 공개키라고 생각되는 것이 정말 서명자의 것인지 확인하여야 한다.

공개키가 어떤 통신 개체(서명자)의 것인지 보증하는 일은 일반적으로 CA(인증 기관)에서 담당한다.

CA는 신원을 확인하고 인증서를 발행한다.

CA는 어떤 개체(사람, 라우터)가 스스로 주장하는 자신의 신분이 바로 그 개체가 맞는지 확인한다.
- 인증에 정해진 방법은 없고 CA가 적절한 방법으로 엄격하게 식별자 검증을 수행하리라는 점을 신뢰해야한다.
일단 CA가 신원을 확인하면, CA는 개체의 공개키와 신분 확인서를 결합한 인증서를 만든다.
- 인증서에는 CA가 서명한다.

Chapter 6 - 4. 스위치 근거리 네트워크, 5. 링크 가상화, 6. 데이터 센터 네트워킹, 7. 총정리: 웹페이지 요청에 대한 처리

ssun_bear — Tue, 9 Jul 2024 20:43:47 +0900

6.4 스위치 근거리 네트워크

스위치는 링크 계층에서 동작하기 때문에 링크 계층 프레임을 교환한다.

또한, 네트워크 계층 주소를 인식하지 않으며, 2계층 스위치들로 구성된 네트워크에서 경로를 결정하는 데 OSPF 같은 라우팅 알고리즘을 사용하지 않는다.

즉, IP 주소가 아닌 링크 계층 주소를 사용한다.

6.4.1 링크 계층 주소체계와 ARP

네트워크 계층 주소와 링크 계층 주소

네트워크 계층 주소 체계가 있는데도 링크 계층 주소를 갖는 이유

랜은 IP와 인터넷만을 위해서가 아니라 임의의 네트워크 계층 프로토콜을 위해 설계되었기 때문이다.
만일 어댑터가 MAC 주소 대신에 네트워크 계층 주소를 사용한다면, 네트워크 계층 주소를 어댑터 RAM에 저장하고 어댑터를 이동할 때마다 재구성해야 한다.

즉, 네트워크 구조에서 계층이 독립적인 구성요소가 되도록 하려면 각 계층은 자신만의 주소 기법을 가져야만 한다.

MAC 주소

실제로 링크 계층 주소를 가진 것은 호스트나 라우터가 아닌 호스트나 라우터의 어댑터(네트워크 인터페이스)다.

즉, 다수의 네트워크 인터페이스를 갖고있으므로 여러 개의 링크 계층 주소를 갖게된다.

그러나 링크 계층 스위치는 호스트와 라우터 간에 데이터그램을 전달하는 일을 하기 때문에 호스트나 라우터를 연결해주는 인터페이스에 링크 계층 주소를 할당받지 않는다.

MAC 주소 표기법

MAC 주소는 링크 계층 주소로, 대부분의 랜의 경우 MAC 주소는 길이가 6바이트이며, 따라서 2^48개만큼의 사용 가능한 랜 주소가 있다.

위 그림처럼, 주로 각 바이트는 2개의 16진수로 표기된다.

본래 MAC 주소는 영구적으로 설계되었으나, 이제는 소프트웨어를 사용해서 어댑터의 MAC 주소를 변경할 수 있다.

IEEE가 MAC 주소 공간을 관리하여 모든 어댑터가 다른 주소를 갖게끔 한다.

즉, 어떤 회사가 어댑터를 제조하려면 2^24개의 주소로 이루어진 주소 영역을 구매 후 첫 24비트를 고정하고, 나머지 24비트는 회사로 하여금 각 어댑터에게 유일하게 부여하는 방식으로 2^24개 주소를 할당한다.

MAC 주소는 계층 구조가 아닌 평면 구조를 가지고, 위치가 변하더라도 바뀌지 않는다.

IP 주소가 마치 우편번호 처럼 쓰였다면 MAC주소는 주민등록번호처럼 사용되는 것이다.

MAC 주소를 활용한 어댑터의 송수신

송신 어댑터는 프레임에 목적지 어댑터의 MAC 주소를 넣고 랜상으로 전송한다.
- 스위치는 종종 프레임을 자신의 모든 인터페이스로 브로드캐스트한다.
- 즉, 자신을 목적지로 하지 않는 프레임을 수신할 수도 있다.
프레임을 수신한 어댑터는 프레임 안의 목적지 MAC 주소와 자신의 MAC 주소가 일치하는지 검사한다.
일치하면 데이터그램을 추출하여 프로토콜 스택의 위쪽으로 전달한다.
일치하지 않으면 폐기한다.

랜상의 다른 모든 어댑터가 자신이 전송한 프레임을 수신하고 처리하기를 원할 때 MAC 브로드캐스트 주소(broadcast address)를 넣는다.

이 주소는 모든 비트가 1로된 6바이트 주소이다.

ARP

네트워크 계층 주소와 링크 계층 주소가 있으므로 이들 주소 사이에 변환을 해주는 프로토콜을 ARP(Address Resolution Protocol) 이라고 한다.

ARP 모듈은 IP와 MAC 주소와 마찬가지로 인터페이스마다 존재한다.

위 그림에서 A에서 C로 데이터그램을 전송하려고 한다고 가정해보자.

데이터그램을 전송하기 위해 목적지 IP 뿐만 아니라 MAC 주소도 주어야만 랜이 적절하게 C로 전달할 수 있다.

송신 호스트 즉, A는 목적지 IP주소를 가진 호스트의 MAC 주소를 알아야하는데 이를 ARP가 해준다.

송신 호스트의 ARP 모듈은 입력값으로서 동일한 랜상의 임의의 IP 주소에 대해 대응되는 MAC 주소를 돌려준다.

이러한 면에서 DNS와 비슷한 면이 있다.

그러나 DNS는 인터넷의 임의의 장소에 있는 호스트의 호스트 네임을 해결하는 반면에, ARP는 동일한 서브넷상에 있는 호스트나 라우터 인터페이스의 IP 주소만을 해결한다.

ARP 동작 과정

각 호스트와 라우터는 자신의 메모리에 ARP 테이블(ARP table)을 갖고 있다.

이 테이블은 IP 주소와 MAC 주소 간의 매핑 정보를 포함하며, 테이블에서 각 매핑이 언제 삭제되는지를 나타내는 TTL(time-to-live) 값을 포함한다.

일반적으로 삭제 시간은 엔트리가 테이블에 들어간 후 20분이다.

테이블에 서브넷상의 모든 호스트와 라우터에 대한 엔트리를 갖고 있지 않아도 된다.

즉,데이터그램을 전송하려할 때, ARP 테이블에 목적지 노드에 대한 엔트리가 없을 수 있다.

다음 동작 과정을 보자.

송신 노드는 MAC 주소를 해결하기 위해 ARP 프로토콜을 사용하여 ARP 패킷이라는 특수 패킷을 어댑터에 보낸다.
- ARP 패킷은 송수신 IP주소와 MAC 주소를 포함하는 필드를 가지며 질의 패킷과 응답 패킷 모두 같은 형식을 갖는다.
- 질의 패킷의 목적은 해결하려는 IP주소에 대응되는 MAC 주소를 결정하기 위해 서브넷의 다른 모든 호스트와 라우터들에게 질의하는 것이다.
- 질의 패킷은 브로드캐스트 프레임으로 전송된다.
어댑터는 ARP패킷을 링크 계층 프레임에 캡슐화하고, 목적지 주소를 MAC 브로드캐스트 주소(FF-FF-FF-FF-FF-FF)로 하여 패킷을 전송한다.
이 질의는 서브넷 상의 다른 모든 어댑터에 의해 수신되며, 브로드캐스트 주소 때문에 각 어댑터는 프레임에 들어있는 ARP 패킷을 자신의 ARP 모듈로 전달한다.
ARP 모듈은 자신의 IP 주소가 ARP 패킷에 들어 있는 목적지 IP주소와 일치하는지 검사한다.
일치하는 노드는 요구된 매핑 정보가 포함된 응답 패킷을 돌려보낸다.
- 질의 패킷은 브로드캐스트 프레임으로 전송되는 반면 응답 패킷은 표준 프레임으로 전송된다.
질의 호스트는 자신의 ARP 테이블을 갱신한다.

즉, 노드의 ARP 테이블(ARP table) 은 플러그 앤 플레이(plug-and-play)다. 즉, 관리자가 구성하지 않아도 자동으로 구축된다.

ARP는 링크 계층 주소도 포함하고, 네트워크 계층 주소도 포함하기 때문에 네트워크 계층과 링크 계층의 경계에 있는 프로토콜이다.

서브넷에 없는 노드로의 데이터그램 전송

위 그림에서 호스트 111.111.111.111이 호스트 222.222.222.222로 IP 데이터그램을 전송하려한다고 가정하자.

라우터는 2개의 IP 주소, 2개의 ARP 모듈, 2개의 어댑터(어댑터는 고유한 MAC 주소를 가지고 있으므로 MAC주소도 2개다.)를 가지고 있다.

송신 호스트는 적절한 목적지 MAC 주소와 IP 주소가 포함된 데이터그램을 자신의 어댑터로 전달해야한다.

만약, 송신 어댑터가 목적지 MAC 주소를 49-BD-D2-C7-56-2A 를 사용한다면 목적지 주소는 111.111.111.111 호스트가 포함된 서브넷에 있는 어떤 어댑터의 MAC 주소와도 일치하지 않으므로 서브넷에 있는 어떤 어댑터도 IP 데이터 그램을 자신의 네트워크 계층으로 전달하지 않는다.

즉, 데이터그램은 전달되지 않고 사라진다.

데이터그램이 전달되기 위해서는 라우터 인터페이스 111.111.111.110으로 전달해야만 한다. 따라서 이 프레임에 대한 적절한 MAC 주소는 라우터 인터페이스의 E6-E9-00-17-BB-4B 이다.

동작 과정

송신 호스트가 111.111.111.110 의 MAC 주소를 ARP를 사용하여 알게된다.
MAC주소를 알게 되면 송신 호스트는 IP 목적지 주소가 222.222.222.222 를 포함하는 데이터그램을 알아낸 MAC 주소와 함께 서브넷으로 전송하고 서브넷의 라우터 어댑터는 MAC 주소가 일치하므로 네트워크 계층까지 전달한다.
라우터의 포워딩 테이블을 통해 라우터에게 데이터그램을 라우터 인터페이스 222.222.222.220 을 거쳐서 전달하도록 지시한다.
인터페이스는 데이터그램을 자신의 어댑터로 전달하고 어댑터는 데이터그램을 새 프레임에 캡슐화하여 그 프레임을 다른 서브넷으로 전달한다.
- 여기서의 목적지 MAC 주소는 당연히 ARP를 통해 알게된다.

6.4.2 이더넷

오늘날 이더넷은 가장 우세한 랜 기술이다.

인터넷이 글로벌 네트워킹에 대한 것이라면, 이더넷은 근거리 네트워킹에 대한 것이다.

발전 과정

1980년대
- 이더넷 랜은 노드를 연결하기 위해 동축 버스를 사용했다.
- 버스 토폴로지의 이더넷은 브로드캐스트 랜으로, 전송되는 모든 프레임은 버스에 연결된 모든 어댑터를 거치며 이들에 의해 처리된다.
1990년대
- 랜을 허브 기반의 스타 토폴로지를 사용하는 이더넷으로 대체
- 꼬임쌍선을 사용해서 허브에 직접 연결된다.
- 허브(hub)는 프레임이 아닌 각각의 비트에 대한 처리를 하는 물리 계층 장치다.
- 허브(hub) 가 한 인터페이스로 비트를 수신하면 그 비트의 복사본을 다른 모든 인터페이스로 전송한다.
2000년대 초반
- 중앙의 허브가 스위치(switch)로 대체되었다.
- 스위치(switch) 는 충돌 없는 장치일 뿐만 아니라 저장-후-전달 패킷 스위치이다.

이더넷 프레임 구조

데이터 필드(46~1500바이트)
- 이 필드는 IP 데이터그램을 운반한다.
- 1500바이트를 초과하면 호스트가 단편화해야한다는 것을 의미한다.
- 46바이트보다 작으면 데이터 필드를 채워서 46바이트로 만들어야 한다. 채운 부분을 제거하기 위해 IP 데이터그램 헤더의 길이 필드를 사용한다.
목적지 주소(6바이트)
- 목적지 MAC주소가 들어간다.
출발지 주소(6바이트)
- 출발지 MAC주소가 들어간다.
타입 필드(2바이트)
- 네트워크 계층 프로토콜을 이더넷으로 하여금 다중화하도록 허용한다.
- 즉, IP 이외의 네트워크 계층 프로토콜을 사용할 수 있게끔 한다.
순환 중복 검사(CRC)(4바이트)
- CRC 필드의 목적은 수신 어댑터가 프레임에 오류가 생겼는지 검출할 수 있게 한다.
프리앰블(8바이트)
- 이더넷 프레임은 8바이트의 프리앰블(preamble) 필드로 시작한다.
- 프리앰블의 첫 7바이트는 10101010 값을 갖고 마지막 바이트는 10101011이다.
- 프리엠블의 첫 7바이트는 수신 어댑터를 깨우고, 수신자의 클록을 송신자의 클록과 동기화하는 역할을 한다.
- 송신 어댑터는 이더넷 랜 종류에 따라 원하는 속도로 프레임을 전송하려 하지만 송신 어댑터는 목적지 속도에 정확히 맞게 전달할 수 없으므로 수신 어댑터는 단순히 프리앰블의 첫 7바이트에 있는 비트들에 맞춤으로써 송신 어댑터의 클록에 맞출 수 있다.
- 8번째 바이트의 마지막 두비트는 수신 어댑터에게 중요한 것이 오고 있음을 알려준다.

이더넷의 비연결형 서비스(connectionless service), 비신뢰적인 서비스

송신 어댑터는 데이터그램을 전송할 때 핸드셰이킹 하지 않고 이더넷 프레임에 캡슐화해서 랜으로 전송한다.

수신 어댑터는 CRC 검사를 통해 프레임을 검사하지만 이에 대한 확인 응답 혹은 부정 확인 응답을 보내지 않는다.

그저, 실패하면 폐기한다.

애플리케이션이 UDP 또는 TCP를 사용하는지에 따라 데이터그램의 손실을 알 수 있음이 결정된다.

UDP의 경우 알 수 없고, TCP는 확인 후 재전송하게 할 것이다.

즉, 이더넷은 전송하고 있는 데이터그램이 재전송인지 새로운 데이터그램인지 구분할 수 없다.

이더넷 기술

이더넷은 수년에 걸쳐 진화해왔으며, 오늘날의 이더넷은 동축케이블을 사용하는 초기 버스 토폴로지 설계와 상당히 다르다.

요즘은 노드가 꼬임쌍선이나 광섬유 케이블로 만들어진 점대점 세그먼트를 통해 스위치에 연결된다.

이더넷이 발전하여도, 프레임 형식은 그대로 유지되어 사용된다.

버스 토폴로지와 허브 기반의 스타 토폴로지의 이더넷 표준은 노드들이 동시에 전송하면 프레임 충돌이 발생하는 브로드캐스트 링크였다.

이 충돌을 처리하기 위해 CSMA/CD 프로토콜이 포함되었다.

현재 많이 사용하는 이더넷은 저장-후-전달 패킷 교환을 하는 스위치 기반의 스타 토폴로지인데, 여전히 MAC 프로토콜이 필요할까?

스위치 기반 이더넷 랜에는 충돌이 없어 MAC 프로토콜이 필요하지 않다.

6.4.3 링크 계층 스위치

스위치의 역할은 들어오는 링크 계층 프레임을 수신해서 출력 링크로 전달하는 것이다.

스위치는 그 자체가 서브넷의 호스트와 라우터들에게 투명하다.

즉, 호스트/라우터는 프레임을 스위치가 아닌 다른 호스트/라우터를 목적지로해서 랜상으로 보내며, 중간에 스위치가 프레임을 받아서 다른 노드에게 전달하는 것을 알지 못한다.

프레임이 스위치 출력 인터페이스들 중 하나에 도착하는 속도가 그 인터페이스의 링크 용량을 일시적으로 초과할 수 있다.

이 문제를 해결하기 위해, 스위치 출력 인터페이스는 버퍼를 갖고 있다.

포워딩과 필터링

필터링(filtering)
- 프레임을 인터페이스로 전달할지 또는 폐기(drop)할지 결정하는 스위치의 기능
- 스위치 테이블(switch table)을 이용
포워딩(forwarding)
- 프레임이 전송될 인터페이스를 결정하고 프레임을 해당 인터페이스로 내보내는 기능
- 스위치 테이블(switch table)을 이용
스위치 테이블(switch table)
- 랜상의 모든 호스트와 라우터는 아니지만 일부 노드에 대한 엔트리가 포함되어 있다.
- 스위치 테이블 엔트리 구성
  - MAC 주소
  - MAC 주소로 가게 하는 스위치 인터페이스
  - 해당 엔트리가 만들어진 시점

스위치 테이블 엔트리의 동작

목적지 주소를 가진 프레임이 스위치 인터페이스 x에 도달했다고 하자.

테이블에 목적지 주소에 대한 엔트리가 없는 경우
- 스위치는 프레임의 복사본을 프레임이 수신된 인터페이스를 제외한 모든 인터페이스의 출력 버퍼로 전달한다.
- 즉, 브로드캐스트한다.
테이블에 목적지 주소가 x 인터페이스에 연관된 엔트리가 있는 경우
- 프레임은 송신자 어댑터를 포함하는 랜 세그먼트로부터 왔다.
- 프레임을 다른 인터페이스로 전달할 필요가 없으며, 프레임을 제거함으로써 필터링 기능을 수행한다.
테이블에 목적지 주소가 y≠x 인터페이스와 연관된 엔트리가 있는 경우
- 프레임은 y 인터페이스에 접속된 랜 세그먼트로 전달되어야 한다.
- 즉, 해당 인터페이스 출력 버퍼에 프레임을 넣음으로써 포워딩 기능을 수행한다.

자가학습

스위치는 테이블을 자동으로, 동적으로, 자치적으로 자가학습(self-learning)하는 특징이 있다.

동작 과정

스위치 테이블은 초기에 비어있다.
인터페이스로 수신한 각 프레임에 대해 스위치는 다음과 같은 정보를 저장한다.
- 프레임의 출발지 주소 필드에 있는 MAC 주소
  - 즉, 다음번 수신 때 다른 랜에서 목적지 주소 필드를 해당 MAC 주소를 갖게되면 프레임을 알맞게 전달할 수 있게 된다.
- 프레임이 도착한 인터페이스
- 현재 시간
랜에 있는 모든 호스트가 프레임을 송신하면, 결국 모든 호스트에 대한 정보가 테이블에 기록된다.
수명 시간(aging time)이 지난 후에도 스위치가 해당 주소를 출발지 주소로 하는 프레임을 수신하지 못하면 테이블에서 이 주소를 삭제한다.
- 즉, PC가 다른 PC로 대체되면 원래 PC의 MAC 주소는 스위치 테이블에서 삭제된다.

스위치는 네트워크 관리자나 사용자의 개입을 요구하지 않으므로 플러그 앤 플레이 장치(plug-and-play device)다.

링크 계층 스위치의 특성

충돌 제거
- 스위치로 구축된 랜에는 충돌로 인해 낭비되는 대역폭이 없다.
- 프레임을 버퍼링하며 어느 시점이든 세그먼트에 하나 이상의 프레임을 전송하지 않는다.
- 브로드캐스트 링크를 사용하는 랜보다 성능이 월등히 향상된다.
이질적인 링크들
- 링크들을 별개로 분리하기 때문에 랜의 각 링크는 상이한 속도로 동작할 수 있으며 상이한 매체를 사용할 수 있다.
관리
- 스위치는 향상된 보안을 제공할 뿐만 아니라 네트워크 관리를 쉽게 할 수 있게 한다.
- e.g. 케이블이 끊긴다면 그쪽 호스트의 연결만 끊어진다, 오동작으로 프레임을 계속 보내는 경우 이 문제를 감지하고 오동작하는 어댑터의 연결을 의도적으로 끊는다.
- 대역폭 사용, 충돌률, 트래픽 종류에 대한 통계치를 수집하여 볼 수 있다.

보안 초점

스위치 테이블에 엔트리가 있을 때
- 호스트가 스위치에 연결되면 보통 자신을 목적지로 해서 전송된 프레임만 수신하기 때문에 다른 호스트는 프레임을 훔쳐볼 수 없다.
스위치 테이블에 엔트리가 없을 때
- 스위치가 프레임을 브로드캐스트하기 때문에 스니퍼는 자신을 목적지로 하지 않는 일부 프레임을 훔쳐볼 수 있다.
- 이를 이용해 스위치 독(switch poisoning)이라는 공격 수법을 사용하여 프레임을 훔쳐본다.
  - 스위치 독(switch poisoning) 은 여러 가짜 출발지 MAC 주소를 갖는 패킷을 상당수 보내 스위치 테이블을 가짜 엔트리로 가득채워 합법적인 호스트들의 MAC 주소를 넣을 공간을 없애는 것을 말한다.

스위치 대 라우터

라우터
- 네트워크 계층 주소를 사용해서 패킷을 전달하는 저장 후 전달 패킷 스위치다.
- 3계층 패킷 스위치이다.
스위치
- 저장후 전달 패킷 스위치이지만 MAC 주소를 사용해서 패킷을 전달한다.
- 2계층 패킷 스위치이다.

이 둘은 근본적으로 다르지만(MAC 주소, IP 주소를 사용한다는 점에서), 네트워크 관리자는 상호연결 장치를 설치할 때 종종 이들 중에서 선택해야만 한다.

실제로, 라우터는 충돌 없이 학과 간의 통신이 가능하게 할 수 있다.

스위치의 장점

플러그 앤 플레이 장치(plug-and-play device) 로 관리자가 크게 신경쓸 필요가 없다.
높은 패킷 필터링 및 전달률을 갖는다.

스위치의 단점

브로드캐스트 프레임의 순환을 방지하기 위해 스위치 네트워크의 실제 사용되는 토폴로지는 스패닝 트리로 제한된다.
대규모 스위치 네트워크에서는 호스트와 라우터가 커다란 ARP 테이블을 갖게 되며 상당한 양의 ARP 트래픽이 생성되고 처리된다.
브로드캐스트 트래픽의 폭주에 대비한 방안을 제공하지 않는다.

라우터의 장점

계층구조이므로, 네트워크에 중복된 경로가 있을 때 조차도 패킷은 라우터를 따라 순환하지 않는다. 즉, 스패닝 트리로 제한받지 않고 최상의 경로를 사용할 수 있다.
제한이 없으므로 인터넷 토폴로지가 자유롭게 구축될 수 있게 한다.
브로드캐스트 폭풍에 대비한 방화벽 보호기능이 있다.

라우터의 단점

플러그 앤 플레이 장치(plug-and-play device) 가 아니다.
스위치보다 패킷당 처리 시간이 더 크다.

일반적으로, 작은 네트워크는 트래픽이 지역적으로 제한되어 있고 IP 주소의 구성을 요구하지 않으면서도 총 처리율을 증가시키므로 스위치로도 충분하다.

그러나 보통 수천 개의 호스트로 구성된 큰 네트워크에서는 라우터도 포함한다.

6.4.4 가상 근거리 네트워크(VLAN)

위 구조에서 스위치는 계층적으로 구성되어있는데, 이러한 구성의 단점은 다음과 같다.

트래픽 격리의 부족
- 계층 구조는 그룹 트래픽을 단일 스위치 내로 격리해주지만, 브로드캐스트 트래픽은 여전히 전체 네트워크로 전달되어야만 한다.
- 즉, 브로드캐스트의 범위를 제한하면 랜 성능을 향상할 수 있다.
스위치의 비효율적인 사용
- 기관에 그룹이 3개가 아닌 10개가 있는 경우 첫 단계 스위치가 10개가 필요하다.
- 그룹 내 인원수가 10명보다 작으면 96 포트 스위치 하나로 모든 사람을 수용할 수 있지만 스위치 하나로는 트래픽 격리를 할 수 없다.
사용자 관리
- 사원이 한 그룹에서 다른 그룹으로 이동하는 경우 이 사원을 다른 스위치에 연결하기 위해 물리적 케이블 연결을 변경해야만 한다.

위와 같은 단점을 가상 근거리 네트워크(virtual local area network, VLAN)를 지원하는 스위치를 사용해서 해결할 수 있다.

VLAN을 지원하는 스위치는 하나의 물리적 근거리 네트워크 인프라스트럭처상에서 여러 개의 가상 근거리 네트워크들을 정의할 수 있게한다.

VLAN에 속한 호스트들은 마치 스위치에 자신들만(다른 호스트들은 없이) 연결된 것처럼 서로 통신한다.

포트 기반 VLAN에서는 네트워크 관리자가 스위치 포트(인터페이스)를 그룹으로 나눈다.

나뉜 각 그룹은 하나의 VLAN을 구성하며, 한 VLAN 포트들은 하나의 브로드캐스트 도메인을 형성한다.

즉, 같은 그룹의 다른 포트에만 브로드캐스트 트래픽을 전달할 수 있다.

기본 VLAN

위 그림은 16개의 포트를 갖고 있는 단일 스위치를 보여준다.

포트 2~8은 EE VLAN이고, 9~15는 CS VLAN에 속한다.

VLAN은 각각의 프레임을 서로 격리해준다.
그룹을 변경하려면 관리자가 포트가 속한 그룹이 바뀌도록 재구성한다.
2개의 그룹을 위해 있던 2개의 스위치가 하나의 스위치로 대체되었다.

즉, 위의 단점을 모두 해결한다.

VLAN 스위치는 포트-VLAN 매핑 테이블을 관리하고 네트워크 관리자가 스위치 관리 소프트웨어를 사용해서 이를 바꿀 수 있다.

또한, 스위치 하드웨어는 같은 VLAN에 속한 포트들 간에만 프레임을 전달한다.

EE VLAN to CS VLAN 트래픽 전송 과정

EE VLAN과 CS VLAN은 물리적으로는 붙어있지만 논리적으로는 다른 LAN이기 때문에 트래픽 전송이 다른 스위치나 라우터를 거쳐야만 한다.

VLAN 스위치 포트(미사용 포트, e.g. 위 그림에서 1번 포트)를 외부 라우터에 연결한다.
VLAN 스위치 포트를 두개의 LAN 모두에 속하게 한다.
데이터그램이 먼저 CS VLAN(스위치 포트)를 통과해서 라우터에 도달한다.
라우터에 의해 CS VLAN을 통해 CS 호스트로 전달된다.

스위치 생산자들은 VLAN 스위치와 라우터를 모두 포함시켜 네트워크 관리자가 위 과정을 쉽게할 수 있도록 한다.

외부 스위치가 VLAN에 속하길 원하는 경우

스위치에 N개의 VLAN이 있다고 하면 N개의 포트를 N개의 VLAN에 속하게 하고, 외부 스위치에 하나씩 연결해주면 외부 스위치도 VLAN 스위치와 같이 일할 수 있다.

그러나 N개의 VLAN에는 N개의 포트가 필요하므로 확장에 문제가 있다.

위 방법은 VLAN 트렁킹(VLAN Trunking) 방식이다.

스위치 마다 하나의 특수 포트가 2개의 VLAN을 연결하는 트렁크 포트(trunk port)로 구성되어있다.

트렁크 포트(trunk port) 는 모든 VLAN에 속하며 한 VLAN에서 전송한 프레임들을 트렁크 링크를 통해 다른 스위치로 전달해준다.

이때 어떤 트렁크 포트로 온 프레임이 어떤 VLAN에 속하는지 알 수 없다.

이를 위해 IEEE는 VLAN 트렁크를 통과하는 프레임을 위한 확장된 형태의 이더넷 프레임 형식을 정의했다.

확장된 이더넷 프레임 형식은 VLAN을 식별해주는 4바이트 VLAN 태그(VLAN Tag)를 헤더에 갖고 있다.

VLAN 태그(VLAN Tag) 는 당연하지만, 송신 측의 스위치에 의해 추가되고, 수신 측에 있는 스위치에 의해 파싱되고 제거된다.

VLAN 태그(VLAN Tag) 구성

2바이트 태그 프로토콜 식별자(Tag Protocol Identifier, TPID) 필드
2바이트 태그 제어 정보(Tag Control Information) 필드
- 12비트의 VLAN 식별자(identifier) 필드 <- 추가 필요
- 3비트 우선순위(priority) 필드

6.5 링크 가상화: 링크 계층으로서의 네트워크

MPLS의 목표는 고정 길이 레이블과 가상 회선을 기반으로 데이터그램을 전달하기 위해 목적지 기반 IP 데이터그램 인프라스트럭처를 포기하는 것이 아니라, 가능한 경우 데이터그램을 선택적으로 레이블링해서 라우터로 하여금 고정 길이 레이블을 기반으로 데이터그램을 전달할 수 있도록 목적지 기반 IP 데이터그램 전달 하부구조를 확장하는 것이다.

MPLS 헤더

MLPS가능 라우터에 의해 처리되는 링크 계층 프레임의 형식은 2계층 헤더와 3계층 헤더 사이에 작은 MPLS 헤더를 가진다.

MPLS 헤더에는 레이블, 실험을 위해 예약된 3개의 비트, 일련의 스택된 MPSL 헤더들의 끝을 나타내는 1개의 S 비트, TTL 필드가 있다.

MPLS 헤더는 MPLS 가능 라우터들 사이에서만 전송될 수 있다.

MPLS 동작 과정

MPLS 가능 라우터는 MPLS 레이블을 포워딩 테이블에서 찾아 적당한 출력 인터페이스로 데이터그램을 전달하여 MPLS 프레임을 전달하므로 종종 레이블 스위치 라우터(label-switched router)라고 부른다.

즉, MPLS 가능 라우터는 목적지 IP 주소를 꺼내 볼 필요도 없고, 포워딩 테이블에서 최장 프리픽스 대응을 찾을 필요도 없다.

R1에서 R4 까지만 MPLS 기능이 있을 때 어떻게 상호 동작하는지 알아보자.

R1은 자신이 A까지 라우팅할 수 있고 MPLS 레이블 6을 포함하는 프레임을 목적지로 보낼 수 있음을 R2 R3에게 광고한다.
R3는 자신이 목적지 A,D까지 라우팅할 수 있고, MPLS 레이블 10과 12를 포함하는 입력 프레임을 각각 이들 목적지를 향해 스위칭할 수 있음을 R4에게 광고한다.
…

이를 반복하여 R4는 3개의 MPLS 경로를 갖게 된다.

MPLS 가능 라우터는 패킷의 IP 헤더를 건드리지 않고 동작한다.

즉, MPLS는 IP 주소를 고려하지 않고 레이블 기반으로 스위칭하여 스위칭 속도를 향상시켰다.

MPLS는 또한 트래픽을 관리하는데, IP 라우팅 프로토콜은 최소 비용 경로 하나만 지정하는 반면, MPLS는 표준 IP 라우팅 프로토콜을 사용해서는 불가능한 경로까지 제공한다.

이는 MPLS를 사용해서 트래픽 엔지니어링(traffic engineering) 을 제공하는 간단한 하나의 방식이다.

6.6 데이터 센터 네트워킹

데이터 센터는 인터넷에 연결되어 있을 뿐만 아니라 내부 호스트들 간 상호연결을 위해 자체 데이터 센터 네트워크(data center network)를 갖고 있다.

데이터 센터의 3가지 목적

웹 페이지, 검색 결과, 전자메일, 스트리밍 비디오와 같은 콘텐츠 제공
검색 엔진을 위한 분산 인덱스 계산과 같은 특정 데이터 처리 작업이 가능한 대량 병렬 컴퓨팅 인프라스트럭처 역할
다른 회사에게 클라우드 컴퓨팅(cloud computing)을 제공

6.6.1 데이터 센터 구조

호스트

데이터 센터에서 작업을 수행한다.

피자 박스 모양의 블레이드(blade)라고도 불린다.

CPU, 메모리, 디스크 저장장치를 갖고 있는 범용 호스트다.

호스트들은 20~40대의 블레이드를 적재할 수 있는 랙(rack)에 적재된다.

데이터 센터 내부에서 사용되는 자신만의 IP 주소를 할당 받는다.

TOR(top of rack) 스위치

랙의 맨 위에는 TOR스위치라고 불리는 스위치가 있다.

TOR 스위치는 네트워크 인터페이스 카드를 통해 랙에 있는 호스트들을 연결해준다.

그 외의 다른 포트들을 통해 데이터 센터의 다른 스위치들과 연결된다.

경계 라우터(border router)

외부 클라이언트와 내부 호스트 간 트래픽 플로우를 처리하기 위해 하나 이상의 경계 라우터를 갖는다.

경계 라우터는 데이터 센터 네트워크를 공중 인터넷으로 연결해준다.

로드 밸런싱

외부 클라이언트의 요청을 지원하기 위해, 애플리케이션에는 공용 IP 주소가 할당되며 클라이언트는 이 IP 주소로 요청을 보내고 응답을 받는다.
요청을 로드 밸런서로 보낸다.
- 일반적으로 여러 로드 밸런서를 갖고 있으며, 각 로드 밸런서는 특정 클라우드 애플리케이션을 위해 사용된다.
- 로드 밸런서 는 목적지 IP 주소 뿐만 아니라 목적지 포트를 보고 결정하기 때문에 4계층 스위치라고도 한다.
로드 밸런서는 요청을 호스트로 분배하고 호스트의 현재 부하 상태에 따라서 호스트 간의 부하를 균등하게 한다.
- 로드 밸런서 는 호스트의 공용 외부 IP 주소를 내부 IP 주소로 변환해주고 그 반대 변환도 해주기 때문에 NAT과 유사한 기능을 제공한다.

클라이언트가 호스트와 직접 통신하지 못하게 하여 내부 구조를 숨기고 보안을 제공한다.

계층적 구조

계층 구조의 최상단에서는 경계 라우터가 접속 라우터들에 연결된다.
접속 라우터는 최상단 스위치와 연결된다.
- 접속 라우터 아래에는 총 세 단의 스위치들이 있다.
최상단 스위치는 여러 개의 두 번째 단 스위치들과 로드 밸런서에 연결된다.
두 번째 단 스위치는 랙의 TOR 스위치(세 번째 단)를 통해 여러 랙으로 연결 된다.
호스트들은 랙에 연결되어 하나의 서브넷을 형성한다.
- ARP 브로드캐스트 트래픽을 지역 내로 한정하기 위해 서브넷은 다시 작은 VLAN 서브넷들로 분할된다.

클라우드 애플리케이션 제공자 입장에서는 애플리케이션 가용성을 높게 유지하는 것이 중요하기 때문에 데이터 센터 설계에 여분의 네트워크 장비와 링크를 포함시킨다.

계층적 구조의 문제

맨 위 데이터센터 그림에서 랙 1에 있는 10대의 호스트가 랙 5의 대응되는 호스트로 플로우를 보낸다고 하자.

마찬가지로 랙 2에서 6, 랙 3에서 7, 랙 4에서 8로 플로우를 보낸다고 하자.

하나의 링크를 지나가는 플로우들이 공평하게 링크 용량을 나눠서 사용하면 A에서 B로의 링크를 거쳐 가는 40개의 플로우는 각각 n Gps/40 만 수신하게 된다.

네트워크 인터페이스 카드의 전송률이 n Gps/40 보다 크다면 이는 문제가 생기고, 위쪽을 거쳐가는 호스트 간 플로우의 경우 훨씬 더 심각해진다.

해결방안

고속 스위치와 라우터를 사용한다.
- 이는 비용이 많이 나간다.
2단 또는 1단 스위치를 경유하는 렉 간 통신이 최소화되도록 서로 관련된 서비스와 데이터를 가능한 한 같은 곳에 위치시킨다.
- 데이터 센터의 주요 요구사항인 계산과 서비스를 융통성 있게 배치해야 한다는 것 때문에 제한적이다.
TOR 스위치들과 2단 스위치들 간, 2단 스위치들과 1단 스위치들 간 연결성을 증가시킨다.
- 예를 들어, 하나의 TOR 스위치를 2개의 2단 스위치에 연결함으로써 랙 간에 여러 개의 링크 비결합(link-disjoint), 스위치 비결합 경로를 제공할 수 있다.
- 단 간의 연결성(경로의 다양성)을 증가시킴으로써 스위치 간 용량 및 신뢰성 증가라는 두 가지 이득을 얻게 된다.

6.6.2 데이터 센터 네트워킹 동향

비용 감소

데이터 센터 네트워킹에서 가장 중요한 동향은 계층적으로 단을 구성해서 데이터 센터 호스트들을 상호 연결해주는 것이다.

즉, 데이터 센터의 호스트는 다른 어떤 호스트와도 통신할 수 있게 한다.

데이터 센터 상호연결 네트워크는 다수의 소규모 스위치들로 구성된다.

중앙 집중형 SDN 제어 및 관리

데이터 센터는 단일 기관에 의해 관리되기 때문에 다수의 대규모 센터 운영자들은 SDN과 같은 논리적 중앙 집중형 제어라는 개념을 쉽게 받아들이게 된다.

SDN의 데이터 평면과 소프트웨어 기반 제어 평면에 대한 명확한 분리가 데이터 센터 구조에도 반영된다.

가상화

가상 머신(virtual machine,VM)은 소프트웨어를 실행하는 애플리케이션을 물리 하드웨어로부터 분리시켰다.

이렇게 분리하여 VM을 상이한 랙에 위치한 물리 서버들 간에 문제없이 마이그레이션할 수 있게 했다.

표준 이더넷과 IP 프로토콜은 서버들 간 활성화된 네트워크 연결을 유지한 채로 VM들을 이동시키는 것을 제한한다.

이를 해결하는 방법은 전체 데이터 센터 네트워크를 단일, 평면, 2계층 네트워크로 다루는 것이다.

모든 호스트가 단일 스위치에 연결된 것과 유사한 효과를 얻기 위해 브로드캐스트 대신 DNS 형태의 질의 시스템을 사용하도록 ARP를 수정하고 디렉토리에 VM에 할당된 IP 주소와 데이터 센터 네트워크에서 VM이 현재 연결된 물리 스위치 간 매핑 정보를 관리한다.

물리적 제약사항

광역 인터넷과 달리 데이터 센터 네트워크는 고용량, 초 저지연 환경에서 동작한다.

따라서 데이터 센터의 경우 버퍼 크기가 작으면 TCP 등과 같은 혼잡 제어 프로토콜이 효율적으로 동작하지 못한다.

손실복구와 타임아웃은 데이터 센터를 매우 비효율적으로 만들기 때문에 혼잡 제어 프로토콜은 반응이 빠르고 초 저지연으로 동작해야한다.

이러한 문제를 해결하기 위해 데이터 센터에 적합하도록 TCP를 변형한 방법부터 표준 이더넷에 RDMA(Remote Direct Memory Access)를 구현한 방법이 제안 및 적용되었다.

하드웨어 모듈화와 커스터마이징

또 다른 주요 동향은 선박 컨테이너(shipping container) 기반의 모듈화된 데이터 센터(modular data center, MDC)다.

MDC에서는 표준 12m 선박 컨테이너에 미니 데이터 센터를 구축한 후 컨테이너를 데이터 센터의 위치로 이동시킨다.

컨테이너에는 수십 개의 렉에 최대 수천 개의 호스트들이 촘촘히 포장되어 들어 있다.

데이터 센터 위치에는 여러 컨테이너들이 서로 연결되어 있고 인터넷도 연결되어 있다.

미리 제작된 컨테이너를 데이터 센터에 설치한 후에는 컨테이너에 대한 서비스를 하기 어려울 수 있다.

따라서 컨테이너 성능은 점진적으로 저하되도록 설계하고, 여러 구성요소가 고장나고 성능이 임계치 이하로 떨어지면 컨테이너를 제거하고 교체한다.

MDC에는 각 컨테이너의 내부 네트워크와 컨테이너들을 연결하는 코어 네트워크, 두 종류의 네트워크가 있다.

그러나 일상적인 작업 부하를 처리할 수 있도록 컨테이너들 간에 고속의 호스트-호스트 대역폭을 제공하면서도 수십 만대의 컨테이너들을 상호 연결해주는 코어 네트워크를 설계하는 것은 아직 난제로 남아있다.

지속적인 구축과 커스터마이징

대규모 클라우드 제공자가 네트워크 어댑터, 스위치, 라우터, TOR, 소프트웨어, 네트워킹 프로토콜 등 데이터 센터에 있는 모든 것을 계속해서 구축하거나 커스터마이징 한다.

신뢰성 확보

근처 건물들에 데이터 센터를 복제하여 가용 구역을 확보하여 신뢰성을 높인다.

6.7 총정리: 웹페이지 요청에 대한 처리

학생 밥이 학교의 이더넷 스위치에 랩톱을 연결하고 www.google.com을 다운로드 하는 과정을 보자.

6.7.1 시작하기: DHCP, UDP, IP 그리고 이더넷

밥은 랩톱을 켠 후 학교 이더넷 스위치에 연결되어 있는 이더넷 케이블에 연결한다.

학교 라우터는 ISP comcast.net에 연결되어 있고, comcast.net 은 이 학교에 DNS 서비스를 제공하며, DNS 서버는 학교 네트워크가 아닌 컴캐스트 네트워크에 있고 DHCP 서버는 라우터에서 실행되고 있다고 가정하자.

밥의 랩톱 운영체제는 DHCP 요청 메시지를 만들어서 이 메시지를 목적지 포트 67(DHCP 서버)과 출발지 포트 68(DHCP 클라이언트)을 갖는 UDP 세그먼트에 넣는다. 이 UDP 세그먼트는 브로드캐스트 IP 목적지 주소(255.255.255.255)와 출발지 IP 주소 0.0.0.0(랩톱이 아직 IP가 없기 때문에)을 갖는 IP 데이터그램에 들어간다.
DHCP 요청 메시지를 포함한 IP 데이터그램은 이더넷 프레임에 들어간다. 스위치에 연결된 모든 장치에 이 프레임이 브로드캐스트될 수 있도록 이더넷 프레임의 목적지 MAC 주소는 FF:FF:FF:FF:FF:FF로 설정된다. 이 프레임의 출발지 MAC 주소는 밥 랩톱의 MAC 주소인 00:16:D3:23:68:8A 가 된다.
DHCP 요청 메시지를 포함한 브로드캐스트 이더넷 프레임은 밥의 랩톱이 처음으로 이더넷 스위치에 전송한 프레임이다. 스위치는 자신의 모든 출력 포트로 브로드캐스트 한다.
- 이때, 자가학습을 통해 스위치 테이블을 갱신한다.
라우터는 MAC 주소 00:22:6B:45:1F:1B 인 인터페이스로 DHCP 요청 메시지가 포함된 브로드캐스트 이더넷 프레임을 수신하고, 이더넷 프레임으로부터 IP 데이터그램을 추출한다. 데이터그램의 브로드캐스트 IP 목적지 주소는 이 IP 데이터그램이 노드의 상위 계층 프로토콜에 의해 처리되어야함을 의미한다. 이렇게 함으로써 데이터그램의 UDP 세그먼트가 UDP로 역다중화되고, UDP 세그먼트로부터 DHCP 요쳥 메시지가 추출되고 DHCP 서버는 요청 메시지를 갖게된다.
라우터에서 실행되고 있는 DHCP 서버가 CIDR 블록 68.85.2.0/24 에 있는 IP 주소들을 할당할 수 있다고 하자. DHCP 서버는 밥의 랩톱에게 주소 68.85.2.101을 할당했다고 가정하자. DHCP 서버는 이 IP 주소와 DHCP 서버의 IP 주소, 디폴트 게이트웨이 라우터의 IP 주소,서브넷 블록을 포함하는 DHCP ACK 메시지를 만든다. 이 메시지는 UDP 세그먼트에 들어가고 세그먼트는 IP 데이터그램으로 들어가고 데이터그램은 이더넷 프레임으로 들어간다. 이더넷 프레임은 출발지 MAC 주소로 홈 네트워크로의 라우터 인터페이스의 MAC 주소로, 목적지 MAC 주소로 밥 랩톱의 MAC 주소를 갖는다.
DHCP ACK 메시지를 포함한 이더넷 프레임은 라우터에 의해 스위치로 전송된다(유니캐스트). 스위치는 자가학습을 하며 밥의 랩톱으로부터 DHCP 요청 메시지를 포함한 이더넷 프레임을 수신했었기 때문에 00:16:D3:23:68:8A를 목적지로 하는 프레임을 밥의 랩톱으로 가는 출력 포트로 전달할 수 있다.
밥의 랩톱은 DHCP ACK 메시지를 수신한 후 이더넷 프레임으로부터 UDP 세그먼트를 추출하고 DHCP ACK 메시지를 추출한다. 밥의 DHCP 클라이언트는 자신의 IP 주소와 DNS 서버의 IP 주소를 기록한다. 또한 IP 포워딩 테이블에 디폴트 게이트웨이의 주소를 저장한다. 밥의 랩톱은 자신이 속한 서브넷의 외부를 목적지 주소로 하는 모든 데이터그램을 디폴트 게이트웨이로 보내게된다.

6.7.2 여전히 시작하기: DNS와 ARP

www.google.com IP주소 알아내기

랩톱 운영체제는 DNS 질의 메시지를 생성하며, 이때 DNS 질의 메시지의 질문 부분에 www.google.com을 넣는다. DNS 질의 메시지는 목적지 포트가 53(DNS 서버)인 UDP 세그먼트에 들어간다. UDP 세그먼트는 목적지 IP 주소 68.87.71.226(DHCP ACK 메시지에 들어 있던 DNS 서버의 주소)로 하여 IP 데이터그램에 들어간다.
만들어진 이더넷 프레임은 밥의 학교 네트워크에 있는 게이트웨이 라우터로 보내진다. 밥의 랩톱이 학교 게이트웨이 라우터의 IP 주소를 DHCP ACK 메시지를 통해 알고 있긴 하지만 MAC 주소는 모르므로 ARP 프로토콜을 사용한다.
밥의 랩톱은 목표 IP주소 68.87.2.1 을 포함한 ARP 질의 메시지를 생성하며 이 메시지는 브로드캐스트 목적지 주소 FF:FF:FF:FF:FF:FF를 갖는 이더넷 프레임에 포함되어 스위치로 전송된다. 스위치는 게이트웨이 라우터를 포함한 모든 연결된 장치로 프레임을 전달한다.
게이트웨이 라우터는 학교 네트워크로의 인터페이스를 통해 프레임을 수신하고, ARP 메시지로부터 목표 IP 주소 68.85.2.1을 찾아서 자신의 인터페이스의 IP 주소와 일치하는 것을 알게 된다. 따라서 게이트웨이 라우터는 68.85.2.1 에 대응하는 MAC주소를 포함하는 ARP 응답 메시지를 만든다. 목적지 주소를 랩톱의 MAC주소로 하여 이더넷 프레임에 넣어 스위치로 보내며, 스위치는 이를 랩톱으로 전달한다.
밥의 랩톱은 프레임을 수신해서 게이트웨이 라우터의 MAC주소를 추출한다.
랩톱은 DNS 질의 메시지를 목적지 MAC주 소를 게이트웨이 라우터의 MAC 주소로, IP 목적지 주소로 DNS 서버로 하여 스위치로 보내고 스위치는 프레임을 게이트웨이 라우터로 전달한다.

6.7.3 여전히 시작하기: DNS 서버로의 인트라 도메인 라우팅

게이트웨이 라우터는 프레임을 받아서 DNS 질의가 포함된 IP 데이터그램을 추출한다. 라우터는 데이터그램의 목적지 주소 68.87.71.226 를 포워딩 테이블에서 찾아 데이터그램을 컴캐스트의 라우터로 보내야 한다는 사실을 알게되고, 학교 라우터를 컴캐스트의 라우터로 연결해주는 링크에 적합한 링크 계층 프레임에 IP 데이터그램을 넣은 후, 프레임을 해당 링크로 전송한다.
컴캐스트의 좌측 상단 라우터는 프레임을 수신한 후, IP 데이터그램을 추출해서 데이터그램의 목적지 주소와 포워딩 테이블(인터넷의 인터 도메인 프로토콜인 BGP와 RIP,OSPF, IS-IS 같은 컴캐스트 의 인트라 도메인 라우팅 프로토콜에 의해 결정됨)로 부터 데이터 그램을 DNS 서버로 전달할 출력 인터페이스를 결정한다.
IP 데이터그램이 DNS 서버에 도착하고, DNS 서버는 DNS 질의 메시지를 추출한 후 DNS 데이터베이스에서 www.google.com 에 해당하는 IP주소를 포함하는 DNS 자원 레코드를 찾는다. DNS 서버는 DNS 응답 메시지를 만들어서 UDP 세그먼트를 만들고 데이터그램을 만들어 밥의 랩톱을 목적지로 하여 보낸다,
- DNS 서버에 캐싱되어 있다고 가정하자. google.com에 대해 책임 DNS 서버가 캐싱 데이터를 준 것이다.
밥의 랩톱은 DNS 메시지로부터 www.google.com IP 주소를 추출한다.

6.7.4 웹 클라이언트 - 서버 상호작용: TCP와 HTTP

밥의 랩톱은 먼저 목적지 포트 80(HTTP)을 갖는 TCP SYN 세그먼트를 생성하고, TCP 세그먼트를 목적지 주소가 64.233.169.105(www.google.com)인 IP 데이터그램에 넣은 후 MAC 주소가 게이트웨이 라우터인 프레임에 넣어서 이 프레임을 스위치로 전송한다.
학교 네트워크, 컴캐스트 네트워크, 구글 네트워크에 있는 라우터들은 TCP SYN 세그먼트를 포함하는 데이터그램을 14~16단계 처럼 자신의 포워딩 테이블을 사용해서 www.google.com 쪽으로 전달한다.
- 컴캐스트와 구글 네트워크 사이의 도메인 간 링크상으로 패킷을 전달하는 데 사용되는 라우터의 포웓ㅇ 테이블 엔트리는 BGP 프로토콜에 의해 결정된다.
TCP SYN 세그먼트를 포함하고 있는 데이터그램이 www.google.com 에 도착한다. TCP SYN 메시지는 포트 80과 연관된 환영 소켓으로 역다중화 된다. 연결 소켓은 구글 HTTP 서버와 밥 랩톱 사이의 TCP 연결을 위해 생성된다. TCP SYNACK 세그먼트를 생성해서 밥의 랩톱을 목적지로 하는 데이터그램에 넣은 후 www.google.com 을 첫 홉 라우터로 연결해주는 링크에 적합한 링크 계층 프레임에 넣는다.
TCP SYNACK 세그먼트가 포함된 데이터그램은 구글, 컴캐스트, 학교 네트워크를 통해 밥 랩톱의 이더넷 컨트롤러에 도착한다. 이 데이터 그램은 18단계에서 생성된 TCP 소켓으로 역다중화된다.
밥의 브라우저는 가져올 URL이 포함된 HTTP GET 메시지를 생성하고 이를 소켓으로 보내며 이 메시지는 TCP 세그먼트의 페이로드가 된다. 이 TCP 세그먼트를 데이터그램에 넣어 18~20단계에서처럼 www.google.com 로 전달한다.
www.google.com 에 있는 HTTP 서버는 TCP 연결 소켓으로부터 HTTP GET 메시지를 읽고 HTTP 응답 메시지를 생성하고 요청된 웹 페이지의 콘텐츠를 HTTP 응답 메시지 body에 포함시켜서 TCP 소켓으로 보낸다.
HTTP 응답 메시지는 밥의 랩톱에 전달되고, 밥의 웹 브라우저 프로그램은 소켓에서 HTTP 응답 메시지를 읽어서, body로부터 웹페이지에 대한 html을 추출한 후 마침내 웹 페이지를 출력한다.

Chapter 6 - 1. 링크 계층 소개, 2. 오류 검출 및 정정 기술, 3. 다중 접속 링크와 프로토콜

ssun_bear — Tue, 9 Jul 2024 20:40:46 +0900

6.1 링크 계층 소개

노드

링크 계층 프로토콜을 실행하는 장치

e.g. 호스트, 라우터, 스위치, AP(access point, 7장에서 설명) 등

링크

통신 경로상의 인접한 노드들을 연결하는 통신 채널

데이터그램을 출발지 호스트에서 목적지 호스트로 이동시키기 위해서는 데이터그램을 종단 간 경로의 개별 링크들로 이동시켜야만 한다.

한 링크에서 전송 노드는 데이터그램을 링크 계층 프레임(link-layer frame)으로 캡슐화해서 링크로 전송한다.

위 그림에서는 6개의 링크를 거쳐간다.

6.1.1 링크 계층이 제공하는 서비스

프레임화(framing)
- 데이터그램을 링크상으로 전송하기 전에 링크 계층 프레임에 캡슐화한다.
- 프레임은 데이터그램이 들어있는 데이터필드와 여러 개의 헤더 필드로 구성된다.
링크 접속(link access)
- 매체 접속 제어(medium access control, MAC) 프로토콜은 링크상으로 프레임을 전송하는 규칙을 명시한다.
- 단일 송신자와 단일 수신자의 점대점 링크에서의 MAC은 단순하며, 링크가 사용되지 않을 때마다 프레임을 전송할 수 있다.
- 하나의 브로드캐스트 링크를 여러 노드가 공요하는 경우, MAC 프로토콜은 여러 노드로부터의 프레임 전송을 조정한다.
신뢰적 전달
- TCP와 마찬가지로 확인 응답과 재전송을 통해 서비스를 제공한다.
- TCP에서는 종단 간에 데이터를 재선송 하는 것과는 달리 링크 계층 프로토콜은 오류가 발생한 링크에서 오류를 정정한다.
- 무선 링크와 같은 높은 오류율을 가진 링크에서 주로 사용되며, 낮은 비트 오류율을 가진 링크에서는 불필요한 오버헤드가 될 수 있어 대다수 유선 링크 계층 프로토콜은 제공하지 않는다.
오류 검출과 정정
- 신호의 약화나 전자기 잡음 때문에 전송된 프레임 비트를 반대로 오인할 수 있다.
- 오류가 있는 데이터그램은 전달할 필요가 없으므로 대부분의 링크 계층 프로토콜은 오류를 검출하는 방법을 제공한다.
- 송신 노드에서 오류 검출 비트를 설정하게 하고 수신 노드에서 오류 검사를 수행하게 함으로써 가능해진다.
- 트랜스포트 계층과 네트워크 계층의 오류 검출보다 일반적으로 더 복잡하며, 하드웨어로 구현된다.
- 오류 정정은 오류 검출과 비슷하지만 프레임의 어느 곳에서 오류가 발생했는지 정확하게 찾아낼 수 있다.

6.1.2 링크 계층이 구현되는 위치

호스트에서 대부분의 경우 링크 계층은 네트워크 인터페이스 컨트롤러(network interface controller, NIC)로 알려진 네트워크 어댑터(network adapter) 에 구현된다.

(라우터에서는 4장에서 봤듯이 라인 카드에 구현된다.)

컨트롤러(controller)

네트워크 어댑터의 중심에 있다.

링크 계층 서비스의 대다수가 구현되어있는 단일의 특수 용도 칩으로 하드웨어로 구현된다.

송신 측의 컨트롤러는 호스트 메모리에 저장된 데이터그램을 링크 계층 프레임으로 캡슐화한 후 링크 접속 프로토콜에 따라 이 프레임을 통신 링크상으로 전송한다.

수신 측의 컨트롤러는 프레임을 수신한 후 네트워크 계층 데이터그램을 추출한다.

CPU

일부 링크 계층 기능이 호스트 CPU에서 실행되는 소프트웨어에 구현되어 있다.

상위 레벨의 링크 계층 기능은 링크 계층 소프트웨어 구성요소에 구현되어 있다.

e.g. 링크 계층 주소 정보 조립, 컨트롤러 하드웨어 활성화, 컨트롤러로부터의 인터럽트, 오류 처리, 데이터그램 전달 등

즉, 링크 계층은 하드웨어와 소프트웨어의 조합이다.

6.2 오류 검출 및 정정 기술

비트 오류를 방지하기 위해 송신 노드에서 데이터 D에 오류 검출 및 정정 비트들(EDC)를 첨가한다.

송신되는 데이터 D와 EDC는 전송 도중 변경될 수 있다.

즉, 수신자는 변경의 가능성이 있는 비트로 오류 검출 여부를 확인하여야 한다.

오류 검출 및 정정 기술을 사용하더라도 여전히 미검출된 비트 오류(undetected bit error)가 있을 수 있다.

즉, 수신자는 잘못된 데이터그램을 네트워크 계층으로 전달할 수 있고, 프레임 헤더의 다른 필드의 내용이 잘못된 것을 모를 수도 있다.

따라서 오류를 감지하지 못할 확률이 낮은 기법을 선택해야한다. (대체로 확률이 낮을 수록 오버헤드가 크다.)

6.2.1 패리티 검사

단일 패리티 비트

데이터 D가 d개의 비트를 갖고 있다고 가정하자.

짝수 패리티 기법에서는 단순히 D에 한개의 Parity bit를 추가하고, d+1개의 비트에서 1의 총개수가 짝수가 되도록 Parity bit 을 선택한다.

수신자는 수신된 d+1개의 bit에서 1의 개수가 짝수임을 확인한다.

(당연히 홀수라면 1의 개수를 홀수로 정한다.)

이 방법의 경우 홀수개의 비트 오류는 검출할 수 있지만 짝수개의 비트 오류는 검출할 수 없다.

측정에 의하면 오류는 종종 버스트(burst)의 형태로 몰려서 발생하기 때문에 위 방법은 50% 확률로 오류를 검출할 수 있다.

2차원 패리티

데이터 D에 있는 d 비트들은 i개의 행과 j개의 열로 나뉜다.

나뉜 각각의 행과 열에 대해 하나의 패리티 값이 계산된다.

2차원 패리티 기법에서는 반전된 비트를 포함하는 열과 행에 대한 패리티에 오류가 생긴다.

따라서 수신자는 단일 비트의 오류 발생을 검출할 수 뿐만 아니라 열과 행의 인덱스 값을 통해 오류를 정정할 수도 있다.

또, 단일 패리티와는 달리 임의의 2개의 오류도 검출할 수 있다. (그러나 정정할 수 없다.)

순방향 오류 정정(forward error correction, FEC)

오류를 검출 및 정정하는 수신자의 능력을 FEC라고한다.

FEC 기술은 송신자에게 요구하는 재전송 횟수를 줄일 수 있다.

이를 통해 NAK 패킷을 수신하고 재전송된 패킷이 수신자로 되돌아가는 소요 시간이 왕복 지연 시간을 기다릴 필요가 없어진다.

6.2.2 체크섬 방법

d 비트들을 k 비트 정수처럼 다루어 이 k비트 정수들을 더해서 그 결괏값을 오류 검출 비트들로 사용한다.

체크섬 동작 과정

인터넷 체크섬(Internet checksum)

더한 값의 1의 보수가 인터넷 체크섬이 되며, 이것을 세그먼트 헤더에 넣어준다.
수신자는 수신 데이터 합의 1의 보수를 취한 후 그 결과가 모두 1인 비트로 구성되어 있는지 계산함으로써 체크섬을 검사한다.
그 결과가 모두 1인 비트로 구성되어 있는지 계산함으로써 체크섬을 검사한다.

체크섬 방법은 상대적으로 패킷 오버헤드가 적어 TCP와 UDP에서 사용된다. 그러나 순환 중복 검사(CRC)와 비교하면 오류면에서 취약하다.

TCP와 UDP에서 사용하는 이유는 TCP와 UDP는 소프트웨어로 구현되어 간단하고 빠른 오류 검출 기법이 필요한 반면 링크 계층은 네트워크 어댑터 안에 하드웨어로 구현되어 순환 중복 검사(CRC) 를 사용한다.

6.2.3 순환 중복 검사(CRC)

오늘날 컴퓨터 네트워크에서 널리 사용되는 오류 검출 기술은 순환 중복 검사(cyclic redundancy check, CRC) 코드 를 사용한다.

CRC 코드는 전송되는 비트열에 있는 0과 1 값을 계수로 갖는 다항식처럼 비트열을 생각할 수 있고, 또한 비트열에 적용되는 연산을 다항식 연산으로 이해하는 것이 가능하기 때문에 다항식 코드(polynomial code)로도 알려졌다.

CRC 동작 과정

먼저 송신자와 수신자는 G로 표기되는 생성자로 알려진 r+1 비트 패턴에 대해 합의한다. 이때 G의 최상위 비트는 1이어야 한다.
송신자는 D에 r개의 추가 비트 R을 선택해서 D 뒤에 덧붙인다.
- 일반 이진 연산에서 2^k을 곱하는 것은 비트 패턴을 k개의 위치만큼 왼쪽으로 이동하는 것과 같다. 즉, 위 그림의 식을 통해 d+r 패턴을 만들 수 있다.
- 만들어진 d+r 비트 패턴은 모듈로 2 연산을 이용하면 G로 정확히 나누어진다.
수신자는 d+r개의 수신 비트를 G로 나눈다. 만일 나머지가 0이 아니면 오류가 발생한 것이다.

모든 CRC 검사는 덧셈의 올림이나 뺄셈의 빌림이 없는 모듈로 2 연산을 사용한다.

즉, 이는 피연산자를 비트별로 XOR한 것과 같다.

e.g.

1011 XOR 0101 = 1110
1001 XOR 1101 = 0100

1011 - 0101 = 1110
1001 - 1101 = 0100

R을 계산하는 과정

먼저 다음과 같은 식을 만족하는 n이 있도록 하는 R을 구해야한다.

D x 2^r XOR R = nG

즉, D x 2^r XOR R을 나머지 없이 G로 나눌 수 있도록 R을 선택해야 한다. 이 식의 양쪽에 R을 XOR(즉, 올림 없는 모듈로 2 덧셈)하면 다음과 같다.

D x 2^r = nG XOR R

이 식은 D x 2^r 을 G로 나누면 나머지가 정확히 R이 되는 것을 뜻한다.

다시 말해, 다음 처럼 R을 계산할 수 있다.

R = 나머지 D x 2^r / G

e.g.

국제 표준으로는 8비트, 12비트, 16비트, 32비트의 생성자 G가 정의되어 있다.

각각의 CRC 표준은 r개 이하의 연속적인 비트 오류를 모두 검출할 수 있다.

6.3 다중 접속 링크와 프로토콜

두 종류의 네트워크 링크

점대점 링크(point-to-point link)
- 링크의 한쪽 끝에 한 송신자와 링크의 다른 쪽 끝에 한 수신자가 있다.
- PPP(point-to-point protocol)과 HDLC(high-level data link control)이 여기에 속한다. (뒤에 다룬다.)
브로드캐스트 링크(broadcast link)
- 동일한 하나의 공유된 브로드캐스트 채널에 다수의 송신 노드 및 수신 노드가 연결된다.
- 임의의 한 노드가 프레임을 전송하면 채널이 그 프레임을 브로드캐스트해서 다른 모든 노드가 그 프레임의 복사본을 수신하기 때문에 브로드캐스트 용어가 쓰인다.

다양한 다중 접속 채널

다중 접속 문제(multiple access problem)

모든 노드가 프레임을 전송할 수 있으므로 2개 이상의 노드가 브로드캐스트 채널에서 직접 통신할 수 있고, 이런 일이 발생하면 모든 노드는 동시에 여러 개의 프레임을 받게 된다.

즉, 전송된 프레임들이 각 수신자에서 충돌하게 되고 어떤 수신 노드도 전송된 프레임의 의미를 파악할 수 없게 된다.

따라서 충돌에 관련된 모든 프레임은 손실되며, 다수의 노드가 빈번히 프레임을 전송하려 한다면 많이 충돌할 것이고 따라서 브로드캐스트 채널의 대역폭이 많이 낭비된다.

다중 접속 프로토콜(multiple access protocol)

초당 R 비트의 전송률을 갖는 브로드캐스트 채널에 대한 다중 접속 프로토콜은 다음과 같은 특성을 지니는 것이 바람직하다.

단 하나의 노드가 전송할 데이터가 있을 때는 그 노드가 R bps의 처리율을 갖는다.
M개의 노드가 전송할 데이터가 있을 때는 각 노드가 R/M bps의 처리율을 갖는다.
- 항상이 아니며 각 노드가 정의된 시간 동안 R/M의 평균 처리율을 가짐을 의미한다.
분산되어 있어 고장으로 인해 전체 시스템을 정지시킬 수 있는 마스터 노드가 없다.
단순해서 구현하는 데 비용이 적게 든다.

6.3.1 채널 분할 프로토콜

시분할 다중화(time-division multiplexing, TDM)

채널이 N개 노드를 지원하고 채널 전송률이 R bps라고 하자.

TDM은 시간을 시간 프레임(time frame)으로 나누고 또한 각 시간 프레임을 N개의 시간 슬롯(time slot)으로 나눈다.

그 후 N개의 노드에게 시간 슬롯을 각각 할당한다.

노드는 전송할 패킷이 있을 때마다 TDM 프레임에서 자신에게 할당된 시간 슬롯 동안 패킷을 전송한다.

장점

충돌을 제거할 수 있다.
매우 공정하다.

단점

전송할 패킷이 있는 노드가 단 하나인 경우에도 노드 전송률이 R/N으로 제한된다.
노드가 전송 순서상 자신의 차례를 항상 기다려야 한다.

주파수 분할 다중화 (frequency-division multiplexing, FDM)

R bps의 채널을 R/N의 대역폭을 갖는 다른 주파수로 나눠서 각 주파수를 N개의 노드 중 하나에게 할당한다.

즉, 하나의 큰 R bps 채널로부터 N개의 R/N bps의 작은 채널을 만든다.

TDM과 같은 장단점을 갖는다.

코드 분할 다중 접속(code division multiple access, CDMA)

CDMA는 다른 코드를 각 노드에게 할당한다.

노드는 전송하는 데이터 비트들을 자신의 유일한 코드로 인코딩한다.

장점

CDMA 네트워크에서 코드들을 신중하게 선택하면 여러 노드들이 동시에 전송할 수 있다.
다른 노드들에 의해 전송이 간섭되더라도 각 수신자들이 송신자의 인코딩된 데이터 비트를 정확하게 수신할 수 있다.

6.3.2 랜덤 접속 프로토콜

랜덤 접속 프로토콜에서 전송 노드는 항상 채널의 최대 전송률인 R bps로 전송한다.

충돌이 생기면 충돌과 관련된 각 노드는 프레임이 충돌 없이 전송될 때까지 자신의 프레임을 계속해서 재전송한다.

프레임이 충돌했을 때 즉시 재전송하지 않고, 랜덤 지연 시간 동안 기다린 후 재전송 한다.

즉, 출동했던 노드 중 하나는 다른 노드가 선택한 지연 시간보다 충분히 작은 지연시간을 선택함으로써 충돌 없이 자신의 프레임을 채널로 전송할 수 있다.

슬롯 알로하(slotted ALOHA)

동작 과정

전송할 새 프레임이 있으면 다음 슬롯이 시작할 때까지 기다렸다가 그 슬롯에 전체 프레임을 전송한다.
만약, 충돌하지 않으면 노드는 성공적으로 자신의 프레임을 전송한 것이다. 따라서 그 프레임을 재전송할 필요가 없다.
만약 충돌하면, 노드는 그 슬롯이 끝나기 전에 충돌을 검출한다. 노드는 그 프레임이 충돌 없이 전송될 때까지 확률 p(0~1 사이)로 해당 프레임을 다음 슬롯들에서 재전송한다.
충돌하지 않을 때까지 3번 과정을 반복한다.

장점

하나의 활성노드로 하여금 채널의 전속력 R로 계속해서 프레임을 전송할 수 있도록 허용한다.
노드가 충돌을 감지하고 언제 재전송할지 각자 결정하므로 분산되어있다.
매우 단순하다.

단점

노드는 슬롯이 언제 시작하는지 동기화되어있어야 한다.
활성 노드가 많이 있으면 일부 슬롯이 충돌로 인해 결과적으로 낭비 된다.
모든 활성 노드가 확률적인 전송 정책 때문에 전송을 억제하는 경우 일부 슬롯이 비게 된다.

낭비되지 않는 슬롯은 정확히 한 노드만 전송하는 슬롯이고, 이 노드를 성공한 슬롯(successful slot)이라 한다.

효율성

노드가 N개가 있을 때 하나의 슬롯이 성공적인 슬롯일 확률은 노드들 중 한 노드만 전송하고 나머지 N-1 개의 노드는 전송하지 않는 확률이다.

노드가 전송할 확률이 p라하면 해당 노드가 성공할 확률은 p x (1-p)^(N-1) 이다.

노드가 N개 있으므로 임의의 한 노드가 성공할 확률은 N x p x (1-p)^(N-1) 이다.

최대의 효율을 구하기 위해서는 이 식을 최대화 하는 p를 구해야 한다.

활성 노드가 많은 경우의 최대 효율을 구하기 위해 N이 무한대가 될 때의 극한값을 취한다.

이렇게 계산하면 최대 효율은 p = 1/e = 0.37 임을 알 수있다.

즉, 많은 노드가 전송할 프레임이 많을 때 기껏해야 37%의 슬롯만 낭비되지 않는다.

알로하(ALOHA)

순수 알로하 프로토콜에서는 슬롯 개념이 없다.

동작 과정

프레임이 도착하면 노드는 즉시 프레임 전체를 브로드캐스트 채널로 전송한다.
만약 충돌하면, 노드는 확률 p로 즉시 재전송 한다.
즉시 재전송하지 않는 경우, 노드는 프레임 전송 시간 동안 기다린다.
기다리고 나서 확률 p로 전송하거나 아니면 1-p 확률로 또 다른 프레임 시간 동안 기다린다.

효율성

임의의 시점에 노드가 프레임을 전송할 확률은 p다.

시간 t0에 프레임 전송을 시작한다고 가정하자.

이 프레임이 성공적으로 전송되기 위해서는 [t0-1,t0] 동안 다른 노드들이 전송을 해서는 안된다. 만일 전송을 하게 되면 노드 i가 전송 시작 부분과 겹쳐 충돌하게 된다.

이 시간동안 다른 모든 노드가 전송을 시작하지 않을 확률은 (1-p)^(N-1) 이다.

마찬 가지로 노드 i가 전송하는 동안에 다른 노드가 전송을 시작해서는 안되고, 이 확률 또한, (1-p)^(N-1) 이다.

즉, 성공적으로 전송할 확률은 i가 전송 할 확률 p 를 포함해서 p x (1-p)^(2(N-1)) 이다. 슬롯 알로하처럼 극한값을 취하면 최대 효율은 p = 1/2e 로 슬롯 알로하의 절반이다.

즉, 순수 알로하는 완전히 분산되어 동기화하는 것을 안하는 대신, 효율성을 포기한다.

CSMA

위 두 프로토콜에서는 다른 노드가 전송하고 있건 말건 일단 보낸다.

즉, 충돌이 생기고 결과적으로 효율이 떨어진다.

이러한 충돌을 없애기 위한 규칙을 보자.

캐리어 감지(carrier sensing)
- 만일 다른 노드가 프레임을 채널로 전송하고 있는 경우, 노드는 임의의 짧은 시간 동안 전송 중단을 감지하면 프레임을 전송하기 시작한다.
충돌 검출(collision detection)
- 만일 다른 노드가 방해 프레임을 전송하고 있음을 검출하면, 자신의 전송을 중단하고 랜덤 시간 동안 기다린 후 유휴 시 감지 및 전송과정을 반복한다.

CSMA에서 충돌이 발생하는 경우

시각 t0에 노드 B가 다른 노드가 아무도 전송하고 있지 않으므로 채널이 비어 있는 것으로 감지한다.
B는 전송을 시작하고, 전송한 비트들이 브로드캐스트 매체를 따라 양방향으로 전송된다.
- 시간이 경과함에 따라 아래쪽으로 전파되는 것은 B의 비트들이 실제로 브로드캐스트 매체로 전파할 때 0보다 큰 시간이 필요하다는 것을 의미한다.
D가 t1 시점에 전송할 프레임이 생겼고, 노드 B가 t1에 전송을 하고 있음에도 불구하고, B에 의해 전송되는 비트들은 D에 도달하지 못했고, 따라서 D는 t1일 때 채널이 사용되지 않는 것으로 감지한다.
D가 전송을 시작하고, 약간의 시간 후에 B가 전송한 비트와 D의 전송한 비트가 간섭을 일으키기 시작한다.

즉, 브로드캐스트 채널 종단 간의 채널 전파 지연(channel propagation delay)이 길수록 다른 노드에서 이미 시작된 전송을 캐리어 감지 노드가 감지할 수 없는 경우가 증가하기 때문에 채널 종단 간의 채널 전파 지연(channel propagation delay) 는 CSMA의 성능을 결정하는데 중요한 역할을 한다.

CSMA/CD

CSMA는 충돌 검출을 수행하지 않는 반면, CSMA/CD는 충돌 검출을 수행한 후 즉시 전송을 취소한다.

동작 과정

어댑터는 네트워크 계층으로부터 데이터그램을 받아서 링크 계층 프레임을 만든 후에 그 프레임을 어댑터 버퍼에 저장한다.
어댑터는 채널이 유휴(idle) 상태임을 감지하면 프레임 전송을 시작한다.
- 만일 어댑터가 채널이 바쁜(busy) 상태임을 감지하면, 어떤 신호 에너지도 감지되지 않을 때까지 더 기다렸다가 프레임을 전송하기 시작한다.
전송하는 동안 어댑터는 브로드캐스트 채널을 사용하는 다른 어댑터로부터의 신호 에너지가 있는지 감시한다.
프레임 전체를 전송하는 동안 다른 어댑터로부터의 신호 에너지가 감지되지 않으면, 프레임 전송을 완료한다.
- 감지되면 자신의 프레임 전송을 취소한다.
전송 취소 후 임의의 랜덤 시간만큼 기다린 후 2단계로 돌아간다.
- 만일 랜덤 시간이 아니라 고정 시간이라면 동시에 프레임을 전송했을 때 똑같은 시간을 기다린 후 전송을 하므로 계속해서 충돌하게 된다.

랜덤 시간을 결정하는 알고리즘: 이진 지수적 백오프(binary exponential backoff)

충돌을 n번 경험한 프레임을 전송할 때 노드는 {0,1,2,…,2^n - 1} 중에서 랜덤하게 K 값을 선택한 후 K x 비트 시간 만큼 기다린다.

이더넷의 경우 K x 512 비트 시간(이더넷으로 512 비트를 전송하는데 걸리는 시간 x K)가 되며 n의 최댓값을 10으로 제한한다.

즉, 충돌을 많이 경험할수록 K의 범위가 지수적으로 커지게 된다.

새 프레임을 준비할 때는 최근 발생한 충돌을 고려하지 않고 CSMA/CD를 수행하여 충돌을 경험한 노드보다 먼저 전송될 수도 있다.

효율성

d(prop) = 신호 에너지가 임의의 두 어댑터 사이에서 전파되는 데 걸리는 최대 시간
d(trans) = 최대 크기의 이더넷 프레임을 전송하는데 걸리는 시간

효율 = 1/(1+5d(prop)/d(trans))

전파 지연이 0이 되면 충돌한 노드는 채널을 장비하지 않고 즉시 취소하기 때문에 d(prop)이 0이되면 효율은 1에 근접한다.

d(trans)가 아주 크면 프레임이 채널을 한번 차지하면 아주 오랫동안 채널을 사용하기 때문에 효율은 1에 근접한다.

따라서 채널은 거의 모든 시간 동안 유용하게 쓰인다.

6.3.3 순번 프로토콜

다중 접속 프로토콜에서 요구되는 두가지 특성은 다음과 같다.

단 하나의 노드만이 활성이면 Rbps의 처리율을 갖는다.
M개의 노드가 활성이면 각 노드가 거의 R/M bps의 처리율을 갖는다.

알로하와 CSMA 프로토콜은 첫번째 특성은 지니고 있으나 두 번째 특성은 없다.

이것이 순번 프로토콜(taking-turns protocol) 을 개발하게된 동기다.

폴링 프로토콜(polling protocol)

노드 중 하나를 마스터 노드로 지정한다.

마스터 노드는 각 노드를 라운드 로빈 방식으로 폴링한다.

특히, 마스터 노드는 먼저 노드 1에게 노드 1이 최대로 보낼 수 있는 프레임 수에 대한 메시지를 전송하고, 노드 1이 프레임을 전부 보낸 다음 다음 노드도 똑같이 수행하여 순환적으로 각 노드를 폴링하는 방식으로 이 과정을 계속한다.

장점

빈슬롯을 제거할 수 있다.

단점

폴링 지연이 있다.
- 한 노드만 활성이면 활성 노드가 프레임을 최대 개수만큼 보낼 때마다 마스터 노드는 비활성 노드들을 차례로 폴링해야만한다.
마스터 노드가 고장나면 전체 채널이 동작하지 못한다.

토큰 전달 프로토콜(token-passing protocol)

토큰(token) 이라고 알려진 작은 특수 목적 프레임이 정해진 순서대로 노드 간에 전달된다.

예를 들어, 노드 1은 항상 노드 2에 노드 2는 노드 3에 노드 N은 노드 1에 토큰을 전송한다.

노드가 토큰을 수신하면, 전송할 프레임이 있을 때만 토큰을 붙잡고, 그렇지 않으면 토큰을 전달한다.

프레임을 최대 개수까지 전송한 뒤 토큰을 다음 노드로 전달한다.

장점

분산 방식으로 효율이 매우 높다

단점

노드 하나가 실패하면 채널이 동작하지 않는다.
노드가 토큰을 놓아주지 않으면, 토큰이 다시 돌 수 있도록 하는 회복 절차가 수행되어야 한다.

6.3.4 DOCSIS: 케이블 인터넷 접속을 위한 링크 계층 프로토콜

DOCSIS(Data-over-Cable Service Interface Specificaitions)는 케이블 데이터 네트워크의 구조와 프로토콜들을 정의한다.

DOCSIS는 하향 및 상향 네트워크 세그먼트들을 다수의 주파수 채널로 나누기 위해 FDM을 사용한다.

각 상향 및 하향 채널은 브로드캐스트 채널이다.

하향 채널

각 하향 채널은 24~192 MHz 대역에 약 1.6 Gbps의 최대 처리율을 제공한다.

CMTS에 의해 하향 채널로 전송된 프레임은 그 채널을 통해 수신하는 모든 케이블 모뎀에 의해 수신된다. (하향 채널로 전송하는 CMTS가 하나이기 때문에 다중 접속 문제는 발생하지 않는다.)

CMTS는 하향 채널상으로 MAP 메시지로 알려진 제어 메시지를 보냄으로써 어떤 케이블 모뎀이 MAP 메시지에서 명시한 시간 간격 동안 어떤 미니슬롯(mini slot)으로 전송할 수 있는지 알려준다.

상향 채널

상향 채널은 6.4~96 MHz 대역에 약 1 Gps의 최대 상향 처리율을 제공한다.

다수의 케이블 모뎀이 CMTS로의 동일한 상향 채널(주파수)을 공유하여 충돌이 발생할 수 있다.

상향 채널은 TDM처럼 시간 간격으로 나뉘어 있고, 각 시간 간격은 케이블 모뎀이 CMTS로 전송할 수 있는 일련의 미니슬롯(mini slot)들로 구성되어 있다.

미니슬롯(mini slot) 이 케이블 모뎀마다 명시적으로 할당되어 있기 때문에 CMTS는 미니슬롯(mini slot) 동안은 충돌이 발생하지 않는 것을 확신할 수 있다.

미니슬롯(mini slot)에는 미니슬롯 요청(mini-slot-request) 프레임을 CMTS에게 전송하기 위한 특정 미니슬롯(mini slot) 들이 있다.

각 케이블 모뎀은 미니슬롯 요청(mini-slot-request) 프레임 을 CMTS에게 전송하여 어떤 케이블 모뎀이 전송할 데이터가 있는지 알 수 있다.

미니슬롯 요청(mini-slot-request) 프레임 은 랜덤 접속 방식으로 전송되기 때문에 충돌이 발생할 수 있다.

케이블 모뎀은 충돌 검출을 수행하지 않고, 요청된 할당에 대한 응답을 다음 하향 제어 메시지에서 수신하지 못한다면 미니슬롯 요청 프레임이 충돌됐다고 추청한다.

이렇게 추정한 케이블 모뎀은 재전송을 지연시키기 위해 이진 지수적 백오프를 사용한다.

Chapter 5 - 5. 소프트웨어 정의 네트워크(SDN) 제어 평면, 6. 인터넷 제어 메시지 프로토콜(ICMP), 7. 네트워크 관리와 SNMP, NETCOMF/YANG

ssun_bear — Tue, 9 Jul 2024 20:37:10 +0900

5.5 소프트웨어 정의 네트워크(SDN) 제어 평면

이 절에서는 4.4절에서 사용한 SDN 용어들을 다시 채택하여
네트워크의 포워딩 장비들은 ‘패킷 스위치’ 또는 그냥 ‘스위치’라고 부를 것이다.

이 스위치들에서의 포워딩 결정은 네트워크 계층에서의 출발지/목적지 주소, 링크 계층에서의 출발지/목적지 주소 외에도
트랜스포트 계층, 네트워크 계층, 링크 계층 패킷 헤더의 다른 많은 값에 기반하여 이루어진다.

SDN 구조의 특징

플로우 기반 포워딩

SDN으로 제어되는 스위치들에서의 패킷 전달은 트랜스포트 계층, 네트워크 계층, 또는 링크 계층 헤더의 어떤 값을 기반으로 하든 이루어질 수 있다.

이는 앞 절에서 살펴본,
IP 데이터그램의 포워딩이 온전히 데이터그램의 목적지 주소를 기반으로 이루어지는 전통적인 라우터 기반 포워딩과는 매우 대조적인 특성이다.

SDN에서는 모든 네트워크 스위치의 플로우 테이블 항목들을 계산하고 관리, 설치하는 일이 모두 SDN 제어 평면의 임무다.

데이터 평면과 제어 평면의 분리

데이터 평면

네트워크의 스위치들로 구성된다. (이들은 상대적으로 단순하지만 빠른 장치들)
자신들의 플로우 테이블 내용을 기반으로 ‘매치 플러스 액션’을 수행한다.

제어 평면

서버와 스위치들의 플로우 테이블을 결정, 관리하는 소프트웨어로 이루어진다.

네트워크 제어 기능이 데이터 평면 스위치 외부에 존재

SDN 제어 평면은 소프트웨어로 구현되어 있으며, 네트워크 스위치로부터 멀리 떨어진 별도의 서버에서 수행된다.

아래의 그림에서 볼 수 있듯, 제어 평면은 2개의 구성요소로 이루어진다.

SDN 컨트롤러(또는 네트워크 운영체제)
SDN 네트워크 제어 애플리케이션들의 집합

SDN 컨트롤러는

정확한 상태정보(e.g., 원격 링크와 스위치, 호스트들의 상태)를 유지하고,
이 정보를 네트워크 제어 애플리케이션들에 제공하며,
애플리케이션들이 하부 네트워크 장치들을 모니터하고 프로그램하고 제어까지 할 수 있도록 수단을 제공한다.

그림에서의 컨트롤러는 단일 중앙 서버의 형태이지만, 실제로 컨트롤러는 논리적으로만 중앙 집중 형태다.

(일반적으로는 협업 능력과 확장성, 높은 이용성을 갖도록 몇 개의 서버에 구현)

프로그램이 가능한 네트워크

제어 평면에서 수행 중인 네트워크 제어 애플리케이션을 통해 네트워크를 프로그램할 수 있다.

이 애플리케이션들은 SDN 컨트롤러가 제공하는 API를 이용하여 네트워크 장치들에 있는 데이터 평면을 명세하고 제어한다.

e.g.,
라우팅 네트워크 제어 애플리케이션은 SDN 컨트롤러가 갖고 있는 노드 상태 및 링크 상태 정보에 기반한 다익스트라 알고리즘을 수행하여
출발지와 목적지 사이의 종단 간 경로를 결정한다.

5.5.1 SDN 제어 평면

: SDN 컨트롤러와 SDN 네트워크 제어 애플리케이션

SDN 컨트롤러

컨트롤러의 기능은 크게 3개의 계층으로 구성된다.

네트워크 제어 애플리케이션 계층과의 인터페이스
네트워크 전역 상태 관리 계층
통신 계층

통신 계층: SDN 컨트롤러와 제어받는 네트워크 장치들 사이의 통신

제어받는 장치들과의 통신

SDN 컨트롤러가 원격의 SDN 기능이 가능한 장치들의 동작을 제어하려면 컨트롤러와 그 장치들 사이에 정보를 전달하는 프로토콜이 필요하다.
장치는 주변에서 관찰한 이벤트를 컨트롤러에 알려, 네트워크 상태에 대한 최신의 정보를 제공해야 한다.

컨트롤러와 제어받는 장치들 간의 통신은 ‘사우스바운드(southbound)’라고 알려진 컨트롤러 인터페이스를 넘나든다.

이 통신 기능을 제공하는 구체적 프로토콜은 OpenFlow이며, 이는 모두는 아니지만 대부분의 SDN 컨트롤러에 구현되어 있다.

네트워크 전역 상태 관리 계층

네트워크 전역에 분산되고 견고한 상태 관리

SDN 제어 평면의 궁극적인 제어 결정을 위해서는
컨트롤러가 네트워크 호스트와 링크, 스위치, 그리고 SDN으로 제어되는 다른 장치들에 대한 최신 정보를 알아야 한다.

제어 평면의 궁극적인 목적은 다양한 제어 장치들의 플로우 테이블을 결정하는 것이므로 컨트롤러도 이 테이블들의 복사본을 유지해야 할 것이다.

스위치의 플로우 테이블이 가지는 카운터들과 같은 이러한 정보 조각들은 모두 SDN 컨트롤러가 유지하는 네트워크 전역 ‘상태’의 예들이다.

네트워크 제어 애플리케이션 계층과의 인터페이스

네트워크 제어 애플리케이션들을 위한 인터페이스와 추상화

컨트롤러는 ‘노스바운드(northbound)’ 인터페이스를 통해 네트워크 제어 애플리케이션과 상호작용한다.

이 API는 네트워크 제어 애플리케이션이 상태 관리 계층 내의 네트워크 상태 정보와 플로우 테이블을 읽고 쓸 수 있도록 해준다.

SDN 컨트롤러는 외부에서 볼 때 ‘논리적으로 중앙 집중된’, 잘 짜여진 하나의 서비스로 보일 수 있지만,

이 서비스들과 상태 정보를 보관하기 위한 데이터베이스는
장애 허용성(fault tolerance)과 높은 가용성, 또는 다른 성능상의 이유로 실제로는 분산된 서버의 집합에 구현된다.

근래의 컨트롤러는 논리적으로는 중앙 집중 형태이나 물리적으로는 분리된 컨트롤러 플랫폼 구조이다.

이런 구조는 제어되는 장치와 네트워크 제어 애플리케이션에게 늘어나는 장치 수에 따라 확장 가능한 서비스와 높은 가용성을 제공한다.

5.5.2 OpenFlow 프로토콜

OpenFlow 프로토콜은 SDN 컨트롤러와 SDN으로 제어되는 스위치 또는 OpenFlow API를 구현하는 다른 장치와의 사이에서 동작한다.
OpenFlow 프로토콜은 TCP상에서 디폴트 포트 번호 6653을 가지고 동작한다.

컨트롤러가 제어되는 스위치로 전달하는 중요한 메시지는 다음과 같다.

설정 : 이 메시지는 컨트롤러가 스위치의 설정 파라미터들을 문의하거나 설정할 수 있도록 한다.
상태 수정 : 이 메시지는 컨트롤러가 스위치 플로우 테이블의 엔트리를 추가/제거 또는 수정하거나 스위치 포트의 특성을 설정하기 위해 사용한다.
상태 읽기 : 이 메시지는 컨트롤러가 스위치 플로우 테이블과 포트로부터 통계 정보와 카운터값을 얻기 위해 사용한다.
패킷 전송 : 이 메시지는 컨트롤러가 제어하는 스위치의 지정된 포트에서 특정 패킷을 내보내기 위해 사용한다.
이 메시지 자체는 페이로드 부분에 보낼 패킷을 포함한다.

SDN으로 제어되는 스위치에서 컨트롤러로 전달되는 주요 메시지는 다음과 같다.

플로우 제거 : 이 메시지는 컨트롤러에게 어떤 플로우 테이블 엔트리가 시간이 만료되었거나 상태 수정 메시지를 수신한 결과로 삭제되었음을 알린다.
포트 상태 : 이 메시지는 스위치가 컨트롤러에게 포트의 상태 변화를 알리기 위해 사용된다.
패킷 전달
- 4.4절에서 스위치 포트에 도착한 패킷 중에서 플로우 테이블의 어떤 엔트리와도 일치하지 않는 패킷은 처리를 위해 컨트롤러에게 전달된다고 했다.
- 어떤 엔트리와 일치한 패킷 중에서도 일부는 그에 대한 작업을 수행하기 위해 컨트롤러에게 보내지기도 한다.
  이 메시지는 그러한 패킷을 컨트롤러에게 보내기 위해 사용한다.

5.5.3 데이터 평면과 제어 평면의 상호작용: 예제

아래 그림은 SDN의 제어를 받는 스위치와 SDN 컨트롤러 간의 상호작용에 대한 것이다.

여기서는 다익스트라 알고리즘이 최단 경로를 결정하기 위해 사용되는데,
다익스트라 알고리즘은 패킷 스위치 외부에서 별도의 애플리케이션으로 수행된다.
패킷 스위치들이 링크 갱신 정보를 서로 간이 아닌 SDN 컨트롤러에게 전송한다.

최단 경로 알고리즘이 사용되고 있다.
스위치 s1과 s2 사이의 링크가 단절되었다고 가정해보자.
- 따라서 s1, s3, s4로 들어오고 나가는 플로우 포워딩 규칙은 변경되었으나, s2의 동작은 바뀌지 않았다고 가정한다.
통신 계층 프로토콜로는 OpenFlow가 사용된다.
제어 평면은 링크 상태 라우팅 외의 기능은 수행하지 않는다.

스위치 s2와의 링크 단절을 감지한 s1은 OpenFlow의 포트 상태 메시지를 사용하여 링크 상태의 변화를 SDN 컨트롤러에게 알린다.
링크 상태 변화를 알리는 OpenFlow 메시지를 받은 SDN 컨트롤러는 링크 상태 관리자에게 알리고,
링크 상태 관리자는 링크 상태 데이터베이스를 갱신한다.
다익스트라 링크 상태 라우팅을 담당하는 네트워크 제어 애플리케이션은 링크 상태의 변화가 있을 경우 알려달라고 이전에 등록해두었다.
이 애플리케이션이 링크 상태의 변화에 대한 알림을 받게 된다.
링크 상태 라우팅 애플리케이션이 링크 상태 관리자에게 요청하여 갱신된 링크 상태를 가져온다.
- 이 작업은 상태 관리 계층에 있는 다른 구성 요소의 도움이 필요할 수도 있다.
- 그 후 새로운 최소 비용 경로를 계산한다.
링크 상태 라우팅 애플리케이션은 갱신되어야 할 플로우 테이블을 결정하는 플로우 테이블 관리자와 접촉한다.
플로우 테이블 관리자는 OpenFlow 프로토콜을 사용하여 링크 상태 변화에 영향을 받는 스위치들의 플로우 테이블을 갱신한다.
- 이 예에서는 s1, s2, s4가 이에 해당한다.
- s1 : 이제부터 s2를 목적지로 하는 패킷을 s4로 보낸다.
- s2 : 이제부터 s1로부터의 패킷을 중간 스위치 s4를 통해 받는다.
- s4 : s1에서 s2로 가는 패킷을 전달해야 한다.

컨트롤러가 플로우 테이블을 마음대로 변경할 수 있기 때문에
단순히 애플리케이션 제어 소프트웨어를 바꿈으로써 원하는 어떤 형태의 포워딩 방식도 구현할 수 있다.

5.5.4 SDN: 과거와 미래

과거

SDN이 많은 관심을 받게 된 것은 비교적 최근의 현상이지만,
SDN의 기술적인 뿌리, 특히 데이터와 제어 평면의 분리를 상당히 거슬러 올라간다.

2004년에 [Feamster 2004, Lakshman 2004, RFC 3746]은 모두 네트워크 데이터와 제어 평면의 분리를 주장했다.
에탄(Ethane) 프로젝트[Casado 2007]는
(1) ‘매치 플러스 액션’ 플로우 테이블이 있는 간단한 플로우 기반 이더넷 스위치,
(2) 플로우 수용 및 라우팅을 관리하는 중앙 집중식 컨트롤러,
(3) 그리고 플로우 테이블의 어떤 엔트리와도 일치하지 않는 패킷을 스위치에서 컨트롤러로 전달하는 개념을 개척했다.
- 300개 이상의 에탄 스위치로 구성된 네트워크가 2007년에 운영되었다.
- 에탄은 OpenFlow 프로젝트로 빠르게 진화했다.

미래

SDN 혁명은 ‘단순한 상용 스위칭 하드웨어와 정교한 소프트웨어 제어 평면’으로
’모든 기능이 하나로 통합된 스위치와 라우터(데이터 및 제어 평면 모두)’를 교체해나가고 있다.

네트워크 기능 가상화(network functions virtualization, NFV)로 알려진 SDN의 일반화는 단순한 상용 서버, 스위칭 및 저장소를 가지고
복잡한 미들박스(전용 하드웨어 및 미디어 캐싱/서비스를 위한 고유의 소프트웨어를 가진 미들박스)를 혁신적으로 교체하는 것을 목표로 한다.

연구의 중요한 두 번째 영역은 SDN 개념을 AS 내부 설정에서 AS 간 설정으로 확장하려는 것이다.

SDN 컨트롤러 사례연구: OpenDaylight와 ONOS 컨트롤러

일부 SDN 컨트롤러는 특정 회사를 위한 고유 제품이다.

그러나 더 많은 컨트롤러는 오픈소스이며 다양한 프로그래밍 언어로 구현된다.

가장 최근에는 OpenDaylight 컨트롤러와 ONOS 컨트롤러가 산업계에서 상당한 지지를 얻었다.

이 둘은 모두 오픈소스이며, 리눅스 재단(Linux Foundation)과 공동으로 개발 중이다.

OpenDaylight 컨트롤러

아래 그림은 ODL(OpenDaylight) 컨트롤러 플랫폼[OpenDaylight 2020, Eckel 2017]의 간략한 구조다.

ODL의 기본 네트워크 서비스 기능들은 컨트롤러의 핵심부에 있다.
서비스 추상 계층(Service Abstraction Layer, SAL)
- 컨트롤러 구성요소와 애플리케이션이 서로의 서비스를 호출하고 그들이 생성한 이벤트에 대한 알림을 받을 수 있도록 한다.
- OpenFlow와 SNMP(Simple Network Management Protocol) 및 NETCONF(Network Configuration) 같은,
  ODL 컨트롤러와 제어 장치 간 프로토콜들에게 균일한 추상 인터페이스를 제공한다.
OVSDB(Open vSwitch Database Management Protocol)는 데이터 센터 스위칭을 관리하는 데 사용된다.
(데이터 센터 네트워킹에 대해서는 6장에서 다룸)

가장 상단의 네트워즈 조정 및 애플리케이션부는
데이터 평면의 포워딩과 방화벽 및 로드 밸런싱 같은 서비스들이 제어 장치에서 어떻게 수행될지를 결정한다.

ONOS 컨트롤러

아래 그림은 ONOS 컨트롤러[ONOS 2020]를 간략화한 모습이다.

표준 컨트롤러와 유사하게 3개의 계층을 구분할 수 있다.

노스바운드 추상화 프로토콜
- ONOS는 의도(intent) 프레임워크이다.
  - 이는 애플리케이션이 해당 서비스가 구체적으로 어떻게 구현되는지 몰라도
    높은 수준의 서비스(e.g., 어떤 호스트 A와 B 사이의 연결을 설정)를 요청할 수 있게 해준다.
- 상태 정보가 노스바운드 API를 통과하여
  네트워크 제어 애플리케이션에게 동기적(직접 질의를 통해) 또는 비동기적(e.g,. 네트워크 상태가 변화했을 때 알림 기능)으로 제공된다.
분산 코어
- 네트워크 링크, 호스트, 장치의 상태는 ONOS의 분산 코어에 유지된다.
- ONOS 코어는 서비스 복제와 인스턴스 간 협력 메커니즘을 제공함으로써
  상부의 애플리케이션과 하부의 네트워크 장치에게 논리적 중앙 집중형 코어 서비스의 추상화를 제공한다.
사우스바운드 추상화와 프로토콜
- 사우스바운드 추상화는 하부의 호스트, 링크, 스위치, 프로토콜의 이질성을 숨겨준다.
- 따라서 분산 코어가 장치나 프로토콜 종류에 상관없이 동작할 수 있다.
- 이 추상화 때문에 분산 코어 아래의 사우스 바운드 인터페이스는 표준 컨트롤러나 ODL 컨트롤러보다 논리적으로 높다.

5.6 인터넷 제어 메시지 프로토콜(ICMP)

인터넷 제어 메시지 프로토콜(Internet Control Message Protocol, ICMP)은 호스트와 라우터가 서로 간에 네트워크 계층 정보를 주고받기 위해 사용된다.

ICMP는 종종 IP의 한 부분으로 간주되지만, ICMP 메시지가 IP 데이터그램에 담겨 전송되므로 구조적으로는 IP 바로 위에 있다.

즉, ICMP 메시지도 IP 페이로드로 전송되며,
호스트가 상위 계층 프로토콜이 ICMP라고 표시된(상위 계층 프로토콜 번호가 1번인) IP 데이터그램을 받으면 ICMP로 내용을 역다중화한다.

ICMP 메시지는 타입(type)과 코드(code) 필드가 있고,
ICMP 메시지의 발생 원인이 된 IP 데이터그램의 헤더와 첫 8바이트를 갖는다.

이는 송신자가 오류를 발생시킨 패킷을 알 수 있도록 하기 위해서이다.

중요한 ICMP 메시지 타입들은 다음과 같다

ICMP 메시지는 오류 상태를 알리기 위해서만 사용되는 것이 아니다.

ping 프로그램

타입 8, 코드 0인 ICMP 메시지를 특정 호스트에 보낸다.
목적지 호스트는 에코 요청을 보고 나서 타입 0, 코드 0인 ICMP 에코 응답을 보낸다.

대부분의 TCP/IP 구현은 ping 서버를 운영체제에서 직접 지원한다.
(즉, ping 서버는 별도의 프로세스가 아님)

출발지 억제 메시지

이 메시지의 원래 목적은 혼잡 제어를 수행하기 위한 것이다.

즉, 혼잡이 발생한 라우터가 호스트의 전송 속도를 늦추도록 ICMP 출발지 억제 메시지를 해당 호스트에 보낸다.

하지만 우리는 앞서 TCP가 ICMP 출발지 억제 메시지와 같은 네트워크 계층의 피드백 없이도
전달 계층에서 동작하는 자신만의 혼잡 제어 메커니즘을 갖고 있음을 보았고, 이에 이 메시지는 실제로는 잘 사용되지 않는다.

Traceroute 프로그램

아래의 방식으로 출발지 호스트는 자신과 목적지 호스트 사이에 있는 라우터들의 수와 정체, 그리고 두 호스트 간의 왕복 시간을 알게 된다.

출발지와 목적지 사이의 라우터 이름과 주소를 알아내기 위해
출발지의 Traceroute는 일련의 IP 데이터그램을 목적지에 보낸다.
- 각각의 데이터그램은 UDP 포트 번호를 가진 UDP 세그먼트를 운반한다.
- TTL 값은 첫 번째 데이터그램이 1, 두 번째는 2, 세 번째는 3, 이런 식이다.
출발지는 각 데이터그램에 대해 타이머를 작동시킨다.
- n번째 데이터그램이 n번째 라우터에 도착하면 해당 라우터는 데이터그램의 TTL이 방금 만료되었음을 알게 된다.
IP 프로토콜 규칙에 따라 라우터는 데이터그램을 폐기하고 ICMP 경고 메시지(타입 11, 코드 0)를 출발지에 보낸다.
- 이 경고 메시지는 라우터의 이름과 IP 주소를 포함한다.
이 ICMP 메시지가 출발지에 도착하면, 출발지는
(1) 타이머로부터 왕복 시간(round-trip time, RTT),
(2) ICMP 메시지로부터 n번째 라우터의 주소와 이름을 획득한다.

Traceroute 출발지는 UDP 세그먼트 전송을 언제 멈춰야 하는지 어떻게 알까?

출발지가 자신이 보내는 각 데이터그램마다 차례로 TTL을 1씩 증가시키기 때문에
이들 데이터그램 중 하나는 결국 목적지 호스트에 도착하게 될 것이다.
이 데이터그램은 없을 것 같은 UDP 포트 번호를 가진 UDP 세그먼트를 포함하고 있으므로,
목적지 호스트는 포트 도달 불가능 ICMP 메시지(타입 3, 코드 3)를 출발지에 보낸다.
출발지 호스트가 이 ICMP 메시지를 받게 되면 추가적인 탐색 패킷을 보낼 필요가 없음을 알게 된다.

5.7 네트워크 관리와 SNMP, NETCONF/YANG

네트워크 관리란 무엇인가?

[Saydam 1996]에는 이에 대해 잘 정리된, 한 문장으로 된 정의가 나온다.

네트워크 관리는 적정한 비용으로 실시간, 운용 성능, 서비스 품질 등의 요구사항을 만족시키기 위해
네트워크와 구성요소 자원을 감시, 테스트, 폴링, 설정, 분석, 평가, 제어하는
하드웨어, 소프트웨어, 인간 요소 등을 배치하고, 통합, 조정하는 것이다.

이 절에서는 이 광범위한 정의 중에서 네트워크 관리의 기초,
즉 네트워크 관리자가 자신의 일을 수행하는 데 사용하는 구조, 프로토콜, 데이터만을 다룬다.

5.7.1 네트워크 관리 프레임워크

아래 그림은 네트워크 관리의 핵심 요소들을 나타낸다.

관리 서버(managing server)

관리 서버는
네트워크 운영 센터(network operations center, NOC)의 중앙 집중형 네트워크 관리 스테이션에서 동작하는,
일반적으로 네트워크 관리자(network managers, 사람)와 상호작용하는 애플리케이션이다.

네트워크 관리 활동이 일어나는 장소로서 네트워크 관리 정보의 수집, 처리, 분석, 발송을 제어한다.
여기서 네트워크의 피관리 장치를 설정, 감시, 제어하기 위한 작업이 시작된다.
하나의 네트워크는 여러 개의 관리 서버를 가질 수 있다.

피관리 장치(managed devicE)

피관리 장치는 관리 대상 네트워크에 존재하는 네트워크 장비(소프트웨어 포함)들이다.

e.g., 호스트, 라우터, 스위치, 미들박스, 모뎀, 온도계, 그 외 네트워크에 연결된 그 밖에 장치들
이 장치들은 많은 관리 가능한 요소들(e.g,. 네트워크 인터페이스 카드는 호스트나 라우터의 구성요소)과
이러한 하드웨어 및 소프트웨어 요소에 대한 설정 매개변수들(e.g., OSPF와 같은 AS 내부 라우팅 프로토콜)을 갖는다.

데이터(data)

각 피관리 장치는 ‘상태(state)’라고 부르는, 장치와 관련된 데이터를 갖는다.

데이터의 유형들

설정 데이터(configuration data)
- 장치 인터페이스에 관리자가 할당 및 설정한 장치 정보
- e.g., IP 주소 또는 인터페이스 속도
동작 데이터(operational data)
- 장치가 동작하면서 획득하는 정보
- e.g., OSPF 프로토콜의 인접 항목 목록
장치 통계(device statistics)
- 장치가 운영되면서 갱신되는 상태 표시기 및 계수기
- e.g., 인터페이스에서 삭제된 패킷 수 또는 장치의 냉각 팬 속도

관리 서버는 네트워크 토폴로지 같은 전체 네트워크와 관련된 데이터뿐만 아니라
관리 대상 장치들의 구성과 운영, 그리고 통계 데이터의 복사본도 유지 관리한다.

네트워크 관리 에이전트(network management agent)

네트워크 관리 에이전트는 관리 서버와 통신하는 피관리 장치상의 소프트웨어 프로세스다.

관리 서버의 명령과 제어에 따라 피관리 장치에 국한되는 행동을 취한다.

네트워크 관리 프로토콜(network management protocol)

네트워크 관리 프로토콜은 관리 서버와 피관리 장치들 사이에서 동작하면서
(1) 관리 서버가 피관리 장치의 상태에 대해 질의하고
(2) 에이전트를 통해 피관리 장치에 행동을 취할 수 있도록 해준다.

에이전트는 예외적인 사건을 관리 서버에게 알리기 위해 네트워크 관리 프로토콜을 사용할 수 있다.
(e.g., 부품의 고장 또는 성능 임계치의 위반)

네트워크 관리 프로토콜 스스로가 네트워크를 관리하지 않는다.

대신에 네트워크 관리자가 네트워크를 관리(감시, 테스트, 폴링, 설정, 분석, 평가, 제어)할 수 있도록 기능을 제공한다.

네트워크 운영자가 위의 구성요소들을 활용하여 네트워크를 관리할 수 있는, 흔히 사용하는 세 가지 방법이 있다.

1️⃣ CLI

네트워크 운영자는 명령줄 인터페이스(Command Line Interaface, CLI)를 통해 장치에 직접 명령을 보낼 수 있다.

이러한 명령은
(1) 운영자가 피관리 장치과 물리적으로 같은 공간에 있는 경우 피관리 장치의 콘솔에 직접 입력하거나
(2) 피관리 장치 사이의 텔넷(Telnet) 또는 SSH(secure shell) 연결을 통해 전달할 수 있다.

이 방법을 통해서는 대체로 오류가 발생하기 쉽고, 대규모 네트워크를 자동화하거나 효율적으로 관리하기 어렵다.

2️⃣ SNMP/MIB

이 방식에서 네트워크 운영자는 SNMP(Simple Network Management Protocol)를 사용하여
장치의 MIB(Management Information Base)에 있는 데이터를 질의하거나 설정할 수 있다.

일부 MIB 데이터는 장치 및 공급업체에 따라 다르지만,

다른 MIB 데이터(e.g., IP 데이터그램 헤더의 오류 때문에 라우터에서 버려지는 IP 데이터그램의 개수, 호스트에서 수신하는 UDP 세그먼트 개수)는
장치에 종속되지 않고 추상성과 일반성을 갖는다.

일반적으로 네트워크 운영자는

이 방식으로 동작 상태 및 장치 통계 정보를 질의 및 모니터링한 다음
명령줄 인터페이스를 사용하여 장치를 실제로 제어하고 설정한다.

CLI와 SNMP/MIB 모두 장치를 개별적으로 관리한다.

SNMP/MIB로도 장치 설정 및 대규모 네트워크 관리의 어려움이 존재한다.

이로 인해 NETCONF와 YANG을 사용하는 가장 최근의 네트워크 관리 방식이 나타났다.

3️⃣ NETCONF/YANG

이 방식은 네트워크 관리에 대해 좀 더 추상적이고 네트워크 전체를 아우르는 전체론적인 관점을 취하면서도,
정확성의 제약 정도를 구체화하고 여러 장치에 대한 세세한 관리 작업을 제공하는 등 설정 관리에 훨씬 더 중점을 둔다.

YANG : 설정 및 동작 데이터를 모델링하는 데 사용되는 데이터 모델링 언어
NETCONF 프로토콜 : 원격 장치과 YANG 호환 작업 및 데이터를 주고받거나 원격 장치 간에 통신하는 데 사용됨

5.7.2 SNMP와 MIB

SNMP

SNMPv3(Simple Network Management Protocol version 3)는
관리 서버와 그 관리 서버를 대표하여 실행되고 있는 에이전트 사이에서 네트워크 관리 제어 및 정보 메시지를 전달하기 위해 사용된다.

요청-응답 모드(request-response mode)

이는 SNMP의 가장 흔한 사용 행태이다.

SNMP 관리 서버는 에이전트에게 요청을 송신하고
- 일반적으로 요청은 피관리 장치과 관련된 MIB 객체 값들을 질의(검색) 또는 수정(설정)하기 위해 이용
이를 받은 SNMP 에이전트는 이를 수행한 후 요청에 대한 응답을 보낸다.

트랩 메시지(trap message)

SNMP의 두 번째로 일반적인 사용은
에이전트가 요구받지 않았더라도 트랩 메시지라는 이름의 메시지를 관리 서버에게 전송하는 것이다.

트랩 메시지들은 관리 서버들에게
MIB 객체 값들을 변화시킨 예외 사항(e.g., 링크 인터페이스의 활성 또는 비활성)의 발생을 통지하기 위해 이용된다.

아래 표는 SNMPv2에 대한 것이며, 일반적으로 PDU(Protocol Data Unit)으로 알려진 일곱 가지 타입의 메시지를 정의하고 있다.

GetRequest, GetNextRequest, GetBulkRequest PDU들은 모두
에이전트의 피관리 장치 내 하나 이상의 MIB 객체의 값을 요청하기 위해 관리 서버로부터 에이전트로 전송된다.
- 이들은 데이터 요청들의 정밀도(granularity) 면에서 다르다.
- 에이전트는 객체 식별자들과 그에 관련된 값들을 Response PDU에 담아 응답한다.
SetRequest PDU는 관리 서버가 피관리 장치 안의 하나 또는 그 이상의 MIB 객체들의 값을 설정하기 위해 사용한다.
- 에이전트는 값이 제대로 설정되었음을 알려주기 위해 ‘noError’라는 오류 상탯값을 Response PDU에 담아 응답한다.
SNMPv2-Trap은 트랩 메시지로, 비동기적으로 발생한다.
- 즉, 요청을 수신했을 때가 아니라 관리 서버가 통지를 요구한 이벤트가 발생했을 때 발생한다.
- 수신된 트랩 요청은 관리 서버로부터 어떤 응답도 요구하지 않는다.

아래 그림은 SNMP PDU의 포맷을 나타낸 것이다.

SNMP PDU들이 다른 많은 전송 프로토콜에 의해 운반될 수 있기는 하지만 일반적으로는 UDP 데이터그램의 페이로드 부분에 실린다.

그러나 UDP는 신뢰성이 보장되지 않는 전송 프로토콜이므로,
요청 또는 그에 대한 응답이 의도한 목적지에 도착한다는 보장이 없다.

따라서 아래처럼 요청 ID 필드는 관리 서버가 요청 또는 응답의 분실을 검출하는 데 이용될 수 있다.

PDU의 요청 ID 필드는 관리 서버가 에이전트에 보내는 요청에 번호를 매기기 위해 사용된다.
에이전트의 응답은 수신된 요청으로부터 요청 ID 값을 취한다.

MIB

MIB 객체는 SMI(Structure of Management Information, 관리 정보 구조)라고 하는 데이터 기술 언어로 명세되는데,
이 이름은 그 기능에 대한 아무런 힌트를 주지 않는 다소 엉뚱한 이름의 네트워크 관리 프레임워크 구성요소다.

SMI는 SNMP(네트워크 관리를 위해 관리 정보 및 정보 운반을 위한 프로토콜)에서 관리 정보의 구조를 말하며,
MIB 객체를 정의하는 일반적인 규칙들의 모음이다.

MIB는 망관리 자원 정보를 구조화시킨, 대규모 관리 정보 집합을 말한다.

앞에서 SNMP/MIB 방식의 네트워크 관리에서
피관리 장치의 동작 상태 데이터가 해당 장치를 위한 MIB에 수집된 객체들로 표현된다는 사실을 배웠다.

MIB 객체는 다음과 같은 정보일 수도 있다.

IP 데이터그램 헤더의 오류로 인해 라우터에서 버려지는 데이터그램 개수
이더넷 엔터페이스 카드의 반송파 감지 오류 횟수를 세는 카운터
DNS 서버에서 실행되는 소프트웨어 버전과 같은 설명 정보
특정 장치가 올바르게 작동하는지 여부와 같은 상태 정보
어떤 목적지로의 라우팅 경로 같은 프로토콜에 특정된 정보 등..

관련된 MIB 객체들은 MIB 모듈로 합쳐진다.

5.7.3 네트워크 설정 프로토콜(NETCONF)과 YANG

NETCONF

NETCONF 프로토콜은 관리 서버과 피관리 네트워크 장치 사이에서 동작하면서

피관리 장치의 설정 데이터를 검색, 셋업, 수정하거나
피관리 장치의 동작 데이터 및 통계를 질의하거나
피관리 장치에서 생성된 알림을 구독하기 위한 메시지 전송 기능을 제공한다.

관리 서버는 피관리 장치를 제어하기 위해 구조화된 XML 문서 형식의 설정 내용을 보내 피관리 장치에서 활성화한다.

NETCONF는 원격 프로시너 호출(remote procedure call, RPC) 패러다임을 사용한다.
XML로 인코딩된 프로토콜 메시지는 TCP상의 TLS(Transport Layer Security) 프로토콜과 같은
안전한 연결 지향 세션을 통해 관리 서버와 피관리 장치 사이에서 교환된다.

e.g., NETCONF <get> 명령

이 명령을 통해 서버는 장치의 설정에 대해 알 수 있다.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get/>
</rpc>

아래는 NETCONF 세션의 예다.

관리 서버는 피관리 장치와 보안 연결을 설정한다.
보안 연결이 설정되면 관리 서버와 피관리 장치는 <hello> 메시지를 교환하고,
기본 NETCONF 명세를 보완하는 어떠한 추가 ‘기능’이 있는지를 알린다.
관리 서버와 피관리 장치 간의 상호작용은 <rpc>와 <rpc-reply> 메시지를 사용하는 원격 프로시저 호출 형식을 갖는다.
- 이러한 메시지는 장치 설정 데이터와 동작 데이터 및 통계를 검색, 설정, 질의, 수정하고 장치의 알림을 구독하는 데 사용된다.
<close-session> 메시지로 세션을 종료한다.

아래 표는 관리 서버가 피관리 장체에서 수행할 수 있는 여러 가지 중요한 NETCONF 작업을 보인다.

YANG

YANG은 NETCONF가 사용하는 네트워크 관리 데이터의 구조, 구문 및 의미를 정확하게 표현하는 데 사용되는 데이터 모델링 언어다.

모든 YANG 정의는 모듈에 포함되고, 장치와 해당 기능을 설명하는 XML 문서는 YANG 모듈에서 생성할 수 있다.

Chapter 5 - 2. 라우팅 알고리즘, 3. OSPF, 4. 인터넷 서비스 제공업자 간의 라우팅: BGP

ssun_bear — Tue, 9 Jul 2024 20:34:19 +0900

5.2 라우팅 알고리즘

라우팅 알고리즘(routing algorithm)의 목표 : 송신자부터 수신자까지 라우터의 네트워크를 통과하는 좋은 경로(루트)를 결정하는 것

일반적으로 ‘좋은’ 경로란 최소 비용 경로(least-cost path)를 말한다.

그러나 현실적으로는 네트워크 정책과 같은 실제 문제가 고려된다.
(e.g., Y 기관에 속해 있는 라우터 x는 Z 기관이 소유한 네트워크가 보낸 패킷을 전달해서는 안 됨)

그래프

라우팅 문제를 나타내는 데는 그래프가 사용된다.

그래프(graph), G(N, E)

N
- 노드(node)의 집합
- 네트워크 계층 라우팅 상황에서 그래프상의 노드는 패킷 전달 결정이 이루어지는 지점인 라우터를 나타낸다.
E
- 에지(edge)의 집합
- 네트워크 계층 라우팅 상황에서 그래프상의 에지는 라우터들 간의 물리 링크를 나타낸다.
- 에지는 그 비용을 나타내는 값을 가진다.
  (일반적으로 해당 링크의 물리적인 거리, 링크 속도, 링크와 관련된 금전 비용 등을 반영)
- 집합 E에 포함된 어떤 에지 (x, y)에 대해 c(x, y)는 노드 x와 y 간의 비용을 의미한다.
- 에지 (x, y)가 집합 E에 속하면, 노드 y는 노드 x의 이웃(neighbor)이라고 한다.
하나의 에지는 집합 N에 속하는 한 쌍의 노드로 표시된다.

그래프 G(N, E)에서의 경로(path)는 노드의 연속(x1, x2, x3, …, xp)이고,
노드 쌍 (x1, x2), (x2, x3), … , (xp-1, xp)는 집합 E에 속한 에지들이다.

경로 (x1, x2, x3, … , xp)의 비용은 경로상 모든 에지 비용의 단순 합이다.
c(x1, x2) + c(x2, x3) + … + c(xp-1, xp)

라우팅 알고리즘의 분류

라우팅 알고리즘을 분류하는 일반적인 방법 한 가지는 알고리즘이 중앙 집중형인지 분산형인지다.

중앙 집중형 라우팅 알고리즘(centralized routing algorithm)

네트워크 전체에 대한 완전한 정보를 가지고 출발지와 목적지 사이의 최소 비용 경로를 계산한다.

계산 자체는 한 장소에서 수행되거나 모든 라우터 각각의 라우팅 모듈로 복사될 수 있다.

전체 상태 정보를 갖는 알고리즘을 링크 상태(link-state, LS) 알고리즘이라고 하는데,
이는 이 알고리즘이 네트워크 내 각 링크의 비용을 알고 있어야 하기 때문이다.

분산 라우팅 알고리즘(decentralized routing algorithm)

최소 비용 경로의 계산이 라우터들에 의해 반복적이고 분산된 방식으로 수행된다.

각 노드는 자신에게 직접 연결된 링크에 대한 비용 정보만을 가지고 시작한다.

이후 반복된 계산과 이웃 노드와의 정보 교환을 통해 노드는 점차적으로 목적지 또는 목적지 집합까지의 최소 비용 경로를 계산한다.

분산 라우팅 알고리즘은 거리 벡터(distance-vector, DV) 알고리즘이라고도 하는데,
이는 각 노트가 네트워크 내 다른 모든 노드까지 비용(거리)의 추정값을 벡터 형태로 유지하기 때문이다.

라우팅 알고리즘을 분류하는 일반적인 두 번째 방식은 정적 알고리즘과 동적 알고리즘으로 분류하는 것이다.

정적 라우팅 알고리즘(static routing algorithm)

사람이 직접 링크 비용을 수정하는 경우와 같은 종종 사람이 개입하는 상황 때문에 정적 라우팅 알고리즘에서 경로는 아주 느리게 변한다.

동적 라우팅 알고리즘(dynamic routing algorithm)

네트워크 트래픽 부하(load)나 토폴로지 변화에 따라 라우팅 경로를 바꾼다.

동적 알고리즘은 주기적으로, 혹은 토폴로지나 링크 비용의 변경에 직접적으로 응답하는 방식으로 수행된다.

장점 : 네트워크 변화에 빠르게 대응한다.
단점 : 경로의 루프(loop)나 경로 진동(oscillation) 같은 문제에 취약하다.

[참고] 토폴로지(topology, 망구성방식) : 컴퓨터 네트워크의 요소들(링크, 노드 등)을 물리적으로 연결해 놓은 것, 또는 그 연결 방식

라우팅 알고리즘을 분류하는 세 번재 방식은 라우팅 알고리즘이 부하에 민감한지 아닌지에 따른다.

부하에 민감한 알고리즘(load-sensitive algorithm)

링크 비용은 해당 링크의 현재 혼잡 수준을 나타내기 위해 동적으로 변한다.

현재 혼잡한 링크에 높은 비용을 부과한다면, 라우팅 알고리즘은 혼잡한 링크를 우회하는 경로를 택하는 경향을 보일 것이다.

초기 ARPAnet 라우팅 알고리즘이 부하에 민감해서 많은 어려움이 있었다.

부하에 민감하지 않은 알고리즘(load-insensitive algorithm)

오늘날 인터넷 라우팅 알고리즘(RIP, OSPF, BGP 등)은 링크 비용이 현재(또는 가장 최근)의 혼잡을 반영하지 않기 때문에 부하에 민감하지 않다.

5.2.1 링크 상태(LS) 라우팅 알고리즘

링크 상태 알고리즘에서는 네트워크 토폴로지와 모든 링크 비용이 알려져 있어서 링크 상태 알고리즘의 입력값으로 사용될 수 있다.

이것은 각 노드가 자신과 직접 연결된 링크의 식별자와 비용 정보를 담은 링크 상태 패킷을
네트워크상의 다른 모든 노드로 브로드캐스트하게 함으로써 가능하며,

이는 종종 인터넷 OSPF 라우팅 프로토콜 같은 링크 상태 브로드캐스트(link-state broadcast) 알고리즘에 의해 수행된다.

다익스트라 알고리즘(Dijkstra’s algorithm)

다익스트라 알고리즘은 하나의 노드(출발지, u라고 지칭)에서 네트워크 내 다른 모든 노드로의 최소 비용 경로를 계산한다.

알고리즘의 k번째 반복 이후에는 k개의 목적지 노드에 대해 최소 비용 경로가 알려지며,
이들은 모든 목적지 노드로의 최소 비용 경로 중에서 가장 낮은 비용을 갖는 k개의 경로다.

기호 정의

D(v) : 알고리즘의 현재 반복 시점에서 출발지 노드부터 목적지 v까지의 최소 비용 경로의 비용
p(v) : 출발지에서 v까지의 현재 최소 비용 경로에서 v의 직전 노드
N’ : 노드의 집합

출발지에서 v까지의 최소 비용 경로가 명확히 알려져 있다면, v는 N’에 포함된다.

출발지 노드 u를 위한 링크 상태(LS) 알고리즘

중앙 집중형 라우팅 알고리즘은 2단계로 구성된다.

초기화 단계(Initialization)
반복 부분(Loop) : 수행 횟수는 네트워크의 노드 수와 같다.

아래 그래프의 네트워크에서 링크 상태 알고리즘을 수행한 결과는 다음과 같다.

포워딩 테이블

링크 상태 알고리즘이 종료된 후에 우리는 각 노드에 대해 출발지 노드로부터의 최소 비용 경로상의 직전 노드를 알게 된다.

노드 u의 포워딩 테이블은 각 목적지에 대해 / 노드 u에서 그 목적지까지의 최소 비용 경로상의 다음 홉 노드 정보를 저장하여 구성한다.

아래 그림은 최소 비용 경로의 결과와 노드 u의 포워딩 테이블을 보여준다.

계산 복잡도

n개의 노드(출발지 노드 제외)가 있다면 출발지에서 모든 목적지까지 최단 비용 경로를 찾기 위해 최악의 경우 얼마나 많은 계산이 필요한가?

첫 번째 반복에서 최소 비용이 이미 계산된 노드의 집합 N’에 포함되지 않은 노드 w를 결정하기 위해 모든 n개의 노드를 검사해야 하며,
두 번째 반복에서는 n-1개의 노드를, 세 번째 반복에서는 n-2개의 노드를 검사해야 한다.

따라서 찾아야 하는 노드의 총수는 n(n+1)/2가 되며,
링크 상태 알고리즘은 최악의 경우 O(n^2)의 복잡성을 갖는다.

진동(oscillation) 문제

진동 문제는 링크 상태 알고리즘뿐만 아니라 혼잡이나 지연 시간을 기반으로 링크 비용을 산출하는 모든 알고리즘에서 발생할 수 있다.

아래의 과정을 통해 진동 문제에 대하여 살펴보자.

초기의 라우팅은 다음과 같다.

링크의 비용은 통과하는 트래픽 양에 따른다.

링크 상태 알고리즘이 다시 수행되면 노드 y는 w로 가는 시계 방향의 경로 비용이 1인 반면,
지금까지 사용해왔던 반시계 방향으로의 경로 비용은 1+e임을 알게 된다.

따라서 w로 가는 y의 최소 비용 경로는 시계 방향이며,
x도 마찬가지로 w로 가는 시계 방향 경로를 새로운 최소 비용 경로로 결정한다.

링크 상태 알고리즘이 다시 한번 수행되면
노드 x, y, z 모두 w로 가는 반시계 방향의 경로 비용이 0임을 알게 되어 모든 트래픽을 반시계 방향 경로로 보낸다.

다음번 링크 상태 알고리즘 수행 시에는 x, y, z 모두 시계 방향으로 트래픽을 전송한다.

이러한 진동 문제를 방지하기 위한 방법들 중 하나는 모든 라우터가 동시에 링크 상태 알고리즘을 실행하지 못하도록 하는 것이다.

라우터들이 동일한 주기 간격으로 링크 상태 알고리즘을 수행한다 하더라도
각 노드에서의 알고리즘의 실행 시각은 같지 않을 것이기 때문에 합리적인 방법이라고 생각된다.

하지만 연구자들은 라우터들이 알고리즘을 처음에는 각기 다른 시작 시각에, 그러나 같은 주기를 갖도록 해서 실행하더라도
점진적으로 결국엔 서로 동기화된다는 것을 발견하였다.

이러한 자기 동기화는 각 노드가 링크 상태 정보를 송신하는 시각을 임의로 결정하게 함으로써 회피할 수 있다.

5.2.2 거리 벡터(DV) 라우팅 알고리즘

오늘날 실제로 사용되는 알고리즘은 거리 벡터(distance-vector, DV) 라우팅 알고리즘이다.

링크 상태 알고리즘이 네트워크 전체 정보를 이용하는 알고리즘인 반면,
거리 벡터 알고리즘은 반복적이고 비동기적이며 분산적이다.

분산적(distributed) : 각 노드는 하나 이상의 직접 연결된 이웃으로부터 정보를 받고, 계산을 수행하며, 계산된 결과를 다시 이웃들에게 배포한다.
반복적(iterative) : 이웃끼리 더 이상 정보를 교환하지 않을 때까지 프로세스가 지속된다.
비동기적(asynchronous) : 모든 노드가 서로 정확히 맞물려 동작할 필요가 없다.

벨만-포드(Bellman-Ford) 식

노드 x부터 y까지 최소 비용 경로의 비용은 다음과 같이 나타낼 수 있다.

min.v는 x의 모든 이웃에 적용된다.
x에서 v로 이동한 후, v에서 y까지의 최소 비용 경로를 택한다면, 경로 비용은 c(x, v) + d.v(y)일 것이다.
반드시 하나의 이웃 v로 가는 것부터 시작해야 하므로,
x에서 y까지의 최소 비용은 모든 이웃 노드 v에 대해 계산된 c(x, v) + d.v(y) 중 최솟값이 된다.

벨만-포드 식의 해답은 각 노드 포워딩 테이블의 엔트리를 제공한다.

위의 식을 최소로 만드는 이웃 노드를 v*라고 해보자.
만약 노드 x가 노드 y에게 최소 비용 경로로 패킷을 보내기 원한다면, 노드 x는 패킷을 노드 v*로 전달해야 한다.

그러므로 노드 x의 포워딩 테이블에는 최종 목적지 y로 가기 위한 다음 홉 라우터로 v*가 지정되어 있어야 한다.

따라서 거리 벡터 라우팅 알고리즘의 기본 아이디어는 다음과 같다.

출발지 노드를 x라고 가정하면, 노드 x는 자신으로부터 집합 N에 속한 다른 모든 노드 y까지의 최소 비용 경로의 비용 D.x(y)를 추정한다.

D.x을 노드 x에서부터 N에 속한 모든 다른 노드 y까지의 비용 추정값의 벡터라고 하자.

DV 알고리즘으로 각 노드 x는 다음과 같은 라우팅 정보를 유지한다.

각 이웃 노드 v 중에서 x에 직접 접속된 이웃 노드까지의 비용 c(x, v)
노드 x의 거리 벡터, 즉 x로부터 N에 있는 모든 목적지 y로의 비용 예측값을 포함하는 벡터 D.x
이웃 노드들의 거리 벡터들, 즉 v가 x의 이웃이라고 하면 D.v = [D.v(y): y in N]

분산적이고 비동기적으로 동작하는 알고리즘에서는 때때로 각 노드가 자신의 거리 벡터를 이웃들에게 보낸다.

노드 x가 이웃 w에게서 새로운 거리 벡터를 수신하면,
x는 w의 거리 벡터를 저장하고 벨만-포드 식을 사용하여 다음처럼 자신의 거리 벡터를 갱신한다.

(N에 속하는 각 노드 y에 대해)

만약 이 갱신으로 인해 노드 x의 거리 벡터가 변경된다면

노드 x는 이 수정된 거리 벡터를 자신의 이웃들에게 보내고
그에 따라 이웃들도 자신의 거리 벡터를 갱신한다.

모든 노드가 자신의 거리 벡터를 비동기적으로 교환하는 동작을 계속하다 보면,
비용 추정값 D.x(y)는 노드 x에서 노드 y까지의 실제 최소 비용 경로의 비용인 d.x(y)로 수렴하게 된다.

거리 벡터(DV) 알고리즘

각 노드 x에서,

특정 목적지 y에 대한 자신의 포워딩 테이블을 갱신하기 위해 노드 x가 알아야 하는 것은 y로의 최단 경로상의 다음 홉 라우터인 이웃 노드 v*(y)다.

다음 홉 라우터 v*(y)는 위 DV 알고리즘의 14번째 줄에서 최솟값을 갖게 하는 이웃 v이기에,
13~14번째 줄에서 각 목적지 y에 대해 노드 x는 v*(y)를 결정하고 목적지 y에 대해 포워딩 테이블도 갱신한다.

DV 알고리즘에서 하나의 노드가 갖는 정보는 단지 자신에게 직접 연결된 이웃으로의 링크 비용과 그 이웃들로부터 수신하는 정보뿐이다.

각 노드는 이웃으로부터의 갱신을 기다리고 (10~11번째 줄)
업데이터를 수신하면 새로 거리 벡터를 계산하고 (14번째 줄)
이 새로운 거리 벡터를 이웃들에게 배포한다. (16~17번째 줄)

이 과정은 더 이상의 갱신 메시지가 없을 때까지 계속된다.

갱신 메시지가 더 이상 없으면 라우팅 테이블 계산도 더 이상 없고 알고리즘은 정지 상태가 된다. (10~11번째 줄 대기 명령을 수행)

이 알고리즘은 링크 비용이 변할 때까지 정지 상태로 있는다.

아래 그림은 세 노드로 이루어진 단순한 네트워크에서의 거리 벡터 알고리즘의 동작을 보여준다.

여기서는 모든 노드가 동기적 방식으로 동작하지만, 비동기적 방식으로도 알고리즘은 올바르게 동작한다.

거리 벡터(DV) 알고리즘: 링크 비용 변경과 링크 고장

거리 벡터 알고리즘을 수행하는 노드가

자신과 이웃 사이 링크의 비용이 변경된 것을 알게 되면
자신의 거리 벡터를 갱신한 후
최소 비용 경로의 비용에 변화가 있는 경우에는 이웃에게 새로운 거리 벡터를 보낸다.

이때 최소 비용 경로의 비용이 감소한 상황과 증가한 상황 두 가지를 전부 살펴보자.

a. 비용이 감소한 상황

아래는 y에서 x로의 링크 비용이 4에서 1로 변한 상황을 나타낸 것이다.

이 상황에서의 DV 알고리즘은 다음과 같은 일련의 사건을 발생시킨다.

시각 t0 : y가 링크 비용의 변화를 감지하고, 자신의 거리 벡터를 갱신한 후 이 변경값을 이웃에게 알린다.
시각 t1 : z는 y로부터 갱신 정보를 받고 자신의 테이블을 갱신한다.
- z는 x까지의 새로운 최소 비용을 계산한다.
- 이웃에게 자신의 새로운 거리 벡터를 전송한다.
시각 t2 : y는 z로부터 갱신 정보를 받고 자신의 테이블을 갱신한다.
- y의 최소 비용은 변화가 없으므로 y는 z에게 아무런 메시지를 보내지 않는다.
- 이에 알고리즘은 정지 상태가 된다.

따라서 거리 벡터 알고리즘은 정지 상태가 될 때까지 두 번만 반복하면 된다.

b. 비용이 증가한 상황

아래는 y에서 x로의 링크 비용이 4에서 60로 변한 상황을 나타낸 것이다.

이 상황에서의 DV 알고리즘은 다음과 같은 일련의 사건을 발생시킨다.

시각 t0 : y가 링크 비용 변화를 감지하고 노드 x까지 다음의 비용을 갖는 새로운 최소 비용 경로를 계산한다.
- 이때 우리는 네트워크 전체를 한눈에 볼 수 있기 때문에 z를 경유하는 이 새로운 비용이 잘못되었다는 사실을 알 수 있지만,
  노드 y의 입장에서는 아니다.
시각 t1
- x로 가기 위해 y는 z로 경로 설정을 하고, z는 y로 경로 설정을 하는 라우팅 루프(routing loop)가 발생한다.
- t1에 x를 목적지로 하는 패킷이 y나 z에 도착하면 포워딩 테이블이 변할 때까지 이 두 노드 사이에서 왔다 갔다 순환할 것이다.
- 노드 y는 x까지의 새로운 최소 비용을 계산했으므로 z에게 새로운 거리 벡터를 알린다.
시각 t2 : z는 y로부터 갱신 정보를 받고 새로운 최소 비용을 계산한다.
- D.z(x) = min{50+0, 1+6} = 7
- x까지의 z의 최소 비용이 증가했으므로, 새로운 거리 벡터를 y에 알린다.
시각 t3 : y는 z로부터 새로운 거리 벡터를 수신하고 새로운 최소 비용을 계산한다.
- Dy(x) = min{60+0, 1+7} = 8
- x까지의 y의 최소 비용이 증가했으므로, 새로운 거리 벡터를 z에 알린다.
…

이렇게 계속 반복되는 문제를 무한 계수 문제(count-to-infinity)라고 한다.

거리 벡터 알고리즘: 포이즌 리버스 추가

방금 설명한 특정한 라우팅 루프 시나리오는 포이즌 리버스(poisoned reverse)라는 방법을 통해 방지할 수 있다.

즉, 만약 z가 y를 통해 목적지 x로 가는 경로 설정을 했다면, z는 y에게 x까지의 거리가 무한대라고 알린다.

z는 y를 통과해서 x로 가는 동안은 이러한 거짓말을 계속한다.

이에 y는 z에서 x로 가는 경로가 없다고 믿으므로,
z가 계속해서 y를 통해 x로 가는 경로를 사용하는 동안은 y는 z를 통해 x로 가는 경로를 시도하지 않을 것이다.

하지만 포이즌 리버스는 모든 무한 계수 문제를 해결할 수는 없다.

단순히 직접 이웃한 2개의 노드가 아닌, 3개 이상의 노드를 포함한 루프는 포이즌 리버스로는 감지할 수 없다.

링크 상태 알고리즘과 거리 벡터 라우팅 알고리즘의 비교

✅ 경로 계산 방법

LS와 DV 알고리즘은 경로를 계산할 때 서로 대비되는 방법을 취한다.

LS 알고리즘

전체 정보를 필요로 한다.
각 노드는 다른 모든 노드와 (브로드캐스트를 통해) 통신한다.
오직 자신에게 직접 연결된 링크의 비용만 알린다.

DV 알고리즘

각 노드는 오직 직접 연결된 이웃과만 메시지를 교환한다.
자신으로부터 네트워크 내 (자신이 알고 있는) 모든 노드로의 최소 비용 추정값을 이웃들에게 제공한다.

✅ 메시지 복잡성

LS 알고리즘

각 노드는 네트워크 내 각 링크 비용을 알아야 하며, 이를 위해서는 O(|N| |E|)개의 메시지가 전송되어야 한다.
링크 비용이 변할 때마다 새로운 링크 비용이 모든 노드에게 전달되어야 한다.

DV 알고리즘

매번 반복마다 직접 연결된 이웃끼리 메시지를 교환한다.
알고리즘의 결과가 수렴하는 데 걸리는 시간은 많은 요소에 좌우된다.
링크 비용이 변하고, 이 새로운 링크 비용이 이 링크에 연결된 어떤 노드의 최소 비용 경로에 변화를 준 경우에만
DV 알고리즘은 수정된 링크 비용을 전파한다.

✅ 견고성

라우터가 고장나거나 오동작하거나 파손된다면 어떤 일이 발생할까?

LS 알고리즘

라우터는 연결된 링크에 대해 잘못된 비용 정보를 브로드캐스트할 수 있다.
노드는 링크 상태 브로드캐스트를 통해 받은 패킷을 변질시키거나 폐기할 수 있다.

그러나 하나의 링크 상태 노드는 자신의 포워딩 테이블만 계산하기 때문에 링크 상태 알고리즘에서 경로 계산은 어느 정도 분산되어 수행된다.

따라서 링크 상태 알고리즘은 어느 정도의 견고성을 제공한다.

DS 알고리즘

노드는 잘못된 최소 비용 경로를 일부 혹은 모든 목적지에 알릴 수 있다.

각 반복마다 한 노드의 거리 벡터 계산이 이웃에게 전달되고 다음 반복에서 이웃의 이웃에게 간접적으로 전달된다.

따라서 거리 벡터 알고리즘을 사용하는 네트워크에서 한 노드의 잘못된 계산은 전체로 확산될 수 있다.

실제로 1997년에 작은 ISP에서 오작동한 라우터가 잘못된 라우팅 정보를 전국망의 백본 라우터에 제공한 적이 있었다.

이는 다른 라우터들이 오작동한 라우터에게 대규모 트래픽을 보내게 만들었고,
인터넷의 상당 부분이 여러 시간 동안 단절되었다고 한다.

결국 어떤 알고리즘이 다른 알고리즘보다 명백히 낫다고 말할 수는 없으며,
실제로 두 알고리즘 모두는 인터넷에서 사용되고 있다.

5.3 인터넷에서의 AS 내부 라우팅: OSPF

네트워크를 동일한 라우팅 알고리즘을 수행하는 동종의 라우터 집합으로 간주하는 관점은 다음의 두 가지 문제점이 존재한다.

확장
라우터의 수가 증가함에 따라 라우팅 정보의 통신, 계산, 저장에 필요한 오버헤드가 걷잡을 수 없이 증가한다.
관리 자율성
ISP는 일반적으로 자신의 네트워크를 원하는 대로 운용하거나(e.g., 어떠한 라우팅 알고리즘이라도 수행할 수 있도록),
네트워크 내부 구성을 외부에 감추기를 원한다.

자율 시스템

위의 문제점들은 라우터들을 자율 시스템(autonomous system, AS)으로 조직화하여 해결할 수 있다.

각 AS는 동일한 관리 제어하에 있는 라우터의 그룹으로 구성된다.
자율 시스템은 전 세계적으로 고유한 AS 번호(autonomous system number, ASN)으로 식별된다.
같은 AS 안에 있는 라우터들은 동일한 라우팅 알고리즘을 사용하고 상대방에 대한 정보를 갖고 있다.
자율 시스템 내부에서 동작하는 라우팅 알고리즘을 AS 내부 라우팅 프로토콜(intra-autonomous system routing protocol)이라고 한다.

개방형 최단 경로 우선(OSPF) 프로토콜

개방형 최단 경로 우선(open shortest path first, OSPF) 라우팅과 IS-IS(Intermediate System to Intermediate System)는
인터넷에서 AS 내부 라우팅에 널리 사용된다.

OSPF는 링크 상태 정보를 플러딩(flooding)하고 다익스트라 최소 비용 경로 알고리즘을 사용하는 링크 상태 알고리즘이다.

OSPF를 이용하여 각 라우터는 전체 AS에 대한 완벽한 토폴로지 지도(그래프)를 얻는다.
각 라우터는 자신을 루트 노드로 두고 모든 서브넷에 이르는 최단 경로 트리를 결정하기 위해 혼자서 다익스트라의 최단 경로 알고리즘을 수행한다.
OSPF를 사용하는 라우터는 자율 시스템 내의 다른 모든 라우터에게 라우팅 정보를 브로드캐스팅한다.
- 링크 상태가 변경될 때마다
- 링크 상태가 변경되지 않았더라도 정기적으로(최소한 30분마다 한 번씩)
OSPF 메시지에 포함된 상태 정보는 인터넷 프로토콜에 의해 전달되며, 상위 계층 프로토콜 번호로는 OSPF를 의미하는 89를 갖는다.
- 따라서 OSPF 프로토콜은 신뢰할 수 있는 메시지 전송과 링크 상태의 브로드캐스트와 같은 기능을 스스로 구현해야 한다.
- 또한 OSPF 프로토콜은 링크가 동작하고 있는지 검사하고,
  OSPF 라우터가 네트워크 전반의 링크 상태에 대한 이웃 라우터의 데이터베이스를 얻을 수 있도록 해야 한다.

OSPF 링크 가중치 설정

링크 상태 라우팅을 설명하면서 우리는 순서를 묵시적으로 아래와 같이 가정했다.

링크 가중치가 설정되고,
OSPF 같은 라우팅 알고리즘이 수행되며,
LS 알고리즘에 의해 계산된 라우팅 테이블의 내용에 따라 트래픽이 흐른다.

이를 원인과 결과 방식으로 설명하면,

원인 : 링크 가중치가 주어지고
결과 : 이에 따라 전체 비용을 최소화하는 라우팅 경로가 결정된다.

실제로는 링크 가중치와 라우팅 경로 간의 원인과 결과 관계는 반대가 될 수도 있다.

네트워크 운영자가 어떤 트래픽 관리 목표를 충족시키는 라우팅 경로를 얻기 위해 링크 가중치를 설정할 수 있다.

즉, 트래픽 흐름에 대한 바람직한 경로가 알려져 있고, OSPF 라우팅 알고리즘이 이 경로대로 구성하게 되도록 OSPF 링크 가중치를 찾아야 한다.

따라서 관리자는 모든 링크 비용을 1로 설정함으로써 최소 홉 라우팅이 이루어지게 하거나,
적은 대역폭을 가진 링크 사용을 억제하기 위해 링크 용량에 반비례하게 링크 가중치를 설정할 수 있다.

OSFP에 구현된 개선사항들

보안

OSPF 라우터들 간의 정보 교환(e.g., 링크 상태 갱신)을 인증할 수 있으며,
인증을 통해 신뢰할 수 있는 라우터들만이 AS 내부의 OSPF 프로토콜에 참여할 수 있다.

원래 라우터 간의 OSPF 패킷은 인증을 하지 않으므로 위조될 수 있다.

두 종류의 인증

단순 인증 : 동일한 패스워드가 각 라우터에 설정되며, 라우터가 OSPF 패킷을 보낼 때 패스워드를 평문 그대로 포함하기 때문에 안전하지 않다.
MD5 인증 : 모든 라우터에 설정된 공유 비밀키를 기반으로 한다. (8장 내용)

복수 동일 비용 경로

하나의 목적지에 대해 동일한 비용을 가진 여러 개의 경로가 존재할 때 OSPF는 여러 개의 경로를 사용할 수 있도록 한다.

즉, 비용이 동일한 여러 개의 경로가 있을 때 모든 트래픽을 전달하기 위한 단 하나의 경로를 선택할 필요가 없다.

유니캐스트와 멀티캐스트 라우팅의 통합 지원

MOSPF(multicast OSPF)는 멀티캐스트 라우팅 기능을 제공하기 위해 OSPF를 단순 확장했다.

기존의 OSPF 링크 데이터베이스를 사용
OSPF 링크 상태 브로드캐스트 메커니즘에 새로운 형태의 링크 상태 알림을 추가

[참고]

MAC 주소 : 네트워크 상에서 서로를 구분하기 위해 디바이스마다 할당된 물리적 주소
유니캐스트(Unicast) : 정보를 전송하기 위한 프레임에 자신의 MAC 주소와 목적지의 MAC 주소를 첨부하여 전송하는 방식 (일대일 통신)
브로드캐스트(Broadcast) : 로컬 네트워크에 연결되어 있는 모든 시스템에게 프레임을 보내는 방식
(송신 노드 하나가 네트워크에 연결된 수신 가능한 모든 노드에 데이터를 전송)
멀티캐스트(Multicast) : 네트워크에 연결되어 있는 시스템 중 특정 그룹을 지정해서 해당 그룹원에게만 한 번에 정보를 전송하는 방식
(라우터가 멀티캐스트를 지원해야만 사용 가능)

단일 AS 내에서의 계층 지원

OSPF의 자율 시스템(AS)는 계층적인 영역(area)으로 구성될 수 있다.

각 영역은 자신의 OSPF 링크 상태 라우팅 알고리즘을 수행한다.
한 역역 내의 라우터는 같은 영역 내의 라우터들에게만 링크 상태를 브로드캐스트한다.
각 영역 내에서 하나 혹은 그 이상의 영역 경계 라우터(area border router)가 영역 외부로의 패킷 라우팅을 책임진다.
백본 영역의 주요 역할은 AS 내 영역 간의 트래픽을 라우팅하는 것이다.

AS 내 영역 간 라우팅을 위해서는,

영역 경계 라우터로 패킷을 라우팅한다. (영역 내 라우팅)
백본을 통과하여 목적지 영역의 영역 경계 라우터로 라우팅한다.
그 후 최종 목적지로 라우팅한다.

5.4 인터넷 서비스 제공업자(ISP) 간의 라우팅: BGP

패킷이 여러 AS를 통과하도록 라우팅할 때,
(e.g., 한국에 있는 스마트폰이 실리콘 밸리에 있는 데이터 센터로 전송을 할 경우)
자율 시스템 간 라우팅 프로토콜(inter-autonomous system routing protocol)이 필요하다.

통신하는 AS들은 같은 AS 간 라우팅 프로토콜을 수행해야만 한다.

실제로 인터넷의 모든 AS는 경계 게이트웨이 프로토콜(Border GateWay Protocol, BGP)을 사용하며,
이는 거리 벡터 라우팅과 같은 줄기에서 나왔다고 볼 수 있는 분산형 비동기식 프로토콜이다.

5.4.1 BGP의 역할

같은 AS 내에 있는 목적지에 대해서는 라우터의 포워딩 테이블 엔트리들이 해당 AS의 AS 내부 라우팅 프로토콜에 의해 결정된다.

하지만 목적지가 AS 외부에 있는 경우, BGP가 필요하다.

BGP에서는 패킷이 CIDER(Classless Inter-Domain Routing) 형식으로 표현된, 주소의 앞쪽 프리픽스(prefix)를 향해 전달된다.

각 프리픽스는 서브넷이나 서브넷의 집합을 나타낸다. (e.g., 139.16.68/22)

라우터의 포워딩 테이블은 (x, I) 같은 형식의 엔트리들을 갖게 된다

x : 주소 프리픽스 (e.g., 139.16.68/22)
I : 라우터 인터페이스의 인터페이스 번호

AS 간 라우팅 프로토콜로서 BGP는 각 라우터에게 다음과 같은 수단을 제공한다.

이웃 AS를 통해 도달 가능한 서브넷 프리픽스 정보를 얻는다.
- 특히 각 서브넷이 자신의 존재를 인터넷 전체에 알릴 수 있도록 한다.
서브넷 주소 프리픽스로의 가장 좋은 경로를 결정한다.
- 라우터는 특정한 주소 프리픽스를 향한 2개 이상의 경로를 알 수도 있다.
- 가장 좋은 경로를 결정하기 위해 라우터는 BGP의 경로 결정 프로시저를 수행한다.

5.4.2 BGP 경로 정보 알리기

아래의 단순한 네트워크는 3개의 자율 시스템 AS1, AS2, AS3를 가지며,
AS3는 주소 프리픽스가 x인 서브넷을 포함한다.

각 AS에서 각각의 라우터들은 게이트웨이 라우터(gateway router) 또는 내부 라우터(internal router)다.

게이트웨이 라우터(gateway router)

AS의 경계에 있는 라우터
다른 AS들에 있는 하나 또는 여러 개의 라우터와 직접 연결된다.
e.g., AS1의 라우터 1c

내부 라우터(internal router)

자신의 AS 내에 있는 호스트 및 라우터와만 연결된다.
e.g., AS1의 라우터 1a, 1b, 1d

자율 시스템은 서로 메시지를 보내지 않고 라우터가 보낸다.

BGP 연결(BGP connection)

BGP에서 라우터의 쌍들은 포트 번호가 179이고 반영구적인 TCP 연결을 통해 라우팅 정보를 교환한다.
이 TCP 연결을 통해 모든 BGP 메시지가 전송된다.

외부 BGP(external BCP, eBGP) 연결

2개의 AS를 연결하는 BGP 연결

내부 BGP(internal BGP, iBGP) 연결

같은 AS 내의 라우터를 연결하는 BGP 연결

보통 각기 다른 AS에 속하는 게이트웨이 라우터들을 직접 연결하는 링크에는 eBGP 연결이 존재한다.

각 AS 내부 라우터 간에는 iBGP 연결도 존재하며,
아래 그림은 한 AS 내 모든 라우터의 쌍 각각에 대해 하나씩의 BGP 연결을 두는 일반적인 설정 모습을 보인다.

iBGP 연결은 물리적인 링크와 항상 일치하지는 않는다.

위 예시에서 프리픽스 x에 대한 도달 가능성 정보를 AS1과 AS2의 모든 라우터에게 알리는 작업을 생각해보자.

아래의 과정이 완료되면 AS1과 AS2의 각 라우터들은 x의 존재와 x로 향하는 AS 경로를 알게 된다.

먼저 게이트웨이 라우터 3a는 게이트웨이 라우터 2c에게 ‘AS3 x’라는 eBGP 메시지를 보낸다.
(’x가 존재하고 AS3 내에 있다’는 의미)
게이트웨이 라우터 2c는 iBGP 메시지 ‘AS3 x’를 게이트웨이 라우터 2a를 포함한 AS2 내부의 모든 라우터에게 전송한다.
게이트웨이 라우터 2a는 eBGP 메시지 ‘AS2 AS3 x’를 게이트웨이 라우터 1c에게 보낸다.
(’x가 존재하고 x에 도달하기 위해서는 먼저 AS2를 통과하고 그 후 AS3으로 갈 수 있다’는 의미)
마지막으로, 게이트웨이 라우터 1c는 iBGP를 사용하여 AS1 내의 모든 라우터에게 메시지 ‘AS2 AS3 x’를 전달한다.

실제 네트워크에서는 주어진 라우터에서 특정 목적지까지 다른 많은 경로가 존재할 수 있고, 심지어 각기 다른 일련의 AS들을 통과하기도 한다.

아래 그림은 라우터 1d에서 3d로 연결되는 물리적인 링크를 추가한 것이다.

이 경우에 AS1에서 x로는 2개의 경로가 존재한다.

라우터 1c를 통과하는 경로 ‘AS2 AS3 x’
라우터 1d를 통과하는 새로운 경로 ‘AS3 x’

5.4.3 최고의 경로 결정

주어진 라우터에서 목적지 서브넷까지는 많은 경로가 있을 수 있는데,
이런 경로들 중에서 라우터는 어떻게 선택을 할까? 그리고 어떻게 그에 따라 포워딩 테이블을 설정할까?

BGP 관련 용어들

라우터가 BGP 연결을 통해 주소 프리픽스를 알릴 때 몇몇 BGP 속성(attribute)을 함께 포함한다.

BGP의 용어로는 프리픽스와 그것의 속성을 경로(route)라고 한다.

AS-PATH

알림 메시지가 통과하는 AS들의 리스트를 담는다.
1. 프리픽스가 어떤 AS에 전달되었을 때
2. 그 AS는 자신의 ASN을 AS-PATH 내 현재 리스트에 추가한다.
메시지의 루프를 감지하고 방지하기 위해 활용한다.
1. 어떤 라우터가 자신의 AS가 경로 리스트에 포함되어 있는 것을 발견하면
2. 그 알림 메시지를 버린다.

NEXT-HOP

AS-PATH가 시작되는 라우터 인터페이스의 IP 주소

e.g.,

AS1에서 AS2를 통과하여 x로 가는 ‘AS2 AS3 x’ 경로의 NEXT-HOP 속성은 라우터 2a의 왼쪽 인터페이스의 IP 주소다.

AS1에서 AS2를 우회하여 x로 가는 ‘AS3 x’ 경로의 NEXT-HOP 속성은 라우터 3d의 맨 왼쪽 인터페이스의 IP 주소다.

즉, AS1의 각 라우터는 프리픽스 x로 가는 2개의 BGP 경로를 알게 된다.

라우터 2a의 맨 왼쪽 인터페이스의 IP 주소; AS2 AS3; x

라우터 3d의 맨 왼쪽 인터페이스의 IP 주소; AS3; x

NEXT-HOP 속성은 AS1에 속하지 않는 라우터의 IP 주소이다.

그러나 이 IP 주소를 포함하는 서브넷이 AS1에 직접적으로 연결된다.

뜨거운 감자 라우팅(hot potato routing)

가능한 모든 경로 중, 경로 각각의 시작점인 NEXT-HOP 라우터까지의 경로 비용이 최소가 되는 경로를 선택한다.

여러 게이트웨이를 통해 서브넷 x에 도달할 수 있다는 사실을 AS 간 프로토콜로부터 알게 된다.
각 게이트웨이까지의 최소 비용 경로를 정하기 위해 AS 내부 프로토콜을 통해 얻은 라우팅 정보를 이용한다.
뜨거운 감자 라우팅: 가장 적은 비용의 게이트웨이를 선택한다.
포워딩 테이블로부터 최소 비용 게이트웨이로의 인터페이스 I를 결정한 후 포워딩 테이블에 (x, I)를 추가한다.

포워딩 테이블에 AS 외부의 목적지를 추가할 때
AS 간 라우팅 프로토콜(BGP)과 AS 내부 라우팅 프로토콜(e.g., OSPF) 둘 다가 사용된다.

e.g.,

라우터 1b는 주소가 x로 시작하는 서브넷으로 가는 2개의 BGP 경로를 안다.
NEXT-HOP 라우터 2a와 3d 각각에 대해 최소 비용을 가진 AS 내부 경로를 찾기 위해 AS 내부 라우팅 정보를 조사한다.
이들 최소 비용 경로 중에서도 가장 적은 비용을 가진 경로를 선택한다.
비용을 거쳐가야 하는 링크의 수로 정의하면,
- 라우터 1b에서 라우터 2a까지의 최소 비용 : 2
- 라우터 1b에서 라우터 3d까지의 최소 비용 : 3
따라서 라우터 2a가 선택된다.
라우터 1b는 자신의 (AS 내부 알고리즘에 의해 설정된) 포워딩 테이블을 관찰하여 라우터 2a로 가기 위한 인터페이스 I를 찾아내고,
엔트리 (x, I)를 자신의 포워딩 테이블에 추가한다.

기본 아이디어
라우터가 목적지까지의 경로 중 자신의 AS 바깥에 있는 부분에 대한 비용은 신경 쓰지 않고
최대한 신속하게(가능한 한 최소의 비용으로) 패킷을 자신의 AS 밖으로 내보내는 것이다.

즉, 뜨거운 감자 라우팅은 오로지 자신의 경로 중에서 자기 AS 내부 비용만 줄이려는 이기적인 알고리즘이다.

이를 사용하면 한 AS 내 2개의 라우터가 동일한 목적지 주소에 대해 각기 다른 AS 경로를 선택할 수도 있다.

e.g.,
위의 예시에서 라우터 1b는 AS2를 통해 서브넷 x로 패킷을 보냈지만, 라우터 1d는 바로 AS3으로 보내 서브넷 x에 도달한다.

경로 선택 알고리즘

실제로 BGP는 뜨거운 감자 라우팅을 포함하는 더 복잡한 알고리즘을 사용한다.

목적지 주소의 프리픽스가 주어지면, 지금까지 라우터가 알아낸 해당 목적지까지의 모든 경로가 BGP의 경로 선택 알고리즘에 입력으로 주어진다.

하나의 목적지에 대해 2개 이상의 경로가 존재한다면 BGP는 하나의 경로가 남을 때까지 다음의 제거 규칙을 계속 수행한다.

여기서 뜨거운 감자 라우팅에서 추가된 것은 속성 중의 하나로서 지역 선호도(local preference)가 경로에 할당되었다는 것이다.

한 경로의 지역 선호도는 라우터에 의해 설정되었거나 같은 AS 내부의 다른 라우터로부터 학습된 것이다.

최고 지역 선호 값을 가진 경로가 선택된다.
최고 지역 선호 값을 가진 경로가 여러 개 있다면 이들 중에서 최단 AS-PATH를 가진 경로가 선택된다.
- 만약 이 규칙이 경로 선택을 위한 유일한 규칙이라면, BGP는 경로 결정을 위해 DV 알고리즘을 사용할 것이다.
- 여기서 거릿값으로는 AS 홉 수를 사용한다.
(같은 최고 지역 선호 값 및 같은 AS-PATH 길이를 가진) 모든 남은 경로들에 대해 뜨거운 감자 라우팅을 수행한다.
만일 아직도 하나보다 많은 경로가 남아 있다면 라우터는 BGP 식별자를 사용하여 경로를 선택한다.

e.g.,

라우터 1b에서 서브넷 x로 가는 BGP 경로는 2가지가 존재했고(AS2를 통과 또는 우회),
뜨거운 감자 라우팅이 바로 사용된다면 BGP는 AS2를 통과하는 경로로 패킷을 보내야 한다.

하지만 위의 경로 선택 알고리즘에서 규칙 2가 규칙 3보다 먼저 적용되므로, 더 짧은 AS-PATH를 가진 AS2 우회 경로가 선택된다.

따라서 이는 더이상 이기적인 알고리즘이 아니며, 결과적으로 종단 간 지연 시간이 줄어들 것이다.

5.4.4 IP 애니캐스트

BGP는 IP 애니캐스트(anycast) 서비스를 구현하는 데도 활용된다.

[참고] 애니캐스트(anycast) : 송신노드가 네트워크에 연결된 수신 가능한 노드 중에서 가장 가까운 한 노드에만 데이터를 전송한다. (IPv6 기반으로 작동)

많은 애플리케이션에서 (1) 같은 콘텐츠를 지리적으로 분산된 다른 많은 서버에 복제하고,
(2) 각 사용자를 가장 가까운 서버의 콘텐츠로 접근하게 하려고 하는 경우를 생각해보자.

e.g., CDN은 비디오 등을 각기 다른 나라의 서버들에 복제해두며, DNS 시스템도 DNS 정보를 전 세계 DNS 서버에 복제할 수 있다.

이 경우, BGP의 경로 선택 알고리즘을 사용할 수 있다.

아래 그림은 사용자를 가장 가까운 CDN 서버로 보내기 위한 IP 애니캐스트의 활용을 보여주는 그림이다.

IP 애니캐스트 설정 단계에서
(1) CDN 사업자가 자신의 서버 여러 대에 동일한 IP 주소를 할당하고
(2) 표준 BGP를 활용하여 이 주소를 서버 각각으로부터 알린다.
- 라우터가 이 IP 주소에 대한 복수 개의 경로 알림 메시지를 받으면
  이를 동일한 물리적 위치로의 서로 다른 경로에 대한 정보를 제공받고 있는 것으로 생각한다.
- 실제로는 서로 다른 물리적 위치로 가는 서로 다른 경로다.
각 라우터는 라우팅 테이블을 설정하면서 BGP 경로 선택 알고리즘을 수행하여 해당 IP 주소로의 최고의 경로를 골라낸다.

이러한 최초의 BGP 주소 알림 단계 이후에 CDN는 콘텐츠 배포를 할 수 있다.

사용자가 비디오를 요청하면 CDN은 사용자가 어디에 위치해 있든 상관없이
지리적으로 분산되어 있는 서버들이 공통적으로 사용하는 IP 주소를 사용자에게 돌려준다.
사용자가 그 주소로 요청을 보내면 인터넷 라우터는 그 요청 패킷을 BGP 경로 선택 알고리즘이 정의한 가장 ‘가까운’ 서버로 전달한다.

실제로는 BGP 라우팅이 변경되면 하나의 TCP 연결에 속한 패킷들이 서로 다른 복제 웹 서버로 도착될 수 있기 때문에
CDN은 위의 예처럼 IP 애니 캐스트를 사용하지 않으며,

DNS 시스템에서는 DNS 질의를 가장 가까운 루트 DNS 서버로 전달하기 위해 IP 애니캐스트를 광범위하게 사용된다.

5.4.5 라우팅 정책

라우터가 목적지까지의 경로를 선택하려고 할 때
AS 라우팅 정책은 최단 AS-PATH나 뜨거운 감자 라우팅 등의 다른 모든 고려사항보다 우선시된다.

아래 그림에서는 A, B, C, W, X, Y 이렇게 6개의 자율 시스템(AS)이 서로 연결되어 있다.

W, X, Y는 사용자 접속 ISP
A, B, C는 백본 제공자 네트워크
- 트래픽을 서로에게 직접 보낸다.
- 그들의 사용자 네트워크에 완전한 BGP 정보를 제공한다.

ISP 접속 네트워크로 들어오는 모든 트래픽은 그 네트워크를 목적지로 해야만 하고,
ISP 접속 네트워크에서 나가는 트래픽은 그 네트워크 안에서 생성된 것이어야만 한다.

W와 Y는 명백히 접속 ISP다.
X는 각기 다른 두 제공자를 통해 네트워크의 다른 부분들과 연결되어 있으므로 다중 홈 접속 ISP(multi-homed access ISP)라고 한다.

X도 W나 Y처럼 자신에게 들어오고 나가는 모든 트래픽의 목적지 또는 출발지여야 한다.

이 접속 네트워크의 동작을 구현하고 강제하며, X가 B와 C간 트래픽을 전달하는 것을 방지하는 것은
BGP 경로의 알림 방식을 제어하는 것으로 가능하다.

즉, X는 이웃인 B와 C에게 자기 자신을 제외하고는 다른 어떤 목적지로도 경로가 없다고 알리는 것이다.
(X가 Y까지 가는 XCY라는 경로를 알고 있더라도 이 경로를 B에게 알리지 않음)

따라서 B는 X가 Y로의 경로를 갖고 있음을 모르기 때문에 C 또는 Y로 가야 하는 트래픽을 X에게 절대 전달하지 않을 것이다.

서비스 제공자 네트워크 B는 (A로부터) A가 W까지의 경로 AW를 갖고 있음을 알게 되었다고 가정하자.

그러면 B는 경로 AW를 자신의 라우팅 정보 테이블에 기록하고,
자신의 고객인 X가 B를 통해 W로 갈 수 있음을 알게 하기 위해 경로 BAW를 X에게 알리길 원할 것이다.

하지만 B는 C에게도 BAW 경로를 알려야 할까?

만약 그렇게 한다면, C는 해당 경로를 통해 W까지 트래픽을 보낼 수 있게 되는데,
A, B, C가 모두 백본 제공자라면 B는 당연히 A와 C 사이의 트래픽을 전달하는 짐을 져서는 안 된다고 생각할 것이다.

현재는 백본 ISP들 사이의 경로를 결정하는 방법에 대한 공식적인 표준은 없지만,

상업적 ISP들이 따르는 대략적인 규칙은
ISP 백본 네트워크를 통해 흐르는 트래픽은 해당 ISP의 고객 네트워크를 출발지로 하거나 목적지로 해야 한다는 것이다(또는 둘 다).

개별적인 상호 협정은 전통적으로 두 ISP 간에 협상되고 종종 기밀사항이다.

왜 AS 간 라우팅과 AS 내부 라우팅 프로토콜이 다를까?

이는 AS 내부 라우팅과 AS 간 라우팅의 목적의 차이에 있다.

정책

AS 간 라우팅은 정책 이슈가 지배한다.

특정 AS에서 시작된 트래픽이 다른 특정 AS를 통과할 수 없다는 것은 중요할 수 있으며,
특정 AS가 다른 AS들 사이에서 어떤 트래픽을 전달할지 결장할 수 있기를 원하는 것 역시 당연하다.

반면, 하나의 AS 안에서는 모든 것이 동일한 관리 통제하에 있으므로 정책 문제는 경로 선택에 그리 중요하지 않다.

확장성

AS 간 라우팅에서 수많은 네트워크로, 또는 네트워크 간 경로 설정을 처리하기 위한 라우팅 알고리즘과 자료 구조의 능력은 매우 중요한 문제다.

반면, 한 AS 내에서는 확장성이 중요하지 않다.

하나의 ISP가 너무 커지면 이를 2개의 AS로 분리하고, 이 새로운 두 AS 사이에서 AS 간 라우팅을 수행할 수 있다.
(OSPF가 하나의 AS를 여러 영역으로 나눔으로써 계층을 만드는 것을 허용함)

성능

AS 간 라우팅은 정책 지향형이므로 사용하는 라우터의 품질(e.g., 성능)은 부수적인 관심사에 지나지 않는다.

단일 AS에서는 이러한 정책의 고려가 중요하지 않으므로, 경로의 성능 수준에 좀 더 초점을 두고 라우팅을 한다.

5.4.6 조각 맞추기: 인터넷 존재 확인하기

이 절은 본질적으로 BGP에 관한 내용은 아니지만,
IP 주소체계, DNS, BGP를 포함하여 지금까지 살펴본 많은 프로토콜과 개념을 한데 모은다.

작은 회사를 설립했다고 가정하다.

회사에는 회사의 제품과 서비스를 설명하는 공개 웹 서버, 메일 서버, DNS 서버를 포함한 많은 서버가 있다.

먼저 지역 ISP와 계약하여 인터넷 연결을 해야 한다.
- 회사는 게이트웨이 라우터를 갖게 될 텐데, 이는 지역 ISP의 라우터에 연결될 것이다.
- 지역 ISP는 특정 범위의 IP 주소를 제공한다. (e.g., 256개의 주소를 포함하는 /24 주소 범위)
- 물리적 연결과 IP 주소 범위를 가지면
  회사의 웹 서버, 메일 서버, DNS 서버, 게이트웨이 라우터와 다른 서버 및 네트워킹 장치들에 IP 주소(주소 범위에서)를 할당해야 한다.

회사의 도메인 이름(e.g., xanadu.com)을 얻기 위해 인터넷 등록 기관과 계약을 해야 하며, DNS 시스템에 등록해야 한다.
- 회사의 DNS 서버의 IP 주소를 등록 기관에 제공해야 한다.
- 그러면 등록 기관은 .com 최상위 도메인 서버에 회사의 DNS 서버(도메인 이름과 해당 IP 주소)를 추가한다.

사람들이 회사의 웹 서버 IP 주소를 검색할 수 있도록
회사의 DNS 서버에 웹 서버의 호스트 이름(e.g., www.xanadu.com)과 IP 주소의 사상 항목을 포함시켜야 한다.
(메일 서버를 포함하여 회사의 공개적으로 사용 가능한 다른 서버들에 대해서도 유사한 항목들을 가져야 한다.)
- 만일 앨리스라는 사람이 회사의 웹 서버를 방문하기를 원하는 경우,
  1. DNS 시스템은 회사의 DNS 서버에 접촉하여 웹 서버의 IP 주소를 알아낸 후
  2. 이를 앨리스에게 제공한다.
- 이제 앨리스는 회사의 웹 서버에 직접적으로 TCP 연결을 설립할 수 있다.

전 세계의 외부인이 회사의 웹 서버에 접근할 수 있도록 하기 위해서는
라우터가 회사 주소 범위에 해당하는 IP 주소 프리픽스 24비트(또는 다른 길이의 엔트리)의 존재를 알고 있어야 한다.
- 예시 상황
  1. 회사의 웹 서버의 IP 주소를 알아낸 앨리스가 그 IP 주소로 IP 데이터그램(e.g., TCP SYN 세그먼트)을 보낸다.
  2. 이 데이터그램은 인터넷을 통해 라우팅되어 여러 자율 시스템의 라우터들을 연속적으로 거친 후 마침내 웹 서버에 도착하게 된다.
    - 라우터들 각각은 이 데이터 그램을 수신하면,
      어느 출력 포트로 내보내야 하는지 결정하기 위해 자신의 포워딩 테이블에서 해당 엔트리를 찾는다.
- 이는 BGP를 통해서 이루어지게 된다.
  - 회사가 지역 ISP와 계약하고 주소 프리픽스(즉, 주소 범위)를 할당 받을 때,
    지역 ISP는 BGP를 사용하여 자신과 연결되어 있는 ISP들에게 회사의 주소 프리픽스를 알린다.
  - 연결된 ISP들 역시 BGP를 활용하여 이 알림 정보를 전파한다.

Chapter 4 - 4. 일반화된 포워딩 및 소프트웨어 기반 네트워크(SDN), 5. 미들 박스, Chapter 5 - 1. 개요

ssun_bear — Tue, 9 Jul 2024 20:31:31 +0900

4.4 일반화된 포워딩 및 소프트웨어 기반 네트워크(SDN)

목적지 IP 주소를 찾은(매치) 후 패킷을 스위치 구조로 지정된 출력 포트로 전송(액션)하는 두 단계의 목적지 기반 포워딩을 앞서 설명했다.

프로토콜 스택의 다른 계층에서 다른 프로토콜과 관련된 여러 헤더 필드에 대해 매치를 수행할 수 있는 일반적인 매치 플러스 액션 방법을 생각해보자.

액션은 하나 이상의 출력 포트로 패킷을 전달하고, 인터페이스에서 나가는 패킷을 로드 밸런싱(load balancing)하고 헤더값을 다시 쓰고, 의도적으로 패킷을 차단/삭제 및 추가 처리 작업을 위해 특수 서버로 패킷을 보내는 등의 작업을 수행한다.

일반화된 포워딩에서는 각각의 패킷 스위치는 원격 컨트롤러에 의해 계산 및 분포된 매치 플러스 액션 테이블을 포함하고 있다.

위 그림은 매치 플러스 액션 테이블을 보여준다.

OpenFlow 1.0

명확하고 간결한 방식으로 SDN 개념 및 기능을 도입한 OPenFlow 1.0을 살펴보자.

OpenFlow의 플로우 테이블로 알려진 매치 플러스 액션 포워딩 테이블의 각 엔트리는 다음을 포함한다.

들어오는 패킷에 대한 헤더값들의 세트가 매치될 것이다. 하드웨어 기반 매치는 TCAM 메모리에서 가장 신속하게 수행되며, 백만 개가 넘는 목적지 주소를 동반한다. 플로우 테이블 엔트리와 매치되지 않는 패킷은 더 많은 처리를 위해 원격 컨트롤러로 전송될 수 있다.
패킷들에 의해 갱신되는 카운터 세트는 플로우 테이블 엔트리들과 매치된다. 이러한 카운터는 플로우 테이블 엔트리와 마지막으로 갱신된 테이블 엔트리 이후에 매치된 다수의 패킷을 포함하고 있다.
패킷이 플로우 테이블 엔트리와 매치될 때 여러가지 액션이 가능해진다. 이러한 액션은 패킷을 지정된 출력 포트로 전달하고, 패킷을 삭제하고, 패킷의 복사본을 만들어 여러 출력 포트로 보내거나 선택한 헤더 필드를 다시 쓰는 것일 수 있다.

4.4.1 매치

위 그림은 OpenFlow 1.0 매치 플러스 액션 규칙에서 매치될 수 있는 11개의 패킷 헤더 필드와 수신 포트 ID를 보여준다.

진입 포트는 패킷이 수신되는 패킷 스위치의 입력 포트를 나타낸다.

플로우 테이블 엔트리에는 와일드카드도 있을 수 있다. 예를 들어, 플로우 테이블의 128.119.*.* 의 주소는 128.119를 주소의 첫 번째 16 비트로 갖는 데이터그램의 해당 주소 필드와 매치된다.

또한 각 플로우 테이블 엔트리에는 우선순위가 있어 여러 플로우 테이블 엔트리와 매치되면, 선별된 매치 엔트리에 해당하는 패킷이 가장 높은 우선순위가 된다.

IP 헤더의 모든 필드가 매치될 수 있는 것은 아니다.

예를 들어 OpenFlow에서는 TTL 필드 또는 데이터그램 길이 필드에 기반한 매치를 허용하지 않는다.

4.4.2 액션

플로우 테이블 엔트리는 플로우 테이블 엔트리와 매치되는 패킷 처리를 결정하는 0개 이상의 액션 목록을 갖고 있다.

여러 액션이 있는 경우 목록에 지정된 순서대로 수행된다.

가장 중요한 액션들은 다음과 같다.

포워딩
- 들어오는 패킷은 특정 실제 출력 포트로 전달되거나 모든 포트를 통해 브로드캐스트되거나 선택된 포트 세트를 통해 멀티캐스트될 수 있다.
- 패킷은 캡슐화되어 원격 컨트롤러로 전송될 수 있다.
- 컨트롤러는 새 플로우 테이블 엔트리를 설치하고 해당 패킷에 대한 조치를 취하거나 갱신된 플로우 테이블 규칙에 따라 포워딩을 위해 패킷을 장치로 반환할 수 있다.
삭제
- 아무 액션이 없는 플로우 테이블 엔트리는 매치된 패킷을 삭제해야함을 나타낸다.
필드 수정
- 패킷이 선택된 출력 포트로 전달되기 전에 10개의 패킷 헤더 필드의 값을 다시 쓸 수 있다.

4.4.3 매치 플러스 액션 작업의 OpenFlow 예

위 그림의 상황을 가정하고 다음 예시들을 보자.

첫 번째 예: 간단한 포워딩

아주 간단한 예로 포워딩 동작이 h3 또는 h4로 예정된 h5 또는 h6 패킷이 s3에서 s1으로 전달된 다음 s1에서 s2로 전달된다고 가정한다.

위 상황에서 s1의 플로우 테이블 엔트리는 다음과 같다.

s3에 플로우 테이블 엔트리가 필요하므로 h5 또는 h6에서 전송된 데이터그램은 인터페이스 3을 통해 s1으로 전달된다.

마찬가지로, s1에 도착한 데이터그램을 호스트 h3 또는 h4로 전달할 수 있도록 s2에 플로우 테이블 엔트리가 필요하다.

위를 바탕으로 직접 채워보길 바란다.

두번째 예: 로드 밸런싱

두 번째 예로 h3에서 10.1.*.*로 향하는 데이터그램이 s2와 s1 사이의 링크를 통해 전달되는 반면, h4에서 10.1.*.* 로의 데이터그램은 s2와 s3 사이의 링크를 통해 전달되는 로드 밸런싱 시나리오를 고려해보자.

이 동작은 IP의 목적지 기반 포워딩으로 수행될 수 없다.

이 경우 s2의 포워딩 테이블은 다음과 같다.

s2에서 수신한 데이터그램을 h1 또는 h2로 전달하려면 s1에서 플로우 테이블 엔트리가 필요하다.

인터페이스 4에서 수신한 데이터그램을 s3에서 인터페이스 3을 통해 s1로 전달하려면 s3에서 플로우 테이블 엔트리가 필요하다. s1및 s3에서 이러한 플로우 테이블 엔트리를 파악할 수 있는지 확인하자.

세번째 예: 방화벽

s2가 s3에 연결된 호스트에서 보낸 트래픽만 수신하려고 하는 방화벽 시나리오를 생각해보자.

s2 플로우 테이블에 다른 엔트리가 없으면 10.3.*.*의 트래픽만 s2에 연결된 호스트로 전달된다.

매치 플러스 액션 플로우 테이블은 제한된 형태의 프로그래밍 가능성이다.

데이터그램의 헤더값과 매치 조건 사이의 매치를 기반으로 라우터가 데이터그램을 전달하고 조작하는 방법을 명시한다.

따라서 더 풍부한 형태의 프로그래밍 가능성을 상상할 수 있다.

4. 5 미들박스

미들 박스의 정의

출발지 호스트와 목적지 호스트 사이의 데이터 경로에서 IP 라우터의 정상적이고 표준적인 기능과는 별도로 기능을 수행하는 모든 미들박스

미들 박스가 수행하는 세 가지 유형의 서비스를 광범위하게 식별할 수 있다.

NAT 변환 : NAT 박스는 사설 네트워크 주소체계를 구현하여 데이터그램 헤더 IP 주소 및 포트 번호를 다시 작성한다.
보안 서비스 : 방화벽은 헤더 필드 값을 기준으로 트래픽을 차단하거나 DPI(Deep Packet Inspection) 같은 추가 처리를 위해 패킷을 리다이렉션한다. 침입 탐지 시스템(IDS)은 미리 결정된 패턴을 탐지하고 그에 따라 패킷을 필터링할 수 있다.
성능 향상 : 미들박스는 압축과 같은 서비스를 수행한다. 즉, 원하는 서비스를 제공할 수 있는 서버 집합 중 하나에 대한 서비스 요청의 로드 밸런싱을 하는 주체다.

미들 박스는 네트워크 계층과 트랜스포트계층, 애플리케이션 계층을 명확히 구분하는 이전 네트워크의 분리를 명백히 위반한다.

예를 들어, 라우터와 호스트 사이에 위치한 NAT 박스는 네트워크 계층 IP 주소와 트랜스포트 계층 포트 번호를 다시 쓴다.

네트워크 내의 방화벽 블록은 IP 데이터그램 헤더 뿐만 아니라 애플리케이션 계층, 트랜스포트 계층 헤더까지 사용하여 데이터그램을 의심한다.

미들박스를 아키텍처적으로 혐오스럽다고 간주하는 사람들도 있지만, 다른 이들은 이러한 미들 박스가 '중요하고 영구적으로 존재한다'는 철학을 채택하고 있다.

5.1 개요

포워딩 테이블(목적지 기반 포워딩의 경우)과 플로우 테이블(일반화된 포워딩의 경우)이 네트워크 계층의 데이터 평면과 제어 평면을 연결하는 수요 요소였는데,
이 테이블들이 라우터의 로컬 데이터 평면에서의 포워딩을 지정했다.

바로 이전 장에서의 그림을 상기해보자.

일반화된 포워딩의 경우에 라우터가 취하는 행동은 다양한 형태로 나타날 수 있었다.

라우터의 출력 포트로 패킷을 전달
패킷을 버리거나 복제
2, 3, 4계층의 헤더 필드를 재작성

이 장에서는 포워딩 테이블이나 플로우 테이블이 어떻게 만들어지고 유지 및 설치되는지를 알아볼 것이다.

라우터별 제어

개별 라우팅 알고리즘들이 제어 평면에서 상호작용한다.

아래 그림은 라우팅 알고리즘들이 모든 라우터 각각에서 동작하는 경우를 나타낸다.

포워팅과 라우팅 기능이 모두 개별 라우터에 포함되어 있다.
각 라우터는 다른 라우터의 라우팅 구성요소와 통신하여 자신의 포워딩 테이블의값을 계산하는 라우팅 구성요소를 갖고 있다.
OSPF, BGP 프로토콜이 이 라우터별 제어 방식을 기반으로 한다.

논리적 중앙 집중형 제어

일반적으로 원격에 위치한 별개의 컨트롤러가 지역의 제어 에이전트(CA)와 상호작용한다.

아래 그림은 논리적 중앙 집중형 컨트롤러가 포워딩 테이블을 작성하고, 이를 모든 개별 라우터가 사용할 수 있도록 배포한 경우를 나타낸다.

일반화된 ‘매치 플러스 액션(match plus action)’ 추상화를 통해
라우터는 기존에는 별도로 장치로 구현되었던 다양한 기능(부하 분산, 방화벽, NAT) 뿐만 아니라 전통적인 IP 포워딩을 수행할 수 있다.

컨트롤러는 프로토콜을 통해 각 라우터의 제어 에이전트(control agent, CA)와 상호작용하여 라우터의 플로우 테이블을 구성 및 관리한다.

라우터별 제어 방식과는 다르게, CA는 서로 직접 상호작용하지 않으며, 포워딩 테이블을 계산하는 데도 적극적으로 참여하지 않는다.

Chapter 4 - 1. 네트워크 계층 개요, 2. 라우터, 3. 인터넷 프로토콜(IP)

ssun_bear — Tue, 9 Jul 2024 20:22:26 +0900

4.1 네트워크 계층 개요

두 호스트 H1과 H2가 있을 때, 네트워크 계층은 두 호스트 중 하나의 트랜스포트 계층 세그먼트를 추출하여 H2의 트랜스포트 계층까지 전달하는 역할을 한다.

라우터는 트랜스포트 계층과 애플리케이션 계층을 지원하지 않으므로 프로토콜 스택에서 네트워크 계층의 상위 계층은 존재하지 않는다.

각 라우터에는 데이터 평면과 제어 평면이 존재한다.

데이터 평면 : 입력 링크에서 출력 링크로 데이터그램을 전달한다.
제어 평면 : 데이터그램이 출발지 호스트에서 목적지 호스트까지 전달되게끔 로컬 포워딩, 라우터별 포워딩을 대응시킨다.

4.1.1 포워딩과 라우팅: 데이터 평면과 제어 평면

네트워크 계층의 근본적인 역할은 송신 호스트에서 수신 호스트로 패킷을 전달하는 것이다.

위 역할을 위한 중요한 기능 두 가지

포워딩(전달) : 패킷이 라우터의 입력 링크에 도달했을 때 라우터는 그 패킷을 적절한 출력 링크로 이동시켜야한다. 포워딩에서 예외적으로 한 기능은 데이터 평면에서 실행된다. 매우 짧은 시간 단위(보통 몇 나노초)를 갖기에 대표적으로 하드웨어에서 실행된다.
라우팅 : 송신자가 수신자에게 패킷을 전송할 때 네트워크 계층은 패킷 경로를 결정해야 한다. 이러한 경로를 계산하는 알고리즘을 라우팅 알고리즘이라고 한다. 네트워크 전반에 걸쳐 출발지에서 목적지까지 데이터그램의 종단 간 경로를 결정하여 시간이 오래걸려 소프트웨어에서 실행된다.

포워딩 테이블

라우터는 도착하는 패킷 헤더의 필드값을 통해 포워딩 테이블의 내부 색인으로 사용하여 패킷을 전달한다.

포워딩 테이블 엔트리에 저장되어 있는 헤더의 값은 해당 패킷이 전달되어야 할 라우터의 외부 링크 인터페이스를 나타낸다.

제어 평면: 전통적인 접근 방법

라우팅 알고리즘은 각각의 모든 라우터에서 실행되며, 라우터는 포워딩과 라우팅 기능을 모두 갖고 있어야 한다.

또한, 한 라우터의 라우팅 알고리즘 기능은 다른 라우터의 라우팅 알고리즘과 소통하며 포워딩 테이블의 값을 계산한다.

이러한 소통은 라우팅 프로토콜에 따라 라우팅 정보에 포함된 라우팅 메시지를 교환하며 이루어진다.

(더 자세한 내용은 5장에서 다룬다.)

제어 평면: SDN 접근 방법

위 그림은 라우터로부터 물리적으로 분리된 원격 컨트롤러 컴퓨터와 각각의 라우터에 의해 사용될 포워딩 테이블을 분배하는 다른 접근법을 보여준다.

라우터는 원격 컨트롤러와 포워딩 테이블과 그 밖의 라우팅 정보를 포함한 메시지를 교환함으로써 소통한다.

원격 컨트롤러가 포워딩 테이블을 계산 및 배분하는 동안 라우팅 기기는 포워딩만을 수행한다.

즉, 네트워크가 소프트웨어적으로 정의되었을 때 포워딩 테이블을 계산하는 컨트롤러는 라우터와 상호작용을 하며 소프트웨어에서 실행된다.

이렇게 원격 컨트롤러가 라우터와 떨어져서 높은 신뢰성과 중복성을 갖춘 원격 데이터 센터에 위치하는 접근 방법은 SDN(software defined networking)의 중심이다.

(더 자세한 내용은 5장에서 다룬다.)

4.1.2 네트워크 서비스 모델

네트워크 계층 제공 서비스

보장된 전달: 이 서비스는 패킷이 출발지 호스트에서부터 목적지 호스트까지 도착하는 것을 보장한다.
지연 제한 이내의 보장된 전달: 이 서비스는 패킷의 전달을 보장할 뿐만 아니라 호스트 간의 특정 지연 제한(예: 100ms 이내) 안에 전달한다.
순서화 패킷 전달: 이 서비스는 패킷이 목적지에 송신된 순서대로 도착하는 것을 보장한다.
최소 대역폭 보장: 이 네트워크 계층 서비스는 송신과 수신 호스트 사이에 특정한 비트율의 전송 링크를 에뮬레이트한다. 송신 호스트가 비트들을 특정한 비트율 이하로 전송하는 한, 모든 패킷이 목적지 호스트까지 전달된다.
보안 서비스: 네트워크 계층은 모든 데이터 그램을 출발지 호스트에서는 암호화, 목적지 호스트에서는 복호화할 수 있게 하여 트랜스포트 계층의 모든 세그먼트에 대해 기밀성을 유지해야한다.

이 외에도 수많은 변형들이 있다.

인터넷 네트워크 계층은 최선형 서비스(best-effort service) 라고 알려진 서비스를 제공한다.

최선형 서비스의 특징

패킷을 보내는 순서대로 수신됨을 보장하지 않는다.
목적지까지 패킷이 전송됨을 보장하지 않는다.
종단 시스템 간 지연이 보장되지 않는다.
보장된 최소 대역폭이 없다.

이렇게 서비스를 제공하지 못하는 인터넷 네트워크 계층의 대안으로 좋은 보다 서비스 모델을 정의하고 구현했지만 인터넷 네트워크 계층은 놀라운 범위의 애플리케이션을 가능하게 할만큼 충분히 좋다고 입증되었다.

4장 개요

4장에서는 네트워크 계층 데이터 평면의 구성요소를 살펴본다.

4.2 라우터 내부에는 무엇이 있을까?

위 그림을 라우터의 구조를 나타낸다.

입력 포트
- 입력 포트의 맨 왼쪽과 맨 오른쪽 박스는 라우터로 들어오는 입력 링크로, 물리 계층 기능을 수행한다.
- 또한 입력 포트는 들어오는 링크의 반대편에 있는 링크 계층과 상호 운용하기 위해 필요한 링크 계층 기능을 수행한다. 이것은 입력 및 출력 포트에서 미들박스로 표시된다.
- 가장 중요한 기능은 입력 포트의 가장 오른쪽에서 수행되는 검색 기능이다. 여기서 포워딩 테이블을 참조하여 도착된 패킷이 스위치 구조를 통해 라우터 출력 포트를 결정한다.
- 라우팅 프로토콜 정보를 전달하는 패킷인 제어 패킷은 입력 포트에서 라우팅 프로세서로 전달된다.
- 여기서의 포트는 앞에서 언급한 포트와는 다르다.
스위치 구조
- 스위치 구조는 라우터의 입력 포트와 출력 포트를 연결한다.
- 라우터 내부에 포함되어 있다.
출력 포트
- 출력 포트는 스위치 구조에서 수신한 패킷을 저장하고 필요한 링크 계층 및 물리 계층 기능을 수행하여 출력 링크로 패킷을 전송한다.
- 링크가 양방향일 경우 출력 포트는 일반적으로 동일한 링크의 입력 포트와 한 쌍을 이룬다.
라우팅 프로세서
- 제어평면 기능을 수행한다.
- 전통적인 라우터에서는 라우팅 프로토콜을 실행하고 라우팅 테이블과 연결된 링크 상태 정보를 유지 관리하며 라우터의 포워딩 테이블을 계산한다.
- SDN 라우터에서 라우팅 프로세서는 원격 컨트롤러와 통신하여 원격 컨트롤러에서 계산된 포워딩 테이블 엔트리를 수신하고 라우터의 입력 포트에 이러한 엔트리를 설치한다.
- 네트워크 관리 기능을 수행한다.

라우터의 입력 포트, 출력 포트, 스위치 구조는 거의 항상 하드웨어로 구현된다.

제어 평면은 일반적으로 소프트웨어로 구현되며 라우팅 프로세서(일반적으로 기존 CPU)에서 실행된다.

4.2.1 입력 포트 처리 및 목적지 기반 전송

입력 포트의 기능은 위에서 언급한 바와 같다.

입력 포트에서 수행되는 검색은 라우터 동작의 핵심이다.

라우터는 포워딩 테이블을 사용하여 도착 패킷이 스위치 구조를 통해 전달되는 출력 포트를 검색한다.

포워딩 테이블은 라우팅 프로세서에서 계산되거나 갱신되거나 원격 SDN 컨트롤러에서 수신된다.

포워딩 테이블은 라우팅 프로세서에서 맨위 그림과 같이 각 라인 카드로 복사되고, 이렇게 각 라인이 복사본을 사용하여 패킷 단위로 중앙 집중식 라우팅 프로세서를 호출하지 않게 되어 병목 현상을 피할 수 있다.

목적지 주소 범위 포워딩 테이블

32비트의 IP 주소의 경우 포워딩 테이블을 억지로 구현한다면 모든 가능한 목적지 주소마다 하나의 엔트리가 필요하고, 이는 40억개 이상의 주소가 있어야 하므로 불가능하다.

라우터에서 0에서 3까지의 4개의 링크가 있다고 가정해보자.

목적지 주소 범위로 포워딩 테이블을 구성할 경우 4개의 엔트리를 갖는 포워딩 테이블이면 된다.

프리 픽스 포워딩 테이블

이런 형식의 포워딩 테이블에서 라우터는 패킷의 목적지 주소의 프리픽스(prefix)를 테이블의 엔트리와 매치한다.

예를 들어, 패킷의 목적지 주소가 11001000 00010111 00010110 10100001 라면 앞 21개의 비트 프리픽스가 테이블의 첫 번째 엔트리와 매치되므로 라우터는 이 패킷을 링크 인터페이스 0으로 보낸다.

11001000 00010111 00011000 10101010와 같이 처음 24비트는 2번째에 처음 21비트는 3번째에 매치되는 경우 라우터는 최장 프리픽스 매치 규칙(longest prefix matching rule)을 사용한다.

즉, 테이블에서 가장 긴 매치 엔트리를 찾고, 여기에 연관된 링크 인터페이스로 패킷을 보낸다. (이유에 대해서는 4.3절에서 다룬다.)

이러한 테이블 설계 뿐만 아니라 검색은 나노초 단위로 수행되어야 하므로 이외의 기술이 필요하다.

메모리 접속 시간에 특별한 주의를 기울여야하므로 내장형 DRAM과 빠른 SRAM 메모리가 있는 설계가 필요하다. 실제로 TCAM도 검색을 위해 자주 사용된다.

검색을 통해 패킷의 출력 포트가 결정되면 패킷을 스위치 구조로 보낼 수 있다. 일부 설계에서는 다른 입력 포트로부터 패킷이 현재 구조를 사용하고 있다면 패킷이 스위칭 구조에 들어가는 것을 일시적으로 차단할 수 있다.

앞으로 패킷의 차단, 큐잉, 스케줄링에 대해 자세히 살펴본다.

4.2.2 스위칭

스위치 구조는 패킷이 입력 포트에서 출력 포트로 실제로 스위칭 되는 구조를 통과하므로 라우터의 핵심이다.

여기서는 여러가지 스위칭 방법을 설명한다.

메모리를 통한 교환

초기의 라우터는 라우터 프로세서를 직접 제어해서 입력 포트와 출력 포트 사이에서 패킷을 스위칭하는 전통적인 컴퓨터다. 입력 포트와 출력 포트는 I/O 장치처럼 작동한다.

패킷 전달 과정

패킷이 도착하면 입력 포트는 라우팅 프로세서에게 인터럽트를 보내 패킷을 프로세서 메모리에 복사한다.
라우팅 프로세서는 헤더에서 목적지 주소를 추출한다.
포워딩 테이블에서 적절한 출력 포트를 찾은 다음 패킷을 출력 포트의 버퍼에 복사한다.

위 과정에서 메모리 대역폭이 초당 최대 B인 패킷을 메모리에 쓰거나 메모리에서 읽을 수 있는 경우 전체 전달 처리량은 B/2 보다 작아야하며 목적지 포트가 다른 경우라도 공유 시스템 버스를 통해 한 번에 하나의 메모리 읽기/쓰기 작업을 수행할 수 있기 때문에 두 패킷을 동시에 전달할 수 없다.

최근의 메모리를 통해 스위칭하는 라우터는 목적지 주소를 검색하고 해당 메모리 위치에 패킷을 저장하는 것이 입력 라인 카드에서 처리함으로써 수행한다.

버스를 통한 교환

입력 포트는 라우팅 프로세서의 개입 없이 공유 버스를 통해 직접 출력 포트로 패킷을 전송한다.

일반적으로 미리 준비된 입력 포트 스위치 내부 레이블이 로컬 출력 포트를 나타내는 패킷에게 전송되거나 버스에 패킷을 전송하여 수행된다.

모든 출력 포트에 패킷이 수신되지만 레이블과 매치되는 포트만 패킷을 유지한다.

레이블은 버스를 통과하기 위해서만 사용되므로 출력 포트에서 제거된다.

동시에 여러 패킷이 다른 입력 포트에 있는 라우터에 도착하면 한 번에 하나의 패킷만 버스를 통과할 수 있기 때문에 하나를 제외한 모든 패킷이 대기 해야한다.

모든 패킷이 하나의 버스를 통과해야하므로 라우터의 교환 속도는 버스 속도에 의해 제한된다.

상호 연결 네트워크를 통한 교환

크로스바 스위치는 N개의 입력 포트를 N개의 출력 포트에 연결하는 2N 버스로 구성된 상호연결 네트워크다.

각 수직 버스는 교차점에서 각 수평 버스와 교차하며 스위치 구조 컨트롤러에 의해 언제든지 열거나 닫을 수 있다.

이를 통해 앞의 두가지 방식과 달리 크로스바 스위치는 여러 패킷을 병렬로 전달할 수 있다.

그러나 두개의 서로 다른 입력 포트에서 나오는 2개의 패킷이 동일한 출력 포트로 보내지는 경우 한번에 하나의 패킷만 특정 버스에서 전송될 수 있기 때문에 입력을 기다려야한다.

좀 더 정교한 상호연결 네트워크는 다단계 스위치 구조를 통해 각기 다른 입력 포트의 패킷이 동일한 출력 포트를 향해 동시에 전달할 수 있도록 여러 단계의 스위칭 요소를 사용한다.

4.2.3 출력 포트 처리

위 그림의 출력 포트 처리는 출력 포트의 메모리에 저장된 패킷을 가져와서 출력 링크를 통해 전송한다. 여기에는 전송을 위한 패킷 선택 및 큐 제거, 필요한 링크 계층 및 물리 계층 전송 기능을 수행하는 것이 포함된다.

어디에서 큐잉이 일어날까?

패킷 큐는 입력 포트와 출력 포트 모두에서 형성될 수 있다.

큐의 위치와 범위는 트래픽 로드, 스위치 구조의 상대 속도 및 라인 속도에 따라서 달라진다.

이 큐가 커지면 라우터의 메모리가 결국 소모될 수 있고 도착하는 패킷을 저장할 수 있는 메모리가 없을 때 패킷 손실이 발생한다.

입력 큐잉

지연 없이 구조를 통해 도착하는 모든 패킷을 전송하기에 스위치 구조가 충분히 빠르지 않으면 어떻게 될까?

이 경우에는 패킷이 스위치 구조를 통해 출력 포트로 전송되기 위해 차례를 기다려야한다.

이 큐잉의 결과를 살펴보기 위해 크로스바 스위치 구조를 가정해보자.

모든 링크의 속도는 같다.
입력 링크가 패킷을 받는 것과 같은 속도로 하나의 패킷을 입력 포트에서 주어진 출력 포트로 전달한다.
FCFS (First-Come-First-Served) 방식으로 패킷은 입력 큐에서 출력 큐로 이동된다.

출력 포트가 다르다면 여러 패킷이 병렬로 전달 가능하지만, 같다면 하나의 패킷만 지정된 출력 포트로 전송이 가능하고 나머지 패킷은 기다려야한다.

위 그림에서 왼쪽 상단 큐의 앞쪽에서 먼저 패킷을 전송한다고 가정해보자.

왼족 하단 큐의 가장 앞쪽의 패킷은 출력 포트가 같으므로 대기하여야하고, 두번째 패킷은 출력 포트가 다름에도 앞의 패킷 때문에 대기하여야한다.

이 현상은 입력 대기 중인 스위치에서의 HOL(Head-of-the-line) 차단 이라고 한다.

출력 큐잉

입력 포트와 출력 포트의 개수가 각각 N개이고 속도가 R이라 할 때, 스위치의 속도가 R보다 N배 빠르고 모든 입력 포트의 패킷이 동일한 출력 포트로 향한다고 가정해보자.

이 경우, 출력 링크에서 단일 패킷을 보내는 데 걸리는 시간에 N개의 새로운 패킷이 출력 포트에 도착한다. 출력 포트는 시간 단위에 단일 패킷만을 전송할 수 있기 때문에 N개의 도착 패킷은 출력 링크를 통한 전송 큐에서 대기 해야한다.

이때 큐의 공간이 충분하지 않을 때, 즉 메모리가 충분하지 않을 때 도착한 패킷을 삭제하거나 이미 대기 중인 하나 이상의 패킷을 제거하여 새로 도착한 패킷을 저장하기 위한 공간을 확보해야 한다.

위 그림은 출력 포트 큐잉의 예시이다.

이러한 큐잉의 결과는 출력 포트의 패킷 스케줄러가 전송 대기 중인 패킷 중 하나의 패킷을 선택하여 큐에서 제거 해야한다는 것이다. (다음 절에서 다룬다.)

얼마나 많은 버퍼가 요구되는가?

몇년 동안 RFC의 버퍼의 크기에 대한 규칙은 링크 용량이 C일 때, 버퍼링의 양은 평균 왕복 시간(RTT)와 같아야 한다는 것이다.

즉, B = RTT x C 와 같은 버퍼의 양이 필요하다.

최근의 실험과 이론에서는 많은 수의 독립적인 TCP 흐름 N이 링크를 통과할 때, 필요한 버퍼링은 B = RTT x C / √N 이라고 제안하고 있다.

버퍼링이 클수록 라우터가 패킷 도착 속도의 큰 변동을 흡수하여 라우터의 패킷 손실률을 감소 시킬 수 있기 때문에 버퍼링이 낫다고 생각하는 것보다 버퍼가 클수록 큐잉 지연이 길어진다고 생각하는 편이 좋다.

예를 들어, 패킷 손실을 줄이기 위해 홉당 버퍼의 양을 10배 늘리면 종단 간 지연이 10의 배만큼 증가한다.

즉, 버퍼의 크기 증가는 패킷 손실율을 줄일 수 있지만 종단 간 지연을 증가시킬 수 있는 양날의 검이다.

네트워크 가장자리의 라우터를 생각해보자.

a는 TCP 세그먼트를 원격 게임 서버로 보내는 홈 라우터에 대한 설명이다. 게이머의 TCP 세그먼트를 포함하는 패킷을 전송하는 데 20ms가 소요되며, 큐잉 지연이 무시해도 될 정도라고 가정한다.

게임 서버 경로의 다른 곳에서 지연되며 RTT는 200ms다.

b에서와 같이 t = 0 에서 25개 패킷의 버스트가 큐에 도착한다고 가정한다.

대기 중인 패킷들 중 하나는 20ms 마다 한 번씩 전송되므로, 21 번째 패킷이 전송되고 있는 것처럼 t = 200ms에서 첫 번째 ACK가 도착한다. 이 ACK 도착은 송신자가 다른 패킷을 보내게 한다.

홈 라우터의 송신 링크 t = 220에서 다음 ACK가 도착하고, 또 다른 ACK가 도착한다. TCP 세그먼트는 게이머에 의해 해제되며, 22번째 패킷은 전송되는 큐에 놓인다.

위 과정에서 ACK 클록은 대기 중인 패킷이 있을 때마다 새 패킷이 큐에 도착하게 되고, 전송되어 홈 라우터의 송신 링크에서 큐 크기가 항상 5 패킷이 된다.

즉, 종단 간 파이프는 꽉 찼지만 큐잉 지연의 양은 일정하고 지속적이다.

결과로 게이머는 홈 네트워크에 다른 트래픽이 존재하지 않는 경우에도 지연이 지속적으로 지나치게 긴 이유를 이해하지 못하게 된다.

이러한 지속적 버퍼링으로 인한 긴 지연에 대한 위 과정을 버퍼블로트(bufferbloat)라고 한다.

이를 극복하기 위해 6장에서 연구할 케이블 네트워크용 DOCIS 3.1 표준은 AQM 메커니즘을 추가하여 대량 처리 성능을 보존했다.

4.2.5 패킷 스케줄링

FIFO

링크가 현재 다른 패킷을 전송 중이면, 출력 링크 큐에 도착한 패킷은 전송을 기다린다.

도착한 패킷을 담을 버퍼 공간이 충분하지 않은 경우 도착 패킷의 공간을 확보하기 위해 큐의 패킷 폐기 정책은 패킷 손실 여부 또는 다른 패킷을 큐에서 제거할 것인지 여부를 결정한다.

FIFO 스케줄링 규칙은 출력 링크 큐에 도착한 순서와 동일한 순서로 출력 링크에서 전송할 패킷을 선택한다.

위 그림에서는 FIFO 큐의 동작을 보여준다.

우선순위 큐잉

우선순위 큐잉에서 출력 링크에 도착한 패킷은 우선순위 클래스로 분류된다.

실제로 네트워크 오퍼레이터는 네트워크 관리 정보를 운반하는 패킷이 사용자 트래픽보다 우선순위를 수신하도록 큐를 구성할 수 있다.

전송할 패킷을 선택할 때 전송 대기 중인 패킷으로 차 있는 상태이고 가장 높은 우선순위 클래스에서 패킷을 전송한다.

우선순위가 동일한 패킷들 중에서의 선택은 FIFO 방식으로 행해진다.

위 그림은 우선순위 클래스가 2개인 경우의 큐 동작을 보여준다.

패킷 1,3,4가 우선순위가 높기 때문에 먼저 전송된다.

이때는 비선점 우선순위 큐잉이기 때문에 패킷 4의 우선순위가 높더라도 패킷 2의 전송이 시작되면 선점하지 않고 전송이 끝난 후에야 전송이 시작된다.

라운드 로빈과 WFQ

라운드 로빈 큐잉 큐칙에서는 패킷은 우선순위 큐잉과 같이 클래스로 분류되지만 클래스 간에는 엄격한 서비스 우선순위가 존재하지 않으며, 라운드 로빈 스케줄러가 클래스 간에 서비스를 번갈아서 제공한다.

가장 단순한 라운드 로빈 스케줄링에서는 그저 클래스를 번갈아가면서 패킷을 전송한다.

작업 보존 큐잉 규칙의 경우 전송을 위해 큐에서 기다리는 패킷이 있다면 링크는 유휴 상태가 되는 것을 허용하지 않는다.

즉, 클래스에 패킷이 없다면 바로 시퀀스의 다음 클래스를 검사한다.

위 그림은 라운드 로빈 큐의 동작을 보여준다.

라우터에서 널리 구현된 라운드 로빈 큐잉의 일반화된 형태는 소위 WFQ(Weighted Fair Queueing) 규칙이다.

도착하는 패킷은 적절한 클래스별 대기 영역에서 분류되며 대기한다.

WFQ 스케줄러는 라운드 로빈과 같이 순환식으로 동작한다.

또한, 작업 보존 큐잉 규칙을 따른다.

WFQ는 각 클래스 i 는 가중치 w(i)를 할당 받는다.

WFQ에서는 전송할 클래스 i 패킷이 있는 동안에 클래스 i는 w(i) / ∑w(i) 만큼의 서비스 시간을 보장받으며, 이 식에서 분모 부분은 전송을 위해 큐에 패킷이 있는 모든 클래스의 합이다.

즉, 최악의 경우 모든 큐에 패킷이 있을 때도 위의 시간을 보장 받는다.

따라서 전송률 R인 링크에 대해 클래스 i는 항상 최소한 R x w(i) / ∑w(i)의 처리율을 갖는다.

패킷이 이상적인 단위 데이터라는 것과 패킷 전송이 다른 패킷을 전송하기 위해 방해되지 않는다는 사실을 고려하지 않았기 때문에 위 설명은 이상적이다.

4.3 인터넷 프로토콜(IP): IPv4, 주소체계, IPv6 등

4.3.1 IPv4 데이터그램 포맷

인터넷 네트워크 계층 패킷을 데이터그램(datagram)이라고 부른다.

IPv4 데이터그램 포맷

버전 번호
- 4비트로 데이터그램의 IP 프로토콜 버전을 명시한다.
- 라우터는 버전 번호를 확인하여 데이터그램의 나머지 부분을 어떻게 해석할지 결정한다.
- 다른 버전의 IP는 다른 데이터그램 포맷을 사용한다.
헤더 길이
- IPv4 데이터그램은 헤더에 가변 길이의 옵션을 포함하므로 이 네 비트로 IP 데이터그램에서 실제 페이로드가 시작하는 곳을 결정한다.
- 대부분의 IPv4는 옵션을 포함하지 않으므로 대체로 IPv4 데이터그램 헤더는 20바이트다.
서비스 타입
- IPv4 헤더에 포함된 서비스 타입 비트는 각기 다른 유형의 IP 데이터그램을 구별한다. 예를 들어, 실시간 데이터그램과 비실시간 트래픽을 구분하는 데 유용하다.
데이터그램 길이
- 바이트로 계산한 IP 데이터그램의 전체 길이다. 총 16비트를 차지하므로 IP 데이터그램의 최대 길이는 65,535 바이트이지만 1,500보다 큰 경우는 거의 없다.
식별자, 플래그, 단편화 오프셋
- IP 단편화와 관련이 있는 필드들이다.
- 큰 IP 데이터그램이 여러 개의 작은 IP 데이터그램으로 분할된 다음 목적지로 독립적으로 전달되며, 여기서 페이로드 데이터가 최종 호스트의 트랜스포트 계층으로 전달되기 전에 다시 모인다.
TTL(time to live)
- 이 필드는 네트워크에서 데이터그램이 무한히 순환하지 않도록 한다(라우팅 루프). 라우터가 데이터그램을 처리할 때마다 감소하고, 이 필드가 0이 되면 데이터그램을 폐기한다.
프로토콜
- 이 필드는 일반적으로 IP 데이터그램이 최종목적지에 도착했을 때만 사용된다. 이 필드값은 IP 데이터그램에서 데이터 부분이 전달될 목적지의 트랜스포트 계층의 특정 프로토콜(TCP, UDP)을 명시한다.
- IP 데이터그램에서 이 필드는 트랜스포트 계층에서 포트 번호 필드와 역할이 유사하다.
헤더 체크섬
- 헤더 체크섬은 라우터가 수신한 IP 데이터그램의 비트 오류를 탐지하는데 도움을 준다.
- 라우터는 오류 검출된 데이터그램을 폐기한다.
- TTL 필드와 옵션 필드의 값은 변경되므로 체크섬은 각 라우터에서 재계산되고 저장되어야 한다.
- 트랜스 포트 계층과 네트워크 계층에서 오류 검사를 수행하는 이유
  - IP 헤더만 IP 계층에서 체크섬을 수행하지만 TCP/UDP 체크섬은 전체 TCP/UDP 세그먼트를 계산한다.
  - TCP/UDP와 IP는 동일한 프로토콜 스택에 속할 필요가 없다. 원리상 TCP는 IP가 아닌 곳 위에서도 운영될 수 있다.
출발지와 목적지 IP 주소
- 출발지가 데이터그램을 생성할 때, 자신의 IP 주소를 출발지 IP 주소 필드에 삽입하고 목적지 IP 주소를 목적지 IP 주소 필드에 삽입한다.
옵션
- IP 헤더 필드를 확장한다.
- 모든 데이터그램 헤더 옵션 필드에 정보를 포함하지 않는 방법으로 오버헤드를 해결하기 위해 헤더 옵션은 거의 사용되지 않는다.
- 데이터그램 헤더가 가변 길이로 데이터 필드 시작점을 초기에 결정할 수 없어 문제를 복잡하게 만든다.
데이터(페이로드)
- 데이터그램이 존재하는 이유이자 가장 중요한 마지막 필드이다. 대부분의 경우 목적지에 전달하기 위해 트랜스포트 계층 세그먼트를 포함한다.

대부분의 IP 데이터그램은 총 20바이트(옵션은 없다고 가정)의 헤더를 갖는다.

TCP 세그먼트를 전송한다면 단편화가 되지 않은 각 데이터그램은 애플리케이션 계층의 메시지와 더불어 총 40바이트의 헤더(IP 헤더 20, TCP 헤더 20)을 전송한다.

4.3.2 IPv4 주소체계

호스트는 일반적으로 네트워크와 연결되는 하나의 링크를 갖는다.

호스트 IP가 데이터그램을 보낼 때 이 링크를 통해 데이터링크를 보낸다.

호스트와 물리적 링크 사이의 경계를 인터페이스(interface)라고 부른다.

라우터는 여러 개의 링크와 연결되고, 링크와 라우터 사이도 인터페이스(interface)로 이루어져있어 여러개의 인터페이스(interface)를 갖는다.

모든 호스트와 라우터는 IP 데이터그램을 송수신할 수 있으므로 IP는 각 호스트와 라우터 인터페이스가 IP 주소를 갖도록 요구한다.

이러한 각 인터페이스는 고유한 IP 주소를 갖는다.

따라서 기술 면에서 IP 주소는 인터페이스(interface)를 포함하는 호스트 라우터보다는 인터페이스(interface)와 관련이 있다.

서브넷과 IP 주소

각 IP 주소는 32비트 길이다. 따라서 2^32개의 주소를 사용할 수 있다. 일반적으로 주소의 각 바이트를 십진수로 표현하고 주소의 다른 바이트와 점으로 구분하는 십진 표기법을 사용한다.

인터페이스의 IP는 마음대로 선택할 수 없다. IP 주소의 일부는 연결된 서브넷이 결정한다.

왼쪽 3개의 호스트와 라우터 인터페이스는 모두 223.1.1.xxx 형식의 IP 주소를 갖는다. 또, 4개의 인터페이스가 중계하는 라우터 없이 하나의 네트워크에 서로 연결되어 있다.

이 네트워크는 이더넷 LAN으로 상호연결되고 이 경우 인터페이스는 이더넷 허브나 이더넷 스위치 또는 무선 AP로 상호연결된다.

IP 용어로 세 호스트 들의 인터페이스들과 하나의 라우터 인터페이스로 연결된 네트워크는 서브넷(subnet)을 구성한다고 말한다.

IP 주소체계는 이 서브넷에 223.1.1.0/24 라는 주소를 할당하는데 여기서 /24는 서브넷 마스크라 부르는데, 왼쪽 24비트가 서브넷 주소라는 것을 가리킨다.

위 그림에서는 3개의 서브넷을 볼 수 있다.

서브넷 IP의 정의는 여러 호스트를 라우터 인터페이스에 연결하는 이더넷 세그먼트만을 의미하는 것은 아니다.

위 그림을 보면 3개의 라우터도 점대점으로 연결되어있는 것을 볼 수 있다.

여기서는 호스트와 라우터의 연결 뿐만 아니라 라우터 간의 연결에서도 서브넷을 볼 수 있다.

총 6개의 서브넷을 찾을 수 있다.

서브넷의 정의

서브넷을 결정하려면 먼저 호스트나 라우터에서 각 인터페이스를 분리하고 고립된 네트워크를 만든다. 이 고립된 네트워크의 종단점은 인터페이스의 끝이 된다. 이렇게 고립된 네트워크 각각을 서브넷이라고 부른다.

위에 의하면 다수의 이더넷 세그먼트와 종단 간의 링크를 갖는 기관은 한 서브넷에서 모든 장비가 같은 서브넷 주소를 갖는 그런 서브넷을 여러개 가질 수 있다.

서로 다른 서브넷은 다른 주소를 가져야 하지만 실제로 서브넷 주소는 같은 부분이 많다.

CIDR

인터넷 주소 할당 방식 중 하나다.

CIDR는 서브넷 주소 체계 표기를 일반화하고 있다.

a.b.c.d/x 형식 주소에서 최상위 비트(Most significant bit)를 의미하는 x는 IP 주소의 네트워크 부분을 구성한다.

이를 해당 주소의 프리픽스 또는 네트워크 프리픽스라고 부른다.

한 기관은 통상 연속적인 주소의 블록(공통 프리픽스를 갖는 주소 범위)을 할당 받고 기관 장비들의 IP 주소는 공통 프리픽스를 공유한다.

외부 기관의 라우터는 목적지 주소가 내부 기관인 데이터그램을 전달할 때, 단지 앞의 x 비트들만 고려한다.

a.b.c.d/x 형태의 한 엔트리만으로 기관 목적지로 패킷을 전달하는 데 충분하므로, 이런 라우터들에서 포워딩 테이블의 크기를 상당히 줄여준다.

주소의 나머지 32-x 비트들은 기관 내부에 같은 네트워크 프리픽스를 갖는 모든 장비를 구별한다.

이 비트들은 기관 내부의 라우터에서 패킷을 전달할 때 사용되며 이 하위 비트들은 추가적으로 서브넷 구조를 가질 수도 있다.

클래스 주소체계

CIDR가 채택되기 전에는 IP 주소의 네트워크 부분을 8, 16, 24 비트로 제한했고 각각의 비트를 서브넷 주소로 갖는 서브넷을 각각 A, B, C 클래스 네트워크로 분류했기 때문에 이러한 주소체계는 클래스 주소체계라고 알려졌다.

그러나 서브넷 부분이 정확히 1, 2, 3 바이트여야 하는 요구사항은 중소형 크기의 네트워크로 급속히 증가하는 기관의 수를 지원하기엔 문제가 있었다.

예를 들어 클래스(/24) 서브넷은 254개의 호스트만을 제공하므로 많은 조직을 위해서는 턱없이 부족하고, 클래스(/16) 서브넷은 65634개의 호스트를 제공하여 너무 크다.

브로드캐스트 주소

IP의 또 다른 형태인 브로드캐스트 주소 255.255.255.255가 있다.

호스트가 목적지 주소가 255.255.255.255인 데이터그램을 보내면, 이 메시지는 같은 서브넷에 있는 모든 호스트에게 전달된다.

다음으로는 한 기관에서 그들의 장비를 위한 주소 블록을 어떻게 획득하는지 알아본 후에, 이 획득한 주소 블록의 주소를 어떻게 장비에 할당하는지 살펴보겠다.

주소 블록 획득

기관의 서브넷에서 사용하기 위한 IP 주소 블록을 얻기 위해, 네트워크 관리자는 먼저 이미 할당받은 주소의 큰 블록에서 주소를 제공하는 ISP와 접촉해야 한다.

ISP가 위와 같은 블럭을 할당 받았다고 할 때, ISP는 블록을 다음처럼 같은 크기의 작은 주소 블록 8개로 나누고, 이것으로 8개 조직을 지원할 수 있다.

ISP는 비영리 단체인 ICANN으로 부터 주소 블록을 할당 받는다.

ICANN의 역할은 IP 주소 할당과 DNS 루트 서버 관리다.

호스트 주소 획득: 동적 호스트 구성 프로토콜 (DHCP)

한 기관은 ISP로부터 주소 블록을 획득하여, 개별 IP 주소를 기관 내부의 호스트와 라우터 인터페이스에 할당한다.

라우터 인터페이스 주소에 대해, 시스템 관리자는 라우터 안에 IP 주소를 할당한다.

호스트에 IP 주소를 할당하는 것은 수동으로 구성이 가능하지만 일반적으로 동적 호스트 구성 프로토콜(DHCP)을 많이 사용한다.

DHCP는 호스트가 IP 주소를 자동으로 얻을 수 있게 하고, 서브넷 마스크, 첫 번째 홉 라우터 주소나 로컬 DNS 서버 주소 같은 추가 정보를 얻게 해준다.

DHCP는 자동으로 호스트와 연결해주는 능력 때문에 플러그 앤 플레이 프로토콜 또는 제로 구성 프로토콜이라고도 한다.

DHCP는 클라이언트-서버 프로토콜이다.

클라이언트는 일반적으로 IP 주소를 포함하며 네트워크 설정을 위한 정보를 얻고자 새롭게 도착한 호스트다.

각 서브넷은 DHCP 서버를 갖거나 없다면 해당 네트워크에 대한 DHCP 서버 주소를 알려줄 DHCP 연결 에이전트(일반적으로 라우터)가 필요하다.

위 그림은 새로운 호스트가 도착할 경우, DHCP 프로토콜의 4단계 과정을 보여준다.

DHCP 서버 발견
- 먼저 새롭게 도착한 호스트는 상호작용할 DHCP를 발견한다. 이것은 DHCP 발견 메시지를 사용하여 수행되며, 클라이언트는 포트 67번으로 UDP 패킷을 보낸다.
- DHCP 클라이언트는 DHCP 발견 메시지를 포함하는 IP 데이터 그램을 생성하는데, 이 메시지 내의 목적지 IP 주소를 브로드캐스트 IP 주소 255.255.255.255로 설정하고 출발지 IP 주소는 0.0.0.0으로 설정한다.
- 링크 계층으로 IP 데이터그램을 보내며 이 프레임은 서브넷에 연결된 모든 노드로 브로드캐스트된다.
DHCP 서버 제공
- DHCP 발견 메시지를 받은 DHCP 서버는 DHCP 제공 메시지를 클라이언트로 응답한다.
- 이때에도 IP 브로드캐스트 주소를 사용하여 서브넷의 모든 노드로 이 메시지를 브로드캐스트한다.
- 서브넷에는 여러 DHCP 서버가 존재하기 때문에, 클라이언트는 여러 DHCP 제공 메시지로부터 가장 최적의 위치에 있는 DHCP 서버를 선택한다.
- 각각의 서버 제공 메시지는 수신된 발견 메시지의 트랜잭션 ID, 클라이언트에 제공된 IP 주소, 네트워크 마스크, IP 주소 임대 기간을 포함한다.
DHCP 요청
- 새롭게 도착한 클라이언트는 하나 또는 그 이상의 서버 제공자 중에서 선택할 것이고 선택된 제공자에게 파라미터 설정으로 되돌아오는 DHCP 요청 메시지로 응답한다.
DHCP ACK
- 서버는 DHCP 요청 메시지에 대해 요청된 파라미터를 확인하는 DHCP ACK 메시지로 응답한다.

클라이언트가 DHCP ACK을 받으면 상호작용이 종료되고 클라이언트는 임대 기간동안 할당 IP 주소를 사용할 수 있다.

DHCP는 노드가 새로운 서브넷에 연결하고자 할 때마다 새로운 IP 주소를 DHCP로부터 얻기 때문에, 이동 노드가 서브넷 사이를 이동할 때 원격 애플리케이션에 대한 TCP 연결이 유지될 수 없다는 결점이 있다.

4.3.3 네트워크 주소 변환 (NAT)

모든 호스트가 서브넷으로부터 IP를 할당받고 할 때 네트워크가 현저하게 커지면 큰 주소 블록이 할당되어야 한다.

ISP가 이미 해당 주소 범위의 인접한 부분을 할당해버리는 등의 문제가 발생할 수 있는데 이런 경우에는 네트워크 주소 변환(NAT)으로 주소를 할당할 수 있다.

NAT 가능 라우터는 위 그림의 오른쪽처럼 홈 네트워크의 일부인 인터페이스를 갖는다.

홈 네트워크의 4개 인터페이스 모두 같은 네트워크 주소 10.0.0.0/24를 갖는다.

주소 공간 10.0.0.0/8은 사설망 또는 그림의 홈 네트워크와 같은 사설 개인 주소를 갖는 권역(realm)을 위해 RFC에 예약된 IP 주소 공간 세 부분 중의 하나다.

사설 개인 주소를 갖는 권역(realm)이란 네트워크 주소들이 그 네트워크 내부에 있는 장비에게만 의미가 있는 그런 네트워크를 의미한다.

사설 개인 주소를 갖는 권역은 홈 네트워크 내부에서만 의미가 있다. 즉, 글로벌 인터넷과는 송수신할 수 없다.

NAT 가능 라우터는 외부 세계로는 하나의 IP 주소를 갖는 하나의 장비로 동작한다.

그림을 보면 홈 라우터를 떠나 인터넷으로 가는 트래픽의 출발지 IP 주소는 138.76.29.7 즉, 라우터의 출력 라우터 인터페이스의 IP 주소를 갖는다.

홈으로 들어오는 트래픽의 목적지 주소는 마찬가지로 138.76.29.7을 가져야한다.

본질적으로 NAT 가능 라우터는 외부에서 들어오는 홈 네트워크의 상세한 사항을 숨긴다.

WAN에서 같은 목적지 IP 주소를 갖는 NAT 라우터에 모든 데이터 그램이 도착하면, 라우터가 주어진 데이터그램을 전달하는 내부 호스트를 어떻게 알 수 있을까?

NAT 라우터에서 NAT 변환 테이블을 사용하고, 그 테이블에 IP 주소와 포트 번호를 포함하여 알 수 있다.

위 그림의 NAT 변환 테이블을 보며 순서대로 잘 따라가보길 바란다.

웹 서버는 내부 호스트를 모른채 WAN side의 라우터를 목적지 IP로 하여 응답하고, 라우터는 이 응답을 NAT 변환 테이블을 사용하여 알맞은 내부 호스트에 전달한다.

포트 번호는 호스트 주소 지정이 아닌 프로세스 주소 지정에 사용된다.

서버 프로세스는 잘 알려진 포트 번호에서 요청이 올 때까지 기다리고 P2P 프로토콜의 피어는 서버로서의 역할을 할 때 들어오는 연결을 수락해야 하기 때문에 홈 네트워크에서 실행되는 서버에 문제가 발생할 수 있다.

이 문제의 기술적인 해결책으로는 NAT 순회 도구가 있다.

4.3.4 IPv6

IPv4 주소 공간이 빠르게 고갈되어가면서 IPv6 주소 체계가 개발되었다.

IPv6 데이터그램 포맷

IPv6 중요한 변화

확장된 주소 기능
- IPv6는 IP 주소 크기를 32비트에서 128비트로 확장했으므로 IP 주소가 고갈되는 일은 발생하지 않을 것이다.
- IPv6는 유니캐스트, 멀티캐스트 주소뿐만 아니라 새로운 주소 형태인 애니캐스트 주소가 도입되었다. 애니 캐스트 주소로 명시된 데이터그램은 호스트 그룸의 어떤 이에게든 전달될 수 있다.
간소화된 40 바이트 헤더
- 40 바이트 고정 길이 헤더는 라우터가 IP 데이터그램을 더 빨리 처리하게 해준다.
- 새로운 옵션 인코딩은 유연한 옵션 처리를 가능하게 한다.
흐름 레이블링
- 정의하기 어려운 흐름을 갖고있다. RFC는 "비 디폴트 품질 서비스나 실시간 서비스 같은 특별한 처리를 요청하는 송신자에 대해 특정 흐름에 속하는 패킷 레이블링"을 가능하게 한다고 설명한다. 아직 정확한 의미는 정의되지 않았지만, 언젠가 필요할 흐름 차별화를 예견하여 구현하였다.

IPv6 데이터그램 포맷은 그림과 같다.

버전
- 4비트 필드는 IP 버전 번호를 인식한다. IPv6라면 6이다.
트래픽 클래스
- IPv4의 TOS 필드와 비슷한 의미로 만든 8비트 필드는 흐름 내의 SMTP 이메일 같은 애플리케이션의 데이터그램보다 Volp 같은 특정 애플리케이션 데이터그램에 우선순위를 부여하는데 사용된다.
흐름 레이블
- 데이터그램의 흐름을 인식하는데 사용된다.
페이로드 길이
- 이 16비트 값은 IPv6 데이터그램에서 고정 길이 40바이트 패킷 헤더 뒤에 나오는 바이트 길이이며, 부호 없는 정수다.
다음 헤더
- 이 필드는 데이터그램의 내용이 전달될 프로토콜을 구분한다.(TCP, UDP)
홉 제한
- 라우터가 데이터그램을 전달할 때 마다 1씩 감소하고, 0이되면 데이터그램이 라우터에 의해 버려진다.
출발지와 목적지 주소
- 출발지와 목적지 주소를 담고 있다.
데이터
- IPv6 데이터그램의 페이로드 부분이다. 데이터그램이 목적지에 도착하면 IP 데이터그램에서 페이로드를 제거한 후, 다음 헤더 필드에 명시한 프로토콜에 전달한다.

IPv4에는 있지만 IPv6에는 없는 필드

단편화/재결합
- IPv6에서는 단편화와 재결합을 출발지와 목적지만이 수행한다.
- 라우터가 받은 IPv6 데이터그램이 너무 커서 출력 링크로 전달할 수 없다면 라우터는 데이터그램을 폐기하고 너무 크다는 ICMP 오류 메시지를 송신자에게 보낸다.
- 송신자는 데이터를 IP 데이터그램 크기를 줄여서 다시 보낸다.
- 라우터에서 이 기능을 수행하는 것은 시간이 오래 걸리므로 이 기능을 삭제하여 IP 전달 속도를 증가시켰다.
헤더 체크섬
- 트랜스포트 계층 프로토콜과 데이터 링크 프로토콜은 체크섬을 수행하므로 IP 설계자는 네트워크 계층의 체크섬 기능이 반복되는 것으로 생략해도 될 것이라 생각하여 삭제했다.
옵션
- IPv4에서도 잘 사용되지 않았던 필드가 사라지고 고정 헤더의 길이를 갖게되었다.
- 다대신 옵션 필드는 IPv6 헤더에서 다음 헤더 중 하나가 될 수 있다.

IPv4에서 IPv6로의 전환

IPv6는 IPv4 데이터그램을 보내고 라우팅하며 받을 수 있는 새 IPv6 시스템이 있는 반면에, IPv4로 구축된 시스템은 IPv6 데이터그램을 처리할 수 없다는 것에서 발생한다.

플래그 데이 선언

모든 인터넷 장비를 끄고 IPv4를 IPv6로 업그레이드하는 시간과 날짜를 정하는 것으로 40년 전에 실제로 NCP를 TCP로 전이하였다.

그러나 수억개의 장비가 관련된 플레그 데이는 오늘날에는 절대 불가능하다.

터널링

실제로 널리 사용하는 방법이다.

두 IPv6 노드(그림에서는 B와 E)가 IPv6 데이터그램을 사용해서 작동한다고 가정해보자.

물론 이들은 IPv4 라우터를 통해 연결되어있다. 이렇게 IPv6 노드 사이에 연결되어있는 IPv4 라우터들을 터널(tunnel)이라고 한다.

IPv6 송신 과정

터널의 송신 측에 있는 IPv6 노드는 IPv6 데이터그램을 받고 IPv4 데이터그램의 데이터 필드에 이것을 넣는다.
IPv4 데이터그램에 목적지 주소를 터널의 수신 측에 IPv6 노드로 적어서 터널의 첫 번째 노드에 보낸다.
터널 내부에 있는 IPv4라우터는 IPv4 라우터는 IPv4 데이터그램이 IPv6 데이터그램을 갖고 있다는 사실을 모른채 다른 데이터그램을 처리하는 방식으로 IPv4 데이터 그램을 처리한다.
터널 수신 측에 있는 IPv6 노드는 IPv4 데이터그램을 받고 이 IPv4 데이터그램이 실제 IPv6 데이터그램임을 결정한다.
다음 노드에 IPv6 데이터그램을 보낸다.

기초적인 IPv6 수용은 이루어지고 있지만 최근에 이루어진 것은 없다.

Chapter 3 - 4. 신뢰적인 데이터 전송의 원리, 5. 연결지향형 트랜스포트: TCP

ssun_bear — Tue, 9 Jul 2024 20:16:45 +0900

3.4 신뢰적인 데이터 전송의 원리

신뢰적인 데이터 전송을 구현하는 문제는 트랜스포트 계층뿐만 아니라 링크 계층과 애플리케이션 계층에서도 발생할 수 있는 문제이다.

따라서 이 절에서는 일반적인 상황에서의 신뢰적인 데이터 전송 문제를 다룬다.

신뢰적인 데이터 전송 연구의 프레임워크는 다음과 같다.

a. 서비스 모델

b. 서비스 구현

상위 계층 객체에게 제공되는 서비스 추상화는 / 데이터가 전송될 수 있는 신뢰적인 채널의 서비스 추상화다.

신뢰적인 채널에서는 전송된 데이터가 손상되거나 손실되지 않으며,
모든 데이터는 전송된 순서 그대로 전달된다.

= TCP가 인터넷 애플리케이션에게 제공하는 서비스 모델

신뢰적인 데이터 전송 프로토콜(reliable data transfer protocol)의 의무는 신뢰적인 채널의 서비스 추상화를 구현하는 것이다.

이 절에서는 점점 복잡해지는 하위 채널 모델을 고려하여 신뢰적인 데이터 전송 프로토콜의 송신자 측면과 수신자 측면을 점진적으로 개발해나간다.

논의 과정 중 채택할 한 가지 가정 : 패킷은 순서대로 전달된다. (하부 채널은 패킷의 순서를 바꾸지 않음)

위 두 가지 그림 중 b는 데이터 전송 프로토콜의 인터페이스를 나타낸다.

데이터 전송 프로토콜의 송신 측은 rdt_send() 호출로 위쪽으로부터 호출될 것이며, 수신 측에서는 상위 계층으로 전달될 데이터를 넘길 것이다.
- rdt : 신뢰적인 데이터 전송(reliable data transfer) 프로토콜을 나타낸다.
- _send : rdt의 송신 측이 호출되고 있음을 나타낸다.
수신 측에서 rdt_rcv()는 패킷이 채널의 수신 측으로부터 도착했을 때 호출된다.
rdt 프로토콜이 상위 계층에 데이터를 전달하려고 할 때 deliver_data()를 호출한다.

이 절에서는 단방향 데이터 전송(unidirectional data tranfer)의 경우인 송신 측으로부터 수신 측까지의 데이터 전송만을 고려한다.

양방향(전이중) 데이터 전송(bidirectional data transfer)의 설명은 상당히 복잡하다.

단방향 데이터 전송만 생각하더라도 프로토콜의 송신 측과 수신 측이 양방향으로 패킷을 전달할 필요가 있다.

즉, rdt의 송신 측과 수신 측은 전송 데이터를 포함하는 패킷을 교환하는 것 외에 제어 패킷을 양쪽으로 전송해야 한다.

rdt의 송신 측과 수신 측 모두 udt_send()를 호출함으로써 다른 쪽에 패킷을 전송한다.
- udt : 비신뢰적인 데이터 전송(unreliable data transfer)을 나타냄

3.4.1 신뢰적인 데이터 전송 프로토콜의 구축

유한상태 머신(finite-state machine, FSM)에 대한 정의

화살표는 한 상태로부터 다른 상태로의 전이를 나타낸다.
FSM의 초기 상태는 점선 화살표로 표시된다.

전이를 일으키는 이벤트(event)는 변화를 표기하는 가로선 위에 나타낸다.
이벤트가 발생했을 때 취해지는 행동, 액션(action)은 가로선 아래에 나타낸다.

이벤트 발생 시 어떠한 행동도 취해지지 않거나, 어떠한 이벤트 발생 없이 행동이 취해질 때
동작이나 이벤트가 없음을 표시하기 위해 각각 가로선 아래나 위에 기호 를 사용한다.

완벽하게 신뢰적인 채널상에서의 신뢰적인 데이터 전송: rdt1.0

하위 채널이 완전히 신뢰적인 가장 간단한 경우를 고려해보자.

rdt1.0에 대한 FSM

rdt1.0 송신자와 수신자에 대한 유한상태 머신(FSM) 정리는 아래 그림과 같다.

송신자에 대해 그리고 수신자에 대해 분리된 FSM이 있다

a는 송신자(sender)의 동작에 대한 정의
b는 수신자(receiver)의 동작에 대한 정의

rdt1.0에서 각각의 FSM은 하나의 상태만을 가지므로, 전이는 필연적으로 그 상태로부터 자신으로 되돌아온다.

송신자

rdt_send(data) 이벤트에 의해
(이 이벤트는 상위 계층 애플리케이션의 프로시저 호출(e.g., rdt_send())에 의해 발생)
1. 상위 계층으로부터 데이터를 받아들이고
2. 데이터를 포함한 패킷을 생성한다. (make_pkt(data))
그러고 난 후 패킷을 채널로 송신한다.

수신자

rdt는 rdt_rcv(packet) 이벤트에 의해 하위의 채널로부터 패킷을 수신한다. : 이 이벤트는 하위 계층 프로토콜로부터의 프로시저 호출(e.g., rdt_rcv())에 의해 발생한다.
패킷으로부터 데이터를 추출하고 (extract(packet, data))
데이터를 상위 계층으로 전달한다. (deliver_data(data))

여기서는 데이터 단위와 패킷의 차이점이 없으며, 모든 패킷 흐름은 송신자로부터 수신자까지다.

완전히 신뢰적인 채널에서는 오류가 생길 수 없으므로 수신 측이 송신 측에게 어떤 피드백(feedback)도 제공할 필요가 없다.

또한, 수신자는 송신자가 데이터를 송신하자마자 데이터를 수신할 수 있다고 가정하였다.

따라서 수신자가 송신자에게 천천히 보내라는 것을 요청할 필요가 없다.

비트 오류가 있는 채널상에서의 신뢰적인 데이터 전송: rdt2.0

패킷 안의 비트들이 하위 채널에서 손상되는 모델이다.

일반적으로 이러한 비트 오류는 패킷이 전송 도는 전파되거나 버퍼링될 때 네트워크의 물리적인 구성요소에서 발생한다.

자동 재전송 요구(Automatic Repeat reQuest, ARQ) 프로토콜

긍정 확인응답(positive acknowledgment, “OK”)
부정 확인응답(negative acknowledgment, “그것을 반복해주세요”)

이러한 제어 메시지는 정확하게 수신되었는지 또는 잘못 수신되어 반복이 필요한지를 수신자가 송신자에게 알려줄 수 있게 한다.

비트 오류를 처리하기 위해 기본적으로 다음과 같은 세 가지 부가 프로토콜 기능이 ARQ 프로토콜에 요구된다.

오류 검출

비트 오류가 발생했을 때 수신자가 검출할 수 있는 기능이 필요하다. → checksum

이러한 기술은 수신자가 패킷 비트 오류를 검출하고 복구할 수 있게 해준다.

수신자 피드백

송신자가 수신자의 상태를 알기 위한 유일한 방법은 수신자가 송신자에게 피드백을 제공하는 것이다.

수신자의 상태 : 패킷이 정확하게 수신되었는지 아닌지 등

e.g., rdt2.0 프로토콜에서는 수신자로부터 송신자 쪽으로 ACK와 NAK 패킷들을 전송할 것이다.

긍정 확인 응답(ACK)
부정 확인 응답(NAK)

→ 이러한 패킷은 단지 한 비트 길이면 된다. (0 또는 1)

재전송

수신자에서 오류를 가지고 수신된 패킷은 송신자에 의해 재전송(retransmit)된다.

rdt2.0에 대한 FSM

송신자

2개의 상태가 존재한다.

왼쪽 상태에서 송신 측 프로토콜은 상위 계층으로부터 데이터가 전달되기를 기다린다.
1. 송신자는 패킷 체크섬과 함께 전송될 데이터를 포함하는 패킷(sndpkt)을 생성하고,
2. 그 패킷을 udt_send(sndpkt) 동작을 통해 전송한다.
rdt_sent(data) 이벤트가 발생하면,
오른쪽 상태에서 송신자 프로토콜은 수신자로부터의 ACK 또는 NAK 패킷을 기다린다.
1. 만약 ACK 패킷이 수신된다면 (rdt_rcv(rcvpkt) && isACK(rcvpkt))
  - 가장 최근에 전송된 패킷이 정확하게 수신되었음을 의미한다.
  - 따라서 프로토콜은 상위 계층으로부터 데이터를 기다리는 상태로 돌아간다.
2. 만약 NAK가 수신된다면
  1. 프로토콜은 마지막 패킷을 재전송한다.
  2. 재전송된 데이터 패킷에 대한 응답으로 수신자에 의해 응답하는 ACK 또는 NAK를 기다린다.

rdt2.0과 같은 프로토콜은 전송 후 대기(stop-and-wait) 프로토콜이다.

송신자가 ACK 또는 NAK를 기다리는 상태에 있을 때, 상위 계층으로부터 더 이상의 데이터를 전달받을 수 없다.

즉, rdt_send() 이벤트는 발생할 수 없으며, 이는 오직 송신자가 ACK를 수신하고 이 상태를 떠난 후에 발생할 것이다.

따라서 송신자는 수신자가 현재의 패킷을 정확하게 수신했음을 확신하기 전까지 새로운 데이터를 전달하지 않는다.

수신자

단일 상태를 갖는다.

패킷이 도착했을 때, 수신자는 수신된 패킷이 손상되었는지 아닌지에 따라 ACK 또는 NAK로 응답한다.

rdt2.0의 결함

여기서는 ACK 또는 NAK 패킷이 손상될 수 있다는 가능성을 고려하지 않았다.

만약 ACK 또는 NAK가 손상되었다면, 송신자는 수신자가 전송된 데이터의 마지막 부분을 올바르게 수신했는지를 알 방법이 없다.

대안 1 : 송신자가 검출뿐만 아니라 비트 오류로부터 회복할 수 있도록 충분한 체크섬 비트들을 추가한다.

이 방식은 패킷이 손상될 수 있으나 손실되지는 않는 채널의 경우에는 즉각적으로 문제를 해결할 수 있다.

대안 2 : 송신자가 왜곡된 ACK 또는 NAK 패킷을 수신할 때 현재 데이터 패킷을 단순히 다시 송신한다.

그러나 이 방식은 송신자에게 수신자 간의 채널로 중복 패킷(duplicate packet)을 전송한다.

송신자 입장에서는 마지막으로 전송된 ACK 또는 NAK가 송신자에게 정확하게 수신됐는지를 알 수 없다.
수신자 입장에서는 도착하는 패킷이 새로운 데이터를 포함하고 있는 것인지 아니면 재전송인지를 사전에 알 수 없다.

해결책

데이터 패킷에 새로운 필드를 추가하고 이 필드 안에 순서 번호(sequence number)를 삽입하는 방식으로 데이터 패킷에 송신자가 번호를 붙인다.

이는 현존하는 데이터 전송 프로토콜에 채택된 방법이다.

수신자는 수신된 패킷이 재전송인지를 결정할 때는 이 순서 번호만 확인하면 된다.

rdt2.0의 수정 버전: rdt2.1

rdt2.1은 rdt2.0보다 두 배 많은 상태를 가지고 있다.

이는 아래의 2가지를 반영해야 하기 때문이다.

프로토콜 상태가 현재 (송신자에 의해) 전송되고 있는지에 대한 반영
(수신자가) 기다리고 있는 패킷이 순서 번호 0 또는 1을 가져야 하는지에 대한 반영

프로토콜 rdt2.1은 수신자로부터 송신자까지의 긍정 확인응답과 부정 확인응답을 모두 포함한다.

순서가 바뀐 패킷이 수신되면, 수신자는 이미 전에 수신한 패킷에 대한 긍정 확인응답을 전송한다.
손상된 패킷이 수신되면, 수신자는 부정 확인응답을 전송한다.

NAK를 송신하는 것 대신에,
가장 최근에 정확하게 수신된 패킷에 대해 ACK를 송신함으로써 NAK를 송신한 것과 같은 효과를 얻을 수 있다.

즉, 같은 패킷에 대해 2개의 ACK를 수신(즉, 중복(duplicate) ACK를 수신)한 송신자는
수신자가 두 번 ACK 한 패킷의 다음 패킷을 정확하게 수신하지 못했다는 것을 알게 된다. (NAK의 의미와 동일)

rdt2.1에 대한 FSM

송신자

수신자

비트 오류를 갖는 채널을 위한 NAK 없는 신뢰적인 데이터 전송 프로토콜 : rdt2.2

rtd2.2는 rdt2.1과 다르게,

수신자가 반드시 ACK 메시지에 의해 확인 응답되는 패킷의 순서 번호를 포함해야 한다.
- 이는 수신자 FSM의 make_pkt()에 ACK, 0 또는 ACK, 1인 인수를 넣어서 수행한다.
송신자는 수신된 ACK 메시지에 의해 확인응답된 패킷의 순서 번호를 반드시 검사해야만 한다.
- 이는송신자 FSM의 isACK()에 0 또는 1인 인수를 넣어서 수행한다.

rdt2.2에 대한 FSM

송신자

수신자

비트 오류와 손실 있는 채널상에서의 신뢰적인 데이터 전송: rdt3.0

하위 채널이 패킷을 손실하는 경우도 생각해보자.

다음과 같은 두 가지 부가 내용을 프로토콜이 다루어야 한다.

어떻게 패킷 손실을 검출할 것인가?
패킷 손실이 발생했을 때 어떤 행동을 할 것인가?

송신자에게 손실된 패킷의 검출과 회복 책임을 부여한다.

송신자가 데이터 패킷을 전송하고, 패킷 또는 수신자의 패킷에 대한 ACK를 손실했다고 가정하자.

어느 경우에서나 송신자에게는 수신자로부터 어떠한 응답도 없다.

즉, 송신자는 데이터 패킷이 손실되었는지, ACK가 손실되었는지, 패킷 또는 ACK가 단순히 지나치게 지연된 것인지를 알지 못한다.

만약 송신자가 패킷을 잃어버렸다고 확신할 정도로 충분한 시간을 기다릴 수만 있다면, 데이터 패킷은 간단하게 재전송될 수 있다.

그러나 송신자가 어떤 패킷을 손실했다는 것을 확신하기 위해 얼마나 오랫동안 기다려야 할까?

송신자는 적어도 다음의 시간만큼을 기다려야 한다.

송신자와 수신자 사이의 왕복 시간 지연(중간 라우터에서의 버퍼링을 포함) + 수신 측에서 패킷을 처리하는 데 필요한 시간

실제 상황에서 채택한 접근 방식은 이와 같다.

패킷 손실이 일어났을 만한 그런 시간을 선택하여, 만일 ACK가 이 시간 안에 수신되지 않는다면 패킷은 재전송된다.

이것은 송신자 대 수신자 채널에서 중복 데이터 패킷(duplicate data packet)의 가능성을 포함하나,
프로토콜 rdt2.2에서처럼 패킷의 순서 번호를 통하여 처리가 가능하다.

시간 기반의 재전송 메커니즘을 구현하기 위해서는
주어진 시간이 지난 후에 송신자를 인터럽트(중단)할 수 있는 카운트다운 타이머(countdown timer)가 필요하다.

그러므로 송신자는 다음처럼 동작해야 한다.

매 패킷(첫 번째 또는 재전송 패킷)이 송신된 시간에 타이머를 시작한다.
타이머 인터럽트에 반응한다. (즉, 적당한 행동을 취함)
타이머를 멈춘다.

rdt3.0에 대한 FSM

송신자

동작과 처리 과정

아래의 4가지 다이어그램은 프로토콜이 패킷 손실 또는 지연 없이 어떻게 동작하는지와 손실된 데이터 패킷을 어떻게 처리하는지를 나타낸 것이다.

시간은 다이어그램의 위로부터 아래로 흐른다.

패킷에 대한 수신 시간은 전송 지연과 전파 지연 때문에 패킷 전송 시간보다 더 늦다.

패킷의 순서 번호가 0과 1이 번갈아 일어나기 때문에 프로토콜 rdt3.0은 얼터네이팅 비트 프로토콜(alternating-bit protocol)이라고 부른다.

무손실 동작

패킷 손실

ACK 손실

조급한 타임아웃

3.4.2 파이프라이닝된 신뢰적인 데이터 전송 프로토콜

프로토콜 rdt3.0은 기능적으로는 정확한 프로토콜이나, 오늘날의 고속 네트워크에서 누구나 이것의 성능에 만족하는 것은 아니다.

rdt3.0의 핵심적인 성능 문제는 전송 후 대기(stop-and-wait) 프로토콜이라는 점 때문에 발생한다.

전송 후 대기 프로토콜은 형편없는 송신자 이용률(utilization, 또는 효율)을 갖는다.

이에 대한 해결책은 다음과 같다.

송신자에게 확인응답을 기다리기 전에 송신을 전송하도록 허용하는 것이다. = 파이프라이닝(pipelining)

즉, 많은 전송 중인 송신자-수신자 패킷을 파이프라인에 채워 넣는 것이다.

아래의 그림들을 통해 만약 확인응답들을 기다리기 전에 송신자가 3개의 패킷을 전송하도록 허용한다면
송신자의 이용률은 3배가 되리라는 것을 볼 수 있다.

즉, window size 만큼 효율이 증가한다는 것이다.

전송 후 대기 동작

파이프라이닝된 동작

파이프라이닝 방식은 신뢰적인 데이터 전송 프로토콜에서 다음과 같은 중요성을 지니고 있다.

순서 번호의 범위가 커져야 한다.

각각의 전송 중인 패킷은 유일한 순서 번호를 가져야 한다.

전송 중인 확인응답(ACK)이 안 된 패킷이 여럿 있을지도 모르기 때문이다.

프토로콜의 송신 측과 수신 측은 패킷 하나 이상을 버퍼링해야 한다.

최소한 ‘송신자는 전송되었으나 확인응답되지 않은 패킷’을 버퍼링해야 한다.

정확하게 수신된 패킷의 버퍼링은 수신자에게서도 필요하다.

필요한 순서 번호의 범위와 버퍼링 조건은 데이터 전송 프로토콜이 손실 패킷과 손상 패킷 그리고 상당히 지연된 패킷들에 대해 응답하는 방식에 달려 있다.

파이프라인 오류 회복의 두 가지 기본적인 접근 방법

GBN(Go-Back-N) : N부터 반복
SR(Selective Repeat) : 선택적 반복

3.4.3 GBN

GBN(Go-Back-N, N부터 반복) 프로토콜에서 송신자는 확인 응답을 기다리지 않고 여러 패킷을 전송(가능할 때)할 수 있다.

그러나 파이프라인에서 확인응답이 안 된 패킷의 최대 허용 수 N보다 크지 말아야 한다.

아래 그림은 GBN 프로토콜에서 송신자 관점의 순서 번호 범위를 보여준다.

확인응답이 안 된 가장 오래된 패킷의 순서 번호를 base로 정의한다.
가장 작은 순서 번호를 nextseqnum(전송될 다음 패킷의 순서 번호)으로 정의한다.

이를 통해서 순서 번호의 범위에서 4개의 간격을 식별할 수 있다.

간격 [0, base-1] : 순서 번호는 이미 전송되고 확인응답이 된 패킷
간격 [base, nextseqnum-1] : 송신은 되었지만 아직 확인응답되지 않은 패킷
간격 [nextseqnum, base+N-1] : 상위 계층으로부터 데이터가 도착하면 바로 전송될 수 있는 패킷
base+N 이상
→ 파이프라인에서 확인응답이 안 된 패킷(특히, 순서 번호 base를 가진 패킷)의 확인응답이 도착할 때까지 사용될 수 없다.

슬라이딩 윈도 프로토콜(sliding-window protocol)

전송되었지만 아직 확인응답이 안 된 패킷을 위해,
허용할 수 있는 순서 번호의 범위는 순서 번호의 범위상에서 크기가 N인 ‘윈도(window)’로 나타낸다.

프로토콜이 동작할 때, 이 윈도는 순서 번호 공간에서 오른쪽으로 이동(slide)된다.
N = 윈도 크기(window size)

따라서 GBN 프로토콜은 슬라이딩 윈도 프로토콜(sliding-window protocol)이라고 부른다.

패킷의 순서 번호

실제로 패킷의 순서 번호는 패킷 헤더 안의 고정된 길이 필드에 포함된다.

만약 k가 패킷 순서 번호 필드의 비트 수라면, 순서 번호의 범위는 [0, 2^k - 1]
순서 번호의 제한된 범위에서, 순서 번호를 포함하는 모든 계산은 모듈로(modulo) 2^k 연산을 이용한다.

ACK 기반의 NAK 없는 확장된(extended) FSM

base와 nextseqnum 변수를 추가한다.
이러한 변수에서의 동작과 이러한 변수를 포함하는 조건부 동작을 추가한다.

송신자

GBN 송신자는 다음과 같은 세 가지 타입의 이벤트에 반응해야 한다.

1️⃣ 상위로부터의 호출

rdt_send()가 위로부터 호출되면, 송신자는 우선 윈도가 가득 찼는지 확인한다.
(즉, N개의 아직 확인응답되지 않은 패킷이 있는지를 확인)
만약 윈도가 가득 차 있지 않다면 패킷이 생성되고 송신되며, 변수들이 적절하게 갱신된다.
만약 윈도가 가득 차 있다면, 단지 데이터를 상위 계층으로 반환한다.
- 이는 윈도가 가득 차 있음을 가리키는 함축적인 의미이다.
- 따라서 상위 계층은 나중에 rdt_send()를 다시 시도할 것이다.

실제적인 구현에서 송신자는 아래와 같은 방법을 사용할 것이다.

이 데이터를 버퍼링한다. (그러나 즉시 송신하진 않음)
오직 윈도가 가득 차 있지 않을 때만 rdt_send()를 호출하는 동기화 메커니즘을 사용한다.
(e.g., semaphore 또는 flag)

2️⃣ ACK의 수신

GBN 프로토콜에서
순서 번호 n을 가진 패킷에 대한 확인응답은 누적 확인응답(cumulative acknowledgment)으로 인식된다.

이 누적 확인 응답은 수신 측에서 올바르게 수신된 n을 포함하여, n까지의 순서 번호를 가진 모든 패킷에 대한 확인 응답이다.

3️⃣ 타임아웃 이벤트

타이머는 손실된 데이터 또는 손실된 확인응답 패킷으로부터 회복하는 데 사용된다.

만약 타임아웃이 발생한다면, 송신자는 이전에 전송되었지만 아직 확인응답되지 않은 !!모든!! 패킷을 다시 송신한다.

위의 그림에서 송신자는
가장 오래된 ‘전송했지만, 아직 확인응답 안 된 패킷’에 대한 타이머로 생각될 수 있는 단일 타이머를 사용한다.

만일 한 ACK가 수신되었지만, 추가로 ‘전송했지만, 아직 확인응답 안 된 패킷’이 아직 존재한다면, 타이머를 다시 시작한다.
만약 아직 확인응답 안 된 패킷이 없다면, 타이머를 멈춘다.

수신자

만약 순서 번호 n을 가진 패킷이 오류 없이, 그리고 순서대로 수신된다면
(= 상위 계층에 마지막으로 전달된 데이터가 순서 번호 n-1을 가진 패킷에서 온 것이라면)
수신자는 패킷 n에 대한 ACK를 송신하고 상위 계층에 패킷의 데이터 부분을 전달한다.
그 외의 경우에는 수신자는 그 패킷을 버리고 가장 최근에 제대로 수신된 순서의 패킷에 대한 ACK를 재전송한다.

GBM 프로토콜에서 수신자는 순서가 잘못된 패킷들을 버린다.

지금 패킷 n이 수신되어야 하지만, 그 사람 다음의 패킷 n+1이 먼저 도착했다고 가정하자.

수신자는 상위 계층에 데이터를 전달해야 한다.

데이터가 순서대로 전달되어야 하므로, 수신자는 패킷 n+1을 저장하고
나중에 패킷 n이 수신되고 전달된 후에 상위 계층에 이 패킷을 전달한다.

그러나 만일 패킷 n이 손실된다면, GBN 재전송 규칙에 따라 수신자에게는 패킷 n과 n+1이 모두 재전송될 것이다.

이점 : 수신자 버퍼링이 간단하다 (수신자는 어떤 순서가 잘못된 패킷에 대해 버퍼링을 할 필요가 없다!)

송신자가 유지해야 하는 것
1. 윈도 상위와 하위 경계
2. 이 윈도 안에 있는 nextseqnum 위치
수신자가 유지해야 하는 것 : 다음 순서 패킷의 순서 번호

물론, 올바르게 수신된 패킷을 버리는 것의 단점은 그 패킷의 재전송이 손실되거나 왜곡될 수 있으므로 많은 재전송이 필요할 수도 있다는 것이다.

아래 그림은 윈도 크기가 4 패킷인 경우에 대한 GBN 프로토콜의 동작을 보여준다.

윈도 크기가 4 → 송신자는 패킷 0부터 3까지 송신한다.
송신을 계속하기 전에 하나 이상의 패킷이 긍정 확인응답되는 것을 기다려야 한다.

ACK0, ACK1처럼 각각의 성공적인 ACK가 수신되었을 때
1. 윈도는 앞으로 이동한다.
2. 송신자는 하나의 새로운 패킷(pkt4와 pkt5, 각각)을 전송한다.
수신 측에서는 pkt2가 손실되었으므로 pkt3, 4, 5는 순서가 잘못된 패킷으로 발견되어 제거된다.

이벤트 기반 프로그래밍(event-based programming)

앞에서 본, 확장된(extended) FSM을 다시 떠올려보자.

이 구현은 발생할 수 있는 다양한 이벤트에 대한 대응으로 취할 수 있는 동작을 구현하는 다양한 절차들과 유사하다.

이러한 이벤트 기반 프로그래밍(event-based programming)에서의 다양한 프로시저들은
프로토콜 스택에서 다른 프로시저에 의해 야기되거나 인터럽트의 결과로 요청될 것이다.

송신자에서 이러한 이벤트들에 대한 예시로는 다음과 같다.

rdt_send()를 호출하기 위한 상위 계층 개체로부터의 호출
타이머 인터럽트
패킷이 도착했을 때 rdt_rcv()를 호출하기 위한 하위 계층으로부터의 호출

GBN 프로토콜의 성능 문제

GBN 프로토콜은 송신자가 패킷으로 파이프라인을 채우는 것을 통해 전송 후 대기 프로토콜에서의 채널 이용률 문제를 피하도록 하였다.

그러나 GBN 자체에는 성능 문제를 겪는 시나리오들이 존재한다.

윈도 크기와 대역폭 지연(bandwidth-delay) 곱의 결과가 모두 클 때, 많은 패킷이 파이프라인에 있을 수 있다.

GBN은 패킷 하나의 오류 때문에 많은 패킷을 재전송하므로, 많은 패킷을 불필요하게 재전송하는 경우가 발생한다.

채널 오류의 확률이 증가할수록 파이프라인은 불필요한 재전송 데이터로 채워진다.

3.4.4 SR

SR(Selective Repeat, 선택적 반복) 프로토콜은
수신자에서 오류(손실되거나 변조된)가 발생한 패킷을 수신했다고 의심되는 패킷만을 재전송한다.

이를 통해서 SR는 불필요한 재전송을 피한다.
필요에 따라 각각의 개별적인 재전송은 수신자가 올바르게 수신된 패킷에 대한 개별적인 확인응답을 요구할 것이다.

윈도 크기 N은 파이프라인에서 아직 확인응답이 안 된 패킷 수를 제한하는 데 사용된다.

그러나 GBN과는 달리, 송신자는 윈도에 있는 몇몇 패킷에 대한 ACK를 이미 수신했을 것이다.

순서 번호 공간에 대한 SR 송신자의 관점

SR 수신자는 패킷의 순서와는 무관하게 손상 없이 수신된 패킷에 대한 확인응답을 할 것이다.
빠진 패킷이 존재하는 경우
1. 순서가 바뀐 패킷은 빠진 패킷이 수신될 때까지 버퍼에 저장하고,
  (빠진 패킷 = 아직 도착하지 않은 더 낮은 순서 번호를 가진 패킷)
2. 빠진 패킷이 수신된 시점에서 일련의 패킷을 순서대로 상위 계층에 전달할 수 있다.
  (re-order & reassemble the packets → in-order delivery to upper layer)

SR 송신자 이벤트와 행동

1️⃣ 상위로부터 데이터 수신

상위에서 데이터가 수신될 때, SR 송신자는 패킷의 다음 순서 번호를 검사한다.

순서 번호가 송신자 윈도 내에 있으면 데이터는 패킷으로 송신된다.
그렇지 않으면 GBN처럼 버퍼에 나중에 전송하기 위해 되돌려진다.

2️⃣ 타임아웃

타이머는 손실된 패킷을 보호하기 위해 재사용된다.

그러나 타임아웃 시 오직 한 패킷만이 전송되기 때문에, 각 패킷은 자신의 논리 타이머가 있어야 한다.

3️⃣ ACK 수신

ACK가 수신되었을 때, SR 송신자는 그 ACK가 윈도 내에 있다면 그 패킷을 수신된 것으로 표기한다.

만약 패킷 순서 번호가 send_base와 같다면, 윈도 베이스는 가장 작은 순서 번호를 가진 아직 확인응답되지 않은 패킷으로 옮겨진다.
만약 윈도가 이동하고 윈도 내의 순서 번호를 가진 미전송 패킷이 있다면, 이 패킷들은 전송된다.

SR 수신자 이벤트와 행동

1️⃣ [rcv_base, rcv_base+N-1] 내의 순서 번호를 가진 패킷이 손상 없이 수신된다.

이 경우는 수신된 패킷이 수신자의 윈도에 속하는 것이며, 선택적인 ACK 패킷이 송신자에게 회신된다.

만약 이 패킷이 이전에 수신되지 않았던 것이라면 버퍼에 저장된다.
만약 이 패킷이 수신 윈도의 base와 같은 순서 번호를 가졌다면,
이 패킷과 이전에 버퍼에 저장되어 연속적으로 번호를 가진(rcv_base로 시작하는) 패킷들은 상위 계층으로 전달된다.

2️⃣ [rcv_base-N, rcv_base-1] 내의 순서 번호를 가진 패킷이 수신된다.

이 경우에는 이 패킷이 수신자가 이전에 확인응답한 것이라도 ACK가 생성되어야 한다.

3️⃣ 그 외의 경우, 패킷을 무시한다.

SR 동작

처음에 pkt3, 4, 5를 버퍼에 저장한다.
마지막으로 pkt2가 수신되었을 때 pkt2와 함께 상위 계층에 전달한다.

SR 프로토콜에서 송신자와 수신자의 윈도는 항상 같지 않다

SR 수신자 이벤트와 행동의 2단계 : [rcv_base-N, rcv_base-1] 내의 순서 번호를 가진 패킷이 수신된다.

여기서 수신자가 현재의 윈도 base보다 작은 특정 순서 번호를 가진 ‘이미 수신된 패킷’을 무시하지 않고 재확인 응답을 하는 것이 중요하다!

e.g.,
송신자와 수신자의 순서 번호 공간을 줬을 때, 수신자가 송신자에게 보내는 send_base 패킷에 대한 ACK가 없다면
(우리에게는 수신자가 그 패킷을 이미 수신했음이 분명하더라도) 결국 송신자는 send_base 패킷을 재전송할 것이다.

만약 수신자가 이 패킷에 대한 확인응답을 하지 않는다면, 송신자의 윈도는 결코 앞으로 이동하지 않을 것이다.

송신자와 수신자는 올바른 수신과 그렇지 않은 수신에 대해 항상 같은 관점을 갖지는 않을 것이다.

→ 이는 SR 프로토콜에서 송신자와 수신자의 윈도가 항상 같지 않다는 것을 뜻한다.

송신자와 수신자 윈도 사이의 동기화 부족은 순서 번호의 한정된 범위에 직면했을 때 중대한 결과를 가져온다.

e.g.,

한정된 범위의 네 패킷 순서 번호 0, 1, 2, 3
윈도 크기 : 3

0부터 2까지의 패킷이 전송되어 올바로 수신되고, 수신자에게서 확인이 되었다고 가정하자.

그 순간에 수신자의 윈도는 각각의 순서 번호가 3, 0, 1인 4, 5, 6번째 패킷에 있다.

첫 번째 시나리오

처음 3개의 패킷에 대한 ACK가 손실되고, 송신자는 이 패킷을 재전송한다.
수신자는 순서 번호가 0인 패킷(처음 보낸 패킷의 복사본)을 수신한다.

두 번째 시나리오

처음 3개의 패킷에 대한 ACK가 모두 올바르게 전달되었다.
송신자는 자신의 윈도를 앞으로 이동시켜, 각각의 순서 번호가 3, 0, 1인 4, 5, 6번째 패킷을 보낸다.
순서 번호 3을 가진 패킷이 손실되고, 순서 번호 0을 가진 패킷(새로운 데이터를 포함한 패킷)은 도착한다.

수신자 관점을 고려해보자

수신자는 송신자의 행동을 볼 수 없다.

모든 수신자는 채널을 통해 받고, 채널을 통해 보내는 메시지의 순서를 관찰하는데, 이는 위의 두 가지 시나리오가 똑같다.

즉, 다섯 번째 패킷의 원래 전송과 첫 번째 패킷의 재전송을 구별할 방법은 없다.

최소한의 윈도 크기는 얼마인가?

윈도 크기는 SR 프로토콜에 대한 순서 번호 공간 크기의 절반보다 작거나 같아야 한다.

패킷 순서 바뀜 현상

맨 앞에서 패킷들은 송신자와 수신자 사이의 채널 안에서 순서가 바뀔 수 없다는 가정 하에 신뢰적인 데이터 전송 프로토콜에 대한 설명을 진행하였다.

이는 일반적으로 송신자와 수신자가 단일한 물리적 선으로 연결되어 있을 때 적합한 가정이다.
하지만 둘을 연결하는 ‘채널’이 네트워크일 때는 패킷 순서 바뀜이 일어날 수 있다.

패킷 순서 바뀜 현상으로, 송신자와 수신자의 윈도가 x를 포함하지 않고 있더라도
순서 번호 또는 확인응답 번호 x를 가진 오래된 패킷의 복사본들이 생길 수 있다.

패킷 순서가 바뀌는 채널이라는 것은 본질적으로 패킷들을 버퍼에 저장하고, 나중에 어느 때나 이 패킷들을 임의로 내보낸다고 간주할 수 있다.

순서 번호가 재사용될 수 있으므로 그런 중복된 패킷들을 막을 수 있는 조치가 필요하다.

실제 방식은 송신자가 이전에 송신된 순서 번호 x를 가진 패킷들이
더는 네트워크 상에 없음을 어느 정도 ‘확신’할 때까지 순서 번호가 재사용되지 않음을 확실히 하는 것이다.

이는 패킷이 어느 일정 시간 이상으로 네트워크에서 존재할 수 없다는 가정에 의해 이루어진다.

신뢰적인 데이터 전송 메커니즘과 그 사용에 대한 요약

체크섬

전송된 패킷 안의 비트 오류를 발견하는 데 사용된다.

타이머

채널 안에서 패킷이 손실되었기 때문에 발생되는 패킷(또는 이것의 ACK)의 타임아웃/재전송에 사용된다.

타임아웃

발생 이유

패킷이 지연되었지만 손실되지는 않았을 경우 (조기 타임 아웃)
패킷이 수신자에 의해 수신되었으나 수신자에서 송신자로의 ACK가 손실되었을 경우

→ 수신자에 의해 수신되는 패킷은 중복으로 복사(수신)된 패킷일 수 있다.

순서 번호

송신자에서 수신자로 가는 데이터 패킷의 순서 번호를 붙이기 위해 사용된다.

수신자 패킷의 순서 번호의 간격 : 수신자가 손실된 패킷을 검사하게 한다.
중복된 순서 번호를 갖는 패킷 : 수신자가 패킷의 중복 복사를 검사하게 한다.

확인응답

수신자가 한 패킷 또는 패킷 집합이 정확히 수신되었다는 응답을 송신자에게 하기 위해 사용된다.

일반적으로 패킷 또는 이미 확인응답된 패킷들의 순서 번호를 전달한다.
프로토콜에 따라 개별적이거나 누적된 것일 수 있다.

부정 확인응답

수신자가 패킷이 정확히 수신되지 않았다는 응답을 송신자에게 하기 위해 사용된다.

일반적으로 정확히 수신되지 않은 패킷의 순서 번호를 전달한다.

윈도, 파이프라이닝

송신자는 주어진 범위에 있는 순서 번호를 가진 패킷만 전송하도록 제한될 수 있다.

확인응답은 없지만 허가된 패킷이 전송될 수 있으므로, 송신자의 이용률은 전송 후 대기 모드의 동작보다 증가할 수 있다.

윈도 크기는 수신자의 메시지를 수신하고 버퍼링하는 능력, 네트워크의 혼잡 정도, 또는 두 가지 모두에 근거하여 설정된다.

3.5 연결지향형 트랜스포트: TCP

3.5.1 TCP 연결

TCP는 애플리케이션 프로세스가 데이터를 다른 프로세스에게 보내기 전에,
두 프로세스가 서로 ’핸드셰이크’를 먼저 해야 하므로 연결지향형(connection-oriented)이다.

즉, 데이터 전송을 보장하는 파라미터들을 각자 설정하기 위한 어떤 사전 세그먼트들을 보내야 한다.

TCP 연결은 두 통신 종단 시스템의 TCP에 존재하는 상태를 공유하는 논리적인 것이다.

TCP 연결은 전이중 서비스(full-duplex service)를 제공한다.

만약 호스트 A의 프로세스와 호스트 B의 프로세스 사이에 TCP 연결이 있다면,
애플리케이션 계층 데이터는 B에서 A로 흐르는 동시에 A에서 B로 흐를 수 있다.

TCP 연결은 항상 단일 송신자와 단일 수신자 사이의 점대점(point-to-point)이다.

따라서 단일 송신 동작으로 한 송신자가 여러 수신자에게 데이터를 전송하는 ‘멀티캐스팅(multicasting)’은 TCP에서는 불가능하다.

TCP 연결 과정

클라이언트 프로세스(client process) : 연결을 초기화하는 프로세스
서버 프로세스(server process)

세 방향 핸드셰이크(three-way handshake)

(3.5.6에서 더 자세히 다룰 예정)

클라이언트 애플리케이션 프로세스는 서버의 프로세스와 연결을 설정하기를 원한다고 TCP 클라이언트에게 먼저 알린다.
클라이언트의 트랜스포트 계층은 서버의 TCP와의 TCP 연결 설정을 진행한다.
즉, 클라이언트가 먼저 특별한 TCP 세그먼트를 보낸다.
서버는 두 번째 특별한 TCP 세그먼트로 응답한다.
마지막으로, 클라이언트가 세 번째 특별한 세그먼트로 다시 응답한다.

처음 2개의 세그먼트에는 페이로드(payload, 애플리케이션 계층 데이터)가 없다.
세 번째 세그먼트는 페이로드를 포함할 수 있다.

TCP 연결이 설정된 이후

일단 TCP 연결이 설정되면, 두 애플리케이션 프로세스는 서로 데이터를 보낼 수 있다.

클라이언트 프로세스는 소켓(프로세스의 관문)을 통해 데이터의 스트림을 전달한다.
데이터가 관문을 통해 전달되면, 이제 데이터는 클라이언트에서 동작하고 있는 TCP에 맡겨진다.
1. TCP는 초기 세 방향 핸드셰이크 동안 준비된 버퍼 중의 하나인 연결의 송신 버퍼(send buffer)로 데이터를 보낸다.
2. 때때로 TCP는 송신 버퍼에서 데이터 묶음을 만들어서 네트워크로 보낸다. (TCP가 언제 버퍼된 데이터를 전송해야 하는지는 정해져 있지 않음)

최대 세그먼트 크기(maximum segment size, MSS)

세그먼트로 모아 담을 수 있는 최대 데이터 양은 최대 세그먼트 크기(maximum segment size, MSS)로 제한된다.

MSS를 결정하는 요소

로컬 송신 호스트에 의해 전송될 수 있는 가장 큰 링크 계층 프레임의 길이
(최대 전송 단위(maximum transmission unit, MTU)
TCP 세그먼트(IP 데이터그램 안에 캡슐화되었을 때)와 TCP/IP 헤더 길이(통상 40바이트)가 단일 링크 계층 프레임에 딱 맞도록 한다.

MSS는 헤더를 포함하는 TCP 세그먼트의 최대 크기가 아니라, 세그먼트에 있는 애플리케이션 계층 데이터에 대한 최대 크기이다.

TCP 세그먼트(TCP segment)

TCP 헤더 + 클라이언트 데이터

네트워크 계층에 전달되어 네트워크 계층 IP 데이터그램 안에 각각 캡슐화된다.
세그먼트는 네트워크로 송신된다.
TCP가 상대에게서 세그먼트를 수신했을 때, 세그먼트의 데이터는 TCP 연결의 수신 버퍼에 위치한다.
→ 애플리케이션은 이 버퍼로부터 데이터의 스트림을 읽는다.

TCP 연결의 양 끝은 각각 자신의 송신 버퍼와 수신 버퍼를 갖고 있다.

즉, TCP 연결은 한쪽 호스트에서의 버퍼, 변수, 프로세스에 대한 소켓 연결과
다른 쪽 호스트에서의 버퍼, 변수, 프로세스에 대한 소켓 연결의 집합으로 이루어진다.

3.5.2 TCP 세그먼트 구조

구조

헤더 필드

출발지와 목적지 포트 번호(source and destination port number)
체크섬 필드(checksum field)
32비트 순서 번호 필드(sequence number field)
32비트 확인응답 번호 필드(acknowledgement number field)
16비트 수신 윈도(receive window) : 흐름 제어에 사용된다.
(수신자가 받아들이려는 바이트의 크기를 나타내는데 사용됨)
4비트 헤더 길이 필드(header length field) : 32비트 워드 단위로 TCP 헤더의 길이를 나타낸다.
옵션 필드(option field)
- 이 필드는 선택적이고 가변적인 길이를 가진다.
- 송신자와 수신자가 최대 세그먼트 크기(MSS)를 협상하거나 고속 네트워크에서 사용하기 위한 윈도 확장 요소로 이용된다.
플래그 필드(flag field) : 6비트를 포함한다.
- ACK 비트 : 확인응답 필드에 있는 값이 유용함을 가리키는 데 사용된다.
- RST, SYN, FIN 비트 : 연결 설정과 해제에 사용된다.
- PSH 비트 : 이 비트가 설정되었다면 이것은 수신자가 데이터를 상위 계층에 즉시 전달해야 함을 가리킨다.
- URG 비트
  - 이 세그먼트에서 송신 측 상위 계층 개체가 ‘긴급’으로 표시하는 데이터임을 가리킨다.
  - 이 긴급 데이터의 마지막 바이트의 위치는 16비트의 긴급 데이터 포인터 필드(urgent data pointer field)에 의해 가리켜진다.

데이터 필드

애플리케이션 데이터의 일정량을 담는다.

MSS

MSS는 세그먼트 데이터 필드의 크기를 제한한다.

큰 파일 전송 시, 일반적으로 MSS 크기로 파일을 분절한다.
많은 대화식 애플리케이션은 MSS보다 작은 양의 데이터를 전송한다.

순서 번호와 확인응답 번호

이 두 필드는 TCP의 신뢰적인 데이터 전송 서비스의 중대한 부분이다.

순서 번호

TCP는 데이터를 구조화되어 있지 않고 단지 순서대로 정렬되어 있는 바이트 스트림으로 본다.

세그먼트에 대한 순서 번호는 세그먼트에 있는 첫 번째 바이트의 바이트 스트림 번호다.

e.g.,

데이터 스트림은 500,000 바이트로 구성된 파일이라고 가정한다.
MSS는 1,000 바이트
데이터 스트림의 첫 번째 바이트는 0으로 설정한다.

아래 그림처럼 TCP는 데이터 스트림으로부터 500개의 세그먼트들을 구성하며, 각 세그먼트가 할당받는 순서 번호는 다음과 같다.

각각의 순서 번호는 적절한 TCP 세그먼트의 헤더 내부의 순서 번호 필드에 삽입된다.

확인응답 번호

TCP는 전이중 방식임을 상기하자.
(호스트 A가 호스트 B로 데이터를 송신하는 동안에 호스트 B로부터 데이터를 수신하게 해줌)

호스트 B로부터 도착한 각 세그먼트는 B로부터 A로 들어온 데이터에 대한 순서 번호를 갖는다.

호스트 A가 자신의 세그먼트에 삽입하는 확인응답 번호는 호스트 A가 호스트 B로부터 기대하는 다음 바이트의 순서 번호다.

e.g.,
호스트 A가 호스트 B로부터
0 ~ 535의 바이트를 포함하는 어떤 세그먼트와 900 ~ 1,000의 바이트를 포함하는 또 다른 세그먼트를 수신했다고 가정하자.

(어떤 이유 때문인지 몰라도, 호스트 A는 그 사이 536~899의 바이트를 아직 수신하지 않았음)

호스트 A는 B의 데이터 스트림을 재생성하기 위해 536번째(와 그 다음의) 바이트를 아직 기다리고 있다.

그러므로 B에 대한 A의 다음 세그먼트이 확인응답 번호 필드에 536을 가질 것이다.

TCP는 스트림에서 첫 번째 잃어버린 바이트까지의 바이트들까지만 확인응답하기 때문에,
TCP는 누적 확인응답(cumulative acknowledgment)을 제공한다고 한다.

위 예에서 호스트 A는 세 번째 세그먼트(900~1,000 값의 바이트)를 두 번째 세그먼트(536~899 값의 바이트)가 수신되기 전에 수신했다.

즉, 세 번째 세그먼트는 순서가 틀리게 도착했다.

이 상황에서 호스트는 어떻게 행동을 할까?

TCP RFC는 TCP 연결에서 순서가 바뀐 세그먼트를 수신할 때 호스트가 어떤 행동을 취해야 하는지에 대한 어떤 규칙도 부여하지 않았고,
TCP 구현 개발자에게 맡기고 있다.

두 가지 선택지

수신자가 순서가 바뀐 세그먼트를 즉시 버린다.
수신자는 순서가 바뀐 데이터를 보유하고, 빈 공간에 잃어버린 데이터를 채우기 위해 기다린다.

후자가 네트워크 대역폭 관점에서는 효율적이며, 실제에서도 취하는 방법이다.

텔넷: 순서 번호와 응답확인 번호 사례연구

텔넷(Telnet)

원격 로그인을 위해 사용되는 유명한 애플리케이션 계층 프로토콜
TCP 상에서 실행되며, 한 쌍의 호스트들 사이에서 동작하도록 설계되었다.

호스트 A가 호스트 B로 텔넷 세션을 시작한다고 가정하자.

호스트 A가 세션을 시작하므로 클라이언트
호스트 B는 서버

세그먼트의 순서 번호 = 데이터 필드 안에 있는 첫 번째 바이트의 순서 번호

클라이언트의 초기 순서 번호 : 42 → 클라이언트에서 송신된 첫 번째 세그먼트는 순서 번호 42를 가진다.
서버의 초기 순서 번호 : 79 → 서버에서 송신된 첫 번째 세그먼트는 순서 번호 79를 가질 것이다.

확인응답 번호 = 호스트가 기다리는 데이터의 다음 바이트의 순서 번호

TCP 연결이 설정된 후에 어떤 데이터도 송신되기 전,

클라이언트는 바이트 79를 기다리고 있다.
서버는 바이트 42를 기다리고 있다.

사용자가 하나의 문자 ‘C’를 입력하고, 커피를 마신다고 가정하자.

위 그림처럼 3개의 세그먼트가 송신된다. = 세 방향 핸드셰이크(three-way handshake)

1️⃣ 첫 번째 세그먼트

클라이언트에서 서버로 송신된다.
순서 번호 필드 안에 42를 가진다.

2️⃣ 두 번째 세그먼트

서버에서 클라이언트로 송신된다.
두 가지 목적을 가진다.
1. 수신하는 서버에게 데이터에 대한 확인응답을 제공
2. 확인응답 필드 안에 43을 넣음으로써,
  (1) 서버는 클라이언트에게 바이트 42를 성공적으로 수신했고
  (2) 앞으로 바이트 43을 기다린다는 것을 말해준다.
3. 문자 ‘C’를 반대로 반향되도록 하는 것두 번째 세그먼트는 TCP 연결의 서버-클라이언트 데이터 흐름의 최초 순서 번호인 순서 79를 갖는다.
  (이는 서버가 보내는 데이터의 맨 첫번째 바이트)
4. → 그의 데이터 필드에 ‘C’의 ASCII 표현을 한다.

클라이언트/서버 데이터에 대한 확인응답은 서버와 클라이언트 간에서 데이터를 운반하는 세그먼트 안에서 전달된다.
= 확인응답은 서버-클라이언트 데이터 세그먼트 상에서 피기백된다(piggybacked)

3️⃣ 세 번째 세그먼트

클라이언트에서 서버로 송신된다.
목적 : 서버로부터 수신한 데이터에 대한 확인응답을 하는 것
- 이 세그먼트는 빈 데이터 필드를 갖는다.
- 즉, 확인응답은 어떤 클라이언트-서버 데이터와 함께 피기백되지 않는다.
세그먼트는 확인응답 필드 안에 80을 갖는다.
- 클라이언트가 순서 번호 79의 바이트를 통해 바이트의 스트림을 수신했기 때문이다.
- 앞으로 80으로 시작하는 바이트를 기다린다.

이 세그먼트가 데이터를 포함하지 않는데도 순서 번호를 갖는다는 것이 이상하지만,
TCP가 순서 번호 필드를 갖고 있으므로 세그먼트 역시 어떤 순서 번호를 가져야 한다.

3.5.3 왕복 시간(RTT) 예측과 타임아웃

TCP는 손실 세그먼트를 발견하기 위해 타임아웃/재전송 매커니즘을 사용한다.

타임아웃은 연결의 왕복 시간(round-trip time, RTT)보다 좀 커야 한다.

왕복 시간 예측

왕복 시간(round-trip time, RTT) : 세그먼트가 전송된 시간부터 긍정 확인응답될 때까지의 시간

TCP가 송신자와 수신자 사이에 왕복 시간을 어떻게 예측하는지에 대하여 알아보자.

✅ SampleRTT라고 표시되는 세그먼트에 대한 RTT 샘플 : 세그먼트가 송신된 시간(IP에게 넘겨진 시간)으로부터 그 세그먼트에 대한 긍정응답이 도착한 시간까지의 시간 길이

대부분의 TCP는 한 번에 하나의 SampleRTT 측정만을 시행한다.

즉, 어떤 시점에서 SampleRTT는 전송되었지만 현재까지 확인응답이 없는 세그먼트 중 하나에 대해서만 측정된다.
이는 대략 왕복 시간마다 SampleRTT의 새로운 값을 얻게 한다.

✅ SampleRTT 값은 라우터에서의 혼잡과 종단 시스템에서의 부하 변화 때문에 세그먼트마다 다르기 때문에
대체로 RTT를 추정하기 위해 SampleRTT 값의 평균값을 채택한다.

→ TCP는 SampleRTT 값의 평균(EstimatedRTT)을 유지한다.

EstimatedRTT = (1 - α) × EstimatedRTT + α × SampleRTT
(권장되는 α의 값 : 0.125)

EstimatedRTT는 SampleRTT의 가중평균(weighted average)이다.

이 가중평균은 예전 샘플보다 최근 샘플에 높은 가중치를 준다.
최신 샘플들이 네트워크상의 현재 혼잡을 더 잘 반영한다. → 지수적 가중 이동 평균(exponential weighted moving average, EWMA)

아래는 TCP 연결에 대해 α = 1/8의 값에 대한 SampleRTT 값들과 EstimatedRTT를 보여준다.

✅ DevRTT는 RTT 변화율을 의미한다.

이는 SampleRTT가 EstimatedRTT로부터 얼마나 많이 벗어나는지에 대한 측으로 정의한다.

DevRTT = (1 - β) × DevRTT + β × | SampleRTT - EstimatedRTT |
(권장되는 β의 값 : 0.25)

DevRTT는 SampleRTT와 EstimatedRTT 값 차이의 EWMA이다.

재전송 타임아웃 주기의 설정과 관리

주어진 EstimatedRTT 와 DevRTT 값에서, TCP 타임아웃 주기에는 어떤 값이 사용되어야 하는가?

주기는 EstimatedRTT보다 크거나 같아야 한다.
(그렇지 않다면 불필요한 재전송이 보내질 것)
EstimatedRTT보다 너무 크면 안된다.
(너무 크면 세그먼트를 잃었을 때, TCP는 세그먼트의 즉각적인 재전송을 하지 않게 됨)

→ 타임아웃값은 EstimatedRTT에 약간의 여윳값을 더한 값으로 설정하는 것이 바람직하다.

TimeoutInterval = EstimatedRTT + 4 × DevRTT

초기 TimeoutInterval의 값으로는 1초를 권고한다.
타임아웃이 발생할 때, TimeoutInterval의 값은 두 배로 하여
조만간 확인응답할 후속 세그먼트에게 발생할 수 있는 조기 타임아웃을 피하도록 한다.

3.5.4 신뢰적인 데이터 전송

TCP는 IP의 비신뢰적인 최선형 서비스에서 신뢰적인 데이터 전송 서비스(reliable data transfer service)를 제공한다.

프로세스가 자신의 수신 버퍼로부터 읽은 데이터 스트림이 손상되지 않음을 보장한다.
중복이 없다는 것과 순서가 유지된다는 것을 보장한다.

즉, 바이트 스트림은 송신자가 전송한 것과 같은 바이트 스트림이다.

타이머 관리는 상당한 오버헤드를 유발할 수 있다.

따라서 전송되었지만 확인응답이 안 된 다수의 세그먼트들이 있다고 하더라도,
권장되는 TCP 타이머 관리 절차에서는 오직 단일 재전송 타이머를 사용한다.

(이 장에서 설명하는 TCP 프로토콜은 단일 타이머를 따름)

TCP 송신자의 데이터 전송/재전송에 관련된 세 가지 주요 이벤트

1️⃣ 상위 애플리케이션으로부터 수신된 데이터

첫 번째 이벤트 발생으로,

TCP는 애플리케이션으로부터 데이터를 받고,
세그먼트로 이 데이터를 캡슐화하고,
IP에게 이 세그먼트를 넘긴다.

각 세그먼트는 세그먼트의 첫 번째 데이터 바이트의 바이트 열 번호인 순서 번호를 포함한다.
타이머가 이미 다른 세그먼트에 대해 실행 중이 아니면, TCP는 이 세그먼트를 IP로 넘길 때 타이머를 시작한다.

2️⃣ 타이머 타임아웃

TCP는 타임아웃 이벤트에 대해 타임아웃을 일으킨 세그먼트를 재전송하여 응답한다.
그리고 TCP의 타이머를 다시 시작한다.

3️⃣ 수신 확인응답 세그먼트(ACK) 수신

이 이벤트가 발생하면, TCP는 변수 SendBase와 ACK 값 y를 비교한다.

SendBase : 수신 확인응답이 확인되지 않은 / 가장 오래된 바이트의 순서번호
SendBase-1 : 수신자에게서 정확하게 차례대로 수신되었음을 알리는 마지막 바이트의 순서번호

TCP는 누적 확인응답을 사용하고, y는 y바이트 이전의 모든 바이트의 수신을 확인한다.

y > SendBase이면, ACK는 이전에 확인응답 안 된 하나 이상의 세그먼트들을 확인해준다.

송신자는 자신의 SendBase 변수를 갱신한다.
아직 확인응답 안 된 세그먼트들이 존재한다면 타이머를 다시 시작한다.

몇 가지 흥미로운 시나리오

TCP 프로토콜이 어떻게 작동하는지 몇 가지 간단한 시나리오를 통해 알아보자.

손실된 확인응답에 기인하는 재전송

호스트 A로부터 세그먼트가 호스트 B 측에서 수신되었음에도 B로부터 A로의 긍정 확인응답이 손실된다면

타임아웃이 발생한다.
호스트 A는 같은 세그먼트를 B에게 재전송한다.
호스트 B의 TCP는 재송신된 세그먼트의 바이트를 버린다.

세그먼트 100이 재전송되지 않는 경우

호스트 A가 연속해서 두 세그먼트를 전송한다.

호스트 A에서 타임아웃 이전에 어떠한 긍정 확인응답도 수신하지 못한다고 가정하자.

타임아웃 이벤트가 발생하면

호스트 A는 순서 번호 92로 첫 번째 세그먼트를 재전송한다.
타이머를 다시 시작한다.
새로운 타임아웃 이전에 두 번째 세그먼트에 대한 ACK가 도착하는 한, 두 번째 세그먼트는 재전송을 하지 않을 것이다.

누적 확인응답은 첫 번째 세그먼트의 재전송을 방지한다

호스트 A가 연속해서 두 세그먼트를 전송한다.

첫 번째 세그먼트의 긍정 확인응답이 네트워크에서 분실되었지만,
첫 번째 세그먼트의 타임아웃 전에 호스트 A가 긍정 응답번호 120의 긍정 확인응답을 수신하면

호스트 A는 호스트 B가 119바이트까지 모든 데이터를 수신했음을 알게 된다.
그러므로 호스트 A는 두 세그먼트 중 어느 것도 재전송하지 않는다.

TCP는 GBN인가 SR인가?

TCP 확인응답은 누적되고 올바르게 수신되지만, 순서가 잘못된 세그먼트는 수신자가 개별적으로 ACK를 받지 않는다.

TCP 송신자는 전송했지만 확인응답 안 된 바이트의 가장 작은 순서 번호, SendBase와 전송될 다음 바이트의 순서 번호, NextSeqNum을 유지해야 한다.

이런 관점에서 TCP는 GBN 형태의 프로토콜과 비슷해보이나, ’TCP에서는 올바르게 수신되었지만 순서가 바뀐 세그먼트들을 버퍼링한다’는 차이점이 존재한다.

e.g.,
패킷 n < N에 대한 긍정 확인응답이 손실되었지만,
나머지 N-1개의 긍정 확인 응답들은 타임아웃 전에 송신 측에 도달했다고 가정한다.

GBN : 패킷 n뿐만 아니라, 연속적인 패킷 n+1, n+2, … , N 모두를 재전송한다.
TCP
1. 세그먼트 n 하나만을 재전송
2. 세그먼트 n에 대한 타임아웃 전에 세그먼트 n+1에 대한 긍정 확인 응답이 도착한다면 세그먼트를 재전송하지 않는다.

TCP에서 수정제안된 선택적 확인응답(selective acknowledgment) : TCP 수신자가 마지막으로 올바로 수신된 ‘순서가 맞는’ 세그먼트에 대해 누적 확인응답을 하기보다는
‘순서가 틀린’ 세그먼트에 대해 선택적으로 확인응답을 하게 한다.

이를 선택적 재전송과 결합했을 경우, SR 프로토콜과 매우 유사하다.

따라서 TCP의 오류 복구 메커니즘은 GBN과 SR 프로토콜의 혼합으로 분류하는 것이 적당하다.

빠른 재전송

타임아웃이 유발하는 재전송의 문제 : 타임아웃의 주기가 때때로 비교적 길다.

긴 타임아웃 주기는 종단 간의 지연을 증가시키지만,
다행히도 송신자는 종종 중복 ACK에 의한 타임아웃이 일어나기 전에 패킷 손실을 발견한다.

중복 ACK(duplicate ACK) : 송신자가 이미 이전에 받은 확인응답에 대한 재확인응답 세그먼트 ACK

수신자가 중복 ACK를 보내는 이유

TCP는 부정 확인응답을 사용하지 않으므로, 수신자는 송신자에게 부정 확인 응답을 보낼 수 없다.

TCP 수신자가 기다리는 다음 것보다 더 큰 순서 번호를 가진 세그먼트를 받았을 때, TCP 수신자는 손실 세그먼트를 찾아낼 것이다.
수신자는 마지막으로 수신된 순차적인 바이트를 갖는 데이터를 그냥 다시 확인응답한다.
즉, 중복 ACK를 생성한다.

TCP ACK 생성 권고

이벤트 1️⃣
기다리는 순서 번호를 가진 ‘순서가 맞는’ 세그먼트의 도착
기다리는 순서 번호까지의 모든 데이터는 이미 확인응답된다.

TCP 수신자 동작 : 지연된 ACK

또 다른 ‘순서가 맞는’ 세그먼트의 도착을 위해 500 ms까지 기다린다.
만약 다음 ‘순서에 맞는’ 세그먼트가 이 기간에 도착하지 않으면, 그냥 ACK를 보낸다.

이벤트 2️⃣
기다리는 순서 번호를 가진 ‘순서가 맞는’ 세그먼트의 도착
ACK 전송을 기다리는 다른 하나의 ‘순서에 맞는’ 세그먼트가 있다.

TCP 수신자 동작 : 2개의 ‘순서가 맞는’ 세그먼트들을 ACK하기 위해, 하나의 누적된 ACK를 즉시 보낸다.

이벤트 3️⃣
기다리는 것보다 높은 순서 번호를 가진 ‘순서가 바뀐’ 세그먼트의 도착 격자가 발견된다.

TCP 수신자 동작 : 순서 번호가 다음의 기다리는 바이트(즉, 격차의 최솟값)를 나타내는 중복 ACK를 즉시 보낸다.

이벤트 4️⃣
수신 데이터에서 격차를 부분적으로 또는 모두 채우는 세그먼트의 도착

TCP 수신자 동작 : 그 세그먼트가 격차의 최솟값에서 시작한다고 하면, 즉시 ACK를 보낸다.

빠른 재전송(fast retransmit)

만약 TCP 송신자가 같은 데이터에 대해 3개의 중복 확인응답을 수신한다면,
이것은 ACK된 세그먼트의 다음 3개의 세그먼트가 분실되었음을 의미한다.

3개의 중복 ACK를 수신할 때, TCP는 세그먼트의 타이머가 만료되기 이전에 손실 세그먼트를 재전송한다.

아래 그림을 보면 두 번째 세그먼트를 잃어버린 경우, 타이머가 만료되기 전에 재전송되었다.

3.5.5 흐름 제어

TCP는 송신자가 수신자의 버퍼를 오버플로시키는 것을 방지하기 위해 애플리케이션에게 흐름 제어 서비스(flow-control service)를 제공한다.

→ 수신하는 애플리케이션이 읽는 속도와 송신자가 전송하는 속도를 같게 한다.

TCP 송신자는 IP 네트워크에서 혼잡 때문에 억제될 수도 있다. = 혼잡 제어(congestion control)

흐름 제어와 혼잡 제어는 명백히 각기 다른 목적으로 수행된다. (잘 구별하여야 함)

과정

TCP는 수신 윈도(receive window)라는 변수를 유지하여 흐름 제어를 제공한다.

수신 측에서 가용한 버퍼 공간이 얼마나 되는지를 송신자에게 알려주는데 사용된다.
TCP는 전이중(full-duplex)이므로 연결의 각 측의 송신자는 별개의 수신 윈도를 유지한다.

e.g., TCP 연결상에서 호스트 A가 호스트 B에게 큰 파일을 전송한다고 가정

호스트 B는 이 연결에 수신 버퍼를 할당한다.
(이때 할당된 수신 버퍼의 크기 : RcvBuffer)
호스트 B의 애플리케이션 프로세스는 버퍼로부터 데이터를 읽으며 다음과 같은 변수들을 정의한다.
- LastByteRead : 호스트 B의 애플리케이션 프로세스에 의해 버퍼로부터 읽힌 데이터 스트림의 마지막 바이트 번호
  - LastByteRcvd : 호스트 B에서 네트워크로부터 도착하여 수신 버퍼에 저장된 데이터 스트림의 마지막 바이트 번호
  - rwnd
  - 수신 윈도 = 버퍼의 여유 공간
  - 시간에 따라 여유 공간은 변하므로 이 변수는 동적이다.

LastByteRcvd - LastByteRead ≤ RcvBuffer

rwnd = RcvBuffer - [LastByteRcvd - LastByteRead]

호스트 B는 호스트 B가 호스트 A에게 전송하는 모든 세그먼트의 윈도 필드에 현재 rwnd 값을 설정한다.
이를 통해 호스트 A에게 연결 버퍼에 얼마만큼의 여유 공간이 있는지를 알려준다.
호스트 A는 두 변수 LastByteSent와 LastByteAcked를 유지한다.
LastByteSent - LastByteAcked = 호스트 A가 이 연결에 전송 확인응답이 안 된 데이터의 양

rwnd의 값보다 작은 확인응답 안 된 데이터의 양을 유지함으로써 호스트 A는 호스트 B의 수신 버퍼에 오버플로가 발생하지 않는다는 것을 확신한다.

호스트 A는 연결된 동안 다음의 내용을 보장한다.

LastBySent - LastByteAcked ≤ rwnd

문제점과 해결법

호스트 B의 수신 버퍼는 rwnd = 0으로서 가득 찼고
호스트 A에게 rwnd = 0이라고 알린 후 호스트 B는 호스트 A에게 전송할 것이 없는 경우

호스트 B에서의 애플리케이션 프로세스가 버퍼를 비우더라도,
TCP는 호스트 A에게 새로운 rwnd로 새로운 세그먼트를 전송하지 않는다.

즉, TCP는 전송할 데이터가 있거나, 전송해야 할 확인응답을 가진 경우에만 호스트 A에게 세그먼트를 전송할 것이다.

→ 호스트 A는 차단되고 더는 데이터를 전송할 수 없다.

따라서 TCP 명세서는 호스트 A가 호스트 B의 수신 윈도가 0일 때, 1바이트 데이터로 세그먼트를 계속해서 전송하도록 요구한다.

3.5.6 TCP 연결 관리

TCP 연결이 어떻게 설정되고 해제되는가?

하나의 호스트(클라이언트)에서 운영되는 프로세스가 다른 호스트(서버) 안의 또 다른 프로세스와 연결을 시작하길 원한다고 가정하자.

클라이언트 애플리케이션 프로세스는 서버에 있는 프로세스와 연결 설정하기를 원한다는 것을 클라이언트 TCP에게 알린다.
클라이언트 안의 TCP는 다음과 같은 방법으로 TCP를 이용해 서버와 TCP 연결 설정을 시작한다.

연결의 설정 : 세 방향 핸드셰이크(three-way handshake)

1단계

클라이언트 측 TCP는 서버 TCP에게 특별한 TCP 세그먼트, SYN 세그먼트를 송신한다.
- 애플리케이션 계층 데이터를 포함하지 않는다.
- 세그먼트 헤더에 SYN 비트를 1로 설정한다.
클라이언트는 최소 순서 번호(client_isn)를 임의로 선택하고, 최초의 TCP SYN 세그먼트의 순서 번호 필드에 이 번호를 넣는다.
이 세그먼트는 IP 데이터그램 안에서 캡슐화되고 서버로 송신된다.

2단계

TCP SYN 세그먼트를 포함하는 IP 데이터그램이 서버 호스트에 도착하면,

서버는 데이터그램으로부터 TCP SYN 세그먼트를 추출한다.
연결에 TCP 버퍼와 변수를 할당한다.
클라이언트 TCP로 연결 승인 세그먼트, SYNACK 세그먼트를 송신한다.
- 애플리케이션 계층 데이터를 포함하지 않는다.
- SYN 비트는 1로 설정된다.
- TCP 세그먼트 헤더의 확인응답 필드는 client_isn+1로 설정된다.
- 서버는 자신의 최초의 순서 번호(server_isn)를 선택하고, TCP 세그먼트 헤더의 순서 번호 필드에 이 값을 넣는다.

3단계

연결 승인 세그먼트를 수신하면,

클라이언트는 연결에 버퍼와 변수를 할당한다.
클라이언트 호스트는 서버로 또 다른 세그먼트를 송신한다.
1. 클라이언트는 TCP 세그먼트 헤더의 확인응답 필드 안에 server_isn+1 값을 넣어, 서버의 연결 승인 세그먼트를 확인한다.
2. 연결이 설정되었기 때문에 SYN 비트는 0으로 설정된다.

세 번째 단계는 클라이언트에서 서버로의 데이터를 세그먼트 페이로드에서 운반할 수 있다.

위의 세 단계가 완료되면,

클라이언트와 서버 호스트들은 각각 서로에게 데이터를 포함하는 세그먼트를 보낼 수 있다.
SYN 비트는 0으로 설정된다.

연결의 종료

TCP 연결에 참여하는 두 프로세스 중 하나가 연결을 끊을 수 있다.

연결이 끝날 때, 호스트의 ‘자원’(버퍼와 변수)는 회수된다.

클라이언트 애플리케이션 프로세스는 종료 명령을 내린다.
이는 클라이언트 TCP가 서버 프로세스에게 특별한 TCP 세그먼트를 보내도록 한다.
(FIN 비트를 1로 설정)
서버가 이 세그먼트를 수신하면, 서버는 클라이언트에게 확인응답 세그먼트를 보낸다.
그 다음에 FIN 비트가 1로 설정된 자신의 종료 세그먼트를 송신한다.
마지막으로 클라이언트는 서버의 종료 세그먼트에 확인응답을 한다.
이 시점에서 두 호스트의 모든 자원은 할당이 해제된다.

TCP 상태(TCP state)

TCP 연결이 존재하는 동안 각 호스트에서 동작하는 TCP 프로토콜은 다양한 TCP 상태를 두루 전이한다.

아래의 두 그림은 클라이언트가 연결 해제를 시작한다는 것을 가정한다.

클라이언트 TCP에서 TCP 상태 변이의 일반 순서

서버 TCP에서 TCP 상태 변이의 일반 순서

SYN 플러드 공격

TCP의 세 방향 핸드셰이크

서버는 수신된 SYN에 대한 응답으로 연결 변수와 버퍼를 할당하고 초기화한다.
그 다음, 서버는 응답으로 SYNACK을 보내고 클라이언트의 ACK 세그먼트를 기다린다.

클라이언트가 이 세 방향 핸드셰이크의 세 번째 단계를 완료하기 위한 ACK를 보내지 않으면
결국(종종 1분 이상 후에) 서버가 절반만 열린 연결을 종료하고 할당된 자원을 회수한다.

→ 이는 SYN 플러드 공격의 무대가 된다.

SYN 플러드 공격(SYN flood attack)

고전적인 서비스 거부(Denial of Service, DoS) 공격

공격자는 핸드셰이크의 세 버너째 단계를 완료하지 않은 상태에서 무수한 TCP SYN 세그먼트를 보낸다.
서버의 연결 자원이 반쪽 연결에 할당된다.
결국 서버의 연결 자원이 소진됨에 따라 합법적인 클라이언트들이 서비스 거부가 된다.

SYN 쿠키

이는 SYN 플러드 공격에 대한 방어책으로, 현재 대부분의 운영체제에 존재하고 있다.

동작 방법

서버는 SYN에 대해 반만 열린(half-open) TCP 연결을 만들지 않고, 초기 TCP 순서 번호(쿠키, cookie)를 만든다.
- 서버가 SYN 세그먼트를 받을 때, 그 세그먼트가 정당한 사용자로부터 또는 공격자로부터 온 것인지 구별할 수 없기 때문이다.
- 해시 함수에 아래의 항목들을 사용하여 쿠키를 생성한다.
  - 비밀번호
  - SYN 세그먼트의 출발지와 목적지 IP 주소들과 포트번호
서버는 이 특별한 초기 순서 번호를 가진 SYNACK 패킷을 보낸다.
서버는 SYN에 관련된 쿠키나 어떤 다른 상태 정보를 기억하지 않는다.
합법적인 클라이언트는 ACK 세그먼트를 회신한다.
이 ACK를 받은 서버는 ACK가 이전에 보낸 일부 SYN에 관한 것인지 확인해야 한다.
- 이는 이전에 보낸 일부 SYN에 관한 것인지는 쿠키를 통해 확인한다.
- 서버는 SYNACK에 있는 출발지와 목적지 IP 주소와 포트번호, 비밀번호를 사용해서 동일한 해시 함수를 실행한다.

만약 함수의 결과에 1을 더한 것이 클라이언트의 SYNACK에 있는 확인응답 번호(쿠키)와 같다면
서버는 ACK가 초기 SYN 세그먼트에 관련된 것, 즉 올바른 것이라고 결론짓는다.

→ 이후 서버는 소켓을 가지고 완전하게 열린 연결을 만든다.

만약 클라이언트가 ACK 세그먼트를 회신하지 않으면
서버가 처음의 가짜 SYN에 대해 어떤 자원도 할당하지 않았기 때문에 처음의 SYN은 서버에 해를 끼치지 못한다.

Chapter 3 - 1. 트랜스포트 계층 서비스 및 개요, 2. 다중화와 역다중화, 3. 비연결형 트랜스포트: UDP

ssun_bear — Tue, 9 Jul 2024 20:14:22 +0900

3.1 트랜스포트 계층 서비스 및 개요

트랜스포트 계층 프로토콜은 각기 다른 호스트에서 동작하는 애플리케이션 프로세스 간의 논리적 통신(logical communication)을 제공한다.

= 애플리케이션의 관점에서 보면, 프로세스들이 동작하는 호스트들이 직접 연결된 것처럼 보인다.

아래 그림처럼, 트랜스포트 계층 프로토콜은 네트워크 라우터가 아닌 종단 시스템에서 구현된다.

송신 측의 트랜스포트 계층은 송신 애플리케이션 프로세스로부터 수신한 메시지를 트랜스포트 계층 패킷으로 변환한다.
(이는 트랜스포트 계층 세그먼트(segment)라고 부른다. : L4-PDU)
1. 애플리케이션 메시지를 작은 조각으로 분할한다.
2. 각각의 조각에 트랜스포트 계층 헤더를 추가한다.
트랜스포트 계층은 송신 종단 시스템에 있는 네트워크 계층으로 세그먼트를 전달한다.
- 세그먼트는 네트워크 계층 패킷(데이터그램(datagram) : L3-PDU) 안에 캡슐화되어(encapsulate) 목적지로 전달된다.
네트워크 라우터는 오로지 데이터그램의 네트워크 계층 필드에 대해 동작한다.
즉, 데이터그램 안에 캡슐화된 트랜스포트 계층 세그먼트의 필드를 검사하지 않는다.
수신 측에서 네트워크 계층은 데이터그램으로부터 트랜스포트 계층 세그먼트를 추출하고 트랜스포트 계층으로 세그먼트를 보낸다.
트랜스포트 계층은 수신 애플리케이션에서 세그먼트 내부의 데이터를 이용할 수 있도록 수신된 세그먼트를 처리한다.

네트워크 애플리케이션에서는 하나 이상의 트랜스포트 계층 프로토콜을 사용할 수 있다.

e.g., 인터넷 : TDP, UDP라는 두 가지 프로토콜을 가지고 있다.

3.1.1 트랜스포트 계층과 네트워크 계층 사이의 관계

트랜스포트 계층 프로토콜은 각기 다른 호스트에서 동작하는 프로세스들 사이의 논리적 통신을 제공한다.

네트워크 계층 프로토콜은 호스트들 사이의 논리적 통신을 제공한다.

트랜스포트 계층 프로토콜은 종단 시스템에 존재하며,
애플리케이션 프로세스에서 네트워크 계층 사이에서 메시지를 운반하는 역할을 한다.
메시지가 네트워크 계층 내부에서 어떻게 이동하는지는 언급하지 않는다.
즉, Application을 다루는(작성하거나 run 하는) 입장에서는 앞으로 이루어질 physical connection을 염려하지 않아도 된다.

트랜스포트 계층이 제공할 수 있는 서비스는 하위 네트워크 계층 프로토콜의 서비스 모델에 의해 제약받는다.
e.g.,
네트워크 계층 프로토콜이 호스트 사이에서 전송되는 트랜스포트 계층 세그먼트에 대한 지연 보장이나 대역폭 보장을 제공할 수 없다면,
트랜스포트 계층 프로토콜은 프로세스끼리 전송하는 메시지에 대한 지연 보장이나 대역폭 보장을 제공할 수 없다.

하위 네트워크 프로토콜이 상응하는 서비스를 제공하지 못할 때도, 특정 서비스는 트랜스포트 프로토콜에 의해 제공될 수 있다.
e.g.,
하위 네트워크 프로토콜이 비신뢰적일 때, 트랜스포트 계층이 애플리케이션에게 신뢰적인 데이터 전송 서비스를 제공할 수 있다.
(비신뢰적이다 = 패킷을 분실하거나, 손상시키거나, 복사본을 만든다)

3.1.2 인터넷 트랜스포트 계층의 개요

TCP & UDP

Transmission Control Protocol, TCP

신뢰적이고 연결지향형 서비스를 제공한다. (reliable data transfer)
혼잡 제어(congestion control) : 혼잡한 네트워크 링크에서 각 TCP 연결이 링크의 대역폭을 공평하게 공유하여 통과하도록 해준다.

User Datagram Protocol, UDP

비신뢰적이고 비연결형인 서비스를 제공한다.
UDP 트랜스포트 프로토콜을 사용하는 애플리케이션은 허용이 되는 한, 그것이 만족하는 어떤 속도로든 전송할 수 있다.

세그먼트와 데이터그램

세그먼트(segment) : 트랜스포트 계층 패킷을 일컫는 말
TCP에 대한 패킷을 세그먼트(segment), UDP에 대한 패킷을 데이터그램(datagram)이라는 용어로 나타내기도 한다.

이 책에서는 TCP와 UDP 패킷을 모두 세그먼트라고 지칭, 네트워크 계층 패킷에 대해서는 데이터그램이라는 용어를 사용한다.

인터넷 프로토콜(Internet Protocol, IP)

인터넷의 네트워크 계층 프로토콜

IP 서비스 모델은 호스트들 간에 논리적 통신을 제공하는 최선형 전달 서비스(best-effort delivery service)

즉, IP가 통신하는 호스트들 간에 세그먼트를 전달하기 위해 최대한 노력하지만, 어떤 보장도 하지 않는다.

세그먼트의 전달 보장 X
순서 보장 X
내부 데이터의 무결성(integrity) 보장 X

→ IP는 비신뢰적인 서비스(unreliable service)이다.

각 호스트는 적어도 하나의 IP 주소를 갖고 있다.

UDP와 TCP의 서비스 모델

트랜스포트 계층 다중화(transport-layer mulitplexing)와 역다중화(demultiplexing)

‘호스트 대 호스트 전달’ → ‘프로세스 대 프로세스 전달’

종단 시스템 사이의 IP 전달 서비스를 / 종단 시스템에서 동작하는 두 프로세스 간의 전달 서비스로 확장한다.

헤더에 오류 검출 필드를 포함

이로써 무결성 검사를 제공한다.

3.2 다중화와 역다중화

트랜스포트 계층 다중화(multiplexing)와 역다중화(demultiplexing)
네트워크 계층이 제공하는 호스트 대 호스트 전달 서비스에서
호스트에서 동작하는 애플리케이션에 대한 프로세스 대 프로세스 전달 서비스로 확장하는 과정

목적지 호스트에서의 트랜스포트 계층은 바로 아래의 네트워크 계층으로부터 세그먼트를 수신한다.트랜스포트 계층은 호스트에서 동작하는 해당 애플리케이션 프로세스에게 이 세그먼트의 데이터를 전달하는 의무를 가진다.

트랜스포트 계층은 세그먼트(데이터)를 중간 매개자인 소켓(socket)에게 전달한다.
- 프로세스는 네트워크 애플리케이션의 한 부분으로서 소켓을 가지고 있다.
- 이는 네트워크에서 프로세스로, 한 프로세스로부터 네트워크로 데이터를 전달하는 출입구 역할을 한다.
- 각각의 소켓은 하나의 유일한 식별자, 포트 번호(port number)를 가진다.

Q. 수신한 트랜스포트 계층 세그먼트는 어떻게 적절한 소켓으로 향하는가?

각각의 트랜스포트 계층 세그먼트는 세그먼트에 필드 집합을 가지고 있으며,
트랜스포트 계층은 수신 소켓을 식별하기 위해 이러한 필드를 검사한 후 해당 소켓으로 보낸다.

✅ 역다중화(demultiplexing)

트랜스포트 계층 세그먼트의 데이터를 올바른 소켓으로 전달하는 작업을 말한다.

✅ 다중화(multiplexing)

출발지 호스트에서 소켓으로 부터 데이터를 모으고,
이에 대한 세그먼트를 생성하기 위해 각 데이터에 헤더 정보로 캡슐화(encapsulation) 한다.
그 세그먼트들을 네트워크 계층으로 전달한다.

트랜스포트 계층 다중화의 두 가지 요구사항

소켓은 유일한 식별자를 갖는다. (= 포트 번호)
각 세그먼트는 세그먼트가 전달될 적절한 소켓을 가리키는 특별한 필드를 갖는다.
- 출발지 포트 번호 필드(source port number field)
- 목적지 포트 번호 필드(destination port number field)

역다중화 서비스의 순서

호스트의 각 소켓은 포트 번호를 할당받는다.
세그먼트가 호스트에 도착하면,
1. 트랜스포트 계층은 세그먼트 안의 목적지 포트 번호를 검사하고,
2. 그에 상응하는 소켓으로 세그먼트를 보낸다.
세그먼트의 데이터는 소켓을 통해 해당되는 프로세스로 전달된다.

이는 UDP의 기본적인 동작 방식과 같다.

비연결형 다중화와 역다중화

UDP 소켓은 목적지 IP 주소와 목적지 포트 번호로 구성된 두 요소로 된 집합에 의해 식별된다.

따라서 만약 2개의 UDP 세그먼트가 같은 목적지 IP 주소와 목적지 포트 번호를 가진다면,
이 2개의 세그먼트는 같은 목적지 소켓을 통해 같은 프로세스로 향할 것이다.

그렇다면 출발지 포트 번호는 무슨 목적으로 사용되는가?

출발지 포트 번호는 ‘회신 주소’의 한 부분으로 사용된다.

아래 그림처럼, B가 A에게로 세그먼트를 보내기를 원할 때
B에서 A로 가는 세그먼트의 목적지 포트 번호는 A로부터 B로 가는 세그먼트의 출발지 포트 번호로부터 가져온다.

연결지향형 다중화와 역다중화

TCP 소켓

TCP 소켓은 4개 요소의 집합(four-tuple)에 의해 식별된다.

출발지 IP 주소
출발지 포트 번호
목적지 IP 주소
목적지 포트 번호

특히, 다른 출발지 IP 주소 또는 다른 출발지 포트 번호를 가지고 도착하는 2개의 TCP 세그먼트는 2개의 다른 소켓으로 향하게 된다.
(초기 연결 설정 요청을 전달하는 TCP는 제외)

TCP 연결 설정

TCP 서버 애플리케이션은 환영(welcome) 소켓을 갖고 있다.
이 소켓은 포트 번호 12000을 가진 TCP 클라이언트로부터 연결 설정 요청을 기다린다. (아래 그림 참고)
TCP 클라이언트는 소켓을 생성하고, 연결 설정 요청 세그먼트를 보낸다.
- 연결 설정 요청은 목적지 포트 번호 12000과 TCP 헤더에 설정된 특별한 연결 설정 비트(3.5절에서 설명)를 가진 TCP 세그먼트를 통해 보내진다.
- 이 세그먼트는 출발지 포트 번호를 포함하는데, 이것은 클라이언트가 선택한 번호이다.
서버 프로세스로 동작하는 컴퓨터의 호스트 운영체제가 목적지 포트 12000을 포함하는 연결 요청 세그먼트를 수신하면,
이 세그먼트를 포트 번호 12000으로 연결 수락을 기다리는 서버 프로세스로 보낸다.
서버는 연결 요청 세그먼트의 4개 요소의 집합에 주목한다.
- 새롭게 생성된 연결 소켓은 4개 요소의 집합의 네 가지 값에 의해 식별된다.
- 따라서 그다음에 도착하는 세그먼트의 출발지 포트, 출발지 IP 주소, 목적지 포트, 목적지 IP 주소가 전부 일치하면,
  그 세그먼트는 이 소켓으로 역다중화될 것이다.
서버 호스트는 동시에 존재하는 많은 TCP 소켓을 지원할 수 있다.

웹 서버와 TCP

서버는 각기 다른 클라이언트가 보낸 세그먼트를 출발지 IP 주소와 출발지 포트 번호로 구별한다.

같은 웹 서버 애플리케이션과 통신하기 위해 같은 목적지 포트 번호(80)를 이용하는 두 클라이언트에 대한 예시를 보자.

호스트 C가 서버 B로 2개의 HTTP 세션을 시작
호스트 A가 서버 B로 하나의 HTTP 세션을 시작

호스트 A, 호스트 C, 서버 B는 각자 유일한 IP 주소인 A, C, B를 각각 가지고 있다.

호스트 C는 2개의 출발지 포트 번호(26145, 7532)를 자신의 HTTP 연결에 할당한다.
호스트 A는 호스트 C와 독립적으로 출발지 포트 번호를 선택하므로, 이것 또한 HTTP 연결에 출발지 포트로 26145를 할당할 수 있다.

이렇게 하더라도, 2개의 연결은 다른 출발지 IP 주소를 가지기 때문에 서버 B는 여전히 올바르게 역다중화할 수 있다.

웹 서버는 각각의 연결에 따라서 새로운 프로세스를 만든다.

이들 프로세스는 각자 연결 소켓을 가지며, 이 연결 소켓을 통해 HTTP 요청을 수신하고, HTTP 응답을 전송한다.

그러나 연결 소켓과 프로세스 사이에 항상 일대일 대응이 이루어지는 것이 아니다.

오늘날의 많은 고성능 웹 서버는 하나의 프로세스만 사용한다.
각각의 새로운 클라이언트 연결을 위해 새로운 연결 소켓과 함께 새로운 스레드(thread)를 생성한다.

Persistent & Non-persistent HTTP

지속적인(persistent) HTTP

지속적인 연결의 존속 기간에 클라이언트와 서버는 같은 서버 소켓을 통해 HTTP 메시지를 교환한다.

비지속적인(non-persistent) HTTP

모든 요청/응답마다 새로운 TCP 연결이 생성되고 종료된다.

3.3 비연결형 트랜스포트: UDP

UDP는 트랜스포트 계층 프로토콜이 할 수 있는 최소 기능으로 동작한다.

다중화/역다중화 기능
간단한 오류 검사 기능

이외에는 IP에 아무것도 추가하지 않는다.

동작 순서

애플리케이션 프로세스로부터 메시지를 가져와서
다중화/역다중화 서비스에 필요한 출발지 포트 번호 필드와 목적지 포트 번호 필드를 첨부한다.
출발지 호스트의 IP 주소 필드, 목적지 호스트의 IP 주소 필드를 추가한 후에
최종 트랜스포트 계층 세그먼트를 네트워크 계층으로 넘겨준다.
네트워크 계층은 트랜스포트 계층 세그먼트를 IP 데이터그램으로 캡슐화하고,
세그먼트를 수신 호스트에게 전달한다.
세그먼트가 수신 호스트에 도착한다면,
UDP는 세그먼트의 데이터를 해당하는 애플리케이션 프로세스로 전달하기 위해 목적지 포트 번호를 사용한다.

UDP는 세그먼트를 송신하기 전에 송신 트랜스포트 계층 개체들과 수신 트랜스포트 계층 개체들 사이에 핸드셰이크를 사용하지 않는다.

→ 비연결형

DNS

DNS는 전형적으로 UDP를 사용하는 애플리케이션 계층 프로토콜의 예이다.

만약 질의 호스트가 응답을 수신하지 못하면 질의를 다른 네임 서버로 송신하거나, 애플리케이션에게 응답을 수신할 수 없음을 통보한다.

UDP의 장점

많은 애플리케이션은 다음과 같은 이유로 UDP에 더 적합하다.

무슨 데이터를 언제 보낼지에 대해서 애플리케이션 레벨에서 더 정교한 제어가 가능하다

UDP 하에서 애플리케이션 프로세스가 데이터를 UDP에 전달하자마자
UDP는 데이터를 UDP 세그먼트로 만들고, 그 세그먼트를 즉시 네트워크 계층으로 전달한다.

실시간 애플리케이션에서는 UDP를 사용하고, 필요한 어떤 추가 기능을 구현할 수 있다.

↔︎ TCP

혼잡 제어 매커니즘이 존재한다.
즉, 목적지 호스트들과 출발지 호스트들 사이에서 하나 이상의 링크가 과도하게 혼잡해지면 트랜스포트 계층 TCP 송신자를 제한한다.
신뢰적인 전달이 얼마나 오래 걸리는지에 관계없이
목적지가 세그먼트의 수신 여부를 확인응답할 때까지 데이터의 세그먼트 재전송을 계속한다.

연결 설정이 없다

UDP는 TCP의 세 방향 핸드셰이크(three-way handshake)와 같은 공식적인 사전준비 없이 전송한다.

따라서 UDP는 연결을 설정하기 위한 어떤 지연도 없다.

연결 상태가 없다

UDP는 연결 상태를 유지하지 않으며, 연결 상태에 대한 그 어떠한 파라미터도 기록하지 않는다.

따라서 일반적으로 특정 애플리케이션 전용 서버는 애플리케이션 프로그램이 UDP에서 동작할 때
좀 더 많은 액티브 클라이언트를 수용할 수 있다.

작은 패킷 헤더 오버헤드

TCP는 세그먼트마다 20바이트의 헤더 오버헤드를 갖지만, UDP는 단지 8바이트의 오버헤드를 갖는다.

UDP의 단점

UDP는 혼잡 제어(congestion control)를 하지 않는다.

혼잡 제어는 네트워크가 꼭 필요한 작업을 할 수 없게 되는 폭주 상태에 빠지는 것을 막기 위해 반드시 필요하다.

만약 모두가 혼잡 제어를 사용하지 않고 높은 비트의 비디오 스트리밍을 시작한다면,

라우터에 많은 패킷 오버플로가 발생
→ 소수의 UDP 패킷만이 출발지-목적지 간의 경로를 무사히 통과할 것이다.
제어되지 않은 UDP 송신자에 의해 발생한 높은 손실률은 그 손실률을 감소시키기 위해 TCP 송신자들이 속도를 줄이도록 할 것
→ TCP 세션의 혼잡이 발생할 것이다.

UDP를 통한 신뢰적인 데이터 전송

UDP는 비신뢰적인 서비스를 제공하지만,
애플리케이션 자체에서 신뢰성을 제공한다면 UDP를 사용하면서 신뢰적인 데이터 전송이 가능해진다.

e.g., 구글의 크롬 브라우저에서 사용되는 QUIC(Quick UDP Internet Connection) 프로토콜

이는 기본 트랜스포트 프로토콜로 UDP를 사용하고, UDP 위에 애플리케이션 계층 프로토콜의 안정성을 구현한다.

3.3.1 UDP 세그먼트 구조

애플리케이션 데이터

UDP 데이터그램의 데이터 필드에 위치한다.

포트 번호

목적지 호스트가 목적지 종단 시스템에서 동작하는 (역다중화 기능을 수행하는) 정확한 프로세스에게 애플리케이션 데이터를 넘기게 해준다.

체크섬(checksum)

세그먼트에 오류가 발생했는지 검사하기 위해 수신 호스트가 사용한다.

길이 필드

헤더를 포함하는 UDP 세그먼트의 길이를 바이트 단위로 나타낸다.

3.3.2 UDP 체크섬

UDP 체크섬은 세그먼트가 출발지로부터 목적지로 이동했을 때,
UDP 세그먼트 안의 비트에 대한 변경사항이 있는지 검사하여 오류 검출을 하기 위한 것이다.

송신자 측에서 세그먼트 안에 있는 모든 16비트 워드의 합산에 대해 다시 1의 보수를 수행하며,
합산 과정에 발생하는 오버플로는 윤회식 자리올림(wrap around)을 한다.
이 결과값이 UDP 세그먼트의 체크섬 필드에 삽입된다.
수신자에서는 체크섬을 포함한 모든 16비트 워드들이 더해진다.
만약 패킷에 어떤 오류도 없다면 수신자에서의 합은 1111111111111111이 되며,
비트 중에 0이 하나라도 있다면 패킷에 오류가 발생했다는 것이다.

UDP는 왜 체크섬을 제공하는가?

출발지와 목적지 사이의 모든 링크가 오류 검사를 제공한다는 보장이 없기 때문이다.

따라서 세그먼트들이 정확하게 링크를 통해 전송되었을지라도, 세그먼트가 라우터의 메모리에 저장될 때 비트 오류가 발생할 수가 있다.

UDP는 오류 검사를 제공하지만, 오류를 회복하기 위한 어떤 일도 하지 않는다.

손상된 세그먼트를 그냥 버리기도 하고, 경고와 함께 손상된 세그먼트를 애플리케이션에게 넘겨주기도 한다.
(처리 방식은 구현에 따라서 다름)

주어진 링크 간의 신뢰성과 메모리의 오류 검사가 보장되지도 않고, 종단 간의 데이터 전송 서비스가 오류 검사를 제공해야 한다면
UDP는 종단 기반으로 트랜스포트 계층에서 오류 검사를 제공해야만 한다.

→ 이것은 종단과 종단의 원칙(end-end principle)의 한 예시이다.

종단과 종단의 원칙(end-end principle)

하위 레벨에 있는 기능들은 상위 레벨에서 이들을 제공하는 비용과 비교했을 때 중복되거나 거의 가치가 없을 수 있다.

Chapter 2 - 5. P2P 파일 분배, 6. 비디오 스트리밍과 콘텐츠 분배 네트워크, 7. 소켓 프로그래밍: 네트워크 어플리케이션 생성

ssun_bear — Tue, 9 Jul 2024 20:11:59 +0900

P2P 구조는 항상 켜져있는 인프라스트럭처 서버에 최소한으로 의존하고, 간헐적으로 연결되는 호스트 쌍들(피어, peer)이 서로 직접 통신한다.

클라이언트-서버 파일 분배에서 서버는 파일 복사본을 각 클라이언트에게 보내려면 서버에게 커다란 부하를 주고, 많은 양의 서버 대역폭을 소비한다.
P2P 파일 분배에서 각 피어는 수신한 파일의 임의의 부분을 다른 피어들에게 재분배할 수 있어서 서버의 분배 프로세스를 도울 수 있다.

2020년에 가장 인기 있는 P2P 파일 분배 프로토콜은 비트 토렌트(BitTorrent)다.

P2P 구조의 확장성

서버와 피어들은 접속 링크로 인터넷에 연결되어 있다.

서버의 접속 링크 업로드 속도를 u(s)로, i번째 피어의 접속 링크 업로드 속도는 u(i)로,
그리고 i번째 피어의 접속 링크 다운로드 속도는 d(i)로 나타낸다.
또한, 분배되는 파일의 크기는 F bit로, 파일을 얻고자 하는 피어들의 수는 N으로 나타낸다.

분배 시간은 모든 N개의 피어들이 파일의 복사본을 얻는데 걸리는 시간이다.

다음 분배 시간에 대한 분석에서 클라이언트-서버와 P2P 구조 모두의 경우, 인터넷 코어가 풍부한 대역폭을 갖고 있다는 간단한 가정을 하며,
이는 모든 병목 현상은 다른 네트워크 애플리케이션에 참여하지 않아서 이들의 모든 업로드와 다운로드 접속 대역폭은 이 파일 분배에 모두 사용된다고 가정한다.

클라이언트-서버 구조 분배 시간

서버는 파일 복사본을 N개의 피어 각각에게 전송해야 한다. 따라서 서버는 NF 비트를 전송해야 한다.
- 즉, 서버가 파일을 분배하는 시간은 적어도 NF/u(s)이다.
d(min)이 가장 낮은 다운로드 속도를 가진 피어의 다운로드 속도를 나타낸다고 하자.
- 가장 낮은 속도를 가진 피어는 F/d(min)초보다 적은 시간에 파일의 모든 F 비트를 얻을 수 없다.
- 즉 최소 분배 시간은 F/d(min)이다.

즉, 분배 시간을 D(cs)라고 하면 다음과 같은 수식을 얻을 수 있다.

D(cs) ≧ max{ NF/u(s) , F/d(min)}

위 식에서 충분히 큰 N에 대해 클라이언트-서버 분배 시간은 NF/u(s)로 주어진다는 사실을 알 수 있다. 즉, N에 따라 선형 증가한다.

P2P 구조 분배 시간

여기서는 각 피어들이 서버가 파일을 분배하는 데 도움을 줄 수 있다.

특히 한 피어가 파일 데이터 일부를 수신할 때, 피어는 그 데이터를 다른 피어들에게 재분배하는 데 자신의 업로드 용량을 이용할 수 있다.

분배가 시작되면 서버만이 파일을 갖고 있다.
- 이 파일이 피어 커뮤니티에 도달할 수 있도록 하기 위해, 서버는 적어도 한 번 접속 링크로 파일의 각 비트를 보내야 한다.
- 따라서 최소 분배 시간은 적어도 F/u(s)다.
  (서버가 한 번 보낸 비트는 서버가 다시 보낼 필요가 없는데, 이는 피어들이 그들 사이에서 재분배할 수 있기 때문이다.)
클라이언트-서버 구조와 마찬가지로 다운로드 속도가 가장 낮은 피어는 F/d(min)초보다 적은 시간 안에 파일의 모든 F 비트를 얻을 수 없다.
- 따라서 최소 분배시간은 적어도 F/d(min)이다.
마지막으로, 시스템의 전체 업로드 용량은 전체적으로 서버의 업로드 속도와 각 피어들의 속도를 더한 것이다. 이를 u(total)이라 하자.
- 시스템은 각 피어들 각각에게 F 비트를 전달해야 한다. 이는 u(total)보다 빠르게 할 수 없다.
- 따라서 최소 분배 시간은 NF/u(total)이다.

즉, 분배시간을 D(p2p)라고 하면 다음과 같은 수식을 얻을 수 있다.

D(p2p) ≧ max {F/u(s) , F/d(min), NF/u(total)}

위 수식들에서 하한값은 서버-클라이언트 구조에서 서버가 전송을 스케줄링 하거나,
P2P 구조에서는 각 피어가 비트를 수신하자마자 그 비트를 재분배할 수 있다고 가정하면(실제로는 chunk가 재분배된다.),
식의 하한값을 최소 분배시간으로 채택할 수 있다.

위 그래프를 통해 임의의 피어 수 N에 대해 클라이언트-서버 구조보다 P2P 구조가 더 시간이 적다는 것을 볼 수 있다.

따라서 P2P 구조를 가진 애플리케이션은 자가 확장성을 갖는다.

비트토렌트(BitTorrent)

비트토렌트(BitTorrent)는 파일 분배를 위한 인기 있는 P2P 프로토콜이다.

토렌트(torrent)

비트토렌트 용어로 특정 파일의 분배에 참여하는 모든 피어의 모임을 토렌트(torrent)라고 부른다.

토렌트에 참여하는 피어들은 서로에게서 같은 크기의 청크(chunk)를 다운로드한다. (일반적으로 256KB)

처음으로 가입하면 그 피어에는 청크가 없지만, 시간이 지나면 점점 많은 청크를 쌓을 수 있다.
(accumulate chunks over time from other peers)
피어가 청크를 다운로드할 때 또한 청크를 다른 피어들에게 업로드한다.
일단 한 피어가 전체 파일을 얻으면 토렌트를 떠나거나, 토렌트에 남아서 다른 피어들로 청크를 계속해서 업로드할 수 있다.

트래커(tracker)

각 토렌트는 트래커(traker)라고 부르는 인프라스트럭처 노드를 갖고있다.

한 피어가 토렌트에 가입할 때 트래커에 자신을 등록하고 주기적으로 자신이 아직 토렌트에 있음을 알려, 트래커는 토렌트에 있는 피어들을 추적할 수 있다.

위의 그림을 예시로 보자.

새로운 피어 앨리스가 토렌트에 가입하면
트래커는 참여하고 있는 피어 집합에서 임의로 피어들의 부분집합(정확히는 50)을 선택하여 이 50개 피어들의 IP 주소를 앨리스에게 보낸다.

이 피어들의 목록을 얻고 나서, 앨리스는 이 목록에 있는 모든 피어와 동시에 TCP 연결을 맺고,
성공적으로 맺은 피어를 이웃 피어(neighbors)라고 부른다.

The peers fluctuate over time

churn : peers may come and go

시간이 지남에 따라 피어들 중 일부는 떠나고, 다른 피어들이 앨리스와 TCP 연결을 시도하고, 피어의 이웃 피어들은 시간에 따라 변동한다.

가장 드문 것 먼저

requesting chunks: rarest first

어느 임의의 시간 안에 앨리스는 청크의 일부를 가질 것이고, 이웃들이 어느 청크를 가지고 있는지를 알게 될 것이다.

앨리스는 이러한 정보를 바탕으로 다음 2가지 결정을 한다.

이웃으로부터 어느 청크를 먼저 요구할 것인가?
이웃들 중 어느 피어에게 청크를 요청할 것인가?

이때 rarest first(가장 드문 것 먼저) 기술을 사용한다.

갖고 있지 않은 청크 중에서, 이웃 가운데 가장 드문 청크를 결정하고 이를 먼저 요구하는 것이다.

이 방법을 통해 가장 드문 청크들은 더 빨리 재분배될 수 있어서 각 청크의 복사본 수가 대략적으로 동일해질 수 있다.

현명한 교역

sending chunks: tit-for-tat

어느 요청에 응답할지 결정할 때 앨리스가 가장 빠른 속도로 그녀에게 데이터를 제공하는 이웃에게 우선순위를 주는 것이다.

특히, 계속해서 비트를 수신하는 속도를 측정하고 가장 빠르게 전송하는 4개의 피어를 결정하고, 이 4개의 피어에게 청크를 보냄으로써 보답한다.
이는 10초마다 계산하여 집합을 수정한다.

비트 토렌트 용어로 4개의 피어는 활성화되었다(unchoked)고 한다.

40초마다 위 피어를 제외하고 임의의 피어에게 청크를 보낸다.

비트 토렌트 용어로 이 피어는 낙관적으로 활성화되었다(optimistically unchoked)고 한다.

즉, 이제 앨리스는 임의의 피어에게 활성화될 수 있고, 활성화가 된다면 임의의 피어도 앨리스에게 활성화될 수 있다.
임의의 선택을 통해 고정된 피어들과만 청크를 교역하는 것이 아니라 여러 피어와 교역할 수 있게 된다.

이러한 5개의 피어 외의 모든 이웃 피어는 비활성화되어 어떤 청크도 교역하지 않는다. (choked by Alice = do not receive chunks from her)

비트 토렌트는 여기서 논의하지 않은 여러 기법들도 갖고 있다.

2.6 비디오 스트리밍과 콘텐츠 분배 네트워크

2.6.1 인터넷 비디오

비디오는 이미지의 연속으로서 일반적으로 초당 24개에서 30개의 이미지로 일정한 속도로 표시된다.

압축되지 않은 디지털 인코딩된 이미지는 픽셀 단위로 구성되며, 각 픽셀은 휘도와 색상을 나타내는 여러 비트들로 인코딩된다.

비디오의 중요한 특징은 압축될 수 있다는 것인데, 비디오 품질과 비트 전송률은 서로 반비례한다.

오늘날의 상용 압축 알고리즘은 근본적으로 원하는 모든 비트 전송률로 비디오를 압축할 수 있다. (비트 전송률이 높을수록 이미지 품질이 좋다.)

네트워킹 측면에서 비디오의 가장 두드러진 특성은 높은 비트 전송률이다.

인터넷 비디오는 일반적으로 고화질 동영상을 스트리밍 하기 위해 100 kbps에서 4 Mbps 이상으로 구성된다.

4K 스트리밍은 10 Mbps 이상의 비트 전송률로 예상된다. 이는 하이엔드 동영상의 경우 트래픽과 스토리지 용량이 엄청나게 필요함을 의미한다.

연속 재생을 제공하기 위해, 네트워크는 압축된 비디오의 전송률 이상의 스트리밍 애플리케이션에 대한 평균 처리량을 제공해야 한다.

→ 압축을 사용하여 동일한 비디오를 여러 버전의 품질로 만들 수 있다.

2.6.2 HTTP 스트리밍 및 DASH

HTTP 스트리밍에서 비디오는 HTTP 서버 내의 특정 URL을 갖는 일반적인 파일로 저장된다.

클라이언트는 서버에게 TCP 연결을 설립하고 해당 URL에 대한 HTTP GET 요청을 발생시킨다.
서버는 기본 네트워크 프로토콜 및 트래픽이 허용되는 대로 HTTP 응답 메시지 내에서 비디오 파일을 전송한다.
애플리케이션 버퍼에 전송된 바이트가 저장된다.
버퍼의 바이트 수가 미리 정해진 임계값을 초과하면 재생을 시작한다.

특히, 버퍼에서 주기적으로 비디오 프레임을 가져와 프레임을 압축 해제한 다음 사용자의 화면에 표시한다.

문제점

가용 대역폭이 달라도 똑같이 인코딩된 비디오를 전송 받는다는 문제가 있다.

이 문제로 인한 HTTP 기반 스트리밍인 DASH(Dynamic Adaptive Streaming over HTTP)가 개발되었다.

Dash

비디오는 여러가지 버전으로 인코딩 되며, 각 버전은 비트율과 품질 수준이 서로 다르다.

클라이언트는 동적으로 서로 다른 버전의 비디오를 몇 초 분량의 길이를 갖는 비디오 조각 단위로 요청한다.

가용 대역폭이 충분할 때는 높은 비트율의 비디오 버전을 요청하며, 가용 대역폭이 적을 때는 낮은 비트율의 비디오 버전을 요청한다.

즉, 클라이언트는 자신의 상황에 알맞은 비디오 버전을 요청한다.

각 비디오 버전은 HTTP 서버에 서로 다른 URL을 가지고 저장된다.

HTTP 서버는 비트율에 따른 각 버전의 URL을 제공하는 매니페스트(manifest) 파일을 갖고 있다.

클라이언트는 이 매니페스트 파일을 제공받고,
이에 따라 매번 원하는 버전의 비디오 조각 단위를 선택하여 HTTP GET 요청 메시지에 URL과 byte-range를 지정하여 요청한다.

궁극적으로 DASH는 클라이언트가 서로 다른 품질 수준을 자유롭게 변화시킬 수 있도록 허용한다.

2.6.3 콘텐츠 분배 네트워크 (CDN)

인터넷 스트리밍 서비스를 제공하는 가장 단순한 방법

단일 거대 데이터 센터를 구축하고 모든 비디오 자료를 데이터 센터에 저장한 뒤, 전 세계의 사용자에게 비디오 스트림을 데이터 센터로부터 직접 전송한다.

문제점

클라이언트가 데이터 센터로부터 먼 지점에 있는 경우 다양한 통신 링크와 ISP를 거치게 되고,
이 링크들 중 하나라도 비디오 소비율 보다 낮은 전송 용량을 갖는 경우 병목현상이 발생한다.
인기 있는 비디오는 같은 통신 링크를 통해 여러 번 반복적으로 전송될 것이다. 동일한 바이트를 전송하는 데에 반복 비용을 지불하게 된다.
한 번의 장애로 전체 서비스가 중단될 수 있다.

이러한 문제를 해결하기 위해 대부분의 비디오 스트리밍 회사들은 콘텐츠 분배 네트워크(CDN)를 이용한다.

CDN

CDN은 다수의 지점에 분산된 서버들을 운영하며, 비디오 및 다른 형태의 웹 콘텐츠 데이터의 복사본을 이러한 분산 서버에 저장한다.

사용자는 최적의 사용자 경험을 제공받을 수 있는 지점의 CDN 서버로 연결된다.

CDN은 구글처럼 사설 CDN일 수도 있으며, 제 3자가 운영하는 CDN을 통해 서비스될 수도 있다.

CDN 서버 위치의 철학 두 가지

두 개의 철학 중 하나를 채용한다.

Enter Deep
Bring Home

Enter Deep

push CDN servers deep into many access networks

Akamai에 의해 주창된 것으로서 서버 클러스터를 세계 곳곳의 접속 네트워크에 구축함으로써 ISP의 접속 네트워크로 깊숙이 들어가는 것이다.

즉, 최대한 서버를 사용자 근처에 위치시켜 링크 및 라우터를 거치는 횟수를 줄여 지연시간 및 처리율을 개선하는 것이다.

Bring Home

smaller number (10’s) of larger clusters in POPs near (but not within) access networks

Limelight와 다른 회사들에 의해 적용된 것으로, 좀 더 적은 수의 핵심 지점에 큰 규모의 서버 클러스터를 구축하여 ISP를 Home으로 가져오는 개념이다.

접속 ISP에 연결하는 대신, 일반적으로 CDN들은 그들의 클러스터를 인터넷 교환 지점(IXP)에 배치한다.

이에 따라 Enter Deep보다 처리율(throughput)은 더 낮고 delay가 더 걸릴 수 있지만, 회사의 입장에서는 유지 보수하기에 편하며, 비용이 적게 든다.

CDN은 콘텐츠의 복사본을 이들 클러스터에 저장하는데 모든 복사본을 유지하지는 않는다.

어떤 비디오는 인기가 거의 없거나 특정 국가에서만 인기가 있을 수 있기 때문이다.

실제로 CDN은 클러스터에 대해 사용자의 요청이 오면 중앙 서버나 다른 클러스터로부터 전송받아 사용자에게 서비스하는 동시에 복사본을 만들어 저장하는 pull 방식을 이용한다.

저장 공간이 가득 차게 되면 자주 사용되지 않는 비디오 데이터는 삭제된다.

CDN 동작

사용자가 URL을 지정하여 비디오를 요청한다.
CDN은 그 요청을 가로채 클라이언트에게 가장 적당한 CDN 클러스터를 선택한다.
클라이언트의 요청을 해당 클러스터의 서버로 연결한다.

요청을 가로챌 때 CDN은 DNS를 활용한다. 이를 DNS redirection이라고 한다.

사용자가 URL을 입력한다.
사용자의 호스트는 URL의 host name에 대한 질의를 로컬 DNS로 보낸다.
로컬 DNS는 host name의 책임 DNS 서버로 질의를 전달한다.
책임 DNS 서버는 해당 질의를 CDN 서버로 연결하기 위해 CDN 서버의 책임 DNS 서버의 IP를 전달한다.
로컬 DNS는 CDN 서버의 책임 DNS로 질의를 보내고, CDN 콘텐츠 서버의 IP 주소를 로컬 DNS 서버로 응답한다.
이때 클라이언트가 콘텐츠를 전송받게 될 서버가 결정된다.
로컬 DNS 서버는 사용자 호스트에게 CDN 서버의 IP 주소를 알려준다.
클라이언트는 호스트가 알게된 IP 주소로 HTTP 혹은 DASH 프로토콜을 통해 비디오를 받아온다.

클러스터 선택 정책

위 CDN이 DNS를 통해 가로채는 과정에서 CDN은 클라이언트의 로컬 DNS 서버의 IP 주소를 알게된다. 이 IP 주소에 기초해 최선의 클러스터를 선택한다.

Geographically Closest

지리적으로 가장 가까운 클러스터를 할당한다.

사용자 지리정보 데이터베이스를 이용하면 얻은 IP 주소를 지리적으로 매핑할 수 있고, 가장 가까운 클러스터를 선택하는 것이다.

대부분 잘 동작하나, 지리적으로 가까운 클러스터가 네트워크 경로의 길이 홉의 수에 따라 가장 가까운 클러스터가 아닐 수 있고,
가까운 로컬 DNS 서버를 이용하고 있지 않을 수 있기 때문에 잘 동작하지 않을 수 있다.

Real-time Measurements

실시간 측정

클러스터와 클라이언트 간의 지연 및 손실 성능에 대한 주기적인 실시간 측정을 통해 현재 네트워크 상황을 반영하여 최선의 클러스터를 선택하는 것이다.

문제는 많은 로컬 DNS 서버가 이러한 측정에 응답을 하지 않도록 설정되어 있다.

2.6.4 사례 연구: 넷플릭스, 유튜브

넷플릭스

넷플릭스의 아마존 클라우드의 기능

콘텐츠 수집 : 영화를 수집하고 처리한다. 영화의 스튜디오 마스터 버전을 받아서 아마존 클라우드 시스템의 호스트에 업로드한다.
콘텐츠 처리 : 아마존 클라우드 시스템의 기기에서는 데스크톱 컴퓨터, 스마트폰, TV에 견결된 게임 콘솔 등 고객들의 다양한 플레이어 기기 사양에 적합하도록 각 영화의 여러가지 형식의 비디오를 생성한다. DASH를 이용하여 각 형식별로 다양한 비트율의 여러가지 버전을 생성한다.
CDN으로 버전 업로드 : 영화의 다양한 버전이 생성되면 아마존 클라우드 시스템의 호스트는 이러한 버전을 CDN으로 업로드할 수 있다.

자체 CDN을 구축하기 위해 넷플릭스는 IXP 및 거주용 ISP 자체에서 서버 랙(rack)을 설치했다.

현재 IXP 위치에 200대 이상의 서버 렉과 서버 랙을 수용하는 수백 개의 ISP 장소도 보유하고 있다.

각각의 랙 서버에는 10 Gbps 이더넷 포트와 100 테라바이트 이상의 스토리지가 있다.

넷플릭스는 푸시 캐싱(push caching)을 사용하여 IXP 및 ISP CDN 서버를 채운다.

전체 라이브러리를 보유할 수 없는 위치의 경우, 매일매일 가장 많이 결정되는 비디오만 푸시한다.

사용자가 재생할 영화를 선택한다.
아마존 클라우드에서 실행 중인 넷플릭스 소프트웨어가 영화 사본을 갖고 있는 CDN 서버를 결정한다.
영화가 있는 서버 중에서 클라이언트 요청에 대한 최적의 서버를 결정한다.
일반적으로 로컬 ISP가 CDN 서버 랙(rack)이 있다면 해당 CDN을 사용하거나, 근처 CDN 서버가 있는 IXP를 사용한다.
클라이언트는 요청된 영화의 다른 버전에 대한 URL을 가진 메니페스트 파일과 특정 서버의 IP 주소를 보낸다.
클라이언트와 해당 CDN 서버는 독점 버전의 DASH를 이용하여 직접 상호작용한다.

넷플릭스는 자체 CDN을 사용하고 있기 때문에 DNS redirection을 사용할 필요가 없다.

대신 아마존 클라우드에서 실행되는 것처럼 넷플릭스 소프트웨어는 클라이언트에게 특정 CDN 서버를 사용하도록 알려준다.

또한 넷플릭스 CDN은 풀 캐싱보다 푸시 캐싱을 사용한다.

콘텐츠는 캐시 미스 중에 동적으로 사용되는 것이 아니라 사용량이 적은 시간 중 예약된 시간에 서버에 푸시한다.

유튜브

넷플릭스와 마찬가지로 자체 CDN을 사용한다.

구글 역시 사용자를 특정 서버 클러스터와 연결하는 데 DNS를 사용한다.

대부분의 경우 클러스터 선택 정책은 클라이언트와 클러스터간의 RTT가 가장 적은 곳을 선택하는 것이다.

때로는 작업 부하를 위해 더 멀리 있는 CDN을 선택하기도 한다.

유튜브는 HTTP 스트리밍을 채용하여 사용자가 직접 버전을 선택하게 했다.

재생 위치 조정과 조기 종료로 인한 대역폭과 서버 자원의 낭비를 줄이기 위해,
유튜브는 HTTP byte-range 헤더를 이용해 목표한 분량의 선인출 데이터 이후에 추가로 전송되는 데이터 흐름을 제한한다.

2.7 소켓 프로그래밍: 네트워크 애플리케이션 생성

네트워크 애플리케이션을 생성할 때는 두 프로그램, 클라이언트와 서버 프로그램을 작성해야 한다.

두 프로그램을 실행하면 프로세스가 생성되고, 두 프로세스가 소켓으로부터 읽고 쓰기를 통해 서로 통신한다.

클라이언트 - 서버 애플리케이션에는 두 가지 형태가 있다.

1️⃣ HTTP 등의 RFC에 정의된 표준 프로토콜을 구현하는 클라이언트-서버 애플리케이션

이 애플리케이션을 구현할 때 그 프로토콜과 연관된 port를 사용하여야 한다.

2️⃣ 개인의 독점적인 네트워크 애플리케이션으로 RFC 또는 다른 곳에 공식적으로 출판되지 않은 애플리케이션 계층 프로토콜을 채택하여 구현하는 애플리케이션

다른 독립 개발자는 이 애플리케이션과 상호작용하는 코드를 개발할 수 없다. 이 애플리케이션을 구현할 때는 잘 알려진 포트번호를 사용하지 않도록 유의해야 한다.

개발자는 TCP, UDP 프로토콜 중 어떤 프로토콜을 사용해야 하는지 각 프로토콜의 특징을 고려하여 선택해야 한다.

2.7.1 UDP 소켓 프로그래밍

UDP를 사용할 때에는 송신 프로세스가 데이터의 패킷을 소켓 문 밖으로 밀어내기 전에, 먼저 패킷에 목적지 주소를 붙여넣어야 한다.

이 패킷이 송신자의 소켓을 통과한 후 인터넷은 이 목적지 주소를 이용하여 그 패킷을 인터넷을 통해 수신 프로세스에 있는 소켓으로 라우트(route)할 것이다.

패킷이 수신 소켓에 도착하면 수신 프로세스는 소켓을 통해 그 패킷을 추출하고, 다음에 패킷의 콘텐츠를 조사하여 적절한 동작을 취한다.

목적지 주소

패킷에 목적지 주소를 포함함으로써 인터넷의 라우터는 목적지 호스트로 인터넷을 통해 패킷을 라우트할 수 있다.

호스트는 각자 IP 주소를 식별자로 갖는다.

그러나 호스트는 하나 혹은 그 이상의 소켓을 갖는 많은 네트워크 애플리케이션 프로세스를 수행하고 있을 수 있기 때문에,
목적지 호스트 내의 특정한 소켓을 식별할 필요가 있다.

소켓이 생성될 때 포트 번호라고 하는 프로세스 식별자가 소켓에 할당된다.

즉, 패킷에는 IP 주소와 포트번호로 구성된 목적지 주소가 붙게 되며, 송신자의 출발지 주소(IP와 port)도 붙게 된다.

일반적으로 이렇게 주소를 붙이는 것은 하부 운영체제가 자동으로 실행한다.

소켓 프로그래밍

위 그림은 UDP 서비스 상에서 통신하는 클라이언트와 서버의 주요 소켓 관련 활동을 나타낸다.

클라이언트는 키보드로부터 한 줄의 문자를 읽고 그 데이터를 서버로 보낸다.
서버는 그 데이터를 수신하고 문자를 대문자로 변환한다.
서버는 수정된 데이터를 클라이언트에게 보낸다.
클라이언트는 수정된 데이터를 수신하고 그 줄을 화면에 나타낸다.

위 순서로 작동하는 간단한 클라이언트-서버 애플리케이션을 만들 예정이다.

UDPClient.py

소켓을 생성할 때는 따로 소켓의 포트 번호를 명시하지 않아도 되며, 운영체제가 이 작업을 대신 수행한다.

# socket module이다. 이 module을 통해 소켓을 생성할 수 있다.
from socket import *

#서버의 IP 혹은 서버의 호스트 이름을 할당한다.
serverName = ’hostname’

# 목적지 port 번호를 나타낸다.
serverPort = 12000

# 클라이언트 소켓을 생성한다. AF_INET은 IPv4를 사용하고 있음을 나타내고, SOCK_DGRAM은 UDP 소켓임을 의미한다.
clientSocket = socket(AF_INET, SOCK_DGRAM)

# 보낼 메시지를 입력 받는다.
message = Input(’Input lowercase sentence:’)

# 소켓으로 바이트 형태를 보내기 위해 먼저 encode()를 통해 바이트 타입으로 변환한다.
# sendTo() 메서드는 목적지 주소를 메시지에 붙이고 그 패킷을 프로세스 소켓인 clientSocket으로 보낸다.
# 클라이언트 주소도 같이 보내지는데 이는 자동으로 수행된다.
clientSocket.sendto(message.encode(),(serverName, serverPort))

# 패킷 데이터는 modifiedMessage에 저장되고, 패킷의 출발지 주소(IP, port)는 serverAddress에 할당된다.
# recvfrom() 메서드는 2048의 버퍼 크기로 받아들인다. 
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)

# 출력
print(modifiedMessage.decode())

# 소켓 닫기
clientSocket.close()

UDPServer.py

while 문을 통하여 한 번의 통신 이후에도, 계속 다음 UDP 패킷이 도착하기를 기다린다.

from socket import *

# 포트 번호
serverPort = 12000

# UDP 소켓 생성
serverSocket = socket(AF_INET, SOCK_DGRAM)

# 12000 포트 번호를 소켓에 할당한다. 이를 통해 서버 IP 주소의 12000 포트로 패킷을 보내면 해당 소켓으로 패킷이 전달된다.
serverSocket.bind((’’, serverPort))

print(”The server is ready to receive”)

while True:
    # 패킷이 서버에 도착하면 데이터는 메세지에 할당되고 패킷의 출발지 주소는 clientAddress에 저장된다.
    # 해당 주소로 서버는 응답을 어디에 보내야할지 알 수 있다.
    message, clientAddress = serverSocket.recvfrom(2048)
    
    # 바이트 데이터를 decode()하고 대문자로 변환한다.
    modifiedMessage = message.decode().upper()
    
    # 클라이언트 주소를 대문자로 변환된 메시지에 붙이고, 그 결과로 만들어진 패킷을 서버에 보낸다.
    # 서버의 주소도 같이 보내지는데 이는 자동으로 수행된다.
    serverSocket.sendto(modifiedMessage.encode(), clientAddress)

2.7.2 TCP 소켓 프로그래밍

TCP는 연결 지향 프로토콜로, 서로 데이터를 보내기 전에 먼저 TCP 연결을 설정할 필요가 있다.

TCP 연결을 생성할 때 클라이언트 소켓 주소와 서버 소켓 주소를 연결과 연관시킨다.

연결이 설정된 후 소켓을 통해 데이터를 TCP 연결로 보내면 된다.

환영 소켓과 연결 소켓

서버 프로세스가 실행되면 클라이언트 프로세스는 서버로의 TCP 연결을 시도하는데, 이는 클라이언트 프로그램에서 TCP 소켓을 생성함으로써 가능하다.

TCP 소켓을 생성할 때, 서버에 있는 환영(welcome) 소켓의 주소(IP, port #)를 명시한다.

소켓을 생성한 후 클라이언트는 3-way handshake를 하고 서버와 TCP 연결을 설정한다. (핸드셰이킹은 프로그램에서 전혀 인지 못한다.)

핸드셰이킹 동안 서버는 해당 클라이언트에게 지정되는 새로운 소켓을 생성한다. 이를 연결 소켓이라고 한다.

애플리케이션 관점에서 볼 때 클라이언트의 소켓과 서버의 연결 소켓은 파이프에 의해 직접 연결된다.

파이프를 통해 클라이언트는 자신의 소켓으로 임의의 바이트를 보낼 수 있으며, 서버 프로세스가 그것을 수신하는 것을 TCP가 보장한다. 이는 서버 입장에서도 마찬가지이다.

소켓 프로그래밍

위 그림은 전형적인 클라이언트-서버 TCP 연결 구조이다.

UDP 프로그램과 똑같은 기능을 하는 프로그램을 작성해보자.

TCPClient.py

주석은 UDP와 다른 부분을 위주로 작성하였다.

from socket import *

serverName = ’servername’
serverPort = 12000

# 클라이언트 소켓을 의미한다. SOCK_STREAM으로 TCP 소켓임을 명시했다.
# UDP 때와 마찬가지로 따로 출발지 주소를 명시하지 않는다. (운영체제가 대신 해준다.) 
clientSocket = socket(AF_INET, SOCK_STREAM)

# 클라이언트가 TCP 소켓을 이용하여 서버로 데이터를 보내기 전에 TCP 연결이 먼저 클라이언트와 서버 사이에 설정되어야 한다.
# 해당 라인으로 TCP 연결을 시작하고, connect() 메서드의 파라미터는 연결의 서버 쪽 주소이다.
# 이 라인이 수행된 후에 3-way handshake가 수행되고 클라이언트와 서버 간에 TCP 연결이 설정된다.
clientSocket.connect((serverName, serverPort))

sentence = raw_input(’Input lowercase sentence:’)

# 클라이언트 소켓을 통해 TCP 연결로 보낸다. UDP 소켓처럼 패킷을 명시적으로 생성하지 않으며 패킷에 목적지 주소를 붙이지 않는다.
# 대신 클라이언트 프로그램은 단순히 문자열에 있는 바이트를 TCP 연결에 제공한다.
clientSocket.send(sentence.encode())

# 서버로부터 바이트를 수신하기를 기다린다.
modifiedSentence = clientSocket.recv(1024)
print(’From Server: ’, modifiedSentence.decode())

# 연결을 닫는다. 이는 클라이언트 TCP가 서버의 TCP에게 TCP 메시지를 보내게 한다.
clientSocket.close()

TCPServer.py

from socket import *

serverPort = 12000

# TCP 소켓 생성
serverSocket = socket(AF_INET, SOCK_STREAM)

# 서버의 포트 번호를 소켓과 연관시킨다.
serverSocket.bind((’’, serverPort))

# 연관시킨 소켓은 대기하며 클라이언트가 문을 두드리기를 기다린다.
# 큐잉되는 연결의 최대 수를 나타낸다.
serverSocket.listen(1)
print(’The server is ready to receive’)

while True:
    # 클라이언트가 TCP 연결 요청을 하면 accept() 메소드를 시작해서 클라이언트를 위한 연결 소켓을 서버에 생성한다.
    # 그 뒤 클라이언트와 서버는 핸드셰이킹을 완료해서 클라이언트의 소켓과 연결 소켓 사이의 TCP 연결을 생성한다.
    connectionSocket, addr = serverSocket.accept()
    sentence = connectionSocket.recv(1024).decode()
    capitalizedSentence = sentence.upper()
    connectionSocket.send(capitalizedSentence.encode())
    
    # 응답을 보내고 연결 소켓을 닫는다. 그러나 환영소켓인 serverSocket이 열려있어 다른 클라이언트가 서버에 연결을 요청할 수 있다. 
    connectionSocket.close()

Chapter 2 - 3. 인터넷 전자메일, 4. DNS: 인터넷의 디렉터리 서비스

ssun_bear — Tue, 9 Jul 2024 20:08:33 +0900

2.3 인터넷 전자메일

이 절에서는 인터넷 전자메일 구조의 중심에 있는 애플리케이션 계층 프로토콜을 알아본다.

아래 그림은 인터넷 메일 시스템의 상위 레벨 개념을 보여준다.

Three major components of Electronic mail:

User agents
Mail servers
SMTP(Simple Mail Transfer Protocol)

사용자 에이전트(User Agent, UA)

a.k.a. "mail reader"
사용자 에이전트는 사용자가 메시지를 읽고, 응답하고, 전달하고, 저장하고, 구성하게 해준다.
대표적으로 마이크로 소프트 아웃룩(Outlook), 애플 메일 등이 있다.

메일 서버(mail server)

전자 메일 인프라스트럭처의 중심이다.
각 수신자는 메일 서버에 메일 박스(mailbox)를 갖고 있다.
- 메일 박스는 수신자의 메시지를 유지하고 관리한다.
- 일반 메시지는 송신자의 사용자 에이전트에서 전달이 시작되고, 송신자의 메일 서버를 거친 후에 수신자의 메일 서버로 전달된다.
  거기서 수신자의 메일 박스에 저장된다.
- 전자메일 박스에 있는 메시지를 보려면 메일 서버는 사용자 계정과 비밀 번호를 이용하여 이용자를 인증하여야 한다.
송신자는 메일 서버의 고장에도 대처해야 한다.
- 만약 메일을 수신자의 메일 서버로 전달할 수 없다면 그 메시지를 메시지 큐(queue)에 보관하고 나중에 그 메시지를 전달하기 위해 다시 시도한다.
- 재시도는 약 30분마다 일어나고, 계속 실패 시에 서버는 그 메시지를 제거하고 송신자에게 통보한다.

SMTP

인터넷 전자메일을 위한 주요 애플리케이션 계층 프로토콜이다.

SMTP는 메일을 송신자의 메일 서버로부터 수신자의 메일 서버로 전송하는 데에 TCP의 신뢰적인 데이터 전송 서비스를 이용한다.
SMTP는 대부분의 애플리케이션 계층 프로토콜처럼, 클라이언트와 서버를 갖고 있다.
SMTP의 클라이언트와 서버 모두가 모든 메일 서버에서 수행되고, 상대 메일로 송신할 때는 클라이언트가 되고 수신할 때는 서버가 된다.

2.3.1 SMTP

uses TCP to reliably transfer email message from client to server, port 25

direct transfer: sending server to receiving server

SMTP에서는 모든 메일 메시지의 몸체는 단순한 7-bit ASCII여야 한다.

이 때문에 전송 용량이 제한되어 커다란 첨부 파일이나 비디오 파일을 보낼 때 문제를 일으킨다.

Three phases of transfer

handshaking (greeting)
transfer of messages (data exchange)
closure

기본 동작 과정

앨리스는 전자 메일 사용자 에이전트를 수행하고, 밥의 전자 메일 주소를 제공하여 메시지를 보내라고 명령한다.
앨리스의 사용자 에이전트는 메시지를 그녀의 메일 서버에게 보내고, 그곳에서 메시지는 메시지 큐에 놓인다.
앨리스의 메일 서버에서 동작하는 SMTP의 클라이언트 측은 메시지 큐에 있는 메시지를 본다.
밥의 메일 서버에서 수행되고 있는 SMTP 서버에게 TCP 연결을 설정한다.
초기 SMTP 핸드셰이킹 이후에 SMTP 클라이언트는 앨리스의 메시지를 TCP 연결로 보낸다.
밥의 메일 서버 호스트에서 SMTP의 서버 측은 메시지를 수신한다. 밥의 메일 서버는 그 메시지를 밥의 메일 박스에 놓는다.
밥은 편한 시간에 그 메시지를 읽기 위해 사용자 에이전트를 시동한다.

SMTP는 두 메일 서버가 먼 거리에 떨어져 있더라도 중간 메일 서버를 이용하지 않는다.

즉, 메시지를 보낼 때 보내는데 실패하더라도 중간 메일 서버에 저장되는 것이 아니라 송신자의 메일 서버에 남아있다.

기본 동작 과정 Detail

클라이언트 SMTP는 서버의 SMTP의 25번 포트로 TCP 연결을 설정한다. 서버가 죽어있다면 나중에 시도한다.
연결이 설정되면, 애플리케이션 계층 핸드셰이킹을 수행한다.
이때 SMTP 클라이언트는 송신자의 전자메일 주소와 수신자의 전자메일 주소를 제공한다.
이후 클라이언트는 메시지를 보낸다. (TCP의 신뢰적인 데이터 전송 서비스에 의존)
보낼 다른 메시지가 있다면 같은 TCP 연결 상에서 반복하며, 그렇지 않으면 TCP를 닫는다. (지속 연결(persistent connection))

SMTP 클라이언트(C)와 SMTP 서버(S) 사이의 메시지 전달 과정 예시

S:  220 hamburger.edu
C:  HELO crepes.fr
S:  250 Hello crepes.fr, pleased to meet you
C:  MAIL FROM: <alice@crepes.fr>
S:  250 alice@crepes.fr ... Sender ok
C:  RCPT TO: <bob@hamburger.edu>
S:  250 bob@hamburger.edu ... Recipient ok
C:  DATA
S:  354 Enter mail, end with ”.” on a line by itself
C:  Do you like ketchup?
C:  How about pickles?
C:  .
S:  250 Message accepted for delivery
C:  QUIT
S:  221 hamburger.edu closing connection

클라이언트는 5개의 HELO, MAIL FROM, RCPT TO, DATA, QUIT 명령을 내린다.
클라이언트는 하나의 점(.)으로 된 라인을 송신하며, 그것은 서버에서 메시지의 끝을 나타낸다.
서버는 각 명령에 응답하며, 각 응답에는 응답 코드와 영문 설명이 있다.

SMTP는 지속 연결(persistent connection)을 사용한다.

즉, 같은 수신 메일 서버로 보내는 여러 메시지를 갖고 있다면, 같은 TCP 연결을 통해 모든 메시지를 전달할 수 있다.

telnet 명령어를 사용하면 원격 메일 서버와 위와 같은 대화를 할 수 있다.

2.3.2 메일 메시지 포맷

전자메일을 보낼 때 주변 정보가 포함된 헤더(header)가 메시지 몸체(body) 앞에 오게 된다.

이 헤더는 RFC 5322에 정의되어 있으며, 헤더와 몸체는 CRLF로 분리된다.
모든 헤더는 From: 헤더라인과 To: 헤더 라인을 반드시 가져야 한다. (나머지 헤더는 선택사항이다.)

일반 메시지 헤더는 다음과 같다.

From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Searching for the meaning of life.

Message

2.3.3 메일 접속 프로토콜(Mail access protocols)

SMTP : delivery / storage to receiver's server
Mail access protocol : retrieval from server

메일 서버가 메일 박스를 관리하고, SMTP의 클라이언트와 서버 측 모두를 수행한다.

메일 서버가 로컬 호스트에 있다면, 호스트는 언제든 도착할 수 있는 전자 메일을 수신하기 위해 항상 켜져 있어야 하고 인터넷에 연결되어 있어야 한다.

이는 대부분의 인터넷 사용자에게는 비현실적이다.

대신에 일반 사용자는 로컬 호스트에서 사용자 에이전트를 수행하고 늘 켜져 있는 공유 메일 서버에 저장된 메일박스에 접근한다.

메일 서버는 보통 사용자들과 공유한다.

송신자 사용자 에이전트에서 수신자 메일 서버까지

클라이언트의 사용자 에이전트는 수신자의 메일 서버로 직접 대화하지 않는다.

대신에 그림처럼 (1) 클라이언트의 사용자 에이전트는 클라이언트의 메일 서버로 전자메일 메시지를 SMTP 또는 HTTP를 이용하여 보낸다.

(2) 그리고 수신자의 메일 서버는 SMTP를 이용하여 수신자의 메일 서버로 전자메일 메시지를 중계한다.

두 단계 절차를 거치는 주요 이유는 수신자의 메일 서버를 통해 중계하지 않으면 수신자의 에이전트는 목적지 메일 서버에 도달할 수 없기 때문이다.

송신자는 전자메일을 자신의 메일 서버에 먼저 저장하고, 수신자의 메일 서버는 그 메시지를 수신자의 메일 서버로 받을 때까지 30분 마다 반복해서 보내려고 한다.

수신자 메일 서버에서 수신자 사용자 에이전트까지

수신자는 자신의 ISP 내부의 메일 서버에 메시지를 어떻게 얻을 수 있는가?

SMTP는 push 프로토콜인 반면 메시지를 얻는 것은 pull 동작이기 때문에 다른 프로토콜을 사용하여야 한다.

두 가지 대표적인 방법

HTTP
- 웹 기반 전자메일이나 스마트폰 앱의 경우에 쓰인다.
- 당연히 메일 서버는 SMTP 인터페이스와 HTTP 인터페이스 둘 다 가지고 있어야 한다.
IMAP : RFC 3501에 정의된 인터넷 메일 접근 프로토콜

2.4 DNS: 인터넷의 디렉터리 서비스

호스트 이름(hostname)

인터넷 호스트의 식별자 중 하나는 www.facebook.com, www.google.com 등의 호스트 이름(hostname)이다.

그러나 호스트의 이름은 인터넷에서의 호스트 위치에 대한 정보를 거의 제공하지 않는다.

또한, 가변 길이의 알파뉴메릭 문자로 구성되므로 라우터가 처리하는 데 어려움이 있다.

이러한 이유로 호스트는 흔히 말하는 IP 주소(IP address)로 식별된다.

IP 주소(IP address)

IP 주소는 4 바이트로 구성되고, 계층구조를 갖는다.

121.7.106.83과 같은 형태로 0 ~ 255의 십진수로 표현하는 각 바이트는 점으로 구분한다.
계층구조여서 왼쪽에서 오른쪽으로 조사함으로써, 그 호스트가 인터넷의 어디에 위치하는지에 대한 자세한 정보를 얻을 수 있다.
(더 자세히는 4장에서 논의한다.)

2.4.1 DNS(Domain Name System)가 제공하는 서비스

사람은 호스트 네임을 선호하지만, 라우터는 고정 길이의 계층구조를 가진 IP 주소를 선호한다.

이 차이를 절충하기 위해 호스트 이름을 IP 주소로 변환해주는 디렉터리(directory) 서비스가 필요하다.

이 서비스가 인터넷 DNS(Domain name system)의 주요 임무다. (hostname translations, address resolutions)

DNS(Domain Name System)

DNS 서버들의 계층구조로 구현된 분산 데이터 베이스이다.
implemented in hierarchy of many name servers
호스트가 분산 데이터 베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜이다.

DNS 서버는 주로 BIND(Berkeley Internet Name Domain) 소프트웨어를 수행하는 유닉스(UNIX) 컴퓨터다.

DNS 프로토콜은 UDP 상에서 수행되고 포트 번호 53을 이용한다.

[참고] DNS가 UDP를 사용하는 이유

1️⃣ 빠른 속도

TCP의 경우 데이터 전송 시작 전에 3-way-handshaking 과정이 있는 반면, UDP는 연결 설정에 드는 비용이 없다.

DNS는 신뢰성보다 속도가 더 중요한 서비스이기 때문에 TCP보다 UDP가 더 적합하다.

또한, UDP는 512 bytes를 넘어가지 않는 패킷만 전송이 가능하고 오버헤드가 없어서 속도가 빠른데,
DNS가 전송하는 데이터 패킷 사이즈가 매우 작으므로 UDP가 유리하다.

이때 단순히 패킷의 사이즈가 작다고 DNS가 UDP를 채택한 것은 아니고,
전달하는 패킷의 크기가 작기 때문에 신뢰성이 보장되지 않아도 되기 때문이다. (못 받으면 다시 전달하면 된다.)

2️⃣ 연결 상태를 유지할 필요가 없다.

TCP는 호스트 간의 연결 상태를 유지한다.

이때 TCP의 패킷 안에는 여러 정보가 담겨 있지만, UDP는 어떤 정보도 기록하지 않고 유지할 필요도 없다.

DNS 서버는 TCP보다 많은 클라이언트를 수용할 수 있으므로 연결 상태를 유지하지 않고 정보 기록을 최소화할 수 있는 UDP를 채택하였다.

사용자의 호스트에서 수행하는 브라우저가 URL을 검색했을 때 발생하는 일

같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트를 수행한다.
브라우저는 URL로부터 호스트 이름을 추출하고 그 호스트 이름을 DNS 애플리케이션의 클라이언트에 보낸다.
DNS 클라이언트는 DNS 서버로 호스트 이름을 포함하는 질의를 보낸다. (client queries to DNS server)
DNS 클라이언트는 결국 호스트 이름에 대한 IP 주소를 받게 된다.
브라우저가 DNS로부터 IP 주소를 받으면,
브라우저는 해당 IP 주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화한다.

DNS는 위 예시에서 알 수 있듯이 추가 지연을 주지만,
가까운 DNS 서버에 캐싱되어 있어서 평균 DNS 지연 뿐만 아니라 DNS 네크워크 트래픽 감소에 도움을 준다.

호스트 이름을 IP 주소로 변환하는 것 이외의 서비스

호스트 에일리어싱(host aliasing)

복잡한 호스트 이름을 가진 호스트는 하나 이상의 별명을 가질 수 있다.

relay1.west-coast.enterprise.com 같은 호스트 이름은 enterprise.com 같은 별칭을 가질 수 있다.

이 경우에 relay1.west-coast.enterprise.com를 정식 호스트 이름(canonical hostname)이라고 한다.

DNS는 호스트의 IP 주소 뿐만 아니라 제시한 별칭 호스트 이름에 대한 정식 호스트 이름을 얻기 위해 이용될 수 있다.

메일 서버 에일리어싱(mail server aliasing)

전자 메일 주소는 간단하지만 그 서버의 호스트 네임은 일반적으로 더 복잡하다.

부하 분산 (load distribution)

load balancing among the servers

인기 있는 사이트는 여러 서버에 중복되어 있어서, 각 서버가 다른 종단 시스템에서 수행되고 다른 IP 주소를 갖는다.

이때 여러 IP 주소가 하나의 정식 호스트 이름과 연관되어 있다. DNS 데이터베이스는 이 IP 주소 집합을 갖고 있다.

클라이언트가 주소 집합으로 매핑하는 호스트 이름에 대한 DNS 질의를 하면, 서버는 IP 주소 집합 전체를 가지고 응답한다.

각 응답에서의 주소는 순환식으로 보낸다.

클라이언트는 대체로 주소 집합 내부의 첫 번째 IP 주소로 HTTP 요청 메시지를 보내므로, DNS의 순환 방식은 트래픽을 분산하는 효과를 낸다.

[참고] What is DNS Load Balancing?

2.4.2 DNS 동작 원리 개요

사용자의 호스트에서 실행되는 어떤 애플리케이션이 호스트 이름을 IP 주소로 변환하려 한다고 가정하자.

과정은 다음과 같다.

애플리케이션이 호스트 이름을 명시하여 DNS 클라이언트 호출한다.
사용자 호스트의 DNS는 네트워크에 질의 메시지를 보낸다.
이때 모든 질의와 응답 메시지는 포트 53의 UDP 데이터그램으로 보내진다.
응답 메시지를 애플리케이션에 전달한다.

DNS는 간단해보이지만 매우 복잡한데, 이는 전 세계에 분산된 많은 DNS 서버 뿐만 아니라
DNS 서버와 질의를 하는 호스트 사이에서 어떻게 통신하는지를 명시하는 애플리케이션 계층 프로토콜로 구성되어 있다.

DNS가 중앙 집중 데이터베이스라면?

why not centralize DNS?

만약 DNS가 간단한 설계로 모든 매핑을 포함하는 하나의 인터넷 네임 서버를 갖고 있다면, 수많은 호스트를 가진 오늘날 다음과 같은 문제를 일으킬 수 있다.

서버의 고장 : 이 네임 서버가 고장 나면, 전체 인터넷이 작동하지 않는다. (single point of failure)
트래픽 양의 과부하 : 단일 DNS 서버가 모든 질의를 해결해야 한다.
먼 거리의 중앙 집중 데이터베이스: 단일 DNS 서버가 모든 질의 클라이언트로부터 '가까울' 수만은 없다. 즉, 멀면 멀수록 모든 질의가 느려진다.
유지 관리
- 단일 네임 서버는 모든 인터넷 호스트에 대한 레코드를 유지해야 한다.
- 모든 새로운 호스트를 반영하기 위해 자주 갱신되어야 하고, 사용자에게 호스트를 등록할 수 있도록 허용하는 것과 관련된 인증 문제가 있다.

요약하면 중앙 집중 데이터베이스는 확장성(scalability)이 전혀 없고, 결과적으로 DNS는 분산되도록 설계되어있다.

분산(distributed) 계층(hierarchical) 데이터 베이스

DNS는 많은 서버를 이용하고 이들을 계층 형태로 구성하며 전세계에 분산시킨다.

계층 DNS 서버의 종류

루트(root) DNS 서버

1000개 이상의 루트 서버 인스턴스가 세계에 흩어져 있다.
루트 네임 서버는 TLD 서버의 IP 주소들을 제공한다.
인터넷 할당 번호 관리기관 ICANN(Internet Corporation for Assigned Names and Numbers)에 의해 조정된다.

TLD(최상위 레벨 도메인) DNS 서버

Top-Level Domain, TLD
com, org, net 같은 상위 레벨 도메인과 kr, uk 같은 모든 국가의 상위 레벨 도메인에 대한 TLD 서버가 있다.
Authoritative(책임) DNS 서버에 대한 IP 주소를 제공한다.

Authoritative(책임) DNS 서버

인터넷에서 접근하기 쉬운 호스트를 가진 모든 기관은 호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 레코드를 제공해야 한다.
- 기관의 책임 DNS 서버는 이 DNS 레코드를 갖고 있다.
기관은 직접 자신의 책임 DNS 서버의 구현을 선택할 수 있고, 일부 서비스 제공자의 책임 DNS 서버에 이 레코드를 저장하도록 비용을 지불한다.

로컬(local) DNS 서버

로컬 DNS 서버는 서버들의 계층 구조에 엄격하게 속하지는 않지만 DNS 구조의 중심에 있다.
ISP는 로컬 DNS 서버를 갖고, 로컬 DNS 서버로부터 IP 주소를 호스트에게 제공한다.
대체로 호스트에 가까이 있기 때문에 지연이 적다.

예시

위 그림에서 cse.nyu.edu가 gaia.cs.umass.edu의 IP 주소를 원한다고 가정해보자.

자신의 로컬 DNS 서버에 질의를 보낸다. 이때 변환하고 싶은 호스트의 이름을 같이 보낸다.
로컬 DNS 서버는 그 질의 메시지를 루트 DNS 서버에게 전달한다.
루트 DNS 서버는 edu를 인식하고, edu에 대한 책임을 가진 TLD 서버의 IP 주소 목록을 로컬 DNS 서버에 보낸다.
로컬 DNS 서버는 TLD 서버에 질의를 보낸다.
TLD 서버는 umass.edu를 인식하고, dns.umass.edu로 이름 지어진 책임 DNS 서버의 IP 주소로 응답한다.
로컬 DNS 서버는 직접 책임 DNS 서버로 질의 메시지를 다시 보낸다.
최종 gaia.cs.umass.edu의 IP 주소를 응답한다.
호스트에 최종 IP 주소를 응답한다.

여기서는 총 8번의 DNS 메시지가 보내졌다.

일반적으로 TLD 서버는 위의 예시와 같이 책임 DNS 서버를 알지 않고, 책임 DNS 서버를 아는 중간 DNS 서버를 알고 있다.

즉, 해당 질의 과정 까지 포함되면 전체 10번의 메시지를 보내게 된다.

위 예는 재귀적 질의와 반복적 질의를 사용한다.

cse.nyu.edu로부터 dns.nyu.edu로 보내는 질의는 자신을 필요한 매핑을 대신하여 얻도록 dns.nyu.edu에 요구하므로 재귀적 질의이고,
나머지는 반복적 질의다.

아래 그림은 모든 질의가 재귀적인 DNS 질의 사슬을 보여준다.

일반 질의는 전형적으로 반복적 질의를 따른다.

재귀적 질의에서는 높은 계층에 있는 DNS server가 책임져야 하는 것들이 많다.
- puts burden of name resolutions on contacted name server
- heavy load at upper levels of hierarchy
중요한 infra를 지키는 것이 훨씬 낫기 때문에, 중요한 root name server 보단 default name server가 일을 더 하는 것이 좋다.

DNS 캐싱

실제로는 DNS 지연 성능 향상과 네트워크의 DNS 메시지 수를 줄이기 위해 캐싱(caching)을 사용한다.

질의 사슬에서 DNS 서버는 DNS 응답을 받았을 때 로컬 메모리에 응답에 대한 정보를 저장할 수 있다.

만약 호스트의 이름과 IP 주소 쌍이 DNS 서버에 저장되고 다른 호스트 이름으로부터 같은 질의가 DNS 서버로 도착한다면,
DNS 서버는 호스트 이름에 대한 책임이 없을 때조차 원하는 주소를 제공할 수 있다.

호스트 DNS와 IP 사이의 매핑과 호스트는 영구적이지 않기 때문에 어떤 기간(TTL, Time to Live) 이후에 저장된 정보를 제거한다.

로컬 DNS 서버는 구체적인 IP 주소 이외에도 TLD 서버의 IP를 저장하여 루트 DNS 서버를 우회할 수 있게 한다.

2.4.3 DNS 레코드와 메시지

각 DNS는 하나 이상의 자원 레코드를 가진 메시지로 응답한다.

DNS 자원 레코드

DNS 서버들은 호스트 이름을 IP 주소로 매핑하기 위한 자원 레코드(Resource Records)를 저장한다.

자원 레코드는 다음과 같은 필드를 포함하는 4개의 Tuple로 되어 있다.

(Name, Value, Type, TTL)

TTL(Time to Live)은 자원 레코드의 생존 기간이다.

Name과 Value는 Type을 따른다. 즉, Type에 따라서 Name과 Value에 대한 semantic(해석법)이 달라진다.

Type = A

Address
Type A 레코드는 표준 호스트 이름의 IP 주소 매핑을 제공한다.

Name : 호스트 이름(hostname)
Value : 호스트 이름에 대한 IP 주소

Type = NS

Name Server

Name : 도메인(domain)
Value : 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는 방법을 아는 책임 DNS 서버의 호스트 이름

Type = CNAME

Canonical NAME

Name : 정식 호스트 이름의 alias name
Value : 별칭 호스트 이름 Name에 대한 정식 호스트 이름

Type = MX

Mail eXchange

Value : 별칭 호스트 이름 Name을 갖는 메일 서버의 정식 이름
MX 레코드는 메일 서버의 호스트 이름이 간단한 별칭을 갖는 것을 허용한다.

메일 서버의 정식 이름을 얻기 위해서는 MX 레코드에 대한 질의를 해야 하고, 다른 서버의 정식 이름을 얻기 위해선 CNAME 레코드에 대한 질의를 한다.

DNS 서버가 특별한 호스트 이름에 대한 책임 서버이면, 그 DNS 서버는 호스트 이름에 대한 Type A 레코드를 포함한다.

서버가 호스트 이름에 대한 책임 서버가 아니라면, 그 서버는 호스트 이름을 포함하는 DNS 서버의 IP 주소를 제공하는 Type A 레코드도 포함할 것이다.

DNS 메시지

DNS의 요청과 응답 메시지는 모두 아래 그림과 같은 포맷을 갖고 있다.

header

처음 12 byte의 헤더 영역 : 여러 필드를 갖고 있다.

첫 필드는 질의를 식별하는 16 bit의 숫자이다.
이 식별자는 질의에 대한 응답 메시지에 복사되어, 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별하게 한다.
플래그(flag) 필드에는 여러 개의 플래그가 있다.
- 1 비트의 질의/응답 플래그는 메시지가 질의인지 응답인지 구분하게 한다.
- 1 비트의 책임 플래그는 DNS 서버가 질의 이름에 대해 책임 서버일 때 응답 메시지에 설정된다.
- 1 비트의 재귀 요구 플래그는 DNS 서버가 레코드를 갖지 않을 때 재귀적 질의를 수행하기를 클라이언트가 원할 때 설정된다.
- 1 비트로 된 재귀 가능 필드는 DNS 서버가 재귀 질의를 지원하면 응답에 설정된다.
나머지 4개의 '개수' 필드는 헤더 다음에 오는 데이터 영역의 네 가지 타입의 발생 횟수를 나타낸다.

payload

질문 영역
- 현재 질의에 대한 정보를 포함한다.
- 질의되는 이름을 포함하는 이름 필드와, 이름에 대해 문의되는 질문 타임을 나타내는 타입 필드를 나타낸다. (A, NS 등)
답변 영역
- 원래 질의된 이름에 대한 자원 레코드를 포함한다. (value, TTL)
- 여러 개의 자원 레코드를 보낼 수 있는데, 하나의 호스트 이름이 여러 개의 IP를 가질 수 있기 때문이다. (중복 웹 서버)
책임 영역
- 다른 책임 서버의 레코드를 포함한다.
추가 영역
- 다른 도움이 되는 레코드를 갖고 있다.
- 예를 들어, MX 질의에 대한 응답에서 응답 필드는 전자메일 서버의 정식 호스트 이름을 제공하는 자원 레코드를 갖고 있고,
  추가 영역은 정식 호스트 이름에 대한 IP 주소를 제공하는 A 레코드를 포함한다.

DNS 데이터베이스에 레코드 삽입

도메인 네임 networkutopia.com을 등록 기관(DNS registrar)에 등록한다고 가정해보자.

등록 기관(DNS registrar)은 도메인 네임의 유일성을 확인하고,
그 도메인 네임을 DNS 데이터베이스에 넣고, 그 서비스에 대한 요금을 받는 상업 기관이다.

이전에는 작은 등록기관이 독점했었지만, 이제는 많은 기관이 경쟁하고 ICANN이 이러한 여러 등록기관을 승인해준다.

도메인 네임을 어떤 등록기관에 등록할 때 등록 기관에 주책임 서버와 부책임 서버의 이름과 IP 주소를 등록기관에 제공해야 한다.

주책임 서버 : dns1.networkutopia.com / 주책임 서버 IP : 212.2.212.1
부책임 서버 : dns2.networkutopia.com / 부책임 서버 IP : 212.2.212.2

위와 같다고 가정하자.

이 두 책임 DNS 서버 각각에 대해 등록 기관은 Type NS와 Type A 레코드가 TLD com 서버에 등록되도록 확인한다.

특히 주책임 서버의 경우 다음 두 개의 자원 레코드를 DNS 서버에 삽입한다.

(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)

또한, Type A 레코드와 메일 서버에 대한 Type MX 자원 레코드가 책임 DNS 서버에 등록되는 것을 확인한다.

이러한 모든 단계가 끝나면 여러 사람들이 웹 사이트를 방문할 수 있고, 전자메일을 보낼 수 있게 된다.

DNS 취약점

DDoS 대역폭 플러딩 공격

공격자는 DNS 루트 서버로 다량의 패킷을 보내려는 시도를 하여 다른 DNS 질의들이 응답을 받지 못하게 하려 한다.

실제로 이 일이 일어났지만, 많은 DNS 루트 서버들은 루트 서버로 향하는 공격자가 사용한 ICMP 핑 메시지를 블록하도록 형상화한 패킷 필터로 보호되었고,
대부분의 로컬 DNS 서버가 최상위 도메인 서버들의 IP 주소들을 캐싱하고 있어서 피해가 거의 없었다.

즉, 더 효과적인 공격은 최상위 도메인 서버를 공격하는 것이고, 실제로 최상위 도메인 서비스 제공자 Dyn에 이러한 일이 발생했다.

이는 유명 애플리케이션들이 무차별 교란되는 결과를 야기했다.

DNS 중독 공격

공격자는 DNS 서버로 가짜 응답을 보내어 그 서버가 자신의 캐시에 가짜 레코드를 받아들이도록 속임수를 쓴다.

이러한 공격은 웹 사용자들을 공격자의 웹사이트로 유도하는 데 이용될 수 있다.

이러한 공격을 막기 위해 DNS 보안 확장 프로토콜이 개발되어 사용되고 있다.

Chapter 2 - 1. 네트워크 어플리케이션의 원리, 2. 웹과 HTTP

ssun_bear — Tue, 9 Jul 2024 20:05:49 +0900

2.1 네트워크 애플리케이션의 원리

네트워크 애플리케이션 개발의 중심은 다른 위치의 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것이다.

예를 들어, 웹 애플리케이션에는 서로 통신하는 서버(웹 서버 프로그램)와 클라이언트(사용자 호스트에서 실행되는 브라우저 프로그램)로 구별되는
두 가지 프로그램이 있다.

중요한 것은 우리가 라우터나 링크 계층 스위치처럼 네트워크 코어 장비에서 실행되는 소프트웨어까지 작성할 필요는 없다는 점이다.
(그렇게 하고 싶더라도 네트워크 코어 장비는 애플리케이션 계층에서 기능하지 않기 때문에 그렇게 할 수 없다.)

2.1.1 네트워크 애플리케이션 구조

애플리케이션 구조는 네트워크 구조와 분명히 다르다.

애플리케이션 개발자 관점에서 네트워크 구조는 고정되어 있고, 해당 애플리케이션의 특정 서비스 집합을 제공한다.

반면, 애플리케이션 구조는 애플리케이션 개발자가 설계하며, 애플리케이션이 여러 종단 시스템에서 어떻게 조직되어야 하는지를 알려준다.

잘 알려진 애플리케이션 구조 2가지

클라이언트-서버(client-server) 구조

항상 동작하고 있는 서버가 존재하고, 클라이언트라는 다른 호스트들로부터 서비스 요청을 받는다.
클라이언트는 서로 직접적으로 통신하지 않는다.
서버는 잘 알려진 고정 IP 주소를 갖는다.
서버가 클라이언트로부터 오는 모든 요청에 더 응답하는 것이 불가능할 때,
많은 수의 호스트를 갖춘 데이터 센터가 강력한 가상의 서버를 생성하는 역할로 사용된다. 보통, 10만개 정도의 서버를 갖추고 있다.

P2P 구조

항상 켜져있는 인프라스트럭처 서버에 최소로 의존한다. (혹은 의존하지 않는다.)
대신에 애플리케이션은 peer라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하게 한다.
peer는 흔히 알려진 클라이언트(개인 데스크톱과 랩톱 등등)이다.
자가 확장성을 가진다. 예를 들어, 파일 공유 애플리케이션에서는 각 피어들이 파일을 요구하여 작업 부하가 생기지만
각 피어들은 파일을 다른 피어들에게 분배하여 시스템에 서비스 능력을 갖춘다.
데이터 센터 등이 필요 없으므로 비용 효율적이다.

2.1.2 프로세스 간 통신

실제 통신하는 것은 프로그램이 아니라, 실행되고 있는 프로그램인 프로세스이다.

2개의 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지 교환으로 서로 통신한다.

송신 프로세스는 메시지를 만들어서 보내고 수신 프로세스는 메시지를 받고 역으로 메시지를 보냄으로써 응답한다.

클라이언트와 서버 프로세스

네트워크 애플리케이션은 네트워크에서 서로 메시지를 보내는 두 프로세스로 구성된다.

클라이언트와 서버 프로세스를 다음과 같이 정의한다.

두 프로세스 간의 통신 세션에서
통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을 초기화)하는 프로세스를 클라이언트(client)라 하고,
세션을 시작하기 위해 접속을 기다리는 프로세스를 서버(server)라고 한다.

간단히 말하면, 요청을 보내는 쪽의 프로세스를 보통 클라이언트라고 하고, 요청을 받는 쪽을 서버라고 한다.

당연히 P2P 구조에서 봤듯이, 클라이언트도 서버 프로세스가 될 수 있고, 서버도 클라이언트 프로세스가 될 수 있다.

프로세스와 컴퓨터 네트워크 사이의 인터페이스

프로세스는 소켓(socket)을 통해 네트워크로 메시지를 보내고 받는다.

네트워크에서 프로세스를 집이라 한다면, 소켓은 마치 문과 같은 존재이다.

위 그림에 보이듯이, 소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층간의 인터페이스다.

네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이의 API라고도 한다.

애플리케이션 개발자는 소켓의 애플리케이션 계층에 대한 모든 통제권을 갖지만, 소켓의 트랜스포트 계층에 대한 통제권은 거의 갖지 못한다.

애플리케이션 개발자의 트랜스포트 계층에 대한 통제

트랜스포트 프로토콜을 선택
최대 버퍼와 최대 세크먼트 크기 같은 약간의 매개변수 설정

프로세스 주소 배정

프로세스가 다른 수행되고 있는 다른 패킷으로 프로세스를 보내기 위해서는 수신 프로세스가 주소를 갖고 있어야 한다.

수신 프로세스를 식별하기 위해서는 두 가지 정보가 필요하다.

호스트의 주소 즉, IP 주소가 필요하다.
호스트 내의 수신 프로세스를 명시하는 식별자 즉, port 번호가 필요하다. 더 자세한 내용은 3장에서 다룬다.

2.1.3 애플리케이션이 이용 가능한 트랜스포트 서비스

송신 측의 애플리케이션은 소켓을 통해 메시지를 보내고,
트랜스포트 프로토콜은 네트워크를 통해 그 메시지를 수신 프로세스의 소켓으로 이동시킬 책임이 있다.

인터넷을 포함한 많은 네트워크는 트랜스포트 프로토콜을 하나 이상 제공한다.

트랜스포트 프로토콜이 그것을 이용하는 애플리케이션에게 제공할 수 있는 4가지 서비스를 알아보자.

신뢰적 데이터 전송(data integrity)
처리율(throughput)
시간(timing)
보안(security)

신뢰적 데이터 전송(data integrity)

1장에서 보았듯이, 패킷들은 컴퓨터 네트워크 내에서 손실될 수 있다.

이러한 데이터 손실은 위험한 결과를 초래할 수 있다.

만약 프로토콜이 보장된 데이터 전송 서비스를 제공한다면 신뢰적 데이터 전송이라고 한다.

트랜스포트 프로토콜이 이 서비스를 제공할 때, 송신 프로세스는 데이터를 소켓으로 보내고 그 데이터가 오류 없이 수신 프로세스에 도착할 것이라는 확신을 갖는다.

트랜스포트 프로토콜이 이 서비스를 제공하지 않을 때 송신 프로세스가 보낸 데이터는 전혀 도착하지 않을 수 있다.

이러한 애플리케이션을 손실 허용 애플리케이션(실시간 비디오/오디오 애플리케이션 등이 대표적)이라고 한다.

처리율(throughput)

다른 세션들이 네트워크 경로를 따라 대역폭을 공유하고, 이 세션들이 생겼다 없어졌다 하기 때문에 가용한 처리율은 시간에 따라 변한다.

트랜스포트 프로토콜은 어느 명시된 속도에서 보장된 가용 처리율을 제공한다.

처리율 요구사항을 갖는 애플리케이션은 대역폭 민감 애플리케이션이라 하고, 현존하는 많은 멀티미디어 애플리케이션은 대역폭에 민감하다.
(너무 처리율이 낮으면 전화같은 서비스가 불가능하다.)

반대로 요구사항이 없는 애플리케이션을 탄력적 애플리케이션(elastic apps)이라고 한다.

시간(timing)

트랜스포트 프로토콜은 시간 보장을 제공할 수 있다.

예를 들어, 송신자가 소켓으로 내보내는 모든 비트가 수신자의 소켓에 100ms 내에 도착하게 할 수 있다.

실시간 애플리케이션에 주로 사용된다.

보안(security)

송신 호스트에서 트랜스포트 프로토콜은 모든 데이터를 암호화할 수 있고, 수신 호스트에서 트랜스포트 프로토콜은 모두 해독할 수 있다.

보통 TCP를 애플리케이션 계층에서 강화하여 TLS로 보안 서비스를 제공한다. (자세한 내용은 8장에서 다룬다.)

2.1.4 인터넷 전송 프로토콜이 제공하는 서비스

1️⃣ TCP 서비스

TCP 전송 프로토콜은 다음 세 가지 서비스를 제공한다.

연결 지향형 서비스

애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환하게 한다.

이 핸드 셰이킹(handshaking) 과정이 클라이언트와 서버에 패킷이 곧 도달할테니 준비하라고 알려주는 역할을 한다.

핸드셰이킹 단계를 지나면, TCP 연결이 두 프로세스의 소켓 사이에 존재한다고 말한다.

이 연결은 두 프로세스가 서로에게 동시에 메시지를 보낼 수 있기에 전이중 연결이라고 한다. (3장에서 더 자세히 다룬다.)

신뢰적인 데이터 전송 서비스

통신 프로세스는 모든 데이터를 오류 없이 올바른 순서로 전달하기 위해 TCP에 의존한다.

TCP는 애플리케이션의 한 쪽이 바이트 스트림을 소켓으로 전달하면, 그 바이트 스트림이 손실되거나 중복되지 않게 수신 소켓으로 전달한다.

혼잡 제어 방식

네트워크가 혼잡 상태에 이르면 프로세스의 속도를 낮추는 방법 (또한, 3장에서 자세히 다룬다.)

2️⃣ UDP 서비스

UDP는 최소의 서비스 모델을 가진 간단한 전송 프로토콜이다.

UDP는 비연결형으로 핸드셰이킹 과정이 없고, 비신뢰적인 데이터 전송 서비스를 제공하여 데이터가 전달되는 것을 보장하지 않는다.

UDP는 또한 혼잡 제어 방식을 포함하지 않아 프로세스의 속도 저하 없이 네트워크를 이용할 수 있다.

그러나 혼잡으로 인해 종단 간 처리율이 낮아져서 속도가 오히려 더 낮아질 수 있다.

인터넷 트랜스포트 프로토콜이 제공하지 않는 서비스

TCP와 UDP는 처리율 혹은 시간 보장 서비스를 제공하지 않는다.

시간 민감 애플리케이션 같은 경우에는 이러한 처리율 및 시간 지연에 잘 대처할 수 있도록 설계되어 있다.

그러나 지연이 과도할 때는 보장이 없기 때문에 한계가 있다.

2.1.5 애플리케이션 계층 프로토콜

애플리케이션 계층 프로토콜은 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의한다.

이는 다음과 같은 내용을 정의한다.

교환 메시지의 타입
여러 메시지 타입의 문법(syntax)
필드의 의미, 즉 필드에 있는 정보의 의미(semantics)
언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지를 결정하는 규칙

여러 애플리케이션 계층 프로토콜은 RFC에 명시되어 있어 공중 도메인에서 찾을 수 있다.

예를 들어, 만약 브라우저 개발자가 HTTP 규칙을 따른다면, HTTP 규칙을 따른 어떠한 웹 서버로부터도 웹페이지를 가져올 수 있다.

다른 많은 애플리케이션 계층 프로토콜은 독점이며 공중 도메인에서 찾을 수 없다.

애플리케이션 계층 프로토콜은 네트워크 애플리케이션의 한 요소일 뿐이다.

예를 들어, 웹 애플리케이션은 문서 포맷 표준, 웹 브라우저, 웹 서버, 웹 애플리케이션 계층 프로토콜(HTTP)을 포함하는 여러 요소들로 구성된다.

2.1.6 이 책에서 다루는 네트워크 애플리케이션

이 책에서는 중요하고 인기 있는 5개의 애플리케이션 분야에 초점을 맞춘다.

웹
전자메일
디렉터리 서비스
비디오 스트리밍
P2P 애플리케이션

2.2 웹과 HTTP

웹은 온디맨드(on-demand) 방식으로 사용자가 원할 때 원하는 것을 수신한다.

개인은 또한, 웹 상에서 많은 정보를 얻고 상호작용할 수 있다.

2.2.1 HTTP 개요

웹 애플리케이션 계층 프로토콜은 웹의 중심이다.

RFC 1945, RFC 7230, RFC 7540에 정의되어 있다.

HTTP는 메시지의 구조 및 클라이언트와 서버가 메시지를 어떻게 교환하는지에 대해 정의하고 있다.

자세히 설명하기 전에 웹 전문 용어들을 알아보자.

웹 페이지(web page)

웹 페이지들은 객체(object)로 구성된다.

객체는 단순히 단일 URL로 지정할 수 있는 하나의 파일(HTML, JPEG 이미지, 자바스크립트 등)이다.

대부분의 웹 페이지는 기본 HTML 파일과 여러 참조 객체로 구성된다.

예를 들어, 웹 페이지가 HTML 텍스트와 5개의 JPEG 이미지로 구성되어 있으면, 이 웹페이지는 6개의 객체를 갖는다.

기본 HTML 파일은 페이지 내부의 다른 객체를 그 객체의 URL로 참조한다.

URL은 객체를 갖고 있는 서버의 호스트 이름과 객체의 경로 이름을 갖고 있다.

e.g.,

http://www.school.edu/picture.gif

호스트의 이름 : www.school.edu
경로 이름 : picture.gif

웹 브라우저와 클라이언트

웹 브라우저(Web browser)는 HTTP의 클라이언트 측을 구현하기 때문에, 웹의 관점에서 브라우저와 클라이언트(client)라는 용어를 혼용하여 사용한다.

브라우저는 요구한 웹 페이지를 보여주고 여러가지 인터넷 항해와 구성 특성을 제공한다.

웹 서버(Web server)는 URL로 각각을 지정할 수 있는 웹 객체를 갖고 있다.

일반적으로, 사용자가 웹 페이지를 요청할 때
(1) 브라우저는 페이지 내부의 객체에 대한 HTTP 요청 메세지를 서버에게 보내고,
(2) 서버는 요청을 수신하고 객체를 포함하는 HTTP 응답 메시지로 응답한다.

HTTP와 TCP

HTTP는 TCP를 전송 프로토콜로 사용한다.

HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작한다.
연결이 이루어지면, 브라우저와 서버 프로세스는 각각의 소켓 인터페이스를 통해 TCP로 접속한다.
클라이언트는 HTTP 요청 메시지를 소켓 인터페이스로 보내고, 소켓 인터페이스로부터 HTTP 응답 메시지를 받는다.
마찬가지로, HTTP 서버는 소켓 인터페이스로부터 요청 메시지를 받고 응답 메시지를 소켓 인터페이스로 보낸다.

이렇게 TCP를 통해 메시지를 보내면 TCP는 신뢰적인 데이터 전송 서비스를 제공하므로
모든 HTTP 요청 메시지가 궁극적으로 서버에 도착한다. (서버에서 보낸 메시지도 마찬가지다.)

HTTP는 TCP가 어떻게 손실 데이터를 복구하고, 올바른 순서로 데이터를 배열하는지 전혀 걱정할 필요가 없어 계층 구조의 장점이 드러난다.

비상태(stateless) 프로토콜

특정 클라이언트가 몇 초 후에 같은 객체를 두 번 요청해도 서버는 전에 보냈다고 알려주지 않고 객체를 또 보낸다.

HTTP 서버는 클라이언트에 대한 정보를 유지하지 않으므로, 비상태(stateless) 프로토콜이라고 부른다.

2.2.2 비지속 연결과 지속 연결

비지속(non-persistent) 연결

클라이언트-서버 상호작용이 TCP 상에서 발생할 때 각 요구/응답 쌍이 분리된 TCP 연결을 통해 보내지는 것을 말한다.

웹 페이지를 서버에서 클라이언트로 전송하는 단계를 살펴보자.

페이지가 기본 HTML 파일과 10개의 이미지로 구성되고, 이 11개의 객체가 같은 서버에 있다고 가정하자.

연결 수행 과정은 다음과 같다.

HTTP 클라이언트는 HTTP 기본 포트 80을 통해 서버로 TCP 연결을 시도한다. TCP 연결과 관련하여 클라이언트와 서버에 각각 소켓이 있게 된다.
HTTP 클라이언트는 설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지를 보낸다. 이 요청에 객체 경로도 포함된다.
HTTP 서버는 TCP 연결 소켓을 통해 요청 메시지를 받는다. 저장 장치로부터 경로의 객체를 추출한다.
HTTP 응답 메시지에 그 객체를 캡슐화 하여 소켓을 통해 클라이언트로 보낸다.
HTTP 서버는 TCP에게 연결을 끊으라고 한다. (그러나 실제로 클라이언트가 응답 메시지를 올바로 받을 때까지 끊지 않는다.)
HTTP 클라이언트가 응답 메시지를 받으면, TCP 연결이 중단된다. 메시지는 캡슐화된 객체가 HTML 파일인 것을 나타낸다.
클라이언트는 응답 메시지로부터 파일을 추출하고 HTML 파일을 조사하여 10개의 JPEG 객체에 대한 참조를 찾는다.
참조되는 JPEG 객체에 대해 1 ~ 4단계를 반복한다.

브라우저는 웹 페이지를 수신하면서, 사용자에게 그 페이지를 보여준다. 다른 브라우저는 웹 페이지를 각기 다른 방식으로 해석하여 보여준다.

HTTP는 통신 프로토콜만 정의할 뿐, 웹 페이지에 대한 관심은 없다.

사용자는 앞의 단계를 동시에 받을지 순차적으로 받을지의 동시성 정도를 조절할 수 있도록 브라우저를 구성할 수 있다.

브라우저는 여러 개의 TCP 연결을 설정하며 다중 연결상에서 웹 페이지의 각기 다른 원하는 부분을 요청할 수 있다.

HTTP 1.0은 비지속 연결을 지원한다.

클라이언트가 HTML 파일을 요청하고 그 파일이 클라이언트로 수신될 때까지의 시간을 측정해보자.

이를 위해 RTT를 알아야 하는데,
RTT(round-trip-time)란 작은 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는 데 걸리는 시간이다.

RTT는 패킷 전파 지연, 큐잉 지연, 처리 지연 등을 포함한다. (1장에 논의되어 있다.)

사용자가 하이퍼링크를 클릭하면, 브라우저와 웹 서버 사이에서 TCP 연결을 시도한다. 이는 3-way handshake를 포함한다.

즉, 클라이언트가 서버로 작은 TCP 메시지를 보내고, 서버는 작은 메시지로 응답하고, 마지막으로 클라이언트가 다시 서버에 응답한다.

서버가 작은 메시지로 응답하면 한 RTT가 계산된다. 이때, 클라이언트는 HTTP 요청 메시지를 TCP 연결로 보내면서 세 번째 응답 부분을 함께 보낸다.

일단, 요청 메시지가 도착하면 서버는 HTML 파일을 TCP 연결로 보내고 이 요청은 또 하나의 RTT를 필요로 한다.

즉, 대략 총 응답 시간은 2RTT와 HTML 파일을 서버가 전송하는 데 걸리는 시간을 더한 것이다.

비지속 연결의 단점

각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 한다.
- TCP 버퍼가 할당되어야 하고, TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 하는데
  이는 수많은 클라이언트들의 요청을 동시에 서비스하는 웹 서버에는 심각한 부담이다.
매번 2RTT를 필요로 한다.

지속(persistent) 연결

HTTP/1.1 지속 연결에서 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지한다. (비지속 연결도 지원한다.)

같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내진다.

즉, 같은 서버에 있는 여러 웹 페이지들을 하나의 지속 TCP 연결을 통해 보낼 수 있다.

이들 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들 수 있다. (파이프라이닝, pipelining)

일반적으로 HTTP 서버는 일정 기간 사용되지 않으면 연결을 닫는다.

HTTP의 디폴트 모드는 파이프라이닝을 이용한 지속 연결을 사용한다.

HTTP 메시지 포맷

RFC는 HTTP 메시지 포맷을 정의한다.

HTTP 요청 메시지

다음은 전형적인 HTTP 요청 메시지이다.

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

특징

ASCII 텍스트로 쓰여 있어 사람들이 읽을 수 있다.
메시지가 다섯 줄로 되어 있고, 각 줄은 CR(carriage return)과 LF(line feed)로 구별된다. 마지막 줄에 이어서 CR과 LF가 따른다.

HTTP 요청 메시지의 첫 줄은 요청 라인이라 부르고, 이후의 줄들은 헤더 라인이라고 부른다.

요청 라인

요청 라인은 3개의 필드, 즉 방식(method) 필드, URL 필드, HTTP 버전 필드를 갖는다.

방식 필드는 GET, POST, HEAD, PUT, DELETE 등의 여러 가지 값을 가질 수 있다.

헤더 라인

Host
- 객체가 존재하는 호스트를 명시한다.
- 이미 호스트까지 TCP 연결이 맺어져 있어 불필요하다고 생각될 수 있지만, 2.2.5절에서 나오는 웹 프록시 캐시에서 필요로 한다.
Connection : 이 헤더 라인을 포함함으로써, 브라우저는 서버에게 지속 연결 사용을 원하는지 비지속 연결 사용을 원하는지 전달한다.
User-agent : 서버에게 요청을 하는 브라우저 타입을 명시한다.
Accept-language : 헤더는 사용자가 객체의 어떤 언어 버전을 원하고 있음을 나타낸다.

개체 몸체(entity body)

GET일 때는 비어있고, POST일 때 사용된다.

POST 메시지로 사용자는 서버에 웹 페이지를 요청하고 있으나, 웹 페이지의 특정 내용은 사용자가 폼 필드에 무엇을 입력하는가에 달려 있다.

폼으로 생성한 요구가 반드시 POST일 필요는 없다. 대신에 흔히 요청된 URL의 입력 데이터를 전송한다.

HEAD 방식은 GET과 유사하다.

서버가 HEAD 방식을 가진 요청을 받으면 HTTP 메시지로 응답하는데, 요청 객체는 보내지 않는다. 흔히 디버깅을 위해 사용된다.

PUT 방식은 웹 서버에 업로드할 객체를 필요로 하는 애플리케이션에 의해 사용된다.

DELETE 방식은 사용자 또는 애플리케이션이 웹 서버에 있는 객체를 지우는 것을 허용한다.

HTTP 응답 메시지

다음은 전형적인 HTTP 응답 메시지를 보여준다.

HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)

상태 라인과 상태 코드

상태 라인(status line)은 버전 필드와 상태 코드, 해당 상태 메시지를 갖는다.

상태 코드와 메시지

200 OK: 요청이 성공했고, 정보가 응답으로 보내졌다.
301 Moved Permanently: 요청 객체가 영원히 이동되었다. 이때, 새로운 URL은 응답 메시지의 Location 헤더에 나와있다.
400 Bad Request : 서버가 요청을 이해할 수 없다.
404 Not Found : 요청한 문서가 서버에 존재하지 않는다.
505 HTTP Version Not Supported : 요청 HTTP 프로토콜 버전을 서버가 지원하지 않는다.

헤더 라인

Connection : 클라이언트에게 메시지를 보낸 후 TCP 연결을 닫을지 말지 결정한다.
Date : HTTP 응답이 서버에 의해 생성되고 보낸 날짜와 시간을 나타낸다.
Server : 메시지가 어떤 웹 서버에 의해 만들어졌는지 나타낸다.
Last-Modified : 객체가 생성되거나 마지막으로 수정된 시간과 날짜를 나타낸다.
Content-Length : 송신되는 객체의 바이트 수를 나타낸다.
Content-Type : 개체 몸체 내부(Entity body)의 객체가 어떤 타입인지 나타낸다.

HTTP 명세서는 많은 헤더라인을 정의하고 있고, 위는 그 중 일부다.

브라우저는 브라우저 타입과 여러 설정, 캐싱하고 있는지에 따라 헤더 라인을 동적으로 생성하고 웹 서버도 비슷하다.

2.2.4 사용자와 서버 간의 상호 작용: 쿠키(cookie)

HTTP 서버는 상태를 유지하지 않는다.

그러나 서버가 사용자 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하기 원하므로
사용자를 확인하는 것이 바람직할 때가 있는데, 이때 HTTP는 쿠키(cookie)를 사용한다.

over stateless HTTP, cookie provides a state related service layer

쿠키 동작 과정

웹 서버에 HTTP 요청 메시지를 전달한다.
웹 서버는 유일한 식별 번호를 만들고 이 식별 번호로 인덱싱 되는 백엔드 데이터 베이스 안에 엔트리를 만든다.
HTTP 응답 메시지에 Set-cookie: 식별 번호의 헤더를 포함해서 전달한다.
브라우저는 헤더를 보고, 관리하는 특정한 쿠키 파일에 그 라인을 덧붙인다.
다시 동일 웹 서버에 요청을 보낼 때
브라우저는 쿠키 파일을 참조하고 이 사이트에 대한 식별번호를 발췌하여 Cookie : 식별 번호의 헤더를 요청과 함께 보낸다.

이렇게 웹 서버는 사용자를 식별할 수 있다.

2.2.5 웹 캐싱

웹 캐시(cache)(프록시(proxy) 서버)는 기점 웹 서버를 대신하여 HTTP 요구를 충족시키는 개체이다.

Goal: satisfy client request without involving origin server

웹 캐시는 자체의 저장 디스크를 갖고 있어, 최근 호출된 객체의 사본을 저장 및 보존한다.

프록시 서버 동작 과정

브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP 요청을 보낸다.
웹 캐시는 객체의 사본이 저장되어 있는지 확인하고, 저장되어 있다면 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체를 전송한다.
갖고 있지 않다면, 기점 서버로 TCP 연결을 설정한다.
이후 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다. 기점 서버는 웹 캐시로 HTTP 응답 메시지를 보낸다.
웹 캐시의 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메시지를 보낸다. (이때, 이미 설정된 TCP를 통해 보낸다.)

캐시(cache)는 요청과 응답을 모두 하는 클라이언트이면서 서버이다.

server for original requesting client
client to origin server

일반적으로 웹 캐시는 ISP(university, company, residential ISP)가 구입하고 설치한다.

웹 캐싱의 사용 이유

클라이언트 요구에 대한 응답 시간을 줄일 수 있다.
보통 클라이언트와 캐시 사이에 높은 속도의 연결이 설정되어 있어 웹서버 캐시에 객체를 갖고 있다면 병목 현상을 줄일 수 있다.
웹 캐시는 한 기관에서 인터넷으로의 접속하는 링크 상의 웹 트래픽을 대폭 줄일 수 있다.
인터넷 전체의 웹 트래픽을 실질적으로 줄여주어 모든 애플리케이션의 성능이 좋아진다.

웹 캐시 미사용과 사용 성능 비교

평균 객체의 크기가 1 Mb이고, 기관 브라우저로부터 기점 서버에 대한 평균 요청 비율이 초당 15 요청이라고 가정하자.
HTTP 메시지 요청이 무시할만큼 작으므로 네트워크 접속 회선에 어떤 트래픽도 발생시키지 않는다고 가정하자.
또한, 접속 회선의 인터넷 부분 라우터가 HTTP 요청을 전달하고 응답을 받을 때까지 평균 소요 시간을 2초라고 가정하자.
통상 이러한 지연을 인터넷 지연이라고 한다.

총 응답 시간 = LAN 지연 + 접속 지연 + 인터넷 지연

LAN의 트래픽 강도는 다음과 같다.

(15 요청/초) X (1 Mb/요청) / 100 Mbps = 0.15

접속 회선(라우터와 라우터 사이)의 트래픽 강도는 다음과 같다.

(15 요청/초) X (1 Mb/요청) / 15 Mbps = 1

LAN의 트래픽 강도는 많아야 수십 ms의 지연을 야기하므로 LAN 지연을 무시할 수 있지만,
트래픽 강도가 1에 가까워지면 1.4절에서 논의한 것과 같이 회선의 지연은 매우 커지고 한없이 증가한다.

접속 회선의 접속률을 100 Mbps 수준으로 늘리면 트래픽 강도를 0.15로 낮추어 해결할 수 있겠지만, 매우 많은 비용이 들어간다.

웹 캐시를 사용한 예시를 보자.

캐시가 만족시킨 요청의 비율(hit rate)은 일반적으로 0.2 ~ 0.7이며, 이 예시에서는 0.4의 적중률을 가진다고 가정하자.

캐시와 클라이언트는 고속 LAN으로 연결되어 있어, 요청의 40%는 캐시에 의해(10ms 이내) 즉시 만족된다.
나머지 60%의 요청은 여전히 기점 서버에 의해 만족되어야 하므로 트래픽 강도는 1.0에서 0.6으로 감소한다.

일반적으로 0.8 미만의 트래픽 강도는 작은 지연에 속한다. (2초에 의하면 무시할 수 있는 수준이다.)

이들을 고려한 평균 지연은 다음과 같다.

0.4 X 0.01초 + 0.6 X 2.01초 = 1.2....

많은 캐시가 저렴한 PC에서 실행되는 공개 소프트웨어를 사용한다.

콘텐츠 전송 네트워크(CDN)을 통해 웹 캐시는 인터넷에서 점진적으로 중요한 역할을 하고 있다.
CDN 회사는 인터넷 전역을 통해 많은 지역적으로 분산된 캐시를 설치하고 있으며,
이를 통해 많은 트래픽을 지역화하고 있다. (전용 CDN을 사용하기도 한다.)

조건부(conditional) GET

웹 캐싱이 사용자가 느끼는 응답 시간을 줄일 수 있지만, 웹 캐시 내부에 있는 복사본이 새 것이 아닐 수 있다는 문제를 야기한다.

복사본이 클라이언트에 캐싱된 이후 웹 서버에 있는 객체가 갱신되었을 수도 있기 때문이다.

HTTP는 클라이언트가 브라우저로 전달되는 모든 객체가 최신의 것임을 확인하면서 캐싱해주는데,
이러한 방식을 조건부 GET(conditional GET) 이라고 한다.

Goal: don't send object if cache has up-to-date cached version

HTTP 요청 메시지가 (1) GET 방식을 사용하고, (2) If-modified-since 헤더를 포함한다면, 그것이 조건부 GET이다.

조건부 GET 동작 과정

브라우저의 요청을 대신해서 프록시 캐시는 요청 메시지를 웹 서버로 보낸다.

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com

웹 서버는 캐시에게 객체를 가진 응답 메시지를 보낸다.

HTTP/1.1 200 OK
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(data data data data data ...)

캐시는 요청하는 브라우저에게 객체를 보내주고 자신에게도 객체를 저장한다.
중요한 것은 캐시가 객체와 더불어 마지막으로 수정된 날짜를 함께 저장한다는 것이다.

일주일 후에 다른 브라우저가 같은 객체를 캐시에게 요청하면 캐시에 저장되어 있다.
이 객체는 지난주에 웹 서버에서 수정되었으므로, 브라우저는 조건부 GET으로 조사를 수행한다.

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Wed, 9 Sep 2015 09:23:24

If-modified-since 값이 일주일 전에 서버가 보낸 Last-Modified 값과 완벽히 일치한다.
이 조건부 GET은 서버에게 If-modified-since에 명시된 값 이후 수정된 경우에만 그 객체를 보내라고 한다.

변경되지 않았다면,

HTTP/1.1 304 Not Modified
Date: Sat, 10 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
(empty entity body)

위와 같은 응답을 보낸다.
데이터가 변화가 없어도 객체를 보내는 것은 대역폭을 낭비하는 것이고, 특히 그 개체가 크다면 사용자가 느끼는 응답 시간이 증가된다.
위 응답 메시지는 클라이언트에게 요청 객체의 캐싱된 복사본을 사용하라는 것을 의미한다.

2.2.6 HTTP/2

2020년 현재 주요 웹 사이트 천만 개의 40%가 HTTP/2를 지원하고 있다.

HTTP/2의 주요 목표는 하나의 TCP 연결상에서 멀티플렉싱 요청/응답 지연 시간을 줄이는 데 있으며,
요청 우선순위화, 서버 푸시, HTTP 헤더 필드의 효율적인 압축 기능 등을 제공한다.

HTTP/2는 클라이언트와 서버 간의 데이터 포맷 방법과 전송 방법을 변경했다.

기존의 HTTP/1.1

지속적인 연결을 사용할 때 웹 페이지당 오직 하나의 TCP 연결을 가짐으로써,
아래 설명하듯이 서버에서의 소켓 수를 줄이며 전송되는 각 웹 페이지는 공정한 네트워크 대역폭을 가질 수 있다.

그러나 하나의 TCP 상에서 모든 웹페이지를 보내면 HOL(Head of Line) 블로킹 문제가 발생할 수 있다.

HOL 블로킹 문제

비디오 아래 수많은 작은 객체들을 포함할 때 서버와 클라이언트 사이에 저속에서 중간 속도의 병목 링크가 있다고 하자.

비디오 클립은 병목 링크를 통과하는데 오래 걸리는 반면, 작은 객체들은 비디오 클립 뒤에서 기다림이 길어진다.

즉, 비디오 클립이 객체들을 블로킹하게 된다.

HTTP/1.1에서는 여러 개의 병렬 TCP 연결을 열어서 위 문제를 해결해왔다.

TCP 혼잡 제어

TCP 혼잡 제어는 각 TCP 연결이 공정하게 병목 링크를 공유하여 같은 크기의 가용한 대역폭을 공평하게 나누게 해준다.

만일 n개의 TCP 연결이 병목 링크에서 작동하고 있다면, 각 연결은 대략 대역폭의 1/n 씩을 사용하게 된다.

하나의 웹 페이지를 전송하기 위해 여러 개의 병렬 TCP 연결을 열게 함으로써 브라우저는 일종의 속임수로 링크 대역폭의 많은 부분을 받게 된다.

많은 HTTP/1.1 브라우저들은 6개까지 병렬 TCP 연결을 열고 HOL을 막을 뿐만 아니라 더 많은 대역폭을 사용할 수 있게 한다.

HTTP/2 프레이밍(framing)

HTTP/2의 주요 목표 중 하나는 하나의 웹 페이지를 전송하기 위한 병렬 TCP 연결의 수를 줄이거나 제거하는 데 있다.

이는 서버에서 열고 유지되는 데 필요한 소켓의 수를 줄일 뿐만 아니라 목표한 대로 TCP 혼잡 제어를 제어할 수 있게 하는 데 있다.

그러나 웹 페이지를 전송하기 위해 오직 하나의 TCP 연결만을 사용하게 될 경우에 HTTP/2는 HOL 블로킹을 피하기 위해 신중하게 구현된 메커니즘이 필요하다.

HTTP/2 프레이밍(framing)이란, HTTP 메시지를 독립된 프레임들로 쪼개고, 인터리빙(interleaving)하고, 반대편 사이트에서 재조립하는 것이다.

예를 들어, 비디오 클립과 크기가 작은 객체 8개의 요청이 들어오면, 서버는 9개의 객체를 보내기 위한 TCP 병렬 요청을 받게된다.

이때 (1) 비디오 클립을 1000개의 프레임으로 나누고 (2) 각 객체를 2개의 프레임으로 나누어 비디오 클립으로부터 하나의 프레임을 전송한다.

이후 프레임 인터리빙을 이용하여 각 소형 객체의 첫 번째 프레임을 보내고 이를 반복하여 HOL 블로킹을 피할 수 있다.

HTTP 메시지를 독립된 프레임들로 쪼개고 인터리빙하고 반대편 사이트에서 재조립하는 것이야말로 HTTP/2의 가장 중요한 개선점이다.

프레이밍은 HTTP/2 프로토콜의 프레임으로 구현된 다른 프레이밍 서브 계층에 의해 이루어진다.

서버가 HTTP 응답을 보내고자 할 때, 응답은 프레이밍 서브 계층에 의해 처리되며 프레임들로 나눠진다.

응답의 헤더필드는 하나의 프레임이 되고, 메시지 본문은 하나의 프레임으로 쪼개진다.

응답 프레임들은 서버의 프레이밍 서브 계층에 의해 인터리빙된 후 하나의 지속적인 TCP 연결상에서 전송된다.

프레임들이 클라이언트에 도착하면 프레이밍 서브 계층에서 처음 응답메시지로 재조립되며 브라우저에 의해 처리된다. (클라이언트에서 서버로 요청할 때도 마찬가지이다.)

각 HTTP 메시지를 독립적인 프레임으로 쪼개는 것 외에도 프레이밍 서브 계층은 프레임을 바이너리 인코딩한다.

바이너리 프로토콜은 파싱하기에 효율적이고, 더 작은 프레임 크기를 갖고, 에러에 강하다.

메시지 우선순위화

메시지 우선순위화는 개발자들로 하여금 요청들의 상대적 우선 순위를 조정할 수 있게 함으로써 애플리케이션의 성능을 최적화할 수 있게 해준다.

클라이언트가 하나의 특정 서버로 동시에 여러 개의 요청을 할 때, 각 메시지에 1에서 256 사이의 가중치를 부여함으로써 요청에 우선순위를 매길 수 있다.

높은 수치일수록 높은 우선순위를 갖는다.

서버는 가장 높은 우선순위의 요청을 위한 프레임을 제일 먼저 보낼 수 있다.

클라이언트 또한 각 의존도에 따라 메시지의 ID를 지정하여 서로 다른 메시지들 간의 의존성을 나타낼 수 있다.

서버 푸싱

HTTP/2의 또 다른 특징은 서버로 하여금 특정 클라이언트 요청에 대해 여러 개의 응답을 보낼 수 있게 해주는 데 있다.

처음 요청에 대한 응답 외에도, 서버는 클라이언트의 요청 없이도 추가적인 객체를 클라이언트에게 푸시하여 보낼 수 있다.

이는 HTML 기반 페이지가 웹 페이지를 완벽하게 구동시킬 필요가 있는 객체들을 가리킬 수 있기에 가능하다.

이러한 객체에 대한 HTTP 요청을 기다리는 대신 서버는 HTML을 분석할 수 있고, 필요한 객체들을 식별할 수 있고,
해당 객체들에 대한 요청이 도착하기도 전에 해당 객체들을 클라이언트로 보낸다.

서버는 해당 요청들을 기다리는 데 소요되는 추가 지연을 없앤다.

HTTP/3

트랜스 프로토콜인 QUIC(3장에서 다룬다) 위에서 작동하도록 설계된 새로운 HTTP 프로토콜로서, 완전히 표준화된 상태는 아니다.

Chapter 1 - 5. 프로토콜 계층과 서비스 모델, 6. 공격받는 네트워크, 7. 컴퓨터네트워킹과 인터넷의 역사

ssun_bear — Tue, 9 Jul 2024 19:59:53 +0900

1.5.1 계층구조

계층구조는 크고 복잡한 시스템의 잘 정의된 특정 부분을 논의할 수 있게 해주며, 이러한 단순화는 매우 중요하다.

시스템이 계층구조를 가질 때, 그 계층이 제공하는 서비스의 구현을 변경하는 것도 매우 쉽다.

어떤 한 계층의 구현이 변하더라도 시스템의 나머지 부분은 변하지 않는다는 것이다.

계층구조의 각 계층은 (1) 그 계층에서 어떤 동작을 취하고 (2) 그 계층 바로 아래 계층 서비스를 사용함으로써 서비스를 제공한다.

프로토콜 계층화

네트워크 프로토콜의 설계 구조를 제공하기 위해,
네트워크 설계자는 프로토콜(프로토콜을 구현하는 네트워크 하드웨어와 소프트웨어)을 계층(layer)으로 조직한다.

즉, 각각의 프로토콜은 한 계층에 속하며, 프로토콜 계층은 소프트웨어, 하드웨어 또는 둘의 통합으로 구현할 수 있다.

한 계층은 상위 계층에 제공하는 서비스(service)에 관심을 갖고, 이것을 계층의 서비스 모델(service model)이라고 한다.
각 계층은 그 계층 내부에서 어떤 동작을 수행하거나, 직접 하위 계층의 서비스를 사용한다.

다양한 계층의 프로토콜을 합하여 프로토콜 스택(protocol stack)이라고 한다.

인터넷 프로토콜 스택

인터넷 프로토콜 스택은 5개 계층으로 구성된다.

물리, 링크, 네트워크, 트랜스포트, 애플리케이션 계층

아래부터 1계층 ~ 5계층

애플리케이션(Application) 계층

네트워크 애플리케이션과 애플리케이션 계층 프로토콜이 있는 곳이다.

인터넷의 애플리케이션 계층이 포함하는 대표적 프로토콜은 다음과 같다.
- HTTP : 웹 문서 요청과 전송 제공
- SMTP : 전자메일 전송 제공
- FTP : 두 종단 시스템 간의 파일 전송 제공
도메인 네임 서버(domain name server, DNS)는 이 애플리케이션 계층에 존재한다.
애플리케이션 계층 프로토콜은 여러 종단 시스템에 분산되어 있어서
한 종단 시스템에 있는 애플리케이션이 다른 종단 시스템에 있는 애플리케이션과 정보 패킷(메시지, message)을 교환하는 데 이 프로토콜을 사용한다.

트랜스포트(Transport) 계층

클라이언트와 서버 간에 애플리케이션 계층 메시지를 전송하는 서비스를 제공한다.

트랜스포트 계층 패킷 = 세그먼트(segment)
트랜스포트 프로토콜의 두 가지 종류로는 다음과 같으며, 이들은 애플리케이션 계층 메시지를 전달한다.
- TCP
  - 애플리케이션에게 연결 지향형 서비스를 제공한다.
  - 목적지로의 애플리케이션 계층 메시지 전달 보장과 흐름 제어(송신자/수신자의 속도 일치)를 포함한다.
  - 긴 메시지를 짧은 메시지로 나누고, 혼잡 제어 기능을 제공한다. (네트워크가 혼잡할 때 출발지의 전송률을 줄임)
- UDP
  - 애플리케이션에게 비연결형 서비스를 제공한다.
  - 신뢰성, 흐름 제어, 혼잡 제어를 제공하지 않는다.

네트워크(Network) 계층 (= IP 계층)

한 호스트에서 다른 호스트로 데이터그램(datagram, IP의 전송 단위)을 라우팅하는 책임을 진다.

즉, 출발지와 목적지 간 일련의 패킷 스위치(인터넷에서는 라우터)를 통해 데이터그램을 라우트한다.

출발지 호스트에서 인터넷 트랜스포트 계층 프로토콜(TCP 또는 UDP)은 트랜스포트 계층 세그먼트와 목적지 주소를 네트워크 계층으로 전달한다.
네트워크 계층은 목적지 호스트의 트랜스포트 계층으로 세그먼트를 운반하는 서비스를 제공한다.

네트워크 계층은 IP 데이터그램의 필드를 정의하며 종단 시스템과 라우터가 이 필드에 어떻게 동작하는지를 정의하는 프로토콜, IP 프로토콜을 가지고 있다.

오직 하나의 IP 프로토콜이 존재한다.
네트워크 계층을 가진 모든 인터넷 요소는 IP 프로토콜을 수행해야만 한다.

인터넷 네트워크 계층은 라우팅 프로토콜을 포함한다.

라우팅 프로토콜은 출발지와 목적지 사이에서 데이터그램이 이동하는 경로를 결정한다.
인터넷은 네트워크의 네트워크이며, 한 네트워크 내부에서 네트워크 운용자는 원하는 어떠한 라우팅 프로토콜이라도 수행할 수 있다.

링크(Link) 계층

전체 프레임을 한 네트워크 요소에서 이웃 네트워크 요소로 이동시킨다.

링크 계층 패킷 = 프레임(frame)

경로상의 한 노드(호스트 혹은 패킷 스위치)에서 다른 노드로 패킷을 이동하기 위해 네트워크 계층은 링크 계층 서비스에 의존해야 한다.

각 노드에서 네트워크 계층은 데이터그램을 아래 링크 계층으로 보내고 링크 계층은 그 데이터그램을 경로상의 다음 노드에 전달한다.
다음 노드에서 링크 계층은 그 데이터그램을 상위 네트워크 계층으로 보낸다.

링크 계층에서 제공하는 서비스는 그 링크에서 채용된 특정 링크 계층 프로토콜에 의해 결정된다.

e.g., 어떤 프로토콜은 송신 노드로부터 하나의 링크를 통해 반대편에 있는 수신 노드까지 신뢰적인 전송을 제공한다. (이는 TCP의 신뢰적인 전달 서비스와는 다름)

데이터그램은 출발지에서 목적지로 가는데 여러 링크를 거치므로, 데이터그램은 경로상의 각기 다른 링크에서 다른 링크 계층 프로토콜에 의해 처리될 수 있다.

물리(Physical) 계층

프레임 내부의 각 비트를 한 노드에서 다음 노드로 이동시킨다.

이 계층의 프로토콜들은 링크에 의존하고, 더 나아가 링크의 실제 전송 매체(꼬임쌍선, 단일 모드 광케이블 등)에 의존한다.

1.5.2 캡슐화

그림은 아래 과정의 물리적 경로를 보여준다.

송신 종단 시스템의 프로토콜 스택 아래로 데이터를 보내며
중간의 링크 계층 스위치와 라우터의 프로토콜 스택을 위아래로 거치고
수신 종단 시스템의 프로토콜 스택 상위로 보낸다.

라우터와 링크 계층 스위치

이들은 둘 다 패킷 교환기다.
종단 시스템과 비슷하게, 라우터와 링크 계층 스위치는 네트워킹 하드웨어와 소프트웨어를 계층으로 구성한다.
그러나 모든 계층을 구현하지는 않고, 일반적으로 하위 계층을 구현한다.
(그림에서는 링크 계층 스위치가 1, 2 계층을 구현하고 라우터는 1~3 계층을 구현)
즉, 인터넷 라우터들은 IP 프로토콜(3계층 프로토콜)을 구현할 수 있지만, 링크 계층 스위치는 불가하다.

호스트

이는 다섯 계층 모두를 구현한다.

인터넷 구조가 네트워크의 ‘가장자리’에서 그 복잡성을 유지한다.

캡슐화(encapsulation)

각 계층에서 패킷은 헤더 필드와 페이로드 필드(payload field)라는 두 가지 형태의 필드를 갖는다.

페이로드(payload)는 일반적으로 그 계층 상위로부터의 패킷을 말한다.

캡슐화 과정

송신 호스트에서 애플리케이션 계층 메시지(application-layer message, 위 그림에서의 M)는 트랜스포트 계층으로 보내진다.
가장 간단한 경우, 트랜스포트 계층은 메시지에 수신 측 트랜스포트 계층에서 사용될 추가 정보인 트랜스포트 계층 헤더 정보(Ht)를 더한다.

트랜스포트 계층 세그먼트(transport-layer segment) = 애플리케이션 계층 메시지 + 트랜스포트 계층 헤더 정보

트랜스포트 계층 세그먼트는 애플리케이션 계층 메시지를 캡슐화한다.
트랜스포트 계층 헤더 정보가 포함하는 내용은 다음과 같다.
- 수신 측의 트랜스포트 계층이 그 메시지를 적절한 애플리케이션으로 보내도록 하는 정보들
- 메시지의 비트들이 변경되었는지 아닌지를 수신자가 결정하게 하는 오류 검출 비트

트랜스포트 계층은 세그먼트를 네트워크 계층으로 보낸다.
네트워크 계층은 출발지와 목적지 종단 시스템 주소와 동일한 헤더 정보(Hn)를 추가하여 네트워크 계층 데이터그램(network-layer datagram)을 만든다.

데이터그램은 링크 계층으로 전달된다.
링크 계층도 자신의 헤더 정보를 추가하여 링크 계층 프레임(link-layer frame)을 만든다.

캡슐화 과정은 위에서 말한 것보다 더 복잡할 수 있다.

큰 메시지는 여러 개의 트랜스포트 계층 세그먼트로 분할될 수 있으며, 그들 각각은 여러 개의 네트워크 계층 데이터그램으로 분할될 수 있다.

그러고 나서 수신 측에서 각 세그먼트는 분할된 데이터그램들로 재구성되어야 한다.

1.6 공격받는 네트워크

인터넷의 모든 유용성과 역동성 뒤에,
‘나쁜 친구들’이 인터넷에 연결된 컴퓨터에 해를 끼리고, 사생활을 침해하고, 우리가 의존하는 인터넷 서비스를 동작하지 못하게 함으로써
일상생활을 망가트리려고 하는 어두운 면이 있다.

네트워크 보안 분야는 나쁜 친구들이 어떻게 컴퓨터 네트워크를 공격할 수 있는가와
그러한 공격으로부터 네트워크를 방어할 수 있는가, 혹은 아예 그러한 공격에 영향을 받지 않는 새로운 구조의 설계 등을 다루는 분야다.

나쁜 친구들은 인터넷을 통해 여러분의 호스트에 멀웨어(악성코드)를 침투시킬 수 있다

우리는 인터넷에서 데이터를 수신/송신하기를 원하기 때문에 장치를 인터넷에 연결한다.

불행하게도 우리에게 전달되는 데이터들 중 해로운 것들도 포함되는데, 이들을 멀웨어(malware)라고 한다.
멀웨어는 우리들의 장치에 들어가서 나쁜 영향을 미친다.

e.g., 파일 삭제, 주민번호, 비밀번호, 키스트로크(keystroke, 키보드를 누르는 것) 등의 사적인 정보를 모으는 스파이웨어를 설치
→ 이러한 정보를 모아 나쁜 친구들에게 인터넷을 통해 다시 보낸다.

면역되지 않은 호스트는 수천의 비슷한 면역되지 않은 장치들로 구성된 네트워크, 즉 봇넷(botnet)에 등록될 수 있다.
나쁜 친구들은 목표로 하는 호스트에 대해 스팸 전자메일 분해 혹은 분산 DoS(Denial of Service) 공격을 위해 이 봇넷을 제어하고 이용한다.

오늘날 널리 퍼져 있는 많은 멀웨어는 자기복제(self-replicating)를 한다.
자기복제 멀웨어는 아래의 방법을 통해 기하급수적으로 퍼질 수 있다.

한 호스트에 영향을 미치면, 그 호스트에서 인터넷을 통해 다른 호스트로의 엔트리를 찾는다.
새롭게 영향을 받은 호스트로부터 또 다른 많은 호스트로의 엔트리를 찾는다.

나쁜 친구들은 서버와 네트워크 인프라스트럭처를 공격할 수 있다

DoS(Denial-of-Service) 공격

네트워크, 호스트 혹은 다른 인프라스트럭처의요소들을 정상적인 사용자가 사용할 수 없게 하는 것

웹 서버, 전자메일 서버, DNS 서버, 기관 네트워크는 DoS 공격을 받을 가능성이 있다.

DoS 공격의 세 가지 범주

취약성 공격(vulnerability attack)

만약 올바른 순서의 패킷을 공격받기 쉬운 애플리케이션 혹은 운영체제에 보내면(교묘한 메시지를 보내는 것을 포함)
그 서비스는 중단되거나, 호스트가 동작을 멈출 수도 있다.

대역폭 플러딩(bandwidth flooding)

목표 호스트의 접속 링크가 동작하지 못하도록 많은 패킷을 보내서 정당한 패킷들이 그 서버에 도달하지 못하게 한다.

1.4.2절의 지연과 손실 분석 논의를 기억해보자.

만약 서버가 R bps의 접속 속도를 갖고 있다면, 공격자는 피해를 주기 위해 대략적으로 R bps의 속도로 트래픽을 전송하면 된다.

만약 R가 매우 크다면 단일 공격 소스는 서버에 나쁜 영향을 줄 수 있는 충분한 트래픽을 발생시킬 수 없다.

더 나아가, 모든 트래픽이 하나의 소스에서 방사된다면 업스트림 라우터는 그 공격을 발견할 수 있고
트래픽이 서버에 가까이 가기 전에 그 소스로부터 모든 트래픽을 차단(block)할 수 있다.

아래 그림처럼 분산 DoS(DDoS) 공격에서 공격자는 다중의 소스를 제어하고 각 소스는 목표에 트래픽을 보낸다.

이런 방법으로 모든 제어 소스에 걸친 통합 트래픽 속도가 서비스를 무능력하게 하기 위해서는 전송률이 약 R이어야 한다.

수천개의 호스트로 구성된 봇넷을 이용하는 DDoS 공격은 오늘날 매우 흔하다.

연결 플러딩(connection flooding)

목표 호스트에 반열림(half-open) 혹은 전열림(fully open)된 TCP 연결을 설정한다.

호스트는 가짜 연결을 처리하느라 바빠서 정상적인 연결을 받아들이는 것을 중단하게 된다.

컴퓨터 네트워크 설계자는 DoS 공격을 방어하기 위해 무엇을 할 수 있는가?

→ 세 가지 유형의 DoS 공격에는 각기 다른 방어가 필요하다.

나쁜 친구들은 패킷을 탐지할 수 있다

유비쿼터스(ubiquitous) 인터넷 접속은 매우 편리하고 이동 사용자를 위한 애플리케이션이 가능하지만, 인터넷 접속은 주요한 보안 취약성을 창출했다.

무선 전송장치의 근처에 수동적인 수신자 즉, 패킷 스니퍼(packet sniffer)를 위치시킴으로써 그 수신자는 전송되고 있는 모든 패킷의 사본을 얻을 수 있다.

스니퍼는 무선 뿐만 아니라, 유선 환경에서도 배치될 수 있다.
(이더넷 LAN, 케이블 접속 기술, 인터넷에 연결되는 기관의 접속 라우터 혹은 접속 링크 등)

나쁜 친구들은 이렇게 가로챈 패킷을 오프라인으로 분석하여 비밀번호, 주민등록번호, 영업 비밀 등 모든 종류의 민감한 정보를 얻을 수 있다.

패킷 스니퍼는 수동적이기 때문에, 즉 스니퍼는 채널에 패킷을 삽입하지 않기 때문에 이를 탐지하기가 어렵다.

그래서 무선 채널로 패킷을 보낼 때 어떤 나쁜 친구가 우리 패킷의 사본을 기록하고 있을 수 있다는 가능성을 받아들여야 한다.

패킷 스니핑을 방지하기 위한 가장 좋은 방어는 암호화를 포함하는 것이다. (8장에서 다룸)

나쁜 친구들은 여러분이 신뢰하는 사람인 것처럼 위장할 수 있다

임의의 출발지 주소, 패킷 내용, 목적지 주소를 갖는 패킷을 생성하고 이 패킷을 인터넷으로 보내는 것은 매우 쉽다.

가짜 출발지 주소를 가진 패킷을 인터넷으로 보내는 능력을 IP 스푸핑(spoofing)이라고 하며,
한 사용자가 다른 사용자인 것처럼 행동하는 여러 가지 방법 중 하나다.

이 문제를 해결하기 위해서는 종단 인증(end-point authentication),
즉 메시지가 실제로 와야 할 곳으로부터 온 것인지 확신할 수 있는 방법이 필요하다.

네트워크 애플리케이션과 프로토콜의 경우 어떻게 이것을 할 수 있을까? (8장에서 다룸)

인터넷은 처음에 어떻게 보안 문제에 직면하게 되었을까?

인터넷은 원래 ‘투명한 네트워크에 연결된 상호 신뢰할 수 있는 사용자 그룹’ 모델,
즉 보안이 필요 없는 모델에 기반을 둔 방식으로 설계되었다. [Blumenthal 2001]

따라서 원래 인터넷 구조의 많은 특성은 이러한 상호 신뢰를 반영하고 있다.
e.g., 한 사용자가 패킷을 다른 사용자에게 보내는 능력은 default, 사용자 식별은 default로 인증해야 하는 것보다는 선언된 액면 그대로 믿는 것이다.

그러나 오늘날 인터넷은 ‘상호 신뢰하는 사용자’를 분명히 포함하지 않는다.

그럼에도 불구하고 오늘날의 사용자들은 서로를 꼭 신뢰하지는 않을 때, 익명으로 통신하기를 원할 때,
제3자를 통해 간접적으로 통신할 때(이동 지원 에이전트, mobility-assisting agent) 등 이러한 상황에서도 여전히 통신이 필요하다.

아직 우리 앞에는 많은 보안 관련 해결 과제가 존재한다.

우리는 스니핑, 종단 위장(end-point masquerading), 중간자 공격, DDoS 공격, 멀웨어 등에 방어하는 방법을 찾아야 한다.

상호 신뢰하는 사용자 간의 통신은 일반적인 것이 아니라 예외적인 것임을 명심해야 한다.

1.7 컴퓨터 네트워킹과 인터넷의 역사

1.7.1 패킷 교환 개발: 1961~1972

1960년대 초의 세계 주요 통신 네트워크는 전화망이었다.

전화망이 송신자에게서 수신자로 정보를 전송하는 데 회선 교환을 사용하였다. (음성이 송수신자 간에 일정한 속도로 전송된다면 이는 적절한 선택)

각 사용자가 만드는 트래픽은 집중적(bursty)이었다.

즉, 원격 컴퓨터에 명령을 내리는 활동과 응답을 기다리고 응답을 검토하는 비활동 사이의 기간이 일정하지 않았다.

세계적으로 3개의 연구 그룹이 회선 교환을 대신할 수 있는 효율적이고 견실한 방법으로서 패킷 교환의 개념을 창안하였다.

1967년, 로렌스 로버츠(Lawrence Roberts)는 ARPAnet에 대한 대략의 계획을 발간하였다.
→ 첫 번째 패킷 교환 컴퓨터 네트워크이자 오늘날 공중 인터넷의 직계 원조
1969년, 첫 번째 패킷 스위치가 UCLA에 설치되었다.
1972년, ARPAnet은 약 15개의 노드로 커졌다.
ARPAnet 종단 시스템 간에 NCP(Network-Control Protocol)라고 하는 첫 번째 호스트 간(host-to-host) 프로토콜이 완성되었다. [RFC 001]

종간 간에서 프로토콜을 사용할 수 있게 되자, 애플리케이션을 개발할 수 있게 되었다.

1972년, 레이 톰린슨(Ray Tomlinson)이 최초의 전자메일 프로그램을 만들었다.

1.7.2 독점 네트워크와 인터네트워킹: 1972~1980

초기 ARPAnet은 단일 폐쇄 네트워크였다.

즉, ARPAnet 호스트와 통신하기 위해서는 다른 ARPAnet IMP에 실제로 접속해야 했다.

1970년대 중반 초, ARPAnet과 별개의 패킷 교환 네트워크들이 생겨났다.

DARPA의 패킷 위성 [RFC 829]
패킷 라디오 네트워크 [Kahn 1978]
ALOHAnet : 하와이에 위치하는 대학들을 함께 연결하는 마이크로파 네트워크 [Abramson 1970]
Cyclades : 루이 푸장(Louis Pouzin)이 이끈 프랑스 패킷 교환 네트워크 [Think 2012]
시분할 네트워크 : 1960년대 후반에서 1970년대 초반의 네트워크 [Schwartz 1977]
e.g., Tymnet, GE Information Services 네트워크

네트워크 수가 증가함에 따라
네트워크를 연결하는 포괄 구조(상호연결 네트워크, 네트워크의 네트워크)의 개발 시기가 점차 다가왔다.

이러한 구조 원리는 TCP 프로토콜로 구체화되었다.

이는 아래의 두 가지를 결합한 것이며, 오늘날의 TCP와는 매우 다르다.

종단 시스템의 재전송을 통한 데이터의 신뢰적인 전송 (오늘날 TCP의 일부분으로 남겨짐)
전달 기능 (오늘날 IP가 수행함)

패킷 음성 같은 애플리케이션을 위한 비신뢰적이고 흐름 제어가 없는 종단 간의 전송 서비스의 중요성에 대한 인식과 결합하여
TCP에 대한 초기 실험은 TCP에서 IP를 분리하도록 했고, UDP 프로토콜을 개발하였다.

TCP, UDP, IP 같은 주요 인터넷 프로토콜은 1970년대 후반에 그 개념이 자리 잡았다.

ALOHA 프로토콜[Abramson 1970]은 지리상 분산된 사용자를 하나의 방송통신매체(라디오 주파수)를 공유하게 하는
최초의 다중 접속(multiple access) 프로토콜이다.

다중 접속 프로토콜에 대한 에이브럼슨의 연구는
유선 기반 공유 브로드캐스트 네트워크를 위한 이더넷 프로토콜[Metcalfe 1976] 개발에서 멧칼프(Metcalfe)와 보그스(Boggs)에 의해 발전되었다.

즉, PC 혁명과 네트워크 폭발이 있기 훨씬 전인 25년 전, 이들은 오늘날의 PC LAN의 기초를 닦고 있었다.

1.7.3 네트워크 확산: 1980~1990

1970년대 말까지 약 200개의 호스트가 ARPAnet에 연결되었다.
1980년대 말까지 공중 인터넷(네트워크 연합)에 연결된 호스트 수는 십만 개에 이르렀다.

이처럼 1980년대는 거대한 성장 시대였는데, 이러한 성장의 주요인은 대학들을 연결하는 컴퓨터 네트워크를 만드는 여러 노력이었다.

CSNET(Computer Science Network) : ARPAnet에 접속하지 않고 대학 연구자들을 연결하기 위해 만들어졌다.
1986년, NSFNET(National Science Foundation Network)이 NSF이 지원하는 슈퍼컴퓨터센터에 접속 가능하도록 만들어졌다.
56 kbps의 초기 백본으로 시작하여 NSFNET의 백본은 1980년대 말에 1.5 Mbps로 동작하게 되었으며, 지역 네트워크를 연결하는 주요 백본이 되었다.

ARPAnet 커뮤니티에서 오늘날 인터넷 구조의 많은 구성요소가 등장했다.

1983년 1월 1일, APRAnet의 새로운 표준 호스트 프로토콜인 TCP/IP가 공식 설치되었다. (NCP 프로토콜을 대체)
NCP에서 TCP/IP로의 전환[RFC 801]은 플래그 데이(flag day) 형태의 사건이었다. 즉, 모든 호스트는 같은 날 동시에 TCP로 전환해야 했다!

1980년대 후반에 호스트 기반의 혼잡 제어를 구축하기 위해 TCP에 중요한 확장이 이루어졌다. [Jacobson 1988]

도메인 네임 시스템(domain name system, DNS)의 개발 [RFC 1034]
이는 도메인(사람이 읽을 수 있는 인터넷 이름, e.g., jw.edu, euna.com)과 32비트 IP 주소 간의 매핑에 사용된다.

1980년대 초 프랑스에서는 데이터 네트워킹을 모든 가정으로 보급하려는 미니텔(Minitel) 프로젝트를 시작했다.

공중 패킷 교환 네트워크 (가상 회선 방식을 사용하는 X.25 프로토콜 스택에 기반을 둠)
미니텔 서버와 내장형 저속 모뎀을 포함하는 값싼 터미널로 구성되었다.
1984년, 프랑스 정부가 원하는 모든 가정에 무상으로 미니텔 단말기를 제공하고 큰 성공을 거두었다.
미니텔 사이트는 전화번호 사이트 같은 무료 사이트와 사용자가 사용량에 따라 요금을 받는 사설 사이트를 포함했다.

1.7.4 인터넷 급증: 1990년대

1990년대는 인터넷의 지속 발전화 상업화를 상징하는 두 사건으로 대변된다.

인터넷이 원조인 ARPAnet이 더 이상 존재하지 않게 되었다. (1991년에 NSFNET 상업화 제한을 풀었음)
월드와이드웹(World Wide Web, WWW)이 출현하였다.

웹은 검색, 인터넷 상거래, 소셜 네트워크 등을 포함하는 수백 가지의 새 애플리케이션을 만들고 보급하는 플랫폼으로 등장했다.

1989~1991년, 팀 버너스 리(Tim Berners-Lee)가 CERN에서 처음으로 만들었다. [Berners-Lee 1989]
웹의 네 가지 주요소(HTML, HTTP, 웹 서버, 브라우저)의 초기 버전을 개발하였다.
이는 1940년대의 바내바르 부시(Vannevar Bush)와 1960년대 이후의 테드 넬슨(Ted Nelson)이 개발한
하이퍼텍스트에 관한 초기 연구의 아이디어를 바탕으로 하였다.
1993년 말에 약 200개의 웹 서버가 동작 중이었다.

이 시기, 여러 연구자가 GUI 인터페이스형 웹 브라우저를 개발하고 있었으며,
크고 작은 회사가 웹 서버를 운영했고 웹을 통한 상거래를 시작했다.

1990년대 후반은 인터넷의 큰 성장과 혁신의 시대이다.

세기가 끝나는 시점에서 인터넷은 다음 4개의 킬러 애플리케이션을 포함해서 수백 개의 인기 있는 애플리케이션을 지원하게 된다.

첨부물과 웹 접속 전자메일을 포함하는 전자메일
웹 브라우징과 인터넷 상거래를 포함하는 웹
대화상대 목록을 가진 인스턴트 메시징
냅스터(Napster)가 개척한 P2P를 통한 MP3 파일 공유

1.7.5 새 천 년

21세기 첫 20년 동안에 인터넷에 연결된 스마트폰과 함께 인터넷보다 사회를 더 변화시킨 기술은 없었다.

그리고 컴퓨터 네트워킹에서의 혁신은 빠른 속도로 계속되어 있다.

그러나 다음의 개발들은 특별한 관심을 끌고 있다.

가정에 광대역 인터넷 접속의 공격적인 구축을 목격하고 있다.
(케이블 모뎀과 DSL뿐만 아니라 그리고 이제는 5G 무선 서비스 포함)

고속 무선 인터넷 접속의 빠른 보급
- 이를 통해 네트워크에 지속적으로 접속할 수 있을 뿐만 아니라, 엘프(Yelp), 틴더(Tinder), 와즈(Waz) 같은
  새로운 위치 기반 애플리케이션이 가능해졌다.
- 인터넷에 연결되는 무선 장치 수는 2011년에 유선 장치의 수를 초과하였다.

페이스북, 인스타그램, 트위터 등 온라인 소셜 네트워크는 인터넷상에 거대한 사람들의 네트워크를 생성했다.
- API를 통해 온라인 소셜 네트워크는 모바일 결제를 포함하는 새로운 네트워크 애플리케이션과 분산 게임용 플랫폼을 생성한다.

1.3.3절에서 논의한 바와 같이 구글와 마이크로스프트 같은 온라인 서비스 제공자는 자신의 커다란 사설 네트워크를 구축하였다.
- 이는 전 세계적으로 분산된 자신들의 데이터 센터를 연결할 뿐만 아니라
  하위 계층 ISP와 직접 연결(peering)함으로써 가능한 한 많은 인터넷을 우회하는 데 사용된다.
- 그 결과 구글의 데이터 센터가 마치 사용자의 컴퓨터 내에서 동작하는 것처럼, 구글은 거의 즉각적으로 검색 결과와 전자메일 접속을 제공한다.

클라우드 회사는 애플리케이션에 확장 가능한 컴퓨팅과 저장 환경을 제공할 뿐만 아니라, 고성능 사설 네트워크 접속도 제공한다.
- 많은 인터넷 상거래 회사는 ‘클라우드’에서 자신의 애플리케이션을 수행하고 있다. (아마존의 EC2, 마이크로소프트의 Azure, 알리바바 클라우드)
- 많은 회사와 대학도 그들의 인터넷 애플리케이션(e.g., 전자메일과 웹 호스팅)을 클라우드로 이동했다.