ESNI ਨਾਲ ਤੁਹਾਡੀ ਜਨਤਕ ਵੈੱਬਸਾਈਟ ਨੂੰ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਹੈ

ਹੈਲੋ ਹੈਬਰ, ਮੇਰਾ ਨਾਮ ਇਲਿਆ ਹੈ, ਮੈਂ Exness 'ਤੇ ਪਲੇਟਫਾਰਮ ਟੀਮ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹਾਂ। ਅਸੀਂ ਮੂਲ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਹਿੱਸੇ ਵਿਕਸਿਤ ਅਤੇ ਲਾਗੂ ਕਰਦੇ ਹਾਂ ਜੋ ਸਾਡੀ ਉਤਪਾਦ ਵਿਕਾਸ ਟੀਮਾਂ ਵਰਤਦੀਆਂ ਹਨ।

ਇਸ ਲੇਖ ਵਿੱਚ, ਮੈਂ ਜਨਤਕ ਵੈੱਬਸਾਈਟਾਂ ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਐਨਕ੍ਰਿਪਟਡ SNI (ESNI) ਤਕਨਾਲੋਜੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਆਪਣੇ ਅਨੁਭਵ ਨੂੰ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹਾਂਗਾ।

ਇਸ ਤਕਨਾਲੋਜੀ ਦੀ ਵਰਤੋਂ ਜਨਤਕ ਵੈੱਬਸਾਈਟ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਵੇਲੇ ਸੁਰੱਖਿਆ ਦੇ ਪੱਧਰ ਨੂੰ ਵਧਾਏਗੀ ਅਤੇ ਕੰਪਨੀ ਦੁਆਰਾ ਅਪਣਾਏ ਗਏ ਅੰਦਰੂਨੀ ਸੁਰੱਖਿਆ ਮਾਪਦੰਡਾਂ ਦੀ ਪਾਲਣਾ ਕਰੇਗੀ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਂ ਇਹ ਦੱਸਣਾ ਚਾਹਾਂਗਾ ਕਿ ਤਕਨਾਲੋਜੀ ਮਿਆਰੀ ਨਹੀਂ ਹੈ ਅਤੇ ਅਜੇ ਵੀ ਡਰਾਫਟ ਵਿੱਚ ਹੈ, ਪਰ CloudFlare ਅਤੇ Mozilla ਪਹਿਲਾਂ ਹੀ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ (ਵਿੱਚ ਡਰਾਫਟ01). ਇਸ ਨੇ ਸਾਨੂੰ ਅਜਿਹੇ ਪ੍ਰਯੋਗ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤਾ।

ਥਿਊਰੀ ਦਾ ਕੁਝ ਹਿੱਸਾ

ਈ.ਐੱਸ.ਐੱਨ.ਆਈ TLS 1.3 ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਇੱਕ ਐਕਸਟੈਂਸ਼ਨ ਹੈ ਜੋ TLS ਹੈਂਡਸ਼ੇਕ "ਕਲਾਇੰਟ ਹੈਲੋ" ਸੰਦੇਸ਼ ਵਿੱਚ SNI ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇੱਥੇ ESNI ਸਮਰਥਨ ਨਾਲ ਕਲਾਇੰਟ ਹੈਲੋ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ (ਸਾਧਾਰਨ SNI ਦੀ ਬਜਾਏ ਜੋ ਅਸੀਂ ESNI ਦੇਖਦੇ ਹਾਂ):

 ESNI ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਤਿੰਨ ਭਾਗਾਂ ਦੀ ਲੋੜ ਹੈ:

• DNS; 
• ਗਾਹਕ ਸਹਾਇਤਾ;
• ਸਰਵਰ ਸਾਈਡ ਸਪੋਰਟ।

DNS ਨੂੰ

