2장. 애플리케이션계층 (Application Layer)cs.sch.ac.kr/lecture/Network/Network-2017/17-2-Network-Applicatio… · 순천향대학교컴퓨터공학과 1 2장. 애플리케이션계층

순천향대학교 컴퓨터공학과 1

2장. 애플리케이션 계층(Application Layer)

순천향대학교 컴퓨터공학과

이 상 정

컴퓨터 네트워크

2. 애플리케이션 계층

2장. 애플리케이션 계층

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

2.2 웹과 HTTP

2.3 인터넷 전자메일• SMTP, POP3, IMAP

2.4 DNS-인터넷 디렉터리서비스

2.5 P2P 파일분배

2.6 비디오 스트리밍과 컨텐츠 분배 네트워크

2.7 소켓 프로그래밍: 네트워크 애플리케이션 생성




강의 목표

네트워크 애플리케이션의 개념과 구현 측면 학습• 애플리케이션 계층 프로토콜

• 클라이언트와 서버, P2P

• 트랜스포트 계층 서비스 모델

• 컨텐츠 분배 네트워크

주요 애플리케이션 프로토콜 계층 학습• HTTP

• SMTP / POP3 / IMAP

• DNS

네트워크 애플리케이션 프로그래밍• 소켓 API






2.2 웹과 HTTP









네트워크 애플리케이션 예

e-메일 (e-mail)

웹 (web)

인턴스트 메시징 (instant messaging)

원격 로그인 (remote login)

P2P 파일 공유 (P2P file sharing)

다중 사용자 네트워크 게임 (multi-user network games)

스트리밍 저장 비디오 (streaming stored video clips)

• YouTube, Hulu, Netflix

VoIP (Voice over IP): Skype

실시간 화상 회의 (real-time video conferencing)

소셜 네트워킹 (social networking)

검색 (search)

……………




네트워크 애플리케이션 개발

애플리케이션 프로그램• 서로 다른 종단 시스템(end system)

에서 동작

• 네트워크 상에서 통신

• 예: 웹 서버 프로그램과 통신하는웹 브라우저 프로그램

네트워크 코어 장비에서 실행되는소프트웨어를 개발할 필요 없음• 네트워크 코어 장비는 사용자

• 애플리케이션 실행하지 않음

• 따라서 종단 시스템의 애플리케이션을 빠르게 개발하고 전파가 가능




네트워크 애플리케이션 구조

애플리케이션 구조 (application architecture)• 개발자가 설계하는 애플리케이션이 다양한 종단 시스템에서 어떻게

조직되어야 하는지를 지시

클라이언트/서버 구조 (client-server architecture)

P2P 구조 (Peer-to-Peer architecture)




클라이언트/서버 구조

서버 (server)• 항상 켜져 있는 호스트

• 서비스 제공

• 고정 IP 주소

• 데이터 센터로 확장

클라이언트 (client)• 서버와 통신

• 서비스 요청

• 클라이언트들 간 직접 통신하지 않음

• 유동 IP 가질 수 있음

• 항상 연결되어 있지 않고 간헐적으로통신할 수 있음


client/server



P2P 구조


항상 켜져 있는 서버 없음

임의의 종단 시스템과 직접 통신

각 피어(peer)들이 각각 서비스를요청하고 제공• 높은 자기 확장성(self-scalability)

• 새 피어가 새로운 서비스를 제공하고,새 서비스를 요청

피어(peer)는 간헐적으로연결되고 IP 주소를 변경• 관리가 어려움

peer-peer



프로세스 간 통신(Processes Communicating)

프로세스(process)는 호스트에서 실행 중인 프로그램• 호스트 내에서 두 프로세스는 OS에서 정의한 IPC(inter-process

communication)로 통신

• 다른 호스트 간의 프로세스들은 메시지(message)를 교환하여 통신

클라이언트(client)와 서버(server) 프로세스• 클라이언트는 두 프로세스 간의 통신 세션을 초기화(접속을 초기화)

하는 프로세스

• 서버는 세션을 시작하기 위해 접속을 기다리는 프로세스

• 웹 예

• 브라우저는 웹 서버 프로세스와 접속을 초기화

• 브라우저는 클라이언트 프로세스, 웹 서버는 서버 프로세스

• P2P 구조의 애플리케이션들은 클라이언트 프로세스와 서버 프로세스를 가짐




소켓 (Socket)

프로세스는 소켓(socket)을 통해 네트워크로 메시지를 송수신• 소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층 간의

인터페이스

• 프로세스는 집(house), 소켓은 출입구(door)에 비유

• 송신 프로세스는 출입구(소켓) 바깥 네트워크로 메시지를 밀어냄

• 소켓은 애플리케이션과 네트워크 사이의 API(Application Programming Interface)




프로세스의 주소

호스트 상의 프로세스는IP 주소와 포트 번호로 구분

포트 번호 예• HTTP 서버: 80

• 메일 서버: 25

• 인터넷 표준 프로토콜에 대한알려진(well-known) 포트번호리스트는 www.iana.org 참조

HTTP 메시지를 gaia.cs. umass.edu 웹 서버에 전송• IP 주소: 128.119.245.12

• 포트 번호: 80


메시지 수신을 위해 프로세스를 구분하는 식별자(identifier)가 있어야 함

호스트는 32 비트 IP 주소로식별

Q: 프로세스가 수행되는 호스트의 IP 주소로 프로세스들을식별할 수 있는가?

• A: 아니요, 호스트에서많은 프로세스들이 동시에수행될 수 있음



애플리케이션 계층 프로토콜

애플리케이션 계층 프로토콜은 다음과 같은 내용을 정의• 교환되는 메시지의 타입

• 예: 요청 메시지, 응답 메시지

• 여러 메시지 타입의 문법(syntax)• 예: 메시지 내부의 필드(field)와 필드 간의 구별 방법

• 메시지 의미 (message semantics)• 필드에 있는 정보의 의미

• 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지를결정하는 규칙

오픈 프로토콜 (open protocol)• RFC(Request For Comments)로 정의

• 상호작용(interoperability) 허용

• 예: HTTP, SMTP

독점적인 프로토콜 (proprietary protocol): Skype, 카카오톡




애플리케이션이 요구하는 트랜스포트 서비스

데이터 무결성(data integrity) • 일부 응용들 (e.g., 파일 전송, 웹 트랜잭션)은 100% 신뢰적 데이터

전송(reliable data transfer) 요구

• 다른 응용들 (e.g., 오디오)은 일부 손실 감내

처리율 (throughput)• 일부 응용들(e.g., 멀티미디어)은 효과적인 서비스를 위해 요구되는

최소의 처리율 보장

• 다른 응용들은 처리율에 덜 민감

시간 (time)• 일부 응용들(e.g., 인터넷 전화, 다자간 상호작용 게임)은 효율적인

서비스를 위해 최소의 지연을 요구

보안 (security)• 암호화(encryption), 데이터 무결성 등 서비스 제공




애플리케이션들의트랜스포트 서비스 요구사항

애플리케이션 데이터 손실 대역폭 시간 민감성

파일 전송 비손실 가변적 아니요

