HTTP/HTTPS: คืออะไร โปรโตคอลการถ่ายโอนข้อมูลและการเข้ารหัส TLS

HTTP และ HTTPS คืออะไร?

HTTP (HyperText Transfer Protocol) เป็นโปรโตคอลเลเยอร์แอปพลิเคชันของโมเดล OSI ที่ออกแบบมาสำหรับการถ่ายโอนเอกสารไฮเปอร์เท็กซ์และข้อมูลอื่นๆ บนเวิลด์ไวด์เว็บ พัฒนาโดย Tim Berners-Lee ในปี 1989 HTTP ผ่านหลายเวอร์ชัน: จาก HTTP/0.9 (เฉพาะคำขอ GET และการตอบกลับ HTML) ไปจนถึง HTTP/2 และ HTTP/3 สมัยใหม่ โปรโตคอลทำงานตามโมเดลคำขอ-ตอบกลับ: ไคลเอ็นต์ส่งคำขอไปยังเซิร์ฟเวอร์ เซิร์ฟเวอร์ประมวลผลและส่งคืนการตอบกลับ

HTTPS (HTTP Secure) เป็นส่วนขยายของโปรโตคอล HTTP ที่เพิ่มเลเยอร์การเข้ารหัสผ่าน TLS (Transport Layer Security) HTTPS ไม่ใช่โปรโตคอลแยกต่างหาก — เป็นการรวมกันของ HTTP และ TLS ข้อมูลที่ส่งผ่าน HTTPS จะถูกเข้ารหัสที่ฝั่งไคลเอ็นต์และถอดรหัสที่เซิร์ฟเวอร์ ทำให้ไม่สามารถเข้าถึงเพื่อการดักจับและแก้ไขได้ HTTPS ยังให้การตรวจสอบสิทธิ์เซิร์ฟเวอร์ผ่านใบรับรอง SSL/TLS เพื่อให้แน่ใจว่าไคลเอ็นต์เชื่อมต่อกับเซิร์ฟเวอร์จริง ไม่ใช่ผู้โจมตี

ความแตกต่างหลักระหว่าง HTTP และ HTTPS คือ ความปลอดภัย HTTP ส่งข้อมูลในรูปแบบข้อความธรรมดา: โหนดเครือข่ายใดๆ ระหว่างไคลเอ็นต์และเซิร์ฟเวอร์สามารถอ่านเนื้อหาของคำขอหรือการตอบกลับได้ HTTPS เข้ารหัสเนื้อหาทั้งหมด รวมถึง URL ส่วนหัวและเนื้อหาคำขอ โดยเหลือเพียงที่อยู่ IP ของเซิร์ฟเวอร์และพอร์ตการเชื่อมต่อที่มองเห็นได้ สำหรับแอปพลิเคชันมือถือที่ทำงานผ่านเครือข่าย Wi-Fi สาธารณะ HTTPS เป็นข้อกำหนดด้านความปลอดภัยที่จำเป็น

HTTP ทำงานอย่างไร

HTTP เป็นโปรโตคอลไร้สถานะ (stateless) ที่ทำงานบน TCP/IP ไคลเอ็นต์สร้างการเชื่อมต่อ TCP กับเซิร์ฟเวอร์ (โดยปกติบนพอร์ต 80 สำหรับ HTTP หรือ 443 สำหรับ HTTPS) ส่งคำขอ HTTP รับการตอบกลับ HTTP และปิดการเชื่อมต่อ (ใน HTTP/1.1 สามารถใช้การเชื่อมต่อซ้ำได้) การโต้ตอบแต่ละครั้งระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ประกอบด้วยคำขอและการตอบกลับ การไม่มีสถานะหมายความว่าเซิร์ฟเวอร์ไม่เก็บข้อมูลเกี่ยวกับคำขอของไคลเอ็นต์ก่อนหน้า — แต่ละคำขอถูกประมวลผลอย่างอิสระ

กระบวนการโต้ตอบ HTTP ประกอบด้วยขั้นตอนต่อไปนี้:

• การแก้ไข DNS — เบราว์เซอร์หรือไคลเอ็นต์แปลงชื่อโดเมนเป็นที่อยู่ IP ผ่าน DNS
• การจับมือ TCP — สร้างการเชื่อมต่อ TCP ผ่านการจับมือสามทาง (SYN, SYN-ACK, ACK)
• การจับมือ TLS — สำหรับ HTTPS จะสร้างการเชื่อมต่อที่เข้ารหัสเพิ่มเติม (การแลกเปลี่ยนใบรับรองและคีย์)
• คำขอ HTTP — ไคลเอ็นต์ส่งวิธีการ URL ส่วนหัว และตัวเลือกเนื้อหาคำขอ
• การตอบกลับ HTTP — เซิร์ฟเวอร์ส่งคืนรหัสสถานะ ส่วนหัว และเนื้อหาการตอบกลับ

