Linux 커널 매개변수 "net.ipv4.tcp_workaround_signed_windows"

Linux 커널 매개변수 "net.ipv4.tcp_workaround_signed_windows"

네트워크를 통해 대량의 데이터를 전송할 때 간헐적으로 네트워크 문제가 발생하는데 누군가 이 옵션을 1로 설정하면 문제가 해결될 수 있다고 제안했습니다.

문서에 따르면:

tcp_workaround_signed_windows  (Boolean; default: disabled; since Linux
   2.6.26)
          If enabled, assume that no receipt of  a  window-scaling  option
          means  that  the remote TCP is broken and treats the window as a
          signed quantity.  If disabled, assume that the remote TCP is not
          broken  even  if  we do not receive a window scaling option from
          it.

TCP를 아는 사람이라면 이 매개변수의 역할이 정확히 무엇인지 명확히 알 수 있습니까? 창 크기 조정이 무엇인지, "창 크기 조정 옵션을 받지 못했다고 가정하면 원격 TCP가 손상되었음을 의미"하는 것이 이 상황에서 어떻게 크게 도움이 될 수 있는지 잘 모르겠습니다.

또한 내가 겪고 있는 문제가 무엇인지 정확히 좁히지 않았다는 점을 언급해야 합니다. 이 문제는 간헐적으로 발생하고 데이터 전송이 예기치 않게 중단됩니다(Wireshark는 두 컴퓨터 간의 패킷 전송이 지연되는 것을 보여줍니다). 다른 몇 가지 항목이 있으며 이 값을 설정하는 것이 도움이 되는 것 같습니다.

감사해요

답변1

TCP에서 창 크기는 수신자가 현재 수신할 수 있는 데이터 바이트 수를 나타내는 16비트 부호 없는 필드입니다.

주어진 시간에 64KB의 데이터만 전송할 수 있으므로 16비트로는 충분하지 않은 것으로 나타났습니다. 이것이 창 크기 조정 옵션이 도입된 이유입니다. 창 크기 조정을 사용하면 필드는 여전히 16비트에 불과하지만 단일 바이트를 계산하는 대신 한 번에 2, 4, 8, ... 또는 16384바이트를 계산할 수 있습니다.

창 크기 조정이 작동하는 방식에 대한 정확한 세부 사항은 귀하의 질문과 특별히 관련이 없습니다. 인용한 설명에 따르면 이 tcp_workaround_signed_windows옵션은 창 크기 조정이 사용되지 않는 경우에만 적용됩니다.

이 옵션이 창 크기 조정이 비활성화된 경우에만 적용되는 이유는 창 크기 조정을 지원하지 않는 이전 시스템에서만 발생하는 버그에 대한 해결 방법일 수 있습니다.

실수

참조에는 창 크기 필드를 부호 있는 값으로 처리하는 버그가 있는 수신기가 언급되어 있습니다. 이는 최대 32KB의 모든 값에 대해 잘 작동하지만 32KB 이상의 값은 음수로 잘못 해석된다는 것을 의미합니다.

그 결과, 이 오류가 있는 피어에게 현재 48KB 이상의 데이터를 수신할 메모리가 있다고 말하면 피어는 이를 -16KB로 잘못 해석하고 다음 1.4KB가 분명히 승리하기를 원하기 때문에 더 많은 데이터 전송을 중단하게 됩니다. 맞지 않아. (또는 양수 값이어야 하는 필드에서 음수 값을 발견하면 그보다 더 어리석은 일을 할 수도 있습니다.)

이 오류가 발생하면 매우 오래된 소프트웨어를 실행하는 특정 컴퓨터와 통신할 때 아무 이유 없이 데이터 전송이 중지되는 것을 볼 수 있습니다.

이 문제는 32KB보다 큰 창 크기를 전송하지 않음으로써 해결될 수 있습니다. 해당 설명에서 설정이 그렇게 되기를 바랍니다.

설정은 무엇을 합니까?

사용 가능한 창 크기를 64KB에서 32KB로 줄이면 이 오류가 발생하는 TCP 구현과 통신할 때 연결 중단을 피할 수 있습니다.

그러나 여기에는 비용이 따릅니다. 전송 속도가 창 크기에 의해 제한되는 경우 창 크기를 절반으로 줄이면 전송 속도도 절반으로 줄어듭니다. 따라서 원래 예상 속도보다 느리게 실행되던 전송이 결국 절반 속도로 실행될 수 있습니다.

이것이 바로 이 해결 방법이 영구적으로 활성화되지 않는 이유입니다.

창 크기 조정을 사용하지 않을 때만 문제를 해결하는 이유는 무엇입니까?

이 오류와 창 크기 조정 사이에는 직접적인 연관성이 없습니다. 따라서 창 크기 조정을 고려해야 하는 유일한 이유는 그것이 특정 버그가 있는 구현을 탐지하는 데 가장 잘 알려진 경험적 방법이기 때문이라고 생각합니다.

누군가가 창 크기 조정을 구현하기 전에 이와 같은 버그가 수정될 가능성이 있는 것처럼 들립니다. 결국 더 큰 창이 필요한 경우 창 크기를 실제 크기의 절반으로 제한하는 버그를 수정하지 않는 것은 어리석은 일입니다.

답변2

창 확대/축소수신 버퍼의 크기를 원래 허용된 것보다 크게 확장할 수 있도록 TCP에서 설정할 수 있는 옵션입니다. 이 옵션이 어떻게 도움이 되는지 확실하지 않습니다. 구현에 버그가 있는 경우 이 방법으로 설정하거나 다른 방법으로 버그를 피할 수 있을 것이라고 생각했지만 현실적으로 TCP는 어느 쪽이든 작동해야 합니다(어떤 경우에는 필요한 것보다 조금 더 길어질 수도 있습니다. 더 자주 확인하세요) ).

관련 정보