I think it would be hard to find an ideal solution from what you say, but I believe the most important thing here is the expected load and reliability of the solution. I'm writing a few ideas here:

• If your web server C must serve other things apart from those requests (static web pages, images...) or is exposed to the internet, I'd go for a production web server and would not invent a kludge for myself.
• If you can afford the cost of a separate connection F via TCP/IP, a CGI on a webserver will likely get the work done with the minimum expense
• If you cannot afford the cost of a separate F for each request, either you find a way to share a global connector object (I'd do it trivially in Java using the Application container, not sure how to do it with Perl) or you find a way to IPC to something else that will handle the connections. The point is that before going this way you have to prove that you can do IPC + marshalling + connection turnaround in less time than a separate F.
• If a single request B translates to more than one F, you can create a new channel for each B and reuse it for all F's therefore spreading the setup cost.
• If you can have C and G on the same machine or using a very low latency hardware, you can probably go with separate TCP-IP connections, otherwise if G is on a data center on the other side of the world and you cannot help latency you'll have to think more about this part