Xây dựng cơ sở dữ liệu định vị địa lý IP từ đầu

 (ipapi.is)
5 điểm bởi GN⁺ 2023-09-15 | 1 bình luận | Chia sẻ qua WhatsApp
  • Cơ sở dữ liệu định vị địa lý IP liên kết các dải IP với quốc gia, thành phố, mã bưu chính, múi giờ và tọa độ; ipapi.is cung cấp CSV miễn phí và cơ sở dữ liệu CSV/MMDB thương mại
  • Bản miễn phí không bao phủ toàn bộ không gian IPv4/IPv6 và độ chính xác cũng thấp, trong khi bản thương mại là cơ sở dữ liệu đầy đủ được dùng cho trường location của API và được cập nhật ít nhất 2 lần mỗi tuần
  • Nếu tự xây dựng, cần kết hợp dữ liệu geoloc/geofeed của WHOIS, suy luận vị trí từ địa chỉ và trường mô tả trong WHOIS, cùng các dự án công khai như RIPE IPmap, geofeed-finder và OpenGeoFeed
  • Khi mạng được phân tán ở nhiều khu vực hoặc IP được phân bổ lại/cho thuê, độ chính xác sẽ dao động; tính đến tháng 7/2023, độ phủ geoloc của RIPE NCC là 2,3%, còn độ phủ URL geofeed là khoảng 0,17%
  • Dữ liệu thu thập cần được bổ sung và chuẩn hóa, chẳng hạn tìm tọa độ từ thành phố/quốc gia hoặc tìm thành phố gần nhất từ tọa độ; ipapi.is sử dụng các tệp thông tin mã bưu chính, thành phố và quốc gia của GeoNames

Cấu trúc của cơ sở dữ liệu định vị địa lý IP

  • IP to Geolocation Database là cơ sở dữ liệu lưu thông tin vị trí địa lý theo từng dải IP
  • Một địa chỉ IP có thể được định vị địa lý bằng các thông tin sau
    • Quốc gia, thành phố, bang/tỉnh, mã bưu chính
    • Múi giờ
    • Vĩ độ, kinh độ
  • Cơ sở dữ liệu ipapi.is được chia thành bản miễn phí và bản thương mại
    • Bản miễn phí có thể tải xuống ở định dạng CSV
    • Bản thương mại được cung cấp ở định dạng CSV và MMDB
    • Bản thương mại bao phủ toàn bộ không gian IPv4/IPv6
    • Bản miễn phí chỉ bao gồm một phần không gian IPv4/IPv6
  • Cơ sở dữ liệu thương mại được cập nhật ít nhất 2 lần mỗi tuần

Khác biệt giữa bản miễn phí và bản thương mại

  • Cơ sở dữ liệu định vị địa lý IP miễn phí có số lượng mục ít hơn bản thương mại và không bao phủ toàn bộ không gian địa chỉ IPv4/IPv6
  • Bản miễn phí có độ chính xác định vị địa lý thấp hơn
  • Nguồn chính của bản miễn phí là dữ liệu WHOIS và RFC 8805 Geofeeds
  • Cơ sở dữ liệu thương mại là cơ sở dữ liệu đầy đủ được dùng cho trường location của API ipapi.is
  • Bản thương mại kết hợp nhiều nguồn để tính ra vị trí
    • Bản ghi WHOIS
    • Đo độ trễ chủ động dựa trên ping và traceroute
    • RFC 8805 Geofeeds
    • Tra cứu DNS ngược

Định dạng cơ sở dữ liệu và trường độ chính xác

  • Tệp cơ sở dữ liệu có định dạng CSV hoặc MMDB
  • Các trường chính chứa đồng thời dải IP, vị trí, tọa độ và độ chính xác
    • ip_version: IPv4 là 4, IPv6 là 6
    • start_ip, end_ip: IP bắt đầu và kết thúc của dải mạng
    • continent, country_code, country, state, city, zip
    • timezone, latitude, longitude
    • accuracy
  • accuracy biểu thị độ chính xác ước tính của thông tin định vị địa lý theo thang 1–5
    • 1: độ chính xác rất cao, thường đáng tin cậy ở cấp thành phố
    • 2: độ chính xác cao, nhìn chung đáng tin cậy ở cấp thành phố
    • 3: độ chính xác trung bình, khó tin cậy ở cấp thành phố
    • 4: độ chính xác thấp, thường chính xác ở cấp quốc gia
    • 5: độ chính xác rất thấp, kỳ vọng chính xác ở cấp quốc gia

