Une vérification TCP depuis le Danemark tente une connexion vers votre hôte sur le port spécifié et enregistre la durée de la négociation. Elle passe par les mêmes règles de pare-feu et politiques de routage que le vrai trafic applicatif, contrairement au ping ICMP. C'est le bon outil pour confirmer qu'un port de service spécifique — pas seulement l'hôte — est accessible depuis l'infrastructure réseau danoise.

Les FAI danois n'appliquent typiquement pas de filtrage au niveau des ports sur le trafic des centres de données ou des entreprises. La raison la plus courante d'un échec TCP depuis le Danemark est côté serveur : règles de géo-blocage, politiques de pare-feu bloquant les ASN non locaux, ou groupes de sécurité configurés pour n'autoriser que des plages IP spécifiques. AS42708 (Glesys) est un fournisseur d'hébergement nordique bien connu et ses plages IP ne figurent pas couramment sur les listes de blocage d'abus ou de renseignement sur les menaces, donc un échec TCP depuis ce nœud pointe généralement vers un problème de configuration sur la cible plutôt que sur la source.

Si un port est joignable depuis d'autres pays nordiques mais échoue spécifiquement depuis le Danemark, il vaut la peine de vérifier si le serveur cible a un blocage IP spécifique au Danemark en place, ou si le chemin de routage entre AS42708 et l'amont de la cible implique un intermédiaire qui abandonne le trafic. Exécuter une vérification MTR aux côtés de la vérification TCP depuis le Danemark vous donne le détail saut par saut pour localiser l'endroit où l'échec se produit.

Copenhague est le principal hub internet du Danemark et fonctionne comme un carrefour de routage entre la Scandinavie, la région baltique et l'Europe centrale. Netnod exploite un IX à Copenhague aux côtés de son infrastructure stockholmoise, et le Danish Internet Exchange (DIX) fournit une alternative de peering gérée par la communauté. Ensemble, ils font de Copenhague un emplacement bien connecté pour les réseaux qui ont besoin de peeriser avec les FAI nordiques et baltiques sans router d'abord via Francfort ou Amsterdam.

Le Danemark relie la péninsule scandinave et le continent européen via sa connexion terrestre par le Jutland en Allemagne. Cette géographie signifie que Copenhague dispose de chemins à faible latence vers Stockholm (environ 20 ms) et Hambourg (environ 17 ms), lui donnant une portée naturelle dans les deux directions. Les liens trans-Øresund vers Malmö maintiennent la latence vers le sud de la Suède bien en dessous de 10 ms. Plusieurs câbles sous-marins connectent le Danemark au Royaume-Uni, à la Norvège et aux États baltiques, offrant une diversité de chemins pour le trafic international.

Notre nœud sonde de Copenhague fonctionne sur AS42708, exploité par Glesys AB. Glesys est un fournisseur d'hébergement et d'infrastructure suédo-nordique avec une présence de centres de données à Stockholm, Göteborg et Copenhague. L'emplacement de Glesys à Copenhague dans leur installation de la municipalité de Glostrup donne au nœud sonde une bonne connectivité amont vers l'écosystème d'hébergement nordique plus large. AS42708 annonce des routes via Netnod et dispose d'accords de transit couvrant les destinations nordiques et d'Europe centrale.

Le marché de l'hébergement danois comprend des opérateurs locaux et des fournisseurs internationaux. TDC (AS3292) est l'opérateur national historique et exploite une part significative du backbone danois. Telia (AS1299) et Telenor (AS2119) fournissent une capacité de transit supplémentaire. Le trafic à forte consommation de bande passante — streaming vidéo, charges de travail cloud — route souvent via Equinix Copenhague, où les CDN et fournisseurs cloud maintiennent des nœuds de cache ou de bord locaux pour servir les utilisateurs danois sans extraire le contenu de centres de données plus distants.

Pour les opérateurs ciblant les utilisateurs danois, Copenhague est l'emplacement de test naturel. Un serveur hébergé à Copenhague ou peerisé chez DIX ou Netnod CPH devrait atteindre la plupart des utilisateurs résidentiels danois bien en dessous de 15 ms. Un serveur à Francfort ajoute 35–45 ms pour les utilisateurs danois avant de tenir compte de toute variation de dernier kilomètre. Le placement du bord CDN à Copenhague ou à Malmö voisine fait une différence matérielle pour les applications sensibles à la latence desservant le marché danois.