co to jest TCP Half Open Connection i TCP Half Close Connection

Próbuję zrozumieć, jaka jest różnica między połową połączenia TCP a połową połączenia TCP. Czy ktoś może powiedzieć, co to dokładnie jest?

Ten post rozwija się na połączeniach w połowie zamkniętych. Połowy otwarte połączenia patrz poprawny opis KContreau.

Co to są połączenia w połowie zamknięte? Lub: To nie jest błąd - to funkcja!

Każde połączenie TCP składa się z dwóch połówek połączenia, które są niezależnie od siebie zamknięte. Więc jeśli jeden koniec wysyła FIN, to drugi koniec może po prostu POTWIERDZIĆ ten FIN (zamiast FIN + ACK-sprawdzenie), co sygnalizuje, że koniec wysyłający FIN ma jeszcze dane do wysłania. Tak więc oba kończą w stabilnym stanie przesyłania danych innym niż ESTABLISHED - a mianowicie FIN_WAIT_2 (dla strony odbierającej) i CLOSE_WAIT (dla strony wysyłającej). Mówi się, że takie połączenie jest w połowie zamknięte, a TCP jest faktycznie zaprojektowany do obsługi tych scenariuszy, więc połączenia w połowie zamknięte są funkcją TCP.

Historia częściowo zamkniętego połączenia

Podczas gdy RFC 793 opisuje jedynie surowy mechanizm, nawet nie wspominając o „pół-zamkniętym”, RFC 1122 rozwija tę kwestię w sekcji 4.2.2.13. Możesz się zastanawiać, kto do diabła potrzebuje tej funkcji. Projektanci TCP wdrożyli także TCP / IP dla systemu Unix i, jak każdy użytkownik Unixa, uwielbiali przekierowania I / O. Według W. Stevensa (ilustrowany protokół TCP / IP, rozdział 18.5) chęć przekierowania strumieni TCP we / wy była motywacją do wprowadzenia tej funkcji. Pozwala FIN ackowi przejąć rolę lub zostać przetłumaczony jako EOF. Jest to więc w zasadzie funkcja, która pozwala swobodnie tworzyć bezproblemową interakcję typu żądanie / odpowiedź na warstwie aplikacji, gdzie FIN sygnalizuje „koniec żądania”.

Inni faceci wykonali całkiem przyzwoitą robotę, opisując, czym tak naprawdę są półotwarte i półotwarte połączenia , ale pomysł półotwartych połączeń jest często poszukiwany w kontekście, że są PROBLEMEM.

W Internecie istnieją argumenty na temat tego, co powinna oznaczać termin „na wpół otwarty” lub „na wpół zamknięty”, ale moim zdaniem terminologia jest tylko semantyczna. Niektórzy twierdzą, że „półotwarte” połączenia to „problem”, podczas gdy „półotwarte” to funkcja projektowa, która umożliwia zamknięcie strumienia wysyłającego przez zamknięcie strumienia wysyłającego przed zakończeniem pobierania pliku w stanie półotwartym ( jak opisali inni użytkownicy).

Jednak w odniesieniu do drugiego ... „problemu”: potrzeba 3-krotnego uzgadniania, aby otworzyć połączenie TCP i 4-kierunkowego uścisku, aby je zamknąć.

TCP ma lukę w zabezpieczeniach polegającą na tym, że końcowy pakiet FIN wysłany do klienta może zostać potencjalnie upuszczony przez routery / sieci, co powoduje, że połączenie jest w połowie otwarte, gdy rzeczywistą intencją było całkowite zamknięcie połączenia. To i podobne podejścia są popularnymi rodzajami ataków typu „odmowa usługi”, ponieważ nie wymagają dużej przepustowości, ale potencjalnie pochłaniają cenne uchwyty, gniazda i wątki w zależności od implementacji serwera, ale mogą się również zdarzyć w prawdziwym świecie z rosnącą częstotliwością dzięki naszym tandetnym przewoźnikom bezprzewodowym.

