The Basics of Reading TCP/IP Traces

来源:互联网 发布:淘宝banner加链接 编辑:程序博客网 时间:2024/05/17 01:07

From: http://support.microsoft.com/kb/169292

TCP Flags

A, ACK- (Acknowledge) The receiver will send an ACK that equals thesenders sequence number plus the Len, or amount of data, at the TCP layer.

SYN, and FIN flags count as 1 byte. The ACK can also be thought of asthe sequence number of the next octet the receiver expects to receive.

S, SYN- Synchronize is used during session setup to agree on initialsequence numbers. Sequence numbers are random.

F, FIN- Finish is used during a graceful session close to show that thesender has no more data to send.

R, RST- Reset is an instantaneous abort in both directions (abnormalsession disconnection).

P, PSH- Push forces data delivery without waiting for buffers to fill.This is used for interactive traffic. The data will also be delivered tothe application on the receiving end with out buffering.

U, URG- Urgent- Data is sent out of band.

 

Example of 3 Way Hand Shake
--------------------------------------------------------------
Time Dst IP Src IP Protocol Description
20.862 157.57.24.193 157.57.11.169 TCP ....S., len: 4, seq: 346564214, ack: 0, win: 8192,
20.866 157.57.11.169 157.57.24.193 TCP .A..S., len: 4, seq: 339000739, ack: 346564215, win: 8760,
20.866 157.57.24.193 157.57.11.169 TCP .A...., len: 0, seq: 346564215, ack: 339000740, win: 8760,
Example of Graceful Close (Modified 3 Way Hand Shake)
Time Dst IP Src IP Protocol Description
39.295 157.57.11.169 157.57.24.193 TCP .A...F, len: 0, seq: 339000917, ack: 346564257, win: 8718,
39.295 157.57.24.193 157.57.11.169 TCP .A...., len: 0, seq: 346564257, ack: 339000918, win: 8583,
39.298 157.57.24.193 157.57.11.169 TCP .A...F, len: 0, seq: 346564257, ack: 339000918, win: 8583,
39.300 157.57.11.169 157.57.24.193 TCP .A...., len: 0, seq: 339000918, ack: 346564258, win: 8718,

In the above two traces, transmission control protocol (TCP) is the highestlayer protocol, so the relevant session information can be read from thesummary line of the trace. If there is a higher layer protocol (NBT, SMB,Telnet, FTP, etc.), you will have to look in the packet for the TCP flags,acks and sequence numbers.

 

Re-transmission Behavior

(from "TCP/IP Implementation Details")

TCP starts a re-transmission timer when each outbound segment is handeddown to IP. If no acknowledgment has been received for the data in a givensegment before the timer expires, then the segment is retransmitted, up tothe TcpMaxDataRetransmissions times. The default value for this parameteris 5.

The re-transmission timer is initialized to 3 seconds when a TCP connectionis established; however it is adjusted "on the fly" to match thecharacteristics of the connection using Smoothed Round Trip Time (SRTT)calculations as described in RFC793. The timer for a given segment isdoubled after each re-transmission of that segment. Using this algorithm,TCP tunes itself to the "normal" delay of a connection. TCP connectionsover high-delay links will take much longer to time out than those over low-delay links.

The following trace clip shows the re-transmission algorithm for two hostsconnected over Ethernet on the same subnet. An FTP file transfer was inprogress, when the receiving host was disconnected from the network. Sincethe SRTT for this connection was very small, the first re-transmission wassent after about one-half second. The timer was then doubled for each ofthe re-transmissions that followed. After the fifth re-transmission, thetimer is once again doubled, and if no acknowledgment is received before itexpires, then the transfer is aborted.

delta source ip    dest ip      pro flags   description
--------------------------------------------------------------
0.000 10.57.10.32 10.57.9.138 TCP .A...., len: 1460, seq: 8043781, ack: 8153124, win: 8760
0.521 10.57.10.32 10.57.9.138 TCP .A...., len: 1460, seq: 8043781, ack: 8153124, win: 8760
1.001 10.57.10.32 10.57.9.138 TCP .A...., len: 1460, seq: 8043781, ack: 8153124, win: 8760
2.003 10.57.10.32 10.57.9.138 TCP .A...., len: 1460, seq: 8043781, ack: 8153124, win: 8760
4.007 10.57.10.32 10.57.9.138 TCP .A...., len: 1460, seq: 8043781, ack: 8153124, win: 8760
8.130 10.57.10.32 10.57.9.138 TCP .A...., len: 1460, seq: 8043781, ack: 8153124, win: 8760

After computer "X's" retries are exhausted, you may not see a "Reset" rightaway. If computer "Y" finally responds, computer "X" may then reset theconnection.

 

Sliding Windows

During the handshake, the send window size is set to the other host'sreceive window. The window size is a buffer and is the amount of data thesender can send and the receiver can receive without an ack. The "window"can slide forward after that packet is acknowledged.

