애플리케이션 계층 - 웹과 HTTP

1990년대초, 네트워크 애플리케이션인 월드와이드웹이 등장하였다.

웹은 기존의 TV나 라디오 송출과는 달리 온디맨드 방식으로 사용자가 원할 때, 원하는 페이지를 수신하고 웹상에 사용자가 원하는 정보를 발행할 수도 있다.

HTTP 개요

HTTP 프로토콜은 웹의 어플리케이션 계층 프로토콜이다. HTTP 프로토콜은 클라이언트와 서버 프로그램으로 구현된다. 각 프로그램들은 서로 메세지 교환을 통해 통신을 한다. 따라서 HTTP 프로토콜은 주고 받는 메세지의 구조, 어떻게 메세지를 교환하는지에 대해 정의하고 있다.

구성 요소

• 웹 페이지 (web page)
  • 웹 페이지는 여러 객체들로 이루어지는데 여기서 객체란 단일 URL로 지정할 수 있는 하나의 파일이다.
    • 파일의 예시 : HTML 파일, JPEG 이미지, 자바스크립트, CSS 파일, 비디오 클립 등등
  • 기본적으로 웹페이지는 기본 HTML파일과 여러 참조 객체들로 이루어 져있다.
    • 예시 : 기본 HTML 파일 + 5개의 이미지 파일
  • URL (Uniform Resource Locator)
    • 네트워크상에 자원이 어디 있는지 알려주는 주소로서 호스트 이름, 객체의 경로 이름을 가지고 있다.
    • 호스트이름 : ko.wikipedia.org
    • 객체 경로 이름 : /wiki/URL
• 웹 브라우저 (Web Browser)
  • HTTP의 클라이언트 측을 구현한 프로그램
  • HTML 파일을 요청, 분석, 출력하는 역할
• 웹 서버 ( Web Server)
  • HTTP의 서버 측을 구현한 프로그램
  • URL로 지정된 웹 객체를 가지고 있고 클라이언트에 요청에 알맞은 응답을 한다.

전송계층 프로토콜

HTTP는 전송계층 프로토콜로 TCP를 사용한다. 3-way 핸드세이크를 사용하여 우선 서버와 TCP연결을 하고 소켓을 통해 메세지를 전송계층으로 내려보낸다.

TCP 프로토콜을 사용하기 때문에 TCP가 제공하는 신뢰적인 데이터 전송 서비스를 제공받을 수 있다.

비상태(Stateless) 프로토콜

HTTP 프로토콜에서 서버는 클라이언트에 관한 어떠한 상태 정보도 저장하지 않기 때문에 비상태 프로토콜이라고 불린다.

비지속 연결과 지속 연결

요청과 응답 쌍이 별도의 분리된 TCP 연결상에서 보내지는 경우를 비지속연결이라고 한다.
반대로 요청과 응답 쌍이 같은 TCP 연결상에서 보내지는 경우를 지속연결이라고 한다.
HTTP 1.0 버젼에서는 비지속연결을 지원하였고 HTTP 1.1에서 지속연결을 지원하게 되었다.

• 예시
  • 가정 : 1개의 기본 HTML파일 + 5개의 JPEG 이미지 파일을 가지는 페이지가 있다고 가정
  • 비지속 연결 : 총 6번의 TCP연결 필요
    • 비지속 연결의 단점
      • 수많은 클라이언트들이 동시에 서버로 요청을 하게되면 많은 TCP연결이 필요하기 때문에 서버에 부담을 줌
  • 지속 연결 : 총 1번의 TCP연결 필요 → 일정 시간동안 사용되지 않으면 연결을 닫음
• 파이프라이닝 (pipelining)
  • 지속연결을 사용하게 되면 요청에 대한 응답을 기다리지않고 남아있는 요청을 할 수 있는데 이를 파이프라이닝이 가능케한다.

HTTP 메세지 포멧

요청 메시지

