Application Layer 개요

• 애플리케이션의 구현은 끝단(end-system)에 있다.
• 물론 네트워크 코어(라우터)에도 관리 목적의 애플리케이션을 구현할 수 있지만, 라우터 본연의 기능은 아니다.

연결 유형

• Client-server paradigm HTTP, IMAP, FTP
  • Server : always-on, 고정(permanent) IP 주소
  • Clients : 서버와 통신(intermittently connected), 동적 IP 주소(일반적으로), Client간 통신하지 않음
• Peer-peer architecture P2P 파일공유
  • no always-on server (서버와 클라이언트가 모두 존재하긴 한다)
  • 임의의 end-system들이 직접 통신
    → self scalability : 새로운 peer들은 새로운 서비스 capacity를 가져옴

프로세스 통신

• Process : host에서 동작하는 프로그램
• Socket : 애플리케이션이 transport layer를 이용하기 위해 '문(門)'과 같이 사용. (수신/송신 측에 각각 하나씩 있다.)

• 통신 방법
  • inter-process communication : 같은 host내의 두 프로세스가 통신할 때 사용 (OS가 정의하는 전통적 방법)
  • message : 다른 host의 프로세스들이 메시지를 교환하여 통신하는 방법
    • client process : 통신을 시작(initiate)
    • server process : 클라이언트의 요청 대기(waits to be contacted)
• process identifier
  • IP 주소 (network layer)
  • port 번호 (transport layer) : e.g., HTTP 80 / mail 25
    → 같은 IP(호스트)에서 여러 프로세스가 돌아가고 있음
    → 특정 프로세스를 지정하려면 포트번호도 필요

Application Layer protocol이 정의하는 것

• 분류
  • open protocols : RFC에 정의, 상호운용성(interoperability)필요 e.g., HTTP, SMTP
  • proprietary protocols
• 정의 요소
  • 교환되는 메시지의 유형
  • 메시지 문법(syntax) : 메시지에 어떤 필드를 넣을지, 어떻게 묘사(delineate)할지
  • 메시지 의미(semantics) : 필드 상 정보들의 의미
  • 규칙(rule) : 언제 어떻게 프로세스들이 메시지를 송수신?

Application단이 Transport단에 요구하는 것

각 요소에 대해 제공받기를 바라는 기준이 있다.

• data integrity : 완벽한 전송 요구 또는 약간의 손실 허용 (require 100% reliable data transfer OR can tolerate some loss)
• timing : 낮은 딜레이 요구 또는 어느정도 딜레이는 허용
• throughput : 최소 처리량 요구 또는 주어진 처리량대로 동작
• security

예시는 다음과 같다.

• 게임 : 데이터 손실 조금 나도 괜찮지만 최소처리량과 낮은 딜레이 요구
• 메일 : 손실 나면 안되고 처리량은 주는대로 받음. 딜레이는 때에 따라 다름.

Transport protocol의 서비스

• TCP Service
  • reliable transport
  • flow control : 받는 속도보다 빨리 못보냄
  • congestion control : 망에 심한 부하가 안걸리게 송신측 제한
  • connection-oriented : 연결 체결 필요
  • 본래 제공하지 않는 것 : timing, 최소 throughput guarantee, security
• UDP Service
  • unreliable data transfer
• Security(TLS)
  • ( 원래 없었다. TCP 보안기능을 애플리케이션단에 구현했다. )
  • encrypted TCP connection
  • data integrity
  • end-point authentication

Web(HTTP)

• HTTP : HyperText Transfer Protocol
  → 웹페이지는 Object들로 구성된다. 다르게 말하면 base HTML파일은 URL로 각 Object들을 참조한다.
• RTT : Round Trip Time (패킷이 클라이언트-서버 왕복하는 시간)

HTTP 특징

• 클라이언트/서버 모델
  • 클라이언트 : (브라우저) 웹 오브젝트들을 요청/수신/표시
  • 서버 : (웹서버) 요청에 대한 응답으로 오브젝트를 송신
• TCP (Port 80) : 브라우저-웹서버 사이에 메시지 교환 (메시지는 ASCII사용)
• stateless
• pull

연결 유형

• Non-persistent HTTP : 개별 오브젝트 전송마다 TCP Connection 여닫음
  • 통신 과정 : TCP커넥션 열기 → 오브젝트 하나 받기 → TCP커넥션 닫기 → TCP연결 열기 → 오브젝트 하나 받기 → ...
  • ⚠ 문제 : HTTP response time이 길다 ( = 2RTT + file transmission time )
