Anda di halaman 1dari 29

Jaringan Komputer

Jaringan Komputer

Pertemuan 3

Prodi Informatika

Outlines
 Web dan HTTP
 Cookies dan Web Cache
 Email
 DNS
 Overview Transport Layer

Prodi Informatika

if.iti.ac.id/kuliah
Jaringan Komputer

Web and HTTP

 web page terdiri objects


 object bisa HTML file, JPEG image, Java applet,
audio file,…
 web page berisi base HTML-file yang
didalamnya terdapat referenced objects
 Setiap objek memiliki alamat dengan sebuah
URL, e.g.,
www.someschool.ac.id/someDept/pic.gif

host name path name

Application
Prodi Layer 2-3
Informatika

HTTP overview
HTTP: hypertext transfer
protocol
 Web’s application layer
protocol PC running
 client/server model Firefox browser

• client: browser that


requests, receives,
(using HTTP protocol) server
and “displays” Web running
objects Apache Web
server
• server: Web server
sends (using HTTP
protocol) objects in iPhone running
response to requests Safari browser

Application
Prodi Layer 2-4
Informatika

if.iti.ac.id/kuliah
Jaringan Komputer

HTTP overview (continued)


uses TCP: HTTP is “stateless”
 client menginisiasi TCP  server tidak menyimpan
connection (creates socket) informasi tentang
permintaan klien
ke server, port 80 sebelumnya
 server menerima TCP
connection dari client aside
 Pesan HTTP (application- protocols that maintain
layer protocol messages) “state” are complex!
dipertukarkan diantara  past history (state) harus
browser (HTTP client) dan dipertahankan
Web server (HTTP server)  jika server/client crashes,
status bisa inconsistent,
 TCP connection closed sehingga harus direkonsiliasi

Application
Prodi Layer 2-5
Informatika

HTTP connections

non-persistent HTTP persistent HTTP


 paling banyak satu objek  beberapa objek dapat
yang dikirim melalui dikirim melalui
koneksi TCP, koneksi koneksi TCP tunggal
kemudian ditutup antara klien, server
 mengunduh banyak
objek memerlukan
banyak koneksi

Application
Prodi Layer 2-6
Informatika

if.iti.ac.id/kuliah
Jaringan Komputer

Non-persistent HTTP
suppose user enters URL: (contains text,
www.someSchool.edu/someDepartment/home.index references to 10
jpeg images)
1a. HTTP client inisialisasi TCP
connection ke HTTP server
(process) pada 1b. HTTP server at host
www.someSchool.edu on port www.someSchool.edu waiting
80 for TCP connection at port 80.
“accepts” connection, notifying
2. HTTP client sends HTTP request client
message (containing URL) into
TCP connection socket. 3. HTTP server receives request
Message indicates that client message, forms response
wants object message containing requested
someDepartment/home.index object, and sends message into
its socket
time
Application
Prodi Layer 2-7
Informatika

Non-persistent HTTP (cont.)

4. HTTP server closes TCP


connection.
5. HTTP client menerima response
message berisi html file, displays
html. Parsing html file, finds 10
referenced jpeg objects

time
6. Steps 1-5 repeated for each of
10 jpeg objects

Application
Prodi Layer 2-8
Informatika

if.iti.ac.id/kuliah
Jaringan Komputer

Non-persistent HTTP: response time


RTT (round trip time): waktu
untuk perjalanan paket dari
client ke server dan sebaliknya
HTTP response time:
initiate TCP
 satu RTT untuk menginisiasi connection
TCP connection RTT
 satu RTT untuk HTTP request request
dan beberapa byte pertama file
time to
dari HTTP response RTT transmit
dikembalikan file
file
 file transmission time received
 non-persistent HTTP response
time = 2RTT+ file transmission time time
time

Prodi Informatika

Persistent HTTP
non-persistent HTTP issues: persistent HTTP:
 requires 2 RTTs per object  server membiarkan
