[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[],[],null,["# About in-transit encryption\n\nThis page gives an overview of in-transit encryption for Memorystore for Redis Cluster.\n\nFor instructions how to encrypt a connection with in-transit encryption, see [Manage in-transit encryption](/memorystore/docs/cluster/manage-in-transit-encryption).\n\nMemorystore for Redis Cluster only supports TLS protocol versions 1.2 or higher.\n\nIntroduction\n------------\n\nMemorystore for Redis Cluster supports encrypting all Redis traffic using the [Transport Layer Security (TLS)](https://en.wikipedia.org/wiki/Transport_Layer_Security) protocol. When\nin-transit encryption is enabled Redis clients communicate exclusively across a\nsecure connection. Redis clients that are not configured for TLS are\nblocked. If you choose to enable in-transit encryption you are responsible for\nensuring that your Redis client is capable of using the TLS protocol.\n| **Note:** For instances with replicas, replicated data is fully encrypted at the network level based on Google Cloud encryption standards.\n\nIn-transit encryption prerequisites\n-----------------------------------\n\nIn order to use in-transit encryption with Memorystore for Redis, you need:\n\n1. A Redis client that supports TLS or a third-party TLS sidecar\n\n2. [Certificate Authorities](/memorystore/docs/cluster/about-in-transit-encryption#certificate_authorities)\n installed on the client machine accessing your Redis instance\n\nNative TLS was not supported prior to open source Redis version 6.0. As a\nresult, not every Redis client library supports TLS. If you are using a client\nthat does not support TLS, we recommend using the [Stunnel](https://www.stunnel.org/)\nthird-party plugin that enables TLS for your client. See [Securely connecting to a Redis instance using Stunnel and telnet](/memorystore/docs/cluster/connect-cluster-instance#securely_connect_to_a_memorystore_cluster_using_stunnel_and_telnet)\nfor an example of how to connect to a Redis instance with Stunnel.\n\nCertificate Authorities\n-----------------------\n\nA Redis cluster that uses in-transit encryption has unique\nCertificate Authorities (CAs) that are used to authenticate the certificates of\nthe machines in your cluster. Each CA is identified by a certificate that you\nmust download and install on the client accessing your Redis instance.\n| **Note:** CAs are valid for ten years from the date they are created. To ensure service continuity, new CAs must be installed on clients of the Redis instance before the previous CAs expire.\n\n### Certificate authority rotation\n\nCAs are valid for 10 years upon instance creation. In addition, a new CA will\nbecome available prior to CA expiration.\n\nOld CAs are valid until their expiration date. This gives you a window in which\nto download and install the new CA to clients connecting to the Redis instance.\nAfter the old CAs expires you can uninstall them from clients.\n\nFor instructions on rotating the CA, see [Managing Certificate Authority rotation](/memorystore/docs/cluster/manage-in-transit-encryption#manage_certificate_authority_rotation).\n\n### Server certificate rotation\n\nServer-side certificate rotation occurs every week. New server certificates\napply to new connections only, and existing connections remain alive during\nrotation.\n\nPerformance impact of enabling in-transit encryption\n----------------------------------------------------\n\nThe in-transit encryption feature encrypts and decrypts data, which comes with\nprocessing overhead. As a result, enabling in-transit encryption can reduce\nperformance. Also, when using in-transit encryption, each additional connection\ncomes with as associated resource cost. To determine the latency associated with\nusing in-transit encryption, compare application performance by benchmarking\napplication performance with both a cluster that has in-transit encryption\nenabled and a cluster that has it disabled.\n\n### Guidelines for improving performance\n\n- Decrease the number of client connections when possible. Establish and reuse\n long-running connections rather than creating on-demand short-lived\n connections.\n\n- Increase the size of your Memorystore cluster.\n\n- Increase the CPU resources of the Memorystore client host\n machine. Client machines with a higher CPU count yields better performance. If\n using a Compute Engine VM, we recommend compute optimized instances.\n\n- Decrease the payload size associated with application traffic because larger\n payloads require more round trips."]]