Apache Tomcat Adalah: Fungsi, Cara Kerja & Versinya

Sebuah web server pada dasarnya bekerja seperti petugas arsip. Ia menerima permintaan dari browser, mencari berkas yang diminta, lalu mengirimkannya kembali apa adanya. Selama yang diminta berupa halaman HTML, gambar, atau berkas CSS yang isinya sudah tetap, cara kerja itu memadai.

Persoalan muncul ketika halaman yang diminta belum ada wujudnya. Saldo rekening, keranjang belanja, atau dasbor yang isinya berbeda untuk setiap pengguna tidak mungkin disiapkan lebih dulu sebagai berkas. Halaman semacam itu harus disusun saat itu juga, dan yang menyusunnya adalah program — bukan petugas arsip.

Di ekosistem Java, program yang menjalankan tugas tersebut paling sering adalah Apache Tomcat. Apache Tomcat adalah perangkat lunak servlet container — program yang menjalankan kode Java untuk menyusun jawaban atas setiap permintaan yang masuk. Ia sudah memegang peran itu sejak 1999.

Apache Tomcat Adalah Servlet Container untuk Aplikasi Java

Definisi resminya bisa dibaca langsung di situs proyeknya: Tomcat adalah implementasi open source dari spesifikasi Jakarta Servlet, Jakarta Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Annotations, dan Jakarta Authentication. Kalimat itu padat, jadi mari kita bongkar bagian yang paling menentukan.

Servlet adalah kelas Java yang menerima objek permintaan dan mengembalikan objek respons. Anda menulis logikanya, tetapi tidak menulis kode untuk membuka soket jaringan, membaca header HTTP, atau mengatur antrian koneksi. Semua itu urusan container. Servlet container adalah program yang menyediakan lingkungan hidup bagi servlet: memuatnya ke memori, memanggilnya saat ada permintaan yang cocok, lalu mematikannya saat aplikasi dihentikan.

Fungsi Apache Tomcat, kalau diringkas menjadi tiga, adalah menerima koneksi HTTP, memetakan setiap permintaan ke kelas Java yang tepat, lalu mengelola siklus hidup aplikasi web yang berjalan di dalamnya. Ia juga mengurusi sesi pengguna, kumpulan koneksi database, dan kompilasi berkas JSP.

Ada satu hal yang perlu diluruskan sejak awal. Daftar spesifikasi tadi hanya sebagian dari Jakarta EE. Tomcat tidak menyertakan EJB, JPA, CDI, JTA, maupun JMS. Menyebut Tomcat sebagai application server Jakarta EE penuh adalah kekeliruan yang sering muncul di dokumen teknis, dan kekeliruan itu berujung pada ekspektasi yang salah saat merancang arsitektur aplikasi.

Anda tetap bisa memakai JPA atau CDI di atas Tomcat, tetapi library-nya harus Anda bawa sendiri ke dalam aplikasi. Yang tidak tersedia adalah implementasi bawaan di tingkat server.

Kenapa Kata Apache Harus Ikut Disebut

Di Indonesia, kata "tomcat" jarang membangkitkan asosiasi ke perangkat lunak. Ada dua hal lain yang lebih dulu memiliki nama itu di kepala orang.

Yang pertama adalah serangga. Kumbang Paederus fuscipes dikenal luas sebagai tomcat setelah wabah dermatitis di Surabaya pada Maret 2012, sampai Kementerian Kesehatan menerbitkan panduan pencegahannya. Racun paederin yang dikeluarkannya saat terpencet membuat kulit melepuh dan gatal.

Yang kedua adalah pesawat tempur. Grumman F-14 Tomcat adalah jet tempur Angkatan Laut Amerika Serikat yang populer lewat film dan permainan video.

Kebingungan tidak berhenti di sana, karena kata "Apache" pun menempel pada beberapa hal sekaligus: suku asli Amerika, helikopter serang AH-64 Apache, dan Apache Software Foundation yang menaungi ratusan proyek perangkat lunak. Perangkat lunak yang kita bahas ini berada di kotak terakhir.

