[네트워크] 네트워크 계층 - IP

data_buddha·2024년 11월 2일
0

네트워크 계층

  • 물리 계층, 데이터 링크 계층 이후의 네트워크 계층
  • LAN을 넘어서 다른 네트워크와 통신을 주고 받기 위한 기술
  • 네트워크 계층의 핵심 프로토콜 IP

IP의 목적과 특징

  • IP의 목적

    • 주소 지정
    • 단편화
  • IP의 특징

    • 신뢰할 수 없는 통신
    • 비연결형 통신

IP의 목적: 주소지정, 단편화

주소지정

  • 주소 지정은 IP 주소를 통해 이루어짐
  • IP 패킷 헤더에 있는 관련 필드: 송신지, 수신지 IP 주소
  • IP 패킷을 전달하는 네트워크 장비: 라우터
    • 네트워크 계층의 핵심 장비
    • 전달받은 패킷을 목적지까지 전달하는 역할
    • 라우팅: 전달할 최적의 경로를 결정하고 해당 경로로 패킷을 보내는 과정

단편화

  • MTU : 최대 전송 단위
  • 전송하고자 하는 IP 패킷의 단위가 MTU를 초과할 경우, MTU 이하의 여러 패킷으로 쪼개어 전송
  • 쪼개진 패킷은 수신지에서 재조합
  • IP 패킷 헤더에 있는 관련 필드: 식별자, 플래그, 단편화 오프셋
    • 식별자: 특정 패킷이 어떤 데이터에서 쪼개진 패킷인지 식별하기 위해 사용되는 필드, 같은 패킷에서 쪼개진 패킷은 같은 식별자를 가지고 있음
    • 플래그: 3비트로 구성, 첫 번째 비트는 0으로 고정, DF(Don't Fragment), MF(More Fragment)로 단편화의 상태 여부를 표시
    • 단편화 오프셋: 특정 패킷이 초기 데이터에서 얼마나 떨어져 있는지를 명시한 필드, 목적지에서 재조합하기 위해 올바른 순서를 나타냄
  • 오늘날에는 단편화가 발생하지 않음
    • 단편화는 네트워크에 악영향을 끼칠 수 있음
    • 패킷을 주고 받는 경로에 있는 모든 호스트들의 처리 가능한 MTU 크기를 고려
    • 이를 "경로 MTU"라고 함
    • 경로 MTU만큼 IP 패킷을 송수신하여 단편화를 회피

IP의 특징: 신뢰할 수 없는, 비연결형 통신

  • 신뢰할 수 없는 프로토콜: 패킷이 수신지까지 제대로 전송되었다고 보장하지 않는 프로토콜
    • 패킷이 유실되거나 순서가 맞지 않더라도 이에 대한 조치 x
  • 비연결형 프로토콜: 패킷을 주고받기 전에 사전 연결 과정을 거치지 않음
    • 상대 호스트의 수신 가능 여부는 따지지 않고, 수신지를 향해 그저 패킷을 전송할 뿐

IP주소의 구조

  • IP주소는 "네트워크 주소"와 "호스트 주소"로 이루어짐
  • 중요한 점은 하나의 IP주소에서 네트워크 주소와 호스트 주소를 표현하는 "크기"가 "유동적"일 수 있다는 점

클래스풀 주소 체계

  • 크기가 유동적일 수 있다면 어느정도의 크기가 적당할까? 이를 위해 생겨난 개념 "클래스풀 주소 체계"
  • 클래스 : 네트워크 주소의 크기에 따라 유형별로 IP주소를 분류하는 기준
  • 이 클래스를 바탕으로 IP주소를 관리하는 주소 체계를 "클래스풀 주소 체계"라고 함
  • 호스트의 주소가 전부 0인 주소와 전부 1인 주소는 특정 호스트를 지칭할 수 없음
    • 호스트 주소가 전부 0 : 해당 네트워크 자체를 의미하는 주소
    • 호스트 주소가 전부 1 : 브로드캐스트를 위한 주소
  • 특수한 목적을 위해 예약된 IP주소도 있음
    • 대표적인 예시로 "루프백 주소" : 자기 자신을 가르키는 주소
    • 일반적인 루프백 주소는 "127.0.0.1"으로 "로컬 호스트"라고도 불림
    • 루프백 주소로 전송된 패킷은 자기 자신에게 돌아오기 때문에 자기 자신을 마치 다른 호스트처럼 간주하여 패킷을 전송할 수 있음

클래스리스 주소 체계와 서브넷 마스크

  • 클래스풀 주소 체계의 단점 : IP주소가 낭비될 수 있음
    • 더 유동적으로 네트워크 영역을 나눌 수단이 필요 -> "클래스리스 주소 체계"의 등장
  • 클래스리스 주소 체계에서, 네트워크와 호스트를 구분하는 수단으로 "서브넷 마스크" 사용
  • "서브넷 마스크"와 "IP주소"를 "비트AND연산"하여 "네트워크 주소"를 생성

공인 IP주소와 사설 IP주소

  • 고유한 IP주소는 공인 IP주소
    • 공인 IP주소는 ISP나 IP주소 할당 기관을 통해 할당
  • 고유하지 않은 IP주소는 사설 IP주소
    • 라우터(공유기)를 통해 할당
    • 해당 호스트가 속한 네트워크에서만 고유함
    • 다른 네트워크의 사설 IP주소와 중복될 수 있음

IP주소의 할당

정적할당

  • 수작업으로 IP주소 할당
  • 게이트웨이 : 서로 다른 네트워크를 연결하는 하드웨어적/소프트웨어적 수단을 의미
    • 기본 게이트웨이 : 호스트가 속한 네트워크의 외부로 나가기 위한 첫 기본 경로를 의미
  • DNS : 호스트가 도메인 네임을 토대로IP 주소를 알아내기 위해 질의하는 것
  • 도메인 네임 : 숫자열로 이루어진 IP주소를 외우긴 어려우므로, 기억할 수 있는 문자열로 대응된 것

동적할당

  • 프로토콜을 통해 자동으로 IP주소를 부여하는 방식 -> 동적 IP주소 생성
    • DHCP 프로토콜을 사용
  • IP 주소를 동적으로 할당받고자 하는 호스트는 DHCP서버와 메시지를 주고 받으며 동적 IP주소를 할당
  • DHCP서버는 호스트에 할당 가능한 IP주소 목록을 관리하다가, IP주소 할당 요청을 받았을 때, IP주소를 할당해 주는 호스트
    • 동적 IP주소에는 사용 가능 기간이 정해져 있음
    • 동적 IP주소는 할당받을 때마다 다른 주소를 받을 수 있음

IP 전송 특징의 보완: ICMP

  • IP가 비신뢰성, 비연결성이라고 해서 반드시 나쁠까? NO
  • IP가 이러한 특징을 지니는 이유는 성능과 관련있음
    • 신뢰성 높은 송수신을 위해선, 패킷에 대한 오류 제어(패킷의 순서, 패킷의 유실 보장)를 수행해야 함
    • 연결형 송수신을 위해선, 호스트 간 연결을 수립하고, 연결을 관리해야 함
    • 오류 제어와 연결수립 및 관리는 빠른 성능과는 배치됨
  • 그럼에도 불구하고 IP의 특징을 보완하기 위한 방법에는 크게 2가지가 존재
    1. 신뢰할 수 있는 연결형 통신을 위한 상위 계층의 프로토콜을 이용하는 것 : 대표적으로 TCP
    2. 네트워크 계층의 "ICMP 프로토콜"을 이용하는 것
  • ICMP 프로토콜
    • IP 패킷의 전송 과정에 대한 피드백 메시지(ICMP 메시지)를 얻기 위해 사용하는 프로토콜
    • ICMP메시지로 IP 전송의 결과를 볼 수 있음
    • ICMP가 IP의 신뢰성을 완전히 보장하지 않음! 완전히 보장하기 전송 계층의 프로토콜이 필요
  • IP 헤더에는 패킷의 수명을 의미하는 TTL필드가 존재
    • 패킷이 하나의 라우터를 거칠 때마다 TTL이 1씩 감소
    • TTL이 0이되면 해당 패킷은 폐기 -> 패킷을 송신한 호스트에게 ICMP 메시지 전송
    • 패킷이 호스트 또는 라우터에게 한 번 전달되는 것은 "홉"이라고 함
    • TTL 필드의 존재 이유는 무의미한 패킷이 네트워크 상에 지속적으로 남아있는 것을 방지하기 위함

IP주소와 MAC 주소의 대응: ARP

  • MAC 주소 : 택배 배송의 송신인과 수신인
  • IP 주소 : 택배 배송의 송신지와 발신지
  • 패킷 송수신 과정에서 IP주소가 우선적으로 활용
  • 상대 호스트의 IP 주소는 알고, MAC 주소는 모르는 상황이 있을 수 있음
    • 이 때 사용되는 것이 "ARP 프로토콜"
  • ARP 프로토콜 : 동일 네트워크에 있는 송수신 대상의 IP주소를 통해 MAC 주소를 알아내는 것
  • ARP 동작 과정
    • ARP 요청은 "브로드캐스트 메시지" : 네트워크 내에 있는 모든 호스트에게 보내는 메시지
    • ARP 요청에는 알고 싶은 MAC주소와 대응되는 IP주소가 포함되어 있음
    • 전달받은 메시지를 받은 호스트들은 ARP 요청에 포함된 IP주소를 확인해 관련이 없으면 무시하고, 자신의 IP주소일 경우에는 ARP 응답 메시지에 MAC주소를 포함시켜 전송
  • ARP 테이블에 <IP주소,MAC주소> 쌍을 보관해놓음
profile
来日方长 : 앞길이 구만리 같다; 앞길이 희망차다. 장래의 기회가 많다.

0개의 댓글