컴퓨터 네트워킹 하향식 접근[Chapter 2]

[2.1] 네트워크 애플리켕션의 원리

• 네트워크 애플리케이션 개발의 중심은 다른 위치의 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것
• 사용자의 호스트(테스크톱, 태블릿, 스마트폰 등)에서 실행되는 브라우저 프로그램과 웹 서버 호스트에서 실행되는 웹 서버 프로그램

2.1.1 - 네트워크 애플리케이션 구조

• 클라이언트-서버 구조(client-sever architecture)
  • 서비스는 클라이언트라는 호스트들로부터 서비스 요청을 받음
  • 고전적인 예는 클라이언트 호스트에서 실행되는 브라우저에서 웹 서버로 서비스를 요청하는 웹 애플리케이션이 있다.
  • 클라이언트들 끼리 직접적으로 소통하지 않는다
    • sns를 통해 메시지를 보낼 때 대상자에게 직접 메시지를 보내는 것이 아닌 '송신 클라이언트 -> 서버 -> 수신 클라이언트'의 과정을 예시로 들 수 있을 듯
  • 서버가 고정 IP주소라는 잘 알려진 주소를 갖는다
    • 이 이유때문에 클라이언트는 언제 어디서든 서버 주소로 패킷을 보내 연결할 수 있다 
    • 서버 주소가 계속해서 바뀌면 클라이언트들은 그 서비스를 이용하기 어려울 것이다.
  • 때로는 하나의 서버 호스트가 해당 서비스의 모든 클라이언트의 요청을 다 응답하는 것은 불가능하다
    • 이런 이유로 수 많은 호스트를 갖춘 데이터 센터가 이용됨
• P2P구조(peer-to-peer)
  • 서버에 최소한으로 의존하는 방식
  • peer라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하게 한다
  • 자가 확장성
    • 하나의 peer는 클라이언트가 되기도 하지만 서버의 역할을 하기도 함

2.1.2 - 프로세스 간 통신

프로세스

• 운영체제에서 실제 통신하는 것(프로그램이 아닌 프로세스가 실제 통신을 한다)
• 프로세스 간의 통신을 위한 규칙은 종단 시스템의 운영체제에 의해 좌우된다
• 2개의 종단 시스템에서 프로세스는 메시지 교환으로 서로 통신한다
  • 송신 프로세스는 메시지를 네트워크로 보냄 -> 수신 프로세스는 네트워크로부터 메시지를 받음

클라이언트와 서버 프로세스

• 네트워크 애플리케이션은 네트워크에서 서로 메시지를 보내는 두 프로세스로 구성된다
  • ex)ㅇ웹 애플리케이션에서 클라이언트 브라우저 프로세스는 웹 서버 프로세스와 메시지를 교환한다
• P2P파일 공유 시스템에서는 한 피어의 프로세스에서 다른 피어의 프로세스로 파일을 전송한다
  • 각 쌍에 대해 하나는 클라이언트의 프로세스(클라이언트), 하나는 서버의 프로세스(서버)로 이름을 짓는다
  • 하나의 프로세스가 서버와 클라이언트의 역할을 다 할 수 있다

클라이언트와 서버 프로세스

• 프로세스는 소켓(socket)을 통해 네트워크로 메시지를 보내고 받는다
• 소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층 간의 인터페이스다
• 애플리케이션과 네트워크 사이의 API라고도 한다
• 애플리케이션 개발자는 소켓의 애플리케이션 계층에 대한 모든 통제권을 갖지만, 소켓의 트랜스포트 계층에 대한 통제권은 거의 갖지 못한다.
  • 트랜스포트 계층에 대한 애플리케이션 개발자의 통제는
    • 트랜스포트 프로토콜의 선택
    • 최대 버퍼와 최대 세그먼트 크기 같은 약간의 트랜스포트 계층 매개변수의 설정

프로세스 주소 배정

• 한 호스트의 프로세스가 패킷을 다른 호스트의 프로세스로 보내기 위해서는 수신 프로세스가 주소를 갖고 있어야 한다
  • 프로세스 주소 = 소켓 = IP주소 + 포트번호
    • 예를 들면 IP 주소는 내가 살고있는 건물의 주소지 이며 포트 번호는 내가 살고 있는 호수 이다
    • 웹 서버는 포트번호 80번으로 식별되며 메일 서버는 25번으로 식별됨
  • IP주소는 32비트로 구성되며 호스트를 유일하게 식별

2.1.3 - 애플리케이션이 이용 가능한 트랜스포트 서비스