คุณลักษณะสำคัญของ HTTP คือ การไม่เปลี่ยนสภาพของวิธีการ (idempotency) GET, HEAD, PUT, DELETE และ OPTIONS เป็นแบบ idempotent: การดำเนินการซ้ำๆ ของคำขอเดียวกันไม่เปลี่ยนสถานะเซิร์ฟเวอร์หลังจากการดำเนินการครั้งแรก POST, PATCH และ CONNECT ไม่เป็น idempotent — แต่ละการเรียกสามารถสร้างทรัพยากรใหม่หรือเปลี่ยนสถานะได้ สำหรับการพัฒนาแอปมือถือ การทำความเข้าใจ idempotency เป็นสิ่งสำคัญ: เมื่อส่งคำขอซ้ำเนื่องจากข้อผิดพลาดเครือข่าย ไคลเอ็นต์ต้องรู้ว่าการทำซ้ำคำขอนั้นปลอดภัยหรือไม่

HTTPS และการเข้ารหัส TLS

HTTPS ใช้โปรโตคอลการเข้ารหัส TLS (Transport Layer Security) เพื่อปกป้องข้อมูลที่ส่ง TLS เป็นผู้สืบทอดของ SSL (Secure Sockets Layer) ซึ่งพัฒนาโดย Netscape ในปี 1995 เวอร์ชัน SSL 2.0 และ 3.0 ถือว่าล้าสมัยและไม่ปลอดภัย เวอร์ชันสมัยใหม่ TLS 1.2 (เปิดตัวในปี 2008) และ TLS 1.3 (เปิดตัวในปี 2018) ถูกใช้อย่างแพร่หลาย โดยเฉพาะ TLS 1.3 ลดเวลาในการสร้างการเชื่อมต่อจาก 2 รอบเหลือ 1 รอบ ซึ่งช่วยเร่งการโหลดบนอุปกรณ์มือถือได้อย่างมาก

กระบวนการจับมือ TLS ประกอบด้วยขั้นตอนต่อไปนี้:

• Client Hello — ไคลเอ็นต์ส่งรายการเวอร์ชัน TLS และชุดรหัสที่รองรับ
• Server Hello — เซิร์ฟเวอร์เลือกเวอร์ชัน TLS และชุดรหัส ส่งใบรับรอง SSL/TLS
• การตรวจสอบใบรับรอง — ไคลเอ็นต์ตรวจสอบใบรับรองของเซิร์ฟเวอร์ผ่านห่วงโซ่ความเชื่อถือไปยัง CA ราก
• การแลกเปลี่ยนคีย์ — ไคลเอ็นต์และเซิร์ฟเวอร์สร้างคีย์ลับร่วมกัน (คีย์เซสชัน)
• การเปลี่ยนรหัส — ทั้งสองฝ่ายยืนยันการเปลี่ยนไปใช้การสื่อสารที่เข้ารหัส

การตรวจสอบ ใบรับรอง SSL/TLS เป็นขั้นตอนสำคัญสำหรับความปลอดภัย ไคลเอ็นต์ตรวจสอบว่าใบรับรอง: ยังไม่หมดอายุ ลงนามโดยหน่วยงานออกใบรับรอง (CA) ที่เชื่อถือได้ ตรงกับโดเมนใน URL และไม่ได้ถูกเพิกถอน (ผ่าน CRL หรือ OCSP) ในแอปพลิเคชันมือถือ แนะนำให้ใช้ การปักหมุดใบรับรอง (Certificate Pinning) — การผูกกับใบรับรองเซิร์ฟเวอร์หรือคีย์สาธารณะเฉพาะ ซึ่งป้องกันการโจมตี MITM แม้ในกรณีที่ CA ถูกบุกรุก อย่างไรก็ตาม การปักหมุดต้องใช้ความระมัดระวัง: เมื่อใบรับรองเปลี่ยนไป แอปพลิเคชันต้องได้รับการอัปเดตล่วงหน้า

โครงสร้างคำขอและการตอบกลับ HTTP

คำขอ HTTP ประกอบด้วยสามส่วน: บรรทัดคำขอ ส่วนหัว และเนื้อหาที่เป็นตัวเลือก บรรทัดคำขอประกอบด้วยวิธีการ HTTP, URL คำขอ และเวอร์ชัน HTTP ส่วนหัวส่งข้อมูลเมตา: ประเภทเนื้อหา โทเคนการตรวจสอบสิทธิ์ การตั้งค่าแคช เนื้อหามีเฉพาะในวิธีการที่ส่งข้อมูล (POST, PUT, PATCH) และไม่มีใน GET และ DELETE

