HTTP/HTTPS: apa itu, protokol transmisi data dan enkripsi TLS

Apa itu HTTP dan HTTPS?

HTTP (HyperText Transfer Protocol) — adalah protokol lapisan aplikasi model OSI, dirancang untuk mentransmisikan dokumen hiperteks dan data lainnya di World Wide Web. Dikembangkan oleh Tim Berners-Lee pada tahun 1989, HTTP telah melalui beberapa versi: dari HTTP/0.9 (hanya permintaan GET dan tanggapan HTML) hingga HTTP/2 dan HTTP/3 modern. Protokol bekerja dengan skema permintaan-tanggapan: klien mengirim permintaan ke server, server memprosesnya dan mengembalikan tanggapan.

HTTPS (HTTP Secure) — adalah perpanjangan dari protokol HTTP yang menambahkan lapisan enkripsi melalui TLS (Transport Layer Security). HTTPS bukan protokol terpisah — ini adalah kombinasi HTTP dan TLS. Data yang dikirim melalui HTTPS dienkripsi di sisi klien dan didekripsi di server, sehingga tidak dapat diakses untuk penyadapan dan pemalsuan. HTTPS juga menyediakan autentikasi server melalui sertifikat SSL/TLS, menjamin bahwa klien terhubung ke server asli, bukan ke penyerang.

Perbedaan utama antara HTTP dan HTTPS adalah keamanan. HTTP mengirim data dalam bentuk terbuka: setiap simpul jaringan antara klien dan server dapat membaca isi permintaan atau tanggapan. HTTPS mengenkripsi seluruh konten, termasuk URL, header, dan badan permintaan, hanya menyisakan alamat IP server dan port koneksi yang terlihat. Untuk aplikasi mobile yang bekerja melalui jaringan Wi-Fi publik, HTTPS adalah persyaratan keamanan wajib.

Bagaimana HTTP bekerja

HTTP — adalah protokol tanpa keadaan (stateless) yang bekerja di atas TCP/IP. Klien membuat koneksi TCP dengan server (biasanya pada port 80 untuk HTTP atau 443 untuk HTTPS), mengirim permintaan HTTP, menerima tanggapan HTTP, dan menutup koneksi (dalam HTTP/1.1 koneksi dapat digunakan kembali). Setiap interaksi antara klien dan server terdiri dari permintaan dan tanggapan. Tanpa keadaan berarti server tidak menyimpan informasi tentang permintaan sebelumnya dari klien — setiap permintaan diproses secara independen.

Proses interaksi HTTP mencakup langkah-langkah berikut:

• Resolusi DNS — browser atau klien mengonversi nama domain menjadi alamat IP melalui DNS
• Jabat tangan TCP — koneksi TCP dibuat melalui jabat tangan tiga langkah (SYN, SYN-ACK, ACK)
• Jabat tangan TLS — untuk HTTPS, koneksi terenkripsi tambahan dibuat (pertukaran sertifikat dan kunci)
• Permintaan HTTP — klien mengirim metode, URL, header, dan opsional badan permintaan
• Tanggapan HTTP — server mengembalikan kode status, header, dan badan tanggapan

Karakteristik penting HTTP adalah idempotensi metode. GET, HEAD, PUT, DELETE, dan OPTIONS bersifat idempoten: eksekusi berulang dari permintaan yang sama tidak mengubah keadaan server setelah eksekusi pertama. POST, PATCH, dan CONNECT tidak idempoten — setiap panggilan dapat membuat sumber daya baru atau mengubah keadaan. Untuk pengembangan mobile, memahami idempotensi sangat penting: saat mengirim ulang permintaan karena kesalahan jaringan, klien harus tahu apakah aman untuk mengulangi permintaan tersebut.

HTTPS dan enkripsi TLS

