1. 네트워크 애플리케이션의 원리
1.1 네트워크 애플리케이션 구조
애플리케이션 개발자 관점에서 네트워크 구조는 고정되어 있고해당 애플리케이션에 특정 서비스 집합을 제공한다.
클라이언트-서버 구조에서 항상 동작하고 있는 호스트는 서버, 서버와의 서비스는 클라이언트라는 다른 호스트들로부터 서비스 요청을 받는다.
P2P 구조에서는 항상 켜져 있는 인프라스트럭처 서버에 최소로 의존한다. 대신 애플리케이션은 피어라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하게 한다. P2P 구조의 가장 주목할 만한 특성 중 하나는 자가 확장성(self-scalability) 다.
1.2 프로세스 간 통신
클라이언트와 서버 프로세스
두 프로세스 간의 통신 세션에서 통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을 초기화)하는 프로세스를 클라이언트라 하고, 세션을 시작하기 위해 접속을 기다리는 프로세스를 서버라고 한다.
프로세스와 컴퓨터 네트워크 사이의 인터페이스
프로세스는 소켓(socket) 을 통해 네트워크로 메시지를 주고 받는다. 소켓은 네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이의 API(Application Programming Interface) 라고도 한다.
프로세스 주소 배정
인터넷에서 호스트는 IP 주소로 식별되며, 같은 호스트 내의 수신 프로세스를 식별하기 위해 포트 번호(port number) 가 사용된다.
1.3 애플리케이션이 이용 가능한 트랜스포트 서비스
인터넷을 포함해서 많은 네트워크는 하나 이상의 트랜스포트 프로토콜을 제공한다.
신뢰적 데이터 전송
만약 프로토콜이 보장된 데이터 전송 서비스를 제공한다면 이를 신뢰적 데이터 전송(reliable data transfer) 을 제공한다고 한다. 신뢰적 데이터 전송을 트랜스포트 계층 프로토콜이 제공하지 않을 때, 송신 프로세스가. 보낸 데이터는 수신 프로세스에 전혀 도착하지 않을 수 있다.
전송율
처리율 요구사항을 갖는 애플리케이션은 대역폭 민감 애플리케이션(bandwidth-sensitive application) 이라고 한다. 반면 탄력적 애플리케이션(elastic application) 은 가용한 처리율을 많으면 많은 대로, 적으면 적은 대로 이용할 수 있다.
시간
트랜스포트 계층 프로토콜은 시간 보장(timing guarantee)를 제공할 수 있다.
1.4 인터넷 전송 프로토콜이 제공하는 서비스
TCP 서비스
TCP 서비스는 연결지향형 서비스이자 신뢰적인 데이터 전송 서비스다. 자세한 사항은 다른 문서에서 다룰 것이다.
UDP 서비스
UDP는 최소의 서비스 모델을 가진 간단한 전송 프로토콜이다. 이 역시 다른 문서에서 TCP와 함께 다룰 것이다.
1.5 애플리케이션 계층 프로토콜
애플리케이션 계층 프로토콜(application-layer protocol) 은 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의한다. 애플리케이션 계층 프로토콜은 다음과 같은 내용을 정의한다.
- 교환 메시지 타입
- 여러 메시지 타입의 문법
- 필드의 의미
- 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지 결정하는 규칙
2 웹과 HTTP
2.1 HTTP 개요
웹 페이지는 객체들로 구성된다. 객체는 단순히 단일 URL로 지정할 수 있는 하나의 파일이다.
기본 HTML 파일은 페이지 내부의 다른 객체를 그 객체의 URL로 참조한다. HTTP는 웹 클라이언트가 웹 서버에게 웹 페이지를 어떻게 요청하는지와 서버가 클라이언트로 어떻게 웹 페이지를 전송하는지를 정의한다.
HTTP는 TCP를 전송 프로토콜로 사용한다. 하지만 HTTP 서버는 클라이언트에 대한 정보를 유지하지 않으므로 HTTP를 비상태 프로토콜(stateless protocol) 이라고 한다.
2.2 비지속 연결과 지속 연결
클라이언트와 서버의 상호작용은 요구/응답 쌍으로 구성되어있다. 이때, 분리된 TCP 연결을 통해 보내지는 경우 비지속 연결, 아닌 경우에는 지속 연결이라고 한다.
2.3 HTTP 메시지 포맷
2.4 쿠키
쿠키 기술은 다음 네 가지 요소를 갖는다.
- HTTP 응답 메시지 쿠키 헤더 라인
- HTTP 요청 메시지 쿠키 헤더 라인
- 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
- 웹 사이트의 백엔드 데이터베이스
2.5 웹 캐싱
웹 캐시(Web cache), 또는 프록시 서버(proxy server) 는 기점 웹 서버를 대신하여 HTTP 요구를 충족시키는 네트워크 개체다. 웹 캐시는 자체의 저장 디스크를 가지고 있어, 최근 호출된 객체의 사본을 저장 및 보존한다. 캐시는 서버이자 클라이언트다. 일반적으로 웹 캐시는 ISP가 구입하고 설치한다.
2.6 HTTP/2
HTTP/2 의 주요 목표는 하나의 TCP 연결상에서 멀티플렉싱 요쳥/응답 지연 시간을 줄이는 데 있으며, 요청 우선순위화, 서버 푸시, HTTP필드의 효율적인 압축 기능이다.
HOL(Head of Line) 블로킹: TCP 상에서 웹 페이지에 있는 모든 객체를 전송할 때 발생할 수 있는 문제점. 주로 용량이 큰 파일로 인해 발생한다.
HTTP/2 프레이밍
HTTP/2는 각 메시지를 작은 프레임으로 나누고, 같은 TCP 연결에서의 요청과 응답 메시지를 인터리빙한다.
메시지 우선순위화 및 서버 푸싱
메시지 우선순위화는 개발자들로 하여금 요청들의 상대적 우선순위를 조정할 수 있게 함으로써 애플리케이션의 성능을 최적화할 수 있게 해준다. HTTP/2는 더나아가 객체에 대한 요청이 도착하기도 전에 해당 객체들을 클라이언트로 보낼 수 있다.
3. 인터넷 전자메일
SMTP(Simple Mail Transfer Protocol) 은 HTTP보다 오래된 프로토콜이다. 메일 서버는 SMTP를 이용해 사용자 에이전트간의 메일을 서로 주고 받는다.
앨리스의 에이전트는 메일을 앨리스의 메일 서버에 SMTP 혹은 HTTP를 사용하여 전송한다. 앨리스의 메일 서버는 밥의 메일 서버가 메시지를 수신할 때까지 메일을 지속적으로 SMTP를 통해 푸시한다. 밥의 메일 서버가 메시지를 수신하면, 밥은 HTTP 혹은 IMAP(Internet Mail Access Protocol)을 통해 메일에 접근한다.
4. DNS
DNS는 Domain Name System이다. 호스트는 IP 주소를 통해 식별될 수 있지만, IP주소는 32비트 주소로 이루어져 있으며, 실질적으로 이 주소들을 외워서 사용하는 것은 매우 힘들다. 이를 위한 서비스가 바로 DNS다.
4,1 DNS가 제공하는 서비스
DNS가 제공하는 서비스는 다음과 같다.
- 호스트 이름에 대한 질의 응답.
- 호스트 에일리어싱(host aliasing)
- 메일 서버 에일리어싱(mail server aliasing)
- 부하 분산(load distribution)
4.2 DNS 동작 원리 개요
DNS서버는 다음과 같은 단점을 갖는다.
- 서버의 고장
- 트래픽 양
- 먼 거리의 중앙 집중 데이터베이스
- 유지관리
이를 위해 분산 계층 데이터 베이스가 활용된다.
분산 계층 데이터 베이스
분산 계층 데이터베이스는 루트 DNS 서버, 최상위 레벨 도메인(TLD) 서버, 책임 서버 로 구성되어 있다. 로컬 DNS 서버에 호스트 이름에 대응하는 IP주소가 없는 경우 다른 DNS에게 질의를 보낸다.
DNS 캐싱
DNS 서버는 다른 DNS 서버로부터 받은 응답을 자신의 서버에 저장할 수 있다. 다른 호스트가 같은 응답을 요구하는 경우 이를 사용할 수 있다.
5. P2P 파일 분배
P2P 구조는 항상 켜져있는 인프라스트럭처 서버에 최소한으로 의존하며, 간헐적으로 연결되는 호스트 쌍들이 서로 직접 통신한다. P2P 구조는 자가 확장성을 갖는다. 이와 관련하여 가장 인기있는 프로토콜이 바로 비트토렌트 다. 앨리스는 임의의 피어 집합과 함께 연결된다. 앨리스는 가장 드문 청크를 맨 먼저 요구할 것이며, 비트토렌트는 그녀가 응답할지를 결정하기 위해 현명한 교역 알고리즘을 사용한다. 이 알고리즘의 기본 아이디어는 앨리스가 가장 빠른 속도로 그녀에게 데이터를 제공하는 이웃에게 우선순위를 주는 것이다.
6. 비디오 스트리밍과 콘텐츠 분배 네트워크
6.1 HTTP 스트리밍 및 DASH
HTTP 스트리밍은 클라이언트 간의 가용 대역폭 차이에도 불구하고 똑같이 인코딩된 비디오를 전송받는다. DASH(Dynamic Adaptive Streaming over HTTP) 에서 비디오는 여러 가지 버전으로 인코딩된다. 클라이언트는 동적으로 서로 다른 버전의 비디오를 몇 초 분량의 길이를 갖는 비디오 조각 단위로 요청한다. 그 결과에 따라 적절한 비트율의 비디오 버전을 요청할 것이다. 그리고 비디오 조각을 요청하기 이전에 매니페스트 파일을 HTTP 서버에 요청하여 어떤 버전의 비디오가 있는지를 살펴볼 것이다.
6.2 콘텐츠 분배 네트워크
사용자들에게 균일한 품질의 비디오를 제공하기 위해 사용하는 기술 중 하나가 바로 CDN(Contents Distribution Network) 다. CDN은 일반적으로 서버의 위치에 대해 다음 두 가지 철학 중 하나를 채용하고 있다.
- Enter Deep: 서버 클러스트를 세계 곳곳의 접속 네트워크에 구축함으로써 ISP의 접속 네트워크로 깊숙히 들어가는 것이다.
- Bring Home: 좀 더 적은 수 의 핵심 지점에 큰 규모의 서버 클러스트를 구축하여 ISP를 Home으로 가져오는 개념이다.
사용자가 특정 비디오를 시청하려고 하는 경우 웹 서버, 로컬 DNS 서버, 책임 DNS 서버 등을 거쳐 CDN의 IP 주소를 응답받고, CDN을 통해 비디오를 시청한다.
