
## 왜 필요한가?


React 개발을 하다 보면 다음과 같은 당황스러운 상황들을 만날 수 있다.

- "분명 같은 객체인데 왜 useEffect가 무한 루프에 빠지지?"
- "React.memo를 썼는데도 왜 계속 리렌더링이 일어나지?"
- "객체를 의존성 배열에 넣으니까 이상하게 동작해..."

이 모든 문제의 원인은 React가 객체를 어떻게 비교하는지의 메커니즘에 이유가 숨어있을 수 있다. React의 모든 최적화(가상 DOM 비교, 컴포넌트 리렌더링 판단, 메모이제이션)가 이 객체 비교 방식에 의존하기 때문이다.


## 문제 상황


실제로 겪을 수 있을 법한 예제를 살펴보자.


```javascript
function DataFetcher() {
  const [data, setData] = useState(null)
  const [loading, setLoading] = useState(false)

  const fetchOptions = {
    method: 'GET',
    headers: { 'Authorization': 'Bearer token' }
  }

  useEffect(() => {
    setLoading(true)
    fetch('/api/data', fetchOptions)
      .then(res => res.json())
      .then(result => {
        setData(result)
        setLoading(false)
      })
  }, [fetchOptions])

  return loading ? <div>Loading...</div> : <div>{data}</div>
}
```


위 컴포넌트는 무한 루프에 빠진다. 왜 그럴까? 단계별로 분석해보자.


### 무한 루프가 발생하는 과정


1단계: 첫 렌더링


```plain text
컴포넌트 실행 → fetchOptions 객체 생성 (메모리 주소: 0xA001)
→ useEffect 실행 (첫 렌더링이므로)
→ API 호출 → setData 실행
```


2단계: 상태 업데이트로 리렌더링


```plain text
setData로 인한 리렌더링 → 컴포넌트 함수 다시 실행
→ fetchOptions 객체 다시 생성 (새로운 메모리 주소: 0xA002)
```


여기가 핵심이다. 똑같은 `{ method: 'GET', headers: {...} }` 내용이지만, 자바스크립트에서는 새로운 객체로 취급된다.


3단계: React의 의존성 비교


```plain text
React: "이전 fetchOptions(0xA001)와 현재 fetchOptions(0xA002)를 비교해보자"
→ Object.is(0xA001, 0xA002) === false
→ "의존성이 변경되었네! useEffect를 다시 실행하자"
```


4단계: 무한 반복


```plain text
useEffect 재실행 → API 호출 → setData → 리렌더링
→ 새 fetchOptions 생성 → 의존성 변경 감지 → useEffect 재실행 → ...
```


이것이 바로 React가 객체 비교에 민감한 이유다. 개발자 눈에는 같은 객체지만, React는 참조(메모리 주소)로 비교하기 때문에 "다른 객체"로 인식한다.


## 자바스크립트의 객체 비교 방식 이해


### 원시 타입과 객체 타입의 차이점


자바스크립트에서 값을 비교하는 방식을 이해해보자.


```javascript
let name1 = 'React'
let name2 = 'React'
console.log(name1 === name2)  // true

const config1 = { theme: 'dark' }
const config2 = { theme: 'dark' }
console.log(config1 === config2)  // false
```


원시 타입인 문자열은 값 자체를 비교해서 `true`가 나오지만, 객체는 참조를 비교해서 `false`가 나온다.


이것이 중요한 이유는 메모리에 저장되는 방식이 다르기 때문이다. 원시 타입은 값 자체가 변수에 저장되지만, 객체는 힙 메모리의 주소(참조)만 변수에 저장된다.


```javascript
// 메모리 관점에서 보면
const obj1 = { name: 'Kim' }  // 변수: 0x001 → 힙: 0xA001번지에 실제 객체
const obj2 = { name: 'Kim' }  // 변수: 0x002 → 힙: 0xA002번지에 실제 객체

// 비교할 때는 주소를 비교
console.log(obj1 === obj2)  // 0xA001 === 0xA002 → false
```


여기서 핵심은 내용이 완전히 같아도 서로 다른 메모리 위치에 있으면 다른 객체로 인식된다는 점이다.


## React의 비교 메커니즘 분석


### Object.is()의 동작 원리


React는 기본적으로 `Object.is()`를 사용한다. `packages/shared/objectIs.js`에서 Object.is의 폴리필을 구현하고 있다.


```javascript
function is(x, y) {
  return (
    (x === y && (x !== 0 || 1 / x === 1 / y)) ||
    (x !== x && y !== y)
  );
}

const objectIs = typeof Object.is === 'function' ? Object.is : is;
```


네이티브 `Object.is`가 있으면 사용하고, 없으면 자체 구현한 `is` 함수를 사용한다.


**Object.is의 실제 동작 예시**


```javascript
Object.is(5, 5)           // true
Object.is('hello', 'hello') // true
Object.is({}, {})         // false
Object.is(+0, -0)         // false (=== 는 true)
Object.is(NaN, NaN)       // true (=== 는 false)
```


이 함수가 하는 일은 기본적으로 `===` 비교이지만, `+0`과 `-0`, 그리고 `NaN` 케이스를 올바르게 처리한다는 점이다. 공식 문서에서도 **useEffect는 Object.is를 사용해 의존성을 비교한다고 명시**되어 있다. 이로 인해 React에서는 개발자가 기대하는 방식으로 특수한 값들이 비교된다.


### ShallowEqual


React는 `Object.is()`만으로는 부족한 객체 비교를 위해 `shallowEqual` 함수를 사용한다.


```javascript
// packages/shared/shallowEqual.js
function shallowEqual(objA, objB) {
  if (Object.is(objA, objB)) {
    return true
  }

  if (typeof objA !== 'object' || objA === null ||
      typeof objB !== 'object' || objB === null) {
    return false
  }

  const keysA = Object.keys(objA)
  const keysB = Object.keys(objB)

  if (keysA.length !== keysB.length) {
    return false
  }

  for (let i = 0; i < keysA.length; i++) {
    const currentKey = keysA[i]
    if (!objB.hasOwnProperty(currentKey) ||
        !Object.is(objA[currentKey], objB[currentKey])) {
      return false
    }
  }

  return true
}
```


위 함수의 실행 과정을 단계별로 분석해보면,

1. 참조가 동일한지 검사해 같은 객체를 가리키는지 확인한다.
2. 타입을 비교해 둘 다 객체인지 확인한다.
3. 키 개수를 비교해 속성 개수가 다르면 즉시 false한다.
4. 각 속성값을 비교해 **1 depth 까지만** `Object.is()`로 비교한다.

이것이 "얕은 비교"라고 불리는 이유는 객체의 첫 번째 깊이만 검사하기 때문이다.


### 얕은 비교의 동작


얕은 비교가 어떻게 동작하는지 자바스크립트로 확인해보자.


```javascript
const user1 = { name: 'Kim', age: 30 }
const user2 = { name: 'Kim', age: 30 }
shallowEqual(user1, user2)  // true
```

1. `Object.is(user1, user2)` → false (다른 참조)
2. 둘 다 객체임 → 계속 진행
3. 키 개수 동일 (2개) → 계속 진행
4. `user1.name === user2.name` → 'Kim' === 'Kim' → true
5. `user1.age === user2.age` → 30 === 30 → true
6. 모든 속성이 일치 → true 반환

하지만 중첩된 객체에서는 실패한다.


```javascript
const profile1 = { user: { name: 'Kim', age: 30 } }
const profile2 = { user: { name: 'Kim', age: 30 } }
shallowEqual(profile1, profile2)  // false
```

1. `Object.is(profile1, profile2)` → false
2. 둘 다 객체임 → 계속 진행
3. 키 개수 동일 (1개) → 계속 진행
4. `profile1.user === profile2.user` 비교
    - `{name:'Kim', age:30}` === `{name:'Kim', age:30}`
    - 서로 다른 객체 참조 → false
5. false 반환

## 이것이 React에서 문제가 되는 이유


### 의존성 배열에서의 함정


```javascript
function WeatherWidget({ city }) {
  const [weather, setWeather] = useState(null)

  // 매 렌더링마다 새로운 객체 생성
  const apiConfig = {
    method: 'GET',
    headers: { 'API-Key': process.env.WEATHER_API_KEY }
  }

  useEffect(() => {
    fetch(`/api/weather/${city}`, apiConfig)
      .then(res => res.json())
      .then(setWeather)
  }, [city, apiConfig])  // apiConfig가 의존성 배열에 포함됨

  return <div>{weather?.temperature}°C</div>
}
```


위 코드는 무한 루프에 빠진다. 실행 과정을 자세히 살펴보자.


### 무한 루프 발생 과정


```plain text
1) 첫 렌더링
   컴포넌트 실행 → apiConfig 생성 (메모리 주소: 0xA001)
   → useEffect 실행 (첫 렌더링이므로)
   → fetch 호출 → 응답 받음 → setWeather(data) 실행

2) state 변경으로 리렌더링
   setWeather로 인한 리렌더링 → 컴포넌트 함수 다시 실행
   → 새로운 apiConfig 객체 생성 (메모리 주소: 0xA002)

3) React의 의존성 비교
   React: 이전 apiConfig(0xA001)와 현재 apiConfig(0xA002) 비교
   → Object.is(0xA001, 0xA002) === false
   → '의존성이 변경되었군.. useEffect를 다시 실행해야지'

4) 무한 반복
   useEffect 재실행 → fetch 호출 → setWeather
   → 리렌더링 → 새 apiConfig 생성 → useEffect 재실행...
```


### 실제로 확인해보기


![2025-08-2411.36.34-ezgif.com-video-to-gif-converter.gif](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/react-object-comp/image-1756020669758-0.gif)


내용은 완전히 동일하지만 React는 참조(메모리 주소)로 비교하기 때문에 다른 객체로 인식한다.


### 해결 방법


```javascript
// 1: useMemo
function WeatherWidget({ city }) {
  const [weather, setWeather] = useState(null)

  const apiConfig = useMemo(() => ({
    method: 'GET',
    headers: { 'API-Key': process.env.WEATHER_API_KEY }
  }), [])

  useEffect(() => {
    fetch(`/api/weather/${city}`, apiConfig)
      .then(res => res.json())
      .then(setWeather)
  }, [city, apiConfig])

  return <div>{weather?.temperature}°C</div>
}
```


useMemo는 가장 일반적인 해결 방법이다. 의존성 배열이 빈 배열 `[]`이므로 컴포넌트가 처음 마운트될 때 한 번만 객체를 생성하고, 그 이후로는 항상 같은 참조를 반환한다. 따라서 useEffect의 의존성 배열에 `apiConfig`를 포함해도 참조가 변하지 않으므로 무한 루프가 발생하지 않는다.


이 방법은 코드가 명확해 예측하기 쉽다. 코드를 보면 "이 객체는 한 번만 생성되고 재사용된다"고 바로 알 수 있다. 또한 나중에 의존성이 추가되어야 할 상황에도 쉽게 추가할 수 있다. 의존성 배열에 값을 추가하기만 하면 된다.


단점이라면 약간의 메모리 오버헤드와 초기 계산 비용이 있다는 점이다. 복잡한 객체를 생성하는 경우에는 오히려 성능상 이득이 있다.


```javascript
// 2: useEffect 내부로 이동
function WeatherWidget({ city }) {
  const [weather, setWeather] = useState(null)

  useEffect(() => {
    const apiConfig = {
      method: 'GET',
      headers: { 'API-Key': process.env.WEATHER_API_KEY }
    }

    fetch(`/api/weather/${city}`, apiConfig)
      .then(res => res.json())
      .then(setWeather)
  }, [city])

  return <div>{weather?.temperature}°C</div>
}
```


이 방법이 동작하는 이유는 React가 의존성 배열에 있는 값들만 비교하기 때문이다. useEffect 내부에서 생성되는 객체는 의존성 배열에 포함시킬 필요가 없다. `apiConfig` 객체가 매번 새로 생성되지만 의존성 배열에 없으므로 무한 루프가 발생하지 않는다. city가 변경될 때만 useEffect가 실행되고, 그때마다 내부에서 새로운 apiConfig를 생성해서 사용한다. ESLint의 exhaustive-deps 규칙도 이 패턴을 허용한다.


다만 주의할 점이 있다. 만약 객체 내부에서 외부 변수(props나 state)를 참조한다면 반드시 해당 변수들을 의존성 배열에 포함해야 한다. 예를 들어 `headers: { 'API-Key': apiKey }`처럼 props의 apiKey를 사용한다면 `[city, apiKey]`로 의존성을 설정해야 한다.


```javascript
// 3: 컴포넌트 외부에 정의
const API_CONFIG = {
  method: 'GET',
  headers: { 'API-Key': process.env.WEATHER_API_KEY }
}

function WeatherWidget({ city }) {
  const [weather, setWeather] = useState(null)

  useEffect(() => {
    fetch(`/api/weather/${city}`, API_CONFIG)
      .then(res => res.json())
      .then(setWeather)
  }, [city])

  return <div>{weather?.temperature}°C</div>
}
```


컴포넌트 외부에 객체를 정의하는 방법은 객체가 절대 변하지 않을 때 사용한다. `API_CONFIG`는 모든 컴포넌트 인스턴스가 공유하는 단일 객체이므로 참조가 항상 동일하다. 따라서 의존성 배열에 넣어도 무한 루프가 발생하지 않는다.


하지만 실제로는 의존성 배열에 넣을 필요도 없다. React는 컴포넌트 외부의 값들이 렌더링 사이클과 무관하다는 것을 알고 있기 때문이다. 이 방법의 장점은 메모리 효율성이다. 여러 컴포넌트 인스턴스가 있어도 객체는 하나만 존재한다. 단점은 환경변수나 전역 설정이 바뀌어도 자동으로 반영되지 않는다는 점이다.


