โปรโตคอล FTP บนแว่นตาอัจฉริยะ — การเข้าถึงไฟล์เซิร์ฟเวอร์สำหรับคอมพิวเตอร์แบบสวมใส่ได้

ข้อมูลจำเพาะโปรโตคอล FTP สำหรับแว่นตาอัจฉริยะ

หน้านี้ครอบคลุมด้านเทคนิคของการใช้โปรโตคอล FTP บนฮาร์ดแวร์แว่นตาอัจฉริยะ — กลไกการเชื่อมต่อ การกำหนดค่าเซิร์ฟเวอร์เพื่อความเข้ากันได้ของแว่นตาที่เหมาะสมที่สุด และข้อควรพิจารณาระดับโปรโตคอลสำหรับอุปกรณ์คอมพิวเตอร์ที่สวมใส่ได้โดยเฉพาะ

โปรโตคอล FTP นั้นไม่เชื่อเรื่องอุปกรณ์ — ทำงานเหมือนกันไม่ว่าไคลเอนต์จะเป็นเดสก์ท็อป โทรศัพท์ หรือหน่วยประมวลผลแว่นตาความแตกต่างอยู่ที่ข้อจำกัดของฮาร์ดแวร์: วิธีการป้อนข้อมูล ข้อจำกัดในการแสดงผล ความไวของแบตเตอรี่ และความน่าเชื่อถือของ WiFi

การทำงานของโปรโตคอลบนฮาร์ดแวร์แว่นตา

สแต็กเครือข่าย

หน่วยประมวลผล Glasses ที่ใช้ Android มีสแต็ก TCP/IP มาตรฐาน:

• วิทยุ WiFi ให้การเชื่อมต่อเครือข่าย (2.4/5 GHz ขึ้นอยู่กับฮาร์ดแวร์)
• การเชื่อมต่อซ็อกเก็ตมาตรฐานรองรับการออกแบบช่องสัญญาณคู่ของ FTP
• ช่องควบคุม (พอร์ต 21) รักษาสถานะเซสชัน
• ช่องข้อมูล (พอร์ตไดนามิกโหมดพาสซีฟ) พกพาการถ่ายโอนไฟล์

โฟลว์เซสชัน FTP บน Glasses

1. TCP connect to server:21
2. Receive server banner (220 response)
3. USER username → 331 response
4. PASS password → 230 response (logged in)
5. TYPE I (binary mode) → 200 response
6. PASV → 227 response (data port assigned)
7. LIST (directory listing) → data transfer
8. PASV → 227 (new data port)
9. RETR filename → file download begins
10. QUIT → session ends

การดำเนินการแต่ละครั้งเป็นไปตามโปรโตคอล FTP RFC 959 มาตรฐานAnExplorer จัดการการเจรจาโปรโตคอลทั้งหมดอย่างโปร่งใส

ข้อกำหนดโหมดพาสซีฟ

โหมด Passive (PASV) เป็นสิ่งจำเป็นสำหรับแว่นตา เหตุผล:

• แว่นตาอยู่ด้านหลัง NAT (เราเตอร์ที่บ้าน) — โหมดที่ใช้งานอยู่จำเป็นต้องมีการเชื่อมต่อแบบเซิร์ฟเวอร์ถึงไคลเอนต์ ซึ่ง NAT จะบล็อก
• แว่นตาอาจมีการจำกัดการรองรับการเชื่อมต่อขาเข้า
• การใช้ FTP สมัยใหม่ทั้งหมดควรใช้โหมดพาสซีฟอยู่แล้ว
• AnExplorer มีค่าเริ่มต้นเป็นโหมดพาสซีฟ

การกำหนดค่าพอร์ตพาสซีฟฝั่งเซิร์ฟเวอร์:

• กำหนดช่วงพอร์ต (เช่น 50,000-51,000)
• เปิดช่วงนี้ในไฟร์วอลล์ถ้ามี
• กำหนดค่าที่อยู่ปลอมหากเซิร์ฟเวอร์อยู่หลัง NAT (สำหรับการเข้าถึงระยะไกล)

การกำหนดค่าเซิร์ฟเวอร์สำหรับแว่นตา

การตั้งค่าเซิร์ฟเวอร์ที่แนะนำ