• 소켓은 애플리케이션 프로세스와 트랜스포트 프로토콜 간의 인터페이스
  • 이 소캣을 통해 송신 프로세스는 메시지를 보내고 수신 프로세스는 메시지를 받음
• 트랜스포트 계층 프로토콜 그것을 이용하는 애플리케이션들에게 제공할 수 있는 서비스는
  '신뢰적 데이터 전송', '처리율', '시간', '보안' 이 네가지 차원으로 분류할 수 있음

신뢰적 데이터 전송

• 패킷들은 네트워크 내에서 손실 될 수 있다.(큐가 꽉차서 버려버리는 현상 등으로 인해)
• 하지만 전자메일, 파일 전송, 원격 호스트 접속, 재무 애플리케이션 등의 경우 데이터 손실은 위험한 결과를 초래함
• 위의 경우 데이터가 올바르고 완전히 전달되도록 보장하기 위한 서비스를 제공해야하는데 이를 신뢰적 데이터 전송을 제공한다고 함
  • 트랜스포트 계층 프로토콜이 이 서비스를 제공할 때 데이터가 온전할 것이라는 확신을 갖는다
  • 트랜스포트 계층 프로토콜이 이 서비스를 제공하지 않을 때는 손실 허용 애플리케이션의 경우이다
    • 실시간 오디오/비디오와 같은 멀티미디어 애플리케이션(ex. 동영상을 보는데 네트워크 상황으로 품질 저하가 일어나도 크게 문제되지 않는 경우)

처리율

• 네트워크 경로를 따라 두 프로세스 간의 통신 세션에서 비트를 전달할 수 있는 비율
• 다른 세션들이 대역폭을 공유하고 생겼다 없어졌다 하기 때문에 가용한 처리율은 시간에 따라 변동
• 대역폭 민감 애플리케이션(bandwidth-sensitive application)
  • 명시된 속도에서 보장된 가용 처리율을 제공한다
• 탄력적 애플리케이션(elastic application)
  • 가용 처리율이 많으면 많은대로 적으면 적은대로 이용
  • 전자메일, 파일 전송, 웹 전송 등

시간

• 송신자가 소켓으로 내보내는 모든 비트가 수신자의 소켓에 일정 시간 이내에 도착 할것이라는 시간보장
• 인터넷 전화, 가상 환경, 원격회의, 게임 등
  • 예를들어 인터넷 전화의 긴 지연시간은 부자연스러운 대화로 이어지기 때문

보안

• 트랜스포트 프로토콜은 애플리케이션에 하나 이상의 보안 서비스를 제공할 수 있다
• 기밀성, 데이터 무결성, 종단 인증등의 보안에 대해서는 8장에서 다룸

 

2.1.4 - 인터넷 전송 프로토콜이 제공하는 서비스

TCP서비스(특징)

• 연결지향형 서비스
  • 애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환한다
    • 이 핸드셰이킹 과정은 패킷이 곧 도달할 테니 준비하라고 알려주는 역할
  • 위 핸드셰이킹 과정을 지나면 TCP연결이 두 프로세스의 소켓 사이에 존재한다고 말해줌
  • 이 연결을 통해 서로에게 메시지를 보내고 받을 수 있기에 '전 이중(full-duplex)연결이라고 한다
  • 통신이 끝나면 연결을 끊어야 한다
• 신뢰적인 데이터 전송 서비스
  • 모든 데이터를 오류 없이 올바른 순서로 전달하기 위해 TCP에 의존
  • 데이터가 손실되거나 중복되지 않게 수신 소켓으로 전달
• 혼잡 제어 방식
  • 통신하는 프로세스의 직접 이득보다는 인터넷의 전체 성능 향상을 위한 서비스
  • 각 TCP연결이 네트워크 대역폭을 공평하게 공유할 수 있게끔 제한하려고 함

UDP서비스(특징)

• 최소의 서비스 모델을 가진 간단한 전송 프로토콜
• 비연결형 -> 핸드셰이킹 안함
• 비신뢰적인 데이터 전송 서비스 -> 데이터 송/수신이 온전하게 이루어지지 않을 수도 있으며 순서가 뒤바뀔 수도 있음
• 혼잡 제어 방식 x

인터넷 트랜스포트 프로토콜이 제공하지 않는 서비스

• 많은 방화벽이 UDP트래픽을 차단하도록 설정되어 있기 때문에 UDP방식의 애플리케이션은 UDP통신이 실패할 경우를 대비해 TCP를 사용하도록 설계됨

2.1.5 - 애플리케이션 계층 프로토콜

애플리케이션의 프로세스가 서로 메시지를 보내는 방법

• 애플리케이션 계층의 프로토콜을 아래와 같은 걸 정의함
  • 교환 메시지 타입(ex. 요청 메시지와 응답 메시지, request&response)
  • 여러 메시지 타입의 문법(ex. 메시지 내부의 필드와 필드 간의 구별 방법, json과 같은...)
  • 필드의 의미, 즉 필드에 있는 정보의 의미
  • 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지 결정하는 규칙
• RFC에 명시되어있음
• 만약 브라우저 개발자가 HTTP RFC 규칙을 따르면 HTTP RFC규칙을 따르는 어떠한 웹 서버와 통신 가능
• 독자적은 프로토콜을 이용하는 애플리케이션도 많다

[2.2] 웹과 HTTP

온디맨드 방식 : 사용자들이 원할 때 원하는 것을 수신

 

2.2.1 - HTTP 개요

HyperText Transfer Protocol. 즉, 하이퍼 텍스트를 전송하는 프로토콜(request와 response를 통해서)

 

웹 용어

• 웹 페이지(web page) : 객체로 구성된 페이지
• 객체(object) : 단일 URL로 지정할 수 있는 하나의 파일(이미지, HTML텍스트 등등)
  • HTML텍스트는 그 안에 다른 객체를 URL로 참조한다

 

• HTTP는 웹 클라이언트가 웹 서버에게 웹 페이지를 어떻게 요청하는지와 서버가 클라이언트로 어떻게 웹 페이지를 전송하는지를 정의
  • 브라우저는 페이지 내부의 객체에 대한 HTTP요청 메시지를 서버에게 보내고 서버는 그 객체를 포함하는 HTTP응답값을 메시지로 응답
• HTTP는 TCP프로토콜 사용
  • HTTP클라이언트는 서버에 TCP연결 시작
  • 연결이 이루어지면 데이터를 주고받을 소켓 인터페이스를 통해 접속
  • 클라이언트는 요청 메시지를 소켓으로 보내고 서버는 소켓으로 응답값을 보낸다
• 서버가 클라이언트에게 요청 파일을 보낼 때, 클라이언트에 대한 그 어떤 정보도 저장하지 않는다 -> 비상태 프로토콜(stateless protocol)

2.2.2 - 비지속 연결과 지속 연결

• RTT : TCP연결을 위해 작은 패킷이 가고 돌아오는데 걸리는 시간

 

• 각 요구/응답 쌍이 분리된 TCP연결을 통해 주고 받는 것 - 비지속 연결(non-persistent connection)
  
  • 요구/응답 할 때 마다 RTT만큼의 시간이 계속 증가
• 모든 요구/응답들이 같은 TCP연결을 통해 주고 받는 것 - 지속 연결(persistent connection)
  • HTTP는 디폴트 모드로 지속 연결을 사용(but, 비지속 연결 설정은 가능함)
  • RTT 한 번만 소요됨
  • 서버는 일정시간 사용되지 않으면 연결을 닫음

2.2.3 - HTTP 메시지 포멧

HTTP 요청 메시지

• 첫 줄은 요청 라인으로 method, URL, 버전으로 이루어짐
  • method : GET, POST, HEAD, PUT, DELETE, PATCH 등

HTTP 응답 메시지

• 상태라인, 헤더라인, 개체 몸체(응답 데이터)로 이루어짐

2.2.4 - 사용자간 서버 간의 상호작용 : 쿠키

• 사이트가 사용자를 추적하기 위해 HTTP는 쿠키를 사용한다
  • 처음으로 어떤 사이트에 접속하게 되면 HTTP응답에 식별 번호를 답고있는 'Set-cookie'가 헤더에 포함되고 클라이언트는 이를 저장한다
  • 저장된 쿠키는 서버로 요청 보낼 때 이 식별 번호를 헤더에 담아 보내고 서버는 이 식별번호를 토대로 데이터 베이스에 정보를 수집한다
• 쿠키는 인터넷 쇼핑등 편의성을 제공하지만 사생활 침해로 이어질 수 있어 논쟁거리가 된다

2.2.5 - 웹 캐싱

웹 캐시(Web cache, 혹은 프록시 서버(proxy server))는 기점 웹 서버를 대신해 HTTP요구를 충족시키는 네트워크 개체

