Tcp Throughput Graph

Tcp Throughput Graph - tcp

I have created a TCP client/server chat software on console in vb.net..m using local host for this program means packets send and receive from the same network interface card..
now i captured packets from this software on Wireshark..and i want to plot TCp throughput graph from the data captured on wireshark but i am having problem with this..kindly help me..!
Also teach me which value should be taken on x and y axis..?
here is the data i captured on wireshark as i can't distinguished between sent and received pckets..!
No.,"Time","Source","Destination","Protocol","Info","New Column","New Column"
1,"0.000000","115.186.111.66","115.186.111.66","TCP","pda-data > versiera [PSH, ACK] Seq=1 Ack=1 Win=65510 Len=3","1","9050"
2,"0.441512","115.186.111.66","115.186.111.66","TCP","[TCP Retransmission] pda-data > versiera [PSH, ACK] Seq=1 Ack=1 Win=65510 Len=3","2","9050"
3,"0.442643","115.186.111.66","115.186.111.66","TCP","versiera > pda-data [PSH, ACK] Seq=1 Ack=4 Win=65532 Len=3","3","3253"
4,"0.829213","115.186.111.66","115.186.111.66","TCP","[TCP Retransmission] versiera > pda-data [PSH, ACK] Seq=1 Ack=4 Win=65532 Len=3","4","3253"
5,"0.949875","115.186.111.66","115.186.111.66","TCP","pda-data > versiera [ACK] Seq=4 Ack=4 Win=65507 Len=0","5","9050"
6,"1.259930","115.186.111.66","115.186.111.66","TCP","[TCP Dup ACK 5#1] pda-data > versiera [ACK] Seq=4 Ack=4 Win=65507 Len=0","6","9050"
7,"6.755535","115.186.111.66","115.186.111.66","TCP","pda-data > versiera [PSH, ACK] Seq=4 Ack=4 Win=65507 Len=3","7","9050"
8,"7.119189","115.186.111.66","115.186.111.66","TCP","[TCP Retransmission] pda-data > versiera [PSH, ACK] Seq=4 Ack=4 Win=65507 Len=3","8","9050"
9,"7.119833","115.186.111.66","115.186.111.66","TCP","versiera > pda-data [PSH, ACK] Seq=4 Ack=7 Win=65529 Len=3","9","3253"
10,"7.467483","115.186.111.66","115.186.111.66","TCP","[TCP Retransmission] versiera > pda-data [PSH, ACK] Seq=4 Ack=7 Win=65529 Len=3","10","3253"
11,"7.588601","115.186.111.66","115.186.111.66","TCP","pda-data > versiera [ACK] Seq=7 Ack=7 Win=65504 Len=0","11","9050"
12,"7.931341","115.186.111.66","115.186.111.66","TCP","[TCP Dup ACK 11#1] pda-data > versiera [ACK] Seq=7 Ack=7 Win=65504 Len=0","12","9050"
13,"11.311228","115.186.111.66","115.186.111.66","TCP","pda-data > versiera [PSH, ACK] Seq=7 Ack=7 Win=65504 Len=3","13","9050"
14,"11.650297","115.186.111.66","115.186.111.66","TCP","[TCP Retransmission] pda-data > versiera [PSH, ACK] Seq=7 Ack=7 Win=65504 Len=3","14","9050"
15,"11.650931","115.186.111.66","115.186.111.66","TCP","versiera > pda-data [PSH, ACK] Seq=7 Ack=10 Win=65526 Len=3","15","3253"
16,"11.953358","115.186.111.66","115.186.111.66","TCP","[TCP Retransmission] versiera > pda-data [PSH, ACK] Seq=7 Ack=10 Win=65526 Len=3","16","3253"
17,"12.114983","115.186.111.66","115.186.111.66","TCP","pda-data > versiera [ACK] Seq=10 Ack=10 Win=65501 Len=0","17","9050"
18,"12.388906","115.186.111.66","115.186.111.66","TCP","[TCP Dup ACK 17#1] pda-data > versiera [ACK] Seq=10 Ack=10 Win=65501 Len=0","18","9050"
19,"18.455431","115.186.111.66","115.186.111.66","TCP","pda-data > versiera [PSH, ACK] Seq=10 Ack=10 Win=65501 Len=3","19","9050"
20,"18.699858","115.186.111.66","115.186.111.66","TCP","[TCP Retransmission] pda-data > versiera [PSH, ACK] Seq=10 Ack=10 Win=65501 Len=3","20","9050"
Sorry i can't find a better way than this to post here my wirehsrak data :-O

