네트워크 [Network] | MailBox, Message Queue, SMTP, POP3, DNS, TLD

사용자 에이전트, 메일 서버, SMTP 라는 3개의 주요 요소로 이루어져있다. 사용자 에이전트는 사용자가 메시지를 읽고 응답하고 전달하고 저장하고 구성하게 해준다.

 

 

각 수신자는 메일 서버 안에 메일 박스 (Mailbox)를 갖고 있다. 수신자의 메일 박스는 그에게 온 메시지를 유지하고 관리한다. 일반 메시지는 송신자의 User agent 에서 전달이 시작되고, 송신자의 메일 서버를 거친 후에 수신자의 메일 서버로 전달된다. 그 이후 수신자의 메일 박스에 저장된다. 또한 수신자가 전자메일 박슷에 있는 메시지를 보려면 메일 서버는 사용자 계정과 비밀번호를 이용하여 수신자를 인증한다. 만일 송신자가 수신자의 서버로 메일을 전달할 수 없다면 송신자 서버는 그 메시지를 Message Queue에 보관하고 나중에 다시 시도한다.

 

SMTP는 인터넷  전자메일을 위한 주요 애플리케이션  계층 프로토콜이다. SMTP는 메일을 TCP의 신뢰적인 데이터 전송 서비스를 이용한다. 대부분의 애플리케이션 계층 프로토콜처럼 SMTP는 송신자 메일 서버에서 수행하는 클라이언트와 수신자 메일 서버에서 수행되는 서버를 갖고 있다.

 

 

앞서 언급한 대로, SMTP는 송신자의 메일 서버로부터 수신자의 메일 서버로 메시지를 전송한다. SMTP는 HTTP보다 훨씬 오래된 기술이기에 낡은 특성을 가지고 있다. 그 예로 모든 메일 메시지의 몸체는 단순한 7비트 ASCII 여야 한다는 점이다. 그래서 오늘날 SMTP를 사용하기 위해서 데이터를 보내기 전에 ASCII로 변환할 필요가 생겼다. 그리고 SMTP 전송 후에는 ASCII 를 다시 원래 메시지로 변환해야만 한다.

 

 

 

1. 앨리스는  전자메일 사용자 에이전트를 수행하고 바의 전자메일 주소를 제공하며, 메시지를 작성하고 사용자  에이전트에게 메시지를 보내라고 명령한다.

2. 앨리스의 사용자 에이전트는 메시지를 그녀의 메일 서버로 보내고 그곳에서 메시지는 Message Queue에 놓는다.

3. 앨리스의 메일 서버에서 동작하는 SMTP의 클라이언트 측은 메시지 큐에 있는 메시지를 본다. 밥의 멜 서버에서 수행되고 있는 SMTP 서버에게 TCP 연결을 설정한다.

4. 초기 SMTP 핸드셰이킹 이후 SMTP 클라이언트는 앨리스의 메시지를 TCP 연결로 보낸다.

5. 밥의 메일 서버 호스트에서 SMTP의 서버 측은 메시지를 수신한다.

6. 밥은 편한 시간에 그 메시지를 읽기 위해 사용자 에이전트를 시동한다.

 

