Downloaden van grote bestanden op server

[radem205]

Hey,

Voor een file sharing website wil ik gebruikers de mogelijkheid bieden om grote bestanden (tot 1 gb) te uploaden om andere mensen in de gelegenheid te stellen deze bestanden te downloaden middels een unieke link die in een e-mail wordt verzonden (dus soortgelijk als Yousendit.com).

De bestanden zullen geupload worden middels een normale http request, wat wellicht voor problemen gaat zorgen bij grote bestanden (echter heb ik de beschikking over krachtige servers, en volledige controle over de servers).

Maar mijn probleem zit 'm nu meer in het downloaden van de bestanden. De bestanden dienen afgeschermd te worden, zodat niet iedereen de bestanden kan downloaden (logisch natuurlijk).

Een goede methode om de bestanden te downloaden lijkt mij via een FTP connectie, echter moet wel eerst gecontroleerd worden door PHP of de gebruiker de juiste rechten heeft om het betreffende bestand te downloaden.
Mijn uitdaging zit 'm dus vooral in de combinatie van de PHP controle en via FTP downloaden.

Mogelijkheden die er zijn (ik hoop dat jullie nog enkele mogelijkheden kunnen aandragen):

PHP controle -> Betreffende bestand in unieke map zetten -> Via FTP bestand downloaden
Nadeel hiervan is dat het bestand on the fly verplaatst moet worden. Het bestand is hierdoor ook verdwenen uit de oorspronkelijke map, wat betekent dat het bestand niet nogmaals gedownload kan worden

PHP controle -> Via FTP bestand downloaden
Op deze manier zal PHP redirecten naar de FTP locatie, echter heb je dan het probleem dat wanneer een gebruiker een bestandsnaam weet, een bestand kan downloaden van de server (dus een beveiligingsprobleem).

PHP controle -> Via FTP bestand downloaden uit unieke map
Dit is misschien wel de beste methode. Na het uploaden wordt een unieke map aangemaakt (bijvoorbeeld een md5 hash of middels een uniqid() ) en hier wordt dan het bestand in geplaatst.
Middels PHP wordt het betreffende bestand opgehaald. 100% veilig is het niet, maar de kans dat iemand andermans bestand download wordt wel zeer gering.

Nu is mijn vraag of jullie nog betere methoden weten en / of jullie nog tips hebben om zo'n soort systeem op te zetten ten aanzien van het uploaden en downloaden van grote bestanden.

Bedankt!

[NetForce1]

Waarom niet gewoon downloaden via http? Dan kun je gewoon de beveiliging middels PHP afhandelen, en heb je al deze problemen niet.

[radem205]

NetForce1 schreef op woensdag 20 oktober 2010 @ 22:06:
Waarom niet gewoon downloaden via http? Dan kun je gewoon de beveiliging middels PHP afhandelen, en heb je al deze problemen niet.

Mijn twijfel is voornamelijk: is dit stabiel genoeg bij grote bestanden (tot 1gb)? FTP is gemaakt voor bestandsoverdracht, waarbij ik het gevoel heb dat het stabieler en beter is (heb nog geen echte vergelijkingen kunnen vinden op internet).

En een map met de bestanden beveiligen middels htaccess, betekent dat je met php het hele bestand (tot 1gb) moet inladen (readfile, of iets dergelijks) en ter download aanbieden middels een header, of kan dit ook anders?

[ Voor 17% gewijzigd door radem205 op 20-10-2010 22:11 ]

[NetForce1]

radem205 schreef op woensdag 20 oktober 2010 @ 22:08:
[...]


Mijn twijfel is voornamelijk: is dit stabiel genoeg bij grote bestanden (tot 1gb)? FTP is gemaakt voor bestandsoverdracht, waarbij ik het gevoel heb dat het stabieler en beter is (heb nog geen echte vergelijkingen kunnen vinden op internet).

En een map met de bestanden beveiligen middels htaccess, betekent dat je met php het hele bestand (tot 1gb) moet inladen (readfile, of iets dergelijks) en ter download aanbieden middels een header, of kan dit ook anders?

htaccess lijkt met niet de meest handige manier om zo'n site te beveiligen, maar dat terzijde. Het lijkt me dat php toch wel data moet kunnen streamen naar client. Dus elke n gelezen bytes meteen doorsturen, zonder deze allemaal in geheugen te houden tot de complete response klaar is.

[radem205]

NetForce1 schreef op woensdag 20 oktober 2010 @ 22:13:
[...]