Since you are monitoring a conversation between your PC and itself, yes, that would make it hard. Generally if you are the source, then You were sending, if you are the destination then you are receiving.
I would suggest X axis is time, Y axis is throughput.

Related

Strange TCP dump sequence

I have an intermittent but reproducible issue with a TCP connection.
Sender (port 64613) is running on a Windows box while the receiver (port 14004) is on a RedHat 6 host.
Ports are not part of the picture: the same issue happens with different ports.
The connection works fine for over a minute or so, with data and acknowledgement packets flowing normally.
But then the following behavior happens: the Wireshark capture on the sender side shows a packet being sent (seq=3020828):
57788 2018-07-16 15:36:20.552618000 10.245.40.74 10.245.54.13 TCP 2974 64613 -> 14004 [ACK] Seq=3020828 Ack=73535403 Win=65536 Len=2920
for which no ACK is ever received back.
The sender also keeps re-transmitting it in a smaller packet, up to 5 times before eventually giving up the connection:
58376 2018-07-16 15:36:20.851770000 10.245.40.74 10.245.54.13 TCP 1514 [TCP Retransmission] 64613 -> 14004 [ACK] Seq=3020828 Ack=74313583 Win=1296 Len=1460
58378 2018-07-16 15:36:21.101721000 10.245.54.13 10.245.40.74 TCP 1350 14004 -> 64613 [PSH, ACK] Seq=74313583 Ack=3020828 Win=4096 Len=1296 [TCP segment of a reassembled PDU]
...
60992 2018-07-16 15:36:22.652682000 10.245.40.74 10.245.54.13 TCP 1514 [TCP Retransmission] 64613 -> 14004 [ACK] Seq=3020828 Ack=77762103 Win=1296 Len=1460
60994 2018-07-16 15:36:22.658427000 10.245.54.13 10.245.40.74 TCP 1514 14004 -> 64613 [ACK] Seq=77762103 Ack=3020828 Win=4096 Len=1460 [TCP segment of a reassembled PDU]
...
91947 2018-07-16 15:36:39.456903000 10.245.40.74 10.245.54.13 TCP 54 64613 -> 14004 [RST, ACK] Seq=3022288 Ack=118789563 Win=0 Len=0
The tcpcap on the receiver side shows the packet being received (just in smaller splits, due to intermediate network device):
13573 2018-07-16 15:36:20.526327000 10.245.40.74 10.245.54.13 TCP 1514 64613 -> 14004 [ACK] Seq=3020828 Ack=73535403 Win=65536 Len=1460
13575 2018-07-16 15:36:20.526360000 10.245.40.74 10.245.54.13 TCP 1514 64613 -> 14004 [ACK] Seq=3022288 Ack=73535403 Win=65536 Len=1460
Also, the retransmitted packets are received fine, up to the final RESET packet:
13878 2018-07-16 15:36:20.825430000 10.245.40.74 10.245.54.13 TCP 1514 [TCP Retransmission] 64613 -> 14004 [ACK] Seq=3020828 Ack=74313583 Win=1296 Len=1460
18810 2018-07-16 15:36:36.047313000 10.245.54.13 10.245.40.74 TCP 29254 14004 -> 64613 [ACK] Seq=114189103 Ack=3020828 Win=20480 Len=29200 [TCP segment of a reassembled PDU]
...
13991 2018-07-16 15:36:21.425465000 10.245.40.74 10.245.54.13 TCP 1514 [TCP Retransmission] 64613 -> 14004 [ACK] Seq=3020828 Ack=74834803 Win=1296 Len=1460
13993 2018-07-16 15:36:21.433178000 10.245.54.13 10.245.40.74 TCP 27794 14004 -> 64613 [ACK] Seq=74834803 Ack=3020828 Win=4096 Len=27740 [TCP segment of a reassembled PDU]
...
14388 2018-07-16 15:36:22.626436000 10.245.40.74 10.245.54.13 TCP 1514 [TCP Retransmission] 64613 -> 14004 [ACK] Seq=3020828 Ack=77762103 Win=1296 Len=1460
14390 2018-07-16 15:36:22.632029000 10.245.54.13 10.245.40.74 TCP 32174 14004 -> 64613 [PSH, ACK] Seq=77762103 Ack=3020828 Win=4096 Len=32120 [TCP segment of a reassembled PDU]
...
19416 2018-07-16 15:36:39.431628000 10.245.40.74 10.245.54.13 TCP 60 64613 -> 14004 [RST] Seq=3020828 Win=0 Len=0
As you can see above, every time the receiver replies with the ACK message for the previous sequential number:
ACK for 3020828 instead of the new one (3020828 + 1460).
Eventually, the connection drops.
What could be a reason for the receiver to pick up new packets but producing ACKs for previous seq number?