• 자체의 저장소를 갖고 있어 요청된 객체의 사본을 저장 및 보존함
  • 브라우저 웹은 프록시서버와 TCP연결을 하고 요청을 보냄
  • 프록시 서버는 사본이 저장되어있으면 사본을 전달하고 없으면 기점 서버로 TCP연결을 설정해 데이터를 받아와 웹 브라우저로 전달(이 때 사본을 저장)
• 일반적으로 프록시 서버는 ISP구입하고 설치함
  • 예를 들어 대학교가 ISP일 때 이 대학교는 프록시 서버를 설치해 캠퍼스의 브라우저가 이 프록시로 요청하도록 설정함
  • 가정에서는 로컬 ISP가 위 역할을 함
• 프록시 서버는 클라이언트의 요구에 대한 응답 시간을 줄일 수 있다
• 기점 서버의 트래픽을 낮출 수 있다
• 전송률 늘리기 vs 프록시 서버 설치
  • 전송률을 늘리기 위해 선로 작업등의 막대한 비용이 들며 이렇게 한다고 해도 그 늘린 만큼의 이용자가 접속하게 되면 또 전송률이지연이 발생한다
  • 프록시 서버를 설치하면 실질적으로 링크에 남아있는 사용자는 없으므로 속도도 향상되고 더 효율적임

조건부 GET

• 웹 캐싱이 속도는 빠를 수 있지만 이 데이터가 기점 서버에서 수정된다면 사본은 더 이상 신뢰가 가능한 데이터가 아님(일관성이 없음)
• 그렇기에 프록시 서버가 기점 서버로 "이 데이터가 변경됐니?" 에 대한 조건을 담은 요청을 보내고 변경되었으면 새로운 객체를 아니라면 "변경되지 않았어"라는 응답값을 받고 사본을 클라이언트에게 건내줌

2.2.6 - HTTP/2

• HTTP/2는 1997년에 표준화된 HTTP/1.1 이후 새로운 첫 번째 HTTP버전
• 2020년 기준 주요 웹사이트의 40%가 HTTP/2를 지원
• HTTP/2의 주요 목표는 TCP 연결상에서 멀티플렉싱 요청/응답 지연 시간을 줄이기
  • 요청 우선순위화, 서버 푸시, HTTP헤더 필드의 효율적인 압축 기능
  • HTTP메소드는 변경되지 않았으나 클라이언트와 서버 간의 데이터 포맷 방법과 전송 방법을 변경
• 웹 페이지당 하나의 TCP연결을 가짐으로써 소켓 수를 줄여 전송되는 각 웹페이지는 공정한 대역폭을 가질 수 있었으나 블로킹 문제 발생
  • 10개 요청중 첫 요청의 응답값의 크기가 크다면 나머지 9개는 기다리는 현상
• 3장에서 논의 예정

HTTP/2 프레이밍

• 각 메시지를 작은 프레임으로 나누고 같은 TCP연결에서의 요청과 응답 메시지를 끼워 넣는다
• 모든 프레임은 고정된 길이를 갖고 비디오 클립은 1000개의 프레임으로 구성되고 나머지는 2개의 프레임으로 구성된다고 가정(비디오 한 개 나머지 10개)
  • 비디오 2/1000 (2개 프레임) -> 1번 객체 (2개 프레임) -> 2번 객체 (2개 프레임)....->9번 객체 (2개 프레임)-> 비디오 4/1000 (2개 프레임) -> 비디오 6/1000 (2개 프레임).....비디오1000/1000 (2개 프레임)
  • 원래 같으면 비디오 1000개 프레임을 다기다려야만 다음 화면을 불러올 수 있는데 이렇게 프레이밍을 하면 사용자는 상대적으로 기다리는 시간이 줄어들게 느껴짐

메시지 우선순위화 및 서버 푸싱

• 1~256사이의 가중치를 부여해 요청에 우선순위를 매김
• 서버는 가장 높은 우선순위의 요청을 위한 프레임을 제일 먼저 보낼 수 있음

HTTP/3

• 새로운 트랜프포트 프로토콜인 QUIC
  • UDP프로토콜 위에 위치하는 애플리케이션 계층에 구현되어 있으며 완전히 표준화된 상태는 아님
  • 3장에 서논의

[2.3] 인터넷 전자메일

