컴퓨터 네트워크 개론 (2) - Application Layer

 

Application Layer(124)

• The goal of this Lecture
  • Transport-layer service model
  • Client-Server 패러다임
  • Peer-to-peer 패러다임
  • HTTP, SMTP, DNS, CDNS
  • Socket API

Principles of network application

• Creating a network app
  • 서로 다른 end system에서 작동하며 network를 거쳐 communicate할 수 있는 network app
  • network-core devices를 위한 소프트웨어를 만들 필요는 없음
    • network-core devices는 유저 applicaion을 run하지 않음
    • End systmes에 있는 applicaion은 빠른 app 개발과 전파 가능

• Client-Server 구조
  • Server: 항상 켜져 있는 호스트, 고정 IP주소, 주로 데이터 센터로 확장
  • Client: 서버와 통신, 클라이언트간에 직접 통신 X, 유동 IP 가질 수 있음, 항상 연결되어 있진 않고 간헐적으로 통신할 수 있음
  • HTTP, IMAP, FTP

 

• P2P 구조
  • 항상 켜져 있는 서버가 없음
  • 임의의 end system끼리 직접 통신함
  • peers끼리 각각 서비스를 요청하고 제공함.
    • Self Scalability - 새로운 peers는 새로운 service capacity과 service demands를 가져옴
  • Peers는 간헐적으로 연결되고 IP주소가 변경됨 → 관리가 어려움
  • 단점: 보안/퀄리티는 떨어지고 cost는 증가(각 host가 통신할 모든 host 주소를 알고 있어야 함)

 

• Processes communicating
  • Process: 호스트 안에서 돌고 있는 프로그램
  • Host 내에서 두 프로세스는 OS에서 정의한 IPC(Inter-Process-Communication)으로 통신
  • 다른 host 간의 프로세스는 messages를 교환하여 통신
  • Client Process: 통신을 시작하려는 프로세스
  • Server Process: 접속을 기다리는 프로세스(listening)
  • P2P 구조의 applicaion들은 client & Server process 모두 가짐

 

• Socket
  • 프로세스는 소켓을 통해 message를 송수신
  • 프로세스는 집, 소켓은 출입구에 비유
  • Sending process는 수신 socket의 transport infrastructure에 의존
  • 두 개의 소켓이 연관되어 있음(송/수신)

 

• Addressing processes
  • message를 받기 위해서는 process는 반드시 identifier를 가지고 있어야 함
  • Host device는 32-비트의 유일한 IP주소를 가지고 있음
  • Identifier는 특정 process와 연관된 IP주소와 포트 번호를 모두 포함함

• Application-layer 프로토콜
  • 정의하는 것
    • Message type(request, response 등)
    • Message syntax(어떤 filed가 있고 어떻게 구분되는가)
    • Message semantics(각 filed가 어떤 의미안가)
    • 언제 어떻게 프로세스가 message를 주고받을지
  • Open protocol:
    • RFC에 정의되어 있음.
    • 모두가 protocol definition에 접근할 수 있음
    • Interoperability(상호 운용성)
    • HTTP, SMTP
  • Proprietary protocol:
    • Skype, Zoom

• Application이 필요한 transport service

  

  • Data integrity
    • Web transaction이나 File transfer는 100% reliable data transfer 필요
    • Audio와 같은 앱들은 일부 loss는 수용 가능
  • Timing
    • 인터넷 전화나 실시간 게임같은 경우는 low delay가 필요(to be effective)
  • Throughput
    • 멀티미디어 같은 앱의 경우 최소한의 throughput가 필요(to be effective)
    • Elastic apps의 경우 큰 상관 없음
  • Security
    • Encryption, Data integrity 등

 

• Internet transport protocol services
  • TCP
    • 신뢰 가능한 프로토콜
    • Flow Control 가능: receiver가 받을 수 있는 데이터보다 더 많은 양을 보내지 않음
    • Congestion control: 네트워크 내에서 처리가능한 양보다 더 많은 데이터를 보내지 않음(throttle sender when network overloaded)
    • Connection-oriented: client-server 사이에서 무조건 Connection setup이 필요함
    • 제공하지 않는 것: timing, 최소 throughput 보장, 보안
  
  
  • UDP
    • 신뢰 불가능한 프로토콜
    • 제공하지 않는 것: 신뢰도, flow control, congestion control, timing , throughput 보장, security, connection setup
    • 사용하는 이유: 복잡한 기능이 필요 없는 app의 경우 굳이 TCP를 안써도 됨. Performance 이슈(Google, Youtube), Freedom of implementation

  

 

