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

TCP optimizes kernel parameters of Linux system [root@www] # cat / etc/redhat-release;uname-rCentOS Linux release 7.5.1804 (Core) 3.10.0-the next layer of 862.11.6.el7.x86_64TLS is the TCP protocol, so the optimization of TCP can directly affect the performance and efficiency of TLS. In the optimization of TCP, the following concepts are mainly involved: (1) congestion control (congestion control) mechanism: at the beginning of a TCP connection, I do not know how fast the other party is. If there is enough bandwidth, the server can transmit data as fast as possible, but if the other side's network is slow and the server sends too much data, it will press across the connection and cause the connection to be interrupted. Therefore, every TCP connection has a speed limit called the congestion window (cwnd = congestion window). This window is initially small, and during communication, if both sides can accept this speed, it will increase the value of the congestion window (initial growth is very fast, double growth), this mechanism is called slow start (slow start). Congestion control mechanism has a great impact on TLS connections. TLS handshake consumes valuable initial connection bytes (when the congestion window is small). If the congestion window is large enough, there will be no additional delay in slow start. However, if the length of the handshake message exceeds the size of the congestion window, the sender will have to split the long message into two pieces, send one piece first, wait for confirmation (1 round trip), increase the congestion window, and then send the rest. This increases the delay caused by the TLS handshake. (2) slow start threshold ssthresh (to prevent the cwnd from growing too fast and the network cannot afford it, resulting in packet loss) if cwnd is less than ssthresh, cwnd doubles in the slow start phase; if cwnd is greater than ssthresh, then in the congestion avoidance phase, cwnd no longer doubles its growth as in the slow start phase, but grows linearly to avoid network congestion as much as possible. (3) the receiving window (rwnd) is used to indicate the maximum amount of data that can be saved. In practice, the reasonable value of the receiving window rwnd depends on the size of the BDP, that is, the product of bandwidth and delay. If the bandwidth is 80Mbps and the delay is 100ms, the calculation process is as follows: BDP = 80Mbps 100ms = (80 / 8) (100 / 1000) = 1MB = 1024KB = 1048576BTCP records the window size with 16 bits, that is, the maximum value is 64KB. If this value is exceeded, the tcp_window_scaling mechanism is required (enabled by default). By configuring the size of the receive buffer in the kernel parameters, you can control the size of the receive window: net.ipv4.tcp_rmem = Linux itself has a buffer size automatic tuning mechanism, and the actual size of the window will automatically change between the minimum and maximum values to find a balance between performance and resources. Confirm the automatic buffer size tuning mechanism (0: off, 1: on): sysctl-a | grep tcp_moderate_rcvbuf. If the buffer size auto-tuning mechanism is set to off, then the buffer DEFAULT value is set to BDP;. If the buffer size auto-tuning mechanism is set to on, then the buffer MAX is set to BDP. (4) the extra cost of storing some information of the TCP connection itself: the value of net.ipv4.tcp_adv_win_scale may be 1 or 2. If it is 1, it means that 1/2 of the buffer is used for extra overhead. If it is 2, then 1/4 of the buffer is used for extra overhead. According to this logic, the final reasonable value of buffering is calculated as follows: result=BDP / (1-1 / 2 ^ TCP _ adv_win_scale). (5) Idle connection returns to slow start: slow start works on connections without any traffic for a period of time, achieving the effect of reducing speed, and the speed drops very fast. The so-called "period of time" can be very small, such as 1 second, but in real situations, each long connection (such as using a HTTP long connection) may be set to very slow! It is recommended to disable this feature in order to maintain speed. On Linux, you can disable slow startup when the connection is idle: 0 means no, 1 means slow startup is enabled. By default, 1 can temporarily take effect with the following command, but it will fail after restart. See: sysctl-a | gerp slow_start_after_idle temporary: sysctl-w net.ipv4.tcp_slow_start_after_idle=0 is permanently effective: add net.ipv4.tcp_slow_start_after_idle=0 settings to the / etc/sysctl.conf configuration file. Tuning the initial value of congestion window (cwnd): the startup speed limit is called initial congestion window (initial congestion window, initcwnd). RFC6928,google, released in April 2013, recommended that the initial congestion window be set to 10 MSS (about 15 KB) by default. [Centos 7 defaults to 10MSS] the early recommendation was to use 2 or 4 MSS (about 3-6KB). MSS is a concept on the TCP layer with a size of 1460 bytes. There are MTU,1500 bytes on the IP layer. [root@www ~] # sysctl-a | grep ssthreshnet.ipv4.tcp_max_ssthresh = 0 # in the virtual machine [root@www ~] # sysctl-a | grep tcp_window_scalingnet.ipv4.tcp_window_scaling = 1 [root@www ~] # cat / proc/sys/net/ipv4/tcp_rmem # rwnd value 4096 87380 6291456 [root@www ~] # sysctl-a | grep tcp_moderate_rcvbuf net.ipv4.tcp_moderate_rcvbuf = 1 [root@www ~ ] # sysctl-a | grep adv_win_scalenet.ipv4.tcp_adv_win_scale = 1 [root@www ~] # sysctl-a | grep start_after_idlenet.ipv4.tcp_slow_start_after_idle = setting cwnd [root@www ~] # ip routedefault via 172.16.216.2 dev ens33 169.254.0.0 dev ens33 scope link metric 1002 172.16.216.0 dev ens33 scope link metric 24 dev ens33 proto kernel scope link src 172.16.216.188 [root@www ~] # ip route | while read p Do ip route change $p initcwnd 10 Done [root@www ~] # ip routedefault via 172.16.216.2 dev ens33 initcwnd 10 169.254.0.0 initcwnd 16 dev ens33 scope link metric 1002 initcwnd 10 172.16.216.0 initcwnd 24 dev ens33 proto kernel scope link src 172.16.216.188 Universe initcwnd 10: initializing cwnd# unilaterally raising the size of the sender cwnd is not necessarily effective because the actual size of unacknowledged data transmitted in the network depends on the minimum values in rwnd and cwnd Therefore, once the rwnd of the receiver is relatively small, it will inhibit the play of cwnd. # set initrwnd (linux kernel 2.6.33 and newer) [root@www ~] # ip routedefault via 172.16.216.2 dev ens33 169.254.0.0 dev ens33 scope link metric 1002 172.16.216.0 dev ens33 proto kernel scope link src 24 dev ens33 proto kernel scope link src 172.16.216.188 [root@www ~] # ip route | while read p; do ip route change $p initrwnd 10 Done [root@www ~] # ip routedefault via 172.16.216.2 dev ens33 initrwnd 10 169.254.0.0 16 dev ens33 scope link metric 1002 initrwnd 10 172.16.216.0 initrwnd 24 dev ens33 proto kernel scope link src 172.16.216.188 initrwnd 10 # some systems rwnd values: # Linux 2.6.32 3*MSS (usually 4380) # Linux 3.0.0 10*MSS (usually 14600) # Windows NT 6.1 (Windows 7 or Server 2008 R2) 8192 ^ 2 optimized tcp time_wait Reduce connections in the time_wait state. The party that shuts down actively will have a time_wait status. A connection in time_wait status has to wait for 2 MSL before it will close, which will take up resources and try to avoid the connection from entering time_wait state. In linux, MSL is usually 30 seconds, and 2 MSL is 1 minute. This number is hard-coded in the kernel and cannot be modified unless the kernel is recompiled. Note: the longest message life cycle of MSL: Maximum Segment Lifetime,MSL. Modify the value of fin_wait2 to reduce the waiting time of fin_wait2, and the connection will be reclaimed after the timeout. Open persistent connection: when browsers open a persistent connection and receive the fin disconnected from the server, they will restore an ack; instead of sending their own fin, so that one side of the server will reclaim the connection after waiting for fin_timeout time. If the persistent connection is not enabled, after the server closes the link, the status of the link will change from fin_wait2 to time_wait. You can also consider urging the client to close the link and configure keepalive_timeout 20s 10s; (nginx configuration) so that the timeout of the client is less than that of the server, and the browser will close the link first, so that the time_wait status will be on the client side. However, experiments show that only Firefox browser supports it, and Fox Fire browser will recognize the parameter Keep-Alive: timeout=time, while other browsers will not. Do not set one of the following two conditions: 1) the initial sequence number is larger than the last sequence number of the old connection in recycle=1 mode and reuse reuse=1,NAT mode, which will cause connection failure (SYN packet will not be responded to) time_wait state (reuse). 2) if a timestamp is used, the timestamp of the new connection is larger than that of the old connection. For tcp_tw_reuse and tcp_tw_recycle to take effect, tcp_timestamps must be enabled and enabled by default. The parameter optimizes the length of the queue net.ipv4.tcp_max_syn_backlog = 1024 # SYN. The default is 1024. Increase the queue to 8192 or larger to cache more waiting network connections. Net.ipv4.tcp_max_tw_buckets = 180000 # the maximum number of sockets that hold the TIME_WAIT state, and as soon as this number is exceeded, the TIME_WAIT socket is cleared and a warning is issued. Net.ipv4.ip_local_port_range = 1024 65535 # Port range for outbound connections. Default: 32768 to 61000, which can be expanded by 1024 to 65535. Net.ipv4.tcp_syncookies = 1 # when you enable SYN Cookies,SYN to wait for queue overflow, use cookies to handle it to prevent a small amount of SYN***. Net.ipv4.tcp_retries2 = 15 # the number of failed retransmissions of TCP. Default is 15, which can be reduced, for example, 5. You can also configure the memory used for TCP/IP links. If you configure the total memory, the unit is "page". The specific size of a page can be obtained through the getconf PAGE_SIZE command; the memory units used for reading and writing are bytes. [root@www ~] # getconf PAGE_SIZE4096 Total memory net.ipv4.tcp_mem = 93408 124544 186816 write (buffer) net.ipv4.tcp_wmem = 4096 16384 3985408 read (cache) net.ipv4.tcp_rmem = 4096 87380 3985408 [root@www ~] # cd / proc/sys/net/ipv4 [root@www ipv4] # cat tcp_fin_timeout 60 [root@www ~] # sysctl-a | grep timestampsnet.ipv4.tcp_timestamps = 1initcwndip-sysctl

TLS protocol optimization to TLS protocol security and speed tuning 1. The biggest cost of using TLS for key exchange, in addition to latency (two more round trips), is the CPU-intensive operation for security parameter negotiation, that is, key exchange (key exchange). The CPU consumption of key exchange largely depends on the private key algorithm, key length and key exchange algorithm selected by the server. The difficulty of cracking the key depends on the length of the key, and the longer the key is, the more secure it is. However, the computing resources consumed by encryption and decryption should also be considered. There are currently two private key algorithms available: RSA and ECDSA. There are still a large number of keys in the RSA algorithm, even though forward encryption is not supported when using it for key exchange. However, RSA can still be used for authentication. The current RSA key algorithm recommends a minimum length of 2048 bits, and consider upgrading to 3072 bits (although the efficiency decreases much after the upgrade), it begins to become slower and slower with the growth of RSA keys. ECDSA is much faster, and more and more sites support ECDSA. Medium-length 256bit ECDSA provides the same security as 3072-bit RSA, but has better performance. Recommended priority: ECDSA256_ECDHE256 and RSA2048_ECDHE256.

two。 When certificate chain an and TLS shake hands, the server will send the certificate chain to the client for verification. B. The certificate chain is as short as possible. C. The certificate chain should be complete. D. Try to use elliptic curve certificate chain. Certificate revocation check and OCSP Service although the certificate revocation status is constantly changing, and the client (browser) is very different about how to check the certificate revocation, as a server, it is necessary to transmit revocation information as soon as possible. Use a certificate with OCSP information. OCSP is designed to provide real-time queries that allow clients to access revocation information. So the query is short and fast (1 HTTP request). By contrast, CRL is a list of a large number of revoked certificates. Some clients download CRL only when the OCSP information is not available. When downloading CRL, the communication between the browser and the server will be suspended until the CRL download is complete, which may take dozens of seconds. CA with fast and reliable OCSP response program has different OCSP response speed between different CA. Slow and incorrect OCSP responders can potentially cause performance degradation. After deciding to use the OCSP response, examine the performance and correctness of the CA response to the OCSP. Another criterion for choosing CA is to look at the speed of updating the OCSP response. It is best to add your own certificate to the OCSP response program as soon as it is issued. Once the security risk is revoked, the OCSP response can also be updated quickly. [root@www ~] # openssl s_client-connect www.openssl.org:443-status | grep-I ocspdepth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3verify error:num=20:unable to get local issuer certificateOCSP response: OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response

3. Session recovery TLS understands two types of handshakes: full handshakes and short handshakes. In theory, a full handshake occurs only once when the client establishes a TLS session (TLS session) with the server. For subsequent connections, the parties resume the previously negotiated session using a short handshake. A short handshake is faster and takes less round-trip time because it does not require operations such as key exchange and key generation. Additional overhead in network transmission caused by 4.TLS 's recording protocol the minimum transmission unit of the TLS protocol is an TLS record, which can contain up to 2 ^ 14 = 16384 bytes (16K) of data. A record has little overhead without encryption; each record begins with 5 bytes of metadata, namely content type (1 byte), protocol version (2 bytes), and data length (2 bytes). Additional overhead of TLS records after stream encryption, block encryption, and authenticated cipher suite encryption.

Try to avoid sending packet data. Try to buffer application layer data to avoid additional network overhead. 5. Symmetric encryption consumes CPU resources and has obvious CPU cost, which is determined by encryption algorithm, encryption mode and integrity checking algorithm. 6. The cache latency TLS record of TLS records is the smallest unit of data sent and received by TLS. The size of the TLS record does not match the size of the next layer of TCP packets. A full-size TLS record of 16 KB needs to be split into many small TCP packets (about 12), usually less than 1.5 KB (1.3KB) each. After the whole TLS record is divided into small TCP packets, each packet will arrive one after another, but it cannot be decrypted until all of them have arrived. This is because TLS records are also the smallest unit of data decryption and integrity checking. Cache latency can sometimes be large. Although lost and delayed packets can be recovered through the TCP protocol, a round trip is still required. Each extra round trip means a delay for the entire TLS record. Another delay that triggers an extra round trip in the initial congestion window is that a large amount of data is sent at the beginning of the connection, causing the initial congestion window to overflow. Once the congestion window is full, the sender must wait for a response (1 round trip) and wait until the congestion window increases before sending more data. If the Web server supports TLS record adjustment, you should consider changing the default value (a value as large as 16 KB) to a more reasonable value, which is determined by the deployed cipher suite and the corresponding transmission overhead, which is generally set to 4 KB. If the TLS record size is set to match the TCP/IP packet exactly, it is set to about 1400 bytes, and then gradually adjusted by watching the packet. Theoretically, the maximum size of IP message is 65535 bytes, which is very large, but because the effect of IP slicing is not good, TCP knows each other's MSS (MTU minus IP header) in the three-way handshake and does not give large chunks of data to the IP layer to avoid IP Datagram fragmentation. For example, if the maximum transmission unit (maximum transfer unit,MTU) of the data link layer is 1500 bytes, it can be foreseen that 1500 bytes MTU removes the extra overhead and the transmitted data is 1379-1419 bytes. -20 bytes IPv4 herder |-40 bytes IPv6 header- 32 bytes TCP header TCP header the minimum is 20 bytes, the maximum is 40 bytes, and the maximum is 60 bytes-29 bytes TLS record |-49 bytes TLS recordMSS is 1460 bytes: 1460-32-29 | 49 = 1379-1399 bytes. First of all, the value of MTU varies. Although most clients inherit the Ethernet 1500-byte limit, there are protocols that support larger data. For example, jumbo frames (jumbo frame) allow up to 9000 bytes. In addition, the calculation using IPv4 and IPv6 (20 bytes for IPv6 head and 40 bytes for IPv6 head) will be slightly different, and changes in the cipher suite will also affect this value. Another problem is that reducing the size of TLS records increases transmission overhead, that is, throughput decreases. If the TLS record length is increased (up to 16K), then because it is encrypted data, all the data (all IP packets) will be decrypted smoothly, the waiting time will be longer, the throughput will be increased, and the real-time response will be reduced. There is also an option on nginx to configure this value, but it cannot be adjusted dynamically.

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.