• 전자메일은 비동기적인 통신 매체(상대방이 대기중인것과 상관없이 메시지를 보냄)
• 메일 시스템의 3개의 주요소
  • 사용자 에이전트(user agent)
    • 사용자가 메일을 읽고 응답하고 전달하고 저장하고 구성하게 해줌
    • 애플 메일, 웹용 지메일, 스마트폰용 지메일 등
  • 메일 서버(mail server)
    
    • 각 유저의 메일 박스를 갖고 있음
    • A가 B에게 메일을 보내면 B메일의 회사의 서버는 B의 메일박스에 그 메일을 저장
    • 만약 B메일 서버가 고장나면 A메일 회사의 서버는 30분마다 재전송을 하다가 성공하지 못하면 A에게 통보하는 등의 조치를 취함
  • SMTP(simple mail transger protocol)(2.3.1 내용 포함)
    
    • 전자메일을 위한 주요 애플리케이션 계층 프로토콜
    • 한 메일 회사의 서버는 메일을 보낼 때는 클라이언트로서, 메일을 받을 대는 서버로서 작동
    • ASCII로 주고 받기에 이미지, 영상같은걸 보낼때는 인코딩-디코딩 과정이 필요
    • 두 메일 서버가 멀리떨어져 있더라도 중간 서버를 사용하지 않음

2.3.2 - 메일 메시지 포멧

• 모든 헤더는 From헤더라인과 To헤더 라인을 반드시 가져야 한다

2.3.3 - 메일 접속 프로토콜

• 메일 회사의 서버간 통신은 SMTP를 사용하지만 사용자가 메일을 확인 할 때는 메일 회사의 서버로 HTTP요청을 통해 주고 받는다

[2.4] DNS : 인터넷의 디렉터리 서비스

• 호스트의 식별자는 IP도 있지만 '호스트 이름'도 있다
  • 예시로 "안녕하세요 저는 000101-1011351 입니다" 하고 인사하는 것 보다 "안녕하세요 저는 김ㅇㅇ입니다"하고 인사를 하는게 서로가 편할 것이다

2.4.1 - DNS가 제공하는 서비스

• 호스트 이름을 IP로 변환해주는 서비스
  • DNS서버들의 계층 구조로 구현된 분산 데이터 베이스
  • 호스트가 분산 데이터베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜
  • UDP상에서 수행되고 포트번호 53을 이용
• 제공하는 서비스
  • 호스트 이름 IP주소로 변환
  • 호스트 에일리어싱(host aliasing)
    • 복잡한 호스트 이름을 가진 호스트는 하나 이상의 별명을 가질 수 있다(정식 호스트 이름 - 별칭으로 구분)
  • 메일 서버 에일리어싱(mail sever aliasing)
    • 전자메일 호스트를 기억하기 쉽게 제공
  • 부하 분산(load distribution)
    • 중복 웹 서버 같은 여러 중복 서버 사이에 부하를 분산하기 위해서도 사용

2.4.2 - DNS 동작 원리 개요

• 클라이언트는 호스트 이름을 명시하여 DNS측의 클라이언트를 호출
• 사용자 호스트의 DNS는 네트워크에 질의 메시지를 보냄
• 해당 요청의 매핑에 해당하는 응답 메시지를 보냄
• 하나의 서버로 하기에는 문제가 있음
  • 고장나면 인터넷 전체가 작동하지 않는다
  • 트래픽양이 많아지면 지연이 발생
  • 먼 거리의 중앙 집중 데이터베이스로 인해 거리가 멀 수록 지연이 발생
  • 데이터베이스가 거대해짐에 따라 유지관리가 어려워짐

분산 계층 데이터베이스

• 루트 DNS 서버
  • 루트서버는13개의 다른 루트 서버 복사체이고 12개의 다른 기관에서 관리됨
  • 루트 서버는 TLD서버의 IP주소를 제공
• 최상위 레벨 도메인(TLD)서버
  • com, org, net, edu, gov같은 상위 레벨 도메인과 kr, uk,fr,ca,jp같은 국가의 상위 레벨 도메인에 대한 TLD서버
  • TLD서버는 책임 DNS서버에 대한 IP를 제공
• 책임 DNS 서버
  • 접근하기 쉬운 호스트를 가진 모든 기관은 호스트 이름을 IP주소로 매핑하는 공개적인 DNS레코드를 제공해야 한다
  • DNS서버에 이 레코드를 저장하도록 비용을 지불한다
  • 대부분의 대학과 큰 기업들은 기본 책임 DNS와 보조 책임 DNS서버를 운영한다
• 로컬 DNS서버
  
  • DNS서버 계층에 엄격하게 포함되지는 않지만 중요함
  • 호스트 질의를 먼저 확인해 저장되어있어주면 전달함(프록시 방식으로 동작)
