chore(doc):Translate an existing blog into multiple languages
This commit is contained in:
david_bai
@@ -0,0 +1,159 @@
|
||||
---
|
||||
title: "Warum ich PrivyDrop Open Source gestellt habe: Eine Geschichte über Privatsphäre, WebRTC und Gemeinschaftsaufbau"
|
||||
description: "PrivyDrop ist jetzt Open Source! Dieser Artikel erzählt die Entwicklung von einem persönlichen Bedürfnis zu einem produktionsreifen privaten Dateiübertragungstool, taucht tief in seine Architektur ein und lädt Sie ein, die Zukunft gemeinsam zu gestalten."
|
||||
date: "2025-07-07"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/privydrop-open-source.jpg"
|
||||
tags: [Open Source, WebRTC, Privatsphäre, Sicherheit, Next.js, Node.js]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## Einleitung
|
||||
|
||||
Heute bin ich unglaublich aufgeregt, ankündigen zu können, dass ein persönliches Projekt, in das ich mein Herz und meine Seele gesteckt habe, **PrivyDrop**, nun offiziell Open Source ist!
|
||||
|
||||
[**Jetzt Live testen »**](https://www.privydrop.app/) | [**GitHub Repository »**](https://github.com/david-bai00/PrivyDrop)
|
||||
|
||||
Dieses Projekt begann mit einem sehr einfachen persönlichen Bedürfnis: "Ich möchte nur Dinge sicher und einfach zwischen meinem Telefon und Computer versenden."
|
||||
|
||||
Wenn Sie, wie ich, jemals frustriert waren bei der Suche nach einem Datei-Freigabetool, das keine Registrierung erfordert, keine Geschwindigkeitsbegrenzungen hat und Ihre Privatsphäre wirklich respektiert, dann ist dieser Artikel für Sie. Er wird nicht nur die Geschichte des "Kratzens am eigenen Juckreiz" teilen, sondern Sie auch auf eine vollständige "Hinter-den-Kulissen"-Tour mitnehmen, um PrivyDrops Kernarchitektur und Designphilosophie zu erkunden. Und am wichtigsten ist es eine aufrichtige Einladung, Co-Autor des nächsten Kapitels zu werden.
|
||||
|
||||
## Teil 1: Die Geburt eines Werkzeugs: Von "Ich brauche es" zu "Alle können es nutzen"
|
||||
|
||||
### 1.1 Die Reise eines Entwicklers, seinen eigenen Juckreiz zu kratzen
|
||||
|
||||
Alles begann mit einem kleinen aber hartnäckigen Schmerzpunkt in meinem täglichen Arbeitsablauf.
|
||||
|
||||
Ich muss häufig Dateien, Screenshots oder Text-Schnipsel zwischen meinem Telefon und meinem Laptop schnell senden. Ich habe viele Werkzeuge ausprobiert, aber keine hat meine Anforderungen vollständig erfüllt:
|
||||
|
||||
- Einige Online-P2P-Werkzeuge waren mächtig, konnten aber nur Dateien senden und scheiterten an meinem Bedarf, leichtgewichtigen Text oder Links zu senden.
|
||||
- Einige Online-Zwischenablagen konnten Text bequem synchronisieren, aber ich war zutiefst besorgt darüber, meine Zwischenablageninhalte auf einen unbekannten Server hochzuladen.
|
||||
- Und die Mainstream-Cloud-Speicher- oder Social-Apps erforderten entweder eine Anmeldung oder hatten Größen- und Geschwindigkeitsbegrenzungen, was den gesamten Prozess umständlich und mühsam machte.
|
||||
|
||||
Nachdem ich versagt hatte, ein Werkzeug zu finden, das perfekt meinen drei Kernanforderungen entsprach—**schnell, privat und ohne Konto erforderlich**—entschied ich mich, eines für mich selbst zu bauen.
|
||||
|
||||
### 1.2 Von einem persönlichen Werkzeug zu einem öffentlichen Projekt
|
||||
|
||||
Ursprünglich war PrivyDrop nur ein kleines Werkzeug, um meine eigenen Bedürfnisse zu erfüllen. Aber als ich nach und nach seine Funktionen verbesserte, erkannte ich, dass mein Schmerzpunkt wahrscheinlich ein gemeinsamer war.
|
||||
|
||||
In einer Zeit, in der Daten und Privatsphäre immer wichtiger werden, verdienen wir eine bessere Wahl—ein Werkzeug, das uns nicht zwingt, eine schmerzhafte Kompromisseingenschaft zwischen "Bequemlichkeit" und "Privatsphäre" einzugehen. Diese Idee trieb mich an, PrivyDrop von einem persönlichen Projekt zu einem robusten und zuverlässigen öffentlichen Dienst zu polieren.
|
||||
|
||||
Unsere Kernvision ist einfach, wie ich im README des Projekts schrieb: **Wir glauben, dass jeder die Kontrolle über seine eigenen Daten haben sollte.**
|
||||
|
||||
### 1.3 Warum Open Source? Die einzige Antwort für Vertrauen
|
||||
|
||||
Für ein Werkzeug, das "Privatsphäre und Sicherheit" als Kernwert beansprucht, ist Closed Source ein Widerspruch in sich selbst. Wie können Benutzer Ihren Versprechen vertrauen?
|
||||
|
||||
Daher war Open Source die unvermeidliche Wahl und die einzige Antwort.
|
||||
|
||||
- **Um Vertrauen aufzubauen**: Code ist der beste Beweis. Wir machen all unseren Code öffentlich, um von der Welt geprüft zu werden, und bauen so unbestreitbares Vertrauen auf.
|
||||
- **Die Kraft der Gemeinschaft**: Ich bin mir sehr bewusst, dass die Kraft eines Einzelnen begrenzt ist. Ich glaube, dass die kollektive Weisheit der Gemeinschaft helfen kann, Fehler zu finden, die ich übersehen habe, und Funktionen vorzuschlagen, an die ich nie gedacht habe, und PrivyDrop dabei helfen, weiterzukommen und robuster zu werden.
|
||||
- **Um zurückzugeben und zu lernen**: Ich habe ungemein von der Open-Source-Gemeinschaft profitiert, und jetzt ist es meine Zeit zurückzugeben. Das Projekt Open Source zu stellen, ist sowohl eine Möglichkeit, von talentierten Entwicklern zu lernen, als auch eine Freude des Teilens.
|
||||
|
||||
## Teil 2: Ein tiefer Einblick in die Architektur: Eine "Produktionsreife" Praxis
|
||||
|
||||
PrivyDrop ist nicht nur ein Spielzeugprojekt. In seiner architektonischen Design verfolgten wir Einfachheit, Effizienz und Skalierbarkeit und strebten danach, Produktionsstandards zu erreichen.
|
||||
|
||||
### 2.1 Das große Ganze: Ein einfaches und effizientes System
|
||||
|
||||
Unser Kern-Designprinzip ist: **ein leichtgewichtiger Backend, ein intelligentes Frontend**. Das Backend agiert nur als "Verkehrspolizist" (für Signalisierung), während das Frontend alle "schweren Arbeiten" (Dateiverarbeitung und -übertragung) übernimmt.
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph "Benutzer A (Sender)"
|
||||
A[Frontend App]
|
||||
end
|
||||
subgraph "Benutzer B (Empfänger)"
|
||||
B[Frontend App]
|
||||
end
|
||||
subgraph "Cloud"
|
||||
C(Signalisierungsserver - Node.js)
|
||||
D(Zustandsspeicher - Redis)
|
||||
end
|
||||
|
||||
A -- "1. Anfrage zum Erstellen/Beitreten von Raum" --> C
|
||||
B -- "2. Anfrage zum Beitreten zum gleichen Raum" --> C
|
||||
C -- "3. WebRTC-Signale austauschen (SDP/ICE)" --> A
|
||||
C -- "4. WebRTC-Signale austauschen (SDP/ICE)" --> B
|
||||
A <-.-> B;
|
||||
C <--> D
|
||||
A <-. "5. P2P-Direktverbindung herstellen" .-> B
|
||||
A -- "6. Dateien/Text direkt übertragen" --> B
|
||||
|
||||
style A fill:#D5E8D4,stroke:#82B366
|
||||
style B fill:#D5E8D4,stroke:#82B366
|
||||
```
|
||||
|
||||
### 2.2 Frontend-Architektur: Von der Trennung von Belangen zur logischen Kohäsion
|
||||
|
||||
Das Frontend ist mit Next.js 14 gebaut, und unsere Kern-Designphilosophie ist **benutzerdefinierte Hooks als Herz unserer Geschäftslogik zu verwenden**.
|
||||
|
||||
Sie könnten fragen, warum nicht Redux oder Zustand? Für PrivyDrop ist der meiste Zustand eng gekoppelt mit spezifischer, hochkohärenter Geschäftslogik. Wir kapselten diese Logik und den Zustand in eine Reihe von benutzerdefinierten Hooks (wie `useWebRTCConnection`, `useRoomManager`, `useFileTransferHandler`), was mehrere klare Vorteile brachte:
|
||||
|
||||
- **Logische Kohäsion**: Alle Zustände und Methoden im Zusammenhang mit der WebRTC-Verbindung sind in `useWebRTCConnection`, was es extrem einfach zu warten macht.
|
||||
- **Reine Komponenten**: React-Komponenten werden von komplexer Geschäftslogik befreit und kehren zu ihrer wesentlichen Rolle des UI-Renderings zurück.
|
||||
- **Klare Schichtung**: Dies schafft einen klaren Datenfluss und Abhängigkeitsbeziehung von `app` (Routing) -> `components` (UI) -> `hooks` (Logik) -> `lib` (Low-Level-Fähigkeiten), was die Wartbarkeit des Code-Basis erheblich verbessert.
|
||||
|
||||
### 2.3 Backend-Architektur: Die Kunst der Zustandslosigkeit und Effizienz
|
||||
|
||||
Das Backend, basierend auf Node.js und Express, folgt in seinem Design streng dem **zustandslosen (Stateless)** Prinzip.
|
||||
|
||||
Der Server selbst hält keinen Zustand im Zusammenhang mit Räumen oder Benutzern. Der gesamte Zustand wird an **Redis** delegiert. Dies ermöglicht es der Backend-Anwendung, leicht horizontal skaliert zu werden.
|
||||
|
||||
Wir nutzten auch clever verschiedene Redis-Datenstrukturen, um Geschäftsanforderungen zu erfüllen:
|
||||
|
||||
- **Hash**: Zum Speichern von Raum-Metadaten.
|
||||
- **Set**: Zum Speichern der `socketId` aller Mitglieder in einem Raum, wodurch Eindeutigkeit sichergestellt wird.
|
||||
- **String**: Um eine `socketId` rückwärts auf ihre `roomId` abzubilden, was eine schnelle Bereinigung bei Benutzertrennung erleichtert.
|
||||
- **Sorted Set**: Zur Implementierung von IP-basierter Ratenbegrenzung, was schädliche Anriffe effektiv verhindert.
|
||||
|
||||
Alle Schlüssel sind mit einer angemessenen TTL (Time To Live) eingestellt, was eine automatische Ressourcenbereinigung sicherstellt und dem System ermöglicht, langfristig stabil zu laufen.
|
||||
|
||||
### 2.4 "Produktionsreife" Überlegungen: Von Bereitstellung bis Sicherheit
|
||||
|
||||
Wir bieten einen vollständigen Produktionsbereitstellungsplan, einschließlich:
|
||||
|
||||
- Verwendung von **Nginx** als Reverse-Proxy und für SSL-Terminierung.
|
||||
- Verwendung von **PM2** für Node.js-Prozessmanagement.
|
||||
- Verwendung von **Certbot** für automatische SSL-Zertifikatserwerbung und -erneuerung.
|
||||
- Eine umfassende Anleitung zur Einrichtung eines **TURN/STUN**-Servers für Szenarien, die das Durchqueren komplexer NATs erfordern.
|
||||
|
||||
All dies zeigt, dass PrivyDrop ein ernstes Projekt ist, dem vertraut und das in einer Produktionsumgebung bereitgestellt werden kann.
|
||||
|
||||
## Teil 3: Mehr als Code: Eine Einladung, die Zukunft zu gestalten
|
||||
|
||||
Open Source ist nur der Anfang. Wir haben eine aufregende Zukunft für PrivyDrop geplant, und jetzt möchten wir Sie einladen, sich uns anzuschließen.
|
||||
|
||||
### 3.1 Projekt-Roadmap
|
||||
|
||||
Wir haben eine öffentliche [<u>**Projekt-Roadmap**</u>](https://github.com/david-bai00/PrivyDrop/blob/main/ROADMAP.md), die unsere zukünftigen Prioritäten umreißt. Wir planen, in Zukunft einige stark nachgefragte Funktionen hinzuzufügen, wie zum Beispiel:
|
||||
|
||||
- **Wiederaufnehmbare Übertragungen**: Um sehr große Dateien und instabile Netzwerkbedingungen zu bewältigen.
|
||||
- **E2E-verschlüsselter Gruppenchat**: Um sichere P2P-Kommunikation auf Multi-Benutzer-Text-Chats zu erweitern.
|
||||
- Andere unbestimmte Funktionen.
|
||||
|
||||
### 3.2 Wie kann man beitragen?
|
||||
|
||||
Wir begrüßen Beiträge jeglicher Form! Egal wer Sie sind, es gibt immer einen Weg zu helfen, PrivyDrop besser zu machen. Bitte lesen Sie unsere [<u>**Beitragsrichtlinien**</u>](https://github.com/david-bai00/PrivyDrop/blob/main/.github/CONTRIBUTING.md), um Ihre Reise zu beginnen.
|
||||
|
||||
- **Für Benutzer**: Verwenden Sie das Produkt, melden Sie Fehler und schlagen Sie Funktionen über [GitHub Issues](https://github.com/david-bai00/PrivyDrop/issues) vor.
|
||||
- **Für Entwickler**: Übernehmen Sie einen Fehler, implementieren Sie eine neue Funktion oder refaktorisieren Sie ein Stück bestehenden Codes.
|
||||
- **Für Dokumentatoren/Übersetzer**: Helfen Sie uns, die Dokumentation zu verbessern oder PrivyDrop in mehr Sprachen zu übersetzen.
|
||||
|
||||
### 3.3 Ein starker Aufruf zum Handeln
|
||||
|
||||
- **Für Benutzer**: Erleben Sie jetzt die ultimative Privatsphäre und Bequemlichkeit mit PrivyDrop!
|
||||
[**➡️ Jetzt Live testen**](https://www.privydrop.app/)
|
||||
|
||||
- **Für Entwickler**: Wenn PrivyDrops Philosophie oder Technologie Sie begeistert, geben Sie unserem GitHub-Repository bitte einen Stern! Es ist die größte Anerkennung und Ermutigung für uns.
|
||||
[**⭐️ Geben Sie uns einen Stern auf GitHub**](https://github.com/david-bai00/PrivyDrop)
|
||||
|
||||
- **Für alle**: Treten Sie unseren Gemeinschaftsdiskussionen bei und lassen Sie uns Ihre Stimme hören!
|
||||
|
||||
## Fazit
|
||||
|
||||
Vielen Dank erneut, dass Sie sich Zeit genommen haben, diese Geschichte zu lesen.
|
||||
|
||||
Die Geschichte von PrivyDrop begann mit dem Bedürfnis einer Person, und ich freue mich darauf, dass ihre Zukunft von einer Gemeinschaft geschrieben wird.
|
||||
@@ -0,0 +1,159 @@
|
||||
---
|
||||
title: "Por qué Abierto PrivyDrop: Una Historia de Privacidad, WebRTC y Construcción Comunitaria"
|
||||
description: "¡PrivyDrop ahora es código abierto! Este artículo narra la evolución desde una necesidad personal hasta una herramienta de transferencia de archivos privada de nivel producción, profundiza en su arquitectura y te invita a construir el futuro juntos."
|
||||
date: "2025-07-07"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/privydrop-open-source.jpg"
|
||||
tags: [Código Abierto, WebRTC, Privacidad, Seguridad, Next.js, Node.js]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## Introducción
|
||||
|
||||
Hoy, estoy increíblemente emocionado de anunciar que un proyecto personal en el que he volcado mi corazón y alma, **PrivyDrop**, ahora es oficialmente código abierto.
|
||||
|
||||
[**Pruébalo en Vivo »**](https://www.privydrop.app/) | [**Repositorio GitHub »**](https://github.com/david-bai00/PrivyDrop)
|
||||
|
||||
Este proyecto comenzó con una necesidad personal muy simple: "Solo quiero enviar cosas entre mi teléfono y mi computadora, de forma segura y fácil."
|
||||
|
||||
Si tú, como yo, alguna vez te has frustrado buscando una herramienta para compartir archivos que no requiera registro, no tenga límites de velocidad y realmente respete tu privacidad, entonces este artículo es para ti. No solo compartirá la historia de "rascarme mi propia picazón", sino que también te llevará en un completo "detrás de cámaras" para explorar la arquitectura central y la filosofía de diseño de PrivyDrop. Y lo más importante, es una sincera invitación para que te conviertas en co-autor de su próximo capítulo.
|
||||
|
||||
## Parte 1: El Nacimiento de una Herramienta: Desde "Lo Necesito" hasta "Todos Pueden Usarlo"
|
||||
|
||||
### 1.1 El Viaje de un Desarrollador para Rascarse su Propia Picazón
|
||||
|
||||
Todo comenzó con un pequeño pero persistente punto de dolor en mi flujo de trabajo diario.
|
||||
|
||||
Frecuentemente necesito enviar rápidamente archivos, capturas de pantalla o fragmentos de texto entre mi teléfono y mi laptop. Probé muchas herramientas, pero ninguna cumplió completamente con mis requisitos:
|
||||
|
||||
- Algunas herramientas P2P en línea eran poderosas pero solo podían enviar archivos, fallando en mi necesidad de enviar texto ligero o enlaces.
|
||||
- Algunos portapapeles en línea podían sincronizar texto convenientemente, pero estaba profundamente preocupado por subir el contenido de mi portapapeles a un servidor desconocido.
|
||||
- Y las aplicaciones主流 de almacenamiento en la nube o sociales requerían iniciar sesión o tenían límites de tamaño y velocidad, haciendo que todo el proceso se sintiera torpe y engorroso.
|
||||
|
||||
Después de fallar en encontrar una herramienta que coincidiera perfectamente con mis tres requisitos centrales—**rápido, privado y sin necesidad de cuenta**—decidí construir una para mí mismo.
|
||||
|
||||
### 1.2 Desde una Utilidad Personal a un Proyecto Público
|
||||
|
||||
Inicialmente, PrivyDrop era solo una pequeña utilidad para satisfacer mis propias necesidades. Pero a medida que mejoré gradualmente sus características, me di cuenta de que mi punto de dolor probablemente era común.
|
||||
|
||||
En una era donde los datos y la privacidad son cada vez más importantes, merecemos una mejor opción—una herramienta que no nos obligue a hacer una dolorosa compensación entre "conveniencia" y "privacidad". Esta idea me impulsó a pulir PrivyDrop desde un proyecto personal hasta un servicio público robusto y confiable.
|
||||
|
||||
Nuestra visión central es simple, como escribí en el README del proyecto: **Creemos que todos deberían tener control sobre sus propios datos.**
|
||||
|
||||
### 1.3 ¿Por qué Código Abierto? La Única Respuesta para la Confianza
|
||||
|
||||
Para una herramienta que reclama "privacidad y seguridad" como su valor central, ser de código cerrado es una contradicción en sí misma. ¿Cómo pueden los usuarios confiar en tus promesas?
|
||||
|
||||
Por lo tanto, el código abierto fue la elección inevitable y la única respuesta.
|
||||
|
||||
- **Para Construir Confianza**: El código es la mejor prueba. Estamos haciendo público todo nuestro código para ser escrutado por el mundo, construyendo así una confianza innegable.
|
||||
- **El Poder de la Comunidad**: Soy muy consciente de que el poder de un individuo es limitado. Creo que la sabiduría colectiva de la comunidad puede ayudar a encontrar defectos que he pasado por alto y sugerir características que nunca he pensado, ayudando a PrivyDrop a ir más lejos y volverse más robusto.
|
||||
- **Para Devolver y Aprender**: He beneficiado inmensamente de la comunidad de código abierto, y ahora es mi momento de devolver. Abrir el código del proyecto es tanto una forma de aprender de desarrolladores talentosos como una alegría de compartir.
|
||||
|
||||
## Parte 2: Una Inmersión Profunda en la Arquitectura: Una Práctica de "Nivel Producción"
|
||||
|
||||
PrivyDrop no es solo un proyecto de juguete. En su diseño arquitectónico, buscamos simplicidad, eficiencia y escalabilidad, esforzándonos por cumplir con los estándares de nivel producción.
|
||||
|
||||
### 2.1 El Panorama General: Un Sistema Simple y Eficiente
|
||||
|
||||
Nuestro principio de diseño central es: **un backend ligero, un frontend inteligente**. El backend solo actúa como "agente de tráfico" (para señalización), mientras que el frontend maneja todo el "trabajo pesado" (procesamiento y transferencia de archivos).
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph "Usuario A (Remitente)"
|
||||
A[Aplicación Frontend]
|
||||
end
|
||||
subgraph "Usuario B (Receptor)"
|
||||
B[Aplicación Frontend]
|
||||
end
|
||||
subgraph "Nube"
|
||||
C(Servidor de Señalización - Node.js)
|
||||
D(Almacenamiento de Estado - Redis)
|
||||
end
|
||||
|
||||
A -- "1. Solicitar crear/unirse a sala" --> C
|
||||
B -- "2. Solicitar unirse a misma sala" --> C
|
||||
C -- "3. Intercambiar señales WebRTC (SDP/ICE)" --> A
|
||||
C -- "4. Intercambiar señales WebRTC (SDP/ICE)" --> B
|
||||
A <-.-> B;
|
||||
C <--> D
|
||||
A <-. "5. Establecer conexión P2P directa" .-> B
|
||||
A -- "6. Transferir archivos/texto directamente" --> B
|
||||
|
||||
style A fill:#D5E8D4,stroke:#82B366
|
||||
style B fill:#D5E8D4,stroke:#82B366
|
||||
```
|
||||
|
||||
### 2.2 Arquitectura Frontend: Desde la Separación de Preocupaciones hasta la Cohesión Lógica
|
||||
|
||||
El frontend está construido con Next.js 14, y nuestra filosofía de diseño central es **usar Hooks personalizados como el corazón de nuestra lógica de negocio**.
|
||||
|
||||
Podrías preguntar, ¿por qué no Redux o Zustand? Para PrivyDrop, la mayor parte del estado está estrechamente acoplado con lógica de negocio específica y altamente cohesiva. Encapsulamos esta lógica y estado en una serie de Hooks personalizados (como `useWebRTCConnection`, `useRoomManager`, `useFileTransferHandler`), lo que trajo varios beneficios claros:
|
||||
|
||||
- **Cohesión Lógica**: Todo el estado y métodos relacionados con la conexión WebRTC están en `useWebRTCConnection`, haciéndolo extremadamente fácil de mantener.
|
||||
- **Componentes Puros**: Los componentes de React se liberan de la compleja lógica de negocio, regresando a su rol esencial de renderizar UI.
|
||||
- **Capas Claras**: Esto crea un claro flujo de datos y relación de dependencia desde `app` (enrutamiento) -> `components` (UI) -> `hooks` (lógica) -> `lib` (capacidades de bajo nivel), mejorando enormemente la capacidad de mantenimiento del código base.
|
||||
|
||||
### 2.3 Arquitectura Backend: El Arte de la Sin Estado y Eficiencia
|
||||
|
||||
El backend, basado en Node.js y Express, sigue estrictamente el principio **sin estado (stateless)** en su diseño.
|
||||
|
||||
El servidor en sí no mantiene ningún estado relacionado con salas o usuarios. Todo el estado es delegado a **Redis**. Esto permite que la aplicación backend sea escalada horizontalmente con facilidad.
|
||||
|
||||
También utilizamos clevermente diferentes estructuras de datos de Redis para satisfacer las necesidades del negocio:
|
||||
|
||||
- **Hash**: Para almacenar metadatos de sala.
|
||||
- **Set**: Para almacenar el `socketId` de todos los miembros en una sala, asegurando unicidad.
|
||||
- **String**: Para mapear inversamente un `socketId` a su `roomId`, facilitando una limpieza rápida cuando un usuario se desconecta.
|
||||
- **Sorted Set**: Para implementar limitación de velocidad basada en IP, previniendo efectivamente ataques maliciosos.
|
||||
|
||||
Todas las claves están configuradas con un TTL (Time To Live) razonable, asegurando la limpieza automática de recursos y permitiendo que el sistema funcione de manera estable a largo plazo.
|
||||
|
||||
### 2.4 Consideraciones de "Nivel Producción": Desde Despliegue hasta Seguridad
|
||||
|
||||
Proporcionamos un plan completo de despliegue en producción, incluyendo:
|
||||
|
||||
- Usar **Nginx** como proxy inverso y para terminación SSL.
|
||||
- Usar **PM2** para gestión de procesos Node.js.
|
||||
- Usar **Certbot** para adquisición y renovación automática de certificados SSL.
|
||||
- Una guía comprensiva para configurar un servidor **TURN/STUN** para escenarios que requieren atravesar NATs complejos.
|
||||
|
||||
Todo esto demuestra que PrivyDrop es un proyecto serio que puede ser confiado y desplegado a un entorno de producción.
|
||||
|
||||
## Parte 3: Más Allá del Código: Una Invitación a Construir el Futuro
|
||||
|
||||
Abrir el código es solo el comienzo. Tenemos un futuro emocionante planeado para PrivyDrop, y ahora, queremos invitarte a unirte a nosotros.
|
||||
|
||||
### 3.1 Hoja de Ruta del Proyecto
|
||||
|
||||
Tenemos una [<u>**Hoja de Ruta del Proyecto**</u>](https://github.com/david-bai00/PrivyDrop/blob/main/ROADMAP.md) pública que describe nuestras futuras prioridades. Planeamos agregar algunas características muy solicitadas en el futuro, tales como:
|
||||
|
||||
- **Transferencias Reanudables**: Para manejar archivos muy grandes y condiciones de red inestables.
|
||||
- **Chat Grupal Cifrado E2E**: Para extender la comunicación P2P segura a chats de texto multi-usuario.
|
||||
- Otras características por determinar.
|
||||
|
||||
### 3.2 ¿Cómo Contribuir?
|
||||
|
||||
¡Bienvenimos contribuciones de todas las formas! No importa quién seas, siempre hay una manera de ayudar a hacer PrivyDrop mejor. Por favor lee nuestras [<u>**Guías de Contribución**</u>](https://github.com/david-bai00/PrivyDrop/blob/main/.github/CONTRIBUTING.md) para comenzar tu viaje.
|
||||
|
||||
- **Para Usuarios**: Usa el producto, reporta bugs y sugiere características a través de [GitHub Issues](https://github.com/david-bai00/PrivyDrop/issues).
|
||||
- **Para Desarrolladores**: Reclama un bug, implementa una nueva característica, o refactoriza una pieza de código existente.
|
||||
- **Para Documentadores/Traductores**: Ayúdanos a mejorar la documentación o traduce PrivyDrop a más idiomas.
|
||||
|
||||
### 3.3 Una Fuerte Llamada a la Acción
|
||||
|
||||
- **Para Usuarios**: ¡Experimenta la máxima privacidad y conveniencia con PrivyDrop ahora!
|
||||
[**➡️ Pruébalo en Vivo**](https://www.privydrop.app/)
|
||||
|
||||
- **Para Desarrolladores**: Si la filosofía o tecnología de PrivyDrop te emociona, por favor da una Estrella a nuestro repositorio GitHub. ¡Es el mayor reconocimiento y aliento para nosotros!
|
||||
[**⭐️ Danos Estrella en GitHub**](https://github.com/david-bai00/PrivyDrop)
|
||||
|
||||
- **Para Todos**: ¡Únete a nuestras discusiones comunitarias y deja que escuchemos tu voz!
|
||||
|
||||
## Conclusión
|
||||
|
||||
Gracias nuevamente por tomar el tiempo de leer esta historia.
|
||||
|
||||
La historia de PrivyDrop comenzó con la necesidad de una persona, y espero que su futuro sea escrito por una comunidad.
|
||||
@@ -0,0 +1,159 @@
|
||||
---
|
||||
title: "Pourquoi j'ai mis PrivyDrop en Open Source : Une histoire de confidentialité, WebRTC et construction communautaire"
|
||||
description: "PrivyDrop est maintenant en open source ! Cet article raconte son évolution d'un besoin personnel à un outil de transfert de fichiers privé de qualité production, plonge en profondeur dans son architecture et vous invite à construire l'avenir ensemble."
|
||||
date: "2025-07-07"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/privydrop-open-source.jpg"
|
||||
tags: [Open Source, WebRTC, Confidentialité, Sécurité, Next.js, Node.js]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## Introduction
|
||||
|
||||
Aujourd'hui, je suis incroyablement excité d'annoncer qu'un projet personnel auquel j'ai consacré mon cœur et mon âme, **PrivyDrop**, est maintenant officiellement open source !
|
||||
|
||||
[**Essayez-le en Direct »**](https://www.privydrop.app/) | [**Dépôt GitHub »**](https://github.com/david-bai00/PrivyDrop)
|
||||
|
||||
Ce projet a commencé avec un besoin personnel très simple : "Je veux juste envoyer des choses entre mon téléphone et mon ordinateur, de manière sécurisée et facile."
|
||||
|
||||
Si vous, comme moi, avez déjà été frustré en cherchant un outil de partage de fichiers qui ne nécessite aucune inscription, n'a pas de limites de vitesse et respecte vraiment votre confidentialité, alors cet article est pour vous. Il partagera non seulement l'histoire de "me gratter là où ça me démange", mais vous emmènera également dans une visite complète "coulisses" pour explorer l'architecture centrale et la philosophie de conception de PrivyDrop. Et plus important encore, c'est une invitation sincère à devenir co-auteur de son prochain chapitre.
|
||||
|
||||
## Partie 1 : La naissance d'un outil : De "J'en ai besoin" à "Tout le monde peut l'utiliser"
|
||||
|
||||
### 1.1 Le parcours d'un développeur pour se gratter là où ça lui démange
|
||||
|
||||
Tout a commencé par un petit point de douleur persistant dans mon flux de travail quotidien.
|
||||
|
||||
J'ai fréquemment besoin d'envoyer rapidement des fichiers, des captures d'écran ou des extraits de texte entre mon téléphone et mon ordinateur portable. J'ai essayé de nombreux outils, mais aucun n'a complètement satisfait mes exigences :
|
||||
|
||||
- Certains outils P2P en ligne étaient puissants mais ne pouvaient envoyer que des fichiers, échouant à mon besoin d'envoyer du texte léger ou des liens.
|
||||
- Certains presse-papiers en ligne pouvaient synchroniser du texte commodément, mais j'étais profondément préoccupé par l'upload de mon contenu de presse-papiers sur un serveur inconnu.
|
||||
- Et les applications主流 de stockage cloud ou sociales nécessitaient soit de se connecter, soit avaient des limites de taille et de vitesse, rendant tout le processus lourd et fastidieux.
|
||||
|
||||
Après avoir échoué à trouver un outil qui correspondait parfaitement à mes trois exigences centrales—**rapide, privé et sans compte nécessaire**—j'ai décidé d'en construire un pour moi-même.
|
||||
|
||||
### 1.2 D'un utilitaire personnel à un projet public
|
||||
|
||||
Initialement, PrivyDrop n'était qu'un petit utilitaire pour répondre à mes propres besoins. Mais à mesure que j'améliorais progressivement ses fonctionnalités, j'ai réalisé que mon point de douleur était probablement courant.
|
||||
|
||||
À une époque où les données et la confidentialité sont de plus en plus importantes, nous méritons un meilleur choix—un outil qui ne nous force pas à faire un compromis douloureux entre "commodité" et "confidentialité". Cette idée m'a poussé à polir PrivyDrop d'un projet personnel à un service public robuste et fiable.
|
||||
|
||||
Notre vision centrale est simple, comme je l'ai écrite dans le README du projet : **Nous croyons que tout le monde devrait avoir le contrôle sur ses propres données.**
|
||||
|
||||
### 1.3 Pourquoi l'Open Source ? La seule réponse pour la confiance
|
||||
|
||||
Pour un outil qui prétend "confidentialité et sécurité" comme valeur centrale, être en code fermé est une contradiction en soi. Comment les utilisateurs peuvent-ils faire confiance à vos promesses ?
|
||||
|
||||
Par conséquent, l'open source était le choix inévitable et la seule réponse.
|
||||
|
||||
- **Pour construire la confiance** : Le code est la meilleure preuve. Nous rendons tout notre code public pour être examiné par le monde, construisant ainsi une confiance incontestable.
|
||||
- **Le pouvoir de la communauté** : Je suis bien conscient que le pouvoir d'un individu est limité. Je crois que la sagesse collective de la communauté peut aider à trouver des défauts que j'ai manqués et suggérer des fonctionnalités auxquelles je n'ai jamais pensé, aidant PrivyDrop à aller plus loin et à devenir plus robuste.
|
||||
- **Pour donner en retour et apprendre** : J'ai énormément bénéficié de la communauté open source, et maintenant c'est mon tour de donner en retour. Mettre le projet en open source est à la fois une façon d'apprendre de développeurs talentueux et une joie de partager.
|
||||
|
||||
## Partie 2 : Une plongée en profondeur dans l'architecture : Une pratique "de qualité production"
|
||||
|
||||
PrivyDrop n'est pas juste un projet jouet. Dans sa conception architecturale, nous avons poursuivi la simplicité, l'efficacité et la scalabilité, s'efforçant d'atteindre les standards de qualité production.
|
||||
|
||||
### 2.1 La vue d'ensemble : Un système simple et efficace
|
||||
|
||||
Notre principe de conception central est : **un backend léger, un frontend intelligent**. Le backend n'agit que comme "agent de circulation" (pour la signalisation), tandis que le frontend gère tout le "travail lourd" (traitement et transfert de fichiers).
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph "Utilisateur A (Expéditeur)"
|
||||
A[Application Frontend]
|
||||
end
|
||||
subgraph "Utilisateur B (Destinataire)"
|
||||
B[Application Frontend]
|
||||
end
|
||||
subgraph "Cloud"
|
||||
C(Serveur de Signalisation - Node.js)
|
||||
D(Stockage d'État - Redis)
|
||||
end
|
||||
|
||||
A -- "1. Demander à créer/rejoindre une salle" --> C
|
||||
B -- "2. Demander à rejoindre la même salle" --> C
|
||||
C -- "3. Échanger des signaux WebRTC (SDP/ICE)" --> A
|
||||
C -- "4. Échanger des signaux WebRTC (SDP/ICE)" --> B
|
||||
A <-.-> B;
|
||||
C <--> D
|
||||
A <-. "5. Établir une connexion P2P directe" .-> B
|
||||
A -- "6. Transférer fichiers/texte directement" --> B
|
||||
|
||||
style A fill:#D5E8D4,stroke:#82B366
|
||||
style B fill:#D5E8D4,stroke:#82B366
|
||||
```
|
||||
|
||||
### 2.2 Architecture Frontend : De la séparation des préoccupations à la cohésion logique
|
||||
|
||||
Le frontend est construit avec Next.js 14, et notre philosophie de conception centrale est **d'utiliser des Hooks personnalisés comme cœur de notre logique métier**.
|
||||
|
||||
Vous pourriez demander, pourquoi pas Redux ou Zustand ? Pour PrivyDrop, la plupart de l'état est étroitement couplé avec une logique métier spécifique et hautement cohésive. Nous avons encapsulé cette logique et cet état dans une série de Hooks personnalisés (comme `useWebRTCConnection`, `useRoomManager`, `useFileTransferHandler`), ce qui a apporté plusieurs avantages clairs :
|
||||
|
||||
- **Cohésion logique** : Tout l'état et les méthodes liés à la connexion WebRTC sont dans `useWebRTCConnection`, le rendant extrêmement facile à maintenir.
|
||||
- **Composants purs** : Les composants React sont libérés de la logique métier complexe, retournant à leur rôle essentiel de rendu d'interface utilisateur.
|
||||
- **Clarté des couches** : Cela crée un flux de données clair et une relation de dépendance de `app` (routage) -> `components` (interface utilisateur) -> `hooks` (logique) -> `lib` (capacités de bas niveau), améliorant grandement la maintenabilité de la base de code.
|
||||
|
||||
### 2.3 Architecture Backend : L'art de l'étatlessness et de l'efficacité
|
||||
|
||||
Le backend, basé sur Node.js et Express, suit strictement le principe **stateless (sans état)** dans sa conception.
|
||||
|
||||
Le serveur lui-même ne détient aucun état lié aux salles ou aux utilisateurs. Tout l'état est délégué à **Redis**. Cela permet à l'application backend d'être facilement mise à l'échelle horizontalement.
|
||||
|
||||
Nous avons également utilisé intelligemment différentes structures de données Redis pour répondre aux besoins métier :
|
||||
|
||||
- **Hash** : Pour stocker les métadonnées de salle.
|
||||
- **Set** : Pour stocker le `socketId` de tous les membres dans une salle, assurant l'unicité.
|
||||
- **String** : Pour mapper inversement un `socketId` à sa `roomId`, facilitant un nettoyage rapide lorsqu'un utilisateur se déconnecte.
|
||||
- **Sorted Set** : Pour implémenter la limitation de débit basée sur IP, prévenant efficacement les attaques malveillantes.
|
||||
|
||||
Toutes les clés sont définies avec un TTL (Time To Live) raisonnable, assurant le nettoyage automatique des ressources et permettant au système de fonctionner de manière stable à long terme.
|
||||
|
||||
### 2.4 Considérations "de qualité production" : Du déploiement à la sécurité
|
||||
|
||||
Nous fournissons un plan complet de déploiement en production, incluant :
|
||||
|
||||
- Utilisation de **Nginx** comme proxy inverse et pour terminaison SSL.
|
||||
- Utilisation de **PM2** pour la gestion des processus Node.js.
|
||||
- Utilisation de **Certbot** pour l'acquisition et le renouvellement automatiques des certificats SSL.
|
||||
- Un guide complet pour configurer un serveur **TURN/STUN** pour les scénarios nécessitant le traversal de NATs complexes.
|
||||
|
||||
Tout cela démontre que PrivyDrop est un projet sérieux qui peut être approuvé et déployé dans un environnement de production.
|
||||
|
||||
## Partie 3 : Plus que du code : Une invitation à construire l'avenir
|
||||
|
||||
L'open source n'est que le début. Nous avons planifié un avenir passionnant pour PrivyDrop, et maintenant, nous voulons vous inviter à nous rejoindre.
|
||||
|
||||
### 3.1 Feuille de route du projet
|
||||
|
||||
Nous avons une [<u>**Feuille de route du projet**</u>](https://github.com/david-bai00/PrivyDrop/blob/main/ROADMAP.md) publique qui décrit nos priorités futures. Nous prévoyons d'ajouter certaines fonctionnalités très demandées à l'avenir, telles que :
|
||||
|
||||
- **Transferts repriseables** : Pour gérer les très gros fichiers et les conditions réseau instables.
|
||||
- **Chat de groupe chiffré E2E** : Pour étendre la communication P2P sécurisée aux chats texte multi-utilisateurs.
|
||||
- Autres fonctionnalités à déterminer.
|
||||
|
||||
### 3.2 Comment contribuer ?
|
||||
|
||||
Nous accueillons les contributions de toutes formes ! Peu importe qui vous êtes, il y a toujours un moyen d'aider à rendre PrivyDrop meilleur. Veuillez lire nos [<u>**Directives de contribution**</u>](https://github.com/david-bai00/PrivyDrop/blob/main/.github/CONTRIBUTING.md) pour commencer votre voyage.
|
||||
|
||||
- **Pour les utilisateurs** : Utilisez le produit, signalez des bugs et suggérez des fonctionnalités via les [GitHub Issues](https://github.com/david-bai00/PrivyDrop/issues).
|
||||
- **Pour les développeurs** : Réclamez un bug, implémentez une nouvelle fonctionnalité, ou refactorez un morceau de code existant.
|
||||
- **Pour les documentaristes/traducteurs** : Aidez-nous à améliorer la documentation ou traduisez PrivyDrop en plus de langues.
|
||||
|
||||
### 3.3 Un fort appel à l'action
|
||||
|
||||
- **Pour les utilisateurs** : Expérimentez maintenant la confidentialité et la commodité ultimes avec PrivyDrop !
|
||||
[**➡️ Essayez-le en Direct**](https://www.privydrop.app/)
|
||||
|
||||
- **Pour les développeurs** : Si la philosophie ou la technologie de PrivyDrop vous excite, veuillez donner une Étoile à notre dépôt GitHub ! C'est la plus grande reconnaissance et encouragement pour nous.
|
||||
[**⭐️ Donnez-nous une Étoile sur GitHub**](https://github.com/david-bai00/PrivyDrop)
|
||||
|
||||
- **Pour tous** : Rejoignez nos discussions communautaires et laissez-nous entendre votre voix !
|
||||
|
||||
## Conclusion
|
||||
|
||||
Merci encore d'avoir pris le temps de lire cette histoire.
|
||||
|
||||
L'histoire de PrivyDrop a commencé avec le besoin d'une personne, et j'attends avec impatience que son avenir soit écrit par une communauté.
|
||||
@@ -0,0 +1,159 @@
|
||||
---
|
||||
title: "PrivyDropをオープンソースにした理由：プライバシー、WebRTC、そしてコミュニティ育成の物語"
|
||||
description: "PrivyDropが正式にオープンソースになりました！この記事では、個人的なニーズから生産レベルのプライベートファイル転送ツールへと進化した道のりを語り、そのアーキテクチャを深く掘り下げ、未来を共に築くための招待状です。"
|
||||
date: "2025-07-07"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/privydrop-open-source.jpg"
|
||||
tags: [オープンソース, WebRTC, プライバシー, セキュリティ, Next.js, Node.js]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## はじめに
|
||||
|
||||
本日、心を込めて開発してきた個人プロジェクトである**PrivyDrop**が、正式にオープンソースとなりましたことを、心より誇りに思います！
|
||||
|
||||
[**今すぐ体験 »**](https://www.privydrop.app/) | [**GitHubリポジトリ »**](https://github.com/david-bai00/PrivyDrop)
|
||||
|
||||
このプロジェクトは、非常にシンプルな個人的なニーズから始まりました：「スマートフォンとコンピューターの間で、安全かつ簡単にファイルを送信したいだけ。」
|
||||
|
||||
もしあなたも私のように、登録不要、速度制限なし、真にプライバシーを尊重するファイル共有ツールを探して困った経験があるなら、この記事はあなたのためのものです。自分自身の「痒いところに手が届く」ツール開発の物語を共有するだけでなく、PrivyDropの中核的なアーキテクチャと設計哲学を探求する完全な「舞台裏」ツアーをご案内します。そして最も重要なこととして、あなたをこの物語の次の章の共同執筆者として招待します。
|
||||
|
||||
## 第1部：ツールの誕生：「私が必要」から「皆が使える」へ
|
||||
|
||||
### 1.1 開発者自身の痒いところに手を届ける物語
|
||||
|
||||
すべては、私の日々のワークフローにおける小さくも持続的な痛みから始まりました。
|
||||
|
||||
私は頻繁にスマートフォンとノートパソコンの間でファイル、スクリーンショット、テキストの断片を素早く送信する必要がありました。多くのツールを試しましたが、どれも私の要求を完全には満たしていませんでした：
|
||||
|
||||
- 一部のオンラインP2Pツールは強力でしたが、ファイルしか送信できず、軽量なテキストやリンクを送信するニーズには応えられませんでした。
|
||||
- 一部のオンラインクリップボードはテキストを便利に同期できましたが、クリップボードの内容を未知のサーバーにアップロードすることに深い懸念を感じました。
|
||||
- そして主流のクラウドストレージやソーシャルアプリは、ログインが必要か、サイズと速度の制限があり、プロセス全体を重くて面倒なものにしていました。
|
||||
|
||||
「**高速、プライベート、アカウント不要**」という3つの中核要件を完全に満たすツールが見つからなかった後、自分で作ることを決意しました。
|
||||
|
||||
### 1.2 個人用ツールから公開プロジェクトへ
|
||||
|
||||
当初、PrivyDropは自分自身のニーズを満たすための小さなユーティリティでした。しかし、機能を徐々に改善していくうちに、私の痛み点がおそらく多くの人々共通のものであることに気づきました。
|
||||
|
||||
データとプライバシーがますます重要になる時代において、私たちは「利便性」と「プライバシー」の間で苦痛な取引を強いられない、より良い選択に値します。この考えがPrivyDropを個人プロジェクトから堅牢で信頼性の高い公開サービスへと磨き上げる原動力となりました。
|
||||
|
||||
私たちの中核的なビジョンはシンプルで、プロジェクトのREADMEに記述した通りです：**すべての人が自分のデータをコントロールできるべきだと信じています。**
|
||||
|
||||
### 1.3 なぜオープンソースなのか？信頼の唯一の答え
|
||||
|
||||
「プライバシーとセキュリティ」を中核価値とするツールにとって、クローズドソースであること自体が矛盾です。ユーザーはどうしてあなたの約束を信頼できるのでしょうか？
|
||||
|
||||
したがって、オープンソースは必然的な選択であり、唯一の答えでした。
|
||||
|
||||
- **信頼の構築**：コードが最良の証明です。私たちはすべてのコードを公開し、世界からの監視を受けることで、議論の余地のない信頼を構築します。
|
||||
- **コミュニティの力**：個人の力には限界があることをよく知っています。コミュニティの集合的知恵が、私が見逃した欠陥を見つけたり、私が思いもよらなかった機能を提案したりして、PrivyDropをさらに進化させ、より堅牢にしてくれると信じています。
|
||||
- **還元と学習**：私はオープンソースコミュニティから多大な恩恵を受けてきました。今が還元するときです。プロジェクトをオープンソースにすることは、才能ある開発者たちから学ぶ機会であり、共有の喜びでもあります。
|
||||
|
||||
## 第2部：アーキテクチャ深掘り：「生産レベル」の実践
|
||||
|
||||
PrivyDropは単なるおもちゃプロジェクトではありません。アーキテクチャ設計において、私たちはシンプルさ、効率性、スケーラビリティを追求し、生産レベルの基準を満たすよう努めています。
|
||||
|
||||
### 2.1 全体像：シンプルで効率的なシステム
|
||||
|
||||
私たちの中核設計原則は：**軽量バックエンド、インテリジェントフロントエンド**です。バックエンドは「交通警察」（シグナリング用）としてのみ機能し、フロントエンドがすべて「重労働」（ファイル処理と転送）を担います。
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph "ユーザーA (送信者)"
|
||||
A[フロントエンドアプリ]
|
||||
end
|
||||
subgraph "ユーザーB (受信者)"
|
||||
B[フロントエンドアプリ]
|
||||
end
|
||||
subgraph "クラウド"
|
||||
C(シグナリングサーバー - Node.js)
|
||||
D(状態ストレージ - Redis)
|
||||
end
|
||||
|
||||
A -- "1. ルーム作成/参加リクエスト" --> C
|
||||
B -- "2. 同一ルーム参加リクエスト" --> C
|
||||
C -- "3. WebRTCシグナル交換 (SDP/ICE)" --> A
|
||||
C -- "4. WebRTCシグナル交換 (SDP/ICE)" --> B
|
||||
A <-.-> B;
|
||||
C <--> D
|
||||
A <-. "5. P2P直接接続確立" .-> B
|
||||
A -- "6. ファイル/テキスト直接転送" --> B
|
||||
|
||||
style A fill:#D5E8D4,stroke:#82B366
|
||||
style B fill:#D5E8D4,stroke:#82B366
|
||||
```
|
||||
|
||||
### 2.2 フロントエンドアーキテクチャ：関心の分離から論理的凝集へ
|
||||
|
||||
フロントエンドはNext.js 14で構築されており、私たちの最も中核的な設計哲学は**カスタムフックをビジネスロジックの中心とすること**です。
|
||||
|
||||
なぜReduxやZustandを使わないのかと尋ねるかもしれません。PrivyDropの場合、ほとんどの状態は特定の、高凝集なビジネスロジックと密接に関連しています。私たちは一連のカスタムフック（`useWebRTCConnection`、`useRoomManager`、`useFileTransferHandler`など）を使用してこれらのロジックと状態をカプル化し、いくつかの明らかな利点をもたらしました：
|
||||
|
||||
- **論理的凝集**：WebRTC接続に関連するすべての状態とメソッドが`useWebRTCConnection`にまとめられており、極めて保守しやすいです。
|
||||
- **純粋なコンポーネント**：Reactコンポーネントは複雑なビジネスロジックから解放され、UIレンダリングという本質的な役割に戻ります。
|
||||
- **明確な階層化**：`app`（ルーティング）→`components`（UI）→`hooks`（ロジック）→`lib`（低レベル機能）の明確なデータフローと依存関係が形成され、コードベースの保守性が大幅に向上します。
|
||||
|
||||
### 2.3 バックエンドアーキテクチャ：ステートレスと効率性の芸術
|
||||
|
||||
Node.jsとExpressに基づくバックエンドは、設計において厳密に**ステートレス（Stateless）**原則に従っています。
|
||||
|
||||
サーバー自体はルームやユーザーに関連する状態を一切保持しません。すべての状態は**Redis**に委ねられます。これにより、バックエンドアプリケーションを非常に簡単に水平スケールできます。
|
||||
|
||||
私たちはまた、ビジネスニーズを満たすためにRedisの異なるデータ構造を巧みに活用しました：
|
||||
|
||||
- **Hash**: ルームのメタデータを格納する
|
||||
- **Set**: ルーム内のすべてのメンバーの`socketId`を格納し、一意性を保証する
|
||||
- **String**: `socketId`を`roomId`に逆マッピングし、ユーザー切断時の迅速なクリーンアップを容易にする
|
||||
- **Sorted Set**: IPベースのレート制限を実装し、悪意のある攻撃を効果的に防ぐ
|
||||
|
||||
すべてのキーには合理的なTTL（有効期間）が設定されており、リソースの自動クリーンアップを保証し、システムを長期にわたり安定して実行できるようにしています。
|
||||
|
||||
### 2.4 「生産レベル」の考慮事項：デプロイメントからセキュリティまで
|
||||
|
||||
私たちは、包括的な本番環境デプロイメントプランを提供しています：
|
||||
|
||||
- **Nginx**をリバースプロキシおよびSSL終端として使用
|
||||
- **PM2**によるNode.jsプロセス管理
|
||||
- **Certbot**によるSSL証明書の自動取得と更新
|
||||
- 複雑なNATのトラバーサルが必要なシナリオのための包括的な**TURN/STUN**サーバー設定ガイド
|
||||
|
||||
これらはすべて、PrivyDropが信頼でき、本番環境にデプロイ可能な深刻なプロジェクトであることを示しています。
|
||||
|
||||
## 第3部：コードを超えて：未来を共に築くための招待
|
||||
|
||||
オープンソースは始まりにすぎません。私たちはPrivyDropのためにエキサイティングな未来を計画しており、今、あなたに参加してほしいと願っています。
|
||||
|
||||
### 3.1 プロジェクトロードマップ
|
||||
|
||||
私たちは公開の[<u>**プロジェクトロードマップ**</u>](https://github.com/david-bai00/PrivyDrop/blob/main/ROADMAP.md)を持っており、未来の優先事項を概説しています。将来的に、以下のような要望の高い機能を追加する予定です：
|
||||
|
||||
- **レジューム可能な転送**：非常に大きなファイルと不安定なネットワーク状況に対応するため
|
||||
- **E2E暗号化グループチャット**：安全なP2P通信をマルチユーザーテキストチャットに拡張する
|
||||
- その他未定の機能
|
||||
|
||||
### 3.2 貢献するには？
|
||||
|
||||
私たちはあらゆる形式の貢献を歓迎します！あなたが誰であれ、PrivyDropをより良くする方法が必ずあります。[<u>**貢献ガイドライン**</u>](https://github.com/david-bai00/PrivyDrop/blob/main/.github/CONTRIBUTING.md)をお読みいただき、あなたの旅を始めてください。
|
||||
|
||||
- **ユーザーの皆さん**：製品を使用し、[GitHub Issues](https://github.com/david-bai00/PrivyDrop/issues)を通じてバグを報告し、機能を提案してください
|
||||
- **開発者の皆さん**：バグを募集し、新機能を実装し、既存のコードをリファクタリングしてください
|
||||
- **ドキュメンター/翻訳者の皆さん**：ドキュメントの改善やPrivyDropの多言語化を手伝ってください
|
||||
|
||||
### 3.3 力強い行動喚起
|
||||
|
||||
- **ユーザーの皆さん**：今すぐPrivyDropを体験し、究極のプライバシーと利便性を感じてください！
|
||||
[**➡️ 今すぐ体験**](https://www.privydrop.app/)
|
||||
|
||||
- **開発者の皆さん**：PrivyDropの哲学や技術に目を輝かせたなら、私たちのGitHubリポジトリにStarを付けてください！それは私たちにとって最高の評価と励みになります。
|
||||
[**⭐️ GitHubでStarを付ける**](https://github.com/david-bai00/PrivyDrop)
|
||||
|
||||
- **すべての皆さん**：コミュニティディスカッションに参加し、私たちにあなたの声を聞かせてください！
|
||||
|
||||
## 結論
|
||||
|
||||
この物語を読む時間を作ってくださり、再度感謝申し上げます。
|
||||
|
||||
PrivyDropの物語は一人の人間のニーズから始まりましたが、その未来はコミュニティによって書かれることを期待しています。
|
||||
@@ -0,0 +1,159 @@
|
||||
---
|
||||
title: "PrivyDrop를 오픈소스로 만든 이유: 개인정보 보호, WebRTC, 그리고 커뮤니티 구축의 이야기"
|
||||
description: "PrivyDrop이 이제 오픈소스가 되었습니다! 이 글은 개인적인 필요에서 시작하여 프로덕션급 개인 파일 전송 도구로 발전한 과정을 설명하고, 아키텍처를 깊이 파고들며, 함께 미래를 만들어갈 당신을 초대합니다."
|
||||
date: "2025-07-07"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/privydrop-open-source.jpg"
|
||||
tags: [오픈소스, WebRTC, 개인정보 보호, 보안, Next.js, Node.js]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## 서론
|
||||
|
||||
오늘, 제가 마음과 영혼을 쏟아부은 개인 프로젝트인 **PrivyDrop**이 공식적으로 오픈소스가 되었음을 매우 기쁘게 알려드립니다!
|
||||
|
||||
[**지금 바로 사용해보세요 »**](https://www.privydrop.app/) | [**GitHub 저장소 »**](https://github.com/david-bai00/PrivyDrop)
|
||||
|
||||
이 프로젝트는 매우 간단한 개인적인 필요에서 시작되었습니다: "그냥 휴대폰과 컴퓨터 사이에 안전하고 쉽게 파일을 보내고 싶어요."
|
||||
|
||||
만약 당신도 저처럼, 등록이 필요 없고 속도 제한이 없으며, 진정으로 당신의 개인정보를 존중하는 파일 공유 도구를 찾다가 좌절했다면, 이 글은 당신을 위한 것입니다. 이 글은 제 '가려운 곳을 긁는' 이야기를 공유할 뿐만 아니라, PrivyDrop의 핵심 아키텍처와 디자인 철학을 탐구하는 완전한 '비하인드 스토리' 투어를 안내할 것입니다. 그리고 가장 중요한 것은, 당신을 다음 장의 공동 저자로 초대하는 진심 어린 초대장입니다.
|
||||
|
||||
## 1부: 도구의 탄생: "내가 필요해"에서 "모두가 사용할 수 있게"까지
|
||||
|
||||
### 1.1 개발자의 자기 필요 해소 여정
|
||||
|
||||
모든 것은 제 일상 워크플로우의 작지만 지속적인 불편함에서 시작되었습니다.
|
||||
|
||||
저는 자주 휴대폰과 노트북 사이에 파일, 스크린샷, 또는 텍스트 조각을 빠르게 보내야 합니다. 많은 도구를 시도했지만, 어느 것도 제 요구사항을 완전히 만족시키지 못했습니다:
|
||||
|
||||
- 일부 온라인 P2P 도구는 강력했지만 파일만 보낼 수 있어서 가벼운 텍스트나 링크를 보내는 필요에 부응하지 못했습니다.
|
||||
- 일부 온라인 클립보드는 텍스트를 편리하게 동기화할 수 있었지만, 클립보드 내용을 알 수 없는 서버에 업로드하는 것에 대해 깊은 우려를 가졌습니다.
|
||||
- 그리고 메인스트림 클라우드 저장소나 소셜 앱은 로그인이 필요하거나 크기와 속도 제한이 있어 전체 과정이 불편하고 번거롭게 느껴졌습니다.
|
||||
|
||||
제 세 가지 핵심 요구사항—**빠르고, 사적이며, 계정이 필요 없는**—에 완벽하게 맞는 도구를 찾지 못한 후, 스스로 하나를 만들기로 결정했습니다.
|
||||
|
||||
### 1.2 개인 유틸리티에서 공개 프로젝트로
|
||||
|
||||
처음에 PrivyDrop은 제 자신의 필요를 만족시키는 작은 유틸리티였습니다. 하지만 점차 기능을 개선하면서 제 불편함이 아마도 많은 사람들의 공통된 불편함일 것이라는 것을 깨달았습니다.
|
||||
|
||||
데이터와 개인정보 보호가 점점 더 중요해지는 시대에서, 우리는 "편리함"과 "개인정보 보호" 사이에서 고통스러운 타협을 강요받지 않는 더 나은 선택을 가치 있습니다. 이 아이디어는 PrivyDrop을 개인 프로젝트에서 견고하고 신뢰할 수 있는 공개 서비스로 다듬게 하는 원동력이 되었습니다.
|
||||
|
||||
저희의 핵심 비전은 간단합니다. 프로젝트 README에 쓴 것처럼: **우리는 모든 사람이 자신의 데이터를 통제할 수 있어야 한다고 믿습니다.**
|
||||
|
||||
### 1.3 왜 오픈소스인가? 신뢰를 위한 유일한 답
|
||||
|
||||
"개인정보 보호와 보안"을 핵심 가치로 주장하는 도구에 있어, 소스 코드를 닫는 것은 그 자체로 모순입니다. 사용자들이 어떻게 당신의 약속을 신뢰할 수 있을까요?
|
||||
|
||||
따라서 오픈소스는 필연적인 선택이자 유일한 답이었습니다.
|
||||
|
||||
- **신뢰 구축**: 코드가 최고의 증거입니다. 저희는 세계의 검토를 받을 수 있도록 모든 코드를 공개하여, 논쟁의 여지가 없는 신뢰를 구축하고 있습니다.
|
||||
- **커뮤니티의 힘**: 개인의 힘은 제한적이라는 것을 잘 알고 있습니다. 커뮤니티의 집단 지성이 제가 놓친 결함을 발견하고 제가 상상하지 못했던 기능을 제안하여, PrivyDrop이 더 나아가고 더 견고해지도록 도울 수 있다고 믿습니다.
|
||||
- **보답과 학습**: 저는 오픈소스 커뮤니티에서 엄청난 혜택을 받았고, 이제 제가 보답할 차례입니다. 프로젝트를 오픈소스로 만드는 것은 재능 있는 개발자들로부터 배우는 기회이자 공유의 기쁨입니다.
|
||||
|
||||
## 2부: 아키텍처 심층 분석: "프로덕션급" 실천
|
||||
|
||||
PrivyDrop은 단순한 장난감 프로젝트가 아닙니다. 아키텍처 설계에서 저희는 단순함, 효율성, 확장성을 추구하며 프로덕션급 표준을 만족시키기 위해 노력했습니다.
|
||||
|
||||
### 2.1 큰 그림: 단순하고 효율적인 시스템
|
||||
|
||||
저희의 핵심 설계 원칙은: **가벼운 백엔드, 지능적인 프론트엔드**입니다. 백엔드는 "교통 경찰"(시그널링용)으로만 작동하고, 프론트엔드는 모든 "무거운 작업"(파일 처리와 전송)을 처리합니다.
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph "사용자 A (발신자)"
|
||||
A[프론트엔드 앱]
|
||||
end
|
||||
subgraph "사용자 B (수신자)"
|
||||
B[프론트엔드 앱]
|
||||
end
|
||||
subgraph "클라우드"
|
||||
C(시그널링 서버 - Node.js)
|
||||
D(상태 저장소 - Redis)
|
||||
end
|
||||
|
||||
A -- "1. 방 생성/참여 요청" --> C
|
||||
B -- "2. 동일 방 참여 요청" --> C
|
||||
C -- "3. WebRTC 신호 교환 (SDP/ICE)" --> A
|
||||
C -- "4. WebRTC 신호 교환 (SDP/ICE)" --> B
|
||||
A <-.-> B;
|
||||
C <--> D
|
||||
A <-. "5. P2P 직접 연결 설정" .-> B
|
||||
A -- "6. 파일/텍스트 직접 전송" --> B
|
||||
|
||||
style A fill:#D5E8D4,stroke:#82B366
|
||||
style B fill:#D5E8D4,stroke:#82B366
|
||||
```
|
||||
|
||||
### 2.2 프론트엔드 아키텍처: 관심사 분리에서 논리적 응집까지
|
||||
|
||||
프론트엔드는 Next.js 14로 구축되었으며, 저희의 핵심 설계 철학은 **사용자 정의 Hooks를 비즈니스 로직의 핵심으로 사용**하는 것입니다.
|
||||
|
||||
왜 Redux나 Zustand를 사용하지 않았는지 물을 수 있습니다. PrivyDrop의 경우, 대부분의 상태가 특정하고 응집도가 높은 비즈니스 로직과 밀접하게 결합되어 있습니다. 저희는 일련의 사용자 정의 Hooks(`useWebRTCConnection`, `useRoomManager`, `useFileTransferHandler` 등)를 사용하여 이 로직과 상태를 캡슐화했으며, 이는 몇 가지 명확한 이점을 가져왔습니다:
|
||||
|
||||
- **논리적 응집**: WebRTC 연결과 관련된 모든 상태와 메서드가 `useWebRTCConnection`에 있어 유지보수가 극도로 쉽습니다.
|
||||
- **순수 컴포넌트**: React 컴포넌트는 복잡한 비즈니스 로직에서 해방되어 UI 렌더링이라는 본질적인 역할로 돌아갑니다.
|
||||
- **명확한 계층화**: 이것은 `app` (라우팅) -> `components` (UI) -> `hooks` (로직) -> `lib` (저수준 기능)의 명확한 데이터 흐름과 의존 관계를 만들어 코드베이스의 유지보수성을 크게 향상시킵니다.
|
||||
|
||||
### 2.3 백엔드 아키텍처: 무상태성과 효율성의 예술
|
||||
|
||||
Node.js와 Express 기반의 백엔드는 설계에서 엄격하게 **무상태(Stateless)** 원칙을 따릅니다.
|
||||
|
||||
서버 자체는 방이나 사용자와 관련된 상태를 유지하지 않습니다. 모든 상태는 **Redis**에 위임됩니다. 이를 통해 백엔드 애플리케이션을 매우 쉽게 수평적으로 확장할 수 있습니다.
|
||||
|
||||
저희는 또한 비즈니스 요구를 충족시키기 위해 Redis의 다양한 데이터 구조를 교묘하게 활용했습니다:
|
||||
|
||||
- **Hash**: 방 메타데이터를 저장하기 위해
|
||||
- **Set**: 방 내 모든 멤버의 `socketId`를 저장하여 고유성 보장
|
||||
- **String**: `socketId`를 `roomId`로 역매핑하여 사용자 연결 끊김 시 빠른 정리 용이화
|
||||
- **Sorted Set**: IP 기반 속도 제한을 구현하여 악의적인 공격 효과적으로 방지
|
||||
|
||||
모든 키는 합리적인 TTL(Time To Live)로 설정되어 자동 리소스 정리를 보장하고 시스템이 장기적으로 안정적으로 실행되도록 합니다.
|
||||
|
||||
### 2.4 "프로덕션급" 고려사항: 배포에서 보안까지
|
||||
|
||||
저희는 포괄적인 프로덕션 배포 계획을 제공합니다:
|
||||
|
||||
- **Nginx**를 리버스 프록시 및 SSL 종료로 사용
|
||||
- **PM2**를 통한 Node.js 프로세스 관리
|
||||
- **Certbot**을 통한 SSL 인증서 자동 획득 및 갱신
|
||||
- 복잡한 NAT 통과가 필요한 시나리오를 위한 포괄적인 **TURN/STUN** 서버 설정 가이드
|
||||
|
||||
이 모든 것은 PrivyDrop이 신뢰할 수 있고 프로덕션 환경에 배포할 수 있는 심각한 프로젝트임을 보여줍니다.
|
||||
|
||||
## 3부: 코드를 넘어서: 미래를 함께 만들기 위한 초대
|
||||
|
||||
오픈소스는 시작일 뿐입니다. 저희는 PrivyDrop을 위해 흥미로운 미래를 계획하고 있으며, 이제 당신이 저희와 함께하기를 원합니다.
|
||||
|
||||
### 3.1 프로젝트 로드맵
|
||||
|
||||
저희는 미래의 우선순위를 개요하는 공개 [<u>**프로젝트 로드맵**</u>](https://github.com/david-bai00/PrivyDrop/blob/main/ROADMAP.md)을 가지고 있습니다. 미래에 다음과 같이 많은 요청이 있었던 기능들을 추가할 계획입니다:
|
||||
|
||||
- **재개 가능한 전송**: 매우 큰 파일과 불안정한 네트워크 상황을 처리하기 위해
|
||||
- **E2E 암호화 그룹 채팅**: 안전한 P2P 통신을 다중 사용자 텍스트 채팅으로 확장
|
||||
- 기타 미정 기능
|
||||
|
||||
### 3.2 기여하는 방법?
|
||||
|
||||
저희는 모든 형태의 기여를 환영합니다! 당신이 누구든, PrivyDrop을 더 나게 만드는 방법이 항상 있습니다. 당신의 여정을 시작하기 위해 저희의 [<u>**기여 가이드라인**</u>](https://github.com/david-bai00/PrivyDrop/blob/main/.github/CONTRIBUTING.md)을 읽어주세요.
|
||||
|
||||
- **사용자**: 제품을 사용하고, [GitHub Issues](https://github.com/david-bai00/PrivyDrop/issues)를 통해 버그를 보고하고 기능을 제안하세요
|
||||
- **개발자**: 버그를 담당하고, 새로운 기능을 구현하거나, 기존 코드의 일부를 리팩토링하세요
|
||||
- **문서 작성자/번역가**: 문서 개선을 도와주시거나 PrivyDrop을 더 많은 언어로 번역해주세요
|
||||
|
||||
### 3.3 강력한 행동 촉구
|
||||
|
||||
- **사용자**: 지금 바로 PrivyDrop을 경험하고 궁극의 개인정보 보호와 편리함을 느껴보세요!
|
||||
[**➡️ 지금 바로 사용해보세요**](https://www.privydrop.app/)
|
||||
|
||||
- **개발자**: PrivyDrop의 철학이나 기술에 감명받았다면, 저희 GitHub 저장소에 Star를 주세요! 이것은 저희에게 가장 큰 인정과 격려입니다.
|
||||
[**⭐️ GitHub에서 Star 주기**](https://github.com/david-bai00/PrivyDrop)
|
||||
|
||||
- **모두**: 저희 커뮤니티 토론에 참여하여 당신의 목소리를 들려주세요!
|
||||
|
||||
## 결론
|
||||
|
||||
이 이야기를 읽는 시간을 내어주셔서 다시 한번 감사드립니다.
|
||||
|
||||
PrivyDrop의 이야기는 한 사람의 필요로 시작되었고, 그 미래가 커뮤니티에 의해 쓰여지기를 기대합니다.
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
title: "Neuer Meilenstein für PrivyDrop: Wiederaufnehmbare Übertragungen beenden die Großdatei‑Angst"
|
||||
description: "Großes Update: Mit wiederaufnehmbaren Übertragungen meisterst du Netzwerkabbrüche gelassen und sendest Gigabyte‑Dateien souverän. So funktioniert’s – und so vereinen wir maximale Zuverlässigkeit mit Privatsphäre."
|
||||
date: "2025-08-01"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/privydrop-resumable-transfer.jpg"
|
||||
tags: ["Neue Funktion", "Wiederaufnehmbare Übertragungen", "Dateiübertragung", "Privatsphäre", "Open Source"]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## Einleitung: der letzte Schritt von „nutzbar“ zu „liebgewonnen“
|
||||
|
||||
In früheren Artikeln haben wir [<u>**den Open‑Source‑Geist von PrivyDrop**</u>](/blog/privydrop-open-source) und die Grundlage [<u>**WebRTC**</u>](/blog/webrtc-file-transfer) vorgestellt. Herausgekommen ist ein sicheres, privates, P2P‑basiertes Werkzeug zum Dateienteilen.
|
||||
|
||||
Doch Wert entsteht nicht nur dadurch, dass etwas „funktioniert“, sondern dadurch, wie es sich im Alltag anfühlt. Stell dir vor: Im Café mit wackeligem WLAN schickst du ein dringendes 4‑GB‑Video. Die Leiste kriecht auf 95 % – dann ein Abbruch.
|
||||
|
||||
Dieses Gefühl, im letzten Moment zu scheitern, kennen wir alle.
|
||||
|
||||
Heute machen wir den Schritt zu Ende: Wir veröffentlichen **wiederaufnehmbare Übertragungen** – und beenden die „Transfer‑Angst“ endgültig.
|
||||
|
||||
## Das Kernstück: Wie funktioniert die smarte Wiederaufnahme?
|
||||
|
||||
Bevor wir zur Anwendung kommen: Wie „merkt“ sich PrivyDrop den Fortschritt?
|
||||
|
||||
### Das Prinzip: Wie entsteht diese „Erinnerung“?
|
||||
|
||||
Denke an ein riesiges digitales Puzzle:
|
||||
|
||||
1. **Den „Bauplan“ austauschen**: Vor dem Start sendet der Sender einen Bauplan (Metadaten: Name, Gesamtgröße, Chunk‑Info). Der Empfänger sieht das große Ganze.
|
||||
2. **Nummerierte Puzzleteile**: Die Datei wird in kleine, nummerierte Stücke zerlegt. Jedes Teil landet an der vorgesehenen Stelle.
|
||||
3. **Schlauer Kassensturz nach Abbruch**: Bei Unterbrechung behält der Empfänger alle Teile. Nach dem Neuverbinden prüft er: „#1 bis #5000 habe ich – bitte ab #5001 weiter.“
|
||||
|
||||
Dieses „Inventar und Anfordern“ ist der Kern: Kein Neustart von vorn, deutlich höhere Effizienz und Zuverlässigkeit.
|
||||
|
||||
### Praxisleitfaden: richtig reibungslos wiederaufnehmen
|
||||
|
||||
So setzt du es alltagstauglich ein.
|
||||
|
||||
**Schritt 1: „Sicherheitsmodus“ aktivieren (Empfänger)**
|
||||
|
||||
Vor dem Empfang klicke **„Speicherverzeichnis festlegen“**. Damit sagst du: „Gib der Datei ein sicheres Zuhause.“ Erst dann ist die Wiederaufnahme aktiv.
|
||||
|
||||
**Schritt 2: Wenn es unterbrochen wird**
|
||||
|
||||
Netzschwankungen, Tab versehentlich geschlossen, Rechner schläft ein … keine Panik. Dein Fortschritt bleibt bestehen.
|
||||
|
||||
**Schritt 3: Doppelte Absicherung**
|
||||
|
||||
PrivyDrop bietet **zwei Schutzmechanismen**:
|
||||
|
||||
**Aktiver Schutz: „Sicher speichern“‑Button**
|
||||
|
||||
Während der Übertragung siehst du den grünen **„Sicher speichern“**‑Knopf – unser Rettungsboot für stürmische Netze.
|
||||
|
||||
- **Wann sichtbar**: Nach Wahl des Speicherorts, immer während aktiver Übertragung.
|
||||
- **Wann nutzen**: Netz wird zäh? Droht ein Abbruch? Musst du kurz weg? Jederzeit klicken.
|
||||
- **Wirkung**: Bereits empfangene Fragmente sofort auf die Platte schreiben – bereit für den nächsten Anlauf.
|
||||
|
||||
**💡 Tipp**: Keine Zeit zum Klicken? Schließen oder Neuladen der Seite hat den gleichen Schutzeffekt – der Exit‑Schutz speichert automatisch.
|
||||
|
||||
**Passiver Schutz: Exit‑Schutzmechanismus**
|
||||
|
||||
Zusätzlich greift der **Exit‑Schutzmechanismus** beim Schließen/Reload: **Schreibströme werden sauber beendet und empfangene Daten finalisiert**. Aus der temporären Datei wird ein stabiler „Speicherpunkt“.
|
||||
|
||||
Normalerweise wirft der Browser unfertige temporäre Dateien weg, wenn man eine aktive Seite schließt. PrivyDrop lässt deinen Einsatz nicht verpuffen.
|
||||
|
||||
**Schritt 4: Nahtlose Wiederaufnahme**
|
||||
|
||||
Betritt mit dem Sender erneut denselben Raum und starte die Übertragung. Die Leiste springt an die alte Position und läuft gelassen weiter. Voilà.
|
||||
|
||||
## Von der „Einzelaufgabe“ zur „laufenden Zusammenarbeit“: dein privater Datenkanal
|
||||
|
||||
Nach der Zuverlässigkeit kommt die Natürlichkeit. Statt „jedes Mal von vorn“ bietet PrivyDrop einen **persistenten privaten Datenkanal**.
|
||||
|
||||
Sobald ihr verbunden seid, wird der Raum zum gemeinsamen „Büro“. Inhalte teilt ihr fortlaufend, ohne den Zyklus „Raum erstellen, Link teilen“ ständig zu wiederholen.
|
||||
|
||||
1. Du sendest zunächst einen erklärenden Text aus der Zwischenablage.
|
||||
2. Danach ziehst du ein Mockup (PNG) rüber.
|
||||
3. Direkt im Anschluss eine Mappe mit allen Assets.
|
||||
|
||||
So fließend wie ein Gespräch am Schreibtisch nebenan. Aus einem „Einmal‑Tool“ wird ein **leichtgewichtiger, hochprivater Echtzeit‑Kollaborationsraum**.
|
||||
|
||||
## Wenn „Zuverlässigkeit“ auf „Privatsphäre“ trifft
|
||||
|
||||
Kostet die neue Stärke Privatsphäre?
|
||||
|
||||
**Nein.** Wir bauen Funktionen auf einem Fundament aus Privacy & Security.
|
||||
|
||||
- **Wiederaufnahme & Ende‑zu‑Ende‑Verschlüsselung**: Auch Fragmente sind per DTLS Ende‑zu‑Ende verschlüsselt – Browser zu Browser. Der Server kann nichts einsehen, zusammensetzen oder speichern.
|
||||
- **„Unbegrenzte Größe“ × „Wiederaufnahme“**: Unser Gold‑Duo. Größenlimit frei ist das Versprechen; Wiederaufnahme ist die Versicherung. Ganze Festplatten oder große Datasets? Nur zu – ohne Angst, Fortschritt zu verlieren.
|
||||
- **Open‑Source‑Vertrauen**: Nicht nur Behauptung, sondern Einsicht in den Code: Alles liegt offen im [<u>**GitHub‑Repository**</u>](https://github.com/david-bai00/PrivyDrop).
|
||||
|
||||
## Fazit: Willkommen zur „furchtlosen“ Übertragung
|
||||
|
||||
PrivyDrop ist mehr als ein Werkzeug – es wird dein verlässlicher Partner für persönliche und berufliche Daten.
|
||||
|
||||
Besuche [<u>**privydrop.app**</u>](https://www.privydrop.app), schnapp dir die größte Datei und **aktualisiere die Seite absichtlich während der Übertragung**. Spüre, wie beruhigend „Wiederfinden“ ist.
|
||||
|
||||
Und wenn dich robuste, verlässliche Tools begeistern, gib uns einen Stern auf [<u>**GitHub**</u>](https://github.com/david-bai00/PrivyDrop). Danke für deinen Rückenwind!
|
||||
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
title: "Nuevo hito de PrivyDrop: transferencias reanudables para decir adiós a la ansiedad de los archivos gigantes"
|
||||
description: "PrivyDrop se renueva: la nueva transferencia reanudable te permite afrontar cortes de red y mover archivos de varios gigas sin miedo. Descubre cómo funciona y cómo unimos fiabilidad extrema y privacidad."
|
||||
date: "2025-08-01"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/privydrop-resumable-transfer.jpg"
|
||||
tags: ["Nueva función", "Transferencias reanudables", "Transferencia de archivos", "Privacidad", "Código abierto"]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## Introducción: el último tramo de “usable” a “disfrutable”
|
||||
|
||||
En artículos anteriores presentamos [<u>**el espíritu de código abierto de PrivyDrop**</u>](/blog/privydrop-open-source) y la tecnología que lo sostiene, [<u>**WebRTC**</u>](/blog/webrtc-file-transfer). Construimos una herramienta de intercambio de archivos segura y privada, basada en P2P.
|
||||
|
||||
Pero el valor real no está solo en que “funcione”, sino en cómo se siente en el mundo real. Imagina que, con el Wi‑Fi inestable de una cafetería, envías un vídeo de 4 GB urgente a un cliente. La barra sube… 95%… y de pronto, la red cae.
|
||||
|
||||
Esa punzada de frustración al final, la conocemos bien.
|
||||
|
||||
Hoy nos alegra anunciar que PrivyDrop ha recorrido ese último tramo. Lanzamos oficialmente las **transferencias reanudables**, para poner fin a tu “ansiedad de transferencia”.
|
||||
|
||||
## La pieza clave: ¿cómo funcionan las transferencias reanudables inteligentes?
|
||||
|
||||
Antes de usarlas, quizá te preguntes: ¿cómo “recuerda” PrivyDrop el progreso?
|
||||
|
||||
### El principio al desnudo: ¿cómo se logra esa “memoria”?
|
||||
|
||||
Nos gusta compararlo con montar un gran rompecabezas digital:
|
||||
|
||||
1. **Intercambiar el “plano”**: Antes de empezar, el emisor envía un “plano” del archivo (metadatos: nombre, tamaño total, información de fragmentos). El receptor entiende el cuadro completo.
|
||||
2. **Piezas numeradas**: El archivo se divide en pequeños fragmentos numerados. El receptor coloca cada pieza en su lugar según llega.
|
||||
3. **Inventario inteligente tras la interrupción**: Si se corta, el receptor conserva las piezas recibidas. Al reconectar, revisa el plano y le dice al emisor: “tengo la #1 a la #5000, empieza por la #5001”.
|
||||
|
||||
Este mecanismo de “inventario y petición” evita empezar de cero y eleva la eficiencia y fiabilidad en archivos grandes.
|
||||
|
||||
### Guía práctica: cómo dominar la reanudación
|
||||
|
||||
Veamos cómo aprovecharla de verdad.
|
||||
|
||||
**Paso 1: Activa el “modo seguro” (receptor)**
|
||||
|
||||
Antes de recibir, pulsa **“Establecer carpeta de guardado”**. Es crucial: le dices a PrivyDrop “prepara un hogar seguro para el archivo que llega”. Así se activa la reanudación.
|
||||
|
||||
**Paso 2: Cuando haya una interrupción**
|
||||
|
||||
Variaciones de red, cerrar la pestaña por error, suspensión del equipo… cuando pase, calma. Tu progreso está a salvo.
|
||||
|
||||
**Paso 3: Doble protección, tranquilidad real**
|
||||
|
||||
PrivyDrop ofrece **dos capas de protección**:
|
||||
|
||||
**Protección activa: botón "Guardado seguro"**
|
||||
|
||||
Mientras se transfiere, verás un botón verde **“Guardado seguro”**. Es el “bote salvavidas” para mares agitados.
|
||||
|
||||
- **Cuándo aparece**: Tras elegir la carpeta de guardado, estará ahí siempre que haya transferencia en curso.
|
||||
- **Cuándo usarlo**: ¿La red va pesada? ¿Temes un corte? ¿Te ausentas un momento? Haz clic cuando quieras.
|
||||
- **Qué hace**: Vuelca inmediatamente los fragmentos recibidos al disco y deja todo listo para reanudar.
|
||||
|
||||
**💡 Consejo**: Si no te da tiempo a pulsarlo, cerrar o recargar la página activa el mismo resguardo: el mecanismo de salida guarda el progreso automáticamente.
|
||||
|
||||
**Protección pasiva: Mecanismo de Protección al Salir**
|
||||
|
||||
Además, el **Mecanismo de Protección al Salir** intercepta el cierre/recarga y actúa como un archivero responsable: **cierra con elegancia la escritura en disco y consolida los datos ya recibidos**. El archivo temporal se convierte en un “punto de guardado” listo para la siguiente sesión.
|
||||
|
||||
Normalmente, si cierras una página con una descarga activa, el navegador puede descartar el temporal y perder datos. Con PrivyDrop, tu esfuerzo no se desperdicia.
|
||||
|
||||
**Paso 4: Reanudación sin costuras**
|
||||
|
||||
Vuelve con el emisor a la misma sala y reinicia la transferencia. Verás la barra saltar al punto exacto y seguir su camino. Eso es reanudar.
|
||||
|
||||
## De la “tarea única” a la “colaboración continua”: tu canal de datos privado
|
||||
|
||||
Resuelta la fiabilidad, queríamos que el intercambio fuera natural. Las herramientas tradicionales son “una y otra vez”. PrivyDrop ofrece un **canal privado persistente**.
|
||||
|
||||
Una vez conectados, la sala es vuestro “despacho” compartido. Compartid contenido sin repetir “crear sala, compartir enlace”.
|
||||
|
||||
1. Envías un texto por el portapapeles.
|
||||
2. Al recibirlo, arrastras un mockup (PNG).
|
||||
3. Al terminar, arrastras una carpeta con todos los recursos.
|
||||
|
||||
El flujo es conversacional, como con un colega al lado. Así, PrivyDrop deja de ser un “pasador de archivos” para ser un **espacio de colaboración ligero y privado en tiempo real**.
|
||||
|
||||
## Cuando la “fiabilidad” se da la mano con la “privacidad”
|
||||
|
||||
¿Todo esto sacrifica la privacidad?
|
||||
|
||||
**En absoluto**. Cada función se construye sobre privacidad y seguridad.
|
||||
|
||||
- **Reanudación + cifrado extremo a extremo**: Incluso los fragmentos para reanudar viajan cifrados (DTLS) y van de navegador a navegador. El servidor no puede inspeccionar, recomponer ni almacenar nada.
|
||||
- **“Tamaño ilimitado” × “reanudación”**: Nuestra combinación dorada. Sin límite de tamaño es la promesa; la reanudación es el seguro que la cumple. Copias un disco entero o mueves datasets enormes sin miedo a perder avance.
|
||||
- **Confianza de código abierto**: No solo lo decimos: lo mostramos. Cada línea está en [<u>**GitHub**</u>](https://github.com/david-bai00/PrivyDrop), abierta al escrutinio.
|
||||
|
||||
## Cierre: te invitamos a una transferencia “sin miedo”
|
||||
|
||||
PrivyDrop ya no es solo una herramienta: es un aliado para tus datos, inmune a los sobresaltos.
|
||||
|
||||
Entra en [<u>**privydrop.app**</u>](https://www.privydrop.app), elige tu archivo más grande y **recarga a propósito a mitad de camino**. Siente la calma de recuperar el terreno.
|
||||
|
||||
Si te entusiasma crear herramientas ultraseguras y fiables, déjanos una estrella en [<u>**GitHub**</u>](https://github.com/david-bai00/PrivyDrop). ¡Tu apoyo nos impulsa!
|
||||
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
title: "Nouveau cap pour PrivyDrop : des transferts reprenables pour en finir avec l’angoisse des gros fichiers"
|
||||
description: "PrivyDrop s’étoffe : la reprise de transfert permet d’affronter les coupures réseau et d’envoyer des fichiers de plusieurs Go sans crainte. Voici le fonctionnement et l’alliance fiabilité/confidentialité."
|
||||
date: "2025-08-01"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/privydrop-resumable-transfer.jpg"
|
||||
tags: ["Nouvelle fonctionnalité", "Transferts reprenables", "Transfert de fichiers", "Confidentialité", "Open source"]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## Introduction : le dernier pas de « utilisable » à « agréable »
|
||||
|
||||
Nous avons déjà présenté [<u>**l’esprit open‑source de PrivyDrop**</u>](/blog/privydrop-open-source) et la technologie au cœur du projet, [<u>**WebRTC**</u>](/blog/webrtc-file-transfer). Nous avons bâti un partage de fichiers sûr et privé, en P2P.
|
||||
|
||||
Mais la valeur d’un outil ne tient pas qu’à « ça marche », elle tient à la sensation d’usage. Imagine : au café, Wi‑Fi capricieux, tu envoies un rendu vidéo de 4 Go. La barre grimpe à 95 %… et la connexion lâche.
|
||||
|
||||
Cette défaite à la dernière seconde, on l’a tous vécue.
|
||||
|
||||
Aujourd’hui, nous franchissons ce pas final : nous lançons les **transferts reprenables**, pour mettre un terme à l’angoisse des transferts.
|
||||
|
||||
## L’arme maîtresse : comment fonctionne la reprise intelligente ?
|
||||
|
||||
Avant la prise en main : comment PrivyDrop « se souvient‑il » de l’avancée ?
|
||||
|
||||
### Le principe : d’où vient cette « mémoire » ?
|
||||
|
||||
Pense à un gigantesque puzzle numérique :
|
||||
|
||||
1. **Échanger le « plan »** : Avant d’envoyer, l’expéditeur partage un plan (métadonnées : nom, taille, fragments). Le destinataire voit l’ensemble.
|
||||
2. **Des pièces numérotées** : Le fichier est découpé en petits morceaux numérotés. Chaque pièce est posée à sa place.
|
||||
3. **Inventaire malin après coupure**: À l’interruption, le destinataire garde ses pièces. À la reconnexion, il vérifie et dit : « j’ai #1 à #5000, reprenons à #5001 ».
|
||||
|
||||
Ce mécanisme « inventaire + requête » évite le redémarrage et booste efficacité et fiabilité sur les gros volumes.
|
||||
|
||||
### Guide pratique : bien utiliser la reprise
|
||||
|
||||
Passons au concret.
|
||||
|
||||
**Étape 1 : activer le « mode sûr » (réception)**
|
||||
|
||||
Avant de recevoir, clique **« Définir le dossier de sauvegarde »**. Tu indiques à PrivyDrop : « prépare un foyer sûr ». La reprise s’active alors.
|
||||
|
||||
**Étape 2 : quand une coupure survient**
|
||||
|
||||
Réseau fluctuant, onglet fermé, mise en veille… garde ton calme. La progression est préservée.
|
||||
|
||||
**Étape 3 : double protection pour l’esprit tranquille**
|
||||
|
||||
PrivyDrop offre **deux protections** :
|
||||
|
||||
**Protection active : bouton "Enregistrement sécurisé"**
|
||||
|
||||
Pendant l’envoi, un bouton vert **« Enregistrement sécurisé »** apparaît. Notre canot de sauvetage pour mers agitées.
|
||||
|
||||
- **Quand il s’affiche** : après choix du dossier, tant qu’un transfert est en cours.
|
||||
- **Quand cliquer** : réseau lent ? crainte d’une coupure ? besoin de s’absenter ? à tout moment.
|
||||
- **Effet** : écrit immédiatement les fragments reçus sur le disque, prêt pour la reprise.
|
||||
|
||||
**💡 Astuce** : Pas le temps de cliquer ? Fermer ou recharger la page déclenche la même protection : le mécanisme de sortie sauvegarde automatiquement.
|
||||
|
||||
**Protection passive : mécanisme de protection à la fermeture**
|
||||
|
||||
En plus, le **mécanisme de protection à la fermeture** intercepte la sortie : **flux d’écriture soigneusement fermés, données déjà reçues finalisées**. Le temporaire devient un « point de sauvegarde » solide.
|
||||
|
||||
En temps normal, fermer une page en téléchargement peut faire perdre le fichier temporaire. Avec PrivyDrop, rien n’est perdu.
|
||||
|
||||
**Étape 4 : reprise sans couture**
|
||||
|
||||
Reviens avec l’expéditeur dans la même salle et relance. La barre saute au bon endroit et continue paisiblement. C’est la magie de la reprise.
|
||||
|
||||
## De la « tâche unique » à la « collaboration continue » : ton canal privé
|
||||
|
||||
Après la fiabilité, la fluidité. Plutôt que « recommencer à chaque fois », PrivyDrop propose un **canal de données privé persistant**.
|
||||
|
||||
Une fois connectés, la salle devient votre « bureau » partagé. Partage en continu, sans recréer/renvoyer le lien.
|
||||
|
||||
1. Tu envoies un texte par le presse‑papiers.
|
||||
2. Puis tu déposes une maquette (PNG).
|
||||
3. Ensuite un dossier avec tous les assets.
|
||||
|
||||
Le tout se déroule comme une conversation. PrivyDrop passe d’un « utilitaire ponctuel » à un **espace de collaboration léger, privé et temps réel**.
|
||||
|
||||
## Quand « fiabilité » rime avec « confidentialité »
|
||||
|
||||
Ces nouveautés coûtent‑elles la vie privée ?
|
||||
|
||||
**Absolument pas.** Tout repose sur la confidentialité et la sécurité.
|
||||
|
||||
- **Reprise + chiffrement de bout en bout** : Même fragmenté, tout transite chifré (DTLS) de navigateur à navigateur. Le serveur ne voit, ne recompose, ni ne stocke rien.
|
||||
- **« Taille illimitée » × « reprise »** : Notre duo doré. L’absence de limite est la promesse ; la reprise, l’assurance qui la tient. Disque entier ou dataset massif, sans peur de perdre le terrain.
|
||||
- **Confiance open‑source** : Nous montrons notre code. Tout est public dans [<u>**GitHub**</u>](https://github.com/david-bai00/PrivyDrop).
|
||||
|
||||
## Conclusion : on t’invite à un transfert « sans peur »
|
||||
|
||||
PrivyDrop n’est plus un simple outil : c’est l’allié fiable de tes données.
|
||||
|
||||
Visite [<u>**privydrop.app**</u>](https://www.privydrop.app), choisis ton plus gros fichier et **actualise exprès en plein transfert**. Ressens la sérénité du « retrouvé ».
|
||||
|
||||
Si bâtir des outils ultra‑fiables te parle, offre‑nous une étoile sur [<u>**GitHub**</u>](https://github.com/david-bai00/PrivyDrop). Merci pour ton soutien !
|
||||
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
title: "PrivyDropの新たな到達点——中断しても続く転送で、大容量の不安にさよなら"
|
||||
description: "PrivyDropが大幅アップデート。中断後にそのまま再開できるレジューム転送で、ネット切断を恐れずギガ級ファイルを軽やかに。仕組みと、最高の信頼性とプライバシーをどう両立したかを解説。"
|
||||
date: "2025-08-01"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/privydrop-resumable-transfer.jpg"
|
||||
tags: ["新機能", "レジューム転送", "ファイル転送", "プライバシー", "オープンソース"]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## はじめに：「使える」から「気持ちよく使える」へ、最後の1マイル
|
||||
|
||||
これまでの記事では、[<u>**PrivyDrop のオープンソース精神**</u>](/blog/privydrop-open-source) と、その中核にある [<u>**WebRTC**</u>](/blog/webrtc-file-transfer) を紹介してきました。私たちは、ピア・ツー・ピア（P2P）に基づく安全でプライベートなファイル共有ツールを形にしました。
|
||||
|
||||
けれど本当の価値は、「使える」ことの先にあります。たとえば、カフェの不安定な Wi‑Fi で、クライアントへ緊急の 4GB 動画を送っているとき。進捗が 95% を超えた瞬間……通信が途切れる——。
|
||||
|
||||
あの、最後の一押しで落ちる胸の底の冷たさ。誰もが一度は味わったはずです。
|
||||
|
||||
今日、PrivyDrop はその最後の1マイルを越えました。**レジューム転送（中断後の再開）**を正式に搭載し、「転送不安」と決別します。
|
||||
|
||||
## 切り札：賢いレジュームはどう動く？
|
||||
|
||||
使い方の前に少しだけ。PrivyDrop はどうやって転送の途中経過を「覚えて」いるのでしょう？
|
||||
|
||||
### 原理をひもとく：レジュームの「記憶」はこうして成り立つ
|
||||
|
||||
巨大なデジタルのジグソーパズルを組む、と想像してください。
|
||||
|
||||
1. **「設計図」を先に交換**: 転送開始前、送信側はファイルの「設計図」（メタデータ：名前・総サイズ・チャンク情報など）を受信側へ送ります。受信側は全体像を先に掴みます。
|
||||
2. **番号付きの「ピース」を受け取る**: ファイルは小さなデータ片に分割され、番号順に送られます。受信側は受け取るたび、設計図の相応の位置にピースをはめ込みます。
|
||||
3. **中断後は「スマート棚卸し」**: もし中断しても、受信側は集めたピースを保持。再接続時に設計図で在庫を確認し、「1〜5000 は持っているので、5001 からお願い」と送信側へ伝えます。
|
||||
|
||||
この「棚卸しと要求」の仕組みこそ、レジューム転送の核。最初からやり直す無駄を取り除き、大容量でも腰の据わった信頼性を実現します。
|
||||
|
||||
### 実践ガイド：レジューム転送を正しく使いこなす
|
||||
|
||||
ここからは、現場での活かし方です。
|
||||
|
||||
**ステップ 1：『セーフモード』を有効化（受信側）**
|
||||
|
||||
受信前に必ず **「保存先フォルダを設定」** をクリックしてください。これは「これから来るファイルの安全な居場所を用意してね」という合図。ここまでして初めて、レジューム転送が起動します。
|
||||
|
||||
**ステップ 2：中断が起きたら**
|
||||
|
||||
回線の揺らぎ、誤ってタブを閉じる、PC のスリープ……中断は起こるもの。慌てずに。進捗は守られています。
|
||||
|
||||
**ステップ 3：二つの保険でスマートに守る**
|
||||
|
||||
PrivyDrop は **二重の保護** を用意しています。
|
||||
|
||||
**能動的保護：「安全保存」ボタン**
|
||||
|
||||
送受信中、画面に緑色の **「安全保存」** ボタンが現れます。ネットが不安定なときのための「救命ボート」です。
|
||||
|
||||
- **いつ出るか**: 保存先フォルダを設定後、転送が走っている間は常に表示されます。
|
||||
- **いつ使うか**: 回線が怪しい？ これから離席？ 不安を感じたらいつでも。
|
||||
- **何が起きるか**: 受信済みの断片をすぐにディスクへ確定保存。次回の再開に備えます。
|
||||
|
||||
**💡 プロのコツ**: 「安全保存」を押す余裕がないときは、ページを閉じる／更新するだけでも同等の保護が働きます。退出時の保護が自動で進捗を確定します。
|
||||
|
||||
**受動的保護：退出保護メカニズム**
|
||||
|
||||
加えて、**退出保護メカニズム** を備えています。ページを閉じる／更新する瞬間をフックし、**ディスクへの書き込みストリームを丁寧に閉じ、受信済みデータをきちんと確定**。一時ファイルを、次回再開のための安定した「セーブポイント」に変換します。
|
||||
|
||||
通常ならアクティブなダウンロードを抱えたページを突然閉じると、ブラウザは未完の一時ファイルを捨てがち。PrivyDrop は、その努力を無駄にしません。
|
||||
|
||||
**ステップ 4：シームレスに再開**
|
||||
|
||||
同じ部屋にもう一度入り直して転送を開始するだけ。進捗バーが途中からスッと復帰して、あとは着実に伸び続けます。これがレジュームの魔法です。
|
||||
|
||||
## 「単発の作業」から「続くコラボ」へ：あなた専用のデータチャネル
|
||||
|
||||
大容量転送の信頼性を解決した私たちは、体験そのものも直感的にしました。多くのツールは「1件送ったらまた最初から」。PrivyDrop は **持続的なプライベート・データチャネル** を提供します。
|
||||
|
||||
一度つながれば、その部屋は二人だけの「小さなオフィス」。リンク共有を何度もやり直す必要はありません。
|
||||
|
||||
1. まずはテキストをクリップボードで送る。
|
||||
2. 相手が受け取ったら、デザインモック（PNG）をドラッグ＆ドロップ。
|
||||
3. 送り終えたら、そのままアセット一式の入ったフォルダを投入。
|
||||
|
||||
まるで隣の同僚と会話するみたいに、流れるように。**一度きりのツール** から **軽やかでプライベートなリアルタイム協働空間** へ。PrivyDrop はその境界をまたぎます。
|
||||
|
||||
## 「信頼性」と「プライバシー」が握手するとき
|
||||
|
||||
強い機能は、プライバシーの犠牲で成り立つのか？
|
||||
|
||||
答えは **いいえ**。私たちの設計は常に、プライバシーとセキュリティを土台にしています。
|
||||
|
||||
- **レジューム転送 × エンドツーエンド暗号化**: 分割されたチャンクであっても、DTLS によるエンドツーエンド暗号化でブラウザ間を直接転送。サーバーが中身を覗く・つなぎ直す・保存する余地はありません。
|
||||
- **「サイズ無制限」×「レジューム」**: 私たちの「黄金コンボ」。サイズ無制限という約束を、レジュームが現実のものにします。丸ごと HDD をバックアップする——そんな大胆さにも伴走します。
|
||||
- **オープンソースの自信**: 口約束ではなく、実装で示す。レジュームや継続転送のコードはすべて [<u>**GitHub リポジトリ**</u>](https://github.com/david-bai00/PrivyDrop) で公開。世界中の開発者の目にさらされています。
|
||||
|
||||
## 結び：「恐れない転送」をあなたに
|
||||
|
||||
PrivyDrop は、ただのツールを越え、あなたの個人・仕事のデータを託せる相棒へ。
|
||||
|
||||
今すぐ [<u>**privydrop.app**</u>](https://www.privydrop.app) を開いて、PC の一番大きなファイルを選び、**あえて途中でページを更新** してみてください。「取り戻せる」安心が、きっと手触りになります。
|
||||
|
||||
もし私たちと同じ熱量で、強固で信頼できるツールづくりにワクワクしてくれるなら、[<u>**GitHub**</u>](https://github.com/david-bai00/PrivyDrop) に Star を。あなたの一票が、前進のエネルギーになります。
|
||||
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
title: "PrivyDrop의 새로운 이정표: 중단 후 재개 전송으로 대용량 전송 불안 끝"
|
||||
description: "네트워크 끊김에도 끄떡없는 재개 가능한 전송으로 기가바이트급 파일을 가볍게. 동작 원리와 극한의 신뢰성·프라이버시의 조화를 소개합니다."
|
||||
date: "2025-08-01"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/privydrop-resumable-transfer.jpg"
|
||||
tags: ["신규 기능", "재개 가능한 전송", "파일 전송", "프라이버시", "오픈 소스"]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## 도입: “쓸 수 있음”에서 “기분 좋게 씀”까지, 마지막 한 걸음
|
||||
|
||||
이전 글에서 [<u>**PrivyDrop의 오픈 소스 정신**</u>](/blog/privydrop-open-source)과 그 근간이 되는 [<u>**WebRTC**</u>](/blog/webrtc-file-transfer)를 소개했습니다. 우리는 P2P 기반의 안전하고 프라이빗한 파일 공유 도구를 만들었습니다.
|
||||
|
||||
하지만 진짜 가치는 “된다”를 넘어서 “잘 된다”에 있습니다. 카페의 불안정한 Wi‑Fi로 4GB 긴급 영상을 보내는 상황을 떠올려 보세요. 진행률 95%… 그 순간 연결이 뚝 끊깁니다.
|
||||
|
||||
막판에 미끄러지는 그 허탈함, 잘 압니다.
|
||||
|
||||
오늘, PrivyDrop은 그 마지막 한 걸음을 채웠습니다. **중단 후 재개 전송**을 공식 제공하여, 전송 불안을 끝냅니다.
|
||||
|
||||
## 비밀 병기: 똑똑한 재개 전송은 어떻게 동작할까?
|
||||
|
||||
사용법으로 들어가기 전, PrivyDrop은 어떻게 진행 상황을 “기억”할까요?
|
||||
|
||||
### 원리: 재개의 “기억”은 이렇게 만들어진다
|
||||
|
||||
거대한 디지털 퍼즐을 맞춘다고 상상해 보세요.
|
||||
|
||||
1. **“설계도”를 먼저 교환**: 시작 전에, 보낸 쪽이 파일의 설계도(메타데이터: 이름, 전체 크기, 청크 정보 등)를 보냅니다. 받은 쪽은 전체 그림을 미리 파악합니다.
|
||||
2. **번호 붙은 퍼즐 조각**: 파일은 잘게 나뉘어 번호가 매겨진 조각으로 전송됩니다. 받은 쪽은 조각을 설계도의 정확한 위치에 채워 넣습니다.
|
||||
|
||||
3. **중단 후의 “스마트 재고 확인”**: 끊기면 받은 쪽은 이미 받은 조각을 그대로 보관합니다. 재연결되면 설계도로 대조하고 “#1~#5000은 있으니 #5001부터 보내 주세요”라고 요청합니다.
|
||||
|
||||
이 “재고 확인 + 요청” 메커니즘이 재개 전송의 핵심입니다. 처음부터 다시 시작하는 낭비를 없애고, 대용량에서도 단단한 신뢰성을 보장합니다.
|
||||
|
||||
### 실전 가이드: 올바르게 재개를 누리는 법
|
||||
|
||||
이제 현장에서의 사용 팁입니다.
|
||||
|
||||
**1단계: ‘안전 모드’ 활성화(수신자)**
|
||||
|
||||
받기 전에 반드시 **“저장 디렉터리 설정”**을 클릭하세요. “들어올 파일의 안전한 집을 준비해”라는 신호입니다. 이 과정을 거쳐야 재개 기능이 활성화됩니다.
|
||||
|
||||
**2단계: 중단이 발생했을 때**
|
||||
|
||||
네트워크 흔들림, 실수로 탭을 닫음, 컴퓨터 절전… 일어나기 마련입니다. 침착하세요. 진행 상황은 안전합니다.
|
||||
|
||||
**3단계: 이중 보호로 더 든든하게**
|
||||
|
||||
PrivyDrop은 **이중 보호 장치**를 제공합니다.
|
||||
|
||||
**능동 보호: “안전 저장” 버튼**
|
||||
|
||||
전송 중에는 녹색 **“안전 저장”** 버튼이 보입니다. 불안정한 네트워크를 위한 우리의 구명보트입니다.
|
||||
|
||||
- **언제 보이나**: 저장 디렉터리를 설정한 뒤, 전송 중에는 항상 표시됩니다.
|
||||
- **언제 누르나**: 네트워크가 버벅이나요? 끊길 것 같나요? 잠시 자리 비우나요? 언제든지.
|
||||
- **무엇을 하나**: 수신된 조각을 즉시 디스크에 안전하게 기록하여 다음 재개를 준비합니다.
|
||||
|
||||
**💡 팁**: “안전 저장”을 누를 시간이 없어도, 페이지를 닫거나 새로고침하면 동일한 보호가 작동합니다. 종료 보호 메커니즘이 자동으로 저장합니다.
|
||||
|
||||
**수동 보호: 종료 보호 메커니즘**
|
||||
|
||||
또한 **종료 보호 메커니즘**이 있어, 페이지 종료/새로고침을 가로채고 **디스크 쓰기 스트림을 우아하게 닫아 수신 데이터를 확정**합니다. 임시 파일이 다음 재개를 위한 안정적인 “세이브 포인트”로 바뀝니다.
|
||||
|
||||
보통은 활성 다운로드 중 페이지를 닫으면 임시 파일이 버려질 수 있지만, PrivyDrop은 당신의 노력을 허공에 날리지 않습니다.
|
||||
|
||||
**4단계: 매끄러운 재개**
|
||||
|
||||
보내는 사람과 함께 같은 방에 다시 들어가 전송을 시작하세요. 진행률이 이전 지점으로 ‘툭’ 올라가고, 안정적으로 이어집니다. 이것이 재개의 마법입니다.
|
||||
|
||||
## “단발 작업”에서 “지속 협업”으로: 나만의 프라이빗 데이터 채널
|
||||
|
||||
신뢰성을 넘어, 흐름도 중요합니다. 많은 도구가 “하나 보내고 다시 처음부터”라면, PrivyDrop은 **지속되는 프라이빗 데이터 채널**을 제공합니다.
|
||||
|
||||
연결되면 방은 둘만의 “가상 오피스”가 됩니다. 매번 “방 만들기–링크 공유”를 반복할 필요가 없습니다.
|
||||
|
||||
1. 먼저 클립보드로 설명 텍스트를 보냅니다.
|
||||
2. 수신 후, 디자인 목업(PNG)을 드래그 앤 드롭합니다.
|
||||
3. 이어서 모든 에셋이 담긴 폴더를 바로 보냅니다.
|
||||
|
||||
바로 옆 동료와 대화하듯 매끈하게. 단발성 전송 도구를 넘어, **가볍고 고프라이버시의 실시간 협업 공간**으로 격상됩니다.
|
||||
|
||||
## “신뢰성”이 “프라이버시”와 만날 때
|
||||
|
||||
이 강력한 기능이 프라이버시를 희생할까요?
|
||||
|
||||
**전혀요.** 우리 설계의 토대는 언제나 프라이버시와 보안입니다.
|
||||
|
||||
- **재개 전송 × 종단 간 암호화**: 재개용 조각도 DTLS로 동일하게 암호화되어 브라우저 간 직접 전송됩니다. 서버는 내용을 볼 수도, 재조립할 수도, 저장할 수도 없습니다.
|
||||
- **“크기 제한 없음” × “재개”**: 우리의 황금 조합. “무제한” 약속을 재개가 지켜 줍니다. 하드디스크 전체 백업이나 거대한 데이터셋 전송도, 진행분 유실 걱정 없이.
|
||||
- **오픈 소스의 자신감**: 말이 아니라 코드로 증명합니다. 재개·연속 전송의 모든 코드는 [<u>**GitHub 저장소**</u>](https://github.com/david-bai00/PrivyDrop)에 공개되어 있습니다.
|
||||
|
||||
## 맺음말: “두렵지 않은 전송”으로의 초대
|
||||
|
||||
PrivyDrop은 도구를 넘어, 개인과 업무 데이터를 맡길 수 있는 믿음직한 동반자가 됩니다.
|
||||
|
||||
지금 [<u>**privydrop.app**</u>](https://www.privydrop.app)에 접속해, 가장 큰 파일을 골라 **일부러 전송 도중 새로고침**해 보세요. “되찾는 안도감”을 직접 느껴 보세요.
|
||||
|
||||
초안정·고신뢰 도구 만들기에 마음이 뜬다면, [<u>**GitHub**</u>](https://github.com/david-bai00/PrivyDrop)에서 Star로 응원해 주세요. 큰 힘이 됩니다!
|
||||
|
||||
@@ -0,0 +1,277 @@
|
||||
---
|
||||
title: "Browser-zu-Browser-Direktverbindung: Enthüllung der Kerntechnologie des datenschutzorientierten Dateitransfers basierend auf WebRTC"
|
||||
description: "Dieser Artikel taucht tief in die Kerntechnologien eines datenschutzorientierten Dateitransferwerkzeugs basierend auf WebRTC ein, einschließlich P2P-Übertragung, E2EE-Verschlüsselung und Stream-Multiplexing. Geeignet sowohl für Technikbegeisterte als auch für allgemeine Benutzer."
|
||||
date: "2025-02-09"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/webrtc-file-transfer.jpg"
|
||||
tags: [WebRTC, P2P-Übertragung, Datenschutz-Sicherheit]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## Einleitung
|
||||
|
||||
Traditionelle Dateitransfermethoden stützen sich weitgehend auf Cloud-Speicher oder zentralisierte Server, was Bedenken hinsichtlich des Datenschutzes aufwirft und gleichzeitig Beschränkungen bei Upload-Größen und Geschwindigkeitsengpässen gegenübersteht. Unser Werkzeug nutzt WebRTC-Technologie, um direkte Gerät-zu-Gerät-Übertragungen zu ermöglichen und diese Herausforderungen effektiv zu bewältigen.
|
||||
|
||||
Unser entwickeltes Werkzeug ([<u>**PrivyDrop**</u>](https://www.privydrop.app)) zeichnet sich durch mehrere bemerkenswerte Merkmale aus:
|
||||
|
||||
- Direkte Gerät-zu-Gerät-Übertragung mittels WebRTC-Technologie, ohne Zwischenserver
|
||||
- Ende-zu-Ende-Verschlüsselung (E2EE) zur Gewährleistung sicherer Datenübertragung
|
||||
- Keine Registrierung erforderlich, sofortige Nutzung, Unterstützung für mehrere gleichzeitige Empfänger
|
||||
- Unterstützung für verschiedene Datentypen einschließlich Text, Bilder, Dateien und Ordner
|
||||
- Übertragungsgeschwindigkeit und Dateigröße nur begrenzt durch Netzwerkbandbreite und Speicherplatz zwischen Geräten
|
||||
|
||||
In diesem Artikel erkunden wir die technische Architektur, die Funktionsweise und warum dieses Werkzeug eine so sichere und effiziente Dateitransfererfahrung bieten kann. Ob Sie ein Technikbegeisterter oder ein allgemeiner Benutzer sind, Sie werden Einblicke darin gewinnen, wie WebRTC-Technologie den Dateitransfer revolutioniert.
|
||||
|
||||
## I. Neubewertung des Dateitransfers: Die architektonische Revolution von WebRTC
|
||||
|
||||
WebRTC (Web Real-Time Communication) ist ein offener Standard, der Echtzeitkommunikation zwischen Browsern unterstützt. Unser auf WebRTC basierendes Dateitransferwerkzeug besteht aus mehreren Kernkomponenten:
|
||||
|
||||
1. **Signalisierungsserver**: Koordiniert Verbindungen zwischen Geräten, ohne an der eigentlichen Datenübertragung teilzunehmen.
|
||||
2. **P2P-Verbindung**: Direkte Gerät-zu-Gerät-Verbindungen ohne Eingreifen von Drittanbieterservern.
|
||||
3. **E2EE-Verschlüsselung**: Alle Daten werden während der Übertragung mittels DTLS-Protokoll ende-zu-ende verschlüsselt.
|
||||
|
||||
### 1.1 Traditioneller Ansatz vs. WebRTC-Ansatz
|
||||
|
||||
| Merkmal | Traditionelle HTTP-Übertragung | WebRTC P2P-Übertragung |
|
||||
| --- | --- | --- |
|
||||
| Übertragungspfad | Client → Server → Client | Direkte Gerät-zu-Gerät-Verbindung |
|
||||
| Latenz | Begrenzt durch zentrale Serverbandbreite | Nur begrenzt durch physische Netzwerkbandbreite |
|
||||
| Dateigrößenlimit | Üblicherweise beschränkt | Nur begrenzt durch Speicherplatz |
|
||||
| Datenschutz | Abhängig von Sicherheitsmaßnahmen des Anbieters | Zwingende Verschlüsselung durch DTLS-Protokoll |
|
||||
|
||||
### 1.2 Prozess der P2P-Verbindungsherstellung
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant UserA as Benutzer A (Sender)
|
||||
participant SignalingServer as Signalisierungsserver
|
||||
participant UserB as Benutzer B (Empfänger)
|
||||
|
||||
UserA->>SignalingServer: (1) Raum erstellen und beitreten
|
||||
activate SignalingServer
|
||||
|
||||
UserB->>SignalingServer: (2) Raum beitreten
|
||||
SignalingServer-->>UserA: Benutzer B beigetreten benachrichtigen
|
||||
|
||||
UserA->>SignalingServer: (3) WebRTC-Aushandlungsinformationen senden (SDP/ICE)
|
||||
SignalingServer-->>UserB: WebRTC-Aushandlungsinformationen weiterleiten (SDP/ICE)
|
||||
|
||||
UserB->>SignalingServer: (4) Mit WebRTC-Aushandlungsinformationen antworten (SDP/ICE)
|
||||
SignalingServer-->>UserA: Antwort-WebRTC-Aushandlungsinformationen weiterleiten (SDP/ICE)
|
||||
|
||||
UserA-->>UserB: (5) P2P-Verbindung herstellen (DataChannel)
|
||||
UserA->>UserB: (6) Datei-Chunk-Übertragung über DataChannel
|
||||
```
|
||||
|
||||
**Prozess:**
|
||||
|
||||
1. Benutzer A erstellt einen Raum und tritt bei ihm ein, verbindet sich mit dem Signalisierungsserver.
|
||||
2. Benutzer B tritt dem Raum bei und verbindet sich mit dem Signalisierungsserver.
|
||||
3. Benutzer A leitet die WebRTC-Aushandlung mit Benutzer B ein (einschließlich SDP- und ICE-Informationen).
|
||||
4. Benutzer B antwortet mit WebRTC-Aushandlungsinformationen, vervollständigt die P2P-Verbindungsherstellung.
|
||||
5. Schließlich werden Dateien über DataChannel auf der P2P-Verbindung übertragen.
|
||||
|
||||
### 1.3 Die Leistungsmagie von SCTP (over DTLS & UDP)
|
||||
|
||||
WebRTCs **DataChannel** basiert auf dem **Stream Control Transmission Protocol (SCTP)**, das über **DTLS** und **UDP** läuft, und bietet drei wesentliche Vorteile gegenüber herkömmlichem TCP:
|
||||
|
||||
1. **Stream-Multiplexing (derzeit nicht genutzt)**: Datei-Chunks können parallel übertragen werden, was die Übertragungseffizienz verbessert.
|
||||
2. **Kein Head-of-Line-Blocking**: Der Verlust eines einzelnen Chunks beeinflusst nicht den Gesamtfortschritt und gewährleistet die Übertragungsstabilität.
|
||||
3. **Automatische Überlastungssteuerung**: Dynamische Anpassung an Netzwerkschwankungen zur Optimierung der Übertragungsleistung.
|
||||
|
||||
**UDP-Vorteile:**
|
||||
|
||||
- **Niedrige Latenz**: UDP ist ein verbindungsloses Protokoll, das kein Three-Way-Handshake erfordert, ideal für Echtzeitkommunikation.
|
||||
- **Flexible Zuverlässigkeit**: Während UDP selbst unzuverlässig ist, implementiert SCTP darüber zuverlässige Übertragungsmechanismen und kombiniert die Flexibilität von UDP mit der Zuverlässigkeit von TCP.
|
||||
|
||||
**SCTP-Multi-Stream-Übertragungsdiagramm**
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Sender] --> B[DataChannel 1]
|
||||
A --> C[DataChannel 2]
|
||||
A --> D[DataChannel 3]
|
||||
B --> E[Empfänger]
|
||||
C --> E
|
||||
D --> E
|
||||
```
|
||||
|
||||
## II. Browser-Direktübertragungs-Engine: Kerntechnologie entschlüsselt
|
||||
|
||||
### 2.1 Präzise Steuerung der Chunk-Übertragung
|
||||
|
||||
```typescript
|
||||
// lib/fileSender.ts - 64KB-Festgrößen-Chunks
|
||||
|
||||
// Definiert Chunk-Größe als 65536 Bytes (64KB), um genau der Netzwerk-MTU (Maximum Transmission Unit) Größe zu entsprechen.
|
||||
// Dies verhindert Netzwerküberlastung oder Fragmentierungsprobleme durch übergroße Pakete.
|
||||
private readonly CHUNK_SIZE = 65536;
|
||||
|
||||
// Erstellt eine asynchrone Generatorfunktion zur Verarbeitung von Dateien in Festgrößen-Chunks.
|
||||
// Jeder Generatoraufruf gibt Chunk-Daten vom Typ ArrayBuffer zurück.
|
||||
private async *createChunkGenerator(file: File) {
|
||||
let offset = 0; // Initialisiert Offset zur Markierung der aktuellen Dateileseposition
|
||||
|
||||
// Schleife durch Datei, bis alle Daten verarbeitet sind
|
||||
while (offset < file.size) {
|
||||
// Verwendet File.slice-Methode, um Datensegment aus [offset, offset + CHUNK_SIZE) zu extrahieren
|
||||
const chunk = file.slice(offset, offset + this.CHUNK_SIZE);
|
||||
|
||||
// Konvertiert extrahierte Daten zu ArrayBuffer und gibt sie über yield zurück
|
||||
yield await chunk.arrayBuffer();
|
||||
|
||||
// Aktualisiert Offset für nächsten Chunk
|
||||
offset += this.CHUNK_SIZE;
|
||||
}
|
||||
}
|
||||
|
||||
// Back-Pressure-Steuerungsalgorithmus: Stellt sicher, dass Senden die DataChannel-Puffergrenzen nicht überschreitet.
|
||||
// Wenn Puffer voll ist, warten, bis Pufferspeicherplatz verfügbar wird, bevor fortgefahren wird.
|
||||
private async sendWithBackpressure(chunk: ArrayBuffer) {
|
||||
// Senden pausieren, wenn DataChannel-Puffernutzung voreingestelltes Maximum überschreitet
|
||||
while (this.dataChannel.bufferedAmount > this.MAX_BUFFER) {
|
||||
// Promise verwenden, um auf bufferedamountlow-Ereignis zu warten, das Pufferplatzfreigabe anzeigt
|
||||
await new Promise(r => this.dataChannel.bufferedamountlow = r);
|
||||
}
|
||||
|
||||
// Aktuellen Chunk senden, wenn Puffer ausreichend Platz hat
|
||||
this.dataChannel.send(chunk);
|
||||
}
|
||||
```
|
||||
|
||||
### 2.2 Zero-Copy-Speicherschreiben
|
||||
|
||||
Implementiert durch File System Access API:
|
||||
|
||||
```typescript
|
||||
// lib/fileReceiver.ts
|
||||
|
||||
// Schreibt empfangene Chunk-Daten direkt auf die Festplatte, vermeidet zusätzliche Speicherkopien
|
||||
private async writeToDisk(chunk: ArrayBuffer) {
|
||||
// Initialisiert Dateischreiber, falls noch nicht erstellt
|
||||
if (!this.writer) {
|
||||
// Dateispeicher-Dialog anzeigen, damit Benutzer Speicherort auswählen kann
|
||||
this.currentFileHandle = await window.showSaveFilePicker();
|
||||
|
||||
// Erstellt beschreibbaren Stream durch Dateihandle für nachfolgende Schreibvorgänge
|
||||
this.writer = await this.currentFileHandle.createWritable();
|
||||
}
|
||||
|
||||
// Konvertiert empfangenen ArrayBuffer zu Uint8Array und schreibt direkt auf Festplatte
|
||||
// Dies umgeht Speicherpuffer, erreicht Zero-Copy-Schreiben zur Leistungsverbesserung
|
||||
await this.writer.write(new Uint8Array(chunk));
|
||||
}
|
||||
```
|
||||
|
||||
## III. Verteiltes Raummanagementsystem
|
||||
|
||||
### 3.1 Vierstellige Kollisionserkennung:
|
||||
|
||||
```typescript
|
||||
// server.ts
|
||||
async function getAvailableRoomId() {
|
||||
let roomId;
|
||||
do {
|
||||
roomId = Math.floor(1000 + Math.random() * 9000); // Vierstellige Zufallszahl generieren
|
||||
} while (await redis.hexists(`room:${roomId}`, "created_at")); // Prüft ob existiert
|
||||
return roomId;
|
||||
}
|
||||
```
|
||||
|
||||
Hinweis: Die 4-stellige Zahl ist eine systemgenerierte zufällige Raum-ID. Sie können jede beliebige Raum-ID angeben, die Sie bevorzugen.
|
||||
|
||||
### 3.2 Elegante Ablaufstrategie:
|
||||
|
||||
```typescript
|
||||
// server.ts
|
||||
await refreshRoom(roomId, 3600 * 24); // Aktive Räume 24 Stunden behalten
|
||||
if (await isRoomEmpty(roomId)) {
|
||||
// Raum freigeben wenn leer (sowohl Sender als auch Empfänger verlassen haben)
|
||||
await deleteRoom(roomId);
|
||||
}
|
||||
```
|
||||
|
||||
### 3.3 Signalisierungsgetriebenes Wiederherstellungsprotokoll
|
||||
|
||||
Mobile Verbindungsunterbrechung-Wiederherstellungsfluss:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Sender
|
||||
participant Signaling
|
||||
participant Recipient
|
||||
|
||||
Sender->>Signaling: initiator-online senden wenn Frontend sichtbar
|
||||
Signaling->>Recipient: Online-Benachrichtigung weiterleiten
|
||||
Recipient->>Signaling: recipient-ready antworten
|
||||
Signaling->>Sender: Wiederherstellungsprozess auslösen
|
||||
Sender->>Recipient: ICE-Verbindung wiederherstellen
|
||||
```
|
||||
|
||||
Durch diesen Mechanismus kann das System Verbindungen schnell wiederherstellen, selbst wenn Benutzer auf mobilen Geräten Anwendungen wechseln oder in den Hintergrund gehen (Mobile umfasst auch Wakelock zur Schlaffverhinderung), was eine gute Benutzererfahrung gewährleistet.
|
||||
|
||||
## IV. Sicherheits- und Datenschutzverteidigungslinie
|
||||
|
||||
### 4.1 Verschlüsselungsprotokoll-Flywheel
|
||||
|
||||
```
|
||||
Anwendungsschicht
|
||||
↑
|
||||
DTLS 1.2+ → TLS_ECDHE_RSA_AES_128_GCM_SHA256
|
||||
↑
|
||||
Betriebssystem-Level-Verschlüsselung
|
||||
```
|
||||
|
||||
**Erklärung:**
|
||||
|
||||
1. **DTLS (Datagram Transport Layer Security)**:
|
||||
- DTLS ist ein UDP-basiertes sicheres Transportprotokoll, das TLS-ähnliche Verschlüsselung bietet.
|
||||
- In WebRTC werden alle Datenkanäle über DTLS ende-zu-ende verschlüsselt, was Abhören oder Manipulation während der Übertragung verhindert.
|
||||
- Verwendet Verschlüsselungssuite **`TLS_ECDHE_RSA_AES_128_GCM_SHA256`** für hochsichere Sicherheit.
|
||||
2. **Betriebssystem-Level-Verschlüsselung**:
|
||||
- Moderne Browser bieten auf Betriebssystemebene zusätzlichen Schutz für sensible Daten im Speicher, um Zugriff durch bösartige Software zu verhindern.
|
||||
|
||||
**Zusammenfassung:**
|
||||
Durch dualen Schutz von DTLS und Betriebssystem-Level-Verschlüsselung bietet WebRTC robusten Datenschutz und gewährleistet Datensicherheit während des Dateitransfers.
|
||||
|
||||
### 4.2 Angriffsfläche-Abwehrmatrix
|
||||
|
||||
| **Angriffstyp** | **Abwehrmaßnahme** | **Erklärung** |
|
||||
| --- | --- | --- |
|
||||
| **MITM** | **SDP-Fingerabdruck-Verifizierung** | **Generiert eindeutigen Fingerabdruck aus DTLS-öffentlichen Schlüssel-Hash, um Identität der Kommunikationspartner zu gewährleisten, verhindert Datenstrom-Fälschung oder Manipulation durch Mittelsmänner.** |
|
||||
| **RaumID-Traversierungsangriff** | **Raumeintritts-Ratenbegrenzung** | **Begrenzt Raumeintrittsfrequenz pro IP-Adresse (z.B. max 2 joins pro 5 Sekunden), um zu verhindern, dass bösartige Benutzer Raumnummern durchlaufen, um auf Inhalte zuzugreifen.** |
|
||||
|
||||
**Erklärung:**
|
||||
|
||||
1. **MITM (Man-in-the-Middle-Angriff)**
|
||||
- **Prinzip**: WebRTC verwendet SDP-Fingerabdrücke (basierend auf DTLS-öffentlichen Schlüssel-Hash), um Identität der Kommunikationspartner während des Handshakes zu verifizieren. Angreifer können gültige Fingerabdrücke nicht fälschen und können sich daher nicht als legitime Parteien ausgeben.
|
||||
- **Wirkung**: Gewährleistet P2P-Verbindungssicherheit und Datenintegrität, verhindert Abhören oder Manipulation.
|
||||
2. **RaumID-Traversierungsangriff**
|
||||
- **Definition**: Bösartige Benutzer könnten verschiedene Raumnummern (z.B. vierstellige IDs) ausprobieren, um unerlaubte Räume zu betreten und auf geteilte Inhalte zuzugreifen.
|
||||
- **Abwehrmaßnahmen**:
|
||||
- **Ratenbegrenzung**: Begrenzt Raumeintrittsfrequenz pro IP-Adresse, z.B. max 2 Raumbeitritte pro 5 Sekunden.
|
||||
- **Implementierung**: Redis verwenden, um IP-Anfragedatensätze zwischenzuspeichern für schnelle Erkennung und Blockierung abnormalen Verhaltens.
|
||||
- **Wirkung**: Verhindert effektiv, dass bösartige Benutzer durch Raumnummern-Durchlauf auf sensible Inhalte zugreifen, schützt Benutzerdatenschutz.
|
||||
|
||||
## Schlussfolgerung: Vertrauenswürdige Übertragungsinfrastruktur aufbauen
|
||||
|
||||
Wir glauben, dass Technologie wesentliche menschliche Bedürfnisse dienen sollte, nicht neue Überwachungsabhängigkeiten schaffen. Erleben Sie jetzt dieses datenschutzsichere Dateitransferwerkzeug und fühlen Sie die revolutionären Veränderungen, die P2P-Technologie bringt! Klicken Sie auf [<u>**PrivyDrop-Portal**</u>](https://www.privydrop.app) zu beginnen.
|
||||
|
||||
**Verpflichtung zur Codetransparenz**: Code wird zukünftig Open Source sein. Wir sind verpflichtet, wirklich vertrauenswürdige Datenschutzwerkzeuge durch Community-Mitverwaltung zu etablieren.
|
||||
|
||||
## Häufig gestellte Fragen
|
||||
|
||||
- **Werden große Dateiübertragungen leicht unterbrochen?**
|
||||
- Solche Fälle noch nicht beobachtet. P2P (Gerät-zu-Gerät) Verbindungen sind im Allgemeinen stabil. Wir können Resume-from-Breakpoint-Fähigkeit basierend auf zukünftigem Feedback hinzufügen.
|
||||
- **Wären Raumpasswörter sicherer?**
|
||||
- Theoretisch ja. Da Passworthinzufügung die Benutzerfreundlichkeit leicht beeinträchtigen würde, noch nicht implementiert. Für erhöhte Sicherheit können Sie jeden benutzerdefinierten String als RoomID verwenden und über Links und QR-Codes teilen. Außerdem begrenzt das System die Empfänger-Raumeintrittsfrequenz, was die Sicherheit weiter verbessert.
|
||||
- **Können Sender die PrivyDrop-Seite jederzeit schließen?**
|
||||
- Ja, vorzugsweise nachdem Inhalt empfangen wurde. Da es direkte Gerätekommunikation ist, ist Sharing nicht möglich, wenn Sender offline ist. Wenn Sie nicht mehr teilen möchten, können Sie die Seite sofort schließen.
|
||||
|
||||
Weitere Fragen? Klicken Sie auf [<u>**PrivyDrop FAQ**</u>](https://www.privydrop.app/faq) oder [<u>**PrivyDrop Hilfe**</u>](https://www.privydrop.app/help) Abschnitte für weitere Antworten und Hilfe.
|
||||
|
||||
**Entwicklerressourcen**
|
||||
|
||||
- [<u>**WebRTC Offizielle Dokumentation**</u>](https://webrtc.org/)
|
||||
@@ -0,0 +1,277 @@
|
||||
---
|
||||
title: "Conexión Directa de Navegador a Navegador: Revelando la Tecnología Central de la Transferencia de Archivos Enfocada en la Privacidad Basada en WebRTC"
|
||||
description: "Este artículo profundiza en las tecnologías centrales de una herramienta de transferencia de archivos enfocada en la privacidad basada en WebRTC, incluyendo transmisión P2P, cifrado E2EE y multiplexación de flujos. Adecuado tanto para entusiastas de la tecnología como para usuarios generales."
|
||||
date: "2025-02-09"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/webrtc-file-transfer.jpg"
|
||||
tags: [WebRTC, Transferencia P2P, Privacidad y Seguridad]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## Introducción
|
||||
|
||||
Los métodos tradicionales de transferencia de archivos dependen en gran medida del almacenamiento en la nube o servidores centralizados, lo que genera preocupaciones sobre la privacidad de los datos y al mismo tiempo enfrenta limitaciones en el tamaño de carga y cuellos de botella de velocidad. Nuestra herramienta aprovecha la tecnología WebRTC para permitir transferencias directas de dispositivo a dispositivo, abordando efectivamente estos desafíos.
|
||||
|
||||
Nuestra herramienta desarrollada ([<u>**PrivyDrop**</u>](https://www.privydrop.app)) presenta varias características notables:
|
||||
|
||||
- Transferencia directa de dispositivo a dispositivo usando tecnología WebRTC, eliminando la necesidad de servidores intermedios
|
||||
- Cifrado de extremo a extremo (E2EE) garantizando la transmisión segura de datos
|
||||
- Sin registro requerido, uso instantáneo, soporte para múltiples receptores simultáneos
|
||||
- Soporte para varios tipos de datos incluyendo texto, imágenes, archivos y carpetas
|
||||
- Velocidad de transferencia y tamaño de archivo limitados solo por el ancho de banda de la red y el espacio en disco entre dispositivos
|
||||
|
||||
En este artículo, exploraremos la arquitectura técnica, los principios de funcionamiento y por qué esta herramienta puede proporcionar una experiencia de transferencia de archivos tan segura y eficiente. Ya sea que sea un entusiasta de la tecnología o un usuario general, obtendrá información sobre cómo la tecnología WebRTC está revolucionando la transferencia de archivos.
|
||||
|
||||
## I. Redefiniendo la Transferencia de Archivos: La Revolución Arquitectónica de WebRTC
|
||||
|
||||
WebRTC (Web Real-Time Communication) es un estándar abierto que admite comunicación en tiempo real entre navegadores. Nuestra herramienta de transferencia de archivos desarrollada basada en WebRTC comprende varios componentes centrales:
|
||||
|
||||
1. **Servidor de Señalización**: Coordina conexiones entre dispositivos sin participar en la transferencia real de datos.
|
||||
2. **Conexión P2P**: Conexiones directas de dispositivo a dispositivo sin intervención de servidores de terceros.
|
||||
3. **Cifrado E2EE**: Todos los datos se cifran de extremo a extremo usando el protocolo DTLS durante la transmisión.
|
||||
|
||||
### 1.1 Enfoque Tradicional vs Enfoque WebRTC
|
||||
|
||||
| Característica | Transferencia HTTP Tradicional | Transferencia P2P WebRTC |
|
||||
| --- | --- | --- |
|
||||
| Ruta de Transferencia | Cliente → Servidor → Cliente | Dispositivo a Dispositivo Directo |
|
||||
| Latencia | Limitada por ancho de banda del servidor central | Limitada solo por ancho de banda de red física |
|
||||
| Límite de Tamaño de Archivo | Usualmente restringido | Limitado solo por espacio en disco |
|
||||
| Protección de Privacidad | Depende de seguridad del proveedor de servicios | Cifrado obligatorio vía protocolo DTLS |
|
||||
|
||||
### 1.2 Proceso de Establecimiento de Conexión P2P
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant UserA as Usuario A (Remitente)
|
||||
participant SignalingServer as Servidor de Señalización
|
||||
participant UserB as Usuario B (Receptor)
|
||||
|
||||
UserA->>SignalingServer: (1) Crear y unirse a sala
|
||||
activate SignalingServer
|
||||
|
||||
UserB->>SignalingServer: (2) Unirse a sala
|
||||
SignalingServer-->>UserA: Notificar Usuario B se unió
|
||||
|
||||
UserA->>SignalingServer: (3) Enviar información de negociación WebRTC (SDP/ICE)
|
||||
SignalingServer-->>UserB: Reenviar información de negociación WebRTC (SDP/ICE)
|
||||
|
||||
UserB->>SignalingServer: (4) Responder con información de negociación WebRTC (SDP/ICE)
|
||||
SignalingServer-->>UserA: Reenviar información de negociación WebRTC de respuesta (SDP/ICE)
|
||||
|
||||
UserA-->>UserB: (5) Establecer conexión P2P (DataChannel)
|
||||
UserA->>UserB: (6) Transferencia de fragmentos de archivo vía DataChannel
|
||||
```
|
||||
|
||||
**Proceso:**
|
||||
|
||||
1. El Usuario A crea y se une a una sala, conectándose al servidor de señalización.
|
||||
2. El Usuario B se une a la sala y se conecta al servidor de señalización.
|
||||
3. El Usuario A inicia la negociación WebRTC con el Usuario B (incluyendo información SDP e ICE).
|
||||
4. El Usuario B responde con información de negociación WebRTC, completando el establecimiento de la conexión P2P.
|
||||
5. Finalmente, los archivos se transfieren a través de DataChannel en la conexión P2P.
|
||||
|
||||
### 1.3 La Magia de Rendimiento de SCTP (sobre DTLS & UDP)
|
||||
|
||||
El **DataChannel** de WebRTC se basa en el **Protocolo de Control de Transmisión de Flujo (SCTP)** que se ejecuta sobre **DTLS** y **UDP**, ofreciendo tres ventajas principales sobre el TCP tradicional:
|
||||
|
||||
1. **Multiplexación de Flujo (Actualmente No Utilizado)**: Los fragmentos de archivo pueden transmitirse en paralelo, mejorando la eficiencia de transferencia.
|
||||
2. **Sin Bloqueo de Cabeza de Línea**: La pérdida de un solo fragmento no afecta el progreso general, asegurando estabilidad de transferencia.
|
||||
3. **Control Automático de Congestión**: Se adapta dinámicamente a la fluctuación de la red, optimizando el rendimiento de transferencia.
|
||||
|
||||
**Ventajas de UDP:**
|
||||
|
||||
- **Baja Latencia**: UDP es un protocolo sin conexión que no requiere protocolo de enlace de tres vías, ideal para comunicación en tiempo real.
|
||||
- **Fiabilidad Flexible**: Mientras que UDP en sí no es confiable, SCTP implementa mecanismos de transmisión confiables sobre él, combinando la flexibilidad de UDP con la fiabilidad de TCP.
|
||||
|
||||
**Diagrama de Transferencia Multi-Flujo SCTP**
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Remitente] --> B[DataChannel 1]
|
||||
A --> C[DataChannel 2]
|
||||
A --> D[DataChannel 3]
|
||||
B --> E[Receptor]
|
||||
C --> E
|
||||
D --> E
|
||||
```
|
||||
|
||||
## II. Motor de Transferencia Directa de Navegador: Tecnología Central Decodificada
|
||||
|
||||
### 2.1 Control Preciso de Transferencia de Fragmentos
|
||||
|
||||
```typescript
|
||||
// lib/fileSender.ts - Fragmentos de 64KB de Tamaño Fijo
|
||||
|
||||
// Definir tamaño de fragmento como 65536 bytes (64KB) para coincidir precisamente con el tamaño MTU (Unidad Máxima de Transmisión) de red.
|
||||
// Esto previene congestión de red o problemas de fragmentación causados por paquetes sobredimensionados.
|
||||
private readonly CHUNK_SIZE = 65536;
|
||||
|
||||
// Crear una función generadora asíncrona para procesar archivos en fragmentos de tamaño fijo.
|
||||
// Cada llamada al generador devuelve datos de fragmento de tipo ArrayBuffer.
|
||||
private async *createChunkGenerator(file: File) {
|
||||
let offset = 0; // Inicializar offset para marcar posición actual de lectura de archivo
|
||||
|
||||
// Bucle a través del archivo hasta que todos los datos sean procesados
|
||||
while (offset < file.size) {
|
||||
// Usar método File.slice para extraer segmento de datos de [offset, offset + CHUNK_SIZE)
|
||||
const chunk = file.slice(offset, offset + this.CHUNK_SIZE);
|
||||
|
||||
// Convertir datos extraídos a ArrayBuffer y devolver vía yield
|
||||
yield await chunk.arrayBuffer();
|
||||
|
||||
// Actualizar offset para siguiente fragmento
|
||||
offset += this.CHUNK_SIZE;
|
||||
}
|
||||
}
|
||||
|
||||
// Algoritmo de control de contra-presión: Asegura que el envío no exceda los límites del búfer de DataChannel.
|
||||
// Si el búfer está lleno, esperar hasta que el espacio del búfer esté disponible antes de continuar.
|
||||
private async sendWithBackpressure(chunk: ArrayBuffer) {
|
||||
// Pausar envío cuando el uso del búfer de DataChannel excede el máximo preestablecido
|
||||
while (this.dataChannel.bufferedAmount > this.MAX_BUFFER) {
|
||||
// Usar Promise para esperar evento bufferedamountlow indicando espacio de búfer liberado
|
||||
await new Promise(r => this.dataChannel.bufferedamountlow = r);
|
||||
}
|
||||
|
||||
// Enviar fragmento actual cuando el búfer tiene espacio suficiente
|
||||
this.dataChannel.send(chunk);
|
||||
}
|
||||
```
|
||||
|
||||
### 2.2 Escritura de Memoria de Copia Cero
|
||||
|
||||
Implementado a través de File System Access API:
|
||||
|
||||
```typescript
|
||||
// lib/fileReceiver.ts
|
||||
|
||||
// Escribir datos de fragmento recibidos directamente al disco, evitando copias de memoria adicionales
|
||||
private async writeToDisk(chunk: ArrayBuffer) {
|
||||
// Inicializar escritor de archivo si aún no está creado
|
||||
if (!this.writer) {
|
||||
// Mostrar diálogo de selector de guardado de archivo para que el usuario elija ubicación de guardado
|
||||
this.currentFileHandle = await window.showSaveFilePicker();
|
||||
|
||||
// Crear flujo escribible a través del manejador de archivo para escrituras posteriores
|
||||
this.writer = await this.currentFileHandle.createWritable();
|
||||
}
|
||||
|
||||
// Convertir ArrayBuffer recibido a Uint8Array y escribir directamente al disco
|
||||
// Esto evita el búfer de memoria, logrando escritura de copia cero para mejor rendimiento
|
||||
await this.writer.write(new Uint8Array(chunk));
|
||||
}
|
||||
```
|
||||
|
||||
## III. Sistema de Gestión de Salas Distribuido
|
||||
|
||||
### 3.1 Detección de Colisión de Cuatro Dígitos:
|
||||
|
||||
```typescript
|
||||
// server.ts
|
||||
async function getAvailableRoomId() {
|
||||
let roomId;
|
||||
do {
|
||||
roomId = Math.floor(1000 + Math.random() * 9000); // Generar número aleatorio de cuatro dígitos
|
||||
} while (await redis.hexists(`room:${roomId}`, "created_at")); // Verificar si existe
|
||||
return roomId;
|
||||
}
|
||||
```
|
||||
|
||||
Nota: El número de 4 dígitos es una ID de sala aleatoria generada por el sistema. Puede especificar cualquier ID de sala que prefiera.
|
||||
|
||||
### 3.2 Estrategia de Expiración Elegante:
|
||||
|
||||
```typescript
|
||||
// server.ts
|
||||
await refreshRoom(roomId, 3600 * 24); // Salas activas retenidas por 24 horas
|
||||
if (await isRoomEmpty(roomId)) {
|
||||
// Liberar sala si está vacía (tanto remitente como receptor se fueron)
|
||||
await deleteRoom(roomId);
|
||||
}
|
||||
```
|
||||
|
||||
### 3.3 Protocolo de Recuperación Impulsado por Señalización
|
||||
|
||||
Flujo de Recuperación de Desconexión Móvil:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Sender
|
||||
participant Signaling
|
||||
participant Recipient
|
||||
|
||||
Sender->>Signaling: Enviar initiator-online cuando frontend visible
|
||||
Signaling->>Recipient: Reenviar notificación en línea
|
||||
Recipient->>Signaling: Responder recipient-ready
|
||||
Signaling->>Sender: Desencadenar proceso de reconexión
|
||||
Sender->>Recipient: Reconstruir conexión ICE
|
||||
```
|
||||
|
||||
A través de este mecanismo, el sistema puede restaurar rápidamente conexiones incluso cuando los usuarios cambian aplicaciones o entran en segundo plano en dispositivos móviles (móvil también incluye Wakelock para evitar dormir), asegurando una buena experiencia de usuario.
|
||||
|
||||
## IV. Línea de Defensa de Seguridad y Privacidad
|
||||
|
||||
### 4.1 Rueda de Protocolos de Cifrado
|
||||
|
||||
```
|
||||
Capa de Aplicación
|
||||
↑
|
||||
DTLS 1.2+ → TLS_ECDHE_RSA_AES_128_GCM_SHA256
|
||||
↑
|
||||
Cifrado a Nivel de Sistema Operativo
|
||||
```
|
||||
|
||||
**Explicación:**
|
||||
|
||||
1. **DTLS (Datagram Transport Layer Security)**:
|
||||
- DTLS es un protocolo de transporte seguro basado en UDP que proporciona cifrado similar a TLS.
|
||||
- En WebRTC, todos los canales de datos se cifran de extremo a extremo a través de DTLS, evitando escucha o manipulación durante la transmisión.
|
||||
- Utiliza suite de cifrado **`TLS_ECDHE_RSA_AES_128_GCM_SHA256`** para alta seguridad.
|
||||
2. **Cifrado a Nivel de Sistema Operativo**:
|
||||
- Los navegadores modernos proporcionan protección adicional para datos sensibles en memoria a nivel de sistema operativo, evitando el acceso de software malicioso.
|
||||
|
||||
**Resumen:**
|
||||
A través de la protección dual de DTLS y cifrado a nivel de sistema operativo, WebRTC proporciona robusta protección de privacidad asegurando la seguridad de datos durante la transferencia de archivos.
|
||||
|
||||
### 4.2 Matriz de Defensa de Superficie de Ataque
|
||||
|
||||
| **Tipo de Ataque** | **Medida de Defensa** | **Explicación** |
|
||||
| --- | --- | --- |
|
||||
| **MITM** | **Verificación de Huella SDP** | **Genera huella única desde hash de clave pública DTLS para asegurar identidad de partes de comunicación, evitando falsificación o manipulación de flujo de datos por intermediarios.** |
|
||||
| **Ataque de Traversía de RoomID** | **Limitación de Tasa de Entrada a Sala** | **Limita frecuencia de entrada a sala por dirección IP (ej. máximo 2 joins por 5 segundos), evitando que usuarios maliciosos atraviesen números de sala para acceder a contenido.** |
|
||||
|
||||
**Explicación:**
|
||||
|
||||
1. **MITM (Ataque de Hombre en el Medio)**
|
||||
- **Principio**: WebRTC usa huellas SDP (basadas en hash de clave pública DTLS) para verificar identidad de partes de comunicación durante el handshake. Los atacantes no pueden falsificar huellas válidas, por lo tanto no pueden hacerse pasar por partes legítimas.
|
||||
- **Efecto**: Asegura seguridad de conexión P2P e integridad de datos, evitando escucha o manipulación.
|
||||
2. **Ataque de Traversía de RoomID**
|
||||
- **Definición**: Usuarios maliciosos podrían intentar diferentes números de sala (ej. IDs de cuatro dígitos) para entrar en salas no autorizadas y acceder a contenido compartido.
|
||||
- **Medidas de Defensa**:
|
||||
- **Limitación de Tasa**: Restringir frecuencia de entrada a sala por dirección IP, ej. máximo 2 entradas a sala por 5 segundos.
|
||||
- **Implementación**: Usar Redis para almacenar en caché registros de solicitudes IP para rápida detección y bloqueo de comportamiento anormal.
|
||||
- **Efecto**: Previene eficazmente que usuarios maliciosos accedan a contenido sensible a través de traversía de números de sala, protegiendo la privacidad del usuario.
|
||||
|
||||
## Conclusión: Construyendo Infraestructura de Transferencia Confiable
|
||||
|
||||
Creemos que la tecnología debería servir necesidades humanas esenciales en lugar de crear nuevas dependencias de vigilancia. ¡Experimente ahora esta herramienta de transferencia de archivos segura para la privacidad y sienta los cambios revolucionarios traídos por la tecnología P2P! Haga clic en [<u>**Portal PrivyDrop**</u>](https://www.privydrop.app) para comenzar.
|
||||
|
||||
**Compromiso de Transparencia de Código**: El código será de código abierto en el futuro. Estamos comprometidos en establecer herramientas de privacidad verdaderamente confiables a través de la cogobernanza comunitaria.
|
||||
|
||||
## Preguntas Frecuentes
|
||||
|
||||
- **¿Las transferencias de archivos grandes serán propensas a interrupciones?**
|
||||
- Aún no se han observado tales casos. Las conexiones P2P (dispositivo a dispositivo) generalmente son estables. Podríamos agregar capacidad de reanudación desde punto de interrupción basado en retroalimentación futura.
|
||||
- **¿Sería más seguro agregar contraseñas a las salas?**
|
||||
- Teóricamente sí. Considerando que agregar contraseñas afectaría ligeramente la usabilidad, aún no está implementado. Para mayor seguridad, puede usar cualquier cadena personalizada como RoomID y compartir a través de enlaces y códigos QR. Además, el sistema limita la frecuencia de entrada a sala del receptor, mejorando aún más la seguridad.
|
||||
- **¿Pueden los remitentes cerrar la página PrivyDrop en cualquier momento?**
|
||||
- Sí, preferiblemente después de que el contenido sea recibido. Como es conexión directa de dispositivo, compartir no es posible si el remitente está fuera de línea. Si no desea seguir compartiendo, puede cerrar la página inmediatamente.
|
||||
|
||||
¿Más preguntas? Haga clic en [<u>**PrivyDrop FAQ**</u>](https://www.privydrop.app/faq) o [<u>**PrivyDrop Ayuda**</u>](https://www.privydrop.app/help) para más respuestas y ayuda.
|
||||
|
||||
**Recursos para Desarrolladores**
|
||||
|
||||
- [<u>**Documentación Oficial de WebRTC**</u>](https://webrtc.org/)
|
||||
@@ -0,0 +1,277 @@
|
||||
---
|
||||
title: "Connexion Directe de Navigateur à Navigateur : Révélation de la Technologie Centrale du Transfert de Fichiers Axé sur la Confidentialité Basé sur WebRTC"
|
||||
description: "Cet article explore en profondeur les technologies centrales d'un outil de transfert de fichiers axé sur la confidentialité basé sur WebRTC, incluant la transmission P2P, le chiffrement E2EE et le multiplexage de flux. Adapté autant pour les passionnés de technologie que pour les utilisateurs généraux."
|
||||
date: "2025-02-09"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/webrtc-file-transfer.jpg"
|
||||
tags: [WebRTC, Transfert P2P, Confidentialité Sécurité]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## Introduction
|
||||
|
||||
Les méthodes traditionnelles de transfert de fichiers dépendent largement du stockage cloud ou de serveurs centralisés, ce qui soulève des préoccupations concernant la confidentialité des données tout en faisant face à des limitations de taille de téléchargement et des goulots d'étranglement de vitesse. Notre outil exploite la technologie WebRTC pour permettre des transferts directs d'appareil à appareil, adressant efficacement ces défis.
|
||||
|
||||
Notre outil développé ([<u>**PrivyDrop**</u>](https://www.privydrop.app)) présente plusieurs caractéristiques notables :
|
||||
|
||||
- Transfert direct d'appareil à appareil utilisant la technologie WebRTC, éliminant le besoin de serveurs intermédiaires
|
||||
- Chiffrement de bout en bout (E2EE) garantissant une transmission sécurisée des données
|
||||
- Aucune inscription requise, utilisation instantanée, support pour plusieurs récepteurs simultanés
|
||||
- Support pour divers types de données incluant texte, images, fichiers et dossiers
|
||||
- Vitesse de transfert et taille de fichier limitées seulement par la bande passante réseau et l'espace disque entre appareils
|
||||
|
||||
Dans cet article, nous explorerons l'architecture technique, les principes de fonctionnement et pourquoi cet outil peut offrir une expérience de transfert de fichiers si sécurisée et efficace. Que vous soyez un passionné de technologie ou un utilisateur général, vous obtiendrez des informations sur la manière dont la technologie WebRTC révolutionne le transfert de fichiers.
|
||||
|
||||
## I. Redéfinir le Transfert de Fichiers : La Révolution Architecturale de WebRTC
|
||||
|
||||
WebRTC (Web Real-Time Communication) est un standard ouvert supportant la communication en temps réel entre navigateurs. Notre outil de transfert de fichiers développé basé sur WebRTC comprend plusieurs composants centraux :
|
||||
|
||||
1. **Serveur de Signalisation** : Coordonne les connexions entre appareils sans participer au transfert réel de données.
|
||||
2. **Connexion P2P** : Connexions directes d'appareil à appareil sans intervention de serveurs tiers.
|
||||
3. **Chiffrement E2EE** : Toutes les données sont chiffrées de bout en bout utilisant le protocole DTLS pendant la transmission.
|
||||
|
||||
### 1.1 Approche Traditionnelle vs Approche WebRTC
|
||||
|
||||
| Caractéristique | Transfert HTTP Traditionnel | Transfert P2P WebRTC |
|
||||
| --- | --- | --- |
|
||||
| Chemin de Transfert | Client → Serveur → Client | Direct d'Appareil à Appareil |
|
||||
| Latence | Limitée par la bande passante du serveur central | Limitée seulement par la bande passante réseau physique |
|
||||
| Limite de Taille de Fichier | Généralement restreinte | Limitée seulement par l'espace disque |
|
||||
| Protection de la Confidentialité | Dépend de la sécurité du fournisseur de services | Chiffrement obligatoire via protocole DTLS |
|
||||
|
||||
### 1.2 Processus d'Établissement de Connexion P2P
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant UserA as Utilisateur A (Émetteur)
|
||||
participant SignalingServer as Serveur de Signalisation
|
||||
participant UserB as Utilisateur B (Récepteur)
|
||||
|
||||
UserA->>SignalingServer: (1) Créer et rejoindre une salle
|
||||
activate SignalingServer
|
||||
|
||||
UserB->>SignalingServer: (2) Rejoindre la salle
|
||||
SignalingServer-->>UserA: Notifier que l'Utilisateur B a rejoint
|
||||
|
||||
UserA->>SignalingServer: (3) Envoyer les informations de négociation WebRTC (SDP/ICE)
|
||||
SignalingServer-->>UserB: Transférer les informations de négociation WebRTC (SDP/ICE)
|
||||
|
||||
UserB->>SignalingServer: (4) Répondre avec les informations de négociation WebRTC (SDP/ICE)
|
||||
SignalingServer-->>UserA: Transférer les informations de négociation WebRTC de réponse (SDP/ICE)
|
||||
|
||||
UserA-->>UserB: (5) Établir la connexion P2P (DataChannel)
|
||||
UserA->>UserB: (6) Transfert de fragments de fichier via DataChannel
|
||||
```
|
||||
|
||||
**Processus :**
|
||||
|
||||
1. L'Utilisateur A crée et rejoint une salle, se connectant au serveur de signalisation.
|
||||
2. L'Utilisateur B rejoint la salle et se connecte au serveur de signalisation.
|
||||
3. L'Utilisateur A initie la négociation WebRTC avec l'Utilisateur B (incluant les informations SDP et ICE).
|
||||
4. L'Utilisateur B répond avec les informations de négociation WebRTC, complétant l'établissement de la connexion P2P.
|
||||
5. Finalement, les fichiers sont transférés via DataChannel sur la connexion P2P.
|
||||
|
||||
### 1.3 La Magie de Performance de SCTP (sur DTLS & UDP)
|
||||
|
||||
Le **DataChannel** de WebRTC est basé sur le **Stream Control Transmission Protocol (SCTP)** fonctionnant sur **DTLS** et **UDP**, offrant trois avantages majeurs par rapport au TCP traditionnel :
|
||||
|
||||
1. **Multiplexage de Flux (Pas Actuellement Utilisé)** : Les fragments de fichiers peuvent être transmis en parallèle, améliorant l'efficacité de transfert.
|
||||
2. **Pas de Blocage de Tête de Ligne** : La perte d'un fragment unique n'affecte pas la progression globale, assurant la stabilité du transfert.
|
||||
3. **Contrôle Automatique de Congestion** : S'adapte dynamiquement à la gigue réseau, optimisant les performances de transfert.
|
||||
|
||||
**Avantages UDP :**
|
||||
|
||||
- **Faible Latence** : UDP est un protocole sans connexion n'exigeant pas de handshake en trois temps, idéal pour la communication en temps réel.
|
||||
- **Fiabilité Flexible** : Bien qu'UDP lui-même ne soit pas fiable, SCTP implémente des mécanismes de transmission fiables par-dessus, combinant la flexibilité d'UDP avec la fiabilité de TCP.
|
||||
|
||||
**Diagramme de Transfert Multi-Flux SCTP**
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Émetteur] --> B[DataChannel 1]
|
||||
A --> C[DataChannel 2]
|
||||
A --> D[DataChannel 3]
|
||||
B --> E[Récepteur]
|
||||
C --> E
|
||||
D --> E
|
||||
```
|
||||
|
||||
## II. Moteur de Transfert Direct Navigateur : Technologie Centrale Décryptée
|
||||
|
||||
### 2.1 Contrôle Précis du Transfert de Fragments
|
||||
|
||||
```typescript
|
||||
// lib/fileSender.ts - Fragments de Taille Fixe 64KB
|
||||
|
||||
// Définir la taille de fragment comme 65536 octets (64KB) pour correspondre précisément à la taille MTU (Maximum Transmission Unit) réseau.
|
||||
// Ceci prévient la congestion réseau ou les problèmes de fragmentation causés par des paquets surdimensionnés.
|
||||
private readonly CHUNK_SIZE = 65536;
|
||||
|
||||
// Créer une fonction générateur asynchrone pour traiter les fichiers en fragments de taille fixe.
|
||||
// Chaque appel au générateur retourne des données de fragment de type ArrayBuffer.
|
||||
private async *createChunkGenerator(file: File) {
|
||||
let offset = 0; // Initialiser l'offset pour marquer la position actuelle de lecture de fichier
|
||||
|
||||
// Boucler à travers le fichier jusqu'à ce que toutes les données soient traitées
|
||||
while (offset < file.size) {
|
||||
// Utiliser la méthode File.slice pour extraire un segment de données de [offset, offset + CHUNK_SIZE)
|
||||
const chunk = file.slice(offset, offset + this.CHUNK_SIZE);
|
||||
|
||||
// Convertir les données extraites en ArrayBuffer et retourner via yield
|
||||
yield await chunk.arrayBuffer();
|
||||
|
||||
// Mettre à jour l'offset pour le fragment suivant
|
||||
offset += this.CHUNK_SIZE;
|
||||
}
|
||||
}
|
||||
|
||||
// Algorithme de contrôle de contre-pression : Assure que l'envoi n'excède pas les limites du tampon DataChannel.
|
||||
// Si le tampon est plein, attendre que l'espace du tampon devienne disponible avant de continuer.
|
||||
private async sendWithBackpressure(chunk: ArrayBuffer) {
|
||||
// Mettre en pause l'envoi quand l'utilisation du tampon DataChannel dépasse le maximum préréglé
|
||||
while (this.dataChannel.bufferedAmount > this.MAX_BUFFER) {
|
||||
// Utiliser Promise pour attendre l'événement bufferedamountlow indiquant l'espace de tampon libéré
|
||||
await new Promise(r => this.dataChannel.bufferedamountlow = r);
|
||||
}
|
||||
|
||||
// Envoyer le fragment actuel quand le tampon a suffisamment d'espace
|
||||
this.dataChannel.send(chunk);
|
||||
}
|
||||
```
|
||||
|
||||
### 2.2 Écriture Mémoire de Copie Zéro
|
||||
|
||||
Implémenté via File System Access API :
|
||||
|
||||
```typescript
|
||||
// lib/fileReceiver.ts
|
||||
|
||||
// Écrire les données de fragment reçues directement sur le disque, évitant les copies mémoire supplémentaires
|
||||
private async writeToDisk(chunk: ArrayBuffer) {
|
||||
// Initialiser l'écrivain de fichier si pas encore créé
|
||||
if (!this.writer) {
|
||||
// Afficher le dialogue de sauvegarde de fichier pour que l'utilisateur choisisse l'emplacement de sauvegarde
|
||||
this.currentFileHandle = await window.showSaveFilePicker();
|
||||
|
||||
// Créer un flux inscriptible via le handle de fichier pour les écritures ultérieures
|
||||
this.writer = await this.currentFileHandle.createWritable();
|
||||
}
|
||||
|
||||
// Convertir l'ArrayBuffer reçu en Uint8Array et écrire directement sur le disque
|
||||
// Ceci contourne le tampon mémoire, réalisant une écriture de copie zéro pour une performance améliorée
|
||||
await this.writer.write(new Uint8Array(chunk));
|
||||
}
|
||||
```
|
||||
|
||||
## III. Système de Gestion de Salle Distribué
|
||||
|
||||
### 3.1 Détection de Collision à Quatre Chiffres :
|
||||
|
||||
```typescript
|
||||
// server.ts
|
||||
async function getAvailableRoomId() {
|
||||
let roomId;
|
||||
do {
|
||||
roomId = Math.floor(1000 + Math.random() * 9000); // Générer un nombre aléatoire à quatre chiffres
|
||||
} while (await redis.hexists(`room:${roomId}`, "created_at")); // Vérifier si existe
|
||||
return roomId;
|
||||
}
|
||||
```
|
||||
|
||||
Note : Le nombre à 4 chiffres est un ID de salle aléatoire généré par le système. Vous pouvez spécifier n'importe quel ID de salle que vous préférez.
|
||||
|
||||
### 3.2 Stratégie d'Expiration Élégante :
|
||||
|
||||
```typescript
|
||||
// server.ts
|
||||
await refreshRoom(roomId, 3600 * 24); // Salles actives retenues pendant 24 heures
|
||||
if (await isRoomEmpty(roomId)) {
|
||||
// Libérer la salle si vide (émetteur et récepteur sont partis)
|
||||
await deleteRoom(roomId);
|
||||
}
|
||||
```
|
||||
|
||||
### 3.3 Protocole de Récupération Piloté par Signalisation
|
||||
|
||||
Flux de Récupération de Déconnexion Mobile :
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Sender
|
||||
participant Signaling
|
||||
participant Recipient
|
||||
|
||||
Sender->>Signaling: Envoyer initiator-online quand frontend visible
|
||||
Signaling->>Recipient: Transférer notification en ligne
|
||||
Recipient->>Signaling: Répondre recipient-ready
|
||||
Signaling->>Sender: Déclencher le processus de reconnexion
|
||||
Sender->>Recipient: Reconstruire la connexion ICE
|
||||
```
|
||||
|
||||
À travers ce mécanisme, le système peut rapidement restaurer les connexions même lorsque les utilisateurs basculent d'application ou entrent en arrière-plan sur les appareils mobiles (mobile inclut aussi Wakelock pour empêcher le sommeil), assurant une bonne expérience utilisateur.
|
||||
|
||||
## IV. Ligne de Défense Sécurité et Confidentialité
|
||||
|
||||
### 4.1 Volant de Protocoles de Chiffrement
|
||||
|
||||
```
|
||||
Couche Application
|
||||
↑
|
||||
DTLS 1.2+ → TLS_ECDHE_RSA_AES_128_GCM_SHA256
|
||||
↑
|
||||
Chiffrement au Niveau OS
|
||||
```
|
||||
|
||||
**Explication :**
|
||||
|
||||
1. **DTLS (Datagram Transport Layer Security)** :
|
||||
- DTLS est un protocole de transport sécurisé basé sur UDP fournissant un chiffrement similaire à TLS.
|
||||
- Dans WebRTC, tous les canaux de données sont chiffrés de bout en bout via DTLS, empêchant l'écoute ou la manipulation pendant la transmission.
|
||||
- Utilise la suite de chiffrement **`TLS_ECDHE_RSA_AES_128_GCM_SHA256`** pour une sécurité haute force.
|
||||
2. **Chiffrement au Niveau OS** :
|
||||
- Au niveau OS, les navigateurs modernes fournissent une protection supplémentaire pour les données sensibles en mémoire, empêchant l'accès par logiciel malveillant.
|
||||
|
||||
**Résumé :**
|
||||
À travers la protection double de DTLS et du chiffrement au niveau OS, WebRTC fournit une robuste protection de confidentialité assurant la sécurité des données pendant le transfert de fichiers.
|
||||
|
||||
### 4.2 Matrice de Défense de Surface d'Attaque
|
||||
|
||||
| **Type d'Attaque** | **Mesure de Défense** | **Explication** |
|
||||
| --- | --- | --- |
|
||||
| **MITM** | **Vérification d'Empreinte SDP** | **Génère une empreinte unique depuis le hash de clé publique DTLS pour assurer l'identité des parties de communication, empêchant la falsification ou manipulation de flux de données par intermédiaires.** |
|
||||
| **Attaque de Parcours RoomID** | **Limitation de Taux d'Entrée de Salle** | **Limite la fréquence d'entrée en salle par adresse IP (ex. max 2 joins par 5 secondes), empêchant les utilisateurs malveillants de parcourir les numéros de salle pour accéder au contenu.** |
|
||||
|
||||
**Explication :**
|
||||
|
||||
1. **MITM (Attaque de l'Homme du Milieu)**
|
||||
- **Principe** : WebRTC utilise les empreintes SDP (basées sur le hash de clé publique DTLS) pour vérifier l'identité des parties de communication pendant le handshake. Les attaquants ne peuvent pas falsifier d'empreintes valides, donc ne peuvent pas se faire passer pour des parties légitimes.
|
||||
- **Effet** : Assure la sécurité de connexion P2P et l'intégrité des données, empêchant l'écoute ou la manipulation.
|
||||
2. **Attaque de Parcours RoomID**
|
||||
- **Définition** : Les utilisateurs malveillants pourraient tenter différents numéros de salle (ex. IDs à quatre chiffres) pour entrer dans des salas non autorisées et accéder au contenu partagé.
|
||||
- **Mesures de Défense** :
|
||||
- **Limitation de Taux** : Restreindre la fréquence d'entrée en salle par adresse IP, ex. max 2 entrées de salle par 5 secondes.
|
||||
- **Implémentation** : Utiliser Redis pour mettre en cache les enregistrements de requêtes IP pour détection rapide et blocage de comportement anormal.
|
||||
- **Effet** : Empêche efficacement les utilisateurs malveillants d'accéder à du contenu sensible via le parcours de numéros de salle, protégeant la confidentialité utilisateur.
|
||||
|
||||
## Conclusion : Construire une Infrastructure de Transfert Fiable
|
||||
|
||||
Nous croyons que la technologie devrait servir les besoins humains essentiels plutôt que créer de nouvelles dépendances de surveillance. Expérimentez maintenant cet outil de transfert de fichiers sécurisé pour la confidentialité et sentez les changements révolutionnaires apportés par la technologie P2P ! Cliquez sur [<u>**Portail PrivyDrop**</u>](https://www.privydrop.app) pour commencer.
|
||||
|
||||
**Engagement de Transparence de Code** : Le code sera open source à l'avenir. Nous sommes engagés à établir de véritables outils de confidentialité fiables à travers la co-gouvernance communautaire.
|
||||
|
||||
## FAQ
|
||||
|
||||
- **Les transferts de gros fichiers seront-ils sujets à interruption ?**
|
||||
- Pas encore observé de tels cas. Les connexions P2P (appareil à appareil) sont généralement stables. Nous pourrions ajouter la capacité de reprise depuis point d'arrêt basée sur les retours futurs.
|
||||
- **Ajouter des mots de passe aux salles serait-il plus sécurisé ?**
|
||||
- Théoriquement oui. Considérant que l'ajout de mots de passe impacterait légèrement l'utilisabilité, pas encore implémenté. Pour une sécurité accrue, vous pouvez utiliser n'importe quelle chaîne personnalisée comme RoomID et partager via liens et codes QR. De plus, le système limite la fréquence d'entrée en salle du récepteur, améliorant encore la sécurité.
|
||||
- **Les émetteurs peuvent-ils fermer la page PrivyDrop à tout moment ?**
|
||||
- Oui, de préférence après que le contenu soit reçu. Comme c'est une connexion directe d'appareil, le partage n'est pas possible si l'émetteur est hors ligne. Si vous voulez arrêter de partager, vous pouvez fermer la page immédiatement.
|
||||
|
||||
Plus de questions ? Cliquez sur [<u>**PrivyDrop FAQ**</u>](https://www.privydrop.app/faq) ou [<u>**PrivyDrop Aide**</u>](https://www.privydrop.app/help) pour plus de réponses et d'aide.
|
||||
|
||||
**Ressources Développeur**
|
||||
|
||||
- [<u>**Documentation Officielle WebRTC**</u>](https://webrtc.org/)
|
||||
@@ -0,0 +1,277 @@
|
||||
---
|
||||
title: "ブラウザー間直接接続！WebRTCベースのプライベートファイル転送核心技術を解明"
|
||||
description: "この記事では、WebRTCベースのプライベートファイル転送ツールの核心技術について深く掘り下げ、P2P転送、E2EE暗号化、ストリーム多重化などを含み、技術愛好家と一般ユーザーの両方に適しています。"
|
||||
date: "2025-02-09"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/webrtc-file-transfer.jpg"
|
||||
tags: [WebRTC, P2P転送, プライバシー・セキュリティ]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## はじめに
|
||||
|
||||
従来のファイル転送方式のほとんどはクラウドストレージまたは中央集権型サーバーに依存しており、これによりデータプライバシーの懸念が生まれるだけでなく、アップロードサイズの制限や速度ボトルネックといった多くの問題に直面していました。私たちのツールはWebRTC技術を活用してデバイス間の直接転送を実現し、これらの問題を完全に解決しました。
|
||||
|
||||
私たちが開発したこのツール（[<u>**PrivyDrop**</u>](https://www.privydrop.app)）には、以下の顕著な特徴があります：
|
||||
|
||||
- WebRTC技術を活用したデバイス間直接転送、中間サーバー不要
|
||||
- エンドツーエンド暗号化（E2EE）による安全なデータ転送保証
|
||||
- 登録不要、即利用可能、複数人同時受信対応
|
||||
- テキスト、画像、ファイル、フォルダなど多様なデータタイプをサポート
|
||||
- 転送速度とファイルサイズはデバイス間のネットワーク帯域とディスク空間のみに制限
|
||||
|
||||
この記事では、このツールの技術アーキテクチャ、動作原理、そしてなぜこれほど安全で効率的なファイル転送体験を提供できるのかについて探求します。技術愛好家であっても一般ユーザーであっても、WebRTC技術がファイル転送分野にもたらす革命的変化を理解できるでしょう。
|
||||
|
||||
## 一、ファイル転送の再定義：WebRTCのアーキテクチャ革命
|
||||
|
||||
WebRTC（Web Real-Time Communication）は、ブラウザー間のリアルタイム通信をサポートするオープンスタンダードです。WebRTCベースで開発された私たちのファイル転送ツールは、主に以下のコアコンポーネントで構成されています：
|
||||
|
||||
1. **シグナリングサーバー**：デバイス間の接続を調整しますが、実際のデータ転送には関与しません。
|
||||
2. **P2P接続**：デバイス間で直接接続を確立し、第三者サーバーを介さずにデータを転送します。
|
||||
3. **E2EE暗号化**：すべてのデータが転送中にDTLSプロトコルでエンドツーエンド暗号化されます。
|
||||
|
||||
### 1.1 従来方式 vs WebRTC方式
|
||||
|
||||
| 特性 | 従来のHTTP転送 | WebRTC P2P転送 |
|
||||
| --- | --- | --- |
|
||||
| 転送パス | クライアント → サーバー → クライアント | デバイス間直接接続 |
|
||||
| 遅延 | 中央サーバーの帯域に制限 | 物理ネットワーク帯域のみに制限 |
|
||||
| ファイルサイズ制限 | 通常制限あり | ディスク容量のみに制限 |
|
||||
| プライバシー保護 | サービスプロバイダーのセキュリティに依存 | DTLSプロトコルによる強制暗号化 |
|
||||
|
||||
### 1.2 P2P接続確立プロセス
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant UserA as ユーザーA（送信者）
|
||||
participant SignalingServer as シグナリングサーバー
|
||||
participant UserB as ユーザーB（受信者）
|
||||
|
||||
UserA->>SignalingServer: (1) 部屋を作成して参加
|
||||
activate SignalingServer
|
||||
|
||||
UserB->>SignalingServer: (2) 部屋に参加
|
||||
SignalingServer-->>UserA: ユーザーBの参加を通知
|
||||
|
||||
UserA->>SignalingServer: (3) WebRTCネゴシエーション情報（SDP/ICE）を送信
|
||||
SignalingServer-->>UserB: WebRTCネゴシエーション情報（SDP/ICE）を転送
|
||||
|
||||
UserB->>SignalingServer: (4) WebRTCネゴシエーション情報（SDP/ICE）で応答
|
||||
SignalingServer-->>UserA: 応答WebRTCネゴシエーション情報（SDP/ICE）を転送
|
||||
|
||||
UserA-->>UserB: (5) P2P接続（DataChannel）を確立
|
||||
UserA->>UserB: (6) DataChannel経由でファイルチャンク転送
|
||||
```
|
||||
|
||||
**プロセス：**
|
||||
|
||||
1. ユーザーAが部屋を作成して参加し、シグナリングサーバーに接続します。
|
||||
2. ユーザーBが部屋に参加し、シグナリングサーバーに接続します。
|
||||
3. ユーザーAがユーザーBとのWebRTCネゴシエーション（SDPとICE情報を含む）を開始します。
|
||||
4. ユーザーBがWebRTCネゴシエーション情報で応答し、P2P接続の確立を完了します。
|
||||
5. 最後に、ファイルがP2P接続上のDataChannelを通じて転送されます。
|
||||
|
||||
### 1.3 SCTP（over DTLS & UDP）の性能魔法
|
||||
|
||||
WebRTCの**DataChannel**は**DTLS**と**UDP**上で動作する**ストリーム制御伝送プロトコル（SCTP）**に基づいており、従来のTCPに対して3つの大きな利点があります：
|
||||
|
||||
1. **ストリーム多重化（現未採用）**：ファイルチャンクを並列転送でき、転送効率を向上させます。
|
||||
2. **ヘッドオブラインブロッキングなし**：単一チャンクの損失が全体の進行に影響せず、転送安定性を保証します。
|
||||
3. **自動輻輳制御**：ネットワークジッターに動的に適応し、転送性能を最適化します。
|
||||
|
||||
**UDPの利点：**
|
||||
|
||||
- **低遅延**：UDPはコネクションレスプロトコルで、3wayハンドシェイク不要で、リアルタイム通信に適しています。
|
||||
- **柔軟な信頼性**：UDP自体は信頼性ありませんが、SCTPがその上に信頼性ある伝送メカニズムを実装し、UDPの柔軟性とTCPの信頼性を組み合わせています。
|
||||
|
||||
**SCTPマルチストリーム転送図**
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[送信者] --> B[DataChannel 1]
|
||||
A --> C[DataChannel 2]
|
||||
A --> D[DataChannel 3]
|
||||
B --> E[受信者]
|
||||
C --> E
|
||||
D --> E
|
||||
```
|
||||
|
||||
## 二、ブラウザー直接転送エンジン：核心技術解読
|
||||
|
||||
### 2.1 チャンク転送の精密制御
|
||||
|
||||
```typescript
|
||||
// lib/fileSender.ts - 64KB固定サイズチャンク
|
||||
|
||||
// 各チャンクサイズを65536バイト（64KB）と定義し、ネットワークMTU（最大伝送単位）サイズに正確に一致させます。
|
||||
// これにより、過大なパケットによるネットワーク輻輳やフラグメンテーション問題を防ぎます。
|
||||
private readonly CHUNK_SIZE = 65536;
|
||||
|
||||
// 固定サイズでファイルをチャンク処理するための非同期ジェネレーター関数を作成します。
|
||||
// 各ジェネレーター呼び出しでArrayBuffer型のチャンクデータを返します。
|
||||
private async *createChunkGenerator(file: File) {
|
||||
let offset = 0; // 現在のファイル読み取り位置をマークするためにオフセットを初期化
|
||||
|
||||
// ファイル全体が処理されるまでループ
|
||||
while (offset < file.size) {
|
||||
// File.sliceメソッドを使用して[offset, offset + CHUNK_SIZE)範囲のデータセグメントを抽出
|
||||
const chunk = file.slice(offset, offset + this.CHUNK_SIZE);
|
||||
|
||||
// 抽出したデータをArrayBufferに変換し、yield経由で返す
|
||||
yield await chunk.arrayBuffer();
|
||||
|
||||
// 次のチャンク用にオフセットを更新
|
||||
offset += this.CHUNK_SIZE;
|
||||
}
|
||||
}
|
||||
|
||||
// バックプレッシャー制御アルゴリズム：送信がDataChannelバッファー制限を超えないようにします。
|
||||
// バッファーが満杯の場合、バッファー空間が利用可能になるまで待機します。
|
||||
private async sendWithBackpressure(chunk: ArrayBuffer) {
|
||||
// DataChannelバッファー使用量がプリセット最大値を超えた場合に送信を一時停止
|
||||
while (this.dataChannel.bufferedAmount > this.MAX_BUFFER) {
|
||||
// bufferedamountlowイベントを待機してバッファー空間が解放されたことを示すPromiseを使用
|
||||
await new Promise(r => this.dataChannel.bufferedamountlow = r);
|
||||
}
|
||||
|
||||
// バッファーに十分な空間がある場合に現在のチャンクを送信
|
||||
this.dataChannel.send(chunk);
|
||||
}
|
||||
```
|
||||
|
||||
### 2.2 ゼロコピーメモリ書き込み
|
||||
|
||||
File System Access APIを通じて実装：
|
||||
|
||||
```typescript
|
||||
// lib/fileReceiver.ts
|
||||
|
||||
// 受信したチャンクデータを直接ディスクに書き込み、余分なメモリコピーを回避します
|
||||
private async writeToDisk(chunk: ArrayBuffer) {
|
||||
// ファイルライターがまだ初期化されていない場合
|
||||
if (!this.writer) {
|
||||
// ファイル保存ピッカーダイアログを表示し、ユーザーが保存場所を選択
|
||||
this.currentFileHandle = await window.showSaveFilePicker();
|
||||
|
||||
// ファイルハンドル経由で書き込み可能ストリームを作成し、後続の書き込み用に準備
|
||||
this.writer = await this.currentFileHandle.createWritable();
|
||||
}
|
||||
|
||||
// 受信したArrayBufferをUint8Arrayに変換し、直接ディスクに書き込み
|
||||
// これによりメモリバッファーを回避し、ゼロコピー書き込みを実現して性能を向上
|
||||
await this.writer.write(new Uint8Array(chunk));
|
||||
}
|
||||
```
|
||||
|
||||
## 三、分散部屋管理システム
|
||||
|
||||
### 3.1 四桁数字衝突検出：
|
||||
|
||||
```typescript
|
||||
// server.ts
|
||||
async function getAvailableRoomId() {
|
||||
let roomId;
|
||||
do {
|
||||
roomId = Math.floor(1000 + Math.random() * 9000); // 四桁の乱数を生成
|
||||
} while (await redis.hexists(`room:${roomId}`, "created_at")); // 存在するかチェック
|
||||
return roomId;
|
||||
}
|
||||
```
|
||||
|
||||
注：4桁の数字はシステム生成のランダム部屋IDです。お好みの任意の部屋IDを指定できます。
|
||||
|
||||
### 3.2 優雅な有効期限戦略：
|
||||
|
||||
```typescript
|
||||
// server.ts
|
||||
await refreshRoom(roomId, 3600 * 24); // アクティブ部屋は24時間保持
|
||||
if (await isRoomEmpty(roomId)) {
|
||||
// 空き部屋の場合（送信者と受信者の両方が退出した場合）、部屋を解放
|
||||
await deleteRoom(roomId);
|
||||
}
|
||||
```
|
||||
|
||||
### 3.3 シグナリング駆動の復旧プロトコル
|
||||
|
||||
モバイル切断回復フロー：
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Sender
|
||||
participant Signaling
|
||||
participant Recipient
|
||||
|
||||
Sender->>Signaling: フロントエンド可視時にinitiator-onlineを送信
|
||||
Signaling->>Recipient: オンライン通知を転送
|
||||
Recipient->>Signaling: recipient-readyで応答
|
||||
Signaling->>Sender: 再接続プロセスをトリガー
|
||||
Sender->>Recipient: ICE接続を再構築
|
||||
```
|
||||
|
||||
このメカニズムにより、ユーザーがモバイルデバイスでアプリを切り替えたりバックグラウンドに入ったりしても、システムは迅速に接続を回復できます（モバイルでもWakelockでスリープを防止）、良好なユーザー体験を保証します。
|
||||
|
||||
## 四、セキュリティとプライバシー防御ライン
|
||||
|
||||
### 4.1 暗号化プロトコルフライホイール
|
||||
|
||||
```
|
||||
アプリケーション層
|
||||
↑
|
||||
DTLS 1.2+ → TLS_ECDHE_RSA_AES_128_GCM_SHA256
|
||||
↑
|
||||
OSレベル暗号化
|
||||
```
|
||||
|
||||
**説明：**
|
||||
|
||||
1. **DTLS（Datagram Transport Layer Security）**：
|
||||
- DTLSはUDPベースのセキュア伝送プロトコルで、TLS類似の暗号化機能を提供します。
|
||||
- WebRTCでは、すべてのデータチャネルがDTLS経由でエンドツーエンド暗号化され、伝送中の盗聴や改ざんを防ぎます。
|
||||
- 暗号化スイート**`TLS_ECDHE_RSA_AES_128_GCM_SHA256`**を使用し、高強度のセキュリティを提供します。
|
||||
2. **OSレベル暗号化**：
|
||||
- OSレベルで、現代ブラウザーはメモリ内の機密データに追加保護を提供し、悪意のあるソフトウェアによるアクセスを防ぎます。
|
||||
|
||||
**要約：**
|
||||
DTLSとOSレベル暗号化の二重保護により、WebRTCは強力なプライバシー保護能力を提供し、ファイル転送中のデータセキュリティを保証します。
|
||||
|
||||
### 4.2 攻撃面防御マトリックス
|
||||
|
||||
| **攻撃タイプ** | **防御措置** | **説明** |
|
||||
| --- | --- | --- |
|
||||
| **MITM** | **SDP指紋検証** | **DTLS公開鍵ハッシュ値から一意の指紋を生成し、通信相手の信頼性を確保し、中間者によるデータストリームの偽造や改ざんを防止します。** |
|
||||
| **部屋ID巡回攻撃** | **部屋入室レート制限** | **各IPアドレスの部屋入室頻度を制限し（例：5秒以内に最大2回）、悪意のあるユーザーが部屋番号を巡回してコンテンツにアクセスするのを防ぎます。** |
|
||||
|
||||
**説明：**
|
||||
|
||||
1. **MITM（Man-in-the-Middle Attack）**
|
||||
- **原理**：WebRTCはSDP指紋（DTLS公開鍵ハッシュ値に基づく）を使用してハンドシェイク中に通信相手の身份を検証します。攻撃者は有効な指紋を偽造できないため、正当な通信者を装うことができません。
|
||||
- **効果**：P2P接続のセキュリティとデータ完全性を保証し、盗聴や改ざんを防ぎます。
|
||||
2. **部屋ID巡回攻撃**
|
||||
- **定義**：悪意のあるユーザーが異なる部屋番号（例：4桁ID）を試すことで、未承認の部屋に入り共有コンテンツにアクセスしようとする可能性があります。
|
||||
- **防御措置**：
|
||||
- **レート制限**：各IPアドレスの部屋入室頻度を制限します。例：5秒以内に最大2回の部屋入室を許可。
|
||||
- **実装方法**：Redisを使用してIPリクエスト記録をキャッシュし、異常な動作の迅速な検出とブロッキングを行います。
|
||||
- **効果**：悪意のあるユーザーが部屋番号巡回による機密コンテンツアクセスを効果的に防ぎ、ユーザープライバシーを保護します。
|
||||
|
||||
## 結論：信頼できる転送インフラの構築
|
||||
|
||||
私たちは、技術が本質的な人間のニーズに奉仕すべきであり、新しい監視依存を作るべきではないと固く信じています。今すぐこのプライバシーセキュアなファイル転送ツールを体験し、P2P技術がもたらす革命的変化を感じてください！[<u>**PrivyDropポータル**</u>](https://www.privydrop.app)をクリックして開始してください。
|
||||
|
||||
**コード透明性コミットメント**：コードは将来的にオープンソース化されます。私たちは、社区共同ガバナンスを通じて真に信頼できるプライバシーツールを確立することに取り組んでいます。
|
||||
|
||||
## よくある質問
|
||||
|
||||
- **大きなファイル転送は中断しやすいですか？**
|
||||
- まだそのようなケースは観察されていません。P2P（デバイス間）接続は一般的に安定しています。将来のフィードバックに基づき、レジューム機能を追加する可能性があります。
|
||||
- **部屋にパスワードを追加するとより安全になりますか？**
|
||||
- 理論的にははい。パスワード追加がわずかに使いやすさに影響することを考慮し、まだ実装されていません。セキュリティを向上させたい場合、任意のカスタム文字列をRoomIDとして使用し、リンクとQRコード経由で共有できます。さらに、システムは受信者の部屋入室頻度を制限し、さらなるセキュリティ向上を図っています。
|
||||
- **送信者はいつでもPrivyDropページを閉じられますか？**
|
||||
- はい、コンテンツが受信された後に閉じることが望ましいです。デバイス間直接接続のため、送信者がオフラインの場合、共有は不可能です。共有を停止したい場合、ページをすぐに閉じることができます。
|
||||
|
||||
その他の質問？[<u>**PrivyDrop FAQ**</u>](https://www.privydrop.app/faq)または[<u>**PrivyDrop Help**</u>](https://www.privydrop.app/help)セクションをクリックして、さらに回答とヘルプをご覧ください。
|
||||
|
||||
**開発者リソース**
|
||||
|
||||
- [<u>**WebRTC公式ドキュメント**</u>](https://webrtc.org/)
|
||||
@@ -0,0 +1,277 @@
|
||||
---
|
||||
title: "브라우저 간 직접 연결! WebRTC 기반 프라이버시 보호 파일 전송 핵심 기술 공개"
|
||||
description: "이 기사는 WebRTC 기반 프라이버시 보호 파일 전송 도구의 핵심 기술에 대해 깊이 탐구하며, P2P 전송, E2EE 암호화, 스트림 멀티플렉싱 등을 포함합니다. 기술 애호가와 일반 사용자 모두에게 적합합니다."
|
||||
date: "2025-02-09"
|
||||
author: "david bai"
|
||||
cover: "/blog-assets/webrtc-file-transfer.jpg"
|
||||
tags: [WebRTC, P2P 전송, 프라이버시 보안]
|
||||
status: "published"
|
||||
---
|
||||
|
||||
|
||||
|
||||
## 서론
|
||||
|
||||
전통적인 파일 전송 방식은 대부분 클라우드 스토리지나 중앙 집중식 서버에 의존하여 데이터 프라이버시에 대한 우려를 제기할 뿐만 아니라 업로드 크기 제한, 속도 병목 현상 등 많은 문제에 직면했습니다. 우리의 도구는 WebRTC 기술을 활용하여 기기 간 직접 전송을 실현하여 이러한 문제들을 완전히 해결했습니다.
|
||||
|
||||
우리가 개발한 이 도구([<u>**PrivyDrop**</u>](https://www.privydrop.app))는 다음과 같은 두드러진 특징을 가지고 있습니다:
|
||||
|
||||
- WebRTC 기술을 사용한 기기 간 직접 전송, 중간 서버 불필요
|
||||
- 종단 간 암호화(E2EE)로 안전한 데이터 전송 보장
|
||||
- 등록 불필요, 즉시 사용 가능, 다중 동시 수신자 지원
|
||||
- 텍스트, 이미지, 파일, 폴더 등 다양한 유형의 데이터 전송 지원
|
||||
- 전송 속도와 파일 크기는 기기 간 네트워크 대역폭과 디스크 공간에만 제한
|
||||
|
||||
이 기사에서는 이 도구의 기술 아키텍처, 작동 원리, 그리고 왜 이렇게 안전하고 효율적인 파일 전송 경험을 제공할 수 있는지에 대해 탐구합니다. 기술 애호가이든 일반 사용자이든, WebRTC 기술이 파일 전송 분야에 가져온 혁명적인 변화를 이해할 수 있을 것입니다.
|
||||
|
||||
## 일. 파일 전송 재정의: WebRTC의 아키텍처 혁명
|
||||
|
||||
WebRTC(Web Real-Time Communication)는 브라우저 간 실시간 통신을 지원하는 개방형 표준입니다. WebRTC 기반으로 개발된 우리의 파일 전송 도구는 주로 다음과 같은 핵심 구성 요소를 포함합니다:
|
||||
|
||||
1. **시그널링 서버**: 기기 간 연결을 조정하지만 실제 데이터 전송에는 참여하지 않습니다.
|
||||
2. **P2P 연결**: 제3자 서버 개입 없이 기기 간 직접 연결을 설정합니다.
|
||||
3. **E2EE 암호화**: 모든 데이터가 전송 중 DTLS 프로토콜로 종단 간 암호화됩니다.
|
||||
|
||||
### 1.1 전통적인 방식 vs WebRTC 방식
|
||||
|
||||
| 특징 | 전통적 HTTP 전송 | WebRTC P2P 전송 |
|
||||
| --- | --- | --- |
|
||||
| 전송 경로 | 클라이언트 → 서버 → 클라이언트 | 기기 간 직접 연결 |
|
||||
| 지연 시간 | 중앙 서버 대역폭에 제한됨 | 물리적 네트워크 대역폭에만 제한됨 |
|
||||
| 파일 크기 제한 | 일반적으로 제한 있음 | 디스크 공간에만 제한됨 |
|
||||
| 프라이버시 보호 | 서비스 제공업체 보안 조치에 의존 | DTLS 프로토콜 강제 암호화 |
|
||||
|
||||
### 1.2 P2P 연결 설정 프로세스
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant UserA as 사용자 A(송신자)
|
||||
participant SignalingServer as 시그널링 서버
|
||||
participant UserB as 사용자 B(수신자)
|
||||
|
||||
UserA->>SignalingServer: (1) 방 생성 및 참여
|
||||
activate SignalingServer
|
||||
|
||||
UserB->>SignalingServer: (2) 방 참여
|
||||
SignalingServer-->>UserA: 사용자 B 참여 통지
|
||||
|
||||
UserA->>SignalingServer: (3) WebRTC 협상 정보(SDP/ICE) 전송
|
||||
SignalingServer-->>UserB: WebRTC 협상 정보(SDP/ICE) 전달
|
||||
|
||||
UserB->>SignalingServer: (4) WebRTC 협상 정보(SDP/ICE) 응답
|
||||
SignalingServer-->>UserA: 응답 WebRTC 협상 정보(SDP/ICE) 전달
|
||||
|
||||
UserA-->>UserB: (5) P2P 연결(DataChannel) 설정
|
||||
UserA->>UserB: (6) DataChannel을 통한 파일 청크 전송
|
||||
```
|
||||
|
||||
**프로세스:**
|
||||
|
||||
1. 사용자 A가 방을 생성하고 참여하여 시그널링 서버에 연결합니다.
|
||||
2. 사용자 B가 방에 참여하여 시그널링 서버에 연결합니다.
|
||||
3. 사용자 A가 사용자 B와 WebRTC 협상(SDP 및 ICE 정보 포함)을 시작합니다.
|
||||
4. 사용자 B가 WebRTC 협상 정보로 응답하여 P2P 연결 설정을 완료합니다.
|
||||
5. 최종적으로 파일이 P2P 연결 위의 DataChannel을 통해 전송됩니다.
|
||||
|
||||
### 1.3 SCTP(over DTLS & UDP)의 성능 마법
|
||||
|
||||
WebRTC의 **DataChannel**은 **DTLS**와 **UDP** 위에서 실행되는 **스트림 제어 전송 프로토콜(SCTP)**을 기반으로 하며, 전통적인 TCP에 비해 세 가지 큰 장점을 가집니다:
|
||||
|
||||
1. **스트림 멀티플렉싱(현재 미사용)**: 파일 청크를 병렬로 전송할 수 있어 전송 효율을 향상시킵니다.
|
||||
2. **헤드 오브 라인 블로킹 없음**: 단일 청크 손실이 전체 진행에 영향을 주지 않아 전송 안정성을 보장합니다.
|
||||
3. **자동 혼잡 제어**: 네트워크 지터에 동적으로 적응하여 전송 성능을 최적화합니다.
|
||||
|
||||
**UDP의 장점:**
|
||||
|
||||
- **낮은 지연 시간**: UDP는 3-way 핸드셰이크가 필요 없는 연결 없는 프로토콜로, 실시간 통신에 이상적입니다.
|
||||
- **유연한 신뢰성**: UDP 자체는 신뢰성 없지만, SCTP가 그 위에 신뢰성 있는 전송 메커니즘을 구현하여 UDP의 유연성과 TCP의 신뢰성을 결합합니다.
|
||||
|
||||
**SCTP 다중 스트림 전송 다이어그램**
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[송신자] --> B[DataChannel 1]
|
||||
A --> C[DataChannel 2]
|
||||
A --> D[DataChannel 3]
|
||||
B --> E[수신자]
|
||||
C --> E
|
||||
D --> E
|
||||
```
|
||||
|
||||
## 이. 브라우저 직접 전송 엔진: 핵심 기술 해독
|
||||
|
||||
### 2.1 청크 전송의 정밀 제어
|
||||
|
||||
```typescript
|
||||
// lib/fileSender.ts - 64KB 고정 크기 청크
|
||||
|
||||
// 각 청크 크기를 65536 바이트(64KB)로 정의하여 네트워크 MTU(최대 전송 단위) 크기에 정확히 일치시킵니다.
|
||||
// 이는 과대한 패킷으로 인한 네트워크 혼잡이나 단편화 문제를 방지합니다.
|
||||
private readonly CHUNK_SIZE = 65536;
|
||||
|
||||
// 고정 크기로 파일을 청크 처리하기 위한 비동기 생성기 함수를 생성합니다.
|
||||
// 각 생성기 호출 시 ArrayBuffer 유형의 청크 데이터를 반환합니다.
|
||||
private async *createChunkGenerator(file: File) {
|
||||
let offset = 0; // 현재 파일 읽기 위치를 표시하기 위해 오프셋 초기화
|
||||
|
||||
// 모든 데이터가 청크 처리될 때까지 파일 루프
|
||||
while (offset < file.size) {
|
||||
// File.slice 메서드를 사용하여 [offset, offset + CHUNK_SIZE) 범위의 데이터 세그먼트 추출
|
||||
const chunk = file.slice(offset, offset + this.CHUNK_SIZE);
|
||||
|
||||
// 추출한 데이터를 ArrayBuffer로 변환하고 yield를 통해 반환
|
||||
yield await chunk.arrayBuffer();
|
||||
|
||||
// 다음 청크용 오프셋 업데이트
|
||||
offset += this.CHUNK_SIZE;
|
||||
}
|
||||
}
|
||||
|
||||
// 백 프레셔 제어 알고리즘: 전송이 DataChannel 버퍼 제한을 초과하지 않도록 합니다.
|
||||
// 버퍼가 가득 찬 경우 버퍼 공간이 사용 가능해질 때까지 기다립니다.
|
||||
private async sendWithBackpressure(chunk: ArrayBuffer) {
|
||||
// DataChannel 버퍼 사용량이 사전 설정된 최대치를 초과할 때 전송 일시 중지
|
||||
while (this.dataChannel.bufferedAmount > this.MAX_BUFFER) {
|
||||
// 버퍼 공간 해제를 나타내는 bufferedamountlow 이벤트를 위해 Promise 사용
|
||||
await new Promise(r => this.dataChannel.bufferedamountlow = r);
|
||||
}
|
||||
|
||||
// 버퍼에 충분한 공간이 있을 때 현재 청크 전송
|
||||
this.dataChannel.send(chunk);
|
||||
}
|
||||
```
|
||||
|
||||
### 2.2 제로 카피 메모리 쓰기
|
||||
|
||||
File System Access API를 통해 구현:
|
||||
|
||||
```typescript
|
||||
// lib/fileReceiver.ts
|
||||
|
||||
// 수신된 청크 데이터를 디스크에 직접 쓰기, 추가 메모리 복사 방지
|
||||
private async writeToDisk(chunk: ArrayBuffer) {
|
||||
// 파일 작성기가 아직 초기화되지 않은 경우
|
||||
if (!this.writer) {
|
||||
// 파일 저장 선택 대화상자 표시, 사용자가 저장 위치 선택
|
||||
this.currentFileHandle = await window.showSaveFilePicker();
|
||||
|
||||
// 파일 핸들을 통해 쓰기 가능 스트림(WritableStream) 생성, 후속 쓰기용 준비
|
||||
this.writer = await this.currentFileHandle.createWritable();
|
||||
}
|
||||
|
||||
// 수신된 ArrayBuffer 데이터를 Uint8Array로 변환하고 디스크에 직접 쓰기
|
||||
// 이는 메모리 버퍼를 우회하여 제로 카피 쓰기를 구현하고 성능 향상
|
||||
await this.writer.write(new Uint8Array(chunk));
|
||||
}
|
||||
```
|
||||
|
||||
## 삼. 분산 방 관리 시스템
|
||||
|
||||
### 3.1 네 자리 숫자 충돌 감지:
|
||||
|
||||
```typescript
|
||||
// server.ts
|
||||
async function getAvailableRoomId() {
|
||||
let roomId;
|
||||
do {
|
||||
roomId = Math.floor(1000 + Math.random() * 9000); // 네 자리 난수 생성
|
||||
} while (await redis.hexists(`room:${roomId}`, "created_at")); // 존재 여부 확인
|
||||
return roomId;
|
||||
}
|
||||
```
|
||||
|
||||
참고: 4자리 숫자는 시스템 생성 난수 방 ID입니다. 원하는 모든 방 ID를 지정할 수 있습니다.
|
||||
|
||||
### 3.2 우아한 만료 전략:
|
||||
|
||||
```typescript
|
||||
// server.ts
|
||||
await refreshRoom(roomId, 3600 * 24); // 활성 방 24시간 유지
|
||||
if (await isRoomEmpty(roomId)) {
|
||||
// 방이 비어있는 경우(송신자, 수신자 모두 나간 경우), 방 해제
|
||||
await deleteRoom(roomId);
|
||||
}
|
||||
```
|
||||
|
||||
### 3.3 시그널링 구동 재생 프로토콜
|
||||
|
||||
모바일 연결 끊김 복구 흐름:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Sender
|
||||
participant Signaling
|
||||
participant Recipient
|
||||
|
||||
Sender->>Signaling: 프론트엔드 가시 시 initiator-online 전송
|
||||
Signaling->>Recipient: 온라인 알림 전달
|
||||
Recipient->>Signaling: recipient-ready 응답
|
||||
Signaling->>Sender: 재연결 프로세스 트리거
|
||||
Sender->>Recipient: ICE 연결 재구축
|
||||
```
|
||||
|
||||
이 메커니즘을 통해 사용자가 모바일 기기에서 앱을 전환하거나 백그라운드로 들어가도 시스템은 빠르게 연결을 복구할 수 있습니다(모바일도 수면 방지를 위해 Wakelock 포함), 양호한 사용자 경험을 보장합니다.
|
||||
|
||||
## 사. 보안 및 프라이버시 방어선
|
||||
|
||||
### 4.1 암호화 프로토콜 플라이휠
|
||||
|
||||
```
|
||||
애플리케이션 계층
|
||||
↑
|
||||
DTLS 1.2+ → TLS_ECDHE_RSA_AES_128_GCM_SHA256
|
||||
↑
|
||||
OS 레벨 암호화
|
||||
```
|
||||
|
||||
**설명:**
|
||||
|
||||
1. **DTLS(Datagram Transport Layer Security)**:
|
||||
- DTLS는 UDP 기반의 보안 전송 프로토콜로 TLS 유사 암호화 기능을 제공합니다.
|
||||
- WebRTC에서 모든 데이터 채널(DataChannel)은 DTLS를 통해 종단 간 암호화되어 전송 중 도청이나 변조를 방지합니다.
|
||||
- 암호화 스위트 **`TLS_ECDHE_RSA_AES_128_GCM_SHA256`**를 사용하여 고강도 보안을 제공합니다.
|
||||
2. **OS 레벨 암호화**:
|
||||
- OS 레벨에서 현대 브라우저는 메모리 내 민감 데이터에 대한 추가 보호를 제공하여 악성 소프트웨어 접근을 방지합니다.
|
||||
|
||||
**요약:**
|
||||
DTLS와 OS 레벨 암호화의 이중 보호를 통해 WebRTC는 강력한 프라이버시 보호 능력을 제공하여 파일 전송 과정의 데이터 안전을 보장합니다.
|
||||
|
||||
### 4.2 공격 표면 방어 행렬
|
||||
|
||||
| **공격 유형** | **방어 조치** | **설명** |
|
||||
| --- | --- | --- |
|
||||
| **MITM** | **SDP 지문 검증** | **DTLS 공개 키 해시값에서 고유 지문 생성, 통신 당사자 신뢰성 보장, 중간자 데이터 스트림 위조나 변조 방지.** |
|
||||
| **방 ID 순회 공격** | **방 입장 속도 제한** | **각 IP 주소의 방 입장 빈도 제한(예: 5초 내 최대 2회), 악의적 사용자가 방 번호 순회로 내용 접근 방지.** |
|
||||
|
||||
**설명:**
|
||||
|
||||
1. **MITM(Man-in-the-Middle Attack)**
|
||||
- **원리**: WebRTC는 핸드셰이크 과정에서 SDP 지문(DTLS 공개 키 해시값 기반)을 사용하여 통신 당사자 신원을 검증합니다. 공격자는 유효한 지문을 위조할 수 없으므로 합법적 통신 당사자로 가장할 수 없습니다.
|
||||
- **효과**: P2P 연결 보안과 데이터 무결성 보장, 도청이나 변조 방지.
|
||||
2. **방 ID 순회 공격**
|
||||
- **정의**: 악의적 사용자가 다른 방 번호(예: 네 자리 ID)를 시도하여 미승인 방에 들어가 공유 콘텐츠에 접근하려고 시도할 수 있습니다.
|
||||
- **방어 조치**:
|
||||
- **속도 제한**: 각 IP 주소의 방 입장 빈도 제한, 예: 5초 내 최대 2회 방 입장 허용.
|
||||
- **구현 방식**: Redis를 사용하여 IP 요청 기록 캐시, 이상 동작 빠른 감지 및 차단.
|
||||
- **효과**: 악의적 사용자가 방 번호 순회를 통한 민감 콘텐츠 접근을 효과적으로 방지, 사용자 프라이버시 보호.
|
||||
|
||||
## 결론: 신뢰할 수 있는 전송 인프라 구축
|
||||
|
||||
우리는 기술이 인간의 본질적인 요구를 봉사해야 하며, 새로운 감시 의존을 만들어서는 안 된다고 굳게 믿습니다. 지금 이 프라이버시 보안 파일 전송 도구를 경험하고 P2P 기술이 가져온 혁명적 변화를 느껴보세요! [<u>**PrivyDrop 포털**</u>](https://www.privydrop.app)을 클릭하여 시작하세요.
|
||||
|
||||
**코드 투명성 약속**: 코드는 미래에 오픈 소스가 될 것입니다. 우리는 커뮤니티 공동 거버넌스를 통해 진정으로 신뢰할 수 있는 프라이버시 도구를 확립하는 데 전념하고 있습니다.
|
||||
|
||||
## 자주 묻는 질문
|
||||
|
||||
- **큰 파일 전송이 중단되기 쉬운가요?**
|
||||
- 아직 그런 경우를 관찰하지 않았습니다. P2P(기기 간) 연결은 일반적으로 안정적입니다. 향후 피드백에 따라 재시작 기능을 추가할 수 있습니다.
|
||||
- **방에 비밀번호를 추가하면 더 안전한가요?**
|
||||
- 이론적으로 그렇습니다. 비밀번호 추가가 사용성에 약간 영향을 줄 것을 고려하여 아직 구현되지 않았습니다. 보안을 높이고 싶다면 임의의 사용자 정의 문자열을 RoomID로 사용하고 링크와 QR 코드를 통해 공유할 수 있습니다. 또한 시스템은 수신자의 방 입장 빈도를 제한하여 추가로 보안을 향상시킵니다.
|
||||
- **송신자는 언제든지 PrivyDrop 페이지를 닫을 수 있나요?**
|
||||
- 네, 공유 콘텐츠가 수신된 후에 닫는 것이 좋습니다. 기기 간 직접 연결이므로 송신자가 오프라인이면 공유가 불가능합니다. 공유를 중단하고 싶다면 즉시 페이지를 닫을 수 있습니다.
|
||||
|
||||
더 궁금한 점이 있으신가요? [<u>**PrivyDrop FAQ**</u>](https://www.privydrop.app/faq) 또는 [<u>**PrivyDrop 도움말**</u>](https://www.privydrop.app/help) 섹션을 클릭하여 더 많은 답변과 도움을 확인하세요.
|
||||
|
||||
**개발자 리소스**
|
||||
|
||||
- [<u>**WebRTC 공식 문서**</u>](https://webrtc.org/)
|
||||
+10
-11
@@ -21,17 +21,14 @@ export interface BlogPost {
|
||||
|
||||
export async function getAllPosts(lang: string): Promise<BlogPost[]> {
|
||||
// Read all directories in the blog path
|
||||
const directories = fs.readdirSync(POSTS_PATH)
|
||||
.filter(file => {
|
||||
const fullPath = path.join(POSTS_PATH, file);
|
||||
return fs.statSync(fullPath).isDirectory();
|
||||
});
|
||||
|
||||
const lang_dst = lang === "zh" ? "zh" : "en";
|
||||
const directories = fs.readdirSync(POSTS_PATH).filter((file) => {
|
||||
const fullPath = path.join(POSTS_PATH, file);
|
||||
return fs.statSync(fullPath).isDirectory();
|
||||
});
|
||||
|
||||
const posts = await Promise.all(
|
||||
directories.map(async (directory) => {
|
||||
const filePath = path.join(POSTS_PATH, directory, `${lang_dst}.mdx`);
|
||||
const filePath = path.join(POSTS_PATH, directory, `${lang}.mdx`);
|
||||
|
||||
// Check if the language file exists
|
||||
if (!fs.existsSync(filePath)) {
|
||||
@@ -61,7 +58,10 @@ export async function getAllPosts(lang: string): Promise<BlogPost[]> {
|
||||
);
|
||||
|
||||
return posts
|
||||
.filter((post): post is BlogPost => post !== null && post.frontmatter.status === "published")
|
||||
.filter(
|
||||
(post): post is BlogPost =>
|
||||
post !== null && post.frontmatter.status === "published"
|
||||
)
|
||||
.sort(
|
||||
(a, b) =>
|
||||
new Date(b.frontmatter.date).getTime() -
|
||||
@@ -74,8 +74,7 @@ export async function getPostBySlug(
|
||||
lang: string
|
||||
): Promise<BlogPost | null> {
|
||||
try {
|
||||
const lang_dst = lang === "zh" ? "zh" : "en";
|
||||
const filePath = path.join(POSTS_PATH, slug, `${lang_dst}.mdx`);
|
||||
const filePath = path.join(POSTS_PATH, slug, `${lang}.mdx`);
|
||||
const source = fs.readFileSync(filePath, "utf8");
|
||||
const { data, content } = matter(source);
|
||||
|
||||
|
||||
Reference in New Issue
Block a user