애플리케이션 계층

📘컴퓨터 네트워크

네트워크 애플리케이션의 원리

client-server 구조

• server
  • 항상운영되는 호스트
  • 고정 ip주소 할당
  • 확장 대비한 데이터 센터에서 운영
• 클라이언트
  • 서버와 통신
  • 필요시 서버와 접속
  • 유동ip주소 사용
  • 클라이언트 간 통신 없음

p2p구조

• 항상 운영되는 호스트 없음
• 종단 시스템간 통신 가능
• 피어는 다른 피어에 서비스를 요청하거나 제공할 수 있음
  • 자가 확장 - 새로운 피어는 서비스 요청과 제공 모두 가능
• 피어는 필요 시 접속 되며 ip주소 변경됨
  • 관리 어려움

프로세스 간 통신(IPC)

• 다른 호스트에서 각각 실행되는 프로세스 간에 합의된 통신 프로토콜 기반 메시지를 교환하여 통신
• 클라이언트 프로세스(서버에 통신을 요청하는 프로세스) 서버 프로세스(클라이언트 연결을 대기하는 프로세스)
• P2P구조 애플리케이션은 클라이언트 프로세스와 서버 프로세스의 속성을 모두 보유

소켓

• 프로세스는 메시지 송수신할때 소켓을 사용
• 소켓은 출입문과 유사
  • 송신 프로세스는 메시지를 출입문 밖으로 전송
  • 송신 프로세스는 출입문 밖에 있는 전송 하부구조에 의존하여 수신 프로세스가 존재하는 호스트의 소켓으로 메시지 전송

주소 운용 체계

• 고유 주소는 ip주소와 해당 프로세스와 연결된 포트 번호로 구성
• 메시지 수신하려면 프로세스는 고유 정보를 부여 받아야함
• 호스트 장치는 고유한 32비트 주소 보유
• Q: 프로세스가 운영되는 호스트의 IP주소만으로 해당 프로세스를 찾아내기에 충분한가?
  • 아니요. 동일한 호스트에서 다수 프로세스가 실행되므로 ip주소만으로 충분하지 않음

애플리케이션을 지원하는 전송 서비스 종류

• 데이터 손실
  • 특정 애플리케이션은 100% 신뢰하는 데이터 전송 필요
• 시간 민감도
  • 특정 애플리케이션은 낮은 지연시간필요
• 처리율
  • 특정 애플리케이션은 최소 처리율을 필요로함
  • 유연성을 요구하는 애플리케이션을 위한 유연한 처리율 필요 -보안
  • 암호화,데이터 정합성등

인터넷 전송 계층 프로토콜 서비스

1. TCP서비스
   • 송수신 프로세스 간 신뢰할 수 있는 전송
   • 연결 기반: 클라이언트와 서버 프로세스 간 사전 설정 필요
   • 흐름 제어 : 송신자의 송신 역량은 수신자의 수신역량을 초과할 수 없음
   • 혼잡 제어 : 네트워크 혼잡 시 송신자는 송신량을 조절
   • 제공하지 않는 서비스 : 타이밍, 최소 처리율 보장 , 보안 등
2. UDP서비스
   • 송수신 프로세스 간 신뢰할 수 없는 데이터 전송
   • 비연결 기반 : 클라이언트와 서버 프로세스 간 사전 설정 불필요
   • 제공하지 않는 서비스 : 신뢰성,흐름제어,혼잡제어,타이밍,처리율 보장,보안 ,연결설정등

웹과 HTTP

• 웹 : 웹이란 객체로 구성됨 , 웹 페이지는 기본 HTML파일과 다양한 참조 객체로 구성됨
  • 각 객체는 URL로 지정됨 host name(www.someschool.edu/someDept)+path name(/pic.gif)
• HTTP
  • 클라이언트 : HTTP 프로토콜을 사용하여 웹 객체를 요청,수신,표시하는 브라우저
  • 서버 : HTTP프로토콜을 사용하여 브라우저에서 요청한 객체를 전송하는 웹 서버
  • TCP프로토콜 사용
  • 클라이언트는 소켓을 열고 80번 포트를 이용하여 웹서버와 TCP연결 시도
  • 서버는 클라이언트의 연결 요청을 수용
  • HTTP메시지가 웹 서버와 웹 브라우저 간에 송 수신됨
  • 전송후 TCP연결 종료
  • HTTP는 연결 상태 유지하지 않음
  • 서버는 클라이언트의 과거 요청 정보를 관리하지 않음
• 2가지 HTTP 연결 종류

  • 비지속 연결 HTTP

  • TCP 연결 설정
  • 1개 이상의 객체가 TCP연결을 통해 전달
  • TCP연결 해재
  • 10개의 jpeg 객체를 얻기 위해 1~5단계를 10번 반복
  • 응답 시간 2RTF+파일 전송 시간
    • RTT : 클라이언트에서 생성한 단위 패킷이 서버로 갔다가 되돌아 올때 까지의 왕복 소요 시간
    • TCP 연결 개시 RTT
    • HTTP요청과 HTTP응답을 처리하기 위한 RTT
    • 파일 전송 시간
  • 문제
    • 객체 당 2개 RTT필요
    • 각 TCP연결 처리를 위한 운영체제 오버헤드 발생
    • 브라우저는 참조 객체를 가져오기 위해 순차적으로 TCP 연결을 시도함

  • 지속 연결 HTTP
    • 서버에 TCP연결 설정
    • 1개의 TCP연결을 통해 서버와 클라이언트 간에 다수 객체가 송 수신됨
    • TCP연결 해재
    • 서버는 응답 전송 후 연결을 오픈 상태로 유지
    • 후속 HTTP메시지는 오픈된 연결을 통해 송 수신
    • 클라이언트는 참조 객체가 확인되면 즉시 요청 시도
    • 1개의 RTT수준으로 모든 참조 객체 처리 가능

  • 다수 객체 다운로드 할 경우
  • 다수 연결 필요

HTTP 업로드 요청 방식

1. Post 방식
   • 웹 페이지는 폼 입력 형식을 사용함
   • 입력 내용이 entity body 형식에 내장되어 서버로 전송됨
2. GET 방식
   • 일반적으로 GET 방식 사용
   • 입력 내용이 URL 필드의 요청라인에 포함되어 전송됨

HTTP 요청 형식

1. POST 메소드
   • 폼 입력 포함 된 웹 페이지 수신
   • 사용자 입력이 클라이언트의 바디 중 엔터티에 포함되어 전송
2. GET메소드(서버에 데이터 전송용)
   • HTTP GEt 요청 메시지의 URL필드에 ? 표시되어 기술
3. HEAD 메소드
   • HTTP GET 메소드에 기술한 URL에 대한 헤더만 요청
4. PUT 메소드
   • 서버에 파일 업로드 시 사용
   • HTTP POST 메소드에 기술된 경로의 파일 내용을 새로 대체함

HTTP 응답 상태 코드

1. 200ok : 요청 성공
2. 301 :요청 객체가 이동 되었으며, 새위치는 메시지에 포함된 로케이션 참조
3. 400 : 요청 메시지를 서버가 이해할 수 없음
4. 404 : 요청 문서를 서버에서 찾을 수 없음
5. 505 : 요청된 HTTP 버전을 서버가 지원하지 않음

서버의 사용자 상태 관리 : 쿠키

• 쿠키의 활용 용도 : 인증,쇼핑카트,상품추천,사용자 세션 상태
• 상태 유지 방법 : 클라이언트와 서버간에 쿠키 정보 공유하여,동일한 사용자의 복수 트랜잭션을 구분하여 처리
• http메시지 중 쿠키 항목을 통해 상태 정보 전송

웹 캐시(프락시 서버)

• 목표 : 오리진(원본) 서버 개입 없이 클라이언트 요청 처리
• 사용자 브라우저 사전 설정 : 웹 캐시를 통해 오리진 접속
• 브라우저는 http요청을 웹 캐시로 전송
  • 웹캐시 내 객체있으면, 해당 객체를 반환, 웹 캐시는 오리진 서버에 객체 요청하고 수신후 클라이언트에 전달
• 웹 캐시는 서버와 클라이언트로 각각 동작 클라이언트<->웹캐시<->오리진서버
• 목적 : 클라이언트 요청의 응답 시간 감소,기관의 액세스 링크 트래픽 감소 , 저속 네트워크 경우 콘텐트 제공자에게 사용자의 고속 네트워크 접속 가능성 제공

  사례 : access link late : 1.54Mbps , RTT from institutional router to server : 2sec average data rate to browsers : 1.50 Mbps , institutional network : 1Gbps

  Lan utilization(이용률) : 1.5Mbps/1Gbps = 1.5/1000 = 0.0015 acces link utiliztion = 1.5Mbps/1.54Mbps = .97

• 내부에 웹 캐시 설치를 하면?
• 60프로 오리진을 가지고 있으면 0.6*1.5Mbps = 0.9Mbps
• utiliztion = 0.9/1.54 = .58

조건부 GET

• 목표 : 웹 캐시에 객체의 최신 정보 저장 되어 있으면 객체 송수신 하지 않음(객체 전송 지연 없음, 링크 이용율 저하)
• 웹 캐시 : HTTP요청 할 때 캐시에 저장된 객체 저장 시간 표기
• 서버 : 캐시 내용에 변화가 없으면 객체 정보 전송하지 않음

HTTP/2

• 목적 : 다중 HTTP 객체 요청시 지연 감소
• HTTP1.1 은 단일 연결 FCFS로 앞에 긴 객체 전송 완료 될때 까지 뒤에 객체 대기
• 서버에서 클라이언트로 다중 객체 전송 시 유연성 향상
• 객체를 프레임으로 분할하고 프레임 단위로 전송

전자 메일

1. 사용자 에이전트
   • 메일 읽기 프로그램 , 메일 메시지 작성, 전송,수신,읽기,기능 제공
   • 아웃룩,스마트폰 이메일 프로그램등
   • 송수신 메시지는 메일 서버에 저장
2. 메일 서버
   • mailbox : 사용자에 전달할 수신 메시지 보관
   • message queue : 외부 사용자에 전송할 메시지 보관
   • smtp protocol : 메일서버간에 메일 전송
3. 전자 메일 : SMTP
   • 클라이언트와 사용자 간에 TCP 프로토콜 사용하여 신뢰성있는 메시지 전송 지원
   • 메일 서버들 간에 직접 송수신
   • 전송 3단계 : 핸드 쉐이킹->메시지전송->연결종료
   • 명령/응답의 상호 작용 / 명령어 : ASCII 텍스트 / 응답 : 상태 코드와 문장들
   • 메시지는 반드시 7비트 ASCII만 사용 가능
   • 송신자는 수신자 서버로 메시지 전송하고 수신자는 메시지 수신후 저장함
   • 메일 사용 프로토콜 : 서버로부터 수신 메시지 추출
     • POP3 : 클라이언트가 메시지 저장 및 보관,세션간 상태 저장 안됨
     • IMAP : 서버에 모든 메시지 저장, 사용자가 폴더 지정하여 분류 저장 가능, 세션중 연결 상태 저장

DNS

• 다수의 name server 를 계층 구조로 재치하여 구현한 분산 데이터 베이스
• 애플리케이션 계층 프로토콜 : 호스트와 네임 서버 간에 통신 :수행하여 주소<->이름 변환
• 호스트 이름과 ip주소 간의 상호 변환
• DNS를 중앙 집중화 하지 않는 이유
  • 단일 지점 고장으로 인한 서비스 중단 배제
  • 엄청난 트래픽의 분산 처리
  • 사용자 근처에서 운영되는 분산 데이터베이스로 접근 시간 단축
  • 유지 보수 용이

    DNS : 분산 계층 데이터 베이스

• 클라이언트에서 www.amazon.com의 IP 주소가 필요할 경우
  • 클라이언트는 com DNS server 주소를 알기 위해 root server에 질의하여 .com DNS server 주소 알아내고 다음으로 클라이언트는 .com DNS server에 질의하여 amazon.com DNS server 주소 알아내고 끝으로 클라이언트는 amazon.com DNS server에 질의하여 www.amazon.com의 IP 주소 알아냄
• TLD 서버 : 레벌 2
  • com,org,net 등 관리
• 책입 DNS 서버 :레벨 3
  • 기관 내에서 운영되며, 서버의 이름과 ip주소 간 변환 저보 관리하고 외부 요청 시에 해당 정보 제공
  • 기관 내 담당자 또는 서비스 제공자에 의해 관리

Local DNS name server

• 엄밀하게는 계층 구조에 포함되지 않음
• 각 ISP가 처리 속도 향상을 위해 개별적으로 운영
  • 디폴트 네임 서버 또는 캐시 서버라고도함
• 호스트가 DNS질의를 하면 , 로컬DNS서버로 먼저 전송됨

DNS 동작 사례

1. 반복적 질의 : 연결된 서버는 다음에 연결할 서버 주소를 클라이언트에 회신
2. 재귀 적 질의 : 연결된 서버가 이름 변환의 부하를 독자적으로 감당함

DNS : 레코드 캐싱과 업데이트

• 네임 서버는 정보를 입수하면 캐시에 매핑 정보 저장
  • 일정한 시간 이후 캐시 정보 사라짐
  • 로컬 캐시 서버에 TLD서버 정보 저장
• 캐시 정보가 실제 정보와 일치 되지 않을 수 있음
  • 호스트 ip주소 변경되면 ttl시간 경과 되어야 갱신된 내용이 전체 dns로 전파됨

DNS 레코드

• DNS : 분산 데이터 베이스 내 자원 레코드 (RR 형식 : (name,value,type,ttl)) 1.type = A
• name : 호스트 명칭
• value : IP주소
  1. type = NS
• name : 도메인
• nalue : 해당 도메인 내 책임 DNS 서버의 호스트 이름
  1. type = CNAME
• name : 정식 명칭의 별칭
• value : 정식 명칭
  1. type = MX
• value : 메일 서버 정식 명칭

단순 P2P 구조

• 항상 접속 가능한 서버 없음
• 임의의 종단 시스템 간 자율적 통신
• 피어들 간에 비정기적으로 통신하고 ip주소를 수시 변경함

P2P파일 분배 : 비트 토렌트

• 파일은 266KB단위 청크로 분할
• 토렌트에 속한 피어 간에 청크 단위로 파일 송수신
• 토렌트에 가입하는 피어
  • 청크가 없지만 시간이 경과하면서 다른 피어들로부터 청크를 받아 저장함
  • 피어 목록을 받거나 일부 이웃한 피어에 접속하기 위해 트래커를 통해 가입
• 피어들은 이웃 피어와 다운로드 및 업로드를 동시에 진행함
• 피어들은 청크 교환을 위해 상대 피어를 변경할 수 있음
• 변동 : 피어들은 임의로 탈퇴하거나 가입할 수 있음
• 전체 파일을 입수한 피어는 토렌트에서 탈퇴하거나 남아 있을 수 있음
• tit-for-tat
  • 4제공자 중 하나가 되고 ,밥이 보답을 함
  • 더 빠른 업로드 속도로 더 나은 파트너를 찾고 파일을 더 빨리 얻을 수 있음

스트리밍 비디오 인코딩(인코딩 + DASH + 클라이언트 버버링)

• 코딩 : 이미지 인코딩을 위해 앞뒤 이미지 들 간에 포함된 중복 요소를 고려
• 단순 시나리오
  • 비디오 서버 -> 인터넷 -> 클라이언트
  • 서버와 클라이언트 간 대역폭이 지속적으로 변경됨
  • 패킷 손실과 지연에 따른 화질 저하 발생
• 스트리밍 비디오
  • 클라이언트는 동영상 첫 부분을 보여주고 있찌만 서버는 동영상 뒷 부분을 전송하고 있음
  • 연속적인 동영상 출력 : 첫 화면과 마지막 화면간 동기화 되어야 함
    • 하지만 네트워크 지연은 가변적
    • 동기화하기 위한 클라이언트에 버퍼 제공(버퍼링)

멀티미디어 스트리밍 : DASH

-서버

• 비디오 파일을 다수의 청크로 분할
• 각 청크는 적합한 인코딩율로 변환 후 청크 단위로 저장
• manifest file : 각 청크의 url 제공
• 클라이언트
  • 주기적으로 서버와 클라이언트 간의 대역폭 측정
  • manifest파일을 참조하여 한번에 한개의 청크 요청
    • 현재 대역폭에서 지원 가능한 최고 비율로 인코딩된 청크 선택
    • 대역폭의 변동에 따라 최적의 인코딩된 청크 선택
  • 언제 청크를 요청할 것인가 : 클라이언트 수신 버퍼가 부족하거나 초과 사용되지 않도록
  • 어떤 인코딩율의 청크를 요청할 것인가 : 대역폭이 가능할 경우 최고율로 인코딩된 청크 선택
  • 어느 서버에 요청할 것인가 : 클라이언트에 가까운 서버에 요청

컨텐츠 전송 네트워크(CDN)

• 옵션1 : 단일 초대형 서버(문제점 : 확장성 없음)
  • 단일 고장 지점
  • 네트워크 혼잡 지점
  • 멀리 떨어진 클라이언트 처리
  • 출력 링크로 여러 개의 복사된 동영상 전송
• 옵션 2 : 지역적으로 분산된 여러 사이트에 여러 개의 복사된 동영상을 저장하고 제공
  • enter deep : CDN 서버를 여러 액세스 네트워크에 고정 배치(사용자에 가깝게 배치)
  • bring home : 네트워크와 일반 가정 사이에 주변에 초대형 클러스터 구성
• CDN 노드에 컨텐츠 복사본 저장
• 가입자는 CDN에 컨텐츠 제공 요청
  • 가입자 근처의 CDN노드에서 복사본 제공
  • 네트워크 경로 혼잡할 경우 다른 CDN노드에 제공 요청