【发布时间】：2014-03-03 18:18:51
【问题描述】：
我有一个 api，客户端使用 get 请求，我回显一个 json_encoded 字符串作为响应。
我想检查字符串是否到达目的地
无需修改客户端。
我正在考虑打开一个套接字或使用一个打开的套接字（如果没有记错的话——当用户发送 GET 请求时，他会和我一起打开一个套接字）
构建一个数据包，将字符串添加为数据并发送到端口 80
如何验证该数据包的 ACK？出于安全原因，客户端不会丢弃此数据包吗？
【问题讨论】：
【发布时间】：2014-03-03 18:18:51
【问题描述】：
为了确保传送（在某种程度上），您应该使用 TCP，而不是数据包。安全性是这里最不关心的问题，因为当任何一方位于 NAT 之后时，您可能会遇到麻烦。与简单的套接字相比，Web 服务器在连接性方面更加通用。 GET API 本身不是很健壮，在这些情况下客户端必须重试（可能使用防止重复执行的唯一 ID）。
【讨论】：
-
我使用 TCP 而非 UDP 发送数据包 - 套接字是通过 TCP 打开的。
另外，如果我到达 NAT，我可以知道服务器还活着，不是吗？
并且我的消息到达了客户端服务器。
我需要知道数据包到达客户端服务器 -
要么你混淆了很多东西，要么我们彼此相距甚远:) 仅供参考：在 TCP 中你不能发送数据包，那就是 UDP。在 TCP 上，您可以发送数据（或只是打开一个连接）然后等待答案。每个 TCP 连接在互联网上可能会走不同的路线，所以如果你建立一个单独的连接，你只有联系到那个目的地，你才知道 json 已经到达它的目的地，并询问“json#185 到达了吗？”。这总是涉及到一些与客户端的逻辑，所以通过“不修改客户端”来排除。
-
NAT 等：能够联系客户端的某些（例如 NAT）服务器并不能表明客户端应用程序是否有机会接收（更不用说处理）消息。顺便说一句，在许多情况下，NAT 服务器甚至不属于客户端。
-
是的，到达 NAT 甚至得到 ACK 并不意味着客户端的应用程序得到了它，但它排除了一种情况。我认为可以在现有套接字上的 TCP 上创建和发送数据包。
-
所以如果我没看错的话，你想使用 HTTP 连接的套接字来发送（或接收？）附加数据。如果是这样，那么当您说“发送到端口 80”时，我无法理解您对端口 80 的想法是如何产生的。您可能想花几句话在整句话中解释您正在努力的目标。