• Persistent HTTP : 하나의 TCP커넥션을 열어 여러 오브젝트 전송한 뒤 닫음
  • 통신 과정 : TCP커넥션 열기 → 필요한 오브젝트 다 받기 → TCP커넥션 닫기
  • TCP커넥션을 유지하도록 알리는 방법 : 요청 메시지 헤더에 Keep-Alive, Connection : keep-alive 표시

Request Message

• General Format
  • request line
  • header lines
  • body
• Method
  • POST : body에 데이터
  • GET : URL에 데이터
  • HEAD : 헤더만
  • PUT : POST요청의 바디를 보내서 존재하는 파일 완전히 대체

Response Message

• General Format
  • status line
  • header lines
  • data
• HTTP response status code
  • 200 OK
  • 301 Moved Permanently
  • 400 Bad Request
  • 404 Not Found
  • 505 HTTP Version Not Supported

Cookie

HTTP는 상태가 없기 때문에(stateless) 트랜잭션 사이의 상태를 저장하기 위해 쿠키를 사용한다.

• 제공
  • 서버→클라이언트 : 응답 메시지의 쿠키 헤더 라인
  • 클라이언트→서버 : 그 다음번 요청 메시지의 쿠키 헤더 라인
• 관리
  • 클라이언트 : 쿠키형태로 유저 호스트에 저장 (브라우저가 관리)
  • 서버 : 백엔드 DB에 저장
• 보안 문제 : Thrid party persistent cookie(Tracking Cookie)를 사용하면 공통 식별자를 다른 웹사이트가 볼 수도 있음

Web caches(proxy servers)

buffer와 같은 역할을 한다. 일반적으로 ISP가 설치한다.

• 웹캐시의 역할
  • 클라이언트로서 : Origin서버에서 오브젝트 가져옴
  • 서버로서 : 브라우저에 오브젝트 제공함
• 브라우저 입장의 웹캐시 사용
  1. 클라이언트는 먼저 웹캐시에 오브젝트 요청
  2. 웹캐시에 오브젝트 있으면 응답받고 끝
  3. 웹캐시에 오브젝트 없으면 origin server에 요청, 응답받고 끝
• 왜쓰냐
  • origin server보다 응답속도 빠름 ( response time = end-end delay )
  • 기관의 access link 트래픽 경감.
  • 통신망 개선보다 캐시 까는게 더 저렴함
• 성능
  • 캐시 없을 때 : end-end delay = internet delay + access link delay + LAN delay
  • 캐시 있을 때 : average end-end delay = cache miss rate$\times$(delay from origin server) $+$ cache hit rate$\times$(delay from cache)

Conditional GET

웹브라우저는 받은 문서를 저장(캐싱)해둔다.
웹서버에 문서를 요청할 때 캐싱된 것과 서버의 것이 같다면 가져오지 않음으로써 응답속도를 줄일 수 있다.

웹서버에 문서를 요청할 때 헤더값 if-modified-since:날짜를 보내 서버의 문서가 수정되었는지 검사한다.

• 수정되었다면 : 새로운 문서를 받아온다.
• 수정되지 않았다면 : 헤더만 있는 응답을 보낸다. 304 Not Modified

HTTP Version

여러 오브젝트에 대한 요청 딜레이 감소가 주된 목표
** HOL blocking(Head-of-line blocking) : 앞에 큰 오브젝트가 뒤에 작은 오브젝트 길막. 큰 것 하나때문에 전체적으로 전송이 지연되는 현상.

• HTTP/1.1
  • 단일 TCP커넥션으로 여러 pipelined GET 처리 (FCFS)
  • FCFS는 HOL blocking을 야기하여 전체 딜레이 증가
  • loss 복구시 전송시간 저하
• HTTP/2
  • 👍 서버는 클라이언트가 정한 순서대로 오브젝트 전송 (FCFS가 필수가 아님)
  • 👍 미리보내기 (push unrequested object to client)
  • 👍 HOL blocking 완화 : 오브젝트를 Frame으로 나누고 적당한 순서로 지정해 보낸다.
  • 👀 HTTP/2도 여전히 단일 TCP커넥션을 사용하므로 loss가 일어나면 복구(재전송)과정에서 전송시간이 저하된다. (HTTP/1.1에서 여러개 병렬 TCP커넥션을 여는 방법이 있긴 했었는데 편법이라서 그닥 바람직하지 않음)
• HTTP/3
  • UDP사용, (HTTP-QUIC-UDP)
  • 보안 기능 제공
  • 오브젝트별 에러/혼잡 제어

E-mail(SMTP, IMAP)

• SMTP : Simple Mail Transfer Protocol (Push동작)
  → 메일 쓰기, 다른 메일서버로 보내기
