Co to znaczy, że połączenia TCP mają zostać zmienione?

Question

W kontekście serwisów internetowych widziałem termin "rezygnacja z połączenia TCP". W szczególności Twitter finagle ma sposoby uniknięcia tego. Jak to się stało? Co to znaczy?

Answer 1

Dla tego terminu może być wiele zastosowań, ale zawsze widziałem, że jest używany w przypadkach, gdy wiele połączeń TCP jest tworzonych w bardzo krótkim czasie, powodując problemy z wydajnością na kliencie i potencjalnie na serwerze. .

To często występuje, gdy zostanie napisany kod klienta, który automatycznie łączy się z awarią TCP jakiegokolwiek rodzaju. Jeśli wystąpi awaria połączenia przed nawiązaniem połączenia (lub bardzo wcześnie w wymianie protokołów), wówczas klient może przejść do pętli o bardzo dużym natężeniu, stale wykonując połączenia. Może to spowodować problemy z wydajnością po stronie klienta - po pierwsze, że istnieje proces w bardzo obciążonej pętli, która zasysa cykle procesora, a po drugie, że każda próba połączenia zużywa numer portu po stronie klienta - jeśli jest wystarczająco szybki, oprogramowanie może owijać się wokół kiedy osiągną maksymalny numer portu (ponieważ port jest tylko 16-bitowym numerem, z pewnością nie jest to niemożliwe).

Podczas pisania solidnego kodu jest wartym celem, to proste "automatyczne ponawianie" podejście jest trochę zbyt naiwny. Podobne problemy można zaobserwować w innych kontekstach - np. proces nadrzędny nieustannie restartujący proces potomny, który natychmiast ulega awarii. Jednym z powszechnych mechanizmów unikania tego jest pewnego rodzaju rosnący back-off. Tak więc, gdy pierwsze połączenie się nie powiedzie, natychmiast połączysz się ponownie. Jeśli ponownie się nie powiedzie w krótkim czasie (na przykład 30 sekund), poczekaj, powiedzmy, 2 sekundy przed ponownym połączeniem. Jeśli ponownie się nie powiedzie w ciągu 30 sekund, poczekasz 4 sekundy i tak dalej. Przeczytaj the Wikipedia article on exponential backoff (lub this blog post może być bardziej odpowiedni dla tej aplikacji), aby uzyskać więcej informacji o tej technice.

Takie podejście ma tę zaletę, że nie przytłacza klienta lub serwera, ale także oznacza, że ​​klient może nadal odzyskiwać dane bez ręcznej interwencji (co jest szczególnie ważne w przypadku oprogramowania na serwerze nienadzorowanym lub na przykład w dużych klastry).

W przypadkach, w których czas odzyskiwania jest krytyczny, proste ograniczenie szybkości tworzenia połączeń TCP jest również możliwe - być może nie więcej niż 1 na sekundę lub coś podobnego. Jeśli jednak na serwer jest wielu klientów, to bardziej uproszczone podejście może pozostawić serwer obciążony obciążeniem akceptacji, a następnie zamknięciem wysokiego współczynnika połączenia.

Trzeba pamiętać, że jeśli planujesz zastosować wykładniczy rozkład wartości - sugeruję nałożenie maksymalnego czasu oczekiwania lub może się okazać, że długotrwałe niepowodzenia powodują, że klient zbyt długo nie odzyskuje mocy po tym, jak serwer przestanie ponownie akceptować połączenia. W większości przypadków sugerowałbym jakieś 5 minut jako rozsądne maksimum, ale oczywiście zależy to od aplikacji.