NanoPi M4 - RK3399: Apache2 + SSL: 대용량 다운로드가 중단됨

NanoPi M4 - RK3399: Apache2 + SSL: 대용량 다운로드가 중단됨

Debian 9(NanoPi M4의 armbian)에서 실행되는 새로운 Apache2 설정이 있습니다.HTTPS를 통해 대용량 파일을 다운로드하기 전까지는 모든 것이 잘 작동합니다.. 그러나 작은 파일은 성공적으로 다운로드되고, 큰 파일은 어느 시점에서 무작위로 실패하는 것 같습니다. 일반 HTTP를 사용하여 이 문제를 재현할 수 없습니다.. 예 wget(브라우저에서도 동일한 동작):

wget https://xyz---/test.bin --no-check-certificate
--2019-01-13 18:22:22--  https://xyz---/test.bin
Resolving xyz--- (xyz---)... 85.241.xxx.xxx
Connecting to xyz--- (xyz---)|85.241.xxx.xxx|:443... connected.
WARNING: cannot verify xyz---'s certificate, issued by 'CN=Let\'s Encrypt Authority X3,O=Let\'s Encrypt,C=US':
  Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1,0G) [application/octet-stream]
Saving to: 'test.bin.2'

test.bin.2                      39%[==================>                               ] 403,66M  11,6MB/s    eta 54s

다운로드는 403,66M에 도달할 때까지 괜찮았으며 그 이후에는 아무 일도 일어나지 않았습니다. 서버측( error.log)에서는 다음과 같은 결과를 얻습니다.

ssl_engine_io.c(2135): [client 85.243.xxx.xxx:59904] OpenSSL: write 16413/16413 bytes to BIO#5588cd8c50 [mem: 5588a87c23] (BIO dump follows)
core_filters.c(525): [client 85.243.xxx.xxx:59904] core_output_filter: flushing because of THRESHOLD_MAX_BUFFER
core_filters.c(547): (70007)The timeout specified has expired: [client 85.243.xxx.xxx:59904] core_output_filter: writing data to the network
ssl_engine_io.c(2144): [client 85.243.xxx.xxx:59904] OpenSSL: I/O error, 16413 bytes expected to write on BIO#5588cd8c50 [mem: 5588a87c23]
(70007)The timeout specified has expired: [client 85.243.xxx.xxx:59904] AH01993: SSL output filter write failed.

실행되는 것 같으나 core_output_filter: flushing because of THRESHOLD_MAX_BUFFER아무 일도 일어나지 않습니다. 때로는 다음 오류도 발견합니다.

ssl_engine_io.c(2135): [client 95.239.xxx.xxx:9937] OpenSSL: write 45/45 bytes to BIO#55bd9e23e0 [mem: 55bd9ec213] (BIO dump follows)
ssl_engine_io.c(2144): [client 95.239.xxx.xxx:9937] OpenSSL: I/O error, 5 bytes expected to read on BIO#55bd9e9d80 [mem: 55bd9ec213]

다음은 이 요청을 처리하는 VHost의 구성입니다.

<VirtualHost *:443>
    ServerName xyz---
    ServerAdmin tcb13---
    DocumentRoot /test
    ErrorLog /test/error.log
    CustomLog /test/access.log combined

    SSLEngine on
    SSLCertificateFile /mnt/SU1/letsencrypt/config/live/xyz---/fullchain.pem
    SSLCertificateKeyFile /mnt/SU1/letsencrypt/config/live/xyz---/privkey.pem
    Header always set Strict-Transport-Security "max-age=15768000"

    LogLevel trace6
</VirtualHost>

다음과 같은 이유로 이것이 네트워크 관련 문제가 아니라고 확신합니다.

  1. SSL이 활성화된 경우에만 발생하며 SSL이 아닌 가상 호스트에서는 문제 없이 다운로드할 수 있습니다.
  2. 다른 프로토콜(FTP 및 SCP)은 동일한 테스트 파일을 정상적으로 다운로드합니다.
  3. iperf3를 사용하여 네트워크를 테스트하는 데에는 문제가 없습니다.

일부 시스템 정보:

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 9.6 (stretch)
Release:        9.6
Codename:       stretch

uname -a
Linux testxyz 4.4.162-rk3399 #41 SMP Fri Oct 26 14:03:47 CEST 2018 aarch64 GNU/Linux

apache2ctl -V | grep -i "Server version"
Server version: Apache/2.4.25 (Debian)
root@testxyz:~# dpkg -l |grep apache2
ii  apache2                         2.4.25-3+deb9u6                                       arm64        Apache HTTP Server
ii  apache2-bin                     2.4.25-3+deb9u6                                       arm64        Apache HTTP Server (modules and other binary files)
ii  apache2-data                    2.4.25-3+deb9u6                                       all          Apache HTTP Server (common files)
ii  apache2-utils                   2.4.25-3+deb9u6                                       arm64        Apache HTTP Server (utility programs for web servers)
ii  libapache2-mod-php7.3           7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f       arm64        server-side, HTML-embedded scripting language (Apache 2 module)

이 문제를 어떻게 해결할 수 있나요? 감사해요.

답변1

나는 이것을 찾을 수 있었다질문그리고RK3399 CPU에 대한 통합 이더넷 및 알려진 문제. USB 3-이더넷 어댑터를 사용해도 이 문제가 발생하지 않습니다.

RK3399와 같은 보드는 재전송 및 오류 재설정을 방지하기 위해 TCP/UDP 오프로딩을 비활성화해야 합니다. 이는 Rock64 및 RockPro64 Rootfs에서 Ayufan에 의해 구현되었으며 DietPi에도 이것이 필요합니다.

이 문제를 해결하는 쉬운 방법은 제거를 비활성화하는 것입니다.

ethtool -K eth0 rx off tx off

그런 다음 를 사용하여 제거 상태를 확인할 수 있습니다 ethtool --show-offload eth0. 제거 기능을 비활성화한 후에는 더 이상 보고된 문제가 없습니다.

재부팅에서 살아남으려면(및 네트워크 다시 시작) /etc/network/if-up.d/disable-offload다음과 유사한 스크립트를 생성할 수 있습니다.

#!/bin/bash
/sbin/ethtool -K eth0 rx off tx off

(파일 이름을 .sh 및 chmod +x로 지정하지 마십시오.)

관련 정보