02 Application Layer

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

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

다른 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것

종단 시스템에만 애플리케이션 소프트웨어가 존재

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

(개발자 관점)

네트워크 구조 : 고정되어 있으며, 애플리케이션에 특정 서비스 집합을 제공

애플리케이션 구조 : 개발자에 의해 설계되고 애플리케이션이 다양한 종단 시스템에서 어떻게 조직되어야 하는지를 지시

• 클라이언트-서버 구조

  : 서버는 항상 켜져있는 호스트, 클라이언트는 가끔 혹은 항상 켜져있을 수 있다.

  클라이언트는 서로 직접적으로 통신하지 않음 서버가 고정 IP주소를 갖음 클라이언트는 서버 주소로 패킷을 보내서 서버에 연결 서버가 모든 요청에 응답할 수 없기에, 데이터 센터를 이용하여 가상서버를 생성

• P2P(peer-to-peer) 구조

  : 항상 켜저 있는 기반구조 서버에 최소로 의존

  애플리케이션은 peer라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하도록 함 peer는 서비스 제공자가 소유하는 것이 아닌, 사용자들이 제어하는 데스크톱/랩톱 **자가 확장성(self-scalability)** 비용 효율적 → 서버 기반구조와 서버 대역폭을 요구하지 않기 때문 분산 구조 특성 → 보안, 성능, 신뢰성에 불확실성

2.1.2 프로세스간 통신

여러 종단 시스템에서 실행하는 프로그램은 서로 통신

실제 통신하는 것은 프로그램이 아니라 프로세스

2개의 다른 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지 교환으로 서로 통신

클라이언트와 서버 프로세스

클라이언트 프로세스 : 통신을 시작하려고 요청하는 프로세스

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

프로세스와 컴퓨터 네트워크 사이의 인터페이스

대부분의 애플리케이션은 메시지를 서로에게 보내는 통신 프로세스 쌍으로 구성

프로세스는 소켓을 통해 네트워크로 메시지를 보내고 받음

소켓 : 호스트의 애플리케이션 계층과 트랜스포트 계층간의 인터페이스

네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스 애플리케이션과 네트워크 사이의 API 개발자는 소켓의 애플리케이션 계층에 대한 모든 권한을 가지나, 트랜트포트 계층의 대한 통제권은 거의 갖지 못함

프로세스 주소 배정

프로세스가 패킷을 다른 호스트의 프로세스로 보내기 위해서는 주소가 필요

수신 프로세스의 식별을 위해서 호스트의 주소와 호스트내의 프로세스 식별자가 필요

⇒ IP 주소와 포트 번호

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

소켓 : 애플리케이션 프로세스와 트랜스포트 프로토콜 간의 인터페이스

트랜스포트 계층 프로토콜이 애플리케이션에게 제공할 수 있는 서비스

• 신뢰적 데이터 전송

  : 프로토콜이 보장된 데이터 전송 서비스를 제공

• 처리량

  : 보장된 가용 처리율을 제공

  처리율 : 네트워크 경로를 따라 두 프로세스간의 통신 세션에서 송신측이 수신측으로 비트를 전달할 수 있는 비율

• 시간

  : 시간보장 제공 → 데이터 전송에 대한 엄격한 시간제한 조건 요구를 가능하게 함

• 보안

  : 보안서비스 제공

  송신 호스트에서 트랜스포트 프로토콜이 전송하는 데이터를 암호화

  수신 호스트에서 트랜스포트 포로토콜이 프로세스로 전송 전에 복호화

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

인터넷은 일반적으로 애플리케이션에게 TCP와 UDP라는 두가지 전송 프로토콜을 제공

TCP (Transmission Control Protocol)

• 연결지향형 서비스 : 메시지 전송전에 클라이언트와 서버가 서로 전송 제어 정보를 교환(핸드셰이킹)
• 신뢰적인 데이터 전송 : 모든 데이터를 오류 없이 올바르게 전송(바이트 스트림을 전달)
• 혼잡 제어

UDP (User Datagram Protocol)

• 가장 간단한 전송 프로토콜
• 비연결형
• 비신뢰적 서비스
• 혼잡 제어 X → 송신 측이 원하는 속도로 데이터 전송

SSL (Secure Sockets Layer)

• TCP와 UDP는 보안기능 제공 X
• SSL은 TCP나 UDP같은 전송 프로토콜이 아님!!!
• 애플리케이션에서 구현되어 TCP를 강화!!
• 클라이언트-서버 양쪽 모두에 SSL코드를 포함해야 함
• 암호화, 데이터 무결성, 종단인증같은 프로세스간의 보안서비스 제공

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

시간과 처리율 보장

→ 애플리케이션이 이러한 보장이 없는 경우에도, 잘 대처할 수 있도록 설계됨

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

