데통 공부 v.04 (DNS, P2P)

DNS

• = URL
• IP주소를 통해 접근 가능 BUT 외우지 는 않고 DNS를 통해 접근
• 특징
  • 분산적 database
  • application-layer에서만 작동 (= client-sever로 동작 )
  • end host= edge에서 작동
• DNS 서비스 → 분산적, 계층적 구조
  • IP주소를 호스트이름으로 변경
  • 호스트에 별명 가능
  • 메일서버에 대해 다른 별명 가능
  • 같은 이름으로 서로 다른 IP 제공가능 → 로드 분산
  • DNS서버 분산적으로 사용하는 이유 :
    • 하나가 망가지면 인터넷이 정상적으로 동작 X , 한번에 몰릴경우, 멀리 있는 경우, 피싱IP로 이동하는 것을 최소한으로막기(유지보수)
    • 분산적이고 계층적 구조 (root= contack-last-resort=13개 → 복제품 가짐)
    • Root(.com) → Top Level Domain (amazon) → Authoritative(직접적으로 IP를 가지고 할당해줄수 있음)
      1. Root = contack-last-resort=13개 → 복제품 가짐
      2. → DNSSEC를 통해 보안 제공, ICANN에 의해 관리(→위임해놓음)
      b. TLD : 담당서버가 다 나눠있음
    • → .kr가 해외에 위치해있는경우는 해외에서의 접근을 빠르게해주기위해
  • DNS servers
    • Authoritative DNS servers:
      • 기관이 직접 설치
    • Local DNS name servers
      • caches처럼 root에게 물어보기전 대답옴
  • DNS name query
    • iterated query (실제)→ host → local DNS / local DNS → host = recursive
    • host → local DNS → root DNS → local DNS → TLD DNS → local DNS → authoritative DNS → local DNS → host
    • recursive query (재귀)
    • host → local DNS → root DNS → TLD DNS → authoritative DNS → TLD DNS → root DNS → local DNS → host
  • DNS caches / update
    • 유효시간 : TTL
    • TLD한테 분산되서 날라가기때문에 ROOT 접근이 힘들다 혹은 LOCAL이 해결
    • out-of-data : 주소를 바꾸고 싶을경우 TTL이 끝날때 까지 기다리고 다시 요청해서 값을 받도록 함
  • DNS가 데이터 베이스 다루는법
    • resource records로 다룸
      1. type=Avalue = IP
      2. name = hostname
      3. type=NSvalue = authoritative name server의 hostname
      4. name = domain (dfa.com)
      5. type=CNAMEvalue = canonical name (adad.ada.ada.com)
      6. name=별명 (www)
      7. type=MX
      8. value = mailserver
    • RR format(name, value, type, ttl)
• DNS 프로토컬 메세지 구조
  • query, reply 모두 동일 한 format
• DNS 보안
  • DDOS 공격
    • root는 한번도 성공한 적 없음
      • 로컬 서버가 응답하거나 우회함
    • TLD 국가 서버는 위험함
  • Redirect 공격
    • dsn queries를 감지후 먼저 응답함 → TTL이 끝나기 전까지 저장된 걸로 응답
    • DNS자체에다가 응답을 넣음 (POISONING)
  • Exploit DNS for DDOS
    • 목적 주소 변경
  • 그래서 해쉬값 사용 = DNSSEC

P2P

• client-server 와는 다르게 여러대의 컴퓨터가 동시에 업로드 하는 시간이 추가되어 다운로드 시간이 측정되는데 이때 그 값은 부모 분자 모두 같이 유저 수에 대해 선형적 증가이므로 완만한 곡선
  • client-server은 n개의 카피만큼의 업로드 시간이 선형적으로 크게 증가하므로 직선형 함수다.
• BitTorrent
  • chunks단위로 파일 나눔
  • tracker : 참여자들의 정보를 담음
  • tracker에게 원하는 파일 요청 후 다운 → tracker에 데이터 쌓임 → 다운로드와 동시에 업로드
  • 여러명에게 분산적을 요청한다

video streaming and content distribution networks

• 하나의 기업이 여러명의 사용자를 커버하기위해서는 분산적이고 application level에 대한 인프라도 필요
• Multimedia
  • 비디오 압축(인코딩) 1
    • 연속된 이미지의 겹쳐진 이미지 활용
    • 처음에 전체 이미지 정보를 주는것이아니라 움직이는 것에 대한 백터 정보만 전달 후 이전 이미지에 덮어씌움
    • spatial coding : 반복되는 색깔
    • 비디오 종류
      • CBR : 비율로 압축된 비디오 → MPEG 1,2
      • VBR : 네트워크 상황에 따라 가변적으로 변함 → MPEG4
  • 도전
    • 처리량이 시간에 따라 변한다 →일정한 서비스 제공
    • 혼잡, delay
      • 이상적인 비디오 : 딜레이가 일정하다면 차례때로 보여줌
      • 실제 비디오 : 네트워크 delay가 매우 가변적(jitter) → client에서 buffer을 둠 (정지, 빨리감기...)
  • 실제 다운보다 조금 늦게 재생 → 네트워크 딜레이가 커져도 해당 버퍼만큼 잡아먹어서 재생 끊어지지 않게함 (클라이언트 하드웨어 사용) 2
  • 비디오 전송하는 프로토콜 : DASH (HTTP위에서) 3
    • server : chunck로 나누고 인코딩된 서로 다른 비율을 가짐 → 즉, 미리 화질에 따라 나눠둔거임, manifest file을 제공함으로써 서로 다른 url 제공
    • client : manifest file을 받아서 어떤 url로 접속할지 알려줌 → 자신에게 맞는 bandwidth로 맞춰서 청크를 불러온다 (자동 화질)
      • 클라이언트에게 intelligence를 가지고 있음
      • 그래서 streaming video = encoding + DASH + playout buffering
• CDNs
  • 동시에 제공하는 서비스 해결방법
    • 지리적으로 멀리 둔 site를 사용
    • client → 원하는 동영상 → 서버는 manifest file 제공 (가까운 서버 알려줌) → 가까운 서버에서 다운
  • 각각의 데이터가 host-host comunication으로 제공되고 있다
  • B → 비디오 요청 → url 제공 → local에게 물어봄 → authorattive dns로 주소 얻음 → 해당 곳으로 가서 주소 얻음 → ip주소 알게됨 → 비디오 다운받음
  • B → 브라우저에서 접속 → 클라우드에서 manifest file 제공 → 가까운 cdn으로 가서 다운
  • 아직도 고민중인 과제
    1. 컨텐츠의 노드를 어떻게 찾는가
    2. congestion 발생시 어떻게 할건가
    3. gd 어디다가?
• application architectures
  • client-server
    • server: 항상 켜져있음 + 영구적 ip 주소 (data center모습)
    • client: 간열적으로 연결, 동적 IP, 클라이언트끼리 소통 x, (HTTP, IMAP, FTP)
  • p2p
    • 토렌트가 대표적
    • 파일 다운로드를 하지 않아도 참여하는 데이터로드를 사용하여 높은 속도 보장 가능
    • 서버 제공 필요 x end systems들이 모여서 통신한다.
    • 서비스를 요청하기도 제공하기도 한다. (독점적 인프라가 없어도 self scalability)
    • IP가 변하고 간열적 연결을 해서 관리 힘듦
    • 여기서는 client process와 server process 이기도 하다!
• application service requirements:
  • reliability, bandwidth, delay
• Internet transport service model
  • connection-oriented, reliable: TCP
    • reliable transport : 확인에 대한 응답으로 해결
    • flow control : 압도하지 않기
    • congestion control : 전송속도 낮추기
    • does not provid : timing, minimum, throughput guarantee, security
    • connection-oriented : 서로간의 확인 필요
    • 많은 오버헤드 필요
    • TLS
      1. 보안을 강화한 TCP
      2. provides encrypted TCP connections data integrity end-point authentication
      3. 필요 단계 : TLS 라이브러리 읽기
  • unreliable, datagrams: UDP
    • unreliable data transfer : 서로 확인 없음
    • does not provid : reliability, flow control, congestion control, timing, throughput guarantee, security, or connection setup.
    • 속도 빠르고 적은 오버헤드 필요
