Canada में VPS Hosting: क्या सच में ज़रूरी है?

क्या आपके VPS का Canada में होना आवश्यक है?

Canada में VPS hosting चुनना तब उचित है जब कोई कानून या contract कहता है कि data Canada की सीमा के भीतर रहना चाहिए। यही एकमात्र अनिवार्य कारण है। Toronto के home connection से New York के data centre तक round trip लगभग 18 ms चलता है, जबकि Toronto वाले तक लगभग 3 ms लगता है। लगभग कोई भी web application यह अंतर नहीं बता सकता।

तीन बातें लोगों को Canadian server चुनने के लिए प्रेरित करती हैं। Data residency कानूनी दायित्व है, इसलिए यह अपने-आप निर्णय तय कर देती है। Latency को मापा जा सकता है और यह आमतौर पर लोगों की अपेक्षा से कम होती है। Canadian dollars में billing आपके accountant के लिए सुविधाजनक है। किसी अन्य आधार पर विकल्प चुनने से पहले पता करें कि इनमें से पहली बात आप पर लागू होती है या नहीं।

यह post सामान्य रूप से बताती है कि नियम कैसे काम करते हैं। यह कानूनी सलाह नहीं है। यदि कोई privacy law आपके organisation पर लागू होता है, तो इसका उत्तर आपके counsel से मिलेगा।

Data residency: एकमात्र अनिवार्य आवश्यकता

PIPEDA (Personal Information Protection and Electronic Documents Act) कनाडा का संघीय निजी-क्षेत्र का गोपनीयता कानून है, और यह व्यक्तिगत जानकारी को देश में ही रखने की अनिवार्यता नहीं रखता है। यह डेटा को विदेश में किसी प्रोसेसर को भेजने को प्रोसेसिंग के लिए स्थानांतरण मानता है: आपकी संस्था डेटा के लिए जवाबदेह बनी रहती है, प्रोसेसर को समान सुरक्षा प्रदान करनी होती है, और आपको लोगों को स्पष्ट रूप से बताना होता है कि ऐसा हो रहा है। Office of the Privacy Commissioner ने 2019 में इसे सख्त करने पर परामर्श किया था और फिर अपनी मौजूदा स्थिति को ही बरकरार रखा। जून 2026 में पेश किया गया Bill C-36, जिसका उद्देश्य PIPEDA के निजी-क्षेत्र के नियमों को एक नए Protecting Privacy and Consumer Data Act से बदलना था, अक्टूबर 2026 तक दूसरे वाचन (second reading) तक नहीं पहुँचा था, इसलिए PIPEDA ही वह कानून है जो लागू होता है। अतः यह आम दावा कि PIPEDA का मतलब है कि आपका डेटा कनाडा में ही रहना चाहिए, गलत है, भले ही बहुत सारी होस्टिंग कॉपी इसे दोहराती हो।

वास्तविक residency नियम मौजूद हैं। वे अधिक सीमित क्षेत्रों में लागू होते हैं।

• Quebec का Law 25 यह अनिवार्य करता है कि व्यक्तिगत जानकारी को प्रांत से बाहर भेजने से पहले उसका आकलन किया जाए, और जानकारी को वहाँ पर्याप्त सुरक्षा मिलनी चाहिए जहाँ वह पहुँचती है। यह प्रावधान सितंबर 2023 से लागू है। यह कागजी कार्रवाई और एक ऐसा निर्णय है जिसे आपको सिद्ध करने में सक्षम होना चाहिए, न कि कोई प्रतिबंध।
• सार्वजनिक-क्षेत्र के नियम सार्वजनिक निकायों और उन्हें सेवा देने वाली कंपनियों को बाध्य करते हैं। Nova Scotia का PIIDPA व्यक्तिगत जानकारी को कनाडा से बाहर स्टोर करने पर प्रतिबंध लगाता है; अक्टूबर 2025 में पारित एक नया Freedom of Information and Protection of Privacy Act, 1 अप्रैल 2027 को इसकी जगह लेगा। British Columbia के FIPPA में भी ऐसा ही नियम था, जब तक कि 2021 में संशोधन करके आकलन के बाद विदेशी स्टोरेज की अनुमति नहीं दी गई।
• संघीय सरकार का कार्य Government of Canada की क्लाउड दिशा-निर्देशों का पालन करता है, जिसके लिए Protected B और उससे उच्च स्तर के डेटा का कनाडा में रहना अनिवार्य है।
• प्रांतीय स्वास्थ्य गोपनीयता कानून स्वास्थ्य रिकॉर्ड कहाँ रखे जा सकते हैं, इस पर अपनी शर्तें जोड़ते हैं, और वे प्रांत-दर-प्रांत भिन्न होते हैं।
• ग्राहक अनुबंध और सार्वजनिक निविदाएं व्यवहार में सबसे आम कारक हैं। एक सुरक्षा प्रश्नावली जो कहती है "data at rest in Canada", आपको उतनी ही मजबूती से बांधती है जितना कि कोई कानून, क्योंकि आपने उस पर हस्ताक्षर किए हैं।

