In each network scenario, TCP hole punching operates in a similar way to UDP hole punching. For example, if two peers A and B are behind di?erent NATs, each peer’s ?rst SYN packet sent to the other peer opens up a hole associated with its public address in its respective NAT. If A’s ?rst SYN packet to B reaches B’s NAT before B’s ?rst SYN packet to A reaches B’s NAT, B’s NAT considers A’s SYN packet unsolicited and drops it. However, subsequently B’s ?rst SYN packet can travel through A’s NAT successfully because A’s NAT recognises B’s public address as the destination of the outgoing session that A has initiated.
So yes. It's possible to TCP holepunch. I don't see why anyone would think otherwise.
Also, could you not create this type of bahaviour manually? It doesn't need to depend on any specific protocol as long as the steps are the same to gather all of the required information.
In general, TCP hole punching (3.2.1) proceeds as follows:
Clients: A, B
Server: S
? A uses its connection with S to ask S for a connection
with B.
? S replies to A with B’s private and public addresses,
and simultaneously sends A’s addresses to B.
? A and B asynchronously make outgoing connection at-
tempts (send SYN packets) to each other’s public and
private addresses, from the same port that they used
to register with S. At the same time, they listen for
TCP incoming connection attempts on their local TCP
ports.
? A and B wait for a SYN-ACK response to their out-
going SYN packets, or an incoming connection request
(SYN packet). If a connection fails, the peer can retry
it up to a maximum timeout period.
? Once the three-way handshake process has completed,
the peers authenticate each other. If the authentica-
tion fails, the peers close that connection and wait until
another connection is successfully authenticated. The
?rst successfully authenticated connection will be used
to transfer TCP data.
(I know this isn't much of an answer but there wasn't enough room for a comment).
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…