이것이 바로 React가 객체 비교에 민감한 이유다. 개발자 눈에는 같은 객체지만, React는 완전히 다른 객체로 인식한다.


### 왜 React는 깊은 비교를 하지 않을까?


React가 shallow comparison을 선택한 이유는 성능뿐만 아니라 설계 철학과 관련이 있다.


### React 공식 설계 원칙


React가 shallow comparison을 선택한 배경에는 몇 가지 기술적 고려사항들이 있다.


**예측 가능한 성능**


[useEffect 문서](https://react.dev/reference/react/useEffect)에 따르면 의존성 비교는 Object.is를 사용한다고 명시되어 있다. 객체의 깊이를 미리 알 수 없는 상황에서 깊은 비교는 성능을 예측하기 어렵게 만들기 때문으로 추론된다.


**불변성 기반 아키텍처**


React 공식 문서의 ["객체 State 업데이트하기"](https://react.dev/learn/updating-objects-in-state) 섹션에서는 "객체나 배열을 업데이트할 때는 새로운 객체를 생성해야 한다"고 강조한다. 이런 불변성 패턴이 shallow comparison과 잘 맞아떨어진다.


```javascript
// React가 권장하는 패턴
const [user, setUser] = useState({name: 'John', age: 30})

// 올바른 업데이트 방식 - 새로운 객체 생성
setUser(prev => ({...prev, age: 31}))

// 잘못된 업데이트 방식 - 기존 객체 변경
user.age = 31 
setUser(user)
```


**명시적 의존성 관리**


useEffect 문서에서는 "모든 의존성을 명시적으로 선언하라"고 권장한다. 이는 개발자가 어떤 값이 변경될 때 Effect가 실행되는지 명확히 알 수 있게 하기 위함으로 보인다.


### 메모리와 가비지 컬렉션 관점


깊은 비교는 메모리 사용량에도 영향을 미친다.


```javascript
// 깊은 비교 시 발생하는 문제들
function deepCompare(obj1, obj2, visited = new WeakSet()) {
  // 순환 참조 체크를 위한 추가 메모리 필요
  if (visited.has(obj1)) return obj1 === obj2

  visited.add(obj1)  // WeakSet에 객체 추가

  // 재귀 호출로 인한 콜 스택 증가
  // 큰 객체의 경우 스택 오버플로우 위험
}
```


React 애플리케이션에서는 컴포넌트 트리가 깊고 state가 복잡할 수 있기 때문에, 매 렌더링마다 깊은 비교를 수행하면 가비지 컬렉션 압박이 증가한다.


### React 팀의 실제 구현 선택


React 소스코드를 살펴보면 일관되게 shallow comparison을 사용한다.


```javascript
// packages/shared/shallowEqual.js (React 소스코드)
function shallowEqual(objA, objB) {
  if (is(objA, objB)) return true

  // 타입 체크 후 1 depth만 비교
  for (let i = 0; i < keysA.length; i++) {
    if (!is(objA[currentKey], objB[currentKey])) {
      return false  // 깊이 들어가지 않고 즉시 false
    }
  }
  return true
}

// packages/react-reconciler/src/ReactFiberClassComponent.js
// PureComponent도 shallowEqual 사용
return !shallowEqual(oldProps, newProps) || !shallowEqual(oldState, newState)
```


### 왜 이것이 더 나은 선택인가


React의 shallow comparison 선택은 무엇보다 일관된 성능을 보장한다. 객체의 복잡성에 관계없이 O(n) 시간 복잡도를 유지하는데, 여기서 n은 객체의 첫 번째 레벨에 있는 속성의 개수를 의미한다.


```javascript
const obj1 = {
  name: 'Kim',    // 1 depth 속성 1
  age: 30         // 1 depth 속성 2
}

const obj2 = {
  name: 'Kim',    // 1 depth 속성 1
  profile: {      // 1 depth 속성 2 (내용이 아무리 복잡해도)
    personal: {
      address: { city: 'Seoul', district: 'Gangnam', street: '...' },
      contacts: { phone: '...', email: '...', sns: [...] }
    },
    work: {
      company: '...',
      projects: [/* 수백 개의 프로젝트 */]
    }
  }
}

// shallow comparison에서는 둘 다 동일하게 2번의 비교만 수행
```


`obj1`이든 `obj2`든 shallow comparison은 항상 2번의 비교만 수행한다. `profile` 객체 안에 얼마나 복잡한 중첩 구조가 있든 상관없이 `profile` 참조 자체만 비교하기 때문이다. 반면 deep comparison이었다면 중첩된 모든 속성을 순회한다.


이렇게 함으로써 개발자가 변경 사항을 명시적으로 표현하도록 유도한다. 객체 내부의 값을 변경하고 싶다면 반드시 새로운 객체를 만들어야 한다. `setUser({...user, age: 31})`처럼 새 객체를 만드는 것을 보면 "age가 변경되었다"는 의도가 즉시 드러난다.


디버깅 관점에서도 참조가 바뀌면 확실히 무언가 변경된 것이므로 문제를 추적하기 쉽다. 깊은 비교에서는 거대한 객체 구조에서 정확히 어느 부분이 변경되었는지 찾아내기 어렵다. shallow comparison에서는 참조 변경 자체가 신호가 될 수 있다.


```javascript
// 디버깅이 쉬운 경우
const prevState = state
const nextState = {...state, count: state.count + 1}
console.log('참조가 변했나?', prevState !== nextState)  // true
console.log('무엇이 변했나?', 'count가 변경됨')

// 디버깅이 어려운 경우 (deep mutation)
state.nested.deep.property.count += 1
console.log('참조가 변했나?', prevState !== state)  // false - 하지만 실제로는 변경됨
// 어느 부분이 변경되었는지 찾기 어려움
```


이런 설계 철학은 React 생태계 전반에 영향을 미쳤다. Immutable.js나 Immer 같은 불변성 도우미 라이브러리들이 발달한 것도 이런 맥락에서다. Redux의 상태 관리 철학, 함수형 프로그래밍의 확산, 심지어 최근의 상태 관리 라이브러리들까지 모두 불변성을 기반으로 한다. 결과적으로 React의 shallow comparison 선택은 성능상의 이유를 넘어 더 견고하고 예측 가능한 아키텍처를 만들어내는 역할을 했다.


## references

- [useEffect](https://react.dev/reference/react/useEffect)
- [React.memo](https://react.dev/reference/react/memo)
- [useMemo](https://react.dev/reference/react/useMemo)
- [useCallback](https://react.dev/reference/react/useCallback)
- [objectIs.js](https://github.com/facebook/react/blob/main/packages/shared/objectIs.js)
- [shallowEqual.js](https://github.com/facebook/react/blob/main/packages/shared/shallowEqual.js)
- [Object.is() - MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is)
- [JavaScript 메모리 관리 - MDN](https://developer.mozilla.org/ko/docs/Web/JavaScript/Memory_Management)


왜 React는 객체 비교에 민감할까

Symmetric key(대칭키) 암호화

## 📡 OpenFlow

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-05-31_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_10.16.42.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236228899-0)

SDN(Software-Defined Networking)은 네트워크 제어를 중앙에서 통합적으로 수행하는 구조다. 각 스위치는 단순히 패킷을 전달하고, 네트워크 전체를 어떻게 구성하고 제어할지는 하나의 중앙 컨트롤러가 결정한다. 이렇게 제어 평면과 데이터 평면을 분리한 구조는 유연하고 강력하지만, 여기서 한 가지 중요한 의문이 생긴다.

컨트롤러는 스위치에게 어떤 방식으로 명령을 전달할까? 예를 들어, ‘이런 조건의 패킷은 포트 3번으로 보내라’는 지시를 실제로 어떻게 전달하는 걸까?

바로 이 역할을 수행하는 것이 OpenFlow다. OpenFlow는 SDN 구조 안에서 컨트롤러와 스위치 사이의 통신을 담당하는 대표적인 프로토콜로, 컨트롤러가 계산한 포워딩 정책이나 트래픽 제어 명령을 스위치에 전달할 때 사용한다. 이 통신은 TCP 위에서 이루어져 필요에 따라 암호화도 적용할 수 있다.

OpenFlow는 하나의 명령어 묶음이 아니라, 컨트롤러가 네트워크 장비를 직접 제어할 수 있게 만들어주는 공식적인 언어라고 볼 수 있다. 스위치는 이 언어로 전달된 지시에 따라 내부 플로우 테이블을 수정하거나, 처리할 수 없는 패킷을 컨트롤러에게 다시 보내기도 한다.

이 글에서는 OpenFlow가 어떤 메시지들을 주고받으며, 실제로 컨트롤러와 스위치가 어떻게 협력하는지 하나씩 살펴본다. 이를 통해 SDN이라는 개념이 실제 네트워크에서 어떤 방식으로 구현되는지를 구체적으로 이해할 수 있을 것이다.

### controller-to-switch 메시지

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-05-29_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_12.33.12.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236231986-1)

controller-to-switch 메시지는 컨트롤러가 스위치의 동작을 직접 제어하거나 정보를 요청할 때 사용한다. 이 메시지 유형에는 여러 가지가 있다.

- `features` 컨트롤러가 스위치의 기능을 조회할 때 사용된다. 컨트롤러가 쿼리를 보내면, 스위치는 자신이 지원하는 기능을 응답으로 알려준다.
- `configure` 컨트롤러가 스위치의 구성 파라미터를 조회하거나 설정할 때 사용된다. 스위치의 동작 방식을 제어하거나 제한할 수 있다.
- `modify-state` 컨트롤러는 스위치의 OpenFlow 테이블에 있는 플로우 항목을 추가, 삭제, 수정할 수 있다. 네트워크의 라우팅 경로를 동적으로 조정하거나 특정 트래픽에 대한 제어 정책을 적용할 수 있다.
- `packet-out` 컨트롤러가 특정 패킷을 스위치의 특정 포트를 통해 외부로 직접 전송하도록 지시할 때 사용된다. 일반적으로 스위치가 처리하지 못한 패킷을 컨트롤러가 수신한 후, 컨트롤러가 그에 대한 응답으로 패킷의 전송 경로를 명시할 때 활용된다.

### switch-to-controller 메시지

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-05-29_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_12.34.07.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236234615-2)

OpenFlow에서 switch-to-controller 메시지는 스위치가 네트워크 상의 변화나 특정 이벤트를 컨트롤러에게 알릴 때 사용된다. 비동기적으로 전달된다. 컨트롤러가 네트워크 상태를 실시간으로 파악하고 적절한 제어 결정을 내린다.

- `packet-in` 스위치가 처리할 수 없는 패킷을 컨트롤러에게 전달할 때 사용된다. 이 메시지를 통해 패킷 자체와 함께 그에 대한 제어 권한도 컨트롤러로 넘어가며, 이후 컨트롤러는 packet-out 메시지를 통해 해당 패킷의 처리 경로를 지시할 수 있다.
- `flow-removed` 스위치 내 플로우 테이블에 등록된 항목이 삭제되었을 때 이를 컨트롤러에 알리는 역할을 한다. 이 기능은 플로우의 수명이나 정책 변화 등을 추적하는 데 유용하다.
- `port status` 스위치 포트의 상태 변화(예: 포트 연결 또는 해제, 오류 발생 등)를 컨트롤러에게 통지한다. 이를 통해 컨트롤러는 물리적 링크 상태를 포함한 네트워크 토폴로지의 변화를 감지하고, 필요한 경우 트래픽 경로를 재조정할 수 있다.

다행히도, 네트워크 운영자가 이러한 OpenFlow 메시지를 일일이 수작업으로 작성하고 전송해야 하는 것은 아니다. 실제 운영 환경에서는 컨트롤러가 제공하는 상위 수준의 추상화 계층과 API를 통해 메시지가 자동 생성되고 전달된다. 이러한 구조 덕분에 운영자는 효율적으로 네트워크를 제어할 수 있고, OpenFlow의 세부 구현에 대해 깊이 이해하지 않아도 된다.

### SDN Control Plane, Data Plane 상호작용 예시

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-01_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_2.40.44.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236237516-3)

SDN에서 control plane과 data plane이 상호작용하는 과정을 예시를 통해 살펴보면, 전통적인 링크 상태 라우팅 방식과 유사하지만 훨씬 더 유연하게 작동함을 알 수 있다.

(1) 네트워크 내에서 스위치 S1이 링크 장애를 감지하면, OpenFlow의 `port status` 메시지를 사용해 컨트롤러에게 해당 사실을 통지한다. 이 메시지는 data plane에서 control plane으로 전달되는 첫 단계다.

(2, 3) 컨트롤러는 이 메시지를 수신하고, 내부적으로 관리하고 있는 링크 상태 정보를 갱신한다. 이때, 컨트롤러는 링크 상태나 토폴로지의 변화가 있을 경우 감지하고 반응할 수 있도록 사전에 등록된 애플리케이션을 호출할 수 있다. 예를 들어, Dijkstra 라우팅 알고리즘이 등록되어 있다면, 링크 상태 변화 이벤트가 발생할 때 자동으로 호출된다.

(4) 호출된 라우팅 애플리케이션은 컨트롤러 내부에서 유지되는 네트워크 그래프, 링크 상태 정보, 스위치 및 호스트 정보 등을 활용해 새로운 라우팅 경로를 계산한다. 이후 이 경로 정보에 따라 필요한 플로우 테이블이 다시 계산되고, OpenFlow 프로토콜을 통해 해당 스위치들에 반영된다. 이 전 과정은 RESTful API, 그래프 추상화, 통계 및 상태 정보와 같은 고수준 추상화를 통해 이루어지고 운영자는 전체 흐름을 명확하게 설계하고 통제할 수 있다.

![0d5259ce-9eec-497d-bc3a-9ddf14fcfb65.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236240687-4)

(5) 링크 상태 라우팅 애플리케이션은 SDN 컨트롤러 내의 플로우 테이블 계산 컴포넌트와 상호작용하게 된다. 이 컴포넌트는 갱신된 네트워크 상태 정보를 바탕으로 새로운 라우팅 경로를 계산하고, 그에 따라 각 스위치가 필요로 하는 플로우 테이블 항목을 다시 생성한다. 이때 라우팅 알고리즘은 전체 네트워크의 토폴로지를 전역적으로 파악할 수 있기 때문에, 장애 이후에도 최적화된 경로를 빠르게 재설정할 수 있다.

(6) 새롭게 계산된 플로우 테이블 정보는 이후 컨트롤러가 OpenFlow 프로토콜을 사용해 각 스위치에 전송한다. 이 과정을 통해 영향을 받은 스위치들은 기존의 경로 정보를 갱신하게 되고, 새로운 경로에 따라 패킷을 전달하게 된다.

### OpenDaylight (ODL)

> 모듈형 설계 + 다양한 프로토콜 지원 = 유연한 플랫폼

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-01_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_2.53.25.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236243862-5)

OpenDaylight(ODL) 컨트롤러는 모듈화된 아키텍처를 기반으로 다양한 네트워크 제어 기능과 서비스를 유연하게 지원하는 오픈소스 SDN 플랫폼이다. 가장 상위에는 트래픽 엔지니어링, 방화벽, 부하 분산 등과 같은 네트워크 오케스트레이션 기능 및 응용 애플리케이션이 위치하고 이들은 Northbound API를 통해 ODL 컨트롤러와 통신한다. 이 API 계층에서는 REST, RESTCONF, NETCONF와 같은 표준 인터페이스가 사용되어 외부 애플리케이션이 컨트롤러 내부의 데이터 및 기능에 접근할 수 있도록 한다.

그 아래에는 AAA(인증, 인가, 계정관리)와 같은 향상된 서비스와 함께 기본적인 네트워크 기능들이 구성된다. 이 기능 모듈에는 네트워크 토폴로지를 처리하는 모듈, 스위치 관리 모듈, 통계 정보 관리 모듈, 포워딩 룰 관리, 호스트 추적 모듈 등이 포함되어 있고 구성 데이터와 운영 데이터 저장소와도 연결된다. 이 계층은 네트워크의 상태를 파악하고 필요한 조치를 결정하는 중추적인 역할을 수행한다.

이 모든 기능들은 Service Abstraction Layer(SAL)을 통해 서로 연결된다. SAL은 내부와 외부의 다양한 애플리케이션 및 서비스 모듈들 간의 연결을 중개하는 계층으로, 모듈 간의 독립성과 재사용성을 높여준다. SAL은 특히 Southbound API와도 연결되는데, 이 하위 계층에서는 OpenFlow, NETCONF, SNMP, OVSDB 등의 프로토콜을 이용해 실제 네트워크 장비와 직접 통신이 이루어진다.

### ONOS

> 대규모 분산 네트워크에 적합한 컨트롤러

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-01_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_2.53.34.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236246424-6)

ONOS(Open Network Operating System) 컨트롤러는 고신뢰성과 확장성을 중심으로 설계된 SDN 플랫폼으로 대규모 네트워크 인프라에서의 안정적인 제어를 목표로 한다. ONOS 아키텍처의 특징 중 하나는 제어 애플리케이션이 컨트롤러와 분리되어 있다는 점이다. 라우팅, 방화벽, 트래픽 엔지니어링, 부하 분산 등의 네트워크 애플리케이션은 ONOS의 외부에서 동작하면서 Northbound API를 통해 컨트롤러와 통신한다.

ONOS는 Intent Framework를 통해 고수준의 서비스 명세 방식을 지원한다. 이 프레임워크는 “어떻게(how)”보다 “무엇을(what)” 중심으로 서비스를 정의할 수 있게 해준다. 예를 들어 운영자는 특정 두 호스트 간 연결을 요청하기만 하면 ONOS가 그 구현 방법을 자동으로 결정해준다. 네트워크 제어를 직관적이고 정책 중심의 네트워크 운용을 가능하게 한다.

내부적으로 ONOS는 분산 코어에 많은 비중을 두고 있고 서비스의 신뢰성, 상태 복제, 성능, 확장성 등을 보장하기 위한 기반이다. 코어는 다양한 상태 정보를 관리하는 모듈들(예: 디바이스, 링크, 호스트, 플로우, 패킷 등)로 구성되어 있으며, 이 정보는 애플리케이션이 필요한 제어 결정을 내리는 데 활용된다.

Southbound API 계층에서는 OpenFlow, Netconf, OVSDB 등의 프로토콜을 통해 실제 네트워크 장비와 상호작용한다. 이 계층도 추상화되어 있어서, 다양한 장비와 기술을 통합적으로 관리할 수 있도록 설계되어 있다. 전체적으로 ONOS는 구조적으로 견고하고 추상화 수준이 높다.


SDN 안에서의 OpenFlow 역할과 동작 방식

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_1.37.14.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/network-security/image-1753236567044-0)

네트워크 보안은 인터넷이나 기타 네트워크를 통해 데이터를 주고받는 과정에서 발생할 수 있는 다양한 위협으로부터 정보를 보호하고, 통신 당사자 간의 신뢰를 보장하는 것을 목표로 한다. 이를 위해 네트워크 보안은 네 가지 요소로 구성된다.

첫 번째 요소는 기밀성(confidentiality)이다. 기밀성은 오직 송신자와 수신자만이 메시지의 내용을 이해할 수 있어야 한다는 원칙이다. 이를 위해 일반적으로 송신자는 메시지를 암호화하고, 수신자는 이를 복호화한다. 제3자가 메시지를 가로채더라도 그 내용을 이해하지 못하도록 막는다.

두 번째는 인증(authentication)이다. 인증은 네트워크 통신에서 통신하는 상대방의 신원을 확인하는 과정이다. 예를 들어 내가 정말 은행과 통신하고 있는지, 아니면 누군가가 은행인 척 하고 있는지를 확인하는 것이 인증이다. 인증을 통해 스푸핑(spoofing)이나 중간자 공격(man-in-the-middle attack) 같은 위협을 방지할 수 있다. 주로 암호학적 서명, 키 기반 프로토콜, 인증 서버 등을 이용해 구현된다.

세 번째는 무결성(integrity)이다.

무결성은 메시지가 전송 도중이나 저장 중에 변경되지 않았음을 확인하는 원칙이다. 메시지가 중간에 조금이라도 바뀌었다면, 수신자는 이를 알아차릴 수 있어야 한다. 이를 위해 보통 해시 함수(hash function)나 메시지 인증 코드(MAC) 등을 사용한다. 이런 기법을 통해 메시지의 변조 여부를 검증할 수 있다.

마지막으로는 가용성(availability)이다. 가용성은 네트워크 서비스가 인증된 사용자에게 항상 접근 가능하고 안정적으로 동작해야 한다는 원칙이다. 만약 서버가 마비되거나, 네트워크가 과부하되어 서비스를 사용할 수 없다면 가용성이 침해된 것이다. 대표적인 위협으로는 서비스 거부 공격(DDoS)이 있으며, 이런 공격은 네트워크 자원을 고의로 소모시켜 정상 사용자가 접근하지 못하게 만든다.

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_1.37.24.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/network-security/image-1753236569499-1)

네트워크 보안 분야에서 자주 사용되는 가상의 인물들이 있다. 대표적으로 Alice와 Bob, 그리고 Trudy다. 두 사람의 신뢰를 바탕으로 비밀스럽게 소통하고 싶어한다는 상황을 드러내기 위해 연인 관계로 설정하기도 한다.

Alice는 일반적으로 송신자(sender) 역할을, Bob은 수신자(receiver) 역할을 한다. 서로 주고받는 메시지는 기밀성, 무결성, 인증과 같은 보안이 충족되길 원한다. 예를 들어,

- Alice는 오직 Bob만 메시지를 읽을 수 있길 바란다. (기밀성)
- Bob은 그 메시지가 변조되지 않았고, 정말 Alice가 보낸 것임을 알고 싶어 한다. (무결성, 인증)

하지만 항상 평화로운 상황만 있는 것은 아니다. 여기에 등장하는 제3의 인물 Trudy는 공격자(intruder) 또는 도청자, 침입자 역할을 하고, 여러 악의적 행위를 시도할 수 있다.

- 메시지를 가로채거나 도청(intercept)
- 메시지를 삭제(delete)
- 위조된 메시지를 추가하거나 변경(add/modify)

Trudy는 이러한 행위를 통해 통신을 방해하거나 속이고, 민감한 정보를 탈취하거나 통신 내용을 왜곡할 수 있다. 따라서 Alice와 Bob은 통신을 보호하기 위해 암호화, 인증, 무결성 체크 등 다양한 보안 기법을 적용해야 한다.

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_1.37.39.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/network-security/image-1753236572094-2)

