넷매니아즈 블로그를 통해 두차례에 걸쳐 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로 보내기 위해서
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가지입니다.
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 정도면 충분하다는 생각이 듭니다.
상호: (주)엔앰씨컨설팅그룹 주소: 서울시 강남구 테헤란로 128, 3층 387호 대표이사: 손장우 전화: 02-3444-5747 메일: webmaster@netmanias.com 등록번호: 서울 아03722 제호: 넷매니아즈 등록일자: 2015년 5월 4일 발행/편집인: 손장우 청소년보호책임자: 이수정
주소: 본사: 서울시 강남구 테헤란로 128, 3층 387호 Netmanias USA: 5214 36th Ave. NE Seattle, WA 98105 USA
Copyright ⓒ 2002-2023 NMC Consulting Group. All rights reserved.
|
TIC Cache HIT 동작 시 Origin서버 측에 Request를 전송하여 8KB 정도의 전송을 진행하고 끊는 액션은 TIC 표준규격(?)인가요?
또한 위의 액션을 통해서 Cache Content Validation Check를 수행하는데 사용한다고 하면, 기존 Cache 서버에서 Origin 서버의 컨텐츠에 대한 HTTP에서 제공하는 If-Modify-Since, Last-modified 등의 Header field를 사용한 validation check는 수행하지 않는 것인지요?
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를 보내는 경우가 많지 않을 것 같은데요.
질문이 있는데요. 요즘 동영상 컨텐츠들은 스트리밍 할때 일종의 url암호화 같은 작업들이 이루어 지는걸 볼 수 있는데요, 동일한 컨텐츠에 대해 클라이언트들 마다 다른 파일명을 보내준다던가 하는 방식이조... 이러한 컨텐츠들을 transparent하게 cache 할 수 있는 방법이 있나요?
결국은 TIC의 경우에는 validation에 대한 확인 방법은 기존 forward, reverse proxy cache에 사용하는 방식은 효율성이 떨어지거나 transparent proxy 정의(request/response에 대한 수정 불가)에 위배될 수 있겠네요.
제가 알고 있기로 TIC는 컨텐츠 구분을 URL로 하지 않고, 실제 컨텐츠 내용의 일부(예. 8KB)를 사용합니다.
즉, www.a.com/vod/movie1.mpg와 www.b.com/vod/movie1.mpg가 있고 movie1.mpg는 동일 컨텐츠라고 할 때,
URL로 구분을 하게 되면 이 2개의 컨텐츠는 다른 것으로 구분하지만 컨텐츠 내용의 일부로 구분을 하면 동일 컨텐츠로 구분할 수 있습니다.
따라서 말씀하신 URL 암호화 같은 작업으로 동일 컨텐츠에 대해 다른 이름을 주더라도 컨텐츠 내용이 변경되지 않는 한 동일 컨텐츠로 구분이 가능할 것으로 보입니다.
본문에 TIC Workflow를 보면 miss 시 (1. User Request Contents But Not Cached)에 컨텐츠의 캐싱유무를 확인하고 miss이면 유투브로 리퀘스트를 보내고 Proxy Caching 하는 것으로 해석되는데요, Workflow가 세밀하게 보면 약간 변경 되는 것인지요?
컨텐츠 구분에 URL을 이용하지 않는다면 최초 hit/miss를 판단할 때 무조건 원본쪽에서 데이터를 가지고 와서 확인을 해야 하는 것인가요?
정말 좋으신 질문이십니다. TIC 문서 상에는 그렇게 써져 있는데 저도 왜 그런지 아직 잘 모르겠더라구요.
며칠만 기다려 주세요. 어쩌면 그 의미를 알 수도 있을 것 같거든요 ^^*
저도 좀 알아보고 혹시 알게되면 빠르게 이곳에 댓글을 남기도록 하겠습니다.
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를 사용자에게 전달하면서 자신도 저장(캐싱)
감사합니다.
덕분에 헷갈리던 부분을 정리 할 수 있게되어 좋았습니다.
넷매니아즈에서 편의상 (캐싱에 포커스를 맞추느라고) TIC를 경유하지 않는 것처럼 그리셨을 것 같네요
그럼 모든 TCP정보를 알 수 있으니까 transparent tcp proxy가 가능하지요
권기석님이 문의하신 tcp의 윈도우사이즈, mss등등을 모르고도 tcp연결을 대행하는 것은 실험실에서는 가능할 지몰라도
실제 서비스용으로는 못 쓴다고 생각됩니다.
단말별/app별로 윈도우사이즈가 틀리고, MSS는 접속망별로 틀리기 때문이죠.
새벽에 문득 눈이 떠져서 잠시 들어와 봅니다.
아주 흥미로운 글 잘 봤습니다.
글을 계속 읽다보니 의문점이 생겼습니다. HTTP GET메시지와 해당 Response 메세지를 통해 Content Availability Check를 한다고하였는데요. 이건 HTTP 즉, 암호화를 안했을 경우 확인이 가능한거고, 예를 들어 HTTPS 즉, TLS를 사용해여 통신을 하게 된다면, 과연 정상적으로 TIC가 처리가 될까 의문이 생겼습니다. 최근 Youtube는 모두 HTTPS(TLS)를 사용하는게 사실이고요.
그럼 이런 상황에서는 어떠한 방법으로 처리되는지도 궁금합니다.
추가적으로 TIC에서 YouTube서버로 Tcp terminate를 한다고 했는데요. terminate하는 방법이 궁금합니다.
안녕하세요. HTTPS 캐싱 관련하여 글을 남깁니다.
결론적으로 캐싱 장비에서 HTTPS 기반의 콘텐츠 (예, 비디오)를 현재 캐싱하지는 못합니다. Content 제공자가 사용하는 암호화 Key값을 캐싱 장비가 알 수가 없기 때문입니다.
그러나, 만약 임의의 캐싱 장비가 기술적으로 해당 Key값을 인지하여 HTTPS 콘텐츠를 캐싱하게 된다면, 이는 Content 제공자의 Key값을 허락없이 해킹하여 사용한 것으로 간주되어 이후 둘 간 문제가 발생하게 될 것 입니다.
이러한 상황에서 저희 퀼트의 경우는 Streaming Video Alliance(http://www.streamingvideoalliance.org/)의 회원사로써 HTTPS 기반으로 콘텐츠를 서비스하는 SVA 회원사 중의 하나인 Ustream과 현재 HTTPS 비디오 캐싱을 시험 중에 있습니다. 혹시 기회가 된다면, 해당 시험 결과가 공개적으로 릴리즈될 때 여기에 소개해드릴 수 있기를 기대합니다.