• IMAP : Internet Mail Access Protocol (Pull동작)
  → 메일 서버에 와있는 이메일(메시지) 가져오기, 지우기
  → 같은 역할 POP (Post Office Protocol)

구성요소

• user agents(UA) = mail reader
• mail servers
  ** 보내는 메일서버가 클라이언트역할, 받는 메일서버가 서버역할
  • mailbox : 받은 메시지 보관
  • message queue : 보내는 메시지가 거쳐감
• 프로토콜 : SMTP, IMAP

SMTP

메일서버 사이에 메시지를 보내기 위한 프로토콜
** 메시지는 7-bit ASCII이고 CRLF.CRLF로 끝지점을 표시

• 특징
  • TCP사용. 포트번호 25 (Persistent TCP Connection)
  • 직접 전송(Direct Transfer)
  • 여러 오브젝트를 multipart 메시지로 보냄
  • push
• 동작 단계
  1. handshaking (greeting)
  2. transfer of messages
  3. closure
• 상호작용
  • command : ASCII text
  • response : status code and phrase

메일 송수신 전체 동작

• 보내기 (SMTP)
  1. 송신측 유저 에이전트에서 메일 작성
  2. 송신측 메시지 큐
  3. 수신측 메일 박스
• 받기 (IMAP, POP)
  1. 수신측 메일 박스에 이미 이메일 와있음
  2. 수신측 유저 에이전트에서 메일박스 내용 가져오기

유저 에이전트 인터페이스는 웹기반인 경우가 많은데(HTTP),
이는 SMTP, IMAP, POP 위에서 동작함

Domain Name System

DNS : 분산된 계층형 데이터베이스 (distributed, hierarchical database)
query <-> reply

역할

• hostname을 IP주소로 변환
• host aliasing : alias name을 canonical name으로 변환
• mail server aliasing
• load distribution : 여러 IP주소와 한 hostname을 연관지음

계층

• Root name servers : .in을 찾을 수 있음
  • 12개 기관의 13개 루트 서버 존재. 13개 서버의 복사본이 세계 곳곳에 존재
  • DNSSEC 제공
  • ICANN이 관리
• Top Level Domain(TLD) servers : wonj.in을 찾을 수 있음
  • .com, .net, .kr, .edu 등 TDL의 네임 서버
• Authoritative servers www.wonj.in을 찾을 수 있음
  • 조직(서비스 제공자)가 소유한 네임 서버.
  • authoritative hostname을 IP 주소로 매핑

Local DNS name server

로컬 DNS 서버는 ISP에 의해 설치된다. (Default name server)
호스트의 DNS 쿼리는 로컬 DNS로 간다.
캐시가 없다면 쿼리를 받은 로컬 DNS는 DNS 3계층으로 쿼리를 보낸다.

• iterated query : 로컬DNS가 직접 루트DNS, TLD DNS, Authoritative DNS와 통신
• recursive query : 로컬DNS가 루트DNS에게 이후 질의를 전가함

              [Recursive query]
       1         2          3         4
호스트----> 로컬 ----> 루트 ----> TLD ----> Authoritative
	 <----  DNS <---- DNS <---- DNS <---- DNS
       8         7          6         5

• caching :
  • 로컬 DNS서버는 일반적으로 TLD DNS서버 내용을 캐싱
  • 캐싱된 내용은 TTL(Time To Live)동안 유지
  • best-effort 이름-주소 변환

DNS records

RR(Resource Record)의 포맷 : {name, value, type, ttl}

name	value	type
hostname	IP adress	A
domain	hostname of authoritative name server	NS
alias name	canonical name	CNAME
name	name of mail server	MX

DNS 보안

• DDoS
• Redirect attacks
  • man in middle
  • DNS poisoning
• Exploit DNS for DDoS

P2P

특징

• no always-on server (서버와 클라이언트가 모두 존재하긴 한다)
• 임의의 end-system들이 직접 통신
  → self scalability : 새로운 peer들은 새로운 서비스 capacity를 가져옴

파일 분배 시간 비교

p2p는 각 피어가 클라이언트이자 서버이므로 파일을 동시다발적으로 배포한다. 때문에 client-server모델에 비해 파일 배포속도가 빠르다.

• client-server : $D_{CS} = max\{NF/u_s, F/d_{min}\}$
  • N : 피어 개수, F : 파일 크기
  • $u_s$ : 서버 업로드 capacity, $d_{min}$ : 가장 느린 피어의 다운로드 capacity
• p2p : $D_{p2p} = max\{F/u_s, F/d_{min}, \frac{NF}{u_s + \sum_{i=1}^{N} u_i}\}$

Bittorrent

