2024-12-16 <OSI 7계층 - 네트워크 계층(IP, 서브넷 마스크, 라우터와 라우팅)>

네트워크 계층을 설명하기에 앞서 OSI에 대해 잠시 복습하고 들어가자.

OSI 7계층이란?

네트워크 통신이 일어나는 과정을 7단계로 나누어서 설명하는 모델이다.

 

이 모델에 의해 네트워크 프로토콜도 계층별로 구성된다. 그러나 아무리 계층을 체계적으로 나누어둔다 하여도, 어떤 양식으로 보낼지, 어떤 규칙을 준수해야 하는지 미리 정하지 않는다면 서로 소통할 수 없을 것이다. 여기서 프로토콜이란 개념이 설명되는데, 프로토콜은 서로 다른 네트워크 장치들이 메시지를 주고 받기 위한 통신규약이라고 할 수 있겠다.

 

OSI 7 계층은 물리 계층, 데이터 링크 계층, 네트워크 계층, 전송 계층, 세션 계층, 표현 계층, 응용 계층으로 구성되어 있으며, 이번 게시글에서는 네트워크 계층에 대해 자세히 알아 보겠다.

네트워크 계층의 핵심

OSI 7계층의 핵심은 데이터를 분할하여 전송하고 재조립하여 수신하는 과정을 계층별로 나눌 수 있다는 점에 있다. 우리가 애플리케이션 레벨에서 보낸 이미지가 실제 케이블을 타고 1과 0의 전기 신호를 거쳐 다른 네트워크 장치에 도달하고, 비트 단위로 분할되었던 데이터가 원래의 이미지로 재구성되기까지. 이 과정이 바로 네트워크 통신이 이루어지는 모습이다.

먼저, 송신 측의 입장에서 네트워크 계층에 대해 설명해 보겠다. 네트워크 계층은 일곱 가지의 계층 중 위에서부터 닷섯번째에 해당한다. 이때 데이터는 이미 '세그먼트' 단위로 분할되어 네트워크 계층에 도착해 있다.

 

하지만, 세그먼트 상태로는 데이터 링크 계층으로 이동할 수 없다. 왜냐하면 네트워크 환경에는 MTU(Maximum Transmission Unit)라는 데이터 전송 단위에 제한이 걸려있기 때문이다. 예를 들어, 이더넷의 MTU는 1500바이트인데, 세그먼트가 이를 초과하면 전송할 수 없기 때문에 데이터를 더 작은 단위로 분할해줄 필요가 있다.

 

따라서, 네트워크 계층은 데이터를 '패킷'의 형태로 만들게 된다.

패킷 분할의 장점

데이터가 패킷으로 전송될 때의 장점에는 여러 가지가 있다.

1. 다양한 네트워크 장치들의 서로 다른 MTU를 만족시킬 수 있다.
2. 데이터 전송 중 일부가 손상되거나 손실될 수 있다. 작은 패킷 단위로 전송하면 손실된 패킷만 재전송하면 되므로 네트워크 성능이 향상된다.
3. 패킷은 독립적으로 라우팅될 수 있어, 네트워크 상태에 따라 다른 경로를 통해 전달될 수 있다. 이는 네트워크 혼잡을 줄이고 데이터가 더 빠르게 도착하도록 돕는다.

1번과 2번의 장점은 비전공자가 보더라도 직관적으로 이해하기에 어렵지 않다. 하지만 3번의 경우 '라우팅'이라는 개념이 필요하기에 다소 모호하게 느껴진다.(라우터에 대해선 아래에서 더 자세히 서술하겠다.) 아마 이런 의문이 들 수도 있을 것이다.

 

"세그먼트도 TCP/UDP라는 프로토콜을 이용한다며. 라우팅이란 걸 쓸 수 없는 거야?"

 

이에 대한 답을 자세히 찾아보도록 하자.

네트워크 계층의 역할 - 경로 설정

결론부터 말하겠다. 데이터가 세그먼트 상태일 때 라우팅이 불가능한 이유는 세그먼트 자체에는 IP 주소와 같은 네트워크 경로 정보가 없기 때문이다. 즉, 송신 측의 세그먼트에는 데이터의 전송을 제어해주기 위한 정보만 담겨있을 뿐 아직 행선지에 대한 정보는 적혀 있지 않은 상태다.(포트 번호 정도만 적혀 있고 그 포트가 어디에 있는 건지는 모르는 상황이다.) 따라서, 네트워크 계층은 세그먼트를 패킷으로 분할하고 경로 설정에 대한 정보를 헤더에 담아주게 된다.

IP의 개념과 IP 주소 체계

바로 이때 할당되는 주소를 바로 IP(Internet Protocol)라고 부른다. 인터넷에서 데이터 패킷을 송수신하기 위한 고유한 식별자라고 이해할 수 있겠다.

IP 주소 체계는 IPv4와 IPv6로 두 가지인데, 두 체계의 차이점은 주소의 길이라고 볼 수 있다.

IPv4는 4개의 옥텟으로, IPv6는 16개의 옥텟으로 이루어져 있다. 따라서, IPv4의 경우 2의 32제곱(대략 43억)만큼의 주소를 가질 수 있다. 우리가 쓰는 네트워크 장치(컴퓨터)도 인터넷 상에서 이런 IPv4 체계의 IP주소를 사용하고 있을 것이다.

그런데 중요한 점이 하나 있다. 현실 세계의 주소가 서울 특별시 관악구 신림동처럼 세분화되어 있듯이, 인터넷 세계의 주소도 그러하다는 점이다.

 

실제로 IP주소는 네트워크 ID와 호스트 ID로 이루어져 있으며, 그들을 구분해주기 위해 서브넷 마스크라는 별도의 수단을 사용하고 있다. 네트워크 ID는 말 그대로 네트워크의 식별자이며, 해당 네트워크에 소속된 호스트들은 모두 같은 네트워크 ID를 가지고 있다. 그리고 각각의 단말기들은 호스트 ID를 통해 식별이 가능하다.

 

여기서 라우터는 바로 이 네트워크 ID를 기준으로 데이터를 목적지 네트워크로 라우팅하게 된다.(그래서 세그먼트로는 데이터 전송이 불가능했던 것) 네트워크 내에서 호스트로 데이터를 전달하는 역할은 데이터 링크 계층이 맡고 있기 때문에 이와 관련된 정보는 데이터 링크 계층 게시글을 참고 바란다.

 

그렇다면 라우터는 IP주소에서 어디까지가 네트워크 ID이고, 어디까지가 호스트ID인지 어떻게 구분하는 걸까?
=> 이 답이 바로 위에서 언급한 서브넷 마스크이다.

서브넷 마스크

서브넷 마스크는 네트워크와 호스트 부분을 구분하기 위해 사용되는 총 32bit 길이의 숫자들이다. 이들이 하는 역할을 글로만 표현하긴 난해하기 때문에 피그마로 간단하게 다이어그램을 만들어 보았다.

위와 같은 방법을 이용해서 서브넷 마스크는 IP 주소의 네트워크 ID와 호스트 ID를 구분해줄 수 있다. 이때 서브넷 마스크의 범위를 어떻게 지정하느냐에 따라 로컬 네트워크의 범위는 좁아질 수도, 넓어질 수도 있다.

 

이를 테면 네트워크를 국가 단위로도 넓힐 수 있을 것이고, 아니면 어느 회사 건물로 국한시킬 수도 있을 것이다. 이와 같은 방식은 대규모 네트워크를 보다 효율적으로 관리하는 것도 도움이 된다. 적어도 전세계 네트워크에서 경로를 찾아가는 것보단 더 작은 네트워크 규모에서 장치를 찾아가는 게 더 쉬울 테니 말이다.

라우터와 라우팅

이제 서브넷 마스크를 통해 IP에 담긴 네트워크 ID를 구분해내는 방식을 올바르게 이해했을 것이다.
그런데, 라우팅해준다는 게 무슨 뜻일까? 맥락상 네트워크의 경로를 설정해주는 것이라고 감이 오기는 한다만, 정확한 의미를 알아볼 필요가 있다.

실생활에서의 라우팅 예시 : express.js

