3. 전 세계의 DNS 서버가 연대한다
3-1. DNS 서버의 기본 동작
DNS 서버의 기본 동작은 클라이언트에서 조회 메시지를 받고 조회의 내용에 응답하는 형태로 정보를 회답하는 일이다.
조회 메시지에는 다음의 세 가지 정보가 포함되어 있다.
(a) 이름
: 서버나 메일 배송 목적지와 같은 이름이다.
(b) 클래스
: DNS의 구조를 고안했을 때 인터넷 이외에도 네트워크에서의 이용까지 검토하여 식별하기 위해 클래스라는 정보를 준비하였다. 하지만 현
재에는 인터넷 이외의 네트워크는 소멸되었으므로 클래스는 항상 인터넷을 나타내는 'IN'이라는 값이 된다.
(c) 타입
: 이름에 어떤 타입의 정보가 지원되는지를 나타낸다. 타입에 따라 클라이언트에 회답하는 정보의 내용이 달라진다.
→ 이름과 타입에 따라 조사하는 정보를 지정하고, 그것에 따라 해당하는 것을 찾아 클라이언트에 회답하는 것이 DNS 서버의 기본 동작
3-2. 도메인의 계층
인터넷에는 막대한 수의 서버가 있으므로 이것을 1대의 DNS 서버에 등록하는 것은 불가능하다. 이 경우 어떻게 DNS 서버가 동작하는지 알아야 한다.
결론부터 말하면, 정보를 분산시켜서 다수의 DNS 서버에 등록하고, 다수의 DNS 서버가 연대하여 어디에 정보가 등록되어 있는지를 찾아내는 구조이다.
- 우선 DNS 서버에 등록된 정보에는 모든 도메인명이라는 계층적 구조를 가진 이름이 붙여져 있다.
- 오른쪽에 위치하느 것이 상위의 계층을 나타낸다.
ex) www.wonsjung.tistory.com이라는 이름은 'com → tistory → wonsjung → www' 형태의 구조를 가진다. 여기서 각각이 존재하는 것을 도메인이라고 하는 것이다. 위는 com 도메인 아래 tistory 도메인이 존재하고 그 아래 wonsjung 도메인 등을 가지는 구조이다.
- 이렇게 계층화된 도메인의 정보를 서버에 등록하며 하나의 도메인을 일괄적으로 취급한다.
- 즉 한 개의 도메인 정보를 일괄적으로 DNS 서버에 등록하고 도메인 한 대의 정보를 분할하여 복수의 DNS 서버에 등록하는 것은 불가능하다
www.cyber.co.kr이라는 도메인을 살펴보자면,
→ 최상위 kr이라는 도메인은 대한민국에 할당된 도메인이다.
→ 그리고 하위에 있는 co라는 도메인은 국내의 도메인을 분류하기 위해 설치된 도메인이며, 회사를 나타낸다.
→ 그 아래 cyber가 회사에 할당된 도메인이며,
→ 최하위의 www가 서버의 이름이다.
3-3. 담당 DNS 서버를 찾아 IP 주소를 가져온다
인터넷에는 DNS 서버가 수만 대나 있으므로 닥치는 대로 뒤지면서 다닐 수 없다. 그래서 다음과 같은 방법을 고안했다.
- 하위의 도메인을 담당하는 DNS 서버의 IP 주소를 그 상위의 DNS 서버에 등록한다.
- 그리고 상위의 DNS 서버를 또 그 상위의 DNS 서버에 등록하는 식으로 차례대로 등록한다.
- 재귀형태로 거슬러 올라간다.
인터넷의 도메인은 com이나 kr의 상위에 또 하나의 루트 도메인이라는 도메인이 존재한다. (보통 생략)
하위의 DNS 서버를 상위의 DNS 서버에 등록하여 루트 도메인에서 차례로 아래쪽으로 거슬러 내려갈 수 있다.
- 등록 작업은 한 가지 더 존재하는데 루트 도메인의 DNS 서버를 인터넷에 존재하는 DNS 서버에 전부 등록한다.
- 이렇게 해서 어느 DNS 서버에서도 루트 도메인에 엑세스할 수 있다
→ 그 결과 클라이언트에서 어딘가의 DNS 서버에 엑세스하면 여기에서부터 루트 도메인을 경유하여 도메인의 계층 아래로 찾아가서 최종적으로 원하는 DNS 서버에 도착한다.
위 그림을 해석하면 루트 도메인에는 www.lab.glasscom.com이라는 이름이 등록되어있지 않아 루트 도메인에서 com 도메인 아래 있다는 것을 알고 있기 때문에 com 도메인의 DNS 서버의 IP 주소를 반송한다.
3-4. DNS 서버는 캐시 기능으로 빠르게 회답한다.
현실은 위 그림처럼 각 도메인에 한 대씩 DNS 서버가 존재한다고 단정지을 수 없다. 그림에서는 도메인마다 따로 DNS 서버를 썼지만 현실에는 상위와 하위의 도메인을 같은 DNS 서버에 등록하는 경우도 있다.
이 경우 상위의 DNS 서버에 조회하면 DNS 서버를 한 개 건너뛰고, 다시 그 아래의 DNS 서버에 관한 정보가 돌아온다.
최상위 루트 도메인에서 차례대로 따라간다는 원칙대로 움직이지 않을 수도 있다. DNS 서버는 한 번 조사한 이름을 캐시에 기록할 수 있는데, 조회한 이름에 해당하는 정보가 캐시에 있으면 그 정보를 회답하기 때문이다.
이 캐시의 원리에는 한 가지 주의할 점이 있다. 캐시에 정보를 저장한 후 등록 정보가 변경되는 경우도 있으므로 캐시 안에 정보는 올바르다고 단언할 수 없다.
따라서 DNS 서버에 등록하는 정보에는 유효 기한을 설정하고, 캐시에 저장한 데이터의 유효 기간이 지나면 캐시에서 삭제한다.
4. 프로토콜 스택에 메시지 송신을 의뢰한다.
4-1. 데이터 송·수신 동작의 개요
- IP 주소를 조사했으면 IP 주소의 상대, 여기에서는 액세스 대상 웹 서버에 메시지를 송신하도록 OS의 내부에 있는 프로토콜 스택에 의뢰한다.
- 디지털 데이터를 송·수신하는 동작은 브라우저 뿐만 아니라 네트워크를 이용하는 애플리케이션 전체에 공통이다.
- 그러므로 이 동작은 웹에 한정되지 않고 모든 네트워크 애플리케이션에 해당된다. 이 동작을 추적한다.
- 여기에서도 DNS 서버에 IP 주소를 조회할 때와 같이 Socket 라이브러리에 들어있는 프로그램을 이용
[ Socket 라이브러리를 이용한 데이터 송·수신 동작 ]
- 데이터를 송·수신하는 컴퓨터 사이에 데이터의 통로 같은 것이 있고, 이것을 통해 데이터가 흐르면서 상대측에 도착한다.
- 한 쪽 끝에서 파이프에 데이터를 쏟아부으면 파이프 안을 통해 반대쪽 끝까지 도착하고, 거기에서 데이터를 추출할 수 있다.
- 데이터는 어느 쪽에서 쏟아부어도 상관 없고 양방향으로 흐를 수 있다.
- 송·수신 동작을 위해서는 송·수신하기 전에 양자 사이를 파이트포 연결하는 동작이 필요하다.
[ 클라이언트 - 서버의 파이프 연결 동작 ]
- 이 부분의 요점은 파이프의 양 끝에 있는 데이터의 출입구이다. 이 출입구를 소켓이라고 부르는데, 우선 소켓을 만들고 연결한다.
- 실제로는 먼저 서버측에서 소켓을 만들고, 소켓에 클라이언트가 파이프를 연결하기를 기다린다.
- 클라이언트 측에도 소켓을 만들고, 소켓에서 파이프를 늘려 서버측의 소켓에 연결한다.
[ 클라이언트 - 서버 파이프 해제 동작 ]
- 데이터를 전부 보내고나면 연결했던 파이프가 분리
- 연결할 때는 클라이언트 → 서버로 연결하였지만, 해제할 때는 어디에서든 해제 가능
[ 데이터 송·수신 동작 정리 ]
- 소켓을 만든다 (소켓 작성 단계)
- 서버측의 소켓에 파이프를 연결 (접속 단계)
- 데이터를 송·수신한다 (송·수신 단계)
- 파이프를 분리하고 소켓을 말소 (연결 끊기 단계)
→ 실행하는 것은 OS 내부의 프로토콜 스택
4-2. 소켓 작성 단계
- ①에서 socket 호출하여 소켓을 만든다.
- 소켓이 생기면 디스크립터를 받아 메모리에 기록해둔다. 디스크립터는 소켓을 식별하기 위해 사용하는 것이다.
ex) 브라우저에 2개의 창을 열어 2개의 웹 서버에 동시에 엑세스하는 경우 소켓을 식별해야 하는데 이 때 사용되는 것이 디스크립터
4-3. 파이프 연결하는 접속 단계
- 만든 소켓을 서버 측의 소켓에 접속하도록 프로토콜 스택에 의뢰
- 애플리케이션은 Socket 라이브러리의 connect라는 프로그램 부품을 호출하여 이 의뢰 동작을 실행
- connect를 호출할 때 지정하는 디스크립터, 서버의 IP 주소, 포트 번호 세 가지 값이 요점
IP주소는 네트워크에 존재하는 각 컴퓨터를 식별하기 위한 값이므로 소켓까지 지정할 수는 없다. 컴퓨터를 식별하여 위치를 알았다면 그 위치까지 도달해야 하는데 도달하기 위한 정보가 포트 번호인 것이다.
- 디스크립터 : 애플리케이션이 소켓을 식별하는 것
- IP 주소와 포트 번호 : 클라이언트와 서버 간에 상대의 소켓을 식별하는 것
4-4. 메시지를 주고 받는 송·수신 단계
소켓이 상대 측과 연결된 후 다음 작업
- 애플리케이션은 송신 데이터를 메모리에 준비한다.
- 사용자가 입력한 URL을 바탕으로 만든 HTTP의 레퀘스트 메시지가 여기에서 말하는 송신 데이터이다.
- write를 호출할 때 디스크립터와 송신 데이터를 지정하면 프로토콜 스택이 송신 데이터를 서버에게 송신
- 네트워크를 통해 전부 그대로 액세스 대상의 서버에 도착하면 서버는 수신 동작을 실행하여 받은 데이터의 내용을 조사하고 적절한 처리를 실행하여 응답 메시지 반송
- 해당 메시지가 돌아오면 이번에는 메시지를 송신한다. 수신할 때는 Socket 라이브러리의 read를 통해 프로토콜 스택에 수신 동작 의뢰
- 이 때 수신한 응답 메시지를 저장하기 위한 메모리 영역을 지정하는데 이를 수신 버퍼라고 한다
4-5. 연결 끊기 단계에서 송·수신이 종료
- 브라우저가 데이터를 수신하면 송수신 동작은 종료
- Scoket 라이브러리의 close를 호출하여 연결 끊기 단계 의뢰
- 웹 서버측에서 close를 호출하여 연결을 끊는다.
- 그러면 이것이 클라이언트 측에 전달되어 클라이언트의 소켓은 연결 끊기 단계로 진입
- 브라우저가 read로 수신 동작을 의뢰했을 때 read는 수신한 데이터를 건네주는 대신 송·수신 동작이 완료되어 연결이 끊겼다는 사실을 통지
지금까지 정리한 내용들이 HTTP의 본래 동작이다. HTTP 프로토콜은 HTML 문서나 영상 데이터를 하나하나 별도의 것으로 취급하여 1개의 데이터를 읽을 때마다 접속, 리퀘스트 메시지 송신, 응답 메시지 수신, 연결 끊기라는 동작을 반복해야 한다.
따라서 웹 페이지에 정보가 많이 포함되어 있으면 이러한 동작을 여러 번 반복한다.
HTTP 1.1버전에서는 한 번 접속한 후 연결을 끊지 않고 복수의 리퀘스트와 응답 주고받기를 실행할 수도 있다. 이 경우에는 리퀘스트 해야 할 데이터가 없어진 상태에서 브라우저에서 연결 끊기 동작을 수행할 수 있다.
'CS > 네트워크' 카테고리의 다른 글
| 액세스 회선이란, 엑세스 회선 과정, 프로바이더와 프로바이더를 경유하여 흐르는 패킷 (0) | 2023.07.26 |
|---|---|
| 허브와 스위치, 라우터의 동작 과정과 기능 (0) | 2023.07.25 |
| 서버에서 연결 끊고 소켓 말소, IP와 이더넷의 패킷 송·수신 동작 (0) | 2023.07.24 |
| 소켓을 이용한 데이터 송/수신 과정, TCP에서 오류 회복 조치가 필요 없는 이유, ACK와 윈도우 제어 (0) | 2023.07.22 |
| HTTP 통신과정, 리졸버를 이용한 DNS 서버에서 IP 조회하기 (0) | 2023.07.21 |