为什么得到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秒,我怀疑是因为它超时了.您可能已经收到了所有必需的内容,但是应用程序没有正确处理,而是挂起,直到服务器终止连接.