Application Layer

Study, Computer Network

Computer Network Application Layer

Posted Aug 1, 2021

네트워크 애플리케이션 원리

네트워크 애플리케이션 개발의 중심은 다른 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것임.

예를 들어, 웹 애플리케이션에는 클라이언트(사용자의 호스트에서 실행되는 브라우저 프로그램)와 서버(웹 서버 호스트에서 실행되는 웹 서버 프로그램)로 구별되는 두 프로그램이 있음.

따라서 새로운 애플리케이션을 개발할 때는 여러 종단 시스템에서 실행되는 소프트웨어를 작성할 필요가 있음.

단, 라우터나 링크 계층 스위치 등 네트워크 코어 장비에서 실행되는 소프트웨어는 예외임.

네트워크 애플리케이션 구조

애플리케이션 구조
- 개발자에 의해 설계되었고, 애플리케이션이 다양한 호스트에서 어떻게 조직되어야 하는지 지시함.
- 두 가지 방식이 있는데, 클라이언트-서버 구조와 P2P구조가 있음.

클라이언트-서버 구조
- 클라이언트는 서로 직접적으로 통신하지 않음 -> 웹에서는 두 개의 브라우저가 직접적으로 통신 x
- 서버가 고정 IP주소라는 잘 알려진 주소를 갖음.
- 하나의 서버 호스트가 자신의 클라이언트로부터의 모든 요청에 응답하는 것은 불가능. 따라서 데이터센터를 사용.

P2P 구조
- 항상 켜저 있는 기반구조 서버에 최소로 의존
- 애플리케이션은 피어(peer) 라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하도록 함.
  - 특정 서버를 통하지 않고 피어가 통신하므로 이 구조를 peer to peer, P2P 라 함.
- 자가 확장성(self-scalability) 이 있는데, 이는 각 피어들이 파일을 요구함으로써 작업 부하를 만들어 내지만 각 피어들은 또한 파일을 다른 피어들에게 분배함으로써 그 시스템에 서비스 능력을 추가함.
- 즉, peer끼리 서비스를 주고 받음.
- 상당한 서버 기반구조와 서버 대역폭을 요구하지 않기 때문에 (데이터센터의 클라이언트-서버 구조와는 대조적으로) 비용이 효율적임.

프로세스 간 통신(중요)

네트워크 애플리케이션 개발 전 여러 end system에서 실행하는 프로그램이 서로 통신하는 방법을 이해해야 함.

운영체제 용어에서 실제로 통신하는 것은 프로그램이 아니라 프로세스임.

프로세스는 end system 에서 실행되는 프로그램임.

통신 프로세스가 같은 호스트에서 실행될 때, 그들은 서로 프로세스 간에 통신하는 것임.

2개의 다른 호스트에서 프로세스는 컴퓨터 네트워크를 통한 메시지 교환으로 서로 통신함.

송신 프로세스는 메시지를 만들어서 네트워크로 보냄. (수신 프로세스는 메시지를 받고 역으로 메시지를 보냄으로써 응답함.)

클라이언트와 서버 프로세스

네트워크 애플리케이션은 네트워크에서 서로 메시지를 보내는 두 프로세스로 구성됨.

웹에서 브라우저는 클라이언트 프로세스, 웹 서버는 서버 프로세스.
P2P에서 파일을 내려받는 피어는 클라 프로세스, 파일 올리는 피어는 서버 프로세스.

정의하면 다음과 같음.: 두 프로세스 간의 통신 세션에서 통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을 초기화)하는 프로세스를 클라이언트라 하고, 세션을 시작하기 위해 접속을 기다리는 프로세스를 서버라고 한다.

프로세스와 컴퓨터 네트워크 사이의 인터페이스

프로세스는 소켓을 통해 네트워크로 메시지를 보내고 받음.

소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층 간의 인터페이스임.

또한 소켓은 네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이의 API(Application Programming Interface)라고도 함.

프로세스 주소 배정

한 호스트상에서 수행되고 있는 프로세스가 패킷을 다른 호스트에서 수행되고 있는 프로세스로 패킷을 보내기 위해서는 수신 프로세스가 주소를 갖고 있어야 함.

수신 프로세스를 식별하기 위해 두 가지의 정보가 명시되어야 함.

첫 번째는 목적지 호스트 주소
두 번째는 목적지 호스트 내의 수신 프로세스를 명시하는 식별자

인터넷에서 호스트는 IP 주소로 식별됨.

