[네트워크] 2.2 웹과 HTTP

▶ 웹

• 어플리케이션
• 온디멘드 방식: 사용자는 그들이 원할 때 원하는 것을 수신한다.

 

2.2.1 HTTP 개요

▶ HTTP

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

 

▷ 웹 페이지(Web page)

웹 페이지(Web page)는 객체들로 구성된다.

• 객체(object): 단순히 단일 URL로 지정할 수 있는 하나의 파일(HTML 파일, JPEG 이미지, 자바스크립트, CCS 스타일 시트 파일, 비디오 클립 등)

--> 대부분의 웹 페이지는 기본 HTML 파일과 여러 참조 객체로 구성된다.

 

▶ HTTP

• 웹 브라우저(Web browser): HTTP의 클라이언트 측을 구현한다.
• 웹 서버(Web server): HTTP의 서버 측을 구현한다.

 

▶ TCP: HTTP의 전송 프로토콜

• HTTP 클라이언트: TCP 연결 시작
• HTTP 서버
  --> TCP 연결이 시작되면, 클라이언트와 서버 프로세스는 소켓 인터페이스를 통해 TCP로 접속한다.

HTTP는 데이터 손실 또는 TCP가 어떻게 손실 데이터를 복구하고 네트워크 내부에서 데이터를 올바른 순서로 배열하는지 걱정할 필요가 없다. 이것은 TCP와 프로토콜 스택의 하위 계층들이 하는 일이다.

 

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

 

 

2.2.2 비지속 연결과 지속 연결

: 각 요구/응답 쌍이 분리된 TCP 연결을 통해 보내져야 하는가? 혹은 모든 요구/응답이 같은 TCP 연결 상으로 보내져야 한는가?

HTTP/1.0: 비지속 연결 HTTP (non-persistent TCP connection)

비지속 연결 HTTP (non-persistent TCP connection)

예) 웹 페이지를 서버에서 클라이언트로 전송하는 단계를 살펴보자. 페이지가 기본 HTML 파일과 10개의 JPEG 이미지로 구성되고, 이 11개의 객체가 같은 서버에 있다고 가정하자. 

기본 HTML 파일의 URL: http://www.someSchool.edu/someDepartment/home.idex

1. HTTP 클라이언트: HTTP의 기본 포트 번호 80을 통해, www.someSchool.edu 서버로 TCP 연결을 시도한다.
   TCP 연결: 클라이언트 소켓 - 서버 소켓
2. HTTP 클라이언트: TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지를 보낸다.
3. HTTP 서버: TCP 연결 소켓을 통해 요청 메시지를 받는다. 저장장치로부터 /someDepartment/home.index 객체를 추출한다. HTTP 응답 메시지에 그 객체를 캡슐화한다. 그리고 응답 메시지를 소켓을 통해 클라이언트로 보낸다.
4. HTTP 서버: TCP 연결을 끊는다.
5. HTTP 클라이언트가 응답 메시지를 받으면, TCP 연결이 중단된다.
6. 그 이후에 참조되는 각 JPEG 객체에 대해 처음 네 단계를 반복한다. --> 사용자가 웹 페이지를 요청할 때 11개의 TCP 연결이 만들어진다.

 

▶ 세 방향 핸드셰이크(three-way handshake)

1. 클라이언트: TCP 메시지를 서버로 보낸다. -- TCP 연결 초기화
2. 서버: 응답한다. -- TCP 연결 수락
   --> 1 RTT
3. 클라이언트: 응답하고, 요청한다. -- 파일 요청
4. 서버: 응답한다. -- 파일 전송 (+ 파일 전송 시간)
5. 클라이언트 (+ 전체 파일 수신 시간)

 

HTTP/1.1: 지속 연결 HTTP (persistent TCP connection)

▷ HTTP/1.0 (비지속 연결) Problem:

• 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 한다.
• 각 객체는 2 RTT를 필요로 한다. (TCP 연결 설정, 객체 요청/수신)

▷ HTTP/1.1 (지속 연결) Solution:

: 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지한다. 따라서 전체 웹 페이지(앞 예에서는 기본 HTML 파일과 10개의 이미지)를 하나의 지속 TCP 연결을 통해 보낼 수 있다.

• 파이프라이닝: 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어질 수 있다.
  - 서버가 연속된 요구를 수신할 때, 서버는 객체를 연속해서 보낸다.
  - HTTP 디폴트 모드는 파이프라이닝을 이용한 지속 연결을 사용한다.

HTTP/1.1 파이프라이닝

 

2.2.3 HTTP 메시지 포멧

HTTP 요청 메시지

HTTP 요청 메시지

▶ 요청 라인(request line): 방식, URL, 버전

• 방식: GET, POST, HEAD, PUT, DELETE 등
  - GET: 브라우저가 URL 필드로 식별되는 객체를 요청할 때 사용한다. 
  - POST: 사용자가 폼을 채워넣을 때(예: 사용자가 검색 엔진에 검색 단어를 넣을 때) --> 개체 몸체(body)
  - HEAD: 요청 객체는 보내지 않는다. (예: 디버깅)

▶ 헤더 라인(header line): 헤더 필드 이름, 값

▶ 공백 라인

▶ 개체 몸체(body)

 

HTTP 응답 메시지

HTTP 응답 메시지 // 상태 라인 sample codes

▶ 상태 라인: 버전, 상태 코드, 문장

▶ 헤더 라인: 헤더 필드 이름, 값

▶ 공백 라인

▶ 객체 몸체

 

 

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

