Understanding IP, TCP, and HTTP

The TCP socket doesn't know anything about any "interfaces" or "links" or anything like that, it only knows about its and the remote IP address (and port), and the IP stack will deliver any packets to it that it receives that are addressed to that port on that address coming from the corresponding remote address and port, no matter which link it was received through (possibly subject to reverse path filtering on end hosts as a security measure). Similarly, each outbound packet is routed independently, so if the routing table changes half-way through a TCP connection, packets simply will be routed via a different link (the end host really just does the same as any other router does, and the fundamental idea of packet switched networks is that routers to not know about connections, they simply forward each packet independently, potentially switching links as needed at any time).

It perfectly possible, for example, to bridge between WiFi and wired ethernet, and have a gateway that routes some IP network onto that Ethernet/WiFi, then, while connected to the WiFi, establish a TCP connection, disconnect from the WiFi, connect to the Ethernet via cable, using the same IP addresss on the Ethernet interface as you previously used on the WiFi interface, and the TCP connection will survive that just fine (it might take a moment for the router to time out its neighbour cache entry and re-resolve your IP address into the new hardware address, but that's just a matter of a few seconds). You could even connect to both, configure things such that the kernel only replied to ARP/ICMP6 ND on WiFi, say, and route outbound packets through the cable, then the outbound packets of the TCP connection would go through the cable while the inbound packets would go through the air.

The only thing that actually breaks a connection is when packets addressed to the address that your TCP connection is using cannot reach you anymore, or when packets you send using that address can not reach the other side anymore, for example because you send them through a link that does not allow you to use that address. The latter really is mostly what kills TCP connections on mobile phones: the default route gets changed from WiFi to G3, say, and your mobile provider won't allow you to continue sending through their network packets using the address you got assigned by the WiFi - so the connection hangs even if the WiFi interface might actually still be up and able to receive packets addressed to that address.

One important thing to notice in this: There isn't really any way how a TCP implementation could detect right away that any of this has happened, as it cannot know what the filtering policies of your provider(s)/network(s) are or whether you disconnected only temporarily or whether you will reconnect to a different access point to the same network ... - so, when some mobile platform kills TCP sockets when you "change from 3G to WiFi" that really is a dirty hack that makes a load of assumptions about some typical setups that don't necessarily hold true.

And obviously I was talking about packet filters, not about some kind of application firewall, which obviously doesn't have anything to do with filtering of packets anyhow.

The Pauli exclusion principle prevents electrons with the same quantum characteristics from entering the same space, this interaction occurs across the amassed copper atoms which form the majority of the metallic wires that approach one another in the internal structure of the keyboard ...

If I had deep knowledge in this area, I'd probably applaud the effort and send corrections, rather than criticize.