다른 종단 시스템에서 실행되는 애플리케이션 프로세스가 서로 메시지를 보내는 방법을 정의

• 교환 메시지 타입 (ex 요청 메시지, 응답 메시지)
• 여러 메시지 타입의 문법 (ex 메시지 내부의 필드와 필드간의 구별 방법)
• 필드의 의미(필드에 있는 정보의 의미)
• 언제 어떻게 프로세스가 메시지를 전송하고 메시지에 응답할지 결정하는 규칙

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

브라우저와 웹 서버 사이에서 교환되는 메시지의 포맷과 순서 결정

SMTP : 전자메일에 대한 주요 애플리케이션 계층 프로토콜

2.1.6 네트워크 애플리케이션

• 웹 : HTTP
• 파일 : FTP
• 전자메일 : 여러 애플리케이션 계층 프로토콜 사용
• 디렉터리 서비스 : DNS
• 비디오 스트리밍 : CDN
• P2P 파일 공유 애플리케이션

2.2 웹과 HTTP

웹은 on-demand 방식으로 작동 → 사용자가 원할 때 원하는 것을 수신

2.2.1 HTTP 개요

메시지 구조 및 클라이언트와 서버가 메시지를 어떻게 교환하는 지에 대해 정의

웹 페이지 : 기본 HTML파일과 여러 참조 객체도 구성

웹 브라우저 : HTTP의 클라이언트측을 구현(ex 익스플로러, 파이어폭스)

요구한 웹 페이지를 보여주고 여러 가지 인터넷 항해와 구성 특성을 제공

웹 서버 : HTTP의 서버측을 구현 (ex 아파치, 마이크로소프트 인터넷 인포메이션 서버)

URL로 각각을 지정할 수 있는 웹 객체를 갖고 있음

HTTP는 TCP를 전송 프로토콜로 사용

HTTP 클라이언트가 먼저 서버에 TCP 연결을 시작

→ 브라우저와 서버 프로세스는 그들의 소켓 인터페이스를 통해 TCP에 접속

→ 클라이언트는 HTTP 요청 메시지를 소켓 인터페이스로 보내고 HTTP 응답 메시지 수신

→ HTTP 서버는 소켓 인터페이스로 요청 메시지를 받고 응답 메시지를 보냄

HTTP는 비상태 프로토콜이다.

⇒ HTTP 서버는 클라이언트에 대한 정보를 유지하지 않아 이전에 한 일을 기억하지 않음

2.2.2 비지속 연결과 지속 연결

비지속 연결 : 각 요구/응답 쌍이 분리된 TCP연결을 통해 보내짐

지속 연결 : 모든 요구와 해당 응답이 같은 TCP 연결상으로 보내짐

▶ HTTP는 둘다 가능

비지속 연결 HTTP

1. HTTP 클라이언트는 HTTP 기본 포트(80)을 통해 서버로 TCP 연결을 시도

2. 앞서 연결된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지를 송신

3. HTTP는 1의 연결소켓을 통해 요청 메시지를 받고 요청에 맞는 객체를 응답메시지에 캡슐화해 응답 메시지를 보냄

4. HTTP 서버는 TCP에게 TCP연결을 끊으라고 지시

5. HTTP 클라이언트가 응답 메시지를 받으면 TCP연결을 중단. 응답메시지에서 추출한 HTML 파일을 조사하고 HTML이 참조하는 객체를 검색

6. 1~4를 반복하여 필요 객체를 참조

   ⇒ 각 요청 객체에 대한 새로운 연결이 설정된다. → 웹서버에 부담을 줌

   각 객체는 TCP연결에 1 RTT, 객체 요청과 수신에 1RTT를 필요로 함

   RTT(round-trip time) : 패킷이 클라이언트에서 서버로 가고 다시 되돌아오는데 걸리는 시간

지속 연결 HTTP

• 서버는 응답을 보낸 후 TCP 연결을 그대로 유지
• 이후의 요청과 응답은 같은 연결을 통해 보내짐
• 객체들에 대한 요구가 진행 요청의 응답을 기다리지 않고 연속해서 보내질 수 있음
• 일반적으로 일정 기간(타임아웃) 사용되지 않으면 연결을 닫음

2.2.3 HTTP 메시지 포맷

HTTP 요청 메시지

request line(start line) + header line + entity body(비어있을 수 있음. 특히 Get method)

request line(start line)

• HTTP 요청 메시지의 첫줄
• method 필드 / URL 필드 / HTTP 버전 필드로 구성
• ex) GET/ somedir/page.html HTTP/1.1

header line

• 해당 요청에 대한 추가정보

• 한줄이 될 수도, 여러 줄이 될 수도 있음

• 웹 프록시 캐시가 필요로 함

• key : value 구조