HTTPS menggunakan protokol kriptografi TLS (Transport Layer Security) untuk melindungi data yang dikirim. TLS — penerus SSL (Secure Sockets Layer), yang dikembangkan oleh perusahaan Netscape pada tahun 1995. Versi SSL 2.0 dan 3.0 dianggap usang dan tidak aman; versi modern TLS 1.2 (dirilis 2008) dan TLS 1.3 (dirilis 2018) digunakan secara luas. TLS 1.3, khususnya, mengurangi waktu pembuatan koneksi dari 2 round-trips menjadi 1, yang secara signifikan mempercepat pemuatan di perangkat mobile.

Proses jabat tangan TLS (handshake) mencakup tahapan berikut:

• Client Hello — klien mengirim daftar versi TLS dan rangkaian sandi yang didukung
• Server Hello — server memilih versi TLS dan rangkaian sandi, mengirim sertifikat SSL/TLS-nya
• Verifikasi sertifikat — klien memverifikasi sertifikat server melalui rantai kepercayaan hingga CA akar
• Pertukaran kunci — klien dan server menghasilkan kunci rahasia bersama (kunci sesi)
• Switch Cipher — kedua belah pihak mengonfirmasi transisi ke koneksi terenkripsi

Verifikasi sertifikat SSL/TLS — tahap kritis untuk keamanan. Klien memeriksa apakah sertifikat: tidak kedaluwarsa, ditandatangani oleh otoritas sertifikasi tepercaya (CA), sesuai dengan domain di URL, dan tidak dicabut (melalui CRL atau OCSP). Dalam aplikasi mobile, disarankan menggunakan Certificate Pinning — pengikatan ke sertifikat tertentu atau kunci publik server. Ini mencegah serangan MITM bahkan jika CA dikompromikan. Namun, pinning memerlukan kehati-hatian: saat sertifikat berubah, aplikasi harus diperbarui terlebih dahulu.

Struktur permintaan dan tanggapan HTTP

Permintaan HTTP terdiri dari tiga bagian: baris awal (request line), header, dan opsional badan (body). Baris awal berisi metode HTTP, URL permintaan, dan versi HTTP. Header mengirimkan meta-informasi: jenis konten, token autentikasi, pengaturan cache. Badan hanya ada dalam metode yang mengirim data (POST, PUT, PATCH) dan tidak ada dalam GET dan DELETE.

Contoh permintaan HTTP ke 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": "Anna",
    "email": "anna@example.com"
}

Tanggapan HTTP memiliki struktur serupa: baris awal dengan versi HTTP dan kode status, header, dan badan. Kode status — angka tiga digit yang menentukan hasil pemrosesan permintaan. Header tanggapan mencakup Content-Type, Content-Length, Cache-Control, Set-Cookie, dan lainnya. Badan tanggapan berisi data yang diminta dalam format yang ditentukan di Content-Type (biasanya JSON untuk API, HTML untuk halaman web, gambar untuk konten media).

Header memainkan peran penting dalam kerja HTTP. Content-Type dan Accept mengelola format data. Authorization mengirim token akses. Cache-Control mengelola caching. Header CORS (Access-Control-Allow-Origin) mengontrol akses dari domain lain di browser. User-Agent mengidentifikasi aplikasi klien. Untuk aplikasi mobile, header manajemen cache sangat penting — mereka mengurangi volume data yang dikirim dan meningkatkan kinerja pada sinyal lemah.

Kode status HTTP

Kode status HTTP dikelompokkan ke dalam lima kelas, ditunjukkan oleh digit pertama: 1xx (informatif), 2xx (sukses), 3xx (pengalihan), 4xx (kesalahan klien), 5xx (kesalahan server). Memahami kode ini diperlukan untuk pemrosesan tanggapan yang benar dalam aplikasi mobile: 2xx berarti sukses dan data dapat ditampilkan, 4xx menunjukkan masalah dalam permintaan (harus menampilkan kesalahan kepada pengguna), 5xx — masalah di server (permintaan harus diulang nanti).

Untuk aplikasi mobile, penanganan kode 401 Unauthorized sangat penting. Setelah menerima kode ini, klien harus mencoba memperbarui token akses melalui Refresh Token dan mengulangi permintaan asli. Jika pembaruan token juga mengembalikan 401, pengguna harus diarahkan ke layar masuk. Logika ini biasanya diimplementasikan dalam Interceptor (OkHttp) atau di lapisan middleware klien jaringan.