전자메일 비손실 가변적 아니요

웹 문서 비손실 가변적(수 kbps) 아니요

실시간 오디오/비디오 손실 허용 오디오: 수 kbps~1Mbps비디오: 10kbps~5Mbps

네: 100msec

저장 오디오/비디오 손실 허용 오디오: 수 kbps~1Mbps비디오: 10kbps~5Mbps

네: 수 초

상호작용 게임 손실 허용 수 kbps ~ 10kbps 네: 100msec

인스턴트 메시징 비손실 가변적 네 그리고 아니오




인터넷 트랜스포트 계층이제공하는 서비스 (1)

TCP (Transmission Control Protocol) 서비스• 연결지향형 서비스 (connection-oriented service)

• 클라이언트와 서버 프로세스들 간에 연결 설정

– 서로 간 전송 제어 정보 교환(handshaking)하고 송수신 준비

• 신뢰적인 데이터 전송

• 송수신 프로세스 간에 데이터의 손실 없이 올바른 순서로 전달

• 흐름제어 (flow control)

• 송신 프로세스가 수신 프로세스의 데이터 수신 속도에 맞추어 송신

• 혼잡제어 (congestion control)

• 네트워크가 혼잡상태에 이르면 프로세스의 전송 속도를 낮춤

• 제공하지 않는 서비스

• 시간 보장, 최소 처리율 보장, 보안




인터넷 트랜스포트 계층이제공하는 서비스 (2)

UDP (User Datagram Protocol) 서비스• 비연결형으로 두 프로세스가 통신 전에 정보 교환(handshaking)을

하지 않음

• 비신뢰적인 데이터 전송 서비스를 제공

• 흐름제어, 혼잡제어, 시간 보장, 처리율 보장, 보안 등의 서비스도제공하지 않음

• 실시간 애플리케이션들이 전송속도를 위해 UDP 사용

• TCP 혼잡제어와 패킷 오버헤드 문제 회피

• 많은 방화벽들이 UDP 트래픽을 차단하도록 설정되어 점차적으로 TCP 상에서 멀티미디어와 실시간 애플리케이션을 수행하도록 선택




인터넷 애플리케이션의 트랜스포트 프로토콜

애플리케이션 애플리케이션 프로토콜 트랜스포트 프로토콜

전자메일 SMTP [RFC 2821] TCP

원격 터미널 접속 Telnet [RFC 854] TCP

웹 HTTP [RFC 2616] TCP

파일 전송 FTP [RFC 959] TCP

스트리밍 멀티미디어 HTTP(예: YouTube), RTP TCP 혹은 UDP

인터넷 전화 SIP, RTP, 독점적인(예: Skype) TCP 혹은 UDP




보안 TCP

TCP와 UDP• 암호화를 제공하지 않음

• 소켓을 통한 평문(암호화되지 않은 내용)의 비밀번호 등이인터넷으로 전송

SSL (Secure Socket Layer)• 암호화된 TCP 연결을 제공

• 데이터 무결성 (data integrity)

• 종단 인증

SSL은 애플리케이션 계층에서 구현• 애플리케이션은 SSL 라이브러리를 사용하여 암호화된 데이터를

TCP 소켓에 전달






2.2 웹과 HTTP









웹과 HTTP

웹 페이지 (web page)는 객체(object)들로 구성• 객체는 HTML 파일, JPEG 이미지, 자바 애플릿, 오디오 파일 ……

웹 페이지는 기본 HTML 파일과 여러 참조 객체들로 구성

각 객체는 URL (Uniform Resource Locator)로 지정• URL은 객체를 가지고 있는 서버의 호스트 이름과 객체의 경로 이름

으로 구성




HTTP 개요 (1)

HTTP (HyperText Transfer Protocol)는웹의 애플리케이션 계층 프로토콜

클라이언트/서버 모델• 클라이언트는 웹 객체들을 요청하고

받아서 디스플레이 하는 브라우저(browser)

• 서버 는 요청에 응답하여 객체들을보내는 웹 서버




HTTP 개요 (2)

HTTP는 TCP 트랜스포트 프로토콜을 사용• 클라이언트는 80번 포트로 서버에게 TCP 연결(소켓을 생성)을 시작

• 서버는 클라이언트의 TCP 연결 요청을 수락

• 브라우저(HTTP 클라이언트)와 웹 서버(HTTP 서버) 사이에 HTTP 메시지(애플리케이션 계층 프로토콜 메시지)를 교환

• TCP 연결 종료

HTTP는 비상태 프로토콜(stateless protocol)• 서버는 클라이언트의 과거 요청들에 대한 정보를 유지하지 않음

참고: 상태를 유지하는 프로토콜은 복잡• 과거의 기록들(상태)를 유지 관리해야 함

• 서버나 클라이언트 중 하나가 깨진 경우 각각의 상태는 불일치하게되어 조정이 필요




HTTP 연결 (HTTP Connections)

HTTP 연결은 비지속 연결과 지속 연결 2가지 방식이 있음

비지속 연결 (nonpersistent connection)• 요구/응답 쌍이 분리된 TCP 연결을 통해 송수신

• 하나의 TCP 연결로 하나의 객체만 전송

지속 연결(persistent connection)• 모든 요구/응답 쌍이 같은 TCP 연결 상에서 송수신

• 다수의 객체들이 하나의 TCP 연결로 전송




비지속 연결 HTTP (1)

다음 URL를 접속하는 예• www.someSchool.edu/someDepartment/home.index

• 웹 페이지는 한 개의 기본 HTML 파일과 10개 JPEG 이미지로 구성


1a. HTTP 클라이언트는www.someSchool.edu 서버의 80번 포트로 TCP 연결을 시도

2. HTTP 클라이언트는 TCP 연결소켓을 통해 HTTP 요청 메시지(request message)를 보냄.

요청 메시지에는 다음 경로 이름이포함.someDepartment/home.index

1b. 80번 포트로 TCP 연결을 기다리는www.someSchool.edu 호스트의HTTP 서버는 연결을 수락

3. HTTP 서버는 요청 메시지를 받고, 요청된 객체들이 포함된 응답 메시지(response message)를 생성하고, 소켓을 통해 송신시간



비지속 연결 HTTP (2)


5. HTTP 클라이언트는 HTML 파일이 포함된 응답 메시지를 받아서HTML을 디스플레이.HTML 파일을 파싱하여 10개의JPEG 객체에 대한 참조를 획득.

6. 10개의 JPEG 객체에 대해 1-5 단계를 반복

4. HTTP 서버는 TCP 연결을 종료

시간



비지속 연결: 응답 시간 (Response Time)

RTT (Round-Trip Time)• 클라이언트에서 송신된 작은 패킷이

서버까지 간 후 (그 응답이) 다시 클라이언트로 되돌아오는데 걸리는시간

HTML 파일 요청 응답 시간(response time)• TCP 연결을 초기화 하는 1 RTT

• HTTP 요청을 하고 HTTP 응답으로처음 몇 바이트를 받는데 필요한1 RTT

• 파일 전송 시간

• 2 RTT + 파일 전송 시간




지속 연결 HTTP

비지속 연결의 단점• 각 객체 당 2 RTT 필요

• 각 TCP 연결에 대한 OS 오버헤드

• 브라우저는 참조 객체들을 가져오기 위해 종종 병렬 TCP 연결을 시도

지속 연결 HTTP (persistent connection HTTP)• 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지

• 클라이언트/서버 간의 이 후 HTTP 메시지들은 같은 연결을 통해송수신

• 클라이언트는 객체를 참조하자마자 요청을 송신

• 모든 참조 객체들에 대해 1 RTT 만 필요




HTTP 요청 메시지 (HTTP Request Message)

두 유형의 HTTP 메시지: 요청(request), 응답(response)

HTTP 요청 메시지• ASCII 텍스트


요청 라인(request line)(GET, POST, HEAD commands)

헤더 라인(header lines)

CR(Carriage Return), LF(Line Feed )메시지의 끝을 표시



HTTP 요청 메시지: 일반 포맷




폼 입력 업로드 (Uploading Form Input)

웹 페이지는 폼 입력을 포함• 사용자가 브라우저의 폼 필드(form field)에 입력하여 서버에 전달

POST 방식 (POST method)• 입력은 개체 몸체(entity body)로 서버에 업로드

URL 방식• GET 방식(method) 사용

• 입력은 요청 라인의 URL 필드로 서버에 업로드


www.somesite.com/animalsearch?monkeys&banana



방식 유형 (Method Type)

HTTP/1.0• GET

• POST

• HEAD

• GET 방식과 유사하나 서버가 응답 시 요청된 객체는 보내지 않음

HTTP/1.1• GET, POST, HEAD

• PUT

• URL 필드에 명시된 경로로 개체 몸체 안의 파일을 업로드

• DELETE

• URL 필드에 명시된 파일을 삭제




HTTP 응답 메시지(HTTP Response Message)


상태 라인(status line)프로토콜(protocol)상태 코드(status code)상태 문장(status phrase)

헤더 라인(header lines)

데이타, e.g., 요청된 HTML file



HTTP 응답 상태 코드(HTTP Response Status Code)

응답 메시지의 상태 라인에서 표시

일반적인 상태 코드• 200 OK

• 요청이 성공되었고, 요청된 객체가 이 메시지로 보내짐

• 301 Moved Permanently

• 요청된 객체가 이동되었고, 새로운 위치는 메시지의 “Location:” 헤더로표시

• 400 Bad Request

• 서버가 요청을 이해할 수 없다는 일반 오류 코드

• 404 Not Found

• 요청된 문서가 서버에 존재하지 않음

• 505 HTTP Version Not Supported

• 요청된 HTTP 프로토콜 버전을 서버가 지원하지 않음




HTTP 응답 메시지 확인


1. 웹 서버에 텔넷으로 접속:

cis.poly.edu 호스트의 80번 포트로 TCP 연결설정(이 후 입력된 문자는 cis.poly.edu 호스트의80번 포트로 전송)

telnet cis.poly.edu 80

2. GET HTTP 요청 입력:

GET /~ross/ HTTP/1.1Host: cis.poly.edu

마지막 줄 입력 후 엔터를 두 번 입력( HTTP 서버에 GET 요청을 전송)

3. HTTP 서버에서 보낸 응답 메시지를 확인



실습 과제 2-1:HTTP, curl 적용하여 메시지 확인

특정 웹 서버에 curl로 접속하여 GET HTTP 요청을입력한 후 응답 메시지를 확인• 방문하는 웹 사이트는 다른 사람과 중복되지 말아야 함

참고: curl• 명령행 데이터 전송 도구 (command line data transfer tool)

• HTTP/HTTPS/FTP/LDAP/SCP/TELNET/SMTP/POP3 등주요 프로토콜을 지원

• C 언어 기반 libcurl 라이브러리도 제공

• 윈도우 버전 cURL은 아래에 다은로드

• https://curl.haxx.se/download.html




curl 사용 예




사용자와 서버 간의 상호작용: 쿠키 (Cookie) (1)

대부분의 상용 웹 사이트들이 쿠키(cookie)를 사용하여사용자 상태를 추적하고 유지• 쿠키는 4가지 요소로 구성

• HTTP 응답 메시지의 쿠키 헤더 라인

• HTTP 요청 메시지의 쿠키 헤더 라인

• 사용자 호스트에 저장되어 브라우저에 의해 관리되는 쿠키 파일

• 웹 사이트의 백엔드(back-end) 데이터베이스

• 예

• 수전은 항상 PC로 인터넷을 접속

• 처음 특정 전자상거래 사이트 방문

• 사이트에 첫 HTTP 요청이 들어올 때 서버는 다음을 생성

– 유일한 식별번호 (unique ID)

– 식별번호로 인덱스되는 백엔드 데이터베이스 안의 엔트리




사용자와 서버 간의 상호작용: 쿠키 (Cookie) (2)




쿠키 (Cookie)

쿠키의 활용• 사용자 식별 확인

• 쇼핑 카트

• 제품 추천

• 사용자 세션 상태 (웹 e-메일)

상태 보존• 일반 프로토콜 종단은 송신자/수신자 사이의 다 수의 전송들 간에

상태 유지

• 쿠키는 http 메시지가 상태를 전송

쿠키와 사용자 사생활 침해• 쿠키와 사용자 계정정보(이름, 메일주소 등)와 결합

• 사용자의 많은 정보가 노출




웹 캐시 (프록시 서버) (1)

웹 캐시(web cache)는 원래 웹 서버를 대신하여HTTP 요구를 충족 시켜주는 네트워크 개체• 프록시 서버 (proxy server) 라고도 함


브라우저는 웹 캐시와연결을 설정하고 웹 캐시에 HTTP 요청 전송• 웹 캐시에 객체가 있으면

객체를 전송

• 없으면 웹 캐시가 기점서버에 객체를 요청하여가져와서 클라이언트에전송



웹 캐시 (프록시 서버) (2)

웹 캐시는 클라이언트와 서버로 동작

일반적으로 웹 캐시는 ISP (대학, 회사, 인터넷 업체)에 의해설치

웹 캐싱(web caching) 이점• 클라이언트의 요청에 대한 응답 시간을 줄일 수 있음

• 인터넷으로의 기관 접속 회선 상의 웹 트래픽(web traffic)을 줄일 수있음

• 웹 캐시를 갖는 고밀도 인터넷(기관,지역,국가)

• 컨텐츠가 제공자가 저속도의 접속 회선을 가진 느린 서버에서 사이트를운영하더라도 빠른 컨텐츠 분배를 위한 기반 구조 제공




웹 캐시 예

가정

• 평균 객체 크기: 1 M 비트

• 브라우저에서 서버로 평균 요청 비율:15 요청/초

• 접속회선: 15 Mbps

• 기관 라우터에서 서버까지 요청을 전달하고응답을 받는 평균 소요 시간(RTT): 2초

성능

• LAN 이용율(15 요청/초 x 1 M 비트 ) / 100 Mbps = 0.15, 15%

• 접속 회선(access link) 이용율(15 요청/초 x 1 M 비트 ) / 15 Mbps = 1, 100% 문제 발생!!!

• 전체 지연인터넷 지연 + 접속 회선 지연 + LAN 지연= 2초 + 수 분(minutes) + 마이크로초 (usec.)




웹 캐시 예 - 더 빠른 접속 회선

가정

• 평균 객체 크기: 1 M 비트

• 브라우저에서 서버로 평균 요청 비율:15 요청/초

• 접속회선: 15 Mbps 150 Mbps

• 기관 라우터에서 서버까지 요청을 전달하고응답을 받는 평균 소요 시간(RTT): 2초

성능

• LAN 이용율(15 요청/초 x 1 M 비트 ) / 100 Mbps = 0.15, 15%

• 접속 회선(access link) 이용율(15 요청/초 x 1 M 비트 ) / 15 Mbps = 0.1, 100% 10% 150 Mbps

• 전체 지연인터넷 지연 + 접속 회선 지연 + LAN 지연= 2초 + 수 분(minutes) + + 마이크로초 (usec.)

msec.


접속 회선의 전송률 증가 시 큰 비용 필요 !!



웹 캐시 예 – 캐시 추가

기관 웹 캐시 설치

• 요청의 40%는 히트라고 가정

이용율(utilization)과 지연

• 요청의 60%만 접속 회선을 이용하므로회선 이용율 60%

• 80% 미만의 이용율의 경우 접속회선지연은 수십 밀리초 소요(10ms 라 가정)

• 전체 지연인터넷 지연 + 접속 회선 지연 + LAN 지연= 0.6 x (2초+0.01초) +

0.4 x 마이크로 초 (usec.) = ~ 1.2 초

150Mbps 접속회선 전송률 증가보다도 빠르면서 저렴 !!!




조건부 GET (Conditional GET)

조건부 GET은 웹 캐시의객체들이 최신 버전이면서버가 객체를 보내지 않음

• 캐시는 HTTP 요청에 캐시된복사본의 시간을 명시If-modified-since: <date>

• 서버는 캐시된 복사본이 최신의 것이면 객체가 생략된응답을 전송HTTP/1.0 304 Not Modified




REST 소개

REST (REpresentational State Transfer) 아키텍처• 웹을 활용한 분산 시스템 소프트웨어 아키텍처

• URI로 자원을 기술하고, HTTP로 전송

• HTTP 메서드로 자원의 제어, 명령의 결과는 XML, JSON 등으로 응답

• 2000년 Roy Fielding의 박사학위 논문에서 제안

순천향대학교 컴퓨터공학과 이 상 정 47



REST 소개 – HTTP 메서드

자원에 대한 명령은 CRUD로 압축• C : Create. 자원을 생성, SQL의 Insert

• R : Read. 자원의 정보를 읽기, SQL의 Select

• U : Update. 자원의 정보를 업데이트, SQL의 Update

• D : Delete. 자원의 삭제, SQL의 Delete

REST는 HTTP 메서드로 원격의 자원을 제어하는 명령을 기술• C: POST, R: GET, U: PUT, D: DELETE

명령의 결과 데이터는 HTTP 바디(body)로 전송• 데이터 형식은 XML, JSON 등으로 표현




REST 예 - 사용자 정보 조회

REST API로 사용자 정보 조회• JSON으로 전송




실습 과제 2-2: HTTP, Wireshark 실습

Wireshark를 다운로드 받아 설치• Wireshark 강의 노트 참조

브라우저를 통해 특정 웹 사이트를 방문한 후 Wireshark를 실행하여 HTTP 패킷을 캡처하고 분석• 방문하는 웹 사이트는 다른 사람과 중복되지 않아야 함

• 캡처된 내용 저장하여 제출

“디스플레이 필터”에 http 입력하여 http 메시지만 디스플레이• http && ip.addr == 주소

• HTTP 프로토콜과 해당 IP 주소 포함된 패킷만 표시

캡처된 내용의 분석• 방식(method), 헤더 내용 등

• 상태코드, HTML 파일 등






2.2 웹과 HTTP









전자메일 (Electronic Mail)


3개 주요 요소• 사용자 에이전트 (user agents)

• 메일 서버 (mail server)

• SMTP (Simple Mail Transfer Protocol)

사용자 에이전트• 메일 리더(mail reader)라고도 함

• 메시지를 읽고, 작성하고, 보내고, 전달

• MS Outlook, Mozilla Thunderbird 등

• 송수신 메시지는 서버에 저장



전자메일: 메일 서버

메일 서버 (mail server)• 받은 메시지를 유지하고 관리하는

메일박스(mail box)

• 보내는 메시지의 메시지 큐(message queue)

• 메일 서버들 간의 SMTP 프로토콜

• 클라이언트: 보내는 메일 서버

• 서버: 받는 메일 서버




전자메일: SMTP [RFC 2821]

클라이언트의 메일 메시지를 25번 포트의 TCP 연결• 보내는 서버에서 받는 서버로 직접 전송

3단계 전송 과정• 핸드세이킹

• 메시지 전송

• 종료

명령/응답 상호 작용• 명령: ASCII 문자

• 응답: 상태 코드와 문장

메시지는 7-비트 ASCII이어야 함




시나리오: 앨리스가 밥에게 메시지 전송

1. 앨리스는 사용자 에이전트(UA)를 사용하여 밥에게 보낼

메시지를 작성

2. 앨리스의 UA는 메시지를 메일서버에 보냄. 메시지는 서버의 메시지큐에 놓임

3. SMTP의 클라이언트는 밥의 메일 서버로 TCP 연결 설정

4. SMTP의 클라이언트는 TCP 연결로 앨리스의 메시지를 보냄

5. 밥의 메일서버는 메시지를 메일박스에 놓음

6. 밥의 UA는 메시지를 읽음




SMTP 상호동작 예

S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... Recipient ok C: DATAS: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUITS: 221 hamburger.edu closing connection




SMTP 상호동작 실습

텔넷을 사용하여 SMTP 서버와 직접 대화• 사용자 에이전트를 사용하지 않고 메일을 전송

telnet servername 25

서버로 부터 220 응답을 확인

SMTP 명령 HELO, MAIL FROM, RCPT TO, DATA, QUIT 을사용하여 입력

위 과정을 프로그래밍하면 메일 클라이언트의 사용자 에이전트• p.166 프로그래밍 문제 3




SMTP 특징

SMTP는 지속 연결을 사용

SMTP 메시지(헤더 & 몸체)는 7-비트 ASCII로 표시

SMTP 서버는 메시지의 끝을 CRLF.CRLF 로 표시

HTTP와 비교• HTTP: 풀(pull) 프로토콜

• SMTP: 푸시(push) 프로토콜

• 모두 ASCII 명령/응답 상호 작용을 하고 응답 코드를 가짐

• HTTP: 각 객체는 응답 메시지에 캡슐화

• SMTP: 모든 메시지의 객체를 한 메시지로 만듬




메일 메시지 포맷 (Mail Message Format)


SMTP: 전자메일 메시지를 주고받는 프로토콜

RFC 822: 텍스트 메시지 포맷의표준

헤더 라인, e.g.,

• To:

• From:

• Subject:

SMTP 명령과는 다름!

몸체

• ASCII 문자의 메시지

header

body

blankline



MIME (Multipurpose Internet Mail Extensions)

ASCII가 아닌 데이터를 메일로 전송 시 사용되는 RFC 822의 확장• 비 ASCII 텍스트 메시지(이미지,오디오,비디오, 다국적 언어 등)는

SMTP가 이해하는 ASCII 포맷으로 인코딩

• RFC 2045, 2046에 추가 헤더 정의

• Content-Transfer-Encoding: 인코딩된 코드 타입 기술

• Content-Type: 메시지 몸체의 타입을 기술


NVT(Network Virtual terminal)



MIME 메시지 예

앨리스가 밥에게 JPEG 이미지를 전송하는 예

From: [email protected]

To: [email protected]

Subject: Picture of yummy crepe.

MIME-Version: 1.0

Content-Transfer-Encoding: base64

Content-Type: image/jpeg

(base64 인코딩 데이터 ………………………………………………………………………………………………………………………

………………………………… base64 인코딩 데이터)




Base64 인코딩

RFC 1421

인코딩 절차• 8 비트 3 개를 6 비트 4개로 변형

• 각 6비트가 64개의 출력가능 문자를 인덱스




Base64 인코딩 예




메일 접속 프로토콜(Mail Access Protocol)

SMTP는 수신자의 서버에 메시지를 전송하고 저장

메일 접속 프로토콜이 서버로부터 메시지를 추출• POP: Post Office Protocol [RFC 1939]

• 인증(에이전트 <--> 서버)과 다운로드

• IMAP: Internet Mail Access Protocol [RFC 1730]

• POP 보다 다양한 특성을 갖고 복잡함

• 서버에 저장된 메시지를 관리

• HTTP

• gmail, Hotmail, Yahoo! Mail, etc.




POP3 프로토콜


인증(authorization )

클라이언트 명령:

• user: 사용자 이름

• pass: 비밀번호

서버 응답

• +OK

• -ERR

트랜잭션(transaction), client:

list: 메시지 번호를 나열

retr: 지정된 번호의 메시지

를 추출

dele: 삭제

quit

C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents>S: . C: dele 1 C: retr 2 S: <message 1 contents>S: . C: dele 2 C: quit S: +OK POP3 server signing off

S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on



POP3와 IMAP

POP3• 앞의 예는 다운로드와 삭제

(download-delete) 모드를사용

• 밥은 클라이언트가 바뀌면(PC에서 스마트폰) 다시메일을 읽을 수 없음

• 다운로드 및 유지(download-keep) 모드를사용하여 여러 클라이언트에 메시지의 복사해야 함

• POP3는 세션 간 상태를유지하지 않음(stateless)


IMAP• 모든 메시지를 서버 한 장소에

보관

• 사용자가 메시지를 (원격) 폴더로저장하고 구성 가능

• 세션 간에 사용자 상태 정보를유지

• 폴더의 이름과 어떤 메시지가어떤 폴더와 연결되어 있는가를 유지





2.2 웹과 HTTP









DNS (Domain Name System)

사람은 여러 방식을 자신을 식별• 이름, 주민등록번호, 운전면허번호, 여권번호

인터넷 호스트, 라우터• IP 주소 (32비트 주소, IPv4)

• 호스트 네임(hostname), www.sch.ac.kr

DNS (Domain Name System)• 호스트 네임을 IP 주소 변환하는 디렉터리 서비스

• DNS 서버들이 계층구조로 구현된 분산 데이터베이스 (distributed database)

• 호스트가 분산 데이터베이스로 질의하여 호스트 네임에서 IP 주소를획득하는 애플리케이션 계층 프로토콜




DNS 서비스

호스트 네임을 IP 주소로 변환

호스트 에일리어싱 (host aliasing)• 간단한 별칭 호스트 네임(enterprise.com)을 복잡한 정식 호스트 네임

(canonical host name, relay1.west-coast.enetrprise.com)으로 변환

메일 서버 에일리어싱 (mail server aliasing)

부하 분산 (load distribution)

• 여러 IP 주소들이 하나의 정식 호스트 네임과 연관되는 중복 웹 서버(replicated Web server)

• 중복 웹 서버에서는 서버들이 부하 분산

단일 중앙 집중 방식 DNS를 사용하지 않는 이유

• 서버 고장 시 전체 작동하지 않음

• 트래픽 양

• 먼 거리의 중앙 집중 데이터베이스

• 유지관리




DNS -분산 계층 데이터베이스(Distributed, Hierarchical Database

DNS 클라이언트가 www.amazon.com 호스트 네임의 IP 주

소를 질의 과정1. com의 DNS 서버를 찾기 위해 루트(root) 서버에 질의

2. amazon.com의 DNS 서버 주소를 위해 com의 DNS 서버(TLD 서버, top-level domain server)에 질의

3. www.amazon.com의 IP 주소를 얻기 위해 amazon.com의 DNS 서

버(책임 서버, authoritative server)에 질의




DNS - 루트 DNS 서버

질의된 호스트 네임을 해결하지 못한(IP 주소를 알지 못하는) 로컬 DNS 서버가 접촉

인터넷에서는 전세계에 13개의 루트 DNS 서버




TLD와 책임 DNS 서버

TLD (Top-Level Domain) 서버• com, org, net, edu 같은 상위 레벨 도메인과 kr, uk, fr, jp 등과 같은

국가의 상위 레벨 도메인에 대해 책임

• Network Solutions 사가 com의 TLD 서버를 관리

• Educause가 edu의 TLD 서버 관리

책임 DNS 서버• 기관(회사, 대학 등)의 서버(웹 서버, 메일 서버 등)의 호스트 네임을

IP 주소 매핑

• 기관이나 서비스 제공자 등이 서버를 관리




로컬 DNS 서버 (Local DNS Server)

로컬 네임 서버는 DNS 계층에 속하지 않음

각 ISP(가정 ISP, 회사, 대학)는 로컬 DNS 서버를 가짐• 디폴트 네임 서버(default name server)라고도 함

호스트가 DNS 질의를 하면 로컬 DNS 서버로 질의가 전송• 프록시와 같은 역할을 하며 질의를 계층으로 전달




DNS 동작 예 (1)

호스트 cis.poly.edu는gaia.cs.umass.edu의

IP 주소를 질의

반복적 질의(iterative query)• 접촉된 서버가 연결할 서버의

주소로 응답

• "이 이름의 IP 주소는 모르지만 이 서버에 질의해 보아라"




DNS 동작 예 (2)

재귀적 질의(recursive query)• 이름에 대한 해결(name

resolution)을 접촉한 서버에부담

• 상위 계층 서버에 많은 부담




DNS 캐싱 (DNS Caching)

DNS 서버가 어떤 이름에 대한 받은 응답 정보를 저장(caching)• 캐싱된 정보는 일정 시간이 지나면 소멸

• 일반적으로 로컬 DNS 서버에 TLD 서버들이 캐싱

• 따라서 루트 DNS 서버는 자주 방문하지 않음

IETF의 갱신/알림(update/modify) 메커니즘• RFC 2136

• http://www.ietf.org/html.charters/dnsind-charter.html




DNS 레코드 (DNS Record)

DNS는 자원 레코드(resource record, RR)를 저장하는 분산데이터베이스


Type=NS (Name Server)• name은 도메인

(e.g. foo.com)

• value는 이 도메인에 대한

책임 DNS 서버의 호스트네임

Type=A (host Address)• name은 호스트 네임• value는 IP 주소

Type=CNAME (Canonical NAME)

• name은 별칭(alias) 호스트네임, www.ibm.com

• value는 정식 호스트 네임,servereast.backup2.ibm.com

Type=MX (Mail eXchange)• value 는 별칭 호스트 네임name 을 갖는 메일서버의 정식호스트 네임



DNS 프로토콜, 메시지 (1)

DNS 프로토콜은 같은 메시지 포맷을 갖는 질의(query), 응답(response) 메시지로 구성


메시지 헤더• 식별자(identification)

질의를 식별하는 16비트 식별자

응답 메시지도 질의와같은 식별자를 가짐

• 플래그(flags) 질의/응답 구분 재귀적 질의 요청 재귀적 질의 가능 책임 서버 응답



DNS 프로토콜, 메시지 (2)


질의되는 이름과 타입

질의대한 응답으로 RR

책임 서버에 대한 레코드

추가 도움 정보



DNS 데이터베이스에 레코드 삽입

“Network Unitopia” 새로 설립된 회사 예

DNS 등록기관(registrar, e.g., Network Solutions)에 도메인네임 networkuptopia.com을 등록

• 주 책임 서버와 부 책임 서버의 이름과 IP 주소를 등록기관에 제공(dns1.networkutopia.com, 212.212.212.1)(dns2.networkutopia.com, 212.212.212.2)

• 등록기관은 두 개의 자원 레코드를 com TLD 서버에 등록(networkutopia.com, dns1.networkutopia.com, NS)(dns1.networkutopia.com, 212.212.212.1, A)

책임 DNS 서버에 두 개의 레코드 등록• www.networkuptopia.com을 위한 Type A 레코드• mail.networkuptopia.com을 위한 Type MX 레코드




실습 과제 2-3: DNS, Wireshark 실습

Wireshark를 실행하고 임의의 웹에 접속하여 적용된 DNS 패킷을 확인하고, DNS 프로토콜, 메시지, 레코드를 분석






2.2 웹과 HTTP









순수한 P2P 구조 (Pure P2P Architecture)

항상 켜져 있는 서버 없음

임의의 종단 시스템들이 직접 통신

피어(peer)들은 간헐적으로 연결되며 IP 주소를 변경

예:• 파일 분배: BitTorrent

• 스트리밍: KanKan

• VoIP : Skype




파일 분배: 클라이언트-서버 vs. P2P

한 서버에서 N개의 피어들에 크기 F의 파일 분배 시간은?• 피어들 간의 다운로드/업로드 대역폭(capacity) 한정된 자원




파일 분배 시간: 클라이언트-서버


서버전송: 파일 복사본 N개를 피어들에게 순차적으로 전송

• 1개 복사본 전송 시간: F/us

• N개 복사본 전송 시간: NF/us

클라이언트: 각 클라이언트가 파일을다운로드

• dmin = 가장 낮은 다운로드 속도를갖는 피어의 다운로드 속도

• 가장 낮은 속도 피어의 파일 다운로드 시간: F/dmin

피어 수 N에 따라 선형적으로 증가

Dcs ≥ max { NF/us, F/dmin }클라이언트-서버 방식으로파일 F를 N 클라이언트에분배하는 시간



파일 분배 시간: P2P


서버: 하나의 복사본만 전송

• 1개 복사본 전송 시간: F/us

클라이언트: 각 클라이언트가 파일을 다운로드

• 가장 낮은 속도 피어의 파일다운로드 시간: F/dmin

클라이언트들: 시스템 전체 업로드 용량은 서버 업로드 속도와 각피어 업로드 속도를 더한 것

• 업로드 속도: us + ui

• 최소 분배시간: NF/ (us + ui )

Dp2p ≥ max { F/us, F/dmin , NF/(us + ui) }

피어 수 N에 따라 선형적으로 증가

그러나,각 피어가 분할하여 업로드



클라이언트-서버 vs. P2P: 비교 사례


클라이언트 업로드 속도= u, F/u = 1 hour, us = 10u, dmin ≥ us

0

0.5

1

1.5

2

2.5

3

3.5

0 5 10 15 20 25 30 35

N

Min

imum

Dis

trib

utio

n T

ime P2P

Client-Server



파일 분배 - 비트토렌트(BitTorrent)

파일은 256KB 청크(chunk)로 분할

피어들은 파일 청크를 송수신




비트토렌트(BitTorrent) (1)

토렌트에 가입(joining)하는 피어:• 처음에는 청크가 없지만 시간이 지남에 따라 청크들이 누적됨

• 트랙커로부터 피어들의 리스트를 얻어서, 이들 중 일부와 연결(“이웃 피어”)

청크를 다운로드하는 동안에 다른 피어들에게 업로드

전체 파일을 얻은 후 토렌트를 (이기적으로) 떠나거나 또는 (이타적으로) 남을 수 있음




비트토렌트(BitTorrent) (2)

청크 가져오기(Pulling Chunks)• 임의의 주어진 시간에 서로 다른

피어들이 파일의 서로 다른 청크들을 가지고 있음

• 주기적으로 한 피어(앨리스)는 이웃 피어들에게 각자 가지고 있는청크의 리스트를 요청

• 앨리스는 본인이 가지고 있지 않은 청크를 요청

• 청크를 요청하는 순서

• 이웃들이 가지고 있는 복사본 중가장 드문 것을 먼저(rarest first)요청


청크 보내기: 되갚음(tit-for-tat)

• 현재 가장 속도가 빠른 4개의이웃들에게 청크들을 보냄

매 10초 마다 가장 빠른 4개의 피어 다시 선택

• 매 30초마다 임의로 하나의 피어를 추가 선택하여 청크를 보냄

새로운 선택된 피어가 가장빠른 4개의 피어일 수 있음

모든 이웃이 소외되지 않고낙관적으로 중단 없는 전송(optimistically unchoke)



비트토렌트 - 되갚음(Tit-for-Tat)

1. 앨리스는 밥이 소외되지 않도록 선택 (optimistically unchoke)

2. 앨리스는 밥의 가장 빠른 4개의 제공자가 됨; 밥이 보답을 함

3. 밥이 앨리스의 가장 빠른 4개의 제공자가 됨






2.2 웹과 HTTP









비디오 스트리밍과CDN (Contents Distrinution Network)

비디오 트래픽이 인터넷 대역폭의 주요 소비자가 되고 있음• Netflix, YouTube: 37%

• 가정용 ISP 다운스트림 트래픽의 16% 차지

• ~1B YouTube 사용자, ~75M Netflix 사용자

도전과제• 확장성(scale) - 어떻게 최대 10억명의 사용자에게 전달하는가?

• 하나의 초대형 비디오 서버로 운용할 수 없음

• 이질성(heterogeneity)

• 서로 다른 환경의 서로 다른 사용자들

– 무선 대 유선 사용자, 높은 대역폭의 사용자 대 낮은 대역폭의 사용자)