ตัวอย่างคำขอ HTTP ไปยัง REST API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "อันนา",
    "email": "anna@example.com"
}

การตอบกลับ HTTP มีโครงสร้างคล้ายกัน: บรรทัดสถานะพร้อมเวอร์ชัน HTTP และรหัสสถานะ ส่วนหัว และเนื้อหา รหัสสถานะเป็นตัวเลขสามหลักที่กำหนดผลลัพธ์ของการประมวลผลคำขอ ส่วนหัวการตอบกลับประกอบด้วย Content-Type, Content-Length, Cache-Control, Set-Cookie และอื่นๆ เนื้อหาการตอบกลับประกอบด้วยข้อมูลที่ร้องขอในรูปแบบที่ระบุใน Content-Type (โดยปกติ JSON สำหรับ API, HTML สำหรับเว็บเพจ, รูปภาพสำหรับเนื้อหาสื่อ)

ส่วนหัวมีบทบาทสำคัญในการทำงานของ HTTP Content-Type และ Accept ควบคุมรูปแบบข้อมูล Authorization ส่งโทเคนการเข้าถึง Cache-Control จัดการแคช ส่วนหัว CORS (Access-Control-Allow-Origin) ควบคุมการเข้าถึงจากโดเมนอื่นในเบราว์เซอร์ User-Agent ระบุแอปพลิเคชันไคลเอ็นต์ สำหรับแอปพลิเคชันมือถือ ส่วนหัวควบคุมแคชมีความสำคัญเป็นพิเศษ — ช่วยลดปริมาณข้อมูลที่ส่งและปรับปรุงประสิทธิภาพบนสัญญาณอ่อน

รหัสสถานะ HTTP

รหัสสถานะ HTTP ถูกจัดกลุ่มเป็นห้าคลาส โดยระบุด้วยตัวเลขตัวแรก: 1xx (ข้อมูล), 2xx (สำเร็จ), 3xx (การเปลี่ยนเส้นทาง), 4xx (ข้อผิดพลาดไคลเอ็นต์), 5xx (ข้อผิดพลาดเซิร์ฟเวอร์) การทำความเข้าใจรหัสเหล่านี้จำเป็นสำหรับการจัดการการตอบกลับในแอปพลิเคชันมือถืออย่างถูกต้อง: 2xx หมายถึงสำเร็จและสามารถแสดงข้อมูลได้, 4xx ระบุปัญหากับคำขอ (แสดงข้อผิดพลาดให้ผู้ใช้), 5xx ระบุปัญหาที่เซิร์ฟเวอร์ (ลองอีกครั้งในภายหลัง)

สำหรับแอปพลิเคชันมือถือ การจัดการรหัส 401 Unauthorized มีความสำคัญเป็นพิเศษ เมื่อได้รับรหัสนี้ ไคลเอ็นต์ควรพยายามรีเฟรชโทเคนการเข้าถึงผ่าน Refresh Token และลองคำขอเดิมอีกครั้ง หากการรีเฟรชโทเคนยังส่งคืน 401 ผู้ใช้ต้องถูกเปลี่ยนเส้นทางไปยังหน้าจอเข้าสู่ระบบ ตรรกะนี้มักถูกนำไปใช้ใน Interceptor (OkHttp) หรือในเลเยอร์มิดเดิลแวร์ของไคลเอ็นต์เครือข่าย

HTTP/1.1, HTTP/2 และ HTTP/3

HTTP/1.1 เผยแพร่ในปี 1999 ยังคงเป็นเวอร์ชันที่ใช้กันอย่างแพร่หลายของโปรโตคอล ข้อเสียหลักคือ head-of-line blocking: คำขอไปยังเซิร์ฟเวอร์เดียวกันถูกดำเนินการตามลำดับ แต่ละคำขอรอให้คำขอก่อนหน้าเสร็จสมบูรณ์ เพื่อแก้ไขข้อจำกัดนี้ เบราว์เซอร์เปิดการเชื่อมต่อ TCP แบบขนาน 6-8 รายการไปยังโดเมนเดียวกัน ทำให้โหลดเซิร์ฟเวอร์และการใช้หน่วยความจำเพิ่มขึ้น HTTP/1.1 ยังส่งส่วนหัวในรูปแบบข้อความธรรมดาและไม่รองรับ server push