네트워크에는 단순한 행동을 넘는 적극적인 공격자들이 존재한다. 통신을 조작하거나 시스템을 마비시키는 등 직접 개입하는 다양한 행위를 시도한다.

가장 대표적인 수동적 공격은 도청(eavesdropping)이다. 네트워크를 통해 흐르는 메시지를 몰래 가로채는 것으로, 민감한 정보가 암호화되지 않은 경우 쉽게 탈취당할 수 있다.

도청보다 더 위협적인 것은 **능동적 공격**이다. 공격자는 다음과 같은 방식으로 통신을 조작한다.

- 메시지 변조/삽입: 기존 메시지를 바꾸거나, 허위 메시지를 추가해 통신 내용을 왜곡한다. 예를 들어 결제 정보를 조작하면 실제 자금이 탈취될 수 있다.
- 스푸핑(Spoofing): 출발지 주소를 위조해 다른 사용자로 가장한다. 인증이 제대로 이루어지지 않으면, 신뢰 관계가 무너진다.
- 세션 하이재킹(Session Hijacking): 진행 중인 통신 세션에 침입해 정상 사용자를 배제하고 공격자가 그 자리를 차지한다. 사용자는 자신도 모르게 조작된 결과를 받게 된다.

가용성을 무너뜨리는 대표적인 공격은 서비스 거부 공격(DoS)이다. 네트워크나 서버에 **과도**한 요청을 보내 시스템을 마비시켜 정상 사용자가 서비스를 이용하지 못하게 만든다.


네트워크 보안이란

IPSec

## 📡 디지털 서명이란

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.34.15.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236434433-0)

디지털 서명(digital signature)은 손으로 직접 서명을 하는 것처럼, 문서의 작성자와 진위를 증명할 수 있게 해주는 암호 기술이다. 서명을 통해 ‘이 문서는 내가 작성한 것이고, 그 내용은 바뀌지 않았다’는 사실을 수학적으로 보장할 수 있다.

위 디지털 서명의 예시를 들어보자. Bob이 Alice에게 편지를 보내며 ‘내가 진짜 보낸 편지’라는 것을 증명하고 싶다고 하자. Bob은 이 편지의 내용을 자신의 개인키(private key)를 사용해 암호화한다. 이렇게 하면 그 누구도 (Alice조차도) 이 서명된 내용을 위조하거나 조작할 수 없다. 왜냐하면, Bob의 개인키는 오직 그만 가지고 있기 때문이다.

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.34.23.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236437503-1)

Alice는 이 서명된 편지를 받으면, Bob의 공개키(public key)를 이용해 복호화할 수 있다. 복호화 결과가 원래의 편지 내용과 일치하면, 다음 두 가지 사실을 동시에 확인할 수 있다.

1. 이 편지는 반드시 Bob이 서명한 것이다.
   - Bob의 공개키로 복호화가 가능하다는 것은 개인키로 암호화했다는 뜻이다.
2. 편지 내용이 바뀌지 않았다.
   - 서명된 데이터가 조금이라도 바뀌었으면 복호화가 깨졌을 것이다.

이 구조 덕분에 디지털 서명은 위조 방지(non-forgeability)와 부인 방지(non-repudiation)의 기능을 동시에 제공한다. Alice는 제3자에게 ‘이 메시지는 확실히 Bob이 보낸 것이다’라고 증명할 수 있다. 그리고 Bob은 ‘나는 그런 메시지 보낸 적 없다’고 주장할 수 없다.

## 📡 메시지 다이제스트

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.34.30.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236440009-2)

디지털 서명을 적용할 때 이런 문제를 마주하게 된다.

> 긴 메시지를 그대로 개인키로 암호화하려면 너무 많은 계산이 필요하다.
>
> 그럼에도 메시지의 진위와 무결성을 어떻게 효율적으로 확인할 수 있을까?

이 문제를 해결해주는 것이 바로 메시지 다이제스트(message digest)다. 메시지 다이제스트는 원래의 긴 메시지를 고정된 길이의 짧은 값으로 요약하는 방식이다. 이를 위해 해시 함수(hash function)라는 수학적 함수를 사용한다.

해시 함수는 어떤 크기의 입력이 들어와도 항상 일정한 크기의 출력을 생성한다. 이 출력값은 흔히 디지털 지문(fingerprint)이라고 불리고 메시지를 대표하는 고유한 값처럼 사용된다. 예를 들어 수백 줄의 이메일 본문을 입력으로 넣어도, 해시 함수는 그 내용을 압축해서 단 몇 바이트 길이의 다이제스트를 만들어준다.

