Shulou(Shulou.com)06/01 Report--

problem

To visit a website, it is quick to access it locally, but it takes about 3 seconds to access it from the client. Put a static web page on the server and return it quickly on the client side.

Troubleshooting steps

Visit the problem website on the client side and grab the package with wireshark on the client side

Use the tcp three-way handshake and the client request and the ACK returned by the server to determine whether there is a line or server busy problem, and it is found that it is not. 348-349 shows that the server responds quickly. It took 3.28 seconds between 349 and 498, indicating that this is a problem with the server application.

Let the developer investigate the server-side application, the developer said that there was a small function to grab the client MAC address, but to see the captured package, it should not be the client code, because the first web page response is more than 3 seconds, if the client code is also the subsequent JS or resource loading is slow.

No matter three, seven or twenty-one, I also grabbed the package on the server side. Filter the packets of arp and http, and find that there are three ARP requests, but there is no corresponding response. In addition, it is also wrong to look at the specific content of the ARP request carefully. It should be wrong for the server to use the ARP request to resolve the MAC address of the client, because the server and the client are not in the same network segment. Normal ARP requests across network segments are only used in the same network segment. If you cross the network segment, you should resolve the MAC address of the router. So there is a problem with these ARP requests.

The developer commented out the code for the client-side ARP address query. The speed of access has increased in an instant. The developer also noticed that the result of the client ARP address query is 00-00-00-00-00-00, which is consistent with the packet capture result on our server, because to request a MAC of a cross-segment IP address, the destination address will not be received, because the ARP broadcast will be terminated on the router side. Uncover the truth

The developer gave me the server-side code C #

```c#

[DllImport ("Iphlpapi.dll")]

Private static extern int SendARP (Int32 dest, Int32 host, ref Int64 mac, ref Int32 length)

[DllImport ("Ws2_32.dll")]

Private static extern Int32 inet_addr (string ip)

Public string getClientMac (string userip) {if (string.IsNullOrEmpty (userip)) return null; / / string userip = Request.UserHostAddress; string strClientIP = userip.ToString (). Trim (); Int32 ldest = inet_addr (strClientIP); Int32 lhost = inet_addr ("); Int64 macinfo = new Int64 (); Int32 len = 6; int res = SendARP (ldest, 0, ref macinfo, ref len); string mac_src = macinfo.ToString (" X ") / / if (mac_src = = "0") / / {/ / ip = userip; / /} while (mac_src.Length < 12) {mac_src = mac_src.Insert (0, "0");} string mac_dest = ""; for (int I = 0; I < 11) If (0 = = (I% 2)) {if (I = = 10) {mac_dest = mac_dest.Insert (0, mac_src.Substring (I, 2));} else {mac_dest = "-" + mac_dest.Insert (0, mac_src.Substring (I, 2)) } return mac_dest;} * according to the code logic, the server should have used one SendARP call, but why three ARP requests were made, and the wait time varies between different ARP request packets. So to verify the actual operation of this SendARP call, I wrote the above sendARP call with powershell, and then grabbed the package with wireshark. ```powershellFunction Send-Arp {param ([string] $DstIpAddress, [string] $SrcIpAddress = 0) $signature = @ "[DllImport (" iphlpapi.dll ", ExactSpelling=true)] public static extern int SendARP (uint DestIP, uint SrcIP, byte [] pMacAddr, ref int PhyAddrLen) "@ Add-Type-MemberDefinition $signature-Name Utils-Namespace Network try {$DstIp = [System.Net.IPAddress]:: Parse ($DstIpAddress) $DstIp = [System.BitConverter]:: ToInt32 ($DstIp.GetAddressBytes (), 0)} catch {Write-Error" Could not convert $($DstIpAddress) to an IpAddress type. Please verify your value is in the proper format and try again. " Break} if ($SrcIpAddress-ne 0) {try {$SrcIp = [System.Net.IPAddress]:: Parse ($SrcIpAddress) $SrcIp = [System.BitConverter]:: ToInt32 ($SrcIp.GetAddressBytes (), 0)} catch {Write-Error "Could not convert $($SrcIpAddress) to an IpAddress type. Please verify your value is in the proper format and try again." Break} else {$SrcIp = $SrcIpAddress} $New = New-Object PSObject-Property @ {IpAddress = $DstIpAddress PhysicalAddress =''Description =' 'ArpSuccess = $true} | Select-Object IpAddress,PhysicalAddress,ArpSuccess,Description $MacAddress = New-Object Byte [] 6$ MacAddressLength = [uint32] $MacAddress.Length $Ret = [Network.Utils]: SendARP ($DstIp, $SrcIp, $MacAddress) [ref] $MacAddressLength) if ($Ret-ne 0) {$New.Description = "An error was returned from SendArp () with error code: $($Ret)" $New.ArpSuccess = $false} else {$MacFinal = @ () foreach ($b in $MacAddress) {$MacFinal + = $b.ToString ('X2')} $New.PhysicalAddress = ($MacFinal-join':')} Write-Output $New}

Use powershell to resolve a target IP address across the network segment, followed by the ping target host, so that the end time of the sendARP can be obtained based on the start time of the ping packet.

The powershell command is as follows:

Send-arp serverIP; ping serverIP grabs the packet filter ARP and ICMP to verify. The SendARP function will send three ARP packets and may also wait for a timeout. Because there is no response from the ARP package, the test time is about 3.1 seconds, which is consistent with the problem.

Finally, it is concluded that:

Local access on the server is very fast because the server uses ARP requests to look up the machine, and there should be a response soon. It is estimated that it will not be slow if other clients and servers are on the same network segment.

The reason why the client is slow is that when the server returns the http information to the client, it first uses ARP to request the client IP across the network segment, but there will be no ARP response. Because of routing, the client cannot see the ARP request from the server, and the timeout of the SendARP function is about 3.1 seconds, so the client across the network segment receives a HTTP response from the server in about 3.28 seconds. Similarly, simply grabbing the package on the client side can only analyze the problems with the server application, but can not say the specific problems.

Static pages are fast because static pages do not execute server-side code, so ARP queries are not executed.

In addition, developers should also be familiar with common network protocols, such as this time, the code will only work in specific scenarios, if the site is Internet-oriented, then this code will not work, but will affect performance.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.