감 1도 없는 개발자

감 1도 없는 개발자

여행을 꿈꾸는 개발자

응용계층

Updated:

강의

http://www.kocw.net/home/search/kemView.do?kemId=1159726

응용계층

1. 네트워크 응용의 구조

  • client - server 구조 :
    • ex) 웹검색
    • 안정적
  • Peer to Peer (P2P) 구조
    • ex) 토렌트
    • 불안정
  • 하이브리드 구조
    • 사람과 사람이 만나기 전까지는 서버에서 관여하다가 만나고 난 이후에는 서버가 관여 하지 않음.
    • ex) Skype, 스타크래프트

2. 프로세스간 통신

  • 응용 : 네트워크로 연결된 컴퓨터들이 협력하여 제공하는 서비스
    • ex) 구글 검색
  • 프로세스 : 하나의 컴퓨터에서 독립된 메모리 공간을 가지고 수행되고 있는 프로그램의 단위

3. 프로세스 주소

  • IP주소 + 포트번호를 통해 프로세스간 연결

  • 기계 주소(IP주소)

    • IP : XXX.XXX.XXX.XXX. 이때 XXX는 0부터 255까지. 256^4 = 2^32 = 약 40억

  • 포트번호

    • IP를 찾았는데 해당 컴퓨터에 어느 프로그램에게 결과 값을 보낼지 알아야하는 것.

    • 2^16개 - TCP. 2^16 개 - UDP. 총 2^32개

4. 소켓통신

  • 소켓이란 세션계층과 전송계층을 이어주는 일종의 인터페이스

  • 클라이언트와 서버간의 private channel로 통신
  • 기본적으로 소켓은 상대방에게 데이터를 보내거나 받는 역할을 하며 연결을 수동적으로 기다리느냐, 능동적으로 연결을 하느냐로 서버, 클라이언트를 나눈다. 꼭 이게 서버,클라이언트 정의는 아님. 단순 역할에 대해서 설명할때 말하는 것.
  • 서버 소켓은 클라이언트로부터 연결 요청이 오기를 기다렸다가 요청이 오면 연결을 하고 다른 소켓을 만든다.
  • 클라이언트 소켓은 요청을 보내는 입장이니 바로 클라이언트 소켓을 생성하고 서버에 연결 요청을 한다.

5. 인터넷 전송계층의 서비스

  • 응용계층이 전송계층의 어느 서비스랑 연결되는지 잠깐 araboza.

5.1 TCP

  • 연결기반 전송 계층
  • 연결에 대한 관리 : 데이터 유실 복구
  • 데이터순서 보장
  • 혼잡에 민감한 패킷전송률 조정

5.2 UDP

  • 무연결 전송 계층
  • 데이터 유실 가능
  • 최대한 성능으로 패킷 전송

6. 세션 계층의 서비스

6.1 FTP (File Transfer Protocol)

  • 원격 host에 있는 파일을 가져오거나 host에 보내기 위한 프로토콜
  • TCP / IP 프로토콜을 가짐
  • 가정 1: 클라이언트 사용자는 서버의 파일을 읽을 수 있는 권한의 계정이 있다.
  • 가정 2: 계정이 없는 경우도 접근 가능하다.
  • 세션 로그인과 종료가 존재
  • 로그인을 통하여 권한 획득
  • 로그인 정보를 서버가 관리
  • Stateful Protocol : 즉, 세션 계층에서 하는 일이 많다는 의미
  • 반대로 http는 세션 관리를 응용계층에서 함. 세션 계층에서 하는 일이 적다. 단순하다는 이야기
  • 그래서 응용 계층에서 해야할일이 많아지므로 확장성이 커짐. 개발자가 할일이 많아짐
  • 다시 반대로 얘기하면 ftp는 확장성이 적음. 사용자가 원하는 방향으로 개발하기가 힘듬
  • 그래서 많은 응용 계층들이 http를 사용하는 이유임

