Chapter 2 : Application Layer

Principles of network applications

creating a network app

• end systems에서 실행
• network 넘어 통신
• network-core devices와 관련해서까지 코딩할 필요 없음

Client-server paradigm

server

• host에 항상 있음
• 영구적인 IP address
• data center에 존재

clients

• server와 통신
• 간헐적으로 연결됨
• 동적 IP 주소를 가짐
• 직접적으로 client끼리 연결하지 않음
• ex. HTTP, IMAP, FTP

Peer-peer architecture

• 서버가 항상 켜져있지 않음
• end systems 끼리 직접적으로 통신함
• peer는 간헐적으로 연결되고 IP를 바꿈
• 자기 확장성을 가짐
• ex. P2P file sharing

Processes communicating

process: host 내부에서 실행되고 있는 program

• 같은 host내에서 두개의 process가 inter-process communication을 이용해서 통신한다
• 다른 host에서 message를 교환하며 통신한다
• client process: 통신을 초기화하는 프로세스
• server process: 연결되기를 기다리는 프로세스
• P2P 구조에서도 클라이언트 프로세스와 서버 프로세스가 존재한다.

Sockets

process는 message를 socket으로부터 주고 받는다.( socket은 door이다.)

• sending process는 message를 바깥으로 민다.
• sending process는 message를 receiving process로 보내기 위해 문 반대쪽의 transport 시설에 의존한다.

Addressing process

• message를 받기 위해 process는 identifier(IP address + port numbers)를 가져야 한다.
• host는 각각 32-bit IP address를 가짐
• process를 식별하는데 host IP로만 충분한가? => 많은 프로세스가 하나의 host에서 실행되기 때문에 충분하지 않다. 

App에 필요한 transport service

• data integrity: data가 보장되어야 하는 서비스도 있고 그렇지 않은 서비스도 있다.
• timing: low delay가 필요한 app이 있다.
• throughput: minimum amount of throughput이 보장되어야 하는 app이 있다. 이와 반대되는 app을 elastic app이라 함
• security

transport protocols services : TCP/UDP

TCP service

• reliable transport
• flow control
• congestion control
• timing, minimum throughput guarantee, security는 보장해주지 않음
• connection-oriented: client / server process 간 연결이 필요하다.

UDP service

• unreliable data transfer
• reliability, flow control, congestion control, timing, throughput guarantee 보장하지 않음 => 제공하는게 없음

Web and HTTP

web

• web page: objects(HTML, JPEG, Java,audio file)로 이루어짐
• URL로 접근가능하다.

HTTP overview

• web의 application layer protocol
• client/server model:
  • client: web object를 요청하고 받고 display하는 browser
  • server: 요청에 대한 응답으로 object를 보내주는 web server
• HTTP uses TCP
  • client가 TCP connection(creates socket) to server를 초기화한다.
  • server가 TCP connection을 client로부터 수락한다.
  • HTTP client와 server가 HTTP message(application layer protocol)를 교환한다.
  • TCP connection 종료
• HTTP is "stateless"
  • 서버가 이전 request 정보를 저장하지 않는다.
• Non-persistent HTTP
  • TCP opened => one object sent over TCP connection => TCP connection closed
• Persistent HTTP
  • TCP connection opened to a server => single TCP connection 에서 많은 객체를 보낼 수 있다. => TCP connection closed

Cookies: maintaining user/server state

HTTP GET/response interaction is stateless => cookie를 통해 transaction간의 state를 유지한다.

1. 웹 서버에 HTTP 요청 메시지 전달
2. 웹 서버는 식별 변호를 만들고 식별 번호로 인덱싱되는 벡엔드 DB안에 엔트리를 만듬
3. HTTP 응답에 식별번호의 헤더 포함해서 전달
4. 브라우저는 헤더를 보고, 관리하는 특정한 쿠키 파일에 그 라인을 덧붙임
5. 동일 웹 서버에 요청을 보낼 때 식별번호와 함께 요청을 함께 보냄

Web caches

cache: 기점 웹 서버를 대신하여 HTTP 요구를 충족시키는 개체
HTTP requests to cache => object가 있다면 반환해줌 or 없다면 origin server에 요청하고 cache가 object를 받고 client한테 반환해줌

• web cache 는 client 와 server 모두 가능 (client에 대한 서버, origin server에 대한 client)
• 장점
  • response time의 감소 (cache는 closer to client)
  • reduce traffic

E-mail, SMTP, IMAP

E-mail

major components

• user agents
  • mail reader
  • composing, editing, reading mail messages
• mail servers
  • mailbox: user에게 오는 message를 보관
  • message queue: 나가는 message들의 queue
  • SMTP protocol: between mail servers
• simple mail transfer protocol: SMTP
  • application 계층 프로토골
  • 메일 전송하는데 TCP의 신뢰적 데이터 전송 서비스 이용
  • 메일 송신할 때는 client/ 수신할 때는 서버가 됨

메일 송수신 과정

• 메일 서버를 거친 후 수신자의 메일 서버로 전달
• 수신자의 메일 박스에 저장
• 메일 서버로 전달이 불가능 할 경우 메시지 큐에 보관하고 일정 시간 주기마다 다시 전송 시도

Mail access protocols

• IMAP이나 HTTP를 사용하여 메일 서버에 있는 것을 user agent로 가져온다.

The Domain Name System (DNS)