With a receive window of 8760, the sender may send 8760 bytes beforereceiving an ack. The receiver could ack every packet, every other packetor the entire 8760 depending on the IP stack and timing. (See Delayed AckTimer, and Retransmit timer) Windows NT will ack every other packet. If thepackets are coming extremely fast, you may see Windows NT ack more than 2packets. If the PUSH bit set, data will be delivered up to the applicationright away, but the ack may still be delayed.

The sequence number in frame 51 is 349349990. The ack in frame 57 is349358750. This is the sequence number from frame 51 plus the amount ofdata received in frames 51 through 56 (6 frames x 1460 =8760) . Also, theack 349358750 is the sequence number of the next packet that the hostexpects to receive.

Frame   Time    Src Other Addr  Dst Other Addr  Protocol  Description
---------------------------------------------------------------------
50 3.923 157.57.11.169 157.57.24.193 TCP .A...., len: 0, seq: 356870796, ack: 349349990, win: 8760,
51 3.924 157.57.24.193 157.57.11.169 FTP Data Transfer To Client, Port = 1636, size 1460
+ TCP: .A...., len: 1460, seq: 349349990, ack: 356870796, win: 8760, src: 20 dst: 1636
52 3.940 157.57.24.193 157.57.11.169 FTP Data Transfer To Client, Port = 1636, size 1460
53 3.941 157.57.24.193 157.57.11.169 FTP Data Transfer To Client, Port = 1636, size 1460
54 3.943 157.57.24.193 157.57.11.169 FTP Data Transfer To Client, Port = 1636, size 1460
55 3.944 157.57.24.193 157.57.11.169 FTP Data Transfer To Client, Port = 1636, size 1460
56 3.946 157.57.24.193 157.57.11.169 FTP Data Transfer To Client, Port = 1636, size 1460
57 3.947 157.57.11.169 157.57.24.193 TCP .A...., len: 0, seq: 356870796, ack: 349358750, win: 4096,


The window size is also used for flow control. If a host is advertising asmaller window size when its buffers are filling, or a window size of 0 ifit can not receive data at all. In frame 50 above, the host is advertisinga window size of 8760 and in frame 57 it has been dropped to 4096.

 

 

Ports, Connections, and Endpoints

Port numbers define the ultimate destination within a computer. Connectionsare identified by a pair of endpoints. An Endpoint is the (host, port). Ex.(199.199.40, 21)

 

Port Numbers

The port numbers are divided into three ranges: the Well-Known Ports,the Registered Ports, and the Dynamic and/or Private Ports. The Well-Known Ports are those from 0 through 1023.The Registered Ports are those from 1024 through 49151. The Dynamic and/or Private Ports are those from 49152 through 65535.

Well-Known Ports are assigned by Internet Assigned Numbers Authority (IANA) andshould only be used by System Processes or by programs executed by priviledgedusers. An example of this type of port is 80/TCP and 80/UDP. These ports arepriviledged and reserved for use by the HTTP protocol.

Registered Ports are listed by the IANA and on most systems can be used byordinary user processes or programs executed by ordinary users. An example ofthis type of port is 1723/TCP and 1723/UDP. Although these ports can be used byother processes they are generally accepted as the connection control port forPoint To Point Tunnelling Protocol (PPTP).

Dynamic or Private Ports can be used by any process or user. They areunrestricted.

IANA maintains a list of ports on their Web site at:

http://www.iana.org/assignments/port-numbers (http://www.iana.org/assignments/port-numbers)

Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

 

Trace Reading Suggestions

Follow a session using source and destination IP address and Port numbers.If you find a Reset, focus on the sequence numbers and acks that proceedit. Use a calculator to see what ack is corresponding to what data sent.Newer versions of NetMon will do the calculations for you. Is the senderdoing retries? Note the number of retries and the time elapsed. The defaultnumber of retries is 5. Is the receiver asking for a missed frame by ACKinga previous sequence number? Did the sender back up and resend the previouspacket? A Reset can be caused by time-outs at the TCP layer or by time outsof higher layer protocols. Resets originating at the TCP layer should beeasy to read from the trace. It may be more difficult to determine thecause of Resets originating from higher layer protocols.

For example, a Server Message Block (SMB) read may time out in 45 secondsand cause a Reset of the session even though communications are slow butworking at the TCP layer. The trace may only narrow down what component isat fault. From there you may need to use other troubleshooting methods todetermine the cause.

To see TCP sequencing when higher-level protocols are present, startNetwork Monitor and perform the following steps:

  1. Click Capture, and then choose Display Captured Data.
  2. Click Display, and then choose Options.
  3. Select Auto (Based on protocols in display filter), and then click OK.
  4. Click Display, and then choose Filter.
  5. Double-click Protocol=Any.
  6. Click the Protocol tab, and then click Disable All.
  7. In the Disabled Protocols list box, choose TCP.
  8. Click Enabled, then click OK.
  9. Click OK.

 

References:

TCP/IP Illustrated Volume 1; W. Richard Stevens
TCP/IP Illustrated Volume 2 ; Gary R. Wright and W. Richard Stevens
Internetworking with TCP/IP Volume 1; Douglas E. Comer
Internetworking with TCP/IP Volume 2; Douglas E. Comer and David L. Stevens
"TCP/IP Implementation Details"; Dave MacDonald