통신을 도와주는 네트워크 주요 기술
종단 장비에서 패킷이 시작되어 중간 네트워크 장비에서 이 패킷을 처리하는 과정 외에도 IP 네트워크에는 통신을 도와주고 사용자를 편리하게 해주는 다양한 서비스와 프로토콜이 있다.
사용자가 IP 설정을 하지 않더라도 IP 주소를 자동으로 할당해주는 DHCP(Dynamic Host Configuration Protocol), 사용자가 복잡한 목적지 IP를 기억하지 않고 쉬운 도메인 이름을 사용하하도록 도메인 이름과 IP주소를 매핑해주는 DNS(Domain Name System), 사용자가 가장 가까운 지역의 데이터 센터에 접소개 신속한 서비스를 받게 해주는 GSLB(Global Service Load Balancing), 하나의 IP를 사용해 여러 단말 장비를 포함하는 네트워크를 쉽게 구축하도록 도와주는 NAT와 같은 다양한 기술들이 있다. 이번장에는 자주 사용되면서 실무환경에서 네트워크 통신을 이해하는 데 중요한 NAT, DNS, GSLB, DHCP에 대해 자세히 알아보자.
NAT/PAT
NAT(Network Address Translation)는 실생활에서 많이 사용되는 기술이다. 가정에서 사용하는 노트부고가 PC는 공유기를 통해서, 통신사에 LTE나 5G로 연결된 스마트폰은 통신사 장비 어디선가 NAT를 수행해 외부와 통신하게 된다.
NAT는 이름 그대로 네트워크 주소를 변환하는 기술이다. NAT는 기본적으로 하나의 네트워크 주소에 다른 하나의 네트워크 주소로 변환하는 1:1 변환이 기본이지만 IP 주소가 고갈되는 문제를 해결하기 위해 1:1 변환이 아닌 여러 개의 IP를 하나의 IP로 변한하기도 한다.
여러 개의 IP를 하나의 IP로 변환하는 기술도 NAT 기술 중 하나이고 NAT로 통칭하여 불리기도 하지만 실제 공식 용어는 NAPT이다.
"NAT는 IP 주소를 다른 IP 주소로 변환해 라우팅을 원할히 해주는 기술"이라고 인터넷 표준 문서에 정의되어 있으며 NAT가 가장 많이 사용되는 경우는 사설 IP 주소에서 공인 IP 주소로 전환하는 경우이다.
NAT/PAT의 용도와 필요성
NAT와 PAT는 우리가 인식하지 못하는 사이 다양한 곳에서 사용되고 있다.
1. IPv4 주소 고갈문제의 솔루션으로 NAT가 사용된다.
폭증한 IP 주소 요구를 극복하기 위해 단기, 중기, 장기의 3단계 IP 주소보존과 전환전략을 수립했다. IPv4 주소 보존전략 중 단기 전략은 서브네팅, 중기 전략은 NAT와 사설 IP체계, 장기 전략은 IPv6 전환이다.
중기 전략인 NAT는 외부에 공개해야 하는 서비스에 대해서는 공인 IP를 사용하고 외부에 공개할 필요가 없는 일반 사용자의 PC나 기타 종단 장비(스마트폰, 테블릿 등)에 대해서는 사설 IP를 사용해 효율적으로 IP를 사용할 수 있게 만들어 준다.
2. 보안을 강화하는 데 NAT 기술을 사용한다.
IP 주소는 네트워크에서 유일해야 하고 이 정보가 식별자로 사용되어 외부와 통신하게 해준다. 외부와 통신할 때 내부 IP를 다른 IP로 변환해 통신하면 외부에서 사내 IP 주소 체계를 숨길 수 있다.
NAT는 주소 변환 후 역변화이 정상적으로 다시 수행되어야만 통신이 가능하다. 이 성질을 이용해 복잡한 룰 없이 방향성을 통제할 수 있으며 내부 네트워크에서 외부 네트워크로 나가는 방향 통신은 허용하지만 외부에서 시작해서 내부로 들어오는 통신은 방어할 수 있다.
3. IP 주소 체계가 같은 두 개의 네트워크 간 통신을 가능하게 한다.
IP 네트워크에서 서로 통신하려면 식별 가능한 유일한 IP 주소가 있어야 한다. 공인 IP는 인터넷에서 유일한 주소로 IP 주소가 중보괴면 안 되지만 사설 IP는 외부와 통신할 때 공인 IP로 변환되어 통신하므로 서로 다른 회사에서 중복해 사용할 수 없다.
대외계라고 부르는 회사 간 통신에서 이런 상황이 많이 발생한다. 카드사나 은행 간 연결이 대표적인 대외계 네트워크이다. IP 대역이 같은 네트워크와 통신할 가능성이 높은 대외계 네트워크를 연결하기 위해 출발지와 도착지를 한꺼번에 변환하는 "더블 나트(Double NAT)"기술을 사용한다.
NAT 동작 방식
아래의 그림은 NAT의 동작 순서를 표현한 그림이다.
NAT의 동작 방식을 이해하기 위해 출발지 사용자(10.10.10.10)가 목적지 웹 서버(20.20.20.20)로 통신하는 과정을 살펴보자.
1. 사용자는 웹 서버에 접근하기 위해 출발지 IP를 10.10.10.10으로, 목적지 IP와 서비스 포트는 20.20.20.20과 80으로 패키슬 전송한다. 출발지 서비스 포트는 임의의 포트로 할당되면 여기서는 2000포트로 가정한다.
2. NAT 역할을 수행하는 장비에서는 사용자가 보낸 패킷을 수신한 후 NAT 정책에 따라 외부 네트워크와 통신이 가능한 공인 IP인 11.11.11.11로 IP 주소를 변경한다. NAT장비에서 변경 전후의 IP 주소는 NAT 테이블에 저장된다.
3. NAT 장비에서는 출발지 주소를 11.11.11.11로 변경해 목적지 웹 서버로 전송한다.
4. 패킷을 수신한 웹 서버는 사용자에게 응답을 보낸다. 응답이므로 수신한 내용과 반대로 출발지는 웹 서버가 되고 목적지는 NAT 장비에 의해 변환된 공인 IP로 사용자에게 전송한다.
5. 웹 서버로부터 응답 패킷을 수신한 NAT 장비는 자신의 NAT 테이블에서 목적지 IP에 대한 원래 패킷을 발생시킨 출발지 IP 주소가 10.10.10.10인 것을 확인한다.
6. NAT 변환 테이블에서 확인된 원래 패킷 출발지 IP(10.10.10.10)로 변경해 사용자에게 전송하면 최종적으로 패킷을 수신한다.
PAT 동작 방식
NAT 예제와 동일한 출발지와 목적지로 하고 NAT 장비는 PAT로 동작하는 예제를 확인해보자.
1. 사용자가 웹 서버로 접근하기 위해 패킷에 출발지 10.10.10.10, 목적지 20.20.20.20, 목적지 서비스 포트는 웹 서비스 포트인 80으로 채워 패킷을 전송한다.출발지 서비스 포트는 임의의 포트로 할당되면 여기서는 2000포트로 가정한다.
2. NAT 장비는 사용자가 보낸 패킷을 받아 외부 네트워크와 통신이 가능한 공인 IP인 11.11.11.11로 변경한다. 다만 출발지에 있는 다수의 사용자가 동일한 공인 IP로 변환되어야 하므로 패킷의 주소 변경 시 출발지 IP뿐만 아니라 출발지의 서비스 포트도 변경된다. 출발지 IP와 출발지 서비스 포트는 NAT 장비에 의해 모두 변경되고 NAT 장비가 이 변경 정보를 NAT 테이블에 기록한다.
3. NAT 장비에서 변경된 출발지 IP 주소인 11.11.11.11과 서비스 포트 3000 패킷을 재작성해 웹 서버로 다시 재전송한다.
4. 사용자가 보낸 패킷을 수신한 웹 서버는 사용자에게 패킷을 응답하는데 출발지 IP는 웹 서버의 IP 주소로 채워지고 목적지 IP는 NAT 장비에 의해 변환된 공인 IP와 서비스 포트로 채워져 전송한다.
5. 웹 서버로부터 응답 패킷을 수신한 NAT 장비는 NAT 테이블을 확인해 웹 서버로부터 받은 패킷의 목적지 IP 주소인 11.11.11.11이 원래 10.10.10.10이며 서비스 포트 3000이 원래 2000인 것을 확인한다.
6. NAT 장비는 NAT 테이블에서 확인한 목적지 IP 주소와 서비스 포트로 패킷을 재작성한 후 사용자에게 전달한다. 사용자는 NAT 장비에서 역변환된 패킷을 받아 웹 페이지를 표시한다.
PAT 동작 방식은 NAT와 거의 동일하게 이루어지지만 IP 주소뿐만 아니라 서비스 포트까지 함께 변경해 NAT 테이블을 관리하므로 하나의 IP만으로도 다양한 포트 번호를 사용해 사용자를 구분할 수 있다.
PAT는 다수의 IP가 있는 출발지에서 목적지로 갈 때 NAT 테이블이 생성되고 응답에 대해 NAT 테이블을 참조할 수 있지만 PAT IP가 목적지일 때는 해당 IP가 어느 IP에 바인딩되는지 확인할 수 있는 NAT 테이블이 없으므로 사용할 수 없다.
즉, PAT는 내부에서 외부로 출발하는 경우에만 사용이 가능한다.
SNAT와 DNAT
NAT를 사용해 네트워크 주소를 변환할 때 어떤 IP 주소를 변환하는지에 따라 두 가지로 구분한다.
SNAT(Source NAT) - 출발지 주소를 변경하는 NAT DNAT(Destination NAT) - 도착기 주소를 변경하는 NAT
SNAT와 DNAT는 트래픽이 출발하는 시작 지점을 기준으로 구분한다. 어떤 주소를 변경해야 하는지는 서비스 흐름과 목적에 따라 결정된다.
SNAT와 DNAT의 기준은 NAT가 수행되기 이전의 트래픽이 출발하는 시작 지점이다. 즉, 요청 시 SNAT를 해 목적지로 전송하면 해당 트패릭에 대한 응답을 받을 때는 출발지와 목적지가 반대가 되므로 DNAT가 되는데 이때 트래픽을 요청하는 시작 지점만 고려해 SNAT 설정을 해야 한다. NAT 장비를 처음 통과할 때 NAT 테이블이 생성되므로 응답 패킷이 NAT 장비에 들어오면 별도의 NAT 설정이 없더라도 NAT 테이블을 사용해 반대로 패킷을 변환해줄 수 있기 때문이다.
SNAT와 DNAT의 몇 가지 사용 경우를 알아보자.
SNAT는 사설에서 공인으로 통신할 때 많이 사용한다.
공인 IP 주소의 목적지에서 출발지로 다시 응답을 받으려면 출발지 IP 주소 경로가 필요한데 공인 대역에서는 사설 대역으로의 경로를 알 수 없으므로 공인 IP의 목적지로 서비스를 요청할 때 출발지에서는 사설 IP를 별도의 공인 IP로 NAT해 서비스를 요청해야한다. 이것은 공유기처럼 PAT를 사용하는 경우에 해당할 수 있다.
보안상 SNAT를 사용하는 경우도 있다.
회사에서는 다른 대외사와 통신 시 내부 IP 주소가 아니라 별도의 다른 IP로 전환해 전송함으로서 대외에 내부의 실제 IP 주소를 숨길 수 있다.
DNAT는 로드 밸런서에서 많이 사용하며 사내가 아닌 대외망과의 네트워크 구성에도 DNAT를 사용한다.
동적 NAT와 정적 NAT
출발지와 목적지의 IP를 미리 매핑해 고정해놓은 NAT를 정적 NAT라고 한다. 반대로 출발지나 목적지 어느 경우든 사전에 정해지지 않고 NAT를 수행할 때 IP를 동적으로 변경하는 것을 동적 NAT라고 한다.
동적 NAT - 출발지와 목적지가 모두 정의돈 것이 아니라 다수의 IP 풀에서 정해지므로 최손한 출발지나 목적지 중 한 곳이 다수의 IP로 구성된 IP 풀이나 레인지(Range)로 설정되어 있다. NAT가 필요할 때 IP 풀에서 어떤 IP로 매핑될 것인지 판단해 NAT를 수행하는 시점에 NAT 테이블을 만들어 관리한다.
정적 NAT - 출발지와 목적지 매핑 관계가 특정 IP로 사전에 정의된 것이므로 1:1 NAT라고 부르기도 한다. 방향성 없이 서비스 흐름을 고려하지 않고 NAT를 설정할 수 있다.
| 동적 NAT | 정적 NAT | |
|---|---|---|
| NAT 설정 | 1:N, N:1, N:M | 1:1 |
| NAT 테이블 | NAT 수행 시 생성 | 사전 생성 |
| NAT 테이블 타임아웃 | 동작 | 없음 |
| NAT 수행 정보 | 실시간으로만 확인하거나 별도 변경 로그 저장 필요 | 별도 필요 없음 (설정 = NAT 내역) |
DNS
네트워크 프로토콜은 크게 두 가지로 나눌 수 있다. 실제로 데이터를 실어나르는 데이터 프로토콜과 이 데이터 프로토콜이 잘 동작하도록 도와주는 컨트롤 프로토콜이다.
컨트롤 프로토콜은 통신에 직접 관여하지 않지만 처음 통신 관계를 맺거나 유지하는 데 큰 역할을 한다. TCP/IP 프로토콜 체계를 유지하기 위한 주요 컨트롤 프로토콜에는 ARP, ICMP, DNS가 있다.
이 중 DNS(Domain Name System)는 도메인 주소를 IP 주소로 변환하는 역할을 한다. IP 주소보다 도메인 주소를 이용하는 것이 일반 사용자에게 더 익숙하고 서버IP 변경에 쉽게 대처할 수 있으므로 네트워크 통신에서는 DNS의 역할이 매우 중요하다.
DNS 소개
우리가 사이트에 접속하거나 링크에 지정된 주소는 https://202.179.177.21 같은 IP 주소이거나 https://www.naver.com 같은 도메인 주소를 사용하게 된다. 물론 어떤 주소를 사용하더라도 실제 네트워크 통신에서는 202.179.177.21 같은 IP 주소를 이용한다.
하지만 사용자가 수많은 IP 주소를 외우기는 어렵기 때문에 숫자로 구성된 IP 주소보다 의미 있는 문자열로 구성된 도메인 주소가 우리가 인식하고 기억하기 더 쉽다.
또한 IP 주소 대신 도메인 주소를 이용하면 하나의 IP 주소를 이용해 여러 개의 웹 서비스를 운영할 수 있고 서비스 중인 IP 주소가 변경되도 도메인 주소 ㄱ대로 유지해 접속 방법 변경 없이 서비스를 그대로 유지할 수 있다.
위의 그림은 naver.com 접속을 위한 절차이고 DNS 서버에 이름 풀이를 요청한 후 IP 주소를 알아내 통신을 시작하는 과정이다.
DNS 구조와 명명 규칙
도메인은 계층 구조여서 수많은 인터넷 주소 중 원하는 주소를 효율적으로 찾아갈 수 있다.
역트리 구조로 최상위 루트부터 Top-Level 도메인, Second-Level 도메인, Third-Level 도메인과 같이 하위 레벨로 원하는 주소를 단계적으로 찾아간다.
Third.Second.Top.과 같은 형태로 표현하고 맨 뒤의 루트는 생력된다.
DNS 동작 방식
도메인을 IP 주소로 변환할면 DNS 서버에 도메인 쿼리하는 과정을 거쳐야 한다. 로컬에서 도메인과 IP 주소를 관리하는 파일을 hosts 파일이라고 하며 hosts 파일에 도메인과 IP 주소를 설정해두면 해당 도메인 리스트는 항사 DNS 캐시에 저장된다.
도메인을 쿼리하면 DNS 서버에 쿼리를 하기 전 로컬에 있는 DNS 캐시 정보를 먼저 확인한다. 동일한 도멘인을 매번 질의하지 않고 캐시를 통해 성능을 향상시키기 위해서이다. 이런 DNS 캐시 정보에는 기존 DNS 조회를 통해 확인한 동적 DNS 캐시와 함께 hosts 파일에 저장되어 있는 정적 DNS 캐시가 함께 저장되어 있다. DNS 캐시 정보에 필요한 도메인 정보가 없으면 DNS 서버로 쿼리를 수행하고 DSN 서버로부터 응답을 받으면 그 결과를 캐시에 먼저 저장한다.
도메인 쿼리(브라우저에 도메인 주소 입력)
-> 로컬에 있는 캐싱된 DNS 정보를 확인한다. DNS 요청을 한 번 이상한 동적 DNS 캐쉬와 로컬 호스트 파일인 정적 DNS 캐쉬를 확인한다.
=> 여기를 거쳤는데도 없으면 DNS 서버에 요청을 보낸다.
아래의 그림은 로컬 캐시 유무에 따른 도메인 쿼리 방법이다.
지금까지는 클라이언트 관점에서 DNS 질의 과정을 알아봤다면 지금부터는 반대로 DNS 시스템 관점에서 도메인에 대한 결괏값을 클라이언트에 보내주는 과정을 알아보자.
전 세계 도메인 정보를 DNS서 서버 하나에 저장할 수 없으므로 DNS는 분산된 데이터베이스로 서로 도와주도록 설계되었는데 자신이 가진 도메인 정보가 아니면 다른 DNS에 질의해 결과를 받을 수 있다.
도메인의 재퀴적 쿼리와 반복적 쿼리 과정을 살펴보며 전체 과정을 살펴보자.
1. 사용자 호스트는 'zigispace.net'이라는 도메인 주소의 IP 주소가 로컬 캐시에 저장되어 있는지 확인한다.
2. 'zigispace.net'이 로컬 캐시에 저장되어 있지 않으면 사용자 호스트에 설정된 DNS에 'zigispace.net'에 대해 쿼리한다.
3. DNS 서버는 'zigispace.net'이 로컬 캐시와 자체에 설정되어 있는지 직접 확인한고 없으면 해당 도메인을 찾기 위해 루트 NS에 .net에 대한 TLD 정보를 가진 도메인 주소를 쿼리한다.
4. 루트 DNS는 'zigispace.net'의 TLD인 '.net'을 관리하는 TLD 네임 서버 정보를 DNS 서버에 응답한다.
5. DNS는 TLD 네임 서버에 'zigispace.net'에 대한 정보를 다시 쿼리한다.
6. TLD 네임 서버는 'zigispace.net'에 대한 정보를 가진 zigi 네임 서버에 대한 정보를 DNS 서버로 응답한다.
7. DNS는 zigi 네임 서버에 'zigispace.net'에 대한 정보를 쿼리한다.
8. zigi 네임 서버는 'zigispace.net'에 대한 정보를 DNS 응답합니다.
9. DNS는 'zigispace.net'에 대한 정보를 로컬 캐시에 저장하고 사용자 호스트에 'zigispace.net'에 대한 정보를 응답한다.
10. 사용자 호스트는 DNS로부터 받은 'zigispace.net'에 대한 IP 정보를 이용해 사이트에 접속한다.
마스터와 슬레이브
DNS 서버는 마스터(Master, Primary) 서버와 슬레이브(Slave, Secondary) 서버로 나눌 수 있다. 두 서버 모두 도메인 쿼리에 응답한다. 마스터와 슬레이브는 도메인에 대한 존(Zone) 파일을 직접 관리하는지 여부로 구분한다.
마스터 서버 - 존 파일을 직접 생성해 도메인 관련 정보를 관리한다. 슬레이브 서버 - 마스터에 만들어진 존 파일을 본제한다.
마스터 서버는 도메인 영역을 생성하고 레코드를 직접 관리하지만 슬레이브 서버는마스터 서버에 설정된 도메인이 가진 레코드값을 정기적으로 복제한다. 아래 그림은 이런 영역 전송을 도식화한 그림이다.
GSLB
DNS에서 동일한 레코드 이름으로 서로 다른 IP 주소를 동시에 설정할 수 있다. 이렇게 설정하면 도메인 질의에 따라 응답받는 IP 주소를 나누어 로드밸런싱할 수 있다. 이것을 DNS 로드밸런싱이라고 한다.
하지만 DNS만 이용한 로드밸런싱으로는 정상적인 서비스를 할 수 없다. DNS는 설정된 서비스 상태의 정상 여부를 확인하지 않고 도메인에 대한 질의에 대해 설정된 값을 무조건 응답한다. 아래의 그림에서 특정 서비스(서버2)에 문제가 있을 때 DNS 서버는 이것을 감지하지 못해 사용자의 도메인 질의 요청에 비정상 상태의 서비스 IP 주소를 응답한 경우, 사용자는 해당 서비스에 접근할 수 없다.
즉 DNS 서버에서는 각 레코드에 대한 서비스 체크가 이루어지지 않고 설정된 값에 따라 동작하므로 서비스 가용성 향상 방법으로는 부적합하다.
GSLB(Global Server/Service Load Balancing)는 DNS의 이런 문제점을 해결해 도메인을 이용한 로드 밸런싱 구현을 도와준다. GSLB는 DNS와 동일하게 도메인 질의에 응답해주는 역활과 동시에 로드 밸런서처럼 등록된 도메인에 연결된 서비스가 정상적인지 헬스 체크를 수행한다. 즉, 등록된 도메인에 대한 서비스가 정상인지 상태를 체크해 정상인 레코드에 대해서만 사용한다.
GSLB 동작 방식
예제를 통해 GSLB 동작 방식와 GSLB를 사용한 도메인 질의가 어떻게 이루어지는지 알아보자.
GSLB의 동작 방식의 이해를 돕기 위해 서울과 부산의 데이터 센터에서 동일한 서비스가 가동 중인 상황을 예로 들어보자.
1. 사용자가 web.zigispace.net에 접속하기 위해 DNS에 질의한다.
2. LDNS는 web.zigispace.net을 관리하는 NS 서버를 찾기 위해 root부터 순차 질의한다.
3. zigispace.net을 관리하는 NS 서버로 web.zigispace.net에 대해 질의한다.
4. DNS 서버는 GSLB로 web.zigispace.net에 대해 위임했으므로 GSLB 서버가 NS 서버라고 LDNS에 응답한다.
5. LDNS는 다시 GSLB로 web.zigispace.net에 대해 질의한다.
6. GSLB는 web.zigispace.net에 대한 IP 주솟값 중 현재 설정된 분산 방식에 따라 서울 또는 부산 데이터 센터의 IP 주소값을 DNS에 응답한다. 본 예제에는 서울 데이터 센터의 서비스 IP 인 1.1.1.1을 응답했다. GSLB가 응답하는 값은 GSLB에서 설정한 주기에 따라 서울과 부산 데이터 센터로 헬스 체크해 정상적인 값만 응답한다.
7. GSLB에서 결괏값을 응답받은 LDNS는 사용자에게 web.zigispace.net이 1.1.1.1로 서비스하고 있따고 최종 응답한다.
DLNS - Local DNS
정리해서 GSLB는 일반 DNS를 사용하는 것과 거의 동일하게 동작한다. 다만 GSLB에서 서비스 IP 정보에 대한 헬스 체크와 사전에 지정한 다양한 분산 방법을 이용한 부하 분산이 일반 DNS와 큰 차이점이라 볼 수 있다.
GSLB 구성 방식
GSLB를 사용한 도메인 설정 방법은 두 가지가 있다.
도메인 자체를 GSLB로 사용 도메인 내의 특정 레코드만 GSLB를 사용
도메인 자체를 GSLB로 사용하면 해당 도메인에 속하는 모든 레코드 설정을 GSLB 장비에서 관리한다. 즉 , 도메인에 대한 모든 레코드를 GSLB에서 설정한다. 도메인 자체를 GSLB로 사용하는 것은 도메인에 대한 네임 서버를 GSLB로 지정하고 GSLB에서 도메인에 대한 모든 레코드를 등록해 처리하는 방식이다. 즉, GSLB 자체가 도메인의 네임 서버 역할을 하는 경우이다.
네임 서버 = DNS 서버
도메인 내의 특정 레코드에 대해서만 GSLB를 사용하는 경우는 DNS에서 도메인 설정 시 GSLB를 사용하려는 레코드에 대해서만 GSLB로 처리하도록 설정한다. 회사 대표 도메인에 속한 레코드 중 GSLB 적용이 불필요한 경우가 많아 도메인 내의 특정 레코드에 대해서만 GSLB로 처리를 이관하는 방식을 사용한다. 특정 레코드에 대해서만 GSLB로 처리를 이관하는 방법은 두 가지이다.
별칭(Alias) 사용(CNAME 레코드 사용) 위임(Delegation) 사용(NS 레코트 사용)
아래의 그림은 별칭을 이용해 GSLB를 사용하기 위한 동작 예시이다.
1. 사용자가 web.zigispace.net을 LDNS(1.1.1.1)로 질의
2. LDNS는 web.zigispace.net을 관리하는 NS 서버를 찾기 위해 root부터 순차적으로 질의
3. zigispace.net을 관리하는 DNS(2.2.2.2)에 web.zigispace.net의 주소 질의
4. DNS 서버는 LDNS에게 별칭으로 web.zigispace.net은 web.zigispace.net.gslb.net이 관리하고 있다는 응답 수신
5. 다시 LDNS(1.1.1.1)는 gslb.net을 관리하는 NS 서버를 root부터 순차 질의
6. LDNS(1.1.1.1)는 zigipace.gslb.net을 관리하는 NS 서버인 GSLB(3.3.3.3)에 web.zigispace.gslb.net에 대해 질의
7. GSLB(3.3.3.3)는 LDNS(1.1.1.1)에 web.zigispace.gslb.net의 IP(10.10.10.10)를 응답
8. LDNS(1.1.1.1)는 해당 결과값(10.10.10.10)을 사용자에게 최종 응답
다음은 NS 레코드를 이용해 위임하여 GSLB를 사용하는 방법이다. 아래의 그림은 NS 레코드를 이용하여 위임을 통해 GSLB를 사용하는 예시이다.
1. 사용자가 web.zigispace.net을 LDNS(1.1.1.1)로 질의
2. LDNS는 web.zigispace.net을 관리하는 NS 서버를 찾기 위해 root부터 순차적으로 질의
3. zigispace.net을 관리하는 DNS(2.2.2.2)dp web.zigispace.net의 주소 질의
4. DNS(2.2.2.2)는 GSLB(3.3.3.3)가 web.zigispace.net을 관리한다고 응답
5. 다시 LDNS(1.1.1.1)는 web.zigispace.net을 관리하는 NS 서버인 GSLB(3.3.3.3)에게 web.zigispace.net을 질의
6. GSLB(3.3.3.3)는 LDNS(1.1.1.1)에 web.zigispace.net의 IP를 응답
7. LDNS(1.1.1.1)는 해당 결과값을 사용자에게 최종 응답
하나의 FQDN을 위임 처리하면 해당 FQDN의 하위 도메인은 별도의 위임 처리없이 이미 상위 계층에서 위임 처리되므로 특정 도메인 내에세 GSLB를 사용한 하부 도메인을 계층화해 사용하면 DNS 서버 설절을 최소화해 GSLB로 다쉬의 FQDN을 위임 처리할 수 있다. 아래의 그림은 위임을 사용하면 계층화된 도메인에 대한 일괄적인 위임 처리가 가능한 예시이다.
FQDN - '절대 도메인 네임' 또는 '전체 도메인 네임'으로 도메인 전체 이름을 표기하는 방식이다.
Ex) www.tistory.com에서 www는 호스트, tistory.com은 도메인이며 www.tistory.com은 호스트와 도메인을 함께 명시하여 전체 경로를 모두 표기하는 것을 FQDN 이라 한다.
정리하자면 별칭(CNAME)을 이용해 GSLB를 사용하는 경우, CDN처럼 GSLB를 운영해주는 외부 사업자가 있거나 GSLB를 사용해야 하는 도메인이 매우 많은 경우, 별도의 GSLB를 운영하기 위해 사용한다.
CDN - 콘텐츠 전송 네트워크(CDN)는 데이터 사용량이 많은 애플리케이션의 웹 페이지 로드 속도를 높이는 상호 연결된 서버 네트워크이다. CDN은 콘텐츠 전송 네트워크 또는 콘텐츠 배포 네트워크를 의미할 수 있다. 사용자가 웹 사이트를 방문할 때 해당 웹 사이트 서버의 데이터는 사용자의 컴퓨터에 도달하기 위해 인터넷을 통해 이동해야 한다. 사용자가 해당 서버에서 멀리 떨어져 있는 경우 동영상 또는 웹 사이트 이미지와 같은 대용량 파일을 로드하는 데 시간이 오래 걸린다. 대신 웹 사이트 콘텐츠는 지리적으로 사용자와 가까운 CDN 서버에 저장되며 컴퓨터에 훨씬 빨리 도달한다.
출처 - https://aws.amazon.com/ko/what-is/cdn/
위임의 경우 DNS와 같은 도메인 GSLB를 운영하면서 계층적으로 GSLB를 이용한 FQDN을 관리할 때 사용될 수 있다.
DHCP
호스트가 네트워크와 통신하려면 물리적 네트워크 구성은 물론 IP 주소, 서브넷 마스크, 게이트웨이와 같은 네트워크 정보와 앞에서 다룬 DNS 주소도 설정이 필요하다. 이런 네트워크 정보를 호스트에 적용하려면 사용자가 IP 정보를 직접 설정하거나 IP 정보를 할당해주는 서버를 이용해 자동으로 설정해야 한다. 수동으로 IP와 네트워크 정보를 직접 설정하는 것이 '정적 할당'이라고 하며 자동을 설정하는 것을 '동적 할당'이라고 한다.
IP를 동적으로 할당하는 데 사용되는 프로토콜이 바로 DHCP(Dynammic host Configuration Protocol)이다. DHCP를 사용하면 사용자가 직접 입력해야 하는 IP 주소, 서브넷 마스크, 게이트웨이, DNS 정보를 자동으로 할당받아 사용할 수 있다.
사용자 이동이 많고 한정된 IP 주소를 가진 경우 유용하게 사용될 수 있으며 IP가 자동으로 관리되므로 사용자가 직접 입력하면서 발생할 수 있는 설정 정보 오류나 중복 IP 할당과 같은 문제를 예방할 수 있다.
DHCP 동작 방식
호스트가 DHCP 서버로 IP를 할당받는 과정은 다음과 같이 4단계로 진행된다.
1. DHCP Discover
DHCP 클라이언트는 DHCP 서버를 찿기 위해 DHCP Discover 메시지를 브로드캐스트로 전송한다.2. DHCP Offer
DHCP Discover를 수신한 DHCP 서버는 클라이언트에 할당한 IP 주소와 서브넷, 게이트웨이, DNS 정보, Lease Time 드으이 정보를 포함한 DHCP 메시지를 클라이언트로 보내다.3. DHCP Request
DHCP 서버로부터 제안받은 IP 주소(Requested IP0와 DHCP 서버 정보(DHCP Server Identifier)를 포함한 DHCP 요청 메세지를 브로드캐스트로 전송한다.4. DHCP Acknowledgement
DHCP 클라이언트로부터 IP 주소를 사용하겠다는 요청을 받으면 DHCP 서버에 해당 IP를 어떤 클라이언트가 언제부터 사용하기 시작했는지 정보를 기록하고 DHCP Request 메시지를 정상적으로 수신했다는 응답을 전송한다.
DHCP를 이용해 IP를 자동으로 할당받기 위해 DHCP 클라이언트는 DHCP서버를 찾기 위한 메시지를 전송하는데 이 메세지를 DHCP Discover 메시지라고 한다. DHCP Discover 메세지에는 DHCP 클라이언트의 IP가 아직 없으므로 출발지는 Zero IP 주소(0.0.0.0), 목적진느 브로드캐스트 주소 (255.255.255.255)로 설정된다.
클라이언트로부터 DHCP Discover 메세지를 받은 DHCP 서버는 클라이언트에 해당할 수 있는 IP 리스트인 DCHP IP Pool 중에서 할당할 IP를 선택한다.
클라잉너트에 IP를 할당할 때는 단순히 IP 주소뿐만 아니라 서브넷, 게이트웨이, DNS 정보와 IP 주소 임대 시간(Lease Time), DHCP 서버 자신의 IP 정보를 포함한 메세지를 DHCP 클라이너트에 전송한다. 이 메시지를 DHCP Offer 메시지라하며 DHCP 서버가 클라이언트에 IP 주소 사용을 제안하는 단계이다.
DHCP 클라이언트는 DHCP 서버로부터 제안받은 IP 정보를 사용하기 위해 DHCP Request 메시지를 DHCP 서버에 전송한다. DHCP 서버를 찾기 위한 Discover 메시지를 보낼 때는 현재 DHCP 서버가 어느 서버인지 알 수 없으므로 브로드캐스트로 전송하고 DHCP Request 메시지를 보낼 때도 유니캐스트가 아닌 브로드캐스트로 전송한다.
마지막으로 DHCP 서버는 DHCP Request를 보낸 클라이언트에 최종 확인을 위한 응답 메시지 패킷을 보내는데 이것을 DHCP Acknowledgement 메시지라고 하며 내용은 DHCP Offer의 내용과 동일하다.
DHCP를 통해 IP를 할당할 때는 IP 임대 시간이 있다. DHCP 서버는 클라이언트에 할당할 IP 정보와 함께 임대 시간을 지정해 전달한다. 임대시간이 만료되면 클라이언트에 할당된 IP를 다시 IP Pool로 회수한다. 아래의 그림은 DHCP 갱신 절차이다.
DCHP에서 IP를 할당받은 후 임대 시간의 50%가 지나면 DHCP 갱신 과정을 수행한다. DHCP 클라이언트는 처음 수앻안 임대 과정과 달리 DCHP 서버와 이미 사용 중인 IP 정보가 있어 DHCP Discover와 DHCP Offer 과정을 생략하고 DHCP Request를 HDCP로 곱다로 전송하고 DHCP 서버에서는 DHCP ACK를 보내면 갱신 과정을 진행한다.
<DHCP 메시지 타입>
| 메시지 타입 | 내용 |
|---|---|
| DHCP Discover | 클라이언트가 사용한 DHCP 서버를 찾는 메시지 |
| DHCP Offer | DHCP 서바가 IP 설정값에 대한 클라이언트에게 제안하는 메시지 |
| DHCP Request | DHCP 서버에서 제안받은 설정값을 요청하는 메시지 |
| DHCP Decline | 현재 IP 가 사용 중임을 클라이언트가 서버에 알려주는 메시지 |
| DHCP ACK | DHCP 서버가 클라이언트에 받은 요청을 수락하는 메시지 |
| DHCP Nak | DHCP 서버가 클라이언트에 받은 요청을 수락하는 않는다는 메시지 |
| DHCP Release | 클라이언트가 현재 IP를 반납할 떄 사용하는 메시지 |
| DHCP Inform | 클라이언트가 서버에 IP 설정값을 요청하는 메시지 |
