웹과 HTTP 동작방식 - 비지속, 지속 연결 HTTP, 쿠키, 캐시(프록시 서버)

[목차여기]

 

 

Web은 온디맨드 방식으로 동작한다. 온디맨드(On Demand) 방식이란 클라이언트 프로그램에서 요구를 하면 그 요구를 전달해 주는 것이다. 그래서 필요할 때만 리소스를 가지고 올 수 있다. 그리고 HTTP는 응용(Application) 계층 프로토콜이다. HTTP는 메시지의 구조 및 클라이언트와 서버가 메시지를 어떻게 교환하는지에 대해 정의하고 있다.

 

웹 브라우저는 HTTP의 클라이언트 측을 구현하고, 웹 서버는 HTTP의 서버 측을 구현한다. 웹 브라우저는 요구한 웹 페이지를 보여주고 여러 가지 인터넷 향해와 구성 특성을 제공한다. 또한 웹 서버는 URL로 각각을 지정할 수 있는 웹 객체를 가지고 있다. 따라서 HTTP는 웹 클라이언트가 웹 서버에게 웹 페이지를 어떻게 요청하는지와, 서버가 클라이언트로 어떻게 웹 페이지를 전송하는지를 정의한다.

 

* 웹 브라우저는 HTTP의 클라이언트 측을 구현하기 위해 웹의 관점에서 브라우저와 클라이언트라는 용어를 혼용하여 사용할 것이다. 

 

 

이제부터 비지속 연결 HTTP와 지속 연결 HTTP, HTTP의 다양한 버전에 대해서 공부할 것이다. 그전에 TCP에 대한 배경지식이 필요하다. TCP에 대해서 간단히 설명하자면, 전송 계층의 프로토콜이며 연결지향형 서비스에서 사용하고 신뢰성이 높다. 자세한 설명은 아래 링크를 참고하면 좋겠다.

TCP, UDP 란? - 특성, 비교

 

 

비지속 연결 HTTP

비지속 연결이라는 단어에서 어떤 상황이 연상되는가? 연결을 계속하지 않는다, 끊는다 등의 의미를 떠올릴 수 있다. 떠올린 것 그대로 연결을 중간에 끊는 행위가 있다. 아래의 시나리오 상황을 통해 이해해 보자.

 

http://www.school.edu/department/home.index 

 

1. HTTP 클라이언트는 HTTP의 기본 포트 번호인 80을 통해 http://www.school.edu 서버로 TCP 연결을 시도한다. 연결이 완료되면 클라이언트와 서버에 각각 소켓이 존재하게 된다.
2. HTTP 클라이언트는 1단계에서 설정된 TCP 소켓을 통해 서버로 HTTP 요청 메시지를 보낸다. 이때 /department/home.index 경로를 포함하여 보낸다.
3. HTTP 서버는 1단계에서 설정된 TCP 연결 소켓을 통해 요청 메시지를 받는다. 저장 장치로부터 /department/home.index 객체를 추출한다. HTTP 응답 메시지에 그 객체를 캡슐화한다. 그리고 응답 메시지를 소켓을 통해 클라이언트로 보낸다.
4. HTTP 서버는 TCP에게 TCP 연결을 끊으라고 한다. 하지만 실제로 TCP 클라이언트가 응답 메시지를 올바로 받을 때까지 연결을 끊지 않는다.
5. HTTP 클라이언트가 응답 메시지를 받으면 TCP 연결이 중단된다. 메시지는 캡슐화된 객체가 HTML 파일인 것을 나타낸다.

 

4단계에서 서버가 객체를 보고 클라이언트가 응답 메시지를 받으면 각 TCP 연결이 끊어지므로 비지속 연결을 사용하고 있는 것이다. 이것을 비지속 연결 HTTP라고 한다.

 

지속 연결 HTTP

비지속 연결은 매번 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 한다는 단점이 있다. TCP 버퍼가 할당되어야 하고 TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 한다. 이것은 수많은 클라이언트들의 요청을 동시에 서비스해야 하는 웹 서버에 부담이 된다. 

 

HTTP/1.1

• HTTP/1.1은 서버가 응답을 보낸 후에 TCP 연결을 그대로 유지한다.
• 같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내진다.
• 그리고 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어질 수 있다.(파이프라이닝)
• 일반적으로 HTTP 서버는 일정 기간(타임아웃) 사용되지 않으면 연결을 닫는다.

HTTP/1.1은 지속적인 TCP 연결을 이용하여 하나의 TCP 연결 상에서 서버로부터 클라이언트로 보내지는 웹 페이지를 허용한다. 웹 페이지 당 오직 하나의 TCP 연결을 가지기 때문에 서버에서의 소켓 수를 줄이며 전송되는 각 웹 페이지는 공정한 네트워크 대역폭을 가질 수 있다. 그러나 하나의 TCP 상에서 웹 페이지에 있는 모든 객체를 보내면 HOL(Head of Line) 블로킹 문제가 발생할 수 있다.

 

HOL 블로킹이란, 만약에 한 웹 페이지 상단에 비디오 클립이 있다고 가정하면 작은 객체들은 비디오 클립 뒤에서 기다림이 길어지며 비디오 클립이 뒤에 오는 작은 객체들을 블로킹하게 되는 현상이다.

 

HTTP/1.1 브라우저에서는 여러 개의 병렬 TCP 연결을 열어서 HOL 블로킹 문제를 해결했다. TCP 혼잡 제어(Congestion Control)는 각 TCP 연결이 공정하게 병목 링크를 공유하여 같은 크기의 가용한 대역폭을 공평하게 나누게 해 준다고 불 수 있다. 우리가 웹 페이지에 접속했을 때 텍스트는 먼저 로딩되고 비디오는 나중에 로딩되는 것이 이 블로킹을 해결한 모습이다.

 

쿠키

우리가 인터넷 쇼핑을 할 때 내가 지난번 장바구니에 담아둔 옷이 그대로 담겨있는 현상을 본 적이 있을 것이다. 이것은 웹 사이트가 사용자를 확인할 수 있었기 때문이다. HTTP 쿠키는 사이트가 사용자를 추적하게 해 준다.

 

쿠키의 기술은 네 가지다.

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

예시 시나리오를 통해 이해해 보자.

1. 네이버 웹 서버에 요청이 들어올 때 그 서버는 유일한 식별번호를 만들고 이 식별번호로 인덱싱 되는 백엔드 데이터베이스 안에 엔트리를 만든다. 그리고 네이버 웹 서버는 응답 메시지에 식별 번호를 담고 있는 Set-Cookie: 헤더를 포함시킨다. Set-Cookie: 1623
2. 은서가 응답 메시지를 받으면 브라우저는 관리하는 특정한 쿠키 파일에 그 라인을 덧붙인다. 그리고 다시 웹 페이지에 요청을 할 때 은서의 브라우저는 쿠키 파일을 참조하고 이 사이트에 대한 은서의 식별번호를 읽어서 HTTP 요청에 식별번호를 포함하는 쿠키 헤더 파일을 넣는다. Cookie: 1623
3. 네이버 웹 사이트는 은서의 이름을 몰라도 1623 사용자가 어는 페이지를 어떤 순서로 몇 시에 방문했는지 정확히 알 수 있다.

 

웹 캐시(= 프록시 서버)

캐시라는 것은 데이터베이스에 접근하지 않고 이미 사용된 데이터를 저장하여 속도와 성능면에서 우수할 수 있도록 한다. 웹 캐시도 마찬가지로 자체의 저장 디스크를 가지고 있기 때문에 최근에 사용된 객체의 사본을 저장한다. 그래서 모든 HTTP의 요구가 웹 캐시에 가장 먼저 보내지도록 한다.

 

예시 시나리오를 통해 이해해 보자