HTTP 서버는 상태를 유지하지 않는다. 이것은 서버 설계를 간편하게 하고, 동시에 수천 개의 TCP 연결을 다룰 수 있는 고성능의 웹 서버를 개발하게 해주었다. 그러나 서버가 사용자 접속을 제한하거나, 사용자에 따라 콘텐츠를 제공하기 원하므로, 웹사이트가 사용자를 확인하는 것이 바람직할 때가 있다.

--> HTTP는 쿠키(cookie)를 사용하여 사이트가 사용자를 추적하게 해준다.

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

▶ 쿠키(cookie)

• cookie file: 사용자 브라우저에 사용자 종단 시스템과 관리를 지속시킨다.
• backend database: 웹사이트의 백엔드 데이터베이스
• HTTP 요청/응답 메시지 쿠키 헤더 라인

 

Case 1) 수잔이 처음으로 아마존 닷컴에 접속했을 때:

1. 서버: 유일한 식별번호(cookie)를 만들고, 이 식별번호로 인덱싱되는 backend database 안에 엔트리를 만든다. 
   --> 클라이언트에 응답한다. (Set-cookie: 1678) 헤더를 포함한다.
2. 클라이언트 - cookie file에 (Set-cookie 1678) 헤더 라인, 식별번호를 추가한다.

Case 2) 수잔이 다시 아마존 닷컴에 접속했을 때:

1. 클라이언트: (cookie 1678) 헤더 라인을 포함한 request message를 보낸다.
2. 서버: cookie-specific action

 

 

2.2.5 웹 캐싱

▶ 웹 캐시(Web cache, 프록시 서버(proxy server))

: 웹 서버(origin Web server)를 대신하여 HTTP 요구를 충족시키는 네트워크 개체

웹 캐싱

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

 

- 일반적으로 웹 캐시는 ISP가 구입하고 설치한다.

 

▷ 웹 캐시의 장점:

• 클라이언트의 요구에 대한 응답 시간을 줄일 수 있다. 
• 한 기관에서 인터넷으로 접속하는 링크 상의 웹 트래픽을 대폭으로 줄일 수 있다.
  --> 웹 트래픽을 줄이면, 기관(회사, 대학)은 자주 대역폭을 개선할 필요가 없어져, 비용을 줄일 수 있다.
  --> 인터넷 전체의 웹 트래픽을 실질적으로 줄임으로써 모든 애플리케이션을 위한 성능을 개선한다.

Caching motivation

Solution

 

조건부 GET (conditional GET)

▶ 웹 캐싱: Problem

: 사용자가 느끼는 응답 시간을 줄일 수 있지만, 새로운 문제를 야기한다. 즉, 캐시 내부에 있는 객체의 복사본이 새것이 아닐 수 있다는 점이다. 다시 말해, 복사본은 클라이언트에 캐싱된 이후에 웹 서버에 있는 객체가 갱신되었을 수도 있다.

 

▶ Solution: 조건부 GET

: 클라이언트가 브라우저로 전달되는 모든 객체가 최신의 것임을 확인하면서, 캐싱을 하는 방식

조건부 GET

• HTTP 요청 메시지
  - GET 방식
  - If-Modified-Since: <date>
• HTTP 응답 메시지
  - object not modified after <date>: HTTP/1.0 304 Not Modified --> "요청 객체의 캐싱된 복사본을 사용하라."
  - object modified after <date>: HTTP/1.0 200 OK <data> --> 새로운 <data> 제공

 

 

2.2.6 HTTP/2

HTTP/2의 주요 목표 중 하나는 TCP 연결 상에서 멀티플렉싱 요청/응답 지연 시간을 줄이는 데 있으며, 요청 우선순위화, 서버 푸시, HTTP 헤더 필드의 효율적인 압축 기능 등을 제공한다.

HTTP/2는 상태 코드, URL, 헤더 필드 등 HTTP 메소드 자체는 변경하지 않았다. 대신에 HTTP/2는 클라이언트와 서버 간의 데이터 포맷 방법과 전송 방법을 변경했다.

• HTTP/1.0: Non-persistent TCP
• HTTP/1.1: Persistent TCP, 파이프라이닝
  - 지속적인 TCP 연결을 이용하여 하나의 TCP 연결 상에서 서버로부터 클라이언트로 보내지는 웹 페이지를 허용한다. 웹 페이지당 오직 하나의 TCP 연결을 가짐으로써, 서버에서 소켓 수를 줄이며 전송되는 각 웹 페이지는 공정한 네트워크 대역폭을 가질 수 있다.
  - Problem: HOL(Head of Line) 블로킹 문제

HTTP/1.1 - Problem: HOL(Head of Line) 블로킹 문제

 

HTTP/2 프레이밍

- Solution: 각 메시지를 작은 프레임으로 나누어 인터리빙하고, 반대편 사이트에서 재조립한다.

Solution: 각 메시지를 작은 프레임으로 나누어 인터리빙하고, 반대편 사이트에서 재조립한다.

 

메시지 우선순위화 및 서버 푸싱

▶ 메시지 우선순위화 (message prioritization)

: 요청들의 상대적 우선순위를 조정할 수 있게 함으로써, 애플리케이션의 성능을 최적화할 수 있게 한다.

 

▶ 서버 푸싱

: HTTP/2의 또 다른 특징은 서버로 하여금 특정 클라이언트 요청에 대해 여러 개의 응답을 보낼 수 있게 해주는 데 있다. 처음 요청에 대한 응답 외에도, 서버는 클라이언트의 요청 없이도 추가적인 객체를 클라이언트에게 푸시하여 보낼 수 있다. 객체에 대한 HTTP 요청을 기다리는 대신, 서버는 HTML 페이지를 분석할 수 있으며, 필요한 객체들을 식별할 수 있고, 해당 객체들에 대한 요청이 도착하기도 전에 해당 객체들을 클라이언트로 보낸다.

 

HTTP/3

: UDP