네트워크 심화

 

 

• 학습 내용

이번 네트워크 심화 시간에는 HTTP 기반 네트워크 흐름과 TCP/IP 기반 데이터 흐름에 대해서 그리고 HTTP 기본 동작과 특징에 대해 학습한다. 그리고 HTTP 헤더의 역할과 마지막으로 캐시에 대해 학습하고자 한다.

 

• IP와 IP Packet

인터넷 망 속 수많은 노드들 속에서 클라이언트와 서버가 통신할 수 있는 이유는 IP(인터넷 프로토콜) 즉, 규약이 있기 때문이다. IP는 지정한 주(IP Address)에 패킷(Packet)이라는 통신 단위로 데이터를 전달한다. 여기서 패킷이란 pack과 bucket이 합쳐진 단어로 소포로 비유할 수 있다. IP 패킷은 데이터 통신에 적용한 것이라고 보면 된다. 그래서 IP 패킷에 우체국 송장처럼 전송 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP와 같은 정보가 포함되어 있다. 

 서버가 무사히 데이터를 전송받으면 서버도 이에 대한 응답을 해줘야 한다. 그 응답 역시 IP 패킷을 이용해 서버가 클라이언트에게 응답을 전달한다. 정확한 출발지와 목적지를 파악할 수 있다는 점에서 IP 프로토콜은 적절한 통신 방법으로 보이지만 이러한 IP 프로토콜에도 비연결성과 비신뢰성이라는 한계가 존재한다. 첫 번째 비연결성은 만약 패킷을 받을 대상이 없거나 서비스 불능 상태여도 클라이언트는 서버의 상태를 파악할 방법이 없기 때문에 패킷을 그대로 전송하게 된다. 두 번째 비신뢰성으로 중간에 있는 서버가 데이터를 전달하던 중 장애가 생겨 패킷이 중간에 소실되더라도 클라이언트는 이를 파악할 방법이 없다. 또 전달 데이터의 용량이 클 경우 이를 패킷 단위로 나눠 데이터를 전달하게 되는데 이때 패킷들은 중간에 서로 다른 노드를 통해 전달될 수 있다. 이렇게 되면 클라이언트가 의도하지 않은 순서로 서버에 패킷이 도착할 수 있다.

 

• TCP, UDP

네트워크 프로토콜 계층은 OSI 7계층과 TCP/UP 4계층으로 나눌 수 있다. IP 프로토콜보다 더 높은 계층에 TCP 프로토콜이 존재하기 때문에 앞서 다룬 IP 프로토콜의 한계를 보완할 수 있다. 물론 TCP/IP 4계층은 OSI 7계층보다 먼저 개발되었으며 TCP/IP 프로토콜의 계층은 OSI 모델의 계층과 정확하게 일치하지는 않는다. 예를 들어 채팅 프로그램에 메시지를 보내면 먼저 HTTP 메시지가 생성되면서 Socket 라이브러리를 통해 전달된다. 프로그램이 네트워크에서 데이터를 송수신할 수 있도록 네트워크 환경에 연결할 수 있게 만들어진 연결부가 바로 네트워크 소켓이다. 그 후 TCP 정보를 생성하면서 메시지 데이터를 포함한다. IP 패킷을 생성하고 TCP 데이터를 포함한 후 서버로 그것을 전달한다.

 TCP/UP 패킷에 대해 자세히 살펴보면 TCP 세그먼트에는 IP 패킷의 출발지 IP와 목적지 IP 정보를 보완할 수 있는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등을 포함한다. TCP는 장치들 사이에 논리적인 접속을 성립하기 위하여 3 way handshake를 사용하는 연결 지향형 프로토콜이다. 연결 방식은 먼저 클라이언트가 서버에 접속을 요청하는 SYN 패킷을 보낸다. 서버는 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 ACKDHK SYN가 설정된 패킷을 발송하고 클라이언트가 다시 ACK로 응답하기를 기다린다. TCP는 데이터 전송이 성공적으로 이루어지면 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있다. 그리고 만약 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청할 수 있다. 이를 통해 IP 패킷의 한계인 비신뢰성(순서를 보장하지 않음)을 보완할 수 있다.

 UDP는 IP 프로토콜에 PORT, 체크섬 필드 정보만 추가된 단순한 프로토콜이다. 앞서 TCP 특징과 비교해 보면 신뢰성은 낮지만 3 way handshake 방식을 사용하지 않기 때문에 TCP와 비교해 빠른 속도를 보장한다. HTTP3는 UDP를 사용하며 이미 여러 기능이 구현된 TCP보다는 하얀 도화지처럼 커스터마이징이 가능하다는 장점이 있다. 아직 TCP와 UDP의 차이가 잘 와닿지 않는다면 좋은 기능이 다 들어있는 무거운 라이브러리와 필요한 기능만 들어있는 가벼운 라이브러리로 비교할 수 있다. 체크섬(checksum)은 중복 검사의 한 형태로 오류 정정을 통해 공간(전자 통신)이나 시간(기억 장치) 속에서 송신된 자료의 무결성을 보호하는 단순한 방법이다.

 

