[컴퓨터 네트워크 하향식 접근] Chapter02 애플리케이션 계층

 

*본문에서 어플리케이션 = 애플리케이션= 어플

2.1 네트워크 애플리케이션의 원리

여러 종단 시스템에서 실행되는 소프트웨어는 C, JAVA 등으로 작성되는데, 라우터나 링크 계층 스위치와 같이

네트워크 코어 장비에서 실행되는 소프트웨어는 작성할 필요가 없다.

 

어플리케이션 구조: 어플 개발자에 의해 설계되고 어플이 종단 시스템에서 어떻게 조직되어야 하는지를 지시

- 네트워크 어플리케이션에 클라이언트/서버구조 혹은 P2P구조를 사용

클라이언트-서버 구조: 서버는 항상 켜짐. 클라이언트라는 호스트의 요청을 받음.

클라이언트끼린 서로 직접적 통신x, 서버는 고정 IP주소라는 잘 알려진 주소를 가짐.

웹, 파일전송, 원격 로그인, 전자메일 등의 어플리케이션들이 있음.

하나의 서버로 호스트의 요청을 못 버티는 경우 때문에 많은 수의 호스트를 갖춘 데이터 센터(약 10만 서버) 사용

P2P 구조: 항상 켜지 있는 기반구조. 서버에 최소로 의존하는 대신 피어라는 간헐적으로 연결된 호스트쌍끼리

직접 통신. 트래픽 집중적인 어플들(파일 공유, 다운로드 가속기, 인터넷 전화 등)에서 주로 사용.

자가 확장성- P2P 파일 공유 어플리케이션에서 각 피어들은 파일을 요구하여 작업 부하를 만들어 내지만

각 피어들은 또한 파일을 다른 피어들에게 분배하여 그 시스템에 서비스 능력을 추가한다.

서버 기반 구조와 달리 서버 대역폭 필요 없어서 비용 효율측면에서 우수.

 

통신하는 건 프로그램이 아닌 종단 시스템에서 시행되는 프로세스이다.

통신 프로세스간에 서로 메시지를 교환하여 통신.

P2P파일 공유에서도 파일을 내려받는 피어를 클라이언트, 파일을 올리는 피어를 서버라고 지칭함.

두 프로세스 간의 통신 세션에서 [통신을 초기화 한다 = 클라이언트, 접속을 기다린다 = 서버]

 

프로세스는 소켓을 통해 네트워크로 메시지를 주고받음. (프로세스는 집, 소켓은 집 출입문)

소켓: 네트워크 어플리케이션과 전송 계층 간의 인터페이스 담당. 어플과 네트워크 사이의 API

어플 개발자는 소캣의 어플계층 통제권은 가지지만 전송 계층 통제권은 거의 갖지 못함.(계층의 분리성)

어플 개발자의 전송 계층 통제권은 기껏해야 [전송 프로토콜 선택, 최대 버퍼와 최대 세그먼트 설정 정도]

 

프로세스 주소 배정

수신 프로세스 식별 - 호스트 주소, 그 목적지 호스트 내의 수신 프로세스 식별자

주소는 IP주소로 식별, 수신 프로세스는 목적지 포트 번호로 식별.

ex) 웹서버는 포트번호 80, SMTP 메일 서버는 25번 등등..

============================================================

전송 계층 프로토콜이 어플리케이션에 제공할 수 있는 서비스

신뢰적 데이터 전송: 패킷이 오버플로우되거나 패킷의 비트가 잘못되어 데이터 손실이 생기는 것 방지.

(실시간 오디오, 비디오 같은 멀티미디어 어플은 손실 허용 어플.)

처리율: 송신 프로세스가 수신 프로세스로 비트를 전달할 수 있는 비율.

명시된 속도에서 보장된 가용 처리율을 제공.

(처리율 요구 사항을 갖는 어플 = 대역폭 민감 어플) (가용한 처리율에 따라 많으면 많은 대로 적으면 적은 대로 사용하는 어플 = 탄력적 어플)

시간: 시간보장 제공. 송신자가 소켓으로 내보내는 모든 비트가 수신자 소켓에 100 msec내에 도착하는 등,

엄격한 시간제한 조건을 요구하는 실시간 상호작용 어플에서 필요

보안: 송신 호스트에서의 전송 프로토콜이 데이터 암호화, 수신 호스트에선 복호화.

두 프로세스 사이에 비밀성 제공, 데이터 무결성과 종단 인증 등.

 

인터넷이 제공하는 어플 지원 서비스로는

TCP: 연결 지향형 서비스. 클라이언트와 서버가 서로 전송 제어 정보 교환(핸드 셰이킹)

핸드 셰이킹 이후에 두 프로세스의 소켓 사이에 TCP 연결 존재여부 확인 -> 전이중 연결

