IPFS 게이트웨이의 실용적인 설명

HOME

IPFS 뉴스

IPFS 게이트웨이의 실용적인 설명 – 첫번째

이은혜 기자
|
입력 2022-06-14 10:28
|
수정 2022-06-14 10:28

▲IPFS 게이트웨이의 실용적인 설명 – 첫번째

IPFS은 파일과 웹사이트를 저장하고 접근하기 위한 피어투피어 프로토콜이다. 분산형 피어투피어 프로토콜로서, 그것은 인터넷의 기초를 이루는 HTTP 프로토콜과는 근본적으로 다르다.

IPFS는 유서 깊은 HTTP 프로토콜에 비해 상대적으로 새로운 프로토콜이며 서로 다른 절충안이 있다. 이 블로그 포스트 시리즈의 목표는 IPFS의 핵심 개념을 이해하고 HTTP를 사용하여 IPFS 네트워크의 많은 이점을 얻을 수 있도록 지원하는 IPFS HTTP 게이트웨이를 소개하는 것이다.

이 블로그 게시물은 2부작 시리즈 중 첫 번째이다.

1부: 널리 사용되는 클라이언트-서버 모델의 문제, 피어 투 피어 네트워킹 및 콘텐츠 어드레싱을 통해 IPFS가 이러한 문제에 어떻게 대처하는지, IPFS와 HTTP(S) 간의 관계, 마지막으로 IPFS HTTP 게이트웨이에 대한 간략한 소개에 대해 알아본다.
2부: 실제 애플리케이션에서 IPFS 게이트웨이를 사용하기 위한 실용적인 팁(예: IPFS 네트워크의 CID 액세스 성능 및 안정성 향상, IPFS 게이트웨이 해결 스타일, 캐싱, 고정, 고정 서비스, DNS와의 통합, 자체 IPFS 노드 및 게이트웨이 실행)을 배우게 된다.

IPFS의 핵심 개념에 이미 익숙하고 IPFS 게이트웨이 사용에 대한 실용적인 가이드에 관심이 있다면 블로그 시리즈의 2부를 기다리면 된다.

참고: 블로그 게시물은 HTTP를 사용하여 간략하게 HTTP와 HTTPS를 모두 참조하고 모든 프로덕션 응용 프로그램에서 HTTPS를 사용해야 한다고 가정한다.

클라이언트-서버 모델의 과제

일반적으로 웹 사이트에 액세스할 때 브라우저는 몇 가지 프로토콜을 사용하여 웹 사이트를 로드한다.

첫째, DNS는 브라우저에서 서버의 IP 주소를 찾는 데 사용된다.
둘째, HTTP는 서버에서 웹 사이트를 요청하는 데 사용된다.

이러한 상호 작용은 브라우저가 HTTP 및 DNS 서버와 상호 작용하는 클라이언트인 클라이언트-서버 모델의 특징이다.

클라이언트-서버 모델이 인터넷의 주요 모델이었지만, 근본적으로 중앙 집중화되어 있으며 복원력, 게이트키퍼에 대한 의존도, 단일 실패 지점을 희생해야 한다.

실질적으로 클라이언트-서버 모델의 공통적인 문제는 서버 운영자에게 컨텐츠의 가용성을 보장할 모든 책임을 묻는다는 것이다.

예를 들어 NASA 웹 사이트에서 우주비행사 제시카 왓킨스(Jessica Watkins)의 이미지의 다음 URL을 열 때 NASA 웹 사이트를 호스팅하는 AWS 서버에 의존한다.

서버가 다운되거나 연결할 수 없는 경우 이미지에 액세스할 수 없다.

또한 HTTP 프로토콜은 다른 서버에 이미지를 요청하는 방법을 지정하지 않으므로 원본 서버가 이미지를 호스트할 경우에만 파일을 사용할 수 있다.

빅 클라우드

그렇다면 AWS, GCP, Azure 등과 같은 대형 클라우드 제공업체 중 하나를 사용하는 것은 어떨까?

많은 웹 사이트, 앱 및 플랫폼이 이러한 클라우드에 배포되어 여러 서버에 배포하고 세부 정보를 상화하여 중복성과 고가용성을 제공합니다.

문제는 클라우드 공급자가 제공하는 독점 고급 추상화(CDN 및 스토리지 서비스) 중 상당수가 오픈 소스도 아니고 표준화도 아니라는 점이다. 이에 따라 공급업체에 종속되어 고객이 한 클라우드 서비스에서 다른 클라우드 서비스로 이동하기가 어렵다.

또 다른 과제는 높은 수준의 클라우드 솔루션이 프로토콜 계층에 구현되지 않아 서로 다른 클라우드 제공업체 간에 상호 운용성이 전혀 없는 벽이 있는 정원을 만드는 것이다.

또한, 빅 클라우드의 시장 집중은 정전이 엄청난 폭발 반경을 가져 수천 개의 사이트와 서비스에 영향을 미칠 수 있음을 의미한다; 어떤 경우에는 사람의 실수로 인해 일어난다.

실제로, 빅 클라우드는 복원력과 상호 운용성을 희생하여 편리함을 제공합니다. 서버를 항상 사용할 수 있다고 가정하면 클라이언트-서버 모델의 관점에서 생각할 수 있으며, 실제로 서버가 중복을 달성하는 방법에 대한 세부 정보와 복잡성을 추상화할 수 있습니다.

여기서 피어투피어 네트워킹이 등장한다.

IPFS를 통해 클라이언트-서버에서 피어-투-피어로 전환

IPFS의 핵심 특성 중 하나는 피어 투 피어 네트워크라는 것이다. 일반적으로 단일 서버에서 많은 클라이언트를 사용하는 클라이언트-서버 모델과 달리 피어 투 피어 모델에서는 IPFS 네트워크의 모든 컴퓨터(일반적으로 피어)가 서버의 모자를 모두 사용한다. 즉, 이 모든 IPFS 피어가 네트워크의 생산적인 구성원이 될 수 있음을 의미한다.

참고: 이 문서에서는 IPFS 소프트웨어를 실행하는 컴퓨터를 가리키기 위해 피어(peer)와 노드(node)라는 용어를 같은 의미로 사용한다.

다이어그램에 표시된 것처럼 클라이언트가 연결하는 네트워크의 중심에 있는 단일 서버에 의존하는 대신 각 피어가 여러 피어에 연결된다. 이 jpg 파일은 세 개의 피어에 저장되므로 세 개의 노드 중 두 개가 중단될 수 있으며 이 파일은 네트워크에서 계속 액세스할 수 있다. 또한 네트워크에서 다운로드한 후에는 수많은 피어가 jpg 파일의 공급자가 된다.

요약하면 IPFS를 사용하면 노드가 인터넷 연결 및 디스크 공간과 같은 리소스를 풀링하고 파일의 가용성을 탄력적으로 분산시킬 수 있다.

위치 주소 지정 대 콘텐츠 주소 지정

IPFS에서 데이터는 웹의 클라이언트-서버 모델에서 흔히 볼 수 있는 위치 주소가 아닌 콘텐츠 주소가 지정된다. 두 접근 방식의 차이를 이해하기 위해, NASA의 이미지가 있는 예로 돌아가 보았다.

NASA에서 로드된 이미지의 예에서는 위치 주소 지정을 사용하여 URL 형식으로 이미지를 가져왔다. URL에는 이미지를 찾고 가져오는 모든 위치 정보가 포함되어 있다.

체계: protocol https.
호스트 이름: 서버의 IP 주소에 매핑된 DNS 이름 www.nasa.gov.
서버의 위치 경로: /syslog/default/files/sails/image/04_iss067e033423.jpg

위치 지정과 관련된 문제는 많다. 우리는 모두 링크가 변경되었거나 서버가 더 이상 파일을 호스팅하지 않기 때문에 데드링크에 의해 갑자기 인터넷 토끼굴로 들어가는 경험을 했다.

IPFS와 같은 피어 투 피어 네트워크에서는 지정된 파일이 여러 IPFS 노드에서 호스팅될 수 있다.

여기서 컨텐츠 주소 지정이 유용하다. IPFS를 사용하면 시스템에 저장된 모든 파일이 콘텐츠 식별자 또는 CID로 알려진 콘텐츠의 암호화 해시에 의해 처리된다. CID는 해당 파일에 고유한 문자와 숫자의 긴 문자열이다.

CID와 관련하여 기억해야 할 세 가지 중요한 사항이 있다.

파일(폴더의 경우 파일 트리)에 대한 모든 차이(단일 비트)는 다른 CID를 생성한다. 이 속성을 불변성이라고 한다.
두 개의 서로 다른 IPFS 노드에 동일한 콘텐츠가 추가되면 동일한 매개변수가 제공되는 동일한 CID가 생성된다.
단일 CID는 단일 파일 또는 파일 폴더(예: 정적 웹 사이트)를 나타낼 수 있다. 이 속성은 "turtles all the way down”으로 알려져 있다.

이 다이어그램은 네트워크에서 두 개의 서로 다른 파일이 어떻게 보이는지 보여준다. 빨간색 JPEG는 두 노드에 호스트 된 하나의 CID를 나타내며 보라색 JPEG는 두 개의 다른 노드에 호스트 되는 다른 CID를 나타낸다.

참고: 크기에 따라 IPFS는 효율성을 위해 각각 고유한 CID가 있는 여러 블록으로 단일 파일을 청크(분할)할 수 있다. 그런데도 파일에는 루트 CID도 포함되어있다. IPLD 탐색기를 사용하여 NASA 이미지가 어떻게 보이는지 탐색할 수 있다.

모든 IPFS 노드에 CID를 요청할 수 있다.

콘텐츠 주소 지정의 이점 중 하나는 네트워크에 제공하는 노드가 하나 이상 있는 한 모든 IPFS 노드에서 CID를 검색할 수 있다는 것이다.

예를 들어 IPFS 노드에 없는 CID를 요청하면 해당 노드는 IPFS 네트워크를 검색할 수 있으며, CID를 호스팅하는 다른 도달 가능한 IPFS 노드를 찾으면 해당 노드를 가져와 사용자에게 다시 제공할 수 있다.