• HTTP

1) HTTP 역사

HTTP/1.1, HTTP/2는 TCP 기반이고 HTTP/3는 UDP 기반 프로토콜이다.

 

• HTTP 특징

HTTP는 클라이언트 서버 구조와 무상태 프로토콜(Stateless), 비연결성(Connectionless)과 HTTP 메시지, 단순함, 확장 가능이라는 특징을 가지고 있다.

 클라이언트 서버 구조의 경우 Request, Response 구조로 클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 클라이언트 서버 구조로 이루어져 있다. 즉, 서버가 요청에 대한 결과를 만들어 응답하는 것이다. 무상태 프로토콜의 경우 서버가 클라이언트의 상태를 보존하지 않는다는 특징이다.

 무상태성은 상태 유지와 대치되는데, 상태 유지의 경우 클라이언트의 상태를 계속 기억하는 것을 말한다. 이 상태 유지는 항상 같은 서버가 유지되기 때문에 예를 들어 클라이언트 A의 요청을 서버 1이 기억하고 있기 때문에 항상 서버 1이 응답해야 한다. 그래서 만약 서버 1에 장애가 생기면 유지되던 상태 정보가 다 날아가 처음부터 다시 서버에 요청해야 한다. 그러나 무상태성의 경우는 이와 달리 상태를 기억하지 않는다. 그래서 갑자기 클라이언트가 증가해도 어느 서버가 대응해도 상관이 없기 때문에 서버를 대거 투입할 수 있다. 그래서 무상태는 응답 서버를 쉽게 바꿀 수 있어 무한한 서버 증설이 가능하다. 그리고 서버에 장애가 생긴다고 해도 다른 서버에서 응답을 전달하면 되기 때문에 클라이언트는 다시 요청할 필요가 없다. 그러나 무상태성에도 한계가 있는데, 무상태로 설계할 수 있는 경우가 있지만 그렇지 않은 경우도 있다는 것이다. 로그인이 필요 없는 단순한 서비스 소개 화면 같은 경우에는 무상태로 설계할 수 있지만 로그인이 필요한 서비스라면 유저 상태를 유지해야 한다. 그래서 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지해야 한다.

 비연결성의 경우 또 연결을 유지하는 모델과 대치된다. TCP/IP의 경우 기본적으로 연결을 유지한다. 연결을 유지하는 모델에서는 클라이언트 1, 2는 요청을 보내지 않더라도 계속 연결을 유지해야 한다. 그러나 이러한 경우 연결을 유지하는 서버의 자원이 계속 소모가 된다. 그러나 비연결성을 가지는 HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는다. 그래서 최소한의 자원으로 서버 유지를 가능하게 한다.

 HTTP 1.0 기준으로 HTTP는 연결을 유지하지 않는 모델이다. 트래픽이 많지 않고 빠른 응답을 제공할 수 있는 경우에는 비연결성의 특징은 효율적으로 작동한다. 그러나 트래픽이 많고 큰 규모의 서비스를 운영할 때에는 비연결성의 한계가 드러난다. 예를 들어 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운되기 때문에 해당 자원들을 각각 보낼 때마다 연결 끊고 다시 연결하고를 반복하는 것은 비효율적이다. 그래서 지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결한다.

 