เพื่อความเข้ากันได้สูงสุดกับหน่วยประมวลผลแว่นตา:

# vsftpd example configuration
pasv_enable=YES
pasv_min_port=50000
pasv_max_port=51000
idle_session_timeout=120
data_connection_timeout=120
utf8_filesystem=YES
ascii_upload_enable=NO
local_enable=YES

อธิบายการตั้งค่าหลัก:

• เปิดใช้งานโหมด Passive: จำเป็นสำหรับแว่นตาที่อยู่หลัง NAT
• การหมดเวลาโดยมาก: แว่นตาอาจนำทางได้ช้าลงหลีกเลี่ยงการขาดการเชื่อมต่อก่อนเวลาอันควร
• รองรับ UTF-8: จัดการชื่อไฟล์ต่างประเทศ
• ค่าเริ่มต้นของโหมดไบนารี่: ไฟล์สื่อต้องถ่ายโอนเป็นไบนารี่
• การตรวจสอบผู้ใช้ภายในเครื่อง: การเข้าถึงชื่อผู้ใช้/รหัสผ่านมาตรฐาน

การตั้งค่าบัญชีผู้ใช้

สร้างผู้ใช้แว่นตาโดยเฉพาะ:

# Create user with restricted shell
useradd -m -s /usr/sbin/nologin glasses-sync
echo "glasses-sync:secure-password" | chpasswd

# Create content directory
mkdir -p /home/glasses-sync/{audio,assets,configs}
chown -R glasses-sync:glasses-sync /home/glasses-sync

หรือบน NAS (แบบ GUI):

1. แผงควบคุม → ผู้ใช้ → สร้าง
2. ชื่อ: "แว่นตาซิงค์"
3. ตั้งค่าการอนุญาต: อ่านอย่างเดียวในการแชร์สื่อ, อ่าน-เขียนในการแชร์การอัพโหลด
4. เปิดใช้งานการเข้าถึง FTP สำหรับผู้ใช้รายนี้

การเพิ่มประสิทธิภาพโครงสร้างโฟลเดอร์

การออกแบบสำหรับการนำทางแบบจำกัดการแสดงผล:

/glasses-sync/
├── audio/           ← First-level: content types
│   ├── new/         ← Second-level: status-based
│   └── favorites/   ← Quick access to known content
├── ar-assets/
│   ├── current/     ← Latest versions only
│   └── archive/     ← Old versions (rarely accessed)
└── upload/          ← For glasses-to-server transfers

หลักการ: ความลึกสูงสุด 2 ระดับสำหรับการเรียกดูแว่นตาเก็บโฟลเดอร์ "ล่าสุด" หรือ "ปัจจุบัน" ไว้ที่ระดับบนสุดเพื่อให้การนำทางน้อยที่สุด

รายละเอียดโปรโตคอลการโอน

ไบนารีกับ ASCII

ใช้ โหมดถ่ายโอนไบนารี่ สำหรับแว่นตาเสมอ:

• ไฟล์เสียง (MP3, FLAC, AAC): ต้องเป็นไบนารี่
• รูปภาพ: ต้องเป็นไบนารี่
• เนื้อหา AR (GLB, พื้นผิว): ต้องเป็นไบนารี
• เฉพาะไฟล์ข้อความธรรมดาเท่านั้นที่สามารถใช้ ASCII ได้ (แต่ไบนารีก็ใช้ได้กับข้อความด้วย)

AnExplorer ตั้งค่าโหมดไบนารีเป็นค่าเริ่มต้นไม่จำเป็นต้องกำหนดค่าผู้ใช้

ดำเนินการต่อการสนับสนุน (คำสั่ง REST)

ประวัติ FTP ช่วยให้การถ่ายโอนถูกขัดจังหวะเพื่อดำเนินการต่อ:

• หาก WiFi ลดลงระหว่างการถ่ายโอน ให้เชื่อมต่อใหม่และดำเนินการต่อจากไบต์สุดท้าย
• เซิร์ฟเวอร์จะต้องรองรับคำสั่ง REST (ส่วนใหญ่ทำ)
• สำคัญอย่างยิ่งกับแว่นตาที่ความเสถียรของ WiFi อาจแตกต่างกันไป
• AnExplorer พยายามดำเนินการต่อโดยอัตโนมัติเนื่องจากการดาวน์โหลดถูกขัดจังหวะ