SMTP 클라이언트는 송신자의 전자메일 주소와 수신자의 전자 메일 주소를 제공한다. SMTP는 서버에 오류 없이 메시지를 전달하기 위해 TCP의 신뢰적인 데[이터 전송 서비스에 의존한다. 그리고 서버에 보낼 다른 메시지가 있으면 클라이언트는 같은 TCP 연결상에서 반복한다. 그렇지 않으면 TCP에게 연결을 닫을 것을 명령한다.

 

 

 

클라이언트와 서버 사이의 메시지 전달 과정의 예를 살펴보자. 클라이언트의 호스트 네임은 crespes.fr이고 서버의 호스트 네임은 hamburger.edu이다. C: 다음에 나오는 ASCII 텍스트 라인은 클라이언트가 TCP 소켓으로 보내는 라인이다. S: 다음에 나오는 ASCII 텍스트 라인은 서버가 TCP 소켓으로 보내는 라인이다.

 

클라이언트는 메일 서버  crepes.fr로부터 메일 서버 hamburger.edu로 Do you like ketchup? How about pickles? 라는 데이터를 전송한다. 또한 QUIT 명령을 내리게 되며 TCP 연결을 종료하게 된다. SMTP는 지속 연결을 사용한다는 것도 언급하고자 한다. 송신 메일 서버가 같은 수신 메일 서버로 보내는 여러 메시지를 갖고 있다면, 같은 TCP 연결을 통해서 모든 메시지를 전달할 수 있다.

 

 

HTTP는 웹 서버로부터 웹 사용자 에이전트(브라우저)로 파일을 전송한다. SMTP는 한 메일 서버로부터 다른 메일 서버로 파일을 전송한다. 파일을 전송할 때 HTTP와 SMTP 모두 지속 연결을 사용한다. (공통점) 하지만 중요한 차이점이 존재한다. HTTP는 원칙적으로 PULL 프로토콜이다. 누군가가 서버에 정보를 올리고 사용자가 편의에 의해서 서버로부터 정보를 가져오기 위해 HTTP를 사용한다. 특히 TCP 연결은 파일을 수신할 컴퓨터가 먼저 초기화한다. 반면 SMTP는 원칙적으로 PUSH 프로토콜이다. 송신 메일 서버가 파일을 수신 서버로 보낸다. 특히 TCP 연결은 파일을 보내는 컴퓨터에서 먼저 초기화한다.

 둘째, SMTP는 각 메시지의 몸체를 포함하여 각 메시지가 7비트 ASCII 포맷일 것을 요구한다. 즉 메시지가 7비트 ASCII가 아닌 문자를 포함하거나 이진 데이터를 포함한다면 그 메시지를 7비트로 인코딩해야 한다. 반면 HTTP는 이러한 제한이 없다.

 셋째, 텍스트와 이미지로 구성된 문서를 다루는 방법이다. HTTP는 자신의 HTTP 응답 메시지에 각 객체를 캡슐화한다. 인터넷 메일은 모든 메시지의 객체를 한 메시지로 만든다.

 

 

일반 우편을 보낼 때 편지를 우편 봉투에 넣는데, 우편 봉투에는 받는 사람의 주소, 앨리스의 반송 주소, 날짜 등 여러가지 주변 정보가 적힌다. 마찬가지로, 전제메일을 보낼 때도 주변 정보가 포함된 헤더가 메시지 몸체 앞에 오게 된다. 이는 일련의 헤더 라인에 포함되는데 RFC 5322에 정의되어 있다. 헤더 랑린과 메시지 몸체는 빈줄 (Blank line)로 분리되어 있다. 모든 헤더는 From: 헤더 라인과 To: 헤더 라인을 반드시 가져야 한다. 헤더는 Subject: 헤더와 다른 옵션 헤더 라인을 가질 수도 있다.

ex)

From: alice@crepes.fr

To : bob@hamburger.edu

Subject: Searching for the meaning of life.

 

메시지 헤더 다음에 빈 줄이 이어지고, 그 다음에 메시지 몸체가 나온다.

 

 

전자메일 메시지가 앨리스 사용자 에이전트로부터 밥 메일 서버로 전송될 때 전자메일 메시지가 갖는 경로를 생각해 보자. 앨리스의 사용자 에이전트는 밥의 메일 서버로 직접 대화하지 않는다. 대신에 그림처럼 앨리스의 사용자 에이전트는 그녀의 메일 서버로 전자메일 메시지를 SMTP를 이용하여 보낸다. 그리고 앨리스의 메일 서버는 SMTP를 이용하여 밥의 메일 서버로 전자메일 메시지를 중계한다. 왜 두 단계의 절차인가? 주요 이유는 앨리스의 메일 서버를 통해 중계하지 ㅇ낳으면 앨리스의 상요자 에이전트는 목적지 메일 서버에 도달할 수 없기 때문이다. 앨리스는 전자메일을 자신의 메일 서버에 먼저 저장하고 앨리스의 메일 서버는 그 메시지를 밥의 메일 서버로 30분마다 반복해서 보내려고 한다.

 

