[네트워크] 어플리케이션 계층

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

• 네트워크 어플리케이션은 다른 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것

네트워크 어플리케이션의 구조

클라이이언트-서버

• 서버 : 항상 켜져있는 호스트
• 고정된 아이피 주소를 지님
• 클라이언트 : 가끔 켜져 있는 호스트로 서버와 통신을 함
• 유동적인 아이피 주소를 지님
• 클라이언트 호스트끼리는 통신하지 않음
• Ex) 웹, 파일전송, 원격 로그인, 전자메일

P2P

• P2P : Peer To Peer 구조
• 항상 켜져 있는 기반 구조 서버에 최소한으로 의존 혹은 사용 X
• 피어라는 간헐적으로 연결된 호스트끼리 직접 통신
• 자가 확장성을 지니나 다루기 어려움
• Ex) 토렌트

클라이어언트-서버 구조 P2P의 혼합

• 스카이프 : 목소리 기반의 P2P 어플리케이션
• 서버 : 각 호스트들의 주소를 찾아줌
• 클라이언트 끼리 직접 연결 (서버를 통하지 않음)
• 인스턴트 메세지 : 두 사용자간의 채팅
• 서버 : 각 호스트들의 주소를 찾아줌
• 사용자들은 서버에 아이피를 등록하고 서버에서 다른 사람의 아이피 주소를 찾음

프로세스 간 통신

• 프로세스 : 호스트 안에서 실행되는 프로그램
• 같은 호스트안에서 프로세스간의 통신은 OS에 의해 결정
• 다른 호스트에 있는 프로세스간의 통신은 메시지 교환을 통해 이루어짐
• 클라이언트 프로세스 : 통신을 초기화하는 프로세스
• 서버 프로세스 : 세션을 시작하기 위해 접속을 기다리는 프로세스
• P2P 구조에서는 프로세스가 서버, 클라이언트 둘다 가능

소켓

• 프로세스는 소켓을 통해 네트워크로 메시지를 주고 받음
• 프로세스는 집이고 소켓은 출입구라 비유 가능
• 프로세스가 메시지를 다른 호스트의 프로세스로 보낼 때 소켓으로 메시지를 밀어 넣고 수신 프로세스의 소켓 안으로 들어감
• 소켓은 호스트의 어플리케이션과 트랜스포트 계층간의 인터페이스
• 어플리케이션 개발자는 소켓의 어플리케이션 계층에 대한 모든 권한을 지니나 트랜스포트 계층의 대한 통제권을 갖지 못함
• 1) 트랜스포트 프로토콜의 선택
• 2) 최대 버퍼와 최대 세그먼트 크기와 같은 약간의 매개변수 설정

프로세스 주소 배정

• 메세지를 받기 위해 프로세스는 주소를 지니고 있어야 함
• 호스트는 32비트로 된 아이피 주소를 지님
• 수신 프로세스를 식별하기 위해 두가지 정보가 필요
• 호스트의 아이피 주소 ,그 목적지 호스트 내의 수신 프로세스를 명시하는 식별자
• 포트번호를 통해 프로세스의 주소를 식별
• Ex) HTTP : 80, Mail : 25

어플리케이션이 이용 가능한 트랜스포트 서비스

• 여러가지 트랜스포트 프로토콜의 하나를 선택해야 함

트랜스포트 프로토콜 선택 기준

• 신뢰적 데이터 전송 제공
• 처리량
• 시간
• 보안

인터넷 전송 프로토콜이 제공하는 서비스

TCP

• 연결지향형 서비스
• 메시지를 전송하기 전 클라이언트와 서버가 전송 제어 정보를 교환
• 이 핸드셰이킹 과정이 클라이언트와 서버에 곧 패킷이 도달할것 이라고 알려줌
• 핸드셰이킹 단계를 지나면 TCP 연결이 두 프로세스 소켓 사이에 존재
• 신뢰적인 데이터 전송 서비스
• 혼잡제어 방식 : 통신하는 프로세스의 직접 이득보다 인터넷의 전체 성능 향상을 고려
• 네트워크가 혼잡상태에 이르면 프로세스 속도를 낮춤

UDP

• 최소의 서비스 모델을 지닌 간단한 전송 프로토콜
• 비연결형 : 핸드셰이킹을 하지 않음
• 비 신뢰적인 데이터 전송
• 혼잡제어 방식을 지니지 않음
• 원하는 속도로 데이터를 보낼 수 있음

웹과 HTTP

HTTP 개요

• HTTP : hypertext transfer protocol
• 웹 어플리케이션 계층 프로토콜
• 클라이언트/서버 모델
• 클라이언트 : 브라우저
• 서버 : 웹서버

TCP 전송 프로토콜

• 클라이언트가 서버의 80번 포트로 TCP 연결을 시작 (소켓 생성)
• 서버는 TCP 연결을 수락
• HTTP 메세지가 브라우저와 웹 서버 사이에서 교환
• TCP 연결이 닫힘
• HTTP는 상태를 저장하지 않음
• 서버는 지난 클라이언트 요청에 대한 정보를 지니지 않음

비지속 연결과 지속 연결

• 비지속 연결 : 각 TCP 연결은 하나의 객체만 전송
• 지속 연결 : 여러가지 객체들이 하나의 TCP 연결을 통해 보내짐

비지속 연결 HTTP

웹페이지를 서버에서 클라이언트로 전송하는 단계를 살펴보자
URL : www.naver.com

• HTTP 클라이언트가 HTTP의 기본 포트 번호 80을 통해 www.naver.com 서버로 TCP 연결을 시도
• TCP 연결과 관련하여 클라이언트와 서버에 각각 소켓이 있게 됨
• HTTP 클라이언트는 1단계에서 설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메세지를 보냄(URL 정보 포함)
• 메세지는 클라이언트가 어떤 객체를 원한다는것을 알려줌
• HTTP 서버는 1단계에서 연결된 연결 소켓을 통해 요청 메세지를 받음
• 저장장치로부터 특정 객체를 추출한 후 HTTP 응답 메세지에 그 객체를 캡슐화한 후 소켓을 통해 클라이언트로 전송
• HTTP 서버는 TCP연결을 끊음 (실제로는 클라이언트가 응답 메세지를 제대로 받으면 끊음)
• HTTP 클라이언트가 응답 메세지를 받으면 TCP 연결을 중단
• 참조된 객체의 수 만큼 앞의 과정을 반복

RTT : Round Trip time, 작은 패킷이 클라이언트로부터 서버로 가고 다시 클라이언트로 되돌아 오는 시간

• 총 응답시간 : 2 RTT + HTML 파일을 서버가 전송하는 시간

지속 연결 HTTP

비지속 연결의 단점

• 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 함
• 수많은 다른 클라이언트의 요청을 동시에 서비스하는 웹 서버에 부담
• 각 객체는 2RTT를 필요로 함

지속 연결

• 서버는 응답메세지를 보내고 연결을 계속 유지함
• 같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내짐
• 각 객체마다 1RTT를 필요로 함

HTTP 메세지 포맷

HTTP 요청 메시지

• 요청 라인, 헤드 라인, 바디로 구성
• 요청 라인 : method 필드, URL 필드, HTTP 버전 필드
• 헤드 라인 : Host, Connection, User-agent, Accept-language

Method 필드

• POST : 바디에 정보를 넣어서 서버로 보냄 ( 생성 )
• GET : 정보 조회, 요청
• PUT : 웹 서버에 업로드할 객체를 필요로 하는 어플리케이션에 의해 사용( 수정 )
• DELETE : 웹 서버에 있는 객체를 지움

HTTP 응답 메세지

HTTP 응답 상태 코드

• 200 : OK
• 300 : 요청 객체가 영원히 이동되었다. 새로운 URL은 응답메세지 Location 헤더에 나와있음
• 400 : Bad Request - 서버가 요청을 이해할 수 없음
• 404 : Not Found
• 505 : 요청 HTTP 프로토콜 버전을 지원하지 않음

쿠키