• 표준 헤더(Representation Headers)

HTTP 메시지는 헤더와 바디로 구분할 수 있다. HTTP 바디에서는 데이터 메시지 본문을 통해서 표현 데이터를 전달한다. 여기서 데이터를 실어 나르는 부분을 페이로드(Payload)라고 한다. 표현은 요청이나 응답에서 전달할 실제 데이터를 뜻하며 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다. 그 정보에 데이터 유형(html, json), 데이터 길이, 압축 정보 등을 포함한다.

 HTTP 헤더는 <field-name> : <field-value> 형식을 유지한다(field -name은 대소문자 구분 없음). 또 HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용한다. HTTP 전송에 필요한 모든 부가정보에는 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등이 있다.

 표현 데이터의 형식을 설명하는 헤더는 Content-Type, 압축 방식은 Content-Encoding, 자연 언어는 Content-Language, 길이는 Content-Length로 표현한다. 이 표현 헤더는 요청, 응답 둘 다 사용한다. 표현 데이터의 형식 설명에 미디어 타입, 문자 인코딩이 있고 그 예는 이렇다. Text/html; charset=utf-8, application/json, Image/png.  표현 데이터 인코딩은 표현 데이터를 압축하기 위해 사용하고 데이터를 전달하는 곳에서 압축 후 인코딩 헤더를 추가한다. 그리고 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제한다. gzip, defte, identity가 있다. 표현 데이터의 자연 언어를 표현하는 것에 ko, en, en-US가 있다. 표현 데이터의 길이에는 바이트 단위를 사용한다. Transfer-Encoding은 전송 시 어떤 인코딩 방법을 사용할 것인가를 명시한다. 그러나 현재는 Transfer-Encoding보다는 content-Encoding을 사용하며, Transfer-Encoding을 사용하는 경우 chunked의 방식으로 사용한다. chunked 방식의 인코딩은 많은 양의 데이터를 분할하여 보내기 때문에 전체 데이터의 크기를 알 수 없다. 그래서 표현 데이터의 길이를 명시해야 하는 Content-Length 헤더와 함께 사용할 수 없다.

 

• HTTP 주요 헤더

1) 요청(Request)에서 사용하는 헤더

From: 유저 에이전트의 이메일 정보	일반적으로 잘 사용하지 않지만 검색 엔진에서 주로 사용한다.
Referer: 이전 웹 페이지 주소	현재 요청된 페이지의 이전 웹 페이지 주소를 보여준다. A->B로 이동하는 경우에 B를 요청할 때 Referer:A를 포함해서 요청한다. Referer를 사용하면 유입경로 수집이 가능하다. 재밌는 것은 referer는 단어 referrer의 오탈자지만 스펙으로 굳어졌다.
User-Agent: 유저 에이전트 애플리케이션 정보	클라이언트의 앱 정보(웹 브라우저 정보 등등)을 볻여준다. 통계 정보 역시 포함하며 어떤 종류의 브라우저에서 장애가 발생하는지 파악할 때 사용한다.  예) user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebkit/ 537.36(KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36
Host: 요청한 호스트 정보(도메인)	필수 헤더이며 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용한다. 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용한다. Host 정보가 없다면 IP 주소만을 가지고 어떤 도메인으로 요청이 왔는지 확인하기 어렵다. 그래서 가상호스트를 통해 여러 도메인을 한번에 처리하고 있는 경우 Host를 통해 요청한 도메인을 찾을 수 있다.
Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄	여기서 요청을 보낸 주소와 받은 주소가 다르면 CORS 에러가 발생한다. 응답 헤더의 ACCESS-Control-Allow-Origin와 관련이 있다.
Authorization: 인증 토큰(ex) JWT를 서버로 보낼 때 사용하는 헤더	'토큰의 종류 + 실제 토큰 문자'를 전송한다. ex) Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1I