Cách kiểm tra mẫu MMDB

Ứng dụng và giới hạn của định vị địa lý IP

  • Định vị địa lý IP là quá trình ánh xạ địa chỉ IP tới một vị trí địa lý được xác định bằng vĩ độ và kinh độ
  • Các doanh nghiệp trực tuyến và nhà cung cấp dịch vụ sử dụng thông tin định vị địa lý cho nhiều mục đích
    • Quảng cáo nhắm mục tiêu
    • Phát hiện và ngăn chặn gian lận
    • Bản địa hóa nội dung
    • DRM và tuân thủ quy định
    • Bảo mật mạng
    • Phân tích và insight
  • Có những lý do mang tính cấu trúc khiến định vị địa lý IP không phải lúc nào cũng chính xác
    • Các mạng IPv4/IPv6 được cấp phát có thể phân tán về mặt địa lý
    • Có những mạng được thiết kế trải rộng nhiều khu vực, như mạng di động hoặc mạng vệ tinh
    • Khi Regional Internet Registry hoặc công ty cho thuê IP phân bổ lại/tái cấp phát mạng IP, vị trí có thể thay đổi
  • Định vị địa lý địa chỉ IP là việc phức tạp, nhưng có thể cung cấp độ chính xác khó bỏ qua trong các API địa chỉ IP

Các công việc cần làm khi xây dựng từ đầu

  • Mỗi địa chỉ IP trên Internet thuộc sở hữu hoặc do một tổ chức cụ thể quản lý
  • Regional Internet Registry (RIR) như ARIN, APNIC lưu thông tin sở hữu trong cơ sở dữ liệu WHOIS
  • Bản ghi WHOIS không phải lúc nào cũng chứa thông tin định vị địa lý của mạng được cấp phát
  • Tổ chức sở hữu mạng có thể sử dụng IP ở bất kỳ vị trí địa lý nào họ muốn, cũng có thể cấp phát cho bên thứ ba hoặc cho thuê các khối IP
  • Việc thu thập thông tin định vị địa lý được chia thành ba hướng lớn
    • Trích xuất dữ liệu định vị địa lý trực tiếp như geoloc, geofeed từ bản ghi WHOIS
    • Suy luận vị trí gián tiếp từ địa chỉ bưu chính, phần mô tả và thông tin quốc gia trong WHOIS
    • Tận dụng các dự án công khai như RIPE IPmap, geofeed-finder, OpenGeoFeed

Dữ liệu định vị địa lý trực tiếp theo từng RIR

  • RIPE NCC

    • Các đối tượng inetnum, inet6num của RIPE NCC cấp phát mạng IP cho tổ chức
    • Thông tin định vị địa lý có thể được cung cấp qua hai thuộc tính geoloc và geofeed
    • geoloc chứa vĩ độ và kinh độ dưới dạng chuỗi
    • Ví dụ: 47.855374 12.132041
    • Tính đến tháng 7/2023, cơ sở dữ liệu RIPE NCC có 4.190.644 đối tượng inetnum và 819.381 đối tượng inet6num
    • Trong số này có 114.389 đối tượng chứa thuộc tính geoloc, tương đương độ phủ tổng thể 2,3%
    • geofeed chứa URL của tệp CSV theo định dạng RFC 8805
    • URL geofeed có thể được ghi trong thuộc tính chuyên dụng geofeed hoặc dưới dạng Geofeed {URL} trong thuộc tính remarks
    • Tính đến tháng 7/2023, RIPE NCC có 6.643 URL geofeed trong thuộc tính remarks và 2.035 bản ghi WHOIS có thuộc tính geofeed
    • Độ phủ URL geofeed là 0,17%, nhưng con số này có thể gây hiểu nhầm vì một tệp geofeed có thể bao gồm nhiều mạng

  • ARIN

    • ARIN cung cấp thông tin định vị địa lý bằng cách đưa URL geofeed vào thuộc tính Comment của đối tượng NetRange
    • Từng có yêu cầu thêm thuộc tính geofeed chuyên dụng, nhưng bị từ chối với lý do các thuộc tính Comment hoặc Remark đã đủ
    • Khác với RIPE NCC, cơ sở dữ liệu ARIN không dùng thuộc tính geoloc

  • LACNIC

    • LACNIC tích cực hỗ trợ định vị địa lý hơn ARIN
    • LACNIC vận hành Geofeed Service, cho phép thành viên cung cấp thông tin định vị địa lý của các địa chỉ IP họ sở hữu
    • Dữ liệu công khai được cung cấp tại milacnic.lacnic.net/lacnic/geofeeds
    • Cơ sở dữ liệu WHOIS của LACNIC mặc định cung cấp thông tin định vị địa lý ở cấp thành phố
    • Có thể tải cơ sở dữ liệu LACNIC từ máy chủ FTP ftp.lacnic.net/lacnic/dbase/

  • AFRINIC và APNIC

    • AFRINIC cho biết họ không cung cấp dịch vụ định vị địa lý và cũng không có quan hệ chính thức hay vận hành với các nhà cung cấp định vị địa lý
    • Tương tự RIPE NCC, AFRINIC hỗ trợ sử dụng URL geofeed trong thuộc tính remarks
    • APNIC hỗ trợ định vị địa lý gần tương đương RIPE NCC
      • Thuộc tính geoloc
      • URL geofeed trong thuộc tính remarks
    • APNIC thể hiện thái độ cởi mở với việc cải thiện hỗ trợ định vị địa lý

Cách suy luận vị trí từ WHOIS

  • Mục đích chính của WHOIS là cung cấp thông tin bên đăng ký của tổ chức sở hữu tài nguyên số Internet như địa chỉ IP hoặc số AS
  • WHOIS thường bao gồm địa chỉ bưu chính và quốc gia của trụ sở hoặc địa điểm quản trị của tổ chức
  • Có trường hợp địa chỉ bưu chính của tổ chức trùng với nơi sử dụng địa chỉ IP, nhưng không phải lúc nào cũng vậy
  • Địa chỉ quản trị của tổ chức lớn có thể không trùng với vị trí của toàn bộ địa chỉ IP của tổ chức đó

  • Suy luận trong RIPE NCC

    • Các thuộc tính có thể dùng từ đối tượng inetnum, inet6num của RIPE NCC gồm
      • country: chỉ cung cấp độ chính xác cấp quốc gia
      • descr: mô tả mạng, có thể chứa thông tin vị trí/địa chỉ
      • netname: khó phân tích cú pháp và độ tin cậy thấp
      • address: về mặt chặt chẽ là thuộc tính của đối tượng role, chứa địa chỉ bưu chính
    • Thuộc tính country xác định mã quốc gia theo ISO 3166-2, nhưng không nói rõ quốc gia đó là vị trí trụ sở, vị trí trung tâm dữ liệu hay vị trí người dùng cuối
    • Thuộc tính descr là mô tả dạng tự do, nhưng hữu ích cho suy luận định vị địa lý vì tổ chức đôi khi đưa thông tin vị trí mạng và địa chỉ vào đây
    • address có thể đem lại độ chính xác cao, nhưng giả định địa chỉ bưu chính của đối tượng vai trò trùng với nơi sử dụng địa chỉ IP có thể gây lỗi

  • Suy luận trong ARIN

    • Trong ARIN, các thuộc tính WHOIS sau tương đối đáng tin cậy với tổ chức nhỏ hoặc tổ chức tập trung tại một địa điểm
      • Address
      • City
      • StateProv
      • PostalCode
      • Country
    • Các tổ chức như trường đại học, bệnh viện, cơ quan chính phủ đôi khi sử dụng địa chỉ IP của đối tượng NetRange tại cùng vị trí với địa chỉ bưu chính quản trị
    • Với các doanh nghiệp lớn hoặc tổ chức toàn quốc sở hữu nhiều NetRange, địa chỉ bưu chính quản trị có thể không khớp với vị trí sử dụng IP thực tế
    • Trong ví dụ Google Fiber, nếu dùng địa chỉ WHOIS thì vị trí sẽ là Mountain View, California, nhưng hầu hết nhà cung cấp định vị địa lý đặt IP đó ở San Antonio, Texas

  • LACNIC, AFRINIC, APNIC

    • LACNIC cung cấp định vị địa lý trong cơ sở dữ liệu WHOIS nên không cần suy luận riêng
    • AFRINIC dùng định dạng cơ sở dữ liệu WHOIS giống RIPE NCC, vì vậy có thể áp dụng cùng nguyên tắc
      • country, descr
      • address của đối tượng role
    • APNIC cũng dùng định dạng cơ sở dữ liệu WHOIS giống RIPE NCC, vì vậy áp dụng cùng nguyên tắc

Các dự án định vị địa lý công khai

  • RIPE IPmap

    • RIPE IPmap từng là API cung cấp dữ liệu định vị địa lý cho hạ tầng Internet cốt lõi
    • Có vẻ dự án không còn được bảo trì, và dường như không có đóng góp mới sau năm 2019
    • RIPE IPmap suy luận vị trí địa lý của địa chỉ IP bằng nhiều engine
    • Các engine latency và single-radius dùng phép đo từ RIPE Atlas để cung cấp bán kính độ trễ của địa chỉ IP
    • Giá trị RTT tối thiểu cung cấp giới hạn trên cho khoảng cách tối đa có thể, do tốc độ ánh sáng trong môi trường cáp quang
    • Engine reverse-dns trích xuất vị trí địa lý cấp thành phố từ hostname trong bản ghi PTR
    • Có thể tải cơ sở dữ liệu RIPE IPmap tại https://ftp.ripe.net/ripe/ipmap/
    • Theo website của người bảo trì trước đây, độ chính xác và độ phủ của dự án đã suy giảm đáng kể

  • geofeed-finder

    • geofeed-finder là công cụ mã nguồn mở để phát hiện và tải tệp geofeed từ dữ liệu WHOIS
    • Công cụ này cũng thực hiện xác minh quyền sở hữu prefix, quản lý cache và xác thực mã ISO
    • Theo RFC 9092, có thể trích xuất geofeed từ dữ liệu WHOIS
    • Do độ phủ thông tin geofeed trên toàn bộ mạng rất thấp, tính hữu dụng thực tế còn hạn chế

  • LACNIC Geofeeds Service và OpenGeoFeed

    • LACNIC Geofeeds Service cung cấp thông tin định vị địa lý cho một phần đáng kể thành viên LACNIC
    • Dữ liệu có thể tải công khai tại milacnic.lacnic.net/lacnic/geofeeds
    • Đây là dự án quan trọng ở chỗ có thể thu thập thông tin định vị địa lý ở cấp RIR
    • OpenGeoFeed là dự án mã nguồn mở thu thập các geofeed tự công khai theo RFC 9092
    • OpenGeoFeed cung cấp một tệp duy nhất chứa các tệp geofeed công khai đã biết tại opengeofeed.org/feed/public.csv
    • OpenGeoFeed có triển vọng, nhưng độ phủ geofeed có vẻ không được cập nhật và khả năng các nguồn dữ liệu được cập nhật thường xuyên là thấp

