2.3 인터넷 전자메일

• 전자 메일은 비동기적인 통신 매체
• 메일은 분배가 쉽고, 빠르고, 저렴하다.
  • 현대의 전자메일: 첨부된 메시지, 하이퍼링크, HTML 포맷 텍스트, 내장된 사진 등 많은 강력한 특성 지님.
• 사용자 에이전트, 메일서버, SMTP
• (예) 송신자 앨리스가 수신자 밥에게 전자메일을 보내는 상황
  • 앨리스가 메시지 작성을 끝내면, 사용자 에이전트는 메시지를 메일 서버로 보냄.
  • 메시지는 메일 서버의 출력 메시지 큐에 들어감.
  • 밥이 메시지를 읽고 싶을 때 그의 사용자 에이전트는 메일 서버에 있는 메일박스에서 메시지를 가져온다.
  • 밥의 메일박스는 그에게 온 메시지를 유지하고 관리함.
  • 밥이 메시지를 보려면? ⇒ 메일 서버는 사용자 계정과 비밀번호를 이용해 밥을 인증함.
    • 앨리스의 메일 서버는 밥의 메일 서버 고장에도 대처해야 함.
  • 앨리스 서버가 메일을 밥의 서버로 전달할 수 없다면, 앨리스 서버는 그 메시지를 메시지 큐에 보관하고 나중에 그 메시지를 전달하기 위해 다시 시도함. (재시도는 30분마다)
  • 만약 성공하지 못한다면? ⇒ 서버는 그 메시지를 제거하고 송신자에게 전자메일로 통보함
• 사용자 에이전트: 사용자가 메시지를 읽고, 응답하고, 저장하고, 구성하게 해준다.
  • 마이크로소프트 아웃룩, 웹 기반 지메일, 스마트폰용 지메일 앱 등
• 메일 서버: 전자메일 인프라스트럭처의 중심
  • 각 수신자는 메일 서버 안에 메일 박스를 갖고 있다.
• 일반 메시지: 송신자의 사용자 에이전트에서 전달이 시작되고, 송신자의 메일 서버를 거친 후에 수신자의 메일 서버로 전달됨. 거기서 수신자의 메일박스에 저장됨.
• SMTP: 인터넷 전자메일을 위한 주요 애플리케이션 계층 프로토콜
  • 메일을 송신자의 메일 서버로부터 수신자의 메일 서버로 전송하는 데 TCP의 신뢰적인 데이터 전송 서비스를 이용한다.
  • 송신자 메일 서버에서 수행하는 클라이언트와 수신자 메일 서버에서 수행되는 서버를 갖고 있음.
  • SMTP의 클라이언트와 서버 모두가 모든 메일 서버에서 수행됨.
    • 메일 서버가 상대 메일 서버로 메일을 보낼 때는 SMTP의 클라이언트로 동작하는 반면, 메일 서버가 메일 서버로부터 메일을 받을 때는 SMTP 서버로 동작함.

2.3.1. SMTP

• 송신자의 메일 서버로부터 수신자의 메일 서버로 메시지를 전송함.
• HTTP보다 훨씬 오래되었음.
• 여러가지 장점이 있지만, 낡은 특성을 가진 오래된 기술
  • ex) 모든 메일 메시지의 몸체는 단순한 7비트 ASCII여야 한다는 단점. ⇒ 전송용량이 제한되고 커다란 첨부파일이나 커다란 이미지, 오디오 혹은 비디오 파일을 보내지 않았던 예전에는 의미가 있었음. 그러나 오늘날의 멀티미디어 시대에서는 문제를 일으킴.
  • SMTP를 통해 이진 멀티미디어 데이터를 보내기 전에 ASCII로 변환할 필요가 생김. 그리고 SMTP 전송 후에는 ASCII를 다시 원래 메시지로 변환해야만 함.
  • HTTP는 전송 전에 멀티미디어 데이터를 ASCII로 변환하는 것을 요구하지 않는다!
• 밥과 앨리스의 시나리오
  • 메일을 보낼 때 두 메일 서버가 먼 거리에 떨어져 있더라도 중간 메일 서버를 사용하지 않음.
  • 밥의 메일 서버가 죽어있다면, 앨리스의 메일 서버에 남아 새로운 시도를 위해 기다린다.
