[Network] Top Down Approach 2장: Application Layer
CS/Network

[Network] Top Down Approach 2장: Application Layer

Application Layer

Application Layer는 서로 다른 Host의 application이 서로의 message(data packet)을 교환하는데 사용됨

ex) HTTP, SMTP, FPT


Principles of network applications

Application Architectures (가능한 application 구조)

  1. Client - Server 구조: 서버와 클라이언트 간 통신
    • Server
      • 항상 연결되어 있어야 한다. always-on
      • 영구적인 IP 주소를 가진다.
      • 규모에 따라 바뀌는 데이터 센터를 가진다.
    • Client
      • 서버를 통해서만 소통한다.
      • 가끔 연결된다. <-> always-on
      • 유동적인 IP 주소를 갖는다.
  2. Peer to Peer (P2P) 구조: 호스트끼리 직접 통신하는 것
    • 사용자가 모두 peer인 구조이며 peer가 서버, 클라이언트의 역할을 모두 한다.
    • 항상 켜져 있을 필요가 없다.
    • 소통시 무작위로 연결된다.
    • self-scalability(자가 확장성)을 가진다. (새로운 peer가 새로운 서비스 용량을 증가시킨다.)
    • IP가 바뀔 수 있다.

Process Communicating

  • Process: 호스트내에서 어플리케이션 레이어를 작동시키는 것. 즉, 실행되는 프로그램
  • Client Process: 클라이언트의 프로세스로 주로 서버에 무언가를 요청하는 것
  • Server Process: 서버 내의 프로세스로 주로 클라이언트의 요청을 기다리는 것
  • P2P 프로세스는 둘의 역할을 같이 한다.
  • 프로세스는 같은 호스트 내에서 통신할 수도 있고(inter-process communication) 각각 서로 다른 호스트 내부의 프로세스에서 메시지를 주고 받을 수도 있다. -> 서로 다른 프로세스끼리 데이터 전달을 위해 Socket을 이용함

Socket

  • 프로세스는 각자의 socket을 통해 메시지를 발신 및 수신한다.

Addressing Processes

  • 메시지를 받기 위해선 프로세스는 반드시 각자의 id를 가지고 있어야 한다. IP 주소와 포트 번호가 이 역할을 한다.
  • IP: 호스트 디바이스가 갖는 32비트짜리 주소. 같은 호스트 내에서 동작하면 IP 주소가 같다.
  • Port 번호: 데이터를 받을 프로세스를 식별하게 해주는 역할. 16비트 정수. 보통 HTTP 서버는 80번, 메일은 25번

Application Layer Protocol

  • Application Layer Protocol은 다음과 같은 정보들을 담고 있다.
    • 메시지의 타입 (요청, 응답)
    • 문법 (메시지 안에 어떤 필드가 있는지)
    • 메시지의 의미 (출발 및 도착지 ip, 포트 번호) 등등...
  • Application Layer가 기대하는 Transport Layer의 역할: 둘은 서로 붙어있고 상호작용 한다. 따라서 Application Layer가 기대하는 Transport Layer의 역할은 다음과 같다.
    • Data integrity 데이터 보전: 데이터의 손실 없이 전송
    • Timing 타이밍: 적은 딜레이로 주고받길 원함
    • Throughput 처리량: 전송량
    • Security 보안-> 이 4가지는 다른 계층에서도 꾸준히 등장하기 때문에 중요. 모든 application이 이 4가지를 완전히 만족시키지는 못하기 때문에 확실히 필요한 것과 아닌것을 설정해야함
  • Internet transport protocols services
    1. TCP (Transmission control protocol)
      • 신뢰적인 전송을 추구
      • Flow control: 발신자는 수신자를 넘어서지 않는다.
      • Congestion control: 네트워크가 overload되면 발신을 조절한다.
      • 타이밍, 처리량, 보안을 제공하지 않음
      • 서버 - 클라이언트 간 연결 설정 단계를 거침
    2. UDP (User datagram protocol)
      • 비신뢰적인 전송을 추구
      • 시간, 처리량, 보안, 신뢰적 전송 모두를 안해준다.
      • 오직 데이터를 빠르게 보내는 것에 초점을 맞춘다. (real-time streaming)
    3. Securing TCP
      • TCP와 UDP는 암호화를 제공하지 않기 때문에 보안적으로 TCP를 강화한 SSL을 개발
      • SSL (Secure Sockets Layer): SSL로 강화된 TCP는 TCP의 일 + 암호화, 데이터 무결성, 종단 인증을 포한하는 프로세스 보안 서비스를 제공
      • SSL은 어플리케이션 계층에서 구현된 것으로서 SSL 서비스를 이용하고자 한다면 인증키를 가지고 해독하여야한다. 

Web and HTTP

HTTP (HyperText Transfer Protocol)

  • 웹의 어플리케이션 계층 프로토콜
  • HTTP는 클라이언트 프로그램과 서버 프로그램으로 구현된다.
  • TCP를 전송프로토콜로 사용한다.
  • Stateless: 서버는 이전 클라이언트의 요청에 대한 정보를 기록하지 않고 단지 요청이 오면 보내기만 함

HTTP Connection 종류

TCP 연결의 지속적 사용 여부에 따라 분류

  1. Non-persistent HTTP
    • 초기의 HTTP로 현재는 사용하지 않음
    • 객체를 가져올 때마다 연결 설정을 다시 해야하기 때문 -> 비효율적
    • TCP를 통해 메시지를 주고 받은 뒤에 TCP 연결을 끊음
  2. Persistent HTTP
    • TCP를 통해서 메시지를 주고 받은 뒤에 TCP연결을 유지 한다 -> 효율적

HTTP 메시지

  • 요청 메시지
    • Request line: HTTP 메서드 + 주소 + HTTP 버전
      1. GET
      2. POST
      3. HEAD commands
      4. PUT
      5. DELETE
    • Header: 요청 정보
      1. User-Agent: 사용자 웹 브라우저 종류 및 버전 정보
      2. Accept: 웹 서버로부터 수신되는 데이터 중 웹 브라우저가 처리할 수 있는 데이터 타입
      3. Cookie: 사용자 정보를 기억하기 위한 값
      4. Referer: 현재 페이지 접속 전에 어느 사이트를 경유 했는지 알려주는 URL
      5. Host: 사용자가 요청한 도메인 정보
    • Body: HTTP의 페이로드
  • 응답 메시지
    • Status line: HTTP 버전 + 상태 코드(200, 404...) + Reason-phrase
    • Header: 응답 정보
      1. Date
      2. Server
      3. Content-type
      4. etc..
    • Body

User-server state: Cookies

  • Cookie: 사용자에 따라 적절한 콘텐츠를 제공하기 위해 쿠키를 사용
  • HTTP의 Stateless를 보완하기 위한 방법
  • 인증, 장바구니, 추천시스템 등에서 사용
  • 구성 요소 4가지
    1. HTTP 응답 메시지 쿠키 헤더 라인
    2. HTTP 요청 메시지 쿠키 헤더 라인
    3. 사용자와 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
    4. 웹 사이트의 백엔드 데이터베이스

Web Caches (Proxy Server)

  • Web Caches: origin server를 대신하여 HTTP 요구를 충족시키는 네트워크 개체. 사용자가 웹 사이트에 접속할 때 정적 컨텐츠를 특정 위치에 저장하여 매번 요청해서 받는게 아닌 그 위치에서 불러옴으로써 응답시간을 줄이고 서버 트래픽 감소 효과를 보는 것
  • Web Cache는 Proxy Server가 될 수 있다.
  • Reverse Proxy Server: 다양한 공격으로부터 방어할 수 있음

조건부 GET

  • Web caching이 야기하는 "캐시 내부의 복사본이 새것이 아닐 수도 있다"는 문제를 해결해주는 방식이다.
  • 조건부 GET은 HTTP가 객체의 갱신 상태를 확인하면서 캐싱하도록 해주는 방식을 말한다.
  • 위의 이미지를 보면 HTTP 요청할 때 if-modified-since: <date>를 통해 갱신 상태를 확인한다.

Electronic mail - SMTP, POP3, IMAP

FTP (File Transfer Protocol)

  • FTP: 파일 전송 프로토콜이며 TCP 프로토콜을 가지고 서버와 클라이언트 사이의 파일 전송을 하기 위한 프로토콜
  • 제어와 데이터 연결의 분리성 -> Out of Band 특성
    • FTP의 중요한 특징중 하나는 포트를 2개 쓴다는 것
    • 하나는 제어(control) 용도로, 새로운 클라이언트가 올 때만 집중적으로 관리하기 위한 포트이며 21번을 사용
    • 하나는 데이터 연결 포트로, 데이터를 주고받을 때만 사용하는 포트로 20번을 사용

E-mail (Electronic mail)

  • 3가지 구성 요소
    1. User agent
      • 사용자가 메시지를 읽고, 응답하고, 저장하고, 구성하게 해줌
    2. Mail server
      • 각 수신자는 메일 서버 안에 메일 박스를 가지고 있음
      • 만약 메시지 전송량이 초과하는 경우 메시지를 메시지 큐에 보관
      • SMTP 프로토콜을 통해 메시지 전송
    3. SMTP(Simple Mail Transfer Protocol)
      • 신뢰적 데이터 전송을 위해 TCP를 사용
      • 전송의 3단계 - handshaking, transfer, closure
      • 명령시 아스키코드, 응답시 상태 코드
      • 메시지는 반드시 7비트짜리 아스키 코드로 이루어져있어야 함
  • 시나리오
  • HTTP vs SMTP
HTTP SMTP
pull push
제한x 메시지가 7bit 아스키 포맷
객체에 캡슐화 방식 포트를 따로 하여 한 메시지로 만듬
  • 메일 메시지 포맷
    • Header와 Body로 구성
    • Header: From, To, Subject가 반드시 있어야함
    • Body: 메시지(아스키 문자)
  • 메일 접속 프로토콜
    • SMTP는 하나의 호스트에서 다른 쪽으로 전자메일을 보내기 위해 설계 -> push 프로토콜임.
    • 하지만 메시지를 얻는 pull 동작을 수행해야 하는데 이를 POP3, IMAP, HTTP(웹메일)과 같은 유명한 메일 접속 프로토콜을 사용해서 수행하게 된다.

DNS

DNS (Domain Name Server)

  • 도메인을 IP로 바꾸어 주는 디렉터리 서비스
  • DNS는 32bit 크기의 IP address를 저장하고 제공함으로써 distributed DB의 속성을 가짐
  • 네임 서버들의 계층구조로 구현된 분산 데이터베이스
  • Application Layer Protocol 중 하나

DNS가 제공하는 서비스들

  • 호스트 네임 -> IP 주소
  • 호스트 aliasing: 정식 호스트네임 외로 사본 또는 별칭을 가질 수 있음
  • 메일 서버 aliasing
  • 부하 분산: 인기 있는 사이트는 여러 서버에 중복되어 있어서 다른 IP 주소를 할당시켜 부하를 분배시킴

DNS의 계층 구조

  • 3단계 구조
    1. 루트 DNS 서버
    2. 최상위 레벨 도메인(TLD) 서버: com, org, net, edu 등 기업, 기관, 대학, 나라를 대표하는 도메인 서버
    3. 책임 DNS 서버: 기관이 실질적으로 DNS 서버를 가지고 있는 곳으로 정확한 이름의 IP 주소가 매핑된 곳. 그 주소로 접근할 권한을 가져 권한 서버라고도 함
  • www.naver.com의 IP 주소를 찾는 과정
    1. 먼저 루트 서버 중 하나에 접속한다.
    2. 루트 서버는 메인 com을 갖는 TLD 서버 IP 주소를 보낸다.
    3. 이후 우리는 TLD 서버 중 하나에 접속하고, 서버는 도메인 naver.com이 가진 책임 서버의 IP 주소를 보낸다.
    4. 우리는 책임 서버 중 하나로 접속하고, 서버는 www.naver.com IP 주소를 보낸다.

P2P applications

P2P

  • 위에서 언급한 통신망의 한 종류
  • 특징
    • 항상 서버가 켜져잇지 않다.
    • End system(peer)끼리 직접적으로 소통을 한다.
    • peer의 IP주소는 바뀔 수 있다.
    • 주로 대용량 파일을 공유할 때 쓰인다.
    • 한 파일에 대한 청크들이 각 피어들에 나뉘어져 있어서, 다운로드할 때 현재 가지고 있지 않은 청크들을 각 피어들에게 요청해 동시에 받게 된다. 이게 P2P의 가장 큰 장점이다.
  • 과정
    1. 서버는 토렌트에 참가한 피어들을 추적하고 피어들의 리스트를 만듬
    2. 유저 pc는 서버에게 각 피어들의 청크 리스트를 받음
    3. 유저는 피어들에게 요청을 하고, 각 피어들은 그룹을 이뤄 청크들을 주고 받음
  • 용어
    • Rarest first: 가장 희소성 있는 청크를 먼저 받아 공유
    • Peer churn: 피어들은 임의로 탈퇴하거나 가입할 수 있음
    • Selfishly, Altruistically: 이기적, 이타적
    • Tit-for-tat: 청크를 보낼 때 쓰이는 용어로, 주고받는 과정에서 전송률 높은 top4 선정해서 이런 이기적 피어를 이타적 피어들로 교체해 높은 업로드 속도를 유지하는 방식

Video streaming and content distribution networks

Video Streaming

  • 대표적인 Network Application
  • 방송, 스트리밍, VOD 등은 수많은 유저를 어떻게 관리할까?
  • 영상은 이미지의 연속이라고 볼 수 있는데 이런 이미지들을 공간적, 시간적 방법으로 압축시킬 수 있다.
    • 공간적 방법: 사진 사진마다 잘게 나누어 전송, JPEG 방식 사용
    • 시간적 방법: 바뀐 부분에 한하여 사진을 여러 개의 프레임으로 나누어 전송, MPEG 방식
  • DASH (Dynamic Adaptive Streaming over HTTP)
    • HTTP 기반의 스트리밍
    • 기존의 HTTP 스트리밍은 클라이언트의 대역폭이 각자 다르더라고 똑같은 인코딩 된 영상을 보냈음
    • 이런 문제점을 해결하기 위해 DASH에서는 영상들을 여러 가지 다른 버전으로 인코딩하여 보냄

CDN (Content Distribution Network)

  • 수많은 유저들과 수 많은 콘텐츠들 속에서 빠르게 전송하기 위한 방법
  • Access network 안에 많은 CDN 서버를 심어놓아 유저들의 요청에 맞는 캐시가 있으면 바로 주는 방식
  • 클라이언트는 파일을 받을 때 가장 가까운 CDN을 택함. 단, 그 CDN에 파일이 없거나 혼잡이 심하면 다른 CDN 선택

 

 

 

참고

https://suhwanc.tistory.com/102?category=781986

 

728x90
반응형