---
title: "FAQ - Geyser gRPC 스트림"
description: "ERPC - Enhanced Solana RPC Geyser gRPC 스트림에 대해 자주 묻는 질문"
canonical: "https://erpc.global/ko/faq/grpc/general/"
locale: "ko"
---

# FAQ - Geyser gRPC 스트림

## Q. 노드는 어느 리전에 있나요?

현재 다음 리전에서 노드를 운영하고 있습니다.

- Frankfurt (FRA)
- Amsterdam (AMS)
- London (LON)
- New York (NY)
- Tokyo (TY)
- Singapore (SGP)
- Sydney (SYD)

ERPC는 직선 거리가 아니라 실제 라우팅 경로를 기반으로 네트워크 지연 시간을 측정하여, 가장 낮은 지연 시간의 리전을 자동으로 선택합니다. 이 방식은 개별 사용자의 지연 시간을 개선할 뿐 아니라 전체 네트워크 효율을 높이고, 잠재적 공격에 대한 ERPC의 글로벌 복원력을 강화합니다.

사용 환경에서 최적 리전이 자동으로 선택되지 않는 경우 ERPC Web Dashboard를 통해 문의해 주세요.

ERPC Web Dashboard: https://dashboard.erpc.global/ko

## Q. 지연 시간이 9999ms로 표시되고 최적이 아닌 리전이 선택됩니다. 어떻게 해야 하나요?

gRPC 리전 선택을 위해 ERPC는 아래에 나열된 프록시 호스트에서 등록된 IP로 ICMP 지연 시간 프로브를 전송합니다. 나열된 모든 소스 IP에서 들어오는 ICMP 에코 요청을 허용하십시오. 방화벽(ufw, 클라우드 방화벽, 보안 그룹 등)에서 이를 차단하면 측정값이 `9999ms`가 되고 최적이 아닌 리전이 선택될 수 있습니다. 한 리전에 여러 IP가 있는 경우 각각 별도의 프로브 호스트이며, 모두 허용해야 합니다.

[ERPC_PING_SOURCES:grpc]: #
| 리전 | ICMP 소스 IP |
| --- | --- |
| 🇳🇱 Amsterdam | `82.21.43.34`, `151.244.92.36` |
| 🇺🇸 New York | `151.243.244.5` |
| 🇩🇪 Frankfurt | `151.241.178.20`, `151.241.178.34`, `151.241.178.21` |
| 🇬🇧 London | `151.241.65.4` |
| 🇯🇵 Tokyo | `143.20.238.66` |
| 🇸🇬 Singapore | `151.245.186.2` |
| 🛰️ Far Point | `143.20.238.73` |

## Q. IP를 허용 목록에 등록했는데도 연결되지 않습니다. 무엇을 확인해야 하나요?

대시보드에서 선택한 HTTPS 엔드포인트를 사용하세요. HTTPS는 443 포트를 사용하며, 80 포트의 HTTP는 암호화되지 않은 저지연 옵션으로 유지됩니다.

두 전송 방식은 동일한 등록 IP 허용 목록을 사용합니다. 대시보드에서 선택한 엔드포인트를 사용하고 HTTPS는 443, HTTP는 80을 지정하세요.

- HTTPS 엔드포인트: 대시보드에서 선택한 엔드포인트의 443 포트를 사용하세요.
- HTTP 엔드포인트: 대시보드에서 선택한 엔드포인트의 80 포트를 사용하세요.
- 대시보드에 표시된 URL을 `https://` 또는 `http://` 형식으로 사용하세요.

인증은 등록된 IP 주소를 기준으로 합니다. 특정 제품 페이지에서 명시하지 않는 한 `x-token`, `token` 또는 `Authorization` 헤더를 추가하지 마세요.

## Q. 이전에는 WebSocket만 사용했습니다. gRPC를 사용할 수 있나요? 샘플이 있나요?

네. SLV를 사용하면 gRPC를 빠르게 테스트하고 개발을 시작할 수 있습니다.

토큰 없이 테스트할 수 있는 공유 엔드포인트는 다음을 실행하세요.

```bash
slv check grpc --endpoint <YOUR_ENDPOINT> --token none
```

