나는 무선 모뎀을 통해 두 데비안 시스템 사이에 안정적인 ppp/tcpip 링크를 설정하는 데 많은 어려움을 겪고 있습니다.
내 하드웨어 토폴로지는 약간 복잡합니다.
이 시스템은 다음을 사용합니다:
- Raspberry Pi 3B는 무선 링크의 각 끝에서 RPI(raspbianstretch)를 실행합니다.
- RFDesign RFD900x 라디오 모뎀(FTDI 케이블을 통한 USB-RPI)(RFD900)
- NAT(WIFI)를 통해 위성 서비스(SkyMuster - 호주), 호주의 알 수 없는 POP, 인터넷(SAT)으로 작동하는 linksys Wi-Fi 라우터
- SAT를 통해 다른 호주 ISP 고정 IP로 연결되는 VPN(vpnc)은 라우터에 의해 종료됩니다. (이것은 RPI3B의 기본 경로입니다)
- (VPN) VPN 엔드포인트는 고정 IP를 사용하여 네트워크에 연결(END)
나는 문제가 RFD900x 모뎀에 있고 라디오가 패킷을 삭제할 때 발생하는 TCP 정체 폴백과 관련이 있다고 생각합니다. 하지만 제가 어리석은 것을 놓친 경우를 대비해 컨텍스트에 대한 추가 세부 정보를 제공하고 있습니다.
이러한 문제는 RFD900의 RPI 간에 재현 가능합니다.
가장 번거로운 엔드포인트에서 인터넷으로의 링크는 다음과 같습니다.
RPI -> RFD900 -> RFD900 -> RPI -> VPN -> WIFI -> SAT -> 종료.
다시 위의 맥락을 참조하세요.
RFD900은 거리와 장애물로 인해 많은 패킷이 손실됩니다. 나는 다양한 공중 구성을 시도했지만 아무 소용이 없었습니다(옴니, 야기, 직접 대 화강암 절벽에서 튕겨 나가는 것). TCP/IP 신뢰성을 얻기 위해 모뎀, mtu, ppp 설정 등의 다양한 매개변수를 조정해 보았지만 성공하지 못했습니다.
대기 속도는 64kb입니다. 직렬 속도는 57kb입니다.
진단 참고사항:
- 131바이트 또는 151바이트의 무선 MTU 크기는 RFD900을 통해 다양한 거리에 걸쳐 간단한 직렬 간 통신을 수행할 때 최고의 처리량을 갖습니다.
- 지속적인 스트리밍이 아닌 "버스트" -> 버스트, 버스트, 버스트에도 불구하고 처리량은 안정적입니다.
- 나는 이 "폭주"가 TCP가 무선 패킷 손실을 혼잡으로 처리하여 불가피한 재시도 포화를 초래하는 기능이라고 생각합니다.
- 포화 상태가 되면 세션(ssh, scp, apt 등)이 다양한 확장 시간(몇 초, 일반적으로 2-3분, 때로는 10분 이상) 동안 정지되는 것처럼 보입니다.
- apt는 일반적으로 실패합니다. scp와 ssh는 여러 번의 일시 중지와 엄청난 지연 시간이 있기는 하지만 계속 진행하여 결국 목적지에 도달하는 경향이 있습니다.
- 긴 ls -la와 같은 긴 응답이 포함되지 않은 경우 SSH 상호 작용을 통해 링크를 사용할 수 있습니다.
- 모뎀의 흐름 제어(없음, RTSCTS, XONXOFF)는 내 테스트에서 중요하지 않은 것 같습니다.
- 다양한 형태의 ppp 페이로드 압축은 중요하지 않은 것 같습니다(BSD, Predictor, deflate 등).
- Van Jacobsen 헤더 압축은 버스트당 처리량을 증가시키지만 정지 및 대기 시간을 증가시킵니다.
- 나는 해결책을 찾기 위해 광범위하게 검색했습니다(돌아가서 RFC를 읽기도 했습니다).
- VJ 헤더 압축은 손실이 있는 링크 문제로 간주되며 RFC는 다양한 독점 압축 프로토콜로 등장한 것으로 보이는 ROHC 작업 그룹을 포함하여 ROHC - RObust 헤더 압축과 같은 압축 기술에 진전을 보이고 있습니다. 이러한 프로토콜은 오픈 소스입니다.
- 이 문제는 독점 프로토콜(ppp 및 RLP 사용)에 의존하는 셀룰러 링크에 대해 잘 해결된 것으로 보입니다.
나는 또한 pppd를 실행하는 현재 스크립트를 여기에 게시했습니다(내가 시도한 다양한 옵션을 포함하여 - #commented 줄을 참조하십시오.):
# set up the pppd to allow the remote unit to connect as an IP peer
# additional options for remote end: usepeerdns defaultroute replacedefultroute
pppd /dev/ttyUSB0 57600 mru 131 mtu 131 noauth crtscts nocdtrcts lock passive 192.168.10.1:192.168.10.2 local maxfail 0 persist proxyarp updetach
#pppd /dev/ttyUSB0 57600 novj novjccomp mru 131 mtu 131 noauth crtscts nocdtrcts lock passive 192.168.10.1:192.168.10.2 local maxfail 0 persist proxyarp updetach
#pppd /dev/ttyUSB0 57600 192.168.10.1:192.168.10.2 mru 131 mtu 131 proxyarp noauth crtscts nocdtrcts noaccomp nobsdcomp nodeflate nopcomp nopredictor1 novj novjccomp lock mru 131 mtu 131 passive local maxfail 0 persist updetach
#debug ktune bsdcomp 12 xonxoff nocrtscts mru 296 mtu 296
#pppd /dev/ttyUSB0 57600 debug mru 131 mtu 131 noauth crtscts nocdtrcts lock passive 192.168.10.1:192.168.10.2 local maxfail 0 persist updetach proxyarp
#pppd /dev/ttyUSB0 57600 noaccomp nobsdcomp nodeflate nopcomp nopredictor1 novj novjccomp mru 131 mtu 131 noauth crtscts nocdtrcts lock passive 192.168.10.1:192.168.10.2 local maxfail 0 persist proxyarp updetach
#pppd /dev/ttyUSB0 57600 novjccomp mru 131 mtu 131 noauth crtscts nocdtrcts lock passive 192.168.10.1:192.168.10.2 local maxfail 0 persist proxyarp updetach
오픈 소스 pppd를 사용하여 이 문제를 해결한 사람이 있습니까? 대신 사용할 수 있는 다른 옵션이나 기술이 있습니까?
커널 TCP 정체 설정을 조사해 볼 가치가 있나요?
답변1
내 질문에 대한 부분적인 답변으로 다음을 통해 상당한 신뢰성 향상을 달성했습니다.
tcp_congestion_control 커널 플러그인을 기본 큐빅에서 bbr로 변경하면 버퍼 팽창 문제가 크게 해결되었으며, 문제의 핵심인 버퍼 팽창 및 무선 연결 손실이 발생했습니다.
이를 위해서는 tcp_bbr 커널 모듈을 로드하고 net.core 대기열 모델을 공정 대기열로 변경하여 bbr 모듈에 속도를 제공해야 합니다.
RPI의 기본값은 다음과 같습니다.
net.ipv4.tcp_congestion_control=입방체
net.core.default_qdisc=pfifo_fast
런타임 시 이 설정을 변경하는 명령은 다음과 같습니다.
modprobe tcp_bbr
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
현재 /etc/rc.local이라는 스크립트에서 이를 실행합니다. modprode.d 및 sysctl.conf를 수정하거나 sysctl.d의 파일로 쉽게 영구적으로 만들 수 있습니다.
그 결과 더 부드러운 SSH 응답, 더 안정적인 일괄 전송이 이루어졌습니다. 여전히 정지된 상태에서 신속하고 안정적으로 재개하여 즉시 명령 프롬프트로 돌아갈 수 있습니다(100%에서 오랫동안 일시 중지하는 대신(예: 1 - 3을 사용하여 이전 몇 개로 돌아가는 대신) ) 분, 큐빅 혼잡 제어의 경우와 마찬가지로).
전체적인 속도는 절충점이지만 안정성이 더 중요합니다. 예를 들어 scp를 사용하여 라디오 링크를 통해 283k 파일을 전송하면 이제 다음과 같은 결과가 발생합니다.
100% 283KB 2.5KB/s 01:51
이것은 지금까지 제가 만족하는 타협입니다. 그러나 장기간 실행되는 대량 전송 프로세스는 여전히 문제가 있으며 결국 중단되고 완료되지 않습니다.
예를 들어, apt-get 업데이트는 1시간 넘게 실행되었으며(11.7MB 파일에서 정지됨) 계속 실행하려면 가끔 ssh 터미널을 통해 입력해야 했으며, 완전히 실패하지는 않았지만 결국 매우 긴 지연에 갇히게 되었습니다.
아래 화면 캡처에서 프로세스는 1시간 이상 지속되었으며 일부 CR은 10~15분마다 표시되고 ^C 전송과 터미널 응답 사이에는 약 5분 정도 지연이 발생했습니다.
root@priotdev2:~# apt-get update
Get:1 http://mirror.internode.on.net/pub/raspbian/raspbian stretch InRelease [15.0 kB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
Get:2 http://archive.raspberrypi.org/debian stretch InRelease [25.3 kB]
Get:2 http://archive.raspberrypi.org/debian stretch InRelease [25.3 kB]
Get:4 http://archive.raspberrypi.org/debian stretch/main armhf Packages [145 kB]
Get:5 http://archive.raspberrypi.org/debian stretch/ui armhf Packages [30.7 kB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
23% [3 Packages 270 kB/11.7 MB 2%] 2,864 B/s 1h 6min 15s
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
29% [3 Packages 1,263 kB/11.7 MB 11%] 131 B/s 22h 2min 19s
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
60% [3 Packages 5,883 kB/11.7 MB 50%] 16 B/s 4d 4h 13min 58s
60% [3 Packages 5,902 kB/11.7 MB 51%] 1,531 B/s 1h 2min 38s
66% [3 Packages 6,704 kB/11.7 MB 58%]
66% [3 Packages 6,704 kB/11.7 MB 58%]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]
66% [3 Packages 6,735 kB/11.7 MB 58%]
66% [3 Packages 6,735 kB/11.7 MB 58%]
66% [3 Packages 6,745 kB/11.7 MB 58%] 32 B/s 1d 18h 37min 55s
66% [3 Packages 6,745 kB/11.7 MB 58%] 32 B/s 1d 18h 37min 55s
66% [3 Packages 6,745 kB/11.7 MB 58%]
66% [3 Packages 6,745 kB/11.7 MB 58%]
66% [3 Packages 6,746 kB/11.7 MB 58%] 230 B/s 5h 55min 46s
66% [3 Packages 6,747 kB/11.7 MB 58%] 148 B/s 9h 12min 47s^C
root@priotdev2:~# ^C
root@priotdev2:~#
root@priotdev2:~#
위의 덤프 오른쪽으로 스크롤하여 낮은 처리량(경우에 따라 초당 16바이트 및 32바이트까지 감소)을 확인합니다.
위성 링크와 관련된 엔드투엔드 변수를 제거하기 위해 apt 프로세스는 실제로 업스트림 RPI를 apt 캐시(최신 캐시)로 사용하고 전송은 무선 링크의 트래픽만 나타냅니다.
추가 개선 사항에 대한 커뮤니티의 의견을 환영합니다.