• HTTP 서버는 상태를 유지하지 않음
• 사이트가 사용자를 추적할 수 있도록 해줌
• 4가지 요소 : HTTP 응답 메시지 쿠키 헤더 라인, HTTP 요청 메시지 쿠키 헤더 라인, 브라우저에 남아있는 쿠키 파일, 백엔드 데이터베이스

쿠키가 동작하는 방식

• 사용자가 서버에 요청
• 서버가 사용자에 대한 ID 1678 생성
• 데이터베이스 안에 인덱스 되는 엔트리 생성
• Set-cookie 헤더에 1678을 포함시켜 응답
• 사용자가 다시 서버에 요청을 할 때 cookie 헤더라인에 1678 포함
• 사용자 세션 기간 동안 사용자 식별 가능

FTP

파일 전송 프로토콜

• FTP : File Transfer Protocol
• 클라이언트 : 전송을 시작하는 호스트
• 서버 : 떨어져 있는 호스트
• ftp server : port 21,20

FTP 예시

• FTP 클라이언트가 FTP 서버의 21번 포트에 TCP를 통해 연결 요청
• 클라이언트가 연결을 허가 받음
• 클라이언트가 제어 연결을 통해 폴더 탐색 명령을 보냄
• 서버가 명령을 받으면 서버는 20번 포트를 통해 두번째 TCP 연결을 함
• 파일 전송이 끝나면 data connection을 닫음
• 새로운 파일을 전솔하려면 다시 data connection 연결
• 작업을 모두 마치면 control connection 종료

인터넷 전자메일

전자메일

• 3가지 구성 요소 : 사용자 에이전트, 메일 서버, SMTP
• 사용자 에이전트 : 메일을 생성하고, 수정하고 읽음
• 메일 서버 : 메일 박스(수신), 메시지 큐(송신)를 지님
• SMTP : Simple Mail Transfer Protocol
• 25번 포트 사용
• 3가지 과정 : 핸드셰이킹, 메세지 전송, 중단
• 송신자의 메일서버로부터 수신자의 메일서버로 메시지 전송

SMTP

• 모든 메일 메시지의 몸체는 7비트 ASCII여야 함
• 송신 메일 서버가 파일을 수신 메일 서버로 보내는 Push 프로토콜
• 모든 메시지의 객체를 한 메시지로 만듬

메일 접속 프로토콜

• IMAP : Internet Mail Access Protocol
• HTTP : gmail, Hotmail, Yahoo
• POP : Post Office Protocol
• 메일서버에서 로컬 컴퓨터로 메일을 보낼 때 사용되는 프로토콜

DNS

• 인터넷 호스트와 라우터는 IP 주소와 이름 두가지 식별자를 지님
• 사람들은 호스트 네임을 더 선호하고 라우터는 IP 주소를 선호
• DNS : 호스트 네임을 IP 주소로 변환

DNS가 제공하는 서비스

• DNS : Domain Name Server
• DNS 서버들의 계층구조로 구현된 분산 데이터베이스
• 호스트가 분산 데이터베이스로 질의하도록 허락하는 어플리케이션 계층 프로토콜
• 주로 UDP상에서 수행되며 포트 번호 53번 사용

클라이언트가 URL을 요청할 때 일어나는 일

• 같은 사용자 컴퓨터는 DNS 어플리케이션의 클라이언트 측을 수행
• 브라우저는 URL로부터 호스트 네임 www.someschool.edu를 추출하고 그 호스트 네임을 DNS 어플리케이션의 클라이언트 측에 넘김
• DNS 클라이언트는 DNS 서버로 호스트 네임을 포함하는 질의를 보냄
• DNS 클라이언트는 결국 호스트 네임에 대한 IP 주소를 가진 응답을 받음
• 브라우저가 DNS로부터 IP 주소를 받으면 브라우저는 그 IP 주소와 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결 초기화

DNS가 추가로 제공하는 서비스

• 호스트 엘리어싱 : 복잡한 호스트 네임을 가진 호스트는 하나 이상의 별명을 지닐 수 있음
• 메일 서버 엘리어싱
• 부하 분산 : 중복 웹 서버는 여러 IP 주소가 하나의 정식 호스트 네임과 연관

DNS의 동작 원리

개요

• 어떤 어플리케이션이 호스트 네임을 IP 주소로 변환시키려 함
• 어플리케이션이 변환될 호스트 네임을 명시하여 DNS측의 클라이언트 호출
• 사용자 호스트의 DNS는 네트워크에 질의 메시지를 보냄
• 모든 DNS 질의와 응답은 포트 53의 UDP 데이터그램으로 보내짐
• 사용자 호스트는 DNS 응답 메시지를 받음

분산 계층 데이터베이스

• 클라이언트는 www.amazon.com 의 아이피를 원함
• com DNS 서버를 찾기 위해 루트 DNS 서버에 질의
• amazon.com DNS 서버를 찾기 위해 com DNS 서버에 질의
• www.amazon.com DNS 서버를 찾기 위해 amazon.com DNS 서버에 질의
• www.amazon.com DNS 서버에서 아이피 정보를 받음

루트 DNS 서버

• 인터넷에서 400개 이상의 루트 DNS 서버가 존재하며 대부분 북미지역에 위치
• TLD 서버에 대한 IP 주소 제공

최상위 레벨 도메인(TLD) 서버

• Top-level-Domain
• com,org,net,edu 같은 상위 레벨 도메인 서버
• kr,uk,fr,ca,jp 같은 모든 국가의 상위 레벨 도메인에 대한 TLD 서버 존재
• 책임 DNS 서버에 대한 IP 주소 제공

책임 DNS 서버

• 조직의 DNS 서버는 호스트 네임과 자신의 서버에 대한 IP 주소 정보를 매핑한다
• 대부분의 대학과 큰 기업들은 자신의 기본 책임 DNS 서버와 보조 책임 DNS 서버를 운영

로컬 DNS 서버

• 서버들의 계층구조에는 속하지 않지만 DNS 구조의 중심에 있음
• ISP들은 로컬 DNS서버를 가짐
• 호스트가 DNS 질문 쿼리를 날릴때 로컬 DNS 서버로 날림
• 재귀적 질의, 반복적 질의 두가지 형태로 질문 쿼리를 날림

DNS 캐싱

• DNS는 지연 성능 향상과 네트워크의 DNS 메시지 수를 줄이기 위해 캐싱을 사용
• 로컬 DNS 서버는 TLD 서버의 IP 주소를 저장 가능
• 그래서 주로 루트 DNS 서버를 방문하지 않는 일들이 많이 발생
• 캐시된 내용은 시간이 조금 지나면 사라짐

DNS 레코드와 메시지

• DNS 서버들은 호스트 네임을 IP 주소로 매핑하기 위한 자원 레코드(RR)을 저장
• 각 DNS는 하나 이상의 자원 레코드를 가진 메시지로 응답
• RR 형식 : name, value, type, ttl
• TTL : 자원 레코드의 생존 기간 (자원이 캐시에서 제거되는 시간)
• Type = A : name은 호스트 네임 value는 아이피 주소
• Type = NS : name은 도메인 , value는 책임 DNS 주소
• Type = CNAME : value는 별칭 호스트 네임 name에 대한 정식 호스트 네임
• Type = MX : Value는 별칭 호스트 네임을 갖는 메일 서버의 정식 이름

DNS 메시지

• DNS 프로토콜 : 질의와 응답이 같은 메시지 형식으로 이루어짐
• 헤더 : 식별자, 플래그, 개수 필드 등 12 바이트로 이루어짐
• 식별자 - 질의를 식별하는 16비트 숫자 응답 메시지에 복사되어 질의와 응답의 일치를 식별
• 질의/응답 플래그 - 질의(0), 응답(1)
• 책임 플래그 - DNS 서버가 질의 이름에 대하여 책임 서버일 떄 응답 메시지에 설정
• 재귀 요구 플래그 - DNS 서버가 레코드를 갖지 않을 때 재귀적 질의를 요청
• 재귀 가능 필드 - DNS 서버가 재귀 질의를 지원
• 질문, 답변 RR, 책임 RR, 추가 RR의 수를 나타내는 개수 필드
• 질문 영역 : 질의되는 이름, 질문 타입
• 답변 영역 : 자원 레코드
• 책임 영역 : 다른 책임 서버의 레코드
• 추가 영역 : 다른 도움이 되는 레코드