Bổ sung và chuẩn hóa dữ liệu

  • Dữ liệu định vị địa lý thô thu thập từ nhiều nguồn có thể không đầy đủ hoặc không nhất quán
  • Có thể xuất hiện cả bản ghi có thông tin quốc gia/thành phố nhưng không có tọa độ, lẫn bản ghi có tọa độ nhưng không có thông tin quốc gia/thành phố
  • Nếu bản ghi nguồn chỉ chứa quốc gia, độ chính xác khó vượt quá cấp quốc gia
  • Dữ liệu thu thập cần được bổ sung và chuyển đổi sang một định dạng chung
  • Việc bổ sung dữ liệu được thực hiện bằng cơ sở dữ liệu địa lý mã nguồn mở
  • Công việc bổ sung được chia thành hai trường hợp
    • Tìm vĩ độ và kinh độ từ cặp thành phố/quốc gia
    • Tìm thành phố và quốc gia gần nhất từ vĩ độ/kinh độ
  • ipapi.is dùng các cơ sở dữ liệu sau để bổ sung thông tin định vị địa lý
    • GeoNames Postal Code Files: mã bưu chính trên toàn thế giới, ngoại trừ một số quốc gia vì lý do pháp lý
    • cities500.zip: các thành phố có dân số trên 500 người
    • countryInfo.txt: metadata quốc gia như thủ đô, dân số, châu lục

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-09-15
Ý kiến trên Hacker News

  • Tôi đã thích đọc các bài viết của tác giả từ trước khi gia nhập IPinfo, và IPinfo cung cấp dịch vụ dữ liệu định vị địa lý IP
    Chúng tôi dùng một phương pháp luận mở rộng hơn so với cách được mô tả ở đây; cũng tận dụng một phần các bộ dữ liệu công khai, nhưng dữ liệu vị trí cốt lõi đến từ đo đạc dựa trên ping
    Chúng tôi gửi ping từ nhiều máy chủ trên khắp thế giới tới các địa chỉ IP, rồi xác định vị trí bằng phép đa phương vị (multilateration). Ping từ một máy chủ chỉ cho biết thông tin một chiều rằng nó ở đâu đó trong một bán kính nhất định, nhưng khi lặp lại từ nhiều máy chủ, vị trí dần trở nên chính xác hơn
    Nếu đo đủ nhiều, có thể đạt độ chính xác gần mức mã bưu chính; hiện chúng tôi có hơn 600 máy chủ dò tìm trên toàn cầu và vẫn đang tiếp tục mở rộng
    Dữ liệu công khai thường cũ hoặc không được cập nhật thường xuyên, nhìn chung không đủ chính xác để hữu dụng, và trong nhiều trường hợp chỉ cung cấp vị trí theo dải IP lớn hoặc theo cấp tổ chức
    Ngoài ra, các bộ dữ liệu công khai không có quy trình xác minh. Khi giao dịch IPv4 và dịch vụ VPN gia tăng, chúng tôi đã thấy những trường hợp thông tin không chính xác bị đưa vào, nên tuy rất hoan nghênh các báo cáo chỉnh sửa vị trí IP, chúng tôi luôn phải xác minh
    Theo kinh nghiệm vận hành mạng dò tìm, mua một máy chủ ở New York dễ và rẻ hơn nhiều so với ở một quốc gia nào đó tại Trung Phi. Vị trí của địa chỉ IP có ảnh hưởng lớn đến giá trị mà IP đó có thể mang lại
    Chúng tôi cũng cung cấp cơ sở dữ liệu IP-to-Country ASN miễn phí có thể dùng cho dự án: https://ipinfo.io/developers/ip-to-country-asn-database

    • Tôi tò mò bạn là fan của bài nào. Là bài ở https://incolumitas.com/ hay https://ipapi.is/?
      Ý tưởng tam giác hóa độ trễ rất hay. Tôi đã dùng thông tin độ trễ cho nhiều mục đích như phát hiện VPN và proxy, nhưng chưa từng nghĩ có thể suy ra vị trí chính xác đến vậy
      Dùng 600 máy chủ để tam giác hóa độ trễ có vẻ sẽ cho ra một xấp xỉ khá tốt, thật ấn tượng
      Tuy vậy tôi có vài điều thắc mắc. Một số ISP xử lý lưu lượng ICMP với mức ưu tiên thấp hoặc làm giảm hiệu năng của nó thì các bạn đối phó thế nào; để định vị địa lý toàn bộ IPv4 thì phải liên tục ping hàng tỷ địa chỉ, vậy các bạn chỉ đo một IP ngẫu nhiên trong mỗi inetnum/NetRange được cấp phát hay sao; phần lớn địa chỉ IP không phản hồi ICMP, vậy các bạn có tìm router phía trước mục tiêu rồi xác định vị trí router đó không?
    • Địa chỉ anycast khó xác định “vị trí” bằng thời gian phản hồi ICMP, và một số còn được gắn với vị trí logic riêng. Có thể xem ví dụ tại https://blog.cloudflare.com/icloud-private-relay/
    • Là fan và khách hàng của IPinfo, chúng tôi dùng API để đưa vào email thông báo đăng nhập những câu như “Bạn vừa đăng nhập từ Berlin, Đức. Nếu không phải bạn, hãy bấm vào đây”
      Chúng tôi cũng dùng để cung cấp dữ liệu quốc gia trong nhật ký kiểm toán của khách hàng, chống spam và phát hiện gian lận
    • Tôi tò mò liệu các bạn đã cân nhắc cho tải cơ sở dữ liệu xuống ở định dạng Parquet chưa
      Như vậy có thể sao chép tệp lên S3, Google Cloud, v.v. rồi truy vấn trực tiếp bằng nhiều công cụ. CSV cũng làm được, nhưng không được mượt lắm
    • Tôi từng thắc mắc làm thế nào để biết vị trí của một địa chỉ IP khi không có nguồn thông tin sẵn có, và phần giải thích này đúng là điều tôi muốn biết, rất thú vị

  • Nếu không muốn tự triển khai, bạn có thể dùng một Cloudflare Worker đơn giản để Cloudflare làm miễn phí cho mình. Mọi request Cloudflare đều chứa thông tin vị trí IP ước chừng
    Bạn cũng có thể gửi request đến URL này chạy bằng Cloudflare Worker. Độ trễ trên toàn cầu sẽ thấp: https://www.edenmaps.net/iplocation
    Dùng cho các ứng dụng nhỏ thì ổn, chỉ xin đừng gửi kiểu 10 triệu request mỗi ngày

    • Tải cơ sở dữ liệu IP về dùng vẫn tốt hơn là chia sẻ với bên thứ ba những địa chỉ IP nào có khả năng đã truy cập dịch vụ
    • Nó báo tôi ở một nơi cách bờ biển Somalia 100 km, trong khi thực tế tôi ở Brussels, Bỉ. Cảm ơn vì quyền riêng tư :D
    • Không biết có ai biết định vị địa lý của Cloudflare trong request Worker chính xác đến mức nào không
    • Tuyệt vời. Nếu có thể, tôi muốn biết bạn có thể công bố mã đó dưới dạng mã nguồn mở không
    • Tôi đang ở Munich, nhưng Cloudflare lại chỉ tới một khu rừng ngẫu nhiên cách 730 km về phía bắc

  • Tôi sống ở một quốc gia mà ngôn ngữ bản địa không phải tiếng mẹ đẻ của mình, nên tôi rất ghét các website suy đoán ngôn ngữ bằng vị trí IP rồi ép áp dụng
    Trình duyệt gửi header ngôn ngữ rất rõ ràng, vậy mà họ vẫn phớt lờ và chọn ngôn ngữ dựa trên một giả định lười biếng

    • Tôi làm trong dịch vụ định vị địa lý IP nhưng cũng ghét chuyện này
      Trong ngành người ta gọi là “cá nhân hóa trải nghiệm web”, nhưng đó là một cách làm khó chịu. Tôi chưa từng khuyên ai làm như vậy
      Nếu cá nhân hóa website bằng định vị địa lý IP, tốt nhất chỉ nên dùng cho những thứ như thuế, phí vận chuyển, hoặc đưa quốc gia của người dùng lên đầu danh sách chọn quốc gia
      Ngoài những việc đó thì hầu như tôi không nghĩ ra gì. Dịch thuật thường không hoạt động tốt và chỉ gây cản trở. Dù website có thiện ý, tạo phiên bản ngôn ngữ địa phương bằng Google Translate không phải ý hay
    • Tôi sống ở Mỹ nhưng trên mọi thiết bị, định vị địa lý IP đều chỉ sai khu vực
      Hiếm có công nghệ nào phá hỏng trải nghiệm Internet hằng ngày như các cơ sở dữ liệu kiểu này
      Tôi chỉ mong chúng biến mất
      Thay vì website lần nào cũng đoán sai rồi giấu luồng sửa sau nhiều liên kết và lần tải trang, cứ hỏi mã bưu chính ngay ở lần tải đầu tiên là được
      Hơn nữa cũng không có cách nào sửa cơ sở dữ liệu để tạo ra “đáp án đúng” hay “đáp án tốt hơn”. Vì hiếm khi website thực sự cần dùng vị trí hiện tại
      Thường thì tôi kiểm tra tồn kho của cửa hàng ở nơi mình sắp đến. Cả lĩnh vực này về cơ bản đang cố giải một bài toán được định nghĩa sai
    • Tôi cũng bức xúc tương tự đến mức đã viết cả bài về chuyện này: https://www.fer.xyz/2021/04/i18n

  • Tùy vào mục đích sử dụng và độ chính xác cần thiết
    Cách tốt nhất để xây dựng dịch vụ định vị địa lý là có được 1 tỷ thiết bị đồng thời báo cáo vị trí của chúng và IP. Trên thực tế, Apple và Google đang ở vị thế này
    Vì liên tục nhận được các cập nhật về IP và vị trí, họ có cơ sở dữ liệu định vị địa lý tốt nhất thế giới
    Điểm cốt lõi là tạo ra một ứng dụng mà mọi người tự nguyện cung cấp vị trí, rồi khiến thật nhiều người dùng ứng dụng đó. Vì vậy mà ngày nay ứng dụng nào cũng đòi quyền truy cập vị trí
    Foursquare đã đi đúng hướng, nhưng đi quá sớm

    • Ngay cả 10 năm trước, chính sách bảo vệ quyền riêng tư nội bộ của Apple đã ngăn Apple thu thập vĩ độ/kinh độ chính xác
      Để xác định endpoint nào là tối ưu cho một IP hay subnet cụ thể, họ phải dùng đo lường từ xa phiên HTTP, và kết quả là đã tự xây dựng một cơ sở dữ liệu kiểu GeoIP dựa trên điều kiện thực tế
      Dù vậy, vì lý do quyền riêng tư, họ phải giữ dữ liệu đó trong thời gian ngắn nhất có thể. Kết quả reverse geocoding của Apple Maps không được phép sử dụng hay ghi lại ngoài ngữ cảnh yêu cầu người dùng theo thời gian thực, chẳng hạn như tìm nhà hàng gần đó

  • Một chuyện có phần liên quan: Google Maps có thể học vị trí IP dựa trên việc bạn khám phá vị trí nào trên bản đồ
    Nếu bạn xem một vị trí cụ thể đủ nhiều lần, ngay cả khi xóa hết cookie, khi mở Google Maps vị trí đó vẫn được dùng làm vị trí mặc định
    Tôi phát hiện ra điều này khi dùng Google Maps, và nếu xét đến việc nhiều người có thể dùng chung một địa chỉ IP, khía cạnh quyền riêng tư hơi đáng lo

    • Khả năng ngược lại có vẻ cao hơn. Có lẽ Google có một cơ sở dữ liệu định vị địa lý IP rất tốt, nên khi không có thông tin khác thì họ dùng nó làm vị trí để khám phá
    • Vì vậy mà đôi khi nó nói tôi đang ở con sông nơi tôi hay chèo thuyền, và đôi khi lại hiện ở nơi có nhà nghỉ mùa hè của tôi
    • Họ cũng dùng điều này cho Google Workspace, bản địa hóa dữ liệu và xác định khu vực thẩm quyền của cơ quan thực thi pháp luật

  • Thú vị, nhưng tôi không nghĩ việc xác định vị trí địa lý thực tế được thực hiện như thế này
    Dữ liệu ARIN/RIPE không đủ chính xác vượt quá cấp quốc gia, nên không hữu ích
    Định vị địa lý thương mại tương quan IP của client với các vị trí vật lý đã biết. Ví dụ như thông tin WiFi AP hoặc bưu kiện gửi cho người dùng. Ít nhất tôi đã nghe nói như vậy suốt hàng chục năm qua

    • Tôi làm trong lĩnh vực công nghệ quảng cáo, và định vị địa lý được xử lý như vậy
      Cũng có định vị địa lý thiết bị, nhưng nếu người dùng không đồng ý chia sẻ dữ liệu GPS thì việc nhắm mục tiêu chỉ dùng địa chỉ IP. Nhà cung cấp phổ biến là MaxMind, họ phân phối cơ sở dữ liệu để host cục bộ và truy vấn

  • Các bình luận có vẻ khá hoài nghi, nhưng cá nhân tôi thấy thật sự thú vị
    Nó làm tôi nhớ đến việc thêm PostGIS và tìm kiếm dựa trên vị trí vào cơ sở dữ liệu ở công việc đầu tiên. Khi đó dựa trên địa chỉ và mã bưu chính

    • Trong MySQL cũng có thể làm tương đối đơn giản. Một mẹo là dùng hình vuông thay vì hình tròn, như vậy có thể tránh được nhiều phép tính toán học

  • Khá lâu trước đây, tôi đã tạo http://www.hostip.info. Đó là một dịch vụ thu thập vị trí địa chỉ IP theo cách cộng đồng, kiểu như “Ước tính này sai à? Hãy sửa giúp”
    Lần cuối tôi kiểm tra có lẽ là khoảng 10 năm trước, quốc gia thì gần như hoàn hảo, khu vực thì chưa đầy đủ, còn thành phố thì tốt hơn tung đồng xu. Tất cả dữ liệu đều miễn phí
    Không biết trên site còn không, nhưng từng có một khối lập phương 3D xoay để hiển thị các địa chỉ đã biết hoặc các truy vấn gần đây. x, y, z là ba octet đầu của địa chỉ, và dùng màu khác nhau theo các nhóm như quốc gia, châu lục
    Nó cũ đến mức được viết bằng Java applet. Nếu làm lại, có lẽ tôi sẽ dùng WebGL
    Tôi đã bán nó từ lâu, nhưng kèm điều kiện rằng dữ liệu phải luôn được giữ miễn phí. Ban đầu tôi không tin vì đề nghị qua email trông giống lừa đảo, nhưng mọi việc diễn ra suôn sẻ qua escrow.com, và tôi nghĩ cả hai bên đều kết thúc hài lòng. Giờ chuyện đó đã gần 20 năm trước

  • Có vẻ là phiên bản hiện đại của GeoIP dựa trên ping đã nhắc ở trên: https://github.com/Ne00n/yammdb

    • Vì nó chỉ liên kết đến một tệp mmdb đã biên dịch sẵn, nên nếu phần triển khai không được công khai thì không có nội dung liên quan nào để xem đó là một triển khai “hiện đại”

  • Muốn biết các đề xuất về cách định vị địa lý IP của trung tâm dữ liệu, dù chỉ rất xấp xỉ
    Đang phân tích dữ liệu traceroute và biết vị trí bắt đầu/kết thúc, nhưng phần quan tâm là các chặng trung gian
    Ví dụ có thể suy luận một phần thông tin từ mã sân bay có trong hostname của node
    Có vẻ cũng có thể suy luận vị trí bằng thời gian RTT trung bình, với giả định rằng trạng thái của một node cụ thể không quá tệ
    Các IP gây đau đầu làm ví dụ là 193.142.125.129, 129.250.6.113, 129.250.3.250. Chúng xuất hiện trong traceroute ở Anh và được cho là ở London, nhưng kết quả định vị địa lý lại rải khắp thế giới

    • Các IP đó thuộc sở hữu của Google và NTT, cả hai đều vận hành mạng quốc tế lớn nên nếu muốn có thể tái bố trí IP trên toàn thế giới. Vì vậy định vị địa lý dựa trên tra cứu vốn không ổn định, như đã thấy
      Traceroute tới các IP đó trông như mạng đang đi đến London
      IP của Google không phản hồi ping, nhưng phía NTT/Verio thì có. Nếu ping từ một hosting đặt tại London, rất có thể sẽ nhận được phản hồi ở mức vài mili giây một chữ số; khi đó có thể xác định được cận trên của khoảng cách từ London
      Cũng có thể ping từ các hosting khác trong Vương quốc Anh và từ bên kia eo biển để kiểm tra xem ping thấp nhất có đến từ hosting London hay không. Tuy nhiên có thể kết nối chỉ đi qua London còn vị trí thực lại ở nơi khác, nên không thể biết chắc hoàn toàn
      Cần kiểm tra từ các điểm quan sát khác nữa để xem có phải anycast hay không. Khi ping 8.8.8.8 từ hầu hết các mạng trên thế giới, bạn sẽ tới một nơi gần đó, nhưng traceroute tới các IP này từ cả khu vực Seattle cũng đi đến London, nên ít nhất hiện tại nhiều khả năng chúng không phải anycast
      Nếu không có hosting trên toàn thế giới, có thể tìm các looking glass công khai của những mạng có kết nối tốt để thỉnh thoảng thực hiện các lần ping như vậy
    • TULIP trông có triển vọng
      Tài liệu nói rằng “mục đích của TULIP là xác định vị trí của một host đích, được nhận diện bằng tên hoặc địa chỉ IP, bằng cách dùng các phép đo độ trễ ping RTT từ các host mốc tham chiếu có vị trí đã biết rõ tới đích”
      https://tulip.slac.stanford.edu/
      Nhưng endpoint để gửi có vẻ đã chết
    • Có một vài ý tưởng trong https://ensa.fi/papers/geolocation_imc17.pdf
      Cách lấy RTT từ các probe RIPE Atlas có vị trí đã biết tới IP đó khá gần với ý tưởng đã nói, và dù sao có lẽ cũng là phương pháp tốt nhất
    • Nếu vận hành một ứng dụng hoặc dịch vụ web phổ biến, bạn sẽ có số AS riêng, mua vài block IP dưới AS đó rồi quảng bá các địa chỉ ấy từ nhiều trung tâm dữ liệu sở hữu/thuê ở khắp thế giới
      Những quảng bá BGP như vậy sẽ đi ra các ISP upstream khác nhau ở nhiều vị trí
      Nếu upstream của quảng bá từ một vị trí cụ thể là ISP khu vực, có thể suy đoán ở mức nào đó rằng trung tâm dữ liệu đó nằm trong khu vực ấy. Nhưng nếu đó là ISP Tier 1 cung cấp kết nối trực tiếp toàn cầu thì ngay cả suy đoán đó cũng khó
      Có thể xem quan hệ BGP bằng các công cụ looking glass như bgp.tools: https://bgp.tools/prefix/193.142.125.0/24#connectivity
      Nếu có thể chạy traceroute từ nhiều probe có vị trí đã biết rải khắp thế giới, có thể nhìn vào IP cố định của các interface router trung gian để tam giác hóa
      Tuy nhiên nếu dùng CDN như Cloudflare để quảng bá block IP của mình từ hơn 200 PoP, rồi cho lưu lượng đi qua mạng riêng của họ tới các trung tâm dữ liệu trên toàn cầu, phương pháp này cũng sẽ bị phá vỡ