koneksi terbuka setelah
 OS overhead for each TCP mengirim respons
connection
 pesan HTTP selanjutnya
 browsers often open antara klien / server yang
parallel TCP connections to sama dikirim melalui
fetch referenced objects koneksi terbuka
 klien mengirim permintaan
segera setelah menemukan
objek yang direferensikan
 sedikitnya satu RTT untuk
semua objek yang
direferensikan
Application
Prodi Layer 2-10
Informatika

10

if.iti.ac.id/kuliah
Jaringan Komputer

HTTP request message


 Dua tipe HTTP messages: request, response
 HTTP request message:
• ASCII (human-readable format)
carriage return character
line-feed character
request line
(GET, POST, GET /index.html HTTP/1.1\r\n
HEAD commands) Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
header Accept-Language: en-us,en;q=0.5\r\n
lines Accept-Encoding: gzip,deflate\r\n
carriage return, Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
line feed at start Keep-Alive: 115\r\n
Connection: keep-alive\r\n
of line indicates \r\n
end of header lines

* Check out the online interactive exercises for more


examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Application 2-11
Prodi Layer
Informatika

11

HTTP request message: general format

method sp URL sp version cr lf request


line
header field name value cr lf
header
~
~ ~
~ lines

header field name value cr lf


cr lf

~
~ entity body ~
~ body

Application
Prodi Layer 2-12
Informatika

12

if.iti.ac.id/kuliah
Jaringan Komputer

Uploading form input


POST method:
 web page often includes
form input
 input is uploaded to server
in entity body
URL method:
 uses GET method
 input is uploaded in URL
field of request line:
www.somesite.com/animalsearch?monkeys&banana

Application
Prodi Layer 2-13
Informatika

13

Method types
HTTP/1.1:
HTTP/1.0:
 GET, POST, HEAD
 GET
 PUT
 POST
• uploads file in entity
 HEAD body to path specified
• asks server to leave in URL field
requested object out of  DELETE
response
• deletes file specified in
the URL field

Application
Prodi Layer 2-14
Informatika

14

if.iti.ac.id/kuliah
Jaringan Komputer

HTTP response message

status line
(protocol
status code HTTP/1.1 200 OK\r\n
status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02
GMT\r\n
header ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
lines Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-
1\r\n
data, e.g., \r\n
requested data data data data data ...
HTML file

* Check out the online interactive exercises for more


examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Application 2-15
Prodi Layer
Informatika

15

HTTP response status codes

 kode status muncul di baris pertama dalam


pesan respons server-ke-klien.
 beberapa kode contoh:
200 OK
• request succeeded, requested object later in this msg
301 Moved Permanently
• requested object moved, new location specified later in this msg
(Location:)
400 Bad Request
• request msg not understood by server
404 Not Found
• requested document not found on this server
505 HTTP Version Not Supported
Application
Prodi Layer 2-16
Informatika

16

if.iti.ac.id/kuliah
Jaringan Komputer

User-server state: cookies


Banyak website menggunakan example:
cookies
four components:  Susan always access Internet
from PC
1) cookie header line of
HTTP response message  visits specific e-commerce
site for first time
2) cookie header line in
next HTTP request  when initial HTTP requests
message arrives at site, site creates:
3) cookie file kept on user’s • unique ID
host, managed by user’s
browser • entry in backend
database for ID
4) back-end database at
Web site

Application
Prodi Layer 2-17
Informatika

17

Cookies: keeping “state” (cont.)


client server

ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response
set-cookie: 1678 1678 for user create backend
ebay 8734 entry database
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
usual http response msg action

one week later:


access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
specific
usual http response msg action
Application
Prodi Layer 2-18
Informatika

18

if.iti.ac.id/kuliah
Jaringan Komputer

