建议:检查客户端/HTTP Web服务器之间的连接 [英] Suggestion: Check connection between Client/HTTP Web Server
问题描述
我正在尝试编写一个小应用程序，该应用程序可以连续检查运行它的PC和HTTP Web服务器之间的连接.
因此，我有一台运行Windows的PC和位于同一LAN上的Web服务器，我需要检查PC是否可以访问Web服务器:我只需要说Web服务器仍在运行即可.
主要问题是我不知道什么是最好的方法.由于我位于有线小型局域网上，因此我对数据包丢失没有任何问题，但我正在寻找一种经济实惠的方法.
所以我认为这些解决方案
1.使用ICMP.定期发送"ECHO REQUEST"并等待答复.如果我没有及时得到答复，则认为它已关闭.
2.使用套接字TCP.我可以将connect(..)和close(...)放在一个循环中.当套接字在连接后返回错误时，我认为它已关闭.
3.使用套接字TCP.我可以通过发送发送一条消息，然后等待响应.如果我没有收到消息，则认为它已关闭.
在第一种情况下，我真的很担心最终的临时拥塞会导致数据包丢失的后果，并假设Web服务器已关闭.我不知道如何在那里获得控制权.
在第二个中，我不知道是否足以假设服务器已关闭，也不安全且正确地将连接和闭合置于一个循环中，因为我还必须在其中包含套接字初始化循环.
在第3种情况下，由于主机上运行的是特定的HTTP Web服务器，我可能会遇到一些限制(例如，在3秒内经过18次尝试后，我无法得到回复).
我需要一个可靠的解决方案(它不能说Web服务器在无法访问时不再可访问)并且要快速(我想在不到1/2秒的时间内检测到Web服务器何时断开连接).我不在乎局域网流量.
如果有人可以帮助我，我将不胜感激.
感谢您的时间.
只需向http服务器发送了标头请求，
彻底了解该过程，您将了解两种状态，
1.如果您的机器还活着??
2.如果您的服务器还活着??
还可以使用
http1.1作为协议版本.还要确保保持活动参数，以查看详细信息，请访问链接 [ ^ ]
<最好的方法是请求HTTP获取测试页.这样，您可以确定整个链条都可以正常工作.
ICMP回声(也称为ping)不可靠:某些网络可能会对其进行过滤，并且某些服务器由于其管理者的意愿而无法响应"它们. (我相信这是一个被误解的安全概念，但是确实存在)
一个TCP套接字到与HTTP守护程序使用的端口不同的任何端口，都可以证明操作系统和守护程序对套接字的响应仍然有效，但是HTTP守护程序可能会关闭或崩溃，并且您永远不会知道.更不用说防火墙可能会过滤您的套接字，这是HTTP服务器无法预料的！
对于问题的最后一部分，很抱歉，但是您要问的是IP网络无法授予的内容:IP是无连接的，TCP是面向连接的，而HTTP是无状态的.您和服务器之间可能有数十台路由器，并且如果网络中发生了某些变化，则网络路由协议必须找到一种将您带到另一条路径上的目的地的方法.根据所涉及的参与方的多少，此过程可能需要几秒钟(TCP通常会等待确认1/2秒，而不是在报告套接字故障之前在1.5、3、4.5、15秒后重试.)在所有这些时间内，服务器可能完美连接，工作和聆听.只是网络正在改变其形状.
您无法检查IP网络中是否存在其他物理连接.只是那不会离开您的身边.
对于TCP/IP的工作原理，1/2秒钟根本就太少了，无法做出有关服务器状态的任何决定，而且，从客户端的角度来看，您唯一可以想到的就是服务器不可访问，而不是它是断开连接".这是只有服务器本身才能知道的事件.
除非(但您没有提到)，否则客户端和服务器都位于同一个LAN上，没有任何设备执行任何类型的信号(L1)，帧(L2)或数据包(L3)中继. (这意味着:LAN本身只是客户端和服务器之间的物理连线)
Hi,
i''m trying to write a little app that can continuously check connection between a PC on which it''s running on, and and HTTP web server.
So i have a PC Running Windows and a Web Server on the same LAN and i need to check if the PC can reach the web server: i just need to say that the web server is still alive.
The main issue is that i don''t know what''s the best way to do that. Since i''m on a cabled and small LAN, i don''t have issue regarding packet loss but an affordable method is what i''m looking for.
So i thought those solutions
1. Use ICMP. Periodically send a "ECHO REQUEST" and wait for the reply. If i don''t get a reply in time, i assume that it was shut down.
2. Use a Socket TCP. I can put a connect(..) and close (...) in a loop. When the socket return an error after the connect, i assume that it was shut down.
3. Use a socket TCP. I can send a message trough the send and wait for the response. If i don''t get a message, i assume it was shut down.
In the 1st case, i really fear a situation in which an eventual temporary congestion would cause a packet loss with a consequence assumption that the web server is down. I don''t have a clue how to get a control there.
In the 2nd, i don''t know if it''s sufficient to assume that the server is down nor it''s safe and correct to put connect and close in a loop cause i have also to include the socket initialization in the loop.
In the 3rd, i can encounter some limitation due to the specific HTTP web server running on the host (for example i can''t get a reply after 18 tryies in 3 seconds).
I need a solution that is reliable (it must not say that the web server is no more reachable, when it''s not) and speedy (i want to detect when the web server is disconnected after less than 1/2 seconds). I don''t care about lan traffic.
It would be really appreciated if someone can help me.
Thanks for your time.
Just sent http server a header request,
thorough out the process, you will know two status,
1. If your machine is alive??
2. If your server is alive??
And Also use
http1.1 as protocol version. And also make sure keep-alive paramter, to see the detail go to the link[^]
The best way is to ask an HTTP get for a test page. This way you are sure that the entire chain actually works.
ICMP echo (aka ping) is not reliable: some networks may filter them, and some server can "not respond" to them because of the wish of their managers. (I believe this is a misunderstood concept of security, but there it is)
A TCP socket to whatever port different then the one used by the HTTP daemon demonstrate that the operating system and the daemon responding to your socket is alive, but the HTTP daemon can be shut-down or crashed and you''ll never know. Not to mention that a firewall may filter your socket being something different an unexpected for an HTTP server!
For the last part of your question, sorry but you''re asking something an IP network cannot grant: IP is connectioless, TCP is connection oriented, and HTTP is stateless. The may be dozens of routers between you and the server, and if something is changing in the network, the network routing protocols have to find a way to take you to the destination on another path. Depending on how many parties are involved, this process can take seconds (TCP typically waits an acknowledge for 1/2 second than it retries after 1.5, 3, 4.5, 15 seconds bfore reporting a socket failure.) In all this time the server may be perfectly connected, working and listening. Simply the network is changing its shape.
There is no way you can check for somebody else physical connection in an IP network. Simply that doesn''t leave at your side.
1/2 of a second is simply too few -for how TCP/IP works- to take whatever decision about a server status, and also, from a client pherpective, the only thing you can assume is that the server is unreachable, not that it is "disconnected". This is an event that only the server itself can know.
Unless (but you didn''t mention) both client and server are sitting on a same LAN with no devices performing whatever kind of signal (L1), frame (L2) or packet (L3) relaying. (That means: the LAN itself is just a physical wire between the client and the server)
这篇关于建议:检查客户端/HTTP Web服务器之间的连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
