Warstwa transportowa musi właściwie dzielić i zarządzać wieloma połączeniami jednocześnie, które często mają różne wymagania. Przykładowo można sobie wyobrazić użytkownika, podłączonego do urządzenia końcowego w sieci. Użytkownik ten jednocześnie wysyła i odbiera pocztę, używa komunikatora, przegląda strony internetowe i ma uruchomioną aplikację VoIP. Każda z tych aplikacji jednocześnie wysyła i odbiera dane, pomimo różnych wymogów niezawodności. Mimo tego, dane z rozmowy telefonicznej nie są kierowane do przeglądarki stron, a tekst z komunikatora nie pojawia się w e-mailu.

Co więcej, użytkownik wymaga by e-mail i strona WWW zostały odebrane i przedstawione w całości, inaczej będą bezużyteczne. Nieznaczne opóźnienia podczas odbioru poczty czy przeglądania stron są akceptowane, o ile "produkt końcowy" będzie przedstawiony całościowo. W powyższym przykładzie, to sieć zarządza ewentualnymi retransmisjami brakujących informacji, a "produkt wynikowy" nie zostanie przedstawiony przed odebraniem i złożeniem całości.

Z drugiej strony, zagubienie drobnych fragmentów telefonicznej konwersacji może nawet zostać niezauważone. Nawet jeżeli pewne drobne części poszczególnych słów zostaną utracone, to ludzie i tak są w stanie wywnioskować brakujący fragment z kontekstu lub poprosić o powtórzenie. Wydaje się to lepszym rozwiązaniem, niż wprowadzanie dodatkowych opóźnień jakie wnosiłaby ewentualna retransmisja zagubionych segmentów. W powyższym przykładzie to użytkownik, a nie sieć, zarządza retransmisją brakującej informacji.

Jak przedstawiono na rysunku, aby TCP i UDP mogły zarządzać wieloma konwersacjami (z różnymi wymaganiami) na raz, muszą śledzić komunikację, pomiędzy aplikacjami. By rozróżniać segmenty i datagramy każdej z aplikacji, zarówno TCP jak i UDP mają w nagłówkach pola, dzięki którym można jednoznacznie zidentyfikować te aplikacje. Te unikalne identyfikatory to numery portów.