A reverse proxy receives the request, takes it apart, potentially examines it and manipulates it, then reconstructs it in accordance with policy and forwards it on to the receiving system. It then takes the response and also takes it apart, examines it, and again possibly applies policy, before reconstructing it and sending it back to the requestor.
Various steps can be elided; I've got a "proxy" that basically just blindly forwards everything, but it is based on an HTTP library and the request and response is fully parsed, even though the policy applied is very light. Various optimizations can be used to avoid expensive disassembly/reassembly, etc.
A tunnel simply shovels the bytes along, and can thus only apply policies based on TCP-level metadata like source and destination IP. A tunnel does not realize you're shoving "GET / HTTP/1.1" or anything else down it, it just moves it along.
Forstalling the inevitable "but what about..."s, this is definitely in that category of things that seems completely separated at 10,000 feet but the closer you get the fuzzier the lines get. Literally anything you can imagine that is technically possible has probably been done. For instance, a "TLS tunnel" is off the shelf tech nowadays; it takes apart the TLS layer of the connection and may apply policy to that, but the socket connection within the TLS tunnel is blindly sent along to the target (possibly itself a TLS connection), thus being simultaneously both a tunnel and a reverse proxy. I can think of at least three other similar things that are both tunnels and proxies, depending on which aspect of them you focus on, off the top of my head, and could list more if I sat down and starting writing it down. Down in the trenches these things are all mixed and matched in all sorts of ways. So in my personal opinion, getting really fussy about the nitty-gritty of the definitions is not terribly useful; there is no sharp line to be found anywhere here. What is useful is understanding that these are primitives that are available to you as you construct solutions, and that they can be assembled into interesting higher-level structures.
Comments
A reverse proxy receives the request, takes it apart, potentially examines it and manipulates it, then reconstructs it in accordance with policy and forwards it on to the receiving system. It then takes the response and also takes it apart, examines it, and again possibly applies policy, before reconstructing it and sending it back to the requestor.
Various steps can be elided; I've got a "proxy" that basically just blindly forwards everything, but it is based on an HTTP library and the request and response is fully parsed, even though the policy applied is very light. Various optimizations can be used to avoid expensive disassembly/reassembly, etc.
A tunnel simply shovels the bytes along, and can thus only apply policies based on TCP-level metadata like source and destination IP. A tunnel does not realize you're shoving "GET / HTTP/1.1" or anything else down it, it just moves it along.
Forstalling the inevitable "but what about..."s, this is definitely in that category of things that seems completely separated at 10,000 feet but the closer you get the fuzzier the lines get. Literally anything you can imagine that is technically possible has probably been done. For instance, a "TLS tunnel" is off the shelf tech nowadays; it takes apart the TLS layer of the connection and may apply policy to that, but the socket connection within the TLS tunnel is blindly sent along to the target (possibly itself a TLS connection), thus being simultaneously both a tunnel and a reverse proxy. I can think of at least three other similar things that are both tunnels and proxies, depending on which aspect of them you focus on, off the top of my head, and could list more if I sat down and starting writing it down. Down in the trenches these things are all mixed and matched in all sorts of ways. So in my personal opinion, getting really fussy about the nitty-gritty of the definitions is not terribly useful; there is no sharp line to be found anywhere here. What is useful is understanding that these are primitives that are available to you as you construct solutions, and that they can be assembled into interesting higher-level structures.
But that's at least the basic understanding.
To be super duper extra pedantic, a tunnel can exist on any transport, not just TCP. It's just most common to hear about them being used with TCP.