DNS Server를 통해 특정 주소의 IP Address를 알아낸다고 했는데, 그럼 DNS Server는 어떻게 IP Address를 저장하고 관리할까?
우선, 임의의 서버 호스트가 본인의 IP Address를 www.example.com이라는 주소로 등록하고 싶다고 요청을 한다. 이 요청과 등록의 과정은 아래에서 더 자세히 살펴보자.
그럼 DNS Server랑은 어떻게 통신할까?
당연히 DNS Server도 Server이기 때문에 호스트이고 호스트와 통신을 하려면 주소가 필요하다. 이 DNS Server의 주소는 컴퓨터에 네트워크를 연결하는 순간 해당 컴퓨터에 DNS Server IP가 바로 할당된다. 그래서 모든 컴퓨터의 운영체제는 인터넷이 연결된 순간 DNS Server와 통신이 가능하게 된다.
이건 통신사가 제공하는 DNS Server와 연결되는 것인데 내가 원하는 DNS Server로 바꿀 수도 있다. 이는 Public DNS Server를 이용하면 된다.
그럼 이제 인터넷이 연결된 호스트는 Part 2에서 언급했던 hosts 파일과 연결된 DNS Server를 통해 특정 주소에 대한 IP를 얻어내고 해당 주소를 가지는 호스트와 통신을 하게 된다. 이것이 동작원리이다.
DNS Internal
본 페이지의 개요에서 DNS Server라는 특정 서버와 임의의 호스트가 연결되는 원리를 알아보았는데, 그럼 과연 DNS Server는 단 한대만 존재할까? 아니다. DNS Server는 수십만 대가 있고, 각 서버마다 역할 또한 다르다.
도메인 구조가 생각보다 여러 파트로 나뉜다.
cwchoiit.tistory.com.이라는 주소가 있으면 이 주소가 네 파트로 나뉜다.
위 그림에서 각 영역별로 담당하는 DNS Server가 다 다르다.
그러나 명확한 한 가지는 있다. Root DNS Server는 Top level DNS Server의 리스트를 가지고 있고 Top level DNS Server는 Second DNS Server의 리스트를 가지고 있고 Second level DNS Server는 Sub DNS Server 리스트를 가지고 있고 모든 호스트의 연결된 DNS Server는 최소한 Root DNS Server의 주소는 반드시 알고 있다.
이러한 구조를 알고 있는 상태에서 만약 내가 cwchoiit.tistory.com. 에 접속하고자 한다면 과정은 아래와 같다.
1. 내 컴퓨터(호스트)는 Root DNS Server에게 해당 주소를 물어본다.
2. Root DNS Server는 호스트에게 ". com"이라는 Top level을 관리하는 Top level DNS Server의 IP를 준다.
3. 호스트는 Top level DNS Server에게 해당 주소를 물어본다.
4. Top level DNS Server는 "tistory"라는 Second level을 관리하는 Second level DNS Server의 IP를 준다.
5. 호스트는 Second level DNS Server에게 해당 주소를 물어본다.
6. Second level DNS Server는 "cwchoiit"라는 Sub level을 관리하는 Sub level DNS Server의 IP를 준다.
7. 호스트는 Sub level DNS Server에게 해당 주소를 물어본다.
8. Sub level DNS Server가 cwchoiit.tistory.com. 의 실제 IP 주소를 알려준다.
이러한 세부적인 과정을 거쳐 최종적으로 원하는 IP를 돌려받고 해당 호스트와 통신하게 된다.
도메인 이름 등록 과정과 원리
위 그림을 통해 간단하게 도메인 등록 과정과 원리를 살펴보자. 사실 크게 중요한가 싶긴 하다만(?) 알고 나니 좀 더 기분이 좋아지긴 했다.
일단 최초에 등록자(Register)가 11.22.33.44라는 IP Address를 example.com이라는 주소로 등록하고 싶다고 가정해 보자.
그럼 등록 대행자(Registrar)에게 (gabia.com 같은) 해당 IP를 알려주어야 한다. 등록 대행자는 자신들이 가지고 있는 DNS Server에 해당 IP를 example.com으로 등록하고 그 정보를 ICANN이라는 기관에 알려준다. 이 기관은 Root DNS Server의 모든 리스트를 가지고 있고 Root DNS Server에게 이렇게 말한다.
"이 example.com이라는 주소를 등록할 건데 너는 Root니까. com을 관리하는 Top level DNS Server에게도 이 사실을 알려줘!"
그럼 ICANN의 Root DNS Server들 중 하나가 Top level DNS Server의 주소를 알려주고 그 Top level DNS Server가 example이라는 Second level domain을 가지는 DNS Server의 주소를 가지게 된다. 그 DNS Server는 바로 등록대행자가 가지고 있는 DNS Server가 된다.
1. 그러니까 Root DNS Server는. com을 관리하는 Top level DNS Server의 주소를 가지게 되고2. .com을 관리하는 Top level DNS Server는 example을 관리하는 Second level DNS Server의 주소를 가지게 되고3. Second level DNS Server는 곧 등록대행자가 가지고 있는 DNS Server인데 이 서버가 example.com의 실제 IP 주소를 가지고 있게 되는 구조다.
이런 식으로 등록을 완료하게 되면 이제 특정 호스트에서 example.com에 접속하기 위해 해당 호스트의 운영체제가 가지고 있는 DNS Server에게 물어본다. 그렇게 물어보면 위 1 - 8까지의 과정을 거쳐 해당 사이트에 접속하게 된다.
A / NS / CNAME Record
위 그림에서 보면 A, NS라는 키워드가 사용되었는데 그 부분을 알아보자.
우선 위 그림에서 example.com A 11.22.33.44example.com NS a.lana-servers.net 이런 한 줄 한 줄이 눈에 보일 것이다.
이런 한 줄을 "레코드"라고 한다.
A는 IP Address를 의미하고 NS는 Name Server를 의미하는데 레코드 타입이 NS인 경우 해당 주소를 저장한 Name Server가 무엇인지 알려주는 레코드가 되는 것이다.
쉽게 말해
example.com A 11.22.33.44라는A 레코드는 example.com의 IP가 11.22.33.44라는 것을 의미한다.
example.com NS a.lana-servers.net이라는NS 레코드는 example.com이라는 주소를 저장한 네임서버가 a.lana-servers.net이라는 것을 의미한다.
Part 1에서 호스트와 호스트가 통신을 하기 위해서는 IP Address를 알아야 한다고 했고, IP Address 알기 위해 도움을 주는 것이 DNS, DNS Server라고 했다. 근데 DNS Server가 아니어도 알아내는 방법이 있다. hosts 파일을 이용하는 것.
반응형
SMALL
hosts file
모든 운영체제에서 기본으로 가지고 있는 파일인 hosts 파일은 특정 IP Address와 특정 도메인 주소를 연결하여 매핑해놓은 파일이다.
예를 들어, 121.138.177.1이라는 IP Address를 www.example.com 으로 매핑했다면 그리고 그 매핑한 파일을 가지고 있는 호스트는 브라우저에 www.example.com을 입력했을 때, DNS Server를 거치지 않고 121.138.177.1이라는 주소로 연결하게 된다.
이게 hosts file의 역할이다. 내 PC에서는 hosts 파일 경로는 다음과 같다. /private/etc/hosts
그리고 이 파일을 실제로 열어보면 다음과 같이 생겼다.
그리고 이 파일의 우선순위가 DNS Server보다 높다. 그렇기에 유저가 브라우저를 통해 어떤 주소를 입력하고 응답받기까지의 과정은 다음과 같다.
1. 유저가 특정 주소를 입력
2. 운영체제는 hosts 파일을 확인
3-1. hosts 파일에 해당 주소와 매핑된 IP Address가 있다면 그 IP Address로 접근
3-2. hosts 파일에 해당 주소와 매핑된 IP Address가 없으면 DNS Server에게 해당 주소의 정보를 요청
그래서 결론은 만약 특정 호스트에서 특정 주소를 입력했을 때, 그 주소 정보가 hosts 파일에 있다면 hosts 파일의 정보를 기반으로 접근하고 그렇지 않으면 DNS Server를 통해 주소를 접근한다.
그러나 이 파일의 한계는 뚜렷하다. 첫 번째 한계는 hosts 파일은 가장 먼저 그 정보를 저장한 호스트에만 적용되는 내용이다. 내가 가진 PC(A)와 다른 누군가가 가진 PC(B)의 hosts 파일 내용은 상이하다. 즉, A와 B가 가리키는 hosts 파일에 적힌 동일한 주소마저도 다른 IP Address를 가질 수 있다.
두 번째 한계는 보안상 매우 취약하다. 만약 내가 hosts 파일에 금융 관련 주소를 입력해서 사용하고 있는데 누군가 그것을 알아내서 hosts 파일을 자기들이 복제해 만든 피싱 사이트로 변경한다고 해도 감쪽같이 속을 수 있다.
그리고 이 호스트와 호스트가 통신하기 위해서는 서로간의 주소가 필요한데 이 주소를 IP Address라고 한다.
이렇게 처음에 IP Address가 세상에 나왔을 때 사람들은 IP Address를 통해 호스트(서버)끼리 통신이 가능해졌기 때문에 만족했지만 얼마 지나지 않아 불만이 생기기 시작했는데 그 불만은 IP Address를 외우기 너무 어렵다는 것이다.
이 불만(문제)를 해결하기 위해 탄생한 것이 DNS(Domain Name System)이다. DNS는 쉽게 IP Address를 사람들이 기억하기 쉽게 이름을 부여한 시스템을 말한다. 예를 들면 www.naver.com 이 주소가 DNS이다.
DNS 얘기를 할 때 빠질 수 없는 것이 DNS Server인데 DNS Server가 하는 역할은 특정 호스트에서 특정 주소(예: www.naver.com)를 입력하면 호스트의 운영체제는 DNS Server에게 해당 주소와 매핑된 IP Address가 무엇인지 물어본다. DNS Server는 해당 주소와 매핑된 IP Address를 돌려주면 그 주소를 통해 호스트와 해당 주소를 가지는 호스트가 통신을 할 수 있게 된다. 이렇듯 중간에서 특정 주소의 IP Address를 저장하고 그 내용을 호스트에게 알려주는 역할을 하는 것이 DNS Server이다.
그리고 이렇게 IP Address와 특정 주소(예: www.naver.com)을 엮은 하나하나를 DNS Record라고 한다.
RDBS를 사용해 개발하던 중에 칼럼 형식으로부터의 자유로움의 필요성을 느끼고 MongoDB를 공부하기 시작했다.
MongoDB와 잘 맞는 Javascript를 사용해 간단한 Blog Service를 구축해 보면서 MongoDB와 친해져 보자.
Getting Started
npm init -y
package.json 파일을 우선 만들고, dependencies를 추가하자.
npm i typescript --save-dev
npm i express --save
이후에 typescript 설정 파일을 생성하기 위해 아래 커맨드를 실행하자.
npx tsc --init
이 커맨드는 tsconfig.json 파일을 작업하고자 하는 프로젝트 경로의 루트에 생성해 주는데, 어떤 식으로 typescript 코드를 javascript 코드로 컴파일할지에 대한 여러 옵션을 지정하고 있다. 언제든지 수정이 가능하지만 기본 옵션으로 우선 진행하자.
Setup Express server
이제 차근차근 하나씩 Express 서버를 구축해 보자. 우선 나는 Typescript를 사용할 거니까, express의 type definition file을 내려받자.
npm i @types/express --save-dev
프로젝트 루트 경로에 src폴더를 만들고 index.ts파일을 하나 생성하자.
src/index.ts
import express from 'express';
const app = express();
app.listen(3000, function () {
console.log('server listening on port 3000');
});
Express server는 3000번 포트로 기동 하게끔 설정했고, 실행 후 callback 함수로 간단한 log를 찍어주었다.
일단 서버가 실행이 정상적으로 되는지 확인해 보자.
Node가 typescript 코드를 다이렉트로 실행하지 못하기 때문에 javascript로 컴파일해주어야 한다는 것을 다시 한번 인지하고 이를 도와주는 ts-node라는 패키지를 내려받자. ts-node는 Node로 Typescript를 다이렉트로 실행하게 도와주는 패키지인데 나는 어떤 코드의 변경사항이 생길 때 서버를 재기동하게끔 ts-node-dev를 내려받을 거다. ts-node-dev는 그냥 nodemon과 같은 녀석이라고 생각하면 된다.
npm i ts-node-dev --save-dev
이제 package.json 파일에서 script 부분을 수정하자.
ts-node-dev로 src/index.ts 파일을 실행하게끔 "dev"라는 커맨드를 추가했고, 이제 서버를 실행해 보자.
실행하면 정상적으로 아래 같은 로그가 출력되는 걸 확인할 수 있다.
server listening on port 3000
Connect to MongoDB
이제, MongoDB를 연동해 보자. MongoDB를 연동하기 위해 mongoose라는 패키지를 내려받자.
import express from 'express';
import mongoose from 'mongoose';
const app = express();
const MONGO_URI =
'mongodb+srv://<username>:<password>@tutorial.qzgcfiu.mongodb.net/BlogService?retryWrites=true&w=majority&appName=AtlasApp';
const start = async () => {
try {
await mongoose.connect(MONGO_URI);
mongoose.set('debug', true);
console.log('MongoDB connected !');
app.listen(3000, function () {
console.log('server listening on port 3000');
});
} catch (error) {
console.log(error);
}
};
start();
Mongo Atlas에서 데이터베이스 만들고, Connect > Compass를 누르면 나한테 연결할 URI를 알려준다.
이렇게 연결을 하고 나서, 다시 재실행을 해보면 아래와 같은 로그가 찍히는 걸 확인할 수 있다.
MongoDB connected !
server listening on port 3000
그럼 성공적으로 연결은 다 끝난 상태이다. 이제 라우팅 및 API를 작업해 보자.
Setup routes
라우트를 작업하기 앞서, 우선 한 가지 미들웨어를 설정해줘야 하는데 express의 json이라는 녀석이다. 이 녀석은 쉽게 말해 외부의 요청이 들어올 때 전달되는 payload의 데이터가 Json 형식의 데이터가 들어오면 그것을 파싱 해주는 미들웨어라고 생각하면 된다. 즉, Json 데이터를 받아줄 수 있는 미들웨어.
import express from 'express';
import mongoose from 'mongoose';
const app = express();
const MONGO_URI =
'mongodb+srv://chiwon99881:VM3j4MQVKrMWW6K3@tutorial.qzgcfiu.mongodb.net/BlogService?retryWrites=true&w=majority&appName=AtlasApp';
const start = async () => {
try {
await mongoose.connect(MONGO_URI);
mongoose.set('debug', true);
console.log('MongoDB connected !');
app.use(express.json()); // 이 부분
app.listen(3000, function () {
console.log('server listening on port 3000');
});
} catch (error) {
console.log(error);
}
};
start();
이제 유저의 스키마 작업, 라우트 작업, API를 만들어보자.
우선, src/model/user라는 폴더를 만들고 해당 폴더에서 user.ts파일을 만들자.
이제 MongoDB에게 알려줄 User Schema를 만든다. 이 유저 스키마 정보는 곧 나의 데이터베이스의 Collection으로 만들어지게 된다.
username에서는 unique: true라는 옵션을 넣어주어서 같은 username을 가지는 유저를 방지하게 하고, timestamp: true라는 옵션을 넣어서 새로운 user document가 생성될 때마다 createdAt 데이터가 자동으로 추가되고 변경 시 updatedAt 정보를 갱신하게끔 만들어 주었다.
이제 mongoose패키지에서 model이라는 모듈을 import 하여 User모델을 mongoDB에게 알려준다. collection이름을 user라고 명시하였는데 이렇게 하면 실제로는 데이터베이스에 users라는 복수명으로 표시되어 만들어진다.
생성한 User model을 export default로 내보내자.
이렇게 만든다고 바로 MongoDB Compass에 collection이 보이지는 않는다. collection에 데이터가 실제로 추가가 되면 그때 비로소 collection이 나타나게 된다. 이를 확인하기 위해 router도 만들고 실제로 API를 구현해서 데이터를 생성해 보자.
router를 만들기 앞서, /src/model/index.ts파일을 만들고 model의 패키지의 모든 모델들을 한 번에 export 하게끔 해보자.
다른 파일에서 model의 특정 파일을 명시하지 않으면 기본적으로 model패키지의 index파일을 찾게 된다. 이를 이용해서 편리하게 export 해보자.
/src/model/index.ts
import User from './user/user';
export { User };
이제 모델 패키지에 새로운 모델들이 만들어질 때마다 항상 이 파일에서 export 해주면 다른 파일에서 원하는 모델을 불러오고 싶을 때 index.ts파일을 통해 불러올 수 있다. 이는 이후에 새로운 모델이 생성된 후에 더 자세히 알아보자.
이것과 유사하게 routes 패키지도 같은 방식으로 처리해 줄 수 있다.
import { userRouter } from './user/userRoute';
export { userRouter };
이러한 쓰임새는 바로 다음 /src/index.ts 파일에 사용되는 routes 패키지를 import 하는 부분에서 확인할 수 있다.
/src/routes/user/userRoute.ts 파일을 생성하자.
import { Router } from 'express';
import mongoose from 'mongoose';
import { User } from '../../models';
export const userRouter = Router();
// Create user
userRouter.post('/', async function (req, res) {
try {
const { username, name } = req.body;
if (!username)
return res.status(400).send({ error: 'username is required' });
if (!name || !name.first || !name.last)
return res
.status(400)
.send({ err: 'Both first and last name are required' });
const user = new User(req.body);
await user.save();
return res.send({ success: true, user });
} catch (e: any) {
console.log(e);
return res.status(500).send({ error: e.message });
}
});
위 코드는 새로운 유저를 생성하는 API를 구현한 코드이다. 내가 구현할 유저 관련 API는 생성, 읽기, 수정, 삭제이다.
우선 POST 메서드로 REST API를 구현하고 Path는/users이다.
request의 body를 통해 username, name을 받는다. 이 코드에서는 email, age는 따로 검증하지 않았다.
username이 없으면응답 코드를 400,에러 메시지를 "username is required"로 반환하기로 했고 name이 없거나 name의 first, last값이 없으면 역시응답 코드를 400,에러 메시지를 "Both first and last name are required"로 반환하기로 한다.
위 검증을 모두 통과하면 유저를 생성하고 저장한다.user.save()를 실행하면 MongoDB에 해당 데이터가 저장이 된다.
모든 과정을 마치면, res.send()에 생성된 유저 정보를 넣어 반환한다.
위 코드에서는 "/" 이렇게만 설정되어 있지만 Express app을 실행하는 부분에서 (src/index.ts) users라는 context를 설정해 줄 것이다. 아래 코드를 확인해 보자.
/src/index.ts
import express from 'express';
import mongoose from 'mongoose';
import { userRouter } from './routes';
const app = express();
const MONGO_URI =
'mongodb+srv://chiwon99881:VM3j4MQVKrMWW6K3@tutorial.qzgcfiu.mongodb.net/BlogService?retryWrites=true&w=majority&appName=AtlasApp';
const start = async () => {
try {
await mongoose.connect(MONGO_URI);
mongoose.set('debug', true);
console.log('MongoDB connected !');
app.use(express.json());
app.use('/users', userRouter); // 이 부분
app.listen(3000, function () {
console.log('server listening on port 3000');
});
} catch (error) {
console.log(error);
}
};
start();
Test create user
이제 생성 관련 API를 만들었으니 테스트해보자. 테스트를 해보기 위해 Postman을 사용해 보자.
Method는 POST, URL은 http://localhost:3000/users로 설정한 후 아래와 같이 body payload를 설정한 후 Request 해보자.
응답의 결과로 아래와 같은 화면을 돌려받을 수 있다.
정상적으로 데이터를 만든 API를 통해 주고받았고 데이터베이스에도 해당 데이터가 저장되었는지 확인하기 위해 MongoDB Compass를 실행해서 확인해 보자.
데이터베이스에도 정상적으로 데이터가 저장된 것을 확인할 수 있다. 저 데이터 형식에서 _id는 MongoDB에서 생성해 주는 고유값이다. 해당 id가 곧 RDBS에서 primary key라고 생각할 수 있는데, 우리는 저 key를 통해 각 유저를 조회하는 API도 만들 것이다.
한 가지 더 해보고 넘어갈 것은 또 다른 collection을 만들고 collection 사이의 관계를 맺어보는 것이다.
Blog collection
이제 새로운 collection하나를 더 만들어보자. 이 blog collection은 데이터로 유저 정보도 가지게 된다. 어떤 유저가 이 블로그의 주인인지를 알기 위해.
위 코드에서 확인할 것은 Blog라는 Schema의 데이터 중 user이다. 이렇게 collection끼리 관계를 갖게 할 수 있는데 그러기 위해선 ref라는 옵션을 사용해서 어떤 collection을 가리키는지 알려주어야 한다. User model을 저장할 때 model이름으로 'user'로 저장한 것과 똑같은 값인 'user'를 ref의 value로 설정해 주면 된다. 그리고 또 한 가지 유저의 type으로 mongoose.Types.ObjectId를 받는다. 이 ObjectId는 아까 MongoDB Compass에서 봤던 것처럼 고유값인 _id를 가리킨다.
이제 Blog collection을 생성했으니 연관된 API도 하나만 만들어보자.
/src/routes/blog/blogRoutes.ts
import { Router } from 'express';
import { Blog, User } from '../../models';
import mongoose from 'mongoose';
export const blogRouter = Router();
// Create blog
blogRouter.post('/', async (req, res) => {
try {
const { title, content, isLive, userId } = req.body;
if (!title) return res.status(400).send({ error: 'title is required' });
if (!content) return res.status(400).send({ error: 'content is required' });
if (isLive && typeof isLive !== 'boolean')
return res.status(400).send({ error: 'isLive must be a boolean value' });
if (!mongoose.isValidObjectId(userId))
return res.status(400).send({ error: 'Invalid user id' });
const user = await User.findOne({ _id: userId });
if (!user) return res.status(400).send({ error: 'User does not exist' });
const blog = new Blog({ ...req.body, user });
await blog.save();
return res.status(201).send({ blog });
} catch (e: any) {
console.log(e);
res.status(500).send({ error: e.message });
}
});