htaccess lijkt met niet de meest handige manier om zo'n site te beveiligen, maar dat terzijde. Het lijkt me dat php toch wel data moet kunnen streamen naar client. Dus elke n gelezen bytes meteen doorsturen, zonder deze allemaal in geheugen te houden tot de complete response klaar is.

Welke methode is beter om de bestanden te beveiligen in jouw ogen? Buiten de root plaatsen?

[Soultaker]

FTP is een enigzins archaïsch protocol dat uitgaat van een open, welwillend internet. Het werkt bijzonder slecht in de werkelijke wereld met encryptie, firewalls, NAT en authorizatie (anders dan authenticatie m.b.v een gebruikersnaam en wachtwoord). Ik ben het dus eens met NetForce1 dat HTTP waarschijnlijk veel beter geschikt is dan FTP. Ik zou tegenwoordig FTP alleen aanraden voor publiek toegankelijke bestanden, als je dus geen authenticatie of beveiligde transmissie nodig hebt.

Hoewel je gelijk hebt dat FTP oorspronkelijk bedoeld was voor bestandsoverdracht, is HTTP daar tegenwoordig simpelweg veel beter geschikt voor. Het is niet inherent minder stabiel dan FTP, maar biedt wel als voordeel dat je authorizatie op een uniforme manier kunt regelen (inloggen op de website, en dezelfde sessie gebruiken voor authorizatie van downloads).

Het enige voordeel van FTP vanuit een gebruikersperspectief is dat niet alle HTTP clients even goed het resumen van afgebroken downloads ondersteunen. Firefox ondersteunt dat in ieder geval wel, maar verder zou je eens moeten uitzoeken of andere mainstream browsers dat ook ondersteunen. In dat geval is er weinig reden om FTP boven HTTP te verkiezen, naar mijn mening.

[NetForce1]

radem205 schreef op woensdag 20 oktober 2010 @ 22:15:
[...]


Welke methode is beter om de bestanden te beveiligen in jouw ogen? Buiten de root plaatsen?

idd, en dan authenticatie met bijv. een form op een webpage.

.edit: wat Soultaker zegt dus

[ Voor 5% gewijzigd door NetForce1 op 20-10-2010 22:18 ]

[radem205]

NetForce1 schreef op woensdag 20 oktober 2010 @ 22:17:
[...]

idd, en dan authenticatie met bijv. een form op een webpage.

Authorisatie zal plaatsvinden met een (goede) uniqid() (of iets dergelijks) in de download link. Dit is dus eigenlijk een wachtwoord die meegestuurd wordt in de link.

Bij mijn weten zal streamen niet bij elk bestandstype lukken, of is dit wel het geval?

En wanneer je een bestand buiten de root plaats zal via php middels de goede headers en readfile (of iets soortgelijks) het bestand ingelezen moeten worden en worden geserveerd aan de gebruiker. Maar hoe gaat readfile om met zeer grote bestanden? Deze plaatst de data toch niet direct in het geheugen of wel?

[ Voor 4% gewijzigd door radem205 op 20-10-2010 22:23 ]

[job]

Edit: is al gezegd.

[ Voor 91% gewijzigd door job op 20-10-2010 22:23 ]

[NetForce1]

radem205 schreef op woensdag 20 oktober 2010 @ 22:21:
[...]
Bij mijn weten zal streamen niet bij elk bestandstype lukken, of is dit wel het geval?

En wanneer je een bestand buiten de root plaats zal via php middels de goede headers en readfile (of iets soortgelijks) het bestand ingelezen moeten worden en worden geserveerd aan de gebruiker. Maar hoe gaat readfile om met zeer grote bestanden? Deze plaatst de data toch niet direct in het geheugen of wel?

Waarom zou streamen voor sommige bestanden niet lukken? Een byte is een byte toch?

Ik ben niet zo thuis in PHP, maar readfile lijkt wel ongeveer te doen wat je wilt. Je zult alleen nog wel support in moeten bouwen voor clients die bij een bepaalde offset willen beginnen (download managers).

[radem205]

NetForce1 schreef op woensdag 20 oktober 2010 @ 22:27:
[...]

Waarom zou streamen voor sommige bestanden niet lukken? Een byte is een byte toch?

Ik ben niet zo thuis in PHP, maar readfile lijkt wel ongeveer te doen wat je wilt. Je zult alleen nog wel support in moeten bouwen voor clients die bij een bepaalde offset willen beginnen (download managers).

Het lijkt er op dat readfile het bestand wel helemaal in het geheugen zet, wat bij grote bestanden dus "not done" is. Is het wellicht beter om de bestanden in een md5 gehashte map zetten en zo de bestanden aan te bieden aan de gebruiker? Dit zal sowieso het snelst werken, maar hiermee gaat wel wat veiligheid verloren.