2) 응답(Response)에서 사용되는 헤더

Server	요청을 처리하는 ORIGIN 서버의 소프트웨어 정보 ex) Server: Apache/2.2.22(Debian), Server: nginx
Date	메시지가 발생한 날짜와 시간 ex) Date: Tue, 15 Nov 1994 08:12:31 GMT
Location	페이지 리디렉션 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 리다이렉트(자동 이동)한다. -201(Created): Location 값은 요청에 의해 생성된 리소스 URI -3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대산 리소스를 가리킴.
Allow	허용 가능한 HTTP 메소드 405(Method Now Allowed)에서 응답에 포함한다. ex) Allow:GET, HEAD, PUT
Retry-After	유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간 -503(Service Unavilable): 서비스가 언제까지 불능인지 알려줄 수 있음 ex) Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기), Retry-After: 120(초 단위 표기)

 

• 콘텐츠 협상 헤더

콘텐츠 협상에서 사용 헤더는 다음과 같다. 협상 헤더는 요청 시에만 사용한다.

Accept	클라이언트가 선호하는 미디어 타입 전달
Accept-Charset	클라이언트가 선호하는 문자 인코딩
Accept-Encoding	클라이언트가 선호하는 자연 언어
Accept-Language	클라이언트가 선호하는 자연 언어

한국어 브라우저에서 특정 웹사이트에 접속했을 때 콘텐츠 협상(Accept-Language)이 적용되지 않았다면 서버는 요청으로 받은 우선순위가 없으므로 기본 언어로 설정된 영어로 응답한다. 클라이언트에서 Accept-Language로 KO를 작성해 용청한다면 서버에서는 해당 우선순위 언어를 지원할 수 있기 때문에 한국어로 된 응답을 돌려준다. 그런데 만약 클라이언트는 한국어를 선호하기에 Accept-Language에 한국어를 요청했지만 서버는 한국어를 한국어를 지원하지 않으며 기본 언어는 독일어로 설정되어 있다고 한다면 클라이언트는 독일어가 어렵기 때문에 한국어가 안되면 영어로라도 응답받기를 원할 것이다. 이것을 해결하기 위해 협상 헤더에서는 원하는 콘텐츠에 대한 우선순위를 지정할 수 있다. Accept-Language: ko-KR(;q=1 생략), ko;q=0.9,en-US;q=0.8,en=0.7 이렇게 하면 1부터 0까지 우선순위를 부여할 수 있고 이를 토대로 서버는 응답을 지원한다. 이렇게 1순위로 영어를 지정하면 영어를 독일어보다 클라이언트가 선호하기 때문에 영어로 응답을 돌려준다.

 

• 캐시 검증 헤더와 조건부 요청

