[컴네/CN] HTTP와 Cookie

⭐️Review⭐️

HTTP/1.1

위 사진은 HTTP/1.1의 헤더의 모습이며, TCP 연결 재사용을 위해 헤더에서는 Keep-Alive 필드로 표시한다.

Keep-Alive 필드는 timeout이라는 최소 시간 동안 max 시간까지 TCP 연결을 유지하라는 의미를 가지고 있다.

 

HTTP/1.1은 한 개의 TCP 연결만을 사용하는 것이 아니라 여러 개의 TCP 연결을 사용하는데

TCP 연결이 너무 많이 생성되면 자원 관리 차원에서 문제가 발생하므로

성능 관리를 위해 브라우저에서는 도메인 당 최대 연결 수를 제한한다.

 

HTTP/1.1 domain sharding

HTTP/1.1은 pipelining을 사용하기 때문에 HoL 병목 현상이 발생한다.(이전 포스트 참고)

따라서 해당 pipelining은 많이 구현되지 않고 domain sharding을 사용한다.

domain sharding을 사용하지 않을 때의 데이터 전송 방식을 보자.

resource 제한으로 인해 데이터를 2개씩 나누어 전송하고 있다.

 

domain sharding은 여러 도메인 연결 제한을 피하기 위해 순차적인 직렬 연결을

동시적으로 데이터를 전송할 수 있는 병렬 요청으로 바꾸어 데이터를 전송하는 방법이다.

(순차 직렬 연결 -> 동시 병렬 요청)

이 말을 간단하게 하자면, 도메인 서버를 여러 개 두는 방식으로

동일한 서버를 주소만 다르게 설정하여 다른 도메인으로 접속한다는 뜻이다.

위 그림을 보면 하나의 브라우저에서 두 개의 도메인으로 연결하여

병렬로 여러 개의 데이터를 한 번에 전송하는 모습을 확인할 수 있다.

이러한 방법은 HTTP/2에서는 사용하지 않는데

HTTP/2에서는 sharding을 사용하지 않고도 병렬적 처리가 가능하기 때문이다.

이러한 sharding 방법은 DB에서의 sharding와 동일하다.

 

HTTP/2

HTTP/2는 HTTP/1.1의 성능 개선을 목표로 하여 탄생한 것이다.

기존의 text(ASCII)로 전달되던 데이터를 binary로 인코딩하여 성능을 높였다.

또한 기존에 존재하던 메소드, api, 라이브러리 등을 그대로 사용하고,

프로토콜의 자체적인 성능을 개선한 방식이다.

 

HTTP/1.1에서는 TCP를 여러 개 사용하여 커넥션에 대한 개수가 제한되어 있었고,

TCP 연결을 바꿔가며 통신을 하기에는 낭비가 존재했다.

따라서 single connection, 즉 하나의 TCP 연결을 사용하여

브라우저의 limit에 걸리지 않고 많은 연결을 멀티플렉싱하였다.

 

멀티플렉싱을 통해 여러 개의 요청을 동시에 처리하기가 가능하여

다른 요청이 끝나기까지 요청이 대기하는 현상이 줄어들었고,

asset 파일들을 여러 개의 작은 사이즈로 나누는 청크를 수행한 후

웹 페이지 로딩 시 분할된 청크를 빠르게 응답하는 등 성능이 크게 향상되었다.

브라우저에서 HTTP/2도 도메인 당 TCP 연결을 수행하였으며

connection 1개에서 여러 개의 resource를 요청한다.

 

HTTP Cookie

HTTP는 자체로 상태를 가지지 않으므로 다양한 정보에 대한 기억 여부는 http 프로토콜과 무관하다.

그렇다면 현재 우리가 사용하고 있는 브라우저에서는 어떻게 우리의 정보를 기억하고,

우리의 선호도에 맞는 광고를 내보낼 수 있을까?

 

HTTP에서는 cookie라는 데이터를 서버에서 발급하여 클라이언트로 전송한다.

이때 서버는 쿠키를 클라이언트마다 생성하며 쿠키의 형태는 아래와 같다.

쿠키는 map 형태처럼 Set-Cookie: [이름] = [값]의 형태로 헤더에 담겨 클라이언트로 전송된다.

Set-Cookie 헤더에는 하나의 쿠키만 담을 수 있어 여러 개의 쿠키를 전송할 때에는

사진과 같이 Set-Cookie를 여러 번 작성한다.

 

클라이언트는 해당 서버를 재방문할 때 쿠키와 함께 데이터를 전송하는데, 형태는 아래와 같다.

사진과 같이 요청 헤더에서는 여러 개의 쿠키를 Cookie: [이름] = [값]; [이름] = [값]의 형태로 보낼 수 있다.

 

쿠키는 세션 관리, 개인화, 트래킹을 위해 사용되는데,

세션 관리는 로그인, 장바구니와 같은 기능을,

개인화는 사용자의 선호 및 테마를,

트래킹은 사용자의 행동을 기록하는 목적으로 사용된다.

 

쿠키는 최대 4000바이트까지 작성될 수 있고, 도메인 당 50개 ~ 최대 3,000개의 쿠키를 만들어 낼 수 있다.

크롬에서 개발자 도구를 통해 쿠키를 확인할 수 있다.

 

광고와 같은 사이트에서 사용자의 선호도에 맞는 광고를 띄우기 위해(트래킹) 쿠키를 띄우는데,

최근 프라이버스 문제가 대두되면서 아이폰에서는 추적 금지 요청을 할 수 있다.(Do-not-Track)

 

웹 캐시(Cache)와 프록시(Proxy)

유튜브와 넷플릭스의 경우 본사가 미국에 있다.

하지만 영상과 같은 큰 파일들을 요청할 때마다 바다를 건너 가져오기에는 자원과 시간이 낭비된다.

즉, 웹 서버를 한 곳에만 두고 해당 서버에서 모든 클라이언트 요청을 처리하기엔 비효율적이다.

따라서 캐시(프록시) 서버를 사용한다.

 

이때, 캐시는 컴퓨터 구조적 개념이고, 프록시는 역할(도구)의 개념인데 비슷한 개념이므로 구분할 필요는 없다.

데이터에 대한 최초의 요청은 원래의 서버에서 가져온 후 캐시(프록시) 서버에 둔다.

이후의 요청은 원래의 서버까지 갈 필요 없이 캐시(프록시) 서버에서 가져올 수 있어

데이터를 가져오는 비용을 줄일 수 있다.

 

CDN(Contents Delivery Network)

CDN는 컨텐츠를 전 세계 여러 지역에 미리 배포하여 지역 서버가 전송하는 네트워크를 말한다.

즉 대륙별, 국가별로 서버를 나누어 컨텐츠를 나눠가진 후 데이터 요청 시

사용자와 가장 가까운 곳에서 서비스를 해주는 방법이다.

대표적인 회사로는 Akamai, Cloudfare, Google, Netflix 등이 있다.

---

출처 및 참고

https://darkstart.tistory.com/178

https://twinparadox.tistory.com/634

https://www.daleseo.com/http-cookies/

https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies