Udostępnij za pośrednictwem

Problemy specyficzne dla protokołu TCP/IP

Niektóre techniki programowania napotykają problemy z wydajnością związane z implementacją protokołu TCP/IP. Takie problemy z wydajnością nie sugerują, że protokół TCP/IP jest nieefektywny lub wąskie gardło wydajności; zamiast tego te problemy są widoczne, gdy operacje TCP/IP nie są zrozumiałe.

Poniższe problemy identyfikują typowe scenariusze, w których kombinacja operacji TCP/IP i wyborów tworzenia aplikacji sieciowych skutkuje niską wydajnością.

  • Łączenie aplikacji z dużymi obciążeniami.

    Niektóre aplikacje tworzy wystąpienie nowego połączenia TCP dla każdej transakcji. Ustanowienie połączenia TCP zajmuje trochę czasu, przyczynia się do dodatkowych RTT i podlega powolnemu uruchamianiu. Ponadto zamknięte połączenia podlegają funkcji TIME-WAIT, która zużywa zasoby systemowe.

    Aplikacje z dużą liczbą połączeń są powszechne w dużej mierze dlatego, że są łatwe do utworzenia; Testowanie i obsługa błędów jest bardzo proste. Wykrywanie błędów w trwałym połączeniu może zająć znaczną ilość kodu i nakładu pracy, a w związku z tym czasami nie zostało ukończone.

    Aby rozwiązać ten problem, należy ponownie nawiązać połączenie TCP. Może to spowodować serializacji za pośrednictwem połączenia TCP, chyba że transakcje są multipleksowane za pośrednictwem wielu połączeń. W przypadku zastosowania tego podejścia liczba połączeń powinna być ograniczona do dwóch, a ramowanie warstwy aplikacji i zaawansowana obsługa błędów są wymagane.

  • wysyłania o zerowej długości i wysyłanie blokujące.

    Wyłączenie buforowania przy użyciu funkcji setsockopt w celu ustawienia buforu wysyłania (SO_SNDBUF) na zero jest podobne do wyłączania buforowania dysku. Podczas ustawiania buforu wysyłania na zero i wysyłania komunikatów blokujących aplikacja ma pięćdziesiąt procent szans na trafienie 200-milisekundowego potwierdzenia opóźnionego.

    Nie wyłączaj buforowania wysyłania, chyba że rozważasz wpływ na wszystkie środowiska sieciowe. Jeden wyjątek: dane przesyłane strumieniowo przy użyciu nakładających się operacji we/wy powinny ustawić bufor wysyłania na zero.

  • Model programowaniaSend-Receive send-Send-Receive.

    Tworzenie struktury aplikacji w celu wykonania wysyłania-wysyłania-odbierania zwiększa prawdopodobieństwo napotkania algorytmu Nagle, co powoduje opóźnienie RTT+200 ms. Algorytm Nagle może wystąpić, jeśli ostatnie wysłanie jest mniejsze niż maksymalny rozmiar segmentu TCP (MSS, maksymalna ilość danych w pojedynczym datagramie). MsS może być bardzo dużą wartością (64K w IPv4, a nawet większym w IPv6), więc nie należy liczyć na zazwyczaj małe msS. Lepszym rozwiązaniem jest połączenie tych dwóch wysyłania w jedną funkcję WSASend lub memcpy.

  • Duża liczba równoczesnych połączeń.

    Połączenia współbieżne nie powinny przekraczać dwóch, z wyjątkiem aplikacji specjalnego przeznaczenia. Przekroczenie dwóch współbieżnych połączeń powoduje marnowanie zasobów. Dobrą regułą jest posiadanie maksymalnie czterech krótkotrwałych połączeń lub dwóch trwałych połączeń na miejsce docelowe.

zachowanie aplikacji

aplikacje Windows Sockets o wysokiej wydajności

Algorytm nagle