TCP 헤더 옵션 : SACK 허용 (선택적 수신 확인) 협상


3

나는 TCP 연결을 분할해야하는 연구 프로젝트를하고있다. 그래서 나는 내 발달에서 일어날 수있는 비정상적인 질문을 가지고있다. 문제는 TCP SACK 허용 협상에 대한 이해입니다. 나는 RFC를 읽고 대답을 찾을 수 없다.

두 개의 TCP 프로그램 사이의 3 방향 TCP 핸드 셰이크 : A와 B A가 SACK 허용 된 B로 TCP SYN을 전송하면 B는 SACK 허용 TCP / IP 패킷에 확실하게 SYN / ACK 패킷을 응답합니까? B가 SACK 허용이없는 TCP SYN / ACK로 응답한다면, 의미합니까?

1) SACK-permmited는 A에서만 활성화됩니다. A는 A로부터의 tcp 패킷을 선택적으로 승인 할 수 있지만 A는 B로부터의 tcp 패킷을 선택적으로 승인 할 수 없습니다.

또는

2) SACK-permmited는 A와 B 모두에서 활성화되지 않습니다.

A가 SACK-allowed없이 B에게 TCP SYN을 보낸다면, B는 SACK 허용 된 SYN / ACK 패킷을 응답 할 수 있습니까?

게다가 왜 SACK 허용이 허용되거나 금지되어 있습니까? 그것은 운영 체제 나 커널 설정 또는 다른 것에 달려 있습니까? 그것을 제어 할 수 있습니까? 감사!

답변:


4

SACK은 나중에 추가되었으므로 최종 호스트와 미들 박스 모두에 대한 하위 호환성이 필요합니다 (아래 참조). 그만큼 SACK-permitted 옵션이 바로 그 기능을 수행합니다.

SACK-permitted A가 SACK 옵션을 기꺼이 받기 위해 A에서 B로 전송됩니다. SACK 처리 (대부분의 재전송 처리와 같이)의 경우 TCP는 서로 다른 상태의 두 개의 단일 연결로 구성되어 있다고 볼 수 있습니다. 따라서 SACK이 한 방향으로 만 이동하는 것은 매우 합법적입니다 (그러나 드문 경우입니다). SACK-permitted SYN 또는 SYNACK 중에).

일반적으로 성능을 향상시키기 때문에 SACK를 활성화 된 채로 둘 수 있습니다. 그러나, 거기에는 (그리고 어쩌면 여전히) 방화벽과 NAT 박스가 있으며, SEQ와 ACK 헤더 필드를 변경하지만 SACK을 인식하지 못하고 SACK 옵션에 시퀀스 번호를 적절하게 적용하지 않습니다. 이로 인해 연결이 끊어 질 수 있습니다 (SACK이 수신되지 않은 다른 세그먼트를 확인한 경우). 이것은 두 시스템이 모두 지원하더라도 SACK을 비활성화하려는 이유입니다.

SACK는 * BSD 시스템 (MacOS X 포함)에서 (테스팅 용 또는 위에 언급 된 못생긴 middleboxes 용) 사용 불가능하게 할 수 있습니다. sysctl -w net.inet.tcp.sack=0 다시 1로 설정하면 다시 활성화됩니다. Linux의 경우, sysctl -w net.ipv4.tcp_sack=0 같은 효과를냅니다.

의 첫 단락 RFC 2018의 섹션 4 SACK 허용이 수신 될 때 SACK이 전송되도록합니다. 일반적으로 SACK 가능 호스트는 SACK 허용을 발표합니다. SACK 가능 호스트가 SACK 허용을 광고하지 않지만 SACK을 사용하는 유용한 시나리오를 상상할 수는 없습니다 (비현실적인 예는 SACK를 한 방향으로 만 심하게 움직이는 중간 상자 일 것입니다). 그러므로 나는 한 방향으로 만 SACK을 사용한다고 기대하지 않는다.

Linux, MacOSX (아마도 BSD에 일반화 가능) 및 HP 프린터에 대해 Wireshark를 사용한 빠른 테스트는 SACK 허용이 SYN에있을 때 SYNACK에서 SYACK으로 허용 된 응답을 보여줍니다. 그러나 RFC에서이 동작을 필요로하거나 권장하지는 않습니다.


A가 Sack-permitted를 사용하여 SYN 또는 SYN / ACK를 보내지 만 B는 보내지 않습니다. 그렇다면 A는 B로부터 SACK을 받아 들일 수 있지만 B는 Sack-permitted를 지원하지 않기 때문입니다. 나는 B가 SACK을 보내는 방법을 알고 있는지 궁금 할뿐입니다. 게다가, SACK을 여행하는 한 방향에 관해서는 어떤 참고 문헌이나 관련 기사가 있습니까? 감사!
misteryes

게다가 A가 자루 허용없이 B에 SYN을 보내면 B는 자루 허용 SYN / ACK에 응답 할 것입니까?
misteryes

의 첫 단락 RFC 2018의 섹션 4 SACK 허용이 수신 될 때 SACK이 전송되도록합니다. 일반적으로 SACK 가능 호스트는 SACK 허용을 발표합니다. SACK 가능 호스트가 SACK 허용을 광고하지 않지만 SACK을 사용할 유용한 시나리오를 상상할 수는 없습니다. (비현실적인 예는 SACK를 심하게 다루는 미들 박스 일 것입니다 한 방향으로 만 ). 그러므로 나는 한 방향으로 만 SACK을 사용한다고 기대하지 않는다.
Marcel Waldvogel

1
Linux, MacOSX (아마도 BSD에 일반화 가능) 및 HP 프린터에 대해 Wireshark를 사용한 빠른 테스트는 SACK 허용이 SYN에있을 때 SYNACK에서 SYACK으로 허용 된 응답을 보여줍니다. 그러나 RFC에서이 동작을 필요로하거나 권장하지는 않습니다.
Marcel Waldvogel

-1

Van Jacobsen이나 그의 동료가이 포럼에서 어울리지 않는 한, 당신이 물어 본 것처럼 누구에게나 대답하려고하는 많은 노력을 수반 할 것입니다. 생각해 보면 질문에 대답하는 데 필요한 연구의 수준은 현재 종사하고있는 연구 프로젝트보다 크거나 클 것입니다. 이것은 대다수의 사람들을 평등하게 생각하지 않을 것으로 보입니다.

그러나 우리 중 많은 사람들은 답변이 명확하지 않거나 쉽게 구할 수없는 어려운 질문을해야 할 기회가있었습니다. 내 경우에는 궁극적으로 이러한 질문에 대한 답을 직접 찾아야했지만, 나는 올바른 방향으로 나를 인도하기 위해 도움이되는 사람들을 만날만큼 운이 좋았다.

현재 2 개의 BSD-unix 시스템에 대한 루트 액세스 권한이 없습니다. 나는 선택적인 ACks를 통제 할 수 있음을 안다. sysctl. Mac에서 SACK을 활성화하는 항목은 다음과 같습니다. net.inet.tcp.sack. 활성화되면 값은 1입니다. 사용 중지, sysctl -w net.inet.tcp.sack=0. 다양한 시나리오를 설정하고 사용합니다. tcpdump 문제를 테스트 해보세요.

다른 사람들은 당신에게 다른 힌트를 줄 수 있습니다 ...


감사! BTW, 윈도우 스케일 팩터에 대해 알고 있습니까? 내 이전 질문은 그것에 대해 수퍼 유저 /questions/593715/...
misteryes
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.