자세한 내용은 [gRPC 빠른 시작 가이드](https://slv.dev/ko/doc/geyser-grpc/quickstart/)를 참고하세요.

## Q. IP 주소를 두 개 등록할 수 있나요?

구독당 하나의 엔드포인트를 사용할 수 있습니다. IP 주소를 두 개 사용하려면 별도의 구독 두 개를 신청해야 합니다.

## Q. 필터 제한이 있나요?

Shared Geyser gRPC에는 하나의 스트림이 다른 ERPC 고객에게 필요한 리소스를 소비하지 않도록 공정 사용 보호 장치가 적용됩니다. 현재 Shared 규칙에서는 범위를 좁힌 블록 요청을 포함해 비어 있지 않은 모든 `blocks` 맵이 거부됩니다. 각 계정 필터에는 `account`, `owner` 또는 지원되는 cuckoo 필터가 포함되어야 하며, `memcmp`나 `dataSize`만으로는 충분하지 않습니다.

거부된 형태를 제거하고 애플리케이션에 필요한 데이터만 구독하세요. 트랜잭션 구독이나 블록 메타데이터로 전체 블록을 받지 않고도 요구를 충족할 수 있는 경우가 있습니다. 정당한 워크로드가 Shared의 형태나 리소스 허용량을 넘는다면 Dedicated Geyser gRPC가 적합하지만, 그렇다고 잘못된 매개변수가 유효해지거나 느린 클라이언트가 고쳐지지는 않습니다.

## Q. 재연결하기 전에 gRPC 오류를 어떻게 수집해야 하나요?

재연결 루프가 덮어쓰기 전에 첫 번째 오류를 보존하세요. 초기 metadata와 trailer에서 gRPC 상태와 메시지를 `x-erpc-error-code`, `x-erpc-error-reason`, `x-erpc-doc-url`과 함께 기록합니다. ERPC가 일시 정지를 지정한 경우에는 `x-erpc-retry-after-seconds`와 `x-erpc-retry-at`(Unix 초)도 기록하세요.

오류는 `ERPC [STREAM_GUARD_SLOW_READER]: ...`처럼 표시될 수 있습니다. 표시된 오류 전체 또는 코드를 FAQ 검색에 붙여 넣으세요. 정식 설명은 [ERPC gRPC FAQ](https://erpc.global/ko/faq/grpc/general/)에서 확인할 수 있습니다. 연결이 일찍 끝나면 trailer가 전달된다고 가정하지 마세요.

증상으로도 검색할 수 있습니다: 느린 수신, 연결 끊김, 대역폭, 전달 지연, 백로그, 일시 정지, 재시도, invalid argument, resource exhausted, permission denied, IP 등록, 너무 많은 스트림, 전체 블록, 모든 계정.

## Q. 어떤 gRPC 오류가 연결을 일시 정지시키며, 클라이언트는 언제 재연결을 멈춰야 하나요?

일시 정지(pause)는 ERPC가 특정 오류 뒤에 설정하는, 시간이 정해진 기간입니다. 일시 정지가 진행되는 동안 클라이언트는 재연결하면 안 됩니다.

**집계되는 항목.** 다음 오류는 집계되며, 모두 하나의 단계 체계를 공유합니다.

- ERPC가 `ERPC_GRPC_INVALID_ARGUMENT`, `STREAM_GUARD_SHAPE_BLOCKS` 또는 `STREAM_GUARD_SHAPE_ACCOUNTS_ALL`로 거부하는 모든 Subscribe 요청(첫 번째 요청도 포함). 처음 집계된 오류는 경고이며, 일시 정지를 시작하지 않습니다.
- `STREAM_GUARD_SLOW_READER`. 단, 전달 지연(delivery lag)이 ERPC 쪽에서 생긴 경우에는 ERPC가 이를 집계하지 않고 스트림을 닫으며, 오류에는 재시도 시각이 포함되지 않습니다.

다음은 집계되지 않습니다: 재연결 자체, 네 가지 `STREAM_ADMISSION_*` 코드(`STREAM_ADMISSION_LIMIT_REACHED`, `STREAM_ADMISSION_IP_NOT_ADMITTED`, `STREAM_ADMISSION_SOURCE_UNAVAILABLE`, `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE`), 그리고 일시 정지가 진행 중일 때 발생한 집계 대상 오류. 일시 정지 중에 발생한 집계 대상 오류는 일시 정지를 연장하지 않으며 다음 단계로 넘어가지도 않습니다.

**단계.** 집계되는 오류가 발생할 때마다 경고부터 시작하는 다음 순서로 한 단계씩 진행됩니다.

- 경고: 일시 정지 없음.
- 60초 동안 일시 정지.
- 300초 동안 일시 정지.
- 1800초 동안 일시 정지.
- 86400초(24시간) 동안 일시 정지. 이것이 마지막 단계이며, 이 단계에서는 집계되는 오류마다 86400초의 일시 정지가 새로 시작됩니다.

경고 단계에서 다음으로 집계되는 오류가 60초 일시 정지로 넘어가는 것은 그 오류가 경고 후 1시간 이내에 발생한 경우뿐입니다. 경고 후 1시간이 넘게 지나서 발생한 집계 대상 오류는 일시 정지가 없는 새 경고가 되며, 1시간의 기간은 그 새 경고부터 다시 계산됩니다.

마지막으로 집계된 오류 후 60초가 지나기 전에 발생한 집계 대상 오류는 그 오류의 일부로 집계되며, 단계를 진행시키지 않습니다.

**단계가 경고로 돌아가는 시점.** 단계가 한 번 일시 정지를 시작한 뒤에는, 마지막 일시 정지가 끝난 시점부터 집계되는 오류도 일시 정지도 없이 24시간이 지나야만 경고로 돌아갑니다. 그 후 다음으로 집계되는 오류는 일시 정지가 없는 경고입니다. 그 전까지는 다음으로 집계되는 오류가 경고 없이 즉시 다음 단계를 시작합니다.

**송신량 초과(egress) 일시 정지.** `STREAM_GUARD_EGRESS_BUDGET`은 600초로 고정된 별도의 일시 정지를 시작합니다. 이 오류는 단계를 진행시키지 않습니다.

**종료 시각을 확인할 수 있는 곳.**

- 일시 정지를 시작하는 오류에는 `Retry after N seconds.`와 헤더 `x-erpc-retry-after-seconds`, `x-erpc-retry-at`(Unix 초)가 포함됩니다. 경고에는 재시도 시각이 포함되지 않습니다.
- 집계되는 거부된 요청이 일시 정지를 시작하는 요청인 경우, 그 요청의 오류는 원래 코드 대신 `ResourceExhausted (8)` 상태와 함께 `STREAM_GUARD_SHAPE_REJECT_PENALTY`로 반환됩니다.
- 느린 수신(slow-reader) 또는 송신량 초과로 인한 일시 정지 중에 재연결하면 남은 시간과 함께 `STREAM_GUARD_PENALTY_ACTIVE`가 반환됩니다.
- 거부된 요청으로 시작된 일시 정지 중에는 새 연결이 gRPC 상태도 ERPC 코드도 없이 즉시 닫힙니다. 아직 열려 있는 연결의 요청에는 그 연결이 닫히기 전에 `STREAM_GUARD_SHAPE_REJECT_PENALTY`와 남은 시간이 다시 반환될 수 있습니다. 클라이언트는 종료 시각을 다시는 보지 못할 수 있으므로, `x-erpc-retry-at`이 포함된 첫 오류에서 그 값을 저장해야 합니다.

| 코드 | gRPC 상태 | 일시 정지를 시작하거나 단계를 진행시키나요? | 클라이언트가 해야 할 일 |
| --- | --- | --- | --- |
| `ERPC_GRPC_INVALID_ARGUMENT` | `InvalidArgument (3)` | 예. Subscribe 요청을 거부한 경우입니다. 이때는 위 단계에서 집계되는 오류입니다. | 재연결 루프를 멈추고 같은 요청을 다시 보내지 마세요. 확인할 내용은 아래의 해당 코드 항목에 있습니다. |
| `STREAM_GUARD_SHAPE_BLOCKS` | `PermissionDenied (7)` | 예. 위 단계에서 집계되는 오류입니다. | 재연결 루프를 멈추고 같은 요청을 다시 보내지 마세요. 확인할 내용은 아래의 해당 코드 항목에 있습니다. |
| `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` | `PermissionDenied (7)` | 예. 위 단계에서 집계되는 오류입니다. | 재연결 루프를 멈추고 같은 요청을 다시 보내지 마세요. 확인할 내용은 아래의 해당 코드 항목에 있습니다. |
| `STREAM_GUARD_SLOW_READER` | `ResourceExhausted (8)` | 예. 위 단계에서 집계됩니다. 다만 전달 지연이 ERPC 쪽에서 생긴 경우에는 ERPC가 이를 집계하지 않고 스트림을 닫으며, 오류에는 재시도 시각이 포함되지 않습니다. | 재연결 루프를 멈추세요. 확인할 내용은 아래의 해당 코드 항목에 있습니다. 일시 정지가 시작되었다면 `x-erpc-retry-at`의 시각 전에 재연결하지 마세요. |
| `STREAM_GUARD_EGRESS_BUDGET` | `ResourceExhausted (8)` | 예. 위 단계와 별도로 600초의 고정 일시 정지를 시작합니다. | `x-erpc-retry-at`의 시각 전에 재연결하지 마세요. 확인할 내용은 아래의 해당 코드 항목에 있습니다. |
| `STREAM_GUARD_SHAPE_REJECT_PENALTY` | `ResourceExhausted (8)` | 예. 일시 정지를 시작한, 집계되는 거부된 요청입니다. 아직 열려 있는 연결에서는 남은 시간과 함께 다시 반환될 수 있습니다. | `x-erpc-retry-at`의 시각 전에 재연결하지 마세요. 거부된 요청을 수정하고, 바꾸지 않은 채 다시 보내지 마세요. |
| `STREAM_GUARD_PENALTY_ACTIVE` | `ResourceExhausted (8)` | 아니요. 이미 진행 중인 느린 수신 또는 송신량 초과 일시 정지를 알립니다. | `x-erpc-retry-at`의 시각 전에 재연결하지 마세요. |
| `STREAM_ADMISSION_LIMIT_REACHED` | `ResourceExhausted (8)` | 아니요. 시간이 정해진 일시 정지가 없습니다. | 사용하지 않는 스트림을 닫은 뒤 다시 시도하세요. |
| `STREAM_ADMISSION_IP_NOT_ADMITTED` | `PermissionDenied (7)` | 아니요. 시간이 정해진 일시 정지가 없습니다. | 확인할 내용은 아래의 해당 코드 항목에 있습니다. |
| `STREAM_ADMISSION_SOURCE_UNAVAILABLE` | `Unavailable (14)` | 아니요. 시간이 정해진 일시 정지가 없습니다. | 평소처럼 간격을 두고(backoff) 잠시 후 다시 시도하세요. |
| `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE` | `Unavailable (14)` | 아니요. 시간이 정해진 일시 정지가 없습니다. | 평소처럼 간격을 두고(backoff) 잠시 후 다시 시도하세요. |

**클라이언트가 해야 할 일.** 집계되는 오류가 발생하면 재연결 루프를 멈추고, 같은 요청을 다시 보내지 말고, 요청을 수정하세요. 일시 정지 중에는 `x-erpc-retry-at`의 시각 전에 재연결하지 마세요. 거부된 Subscribe 요청은 위 규칙에 따라 집계되며, 재연결은 집계되지 않습니다.

## Q. 느린 수신 측의 연결이 끊길 때 `STREAM_GUARD_SLOW_READER` 오류가 `ResourceExhausted (8)` 상태와 함께 나타나면 무슨 뜻인가요?

ERPC가 이 스트림에서 쓰기 진행이 충분하지 않거나 전달 지연이 생긴 것을 관찰했습니다. 전달 지연만으로는 원인을 특정할 수 없습니다. 네트워크 손실, 실효 대역폭, 호스트 하드웨어, 그리고 애플리케이션의 컨슈머가 따라가고 있는지 확인하세요. 구독하는 데이터를 줄이고, 처리를 수신 루프 밖의 bounded 큐로 옮기세요. bounded 큐는 메모리 사용량을 제어하지만 지속적으로 느린 컨슈머를 해결할 수는 없습니다. ERPC가 재시도 기한을 제공하면 재연결하기 전에 그때까지 기다리세요. 아래의 질문 “gRPC 스트림이 일정한 속도에 머물며 뒤처지는 이유는 무엇인가요?”에서 수신 윈도우와 클라이언트 라이브러리에서 이를 넓히는 방법을 설명합니다.

## Q. gRPC 스트림이 일정한 속도에 머물며 뒤처지는 이유는 무엇인가요?

클라이언트나, 클라이언트와 ERPC 사이에 있는 무언가의 수신 윈도우가 작으면 `STREAM_GUARD_SLOW_READER`로 인한 스트림 끊김과 그 뒤의 일시 정지가 생길 수 있습니다. 이 답변에서는 수신 윈도우가 무엇인지, 수신 윈도우가 스트림을 제한하는지 어떻게 알 수 있는지, 그리고 라이브러리별로 어떻게 넓히는지 설명합니다. 위의 질문 “어떤 gRPC 오류가 연결을 일시 정지시키며, 클라이언트는 언제 재연결을 멈춰야 하나요?”에서 각 단계와 그 길이를 설명합니다.

**수신 윈도우란.** HTTP/2에서 수신 측은 송신 측에, 수신 측이 확인하기 전까지 보낼 수 있는 데이터의 양을 알려 줍니다. 이 양이 수신 윈도우(HTTP/2 flow control window)입니다. 한 번의 왕복에는 최대 윈도우 하나만큼만 실리므로, 속도는 윈도우를 왕복 시간(엔드포인트까지 갔다가 돌아오는 시간)으로 나눈 값 근처에서 더 오르지 않습니다.

**다른 한계.** 윈도우는 스트림별 윈도우와 연결별 윈도우(한 연결의 모든 스트림이 함께 씀) 두 가지가 있으며, 둘 중 작은 쪽이 한계를 정합니다. HTTP/2 사양에서는 두 윈도우 모두 65,535바이트에서 시작합니다. TCP 수신 버퍼(들어오는 데이터를 위한 메모리)도 같은 방식으로 속도를 제한합니다. 중간에 있는 프록시, 로드 밸런서, 게이트웨이, VPN, 사이드카는 각자의 윈도우와 버퍼를 가집니다. 그곳의 윈도우나 버퍼가 작으면, 클라이언트 자체의 윈도우가 커도 스트림의 속도가 묶입니다.

**나타나는 모습.** 체인이 얼마나 바쁘든 스트림 하나의 속도가 거의 같은 값에서 일정하게 유지되고, 전달 지연은 꾸준히 늘어납니다. ERPC가 Frankfurt의 Shared 엔드포인트까지 왕복 시간이 약 6 ms인 곳에서, 실행마다 윈도우만 바꾸어 측정한 결과는 다음과 같습니다.

- 16 KiB 스트림 윈도우: 약 2.7 MB/s에서 일정함(16 KiB를 6 ms로 나눈 값). 전달 지연은 초당 약 0.6초씩 늘어 45초 만에 26초에 이르렀습니다.
- 둘 다 16 MiB: 최대 전달 지연은 14 ms였습니다.

전달 지연이 ERPC 쪽에서 생긴 경우, ERPC는 이를 집계하지 않고 스트림을 닫으며, 오류에는 재시도 시각이 포함되지 않습니다.

**확인 방법.**

1. 스트림의 속도와 전달 지연을 위의 모습과 비교하세요.
2. 왕복 시간을 측정하세요. 스트림의 속도에 왕복 시간을 곱해 윈도우를 추정하세요(2.7 MB/s에 6 ms를 곱하면 약 16 KB).
3. 클라이언트의 두 윈도우 중 하나가 작은 값으로 설정되어 있지 않은지, 또는 자동 증가(라이브러리가 윈도우를 넓히는 기능)가 꺼져 있지 않은지 확인하세요.
4. TCP 수신 버퍼를 확인하세요. Linux에서는 `sysctl net.ipv4.tcp_rmem net.core.rmem_max`를 실행하고, 애플리케이션이 `SO_RCVBUF`를 설정하는지 보세요. 설정하면 자동 크기 조정이 꺼집니다.
5. 중간에 있는 모든 것의 윈도우와 버퍼를 확인하세요.
6. 속도에 상한이 없고 지연만 늘어난다면, 느린 것은 수신 후의 처리입니다. 위의 질문 “느린 수신 측의 연결이 끊길 때 `STREAM_GUARD_SLOW_READER` 오류가 `ResourceExhausted (8)` 상태와 함께 나타나면 무슨 뜻인가요?”에서 수신 루프는 읽기만 하게 하고 무거운 작업을 bounded 큐로 옮기는 방법을 설명합니다.

**라이브러리별 설정.** 예시는 ERPC의 측정과 같이 두 윈도우를 모두 16 MiB로 설정합니다. 여기에 없는 라이브러리라면 HTTP/2 initial window 설정을 찾아보세요.

**Rust, `yellowstone-grpc-client`.** 윈도우를 설정하지 않으면 `GeyserGrpcClient::build_from_shared`는 스트림당 2 MiB, 연결당 5 MiB를 사용합니다. 왕복 6 ms에서 이 기본값은 300 MB/s가 넘는 속도를 허용하므로 스트림을 묶지 않습니다. 윈도우를 직접 설정하려면 builder의 두 메서드를 사용하고 `http2_adaptive_window`는 꺼 두세요. 켜 두면 윈도우가 65,535바이트에서 시작해 16 MiB까지 스스로 커지며, 설정한 값은 무시됩니다.

```rust
// 두 window를 16 MiB로 고정; http2_adaptive_window는 꺼 두세요.
let client = GeyserGrpcClient::build_from_shared(endpoint)?
    .tls_config(ClientTlsConfig::new().with_native_roots())?
    .initial_stream_window_size(16 * 1024 * 1024)
    .initial_connection_window_size(16 * 1024 * 1024)
    .connect()
    .await?;
```

**TypeScript, `@triton-one/yellowstone-grpc` 5.0.1 이상.** 기본값: 스트림당 4 MiB, 연결당 8 MiB, 자동 증가 켜짐. 윈도우는 64 KiB에서 시작해 16 MiB까지 커지므로, 기본값이 스트림을 묶는 경우는 드뭅니다. 크기를 고정하려면 세 번째 인자에 `grpcHttp2AdaptiveWindow: false`를 넣어 전달하세요.

```typescript
// Adaptive window가 꺼져 있어 이 고정 크기가 사용됩니다.
const client = new Client(endpoint, undefined, {
  grpcInitialStreamWindowSize: 16 * 1024 * 1024,
  grpcInitialConnectionWindowSize: 16 * 1024 * 1024,
  grpcHttp2AdaptiveWindow: false,
})
```

**TypeScript, `@triton-one/yellowstone-grpc` 5.0.0 이하.** 이 버전들은 `@grpc/grpc-js`를 사용하며, 그 기본 윈도우는 65,535바이트입니다. 6 ms에서 약 11 MB/s, 100 ms에서 약 0.66 MB/s입니다. `@grpc/grpc-js`는 버전 1.14부터 `'grpc-node.flow_control_window'`를 두 윈도우에 모두 적용합니다. 버전 1.13은 이 옵션을 스트림 윈도우에만 적용하므로, 연결 윈도우는 65,535바이트(6 ms에서 약 11 MB/s) 그대로입니다. `@grpc/grpc-js`가 1.14보다 오래된 버전이라면 `@triton-one/yellowstone-grpc` 5.0.1 이상으로 업그레이드하는 편이 빠릅니다.

```typescript
// 두 window를 모두 넓히려면 @grpc/grpc-js 1.14 이상 필요.
const client = new Client(endpoint, undefined, {
  'grpc-node.flow_control_window': 16 * 1024 * 1024,
})
```

**Go, `google.golang.org/grpc`.** 기본적으로 라이브러리가 윈도우를 16 MiB까지 스스로 넓힙니다. `grpc.WithInitialWindowSize`와 `grpc.WithInitialConnWindowSize`는 크기를 고정하고 자동 증가를 끕니다. 64 KiB 미만의 값은 무시됩니다. 두 가지를 모두 설정하세요. 하나만 설정하면 다른 윈도우는 64 KiB로 남습니다.

```go
// 두 가지를 모두 설정; 자동 window 증가도 꺼집니다.
conn, err := grpc.NewClient(target,
	grpc.WithTransportCredentials(creds),
	grpc.WithInitialWindowSize(16<<20),
	grpc.WithInitialConnWindowSize(16<<20),
)
```

**Python, `grpcio`.** `grpc.http2.bdp_probe`는 기본적으로 켜져 있어 윈도우가 스스로 커집니다. 코드에서 `("grpc.http2.bdp_probe", 0)`을 전달하고 있다면 제거하세요. `grpc.http2.lookahead_bytes`는 스트림당 미리 읽기(read-ahead) 양을 설정합니다(기본값 64 KB). 왕복 시간이 길면 더 큰 값이 도움이 될 수 있습니다.

```python
# options에 ("grpc.http2.bdp_probe", 0)이 있으면 제거하세요.
channel = grpc.secure_channel(target, creds, options=[
    ("grpc.http2.lookahead_bytes", 16 * 1024 * 1024),
])
```

**더 가까이에서 받기.** 왕복 시간이 짧으면 같은 윈도우로 더 많이 전달할 수 있으며, ERPC의 [VPS 서비스](https://erpc.global/ko/vps/)와 [Bare-Metal 서버](https://erpc.global/ko/baremetal/)는 클라이언트를 엔드포인트 가까이에 둡니다.

**나눌 때 주의할 점.** 등록된 소스 IP 하나당 Standard는 10개, Premium은 50개의 스트림을 허용합니다. 스트림마다 자체 스트림 윈도우를 받지만, 한 연결의 스트림들은 연결 윈도우 하나를 함께 쓰므로 작은 연결 윈도우는 여전히 속도를 제한합니다. 스트림을 교체할 때는 이전 스트림을 먼저 닫으세요. 열려 있는 스트림은 한도에 포함되며, 한도를 넘으면 `STREAM_ADMISSION_LIMIT_REACHED`가 반환됩니다(별도 질문이 아래에 있습니다). 나눈다고 느린 처리가 빨라지지는 않습니다.

## Q. `STREAM_GUARD_EGRESS_BUDGET` 오류가 `ResourceExhausted (8)` 상태와 함께 나타나면 무슨 뜻인가요?

해당 IP의 전체 트래픽이 Shared 허용량을 초과하여 관련 스트림들이 함께 닫힐 수 있습니다. 데이터 양과 불필요한 병렬 스트림을 줄인 뒤, 반환된 기한까지 기다리세요. 이 송신량 초과 일시 정지는 600초로 고정되어 있으며 페널티 단계를 올리지 않지만, 이미 적용 중인 더 긴 일시 정지는 계속 유효할 수 있습니다.

## Q. `STREAM_GUARD_PENALTY_ACTIVE` 오류가 `ResourceExhausted (8)` 상태와 함께 나타나면 무슨 뜻인가요?

이전의 느린 수신 또는 송신량 초과 일시 정지가 아직 진행 중이며, 이 응답에는 남은 시간이 포함되어 있습니다. 첫 ERPC 오류를 보존하고 원인을 수정하되, `x-erpc-retry-at` 전에는 재연결하지 마세요. 확인하려고 일찍 재연결하지도 마세요. 재연결 시도는 집계되지 않습니다. 위의 질문 “어떤 gRPC 오류가 연결을 일시 정지시키며, 클라이언트는 언제 재연결을 멈춰야 하나요?”에서 각 단계와 그 길이를 설명합니다.

## Q. `STREAM_GUARD_SHAPE_BLOCKS` 오류가 `PermissionDenied (7)` 상태와 함께 나타나면 무슨 뜻인가요?

현재 Shared 규칙은 요청 범위가 좁아도 비어 있지 않은 모든 `blocks` 맵을 거부합니다. `blocks` 맵을 제거하세요. 요구에 맞는 경우 트랜잭션 및/또는 블록 메타데이터를 사용하되, 어느 쪽도 전체 블록과 같지는 않습니다. 전체 블록이 필요하면 Dedicated Geyser gRPC를 사용하세요. 이는 블록을 골라 받는 Shared 플랜이 제공된다는 뜻이 아닙니다.

## Q. `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` 오류가 `PermissionDenied (7)` 상태와 함께 나타나면 무슨 뜻인가요?

계정 필터 항목은 `account`, `owner` 또는 지원되는 cuckoo 필터로 데이터를 선택해야 합니다. `memcmp`와 `dataSize`만으로는 충분하지 않습니다. 계정 요청을 이처럼 지원되는 형태 중 하나로 좁히거나, 전체 계정 스트림이 필요하면 Dedicated Geyser gRPC를 사용하세요.

## Q. `STREAM_GUARD_SHAPE_REJECT_PENALTY` 오류가 `ResourceExhausted (8)` 상태와 함께 나타나면 무슨 뜻인가요?

이 코드는 집계되는 거부된 요청이 일시 정지를 시작하는 요청일 때 `ERPC_GRPC_INVALID_ARGUMENT`, `STREAM_GUARD_SHAPE_BLOCKS` 또는 `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` 대신 반환됩니다. 이런 일이 언제 일어나는지는 위의 질문 “어떤 gRPC 오류가 연결을 일시 정지시키며, 클라이언트는 언제 재연결을 멈춰야 하나요?”에서 설명합니다. 이 오류에는 `Retry after N seconds.`, `x-erpc-retry-after-seconds`, `x-erpc-retry-at`이 포함됩니다. 이 일시 정지 중에는 새 연결이 gRPC 상태도 ERPC 코드도 없이 즉시 닫히므로, 클라이언트는 종료 시각을 다시는 보지 못할 수 있습니다. `x-erpc-retry-at`이 포함된 첫 오류에서 그 값을 저장하세요. 거부된 Subscribe 요청은 위 규칙에 따라 집계되며, 재연결은 집계되지 않습니다. 요청을 수정하고, 바꾸지 않은 채 다시 보내지 마세요. 연결이 일찍 끊기면 transport 오류처럼 보일 수 있으므로, 재연결 루프가 가리기 전에 첫 ERPC 오류를 보존하세요.

## Q. `STREAM_ADMISSION_LIMIT_REACHED` 오류가 `ResourceExhausted (8)` 상태와 함께 나타나면 무슨 뜻인가요?

접속 허용량(admission allowance)이 현재 가득 찼습니다. 사용하지 않거나 중복된 스트림을 닫고, 연결의 허용량을 확인한 뒤 여유가 생기면 다시 시도하세요. 이 응답만으로 시간이 정해진 페널티가 적용 중이라는 뜻은 아닙니다.

## Q. `STREAM_ADMISSION_IP_NOT_ADMITTED` 오류가 `PermissionDenied (7)` 상태와 함께 나타나면 무슨 뜻인가요?

ERPC가 이 연결을 허용(admit)하지 못했습니다. IP 등록 유예 기간이 끝난 뒤인 경우도 포함됩니다. 실제 아웃바운드 IP를 등록된 IP와 비교하고 현재 접근 상태를 확인하세요. 등록 변경이 반영될 때까지 기다리되 반영 시간이 정해져 있다고 가정하지 말고, 상태가 계속되면 지원팀에 문의하세요.

## Q. `STREAM_ADMISSION_SOURCE_UNAVAILABLE` 오류가 `Unavailable (14)` 상태와 함께 나타나면 무슨 뜻인가요?

ERPC가 그 시점에 이 연결의 소스를 판단하지 못했습니다. 간격을 두고(backoff) 잠시 후 다시 시도하세요. 계속되면 첫 오류와 그 metadata를 첨부해 지원팀에 문의하세요. 이 응답이 고객의 네트워크나 서버에 문제가 있다는 뜻은 아닙니다.

## Q. `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE` 오류가 `Unavailable (14)` 상태와 함께 나타나면 무슨 뜻인가요?

ERPC가 그 시점에 접근 권한을 확인하지 못했습니다. 간격을 두고(backoff) 잠시 후 다시 시도하고, 계속되면 지원팀에 문의하세요. 반복적인 재등록, 필터 확장, Dedicated Geyser gRPC 구매로는 이 가용성 응답이 해결되지 않습니다.

## Q. `ERPC_GRPC_INVALID_ARGUMENT` 오류가 `InvalidArgument (3)` 상태와 함께 나타나면 무슨 뜻인가요?

요청에 잘못된 매개변수, 옵션, 필드 타입, 키 또는 필터 조합이 있습니다. 재시도하기 전에 요청을 수정하고, 같은 요청을 다시 보내지 마세요. 이 코드로 거부된 Subscribe 요청은 각각 위의 질문 “어떤 gRPC 오류가 연결을 일시 정지시키며, 클라이언트는 언제 재연결을 멈춰야 하나요?”의 일시 정지 규칙에서 집계되는 오류이며, 이 규칙은 `STREAM_GUARD_SHAPE_BLOCKS`, `STREAM_GUARD_SHAPE_ACCOUNTS_ALL`, `STREAM_GUARD_SLOW_READER`와 공유됩니다. 이 코드로 거부된 요청이 일시 정지를 시작하면 그 오류는 `ResourceExhausted (8)` 상태와 함께 `STREAM_GUARD_SHAPE_REJECT_PENALTY`로 반환됩니다. Dedicated Geyser gRPC도 잘못된 매개변수를 유효하게 만들지 않습니다.

오류 메시지는 코드 끝에 `(reason: <token>)`을 붙이며, 같은 token이 응답 헤더 `x-erpc-error-reason`으로도 반환됩니다. 아래에서 token을 찾아 무엇을 바꿔야 하는지 확인하세요. 한도가 적용되는 경우 오류 메시지에 그 값이 표시됩니다.

| 이유 | 의미 | 수정할 내용 |
| --- | --- | --- |
| `too_many_filters` | 요청에 한 요청이 가질 수 있는 수보다 많은 이름이 지정된 필터 또는 데이터 슬라이스가 있습니다. | 요청당 이 유형의 이름이 지정된 필터(또는 데이터 슬라이스)를 줄이세요. |
| `empty_filter` | 필터에 주소가 없습니다. 빈 필터는 전체를 뜻합니다. | 모든 필터에 주소를 하나 이상 지정하세요(계정: account 또는 owner, 트랜잭션: 계정 목록). Shared gRPC는 빈 필터를 처리하지 않습니다. |
| `too_many_addresses` | 하나의 필터 필드에 주소가 너무 많습니다. | 한 필터 필드의 주소 수를 줄이세요. 여러 필터로 나누거나 목록을 좁히세요. |
| `address_not_allowed` | 필터에 Shared gRPC가 허용하지 않는 주소가 있습니다. | 트래픽이 많은 그 주소를 필터에서 제거하세요. |
| `filter_name_too_long` | 필터 이름이 너무 깁니다. | 더 짧은 필터 이름(맵 키)을 사용하세요. |
| `invalid_commitment` | commitment 수준이 올바르지 않습니다. | `processed`, `confirmed`, `finalized` 중 하나를 사용하세요. |
| `invalid_address` | 필터에 올바르지 않은 주소가 있습니다. | 모든 주소를 유효한 base58 Solana 주소로 만드세요(빈 문자열, 공백, 잘못된 길이 불가). |
| `invalid_signature` | 트랜잭션 서명 값이 올바르지 않습니다. | 유효한 base58 트랜잭션 서명을 사용하세요. |
| `invalid_account_data_filter` | 계정 데이터 필터가 올바르지 않습니다. | `memcmp`, `datasize`, 토큰 계정 데이터 필터를 수정하고, 그 개수를 메시지에 표시된 한도 안으로 유지하세요. |
| `invalid_data_slice` | 데이터 슬라이스가 올바르지 않습니다. | 데이터 슬라이스를 offset 순으로 정렬하고 서로 겹치지 않게 하세요. |
| `blocks_include_not_allowed` | 블록 구독 옵션은 Shared gRPC에서 사용할 수 없습니다. | `blocks`를 빼고 트랜잭션 또는 `blocks_meta` 구독을 사용하세요. |
| `invalid_token_accounts_mode` | 토큰 계정 모드가 올바르지 않습니다. | `ALL` (0) 또는 `BALANCE_CHANGED` (1)을 사용하세요. |
| `invalid_argument` | 위의 어느 이유에도 해당하지 않습니다. | 다시 시도하기 전에 요청의 필터와 매개변수를 확인하세요. |

## Q. gRPC가 다른 0이 아닌 상태로 `ERPC_GRPC_REQUEST_FAILED` 오류를 반환하면 무슨 뜻인가요?

요청이 다음 조치를 결정하는 유효한 gRPC 상태와 함께 실패했습니다. 이력 범위가 잘못되었다면 `OutOfRange (11)` 같은 상태에 맞춰 요청을 수정하고, `Unavailable (14)` 같은 가용성 상태라면 간격을 두고(backoff) 다시 시도하세요. 0이 아닌 상태를 모두 일시적인 것으로 분류하거나, 모든 응답을 바꾸지 않은 채 재시도하지 마세요.

## Q. 어떤 리전을 추천하나요?

영구적으로 가장 좋은 단일 리전은 없습니다. Solana는 글로벌하며 리더 역할은 리더 스케줄에 따라 검증자 간에 넘어갑니다. 검증자가 많고 스테이크가 높은 리전일수록 리더 슬롯이 더 자주 발생하여 트랜잭션이 더 빨리 안착하는 데 도움이 될 수 있습니다. 다만 경쟁 트래픽도 그곳에 집중되므로, 전략에 따라서는 덜 붐비는 리전이 더 나은 결과를 줄 때도 있습니다.

실용적인 출발점으로, 안정적인 리더 슬롯 공급이 가장 중요하다면 Frankfurt나 미국 동부 해안처럼 검증자가 밀집한 리전을 선택하고, 최단 경로 실행이 우선이라면 특정 대상 검증자 가까이에 배치하세요. [Validators Solutions](https://validators.solutions/)로 공개된 Solana 네트워크 분포를 파악한 뒤, [ERPC Leader Slot API](https://erpc.global/ko/doc/rpc/leader-slot-api/)와 실제 측정값을 사용해 단일 리전, 이중 리전, 글로벌 배포 중 무엇이 적합한지 판단하세요.

[![Solana 메인넷 분포 보고서](https://erpc.global/faq/SolanaMainnetReportEN.jpg)](https://validators.solutions/)

## Q. ~400ms 이내의 지연 시간이 필요합니다.

약 400ms 이내의 지연 시간을 달성하려면 다음 핵심 사항을 고려하세요.

- **Ping 값에 대한 현실적인 이해**: ping 값은 이상적인 조건을 나타낼 뿐 스트리밍 통신의 실제 지연 시간을 반영하지 않으며, 스트리밍 통신의 지연 시간은 일반적으로 ping의 약 5배에 이릅니다. 예를 들어 대륙 간 100ms의 ping은 실제로는 약 500ms의 지연 시간으로 이어집니다. 따라서 ~400ms 지연 시간을 달성하려면 동일 리전 내에 인프라를 구축해야 합니다.
  - 일반적인 Ping 값 참고:
    - 동일 네트워크: ~0.1ms
    - 사설 네트워크 상호 연결(PNI): ~0.2ms
    - 동일 데이터 센터: ~0.3ms
    - 동일 도시: ~1ms
    - 인접 국가: ~5–10ms
    - 대륙 간: ~100–300ms

- **평균 지연 시간의 함정 피하기**: Solana 검증자는 전 세계에 분산되어 있고 리더 스케줄은 매 에포크마다 무작위로 바뀝니다. 평균 지연 시간에 의존해 ~400ms를 달성하는 것은 비현실적입니다. 대신 특정 리전의 검증자 스케줄을 정밀하게 추적하여 가장 낮은 지연 시간의 슬롯을 식별해야 합니다. 최소 지연 시간을 일관되게 달성하려면 관련된 모든 리전에 인프라가 필요합니다. 동일 리전 내에서는 데이터 취득이 수십 밀리초 내에, 전송은 단 몇 밀리초 내에 이루어질 수 있습니다.

- **리더 스케줄 추적**: **ERPC Leader Slot API**(`getLeaderSlots`)를 사용해 해당 리전의 리더 검증자 스케줄을 모니터링하세요.
  이 API는 다가오는 리더 스케줄, 현재 에포크의 스테이크 가중치, 검증자의 추정 지오로케이션, 참고 ping 값을 반환하므로, 지연 시간이 가장 낮아 노려야 할 슬롯을 해당 슬롯이 오기 전에 미리 파악할 수 있습니다.
  공개된 지도 형식의 데이터와 네이티브 RPC API는 폭넓은 네트워크 가시성에는 유용하지만 실행 타이밍에는 충분히 정밀하지 않습니다. Leader Slot API는 라우팅 및 거래 결정에 필요한 세밀함으로 그 격차를 메웁니다.
  - [ERPC Leader Slot API 문서](https://erpc.global/ko/doc/rpc/leader-slot-api/)
  - [ERPC Web Dashboard](https://dashboard.erpc.global/ko)

[![Validators Solutions - Solana 네트워크 데이터](https://erpc.global/faq/ValidatorsSolutionsEN.jpg)](https://validators.solutions/)

Solana 네트워크 데이터: [Validators Solutions](https://validators.solutions/)

## Q. 제로 블록(zero-slot) 거래는 어떻게 달성할 수 있나요?

제로 블록(zero-slot) 거래를 성공적으로 달성하려면 다음과 같이 더 정교한 전략이 필요합니다.

- **기회 구역 식별**: Solana 검증자는 전 세계에 분산되어 있어 모든 슬롯에서 최적의 지연 시간을 달성하는 것은 물리적으로 불가능합니다. 따라서 인프라가 위치한 리전의 검증자 리더 스케줄을 모니터링하여 가장 유리한 기회 구역을 식별하세요. 여러 리전에 인프라를 배포하는 것도 유리할 수 있습니다. 예를 들어 Frankfurt는 검증자 밀도가 높아 리더 선택이 더 자주 일어나고 거래 기회가 더 많은 핵심 리전입니다.

  공개된 지도 형식의 데이터 소스나 네이티브 RPC API보다 훨씬 높은 정밀도로 다가오는 리더 스케줄, 현재 에포크의 스테이크 가중치, 검증자의 추정 지오로케이션 데이터, 참고 ping 값을 조회하려면 **ERPC Leader Slot API**(`getLeaderSlots`)를 사용하세요. 이를 통해 슬롯이 오기 전에 기회 구역을 파악하고 거의 제로에 가까운 지연 시간으로 거래를 실행할 수 있습니다.
  - [ERPC Leader Slot API 문서](https://erpc.global/ko/doc/rpc/leader-slot-api/)
  - [ERPC Web Dashboard](https://dashboard.erpc.global/ko)

- **전용 노드 구축**: 경쟁이 어렵다면 전용 노드 배포를 고려하세요. 공유 노드는 다른 사용자의 트래픽으로 인해 지연이 발생하므로 권장되지 않습니다. 또한 애플리케이션과 동일한 네트워크 내에 전용 노드를 배치하면 네트워크 지연 시간을 크게 줄이고 성능을 최적화할 수 있습니다.

## Q. 특정 엔드포인트를 사용할 수 있나요?

저지연 환경을 유지하기 위해 시스템이 자동으로 가장 가까운 사용 가능한 노드를 선택합니다. 특정 엔드포인트를 사용하려면 해당 엔드포인트에 가장 가까운 서버를 임대하는 것을 권장합니다.

## Q. 401 오류가 발생합니다. 왜 그런가요?

저지연 환경을 유지하기 위해 IP 제한을 적용합니다. 구독이 없거나 IP가 등록되지 않은 경우 401 오류가 발생합니다.

등록한 IP가 현재 접속 IP와 일치하는지 다시 확인해 주세요.

## Q. 429 오류가 발생합니다. 왜 그런가요?

플랜의 연결 제한에 도달했습니다.

이 오류가 발생하면 플랜 업그레이드를 고려하세요. 프리미엄 플랜이 제공하는 것보다 더 많은 연결이 필요하다면 전용 gRPC 노드가 더 적합합니다.

## Q. 전용 엔드포인트는 왜 더 빠른가요?

공유 엔드포인트는 동일한 리소스를 공유하는 여러 고객이 사용합니다. 트래픽이 늘어나면 지연이 발생하는 경향이 있습니다. 서버 리소스에는 물리적 한계가 있어 처리할 수 있는 작업량이 유한합니다. 너무 많은 요청이 동시에 도착하면 순차적으로 처리해야 하므로 응답 시간이 느려집니다.

공유 엔드포인트에서도 성능을 최적화하기 위해 다양한 조치를 취하고 있지만, 전용 엔드포인트에서는 고객이 해당 리소스의 유일한 사용자입니다. 따라서 다른 사용자의 영향을 전혀 받지 않아 일관되게 안정적이고 빠른 응답이 보장됩니다.

또한 전용 엔드포인트는 TLS 없이 HTTP 등으로 통신하는 옵션을 제공합니다. TLS 핸드셰이크(약 20ms)를 생략하면 HTTPS에 비해 통신이 더욱 빨라집니다.

## Q. 구독한 뒤에 판매 가격이 인상되나요?

구독이 활성 상태인 동안에는 가입 시 고정한 판매 가격이 그대로 유지됩니다. Solana의 실시간 워크로드를 견뎌내는 환경은 전 세계적으로 희소하며, 하드웨어와 네트워크 수요 증가에 맞춰 가격을 단계적으로 인상할 계획입니다. 고사양 구성과 수요가 높은 리전일수록 가장 빠르게 소진되므로, 현재 가격을 고정해 두는 것이 장기적으로 가장 비용 효율적인 선택입니다.

## Q. 암호화폐로 결제하고 싶습니다

암호화폐 결제는 등록된 청구지 국가가 EU 회원국 중 하나인 경우 ERPC Web Dashboard에서 이용할 수 있습니다. 계정에 등록된 결제 카드가 모두 EU 외 지역에서 발급된 경우 암호화폐 결제를 이용할 수 없습니다. SOL, USDC 또는 EURC를 사용하여 ERPC Credits를 구매할 수 있습니다.

구매한 ERPC Credits로 ERPC 플랜을 시작하거나 계속 이용할 수 있습니다. 대시보드를 열고 암호화폐 결제를 선택한 뒤 지갑에서 송금하면, 대시보드가 트랜잭션을 확인하고 계정에 Credits를 반영합니다.

지원 국가: 그리스, 네덜란드, 덴마크, 독일, 라트비아, 루마니아, 룩셈부르크, 리투아니아, 몰타, 벨기에, 불가리아, 스웨덴, 스페인, 슬로바키아, 슬로베니아, 아일랜드, 에스토니아, 오스트리아, 이탈리아, 체코, 크로아티아, 키프로스, 포르투갈, 폴란드, 프랑스, 핀란드, 헝가리.

목록에 없는 국가에서는 신용카드 결제를 이용해 주세요.

[ERPC Web Dashboard](https://dashboard.erpc.global/ko)

## Q. 가능한 한 가장 낮은 지연 시간을 달성하려면 어떻게 해야 하나요?

전용 gRPC 노드와 [Bare-Metal 서버](https://erpc.global/ko/baremetal/)를 결합하는 것을 적극 권장합니다.

둘은 동일한 네트워크를 공유하므로 인터넷을 거치지 않고 사설로 거리 제로(zero-distance) 통신이 가능합니다. 이 구성은 일반적으로 약 0.1ms ping의 극히 낮은 지연 시간을 달성합니다.

자세한 내용은 ERPC Web Dashboard를 통해 문의해 주세요.

[ERPC Web Dashboard](https://dashboard.erpc.global/ko)

🔗 [ERPC Web Dashboard](https://dashboard.erpc.global/ko)

## Q. 지연 시간은 어느 정도인가요?

지연 시간은 측정 방법과 구체적인 사용 환경에 따라 달라집니다. 정확한 수치에 집중하기보다는, 지연 시간이 실제 운영 요구사항을 충족하는지 확인하는 것이 중요합니다.

지연 시간 측정을 위한 사용하기 쉬운 TypeScript 및 Rust 도구를 제공합니다.

- [Solana Stream SDK - ValidatorsDAO GitHub](https://github.com/ValidatorsDAO/solana-stream)
- [SLV (한국어)](https://slv.dev/ko)

## Q. 이 RPC(gRPC, Shreds)는 다른 서비스보다 빠른가요?

저희는 모든 가격대에서 속도를 우선해 설계하며, 다른 어떤 제공업체와 나란히 측정해 보시는 것을 환영합니다. 결과는 리전, 공유 엔드포인트인지 전용 엔드포인트인지, 사용하는 프로토콜(WebSockets, gRPC, Shreds), 그리고 클라이언트의 프로그래밍 언어에 따라 달라질 수 있습니다.

저희 서비스가 더 느리다고 느끼신다면, 비교한 구체적인 조건과 경쟁사를 ERPC Web Dashboard를 통해 알려주세요. 원인을 파악하고 속도를 더욱 개선하겠습니다.

[ERPC Web Dashboard](https://dashboard.erpc.global/ko)

## Q. 가장 빠른 성능을 제공하는 플랜은 무엇인가요?

일반적으로 최상위 등급 플랜이 우수한 CPU, 더 큰 메모리 용량, 견고한 하드웨어 구성 덕분에 가장 빠른 성능을 제공합니다.

더 강력한 서버가 필요하면 맞춤형 솔루션도 제공하지만, 표준 플랜은 최적의 가격 대비 성능을 제공하도록 설계되었습니다.

저희는 모든 가격대에서 세계 최고 수준의 성능을 제공한다고 자신합니다. 동일한 가격대에서 더 빠른 제공업체를 찾으신다면 알려주세요. 조사하여 개선하겠습니다.

## Q. 지연 시간이 높습니다. 어떻게 해야 하나요?

지연 시간은 엔드포인트와의 근접성에 크게 좌우됩니다. 제공된 엔드포인트에 가까운 서버에서 접속하는 것을 권장합니다. 가장 빠른 연결은 저희 [Bare-Metal 서버](https://erpc.global/ko/baremetal/)와 [VPS 서비스](https://erpc.global/ko/vps/)로 달성할 수 있습니다.

## Q. WebSockets, gRPC, Shreds 중 무엇이 가장 빠른가요?

고객 피드백은 속도를 일관되게 다음과 같이 평가합니다.

**Shreds > gRPC > WebSockets**

다른 결과를 관찰하셨다면 경험을 공유해 주세요.

## Q. 지연 시간이 예상과 다릅니다.

성능은 사용하는 프로그래밍 언어에 따라 달라집니다. 일반적으로 언어 속도는 다음 순서입니다.

**Rust > Go > TypeScript (JavaScript) > Python**

자세한 비교는 다음을 참고하세요.

[프로그래밍 언어 속도 비교](https://niklas-heer.github.io/speed-comparison/)

최대 성능을 위해서는 Rust 사용을 강력히 권장합니다.