네트워크 통신 계층에서의 라우팅이란 개념을 바로 설명한다면 분명 와닿지 않을 것이다. 일단은 이해를 돕기 위해 친숙한 코딩에서 예시를 찾아보겠다. 이전 프로젝트에서 express.js를 통해 서버를 만들었을 때, 우리가 어떻게 API를 구성했는지 떠올려보자. 클라이언트가 특정 엔드포인트(URI 또는 경로)로 특정 HTTP 요청 메서드(GET, POST 등)를 보낼 때, 서버가 어떻게 응답할지 코드를 작성해왔을 것이다.

즉, 클라이언트가 특정 자원을 서버에 요청하는 것을 특정 경로('/api')를 통해 가능하도록 라우팅해주었던 것이다. 이렇게 최적의 경로를 설정하는 프로세스를 라우팅이라고 부른다.

네트워크 계층에서의 라우터와 라우팅

다시 네트워크 통신으로 돌아와서 라우터와 라우팅에 대해 설명하겠다.

라우터의 역할 (네트워크 계층):

• 라우터는 IP 주소를 기반으로 목적지 네트워크를 식별하고 경로를 설정하는 장치이다.
• IP 패킷을 보고 네트워크 ID를 기준으로 적절한 다음 네트워크로 데이터를 전달한다.
• 라우터는 호스트가 속한 네트워크 ID까지만 데이터를 전달하고, 네트워크 내에서의 전달은 데이터 링크 계층이 처리한다.

스위치와 호스트의 역할 (데이터 링크 계층):

• 목적지 네트워크에 도착하면 스위치는 목적지 MAC 주소를 기반으로 적절한 호스트로 프레임을 전달한다.
• 네트워크에 있는 각 호스트는 자신의 MAC 주소를 확인하고 프레임을 처리한다.
• 만약 MAC 주소가 일치하지 않으면 해당 프레임은 폐기된다.(물론 프레임 학습도 가능하다.)

이때, 데이터 패킷을 전송하기 위한 가장 좋고 안전한 경로를 찾기 위해 수많은 라우팅 방식이 사용된다. 링크 상태 라우팅, 거리 벡터 라우팅 등과 같은 다양한 라우팅 알고리즘이 최상의 경로를 결정하는 데 사용된다.

정적 라우팅

정적(Static)이라는 단어에서부터 알 수 있듯이, 정적 라우팅은 네트워크 관리자가 수동으로 경로를 설정하는 방식이다. 패킷이 목적지 네트워크에 도달하기 위한 경로를 미리 정의한다. 경로가 고정되어 있어 예측 가능하고, 제어가 쉬운 편이다.
다만, 네트워크 변화(예: 링크 장애)가 발생하면 수동으로 수정해야 한다.

동적 라우팅

반대로 동적 라우티은 라우터가 라우팅 프로토콜을 사용해 네트워크 상태를 실시간으로 학습하고, 최적의 경로를 자동으로 설정하는 방식이다. 경로를 수동으로 설정하지 않아도 된다는 건, 그만큼 대규모 네트워크에 적합하다는 뜻이 된다. 네트워크에 변화가 생기더라도 직접 수정할 필요가 없기 때문에 효율적인 방식이다.

그러나 라우팅 프로토콜 실행으로 인해 라우터의 CPU와 메모리를 더 많이 사용하며, 설정과 관리가 정적 라우팅보다 복잡하다는 단점을 가지고 있다.

라우팅 프로토콜

동적 라우팅은 사용하는 라우팅 프로토콜에 따라 거리 벡터 라우팅(Distance Vector Routing), 링크 상태 라우팅(Link State Routing), 하이브리드 라우팅(Hybrid Routing) 으로 나뉜다.

1. 거리 벡터 라우팅(Distance Vector Routing)

기본 개념:

• 거리와 방향(Next Hop)을 기준으로 경로를 계산한다.
• 각 라우터는 이웃 라우터로부터 받은 정보를 이용해 자신의 라우팅 테이블을 업데이트한다.

작동 방식:

• 라우터는 자신의 라우팅 테이블을 주기적으로 인접한 라우터와 공유한다.
• 각 경로는 "목적지까지의 거리(홉 수)"로 평가되며, 가장 짧은 거리를 가진 경로를 선택한다.
  • 예: 네트워크 A에서 B까지 3개의 라우터를 거쳐야 한다면, 홉 수는 3이다.

장점:

• 설정이 간단하고 소규모 네트워크에서 효과적이다.

단점:

1. 수렴 속도(네트워크 상태 변화 후 업데이트 완료까지 걸리는 시간)가 느리다.
2. 라우팅 루프 문제가 발생할 수 있다.
   • 루프: 데이터가 같은 경로를 반복해서 도는 현상.
3. 홉 수 제한(예: RIP에서는 최대 15홉까지만 허용).

예시 프로토콜:

• RIP (Routing Information Protocol):
  • 30초마다 라우팅 테이블을 이웃 라우터와 교환한다.
  • 단순하지만 홉 수 제한(15홉)으로 인해 대규모 네트워크에는 적합하지 않다.

비유:
거리 벡터 라우팅은 "내가 목적지까지 몇 번의 신호등을 지나야 하는지 알려줄게"라는 개념이다. 가까운 이웃들로부터 정보를 받아, "신호등 수가 가장 적은 경로"를 선택하는 방식이다.

2. 링크 상태 라우팅(Link State Routing)

기본 개념:

• 네트워크의 전체 구조(모든 링크 상태)를 이해하고, 최적 경로를 계산한다.
• 각 라우터는 전체 네트워크 지도를 가진 상태에서 최적 경로를 독립적으로 계산한다.

작동 방식:

1. 라우터는 자신과 연결된 네트워크 상태를 확인한다(예: 대역폭, 링크 가용성 등).
2. 링크 상태 정보를 모든 라우터에 브로드캐스트(LSA: Link State Advertisement).
3. 다익스트라 알고리즘을 사용해 최단 경로 트리(Shortest Path Tree) 를 계산하여 라우팅 테이블을 생성한다.

장점:

1. 빠른 수렴 속도:
   • 네트워크 상태가 변경되면 즉시 반영된다.
2. 안정적:
   • 라우팅 루프 문제가 발생하지 않는다.

단점:

1. 라우터의 CPU와 메모리 리소스를 더 많이 사용한다.
2. 초기 설정이 복잡하다.

예시 프로토콜:

• OSPF (Open Shortest Path First):
  • 대규모 네트워크에서 널리 사용된다.
  • 영역(Area)으로 네트워크를 나눠 관리 효율성을 높인다.

비유: 
링크 상태 라우팅은 "내가 지도를 가지고 있으니 목적지까지 가는 최단 경로를 계산할게"라는 방식이다. 모든 라우터가 같은 지도를 보며 경로를 계산하기 때문에, "길이 막혀도 가장 빠른 길"을 찾아낸다.

3. 하이브리드 라우팅(Hybrid Routing)

기본 개념:

• 거리 벡터와 링크 상태 라우팅의 장점을 결합한 방식이다.
• 네트워크 크기와 성능을 고려해 두 방식의 특성을 조합한다.

작동 방식:

• 거리 벡터 방식을 사용해 기본 경로를 계산하면서도,
• 링크 상태 정보를 참고해 네트워크 상태에 따라 경로를 최적화한다.

장점:

1. 빠른 경로 계산과 효율적인 리소스 사용.
2. 대규모 네트워크에서도 높은 확장성과 안정성을 제공.

단점:

• 복잡한 설정과 높은 학습 곡선.

예시 프로토콜:

• EIGRP (Enhanced Interior Gateway Routing Protocol):
  • Cisco에서 개발한 프로토콜.
  • 빠른 수렴 속도와 낮은 네트워크 리소스 사용이 특징이다.

비유:
하이브리드 라우팅은 "내가 가까운 경로도 참고하고, 지도의 정보를 활용해서 최적의 경로를 만들어볼게"라는 방식이다. 거리 벡터 방식의 간편함과 링크 상태 방식의 정확성을 결합한 접근이다.

전체 비교

특징	거리 벡터 라우팅	링크 상태 라우팅	하이브리드 라우팅
정보 기준	이웃 라우터로부터 받은 거리 정보	네트워크 전체 링크 상태 정보	거리 정보와 링크 상태 정보를 결합
라우팅 테이블 갱신	주기적 업데이트	변경 사항 발생 시 업데이트	필요 시 업데이트
수렴 속도	느림	빠름	매우 빠름
라우팅 루프	발생 가능	발생하지 않음	발생하지 않음
리소스 소모	낮음	높음	중간
예시 프로토콜	RIP	OSPF	EIGRP

 

