![]() ![]() 196 shows “TCP previous segment not captured” and “SEQ = 1011” in the packet, while the last server side packet we caught needs to be “SEQ = 1”, indicating that there is 1010 in it We didn’t catch the byte packet 196 indicates that the server thinks that it has completed the service request, but the client does not actively close the connection, so it has to actively close the connection after 20 seconds packet No. It should be noted that: the above two screenshots are captured during continuous testing through curl, and the recurrence probability of the problem is very high because the server is in the cloud, it can only perform packet capture analysis on the local client sideįor the abnormal data packets, the analysis is as follows: In abnormal cases, we can see that the server actively closes the TCP connection after 20 seconds, and Wireshark’s expert information tells us that there are packets that have not been captured (TCP previous segment not captured) Under normal circumstances, the server will respond quickly after receiving the HTTP request, and the TCP connection closure is initiated by the client side Two days ago, I met such a strange phenomenon: when I send an HTTP request to a service, there will be packet loss in probability
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |