[Computer network] Chapter 7 - Application Layer : HTTP and DNS

1. Application Architecture

• Application Layer : 계층 구조의 가장 상위에 위치한 계층으로, 사용자와 실질적으로 상호작용(User Interface 제공)하는 계층이다.

• Client-Server Architecture : 네트워크 애플리케이션에 사용되는 대표적인 아키텍처이다.

  • Server

    • 항상 실행 상태이며, 클라이언트의 요청을 대기한다.

    • 고정된 IP 주소(Permanent IP Address)를 사용하기 때문에 쉽게 찾을 수 있다.

    • 서버는 대규모 요청 처리 및 확장성을 위해 데이터 센터를 활용한다.

  • Client

    • 클라이언트는 서버로 어떠한 요청을 전달하며, 서버로부터 응답을 받는다.

    • 클라이언트는 필요할 때만 네트워크에 연결된다.

    • 주로 동적 IP 주소를 사용한다.

• P2P Architecture : 전통적인 Client-Server 아키텍처에서 발전된 형태로, 마찬가지로 네트워크 애플리케이션에 자주 활용된다.

  • 별도의 대규모 서버가 존재하지 않는다.

    • 전통적인 서버-클라이언트 모델과 달리, 중앙 서버가 없다.

    • 서버가 네트워크 전역에 흩어져있는 형태이다.

    • 데이터 전송 및 처리는 네트워크에 참여하는 peer(host)간에 이루어진다.

  • 임의의 종단 시스템 간 직접 통신이 이루어진다.

    • 네트워크에 연결된 모든 피어는 서버이자 클라이언트이다.

    • 피어는 다른 피어에게 서비스를 요청하고, 동시에 자신도 서비스를 제공한다.

  • 장점

    • 자체 확장성이 뛰어나다.

    • 중앙 서버가 없으므로 한 서버에 접근을 하지 못하더라도, 다른 서버를 통해 서비스를 제공받을 수 있다.

  • 단점

    • 서버와 연결하는 과정이 어렵고 복잡하다.

    • 특정 데이터를 요청하려면 해당 데이터를 제공해줄 피어(서버)를 찾아야한다.

2. World Wide Web and HTTP

• World Wide Web (WWW) : 인터넷에서 가장 널리 사용되는 서비스로, 전 세계적으로 HTML과 멀티미디어 컨텐츠를 공유하고 접근할 수 있는 시스템이다.

  • Client-server 아키텍처를 기반으로 설계되었다.

  • 처음 시작은 유럽의 여러 연구자들이 서로의 연구 자료에 쉽게 접근할 수 있도록 설계한 시스템이었다.

  • 웹 브라우저와 HTTP가 널리 사용되면서, 일반 대중들도 쉽게 웹에 접근할 수 있게 되었다.

• Hyper-Text Transfer Protocol (HTTP) : 웹 클라이언트(브라우저)와 웹 서버간 통신을 위한 애플리케이션 계층 프로토콜이다.

  • HTTP는 TCP 기반으로 동작한다.

  • 포트 번호

    • Server : 기본적으로 80을 사용

    • Client : 임시 포트 번호를 사용하여 서버와 통신함

  • Message Format : HTTP에서 사용하는 메시지 포맷은 다음과 같다.

• Non-Persistent Connection 예제 : HTTP 1.0에서 사용되는 연결 방식으로, 하나의 TCP 연결은 하나의 요청만을 처리한다. 자세한 예제를 살펴보자.

  • 첫 번째 연결 : 클라이언트가 텍스트 파일을 요청한다.

    • 3-way handshake를 통해 연결이 설정되고, 서버는 텍스트 파일을 전송한다.

    • 데이터 전송이 끝나고, 3-way handshake를 통해 연결이 종료된다.

  • 두 번째 연결 : 클라이언트가 이미지 파일을 요청한다.

    • 3-way handshake를 통해 새로운 TCP 연결이 설정된다.

    • 데이터 전송이 끝나고, 다시 연결이 종료된다.

  • 위 방식의 장점

    • 각 객체에 대한 TCP 연결이 독립적이기 때문에, 데이터 전송이 빠르다.

    • Waiting time이 필요 없는 단순한 구조이다.

  • 단점

    • 각 요청마다 새로운 TCP 연결이 필요하므로, 메모리 사용량이 크다.

• Persistent Connection 예제 : HTTP 1.1에서 사용되는 연결 방식으로, 하나의 TCP 연결에 여러 요청과 응답을 처리할 수 있다.

  • 한번의 TCP 연결에 여러 요청과 응답을 처리할 수 있으므로, 메모리 사용량이 적다.

  • 여러번 연결 할 필요가 없으므로, 연결에 소모되는 시간이 짧아진다.

  • Header(HOL) Blocking

    • 클라이언트가 여러 객체를 요청할 경우, 큰 객체와 작은 객체들이 요청된 순서대로 전송된다.

    • 크기가 작은 객체는 크기가 큰 객체의 전송 완료를 기다려야 하므로, 지연이 발생한다.

• HTTP/2 : Header Blocking 문제를 해결하기 위해 고안된 프로토콜이다.

  • 각 객체를 프레임 단위로 나누고, 여러 요청을 멀티플렉싱 방식으로 전송한다.

  • 크기가 큰 객체와 작은 객체의 프레임이 같이 전송되므로, Header Blocking 문제 해결

  • 다만, TCP 방식은 오버헤드가 매우 큰 프로토콜이므로 현재는 HTTP/3를 사용하고 있다.

• HTTP Evolution

2-1. Method

• Method : 클라이언트가 서버와 통신할 때 사용되는 메소드들이다.

• GET 메소드 사용 예시

  • 클라이언트는 GET 메소드를 통해 서버의 /usr/bin/image1 파일을 요청한다.

    • Accept : 클라이언트가 허용하는 확장자

  • 서버는 여러 가지 정보와 요청된 이미지 파일을 포함한 응답 메시지를 전송한다.

    • 이미지 파일은 본문(Payload)에 들어있다.

• PUT 메소드 사용 예시

  • 클라이언트는 PUT 메소드를 통해 서버의 /cgi-bin/doc.pl 경로에 데이터 업로드를 요청한다.

    • 클라이언트 메시지의 Payload에는 업로드하려는 데이터가 포함되어 있다.

  • 서버는 업로드된 CGI 문서의 데이터를 Payload에 포함하여 요청에 대한 승인 메시지를 보낸다.

2-2. Cookie

• Cookie : HTTP 환경에서 클라이언트와 서버 간 상태 정보를 유지하기 위해 사용하는 작은 데이터 조각이다.

  • HTTP는 상태 비저장 프로토콜이기 때문에, 이전 요청의 상태를 저장하지 않고 있다. 따라서 클라이언트와 서버가 통신할 때마다 중복되는 상태 정보를 계속해서 주고 받아야한다.

    • 이를 해결하기 위해 쿠키를 사용한다.

  • 쿠키는 주로 다음과 같은 용도로 사용한다

    • 인증 (Authorization)

    • 쇼핑 카트 (Shopping carts)

    • 추천 (Recommendations)

    • 유저 정보 (User Session State)

  • How to keep state?

    • 쿠키는 클라이언트의 상태 정보를 저장하고 있음

    • 클라이언트가 서버에 요청을 보낼 때마다 메시지에 쿠키 값을 포함하여 서버가 사용자의 상태를 확인할 수 있도록 한다.

  • 쿠키는 여러가지 개인정보를 담고 있기 때문에, 보안에 매우 민감한 데이터이다.

    • 쿠키를 통해 웹사이트는 사용자의 브라우징 활동, 관심사 등의 통계 정보를 확인할 수 있음

    • 사용자의 ID, 이름, 이메일 주소 등의 개인 정보도 담고 있기 때문에 보안과 밀접한 관계가 있다.

