[컴퓨터 네트워크] 2-2 Application Layer

윤민우·2023년 3월 30일

CS 전공 공부 컴퓨터 네트워크

컴퓨터 네트워크

목록 보기

4/12

Electronic mail

전자 메일 3요소

user agents
mail servers
SMTP(Simple Mail Transfer Protocol)

User Agent

a.k.a. mail reader
메일을 작성하고, 수정하고, 읽을 수 있게한다.
예시) Outlook, Thunderbird, iPhone mail client
들어오고 나가는 메세지들은 서버에 저장된다.

Mail Server

mailbox에 들어오는 메시지를 저장한다.
보내고자 하는 메시지를 message queue에 저장한다.z
SMTP를 사용하여 mail server간에 메시지를 주고 받는다.
- client: sending mail server
- server: receiving mail server

SMTP[RFC 2821]

TCP를 사용하여 안정적으로 이메일 메세지를 서버에 전송한다. 25번 포트
direct transfer : sending server에서 receiving server로, 다른 mail server를 거치지 않고 direct로 전송되게 된다.
Handshaking(greeting) & transfer of messages & closure 등 다양한 커맨드를 거쳐 통신을 한다.
HTTP와 비슷하게 command/response interaction이지만, HTTP보다 많은 command와 많은 메시지(7bit의 ASCII)를 사용한다.
사진이나 파일과 같은 경우에는 Encoding을 통하여 Base64로 변환시켜 보내게 된다.

Sender가 UA(User Agent)를 통해 메세지를 만든다.
Sender의 UA가 Sender 자신의 메일 서버로 메세지를 보낸다. -> message Queue에 담는다.
Sender의 Mail Server가 Receiver의 Mail Server로 TCP Connection을 요청한다.
TCP 연결이 되면 TCP Connection을 통해 Receiver의 Mail Server로 메일을 보낸다.
Receiver의 Mail Server는 UA를 사용하여 mail access protocol인 POP(Post Office Protocol), IMAP(Internet Message Access Protocol), HTTP 중에 하나의 프로토콜을 사용하여 데이터를 가져온다.

위와 같은 SMTP Interaction을 telnet을 통해 경험해볼 수 있다.
Command와 같은 경우에는 처음 접속 할 때는 helo를 통해서 transaction을 시작하게 되고, mail from email을 통해서 클라이언트가 서버에게 sender가 누군지 알리고 rcpt to를 통해서 receiver가 누구인지 알려주게 된다. 또한 data를 통해서 메일의 내용을 시작하게 되고, '.'을 통해서 메일의 끝을 알려준다. 그리고 quit을 통해서 connection을 종료하게 된다.

SMTP는 persistent connection을 사용한다.
SMTP는 Header와 Body를 7-bit의 ASCII 코드여야 한다.
CRLF.CRLF 을 통하여 메세지가 끝났다는 것을 인지 시켜준다.

HTTP vs SMTP

HTTP와 같은 경우에는 web Server로 부터 client가 데이터를 pull하게 되는데, SMTP와 같은 경우에는 상대방의 메일 서버로 client가 데이터를 push하게 된다.
둘다 ASCII command/response interaction, status 코드를 갖고 있다.
HTTP는 하나의 Object를 하나의 response를 통해서 보내게 된다. 하지만, SMTP와 같은 경우에는 여러 개의 Object들이 하나의 메세지에 합쳐져서 보내지게 된다.

Mail Message Format

메일의 실제 내용 -> 헤더와 바디로 구성되어 있다.

Header : subject -> 제목 / to, from은 smtp 커맨드랑 별도로 실제(데이터 속에 들어가는) 보내는사람, 받는 사람임(smtp에서는 보내는 서버, 받는 서버의 서버에 대한 정보)
Body : 아스키코드로 되어있는 내용

Mail Access Protocols

SMTP: UA가 메일을 보내기 위해 자기의 메일 서버에 접속할 때, 메일 서버들 사이엥서 메세지를 교환할 때, 사용하는 프로토콜
mail access protocol: 자신의 메일 서버로부터 받은 메일을 가져올 때 사용하는 프로토콜
-> POP : 제일 먼저 사용된 프로토콜. Authorization(유저네임, 패스워드 확인 등 권한부여), download 기능
-> IMAP : pop에 기능 약간 추가. 메일 관리를 위한 폴더 등
-> 요즘은 그냥 웹을 이용하여 메일을 본다.(그저 http 사용)

POP3 protocol

authorization 부분에서 사용자 인증을 진행
transaction 부분
-> list: 메세지 리스트를 보여줌
-> retr : 번호에 해당하는 메세지를 보여줌

POP3 & IMAP

POP3의 특징

다운로드 후 삭제 기능 -> 클라이언트 바꾸면 다시 못읽음
다운로드 후 보관 기능 -> 다운받은 후에 다른 클라이언트에 메세지 복사해서 저장
stateless함

IMPA의 특징

모든 메세지를 서버에 저장함
폴더를 통해 메세지 관리 가능
stateful함 -> 폴더 보고있다가 끄면 다음에 들어왔을 때 그 폴더부터 볼 수 있음

