[네트워크] Network | Caching, DNS Record, Peer-to-peer architecture, File-distribution, BitTorrent

 

실제로 DNS는 지연 성능 향상과 네트워크의 DNS 메시지 수를 줄이기 위해 캐싱을 사용한다. DNS 서버가 DNS 응답을 받았을 때 그것을 로컬 메모리에 응답에 대한 정보를 저장할 수 있다. 만약 호스트 네임과 IP 주소 쌍이 DNS 서버에 저장되고 다른 호스트 네임으로부터 같은 질의가 DNS 서버로 도착한다면, DNS 서버는 호스트 네임에 대한 책임이 없을 때조차 원하는 IP 주소를 제공할 수 있다. 

 

 

DNS 분산 데이터베이스를 구현한 DNS 서버들은 호스트 네임을 IP 주소로 매핑하기 위한 Resource Record (RR)를 저장한다. 각 DNS는 하나 이상의 RR를 가진 메시지로 응답한다. 자원 레코드(RR)는 다음과 같은 필드를 포함하는 4개의 투플로 되어있다. Type=A 이면 Name은 호스트 네임이고 Value는 호스트 네임에 대한 IP 주소이다. Type = NS 이면 Name은 도메인이고 Value는 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는 방법을 아는 책임 DNS 서버의 호스트 네임이다. Type = CNAME 이면 Value는 별칭 호스트 네임 Name에 대한 정식 호스트 네임이다. Type = MX 이면 Value는 별칭 호스트 네임 Name을 갖는 메일 서버의 정식 이름이다. 

 

 

 

첫 필드는 질의를 식별하는 16비트 숫자이다. 이 식별자는 질의에 대한 응답 메시지에 복사되어, 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별하게 된다. 플래그 필드에 여러 개의 플래그가 있다. 1바이트의 질의 응답 플래그는 메시지가 질의인지 응답인지를 구별하게 된다.

 

질문 영역은 현재 질의에 대한 정보를 포함한다. 이 영역은 (1) 질의되는 이름을 포함하는 이름 필드와 (2) 이름에 대해 문의되는 질문 타입을 나타내는 타입 필드를 포함한다. 

 

DNS 서버로부터의 응답에서 답변 영역은 원래 질의된 이름에 대한 자원 레코드를 포함한다. 각 자원 레코드에 Type, Value, TTL이 있음을 기억해보자. 응답으로 여러 개의 RR을 보낼 수 있다. 왜냐하면 호스트 네임은 여러 개의 IP 주소를 가질 수 있기 때문이다. 

 

레코드를 어떻게 데이터 베이스에 넣는지가 궁금할 것이다. 만일 우리가 네트워크 유토피아라고 하는 새로운 기업을 설립했다고 가정하자. 당신이 처음으로 하고자 하는 것은 도메인 네임을 등록기관에 등록하는 것이다. 등록 기관은 도메인 내임의 유일성을 확인하고 그 도메인 이름을 DNS 데이터베이스에 넣고 그 서비스에 대해서 당신으로부터 약간의 요금을 받는 상업기관이다. ICANN이 여러 등록기관을 승인해준다. 

 

당신의 도메인 네임을 어떤 등록기관에 등록할 때 등록기관에 주책임 서버와 부책임 서버의 이름과 IP 주소를 등록기관에 제공해야 한다.이름은 dns1.networkutopia.com, IP 주소를 212.212.212.2 라고 하자. 이 두 책임 DNS 서버 각각에 대해 등록기관은 Type NS와 Type A 레코드가 TLD com 서버에 등록되도록 확인한다.

 

 

지금까지 기술한 애플리케이션 (웹, 전자메일, DNS) 모두는 항상 켜져 있는 기반 구조 서버에 상당히 의존하는 클리이언트- 서버 구조를 채택하고 있다. P2P 구조는 항상 켜져 있는 기반구조 서버에 최소한으로 의존한다는 것을 기억해야 한다. 대신 간헐적으로 연결되는 호스트 쌍들이 서로 직접 통신한다. (여기서 피어라고 부름) 피어는 서비스 제공자가 소유하는 것이 아니라 사용자가 제어하는 데스크톱과 랩톱이 소유한다.

 

첫 번째로 살펴볼 것은 파일 분배인데, 애플리케이션은 한 출발지에서 많은 수의 피어에게 하나의 파일을 분배한다. 파일 분배는 P2P에 대한 조사를 시작하기에 좋은 애플리케이션이다. 왜냐하면 P2P 구조의 자기 확장성 (Self scalability)을 잘 보여 주기 때문이다. 

 

 

서버는 파일 복사본을 N 개의 피어 각각에게 전송해야 한다. 따라서 서버는 NF 비트를 전송해야 한다. 서버의 업로드 속도가 Us이기 때문에 파일을 분배하는 시간은 적어도 NF이다. Dmin이 가장 낮은 다운로드 속도를 가진 피어의 다운로드 속도를 나타낸다고 하자. 가장 낮은 다운로드 속도를 가진 피어는 F / Dmin 초 보다 적은 시간에 파일의 모든 F 비트를 얻을 수 없다. 따라서 최소 분배 시간은 적어도 F / Dmin 이다. 

 

이는 클리이언트-서버 구조에 대한 최소 분배 시간에 대한 하한값을 제공한다. 분배 시간은 피어의 수 N에 따라 선형적으로 증가한다. 예를 들어 한 주에서 다음 주까지 피어의 수가 천에서 백만으로 천 배 증가한다면, 파일을 모든 피어들에게 분배하는 데 필요한 시간도 천 배 증가한다. 

 

 

여기서는 각 피어들이 서버가 파일을 분배하는 데 도움을 줄 수 있다. 특히 한 피어가 파일 데이터 일부를 수신할 때, 피어는 자신의 업로드 용량을 그 데이터를 다른 피어들에게 재분배하는데 이용할 수 있다. P2P 구조에 대한 분배 시간을 계산하는 것은 클라이언트-서버 구조의 경우보다 좀 더 복잡하다. 

 

분배가 시작되면 서버만이 파일을 갖고 있다. 서버는 적어도 한 번 접속 링크로 파일의 각 비트를 보내야만 한다. 따라서 최소 분배 시간은 적어도 F/Us이다.

 

클라이언트-서버 구조와 마찬가지로 가장 낮은 다운로드 속도를 가진 피어는 F / dmin 초이다. 적은 시간 안에 파일의 모든 F 비트를 얻을 수 없다. 따라서 최소 분배 시간은 적어도 F/Dmin 이다. 

 

마지막으로 시스템의 전체 업로드 용량은 전체적으로 서버의 업로드 속도와 각 피어들의 업로드 속도를 더한 것이다. N 개 피어들 각각에게 F 비트를 전달해야만 한다. U total 보다 더 빠른 속도로 할 수 없다. 따라서 최소 분배 시간은 적어도 NF/(us + u1 + ... + un) 이다.

 

 

 

P2P 구조를 가진 애플리케이션의 자가 확작성을 알 수 있는 그래프이다.

 

 

비트 토렌트는 파일 분배를 위한 인기 있는 P2P 프로토콜이다. 용어로 모든 피어들의 모임을 토렌트라고 부른다. 토렌트에 참여하는 피어들은 서로에게서 같은 크기의 청크(Chunk)를 다운로드한다. 일반적인 청크의 크기는 256 킬로바이트이다. 일단 한 피어가 전체 파일을 얻으면, 토렌트를 떠날 수 있거나 혹은 토렌트에 남아서 다른 피어들로 청크를 계속해서 업로드할 수 있다.

 

 각 토렌트는 트랙커라고 부르는 기반구조 노드를 갖고 있다. 한 피어가 토렌트에 가입할 때 트랙커에 자신을 등록하고 주기적으로 자신이 아직 토렌트에 있음을 알린다. 이러한 방식으로 트랙커는 토렌트에 참여하는 피어들을 추적한다.

 

 

 

새로운 피어가 토렌트에 가입할 때 트랙커는 참여하고 있는 피어 집합에서 임의로 피어들의 부분 집합을 선택하여 이들 50개 피어ㅊ들의 IP 주소를 앨리스에게 보낸다. 이 피어들의 리스트를 얻고 나서, 앨리스는 이 리스트에 있는 모든 피어들과 동시에 TCP 연결을 설정한다. 앨리스가 성공적으로 TCP 연결을 설정한 모든 피어들을 '이웃 피어' (Neighbors) 라고 부르자. 시간이 지남에 따라 이들 피어 중 일부는 떠나고 다른 피어들이 앨리스와 TCP 연결을 시도한다. 그래서 피어의 이웃 피어들은 시간에 따라 변동한다.

 

 

주기적으로 앨리스는 이웃 피어들 각각에게 그들이 갖고 있는 청크 리스트를 요구한다. 만약에 앨리스가 L개의 다른 이웃을 갖고 있다면, 그녀는 L개의 청크 리스트를 얻을 것이다. 이를 바탕으로 앨리스는 지금 갖고 있지 않은 청크에 대해 요구한다. 그렇다면 이웃으로부터 어떤 청크를 먼저 요구할 것인가? 그리고 이웃들 중 어느 피어에게 청크를 요청할 것인가? 어는 청크를 요청할 것인가를 결정하는 데 있어, 앨리스는 가장 드문 것 먼저 (Rarest First) 라고 하는 기술을 사용한다. 

 

어느 요청에 Alice 가 반응하는 가를 결정하기 위해 Trading 알고리즘을 사용한다. 기본 아이디어는 앨리스가 가장 빠른 속도로 그녀에게 데이터를 제공하는 이웃에게 우선순위를 주는 것이다. 앨리스는 계속해서 그녀가 비트를 수신하는 속도를 측정하고 가장 빠르게 전송하는 4개의 피어들을 결정한다. 그러고 나서 그녀는 이 4개의 피어들에게 청크를 보냄으로써 보답한다. 매 10초마다 그녀는 속도를 재계산하고 4개의 피어 집합을 수정한다. 그리고 중요한 것은 30초마다 그녀는 임의로 하나의 피어를 추가로 선택하여 그것에게 청크를 보낸다. 임의로 선택된 피어를 밥이라고 하자. 비트토렌트 용어로 밥은 낙관적으로 활성화 (Optimistically Unchoke) 되었다고 한다.