Karena itu, biasakan menyebut "Apache Tomcat" secara utuh di dokumentasi dan tiket. Menyingkatnya menjadi "Tomcat" aman di percakapan antar-developer yang konteksnya sudah jelas, tetapi berisiko disalahpahami begitu dokumen tersebut dibaca orang di luar tim teknis.

Tomcat dan Apache HTTP Server Mengerjakan Hal Berbeda

Keduanya bernaung di yayasan yang sama, tetapi keduanya proyek terpisah dengan basis kode, tim, dan siklus rilis yang berbeda. Apache HTTP Server bukan versi lain dari Tomcat, begitu pula sebaliknya. Nomor versi keduanya bahkan berjalan di jalur yang sama sekali berlainan — Apache HTTP Server ada di seri 2.4, sementara Tomcat sudah di seri 11.

Perbedaan tugasnya lebih mudah dilihat dari apa yang mereka lakukan terhadap sebuah permintaan:

Susunan yang paling lazim di server produksi justru memakai keduanya sekaligus. Apache HTTP Server atau Nginx berdiri paling depan menghadap internet, menangani sertifikat HTTPS dan berkas statis, lalu meneruskan sisanya ke Tomcat di belakang. Masing-masing mengerjakan bagian yang paling dikuasainya, dan Tomcat tidak perlu diekspos langsung ke internet.

Cara Kerja Tomcat: Dari Permintaan HTTP sampai Servlet

Perjalanan sebuah permintaan di dalam Tomcat melewati beberapa tangan. Bagian yang menerima koneksi jaringan disebut Connector. Dokumentasi resmi menyebutnya sebagai komponen yang "menangani komunikasi dengan klien". Nama kode subsistem ini adalah Coyote, terlihat jelas dari nama kelasnya di konfigurasi: org.apache.coyote.http11.Http11NioProtocol. Tugasnya membaca byte mentah dari soket dan mengubahnya menjadi objek permintaan yang dimengerti Java.

Objek tersebut lalu diserahkan ke Engine, yang dokumentasinya gambarkan sebagai "pipeline pemrosesan permintaan". Engine memilih Host berdasarkan nama domain di header, dan Host memilih Context berdasarkan path URL. Satu Context sama dengan satu aplikasi web. Barulah di dalam Context, servlet yang pemetaannya cocok dipanggil.

Seluruh rangkaian container ini — Engine, Host, Context, sampai pemanggilan servlet — berada di bawah subsistem bernama Catalina. Nama itu bukan sekadar julukan internal; Anda menemuinya lewat variabel lingkungan CATALINA_HOME dan CATALINA_BASE, serta di seluruh nama paket org.apache.catalina.

Alur permintaan Tomcat: Connector Coyote mengubah HTTP jadi objek Java, Engine dan Host memilih Context, servlet menjawab.

Satu subsistem lagi bekerja di jalur yang sedikit berbeda: Jasper, mesin JSP. Berkas .jsp yang Anda tulis sebenarnya tidak dijalankan sebagai template. Jasper menerjemahkannya lebih dulu menjadi kode servlet Java, mengompilasinya, baru menjalankan hasilnya. Inilah sebabnya permintaan pertama ke sebuah halaman JSP terasa lebih lambat dibanding permintaan berikutnya.

Anatomi Tomcat: Dari server.xml sampai Context

Komponen yang tadi disebut bukan konsep abstrak. Susunan sebuah Apache Tomcat server tertulis sebagai elemen XML bersarang di dalam conf/server.xml, persis mengikuti hierarki berikut.

Hierarki Tomcat: Server memuat Service, Service mengikat Connector dan Engine, Engine memuat Host, Host memuat Context.

Di sisi disk, isi folder instalasi Tomcat terbagi rapi menurut fungsinya. Tujuh folder berikut yang paling sering Anda sentuh:

1. /bin: skrip untuk menyalakan dan mematikan Tomcat. Berkas .sh untuk Unix dan .bat untuk Windows berisi fungsi yang setara.
2. /conf: seluruh berkas konfigurasi. Yang terpenting server.xml, ditemani tomcat-users.xml untuk akun dan web.xml untuk pengaturan bawaan aplikasi.
3. /lib: library yang dibagikan ke semua aplikasi di dalam server.
4. /logs: lokasi bawaan berkas log, termasuk catalina.out yang biasanya jadi tujuan pertama saat menelusuri masalah.
5. /webapps: tempat aplikasi Anda diletakkan. Menaruh berkas .war di sini membuatnya ter-deploy otomatis.
6. /work: direktori kerja sementara, termasuk tempat Jasper menyimpan hasil kompilasi JSP.
7. /temp: berkas sementara milik JVM.

