Netty in Action (21) The first part of the 11th chapter Netty provides some native handler and codecs

The contents of this chapter include ( 2 translations ):

1) using SSL/TLS to build secure Netty applications

2) Construction of HTTP/HTTPS application

3) Handling Idle connections and timeouts

4) Decoding of space-space segmentation protocol and length-splitting protocol

5) Write Big Data

Netty provides a number of decoders and processor classes for a wide variety of protocols, which you can use to make it easy for you to spend unnecessary time and effort on some of the more troublesome events that we will introduce to you in this chapter, and analyze their role, These tools include: tools that support SSL/TLS and WebSocket, and data compression capabilities that are more performant than HTTP's natural data compaction, and so on

11.1 Securing Netty applications with SSL/TLS

Data privacy is a more important issue today, so as a developer we should be ready to deal with this problem, first of all we must be familiar with some of the more common cryptographic protocols, such as SSL or TLS protocol, these two protocols are in the most important location of data confidentiality protocol, When we go to some of the more secure sites, we are exposed to these protocols, which can also be used in applications that are not based on HTTP protocols, such as SMTPS mail services or even related database systems.

To support SSL and TLS, Java provides the JAVAX.NET.SSL toolkit, the package of Sslcontext and Sslengine can be simple and straightforward to implement encryption and decryption, Netty Use the Java implementation of the API to implement the Channelhandler interface named Sslhandler class, this class Actually, it's internal use of sslengine to do something real.

Openssl/sslengine realization of Tips:netty

Netty also provides a sslengine that is implemented using the OpenSSL tool class, which is called Opensslengine, which is an analogy with the sslengine of the original JDK for better performance

When OpenSSL jar package libraries is provided, the Netty client and server are used by default opensslengine, and if not provided, will be provided in the JDK with more information about OpenSSL to view Netty's documentation

Notice that whether you're using the JDK or the Netty opensslengine is actually the same for data transfer

The code listing shows how a Sslhandler is added to the channelpipeline by a channelinitializer, recalling that Once the channel is registered Channelinitializer will be set to Channelpipeline

In many cases, Sslhandler is often used as the first channelhandler in Channelpipeline, which ensures that cryptographic actions occur after all business logic operations

Sslhandler has some useful methods, as shown in table 11.1, specifically, in the handshake phase, two terminals mutual authentication and an encryption method, you can configure the Sslhandler to edit its behavior or when the SSL/TLS handshake is completed to provide notification, etc. All data is encrypted and the SSL/TLS handshake will be executed automatically.

11.2 Building Netty Http/https applications

Http/https is one of our most common protocols, with the mobile phone side of the day and night, for any company, a support mobile Web page has become an essential requirement, these protocols are also used in other aspects, WebService APIs are exposed by many organizations to communicate with their enterprise partners based on the HTTP protocol

Next, we'll see some of the relevant aspects of Netty's channehandler, with these tools you don't need to write a custom decoder to use the HTTP and HTTPS protocols

11.2.1 HTTP decoder, encoder, and codec

HTTP is based on the request-response pattern, the client sends an HTTP request to the server side, the server-side feedback an HTTP response, Netty provides a series of encoding and decoding classes to simplify the use of the Protocol, figures 11.2 and 11.3 show the complete HTTP request body and the response body

As shown in 11.2 and 11.3, an HTTP request or response consists of multiple data components that are terminated with a lasthttpcontent section, and Fullhttprequest and fullhttpresponse information are specific derivative classes representing a complete request and Response, all implementations of the Httpobject interface for the HTTP information type of the model class request or lasthttpcontent are shown in the following list of Figure 11.2 and table 11.2:

Table 11.2 gives an overview of some common classes of HTTP decoding and encoding

The Httppipelineinitializer in the following code listing shows an example of how Netty support for HTTP can be applied to your app, As a user you almost just need to drop the right channelhandler into the channelpipeline.

11.2.2 HTTP Message Aggregation

When all of the initialization work has been installed into Channelpipeline, you can manipulate different types of Httpobject objects, but we have said before that an HTTP request or response is made up of multiple parts, So you need to aggregate this information together to make a complete message, in order to eliminate this frustrating work, Netty provides an aggregation tool to combine multiple information bodies into one fullhttprequest or fullhttpresponse information body, In this way, you can always see the full message content.

This aggregation operation has a certain performance penalty because the arrival information end needs to wait in the buffer until it is assembled into a complete message to the next Channelinboundhandler, the tradeoff is that you don't have to worry about breaking information.

Introducing this automated aggregation requires only one thing: adding a channelhandler to the pipeline is all right, and the following code listing shows how to do it:

11.2.3 HTTP Compression

When using the HTTP protocol, we recommend the use of compression technology to minimize the size of the transmission message body, although compression will cost some CPU performance, but in a word, the compression is a good idea, especially when the text transmission

Netty provides channelhandler to support compression and decompression, and supports two encoding formats for gzip and deflate

The following code listing shows this example:

TIPS: Compressed jar-pack dependencies

If you use JDK1.6 or earlier versions, you may need to add Jzlib package dependencies to your classpatch down to support compression, if using MAVEN, use the following dependencies

11.2.4 Using HTTPS

The following code listing shows that if you want to support HTTPS, you only need to add a sslhandler to the mixed handler.

This code is a good demonstration of Netty's architectural philosophy: reusable components, just as you need to add a channelhandler to Channelpipeline to provide a high-performance and encrypted application

11.2.5 WebSocket

Netty provides a number of toolkits for HTTP protocol-based applications that can support a lot of cash features, and in this section we will explore WebSocket, a young protocol proposed by the IETF in 2011

WebSocket dealt with the "century" difficult problem, if based on the underlying protocol HTTP to real-time push information, HTTP to do a typical request-response interaction Protocol native is not support this scenario, although Ajax technology to make some amends, but the data flow driver still relies on the client, There are other solutions, but so far these solutions have been working for customers in a single constraint

The WebSocket specification and its specific implementation represent a more advanced attempt in this field, in short, WebSocket provides a separate TCP connection for bidirectional data transfer, with WebSocket APIs, and now has a new approach to data bidirectional transmission, There is no need to poll the server side like a previous client to get bidirectional data transfer functionality.

WebSocket provides the server side and the client a real data bidirectional interaction technology, this section, we do not go deep into the websocket technology to explore the implementation of more details, but we must realize that some of the early two-way communication is limited by the text data transmission, Now this limitation will no longer exist, WebSocket can be used for any data, and looks more like a normal protocol.

Figure 11.4 shows the WebSocket design concept, in which the communication will be based on a common HTTP protocol and can be upgraded to function with two-way data transfer

In order to add the functionality of WebSocket to our application, we need to add the appropriate client or server-side Channelhandler to the pipeline, a class that is specifically designed to handle some special types of information websocket definitions, Frames, as shown in Table 11.3, WebSocket can be classified as data or control frames.

Because Netty is in principle a server-side technology, we prefer to create a websocket server, Listing 11.6 shows us how to build a simple example using Websocketserverprotocolhandler, which handles the protocol, upgrades the handling of the handshake phase, uses three control frames, Close,ping,pong, text, and byte data frames through this handle R will be transferred to the next handler as the pipeline

TIPS: a safe websocket

To increase the security of the websocket, we only need to add Sslhandler as the first Channelhandler to the pipeline.

For more examples of websocket, please refer to the 12th chapter for more details on the design of a real-time websocket application.

11.3 Idle Connections and timeouts

So far, we've explained that Netty provides support for Http,https,websocket by giving several specific code and processing classes that can make your application more efficient, secure, more efficient, and manage your application resources more effectively, so Let's talk about a more central concept-------connection management

Detecting vacant connections and timeouts is critical to the timely release of resources, and for this important and common task, Netty provides several specific Channelhandler implementations to achieve this functionality, and table 11.4 gives an overview of this class:

We explain in detail the Idlestatehandler, which is the most frequently used class in the actual project, Listing 11.7 shows a case of receiving a notification when there is no data received or sent within 60 seconds, using a more popular solution to send a heartbeat packet to the remote end, and if not, then close the connection

This example shows how to hire a idlestatehandler to test if the remote side is still alive, and if the remote does not survive, you can release resources by shutting down the resources. Idlestatehandler with Idlestateevent to invoke the Usereventtriggered method if the connection does not receive or send data within 60 seconds, The Heartbeathandler method specifically implements the Usereventtriggered method, which detects idlestateevent, which sends a heartbeat message, And added a channelfuturelistener when sending a heartbeat packet fails to close the connection

Netty in Action (21) The first part of the 11th chapter Netty provides some native handler and codecs