이 다이제스트는 다음과 같은 성질을 갖는다.

- 길이가 고정되어있다. 입력 길이에 관계없이 출력은 일정하다. (예: SHA-1은 160비트)
- 많은 입력, 같은 출력(many-to-one). 무한한 입력 공간을 유한한 출력에 맵핑하기 때문에, 서로 다른 메시지가 같은 해시 값을 가질 수도 있다. 하지만 이건 설계상 허용되며, 중요한 건…
- 역으로 찾기 어렵다. 어떤 해시 값 $x$가 주어졌을 때, 이를 만들어내는 입력 $m$을 찾는 건 계산적으로 불가능에 가깝다. 이것이 해시 함수의 핵심 보안 성질이다.

이러한 성질 덕분에 해시 함수는 디지털 서명과 결합되어 사용된다. 실제 서명 과정에서는 메시지 전체가 아닌, 해시 함수로 요약한 다이제스트에만 서명을 한다. 그 결과 서명은 빠르고 간결하면서도 메시지 전체의 무결성을 검증할 수 있게 된다.

### 작동 예시

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.35.33.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236442069-3)

실제 구현에서는 전체 메시지가 아니라, 그 메시지의 요약 값(hash)에 대해 서명을 한다. 이 구조를 사용하면 성능은 빠르면서도 무결성과 인증을 동시에 보장할 수 있다.

예를 들어 Bob이 Alice에게 메시지 m을 보내며 디지털 서명을 추가한다고 하자. 이때 전체 과정은 다음과 같이 이뤄진다.

<u>서명 생성: Bob → Alice</u>

- Bob은 먼저 메시지 $m$에 대해 해시 함수를 적용해 메시지 다이제스트 $H(m)$를 계산한다. 이 다이제스트는 메시지를 요약한 고정 길이의 값이다.
- 이어서, 이 $H(m)$을 자신의 개인키 $K_B^-$로 암호화한다. 이 암호화된 다이제스트가 곧 디지털 서명이다.
- Bob은 이제 두 가지를 Alice에게 전송한다.
  - 원본 메시지 $m$
  - 디지털 서명 $K_B^-(H(m))$

<u>서명 검증: Alice</u>

- Alice가 이 메시지를 받으면, 다음과 같은 과정을 통해 서명이 유효한지 확인할 수 있다.
  - Alice는 메시지 $m$에 똑같은 해시 함수를 적용해 자신만의 $H(m)$을 만든다.
  - 동시에 Bob이 보낸 디지털 서명을 Bob의 공개키 ${K_B}^+$를 사용해 복호화한다.
    - 이 결과는 Bob이 실제로 서명할 때 사용한 $H(m)$이어야 한다.
  - 마지막으로 두 개의 다이제스트를 비교한다.
    - Alice가 직접 계산한 $H(m)$
    - 서명으로부터 복호화한 $H(m)$
- 이 둘이 일치한다면, Alice는 다음 두 가지를 확신할 수 있다.
  - 이 메시지는 Bob이 보낸 것이고 제3자가 위조한 것이 아니다.
  - 메시지 내용은 전송 중에 변경되지 않았다.

## 📡 암호에는 부적절한 인터넷 체크섬

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.35.25.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236444978-4)

## 📡 실제로 사용되는 해시 함수들

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.35.41.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236447404-5)

위에서 봤듯이 디지털 서명과 메시지 무결성 검증에는 반드시 **해시 함수**가 필요하다. 하지만 해시 함수는 단지 ‘있으면 되는 도구’가 아니다. 충분히 안전하고, 빠르며, 충돌 가능성이 낮아야 실전에서 쓸 수 있다. 지금까지 널리 사용된 대표적인 해시 함수로는 MD5와 SHA-1이 있다.

### MD5

MD5(Message Digest 5)는 1991년, 로널드 리베스트(Ron Rivest)가 설계한 해시 함수로 RFC 1321에 표준으로 정의되어 있다. 이 알고리즘은 어떤 크기의 입력 메시지가 들어와도 **128비트의 고정된 해시 값**을 만들어낸다. 내부적으로는 4단계 과정을 거쳐 입력을 압축하고, 최종 요약값을 계산한다.

MD5는 오랜 기간 동안 암호화 검증, 파일 무결성 체크, 디지털 서명 등에 널리 사용되었다. 특히 계산이 매우 빠르다는 장점이 있어 시스템 전반에 많이 채택되었지만, 시간이 지나면서 보안 취약점이 드러났다.

2000년대 중반 이후에는 서로 다른 두 입력이 같은 해시 값을 갖는 ’충돌(collisions)’을 비교적 쉽게 찾을 수 있음이 밝혀졌고, 그 이후 보안 분야에서는 더 이상 안전한 해시 함수로 간주되지 않는다.

### **SHA-1**

SHA-1(Secure Hash Algorithm 1)은 미국 NIST(국립표준기술연구소)에서 표준으로 채택한 해시 함수로, 160비트의 메시지 다이제스트를 생성한다. MD5보다 출력이 길기 때문에 이론상 충돌 가능성이 더 낮으며, 한동안 보안적으로 더 안전한 대안으로 여겨졌다.

하지만 SHA-1 역시 2010년대 중반 이후 이론적 충돌 공격이 가능하다는 연구 결과가 발표되었고, 2017년에는 실제 충돌을 만들어내는 사례(SHAttered attack)도 등장했다. 그 결과 현재는 대부분의 보안 프로토콜이 SHA-1 사용을 중단하고, SHA-256이나 SHA-3 같은 더 강력한 해시 함수로 전환하고 있다.

## 📡 공개키 인증 방식은 안전할까?

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.35.49.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236449176-6)

공개키 암호화는 인증과 보안 통신에서 매우 강력한 도구다. 그래서 ap5.0 프로토콜에서는 다음과 같은 방식으로 인증을 시도한다.

1. Alice는 Bob에게 ‘나는 Alice야’라고 주장하며 공개키 기반 인증을 시작한다.
2. Bob은 Alice에게 난수 $R$을 보내고, 이것을 Alice의 비밀키로 암호화해 되돌려 달라고 한다.
3. 암호문을 Bob이 Alice의 공개키로 복호화했을 때 $R$과 일치한다면, 그 상대방은 Alice라고 확신할 수 있다.

이론상 아주 깔끔한 방식처럼 보이지만, 여기에 **치명적인 허점**이 있다.

### **ap5.0의 실패 시나리오, Trudy의 공격**

공격자인 Trudy는 다음과 같은 방식으로 공격을 수행할 수 있다.

1. Bob에게 접근해 ‘나는 Alice야’라고 주장한다.
2. Bob이 Trudy에게 공개키를 달라고 요청하자, Trudy는 자신의 공개키를 보내지만 그것이 Alice의 것처럼 속인다.
3. Bob은 이 키가 진짜 Alice의 것이라고 믿고, 거기에 난수 $R$을 보내 암호화된 응답을 기대한다.
4. Trudy는 자신의 비밀키로 $R$을 암호화해 다시 Bob에게 보낸다.
5. Bob은 그 암호문을 Trudy가 준 공개키로 복호화하므로, 결과적으로 R이 제대로 복호화된다고 착각하고 Trudy를 Alice로 신뢰하게 된다.

이 시점에서 Bob은 Trudy를 Alice로 완전히 잘못 인증하고, 이후 개인적인 메시지 $m$를 암호화해 보내게 된다.

Trudy는 이 메시지를 쉽게 복호화할 수 있다. 왜냐하면 메시지는 Trudy가 넘긴 공개키로 암호화되었고, Trudy는 그에 해당하는 비밀키를 가지고 있기 때문이다. 게다가 Trudy는 이 메시지를 다시 Alice의 공개키로 재암호화해서 전달할 수도 있다. 결과적으로 Alice와 Bob은 서로 안전하게 통신했다고 믿지만, 그 사이에서 Trudy는 모든 내용을 엿볼 수 있게 된다.

### **문제점**

이 시나리오의 가장 큰 문제는 다음 한 줄로 요약할 수 있다.

> Bob은 Trudy가 보내온 공개키가 진짜 Alice의 것인지 검증하지 않았다.

즉, 공개키 자체는 안전하더라도, **그 키가 실제 Alice에게 속하는지 확인하지 않으면 전체 인증 체계가 무너질 수 있다.** 이를 해결하려면 공개키와 사용자의 신원을 묶어주는 **공인 인증서(Certificate Authority)** 시스템이 필요하다.


Digital Signature (디지털 서명)

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.25.40.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/crpytography/image-1753236561617-0)

암호학(cryptography)은 평문(plaintext), 암호문(ciphertext), 그리고 키(key)를 중심으로 구성된다. 통신에서 Alice는 메시지를 안전하게 Bob에게 전달하고 싶어 한다. 이를 위해 Alice는 메시지를 암호화하고, Bob은 이를 복호화해서 원래의 내용을 읽는다.

Alice는 먼저 전달하려는 평문 메시지 $m$을 가지고, 자신의 암호화 키 $K_A$를 사용해 암호화한다. 이 과정을 통해 $K_A(m)$이라는 암호문(ciphertext)이 생성된다. 암호화는 평문을 외부에서 알아볼 수 없는 형태로 바꾸는 과정으로, 네트워크 상에서 중간에 누군가 메시지를 가로채더라도 내용을 파악하지 못하게 한다.

이 암호문은 Bob에게 전달된다. Bob은 자신의 복호화 키 $K_B$를 사용해 이 암호문을 복호화한다. 복호화는 암호화를 역으로 수행하는 과정이고, 아래 식으로 표현할 수 있다.

$$
m = K_B(K_A(m))
$$

즉, Bob이 자신의 키로 Alice의 암호문을 복원하면 원래 메시지 $m$이 다시 나타난다.

실제로는 $K_A$가 Alice의 공개키, $K_B$가 Bob의 개인키일 수도 있다. 대칭키 암호에서는 $K_A$와 $K_B$가 동일한 키를 공유하는 경우도 있다.

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.25.54.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/crpytography/image-1753236563968-1)

암호화 시스템도 완전히 안전하지는 않다. 만약 공격자인 Trudy가 시스템을 공격하려고 한다면, 사용 가능한 정보에 따라 다양한 방법을 시도할 수 있다.

첫 번째는 암호문만을 가지고 시도하는 공격(ciphertext-only attack)이다. 이 경우 Trudy는 평문은 전혀 모르고, 오직 암호화된 메시지(=ciphertext)만 가지고 분석해야 한다. 이 상황에서는 두 가지 주요 전략이 존재한다.

- 하나는 무차별 대입(brute force) 방식으로, 가능한 모든 키를 하나씩 대입해 복호화를 시도하고, 그중 자연스러운 결과가 나오는 키를 찾아내는 방식이다. 키 공간이 충분히 클 경우 시간과 자원이 매우 많이 들기 때문에 실용적인 키 크기를 사용하는 것이 중요하다.
- 다른 하나는 통계적 분석(statistical analysis)이다. 예를 들어 어떤 글자가 더 자주 나오는지를 분석해서 암호문 속 규칙을 추론하려는 시도다. 단순한 암호일수록 성공 확률이 높다.

두 번째는 알고 있는 평문을 기반으로 한 공격(known-plaintext attack)이다. 여기서 Trudy는 어떤 암호문이 어떤 평문에 대응되는지를 일부 알고 있다. 예를 들어, Trudy가 "alicebob"이라는 평문과 그에 대응하는 암호문을 알고 있다면, 특히 암호 체계가 단순하다면(ex, 단일 치환 암호) 각 알파벳이 어떻게 암호화되는지를 비교적 쉽게 유추할 수 있다.

세 번째는 선택 평문 공격(chosen-plaintext attack)이다. Trudy가 자신이 선택한 평문을 암호화해서 대응하는 암호문을 얻을 수 있는 상황을 의미한다. 이 경우 암호화 함수의 구조나 키에 대한 정보를 유추해내기가 상대적으로 쉬워진다. 특히 블록 암호나 대칭키 시스템에서는 주의가 필요하다.


cryptography 기본 용어 정리

## 📡 라우팅을 거대하게

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_9.48.16.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/inter-as-inter-as/image-1753236592459-0)

지금까지 살펴본 라우팅은 이상적인 가정을 바탕으로 설명된 것이었다. 모든 라우터가 동일하게 동작하고, 네트워크가 평평하게(flat) 구성되어 있다고 가정했지만 실제 인터넷 환경은 이와 다르다.

현실에서는 전 세계적으로 수십억 개의 목적지가 존재한다. 이 규모에서는 각 라우터가 모든 목적지를 라우팅 테이블에 저장할 수 없다. 뿐만 아니라, 이 테이블을 주기적으로 교환하게 되면 네트워크 링크 자체가 그 정보 전달만으로도 과부하에 빠질 수 있다.

또한 실제 인터넷은 단일 네트워크가 아니라 수많은 네트워크가 연결된 구조이고 각 네트워크는 독립적인 관리 주체 아래 운영된다. 이런 관리적 자율성(administrative autonomy) 때문에 각 네트워크는 자체 내부의 라우팅 방식을 설정하고 통제하고자 할 수 있다. 결국 이러한 요구와 제약을 충족하기 위해 라우팅 시스템은 규모에 맞게 설계되어야 하고 계층적 구조와 자율 시스템 개념이 필요하게 된다.

## 📡 계층적 네트워크

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_9.48.38.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/inter-as-inter-as/image-1753236596174-1)

