Web Cache - 편집 역사

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 네트워크(\|[^\]]+)?\]\] +분류:컴퓨터 네트워킹\1)

2026-01-15T13:04:13Z

봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 네트워크(\|[^\]]+)?\]\] +분류:컴퓨터 네트워킹\1)

← 이전 판		2026년 1월 15일 (목) 13:04 판
79번째 줄:		79번째 줄:

	==각주==		==각주==
	[[분류:컴퓨터 ~~네트워크~~]]		[[분류:컴퓨터 네트워킹]]

2025년 4월 18일 (금) 16:56에 Pinkgo님의 편집

2025-04-18T16:56:21Z

← 이전 판		2025년 4월 18일 (금) 16:56 판
2번째 줄:		2번째 줄:

	==개요==		==개요==
	[[파일:WebCacheAsMultiRole.png\|대체글=Clients requesting objects through a Web cache\|섬네일\|'''Clients requesting objects through a Web cache''' ]]		[[파일:WebCacheAsMultiRole.png\|대체글=Clients requesting objects through a Web cache\|섬네일\|'''FIgure 1. Clients requesting objects through a Web cache''' ]]
	'''Web Cache(Proxy server라고도 한다.)는 origin web server를 거치지 않고로 client의 HTTP request를 처리하기 위해서 사용'''된다. 유저는 기본적으로 Web에 cache를 통해서 접근한다. 이때 Web cache는 자체적인 data storage space를 가지고 있어 '''최근에 요청된 object들의 복사본들을 해당 space에 저장'''한다. 사용자는 모든 request를 기본적으로 Web cache가 존재한다면 origin server가 아닌 web cache에 전송한다. 이때 Web cache는 다음과 같이 작동한다.		'''Web Cache(Proxy server라고도 한다.)는 origin web server를 거치지 않고로 client의 HTTP request를 처리하기 위해서 사용'''된다. 유저는 기본적으로 Web에 cache를 통해서 접근한다. 이때 Web cache는 자체적인 data storage space를 가지고 있어 '''최근에 요청된 object들의 복사본들을 해당 space에 저장'''한다. 사용자는 모든 request를 기본적으로 Web cache가 존재한다면 origin server가 아닌 web cache에 전송한다. 이때 Web cache는 다음과 같이 작동한다.
	# browser는 Web cache와 TCP 연결을 설정하고 해당 객체에 대한 HTTP 요청을 Web cache에 보낸다.		# browser는 Web cache와 TCP 연결을 설정하고 해당 객체에 대한 HTTP 요청을 Web cache에 보낸다.
11번째 줄:		11번째 줄:

	==Web cache의 장점==		==Web cache의 장점==
	[[파일:BottleneckToOriginServer.png\|대체글=Bottleneck between an institutional network and the Internet\|섬네일\|'''Bottleneck between an institutional network and the Internet''' ]]		[[파일:BottleneckToOriginServer.png\|대체글=Bottleneck between an institutional network and the Internet\|섬네일\|'''Figure 2. Bottleneck between an institutional network and the Internet''' ]]
	ISP가 추가적인 비용을 들여서 web cache를 설치하는 이유는 다음과 같다.		ISP가 추가적인 비용을 들여서 web cache를 설치하는 이유는 다음과 같다.
	# client request에 대한 응답 시간을 상당히 줄일 수 있다.		# client request에 대한 응답 시간을 상당히 줄일 수 있다.

2025년 4월 18일 (금) 16:55에 Pinkgo님의 편집

2025-04-18T16:55:59Z