송신 호스트는 메시지가 전달되어야 하는 수신 호스트의 주소와 수신 호스트에서 수행되고 있는 수신 프로세스도 식별해야 함.

여기서 목적지 포트 번호가 수신 프로세스 식별을 위해 사용됨.

애플리케이션이 이용 가능한 트랜스포트 서비스

트랜스포트 계층 프로토콜(TCP, UDP)이 그것을 이용하는 애플리케이션들에게 제공할 수 있는 서비스는 크게 4가지임.

넓은 범위에서 가능한 서비스들을 신뢰적 데이터 전송, 처리율, 시간, 보안이라는 네 가지 차원으로 분류할 수 있음.

신뢰적 데이터 전송
- 전자메일, 파일 전송 등과 같은 파일 데이터가 손실되면 위험한 결과를 초래할 수 있는 애플리케이션에게 트랜스포트 계층 프로토콜이 보장된 데이터 전송 서비스를 제공해주는 것을 말함.
- 트랜스포트 계층 프로토콜이 신뢰적 데이터 전송을 제공하지 않을 때(UDP), 송신 프로세스가 보낸 데이터는 수신 프로세스에 전혀 도착하지 않을 수 있음.
  - 이런 경우에는 손실 허용 애플리케이션(loss-tolerant application) 의 경우(실시간 or 저장 비디오/오디오)에는 받아들여질 수 있음.

처리량
- 가용한 처리율: 네트워크 경로를 따라 두 프로세스 간의 통신 세션에서 송신 프로세스가 수신 프로세스로 비트를 전달할 수 있는 비율.
- 다른 세션들이 네트워크 경로를 따라 대역폭을 공유, 이 세션들이 생겼다 없어졌다 하기 때문에 가용한 처리율은 시간에 따라 변동함.
- 이를 통해 트랜스포트 계층 프로토콜은 어느 명시된 속도에서 보장된 가용 처리율을 제공한다는 것을 알 수 있음.
- 이런 서비스를 통해 애플리케이션은 r bits/sec 속도의 보장된 처리율을 요구할 수 있고, 트랜스포트 계층 프로토콜은 가용한 처리율이 항상 적어도 r bps 임을 보장함.
- 처리율 요구 사항을 갖는 애플리케이션을 대역폭 민감 애플리케이션(bandwidth-sensitive application) 이라 하고, 가용한 처리율이 많으면 많은대로, 적으면 적은대로 이용할 수 있는 애플리케이션을 탄력적 애플리케이션(elastic app) 이라 함.
  - 예를 들어 전자메일, 파일 전송, 웹 전송 등이 융통성 있는 애플리케이션. 물론 대역폭은 많으면 많을수록 좋음.

시간
- 트랜스포트 계층 프로토콜은 시간 보장(timing guarantee)을 제공할 수 있음.
- 인터넷 전화, 가상 환경, 원격 회의, 멀티플레이어 게임과 같은 상호 작용 실시간 애플리케이션은 시간에 민감함.

보안
- 트랜스포트 프로토콜은 애플리케이션에 하나 이상의 보안 서비스를 제공할 수 있음.
- 예를 들어, 송신 호스트에서 트랜스포트 프로토콜은 송신 프로세스가 전송하는 모든 데이터를 암호화 할 수 있음.

인터넷 전송 프로토콜이 제공하는 서비스

인터넷(그리고 일반적인 TCP/IP 네트워크)은 애플리케이션에게 2개의 전송 프로토콜을 제공함.

UDP(User Datagram Protocol)과 TCP(Transmission Control Protocol)가 있음.

TCP 서비스

TCP 서비스 모델은 연결지향형(connection-oriented) 서비스와 신뢰적인 데이터 전송 서비스를 포함함.

애플리케이션은 TCP로부터 두 가지의 서비스를 받음.

연결지향형 서비스
- 애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환하도록 함.
  - 이를 핸드셰이킹 과정이라 하며 이 과정에서 클라이언트와 서버에게 패킷이 곧 도달할 것이니 준비하라고 알려줌.
- 핸드셰이킹 단계 후 TCP 연결이 두 프로세스 간에 형성되는데, 이 연결은 두 프로세스가 서로에게 동시에 메시지를 보낼 수 있기에 전이중(full-deplex) 연결이라 함.

신뢰적인 데이터 전송 서비스
- 통신 프로세스는 모든 데이터를 오류 없이 올바른 순서로 전달하기 위해 TCP에 의존함.
- 애플리케이션의 한쪽이 바이트 스트림을 소켓으로 전달하면 그 바이트 스트림을 손실하거나 중복되지 않게 수신 소켓으로 전달함.

