[컴퓨터 네트워크] Application Layer

Network application

네트워크 애플리케이션은 여러 다른 종단 시스템(End Systems)에서 실행되고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 과정이다. 예를 들어, 웹 서버 소프트웨어는 브라우저 소프트웨어와 통신한다.

 

여기서 "종단 시스템"이란 사용자가 직접적으로 사용하고 제어할 수 있는 장치를 의미한다. 이러한 종단 시스템에는 개인용 컴퓨터, 스마트폰, 태블릿 등이 포함될 수 있다.

 

네트워크 애플리케이션을 개발할 때 중요한 점은 네트워크 핵심 장치(Network-core devices)에 대한 소프트웨어를 작성할 필요가 없다는 것이다. 네트워크 핵심 장치들은 라우터나 스위치 같은 장비로서, 데이터 패킷의 전송 및 라우팅 등의 기능을 담당한다. 이런 장치들은 일반적으로 사용자 애플리케이션을 실행하지 않는다.

 

사용자 애플리케이션이 종단 시스템에서 실행되므로, 애플리케이션 개발과 배포가 비교적 쉽고 빠르게 이루어질 수 있다. 웹 기반의 애플리케이션이 대부분의 경우에 해당되며, 이런 애플리케이션들은 클라우드 서비스나 사용자의 디바이스에서 동작하면서 서로 데이터를 주고 받게 된다.

 

 

 

 

Client-Server Paradigm

클라이언트-서버 모델(Client-Server Paradigm)은 네트워크 애플리케이션 아키텍처의 한 형태로, 서버와 클라이언트 두 가지 주요 컴포넌트로 구성된다.

 

서버는 다음과 같은 특징을 가진다:

• 항상 켜져있는(Always-On) 호스트: 서버가 언제든지 클라이언트의 요청을 받아들일 수 있어야 함을 의미한다.
• 고정된 IP 주소: 이를 통해 클라이언트가 서버에 연결할 수 있다.
• 데이터 센터에 위치: 이는 확장성(Scaling)을 위한 것으로, 여러 대의 서버를 운영하면 많은 수의 클라이언트 요청을 처리할 수 있다.

 

반면에 클라이언트는 다음과 같은 특징을 가진다:

• 서버와 연락하고 통신: 사용자가 웹 브라우저를 사용하여 웹 사이트에 접속하는 경우, 웹 브라우저는 클라이언트 역할을 하게 된다.
• 간헐적으로 연결될 수 있음: 예를 들어, 스마트폰 앱은 사용자가 앱을 실행할 때만 서버와 연결되고 그 외 시간에는 연결되지 않는다.
• 동적 IP 주소를 가질 수 있음: 대부분의 홈 인터넷 및 모바일 네트워크에서 IP 주소는 동적으로 할당된다.

일반적으로 직접적으로 서로 통신하지 않으며, 대신 중간에서 서버가 중재 역할을 한다.

 

HTTP (HyperText Transfer Protocol), IMAP (Internet Message Access Protocol), FTP (File Transfer Protocol) 등 모두 클라이언트/서버 모델에서 동작하는 프로토콜들이다.

 

HTTP: 웹브라우저(클라이언트)와 웹서버(서버) 사이에서 HTML 문서나 이미지 파일 등의 리소스를 전송하기 위한 프로토콜

IMAP: 이메일 클라이언드와 이메일 서버사이에서 메일을 주고 받기 위한 프로토콜

FTP: 파일을 전송하기 위해 클라이언트와 서버 사이에서 사용하는 프로토콜

 

 

 

 

Peer-Peer architecture

피어-투-피어(Peer-to-Peer, P2P) 아키텍처는 클라이언트-서버 모델과는 다르게 동작한다. 이 모델에서는 중앙 서버가 없으며, 각각의 노드(종단 시스템)가 동등한 관계로 직접 통신하게 된다.

 

P2P 아키텍처의 주요 특징은 다음과 같다:

1. 항상 켜져 있는 서버가 없다: 대신, 모든 노드가 서비스를 제공하고 요청할 수 있다.
2. 임의의 종단 시스템들이 직접 통신한다: 이들은 서비스를 요청하고 제공하는 역할을 동시에 수행한다.
3. 자체 확장성(self-scalability)을 가진다: 즉, 새로운 피어(노드)가 추가될 때마다 그것은 새로운 서비스 용량을 가져오지만, 동시에 새로운 서비스 요구도 생긴다.
4. 동적 IP 주소: 피어들은 간헐적으로 연결되며 IP 주소를 변경할 수 있다.
5. 복잡한 관리: 중앙화된 서버 구조가 없기 때문에 네트워크 관리와 리소스 분배 등이 복잡해질 수 있다.

예를 들면 P2P 파일 공유 시스템 (BitTorrent 등)이 P2P 아키텍처의 대표적인 예이다. 이러한 시스템에서 사용자는 파일 조각을 다른 사용자로부터 직접 받아올 수 있으며, 동시에 자신이 가진 파일 조각도 다른 사용자에게 제공한다.

 

 

 

 

Processes communicating

프로세스는 호스트 내에서 실행되는 프로그램을 의미한다. 같은 호스트 내에서 두 프로세스는 운영 체제에 의해 정의된 인터프로세스 통신(Inter-Process Communication, IPC)을 사용하여 통신할 수 있다.

 

다른 호스트에 있는 프로세스들은 메시지를 교환함으로써 통신한다. 이러한 메시지 교환은 네트워크 프로토콜을 사용하여 이루어진다.

 

클라이언트 프로세스(Client Process)와 서버 프로세스(Server Process)라는 두 가지 주요 유형의 프로세스가 있다:

1. 클라이언트 프로세스: 통신을 시작하는 프로세스다. 일반적으로 사용자 요청에 따라 작동하며, 서버에 연결하여 데이터를 요청하거나 작업을 수행한다.
2. 서버 프로세스: 연락을 기다리는 즉, 클라이언트의 요청을 대기하는 프로세서다. 클라이언트의 요청을 받으면 해당 요청에 따른 데이터나 서비스를 제공한다.

P2P 아키텍처를 가진 애플리케이션들도 클라이언트와 서버 역할을 하는 프로세서가 존재하지만, 이들은 동일한 노드 내에서 동적으로 역할 전환 (클라이언트에서 서버 역할 또는 그 반대) 할 수 있다.

 

 

 

 

Socket

소켓(Socket)은 프로세스가 네트워크를 통해 메시지를 보내고 받는 데 사용하는 인터페이스다. 소켓을 문(Door)에 비유하면 이해하기 쉽다.

1. 프로세스가 메시지를 보낼 때, 그것은 자신의 소켓으로 메시지를 "밀어넣는다". 이것은 문을 통해 무언가를 밖으로 내보내는 것과 유사하다.
2. 메시지를 보낸 후, 프로세스는 그 문의 다른 쪽에 있는 전송 인프라(Transport Infrastructure)가 메시지를 수신 프로세스의 소켓까지 전달하도록 의존한다. 이것은 우리가 편지나 소포를 우체국에 맡긴 후, 우체국이 그것을 수령인에게 전달하도록 의존하는 것과 유사하다.
3. 각각의 통신에서 두 개의 소켓이 관여한다. 하나는 보내는 쪽(클라이언트 혹은 서버)의 소켓이고, 다른 하나는 받는 쪽(서버 혹은 클라이언트)의 소켓이다.

소켓을 사용하여 데이터 교환을 할 때, IP 주소와 포트 번호라는 두 가지 중요한 정보가 필요하다. IP 주소는 호스트 컴퓨터를 식별하며, 포트 번호는 해당 컴퓨터 내에서 실행 중인 특정 프로세스 (즉, 특정 '문')을 식별한다. 이러한 방식으로 네트워크 상에서 각각의 프로세스간 정확한 데이터 교환을 가능하게 한다.

 

 

 

 

IP address / Port number

프로세스가 메시지를 받기 위해서는 고유한 식별자가 필요하다. 호스트 장치는 32비트 IP 주소를 가지며, 이 IP 주소는 인터넷상에서 해당 호스트 장치를 고유하게 식별하는 데 사용된다.

 

그러나 프로세스를 식별하기 위해 호스트의 IP 주소만으로 충분하지 않다. 한 호스트에서 여러 프로세스가 동시에 실행될 수 있기 때문이다. 따라서 프로세스를 구분하기 위해 포트 번호라는 개념이 함께 사용된다.

 

포트 번호는 특정 호스트 내의 특정 프로세스를 식별하는 데 사용되며, IP 주소와 함께 사용되어 네트워크 상의 각 프로세스에 대한 고유한 주소 역할을 한다. 일반적으로 알려진 예들은 HTTP 서버(포트 80)와 메일 서버(SMTP, 포트 25) 등이 있다.

 

 

 

Application-layer protocol

응용 계층 프로토콜(Application-layer protocol)은 통신하는 시스템 간에 어떻게 데이터를 교환할 것인지를 정의한다. 이는 다음과 같은 요소들을 포함한다:

1. 메시지 유형: 교환되는 메시지의 유형을 정의한다. 예를 들어, 요청(request)과 응답(response) 등이 있다.
2. 메시지 구문(Syntax): 메시지 내부의 필드와 필드가 어떻게 구분되는지를 명시한다.
3. 메시지 의미(Semantics): 필드 내 정보의 의미를 정의한다.
4. 통신 규칙: 프로세스가 언제 그리고 어떻게 메시지를 보내고 응답해야 하는지에 대한 규칙을 정의한다.

 

응용 계층 프로토콜에는 크게 두 가지 유형이 있다:

• 오픈 프로토콜(Open Protocols): RFC(Request for Comments)에서 정의된 프로토콜로, 모든 사람이 이러한 프로토콜 정의에 접근할 수 있다. 이렇게 공개적으로 사용 가능한 표준은 다양한 시스템 간 상호 운용성(interoperability)을 가능하게 한다. HTTP(HyperText Transfer Protocol), SMTP(Simple Mail Transfer Protocol) 등이 여기에 해당된다.
• 독점적인 프로토콜(Proprietary Protocols): 특정 회사나 조직이 소유하고 있는 프로토콜이다. 이러한 종류의 프로토콜은 일반적으로 공개되어 있지 않으며, 해당 회사나 조직만이 사용하거나 라이센스를 부여받은 사람들만 사용할 수 있다.

 

 

 

Transport service requirements

여러 애플리케이션과 시스템들은 각각의 요구 사항에 따라 데이터 무결성, 타이밍, 처리량(throughput), 보안 등에 대한 다른 기준치를 가진다.

1. 데이터 무결성(data integrity): 일부 애플리케이션들(예: 파일 전송, 웹 트랜잭 션)은 100% 신뢰할 수 있는 데이터 전송을 필요로 하는 반면, 오디오와 같은 다른 애플리케이션들은 일부 손실을 용인할 수 있다.
2. 타이밍(timing): 인터넷 전화나 인터랙티브 게임과 같은 일부 애플리케이션들은 "효과적"으로 작동하기 위해 낮은 지연 시간을 필요로 한다.
3. 처리량(throughput): 멀티미디어와 같은 일부 애플리케이션들은 "효과적"으로 작동하기 위해 최소한의 처리량을 필요로 한다. 반면에 "탄력적인 앱"(elastic apps)들은 처리량에 영향을 덜 받는다.
4. 보안(security): 데이터의 무결성 및 기밀성 유지를 위해 암호화가 필요하며, 이는 중요한 보안 요소이다.

따라서 개별 네트워크 서비스나 응용 프로그램에서는 이러한 요구사항들을 고려하여 설계되어야 하며, 각각의 상황에 따라 적절한 균형점을 찾아야 한다.

 

 

 

 

 

 

TCP / UDP

TCP와 UDP는 인터넷 프로토콜 스택의 전송 계층에서 사용하는 두 가지 주요 프로토콜이다. 이들은 데이터를 전송하는 방식과 제공하는 서비스에 있어서 몇 가지 중요한 차이점을 가진다.

 

TCP (Transmission Control Protocol) 서비스:

• 신뢰성: TCP는 신뢰할 수 있는 데이터 전송을 보장한다. 이는 패킷이 손실되거나 순서가 잘못되면 재전송을 요청하여 에러를 복구한다.
• 흐름 제어(Flow Control): TCP는 송신량이 수신량보다 많지 않도록 흐름 제어 메커니즘을 제공한다.
• 혼잡 제어(Congestion Control): 네트워크가 과부하 상태일 때 송신자의 데이터 전송률을 조절한다.
• 연결 지향적(Connection-oriented): 클라이언트와 서버 간에 통신을 시작하기 전에 세팅 과정이 필요하다.
• 하지만 TCP는 타이밍, 최소 처리량 보장, 보안 등은 제공하지 않는다.

 

UDP (User Datagram Protocol) 서비스:

• UDP는 비연결형 프로토콜로서 신뢰성 있는 데이터 전송을 보장하지 않는다. 즉, 패킷의 도착 순서나 패킷 손실에 대해 확인하거나 복구하는 메커니즘이 없다.
• 또한 UDP는 흐름 제어, 혼잡 제어, 타이밍, 처리량 보장, 보안 또는 연결 설정 등도 제공하지 않는다.

따라서 어떤 프로토콜을 사용할지 결정할 때는 애플리케이션의 요구 사항과 네트워크 환경 등 여러 요인들을 고려해야 한다. 예를 들어 신뢰성과 순서 유지가 중요한 웹 페이지나 이메일 같은 경우 TCP를 사용하며 반면 실시간 스트리밍 같은 경우 일부 패킷 손실 허용이 가능하므로 UDP가 적합하다.

 

 

 

 

 

 

Securing TCP

기본 TCP 및 UDP 소켓은 암호화 기능이 없으므로, 클리어텍스트(암호화되지 않은 텍스트) 비밀번호가 소켓을 통해 인터넷에 전송될 때 그대로 노출될 수 있다. 이는 보안상 큰 문제가 될 수 있다.

 

이러한 문제를 해결하기 위해 "전송 계층 보안"(Transport Layer Security, TLS)이라는 프로토콜이 사용된다. TLS는 TCP 연결에 대한 암호화를 제공하며, 데이터 무결성과 종단점 인증도 보장한다.

 

