[HTTP] HTTP Cookies, Session, Cache

 

HTTP 프로토콜의 정보파일 인 Cookies, Session, Cache 에 대해 알아보자. HTTP 프로토콜은 ConnectionLess and Stateless를 지향하기 때문에 데이터를 접속 할때 마다 요청하고 갱신해야 하는 불편함이 있다. 그러나 로그인 정보 저장이나 특정 데이터를 가지고 있어야 하는 Stateful 의 상황을 보완하기 위해 쿠키,세션을 사용한다.

 

---

Cookies

HTTP 의 일종으로 인터넷 클라이언트가 어떠한 웹사이트를 방문할 경우 그 사이트가 사요하고 있는 서버를 통해 클라이언트의 컴퓨터에 저장되는 작은 기록 정보 파일을 말한다. 쿠키, 웹쿠키, 브라우저 쿠키라고도 한다. 이 기록 파일에 담긴 정보는 클라이언트가 같은 웹 사이트를 방문할 때 마다 읽히고 수시로 업데이트 된다.

자동로그인, 팝업창 그만보기 등이 여기에 해당된다.

로그인 정보가 저장되 있는 경우가 많으므로 보안에 유의해야한다.

쿠키가 클라이언트 컴퓨터에 저장이 되면 이후 브라우저는 상태를 Stateless HTTP transaction 으로 유입시키면서 모든 요청을 서버로 되돌려 보낸다. 쿠키가 없다면 웹페이지의 각각의 검색 또는 웹 페이지의 구성요소가 대체적으로 웹사이트 상에서 사용자가 만드는 다른 모든 페이지와 무관한 별개의 이벤트로 취급된다.

쿠키설정

Set-Cookie HTTP header 를 사용하여 설정되며 이는 웹 서버의 HTTP 응답을 통해 송신된다.

이 header 정보는 웹 브라우저가 쿠키를 저장하고 후에 서버에 정보 요청시 송신할지를 지시한다.

브라우저는 쿠키 미지원이거나 비활성화 인 경우는 이 헤더를 무시한다.

예시

1) web Browser ▶ web server request 보냄

2) web Server response

첫번째 Set-Cookie 인 theme 은 세션쿠키로 간주 : Expires, Max Age attribute 이 없음. 세션쿠키는 브라우저가 닫히면 브라우저에 의해 지워짐

두번째 Set-Cookie 는 영구 쿠키, Expires 속성이 있음. 브라우저 종료시에도 유지될 수 있다.

3) 같은 웹사이트에서 spec.html 를 보기를 원함 request 를 보냄

2번째 과정에서 언급한 쿠키가 들어있는 것을 확인 할 수 있다.

특징

1. 이름, 값, Expires, 경로정보로 구성됨

2. 클라이언트는 자신의 컴퓨터에 총 300개의 쿠키 저장이 가능하다

3. 하나의 도메인 당 20개의 쿠키를 가질수 있다.

4. 하나의 쿠키는 4kb까지 저장 가능한다.

5. 속도가 세션보다 빠르다

 

---

Session

서버에서 클라이언트의 로그인 여부 들을 임시로 저장한 파일이다.  일정시간 동안 같은 브라우저로 부터 들어오는 request 를 하나의 state로 보고 그 상태를 일정하게 유지하는 것, 이는 클라이언트가 웹서버에 접속한 시간부터 웹 브라우저를 종료하여 연결을 끝낼 때 까지 유지된다. 쿠키와의 가장 큰 차이점은 이 정보가 서버에 저장된 다는 것이다. 로그인을 한 후  다른 페이지를 열었을 때 계속 로그인이 유지되는 것이 세션의 예라고 할 수 잇다. 보안 성 측면에서 보았을 때 세션을 유지하는 것이 쿠키보다 낫다고 생각할 수 가 있으나 세션을 너무 많이 사용하면 서버 메모리를 과도하게 사용하기 때문에 쿠키와 적절히 섞어서 사용한다.

동작원리

1. Client 가 웹페이지 request

2. 웹 서버는 Client 의 Request-Header의 Cookie를 체크해서 클라이언트가 해당 session ID 를 보냈는지 확인함

3. session ID 가 없는 경우 서버는 이를 생성해 response 해준다. 또 이를 쿠키를 사용해 서버에 저장한다.

4. Client 재 접속시 3번 과정에서 만든 쿠키이름을 이용해서 session ID 값을 서버에 전달 가능하다.

특징

1. 웹서버에 웹컨테이너 상태를 유지하기 위한 정보를 저장함

2. 웹 서버에 저장하는 쿠키를 세션쿠키라 한다.

3. 브라우저 종료 시 삭제, 혹은 세션기간이 만료되면 삭제되므로 보안성이 더 높다

4. 데이터 저장에 제한이 없다.

5. 각 클라이언트별로 sessionID 가 주어진다.

6. 보안이 쿠키보다 좋다.

 

---

Cache

데이터값을 미리 복사 해 놓는 임시저장소를 말한다. 원래 데이터의 접근하는 시간이 오래걸릴경우 값을 다시 계산하는 시간을 절약하고 싶을 때 이용한다.

기본적으로 쿠키와 비슷한 기능을 가지고 있으나 사용하는 목적이 다르다. 이 데이터들은 쿠키와 마찬가지로 클라이언트의 컴퓨터에 저장되며 웹 페이지 로딩속도를 개선하는데 사용된다.

주로 이미지, 비디오, 오디어, CSS JS 파일이 여기에 해당된다.

Advantages of Caching

Webpages can be cached pre-fetched on the clients, the proxies, and the servers. There are many advantages of web caching, including an improved performance of the web.

