Quelle est la taille de fichier maximale que je peux transférer avec HTTP? Et en utilisant FTP?
Ajouté : Je réalise une étude sur un nouveau système que nous allons développer dans mon travail. Il consiste à authentifier les utilisateurs, à afficher les fichiers qu’ils veulent télécharger et à les télécharger. De plus, si les fichiers ne sont pas facilement disponibles, l'utilisateur ne peut pas les télécharger, mais le serveur obtient une copie du fichier demandé et l'informe par courrier électronique lorsqu'il peut récupérer le fichier. Nous nous attendons à ce que les fichiers atteignent typiquement entre 2 et 50 gigaoctets, pour le moment.
Je veux juste vérifier s'il est possible d'écrire une application Web pour résoudre le problème ou s'il faut créer une solution client-serveur.
Il n'y a pas de maximum. Tout ce que vous rencontrez est spécifique à une application ou à un site.
J'ai téléchargé les DVD isos de Microsoft en utilisant HTTP et FTP sans problème (~ 4 Go).
J'ai également téléchargé d'énormes fichiers via les deux méthodes.
Pouvez-vous préciser ce que vous essayez de faire?
Comme déjà répondu, le protocole n'a pas de limites, mais la plupart des serveurs HTTP serveurs ont des limites de téléchargement par défaut prêtes à l'emploi:
IIS6 utilise MaxRequestEntityAllowed (4 Go par défaut) et AspMaxRequestEntityAllowed (200000 octets par défaut) dans metabase.xml .
IIS7 utilise maxRequestEntityAllowed : ** appcmd set config/section: asp/maxRequestEntityAllowed: *** int * (la valeur par défaut est 200 000 octets)
Apache utilise LimitRequestBody (2 Go par défaut)
Vous avez dit qu'il n'y avait pas de limitation de ce type dans les protocoles. Seuls les délais sur des serveurs concrets
Et une question importante - allez-vous télécharger ou télécharger?
Je pourrais dire que le téléchargement a beaucoup moins de limitations que le téléchargement. Je ne sais pas pourquoi. Peut-être parce que le but principal de HTTP et FTP est d'envoyer des données, pas de les recevoir.
C'est pourquoi les serveurs HTTP/FTP pourraient interrompre la session de téléchargement plus souvent que la session de téléchargement.
Étant donné que la taille d'un transfert est probablement indiquée vers le début, je parierais que la limite de la taille de votre fichier est la même que celle d'un entier non signé. À en juger par la période où HTTP et FTP sont devenus populaires et utiles, je dirais que c'est un entier non signé 32 bits, donc 2 ^ 32 octets, ou 4.0 GiB .
Le téléchargement dans HTTP est généralement limité car le serveur doit attendre que le téléchargement (généralement lent) soit terminé pour répondre à la demande.
Pour le protocole TCP, vous avez un numéro de séquence compris entre 0 et 2 ^ 32-1 . Supposons le pire cas lorsque vous augmentez la séquence de 1 pour chaque octet . La taille de fichier maximale est maintenant de 4 Go. Et vous avez une connexion de 1 Go/s . Toutes les séquences se terminent en 4 secondes, ce qui correspond à l'heure ... .. Si. TTL est supérieur à l'heure, nous ne pouvons donc pas réutiliser la séquence si la taille maximale du fichier est de 4 Go.
Mais Magic est dans TCP Options, dans les options, nous pouvons ajouter un horodatage. Maintenant, le problème est résolu même si nous obtenons avec la même source et la même destination le même numéro de séquence mais que nous avons un horodatage différent à identifier.