• torrent = 특정 파일의분배에 참여하는 모든 피어의 모임
• tracker = 토렌트의 인프라스트럭쳐 노드. 피어가 토렌트에 참여할 때 트래커에 자신을 등록
• chunk = 피어로부터 다운로드 받는 데이터 단위 (256KB)
  다운로드 하면서 업로드

연결된 피어는 계속해서 달라진다. 초기에 토렌트에 진입한 피어는 여러 피어와 TCP커넥션을 연다. 연결된 피어들을 이웃이라고 한다. 이 중에서 일부 피어는 떠나고 새로운 피어가 연결될 수도 있다. (churn, come and go)

• 청크 요청 : 이웃에게 가장 복사본이 적은 청크를 요청한다.
• 청크 주기 :
  • 가장 빠르게 줄 수 있는 이웃의 4개 피어를 10초마다 고른다. (4개 피어는 unchocked되고, 나머지는 chocked된다.)
  • 30초마다 랜덤하게 한 개 피어를 고르고 여기에도 청크를 준다. (optimistically unchocked)
• 보상 방식 : TFT(Tit-for-tat, 치고받기)

Video streaming

비디오 스트리밍은 heterogeneity문제가 있다. (사용자마다 환경이 다름)
이를 해결하기 위해 분산된 애플리케이션 단의 인프라가 필요하다. (distributed, application-level infrastructure)

비디오

• 비디오 : 단위시간당 일정한 개수의 이미지를 보여준다. (sequence of images displayed at constant rate)
• 이미지 : 픽셀의 배열
• coding : 이미지를 압축하기 위해 이미지 내 중복성(redundancy)을 사용한다.
  • spatial coding (within image) : 모든 픽셀값을 보내는 대신, 특정 한 픽셀의 정보와 반복 횟수를 보낸다. (예시 : rrrrrrrrrrrrrrrrrrrr 대신 r20)
  • temporal coding (from one image to next) : 변화가 있는 프레임만 보낸다.
• bit rate
  • CBR(constant bit rate) : e.g., MPEG1은 1.5Mbps
  • VBR(variable bit rate) : e.b., MPEG4는 64Kbps~12Mbps

Streaming

video server ----- (internet) ----- client

• 문제상황 : 서버-클라이언트 사이의 대역폭은 다양하고 망혼잡도가 계속해서 바뀐다. 따라서 패킷 손실과 딜레이가 발생할 수 있고, 이는 스트리밍 품질의 저하로 이어진다.
  -----> 클라이언트 측에 버퍼를 두고 조금 늦게 재생을 시작한다.

• DASH (dynamic, adaptive streaming over HTTP)

  • 서버
    • 비디오를 청크로 분할. 각 청크를 각기 다른 품질로 인코딩
    • manifest 파일에 각 인코딩 결과의 URL을 저장
  • 클라이언트
    • 주기적으로 서버-클라이언트 사이 대역폭을 체크하고 이 망 상황에 적절한 버전의 청크를 가져옴

• 문제 해결 : 압축, DATH, 재생 버퍼링

CDN

CDN : Content Distribution Network

영상 스트리밍 서버 구성안

• 안1 : 단일 거대서버 구축
  • 문제 : 싱글 포인트 실패, 네트워크 혼잡, 호스트와 먼 거리, 중복된 데이터 전송, 스케일링 불가
• 안2 : ( C D N ) 여러 곳에 클러스터를 두고 복사본을 저장한다.
  • enter deep : 많은 access network안에 둔다.
  • bring home : IXP에 둔다.

CDN

서비스 제공자는 CDN에 복사본을 넣어둔다.
구독자는 빨리 가져올 수 있는 CDN에 서비스를 요청한다. (가까이 있거나, 덜 혼잡하거나)

** OTT : Over the top

CDN 동작과정

다음과 같은 요소가 있다고 하자.

• 클라이언트
• 클라이언트 로컬DNS (로컬 DNS라 하자)
• 서비스 웹페이지 (웹서버 라 하자)
• 서비스 웹페이지 authoritative DNS (웹 DNS라 하자)
• CDN
• CDN authoritative DNS (CDN DNS라 하자)

1. 클라이언트 → 웹서버 : 영상 주셈
2. 웹서버 → 클라이언트 : 저기(영상 주소)로 가셈
3. 클라이언트 → 로컬DNS → 웹 DNS : 이거(영상 주소) 어디냐?
4. 웹 DNS → 로컬DNS : 저기(CDN)로 가셈
5. 로컬DNS → CDN DNS : 이거(CDN) 어디냐?
6. CDN DNS → 로컬DNS → 클라이언트 : 여기(CDN IP)로 가셈
7. 클라이언트 → CDN : 이제 진짜 영상 내놓으셈
8. CDN → 클라이언트 : ㅇㅋ