| 리포트 | 기술문서 | 테크-블로그 | 원샷 갤러리 | 스폰서 컨텐츠 | 네트워크/통신 뉴스 | 기술자료실 | 자유게시판      한국 ICT 기업 총람 |

제품 검색

|

통신 방송 통계

 
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 

5G 특화망

(Private 5G) 

포탈 홈 넷매니아즈 Private 5G 분석글 5G 특화망 뉴스  5G 특화망 정책 일본의 Local 5G 전개현황 KT SK Telecom Verizon AT&T Vodafone DT  Telefonica
China Mobile Optage NEC Fujitsu Microsoft AWS HFR Ericsson Nokia Huawei Samsung Mavenir Affirmed Metaswitch Athonet Altiostar Airspan Kyocera Apresia
 
스폰서채널 |

 HFR의 5G 특화망 솔루션 (my5G |  

  스폰서채널 서비스란?
banner
banner
Transparent Internet Caching (TIC) 상세 동작 원리
Transparent Internet Caching (TIC) Detailed Workflow
June 06, 2012 | By 유창모 (cmyoo@netmanias.com)
banner
코멘트 (15)
11

넷매니아즈 블로그를 통해 두차례에 걸쳐 TIC(Transparent Internet Caching)에 대해 소개해 드린 적이 있습니다. (관련 글은 하단 Related Netmanias Contents 참조)

오늘은 TIC 동작 원리를 좀 더 상세히 알아 보도록 하겠습니다.

 

Redirector

TIC 솔루션을 위해서는 TIC와 연결된 네트워크 장비가 Redirector 기능을 지원해야 합니다. Redirector는 사용자에서 Origin 서버로(예. YouTube), 그리고 Origin 서버에서 사용자로의 패킷을 의도적으로 TIC로 전달해주는 역할을 하며 정교한 Redirect Rule을 주기 위해서는 DPI(Deep Packet Inspection) 장비를 사용할 수도 있으며(HTTP 302 Redirection) 간편하게는 라우터(아래 그림상 ER: Edge Router)의 PBR(Policy-Based Routing) 기능을 사용하면 됩니다. 

예를 들면 YouTube 트래픽을 TIC로 보내기 위해서

  • DPI의 경우 YouTube 서버 URL을 적어(설정) 주기만 하면 되고 (아, 쉽다! 그런데 DPI는 너무 비싸!)
  • PBR의 경우 사용자에서 YouTube 서버 방향의 트래픽에 대해서는 Destination IP 주소가 YouTube 서버이고(수많은 서버 주소를 일일히 다 적어 줘야 함), TCP Destination Port #가 80이면 TIC로 PBR(redirect), 그리고 반대 방향 트래픽(YouTube 서버에서 사용자)에 대해서는 Source IP 주소가 YouTube 서버이고 TCP Source Port #가 80이면 TIC로 PBR을 할 수 있도록 설정해야 합니다. (PBR에 대해서는 여기, 여기 클릭)

 

TIC (Transparent Internet Caching)

TIC는 Transparent Proxy Server로 동작하며 단말에서 OTT(예. YouTube) Origin 서버로 전달되는 Content Request 메시지와 Origin 서버에서 단말로 전달되는 Content(동영상 파일)을 인터셉트하여 캐싱합니다. TIC는 단말과 Origin 서버간에 주고 받는 패킷의 IP 주소, Port 번호, HTTP 헤더를 전혀 수정하거나 변경하지 않기 때문에 단말과 Origin 서버는 중간에 캐싱 서버가 있음을 알지 못합니다 (그래서 이름 앞에 Transparent가 붙었나보네요).

 

 

TIC Workflow

 

1. User Request Content but Not Cached (Cache Miss)

 

 

1. 단말은 YouTube 서버로 HTTP 메시지를 보내기 위해 일단 TCP 연결을 합니다.

2. 단말이 YouTube 서버로 HTTP GET 메시지를 보내고(Content 요청을 위해)

3. 라우터(ER) 혹은 DPI에 의해서 이 메시지는 TIC로 redirect 됩니다.

4. TIC는 요청된 Content(비디오 파일)가 캐싱이 되어 있는지를 체크합니다(Content Availability Check).

5. 최초 요청의 경우 Content가 캐싱되어 있지 않으므로 Content Request 패킷을 그대로 YouTube 서버로 전달한다. 이 과정에서 패킷의 IP 주소나 HTTP 헤더 정보에 아무 변경없이 그대로 전달되며 일종의 Snooping이라고 볼 수 있습니다.

 

2. Content Delivered to User and Cached (Cache Fill)

 

 

6. YouTube 서버는 요청된 Content을 HTTP 메시지를 통해 전송해주고 

7. 역시 이 메시지는 ER/PBR에 의해서 TIC로 redirect 됩니다.

8 & 9. TIC는 단말로 Content을 전달해주면서 TIC 로컬에 저장을 합니다. 실제로는 한번의 요청으로 해당 Content을 캐싱하는 것은 아니고 빈번히 요청되는 파일만 캐싱합니다(Popularity를 반영한 Statistical Caching). 단말과 YouTube 서버는 중간에 TIC가 있음을 알지 못하며 TIC는 패킷의 IP 주소, HTTP 헤더, Content Payload(비디오 파일)에 전혀 수정을 하거나 변환을 하지 않습니다. 단지 몰래 훔쳐 보기(snooping)만 합니다.

 

3. User Request Content and Content Delivered to User (Cache Hit)

 

 

1. 이후 다른 사용자가 YouTube 서버와 TCP 연결을 하고,

2. 동일한 Content를 요청하면 

3. TIC는 요청된 Content가 이미 캐싱되어 있는지 체크하여(Content Availability Check), 

4. 요청된 Content가 캐싱되어 있으면(Cache Hit) 캐싱되어 있는 파일이 YouTube 서버의 파일과 동일한지 체크합니다(Content Validity Check). 따라서 TIC는 단말이 요청한 Content Request 메시지(HTTP GET /…)를 YouTube 서버로 그대로 전달하고 

5. YouTube 서버가 Content을 다운로드해주기 시작하면 

6. 이 Content을 검사하여 자신이 캐싱하고 있는 파일과 동일한지 확인 후에

7. YouTube 서버로 Content 전달 중지 메시지를 보내고(TCP Session Termination 즉, TCP session을 끊어 버림)

8. 캐싱된 Content를 단말로 전달 해 줍니다.

 

 

캐싱되어 있는데 왜 Content Request를 YouTube 서버로 보내야 되나?

 

TIC는 단말로부터 수신되는 모든 Request 메시지를 자신이 서비스를 할 수 있어도(요청 Content가 캐싱되어 있어도) 항상 Origin 서버로 보내고 일부 Content를 다운로드 받습니다. 그렇게 하는 이유는 크게 3가지입니다.

  1. Contents Validity(Freshness) 확인: TIC는 자신의 로컬에 저장된 Content가 "최신"인지 알 수 없습니다. 따라서 Origin 서버의 Content 일부(예. 8KB)를 수신하여 이를 통해 로컬에 캐싱되어 있는 파일이 최신 건지 확인을 합니다.
  2. 유료 Content 보호: 사용자의 Content 요청을 받은 Origin 서버는 유료 Content에 대해서 User Credential(ID/PW)을 요청하고, 확인된 유료 사용자에 대해서만 Content를 전달해 줍니다. 그렇지 않은 경우 Origin 서버는 Content를 전달해 주지 않겠죠. 따라서 TIC는 Origin 서버로 부터 컨텐츠가 수신되었음을 통해 사용자가 Content 수신 권한이 있음을 알게 됩니다.
  3. CP에 User Behavior 제공: Content Provider 입장에서는 사용자가 어떤 컨텐츠를 많이 봤는지 알아야 이를 통해 마케팅/광고등의 행위를 할 수 있을 것입니다. 그래서 TIC는 항상 사용자의 요청을 일단 Origin 서버로 보내어 CP가 각종 통계 데이터(예. Unique Subscriber, Content Popularity, 이용자 별 취향)를 확보 할 수 있도록 합니다.

 

TIC는 Content 식별을 어떻게 하지?

 

보통 TIC는 Content 식별자로 URL과 더불어 Content 자체에 대한 Hash값을 사용합니다. Verizon에 따르면 Content 맨 앞에 8KB를 이용하여 Hash를 만든다고 하는데요. 그래서 TIC에 캐싱된 Content에 대한 Hash 값과 Origin 서버에서 다운로드 받아온 Content의 최초 8KB를 Hashing하여 나온 결과값을 비교하여 Content에 대한 유효성을 확인한다고 합니다. 

 

여기서 8KB 정도의 크기라면 YouTube에서 사용하고 있는 FLV 파일 기준으로 960 Byte의 Video Meta Data(duration, video/ audio data rate, framerate, file size 등이 포함)와 나머지 약 7KB의 H.264 영상 데이터가 포함될 수 있습니다. 즉, Content 식별자로 8KB 정도면 충분하다는 생각이 듭니다.

 

조성문 2012-10-17 21:07:11
좋은 글 감사합니다. 두 가지 정도 궁금한 사항이 있어 글 남깁니다.
TIC Cache HIT 동작 시 Origin서버 측에 Request를 전송하여 8KB 정도의 전송을 진행하고 끊는 액션은 TIC 표준규격(?)인가요?
또한 위의 액션을 통해서 Cache Content Validation Check를 수행하는데 사용한다고 하면, 기존 Cache 서버에서 Origin 서버의 컨텐츠에 대한 HTTP에서 제공하는 If-Modify-Since, Last-modified 등의 Header field를 사용한 validation check는 수행하지 않는 것인지요?
넷매니아즈 2012-10-18 12:17:34
답변 드리면요.

1. Video Content 맨 앞에 8KB를 본다는 건 벤더 구현일 뿐입니다. 8KB 정도면 Video Metadata(영상 포맷, 재생시간, 파일크기, 해상도 등이 포함)와 Video 영상 데이터의 일부가 들어갈 수 있어 이렇게 한 듯 하네요.

2. TIC가 HTTP If-Modified-Since Get을 하는지는 저도 잘 모르겠네요.
다만 YouTube의 경우를 생각한다면 동일 Video Content를 연달아 요청해도 Content를 다운로드 해 주는 YouTube 서버가 바뀔 가능성이 높아(예. 처음 요청시 다운로드 서버의 hostname = v1.lscache1.c.youtube.com, 두번째 요청시 hostname = v2.lscache5.c.youtube.com) If-Modified-Since를 보내는 경우가 많지 않을 것 같은데요.
호용환 2012-10-18 13:43:25
좋은 글 감사합니다.
질문이 있는데요. 요즘 동영상 컨텐츠들은 스트리밍 할때 일종의 url암호화 같은 작업들이 이루어 지는걸 볼 수 있는데요, 동일한 컨텐츠에 대해 클라이언트들 마다 다른 파일명을 보내준다던가 하는 방식이조... 이러한 컨텐츠들을 transparent하게 cache 할 수 있는 방법이 있나요?
조성문 2012-10-18 13:44:17
답변 감사합니다.^^
결국은 TIC의 경우에는 validation에 대한 확인 방법은 기존 forward, reverse proxy cache에 사용하는 방식은 효율성이 떨어지거나 transparent proxy 정의(request/response에 대한 수정 불가)에 위배될 수 있겠네요.
넷매니아즈 2012-10-22 11:08:09
호용환님, 답변 드리면요.
제가 알고 있기로 TIC는 컨텐츠 구분을 URL로 하지 않고, 실제 컨텐츠 내용의 일부(예. 8KB)를 사용합니다.
즉, www.a.com/vod/movie1.mpg와 www.b.com/vod/movie1.mpg가 있고 movie1.mpg는 동일 컨텐츠라고 할 때,
URL로 구분을 하게 되면 이 2개의 컨텐츠는 다른 것으로 구분하지만 컨텐츠 내용의 일부로 구분을 하면 동일 컨텐츠로 구분할 수 있습니다.
따라서 말씀하신 URL 암호화 같은 작업으로 동일 컨텐츠에 대해 다른 이름을 주더라도 컨텐츠 내용이 변경되지 않는 한 동일 컨텐츠로 구분이 가능할 것으로 보입니다.
호용환 2012-10-23 11:34:58
답변감사합니다. 답변에 이해가지 않는 부분이 있어 질문드립니다.

본문에 TIC Workflow를 보면 miss 시 (1. User Request Contents But Not Cached)에 컨텐츠의 캐싱유무를 확인하고 miss이면 유투브로 리퀘스트를 보내고 Proxy Caching 하는 것으로 해석되는데요, Workflow가 세밀하게 보면 약간 변경 되는 것인지요?
컨텐츠 구분에 URL을 이용하지 않는다면 최초 hit/miss를 판단할 때 무조건 원본쪽에서 데이터를 가지고 와서 확인을 해야 하는 것인가요?
넷매니아즈 2012-10-25 20:58:03
안녕하세요? 호용환님,
정말 좋으신 질문이십니다. TIC 문서 상에는 그렇게 써져 있는데 저도 왜 그런지 아직 잘 모르겠더라구요.
며칠만 기다려 주세요. 어쩌면 그 의미를 알 수도 있을 것 같거든요 ^^*
호용환 2012-10-26 14:23:41
답변 감사합니다. 더군다나 의미를 알아봐 주신다니 더욱 감사해 몸둘바를 모르겠습니다.^^;;
저도 좀 알아보고 혹시 알게되면 빠르게 이곳에 댓글을 남기도록 하겠습니다.
넷매니아즈 2012-11-01 10:38:15
안녕하세요? 호용환님,
TIC 벤더로는 PeerApp, BTI, OverSi, Juniper(Ankeena), Blue Coat 등이 있으며 각 벤더마다 동작에 차이가 있습니다.
따라서 "TIC는 URL을 보지 않고 Content Hashing 값으로 Content를 식별한다"라는 말은 안맞을 수도 있을 것 같은데요. 왜냐면 위 벤더 중에는 URL로 Content를 식별하는 경우도 있다고 하거든요.

아무튼...
넷매니아즈에서 소개드린 TIC 장비 기준으로 말씀을 드리면,
장비 관계자분과 미팅을 통해 파악한 바로는 "사용자가 보낸 URL은 보지 않는다!"입니다.
따라서 블로그 글 첫 그림에 "4. Content Availability Check"란 표현은 잘못 되었다고 보입니다. 없어져야 하겠네요...

정리하자면,
(1) 사용자의 요청은 무조건 Origin으로 bypass (TIC는 어떠한 판단도 안함)
(2) Origin이 전달해 준 Content에 대해 hash 계산을 통해 Content 식별
(3) hash 값이 있으면(Content가 있으면) Origin과 연결을 끊고 TIC가 사용자에게 Content 전달
(4) hash 값이 없으면(Content가 없으면) Origin이 주는 Content를 사용자에게 전달하면서 자신도 저장(캐싱)

감사합니다.
호용환 2012-11-02 11:24:38
답변 감사합니다. 저도 이곳저곳 물어봤는데 다들 말들이 좀 달라 헤메고 있었습니다.
덕분에 헷갈리던 부분을 정리 할 수 있게되어 좋았습니다.
권기석 2013-11-12 19:44:58
그림에서 보면 처음 사용자가 TCP Connection을 오리지날 서버와 맺을 때의 TCP 패킷들은 캐쉬서버를 그냥 지나치는 것 처럼 보입니다. 그리고 HTTP GET 메시지만 DPI/PBR을 통해서 캐쉬서버에게 Redirection 하는 것 처럼 보입니다. 만약, 캐쉬 히트가 나서 캐쉬 서버가 오리지날 서버 대신해서 사용자에게 서비스를 제공 해 줄 때, 초기 TCP connection 맺을 때 서로 교환 했던 정보 (window scale factor, MSS 등) 없이 바로 단말에게 서비스 해주는 것이 가능한가요 ? 즉, 단말의 HTTP GET 메시지에 있는 Sequence Number, IP address, port 등의 정보 만으로도 오리지날 서버 대신해서 단말에게 서비스가 가능한지가 궁금합니다.
버너 2013-11-13 04:40:36
1번 플로우가 TIC를 거치지 않는 것처럼 그려졌지만 실제는 TIC를 거쳐서 지나갑니다
넷매니아즈에서 편의상 (캐싱에 포커스를 맞추느라고) TIC를 경유하지 않는 것처럼 그리셨을 것 같네요
그럼 모든 TCP정보를 알 수 있으니까 transparent tcp proxy가 가능하지요
권기석님이 문의하신 tcp의 윈도우사이즈, mss등등을 모르고도 tcp연결을 대행하는 것은 실험실에서는 가능할 지몰라도
실제 서비스용으로는 못 쓴다고 생각됩니다.
단말별/app별로 윈도우사이즈가 틀리고, MSS는 접속망별로 틀리기 때문이죠.
새벽에 문득 눈이 떠져서 잠시 들어와 봅니다.
권기석 2014-01-29 17:23:37
버너님 답변 감사합니다.
정원용 2015-08-10 15:56:24

아주 흥미로운 글 잘 봤습니다.

글을 계속 읽다보니 의문점이 생겼습니다. HTTP GET메시지와 해당 Response 메세지를 통해 Content Availability Check를 한다고하였는데요. 이건 HTTP 즉, 암호화를 안했을 경우 확인이 가능한거고, 예를 들어 HTTPS 즉, TLS를 사용해여 통신을 하게 된다면, 과연 정상적으로 TIC가 처리가 될까 의문이 생겼습니다. 최근 Youtube는 모두 HTTPS(TLS)를 사용하는게 사실이고요. 


그럼 이런 상황에서는 어떠한 방법으로 처리되는지도 궁금합니다. 


추가적으로 TIC에서 YouTube서버로 Tcp terminate를 한다고 했는데요. terminate하는 방법이 궁금합니다.


이상흔 2015-08-20 11:01:22

안녕하세요. HTTPS 캐싱 관련하여 글을 남깁니다.

 

결론적으로 캐싱 장비에서 HTTPS 기반의 콘텐츠 (예, 비디오)를 현재 캐싱하지는 못합니다. Content 제공자가 사용하는 암호화 Key값을 캐싱 장비가 알 수가 없기 때문입니다.

그러나, 만약 임의의 캐싱 장비가 기술적으로 해당 Key값을 인지하여 HTTPS 콘텐츠를 캐싱하게 된다면, 이는 Content 제공자의 Key값을 허락없이 해킹하여 사용한 것으로 간주되어 이후 둘 간 문제가 발생하게 될 것 입니다.

 

이러한 상황에서 저희 퀼트의 경우는 Streaming Video Alliance(http://www.streamingvideoalliance.org/)의 회원사로써 HTTPS 기반으로 콘텐츠를 서비스하는 SVA 회원사 중의 하나인 Ustream과 현재 HTTPS 비디오 캐싱을 시험 중에 있습니다. 혹시 기회가 된다면, 해당 시험 결과가 공개적으로 릴리즈될 때 여기에 소개해드릴 수 있기를 기대합니다.

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
banner
View All (1016)
5G (83) 5G 특화망 (2) AI (5) ALTO (1) AR (2) ARP (6) AT&T (1) Akamai (5) Authentication (5) BT (1) Backhaul (2) Big Data (2) Bridging (5) C-RAN/Fronthaul (17) CDN (20) CIoT (2) CPRI (6) Carrier Aggregation (5) Charging (2) China Mobile (2) Cisco (6) CoMP (3) Comcast (1) DHCP (6) DNS (15) Data Center (15) EDGE (14) EMM (1) EPS Bearer (7) Ethernet (3) FTTH (8) GSLB (5) Gigabit Internet (17) Google (17) Google Global Cache (8) Google TV (1) HLS (5) HTTP (5) HTTP Adaptive Streaming (7) HTTP Progressive Download (2) Handover (5) Huawei (1) IGMP (3) IP (6) IP Allocation (8) IP Routing (20) IPSec (4) IPTV (25) IoST (2) IoT (51) KT (45) Korea (8) Korea ICT Vendor (1) L3 Switch (5) LG U+ (24) LTE (99) LTE-A (10) LTE-A Pro (1) LTE-M (1) LTE-U (3) LoRa (5) MEC (15) MPLS (3) MWC 2013 (1) MWC 2015 (3) MWC 2016 (2) MWC 2017 (1) Mobile IPTV (1) Multi-Screen (1) Multicast (2) NAT (9) NB-IoT (6) NTT Docomo (1) Netflix (5) Network Protocol (49) Network Slicing (3) OSPF (3) OTT (20) Operator CDN (1) P2P (3) PS-LTE (3) Pooq (2) Private 5G (9) QoS (5) RCS (1) RRH (1) Request Routing (3) SD-WAN (8) SDN/NFV (38) SK Broadband (1) SK Telecom (38) Samsung (2) Security (8) Self-Driving (3) Shortest Path Tree (2) Small Cell (3) Spectrum Sharing (1) TAU (2) Transparent Caching (9) UHD (7) VLAN (2) VPN (3) VR (3) Video Streaming (22) VoLTE (1) VoWiFi (1) WAN Optimization (1) Wi-Fi (30) WiBro(WiMAX) (2) YouTube (16) eICIC (1) eMBMS (1) ePDG (6) u+ tv G (4) 로컬 5G (1)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2020년 1월 현재 넷매니아즈 회원은 49,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호