[Network] 1. Application Layer

신명철·2022년 6월 18일
network
0

네트워크

목록 보기
14/17

client-server architecture

  • server
    • always-on server
    • 영구적인 IP를 가짐
    • data가 군집되어 있는 center
  • client
    • server와 소통, 서로 직접적으로 소통하지 않음
    • 동적으로 IP를 할당받음

    P2P architecture

  • always-on server는 존재하지 않음
  • peer-peer간 소통함
  • self scalability의 특징을 가짐 => service에 peer가 증가하면 자가확장적인 특성을 띔
  • peer의 IP는 동적으로 할당되기 때문에 관리가 매우 복잡함

processes communicating

  • 같은 host 내의 process는 IPC를 통해 소통
  • 다른 host 내의 process는 message 교환을 통해 소통
    • peer to peer, client to server 의 소통은 사실 process 간의 소통임
    • server process: 소통을 대기하는 process
    • client process: 소통을 시작하는 process

Socket

  • socket은 문으로 비유할 수 있음
  • process는 socket을 통해 message를 보내고/받음

addressing process

  • host 간의 소통은 process 간의 소통임. 따라서 host별로, process별로 서로 식별하는 값이 필요함
  • host는 IP라는 32bit의 고유한 주소를 가지게 되고, process는 port number라는 고유한 주소를 가지게 됨
  • e.g) HTTP server의 port#는 80, mail server는 25임
  • e.g) 128.119.254.12:80

app이 필요로 하는 transport service 의 종류

1. data integrity

  • file transfer, web transactions 같은 app들은 100% 안정적인 data transfer을 필요로 함
  • audio 같은 app은 어느정도의 loss를 감안함

2. timing

  • internet telephony, interactive games 는 낮은 delay를 필요로 함

3. throughput

  • multimedia 같은 app들은 최소한의 throughput을 보장받길 원함

4. security

  • encrpytion, data intergrity, ...

=> app이 필요로 하는 transport service에 따라서 TCP or UDP를 결정하게 됨

app-layer에서 정의하는 것들

  • types of messages exchanged
    • e.g) request, response
  • message syntax
    • message에 어떤 field가 있고, 어떻게 표시되어야 하냐
  • message semantics
    • field 값의 의미
  • 언제 어떻게 보내고 받아야 하냐
  • app-layer protocol에는 두가지 종류가 있음
    • open protocols
      • internet protocol의 표준을 나타내는 RFC에 공개되어 있는 protocols
      • e.g) HTTP, SMTP
    • proprietary protocols
      • e.g) Skype

WEB

HTTP

  • web page는 HTML 파일로 이루어져 있고, HTML 파일들은 object들의 reference(URL)를 담고 있음
  • server-clinet 모델로 이루어져 있음
  • TCP 방식을 이용함
    • HTML file을 주고 받기 전에 handshaking이 이루어짐
  • stateless 하게 동작함
    • 이전의 동작 결과를 기억하지 않음

non-persistnet HTTP (= 1.0 HTTP)

  • 한번의 connection에 하나의 object만을 보냄
  • multiple objects를 다운로드하기 위해선 multiple connections이 필요함
  • TCP connection이 맺어졌다는 것은 두 process 간에 socket이 만들어졌다는 것을 의미함
    • 이렇게 만들어진 socket을 통해서 object를 주고/받게 됨

response time

  • user가 요청을 시작하고 file을 응답받을 때까지 걸린 시간
  • RTT(Round Trip Time): 작은 패킷이 clinet에서 출발해서 다시 돌아오는데 걸린 시간
  • non-persistent HTTP response time = 2RTT + file transmission time
  • 하나의 object마다 2RTT가 필요함 => 너무 오래 걸려서 브라우저가 TCP 연결을 병렬적으로 연결하기도 함

persistnet HTTP

  • 한번의 connection에 여러개의 object를 보낼 수 있음
  • connection을 닫지 않고 열어둔 채로 file을 request/response를 함
  • 1RTT에 모든 파일들을 보내고/받을 수 있음

HTTP request message

  • HTTP message는 request/response 2가지 type으로 나뉨
  • Method types
    • GET, POST, PUT, DELETE
    • HEAD: request에 대한 response 메세지에 object를 담지 말라고 요청 (개발 단계에서 사용)
  • stateless한 HTTP를 stateful 하게 사용하기 위한 방법
  • 동작 방법
      1. clinet가 최초 접속 시 server는 response message header에 set-cookie 값으로 cookie 값을 보냄
      1. client의 browser는 cookie 값을 보관
      1. 다음 request 시에 request header에 cookie 값을 보냄
      1. server는 cookie 값을 이용해서 해당 DB entry에 저장된 값들을 가져와서 response

Web caches(proxy server)

  • origin server 의 내용을 proxy server에 copy 해두고, web access를 항상 proxy server를 통하도록 함
  • web cache는 client 이자 server 임
  • response time을 줄이고자 ISP가 web cache를 설치함
    • access link의 traffic을 분산시켜서 response time을 줄일 수 있음
    • 지리적으로 먼 경우 가까운 곳에 설치해 response time을 줄일 수 있음
    • connection을 제공하는 ISP들을 많이 거칠수록 많은 비용이 드는데 content가 web cache에 퍼지면 비용을 줄일 수 있음
  • 동작 방법
      1. client가 object를 request하면 proxy server는 해당 object를 대신 origin server에 request함
      1. proxy server는 client에게 response해주고 해당 object를 저장하고 있음
      1. 다른 client가 동일한 object를 request하면 proxy server가 바로 response 해줌

Conditional GET

  • web cache가 자신이 가지고 있는 object의 정확성을 위해 사용하는 method
    1. web cache가 origin server로 requst를 보낼 때 해당 object를 copy한 날짜를 If-modified-since 값으로 header에 집어넣음
  • 2-1. 만약 수정이 되지 않았다면 origin server가 304 Not Modified를 response함
  • 2-2. 만약 수정이 되었다면 origin server가 200 OK와 함께 새로운 object를 보내줌

Electronic mail

  • user agent와 mail server로 이루어져 있음
    • user agent: 메일의 작성/수정/읽기/보내기 등의 작업을 수행
    • mail server: 나가거나 들어오는 메일들을 보관하는 서버
      • mailbox: 유저마다 들어오는 메일들을 보관함(유저마다 하나씩 있음)
      • message queue: 유저가 보내는 메일들이 들어감(서버마다 하나)

SMTP

  • user agent가 mail server로 메일을 보내거나 mail server가 mail server로 메일을 보낼 때 사용하는 mail protocol을 말함
  • SMTP protocol은 TCP 위에서 사용하기 때문에 mail server로 보내기 전에 TCP connection이 맺어져야 함
  • persistent connection을 사용함 (한번의 connection으로 여러 개의 object를 보낼 수 있음)
  • port 25 번을 사용함
  • 작동 순서
      1. handshaking
      1. transfer of messages
      1. closure

mail access protocol

  • user 는 mail server로 부터 mail을 받아올 때 mail access protocol을 이용해서 메일을 가져오게 된다

POP3

  • 세션 간 stateless 하다는 특징이 있음
  • mailbox에서 mail들을 download 하는 방식 (download n keep mode, download n delete mode 두 가지 방식이 있음)

IMAP

  • POP3의 단점을 보완하고자 나옴
  • POP3에서 client의 작업은 local에서 이루어지지만 IMAP에서는 서버에서 이루어짐
  • 세션 간 user state가 유지됨

DNS(Domain Name System)

  • host name를 IP address에 매핑해줌
  • host aliasing (=> host naem의 별칭(alias)를 실제의 host name에 매핑해주는 기능)
  • mail server (=> 메일 서버에 대한 주소를 알려줌)
  • load distribution
    • 규모가 큰 web server의 경우 여러 개의 replica(ws1, ws2, ws3)를 가지고 있고 특정한 alias로 오는 request들을 여러개의 replica들로 매핑해줌

why not centralize

  • single point of failure
    • 문제 발생시 서비스 중단으로 이어질 수 있음
  • traffic volume
    • DNS server로 traffic이 몰릴 수 있음
  • distant centralized database
    • 지리적으로 멀면 response time이 길어짐
  • maintenance
    • 규모가 큰 DB의 경우 유지 보수가 힘듦