Cookies (continued)
aside
what cookies can be cookies and privacy:
used for:
 cookies permit sites to
 authorization learn a lot about you
 shopping carts  you may supply name and
 recommendations e-mail to sites
 user session state (Web e-
mail)
how to keep “state”:
 protocol endpoints: maintain state at
sender/receiver over multiple
transactions
 cookies: http messages carry state

Application
Prodi Layer 2-19
Informatika

19

Web caches (proxy server)


goal: satisfy client request without involving origin server
 user sets browser: Web
accesses via cache
 browser sends all HTTP proxy
requests to cache server
client
origin
• object in cache: cache server
returns object
• else cache requests
object from origin
server, then returns
object to client client origin
server

Application
Prodi Layer 2-20
Informatika

20

if.iti.ac.id/kuliah
Jaringan Komputer

More about Web caching

 cache acts as both why Web caching?


client and server  reduce response time
• server for original for client request
requesting client
• client to origin server  reduce traffic on an
 typically cache is institution’s access link
installed by ISP  Internet dense with
(university, company, caches: enables “poor”
residential ISP) content providers to
effectively deliver
content (so too does P2P
file sharing)
Application
Prodi Layer 2-21
Informatika

21

Caching example:
assumptions:
 avg object size: 100K bits
 avg request rate from browsers origin
to origin servers:15/sec servers
public
 avg data rate to browsers: 1.50 Internet
Mbps
 RTT from institutional router to
any origin server: 2 sec
1.54 Mbps
 access link rate: 1.54 Mbps access link
consequences: institutional
problem!
 LAN utilization: 15% network
1 Gbps LAN
 access link utilization = 99%
 total delay = Internet delay +
access delay + LAN delay
= 2 sec + minutes + usecs
Application
Prodi Layer 2-22
Informatika

22

if.iti.ac.id/kuliah
Jaringan Komputer

Caching example: fatter access link


assumptions:
 avg object size: 100K bits
 avg request rate from browsers to origin origin
servers:15/sec servers
 avg data rate to browsers: 1.50 Mbps public
Internet
 RTT from institutional router to any
origin server: 2 sec
 access link rate: 1.54 Mbps
154 Mbps
consequences: 1.54 Mbps
 LAN utilization: 15% 154 Mbps
access link
 access link utilization = 99% 9.9% institutional
 total delay = Internet delay + access network
delay + LAN delay 1 Gbps LAN
= 2 sec + minutes + usecs
msecs

Cost: increased access link speed (not cheap!)


Application
Prodi Layer 2-23
Informatika

23

Caching example: install local cache


assumptions:
 avg object size: 100K bits origin
 avg request rate from browsers to servers
origin servers:15/sec public
 avg data rate to browsers: 1.50 Mbps Internet
 RTT from institutional router to any
origin server: 2 sec
 access link rate: 1.54 Mbps 1.54 Mbps
access link
consequences:
 LAN utilization: 15% institutional
access link utilization = 100% network
 ? 1 Gbps LAN
 ?
total delay = Internet delay + access
delay + LAN delay local web
How to compute link
= 2 sec + minutes + usecs cache
utilization, delay?
Cost: web cache (cheap!)
Application
Prodi Layer 2-24
Informatika

24

if.iti.ac.id/kuliah
Jaringan Komputer

Caching example: install local cache


Calculating access link utilization, delay
with cache:
 suppose cache hit rate is 0.4 origin
servers
• 40% requests satisfied at cache, public
60% requests satisfied at origin Internet

 access link utilization:


 60% of requests use access link
 data rate to browsers over access link 1.54 Mbps
= 0.6*1.50 Mbps = .9 Mbps access link
 utilization = 0.9/1.54 = .58 institutional
network
1 Gbps LAN
 total delay
 = 0.6 * (delay from origin servers) +0.4 local web
* (delay when satisfied at cache) cache
 = 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs
 less than with 154 Mbps link (and
cheaper too!)
Application
Prodi Layer 2-25
Informatika

25