로컬 PC에서 사용자 에이전트를 수행하는 밥과 같은 수신자는 자신의 ISP 내부의 메일 서버에 있는 자신의 메시지를 어떻게 얻을 수 있는가? 밥의 사용자 에이전트는 메시지를 얻기 위해 SMTP를 사용할 수 없다는 것에 주목해야 한다. SMTP가 PUSH 프로토콜인 반면 메시지를 얻는 것은 PULL 프로토콜이기 때문이다. 이 문제는 밥의 메일 서버에서 자신의 로컬 PC로 메시지를 전송하는 특별한 메일 액세스 프로토콜을 통해서 해결할 수 있다. POP3 IMAP HTTP와 같은 유명한 메일 접속 프로토콜이 존재한다.

 

 

호스트에 대한 하나의 식별자는 호스트 네임이다. 사람은 좀 더 기억하기 쉬운 호스트 네임 식별자를 좋아하지만 라우터는 고정 길이의 계층 구조를 가진 IP 주소를 좋아한다.  이러한 선호 차이를 절충하기 위해, 호스트 네임을 IP 주소로 변환해 주는 디렉터리 서비스가 필요하다. 이것이 DNS의 주요 임무이다. DNS는 DNS 서버들의 계층 구조로 구현된 분산 데이터베이스고 호스트가 분산 데이터베이서로 절의하도록 허락하는 애플리케이션 계층 프로토콜이다. DNS 프로토콜은 UDP 상에서 수행되고 포트 번호 53을 이용한다.

 

 

1. 같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트 측을 수행한다.

2. 블라우저는 URL로부터 호스트 네임 www.handong.edu를  를 추출하고 그 호스트 네임을 DNS 애플리케이션의 클라이언트 측에 넘긴다.

3. DNS 클라이언트는 DNS 서버로 호스트 네임을 포함하는 질의를 보낸다.

4. DNS 클라이언트는 궁극적으로 호스트 네임에 대한 IP 주소를 가진 응답을 받는다.

5. 브라우저가 DNS로부터 IP 주소를 받으려면 브라우저는 그 IP 주소의 80 번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화한다.

 

 

 

확장성 문제를 다루기 위해 DNS는 많은 서버를 이용하고 이들은 계층 형태로 구성하며 전 세계에 분산시킨다. 루트 DNS 서버, 최상위 레벨 도메인 네임 DNS 서버, 책임 DNS 서버이다. www.amazon.com의  의 IP 주소를 결정하기 원한다고 가정해보자. 먼저 이 클라이언트는 루트 서버 중 하나에 접속한다. 루트 서버는 최상위 레벨 도메인 com 을 갖는 TLD 서버 IP 주소를 보낸다. 그 다음 클라이언트는 이 TLD 서버 중 하나에 접속하고 서버는 도메인 amazon.com의 책임 서버 중에서 하나로 접속한다.

 

 

 

인터넷에는 13개의 루트 DNS 서버가 있는데, 대부분 북미 지역에 위치한다. 비록 13개 루트 DNS 서버 각각을 마치 하나의 단일 서버인 것처럼 인용했지만, 사실 각 서버는 보안과 신뢰를 목적으로 복사된 서버들의 클러스터이다. 

 

 

com, org, net, edu 같은 상위 레벨 도메인과 kr, uk, fr 같은 모든 국가의 상위 레벨 도메인에 대한 책임이 있다. 인터넷에 접근하기 쉬운 호스트를 가진 모든 기관은 호스트 네임을 IP 주소로 매핑하도록 한다. 이를 위해 접근이 쉬운 DNS 레코드를 제공해야 하며 기관의 책임 DNS 서버는 이 DNS 레코드를 갖는다. 또한 기관은 이 레코드를 갖도록 자신의 책임 DNS 서버의 구현을 선택할 수 있고, 일부 서비스 제공자의 책임 DNS 서버에 이 레코드를 저장하도록 비용을 지불한다.

 

 

 

DNS의 다른 중요한 형태는 로컬 DNS 서버다. 로컬 네임 서버는 엄격한 계층 서버를 소유하지 않지만, DNS 구조의 중심에 있다.