When you want to troubleshoot general network issues, the best thing to do is analyze tcp packets flow in the network. I came across this when I am working at WSO2, I believe this can be useful for Software Engineers in any context.
In this article, I will give a brief introduction to the TCP theories, but I will put references for those who like to read more about this.
How TCP works
Bascially, TCP is a transport layer protocol. TCP will connect one socket (IP address + port) of the source host to a socket in the destination host. IP header will carry the IP addresses related information and TCP will carry the port information.
For more info 
TCP headers will travel through the network to establish, data transfer, maintain and termination of TCP connections.
Fields in the TCP Header
- source port: Port of the host where the request is originated
- destination port: Port of the host where the request is headed
- sequence number: This will keep a track of the ordering of messages. Each endpoint(source and destination) will maintain their sequence number. At the start of the TCP connection (message with SYN flag is set) a random number will get generated as the sequence number. It will get incremented by 1 for SYN packets, FIN packets and for each byte of data sent. For more info 
- acknowledgement number: When the ACK flag is set then the value in the acknowledge number field is the next sequence number sender is expecting. One acknowledge number will acknowledge all the bytes sent before it. For more info 
- data offset: Contains the size of the TCP header in 32 bits of segments. Minimum size of the TCP header is 5, 32 bit segments(20 bytes) and maximum is 15 (60 bytes)
- reserved: Reserved for future use, should be set to zero.
- URG: If it needs to be refered to the urgent pointer field
- ACK: If this packet contains an acknowledgement value in the acknowledgement field. All the packets after SYN packet will contain have the ACK flag is set.
- PSH: Makes this packet a PUSH packet. In normal flow receiver will not acknowledge each packet after receiving. Receiver will keep the data it get received in a buffer for some time until it gives to the application. PUSH packet will tell the receiver to give the data to the application immediately and then it will acknowledge.
- RST: Reset the connection. One particular example of sending the RST packet would be in response for a packet received for a closed socket.
- SYN: Start the connection, synchronize the sequence numbers. First packet from each end will only have this flag is set.
- FIN: One endpoint will FIN flag set packet to other endpoint to express that I’m done sending packets we can terminate the connection.
[Note] NS, CWR, ECE flags are added later to the TCP header. For more info refer 
- window size: Available size of the receive buffer(window).
- checksum: Used for error checking. It will calculate a number based on Pseudo-header (source IP address, destination IP address, protocol number, TCP length) and TCP header with data. TCP length is the length of TCP segment including header fields and data. For more info 
- urgent pointer: If the URG flag is set, then this urgent pointer field is an offset from the sequence number indicating the last urgent data byte. For more info 
TCP message flow
- Connection initialization
TCP connection initialization happens with 3 way handshake.
(#1) Client will send a packet with SYN flag is set and random number(R1) included in the sequence number field.
(#2) Server will send a packet with SYN flag and ACK flags are set. sequence number field will contain a new random number(R2) and acknowledgement number field will contain clients sequence number +1 (R1+1).(Which is the next sequence number server is expecting from the client)
(#3) Client will acknowledge servers SYN packet by sending a packet with ACK flag is set and acknowledge number field with R2+1. (Which is the next sequence number client is expecting from the server)
Payloads will travel both the directions of the TCP connection after the connection initialization. All the packets will set the ACK flag, PSH, URG flags may or may not be set.
TCP connection is normally terminating using a special procedure where each side independently closes its end of the link. It normally begins with one of the application processes signalling to its TCP layer that the session is no longer needed. That device sends a message with FIN flag set to tell the other device that it wants to end the connection, which then get acknowledged. When the responding device is ready, it too sends a FIN, after waiting a period of time for the ACK to be received, the session is closed. For more info 
In the TCP level there is no keep-alive messages, if the session become idle it will keep on so, until the next packet is sent.
But when we send a HTTP request over a network first we have to create a TCP connection, because this TCP connection creation process is somewhat costly HTTP 1.1 decides to keep the TCP connection open until one side decides to terminate it. (Unless “keep-alive=close” header is included in HTTP headers) In HTTP 1.0 keep-alive is close by default.
HTTP servers support keep-alive timeout and maximum keep-alive requests for stop the idling the session and to give more control over the flow. For more info 
Generating TCP dumps
In Linux, Mac OS environments tcpdump is the tool which can be used to capture TCP dumps, it uses libpcap library to capture network traffic.
Installing tcpdump (ubuntu): apt-get install tcpdump
Running tcpdump : Following are some of the commonly used commands with arguments that can be useful in generating TCP dumps with different level of information. We can use most of the arguments to specify the level of detail we need and to apply filters. You might need root access to run following commands
- tcpdump -D : display all available interfaces
- tcpdump -i eth0 : capture traffic at the interface “eth0”
- tcpdump -i any : capture traffic at any interface
- tcpdump -i wlan0 port 80 : capture traffic at the interface “wlan0” on port 80
- tcpdump -i wlan0 -c 5 : capture 5 packets at the interface “wlan0”
- tcpdump -i wlan0 tcp : capture only tcp traffic at interface “wlan0”
- tcpdump -i wlan0 src 192.168.1.1 : capture traffic at interface “wlan0” with source IP 192.168.1.1
- tcpdump -i wlan0 dst 192.168.1.1 : capture traffic at interface “wlan0” with destination IP 192.168.1.1
- tcpdump “src port 22” and “dst host 22.214.171.124” : tcpdump command with boolean opertators
- tcpdump -i wlan0 -s 65535 : capture traffic with snapshot size as 65535 bytes, by default its 262144 bytes. Older versions of tcpdump captures 68 or 96 bytes.
- tcpdump -i wlan0 -w dump.pcap : capture traffic at the interface “wlan0” and write into a pcap file
- tcpdump -r dump.pcap : read captured file (we can use wireshark instead and its preferred)
[Note] if you are planning to analyze the packets using Wireshark you should capture it into a .pcap file by using -w argument.
Following is the command can be recommanded command if you dont want to add too much filters and wants to analyze the packets using wireshark
tcpdump -i <interface> -s 65535 -w <some-file>.pcap
For more info: 
Pre-processing and Analyzing on Wireshark
After generating the .pcap file using tcpdump we can use Wireshark GUI tool to analyze traffic. But there are few things that might be important to know. 
- Time format
Change the Date-Time format in WireShark from View -> Time Display Format
- Time shift
The way Wireshark display time stamps can be confusing at first. If you are analyzing tcp packets compared some other sever log, you need to co-relate the time stamps and for that its important to understand how to correctly shift the time of the packets.
Example: You have an WSO2 ESB server running on PST (UTC-7) and you have the ESB logs generated on PST and you have TCP dumps generated at the same server. Then you try to analyze the TCP dump from IST(UTC+5.30) time zone.
Now, lets say there was a TCP packet that went through the ESB at 8AM 2017–06–20. But when you open that TCP dump on IST time zone for analyzing the time of that that packet will show as 8:30PM 2017–06–20. This is because Wireshark adjust the packet time according to the time zone. (PST+12:30h -> IST)
But when we are comparing this with ESB server logs which are in PST is not helpful. So what we have to do is, shift the time in TCP packets by 12:30hrs, then it will co-relate with the WSO2 ESB server logs times stamps.
This can be done by Wiresharks timeshift option (Edit -> Time Shift) or editcap tool. 
editcap -t 45000 mytcpdump.pcap
More info: 
- Merge multiple TCP dump files
In siutations where multiple TCP dumps needs to be examined together, you can merge those TCP dumps into one file. That can be done using mergecap tool or WireShark UI(File -> Merge).
mergecap -w outfile.pcap input-1.pcap input-2.pcap
More info: 
Wireshark is capable of applying different filter to the TCP dump, for an example host, port values for soruce and detinations, protocols etc.
More info: 
- Follow Stream
This is also one type of filter that Wireshark has. But this can be done by right clicking on a particular packet and click on “Follow TCP Stream”. This will show us a filtered set of TCP packets that are in the sequence of the packet that we selected. It can be really useful in following packet flows.