Electronic mail
outgoing
message queue
user mailbox
Three major components: user
agent
 user agents
 mail servers mail user
server agent
 simple mail transfer protocol:
SMTP SMTP mail user
server agent
User Agent
SMTP
 a.k.a. “mail reader”
 composing, editing, reading mail SMTP user
agent
mail
messages
server
 e.g., Outlook, Thunderbird, user
iPhone mail client agent

 outgoing, incoming messages user


agent
stored on server

Application
Prodi Layer 2-26
Informatika

26

if.iti.ac.id/kuliah
Jaringan Komputer

Electronic mail: mail servers

mail servers: user


agent
 mailbox contains incoming mail
messages for user server
user
agent
 message queue of SMTP mail user
outgoing (to be sent) mail server agent
messages SMTP
 SMTP protocol between
mail servers to send email SMTP user
agent
mail
messages server
user
• client: sending mail agent
server user
agent
• “server”: receiving mail
server
Application
Prodi Layer 2-27
Informatika

27

Electronic Mail: SMTP [RFC 2821]

 uses TCP to reliably transfer email message from client


to server, port 25
 direct transfer: sending server to receiving server
 three phases of transfer
• handshaking (greeting)
• transfer of messages
• closure
 command/response interaction (like HTTP)
• commands: ASCII text
• response: status code and phrase
 messages must be in 7-bit ASCI
Application
Prodi Layer 2-28
Informatika

28

if.iti.ac.id/kuliah
Jaringan Komputer

Scenario: Alice sends message to Bob

1) Alice uses UA to compose 4) SMTP client sends Alice’s


message “to” message over the TCP
bob@someschool.edu connection
2) Alice’s UA sends message to 5) Bob’s mail server places the
her mail server; message message in Bob’s mailbox
placed in message queue 6) Bob invokes his user agent to
3) client side of SMTP opens read message
TCP connection with Bob’s
mail server

1 user mail user


mail agent
agent server server
2 3 6
4
5
Alice’s mail server Bob’s mail server
Application
Prodi Layer 2-29
Informatika

29

Sample SMTP interaction


S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

Application
Prodi Layer 2-30
Informatika

30

if.iti.ac.id/kuliah
Jaringan Komputer

SMTP: final words

 SMTP uses persistent comparison with HTTP:


connections
 HTTP: pull
 SMTP requires message
(header & body) to be in  SMTP: push
7-bit ASCII
 both have ASCII
 SMTP server uses command/response
CRLF.CRLF to interaction, status codes
determine end of
message  HTTP: each object
encapsulated in its own
response message
 SMTP: multiple objects
sent in multipart message
Application
Prodi Layer 2-31
Informatika

31

Mail message format


SMTP: protocol for
exchanging email
messages
header
RFC 822: standard for text blank
message format: line

 header lines, e.g.,


• To: body
• From:
• Subject:
different from SMTP MAIL
FROM, RCPT TO:
commands!
 Body: the “message”
• ASCII characters only
Application
Prodi Layer 2-32
Informatika

32

if.iti.ac.id/kuliah
Jaringan Komputer

Mail access protocols

user
mail access user
SMTP SMTP protocol agent
agent
(e.g., POP,
IMAP)

sender’s mail receiver’s mail


server server

 SMTP: delivery/storage to receiver’s server


 mail access protocol: retrieval from server
• POP: Post Office Protocol [RFC 1939]: authorization,
download
• IMAP: Internet Mail Access Protocol [RFC 1730]: more
features, including manipulation of stored messages on
server
• HTTP: gmail, Hotmail, Yahoo! Mail, etc.
Application
Prodi Layer 2-33
Informatika

33

POP3 protocol
S: +OK POP3 server ready
C: user bob
authorization phase S: +OK
C: pass hungry
 client commands: S: +OK user successfully logged on

• user: declare username C: list


• pass: password S: 1 498
S: 2 912
 server responses S: .
• +OK C: retr 1
S: <message 1 contents>
• -ERR S: .
transaction phase, client: C: dele 1
C: retr 2
 list: list message numbers S: <message 1 contents>
S: .
 retr: retrieve message by
C: dele 2
number C: quit
 dele: delete S: +OK POP3 server signing off
 quit Application
Prodi Layer 2-34
Informatika

34

if.iti.ac.id/kuliah
Jaringan Komputer

POP3 (more) and IMAP

more about POP3 IMAP


 previous example uses  keeps all messages in one
POP3 “download and place: at server
delete” mode
 allows user to organize
• Bob cannot re-read e- messages in folders
mail if he changes client
 keeps user state across
 POP3 “download-and- sessions:
keep”: copies of messages
on different clients • names of folders and
mappings between
 POP3 is stateless across message IDs and folder
sessions name

Application
Prodi Layer 2-35
Informatika

35

DNS: domain name system

people: many identifiers: Domain Name System:


• SSN, name, passport #  distributed database
Internet hosts, routers: implemented in hierarchy of
many name servers
• IP address (32 bit) -
used for addressing  application-layer protocol:
datagrams hosts, name servers
communicate to resolve
• “name”, e.g., names (address/name
www.yahoo.com - used translation)
by humans
• note: core Internet function,
Q: how to map between IP implemented as application-
address and name, and layer protocol
vice versa ? • complexity at network’s
“edge” Application Layer 2-36
Prodi Informatika

36

if.iti.ac.id/kuliah
Jaringan Komputer

DNS: services, structure

DNS services why not centralize DNS?


 hostname to IP address  single point of failure
translation  traffic volume
 host aliasing  distant centralized database
• canonical, alias names
 maintenance
 mail server aliasing
 load distribution A: doesn‘t scale!
• replicated Web servers:
many IP addresses
correspond to one
name

Application
Prodi Layer 2-37
Informatika

37

DNS: a distributed, hierarchical database

Root DNS Servers

… …

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu


yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers DNS servers

client wants IP for www.amazon.com; 1st approximation:


 client queries root server to find com DNS server
 client queries .com DNS server to get amazon.com DNS server
 client queries amazon.com DNS server to get IP address for
www.amazon.com

Prodi Informatika

38

if.iti.ac.id/kuliah
Jaringan Komputer

DNS: root name servers

 contacted by local name server that can not resolve name


 root name server:
• contacts authoritative name server if name mapping not known
• gets mapping
• returns mapping to local name server
c. Cogent, Herndon, VA (5 other sites)
d. U Maryland College Park, MD k. RIPE London (17 other sites)
h. ARL Aberdeen, MD
j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites)

e. NASA Mt View, CA m. WIDE Tokyo


f. Internet Software C. (5 other sites)
Palo Alto, CA (and 48 other
sites)

a. Verisign, Los Angeles CA


13 logical root name
(5 other sites)
b. USC-ISI Marina del Rey, CA
“servers” worldwide
l. ICANN Los Angeles, CA •each “server” replicated
(41 other sites)
g. US DoD Columbus, many times
OH (5 other sites)

Application
Prodi Layer 2-39
Informatika

39

TLD, authoritative servers

top-level domain (TLD) servers:


• responsible for com, org, net, edu, aero, jobs,
museums, and all top-level country domains, e.g.: uk,
fr, ca, jp
• Network Solutions maintains servers for .com TLD
• Educause for .edu TLD
authoritative DNS servers:
• organization’s own DNS server(s), providing
authoritative hostname to IP mappings for
organization’s named hosts
• can be maintained by organization or serviceApplication
provider Layer 2-40 Prodi Informatika

40

if.iti.ac.id/kuliah
Jaringan Komputer

Local DNS name server


 does not strictly belong to hierarchy
 each ISP (residential ISP, company, university) has
one
• also called “default name server”
 when host makes DNS query, query is sent to its