TLS는 응용 계층에서 구현되며, 응용 프로그램은 TLS 라이브러리를 사용하여 암호화된 통신을 할 수 있다. 이러한 라이브러리들은 내부적으로 TCP를 사용하여 데이터 전송을 처리한다.

 

TLS 소켓 API(Application Programming Interface)를 사용하면, 클리어텍스트 데이터가 소켓에 입력되더라도 그것들은 인터넷을 통해 암호화된 형태로 전송된다. 이렇게 함으로써 중간자 공격(Man-in-the-Middle Attack) 등의 보안 위협으로부터 데이터를 보호할 수 있게 된다.

 

 

 

 

 

HTTP is 'stateless'

웹 브라우징 과정에서 클라이언트(브라우저)는 서버에 대한 TCP 연결을 초기화한다. 이때 일반적으로 사용하는 포트 번호는 80이다. 서버는 클라이언트로부터의 TCP 연결 요청을 수락하고, 그 후에 HTTP 메시지(응용 계층 프로토콜 메시지)가 브라우저(HTTP 클라이언트)와 웹 서버(HTTP 서버) 사이에서 교환된다. 필요한 데이터를 모두 전송 받은 후, TCP 연결은 종료된다.

 

HTTP는 "상태를 유지하지 않는(stateless)" 프로토콜으로, 서버가 과거의 클라이언트 요청에 대한 정보를 유지하지 않아 간단하고 효율적인 동작을 할 수 있다.

 

반면 "상태를 유지하는(stateful)" 프로토콜은 복잡할 수 있다. 과거의 상태(즉, 히스토리)를 유지해야 하기 때문이다. 만약 서버나 클라이언트가 다운되면, 그들 간의 '상태' 는 일치하지 않을 수 있으며, 이것들을 조정해야 한다.

 

그러나 HTTP가 상태를 기본적으로 유지하지 않더라도 세션 쿠키나 다른 방법들을 통해 상태 정보를 일시적으로 저장하고 추적하는 것은 가능하다. 이런 방법들은 로그인 세션 유지 등의 기능을 제공하기 위해 널리 사용된다.

 

 

 

 

 

Persistent HTTP, non Persistent HTTP

RTT(Round-Trip Time)는 클라이언트에서 서버로 작은 패킷이 이동하고 다시 돌아오는 데 걸리는 시간을 의미한다. 네트워크의 지연 시간을 측정하는 주요 지표 중 하나다.

 

영구적이지 않은 HTTP(Non-Persistent HTTP) 응답 시간은 웹 객체당 다음 세 가지 요소의 합으로 계산될 수 있다:

1. TCP 연결 초기화에 필요한 RTT: 클라이언트와 서버 사이에 TCP 연결을 설정하는 데 필요한 시간이다.
2. HTTP 요청 및 첫 번째 HTTP 응답 바이트가 반환되는 데 필요한 RTT: 클라이언트가 HTTP 요청을 보내고, 그에 대한 첫 번째 응답(헤더 정보 등)을 받아오는 데 필요한 시간이다.
3. 객체/파일 전송 시간: 실제 웹 객체(HTML 파일, 이미지, 스크립트 등)를 전송하는 데 걸리는 시간이다. 이 값은 객체의 크기와 네트워크의 대역폭에 따라 달라진다.

 

 

HTTP 응답 시간은 TCP 연결 초기화에 필요한 RTT, HTTP 요청 및 첫 번째 HTTP 응답 바이트가 반환되는 데 필요한 RTT, 그리고 객체/파일 전송 시간의 합으로 표현할 수 있다.

 

 

영구적인 HTTP(Persistent HTTP, 또는 HTTP/1.1)는 서버가 응답을 보낸 후에도 연결을 유지하는 방식이다. 동일한 클라이언트/서버 간의 후속 HTTP 메시지는 이미 열려 있는 연결을 통해 전송된다.

 

클라이언트는 참조된 객체를 발견하자마자 요청을 보낼 수 있다. 이렇게 하면 모든 참조된 객체에 대해 RTT가 하나만 필요하므로 응답 시간이 절반으로 줄어들 수 있다.

 

영구적인 HTTP의 장점은 다음과 같다:

• 효율성: 여러 요청에 대해 단일 TCP 연결을 사용하므로, 각 요청마다 연결 설정 및 해제에 필요한 시간과 리소스를 절약할 수 있다.
• 성능: 웹 페이지 로딩 시간이 단축되어 사용자 경험이 향상된다.
• 네트워크 자원 최적화: TCP 연결의 개수와 관련된 네트워크 오버헤드를 줄일 수 있다.

그러나 영구적인 HTTP는 상태를 유지하지 않으므로(stateless), 서버는 과거 클라이언트의 요청 정보를 기억하지 않는다. 이 문제는 세션 쿠키 등 다른 메커니즘을 통해 해결할 수 있다.

 

Non-Persistent HTTP와 Persistent HTTP 차이는 다음과 같다.

• Non-Persistent HTTP: 각각의 웹 객체를 가져올 때마다 새로운 TCP 연결을 생성한다. 따라서 웹 페이지를 로딩할 때 많은 RTTs가 발생하며, 이로 인해 전체 페이지 로딩 속도가 저하될 수 있다.
• Persistent HTTP: 한 번의 TCP 연결로 여러 개의 웹 객체를 가져올 수 있다. 즉, 웹 페이지 내 모든 객체를 다운로드하기 위해 같은 TCP 연결을 재사용한다. 이 방식은 RTTs를 줄여주므로 Non-Persistent 방식보다 효율적이다. (keep-alive 메커니즘)

 

 

 

 

 

Cookie

웹사이트와 클라이언트 브라우저는 쿠키(Cookie)를 사용하여 트랜잭션 간에 일부 상태를 유지한다. 쿠키 시스템은 주로 네 가지 구성 요소로 이루어져 있다:

• HTTP 응답 메시지의 쿠키 헤더 라인: 서버가 클라이언트에게 보내는 응답 메시지에 포함된다. 이 헤더 라인은 'Set -Cookie'를 사용하여 쿠키를 설정하며, 이름, 값, 만료 날짜, 경로 등의 속성을 포함할 수 있다.
• 다음 HTTP 요청 메시지의 쿠키 헤더 라인: 클라이언트가 서버에게 보내는 요청 메시지에 포함된다. 이 헤더 라인은 'Cookie'를 사용하여 이미 설정된 쿠키 값을 전송한다.
• 사용자 호스트의 쿠키 파일: 이 파일은 사용자의 웹 브라우저에 의해 관리되며, 여러 웹사이트에서 설정한 모든 쿠키 정보를 저장한다.
• 웹사이트의 백엔드 데이터베이스: 각각의 고유한 ID(즉, "쿠키")와 연관된 데이터를 저장하고 관리한다.

 

예를 들어 Susan이 그녀의 노트북에서 브라우저를 사용해 처음으로 특정 전자상거래 사이트를 방문한다고 가정해보자. Susan의 초기 HTTP 요청이 사이트에 도착하면 사이트는 고유한 ID(즉 "쿠키")와 백엔드 데이터베이스에서 해당 ID에 대한 항목을 생성한다. 그 후 server는 'set-cookie'를 통해 Susan에게 쿠키 ID를 부여하면 Susan으로부터 온 후속 HTTP 요청들은 모두 이 쿠키 ID 값을 포함하게 된다. 이렇게 함으로써 사이트는 Susan을 "식별"할 수 있다.

 

 

 

 

 

 

