14

我正在使用 http post 方法向 Http Server URL 发送请求。

请求和响应之间的时间差约为 60 秒，但根据服务器团队的说法，一旦请求到达终点，他们将在 7 秒内发送响应。

我不认为网络需要剩余 53 秒的时间才能到达服务器端的数据包，所以可能是什么问题。

在这个应用程序中，我们在客户端和服务器之间使用同步通信。请向我提供以下详细信息。

  1. 是不是因为服务器发送请求的速度超过了服务器能够处理的速度。在这种情况下，客户端多次以 3 秒的间隔获取请求，而服务器则需要 7 秒来处理此问题。
  2. 什么是网络缓冲区。网络层是否有两个缓冲区，一个在客户端，另一个在服务器。
  3. 如果服务器无法以相同的速度处理请求，则客户端发送的所有请求都被缓冲在客户端缓冲区中，如果等待处理的请求超过该缓冲区的最大大小会发生什么情况。
  4. 如果我们在客户端并且无法控制服务器，有什么替代方法可以提高性能

编辑：当我在网络中使用wireshark 来捕获网络日志时，我发现它在我的应用程序实际发送到服务器后20 秒出现在wireshark 中。这种延迟背后的原因是什么。请求出现在网络中的可能原因是什么可能导致实际发送延迟 20 秒。

4

6 回答 6

33

关于您的编辑，以帮助您理解。网络遵循称为开源互通 (OSI)的模型。该模型分为七个不同的层，所有层都有一个功能。

这些层在这里：

OSI 模型

Wireshark 检测位于第 3 层的数据包。由路由器处理。网络接口卡 (NIC)获取分配的数据并将其转换为数据包以通过网络发送。

在您的NIC将其转换为路由器处理的数据包之前，Wireshark 不会检测到该数据包。

您会看到，一旦将其转换为数据包，它就会包含以下信息：

  • 4 位包含版本（IPV4 或 IPV6）
  • 4 位包含 Internet 标头。
  • 包含服务类型或服务质量和优先级的 8 位。
  • 包含数据包长度的 16 位，以字节为单位。
  • 包含识别标签的 16 位，以帮助从 Fragments 重建数据包。
  • 3 位，第一个是零，后跟一个标志，表示是否允许分片。和数量。
  • 包含片段偏移量的 13 位，用于标识原始位置的字段。
  • 包含生存时间 (TTL)和跨路由器的跳数的 8 位。
  • 8 位包含协议（TCP、UDP、ICMP 等）
  • 包含Header Checksum的 16 位
  • 包含源 IP 地址的 32 位
  • 包含目标 IP 地址的 32 位

这些是创建此类数据包时创建的关键 160 位。

这是什么意思？

好吧，您知道Wireshark需要 20 秒才能检测到您的数据包。因此，我们一开始就知道您的应用程序需要 20 秒才能真正构建此数据包。

我们知道服务器还需要重建这个数据包，以便它可以处理数据并可能发送请求。

我们也知道路由器就像交通警察一样，通过互联网或本地网络发送您的数据。

好吧，这增加了很多推断？但我该去哪里？

您有一个名为：tracert

平均而言，通过 5 到 6 英尺的电缆需要一到两毫秒的路由请求，因此如果它生成一到两毫秒的初始跃点，但在 230 毫秒内触发第二个跃点，那么您可以使用一个简单的公式：

6 * 20

根据我们跟踪器的当前速度，我们可以估计持续时间。这是一种非常通用的方法，但存在用于精确准确性的工具。但是跳越多，到达目的地所需的时间就越多。此外，您将乘以更多。

从客户端到服务器之间的那个呢？

  • 局域网（LAN）：网络的内部效率是由于每个网络协议、设备和物理介质的优化。网络管理员必须以速度衡量可靠性；以及网络产生的所有流量。因此，设备吞吐量和物理中位数很重要。您不希望十辆汽车合并到一条单车道隧道中，这可能会产生同样适用于网络的瓶颈。

  • 广域网（WAN）：这本质上是与互联网、云的连接。可以这样想：您的计算机在 LAN 上，路由器连接到 WAN。然后你的 ISP 很可能有一个 LAN，然后它的 WAN 向更大的分发设施开放。它一直在工作，直到它到达互联网。

不过我能做什么？

你知道现在之间是什么，但我能做什么？

好吧，当您生成服务时，您显然希望确保您的代码精简且高效。因为效率对速度至关重要。因此，改变缓冲区大小、传输速率等可以极大地改进您的应用程序。

显然，良好的代码实践会有所帮助。

我的代码是坚如磐石吗？