GET /somedir/page.html HTTP/1.1
HOST: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
// 공백라인
data~~~~~~~~data~~~~~~~~

• 메시지가 일반 ASCII로 적혀있어 사용자가 이해하기 편하다.
• 요청 메시지의 첫줄은 요청 라인(request line)이라고 하고 이후의 줄들은 헤더 라인(header line)이라고 한다.
• 요청라인은 3개의 필드(방식(method) 필드, URL 필드, HTTP버전 필드)를 가지고 있다.
  • 방식 필드
    • GET, POST, HEAD, PUT, DELETE
• 헤더라인
  • HOST : 객체가 존재하는 호스트를 명시한다. 추후 웹 캐시에서 캐싱되어 있는 정보를 찾을 때 사용된다.
  • Connection : 서버가 지속/비지속 연결을 지원하는지 알려줌
  • User-agent : 클라이언트 브라우저의 타입
• 빈줄이후 개체의 몸체(entity body)가 있다.
  • GET 방식에서 개체의 몸체는 존재하지 않고 POST에서는 존재한다.

응답 메시지

HTTP/1.1 200 OK
Connection: close // 메시지를 보내고 TCP 연결을 닫는다
Date: Tue, 18 .... // 응답 메세지를 보낸 시간
Server: Apache/2.2.3 (CentOS) // 서버 프로그램
Last-Modified: TUE. 18 ... // 객체가 생성되 시간 or 마지막으로 수정된 시간
Content-Length: 6821 // 송신되는 객체의 바이트 수
Content-Type: text/html // 개체 몸체의 종류

data~~~~~data~~~~

• 3개의 섹션으로 구성됨
  • 요청 라인 : 1번째 라인
  • 헤더라인 : 요청라인 아래 6줄
  • 개체 몸체
• 요청라인
  • 3개의 필드로 구성됨
    • 버전 필드 : HTTP/1.1
    • 상태 코드 : 200
    • 상태 메시지 : OK

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

HTTP 프로토콜은 기본적으로 비상태 프로토콜이라고 하였다. 서버가 클라이언트의 상태 정보를 저장하지 않기 때문에 수천개의 TCP연결을 다룰 수 있는 고성능 서버를 설계하는데 도움이 되었다.
하지만 서버가 사용자의 접속을 제한하거나 사용자에 따른 추천 콘텐츠를 제공해야 하기 때문에 웹사이트가 사용자를 확인해야할 경우가 생기게 되었다. 이를 위해 쿠키(Cookie)를 사용하게 되었다. 서버는 쿠키를 통해 사용자를 추적할 수 있게 되었다.

쿠키가 작동하는 방식

1. 웹 서버에 요청이 들어올 때, 서버는 유일한 식별 번호를 만들고 백앤드 데이터 베이스 안에 해당 번호로 인덱싱되는 엔트리를 만든다.
2. 서버는 해당 식별번호를 포함하는 응답을 클라이언트에게 보낸다.
   1. Set-cookie: 1678
3. 클라이언트는 관리하는 쿠키파일에 식별번호를 추가한다.
4. 추후 클라이언트가 동일한 호스트에 요청을 보낼 때, 쿠키 파일을 참고 하여 식별번호르 추출하고 해당 내용을 요청 메시지의 헤더에 넣고 요청을 보낸다.
5. 서버는 쿠키 번호를 가지고 사용자가 어떤 페이지를 어떤 순서로 방문을 하였는지 등등 여러 정보를 알 수 있고 이에 따라 알맞는 컨텐츠를 보내 줄 수 있게 된다.
   1. 예시 : 아마존의 쇼핑카트 서비스

웹 캐싱

웹 캐시(Web cache, 프록시 서버(proxy server)라고도 함)는 웹서버를 대신하여 웹 요청을 응답해주는 네트워크개체이다. 웹캐시는 저장 디스크를 가지고 있어서 최근에 호출된 객체의 사본을 저장 및 보존하여 캐싱의 역할을 수행 할 수 있다.