인터넷에서는 라우팅의 확장성을 확보하기 위해 전체 네트워크를 하나의 평면 구조로 유지하지 않고, 자율 시스템(AS, Autonomous System)이라는 단위로 나누어 계층적으로 구성한다. 각 AS는 도메인(domain)이라고도 불린다. 일반적으로 하나의 ISP, 대기업 네트워크, 또는 대형 캠퍼스 네트워크와 같이 독립적으로 운영되는 네트워크 집합을 의미한다.

AS 내부에서의 라우팅은 intra-AS routing 또는 intra-domain routing이라고 부른다. 같은 AS 안에 있는 모든 라우터는 동일한 라우팅 프로토콜을 사용해야 한다. 대표적으로 OSPF, RIP, IS-IS가 여기에 해당한다. 반면 AS가 다르면 서로 다른 라우팅 프로토콜을 자유롭게 사용할 수 있다. 이 덕분에 각 네트워크는 자율적으로 내부 운영 방식을 선택할 수 있고, 관리 유연성이 확보된다.

AS의 경계에 위치한 라우터는 게이트웨이 라우터(gateway router)라 불린다. 이들은 자신의 AS에 속한 내부 라우터들과도 연결되어 있지만, 동시에 외부의 다른 AS에 속한 라우터와도 링크를 가지고 있다. 즉, AS 간의 경로 선택과 같은 외부 라우팅도 담당해야 한다.

AS 간의 라우팅은 inter-AS routing 또는 inter-domain routing이라 한다. 주로 게이트웨이 라우터들이 담당한다. 외부와의 경로 교환은 물론 내부 AS 내에서의 경로 결정도 함께 수행하게 된다. 이렇게 계층적이고 분할된 구조 덕분에 인터넷은 수십억 개의 목적지를 가진 거대한 네트워크임에도 불구하고 효율적이고 유연한 라우팅이 가능해진다.

## 📡 라우팅끼리의 협력

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_9.48.28.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/inter-as-inter-as/image-1753236598681-2)

intra-AS 라우팅과 inter-AS 라우팅은 각각 다른 목적지를 위해 동작하지만, 실제로는 서로 협력해 각 라우터의 포워딩 테이블을 완성한다.

Intra-AS 라우팅은 같은 AS 내부의 목적지로 가는 경로를 결정한다. 예를 들어, AS1에 속한 한 라우터가 동일한 AS1 내의 다른 호스트에게 데이터를 전달하려면 OSPF나 RIP 같은 내부 라우팅 프로토콜이 사용된다. 이때 라우팅 경로는 해당 AS의 정책과 네트워크 구조에 따라 자율적이고 독립적으로 결정된다. 따라서 같은 프로토콜을 사용하더라도 각 AS는 다른 라우팅 전략을 취할 수 있다.

Inter-AS 라우팅은 다른 자율 시스템에 속한 목적지로의 경로를 결정한다. 이때 사용되는 대표적인 프로토콜은 BGP(Border Gateway Protocol)이다. 하지만 BGP는 목적지 AS에 도달하기 위한 논리적 경로만 결정해 이 경로를 실제로 따라가기 위한 물리적인 전달 경로는 다시 내부 라우팅 프로토콜에 의해 계산된다.

즉, 외부 AS를 향하는 트래픽의 경우

- 어떤 외부 AS 경로를 선택할지는 BGP가 결정하고,
- 선택된 외부 경로까지 가는 실제 내부 경로는 intra-AS 라우팅 프로토콜이 다시 계산하는 구조다.

이렇게 두 계층이 분업해서 작동하기 때문에 외부 목적지에 대해서도 정확한 포워딩 테이블 항목이 생성될 수 있다.

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_9.48.50.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/inter-as-inter-as/image-1753236601390-3)

인터넷은 수많은 자율 시스템(AS)들이 서로 연결되어 구성된다. 이때 각 AS 내부에서 동작하는 라우터들은 단지 내부 목적지뿐 아니라, 외부 AS로 향하는 트래픽도 처리해야 한다. 특히 외부 목적지를 향하는 패킷을 처리할 때, AS 내부의 라우터가 어떤 경계 라우터(gateway router)를 통해 포워딩할지 결정하는 문제는 inter-AS 라우팅 정보에 의존하게 된다.

예를 들어 AS1 내부의 한 라우터가 도착지가 AS1 외부에 있는 데이터그램을 수신했다고 가정하자. 이 경우 해당 라우터는 패킷을 AS1 내부의 다른 라우터 중 하나인 게이트웨이 라우터(gateway router)에게 전달해야 한다. 하지만 AS1에는 여러 개의 게이트웨이 라우터가 있을 수 있고 어느 게이트웨이를 선택해야 하는지는 intra-AS 라우팅만으로는 판단할 수 없다.

이 문제를 해결하기 위해 inter-AS 라우팅 프로토콜(BGP 등)은 아래와 같은 역할을 수행해야 한다.

1. 외부 목적지에 도달 가능한 경로 정보를 수집해야 한다. 예를 들어 어떤 목적지는 AS2를 통해 접근 가능하고, 또 다른 목적지는 AS3을 통해 가능하다는 정보가 필요하다.
2. 수집한 도달 가능성(reachability) 정보를 AS1 내부의 모든 라우터에 전파해야 한다. 그래야 AS1 내부의 어느 라우터라도 외부 목적지에 대해 적절한 게이트웨이를 선택할 수 있다.
3. 이 정보를 바탕으로 intra-AS 라우팅 알고리즘은 각 목적지에 대해 해당 게이트웨이로 향하는 경로를 계산하고, 포워딩 테이블을 완성하게 된다.

결과적으로, 외부 목적지를 향한 포워딩 결정도 결국 AS 내부 라우팅 체계에 의해 수행되지만, 그 의사결정의 기반은 inter-AS 라우팅 정보에 있다. 즉, inter-AS 라우팅은 단순히 외부 경로를 계산하는 데 그치지 않고, AS 내부의 포워딩 경로 형성에도 영향을 미친다.

## 📡 intra-AS 라우팅 프로토콜

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_9.48.57.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/inter-as-inter-as/image-1753236604176-4)

intra-AS routing에는 여러 프로토콜이 사용된다. 각각은 목적지까지의 경로를 계산하는 방식과 네트워크 규모, 확장성 등에 따라 특징이 다르다. 실제 운영 환경에서는 다음과 같은 프로토콜들이 주로 사용된다.

- RIP (Routing Information Protocol)
  - 고전적인 거리 벡터(Distance Vector) 방식의 라우팅 프로토콜이다. 라우터들은 자신의 거리 벡터를 30초마다 이웃 라우터에게 주기적으로 전달해 이걸 바탕으로 경로를 갱신한다. 구현이 간단하고 구조가 직관적이지만, 수렴 속도가 느리고 홉 수 제한(최대 15홉) 등으로 인해 현재는 널리 사용되지 않는다.
- EIGRP (Enhanced Interior Gateway Routing Protocol)
  - 역시 거리 벡터 기반이지만, 전통적인 DV 방식보다 더 빠르고 안정적인 수렴을 목표로 한다. 수치적 거리 대신 복합적인 경로 메트릭(대역폭, 지연 등)을 고려하고 업데이트도 변화가 있을 때만 보내는 방식이 특징이다. 오랫동안 시스코(Cisco)의 독점 프로토콜이었지만 2013년에 표준화되면서 공개되었다.
- OSPF (Open Shortest Path First)
  - 링크 상태(link-state) 기반의 라우팅 프로토콜로, 네트워크 전체의 구조를 토폴로지 형태로 파악하고 Dijkstra 알고리즘을 이용해 최단 경로를 계산한다. 라우터들은 주기적으로 자신과 연결된 링크 상태 정보를 전체 AS에 광고해 모든 라우터가 동일한 네트워크 맵을 유지한다. 계층적 구조와 강력한 확장성을 바탕으로, 오늘날 가장 널리 사용되는 intra-AS 라우팅 프로토콜 중 하나다.
- IS-IS (Intermediate System to Intermediate System)
  - OSPF와 매우 유사한 링크 상태 기반 프로토콜로 ISO 표준에 기반한 점만 다를 뿐 핵심 원리는 거의 동일하다. 둘 다 대규모 네트워크에서의 정밀한 경로 제어와 빠른 수렴을 지원한다.


intra-AS, inter-AS

네트워크 관리: SNMP, NETCONF, YANG

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-03_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_11.58.36.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-link-layer/image-1753237162915-0)

컴퓨터 네트워크를 계층 구조로 나누었을 때, 링크 계층(Link Layer)은 물리적인 연결에 가장 가까운 위치에 있다. 이 계층은 네트워크를 구성하는 각 노드들이 실제로 연결된 통신 경로를 통해 데이터를 주고받을 수 있도록 도와주는 역할을 한다.

여기서 말하는 노드(node)는 데이터를 주고받는 **호스트**(예: 사용자 단말기나 서버) 또는 **라우터**를 의미하고, 이 노드들이 서로 통신하려면 물리적으로 인접한 노드와 연결되어 있어야 한다. 이러한 연결을 우리는 링크(link)라고 부른다. 링크 계층은 바로 이 링크를 통해 데이터를 전달하는 일을 맡고 있다.

링크는 물리적인 전송 매체를 기반으로 한다. 예를 들어, **유선(wired)** 링크는 이더넷 케이블이나 광케이블처럼 물리적인 전선을 통해 정보를 전달하고, **무선(wireless)** 링크는 Wi-Fi나 LTE처럼 전파를 통해 통신한다. 또한 LAN(Local Area Network)은 비교적 좁은 공간에서 여러 장치가 공유된 매체를 이용해 연결된 환경을 말하고 이 역시 링크 계층의 역할이 중요한 영역이다.

링크 계층에서 데이터를 주고받을 때는 프레임(frame)이라는 단위를 사용한다. 프레임은 상위 계층(예: 네트워크 계층)에서 전달받은 데이터그램(datagram)을 감싸는 형태로 구성된다. 이렇게 만들어진 프레임을 인접한 노드에게 전송하는 것이 이 계층의 기본적인 역할이다. 말하자면, 링크 계층은 데이터그램을 한 홉(hop)씩 다음 노드로 넘겨주는 연결의 다리 역할을 한다.

이 기능은 단순해 보일 수도 있지만, 실제 네트워크 환경은 매우 다양하다. 예를 들어 이동통신망, 글로벌 ISP 환경, 데이터센터, 기업 내부 네트워크 등 각각의 환경마다 링크 계층이 다루는 기술과 방식은 조금씩 다를 수밖에 없다. 그만큼 링크 계층은 네트워크 기술의 기반을 이루면서도 다양한 하드웨어와 프로토콜을 포괄해야 하는 중요한 위치에 있다.

결국 링크 계층은 “한 노드에서 인접한 노드로 데이터를 안정적으로 전달”하는 데 집중해 매체 접근 제어(MAC), 주소 지정, 오류 검출 등의 기능을 제공한다.

### 링크 계층의 맥락

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-03_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_11.58.26.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-link-layer/image-1753237167109-1)

링크 계층은 네트워크 전체에서 한 구간씩 데이터를 전달하는 역할을 맡는다. 우리가 하나의 목적지까지 데이터를 보낼 때, 그 경로에는 여러 개의 네트워크 링크들이 연결되어 있을 수 있다. 예를 들어 어떤 패킷이 전송되는 동안 처음 구간에서는 **Wi-Fi**, 다음 구간에서는 이더넷(Ethernet)을 이용할 수도 있다. 이처럼 각 구간(link)마다 사용하는 전송 기술은 다를 수 있고, 그에 따라 적용되는 링크 계층 프로토콜도 서로 다르다.

각 링크 프로토콜은 자신만의 방식으로 데이터를 전달하고 제공하는 기능도 다르다. 예를 들어 어떤 프로토콜은 오류를 자동으로 감지하고 재전송해주는 신뢰성 있는 전송(reliable transfer)을 지원할 수 있지만, 다른 프로토콜은 그런 기능 없이 데이터만 빠르게 전달하는 데 초점을 맞출 수도 있다. 이처럼 링크 계층은 네트워크 전체를 구성하는 각기 다른 구간들에서 저마다의 방식을 통해 데이터 전달을 책임지고 있는 것이다.

이를 보다 쉽게 이해할 수 있도록, 하나의 여행에 비유해보자. 예를 들어 누군가가 프린스턴에서 로잔(Lausanne)까지 여행을 간다고 해보자. 프린스턴에서 JFK 공항까지는 리무진, JFK에서 제네바까지는 비행기, 제네바에서 로잔까지는 기차를 이용한다면, 이 여행 전체는 여러 개의 이동 수단이 결합된 여정이 된다. 이때 여행자는 바로 데이터그램(datagram)이고, 각 교통 수단이 지나가는 경로는 통신 링크(link), 이동 수단 자체는 링크 계층 프로토콜, 그리고 여정을 설계해준 여행사(또는 경로를 선택해주는 존재)는 라우팅 알고리즘에 해당한다.

이 비유에서 보듯이, 링크 계층은 전체 여정에서 한 구간 한 구간의 이동을 책임진다. 각 구간마다 교통수단이 다르고, 그에 따라 이용 방식이나 제공되는 서비스도 다르지만, 전체 여정을 위해서는 이 다양한 방식들이 함께 잘 조화되어야 한다. 네트워크에서도 마찬가지다. 하나의 패킷이 목적지까지 잘 도달하려면 각 링크마다 적절한 링크 계층 프로토콜이 작동하면서, 상위 계층에서 설정한 경로에 따라 **순차적으로 안정적인 전달**이 이루어져야 한다.

결과적으로 링크 계층은 **이질적인 네트워크 환경**을 부드럽게 연결해주는 인터페이스 역할을 해 물리적으로 인접한 노드 간에 데이터를 안전하고 효율적으로 넘겨주는 데 집중한다.