P2P 파일 분배

• 항상 켜져있는 서버에 최소한으로 의존하거나 의존하지 않음
• 간헐적으로 연결되는 호스트쌍들이 서로 직접 통신
• 호스트들은 아이피를 바꿀 수 있음

파일 분배

• 서버-클라이언트 모델에서는 어떤 피어도 파일을 분배하는 데 도움을 주지않음
• 분배 시간은 피어의 수에 따라 선형적으로 증가
• P2P 모델에서는 각 피어들이 서버가 파일을 분배하는 데 도움을 줌
• 한 피어가 파일 데이터 일부를 수신할 때 피어는 자신의 업로드 용량을 다른 피어들에게 재분배 함
• 피어의 수가 늘어날 수록 서버-클라이언트 모델과 P2P 모델의 파일 분배 시간이 차이가 남

비트토렌트

• 트랙커 : 토렌트에 참여하고 있는 피어들을 추적함
• 토렌트 : 파일 분배에 참여하는 모든 피어들의 모임
• 토렌트에 참여하는 피어들은 서로에게 같은 크기의 청크를 다운로드함
• 피어가 청크를 다운로드 할 때 청크를 다른 피어들에게 업로드 함
• 전체 파일을 얻으면 토렌트를 떠나거나 남아 있을 수 있음
• 서로 다른 피어들이 다른 청크들을 지니고 있음
• 주기적으로 피어는 주변 피어들에게 가지고 있는 청크 리스트를 받음
• 자기가 없는 청크를 가지고 있는 피어에게 요청을 보냄
• 주변 이웃들이 가장 적게 가지고 있는 청크 부터 먼저 요청을 보냄
• 자신에게 빠른 속도로 데이터를 제공하는 이웃에게 우선권을 줌
• 10초마다 속도를 계산하고 상위 4개의 피어들에게 우선권을 줌
• 30초마다 임의의 피어들과 데이터를 주고 받음

소켓 프로그래밍

네트워크 어플리케이션 생성

• 소켓을 사용해 소통하는 서버-클라이언트 모델을 만들기
• 소켓 : 호스트의 어플리케이션과 트랜스포트 계층간의 인터페이스
• 개발자는 우선 TCP, UDP 중 하나를 선택
• TCP : 연결지향형 서비스, 신뢰적 바이트 스트림 제공
• UDP : 비연결형, 전송 보장 X

TCP 소켓 프로그래밍

• 클라이언트가 서버와 데이터를 교환하기 전 TCP 연결을 먼저 설정함(핸드셰이크)
• 서버 프로세스가 먼저 수행 되고 있음
• 서버 프로세스는 클라이언트 프로세스의 접속을 처리하는 (welcome)소켓을 지님
• 클라이언트 프로세스는 TCP 소켓을 생성한 후 서버로 TCP 연결을 시도
• TCP 소켓을 생성할 때 서버의 welcome 소켓의 주소 즉 서버의 아이피 주소와 소켓의 포트 번호를 명시
• 소켓을 생성한 후 세 방향 핸드셰이크를 하고 서버와 TCP 연결을 설정
• 서버는 접속 시도를 받으면 해당 클라이언트에 지정되는 새로운 소켓(연결 소켓) 생성
• 클라이언트 소켓과 연결 소켓은 파이프로 연결되어 바이트를 주고 받음
• TCP는 클라이언트와 서버간의 신뢰적 서비스를 제공

UDP 소켓 프로그래밍

• 핸드셰이킹 과정 x
• 패킷에 도착지와 출발지의 아이피 주소와 포트번호를 명시
• 보내진 패킷들은 순서대로 도착하거나 중간에 없어질 수 있음

요약

• 네트워크 어플리케이션의 개념 및 구현
• 클라이언트 - 서버 패러다임
• HTTP,FTP,SMTP,POP3 프로토콜
• 중요 어플리케이션 계층 프로토콜과 관련된 어플리케이션
• P2P구조
• 소켓 프로그래밍