이외에도 TCP는 혼잡제어 방식, 즉 통신하는 프로세스의 직접 이득보다는 인터넷의 전체 성능 향상을 위한 서비스를 포함함.

TCP 혼잡제어 방식은 네트워크가 혼잡상태에 이르면 프로세스(클라이언트 또는 서버) 속도를 낮춤.

특히 각 TCP 연결이 네트워크 대역폭을 공평하게 공유할 수 있게끔 제한하려고 시도함.

UDP 서비스

UDP는 비연결형이므로 두 프로세스가 통신을 하기 전에 핸드셰이킹을 하지 않음.

UDP는 비신뢰적인 데이터 전송 서비스를 제공함.

즉, 하나의 프로세스가 UDP 소켓으로 메시지를 보내면 UDP는 그 메시지가 수신 소켓에 도착하는 것을 보장하지 않음.

게다가 수신 소켓에 도착하는 메시지들의 순서가 바뀔수도 있음.

반면에 UDP는 혼잡제어 방식을 포함하지 않으므로 UDP의 송신 측은 데이터를 원하는 속도로 하위 계층(네트워크 계층)에 보낼 수 있음.

애플리케이션 계층 프로토콜

애플리케이션 계층 프로토콜은 다음과 같은 내용을 정의함.

교환 메시지 타입 (예 : 요청 메시지와 응답 메시지)
여러 메시지 타입의 문법 (예 : 메시지 내부의 필드와 필드 간의 구별 방법)
필드의 의미, 즉 필드에 있는 정보의 의미
언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지 결정하는 규칙

네트워크 애플리케이션과 애플리케이션 계층 프로토콜을 구별하는 것은 중요함.: 애플리케이션 계층 프로토콜은 네트워크 애플리케이션의 한 요소일 뿐임.

웹은 사용자가 필요에 따라 웹 서버로부터 문서를 얻게 해주는 네트워크 애플리케이션임.: 웹 애플리케이션 계층 프로토콜로 HTTP은 웹 애플리케이션의 한 요소일 뿐임.

웹과 HTTP

HTTP 개요

웹 페이지는 객체들로 구성됨.

객체는 단순히 단일 URL로 지정할 수 있는 하나의 파일(HTML 파일, JPEG 이미지 등)임.

대부분의 웹 페이지는 기본 HTML 파일과 여러 참조 객체로 구성됨.

HTTP는 TCP를 전송 프로토콜로 사용함.

HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작하며 연결이 이루어지면, 브라우저와 서버 프로세스는 그들의 소켓 인터페이스를 통해 TCP로 접속함.

HTTP 서버는 클라이언트에게 요청 파일을 보낼 때, 서버는 클라이언트에 관한 어떠한 상태 정보도 저장하지 않는데, 이런 상태를 비상태 프로토콜(stateless protocol) 이라 함.

비지속 연결과 지속 연결

많은 인터넷 애플리케이션에서 클라이언트와 서버는 서로 상당 기간 통신을 함.

이때 서로가 보내는 일련의 요구가 계속해서, 일정한 간격으로 주기적으로 혹은 간헐적으로 만들어질 수 있음.

이런 상황에서 개발자는 중요한 결정을 할 필요가 있음.

각 요구/응답 쌍이 분리된 TCP 연결을 통해서 보내져야 하는가?
모든 요구와 응답들이 같은 TCP 연결상으로 보내져야 하는가?

전자의 경우를 비지속 연결(non-persistent connection), 후자의 경우를 지속 연결(persistent connection) 이라고 함.

HTTP는 기본 모드로 지속 연결을 사용하지만, 비지속 연결을 사용하도록 설정할 수 있음.

비지속 연결 HTTP

웹 페이지를 서버에서 클라이언트로 전송하는 단계를 통해 살펴보면 다음과 같음.

페이지가 기본 HTML 파일과 10개의 JPEG 이미지로 구성되고, 이 11개의 객체가 같은 서버에 있다고 가정.

기본 HTML URL은 http://www.example.com/example1/home.index

연결 수행 과정은 다음과 같음.