웹 캐싱 작동 방식

1. 브라우저는 우선 웹 캐시와 TCP연결을 하여 웹 캐시에 HTTP 요청을 보낸다.
2. 웹 캐시는 객체의 사본이 저장되어 있는지 확인하고 저장되어 있다면 객체를 클라이언트에게 보낸다.
3. 저장되어 있지 않다면 웹 캐시는 실제 서버에 TCP연결을 하고 객체 요청을 한다.
4. 실제 서버는 요청에 대한 응답을 웹 캐시에게 하고 웹 캐시는 응답받은 객체를 로컬에 저장한뒤 클라이언트에게 객체를 보낸다.

위 작동 방식에서 보면 알 수 있듯이 캐시는 서버이자 클라이언트가 될 수 있다.

웹 캐시 사용 이유

• 클라이언트의 요청에 대한 응답시간을 단축할 수 있다.
• 한 기관에서 인터넷으로 접속하는 링크상의 웹 트래픽을 줄일 수 있다. 나아가 인터넷 전체의 웹 트래픽을 줄이는데 큰 역할을 한다.

조건부 GET

웹 캐시를 사용할 때, 생길 수 있는 문제점으로는 캐시에 저장되어 있는 객체가 최신의 객체가 아닐 수 있다는 것이다. 캐싱된 이후에 웹 서버의 원본 객체가 수정되었을 수 있기 때문이다. 조건부 GET을 활용한다면 이 문제를 해결 할 수 있다.

조건부 GET 작동방식

1. 캐시는 객체를 저장하고 클라이언트에 객체를 보낼 때, 마지막으로 수정된 날짜를 같이 응답한다.
   1. Last-Modifed : ……
2. 시간이 지나 클라이언트(웹 캐시)는 조건부 GET을 사용하여 갱신 여부를 조사한다.
   1. If-Modified-since : …….
3. 실제 서버는 마지막으로 수정된 날짜를 확인하여 날짜가 일치하지 않는다면 새로운 객체를 보내고 일치한다면 Not Modified 상태라인을 응답한다. (복사본을 사용해도 좋다는 의미)

HTTP/2

2015년에 HTTP/2 가 표준화 되었고 현재의 대부분의 주요 브라우저가 지원하고 있다.

HTTP/1.1에서의 문제

• 하나의 TCP연결에서 웹페이지의 모든 객체를 보내면 HOL(Head of Line)블로킹 문제가 발생함
  • HOL블로킹 문제
    • 웹페이지의 상단에 큰 용량의 비디오 객체가 있다면 비디오 객체를 전송하는 동안 비디오 뒤의 작은 객체들이 기다려야 하는 상황이 발생하는데 이때 비디오 객체가 작은 객체들을 블로킹하게 됨
  • 1.1 버전에서 블로킹 문제 해결
    • 여러 개의 병령 TCP 연결을 열어 (최대 6개) 해결함

HTTP/2의 목표

• 하나의 TCP 연결상에서 멀티플렉싱 요청/응답의 지연속도를 줄이자
  • 구현 : 클라이언트 서버 간의 데이터 포맷 방법 및 전송 방법을 변경함
• 해결 방법
  • 프레이밍
    • 각 메세지를 작은 프레임으로 나누고, 같은 TCP 연결에서 요청과 응답 메시지를 인터리빙함
      • 인터리빙 : 끼워넣기
      • 객체를 잘게 쪼개서 조각 조각 순서대로 보내게 되면 작은 객체들이 큰 객체보다 먼저 전송될 수 있음
      • 쪼개진 객체는 반대편에서 조립됨
  • 메시지 우선 순위화 및 서버 푸싱
    • 클라이언트가 하나의 서버로 동시에 요청을 할때, 요청에 우선순위를 매길 수 있음
    • 서버가 HTML 페이지를 분석하여 클라이언트의 요청이 없이도 응답을 푸싱할 수 있음