### 링크 계층의 핵심 기능들

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-04_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_12.14.57.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-link-layer/image-1753237170002-2)

링크 계층은 단순히 데이터를 옆 노드로 전달하는 것 이상의 역할을 한다. 이 계층은 네트워크의 하위에 위치하면서, 인접한 노드 간의 데이터 전송을 좀 더 안정적이고 효율적으로 만들기 위한 다양한 기능들을 제공한다. 하위 계층인 물리 계층이 제공하지 못하는 논리적인 조율을 담당해 상위 계층이 제대로 작동할 수 있도록 돕는다.

가장 기본적인 기능 중 하나는 프레이밍(framing)이다. 링크 계층은 상위 계층에서 내려온 데이터그램(datagram)을 프레임(frame)이라는 형식으로 감싼다. 이 과정에서 앞쪽에는 헤더(header), 뒤쪽에는 트레일러(trailer)를 덧붙이는데, 이 안에는 출발지와 목적지를 식별하기 위한 MAC 주소 같은 정보가 포함된다. MAC 주소는 IP 주소와 달리 **물리적 장치에 부여된 고유한 식별자**로, 동일한 네트워크 내에서의 통신에서 주로 사용된다.

또한 링크 계층은 공유된 매체(shared medium)—예를 들어 이더넷이나 무선 네트워크처럼 여러 장치가 동시에 접근할 수 있는 환경—에서는 누가 언제 통신할지를 정하는 채널 접근 제어(channel access) 기능도 수행한다. 이를 통해 충돌을 최소화하고, 네트워크 자원을 공정하게 분배할 수 있게 된다.

그 외에도 링크 계층은 선택적으로 신뢰성 있는 데이터 전송(reliable delivery)을 제공할 수도 있다. 손실되거나 오류가 발생한 프레임을 다시 보내주는 기능인데, 보통 무선 링크처럼 오류율이 높은 환경에서 중요하게 쓰인다. 반면 이더넷처럼 비트 오류율이 낮은 환경에서는 이런 기능이 오히려 불필요한 오버헤드가 되어 생략되기도 한다.

> 💡 **그렇다면 TCP 같은 end-to-end 신뢰성이 있으면 충분하지 않나?**  
> 무선 구간에서 손실이 많으면, 매번 TCP 수준에서 다시 전송하는 것보다 링크 계층에서 빠르게 재전송해주는게 더 효율적일 수 있다.

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-04_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_12.15.05.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-link-layer/image-1753237173459-3)

이 외에도 링크 계층은 흐름 제어(flow control) 기능을 통해 송신자와 수신자의 전송 속도를 조절함으로써 버퍼 오버플로우를 방지하고, 안정적인 통신을 유지하도록 돕는다. 그리고 오류 검출(error detection) 기능은 신호 감쇠나 잡음으로 인해 발생할 수 있는 비트 오류를 수신 측에서 인식해 잘못된 프레임을 폐기하거나 재전송을 요청할 수 있도록 한다. 나아가 일부 시스템에서는 오류 정정(error correction) 기능까지 제공되어 수신 측에서 비트 오류를 스스로 복구하기도 한다.

마지막으로, 링크의 통신 방식에는 half-duplex와 full-duplex가 있다. half에서는 양쪽 노드가 동시에 데이터를 주고받을 수 없고, 번갈아 가며 전송해야 하는 반면, full에서는 양방향 통신이 동시에 가능하다.

> 💡 현재 대부분의 Ethernet은 전이중을 사용하고 있다. 무선처럼 충돌 위험이 있는 경우에는 반이중이 사용되기도 한다.

### 링크 계층은 어디에 구현되는가

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-04_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_1.01.34.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-link-layer/image-1753237176704-4)

링크 계층은 네트워크에 연결된 모든 호스트—즉, 컴퓨터, 스마트폰, 서버, 라우터 등 네트워크 통신을 수행하는 모든 장치—에 구현되어 있다. 단 한 대의 장치라도 링크 계층이 없으면 물리적으로 인접한 장치와의 데이터 전송이 불가능해진다.

링크 계층은 주로 네트워크 인터페이스 카드(NIC: Network Interface Card) 또는 네트워크 칩셋에 의해 구현된다. 예를 들어 우리가 흔히 사용하는 이더넷 카드, Wi-Fi 칩 등이 바로 링크 계층 기능을 담당하는 하드웨어이다. 물리적인 신호만 주고받는 것이 아니라, 링크 계층과 물리 계층을 모두 구현한 복합적인 구조를 갖고 있다. 즉, 프레임 생성, MAC 주소 처리, 오류 검출, 채널 접근 등의 링크 계층 기능뿐 아니라 전기적 신호를 주고받는 물리 계층의 역할까지 함께 수행한다.

이 NIC는 호스트의 내부 시스템 버스에 연결되어 있어 CPU, 메모리 등 시스템의 다른 구성 요소와 데이터를 주고받을 수 있다. 따라서 운영체제의 네트워크 스택에서 내려온 데이터그램이 링크 계층까지 도달하면 NIC를 통해 실제 프레임으로 변환되고, 물리 매체를 타고 외부로 전송된다. 반대로 수신된 프레임도 NIC에서 처리되어 상위 계층으로 전달된다.

흥미로운 점은, 이 구현이 하드웨어만 구성된 것이 아니다. 실제로 링크 계층은 하드웨어, 소프트웨어, 그리고 펌웨어가 결합된 형태로 동작한다. 예를 들어 프레임 포맷이나 주소 필드 해석 같은 기능은 하드웨어에 내장된 논리 회로에서 수행되지만, 드라이버나 펌웨어는 이러한 동작을 설정하거나 제어하는 데 쓰인다. 또한 운영체제는 NIC와의 인터페이스를 관리하면서 오류가 생겼을 때 로그를 남기거나 처리 순서를 조절하기도 한다.

### 링크 계층이 하는 일 - 송/수신 관점

![controller는 NIC나 칩셋을 의미하고, 여기서 프레임 생성 및 처리, 오류 검사 등을 맡음. physical layer는 전기 신호를 만들고 해석하는 계층.](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-link-layer/image-1753237179603-5)

컴퓨터에서 하나의 애플리케이션이 다른 장치의 애플리케이션과 통신을 할 때, 데이터는 여러 네트워크 계층을 차례로 거치며 포워딩된다. 송신 측에서는 애플리케이션 계층에서 만들어진 데이터가 전송 계층, 네트워크 계층을 거쳐, 마지막으로 링크 계층에 도달하게 된다.

이때 링크 계층은 상위 계층에서 전달받은 데이터그램(datagram)을 받아 이를 프레임으로 감싼다. 이 과정에서 헤더(link header)가 추가되며, 이 안에는 MAC 주소, 프레임 번호, 오류 검출 코드 등 전송에 필요한 다양한 정보들이 담긴다. 또한 링크 계층은 선택적으로 오류 검출(error checking), 신뢰성 있는 전송(reliable delivery), 흐름 제어(flow control) 기능을 수행하기도 한다. 이렇게 구성된 프레임은 네트워크 인터페이스 컨트롤러(NIC)를 통해 전선이나 전파와 같은 물리적 매체를 통해 전송된다.

수신 측에서도 이 흐름은 거꾸로 진행된다. 먼저 물리 계층을 통해 신호가 수신되고, NIC가 이를 프레임으로 재구성한다. 이 프레임은 링크 계층에서 처리되며, 이때 **오류가 있는지 검사하고**, 필요시 **재전송을 요청**하거나 프레임을 **버리기도** 한다. 오류가 없고 정상적인 프레임이라면, 그 안에서 데이터그램을 추출해 상위 계층(네트워크 계층)으로 전달한다.

이 과정은 송신자와 수신자 양쪽 모두에서 이루어지고 링크 계층은 노드 간의 직접적인 통신을 가능하게 하는 가장 가까운 계층으로서 기능한다. 데이터를 전달하는 것처럼만 보일 수 있지만 실제로는 오류 처리, 흐름 조절, 주소 해석 등 다양한 세부 기능들이 함께 작동하면서 안정적이고 신뢰성 있는 네트워크 통신을 만들어내고 있다.


데이터링크 계층이란

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-16_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.20.27.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/subnet-cidr/image-1753237554379-0)

인터넷에 연결된 장치는 모두 IP 주소를 가지고, 이 주소를 통해 서로를 식별하고 데이터를 주고받는다. 하지만 모든 장치를 단일 네트워크로 구성할 수는 없기 때문에 큰 네트워크를 여러 개의 작은 네트워크(서브넷, subnet)로 나누는 방식이 사용된다.

Subnet은 말 그대로 _Sub + Network_, 즉 하나의 큰 네트워크를 작은 단위로 나눈 것을 의미한다. 서브넷은 라우터를 거치지 않고도 직접 통신이 가능한 인터페이스들의 집합이다. 예를 들어 같은 스위치나 공유기에 연결된 장비들은 보통 하나의 서브넷에 속해 서로 라우터를 통과하지 않고 직접 데이터를 주고받을 수 있다.

IP 주소는 두 부분으로 구성된다.

- 네트워크 부분(network/subnet part): 이 주소가 어느 서브넷에 속하는지를 나타낸다. 라우터는 이 정보를 바탕으로 패킷의 전송 경로를 결정한다.
- 호스트 부분(host part): 해당 서브넷 내에서 각 장치를 구분하는 식별자 역할을 한다.

결과적으로 IP 주소만으로도 어느 네트워크에 있는 어떤 장치인지를 식별할 수 있게 된다. 이후 등장하는 서브넷 마스크나 CIDR 표기법으로 경계를 명확하게 표현할 수 있다.

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-16_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.20.38.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/subnet-cidr/image-1753237557667-1)

서브넷을 표현할 때는 일반적으로 CIDR(Classless Inter-Domain Routing) 표기법을 사용한다. 예를 들어 `223.1.1.1/24`라는 주소에서 /24는 이 주소가 서브넷 마스크 24비트를 사용하고 있다는 의미다.

이 경우, 앞의 24비트가 서브넷(네트워크) 주소로 사용되고 나머지 하위 8비트는 해당 서브넷 내의 호스트 주소로 사용된다. `223.1.1.0/24` 서브넷에는 총 256개의 주소(0~255)가 포함되지만, 일반적으로 네트워크 주소(.0)와 브로드캐스트 주소(.255)는 사용할 수 없기 때문에, 실제로는 223.1.1.1부터 223.1.1.254까지가 유효한 호스트 주소가 된다. 이 범위에 속하는 장비들은 모두 같은 서브넷에 속해 있고 서로 라우터 없이 직접 통신할 수 있다.

서브넷은 물리적 연결성과 논리적 경계를 함께 고려해 정의된다. 기본적으로, 각 인터페이스가 라우터 없이 직접 연결될 수 있는 장비들끼리 하나의 서브넷(섬)을 이룬다고 생각하면 된다. 유선이라면 같은 스위치에 연결된 장비들이, 무선이라면 같은 WiFi 액세스 포인트에 연결된 장비들이 보통 같은 서브넷에 속한다. 이러한 방식으로 네트워크를 분리하면 효율적인 트래픽 분산, 보안, 주소 공간 관리 측면에서도 유리하다.

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-16_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.20.47.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/subnet-cidr/image-1753237561250-2)

IP 주소가 같은 서브넷에 속한다는 것은 라우터를 거치지 않고 직접 통신할 수 있다는 것을 의미한다. 서브넷은 IP 주소의 앞부분을 공유하는 장비들의 집합이고, 앞부분의 길이는 서브넷 마스크로 정의된다. 예를 들어 `/24` 서브넷 마스크는 IP 주소의 상위 24비트가 서브넷을 식별하는 부분이고, 하위 8비트가 해당 서브넷 내의 호스트를 구분하는 부분이다. `223.1.1.x` 형식의 주소들은 모두 `223.1.1.0/24` 서브넷에 속하게 된다.

아래는 여러 서브넷과, 각각에 포함된 일부 IP 주소들의 예시다.

| **서브넷 주소 (/24)** | **포함된 IP 주소들**                       |
| --------------------- | ------------------------------------------ |
| **223.1.1.0/24**      | 223.1.1.1, 223.1.1.2, 223.1.1.3, 223.1.1.4 |
| **223.1.2.0/24**      | 223.1.2.1, 223.1.2.2, 223.1.2.6            |
| **223.1.3.0/24**      | 223.1.3.1, 223.1.3.2, 223.1.3.27           |
| **223.1.7.0/24**      | 223.1.7.0, 223.1.7.1                       |
| **223.1.8.0/24**      | 223.1.8.0, 223.1.8.1                       |
| **223.1.9.0/24**      | 223.1.9.1, 223.1.9.2                       |

각 서브넷은 `223.1.X.0/24` 형식으로 구성되어 동일한 X 값을 공유하는 장비들이 같은 서브넷에 속한다. 예를 들어 `223.1.3.1`과 `223.1.3.27`은 모두 `223.1.3.0/24` 서브넷에 속하므로, 서로 직접 통신할 수 있다. 반면 `223.1.3.1`과 `223.1.2.2`는 서로 다른 서브넷이므로, 라우터를 통해서만 통신할 수 있다.

### CIDR

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-16_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.20.54.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/subnet-cidr/image-1753237564231-3)

과거의 IP 주소 체계는 Class A, B, C처럼 고정된 블록 단위로 주소를 할당하는 클래스 기반 주소 체계였다.

- Class A: /8 – 약 16,777,216개의 호스트 주소
- Class B: /16 – 약 65,536개
- Class C: /24 – 256개

