Encore un autre projet d'outils pour le diplôme
Avant de commencer, essayez de tester les fonctions de base. Parmi tous les modules, les pièces typiques à tester sont les trois implémentations serveur / proxy:
$ cd /path/to/project/root/directory
$ PYTHONPATH=. python3 server/static_file.py > log/static.log
$ PYTHONPATH=. python3 server/fastcgi_proxy.py > log/fastcgi.log
$ PYTHONPATH=. python3 server/http_proxy.py > log/http.log En raison de la vitesse de connexion lente de httpbin.org, vous devrez peut-être utiliser ProxyChain pour accélérer les tests de HTTPProxy , et peut-être une erreur comme proxychains can't load process pourrait se produire si votre terminal utilise Dash comme le shell par défaut, dans ce cas, il suffit de spécifier le shell avec bash -c "python3 file.py" , les commandes complètes sont répertoriées en dessous respectivement:
$ PYTHONPATH=. proxychains4 python3 server/http_proxy.py > log/http.log
$ PYTHONPATH=. proxychains4 bash -c " python3 server/http_proxy.py > log/http.log " Enfin, vous pouvez modifier les configurations dans config/config.yaml , puis démarrer le serveur principal et visiter le site pour voir si tout fonctionne bien:
$ PYTHONPATH=. python3 main.py Remarque que host:port par défaut est localhost:80 , et pour lier ce type de ports "privilégiés" (1-1023) avec l'utilisateur non root, vous devrez définir capability de Python Binary, Say /usr/bin/python3 :
$ sudo setcap ' cap_net_bind_service=+ep ' /usr/bin/python3 Vérifiez les journaux sous log/ si vous le souhaitez, main.log enregistrera le processus complet de toutes les demandes et réponses, tandis que (static|fastcgi|http).log sont les résultats des tests mentionnés précédemment.
Tous les tests ci-dessus, y compris les tests d'autres modules, sont désormais écrits comme un script d'assistance dans modtests.sh , que vous pouvez directement exécuter et voir les résultats. Vous pouvez utiliser tee pour dupliquer les sorties dans un fichier journal et les vérifier plus tard:
$ ./modtests.sh 2>&1 | tee modtests.log Le module FastCGiProxy de Project communique avec FastCGI à l'aide de cgi-fcgi , qui peut être installé par apt-get install libfcgi0ldbl sur Debian Series ou yum --enablerepo=epel install fcgi sur la série CentOS.
Si vous utilisez application comme projet de démonstration, les dépendances PHP suivantes sont nécessaires:
php-mysql pour la connexion de la base de donnéesphp-gd pour la génération d'images captchaphp-fpm pour courir avec FastCGI comme socket Unix La taille de tampon readbuf.first est supposée être suffisamment grande pour lire l'intégralité de la partie de tête HTTP, car le programme utilise la valeur d'en-tête pour déterminer s'il y a encore une pièce gauche à recevoir, et si elle est vraie, lisez les autres en utilisant la taille de tampon readbuf.left .
Paramètre fastcgi.upstream peut être configuré sur un host:port ou un fichier de sockain de domaine Unix, cependant, il existe un problème inconnu en utilisant cgi-fcgi avec une prise de domaine UNIX sur la plate-forme WSL: le processus exécuté avec une grande entrée de STDIN par Pipe termina avec le code de sortie 11 et la sortie sans contenu, tandis qu'une taille d'entrée qui est un peu plus grande de 65536 étant toujours gérée. Donc, s'il est nécessaire de télécharger des fichiers volumineux et que le projet est déployé sur WSL, utilisez TCP au lieu de la prise de domaine UNIX comme FastCGI en amont.
De plus, il y a un module de minuterie et un module de travail à essayer, qui sont écrits à des fins d'apprentissage, et pour être rappelé, ce dernier n'est pas stable.
Les fichiers du module de temporisation sont tous situés sous le timer du répertoire, implémentés avec un tas K-Ay ou un arbre rouge-noir comme structure de données. Le code du module de travailleur est dans le répertoire worker , la conception est inspirée par l'arbitre de Gunicorn et la mise en œuvre n'est pas garantie de fonctionner comme prévu si vous envoyez des signaux trop rapidement, auquel cas vous devez être conscient des processus de zombies laissés.
Voir les versions