[지식창고]/네트워크

[ 컴퓨터 네트워크 ] 2.2 Web and HTTP(2)

개발새발주발 2023. 3. 27. 22:47
728x90

이번 장에서는 내가 만든 쿠..키가 아니라 HTTP가 만드는 쿠키와 웹 캐쉬에 대해서 다루어 볼 것이다~ 

 

 

그 전에 잠시 HTTP와 Web에 대해 복습을 해보자 ~ 

 

웹(Web)은 워낙 방대한 개념이다. 

웹을 구성하는 요소는 웹 서버, 웹 클라이언트, HTTP 프로토콜, 웹 컨텐츠이다. 

웹 컨텐츠를 제외하고 네트워크에 밀접한 관련이 있는 웹 서버와 웹 클라이언트, HTTP프로토콜에 대해 자세히 알아보겠다. 

 

* 서버 : 네트워크상에서 다른 컴퓨터에 대하여 해당 네트워크 모두 또는 일부에 대한 접속과 네트워크의 자원(디스크 장치,파일,프린터 등)에 대한 접속을 제어하는 관리 소프트웨어를 운용하는 컴퓨터나 장치 또는 프로그램

* 클라이언트 : 서버에 접속하여 서버가 제공하는 서비스를 이용하는 프로그램 또는 그 프로그램이 동작하는 컴퓨터 또는 장치

* HTTP : TPC/IP 프로토콜 위에서 동작 

→ 웹 클라이언트는 웹 서버에게 필요한 파일을 요청하고 웹 서버는 요청한 파일을 웹 클라이언트에게 전송하고, 웹 클라이언트는 전송받은 데이터를 웹 브라우저를 이용하여 사용자에게 보여주는 것 

 

HTTP 프로토콜 개요


쿠키! 는 왜 나왔는가 하면 .. (1)장에서 보았듯이 HTTP는 stateless로 상태를 기록하지 않는다. 하지만 웹 서핑을 하다보면?

우리는 ~~ 어쩌곤데 님의 더 나은 웹 서비스 제공을 위해 쿠키를 설정해주세요 ~~ 라고 안내문이 뜨는 경우가 많다.

하나의 예를 들어 보자면 쇼핑 사이트와 같이 서비스 제공자가 사용자에 대한 기록이 필요한 경우가 있다.

이럴 때 사용하는 것이 바로 쿠키🍪다 ! 

 

1. User-server state: Cookies 🍪

웹 사이트에서 쿠키를 사용하는 것은 일반적이다 ! 

다음은 쿠키의 4가지 구성요소이다 

  1. HTTP 응답 메시지의 쿠키 헤더 라인 
    - 웹 서버가 사용자의 브라우저에게 전송하는 HTTP응답 메세지의 일부로 쿠키 정보가 포함된다.
  2. 다음 HTTP 요청 메세지의 쿠키 헤더 라인
    - 사용자의 브라우저는 이전에 받은 쿠키 정보를 다음 요청 메세지에 포함시키는 HTTP요청 메세지의 헤더 라인에 쿠키 정보를 추가한다.
  3. 사용자의 호스트에 저장된 쿠키 파일 및 브라우저가 관리하는 쿠키
    - 사용자의 브라우저는 쿠키 파일을 사용자의 호스트에 저장하며, 이 파일에는 사용자가 이전에 방문한 웹 사이트에서 설정한 쿠키 정보가 포함된다. 사용자의 브라우저는 쿠키 정보를 읽고 쓰며 관리한다.
  4. 웹 사이트의 백엔드 데이터베이스
    - 웹 사이트의 백엔드 데이터베이스에는 쿠키 정보를 포함하여 사용자에 대한 정보가 저장된다. 웹 서버는 이 정보를 사용하여 사용자에게 맞춤형 콘텐츠를 제작하거나 인증을 수행한다 ! 

 

Cookies : keeping 'state'

 

① 클라이언트가 서버로 request 메세지 보냄 

② 서버에서는 ID를 만들어 쿠키 세팅

→ 클라이언트로 response 하고 관련 정보 DataBase에 저장

③ 재접속 시, 쿠키번호를 request메세지에 담아서 함께 보냄 

④ 서버에서 해당쿠키에 맞는 정보를 DB로 보냄 ! 

 

 

* 쿠키가 state저장, HTTP는 쿠키를 전달만 ! 

 

 

 

what cookies can be used for (쿠키의 용도) 🍪 :  

① 인증 (authorization)

② 쇼핑카트

③ 추천

④ 사용자 세션 상태(웹 이메일 - 사용자가 웹 이메일을 사용할 때 메일을 보낼 때마다 세션 상테를 유지하기 위해 쿠키를 사용할 수 있다 ) 

 

how to keep 'state' (상태를 유지할 수 있는 방법) : 

① protocol endpoints : 여러 트랜잭션을 거쳐 송신자/수신자에서 상태를 유지한다.

② 쿠키 : HTTP 메세지가 상태 정보를 전달하고 쿠키를 사용하여 상태를 유지한다. 

 

** 트랜잭션 : 두 개 이상의 시스템 간에 데이터를 전송하고 처리하는 데 필요한 모든 단계와 단계 간의 상호 작용을 나타내는 용어 

일반적으로 트랜잭션은 데이터 전송, 처리 및 수신에 필요한 모든 과정을 포함한다. 


2. Web Caches(proxy server) 

 클라이언트 request를 원본 서버를 거치지 않고 만족시키는 것이 목표 ! → 즉각적으로 쓰기 위함 

** 캐시 : 이전에 검색된 데이터나 리소스를 저장하는 임시 저장소, 네트워크 성능을 향상시키는데 사용

 

① 사용자가 브라우저를 설정하여 캐시를 통해 웹으로 액세스한다. 

② 브라우저는 모든 HTTP 요청을 캐시에 전송한다. 

  • 캐시에 해당 객체가 존재하는 경우, 캐시는 해당 객체를 반환한다.
  • 그렇지 않은 경우, 캐시는 원본서버에서 해당 객체를 요청한 다음, 객체를 클라이언트에게 반환 

* 이러한 방식을 통해 캐시된 객체를 사용하여 원본 서버의 부하를 줄이고 클라이언트 요청에 대한 응답 시간을 단축하여 더 빠른 성능을 제공한다. 그러나 캐시된 객체가 업데이트 되지 않은 경우, 최신 버전의 객체를 얻기 위해 원본 서버로 다시 요청해야함 

 

캐시에 대해 더 알아보자 ! 

 

③ 캐시는 클라이언트, 서버 역할을 모두 수행 
 - 원래 요청한 클라이언트에 대해 서버 역할을 수행하여 요청을 수신하고 캐시된 객체를 반환
 - 원본 서버에 대해 클라이언트 역할을 수행하여 원본 서버로 요청을 보내고 응답을 받아 캐시에 저장

 

④ 일반적으로 캐시는 인터넷 서비스 제공자(ISP)나 대학, 회사, 주거용 ISP등에 의해 설치된다 ! 

 

Why web caching? (캐시는 왜 써 ?? )

  1. 클라이언트 요청에 대한 응답 시간을 줄이기 위해
  2. 기관의 액세스 링크에서 트래픽을 줄이기 위해
  3. 인터넷이 캐시로 가득 차 있기 때문에, "좋지 않은" 콘텐츠 제공 업체도 콘텐츠를 효과적으로 제공할 수 있도록
  4. (이와 마찬가지로 P2P 파일 공유도 가능)

** 트래픽 : 데이터가 네트워크를 통해 이동하는 양 ( 더 많은 데이터가 이동하면 더 많은 트래픽 발생) 

 

Caching example : 

  • 웹 브라우저에서 원본 서버로의 평균 요청률이 매우 높고, 평균 객체 크기도 상당히 크기 때문에 엑세스 링크가 매우 혼잡 
  • 액세스 링크 이용률 = 97% * → 100%로 갈수록 delay가 무한대로 ! 80%정도가 안전함

 

Caching example : fatter access link

유선을 교체하여 access link 속도를 10배 높였다. 

하지만 결코 싸지 않다는 점 .. 비용 문제가 발생한다. 

 

Caching example : install local cache 

로컬 캐시를 사용해보자 ! 

그런데 로컬 캐시안에 우리가 원하는 콘텐츠가 있을까.. ? 에 대한 문제점이 있다 

 

그럼 hit rate(히트율)을 가정해서 로딩 속도를 계산해볼까 ? ? 

  • 캐시 히트율 0.4로 가정 
    →  40%의 요청이 캐시에서 처리되고 나머지 60%는 서버에서 처리된다
  • 접근 링크 이용률은 60%
  • 15Mbps의 제이터 전송률 가지고 있다고 가정 
  • 이를 바탕으로 접근 링크 이용률은 9Mbps이며, 전체 대역폭인 15.4Mbps로 나누어 계산하면 0.58이나온다 ! → 대역폭 이용률이 80%이하, 즉 정상적으로 작동 됨을 의미 
  • 총 지연 시간 =  원본 서버에서 처리될 때의 지연시간*(0.6) + 캐시에서 처리될 때 지연시간*(0.4) = 1.2초 

→ 대역폭이 154Mbps인 경우보다 더 적은 시간이 걸리며 비용도 적게 든다 ! 

→ 따라서 캐시를 사용하여 웹 페이지 로딩 속도를 개선할 수 있으며 더 나은 사용자 경험과 비용 효율을 얻을 수 있음 !!

 

Conditional GET 

캐시가 최신 버전의 객체를 보유하고 있을 경우 객체를 다시 전송하지 않도록 하여 객체 전송 지연을 없애고 링크 이용률을 줄이는 HTTP 캐시 제어 메커니즘 

 

??? : 니가 가지고 있는 data 최신임 ? 언제 이후(날짜)에 바뀜? 

Conditional GET은 캐시가 HTTP 요청에서 캐시된 복사본의 날짜를 지정하도록 요청하는 것으로 시작함 → 이를 위해 HTTP 요청 헤더에 'if-modified-since'필드를 사용

 

*  'if-modified-since'필드 : 캐시된 복사본의 마지막 수정날짜를 포함 

 

서버는 캐시된 복사본이 최신 상태인 경우 객체를 다시 전송하지 않는다. 대신 HTTP응답 상태 코드 '304 Not Modified'를 반환 : 객체가 변경되지 않았음을 나타내며 서버는 이전에 캐시된 복사본을 계속 사용할 수 있도록 허용 

 

Conditional GET은 객체 전송 지연을 제거하고 링크 이용률을 줄일 수 있다 ! 

→ 이는 웹 성능 개선과 대역폭 절약을 위해 매우 유용 ~~ !