신뢰적 데이터 전송 서비스(한쪽 어플에서 보낸 스트림이 손실되거나 중복되지 않게 전달),

혼잡제어(인터넷 전체 성능 향상을 위한 서비스로 각 TCP 대역폭을 공평하게 공유할 수 있게끔) 등의 기능 제공

UDP: 비연결형 서비스. 비신뢰적, 혼잡제어 제공x (송신 측이 데이터를 원하는 속도로 하위 계층으로 보낼 수 있음)

 

TCP, UDP 둘 다 처리율, 시간 보장에 대해 만족스런 서비스를 제공할 순 있으나,

시간 혹은 대역폭 보장을 제공할 순 x 많은 방화벽들이 대부분의 UDP 트래픽은 차단함.

 

자 이제 어플 계층 프로토콜로 다시 돌아오자

->서로 다른 종단 시스템에서 실행되는 어플의 프로세스가 서로 메시지를 보내는 법

교환 메시지 타입(요청/응답), 여러 메시지 타입의 문법(메시지 내부 필드와 필드 간 구별법 등), 필드의 의미,

언제 어떻게 프로세스가 메시지를 전송하고 응답하는지 결정규칙.

HTTP 등은 RFC에 명시돼 있음.비개방 어플 계층 프로토콜(Skype 등)은 공중 도메인에서 구할 수 없다.

웹: 사용자가 웹 서버로부터 문서를 얻게 해주는 네트워크 어플

문서 포맷 표준(HTML), 웹 브라우저, 웹 서버, 어플 계층 프로토콜, HTTP 등으로 구성

*어플 계층 프로토콜 & HTTP : 브라우저와 웹 서버 사이 교환되는 메시지의 포맷, 순서 정의

 

(아래 2.2~2.6 웹이랑 HTTP를 이해하고, HTTP와 대조를 이루는 FTP를 쓱 알아볼 예정.

전자메일도 여러 어플 계층 프로토콜을 사용한다는 점에서 웹보다 복잡.

그 후 디렉터리 서비스를 제공하는 DNS에 대해 다룸. 코어 네트워크 기능(네트워크 이름->주소 변환)

P2P와 CDN상에서 저장 비디오를 포함하는 비디오 스트리밍 온 디맨드에 대해 다룸)

 

2.2 웹과 HTTP

웹: 온-디맨드 방식으로 동작. 정보를 주고받기 쉽고 비용이 낮으며 하이퍼링크와 검색엔진이 정보 제공,

모바일 인터넷 어플을 위한 플랫폼 제공 등등의 장점을 가짐.

 

HTTP: 클라이언트 프로그램과 서버 프로그램으로 구현됨. 서로 HTTP 메시지로 통신.

웹 페이지는 객체로 구성. (객체 = 단순히 단일 URL로 지정할 수 있는 하나의 파일)

대부분의 웹 페이지는 기본 HTML 파일 + 여러 참조 객체로 구성

각 객체의 URL은 객체를 갖고 있는 서버의 호스트 네임과 객체의 경로 이름을 가짐.

웹 브라우저 = HTTP 의 클라이언트      //    웹 서버 = HTTP의 서버

브라우저는 웹 페이지를 보여주고 각종 인터넷 구성 특성을 제공

서버는 URL로 각각을 지정할 수 있는 웹 객체를 가짐.

HTTP = 클라이언트가 서버에게 어떻게 웹 페이지를 요청하는지, 서버가 어떻게 웹페이지를 전송해 주는지 정의.

TCP를 사용하면 TCP가 알아서 데이터의 손실방지나 복구, 데이터 순서 등을 관리해 주기 때문에 

TCP 하위 계층이 하는 일은 따로 걱정할 필요 x

서버는 클라이언트에게 요청 파일을 보낼 때 클라이언트의 상태 정보를 저장하지 않음(= 비상태 프로토콜)

============================================================

각 요구/응답 쌍이 분리된 TCP(비지속) or 모든 요구와 해당하는 응답이 같은 TCP(지속)

비지속 연결 HTTP

서버가 객체를 보낸 후에 각 TCP 연결은 끊어짐.

보통 브라우저는 5~10개의 TCP 연결을 동시에 설정하여 각각 하나의 요청/응답을 처리 하게 함.

RTT(round-trip time)은 패킷 전파 지연, 큐잉지연, 처리 지연 등도 포함함.

연결확인 왕복, 파일 요청 및 전송 왕복. 총 2RTT + 서버가 파일 전송하는 시간

*단점: 각 요청에 새로운 연결을 하면 TCP 버퍼를 할당해 주고 TCP 변수가 클라이언트와 서버 모두에 유지되면

웹서버에 부담을 준다. 거기다 2RTT라는 긴 시간이 필요하다.

지속 연결 HTTP

서버는 응답을 보낸 후에 TCP 연결을 그대로 유지. 전체 웹 페이지를 하나의 지속 TCP 연결을 통해 보냄.

★객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어질 수 있다.(=파이프라이닝)

일정 기간 사용되지 않으면 연결을 닫는다.

다중 요청/응답이 가능하고 각 요청/응답에 우선순위 기법을 적용할 수 있다.

 

HTTP 요청 메시지

일반 ASCII 텍스트로 쓰여있다. 각 줄은 CR과 LF(carriage return & line feed)로 구별.

첫 줄은 요청 라인, 이후 줄들은 헤더 라인이다.

요청 라인 = 방식 필드, URL 필드, HTTP 버전 필드 등으로 구성

*방식 필드: GET, POST, HEAD, PUT, DELETE 등을 나타냄

대부분은 GET 방식으로, 브라우저가 URL 필드로 식별되는 객체를 요청할 때 사용한다.

헤더라인 = 객체가 존재하는 호스트를 명시. 호스트 헤더라인이 제공하는 정보는 웹 프록시 캐시에서 필요.

connection: close 헤더라인을 포함하면 브라우저에서 서버에게 지속 연결 사용을 원하지 않음을 나타냄.

user-agent 헤더라인은 서버에게 요청을 하는 브라우저 타입을 명시함.

Accept-language 헤더라인은 사용자가 객체의 언어를 요구함.

 

요청 메시지의 일반 포맷 [요청라인/헤더라인/공백라인(추가 CF,LF)/개체 몸체]

개체 몸체는 GET방식에선 비어있고 POST방식에서 사용한다.

폼으로 생성한 요구가 반드시 POST 방식을 사용하는 건 x, GET방식을 써서 폼필드를 확장시킨 URL을 만든다.

HEAD방식: GET과 유사하다. HEAD방식의 요청을 받으면 HTTP  메시지로 응답하는데

보통 요청 객체는 보내지 않고 디버깅용도로 사용함.

PUT방식: 웹 서버에 업로드할 객체를 필요로 하는 어플에서 사용.

DELETE방식: 사용자 또는 어플이 웹 서버에 있는 객체를 지우는 것을 허용

 

HTTP 응답 메시지 [초기 상태라인/헤더라인/객체몸체]

상태라인: 버전필드, 상태코드, 해당 상태 메시지라는 3가지 필드를 가짐.

*상태코드: 200 ok 요청완, 400 Bad Request 서버가 요청이해 불가 등

헤더라인: DATE: HTTP 응답이 서버에 의해 생성되고 보낸 날짜와 시간(객체가 생성되거나 마지막 수정된 시간x)

SERVER: 메시지가 특정 웹 서버에 의해 만들어졌음을 나타냄

Last-Modified: 객체가 생성되거나 마지막으로 수정된 시간.(로컬 클라이언트와 네트워크 캐시서버에서 캐싱에 사용)

============================================================

쿠키: 사이트가 사용자를 추적하도록 해줌

HTTP 서버는 상태를 유지x. 사용자를 확인하는 것이 나은 웹사이트들도 있어서 이때 쿠키 사용.

1. HTTP 응답 메시지 쿠키 헤더라인

2. 요청 메시지 쿠키 헤더라인

3. 사용자의 브라우저에 사용자 호스트와 관리를 지속시키는 쿠키 파일

4. 웹사이트 백엔드 데이터베이스

 

ex) 아마존 첫 방문 시 웹서버는 유일한 식별번호를 만들고 이 식별번호로 인덱스 되는 백엔드 데이터베이스 안에

엔트리를 만든다. 사용자의 브라우저에 응답할 때 Set-Cookie 헤더를 포함하여 사용자가 그 응답 메시지를 받으면

브라우저가 관리하는 쿠키 파일에 그 라인을 덧붙인다.(서버의 호스트 네임과 Set-Cookie 헤더 및 식별번호 저장)

사용자가 웹 페이지 재요청 시 브라우저가 쿠키파일을 참조해 그 사이트에 대한 식별번호를 발췌하여 요청 메시지에

쿠키 헤더파일 Cookie를 넣는다. 그럼 웹사이트는 그 요청 메시지에서 Cookie를 받아 사용자에게 적합한 응답

메시지를 보내준다. (= HTTP 위에서 사용자 세션 계층을 생성하는데 이용)

 

웹 캐싱: 원출처의 웹서버를 대신하여 HTTP 요구를 충족시키는 네트워크 개체

자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존

브라우저가 웹 캐시와 TCP 연결 후, 웹 캐시가 객체의 사본을 가지고 있다면 응답 메시지를 보내고, 없다면

원출처의 서버로 TCP 연결을 설정하여 거기로 HTTP 요청을 보냄. 원출처에서 응답을 받은 웹캐시는 객체를