6.2 HTTP

  • TCP / UDP 프로토콜을 가짐

  • 세션 계층 (WWW) 프로토콜
  • HTML을 기본 프로젠테이션 계층으로 사용
  • 목적 : 전 서계 인터넷에 있는 정보를 탐색
  • 발명 : Tim 버너스-lee가 CERN에서 1980년말 ~ 1990년 초 연구해서 개발
  • 동작 : Web 자료를 가져와서(get) 보여주기. web에 자료를 posting하기
  • 보통 80번 port를 사용
  • 하나의 요청와 응답을 http transaction이라고 부름.
  • 즉, 각 http transaction에 대해서 서로 상관이 없음. state를 저장하지 않기 때문에
  • stateless protocol 이다 : 세션을 관리 안하기 때문에

  • 단순하고 자유도가 높다보니 ftp를 밀어내고 주요 프로토콜로 성장함

  • URL (Universal Resoucre Locator)
    • http://naver.com/cafe/
    • http : 프로토콜 이름. 물론 ftp를 지원한다면 웹 브라우저로 ftp 프로토콜 사용 가능
    • //naver.com : 호스트 이름. 물론 여기에 ip주소를 써도 된다.
    • /cafe/ : 호스트 아래 있는 리소스 주소. directory or file (자원들)
    • URI는 URL보다 작은 개념으로 동적으로 찾으려는 자원을 말함.
    • URI 차이는 자세히 포스팅 해둠
6.1 GET 요청
  • 원하는 자원을 가져오는 요청
  • 요청, 응답 형식. 응답은 post와 동일
GET /서버상의 자원의 위치/ HTTP/1.1(버전)
host(매개변수 1): formal.kw.ac.kr
User-agent매개변수 2: Media/5.0
***

// 헤더의 끝에 한줄을 띄우면 Get 요청이 끝난다는 것을 의미

HTTP/1.1 200 OK
last_modifited : 날짜
Content-length : 487 // 응답코드의 전체 길이. 여기까지 헤더를 의미
	// 한줄 띄기 헤더와 몸통 분리 의미
    // 여기서부터 body(몸통) 실제 요청한 자원

6.2 POST 요청

  • 자원을 서버에 게시하고 싶을 때
  • 요청 형식
POST /서버상의 자원의 위치/ HTTP/1.1(버전)
host(매개변수 1): formal.kw.ac.kr
User-agent매개변수 2: Media/5.0
	// 한줄 띄기. 몸통과 분리
    // posting할 내용 적기
  • http는 각 요청마다 상관이 없는 stateless다.

  • 근데 우리가 사용하는 웹서비스는 그렇지 않다. ex) 다른 게시글을 이동해도 계속해서 로그인 유지

  • 웹 응용의 구조
  • 서버 응용이 클라이언트의 이전 작업정보(state)를 파악하기 위한 도구

  • 프로토콜 : http Response 헤더의 set-cookie라는 필드. http request 헤더의 Cookie라는 필드

  • 기억해야할 사항을 쿠키에 담아 클라이언트가 기억하도록 하고 서버는 클라이언트의 방문시 주는 쿠키 정보의 맞추어 반응.
  • 클라이언트의 권한이 너무 크고 정보를 너무 많이 주게 됨. 해킹의 문제 원인
  • 해결책 : 세션.

7.1 세션

  • 클라이언트의 고유 세션 ID를 제공. 클라이언트는 요청 시 서버에게 받은 고유 세션 ID만을 서버에게 전달.

  • 따라서 클라이언트 정보를 서버가 가지고 있음

8. HTTP

  • 지금 까지는 HTTP의 작동 방식을 배움
  • 지금부터는 성능의 발전을 공부해보자.

8.1 성능 향상 (다 중HTTP transaction)

  • 지속적인 http transaction이 일어나면 http 연결과 종료가 너무 빈번히 일어난다.
    • Persistent HTTP : 반복되는 http 연결과 종료를 한 번만 일어나도록 개선
  • 요청 자체로도 시간이 오래 걸린다.
    • Pipelined HTTP
8.1.1 성능 향상 예시

  • 현재 http 작동 방식이 기본이면서 아래 조건이라고 가정하자

  • 지연 시간 : 패킷을 보내기 시작한 시점에서 패킷을 받기 시작한 시점까지 걸리는 전송 지연 시간
  • 전송률 : 단위시간당(초) 전송되는 데이터의 양

ex1) 끝단간 지연시간이 100ms이고 전송률이 100MB/s인 네트워크에서 1MB를 전송하여 수신을 완료하는데 걸리는 시간은?

  • 전송 받고자하는 정보
  • HTTP 헤더
  • TCP 연결 / 종료 시간

ex 2) 지연시간은 100ms 전송률 100KB/s, HTML 페이지 문서 1KB, 이미지 저장크기 10KB(이미지는 총 3개 가져옴), HTTP헤더 Req, Res 각각 1KB, TCP 연결 400ms, TCP 종료 200ms라고 가정.

  • 최초 HTML 페이지만 주고 받았을 때 정보 수신완료 시간 630ms. 전체 완료는 830ms.

  • 이미지는 HTML 문서(1KB)보다 10배이므로 100ms가 됨. 그래서 이미지 수신은 720ms. 전체완료는 920ms
  • 근데 이미지가 3개라고 했으니 최종 920ms * 3 + 830ms = 3590s가 된다.
8.1.2 persistent http

  • 위의 상황에서 성능을 향상 시켜보자

  • 3590ms - 3 * 600ms(TCP 연결과 종료 시간을 합친것) = 1790ms

8.1.3 Pipeline Http
  • 각자 해보자..

8.2 성능향상 2 (네트워크 구조)

8.2.1 Web Cache (Proxy Server) :
  • ISP에서 비용 절감을 위하여 이전에 가져온적이 있는 문서를 DB에 임시 저장해 두었다가 동일 문서가 다시 요청될 때 재사용
  • 자기가 가지고 있는 내용이라고 해도 서버에 안가는 것은 아니다. 단지 HTTP 요청크기(내용)가 줄어듬.
  • 단지 내용이 서버에서 바뀌었냐 아니냐 물어보기 때문에 빨라짐.
  • 서버이자 클라이언트. 중개상인의 개념
  • 요청에 대한 응답시간 단축. 제공하는 교통량 증가(적은 서버로 더 많은 사용자 수용)

9. DNS (Domain Name System)

  • 인터넷에서의 ID 체계 : IPv4, IPv6
  • 그러나 이것은 너무 많은 숫자로 이루어져 외우기 힘들다.
  • 그래서 인간이 외우기 쉽게 만든 시스템이 DNS
  • 응용계층(인터넷 5계층에서)에서만 관여
  • aliasing 관리

9.1 계층

  1. 최상위 : Root Name Service
  • Top-level domain name server (TLDNS) 관리

  • Top-level domain : .kr, .com , .edu, .net 같은 것들을 말함

  • 맨 처음 Top-level domain server의 ip와 유효기간을 반환
  • 그 후에는 유효기간 안에는 top level domain 서버 ip 요청 X
  1. Authorized DNS (ADNS)

  • TLDNS 아래 있는 계층

  • .kr DNS, .net DNS, .com DNS 이렇게 같은 top level domain을 들로 이루어져 있음
  • 여기서부터 캐쉬를 가지고 있음
  1. Local DNS (LDNS)

  • Authorized DNS 계층 아래 있음

  • 사용자가 처음 Domain을 물어보는 시스템

9.1.1 Recursive Domain Name Resolvation
  • 사용자가 요청한 도메인이 LDNS에 없을 경우 바로 ROOT DNS 계층에 물어봄.
  • 거기에 없으면 TLDNS에 물어봄.

  • 다시 또 없음 LDNS에 물어봄.

  • 그 이후로 같은 DNS에 물어보게 되면 바로 요청한 도메인이 있는 LDNS에 요청. 이를 Interactive라고 함

10. P2P

  • 서버없이 Peer들끼리 직접 상호간 서비스를 제공하는 시스템(물물교환)
  • 서비스가 보장이 안된다. 그래서 신뢰성이 없음
  • 조각들의 쏠림 현상
  • Peer 들은 IP를 바꾸며 옮겨 다닐 수 있다.

10.1 Hybrid System

  • 서비스마다 정보는 서버가 관리
  • 실제 서비스는 peer끼리
  • ex) Skype, 스타크래프트, 토렌트

You may also enjoy