http://www.school.edu/department/home.index 

 

1. 브라우저는 웹 캐시와 TCP 연결을 설정하고 브라우저가 웹 캐시에 있는 객체에 대한 HTTP 요청을 보낸다.
2. 웹 캐시는 객체의 사본이 자신에게 저장되어 있는지 확인한다. 만약 저장되어 있다면 웹 캐시는 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체를 전송한다.
3. 만약 저장되어 있지 않다면, 웹 캐시는 기점 서버인 http://www.school.edu로 TCP 연결을 설정한다. 그리고 웹 캐시는 서버로 HTTP 요청을 보낸다. 이 요청을 받은 서버는 웹 캐시로 HTTP 응답 메시지와 함께 객체를 보낸다.
4. 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메시지와 함께 객체의 사본을 전달한다.

이 경우는 캐시가 서버이면서 클라이언트라고 할 수 있다. 그런데 하나의 문제점이 있다. 캐시의 고전적인 문제인데, 캐시에 저장된 객체의 복사본이 새 값이 아닐 수 있다는 것이다. 그래서 조건부 GET이라는 개념이 등장한다. 

 

조건부 GET

HTTP는 클라이언트가 브라우저로 전달되는 모든 객체가 최신이라는 것을 확인하면서 캐싱하게 해주는 방식을 가지고 있다. 이러한 방식을 조건부 GET이라고 한다.

 

1. 브라우저의 요청을 대신하여 프록시 서버는 요청 메시지를 웹 서버로 보낸다.
2. 웹 서버는 프록시 서버에게 객체를 담은 응답 메시지를 보낸다.
3. 캐시는 요청한 브라우저에게 객체를 보내주고 자신에게도 객체를 저장한다. 이때 객체와 함께 마지막으로 수정된 날짜를 함께 저장한다.
4. 몇 주 후에 다른 브라우저가 같은 객체를 캐시에게 요청하면 객체는 여전히 저장되어 있으므로 브라우저는 조건부 GET으로 갱신 여부를 조사한다.
5. 이때 조건부 GET은 서버에게 그 객체가 명시된 날짜 이후 수정된 경우에만 그 객체를 보내라고 말한다.

 

HTTP/2 

• HTTP/2의 목적은 하나의 웹 페이지를 전송하기 위한 병렬 TCP 연결의 수를 줄이거나 제거하는 데 있다.
• 이를 위해 Frame으로 쪼개서 Round-Robin 방식을 사용한다. ➡️ HTTP/2 프레이밍, 프레임 인터리빙(Frame Interleaving)

예를 들어, 하나의 큰 비디오 클립과 8개의 작은 객체가 있다고 생각하자. 서버는 이 웹 페이지를 확인하기 위해 9개의 병렬 요청을 받게 된다. 그리고 서버는 9개의 HTTP 응답 메시지를 브라우저로 보내야 한다. 

비디오 클립 : 1000개의 프레임

작은 객체들 : 2개의 프레임

 

인터리빙이 사용된다면 비디오 클립의 한 프레임 전송, 소형 객체의 첫 번째 프레임 전송, 비디오 클립의 한 프레임 전송, 소형 객체의 첫 번째 프레임 전송, ... 이렇게 반복되기 때문에 모든 소형 객체는 18개의 프레임을 보낸 후에 전송된다.

 

그런데 만약 인터리빙이 사용되지 않는다면 모든 소형 객체들은 1016(1000+2*8) 개의 프레임을 보낸 후에 전송된다.

 

HTTP/3

• HTTP/3는 QUIC 위에서 작동되도록 설계된 새로운 HTTP 프로토콜이다.
• QUIC이란 UDP 프로토콜 위에 위치하는 응용계층에 구현되어 있는 것으로, 메시지 멀티플렉싱(인터리빙) 스트림별 흐름 제어, 저지연 연결 확립과 같은 HTTP에 의미 있는 여러 특징을 갖는다.