Shulou(Shulou.com)06/01 Report--

Netty how to solve the TCP sticky package problem, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

0. cause

Because when you build a RPC frame wheel, you need to solve the sticky package problem of TCP. I hereby record it, hoping to facilitate others. This is the GitHub address https://github.com/yangzhenkun/krpc of the RPC framework I wrote.

Welcome to star,fork. Several articles have been written to explain the principle of this framework. Welcome to communicate with those who are interested in the principle.

1. What is a sticky package? what is a TCP sticky package?

TCP sticky packet is in the process of TCP data transmission, for some reason, the data received by the receiver is not one-time data that can be saved, but the byte stream of multiple data packets are assembled together, resulting in multiple data sticking together. When reading, the receiver does not know how to divide the data into expected groups of data, this is sticky packet.

1.2 causes of formation

The sticky packet phenomenon of TCP is caused by the buffer and TCP data flow of its sender and receiver.

For example, the nagle algorithm will assemble many instantaneous small packets of data into a large data to improve the utilization of bandwidth. The specific nagle algorithm will not be expanded.

But even if the nagle algorithm is turned off, sticky packets still exist. Because this is not the root cause of tcp sticky package. Because of the existence of the buffer, it will not be sent until the cache area is full. At the same time, the receiver also uses the cache area to receive data and then reads the received data parsing from the cache area. At this time, someone asked, what if the amount of data is very small and the buffer is not always full? it depends on the timer of the sender and receiver, who will process the data regularly, otherwise it will become a bug.

It is because of the existence of buffer and the form of tcp data flow that multiple groups of data are spliced, resulting in the problem of sticky packet and semi-packet.

1.3 how to solve the problem

At present, the commonly used method is to define the starting edge character + data length to tell the receiver the specific length of a packet.

However, there are also defined fixed lengths, but this may result in a waste of white space bytes and a way that is not easy to expand beyond the length. The way of pure boundary character is afraid of the collision between the actual message body and the boundary character, resulting in the wrong truncation of the message.

How to solve the problem of 2.netty

Netty's encapsulation of TCP communications in NIO mode is perfect. It allows people to quickly write out the available tcp communication servers and clients, and easily solve the sticky packet problem.

Netty provides codecs based on delimiters and length for developers to use.

DelimiterBaseFrameDecoder can be separated by user-defined data delimiters, and LineBaseFrameDecoder is split by line endings (\ n or\ r\ n), which is faster than the former.

There are length-based FixedLengthFrameDecoder fixed-length decoders and LengthFieldBasedFrameDecoder dynamic-length decoders. All of these four methods have corresponding codecs.

At the same time, for the boundaries of data types, netty also supports byte,string,protobuf and so on. You can look at the subclasses of MessageToMessageDecoder and you will find that netty provides a lot of coding and decoding rules.

3. Practice-client and server implementation of RPC framework

When I was writing KRPC, I didn't advance my NIO plan so early, but I used synchronous IO to write the client in the first edition. I found it so unbearable during the stress test, so I decided to rewrite it with NIO. At first, I thought it was inconvenient to write the client with Netty (I didn't know how to write it at that time). I decided to write the client with java's native NIO. In the end, I found it particularly difficult to deal with sticky packets, so I needed to define a special demarcation symbol by myself, and then set the length. Parsing on the client side and server side is particularly complicated. So I tried to write in netty and found it very simple.

Bootstrap.group (bossGroup, workerGroup) .channel (NioServerSocketChannel.class)

.childHandler (new ChannelInitializer () {

@ Override

Protected void initChannel (SocketChannel ch) throws Exception {

ChannelPipeline pipeline = ch.pipeline ()

Pipeline.addLast ("frameDecoder", new LengthFieldBasedFrameDecoder (Integer.MAX_VALUE, 0,4,0,4))

Pipeline.addLast ("frameEncoder", new LengthFieldPrepender (4))

Pipeline.addLast ("decoder", new ByteArrayDecoder ())

Pipeline.addLast ("encoder", new ByteArrayEncoder ())

Pipeline.addLast (new ServerHandler ())

}

}) .option (ChannelOption.SO_BACKLOG, 128)

.childOption (ChannelOption.SO_KEEPALIVE, true)

.childOption (ChannelOption.RCVBUF_ALLOCATOR, new AdaptiveRecvByteBufAllocator (64 Globe. GetInstance (). GetMaxBuf (), Global.getInstance (). GetMaxBuf ())

This is the server code, there is no particularly simple, because TCP will serialize the transmitted data from the compressed data into a byte array, so the use of its own ByteArray codec, the use of dynamic length of LengthFieldBaseFrame to solve the sticky packet problem. In this way, the sticky bag problem is solved.

This is the answer to the question about how netty solves the TCP sticky package problem. I hope the above content can be of some help to everyone. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.