Systemy operacyjne podjęły próby walki z półotwartymi atakami DDoS, ograniczając liczbę półotwartych / zamkniętych połączeń, które mogą być obecne w systemie operacyjnym w danym czasie i wprowadzając maksymalny czas, przez który połączenia mogą pozostać stan półotwarty / zamknięty. Ostatnio sprawdziłem osobiście jednak limit czasu w systemie Windows był dość wysoki (o ile pamiętam, 2 dni).

Ten warunek jest dodatkowo zaostrzony przez opcjonalną naturę utrzymywania protokołu TCP, które, jeśli zostaną w pełni zaimplementowane, miały służyć jako rozwiązanie na poziomie protokołu (w przeciwieństwie do poziomu aplikacji) do wykrywania połączeń martwych / zombie. Ale kiedy zaprojektowano TCP, przepustowość była znacznie cenniejsza niż obecnie, i istniały obawy, że czasomierze utrzymywania aktywności TCP będą zbyt „gadatliwe”. Dlatego utrzymywanie aktywności jest opcjonalne, nie jest powszechnie używane i nie ma gwarancji, że zostaną przesłane przez routery zgodnie z RFC1122. Więc ... nawet jeśli włączysz utrzymywanie aktywności w warstwie TCP, próbując wykryć / obsłużyć scenariusz, może się okazać, że w miarę jak twój ruch przemieszcza się po całym świecie, niektóre routery upuszczają pakiety utrzymywania aktywności ... tworząc potencjalnie INNY rzadki scenariusz do przetestowania.

Połączenia półotwarte stanowią wyzwanie dla programistów piszących serwery oparte na TCP, szczególnie dlatego, że mogą przypadkowo pojawiać się przypadkowo, w czasie dużego obciążenia ... i zazwyczaj na serwerach produkcyjnych ... i mogą być trudne do zauważenia na etapach testów alfa / beta. Z mojego doświadczenia wynika, że ​​występują one w około 1 na 40 000 połączeń na serwerach obsługujących 2,5 miliona połączeń dziennie, ale liczby te będą się różnić w zależności od warunków ruchu i warunków ruchu na każdym odcinku Internetu między serwerem a klientem .

Jako inżynier może być trudno wyśledzić problemy, które występują rzadko i tylko na uruchomionych serwerach na żywo, dlatego ważne jest, aby spróbować symulować ten rzadki stan połączenia podczas pisania kodu serwera TCP, aby przeanalizować reakcję serwera, gdy w obliczu tej sytuacji. Jeśli na przykład twój serwer TCP używa statycznej liczby wątków roboczych, możesz znaleźć je wszystkie zużyte przez połączenia zombie, na przykład podczas wdrażania do produkcji. Jeśli połączenia wymagają dużej ilości pamięci roboczej, wynik końcowy może wyglądać podobnie do wycieku pamięci. itd itd.

Bez w 100% opłacalnego rozwiązania utrzymującego aktywność TCP pozostawia to warstwie użytkownika, aby określić sposób obsługi połączeń półotwartych / zamkniętych, więc kod musi mieć plan / mechanizm wykrywania, przekroczenia limitu czasu i czyszczenia zwiększ zasoby, gdy wystąpi ten warunek ... to znaczy ... zakładając, że jest to wymyślony przez ciebie protokół, a nie jeden z wielu (złych) otwartych standardów, których zwykle używają programiści. Oczywiście mam na myśli protokoły takie jak HTTP, które działają wyłącznie przez TCP. Te protokoły są bardzo przereklamowane w opinii tego programisty.

Dostrzegając słabości protokołu TCP i jego niefortunną popularność w transmisji ruchu HTTP / Web, inteligentne firmy starają się znaleźć zastępcę. Na przykład Google eksperymentował z protokołem o nazwie QUIC, który przesyła HTTP przez UDP. Istnieje również otwarty protokół o nazwie TSCP. Żaden z tych protokołów nie został jednak powszechnie przyjęty.

