OSI 7 Layer - 네트워크 계층과 IP 주소
OSI 7 Layer - 네트워크 계층과 IP 주소
1. 개요
이전에 Switch를 이용해서 다중 통신 환경을 구성했었는데, 이런 환경을 근거리 통신망(Local Area Network, LAN)이라고 한다.
이렇게 구성된 근거리 통신망끼리 통신하기 위해서는 어떻게 하면 될까? 이럴때를 위해서 필요한게 IP 주소이다.
이러한 주소를 통해 어떤 네트워크인지 찾아서 요청 경로를 찾아서 보낼 수 있는 것이다. 이렇게 요청 경로를 찾아서 보내는 것을 Routing이라고 하며 보내주는 기기를 Router라고 한다. 대부분 이런 라우터는 큰 네트워크의 입구에 위치한다.
2. IP의 개요
IP란 Internet Protocol의 약자로 인터넷을 통해 통신하기 위해 필요한 규약이다.
이러한 규약을 통해 통신하기 위해 필요한 주소가 IP 주소이다.
3. IP 주소의 구성
IP 주소는 현재 총 2가지 버전이 있다.
1) IPv4
총 12자리이며, 4부분으로 끊어진다.
1
XXX.XXX.XXX.XXX
XXX 부분은 0~255까지 총 4개로 이루어져있다.
그 이유가 각 부분마다 32bit로 이루어져있기 때문이다.
IPv4의 최대 개수는 이론상 4,294,967,296개이다.
하지만 특정 범위의 주소는 특수한 목적을 위해 예약되어있으므로 사용가능한 IP 주소는 훨씬 적으며
2024년 현재 분배 가능한 IP 주소가 없다고 한다.
2) IPv6
총 128bit로 이루어져있으며 16비트씩 8자리로 이루어져있다.
각 부분은 콜론(:)으로 구분된다.
1
XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
IPv4가 0~255까지인 반면 IPv6는 0000~FFFF(16진수)까지의 값을 가질 수 있다. 따라서 이론상 $2^{128}$개의 주소를 가질 수 있다.
이 역시 IPv4와 같이 특정 범위는 특수한 목적을 위해 예약되어있으므로 사용가능한 IP 주소는 훨씬 적다.
3. IP 주소 통신 방식
IP주소를 이용하여 네트워크를 구성하게 되면 통신 대상 컴퓨터를 빠르게 찾을 수 있다.
이는 Subnet을 이용한 네트워크 쪼개기를 통해 쓸데 없는 라우팅을 줄일 수 있기 때문이다.
1) Network
IPv4의 경우 42억개 정도이지만 지구상의 인구가 대략 60억이고, 통신 기기마다 IP를 요한다고 할때 스마트폰과 노트북 정도는 갖고 있는 사람이 다수이니 IPv4의 개수는 턱없이 부족하다.
IPv6의 경우에는 더욱 더 많은 양의 개수를 지원하지만 현재 인프라 자체가 IPv4를 기준으로 설계되어있으니 어떻게든 나눠서 사용할 수 밖에 없다. 따라서 IP를 나눠서 사용하게 되었다. 적은 양으로 어떻게든 잘 사용해보려는 몸부림인것이다.
여기서 등장하는게 클래스의 개념이다.
| 클래스 | 최상위 비트 | 범위 | 네트워크 비트 | 호스트 비트 | 네트워크 수 | 호스트 수 |
| CLASS A | 0 | 0.0.0.0~127.0.0.0 | 8 | 24 | 128 | 16,777,214 |
| CLASS B | 1 | 128.0.0.0~191.255.0.0 | 16 | 16 | 16,384 | 65,534 |
| CLASS C | 11 | 192.0.0.0~223.255.255.0 | 24 | 8 | 2,097,152 | 254 |
| CLASS D | 111 | 224.0.0.0~239.255.255.255 | N/A | N/A | N/A | N/A |
| CLASS E | 1111 | 240.0.0.0~255.255.255.255 | N/A | N/A | N/A | N/A |
일반적으로 사용하는 클래스는 A,B,C 클래스이다. IP 주소는 네트워크 주소 + 호스트 주소의 형태를 하고 있다. 여기서 네트워크 주소는 어떤 네트워크인지 구분하는 역할이고, 호스트 주소는 해당 네트워크의 어떤 호스트인지 알려주는 식별자의 구조이다. 따라서 라우터에서는 이러한 네트워크 주소만을 확인하여 해당 라우터로 전달하고 해당 라우터에서는 호스트 주소를 보고 내부 네트워크의 호스트에게 전달하게 된다.
2) 예약된 IP 주소
클래스와는 별도로 특정 IP 주소는 특정한 기능을 수행하도록 예약되어있다.
- 127.0.0.1 : 루프백 주소라고 하며 자기자신을 가르킨다. localhost라고도 하낟.
- 192.168.0.0 : 사설 네트워크 대역으로 IP TIME 같은 공유기에 컴퓨터를 연결해두고 쓸때 cmd에서 ipconfig를 입력해보면 이 대역으로 나온다.
3) Subnet
위의 클래스로 분류하자니 낭비가 너무 심해지는 경우가 생겼다.
가령 만약 255개의 호스트가 필요한 경우라고 해보자. 이럴때 해당 업체에는 B클래스를 할당해주어야한다.
B 클래스는 65,534개의 호스트를 사용할 수 있는데, 255개를 제외한 나머지 65,289개는 낭비된다.
따라서 좀 더 적합하게 분할 해야할 필요성을 느끼게 되었고 이때문에 생긴게 서브넷이라는 개념이다.
서브넷은 간단히 말해서 잘개 쪼개진 네트워크라고 할 수 있다. 이 잘개 쪼개진 네트워크가 원래 크던 하나의 네트워크일수도 있고, 이미 쪼개져있는 네트워크일수 도 있다.
네트워크를 나누는 행위를 서브네팅(Subnetting)이라고 하는데 정해진 클래스가 아닌 서브넷 마스크(Subnet mask)라는 것을 통해 해당 IP 주소의 몇번째 비트까지를 네트워크 주소로 쓸 것인지를 명시 할 수 있다.
표기법은 크게 두 가지가 있다. 어떤 IP 주소가 205.1.1.244라고 해보자 여기서 왼쪽에서 23비트까지만 네트워크 주소라고 한다면 아래와 같이 두 가지 방법으로 표기 할 수 있다.
1
2
3
4
5
6
255.255.254.0
// bit로 표기하면 1111 1111 . 1111 1111 . 1111 1110 . 0000 0000 이다.
// AND 연산으로 대상 IP 주소와 연산하게 되면 호스트 주소만 남게 되기 때문에 저런식으로 표기한다.
205.1.1.244/23
// 23비트까지 네트워크 주소임을 표기, CIDR 방식이라고도 한다.
※ Subnetting 예시
할당 받은 대역에서 필요한 host 개수만큼을 산출해서 해당 비트수만큼 확보해주면 되는데 암묵적으로 지정되는 네트워크 주소는 아래와 같다.
- 서브넷의 가장 첫번째 주소는 네트워크 주소
- 서브넷의 두 번째 주소는 네트워크로 들어오는 게이트웨이 주소
- 가장 마지막 주소는 해당 네트워크의 브로드 캐스트를 위한 주소
가령 192.168.12.0/24를 4개의 서브넷으로 나눈다고 하면 각각 값들은 아래와 같다.
서브넷 마스크
192.168.12.0/26 (255.255.255.192)네트워크 주소
192.168.12.0
192.168.12.64
192.168.12.128
192.168.12.192브로드 캐스트 주소
192.168.12.63
192.168.12.127
192.168.12.191
192.168.12.255가능한 값의 범위
192.168.12.1 ~ 192.168.12.62
192.168.12.65 ~ 192.168.12.126
192.168.12.129 ~ 192.168.12.190
192.168.12.193 ~ 192.168.12.254
4) IP 헤더
통신을 할 때 보내려는 데이터의 주소를 명시해야한다. 따라서 아래의 형태로 데이터 앞에 헤더를 붙이는데 이를 IP 헤더라고 한다. 당연하지만 IPv4와 IPv6 간의 헤더의 모양은 다르며 IPv4의 경우 아래와 같은 형태를 하고 있다.
- Version : IPv4면 바이너리값으로 4, IPv6면 바이너리값으로 6이다.
- Header Length(HLEN) : 헤더의 길이를 32비트 워드 단위로 표시한다.
- Type of Service (ToS) : 요구 되는 서비스 품질을 나타낸다. 미리 약속된 값이 있다.
- Total Packet Length : IP 헤더 및 데이터를 포함한 IP 패킷 전체의 길이를 바이트 단위로 표시한다. 최대값은 65,535이다.
- Fragment Identifier : 너무 데이터가 크면 쪼개져서 보내지는데 동일한 데이터인지 알수 있는 일련번호이다.
- Fragment Flag : 분할된 특성을 나타낸다.
- Fragmentation Offset : 분할된 조각 중 몇번째인지 나타낸다.
- Time To Live : IP 패킷의 수명이다. 라우터를 거칠때마다 1씩 줄어든다. OS마다 값이 다르다.
- Protocol Idendifier : 어떤
- Header checksum : 헤더 데이터에 오류가 없는지 알 수 있는 checksum 값이다.
- Source Address : 송신지 IP 주소이다.
- Destination Address : 수신지 IP 주소이다.
- IP Option : 추가적인 IP Header에 대한 옵션이다. 거의 사용되지 않는다.
4. DNS
IP 주소 같은 숫자를 사람이 외우기에는 꽤나 헷갈린다. 따라서 도메인 네임(Domain Name)이라는 것을 도입했는데 이 도메인 네임이라는 것은 일종의 사람이 기억하기 쉬운 문자열 형태이다.
우리가 일반적으로 웹 페이지를 사용할 때 입력하는 그 문자열 말하는 것이다.
1
nid.naver.com
우리가 가장 많이 접하는 naver에서 로그인하기 위한 도메인 주소를 가져와봤다. 여기서 “.com”은 TLD(Top Level Domain)으로 아래와 같은 정보를 이름을 보고 유추 할 수 있다.
※ 일반 최상위 도메인
- .com : 영리사업체
- .org : 비영리 단체
※ 국가코드 최상위 도메인
- .kr : 한국
- .uk : 영국
그 다음으로 “.naver” 부분은 SLD(Second Level Domain)으로 실질적으로 우리가 도메인 네임으로 인지하는 부분이다. 이 부분은 해당 최상위 도메인 내에서 겹칠 수 없으면 최상위 도메인 내에서 유일한 이름을 가진다.
그 다음이 nid 부분인데, 이는 SLD에서 파생되는 서브도메인이라는 것으로 SLD 보유자가 지정하는 것이다.
사용자가 IP가 아닌 도메인 네임으로 요청을 보내면 아래와 같은 일련의 과정을 거치게 된다.
처음에 요청시 host 파일을 확인한다고 되어있는데 여기서 말하는 host 파일은 로컬에 저장하고 있는 file이다. linux, mac, windows 모두 있는 파일로 여기에 해당 도메인에 대해 IP가 등록되어 있는지 확인한다.
이후 DNS 캐시를 확인하는데 이 역시 해당 클라이언트 컴퓨터에서 유지하고 있는 일종의 테이블과 같은 것이다. 이전에 방문한 도메인 네임의 IP 주소를 갖고 있다.
앞서 HOST파일과 DNS 캐시에도 요청 도메인 네임에 대한 IP 주소가 없다면 위 그림과 같이 탐색하여 IP 주소를 받아온 뒤 DNS 캐시에 기재하고 해당 서버 IP로 요청을 보내게 된다.
※ 도메인 캐싱이 문제를 일으키는 경우
캐싱해두면 편리하지만 가끔 문제를 일으키는 경우도 있다.
1. 보안
DNS 캐시나 DNS 서버로 요청하는 것보다 HOST 파일을 확인하는 것에 대해 우선순위가 높다보니 HOST 파일을 변조하여
피싱 사이트를 원래 사이트로 위조하는 공격이 있었다.
2. IP가 중간에 바뀌어버린 경우
IP가 중간에 바뀐 경우에는 없는 서버로 전송하는 셈이기 때문에 캐시 데이터를 사용하는 것은 문제가 있다.
일반적인 컴퓨터의 경우에는 캐시 갱신을 위해 DNS 서버로 요청을 보내기 때문에 문제가 없지만 가령 AWS와 같은 클라우드 서비스로 특정 서버에 도메인 주소를 지정하고 그 도메인 주소를 통해 NGINX를 이용한 리버스 프록시 환경을 구성할 시에 문제가 생길 수 있었다.
구 버전 NGINX가 이런 문제를 일으켰었으며, 일정 시간 마다 DNS에 요청하여 캐시를 갱신하는 식의 처리를 해주어야 해결 할 수 있었다.