HTTP 클라이언트는 HTTP의 기본 포트 번호 80을 통해 www.example.com 서버로 TCP 연결을 시도.
HTTP 클라이언트는 1단계에서 설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지를 보냄. 이 요청 메시지는 /example1/home.index 경로 이름을 포함함.
HTTP 서버는 1단계에서 설정된 연결 소켓을 통해 요청 메시지를 수신 후, 저장 장치로부터 /example1/home.index 객체 추출. HTTP 응답 메시지에 그 객체를 캡슐화한 후 응답 메시지를 소켓을 통해 클라이언트에게 전송.
HTTP 서버는 TCP에게 TCP 연결을 끊으라고 함. (TCP 클라이언트가 응답 메시지를 올바르게 받을 때까지 연결을 끊지 않음)
HTTP 클라이언트가 응답 메시지를 받으면 TCP 연결이 중단됨. 메시지는 캡슐화된 객체가 HTML 파일인 것을 나타내며 클라이언트는 응답 메시지로부터 파일을 추출하고 HTML 파일을 조사하여 10개의 JPEG 객체에 대한 참조를 찾음.
그 이후에 참조되는 각 JPEG 객체에 대해 위의 네 단계를 반복.

위의 연결 수행 과정을 보면 서버가 객체를 보낸 후 각 TCP 연결이 끊어지므로, 비지속 연결을 사용하는 것임.

각 TCP 연결은 하나의 요청 메시지와 응답 메시지만 전송함.

따라서, 이 예시에서는 사용자가 웹 페이지를 요청할 때 11개의 TCP 연결이 생성됨.

클라이언트가 기본 HTML 파일을 요청하고 그 파일이 클라이언트로 수신될 때까지의 시간을 측정해봄.

RTT(Round Trip Time)
- 작은 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는데 걸리는 시간
RTT는 패킷 전파 지연, 중간 라우터와 스위치에서의 패킷 큐잉 지연, 패킷 처리 지연 등을 포함함.

대략 총 응답 시간은 2RTT + HTML 파일을 서버가 전송하는데 걸리는 시간임.

따라서, 비지속 연결 HTTP일 경우 한 객체당 2RTT+@이므로 총 11번의 객체를 전송받는다고 하면 11*(2RTT+@)이므로 22RTT+11*@이다.

지속 연결 HTTP

비지속 연결의 단점
- 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 함.
  - TCP 버퍼가 할당되어야 하고 TCP 변수들이 클라와 서버 양쪽에 유지되어야 하므로, 이는 수많은 다른 클라의 요청을 동시에 서비스하는 웹 서버에게 심각한 부담을 줄 수 있음.
- 앞서 언급한 대로 각 객체는 최소 2RTT를 필요로 함.

지속 연결인 경우 서버는 응답을 보낸 후 TCP 연결을 그대로 유지함.

같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내짐.

특히 전체 웹 페이지를 하나의 지속 TCP 연결을 통해 보내질 수 있으며, 같은 서버에 있는 여러 웹 페이지들을 하나의 지속 TCP 연결을 통해 보낼 수 있음.

이들 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어질 수 있음.(pipelining)

위의 예제로 보면 다음과 같음.: 2RTT 이후 클라는 10개의 JPEG 객체 이미지를 연속으로 요청을 하게 되므로, 시간은 다음과 같음.; 3RTT + (object 개수)*d_trans

인터넷 전자메일

송신자가 메시지 작성을 끝내면 송신자는 메시지를 메일서버로 보내고, 거기서 메시지는 메일 서버의 출력 메시지 큐에 들어감.
수신자가 메일을 읽고 싶을 때, 수신자는 자신의 메일 서버에 있는 메일박스에서 메시지를 가져옴.

SMTP

SMTP(Simple Message Transfer Protocol)는 인터넷 전자메일을 위한 주요 애플리케이션 계층 프로토콜.

SMTP는 메일을 송신자의 메일 서버로부터 수신자의 메일 서버로 전송하는데 TCP 신뢰적인 데이터 전송 서비스를 이용.

SMTP는 송신자 메일 서버에서 수행하는 클라이언트와 수신자 메일 서버에서 수행되는 서버를 갖고 있으며, SMTP의 클라이언트와 서버 모두가 모든 메일 서버에서 수행됨.

단점은 모든 메일 메시지의 몸체는 단순한 7비트 ASCII이어야 한다는 것.

이러한 점은 1980년대 초까지에는 나름대로 의미가 있었지만, 오늘날의 멀티미디어 시대에는 많은 제한을 주는 부분임.

따라서 SMTP로 멀티미디어 데이터를 보내기 전, ASCII로 변환 후 전송 한 다음에 ASCII를 다시 원래 메시지로 변환해야 함.

HTTP와 SMTP를 비교해보면 두 프로토콜 모두 한 호스트에서 다른 호스트로 파일을 전송하는데 이용됨.

HTTP는 웹 서버로부터 웹 사용자 에이전트로 파일을 전송.
SMTP는 한 메일 서버로부터 다른 메일 서버로 파일을 전송.

파일을 전송할 때, 지속 HTTP와 SMTP 모두 지속 연결을 사용함.

중요한 차이점은 다음과 같음.

HTTP는 원칙적으로 pull 프로토콜로, 누군가 서버에 정보를 올리고 사용자가 편의에 의해서 서버로부터 정보를 가져오기 위해 HTTP를 사용하는 반면 SMTP는 push 프로토콜임.
- pull protocol은 TCP 연결을 파일을 수신할 컴퓨터가 먼저 초기화함.
- push protocol은 TCP 연결을 파일을 보내는 컴퓨터에서 먼저 초기화함.
SMTP는 7bit ASCII이어야 하지만 HTTP는 제한이 없음.
텍스트와 이미지로 구성된 문서를 다루는 방법이 다름.
- HTTP는 자신의 HTTP 응답 메시지에 각 객체를 캡슐화하지만, 인터넷 메일은 모든 메시지의 객체를 한 메시지로 만듦.

메일 메시지 포맷

헤더 라인과 메시지 몸체는 CRLF로 구분.

모든 헤더는 From: 헤더 라인과 To: 헤더라인을 반드시 가져야 함.

또한 Subject: 헤더와 다른 옵션 헤더 라인을 가질 수도 있음.

메일 접속 프로토콜

메일을 전송할 땐, SMTP를 이용하지만 자신의 메일 서버에 도착한 메시지를 로컬 PC 사용자가 어떻게 확인하는가?

SMTP는 push 프로토콜이므로 SMTP를 통해서는 불가능함.

따라서 pull 프로토콜을 이용해야 하는데, 이 문제는 특별한 메일 액세스 프로토콜을 통해 해결 가능함.: 특별한 프로토콜에는 IMAP, POP3, HTTP 등이 있음.

POP3(Post Office Protocol - Version 3)

POP3는 사용자 에이전트가 메일 서버의 포트 110번으로 TCP 연결을 열 때 시작함.

TCP 연결이 설정되면 3단계 과정으로 진행함.: 인증 -> 트랜잭션 -> 갱신

인증
- 사용자 에이전트는 메일을 다운로드하는 사용자 인증을 위해 사용자 이름과 비밀번호를 보냄.
- user <이름> pass <비밀번호>로 인증을 함.

트랜잭션
- 사용자 에이전트는 메시지를 가져오고, 삭제를 위해 메시지에 표시하거나 그 삭제 표시를 지울 수도 있고 메일 통계를 얻을 수도 있음.

갱신
- 클라이언트가 POP3 세션을 끝내는 quit 명령이 내려진 후에 일어나는데, 이때 메일 서버는 삭제 표시된 메시지를 삭제함.

POP3 트랜잭션에서, 사용자 에이전트는 명령을 내리고 서버는 각 명령에 대해 응답함.: 잘 처리하면 서버는 +OK, 실패시 -ERR

또한 사용자 에이전트는 다운로드 후 삭제 혹은 다운로드 후 유지 처럼 설정 가능함.

다운로드 후 삭제 모드
- 서버로부터 메시지를 가져오고 삭제함.
- 문제점은 수신자가 이동성을 가질 경우, 다른 PC에서 메일을 다시 읽고 싶어도 이미 다른 PC에서 확인을 했으므로, 서버에서 삭제되어서 읽을 수가 없음.

다운로드 후 유지 모드
- 메일을 읽어도 서버에서 삭제되지 않음.

~~POP3 서버는 사용자 에이전트와 메일 서버 사이의 POP3 세션 시간 동안 여러 상태 정보를 유지함.~~: 특히 어느 메시지가 삭제되었는지 유지함.; 그러나 세션 기간 동안의 상태 정보를 전달하지는 않음.

IMAP(Internet Mail Access Protocol)

POP3를 이용하여 사용자가 로컬 PC로 메시지를 다운로드하면, 폴더를 생성하고 폴더에 메세지를 이동시키거나 메시지를 검색하거나 등을 할 수 있음.

그러나 이 방법은 어떤 컴퓨터에서도 접속할 수 있는 원격 서버에 폴더 계층구조를 유지해 주기를 원하는 이동 사용자에게는, POP3는 그 기능을 제공할 수 없음.

이 문제점을 해결하기 위해 개발된 것이 IMAP임.