local DNS server
• has local cache of recent name-to-address translation
pairs (but may be out of date!)
• acts as proxy, forwards query into hierarchy

Application
Prodi Layer 2-41
Informatika

41

DNS name root DNS server


resolution example
2
 host at cis.poly.edu 3
TLD DNS server
wants IP address for 4
gaia.cs.umass.edu
5

local DNS server


iterated query: dns.poly.edu
 contacted server 7 6
1 8
replies with name of
server to contact
authoritative DNS server
 “I don’t know this dns.cs.umass.edu
name, but ask this requesting host
cis.poly.edu
server”
gaia.cs.umass.edu

Application
Prodi Layer 2-42
Informatika

42

if.iti.ac.id/kuliah
Jaringan Komputer

DNS name root DNS server


resolution example
2 3
7
recursive query: 6
 puts burden of name TLD DNS
server
resolution on
contacted name local DNS server
server dns.poly.edu 5 4

 heavy load at upper 1 8


levels of hierarchy?
authoritative DNS server
dns.cs.umass.edu
requesting host
cis.poly.edu

gaia.cs.umass.edu

Application
Prodi Layer 2-43
Informatika

43

DNS: caching, updating records

 once (any) name server learns mapping, it caches


mapping
• cache entries timeout (disappear) after some time (TTL)
• TLD servers typically cached in local name servers
thus root name servers not often visited

 cached entries may be out-of-date (best effort


name-to-address translation!)
• if name host changes IP address, may not be known
Internet-wide until all TTLs expire
 update/notify mechanisms proposed IETF standard
• RFC 2136
Application
Prodi Layer 2-44
Informatika

44

if.iti.ac.id/kuliah
Jaringan Komputer

DNS records
DNS: distributed database storing resource records (RR)
RR format: (name, value, type, ttl)

type=A type=CNAME
 name is hostname  name is alias name for some
 value is IP address “canonical” (the real) name
type=NS  www.ibm.com is really
servereast.backup2.ibm.com
• name is domain (e.g.,
foo.com)  value is canonical name

• value is hostname of type=MX


authoritative name server
for this domain  value is name of mailserver
associated with name

Application
Prodi Layer 2-45
Informatika

45

DNS protocol, messages


 query and reply messages, both with same
message format 2 bytes 2 bytes

message header identification flags


 identification: 16 bit # for
