Using tcpdump to locate server and client communication problems

Note: Tcpdump needs to log in with the root account

First, the application scenario 1

The packet sent by the client, after the server was untied, found the packet wrong?

[Root@ied_224_42_sles10_64]~>tcpdump-i eth1 Port 8029-x

Tcpdump:verbose output suppressed, use-v OR-VV for full protocol decode

Listening on eth1, Link-type EN10MB (Ethernet), capture size bytes

11:03:06.125337 IP 10.18.124.47.4217 > 10.6.224.42.8029:p 651073194:651073233 (km) ACK 1685844515 win 64472

0x0000:4500 004f 056d 4000 3a06 caca 0a12 7c2f E. o.m@.:.....| /

0x0010:0a06 e02a 1079 1f5d 26ce 96aa 647b f223 ... *.y.] &...d{.#

0x0020:5018 fbd8 51a5 0000 0027, 0001 0000 0000 P ... Q. .....

0x0030:0000 0000 0000 02bd 03ea 2540 0000 0000 ....%@ .....

0x0040:0000 0000 0a40 4553 355a 4961 5969 5a .... @ES5ZIaYiZ

11:03:06.125869 IP 10.6.224.42.8029 > 10.18.124.47.4217:. ACK-1460 win

0X0000:4500 0028 b292 4000 4006 17cc 0a06 E.. (.. @.@......*

0x0010:0a12 7c2f 1f5d 1079 647b f223 26ce 96d1. | /.]. Yd{.#&

0x0020:5010 05b4 f599 0000 P .....

[MSG version= "1"]:

[M_stmsghead]

M_shmsgversion=1

M_uitimestamp_low=0

M_uitimestamp_high=0

M_uimsgid=account_createrole_request

m_uiuin=65676608

M_ifeedback=0

M_uibodylength=0

M_ucskeylength=0xa

m_szsessionkey[10]=0x40 0x45 0x53 0x35 0x5a 0x49 0x61 0x59 0x69 0x5a

[M_stmsgbody]

[M_staccountcreaterolerequest]

Can see this line for the client to the server packet, and then according to the protocol above, it is obvious that the client sent over the package is problematic, there is no msgbody part of the interior.

11:03:06.125337 IP 10.18.124.47.4217 > 10.6.224.42.8029:p 651073194:651073233 (km) ACK 1685844515 win 64472

Second, the application scenario 2

The client sends a login request, but receives a package that has no msgbody part of the content on the server side?

command with Scene 1, from the tcpdump print see the server did receive the full packet, but at the server logic layer received is empty msgbody, it is obvious that the problem is in the server access layer.

Then to the access layer positioning, quickly found that because of configuration reasons, the access layer to the client data packet validation does not pass, the problem is found.

Third, the application scenario 3

In a very high time delay scene (MS level), the server sent the packet, the client failed to receive timely?

Or the client sent the packet, the server did not receive in time?

command with Scene 1, from the log can be seen that the server did not send on time, in the server logic layer printing time, but is sent on time, this is strange?

Further think of the send layer, think of TCP delay send and delay confirmation, Nagel algorithm, set sock no delay attribute, close the Nagel algorithm can be.

This column more highlights: http://www.bianceng.cnhttp://www.bianceng.cn/Servers/zs/