• specific protocols:
  • HTTP
  • SMTP, IMAP
    • SMTP: 전송과 저장
    • IMAP : 메일을 불러올때
  • DNS
  • P2P: BitTorrent
    • client-server 와는 다르게 여러대의 컴퓨터가 동시에 업로드 하는 시간이 추가되어 다운로드 시간이 측정되는데 이때 그 값은 부모 분자 모두 같이 유저 수에 대해 선형적 증가이므로 완만한 곡선
      • client-server은 n개의 카피만큼의 업로드 시간이 선형적으로 크게 증가하므로 직선형 함수다.
    • BitTorrent
      • chunks단위로 파일 나눔
      • tracker : 참여자들의 정보를 담음
      • tracker에게 원하는 파일 요청 후 다운 → tracker에 데이터 쌓임 → 다운로드와 동시에 업로드
      • 여러명에게 분산적을 요청한다
• video streaming, CDNs
  • 동시에 제공하는 서비스 해결방법
    • 지리적으로 멀리 둔 site를 사용
    • client → 원하는 동영상 → 서버는 manifest file 제공 (가까운 서버 알려줌) → 가까운 서버에서 다운
  • 각각의 데이터가 host-host comunication으로 제공되고 있다
  • B → 비디오 요청 → url 제공 → local에게 물어봄 → authorattive dns로 주소 얻음 → 해당 곳으로 가서 주소 얻음 → ip주소 알게됨 → 비디오 다운받음
  • B → 브라우저에서 접속 → 클라우드에서 manifest file 제공 → 가까운 cdn으로 가서 다운
  • 아직도 고민중인 과제
    1. 컨텐츠의 노드를 어떻게 찾는가
    2. congestion 발생시 어떻게 할건가
    3. gd 어디다가?

Most importantly: learned about protocols!

• typical request/reply message exchange:
  • server responds with data, status code
    • request : ASCII (어떤요청을 하는지, URL, HTTP버전)
      • POST : 글자를 써서 전송
      • GET : URL을 쳐서 파일을 받아올때 (?사용)
      • HAED : 헤더만 달라
      • PUT : 업테이트 replaces
    • 명령어
    • response : 버전, 코드, 데이트, 최신 버전
      • 200 ok
      • 301 : 주소가 변경되서 REDIRECTION
      • 400 : 잘못된 요청다
      • 404 : 지원못하는 버전이다
      • 505 : 지원할수 없다
    • 코드
• message formats:
  • headers: fields giving info about data
  • data: info(payload) being communicated
• important themes:
  • centralized vs. decentralized
  • stateless vs. stateful
    • stateless : 과거의 동작을 기억하지 않는다.
    • stateful : 유지하기 위해서는 history를 유지하고 연결 중단시 복구에 대한 고려도 필요
      • COOKIES
        • state가 필요할경우에 cookies 사용!!
        • 다 잊어버려서 multi-step이 없다
        • stateful protocol과 유사하게 진행
        • 4가지 요소
          1. HTTP 응답에 쿠기 헤더 붙임
          2. HTTP요청에 쿠키 헤더 추가
          3. 사용자의 호스트에 보관된 쿠키 파일, 사용자의 브라우저에 의해 관리됨
          4. 웹 사이트의 백엔드 데이터베이스
        • 쿠키 단점
          1. 스니핑을 통해 사생활 침해
          2. 영구적인 쿠키를 통해 다중 웹 사이트 추적 가능
        • conditional GET
          • 업데이트가 되었으면 전송하고 너가 최신버전이면 304 CODE로 응답
      • Web caches (ISP에의해 주로 사용)
        • proxy servers가 접속한 사이트를 caches에 저장해서 다음번에도 이용 (여러 클라이언트 접속)
        • 사용하는 이유 : 소모되는 response 시간(RTT)를 줄일수 있다, traffic 줄일수 있다.
  • scalability
  • reliable vs. unreliable message transfer
    • TCP
    • UDP
  • “complexity at network edge”
    • 어플리케이션 layer에서 실행되기때문에 network end host 인 edge에서 동작한다

 

출처 : Hoorin Park Assistant Professor, Department of Information Security, Seoul Women’s University