HTTP/2 Support
The HTTP protocol is one of the most frequently used protocols in the Internet. However, HTTP/1.0 and HTTP/1.1 do have some disadvantages for modern applications, in particular with respect to performance in wide-area networks. To improve these problems, their successor RFC 7540 HTTP/2 has been implemented.
HTTP/2 is not a fundamental restructure of the HTTP protocol, but it optimizes the transport of existing HTTP semantic. All basic features of HTTP/1.1 remain the same; only the transport across the network has been changed.
As of kernel version 749, SAP Web Dispatcher and Internet Communication Manager support the HTTP/2 protocol as the protocol converter. Both components can receive HTTP/2 and convert to HTTP/1.1. The back end continues to use HTTP/1. With SAP Web Dispatcher, HTTP/1.1 requests are sent to the back-end server, whereas with ICM HTTP/1.1 requests are sent to the work process.
HTTP/2 support in ICM is restricted to AS ABAP instances. For AS Java and dual stack systems there is no HTTP/2 support in ICM, but a Web Dispatcher with HTTP/2 support can be used in front of an AS Java or dual stack system.
HTTP/2 support can be activated or deactivated with parameter icm/HTTP/support_http2. As soon as icm/HTTP/support_http2= true is set, HTTP/2 is supported on all open HTTPS ports. (HTTP/2 is supported only with SSL. HTTP ports do not offer HTTP/2) The applies only for clients (browsers) that also support HTTP/2. If a client itself does not support HTTP/2, HTTP/1 continues to be used on this port.
If SSL Cipher Suites have been especially configured in the system, further configurations are required: HTTP/2 has further requirements of SSL / TLS. For example, only a defined number of Cipher Suites are permitted. If parameter ssl/ciphersuites is set, "PFS" is added to the list of configured Cipher Suites so that HTTP/2 can be supported.
Existing configuration: ssl/ciphersuites = 135:HIGH:!aNULL
Configuration required for HTTP/2: ssl/ciphersuites = 135:PFS:HIGH:!aNULL
For details, see 2181733 
.
For Linux, we recommend you leave the default value as 0 for parameter is/socket_buffer_size.
For other platforms, the parameter should be set to a value that allows the available bandwidth to be fully used.
For details, see 2304840 .
HTTP/2 was developed with the aim of improving response times of Web-based applications. To what extent response times are improved (or an improvement is visible) depends on the application and characteristics of the network connection. In local networks (with a high bandwidth and a low round trip time (RTT)) there is hardly a visible difference between HTTP/1.1 and HTTP/2. Improvements on HTTP/1.1 can usually be seen in networks with higher bandwidth and higher RTT. In extreme cases, for example, with a lower bandwidth and a lower RTT, HTTP/2 can even lead to longer response times. On some platforms the socket buffer settings must be optimal so that the full benefits of HTTP/2 can be seen. (See previous section).
An important feature of HTTP/2 is the significant increase in the maximum number of parallel requests. It can therefore be expected that multiple work processes can execute HTTP requests of one user.
The total number of requests to be processed remains the same. However, it may result in a change to the load peaks. If may therefore be necessary to increase icm/max_conn.
icm/H2/max_concurrent_streams
With this parameter the maximum number of parallel requests for each physical HTTP/2 connection can be configured. If this parameter is set too small, the benefits of HTTP/2 are less.
icm/H2/idle_timeout
Number of seconds after which unused HTTP/2 connections are closed.
icm/H2/ping_interval
Number of seconds after which a ping is expected. Pings are used to test whether connections are still working.
For more details, see system documentation for transaction RZ11