Posté par Krunch (site web personnel) .
Évalué à 4 (+2/-0).
Dernière modification le 15 novembre 2024 à 00:37.
Il n'y a pas de fin. Ce genre de problèmes arrive tout le temps. Si tu veux lire des histoires de gens qui ont eu des problèmes similaires, ont trouvé le client problématique et ont eu des discussions plus ou moins productives avec eux, il y a l'exemple de Netgear et l'université de Wisconsin–Madison ainsi que Wikimedia et une app mobile dans le lien. Wikipedia a aussi une page dédiée à cette classe de problèmes en ce qui concerne NTP.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
The discussion revolves around an unusual and excessive number of HTTP GET requests to the kernel.org website, specifically a log entry that appears over 56 million times in a single day. K. Ryabitsev, the original poster, speculates that these requests are likely from a mobile application or device performing connectivity checks, as they consistently receive a 301 redirect response.
Participants in the conversation suggest various approaches to mitigate the issue, including:
Redirecting Traffic: One user proposes routing the traffic through a CDN to manage the load better.
Blocking Requests: Several participants suggest blocking requests from the specific user agent (okhttp/4.9.0) or implementing timeout strategies to make the connectivity checks ineffective.
Analyzing Traffic: Suggestions include using tools like Wireshark to analyze the traffic and identify the source devices or applications.
Testing Responses: Some participants recommend returning different HTTP status codes (like 404 or 429) to see how the requesting applications respond, potentially leading to bug reports from users or developers.
Identifying the Source: There are discussions about the possibility of this traffic being linked to a popular Android app or a botnet, with suggestions to check for patterns in the requests or to reach out to the okhttp library maintainers for insights.
Overall, the conversation highlights the challenges of managing unexpected traffic to a website and the collaborative effort to find a solution.
Ben le LLM dit que des gens ont suggérés d'utiliser un outil comme wireshark pour analyser le trafic ou identifier les sources.
Or le premier commentaire suggère d'utiliser wireshark pour analyser le trafic.
Et le second d'utiliser wireshark pour faire du « fingerprinting » d'OS/Application, pour essayer de déterminer la source.
Le LLM parle d'identifier les sources ou appareils à partir de l'analyse faite par Wireshark. Ça sous-entend qu'il faut lancer Wireshark sur le serveur lui-même, pour remonter jusqu'aux sources.
Or, les commentaires parlent d'utiliser Wireshark depuis la source. Dans le premier cas, il faut un appareil avec OxygenOS et un Wireshark associé. Dans le deuxième, c'est moins clair, mais ça pourrait être à double sens.
La discussion porte sur un nombre inhabituel et excessif de requêtes HTTP GET vers le site kernel.org, avec une entrée de journal qui apparaît plus de 56 millions de fois en une seule journée. K. Ryabitsev, l'auteur du message original, suppose que ces requêtes proviennent probablement d'une application mobile ou d'un appareil effectuant des vérifications de connectivité, car elles reçoivent systématiquement une réponse de redirection 301.
Les participants à la conversation suggèrent diverses approches pour atténuer le problème, notamment :
Rediriger le trafic : Un utilisateur propose de faire passer le trafic par un CDN pour mieux gérer la charge.
Bloquer les requêtes : Plusieurs participants suggèrent de bloquer les requêtes provenant de l'agent utilisateur spécifique (okhttp/4.9.0) ou de mettre en œuvre des stratégies de délai d'attente pour rendre les vérifications de connectivité inefficaces.
Analyser le trafic : Des suggestions incluent l'utilisation d'outils comme Wireshark pour analyser le trafic et identifier les appareils ou applications sources.
Tester les réponses : Certains participants recommandent de renvoyer différents codes de statut HTTP (comme 404 ou 429) pour voir comment les applications demandeuses réagissent, ce qui pourrait potentiellement conduire à des rapports de bogues de la part des utilisateurs ou des développeurs.
Identifier la source : Il y a des discussions sur la possibilité que ce trafic soit lié à une application Android populaire ou à un botnet, avec des suggestions de vérifier les modèles dans les requêtes ou de contacter les mainteneurs de la bibliothèque okhttp pour obtenir des informations.
Dans l'ensemble, la conversation met en lumière les défis de la gestion d'un trafic inattendu vers un site web et l'effort collaboratif pour trouver une solution.
On est d'accord que ton message demandait une versions FR ?
Normalement, j'aurai pas pu y répondre ou tu n'aurais pas du pouvoir le modifier. Un bug/feature du site ?
Une simple « race condition », tu as vu le message dans la courte période où un auteur peut encore modifier - mais pas supprimer - son commentaire, et tu as répondu à une version du commentaire qui a changé entre temps.
C'est d'ailleurs pour ça qu'on ne peut pas éditer ses propres commentaires.
Mais comme on a droit-à-l'erreur.gouve.fer, on a quelques minutes quand même pour se relire une dernière fois, et corriger.
# On veut la suite !
Posté par gUI (Mastodon) . Évalué à 10 (+7/-0).
Il me tarde d'avoir le fin mot de l'histoire quand même.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: On veut la suite !
Posté par Krunch (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 15 novembre 2024 à 00:37.
Il n'y a pas de fin. Ce genre de problèmes arrive tout le temps. Si tu veux lire des histoires de gens qui ont eu des problèmes similaires, ont trouvé le client problématique et ont eu des discussions plus ou moins productives avec eux, il y a l'exemple de Netgear et l'université de Wisconsin–Madison ainsi que Wikimedia et une app mobile dans le lien. Wikipedia a aussi une page dédiée à cette classe de problèmes en ce qui concerne NTP.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# sum up of the discussion
Posté par steph1978 . Évalué à -10 (+2/-18).
The discussion revolves around an unusual and excessive number of HTTP GET requests to the kernel.org website, specifically a log entry that appears over 56 million times in a single day. K. Ryabitsev, the original poster, speculates that these requests are likely from a mobile application or device performing connectivity checks, as they consistently receive a 301 redirect response.
Participants in the conversation suggest various approaches to mitigate the issue, including:
Overall, the conversation highlights the challenges of managing unexpected traffic to a website and the collaborative effort to find a solution.
[^] # Re: sum up of the discussion
Posté par Glandos . Évalué à 10 (+10/-0).
C'est un résumé fait par IA générative je suppose ?
Je préférerais que ça soit clairement mentionné, si c'est le cas, soit dans le titre, soit dans le commentaire lui-même :)
[^] # Re: sum up of the discussion
Posté par steph1978 . Évalué à 2 (+1/-1).
Tu as raison, j'aurai du rendre cet aspect plus explicite.
[^] # Re: sum up of the discussion
Posté par Glandos . Évalué à 7 (+5/-0).
C'est faux, personne ne dit ça. Je cite les deux passages dans la source :
[^] # Re: sum up of the discussion
Posté par steph1978 . Évalué à 2 (+0/-0).
Bien vu
Le LLM s'est fait prendre par la forme conditionnelle, j'imagine.
[^] # Re: sum up of the discussion
Posté par Yth (Mastodon) . Évalué à 2 (+0/-0).
Ben le LLM dit que des gens ont suggérés d'utiliser un outil comme wireshark pour analyser le trafic ou identifier les sources.
Or le premier commentaire suggère d'utiliser wireshark pour analyser le trafic.
Et le second d'utiliser wireshark pour faire du « fingerprinting » d'OS/Application, pour essayer de déterminer la source.
J'ai du mal à voir, ici, où il se serait trompé…
[^] # Re: sum up of the discussion
Posté par Glandos . Évalué à 4 (+2/-0).
Le LLM parle d'identifier les sources ou appareils à partir de l'analyse faite par Wireshark. Ça sous-entend qu'il faut lancer Wireshark sur le serveur lui-même, pour remonter jusqu'aux sources.
Or, les commentaires parlent d'utiliser Wireshark depuis la source. Dans le premier cas, il faut un appareil avec OxygenOS et un Wireshark associé. Dans le deuxième, c'est moins clair, mais ça pourrait être à double sens.
[^] # Re: sum up of the discussion
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 13 novembre 2024 à 14:40.
(Zut, j'avais écrit ce message avant que les autres réponses ne soient postées, il était donc obsolète au moment où je l'ai envoyé. Désolé)
[^] # Re: sum up of the discussion
Posté par steph1978 . Évalué à -5 (+1/-8).
Voici (LLM generated):
La discussion porte sur un nombre inhabituel et excessif de requêtes HTTP GET vers le site kernel.org, avec une entrée de journal qui apparaît plus de 56 millions de fois en une seule journée. K. Ryabitsev, l'auteur du message original, suppose que ces requêtes proviennent probablement d'une application mobile ou d'un appareil effectuant des vérifications de connectivité, car elles reçoivent systématiquement une réponse de redirection 301.
Les participants à la conversation suggèrent diverses approches pour atténuer le problème, notamment :
Dans l'ensemble, la conversation met en lumière les défis de la gestion d'un trafic inattendu vers un site web et l'effort collaboratif pour trouver une solution.
[^] # Re: sum up of the discussion
Posté par steph1978 . Évalué à 2 (+1/-1).
On est d'accord que ton message demandait une versions FR ?
Normalement, j'aurai pas pu y répondre ou tu n'aurais pas du pouvoir le modifier. Un bug/feature du site ?
[^] # Re: sum up of the discussion
Posté par Yth (Mastodon) . Évalué à 4 (+2/-0).
Une simple « race condition », tu as vu le message dans la courte période où un auteur peut encore modifier - mais pas supprimer - son commentaire, et tu as répondu à une version du commentaire qui a changé entre temps.
C'est d'ailleurs pour ça qu'on ne peut pas éditer ses propres commentaires.
Mais comme on a droit-à-l'erreur.gouve.fer, on a quelques minutes quand même pour se relire une dernière fois, et corriger.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.