• 예시 : 전자 상점에서 장난감 구매

  • 고객의 브라우저가 BestToys 서버에 요청 메시지를 전달한다.

  • 서버는 고객의 쇼핑 카트를 생성하고, 이를 식별하기 위한 고유 ID(12343)을 할당한다.

  • 해당 쇼핑 카트에 대한 정보가 담긴 쿠키는 클라이언트의 브라우저에 로컬 파일로 저장된다.

  • 클라이언트가 추가 요청을 보낼 때마다 쿠키를 서버에 함께 전송한다.

  • 서버는 쿠키를 통해 해당 고객의 상태(장바구니)를 유지할 수 있으며, 추가적인 요청을 처리한다.

3. Proxy Server

• Proxy Server : 프록시 서버는 클라이언트와 서버 사이에 위치하여 원본 서버를 거치지 않고, 클라이언트의 요청을 처리하도록 동작하는 서버이다.

  • 동작 방식

    • 사용자는 브라우저를 설정하여 요청이 프록시 서버로 전달되도록 설정한다.

    • 클라이언트에서 보낸 HTTP 요청이 프록시 서버로 전달된다.

    • 프록시 서버는 가지고 있는 캐시(Cache)를 확인한다.

    • 요청한 리소스가 캐시에 있는 경우 : 프록시 서버는 캐시의 데이터를 클라이언트에게 반환한다.

    • 요청한 리소스가 캐시에 없는 경우 : 프록시 서버는 원본 서버에 HTTP 요청을 전달하고, 응답 받은 리소스를 캐시에 저장한 뒤 클라이언트에게 전달한다.

  • 프록시 서버의 캐시

    • 서버 역할 : 클라이언트가 요청한 데이터가 캐시에 존재한다면, 요청을 바로 처리할 수 있다. 따라서 클라이언트 입장에서 서버의 역할을 수행한다.

    • 클라이언트 역할 : 요청한 데이터가 캐시에 존재하지 않을 경우, 캐시는 원본 서버에 데이터를 요청한다. 따라서 원본 서버 입장에서의 캐시는 클라이언트의 역할을 수행한다.

    • 캐시는 보통 기업이나 서비스 제공자에 의해 설치된다. (ISP, 대학, 회사, ...)

  • 웹 캐싱의 장점

    • 원본 서버에 요청할 필요를 줄이고, 사용자가 자주 요청하는 데이터를 캐시에서 처리하므로 응답 속도가 빨라짐

    • 반복적인 요청을 모두 캐시로 처리하므로, 원본 서버의 부하를 효과적으로 줄일 수 있음.

    • 인터넷 전반에 걸쳐 캐시가 존재하므로, 소규모 컨텐츠 제공자도 효율적으로 데이터를 제공할 수 있음

    • P2P 네트워크와 유사한 방식으로 데이터를 효율적으로 네트워크에 분산 시킬 수 있음

4. Domain Name System (DNS)

• Domain Name System (DNS) : 우리는 현재 웹 서버에 접근하기 위해 IP 주소를 입력하는 것이 아니라, 특정 도메인(Google, Naver, ...)을 입력한다. DNS는 이러한 도메인 이름과 IP 주소 간의 매핑을 제공하는 클라이언트-서버 기반 디렉토리 시스템이다.

  • 사용자는 웹 브라우저에 도메인 이름(Host name)을 입력한다.

  • 애플리케이션 계층의 파일 전송 클라이언트는 입력된 도메인을 DNS 클라이언트에 전달한다.

  • DNS 클라이언트는 도메인 이름을 IP 주소로 변환하기 위해 DNS 서버에 Query(질의)를 보낸다.

  • DNS 서버는 요청된 도메인 이름에 매핑된 IP 주소를 DNS 클라이언트에게 반호나한다.

  • DNS 클라이언트는 이 IP 주소를 애플리케이션 계층에 전달한다.

  • 애플리케이션 계층(파일 전송 클라이언트)는 IP 주소를 네트워크 계층을 전달하여, 연결이 설정(접속)된다.