이 방식은 단순했지만 주소 공간을 매우 비효율적으로 사용하게 되었다. 작은 기업이나 조직도 필요 이상으로 큰 주소 블록을 할당받아야 했고, 전체 IP 주소 공간이 빠르게 고갈되었다.

이러한 문제를 해결하기 위해 등장한 방식이 바로 CIDR(Classless Inter-Domain Routing)이다. CIDR은 주소를 클래스에 구애받지 않고 필요한 만큼의 크기로 유연하게 나눌 수 있는 방식이다.

CIDR 표기법은 아래와 같은 형식을 따른다.

```plain text
a.b.c.d/x
```

a.b.c.d는 IP 주소의 시작점, 즉 서브넷(네트워크)의 주소다. `/x`는 상위 x비트가 네트워크(서브넷) 식별자임을 나타닌다. 나머지 `32 - x` 비트는 호스트 구분에 사용한다.

예를 들어 `192.168.10.0/28`은 상위 28비트가 네트워크다. 나머지 4비트를 사용해 최대 16개의 호스트 주소를 지정할 수 있다. 단, 네트워크와 브로드캐스트 주소를 제외하면 실제 사용 가능한 호스트는 14개다.

CIDR 덕분에 IP 주소 공간을 훨씬 더 세밀하게 분할할 수 있게 되었고 네트워크 크기에 맞는 주소를 할당함으로써 주소 낭비를 줄이고 라우팅 효율도 향상시킬 수 있게 되었다.


Subnet & CIDR

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_7.55.33.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow/image-1753237429463-0)

OpenFlow는 소프트웨어 정의 네트워킹(SDN, Software-Defined Networking)의 기술 중 하나로, 네트워크 장비의 제어 기능을 중앙화된 컨트롤러로 분리해내기 위해 도입되었다. 기존의 네트워크 장비는 데이터 전달과 제어 기능을 모두 장비 내부에서 처리했기 때문에 복잡한 정책 변경이나 새로운 기능 적용이 어렵고 비효율적이었다. 하지만 OpenFlow는 제어 기능을 외부의 중앙 컨트롤러가 담당하고, 스위치나 라우터는 단순히 컨트롤러의 지시에 따라 패킷을 전달하는 역할만 수행하게 만든다.

OpenFlow를 사용하는 장비는 내부에 flow table이라는 구조를 가지고 있다. 이 테이블은 들어오는 패킷이 어떤 규칙에 일치하는지를 확인한 뒤, 그에 따라 어떤 동작을 취할지를 정의한다. 각 flow entry는 일치 조건(Match), 동작(Action), 그리고 통계 정보(Stats)로 구성된다.

- Match (일치 조건)
  - 패킷이 스위치에 도달하면 해당 패킷의 헤더 정보를 기반으로 flow table에서 일치하는 항목을 찾는다. 이때 참조하는 헤더 필드는 계층별로 다양하다.
  - 예를 들어 데이터링크 계층에서는 입력 포트나 MAC 주소, VLAN 정보 등을 사용할 수 있고, 네트워크 계층에서는 IP 주소나 프로토콜 번호, 전송 계층에서는 TCP/UDP 포트 번호 등이 사용된다. 이처럼 풍부한 헤더 필드를 기반으로 정교한 분류가 가능하다.
- Action (동작)
  - 일치하는 flow entry를 찾으면 정의된 동작에 따라 해당 패킷은 특정 포트로 전달되거나(drop), 헤더가 수정되거나, 혹은 컨트롤러로 전송되기도 한다. 네트워크의 제어 논리는 외부 컨트롤러에서 정의하고 각 스위치는 그것을 빠르게 실행하는 역할을 맡는다.
- Stats (통계)
  - 각 flow entry는 얼마나 많은 패킷과 바이트를 처리했는지에 대한 통계 정보를 유지한다. 네트워크 상태를 모니터링하거나 동적으로 정책을 조정할 때 활용될 수 있다.

## 📡 계층 분리 없는 제어: L2~L3

![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow/image-1753237432534-1)

OpenFlow는 패킷의 헤더 정보를 기반으로 구체적인 정책을 테이블 형식으로 정의하고 네트워크를 제어할 수 있다. 이 규칙들은 포워딩부터 방화벽 수준의 정책까지 다양하게 확장될 수 있다.

<u>Destination-Based Forwarding</u>

- IP 주소가 51.6.0.8인 패킷을 포트 6으로 전달한다
  - `IP Dst` 51.6.0.8
  - `나머지 필드` \* (와일드카드)
  - `Action` forward to port6
- 전통적인 라우팅과 비슷하지만, 매우 구체적인 정책을 테이블로 명시할 수 있다

<u>Firewall (방화벽)</u>

- TCP 포트 22 (SSH)로 향하는 트래픽은 차단(drop), 특정 애플리케이션(SSH)을 정책적으로 차단할 수 있다
  - `IP Proto` TCP
  - `TCP Dst Port` 22
  - `나머지 필드` \*
  - `Action` drop
- 특정 출발지 IP(128.119.1.1)에서 온 패킷은 모두 차단(drop)하고, 특정 장치나 유저의 트래픽을 정밀하게 필터링이 가능하다
  - `IP Src` 128.119.1.1
  - `나머지 필드` \*
  - `Action` drop

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_8.12.30.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow/image-1753237435089-2)

<u>Layer 2 Destination-Based Forwarding</u>

- 목적지 MAC 주소가 22:A7:23:11:E1:02인 프레임, 스위치의 포트 3으로 전달한다
  - `MAC dst` 22:A7:23:11:E1:02
  - `나머지 필드` \*
  - `Action` forward to port3
- L3 라우터 뿐만 아니라 L2 스위치까지 모두 통합적으로 제어 가능하다

## 📡 End-to-End 제어

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_8.17.42.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow/image-1753237437141-3)

- 네트워크 구성도
  - s3는 h5/h6과 연결
  - s1 → s2는 라우팅 중간 지점
  - s2는 목적지 h3/h4로 연결

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_8.17.49.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow/image-1753237440316-4)

OpenFlow의 가장 큰 장점 중 하나는 여러 스위치를 거치는 복잡한 네트워크 흐름을 중앙 컨트롤러가 설계하고 각 스위치에는 이에 맞는 규칙만 설치하면 전체 트래픽 흐름을 구현할 수 있다는 점이다. 다음은 그런 end-to-end 제어의 대표적인 예시다.

네트워크에는 여러 호스트와 스위치가 존재한다. h5와 h6는 각각 IP 주소 `10.3.0.5`, `10.3.0.6`을 가지며 스위치 s3에 연결되어 있고, 최종 목적지는 `10.2.0.3`(h3) 또는 `10.2.0.4`(h4)다. 이 트래픽은 스위치 s1과 s2를 거쳐야 하고 이러한 흐름을 위해 각 스위치에는 다음과 같은 flow rule이 설정된다.

- s3 (엣지 스위치)
  - h5, h6에서 나온 트래픽은 일단 s1으로 포워딩한다

  ```plain text
  match:
    IP Src = 10.3.*.*
    IP Dst = 10.2.*.*
  action:
    forward(3)  // s1으로 향하는 포트
  ```

- s1 (중간 스위치)
  - s1은 s3에서 온 트래픽을 s2로 넘긴다

  ```plain text
  match:
    ingress port = 1
    IP Src = 10.3.*.*
    IP Dst = 10.2.*.*
  action:
    forward(4)  // s2로 전달
  ```

- s2 (마지막 스위치)
  - 목적지 IP에 따라 정확한 호스트로 포워딩한다

  ```plain text
  match:
    ingress port = 2
    IP Dst = 10.2.0.3
  action:
    forward(3)  // h3

  match:
    ingress port = 2
    IP Dst = 10.2.0.4
  action:
    forward(4)  // h4
  ```

- 전체 흐름
  - h5 → s3 (match) → s1 (match) → s2 (match) → h3 or h4
  - 모든 스위치의 Flow Table이 SDN 컨트롤러에 의해 조율된다(orchestrated). 즉, 하나의 중앙 지능이 전체 네트워크 동작을 설계하고 명령한다.


OpenFlow

### **왜 인터넷에는 계층적 주소 구조가 필요한가?**

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.07.00.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/hierarchical-ip-addressing/image-1753237511896-0)

인터넷은 수십억 개의 장치가 연결된 거대한 네트워크다. 이 장치들 각각이 고유한 IP 주소를 가지기 때문에 라우터는 목적지 IP 주소를 기반으로 올바른 경로를 선택해 패킷을 전달해야 한다. 하지만 전 세계의 모든 IP 주소에 대해 일일이 경로를 저장하고 유지하는 것은 기억 공간이나 관리 측면에서 비현실적이다.

이 문제를 해결하기 위해 인터넷은 계층적인 IP 주소 구조(hierarchical addressing)를 채택하고 있다. 즉, IP 주소를 조직, 지역, ISP 등의 논리적 단위로 묶고, 이 단위별로 요약된 경로 정보(route aggregation)만 라우터에 광고하게 한다.

### route aggregation

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.07.05.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/hierarchical-ip-addressing/image-1753237513737-1)

가령, Fly-By-Night ISP라는 지역 인터넷 제공업체가 다음과 같은 여러 조직에 IP 주소 블록을 할당했다고 하자.

- Organization 0 → `200.23.16.0/23`
- Organization 1 → `200.23.18.0/23`
- Organization 2 → `200.23.20.0/23`
- …
- Organization 7 → `200.23.30.0/23`

Fly-By-Night ISP는 이 모든 조직의 IP 주소들을 하나의 **더 큰 블록**으로 묶어 다음과 같이 광고할 수 있다.

> ‘`200.23.16.0/20`으로 시작하는 주소는 모두 내게 보내줘.’

이 말은 해당 ISP가 관리하는 조직들에 대한 **세부 경로 정보를 외부에 드러내지 않고**, 하나의 요약된 경로(prefix)만 인터넷 전체에 알려주는 것을 의미한다. 이처럼 여러 개의 세부 네트워크를 하나로 묶는 과정을 route aggregation(경로 집합화)라고 한다.

마찬가지로 더 상위 ISP인 “ISPs-R-Us”는 여러 하위 ISP가 사용하는 IP 대역 전체를 199.31.0.0/16처럼 더 넓은 범위로 요약해 상위 인터넷 백본에 광고할 수 있다.

### 더 구체적인 경로

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.07.10.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/hierarchical-ip-addressing/image-1753237515888-2)

계층적 IP 주소 구조는 주소 공간을 집약하고 요약된 경로(prefix)를 통해 라우팅 정보를 간결하게 유지할 수 있게 해준다. 하지만 인터넷은 끊임없이 변화하는 환경이기 때문에 라우팅 체계도 이 변화에 유연하게 대응해야 한다.

예를 들어 어떤 조직(Organization 1)이 기존에는 Fly-By-Night ISP를 통해 인터넷에 연결되어 있었지만, 이제 ISPs-R-Us라는 다른 ISP로 이관되었다고 하자.

이 경우 기존 라우팅 구조는 다음과 같았다.

- Fly-By-Night ISP는 전체 조직들(Organization 0~7)에 대해 `200.23.16.0/20`이라는 요약된 경로로 광고하고 있었고, 이 범위에는 Organization 1(200.23.18.0/23)도 포함되어 있었다.

하지만 이제 Organization 1은 ISPs-R-Us를 통해 연결되므로 더 이상 Fly-By-Night ISP에 속하지 않는다. 이에 따라 ISPs-R-Us는 `200.23.18.0/23`이라는 더 구체적인 경로를 별도로 광고하게 된다.

> ‘`199.31.0.0/16`은 내 소속이고, 추가로 `200.23.18.0/23`도 내 쪽으로 보내줘.’

이처럼 하나의 주소 대역(ex, `200.23.18.0/23`)에 대해 여러 ISP가 서로 다른 범위로 경로를 광고할 수 있고, 이 중 가장 구체적인 경로, 즉 Longest Prefix Match(가장 긴 일치 접두어)를 따르는 것이 인터넷 라우팅의 원칙이다.

### **IP 주소는 어떻게 할당되는가? 그리고 충분한가?**

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.07.27.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/hierarchical-ip-addressing/image-1753237518496-3)

전 세계의 IP 주소 공간은 무작위로 사용되는 것이 아니라, **글로벌한 관리 체계**를 통해 조직적으로 배분된다. 이 관리의 최상단에는 ICANN(Internet Corporation for Assigned Names and Numbers)이 있으며, ICANN은 다음과 같은 역할을 수행한다.

- IP 주소 공간을 전 세계 5개 지역 인터넷 등록기관(RIR, Regional Internet Registries)에 할당한다.

  각 RIR은 소속 국가와 지역의 ISP나 기관에 주소를 재분배한다.

- DNS 루트 영역을 관리하고, 각 최상위 도메인(TLD, 예: .com, .edu)에 대한 관리 권한을 위임한다.

하지만 인터넷이 급속도로 확산되면서 IPv4의 32비트 주소 공간이 예상보다 훨씬 빠르게 고갈되었다. 실제로 ICANN은 2011년에 IPv4 주소의 마지막 블록을 RIR에 모두 할당했다. 이로써 공식적인 IPv4 주소 배정은 종료되었고, 기존에 남아 있는 할당된 주소만이 재사용되고 있다.

이러한 주소 부족 문제를 해결하기 위한 대응은 두 가지 방향으로 이루어졌다.

1. NAT(Network Address Translation): 하나의 공용 IP 주소를 여러 장치가 공유하게 함으로써, IPv4 주소 공간의 활용도를 극대화.
2. IPv6의 도입: IPv6는 주소 길이를 128비트로 확장해 사실상 무한에 가까운 주소 공간을 제공한다.