Web cache

웹 캐시는 자주 방문하는 웹사이트의 데이터를 임시로 저장해두는 공간으로, 사용자가 웹사이트에 접속할 때마다 모든 정보를 서버에서 새로 받아오지 않고, 일부 정보만을 가져옴으로써 네트워크 사용과 응답 시간을 개선하는 역할을 한다.

 

사용자가 브라우저를 특정 웹 캐시로 지정하면 다음과 같은 과정을 거친다:

• 브라우저가 모든 HTTP 요청을 캐시에 보낸다: 사용자가 웹페이지에 접근하려 할 때, 브라우저는 해당 요청을 직접 서버로 보내지 않고 설정된 웹 캐시로 보낸다.
• 객체가 캐시에 있는 경우: 요청받은 객체(웹 페이지, 이미지 등)가 이미 캐시에 저장되어 있다면, 그 객체를 클라이언트(브라우저)에게 바로 반환한다. 이 경우 서버와의 통신 없이 더 빠르게 결과를 얻을 수 있다.
• 객체가 캐시에 없는 경우: 요청받은 객체가 캐시에 없다면, 이제서야 웹 캐시는 실제 서버에 해당 객체를 요청한다. 그리고 받아온 객체를 클라이언트에게 반환하기 전에 자신의 저장공간인 '캐시' 에도 저장해둔다. 이후 같은 요청이 들어올 경우 위의 과정(객체가 캐시에 있는 경우)대로 바로 반환할 수 있다.

 

웹 캐시는 클라이언트와 서버의 역할을 모두 수행한다:

• 서버로서의 역할: 원래 요청을 보낸 클라이언트에게 서버 역할을 한다. 클라이언트가 요청한 리소스를 제공하거나, 해당 리소스가 캐시에서 찾아지지 않으면 원본 서버에서 가져온다.
• 클라이언트로서의 역할: 원본 서버 대상으로 클라이언트 역할을 한다. 필요한 리소스를 직접적으로 원본 서버에서 가져온다.

 

일반적으로, 캐시는 ISP(인터넷 서비스 제공자)가 설치한다. 이런 ISP는 대학, 회사 또는 주거용 인터넷 제공업체 등이 될 수 있다.

1. 클라이언트 요청에 대한 응답 시간 감소: 캐시가 클라이언트에게 더 가깝기 때문에 응답 시간을 줄일 수 있다.
2. 기관의 접근 링크에서 트래픽 감소: 인터넷 트래픽은 비용적인 면과 네트워크 성능 면에서 중요한 이슈다. 특히 많은 사용자를 관리하는 기관에서는 이런 문제가 더욱 중요하다.
3. 인터넷 상의 다수의 캐시 활용 가능성: 인터넷은 많은 수의 캐시로 가득 차 있으며, 이들을 잘 활용하면 "불리한" 컨텐츠 제공자도 내용을 효과적으로 전달할 수 있다.

따라서 웹 캐싱은 네트워크 성능 최적화와 비용 절감 등 여러 방면에서 중요한 도구다.

 

 

 

 

 

Email

이메일 시스템에는 세 가지 주요 요소들이 있다.

1. 사용자 에이전트(User Agents): "메일 리더"라고도 불리는 사용자 에이전트는 이메일 시스템과 상호작용할 수 있게 해주는 응용 프로그램이다. 메일 작성, 편집, 읽기 등의 기능을 제공한다. 예를 들어, Microsoft Outlook, Apple Mail 그리고 Gmail이나 Yahoo Mail 같은 웹 기반 클라이언트가 있다.
2. 메일 서버(Mail Servers): 메일 서버는 사용자를 대신해 이메일을 보내고 받는 컴퓨터화된 시스템이다. 사용자가 이메일을 보낼 때, 먼저 발신 메일 서버(SMTP 서버)로 가게 되며, 그 후 수신인의 수신 메일 서버(보통 POP3 또는 IMAP 서버)로 전송된다. 수신인은 그들의 사용자 에이전트를 사용해 자신들의 수신 메일 서버에서 메시지를 검색할 수 있다.
3. 단순 메일 전송 프로토콜(Simple Mail Transfer Protocol, SMTP): SMTP는 인터넷을 통해 이메일을 보내기 위해 메일 서버가 사용하는 프로토콜이다. 발신인의 발송 용 메일 서버에서 수령인의 받는 용 메서드까지 연결되어 있는 방식으로 동작한다.

이메일을 보낼 때 사용자 에이전트가 SMTP 프로토콜을 통해 해당 이메일을 SMTP서버에 전송한다. 그 후 SMTP서버가 인터넷(다른 SMTP서브들을 거치며)상에서 해당 정보를 전달하여 받아야 하는 사람의 받아오기 용 mail server까지 도달하게 한다.

 

 

 

Mail servers

1.  메일 서버(Mail Servers): 메일 서버는 사용자를 위한 수신 메시지를 포함하는 메일박스와 보내질 예정인 발신 메시지 큐를 관리한다.

• 메일박스(Mailbox): 이는 사용자가 받은 모든 이메일을 저장하는 공간이다. 사용자는 자신의 이메일 클라이언트(사용자 에이전트)를 통해 이 메일박스에 접근하여 새로운 이메일을 확인하고 기존의 이메일을 관리할 수 있다.
• 발신 메시지 큐(Message Queue): 사용자가 보낸 모든 아직 전송되지 않은 이메일을 임시로 저장하는 공간이다. SMTP 프로토콜을 통해 해당 메세지들이 최종 수령인에게 전달된다.

2.  단순 메일 전송 프로토콜(Simple Mail Transfer Protocol, SMTP): SMTP 프로토콜은 두 개의 메일 서버 사이에서 이메일 메시지를 전송하기 위한 규약이다.

• SMTP 클라이언트(Client): 여기서 '클라이언트'란 '보내는' 쪽의 메일 서버를 의미한다. 즉, 발신자가 보낸 원본 이메일을 받아서 목적지인 수령인의 mail server까지 정보를 전달한다.
• SMTP 서버(Server): 여기서 '서버'란 '받는' 쪽의 메일 서버이다. 클라이언트(즉, 보내는 쪽)에서 온 정보(즉, 원본 email)을 받아들여 최종적으로 해당 정보(email)을 받아야 하는 사람에게 전달하게 된다.

메일 전송 과정을 예를 들면 다음과 같다.

1. 메시지 작성: Alice는 사용자 에이전트(User Agent, UA)인 이메일 클라이언트를 사용하여 이메일 메시지를 작성한다.
2. 메시지 전송: Alice의 UA는 작성된 메시지를 그녀의 메일 서버로 전송한다. 메세지는 서버의 메세지 큐에 저장된다.
3. SMTP 연결: 클라이언트 측 SMTP(Simple Mail Transfer Protocol)가 TCP(Transmission Control Protocol) 연결을 통해 Bob의 메일 서버와 통신을 시작한다.
4. 메시지 전달: SMTP 클라이언트가 Alice의 메세지를 Bob의 메일 서버로 보낸다.
5. 메시지 저장: Bob의 메일 서버는 받은 메세지를 Bob의 메일박스에 저장한다.
6. 메시지 읽기: 나중에 Bob은 자신의 사용자 에이전트를 호출하여 사서함에서 이메일을 읽는다.

 

 

