TCP SACK을 해제하는시기


28

나는 리눅스 튜닝 매개 변수를 살펴 보았고 SACK이 꺼져있는 구성을 보았습니다. 누구든지 이것을 설명 할 수 있습니까?

이것은 바쁜 웹 서버에 맞게 조정됩니다.

답변:


34

기본 TCP ACK는 "모든 바이트를 X까지 수신했습니다."라고 말합니다. 선택적 ACK를 사용하면 "바이트 XY 및 VZ를 받았습니다."라고 말할 수 있습니다.

예를 들어, 호스트가 당신에게 10,000 바이트를 보내고 3000-5000 바이트가 전송 중에 손실되면 ACK는 "모든 것을 3000까지 얻었습니다"라고 말할 것입니다. 다른 쪽 끝은 바이트 3001-10000을 다시 보내야합니다. SACK는 "1000-2999, 5001-10000을 받았습니다"라고 말할 수 있으며 호스트는 3000-5000을 보낼 것입니다.

이것은 높은 대역폭, 손실 (또는 높은 지연) 링크에 비해 좋습니다. 문제는 특정 상황에서 심각한 성능 문제가 발생할 수 있다는 것입니다. 정상적인 TCP ACK는 서버가 키드 장갑 (500 바이트 전송, 대기, 500 바이트 전송, 대기 등)과의 고 대역폭 손실 연결을 처리하도록합니다. SACK은 실제로 손실 된 패킷 수를 정확히 알고 있기 때문에 높은 지연에 적응할 수 있습니다 .

여기서 나쁜 일이 일어날 수 있습니다. 공격자는 서버가 대규모 재전송 대기열을 오랫동안 유지하도록 강요 한 다음 그 모든 것을 반복해서 처리 할 수 ​​있습니다. 이것은 CPU를 페깅하고, RAM을 소비하며, 필요한 것보다 더 많은 대역폭을 소비 할 수 있습니다. 간단히 말해 경량 시스템은보다 강력한 서버에 대해 DoS를 시작할 수 있습니다.

서버가 강력하고 대용량 파일을 제공하지 않으면 이에 대한 대비가 잘됩니다.

대부분 인트라넷 또는 대기 시간이 짧은 다른 사용자 그룹에 서비스를 제공하는 경우 SACK은 아무 것도 구매하지 않으며 보안상의 이유로 성능 손실없이 끌 수 있습니다.

대역폭이 낮은 링크 (완전히 임의의 경험으로 1Mbps 이하)로 연결되어있는 경우 SACK은 연결을 포화시켜 정상적인 작동에 문제를 일으킬 수 있으므로 꺼야합니다.

궁극적으로, 그것은 당신에게 달려 있습니다. 무엇을 제공하고 누구에게 무엇을 제공하고 SACK의 성능 영향에 대한 위험 정도를 평가하십시오.

여기에 SACK과 그 취약점에 대한 훌륭한 개요가 있습니다.


FTR : Linux 4.18부터 SACK 압축이 가능합니다. 예를 들어 무선 네트워크의 성능을 향상시킬 수 있습니다. 또한 다소 관련성이 있음 : 원래 개발자의 의견 .
Hi-Angel

12

TCP SACK이 자주 비활성화되는 또 다른 이유는이 옵션을 올바르게 처리하지 못하는 엄청난 양의 네트워크 장비가 있기 때문입니다. 우리는 TCP를 사용하는 우리가 제공하는 고속 파일 전송 제품으로 항상 이것을 봅니다. 가장 일반적인 문제는 내부 네트워크에서 외부로 장치를 통과하는 TCP 패킷에 대해 시퀀스 번호를 무작위 화하는 것과 같은 게이트웨이 장치의 문제이지만 원격에서 전송 될 수있는 TCP SACK 옵션을 "무작위 화"하지는 않습니다. 종료. 실제 SACK 값이 이러한 장치에 의해 올바른 값으로 다시 변환되지 않으면 원격 끝에서 SACK을 사용하여 선택적 ACK 이점을 얻으려고 할 때 패킷 손실이 발생하더라도 TCP 세션이 완료되지 않습니다.

사람들이이 소프트웨어에 예방 적 소프트웨어 유지 보수를보다 적극적으로 적용하려는 경우에는 문제가되지 않을 것입니다.


2
이 RedHat KB 기사 : ADSL 라우터 뒤에있는 클라이언트 시스템의 TCP 연결이 Red Hat Enterprise Linux에서 간헐적으로 중단되는 이유는 무엇입니까? kbase.redhat.com/faq/docs/DOC-26683
davey

6

쓴 경험에서 tcp_sack = 1이 특정 Cisco ASA 방화벽 어플라이언스를 사용할 때 약 12mb를 초과하는 파일로 sftp / rsync / scp 등을 통해 데이터 전송이 중단됨을 확인할 수 있습니다.

매번 그것은 멈추게 될 것입니다.

우리는 두 개의 서로 다른 데이터 센터에서 호스트 A와 호스트 B 사이의 전용 100mbps 링크를 통해 Cisco 방화벽과 센 토스가있는 스위치 하드웨어를 사용하고있었습니다.

이것은 버퍼 크기를 수정함으로써 다소 완화 될 수 있습니다. 예를 들어, sftp 버퍼를 2048로 설정하지 않으면 호스트 A에서 호스트 B로 sftp를 통해 1GB 파일을 전송할 수 없었지만 호스트 B가 파일을 A에서 가져 왔는지 여부에 관계없이 가능합니다.

rsync 및 send / receive 버퍼 튜닝을 사용하는 동일한 파일을 사용한 실험을 통해 A에서 B로 푸시 된 1GB 파일의 약 70MB를 얻을 수있었습니다.

그러나 궁극적 인 대답은 호스트 A에서 tcp_sack을 비활성화하는 것이 었습니다. 처음에는 커널에서 tcp_sack = 0을 설정하여 궁극적으로 /etc/sysctl.conf에 추가했습니다.


1
시스코 ASA 방화벽도 여기에 있습니다. 문제의 일방적 인 성격은 당황 스러웠습니다. 우리는 이것을 몇 달 동안 쫓아 왔습니다. scp는 어느 정도 '속도로'작동했지만 정기적으로 지연되고 다른 방향으로 시간이 초과되었습니다. tcp_sack 비활성화는 치료법이었습니다.

@ Jean-loup 장비 교체를 제안하지 않기를 바랍니다. 마지막 작업 에서이 문제가 있었고 구성 변경으로 수정했습니다. unix.stackexchange.com/questions/391125/…
Rui F Ribeiro
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.