애플리케이션 계층 1

BinaryHyeok·2023년 10월 20일

컴퓨터 네트워킹 하향식 접근

목록 보기

2/10

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

네트워크 애플리케이션 개발의 중심은 다른 위치의 종단 시스템에서 동작하고, 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것
Ex) 사용자의 호스트에서 실행되는 브라우저 프로그램과 웹 서버 호스트에서 실행되는 웹 서버 프로그램

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

클라이언트-서버 구조(client-server)
- 서버(server)
  - 항상 동작
  - 고정 IP
  - 많은 수의 호스트를 갖춘 데이터 센터가 강력한 가상의 서버를 생성하는 역할로 사용
- 클라이언트(client)
  - 서버와 통신
  - 가끔 또는 항상 동작
  - 클라이언트는 서로 직접적으로 통신하지 않음
  - 변경가능한 IP
P2P 구조(peer-to-peer)
- 피어(peer)라는 간헐적으로 연결된 호트스 쌍이 서로 직접 통신하게 한다.
- 특정 서버를 통하지 않고 피어가 통신하므로 이 구조를 peer-to-peer라고 한다.
- 자가 확장성이 있다.

프로세스 간 통신

2개의 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지(message) 교환으로 서로 통신한다. 송신 프로세스는 메시지를 만들어서 네트워크로 보내고, 수신 프로세스는 메시지를 받고 역으로 메시지를 보냄으로써 응답한다. 프로세스 간의 통신에서 클라이언트와 서버는 다음과 같이 정의할 수 있다.

두 프로세스 간의 통신 세션에서 통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을 초기화)하는 프로세스를 클라이언트라 하고, 세션을 시작하기 위해 접속을 기다리는 프로세스를 서버라고 한다.

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

프로세스는 소켓(socket)을 통해 네트워크로 메시지를 보내고 받는다. 소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층 간의 인터페이스이며, 네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이의 API라고도 한다.

프로세스 주소 배경

특정 목적지로 우편 메일을 보내기 위해서는 목적지가 주소를 갖고 있어야 한다. 마찬가지로, 한 호스트상에서 수행되는 프로세스가 패킷을 다른 호스트에서 수행되고 있는 프로세스로 패킷을 보내기 위해서는 수신 프로세스가 주소를 가지고 있을 필요가 있다. 수신 프로세스를 식별하기 위해서는 다음과 같은 두 가지 정보가 명시되어야 한다.

호스트의 주소
인터넷에서 호스트는 IP 주소로 식별된다.
목적지 호스트 내의 수신 프로세스를 명시하는 식별자
수신 호스트에서 수행되는 수신 프로세스(수신 소켓)을 식별하기 위해서는 포트 번호(port number)가 필요하다.
인기 있는 애플리케이션은 특정 포트 번호가 할당된다.
Ex) 웹서버 : 80, 메일서버 : 25

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

트랜스포트 계층 프로토콜이 그것을 이용하는 애플리케이션에게 제공할 수 있는 서비스들은 넓은 범위에서 신뢰적 데이터 전송, 처리율, 시간, 보안으로 분류할 수 있다.

신뢰적 데이터 전송

패킷들은 컴퓨터 네트워크 내에서 손실될 수 있다. 예를 들어, 패킷은 라우터의 버퍼에서 오버플로 되거나, 패킷의 비트가 잘못되면 호스트 혹은 라우터에 의해 버려질 수 있다. 재무 애플리케이션 같은 경우 데이터 손실은 위험한 결과를 초래할 수 있다. 따라서 이러한 애플리케이션을 지원하기 위하여 한 애플리케이션이 보낸 데이터가 올바르고 완전히 다른 애플리케이션에 전달되도록 보장하기 위해 조치를 취해야 한다. 만약 프로토콜이 보장된 데이터 전송 서비스를 제공한다면 이를 신뢰적 데이터 전송(reliable data transfer)을 제공한다고 한다. 트랜스포트 프로토콜이 신뢰적 데이터 전송을 제공하지 않을 때, 송신 프로세스가 보낸 데이터는 수신 프로세스에 전혀 도착하지 않을 수 있다. 이것은 손실 허용 애플리케이션(loss-tolerant application)의 경우, 어느 정도의 데이터 손실을 참아낼 수 있는 실시간 오디오/비디오 같은 멀티 애플리케이션에서 받아들여 질 수 있다.

처리율