E-mail: the RFC (5321)

SMTP(Simple Mail Transfer Protocol)는 클라이언트(연결을 시작하는 메일 서버)에서 서버로 이메일 메시지를 안정적으로 전송하는 데 TCP를 사용한다. 일반적으로 이 작업은 TCP의 25번 포트를 통해 이루어진다.

 

SMTP는 직접 전송 방식을 사용한다. 즉, 보내는 서버(클라이언트 역할을 하는)가 받는 서버로 메시지를 직접 전달한다.

 

SMTP의 전송 과정은 세 단계로 나눌 수 있다:

1. 핸드셰이킹 (인사): 클라이언트와 서버 간에 연결을 설정하고 인증 과정을 거치는 단계다.
2. 메시지 전송: 실제 이메일 메시지가 클라이언트에서 서버로 전송되는 단계다.
3. 종료: 모든 메시지가 성공적으로 전송된 후, 클라이언트와 서버 사이의 연결을 종료하는 단계다.

SMTP는 명령/응답 상호작용 방식(HTTP와 유사)을 사용한다. 명령은 ASCII 텍스트로 구성되며, 응답은 상태 코드와 문구로 구성된다. 그리고 모든 메시지들은 7비트 ASCII 형태여야 한다.

 

따라서 SMTP 프로토콜은 이메일 시스템에서 중요한 역할을 하며, 이메일의 안정적인 송수신에 필수적인 기술이다.

 

 

 

Mail access protocols

이메일을 전송하고 받는 데는 여러 프로토콜이 사용된다:

1. SMTP (Simple Mail Transfer Protocol): 이 프로토콜은 이메일 메시지를 보내는 사람의 메일 서버에서 받는 사람의 메일 서버로 메시지를 전달하고 저장하는 역할을 한다.
2. IMAP (Internet Mail Access Protocol): IMAP은 서버에서 이메일을 검색하는 데 사용되는 프로토콜이다 (RFC 3501 참조). IMAP은 메시지를 서버에 저장하며, 이 프로토콜을 통해 사용자가 서버에 저장된 메시지를 검색하거나 삭제할 수 있다.
3. HTTP (Hypertext Transfer Protocol): 웹 기반의 이메일 서비스(예: Gmail, Hotmail, Yahoo! Mail 등)에서 HTTP는 SMTP(이메일 발송용)와 IMAP(또는 POP으로 이메일 검색용) 위에 웹 인터페이스를 제공한다.

따라서 일반적인 웹 기반 이메일 시스템에서는 SMTP를 통해 발신된 메시지가 수신자의 메일서버에 도착하고 저장되며, 그 후 수신자가 IMAP 혹은 POP3 프로토콜을 통해 자신의 클라이언트 장치(예: PC나 스마트폰 등)에 해당 정보(emails)을 가져오게 된다.

 

 

 

 

 

DNS

인터넷에서 호스트나 라우터는 IP 주소와 도메인 이름을 가지고 있다. 이들은 다음과 같이 사용된다:

1. IP 주소: IP 주소는 데이터그램을 전송할 때 사용되는 식별자다. 이것은 숫자로 이루어진 32비트(IPv4의 경우) 또는 128비트(IPv6의 경우)의 식별자다.
2. 도메인 이름: 도메인 이름은 사람들이 쉽게 기억하고 타이핑할 수 있는 문자열로 구성된 식별자다. 예를 들어, "cs.umass.edu"와 같다.

IP 주소와 도메인 이름 사이의 매핑(즉, 서로를 어떻게 찾아내는지)은 어떻게 이루어질까? 그 답은 DNS(Domain Name System)에 있다.

 

DNS:

• DNS는 계층적으로 구현된 분산 데이터베이스 시스템이다.
• 호스트와 네임 서버가 이름을 해석하기 위해 통신하는 데 사용된다.
• 인터넷의 핵심 기능 중 하나지만, 응용 계층 프로토콜로 구현되어 있다. 
• 네트워크 "엣지"에서 복잡성을 관리한다.

따라서 DNS는 IP 주소를 도메인 이름으로, 그리고 반대로 도메인 이름을 IP 주소로 변환하는 역할을 한다. 이렇게 함으로써 사용자가 웹사이트에 접속할 때 숫자 조합의 IP 주소 대신 사람들이 쉽게 기억할 수 있는 도메인 이름을 입력하여 접속할 수 있게 된다.

 

DNS(Domain Name System)는 다음과 같은 서비스를 제공한다:

• 호스트 이름에서 IP 주소로의 변환: DNS의 가장 기본적인 역할로, 사람이 읽을 수 있는 도메인 이름을 해당 서버의 IP 주소로 변환한다.
• 호스트 별칭(Host Aliasing): 한 호스트에 여러 개의 이름을 부여할 수 있다. 이를 통해 사용자가 다양한 이름으로 동일한 웹사이트에 접근할 수 있게 한다.
• 메일 서버 별칭(Mail Server Aliasing): 메일 서버도 마찬가지로 여러 개의 별칭을 가질 수 있다.
• 부하 분산(Load Distribution): 하나의 도메인 이름에 여러 IP 주소를 연결하여, 웹서버들에 대한 요청을 분산시킬 수 있다. 이는 트래픽이 몰리는 것을 방지하고 성능을 유지하는 데 도움이 된다.

 

왜 DNS를 중앙화하지 않는 것일까? 중앙화된 DNS 시스템은 다음과 같은 문제점들이 있다:

• 단일 실패 지점(Single Point of Failure): 모든 DNS 요청이 한 곳으로 집중되면, 그 시스템에 문제가 생기면 전체 네트워크에 영향을 미칠 수 있다.
• 트래픽 볼륨(Traffic Volume): 중앙화된 시스템은 네트워크 트래픽 처리량이 많아질 경우 부하가 증가한다.
• 먼 거리 데이터베이스(Distant Centralized Database): 사용자와 물리적으로 멀리 떨어진 위치에 데이터베이스가 있다면, 요청 처리 속도가 느려질 수 있다.
• 유지 관리(Maintenance): 중앙에서 모든 정보를 관리하는 것은 유지 보수 측면에서 큰 부담이다.

예를 들어, Comcast는 하루에 약 6000억 번의 DNS 쿼리를 처리해야 한다. 이런 규모에서는 중앙화된 시스템보다 분산형 아키텍처가 훨씬 더 효과적이다. 따라서 DNS는 계층적이고 분산형으로 설계되어 있다.

 

DNS(Domain Name System)는 계층적인 구조를 가지고 있어, 특정 도메인 이름의 IP 주소를 찾기 위해 여러 단계를 거치게 된다. 예를 들어 클라이언트가 "www.amazon.com"의 IP 주소를 알고 싶다면, 다음과 같은 단계로 진행된다:

1. 루트 DNS 서버 쿼리: 클라이언트는 루트 DNS 서버에 ".com" TLD(Top-Level Domain)에 대한 정보를 요청한다. 루트 서버는 ".com" TLD에 대한 DNS 서버 정보(즉, .com TLD의 네임서버)을 응답으로 제공한다.
2. TLD DNS 서버 쿼리: 클라이언트는 이제 받은 정보로 ".com" TLD DNS 서버에 접근하여 "amazon.com" 도메인의 네임서버 정보를 요청한다.
3. 도메인 DNS 서버 쿼리: 마지막으로 클라이언트는 "amazon.com" 도메인의 네임서버에 접근하여 "www.amazon.com" 호스트명에 대한 IP 주소를 요청한다.

위 과정을 통해 클라이언트는 원하는 도메인 이름("www.amazon.com")에 해당하는 IP 주소를 얻게 된다.

 

 

 

 

DNS는 인터넷이 정상적으로 작동하는 데 있어 굉장히 중요한 역할을 한다. 이름을 해석하지 못하는 서버에 대한 최종 연락처로서의 역할을 수행하며, 이 기능 없이는 인터넷이 제대로 작동하지 않을 것이다.

 

또한 DNS는 보안 측면에서도 중요하다. DNSSEC(Domain Name System Security Extensions)은 DNS의 보안을 강화하기 위해 설계된 프로토콜 세트이다. DNSSEC는 인증과 메시지 무결성 보장 등의 기능을 제공하여, DNS 스푸핑 공격 등 다양한 형태의 공격으로부터 사용자를 보호한다.

 

루트 도메인 네임 시스템은 ICANN(Internet Corporation for Assigned Names and Numbers)에 의해 관리된다. ICANN은 전 세계적인 IP 주소 할당, 프로토콜 파라미터 할당, 도메인 이름 시스템 관리 등 인터넷 자원의 조정 역할을 수행하는 비영리 기구이다.

 

 

 

TLD

Top-Level Domain (TLD) 서버는 특정 최상위 도메인(.com, .org, .net, .edu 등)에 대한 DNS 정보를 관리한다. 각 TLD는 일반적으로 특정 기관에 의해 관리되며, 그 예로 다음과 같은 것들이 있다:

• Network Solutions: ".com" 및 ".net" TLD를 관리한다.
• Educause: ".edu" TLD를 관리한다.

또한 각 국가별 도메인(.cn, .uk, .fr 등)도 해당 국가의 기관에서 관리하게 된다.

 

Authoritative DNS 서버는 특정 조직의 도메인 이름에 대한 권한 있는 호스트 이름과 IP 매핑을 제공하는 DNS 서버다. 이러한 서버는 해당 조직이나 인터넷 서비스 제공자(ISP)가 유지할 수 있다.

 

예를 들어 "www.example.com"의 IP 주소를 찾으려면 "example.com" 도메인의 Authoritative DNS 서버에 질의해야 한다. 이 서버는 "www.example.com"에 대응하는 IP 주소를 알고 있거나 알아낼 수 있는 유일한 서버다. 따라서 Authoritative DNS 서버는 웹 브라우저와 같은 클라이언트가 웹사이트의 실제 IP 주소를 찾을 수 있게 해주며, 이 과정은 사용자가 웹사이트에 접속할 때 모두 자동으로 처리된다.

 

 

 

 

Local DNS name servers

Local DNS name server는 계층 구조에 엄격하게 속하지 않으며, 각 ISP(주거용 ISP, 회사, 대학 등)가 하나씩 가지고 있다.

 

호스트가 DNS 쿼리를 만들면, 그 쿼리는 호스트의 로컬 DNS 서버로 전송된다. 로컬 DNS 서버는 최근의 이름-주소 변환 쌍에 대한 로컬 캐시를 가지고 있다.

 

로컬 DNS 서버는 프록시 역할을 하여 쿼리를 계층 구조 안으로 전달한다. 예를 들어, www.example.com의 IP 주소를 찾으려는 요청이 들어오면 로컬 DNS 서버는 먼저 자신의 캐시에서 해당 정보를 찾아본다. 만약 찾을 수 없거나 정보가 오래되었다면 (TTL이 만료된 경우), 그때 비로소 상위 계층의 DNS서버(TLD서버 혹은 루트서버)에게 질의하여 필요한 정보를 얻어온다.

 

따라서 로컬 DNS 서버는 사용자 요청을 처리하는 첫 번째 단계이며, 이후 필요에 따라 복잡한 전체 인터넷 DNS 시스템과 통신하게 된다.

 

 

 

DNS name resolution

DNS 이름 해석에는 반복 쿼리(iterated query)와 재귀 쿼리(recursive query) 두 가지 주요 방법이 있다:

1. 반복 쿼리 (Iterated Query): 이 방식에서 클라이언트(또는 요청하는 DNS 서버)는 DNS 서버에 질의를 보낸다. 받은 DNS 서버가 해당 정보를 알고 있다면 바로 응답하며, 그렇지 않다면 다음으로 찾아볼 수 있는 DNS 서버의 주소를 응답으로 반환한다. 클라이언트는 이렇게 받은 주소로 다시 질의를 보내고, 이 과정을 원하는 정보를 얻을 때까지 반복한다.
2. 재귀 쿼리 (Recursive Query): 이 방식에서 클라이언트는 DNS 서버에 질의를 보내고, 그 결과(원하는 정보 또는 오류 메시지)가 반환될 때까지 기다린다. 만약 받은 DNS 서버가 해당 정보를 모른다면, 그 서버가 다른 DNS 서버에 질의하여 필요한 정보를 얻어온다.

재귀 쿼리와 반복 쿼리 사이에서 주된 차이점은 결과를 찾기 위해 필요한 추가적인 작업을 누가 수행하는가이다. 재귀적인 경우, 요청을 처음 받은 DNS서버가 모든 작업을 처리하며, 반복적인 경우 요청자(클라이언트 혹은 요청하는 DNS서버) 자신이 추가적인 작업을 수행한다.

 

 

 

 

 

 

CDNs

동영상 스트리밍 트래픽은 인터넷 대역폭의 주요 소비자이다. Netflix, YouTube, Amazon Prime 등은 2020년 기준으로 주거용 ISP 트래픽의 80%를 차지하고 있다. 이러한 동영상 스트리밍 서비스는 다음과 같은 두 가지 주요 도전 과제에 직면해 있다.

1. 규모: 약 10억 사용자에게 어떻게 서비스를 제공할 것인가? 단일 메가 비디오 서버는 작동하지 않을 것이다. 왜냐하면, 그런 규모의 사용자 수를 지원하기 위한 네트워크 대역폭, 저장 공간, 컴퓨팅 자원 등이 필요한데 이는 실질적으로 한대의 서버로는 충분하지 않기 때문이다.
2. 다양성: 사용자들 간에 다양한 능력이 있다. 예를 들어 유선과 모바일, 대역폭이 풍부한 사용자와 그렇지 않은 사용자 등이 있다.

위와 같은 문제들을 해결하기 위해 분산형 애플리케이션 수준 인프라가 필요하다. 이는 여러 위치에 분산된 데이터 센터와 캐시 서버로 구성되며, 사용자에게 가장 가까운 위치에서 콘텐츠를 제공하여 네트워크 지연 시간을 줄여주고 대역폭 요구사항을 분산시켜 처리한다.

 

