Object Storage Service:Domain name access and network connection overview

HTTPS

Les noms de domaine des buckets OSS prennent en charge l'accès HTTPS par défaut, sans configuration supplémentaire. Lorsque vous accédez à OSS via un nom de domaine personnalisé, vous devez configurer un certificat SSL pour ce domaine. Si CDN n'est pas activé, configurez Upload Certificate pour le nom de domaine personnalisé mappé au bucket dans la console OSS. Si CDN est activé, configurez un SSL Certificate pour le nom de domaine CDN dans la console CDN. Pour les environnements de production, nous recommandons d'imposer l'accès HTTPS avec une politique de bucket qui refuse toutes les requêtes HTTP. Les certificats SSL Alibaba Cloud prennent en charge le renouvellement automatique grâce à l'hébergement de certificats. Pour plus d'informations, consultez la rubrique Accéder à OSS via HTTPS.

PrivateLink

PrivateLink crée un endpoint privé dédié pour OSS au sein de votre Virtual Private Cloud (VPC). Tout le trafic transite par le réseau dorsal d'Alibaba Cloud plutôt que par l'internet public. Cette approche offre une isolation de sécurité plus robuste que le nom de domaine interne OSS par défaut.

Connectez vos appareils ou centres de données sur site à votre VPC via un circuit SSL-VPN ou Express Connect pour accéder à OSS par le biais de PrivateLink. Pour plus d'informations, consultez la rubrique Accéder à OSS via un réseau privé à l'aide de PrivateLink.

Protection contre le hotlinking

Si d'autres sites web utilisent vos ressources OSS via des liens directs (hotlinking), augmentant ainsi vos coûts de trafic, vous pouvez configurer des listes noires et blanches basées sur le Referer pour contrôler l'accès. OSS applique le contrôle d'accès selon l'ordre de priorité suivant : empty Referer check > blacklist check > whitelist check. La protection contre le hotlinking s'applique uniquement à l'accès anonyme et aux URL signées. Cette restriction ne s'applique pas aux appels API signés avec un AccessKey. Si vous utilisez l'accélération CDN pour OSS, vous devez également configurer des règles de protection contre le hotlinking au niveau de la couche CDN. Sinon, les requêtes de hotlinking pourraient atteindre le cache CDN et contourner la vérification OSS. Pour plus d'informations, consultez la rubrique Protection contre le hotlinking.

Proxy inverse ECS

OSS fournit des adresses IP dynamiques via la résolution DNS. Cette dynamique peut compliquer la mise sur liste blanche des pare-feu et certaines intégrations système. Vous pouvez déployer un proxy inverse Nginx sur une instance ECS disposant d'une adresse IP publique statique pour transférer les requêtes vers OSS. Cela vous permet d'accéder aux ressources OSS via une adresse IP fixe. Pour les environnements de production, nous recommandons une architecture haute disponibilité utilisant un équilibreur de charge avec un groupe d'instances ECS réparti sur plusieurs zones de disponibilité. Pour plus d'informations, consultez la rubrique Accéder à OSS à l'aide d'un proxy inverse ECS.

Point d'accès

Un point d'accès fournit un point d'entrée dédié pour un bucket. Lorsque plusieurs applications ou équipes ayant différents niveaux d'autorisation doivent accéder au même bucket, vous pouvez créer un point d'accès distinct pour chacune d'elles. Cela vous permet de gérer les autorisations individuellement via des politiques de point d'accès, évitant ainsi des règles complexes dans une seule politique de bucket. Chaque point d'accès possède son propre alias, sa politique d'accès et sa configuration d'origine réseau (internet public ou VPC spécifié). Il prend en charge l'authentification fédérée avec les politiques RAM et les politiques de bucket dans un modèle de politique à trois couches. Pour plus d'informations, consultez la rubrique Point d'accès.

Hébergement de site web statique

OSS vous permet de publier des fichiers statiques (tels que HTML, CSS et JavaScript) stockés dans un bucket directement sous forme de site web accessible publiquement, sans nécessiter de maintenance de serveur. Vous pouvez configurer une page d'accueil par défaut, des pages d'accueil pour les sous-répertoires et une page d'erreur 404 personnalisée. Il prend également en charge le routage pour les applications monopages (SPA) en définissant la page 404 sur index.html et le code de réponse d'erreur sur 200. Pour plus d'informations, consultez la rubrique Hébergement de site web statique.

Configuration CORS

Lorsque votre site web charge des ressources depuis OSS, le navigateur peut signaler une erreur blocked by CORS policy . Cela est dû à la politique de même origine du navigateur, qui restreint l'accès aux ressources cross-origin. En configurant des règles CORS pour votre bucket (telles que Origin , Allowed Methods et Allowed Headers ), vous pouvez autoriser des sites web spécifiques à accéder à vos ressources OSS. Lors de l'utilisation de plusieurs sources ou de caractères génériques, activez Vary: Origin pour éviter la pollution du cache. Si votre bucket utilise l'accélération CDN, vous devez soit configurer des règles cross-origin dans la console CDN, soit paramétrer CDN pour transmettre les en-têtes de réponse CORS provenant d'OSS. Pour plus d'informations, consultez la rubrique Configuration CORS.

Accès avec des URL non signées à long terme

Vous pouvez utiliser l'une des méthodes suivantes :

• Définir l'ACL de l'objet sur public-read : Toute personne peut accéder à l'objet sans restriction. Pour éviter des coûts supplémentaires liés à une utilisation non autorisée, veillez à configurer la protection contre le hotlinking afin de restreindre les sources d'accès.

• Accéder à OSS via l'accélération CDN : Conservez l'autorisation de l'objet en mode privé et activez la fonctionnalité de retour à la source pour bucket privé de CDN afin de fournir un accès public. CDN offre de meilleures performances d'accès et de mise en cache. Vous devez configurer des règles de protection contre le hotlinking au niveau de la couche CDN pour prévenir toute utilisation non autorisée.

Résoudre les problèmes de lenteur lors des uploads ou downloads

La vitesse de transfert OSS dépend de la bande passante du réseau client, de la qualité de la liaison et de la stratégie de transfert. Suivez les directives ci-dessous pour diagnostiquer et optimiser les performances :

• Bande passante et qualité de la liaison : Vérifiez que votre bande passante actuelle ne dépasse pas la limite de bande passante du bucket. Utilisez un outil MTR pour analyser la liaison réseau et détecter toute perte de paquets, latence élevée ou anomalie de routage. Pour les transferts transfrontaliers ou sur de longues distances, nous recommandons d'activer l'accélération de transfert .

• Sélection de l'outil : Utilisez ossutil pour transférer des fichiers volumineux ou nombreux. Vous pouvez utiliser sa commande probe pour vérifier l'état actuel du réseau.

• Optimisation du SDK : Pour les fichiers volumineux, utilisez toujours l'upload multipart et l'upload resumable . Configurez adéquatement la taille des parties (part_size ) et le nombre de threads simultanés (num_threads ). Sur un réseau de bonne qualité, augmentez la taille des parties pour réduire le nombre de requêtes. Lors de l'initialisation du client, vous pouvez désactiver la validation CRC64 (par exemple, définir enable_crc=False en Python) et utiliser l'en-tête de requête Content-MD5 pour les vérifications d'intégrité. Cela peut améliorer les performances de transfert tout en garantissant la sécurité des données.

Résoudre les erreurs réseau

Si la requête a atteint OSS (la réponse contient un ID de requête), obtenez l'ID de requête et utilisez l'outil de diagnostic en libre-service OSS pour effectuer une vérification.

Si la requête n'a pas atteint OSS (l'ID de requête est vide), procédez au dépannage en fonction du type d'erreur :