로컬 저장장치에 복사한 후 클라이언트한테 응답 메시지와 객체의 사본을 보내줌(캐시가 서버, 클라이언트 역할 모두 함)

- 클라이언트의 요구에 대한 응답 시간을 줄임.

- 한 기관에서 인터넷으로 접속하는 링크상의 웹 트래픽을 대폭 줄이고 인터넷 전체의 웹트래픽도 실질적으로 줄여줌.

- 콘텐츠 전송네트워크(CDN): CDN은 인터넷 전역을 통해 지역적으로 분산된 캐시를 설치(트래픽 지역화)

 

조건부 GET

웹캐싱은 캐시가 로컬 저장소에서 사본으로 날라오는 거라서 실제 원출처에 있는 객체는 업데이트된 상태일 수도..

조건부 GET을 통해 HTTP는 모든 객체들이 최신의 것인지를 확인한다.

GET + IF-Modified-Since: 헤더를 포함하여 조건부 GET을 만든다.

브라우저가 웹캐시에게 재요청을 할 때, 웹 캐시는 본 서버에게 IF-Modified-Since 헤더를 붙이고,

첫 요청 때 받았던 Last-Modified 시간을 첨부하여 그 이후로 객체가 업데이트된 적 있는지 확인한다.

바뀐 적 없으면 본서버가 웹 캐시에게 304 Not Modified라는 상태 메시지와 함께 빈 개체 몸체를 보내어

바뀐 적 없으니 너가 가지고 있는 사본을 클라이언트에게 줘도 됨을 알린다.

2.3 인터넷 전자메일

비동기적인 통신 매체. 첨부된 메시지, 하이퍼링크, HTML 포맷 텍스트, 내장 사진

사용자 에이전트/메일서버/SMTP

A가 메시지 작성- 메일서버 - 출력 메시지 큐에 들어감 - 수신자 메일서버 메일박스 도착

B가 메시지 읽으려면 - 메일서버에 있는 메일박스에서 가져옴

B의 서버가 고장 나서 전달할 수 없다면 A서버는 그 메시지를 메시지 큐에 보관하고 나중에 재시도(30분마다)

 

SMTP: TCP의 신뢰적인 데이터 전송 서비스 이용. 클라이언트와 서버 모두가 모든 메일 서버마다 수행됨.

메일 메시지의 몸체는 단순한 7비트 ASCII여야 한다는 단점이 있다.

이진 멀티미디어를 보내기 전에 ASCII로 바꿨다가 다시 원래 메시지로 바꾸는 ,, 불편함.

1. 클라이언트 SMTP는 서버 SMTP의 25번 포트로 TCP 연결을 설정. 핸드셰이킹 수행

2. 클라이언트는 TCP 전송 서비스에 의존하여 메시지 보냄. 지속 연결을 사용.

HELO: 클라이언트 호스트네임 소개 / MAIL FROM: 송신자 전자메일 주소 / RCPT  TO: 수신자 메일 주소

DATA랑 .으로 메시지의 시작과 끝을 나타내어 메시지 전달. 종료 시 QUIT

 

HTTP와 SMTP 비교

공통점: 한 호스트에서 다른 호스트로 파일전송. 모두 지속 연결 사용

차이점: 1. HTTP는 PULL 프로토콜로 서버에 올라간 정보를 사용자가 편의에 의해 가져옴. 즉 파일을 받을 호스트가

서버 쪽으로 먼저 초기화(연결함). 반면 SMTP는 PUSH프로토콜로 송신 메일 서버가 TCP 연결 먼저 초기화해서 보냄.

2. SMTP는 7비트 ASCII 포맷이고 메시지들은 7비트 ASCII로 인코딩 돼야 함.

3. HTTP는 자신의 응답 메시지에 각 객체를 캡슐화하는 반면 메일은 모든 메시지의 객체를 한 메시지로 만든다.

============================================================

메일 접속 프로토콜

컴퓨터를 맨날 켜놓을 순 없기 때문에 사용자는 로컬 pc에서 사용자 에이전트를 수행하고

공유 메일 서버(대학, 회사  등)에 저장된 메일박스에 접근한다.

B의 에이전트는 결국 B의 메일서버에서 메시지를 PULL 해야 하는데, SMTP는 기본적으로 PUSH 프로토콜이라..

다른 메일 액세스 포로토콜이 필요한 상황이다.[수신자 메일 서버 -> 수신자 사용자 에이전트를 위한  프로토콜]

POP3

사용자 에이전트가 메일 서버의 포트 100번으로 TCP열 때 시작. 인증, 트랜잭션, 갱신 기능

인증: 메일을 다운로드하는 사용자 인증 위해 이름과 비밀번호 보냄

트랜잭션: 사용자 에이전트가 메시지 가져오고, 삭제를 위해 메시지에 표시. 통계 얻기 등.

갱신: 클라이언트가 POP3 세션 끝내는 QUIT 명령 이후에 삭제 표시된 메시지를 삭제.

클라이언트 명령에 대해 서버는 Ok또는 -ERR로 응답. 인증 이후, 사용자 에이전트는 list, retr, dele, quit 중 명령 내림

POP3 서버는 세션 사이의 상태 정보를 전달하지 않아 구현이 간편함.

IMAP

원격 폴더 생성 또는 폴더에 메시지 할당하는 수단을 POP3는 안 해줘서 IMAP 사용

IMAP 서버가 폴더에 각각의 메시지를 연결. 첫 메시지- 수신자의 INBOX 폴더에 연결.

폴더 생성하고 다른 폴더로 메시지 옮기는 명령 등을 제공/ 대신 IMAP 세션을 통해 사용자 정보를 유지해야 함.

사용자가 메시지의 구성요소를 얻을 수 있게 함.(메시지 헤더만을 얻거나, 멀티파트 MIME 메시지 일부만 얻는 등)

웹 기반 전자메일

사용자 에이전트 = 일반 웹 브라우저, 사용자는 HTTP를 통해 메일 서버에 있는 원격 메일 박스와 통신.

HTTP 프로토콜로 메일서버-브라우저로  전달해줌.(대신 메일 서버 간에서의 통신은 여전히 SMTP 사용)

2.4 DNS- 인터넷의 디렉터리 서비스

호스트네임: 인터넷 호스트에 대한 하나의 식별자

-알파뉴메릭 문자로 구성되어 라우터가 처리하는데 어렵기 때문에 IP주소로 식별하기도 함.

사람은 호스트네임 식별자를, 라우터는 IP주소를 좋아함.

 

DNS: 호스트네임을 IP주소로 변환해 주는 디렉터리 서비스

-DNS 서버들의 계층구조로 구현된 분산 데이터베이스

-호스트가 분산 데이터베이스로 질의하도록 허락하는 어플 계층 프로토콜

-서버는 주로 유닉스 컴퓨터, 프로토콜은 UDP 상에서 수행, 포트번호 53

-다른 어플 프로토콜들이 HTTP, SMTP, FTP 등 사용자가 제공한 호스트네임을 IP주소로 변환하기 위해 사용

1. 같은 사용자 컴퓨터는 DNS 어플의 클라이언트 측을 수행

2. 브라우저는 URL로부터 호스트네임을 추출하고 이를 DNS 어플 클라이언트 측에 넘김

3. DNS 클라이언트는 DNS 서버로 호스트네임을 포함하는 질의를 보냄

4. DNS 클라이언트는 호스트네임에 대한 IP주소를 가진 응답을 받음

5. 브라우저가 IP주소 받으면 그 주소와 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결 초기화

DNS를 사용하면 물론 추가 지연이 발생한다. 다만 가까운 DNS서버에 캐시 돼있기 때문에 괜찮다.

 

DNS 추가기능

호스트 엘리어싱: 복잡한 호스트네임을 가진 주소는 하나 이상의 별명을 가질 수 있는데,

별칭 호스트네임은 정식 호스트네임보다 대체로 기억하기 쉽다.

별칭 호스트네임에 대한 정식 호스트네임을 얻기 위해서도 DNS를 사용한다.

메일 서버 엘리어싱: 핫메일 서버의 호스트네임은 정식 호스트네임이 복잡할 수 있기 때문에 마찬가지로

별칭 호스트네임에 대한 정식 호스트네임을 얻기 위해 메일 어플을 수행한다.

부하 분산: 중복 웹 서버 같은 중복 서버 사이에 부하를 분산하기 위해서도 DNS를 사용한다.

ex. 구글의 google.com 같은 인기 있는 사이트는 여러 서버에 중복돼 있어서 각 서버가 서로 다른 종단시스템에서

수행되고 서로 다른 IP주소를 갖는다. 중복 웹서버는 여러 IP주소가 하나의 정식 호스트네임과 연관되고,
DNS 데이터베이스가 이 IP주소의 집합을 가지고 있기 때문에 이를 순환 방식으로 보내면 트래픽 분산이 가능하다.

 

서버고장, 트래픽 양, 먼 거리의 중앙 집중 데이터베이스, 유지관리 측면에서

단일 DNS 서버가 모든 질의 클라이언트에 응답할 수 없기 때문에 DNS는 분산 설계된다.

분산 계층 데이터베이스

루트 DNS서버- 최상위 레벨 도메인 네임(TLD) DNS서버- 책임 DNS서버

루트 DNS서버: 400개 이상의 루트 DNS 서버로, 대부분 북미 지역에 위치