앞에서 유효시간이 초과하면 다시 요청을 보내 새로운 데이터로 캐시를 업데이트했다. 그러나 만약 유효시간이 지났음에도 변경 사항이 없어 해당 데이터를 써도 되는 상황이라면 어떻게 될까? 이 경우 검증 헤더 Last Modified를 이용해 캐시의 수정시간을 알 수 있다. Last Modified는 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함한다. 이로 인해 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장된다. 이 과정으로 먼저 데이터가 수정되었는지 검증한다. 그리고 수정되지 않았다면 바디를 제외한 HTTP 헤더만 전송한다. 그 후 브라우저 캐시에서 응답 결과를 재사용하고 헤더 메타데이터 또한 갱신한다. 마지막으로 브라우저는 캐시에서 조회한 데이터를 렌더링 한다.

 서버의 해당 자료의 최종 수정일과 비교해서 데이터 수정이 안되었을 경우 응답 메시지에 이를 담아서 알려주는데, 이때 HTTP body는 응답 데이터에 없으며 상태 코드는 304 Not Modified로 변경된 것이 없다는 뜻이다. 그래서 전송 데이터에 바디가 빠졌기 때문에 헤더만 포함된 0.1M만 전송된다.

 그러나 Last-Modified와 If-Modified-Since에 단점들이 있는데, 1초 미만 단위로 캐시 조정이 불가능하고 날짜 기반의 로직만 사용한다. 그리고 데이터를 수정해서 날짜가 다르지만 같은 데이터를 수정해서 데이터 결과가 똑같은 경우에도 문제를 일으킨다. 서버에서 별도의 캐시 로직을 관리하고 싶은 경우에도 불리하다. 그래서 좀 더 간단한 방식으로 ETag(Entity Tag)와 If-None-Match 검증 헤더가 있다. 서버에서 완전히 캐시를 컨트롤하고 싶은 경우 ETag를 사용하면 된다. ETag는 캐시용 데이터에 임의의 고유한 버전 이름을 달고 데이터가 변경되면 이 이름을 바꾸어 변경해서 Hash를 다시 생성한다. 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받는 방식을 취한다.

 ETag 작동방식은 서버에서 헤더에 ETag를 작성해 응답한다. 그러면 클라이언트의 캐시에서 해당 ETag 값을 저장할 것이다. 여기서 만약 캐시 시간이 초과돼서 다시 요청을 해야 하는 경우면 ETag 값을 검증하는 If-None-Match를 요청 헤더에 작성해서 보낸다. 서버에서 데이터가 변경되지 않았을 경우 ETag는 동일하기에 If-None-Match는 거짓이 된다. 이 경우 서버에서 304 Not Modified를 응답하며 이때 HTTP Body는 없다. 브라우저 캐시에서 응답 결과를 재사용하더라도 헤더 데이터를 갱신한다.

캐시와 관련된 헤더들과 조건부 요청 헤더

Cache-Control: max-age	캐시 유효 시간. 초 단위
Cache-Control: no-cache	데이터는 캐시해도 되지만, 항상 원(Origin) 서버에 검증하고 사용
Cache-Control: no-store	데이터에 민감한 정보가 있으므로 저장하면 안되는 경우 사용(메모리에서 사용하고 최대한 빨리 삭제)
Expires: Mon, 01 Jan 1990 00:00:00 GMT	캐시 만료일을 정확한 날짜로 지정한다. 주의할 점은 HTTP 1.0부터 사용이 가능하다. 그리고 지금은 더 유연한 Cache-Control: max-age를 사용하는 것이 좋다. 만약 Cache-Control: max-age와 함께 사용하면 Expires는 무시된다.
검증 헤더 (Validator)	ETag의 경우 "v1.0", "845eed07c5887cf" 이렇게 사용하고, Last-Modified는 Wed, 26 Dec 2020 12:01:29 GMT 이렇게 사용한다.
조건부 요청 헤더	If-Match, If-None-Match는 ETag 값을 사용하고 If-Modified-Since, If Unmodified-Since는 Last-Modified 값을 사용한다.

 

• 프록시 캐시(Proxy Cache)

