<![CDATA[
<p>CDN overview <br>CDN 기술의 이해 2018.07 | 김유현 <br>목 차 1. CDN Business Overview 2. Internet Technology Basics 3. CDN Overview 4. Caching technology 5. Acceleration technology <br>1. CDN Business Overview <br>- 4 - • CDN의 역사를 살펴보면, 한국은 2000년도, 미국은 1997년도로 거슬러 올라감. • 미국은 인터넷 제반 인프라가 고도로 발달하지 못했기 때문에 ISP간의 IX구간 네트워크 라우팅을 최적화하는 방향으로 발전했음. 즉, 네트워크 홉 (Hop) 수 기반으로 최적 경로를 산출하는 것 (Route Optimization), RTT (Round Trip Time)을 최소화할 수 있는 경로로 라우팅 하는 것, 가장 가까운 라우팅 거리라고 해도 병목현상이 발생하는 IX 구간을 우회하는 경로로 라우팅 하는 것, 이러한 것들이 미국이 먼저 발전시켜왔던 기술임. • 반면, 한국은 ISP간의 IX 구간이 열려 있고, ISP의 제반 기술 및 인프라 투자가 높았기 때문에 2000년대 초기 외에는 이러한 고민을 할 필요가 없었음. 그래서 사용자 트래픽을 탄력적으로 대응하는 구 성으로 발전해왔음. • CDN 기술 발전 역사 1. 2000년대 초반~2000년대 중반: Static/Dynamic content delivery 2. 2000년대 중반~2000년대 후반: Media Delivery (VoD, Live Streaming), Global CDN 3. 2000년대 후반~2013: Enterprise Application 가속, Mobile CDN 4. 2014년~현재: Security, Mobile-Focused The History of CDN <br>- 5 - CDN Market Size • CDN 시장은 여전히 성장 중 1. 글로벌 CDN 시장은 2014년 매출액 기준 약 35억 달러 (약 4조 2천억 원) 규모이고, 2015년에는 14% 성장 한 약 40억 달러 (약 4조 7천억 원) 규모로 예상되며, 연평균 성장률 14%로 성장하여 2019년에는 약 68억 달러 (약 8조 2천억 원) 규모가 될 것으로 전망 <br>- 6 - Regional Market Overview • 2015년 기준 북미 시장이 전체 시장의 과반 (약 63%) 이상을 차지하고 있는 가장 큰 시장이며, 유럽 (17%), ASIA- PACIFIC (19%), 남미 (1%) 순 • 북미 시장 키워드 – Video, Large file delivery / Akamai Home Ground • EMEA 시장 키워드 – Online Video, SNS, Gaming (and gambling) • APAC 시장 키워드 – 한국, 일본, 중국 시장 경쟁 가속화 / 중국, 홍콩, 한국의 경제 성장 둔화 • 남미 시장 키워드 – 경제 성장 potential, 모바일, OTT 서비스 <br>- 7 - Competition Dynamics • Akamai가 전체 시장에서 가장 큰 Market Share를 차지 • Akamai – 2013년 Prolexic 인수 후 Security가 성장을 견인 중 / 활발한 인수 합병 진행 중 • CDNetworks – Security (DDoS/WAF) 와 Network performance 강조 • ChinaCache – 글로벌 서비스 확장 중 (NovaCDN 브랜드 북미 런칭) • Level 3 – DDoS 서비스 런칭, CDN 서비스와 독 립적으로 판매 • Limelight Networks – DDoS 서비스 런칭 • 그 밖에 AWS (Amazon Web Service), CloudFlare, China Net Center도 시장에서 영향 력을 미치고 있음. <br>- 8 - • 전통적 CDN 상품인 Media Delivery의 가격은 지속적으로 하락하고 있는 추세임. 1. <a href="http://blog.streamingmedia.com/wp-content/uploads/2015/08/2015CDNSummit-Rayburn-" target="_blank" class="ke-link">http://blog.streamingmedia.com/wp-content/uploads/2015/08/2015CDNSummit-Rayburn-</a> Pricing.pdf 2. 단순 Media Delivery 상품의 Big volume customer의 경우 약 10PB 약정에 $0.006/GB ~ $0.01/GB 의 가격이 형성되어 있음. 3. 2015년 단가는 2014년 통계보다 31% 하락하였음. (7PB commit | $0.007/GB ~ $0.01/GB) 4. 2014년 단가는 2013년에 비해 26% 하락하였음. 5. 단가 하락의 추세는 가속화되고 있는 상황임. 시장 Pie도 늘어나고 있지만, 경쟁이 심 화되고 있음을 보여줌. Price Degradation <br>2. Internet Technology Basics <br>- 10 - Internet Basics • 인터넷은 컴퓨터 (혹은 스마트기기)로 연결하여 TCP/IP (Transmission Control Protocol/Internet Protocol)라는 통신 프로토콜을 이용해 전 세계 수십억 명의 사용자들에게 제공되는 지구 전체의 컴퓨 터 네트워크 시스템을 의미함. • 대중적인 월드 와이드 웹 (WWW)은 HTTP (Hyper Text Transfer Protocol)와 함께 사용되고, HTTP로 되어 있는 웹 페이지를 보기 위한 웹 브라우저로는 Microsoft의 Internet Explorer, Mozilla의 Firefox, Google의 Chrome 등을 이용함. • 하이퍼텍스트 (Hypertext)는 참조 (하이퍼링크)를 통해 독자가 한 문서에서 다른 문서로 즉시 접근할 수 있도록 한 텍스트를 의미함. • 인터넷은 개인, 학교, 기업, 정부 네트워크 등을 한정적 지역에서 전체 영역으로 유선, 무선, 광케이블 기술 등을 통해 연결하여 구성한 네트워크들의 네트워크임. • 인터넷 구축에 사용된 하드웨어와 프로토콜은 전화, 음악 스트리밍, 영화 스트리밍, 게임, 홈 서버 등의 서비스를 그대로 구현함. • 신문이나 도서 등의 출판물들도 웹사이트 기술에 맞춰 새롭게 구현되었는데, 블로그나 RSS 등과 같은 형태로 독자들에게 서비스 중임. • 인터넷에 의해 사람들의 소통방식도 인스턴스 메시지 (IM), 인터넷 포럼, SNS 등으로 진화하고 있음. <br>- 11 - Web Browsing • 접속하고자 하는 웹 페이지의 Domain name을 브라우저 상에 입력하여 접속하나, 실제로는 해당 웹 페 이지의 IP 주소로 접속함. • IP주소는 일종의 전화번호 개념이고, 흔히 Contact name과 전화번호를 mapping한 전화번호부를 사용 하듯이, 웹 페이지의 Domain name (예. <a href="http://www.google.com)과" target="_blank" class="ke-link">http://www.google.com)과</a> IP주소를 mapping한 DNS (Domain Name System)를 사용하여 웹 페이지에 접속함. • TCP는 인터넷에 연결된 컴퓨터에서 실행되는 프로그램 간에 정보를 안정적으로, 순서대로, 에러 없이 교환할 수 있게 하며, 웹 브라우저가 월드 와이드 웹에서 서버에 연결할 때 혹은 이메일 전송이나 파일 전송에도 사용함. Internet Hey, 213.236.208.98, show me your home page. HTTP 200 – OK Here you go: <HTML>... 213.236.208.98 <br>- 12 - Cache • 캐시란 (Cache) “앞서 사용된 데이터를 저장하고 있다가 재 요청이 있을 경우 원래의 장치에 요청하지 않고, 좀 더 빠르게 응답해 주는 것”을 의미함. • 캐시 메모리 (Cache memory): 컴퓨터 시스템의 성능을 향상시키기 위해 주로 CPU 칩 안에 포함된 빠 르고 작고 비싼 메모리를 말함. <br>- 13 - Cache • ARP (Address Resolution Protocol) 캐시: TCP/IP에서 실제 데이터들은 Destination IP 주소가 아닌 Destination MAC (Media Access Control) 주소에 (하드웨어 물리적 주소) 의해서 매체간 이동이 이루어 지며 Destination MAC 주소를 찾기 위해 ARP를 사용. 대부분의 네트워크장비 (PC, 서버, 스위치, 라우 터 등)들은 이 정보를 재사용하기 위해 IP주소와 MAC 주소를 메모리에 일정시간 기억하게 되고 이것을 ARP 캐시라 함. • DNS 캐시: 도메인 이름을 IP로 응답해 주는 DNS 역시 캐시를 가지고 있으며, 네트워크 장비들이 ARP 캐시를 사용하는 이유는 IP가 자주 바뀌지 않기 때문이고, DNS도 도메인 이름에 할당된 IP가 바뀔 가능 성이 적기 때문임. DNS 요청에 대한 DNS 서버 부하를 줄이기 위해 얻어진 결과 값에 대해 일정기간 캐시를 하고 클라이언트의 요청이 있을 경우 캐시의 정보로 응답함. • 웹 브라우저 캐시: 브라우저는 속도를 높이기 위해 사용자가 한 번 본 페이지를 저장하고 있다가 같은 페이지를 재 요청하면 캐시 데이터를 확인하여 응답하는 방식을 사용하는데 이를 웹 브라우저 캐시라 고 함. <br>- 14 - DNS Basic Operation • 인터넷에서 통신을 하기 위해서 모든 단말은 IP주소가 설정되어 있어야 함. 사람이 이해하기 쉬운 Domain name을 IP주소로 변환해 주는 것을 DNS resolving이라고 함. • DNS 동작 원리 (다음 Page 그림 참조) 1. 브라우저에서 <a href="http://www.test.com을" target="_blank" class="ke-link">http://www.test.com을</a> 입력하면, PC는 미리 설정되어 있는 DNS (이 DNS를 Local DNS라 고 부름)에게 <a href="http://www.test.com이라는" target="_blank" class="ke-link">http://www.test.com이라는</a> hostname에 대한 IP 주소를 물어봄. Local DNS에는<a href="http://www.test.com에" target="_blank" class="ke-link">http://www.test.com에</a> 대한 IP주소가 있을 수도 없을 수도 있으며, Local DNS가 이미 가지고 있는 경우 (캐시 되어 있는 경우) 바로 IP주소를 주고 동작을 끝내게 됨. 2. 하지만 Local DNS가 해당 IP주소를 가지고 있지 않은 경우 Local DNS는 “<a href="http://www.test.com에" target="_blank" class="ke-link">http://www.test.com에</a> 대한 IP주소“를 찾아내기 위해 다른 DNS서버들과 통신을 시작함. 먼저 Root DNS 서버에게 “<a href="http://www.test.com에" target="_blank" class="ke-link">http://www.test.com에</a> 대한 IP주소＂를 가지고 있는 지 물어봄. 이를 위해 각 Local DNS 서버에는 Root DNS 서버의 정보 (IP주소)가 미리 설정되어 있어야 함. (Root DNS 서버 는 전 세계에 13대가 구축되어 있으며 우리 나라의 경우 Root DNS Mirror 서버를 3대 운용하고 있 음.) 3. Root DNS 서버는 “<a href="http://www.test.com의" target="_blank" class="ke-link">http://www.test.com의</a> IP주소”에 대한 정보가 없어 Local DNS에게 “.com 도메인을 관 리하는 DNS서버”에게 물어보라는 응답을 하게 됨. 4. Local DNS는 .com DNS서버에게 “<a href="http://www.test.com에" target="_blank" class="ke-link">http://www.test.com에</a> 대한 IP주소“를 문의하고, 5. 역시 “.com DNS 서버”에도 해당 정보가 없어, “.com DNS 서버”는 “test.com을 관리하는 DNS서버” 에게 물어보라는 응답을 하게 됨. 6. Local DNS는 “test.com DNS서버”에게 “<a href="http://www.test.com에" target="_blank" class="ke-link">http://www.test.com에</a> 대한 IP주소“를 문의하고, 7. “test.com DNS 서버”에는 “<a href="http://www.test.com" target="_blank" class="ke-link">http://www.test.com</a> hostname에 대한 IP주소가 있어, 173.194.33.17을 응답함. 8. 이를 수신한 LDNS는 “ <a href="http://www.test.com에" target="_blank" class="ke-link">http://www.test.com에</a> 대한 IP주소를 캐시하고 해당 IP 주소를 브라우저에 전달함. <br>- 15 - DNS Basic Operation • 이와 같이 Local DNS 서버가 여러 DNS 서버를 차례대로 (Root DNS 서버 - .com DNS 서버 – test.com DNS 서버) 질의하여 답을 찾는 과정을 “Recursive Query”라고 부름 • Terminology 1. Domain:<a href="http://www.test.com" target="_blank" class="ke-link">http://www.test.com</a> (test.com이 Domain name) 2. Sub-domain: images.test.com (images가 Sub-domain) 3. Hostname: images.test.com 4. URL: <a href="http://www.test.com/index.html" target="_blank" class="ke-link">http://www.test.com/index.html</a> (Hostname + path) 5. Top level domain name: .com 6. Second level domain name: test.com <br>- 16 - DNS resolving Client requests IP address of <a href="http://www.test.com" target="_blank" class="ke-link">http://www.test.com</a> from DNS server DNS Resolver (LDNS) 1. Request to resolve <a href="http://www.test.com" target="_blank" class="ke-link">http://www.test.com</a> Root DNS server Top Level DNS server for .com example.com name server <a href="http://www.test.com" target="_blank" class="ke-link">http://www.test.com</a> Web server (173.194.33.17) 4. Address of <a href="http://www.test.com" target="_blank" class="ke-link">http://www.test.com</a> 5. Referral to test.com name server8. Return 173.194.33.17 <a href="http://www.test.com." target="_blank" class="ke-link">http://www.test.com.</a> IN A Request <a href="http://www.test.com" target="_blank" class="ke-link">http://www.test.com</a> 37872 IN CNAME <a href="http://www.test.com.cdngc.net" target="_blank" class="ke-link">http://www.test.com.cdngc.net</a> <a href="http://www.test.com.cdngc.net" target="_blank" class="ke-link">http://www.test.com.cdngc.net</a> 75 IN A 173.194.33.20 Response Domain requested for lookup Requested record type Time-To-Live of record DNS record type Resolved IP address • “CNAME” record = Domain Name to another domain name ( <a href="http://www.test.com" target="_blank" class="ke-link">http://www.test.com</a> CNAME g1.test.co<a href="http://m.cdngc.net)" target="_blank" class="ke-link">http://m.cdngc.net)</a> • “A” record = <a href="http://www.test.com" target="_blank" class="ke-link">http://www.test.com</a> A 173.194.33.17 • 고객 Domain을 (Origin) 자사의 CDN 네트워크 에 위임하여 “CNAME”처리하면, 고객 Origin IP 주소가 아닌 자사 edge 서버의 IP 주소를 return <br>- 17 - Web Cache • 웹 캐시란 (Web Cache) 하나의 사용자를 위한 브라우저 캐시와는 달리 대다수 사용자를 대상으로 함. 사용자가 많은 만큼 같은 사이트를 방문할 가능성이 높으므로 재 사용될 가능성도 브라우저 캐시에 비 해서 상당히 높음. 일반적으로 사용자가 많으면 많을수록 웹 캐시는 더 많은 효과를 볼 수 있게 됨. 가 장 큰 특징은 특정 웹 페이지를 요청할 경우 두 번째 클라이언트부터는 멀리 있는 서버 (Origin server) 까지 가지 않고 직접 응답한다는 것임. • 웹 캐시는 인터넷의 통로인 게이트웨이에 존재하기도 하지만 대규모 웹 사이트를 운영하는 곳은 아래 그림과 같이 웹 서버 앞에 위치하여 웹 서버보다 먼저 클라이언트에게 응답을 해 주어 서버의 부하를 줄여주는 가속기 (Accelerator) 형태로 많이 사용됨. 인터넷 웹 클라이언트 웹 클라이언트 웹 클라이언트 게이트웨이 가속기 웹 서버 서버를 위한 캐시 클라이언트를 위한 캐시 <br>- 18 - Forward Cache System • 포워드 캐시 (Forward Cache): 일반적인 사용자들이 생각하는 보편적인 형태로서 사용자의 인터넷 앞 에 위치하여 속도를 높여줌. 포워드 캐시의 가장 큰 목적은 인터넷 구간의 “회선비용절감”임. 캐시를 사 용하면 속도가 빨라지는데, 이는 클라이언트가 요청한 콘텐츠를 회선 대역폭이 작은 인터넷 바깥 영역 을 통하지 않고 속도가 빠른 로컬에서 응답을 하기 때문임. • 포워드 캐시 시스템은 라우터 바로 아래 설치가 되어 많은 사용자가 캐시를 통과하도록 구성함. 포워드 캐시는 네트워크 내의 많은 사용자는 물론 인터넷 밖의 수많은 서버들과 통신을 함. (1대의 캐시 (edge server) – 여러 대(고객)의 웹 서버와 (Origin Server) 통신) 인터넷 웹 클라이언트 웹 클라이언트 웹 클라이언트 웹 캐시 <a href="http://www.cdnetworks.com" target="_blank" class="ke-link">http://www.cdnetworks.com</a> <a href="http://www.daum.net" target="_blank" class="ke-link">http://www.daum.net</a> <a href="http://www.naver.com" target="_blank" class="ke-link">http://www.naver.com</a> . . . <br>- 19 - Reverse Cache System • 리버스 캐시 (Reverse Cache): 포워드 캐시와는 달리 사용자의 인터넷 앞이 아니라 인터넷을 지나서 웹 서버의 앞에 설치가 된 형태를 말함. 이 경우 캐시는 회선절감과는 무관하게 서버 대신 일을 함으로 써 서버의 부하를 줄여주는 역할을 함. • 리버스 캐시가 웹 서버의 IP를 가지고 있으므로 외부에서는 무조건 캐시로 요청할 수 밖에 없음. 만약 캐시가 클라이언트의 요청 콘텐츠를 가지고 있지 않다면 캐시는 설정된 서버와 통신을 하 고 jsp와 같은 동적 콘텐츠는 항상 캐시가 아닌 웹 서버에서 처리됨. • 리버스 캐시는 다른 용어로 웹 서버의 성능을 높여주는 웹 가속기 (Web Accelerator)라고도 함. 인터넷 웹 클라이언트 웹 클라이언트 웹 클라이언트 웹 캐시 웹 서버 Reverse cache = 192.168.10.1 W1=192.168.10.2 W1=192.168.10.3 W1=192.168.10.4 <br>- 20 - Transparent Cache System • 트랜스페어런트 캐시 (Transparent Cache): Transparent (투명한)이란 말 그대로 사용자 입장에서는 캐 시가 있는지 없는지 모르는 상태로 캐시 서버를 위치시키는 형태를 말함. 트랜스페어런트 캐시는 포워 드나 리버스 형태 모두 사용될 수 있지만 일반적으로 별도의 장비 (로드밸런서나 라우터)의 도움을 받 아서 구성함. • 트랜스페어런트 구성의 가장 큰 장점은 캐시에 장애가 발생하더라도 로드밸런서와 같은 장비에서 이를 감지하여 실제 웹 서버로 트래픽을 보내므로 캐시의 장애로 인한 전체 웹 사이트가 다운되는 문제가 발 생하지 않음. 또한 인터넷 구간의 회선 비용을 절감할 수 있음. 인터넷 웹 클라이언트 웹 클라이언트 웹 클라이언트 웹 캐시 웹 캐시 웹 서버 라우터/스위치라우터/스위치 웹 트래픽 <br>- 21 - Proxy, Cache Miss / Cache Hit • 프록시 (Proxy): 보통 캐시를 프록시라고 부르는데 명확히 하면 캐시는 프록시 서버의 일종임. 프록시 란 클라이언트의 요청에 대해 클라이언트를 대신해서 서버로 요청을 하고 그 결과를 다시 클라이언 트에게 되돌려주는 아주 간단한 일을 하는 것을 가리킴. • Cache Miss / Cache Hit: 클라이언트가 캐시에게 “<a href="http://www.cdnetworks.com/Media" target="_blank" class="ke-link">http://www.cdnetworks.com/Media</a> Acceleration.jpg”이라는 그림을 요청했다고 가정하면, 캐시는 이 요청에 대한 응답을 했는지를 먼저 확 인하고, 1) 이전에 응답한 적이 없었다면 이것은 “Cache Miss”가 되며, 캐시는 <a href="http://www.cdnetworks.com" target="_blank" class="ke-link">http://www.cdnetworks.com</a> 서 버에 Media Acceleration.jpg를 요청하게 됨. • 만약 2) 이전에 응답한 적이 있다면 이것은 “Cache Hit”가 되고, 클라이언트가 요청한 콘텐츠가 캐시 서 버에 존재하여 직접 클라이언트에 응답을 주게 됨. 캐시를 운영하는 입장에서는 Hits가 많을수록 좋음. Hit Ratio는 캐시의 효과를 나타내는 척도로 사용됨. 인터넷 웹 클라이언트 웹 클라이언트 웹 캐시 <a href="http://www.cdnetworks.com" target="_blank" class="ke-link">http://www.cdnetworks.com</a> <a href="http://www.daum.net" target="_blank" class="ke-link">http://www.daum.net</a> <a href="http://www.naver.com" target="_blank" class="ke-link">http://www.naver.com</a> Cache Hit Cache Miss <br>- 22 - Freshness / Validation check • Freshness check: Freshness란 클라이언트가 요청한 콘텐츠를 캐시에서 직접 주어도 되는지 판단하는 것을 말함. 캐시는 응답했던 콘텐츠가 가지고 있는 유효기간 (Expiration time)을 제일 먼저 확인하며 이 정보는 HTTP 응답 헤더의 max-age나 Expires를 참조하면 됨. 예를 들어 max age=86,400s (24시간)이지만 캐시가 응답한지 아직 24시간이 지나지 않았으면 이 콘텐츠는 Fresh하다 고 판단할 수 있음. (Cache Hit) • 유효성(Validation) check: Hit된 콘텐츠가 캐시에서 Fresh하지 않은 콘텐츠로 판단되면 웹 서버로 콘텐츠 재사용 여부를 묻게 됨. 웹 서버는 자신이 가지고 있는 콘텐츠와 비교하여 1) 아직 사용 가능할 경우 “304 Not Modified” 메시지만을 보내 재사용하게 하고, 2) 사용 불가능할 경우 새 콘 텐츠를 내려 보내게 됨. 인터넷 웹 클라이언트 웹 클라이언트 웹 캐시 <a href="http://www.cdnetworks.com" target="_blank" class="ke-link">http://www.cdnetworks.com</a> <a href="http://www.daum.net" target="_blank" class="ke-link">http://www.daum.net</a> <a href="http://www.naver.com" target="_blank" class="ke-link">http://www.naver.com</a> 5. Update 4. Response 3. Validation check2. Freshness check 1. Cache Hit <br>3. CDN Overview <br>- 24 - Content Delivery Network • 콘텐츠 전송 네트워크 (CDN – Content Delivery Network): 콘텐츠를 효율적으로 전달하기 위해 여러 노드 (웹 캐시)를 가진 네트워크에 데이터를 저장하여 제공하는 시스템. 인터넷 서비스 제공자 (ISP – Internet Service Provider)에 직접 연결되어 데이터를 전송하므로, 콘텐츠 병목을 피할 수 있는 장점이 있음. • CDN의 목적은 높은 사용성과 효율로 사용자에게 콘텐츠를 전달함에 있음. CDN은 오늘날 인터넷에 존재하는 콘텐츠의 상당수를 서비스하고 있는데, 여기에는 웹 요소 (텍스트, 그래픽, 스크립트), 다운 로드 가능한 요소 (미디어 파일, 소프트웨어, 문서), 애플리케이션 (전자상거래, 포털), 실시간 미디 어, 주문형 스트리밍 등이 포함됨. • 미디어 회사나 전자상거래 업체와 같은 콘텐츠 제공자는 (CP – Content Provider) 그들의 콘텐츠를 사 용자들에게 전달하기 위해서 CDN 사업자에 사용료를 지불하고, 반대로, CDN 사업자는 ISP 그리고 네 트워크 사업자들에게 데이터 센터에서의 서버 호스팅 비용을 지불함. 더 나은 퍼포먼스와 (Performance) 사용성 (Service Availability) 이외에도 CDN은 콘텐츠 제공자의 서버의 (Origin server) 트래픽을 덜어주어 콘텐츠 제공자의 비용을 줄여줌. • CDN은 대규모 분산 서버 장비로 공격 트래픽을 완화할 수 있으므로 콘텐츠 제공자에게 DoS 공격에 대 해서도 어느 정도 보호해 줄 수 있음. 초기 대부분의 CDN 사업자는 각 Vendor가 소유하고 동작하는 서 버를 사용하는 콘텐츠만 서비스하였으나 최신 트렌드는 P2P기술을 이용하는 하이브리드 모델을 사용 하는 것임. 하이브리드 모델에서 콘텐츠는 지정된 서버 그리고 주변 컴퓨터(peer-user-owned)를 모두 사용함. <br>- 25 - • 전통적으로 CDN은 캐싱 (Caching)이라는 기술을 기반으로 빠르게 콘텐츠를 전달해 왔음. CDN의 역사 를 살펴보면, 한국은 2000년도, 미국은 1997년도로 거슬러 올라감. • 미국은 인터넷 제반 인프라가 고도로 발달하지 못했기 때문에 ISP간의 IX구간 네트워크 라우팅을 최적화하는 방향으로 발전했음. 즉, 네트워크 홉 (Hop) 수 기반으로 최적 경로를 산출하는 것 (Route Optimization), RTT (Round Trip Time)을 최소화할 수 있는 경로로 라우팅 하는 것, 가장 가까운 라우팅 거리라고 해도 병목현상이 발생하는 IX 구간을 우회하는 경로로 라우팅 하는 것, 이러한 것들이 미국이 먼저 발전시켜왔던 기술임. • 반면, 한국은 ISP간의 IX 구간이 열려 있고, ISP의 제반 기술 및 인프라 투자가 높았기 때문에 2000년대 초기 외에는 이러한 고민을 할 필요가 없었음. 그래서 사용자 트래픽을 탄력적으로 대응하는 구 성으로 발전해왔음. • CDN 기술 발전 역사 1. 2000년대 초반~2000년대 중반: Static/Dynamic content delivery 2. 2000년대 중반~2000년대 후반: Media Delivery (VoD, Live Streaming), Global CDN 3. 2000년대 후반~2013: Enterprise Application 가속, Mobile CDN 4. 2014년~현재: Security, Mobile-Focused The History of CDN <br>- 26 - First mile, Middle mile and Last mile • 퍼스트 마일 – 데이터센터로부터 (IDC – Internet Data Center) 인터넷서비스제공자 (ISP)까지 콘텐츠가 전송되는 구간 • 미들 마일 – 퍼스트 마일에서 라스트 마일 사이에 있는 구간으로 콘텐츠 제공 사업자와 사용자 사이에 있는 ISP들간에 연결된 구간 • 라스트 마일 – 지역 ISP로부터 일반 사용자에게 콘텐츠가 전달되는 구간 Origin Web server (IDC) ISP Local ISP Internet Middle Mile End user Last Mile Middle Mile First Mile End user End user End user <br>- 27 - Middle mile problem “Origin Server” Customer web site “End User” Last Mile Middle Mile First Mile • Same ISP/Location • Low latency • High Bandwidth • Same Data Center/ISP • Low latency • High Bandwidth Bad Routing Network Failure Long distance <br>- 28 - Middle Mile problem without CDN • CDN이 없는 기존 모델에서는, 1. 콘텐츠 제공자 (CP) 입장: 서버 이중화를 고려하지 않은 환경에서 콘텐츠 웹 서버와 연결된 네 트워크에 장애가 발생하면, 극단적인 경우 콘텐츠를 사용자에게 제공할 수 없는 상황에 직면할 수 있음. 또한 일시적으로 수많은 사용자들이 동시에 콘텐츠 웹 서버에 접속을 시도하게 되 면 콘텐츠 서버와 연결된 네트워크 구간에서 병목 현상이 발생하여 사용자에게 원활한 서비스 제공 이 어려워짐. 결국 대용량의 콘텐츠를 원활하게 제공하기 위해서는 콘텐츠 증가에 비례하여 고사양 의 콘텐츠 서버 및 서버의 네트워크 회선 용량 증설이 필요하며 이로 인한 비용 발생이 늘어나게 됨. 2. 인터넷 서비스 제공자 (ISP) 입장: ISP의 가입자가 외국에 위치한 서버의 콘텐츠 서비스를 이용하는 경우, 연결 과정에서 트래픽은 수 많은 ISP 혹은 IXP (Internet eXchange Provider)를 거치는데, 이 경 우 해당 ISP는 다른 ISP 혹은 IXP에 트래픽 양에 비례하여 회선 비용을 지불해야 함. 따라서 대용량 멀티미디어 트래픽이 빈번하게 전송되는 경우 해당 ISP가 지불해야 하는 회선 비용은 지속적으로 증가할 수 밖에 없음. 3. 콘텐츠 사용자 (End user) 입장: 물리적으로 멀리 떨어진 콘텐츠 웹 서버에 접속하여 콘텐츠를 받아 오는 경우, 사용자는 회선 거리에 따라 End-to-End delay 값 (RTT – Round Trip Time)의 증가로 인해 보다 빠른 시간 안에 원하는 콘텐츠를 제공 받기 어렵게 됨. 예를 들어, 미국 에 있는 YouTube 서버에 저장된 콘텐츠를 한국에서 제공받고자 할 때, 서버에서 클라이언트까지 라 우팅 홉 수가 상당히 많기 때문에 느린 속도로 콘텐츠를 제공받을 수 밖에 없음. • 이러한 문제들을 해결하기 위해서는 네트워크 용량 증설, 서버 용량 증설, 서버 이중화 등과 같이 끊임 없는 네트워크 및 시스템 확장이라는 요구사항이 동반됨. <br>- 29 - Solution for Middle mile problem (CDN) • CDN 서비스를 적용하게 되면, 1. 콘텐츠 제공자 (CP) 입장: 콘텐츠 서버와 연결된 네트워크에 장애가 발생하더라도, 콘텐츠는 다른 여러 지역에 위치한 캐시 서버에 저장되어 있으므로 콘텐츠 제공자는 정상적으로 사용자에게 콘텐 츠를 제공할 수 있으며 (지역적 이중화 (Geographical Redundancy) 보장), 또한 다수의 사용자가 하 나의 콘텐츠를 동시에 요청하더라도 그 모든 요청들이 하나의 콘텐츠 서버로 집중되지 않고 각 사용 자의 접속 위치에 따라 여러 곳에 배치되어 있는 캐시 서버로 분산되기 때문에, 콘텐츠 제 공자는 접속 폭주에 따른 서비스 불가 문제 해결 및 성능 향상 등과 같은 효과를 기대할 수 있음. 2. 인터넷 서비스 제공자 (ISP) 입장: 여러 지역에 분산된 CDN 사업자의 캐시 서버에 콘텐츠를 미리 가 져다 놓음으로써 외부 ISP 혹은 IXP를 통해 전송되는 구간 즉, 미들 마일 (Middle-Mile)을 지나 는 트래픽의 양이 현저히 감소하게 되고, 이에 따라 ISP는 기존 클라이언트-서버 환경에서 콘텐 츠 전송을 위해 소요되던 막대한 회선 비용을 줄일 수 있음. 이러한 이유로 ISP가 자사의 데이 터센터에 CDN 사업자의 캐시 서버를 “무상”으로 호스팅 해 주는 경우도 있음. (예. LGU+의 YouTube 무상 호스팅) 3. 콘텐츠 사용자 (End user) 입장: 사용자의 콘텐츠 요청을 해당 웹 서버가 아닌, 사용자에게 근접한 위치의 캐시 서버가 처리함으로써 End-to-End delay가 현저히 줄어들게 됨에 따라, 사용자는 기존 네트워크 환경에서의 응답속도에 비해 훨씬 빠른 시간 안에 원하는 콘텐츠를 제공받을 수 있는 효과를 볼 수 있음. 또한 기존 클라이언트-서버 환경에 비해 콘텐츠를 제공하는 서버에서 클라이언트까지 라우팅 홉 수가 상대적으로 적기 때문에 네트워크에서 Congestion이 발생할 확률 또한 낮아지는 효과를 기대할 수 있음. <br>- 30 - Without Cache vs With Cache 웹 클라이언트 웹 클라이언트 웹 클라이언트 웹 클라이언트 웹 클라이언트 웹 클라이언트 웹 서버 (Origin server) 웹 클라이언트 웹 클라이언트 웹 클라이언트 웹 클라이언트 웹 클라이언트 웹 클라이언트 웹 서버 (Origin server) One Central web server Many Cache servers 캐시 캐시 캐시 캐시 캐시 <br>4. Caching technology <br>- 32 - Static Content / Dynamic Content 콘텐츠 유형별 가속 기술 동적 콘텐츠 (Dynamic content) 정적 콘텐츠 (Static Content) 캐시 가능 콘텐츠 캐시 불가능 콘텐츠엣지 서버에 캐시 할 수 있고 사용자 요청에 상관없이 결과값이 동일한 콘텐츠 (예: 이미지, 텍스트, 동영상) 엣지 서버에 캐시 하면 안되고 사용자 요청에 상관없이 결과값이 동일한 콘텐츠 (예: 건설/자동차 설계 도면) 엣지 서버에 캐시 할 수 없고 사용자 요청에 따라 결과값이 달라지는 콘텐츠 (예: 영화/항공 좌석 예매) 엣지 서버에 캐시 할 수 있으나 사용자 요청에 따라 결과값이 달라지는 콘텐츠 (예: 포털 지도) Static Content Cache TCP & Route optimization <br>- 33 - Static and Dynamic Caching • 다시 한 번 이야기하면, CDN 서비스는 사용자와 지리적으로 멀리 떨어져 있는 Origin Server (고객의 웹 서버)로부터 콘텐츠 (예. Web object, 음악, 이미지, 문서 등)을 다운로 드 받으면 시간이 오래 걸리므로 사용자와 가까운 곳에 위치한 캐시 서버에 해당 콘텐츠를 저장 (Caching)하고 콘텐츠 요청 시에 캐시 서버가 응답을 주는 기술임. 따라서 사용자는 가 까운 곳에 있는 캐시 서버로부터 콘텐츠를 수신하므로 빠르게 다운로드 할 수 있게 됨. • Static Caching 1. 사용자의 요청이 없어도 Origin Server에 있는 콘텐츠를 운영자가 미리 캐시 서버에 복사함. 2. 사용자가 캐시 서버에 접속하여 콘텐츠를 요청하면 무조건 그 콘텐츠는 캐시 서버에 있음. (100% Cache hit) • Dynamic Caching 1. 최초 캐시 서버에는 콘텐츠가 없음. (Cache Miss) 2. 사용자가 콘텐츠를 요청하면 해당 콘텐츠가 있는지 확인하고, 없으면 Origin Server로부터 다운로드 받아 사용자에게 전달해 줌. 3. 이후 동일 콘텐츠를 요청 받으면 저장 (Caching)된 콘텐츠를 사용자에게 전달함. (Cache Hit) 4. 각 콘텐츠는 일정 시간 (TTL - Time To Live)이 지나면 캐시 서버에서 삭제되거나 Origin Server를 통 해 콘텐츠 Freshness 확인 후에 계속 가지고 있을 수 있음. <br>- 34 - Request Routing • Request Routing은 사용자의 콘텐츠 Request에 (예. 게임파일 다운로드) 대해 최적의 캐시 서버를 선택해 주는 기능으로 이를 위해 CDN 네트워크에는 Request Router가 존재함. Request Router는 DNS 기능을 지원하며 사용자의 콘텐츠 요청을 글로벌 네트워크 상의 적절한 캐시 서버로 Redirection 해 줌. 1. 사용자가 요청한 origin.example.com에 대해 example.com DNS 서버는 CNAME으로 csp123.cdn.kt.net을 돌려주고 (5번, 6번) 2. Local DNS 서버는 Request Router 로 DNS Query를 전달하여 Host Name = csp123.cdn.kt.net에 대한 IP 주소를 요청 (7번) 3. DNS-based Request Router는 1) Local DNS서버의 IP 주소와 2) 캐 시 서버의 부하 등을 고려하여, 글 로벌 네트워크 상의 적절한 캐시 서버 IP주소를 return (8번, 9번) 4. 사용자는 이 캐시 서버로 콘텐츠 Request를 보내 콘텐츠 다운로드/ 스트리밍 (11번, 12번) <br>- 35 - Global Server Load Balancing • GSLB (Global Server Load Balancing) 서비스 1. GSLB 서비스는 동일한 기능을 수행할 수 있는 여러 대의 클라우드 서버 (예. 캐시 서버) 중 최적 상태의 서버와 연결함으로써 고객 시스템의 안정성을 향상시키며, 부하를 분산시켜 일 부 서버에 트래픽이 집중되는 것을 막기 때문에 서버의 가용성 (Availability)을 높일 수 있음. GSLB 서비스는 서버의 상태 확인 후 정상적인 서버에만 연결하므로 보다 신속한 트래픽 처리 및 장애 대응이 가능함. 2. GSLB는 SLB (Server Load Balancing)에서 발전된 개념으로, SLB가 한 사이트 내에서 L4 스위칭 기 능을 통해 서버의 상태 체크 및 부하 분산 기능을 제공하였다면, GSLB는 이 개념을 지리적으로 확 장시켜 복수개의 사이트에 대해 동일한 기능을 수행하도록 함. <br>- 36 - GSLB Basic Operation • GSLB의 서비스 로직 (앞 Page 그림 참조) 1. 사용자가 <a href="http://www.example.com에" target="_blank" class="ke-link">http://www.example.com에</a> 접속하기 위해 Local DNS로 Query를 보내고, Root DNS, .com DNS 서버를 거쳐 2. GSLB로 <a href="http://www.example.com에" target="_blank" class="ke-link">http://www.example.com에</a> 대한 DNS Query를 보냄. 3. GSLB는 DNS Proxy로 동작하며, 따라서 이 DNS Query를 그대로 example.com DNS 서버로 전달함. 4. example.com DNS 서버는 <a href="http://www.example.com에" target="_blank" class="ke-link">http://www.example.com에</a> 대한 IP주소 (SLB의 virtual IP) 1.1.1.1과 2.2.2.2가 미리 등록되어 있어 그 값을 GSLB로 전달함. (TTL=300초로 가정) 5. GSLB는 서버/사이트 정책 (GSLB Policy)를 통해 1.1.1.1과 2.2.2.2 중에 사용자를 위한 최적의 사이 트를 결정함. 6. GSLB 정책을 통해 결정된 웹 서버 IP 1.1.1.1이 Local DNS로 전달되고, 7. Local DNS는 사용자 (단말)에게 IP 주소를 전달하게 됨. 8. 사용자는 <a href="http://www.example.com의" target="_blank" class="ke-link">http://www.example.com의</a> IP 주소 1.1.1.1을 destination으로 하여 한국 사이트 SLB1으로 HTTP GET을 보내고, SLB1은 다시 정책 (서버 Health/Load 등 고려)을 적용하여 최종 서버인 10.1.1.10으로 HTTP GET 메시지를 전달하게 됨. <br>- 37 - GSLB Policy • GSLB 정책 (GSLB의 서버 선택 기준) 1. Server Health check: 살아 있는 서버/사이트 선택 2. SLB Session & Network capacity threshold: 과부하 상태가 아닌 사이트 선택 3. Network Proximity: 응답 속도가 빠른 (Low Latency) 사이트 선택 4. Geographic Proximity: 지리적으로 가까운 사이트 선택 5. SLB Connection Load: 새로운 연결 요청이 적은 사이트 선택 6. Site Preference: 운영자의 정책에 의해 특정 사이트 선택 7. Least Selected: 선택이 덜 된 사이트 선택 8. Static Load Balancing: 균등하게 사이트 선택 (Round Robin or Weighted Round Robin) • 사이트/서버 선택 과정은 1번 단계를 시작으 로 8번 단계까지 순차적으로 진행되며, 만약 1번 단계에서 사이트/서버가 선택이 되면 2 번 단계로 넘어가지 않고 종료되며 1번에서 결정이 나지 않으면 2번으로 넘어가는 방식 임. 또한 운영자는 설정을 통해 각 단계를 enable/disable할 수 있으며 1~8번 순서 변 경도 가능함. <br>- 38 - GSLB Policy • GSLB 정책 (GSLB의 서버 선택 기준) 1. Server Health Check: SLB가 서버들로 ICMP(Internet Control Message Protocol), UDP, TCP, HTTP health check 메시지를 보내고 그 응답 여부를 통해 서버 혹은 서버의 Application이 살아 있음을 주기적으로 모니터링 하여 서비스가 가능한 서버를 선택하게 함. 2. Session & Network usage threshold: Server Health Check 결과 한국과 미국 서버가 모두 살아 있는 경우 1) 서버의 현재 session 수와 2) Network usage 값을 참조하여 과부하 (Over-loaded)상 태가 아닌 서버를 선택하게 함. 여기서 Session 수란 서버에서 유지하고 있는 TCP 혹은 UDP 연결 수를 의미하고, Network usage란 현재 SLB를 통해 송수신되는 트래픽 대역폭 (bps)을 의미함. 3. Network Proximity: 한국과 미국 서버의 Session/Network usage가 임계치를 넘지 않은 경우, Network proximity를 기반으로 서버를 선택하게 됨. 여기서 Network Proximity란 네트워크 관점에 서 (지리적 관점 아님) 사용자와 가까운 서버를 선택해 주는 것으로 여기서 “가까움＂의 의미는 Low latency를 의미함. 4. Geographic Proximity: Network Proximity 선택에서 Local DNS가 ICMP에 응답을 하지 않거나, 두 사이트의 RTT 결과가 유사한 경우, 지리적으로 사용자와 가까운 사이트를 선택하게 함. 5. SLB Connection Load: Geographic Proximity 선택에서 사이트를 선택하지 못한 경우, SLB의 Connection Load가 적은 사이트를 선택하게 함. 여기서 SLB Connection Load란 “일정 시간 동안 SLB에 생성되는 새로운 TCP or UDP 연결 수＂를 의미함. 6. Site Preference: 두 사이트의 SLB 모두 Connection Load 임계치를 넘지 않는 경우, 운영자가 설정 한 Site Preference 값 (사이트 선호도)에 의해 사이트를 선택하게 함. 운영자는 GSLB에 각 사이트 별 (SLB)별로 Preference 값을 설정하고, GSLB는 항상 그 값이 큰 사이트를 선택함. <br>- 39 - GSLB Policy • GSLB 정책 (GSLB의 서버 선택 기준) 7. Least Selected: 두 사이트 모두 동일한 Preference로 설정되어 있다면, 사이트 부하를 균등하게 하 기 위한 방법으로 선택이 덜 된 사이트 (Least Selected site)를 선택하게 함. 8. Static Load Balancing: Round Robin 혹은 Weighted Round Robin 방식으로 사이트를 선택하게 함. Round Robin의 경우 한국 – 미국 – 한국 – 미국 ... 순으로 번갈아 가며 사이트를 선택하고, Weighted Round Robin 방식의 경우 한국:미국의 weight가 2:1로 되어 있다면 한국 – 한국 – 미국 – 한국 – 한국 – 미국 ... 순으로 한국 사이트를 2배 더 선택하도록 하는 방식임. (예. 한국 사이트에 서버가 더 많음.) • GSLB + SLB 방식의 경우 8가지 Policy 모두 지원하지만, GSLB only 방식의 경우와 DNS 방식의 경우 지원 정책이 아래 표와 같음. <br>5. Acceleration technology <br>- 41 - Static Content / Dynamic Content 콘텐츠 유형별 가속 기술 동적 콘텐츠 (Dynamic content) 정적 콘텐츠 (Static Content) 캐시 가능 콘텐츠 캐시 불가능 콘텐츠엣지 서버에 캐시 할 수 있고 사용자 요청에 상관없이 결과값이 동일한 콘텐츠 (예: 이미지, 텍스트, 동영상) 엣지 서버에 캐시 하면 안되고 사용자 요청에 상관없이 결과값이 동일한 콘텐츠 (예: 건설/자동차 설계 도면) 엣지 서버에 캐시 할 수 없고 사용자 요청에 따라 결과값이 달라지는 콘텐츠 (예: 영화/항공 좌석 예매) 엣지 서버에 캐시 할 수 있으나 사용자 요청에 따라 결과값이 달라지는 콘텐츠 (예: 포털 지도) Static Content Cache TCP & Route optimization <br>- 42 - Application Delivery Network • ADN (Application Delivery Network): 캐시와 마찬가지로 사용자와 Origin Server 간에 지리적인 거 리로 인해 발생하는 ‘느린 응답속도/다운로드 타임＇을 해결하지만, 콘텐츠를 캐시 하지 않고 인터넷 미들 마일에 위치한 서버들간에 콘텐츠 트래픽을 빨리 전달할 수 있도록 하는 기술임. ADN은 콘텐츠 캐시가 불가능한 Dynamic 콘텐츠 (예. 영화/항공기 좌석 예매와 같이 개인별로 다른 콘텐츠가 전달되 는 경우)에 적용하여 응답 속도를 향상시킴. • ADN 핵심 기술 1. Route Optimization: 사용자와 Origin Server 사이의 Routing 경로를 최적화 2. TCP optimization: TCP 프로토콜 최적화 (예. Fast Start, Advanced Congestion Avoidance, Large Window Size) 3. Packet Redundancy (FEC: Forward Error Correction): 동일 패킷을 서로 다른 경로를 통해 중복 전달 하여 패킷 손실 시 재전송 없이 데이터를 복구 4. Application Optimization: Application Layer (예. HTTP) 프로토콜 최적화 (예. Web Object Prefetching, Pipelining 등) 5. Data Compression: 데이터 압축을 통해 전송량 최소화 6. Data De-duplication: 동일 byte-stream에 대해서는 중복 전송을 하지 않아 전송량 최소화 <br>- 43 - BGP Based Routing • BGP based Routing 1. 각 나라에는 하나 이상의 ISP가 존재하고 각 ISP 간에는 BGP (Border Gateway Protocol)을 통해 라 우팅 정보를 교환하여 전 세계가 연결되는 internet이 만들어짐. BGP를 통해 ISP간에 라우팅 정보 를 교환할 때, ISP를 식별할 수 있게 AS (Autonomous System) number가 함께 전달되어 Destination으로 패킷을 전달하기 위해 몇 개의 ISP (AS)를 거쳐야 하는지 알 수 있게 됨. 2. 아래 그림에서 보듯이 좌측 Origin Server에서 우측 User에게 전달되는 패킷은 BGP에 의해 생성된 경로를 따르게 되는데, 이 때 BGP 경로 선택기준은 일반적으로 AS가 짧은 경로 (ISP를 가장 적게 거치는 경로)를 따르게 됨. (AS1759 – AS12068 – AS3559 – AS6984 – AS7018) <br>- 44 - BGP Routing Problem • BGP based Routing의 문제점 1. AS 기반 패킷 라우팅의 문제점은 경로 선택 기준이 단순히 “최단경로”이기 때문에 네트워크 부하 상태에 따른 트래픽 품질 (Loss, Delay, Jitter)를 반영하지 못함. 예를 들어 앞 페이 지 그림에서 AS3559 (아시아)와 AS6984 (북미)간 링크에 트래픽이 증가하여 (네트워크 congestion 발생) Latency가 증가한다면 AS 경로가 길더라도 AS7543 (호주)를 거쳐 패킷을 전달하면 효율적이 지만, BGP 기반에서는 불가능함. 2. 즉, BGP 기반 라우팅은 실시간으로 변화하는 네트워크 상황에 대처하여 Optimal Routing Path를 제공할 수 없음. <br>- 45 - BGP Routing Problem 만약 단순 BGP Routing이 아닌 실시간으로 변화하 는 네트워크 상황에 대처하여 Optimal Routing Path를 제공할 수 있다면? 고객에게 더 빠르게 콘텐츠 전달 가능! 티맵은 두 시 방향 우회전 (왼쪽) 아이나비는 10시 방향 좌회전 (오른쪽) <br>- 46 - Route Optimization – AKAM SureRoute • BGP based Routing의 한계 극복 – AKAM SureRoute 사례 1. AKAM SureRoute는 BGP 경로 외에 “Edge Server를 경유하는 경로 2개＂를 선정하게 되는데, 이때 의 경로 선정 기준은 “빠른 응답 속도”임. 즉, Origin Server와 User 사이에 Edge 서버를 경유하는 여러 경로들에 대한 Latency를 측정하여 (각 경로를 통해 Origin Server로 특정 Object에 대한 HTTP GET 및 HTTP 200 OK 메시지 송수신) Latency가 가장 작은 경로 2개를 고르고 1) 이 중 Latency가 작은 Path 1이 Best Path가 되어 이 경로를 통해 Origin 서버와 User간에 트래픽을 전달 하고 2) Path 2는 Path 1 구간 네트워크 장애 발생 시 대체 경로로 사용할 수 있도록 함. <br>- 47 - • Best Path 선정되면 Origin Server와 User 사이에 있는 Edge Server들은 HTTP Proxy 기능을 수행하여, Web Server와 User 사이의 연결은 아래와 같이 3개의 구간으로 나누어 지게 됨. 1. 연결 1: Origin Server – Edge Server 2 (Low Latency 구간) – First Mile 2. 연결 2: Edge Server 2 – Edge Server 1 (High Latency 구간) – Middle Mile 3. 연결 3: Edge Server 1 – User (Low Latency 구간) – Last Mile • Origin Server에서 User로 향하는 트래픽 (패킷)의 IP 주소 정보도 1) 연결 1에서는 Source IP = Origin Server, Destination IP = Edge Server 2, 2) 연결 2에서는 S. IP = Edge Server 2, D. IP = Edge Server 1, 3) 연결 3에서는 S. IP = Edge Server 1, D. IP = User로 변경되며 전달됨. • 이와 같이 Edge 서버가 Origin Server와 User 사이의 HTTP/TCP 연결을 분리 (split)시킴으로 인해, Latency가 가장 큰 인터넷 미들 마일 (Edge Server 2 ~ Edge Server 1)에 대해 다음과 같은 추가 기능을 수행하여 User에게 보다 빠르게 데이터를 전달해 줌. 1. TCP Optimization: TCP Window scaling, Selective ACK (SACK), Fast Start, Advanced Congestion Avoidance Algorithm, Forward Error Correction (FEC) 2. HTTP Optimization: Web object prefetching Route Optimization – AKAM SureRoute <br>- 48 - Multi Proxy Dynamic Routing Origin (London) Shield End client Relay Edge <br>- 49 - TCP Optimization • TCP Optimization: TCP는 Delay가 큰 WAN에 최적화되어 있지 않기 때문에, TCP 전송 효 율을 최대화 (Optimization)해야 함. 1. TCP 최적화의 예 1: Packet Drop이 발생해도 TCP 전송 속도를 거의 줄이지 않는 방법 (표 준 TCP 프로토콜은 50%로 감소시킴) – Advanced Congestion Control 알고리즘 2. TCP 최적화의 예 2: TCP Window size를 수 MB까지 올려 WAN 구간의 Delay가 커도 TCP 전송 성능 (Throughput, bps로 측정)을 Line Rate (Link Speed)로 유지 3. TCP 최적화의 예 3: Forward Error Correction (FEC) – 전송 후 에러 발생 시 에러 검출 및 재전송 요 청하지 않고 정정 <br>- 50 - Slow start and congestion avoidance Traffic congestion을 방지하면서 동시에 최대 크기의 세그먼트 수로 전송하는 기술 Slow Start and Congestion Avoidance 알고리즘 한번에 보낼 수 있는 세그먼트 수 (cwnd) 시간 Slow Start 임계값 (rcv_ssthresh) 1. 한번에 보내는 전송 세그먼트 수를 1부터 시작해 2n 으로 증가시킨다. Packet Loss로 인한 Timeout 발생 (RTO, Retransmission Timeout, 보통 1초) 2. 임계값을 초과하면 1개씩 증가시킨다. Timeout Slow Start Congestion Avoidance 3. 임계값을 ½로 조정하고 다시 2n 으로 전송 세그먼트 수를 증가시킨다. Congestion Avoidance 수신 단말이 수신 가능한 최대 세그먼트 크기와 네트워크 혼잡 상황에 따른 전송 cwnd와 rcv_ssthresh를 조정해가며 최대 세그먼트를 보내도록 조정 <br>- 51 - Fast retransmit and fast recovery Fast Retransmit and Fast Recovery 알고리즘 한번에 보낼 수 있는 세그먼트 수 (cwnd) 시간 임계값 (rcv_ssthresh) Packet Loss로 인한 Timeout 발생 (RTO, Retransmission Timeout, 보통 1초) Fast Recovery Slow Start Congestion Avoidance Packet Loss 발생 시 전체 데이터 재전송이 아닌 해당 패킷만 재전송 Packet Loss 발생 직전 세그먼트 수/2 부터 전송 시작하도록 하여 전송율 향상 패킷 유실 (Packet Loss) 발생 시 신속하게 해당 패킷만 재전송하고 빠르게 최대 세그먼트 크기로 복구 Fast Retransmit 2. 유실된 패킷만 재전송한다 3. 유실 패킷을 제외한 나머지 세그먼트는 정상이므로 Slow Start 과정 없이 임계값을 ½로 조정하여 바로 Congestion Avoidance 단계로 돌입, 세그먼트 1개씩 증가시킨다. 1. 특정 세그먼트 유실 시 해당 세그먼트 이후 연속 x개 세그먼트에 대한 동일한 ACK (dupACK)를 전송하여 패킷 유실을 알린다. (RTO 1초를 계속 기다리지 않음) <br>- 52 - Application Protocol Optimization • Application Protocol Optimization: HTTP 등 각 Application protocol 최적화를 하여 응답속도를 개선 1. Connection Pooling and HTTP Keep Alive: 서버 간 일정량의 HTTP 커넥션을 유지하고 재 사용하는 기술 2. Chunking: 콘텐츠를 일정 단위 (Chunk)로 분할하여 빠르게 전송하는 기술 <br>- 53 - SSL Offload • SSL Offload: 캐시 서버가 Origin Server를 대신하여 SSL 암호화/복호화 연산을 처리하는 기술 • SSL이란 무엇이며 어떻게 동작하는가? 1. SSL (Secure Socket Layer)은 웹 서버와 브라우저 간에 암호화된 연결을 제공하는 표준 보안 기술이 며, 웹 서버와 브라우저 간에 오가는 모든 데이터가 Private하게 유지됨을 보장하는 기술 2. 암호화는 오직 송신자와 수신자만이 메시지를 이해하는 것을 보장하며, 만약 중간에서 메시지를 가 로채어 본다 하더라도 알아볼 수 없음. (임의의 문자의 나열) <br>- 54 - Other ADN technology • Data Compression: PC에서 파일을 압축하여 하드디스크 공간을 절약하듯이, WAN으로 전송되는 패킷 들을 압축하여 트래픽의 양을 줄이는 개념임. • Data Deduplication: 최초 전송한 패킷들의 Payload 내 bit stream을 일정 조각으로 잘라 token (또는 reference라고 부름) 값과 함께 저장하고 있다가 동일 bit stream이 포함된 패킷들이 수신되면 bit stream 대신 token 값 (token의 길이는 bit stream 길이보다 짧음)을 보내는 개념임. 이를 수신한 반대 편에서는 token 값을 bit stream으로 바꿔 클라이언트로 전달함. <br>- 55 - Web Application • 소프트웨어 공학적 관점에서 웹 어플리케이션 (Web Application) 또는 웹 앱은 인터넷이나 인트라넷을 통해 웹 브라우저에서 이용할 수 있는 응용소프트웨어 를 말함. • 웹 어플리케이션은 클라이언트로서 웹 브라우저를 사용하는 사람 이 많기 때문에 인기를 누리고 있으며, 수천만 대의 PC에 굳이 소프트웨어를 배포해서 설치하지 않아도 웹 어플리케이션을 유지 관리할 수 있다는 장점이 있음. • 웹 어플리케이션은 웹 메일, 온라인 전자상거래 및 경매, 위키, 인터넷 게시판, 블로그 및 MMORPG (Massively Multiplayer Online Role Playing Game) 게임 등 다양한 기능을 구현할 수 있음. • 초기의 클라이언트-서버 컴퓨팅 환경에서 각 응용 소프트웨어들은 저만의 사용 자 인터페이스를 가지고 있고 사용자 PC마다 따로 설치해야 했기 때문에, 서버 환경이 바뀌면 클라이언트 응용 프로그램도 업그레이드해야 하고 이에 따라 기 술 지원 비용은 증가하고 생산성을 떨어지게 됨. • 이와 대조적으로 웹 어플리케이션은 웹 브라우저가 지원하는 HTML같은 표준 형식의 웹 문서 조합을 동적으로 만들어 내는 것으로 일반적으로 개별 웹 페이 지는 정적 문서로 웹 브라우저로 배포되지만, 웹 문서가 연속적으로 전달되고 문서 마크업에 포함된 웹 폼을 통해 정보를 주고 받을 수 있기 때문에 사용자에 게 인터렉티브한 경험을 제공함. <br>- 56 - SSL Offload • SSL Offload: 캐시 서버가 Origin Server를 대신하여 SSL 암호화/복호화 연산을 처리하는 기술 • SSL이란 무엇이며 어떻게 동작하는가? 1. SSL (Secure Socket Layer)은 웹 서버와 브라우저 간에 암호화된 연결을 제공하는 표준 보안 기술이 며, 웹 서버와 브라우저 간에 오가는 모든 데이터가 Private하게 유지됨을 보장하는 기술 2. 암호화는 오직 송신자와 수신자만이 메시지를 이해하는 것을 보장하며, 만약 중간에서 메시지를 가 로채어 본다 하더라도 알아볼 수 없음. (임의의 문자의 나열) <br>- 57 - SSL Offload • 캐시 서버에서 암호화/복호화 과정을 거치기 때문에, 일반적인 HTTP 전송에 비해 캐시 서버 자 원 (CPU loading) 소모가 크고 performance가 낮아지게 됨. 1. HTTP와 동일한 performance를 유지하기 위해서는 투입 서버의 수가 HTTP보다 많아야 함. <br>- 58 - SSL Offload • SSL 인증서는 CA (Certificate Authority such as VeriSign, DigiCert, etc.)에 의해 발급 1. 웹 서버의 존재여부를 확인하고 2. 데이터를 암호화하고 전송 데이터의 무결성을 보장 • Certificate Authority는 SSL 인증서 신청 기간 동안 웹사이트 소유자의 상세 정보를 확인 • 일반적인 SSL 인증서는 도메인 명, 조직 명 및 주소, 인증서 만료기간, 인증서 보장에 대한 CA의 의무사 항 상세정보를 포함 • 브라우저가 안전한 웹사이트에 접속하게 되면 SSL 인증서를 가져와서 만료되지 않았는지, 신뢰할만한 CA로부터 발급 받았는지, 발급 받은 웹 사이트에서 사용중인 지 등을 확인 SSL Type Description Wildcard Wildcard SSL인증서는 도메인들이 같은 조직이나 동일한 도메인 명을 공유하는 경우 하나의 인증서로 다수의 서브도메인 에 대해 SSL암호화를 하는데 사용된다. 예를 들면, ABC라는 회사에 발급된 *.companyabc.com이 라는 Common name의 Wildcard SSL인증서는 아래와 같은 도메인들을 암호화하는데 사용될 수 있다. login.companyabc.com payment.companyabc.com support.companyabc.com Multi-Domain Certificate Multi domain 인증서 (MDC)는 하나의 인증서와 하나의 동일한 서버로 300 여개의 도메인을 보호하는데 사용 할 수 있다. 이 공유 호스팅 환경은 하나의 SSL 인증서로 복수 도메인을 암호화할 수 있다. 이 MDC는 하나의 서버로 Multiple unique 도메인을 가지는 조직에게 적합하며, 이는 높은 수준의 신뢰와 보안을 제공하면서 시 간과 금액을 절약해준다. 고객은 고객사 고유의 URL사용이 가능하다. (e.g. secure.foo.com) Private Private SSL은 고객사 자신의 SSL 인증서를 구매하고 서버 별로 dedicated 된 IP주소를 확보해야 한다. 고객은 고객사 고유의 URL사용이 가능하다. (e.g. secure.foo.com)</p>
<!-- -->
]]>
카페 게시글
우리들의 이야기
씨디엔 어쩌구 옛날 문서에서 텍스트로 복사한 건데
칡 흰
추천 0
조회 120
24.06.13 21:40
댓글 1
다음검색
첫댓글 ................
낱말의 사용이 분명하며 전개가 명확한 문장을 좋아한다.... 근데 정작 나님이 딴놈에게 하는 말은 존혀 그러하지 아니하다 ㅎ