• ex) Host : www.someschool.edu (target host url)

  Connection : close (요청 완료 후 연결을 끊을지 유지할지)

  User-agent : Mozilla/5.0 (클라이언트에 대한 정보)

  Accept-language : fr (Accept - 요청이 받을 수 있는 응답 타입)

body

• 요청의 실제 메시지/내용
• body가 없는 요청이 많음 (특히 Get method)

HTTP 응답 메시지

status line+ header line + entity body

status line

• HTTP 응답 메시지의 첫줄
• HTTP 버전 필드 / 상태 코드 / 해당 상태 메시지
• ex) HTTP/1.1 200 OK

header line

• 요청 메시지의 header과 동일

• 응답 메시지에서만 사용되는 header가 있음 (User-Agent → Server)

• key : value 구조

• ex) Connection : close (요청 완료 후 연결을 끊을지 유지할지)

  Date : Tue, 18 Aug 2015 15:44:04 GMT (응답이 서버에 의해 생성된 날짜 시간)

  Server : Apache/2.2.3 (서버에 대한 정보)

  Last-Modified : Tue, 18 Aug 2015 15:11:03 GMT (객체의 수정(생성) 날짜 시간)

  Content-Length : 6821 (송신되는 객체의 바이트 수)

  Content-Type : text/html (객체 타입)

entity body

• 요청의 body와 동일
• 데이터를 전송할 필요가 없는 경우, 비어있음

상태코드

• 200 OK : 요청이 성공되었고, 정보다 응답으로 보내졌음
• 301 Moved Permanently : 요청객체가 영원이 이동됨, 새로운 URL은 응답메시지에 포함(Location : 새로운 URL)
• 400 Bad Request : 서버의 요청을 이해할 수 없다는 일반 오류 코드
• 404 Not Found : 요청 문서가 서버에 존재하지 않음
• 505 Http Version Not Supported : 요청 HTTP 버전을 지원하지 않음

2.2.4 사용자와 서버간의 상호작용 : 쿠키

HTTP 서버는 상태를 유지하지 않는다.

서버가 사용자의 정보를 확인하기 위해 쿠키를 사용

정의된 쿠키는 사이트가 사용자를 추적할 수 있도록 함

쿠키의 기술 요소

• HTTP 응답 메시지의 쿠키 헤더 라인
• HTTP 요청 메시지의 쿠키 헤더 라인
• 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
• 웹 사이트의 백엔드 데이터베이스

⇒ 쿠키는 사용자 식별에 사용할 수 있다.

2.2.5 웹 캐싱

웹 캐시(혹은 프록시 서버) : 웹 서버를 대신하여 HTTP 요구를 충족시키는 네트워크 개체

자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장, 보존함

⇒ 클라이언트의 요구에 대한 응답 시간을 줄일 수 있다.

인터넷으로 접속하는 링크상의 웹 트래픽을 대폭으로 줄일 수 있다.

조건부 GET

모든 객체들이 최신의 것임을 확인하면서 캐싱하는 방식

• Get method 사용
• If-Modified-Since : 헤더라인 포함

2.3 인터넷 전자메일

• 사용자 에이전트 : 사용자가 작성한 메시지를 메일 서버에 보냄

• 메일 서버 : 전자 메일 기반구조의 중심으로, 각 사용자의 메일박스를 갖고 있음

  송신자의 메일 서버에서 수신자의 메일 서버내의 수신자 메일 박스에 저장

• SMTP : 전자메일을 위한 주요 애플리케이션 계층 프로토콜

  송신자의 메일 서버에서 수신자의 메일서버로 메시지를 보내기 위해 TCP의 신뢰적인 데이터 전송 서비스를 이용.

2.3.1 SMTP

SMTP는 중간 서버를 거치지 않는다.

즉 송신 메일 서버와 수신 메일서버 사이에서 TCP연결을 통해 직접 연결이 이루어짐

만약 수신 메일 서버가 닫혀있다면, 메시지는 송신 측에 대기 후 새로운 시도를 함

단점 :

• 메일 메시지의 body는 단순한 7비트 ASCII 여야 함
• ASCII 의 제한은 오늘날의 멀티미디어 시대에 문제를 발생
• 멀티미디어 <> ASCII 변환이 필요

2.3.2 SMTP vs HTTP

• 둘 모두 한 호스트에 다른 호스트로 파일을 전송하는 데 이용

• push 프로토콜 vs pull 프로토콜

  : SMTP는 송신측에서 파일을 보내며, TCP연결을 초기화한다.

  반면 HTTP는 누군가 올려놓은 파일을 수신측에서 가져오는 것이며, 수신측에서 TCP연결을 초기화 한다.

• 7비트 ASCII vs 제한 없음

  : SMTP는 각 메시지가 7비트 ASCII로 이루어져야 하며 그 이외의 데이터는 ASCII로 인코딩되어야 한다. 반면 HTTP 데이터는 이러한 제한이 없다.

2.3.4 메일 접속 프로토콜

SMTP는 push 프로토콜이기에, 수신자가 자신의 메일서버에서 pull하는 프로토콜이 필요

POP3

• 매우 간단한 메일 접속 프로토콜 → 매우 한정된 기능
• 인증-트랜잭션-갱신 과정
• 인증 : 메일을 다운로드 하는 사용자를 인증
• 트랜잭션 : 메시지 수신, 삭제 표시 등 메일 관련 작업 표시
• 갱신 : quit 명령 이후 동작, 삭제 표시된 메시지 삭제

IMAP

POP3는 사용자가 어느 컴퓨터에서나 접속할 수 있는 원격 서버 폴더 유지를 못함

(로컬 컴퓨터안의 폴더에 메시지를 유지)

⇒ IMAP는 이를 보완하고 더 다양한 특성을 갖으나, 매우 복잡하다.

• IMAP 서버는 폴더에 각각의 메시지를 연결
• IMAP 프로로콜은 사용자가 폴더를 생성하고 메시지를 옮길 수 있게 함
• IMAP 세션을 통해 사용자 상태 정보를 유지
• 메시지의 일부 구성요소만을 얻는 것을 허용

웹 기반 전자메일

• 사용자 에이전트 - 일반 웹 브라우저
• 사용자는 HTTP를 통해 메일 서버의 메일박스와 통신
• 메일 서버 끼리의 송수신은 SMTP를 이용

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

인터넷 호스트는 호스트 네임과 IP주소로 식별

2.4.1 DNS가 제공하는 서비스

호스트 네임을 IP 주소로 변환해 주는 디렉터리 서비스

DNS : DNS 서버들의 계층구조로 구현된 분산 DB이며, 호스트가 분산 DB에 질의하도록 허락하는 애플리케이션 계층 프로토콜

• 호스트 엘리어싱(hos aliasing)

  : 복잡한 호스트 네임을 가진 호스트는 하나 이상의 별명을 가질 수 있다.

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

  : 메일 주소는 별명을 가질 수 있고, DNS는 정식 호스트 네임을 알려준다.

• 부하 분산(load distribution)

  : 중복 웹 서버 같은 여러 중복 서버 사이에서 부하를 분산한다.

  중복 웹 서버는 여러 IP주소를 갖고 있으며, 이러한 여러 IP주소로 부하를 분산한다.

2.4.2 DNS의 동작 원리

1. 애플리케이션이 호스트 네임을 명시하여, DNS의 클라이언트를 호출

2. 사용자 호스트의 DNS는 네트워크에 질의 메시지를 보냄

3. 모든 질의와 응답은 포트 53의 UDP 데이터그램으로 보내짐

4. 사용자 호스트 DNS는 요청한 매핑에 해당하는 DNS 응답메시지를 수신

5. 매핑을 애플리케이션에 전달

단일 DNS 서버의 문제점

• 서버의 고장 : 네임 서버가 고장나면, 전체 인터넷이 작동X
• 트래픽 양 : 단일 DNS 서버가 모든 DNS 질의를 처리해야 함
• 먼 거리의 중앙 집중 DB : 물리적으로 먼 거리의 질의도 처리해야 함
• 유지 관리 : 모든 호스트에 대한 레코드를 기록해야 하고 자주 갱신해야 함
• 확장성 : 확장성이 전혀 없다.

분산 계층 데이터베이스

DNS는 많은 서버를 이용하고 이들을 계층 형태로 구성하여 전세계에 분산

• 루트 DNS 서버 : DNS 레코드를 요청하는 과정의 첫 단계. 모든 확인자에게 알려져 있음
• 최상위 레베 도메인(TLE) 서버 : com,org,net,edu같은 상위 레베 도메인과 kr,uk,fr,ca,jp같은 국가의 상위 레벨 도메인에 대한 서버
• 책임 DNS 서버 : 각 호스트 네임과 IP 주소를 매핑해서 가지고 있다.

1. 요청 호스트가 로컬 DNS서버에 호스트 네임을 질의

2. 로컬 DNS서버에 해당 정보가 없으면 루트 DNS 서버에 요청메시지를 보냄

3. 루트 DNS 서버는 해당 호스트 네임에 대한 책임을 가진 TLD서버의 IP주소를 반환

4. 로컬 DNS서버는 TLD 서버로 요청하며, TLD 서버는 해당 책임 DNS 서버를 반환

5. 로컬 DNS 서버는 책임 DNS 서버로 요청하고 책임 DNS 서버는 매핑 정보를 반환

DNS 캐싱

DNS 서버가 호스트 네임에 대한 정보를 받았을 때, 이 정보를 로컬 DNS 서버에 저장