Introduction

In a previous post,* we gave an overview of how we came to adopt the networking protocol “SPDY” for use with the messaging service offered on LINE. This time we would like to go into detail about the various features that SPDY has to offer.

*Adopting SPDY in Line – Part 1: An Overview, http://tech.naver.jp/blog/?p=2381 

Discussion

Security

In the previous post, we mentioned that under some circumstances, LINE allowed connections that were unencrypted without using TLS. For mobile networks with slow connection times and transfers, a problem occurs at the beginning steps* of relatively large data transfers when using TLS connections. Connection times are slow and sometimes connections are even lost altogether. We wanted to provide a more comfortable user experience by allowing unencrypted connections in order to protect the user from this problem. However, we started receiving a lot more inquiries that dealt with security concerns.

*http://tools.ietf.org/html/rfc5246#section-7

In order to solve the security issue and continue to offer the best user experience possible at the same time, LINE takes advantage of prepackaged certificates used for encryption. Prepackaged certificates are safely packaged inside the LINE app with the assurance of the App Store system.  They are ready to be used as soon as installation of the client is complete.  By removing the step where certificates are downloaded over the network, we no longer have to worry about faked certificates. However, we still check the certificates sent by the client.  When combined with the fact that we are also using the already verified TLS encryption, we are able to provide a safe and secure system.  We put in a lot of work to reduce the amount of time it takes to make the initial connection, but we also put in a lot of work to reduce the time it takes for the encryption process to work its magic. All kinds of data are sent back and forth between the client and the server, but not all require security measures. We realized we did not have to encrypt all the data being sent. We only had to encrypt the parts of the data that needed it.

Establishing Priority for Requests and Sent Messages

LINE does not only offer its users the ability to send and receive messages. It also offers a complex set of features that include a personal timeline. Even so, message transmission is the core feature at the heart of the app. This means that sending and receiving messages takes top priority. SPDY allows multiple requests to be sent at the same time and assigns each request a priority level.*

LINE gives requests related to sending messages the highest priority level there is.

*http://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-2.3.3

As shown in the graph above, when the client sends multiple requests simultaneously, they arrive at the server at roughly the same time, where each request receives a priority level. The server saves them in a queue, and processes and responds to the requests with the highest priority level first. This feature lets our servers process sent messages first, allowing us to provide the user with prompt messaging functionality even when the server or client is experiencing heavy traffic.

Ping and Connection Warm-Up

3G mobiles networks normally operate at slow speeds with few transmissions or are even idle altogether in order to reduce the strain on the mobile device’s battery. When transmission volume increases, it may take anywhere from several seconds to several tens of seconds to switch to the mode that supports high speed transfers.* If the connection changes modes when the user sends a message, we are forced to wait until we receive the server response before we can do anything else.

*http://en.wikipedia.org/wiki/Radio_Resource_Control

In order to ensure this situation does not happen, LINE pings the server by sending it a small SPDY ping* before sending the user’s message. This means messages are sent even faster, because after the first transmission is received, all subsequent messages are processed at a relatively higher rate. This process is affectionately called “Connection Warm-Up”.

http://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-2.6.5

When the client sends the SPDY ping to the server, the same ping is sent back to the client in the response. However, there is no need for the client to receive a response with Connection Warm-Up. Here at LINE, we expanded the protocol and added a NOOP Frame that does not require a server response.

Header Compression and the Header Cache

SPDY reduces network traffic by compressing frequently used headers.* When the client makes a request to the server, the header is compressed when the response is made to the client. LEGY, our server used to process client connections, uses a lot of memory in order to decompress the client request header and compress the response header. In order to accommodate a large number of client connections, LEGY needs to reduce the memory required for each connection. Because the amount of memory used varies depending on the compression rate, we reduced compressibility to use as little memory as possible in the process. Decompression does not use that much memory, so there are no special controls in place for when the client request header is processed.

*http://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-2.6.10.1

LINE is used on a wide variety of devices. There is a limit in the amount of memory available when SPDY is applied to a large number of different devices, so we were unable to use header compression with some clients. In order to allow these clients to be able to use SPDY even without header compression, we expanded the SPDY protocol, modifying the server and client portion. However, this introduced another problem with the header size. We used the Header Cache, a cache of headers sent by the client and saved by LEGY, to resolve this issue.

 

• When the client sends all the headers necessary for the request in the first connection, LEGY saves the headers in its memory and processes them. (Steps 1 through 4 in the figure above.)
• When sending the second request, the client omits the headers sent in the first request.  (Step 6 in the figure above.)
• When LEGY receives the second request, it adds the saved headers and sends the response. (Steps 7 through 8 in the figure above.)

This process allows the client to avoid sending redundant headers, thereby reducing the header size without using compression.

Conclusion

We improved the functionality provided by SPDY in order to offer the user a faster way to send and receive messages. Next we plan to use Server Push* transactions to provide an even better user experience.

*http://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-3.3