Transport Layer (TCP/UDP) Where we are in the Course Moving on up - - PowerPoint PPT Presentation

transport layer tcp udp where we are in the course
SMART_READER_LITE
LIVE PREVIEW

Transport Layer (TCP/UDP) Where we are in the Course Moving on up - - PowerPoint PPT Presentation

Transport Layer (TCP/UDP) Where we are in the Course Moving on up to the Transport Layer! Application Transport Network Link Physical CSE 461 University of Washington 2 Recall Transport layer provides end-to-end connectivity across


slide-1
SLIDE 1

Transport Layer (TCP/UDP)

slide-2
SLIDE 2

Where we are in the Course

  • Moving on up to the Transport Layer!

CSE 461 University of Washington 2

Physical Link Network Transport Application

slide-3
SLIDE 3

Recall

  • Transport layer provides end-to-end connectivity

across the network

CSE 461 University of Washington 3

Router Host Host

TCP IP 802.11 app IP 802.11 IP Ethernet TCP IP Ethernet app

slide-4
SLIDE 4

Recall (2)

  • Segments carry application data across the network
  • Segments are carried within packets within frames

CSE 461 University of Washington 4

802.11 IP TCP App, e.g., HTTP Segment Packet Frame

slide-5
SLIDE 5

Transport Layer Services

  • Provide different kinds of data delivery across the

network to applications

CSE 461 University of Washington 5

Unreliable Reliable Messages Datagrams (UDP) Bytestream Streams (TCP)

slide-6
SLIDE 6

Comparison of Internet Transports

  • TCP is full-featured, UDP is a glorified packet

CSE 461 University of Washington 6

TCP (Streams) UDP (Datagrams) Connections Datagrams Bytes are delivered once, reliably, and in order Messages may be lost, reordered, duplicated Arbitrary length content Limited message size Flow control matches sender to receiver Can send regardless

  • f receiver state

Congestion control matches sender to network Can send regardless

  • f network state
slide-7
SLIDE 7

Socket API

  • Simple abstraction to use the network
  • The “network” API (really Transport service) used to write

all Internet apps

  • Part of all major OSes and languages; originally Berkeley

(Unix) ~1983

  • Supports both Internet transport services (Streams

and Datagrams)

CSE 461 University of Washington 7

slide-8
SLIDE 8

Socket API (2)

  • Sockets let apps attach to the local network at

different ports

CSE 461 University of Washington 8

Socket, Port #1 Socket, Port #2

slide-9
SLIDE 9

Socket API (3)

  • Same API used for Streams and Datagrams

CSE 461 University of Washington 9

Primitive Meaning SOCKET Create a new communication endpoint BIND Associate a local address (port) with a socket LISTEN Announce willingness to accept connections ACCEPT Passively establish an incoming connection CONNECT Actively attempt to establish a connection SEND(TO) Send some data over the socket RECEIVE(FROM) Receive some data over the socket CLOSE Release the socket

Only needed for Streams To/From for Datagrams

slide-10
SLIDE 10

Ports

  • Application process is identified by the tuple IP

address, protocol, and port

  • Ports are 16-bit integers representing local “mailboxes”

that a process leases

  • Servers often bind to “well-known ports”
  • <1024, require administrative privileges
  • Clients often assigned “ephemeral” ports
  • Chosen by OS, used temporarily

CSE 461 University of Washington 10

slide-11
SLIDE 11

Some Well-Known Ports

CSE 461 University of Washington 11

Port Protocol Use 20, 21 FTP File transfer 22 SSH Remote login, replacement for Telnet 25 SMTP Email 80 HTTP World Wide Web 110 POP-3 Remote email access 143 IMAP Remote email access 443 HTTPS Secure Web (HTTP over SSL/TLS) 543 RTSP Media player control 631 IPP Printer sharing

slide-12
SLIDE 12

Topics

  • Service models
  • Socket API and ports
  • Datagrams, Streams
  • User Datagram Protocol (UDP)
  • Connections (TCP)
  • Sliding Window (TCP)
  • Flow control (TCP)
  • Retransmission timers (TCP)
  • Congestion control (TCP)

CSE 461 University of Washington 12

slide-13
SLIDE 13

UDP

slide-14
SLIDE 14

User Datagram Protocol (UDP)

  • Used by apps that don’t want reliability or

bytestreams

  • Voice-over-IP
  • DNS, RPC
  • DHCP

(If application wants reliability and messages then it has work to do!)

CSE 461 University of Washington 14

slide-15
SLIDE 15

Datagram Sockets

CSE 461 University of Washington 15

Client (host 1) Server (host 2)

Time

request reply

slide-16
SLIDE 16

Datagram Sockets (2)

CSE 461 University of Washington 16

Client (host 1) Server (host 2)

Time

1: socket 2: bind 1: socket 6: sendto 3: recvfrom* 4: sendto 5: recvfrom* 7: close 7: close *= call blocks request reply

slide-17
SLIDE 17

UDP Buffering

CSE 461 University of Washington 17

App Port Mux/Demux App App

Application Transport (TCP) Network (IP)

packet

Message queues Ports

slide-18
SLIDE 18

UDP Header

  • Uses ports to identify sending and receiving

application processes

  • Datagram length up to 64K
  • Checksum (16 bits) for reliability

CSE 461 University of Washington 18

slide-19
SLIDE 19

UDP Header (2)

  • Optional checksum covers UDP segment and IP

pseudoheader

  • Checks key IP fields (addresses)
  • Value of zero means “no checksum”

CSE 461 University of Washington 19

slide-20
SLIDE 20

TCP

slide-21
SLIDE 21

TCP

  • TCP Consists of 3 primary phases:
  • Connection Establishment (Setup)
  • Sliding Windows/Flow Control
  • Connection Release (Teardown)
slide-22
SLIDE 22

Connection Establishment

  • Both sender and receiver must be ready before we

start the transfer of data

  • Need to agree on a set of parameters
  • e.g., the Maximum Segment Size (MSS)
  • This is signaling
  • It sets up state at the endpoints
  • Like “dialing” for a telephone call

CSE 461 University of Washington 22

slide-23
SLIDE 23

CSE 461 University of Washington 23

Three-Way Handshake

  • Used in TCP; opens connection for

data in both directions

  • Each side probes the other with a

fresh Initial Sequence Number (ISN)

  • Sends on a SYNchronize segment
  • Echo on an ACKnowledge segment
  • Chosen to be robust even against

delayed duplicates

Active party (client) Passive party (server)

slide-24
SLIDE 24

CSE 461 University of Washington 24

Three-Way Handshake (2)

  • Three steps:
  • Client sends SYN(x)
  • Server replies with SYN(y)ACK(x+1)
  • Client replies with ACK(y+1)
  • SYNs are retransmitted if lost
  • Sequence and ack numbers carried
  • n further segments

1 2 3 Active party (client) Passive party (server) Time

slide-25
SLIDE 25

CSE 461 University of Washington 25

Three-Way Handshake (3)

  • Suppose delayed, duplicate

copies of the SYN and ACK arrive at the server!

  • Improbable, but anyhow …

Active party (client) Passive party (server)

slide-26
SLIDE 26

CSE 461 University of Washington 26

Three-Way Handshake (4)

  • Suppose delayed, duplicate

copies of the SYN and ACK arrive at the server!

  • Improbable, but anyhow …
  • Connection will be cleanly

rejected on both sides 

Active party (client) Passive party (server)

X X

REJECT REJECT

slide-27
SLIDE 27

TCP Connection State Machine

  • Captures the states ([]) and transitions (->)
  • A/B means event A triggers the transition, with action B

Both parties run instances

  • f this state

machine

slide-28
SLIDE 28

TCP Connections (2)

  • Follow the path of the client:
slide-29
SLIDE 29

TCP Connections (3)

  • And the path of the server:
slide-30
SLIDE 30

TCP Connections (4)

  • Again, with states …

CSE 461 University of Washington 30

LISTEN SYN_RCVD SYN_SENT ESTABLISHED ESTABLISHED 1 2 3 Active party (client) Passive party (server) Time CLOSED CLOSED

slide-31
SLIDE 31

TCP Connections (5)

  • Finite state machines are a useful tool to specify and

check the handling of all cases that may occur

  • TCP allows for simultaneous open
  • i.e., both sides open instead of the client-server pattern
  • Try at home to confirm it works 

CSE 461 University of Washington 31