TIC는 일반적으로 통신사업자의 POP(Edge Router, BRAS, LTE S/P-GW등이 위치한 통신 사업자 건물)에 위치시키는 것이 일반적인 구성일 것입니다. 그래서 위 그림과 같이 TIC는 ER(Edge Router)에 연결을 시켜 놓았습니다.
① Cache Miss: 사용자가 요청한 Contents가 TIC에 없다!
- 사용자가 YouTube 페이지에 접속하였고, "나가수 박정현" 영상을 클릭합니다. 이제 단말에서 해당 영상 Contents에 대한 요청 메시지(HTTP GET)를 YouTube 서버로 보냅니다.
- HTTP GET을 수신한 ER은 패킷의 TCP Destination Port = 80 (HTTP) 인 것을 확인하고 본 패킷을 TIC로 IP Redirection 시킵니다. ER에는 Port=80에 대한 IP Redirection (Policy based Routing) rule이 미리 configuration되어 있어야 합니다.
- HTTP GET을 수신한 TIC는 HTTP GET 메시지를 분석하여 사용자가 요청한 "나가수 박정현" 영상 Contents가 storage에 있는지 확인합니다. 이 경우에는 없습니다(Cache Miss !!!).
- TIC는 사용자가 보낸 HTTP GET 패킷의 내용을 변경하지 않고 다시 ER로 내보냅니다.
- 본 패킷은 라우팅되어 YouTube 서버로 도착합니다. (사용자가 요청한 Contents가 TIC에 없으니 Origin Server인 YouTube 서버로 가는 것임)
② Cache Fill: YouTube 서버(Origin Server)로 부터 사용자가 요청한 Contents 가져오기
- YouTube 서버가 "나가수 박정현" 영상을 사용자쪽으로 전달합니다. (참고: 현재 YouTube는 Adobe Progressive Download 방식임)
- 본 패킷은 라우팅 되어 ER에 도달 할 것이고, ER은 TCP Source Port = 80 (HTTP) 인 것을 확인하고 본 패킷을 TIC로 IP Redirection 시킵니다. (역시 이 Redirection rule도 미리 ER에 설정되어 있어야 함)
- "나가수 박정현" 영상을 수신한 TIC는 본 Contents를 자신의 storage에 저장합니다(Cache Fill !!!). 사실 무조건 저장하는 것은 아니고 TIC 벤더 나름의 Policy에 기반하여 Cache Fill 여부를 판단합니다. (제한된 storage 공간하에서 사용자가 자주 요청하는 Contents 위주로 저장을 하는 Policy가 들어 있겠죠)
- TIC는 Cache Fill 동작을 하면서 YouTube 서버로 부터 수신한 패킷의 내용을 변경하지 않고 ER로 내보냅니다.
- 본 패킷은 라우팅되어 사용자에게 도달 할 것이고, 사용자는 이제 "나가수 박정현" 동영상을 시청하게 됩니다. 만약 "나가수 박정현" Contents를 미국에 있는 YouTube 서버로 부터 가져 오게 되는 경우라면, 사용자는 약간의 버퍼링(기다림)을 경험하게 될 것입니다.
③ Cache Hit: 사용자가 요청한 Contents가 TIC에 있다!
- 이제 다른 사용자가 동일한 "나가수 박정현" 영상을 요청하기 위해 HTTP GET 메시지를 YouTube 서버를 향해 보냅니다
- ER은 Port # = 80을 보고 TIC로 IP redirection을 수행합니다.
- TIC에 사용자가 요청한 "나가수 박정현" 영상이 있습니다(Cache Hit !!!).
- TIC에 Contents가 있으니 사용자에게 전달하면 땡인데 그렇게 동작하지는 않습니다 ^^. TIC는 자신에게 Contents가 있음을 확인한 후에, 사용자가 보낸 HTTP GET 메시지를 변경 없이 ER로 다시 내려 보내 YouTube 서버가 받을 수 있도록 합니다. 그 이유는 다음과 같습니다:
- Contents의 Freshness 확인: TIC에 caching된 contents 내용이 YouTube 서버에서 변경(update)이 될 수도 있으니, TIC에 caching된 내용이 YouTube 서버에 저장되어 있는 contents와 동일한 것인지(최근 건지) 확인이 필요합니다. (예. Contents의 맨 앞 8KB를 해싱하여 그 값을 저장 및 비교)
- 유료 Contents 보호: 캐싱된 유료 contents를 무턱대고 아무 유저에게 전달해 주면 CP(컨텐츠 제공자)가 아주 많이 화를 내겠죠(YouTube가 아직까지는 무료이지만 머지않아 Premium Contents에 대해 유료화를 하지 않을까요?). 따라서 사용자의 HTTP GET을 YouTube 서버로 보내고, 사용자의 요청 contents가 유료인 경우 YouTube는 사용자 계정(ID/PW) 확인 후에 Contents를 전달해 줄 것이고, 만약 유료 가입자가 아닌 경우 Contents를 전달해 주지 않을 것입니다. 그래서 만약 YouTube로 부터 contents가 오지 않으면 TIC는 사용자에게 캐싱된 contents를 전달해 주지 않습니다.
- Origin Server(YouTube 서버)에게 Transparency 제공: 만약 TIC에 caching된 contents를 YouTube 서버 모르게 TIC가 사용자들에게 제공한다면, YouTube 서버 소유주인 Google은 사용자들이 어떤 contents들을 얼마나 시청했는지 알길이 없습니다. 이는 마케팅적으로 필요한 정보입니다. 그래서 YouTube 서버에게 사용자의 behavior(어떤 contents를 클릭)를 transparent하게 알려 주기 위함입니다.
- YouTube 서버는 사용자로 부터 온 HTTP GET에 대한 응답으로 "나가수 박정현" 영상 패킷을 보냅니다. 그리고 이 패킷은 ER에 의해서 TIC로 IP redirection합니다.
- TIC는 "나가수 박정현" 영상 데이터의 앞부분(예를 들어, 전체 10MB 파일 중에 128KB 데이터만)를 수신하여 Contents의 Freshness를 확인 한 후에, Fresh하다고 판단이 되면 TIC가 YouTube 서버로 "STOP command" 메시지를 보냅니다 (TCP RST 메시지를 보내어 YouTube와의 TCP connection을 끊는 것으로 추정). 이에 의해서 YouTube 서버는 "나가수 박정현" 영상을 더 이상 보내지 않게 됩니다.
- TIC는 자신에 caching 되어 있는 "나가수 박정현" 영상을 사용자 쪽으로 보냅니다. 이때 영상 패킷의 Source IP는 TIC가 아니라 YouTube 서버의 주소입니다. 따라서 사용자는 YouTube 서버로 부터 영상을 시청한다고 생각을 하게 됩니다. 그래서 TIC의 첫글자가 Transparent입니다.
- 사용자는 "나가수 박정현"을 시청합니다. 이 경우, 통신 사업자내의 사용자와 가까운 위치에 있는 곳(TIC)으로 부터 영상을 가져 오니까 버퍼링(기다림)이 없게 됩니다.
TIC도 일종에 Web caching 하는 장비로 보입니다.
그럼 TIC는 reverse proxy에 해당하나요?
가입자는 TIC의 존재를 모르는 상황에서 caching이 되는 것이므로 reverse proxy입니다.
forward proxy의 경우, 단말에 proxy server의 IP 주소(혹은 URL)와 포트번호를 기록해야 합니다.
다음에 기회가 된면 Forward Proxy와 Reverse Proxy의 차이점에 대해 Blog를 통해 설명 드리도록 하겠습니다.
통신 사업자가 Cache 서버를 도입하는 이유는 ...
(1) Internet 회선 비용 절감: YouTube 트래픽이 더 이상 미국에서 오지 않으므로 미국 통신 사업자에 돈을 낼 필요가 없습니다.
(2) 가입자 이탈 방지: 가입자가 쾌적한 환경에서 YouTube를 볼 수 있어 타통신 사업자로 바꾸지 않겠죠.
Cache 서버 도입으로 인한 장점은 아래 링크를 클릭하셔서 보셔요~*
https://www.netmanias.com/bbs/view.php?id=blog&no=214
TIC와 CDN의 구분이 잘 안됩니다. 둘다 캐쉬서버 역할을 하는것 같은데 두 서비스의 차이점좀 알려주세요.
CDN이란 Contents를 사용자와 가까운 서버(캐싱 서버)에 위치시켜 빠르게 사용자게 contents를 전달해 주는 개념이며,
이를 위한 CDN 기술로 TIC를 포함하여 여러가지 방법이 적용될 수 있습니다.
1) TIC
2) Walled-Garden IPTV CDN: 우리가 시청하는 IPTV의 VoD 서비스도 VoD 서버가 각 지역별로 전진 배치되어 있어 이 VoD 서버로 부터 Hot contents(많이 보는 contents)를 스트리밍 받습니다. 다만 VoD 서비스의 경우 Cache Miss/Fill 과정 없이 통신 사업자가 Hot contents를 미리 VoD 서버에 push하는 방식입니다.
3) Wholesale CDN: Cisco, ALU 등이 통신사업자에 제공하는 CDN 솔루션으로, DNS/HTTP Redirection 기반으로 사용자의contents 요청을 캐싱 서버로 돌려 캐싱 서버로 부터 contents를 다운로드/스트리밍 받습니다.
4) Global CDN: Google, Akamai, EdgeCast, Level 3, Limelight 그리고 우리나라 업체인 CDNetworks등이 전 지구상에 캐싱 서버를 분산 배치하여 Apple, Cisco, Samsung등과 같은 다국적 기업의 contents를 고객에게 빠르게 전달해 줄 수 있도록 합니다.
TIC를 도입하는 것은 통신 사업자에서 하게된다면 Youtube와 같은 Contents Provider에서는 어떻게 의무적으로 TIC에서 Original Server로 Redirect 시킬수 있는 걸까요??
https://www.netmanias.com/bbs/view.php?id=blog&no=318
혹시 추가적으로 궁금하신 부분이 있으시면 글 남겨 주세요.
포워드 프록시와 리버스 프록시의 개념을 잘못 이해하고 계신것 같습니다.
일반적으로 캐시가 클라이언트와 가깝게 위치하는 구조를 포워드 프록시하고 합니다.
즉 유저에게 가깝게 위치해서 QoE향상과 WAN구간의 B/W saving이 목적이라면 포워드 캐시라고 하고
일반적으로 대부분의 캐시가 포워드 프록시 라고 하지요... 즉 ISP 구간에 들어가는 TIC도 포워드 구조라고
하는게 정확합니다. (단지 explict 셋팅을 한것을 포워드 프록시라고 하진 않습니다)
리버스 프록시는 반대되는 개념으로 유저단의 QoE와 B/W saving보단
서버앞단에 위치해서 여러 서버들의 대표하는 캐시로 동작하는 경우를 생각하시면 됩니다.
L4의 SLB를 연상하시되 다만 캐싱 기능을 겸한다고 생각하시면 됩니다.
즉 서버를 대표하는 캐시다... 이럴 경우 OCS 바로 앞단에 위치하거나
혹은 ISP에 위치하더라도 CDN구성으로 특정서버를 대표하는 경우 리버스 프록시라고 합니다.