2025-11-11

오늘 배운 것

03-1 LAN을 넘어서는 네트워크 계층

  • 네트워크 계층
    • IP 주소를 이용해 송수신지 대상을 지정
    • 다른 네트워크에 이르는 경로는 결정하는 라우팅을 통해 다른 네트워크와 통신

데이터 링크 계층의 한계

  1. 물리 계층과 데이터 링크 계층만으로는 다른 네트워크까지의 도달 경로를 파악하기 어려움
    • 물리 계층과 데이터 링크 계층은 기본적으로 LAN을 다루는 계층
    • 하지만 LAN에 속한 호스트끼리만 통신하는 것은 아님 → 라우팅이 필요
    • 라우팅
      • 패킷이 이동할 최적의 경로 결정 → 네트워크 계층의 라우터가 담당
  2. MAC 주소만으로는 모든 네트워크에 속한 호스트의 위치를 특정하기 어려움
    • 모든 호스트가 모든 네트워크에 속한 모든 호스트의 MAC 주소를 서로 알고 있기 어려움 → IP 주소 필요
    • IP 주소
      • 네트워크 계층의 논리주소
      • MAC주소는 NIC 마다 할당되는 고정된 주소
      • IP 주소는 DHCP라는 특정 프로토콜을 통해 자동 할당 OR 수동 할당가능
      • 한 호스트가 복수의 IP 주소를 가질 수 있음

인터넷 프로토콜

  • 네트워크 계층의 가장 핵심적인 프로토콜 : IPv4, IPv6

IP 주소 형태(IPv4)

  • 4바이트
  • 숫자당 8비트로 표현 → 0 ~ 255 범위 안에 있는 4개의 10진수로 표기
  • 옥텟 : 점으로 구분된 8비트

IP의 기능

  1. IP 주소 지정 : IP 주소를 바탕으로 송수신 대상 지정
  2. IP 단편화 : 전송 패킷의 크기가 MTU라는 최대 전송 단위보다 클 경우, 이를 MTU 크기 이항의 복수의 패킷으로 나누는 것을 의미
    1. MTU(Minimum Transmission Unit)
      1. 한 번에 전송 가능한 IP 패킷의 최대 크기
      2. IP 패킷의 헤더도 MTU 크기에 포함
      3. 일반적으로 1500 바이트
      4. 나누어진 패킷은 수신지에서 다시 재조합

IPv4

  • 프레임의 페이로드로 데이터 필드에 명시됨

스크린샷 2025-11-10 오후 10.46.54.png

  1. 식별자
    1. 패킷에 할당된 번호
    2. 어떤 메시지에서부터 쪼개졌는지 인식하기 위해서 식별자 사용
  2. 플래그
    1. 총 3개의 비트
    2. 첫번째 비트 : 항상 0으로 예약된 비트 (현재는 사용 x)
    3. DF(Don’t Fragement) : IP 단편화 수행 x
      1. 1 : IP 단편화 불가
        • 1로 설정되어도 패킷의 크기가 너무 크면 폐기됨
      2. 0 : IP 단편화 가능
    4. MF(More Fragment) : 단편화된 패킷이 더 있는지 여부
      1. 1 : 아직 쪼개진 패킷이 남음
      2. 0 : 이 패킷이 마지막 패킷
  3. 단편화 오프셋
    1. 단편화되기 전에 패킷의 초기 데이터에서 몇 번째로 떨어진 패킷인지
    2. 순서대로 도착하지 않은 단편화된 패킷들 재조합 용도로 활용
  4. TTL(Time To Live)
    1. 패킷의 수명
    2. 홉 마다 1씩 감소
      1. 홉 : 패킷이 호스트 또는 라우터에 한 번 전달 되는 것
    3. 무의미한 패킷이 네트워크상에 지속적으로 남아 있는 것 방지
    4. 0이 되면 해당 패킷 폐기 후 송신 호스트에게 시간 초과(Time Exceeded) 메시지 전송
      1. ICMP 프로토콜의 역할
  5. 프로토콜
    1. 상위 계층의 프로토콜이 무엇인지 나타냄
    2. TCP : 6
    3. UDP : 17
  6. 송신지 IP 주소 & 수신지 IP 주소
    1. 송수신지의 IPv4 주소
      • IP 단편화 & 재조합 → 식별자, 플래그, 단편화 오프셋
      • 상위 계층 프로토콜 → 프로토콜 필드
      • 남은 수명 → TTL
      • IP 주소 지정 - 송수신지 IP 주소

IPv6

  • IPv4 주소는 총 2^32개로 약 43억개 ⇒ 부족
  • 이를 해결하기 위해 등장한 주소 체계
  • 16바이트

  • 콜론으로 구분된 8개 그룹의 16진수로 표기

    스크린샷 2025-11-10 오후 10.57.17.png

  1. 다음 헤더(next header)
    1. 상위 계층의 프로토콜을 가리키거나 확장 헤더를 가리킴
    2. IPv6는 기본 헤더 외에도 추가적인 헤더 정보가 필요한 경우 확장 헤더를 추가로 가질 수 있음
      1. 확장 헤더
        1. 기본 헤더와 페이로드 데이터 사이에 위치
        2. 예
          1. 홉 간 옵션 : 송신지에서 수신지에 이르는 모든 경로의 네트워크 장비가 패킷을 검사
          2. 수신지 옵션 : 수신지에서만 패킷을 검사
          3. 라우팅 : 라우팅 관련 정보 운반
          4. 단편 : 단편화
            1. IPv6에서는 단편화 관련 필드가 없고 이 확장헤더를 통해 단편화가 이루어짐
            2. 구성 : 다음 헤더 + 예약 필드 + 단편화 오프셋 + 예약 필드 + M + 식별자
            3. M : 1일 때 단편화된 패킷 남음 / 0일 때 마지막 패킷
            4. 식별자 : 동일 메시지에서 단편화된 패킷
          5. ESP(Encapsulation Security Protocol), AH(Authentication Header) : 암호화와 인증
  2. 홉 제한
    1. 패킷의 수명
  3. 송신지 IP 주소 & 수신지 IP 주소
    1. 송수신지 IPv6 주소
      • IPv4 헤더 길이는 가변적 ↔ IPv6 기본 헤더는 40 바이트로 고정

ARP

  • 상대의 호스트의 IP 주소는 알지만, MAC 주소는 알지 못하는 상황에서 사용하는 프로토콜
  • 동일 네트워크 내에 있는 송수신 대상의 IP 주소를 통해 MAC 주소 알아냄

1. ARP 요청

  • 네트워크 내의 모든 호스트에게 ARP 요청이라는 ARP 패킷을 브로드캐스트

2. ARP 응답

  • 응답을 받은 해당 호스트는 자신의 MAC 주소를 담은 ARP 응답이라는 ARP 패킷을 유니캐스트함
  • 나머지 응답을 받은 호스트는 자신에게 해당하는 메시지가 아님으로 폐기

3. ARP 테이블 갱신

  • ARP 를 활용할 수 있는 모든 호스트는 ARP 테이블 정보 유지
  • 1, 2단계를 통해 알게된 IP주소와 MAC 주소의 연관 관계를 ARP 테이블에 갱신
  • ARP 테이블은 일정 시간이 지나면 삭제 또는 임의 삭제도 가능
  • 이후 브로크 캐스트로 ARP 요청없이 바로 통신 가능
  • ARP 테이블은 ARP 캐시(테이블)이라고도 불림

ARP 패킷

스크린샷 2025-11-10 오후 11.11.00.png

  • 프레임의 페이로드에 포함되어 전송
  • 오퍼레이션 코드 : ARP 패킷의 유형
    • 1 : ARP 요청
    • 2 : ARP 응답
  • 송신지 하드웨어 주소 / 수신지 하드웨어 주소 : MAC 주소
    • ARP 요청시, 이더넷 프레임의 수신지 MAC 주소에는 브로드 캐스트 메시지임을 나타내는 ff:ff:ff:ff:ff:ff:ff:ff, 수신지 하드웨어 주소에는 00:00:00:00:00:00:00:00 명시
  • 송신지 프로토콜 주소 / 수신지 프로토콜 주소 : IP 주소

외부 네트워크 호스트에게 통신할 때는? A → B

  • 호스트 A는 라우터 A와 ARP
  • 라우터 A는 라우터 B와 ARP
  • 라우터 B는 호스트 B와 ARP
  • 이건 간략화된 예시이고 실제 라우터간 통신에서는 ARP만 사용하지는 않음

03-2 IP 주소

  • IP 주소 : 네트워크 주소 + 호스트 주소
  • 네트워크 주소 : 호스트가 속한 특정 네트워크 식별
  • 호스트 주소 : 네트워크 내에서 특정 호스트 식별

네트워크 주소와 호스트 주소

  • 네트워크주소 = 네트워크 ID = 네트워크 식별자
  • 호스트 주소 = 호스트 ID = 호스트 식별자
  • 네트워크 주소와 호스트 주소를 구분하는 범위는 유동적
    • 네트워크 주소 많이 할당 ⇒ 호스트 주소 부족
    • 호스트 주소 많이 할당 ⇒ IP 주소 낭비
    • 해결책 ⇒ 클래스

클래스풀 주소 체계

  • 클래스 : 네트워크 크기에 따라 IP 주소를 분류하는 기준
    • 총 5개 : A, B, C, D, E
      • D는 멀티캐스트, E는 특수 목적을 위한 예약 클래스로 제외되고 A, B, C만 실질적으로 사용
  • 클래스풀 주소 체계 : 클래스를 기반으로 IP 주소를 관리
    • A
      • 네트워크 주소
        • 0으로 시작
        • 1옥텟
      • 호스트 주소
        • 3옥텟
      • 0.0.0.0 ~ 127.255.255.255
    • B
      • 네트워크 주소
        • 10으로 시작
        • 2옥텟
      • 호스트 주소
        • 2옥텟
      • 128.0.0.0 ~ 191.255.255.255
    • C
      • 네트워크 주소
        • 110으로 시작
        • 3옥텟
      • 호스트 주소
        • 1옥텟
      • 192.0.0.0 ~ 223.255.255.255
    • 단, A, B, C 모두 호스트 주소가 전부 0(해당 네트워크 자체를 의미)이거나 전부 1(브로드캐스트)인 주소는 사용 불가

클래스리스 주소 체계

  • 클래스풀 주소 체계의 한계
    • 클래스별 네트워크의 크기가 고정되어 있기에 여전히 다수의 IP 주소 낭비
      • 예
        • 단일 조직이 300명 정도일 때 C 클래스는 IP주소가 최대 254개이기 때문에 B클래스를 사용해야되는데 이렇게 되면 낭비가 심해짐
  • 클래스리스 주소 체계
    • 클래스에 구애받지 않고 네트워크의 영역을 나누어서 호스트에게 IP 주소 공간을 할당하는 방식

서브넷 마스크

  • 클래스리스 주소 체계에서 네트워크와 호스트를 구분 짓는 수단
  • 네트워크 주소는 1, 호스트 주소는 0으로 표기한 비트열
  • 서브네팅 : 클래스를 원하는 크기로 더 잘게 쪼개어 사용하는 것

서브네팅: 비트 AND 연산

  • 서브넷 마스크를 이용해 네트워크 주소와 호스트 주소를 구분 짓는 방법 ⇒ IP 주소와 서브넷 마스크를 비트 AND 연산

서브넷 마스크 표기: CIDR

  • IP 주소/서브넷 마스크상의 1의 개수로 표기하는 형식
  • 예 : 192.168.219.103/24

공인 IP 주소와 사설 IP 주소

  • 전세계에는 고유한 IP 주소와 고유하지 않은 IP 주소가 있음

공인 IP 주소

  • 전세계에서 고유한 IP 주소
  • 네트워크 간의 통신시 사용하는 주소
  • ISP나 공인 IP 주소 할당 기관에서 할당

사설 IP 주소와 NAT

  • 사설 네트워크에서 사용하기 위한 IP 주소
    • 사설 네트워크 : 인터넷이나 외부 네트워크에 공개되지 않은 네트워크
  • 모든 네트워크 기기의 IP 주소를 별도로 신청하지 않아도 되는 이유 → 사설 IP 주소를 사용하기 때문
  • 사설 IP 주소 용도로 예약된 주소 공간
    • 10.0.0.0/8
    • 172.16.0.0/12
    • 192.168.0.0/16
  • 라우터 : 사설 IP 주소의 할당 주체
  • 할당 받은 사설 IP 주소는 해당 호스트가 속한 사설 네트워크상에서만 유효
    • 외부 사설 IP 주소와 중복 가능
  • NAT
    • 사설 IP주소와 외부에서 사용되는 공인 IP 주소를 변환하는 기술
    • 대부분의 라우터와 공유기는 해당 기능을 내장

정적 IP 주소와 동적 IP 주소

정적 할당

  • 직접 수작업으로 IP 주소를 부여
  • 정적할당으로 부여된 주소 = 정적 IP 주소

