Question

使用哈希从公共网关查询文件时，网关查询对等节点，并将内容作为http响应发回。

例如

在本地添加的文件会生成一个哈希QmXjFR1MiAMYprPjwLQwXXonYK52FihQVEL6a2dh3uhUey，其中
当网关用作https://ipfs.io/ipfs/QmXjFR1MiAMYprPjwLQwXXonYK52FihQVEL6a2dh3uhUey时，网关查询我的本地节点（具有文件）并在浏览器中返回检索到的内容。

问题是：

是否可以通过任何方式（例如响应头或其他方式）从哪个对等/远程计算机知道网关检索了内容？（在上面的示例中，我的计算机的 peer-id ）

Answer 1

我认为答案为否（自v0.4.20起）。检索块时，IPFS经历的过程是：

同时执行以下操作：
1. 通知您当前要阻止的所有同级对象（例如QmXjFR1...）
2. 询问网络以查找所需块的提供者（例如QmXjFR1...）
如果对等方拥有该阻止，它将把它发送出去，而您将忽略找到的任何提供程序。
如果没有对等方拥有该块并且找到了提供者，则该提供者被添加为对等体，并被告知您需要该块（例如QmXjFR1...），此时对等点开始通过该块发送该块。

理论上，如果您运行IPFS节点，则可以做一些事情来确定块来自哪个对等点。但是网关不通过其接口AFAIK提供该信息。

无论如何，我在响应头中看不到任何内容。这是点击网关API的示例：

λ curl -v https://gateway.ipfs.io/api/v0/cat/QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o
*   Trying 2602:fea2:2::1...
* TCP_NODELAY set
* Connected to gateway.ipfs.io (2602:fea2:2::1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=ipfs.io
*  start date: May  7 21:37:01 2019 GMT
*  expire date: Aug  5 21:37:01 2019 GMT
*  subjectAltName: host "gateway.ipfs.io" matched cert's "*.ipfs.io"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7ff002806600)
> GET /api/v0/cat/QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o HTTP/2
> Host: gateway.ipfs.io
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< server: nginx
< date: Wed, 22 May 2019 04:32:43 GMT
< content-type: text/plain
< vary: Accept-Encoding
< trailer: X-Stream-Error
< vary: Origin
< x-content-length: 12
< x-stream-output: 1
< access-control-allow-origin: *
< access-control-allow-methods: GET, POST, OPTIONS
< access-control-allow-headers: X-Requested-With, Range, Content-Range, X-Chunked-Output, X-Stream-Output
< access-control-expose-headers: Content-Range, X-Chunked-Output, X-Stream-Output
< x-ipfs-pop: gateway-bank2-sjc1
< strict-transport-security: max-age=31536000; includeSubDomains; preload
<
hello world
* Connection #0 to host gateway.ipfs.io left intact

查询https://ipfs.io/ipfs/时如何知道从哪个节点检索文件/块

1 个答案: