Мы получаем 7% сообщений сброса для наших сообщений уровня TCP. У нас есть два набора журналов.
Первый из журналов Wireshark показывает хороший запрос и ответ. Здесь клиент получил ответ с подтверждением синхронизации, например [syn, ack] seq = 0 ack = 1
[syn, ack] seq = 0 ack = 1
Второй набор журналов показывает, что сервер ответил с SEQ = 1 напрямую, и ACK имел большой номер ACK, на который клиент, отправивший сообщение, отправил сообщение сброса.
[ACK] seq = 1 ack = большой номер подтверждения
Какие настройки сервера мы должны изменить на нашем сервере Linux, чтобы изменить сообщения ACK, чтобы эти сбросы можно было остановить.
То, что вы видите, является нормальным поведением, если предыдущее TCP-соединение не было отключено должным образом.
Если номера портов соответствуют предыдущему соединению, которое было полностью закрыто на клиенте, но остается установленным на сервере, произойдет последовательность, которую вы видите.
Клиент отправит SYN
, потому что он не помнит старое соединение. Сервер увидит SYN
прибытие на соединение в установленном состоянии, что является неожиданным. Но поскольку это действительное соединение, сервер не может ответить RST
. Вместо этого он отправит ACK
соответствующие текущим порядковым номерам, известным серверу.
Клиент получит ACK
для соединения, которое еще не установлено. Первый пакет в каждом направлении должен иметь SYN
бит установлен. Итак, клиент знает ACK
для предыдущего соединения и ответит RST
. В RST
удалит старое соединение с сервера.
После SYN
, ACK
, и RST
пакеты были отправлены, клиент может повторно передать SYN
пакет. На этот раз рукопожатие сработает.
Существует несколько возможных причин, по которым старое соединение оказывается в разорванном состоянии. Вот несколько возможностей: