nginx android app 느 린 네트워크 요청 시간 초과

최근 안 드 로 이 드 가 느 린 네트워크 에서 서버 보 고 를 요청 하 는 것 을 만 났 습 니 다.

java.net.SocketException: recvfrom failed: ECONNRESET (Connection reset by peer)
java.net.SocketTimeoutException: failed to connect to mobile2.itanzi.com/120.27.142.146 (port 80) after 15000ms
java.net.SocketTimeoutException: timeout
java.net.UnknownHostException: Unable to resolve host "mobile2.itanzi.com": No address associated with hostname

한편, ios 는 이 문제 가 존재 하지 않 습 니 다. 원인 을 알 지 못 하고 안 드 로 이 드 의 원인 이 라 고 생각 합 니 다.

netstat -an |grep 'ESTABLISHED' |grep 'tcp' |wc -l
243

하나의 tcptw_recycle, 높 은 병발 을 지원 하기 위해 이것 을 열 었 습 니 다. 즉, tcp 가 회수 요청 을 했 습 니 다. 이것 을 열 었 다 면 기본 60s 에서 같은 ip 가방 을 가 져 오 면 회수 되 었 을 것 입 니 다. 게임 네트워크 는 여러 개의 프 록 시 네트워크 를 거 쳤 습 니 다. 프 록 시 네트워크 에서 온 패 킷 의 시간 은 이 요청 시간 보다 적 을 것 입 니 다. 그러면 서버 는 그 가 잘못된 연결 이 라 고 생각 할 것 입 니 다.연결 을 거부 하기 때문에 TCP 패키지 재 전송 이 나타 나 는 것 입 니 다. 실천 을 바탕 으로 검사 이론의 유일한 기준 이 므 로 고 쳐 보 세 요.

vim /etc/sysctl.conf
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_tw_recycle = 0

인터넷 에서 찾 아 봤 는데
tcp_tw_reuse、tcp_tw_휴지통 사용 장면 및 주의사항
linux TIME_WAIT 관련 매개 변수:

net.ipv4.tcp_tw_reuse = 0          。   TIME-WAIT sockets      TCP  ，   0，    
net.ipv4.tcp_tw_recycle = 0      TCP   TIME-WAIT sockets     ，   0，    
net.ipv4.tcp_fin_timeout = 60                ，           FIN-WAIT-2     （   30，    FIN-WAIT-2      ）

 
주의:
- 윈도 우즈 와 달리 레 지 스 트 리 지 를 수정 하여 2MSL 값 을 수정 할 수 없 으 며, Liux 는 MSL 을 수정 할 수 없습니다. tcpfin_timeout 은 2MSL 이 아니 라 Fin - WAIT - 2 상태 입 니 다.
- tcp_tw_reuse 와 SOREUSEADDR 은 전혀 다른 거 예요.
 
1. tw_reuse，tw_recycle 는 클 라 이언 트 와 서버 timestamps 가 열 릴 때 만 사용 할 수 있 습 니 다 (기본 값 으로 열 림)
2. tw_reuse 클 라 이언 트 에 게 만 작용 합 니 다. 오픈 후 클 라 이언 트 는 1s 내 에서 회수 합 니 다.
3. tw_recycle 는 클 라 이언 트 와 서버 에 동시에 작용 합 니 다. 3.5 * RTO 내 회수, RTO 200 ms ~ 120 s 구체 적 인 시간 은 네트워크 상황 을 본다.
내부 네트워크 상황 비 twreuse 가 조금 빠 르 고, 특히 모 바 일 네트워크 는 대부분 tw 보다reuse 느 리 고 장점 은 서버 를 회수 할 수 있 는 TIMEWAIT 수량
클 라 이언 트
1. 클 라 이언 트 로 서 포트 65535 문제 가 있어 TIMEOUT 과 다 처리 능력 에 직접적인 영향, tw 열기재사 용 하면 해결 할 수 있 습 니 다. 동시에 tw 를 여 는 것 을 권장 하지 않 습 니 다.휴지통
2. tw_reuse 는 클 라 이언 트 1s 가 연결 회 수 를 완성 하도록 도와 주 고 대체적으로 단기 6w / s 요청 을 실현 할 수 있 으 며 더 높 으 면 IP 수량 을 증가 합 니 다.
3. 만약 에 내부 네트워크 에서 장면 을 측정 하고 클 라 이언 트 가 연결 을 받 지 않 아 도 된다 면 동시에 tw재 활용 은 조금 좋 을 거 예요.
4. 업무 상 서버 에서 주동 적 으로 연결 을 닫 도록 설계 할 수 있 습 니 다.
서버
1. tw 열기재사 용 무효
2. 온라인 환경 tw_recycle 열지 마.
   서버 가 NAT 부하 에 있 거나 클 라 이언 트 가 NAT 뒤에 있 는 경우 (이것 은 일정한 일이 고 기본 회사 의 가정 네트워크 는 모두 NAT 로 갑 니 다).
공공 네트워크 서비스 가 열 리 면 일부 연결 이 실패 할 수 있 습 니 다. 내부 네트워크 는 상황 에 따라 열 수 있 습 니 다.
   우리 회사 의 대외 서 비 스 는 모두 부하 뒤에 놓 으 면 부하 가 timestamp 를 모두 비 울 것 이다. 그래, 네가 열 어도 소 용이 없다.
3. 서버 TIMEWAIT 높 으 면 어 떡 해?
   클 라 이언 트 가 포트 제한 이 있 는 것 처럼 대량의 TIME 처리WAIT Linux 는 최적화 되 어 있 습 니 다. 각각 TIME 에 있 습 니 다.WAIT 상태 에서 연결 메모리 소모 가 적 습 니 다.
그리고 tcp 를 통 해서 도max_tw_buckets = 262144 최대 상한 선 을 설정 하고 현대 기 계 는 일반적으로 이 메모리 가 부족 하지 않다.
    다음은 초당 최고치 1w 가 요청 한 http 짧 은 연결 서비스 와 같이 장기 적 으로 tw 에 있 습 니 다.buckets 넘 침 상태,
tw_socket_TCP 는 70M 을 차지 합 니 다. 업무 단순 서비스 가 CPU 200% 를 차지 하기 때문에 안정 적 으로 작 동 합 니 다.