ขีดจำกัดขนาดการโอน

ไม่มีการจำกัดขนาดโปรโตคอล FTP โดยธรรมชาติข้อจำกัดในทางปฏิบัติสำหรับแว่นตา:

• พื้นที่เก็บข้อมูลที่มีอยู่ในอุปกรณ์ (ตรวจสอบก่อนถ่ายโอนข้อมูลจำนวนมาก)
• อายุการใช้งานแบตเตอรี่ระหว่างการถ่ายโอน (ไฟล์ขนาดใหญ่ต้องใช้เวลา)
• ความเสถียรของเซสชัน WiFi (การถ่ายโอนนานขึ้น = มีโอกาสหยุดชะงักมากขึ้น)

การเปรียบเทียบโปรโตคอลสำหรับแว่นตา

สำหรับเสียงแบบแว่นตา: SMB สำหรับการสตรีม FTP/SFTP สำหรับการดาวน์โหลด สำหรับเนื้อหา Glass: FTP สำหรับการปรับใช้จำนวนมาก SFTP สำหรับเนื้อหาที่ละเอียดอ่อน

ประสิทธิภาพการทำงานของฮาร์ดแวร์แว่นตา

ผลกระทบของ CPU

FTP เองมีค่าใช้จ่าย CPU น้อยที่สุด (ต่างจาก SFTP ที่ต้องมีการเข้ารหัส/ถอดรหัส)ในหน่วยประมวลผลแว่นตาที่มีพลังการประมวลผลจำกัด ความต้องการ CPU ที่ต่ำกว่าของ FTP หมายถึง:

• ถ่ายโอนได้เร็วขึ้น (ไม่มีคอขวดการเข้ารหัส)
• สิ้นเปลืองแบตเตอรี่น้อยลงระหว่างการถ่ายโอน
• ระบบยังคงตอบสนองในระหว่างการดาวน์โหลด

การใช้หน่วยความจำ

รอยเท้าหน่วยความจำไคลเอนต์ FTP:

• ช่องควบคุม: น้อยที่สุด (โปรโตคอลแบบข้อความ)
• การถ่ายโอนข้อมูล: ขนาดบัฟเฟอร์ (โดยทั่วไป 8-64 KB)
• รายชื่อไดเร็กทอรี: สัดส่วนกับจำนวนไฟล์
• ทั้งหมด: ไม่มีนัยสำคัญในอุปกรณ์ Android สมัยใหม่ (แม้แต่หน่วยประมวลผล)

สถานะพลังงาน WiFi

หน่วยประมวลผลของ Glasses จัดการพลังงาน WiFi อย่างจริงจัง:

• WiFi อาจเข้าสู่โหมดสลีประหว่างการโต้ตอบของผู้ใช้
• การถ่ายโอน FTP ที่ใช้งานช่วยให้ WiFi ตื่นตัว
• การเชื่อมต่อที่ไม่ได้ใช้งานอาจหมดเวลาหาก WiFi เข้าสู่โหมดงีบหลับ
• วิธีแก้ปัญหา: ทำให้การโต้ตอบเคลื่อนไหวต่อไปหรือดาวน์โหลดทุกอย่างในคราวเดียว

การแก้ไขปัญหา FTP บนแว่นตา

การเชื่อมต่อถูกปฏิเสธ

• เซิร์ฟเวอร์ไม่ทำงานหรือพอร์ตผิด
• ไฟร์วอลล์บล็อกการเชื่อมต่อจาก IP ของแว่นตา
• เซิร์ฟเวอร์เชื่อมโยงกับอินเทอร์เฟซที่ไม่ถูกต้อง (เฉพาะ localhost เท่านั้น)
• แก้ไข: ตรวจสอบสถานะเซิร์ฟเวอร์ ตรวจสอบกฎไฟร์วอลล์

การเข้าสู่ระบบล้มเหลว (ตอบกลับ 530 ครั้ง)

• ข้อมูลรับรองไม่ถูกต้อง
• ผู้ใช้ไม่ได้รับอนุญาตให้เข้าถึง FTP
• พยายามล้มเหลวหลายครั้งเกินไป (ล็อกเอาต์ชั่วคราว)
• แก้ไข: ตรวจสอบข้อมูลรับรองบนไคลเอนต์อื่น ตรวจสอบสิทธิ์ผู้ใช้เซิร์ฟเวอร์

โหมดพาสซีฟล้มเหลว (ไม่มีการเชื่อมต่อข้อมูล)

• ไม่ได้กำหนดค่าช่วงพอร์ตแบบพาสซีฟบนเซิร์ฟเวอร์
• ไฟร์วอลล์บล็อกช่วงพอร์ตแบบพาสซีฟ
• เซิร์ฟเวอร์ส่งคืน IP ที่ไม่ถูกต้องในการตอบกลับ PASV (ปัญหา NAT)
• แก้ไข: กำหนดค่าช่วงพอร์ตแบบพาสซีฟ ตรวจสอบไฟร์วอลล์ ตั้งค่าที่อยู่ปลอม

หมดเวลาการโอน

• WiFi ลดลงระหว่างการถ่ายโอน
• หมดเวลาการเชื่อมต่อข้อมูลเซิร์ฟเวอร์สั้นเกินไป
• ประหยัดแบตเตอรี่ฆ่า WiFi
• แก้ไข: เพิ่มการหมดเวลาของเซิร์ฟเวอร์, ทำให้แว่นตาทำงานอยู่, ตรวจสอบความเสถียรของ WiFi

ไฟล์เสียหายหลังการถ่ายโอน

• โหมด ASCII ที่ใช้สำหรับไฟล์ไบนารี่ (ใช้ไบนารี่เสมอ)
• การถ่ายโอนขัดจังหวะโดยไม่มีประวัติ
• แก้ไข: ดาวน์โหลดซ้ำในโหมดไบนารี ตรวจสอบขนาดไฟล์ให้ตรงกับเซิร์ฟเวอร์

แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัย

สำหรับการใช้งานเครือข่ายในบ้าน

• การเข้ารหัส WPA2/WPA3 WiFi ปกป้องส่วนไร้สาย
• การเดินทางข้อมูลรับรอง FTP ถูกเข้ารหัสภายในอุโมงค์ WiFi
• ผู้ใช้เฉพาะที่มีสิทธิ์ขั้นต่ำจำกัดการเปิดเผย
• การรักษาความปลอดภัยที่ยอมรับได้สำหรับการซิงค์สื่อส่วนบุคคล

สำหรับการใช้งานในองค์กร

• ใช้ SFTP แทน — การเข้ารหัสจากต้นทางถึงปลายทางโดยสมบูรณ์
• การรับรองความถูกต้องตามใบรับรอง (ไม่มีรหัสผ่านเพื่อสกัดกั้น)
• การแบ่งส่วนเครือข่าย (แว่นตาบน VLAN แยก)
• ตรวจสอบการบันทึกบนเซิร์ฟเวอร์เพื่อการปฏิบัติตามข้อกำหนด

ที่เก็บข้อมูลรับรองบนแว่นตา

AnExplorer บันทึกข้อมูลประจำตัว FTP ในที่จัดเก็บข้อมูลที่ปลอดภัยของอุปกรณ์:

• เข้ารหัสที่เหลือบน Android ที่ทันสมัย
• ป้องกันโดยการล็อคอุปกรณ์ (PIN, รูปแบบ, ไบโอเมตริกซ์)
• ข้อควรพิจารณา: หากแว่นตาสูญหาย จะสามารถเข้าถึงข้อมูลรับรองที่บันทึกไว้ได้
• การบรรเทาผลกระทบ: บัญชี FTP ที่ได้รับอนุญาตแบบจำกัดจะช่วยลดความเสียหายให้เหลือน้อยที่สุด

คำแนะนำที่เกี่ยวข้อง

• ไคลเอนต์ FTP สำหรับแว่นตาอัจฉริยะ — ภาพรวมคุณสมบัติ FTP
• SMB บนแว่นตาอัจฉริยะ — โปรโตคอลทางเลือก
• WebDAV บนแว่นตาอัจฉริยะ — การเข้าถึงโปรโตคอล WebDAV
• โปรโตคอล SFTP — ทางเลือกที่ปลอดภัยแทน FTP