• 작동 박싱
  • 클라이언트가 로컬 DNS서버에게 호스트 네임으로 질의함
  • 로컬 DNS 서버에 저장되어있으면 전달하고 없으면 루트 DNS에 물어봄
  • 해당 정보에 해당하는 TLD서버 정보를 줌(Type A + Type NS -> 아래 작성될 예정)
  • 로컬 DNS는 이 정보를 가지고 해당 TLD서버에게 또 물어봄
  • TLD서버는 해당 정보에 해당하는 책임 DNS서버 정보를 줌(Type A + Type NS)
  • 로컬 DNS는 이 정보를 가지고 책임 DNS서버에게 또 물어봄
  • 책임 DNS서버는 결과를 돌려줌(Type A)
  • 로컬 DNS 서버는 이 결과를 클라이언트에게 전달함

DNS 캐싱

• 로컬 DNS는 성능 향상을 위해 캐싱을 사용
• 호스트 DNS와 IP주소 매핑은 영구적인것이 아니기에 특정 기간(흔히 2일)을 설정해놓고 이 이내에 요청된 정보라면 그걸 클라이언트로 전달 -> TTL(time to live)

2.4.3 - DNS 레코드와 메시지

• DNS서버들은 호스트 이름을 IP주소로 매핑하기 위해 자원 레코드(resource record, RR)을 저장함
• 자원 레코드는 (Name, Value, Type, TTL)의 필드를 포함하며 Type은 아래와 같음
  • Type=A : Name은 호스트 이름이고 Value는 호스트 이름에 대한 IP주소
  • Type=NS : Name은 도메인 이고 Value는 도메인 내부의 호스트에 대한 IP주소
  • Type=CNAME : Name은 별칭 호스트 이름이고 Value는 정식 호스트 이름
  • Type=MX : Name은 별칭 호스트 이름이고 Value는 해당 메일 서버의 정식 이름

DNS메시지

• 처음 12바이트는 헤더 영역
• 질문 영역
  • 현재 질의에 대한 정보를 포함
    • 질의 되는 이름을 포함하는 이름 필드와 질문타입을 나타내는 타입 필드를 포함
• DNS 서버로부터의 응답에서 답변 영역
• 책임 영역 : 다른 책임 서버의 레코드를 포함
• 추가 영역 : 다른 도움이 되는 레코드를 포함

즉, Type=A 자원 레코드와 Type=MX레코드 둘 다 DNS메시지에 포함 될 수 있음

 

DNS 데이터베이스에 레코드 삽입

• 새로운 기업을 설립해 도메인을 만들었으면 도메인 네임을 등록기관에 등록해야함
• 등록기관은 도메인 네임의 유일성을 확인하고 그 도메인 이름을 데이터베이스에 넣고 요금을 받음
• 도메인 네임 등록시 주책임 서버와 부책임 서버의 이름과 IP주소를 등록기관에 제공해야함
• 등록기관은 Type NS와 Type A레코드가 TLD서버에 등록되도록 확인해야함

[2.5] P2P파일 분배

• P2P구조는 서버에 최소한으로 의존하는 대신 간헐적으로 연결되는 호스트 쌍들(피어)이 서로 직접 통신
• 만약 서비스가 서버 <-> 클라이언트 방식에 의존한다면 클라이언트가 늘어나면 시간이 무한정으로 증가하고 어떤 클라이언트는 다운도 못하고 기다리고 있을 것이다
• P2P방식에서는 파일을 여러개의 조각(청크chunk)로 나눈 뒤 공유한다
• P2P방식은 아래와 같다
  • 최초에는 서버로부터 A클라이언트가 파일을 공유 받는다
  • A는 다운로드 스트림을 통해 청크를 공유받는대로 해당 청크를 업로드 스트림을 통해 B클라이언트에게 공유한다
  • B클라이언트는 다운로드 스트림을 통해 A클라이언트로 부터 청크를 받는 대로 B의 업로드 스트림을 통해 C에게 공유한다.
  • 위 과정을 다운로드를 시도하는 클라이언트에게 무한히 반복
• 위 과정을 토대로라면 A가 서버로부터 다운로드가 끝났을 때 B로의 공유가 끝나기 전에 연결을 끊는다면 문제가 발생하는 데 '비트 토렌트'는 아래와 같이 해결
  •  각 피어들에게 '트래커'라고 부르는 노드를 갖고있게 한다
  • 이 노드를 통해 각 피어가 활성화 되어있음을 주변에게 알린다
  • 만약 A가 연결을 끊었을 때 트래커가 활성화 되어있는 사람을 찾아 남은 파일을 공유 받는다
    • 이 과정에서 '가장 드문 것 먼저' 찾고 해당 클라이언트에게 공유를 요청한다
    • 가장 드문 것 먼저 : 실제로 공유가 제일 잘 안돼서 먼저 받아두면 좋은 거