• SMTP가 메시지를 송신 메일 서버에서 수신 메일 서버로 어떻게 전송하는가?
  • 마주본 사람의 상호작용에 이용되는 프로토콜과 유사
  • 첫째, 클라이언트 SMTP는 서버 SMTP의 25번 포트로 TCP 연결을 설정.
    • 서버가 죽어있다면? ⇒ 나중에 다시 시도.
    • 연결이 설정되면? ⇒ 서버와 클라이언트는 애플리케이션 계층 핸드셰이킹을 수행함.
    • 핸드 셰이킹 과정 동안에 SMTP 클라이언트는 송신자의 전자메일 주소와 수신자의 전자메일 주소를 제공함.
  • 둘째, 클라이언트는 메시지를 보냄.
    • SMTP는 서버에 오류 없이 메시지를 전달하기 위해 TCP의 신뢰적인 데이터 전송 서비스에 의존함.
    • 서버에 보낼 다른 메시지가 있으면, 클라이언트는 이 과정을 같은 TCP 연결상에서 반복함. 그렇지않으면 TCP에게 연결을 닫을 것을 명령함.
• (예제)
  • 메일 서버 crepes.fr로부터 메일 서버 hamburger.edu에게 메시지를 보냄.
  • 클라이언트는 하나의 점으로 된 라인을 송신하며, 그것은 서버에게 메시지의 끝을 나타냄.
  • 서버는 각 명령에 응답하며, 각 응답에는 응답 코드와 영문 설명이 있음.
• SMTP는 지속 연결을 사용한다는 것을 언급.
• 송신 메일 서버가 같은 수신 메일 서버로 보내는 여러 메시지를 갖고 있다면, 같은 TCP 연결을 통해 모든 메시지를 전달할 수 있음.
  • 모든 메시지를 전송한 후에 QUIT를 보낸다!

2.3.2. 메일 메시지 포맷

• 전자메일을 보낼 때도 주변 정보가 포함된 헤더가 메시지 몸체 앞에 오게 됨.
• 주변 정보는 RFC 5322에 정의되어 있음!
• 헤더 라인과 메시지 몸체는 빈 줄(CRLF)로 분리됨.
• RFC 5322는 메일 헤더 라인에 대한 정확한 포맷과 그 의미에 대한 해석을 기술하고 있음.
• 각 헤더라인은 키워드, 콜론, 값의 순서로 구성되고 읽을 수 있는 텍스트를 포함함.
  • 모든 헤더는 From: 헤더 라인과 To: 헤더 라인을 반드시 가져야 함.

2.3.3. 메일 접속 프로토콜

• SMTP가 앨리스의 메일 서버로부터 밥의 메일 서버로 메시지를 전달하고 나면, 메시지는 밥의 메일 박스에 놓이게 됨.
• 밥이 자신의 호스트에서 사용자 에이전트를 수행한다면, 메일 서버도 자신의 로컬 PC에 놓는 것이 자연스러울 것 ⇒ 그러나 해당 방식에는 문제가 있음!
• 메일 서버가 메일 박스를 관리하고 SMTP의 클라이언트와 서버 측 모두를 수행한다는 것을 기억하라
• IF, 밥의 메일 서버가 로컬 호스트에 있다면, 밥의 호스트는 언제든 도착할 수 있는 전자메일을 수신하기 위해 항상 켜져있어야 하고 인터넷에 연결되어야 함. ⇒ 비현실적
• 일반 사용자는 로컬 호스트에서 사용자 에이전트를 수행하고 늘 켜져 있는 공유 메일 서버에 저장된 메일박스에 접근함.
  • 메일 서버는 보통 사용자들과 공유.
• 전자메일 메시지가 앨리스 사용자 에이전트로부터 밥 메일 서버로 전송될 때 전자메일 메시지가 갖는 경로
  • 앨리스 사용자 에이전트는 밥의 메일 서버로 직접 대화하지 않는다.
  • 앨리스 사용자 에이전트는 그녀의 메일 서버로 전자메일 메시지를 SMTP 또는 HTTP를 이용하여 보냄.
  • 앨리스이 메일 서버는 SMTP를 사용하여 밥의 메일 서버로 전자메일을 중계함.
• 왜 두 단계의 경로인가?
  • 앨리스의 메일 서버를 통해 중계하지 않으면 앨리스의 사용자 에이전트는 목적지 메일 서버에 도달할 수 없기 때문.
  • 앨리스는 전자메일을 자신의 메일 서버에 먼저 저장하고 앨리스의 메일 서버는 그 메시지를 밥의 메일 서버로 30분마다 반복해서 보내려 함.