CDN(Content Delivery Network) 기술도 이러한 방식 중 하나로 넷플릭스나 유튜브 등 많은 비디오 스트리밍 사이트들이 CDN을 활용하여 전 세계적인 규모의 동영상 스트리밍 서비스를 제공하고 있다.

 

CDN의 주요 전략에는 'Deep Enter'와 'Bring Home'이 있다.

1. Deep Enter: CDN 서버를 많은 액세스 네트워크 안쪽에 깊게 배치한다. 이렇게 하면 사용자에게 가깝게 위치하여 데이터 전송 시간을 줄일 수 있다. 예를 들어, Akamai는 2015년 기준으로 120개 이상의 국가에 240,000개의 서버를 배치하여 전 세계적으로 콘텐츠를 제공하고 있다.
2. Bring Home: 액세스 네트워크 근처(하지만 내부에는 아닌)의 POPs(Point of Presence)에서 큰 클러스터 몇 개(10개 정도)를 운영한다. 이렇게 하면 네트워크 트래픽을 분산시키고, 여전히 사용자에게 상대적으로 가깝게 콘텐츠를 제공할 수 있다. 이 방식은 Limelight와 같은 회사에서 사용되고 있다.

이러한 CDN 방식은 다음과 같은 장점들이 있다:

• 확장성: 서버가 여러 위치에 분산되어 있으므로, 사용자 수나 요청된 콘텐츠 양이 증가해도 시스템 전체의 성능을 유지할 수 있다.
• 내구성과 가용성: 한 서버나 위치에서 문제가 발생하더라도 다른 서버들이 계속해서 콘텐츠를 제공할 수 있으므로 시스템 전체가 중단될 확률이 줄어든다.
• 네트워크 성능 최적화: 각 사용자에 가장 가까운 서버에서 콘텐츠를 제공함으로써 데이터 전송 지연을 최소화하고 네트워크 혼잡을 줄일 수 있다.

따라서 CDN 방식은 대규모 스트리밍 시스템을 구축하는데 가장 널리 사용되는 방법이다.

 

 

 

 

Multimedia:video

비디오는 일정한 속도로 연속적으로 표시되는 이미지의 시퀀스이다. 예를 들어, 영화에서는 초당 24개의 이미지(프레임)가 일반적으로 사용된다.

 

디지털 이미지는 픽셀의 배열로 구성되며, 각 픽셀은 비트로 표현된다. 색상 이미지에서 각 픽셀은 보통 빨강, 녹색, 파랑(RGB) 세 가지 색상 성분을 나타내는 비트를 사용하여 표현된다.

 

코딩은 이미지 내부 및 이미지 간의 중복성을 활용하여 이미지를 인코딩하는 데 사용되는 비트 수를 줄이는 방법이다. 이러한 최적화 기법에는 공간적(spatial) 인코딩과 시간적(temporal) 인코딩이 있다.

1. 공간적(Spatial) 인코딩: 같은 이미지 내부에 있는 정보에 대한 중복성을 제거한다. 예를 들어, 하늘을 찍은 사진에서 많은 픽셀들이 유사한 파랑색일 수 있으며, 이런 유사성을 활용해 데이터를 압축할 수 있다.
2. 시간적(Temporal) 인코딩: 연속된 프레임들 사이에 발생하는 정보의 중복성을 제거한다. 대부분의 동영상에서 한 프레임에서 다음 프레임으로 넘어갈 때 모든 것이 완전히 바뀌진 않기 때문에 이전 프레임과 다음 프레임 사이에 많은 유사성이 있는 경우 이 정보를 활용해 데이터를 압축할 수 있다.

위와 같은 방식들로 동영상 데이터가 압축되며 저장 공간과 전송 대역폭 요구사항을 줄일 수 있게 된다.

 

동영상 인코딩에는 주로 두 가지 방식인 CBR(Constant Bit Rate)과 VBR(Variable Bit Rate)가 사용된다.

1. CBR (Constant Bit Rate): CBR은 비디오 인코딩 비율이 고정되어 있다. 이 방식은 네트워크 대역폭이 일정하거나 예측 가능한 경우에 적합하다. 하지만, 비트 전송률이 일정하기 때문에 데이터가 많이 필요없는 부분에는 데이터가 낭비되고, 비트 전송률 이상의 데이터가 필요할 때는 화질이 떨어질 수 있다.
2. VBR (Variable Bit Rate): VBR은 비디오 인코딩 비율이 공간적 또는 시간적 인코딩의 양에 따라 변화한다. 이 방식은 각각의 프레임에 필요한 만큼의 데이터를 할당함으로써 전반적인 품질을 개선할 수 있다. 하지만, 네트워크 대역폭 요구사항이 예측하기 어려울 수 있으며, 실시간 스트리밍과 같은 애플리케이션에서는 문제가 될 수 있다.

 

 

 

 

Streaming stored video

동영상 스트리밍은 다양한 도전 과제에 직면하고 있다. 주요 문제점은 다음과 같다:

1. 변동하는 서버-클라이언트 대역폭: 네트워크의 혼잡도에 따라 시간이 지남에 따라 서버와 클라이언트 사이의 대역폭이 변동할 수 있다. 이는 사용자의 집, 접속 네트워크, 네트워크 핵심 부분, 비디오 서버에서 모두 발생할 수 있다.
2. 패킷 손실 및 지연: 혼잡도로 인한 패킷 손실과 지연은 플레이아웃을 지연시키거나 비디오 품질을 저하시킬 수 있다.

위와 같은 문제를 해결하기 위해 여러 가지 방법들이 사용되고 있다:

• 어댑티브 스트리밍: 클라이언트는 현재의 네트워크 조건에 따라 적절한 비율로 비디오를 요청한다. 예를 들어, 네크워크 상태가 좋다면 높은 해상도의 비디오를 요청하고, 상태가 나쁘다면 낮은 해상도의 비디오를 요청한다.
• 버퍼링: 클라이언트는 재생 전에 일정량의 데이터를 버퍼링(미리 받아 놓음)하여 패킷 지연 시간을 줄인다.
• 전송 제어 프로토콜(TCP) 사용: TCP는 패킷 손실을 감지하고 재전송함으로써 데이터 전송을 안정화한다.

 

동영상 스트리밍에서는 다른 도전 과제들도 존재한다:

1. 클라이언트 상호작용: 사용자는 비디오를 일시정지하거나, 빨리 감기, 되감기, 비디오 내의 특정 부분으로 점프하는 등의 상호작용을 수행할 수 있다. 이러한 기능들은 서버와 클라이언트 사이에 추가적인 통신과 처리를 필요로 한다.
2. 비디오 패킷 손실: 네트워크 혼잡이나 오류로 인해 비디오 패킷이 손실될 수 있다. 이 경우, 해당 패킷은 재전송되어야 하며, 이는 추가적인 대역폭을 요구하고 지연을 발생시킬 수 있다.

 

 

 

DASH

DASH(Dynamic Adaptive Streaming over HTTP)는 HTTP 프로토콜을 사용하여 동영상을 스트리밍하는 기술이다. DASH는 서버와 클라이언트 간의 상호작용을 통해 네트워크 조건에 맞게 비디오의 품질을 동적으로 조정한다.

 

서버 측에서의 작동 방식:

1. 서버는 비디오 파일을 여러 개의 청크(chunk)로 나눈다.
2. 각 청크는 다른 비율(rate)로 인코딩되어 저장된다.
3. 매니페스트 파일(manifest file)은 다른 청크에 대한 URL을 제공한다.

클라이언트 측에서의 작동 방식:

1. 클라이언트는 주기적으로 서버-클라이언트 대역폭(bandwidth)를 측정한다.
2. 매니페스트를 참조하여, 클라이언트는 한 번에 하나의 청크를 요청한다.
3. 현재 대역폭에 따라 지속 가능한 최대 코딩 비율(rate)을 선택한다.
4. 시간에 따라(즉, 해당 시점에서 사용 가능한 대역폭에 따라) 다른 코딩 비율을 선택할 수 있다.

DASH 기법은 네트워크 상태가 변할 때마다 가장 적합한 품질의 스트림을 선택함으로써 끊김 없는 재생 경험과 최적화된 품질 경험을 제공하려고 한다.

 

예를 들어, 네크워크 상태가 좋아지면 클라이언트는 높은 해상도(비율이 높은) 청크를 요청할 수 있다. 반대로, 네크워크 상태가 나빠지면 낮은 해상도(비율이 낮은) 청크를 요청하여 버퍼링 현상(재생 중단 및 로딩 지연 현상) 없이 재생 경험 유지할 수 있다.

 

DASH와 같은 어댑티브 스트리밍 기법들은 오늘날 YouTube, Netflix 등 대부분의 온라인 스트리밍 서비스에서 사용되고 있다.

 

DASH(Dynamic Adaptive Streaming over HTTP)는 클라이언트에게 상당한 "지능"을 부여한다. 즉, 클라이언트는 다음과 같은 결정을 내릴 수 있다:

1. 청크 요청 시점 결정: 클라이언트는 버퍼가 고갈(buffer starvation)되거나 넘치지(buffer overflow) 않도록 청크를 요청하는 시점을 결정한다. 이를 위해 클라이언트는 주기적으로 버퍼의 상태를 모니터링하고, 적절한 시점에 청크를 요청하여 끊김 없는 재생 경험을 유지한다.
2. 요청할 인코딩 비율 결정: 사용 가능한 대역폭에 따라 클라이언트는 요청할 청크의 인코딩 비율(즉, 품질)을 선택한다. 대역폭이 충분하다면 높은 해상도(높은 비율)의 청크를, 그렇지 않다면 낮은 해상도(낮은 비율)의 청크를 선택할 수 있다.
3. 어디에서 청크를 요청할지 결정: 클라이언트가 위치한 가장 가까운 서버나 가장 많은 대역폭을 제공하는 서버 등에서 처음으로 청크를 받아올 수 있다.

따라서 스트리밍 비디오는 다음 세 가지 주요 구성요소로 이루어져 있다고 볼 수 있다:

• 인코딩: 원본 동영상 데이터가 압축되며 저장 공간과 전송 대역폭 요구사항을 줄인다.
• DASH: 동적으로 적응하여 네트워크 조건 변화와 사용자의 재생 경험에 맞게 스트리밍 품질을 조정한다.
• Playout Buffering: 네트워크 지연과 지터로부터 재생 경험을 보호하기 위해 사용된다.

위 세 가지 구성요소들이 함께 작동함으로써, 스트리밍 비디오 서비스들은 최적화된 품질과 끊김 없는 재생 경험을 제공할 수 있다.

 

 

 

 

 

 

 

OTT

OTT(Over-The-Top) 서비스는 전통적인 미디어 제공 방식을 우회하여 직접 소비자에게 콘텐츠를 제공하는 방식이다. 이러한 서비스는 인터넷의 혼잡성과 같은 여러 도전과 맞닥뜨릴 수 있다. 다음은 그 중 일부이다:

1. 어느 CDN 노드에서 콘텐츠를 검색할 것인가?: 사용 가능한 여러 CDN 노드 중 어느 것을 선택할지 결정하는 것은 중요한 문제다. 이 선택은 사용자의 위치, 네트워크 상태, 서버의 부하 등 다양한 요소에 따라 달라질 수 있다.
2. 혼잡 상황에서의 시청자 행동: 인터넷이 혼잡해지면 사용자들의 경험이 저하될 수 있다. 이런 상황에서 사용자들이 어떻게 반응하는지 파악하는 것은 OTT 서비스 제공업체에게 중요하다. 예를 들어, 버퍼링 시간이 길어질 경우 사용자들이 다른 콘텐츠로 전환하거나 서비스를 완전히 종료할 수도 있다.
3. 어떤 콘텐츠를 어느 CDN 노드에 배치할 것인가?: 모든 콘텐츠를 모든 CDN 노드에 저장하는 것은 비용 효율적이지 않을 수 있으므로, 어떤 콘텐츠가 어느 위치의 사용자들에게 가장 인기 있는지 파악하여 효율적으로 분산 저장해야 한다.

위와 같은 도전 사항들을 해결하기 위해서는 데이터 분석, 네트워크 엔지니어링 및 최적화 기법 등 다양한 전략과 기술이 필요하다.

 

 

 

Netflix와 같은 OTT(Over-The-Top) 서비스에서 비디오 스트리밍 프로세스는 다음과 같다:

1. 사용자 로그인: 사용자(Bob)가 Netflix 계정을 관리하고 로그인한다.
2. 비디오 탐색: Bob은 Netflix의 콘텐츠 라이브러리를 탐색하고 특정 비디오를 선택한다.
3. videoManifest 파일 요청: 선택된 비디오에 대한 videoManifest 파일이 요청된다. 이 파일은 비디오의 메타데이터(예: 제목, 설명, 길이 등)와 함께 각각의 청크에 대한 정보(예: URL, 인코딩 비율 등)를 포함하고 있다.
4. 특정 비디오 반환: videoManifest 파일을 바탕으로 클라이언트는 특정 비디오를 반환 받는다.
5. DASH 서버 선택 및 연결: 클라이언트는 DASH(Dynamic Adaptive Streaming over HTTP) 서버를 선택하고 연결한다. 이 서버는 사용 가능한 네트워크 조건과 클라이언트의 재생 요구 사항에 따라 적절한 인코딩률을 가진 청크를 제공한다.
6. 스트리밍 시작: DASH 서버와의 연결 후, 실제 스트리밍 과정이 시작된다. 클라이언트는 버퍼가 고갈되지 않도록 주기적으로 청크를 요청하며, 네트워크 조건 변화에 따라 다른 인코딩률의 청크를 요청할 수 있다.
7. 재생 및 버퍼링 관리: 클라이언트는 받아온 청크들을 재생하면서 동시에 버퍼링 상태도 관리한다. 만약 네트워크 상태가 좋지 않아 버퍼링 시간이 길어질 경우, 클라이언트는 더 낮은 인코딩률의 청크를 요청하여 재생 경험을 최적화할 수 있다.

위 과정들은 사용자가 원활하게 동영상을 시청할 수 있도록 하는 데 필요한 단계들로 구성되어 있다.