IMAP 서버는 폴더에 각각의 메시지를 연결함.
메시지가 서버에 도착하면 수신자의 INBOX 폴더와 연결됨.
IMAP 프로토콜은 사용자가 폴더를 생성하고 하나의 폴더에서 다른 폴더로 메시지를 옮기는 명령 제공
IMAP 서버는 POP3 서버와 달리 IMAP 세션을 통해 사용자 상태 정보를 유지
- ex) 폴더의 이름과 어떤 메시지가 어떤 폴더와 연결되어 있는가
IMAP은 사용자 에이전트가 메시지의 구성요소를 얻을 수 있게 허용하는 명령을 갖음.
- 즉, 헤더만 얻는다거나 멀티파트 MIME 메시지의 일부만 얻는 등을 가능케 함.
- 이 특성은 사용자 에이전트와 메일 서버 사이에 낮은 대역폭으로 연결될 때 유용함.
포트 번호는 143번을 사용.

웹 기반 전자메일

사용자 에이전트는 HTTP를 통해 메일 서버에 있는 원격 메일박스와 통신.
송신자와 수신자 모두 메시지를 송신, 수신 시 HTTP를 이용.
- 즉, 수신자가 자기 메일박스에 있는 메시지를 보고자 할 때, POP3나 IMAP이 아닌 HTTP를 이용해서 확인함.
그러나 메일 서버는 여전히 SMTP를 이용하여 메시지를 다른 메일 서버로 전달하거나 다른 메일 서버로부터 수신함.

DNS - 인터넷의 디렉터리 서비스

DNS가 제공하는 서비스

DNS는

DNS 서버들의 계층구조로 구현된 분산 데이터베이스
호스트가 분산 데이터베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜임.

DNS는 호스트 네임을 IP 주소로 변환하기 위해 주로 이용함.

사용자의 호스트가 HTTP 요청 메시지를 요청한 URL의 웹 서버로 보낼 수 있게 하기 위해 사용자 호스트는 요청한 URL의 IP 주소를 얻어야만 함.

이는 아래와 같은 순서로 수행됨.

같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트 측을 수행.
브라우저는 URL로부터 호스트 네임 www.requesturl.com를 추출하고 그 호스트 네임을 DNS 애플리케이션 클라이언트 측(사용자)에 넘김.
DNS 클라이언트는 DNS 서버로 호스트 네임을 포함하는 질의를 보냄.
DNS 클라이언트는 결국 호스트 네임에 대한 IP 주소를 가진 응답을 받게 됨.
브라우저가 DNS로부터 IP 주소를 받으면, 브라우저는 그 IP 주소와 그 주소의 80포트에 위치하는 HTTP 서버 프로세스로 TCP 연결 초기화.

DNS는 호스트 네임을 IP 주소로 변환하는 것 외에 다른 서비스도 제공함.

host aliasing
- 복잡한 호스트 네임을 가진 호스트는 하나 이상의 별명을 가질 수 있음.
- DNS는 별칭 호스트 네임에 대한 정식 호스트 네임(canonical hostname)을 얻기 위해 이용될 수 있음.

mail server aliasing
- DNS는 호스트의 IP 주소뿐만 아니라 정식 호스트 네임을 얻기 위해 메일 애플리케이션에 의해 수행됨.
- MX 레코드는 기업의 메일 서버와 웹 서버가 같은 호스트 네임(별칭)을 갖는 것을 허용함.

load distribution
- DNS는 중복 웹 서버 같은 여러 중복서버 사이에 부하를 분산하기 위해서도 사용되고 있음.
- cnn.com 같은 인기 사이트는 여러 서버에 중복되어 있어서, 각 서버가 다른 host에서 수행되고 다른 IP 주소를 갖음.
- 중복 웹서버의 경우, 여러 IP 주소가 하나의 정식 호스트 네임과 연관되어 있음.
- DNS 데이터베이스는 이 IP 주소 집합을 갖고 있음.
  - 따라서 DNS 클라이언트가 질의하면 서버는 이 집합을 가지고 응답함.
  - 그러나 각 응답에서의 주소는 순환식으로 보냄.

DNS 동작 원리 개요

사용자의 호스트에서 실행되는 어떤 애플리케이션의 DNS측의 클라이언트 호출 및 질의.
- 모든 DNS 질의와 응답 메시지는 포트 53의 UDP 데이터그램으로 보내짐.
수 msec에서 수 sec 지연 후에, 사용자 호스트의 DNS는 응답 메시지를 받고 호출한 애플리케이션으로 전달함.