IP 주소 체계를 설계할 당시엔 누구도 지금처럼 전 세계 수십억 대의 장치가 인터넷에 연결될 거라고 예측하지 못했다. 이에 대해 인터넷의 아버지 중 한 명인 Vint Cerf는 훗날 이렇게 회고했다.

> _**도대체 우리가 얼마나 많은 주소 공간이 필요할 줄 알았겠어?**_
>
> - Vint Cerf (IPv4를 32비트로 설계한 결정을 돌아보며)


인터넷은 어떻게 주소를 구조화할까 - Hierarchical IP Addressing

## 📡 네트워크 계층의 목표

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.04.54.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237347944-0)

네트워크 계층의 데이터 플레인(data plane)에 초점을 맞춰 네트워크 계층이 어떤 서비스 모델을 제공하는지, 라우팅과 포워딩의 차이, 실제 라우터가 어떻게 동작하는지를 살펴본다. IP 주소 체계를 포함한 주소 지정 방식, 전통적인 목적지 기반 포워딩을 확장한 generalized forwarding 개념, 그리고 이러한 구조가 전체 인터넷 아키텍처에서 어떤 역할을 수행하는지도 함께 다룬다.

실제 인터넷 환경에서 어떻게 구현되는지도 역시 중요한 학습 주제다. 구체적으로는 IP 프로토콜의 데이터그램 구조와 동작 방식, 여러 장비가 하나의 공용 IP 주소를 공유할 수 있게 해주는 NAT(Network Address Translation), 그리고 방화벽이나 프록시와 같은 미들박스(middleboxes)의 역할과 동작 방식까지 살펴본다.

## 📡 Data plane

### 네트워크 계층 서비스와 프로토콜

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.02.55.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237349723-1)

네트워크 계층은 송신 호스트에서 수신 호스트로 전송 계층의 세그먼트를 전달하는 역할을 한다.

송신 측에서는 전송 계층에서 생성된 세그먼트를 IP 데이터그램으로 캡슐화한 후, 링크 계층으로 넘긴다. 수신 측에서는 이 데이터그램에서 세그먼트를 추출해 전송 계층에 전달한다. 이 과정을 통해 애플리케이션 데이터는 여러 네트워크를 거쳐 목적지에 도달한다.

네트워크 계층 프로토콜은 인터넷에 연결된 모든 장치에 구현되어 있다. 호스트뿐 아니라, 경로를 선택하고 데이터그램을 전달하는 라우터에도 포함된다. 라우터는 수신한 데이터그램의 IP 헤더를 확인해 목적지를 파악하고, 이를 적절한 출력 포트로 전송한다.

네트워크 계층은 모바일, 기업, ISP, 데이터센터 등 다양한 종류의 네트워크를 하나로 연결하는 구조를 형성한다. 이질적인 네트워크들이 함께 동작할 수 있는 이유는 IP(Internet Protocol)라는 공통된 프로토콜이 존재하기 때문이다. IP는 서로 다른 네트워크 간 통신을 가능하게 해 인터넷이 전 세계적으로 작동할 수 있도록 한다.

### 네트워크 계층의 두 가지 주요 기능

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.04.14.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237354022-2)

네트워크 계층은 포워딩$_{forwarding}$과 라우팅$_{routing}$이라는 두 가지 필수적인 기능을 수행한다.

포워딩은 라우터가 입력 링크로 받은 패킷을 적절한 출력 링크로 이동시키는 과정이다. 로컬 작업으로, 각 라우터가 자신의 포워딩 테이블을 참조해 개별 패킷을 어디로 보낼지 결정한다. 여행에 비유하자면, 포워딩은 특정 교차로나 인터체인지를 통과하는 과정과 유사하다.

이 두 기능은 상호 보완적이다. 라우팅이 전체 경로의 청사진을 그린다면, 포워딩은 그 청사진에 따라 각 지점에서 다음 홉으로 패킷을 전달하는 작업을 수행한다. 네트워크 계층의 효율성은 이 두 기능이 얼마나 잘 조화를 이루는지에 달려 있다.

### 네트워크 계층: data plane, control plane

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.04.23.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237358395-3)

네트워크 계층은 기능적으로 data plane과 control plane이라는 두 가지 구분된 영역으로 나눌 수 있다.

data plane은 라우터 단위의 지역적$_{local}$ 기능을 담당한다. 주요 역할은 라우터의 입력 포트로 도착한 데이터그램을 어떤 출력 포트로 전달할지 결정하는 것이다. 이 결정은 주로 패킷 헤더에 있는 값들(특히 목적지 주소)을 검사해 이루어진다. data plane은 고속으로 동작해야 하므로 주로 하드웨어로 구현되고 나노초 단위의 시간 프레임 내에서 작동한다.

반면, control plane은 네트워크 전반에 걸친 논리를 구현한다. 출발지 호스트에서 목적지 호스트까지 데이터그램이 라우터들을 통해 어떻게 라우팅될지 결정한다. control plane은 밀리초 단위의 시간 프레임에서 작동하고 주로 소프트웨어로 구현된다.

control plane 구현에는 두 가지 접근 방식이 있다.

- 전통적인 라우팅 알고리즘
  - 각 라우터에 개별적으로 구현되어 있으며, 라우터들은 서로 라우팅 정보를 교환해 포워딩 테이블을 구성합니다.
- 소프트웨어 정의 네트워킹$_{SDN}$
  - 중앙집중식 접근 방식으로, 라우팅 결정은 원격 서버(컨트롤러)에서 이루어지고, 이 결정이 각 라우터의 포워딩 테이블에 설치됩니다.

## 📡 Control plane

### 라우터별 control plane

![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237361058-4)

전통적인 네트워크 구조에서는 각 라우터가 자체적으로 control plane 기능을 수행한다. 라우팅 알고리즘은 라우터마다 독립적으로 구현되고 라우터 간 상호작용을 통해 전체 네트워크의 control plane이 분산된 형태로 구성된다.

각 라우터는 인접한 라우터들과 주기적으로 라우팅 정보를 교환하고 이를 바탕으로 네트워크 토폴로지를 학습한다. 그 결과로 최적 경로를 계산해 포워딩 테이블에 저장한다. 포워딩 테이블은 데이터 패킷을 올바른 경로로 전달하기 위해 data plane이 참조하는 중요한 자료다.

포워딩 과정 자체는 단순하다. 라우터는 수신한 패킷의 헤더 중 목적지 IP 주소를 확인하고, 포워딩 테이블에서 해당 항목을 찾아 출력 포트를 결정한다. 포워딩은 테이블 기반의 헤더 조회를 통해 이루어진다.

이 구조는 control plane이 라우터별로 분산되어 있어 네트워크 확장성 측면에서 유리하다. 각 라우터가 독립적으로 동작하므로 단일 장애점이 없다는 장점도 있다. 하지만 일일이 정책을 정해줘야 하기 때문에, 네트워크 전체에 정책을 일관되게 적용하기 어려워 구성과 운영이 복잡해질 수 있다.

### 소프트웨어 정의 네트워킹(SDN) control plane

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.20.04.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237364316-5)

소프트웨어 정의 네트워킹(SDN: Software Defined Networking)은 네트워크의 control plane을 중앙에서 관리하는 방식이다. 전통적인 네트워크에서는 각 라우터가 자체적으로 라우팅 결정을 내리지만, SDN에서는 이러한 기능이 중앙의 컨트롤러로 옮겨진다.

> 기존의 분산형 네트워크 구조는 유연하지만, 네트워크 상태를 통합적으로 파악하거나 일관된 정책을 적용하는 데에는 한계가 있다. 이런 문제를 해결하기 위한 접근이 바로 소프트웨어 정의 네트워킹(SDN)이다.

컨트롤러는 네트워크 전체 상태에 대한 전반적인 정보를 가지고 있고 이걸 바탕으로 각 라우터에 필요한 포워딩 테이블을 계산해 전달한다. 이 과정에는 OpenFlow 같은 표준 프로토콜이 사용된다.

SDN 구조에서는 라우터가 제어 기능을 수행하지 않는다. 컨트롤러로부터 받은 포워딩 테이블을 참고해 data plane 수준에서 패킷을 전달하는 역할만 한다. 제어와 실행이 분리되어 라우터는 결정이 아닌 실행만 맡는다.

이렇게 되면 네트워크 운영을 단순화할 수 있고정책을 일관되게 적용할 수 있다는 장점이 있다. 또한 새로운 기능이나 정책을 컨트롤러에만 반영하면 전체 네트워크에 빠르게 확산시킬 수 있어, 트래픽 관리, 보안, 가상화 등 다양한 기능 구현에 유리하다.

하지만 중앙 컨트롤러는 단일 장애점(Single Point of Failure)이 될 수 있고, 네트워크 규모가 커질수록 컨트롤러의 부하와 확장성 문제가 나타날 수 있다. 이를 보완하기 위해 최근에는 복수의 컨트롤러를 사용하는 분산형 구조도 함께 연구되고 있다.

### 네트워크 계층 서비스 모델

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.20.14.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237368020-6)

네트워크 서비스 모델은 송신자에서 수신자로 데이터그램을 전달하는 “채널”이 어떤 수준의 서비스 보장을 제공할지를 정의한다. 이 모델은 단일 데이터그램에 대해 적용될 수도 있고, 데이터그램의 연속적인 흐름(플로우)에 대해 적용될 수도 있다. 개별 데이터그램에 대한 서비스로는 데이터그램이 반드시 목적지까지 전달되는 것을 보장하는 방식이나, 40밀리초 이하의 지연 시간 내에 도달할 것을 보장하는 방식이 있다.

반면, 플로우 단위의 서비스에서는 더 정교한 보장이 필요하다. 예를 들어 데이터그램이 송신 순서대로 수신되도록 보장하거나, 특정 플로우에 대해 최소한의 대역폭을 보장하거나, 각 패킷 간의 간격이 일정 수준 이상 변하지 않도록 제한하는 방식이 해당한다.

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.20.25.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237370335-7)

네트워크 계층의 서비스 모델은 데이터그램 전송 시 어떤 품질 보장을 제공하는지를 정의하고, 네트워크 아키텍처가 애플리케이션에게 어떤 수준의 신뢰성과 성능을 제공할 수 있는지를 나타낸다. 현재의 인터넷은 best-effort 서비스 모델을 채택하고 있어 전송되는 데이터그램에 대해 대역폭, 손실 방지, 순서 보장, 지연 시간 등에 대해 아무런 보장을 제공하지 않는다.

![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237375329-8)

반면 ATM 네트워크는 Constant Bit Rate(CBR) 모델을 통해 고정된 대역폭을 제공하고, 패킷 손실 없이 순서와 타이밍까지 보장하는 높은 수준의 서비스를 제공한다. 같은 ATM 기반이라도 Available Bit Rate(ABR) 모델은 최소 대역폭만 보장하고, 그 외 품질 요소들은 보장하지 않는다.

인터넷 환경에서도 품질 보장을 제공하려는 시도로 Intserv(Integrated Services)와 Diffserv(Differentiated Services)라는 두 가지 모델이 있다.

Intserv는 RFC 1633에 정의되어 데이터그램의 성공적인 목적지 전달은 물론, 도착 순서와 지연 시간까지 명시적으로 보장해 종단 간 흐름에 대해 필요한 대역폭을 사전에 예약하는 구조다. 이에 비해 Diffserv는 RFC 2475에서 정의되어 흐름이 아닌 트래픽 클래스 단위로 차별화된 처리를 통해 QoS를 제공한다. Diffserv는 일부 조건에서 순서나 지연, 대역폭에 대한 상대적 보장을 가능하게 하지만 Intserv처럼 정밀한 품질 보장을 명시적으로 제공하지는 않는다.

### best-effort 모델에 대한 고찰

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.25.23.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237379182-9)

인터넷은 전 세계적으로 수많은 네트워크와 장비들이 연결되어 형성된 구조다. 이처럼 이질적인 환경에서 통일된 품질 보장을 제공하는 것은 기술적으로나 운영 측면에서 많은 제약이 따른다. 이러한 배경 속에서, 인터넷은 복잡한 보장 없이도 동작 가능한 단순한 전송 모델, 즉 best-effort 모델을 채택하게 되었다.

best-effort 모델은 가능한 한 데이터를 전달하되, 지연, 손실, 순서 보장 등을 명시적으로 보장하지 않는다. 그 대신 구현이 단순하고 확장성이 뛰어나 다양한 환경에서 손쉽게 도입될 수 있었다. 이 점이 인터넷이 빠르게 확산되는 데 중요한 역할을 했다.

충분한 대역폭이 확보된 환경에서는 실시간 음성 통화나 화상 회의처럼 지연에 민감한 애플리케이션도 대부분의 경우 수용 가능한 품질을 유지할 수 있다. 명시적인 보장 없이도 서비스 제공이 가능했던 것이다. 애플리케이션 계층에서도 이러한 한계를 보완할 수 있었다. 데이터센터와 콘텐츠 전송 네트워크(CDN)는 사용자와 가까운 위치에서 서비스를 제공함으로써 지연을 줄이고 전송 효율을 높였다. 분산된 애플리케이션 구조를 통해 네트워크 계층이 복잡한 보장을 제공하지 않아도 안정적인 사용자 경험이 가능해졌다.

게다가 탄력적인 애플리케이션은 네트워크 상황에 맞춰 전송 속도를 조절하는 혼잡 제어 메커니즘을 통해 혼잡 상태에서도 전체적인 안정성과 공정성을 유지할 수 있었다. 결과적으로 best-effort 모델은 단순함과 실용성이라는 강점을 바탕으로, 인터넷의 확장성과 유연성을 이끌어낸 설계가 될 수 있었다.


2025