← 이전 판		2025년 4월 18일 (금) 16:55 판
3번째 줄:		3번째 줄:
	==개요==		==개요==
	[[파일:WebCacheAsMultiRole.png\|대체글=Clients requesting objects through a Web cache\|섬네일\|'''Clients requesting objects through a Web cache''' ]]		[[파일:WebCacheAsMultiRole.png\|대체글=Clients requesting objects through a Web cache\|섬네일\|'''Clients requesting objects through a Web cache''' ]]
	Web Cache(Proxy server라고도 한다.)는 origin web server를 거치지 않고로 client의 HTTP request를 처리하기 위해서 ~~사용된다~~. 유저는 기본적으로 Web에 cache를 통해서 접근한다. 이때 Web cache는 자체적인 data storage space를 가지고 있어 최근에 요청된 object들의 복사본들을 해당 space에 ~~저장한다~~. 사용자는 모든 request를 기본적으로 Web cache가 존재한다면 origin server가 아닌 web cache에 전송한다. 이때 Web cache는 다음과 같이 작동한다.		'''Web Cache(Proxy server라고도 한다.)는 origin web server를 거치지 않고로 client의 HTTP request를 처리하기 위해서 사용'''된다. 유저는 기본적으로 Web에 cache를 통해서 접근한다. 이때 Web cache는 자체적인 data storage space를 가지고 있어 '''최근에 요청된 object들의 복사본들을 해당 space에 저장'''한다. 사용자는 모든 request를 기본적으로 Web cache가 존재한다면 origin server가 아닌 web cache에 전송한다. 이때 Web cache는 다음과 같이 작동한다.
	# browser는 Web cache와 TCP 연결을 설정하고 해당 객체에 대한 HTTP 요청을 Web cache에 보낸다.		# browser는 Web cache와 TCP 연결을 설정하고 해당 객체에 대한 HTTP 요청을 Web cache에 보낸다.
	# 유저가 request한 object가 해당 cache의 저장공간에 존재한다면 cache는 request받은 object를 client에 전송한다.		# 유저가 request한 object가 해당 cache의 저장공간에 존재한다면 cache는 request받은 object를 client에 전송한다.
15번째 줄:		15번째 줄:
	# client request에 대한 응답 시간을 상당히 줄일 수 있다.		# client request에 대한 응답 시간을 상당히 줄일 수 있다.
	# server와 전체 네트워크에 가해지는 traffic을 상당히 줄일 수 있다.		# server와 전체 네트워크에 가해지는 traffic을 상당히 줄일 수 있다.
	# 무엇보다, 비용이 ~~저렴하다~~.		# 무엇보다, '''비용이 저렴'''하다.

	===Web cache 예시===		===Web cache 예시===
55번째 줄:		55번째 줄:

	==Conditional Get==		==Conditional Get==
	Cache의 가장 큰 문제는 cache ~~coherence이다~~. 이는 web cache에 저장된 정보가 origin server에서 바뀌더라도 web cache에 저장된 정보가 바뀌지 않을 수 있기 때문에 발생한다. 이렇게 바뀌지 않고 origin server와는 다른 정보는 out-of-date되었다고 한다. 이러한 문제를 해결하는 방식 중 하나는 일정 시간 마다, web cache에 저장된 정보를 통째로 모두 origin server에서 update하는 것이다. 이는 과거에 실제로 수행되었던 해결책이지만 너무 비효율적이라는 문제가 있다. 현재는 web cache가 저장한 객체가 out-of-date되었는지 확인하고, 만약 그럴 경우에만 update하는 식으로 이를 해결한다. 이때, HTTP에서 cache가 저장한 object가 최신 상태인지 확인하는 메커니즘을 Conditional ~~GET이라고~~ 한다.		Cache의 가장 큰 문제는 '''cache coherence'''이다. 이는 web cache에 저장된 정보가 origin server에서 바뀌더라도 web cache에 저장된 정보가 바뀌지 않을 수 있기 때문에 발생한다. 이렇게 바뀌지 않고 origin server와는 다른 정보는 out-of-date되었다고 한다. 이러한 문제를 해결하는 방식 중 하나는 일정 시간 마다, web cache에 저장된 정보를 통째로 모두 origin server에서 update하는 것이다. 이는 과거에 실제로 수행되었던 해결책이지만 너무 비효율적이라는 문제가 있다. 현재는 web cache가 저장한 객체가 out-of-date되었는지 확인하고, 만약 그럴 경우에만 update하는 식으로 이를 해결한다. 이때, '''HTTP에서 cache가 저장한 object가 최신 상태인지 확인하는 메커니즘을 Conditional GET'''이라고 한다.

	HTTP request message가 Conditional GET message라고 불리기 위해서는 다음 두 가지 조건을 충족해야 한다:		HTTP request message가 Conditional GET message라고 불리기 위해서는 다음 두 가지 조건을 충족해야 한다:
61번째 줄:		61번째 줄:
	* request message에 'If-Modified-Since:' header line이 포함되어야 한다.		* request message에 'If-Modified-Since:' header line이 포함되어야 한다.

	cache는 HTTP request를 통해서 object를 수신하고 이를 저장할 때, 그 정확한 시점(date)를 ~~저장한다~~. cache는 다음과 같은 ~~request~~ 메시지를 보내서 확인하고자 하는 object가 out-of-date되었는지 ~~확인한다~~.		cache는 HTTP request를 통해서 '''object를 수신하고 이를 저장할 때, 그 정확한 시점(date)를 저장'''한다. cache는 다음과 같은 r'''equest 메시지를 보내서 확인하고자 하는 object가 out-of-date되었는지 확인'''한다.
	<syntaxhighlight lang="yami">		<syntaxhighlight lang="yami">
	GET /fruit/kiwi.gif HTTP/1.1		GET /fruit/kiwi.gif HTTP/1.1

Pinkgo: /* Conditional Get */

2025-03-21T16:21:41Z

Conditional Get

← 이전 판		2025년 3월 21일 (금) 16:21 판
62번째 줄:		62번째 줄:

	cache는 HTTP request를 통해서 object를 수신하고 이를 저장할 때, 그 정확한 시점(date)를 저장한다. cache는 다음과 같은 request 메시지를 보내서 확인하고자 하는 object가 out-of-date되었는지 확인한다.		cache는 HTTP request를 통해서 object를 수신하고 이를 저장할 때, 그 정확한 시점(date)를 저장한다. cache는 다음과 같은 request 메시지를 보내서 확인하고자 하는 object가 out-of-date되었는지 확인한다.
	<syntaxhighlight lang="~~cpp~~">		<syntaxhighlight lang="yami">
	GET /fruit/kiwi.gif HTTP/1.1		GET /fruit/kiwi.gif HTTP/1.1
	Host: www.exotiquecuisine.com		Host: www.exotiquecuisine.com
	If-Modified-Since: Wed, 9 Sep 2015 09:23:24		If-Modified-Since: Wed, 9 Sep 2015 09:23:24
	</syntaxhighlight>		</syntaxhighlight>
	위는 /fruit 파일에 저장된 kiwi.gif 파일이 저장된 origin server<ref>해당 server의 주소는 Host: www.exotiquecuisine.com이다.</ref>에 Wed, 9 Sep 2015 09:23:24 이후로 수정이 이루어졌는지를 물어보는 request message이다.		위는 /fruit 파일에 저장된 kiwi.gif 파일이 저장된 origin server<ref>해당 server의 주소는 Host: www.exotiquecuisine.com이다.</ref>에 Wed, 9 Sep 2015 09:23:24 이후로 수정이 이루어졌는지를 물어보는 request message이다. origin server는 해당 object가 해당 date 이후로 변경되지 않았다면 다음과 같은 response message를 보낸다.
			<syntaxhighlight lang="yami">
			HTTP/1.1 304 Not Modified
			</syntaxhighlight>
			위는 단순히 해당 object가 cache에 저장된 이후로 수정되지 않았음을 알려준다. 또한 origin server는 해당 object가 해당 date 이후로 변경되었다면 다음과 같은 response message를 보낸다.
			<syntaxhighlight lang="yami">
			HTTP/1.1 200
			<new data>
			</syntaxhighlight>
			즉, 해당 객체가 out-of-date되었다면 server는 00 응답과 함께 새로운 Last-modified 정보가 담긴 객체를 전해준다.

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

