为什么得到Http请求和响应太晚了

Question

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

请求和响应之间的时差大约为60秒，但根据服务器团队，一旦请求到达结束时，他们将发送响应7秒。

我不认为网络在服务器端需要剩余的53秒时间才能到达数据包，因此可能会出现问题。

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

1. 是否由于服务器以比服务器更快的速度发送请求 能够处理。在这种情况下，客户端多次收到请求 间隔3秒，而服务器需要7秒钟来处理 此。
2. 什么是网络缓冲区。网络上是否有两个缓冲区 客户所在地的第一级和服务器所在地的其他地方。
3. 如果服务器无法以相同的速度处理客户端的请求 发送是所有请求在客户端缓冲区缓冲，会是什么 如果有更多请求待处理而不是最大大小，则会发生 那个缓冲区。
4. 如果我们在客户端，有什么方法可以提高性能 结束而无法控制服务器

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

Answer 1

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

这些图层在这里：

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

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

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

• 4个包含版本（IPV4或IPV6）
的位
• 包含Internet标头的4个位。
• 包含服务类型或服务质量和优先级的比特。
• 包含字节数据包长度的16位。
• 16个包含识别标记的位，以帮助从碎片重建数据包。
• 3位，第一个是零，后跟一个标志，表示允许Fragment或Not。和数量。
• 13包含片段偏移的位，用于标识原始位置的字段。
• 包含生存时间（TTL）和在路由器中跳跃的8个位。
• 8包含协议（TCP，UDP，ICMP等）的位
• 包含标头校验和
的16个位
• 包含源IP地址的32位
• 包含目标IP地址的32位

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

这是什么意思？

嗯，你知道 Wireshark 需要20秒才能检测到你的数据包。所以，我们知道你的应用程序需要20秒才能真正构建这个数据包。

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

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

嗯，这增加了相当多的推论？但是我该去哪里？

您有一个名为： tracert

的实用程序

平均而言，需要一到两毫秒的路由请求才能通过5到6英尺的电缆，所以如果它产生一到两毫秒的初始跳，但是第二跳是在二十三毫秒内触发的，那么你可以使用一个简单的公式：

6 * 20

根据我们 tracert 的当前速度，我们可以估算持续时间。这是一种非常通用的方法，但存在精确准确的工具。但跳越多，到达目的地所需的时间就越多。你也越多。

从客户端到服务器之间的情况如何？

• 局域网（LAN）：网络的内部效率是由于每个网络协议，设备和物理中位数的优化。网络管理员必须快速测量可靠性;以及网络生成的所有流量。因此，设备吞吐量和物理中值很重要。你不会想要将十辆汽车合并到单车道隧道中，这样可以创建一个同样适用于网络的瓶颈。

• 广域网（WAN）：这实际上是与Internet的连接，即云。可以这样想：您的计算机在局域网上，路由器到WAN。然后，您的ISP可能会有一个局域网，然后将其开放到更大的分发机构。它一直在努力，直到它上网。

我该怎么办？

你知道现在之间的情况，但我能做些什么？

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

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

我的代码虽然坚如磐石？

如果您认为您的代码目前不是问题，或者您主持和创建服务的方法，则这些因素可能是造成：

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

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

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

我假设你在一个地方部署，并且你可能在远离你的服务器的几个州。

工具：

命令行：

• 平
• Tracert检测

网络和协议分析仪：

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

还有其他实用程序可用于实际缓解和测试网络速度，甚至是其他位置，只有Google＆＃34;网络工具＆＃34;。福禄克有一些。

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

希望有所帮助。

Answer 2

使用Wireshark在线路上相隔60秒捕获您的请求和响应，并将其发送给服务器团队。他们可以通过捕获来回应，显示请求和响应接近7秒。那很棒！将它们发送给网络团队。

另一方面，跟踪可能表明延迟在您的代码中。您的结束可能存在某种限制或延迟，导致请求在很长一段时间内离开您的流程。 Wireshark跟踪也可以告诉你。

Answer 3

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和count字节，以便知道服务器是否结束了发送您请求的内容。

同样重要的是要注意并非所有服务器都支持HTTP 1.0。您可以发出HTTP 1.0请求，但无论如何它都会响应，使用Keep-Alives和您不期望的所有内容。在一个完美的世界，它不应该发生，但确实如此。

你的错误可能在这方面。 Sinse你说你的请求正好花了60秒，我怀疑是因为它超时了。您可能已经收到了所有必需的内容，但是应用程序没有正确处理，而是在服务器终止连接之前挂起。

Answer 4

点数1：

在你的第1点，我相信你的意思是'1。是由于客户端发送....'和'在这种情况下，很多时候客户端正在以间隔获得响应....'。

第3点：

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

• 服务器响应的时间通常很快但是返回给你的时间结果（客户端）更多地与原始请求的作用有关，是否它只检索静态html文件，或者检索大图像或文档，或者必须在DB服务器上执行繁重的查询等。

• 您是唯一向服务器提交HTTP请求的客户端吗？可能不是。该服务器机器是否仅包含HTTP服务器？请记住，服务器正在或将要处理来自多个客户端的请求，这可能是有时延迟响应的另一个因素，即使服务器可以同时处理多个请求，也取决于其他请求正在执行的操作。由于多个请求而无法响应的HTTP服务器的极端示例是服务器处于[分布式]拒绝服务攻击之下。

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

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

第4点：

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

• 首先，所有其他不是延迟的主要因素，找出你期望的响应时间。

• 其次，确保您在合理的条件/环境下有一个合理的准确度量。我认为HTTP服务器不应该受到责备。

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

编辑：

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

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

  

<强> ping www.yahoo.com

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

1）注意往返如何采用aprox 0.5秒或更短（0.5秒= 500毫秒）。我在美国东海岸，雅虎可能会在美国西部成本（我不确定）。

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

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

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

Answer 5

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

Answer 6

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

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

C：\ Windows \ System32下\驱动程序\等\主机

或在linux系统中：

\等\主机

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