distributed, hierarchcal DB

  • root name server: 계층의 최상위에 존재하며 어떤 TLD server들이 존재하는지 알고 있고 요청 시 해당 TLD server로 매핑해줌
    • local DNS server와 contact함
  • TLD(Top level Domain)Server: .com, .org, .edu, .kr, .jp level의 DNS server들
    • 기관별 authoritative DNS server 를 알고 있음
  • authoritative DNS server: TLD 아래의 DNS Server들
    • 서비스 제공자가 자신의 DNS Server를 관리함(e.g amazon.com => 아마존이 관리)
    • 요청으로 들어온 hostname의 IP에 대한 정보를 갖고 있음
    • ``에 대한 매핑 정보를 caching 하고 있음

local DNS Server

  • 위의 hierarchy 구조에 속하지 않는 DNS Server, proxy server 라고도 불림
  • ISP가 local site 내에 설치하게 됨
  • 매핑 정보를 갖고 있으면서 client 들의 요청을 1차적으로 처리(=> web caching과 비슷)
  • 없는 내용에 대해서 request가 들어오면 root name server로 query
  • TLD Server에 대한 매핑 정보를 caching 하고 있어서 보통은 root name server를 거치는 일이 적음
    • out-of-date 방지를 위해 TTL(time to live)를 포함하고 있음

DNS Server의 query 해결 방법

  • DNS는 query와 reply 두 가지 type으로 메세지를 주고 받음

1. iterated query

  • query가 들어왔을 때 contact한 DNS Server는 어떤 server에 contact해야 하는지만 알려줌
  • "난 모르는데 쟤가 알고 있어"

2. recursive query

  • query가 들어왔을 때 contact한 DNS server가 답을 찾아서 응답해줌
  • 계층구조의 상위계층에 많은 부하가 몰릴 수 있음

DNS Server에 records를 넣는 example

  1. 'network utopia'라는 회사가 등장
  2. network utopia는 authoritative server를 구입
  3. .com 의 TLD Server를 관리하는 회사(network solutions)에 자신의 authoritative server IP 주소와 이름을 제공
  4. network solutions는 .com TLD Server에 이를 등록함

P2P Application

  • 이전까지는 Client to Server 구조였음
  • P2P 구조는 확장성의 장점을 가짐

File distribution time
파일의 크기를 F, 서버의 업로드 속도 u(s), peer의 업로드 속도와 다운로드 속도를 u(i), d(i) 라고 했을 때 N 명에게 파일을 distribution 하는 시간은 max( NF/u(s), NF/(u(s)+u(0)+u(1)+..+u(n-1)), F/d(min)) 이다.

Socket programming

  • 두 가지 transport service에 따라 두 가지 socket type으로 나뉜다
    • TDP: reliable & byte stream-oriented 인 특징을 지님
    • UDP: unreliable

UDP Socket Programming

  • client & server 간 connection이 없음
    • data를 보내기 전 handshaking 과정 없음
    • 각 패킷(=> datagram)마다 IP 주소와 port#를 붙여서 보냄
    • 수신 측은 전달된 packet 으로 부터 송신 측의 IP 주소와 port#를 알아냄
  • 전달한 data가 순서가 뒤죽박죽으로 오거나 손실될 가능성이 있음
  • 동작과정

TCP Socket Programming

  • client는 server와 connection을 맺어야 함
  • server는 contact를 위한 socket을 열어두고 request를 대기함
  • client가 contact하면 client는 TCP socket 을 만들고, socket에게 contact할 IP주소와 port#를 명시하고 connection을 맺음
    • server는 접촉한 client 만을 위한 새로운 socket을 만듦
    • byte stream order를 제공해야 하기 때문에 client별로 별도의 socket을 만들어야 하는 것
  • 동작과정

출처: http://www.kocw.net/home/search/kemView.do?kemId=1046412

profile
신명철
내 머릿속 지우개
이전 포스트

[Network] 0. 기본

다음 포스트

[Network] 2. Transport Layer

0개의 댓글