• 그러나 고려되지 않은 한 가지 문제 → 로컬 호스트 PC에서 사용자 에이전트를 수행하는 밥과 같은 수신자는 자신의 ISP 내부의 메일 서버에 있는 자신의 메시지를 어떻게 얻을 수 있는가?
  • 밥의 사용자 에이전트는 메시지를 얻기 위해 SMTP를 사용할 수 없음.
  • SMTP가 푸시 프로토콜인 반면에 메시지를 얻는 것은 풀 동작이기 때문. (서버가 계속 열려있는 것을 막기위함. → gpt 조언)
• 대안: HTTP 사용, 인터넷 메일 접근 프로토콜 사용.

---

2.4. DNS: 인터넷의 디렉터리 서비스

• 식별자 → 사람을 여러 가지 방법으로 식별할 수 있는 것처럼, 인터넷 호스트도 마찬가지!
• 호스트의 식별자 중 하나는 호스트 이름이다.
  • 호스트는 흔히 말하는 IP주소로도 식별됨.

2.4.1. DNS가 제공하는 서비스

• 사람은 좀 더 기억하기 쉬운 호스트 이름 식별자를 좋아하지만, 라우터는 고정 길이의 계층 구조를 가진 IP주소를 좋아함.

• 선호 차이를 절충하기 위해, 호스트 이름을 IP 주소로 변환해주는 디렉터리 서비스가 필요함. ⇒ DNS의 주요 임무

• DNS

  • DNS 서버들의 계층구조로 구현된 분산 데이터베이스
  • 호스트가 분산 데이터베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜
    • DNS 서버는 주로 BIND 소프트웨어를 수행하는 유닉스 컴퓨터에서 동작함.
  • DNS 프로토콜은 UDP 상에서 수행되고 포트 번호 53을 이용함.

• DNS는 다른 애플리케이션 프로토콜들이 HTTP, SMTP, FTP 등 사용자가 제공한 호스트 이름을 IP 주소로 변환하기 위해 주로 사용함.

• (예) 어떤 사용자의 호스트에서 수행되는 브라우저가 URL (www.someschool.edu/index.html) 을 요청할 때 어떤 일이 발생하는가?

  • 사용자의 호스트가 HTTP 요청 메시지를 웹 서버 www.someschool.edu로 보낼 수 있도록 사용자 호스트는 www.someschool.edu의 IP주소를 얻어야만 함.
  • 같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트 측에 수행함.
  • 브라우저는 URL로부터 호스트 이름 www.someschool.edu를 추출하고 그 호스트 이름을 DNS 애플리케이션의 클라이언트 측에 넘김. (로컬 dns 서버)
  • DNS 클라이언트는 DNS 서버로 호스트 이름을 포함하는 질의를 보냄.
  • DNS 클라이언트는 결국 호스트 이름에 대한 IP 주소를 가진 응답을 받게 됨.
  • 브라우저가 DNS로부터 IP 주소를 받으면, 브라우저는 해당 IP 주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화함.
  • DNS는 DNS를 사용하는 인터넷 애플리케이션에 추각 지연을 준다
    • 클라이언트가 사용자(우리)고, dns 계층구조 → 이 두 개를 연결하는 게 로컬 DNS

• IP 주소는 가까운 DNS 서버에 캐싱되어 있어서 평균 DNS 지연뿐만 아니라 DNS 네트워크 트래픽 감소에 도움을 줌.

• DNS는 호스트 이름을 IP 주소로 변환하는 것외에 다양한 중요 서비스를 제공함.

  • 호스트 에일리어싱: 복잡한 호스트 이름을 가진 호스트는 하나 이상의 별명을 가질 수 있음.
    • 정식 호스트 이름, 별칭 호스트 이름
    • DNS는 호스트의 IP 주소뿐만 아니라 제시한 별칭 호스트 이름에 대한 정식 호스트 이름을 얻기 위해 이용될 수 있음.
  • 메일 서버 에일리어싱
  • 부하 분산: DNS는 중복 웹 서버 같은 여러 중복 서버 사이에 부하를 분산하기 위해서도 사용되고 있음.

2.4.2. DNS 동작 원리 개요

• 호스트 이름을 IP 주소로 변환하는 서비스에 초점을 맞춤.
• 사용자의 호스트에서 실행되는 어떤 애플리케이션이 호스트 이름을 IP 주소로 변환하려 한다고 가정.
  • 그 애플리케이션은 변환될 호스트 이름을 명시하여 DNS 측의 클라이언트를 호출할 것이다.
  • 사용자의 호스트의 DNS는 네트워크에 질의 메시지를 보낸다.
    • 모든 DNS 질의와 응답 메시지는 포트 53의 UDP 데이터그램으로 보내짐.
  • 수 밀리초에서 수 초의 지연 후에 사용자 호스트의 DNS는 요청한 매핑에 해당하는 DNS 응답 메시지를 받음.
  • 해당 매핑은 호출한 애플리케이션으로 전달됨.
  • 그러므로 사용자 호스트의 호출한 애플리케이션 관점에서 DNS는 간단하고 직접적인 변환 서비스를 제공하는 블랙박스
• 블랙박스는 분산된 많은 DNS 서버뿐만 아니라 DNS 서버와 질의를 하는 호스트 사이에서 어떻게 통신하는지를 명시하는 애플리케이션 계층 프로토콜로 구성되어 있음.
• DNS의 간단한 설계로 모든 매핑을 포함하는 하나의 인터넷 네임 서버를 생각할 수 있음.
  • 중앙 집중 방식에서 클라이언트는 모든 질의를 단일 네임 서버로 보내고, DNS 서버는 질의 클라이언트에게 직접 응담함. ⇒ 수많은 호스트를 가진 오늘날의 인터넷에는 적합하지 않음.
    • 서버의 고장 : 네임 서버가 고장 나면, 전체 인터넷이 작동하지 않음.
    • 트래픽 양 : 단일 DNS 서버가 모든 DNS 질의를 처리해야 함.
    • 먼 거리의 중앙 집중 데이터베이스 : 단일 DNS 서버가 모든 질의 클라이언트로부터 가까울 수만은 없음. → 매우 심각한 지연을 일으킬 수 있음.
    • 유지관리 : 갱신. 중앙 집중 데이터베이스에 호스트를 등록할 수 있도록 사용자에게 허용하는 것과 관련된 인증 문제가 있음.
• 단일 DNS 서버에 있는 중앙 집중 데이터베이스는 확장성이 전혀 없다. ⇒ 결과적으로 DNS는 분산되도록 설계되었다.

분산 계층 데이터베이스

• 확장성 문제를 다루기 위해 DNS는 많은 서버를 이용하고 이들을 계층 형태로 구성하며 전 세계에 분산시킴.
• 어떠한 단일 DNS 서버도 인터넷에 있는 모든 호스트에 대한 매핑을 갖지 않는 대신에 그것은 DNS 서버 사이에 분산된다.
• 계층으로 구성된 세 유형의 DNS 서버가 있음.
  • 루트 DNS 서버
    • 1000개 이상의 루트 서버의 인스턴스가 전 세계에 흩어져 있음.
    • 루트 서버들은 13개의 다른 루트 서버 복사체이고, 12개의 다른 기관에서 관리되며, 인터넷 할당 번호 관리기관에 의해 조정됨.
    • 루트 네임 서버는 TLD 서버의 IP 주소들을 제공함.
  • 최상위 레벨 도메인 네임 DNS 서버
    • com, org, net, edu, gov 같은 상위 레벨 도메인과 kr, uk, fr, ca, jp 같은 모든 국가의 상위 레벨 도메인에 대한 tld 서버가 있음.
    • TLD 서버는 책임 DNS 서버에 대한 IP 주소를 제공함.
  • 책임 DNS 서버 (중간 DNS 서버 해당될걸?)
    • 인터넷에서 접근하기 쉬운 호스트(웹 서버와 메일 서버)를 가진 모든 기관은 호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 레코드를 제공해야 함. ⇒ 기관의 책임 DNS 서버는 이 DNS 레코드를 갖고 있음!
    • 기관은 이 레코드를 갖도록 자신의 책임 DNS 서버의 구현을 선택할 수 있고, 일부 서비스 제공자의 책임 DNS 서버에 이 레코드를 저장하도록 비용을 지불함.
• 루트, TLD, 책임 DNS 서버들은 모두 DNS 서버들의 계층구조를 갖는다.
• DNS의 또 다른 중요한 형태는 로컬 DNS 서버이다.
  • 이는 서버들의 계층 구조에 엄격하게 속하지는 않지만, DNS 구조의 중심에 있음.
• 대학이나 주거지역 ISP 같은 ISP들은 로컬 DNS 서버를 갖음.
• 호스트가 ISP가 연결될 때, 그 ISP는 로컬 DNS 서버로부터 IP 주소를 호스트에게 제공함.
• 윈도우나 유닉스에서 네트워크 상태 창에 접근하여 로컬 DNS 서버의 IP 주소를 쉽게 결정할 수 있음.
• 호스트의 로컬 DNS 서버는 대체로 호스트 가까이 있음.
• 기관 ISP에서 로컬 DNS 서버는 호스트와 같은 LAN상에 있을 수 있음.
• 주거지역 ISP는 전형적으로 몇 개의 라우터 범위 안에서 호스트로부터 떨어져 있음. 호스트가 DNS 질의를 보내면, 이 질의는 먼저 프록시로 동작하는 로컬 DNS 서버에게 전달되고, 그 로컬 DNS 서버는 이 질의를 DNS 서버 계층으로 전달함.
• (책 참고)

DNS 캐싱

• DNS는 지연 성능 향상과 네트워크의 DNS 메시지 수를 줄이기 위해 캐싱을 사용

2.4.3. DNS 레코드와 메시지

DNS 메시지

• DNS의 유일한 두 가지 메시지 유형 ⇒ DNS 질의와 응답 메시지
• DNS의 메시지 포맷
  • 헤더 영역(6개 필드)
    • 처음 12바이트, 여러 필드를 갖고 있음.
    • 첫 필드는 질의를 식별하는 16비트 숫자. 이 식별자는 질의에 대한 응답 메시지에 복사되어, 클라이언트가 보낸 질의와 수신된 응답 질의 간의 일치를 식별하게 함.
    • 플래그 필드 : ..
  • 질문 영역: 현재의 질의에 대한 정보를 포함
    • 질의되는 이름을 포함하는 이름 필드와, 이름에 대해 문의되는 질문 타입을 나타내는 타입 필드를 포함함.
  • DNS 서버로부터의 응답에서 답변 영역: 원래 질의된 이름에 대한 자원 레코드를 포함함.
    • 각 자원 레코드에 Type, Value, TTL이 있음.
    • 응답으로 여러개의 RR을 보낼 수 있음. → 호스트 이름은 여러 개의 IP 주소를 가질 수 있기 때문.(중복된 웹 서버와 같은 경우)
  • 책임 영역: 다른 책임 서버의 레코드를 포함
  • 추가 영역: 다른 도움이 되는 레코드를 포함하고 있음.
• DNS 질의 메시지가 우리가 작업하는 호스트로부터 DNS 서버로 곧장 보내질 수 있는가? ⇒ nslookup 프로그램
• (예) nslookup을 실행한 후에 DNS 질의를 어떤 DNS 서버로 보낼 수 있음.
• DNS 서버로부터 응답 메시지를 받은 후에 nslookup은 응답에 있는 레코드를 사람이 읽을 수 있는 형태로 보여줌.
  • 우리의 호스트로부터 nslookup을 실행하는 대신 nslookup을 원격에서 실행하게 하는 많은 웹사이트 중 하나를 방문할 수도 있음.

DNS 데이터베이스에 레코드 삽입

• 레코드를 db에 어떻게 넣는가?
• (예시) 네트워크 유토피아라고 하는 새로운 벤처기업을 설립했다고 가정함.
  • 도메인 네임 networkutopia.com을 등록기관에 등록.
    • 등록기관: 도메인 네임의 유일성을 확인하고, 그 도메인 이름을 DNS 데이터베이스에 넣고, 그 서비스에 대한 약간의 요금을 우리로부터 받는 상업기관
  • 도메인 네임을 어떤 등록기관에 등록할 때 등록 기관에 주책임 서버와 부책임 서버의 이름과 IP 주소를 등록기관에 제공해야함.
  • 최근에는 DNS 메시지를 통해 데이터베이스에 데이터를 동적으로 추가 혹은 삭제할 수 있도록 DNS 프로토콜에 UPDATE 선택사양이 추가되었음.
    • RFC 2136, RFC 3007은 DNS 동적 갱신을 기술하고 있음.
  • 모든 단계가 끝나고 나면, 사람들은 우리의 웹사이트를 방문할 수 있고 우리 회사의 직원들에게 전자메일을 보낼 수도 있음.