There is no conversion, what you have is Encapsulation
Ex: you use wireshark on your local PC to capture your HTTP session. Basically, what you end up with looks like:
[Ethernet Frame [IP Packet [TCP Segment [HTTP Request]]]]
- The Ethernet frame has the EtherType field of 0x0800 that gives us the encapsulated protocols as IP
- The IP Packet has the Protocol Field of "6" that tells us the next level is TCP (ICMP is Protocol "1")
- TCP has the Destination port of 80, on which normally a Web Server is listening to
- HTTP is what is actually understood by a Web Server
I would give an answer of "no, but it is remarkably similar."
Here's some history and a largely complete explanation.
Circuits 101
Information networks can route traffic, basically, in terms of circuit switching or in terms of packet switching. Circuit switching offers many more guarantees than packet switching, but this comes at a cost, and so circuit switched networks can't degrade gracefully. The classic circuit-switched network is the PSTN, and a virtual circuit would be something like a DS0 on the PSTN.
A DS0 basically works as part of a bundle of connections, usually in a DS1. In a DS1, you will have a bundle of DS0's which are transmitted together, frame-by frame in time-division manner, so each DS0 is guaranteed a specific bandwidth, timeliness, etc. by the underlying network transport.
Another way to look at this is that a physical circuit would be something like a cat6 cable running between two terminals. You can send data back and forth over the wires at guaranteed speeds, and no other communications are going to interfere with that. Indeed the early telephone networks worked by connecting physical circuits (that is copper wires) using manual or electromechanical switches. As this was computerized, the circuits were virtualized and digital (as opposed to analog) information was sent down wires on a time division basis again with a circuit reserving a slot in the time division schedule.
What this means is that circuit switching is more about bandwidth reservation than it is about routing. The former leads to the latter. I.e. a circuit reserves bandwidth for the entire connection.
Why TCP Connections are not Virtual Circuits
TCP/IP is fully packet-switched. It makes no provisions for virtual circuits. This is why things like QoS are often necessary when trunking VOIP (a virtual circuit has built-in QoS guarantees). You have no guarantee that all packets will be routed alike. They may not come through in the same order. They may not come through in a timely manner (from a connection-oriented perspective). So you can't really build virtual circuits per se on top of a packet switched protocol like IP.
TCP comes somewhat close and in fact can work as a somewhat imperfect substitute. It offers as many of the guarantees as it can. This is why, when implemented on TCP/IP, H.323 uses TCP connections instead of the virtual circuits the protocol prefers.
But TCP connections still aren't circuits, because they don't reserve bandwidth during connection on every switch between the two nodes.
Of course TCP connections are more than just datagrams. They include routing information (as does UDP) but they also include the accounting information necessary to reconstruct the stream on the other side in order.
The Answer
Both TCP and UDP are datagram protocols. They send a packet of data with routing information to routers with none of the guarantees of that a circuit offers. TCP offers a subset of guarantees on the end points of what a circuit would offer by adding accounting information to allow the end points to handle errors and a series of data in order, but it is only a subset. Of datagram protocols, TCP is the closest thing one will find to a virtual circuit but it is still conceptually and operationally very different.
Best Answer
Each layer in the stack has its very own function and all layers together form the complete functionality, the "stack".
Ethernet (physical and data link layers) transports packetized data in frames within a local segment. While the physical size of this segment can be many km, it's usually much more limited, to a building for instance.
IP (network layer) uses this functionality and puts logical addresses on top that can be routed on a global scale. Its IP packets are wrapped in Ethernet frames for delivery in a local segment. Multiple segments = IP subnets are connected by routers. Frames can't cross routers but the IP packets inside can.
IP is still only transporting readily packetized data. In order to get a data stream that an application can easily use, a transport layer protocol like TCP creates a virtual, bilateral, stream connection (a socket) that is very similar to a simple, serial connection - think of a telephone call between two parties. The inner workings of TCP are far more complicated than most things on the lower layers and not so easy to grasp. The beauty is that you don't necessarily need to know how it works in order to use it.
HTTP is an application layer protocol that makes use of this socket connection to GET a resource from a web server (a web page, graphics file, ...).
Because TCP does all the packetizing and reassembly work, and IP does all the work traveling across the globe, and Ethernet does all the work messing with the cables and hardware interfaces, HTTP can concentrate on its own job and keep it (rather) simple.
This is a simplified, rough overview. Of course you can use other physical and link layer protocols with IP, but Ethernet is extremely popular. You can also use other transport protocols on top of IP, depending on the application's requirements. And obviously, you can use an extremely large variety of application protocols on top of TCP or UDP or whatever.
The key to packet networks is that you can run all of this together in a single, extremely multi-functional network.