TCP/IP: Aplikasi Internet

From OnnoWiki
(Redirected from Application Layer)
Jump to navigation Jump to search

Internet pada dasarnya adalah lapisan aplikasi TCP/IP. Bagian ini akan memperlihatkan beberapa aplikasi Internet tersebut.

Aplikasi TCP dan UDP

Ada beberapa protokol aplikasi Internet termasuk:

  • Archie: Sebuah program utility untuk mencari di anonymous FTP yang terdaftar untuk sebuah file atau topik tertentu. Pada hari ini sudah obsolete dengan adanya Web.
  • BGP: Border Gateway Protocol versi 4 (BGP-4) adalah sebuah exterior routing protocol berbasis distance vector yang banyak digunakan untuk sambungan antar ISP atau antara ISP dengan lokasi pelanggan, jika pelanggan mempunyai beberapa sambungan ke Internet sekaligus.
  • DNS: Domain Name System mendefinisikan struktur nama dengan IP address-nya maupun dengan mail dan name server.
  • Finger: Digunakan untuk melihat status sebuah mesin dan / atau penggunanya, berbasis pada RFC 1288 ( http://www.isi.edu/in-notes/rfc1288.txt). Tidak lagi di gunakan karena masalah keamanan jaringan.
  • FTP: File Transfer Protocol yangmemungkinkan pengguna untuk mentransfer file ke computer lain, berdasarkan RFC 959 ( http://www.isi.edu/in-notes/rfc959.txt).
  • Gopher: Sebuah tool / utility yang memungkinkan pengguna untuk mencari data di repository menggunakan interface yang memiliki menu dan hirarki. Pada hari ini tidak lagi digunakan karena digantikan dengan Web.
  • HTTP: Hypertext Transfer Protocol adalah dasar dari pertukaran informasi melalui Web / World Wide Web (WWW). Ada banyak versi dari HTTP yang digunakan di Internet, dengan HTTP versi 1.0 (RFC 1945) (http://www.isi.edu/in-notes/rfc1945.txt) yang paling baru. Halaman WWW ditulis dalam Hypertext Markup Language (HTML), berbasis ASCII, yang merupakan bahasa formatting yang platform-independent (RFC 1866) (http://www.isi.edu/in-notes/rfc1866.txt).
  • IMAP: Internet Mail Access Protocol merupakan alternative dari POP sebagai interface antara user mail client software dengan e-mail server, digunakan untuk mengambil e-mail dengan lebih banyak flexibilitas dalam managemen mailbox.
  • OSPF: Open Shortest Path First versi 2 (OSPFv2) adalah protocol routing berbasis link state yang digunakan di dalam jaringan corporate. OSPF sering disebut sebagai interior gateway protocol.
  • Ping: Program Utility yang memungkinkan pengguna untuk mengetahui status sebuah mesin dan waktu yang dibutuhkan untuk mencapai mesin tersebut. Ping menggunakan message ICMP Echo.
  • POP: Post Office Protocol mendefinisikan interface sederhana antara software user client (seperti Eudora, Outlook) dengan e-mail server, digunakan untuk mengambil e-mail dari server, sehingga client dapat me-manage mailbox-nya. Versi terakhir adalah POP3 (RFC 1460) (http://www.isi.edu/in-notes/rfc1460.txt).
  • RADIUS: Remote Authentication Dial-In User Service (RADIUS) adalah protocol untuk mengauthentikasi pengguna dial-up, biasanya digunakan di ISP yang menggunakan telepon.
  • RIP: Routing Information Protocol (RIP) adalah protokol routing berbasis distance-vector digunakan di dalam jaringan sebuah organisasi.
  • SSH: Protocol Secure Shell memungkinkan pengguna untuk login ke mesin lain di Internet, seperti halnya Telnet. Berbeda dengan Telnet, SSH akan mengenkrop password maupun data yang dikirim.
  • SMTP: Simple Mail Transfer Protocol adalah protokol standard untuk mengirimkan e-mail di Internet (RFC 821) (http://www.isi.edu/in-notes/rfc821.txt). SMTP digunakan antar e-mail server di Internet dan memungkinkan pengguna untuk mengirimkan mail ke server. RFC 822 (http://www.isi.edu/in-notes/rfc822.txt) secara khusus menerangkan format dari message di sebuah mail, sedang RFC 1521 (http://www.isi.edu/in-notes/rfc1521.txt) dan 1522 (http://www.isi.edu/in-notes/rfc1522.txt) menjelaskan MIME (Multipurpose Internet Mail Extensions). Beberapa buku referensi tentang elektronik mail termasuk !%@:: Addressing and Networks oleh D. Frey dan R. Adams (O'Reilly & Associates, 1993) dan THE INTERNET MESSAGE: Closing the Book With Electronic Mail oleh M. Rose (PTR Prentice Hall, 1993).
  • SNMP: Simple Network Management Protocol mendefinisikan prosedur dan database informasi managemen untuk mengatur peralatan jaringan yang berbasis TCP/IP. SNMP (RFC 1157) (http://www.isi.edu/in-notes/rfc1157.txt) pada hari ini banyak di implementasikan di jaringan local maupun di jaringan wide area network. SNMP Versi 2 (SNMPv2, RFC 1441) (http://www.isi.edu/in-notes/rfc1441.txt) menambahkan mekanisme keamanan yang tidak ada di SNMP, tapi lumayan kompleks. Penggunakan SNMPv2 semoga menjadi lebih luas. Informasi tambahan tentang SNMP dan manajemen di jaringan berbasis TCP/IP dapat di peroleh di buku SNMP oleh S. Feit (McGraw-Hill, 1994) dan THE SIMPLE BOOK: An Introduction to Internet Management, 2/e, oleh M. Rose (PTR Prentice Hall, 1994).
  • SSL: Secure Sockets Layer (SSL), dirancang oleh Netscape, memberikan mekanisme untuk berkomunikasi yang aman di Internet. SSL berbasis sertifikat dan kriptografi menggunakan kunci public. Aplikasi SSL yang sering kita gunakan adalah HTTP di atas SSL, yang lebih sering dikenal sebagai HTTPS. Versi baru SSL di kenal sebagai Transport Layer Security (TLS) (RFC 2246) (http://www.isi.edu/in-notes/rfc2246.txt). SSL tidak spesifik HTTP; protokol seperti IMAP4 (imaps), FTP (ftps), Telnet (telnets), dan POP3 (pop3s) semua mempunyai definisi untuk beroperasi di atas SSL.
  • TACACS+: The Terminal Access Controller Access Control System plus adalah sebuah protocol untuk remote akses.
  • Telnet: Kependekan dari Telecommunication Network, sebuah protokol virtual terminal yang memungkinkan seorang pengguna untuk logon ke sebuah mesin TCP/IP untuk mengakses ke mesin lain di jaringan. Telnet di jelaskan di RFC 854 (http://www.isi.edu/in-notes/rfc854.txt).
  • TFTP: Trivial File Transfer Protocol (TFTP) digunakan untuk beberapa aplikasi special yang membutuhkan file transfer sederhana.
  • Time/NTP: Time dan Network Time Protocol (NTP) digunakan oleh mesin di Internet untuk mensinkronkan waktu mereka dengan time server yang ada di Internet.
  • Traceroute: Sebuah tool yang dapat menayangkan routing yang diambil sebuah paket yang berjalan di Internet dari mesin local ke mesin remote tujuan. Di Linux / Unix telah tersedia perintah traceroute. Di Windows, mulai Windows 95 telah tersedia perintah tracert.
  • Whois/NICNAME: Program utility untuk mencari informasi di database tentang Internet Domain dan informasi domain kontak. Whois di jelaskan di RFC 3912 ( http://www.isi.edu/in-notes/rfc3912.txt)

Panduan untuk menggunakan banyak aplikasi ini dapat di peroleh di "A Primer on Internet and TCP/IP Tools and Utilities" (FYI 30/RFC 2151) (http://www.isi.edu/in-notes/rfc2151.txt) oleh Gary Kessler & Steve Shepard.

Pada kesempatan ini, tidak semua aplikasi TCP/IP akan di bahas, beberapa diantaranya, terutama Web dan e-mail akan di bahas secara lebih mendalam.

Untuk dapat secara mendalam mempelajari cara kerja protokol aplikasi ini, sangat di sarankan untuk menggunakan Ethereal dan menangkap / meng-capture data yang dikirim dan mempelajari interaksi protokol aplikasi menggunakan fasilitas “Follow TCP Stream”.


Post Office Protocol 3 – Mengambil E-mail di Server

Dalam aplikasi Internet, sebuah client e-mail lokal akan menggunakan Post Office Protocol version 3 (POP3), untuk mengambil e-mail dari server remote melalui sambungan TCP/IP. Hampir semua pelanggan Internet Service Provider mengambil e-mail mereka menggunakan software yang menggunakan POP3.

Disain dari POP3 maupun yang sebelumnya, untuk mendukung end user yang tidaj mempunyai akses 24 jam ke Internet, seperti dial-up, untuk mengambil semua e-mail pada saat tersambung ke Internet. Walaun umumnya software POP mempunyai option untuk meninggalkan e-mail di server, umumnya yang terjadi adalah connect, ambil semua e-mail, delete yang ada di server, dan masukan ke mailbox di PC sebagai new message.

Bagi mereka yang ingin mengambil e-mail, dan meninggalkannya di server, tidak mendelete-nya biasanya menggunakan perintah POP3 UIDL (Unique Iddentification Listing). Dengan cara itu, client dapat terus mengetahui e-mail mana yang sudah di ambil, dan mana yang belum di ambil. Mekanisme lain yang dapat digunakan untuk mengambil e-mail dan menyimpannya di mail server adalah menggunakan protokol IMAP.

Dengan menggunakan POP3 maupun IMAP untuk mengambil e-mail, untuk mengirimkan e-mail biasanya menggunakan protokol SMTP.

Seperti halnya protokol Internet yang lama lainnya, POP3 awalnya hanya mendukung mekanisme login yang tidak di enkripsi. Hingga hari ini pengiriman password dalam bentuk text pada POP3 masih digunakan, tapi beberapa mekanisme authentikasi yang lebih aman telah di kembangkan. Salah satunya adalah APOP yang menggunakan fungsi hash MD5 untuk menghindari replay attack. Beberapa client yang mengimplementasikan APOP termasuk Mozilla, Thunderbird, Eudora, dan Novell Evolution.

Untuk lebih aman lagi, e-mail client dapat meng-enkrip trafik POP3 menggunakan SSL.



Cara Kerja POP3

Proses awalnya, server akan menjalankan servis POP3 yang mendengarkan pada TCP port 110. Jika di enkapsulasi dalam SSL, biasanya digunakan TCP port 995. Jika client ingin menggunakan servis tersebut, maka client akan membuka hubungan TCP ke server host.

Jika sambungan terjadi, server POP3 akan mengirimkan selamat datang. Client dan akan server POP3 akan saling bertukar perintah dan responds sampai hubungan di putuskan atau terputus. Perintah di POP3 biasanya terdiri dari keyword yang tidak case-sensitif, biasanya di ikuti oleh satu atau lebih argumen / parameter. Ada dua indikator status, positif (+OK) dan negatif (-ERR).

Ada tiga (3) tahap transaksi POP3, tahap pertama adalah tahap AUTHORIZATION. Tahap ke dua adalah tahap TRANSACTION, dan terakhir adalah tahap UPDATE yang dimulai dengan perintah QUIT dari sisi client.

Rangkuman Perintah POP3 

Perintah Minimal POP3
USER name valid di tahap AUTHORIZATION
PASS string
QUIT
STAT valid di tahap TRANSACTION
LIST [msg]
RETR msg
DELE msg
NOOP
RSET
QUIT

Perintah Optional POP3 

APOP name digest valid di tahap AUTHORIZATION 
TOP msg valid di tahap TRANSACTION
UIDL [msg]
POP3 Replies:
+OK
-ERR

Contoh Dialog POP3

client (“C:”)membuka hubungan ke server POP3 (“S:”) 

S:    <wait for connection on TCP port 110>
C:    $ telnet pop.cbn.net.id 110
C:    Trying 210.210.145.40...
C:    <open connection>
C:    Connected to pop.cbn.net.id (210.210.145.40).
C:    Escape character is '^]'.
S:    +OK POP3 Ready pop1a.int.cbn.net.id 0001d694

client (“C:”) mengauthentikasi ke server POP3 (“S:”) 

C:   USER malin
S:    +OK USER nurlina set, mate
C:    PASS kundang123
S:    +OK You are so in

client (“C:”) melihat jumlah mail yang ada di server POP3 (“S:”) 

C:    STAT
S:    +OK 1 1785
C:    LIST
S:     +OK POP3 clients that break here, they violate STD53.
S:     1 1785

client (“C:”) mengambil mail di server POP3 (“S:”) 

C:    RETR 1
S:     +OK 1785 octets follow.
S:     Received: (qmail 6387 invoked from network); 28 Feb 2006 15:34:03 +0700
S:     Received: from unknown (HELO mx1a.int.cbn.net.id) (10.64.128.128)
S:        by box3a.int.cbn.net.id with SMTP; 28 Feb 2006 15:34:03 +0700
S:      … dst …
S:      .

client (“C:”) membuang / mendelete mail yang sudah di ambil. 

C:    DELE 1
S:     +OK Deleted.

client (“C:”) memutuskan hubungan dengan server POP3 (“S:”) 

C:    QUIT
S:     +OK Bye-bye.
C:    Connection closed by foreign host.
C:    <close connection>
S:    <wait for next connection>

Instalasi POP3 Server

POP3 dan IMAP Server yang tersedia di Linux Fedore Core 4 adalah Dovecot. Instalasi POP3 Server di Linux Fedora Core 4 tidak sulit dan tidak perlu mengkonfigurasi apa-apa karena biasanya langsung operasional. Perintah instalasi ini tidak berbeda jauh di Fedora Core 5 maupun versi yang lebih tinggi. Perintah instalasi yang perlu dilakukan adalah

1.Masukan CD 3 Fedora Core 4 2.# cd /mount/cdrom/Fedora/RPMS 3.# rpm –ivh dovecot-0.99.14-4.fc4.i386.rpm

Cara yang lebih mudah, menggunakan fasilitas “Add Remove Applications” di bagian System Settings yang ada di Fedora Core 4 yang berbentuk GUI. Dovecot ada di bagian server  mail server.

Menjalankan Service POP 3 dan IMAP dapat dilakukan sekaligus melalui perintah 

# chkconfig dovecot on
# service dovecot restart

Bagi pengguna Debian / Ubuntu dapat dilakukan menggunakan perintah 

$ sudo /etc/init.d/dovecot start

File konfigurasi dovecot terdapat di /etc/dovecot.conf, pada operasi normal tidak perlu di edit sama sekali. Simple Mail Transport Protocol (SMTP) – Mengirim / Menerima E-mail

Berkomunikasi dengan e-mail merupakan salah satu layanan Internet yang paling banyak digunakan. E-mail terkenal karena memberikan cara yang mudah dan cepat dalam mengirim informasi. Selain itu juga dapat menangani attachment kecil sampai file yang ukurannya cukup besar. Dan tidak perlu diragukan lagi, bahwa sebagian besar pengguna mengirim file menggunakan e-mail dari pada menggunakan program transfer file. Rata-rata pesan dalam e-mail tidak mencapai sepuluh kilobyte dan beberapa pesan mengandung beberapa megabyte data, karena digunakan untuk mengirim file.

Mekanisme pertukaran e-mail menggunakan TCP/IP dapat dilihat di gambar berikut.


Pemakai di terminalnya berhubungan dengan user agent (UA). Beberapa agent e-mail yang populer antara lain: Pine, Pegasus, Eudora, dan Outlook Express. Pertukaran mail menggunakan TCP dilakukan oleh Message Transport Agent (MTA). MTA yang paling umum untuk Linux adalah Sendmail dan Postfix. Pemakai awam biasanya tidak berhubungan dengan MTA ini. MTA adalah tanggung jawab administrator jaringan.

Pada bagian ini akan dipelajari pertukaran elektronik mail antar dua MTA menggunakan TCP. User agent tidak akan dibahas di sini.

Protokol SMTP

Komunikasi antara dua MTA menggunakan NVT ASCII. Perintah dikirim oleh client ke server, dan server merespon dengan kode balasan numerik dan beberapa string yang dapat dibaca.

Contoh interaksi MTA ditampilkan berikut ini. Kita akan mengirim sebuah pesan satu baris dan akan kita lihat hubungan SMTPnya. Kita menjalankan user agent mail di shell dengan tambahan flag -v, yang kemudian dikirim ke MTA (disini menggunakan Postfix di Fedora Core 4). MTA akan menampilkan apa yang dikirim dan diterimanya melalui hubungan SMTP. Baris yang dimulai dengan >>> adalah perintah yang dikirim oleh client SMTP, dan baris yang dimulai dengan kode balasan 3 digit adalah dari server SMTP. Berikut ini adalah contoh session interaktifnya: 

[onno@yc0mlc ~]$ mail yc0mlc@yc0mlc.ampr.org -v
Subject: testing
test satu dua tiga
.
Cc:
yc0mlc@yc0mlc.ampr.org... Connecting to [127.0.0.1] via relay...
220 yc0mlc.ampr.org ESMTP Postfix
>>> EHLO yc0mlc.ampr.org
250-yc0mlc.ampr.org
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250 8BITMIME
>>> MAIL From:<onno@yc0mlc.ampr.org> SIZE=64
250 Ok
>>> RCPT To:<yc0mlc@yc0mlc.ampr.org>
>>> DATA
250 Ok
354 End data with <CR><LF>.<CR><LF>
>>> .
250 Ok: queued as D8FB0CDB3B
yc0mlc@yc0mlc.ampr.org... Sent (Ok: queued as D8FB0CDB3B)
Closing connection to [127.0.0.1]
>>> QUIT
221 Bye
[onno@yc0mlc ~]$

Untuk mengirim pesan e-mail, hanya ada lima perintah yang digunakan, yaitu: HELO, MAIL, RCPT, DATA, dan QUIT.

Pada contoh di atas, kita mengetik mail untuk menjalankan user agent. Selanjutnya kita diminta mengisi Subject dan Body of the message (isi pesan). Untuk mengakhiri pesan, kita mengetik sebuah titik pada baris paling akhir, yang selanjutnya user agent akan mengirim mail tersebut ke MTA.

SMTP sangat sederhana. Komunikasi antara client dan server terdiri dari teks-teks yang mudah dibaca. Meski SMTP mendefinisikan perintah-perintah secara kaku, namun kita masih bisa dengan mudah membaca transkrip interaksi antara client dan server.

Mula-mula, client melakukan hubungan TCP secara aktif ke port 25, dan menunggu kode balasan 220 yang kadang kala di tambahkan ucapan selamat datang dari server, dalam hal ini ESMTP Postfix. Respon server harus dimulai dengan FQDN (fully qualified domain name) dari server, misal yc0mlc.ampr.org.

Selanjutnya client memperkenalkan dirinya dengan perintah EHLO, yaitu perintah yang ada pada ESMTP. Bagi MTA yang menggunakan SMTP versi awal yang primitif, maka MTA tersebut biasanya hanya mengenal perintah HELO. Argumen di belakang perintah tersebut harus FQDN dari client, misal yc0mlc.ampr.org.

Server merespon dengan memberikan identitas dirinya kepada client. Jika komunikasi sudah terbentuk, client dapat mengirim lebih dari satu pesan, mengakhiri hubungan, atau meminta server untuk mengirim aturan bagi pengirim dan penerima, sehingga pesan dapat mengalir dengan arah yang sebaliknya.

Transaksi mail dimulai dengan perintah MAIL, yang menjelaskan siapa pengirim pesan ini. Server selanjutnya mempersiapkan struktur datanya agar dapat menerima pesan baru, dan membalas perintah MAIL tersebut dengan kode 250, atau lengkapnya 250 OK.

Perintah selanjutnya RCPT, menjelaskan kepada siapa mail ditujukan. Jika ada banyak penerima, maka beberapa perintah RCPT dapat dikirimkan. Server harus mengirim pemberitahuan bagi setiap perintah RCPT ini dengan mengirim respon 250 OK, atau pesan kesalahan, misal 550 No such user here.

Isi pesan dikirim oleh client dengan perintah DATA yang diakhiri dengan mengirim satu baris data yang hanya berisi satu titik. Server merespon dengan mengirim pesan 354 dan menentukan urutan karakter tertentu yang dijadikan sebagai tanda akhir pesan e-mail. Urutan ini sebenarnya terdiri dari 5 karakter: carriage return (CR), line feed (LF), titik (“.”), carriage return (CR), dan line feed (LF).

QUIT dikirim terakhir untuk mengakhiri transaksi pengiriman pesan e-mail ini. Server meresponnya dengan mengirim pesan 221, yang berarti setuju untuk menghentikan transaksi. Kedua pihak akhirnya menutup hubungan TCP.

Di bawah ini adalah e-mail yang diterima oleh yc0mlc@yc0mlc.ampr.org lengkap dengan header informasi yang di tambahkan oleh MTA. 

Return-Path: <onno@yc0mlc.ampr.org>
X-Original-To: yc0mlc@yc0mlc.ampr.org
Delivered-To: yc0mlc@yc0mlc.ampr.org
Received: from yc0mlc.ampr.org (yc0mlc.ampr.org [127.0.0.1])
    by yc0mlc.ampr.org (Postfix) with ESMTP id D8FB0CDB3B
    for <yc0mlc@yc0mlc.ampr.org>; Wed,  1 Mar 2006 05:49:52 +0700 (WIT)
Received: (from onno@localhost)
    by yc0mlc.ampr.org (8.13.4/8.13.4/Submit) id k1SMnoDL015047
    for yc0mlc@yc0mlc.ampr.org; Wed, 1 Mar 2006 05:49:50 +0700
Date: Wed, 1 Mar 2006 05:49:50 +0700
From: onno@yc0mlc.ampr.org
Message-Id: <200602282249.k1SMnoDL015047@yc0mlc.ampr.org>
To: yc0mlc@yc0mlc.ampr.org
Subject: testing
MIME-Version: 1.0

test satu dua tiga



Sebenarnya SMTP jauh lebih kompleks dibandingkan dengan yang dijelaskan di sini. Misalnya, jika seorang pemakai pindah, server bisa tahu dimana mailbox yang baru, dan memberi tahu client agar menggunakan alamat terbaru tersebut.

Komponen E-mail

Elektronik mail terdiri dari tiga (3) komponen.

1.Envelope, atau amplop. Ini digunakan oleh MTA untuk pengiriman. Dalam contoh sebelumnya, envelope ditandai dengan dua buah perintah SMTP: MAIL From: <onno@yc0mlc.ampr.org> RCPT To: <yc0mlc@yc0mlc.ampr.org> Isi dan interpretasi dari envelope SMTP ditentukan di RFC 821. RFC ini juga menentukan protokol yang digunakan untuk mengirim mail melalui hubungan TCP.

2.Header, digunakan oleh user agent. Dalam contoh sebelumnya, ada beberapa field header dalam contoh, yaitu: Return-Path, X-Original-To, Delivered-To, Received, Date, From, Message-Id, To, dan Subject. Setiap field header berisi sebuah nama yang diikuti oleh sebuah titik dua (:), dan nilai dari field header tersebut. Format dan interpretasi atas field header ini ditentukan dalam RFC 822. Field header yang panjang, seperti Received, akan dilipat ke dalam beberapa baris, dengan ditambah sebuah spasi kosong di depannya.

3.Body merupakan isi pesan dari pengirim ke penerima. Dalam RFC 822 disebutkan bahwa body ini merupakan baris-baris dalam bentuk text ASCII. Setiap baris yang dikirim menggunakan perintah DATA, tidak boleh melebihi 1024 byte.


Relay Agent

Baris pertama informasi yang diberikan oleh MTA lokal pada contoh kita di atas adalah “Connecting to [127.0.0.1] via relay...”. Pesan yang sudah diterima oleh MTA lokal dari user agent (UA) dikirim ke relay. Relay adalah host yang bertindak sebagai mesin relay untuk pengiriman mail. Jadi setiap mail yang dikirim ke luar jaringan, akan dikirim dulu ke relay agent ini, dan selanjutnya menjadi tanggung jawab relay agent untuk meneruskan ke tujuan.

Host yang bertindak sebagai relay agent harus didaftarkan di DNS sebagai MX (Mail Exchanger) dan setiap sistem e-mail di dalam domainnya diset agar mengirim mail mereka ke host ini.

Untuk melihat relay sebuah mesin di Internet dapat menggunakan perintah host seperti di bawah ini, 

[onno@yc0mlc ~]$ host yahoo.com
yahoo.com has address 66.94.234.13
yahoo.com has address 216.109.112.135
yahoo.com mail is handled by 1 mx1.mail.yahoo.com.
yahoo.com mail is handled by 1 mx2.mail.yahoo.com.
yahoo.com mail is handled by 1 mx3.mail.yahoo.com.
yahoo.com mail is handled by 5 mx4.mail.yahoo.com.

Atau menggunakan perintah dig, sebagai berikut, 

[onno@yc0mlc ~]$ dig MX yahoo.com 

; <<>> DiG 9.3.1 <<>> MX yahoo.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52898
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 19

;; QUESTION SECTION:
;yahoo.com.                     IN      MX

;; ANSWER SECTION:
yahoo.com.              7097    IN      MX      5 mx4.mail.yahoo.com.
yahoo.com.              7097    IN      MX      1 mx1.mail.yahoo.com.
yahoo.com.              7097    IN      MX      1 mx2.mail.yahoo.com.
yahoo.com.              7097    IN      MX      1 mx3.mail.yahoo.com.

;; AUTHORITY SECTION:
yahoo.com.              83688   IN      NS      ns5.yahoo.com.
;; ADDITIONAL SECTION:
mx1.mail.yahoo.com.     1091    IN      A       67.28.113.10

;; Query time: 23 msec
;; SERVER: 202.46.3.178#53(202.46.3.178)
;; WHEN: Wed Mar  1 06:30:44 2006
;; MSG SIZE  rcvd: 506

Terilihat bahwa relay agent untuk yahoo.com di set ke mx1, mx2, mx3.mail.yahoo.com yang kebetulan mempunyai priorotas 1, dan mx4.mail.yahoo.com yang mempunyai prioritas lebih rendah, yaitu 5.

Di Internet, sebagian besar organisasi telah menggunakan sistem relay. Dengan sistem ini, kita dapat menyembunyikan setiap sistem e-mail individual dari luar. Gambar memperlihatkan sistem elektronik mail Internet yang menggunakan sistem relay di kedua ujungnya.

Ada empat MTA pada skenario tersebut, antara pengirim dan penerima. MTA lokal hanya meneruskan mail ke MTA relay milik organisasi yang sama. Dengan demikian, komunikasi antara kedua MTA ini menggunakan SMTP melalui intranet organisasi tersebut. MTA relay pada organisasi pengirim, meneruskan mail ke MTA relay pada organisasi penerima melalui Internet. MTA relay yang satunya ini selanjutnya mengirim mail ke host penerima, melalui komunikasi dengan MTA lokal pada host penerima tersebut. Semua MTA pada skenario ini menggunakan protokol SMTP.



Laporan Kegagalan

Kegagalan pengiriman e-mail adalah hal yang wajar. Mail Server biasanya akan mengirimkan pesan, seperti di bawah ini: 

Date: Wed,  1 Mar 2006 05:40:10 +0700 (WIT)
From: Mail Delivery System <MAILER-DAEMON@yc0mlc.ampr.org>
To: onno@yc0mlc.ampr.org
Subject: Undelivered Mail Returned to Sender
Parts/Attachments:
   1   Shown     14 lines  Text, "Notification"
   2   Shown    391 bytes  Message, "Delivery report"
   3   Shown    918 bytes  Message, "Undelivered Message"
   3.1 Shown      9 lines  Text
---------------------------------------- 

This is the Postfix program at host yc0mlc.ampr.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                        The Postfix program 

<antahberantah@entahdimana.com>: Host or domain name not found. Name service
    error for name=entahdimana.com type=A: Host not found 

    [ Part 2: "Delivery report" ]

Reporting-MTA: dns; yc0mlc.ampr.org
X-Postfix-Queue-ID: DE135CDB3D
X-Postfix-Sender: rfc822; onno@yc0mlc.ampr.org
Arrival-Date: Wed,  1 Mar 2006 05:40:02 +0700 (WIT)

…. di hapus ….

Dalam laporan ke gagalan di atas, kesalahan terjadi karena domain entahdimana.com tidak di ketahui keberadaannya di Internet. Tentunya masih banyak lagi kesalahan pengiriman yang mungkin terjadi, misalnya, username yang dituju tidak ada, MTA tidak berhasil mengirimkan e-mail dalam selang waktu tertentu (biasanya sekitar 4 jam), MTA tidak berhasil mengirimkan e-mail dalam waktu beberapa hari sehingga mail terpaksa di buang.

Extended SMTP

Extended SMTP atau ESMTP merupakan hasil framework yang ditambahkan kepada SMTP. Adanya kemampuan baru pada ESMTP ini tidak mempengaruhi implementasi lama yang telah ada.

EHLO, adalah perintah pengganti HELO, pada ESMTP. Ini merupakan pemberitahuan kepada server bahwa client akan memanfaatkan kemampuan baru pada ESMTP. Jika client membuka hubungan dengan perintah HELO, berarti dia masih ingin menggunakan implementasi yang lama, yaitu SMTP. Server yang kompatibel dengan ESMTP akan merespon dengan memberi kode 250. Respon ini normalnya bersifat multi baris yang setiap baris terdiri dari sebuah keyword dan argumen pilihan. Keyword-keyword ini menunjukkan ekstension SMTP yang didukung oleh server.

Inisialisasi hubungan kepada beberapa server SMTP yang mendukung ESMTP akan kita lihat, untuk mengetahui ekstension SMTP yang didukung oleh masing-masing server. Kita melakukannya dengan perintah Telnet ke port 25. 

[yc0mlc@yc0mlc ~]$ telnet yc0mlc.ampr.org 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 yc0mlc.ampr.org ESMTP Postfix
EHLO test
250-yc0mlc.ampr.org
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250 8BITMIME

Exteded command ditunjukkan dibelakang kode 250, yaitu PIPELINING, SIZE, VRFY, dan 8BITMIME. Server ESMTP ini menyatakan perintah-perintah pilihan dari RFC 821 yang didukungnya, dan dalam contoh ini adalah VRFY dan ETRN. Keyword 8BITMIME melarang client untuk mengirim karakter selain ASCII. Keyword SIZE akan membolehkan client memasukkan ukuran mail (bytes) setelah perintah MAIL FROM. Setiap keyword yang dimulai dengan X, seperti XUSR, merujuk pada ekstension SMTP lokal.

Contoh berikut adalah server SMTP yang dimiliki oleh NOS (Network Operating System), yaitu server elektronik mail untuk jaringan radio paket. Server ini tidak mendukung Extended SMTP, sehingga memberi pesan kesalahan 500 Command unrecognized, terhadap perintah EHLO. 

khnemu # telnet hathor 25
Trying 132.92.36.167...
Connected to hathor.cnrg.net.
Escape character is '^]'.
220 hathor.cnrg.net SMTP HMEITB ready
EHLO khnemu
500 Command unrecognized
rset
250 Reset state

Selanjutnya, client harus mengirim perintah RSET dan diikuti oleh perintah HELO.


Multipurpose Internet Mail Extension (MIME)

Jika RFC 822 menentukan body message sebagai baris-baris teks dalam NVT ASCII tanpa struktur, maka RFC 1521 mendefinisikan ekstension yang memungkinkan adanya struktur dalam body message e-mail. Hal ini disebut MIME, Multipurpose Internet Mail Extension.

MIME tidak memerlukan ekstension pada ESMTP atau header non-ASCII. MIME hanya menambah beberapa header yang memberitahukan kepada penerima struktur dari body message. Dengan demikian, body masih bisa dikirim menggunakan NVT ASCII, tidak perduli isi dari mail. Kalau pada ESMTP ada perintah SIZE yang menyatakan panjang maksimum mail, sementara MIME bisa sangat panjang, maka ESMTP harus tidak berpengaruh pada MIME. Yang diperlukan agar MIME bisa diterapkan adalah, kedua ujung, baik pengirim maupun penerima, harus memiliki user agent yang mengerti MIME.

Ada lima field header pada MIME: 

Mime-Version:
Content-Type:
Content-Transfer-Encoding:
Content-ID:
Content-Description:

Contoh, pada message mail Internet, akan ada dua baris header seperti ini: 

Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Default dari Internet adalah MIME versi 1.0 dengan charset US-ASCII. MIME mendefinisikan tujuh Content-type. Tabel berikut ini memperlihatkan ke tujuh tipe dan sub-tipenya. 

Content-Type
Subtype
Keterangan
Text
plain

Teks yang tidak diformat

richtext Teks dengan format sederhana: tebal, miring, garis bawah, dst.

enriched Penyederhanaan dan penyempurnaan dari richtext. multipart mixed Beberapa bagian dari body diproses secara berurutan.

parallel Beberapa bagian dari body dapat diproses secara paralel

digest Sebuah digest elektronik mail

alternative Beberapa bagian dari body ada, semua menggunakan isi semantik yang identik. message rfc822 Content adalah pesan mail berdasarkan RFC 822.

partial Content adalah bagian dari sebuah pesan mail.

external-body Content merupakan penunjuk ke pesan yang sebenarnya. application octet-stream Biasanya data biner.

postscript Sebuah program postscript. image jpeg Format ISO 10918.

gif Format Graphic Interface Format dari CompuServe. audio basic Pengkodean menggunakan format -law ISDN 8-bit. video mpeg Format ISO 11172.


Pengkodean untuk transfer ditentukan oleh field header Content-Transfer-Encoding. Ada lima format pengkodean yang berbeda:

  1. Default, ASCII (7 bit).
  2. quoted-printable, seperti pada contoh sebelumnya. Ini berguna jika ada beberapa karakter yang menggunakan 8-bit set.
  3. base64.
  4. 8bit, yang mengandung karakter baris dan beberapa karakter non-ASCII.
  5. binary, yaitu data 8-bit yang tidak mengandung baris.

Berikut ini contoh mail yang mengandung MIME dengan Content-Type MULTIPART dan subtype MIXED. Mail ini mengandung beberapa bagian atau attachment. Bagian pertama memiliki Content-Type TEXT dan bagian kedua adalah IMAGE/jpeg. 

From onno@indo.net.id  Wed Mar  1 08:06:52 2006
X-Original-To: onno@yc0mlc.ampr.org
Delivered-To: onno@yc0mlc.ampr.org
Date: Wed, 1 Mar 2006 08:06:48 +0700 (WIT)
From: "Onno W. Purbo" <onno@indo.net.id>
X-X-Sender: onno@yc0mlc.ampr.org
To: onno@yc0mlc.ampr.org
Subject: foto
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-2082643410-1141175208=:17717"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-2082643410-1141175208=:17717
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Test pengiriman foto

--8323328-2082643410-1141175208=:17717
Content-Type: IMAGE/jpeg; name=OnnoW-STT.jpg
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.63.0603010806480.17717@yc0mlc.ampr.org>
Content-Description:
Content-Disposition: attachment; filename=OnnoW-STT.jpg

/9j/4AAQSkZJRgABAAEAyADIAAD//gAfTEVBRCBUZWNobm9sb2dpZXMgSW5j
LiBWMS4wMQD/2wCEACEWGB0YFCEdGx0lIyEnMVM2MS0tMWVITDxTeGp+fHZq
dHKFlb+ihY20j3J0puKotMXL1tjWgKDr++jQ+b/S1s0BIyUlMSsxYTY2Yc2J
dInNzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3N
NQscaooOQFGAKAHYG4HAyOAaAEEaCQyBFDkYLY5P40ACIkYIRVUE5OBjJoAX
KACgAoAKACgAoAKACgAoAQ9DQDKC/MfTNavQwEBz+QpvcA9Md6BC45zSHYQd
cfU/qKb0EAOe1D0GWLYYf6r/AFqJFw3MrVsC+fjoB/KtIbIfVlLHy89PT8qp
FARnGfSgYh+UA+1Akbemf8eUnoCRWMipbDiORzz/APWqrnMJimOwoGfxx/n9
aQmhv+f1oAXvj/Pb/GgBVG4+gz/n+dMCe0+6T6gVEzWHVFioLCgAoAKACgAo
AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA//2Q== 

--8323328-2082643410-1141175208=:17717—


Instalasi Mail Server Sederhana

Di Linux Fedora Core 4 ada beberapa software yang siap untuk Mail Server sederhana. Untuk memudahkan pengguna mengambil e-mail menggunakan POP3 dan IMAP telah tersedia dovecot yang di jelaskan di bagian sebelumnya.

Ada beberapa paket program yang akan membantu dalam mengoperasikan SMTP & mail server di Fedora Core 4, antara lain adalah:

  1. sendmail (SMTP server)
  2. Postfix (SMTP server, alternatif dari Sendmail. Saya menggunakan ini).
  3. Squirrelmail (Webmail interface, supaya pengguna bisa mengakses menggunakan Web pada URL http://ipmesinanda/webmail/ atau http://127.0.0.1/webmail/ di mesin lokal).
  4. dovecot (POP3 & IMAP server)
  5. mailman (mailing list server yang mempunyai interface Web).

Semua paket program ini dapat di instalasi menggunakan fasilitas “Add Remove Applications” yang ada di System Settings terutama masuk ke bagian server  mail server. Beberapa catatan untuk paket program ini,

dovecot dapat langsung di operasikan tanpa di konfigurasi. Mailman baru akan jalan jika kita sudah membuat user mailman dan menset password site mailman. Squirrelmail akan jalan jika dovecot sudah aktif. Squirrelmail membutuhkan akses ke server IMAP. Sendmail dan Postfix hanya dapat jalan salah satu. Kita dapat menggunakan fasilitas konfigurasi di bagian setting untuk memilih SMTP server mana yang akan di gunakan. Default akan menggunakan sendmail.

Setting default mail server umumnya hanya dapat me-relay mail dari localhost (127.0.0.1) saja. Agar Postfix dapat merelay e-mail dari workstation lain yang ada di LAN, kita perlu membuka satu parameter di file konfigurasi /etc/postfix/main.cf, agar, 

inet_interfaces = all

nilai default awalnya adalah net_interfaces = localhost, sehingga hanya localhost yang dapat mengirimkan e-mail melalui mail server postfix.

Untuk mengaktifkan mail server tidak terlalu sulit, hanya, 

# chkconfig sendmail on
# service sendmail restart

atau 

# chkconfig postfix on
# service postfix restart

Dengan setting yang sangat minimal di atas, sebetulnya server kita telah dapat beroperasi dengan baik. Tentunya masih banyak detail konfigurasi lainnya yang bisa kita gunakan supaya sistem menjadi lebih effisien, lebih aman, dan lebih andal. Situs yang baik tentang Postfix di Indonesia adalah http://www.postfix.or.id.



Hypertext Transfer Protocol

Sebelum ini telah dijelaskan bahwa Hypertext Transfer Protocol digunakan untuk jenis layanan WWW di jaringan TCP/IP. Spesifikasi protokol ini didefinisikan oleh Tim Berners-Lee dalam RFC 1945 dan digunakan di Internet sejak tahun 1990. Pada bagian ini akan dijelaskan bagaimana protokol HTTP bekerja, dimulai dari model hubungan HTTP, format pesan, dan cache di protokol HTTP.

RFC 1945 yang mendefinisikan protokol HTTP versi 1.0 ternyata dianggap masih memiliki kekurangan dan kemudian IETF menspesifikasikan protokol HTTP versi baru, yaitu 1.1 dalam RFC 2068. Perbaikan atas HTTP 1.0 antara lain adalah koneksi persistent dan pipelined serta model cache yang lebih baik.

Standarisasi Web dilakukan oleh W3C http://www.w3c.org. Sangat di sarankan, untuk membaca berbagai tutorial yang berhubungan dengan Web melalui alamat http://www.w3.org/2002/03/tutorials.

Model hubungan HTTP

Protokol HTTP bersifat request-response, yaitu dalam protokol ini client menyampaikan pesan request ke server dan server kemudian memberikan response yang sesuai dengan request tersebut. Request dan response dalam protokol HTTP disebut sebagai request chain dan response chain. Hubungan HTTP yang paling sederhana terdiri atas hubungan langsung antara user agent dengan server asal. Hubungan HTTP tidak selalu seperti ini karena spesifikasi HTTP mengenal adanya beberapa komponen yang dapat terlibat dalam membentuk sebuah hubungan HTTP, yaitu client, user agent, server asal, proxy, gateway, dan tunnel.

Menurut spesifikasi HTTP, istilah-istilah di atas adalah sebagai berikut:

Client - Program yang membentuk hubungan HTTP dengan tujuan untuk mengirimkan request User agent - Client yang melakukan request, dapat berupa browser, editor, spider, atau perangkat lain Server asal - Server tempat menyimpan atau membuat resource Proxy - Program perantara yang bertindak sebagai server dan client dengan tujuan untuk membuat request atas nama client yang lain Gateway - Server yang bertindak sebagai perantara untuk server lain. Gateway menerima request seolah-olah ia adalah server asal dan client tidak mengetahui bahwa gateway yang menerima request yang dikirim. Tunnel - Program perantara yang bertindak sebagai perantara buta antara dua hubungan HTTP. Tunnel tidak dianggap sebagai pihak yang terlibat dalam hubungan HTTP, walaupun ia dapat membuat HTTP request.

Pada protokol HTTP terdapat tiga jenis hubungan dengan perantara: proxy, gateway, dan tunnel. Proxy bertindak sebagai agen penerus, menerima request dalam bentuk Uniform Resource Identifier (URI) absolut, mengubah format request, dan mengirimkan request ke server yang ditunjukkan oleh URI. Gateway bertindak sebagai agen penerima dan menerjemahkan request ke protokol server yang dilayaninya. Tunnel bertindak sebagai titik relay antara dua hubungan HTTP tanpa mengubah request dan response HTTP. Tunnel digunakan jika komunikasi perlu melalui sebuah perantara dan perantara tersebut tidak mengetahui isi dari pesan dalam hubungan tersebut. Gambar contoh hubungan HTTP yang melibatkan beberapa komponen dapat dilihat di gambar



Proxy atau gateway dapat menggunakan mekanisme cache untuk memperpendek rantai hubungan HTTP. Proxy pada gambar di atas dapat menggunakan cache dan memberikan response cache sehingga request dari UA tidak perlu dilayani oleh server asal karena proxy telah memberikan response atas request tersebut.

Hubungan Persistent

Perbedaan mendasar antara HTTP/1.1 dengan HTTP/1.0 adalah penggunaan hubungan persistent. Jika HTTP/1.0 membutuhkan sebuah koneksi TCP untuk setiap permintaan URI, maka HTTP/1.1 dapat menggunakan sebuah koneksi TCP saja untuk beberapa permintaan URI. Server HTTP/1.1 dapat mengasumsikan bahwa hubungan yang digunakan dengan client HTTP/1.1 adalah hubungan persistent, kecuali jika client menyatakan tidak hendak menggunakan hubungan persistent. Dalam mekanisme ini, server dan client dapat mengirim sinyal untuk menutup koneksi TCP menggunakan header

Connection: close.

Setelah sinyal ini dikirim, client tidak boleh lagi mengirimkan request ke server.

Server atau client yang berhubungan menggunakan protokol HTTP dengan versi lebih rendah dari 1.1 harus tidak mengasumsikan terjadinya hubungan persistent kecuali dinyatakan dengan jelas melalui sinyal

Connection: Keep-Alive.

Hubungan persistent juga mendukung request yang di-“pipeline”, yaitu client mengirimkan beberapa request sekaligus tanpa menunggu response selesai datang dari server. Server yang menerima request yang di-“pipeline” harus memberikan response sesuai urutan request. Client yang mendukung pipeline harus siap untuk kembali mengirimkan request tersebut jika server tidak memberikan response.




Format HTTP

Kita mengenal protokol HTTP menggunakan format URL (Universal Resource Locator) HTTP dalam bentuk:

“http:” “//” host [ “:”port ] [ abs_path ]

Dengan,

host - nama domain Internet yang legal. port - bilangan yang menunjukkan port HTTP di host (default 80). abs_path - lokasi resource di dalam host.

Contoh: http://www.google.co.id/index.html http://sandbox.bellanet.org:80/~onno/the-guide/

Jika kita mengisikan URL tersebut ke browser, browser bertugas untuk mengartikan URL tersebut dan menerjemahkannya dalam komunikasi protokol HTTP. Aturan dalam mengartikan format URL HTTP mengikuti aturan umum URI, yaitu case-sensitive, kecuali nama dan skema URI case-insensitive. Dengan aturan ini maka http://sandbox.bellanet.org:80/~onno/the-guide/ sama dengan http://sandbox.BELLANET.org:80/~onno/the-guide/ tetapi berbeda dengan http://sandbox.bellanet.org:80/~onno/The-guide/.

Komunikasi protokol HTTP terdiri atas pesan request yang diberikan oleh user agent dan response yang dikeluarkan oleh server. Setiap request dan response HTTP menggunakan format pesan generik seperti yang didefinisikan oleh RFC 822. Pesan HTTP terdiri atas baris mulai, header pesan, dan isi pesan beserta entity (opsional). Header pesan dan isi pesan dipisahkan oleh sebuah baris kosong, yaitu hanya berisi karakter CRLF. Baris mulai pada pesan request berisi pesan permintaan dari client, sementara pada pesan response, baris ini berisi status response atas request yang diterima. Header pesan dapat terdiri atas beberapa baris, tergantung dari field-field yang perlu disertakan dalam header tersebut. Terdapat empat jenis header pesan, yaitu header pesan umum yang berlaku di setiap jenis pesan, header request, header response, dan header entity.

Header yang umum pada pesan HTTP request dan response adalah

Header-umum = Cache-Control | Connection | Date | Pragma 

    | Transfer-Encoding | Upgrade | Via

Fungsi dari masing-masing field adalah,

Field Cache-control memberikan aturan yang harus ditaati oleh seluruh mekanisme cache dalam rantai request/response. Field Connection mengatur tipe hubungan HTTP, apakah akan menggunakan hubungan persistent atau tidak. Field Date memberikan informasi mengenai waktu asal pesan. Field Transfer-Encoding menentukan jenis transfer yang diberikan kepada isi pesan agar dapat sampai dengan aman ke client. Field Upgrade pada pesan HTTP digunakan untuk mengganti protokol yang hendak digunakan, field ini berguna sebagai mekanisme transisi dari protokol HTTP/1.1 ke protokol tipe lain. Field Via digunakan oleh proxy dan gateway untuk memberitahu jalur yang digunakan dalam sebuah rantai request/response.

Isi pesan HTTP digunakan untuk mengirimkan isi entity. Keberadaan isi pesan dalam pesan request ditandai dengan adanya header Content-Length. Dalam pesan response, keberadaan isi pesan ini tergantung atas kode-status yang diberikan. Dalam sebuah pesan HTTP, header Content-Length dan Transfer-Encoding tidak boleh muncul bersama-sama. Kedua header ini menunjukkan hal yang berlawanan: adanya header Transfer-Encoding menunjukkan bahwa panjang isi pesan tidak diketahui sementara header Content-Length menunjukkan panjang isi pesan dalam byte. Jika dalam sebuah pesan terdapat kedua header ini, maka header Content-Length harus diabaikan.

Setiap request dan response dalam komunikasi HTTP harus menyertakan versi protokol yang digunakan. Format penulisan versi protokol ini adalah

HTTP/<major>.<minor>

Major dan minor adalah bilangan yang menunjukkan versi dari protokol HTTP. Dengan aturan ini penulisan versi protokol untuk versi 1.0 adalah HTTP/1.0 dan HTTP/1.1 untuk versi 1.1.

Penyertaan versi protokol ini diperlukan karena dapat saja terjadi dalam sebuah hubungan HTTP, server dan client menggunakan versi yang berbeda. Jika ini terjadi maka server dan client harus menggunakan versi HTTP tertinggi yang mungkin agara keduanya dapat berkomunikasi dengan baik.


Request

Format baris mulai dari pesan request HTTP dimulai dengan metode request, diikuti oleh URI untuk request, versi protokol yang digunakan dan diakhiri oleh karakter CRLF

Baris-request = Method SP Request-URI SP HTTP-Version CRLF

Method menunjukkan metode apa yang hendak dilakukan atas resource yang ditunjuk oleh Request-URI. Ada beberapa metode yang didefinisikan oleh HTTP/1.1, yaitu:

OPTIONS, GET, HEAD, POST, PUT, DELETE & TRACE.

Untuk setiap pesan request, server harus memberikan kode jawaban untuk memberitahu apakah client diperbolehkan mengakses menggunakan method yang diinginkan. Jika method tidak boleh digunakan, server harus menjawab dengan kode 405 (Method Not Allowed).. Dari semua metode di atas, hanya metode GET dan HEAD yang harus diimplementasikan oleh semua server. Jika server tidak mengimplementasikan sebuah metode atau tidak mengenal metode yang diminta client, maka server harus memberikan response 501 (Not Implemented).

Metode GET mengambil informasi apa saja dalam bentuk entity yang diidentifikasikan oleh Request-URI. Metode HEAD sama dengan metode GET kecuali bahwa server harus tidak mengirimkan entity yang ditunjukkan oleh Request-URI. Metode POST digunakan untuk meminta server menempatkan entity yang dikirim bersama request sebagai subordinat dari Request-URI yang dituju. Metode ini biasa digunakan dalam mengirimkan form.

Metode PUT meminta server untuk menempatkan entity request sebagai Request-URI. Perbedaan antara POST dan PUT adalah Request-URI dalam metode POST bertindak sebagai proses penerima data atau sebagai gateway, sementara dalam metode PUT, Request-URI adalah entity yang terdapat dalam request.

Metode DELETE meminta server untuk menghapus URI yang dikirim client. Client tidak dapat menjamin server berhasil melaksanakan request yang diminta. Metode TRACE digunakan untuk meminta loop-back pesan. Metode TRACE ini dapat digunakan untuk diagnostik.

Request-URI menunjukkan resource yang hendak diakses melalui pesan request. Request-URI dapat berupa URI absolut, path absolut, atau tanda asteriks (‘*’). Request-URI tergantung pada request itu sendiri. Tanda asteriks ‘*’ berarti bahwa request tidak merujuk pada resource tertentu, melainkan pada server. Request-URI asteriks hanya boleh digunakan jika metode yang digunakan tidak harus merujuk pada sebuah resource. Contoh:

OPTIONS * HTTP/1.1

Request-URI absolut diperlukan jika request dilakukan ke server proxy. Server proxy yang biasa digunakan squid dengan port 3128. Proxy dapat memberikan jawaban berdasarkan cache atau meneruskan request tersebut. Proxy boleh meneruskan request tersebut langsung ke server asal atau ke server proxy yang lain. Jika proxy meneruskan request ke server proxy lain, maka Request-URI tidak boleh diubah. Contoh request absolut:

GET http://www.google.co.id/index.html HTTP/1.1

Request dalam bentuk path absolut digunakan untuk menentukan resource pada server atau gateway. Jika sebuah request menggunakan Request-URI path absolut maka request juga harus mengirimkan lokasi jaringan URI dalam sebuah field header host. Dalam kasus seperti request di atas, proxy dapat menghubungi server www.google.co.id pada port 80dan mengirimkan request

GET /index.html HTTP/1.1 Host: www.google.co.id

Perhatikan bahwa dalam Request-URI path absolut informasi host tujuan juga turut disertakan. Server HTTP/1.1 harus mengetahui bahwa sebuah request ditentukan dengan melihat Request-URI dan header host. Server HTTP/1.1 yang tidak membolehkan resource berbeda untuk field Host yang berbeda dapat mengabaikan field header Host tersebut. Jika server tersebut membolehkan resource yang berbeda maka server tidak boleh mengabaikan field header Host dalam Request-URI path-absolut. Jika server tersebut menerima Request-URI absolut, maka field header Host harus diabaikan. Jika ternyata host yang dirujuk pada Request-URI absolut atau path-absolut bukan host yang valid di server, maka server harus memberikan respon kesalahan 400 (Bad Request).

Setelah baris-request, client mengirimkan request header yang berisi informasi mengenai request atau mengenai client itu sendiri ke server. Header-header tersebut adalah:

Header-request = Accept | Accept-Charset | Accept-Encoding 

              | Accept-Language | Authorization | From                     
              | Host | If-Modified-Since | If-Match
              | If-None-Match | If-Range | If-Unmodified-Since      
              | Max-Forwards | Proxy-Authorization | Range                    
              | Referer | User-Agent

Keterangan mengenai beberapa field header adalah sebagai berikut,


Field Header Keterangan Accept Menentukan tipe media yang dapat diterima sebagai respon dari server Contoh: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Accept-Charset Mengindikasikan set karakter yang dapat diterima sebagai respon Contoh: Accept-Charset: iso-8859-1,*,utf-8 Accept-Language Memperkecil jenis bahasa yang lebih disukai untuk diterima oleh client Contoh: Accept-Language: da, en-gb;q=0.8, en;q=0.7 Host Menentukan host dan port tempat resource hendak diambil. Client HTTP/1.1 harus menyertakan field ini dalam setiap request. Contoh: Host: www.google.co.id:80 If-Modified-Since Digunakan bersama metode GET memberikan kondisi bahwa jika resource yang hendak diakses belum diubah sejak waktu yang ditentukan oleh field ini, maka resource tersebut tidak akan dikirim oleh server, melainkan server memberikan response 304 (not modified) tanpa isi pesan. Contoh: If-Modified-Since: Sat, 21 Feb 2006 19:43:31 GMT User-Agent Berisi informasi mengenai user agent yang melakukan request ke server. Contoh: User-Agent: Lynx/2.7.1 libwww-FM/2.14


Contoh request lengkap yang berasal dari browser Internet Explorer 6.0 yang hendak mengakses http://www.yahoo.com

GET / HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: www.yahoo.com Connection: Keep-Alive Cookie: FPB=881h90lik11rsfl3; B=5ut53s91rs4no&b=2;

Contoh request lengkap yang berasal dari browser Opera 7.52 yang hendak mengakses http://www.google.co.id.

GET / HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.52 [en] Host: www.google.co.id Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 Accept-Language: en Accept-Charset: windows-1252, utf-8, utf-16, iso-8859-1;q=0.6, *;q=0.1 Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 Connection: Keep-Alive Response

Setelah menerima request, server harus memberikan response HTTP atas request tersebut, yang terdiri atas baris status, header-header, dan isi pesan. Baris status berisi kode-status yang berupa kode tiga digit dan frasa-alasan yaitu penjelasan singkat atas kode-status tersebut.

Digit pertama kode-status menentukan kelas dari response. Protokol HTTP/1.1 mendefinisikan 5 nilai untuk digit pertama: 1xx: Informational – request diterima, dan proses berlanjut 2xx: Success – request diterima dan dimengerti 3xx: Redirection – request membutuhkan tindakan lebih lanjut 4xx: Client Error - request mengandung sintaks yang salah 5xx: Server Error – server gagal melakukan tindakan sesuai request.

Server HTTP dapat menghasilkan kode-status selain yang didefinisikan dalam RFC sepanjang digit pertama kode-status tersebut dimengerti oleh aplikasi HTTP.

Format baris-status adalah sebagai berikut:

Baris-Status = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Setelah baris response, server HTTP mengirimkan header-header response ke client. Header ini memberikan informasi mengenai server serta mengenai akses lebih lanjut ke URI.

Header-response = Age | Location | Proxy-Authenticate 

               | Public | Retry-After | Server | Vary                    
               | Warning | WWW-Authenticate

Keterangan mengenai header-response dapat dilihat pada tabel berikut.

Field Header Keterangan Age Perkiraan lama waktu sejak response atas URI diambil dari server asal. Header ini harus digunakan oleh cache HTTP/1.1. Location Digunakan untuk mengarahkan client ke URL lain. Contoh: Location: http://www.w3c.org/pub/WWW/People.html Proxy-Authenticate Field ini memungkinkan client untuk mengirimkan identitasnya untuk menggunakan proxy yang membutuhkan autentikasi. Public Memperlihatkan jenis metode yang didukung oleh server Retry-After Dapat digunakan bersama kode-status 503 untuk menunjukkan berapa lama layanan belum dapat diberikan. Contoh: Retry-After: Fri, 31 Mar 2006 23:59:59 GMT Server Berisi informasi mengenai server yang menangani request Contoh: Server: Apache/2.0.54 (Fedora) Vary Digunakan server untuk mengirimkan sinyal bahwa entity yang dikirim adalah hasil negosiasi yang ‘server driven’. URI dengan header ini harus tidak di-cache. Warning Digunakan untuk memberi informasi tambahan selain dari kode-status. WWW-Authenticate Dikirimkan beserta kode-status 401. Terdiri atas setidaknya satu challenge yang menentukan scheme autentikasi dan parameter-parameternya.


Contoh request responds antara client dan server Fedora Core 4 yang bekerja pada IP 192.168.0.1 adalah,

Request Response HEAD /index.html HTTP/1.1 Host: 192.168.0.1 Connection: close HTTP/1.1 200 OK Date: Wed, 01 Mar 2006 04:25:51 GMT Server: Apache/2.0.54 (Fedora) Last-Modified: Wed, 01 Mar 2006 04:25:26 GMT ETag: "c3de1-870-55447980" Accept-Ranges: bytes Content-Length: 2160 Connection: close Content-Type: text/html; charset=UTF-8


HEAD / HTTP/1.1

HTTP/1.1 400 Bad Request Date: Wed, 01 Mar 2006 04:21:37 GMT Server: Apache/2.0.54 (Fedora) Connection: close Content-Type: text/html; charset=iso-8859-1



Entity

Setiap pesan HTTP baik request maupun response dapat menyertakan isi pesan atau entity tergantung dari apakah pesan tersebut memungkinkan untuk membawa entity. Entity HTTP terdiri atas header entity dan isi entity. Header entity berisi informasi mengenai isi entity atau mengenai resource yang ditunjuk oleh Request-URI.

Header-entity = Allow | Content-Base | Content-Encoding 

              | Content-Language | Content-Length | Content-Location         
              | Content-MD5 | Content-Range | Content-Type
              | ETag | Expires | Last-Modified
              | extension-header


Field Header Keterangan Allow Menunjukkan metode yang didukung oleh resource yang ditunjuk oleh Request-URI Content-Base Menentukan base URI yang digunakan untuk mengartikan URI relatif. Contoh: Content-Base: http://www.detik.com/ Content-Encoding Menentukan tipe media dan mekanisme decoding yang harus diberikan pada entity. Contoh: Content-Encoding: gzip Content-Language Menentukan bahasa yang hendak digunakan. Content-Length Menentukan panjang isi pesan dalam oktet Content-Location Menginformasikan lokasi resource dari isi pesan Content-MD5 Untuk memeriksa integritas isi entity Content-Range Digunakan untuk mengirimkan sebagian dari seluruh entity. Misal untuk mengirim 500 byte pertama dari 1234 byte: Content-Range: bytes 0-499/1234 Content-Type Menentukan tipe media isi entity yang dikirim ke penerima Etag Menentukan tag untuk entity yang bersangkutan. Digunakan untuk GET bersyarat. Expires Mengindikasikan waktu kadaluwarsa entity. Cache harus mengambil ke server asal jika waktu kadaluwarsa entity sudah terlewati. Last-Modified Mengindikasikan waktu terakhir perubahan entity.

Contoh request client yang sedang mengambil entity berbentuk file GIF

GET /status_03.gif HTTP/1.1 Accept: */* Referer: http://202.105.11.46 Accept-Language: en-us Accept-Encoding: gzip, deflate If-Modified-Since: Wed, 16 Apr 2003 00:06:10 GMT; length=195 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: 202.105.11.46 Connection: Keep-Alive Authorization: Basic YWRtaW46bjFtZDQ=


Contoh jawaban yang dikirim oleh server ke client dengan entity file gambar GIF yang terkirim bersama-nya.

HTTP/1.1 200 OK Server: Embedded HTTP Server 3.4.0 Content-Type: image/gif Content-Length: 195 Last-Modified: Tue, 16 Apr 2003 00:06:10 GMT Connection: close

GIF89a.."....[..............\............?..........A.......................ZAD.kj.....|Q...............3....,......"...H`'.di.h.....b.....v........%....#2.Y,....)M...kU[.z.....+.>..z.n....|....;

Cache HTTP

Salah satu cara untuk mempercepat response HTTP di jaringan adalah dengan menggunakan cache. Dalam protokol HTTP dimungkinkan dalam sebuah rantai request/response terdapat beberapa proxy yang dapat bertindak sebagai server cache. Spesifikasi protokol HTTP juga menyertakan elemen-elemen agar cache dapat dilakukan sebaik mungkin. Tujuan adanya cache adalah mencegah pengiriman request dan menghilangkan kebutuhan untuk mengirim response lengkap dari server. Cache mencegah pengiriman request ke server asal dengan menggunakan mekanisme kadaluwarsa sehingga memperpendek rantai request/response dan waktu round-trip. Menghilangkan kebutuhan untuk mengirim response lengkap dari server asal dengan menggunakan mekanisme validasi berarti mengurangi kebutuhan bandwidth.

Isu utama dalam cache adalah kinerja, yang diukur dalam kecepatan waktu response, dan benarnya response yang dihasilkan cache. Cache harus memberi response yang paling ‘up-to-date’ atas sebuah request, yaitu response yang telah divalidasi dengan server asal; atau masih ‘cukup segar’; atau memberikan peringatan jika ‘kesegaran’ cache dilanggar; atau response 304 (Not Modified), 305 (Proxy Redirect), atau error yang sesuai.

Mekanisme waktu kadaluwarsa dalam cache HTTP/1.1 dilakukan dengan menggunakan pendekatan heuristik. Cache menghitung umur entry URI dalam cache dan memperkirakan apakah entry tersebut sudah kadaluwarsa. Cache HTTP/1.1 menggunakan header Age dalam berkomunikasi antar cache untuk menginformasikan selang waktu sejak sebuah entri diambil dari server asal. Dengan cara ini cache dapat menghitung umur sebuah entri yang diperolehnya dari cache lain.

Jika entri dalam cache dianggap tidak ‘segar’ lagi maka cache perlu melakukan validasi ke server asal atau server cache lain yang memiliki entri cache yang masih baru. Cache mem-validasi entri dengan mengirimkan request bersyarat ke server. Jika entri tersebut tidak berubah maka server akan mengeluarkan kode-status seperti 304 (Not Modified). Jika ternyata entri berubah, server akan mengirimkan isi pesan entri tersebut secara lengkap.

Cache menggunakan header ETag dan sebagai alat memvalidasi entri URI yang utama. ETag disebut sebagai pemvalidasi kuat (strong validator) karena ETag berubah setiap kali isi pesan berubah. Parameter lain yang dapat yang digunakan sebagai alat pemvalidasi adalah waktu modifikasi terakhir. Parameter ini menunjukkan waktu terakhir entity tersebut berubah sampai hitungan detik. Parameter ini disebut sebagai pemvalidasi lemah (weak validator) karena nilainya tidak selalu berubah walaupun entity berubah (entity dapat saja berubah dua kali dalam satu detik). Dalam beberapa kasus server tidak ingin menggunakan ETag sebagai pemvalidasi kuat tersebut karena entity tidak berubah secara signifikan.

Mekanisme validasi dan waktu kadaluwarsa juga dapat diatur oleh server asal atau client melalui header Cache-Control. Header Cache-Control yang terdapat dalam pesan HTTP akan menyebabkan cache mengikuti mekanisme validasi dan kadaluwarsa yang sesuai dengan header tersebut. Client dapat memaksa cache untuk memvalidasi entri ke server asal dengan header

Cache-Control: max-age=0

atau memaksa agar mengambil entri terbaru dari server asal dengan header

Cache-Control: no-cache

Server juga dapat memaksa agar cache HTTP/1.1 selalu memvalidasi sebuah request ke server asal dengan header

Cache-Control: must-revalidate

yang dikirim beserta response atas request tersebut.

Untuk melihat bagaimana cache HTTP bekerja, di bawah ini diperlihatkan contoh request dari client melalui server proxy squid yang bekerja pada 192.168.0.1 (yc0mlc.ampr.org) port 3128. Kali pertama, client meminta URL http://www.detik.com/ melalui server cache yc0mlc.ampr.org. Isi request dari client adalah,

GET http://www.detik.com/ HTTP/1.1 Host: www.detik.com Connection: close

Header dari response server cache yang MISS adalah seperti berikut:

HTTP/1.0 200 OK Date: Wed, 01 Mar 2006 07:00:50 GMT Server: Apache/2.0.55 (Trustix Secure Linux/Linux) PHP/5.0.4 Last-Modified: Mon, 30 Jan 2006 02:51:15 GMT ETag: "13e324-235-8533cec0" Accept-Ranges: bytes Content-Length: 565 Content-Type: text/html; charset=ISO-8859-1 X-Cache: MISS from yc0mlc.ampr.org Proxy-Connection: close

<ISI PESAN RESPONSE>

Dari response yang diberikan oleh server yc0mlc.ampr.org terlihat bahwa server tersebut tidak menyimpan URL yang diminta client. Hal ini terlihat melalui header X-Cache: MISS.


Beberapa saat kemudian client kembali melakukan request atas URL yang sama. Server proxy memberikan response dan kali ini server tersebut menjawab dengan menyatakan bahwa URL tersebut tersimpan dalam cache melalui header X-Cache: HIT.

HTTP/1.0 200 OK Date: Wed, 01 Mar 2006 07:00:50 GMT Server: Apache/2.0.55 (Trustix Secure Linux/Linux) PHP/5.0.4 Last-Modified: Mon, 30 Jan 2006 02:51:15 GMT ETag: "13e324-235-8533cec0" Accept-Ranges: bytes Content-Length: 565 Content-Type: text/html; charset=ISO-8859-1 Age: 206 X-Cache: HIT from yc0mlc.ampr.org Proxy-Connection: close

<ISI PESAN RESPONSE>

Setelah selang beberapa waktu client kembali meminta URL yang sama, dan kali ini client memaksa agar server cache melakukan validasi ke server asal dengan menggunakan header Cache-Control. Request dari client adalah seperti berikut:

GET http://www.detik.com/ HTTP/1.1 Host: www.detik.com Cache-Control: max-age=0 Connection: close

Karena client memaksa server cache untuk mem-validasi URL ke server asal, maka server cache melakukan request bersyarat ke server asal tersebut. Alat validasi yang digunakan oleh server cache adalah tanggal perubahan terakhir URL, seperti request berikut:

GET / HTTP/1.0 Host: www.detik.com Via: 1.1 yc0mlc.ampr.org:3128 (squid/2.5.STABLE6) X-Forwarded-For: 192.168.0.22 Cache-Control: max-age=0 Connection: keep-alive

Setelah mendapat response dari server asal, server cache memberikan response ke client seperti berikut:


HTTP/1.0 200 OK Date: Wed, 01 Mar 2006 07:00:50 GMT Server: Apache/2.0.55 (Trustix Secure Linux/Linux) PHP/5.0.4 Last-Modified: Mon, 30 Jan 2006 02:51:15 GMT ETag: "13e324-235-8533cec0" Accept-Ranges: bytes Content-Length: 565 Content-Type: text/html; charset=ISO-8859-1 X-Cache: HIT from yc0mlc.ampr.org Proxy-Connection: close

<ISI PESAN RESPONSE>


Response yang dikeluarkan server cache menunjukkan bahwa URL tersebut tidak berasal dari cache yang disimpan server, melainkan langsung dari server asal walaupun tanggal URL terakhir diubah serta ETag tetap sama dengan response sebelumnya.





Instalasi Web Server dan Proxy Web

Web server default yang ada di Linux Fedora Core 4 adalah Apache Web server. Sementara, proxy server-nya adalah Squid. Cara mudah menginstalasi Web server Apache maupun Squid melalui fasilitas “Add Remove Applications” pada bagian System Settings yang ada di Fedora Core 4 yang berbentuk GUI.

Menjalankan Service Web dapat dilakukan melalui perintah

# chkconfig httpd on # service httpd restart

Apache Web server dapat langsung kita gunakan menggunakan konfigurasi default yang ada di /etc/httpd/. File-file HTML yang ingin kita publikasi di Web dapat diletakan di /var/www/html/.

Menjalankan Server Proxy Web dapat dilakukan menggunakan perintah

# chkconfig squid on # service squid restart

Default konfigurasi yang ada di squid tidak dapat langsung digunakan untuk keamanan. Anda perlu mengubah satu line di konfigrasi Squid /etc/squid/squid.conf, supaya

http_access allow all

konfigurasi defaultnya adalah http_access deny all, dengan membuka http_access menjadi allow all cukup berbahaya dari sisi keamanan. Sebaiknya kita melakukan hal lain yang lebih aman. Fasilitas konfigurasi yang lebih aman cukup banyak dan dapat dibaca di file konfigurasi /etc/squid/squid.conf.

Bagi anda yang ingin memblokir akses ke situs porno, situs kekerasan, situs perjudian dll. Telah tersedia SquidGuard di Fedora Core 4 yang dapat di install melalui fasilitas yang sama dengan Apache maupun Squid. SquidGuard dapat langsung di aktifkan dengan menimpakan file /etc/squid/squid.conf dengan file /etc/squid/squid-squidGuard.conf. Tentunya konfigurasi http_access allow all di atas harus di ulang kembali.

Ringkasan

Aplikasi merupakan protokol level atas dalam lapisan protokol TCP/IP. Beberapa aplikasi yang banyak digunakan adalah E-mail menggunakan POP3 dan SMTP dan Web menggunakan HTTP. 

Aplikasi-aplikasi jaringan umumnya bersifat client-server. Artinya, dalam setiap operasinya, selalu ada mesin yang bertindak sebagai server, yang tugasnya sebagai penyedia data (HTTP) atau layanan (SMTP). Komunikasi antara client dan server inilah yang diatur oleh protokol aplikasi tersebut. Ketiga protokol yang dijelaskan di atas menggunakan sistem request-response, cara yang paling umum digunakan dalam hubungan client-server. Setiap kali client mengirimkan request, server selalu terlebih dahulu memberikan baris status agar client dapat menentukan apa yang selanjutnya dilakukan terhadap response tersebut.

Perkembangan berikutnya dari SMTP dan HTTP adalah penggunaan connection caching, yaitu mengirimkan beberapa set data (mail untuk SMTP, URI untuk HTTP) sekaligus dalam satu kali hubungan TCP. Dengan menggunakan connection caching terbukti kecepatan pengiriman data lebih cepat dibandingkan tanpa connection caching.

Pranala Menarik

Retrieved from "https://onnocenter.or.id/wiki/index.php?title=TCP/IP:_Aplikasi_Internet&oldid=20596"