• Securing TCP
  • Vanilla TCP & UDP sockets:
    • 암호화 없음
    • cleartext PW가 노출됨
  • TLS(Transport Layer Security)
    • 암호화된 TCP연결 제공
    • Data integrity
    • End-point authentication

 

Web and HTTP

• HTTP Overview(Hyper Text Transport Protocol)
  • Web’s application-layer protocol
    • 웹 clients가 어떻게 web server로 페이지를 요청하고 web serve가 web client로 어떻게 page를 보내는지에 대해 정의
    • Client: HTTP 프로토콜을 이용하여 page를 요청하고 page를 받아 web object를 보여줌
    • Server: HTTP 프로토콜을 이용하여 요청받은 page를 client에게 보내는 역할
  • HTTP uses TCP
    • Connection oriented로 loss 없이 데이터 전송이 가능하도록 함
    • Port 80번 사용
  • HTTP는 Stateless
    • 서버는 이전 client 요청에 대한 정보를 저장하지 않음
    • Server doesn’t manage the status
    • state를 유지하는 프로토콜은 복잡함

• 두 종류의 HTTP연결
  • Non-Persistent HTTP
    • 하나의 conncection에 대해 하나의 object만 전송됨(여러 object → 여러 Connection 병렬로 연결) ⇒ 전송 이후 TCP 연결이 종료됨
    • HTTP/1.0 사용
    • Connection 수가 늘어나므로 server의 부담이 커짐
  • Persistent HTTP
    • 하나의 TCP 연결에서 다수의 object가 오갈 수 있음
    • Server는 계속해서 연결을 유지할 수 잇음
    • HTTP/1.1에서 default로 persistent connection을 사용함

• Non-Persistent HTTP: Response Time
  • RTT: 작은 패킷이 clinet와 server 사이를 왕복하는 시간
  • HTTP response time(Object 마다):
    • TCP 연결 시작: 1 RTT
    • HTTP Request: 1 RTT & Time transmission 시작
    • Object/Time transmission
    Non-persistent HTTP response time ⇒ 2RTT + file 전송 시간
  • Object 마다 2 RTT 필요
  • 각 TCP 연결마다의 OS overhead
  • 브라우저는 종종 referenced objects를 가져오기 위해 병렬 TCP 연결을 함

 

• Persistent HTTP(HTTP1.1):
  • 서버가 Response보낸 이후에도 Connection을 유지시킴
  • 후속 HTTP message는 open connection을 통해 보내짐
  • Client는 referenced object를 보자마자 requests를 보냄
  • 모든 referenced objects에 대해 RTT 1밖에 안필요함(reponse time 반으로 줄임)

 

• HTTP Request message

  

  • ASCII 포맷

• HTTP REST
  • POST(등록)
    • client에서 server로 information을 보냄
    • 종종 form input 포함
    • user input은 entity body에 담겨져 보내짐
  • GET(조회)
    • 제일 많이 씀
    • user data를 URL filed에 넣어서 보냄(? 뒤에)
    • sending data to server
  • HEAD
    • 헤더만 request함
  • PUT(수정)
    • 새로운 file을 서버에 업로드
    • 완전하게 수정할 수 있음

• HTTP Response message

  

• HTTP Response status code
  • 200 OK
  • 301 Moved Permanently
  • 400 Bad requuest(서버가 이해 못함)
  • 404 Non found(document를 서버에서 찾을 수 없음)
  • 505 HTTP Version Not supported
•  

• User-server State: Cookies
  • 쿠키는 transaction 사이에 some state를 유지하기 위해 사용
  • 쿠키는 과거의 event에 따라 다르게 행동하게 해주기 위해서 사용됨
  • HTTP는 stateless이기 때문에 client에서 오는 요청에 대한 응답을 보낸 뒤에 바로 초기화가 된다. ⇒ client에 대한 정보를 알 수가 없다.
  • Server가 새로운 유저를 파악했을 때 reposnse 데이터에 Set-Cookie header(해당 user를 구분하기 위한 ID)를 설정하여 보냄
  • Client는 Set-Cookie 헤더의 정보를 디스크에 저장하고 동일한 서버에 대한 요청 시 사용
  • Privacy 문제 우려 → 개인 컴퓨터에서만 사용할 것
  
  
  1. 서버에서 HTTP reponse message에 Set-cookie header 설정해서 보냄
  2. Cookie header line in next HTTP request message
  3. Cookie file kept on user’s host, managed by user’s browser
  4. 웹사이트의 백엔드 데이터베이스에 저장(cookie에 대한 entry)

  

  • 쿠키카 쓰이는 곳: Authorization, 쇼핑카트, 추천, user session state

• Web caches
  • Goal: Satisfy client requests without involving origin server
  • user configures browser to point to a Web cache
  • 브라우저는 모든 HTTP 요청을 cache로 보냄
    • object가 cache에 있다면 바로 object를 client에게 반환
    • 없다면 cache에서 server로 요청을 날리고 받아온 뒤 다시 client로 반환
  • Client와 Server 양쪽의 역할을 함
  • Reponse header에 caching 정보를 담을 수 있음
  • Cache 쓰는 이유
    • Response time 감소(client에는 cache가 더 가까움)
    • 트래픽 감소
    • 인터넷은 cache가 매우 많음. Content 제공자들에게 content를 더욱 효과적으로 전달하도록 함

  

 

• Conditional GET
  • 문제: server의 데이터가 변함으로 인해 Cache에 있는 데이터와 다를 때→ cache에 있는 데이터가 구버전이라면 server에서 받아와서 보내야 함
  • 목표: Cache가 최신의 버전 → object를 보내지 말 것
  • 해결법: If-modified-since 헤더 조건에 따라 cache의 값을 받을 것인지 server에서 값을 새롭게 받을 것인지 결정을 한다.→ server에 last modified date(날짜가 기준임)가 있게 되고 그 날짜보다 If-modified-since날짜가 더 옛날이라면(바뀌었다면) cache server의 데이터를 바꾼 후 보낸다.
    → 바뀌지 않았으면 304 Not Modified
  • → 바뀌었다면 200 OK

  

 

• HTTP
  • 주요 목표: multi-object HTTP requests의 delay를 줄이는 것
  • HTTP1.1: single TCP연결에서 multiple, pipelined GETs 개념을 도입
    • server는 FIFO 방식으로 GET requests에 응답함
    • FIFO(FCFS)로는 small object가 large objects 뒤에서 한참 기다려야함⇒ HOL(Head Of Line Blocking)
    L
    oss recovery
    (손실된 TCP 세그먼트 재전송)로 인해
    객체 전송이 중단
    됨
  • 
  • HTTP2: server에서 client에게 objects를 보낼 때 유동성을 강화
    • methods, status code, 대부분 헤더 필드는 안변함
    • 요청된 objects의 전송 순서는 clienct-spcified object 우선순위에 따름(FCFS x)
      • Client가 우선순위를 설정할 수 있음
    • 요청하지 않은 object 또한 보낼 수 있음
      • base HTML + 내부 object들
    • Divide objects into frames, schedule frames → HOL blocking 완화

    

• HTTP/2 to HTTP/3
  • 단일 TCP 연결에서 HTTP/2가 의미하는 것
    • 패킷 손실 복구는 여전히 모든 개체 전송을 지연시킴
    • HTTP 1.1에서와 같이 브라우저는 지연을 줄이고 전체 처리량을 높이기 위해 여러 개의 병렬 TCP연결을 할 수 있음
    • Vanilla TCP 연결에선 no security
  • HTTP/3
    • Security 추가
    • UDP 상에서 object 당 error- and congestion control

DNS(Domain Name System)

• DNS
  • Host name을 IP 주소로 변환하는 디렉터리 서비스
  • DNS 서버들이 계층 구조로 구현된 분산 Database → 확장성, 유지가 간편
  • Host가 분산 DB로 질의하여 host name에서 IP 주소를 획득하는 APP 계층 프로토콜
  • core internet function, implemented as app-layer protocol
  • 코어는 단순하게, 엣지는 복잡하게(성능 향상을 위해)
  • DNS Service
    • Host aliasing: 간단한 별칭 host name을 복잡한 정식 host name으로 변환
    • mail server aliasing
    • 부하 분산: 여러 IP 주소들이 하나의 정식 host name과 연관되는 replicated web server
      • 중복 웹서버에서는 서버들이 부하 분산
  • 단일 중앙 집중 방식 DNS를 사용하지 않은 이유
    • 서버 고장시 전체가 작동하지 않음
    • Traffic volume
    • 유지 관리
    • 먼 거리의 중앙 집중 데이터베이스

 

• DNS: a distributed hierarchical database

  

• Root DNS server:
  • namer server의 contact-of-last-reosrt(최후의 연락 수단, 아무 것도 모를 때 접근한느 최상위 서버), cannot reslove name
  • Server farm 형식으로 총 13개의 root server가 전세계에 존재함(각 서버는 복제된 서버의 cluster)
    • 각 서버는 수 차례 복제되어 cluster 형식으로 존재
  • ICANN(Internet Corporation for Assigned Names and Numbers)가 관리함

 

 

• TLD(Top-Level Domain) Server
  • .com, .org, .net과 같은 top-levle 도메인
  • 국가 도메인 .kr, .cn

• Authoritative DNS Server
  • 조직이나 서비스 제공자가 관리함
  • 각 조직의 DNS 서버로 각각의 조직에 맞는 IP를 mapping해주는 역할

• Local DNS Name Server
  • host가 DNS 쿼리를 날리면 그 쿼리는 일단 local DNS server에 보내짐
  • local cache에 있으면 반환하고 없으면 계층적 DNS 구조로 쿼리를 보냄
  • 계층적 구조에 속하지 않음
  • 각각의 ISP는 local DNS name server를 가지고 있음

 

 

• DNS name resolution
  • Iterated query
    • 연결된 서버가 새로 연결할 서버의 이름을 알려줌

    

  • Recursive query

    

    • 연결된 name server로 name resolution 책임을 넘김
    • 상위 계층 DNS server에 많은 부담이 가게 됨

• Caching and update DNS information
  • name server가 mapping하는 것을 학습하면 캐싱을 하고 곧바로 cached된 mapping으로 응답함
  • cache를 사용하면 reponse time을 향상시킴
  • TTL(Time to live)이 지나면 cache는 timeout(사라짐)
  • Local name server에 보통 TLD server가 캐시되어 있음
  • 캐시 entries는 out-of-date가 될 수 도 있음 ⇒ 기존 TTL이 expire해야 확인 가능
  • ‘best-effort name-to-address translation’ (보장 x)

• DNS Records
  • Distributed database storing resource records(RR)
  • RR format: (name, value, type, ttl)
•  

Video streaming and content distribution networks

• Video Streaming and CDNs: context
  • 요즘 Internet 대역폭의 대부분은 비디오에 의해 사용됨
  • Netflix, Youtube, Amazon Prime: residential ISP traffic 80%
  • Challenge: Heterogeneity(이질성)
    • Different users have different capabilities
  • Solution: 분산형 앱-level Infrastructure

 

• Multimedia: Video
  • VIdeo: 일정한 속도로 보여지는 이미지의 sequence
  • 많은 pixel들을 계속 표현하기에는 데이터가 많이 소모 → 필요한 부분만 새로이 전송
  • 시공간적으로 근처의 bits 확인 → Redundancy(중복성) 이용
  • Encoding 방식
    • CBR(Constant Bit Rate): encoding rate가 고정
    • VBR(Variable Bit Rate): encoding rate가 가변
  • MPEG4(제일 흔하게 사용, 64kbps-12Mbps)

 

• Streaming multimedia: challenges
  • Continuous playout constraint: client가 비디오를 시청하는 동안 playout timing이 original timing과 맞아야함
    • 하지만 network delay는 network congestion level에 따라 가변적이기 때문에(jitter), client-side buffer를 두어 continuous playout constraint를 match한다.

  

  • Client-side buffering and playout delay: network-added delay에 대한 보상, delay jitter(jitter: delay의 변화량)

 

• Streaming multimedia: DASH
  • Dynamic, Adaptive Streaming over HTTP
  • Client가 bandwidth를 측정하고 chunk 파일을 요구하는 방식, client에게 부담을 줌
  • Server
    • video 파일을 chunk로 나누어 저장함
    • 각각의 chunk는 서로 다른 rate로 encode되어 저장(한 chunk에 여러 종류의 rate)
    • files replicated(모방) in various CDN nodes
    • manifest file: chunks에 대한 URL 제공
      • 파일 각각의 encoding rate와 url이 기록되어 있음
  • Client
    • Manifest file을 가장 먼저 요청함
    • 지속적으로 server-client 사이의 bandwidth 측정
    • manifest 파일을 보고 해당 url로 chunk를 요청함
    • 현재 주어진 bandwidth를 보고 지속가능한 최대의 coding rate를 선택
    • 시간에 따라 다른 coding rate의 chunk file을 받을 수 있음(각 시간마다 적절한 bandwidth에 따름)
  • ‘intelligence’ at client: 클라이언트가 결정함
    • 언제 chunk를 요청할지
    • 어떤 encoding rate를 요청할지
    • 어디에 chunk를 요청할지
  • Streaming video = encoding + DASH + playout buffering

• CDN(Content Distribution Networks): 동시에 여러 명의 유저가 비디오를 요청 시 어떻게 대응을 할 것인가에 대한 해결책
  • Enter deep: 서버를 세계 곳곳에 있는 네트워크에 접속시키는 형식
    • 유저와 가까움
    • 수많은 작은 서버들을 연결시키는 방식
  • Bring home: 적은 수의 large clusters를 ISP 근처에 세우고 네트워크에 접속시킴
  • 구독자가 content를 요청하면 service provider는 manifest를 반환함
    • manifest를 이용하여 client는 가능한 가장 빠른 rate로 content를 검색함
    • 가장 가까운 곳에서 해당 파일을 받지만, 너무 많은 traffic이 있다면 그 다음으로 가장 가까운 곳에 요청을 함
    • network path가 혼잡하면 다른 rate나 copy를 선택할 수도 있음
• → 지역적으로 분산된 서버에 여러 개의 복사된 비디오들을 저장해 두는 것

 

• OTT(Over The Top): 인터넷을 통해 각종 미디어 콘텐츠를 제공하는 서비스
  • OTT challenges: coping with a congested Internet from the ‘edge’
    • 어떤 CDN node에 어떤 content를 둘지
    • 어떤 CDN node에서 content를 어떤 rate로 검색할지

 

Socket Programming with UDP and TCP

• Socket programming
  • Socket: Application 프로세스와 end-end-transport protocol사이의 door
  Goal: socket을 이용하여 client-server application을 만드는 방법을 배우는 것
  • Two socket types
    • UDP: unreliable datagram
    • TCP: reliable, byte stream-oriented

 

• Socket Programming with UDP
  • UDP: client와 server 사이에 no connection
    • no handshaking
    • 송신자가 수신자의 정보를 명시해줘야 함
    • 수신자는 받은 패킷에서 송신자의 IP주소와 포트 넘버를 추출해냄
  • UDP: 전송된 데이터가 없어지거나 순서가 어긋날 수 있음Applicaion viewpoint:
    • UDP는 client-server process 사이에 datagram에 대한 unreliable transfer를 제공함

• Socket Programming with TCP
  • Client는 반드시 server와 contact해야 함
    • Server process는 반드시 먼저 동작하고 있어야 함
    • Server는 반드시 socket을 미리 만들어 놨어야 함
  • Client contacts server by:
    • TCP socket 생성, IP 주소와 포트 번호 명시
    • client가 socket을 만들면 client TCP가 server TCP와 연결을 수행
  • Client와 연결되면 server TCP는 새로운 socket을 생성함
    • 그 특정한 client와 통신하기 위해 해당 server process에 생성하는 것임
    • Server가 다수의 clients와 통신할 수 있게 해줌
    • source port number는 client를 구분할 수 있게 해줌
  • Application viewpoint
    • TCP는 클-섭 사이에 reliable하고 in-order byte-stream transfer(pipe) 제공

 

 

Application Layer.pdf

1.50MB