Soal port, berkas server.xml bawaan mengaktifkan dua dan menyiapkan dua lainnya dalam keadaan dikomentari:

Inilah alasan alamat localhost:8080 begitu identik dengan Tomcat. Kalau Anda ingin memahami kenapa alamat tersebut hanya bisa diakses dari komputer sendiri, penjelasannya ada di artikel tentang localhost.

Beberapa angka bawaan lain berguna diketahui sebelum menyetel: maxThreads bernilai 200, artinya Tomcat melayani maksimal 200 permintaan bersamaan sebelum sisanya mengantre. connectionTimeout di server.xml bawaan diisi 20000 milidetik, lebih ketat daripada nilai bawaan atributnya sendiri yang 60000 milidetik. Sementara maxParameterCount dibatasi 1000 parameter per permintaan sebagai pengaman dari serangan yang membanjiri server dengan parameter.

Peta Versi Tomcat dan Batas Dukungannya

Mengetahui versi mana yang masih didukung sama pentingnya dengan memahami cara kerjanya. Tabel berikut menyusun tiga cabang yang masih hidup beserta cabang yang sudah berhenti didukung.

Kolom Java di atas adalah batas bawah, bukan batas atas. Dokumentasi resmi menyatakan setiap versi Tomcat didukung untuk semua rilis Java stabil yang memenuhi syarat minimum tersebut, sehingga Tomcat 9 tetap sah dijalankan di atas Java 17 maupun Java 21. Yang tidak berlaku adalah arah sebaliknya: Tomcat 11 menolak menyala di Java 11.

Angka rilis di atas berlaku per Juli 2026 dan akan terus bertambah, tetapi kolom yang benar-benar perlu Anda perhatikan adalah Namespace.

Di Tomcat 10, seluruh paket spesifikasi berpindah dari javax.* ke jakarta.*. Penyebabnya adalah penyerahan Java EE ke Eclipse Foundation, yang tidak memperoleh hak memakai merek dagang javax. Akibatnya bersifat memutus: aplikasi yang berjalan mulus di Tomcat 9 tidak akan berjalan di Tomcat 10 ke atas tanpa perubahan kode. Setiap import javax.servlet.http.HttpServlet harus menjadi import jakarta.servlet.http.HttpServlet.

Untuk aplikasi lama yang kode sumbernya sudah tidak dapat diubah, tersedia Apache Tomcat Migration Tool for Jakarta EE (versi 1.0.12) yang mengonversi berkas .war secara otomatis dengan menulis ulang nama paket di dalamnya.

Aplikasi javax.servlet jalan di Tomcat 9; untuk Tomcat 10.1 dan 11 harus diubah ke jakarta.servlet dulu.

Rekomendasi konkretnya begini. Kalau Anda memulai proyek baru, langsung pakai Tomcat 11 dengan Java 17 ke atas. Kalau Anda masih di Tomcat 9, dukungannya akan berakhir paling cepat 31 Maret 2027 — jadwalkan migrasi mulai sekarang, karena mengubah namespace pada aplikasi besar bukan pekerjaan satu sore. Kalau Anda masih di 8.5 atau lebih lama, server Anda sudah lebih dari dua tahun tidak menerima perbaikan keamanan apa pun.

Nama Tomcat yang Muncul di Halaman Error

Sebagian pembaca sampai di topik ini bukan karena penasaran pada teknologinya, melainkan karena melihat tulisan seperti ini di layar:

HTTP Status 404 – Not Found
...
Apache Tomcat/8.5.63

Baris terakhir itu bukan pesan kesalahan, melainkan tanda tangan server. Ia dicetak oleh komponen bernama ErrorReportValve yang secara bawaan menyalakan atribut showServerInfo, sehingga setiap halaman error yang tidak diganti oleh aplikasi ikut memuat versi lengkapnya.

Ada tiga hal yang bisa Anda baca dari satu baris tersebut. Pertama, aplikasi di balik alamat itu berbasis Java. Kedua, ada Tomcat yang melayaninya secara langsung, bukan disembunyikan di belakang proxy. Ketiga — dan ini yang paling penting — nomor versinya terbuka untuk siapa pun, termasuk pemindai otomatis yang mencocokkan versi dengan daftar kerentanan yang diketahui.

Ambil contoh 8.5.63 di atas. Seluruh cabang 8.5.x berhenti didukung pada 31 Maret 2024, sehingga server tersebut sudah lama tidak menerima perbaikan keamanan. Menampilkan versinya ke publik berarti memberi tahu penyerang kerentanan mana yang layak dicoba.

Untuk menutupnya, tambahkan atribut berikut pada elemen Host di dalam server.xml:

<Valve className="org.apache.catalina.valves.ErrorReportValve"
       showServerInfo="false"
       showReport="false" />

Atribut showReport="false" sekaligus menyembunyikan stack trace, yaitu rincian jalur kode saat terjadi kesalahan yang seharusnya tidak pernah terlihat pengunjung. Perlu diingat, dokumentasi resmi mencatat bahwa mematikan keduanya membuat halaman error hanya menyisakan kode status HTTP.

Menyembunyikan nomor versi bukan pengganti memperbarui versi. Ini memperlambat pemindai otomatis, bukan menutup celahnya.

Batas Bawaan yang Sering Memicu Error

Sebagian besar kesalahan yang muncul tepat setelah aplikasi berpindah ke Tomcat bukan berasal dari kode aplikasi, melainkan dari batas yang sudah aktif sejak instalasi.

400 Bad Request pada URL yang sebelumnya normal. Tomcat menegakkan RFC 7230 secara ketat. Karakter seperti " < > [ \ ] ^ { | } yang dikirim browser tanpa encoding akan membuat permintaan ditolak, dan dokumentasi resmi mengakui bahwa semua browser besar memang mengirimnya apa adanya. Kedua atribut relaxed di atas ada untuk mengembalikan izin pada karakter tertentu, satu per satu.

413 yang sering bukan berasal dari Tomcat. Kalau ada reverse proxy di depan, batas yang lebih dulu tersentuh biasanya milik proxy itu. Nginx, misalnya, membatasi client_max_body_size di 1 MB secara bawaan dan menjawab 413 sebelum permintaan sempat mencapai Tomcat yang batasnya 2 MiB. Menaikkan maxPostSize saja tidak akan mengubah apa pun selama batas di depan belum ikut dinaikkan.

Unggahan melewati dua batas: nginx menolak di atas 1 MB dengan 413, sisanya baru menemui batas 2 MiB Tomcat.

Satu catatan penting soal maxPostSize: ia bukan batas umum ukuran badan permintaan. Batas ini hanya berlaku saat Tomcat mengurai isi permintaan menjadi parameter, sehingga unggahan yang dibaca aplikasi sebagai aliran data langsung tidak tersentuh olehnya.

Ada pula gejala yang menyesatkan: unggahan besar ditolak, tetapi browser menampilkan koneksi terputus alih-alih halaman error. Penyebabnya maxSwallowSize (bawaan 2 MiB) — Tomcat berhenti membuang sisa data yang masih dikirim klien, dan tanpa itu klien memang jarang sempat melihat responsnya.

Terakhir, java.lang.OutOfMemoryError: GC overhead limit exceeded di catalina.out bukan kode status HTTP dan bukan urusan server.xml. Itu pesan dari JVM yang menghabiskan hampir seluruh waktunya melakukan pengumpulan sampah tanpa berhasil membebaskan memori. Perbaikannya ada di ukuran heap lewat -Xmx, atau di kebocoran memori pada aplikasinya.

Tomcat yang Tidak Pernah Anda Pasang

Ada dua cara memakai Tomcat, dan keduanya menghasilkan pengalaman yang sangat berbeda.

Cara klasik: Anda mengunduh Tomcat, memasangnya sebagai layanan tersendiri, lalu menaruh berkas .war aplikasi ke folder /webapps. Satu instalasi bisa menampung beberapa aplikasi sekaligus, masing-masing sebagai Context terpisah, dan konfigurasinya ada di server.xml.

Cara kedua jauh lebih umum hari ini: Tomcat ditanam langsung di dalam aplikasi (embedded). Spring Boot memakai Tomcat sebagai server tertanam bawaannya. Menambahkan spring-boot-starter-web ke proyek berarti menarik Tomcat ikut serta secara otomatis, dan hasilnya berupa satu berkas .jar yang dijalankan dengan java -jar. Untuk menggantinya dengan Jetty, Anda harus meng-exclude spring-boot-starter-tomcat lebih dulu.

Konsekuensi praktisnya penting. Banyak developer Java sudah menjalankan Tomcat bertahun-tahun tanpa pernah mengunduhnya, dan port 8080 yang mereka lihat saat menjalankan aplikasi Spring Boot memang port bawaan Tomcat. Yang berubah adalah tempat mencari pengaturan: maxThreads dan connectionTimeout tidak lagi diatur di server.xml, melainkan lewat properti aplikasi. Kalau sebuah framework menyembunyikan servernya, dokumentasi framework itu yang jadi rujukan pertama.

Cara ketiga yang kini juga lazim adalah menjalankan Tomcat di dalam container Docker, memakai image resmi maupun image yang Anda susun sendiri.

Kelebihan Tomcat

1. Ringan dan cepat menyala: karena hanya mengimplementasikan sebagian spesifikasi Jakarta EE, jejak memorinya jauh lebih kecil daripada application server penuh. Waktu menyala terhitung detik, bukan menit.
2. Gratis tanpa versi berbayar tersembunyi: dirilis di bawah Apache License 2.0, bebas dipakai untuk keperluan komersial tanpa fitur yang sengaja ditahan.
3. Dokumentasi resmi yang rinci per versi: setiap cabang punya set dokumentasi tersendiri, sehingga nilai bawaan sebuah atribut dapat diperiksa untuk versi yang benar-benar Anda pakai.
4. Ekosistem yang matang: setelah lebih dari dua dekade, hampir setiap pesan kesalahan sudah pernah dibahas dan hampir semua alat pemantauan memiliki dukungan bawaan untuknya.
5. Berjalan di mana saja selama ada JVM: Linux, Windows, macOS, sampai container, tanpa ketergantungan pada sistem operasi tertentu.
6. Beberapa pengaman sudah aktif secara bawaan: aplikasi Manager tertutup total karena tidak ada akun yang diberi role pengelola, konektor AJP dan HTTPS dikirim dalam keadaan dikomentari, dan SecurityListener menolak menyalakan Tomcat sebagai root.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Kelemahan Tomcat sebagian besar merupakan konsekuensi langsung dari keputusan desainnya, sebagian lagi tanggung jawab operasional yang tidak bisa dihindari.

1. Bukan application server Jakarta EE penuh: tidak ada EJB, JPA, CDI, JTA, maupun JMS. Kalau aplikasi Anda membutuhkannya di tingkat server, pilihannya adalah membawa library sendiri atau berpindah ke Apache TomEE — distribusi yang memang menambahkan komponen tersebut di atas Tomcat.
2. Bukan pilihan terbaik untuk berkas statis: Tomcat mampu melayani gambar dan berkas CSS, tetapi web server khusus mengerjakannya lebih efisien. Inilah sebabnya pola reverse proxy di depan Tomcat menjadi kebutuhan, bukan sekadar pilihan gaya.
3. Membutuhkan proses Java yang berjalan permanen: Tomcat memerlukan JVM dengan alokasi memori tersendiri, sesuatu yang tidak disediakan hosting bersama pada umumnya. Menjalankannya menuntut akses administrator, misalnya lewat VPS. Untuk aplikasi Java yang membutuhkan kendali penuh atas JVM dan port yang dipakai, VPS Indonesia menyediakan keleluasaan tersebut.
4. Permukaan serangan yang harus diikuti secara aktif: sepanjang 2025 saja ada tiga kerentanan penting. CVE-2025-24813 memungkinkan eksekusi kode jarak jauh lewat kesetaraan path pada versi 9.0.0.M1 hingga 11.0.2, meski hanya aktif bila servlet bawaan disetel readonly=false yang bukan nilai bawaannya. CVE-2025-48988 dan CVE-2025-61795 membuka celah denial of service lewat unggahan multipart; yang pertama diperbaiki di versi 11.0.8, 10.1.42, dan 9.0.106.
5. Aplikasi Manager berbahaya bila salah tempat: antarmuka ini dapat men-deploy dan menghapus aplikasi dari jarak jauh. Dokumentasi resmi memperingatkan bahwa antarmuka teks dan JMX-nya tidak dapat dilindungi dari serangan CSRF, sehingga aksesnya sebaiknya dibatasi per alamat IP memakai RemoteCIDRValve dan tidak pernah dibuka ke internet.
6. Siklus versi menuntut perhatian berkala: tanggal akhir dukungan datang setiap beberapa tahun, dan perpindahan namespace di Tomcat 10 membuktikan naik versi tidak selalu berarti mengganti berkas. Waktu untuk migrasi perlu direncanakan, bukan disiapkan mendadak.