---

번외) 브라우저에 네이버 주소를 입력했을 때 네트워크 상에서 발생하는 과정

앞선 글을 모두 읽었다면 IP와 네트워크 통신에 대해 어느 정도 이해하게 되었으리라. 그렇다면 우리가 실제 응용 계층에서 요청을 보냈을 때 어떤 일이 일어나는지 알아보도록 하자.

대표적인 예시 중 하나를 골라보자면, 웹 브라우저에서 어떤 사이트(이 글에서는 네이버)의 주소를 입력했을 때 네트워크 통신이 발생하는 일련의 과정들을 살펴보는 게 좋을 것 같다.

 

일단 '주소'라는 단어를 보자마자 우리는 이것이 IP주소일 것이라고 짐작할 수 있을 것이다. 이름부터 Internet Protocol의 약자이니 말이다. 그렇다면 IP 주소를 웹 브라우저에 입력한다는 건 어떤 의미일까. 이에 답하기 위해선 "웹"이란 것을 정확히 알 필요가 있다.

웹이란?

인터넷(전 세계 네트워크를 연결하는 물리적이며 논리적인 인프라) 위에서 작동하는 정보 공유 시스템이다. HTTP/HTTPS 프로토콜을 통해 정보를 요청하고 응답하는 애플리케이션 레벨(응용 계층)의 서비스이다. 그리고 IP 주소는 인터넷 세상의 식별자로서 데이터 공유를 위한 라우팅의 경로가 되어준다.

 

하지만 다른 통신 기기와 데이터를 주고 받기 위해 해당 기기의 IP주소를 외우고 다니는 건 상당히 난감한 일일 것이다. 가족이 아니고서야 전화번호를 외우는 일이 잘 없듯이, 네이버의 IP주소를 외우고 다니는 건 더 하고 싶지 않은 일이다.

그래서 우리는 도메인 주소를 사용한다.

도메인

도메인이란, 사람이 쉽게 외울 수 있도록 IP주소를 어떠한 문자로 표현한 것을 의미한다. 우리는 네이버 사이트의 IP를 주소창에 입력하는 대신 naver.com을 사용해도 같은 결과를 얻어낼 수 있는 이유는, 도메인을 다시 IP 주소로 변환하는 DNS 서버가 인터넷 인프라로서 작동하고 있기 때문이다.

우리의 웹 브라우저는 "네이버 메인 페이지 데이터를 달라"고 HTTP 요청을 보내게 되는데, 그 이전에! 해야할 일이 하나 있다. 네이버 웹 서버와 TCP 연결을 하는 것이다.(굳이 연결을 해야하는 이유는 TCP가 HTTP의 기반 프로토콜이고, 연결지향성 프로토콜이기 때문에 그렇다.)

이 과정을 3-Way Handshake라고 한다.

• SYN (Synchronize):
  => 클라이언트(브라우저)가 서버에 연결 요청을 보낸다.
• SYN-ACK (Synchronize-Acknowledge):
  => 서버가 요청을 받아들이고, 응답 메시지를 보낸다.
• ACK (Acknowledge):
  => 클라이언트가 서버의 응답을 확인하며 연결이 완료된다.

TCP 연결이 완료되면, 브라우저는 HTTP(S) 요청을 통해 네이버 서버에 정보를 요청한다.(HTTPS 프로토콜을 사용하는 경우, TLS/SSL 핸드셰이크를 이용해서 HTTPS라면 보안 채널을 설정하고 HTTP 요청이 암호화된 상태로 전송된다.)

 

이제 웹 브라우저의 HTTP(S) 요청은 하위 네트워크 계층을 통해 비트 단위로 전송되고, 네이버 웹 서버는 이 데이터를 추출하고 다시 복원해서 브라우저의 요청을 처리하게 된다. 그리고 HTTP(S) 응답을 패킷이 왔던 방식 그대로 돌려보내준다.(이 경우엔 메인 페이지 데이터)

 

브라우저에 도착한 Response는 각종 파싱과 렌더링 과정을 거쳐서 브라우저에 나타나고, 최종적으로 네이버 메인 페이지의 화면을 완성한다.