IPFS로 말하기

IPFS 네트워크에 저장된 파일을 가져오는 두 가지 주요 방법은 다음과 같다.

시스템 또는 클라우드의 서버에 IPFS 구현 중 하나를 데몬(장기 실행 프로세스)으로 설치하여 IPFS 노드를 실행한다. 노드는 IPFS 피어투피어 네트워크의 구성원이 되고 어떤 데이터를 보유하고 있는지 알리고 데이터 요청에 응답.
HTTP 프로토콜을 사용하여 CID를 가져올 수 있는 IPFS 게이트웨이 사용.

첫 번째 옵션을 사용하면 기본 IPFS 프로토콜을 사용할 수 있다. 후자는 앱 사용자가 IPFS 노드를 실행하지 않을 수 있는 웹 앱과 같이 HTTP를 사용하도록 제한될 수 있는 상황에서 브리지 역할을 한다.

올바른 접근 방식을 선택하는 것은 사용 사례 및 요구 사항에 따라 다르다. 실제로 두 가지 접근 방식을 결합하는 것도 완벽하게 유효하다.

참고: 위의 두 가지 방법 외에도 브라우저 Brave는 내장된 IPFS 노드가 있어 브라우저에서 IPFS 네트워크와 직접 상호 작용할 수 있다. 게다가, js-ipfs는 브라우저에서 실행되는 웹 애플리케이션의 일부로 내장될 수 있는 IPFS 프로토콜의 구현을 위한 길을 열어준다.

IPFS 게이트웨이란

IPFS 게이트웨이는 웹2와 웹3 사이를 변환하여 HTTP와 IPFS를 연결하는 공용 서비스이다.

거의 모든 프로그래밍 언어가 사용할 수 있는 HTTP 프로토콜을 사용하여 IPFS 네트워크에서 CID로 데이터를 요청할 수 있다.

HTTP 요청에서 CID를 전달하여 IPFS 게이트웨이에서 데이터를 요청한다. CID는 특정 데이터의 해시이므로 데이터가 네트워크의 노드에 의해 제공되고 게이트웨이에서 액세스할 수 있는 경우 게이트웨이는 위치와 관계없이 네트워크에서 특정 데이터를 가져올 수 있다.

가장 간단한 형태의 게이트웨이는 CID에 대한 HTTP 요청도 수락하는 IPFS 노드를 실행하는 컴퓨터이다.

일반적으로 IPFS 게이트웨이에 대한 HTTP 요청은 다음 구조를 따른다: https://<gateway-url>/ipfs/<cid

공개 게이트웨이 검사기를 통해 공용 게이트웨이를 찾을 수 있다.

예시

IPFS 게이트웨이를 사용하는 방법을 알아보려면 우주비행사 제시카 왓킨스의 이미지의 CID를 사용하여 다음 게이트웨이 링크를 열어 보면 된다.

IPFS의 핵심 요소를 사용하여 동일한 이미지를 가져올 수 있는 두 가지 게이트웨이, 즉 콘텐츠 주소 지정과 피어 투 피어 네트워킹이다.

이 예에서는 단일 이미지만 요청하지만, CID가 파일의 전체 디렉터리(예: 웹 사이트)가 될 수 있다는 점을 기억해야 한다. IPFS 게이트웨이에서 전체 웹 사이트를 로드할 때는 하위 도메인 게이트웨이 확인 스타일을 사용하여 동일한 원본 정책 위반을 방지하는 것이 좋다.

예를 들어, 경로 확인 스타일: https://ipfs.io/ipfs/bafybeiakks4s3ixictcn3alt45kfalkrotmfqishpgfl72pbnclhmk3rme을 사용하여 IPFS 설명서 웹 사이트(IPFS에도 배포됨)를 로드하는 대신 하위 도메인 확인 스타일 https://<cid>.<gateway-url>을 사용하여 로드한다.

요약

이 블로그 게시물에서는 클라이언트-서버 모델의 과제, IPFS의 기본원리, 즉 피어 투 피어 네트워킹 및 콘텐츠 주소 지정, IPFS 게이트웨이가 어떻게 웹2와 웹3 사이의 브리지 기능을 제공하여 HTTP를 사용하여 IPFS 네트워크를 활용할 수 있는지를 다뤘다.

후속 블로그 게시물에서는 실제 애플리케이션에서 IPFS 게이트웨이를 사용하는 방법, 해상도 스타일, DNS와의 통합, 캐싱, 고정, 디버깅 등에 대한 모든 팁과 요령을 자세히 알아볼 예정이다.

관심이 있는 경우:

IPFS 문서
IPFS 설치
IPFS 포럼
디스코드 또는 매트릭스를 확인하면 된다.

더욱 다양한 정보 및 방송 관련 소식은

공식 SNS 채널을 통해 확인 가능합니다.

이은혜 기자 | [email protected]

댓글 [ 0 ]

댓글 서비스는 로그인 이후 사용가능합니다.

회원가입

로그인

최신순