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)입니다.
따라서 Linux 수신 창(tcp_rmem)의 기본 매개변수는 87380 - (87380 / 2^2) = 65536입니다.
대서양 횡단 링크(150ms RTT)가 주어지면 최대 성능은 65536/0.150 = 436906바이트/초 또는 약 400kbyte/초가 되며 이는 오늘날 매우 느립니다.
기본 크기가 증가하면: (873800 - 873800/2^2)/0.150 = 4369000바이트/초 또는 약 4MB/초이며 이는 최신 네트워크에 적합합니다. 이것이 기본값이며, 발신자가 더 큰 창 크기로 구성되면 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 창을 위해 예약할 바이트 수를 커널에 알려줍니다. 이 값은 예약할 버퍼 공간의 양을 지정하는 계산에 사용됩니다. 이는 다음과 같습니다.
위의 계산에서 알 수 있듯이 값이 클수록 특정 창에 대한 버퍼 공간은 작아집니다. 이 계산의 유일한 예외는 0입니다. 이는 커널이 특정 연결을 위해 공간을 예약하지 않도록 지시합니다. 이 변수의 기본값은 31이며 일반적으로 적절한 값입니다. 수행 중인 작업을 알지 못하는 경우에는 이 값을 변경하지 마십시오.
이러한 설명에 따르면 첫 번째 매개 변수는 tcp_adv_win_scale소켓 버퍼 공간의 분할, 즉 TCP 창 사용량과 응용 프로그램 버퍼를 나누는 방법을 제어하는 것처럼 들립니다.
두 번째 매개변수는 tcp_app_win설명에 언급된 애플리케이션 버퍼용으로 예약된 바이트 수를 지정합니다 tcp_adv_win_scale.
답변2
커널 소스 코드에서 제가 찾은 내용은 다음과 같습니다.
- 매크로용 tcp_adv_win_scaleinclude/net/tcp.h의 tcp_win_from_space. 이 매크로는 다음 용도로 사용됩니다.net/ipv4/tcp_input.c의 tcp_grow_window 함수.
연결이 아닌 기존 연결에만 해당되는 것 같습니다.
이 매개변수의 기본값은 1이며, 이는 애플리케이션이 rcv 버퍼의 50%를 사용하게 합니다. - tcp_app_win은 다음 용도로 사용됩니다.net/ipv4/tcp_input.c의 tcp_init_buffer_space 함수.
설정된 연결에는 사용되지 않고 연결에만 사용되는 것 같습니다.
이 매개변수의 기본값은 31이며, 이는 애플리케이션이 rcv 버퍼의 0.0%를 사용하게 합니다.
내가 말하려는 논리는 새로운 연결에서 애플리케이션을 위한 버퍼를 예약하고 데이터가 수신될 때 버퍼를 늘리는 것이 아닙니다.
이런 방식으로 초기 rwnd는 이론적으로 전체 버퍼만큼 크게 광고될 수 있습니다. 발신자는 그만큼의 데이터를 보낼 것입니다. 수신자 버퍼가 채워지고 수신자는 tcp_adv_win_scale에 따라 win을 축소하고 버퍼의 적용 부분을 늘립니다.
그래서 에서 언급한 것처럼@slm답변 - tcp_app_win을 건드릴 이유가 없을 것 같습니다.