일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 코루틴 빌더
- JanusGateway
- 깡돼후
- addhooks
- JanusWebRTC
- python
- PersistenceContext
- Spring Batch
- tolerated
- kotlin
- Value too long for column
- 달인막창
- JanusWebRTCGateway
- mp4fpsmod
- pytest
- 개성국밥
- 헥사고날아키텍처 #육각형아키텍처 #유스케이스
- PytestPluginManager
- vfr video
- 오블완
- JanusWebRTCServer
- 자원부족
- table not found
- VARCHAR (1)
- 티스토리챌린지
- preemption #
- terminal
- 코루틴 컨텍스트
- taint
- 겨울 부산
너와 나의 스토리
[CH.4] Network Layer - IP(datagram format, IPv4 addressing) 본문
[CH.4] Network Layer - IP(datagram format, IPv4 addressing)
노는게제일좋아! 2019. 11. 14. 21:58The Internet network layer
- network layer - 3계층
- Routing protocol: 패킷이 목적지까지 가는 경로 결정 - static과 dynamic 프로토콜로 구분됨
- path selection - 다익스트라, 벨만 포드 등에서 선택
- RIP: Routing Information Protocol
- OSPF: Open Shortest Path First -> 최단 경로 우선 프로토콜
- BGP: Border Gateway Protocol -> 외부 라이팅 프로토콜
- 5계층 -> 4계층 -> 3계층 => 복잡성 낮아짐
- ICMP(Internet Control Message Protocol): 인터넷 제어 메시지 프로토콜
- 오류 메시지를 전송받는데 주로 쓰임(ping)
IP datagram format
- TTL - 라우팅 잘못하면 루프가 생길 수 있는데 TTL이 이를 방지한다.
- 라우터마다 1씩 감소하고 0이 되면 버려짐
- identifier, flags, fragment offset - IP fragment(단편화)와 관계있다.
- IP의 새로운 버전인 IPv6는 단편화를 허용하지 않는다.
- upper layer(protocol) - 일반적으로 IP 데이터그램이 최종 목적지에 도착했을 때만 사용되는 필드
- 이 필드 값은 IP 데이터그램에서 데이터 부분이 전달될 목적지의 전송 계층의 특정 프로토콜을 명시한다.\
- header checksum - 라우터가 수신한 IP 데이터그램의 비트 오류를 탐지하는데 도움을 줌
IP fragmentation, reassembly
- 모든 링크 계층 프로토콜이 같은 크기 네트워크 계층 패킷을 전달할 수 없다 -> 6장에서 배움
- 어떤 프로토콜은 큰 데이터그램 전달하는 반면 다른 프로토콜은 작은 것만 전달 가능
- MTU(Mszimum Transmission Unit): 링크 계층 프레임이 전달할 수 있는 최대 데이터의 양
- 링크 타입이 다르면 MTU도 다르다
- 각 IP 데이터그램은 한 라우터에서 다른 라우터로 전송하기 위해 링크 계층 프레임 내에 캡슐화되므로 링크 계층 프로토콜의 MTU는 IP 데이터 그램의 길이에 엄격한 제약을 둔다.
- 큰 IP 데이터그램을 net 내에서 분할한다(fragmented)
- 하나의 데이터그램이 여러 개의 데이터그램으로 나뉨
- 마지막 목적지에서만 "재조립(reassembled)"됨
- IP header bifs는 fragments의 순서와 identify 하기 위해 사용된다
- ex)
4000 = 3980+20(header)
1480(body)+20(header)
현재 보내야 할 내용은 1020byte 남았으므로 (1020+20)byte 보냄
fragflag는 마지막 데이터그램만 0으로 표시하여 내용 끝났음을 표시
IP addressing: introduction
- IP 주소: 32bit - 호스트와 라우터의 인터페이스 식별
- 호스트는 일반적으로 네트워크와 연결되는 하나의 링크를 가진다.
- 호스트 IP가 데이터그램을 보낼 때 이 링크를 통해 데이터 링크를 보낸다
- 호스트와 physical link 사이의 경계를 '인터페이스'라고 부른다.
- 라우터의 작업: 한 링크로부터 데이터그램을 수신하여 다른 링크로 전달하는 것
- 2개 이상의 연결된 링크가 필요
- 라우터와 이런 링크 사이의 경계 또한 인터페이스라고 함
- 모든 호스트와 라우터는 IP 데이터그램을 송수신할 수 있으므로 IP는 각 호스트와 라우터 인터페이스가 IP 주소를 갖도록 요구한다.
- 따라서 기술 면에서 IP 주소는 인터페이스를 포함하는 호스트 라우터보다는 인터페이스와 관련이 있다.
- IP 주소: 호스트를 identifier 할 32-bit
- 인터페이스의 IP 주소 일부는 연결된 '서브넷'이 결정
- 오른쪽 그림을 보면, 하나의 라우터가 7개의 호스트를 연결한다.
- 왼쪽 3개의 호스트와 연결된 라우터 인터페이스 모두 223.1.1.xxx 형식의 IP 주소를 갖는다.
- 즉 동일한 왼쪽 24비트를 사용한다.
- 또한 4개의 인터페이스가 중계하는 라우터 없이 하나의 네트워크에 서로 연결되어 있다.
- 이 네트워크는 이더넷 LAN으로 상호 연결되고 이 경우 인터페이스는 이더넷 허브나 이더넷 스위치 또는 무선 액세스 포인터로 상호 연결된다.
- 세 호스트들의 인터페이스들과 하나의 라우터 인터페이스로 연결된 네트워크는 서브넷을 구성한다고 말한다.
- IP 주소체계는 이 서브넷에 223.1.1.0/24라는 주소를 할당해주는데, 여기서 /24는 서브넷 마스크라 부르며 32비트 주소의 왼쪽 24비트가 서브넷 주소라는 것을 가리킨다.
- 왼쪽 3개의 호스트와 연결된 라우터 인터페이스 모두 223.1.1.xxx 형식의 IP 주소를 갖는다.
Network prefix and Host number
- network prefix는 네트워크 식별, host number는 특정 호스트를 식별(정확히는 네트워크의 인터페이스를 식별)
- network prefix가 얼마나 긴지 어떻게 알 수 있을까?
- 명시적인 정의를 사용한 network prefix (class bassed addressing, A,B,C,D...)
- IP 주소의 네트워크 부분을 8,16,24비트로 제한하고 각각을 A,B,C 클래스 네트워크로 분류
- network prefix를 유연하게 prefix/netmask로 나타냄. (classless)
- 명시적인 정의를 사용한 network prefix (class bassed addressing, A,B,C,D...)
- Classful IP Addresses의 문제
- 큰 네트워크에 비해 네트워크 주소가 너무 적음(부족)
- 2계층 구조는 클래스 A 및 클래스 B 주소가 있는 대규모 네트워크에는 적합하지 않음
- Fix #1: subnetting
- 호스트 ip 주소가 10,000개 필요한데, 클래스 C로는 부족해서 클래스 B를 할당 받으면,
- 클래스 B = 2^(32-16) =65,000
- 그럼 65000-10000개가 낭비됨
Subnets
- IP 주소:
- 서브넷 부분 - high order bits
- 호스트 부분 - low order bits
- subnet:
- IP 주소의 같은 서브넷 부분을 가지는 디바이스 인터페이스
- 서로 라우터의 개입 없이 물리적으로 접근 가능
- 서브넷: 서브넷을 결정하려면 먼저 호스트나 라우터에서 각 인터페이스를 분리하고 고립된 네트워크를 만든다. 이 고립된 네트워크의 종단점은 인터페이스의 끝이 된다. 이렇게 고립된 네트워크 각각을 서브넷이라고 부른다.
- 인터퍼이스의 IP 주소는 연결된 subnet이 결정한다.
Subnetting
- 문제: 조직에는 독립적으로 관리되는 여러 네트워크가 있다.
- solution 1. 각 네트워크 주소를 할당
- 관리 힘듦
- 조직 밖에서 각 네트워크로 addressable 해야 함
- 식별 가능한 identifiable address를 가져야 함
- solution 2. IP 주소 구조에 계층 추가 => subnetting
- solution 1. 각 네트워크 주소를 할당
Subnetting의 기본 아이디어
- IP 주소에서 호스트 넘버 부분을 subnet numnber와 host number로 나누자
- 서브넷은 조직 내에서 자유롭게 할당될 수 있음
- 내부적으로 서브넷은 분리된 네트워크로 다뤄진다
- 서브넷 구조는 조직 밖에서 볼 수 없다
Subnet Masks
- 라우터와 호스트는 호스트 넘버의 시작을 식별하기 위해 extended network prefix (subnet mask)를 가진다.
" /24 ": subnet mask
-> 32 bits 주소의 왼쪽 24bits가 서브넷 주소라는 것을 가리킴
Classful IP Address의 문제점 3
- 유연하지 못하다!
- 주소가 많이 필요하면 감당하지 못함
- Fix #2: Classless Interdomain Routing(CIDR)
CIDR - Classless Interdomain Routing
- 목표
- 효율성을 늘리도록 IP 주소를 재구성
- 라우터 테이블 엔트리를 최소화하기 위해 계층적으로 라우팅 집계
- 주요 개념: IP 주소의 네트워크 id(prefix)의 길이를 임의로/유연하게 네트워크 계층에 따라 정의하라
- 결과:
- 라우터는 포워딩을 위해 IP 주소와 prefix 길이를 사용한다
- 모든 advertised된 IP 주소는 prefix를 포함해야 한다.
- 예:
- 네트워크 주소의 CIDR notation: 192.0.2.0/18
- "18"은 첫 18bits가 주소의 네트워크 부분이라는 것을 말함
- 네트워크 부분을 네트워크 prefix라고 부름
- 어떤 사이트가 1000 IP 호스트 주소를 지원 가능한 IP network domain이 필요하다고 가정하자.
- CIDR을 사용하면, 네트워크는 1024 = $2^{10}$(>1000) 주소의 연속된 블락을 할당한다
- 32-10=22bit long prefix
- 네트워크 주소의 CIDR notation: 192.0.2.0/18
CIDR and Address assignments
- backbone ISPs는 IP 주소 공간의 큰 블락을 얻은 후 자신의 고객들에게 주소 블락의 일부분을 재할당한다.
- ex)
- ISP가 206.0.64.0/18 주소 블락을 소유한다고 가정하자. 16384($2^{32-18})$ IP 호스트 주소를 나타내는
- 고객이 800 호스트 주소를 요청한다면?
- 512=$2^{9}$<800<1024=$2^{10}$ -> 32-10 =22
- a/22 블락 할당. 예: 206.0.68.0/22 -> 고객에게1024($2^{10}$)개의 IP 주소 블락을 줌
IP addresses: 어떻게 얻을 수 있나?
- 어떻게 호스트는 IP 주소를 얻나?
- 한 기관은 ISP로부터 주소 블록을 획득하여, 개별 IP 주소를 기관 내부의 호스트와 라우터 인터페이스에 할당한다.
- 라우터 인터페이스 주소에 대해서, 시스템 관리자는 라우터 안에 IP 주소를 할당한다
- 호스트에 IP를 할당하는 것은 일반적으로 동적 호스트 구성 프로토콜(Dynamic Host Configuration Protocol, DHCP)을 더 많이 사용한다.
- 네트워크 관리자는 해당 호스트가 네트워크에 접속하고자 할 때마다 동일한 ip 주소를 받도록 하거나, 다른 임시 ip 주소를 할당하도록 DHCP를 설정한다.
- DHCP는 호스트 IP 주소의 할당뿐만 아니라, 서브넷 마스크, 첫 번째 홉 라우터 주소나 로컬 DNS 서버 주소 같은 추가 정보를 얻게 해 준다.
- 네트워크에서 자동으로 호스트와 연결해 주는 DHCP 능력 때문에 "plug and play"라고도 한다
정적 IP VS 동적 IP
- 정적 IP - 데스크탑처럼 항상 IP가 변하지 않음
- 장점: 정체성이 있음, 항상 들어올 수 있음
- 단점: 사용성이 떨어짐, 얼마 쓰지도 않으면서 계속 할당받고 있어야 함
- 동적 IP - 내가 가진 IP가 계속 바뀜
- 장점: cost 절약
- 단점: 고정적으로 데이터 받는 서비스 사용 불가
DHCP
- host broadcasts "DHCP 발견" 메시지 [optional] - 호스트가 DHCP 서버 발견 메시지 발송
- DHCP 서버는 "DHCP 제공" msg로 응답 [optional] -
- host는 "DHCP request" msg로 IP 주소 요청
- DHCP 서버는 "DHCP ack" msg로 주소 보냄
1. 새롭게 도착한 호스트는 상호 동작될 DHCP를 발견. 클라이언트는 포트 67번으로 UDP 패킷을 보낸다. UDP 패킷은 IP 데이터그램으로 캡슐화된다.
2. 클라이언트가 출발지 IP 주소 0.0.0.0으로 보내면 DHCP가 채워서 IP 할당해서 *보냄
DHCP 기본 동작 원리
- DHCP discover
- device가 부팅되면 동일 서브넷에 위치한 DHCP 서버를 찾기 위해 DHCP discover 메시지를 이더넷 망에 브로드캐스팅한다. (IP dest:FF-FF-FF-FF-FF)
- DHCP offer
- DHCP discover 메시지를 수신한 DHCP 서버는 DHCP offer 메시지를 broadcast 또는 unicast로 클라이언트에게 전송한다. 여기에는 장치(클라이언트)에게 임대해 줄 IP 주소와 자신의 IP 주소가 포함되어 있다.
- DHCP request
- 클라이언트는 DHCP offer 메시지로부터 받은 네트워크 정보들을 사용하겠다고 요청
- DHCP ACK
- DHCP 서버는 'DHCP ACK' 메시지를 통해 클라이언트의 IP 주소, Subnet mask, Default gateway IP 주소, DNS 서버 IP 주소, Lease Time(IP 주소 임대 시간)을 전달한다.
DHCP: more than IP addresses
- DHCP는 서브넷에서 할당받은 IP 주소 외에도 다음 정보를 전달
- 고객의 first-hop router의 주소
- DNS 서버의 이름과 IP 주소
- network mask ( network host portion of address)
DHCP: Example
- 노트북과 연결하기 위해서는 IP 주소, first-hop router 주소, DNS 서버 주소가 필요하다: use DHCP
- DHCP는 UDP로 캡슐화되고, IP로 캡슐화되고, 802.1 Ethernet으로 캡슐화된다.
- Ethernet frame은 LAN으로 broadcast(dest:FFFFFFFFFFFF), 작동되는 DHCP 서버에서 받음
- Ethernet은 IP demuxed로 demuxed되고, UDP는 DHCP로 demuxed된다.
- unicast: 1대 1 통신
- multicast: 1대 다 통신
- broadcast: 전체 통신 (원하지 않더라도 모두에게 패킷 다 보냄)
- DHCP는 unicast 안됨
- why? IP 주소를 모르니까 => 그래서 broadcast 함
- DCP 서버는 클라이언트의 IP 주소, 클라이이언트의 first-hop router의 IP 주소, DNS 서버의 이름 및 IP 주소를 포함하는 DHCP ACK을 공식화한다
- DHCP 서버 캡슐화, 클라이언트에 프레임 전달, 클라이언트에서 DHCP로 demuxing
- 이제 클라이언트는 자신의 IP주소, name, DSN 서버의 IP 주소, 자신의 first-hop router를 알게 된다.
DHCP 정리
- 호스트가 네트워크에 접속할 때 서버로부터 IP 주소를 동적으로 얻음
- 주소가 변할 수 있고, 재사용이 가능하다
NAT: Network Address Translation
- motivation: 로컬 네트워크는 오로지 한 개의 IP 주소만 가진다.
- ISP로부터 필요하지 않은 주소 범위: 모든 디바이스를 위해 단 하나의 IP 주소만 있으면 된다.
- 바깥 세상과으로부터 독립됨:
- 밖에 알리지 않고 로컬 네트워크에 있는 디바이스의 주소를 바꿀 수 있다.
- 로컬 네트워크의 주소를 바꾸지 않고 ISP를 바꿀 수 있다.
- 로컬 net에 있는 디바이스는 바깥세상에 의해 명시적으로 addressable, visible하지 않는다.
- 하나의 네트워크 망에서 여러 개의 디바이스들이 존재할 때, 그들 각각에게 실제 IP를 하나씩 주게 되면 IP를 너무 많이 필요로 한다. -> 이를 해결하는 방법이 NAT(네트워크 주소 변환)
- 현재 사용 중인 IPv4 주소가 많이 남아있지 않음
- implementation: NAT router must:
- outgoing datagrams: 모든 나가는 데이터그램의 (출발지 IP 주소, 포트 번호)를 (NAT IP 주소, 새로운 포트 번호 -> 목적지 주소로 사용)로 대체한다.
- 모든 (출발지 IP 주소, 포트 번호)->(NAT IP 주소, 새로운 포트 번호) 변환 쌍을 NAT translation table에 기록한다.
- incoming datagrams: 들어오는 데이터그램의 목적지 필드에 있는 (NAT IP 주소, 새로운 포트 번호)를 NAT 테이블 내의 상응하는 (출발지 IP 주소, 포트 번호)로 바꾼다.
- 외부에서 보기에는 하나의 IP 주소인(138.76.29.7)만 알고 있다.
- NAT 라우터는 ISP의 DHCP 서버로부터 IP 주소를 얻고, NAT-DHCP-라우터로 제어되는 홈 네트워크의 주소 공간에서 DHCP 서버를 실행하여 컴퓨터에게 주소를 제공
- 16bit의 port-number field:
- 하나의 LAN 주소로 동시에 60,000개의 연결이 가능
- [(WAN side addr) 138.76.29.7, 5001]이랑 [(LAN side addr) 10.0.0.1, 3345]를 바인딩한 것 => flow
- 60,000개의 flow를 생성할 수 있다는 말
- NAT은 논란의 여지가 있다.
- 라우터는 3계층까지만 처리해야 한다.
- end-to-end 법칙을 위반함
- host가 중간 노드에서 (IP 주소, 포트 번호) 수정 없이 직접 통신해야 한다는 원칙을 어김
- 장점: 경제적
- 단점: 인터넷 원칙을 어김 (smart end, dump middle)
- NAT 대신 IPv6로 주소 부족 문제를 해결해야 한다. -> 라고 NAT 사용 반대하는 사람들의 주장
NAT traversal problem
- 클라이언트가 10.0.01인 주소를 가지는 서버와 연결하고 싶다면?
- 이는 LAN의 로컬 주소로 클라이언트가 이를 목적지 주소로 사용할 수 없다.
- 클라이언트는 오직 138.76.29.7 주소만 알 수 있다.
- 해결책1: 주어진 포트에서 들어오는 연결 요청을 서버로 전달하도록 NAT을 정적으로 구성
즉,
- NAT Router의 특성: 내부에 있는 클라이언트가 외부로 나가는 요청을 해야 테이블에 해당 정보를 매핑해서 외부와 연결이 됨
- 문제1: 서버는 클라이언트 요청을 기다리는 역할임으로 테이블이 만들어지지 않음
- NAT side에서 나갈 때만, 주소 변환 쌍이 테이블에 업데이트됨
- 내부에서 외부로 트래픽이 나갈 때 생성된 NAT 매핑 테이블을 활용하여 외부 트래픽이 내부로 들어오는 것
- 문제2: 내부 사설 아이피는 사설 인터넷 내에서만 유효하기 때문에 외부에서 접근 불가
- 해결책1: 특정 서버를 위해 관리자가 NAT 테이블에 서버 정보를 매핑해두는 방식
- 특정 포트로 들어오는 연결 요청을 서버로 전달(forward) 하도록 NAT을 정적으로 구성
- 해결책2: Universal Plug and Play(UPnP) Internet Gateway Device(IGD) Protocol.
- UPnP 프로토콜을 사용하여 자동으로 NAT 포트 매핑 테이블을 생성하기
- 호스트가 가까운 NAT을 발견하고 동적으로 포트 매핑을 자동 설정하는 프로토콜
- 해결책3: Skype를 사용하여 전달(relaying)
- NAT의 클라이언트와 릴레이로 연결을 설정
- 외부 클라이언트는 릴레이에 연결
- 릴레이가 두 연결 사이에 패킷을 중계
- Skype에서 사용
출처: [Computer networking: A top-down approach, 6th]