DNS

DNS(Domain Name System)

어떤 서버에 접속하기 위해서는 IP 주소와, Port 번호가 필요하다.
-> 하지만 IP 주소는 기억하기 어렵다.
-> 따라서 인터넷의 호스트를 나타내기 위해서 Domain Name을 사용한다.
-> 어떤 호스트의 IP 주소와 Domain Name은 매핑되어 있다.
사람들은 Domain Name을 통해서 웹 서버에 접속할 수 있다.
패킷들을 서버로 보내기 위해서는 서버의 IP 주소가 필요하다
-> Domain Name을 IP 주소로 변환시키기 위해 필요한 것이 DNS이다.
일종의 distributed한 데이터베이스 : 많은 name server들의 계층 구조로 구현되어 있다.
Application-layer Protocol을 이용해 통신을 하여 Domain Name에 대한 IP 주소를 가져온다.
HTTP, SMTP 등의 Applicaiton을 위한 프로토콜이 아닌, Core Internet Function(보조적 프로토콜)이다.
Core의 라우터에 존재하지 않고, Edge의 Host에 구현되어 있음.

DNS: Service & Structure

Host Name을 IP로 변환한다.
Host Aliasing(도메인 이름 마저 복잡해서 별명이 존재할 수 있는데, 별명만 알아도 도메인 이름을 알게 해 준다.)
Mail Server Aliasing(메일서버도 복잡해서 별명 있을 때 메일 서버를 정확히 알고 싶을 때 사용)
Load Distribution: 도메인 네임과 ip 주소가 1:1 매핑이 아닐 때(접속한 사람이 너무 많아서 서버가 여러개 존재 할 때 (한 도메인에 여러 ip 매핑, 예를 들어 www.naver.com 이 가지고 있는 서버가 여러개 일 때)) 클라이언트의 요청을 분산 시켜준다.

why not centralized DNS? - 왜 중앙화 되지 않은 여러 개의 DNS를 사용하는가?

single point of failure : 하나가 동작하지 않을 경우 모든 서버가 동작하지 않을 수 있기 때문
traffic volume : 양이 많기 때문
distant centralized database : 하나의 데이터베이스만 사용하면 멀리 떨어져 있는 경우 딜레이가 오래 걸리기 때문
maintenance : 유지보수가 어렵기 때문
-> centralized DNS는 확장되지 않는다.

DNS: Distributed & Hierarchical DataBase

분산 & 계층적 구조

-> Root Server가 있음 -> Root Server도 여러 개 존재함.
--> .com, .org, .edu 등으로 구분한 여러 서버가 존재한다.
---> naver.com 등의 서버가 존재한다.

Root Name Server

가장 상위 name server(총 13개의 local root name server가 존재한다)
처음에는 local name server에 물어보는데 만약 없다면 root name server로 연결해 준다.
직접적인 ip 주소를 알려주는 것이 아니라 하위 서버의 주소를 알려준다.

TLD, authoritative servers

TLD servers(top-level domain server)
-> .com .ord .net .edu 등 + 모든 top-level country domain(kr, uk, fr 등)
authoritative DNS servers
-> 야후, 네이버 등의 서버(한 기관만의 DNS Server)
-> 만약, authoritative DNS servers가 데이터를 변경하면 다른데도 바뀐다.

루트서버 -> tld 서버 -> authoritative 서버 순으로 ip 주소를 알려준다.

Local DNS server

계층구조에 꼭 속해있거나 그런것은 아니다.
기관마다 있을 수 있다.(회사, 대학, residention ISP 등) -> default name server 라고도 부른다.
호스트가 DNS 쿼리를 보내면, 쿼리는 local DNS server로 전달된다.
-> 만약 캐쉬 사용으로 ip 주소를 이미 알고 있으면 바로 반환한다.
-> 프록시, 계층구조로의 포워딩 역할을 수행한다.

Local DNS Server는 특정한 네트워크(예: 회사 내부 네트워크)에서 사용하는 DNS 서버를 말합니다.
인터넷에 연결되어 있는 컴퓨터나 모바일 기기에서 웹 페이지나 앱을 실행할 때, 먼저 해당 도메인 이름에 해당하는 IP 주소를 알아내기 위해 DNS 서버에 질의를 보내야 합니다.
하지만 이 때 인터넷 상의 DNS 서버에 질의를 보내면 응답 시간이 느려질 수 있기 때문에, Local DNS Server를 구축하여 해당 네트워크 내에서 도메인 이름과 IP 주소를 매핑하는 역할을 합니다.
따라서 Local DNS Server는 해당 네트워크 내에서 빠른 응답 시간과 효율적인 DNS 캐싱을 통해 빠르고 안정적인 인터넷 사용을 가능하게 합니다.

DNS name resolution example - 동작 예시

iteated query(반복적 질의) -> 이리저리 물어보는거(책임회피)