[2.6] 비디오 스트리밍과 콘텐츠 분배 네트워크

넷플릭스, 유튜브, 아마존 프라임등 스트리밍 비디오가 2020년 인터넷 트래픽의 80%를 차지했다

2.5.1 - 인터넷 비디오

• 스트리밍 비디오 애플리케이션에는 미리 녹화된 비디오를 서버에 저장되어 사용자가 비디오 시청을 서버에게 온디맨드로 요청한다
• 비디오 매체
  • 비디오는 이미지의 연속으로서 일반적으로 초당 24개 또는 30개의 이미지로 일정한 속도로 표시된다
  • 비디오 품질과 비트 전송률은 서로 반비례한다
• 스트리밍 비디오에서 가장 중요한 성능 척도는 평균 종단 간 처리량이다
• 연속적으로 재생을 제공하기 위해, 네트워크는 압축된 비디오의 전송률 이상의 스트리밍 애플리케이션에 대한 평균 처리량을 제공해야 한다
• 300kbps, 1Mbps, 3Mpbs등의 속도로 동일한 비디오의 여러 버전을 만들어놔 사용자의 인터넷 환경에 맞게 보고싶은 버전을 결정할 수 있다
  • 3G환경에서는 300kbps버전 영상을, 와이파이 환경에서는 3Mpbs버전을

2.6.2 HTTP 스트리밍 및 DASH

• 사용자가 비디오 시청을 원하면 클라이언트는 서버에게 TCP연결을 하고 해당 URL에 대한 GET요청을 보낸다
• 클라이언트 쪽에서는 애플리케이션 버퍼에 전송된 바이트가 저장되고 이게 임곗값을 넘어가면 재생을 시작한다(버퍼링)
• 정리
  • 서버는 동영상을 몇 초 단위의 청크로 저장함 
  • DASH방식은 네트워크 속도를 감지하고 그 속도에 맞는 품질의 URL로 해당 청크를 요청
  • 예)
    • 집에 오는길에 3G상태로 영상을 보면서 올 때 480p로 보면서 왔다
    • 집에 들어와 네트워크가 와이파이에 연결되자 화잘이 1080p로 바뀐다

2.6.3 콘텐츠 분배 네트워크(CDN)

• 스트리밍 서비스 제공하는 가장 단순한 방법은 단일 거대한 데이터 센터 구축 후 운영
  • 클라이언트가 데이터 센터로부터 멀면 많은 링크를 거쳐 결국 속도가 느려짐
  • 인기있는 비디오는 요청이 많아 느려짐
  • 서버 문제 생기면 그냥 서비스가 중단됨
• 콘텐츠 분배 네트워크(Content Distribution Network, CDN)
  • 다수의 지점에 분산된 서버들을 운영하며 복사본을 분산 서버에 저장
  • 철학
    • Enter Deep
      • Akamai에 의해 주장됨
      • 서버 클러스터를 세계 곳곳의 접속 네트워크에 구축함으로써 ISP의 접속 네트워크로 깊숙이 들어가는 것
      • 이 방식의 목적은 서버를 최대한 사용자 가까이에 위치시켜 사용자와 서버 사이의 링크 및 라우터 수를 줄이고 지연시간 개선
      • 비용이 커진다는 문제가 있음
    • Bring Home
      • Limelight와 다른 회사들에 의해 적용된 것
      • 좀 더 적은 수의 핵심 지점에 큰 ㅋ규모의 서버 클러스터를 구축하여 ISP를 Home으로 가져오는 것
      • 접속 ISP에 연결하는 대신, 이러한 CDN들은 일반적으로 그들의 클러스터를 인터넷 교환 지점에 배치
      • 유지 관리 비용이 줄어드는 대신 사용자의 지연시간은 상대적으로 나빠짐
  • 서버 클러스터는 모든 비디오를 저장 할 필요는 없고 인기있는 비디오나 특정 국가에서만 인기있는 비디오를 저장
  • 공간이 가득차면 자주 사용되지 않는 비디오는 제거

CDN 동작

• 클라이언트가 비디오 재생 요청
• CDN은 그요청을 가로채 그 시점에서 클라이언트에게 가장 적당한 CDN클러스터를 선택하고 해당 클러스터의 서버로 연결
• 보통 링크가 가장 적은곳으로(가까운곳?)연결하나 서버 부하를 줄이기 위해 일부러 먼곳으로 배정하기도 함

2.6.3 사례연구 : 넷플릭스, 유튜브

넷플릭스

• 아마존 클라우드와 자체 CDN 인프라 구축
  • 아마존 클라우드의 역할
    • 회원가입, 로그인, 결제, 검색, 추천 서비스등을 처리하는 웹사이트의 기능
    • 콘텐츠 수집 : 사용자에게 제공할 영화 드라마등을 수집
    • 콘텐츠 처리 : 위에서 수집된 영상을 플랫폼, 네트워크등 상황에 맞춰 여러 버전으로 생성
    • CDN으로의 버전 업로드
• 넷플릭스는 풀캐싱 방식으로 CDN서버를 채우기에 사용량이 적은 시간에 비디오를 푸시함
• 전체 영상을 보유할 수 없는 곳의 경우 매일매일 가장 많이 보는 비디오만 푸시

유튜브

• 구글은 자체 비공개 CDN을 사용해유튜브 동영상을 배포하고 수백가지의 위치에 서버 클러스터를 설치함
• 해당 위치에서 거대한 데이터 센터에서 직접 동영상을 배포
• 유튜브는 DASH대신 사용자가 직접 영상 버전을 선택하도록함

[2.7] 소켓 프로그래밍 : 네트워크 애플리케이션 생성

• 일반적인 네트워크 애플리케이션은 클라이언트와 서버 프로세스가 생성되고, 두 프로세스가 소켓으로부터 읽고 쓰기를 통해 서로 통신함
• TCP는 연결지향형 서비스이고 신뢰적 바이트 스트림 채널 제공
• UDP는 비연결형이고 다른 곳으로 데이터를 독립적인 패킷으로 만들어서 보내는데 전송에 대한 보장은 하지 않음
• RFC에 정의된 프로토콜을 사용할 때는 잘 알려진 포트 번호를 사용해야하고 독점적으로 개발할 때는 잘 알려지지 않은 포트 번호를 사용해야한다

2.7.1  UDP를 이용한 소켓 프로그래밍

• 연결 없은, 무엇을 어디로(ip, 포트번호) 보낼지만 정해서 보냄, 유실에 대한 고민 x
• 서버는 클라이언트의 메시지를 수신하고 응답할 수 있도록 준비하고 수행되고 있어야 한다(즉, 프로세스가 실행되고 있어야 한다)

UDPClient.py

• 첫 번째 라인은 'serverName'은 호스트이름을 할당
• 두 번째 라인 'serverPort'는 소켓 포트 번호 할당
• ClientSocket = socket(AF_INET, SOCK_DGRAM) 라인은 소켓을 생성하는 라인
  • AF_INET: 네트워크가 IPv4를 사용하고 있음을 나타냄
  • SOCK_DGRAM은 이 소켓은 UDP소켓임을 나타냄
• 이 후 서버로 메시지를 보내고 통신하게 되며 통신이 끝나면 꼭 close()를 해줘야 함

UDPServer.py

• 첫 번째 라인은 'serverName'은 호스트이름을 할당
• 두 번째 라인 'serverPort'는 소켓 포트 번호 할당
• ClientSocket = socket(AF_INET, SOCK_DGRAM) 라인은 소켓을 생성하는 라인
• bind(('', serverPort(포트번호))
  • 포트 번호를 서버의 소켓에 할당함
• 이 후 클라이언트로 부터 메시지를 받고 통신하게 되며 통신이 끝나면 꼭 close()를 해줘야함

2.7.2  TCP를 이용한 소켓 프로그래밍

• 클라이언트와 서버가 데이터를 보내기 전에 TCP연결을 설정해야함
• TCP연결 소켓을 통해 연결하면 새로운 소켓으로 데이터를 주고 받음
• 서버가 TCP연결을 위한 포트를 열고 기다림
  • soket(AF_INET, SOCK_STREAM) : 소켓 정보를 통해 소켓 생성
  • bind() : 해당 포트 번호를 서버의 소켓에 할당
  • listen() : 서버 소켓을 리스닝 상태로 만들고 데이터 받을 준비
  • accept() : 대기 중인 요청을 수락
  • 그 뒤로 통신 주고받고 마무리 할 때 close()
• 클라이언트는 서버의 TCP연결 요청을 먼저함
  • soket(AF_INET, SOCK_STREAM) : 서버의 특정 포트에 연결되는 소켓 생성
  • connect() : 서버간 연결 시작
  • 그 뒤로 통신 주고받고 마무리 할 때 close()