The source IP address is 192.168.4.27 and its port number is 60268
The destination IP address is 128.119.245.12 and its port number is 80
–
The relative sequence number of the initial TCP segment is 0. The raw sequence number is 378842094. It is identified as a SYN segment because the SYN flag is set.
The relative sequence number of the second TCP segment is 0. The raw sequence number is 1147676677. The raw acknowledgment number is 378842094; that is the last received segment’s sequence number + 1. It is identified as a SYNACK segment because the SYN and ACK flags are both set.
The sequence number of the TCP segment containing the HTTP POST command is 1 (378842095).
(Relative) sequence numbers for the first six segments in the TCP connection were: 1, 714, 2162, 3610, 5058, 6506. The times at which those segments were sent were: 3.042440, 3.042623, 3.042623, 3.042624, 3.042625, 3.042626. The times at which those segments were acknowledged were: 3.044654, 3.070550, 3.070556, 3.070557, 3.070557 (cumulative acknowledgment of relative sequence 10850). The RTT values (acknowledgment time - sent time) for each segment were: 0.002214, 0.027927, 0.027933, 0.027933, 0.027932, 0.027931. The running EstimatedRTT for each segment (assuming EstimatedRTT = measured RTT for the first segment) is given by the formula EstimatedRTT = (1 - alpha) _ EstimatedRTT + alpha _ SampleRTT, where the recommended value for alpha is 1/8 = 0.125. That yields a running EstimatedRTT of: 0.002214, 0.005428, 0.008241, 0.010702, 0.012856, 0.014740.
The lengths of each of the first six TCP segments were: 713, 1448, 1448, 1448, 1448, 1448.
The minimum amount of buffer space advertised by the receiver is 235. This comes in the first ACK segment from the server after the SYNACK segment in the three-way handshake. This appears to cause throttling on the part of the sender, which had been sending packets at a rate of about one per microsecond. After receiving the ACK with window size 235, the sender stops sending segments until it receives a second ACK ~26 milliseconds later with a calculated window size of 30464. 3 more ACKs are then received within the next 7 microseconds, each one of which further increases the window size, and the sender resumes sending segments about 100 microseconds later at the originally observed rate of about 1/microsecond. Throughout the connection, pauses of 1-15 milliseconds are observed between data segments from the sender and ACK segments from the receiver; in these cases, the sum of bytes sent by the sender between the byte acknowledged by the receiver and the next pause consistently appears to be ~1/2 the size of the receive window specified in the ACK segment. For example, segemnt 147 specifies a window size of 150,008 and acknowledges segment 103. Between segment 103 and the next ACK segment after 147 (segment 167), the sender sends 53 data segments each containing 1448 bytes of data, for a total of 76,744 (~150,008/2). This suggests that the sender is throttling itself to fill just half of the window size.
No segments were retransmitted in this trace, since for all segments in the trace either the Acknowledgment number or Sequence number was different (that is to say, every segment was uniquely identified by the double (ack no, seq no)). This is easy enough to check manually, because either the Acknowledgment number or Sequence number always increased with respect to the previous segment, so all segments were in order.
Consecutive ACK segments typically differed in there Acknowledgment number by 5792 or 2896, that is to say, receiver was acknowledging 2-4 segments at a time.
HTTP POST request was initiated at 3.017912 and finished at 3.140010 for a total of 0.122098 seconds and contained 148722 bytes = 145.24kB. 145.24 / 0.122098 = 1189.54 kB/s of throughput.
We initially see a the slow-start phase operating as expected, as the sender sends two segments for each acknowledged segment until four segments are in flight. The sender then waits for all four segments to be acknowledged and then begins sending segments in bursts of six at a time, waiting for all six to be acknowledged before sending the next burst. This does not appear to be due to congestion control, since there are no duplicate ACKs or timeouts, or flow control, since the receiver’s receive window keeps going up, but more segments are not sent to fill it.
In this case there does not appear to be any probing; after the three-way handshake, a burst of segments is sent immediately.