Tracing HTTP Requests with tcpflow

For a tool that understands TCP and HTTP conversations, the filter syntax is awfully similar to tcpdump&#x27;s, and having to use `grep -A 15` to filter specific requests seems clunky.<p>It&#x27;s good knowing this tool exists, but I think I&#x27;ll stick to tcpdump and Wireshark. In Wireshark it&#x27;s trivial to use the `http.request` filter to do this, and following the TCP conversation with decoded bodies, or specifying a TLS cert, is equally simple.

There is also netpeek[1] which has better filtering capabilities and UX overall. It supports ngrep like bpf filters which we found useful.<p>1: <a href="https:&#x2F;&#x2F;github.com&#x2F;darshanime&#x2F;netpeek" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;darshanime&#x2F;netpeek</a>

This assumes you have shell and those tools installed via your Dockerfile. Best practice is to have a multi stage build and just have the working binary, keeping the image as light as possible.<p>So when do you make a fat image with debug tools and when do you keep it skinny?

A thought. I would usually start with my application logs. Reverting to a tcp tool for a http app problem seems cobtrived

This looks handy, better ergonomics than strace to just hook into http requests of a running process.<p>I wonder how it works with TLS if it’s working at the socket level..

in this space I have successfully used mitmproxy, charles and, with the best experience, fiddler<p>mitmproxy.org www.charlesproxy.com <a href="https:&#x2F;&#x2F;www.telerik.com&#x2F;fiddler&#x2F;fiddler-classic" rel="nofollow">https:&#x2F;&#x2F;www.telerik.com&#x2F;fiddler&#x2F;fiddler-classic</a>

There&#x27;s also termshark, a TUI for tshark inspired by Wireshark.<p>You also have mitmproxy which can be useful if TLS is involved.

Just because I know them better, I would have used `netstat -putln` and `tcpdump -i lo -n -A port 8000` to do the same thing. I&#x27;ll take a look at tcpflow and ss though - it&#x27;s always nice to know more tools.