🥇ESNI ನೊಂದಿಗೆ ನಿಮ್ಮ ಸಾರ್ವಜನಿಕ ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ಹೇಗೆ ರಕ್ಷಿಸುವುದು

ಹಾಯ್ ಹಬ್ರ್, ನನ್ನ ಹೆಸರು ಇಲ್ಯಾ, ನಾನು ಎಕ್ಸ್‌ನೆಸ್‌ನಲ್ಲಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತಂಡದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ನಮ್ಮ ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿ ತಂಡಗಳು ಬಳಸುವ ಮೂಲಸೌಕರ್ಯ ಘಟಕಗಳನ್ನು ನಾವು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೇವೆ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ.

ಈ ಲೇಖನದಲ್ಲಿ, ಸಾರ್ವಜನಿಕ ವೆಬ್‌ಸೈಟ್‌ಗಳ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ SNI (ESNI) ತಂತ್ರಜ್ಞಾನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ನನ್ನ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾನು ಬಯಸುತ್ತೇನೆ.

ಈ ತಂತ್ರಜ್ಞಾನದ ಬಳಕೆಯು ಸಾರ್ವಜನಿಕ ವೆಬ್‌ಸೈಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಭದ್ರತೆಯ ಮಟ್ಟವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ಕಂಪನಿಯು ಅಳವಡಿಸಿಕೊಂಡ ಆಂತರಿಕ ಭದ್ರತಾ ಮಾನದಂಡಗಳನ್ನು ಅನುಸರಿಸುತ್ತದೆ.

ಮೊದಲನೆಯದಾಗಿ, ತಂತ್ರಜ್ಞಾನವು ಪ್ರಮಾಣೀಕರಿಸಲ್ಪಟ್ಟಿಲ್ಲ ಮತ್ತು ಇನ್ನೂ ಡ್ರಾಫ್ಟ್‌ನಲ್ಲಿದೆ ಎಂದು ನಾನು ಗಮನಸೆಳೆಯಲು ಬಯಸುತ್ತೇನೆ, ಆದರೆ ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಮತ್ತು ಮೊಜಿಲ್ಲಾ ಈಗಾಗಲೇ ಅದನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ (ಇನ್ ಕರಡು01). ಇದೇ ನಮಗೆ ಇಂತಹ ಪ್ರಯೋಗ ನಡೆಸಲು ಪ್ರೇರಣೆ ನೀಡಿತು.

ಸಿದ್ಧಾಂತದ ಒಂದು ಬಿಟ್

ಇಎಸ್‌ಎನ್‌ಐ – ಇದು TLS 1.3 ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ವಿಸ್ತರಣೆಯಾಗಿದ್ದು ಅದು "ಕ್ಲೈಂಟ್ ಹಲೋ" TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಂದೇಶದಲ್ಲಿ SNI ಅನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ESNI ಬೆಂಬಲದೊಂದಿಗೆ ಕ್ಲೈಂಟ್ ಹಲೋ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ (ಸಾಮಾನ್ಯ SNI ಬದಲಿಗೆ, ನಾವು ESNI ಅನ್ನು ನೋಡುತ್ತೇವೆ):

ESNI ಬಳಸಲು, ಮೂರು ಘಟಕಗಳು ಅಗತ್ಯವಿದೆ:

ಡಿಎನ್ಎಸ್;
ಗ್ರಾಹಕ ಬೆಂಬಲ;
ಸರ್ವರ್ ಸೈಡ್ ಬೆಂಬಲ.

ಡಿಎನ್ಎಸ್

ನೀವು ಎರಡು DNS ದಾಖಲೆಗಳನ್ನು ಸೇರಿಸಬೇಕಾಗಿದೆ – Aಮತ್ತು TXT (TXT ದಾಖಲೆಯು ಕ್ಲೈಂಟ್ SNI ಅನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದಾದ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯನ್ನು ಒಳಗೊಂಡಿದೆ) - ಕೆಳಗೆ ನೋಡಿ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಬೆಂಬಲ ಇರಬೇಕು DoH (HTTPS ಮೂಲಕ DNS), ಲಭ್ಯವಿರುವ ಕ್ಲೈಂಟ್‌ಗಳು (ಕೆಳಗೆ ನೋಡಿ) DoH ಇಲ್ಲದೆ ESNI ಬೆಂಬಲವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದಿಲ್ಲ. ಇದು ತಾರ್ಕಿಕವಾಗಿದೆ, ಏಕೆಂದರೆ ESNI ನಾವು ಪ್ರವೇಶಿಸುತ್ತಿರುವ ಸಂಪನ್ಮೂಲ ಹೆಸರಿನ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಅಂದರೆ UDP ಮೂಲಕ DNS ಅನ್ನು ಪ್ರವೇಶಿಸುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ. ಇದಲ್ಲದೆ, ಬಳಸುವುದು ಡಿಎನ್‌ಎಸ್‌ಎಸ್‌ಇಸಿ ಈ ಸನ್ನಿವೇಶದಲ್ಲಿ ಕ್ಯಾಶ್ ವಿಷಪೂರಿತ ದಾಳಿಯಿಂದ ನಿಮ್ಮನ್ನು ರಕ್ಷಿಸಿಕೊಳ್ಳಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಪ್ರಸ್ತುತ ಲಭ್ಯವಿದೆ ಹಲವಾರು DoH ಪೂರೈಕೆದಾರರು, ಅವುಗಳಲ್ಲಿ:

ಕ್ಲೌಡ್ಫಲೇರ್ ಘೋಷಿಸುತ್ತದೆ (ನನ್ನ ಬ್ರೌಸರ್ ಪರಿಶೀಲಿಸಿ → ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ SNI → ಇನ್ನಷ್ಟು ತಿಳಿಯಿರಿ), ಅವರ ಸರ್ವರ್‌ಗಳು ಈಗಾಗಲೇ ESNI ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ, ಅಂದರೆ, DNS ನಲ್ಲಿ ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಸರ್ವರ್‌ಗಳಿಗಾಗಿ ನಾವು ಕನಿಷ್ಠ ಎರಡು ದಾಖಲೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ - 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 ನೊಂದಿಗೆ ಆದ್ಯತೆ) ಮತ್ತು ಎರಡು ದಾಖಲೆಗಳನ್ನು ಸೇರಿಸಬೇಕು.

ಗ್ರಾಹಕ ಬೆಂಬಲ

ನಾವು ಬ್ರೌಸರ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ಈ ಸಮಯದಲ್ಲಿ ಬೆಂಬಲವನ್ನು ಫೈರ್‌ಫಾಕ್ಸ್‌ನಲ್ಲಿ ಮಾತ್ರ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ.. ಇದು FireFox ನಲ್ಲಿ ESNI ಮತ್ತು DoH ಬೆಂಬಲವನ್ನು ಹೇಗೆ ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಸೂಚನೆಗಳನ್ನು ನೀಡಲಾಗಿದೆ. ಬ್ರೌಸರ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ನಂತರ, ನಾವು ಈ ರೀತಿಯದ್ದನ್ನು ನೋಡಬೇಕು:

ಲಿಂಕ್ ಬ್ರೌಸರ್ ಪರಿಶೀಲಿಸಲು.

ESNI TLS 1.3 ಗೆ ವಿಸ್ತರಣೆಯಾಗಿರುವುದರಿಂದ, ESNI ಅನ್ನು ಬೆಂಬಲಿಸಲು TLS 1.3 ಅನ್ನು ಬಳಸಬೇಕು ಎಂಬುದು ನಿಜ.

ESNI ಬೆಂಬಲದೊಂದಿಗೆ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವ ಉದ್ದೇಶಕ್ಕಾಗಿ, ನಾವು ಒಂದು ಕ್ಲೈಂಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ go, ಆದರೆ ನಂತರ ಹೆಚ್ಚು.

ಸರ್ವರ್ ಸೈಡ್ ಬೆಂಬಲ

ಪ್ರಸ್ತುತ ESNI ಅನ್ನು nginx/apache ಇತ್ಯಾದಿ ವೆಬ್ ಸರ್ವರ್‌ಗಳು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅವು OpenSSL/BoringSSL ಮೂಲಕ TLS ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಆದರೆ ಅವು ಅಧಿಕೃತವಾಗಿ ESNI ಅನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.

ಅದಕ್ಕಾಗಿಯೇ ನಾವು ನಮ್ಮದೇ ಆದ ಫ್ರಂಟ್-ಎಂಡ್ ಕಾಂಪೊನೆಂಟ್ (ESNI ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ) ಅನ್ನು ರಚಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಇದು ESNI ನೊಂದಿಗೆ TLS 1.3 ಮುಕ್ತಾಯವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಮತ್ತು ESNI ಅನ್ನು ಬೆಂಬಲಿಸದ HTTP(S) ಟ್ರಾಫಿಕ್ ಅನ್ನು ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗೆ ಪ್ರಾಕ್ಸಿ ಮಾಡುತ್ತದೆ. ಇದು ಮುಖ್ಯ ಘಟಕಗಳನ್ನು ಬದಲಾಯಿಸದೆ, ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ - ಅಂದರೆ, ESNI ಅನ್ನು ಬೆಂಬಲಿಸದ ಪ್ರಸ್ತುತ ವೆಬ್ ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸುವುದು.

ಸ್ಪಷ್ಟತೆಗಾಗಿ, ಇಲ್ಲಿ ಒಂದು ರೇಖಾಚಿತ್ರವಿದೆ:

ESNI ಇಲ್ಲದೆಯೇ TLS ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ, ESNI ಇಲ್ಲದೆಯೇ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಪ್ರಾಕ್ಸಿಯನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾನು ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ. ಅಲ್ಲದೆ, ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ ಪ್ರೋಟೋಕಾಲ್ 1.3 ಕ್ಕಿಂತ ಕಡಿಮೆ TLS ಆವೃತ್ತಿಯೊಂದಿಗೆ HTTP ಅಥವಾ HTTPS ಆಗಿರಬಹುದು (ಅಪ್‌ಸ್ಟ್ರೀಮ್ 1.3 ಅನ್ನು ಬೆಂಬಲಿಸದಿದ್ದರೆ). ಈ ಯೋಜನೆಯು ಗರಿಷ್ಠ ನಮ್ಯತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.

ESNI ಬೆಂಬಲದ ಅನುಷ್ಠಾನ go ನಾವು ಸಾಲ ಪಡೆದಿದ್ದೇವೆ ಕ್ಲೌಡ್ಫಲೇರ್ಅನುಷ್ಠಾನವು ಸಾಕಷ್ಟು ಕ್ಷುಲ್ಲಕವಲ್ಲ ಎಂದು ನಾನು ತಕ್ಷಣ ಗಮನಿಸುತ್ತೇನೆ, ಏಕೆಂದರೆ ಇದು ಪ್ರಮಾಣಿತ ಗ್ರಂಥಾಲಯದಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಕ್ರಿಪ್ಟೋ/ಟಿಎಲ್ಎಸ್ ಮತ್ತು ಆದ್ದರಿಂದ "ಪ್ಯಾಚಿಂಗ್" ಅಗತ್ಯವಿದೆ ಗೊರೂಟ್ ಅಸೆಂಬ್ಲಿ ಮೊದಲು.

ESNI ಕೀಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ನಾವು ಬಳಸಿದ್ದೇವೆ ಎಸ್ನಿಟೂಲ್ (ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ರಚನೆಯೂ ಸಹ). ಈ ಕೀಗಳನ್ನು SNI ಅನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್/ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಲು ಬಳಸಲಾಗುತ್ತದೆ.
ನಾವು ಗೋ 1.13 ಬಳಸಿ ಬಿಲ್ಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ Linux (Debian, ಆಲ್ಪೈನ್) ಮತ್ತು ಮ್ಯಾಕೋಸ್.

ಕಾರ್ಯಾಚರಣೆಯ ವೈಶಿಷ್ಟ್ಯಗಳ ಬಗ್ಗೆ ಕೆಲವು ಪದಗಳು

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 ಯೊಂದಿಗೆ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಪ್ರಾಕ್ಸಿ ಮಾಡುವಿಕೆಯೊಂದಿಗೆ, ನಾವು ಒಂದು ನಿದರ್ಶನದಿಂದ ಸುಮಾರು ~550 rps ಅನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ, ESNI ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯ ಸರಾಸರಿ CPU/RAM ಬಳಕೆಯೊಂದಿಗೆ:

80% CPU ಬಳಕೆ (4 vCPU, 4 GB RAM ಹೋಸ್ಟ್‌ಗಳು, Linux)
130 MB ಮೆಮ್ RSS

ಹೋಲಿಕೆಗಾಗಿ, TLS ಮುಕ್ತಾಯ (HTTP ಪ್ರೋಟೋಕಾಲ್) ಇಲ್ಲದೆ ಅದೇ nginx ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗೆ 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 vCPU, 4 GB RAM ಹೋಸ್ಟ್‌ಗಳನ್ನು ಬಳಸಿದ್ದೇವೆ, Linux), ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಸಂಭಾವ್ಯ RPS ಹೆಚ್ಚಾಗಿದೆ (ಹೆಚ್ಚು ಶಕ್ತಿಶಾಲಿ ಸಂಪನ್ಮೂಲಗಳ ಮೇಲೆ ನಾವು 2700 RPS ವರೆಗಿನ ಅಂಕಿಅಂಶಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ).

ಕೊನೆಯಲ್ಲಿ, ನಾನು ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ ESNI ತಂತ್ರಜ್ಞಾನವು ಸಾಕಷ್ಟು ಭರವಸೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಇನ್ನೂ ಅನೇಕ ಮುಕ್ತ ಪ್ರಶ್ನೆಗಳಿವೆ, ಉದಾಹರಣೆಗೆ, ಸಾರ್ವಜನಿಕ ESNI ಕೀಲಿಯನ್ನು DNS ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ESNI ಕೀಲಿಗಳನ್ನು ತಿರುಗಿಸುವುದು - ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಸಕ್ರಿಯವಾಗಿ ಚರ್ಚಿಸಲಾಗಿದೆ ಮತ್ತು ESNI ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿ (ಬರೆಯುವ ಸಮಯದಲ್ಲಿ) ಈಗಾಗಲೇ ಇದೆ. 7.

ಮೂಲ: www.habr.com