네트워크 6강 - 쿠키와 웹캐시

---

쿠키 : Cookie

 

• Http는 상태정보를 저장할 수 없어!
  • 카톡 메세지 하나 보낼 때마다 카톡 로그인을 다시 해야한다고 생각해보자.
  • 즉 자신의 로그인 상태가 저장이 안된다면(Stateless) 많이 곤란하다.
  • Http 프로토콜 자체는 Stateless 한 프로토콜이다!
  • 즉 State 정보 저장은 유저가 해야한다.
  • http를 stateful하게 설계한다면 물리적으로 항상 같은 서버와 통신해야 하기 때문에 서버 측에서 확장하기 어렵다.
• 쿠키 : Cookie
  • 쿠키는 Unique한 ID이다!
  • Unique한 ID로 상태정보를 저장할 수 있다.
  • 작동원리
    • 클라이언트가 서버에게 요청을 보낸다.
    • 서버는 클라이언트에게 Unique한 ID를 http헤더에 실어서 보내고
    • 누구에게 어떤 ID를 할당했는지 서버 데이터베이스에 저장한다.
    • 클라이언트는 그 사이트의 쿠키를 다른 쿠키들이 모여있는 쿠키파일에 저장하고
    • 다음 요청부터는 헤더에 쿠키를 같이 적어서 보낸다!
    • 서버는 쿠키가 담긴 http 메세지를 보고 Cookie Specific Action을 취할 수 있다.

---

웹 캐시 (Web Cache)

• 다른 말로 Proxy(대리인) Server라고도 한다.
• 웹 캐시는 왜 필요할까?
  • 클라이언트와 서버가 매우 멀리 있고
  • 몇몇 페이지만 자주 사용된다고 생각해보자.
  • 그러면 매번 저 멀리있는 서버까지 왔다갔다 해야할까....?
• 그럼 중간에 서버를 하나 더 두자!
  • 자주 사용하는 파일은 중간 서버에 두고
  • 덜 사용하는 파일은 중간 서버에 없으면 그때만 서버에 갔다오면 되지!
  • 중간에 있는 서버가 Original 서버를 대신한다. == Proxy!!!
• 작동과정
  • 클라이언트가 프록시 서버에게 요청한다.
  • 프록시 서버는 원 서버에게 Conditional Get메소드를 이용해서 물어본다.
    
    • 프록시 서버는 자신의 파일에 최근 수정일 <Date>를 보고
    • Condtional Get 메소드로 원 서버에게 <Date>이후로 수정되었는지 물어본다.
    • 원 서버는 수정되었지 않다면 304 not Modified를, 수정되었다면 200 OK [New Data]를 응답으로 보낸다.
    • 매번 크기가 큰 데이터를 받을 필요없이 크키가 작은 http 헤더 메세지만 주고 받으면 돼서 ISP 비용이 저렴하다.
    • 수정일 대신 버전을 사용할 수도 있다.
  • 클라이언트에게 응답 메세지를 보낸다.
  • Hit Rate만큼 트래픽이 감소한다.

 

 

 

 

본 게시물은 kocw 이화여자대학교 이미정 교수님의 컴퓨터 네트워크 강의를 듣고 정리한 글임을 밝힙니다.

내용상 틀린 부분이 있을 수도 있으며 이에 대한 책임을 지지 않습니다.

틀린 부분이나 오타 지적은 댓글로 남겨주세요.

www.kocw.net/home/cview.do?cid=e44bdd9b3a3f9bb5