व्यावहारिक परीक्षण सरल है। क्या आप उस क्लॉज की ओर इशारा कर सकते हैं? यदि आपकी संस्था में कोई भी उस कानून या अनुबंध का नाम नहीं ले सकता जो कनाडा कहता है, तो आप केवल latency और कीमत के आधार पर चुनाव कर रहे हैं।

क्या कनाडाई data centre अमेरिका के कानूनी अधिकार-क्षेत्र से बाहर है?

अपने-आप नहीं। US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) उस data पर लागू होता है जो किसी US provider के possession, custody या control में हो, चाहे hardware कहीं भी स्थित हो। इसलिए किसी अमेरिकी company द्वारा संचालित Toronto region भी इसके अधिकार-क्षेत्र में आता है। यदि वास्तविक आवश्यकता geography के बजाय foreign legal process से संबंधित है, तो महत्वपूर्ण यह है कि service कौन संचालित करता है और encryption keys किसके पास हैं। भवन पर कनाडाई address होना अपने-आप इसका उत्तर नहीं देता।

Routing दूसरा महत्वपूर्ण मुद्दा है। दो कनाडाई शहरों के बीच traffic अक्सर United States से होकर गुजरता है, क्योंकि ऐतिहासिक रूप से सस्ती peering वहीं उपलब्ध रही है। Researchers इसे boomerang routing कहते हैं। किसी को यह बताने से पहले कि आपके packets देश से बाहर नहीं जाते, traceroute चलाएँ।

traceroute vps.example.com

Hop names में nyc, chi या ash जैसे city codes होते हैं। ये names केवल संकेत हैं और पुराने हो सकते हैं। इसलिए इन्हें proof के बजाय provider से प्रश्न पूछने का कारण मानें। Transit में data के लिए विश्वसनीय उपाय वह encryption है जिसे आप स्वयं नियंत्रित करते हैं, न कि कोई map। यदि आप अपनी machines के बीच private path चाहते हैं, तो self-hosted WireGuard VPN ऐसा path देता है जिसे fibre किस देश से होकर गुजरती है, इससे कोई फर्क नहीं पड़ता।

Latency: इसे मापें, अनुमान न लगाएँ

फाइबर में प्रकाश लगभग 200 km प्रति मिलीसेकंड की गति से चलता है, इसलिए किसी भी उपकरण के शामिल होने से पहले, हर 100 km की दूरी पर लगभग 1 ms का round trip समय लगता है। Toronto से Vancouver की सीधी दूरी लगभग 3,400 km है और केबल के माध्यम से यह और भी अधिक है, जो न्यूनतम समय को 40 ms के करीब ले जाती है। वास्तविक paths का समय इससे अधिक होता है।

[
  {
    "label": "Toronto",
    "rtt_ms": 3
  },
  {
    "label": "Montreal",
    "rtt_ms": 12
  },
  {
    "label": "New York",
    "rtt_ms": 18
  },
  {
    "label": "Chicago",
    "rtt_ms": 24
  },
  {
    "label": "Northern Virginia",
    "rtt_ms": 26
  },
  {
    "label": "Dallas",
    "rtt_ms": 42
  },
  {
    "label": "Vancouver",
    "rtt_ms": 62
  },
  {
    "label": "London",
    "rtt_ms": 88
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 98
  }
]

ये Toronto में एक अच्छी तरह से जुड़े हुए consumer line के लिए सामान्य प्रकाशित आंकड़े हैं। ये एक शुरुआती बिंदु हैं, कोई वादा नहीं। आपके अपने आंकड़े आपके access network और आपके provider की peering पर निर्भर करते हैं, और वे दिन के समय के साथ बदलते रहते हैं।

