Nw 2 1 Application Layer
2.1 네트워크 애플리케이션의 원리
2.1.1 네트워크 애플리케이션 구조
애플리케이션 구조는 애플리케이션 개발자에 의해 설계되며 두 가지(클라이언트-서버 구조 혹은 P2P 구조) 중의 하나로 작성한다.
클라이언트 서버 구조에서는 서로 직접적으로 통신하지 않는다. 예를 들어, 웹 애플리케이션에서는 2개의 브라우저가 직접적으로 통신하지 않는다. 서버와 클라이언트의 프로세스가 통신을 한다.
또 다른 특징은 서버가 고정 IP 주소를 갖는다는 것이다. 클라이언트는 동적 IP 주소로 연결될 때마다 변경 가능하다.
P2P 구조는 항상 켜져 있는 서버에는 최소 혹은 전혀 의존하지 않는다. 대신 피어라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신한다.
2.1.2 프로세스 간 통신
클라이언트와 서버 프로세스
두 프로세스 간의 통신 세션에서 통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을 초기화)하는 프로세스를 클라이언트라 하고 세션을 시작하기 위해 접속을 기다리는 프로세스를 서버라고 한다.
그림 2.3은 프로세스가 사용하는 하위 전송 프로토콜이 인터넷의 TCP 프로토콜이라고 가정한다.
소켓은 호스트의 애플리케이션과 트랜스포트 계층 간의 인터페이스다.
또한 소켓은 네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로 애플리케이션과 네트워크 사이의 API라고도 한다.
애플리케이션 개발자는 소켓 애플리케이션 계층에 대한 모든 통제권을 갖지만 소켓의 트랜스포트 계층에 대한 통제권은 거의 갖지 못한다.
트랜스포트 프로토콜의 선택, 최대 버퍼와 최대 세그먼트 크기와 같은 약간의 매개변수 설정 뿐이다.
프로세스 주소 배정
주소가 있어야 우편을 보내듯이 프로세스 패킷을 보내기 위해 수신 프로세스 주소가 필요하다.
수신 프로세스를 식별하기 위해 호스트의 주소와 목적지 호스트 내의 수신 프로세스를 명시하는 식별자가 요구된다.
인터넷에서 호스트는 IP 주소로 식별된다. IP 주소는 32비트로 구성되며 호스트를 유일하게 식별한다.
수신 프로세스(좀 더 자세히는 수신 소켓)도 식별해야 하는데 목적지 포트 번호가 이를 위해 사용된다.
2.1.3 애플리케이션이 이용 가능한 트랜스포트 서비스
송신 측 애플리케이션이 소켓을 통해 메시지를 보내면 그 소켓의 반대편에서 트랜스포트 프로토콜은 네트워크를 통해 메시지를 수신 프로세스의 소켓으로 이동시킬 책임이 있다.
트랜스포트 계층 프로토콜이 애플리케이션에 제공할 서비스는 크게 신뢰적 데이터 전송, 처리율, 시간, 보안의 네 가지로 분류할 수 있다.
신뢰적 데이터 전송
패킷은 네트워크 내에서 손실될 수 있으므로(예를 들어 오버플로우, 패킷의 비트가 잘못되는 등) 데이터를 완전히 전달되기 위해서는 특정 조치를 취해야 한다. 만약 프로토콜이 보장된 데이터 전송 서비스를 제공한다면 이를 신뢰적 데이터 전송을 제공한다고 표현한다.
처리량
처리율은 네트워크 경로를 따라 두 프로세스 간의 통신 세션에서 송신 프로세스가 수신 프로세스로 비트를 전달할 수 있는 비율이다.
애플리케이션은 r bits/sec의 보장된 처리율을 요구할 수 있고 트랜스포트 프로토콜은 가용한 처리율이 항상 적어도 r bps임을 보장한다.
시간
예를 들어 송신자가 소켓으로 내보내는 모든 비트가 쉰자의 소켓에 100 msec 내에 도착하도록 하는 것이다. 그러한 서비스는 인터넷 전화, 가상 환경, 원격회의 등의 실시간 애플리케이션에서 매력적이다.
보안
트랜스포트 프로토콜은 애플리케이션에 하나 이사의 보안 서비스를 제공할 수 있다. 예를 들어 송신 호스트에서 트랜스포트 프로토콜은 송신 프로세스가 전송하는 모든 데이터를 암호화할 수 있고 수신 호스트에서 트랜스포트 프로토콜은 그 데이터를 수신 프로세스에 전달하기 전에 데이터의 암호를 해독할 수 있다.
보안 TCP
TCP나 UDP는 암호화를 제공하지 않는다. 이에 TCP를 강화한 SSL(Secure Sockets Layer)가 개발됐다. SSL로 강화된 TCP는 기존 TCP의 모든 기능뿐만 아니라 암호화, 데이터 무결성, 종단 인증을 제공한다.
SSL은 TCP, UDP와 같이 트랜스포트 프로토콜이 아니라 애플리케이션 계층에 구현된 것이다. 애플리케이션이 SSL 서비스를 이요하려면 클라이언트와 서버 측 모두에 SSL 코드를 포함해야 한다.
2.1.4 인터넷 전송 프로토콜이 제공하는 서비스
이제는 인터넷이 제공하는 애플리케이션 지원 유형을 살펴보자. 인터넷(그리고 일반적인 TCP/IP 네트워크)은 애플리케이션에게 2개의 전송 프로토콜(UDP, TCP)을 제공한다.
TCP 서비스
연결지향형 서비스
애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환(핸드셰이킹)하도록 한다.
셰이킹 단계를 지나면 TCP 연결이 두 프로세스 소켓 사이에 존재한다고 얘기한다.
이 연결은 두 프로세스가 서로에게 동시에 메시지를 보낼 수 있기에 전이중(full-duplex) 연결이라고 한다.
신뢰적인 데이터 전송 서비스
모든 데이터를 오류 없이 올바른 순서로 전달하기 위해 통신 프로세스는 TCP에 의존한다.
이외에 TCP는 혼잡제어 방식(네트워크가 혼잡상태에 이르면 프로세스 속도를 낮춘다)을 사용한다. TCP 연결이 네트워크 대역폭을 공평하게 공유할 수 있게끔 제한하는 것이다.
UDP 서비스
UDP는 비연결형이므로 두 프로세스가 통신을 하기 전에 핸드셰이킹을 하지 않는다. 비신뢰적인 데이터 전송 서비스를 제공한다. 수신 소켓에 도착하는 메시지들의 순서가 바뀔 수도 있다.
UDP는 혼잡제어 방식을 포함하지 않아서 데이터를 원하는 속도로 하위 계층(네트워크 계층)으로 보낼 수 있다. 하지만 실제 종단간 처리율은 중간 링크들의 제한된 대역폭 혹은 혼잡으로 인해 속도가 느려질 수도 있다.
2.1.5 애플리케이션 계층 프로토콜
애플리케이션 계층 프로토콜은 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의한다.
- 교환 메시지 타입(예: 요청 메시지와 응답 메시지)
- 여러 메시지 타입의 문법(예: 메시지 내부의 필드와 필드 간의 구별 방법)
- 필드의 의미, 즉 필드에 있는 정보의 의미
- 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지 결정하는 규칙
여러 애플리케이션 계층 프로토콜은 RFC에 명시돼 있으므로 공중 도메인(Public domain)에서 찾을 수 있다. 예를 들어 브라우저 개발자가 HTTP RFC의 규칙을 따른다면 브라우저는 HTTP RFC 규칙을 따른 어떠한 웹 서버로부터도 웹 페이지를 가져올 수 있다. 반대로 다른 애플리케이션 계층 프로토콜들은 독점(비개방)이며 공중 도메인에서 구할 수 없다(예: 스카이프).
2.2 웹과 HTTP
2.2.1 HTTP 개요
웹 애플리케이션 계층 프로토콜인 HTTP(Hypertext Transfer Protocol)은 웹의 중심으로 RFC 1945, RFC 2616에 정의돼 있다.
웹 페이지(문서라고도 한다)는 객체들로 구성된다. 객체(Object)는 단순히 URL로 지정할 수 있는 하나의 파일(HTML 파일, JPEG 이미지, 자바 애플릿, 오디오 클립 등)이다. 대부분의 웹페이지는 기본 HTML 파일과 여러 참조 객체로 구성된다.
http://www.someSchool.edu/someDpartment/picture.git
http://www.someSchool.edu는 호스트 네임이고 /someDpartment/picture.git는 경로 이름이다.
HTTP는 TCP를 전송 프로토콜로 사용한다. 클라이언트는 먼서 서버에 TCP 연결을 시작하고 일단 연결이 이뤄지면 브라우저와 서버 프로세스는 그들의 소켓 인터페이스를 통해 TCP로 접속한다.
HTTP 서버는 클라이언트에 대한 정보를 유지하지 않으므로 비상태 프로토콜(stateless protocl)이라고 한다.
2.2.2 비지속 연결과 지속 연결
각 요구/응답 쌍이 분리된 TCP 연결을 통해 보내져야 하면 비지속 연결(non-persistent connection)이라고 하고 같은 TCP 연결상으로 보내져야 한다면 지속 연결(persistent-connection)이라고 한다.
HTTP가 디폴트 모드로 지속 연결을 사용하지만 HTTP 클라이언트와 서버는 비지속 연결을 사용하도록 설정될 수 있다.
비지속 연결 HTTP
서버가 객체를 보낸 후에 TCP 연결이 끊어진다. 연결이 다른 객체를 위해 유지되지 않는다. 각 TCP 연결은 하나의 요청 메시지와 하나의 응답 메시지만 전송한다.
작은 패킷이 클라이언트로부터 서버까지 가고 다시 클라이언트로 되돌아오는 데 걸리는 시간을 RTT(round-trip-time)로 정의하면 비지속 연결은 2RTT가 걸린다.
연결 초기화 요청에서 응답을 받은 1RTT(3-way 핸드 셰이크의 2번째까지) 이후 파일 요청 후 응답으로 파일을 수신하는 1RTT가 더해져 2RTT와 HTML 파일을 서버가 전송하는 데 걸리는 시간이 필요하다.
지속 연결
HTTP 1.1 지속 연결에서는 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지한다. 일반적으로 HTTP의 디폴트 모드는 파이프라이닝을 이용한 지속 연결을 사용한다.
HTTP/2는 같은 연결상에서 다중 요청과 응답이 가능하다.
2.2.3 HTTP 메시지 포맷
GET/somdir/page.html HTTP/1.1
Host: www.someshool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
HTTP 요청 메시지의 첫 줄은 요청 라인(request line)이라 부르고 이후의 줄들은 헤더 라인(header line)이라고 부른다. 각 줄은 CR과 LF(캐리지 리턴 & line feed)로 구별한다.
요청 라인은 3개의 필드로 Method 필드, URL 필드, HTTP 버전 필드다.
헤더 라인을 살펴보자. www.someshool.edu는 객체가 존재하는 호스트를 명시한다. 호스트 헤더 라인이 제공하는 정보는 웹 프록시 캐시에서 필요로 한다.
Connection은 지속 연결 여부를 말한다.
User-agent는 서버에게 요청하는 브라우저 타입을 명시한다.
Accept-language는 언어 버전(fr은 프랑스)을 원하고 있음 을 나타낸다. 만약 서버에 존재하지 않으면 기본 버전을 보낸다.
헤더 라인 이후 CR, LF로 구분하고 개체 몸체(entity body)가 나온다.
응답 메시지
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
Content-Type: text/html
(데이터 데이터 데이터 ...)
상태라인은 3개 필드 프로토콜 버전 필드, 상태코드, 해당 상태 메시지다.
그 다음은 헤더라인이다.
- 1) Connection: close - 클라이언트에게 메시지를 보낸 후 TCP 연결을 닫는 데 사용한다.
- 2) Date: 서버가 응답을 보낸 날짜와 시간이다. 객체가 생성되거나 수정된 시간이 아니다.
- 3) Server
- 4) Last-Modified
- 5) Content-Length: 송신되는 객체의 바이트 수다.
- 7) Content-Type: 객체 타입은 파일확장자가 아니라 콘텐츠타입 헤더로 나타낸다.
2.2.4 사용자와 서버 간의 상호작용: 쿠키
HTTP 서버는 상태를 유지하지 않아서 동시에 수천 개의 TCP 연결을 다룰 고성능 웹 서버 개발이 가능하게 되었다. 그러나 서버가 사용자 접속을 제한하거 사용자에 따라 콘텐츠를 제공하기 원하므로 사용자를 확인해야 할 때가 있다. 이 목적으로 쿠키(cookie)를 사용한다.
RFC 6265에 정의된 쿠키는 사이트가 사용자를 추적하도록 해준다.
쿠키 기술은 네 가지 요소가 있다.
- 1) HTTP 응답 메시지 쿠키 헤더라인
- 2) HTTP 요청 메시지 쿠키 헤더라인
- 3) 사용자의 브라우저에 사용자 중단 시스템과 관리를 지속시키는 쿠키 파일
- 4) 웹 사이트의 백엔드 데이터 베이스
그림 2.10을 살펴보자. 수잔은 과거에 이베이를 방문한 적이 있고 처음으로 아마존에 접속했다.
아마존 웹 서버에 요청이 오면 서버는 유일한 식별번호를 만들고 이 식별번호로 인덱스되는 백엔드 데이터베이스 안에 엔트리를 만든다.
그러나 나서 아마존 서버는 수잔의 브라우어에 응답할 때 식별번호를 담은 Set-cookie:헤더를 포함해 보낸다.
브라우저는 응답을 받고 관리하는 특정한 쿠키 파일에 헤더 라인을 덧붙인다. 이 라인은 서버의 호스트 네임과 Set-cookie: 헤더와 식별번호를 포함한다.
수잔이 아마존 사이트를 계속 살펴봄에 따라 HTTP 요청에 식별번호를 포함하는 쿠키 헤더 파일을 넣는다. 아마존 서버는 수잔의 활동을 추적할 수 있는 것이다.
2.2.5 웹 캐싱
웹 캐시(프록시 서버)는 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장한다.
- 1) 브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP 요청을 보낸다.
- 2) 웹 캐시는 객체의 사본이 자기에게 저장돼 있는지 확인한다. 만일 저장돼 있다면 웹 캐시는 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체를 전송한다.
- 3) 만약 웹 캐시가 객체를 가지고 있지 않다면 원출처 서버인
www.somschool.edu로 TCP 연결을 설정한다. 그러고 나서 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다. 이러한 요청을 받은 후에 기점 서버는 웹 캐시로 HTTP 응답 메시지와 함께 객체를 보낸다. - 4) 웹 캐시가 객체를 수신할 때 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메시지와 함께 객체의 사본을(클라이언트 브라우저와 웹 캐시 사이에 이미 설정된 TCP 연결을 통해) 보낸다.
한편 콘텐츠 전송 네트워크(CDN, Content Distribution Network) 회사는 인터넷 전역을 통해 지역적으로 분산된 캐시를 설치하고 있으며 이를 통해 많은 트래픽을 지역화하고 있다.
조건부 GET
웹 캐싱이 응답 시간을 줄일 수 있지만 캐시 내부의 객체의 복사본이 새것이 아닐 수 있다는 문제를 야기한다.
HTTP는 이를 해결하기 위해 조건부 GET(conditional GET)으로 모든 객체들이 최신인지 확인하는 캐싱방식을 갖고 있다.
HTTP 요청 메시지가 GET 방식을 사용하면서 헤더 라인에 If-Modified-Since:를 포함하면 조건부 GET이 된다.
조건부 GET은 서버에게 날짜를 보내는데 명시된 날짜 이후 수정된 경우에만 그 객체를 보내라는 의미다.
그 날짜 이후 객체 변경이 없었다면 서버는 빈 개체 몸체와 함께 304 Not Modified를 응답한다.
이는 클라이언트에게 요청 객체의 캐시된 복사본을 사용하라는 의미다.