1. Caching reduces bandwidth consumption; therefore, it decreases network traffic and diminishes network congestion
2. Caching reduces access latency for two reasons:
   a) Frequently accessed documents are fetched from a nearby proxy cache instead of remote data servers; therefore, the transmission delay is minimized.
   b) Caching can reduce the network traffic, so those documents that are not cached can also be retrieved comparatively faster than without caching due to less congestion along the path and with less work load on the server.
3. Caching reduces the workload of the remote web server by spreading the data widely among the proxy caches over the WAN.
4. In a scenario where the remote server is not available due to a crash or network partitioning, the client can obtain a cached copy at the proxy. Hence, the robustness of the Web service is enhanced.

Disadvantages of Caching

1. The major disadvantage of caching is that a client might be looking at stale data, which can happen because of a lack of proper proxy updating.
2. The access latency may rise, in the case of a cache miss, due to some extra proxy processing. Therefore, while designing a cache system, the cache hit rate should be maximized and the cost of a cache miss should be minimized.
3. A single proxy cache is always a bottleneck. Some limit has to be set for the number of clients a proxy can serve.
4. A single proxy is a single point of failure.
5. By implementing a proxy cache, we can reduce the hits on the original remote server. This may disappoint many information providers because they won’t be able to maintain a true log of the hits to their pages. In this case, they might decide to not allow their documents to be cached.

Proxy Caching

Proxy servers are generally used to allow users access to the internet within any firewall. For security reasons, companies run a special type of HTTP server called "proxy" on their own firewall machines. A proxy server usually processes requests from within a firewall by forwarding them to the remote servers, intercepting the responses in between, and sending the replies back to clients. Because the same proxy servers are shared by all clients inside of the firewall, this naturally leads to the question of the effectiveness of using the proxy to cache documents. The clients within the same firewall usually belong to the same organization and likely share some common interests, so there’s a high probability that they would access the same set of documents and each client might have the tendency to browse back and forth within a short period of time. So on the proxy server, a previously requested and cached document would likely result in future hits by user. Web caching at a proxy server can not only save the network bandwidth, but can also lower the access latency for the clients.

Reverse Proxy Caching

An interesting twist to the proxy cache approach is the notion of reverse proxy caching, where caches are deployed not to near clients but on the origin of the content. This is an attractive solution for the servers that expect a high number of requests and want to ensure a high level of service quality. Reverse proxy caching is a useful mechanism when supporting web hosting farms, or virtual domains mapped to a single physical site, which is an increasingly common service for many Internet service providers (ISPs).

 

Transparent Caching

Transparent proxy caching removes one of the big drawbacks of the proxy server approach: the requirement that configures web browsers. Transparent caches work by obstructing HTTP requests and redirecting them to web cache clusters or cache servers. This caching style establishes a point at which different kinds of administrative controls are possible; for example, to judge how to load balance requests from the multiple caches. There are two ways to deploy transparent proxy caching: the first at the switch level and the second one at the router level.

Router-based proxy caching uses policy-based routing to direct requests to their appropriate cache(s). This means that requests from certain clients can be associated by a particular cache.

In switch-based transparent proxy caching, switch acts as a dedicated load balancer. This approach is attractive because it decreases the overhead and is usually incurred by policy-based routing. Since switches are generally less expensive than routers, it reduces cost to the deployment.

 

Caching Architectures

Hierarchical Caching Services

We can set up a caching hierarchy as an approach to coordinate caches in the same system. There are multiple levels of networks where a cache is kept. For the sake of clarity, we will assume that there are four levels of caches:

1. Bottom
2. Institutional
3. Regional
4. National

We have client/browser caches at the bottom level. When there is a request made of a web page and it is not fulfilled by the client cache, the request is forwarded to the institutional cache. If the page is not found at the institutional level, then we redirect the request to the next level in the hierarchy - the regional level. In the regional level cache server, the request checks whether or not a webpage is there. If the webpage is there with the cache, then it serves the request with the content; otherwise, it forwards the cache to the next level - the national level. When the request reaches the national level from the regional level, it cheeks its cache for the web document content. If the content is there, it is returned; otherwise, it communicates with the original server to get the latest content and then the request is served. The copy of the original request is kept with the each level of the cache in the hierarchy, so if the same request comes again then it gets served from the cache itself.

Distributed Caching Architecture

As the name suggests, distributed caching is a caching architecture in which we do not have different cache servers; instead, we have only one cache level known as the institutional cache. There is different institutional level distributed in the server. These cache levels know information about each other to serve requests. All the meta-data information of the content of each institutional cache level is kept within each institutional cache level to serve the requests. In distributed caching, the traffic mainly flows via low network levels, which are less congested. With distributed caching, we can achieve better load sharing and fault tolerant. However, there can be many problems, such as higher bandwidth usage and admin issues, due to a huge deployment of distributed caching.

There are mainly two approaches in which distributed caching can be achieved:

1. Internet Cache Protocol (ICP): In ICP, we support the discovery and retrieval of web pages from different neighboring caches, as well as their parent caches.
2. Cache Array Routing Protocol (CARP): In this technique, the space of the URL is divided between arrays of loosely coupled caches and lets each cache store only the documents whose URLs are hashed to it.

---

Reference

출처 1 : ko.wikipedia.org/wiki/HTTP_%EC%BF%A0%ED%82%A4

HTTP 쿠키 - 위키백과, 우리 모두의 백과사전

출처 2 : hahahoho5915.tistory.com/32

쿠키(Cookie), 세션(Session) 특징 및 차이

출처 3 : ko.wikipedia.org/wiki/%EC%BA%90%EC%8B%9C

캐시 - 위키백과, 우리 모두의 백과사전

출처 4 : www.3pillarglobal.com/insights/blog-posts/how-web-caching-improves-internet-performance/

How Web Caching Improves Internet Performance | 3Pillar Global