호스트 식별자 중 하나는 호스트 이름임 => 근데 컴퓨터가 처리 불가능함 => IP 주소로 식별됨

• DNS 서버들의 계층구조로 구현된 분산 데이터 베이스
  
  • 예시: www.amazon.com의 IP 주소를 찾아보자
  • root => .com DNS server => amazon.com DNS server => IP address for www.amazon.com 
• 호스트가 분산 데이터 베이스로 질의하도록 허락하는 에플리케이션 계층 프로토콜
  • 중앙 집중 데이터베이스라면? => 서버 고장시 전체 인터넷 고장, 트래픽 양 과부하, 먼거리일때 문제, 유지 관리

계층 DNS 서버의 종류

Root DNS 서버

• 1000개 이상의 루트 서버 인스턴스가 세계에 흩어져 있다.
• 루트 네임 서버는 TLD 서버의 IP 주소들을 제공

TLD servers

• .com , .org, .net 같은 상위 레벨 도메인에 대한 TLD 서버가 있다.
• 책임 DNS 서버에 대한 IP주소 제공

Authoritative DNS servers

• 인터넷에서 접근하기 쉬운 호스트를 가진 모든 기관은 호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 레코드를 제공해야 한다.

Local DNS name servers

• 서버들의 계층 구조에 엄격하게 속하진 않음
• ISP는 로컬 DNS 서버를 갖고, 로컬 DNS 서버로부터 IP 주소를 호스트에게 제공한다.
• 대체로 호스트에 가까이 있기 때문에 지연이 적다

DNS name resolution: iterated query

1. 자신의 로컬 DNS 서버에 질의를 보낸다. 이때 변환하고 싶은 호스트의 이름을 같이 보낸다.
2. 로컬 DNS 서버 => 루트 DNS 서버
3. 루트 DNS 서버는 edu를 인식하고 edu에 책임을 가진 TLD 서버의 IP 주소 목록을 로컬 DNS 서버에 보낸다.
4. 로컬 DNS => TLD 서버
5. TLD 서버는 umass.edu를 인식하고 dns.umass.edu로 이름 지어진 책임 DNS 서버의 IP 주소로 응답한다.
6. 로컬 DNS 서버는 책임 DNS 서버로 질의 메시지를 다시 보낸다.
7. 최종 gaia.cs.umass.edu IP 주소를 응답하고 host에게 알려준다.

DNS name resolution: recursive query

• 높은 계층에 있는 DNS server가 책임져야 하는 것이 많다.
• 중요한 infra를 지키는 것이 중요해 root name server보단 default name server가 일을 더 하는 것이 좋다.

P2P applications

architecture

• 서버가 항상 켜져있는건 아니다.
• end system끼리 직접 소통함
• peer 끼리 서비스를 요청하고 제공받는다.
• peer는 간헐적으로 연결되고 IP 주소를 바꾼다.
• ex. P2P file sharing (BitTorrent)

P2P file distribution: BitTorrent

• 256kb chunks로 분할되어 있다.
• peer는 file chunk를 주고 받는다.
• 가장 드문 chunk부터 받고 재분배를 통해 복사본수를 맞춘다.
•  가장 빠른 속도로 데이터를 보내는 peer에게 chunk를 보낸다.

Video streaming and content distribution networks

video

• 일정한 속도로 일련의 이미지를 보여주는 것
• coding: 영상 암호화에 사용되는 bit를 줄이기 위해 이미지 사이의 잉여를 사용

Streaming stored video

• server2client bandwith 가 시간에 따라 계속다르다. => poor video quality
• continuous playout constraint
• client-side buffering and playout delay

Streaming multimedia: DASH

server

• multiple chunks로 video file을 나눈다.
• 각 chunk 는 다른 rate로 인코딩된다

client

• server2client간의 bandwidth를 측정하고 시간당 one chunk를 요청한다. => bandwidth가 클때는 높은 전송률을 택한다.
• 언제 요청할 건지, encoding rate는 어떻게 할건지, 어디로 요청할건지

Content distributions networks (CDNs)

어떻게 존나 많은 사람들에게 content를 제공할것인가?

1. 하나의 존나 큰 mega-server를 만들자! => 확장성이 ㅄ임
2. 비디오 복제본을 분산해서 저장하고 서비스하자

enter deep: CDN server를 많은 access network에 두자 => close to users
bring home: 적은 수의 핵심 지점에 서버 클러스터를 구축하여 ISP를 Home으로 가져오자 => enter deep보단 throughput과 delay측면에선 손해이지만 회사입장에서는 유지보수하기 편하다.

CDN 동작

1. 사용자가 URL을 입력한다.
2. 사용자의 호스트는 URL의 host name에 대한 질의를 로컬 DNS로 보낸다.
3. 로컬 DNS는 host name의 책임 DNS 서버로 질의를 전달함
4. 로컬 DNS는 CDN 서버의 책임 DNS로 질의를 보내고, CDN 콘텐츠 서버의 IP주소를 로컬 DNS 서버로 응답한다. 이때 클라이언트가 콘텐츠를 전송받을 서버가 결정됨
5. 로컬 DNS 서버는 사용자 호스트에게 CDN 서버 IP 주소를 알려준다. 
6. 클라이언트는 호스트가 알게된 IP 주소로 HTTP 혹은 DASH 프로토콜을 통해 비디오를 받아온다.