Morgan's general description of the two kinds of Modbus network gateways is excellent and concise.
Examples of the first type of "forwarding" gateway are the Digi One IAP, and that linked Automation Direct MB-Gateway. They take one Modbus / TCP command over Ethernet, use the Unit ID as the Slave ID, and perform that command over serial, then wait for the reply.
Because Modbus has no "transaction identifier" in the protocol, there's no way to make that particularly efficient. The gateway device can't tell which message the slave is replying to, so it just has to wait for a reply before it can process the next request.
I think the best example of the second type of gateway is a Red Lion or Prosoft device, that uses an internal data table to store information so it can run some optimization. If multiple Modbus/TCP clients are asking for the same Modbus RTU slave device data, a buffering gateway knows it just received that data from a given slave device and can offer it up to the Modbus/TCP clients without doing another transaction on the serial side.
For applications where you just need a simple translation between physical network types and Modbus TCP <-> RTU protocols, with one client and one message at a time, the first type of gateway is sufficient.