net.ipv4.tcp_app_win은 무엇을 합니까?

net.ipv4.tcp_app_win은 무엇을 합니까?

Linux에서 tcp_adv_win_scale 및  변수가 공존하는 이유를 알 수 없습니다 . tcp_app_win정보는TCP(7)말한다:

을 위한 tcp_adv_win_scale:

tcp_adv_win_scale(정수; 기본값: 2; Linux 2.4부터)

    버퍼링 오버헤드를 다음과 같이 계산합니다.bytes/2^tcp_adv_win_scale, 만약에 tcp_adv_win_scale0보다 크다; 또는 bytes-bytes/2^(-tcp_adv_win_scale), 만약에tcp_adv_win_scale0보다 작거나 같습니다.

     소켓 수신 버퍼 공간은 애플리케이션과 커널 간에 공유됩니다. TCP는 버퍼의 일부를 TCP 창으로 유지하며 이는 상대방에게 알리는 수신 창의 크기입니다. 나머지 공간은 "애플리케이션" 버퍼로 사용되며, 스케줄링 및 애플리케이션 대기 시간으로부터 네트워크를 분리하는 데 사용됩니다. 그만큼tcp_adv_win_scale기본값 2는 애플리케이션 버퍼에 사용되는 공간이 전체 공간의 1/4임을 의미합니다.

그리고 tcp_app_win:

tcp_app_win(정수; 기본값: 31; Linux 2.4부터)

    이 변수는 버퍼링 오버헤드를 위해 예약된 TCP 창의 바이트 수를 정의합니다.

    최대 (window/2^tcp_app_win, mss) 창의 바이트는 애플리케이션 버퍼용으로 예약되어 있습니다. 값이 0이면 예약된 금액이 없음을 의미합니다.

그래서 정확히 무엇이 바뀌는 지 잘 모르겠습니다 tcp_app_win. 제가 보기에는 두 변수를 모두 사용하여 TCP 애플리케이션 버퍼를 조정할 수 있으므로 함께 변경할 필요가 없습니다. 내 말이 맞나요?

답변1

에 관한 정보를 찾았습니다 tcp_adv_win_scale. 페이지 제목은 다음과 같습니다.TCP 성능 튜닝 - Linux를 튜닝하는 방법.

발췌

TCP 성능은 window_size/RTT(주어진 순간에 링크를 통해 "전송"될 수 있는 데이터의 양)에 따라 대기 시간과 창 크기(및 유효 창 크기를 줄이는 오버헤드)에 의해 제한됩니다.

가능한 실제 전송 속도를 얻으려면 결과 창을 대기 시간(초)으로 나누어야 합니다.

오버헤드는 window/2^tcp_adv_win_scale(tcp_adv_win_scale 기본값은 2)입니다.

따라서 수신 창(tcp_rmem)에 대한 Linux 기본 매개변수의 경우: 87380 - (87380 / 2^2) = 65536입니다.

대서양 횡단 링크(150ms RTT)가 주어지면 최대 성능은 65536/0.150 = 436906바이트/초 또는 약 400kbyte/s로 끝나며 이는 오늘날 매우 느립니다.

증가된 기본 크기: (873800 - 873800/2^2)/0.150 = 4369000바이트/s 또는 약 4Mbytes/s로, 이는 최신 네트워크에 적합합니다. 그리고 이것이 기본값이라는 점에 유의하세요. 발신자가 더 큰 창 크기로 구성되면 최대 10배까지 확장됩니다(8738000*0.75/0.150 = ~40Mbytes/s). 이는 현대 네트워크에 꽤 좋습니다.

2.6.17 이상 버전은 매우 좋은 기본값을 가지며, 상대방이 지원하는 경우 실제로 창 크기를 허용되는 최대값까지 조정합니다. 따라서 그 이후로 이 가이드의 대부분은 필요하지 않습니다. 그러나 장거리 처리량을 높이려면 최대 값을 늘려야 할 수도 있습니다.

나는 그것을 따라갈 수 있었지만 이 두 변수 사이의 관계를 잘 이해하지 못했습니다.

나는 그것이 설명하려는 내용을 약간만 이해했습니다. 핵심적으로는 TCP와 애플리케이션에 사용되는 버퍼링 공간의 양을 확장하는 이 매개변수처럼 들립니다.

조금 더 검색해 보니 더 이해가 되는 설명을 찾았습니다. 페이지 제목은 다음과 같습니다.Ipsysctl 튜토리얼 1.0.4 - 3장. IPv4 변수 참조.

발췌

3.3.2. tcp_adv_win_scale

이 변수는 TCP 창 크기에 사용해야 하는 소켓 버퍼 공간의 양과 애플리케이션 버퍼를 위해 절약할 양을 커널에 알려주는 데 사용됩니다. tcp_adv_win_scale이 음수인 경우 다음 방정식을 사용하여 창 크기 조정을 위한 버퍼 오버헤드를 계산합니다.

여기서 bytes는 창의 바이트 양입니다. tcp_adv_win_scale 값이 양수이면 다음 방정식을 사용하여 버퍼 오버헤드를 계산합니다.

tcp_adv_win_scale 변수는 정수 값을 가지며 기본적으로 2로 설정됩니다. 이는 애플리케이션 버퍼가 tcp_rmem 변수에 지정된 총 버퍼 공간의 1/4임을 의미합니다.

3.3.3. tcp_app_win

이 변수는 특정 TCP 창이 전송되는 TCP 소켓 메모리 버퍼에서 특정 TCP 창을 위해 예약할 바이트 수를 커널에 알려줍니다. 이 값은 예약할 버퍼 공간의 양을 지정하는 계산에 사용됩니다. 다음과 같은:

수식의 ss

위의 계산에서 알 수 있듯이 이 값이 커질수록 특정 창에 대한 버퍼 공간은 작아집니다. 이 계산의 유일한 예외는 0입니다. 이는 커널이 이 특정 연결을 위해 공간을 예약하지 않도록 지시합니다. 이 변수의 기본값은 31이며 일반적으로 좋은 값입니다. 수행 중인 작업을 알지 못하는 경우에는 이 값을 변경하지 마십시오.

이러한 설명에 따르면 첫 번째 매개 변수는 tcp_adv_win_scaleTCP 창 사용과 응용 프로그램 버퍼에 맞게 분할되는 방식에 따라 소켓 버퍼 공간의 분할을 제어하는 ​​것 같습니다.

두 번째 매개변수는 설명 tcp_app_win에 언급된 애플리케이션 버퍼용으로 예약할 바이트 수를 지정합니다 tcp_adv_win_scale.

답변2

커널 소스에서 얻은 결과는 다음과 같습니다.

새로운 연결에 적용하기 위해 버퍼를 예약하고 데이터 수신 시 버퍼를 늘리는 것이 논리가 아니라고 말하고 싶습니다.
그런 식으로 초기 rwnd는 이론적으로 전체 버퍼만큼 크게 광고될 수 있습니다. 발신자는 그만큼의 데이터를 보낼 것입니다. 수신기 버퍼가 채워지고 수신기는 tcp_adv_win_scale에 따라 win을 축소하고 버퍼의 애플리케이션 부분을 늘립니다.
그래서 에서 언급한 것처럼@slm답변 - tcp_app_win을 건드릴 이유가 없는 것 같습니다.

관련 정보