2025년 3월 21일 (금) 16:12에 Pinkgo님의 편집

2025-03-21T16:12:25Z

@@ 53번째 줄: / 53번째 줄: @@
              = 0.6 * 2.01 + 0.4(msecs) = 약 1.2secs</pre>
 이를 통해서 ISP가 access link의 bandwidth를 150Mbps로 확장했을 때보다 더욱 빠를 뿐만 아니라, 더욱 싸다는 결론을 내릴 수 있다.
 ==각주==
 [[분류:컴퓨터 네트워크]]

Pinkgo: /* Web cache 예시 */

2025-03-21T15:54:12Z

Web cache 예시

← 이전 판		2025년 3월 21일 (금) 15:54 판
40번째 줄:		40번째 줄:
	<pre>		<pre>
	total delay = Internet delay + access delay + LAN delay		total delay = Internet delay + access delay + LAN delay
	= 2sec + msecs + usecs <~~math~~>~~\times~~</~~math~~></pre>		= 2sec + msecs + usecs</pre>
			즉, access link의 bandwidth 확장은 이를 해결할 수 있는 해결책 중 하나이다. 몇 분간의 딜레이가 약 2초 정도로 줄어들었기 때문이다. 하지만 이러한 해결책은 자금이 천문학적으로 많이 든다는 문제가 있다.

			2. Local Cache의 설치
			보수적으로, cache hit rate를 잡으면 약 40% 정도이다.
			<ref>cache hit rate란 client가 web cache에 object를 요청했을 때 해당 object가 web cache에 저장되어 있을 확률이다.</ref>
			따라서 약 40%의 request는 cache에서 처리되며, 약 60%의 request는 origin server에서 처리된다. 이 경우에, access link의 bandwidth는 평소의 약 60%만 사용된다.
			<ref>traffic intensity = 0.6(15requests/sec)(1Mbits/requests)/(15Mbps) = 60%</ref>
			이러한 경우, total delay는 다음과 같이 결정된다.<ref>약간의 delay는 0.01초로 간주한다.</ref>
			<pre>
			total delay = 0.6 * (delay from origin server) + 0.4 * (delay when satisfied at cache)
			= 0.6 * 2.01 + 0.4(msecs) = 약 1.2secs</pre>
			이를 통해서 ISP가 access link의 bandwidth를 150Mbps로 확장했을 때보다 더욱 빠를 뿐만 아니라, 더욱 싸다는 결론을 내릴 수 있다.

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

Pinkgo: /* Web cache 예시 */

2025-03-21T15:41:20Z

Web cache 예시

← 이전 판		2025년 3월 21일 (금) 15:41 판
40번째 줄:		40번째 줄:
	<pre>		<pre>
	total delay = Internet delay + access delay + LAN delay		total delay = Internet delay + access delay + LAN delay
	= 2sec + msecs<~~ref~~>~~minutes~~</~~ref~~> ~~+ usecs~~</pre>		= 2sec + msecs + usecs <math>\times</math></pre>

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

Pinkgo: /* Web cache의 장점 */

2025-03-21T15:39:52Z

Web cache의 장점