프록시란 클라이언트와 서버 사이에 대리로 통신을 수행하는 것을 말한다. 즉 클라이언트가 다른 네트워크 서비스에 간접적으로 접속할 수 있게 하는 컴퓨터 시스템이나 응용 프로그램을 의미한다. 그리고 그 중계 기능을 하는 서버를 프록시 서버라고 한다. 클라이언트 혹은 반대로는 서버가 다른 네트워크에 간접적으로 접속할 수 있기 때문에 보안 캐싱을 통한 선능, 트래픽 분산 등의 장점을 가진다. 여기서 클라이언트에서 사용하고 저장하는 캐시 private 캐시라고 하고 프록시 캐시 서버의 캐시를 public 캐시라고 한다.

프록시 캐시와 관련된 헤더

Cache-Control: public	응답이 public 캐시에 저장되어도 됨
Cache-Control: private	응답이 해당 사용자만을 위한 것, private 캐시에 저장해야 함(기본값)
Cache-Control: s-maxage	프록시 캐시에만 적용되는 max-age
Age: 60 (HTTP 헤더)	오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초 단위)

만약 웹 브라우저가 임의로 캐싱을 하려고 할 때 이를 무효화해야 할 필요가 있다. 왜냐하면 노출되면 안 되는 개인 정보가 포함될 수 있기 때문이다.

캐시를 무효화할 수 있는 헤더

Cache-Control: no-cache	데이터는 캐시해도 되지만 항상 원 서버에 검증하고 사용
Cache-Control: no-store	데이터에 민감한 정보가 있으므로 정하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)
Cache-Control: must-revalidate	캐시 만료 후 최초 조회 시 원 서버에 검증함. 원 서버 접근 실패 시 반드시 오류가 발생해야함 - 504(Gateway Timeout). must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
Pragma: no-cache	HTTP 1.0 하위 호환

확실한 캐시 무효화 응답을 하고 싶다면 위에 있는 캐시 지시어를 모두 넣어야 한다.

 no-cache와 must-revalidate 모두 원 서버에 검증해야 하지만 그에 대한 응답에 대해 다른 점이 있다. no-cache의 경우 캐시 서버 요청을 하면 프록시 캐시 서버에 도착하면 no-cache인 경우 원 서버에 요청을 한다. 그리고 원 서버에서 검증 후 304 응답을 하게 된다. 만약 프록시 캐시 서버와 원 서버 간 네트워크 연결이 단절되어 접근이 불가능하다면 no-cache에서는 응답으로 오류가 아닌 오래된 데이터라도 보여주자는 개념으로 200ok으로 응답을 한다.

 하지만 must-revalidate라면 원 서버에 접근이 불가할 때 504 Gateway Timeout 오류를 보낸다. 통장 잔고 등 중요한 정보가 원 서버를 못 받았다고 해서 예전 데이터로 뜬다면 큰 문제가 생기기 때문에 이런 경우 must-revalidate를 써야 한다.

 

• CDN

