Warstwa transportowa HTTP-ng realizuje funkcję podziału pojedynczego połączenia na wiele kanałów za pomocą protokołu multipleksacji o nazwie WebMUX. Wszystkie wiadomości sterujące są przesyłane kanałem sterującym, a obiekty są kierowane do oddzielnych kanałów pojedynczego połączenia. Kolejnym ulepszeniem jest asynchroniczna obsługa grupy dyspozycji: klient nie musi czekać na odpowiedź przed wysłaniem kolejnego zlecenia. Ponadto serwer nie musi odpowiadać na zlecenia w kolejności ich przyjęcia i może przeplatać dane z wielu obiektów, dopuszczając do równoległej transmisji kilku obiektów przez grupę kanałów funkcjonujących w pojedynczym połączeniu.

Poziom pośredni Remote Invocation jest ogólnym poziomem zleceń/odpowiedzi, na którym klient ma dostęp do usług serwera, wywołując operacje z zasobów rezydujących na serwerze. Zapewnia on mechanizm zdalnego wywoływania dostosowany do aplikacji aktualnie "uwarstwowionych" nad HTTP, a także nowych. Poziom ten nie zapewnia żadnych usług specyficznych dla aplikacji, takich jak ochrona, buforowanie czy jakiekolwiek inne. Nie obsługuje indywidualnych mechanizmów, takich jak CORBA, DCOM czy Java RMI, w ich aktualnej postaci, ale określa zasady wymuszające unifikację przez uogólnioną obsługę aktualnych aplikacji.

Poziom Web Application jest zestawem interfejsów sieciowych definiujących aplikacje – zmiennym w zależności od aplikacji. Zapewnia on operacje i usługi poziomu aplikacji obejmujące bieżący zestaw metod (GET, HEAD, PUT), negocjacje zawartości, buforowanie, uwierzytelnianie dostępu itp.

QoIP (Quality over IP)

Gwarantowana jakość usług IP – QoIP – jest jedną z najważniejszych charakterystyk wymaganych dziś w Internecie, której nie zapewnia oryginalna architektura TCP/IP. QoS wymaga utrzymywania na routerach informacji dotyczących stanu każdego przepływu, wpływających na normalne mechanizmy sygnalizacji i kolejkowania. Wszystkie hosty, routery i inne elementy infrastruktury sieciowej, leżące pomiędzy odbiorcą i nadawcą, muszą zapewnić obsługę funkcji QoS, a każdy z nich musi zarezerwować na ten cel odpowiednie zasoby systemowe, takie jak pasmo, CPU i pamięć operacyjna.

IETF prowadzi prace standaryzacyjne, których celem jest rozwiązanie problemu jakości IP. Jednak droga do powszechnej akceptacji jednolitego podejścia jest ciągle daleka. Protokół RSVP obsługuje jedynie zlecenia od odbiorcy i nie może określać drogi przekazu oraz kolejek. Odbiorca po stronie hosta używa RSVP do zlecania specyficznego QoS w sieci dla poszczególnych strumieni danych pochodzących z poszczególnych źródeł danych. Elementarne zlecenie rezerwacji RSVP składa się z określenia pożądanego QoS w układzie end-to-end (na przykład szczytowe i średnie zapotrzebowanie na pasmo czy granice opóźnień) i definicji zestawu pakietów danych odbieranych wg QoS. RSVP jest użyteczny dla środowisk, w których rezerwacja QoS może być obsługiwana przez realokację zasobów, a nie przez dodawania zasobów.

Usługi DiffServ (Differentiated Services) operują wyłącznie na poziomie 3 i używają jednobajtowego pola "Type of Service" pakietu IP do przenoszenia informacji o wymaganych usługach, bez przyjmowania jakichkolwiek założeń odnośnie mechanizmów niższego poziomu. DiffServ są rozwinięciem IETF Integrated Services (Interserv), standardu klasyfikacyjnego usług, używanego z RSVP i zakładającego wyprzedzającą rezerwację zasobów na każdym węźle pośrednim. Trasowanie jest wykonywane w oparciu o pakiet, a nie sesję, a poziom QoS jest zapewniany przez połączenie funkcji sterująco-administracyjnych (reguły sterowania ruchem) z funkcjami dostarczania wymaganego pasma.