Supongamos que el cliente envía dos paquetes de datos al servidor, el servidor debido a un número de bytes leídos incierto, habrá cuatro casos: 1: servidor dos veces a leer dos paquetes de datos independientes , no se produce palillo paquete de desembalaje
2: un servidor de recepción de los dos paquetes de datos, dos unidas entre sí, se hace referencia como paquete stick
3: el servidor en dos ocasiones separadas para leer los dos paquetes de datos, la primera vez que un completo paquete de lectura D1 y D2 partes del paquete, la segunda lectura de los contenidos restantes de D2, que se conoce como TCP desembalaje .
4: terminales de servicio se leen dos veces para dos paquetes, la primera parte de lectura para el contenido del paquete D1, la segunda lectura para el contenido del paquete restantes D1 y D2 de toda la bolsa de envase.
Si el servidor recibe la ventana deslizante TCP es muy pequeño, y el paquetes de datos D1 y D2 es relativamente grande,
Es probable que se produzca en un quinto posible, el servidor varias veces a la recepción de paquetes D1 y D2 por completo, se producen varias veces durante el desembalaje.
Las causas de
1: escritura tamaño en bytes solicitud por escrito es mayor que el tamaño del búfer de transmisión zócalo.
2: TCP MSS tamaño de segmento
3: trama Ethernet payoload supera la fragmentación MTU
estrategias de resolución
Debido a que los datos de servicio de capa superior subyacentes TCP no se pueden entender, no se garantiza en la parte inferior del paquete no se divide y recombina,
Este problema sólo se puede resolver mediante la aplicación de soluciones de diseño del protocolo de capa superior de la pila de protocolos basados en la corriente principal de la industria:
1: una longitud del mensaje, por ejemplo, el tamaño de cada paquete tiene una longitud fija de 200 bytes, si no, el espacio de llenado de brecha;
2: se ha añadido en el carro extremo retornos en el paquete se divide, por ejemplo, el protocolo FTP
3: el mensaje en la cabecera del mensaje y un cuerpo de mensaje, cabecera del mensaje comprende la longitud total de la representación sobre el terreno cuerpo del mensaje,
Típicamente ideas de diseño al primer campo de la cabecera utilizan para indicar la longitud del mensaje 32int
4: protocolo de capa de aplicación más compleja
LineBasedFrameDecoder y Análisis Principio StringDecoder
LineBasedFrameDecoder es que funciona de bytes de lectura secuencial conveniente ByteBuffer, se determina para ver si \ no \ R ^ \ n,
Si es así, esta es la posición final, desde la posición de la sección de extremo para leer el índice del byte en la composición de una fila, que es el extremo marca de interlínea decodificador, los soportes que llevan terminador o terminadores tanto decodificador no lleva una y apoyar una configuración máxima de una sola línea, si la longitud máxima de lectura continua siendo encontró ningún salto de línea será una excepción, los mismos se lee antes ignoran flujo anormal
StringDecoder función es muy simple, que se recibe se convierte en un objeto de cadena, y luego continuar para volver a llamar Handler.
Composición LineBasedFrameDecoder + StringDecoder es un interruptor decodificador fila de texto, el cual está diseñado para apoyar el paquete TCP palo y desembalaje.
serialización de Java Hay dos propósitos principales:
1: La transmisión 2 de red: persistente objetos
serialización de Java se ha proporcionado desde el JDK 1.1, y sólo necesita aplicar java.io.Serializable ID para generar una secuencia
desventajas:
1: No se puede cruzar en lengua, porque la tecnología Java Java es el lenguaje de serialización protocolo propietario interna, otros idiomas no son compatibles para los usuarios, que es completamente cuadro negro. Para el conjunto de bytes de serialización de Java, otros idiomas no se puede deserializar.
2: una secuencia serializada es demasiado grande (el tamaño de la matriz binaria codificada mecanismo de JDK serialización varias veces más grande que el codificado en binario) en las mismas circunstancias, cuanto mayor sea la matriz de bytes codificada, más el espacio cuando se almacena, el mayor costo de hardware de almacenamiento, y representó más transmisión de la red de banda ancha, lo que resulta en una reducción de rendimiento del sistema.
3: Secuencia de rendimiento es muy bajo en las mismas circunstancias, el rendimiento de serialización de Java es muchas veces en código binario.
marco de selección Codec:
1: protobuf de Google sus características son: formato de almacenamiento de datos estructurados (XML, JSON, etc.)
2: alto rendimiento codec
3: independiente del lenguaje, independiente de la plataforma, y una buena escalabilidad
4: apoyo oficial para Java, C ++ y Python en tres idiomas
Protobuf datos del perfil y que tiene un mecanismo de generación de código, se describen la ventaja de utilizar un perfil de datos de la estructura de datos:
1: Pruebas de descripción de estructura de datos lenguaje, el lenguaje se pueden realizar y plataformas independientes, especialmente adecuado para la integración entre sistemas heterogéneos
Compatibilidad hacia adelante por el campo identificador secuencial, un protocolo puede implementarse: 2
3: generación automática de código, escribiendo la misma estructura de datos del C ++ y Java versión no requiere manual de
4: fácil de manejar y mantener, en comparación con el código, documentos estructurados más fáciles de manejar y mantener
Facebook 的 Thrift
Para Facebook, la creación de Ahorro para resolver la transferencia de tráfico de datos de gran tamaño entre los diversos sistemas de Facebook
Así como entre las diferentes localidades sistemas requieren características de plataforma cruzada, que puede soportar múltiples lenguajes de programación de Ahorro
Thrift se puede utilizar como un middleware de comunicación de alto rendimiento que soporta la secuencia de objetos de datos y una pluralidad de tipos de servicios RPC.
Ahorro para el intercambio de datos estáticos, es necesario determinar su estructura de datos bueno,
Cuando se cambia la estructura de datos, es necesario volver a editar el código generado y compilado archivo IDL.
herramienta universal Thrift adecuado para la construcción de almacenamiento de datos de gran tamaño o de transmisión de datos interno cambio de sistemas grandes,
JSON y XML con respecto al tamaño y el rendimiento de transferencia tiene ventajas obvias
Hay cinco componentes principales de Ahorro
1: Sistema compilador de lenguaje IDL, y es responsable de un fichero IDL generación de lenguaje de código correspondiente interfaz por un usuario;
2: TProtocol: RPC capa de protocolo, puede elegir una variedad de diferentes objetos de serialización, como binario y Json
3: TTransport: RPC capa de transporte, puede también optar por aplicar diferentes capas de transporte, tales como un socket, NIO, MemoryBuffer
4: TProcessor: como un enlace entre la aplicación de capa de protocolo y el servicio proporcionado por el usuario, la interfaz es responsable de llamar a la implementación del servicio
5: TServer: polimerización TProtocol, TTransport, y otros objetos TProcessor
Thrift soporta tres códec típico:
1: codecs binarios universales
2: códecs binarias comprimidas
3: Optimización de códecs de compresión de campo de opción
JBoss Marshalling Introducción
JBoss es una API de Java serializados paquetes de objeto, corrige un montón de problemas JDK viene con la secuencia de paquetes, pero siguen siendo compatibles con la interfaz java.io.Serializable, mientras que la adición de algunos parámetros ajustables y características adicionales y estas características y parámetros pueden ser configurados por una clase de fábrica, en comparación con el mecanismo de serialización de Java tradicional, sus ventajas son:
1: clase analizador enchufable proporciona una forma más cómoda políticas personalizadas de carga de clases se pueden personalizar a través de una interfaz
2: técnicas de reemplazo de objeto enchufable, sin ir a través de manera herencia.
3: enchufable mesa clases caché predefinido puede reducirse serializado longitud matriz de bytes de la secuencia diana para mejorar el rendimiento de tipo convencional.
4: no hay necesidad de implementar interfaces jaa.io.Serializable, se puede lograr la serialización de Java
5: para mejorar el rendimiento de la secuencia diana mediante la caché.
Google Protobug Codec características:
Cruz-idioma, soporte multi-idioma, el mensaje codificado es más pequeño, más propicio para el almacenamiento y la transmisión, los códecs de alto rendimiento, soporte diferente versión del protocolo antes de compatibilidad con versiones anteriores, el apoyo y definir Campo obligatorio opcional.
