Korelasikan waktu koneksi aplikasi, state socket, counter TCP, dan packet capture terbatas untuk membedakan timeout handshake, reset, retransmission, serta respons aplikasi yang lambat.
Mengumpulkan bukti berurutan pada host Linux dan menentukan apakah gangguan intermittent paling mungkin terjadi sebelum handshake TCP, selama transfer, atau setelah request mencapai aplikasi.
PersiapanHost Linux dengan curl, iproute2/ss, dan tcpdump; izin sudo hanya bila diperlukan untuk packet capture. Gunakan endpoint milik sendiri atau yang Anda diizinkan periksa, batasi durasi capture, dan jangan merekam payload sensitif.
Gangguan TCP intermittent sering muncul sebagai request yang kadang cepat, kadang timeout, atau tiba-tiba mendapat connection reset. Satu ping sukses atau satu curl gagal belum cukup untuk menunjuk jaringan, firewall, server, atau aplikasi. Panduan ini membangun timeline dari gejala aplikasi ke bukti socket dan paket, lalu memakai pola gejala → bukti → interpretasi → tindakan berikutnya.
Tentukan satu hostname, satu port, rentang waktu singkat, dan request yang aman. Jangan menguji endpoint transaksi dengan method yang mengubah data. Ganti example.com dan alamat TEST-NET dengan target yang memang Anda kelola. Packet capture dapat memuat IP, hostname, ukuran traffic, dan payload yang tidak terenkripsi; simpan seperlunya, batasi akses, dan hapus sesuai kebijakan organisasi.
Tujuan langkah ini adalah membuat semua bukti dapat dikorelasikan. Catat waktu UTC, hostname, IP hasil resolusi, dan route yang dipilih kernel. Pada hasil normal, hostname menghasilkan alamat yang diharapkan dan ip route get menunjukkan interface/source yang sesuai. Jika alamat berubah antarpercobaan, pisahkan hasil per-IP; jika route salah, selesaikan routing sebelum menafsirkan TCP.
date -u +'%Y-%m-%dT%H:%M:%SZ'
getent ahosts example.com
ip route get 192.0.2.10Contoh berikut hanya ilustrasi. Field via, dev, dan src menunjukkan keputusan route lokal, bukan bukti bahwa paket telah mencapai server.
192.0.2.10 via 192.0.2.1 dev eth0 src 192.0.2.20 uid 1000Tujuannya memisahkan DNS, TCP connect, TLS, first byte, dan total time. --connect-timeout membatasi fase koneksi, sedangkan --max-time membatasi keseluruhan operasi. Perhatikan exit code, http_code, remote_ip, time_namelookup, time_connect, time_appconnect, time_starttransfer, dan time_total. time_connect yang melonjak mengarah ke handshake/path; time_appconnect yang melonjak setelah connect mengarah ke TLS; time_starttransfer yang tinggi setelah TLS mengarah ke edge/origin/aplikasi.
curl --silent --show-error --output /dev/null \
--connect-timeout 5 --max-time 20 \
--write-out 'code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/Baris pertama menggambarkan request selesai. Baris kedua menggambarkan koneksi yang tidak selesai dalam batas waktu; nilai nol pada fase sesudah connect berarti fase tersebut belum tercapai, bukan durasi nyata nol.
code=200 remote=192.0.2.10 dns=0.012 connect=0.041 tls=0.108 first_byte=0.231 total=0.244
code=000 remote=192.0.2.10 dns=0.010 connect=0.000 tls=0.000 first_byte=0.000 total=5.002Gangguan intermittent memerlukan lebih dari satu observasi, tetapi jangan membuat load test terselubung. Jalankan lima request dengan jeda tiga detik ke endpoint read-only. Normal berarti remote IP dan timing relatif konsisten. Jika hanya satu IP yang gagal, fokus ke node/path tersebut; jika semua IP menunjukkan lonjakan fase yang sama, lanjutkan ke bukti socket dan packet capture. Hentikan bila muncul 429, challenge, atau dampak pada layanan.
for i in 1 2 3 4 5; do
date -u +'%H:%M:%S'
curl --silent --show-error --output /dev/null --connect-timeout 5 --max-time 20 \
--write-out 'code=%{http_code} remote=%{remote_ip} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/
sleep 3
doneTujuan langkah ini adalah melihat apakah koneksi berhenti di SYN-SENT, sudah ESTAB, menumpuk di CLOSE-WAIT, atau berakhir normal. Jalankan saat gejala terjadi. Recv-Q/Send-Q yang terus membesar dapat menunjukkan aplikasi tidak membaca/menulis cukup cepat, tetapi satu snapshot tidak membuktikan penyebab. SYN-SENT berulang tanpa ESTAB mengarahkan pemeriksaan ke jalur/SYN-ACK; ESTAB dengan request lambat mengarahkan ke TLS, server, atau aplikasi.
ss -tanp | grep -E 'State|:443'
ss -sGunakan ss -ti saat koneksi masih ada. Field yang tersedia bergantung kernel, tetapi dapat mencakup rtt, rto, retrans, cwnd, bytes_acked, dan delivery_rate. RTT tinggi tidak otomatis berarti packet loss; retrans yang bertambah selama gejala adalah bukti lebih kuat bahwa segment perlu dikirim ulang. Jika koneksi keburu selesai, ulangi request berukuran/durasi aman atau ambil snapshot cepat—jangan memperpanjang transaksi produksi hanya demi observasi.
ss -tin dst 192.0.2.10Contoh ini hanya menunjukkan bentuk field. Nilai retrans:2/5 perlu dibaca bersama timeline dan capture: counter kumulatif tanpa baseline tidak membuktikan lima kehilangan baru pada satu request.
ESTAB 0 0 192.0.2.20:49152 192.0.2.10:443
cubic wscale:7,7 rto:248 rtt:42.1/8.4 cwnd:10 retrans:2/5 bytes_acked:18420Tujuannya menemukan error/drop lokal yang berubah selama jendela uji. Ambil baseline dengan ip -s link, jalankan sampel kecil, lalu bandingkan lagi. RX/TX errors atau dropped yang meningkat pada interface target patut ditelusuri ke driver, NIC, queue, virtual switch, atau host load. Counter tetap tidak berubah tidak membuktikan seluruh path bersih karena loss dapat terjadi di perangkat lain.
ip -s link show dev eth0Sebelum menjalankan tcpdump, resolve target lalu filter satu IP dan satu port. Gunakan -n agar tidak memicu lookup tambahan, -i pada interface yang benar, -c untuk membatasi jumlah paket, dan -s 96 bila header TCP saja cukup. Capture pada any memudahkan discovery tetapi dapat menampilkan paket duplikat pada beberapa topologi; untuk bukti final pilih interface dari ip route get.
sudo tcpdump -ni eth0 -s 96 -c 100 \
'host 192.0.2.10 and tcp port 443'Mulai capture terbatas, lalu jalankan tepat satu curl pada terminal lain dan catat timestamp. Handshake normal terlihat sebagai SYN client, SYN-ACK server, lalu ACK client sebelum data TLS. Jika SYN diulang tanpa SYN-ACK, bukti menunjukkan balasan tidak terlihat di titik capture—kemungkinan termasuk filtering, path asymmetry, server/listener tidak menjawab, atau capture di interface yang salah. Jika bahkan SYN tidak terlihat, periksa target IP, route, proxy, namespace/container, dan interface capture.
Flag [S] adalah SYN, [S.] adalah SYN-ACK, dan [.] adalah ACK. Nomor IP/port berikut menggunakan TEST-NET dan bukan capture nyata.
03:12:01.100 IP 192.0.2.20.49152 > 192.0.2.10.443: Flags [S]
03:12:01.142 IP 192.0.2.10.443 > 192.0.2.20.49152: Flags [S.]
03:12:01.143 IP 192.0.2.20.49152 > 192.0.2.10.443: Flags [.]Timeout tanpa respons biasanya memperlihatkan pengiriman ulang SYN atau segment tanpa ACK yang terlihat. RST menunjukkan salah satu endpoint/perangkat secara eksplisit mereset koneksi; cocokkan arah paket agar tahu sisi yang terlihat mengirim RST, tetapi jangan langsung menyimpulkan proses tertentu tanpa log host. FIN/ACK adalah penutupan normal pada level TCP, walau aplikasi masih dapat menutup terlalu cepat. Setelah handshake normal tetapi curl lambat, fokus pada TLS, first byte, queue, dan log aplikasi.
tcpdump menampilkan sequence/ack dan timestamp, tetapi tidak selalu memberi label retransmission seperti analyzer GUI. Segment dengan sequence range yang sama muncul kembali tanpa ACK yang maju adalah indikasi retransmission. Capture point dapat menipu: offload NIC, packet duplication, asymmetric path, atau packet loss di host capture dapat menghasilkan asumsi salah. Konfirmasi dengan ss -ti, counter sebelum/sesudah, dan bila diizinkan capture pada kedua endpoint.
Gunakan pcap hanya jika analisis lanjutan memang perlu. Filter ketat dan batasi ukuran/waktu. HTTPS menyembunyikan payload aplikasi, tetapi metadata, alamat, SNI pada beberapa konfigurasi, timing, dan ukuran tetap sensitif. Jangan mengunggah pcap mentah ke tiket publik. Contoh berikut menyimpan maksimal 1000 paket untuk satu target; sesuaikan kebijakan retention dan permission lokal.
sudo tcpdump -ni eth0 -s 96 -c 1000 \
-w tcp-intermittent.pcap \
'host 192.0.2.10 and tcp port 443'Jika curl gagal sebelum time_connect dan capture menunjukkan SYN berulang tanpa SYN-ACK, periksa firewall/path/listener serta bandingkan capture sisi server. Jika handshake lengkap tetapi time_appconnect tinggi, periksa TLS negotiation, CPU, certificate path, dan proxy. Jika TLS cepat tetapi time_starttransfer tinggi, korelasikan request ID dan log edge/origin/aplikasi. Jika RST terlihat, identifikasi arah RST lalu periksa log endpoint/perangkat pada timestamp yang sama. Jika retrans dan counter lokal meningkat, telusuri interface/driver/host sebelum menyalahkan aplikasi.
Ulangi command curl yang sama, jumlah sampel yang sama, dan window waktu sebanding. Bandingkan remote IP, exit code, fase timing, state ss, retrans, serta counter interface. Perbaikan dianggap terverifikasi bila gejala pengguna hilang dan bukti yang sebelumnya abnormal juga membaik. Jika hanya timing membaik satu kali, lanjutkan observasi; gangguan intermittent membutuhkan konsistensi, bukan satu hasil hijau.
Jangan menyimpulkan packet loss dari ping saja atau dari satu baris tcpdump. Jangan menangkap semua traffic tanpa filter. Jangan memakai curl -k untuk menutupi error TLS. Jangan menganggap RST selalu dikirim aplikasi tujuan; perangkat perantara juga dapat mereset koneksi. Jangan membandingkan dua request yang menuju IP berbeda tanpa mencatat remote_ip. Jangan mengubah sysctl TCP, MTU, firewall, dan aplikasi sekaligus karena korelasi penyebab akan hilang.
Pastikan timestamp UTC tercatat; hostname, resolved IP, remote_ip, route, dan interface konsisten; curl memisahkan connect/TLS/first byte/total; sampel dibatasi; ss diambil saat gejala; counter interface dibandingkan sebelum/sesudah; tcpdump difilter dan dibatasi; arah SYN/SYN-ACK/RST/FIN dibaca; data sensitif dilindungi; serta tindakan berikutnya ditentukan oleh fase yang benar-benar gagal.
Diagnosis TCP intermittent yang dapat dipertanggungjawabkan membutuhkan korelasi lintas layer. curl menunjukkan fase yang lambat, ss menunjukkan keadaan socket dan counter TCP, ip menunjukkan kondisi interface, sedangkan tcpdump membuktikan paket yang terlihat pada satu titik. Tidak satu pun alat cukup sendirian; timeline bersama adalah dasar keputusan yang aman.