동적 할당과 DHCP

  • 동적 할당 : 수작업 없이 호스트에 IP 주소가 동적으로 할당되는 방식
  • 동적할당으로 부여된 주소 = 동적 IP 주소
  • 장점
    • 호스트 수가 많아져도 관리 용이
    • 잘못되거나 중복되는 IP 주소 입력의 위험성 제거
  • DHCP(Dynamic Host Configuration Protocol)
    • 응용계층의 IP 동적할당에 사용되는 프로토콜
    • IPv4 → DHCPv4, IPv6 → DHVPv6
    • IP 주소를 할당받고자 하는 호스트와 해당 호스트에게 IP 주소를 제공하는 DHCP 서버간에 메시지를 주고받는 과정으로 할당이 이루어짐
    • 일반적으로 라우터가 DHCP 서버의 역할을 수행하고, 특정 호스트에 DHCP 서버 기능을 추가할 수도 있음
    • DHCP 서버는 클라이언트에게 할당 가능한 IP 주소 목록을 관리하다가 클라이언트가 요청할 때 IP 주소를 할당
    • DHCP로 할당받은 IP 주소는 사용할 기간이 정해져 있고 임대 기간이 끝나면 다시 DHCP 서버로 반납
    • 일반적으로 수시간 에서 수일
    • 할당 과정
      1. DHCP Discover(클라이언트 → DHCP 서버)
        • 클라이언트는 DHCP Discover 메시지를 브로드 캐스트하여 DHCP 서버를 전송
        • 이때 클라이언트는 아직 IP 할당이 안되어 송신지 IP 주소는 0.0.0.0
      2. DHCP Offer(DHCP 서버 → 클라이언트)
        • DHCP Discover 메시지를 응답받은 DHCP 서버는 IP 주소, 서브넷 마스크, 임대 기간 등의 정보가 포함된 DHCP Offer 메시지를 보냄
      3. DHCP Request(클라이언트 → DHCP 서버)
        • DHCP Offer 메시지를 응답 받은 클라이언트는 브로드 캐스트로 DHCP Request를 전송
      4. DHCP ACK(DHCP서버 → 클라이언트)
        • DHCP 서버는 DHCP ACK 메시지를 클라이언트에게 보내고 이 응답을 받은 클라이언트는 할당 받은 IP 주소를 사용
    • IP 주소 사용 기간이 끝나면 반납 뒤에 할당과정을 다시 해야하지만 임대 갱신을 통해 연장할 수 있음
      • 임대 갱신 : 임대 기간이 끝나기 전에 임대 기간 연장
        • 기본적으로 두 차례 자동 수행
        • 모두 실패 시 IP 주소 DHCP 서버로 반납

03-3 라우팅

  • 라우팅 : 패킷이 이동할 최적의 경로를 설정한 뒤 해당 경로로 패킷을 이동시키는 것

라우터

  • 네트워크 계층의 장비
    • L3 스위치라는 네트워크 계층의 장비 이지만 오늘날 라우터와 L3 스위치는 기능상 상당 부분 유사하여 엄밀히 구분하지 않음

라우팅 테이블

  • 특정 수신지까지 도달하기 위한 정보를 명시한 일종의 표와 같은 정보
  • 라우팅 테이블에 포함되는 정보는 라우팅 방식이나 호스팅 환경에 따라 달라질 수 있음
  • 공통적으로 가지고 있는 핵심 정보
    • 수신지 IP 주소 & 서브넷 마스크 : 최종적으로 패킷을 전달할 대상
    • 다음 홉(=게이트웨이) : 최종 수신지까지 가기 위해 다음으로 거쳐야 할 호스트의 IP 주소나 인터페이스
    • 네트워크 인터페이스 : 패킷을 내보낼 통로
      • 인터페이스(NIC) 이름이나 대응하는 IP 주소 명시
    • 메트릭 : 해당 경로로 이동하는 데에 드는 비용
      • 메트릭이 낮은 경로를 선호
  • 디폴트 라우트는 기본적으로 패킷을 내보낼 경로
  • 기본 게이트는 호스트가 속한 네트워크 외부로 나아가기 위한 첫번 째 경로
  • 일반적으로 기본 게이트 웨이가 디폴트 라우트

정적 라우팅과 동적 라우팅

정적 라우팅

  • 사용자가 수동으로 직접 채워 넣은 라우팅 테이블의 항목을 토대로 라우팅 되는 방식

동적 라우팅

  • 자동으로 라우팅 테이블 항목을 만들고 이를 이용하여 라우팅 하는 방식
  • 수시로 라우팅 테이블 항목이 바뀔 수 있음
  • 동적 라우팅 프로토콜
    • 특정 수신지까지 도달하기 위한 최적의 경로를 찾아 라우팅 테이블에 추가하기 위해 라우터 끼리 서로 자신의 정보를 교환하는 과정에서 사용되는 프로토콜
  • 장점
    • 규모가 큰 네트워크 관리 용이
    • 입력 실수 방지
    • 경로상에 문제가 발생한 라우터 우회 가능

라우팅 프로토콜

  • 라우터끼리 자신들의 정보를 교환하며 패킷을 이동할 최적의 경로를 찾기 위한 프로토콜
  • AS 내부 → IGP(Interior Gateway Protocol), EGP(Exterior Gateway Protocol)

IGP: RIP와 OSPF

  • RIP(Routing Information Protocol)
    • 거리 벡터 기반의 라우팅 프로토콜
    • 거리는 패킷이 경유한 라우터의 수(홉수)
    • 인접한 라우터끼리 경로 정보를 주기적으로 교환하며 라우팅 테이블 갱신
    • 홉 수가 가장 적은 경로를 최적의 경로로 판단
      • 홉수가 작을 수록 메트릭도 작음
  • OSPF(Open Shortest Path First)
    • 링크 상태 라우팅 프로토콜
    • 링크 정보를 비롯한 현재 네트워크 상태를 그래프 형태로 링크 상태 데이터 베이스에 저장
      • 라우터들의 연결 관계, 연결 비용 등 저장됨
    • 링크 상태 데이터베이스를 기반으로 네트워크 구성을 마치 지도처럼 그린 뒤 최적의 경로 선택
    • 대역폭이 높을 수록 메트릭이 낮은 경로로 인식
    • 네트워크 구성이 변경되었을 때 라우팅 테이블 갱신
    • 네트워크 규모가 크면 갱신 시 모든 정보를 저장하기 어려움으로 에어리어 단위로 나눔
      • 에어리어
        • AS를 에어리어라는 단위로 나누고 구분된 에어리어 내에서만 링크 상태를 공유
        • ABR(Area Border Router) : 에어리어 경계에 있는 라우터로 에어리어 간의 연결을 담당

EGP: BGP

  • BGP(Border Gateway Protocol)
    • AS 간의 통신에서 사용되는 대표적인 프로토콜
      • AS 간의 통신 → eBGP(External BGP)
      • AS 내의 통신 → iBGP(internal BGP)
    • AS 간에 정보를 주고받기 위해서는 AS 내에서 eBGP를 사용하는 라우터가 하나 이상 있어야 하고 또 다른 AS의 eBGP 라우터와 연결되어야 함
    • 피어 : BGP 메시지를 주고받을 수 있도록 연결된 라우터
    • 피어링 : 다른 AS와의 BGP 연결을 유지하기 위해서 eBGP 라우터끼리 연결되는 과정
    • RIP나 OSPF와 달리 최적의 경로를 결정하는 과정이 복잡하고 일정하지 않음
      • 속성과 정책을 고려
        • 속성 : 경로에 대한 일종의 부가 정보
          • AS-PATH
            • 메시지가 수신지에 이르는 과정에서 통과하는 AS들의 목록
            • 메시지가 AS를 거칠 때마다 AS-PATH에 추가
            • 따라서!
              • BGP는 AS 간 라우팅을 할 때 거치게 될 라우터의 수가 아닌 AS의 수를 고려
                • AS-PATH의 길이가 짧아도 홉수는 더 많을 수 있음
              • BGP는 RIP처럼 단순히 수신지에 이르는 거리가 아닌 메시지가 어디를 거쳐 이동하는지를 나타내는 경로를 고려
                • BGP는 경로 벡터 라우팅 프로토콜의 일종
                • BGP는 AS-PATH의 자신의 AS가 포함되어 있으면 해당 메시지를 버림으로써 순환을 방지
          • NEXT-HOP
            • 다음으로 거칠 라우터(홉)의 IP 주소
          • LOCAL-PREF
            • 지역 선호도로 AS 외부 경로에 있어 AS 내부에서 어떤 경로를 선호할지에 대한 척도
            • AS-PATH나 NEXT-HOP속성보다 우선시됨
            • 값이 클수록 우선으로 선택
            • 따라서
              • 특정 정책에 따라서 경로가 결정됨
              • 예
                • 성능을 우선시 → 송수신 지연시간이 적고 대역폭이 높은 AS선택
                • 보안과 안정성 우선시 → 속도는 느리더라도 더 안전한 AS 선택

results matching ""

    No results matching ""