wireshark tcp study notes

Time to live is a good indicator of number of hops a message has experienced.
Identification is a good indicator of source of message. (Identfication=0 will always send identification=0).

TCP delay acknowledgement: delay between message and ack, so that ack can be sent together with next message.It saves bandwidth but causes additional delay between message and ack. Especially if some messages are missing due to network congestion, delayed ack may cause unnecessary delay between resending of each message, especially for small window size
Delay ack can be turned off by TCP_QUICKACK.

TCP selective acknowledgement. (SACK) can be a mitigation of delay ack issue caused tcp message loss and resend. With TCP selective acknowledgement, only messages between ACK and SACK range are missing and need to resend, and they can be resent simultaneously without waiting for previous ack. This mechansim greatly reduces traffic generated and improves response time.

TCP handshake
client: SYN seq = x
server: SYN seq = y, ack = x + 1
client: seq = x+1, ack = y + 1
wireshark use relative sequence numbers to make display easier to read
failure to handshake:
server reject: (tcp.flags.reset == 1) && (tcp.seq == 1) then follow TCP stream
packet loss: (tcp.flags.syn == 1) && (tcp.analysis.retransmission) then follow TCP stream
Sync flood attack: send a lot of syn request with faked source address, server response will never receive ack, leave the connection half open and eventually cause resource depletion.
wireshark's analyze -> expert info -> chats will show total numbers of sync

Not every single tcp packet results in an ack, ack may be lazy. client may send 1,2,3,4,5 server ack 4 implies that all of 1-4 are received.
Client may send additional messages before receiving ack as long as sliding window is not full.
TCP is good for transmit large amount of data, for small chunk of data, it incurs additional cost of handshake.

statistics -> summary (show transmission speed)
statistics -> TCP stream graph -> TCP sequence graph (show speed change)

Silly window syndrome and nagle algorithm: for small packet, if previous data is not acked timely, cache the data until max segment size is reached and send together. (combine nagle algorithm and delay ack may cause slow transmission)

Frame check sequece (FCS) is used to check bad sequence. netstat -i can be used to show fcs error.

TCP close
client: FIN seq = x, ack = y
server: seq = y, ack = x + 1
server: FIN seq = y, ack = x + 1
client: seq = x + 1, ack = y +1
with delayed ack, it might combine message 2, 3 and become
client: FIN seq = x, ack = y
server: FIN seq = y, ack = x + 1
client: seq = x + 1, ack = y + 1

Prompt by wireshark
Packet size limited during capture (packet too large ). can be set with tcpdump -s packet size
Tcp previous segment not captured. usually: next packet seq = prev packet seq + packet len. If next packet seq > prev packet seq + packet len, it means that some packets are missing. check ack to verify whether it is packet loss or missing capture by wireshark. If packet is larger than MTU, it will be discarded.
Tcp acket unseen segment. Only ack but not the original message is captured, usually occurs at the start of capture.
Tcp out-of-order. if next packet sequence is less than prev packet sequence + length. Large range of out-of-orderness may cause too many duplicate ack and cause retransimssion.
Tcp dup ack. missing a packet in middle of sequence, cause it to be acked multiple times
Tcp fast retransmission. >=3 tcp dup ack triggers tcp fast retransmission
Tcp retransmision. last packet in a sequence is missing, and no further packet triggers dup ack. sender wait for timeout and triggers tcp retransmission
Tcp zerowindow. (win = 0) Receiver side's receiving buffer is full.
Tcp window full. data in transmission without ack >= receiver annouced window size (implies sender cannot send more data)
Fragment reassembly time exceeded. fragment packet cannot be assembled correctly

Bytes in flight = seq + len - ack
to detect network congestion, first detect retransmission in wireshark, find the origianl packet, calculate bytes in flight. Get a few samples, then you know the threshold of network congestion.

LSO (Large segment offload)
Sometimes, we cannot get original packet for a retransmission, this can due to LSO, if transmission data size is larger than MSS, instead of TCP layer segments data, network card segments data directly.

slow data transmission can due to small receiving window size or congestion window size. cwnd slow start: low value and increase fast, congestion avoidance: each RTT only increase one MSS. Bytes in flight of last packet in sending window represents cwnd. each ack may increase cwnd by 1 MSS, low ack frequency may cause slow increment of cwnd.

UDP fragment lost can cause reassembly time exceeded. For TCP, only resending lost fragment is needed, but not all fragments.

Fragmentation occurs when data size > MTU (usually 1500) - header size (20)
It is not easy to detect smallest MTU along the path, different MTU may cause refragmentation or packet discard.

ID + offset is used to reassemble fragment, last fragment contains flag (more fragments = 0)

TCP uses MSS, which is MTU - IP header - TCP header - TCP options, UDP does not have concept of MSS.
TCP handshake exchanges MSS, so that client can use the correct MSS to avoid fragmentation.
Don't fragment flag will cause packet to be discarded if it is less than MTU

firewall caused packet loss usually starts with handshake
network congestion caused packet loss will recover after sometime
check packet size of loss packet, large packet can be indicator of MTU problem.
ping -f -l [size] can be used to detect smallest MTU.

TCP handshake may send window scale, so that it can exceed limit imposed by tcp head window size.

Http hijacking: replicate http request in router and send faked http response before true response. Key charaecters: 1. different TTL of response. 2. identification discontinuation. 3. window size difference.

Http 1.1 limit number of concurrent connections to server to 2.
Use multiple http server increases number of concurrent requests, at the cost of tcp cwnd slow start. A ideal protocol: no handshake, no slow start, support multiplexing

TCP retransmission:
tshark -n -q -r <file name> -z io, stat, 0, tcp.analysis.retransmission, "tcp.analysis.retransmission and ip.src = <IP_A>", "tcp.analysis.retransmission and ip.src = <IP_B>"

wirshark -> prepare a filter -> selected (generate tshark expression)
http://www.wireshark.org/doc/main-pages/tshark.html

long transmission delay -> increase window size
high packet loss rate -> use tcp window scale, remove sending window's limitation on receiving window size
slow down sending rate when transmission delay increases
tuning window size for different connections to achieve priority
use selective acknowledgement
improve slow cnwd start size(default 4MSS) (retransmission due to timeout will also reset to default cnwd start size)
use tcp timestamps

Guess you like

Origin blog.51cto.com/shadowisper/2487689