HTTP/1.1, HTTP/2 dan HTTP/3

HTTP/1.1, diterbitkan pada tahun 1999, masih menjadi versi protokol yang banyak digunakan. Kekurangan utamanya — head-of-line blocking: permintaan ke server yang sama dieksekusi secara berurutan, setiap permintaan berikutnya menunggu yang sebelumnya selesai. Untuk mengatasi keterbatasan ini, browser membuka 6–8 koneksi TCP paralel ke domain yang sama, yang meningkatkan beban server dan konsumsi memori. HTTP/1.1 juga mengirim header dalam bentuk tidak terenkripsi dan tidak mendukung server push.

HTTP/2 (2015) memecahkan masalah pemblokiran melalui multipleksing — banyak aliran data dikirim melalui satu koneksi TCP secara bersamaan. Server dapat mengirim sumber daya ke klien sebelum klien memintanya (server push). HTTP/2 juga mengompresi header melalui HPACK, yang mengurangi volume data yang dikirim. Untuk aplikasi mobile, HTTP/2 sangat berguna: satu koneksi menggantikan beberapa, mengurangi waktu jabat tangan TLS dan konsumsi baterai.

HTTP/3 (2022) — versi protokol terbaru, yang menggunakan QUIC (Quick UDP Internet Connections) sebagai pengganti TCP. QUIC bekerja di atas UDP, menghilangkan masalah head-of-line blocking di tingkat protokol transport. HTTP/3 mengurangi waktu pembuatan koneksi menjadi 0 round-trips dalam kasus terbaik (pada koneksi berulang) dan 1 round-trip pada koneksi pertama, yang jauh lebih cepat dari HTTP/2 dengan 2–3 round-trips. Untuk perangkat mobile, HTTP/3 sangat efisien saat beralih antara Wi-Fi dan jaringan seluler — koneksi tidak terputus karena QUIC menggunakan ID koneksi, bukan alamat IP.

HTTPS dalam pengembangan mobile

Penggunaan HTTPS dalam aplikasi mobile — bukan rekomendasi, melainkan persyaratan wajib. Mulai dari Android 9 (API 28) dan iOS 9 (ATS — App Transport Security), semua permintaan jaringan secara default harus menggunakan HTTPS. Permintaan HTTP diblokir oleh sistem, dan untuk mengizinkannya diperlukan pengecualian eksplisit dalam konfigurasi aplikasi. Google Play Store dan App Store menolak aplikasi yang mengirim data rahasia melalui HTTP, termasuk kata sandi, token, dan data pribadi.

Konfigurasi HTTPS dalam aplikasi mobile di Android mencakup:

<!-- AndroidManifest.xml — izin untuk permintaan jaringan -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — konfigurasi 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>

Di iOS, konfigurasi serupa dilakukan melalui Info.plist dengan kunci NSAppTransportSecurity. Untuk debug lalu lintas HTTPS di aplikasi mobile, digunakan alat proksi: Charles Proxy, Proxyman, atau mitmproxy. Mereka memerlukan instalasi sertifikat SSL tepercaya di perangkat. Dalam build produksi, kemampuan debug harus dinonaktifkan dan Certificate Pinning harus dikonfigurasi dengan benar. Penggunaan OkHttp di Android dengan CertificatePinner atau TrustManager di iOS dengan SecTrustEvaluate — pendekatan standar untuk implementasi pinning.

Aspek penting keamanan HTTPS dalam pengembangan mobile — SSL Pinning. Tanpa pinning, aplikasi mempercayai sertifikat apa pun yang ditandatangani oleh CA yang dikenal. Jika CA dikompromikan, penyerang dapat menyadap lalu lintas aplikasi. Pinning mengikat aplikasi ke sertifikat tertentu atau kunci publik server. Saat sertifikat di server berubah, pembaruan aplikasi harus dirilis, oleh karena itu pinning direncanakan dengan cadangan — diikat ke sertifikat CA tingkat atas atau menggunakan beberapa kunci cadangan.