parámetros del servidor núcleo del problema (problemas de red androide) con respecto a un aspecto de la evolución

Reproducido problema (con el propio autor se encontró con el mismo problema)

Descripción del problema

Descripción del problema: En los últimos años en el desarrollo de Android, ha encontrado un problema me está molestando durante mucho tiempo, a veces en compañía de wifi, solicitar propio servidor de nuestra empresa es muy lento, y con frecuencia petición falla, cambiar a 3G o redes móviles 4G, que es significativamente más rápido. wifi pero en el mismo entorno, el ordenador solicita de forma rápida y con el iphone

Apenas comienza a descubrir el teléfono del wifi tiempo muy lento, pensó que era la red de la empresa, a fin de buscar operación y mantenimiento para resolver, operación y mantenimiento de la explicación es que la banda ancha Dr. Beijing Peng nuestra empresa con la sala de la compañía de banda ancha Beijing Unicom con la empresa conexión de red a través de los servidores de la compañía al punto de transferencia de Wuhan para conectarse a los servidores de la compañía, en torno a un gran círculo, lo que lleva a solicitud lenta, la solución es el acceso a múltiples operadores , pero debido a los problemas de presupuesto de la empresa, esto no es la ley resuelto.

Más tarde encontré la conexión con el servidor único teléfono Android más lentamente, computadoras iPhone y Windows solicitudes son normales, sospecho que puede ser una aplicación de solicitudes de trama de red en cuestión, y por lo tanto escribí específicamente un demo, con Android proporciona solicitud directa HttpURLConnection, y el sistema a continuación, busque interfaz solicitud directamente, sino que también tienen el mismo problema, el problema de la trama descartada.

Se teléfonos Android calidad módulo WiFi comparar los tiempos, por lo que poner a su disposición todos los teléfonos Android se prueban de nuevo, si es caro o barato, o potencialmente explosiva espíritu artesanal tiene este problema, y también se encuentra en el hogar a una velocidad de viento, wifi. Así que la pregunta módulo WiFi también está descartado.

Los datos más adelante queremos hacer es enviar un problema, por lo que empecé a usar la captura violinista, y luego descubrí que mientras el proxy, el proxy a las computadoras de la aplicación de la compañía en el wifi de la empresa, la conexión es muy suave, y más tarde el uso deliberado de un teléfono móvil para hacer un punto caliente, a otro teléfono wifi compartir y muy suave /

En este punto, debido al nivel limitado, puede intentar se utilizan todos los métodos, no hay ninguna razón para localizar, este problema será archivado. Entonces, un día okhttp estudio, ver la agrupación de conexiones multiplexadas, se repente pensar en ello, con este motivo, desea ver la conexión no se reutilizará, comenzará a capturar teléfono Android, y no a modo de apoderado etéreo, a la captura directa, métodos de captura: http://blog.csdn.net/jk38687587/article/details/48467329

prueba etérea

Después de instalar la herramienta de captura, el teléfono comienza a capturar, comparando el paquete de petición y el ordenador directamente, nos pareció que el wifi teléfono, donde Tcp montón de retransmisión, que se muestra en la figura.

pérdida de pantalla

Qué demonios, SYN qué demonios es, ACK es válida y, así, para estudiar intensamente protocolo TCP / IP y, a continuación, busque en Google, dijo que el primer apretón de manos (SYN) cuando una red de solicitud de retransmisión de tiempo de espera, pero ¿Por qué el tiempo de espera, si la red no es la razón por la solicitud a que las ventanas no se pueden hacer paquetes de horas extras? a continuación, compare cuidadosamente a ambos lados de la cuestión, se encontró que Android emitió al paquete de las ventanas enviaron más que un paquete de marcas de tiempo de campo, mira esto es Qué demonios, encontró el http://blog.csdn.net/jueshengtianya/article/details/50440696 , es posible que las marcas de tiempo pueden hacer que el cliente no puede acceder al servidor.

Hay dos soluciones:

