125 lines
4.8 KiB
Markdown
125 lines
4.8 KiB
Markdown
# Rapport du TP 1
|
||
Réalisé par Thibaut Rochas et Tuan Minh VU
|
||
|
||
https://gitlab2.istic.univ-rennes1.fr/trochas/tp1.http
|
||
|
||
Le 4 février 2025
|
||
|
||
## Partie I: Le classique serveur Echo
|
||
|
||
### EXERCICE 1 : Version séquentielle
|
||
|
||
Nous nous sommes inspirés du cours pour implémenter le serveur écho.
|
||
|
||
### EXERCICE 2 : Test et capture
|
||
Après avoir lancé le serveur, on a ouvert un terminal cmd sur windows pour tester:
|
||
```
|
||
ncat localhost 8080
|
||
Hello World!
|
||
Hello World!
|
||
Je teste, je suis content, je dors
|
||
Je teste, je suis content, je dors
|
||
^C
|
||
```
|
||
Quand on voit le contenu du TCP, on voit tout le texte d'échange mais on voit qu'il y a un espace entre chaque 8 caractères quand on passe la taille du buffer. Et à la fin du caractère, nous pouvons voir le dernier caractère pour déterminer la fin du texte.
|
||
|
||
|
||
|
||
|
||
La taille des segments TCP est cohérente avec la taille du buffer.
|
||
Dans "Bonjour tout le monde !" nous avons 13 octets (comptez le dernier caractère à la fin) de texte et 64 octets pour échanger des informations pour un total de 77 octets.
|
||
Dans le texte "Je teste, je suis content, je dors" nous avons 99 octets, dont 64 octets pour le protocole d'échange et l'IP, et 35 pour le texte.
|
||
|
||
|
||
|
||
|
||
### EXERCICE 3 : Version Multithreadée
|
||
|
||
Dans cet exercice, on réussit à créer un multi thread pour 4 personnes seulement, on teste avec le 5ème et il ne peut pas être "echo"
|
||
On peut voir dans l'image qu'on a 2 clients demandent l'accès du serveur:
|
||
Paquet n°49 et n°51 sont le client 1 et paquet n°324 et n°326 sont le client 2.
|
||
|
||
|
||
## Partie II: Implémentation d’un client HTTPping
|
||
|
||
### EXERCICE 1 : Analyse du protocole HTTP
|
||
Coté requête :
|
||
1. Ex: La première ligne `GET / HTTP/1.1` est la ligne de requête avec structure:
|
||
```
|
||
Méthode Lien Version_de_HTTP
|
||
```
|
||
|
||
2. Rôle des options:
|
||
- Accept-Encoding: L'encodage que le client peut comprendre
|
||
- Accept: Type de conetnu que le client peut accepter
|
||
- Connection: keep-alive: C'est une intruction qui permets de rester ouvert pour multiples requêtes/ réponses HTTP
|
||
|
||
Cote serveur:
|
||
1. La première ligne est la ligne de status avec structure:
|
||
```
|
||
Version_de_HTTP Code_de_status Message
|
||
```
|
||
2. On n'a pas trouvé de siteweb qui retourne 404. On a testé avec nombreux sitewebs et reçu 400 Bad Request.
|
||
Donc on a utiliser localhost de 3ème partie qui lance test.html et change à abc.html pour créer erreur 404
|
||
```
|
||
ncat localhost 8080
|
||
GET /a.html HTTP/1.1
|
||
HTTP/1.1 404 File Not Found
|
||
Content-Type: text/html
|
||
Connection: close
|
||
```
|
||
|
||
3. Les étapes du protocole pour la récupération d’une page:
|
||
- Le client demande la connexion
|
||
- Le client envoie les requêtes
|
||
- Serveur va vérifier et se connecter
|
||
- Serveur verra s'il existe la page web
|
||
- Serveur renvoie le résultat et son contenu si c'est possible
|
||
- Fermeture la connexion
|
||
|
||
### Exercice 2 : Récupération d’une page avec netcat
|
||
|
||
- example.com supporte-t-il le protocole HTTP/1.0?
|
||
|
||
On a executé ` curl -v www.example.com ` et il retourne HTTP1.x donc on ne connais pas sa version.
|
||
Pour forcer le siteweb à utiliser HTTP1.0 on tape la commande `curl -v --http1.0 www.example.com` et on a recu ce résultat:
|
||
|
||
`> GET / HTTP/1.0` donc example.com a supporté HTTP/1.0
|
||
|
||
- Quel est l’encodage utilisé pour le type de retour ?
|
||
|
||
Type de retour est en HTML ` < Content-Type: text/html`
|
||
|
||
- Que se passe-t-il si vous ajoutez “Accept-Encoding : gzip” ?*
|
||
|
||
La commande ` curl -v -H "Accept-Encoding: gzip" www.example.com` avec -H est header
|
||
|
||
On a vu que la taille est diminué de 1256 à 648. Par ailleurs, le contenu html n'est pas affiché parce qu'il est compressé
|
||
### Exercice 3, Implémentation du HTTP ping
|
||
|
||
### Exercice 4 : Socket securisée
|
||
On test avec google.fr et on a reçu ce résultat:
|
||
```
|
||
ncat --ssl google.fr 443
|
||
GET / HTTP/1.0
|
||
|
||
HTTP/1.0 200 OK
|
||
Date: Tue, 04 Feb 2025 22:57:57 GMT
|
||
Expires: -1
|
||
Cache-Control: private, max-age=0
|
||
Content-Type: text/html; charset=ISO-8859-1
|
||
```
|
||
|
||
Ensuite, nous devons changer `GET / HTTP/1.1` en `GET / HTTP/1.0` pour détecter https, son port et créer SSLSocketFactory pour détecter le http sécurisé.
|
||
On lance wireshark et obtient le message crypté. Malheureusement, je ne peux pas mettre le fichier pcapng car j'utilise l'adresse IP chez moi.
|
||
J'ai mis toute la partie http en code commenté.
|
||
|
||
|
||
|
||
Vérification de message encrypté:
|
||
|
||
|
||
|
||
## Partie III : Implémentation d’un serveur HTTP simple
|
||
Dans cette dernière partie, on a codé un serveur auquel on peut accéder depuis ncat et notre navigateur. On utilise PrintWriter pour envoyer les données au client.
|
||
Et on vérifie également auprès de Wireshark pour assurer que cela a fonctionné correctement. |