이 글은 2018년 2학기 아주대학교 Paul Rajib 교수님의 Computer Network 수업을 듣고 작성한 수업노트입니다. 부족한 내용이나 오류가 있을 수 있습니다.
FTP — File Transfer Protocol
FTP는 클라이언트가 서버에 접속해서 파일을 업로드, 다운로드, 삭제 등의 관리를 할 수 있는 프로토콜이다. TCP를 사용하며 포트는 20, 21번을 사용한다.
21번 포트는 Control Connection으로 사용되며, 클라이언트가 접속하는 동안 내내 유지된다. 파일을 업로드하거나 다운로드할 때마다 20번 포트로 Data Connection을 생성하고 데이터를 주고받은 뒤 연결을 해제한다. 이처럼 FTP는 용도에 따라 Connection이 분리되어있다.
DNS — Domain Name System
DNS는 naver.com같은 도메인 이름의 IP주소를 저장하고 클라이언트가 이 도메인명을 조회(Query)할 때 IP주소를 알려주는 역할을 한다. 터미널에서 nslookup 명령어로 도메인의 IP주소를 확인할 때에도 DNS 서버에 조회해서 알아내게 된다.
한 DNS 서버가 모든 도메인의 정보를 갖고있지 않으며, 여러 DNS 서버에 분산되어(Distributed)있다. 그렇기 때문에 클라이언트가 조회한 도메인을 DNS 서버가 갖고있지 않을 경우, DNS서버는 다른 DNS 서버에 조회하고 도메인 정보를 클라이언트에게 알려준다(Client-to-Server-to-Server 구조). 또 이 과정을 빠르게 하기 위해서 도메인을 그룹화하고 그룹마다 계층을 부여하게 된다.
도메인 계층 — DNS Hierarchy
도메인 주소가 mmcn.ajou.ac.kr 가 있다면 뒤에서부터 소속된 그룹을 알 수 있다. 먼저 .kr 이라는 그룹에 속하게 되며, 이 그룹은 첫번째 최상위 그룹으로 TLD(Top-Level Domain)이라고한다. kr외에도 .com, .org, .kr, .uk같은 클래스가 있다. 그리고 다시 .kr에 소속된 .ac가 이 도메인의 두번째 클래스이다. 이후에 ajou, mmcn 이 도메인에서 보다 하위 클래스가 된다.
이런식으로 도메인에 클래스별로 그룹을 나누고 상위 계층부터 하위 계층으로 점점 도메인 주소를 찾아가게 된다. mmcn.ajou.ac.kr의 경우 kr → ac.kr → ajou.ac.kr → mmcn.ajou.ac.kr 순으로 도메인 정보를 찾아가게 된다. 도메인 정보를 찾는 방식도 Iterative 방식과 Recursive 방식 2가지가 존재한다.
Iterative Query & Recursive Query
DNS 서버에 조회할 때 재귀적(Recursive) 방법과 반복적(Iterative) 방법 중 하나를선택할 수 있으며, 이에 DNS서버도 특정 방식을 거절할 수도 있다.
클라이언트가 로컬 DNS 서버에게 mmcn.ajou.ac.kr 의 IP주소를 조회했지만 DNS서버가 이를 모른다고 가정해보자. 이 경우 Root DNS 서버에 제일 먼저 조회한다. 하지만 Root DNS 서버는 이 도메인의 정보를 갖고 있지 않다. 그렇지만 하위 계층인 TLD들의 DNS서버를 알고있다. 이 경우 TLD는 kr이므로 .kr DNS서버를 알려준다. 이 응답을 받은 로컬 DNS서버는 다시 .kr에게 조회한다.
.kr은 마찬가지로 mmcn.ajou.ac.kr 주소를 모르고 보다 하위 도메인인 .ac.kr 의 DNS서버를 알려준다. 이런 식으로 로컬 서버 → kr → 로컬 서버 → ac.kr → 로컬 서버 → ajou.ac.kr → 로컬 서버 → mmcn.ajou.ac.kr 계층 순서대로 여러 DNS서버에게 직접 물어보며 알아내는 방식이 반복적인 방식이다.
재귀적인 방식은 처음에 루트 DNS 서버에게 물어볼 때 루트 DNS서버가 .kr의 DNS서버 주소를 알려주는 게 아닌, 자신이 직접 .kr 서버에게 물어보고 다시 .kr은 .ac.kr에게 물어보고, 이런 식으로 로컬 DNS 서버 → kr → ac.kr → ajou.ac.kr → mmcn.ajou.ac.kr 에게 물어보고 알아낸 결과를 mmcn.ajou.ac.kr → ajou.ac.kr → ac.kr → kr → 로컬 DNS서버 → 클라이언트에게 돌려주는 방식이다.
TTL (Time To Live)
DNS 서버가 클라이언트의 요청을 받을 때마다 다른 DNS서버를 조회하며 알려준다면 시간적으로도 오래 걸리고 네트워크 트래픽도 크게 증가할 것이다. 그래서 DNS서버는 도메인 조회 결과를 캐싱해두고 이 캐싱해둔 결과를 클라이언트에게 제공한다. 하지만 도메인에 해당하는 정보들은 바뀔 수 있기 때문에 주기적으로 캐싱된 값을 삭제하고 다시 조회해야한다. 이 캐싱된 값이 유지되는 시간을 TTL(Time To Live)라고 한다.
DNS Record Type
DNS 서버에 도메인을 조회하면 Record라 불리는 조회 결과를 알려준다. Record는 4개 종류(Type)로 나뉘며, 여러 Record가 결과에 포함될 수 있다. 하나의 도메인이 여러 IP주소를 가질 수 있고, 부가적인 정보도 이 결과에 포함된다.
- Type A
조회한 도메인의 IPv4 주소값을 의미한다. - Type AAAA
조회한 도메인의 IPv6 주소값을 의미한다. - Type CNAME
Canonical Name을 의미한다. 이는 해당 도메인의 ‘실제 도메인 주소’를 값으로 갖고있다. 예를 들어 구글이 전 세계에 서버가 있을 경우 유럽에서 google.com으로 DNS Query를 받으면 유럽 서버의 도메인 주소인 google.eu를 알려주고 더 가깝고 빠른 유럽 서버로 접속하게 만들어줄 수 있다. - Type NS
해당 도메인의 네임서버 도메인을 알려준다. 예를 들어 naver.com에 조회하면 naver.com의 네임서버인 ns2.naver.com을 레코드에 포함시켜주는데, 네이버와 관련된 도메인은 앞으로 여기로 조회하면 더 빠르게 찾을 수 있다는 의미이다.
이 외에도 다양한 종류들이 정의되어있다.
왜 DNS는 UDP를 사용할까?
DNS서버는 UDP를 사용하고 53번 포트를 이용한다. 도메인을 조회할 때 여러 타 DNS서버에게 지속적으로 조회를 하게되는데, 이 때 TCP를 사용한다면 조회할 때마다 DNS 서버 사이에서 수많은 TCP 연결상태가 만들어질 것이다. 도메인 조회는 단순히 한번 결과를 받기만 하면 되므로 다시 연결을 해제할 것이며, 이로인해서 도메인을 조회하는데 걸리는 시간이 크게 증가하게된다. 또 전송되는 데이터의 작아 UDP 세그먼트에 잘 들어가며, UDP를 써도 어플리케이션 레이어에서 다양한 방법으로 데이터의 변형을 감지해내고 다시 요청을 보내면 된다.