• Name Space : 이름 공간은 네트워크 상의 각 호스트에 고유한 이름을 부여하기 위한 체계이다.

  • IP 주소는 고유하기 때문에, 이와 매핑되는 도메인 명도 고유해야 한다. 따라서 이름 공간은 철저하게 관리되어야 한다.

  • Flat Name Space : 모든 도메인이 평면적으로 구성되는 이름 공간

    • 네트워크가 확장되면 이름 관리가 복잡해질 수 있다.

    • 충돌 가능성이 높기 때문에, 규모가 큰 시스템에는 부적합

  • Hierarchical Name Space : 도메인이 여러 서브 도메인으로 구성되어, 상위 도메인과 하위 도메인이 결합하며 고유성이 보장되는 형태이다.

    • 도메인이 계층적으로 형성된다.

    • 예를 들어, www.google.com에서 .com은 google의 서브도메인에 속한다.

    • 확장성이 뛰어나기 때문에 규모가 큰 시스템에 적합하다. 현재 DNS는 이 구조를 사용한다.

  • Zone : 이름 공간의 관리 단위로, 각 Zone은 특정 관리자에 의해 관리된다.

• Domain in Internet : 초기 DNS의 도메인 공간은 다음과 같이 세 가지 섹션으로 나누어졌다.

  • 일반 도메인 (Generic Domain) : 범용적으로 사용되는 도메인이다.

    • .com, .org, .net과 같은 도메인

  • 국가 도메인 (Country Domain) : 국가와 관련된 웹사이트에 주로 사용되는 도메인이다.

    • .kr, .us, .jp과 같이 각 국가를 나타내는 도메인

  • 역방향 도메인 : IP 주소를 기반으로 도메인을 조회하는 방식

    • 인터넷의 급격한 성장으로 인해 역방향 도메인의 관리가 매우 어려워져, 이제는 더이상 사용하지 않음.

4-1. Resolution

• Resolution : 도메인을 주소로 변환하는 과정이며, Resolution은 Recursive 방식과 Iterative 방식으로 나뉜다.

  • Recursive Resolution : 목적지 = engineering.mcgraw-hill.com

    • 클라이언트는 로컬 서버로 도메인 해석 요청을 보낸다.

    • 요청은 로컬 서버로부터 Root 서버, DNS 서버를 거쳐 mcgraw-hill network의 로컬 서버에 도착한다.

    • 로컬 서버는 요청에 대해 응답 메시지를 보내며, 이 메시지는 동일한 경로를 거쳐 로컬 서버로 돌아온다.

    • 최종적으로 클라이언트는 도메인과 매핑된 IP 주소를 얻을 수 있다.

  • Iterative Resolution : 목적지 = engineering.mcgraw-hill.com

    • 클라이언트는 로컬 서버로 도메인 해석 요청을 보낸다.

    • 로컬 서버는 루트 서버로 요청을 전달하며, 루트 서버는 DNS 서버를 참조하도록 응답 메시지를 보낸다.

    • 로컬 서버는 DNS 서버에 요청을 보내며, DNS서버는 mcgraw-hill서버를 참조하도록 응답을 보낸다.

    • 로컬 서버는 mcgraw-hill서버로 요청을 전달하고, mcgraw-hill network의 로컬 서버는 응답을 로컬 서버로 전달한다.

    • 로컬 서버는 클라이언트에게 응답하며, 최종적으로 클라이언트는 도메인과 매핑된 IP 주소를 얻을 수 있다.

• Caching (캐싱) : DNS 서버가 외부 도메인에 대한 해석 요청을 받을 때, 검색 시간을 줄이고 효율성을 높이기 위해 사용되는 메커니즘이다.

  • DNS 서버가 요청을 받았을 때, 해당 도메인에 대한 정보가 캐시에 없다면 다른 외부의 DNS 서버에 접근해야 한다.

    • 이때 ARP를 활용하며, 얻어온 결과는 DNS 서버의 캐시에 저장한다.

  • 해당 도메인에 대한 정보가 캐시에 있다면, 해당 정보를 바로 반환할 수 있다.

    • 캐시 데이터는 유효 기간이 존재하며, 일정 시간이 지나면 삭제된다.

• DNS Resource Records : 특정 도메인 이름에 대한 속성을 정의하는 데이터 구조로, 클라이언트의 요청에 응답하기 위해 사용된다.