Pertanyaan yang Sering Muncul

Apache Tomcat untuk apa? Untuk menjalankan aplikasi web berbasis Java. Setiap kali sebuah halaman harus disusun berdasarkan data pengguna, sesi, atau isi database, Tomcat yang memanggil kode Java penyusunnya lalu mengirimkan hasilnya ke browser.

Apakah Apache Tomcat sama dengan Apache HTTP Server? Bukan. Keduanya proyek terpisah dengan basis kode dan seri versi yang berbeda, meski sama-sama bernaung di Apache Software Foundation. Apache HTTP Server mengirim berkas dan mengatur lalu lintas HTTP, sedangkan Tomcat menjalankan kode Java. Keduanya lazim dipasang berdampingan.

Apakah Tomcat punya username dan password bawaan? Tidak ada sama sekali. Dokumentasi resminya menyatakan tidak ada satu pun akun di tomcat-users.xml bawaan yang diberi role pengelola, sehingga aplikasi Manager tertutup total sampai Anda sendiri yang membuka. Kalau sebuah instalasi bisa dimasuki dengan kombinasi seperti admin/admin, seseorang pernah menambahkannya secara manual.

Versi Tomcat mana yang sebaiknya dipakai sekarang? Untuk proyek baru, Tomcat 11 dengan Java 17 ke atas. Untuk aplikasi lama yang masih memakai paket javax.*, Tomcat 9 didukung sampai paling cepat 31 Maret 2027, tetapi migrasi ke jakarta.* sebaiknya sudah dijadwalkan.

Apakah Tomcat bisa menjalankan aplikasi PHP atau Node.js? Tidak. Tomcat menjalankan bytecode Java di dalam JVM. Aplikasi PHP membutuhkan penerjemah PHP di sisi web server, sedangkan aplikasi Node.js menjalankan servernya sendiri. Untuk keperluan seperti itu, Apache HTTP Server atau Nginx yang lebih tepat.

Kesimpulan

Apache Tomcat adalah servlet container open source yang menjalankan aplikasi web berbasis Java: ia menerima permintaan HTTP lewat Connector, memetakannya ke aplikasi yang tepat melalui Engine dan Host, lalu memanggil servlet yang menyusun jawabannya. Ia sengaja dirancang ringan dengan hanya mengimplementasikan sebagian spesifikasi Jakarta EE — keputusan yang sekaligus menjadi kekuatan dan batasnya.

Tomcat tepat dipakai untuk aplikasi Java berbasis servlet atau JSP, termasuk lewat Spring Boot yang sudah menanamkannya secara bawaan. Pertimbangkan Apache TomEE bila Anda membutuhkan komponen Jakarta EE yang lebih lengkap, dan tetap letakkan web server di depannya bila sebagian besar yang dilayani berupa berkas statis. Apa pun pilihannya, periksa dulu versi yang Anda jalankan masih menerima perbaikan keamanan — pemeriksaan sederhana itu jauh lebih menentukan daripada penyetelan mana pun.

Semoga artikel ini membantu.