ਤੁਹਾਨੂੰ ਦੋ DNS ਰਿਕਾਰਡ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ - Aਅਤੇ TXT (TXT ਰਿਕਾਰਡ ਵਿੱਚ ਜਨਤਕ ਕੁੰਜੀ ਹੁੰਦੀ ਹੈ ਜਿਸ ਨਾਲ ਕਲਾਇੰਟ SNI ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰ ਸਕਦਾ ਹੈ) - ਹੇਠਾਂ ਦੇਖੋ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਹਾਇਤਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ DoH (HTTPS ਉੱਤੇ DNS) ਕਿਉਂਕਿ ਉਪਲਬਧ ਕਲਾਇੰਟਸ (ਹੇਠਾਂ ਦੇਖੋ) DoH ਤੋਂ ਬਿਨਾਂ ESNI ਸਹਾਇਤਾ ਨੂੰ ਸਮਰੱਥ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਇਹ ਤਰਕਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ESNI ਉਸ ਸਰੋਤ ਦੇ ਨਾਮ ਦੀ ਏਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਸ ਤੱਕ ਅਸੀਂ ਪਹੁੰਚ ਕਰ ਰਹੇ ਹਾਂ, ਯਾਨੀ, UDP ਉੱਤੇ DNS ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਵਰਤੋਂ DNSSEC ਤੁਹਾਨੂੰ ਇਸ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਕੈਸ਼ ਜ਼ਹਿਰ ਦੇ ਹਮਲਿਆਂ ਤੋਂ ਬਚਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

ਵਰਤਮਾਨ ਵਿੱਚ ਉਪਲਬਧ ਹੈ ਕਈ DoH ਪ੍ਰਦਾਤਾ, ਉਨ੍ਹਾਂ ਦੇ ਵਿੱਚ:

• CloudFlare
• OpenDNS
• ਗੂਗਲ

CloudFlare ਐਲਾਨ (ਮੇਰਾ ਬ੍ਰਾਊਜ਼ਰ ਚੈੱਕ ਕਰੋ → ਐਨਕ੍ਰਿਪਟਡ SNI → ਹੋਰ ਜਾਣੋ) ਕਿ ਉਹਨਾਂ ਦੇ ਸਰਵਰ ਪਹਿਲਾਂ ਹੀ ESNI ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਯਾਨੀ DNS ਵਿੱਚ CloudFlare ਸਰਵਰਾਂ ਲਈ ਸਾਡੇ ਕੋਲ ਘੱਟੋ-ਘੱਟ ਦੋ ਰਿਕਾਰਡ ਹਨ - A ​​ਅਤੇ TXT। ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਨ ਵਿੱਚ ਅਸੀਂ Google DNS (HTTPS ਉੱਤੇ) ਦੀ ਪੁੱਛਗਿੱਛ ਕਰਦੇ ਹਾਂ: 

А ਇੰਦਰਾਜ਼:

curl 'https://dns.google.com/resolve?name=www.cloudflare.com&type=A' 
-s -H 'accept: application/dns+json'
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
      "name": "www.cloudflare.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "www.cloudflare.com.",
      "type": 1,
      "TTL": 257,
      "data": "104.17.210.9"
    },
    {
      "name": "www.cloudflare.com.",
      "type": 1,
      "TTL": 257,
      "data": "104.17.209.9"
    }
  ]
}

TXT ਰਿਕਾਰਡ, ਬੇਨਤੀ ਇੱਕ ਟੈਪਲੇਟ ਦੇ ਅਨੁਸਾਰ ਤਿਆਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ _esni.FQDN:

curl 'https://dns.google.com/resolve?name=_esni.www.cloudflare.com&type=TXT' 
-s -H 'accept: application/dns+json'
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
    "name": "_esni.www.cloudflare.com.",
    "type": 16
    }
  ],
  "Answer": [
    {
    "name": "_esni.www.cloudflare.com.",
    "type": 16,
    "TTL": 1799,
    "data": ""/wEUgUKlACQAHQAg9SiAYQ9aUseUZr47HYHvF5jkt3aZ5802eAMJPhRz1QgAAhMBAQQAAAAAXtUmAAAAAABe3Q8AAAA=""
    }
  ],
  "Comment": "Response from 2400:cb00:2049:1::a29f:209."
}

ਇਸ ਲਈ, ਇੱਕ DNS ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਸਾਨੂੰ DoH (ਤਰਜੀਹੀ ਤੌਰ 'ਤੇ DNSSEC ਦੇ ਨਾਲ) ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਦੋ ਐਂਟਰੀਆਂ ਜੋੜਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। 

ਗਾਹਕ ਸਹਾਇਤਾ

ਜੇ ਅਸੀਂ ਬ੍ਰਾਉਜ਼ਰਾਂ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਤਾਂ ਇਸ ਸਮੇਂ ਸਮਰਥਨ ਸਿਰਫ ਫਾਇਰਫਾਕਸ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਇਹ ਇਸ ਲਈ ਹੈ ਫਾਇਰਫਾਕਸ ਵਿੱਚ ESNI ਅਤੇ DoH ਸਮਰਥਨ ਨੂੰ ਕਿਵੇਂ ਸਰਗਰਮ ਕਰਨਾ ਹੈ ਇਸ ਬਾਰੇ ਨਿਰਦੇਸ਼ ਇੱਥੇ ਦਿੱਤੇ ਗਏ ਹਨ। ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਾਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਕੁਝ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ:

ਲਿੰਕ ਨੂੰ ਬਰਾਊਜ਼ਰ ਨੂੰ ਚੈੱਕ ਕਰਨ ਲਈ.

ਬੇਸ਼ੱਕ, ESNI ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ TLS 1.3 ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ESNI TLS 1.3 ਲਈ ਇੱਕ ਐਕਸਟੈਂਸ਼ਨ ਹੈ।

ESNI ਸਮਰਥਨ ਨਾਲ ਬੈਕਐਂਡ ਦੀ ਜਾਂਚ ਕਰਨ ਦੇ ਉਦੇਸ਼ ਲਈ, ਅਸੀਂ ਕਲਾਇੰਟ ਨੂੰ ਚਾਲੂ ਕੀਤਾ ਹੈ go, ਪਰ ਬਾਅਦ ਵਿੱਚ ਇਸ 'ਤੇ ਹੋਰ.

ਸਰਵਰ ਸਾਈਡ ਸਪੋਰਟ

ਵਰਤਮਾਨ ਵਿੱਚ, ESNI ਵੈੱਬ ਸਰਵਰਾਂ ਜਿਵੇਂ ਕਿ nginx/apache, ਆਦਿ ਦੁਆਰਾ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਉਹ OpenSSL/BoringSSL ਦੁਆਰਾ TLS ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਜੋ ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ ESNI ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ ਹਨ।

ਇਸ ਲਈ, ਅਸੀਂ ਆਪਣਾ ਫਰੰਟ-ਐਂਡ ਕੰਪੋਨੈਂਟ (ESNI ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ) ਬਣਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ, ਜੋ ESNI ਨਾਲ TLS 1.3 ਸਮਾਪਤੀ ਅਤੇ ਅੱਪਸਟਰੀਮ ਲਈ ਪ੍ਰੌਕਸੀ HTTP(S) ਟ੍ਰੈਫਿਕ ਦਾ ਸਮਰਥਨ ਕਰੇਗਾ, ਜੋ ESNI ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਇਹ ਮੁੱਖ ਭਾਗਾਂ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ, ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਤਕਨਾਲੋਜੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ - ਭਾਵ, ਮੌਜੂਦਾ ਵੈਬ ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਜੋ ESNI ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ ਹਨ। 

ਸਪਸ਼ਟਤਾ ਲਈ, ਇੱਥੇ ਇੱਕ ਚਿੱਤਰ ਹੈ:

ਮੈਂ ਨੋਟ ਕਰਦਾ ਹਾਂ ਕਿ ਪ੍ਰੌਕਸੀ ਨੂੰ ESNI ਤੋਂ ਬਿਨਾਂ, ESNI ਤੋਂ ਬਿਨਾਂ ਗਾਹਕਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ, TLS ਕਨੈਕਸ਼ਨ ਨੂੰ ਖਤਮ ਕਰਨ ਦੀ ਯੋਗਤਾ ਨਾਲ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ। ਨਾਲ ਹੀ, ਅੱਪਸਟ੍ਰੀਮ ਨਾਲ ਸੰਚਾਰ ਪ੍ਰੋਟੋਕੋਲ ਜਾਂ ਤਾਂ HTTP ਜਾਂ HTTPS ਹੋ ਸਕਦਾ ਹੈ ਜਿਸਦਾ TLS ਸੰਸਕਰਣ 1.3 ਤੋਂ ਘੱਟ ਹੈ (ਜੇਕਰ ਅੱਪਸਟ੍ਰੀਮ 1.3 ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਹੈ)। ਇਹ ਸਕੀਮ ਵੱਧ ਤੋਂ ਵੱਧ ਲਚਕਤਾ ਦਿੰਦੀ ਹੈ।

'ਤੇ ESNI ਸਹਾਇਤਾ ਨੂੰ ਲਾਗੂ ਕਰਨਾ go ਅਸੀਂ ਤੋਂ ਉਧਾਰ ਲਿਆ ਹੈ CloudFlare. ਮੈਂ ਤੁਰੰਤ ਨੋਟ ਕਰਨਾ ਚਾਹਾਂਗਾ ਕਿ ਲਾਗੂ ਕਰਨਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕਾਫ਼ੀ ਗੈਰ-ਮਾਮੂਲੀ ਹੈ, ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਸ਼ਾਮਲ ਹਨ crypto/tls ਅਤੇ ਇਸ ਲਈ "ਪੈਚਿੰਗ" ਦੀ ਲੋੜ ਹੈ ਗੂਰੋਟ ਵਿਧਾਨ ਸਭਾ ਦੇ ਅੱਗੇ.

ESNI ਕੁੰਜੀਆਂ ਬਣਾਉਣ ਲਈ ਅਸੀਂ ਵਰਤੀਆਂ esnitool (ਕਲਾਉਡਫਲੇਅਰ ਦੀ ਦਿਮਾਗ ਦੀ ਉਪਜ ਵੀ)। ਇਹ ਕੁੰਜੀਆਂ SNI ਇਨਕ੍ਰਿਪਸ਼ਨ/ਡਿਕ੍ਰਿਪਸ਼ਨ ਲਈ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਅਸੀਂ ਲੀਨਕਸ (ਡੇਬੀਅਨ, ਅਲਪਾਈਨ) ਅਤੇ ਮੈਕੋਸ 'ਤੇ ਗੋ 1.13 ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਿਲਡ ਦੀ ਜਾਂਚ ਕੀਤੀ। 

ਕਾਰਜਸ਼ੀਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ

ESNI ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਪ੍ਰੋਮੀਥੀਅਸ ਫਾਰਮੈਟ ਵਿੱਚ ਮੈਟ੍ਰਿਕਸ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ rps, ਅੱਪਸਟ੍ਰੀਮ ਲੇਟੈਂਸੀ ਅਤੇ ਜਵਾਬ ਕੋਡ, ਅਸਫਲ/ਸਫਲ TLS ਹੈਂਡਸ਼ੇਕ ਅਤੇ TLS ਹੈਂਡਸ਼ੇਕ ਮਿਆਦ। ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਇਹ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਜਾਪਦਾ ਸੀ ਕਿ ਪ੍ਰੌਕਸੀ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੀ ਹੈ। 

ਅਸੀਂ ਵਰਤੋਂ ਤੋਂ ਪਹਿਲਾਂ ਲੋਡ ਟੈਸਟਿੰਗ ਵੀ ਕੀਤੀ। ਹੇਠਾਂ ਨਤੀਜੇ:

wrk -t50 -c1000 -d360s 'https://esni-rev-proxy.npw:443' --timeout 15s
Running 6m test @ https://esni-rev-proxy.npw:443
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.77s     1.21s    7.20s    65.43%
    Req/Sec    13.78      8.84   140.00     83.70%
  206357 requests in 6.00m, 6.08GB read
Requests/sec:    573.07
Transfer/sec:     17.28MB 

ਅਸੀਂ ESNI ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਤੇ ਬਿਨਾਂ ਸਕੀਮ ਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗੁਣਾਤਮਕ ਲੋਡ ਟੈਸਟਿੰਗ ਕੀਤੀ। ਅਸੀਂ ਇੰਟਰਮੀਡੀਏਟ ਕੰਪੋਨੈਂਟਸ ਵਿੱਚ "ਦਖਲਅੰਦਾਜ਼ੀ" ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ "ਡੋਲ੍ਹਿਆ"।

ਇਸ ਲਈ, ESNI ਸਮਰਥਨ ਅਤੇ HTTP ਤੋਂ ਅੱਪਸਟ੍ਰੀਮ ਕਰਨ ਲਈ ਪ੍ਰੌਕਸੀ ਕਰਨ ਦੇ ਨਾਲ, ਸਾਨੂੰ ESNI ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਦੀ ਔਸਤ CPU/RAM ਖਪਤ ਦੇ ਨਾਲ, ਇੱਕ ਵਾਰ ਤੋਂ ਲਗਭਗ ~550 rps ਪ੍ਰਾਪਤ ਹੋਏ:

• 80% CPU ਵਰਤੋਂ (4 vCPU, 4 GB RAM ਹੋਸਟ, Linux)
• 130 MB Mem RSS

ਤੁਲਨਾ ਲਈ, TLS (HTTP ਪ੍ਰੋਟੋਕੋਲ) ਸਮਾਪਤੀ ਤੋਂ ਬਿਨਾਂ ਉਸੇ ਐਨਜੀਨੈਕਸ ਅਪਸਟ੍ਰੀਮ ਲਈ RPS ~ 1100 ਹੈ:

wrk -t50 -c1000 -d360s 'http://lb.npw:80' –-timeout 15s
Running 6m test @ http://lb.npw:80
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.11s     2.30s   15.00s    90.94%
    Req/Sec    23.25     13.55   282.00     79.25%
  393093 requests in 6.00m, 11.35GB read
  Socket errors: connect 0, read 0, write 0, timeout 9555
  Non-2xx or 3xx responses: 8111
Requests/sec:   1091.62
Transfer/sec:     32.27MB 

ਸਮਾਂ ਸਮਾਪਤੀ ਦੀ ਮੌਜੂਦਗੀ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਸਰੋਤਾਂ ਦੀ ਘਾਟ ਹੈ (ਅਸੀਂ 4 vCPUs, 4 GB RAM ਹੋਸਟ, Linux ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ), ਅਤੇ ਅਸਲ ਵਿੱਚ ਸੰਭਾਵੀ RPS ਵੱਧ ਹੈ (ਸਾਨੂੰ ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਰੋਤਾਂ 'ਤੇ 2700 RPS ਤੱਕ ਦੇ ਅੰਕੜੇ ਪ੍ਰਾਪਤ ਹੋਏ)।

ਸਿੱਟਾ ਵਿੱਚ, ਮੈਂ ਨੋਟ ਕਰਦਾ ਹਾਂ ਕਿ ESNI ਟੈਕਨਾਲੋਜੀ ਕਾਫ਼ੀ ਹੋਨਹਾਰ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ। ਅਜੇ ਵੀ ਬਹੁਤ ਸਾਰੇ ਖੁੱਲੇ ਸਵਾਲ ਹਨ, ਉਦਾਹਰਨ ਲਈ, DNS ਵਿੱਚ ਜਨਤਕ ESNI ਕੁੰਜੀ ਨੂੰ ਸਟੋਰ ਕਰਨ ਅਤੇ ESNI ਕੁੰਜੀਆਂ ਨੂੰ ਘੁੰਮਾਉਣ ਦੇ ਮੁੱਦੇ - ਇਹਨਾਂ ਮੁੱਦਿਆਂ 'ਤੇ ਸਰਗਰਮੀ ਨਾਲ ਚਰਚਾ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ, ਅਤੇ ESNI ਡਰਾਫਟ ਦਾ ਨਵੀਨਤਮ ਸੰਸਕਰਣ (ਲਿਖਣ ਦੇ ਸਮੇਂ) ਪਹਿਲਾਂ ਹੀ ਹੈ. 7.

ਸਰੋਤ: www.habr.com