DNS 정보 캐싱
DNS의 정보에는 TTL(Time to live)값이 세팅되어있으며, 이 기간동안에는 DNS 캐싱정보가 유효함을 나타냅니다.
하지만 DNS정보는 수시로 바뀌지 않으므로 TTL값이 넘었다해도 해당 정보를 response로 제공해주는 것이 보통입니다.
만약 정보가 변경되었더라도 변경이 발생한 DNS 서버가 있는 지역을 중심으로 변경된 데이터를 갱신해나가기 때문에 지역적으로 멀리 떨어진 DNS서버는 반영이 느릴 수 있습니다.
DNS records
DNS의 정보는 Resource Record라는 틀에 맞게 저장되어있습니다.
name, value, type, ttl이란 필드가 존재하며, type에 따라 name과 value에 해당하는 값의 성격이 조금씩 달라집니다.
가장 이해하기 쉬운 A 타입은 말그대로 hostname과 ip주소를 보관하고 있으며, NS 타입은 도메인(.com, .org 등)과 해당 도메인의 주소를 보관하고 있습니다.
ip주소는 alias(별칭)이 아닌 canonical name과만 매칭되어있으므로, alias와 canonical name을 매칭시켜주는 CNAME 타입이 존재하며, 메일 서버를 위한 MX 타입이 존재합니다.
DNS protocol message
DNS 프로토콜을 사용할때 보내는 request(query)와 받는 response(reply)의 틀은 동일합니다.
identification은 요청들을 구분하기 위한 필드이며, flag에는 query인지 reply인지 구분하는 비트, recursion 요청을 허용할 것인지를 나타내는 비트, reply가 유효한지 (ttl 값이 현시각보다 낮은지) 등의 다양한 플래그 비트가 포함되어있습니다.
그 외의 필드들에는 요청한 질문, 질문에 대한 답 등의 정보가 실려있습니다.
DNS 등록
새롭게 DNS 정보를 등록하려면 인증된 기관에 대신 요청해야 합니다.
만약 개개인이 DNS 정보 등록을 가능하게 한다면 지나치게 혼잡할 뿐더러 보안상의 문제가 있을 수 있으므로 공인된 기관을 통해서만 등록할 수 있습니다.
만약 .com 도메인으로 등록하고 싶다면 .com 도메인에 DNS 등록을 요청해야 하는 것이죠.
DNS 보안
DNS 서버에 대한 공격은 이미 몇차례 있어왔고, DNS 보안 허점을 악용하는 사례도 늘고 있습니다.
DDoS 공격
DDoS 공격은 bot을 생성해(일반 사용자의 컴퓨터를 좀비 pc로 만들기) 해당 bot들로 일제히 수많은 양의 쿼리를 보내 서버를 다운시키는 공격을 말합니다.
root name server에도 DDoS 공격이 이루어졌으나, DDoS 공격임을 판별하는 로직을 통해 큰 피해 없이 막을 수 있었습니다.
DNS 스푸핑
DNS는 쿼리를 날리고 응답을 받는게 핵심인 서비스입니다.
DNS 스푸핑은 DNS 캐시를 업데이트할때 어떠한 인증, 암호화도 사용하지 않는다는 허점을 악용하여 캐시를 오염시킴으로써 응답을 바꿔치기하는 방법입니다.
DNSSEC
위와 같은 상황을 막기 위해 등장한 것이 DNSSEC이라는 보안 프로토콜입니다.
하지만 인증과 보안이 적용되면 필연적으로 응답속도가 저하되고, 유저들은 이를 원하지 않기 때문에 현재 DNSSEC은 널리 사용되고 있지 못합니다.
비디오 스트리밍과 CDN
CDN은 유튜브 넷플같은 비디오 스트리밍을 운영하는 핵심기술입니다.
조사에 따르면 인터넷 대역폭을 가장 많이 쓰고 있는 서비스가 비디오 스트리밍임이 밝혀졌습니다. (전체 트래픽의 80%)
비디오 스트리밍 회사들은 서비스를 제공하기 위해 다음과 같은 사항들을 고려해야합니다.
- 사용자가 사용하는 기기가 각기 다른 문제
- 사용자의 네트워크 대역폭이 수시로 변하는 문제 (이동중에 시청 등)
이러한 사항들을 해결하고자 등장한 것이 분산된 어플리케이션 레벨의 인프라스트럭쳐인 CDN입니다.
Multimedia: video
영상을 보여주는 것은 여러장의 사진을 빠르게 연달아 보여주는 것과 같습니다.
일반적으로 초당 24개 이상의 사진을 보여주면 사람은 사진의 연속이 아닌 하나의 영상으로 인식합니다.
결국 서비스의 입장에서는 초당 24개 이상의 사진을 수신해서 이를 보여줘야 하는 것인데, 이를 최적화하기 위해 redundancy를 이용한 코딩 기법이 활용됩니다.
일반적으로 영상속 n번째 사진과 n+1번째 사진은 아주 큰 차이가 있다기보단, 대부분 약간의 변화만 존재합니다. 이런 픽셀의 diff 값만을 저장하여 수신하는 정보의 양을 줄여 서비스를 할 수 있습니다.
Streaming stored video
 |
 |