해결책• 분산화된, 응용-수준의 인프라스트럭처




멀티미디어 – 비디오 (Video) (1)

비디오: 일정 속도로 출력되는 일련의 이미지• e.g. 24 이미지/초

디지털 이미지: 픽셀의 배열• 각 픽셀은 일정한 수의 비트로 표현

압축(coding)• 이미지 인코드(encode) 시 이미지 내

와 이미지 간의 중복(redundancy)된내용을 활용

• 공간적(spatial) 중복

• 이미지 내의 중복

• 시간적(temporal) 중복

• 연속된 이미지 간의 중복




멀티미디어 – 비디오 (2)

CBR (constant bit rate)• 비디오 인코딩 속도가 고정

VBR (variable bit rate)• 비디오 인코딩 속도가 공간, 시간적

코딩 변화량에 따라 가변

예• MPEG 1 (CD-ROM) 1.5 Mbps

• MPEG 2 (DVD) 3-6 Mbps

• MPEG 4 (인터넷) , < 1 Mbps




스트리밍 저장 비디오(Streaming Stored Video)




적응적 스트리밍과 DASH (1)

DASH (Dynamic, Adaptive Streaming over HTTP)• 클라이언트들의 가용 대역폭 차이에 따라 서로 다른 품질 수준의

비디오 인코딩을 선택

서버• 비디오 파일을 여러 개의 비디오 조각(chunk)로 분할

• 각 조각은 각기 다른 비트율로 인코드되어 저장

• 목록(manifest) 파일: 각 비트율에 따른 URL를 제공

클라이언트• 주기적으로 서버와 클라이언트 간 대역폭을 측정

• 목록 파일을 참조하여 한 번에 한 조각을 요청

• 현재 가용한 대역폭 하에서 지속할 수 있는 최대 비트율의 인코딩을 선택

• 각 시간대에서 대역폭의 변화에 따라 다른 비트율의 코딩을 선택할 수있음




적응적 스트리밍과 DASH (2)

DASH (Dynamic, Adaptive Streaming over HTTP)

지능적인 클라이언트 동작• 버퍼가 비거나 차있지 않도록 조각의 요청 시점을 결정

• 가용 대역폭을 보면서 요청할 비디오 비트율 결정

• 클라이언트와 가깝거나 또는 높은 가용 대역폭의 URL 서버를 선택하여 비디오 조각을 요청




컨텐츠 분배 네트워크 – 단일 데이터센터(CDN, Contents Distribution Network)

주요 과제: 수 십만의 사용자들에게 수 백만 개의 컨텐츠의스트리밍 서비스를 어떻게 동시에 제공하는가?

옵션 1: 단일한 거대 데이터 센터 구축• 한 번의 장애로 인해 전체 서비스 중단 위험

• 서버가 네트워크 혼잡의 주요 지점

• 지역적으로 먼 클라이언트들에게 긴 경로

• 인기 비디오는 같은 통신 링크 상에서 여러 번 반복 전송

=> 한 마디로 이 방식은 확장성이 없음 (doesn’t scale)




컨텐츠 분배 네트워크 (CDN) – 분산 서버

주요 과제: 수 십만의 사용자들에게 수 백만 개의 컨텐츠의스트리밍 서비스를 어떻게 동시에 제공하는가?

옵션 2: 다수의 지점에 분산된 서버를 운영하여 여러 복사본의 비디오들을 저장 (CDN)• enter deep: CDN 서버들이 세계 곳곳의 ISP 접속 네트워크에 깊숙이

들어가 있도록 배치

• 최대한 사용자 가까이 위치

• Akamai는 1700개의 지점에 서버 클러스터를 구축

• bring home: 접속 네트워크의 (내부가 아닌) 근처 POP(Point of Presence)에 적은 수의 큰 규모 서버 클러스터 구축

• Limelight에 의해 사용




where’s Madmen?manifest file

컨텐츠 분배 네트워크 (CDN) 동작

CDN: CDN 노드들에 컨텐츠의 복사본들을 저장• e.g. Netflix는 ‘MadMen’의 복사본들을 저장

가입자는 CDN의 컨텐츠를 요청• 가까운 노드로의 연결 유도되어 컨텐츠를 수신

• 네트워크의 경로가 혼잡하면 다른 복사본의 노드 선택



Internet host-host communication as a service

“over the top”

OTT 도전과제 : 인터넷 혼잡에 대한 대처• 어느 CDN 노드에서 컨텐츠를 받을 것인가?

• 혼잡 시에 시청자들의 반응은?

• 어느 노드에 어떤 컨텐츠를 배치할 것인가?• OTT(Over The Top) 서비스는 인터넷을 통해 영화등 미디어 컨텐츠를 제공하는 서비스를 말함

컨텐츠 분배 네트워크 (CDN) – OTT 서비스



CDN 컨텐츠 접근 동작

Bob (클라이언트)은 http://netcinema.com/6Y7B23V 에 비디오를 요청

• 비디오는 http://KingCDN.com/NetC6y&B23V 의 CDN에 저장


netcinema.com

KingCDN.com

1

1. Bob은 netcinema.com 웹 페이지에서 비디오의 URL 얻음http://netcinema.com/6Y7B23V

2

2. Bob의 로컬 DNS를 통해http://netcinema.com/6Y7B23V를 질의

netcinema’sauthorative DNS

4

4&5. KingCDN의 책임 DNS 서버에http://KingCDN.com/NetC6y&B23 를질의하여 비디오가 KIingCDN 의 IP 주소를리턴

6. KINGCDN 서버에비디오를 요청,HTTP로 스트리밍서비스

3. netcinema’s 책임 DNS는 URL http://KingCDN.com/NetC6y&B23V 를리턴

3

5

KingCDNauthoritative DNS

Bob’s local DNSserver



사례 연구 – Netflix (1)

미국의 선도적인 온라인 영화 및 TV 서비스 공급자

자신의 고유한 인프라스트럭처를 소유하지 않고 제3자의서비스(서버, 대역폭, 저장공간, 데이터베이스) 이용• 자신의 등록 및 과금 서버 운용

• Amazon (3rd party) 클라우드 서비스 이용

• Netflix 영화의 스튜디오 마스터 버전을 Amazon 클라우드에 업로드

• 다른 인코딩 비트율을 갖는 여러 가지 형식의 영화를 클라우드에 생성

• 클라우드에서 CDN으로 여러 버전의 영화를 업로드

• 제3자 CDN 서비스 동시 활용

• Akamai, Limelight, Level-3




사례 연구 – Netflix (2)


2. Bob은 Netflix비디오를브라우징

1

1. Bob은 Netflix 계정을개설하고 관리

Netflix 등록 및과금 서버

Amazon cloud

Akamai CDN

Limelight CDN

Level-3 CDN

23

3. 요청한 비디오 의manifest 파일을리턴

4. DASH 스트리밍

비디오의 여러 버전들을CDN 으로 업로드