दो पंक्तियों को दो बार पढ़ना सार्थक है। Toronto से Montreal का समय लगभग 12 ms है, जो इतना कम है कि अधिकांश उद्देश्यों के लिए ये दोनों शहर एक ही क्षेत्र की तरह व्यवहार करते हैं। Toronto से Vancouver का समय लगभग 62 ms है, जो Toronto से Northern Virginia के 26 ms की तुलना में अधिक दूरी है। Canada में होने का मतलब यह नहीं है कि आप अपने users के करीब हैं।

आमतौर पर last mile का प्रभाव सबसे अधिक होता है। Home fibre कुछ मिलीसेकंड जोड़ता है। लाइन व्यस्त होने पर Cable अधिक समय जोड़ता है। एक mobile connection अपने आप में दसियों मिलीसेकंड जोड़ देता है। Toronto में एक phone user को Toronto के सर्वर तक 50 ms का समय मिल सकता है। यदि उस सर्वर को New York ले जाएं, तो path में वही लगभग 15 ms जुड़ते हैं जो सभी के लिए जुड़ते हैं, जिससे कुल समय लगभग 65 ms हो जाता है, और उस user के इंतजार का अधिकांश हिस्सा अभी भी radio link के कारण ही होता है।

अपने उपयोगकर्ताओं के स्थान से लेटेंसी का परीक्षण कैसे करें

पहले पता करें कि आपके उपयोगकर्ता वास्तव में कहाँ हैं। आपके analytics पहले से ही sessions को city या region के अनुसार विभाजित करते हैं। अपने office के स्थान से अनुमान लगाने के बजाय उसी जानकारी को पढ़ें।

फिर वहीं से माप लें। Ottawa की desk से Vancouver की latency का परीक्षण नहीं किया जा सकता। लक्षित city में hourly VPS बीस मिनट के लिए किराये पर लें और उसके बाद उसे नष्ट कर दें। किसी colleague या customer से एक command चलाने को कहें। या https://atlas.ripe.net पर उपलब्ध free RIPE Atlas measurement network का उपयोग करें। इसमें Canadian cities में probes हैं और आप उनसे pings चला सकते हैं।

sudo apt update && sudo apt install -y mtr-tiny traceroute iperf3
ping -c 20 vps.example.com

अंतिम दो lines पढ़ें।

20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 17.412/18.006/19.882/0.594 ms

avg मुख्य संख्या है। mdev jitter है, यानी packets के बीच का फैलाव। छोटी path पर कोई भी packet loss ऐसी fault है जिसकी जाँच करनी चाहिए। High jitter voice और games को slightly higher average से अधिक प्रभावित करता है, क्योंकि receiver को सामान्य packet के बजाय सबसे देर से आने वाले packet के लिए buffer करना पड़ता है।

mtr --report --report-cycles 50 vps.example.com

mtr प्रत्येक hop के लिए loss दिखाता है। यदि यह permission error के साथ समाप्त हो, तो इसे sudo के साथ चलाएँ। Middle hops में अक्सर ऐसा loss दिखता है जो वास्तविक नहीं होता, क्योंकि routers अपने द्वारा बनाए गए ICMP replies को सबसे कम priority देते हैं। केवल वह loss वास्तविक है जो final line तक बना रहता है और आपके traffic को प्रभावित करता है। पहले bottom row पढ़ें, फिर ऊपर की ओर जाँच करें।

जब ICMP blocked हो या rate limited हो, तो इसके बजाय वास्तविक protocol का समय मापें।

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://vps.example.com/

प्रत्येक field request की शुरुआत से cumulative seconds दिखाता है। connect में से dns घटाने पर एक TCP round trip मिलता है। tls में से connect घटाने पर handshake का समय मिलता है। ttfb में से tls घटाने पर एक अतिरिक्त round trip और आपके application के उत्तर देने में लगा समय मिलता है। अधिकांश slow sites इसी अंतिम gap में अपना समय खोती हैं। छोटी path पर 0.8 s का ttfb application problem है। Server को किसी अन्य city में ले जाने से यह समस्या दूर नहीं होगी।

Throughput के लिए server को VPS पर चलाएँ और client को उपयोगकर्ता की ओर से चलाएँ। iperf3 TCP 5201 पर सुनता है, इसलिए परीक्षण के लिए ufw के साथ port खोलें और काम पूरा होने पर उसे फिर बंद कर दें।

iperf3 -s

iperf3 -c vps.example.com -t 20
iperf3 -c vps.example.com -t 20 -R
iperf3 -c vps.example.com -t 20 -P 8

-R direction को reverse करता है, इसलिए आप download और upload दोनों को मापते हैं। -P 8 आठ parallel streams खोलता है। यदि आठ streams एक stream से बहुत तेज हैं, तो सीमा link के बजाय लंबी path पर TCP window है, क्योंकि एक stream प्रत्येक round trip में केवल एक window भेज सकती है। Vancouver path पर वही window New York path की तुलना में प्रति second लगभग एक-तिहाई data भेजती है। Long-haul backups भी इसी तरह काम करते हैं। इसी कारण restic के साथ off-site backups fast line पर भी distant target के विरुद्ध slow लगते हैं।

iperf3 के चलने के दौरान दूसरे terminal में ping चालू रखें। यदि transfer के दौरान round trip 20 ms से बढ़कर 300 ms हो जाता है, तो यह आपके अपने access equipment में bufferbloat है। कोई भी data centre location इसे ठीक नहीं कर सकती।

एक से अधिक बार मापें और शाम को भी मापें। 9pm पर congestion वह संख्या है जिसका सामना आपके उपयोगकर्ता करते हैं। 4am की संख्या वह है जिसे sales page दिखाना पसंद करेगा।

आपके वर्कलोड के लिए round-trip time का क्या अर्थ है

एक cold page load ब्राउज़र द्वारा कुछ भी ड्रा करने से पहले चार round trips खर्च करता है।

[
  {
    "label": "DNS lookup",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TCP handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TLS 1.3 handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "Request and first byte",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "All four round trips",
    "toronto_to_new_york_ms": 72,
    "toronto_to_vancouver_ms": 248
  }
]

DNS lookup आपके सर्वर के बजाय एक resolver के पास जाता है और यह आमतौर पर cached होता है, इसलिए एक warm visit इसे छोड़ देती है। अंत से अंत तक गिनने पर, एक cold load New York path पर 72 ms पीछे और Vancouver path पर 248 ms पीछे शुरू होता है। New York का आंकड़ा एक 400 ms की database query की तुलना में छोटा है। Vancouver का आंकड़ा ऐसा नहीं है: यह उस query का आधे से अधिक है, और एक cold visitor वास्तव में इसका भुगतान करता है। एक बार कनेक्शन खुल जाने के बाद, HTTP/2 और HTTP/3 एक ही समय में कई requests ले जाते हैं, इसलिए वह लागत प्रति फ़ाइल के बजाय एक बार चुकाई जाती है। Static assets को CDN (content delivery network) पर रखें और उनके लिए origin का शहर मायने रखना बंद कर देता है, यही कारण है कि Toronto तक 98 ms का सामना करने वाला एक यूरोपीय आगंतुक भी एक तेज़ पेज प्राप्त कर सकता है।

Real-time multiplayer games इसके विपरीत हैं, क्योंकि round trip ही अनुभव है। लगभग 50 ms से कम का समय एक तेज़ action game में तत्काल महसूस होता है, खिलाड़ी 80 ms के आसपास ध्यान देना शुरू करते हैं, और 120 ms से अधिक होने पर वे सर्वर को दोषी ठहराते हैं। यहाँ क्षेत्र वास्तव में तय करता है कि उत्पाद अच्छा है या नहीं। धीमी गति वाले सर्वर कहीं अधिक क्षमाशील होते हैं, इसलिए running a Minecraft server on a VPS उन दूरियों को भी झेल लेता है जो एक शूटर गेम को बर्बाद कर देंगी।

Databases वह जगह हैं जहाँ क्षेत्र का चुनाव वास्तविक नुकसान पहुँचाता है। एप्लिकेशन को एक क्षेत्र में और उसके डेटाबेस को दूसरे क्षेत्र में कभी न रखें। प्रत्येक query एक round trip है। 40 queries जारी करने वाला एक पेज उनमें से 40 का भुगतान करता है: 18 ms प्रति query पर यह एक सेकंड का अधिकांश हिस्सा है, और 62 ms प्रति query पर यह दो सेकंड से अधिक है, जबकि उसी बॉक्स पर डेटाबेस के साथ पेज का प्रोफाइल 30 ms था। Read replicas और disaster recovery के लिए दूसरे क्षेत्र में Asynchronous replication ठीक है। एक लंबे path पर Synchronous commit हर एक write में उस path को जोड़ देता है।

Interactive sessions इनके बीच में आते हैं। SSH लगभग 100 ms तक आरामदायक रहता है और उससे ऊपर laggy महसूस होता है, क्योंकि प्रत्येक keystroke को वापस आने वाले echo का इंतजार करना पड़ता है। mosh स्थानीय रूप से अनुमान लगाता है और इसमें से अधिकांश को छिपा देता है। Webhooks और internal APIs को हमेशा उसी क्षेत्र में रहना चाहिए जहाँ वे सेवा कॉल करते हैं।

बिलिंग, मुद्रा और कर

Canadian dollars में भुगतान करने से आपके card issuer द्वारा लिया जाने वाला foreign transaction fee नहीं लगेगा, जो August 2026 तक सामान्यतः लगभग 2.5% था। इससे आपके लेखे एक ही मुद्रा में बने रहते हैं। Canadian provider GST या HST के साथ invoice जारी करता है। Registered business इसे input tax credit के रूप में वापस दावा कर सकता है। यह वित्त से जुड़ा प्रश्न है और इसका उत्तर भी वित्तीय है। इससे यह तय नहीं होना चाहिए कि packets किस दिशा में जाएँ। Server की वास्तविक लागत और renewal pricing के प्रभाव से बचते हुए plans की तुलना करने के लिए हर महीने VPS की वास्तविक लागत पढ़ें।

छोटे बाज़ार की लागत

United States की तुलना में Canada का hosting बाज़ार छोटा है। इसलिए ईमानदार सलाह में यह बताना भी शामिल है कि आपको क्या छोड़ना पड़ेगा।

• आपके पैसे के लिए प्रतिस्पर्धा करने वाले providers कम हैं। इसलिए समान श्रेणी की machine के लिए RAM या disk के प्रति gigabyte की कीमत आमतौर पर अधिक होती है।
• Capacity Toronto और Montreal में केंद्रित है। Vancouver और Calgary में यह कम है। Failover के लिए दूसरा Canadian region चुनने पर अक्सर network path लंबा होगा या आपको देश से बाहर जाना पड़ेगा।
• कोई छोटा regional host एक building को एक या दो upstream carriers के पीछे चला सकता है। पूछें कि कितने carriers हैं और उनमें से किसी एक के विफल होने पर क्या होता है।
• Hardware का विकल्प सीमित होता है। US regions में बड़े instances और GPU machines आसानी से मिलती हैं। इसलिए आपकी पसंद के शहर में आपकी पसंद के आकार का GPU VPS उपलब्ध न हो सकता है।
• छोटे host में support coverage वास्तविक प्रश्न है, marketing का नहीं। पूछें कि human support कब उपलब्ध रहता है।

कीमत के मामले में Montreal अपवाद है। Quebec की hydroelectric power सस्ती है और सर्दियों में cooling costs कम हो जाती हैं। इसलिए Montreal क्षेत्र में बहुत अधिक capacity ऐसी दरों पर उपलब्ध है जो US regions से प्रतिस्पर्धा करती हैं। यदि आपकी आवश्यकता Canada है, किसी एक खास शहर की नहीं, तो वहीं से शुरुआत करें।

यदि Canadian VPS tiers workload के लिए बहुत छोटे लगते हैं, तो यह तय करने से पहले कि समस्या देश में है, VPS और dedicated server की तुलना करें।

कनाडा में VPS होस्टिंग कब सही विकल्प है