TLD DNS서버: com, org, net, edu 같은 상위레벨 도메인, kr, uk, fr, ca 같은 국가 단위 상위 레벨 도메인 관리

책임 DNS서버: 인터넷에서 접근하기 쉬운 호스트를 가진 모든 기관의 책임 DNS 서버는 IP주소로 매핑하는

공개적인 DNS레코드를 제공. 대학이나 큰 기업들은 자신의 기본 책임 DNS와 보조책임 DNS 서버를 유지 및 구현

 

로컬 DNS 서버

서버들의 계층구조에 엄격하게 속하진 x. ISP들은 로컬 DNS를 가지며 호스트가 ISP에 연결될 때

그 ISP는 로컬 DNS서버로부터 IP주소를 호스트에게 제공한다.(4장에서 기술할 DHCP)

윈도우나 유닉스 네트워크 상태 창에서 로컬 DNS 서버의 IP주소를 쉽게 결정 가능하다.

보통 주거지역 ISP가 몇 개의 라우터 범위 안에서 호스트와 연결돼 있기 때문에

호스트가 DNS질의를 보내면 프록시로 동작하는 로컬 DNS서버에 전달되고

로컬 DNS 서버가 이 질의를 DNS 서버 계층으로 전달한다.

 

요청 호스트 → 로컬 DNS서버 → 루트 DNS 서버 질의 → 루트 DNS서버 응답 → TLD 서버 질의

→ TLD 서버 응답 → 책임 DNS 서버 질의 → 책임 DNS 서버 응답 → IP 주소 받음 (총 8회)

이런 경우에 만약 TLD 서버가 책임 DNS를 모르고 있다면 중간 DNS 서버가 로컬 DNS 서버한테 호스트네임을

뭉텅이로 주고, 로컬 DNS 서버가 책임 DNS서버에 질의하는 순서를 거쳐야 된다.

TLD 서버 응답 → 로컬 서버가 중간 DNS에게 질의 → 중간 DNS가 뭉텅이 응답을 로컬에게

→   로콜 서버가 책임 DNS 서버 질의 (빨간색 화살표 2회 추가, 총 10회)

[요청 호스트~ 로컬 DNS 서버까지 재귀적, 로컬 DNS 서버~ 계층 DNS들 간에는 반복적 질의]

 

DNS 캐싱

질의 사슬에서 DNS 서버가 DNS 응답받았을 때 로컬 메모리에 응답에 대한 정보를 저장.

아니면 로컬 DNS서버에서 TLD 서버 IP주소를 저장하면 루트 DNS는 우회가능

 

DNS 레코드

자원 레코드: DNS 분산 데이터베이스를 구현한 DNS 서버들이 호스트네임을 IP주소로 매핑하기 위한

자원 레코드를 저장. (Name, Value, Type, TTL) 4개의 튜플로 구성됨.

*TTL = 자원 레코드 생존 기간

Type = A/Name = 호스트네임, value= 호스트네임에 대한 IP 주소

(relay1.bar.foo.com, 145.37.03.126, A)

Type = NS/Name = 도메인, value = 도메인 내부의 호스트에 대한 IP주소를 얻을 책임

DNS 서버의 호스트네임.(foo.com, dns.foo.com, NS)

Type = CNAME/Name = 별칭 호스트네임, value = 정식 호스트네임

(foo.com, relay1.bar.foo.com, CNAME)

Type = MX/Name = 별칭 호스트네임, value = 메일 서버의 정식 이름

(foo.com, mail.bar.foo.com, MX)

 

어떤 서버가 한 호스트네임에 대한 책임 서버면 그 호스트 네임에 대한 Type A레코드를 가지고 있겠네.

책임 서버가 아니라면 Type NS레코드를 가지고 있을 거고,

(NS 레코드의 value 쪽에 DNS서버의 IP주소를 제공하는) Type A 레코드도 가지겠네.

 

DNS 메시지

헤더 영역: 첫 12바이트, 질의를 식별하는 16비트 식별자(응답 메시지에 복사되어 일치를 식별)

플래그 필드(질의=0,응답=1로 구분하는 1비트짜리 질의응답 플래그, 질의 이름에 대하여 책임서버일 때

응답 메시지에 설정되는 1비트 책임 플래그, DNS서버가 레코드 없을 때 재귀적 질의를 수행하기를 원하는

1비트 재귀요구 플래그, 재귀가능여부를 나타내는 1비트 재귀가능 플래그)

질문 영역: 현재 질의에 대한 정보 / 질의되는 이름필드, 이름에 대해 문의되는 질문 타입 필드

답변 영역: 원래 질의된 이름에 대한 자원 레코드. 여러 개의 RR을 보낼 수 있음(호스트가 여러 IP가지면)

책임 영역: 다른 책임 서버의 레코드 포함

추가 영역: 다른 도움이 되는 레코드 포함(ex. 메일 서버의 정식 호스트네임에 대한 IP주소 제공하는 A레코드)

 

nslookup 프로그램으로 DNS 질의 메시지를 DNS 서버로 보낼 수 있다.

 

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

도메인 네임을 등록기관에 등록, 등록기관은 도메인 네임의 유일성을 확인한 뒤 데이터베이스에 넣고

약간의 요금을 받음. 등록기관에 주책임 서버와 부책임 서버의 이름 및 IP주소를 제공해야 함.

DNS 메시지를 통해서도 데이터베이스에 올릴 수 있도록 DNS 프로토콜에 UPDATE 선택사양도 존재.

2.5 P2P 파일 분배

P2P파일 분배에서 각 피어는 수신한 파일의 임의의 부분을 다른 피어들에게 재분배할 수 있어서

서버의 분배 프로세스를 돕고 트래픽을 감소시키는데 도움을 준다.

 

P2P고유의 자가 확장성

일단 하나의 피어에는 파일의 전체 비트를 보내야 되니까 최소 분배 시간은 F/us

가장 낮은 다운로드 속도를 가진 피어 때문에 최소 분배 시간은 F/d min

각 피어들이 업로드를 도와준다 치면 NF/(us+ u1+ u2+ u3...uN) 

위 셋 중에 가장 큰 값이 하한선. P2P 구조는 최소 분배시간이 클라이언트-서버구조보다 항상 작지는 않다.

 

비트토렌트

모든 피어들의 모임 = 토렌트 피어들은 서로에게서 같은 크기의 청크를 다운

트랙커라고 부르는 기반구조 노드를 가짐.

토렌트 가입 → 트랙커에 자신 등록, 주기적으로 자신이 토렌트에 있음을 알림 → 트랙커가 토렌트에 참여한 피어 추적 → 트랙커가 새로운 피어에게 기존 피어들의 부분집합만큼의 IP주소를 새로운 피어에게 보냄 → 새로운 피어는 그 리스트에 있는 모든 이웃피어들과 TCP 연결을 설정 → 몇몇 피어가 떠나고 몇몇 피어는 이 새로운 피어와 연결됨.. (반복)

→ 임의의 시간에 각 피어는 어떤 청크는 가지고, 없는 청크도 있겠지?

그래서 이웃피어들에게 청크 리스트를 요구해서 본인이 없는 청크를 가진 피어한테 청크를 요구

 

그럼 여기서

 

이웃피어에게 어느 청크를 요구할 것인가? 이웃 중 누구에게 요구할 것인가?

어느 청크를 요구할 것인가? → 가장 드문 것 먼저(rarest first)

누구에게 요구할 것인가? → 현명한 교역 알고리즘(가장 빠른 속도로 나에게 주는 이웃한테)

계속해서 이웃에 대해 본인이 비트를 수신하는 속도를 측정하고, 가장 빠르게 전송해 주는 4개의 피어를

결정해서 그 피어들에게 청크를 보냄으로써 보답. 매 10초마다 4개의 피어 집합을 수정함(=활성화된 피어들)

30초마다 하나의 피어를 추가로 선택하여 청크를 보내는데(= 낙관적으로 활성화된 피어)

본인은 이 피어의 4개 업로더 중 하나가 될 수 있고, 이 피어가  충분히 높은 속도로 보내주면 활성화시켜버림

(30초마다 임의의 새로운 교역 파트너와 교역하여 우수한 파트너를 찾는다)

이 5개의 피어들을 제외한 이웃 피어들은 비활성화되어있다.

 

미니청크, 파이프라이닝, 무작위 우선 선택, 마지막 게임모드, 안티스너빙 등의 기술도 있다...

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

인터넷 비디오

서버에 저장돼 있다가 온디멘드로 요청받으면 송신

4K스트리밍은 10 Mbps 이상의 비트 전송률을 보임.

스트리밍 비디오에선 평균 종단 간 처리량이 중요. 네트워크는 압축된 비디오의 전송률 이상의

스트리밍 어플에 대한 평균 처리량을 제공해야 끊김이 없음

 

HTTP 스트리밍

HTTP 서버 내의 특정 URL을 갖는 파일로 HTTP 스트리밍 비디오 저장

사용자가 시청을 원하면 TCP 연결을 설립해서 해당 URL에 대한 HTTP GET요청

클라이언트 어플 버퍼에서 주기적으로 비디오 프레임을 가져와서 프레임을 압축해제한 다음

사용자 화면에 표시. 클라이언트마다 가용 대역폭 차이가 있는데 똑같이 인코딩 된 비디오를 전송받는다는

단점을 가짐 그래서 DASH(HTTP기반 스트리밍) 사용

 