Uno de ellos es el tiempo servidor de marca se establece en 0 net.ipv4.tcp_timestamps
El otro es el cliente, una marca de tiempo está cerrado, no podemos cambiar el servidor, el cliente primer cambio de cambiarlo, cómo cambiar la forma en que el cliente, en busca de respuestas en el proceso también encontró que uno se encuentra con el mismo problema con mi Android los eventos de pérdida de paquetes de red , primero trataron de usar Root Explorer para modificar el archivo / proc / sys / net / ipv4 carpeta tcp_timestamps (aquí encontrado un pozo, que puede ser editado directamente modificar, pasan con gran dificultad no modificado con éxito , que no es completamente raíz, jugar con la raíz por un largo tiempo, no tuvo éxito, pero más tarde se encontró a ser necesario modificar el mandato, consulte http://blog.csdn.net/apn172/article/details/8034240 )
primero marcas de tiempo establecido es 0,

Las marcas de tiempo se pone a 0

pantalla etérea

ts0.png

tsd0.png

Las marcas de tiempo pasado, el efecto es importante legislación, todos se han ido retransmisión

Entonces el conjunto de vuelta:

pantalla etérea

ts1.png

tsd1.png

El problema ha surgido, de ida y vuelta intentado docenas de veces para confirmar el problema es este parámetro. Sí buen sentido de logro.

Pero la solución definitiva al problema tuvo que cambiar el servidor, porque el cliente para cambiar los parámetros a ser root, así que después de la operación y el mantenimiento de la comunicación con los estudiantes, el servidor net.ipv4.tcp_timestamps se establece en 0 y 1, respectivamente, para verificar el efecto, el resultado es obviamente, el problema es este parámetro, el servidor finalmente los estudiantes este parámetro se establece en 0, hasta ahora, me ha preocupado desde hace mucho tiempo el problema se ha resuelto finalmente! ! !

Más tarde, comprueban los tcp_timestamps de información pertinentes entienden un protocolo RFC1323 bits en Linux ** Si se abre tcp_tw_recycle, se supondrá que el par tcp_timestamps abrió, y luego irá a la comparación de marca de tiempo, si la marca de tiempo más grande que pueda ser reutilizado. ** tcp_timestamps registro es ahora desde el arranque en el número de segundos transcurridos, tcp_tw_recycle después de la apertura sería más de lo mismo tcp_timestamps del IP de la red pública, por lo que en la misma wifi, la primera vez que el SYN, tcp_timestamps si se compara con otros dispositivos tcp_timestamps pequeño, entonces el paquete se descarta directamente.

Por el lado del servidor está abierto parámetros marcas de tiempo ayuda a proteger contra ataques DDoS

Acerca de los parámetros del kernel optimizado en el archivo /etc/sysctl.conf

1) Número predeterminado es TIMEWAIT 180000 (Deven: Así que si usted quiere hacer tcp_max_tw_buckets TIMEWAIT caen valor disminuye)

net.ipv4.tcp_max_tw_buckets = 6000

2) Permitir que el sistema para abrir un rango de puertos

net.ipv4.ip_local_port_range = 1024 65000

3) permitir tomas rápidas función de recuperación del estado TIEM_WAIT, el número de conexiones TCP para el estado TIME-WAIT rápida DESCRIPCIÓN. 1 representa el principio; 0 significa cerrados, pero prestar especial atención a lo siguiente: En general, esto no es recomendable para permitir estado, debido a que en NAT (Network Address Translation) de red, TCP hará que una gran cantidad de errores de enlace, lo que llevó al fracaso de acceso al sitio.

net.ipv4.tcp_tw_recycle = 0

De hecho, la función net.ipv4.tcp_tw_recycle abierto requiere net.ipv4.tcp_timestamps (sistema general de esta característica está habilitada por defecto) después de que el interruptor se enciende eficaz; se activa cuando el tcp_tw_recycle (tcp_timestamps abiertas al mismo tiempo, el efecto de la recuperación rápida de la toma REACH), que se encuentra detrás de un dispositivo NAT para el cliente, es un desastre! tcp_tw_recycle que esta función es para la red interna (propio entorno de red controlada "" la ausencia de NAT) diseñado para entornos públicos al lado, no se debe utilizar.

En términos generales, toma de reciclaje de estado TIME_WAIT, porque "no se puede tomar la iniciativa para vincular extremo remoto" porque no hay puertos disponibles, y no debe ser para reclamar memoria (no es necesario)

Es decir, la demanda es la demanda del cliente, el servidor tendrá un "puerto no es suficiente," el problema?

A menos que la máquina es de front-end, servicios de back-end necesitan una gran cantidad de enlaces, es decir, como el papel del cliente.