분산 계층 데이터베이스

root DNS 서버
최상위 레벨 도메인 네임(TLD, top-level domain) DNS 서버
책임(authoritative) DNS 서버

어떤 DNS 클라이언트가 호스트 네임 www.amazon.com의 IP 주소를 결정하기 원한다고 가정하면, 먼저 이 클라이언트는 root DNS 서버 중 하나에 접속함.
루트 서버는 최상위 레벨 도메인 com을 갖는 TLD 서버 IP 주소를 보냄.
그 다음 클라이언트는 이 TLD 서버 중 하나에 접속하고, 서버는 도메인 amazon.com을 가진 책임 서버의 IP 주소를 보냄.
클라이언트는 amazon.com의 책임 서버 중에서 하나로 접속.

인터넷에는 400개 이상의 루트 DNS 서버가 있으며 대부분 북미에 위치.

TLD 서버는 com, org, net, edu 같은 상위 레벨 도메인과 kr, uk, fr 같은 모든 국가의 상위 레벨 도메인에 대한 TLD 서버가 있음.

TLD 서버들은 책임 DNS 서버들에 대한 IP 주소들을 제공함.

DNS의 다른 중요한 형태는 로컬 DNS 서버임.

로컬 DNS 서버는 계층 구조에 엄격하게 속하지는 않지만, DNS 구조의 중심에 있음.
ISP는 로컬 DNS 서버를 갖으며 호스트가 ISP에 연결될 때, 그 ISP는 로컬 DNS 서버로부터 IP 주소를 호스트에게 제공.
호스트가 질의를 보내면, 이 질의는 먼저 프록시로 동작하는 로컬 DNS 서버에게 전달되고, 그 로컬 DNS 서버는 이 질의를 DNS 서버 계층으로 전달함.

위의 그림에서 하나의 호스트 네임을 얻기 위해서 총 8번의 DNS 메시지가 보내졌음.

또한 위의 그림에서는 TLD 서버가 Authoritative 서버를 안다고 가정을 하였지만 일반적으론 TLD 서버는 호스트 네임에 대한 책임 DNS를 아는 중간 DNS 서버만 알고 있음.

따라서 사실상 총 10번의 DNS 쿼리가 보내지게 됨.

위의 그림은 재귀적 질의(recursive query)와 반복적 질의(iterative query)를 사용함.

위의 그림에서 호스트가 로컬 DNS 서버로 보내는 질의는 자신을 대신하여 필요한 매핑을 얻도록 로컬 DNS에게 요구하므로 재귀적 질의임. 그 외의 다른 질의는 반복적 질의임.

이론상, DNS 질의는 반복적이고 재귀적일 수 있음.

recursive query를 계속 처리하는 서버를 recursive DNS server라 하는데, 위의 예에서 로컬 DNS 서버가 recursive DNS server가 됨.

DNS 캐싱

DNS 캐싱은 DNS의 지연 성능 향상과 네트워크의 DNS 메시지 수를 줄일 수 있는 방법임.

질의 사슬에서 DNS 서버가 DNS 응답을 받았을 때, 이를 로컬 메모리에 저장 가능함.: 단, TTL로 시간이 지나면 없어짐. (보통 2일); 추가로 만약 host name이 변경이 되었더라도 TTL이 만료되기 전까지는 모를 수 있음.

예를 들어, 한 NYU의 호스트 A가 cnn.com에 대한 질의를 하면, NYU의 로컬 DNS 서버에서 이를 저장해두면, 그 뒤에 다른 NYU의 호스트 B가 cnn.com에 대한 질의를 할 때, 다른 DNS에 질의하지 않고 바로 응답해줄 수 있음.

또한 로컬 DNS 서버는 TLD 서버의 IP 주소를 저장할 수 있어서 로컬 DNS 서버가 루트 DNS 서버를 우회할 수 있음.

DNS 레코드와 메시지

DNS 서버들은 호스트 네임을 IP 주소로 매핑하기 위한 자원 레코드 (resource record, RR) 를 저장함.

각 DNS는 하나 이상의 RR를 가진 메시지로 응답함.

RR는 (Name, Value, Type, TTL)의 필드를 포함하는 4개의 tuple로 되어 있음.: TTL은 RR의 생존 기간이며 Name과 Value의 의미는 Type에 따름.

아래 예에선 TTL 필드는 무시함.

Type=A 이면

Name = Host name
Value = Host Name IP Address
Type A Record는 표준 호스트 네임의 IP 주소 매핑을 제공함.
ex) (relay1.bar.foo.com, 145.37.93.126, A)

Type=NS 이면

Name = Domain (ex : foo.com)
Value = 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는 책임 DNS 서버의 호스트 네임
ex) (foo.com, dns.foo.com, NS)

Type=CNAME 이면

Name = Alias host name
Value = 별칭 호스트 네임 Name에 대한 정식 호스트 네임
Type=CNAME은 질의 호스트에게 호스트 네임에 대한 정식 이름을 제공함.
ex) (foo.com, relay1.bar.foo.com, CNAME)

Type=MX 이면

Name = Alias host name
Value = 별칭 호스트 네임 Name을 갖는 메일 서버의 정식 이름
ex) (foo.com, mail.bar.foo.com, MX)
MX 레코드는 메일 서버의 호스트 네임이 간단한 별칭을 갖는 것을 허용.
- 어떤 회사는 한 메일 서버와 다른 서버들이 같은 별칭을 가질 수 있음.

메일 서버의 정식 이름을 얻기 위해서 DNS 클라이언트는 MX 레코드 에 대한 질의를 함.
다른 서버의 정식 이름을 얻기 위해서 DNS 클라이언트는 CNAME 레코드 에 대한 질의를 함.

DNS 메시지

DNS 메시지 유형은 질의, 응답 두 가지뿐임.

요청과 응답 메시지 모두 아래 사진과 같은 포맷을 가지고 있음.

12바이트는 헤더 영역으로 여러 필드를 갖고 있음.
- 식별자 (Identification)
  - 질의를 식별하는 16비트 숫자, 질의에 대한 응답 메시지에 복사되어, 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별함.
- 플래그 (Flags)
  - 플래그 필드에는 여러 개의 플래그가 있음.
  - 1비트의 질의/응답 플래그는 메시지가 질의(0)인지 응답(1)인지 구별함.
  - 1비트의 책임 플래그는 DNS 서버가 질의 이름에 대해 책임 서버일 때 응답 메시지에 설정됨.
  - 1비트의 재귀 요구 플래그는 DNS 서버가 레코드를 갖지 않을 때 재귀적 질의를 수행하기를 클라가 원할 때 설정됨.
  - 1비트의 재귀-가능 필드는 DNS 서버가 재귀 질의를 지원하면 응답에 설정됨.
- 4개의 개수 필드는 헤더 다음에 오는 데이터 평면의 네 가지 타입의 발생 횟수를 나타냄.

질문 영역은 현재 질의에 대한 정보를 포함함.
- 이 영역은 질의되는 이름을 포함하는 이름 필드와, 이름에 대해 문의되는 질문 타입을 나타내는 타입 필드 (A, NS, CNAME, MX)를 포함함.

DNS 서버로부터의 응답에서, 답변 영역은 원래 질의된 이름에 대한 자원 레코드를 포함함.
- 응답으로 여러 개의 RR을 보낼 수 있음. 왜냐하면 호스트 네임은 여러 개의 IP주소를 가질 수 있기 때문.

책임 영역은 다른 책임 서버의 레코드를 포함함.

추가 영역은 다른 도움이 되는 레코드를 포함함.
- 예를 들어, MX질의에 대한 응답에서 응답 필드는 전자메일 서버의 정식 호스트 네임을 제공하는 RR을 가지고 있음. 추가 영역은 메일 서버의 정식 호스트 네임에 대한 IP 주소를 제공하는 Type A 레코드를 포함함.

P2P 파일 분배

P2P 구조는 항상 켜져 있는 기반구조 서버에 최소한으로 의존함.
대신 간헐적으로 연결되는 호스트 쌍들(피어)이 서로 직접 통신함.

P2P 구조의 확장성

클라이언트-서버 구조와 P2P구조의 차이점은 분배시간(distribute time)임.: 분배 시간이란 모든 N개의 피어들이 파일의 복사본을 얻는 데 걸리는 시간임.

클라이언트-서버 구조는 분배시간이 선형적으로 증가를 하게 됨.

CDN(콘텐츠 분배 네트워크, Contents Distribution Network)

자세한건 akamai.com/kr/ko/cdn/what-is-a-cdn.jsp

CDN은 다수의 지점에 분산된 서버들을 운영하며, 여러 형태의 웹 콘텐츠 데이터 복사본을 캐싱한 분산 서버들을 운영하여 사용자가 최선의 서비스를 이용할 수 있게 함.