Dlaczego BGP wdraża swój własny system podtrzymujący zamiast używać tcp keepalive?

BGP nie korzysta z TCP keepalive, używa własnego mechanizmu keepalive. Moje pytanie brzmi: dlaczego bgp nie może włączyć SO_KEEPaLIVE TCP i żyć szczęśliwie? dlaczego nie używa tcp keepalive i nie implementuje własnego keepalive?

„Keepalive” TCP to funkcja, która nie jest dostępna we wszystkich systemach operacyjnych. Nie ma go w samym standardzie TCP i nie jest niezawodny. RC1122 określa to, ale wyraźnie stwierdza:

Wdrażacze MOGĄ włączyć „utrzymywanie przy życiu” w swoich implementacjach TCP, chociaż ta praktyka nie jest powszechnie akceptowana. Jeśli dołączone są podtrzymujące połączenia, aplikacja MUSI być w stanie je włączyć lub wyłączyć dla każdego połączenia TCP i MUSI domyślnie być wyłączona.

Jeszcze ważniejsze:

Bardzo ważne jest, aby pamiętać, że segmenty ACK, które nie zawierają danych, nie są niezawodnie przesyłane przez TCP. W konsekwencji, jeśli wdrożony zostanie mechanizm utrzymywania aktywności, NIE MOŻE interpretować braku odpowiedzi na jakąkolwiek sondę jako martwego połączenia.

Keepalive TCP używa protokołu TCP w specjalny sposób, wysyłając duplikat ACK bez dołączonych do niego danych. Chodzi o to, że nie można liczyć na to, że będzie dostępny. Również niektóre zapory ogniowe filtrują pakiety TCP.

Aby BGP działał poprawnie, potrzebujesz sposobu na wdrożenie określonych timerów utrzymywania aktywności (jak często wysyłamy wiadomość) i wstrzymania (po tym czasie deklarujemy, że peer nie odpowiada), które są wysyłane w sposób niezawodny . Więc BGP używa własnego komunikatu podtrzymującego, który nie stanowi dużego obciążenia (19 bajtów) w porównaniu z utrzymywaniem protokołu TCP.