manifest 파일: CDN 순위리스트, DASH의 다양한 버전 비디오의 URL 정보 등 포함





2.2 웹과 HTTP









소켓 프로그래밍 (Socket Programming) (1)

소켓(socket)을 사용하여 클라이언트/서버 응용을 구축하는방법 소개

소켓(socket)• 애플리케이션 프로세스와 종단 간 트랜스포트 프로토콜 사이의 인터

페이스




소켓 프로그래밍 (2)

두 가지 형태의 트랜스포트 서비스• UDP: 비연결형, 비신뢰적인 데이터 전송

• TCP: 연결형, 신뢰적인 데이터 전송

애플리케이션 예1. 클라이언트는 키보드로 한 줄의 문자(데이터)를 읽고, 그 데이터를

서버로 송신

2. 서버는 데이터를 수신하고, 문자를 대문자로 변환

3. 서버는 수정된 데이터를 클라이언트에게 송신

4. 클라이언트는 수정된 데이터를 수신하고 화면에 출력




UDP 소켓 프로그래밍

UDP는 클라이언트와 서버 사이에 비연결형(no connection) 서비스• 초기 핸드셰이킹 과정 없음

• 송신 프로세스는 각 패킷 마다 수신 프로세스의 IP와 포트 번호를 명시해야 함

• 서버는 수신된 패킷에서 IP 주소와 포트 번호를 추출해야 함

UDP는 비신뢰적인 전송 서비스를 제공하여 전송된 데이터의 순서가 뒤바뀌거나 데이터를 손실할 수도 있음


애플리케이션 관점

UDP 는 클라이언트와 서버 사이에바이트들 그룹(“데이터그램”)의

비신뢰적인 전송을 제공



UDP 클라이언트/서버 소켓 상호동작




UDP 클라이언트 프로그램 예 – 파이썬




UDP 서버 프로그램 예 - 파이썬




TCP 소켓 프로그래밍

클라이언트는 서버에 초기 접속

• 서버 프로세스가 먼저 수행 중에 있어야 함

• 서버는 클라이언트의 초기 접속을 처리하는 소켓을 생성해야 함

• 클라이언트는 TCP 소켓을 생성하고, 서버 프로세스의 IP 주소와 포트 번호를명시하여 서버에 접속

• 클라이언트가 소켓을 생성할 때 클라이언트 TCP는 서버 TCP와 연결 설정

클라이언트에 의해 초기 접속 시 서버 TCP는 클라이언트와 통신하는 서버 프로세스를 위한 새로운 소켓(연결 소켓)을 생성

• 서버가 다수의 클라이언트와 통신 가능

• 소스 포트 번호가 클라이언트들을 구분 (3장)


TCP는 클라이언트와 서버 사이에 바이트들의 신뢰적인 전송

(“파이프”)을 제공

애플리케이션 관점



TCP 클라이언트/서버 소켓 상호동작




TCP 클라이언트 프로그램 예 – 파이썬




TCP 서버 프로그램 예 – 파이썬




실습 과제 2-4 / 2-5: 소켓 프로그래밍

실습 과제 2-4• UDP/TCP 클라이언트/서버 예제 프로그램을 작성, 실행한 후 분석

실습 과제 2-5 • 임의의 네트워크 소켓 프로그램 작성, 실행한 후 분석

• 예: 채팅 프로그램, 네트워크 게임, 웹 서버, 메일 클라이언트……

• 사용 언어는 C/C++, Java, Python, C# 등 자유 선택

• 파이썬

• 파이썬 인터프리터 설치 및 언어 사양은 1학년 1학기 강의 참조=> 컴퓨터와 현대기술

• GUI 채팅 프로그램은 1학년 2학기 강의 참조




요약 (Summary) (1)

애플리케이션 구조• 클라이언트/서버

• P2P

애플리케이션 서비스 요구사항• 신뢰성, 처리율(대역폭),

시간(지연)

인터넷 트랜스포트 서비스모델• 연결 지향, 신뢰적: TCP

• 비신뢰적, 데이터그램: UDP


애플리케이션 프로토콜• HTTP

• SMTP, POP, IMAP

• DNS

• P2P: BitTorrent, DHT

비디오 스트리밍, CDN

소켓 프로그래밍• TCP, UDP 소켓



요약 (Summary) (2)

네트워크의 중요한 개념인 프로토콜 학습

요청/응답 메시지 교환• 클라이언트가 정보 또는 서

비스를 요청

• 서버는 데이터, 상태 코드를 응답

메시지 포맷• 헤더: 데이터에 관한 정보

를 기술한 필드

• 데이터: 통신되는 정보


주요 이슈

• contorl vs. data msgs

• in-band, out-of-band

• in-band는 동일 채널로 전송=> HTTP

• out-of-band는 다른 채널로전송 => FTP

• centralized vs. decentralized

• stateless vs. stateful

• reliable vs. unreliable msgtransfer

• “complexity at network edge”



실습 과제 2-1:HTTP, curl 적용하여 메시지 확인

특정 웹 서버에 curl로 접속하여 GET HTTP 요청을 입력한후 응답 메시지를 확인• 방문하는 웹 사이트는 다른 사람과 중복되지 말아야 함

참고: curl• 명령행 데이터 전송 도구 (command line data transfer tool)

• HTTP/HTTPS/FTP/LDAP/SCP/TELNET/SMTP/POP3 등 주요한 프로토콜을 지원

• C 언어 기반 libcurl 라이브러리 제공

• https://curl.haxx.se/




실습 과제 2-2: HTTP, Wireshark 실습

Wireshark를 다운로드 받아 설치

브라우저를 통해 특정 웹 사이트를 방문한 후 Wireshark를실행하여 HTTP 패킷을 캡처하고 분석• 방문하는 웹 사이트는 다른 사람과 중복되지 않아야 함

“디스플레이 필터”에 http 입력하여 http 메시지만 디스플레이

캡처된 내용을 분석• 방식(method), 헤더 내용 등

• 상태코드, HTML 파일 등




실습 과제 2-3: DNS, Wireshark 실습

Wireshark를 실행하고 임의의 웹에 접속하여 적용된 DNS 패킷을 확인하고, DNS 프로토콜, 메시지, 레코드를 분석




실습 과제 2-4 / 2-5: 소켓 프로그래밍

실습 과제 2-4• UDP/TCP 클라이언트/서버 예제 프로그램을 작성, 실행한 후 분석

실습 과제 2-5 • 임의의 네트워크 소켓 프로그램 작성, 실행한 후 분석

• 예: 채팅 프로그램, 네트워크 게임, 웹 서버, 메일 클라이언트……

• 사용 언어는 C/C++, Java, Python, C# 등 자유 선택

• 파이썬

• 파이썬 인터프리터 설치 및 언어 사양은 1학년 1학기 강의 참조=> 컴퓨터와 현대기술

• GUI 채팅 프로그램은 1학년 2학기 강의 참조


Documents

2장. 애플리케이션계층 (Application Layer)cs.sch.ac.kr/lecture/Network/Network-2017/17-2-Network-Applicatio… · 순천향대학교컴퓨터공학과 1 2장. 애플리케이션계층