Should you be concerned if you see this Expert warning in your trace file? Maybe. There are several possible reasons these may be in your trace file.
What Does this Expert Warning Mean?
The Expert warning ACKed Segment that wasn't Captured, identified with TCP ACKed unseen segment in the Info column, indicates that this trace file does not contain the data packet for this acknowledgment.
Walk-Through Example
Let's look at the example below.
In frame 3, the client sends a GET request to the server with Sequence Number 1 and 756 bytes of data. The next sequence number this client sends should be 757 (outbound SEQ# + data bytes = next SEQ#).
Frame 4 is an ACK from the server. This frame acknowledges receipt of the GET request - the Acknowledgment Number field is set to 757, which means, "I received everything up to, but not including your Sequence Number 757.
If all goes well, we now expect the server to send a 200 OK and at least the start of the requested file.
Frame 5, however, is an ACK from the client. This is the frame marked with TCP ACKed unseen segment. Where is that data from the server? In frame 5, the client indicates (via the Acknowledgment Number value) that it has received everything up to but not including Sequence Number 2639 from the server.
Where are the data packets covering Sequence Numbers 757-2638?
Frame 6 is marked as TCP Previous segment not captured (but we already know we are missing some data packets).
Situation #1: Capturing Existing TCP Connection
This is pretty common - if a TCP connection has already been established when you started capturing its traffic, well... you missed the data packets being ACKed. This is why the Expert indicates "(common at capture start)." Filter on the TCP conversation to make sure you aren't looking at the top of a previously established connection.
Situation #2: Faulty Capture Process
Almost every time I come across this issue, if the TCP ACKed unseen segment isn't at the top of a previously existing connection, it is an indication that the capture tool could not keep up with the traffic rate and it dropped data packets.
If you are using Wireshark to capture traffic and it can't keep up - try applying a capture filter to reduce the traffic that Wireshark needs to capture. If that doesn't work, it's time to make a change. You can try to go directly to the command-line tool dumpcap or even tcpdump. It may, however be time to get a decent tap that can keep up with and capture the traffic.
Situation #2: Asymmetrical Data Paths
I've hit this one a few times in my career - it's strange and atypical. The image below provides an example of asymmetrical data paths. If you capture along one path, but data and the ACKs travel on separate paths, you'll only see part of the picture when you capture traffic.
Always pay attention to the Expert when analyzing traffic - it can identify problems in the network traffic as well as the capture process.