如果您认为您的代码此时不是问题，或者您托管和创建服务的方法不是问题，那么这些因素可能是原因：

  • 本地机器可能会产生过多的抖动，因此需要更长的时间。
  • 本地网络正在产生过多的抖动或低效/低吞吐量。
  • 您的请求是长途旅行，所以时间有所延迟。
  • 您的 Internet 服务提供商可能具有扫描这些数据包的硬件防火墙、代理等。
  • 您的服务器可能有过多的请求或 Host 方法效率不高。

这些是更大的变量。您可以尝试的只是重构服务并确保您的服务器以最有效的方式托管它。否则，您需要让信息技术团队参与进来，这一点至关重要。

但请记住这一点，您的体验可能比与此服务交互的其他客户更好或更差。

我是在假设您部署在一个位置并且您可能远离您的服务器的几个州的情况下说的。

工具：

命令行：

  • 平
  • 示踪剂

网络和协议分析仪：

  • Fiddler (HTTP/HTTPS) ：查看 Fiddler 是否显示任何 HTTP 状态代码以进行故障排除。
  • Wireshark ：将分析您的网络流量，这有助于持续时间。

还有其他实用程序可用于实际缓解和测试网络速度，甚至到其他位置，仅谷歌“网络工具”。福禄克有几个。

希望这可以解释为什么 Wireshark 甚至可能需要 20 秒才能在网络上显示数据包。

希望有帮助。

于 2013-03-21T18:02:12.797 回答
8

使用 Wireshark 在网络上每隔 60 秒捕获您的请求和响应，并将其发送给服务器团队。他们可能会通过捕获显示请求和响应在他们身边接近 7 秒来响应。那太棒了！将它们都发送给网络团队。

另一方面，跟踪可能显示延迟存在于您的代码中。您的终端可能存在某种限制或延迟，从而使请求无法在很长一段时间内离开您的流程。Wireshark 跟踪也可以告诉您这一点。

于 2013-03-15T00:37:17.777 回答
6

TCP/IP 流将控制您担心的大部分内容。

“发送请求比服务器无法处理的速度更快”

不，您永远不会比使用 TCP 会话时接收到的速度更快地向服务器发送任何内容。传输流是受引导的，不可能发送得比服务器可以处理的快。

“什么是网络缓冲区”

TCP/IP 通信涉及两个队列缓冲区，一个发送缓冲区和一个接收缓冲区。

当您send()拨打电话时，它并没有真正发送任何内容，它只是将数据排队在发送缓冲区中，并返回给您您尝试发送的字节中有多少实际上已放入队列中以进行发送。如果它返回的比您尝试发送的少，则意味着您必须等待才能发送其余的，因为缓冲区已满。

这就是您控制流量的方式，这是您知道您是否尝试发送内容过快的提示。只要您有数据要发送，请尽量保持缓冲区已满，但不要忽略并非所有内容都适合缓冲区并且您必须稍后重试的事实。

recv()也有自己的缓冲区。这个命令实际上并没有接收任何东西，数据已经接收到，recv()只会从接收缓冲区中读取。使用阻塞套接字时（默认），recv()如果缓冲区为空，将挂起，等待新数据到达。recv()仅当连接终止或您尝试将其与非阻塞套接字一起使用时才会返回 0。

如果您忘记了recv()并且接收缓冲区已满，也可以。对端将无法继续发送，send()将开始向它们返回 0，但只要注意send()返回值，任何时候都不会丢失数据。

据我所知，所有系统的缓冲区大小默认为 64KB，用于发送或接收。有一些命令可以调整这个缓冲区的大小，但它并不有趣。如果您需要更大的缓冲区，请在您的应用程序中使用。

“如果我们在客户端并且无法控制服务器，有什么替代方法可以提高性能”

它不完全是一个有效的问题，你不能这样做。我认为您可能在 HTTP 请求上犯了一些错误，特别是考虑到您正在执行 POST 请求。

在执行 POST 请求时，您的 HTTP 标头将包含两个通常仅在服务器 HTTP 响应标头中可见的标头：Content-Type 和 Content-Length。它们在进行 POST 时非常重要，如果其中一个丢失或错误，HTTP 会话可能会挂起几秒钟或根本不成功。

HTTP 的另一个重要方面，是 HTTP 1.0 和 HTTP 1.1 最本质的区别：HTTP 1.0 不支持Keep-Alive。对于初学者来说处理 HTTP 1.0 更容易，因为使用 HTTP 1.0，您连接、发送请求、服务器响应并终止连接，这意味着您完成了服务器响应的下载。对于 HTTP 1.1，默认情况下不会发生。连接保持打开状态，直到超时。您必须注意 HTTP 响应标头 Content-Length 和字节数，以便了解服务器是否结束发送您请求的内容。

同样重要的是要注意并非所有服务器都支持 HTTP 1.0。您可以发出 HTTP 1.0 请求，但无论如何它都会以 1.1 响应，包括 Keep-Alives 和所有您没有预料到的东西。在一个完美的世界里，它不应该发生，但它确实发生了。

你的错误可能就在这个区域。你说你的请求正好用了 60 秒，我怀疑这是因为它超时了。您可能已经收到了您必须收到的所有内容，但应用程序没有正确处理这些内容，然后挂起，直到服务器终止连接。

于 2013-03-24T00:26:11.637 回答
2

在第 1 点：

在您的第 1 点中，我相信您的意思是说“1”。是否是由于客户端发送......'和'在这种情况下，客户端多次收到响应......'。

关于第 3 点：

  • 服务器机器通常是比客户端机器更强大的计算机，因此这种“如果服务器无法以相同的速度处理客户端发送的请求”的情况很少见。如果我没记错的话，HTTP 服务器采用“先到先服务”的方式，而您所称的请求缓冲区将是服务器端的队列，而不是客户端。我从未听说过“所有请求都在客户端缓冲区缓冲”。

  • 服务器响应所需的时间通常很快，但返回给您（客户端）的时间结果更多地与原始请求正在执行的操作有关，无论是仅检索静态 html 文件，还是检索大图像或文档，或者必须在数据库服务器上执行繁重的查询等。

  • 您是唯一向服务器提交 HTTP 请求的客户端吗？可能不是。那台服务器机器是否仅容纳 HTTP 服务器？请记住，服务器正在或将要处理来自多个客户端的请求，这有时可能是延迟响应的另一个因素，即使服务器可以同时处理多个请求并且取决于其他请求在做什么。HTTP 服务器因多个请求而无法响应的极端示例是服务器受到 [分布式] 拒绝服务攻击。

  • 您是否有任何防火墙保护 HTTP 服务器或保护 HTTP 服务器所在的网络？拥有防火墙规则或网络入侵检测系统可能会延迟请求/响应时间。

  • 以下可能是“请求出现在网络中的可能原因可能是它实际发送延迟 20 秒”的另一个因素。它被称为“网络拥塞”，通常发生在路由器级别。

关于第 4 点：

  • 一旦放弃或消除与第 3 点相关的因素，您可以通过以下方式提高性能：

  • 首先，所有其他都不是延迟的[主要]因素，请弄清楚您的预期响应时间是多少。

  • 其次，确保您对往返行程在什么条件/情况下所花费的时间有一个合理准确的衡量标准。我认为 HTTP 服务器不是罪魁祸首。

  • 第三，如果仍然遇到延迟，您（或其他人）将需要查看路由器的配置、防火墙配置以及您的 html 页面代码（如果有）或您的 Web 应用程序（如果有）。

编辑：

尝试 ping 您的 HTTP 服务器以了解网络往返时间。

这是一个例子；我确实提交了这个命令：

ping www.yahoo.com

从客户端 PC 上的 MS-DOS 窗口。

在此处输入图像描述

1) 注意往返时间大约为 0.5 秒或更短（0.5 秒 = 500 毫秒）。我在美国东海岸，Yahoo.com 很可能是美国西部的费用（我不确定）。

2）请注意，每次往返的长度并不总是相同，但变化很小。

3）从我的本地PC到像Yahoo.com这样的世界级暴露服务器，中间有几个请求、路由器和防火墙，响应时间甚至不到1秒。这意味着如果网络和服务器配置正确，它们很少会导致延迟，这意味着在将其归咎于 HTTP 服务器之前，应彻底检查/审查您的页面或应用程序。

4）当我从浏览器提交请求http://www.yahoo.com时，加载页面肯定花了 0.5 秒多一点，我认为是因为页面中的所有 html 元素和广告，但 HTTP 服务器响应是可能是 0.5 秒。

于 2013-03-22T19:47:23.793 回答
0

尝试检查您的 DNS 配置，我认为这可能是一个问题。在您的浏览器或脚本发出请求之前，必须将域名解析为 IP 地址。

您可以通过向位于 Windows 中的主机文件添加其他信息来轻松检查这一点：

C:\Windows\System32\drivers\etc\hosts

或者在linux系统中：

\等\主机

要检查有关域和 IP 地址的信息，请尝试使用 nslookup（Windows 和 Linux 操作系统上的相同命令）

于 2013-04-04T10:39:58.587 回答
0

第 4 点：对于大量数据，在线路中花费的时间可能很重要。如果您的服务器支持它，您可能希望在发送之前压缩内容。

于 2013-04-04T04:30:01.637 回答