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

Transport services and protocols

• provide logical communication between app processes on different hosts
• transport protocols run in end systems
  • send side: breaks app messages into segments, passes to entwork layer
  • receive side: reassembles segments into messages, passes to app layer
• more than one transport protocol abailable to apps
  • Internet: TCP and UDP

Transport vs network layer

• network layer: logical communication between hosts
• transport layer : logical communication between processes
  • relies on, enhances, network layer services

Internet 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
• service not available
  • delay guarantees
  • bandwidth guarantees

Multiplexing/demultiplexing

How demultiplexing works

• host receives IP datagrams
  • each datagram has source IP address, destination IP address
  • each datagram carries one transport-layer segment
  • each segment has source, destination port number
• host uses IP address & port numberes to direct segment to appropriate socket

Connectionless demultiplexing

• recall: created socket has host-local port #:

  • DatagramSoket mySocket1 = new DatagramSocket(12534)

• recall: when creating datagram to send into UDP socket, must specify

  • destination IP address
  • destination port #

• when host receives UDP segment

  • checks destination port # in segment

  • directs UDP segment to secket with that port #

    IP datagrams with same dest. post #, but different source IP addesses and/or source port numbers will be directed to same socket at dest

Connectionless demux: example

Connection-oriented demux

• TCP socket identified by 4-tuple
  • source IP address
  • source port number
  • dest IP address
  • dest port number
• demux
  • receiver uses all four values to direct segment to appropriate socket
• server host may support many simutaneous 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: example

UDP: 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
• UDP use:
  • streaming multimedia apps (loss tolerant, rate sensitive)
  • DNS
  • SNMP
• reliable transfer over UDP
  • add reliability at application layer
  • application-specific error recovery

UDP: segment header

UDP checksum

• Goal: detect “errors” in transmitted segment
• sender
  • treat segment contents, including header fields, as sequence of 16-bit integers
  • checksum: additon (one’s complement sum) of segment contents
  • sender puts checksum value into UDP checksum field
• receiver:
  • compute checksum of received segment
  • check if computed checksum equals checksum field value
    • No - error detected
    • YES - no error detected. But maybe errors nonetheless?

Internet checksum: example

carry된 비트를 더해주고 1의 보수를 취하면 checksum

TCP

• point-to-point
  • one sender, one receiver
• reliable, in-order byte stream
  • no “messge boundaries”
• pipelined
  • TCP congestion and flow control set window size
• full duplex data
  • bi-directional data flow in same connection
  • MSS: maximum segment size
• connection-oriented
  • handshaking (exchange of control msgs) inits sender, receiver state before data exchange
• flow controlled
  • sender will not overwhelm receiver

TCP segment structure

TCP seq. numbers, ACKs

• sequnce number
  • byte stream “number” of first byte in segment’s data
• acknowledgements
  • seq # of next byte expected from other side
  • cumulative ACK
  • Q: how receiver handles out-of-order segments
    • A: TCP spec doesn’t say, up to implementor

TCP round trip time, timeout

• Q: how to set TCP timeout value?
  • longer than RTT
    • but RTT varies
  • too short: premature timeout, unneceessary retransmissions
  • too long: slow reaction to segment loss
• Q: how to estimate RTT
  • SampleRTT: measured time from segment transmission until ACK receipt
    • ignore retransmissions
  • SampleRTT will vary, want estimated RTT “smoother”
    • average several recent measurements, not just current SamplRTT

TCP: reliable data transfer

• TCP creates rdt(reliable data transfer) service on top of IP’s unreliable service
  • pipelined segments
  • cumulative acks
  • sigle retransmission timer
• retransmissions triggered by
  • time out
  • duplicate acks
• let’s initially consider simplified TCP sender
  • ignore duplicate acks
  • ignore flow control, congestion control

TCP sender events

• data rcvd from app
  • create segment with seq #
  • seq # is byte-stream number of first dta byte in segment
  • start timer if not already running
    • think of timer as for oldest unacked segment
    • expiration interval : TimeOutInterval
• timeout
  • retransmit segment that caused timeout
  • restart timer
• ack rcvd
  • if ack acknowledges previously unacked segemtns
    • update what is known to be ACKed
    • start timer if there are still unacked segments

NextSeqNum은 보내야하는 Seq 번호, SendBase는 보냈지만 ACK 받지 않은 Seq 번호

TCP: retransmission scenarios

TCP ACK generation

TCP fast retransmit

• time-out period often relatively long
  • long delay before resending lost packet
• detection lost segments via duplicate ACKs
  • sender often sends many segments back-to-back
  • if segment is lost, there will likely be many duplicate ACKs
• TCP fast retransmit
  • if sender receives 3 ACKs for same data (“triple duplicate ACKs), resend unacked
    • likely that unacked segment lost, so don’t wait for timeout

TCP: flow control

• receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segments
  • RcvBuffer size set via socket options (typical default is 4096 bytes)
  • many operating systems autoadjust RcvBuffer
• sender limits amount of unacked (“in-flight”) data to receiver’s rwnd value
• guarantees receive buffer will not overflow

TCP: connection management

• before exchanging data, sender/receiver “handshake”
  • agree to establish connection (each knowing the other willing to establish connection)
  • agree on onnection parameters

Agreeing to establish a connection

• Q: will 2-way handshake always work in network?
  • variable delays
  • retransmitted messages (e.g. req_conn(x)) due to message loss
  • message reordering
  • can’t “see” other side

2-way handshake failure scenarios

TCP 3-way handshake

TCP: closing a connection

• client, server each close ther side of connection
  • send TCP segment with FIN bit = 1
• responsd to receved FINB with ACK
  • on receiving FIN, ACK can be combined with own FIN
• simultaneous FIN exchanges can be handled

client가 마지막에 2 * max segment lifetime을 대기하는 이유는

server측에서 FIN 요청을 하고 ACK를 못 받아서 다시 FIN 요청을 보낼 경우를 대비해서 대기한다

TCP congetion control

• congestion
  • informally: “toioi many sources sending too much data too fast for network to handle”
  • different from flow control!
  • manifestations
    • lost packets (buffer overflow at routers)
    • long delays (queueing in router buffers)

TCP congestion control: additive increase, multiplicative decrease

• approach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs
  • additive increase: increase cwnd by 1 MSS every RTT until loss detected
  • multiplicative decrease: cut cwnd in half after loss

TCP Congestion Control: details

• sender limits transmission
  • LastByteSent - LastByteAcked <= min(cwnd, rwnd)
• cwnd is dynamic, function of perceived network congestion
• TCP sending rate
  • roughly: send cwnd bytes, wait RTT for ACKS, then send more bytes
  • rate = cwnd / RTT (bytes/sec)

TCP Slow Start

• when connection begins, increase rate exponentially until first loss event
  • initially cwnd = 1 MSS
  • double cwnd every RTT
  • done by incrementing cwnd for every ACK received
• summary: initial rate is slow but ramps up exponentially fast

TCP: detecting, reacting to loss

• loss indicated by timeout
  • cwnd set to 1 MSS
  • window then grows exponetially (as in slow start)
• loss indicated by 3 duplicate ACKs: TCP RENO
  • dup ACKs indicate network capable of delivering som segments
  • cwnd is cut in half window then grows linearly
• TCP Tahoe always set cwnd to 1 (timeout or 3 duplicate acks)

TCP: switching from slow start to CA

• Q: when should the exponential increase switch to linear?
• A: when cwnd gets to 1/2 of its value before timeout
• Implementation
  • variable ssthresh
  • on loss event, ssthresh is set to 1/2 of cwnd just before loss event

TCP throughput

• avg. TCP throughput as function of window size, RTT?
  • ignore slow start, assuum always data to send
• W: window size (measured in bytes) where loss occurs
  • avg. window size (# in-flight bytes) is 3/4 W
  • avg. throughput is 3/4W per RTT

TCP Fairness

• fairness goal
  • if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K

Why is TCP fair?

• two competing sessions
  • additive increase gives slope of 1, as throughout inscreases
  • multiplicative decrease decreases throughput proportionally

참조

• 컴퓨터 네트워크 이미정 교수님 강의
• Computer Networking: A Top-Down Approach Featuring the Internet

Comment and share

Socket programming

• goal: learn how to build client/server applications that communicate using sockets
• socket: door between application process and end-end-transport protocol

• Two socket types for two transport services
  • UDP : unreliable datagram
  • TCP : reliable, byte stream-oriented
• Application Example
  1. client reads a line of characters (data) from its keyboard and sends data to server
  2. server receives the data and converts characters to uppercase
  3. server send modified data to client
  4. client receives modified data and displays line on its screen

Socket programming with UDP

• UDP: no “connection” between client & server
  • no handshaking before sending data
  • sender explicitly attaches IP destination address and port $ to each packet
  • receiver extracts sender IP address and port # from received packet
• UDP : transmitted data may be lost or received out-of-order
• Application viewpoint
  • UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server

Client/server socket interaction: UDP

Example app: UDP client

Example app: UDP server

Socket programming with 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 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 that particular client
    • allows server to talk with multiple clients
    • source port numbers userd to distinguish clients
• application viewpoint
  • TCP provides reliable, in-order byte-stream transfer (“pipe”) between cient and server

Client/server socket interaction: TCP

Example app: TCP client

Example app: TCP server

연결을 담당하는 serverSocket 1개와 각 연결이 완료되면 요청마다 처리를 담당하는 connectionSocket이 생성된다

참조

• 컴퓨터 네트워크 이미정 교수님 강의
• Computer Networking: A Top-Down Approach Featuring the Internet

Comment and share

Web and HTTP

• web page consists of objects

• object can be HTML file, JPEG image, Java applet, audio file, …

• web page consists of base HTML-file which includes several referenced objects

• each object is addressable by a URL, e.g.,

  

HTTP overview

HTTP: hypertext transfer protocol

• Web’s application layer protocol
• client/server model
  • client: browser that requests, revceives, (using HTTP protocol) and displays Web objects
  • server: Web server sends (using HTTP protocol) objects in response to requests

• uses TCP
  1. client initiates TCP connection(creates socket) to server, port 80
  2. server accepts TCP connection from client
  3. HTTP messages (application-layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)
  4. TCP connection closed
• HTTP is “stateless”
  • server maintains no information about past client requests
  • aside : protocols that maintain "state" are complex!
    • past history (state) must be maintained
    • if server/client crashes, their views of “state” may be inconsistent, must be reconciled

HTTP connections

• non-persistent HTTP
  • at most one object sent over TCP connection
    • connection then closed
  • downloading multiple obejcts requires multiple connections
• persistent HTTP
  • multiple objects can be sent over single TCP connection between client, server

Non-persistent HTTP

suppose user enters URL:

www.someSchool.edu/someDepartment/home.index

Non-persistent HTTP: response time

• RTT (definition): time for a small packet to travel from client to server and back
• HTTP response time
  • one RTT to initiate TCP connection
  • one RTT for HTTP request and first few bytes of HTTP response to return
  • file transmission time
  • non-persistent HTTP response time = 2RTT + file transmission time

Persistent HTTP

• non-persistent HTTP issues
  • requires 2 RTTs per object
  • browsers often open parallel TCP connections to fetch referenced objects
  • OS overhead for each TCP connection (each tcp buffer, socket)
• persistent HTTP
  • server leaves connection open after sending response
  • subsequent HTTP messages between same client/server sent over open connection
  • client sends request as soon as it encounters a referenced object
  • as little as one RTT for all the referenced objects

HTTP request message

• two types of HTTP messages: request, response
• HTTP request message
  • ASCII (human-readable format)

Keep-Alive Header is persistent HTTP configure

general format

Uploading form input

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

Method types

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

HTTP response message

HTTP response status codes

• status code appears in 1st line in server to client response message
• some sample codes
  • 200 OK
    • request succeeded, requested object later in this msg
  • 301 Moved Permanently
    • request object moved, new location specified later in this msg (Location Header)
  • 400 Bad Request
    • request msg not understood by server
  • 404 Not Found
    • requested document not found on this server
  • 505 HTTP Version Not Supported

User-server state: cookies

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

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

Web caches (proxy server)

• goal: satisfy client request with out involving origin server
• user sets browser: Web access via cache
• browser sends all HTTP requests to cache
  • object in cache: cache returns object
• else cache requets object from origin server, then returns object to client

• cache acts as both client and server
  • server for original requesting client
  • client to origin server
• typically cache is installed by ISP (university, company, residential ISP)
• why Web cacing?
  • reduce response time for cient request
  • reduce traffic on an institution’s access link
  • Internet dense with caches: enables “poor” content providers to effectively deliver content (so Too does P2P file sharing)

Conditional GET

• Goal: don’t send object if cache has up-to-date cached version
  • reduce delay
  • lower link utilization
• cache: specify date of cached copy in HTTP request
  • If-modified-since: date
• server response contatins no object if cached copy is up-to-date
  • HTTP/1.0 304 Not Modified

참조

• 컴퓨터 네트워크 이미정 교수님 강의
• Computer Networking: A Top-Down Approach Featuring the Internet

Comment and share

Application architectures

• possible structure of applications
  • client-server
  • peer-to-peer (P2P)

Client-server architecture

• server
  • always-on host
  • permanent IP address
  • data centers for scaling
• clients
  • communicate with server
  • do not communicate directly with each other
  • may be intermittently(on and off) connect
  • may have dynamic IP addresses

P2P architecture

• no always-on server
• arbitrary end systems directly communicate
• peers request service from other peers, provide service in return to ohter peers
  • self scalability - new peers bring new service capacity, as well as new service demands
• peers are intermittently connected and change IP address
  • complex management

Processes communicating

• process: program running within a host

  • within same host, tow processes communicate using inter-process communication (defined by OS)
  • processes in different hosts communicate by exchanging messages

• clients, servers

  • client process: process that initiates communication

  • server process: process that waits to be contacted

    aside: applications with P2P architectures have client processes & server processes

Sockets

• process sends/receives messages to/from its socket
• socket analogous to door
  • sending process shoves message out door
  • sending process relies on transport infrastructure on other side of door to deliver message to socket at receiving process

Addressing processes

• to receive messages, process must have identifier
• host device has unique 32-bit IP address
• Q: does IP address of host on which process runs suffice for identifying th process?
  • A: no, many processes can be running on same host
• identifier include both IP adderss and port numbers
• example port numbers:
  • HTTP server: 80
  • mail server: 25
• to send HTTP message to www.naver.com web server
  • IP address: 121.33.223.11
  • port number: 80

What transport service does an app need?

• data integrity
  • some apps (e.g., file transfer, web transactions) require 100% reliable data transfer
  • other apps (e.g., audio) can tolerate some loss
• timing
  • some apps (e.g., Internet telephony, interactive games) require lo delay to be “effective”
• throughput
  • some apps (e.g., multimedia) require minimum amount of throughtput to be “effective”
  • other apps (“elastic apps”) make use of whatever throughtput they get

Transport service requirements: common apps

Internet transport protocols services

• TCP service
  • reliable transport between sending and receiving process
  • flow control: sender won’t overwhelm receiver
  • connection-oriented: setup required between client and server processes
  • congestion control: throttle sender when network overloaded
  • does not provide: timing, minimum throughput guarantee, security
• UDP service
  • unreliable data transfer between sending and reveiving process
  • does not provide: reliability, flow control, congestiong control, timing, throughput guarantee, security, or connection setup

    Internet apps: application, transport protocols

Application layer protocol defines

• types of messages exchanged
  • e.g., request, response
• message syntax
  • what fields in messages & how fields are delineated
• message semantics
  • meaning of information in fields
• rules for when and how processes send & responsd to messages

참조

• 컴퓨터 네트워크 이미정 교수님 강의
• Computer Networking: A Top-Down Approach Featuring the Internet

Comment and share