View
221
Download
1
Category
Tags:
Preview:
Citation preview
Basic Philosophy of TCP/IPBasic Philosophy of TCP/IP
Simple core, complex edge Edge can be hosts, edge routers, network boundaries, etc. Why? Scalable, flexibility for different complexities at edge
Internet ArchitectureInternet Architecture
Mesh of separate networks connected at exchange points Tier 1 providers carry full Internet routing tables no defaults Tier 2+ providers carry subset and point to upstream default
Transport services and protocolsTransport services and protocols
provide logical communication between app processes running on different hosts
transport protocols run in end systems send side: breaks app
messages into segments, passes to network layer
rcv side: reassembles segments into messages, passes to app layer
more than one transport protocol available to apps Internet: TCP and UDP
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
Transport vs. network layerTransport vs. network layer
network layer: logical communication between hosts
transport layer: logical communication between processes relies on, enhances,
network layer services
Household analogy:
12 kids sending letters to 12 kids
processes = kids app messages =
letters in envelopes hosts = houses transport protocol =
Ann and Bill network-layer protocol
= postal service
Internet transport-layer protocolsInternet transport-layer protocols
reliable, in-order delivery (TCP) congestion control flow control connection setup
unreliable, unordered delivery: UDP no-frills extension of “best-
effort” IP
services not available: delay guarantees bandwidth guarantees
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
UDP: User Datagram ProtocolUDP: User Datagram Protocol
“no frills,” “bare bones” Internet transport protocol
“best effort” service, UDP segments may be: lost delivered out of order to
app
connectionless: no handshaking between
UDP sender, receiver each UDP segment
handled independently of others
Why is there a UDP? no connection
establishment (which can add delay)
simple: no connection state at sender, receiver
small segment header no congestion control:
UDP can blast away as fast as desired
UDP: moreUDP: more
often used for streaming multimedia apps loss tolerant rate sensitive
other UDP uses DNS SNMP
reliable transfer over UDP: add reliability at application layer application-specific error
recovery!
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksumLength, in
bytes of UDPsegment,including
header
TCP OverviewTCP Overview
full duplex data: bi-directional data flow in
same connection MSS: maximum segment
size
connection-oriented: handshaking (exchange of
control msgs) init’s sender, receiver state before data exchange
flow controlled: sender will not overwhelm
receiver
point-to-point: one sender, one receiver
reliable, in-order byte steam: no “message boundaries”
pipelined: TCP congestion and flow
control set window size
send & receive buffers
socketdoor
T C Psend buffer
T C Preceive buffer
socketdoor
segm ent
applicationwrites data
applicationreads data
TCP segment structureTCP segment structure
source port # dest port #
32 bits
applicationdata
(variable length)
sequence number
acknowledgement numberReceive window
Urg data pnterchecksum
FSRPAUheadlen
notused
Options (variable length)
URG: urgent data (generally not used)
ACK: ACK #valid
PSH: push data now(generally not used)
RST, SYN, FIN:connection estab(setup, teardown
commands)
# bytes rcvr willingto accept
countingby bytes of data(not segments!)
Internetchecksum
(as in UDP)
Reliable TrReliable Transfer in TCPansfer in TCP
Host A Host B
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
Usertypes
‘C’
host ACKsreceipt
of echoed‘C’
host ACKsreceipt of
‘C’, echoesback ‘C’
timesimple telnet scenario
Sliding Window
TCP Connection Setup and TeardownTCP Connection Setup and Teardown Establishment: Three-Way Handshake
Termination
Sliding WindowSliding Window
Each byte has a sequence number ACKs are cumulative Sending side
LastByteAcked LastByteSent LastByteWritten Bytes between LastByteAcked and LastByteWritten must be buffered
Receiving side
NextByteRead < NextByteExpected LastByteRcvd + 1 Bytes between NextByteRead and LastByteRcvd must be buffered
NextByteRead
TIME_WAIT StateTIME_WAIT State
MSL: maximum segment lifetime 30 sec in BSD-derived implementation 2 min in RFC 1122
Reason for the TIME-WAIT state(waiting for 2MSL) to implement TCP’s full-duplex connection termination
reliably termination 중에 lost, duplicated packet 문제를 해결하기
위해 to allow old duplicate segments to expire in the
network 같은 host 의 같은 port 로 연결되는 next TCP connection 에
그전 session 의 packet 을 제거하기 위해
Multiplexing/demultiplexingMultiplexing/demultiplexing
application
transport
network
link
physical
P1 application
transport
network
link
physical
application
transport
network
link
physical
P2P3 P4P1
host 1 host 2 host 3
= process= socket
delivering received segmentsto correct socket
Demultiplexing at rcv host:gathering data from multiplesockets, enveloping data with header (later used for demultiplexing)
Multiplexing at send host:
How demultiplexing worksHow demultiplexing works
host receives IP datagrams each datagram has
source IP address, destination IP address
each datagram carries 1 transport-layer segment
each segment has source, destination port number (recall: well-known port numbers for specific applications)
host uses IP addresses & port numbers to direct segment to appropriate socket
source port # dest port #
32 bits
applicationdata
(message)
other header fields
TCP/UDP segment format
Connectionless demultiplexingConnectionless demultiplexing
Create sockets with port numbers:
DatagramSocket mySocket1 = new DatagramSocket(99111);
DatagramSocket mySocket2 = new DatagramSocket(99222);
UDP socket identified by two-tuple:
(dest IP address, dest port number)
When host receives UDP segment: checks destination port
number in segment directs UDP segment to
socket with that port number
IP datagrams with different source IP addresses and/or source port numbers directed to same socket
Connectionless demux (cont)Connectionless demux (cont)
DatagramSocket serverSocket = new DatagramSocket(6428);
ClientIP:B
P2
client IP: A
P1P1P3
serverIP: C
SP: 6428
DP: 9157
SP: 9157
DP: 6428
SP: 6428
DP: 5775
SP: 5775
DP: 6428
SP provides “return address”
Connection-oriented demuxConnection-oriented demux
TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number
recv host uses all four values to direct segment to appropriate socket
Server host may support many simultaneous TCP sockets: each socket identified by
its own 4-tuple
Web servers have different sockets for each connecting client non-persistent HTTP will
have different socket for each request
Connection-oriented demux (cont)Connection-oriented demux (cont)
ClientIP:B
P1
client IP: A
P1P2P4
serverIP: C
SP: 9157
DP: 80
SP: 9157
DP: 80
P5 P6 P3
D-IP:CS-IP: A
D-IP:C
S-IP: B
SP: 5775
DP: 80
D-IP:CS-IP: B
Connection-oriented demux: Connection-oriented demux: Threaded Web ServerThreaded Web Server
ClientIP:B
P1
client IP: A
P1P2
serverIP: C
SP: 9157
DP: 80
SP: 9157
DP: 80
P4 P3
D-IP:CS-IP: A
D-IP:C
S-IP: B
SP: 5775
DP: 80
D-IP:CS-IP: B
Socket programmingSocket programming
Socket API introduced in BSD4.1 UNIX,
1981 explicitly created, used,
released by apps client/server paradigm two types of transport service
via socket API: unreliable datagram reliable, byte stream-
oriented
a host-local, application-created,
OS-controlled interface (a “door”) into which
application process can both send and
receive messages to/from another
application process
socket
Goal: learn how to build client/server application that communicate using sockets
Socket-programming using TCPSocket-programming using TCP
Socket: a door between application process and end-end-transport protocol (UCP or TCP)
TCP service: reliable transfer of bytes from one process to another
process
TCP withbuffers,
variables
socket
controlled byapplicationdeveloper
controlled byoperating
system
host orserver
process
TCP withbuffers,
variables
socket
controlled byapplicationdeveloper
controlled byoperatingsystem
host orserver
internet
Socket programming Socket programming with TCPwith TCP
Client must contact server server process must first
be running server must have created
socket (door) that welcomes client’s contact
Client contacts server by: creating client-local TCP
socket specifying IP address, port
number of server process When client creates
socket: client TCP establishes connection to server TCP
When contacted by client, server TCP creates new socket for server process to communicate with client allows server to talk with
multiple clients source port numbers
used to distinguish clients (more in Chap 3)
TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server
application viewpoint
TCP Port Numbers and Concurrent Servers (1)TCP Port Numbers and Concurrent Servers (1)
foreignlocal
?21
?0
foreignlocal
150021
206.168.112.21912.106.32.254
foreignlocal
?21
?0
foreignlocal
?21
?0
foreignlocal
211500
12.106.32.254206.168.112.219
foreignlocal
211500
12.106.32.254206.168.112.219
TCP Port Numbers and Concurrent Servers (2)TCP Port Numbers and Concurrent Servers (2)
foreignlocal
150021
206.168.112.21912.106.32.254
foreignlocal
021
00
foreignlocal
150121
206.168.112.21912.106.32.254
foreignlocal
211500
12.106.32.254206.168.112.219
foreignlocal
211501
12.106.32.254206.168.112.219
TCP OutputTCP Output
Successful return from write means that we can reuse application buffer
TCP must keep a copy of our data in the socket send buffer until ACK is received.
UDP OutputUDP Output
Successful return from write means that the datagram or fragments of the datagram have been added to the datalink output queue
Buffer Size and LimitationBuffer Size and Limitation Max. size of IP datagram
IPv4: 65535 bytes including header(20 bytes) IPv6: 65535 bytes(payload) + 40 bytes(header)
MTU (Max. Transmission Unit) Network 이 전달해 줄 수 있는 최대 payload 크기 (Ethernet 에서 1500
bytes) path MTU: the smallest MTU in the path between two hosts
Fragmentation is performed if datagram size > link MTU
In IPv4: by host or router, IPv6: only by host DF bit in IPv4 header
may be used for path MTU discovery Min. reassembly buffer size (guaranteed by any implementation)
576 bytes in IPv4, 1500 bytes in IPv6 MSS (Max. Segment Size): max TCP payload size to avoid IP
fragmentation In Ethernet, MSS = MTU(1500) – IP header(20 or 40) – TCP header(20)
= 1460 B (IPv4) or 1440 B (IPv6)
Standard Internet ServicesStandard Internet Services
See /etc/services Services running on TCP or UDP
Distinguished by protocol and port number A Service is a symbolic representation of port number
Recommended