HTTP/2 (2015) แก้ปัญหาการบล็อกผ่านการมัลติเพล็กซ์ — สตรีมข้อมูลหลายรายการถูกส่งพร้อมกันผ่านการเชื่อมต่อ TCP เดียว เซิร์ฟเวอร์สามารถส่งทรัพยากรไปยังไคลเอ็นต์ก่อนที่ไคลเอ็นต์จะร้องขอ (server push) HTTP/2 ยังบีบอัดส่วนหัวผ่าน HPACK ซึ่งลดปริมาณข้อมูลที่ส่ง สำหรับแอปพลิเคชันมือถือ HTTP/2 มีประโยชน์เป็นพิเศษ: การเชื่อมต่อเดียวแทนที่หลายรายการ ลดเวลาการจับมือ TLS และการใช้แบตเตอรี่

HTTP/3 (2022) เป็นเวอร์ชันล่าสุดของโปรโตคอล ซึ่งใช้ QUIC (Quick UDP Internet Connections) แทน TCP QUIC ทำงานบน UDP ขจัดปัญหา head-of-line blocking ในระดับโปรโตคอลขนส่ง HTTP/3 ลดเวลาในการสร้างการเชื่อมต่อเหลือ 0 รอบในกรณีที่ดีที่สุด (ในการเชื่อมต่อซ้ำ) และ 1 รอบในการเชื่อมต่อครั้งแรก ซึ่งเร็วกว่า HTTP/2 ที่มี 2-3 รอบอย่างมาก สำหรับอุปกรณ์มือถือ HTTP/3 มีประสิทธิภาพเป็นพิเศษเมื่อสลับระหว่าง Wi-Fi และเครือข่ายมือถือ — การเชื่อมต่อไม่ขาดเนื่องจาก QUIC ใช้ตัวระบุการเชื่อมต่อแทนที่อยู่ IP

HTTPS ในการพัฒนาแอปมือถือ

การใช้ HTTPS ในแอปพลิเคชันมือถือไม่ใช่คำแนะนำแต่เป็นข้อกำหนดบังคับ เริ่มตั้งแต่ Android 9 (API 28) และ iOS 9 (ATS — App Transport Security) คำขอเครือข่ายทั้งหมดต้องใช้ HTTPS โดยค่าเริ่มต้น คำขอ HTTP ถูกบล็อกโดยระบบ และการอนุญาตต้องมีข้อยกเว้นที่ชัดเจนในการกำหนดค่าแอปพลิเคชัน Google Play Store และ App Store ปฏิเสธแอปพลิเคชันที่ส่งข้อมูลที่ละเอียดอ่อนผ่าน HTTP รวมถึงรหัสผ่าน โทเคน และข้อมูลส่วนบุคคล

การกำหนดค่า HTTPS ในแอปพลิเคชัน Android ประกอบด้วย:

<!-- AndroidManifest.xml — สิทธิ์คำขอเครือข่าย -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — การกำหนดค่า HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

บน iOS การกำหนดค่าที่คล้ายกันทำผ่าน Info.plist ด้วยคีย์ NSAppTransportSecurity สำหรับการดีบักทราฟฟิก HTTPS ในแอปพลิเคชันมือถือ จะใช้เครื่องมือพร็อกซี: Charles Proxy, Proxyman หรือ mitmproxy ซึ่งต้องติดตั้งใบรับรอง SSL ที่เชื่อถือได้บนอุปกรณ์ ในบิลด์โปรดักชัน ต้องปิดใช้งานความสามารถในการดีบักและตรวจสอบว่าการปักหมุดใบรับรองได้รับการกำหนดค่าอย่างถูกต้อง การใช้ OkHttp บน Android กับ CertificatePinner หรือ TrustManager บน iOS กับ SecTrustEvaluate เป็นแนวทางมาตรฐานสำหรับการปักหมุด

ด้านความปลอดภัยที่สำคัญของ HTTPS ในการพัฒนาแอปมือถือคือ การปักหมุด SSL (SSL Pinning) หากไม่มีการปักหมุด แอปพลิเคชันจะเชื่อถือใบรับรองใดๆ ที่ลงนามโดย CA ที่รู้จัก หาก CA ถูกบุกรุก ผู้โจมตีสามารถดักจับทราฟฟิกของแอปพลิเคชันได้ การปักหมุดผูกแอปพลิเคชันกับใบรับรองเซิร์ฟเวอร์หรือคีย์สาธารณะเฉพาะ เมื่อใบรับรองเซิร์ฟเวอร์เปลี่ยนไป ต้องออกอัปเดตแอปพลิเคชัน ดังนั้นการปักหมุดจึงวางแผนด้วยการเผื่อ — ผูกกับใบรับรอง CA ระดับบนหรือใช้คีย์สำรองหลายรายการ