What could be a reason for the receiver to pick up new packets but producing ACKs for previous seq number?
I would suggest that the recipient (i.e. the application at the RedHat system) has stopped reading the data. This will fill up the socket buffer and once the socket buffer is full no more data will be accepted by the OS kernel. The application is still writing though data to the original sender. But since the applications read socket buffer is full only the ACK for the last (and still unread) data in the socket buffer will be send together with the data written to the original sender.

Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)

I wrote a proxy server which support http and https connection, When I use with http all work fine, but when I work with https , wireshark report this error
'Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)'
Although the browsing work fine but performance is impacted as after this I see TCP RST and because of that SSL negotiation happen again.
Any clue on what could be wrong ?
169.254.119.252 169.254.1.66 TCP 66 54589 > ff-fms [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
169.254.1.66 169.254.119.252 TCP 60 ff-fms > 54589 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1456
169.254.119.252 169.254.1.66 TCP 54 54589 > ff-fms [ACK] Seq=1 Ack=1 Win=65520 Len=0
169.254.119.252 169.254.1.66 TCP 245 [TCP segment of a reassembled PDU]
169.254.1.66 169.254.119.252 TCP 912 [TCP segment of a reassembled PDU]
169.254.119.252 169.254.1.66 TCP 252 54588 > ff-fms [PSH, ACK] Seq=192 Ack=859 Win=64662 Len=198[Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)]
169.254.1.66 169.254.119.252 TCP 91 [TCP segment of a reassembled PDU]
169.254.119.252 169.254.1.66 TCP 54 54587 > ff-fms [RST, ACK] Seq=391 Ack=955 Win=0 Len=0

Why did this TCP retransmission occur in frame 7

Sorry for the bad formatting. But frame 7, I do not understand why a TCP retransmission was intiated. My understanding is that the retransmission occurs when an ACK is not returned in time and the send assumes that packet loss occurred and retransmits everything. What ACK not being returned resulted in this?
TCP: 57190 > 6007 [PSH, ACK] Seq=1 Ack=1 Win=64162 Len=200
TCP: 57190 > 6007 [PSH, ACK] Seq=201 Ack=1 Win=64162 Len=200
TCP: 57190 > 6007 [PSH, ACK] Seq=401 Ack=1 Win=64162 Len=200
TCP: 57190 > 6007 [PSH, ACK] Seq=601 Ack=1 Win=64162 Len=62
TCP: 6007 > 57190 [ACK] Seq=1 Ack=4294966897 Win=64240 Len=0 SLE=1 SRE=601
TCP: [TCP Dup ACK 5#1] 6007 > 57190 [ACK] Seq=1 Ack=4294966897 Win=64240 Len=0 SLE=1 SRE=663
TCP: [TCP Retransmission] 57190 > 6007 [PSH, ACK] Seq=4294966897 Ack=1 Win=64162 Len=1062
TCP: 6007 > 57190 [ACK] Seq=1 Ack=663 Win=63178 Len=0 SLE=1 SRE=663
TCP: 6007 > 57190 [PSH, ACK] Seq=1 Ack=663 Win=63178 Len=78
TCP: 57190 > 6007 [ACK] Seq=663 Ack=79 Win=64084 Len=0
Thanks,
Kyle

In TCP the receiver replies with ACK# of the next packet that it expects. If that packet is sent by the sender but is lost in the network and the receiver receives the packet next to the packet it was expecting, it will result in receiver sending another ACK with ACK# of the packet it is expecting next (in this case, the lost packet). And the sender after receiving the second duplicate ACK understands that the receiver hasn't received that particular payload (must have been lost) and it re-transmits it.

What timer prevents TCP window update packet loss

When the receiver of a TCP data stream closes its receive window (or, more exactly, the window is closed by the sender filling it up), there will be a flurry of packets which Wireshark would identify as TCP ZeroWindow and TCP Keep-Alive (repeated ACK with same sequence number). Some time later the receiver will send a new ACK to re-open the window (TCP Window Update) and data will start flowing again.
What TCP timer mechanism ensures that the window update packet is retransmitted if data does not start flowing?
Here is the sequence of packets that I see at the end of a connection (more data is expected):
No. Time Source Destination Protocol Length Info
122160 21:24:37.421824 192.168.15.121 72.21.81.253 TCP 60 41200 > http [ACK] Seq=462 Ack=2984241 Win=5152 Len=0
122162 21:24:37.445528 72.21.81.253 192.168.15.121 TCP 1514 [TCP segment of a reassembled PDU]
122163 21:24:37.445796 72.21.81.253 192.168.15.121 TCP 1514 [TCP segment of a reassembled PDU]
122164 21:24:37.446087 72.21.81.253 192.168.15.121 TCP 1514 [TCP segment of a reassembled PDU]
122171 21:24:37.481802 192.168.15.121 72.21.81.253 TCP 60 41200 > http [ACK] Seq=462 Ack=2988621 Win=784 Len=0
122184 21:24:37.744838 72.21.81.253 192.168.15.121 TCP 838 [TCP Window Full] [TCP segment of a reassembled PDU]
122185 21:24:37.745048 192.168.15.121 72.21.81.253 TCP 60 [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0
122190 21:24:38.014841 72.21.81.253 192.168.15.121 TCP 60 [TCP Keep-Alive] http > 41200 [ACK] Seq=2989404 Ack=462 Win=15872 Len=0
122191 21:24:38.014993 192.168.15.121 72.21.81.253 TCP 60 [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0
122232 21:24:38.534437 72.21.81.253 192.168.15.121 TCP 60 [TCP Keep-Alive] http > 41200 [ACK] Seq=2989404 Ack=462 Win=15872 Len=0
122233 21:24:38.534599 192.168.15.121 72.21.81.253 TCP 60 [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0
122314 21:24:39.564525 72.21.81.253 192.168.15.121 TCP 60 [TCP Keep-Alive] http > 41200 [ACK] Seq=2989404 Ack=462 Win=15872 Len=0
122315 21:24:39.564680 192.168.15.121 72.21.81.253 TCP 60 [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0
122361 21:24:43.403052 192.168.15.121 72.21.81.253 TCP 60 [TCP Window Update] 41200 > http [ACK] Seq=462 Ack=2989405 Win=119904 Len=0
122892 21:25:45.161896 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
122902 21:25:45.373289 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
122927 21:25:45.813267 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
122936 21:25:46.693275 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
122956 21:25:48.453337 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
123009 21:25:51.983392 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
123061 21:25:59.033566 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
123262 21:26:13.153852 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
123460 21:26:41.394469 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
The receiver re-opens the window at 21:24:43 and hears nothing more from the sender. A minute later the receiver times out the connection (the close is initiated by the application) and sends a series of FIN-ACKs which remain unacknowledged.
It looks like communication with the sender is simply lost (the capture was taken on the receiver's network). If not, then should one always expect an acknowledgement to the FIN-ACKs, even after a period long enough for the peer to have forgotten the connection?
Despite what RFC1122 may say on the matter, is it (common) practice for large Internet servers to do something different in this regard, perhaps as counter-DoS measures?

As you noted, the receiver sends a new ACK with an updated window size once space is available in its receive window.
In order to handle the case where that ACK is lost, the sender keeps a "persist timer" that will occasionally re-transmit a packet (a "window probe") in order to test the waters and see if there is indeed unreported receive space.
The value of the persist timer is not specified explicitly but rather is a function of the calculated round-trip time along with some exponential backoff. Full details are in RFC1122 in section 4.2.2.14, here: https://www.rfc-editor.org/rfc/rfc1122#page-92
The trace provided looks like something in the middle is blocking return traffic from the server. My guess would be that your NAT gateway (192.168.. is not a valid address on the Internet so something in between is doing network address translation) has decided the connection is gone and is refusing to forward additional packets back from the server.

TCP Windowsize 0 after FIN packet

Is it okay if a machine sets the TCP windowsize to zero after receiving a FIN?
I've got the following packet dump from wireshark of the end of the connection and I'm just wondering if this is a valid way to end a connection or if something is wrong.
192.168.1.1 192.168.1.6 TCP 3450 > 102 [FIN, ACK] Seq=48 Ack=50 Win=65486 Len=0
192.168.1.6 192.168.1.1 TCP [TCP ZeroWindow] 102 > 3450 [ACK] Seq=50 Ack=49 Win=0 Len=0
192.168.1.6 192.168.1.1 TCP 102 > 3450 [FIN, PSH, ACK] Seq=50 Ack=49 Win=0 Len=0
192.168.1.1 192.168.1.6 TCP 3450 > 102 [ACK] Seq=49 Ack=51 Win=65486 Len=0
BTW: .1 is a regular windows PC while .6 is a Siemens PLC. (S7-400)
After some investigation it looks like a weird but valid way to end a TCP conversation.

I see nothing wrong with sending a zero window after a FIN ACK... presumably 192.168.1.6 sent a FIN to 192.168.1.1, so they are now closing the connection.
192.168.1.6 192.168.1.1 TCP [TCP ZeroWindow] 102 > 3450 [ACK] Seq=50 Ack=49 Win=0 Len=0
But immediately setting a PSH flag and sending no data (Len=0) right after that ACK, looks rather odd (but not technically wrong) to me...
192.168.1.6 192.168.1.1 TCP 102 > 3450 [FIN, PSH, ACK] Seq=50 Ack=49 Win=0 Len=0

Develop Reference

r css asp.net wordpress firebase qt symfony nginx http apache-flex

Tcp Throughput Graph - tcp

Since you are monitoring a conversation between your PC and itself, yes, that would make it hard. Generally if you are the source, then You were sending, if you are the destination then you are receiving. I would suggest X axis is time, Y axis is throughput.

Related

Strange TCP dump sequence

Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)

Why did this TCP retransmission occur in frame 7

What timer prevents TCP window update packet loss

TCP Windowsize 0 after FIN packet

Categories

Resources