1. किसी कानून, अनुबंध या सार्वजनिक क्षेत्र की नीति में Canada का नाम दिया गया हो। Canada में होस्ट करें। इस पोस्ट की कोई अन्य बात लागू नहीं होती। प्रदाता से डेटा-रेज़िडेंसी की प्रतिबद्धता लिखित रूप में भी लें।
2. आपके उपयोगकर्ता एक ही Canadian महानगरीय क्षेत्र में हों और वर्कलोड latency पर निर्भर हो: multiplayer games, voice, remote desktops या trading। निकटतम शहर में होस्ट करें और कोई भी अनुबंध करने से पहले दोनों विकल्पों का मापन करें।
3. आपके उपयोगकर्ता पूरे देश में फैले हों। Toronto या Montreal आबादी के सबसे बड़े हिस्से को कवर करता है। Static assets के सामने CDN लगाने से Vancouver के उपयोगकर्ता को origin स्थानांतरित करने की तुलना में अधिक लाभ मिलता है।
4. बाकी सभी मामले, जो अधिकांश मामले हैं। कीमत और वास्तविक hardware के आधार पर चयन करें। फिर देखें कि 2am पर support कैसा मिलता है। पहले उम्मीदवार का benchmark करें, क्योंकि समान specification sheet वाली दो plans का performance समान नहीं होता: VPS का सही benchmark कैसे करें।

आप जो भी विकल्प चुनें, निर्णय के साथ उसका कारण लिखें। अगला व्यक्ति, जो पूछे कि इसे Canada में होना चाहिए या नहीं, अनुमान से बेहतर उत्तर का हकदार है। यदि उत्तर कभी किसी contract clause में था, तो किसी को उसे फिर से ढूंढना होगा। Box उपलब्ध होने के बाद, नए VPS पर पहले दस मिनट उसकी security के लिए उसके शहर से कहीं अधिक महत्वपूर्ण होते हैं।

FAQ

क्या PIPEDA के अनुसार मेरा डेटा Canada में ही रहना आवश्यक है?

नहीं। PIPEDA (Personal Information Protection and Electronic Documents Act) में private sector के लिए data residency का कोई नियम नहीं है। किसी दूसरे देश में स्थित processor को personal information भेजना processing के लिए transfer माना जाता है। आपकी organisation डेटा के लिए जवाबदेह रहती है। Processor को तुलनीय सुरक्षा देनी होती है। आपको लोगों को स्पष्ट रूप से बताना होता है कि ऐसा transfer किया जाता है। Office of the Privacy Commissioner ने 2019 में इस स्थिति को बदलने पर परामर्श किया था और बाद में इसे बरकरार रखा। Residency requirements अन्य स्रोतों से आती हैं: Quebec का Law 25 assessment, Nova Scotia के PIIDPA जैसे public-sector acts, Government of Canada की cloud direction, या आपके अपने customer contract की कोई clause।

क्या Canada के users को United States में स्थित server का पता चलेगा?

सामान्य web application में नहीं। Toronto से New York तक round trip लगभग 18 ms और Northern Virginia तक लगभग 26 ms है। दोनों, Toronto से Vancouver तक के 62 ms से कम हैं। Users को network के 20 ms का अंतर महसूस होने से बहुत पहले server response time और page weight का अंतर महसूस हो जाता है। Real-time games, voice calls और ऐसी किसी भी स्थिति में उन्हें इसका पता चलता है जहां एक व्यक्ति दूसरे व्यक्ति की प्रतिक्रिया पर प्रतिक्रिया दे रहा हो।

क्या Canadian data centre US law के दायरे से बाहर होता है?

अपने-आप नहीं। US CLOUD Act, US provider के possession, custody या control में मौजूद डेटा पर लागू होता है, भले ही server कहीं भी स्थित हो। इसलिए American company द्वारा operated Canadian region भी इसके दायरे में आता है। यदि आपकी वास्तविक चिंता foreign legal process है, तो building के address के बजाय यह देखें कि service कौन operate करता है और encryption keys किसके पास हैं। आपके स्वयं के पास मौजूद keys से किया गया encryption यह बदल देता है कि provider क्या सौंप सकता है।

जिस city में मैं नहीं रहता, वहां से latency कैसे मापूं?

उस city में hourly VPS किराये पर लें। ping -c 20 चलाकर अपने server तक और वापस mtr --report --report-cycles 50 चलाएं। इसके बाद VPS नष्ट कर दें। RIPE Atlas network एक free alternative है, जिसमें Canadian cities में probes हैं। यदि ICMP blocked है, तो इसके बजाय वास्तविक request का समय curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/ से मापें। यह TCP round trip और first byte तक का पूरा समय देता है।