Z reguły buduję wszystkie własne serwery, aby rozmawiać wyłącznie na własnym protokole opartym na UDP. UDP jest trudniejsze, niż mogłoby się wydawać, i wydaje mi się, że zawsze poprawiam go, aby był szybszy, mądrzejszy, z mniejszymi opóźnieniami, zatorami ... ale przynajmniej nie mam już do czynienia z połączeniami częściowo otwartymi; )

Kiedy TCP ustanawia połączenie, uważa się to za gwarantowane, ponieważ następuje uścisk dłoni:

1. Komputer inicjujący wysyła żądanie połączenia, wysyłając SYN
2. Komputer odpowiadający przyjmuje żądanie, odpowiadając przy użyciu SYN-ACK
3. Komputer inicjujący wysyła potwierdzenie, odpowiadając za pomocą ACK

W tym momencie połączenie jest ustanawiane, a dane zaczynają przepływać. Natomiast pakiet UDP nie jest gwarantowany i jest wysyłany tylko w nadziei, że tam dotrze.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment

Oficjalnie, zgodnie z RFC, półotwarte połączenie TCP ma miejsce, gdy jedna strona ustanowionego połączenia uległa awarii i nie wysłała powiadomienia o zakończeniu połączenia. To nie jest dzisiaj powszechne użycie.

Nieoficjalnie, jeśli może odnosić się do połączenia embrionalnego, które jest połączeniem w trakcie ustanawiania.

http://en.wikipedia.org/wiki/Embryonic_connection

Pół-zamknięte jest przeciwieństwem tej nieoficjalnej definicji. Jest to stan gdzieś pośrodku, w którym komputery niszczą ustanowione połączenie.

Najlepsze wyjaśnienie zakończenia połączenia TCP

W 3-kierunkowym procesie uzgadniania TCP badaliśmy, w jaki sposób ustanawia się połączenie między klientem a serwerem w protokole TCP (Transmission Control Protocol) za pomocą segmentów bitowych SYN. W tym artykule przestudiujemy sposób, w jaki TCP zamyka połączenie między klientem a serwerem. Tutaj również będziemy musieli wysłać segmenty bitów do serwera, dla którego bit FIN jest ustawiony na 1.

11

Jak działa mechanizm w TCP:

Step 1 (FIN From Client) – Suppose that the client application decides it wants to close the connection. (Note that the server could also choose to close the connection). This causes the client send a TCP segment with the FIN bit set to 1 to server and to enter the FIN_WAIT_1 state. While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment (ACK).
Step 2 (ACK From Server) – When Server received FIN bit segment from Sender (Client), Server Immediately send acknowledgement (ACK) segment to the Sender (Client).
Step 3 (Client waiting) – While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment. When it receives this segment, the client enters the FIN_WAIT_2 state. While in the FIN_WAIT_2 state, the client waits for another segment from the server with the FIN bit set to 1.
Step 4 (FIN from Server) – Server sends FIN bit segment to the Sender(Client) after some time when Server send the ACK segment (because of some closing process in the Server).
Step 5 (ACK from Client) – When Client receive FIN bit segment from the Server, the client acknowledges the server’s segment and enters the TIME_WAIT state. The TIME_WAIT state lets the client resend the final acknowledgment in case the ACK is lost.The time spent by client in the TIME_WAIT state is depend on their implementation, but their typical values are 30 seconds, 1 minute, and 2 minutes. After the wait, the connection formally closes and all resources on the client side (including port numbers and buffer data) are released.

Więcej informacji: https://www.geeksforgeeks.org/tcp-connection-termination/

Połowa zamkniętego połączenia to proces ustanawiany, gdy jeden koniec serwera i klienta zamierza zakończyć połączenie. TCP jest procesem zorientowanym na połączenie, dlatego każde gniazdo jest otwierane dla określonej aplikacji. W TCP nie ma presji na zakończenie aplikacji. W ten sposób proces zorientowany na połączenie przedłuża zakończenie o sygnały oczekiwania. jest to nazywane jako pół zamknięte w TCP (połączenie)