The Internet has in the last decade experienced an explosive expansion with regards to both size and traffic volumes. Private users connected to the Internet are continuously presented with innovative ways of consuming their available bandwidth. In general these new ways of using the Internet initiate needs for more and more available bandwidth. In the final part of the last decade applications for watching video, listening to sound and interacting both visually and audio visually have become very popular. Such applications can be highly bandwidth consuming. In addition to the demand for high throughput they are also usually transported by UDP at the transport layer. Today it is possible to stream video and audio without specialized multimedia applications. HTTP streaming is such a technique where the stream is transported by TCP on port 80. Many streaming applications tries to use UDP as the primary transport protocol. If that fails it turns over to TCP. The personality of UDP makes it very suitable for video and audio. For video and audio applications loss is usually less critical than delay and UDP have the same priorities. The problem with UDP is that it does not react to congestion in the network from the sender to the receiver. In other words UDP does not incorporate a congestion control mechanism and sends data at the application specified rate. As the use of video and audio applications in the Internet increases so does the amount of connections without any form for congestion control. Transport Control Protocol (TCP) which still today is the dominating transport protocol in the Internet does incorporate congestion control mechanisms. TCP detects lost packets and reduces its sending rate when an assumed congestion is discovered. In brief this means that increasing use of UDP opens the possibility for TCP connections being strangled is higher. This problem has been widely discussed and alternative transport protocols and application extensions to UDP have been suggested. Application extensions to UDP that can cooperate with TCP in the network use a TCP-friendly algorithm at the application layer to adapt the application specific data rate. The carelessness of UDP is handled at application layer to make the long term throughput be similar to a TCP connection working under the same conditions. \\\\In addition to be unaware of congestion, UDP is in many cases restricted from access through firewalls. More and more end users access the Internet from beyond a firewall. Since TFRC is typically implemented on top of UDP, rate controlled UDP solutions suffer the same problem as regular UDP with regards to access through firewalls.\\\\In this work we investigate a streaming system with the means of a proxy which is situated just outside the access network firewall. The backbone transfer is carried by UDP and TFRC to control the rate at application layer. The proxy translates packets from UDP to TCP and forwards them towards the client. By using this architecture the transfer is TCP-friendly in the backbone and the firewall will let data through to the client assuming it is streamed using a well known port number like 80. The investigation also includes hierarchical layered multimedia to scale the throughput according to the TFRC rate control.\\\\During our work we showed that the combination of TFRC in the backbone and TCP in the access network can improve regular HTTP streaming from server to client. The throughput and delay variations introduced by TCP during packet loss in the access network are very limited due to the environment of access networks. The experiments also shows how the use of blocking TCP in the access network can regulate the TFRC backbone rate during high backpressure for scaling between the two environments. We also presents tuning options for the combined transport environment with the goal of maximizing the overall perceived quality and minimizing the delay variations.