네트워크 경로를 따라 두 프로세스간의 통신 세션에서 송신 프로세스가 수신 프로세스로 비트를 전달할 수 있는 비율을 나타낸다. 트랜스포트 프로토콜은 가용한 처리율이 항상 적어도 r bps임을 보장한다. 만약 트랜스포트 프로토콜이 이 처리율을 제공할 수 없다면, 애플리케이션은 낮은 속도로 인코딩하거나 포기해야한다. 처리율 요구사항을 갖는 애플리케이션은 대역폭 민감 애플리케이션(bandwidth-sensitive application)이라고 한다.
대역폭 민감 애플리케이션들이 특정 처리율 요구사항을 갖고 있는 반면에, 탄력적 애플리케이션(elastic application)은 가용한 처리율을 많으면 많은 대로 적으면 적은 대로 이용할 수 있다.

시간

트랜스포트 계층 프로토콜은 시간 보장(timing guarantee)을 제공할 수 있다. 예를 들면 송신자가 소켓으로 내보내는 모든 비트가 수신자의 소켓에 100ms 내에 도착하게 하는 것이다. 이러한 서비스는 인터넷 전화, 가상 환경, 원격회의 같은 실시간 상호작용 애플리케이션에 매력적이다. 비실시간 애플리케이션의 경우 낮은 지연이 항상 높은 지연보다 선호되지만 종단 간 지연에 엄격한 제약을 받는 것은 아니다.

보안

트랜스포트 프로토콜은 애플리케이션에 하나 이상의 보안 서비스를 제공할 수 있다.

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

인터넷은 애플리케이션에게 2개의 전송 프로토콜, 즉 UDP(User Datagram Protocol)와 TCP(Transmission Control Protocol)를 제공한다.

TCP 서비스

연결지향형 서비스 : 애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환하게 한다. 이 핸드셰이킹 과정이 클라이언트와 서버에 패킷이 곧 도달할 테니 준비하라고 알려주는 역할을 한다. 핸드셰이킹 단계를 지나면, TCP 연결이 두 프로세스 소켓 사이에 존재한다고 말한다. 이 연결은 두 프로세스가 서로에게 동시에 메시지를 보낼 수 있기에 전이중(full-duplex) 연결이라고 한다. 애플리케이션이 메시지 전송을 마치면 연결을 끊어야 한다.
신뢰적인 데이터 전송 서비스 : 통신 프로세스는 모든 데이터를 오류 없이 올바른 순서로 전달하기 위해 TCP에 의존한다. TCP는 애플리케이션의 한쪽이 바이트 스트림을 소켓으로 전달하면 그 바이트 스트림이 손실되거나 중복되지 않게 수신 소켓을 전달한다.

UDP 서비스

UDP는 최소의 서비스 모델을 가진 간단한 전송 프로토콜
비연결형이므로 두 프로세스가 통신을 하기 전에 핸드셰이킹을 하지 않는다.
비신뢰적인 데이터 전송 서비스를 제공한다.
혼잡 제어 방식을 포함하지 않으므로, 송신 측은 데이터를 원하는 속도로 하위 계층(네트워크 계층)으로 보낼 수 있다.

웹과 HTTP

HTTP 개요

웹의 애플리케이션 계층 프로토콜인 HTTP(HyperText Transfer Protocol)는 웹의 중심이다. HTTP는 두가지 프로그램으로 구현된다.(클라이언트 프로그램과 서버 프로그램). 각기 다른 종단 시스템에서 수행되는 클라이언트 프로그램과 서버 프로그램은 서로 HTTP 메시지를 교환하여 통신하며, HTTP는 메시지의 구조 및 클라이언트와 서버가 메시지를 어떻게 교환하는지에 대하여 정의하고 있다.

사용자가 웹 페이지를 요청할 때, 브라우저는 페이지 내부의 객체에 대한 HTTP요청 메시지를 서버에게 보낸다. 서버는 요청을 수신하고 객체를 포함하는 HTTP 응답 메시지로 응답한다.

메시지 전송 과정

HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작한다.
연결이 이루어지면 브라우저와 서버 프로세서는 그들의 소켓 인터페이스를 통하여 TCP로 접속한다.
클라이언트는 HTTP 요청 메시지를 소켓 인터페이스로 보내고 소켓 인터페이스로부터 HTTP 응답 메시지를 받는다.
마찬가지로, HTTP 서버는 소켓 인터페이스로부터 요청 메시지를 받고 응답 메시지를 소켓 인터페이스로 보낸다.

HTTP 서버는 클라이언트에 대한 정보를 유지하지 않으므로, HTTP를 비상태 프로토콜(stateless protocol)이라고 한다.

비지속 연결과 지속 연결

HTTP는 디폴트로 지속 연결을 사용하지만, HTTP 클라이언트와 서버는 비지속 연결을 사용하도록 설정될 수 있다.

비지속 연결 HTTP

페이지가 기본 HTML파일과 10개의 JPEG 이미지로 구성되고, 이 11개의 객체가 같은 서버에 있다고 가정하자. 기본 HTML파일의 URL은 다음과 같다.

http://www.someSchool.edu/someDepartment/home.index

연결 수행 과정은 다음과 같다.

HTTP 클라이언트는 HTTP의 기본 포트 번호 80을 통해 www.someSchool.edu 서버로 TCP 연결을 시도한다.
HTTP 클라이언트는 1단계에서 설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지를 보낸다. 이때 요청 메시지에는 /someDepartment/home.index 경로 이름을 포함한다.
HTTP 서버는 1단계에서 설정된 연결 소켓을 통해 요청 메시지를 받는다. 저장장치로부터 /someDepartment/home.index 객체를 추출한다. HTTP 응답 메시지에 그 객체를 캡슐화하여 소켓을 통해 클라이언트로 보낸다.
HTTP 서버는 TCP에게 TCP 연결을 끊으라고 한다(TCP 클라이언트가 응답 메시지를 올바로 받을 때까지 연결을 끊지 않음).
HTTP 클라이언트가 응답 메시지를 받으면, TCP 연결이 중단된다. 메시지는 캡슐화된 객체가 HTML 파일인 것을 나타낸다. 클라이언트는 응답 메시지로부터 파일을 추출하고 HTML 파일을 조사하고 10개의 JPEG 객체에 대한 참조를 찾는다.
그 이후 참조되는 각 JPEG 객체에 대해 처음 네 단계를 반복한다.

비지속 연결은 몇 가지 단점이 있다.

각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 한다. TCP 버퍼가 할당되어야 하고, TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 한다. 이는 수많은 클라이언트들의 요청을 동시에 서비스하는 웹 서버에 부담을 줄 수 있다.
각 객체는 2RTT를 필요로 한다.(TCP연결 설정에 1RTT, 객체를 요청하고 받는 데 1RTT)
RTT는 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는 데 걸리는 시간이다.

지속 연결 HTTP

지속 연결에서 서버는 응답을 본내 후에 TCP 연결을 그대로 유지한다. 같은 클라이언트나 서버 간의 이후 요청과 응답은 같은 연결을 통하여 보내진다. 특히 앞선 예에서의 전체 웹 페이지를 하나의 지속 TCP 연결을 통해 보낼 수 있다. 이들 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어질 수 있다.(파이프라이닝) 일반적으로 HTTP 서버는 일정 기간 사용되지 않으면 연결을 닫으며, 서버가 연속된 요구를 수신할 때, 서버는 객체를 연속해서 보낸다.

HTTP 메시지 포맷

HTTP 요청메시지

Get /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accpet-language: fr

HTTP 요청 메시지의 첫 줄은 요청 라인(request line), 이후의 줄들은 헤더 라인(header line) 이라고 부른다.
요청 라인은 3개의 필드, 즉 방식(method) 필드, URL 필드, HTTP 버전 필드를 가진다.
Host : www.someschool.edu는 객체가 존재하는 호스트를 명시하고 있다.
Connection: close 헤더 라인은, 브라우저는 서버에게 지속 연결 사용을 원하지 않는다는 것을 말하고 있다.
User-agent: 헤더 라인은 서버에게 요청하는 브라우저 타입을 명시하고 있다.
Accpet-language: 헤더는 사용자가 객체의 프랑스어 버전을 원하고 있음을 나타낸다.

HTTP 응답 메시지

HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Conent-Type: text/html
(data.....)

응답 메시지는 총 3개의 섹션인 초기 상태라인, 헤더라인, 개체 몸체로 나뉘어져 있다.

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

HTTP 서버는 상태를 유지하지 않지만, 서버가 사용자 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하기 원하므로 웹사이트가 사용자를 확인하는 것이 바람직할 때가 있다. 이 목적으로 HTTP는 쿠키(cookie)를 사용한다.

쿠키 기술은 네 가지 요소를 포함한다.

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

쿠키가 동작하는 과정은 다음과 같다.
이베이 사이트에 방문한 적이 있는 사람이 처음으로 아마존닷텀에 접속했다고 가정한다.

아마존 웹 서버에 요청이 들어올 때 그 서버는 유일한 식별번호를 만들고 이 식별번호로 인덱싱되는 백엔드 데이터베이스 안에 엔트리를 만든 후 브라우저에 응답한다. 이때 HTTP 응답에 식별번호를 담고 있는 Set-cookie: 헤더가 포함된다.
브라우저가 HTTP 응답 메시지를 받았을 때 그 Set-cookie: 헤더를 볼 수 있다. 브라우저는 관리하는 특정한 쿠키 파일에 그 라인을 덧붙여 저장하고, 이 라인은 서버의 호스트 이름과 Set-cookie: 헤더와 식별번호를 포함한다.
아마존 사이트를 계속 탐색함에 따라, 웹 페이지 요청을 할 때 브라우저는 쿠키 파일을 참조하고 이 사이트에 대한 식별번호를 발췌하고, HTTP 요청에 식별번호를 포함하는 쿠키 헤더 파일을 넣는다. 이러한 방식으로 아마존 서버는 활동을 추적할 수 있다.

웹 캐싱

웹 캐시(Web cache, 프록시 서버(proxy server)라고도 함)는 기점 웹 서버(origin Web server)을 대신하여 HTTP 요구를 충족시키는 네트워크 개체이다. 웹 캐시는 자체의 저장 디스크를 가지고 있어 최근 호출된 객체의 사본을 저장 및 보존한다. 브라우저는 사용자의 모든 HTTP 요구가 웹 캐시에 가장 먼저 보내지도록 구성될 수 있다.

브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP 요청을 보낸다.
웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인한다. 만일 저장되어 있다면 웹 캐시는 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체를 전송한다.
만일 웹 캐시가 객체를 갖고 있지 않다면, 웹 캐시는 기점 서버로 TCP 연결을 설정한다. 그러고 나서 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다.
웹 캐시의 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메시지와 함께 객체의 사본을(클라이언트 브라우저와 웹 캐시 사이에 이미 설정된 TCP 연결을 통해) 보낸다.

캐시는 서버이면서 클라이언트이며 웹 캐시의 장점은 다음과 같다.

웹 캐시는 클라이언트의 요구에 대한 응답 시간을 줄일 수 있다. 특히 클라이언트와 기점 서버 사이의 병목 대역폭이 클라이언트와 캐시 사이의 병목 대역폭에 비해 매우 작을 때 더욱 효과적이다.
웹 캐시는 한 기관에서 인터넷으로의 접속하는 링크상의 웹 트래픽을 대폭으로 줄일 수 있다. 이는 기관이 자주 대역폭 개선을 할 필요가 없어져 비용 감소로 이어진다.

조건부 GET

웹 캐싱이 사용자가 느끼는 응답 시간을 줄일 수 있지만, 새로운 문제를 야기한다. 캐시 내부에 있는 복사본이 최신이 아닐 수 있다. 이 문제는 조건부 GET(conditional GET)을 사용하면 해결할 수 있다. HTTP 요청메시지가 (1)Get 방식을 사용하고, (2) If-Modified-Since: 헤더 라인을 포함하고 있다면, 그것이 조건부 GET 메시지다.

브라우저의 요청을 대신해 프록시 캐시는 요청 메시지를 웹 서버로 보낸다.

GET /fruit/kiwi.gif HTTP/1.1
HOST: www.exotiquecuisine.com
웹 서버는 캐시에게 객체를 가진 응답을 보낸다.

HTTP/1.1 200 OK
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(data...)

캐시는 요청하는 브라우저에게 객체를 보내주고 자신에게도 객체를 저장한다. 중요한 것은 캐시가 객체와 더불어 마지막으로 수정된 날짜를 함께 저장한다는 것이다.
일주일 후에 다른 브라우저가 같은 객체를 캐시에게 요청하면 객체는 여전히 저장되어 있다. 이 객체는 지난 주에 웹 서버에서 수정되었으므로 브라우저는 조건부 GET으로 갱신 조사를 수행한다.

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Wed, 9 Sep 2015 09:23:24
If-modifed-since 헤더 라인 값이 Last-Modified 헤더 값과 같다면 다음과 같은 응답 메시지를 보낸다.

HTTP/1.1 304 Not Modified
Date: Sat, 10 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)

응답 메시지를 보내지만 요청된 객체는 포함되어 있지 않다. 이는 클라이언트에게 요청된 객체의 캐싱된 복사본을 사용하라는 것을 의미한다.

Reference

KOCW - 컴퓨터 네트워크
컴퓨터 네트워킹 하향식 접근

BinaryHyeok

이전 포스트

컴퓨터 네트워크 기본

다음 포스트