为什么得到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的将不会检测数据包，直到你的网卡已经转换成在路由器处理数据包 。

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

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

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

这是什么意思？

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

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

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

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

你有一个名为： tracert的实用程序

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

6 * 20

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

从客户端到服务器之间怎么样？

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

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

虽然怎么办？

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

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

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

我的代码虽然坚如磐石？

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

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

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

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

我假设您部署在一个位置，并且您可能处于远离服务器的几个状态。

工具：

命令行：

• 平
• TRACERT

网络和协议分析仪：

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

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

希望这能解释为什么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文件，还是检索大图像或文档，或必须在数据库服务器上执行繁重的查询等。

• 您是唯一向服务器提交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 \\ DRIVERS \\ ETC \\主机

或者在linux系统中：

\\等\\主机

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