[Verwijderd]

Readfile gaat prima werken bij alle type (grote) bestanden. Je moet alleen de juiste HTTP headers mee sturen. Zie het voorbeeld in de PHP handleiding hiervoor.

Van FTP zou ik afblijven dit geeft teveel problemen.

[edit]
Readfile zet de bestanden niet in het geheugen. Wat dacht je er van om het gewoon te testen?

[ Voor 19% gewijzigd door Verwijderd op 20-10-2010 22:40 ]

[NetForce1]

radem205 schreef op woensdag 20 oktober 2010 @ 22:32:
[...]
Het lijkt er op dat readfile het bestand wel helemaal in het geheugen zet, wat bij grote bestanden dus "not done" is. Is het wellicht beter om de bestanden in een md5 gehashte map zetten en zo de bestanden aan te bieden aan de gebruiker? Dit zal sowieso het snelst werken, maar hiermee gaat wel wat veiligheid verloren.

Waarom denk je dat bestanden in het geheugen geplaatst worden? Als ik de documentatie lees krijg ik nl het tegenovergestelde idee. Hoe dan ook, ik geloof gewoon niet dat er geen manier is om met php een file te streamen naar de client. Doe eens een Google-search, er zijn vast wel meer mensen die zoiets gemaakt hebben.

[Gomez12]

Alternatief wat ik nog weleens bij andere pakketten heb gezien is gewoon dat php een hard-link op FS nivo aanmaakt. Hierna handelt de webserver het hele verdere traject af.

Btw, wat is zo ongeveer de geschatte grootte van de dienst? Want daar hangt nogal redelijk wat vanaf. Met grote bestanden krijg je lang openstaande connecties.
500 clients zijn dan ook zo goed als altijd 500 concurrent users.
Als elke client een php-instantie en een webserver-connectie openhoud dan heb je redelijk wat processen draaien die "niks" zitten te doen behalve geheugenruimte en threads innemen.

De "grotere" diensten houden het daarom ook zo simpel mogelijk.
5000 bestandjes van 1 Gb concurrent versturen is op zich namelijk simpel en licht.
5000 bestandjes van 1 Gb concurrent versturen met een authenticatie-laag en gelockte sessiebestanden etc is een redelijk recipe for disaster.
Zoek hier dus een mix in.

Dit soort dingen hangt 100% op goed voorbereide simpele uitvoeringen en ongeveer 0% echt op hardware.

[Soultaker]

Als je efficiënt grote bestanden wil sturen en daarbij ook het resumen van downloads (via de HTTP Range header) wil ondersteunen is readfile() helaas niet geschikt, want daarmee kun je alleen een heel bestand versturen. Er zijn twee voor de hand liggende manier om dat te doen.

Ten eerste is er file_get_contents(), die gebruik maakt van memory mapping om te voorkomen dat het hele bestand in het geheugen geladen moet worden. Met file_get_contents() kun je bovendien eenvoudig alleen het gewenste deel van het bestand inladen.

Ten tweede kun je natuurlijk fopen() en fread() gebruiken om in een lusje het bestand in stukjes van 32KB ofzo in te lezen en te versturen. Onder de comments van die pagina over readfile() staat daar wel een goed voorbeeld van, waarbij ook de HTTP Range header wordt gerespecteerd. (Ironisch dat dat voorbeeld juist op die pagina staat, terwijl readfile() dan niet gebruikt wordt).

[RobIII]

Het stikt gewoon van de kant-en-klare voorbeelden in de comments (de een beter dan de ander weliswaar). Met wat doorzettingsvermogen moet je daar prima een eigen oplossing uit kunnen destileren.

[ Voor 11% gewijzigd door RobIII op 20-10-2010 23:01 ]

[Verwijderd]

readfile() output de file direct naar de output buffer die maximaal een paar K groot is. Zodra hij vol is zal de data worden verzonden. PHP zal echt niet een bestand van 1GB in het geheugen laten voor de tijd dat het nodig heeft om deze te versturen.

Je opmerking over resumen is natuurlijk helemaal terecht.

Met het zelf inlezen van kleine blokjes kun je natuurlijk ook andere leuke dingen doen zoals een bandbreedte limiet hanteren.

[Soultaker]

RobIII schreef op woensdag 20 oktober 2010 @ 23:00:
Het stikt gewoon van de kant-en-klare voorbeelden in de comments (de een beter dan de ander weliswaar). Met wat doorzettingsvermogen moet je daar prima een eigen oplossing uit kunnen destileren.