# questions # answer RRs
query, reply to query
# authority RRs # additional RRs
uses same #
 flags: questions (variable # of questions)

 query or reply
answers (variable # of RRs)
 recursion desired
 recursion available authority (variable # of RRs)
 reply is authoritative
additional info (variable # of RRs)

Application
Prodi Layer 2-46
Informatika

46

if.iti.ac.id/kuliah
Jaringan Komputer

DNS protocol, messages

2 bytes 2 bytes

identification flags

# questions # answer RRs

# authority RRs # additional RRs

name, type fields


questions (variable # of questions)
for a query
RRs in response answers (variable # of RRs)
to query
records for
authority (variable # of RRs)
authoritative servers
additional “helpful” additional info (variable # of RRs)
info that may be used
Application
Prodi Layer 2-47
Informatika

47

Transport Layer

our goals:
 understand  learn about Internet
principles behind transport layer protocols:
transport layer • UDP: connectionless
services: transport
• multiplexing, • TCP: connection-oriented
demultiplexing reliable transport
• reliable data transfer • TCP congestion control
• flow control
• congestion control

Transport
Prodi Layer 3-48
Informatika

48

if.iti.ac.id/kuliah
Jaringan Komputer

Transport services and protocols


 provide logical communication application
between app processes transport
network
running on different hosts data link
physical

 transport protocols run in end


systems
• send side: breaks app
messages into segments,
passes to network layer
• rcv side: reassembles
segments into messages, application
passes to app layer transport
network
data link
 more than one transport physical

protocol available to apps


• Internet: TCP and UDP

Transport
Prodi Layer 3-49
Informatika

49

Transport vs. network layer

 network layer: household analogy:


logical
communication 12 kids in Ann’s house sending
letters to 12 kids in Bill’s
between hosts house:
 transport layer:  hosts = houses
logical  processes = kids
communication  app messages = letters in
between processes envelopes
• relies on, enhances,  transport protocol = Ann
and Bill who demux to in-
network layer house siblings
services
 network-layer protocol =
postal service

Transport
Prodi Layer 3-50
Informatika

50

if.iti.ac.id/kuliah
Jaringan Komputer

Internet transport-layer protocols


 reliable, in-order delivery application
transport
(TCP) network
data link
physical
• congestion control network
network
data link
data link physical

• flow control physical


network
data link
physical
• connection setup network
data link
 unreliable, unordered physical

delivery: UDP
network
data link
physical
network
• no-frills extension of data link
physical
application
transport
“best-effort” IP
network
data link network
physical data link
physical
 services not available:
• delay guarantees
• bandwidth guarantees
Transport
Prodi Layer 3-51
Informatika

51

Multiplexing/demultiplexing

multiplexing at sender:
handle data from multiple demultiplexing at receiver:
sockets, add transport header use header info to deliver
(later used for demultiplexing) received segments to correct
socket

application

application
P1 P2 application

P3 P4
socket
transport process
transport network transport
network link network
link physical link
physical physical

Transport
Prodi Layer 3-52
Informatika

52

if.iti.ac.id/kuliah
Jaringan Komputer

How demultiplexing works


 host receives IP datagrams
32 bits
• each datagram has source IP
address, destination IP source port # dest port #
address
• each datagram carries one other header fields
transport-layer segment
• each segment has source, application
destination port number data
(payload)
 host uses IP addresses &
port numbers to direct
segment to appropriate TCP/UDP segment format
socket
Transport
Prodi Layer 3-53
Informatika

53

Connectionless demultiplexing

 recall: created socket has  recall: when creating


host-local port #: datagram to send into UDP
DatagramSocket mySocket1 socket, must specify
= new DatagramSocket(12534); • destination IP address
• destination port #

 when host receives UDP IP datagrams with same


segment: dest. port #, but different
source IP addresses
• checks destination port # and/or source port
in segment numbers will be directed
• directs UDP segment to to same socket at dest
socket with that port #
Transport
Prodi Layer 3-54
Informatika

54

if.iti.ac.id/kuliah
Jaringan Komputer

Connectionless demux: example


DatagramSocket
DatagramSocket serverSocket = new
DatagramSocket
mySocket2 = new DatagramSocket mySocket1 = new
DatagramSocket DatagramSocket
(6428);
(9157); application (5775);
application

P3 P1 application

P4
transport
transport transport
network
network link network
link physical link
physical physical

source port: 6428 source port: ?


dest port: 9157 dest port: ?

source port: 9157 source port: ?


dest port: 6428 dest port: ?
Transport
Prodi Layer 3-55
Informatika

55

Connection-oriented demux

 TCP socket identified  server host may support


by 4-tuple: many simultaneous TCP
• source IP address sockets:
• source port number • each socket identified by
its own 4-tuple
• dest IP address
 web servers have
• dest port number
different sockets for
 demux: receiver uses each connecting client
all four values to direct • non-persistent HTTP will
segment to have different socket for
appropriate socket each request

Transport
Prodi Layer 3-56
Informatika

56

if.iti.ac.id/kuliah
Jaringan Komputer

Connection-oriented demux:
example
application
application

P3 P4P5P6 application

P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP


address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets Transport 3-57
Prodi Layer
Informatika

57

Connection-oriented demux:
example
threaded server
application

P4
application application

P3 transport
P2 P3
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP


address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80

Transport
Prodi Layer 3-58
Informatika

58

if.iti.ac.id/kuliah