|---|---|
| 네트워크 딜레이가 일정한 이상적 시나리오 | 네트워크 딜레이가 달라지는 현실적 시나리오 |
스트리밍되는 비디오는 이미 어딘가에 저장되어 있는 데이터입니다. (실시간으로 데이터를 생성해서 주지 않음)
서버가 비디오 제공할때 고려할 점으로는
- 시시각각으로 대역폭이 변화할 수 있음
- 패킷로스로 인한 딜레이 관리
등이 존재합니다.
버퍼링
플레이어가 플레이 시작한 시점에도 서버는 여전히 데이터를 보내고 있습니다.
이상적인 시나리오와 다르게 네트워크 딜레이는 시시각각으로 변하므로, 기대한 양의 데이터가 기대한 시점에 도착하지 않을 수 있습니다.
이때마다 영상이 끊긴다면 UX적으로 좋지 않으니 “이미 받아온” 데이터를 통해 영상을 보여주며 다음 데이터를 받아올 시간을 법니다.
이때 비축해둔 데이터(버퍼)가 없다면 데이터를 일정시간 동안 받아와 비축해두는 시간이 발생하며, 이 시간을 버퍼링이라 부릅니다.
Buffer는 간단하지만 필수적인 기술적 요소이며, 비디오 스트리밍 서비스를 제공하는 모든 회사에서 사용중입니다.
DASH protocol
DASH는 Dynamic Adaptive Streaming over HTTP의 약자이며, 스트리밍 서비스가 채택하는 핵심 서비스입니다.
스트리밍은 보통 브라우저로부터 시작하므로 HTTP 위에서 동작합니다.
DASH 프로토콜에서 서버와 클라이언트는 각각 아래와 같은 동작을 합니다.
서버
- 비디오 파일을 여러개의 조각으로 나누어 놓음 (단위:
chunk) - 각각의
chunk를 서로 다른 비율(화질)로 인코딩 - 각각의
chunk들을 여러 CDN에 저장 (사용자의 지리적 위치, 대역폭을 봤을때 최적인 CDN에서 파일을 제공하는 형식) manifest file(chunk들의 설명서)을 만들어 놓음 (어디에 저장돼있는지, chunk가 몇분 단위로 나누어져 있는지 등)
클라이언트
- 주기적으로 서버와 클라이언트 사이의 대역폭을 측정 (response time을 가지고 판단합니다)
manifest file을 참조해chunk를 하나씩 요청 (대역폭을 참고해서 최선의 화질로 가장 가까운 곳에서 가져옴)
본 글에 사용된 자료는 https://gaia.cs.umass.edu/kurose_ross/ppt.php에서 무료로 제공하고 있습니다.
