Why TCPDump Command Didn’t Capture Three-Way Handshake

Both HTTP GET and HTTP POSTS use TCP. If you are asking whether a POST also requires a 3-way TCP handshake (syn-synack-ack), it does just like any other TCP connection. The TCP handshake is required before any application protocol (such as HTTP) starts work.

FYI, your three-way handshake is incorrect; it should be "syn-synack-ack"

ADD:

If browser use QUIC (Quick UDP Internet Connections, pronounced quick. Proposed by Google) protocol for HTTP is possible to avoid 3-way TCP handshake. But AFAIK it supported in Chrome and Google.

Most software prefer HTTP/2 which still TCP but wit many features it use persistent connection then 3-way handshake done once for each server server.

If this protocols is used, 3-way hanshake can be avoided by any request, including GET.

Break down the handshake into what it is really doing.

In TCP, the two parties keep track of what they have sent by using a Sequence number. Effectively it ends up being a running byte count of everything that was sent. The receiving party can use the opposite speaker's sequence number to acknowledge what it has received.

But the sequence number doesn't start at 0. It starts at the ISN (Initial Sequence Number), which is a randomly chosen value. And since TCP is a bi-directional communication, both parties can "speak", and therefore both must randomly generate an ISN as their starting Sequence Number. Which in turn means, both parties need to notify the other party of their starting ISN.

So you end up with this sequence of events for a start of a TCP conversation between Alice and Bob:

Alice ---> Bob    SYNchronize with my Initial Sequence Number of X
Alice <--- Bob    I received your syn, I ACKnowledge that I am ready for [X+1]
Alice <--- Bob    SYNchronize with my Initial Sequence Number of Y
Alice ---> Bob    I received your syn, I ACKnowledge that I am ready for [Y+1]

Notice, four events are occurring:

1. Alice picks an ISN and SYNchronizes it with Bob.
2. Bob ACKnowledges the ISN.
3. Bob picks an ISN and SYNchronizes it with Alice.
4. Alice ACKnowledges the ISN.

In actuality though, the middle two events (#2 and #3) happen in the same packet. What makes a packet a SYN or ACK is simply a binary flag turned on or off inside each TCP header, so there is nothing preventing both of these flags from being enabled on the same packet. So the three-way handshake ends up being:

Bob <--- Alice         SYN
Bob ---> Alice     SYN ACK 
Bob <--- Alice     ACK     

Notice the two instances of "SYN" and "ACK", one of each, in both directions.

So to come back to your question, why not just use a two-way handshake? The short answer is because a two way handshake would only allow one party to establish an ISN, and the other party to acknowledge it. Which means only one party can send data.

But TCP is a bi-directional communication protocol, which means either end ought to be able to send data reliably. Both parties need to establish an ISN, and both parties need to acknowledge the other's ISN.

So in effect, what you have is exactly your description of the two-way handshake, but in each direction. Hence, four events occurring. And again, the middle two flags happen in the same packet. As such three packets are involved in a full TCP connection initiation process.