Op zich mee eens, en je kunt er wel inspiratie opdoen, maar kopieer alsjeblieft niet blind code van de user comments op PHP.net. De kwaliteit... varieert, zullen we maar zeggen.

(Sowieso is het aan te raden om geen code over te nemen die je zelf niet begrijpt, maar dat geldt dubbel als de bron geen of nauwelijks kwaliteitscontrole kent.)

[Wolfboy]

In plaats van dit geheel met PHP te doen kan je het ook regelen via je webserver. Bij Nginx heb je bijvoorbeeld de x-accel-redirect mogelijkheid die je het echte bestand teruggeeft.

Docs: http://wiki.nginx.org/NginxXSendfile

[Gomez12]

Wolfboy schreef op donderdag 21 oktober 2010 @ 00:04:
In plaats van dit geheel met PHP te doen kan je het ook regelen via je webserver. Bij Nginx heb je bijvoorbeeld de x-accel-redirect mogelijkheid die je het echte bestand teruggeeft.

Docs: http://wiki.nginx.org/NginxXSendfile

Nice, dan schakel je dus heel php uit als iemand eenmaal authorised is en je webserver produceert zelf het bestand.

[Wolfboy]

Gomez12 schreef op donderdag 21 oktober 2010 @ 00:19:
[...]

Nice, dan schakel je dus heel php uit als iemand eenmaal authorised is en je webserver produceert zelf het bestand.

Indedaad
Je hoeft alleen een header door te geven en het werkt.

Voor Apache heb je zo ook mod_xsendfile: https://tn123.org/mod_xsendfile/

Ik weet uit ervaring dat je zelfs met lichte servers op die manier makkelijk een gigabit verbinding vol trekt voor je cpu aan z'n max zit. De harde schijven en de netwerkverbinding zijn de enige limiet met zo'n oplossing. Ook bij gigantische bestanden (denk aan 10GB+)

[ Voor 4% gewijzigd door Wolfboy op 21-10-2010 00:26 ]

[Cartman!]

Soultaker schreef op woensdag 20 oktober 2010 @ 22:17:
FTP is een enigzins archaïsch protocol dat uitgaat van een open, welwillend internet. Het werkt bijzonder slecht in de werkelijke wereld met encryptie, firewalls, NAT en authorizatie (anders dan authenticatie m.b.v een gebruikersnaam en wachtwoord). Ik ben het dus eens met NetForce1 dat HTTP waarschijnlijk veel beter geschikt is dan FTP. Ik zou tegenwoordig FTP alleen aanraden voor publiek toegankelijke bestanden, als je dus geen authenticatie of beveiligde transmissie nodig hebt.

Pardon? Bij FTP kun je gewoon gebruik maken van encryptie, ip-checks, user/password, public/private keys en de hele rambam.

In dit specifieke geval zou ik ook HTTP gebruiken maar naar mijn idee doe je FTP nu echt tekort.

[radem205]

Wolfboy schreef op donderdag 21 oktober 2010 @ 00:25:
[...]
Indedaad
Je hoeft alleen een header door te geven en het werkt.

Voor Apache heb je zo ook mod_xsendfile: https://tn123.org/mod_xsendfile/

Ik weet uit ervaring dat je zelfs met lichte servers op die manier makkelijk een gigabit verbinding vol trekt voor je cpu aan z'n max zit. De harde schijven en de netwerkverbinding zijn de enige limiet met zo'n oplossing. Ook bij gigantische bestanden (denk aan 10GB+)

Dit lijkt mij een hele mooie oplossing. Nu komen de bestanden waarschijnlijk op een aparte server te staan, waardoor het opvragen van het bestand via server 1 verloopt en het bestand op server 2 staat.

Is het mogelijk om via X-Sendfile ook bestanden op een andere server op te vragen en ter download aan te bieden?
Omdat de servers nog niet direct beschikbaar zijn, is het nog lastig om het één en ander te testen.

[RobIII]

radem205 schreef op donderdag 21 oktober 2010 @ 11:39:
Is het mogelijk om via X-Sendfile ook bestanden op een andere server op te vragen en ter download aan te bieden?
Omdat de servers nog niet direct beschikbaar zijn, is het nog lastig om het één en ander te testen.

Je zou voor de gein eens een keer wat documentatie kunnen lezen of het testen. Ook al heb je de uiteindelijke servers niet beschikbaar, een testsituatie is simpel op te zetten (doe eens gek en pak een VM). Dat iets "lastig" is wil niet zeggen dat je 't zelf niet even kunt proberen. Ik begin, to be honest, dit helpdesk gedrag aardig beu te worden.

[ Voor 24% gewijzigd door RobIII op 21-10-2010 12:15 ]