CDN(Content Delvery Network)은 콘텐츠를 좀 더 빠르고 효율적으로 제공하기 위해 등장했다. 세계 곳곳에 분포하는 데이터 센터에 콘텐츠를 저장해 둔다. 그리고 그 후 콘텐츠 요청을 받으면 지리적으로 가장 가까운 데이터 센터에서 콘텐츠를 제공해 주는 방식이다. 그 특징으로 원본을 복사하여 저장할 여러 개의 캐시 서버로 구성하고 있고 콘텐츠를 요청받은 경우 데이터를 전달하기 가장 유리한 캐시 서버에서 관련 콘텐츠를 제공한다. 제공할 콘텐츠를 가지고 있으며 위치상으로 가장 가까운 캐시 서버가 우선순위를 가진다.

 CDN이 다룰 수 있는 종류는 정적 콘텐츠와 동적 콘텐츠로 구분할 수 있다. 정적 콘텐츠란 내용이 거의 변하지 않는 콘텐츠인데 HTML 파일, 동영상과 같은 콘텐츠나 변화가 없는 콘텐츠, 개인화가 되지 않은 대중적인 콘텐츠가 여기에 해당한다. 이런 정적 콘텐츠는 CDN의 캐시 센터에 저장하는 것이 적합하다. 반대로 동적 콘텐츠의 경우 위치, IP주소 등 접근할 때마다 내용이 달라지는 콘텐츠이다. 위치, IP주소, 사용시간 관련 콘텐츠나 사용자가 접근할 때마다 내용이 달라지는 콘텐츠, 카드 번호, 전화번호 등 개인화된 정보 관련 콘텐츠가 여기에 해당된다. CDN에 저장되어 있는 콘텐츠들은 내용이 바뀔 때마다 CDN 서버들에도 변경 내용이 전파되어야 한다. 그렇기 때문에 내용이 자주 바뀌는 동적 콘텐츠 자체는 CDN 네트워크가 지원하기 어렵다. 그래서 공통적인 부분을 캐시 서버에 저장한다.

 CDN의 장점으로 DDoS 공격에 대해 어느 정도 대응이 가능하고, 로딩 속도 감소로 인한 사용자 경험 향상과 트래픽 분산으로 인한 트래픽 관련 비용이 절감되는 장점들이 있다. DDoS 공격의 경우 서버의 수용량보다 훨씬 많은 요청을 보내 서버를 사용 불가능하게 만든다. CDN의 데이텀 센터 중 하나가 이런 이유로 사용이 불가능 해졌다고 해도 여전히 다른 데이터 센터는 동작하기 때문에 다른 데이터 센터에서 콘텐츠를 제공받으면 그만이다. 또한 데이터 센터들은 거대한 컴퓨팅 능력을 가지기 때문에 DDoS 공격으로 서비스 장애가 발생하기 어렵다. 둘째로 사용자 경험의 경우 데이터 처리 속도가 빠르기 때문에 훨씬 향상될 수 있다. 마지막으로 한 곳에서 동시에 처리하는 것에 비해 서버들이 세계 곳곳에 분산되어 있기 때문에 지역에 맞게 서버의 성능과 인터넷의 선능을 낮춘다 해도 무리 없이 서비스를 제공할 수 있다. 또 외국에 있는 사용자들의 로딩 시간을 단축시킬 수 있다. 그래서 비용 절감의 효과까지도 볼 수 있다.

 CDN이 서버를 분산하는 방식은 크게 Scattered 방식과 Consolidated 방식을 사용한다. 하지만 한 가지 방식만 사용하는 것은 아니고 필요에 따라 둘 중 하나를 선택해서 사용한다. Scattered 방식은 최대한 빠른 응답속도를 목표로 하고 있다. 따라서 세계 곳곳에 비교적 낮은 성능의 데이터 센터를 구성하고 연결해 두어야 한다. 해당 방식은 관리해야 하는 데이터 센터의 수가 많기 때문에 데이터 센터 유지 비용 또한 높다. 따라서 클라우드 제공자는 관리 비용을 사용자에게 전가한다. Consolidated 방식은 기존의 Scattered 방식과 다르게 데이터 센터들을 통합하여 운용하는 방식이다. 따라서 Scattered 방식에서 사용했던 낮은 성능 대신 고성능의 데이터 센터들을 운영해야 한다. 비록 응답 시간이 증가하지만 데이터 센터의 수가 줄어듦으로 데이터 센터의 관리 및 유지 비용을 절감할 수 있다. 이 말은 사용자들에게 전가되는 요금이 줄어든다는 의미이다.

 초기에는 응답 속도에 중점을 주어서 Scattered 방식, 정적 콘텐츠 CDN이 주류였다. 그래서 사용자에게 전가되는 비용이 매우 높았다. 하지만 점차 동적 콘텐츠를 지원하고 데이터 센터를 통합하기 시작했고 이로 인해 사용자에게 전가되는 비용은 줄어들고 있다. 또한 DDoS 공격 등 사이버 공격에 대응하고 어느 상황에서도 콘텐츠를 제공할 수 있도록 보안과 안정성에 집중하고 있다.