1. 호스트가 Local DNS Server에 요청
2. Root DNS서버에 없으면 Root DNS 서버에 알고 있냐고 물어봄
3. root DNS 서버가 나는 모르지만 TLD DNS 서버는 알거라고 해서 TLD DNS 서버를 local DNS 서버에 알려줌
4. TLD DNS 서버에 물어봄
5. TLD DNS 서버가 나는 모르지만 authoritative DNS 서버는 알거라고 해당 주소 알려줌
6. authoritative DNS 서버에 물어봄
7. 원하는 ip 주소 알려줌
8. local DNS 서버에 캐쉬로 저장하고 호스트에게 반환해줌

recursive query(재귀적 질의) -> 본인이 직접 물어보는거(책임짐)

1. 호스트가 local DNS 서버에 요청을 함
2. local DNS 서버에 없으면 root DNS 서버에 알고 있냐고 물어봄
3. root DNS 서버가 TLD DNS 서버에 물어봄
4. TLD DNS 서버가 authoritative DNS 서버에 물어봄
5. authoritative DNS 서버는 알고 있기 때문에 주소 알려줌
6. TLD DNS 서버가 받아서 root DNS 서버에 알려줌
7. root DNS 서버가 받아서 local DNS 서버에 알려줌
8. local DNS 서버에 캐쉬로 저장하고 호스트에게 반환해줌
-> 보통 iterative 한 것 사용한다.(많은 데이터 저장 되어 있을 때)

DNS : caching, updating records

어떤 네임 서버든지 새로운 매핑을 알게 되면 캐싱한다.
-> 어느정도 시간(TTL)이 지나면 지워버린다.(바뀔수 있기 때문)
-> TLD 서버는 보통 local name server에 캐싱해 놓는다.(루트 네임에 대한 트래픽을 감소시킨다.)
문제점 : 잘못된 기간이 있을 수 있다.
-> 만약 TTL이 일주일인데, 일주일 사이에 정보가 바뀌었으면 잘못된 정보를 TTL의 남은 기간동안 가지고 있게 된다.
새로운 서버와 변경점에 대한 업데이트와 알려주는 메커니즘을 IETF 표준으로 정의해 두었다.
-> RFC 2136으로 문서화 되어 있다.

ex) 레코드가 변경되는 예시로는 도메인 이름을 다른 IP 주소로 연결하는 경우가 있습니다. 예를 들어, 기존에 www.example.com 도메인 이름이 IP 주소 192.0.2.1로 연결되어 있었다면, 이를 203.0.113.0으로 변경할 수 있습니다. 이 경우 DNS 서버에서 www.example.com에 대한 A 레코드를 192.0.2.1에서 203.0.113.0으로 변경하면 됩니다. 레코드 변경은 일반적으로 TTL(Time-To-Live) 값이 만료되면 새로운 값을 적용합니다.

DNS Records

DNS는 RR(Resource Records)을 분산 데이터베이스에 저장해놓는다.

ttl : 유효기간
네 가지 타입 존재 : A, NS, CNAME, MX -> 타입에 따라 name, value의 의미가 달라진다.
- A record (Address record)
  도메인 이름과 연결된 IPv4 주소를 나타냅니다.
  예: google.com IN A 172.217.11.14
- CNAME record (Canonical Name record)
  도메인 이름의 별칭(alias)을 나타내며, 다른 도메인 이름에 대한 참조를 포함합니다.
  예: www.example.com IN CNAME example.com
- NS record (Name Server record)
  도메인 이름에 대한 네임 서버의 호스트 이름을 나타냅니다.
  예: example.com IN NS ns1.example.com
- MX record (Mail eXchange record)
  도메인 이름과 연결된 이메일 서버의 우선순위와 도메인 이름을 나타냅니다.
  예: example.com IN MX 10 mail.example.com

DNS Protocol, Messages

1. Transaction ID : 메시지의 고유 식별자로, DNS 서버가 이를 활용하여 클라이언트에게 응답 메시지를 보낼 때 사용합니다.
2. Flags : 메시지의 특성을 나타내는 정보로, 주로 query 여부, recursion 요청 여부, authoritative answer 여부 등이 포함됩니다.
3. Questions : 질문의 수와 질문에 대한 정보를 포함합니다. 일반적으로 하나의 query 메시지에는 하나의 질문만 있습니다.
4. Answer RRs : DNS 서버에서 반환하는 답변 메시지의 수와 각각의 레코드를 포함합니다. 일반적으로 query 메시지에서는 이 필드가 비어 있습니다.
5. Authority RRs : 메시지의 권한을 나타내는 정보를 포함합니다. 일반적으로 query 메시지에서는 이 필드가 비어 있습니다.

Inserting records into DNS

업데이트를 어떻게 하는가? -> 새로운 도메인 생겼을 때 DNS에 어떻게 추가하는지

예) Network Utopia 라는 회사가 생겼다

networkutopia.com을 DNS에 등록해야 한다.
-> Authoritative name server의 ip주소와 호스트 네임을 tld 서버에 등록한다.
-> NS 타입(도메인 이름과 authoritative name server의 hostname, A 타입(hostname과 실제 ip 주소)의 레코드가 들어간다.

메일서버도 있으면 MX 타입 레코드도 같이 등록한다.