DASH(Dynamic Adaptive Streaming over HTTP)

비디오는 여러 개의 서로 다른 버전으로 인코딩 되어 버전마다 비트율과 품질 수준이 다름

클라이언트는 자기 컨디션에 따라 높은 버전, 낮은 버전을 청크 단위로 GET 요청함.

각 비디오 버전은 HTTP 서버에 서로 다른 URL을 가지고 저장됨. HTTP 서버는 비트율에 따른 각 버전의

URL을 제공하는 매니페스트 파일을 가짐. 클라이언트가 매니페스트 파일부터 요청해서 버전을 파악한 뒤

그다음 매번 원하는 버전을 GET 요청 메시지에 URL과 함께 byte-range를 지정하여 요청.

 

CDN

1. 지역적으로 먼 거리 대처(병목 지점의 링크에 의해 종단 간 처리율이 좌지우지되기 때문)

2. 인기 있는 비디오는 여러 번 반복적으로 전송될 것이기 때문

3. 단일 데이터 센터는 한 번의 장애로 전체 서비스가 중단될 수 있기 때문에 위험

이 문제들 때문에 콘텐츠 분배 네트워크(CDN)을 사용. 다수의 지점에 분산된 서버를 운영

CDN은 사설 CDN일수도, 제3자가 운영하는 CDN을 통해 분배될 수도 있다.

서버의 위치에 대한 철학

Enter Deep: 세계 곳곳의 접속 네트워크에 구축해서 서버를 최대한 사용자 가까이에 위치하고자 함

- 지연시간 줄이고 처리율 빨라지겠지만 비용문제..

Bring Home: 적은 수의 핵심 지점에 큰 규모의 서버 클러스터를 구축. ISP에 직접 연결하는 것이 아닌

CDN 클러스터를 IXP라는 인터넷 교환지점에 배치하여 효율성 추구.

- 서버 클러스터 위치 정하고 나면 CDN은 콘텐츠 복사본을 클러스터에 저장하여

인기 있는, 즉 자주 PULL 되는 비디오만 클러스터에 저장하면 됨.

 

사용자가 비디오 보려고 URL에 대한 DNS쿼리를 로컬 DNS 서버에 보냄 

→ DNS 서버는 호스트 이름의 video 문자열을 읽곤 아 얘 비디오네.. 하고 책임 DNS 서버로 보냄 

→ 책임 DNS서버에서 쿼리를 CDN으로 연결하기 위해 IP주소가 아닌 CDN의 호스트이름을 로컬에게 응답.

→ 로컬 DNS가 호스트이름에 대한 쿼리를 CDN의 DNS로 보내고,

→ 그 CDN에서 IP주소를 로컬 DNS에게 응답하여 콘텐츠를 받을 서버가 결정됨

→ 그 서버 IP주소로 로컬이 HTTP GET요청 쏴서 콘텐츠를 받음

 

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

개방형: 클라이언트-서버를 RFC에 정의된 표준 프로토콜로 구현

독점형: RFC 또는 다른 곳에 공식적으로 출판되지 않은 어플 계층 프로토콜을 채택

 

UDP 소캣 프로그래밍

패킷에 목적지 주소(목적지 호스트 IP주소 + 포트번호)를 붙임.

[송신자의 출발지 주소(출발지 호스트 IP주소 + 포트번호)도 붙이긴 하는데 이건 udp 어플리케이션 코드가 아닌

하부 운영체제가 자동으로 실행하는 것..]

클라이언트가 메시지를 전송하기 전에 서버는 프로세스로 수행하고 있어야 함.

 

TCP 소캣 프로그래밍

클라이언트와 서버가 우선 TCP 연결을 설정해야 하기 때문에 클라이언트 소켓주소와 서버 소켓주소를

TCP연결과 연관시킴. 패킷은 서버의 IP주소와 소켓의 포트 번호를 명시하여 three-way 핸드셰이크를 한다.

핸드 셰이킹 동안 프로세스가 서버 프로세스의 출입문(severSocket)을 두드려서 knocking을 서버가 들으면

서버는 새로운 출입문, 즉 클라이언트와 연결된 새로운 소켓(connectionSocket)을 생성한다.

 

client 소켓과 connection 소켓은 파이프에 의해 직접 연결된다.(핸드셰이킹을 통해)

connectionSocket.close()가 실행되어 연결 소캣은 닫아도, severSocket이 열려있으면

다른 클라이언트가출입문 두드려서 수정할 문장을 보낼 수도 있다.

 

 

 

*코드에 대한 리뷰는 컴퓨터 네트워크 과제를 수정하면서 다시 복습할 예정..

객체지향을 다시 공부해서 좀 더 클린한 코드로 바꿀 실력이 되면 그때 git에 업로드 예정