← 이전 판		2025년 3월 21일 (금) 15:39 판
20번째 줄:		20번째 줄:
	다음과 같은 상황을 가정해보자.		다음과 같은 상황을 가정해보자.
	* request하는 평균 object 크기: 1Mbits		* request하는 평균 object 크기: 1Mbits
	* browser에서 origin server로의 평균 request rate: 15/sec		* LAN의 bandwidth: 100Mbps
			* browser에서 origin server로의 평균 request rate: 15requests/sec
	* institutional router에서 origin server까지의 RTT: 2sec		* institutional router에서 origin server까지의 RTT: 2sec
	* access link rate: 15Mbps		* access link rate: 15Mbps
	이러한 경우, LAN<ref>근거리 네트워크를 의미한다.</ref>의 bandwidth는 단 15%만 사용된다. 하지만, access link의 bandwidth는 99%가 사용된다. 이러한 경우, total delay는 다음과 같이 결정된다.		이러한 경우, LAN<ref>근거리 네트워크를 의미한다.</ref>의 bandwidth는 단 15%만 사용된다.
			<ref>traffic intensity = (15requests/sec)*(1Mbits/requests)/(100Mbps) = 15%</ref>
			하지만, access link의 bandwidth는 99%가 사용된다.
			<ref>traffic intensity = (15requests/sec)*(1Mbits/requests)/(15Mbps) = 100%</ref>
			이러한 경우, total delay는 다음과 같이 결정된다.
	<pre>		<pre>
	total delay = Internet delay + access delay + LAN delay		total delay = Internet delay + access delay + LAN delay
	= 2sec + minutes + usecs</pre>		= 2sec + minutes + usecs</pre>
			이 경우, RTT에 의해서 생기는 Internet delay나 LAN에서 발생하는 delay는 사실상 무시되고 total delay는 거의 access delay에 의해서 결정된다.
			access delay는 institutional router와 origin server를 연결하는 access link가 bottleneck link로 작동하기 때문에 발생한다.
			이러한 문제를 해결하는 방법은 두가지가 있다.

			1. ISP가 access link의 bandwidth를 150Mbps로 확장한다.
			이 경우, access link의 bandwidth는 10%가 사용된다. 따라서 total delay는 다음과 같이 결정된다.
			<pre>
			total delay = Internet delay + access delay + LAN delay
			= 2sec + msecs<ref>minutes</ref> + usecs</pre>

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

Pinkgo: /* Web cache 예시 */

2025-03-21T15:30:47Z

Web cache 예시

← 이전 판		2025년 3월 21일 (금) 15:30 판
24번째 줄:		24번째 줄:
	* access link rate: 15Mbps		* access link rate: 15Mbps
	이러한 경우, LAN<ref>근거리 네트워크를 의미한다.</ref>의 bandwidth는 단 15%만 사용된다. 하지만, access link의 bandwidth는 99%가 사용된다. 이러한 경우, total delay는 다음과 같이 결정된다.		이러한 경우, LAN<ref>근거리 네트워크를 의미한다.</ref>의 bandwidth는 단 15%만 사용된다. 하지만, access link의 bandwidth는 99%가 사용된다. 이러한 경우, total delay는 다음과 같이 결정된다.
	<pre>total delay = Internet delay + access delay + LAN delay		<pre>
	= 2sec + minutes + usecs</pre>		total delay = Internet delay + access delay + LAN delay
			= 2sec + minutes + usecs</pre>

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

Pinkgo: /* Web cache 예시 */

2025-03-21T15:30:38Z

Web cache 예시

← 이전 판		2025년 3월 21일 (금) 15:30 판
25번째 줄:		25번째 줄:
	이러한 경우, LAN<ref>근거리 네트워크를 의미한다.</ref>의 bandwidth는 단 15%만 사용된다. 하지만, access link의 bandwidth는 99%가 사용된다. 이러한 경우, total delay는 다음과 같이 결정된다.		이러한 경우, LAN<ref>근거리 네트워크를 의미한다.</ref>의 bandwidth는 단 15%만 사용된다. 하지만, access link의 bandwidth는 99%가 사용된다. 이러한 경우, total delay는 다음과 같이 결정된다.
	<pre>total delay = Internet delay + access delay + LAN delay		<pre>total delay = Internet delay + access delay + LAN delay

	= 2sec + minutes + usecs</pre>		= 2sec + minutes + usecs</pre>

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]