Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Transport Layer By Ossi Mokryn and Hadar Binsky, Based on slides from: the Computer Networking: A Top Down Approach Featuring the Internet by Kurose and Ross, also by Jennifer Rexford, Princeton, And on data from beej’s guide : http://beej.us/guide/bgnet Transport Layer Connectionless and connection oriented communication Sockets programming UDP TCP Reliable communication Flow control Congestion control Timers Transport Layer 2 Transport 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 Transport Layer application transport network data link physical application transport network data link physical 3 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 services not available: delay guarantees bandwidth guarantees Transport Layer application transport network data link physical network data link physical network data link physical network data link physicalnetwork network data link physical data link physical network data link physical application transport network data link physical 4 Transport vs. network layer network layer: logical communication between hosts transport layer: logical communication between processes relies on, enhances, network layer services Transport Layer 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 5 Multiplexing/demultiplexing Multiplexing at send host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) Demultiplexing at rcv host: delivering received segments to correct socket = socket application = process P3 transport network link P1 P1 application transport network P2 P4 application transport network link link physical host 1 Transport Layer physical host 2 physical host 3 6 How 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 host uses IP addresses & port numbers to direct segment to appropriate socket 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format Transport Layer 7 Connectionless demultiplexing Create sockets with port numbers: 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 Transport Layer 8 Connectionless demux (cont) DatagramSocket serverSocket = new DatagramSocket(6428); P2 SP: 6428 SP: 6428 DP: 9157 DP: 5775 SP: 9157 client IP: A P1 P1 P3 DP: 6428 SP: 5775 server IP: C DP: 6428 Client IP:B SP provides “return address” Transport Layer 9 UDP: User Datagram Protocol [RFC 768] Simplest Internet transport protocol Each app. Output produces exactly one UDP segment “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 Transport Layer 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 10 UDP: more often used for streaming multimedia apps loss tolerant rate sensitive Length, in bytes of UDP segment, uses including header and data Minimum value is 8 Bytes other UDP DNS SNMP reliable transfer over UDP: add reliability at application layer application-specific error recovery! Transport Layer 32 bits source port # dest port # length checksum Application data (message) UDP segment format 11 UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment Sender: Receiver: treat segment contents compute checksum of as sequence of 16-bit integers checksum: addition (1’s complement sum) of segment contents sender puts checksum value into UDP checksum field Transport Layer received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonetheless? More later …. 12 Internet Checksum Example Note When adding numbers, a carryout from the most significant bit needs to be added to the result Example: add two 16-bit integers 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 Transport Layer 13 Sockets Programming over UDP – use socket slides now. Transmission Control Protocol Principles of reliable communication TCP basic notations, 3 way handshake TCP flow control, congestion control Principles of Reliable data transfer important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 16 Principles of Reliable data transfer important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 17 Principles of Reliable data transfer important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 18 Reliable Data Transfer: Stream stream jargon A stream is a sequence of characters that flow into or out of a process. An input stream is attached to some input source for the process, eg, keyboard or socket. An output stream is attached to an output source, eg, monitor or socket. Application Layer 19 Reliable Communication Terminology of a State Machine event causing state transition actions taken on state transition state 1 event actions state 2 Note: The state machine is for a certain host. Transport Layer 20 Reliable Communication First Model: sender sends, receiver receives. Is this enough? When will it work? When will it not work? stop and wait Sender sends one packet, then waits for receiver response Transport Layer 21 Reliable Communication Stop and Wait – Sender side Wait for data State 1 In State 1 Sender can send data Data available Wait Send Data for ack Received Ack Discussion: • What does the receiver do? • What happens if data is available at state 2? Transport Layer state 2 In State 2 Sender can receive acknowledge packets 22 channel with bit errors and losses underlying channel may flip bits in packet checksum to detect bit errors underlying channel can also lose packets the question: how to recover from errors: acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK timeout: sender retransmits pkt if doesn’t receive ack within timeout new mechanisms in: error detection receiver feedback: control msg (ACK) rcvr->sender sender control: timer to understand if to send again. Transport Layer 23 Reliable Communication Stop and Wait with errors/losses - sender Ack received Process ack Discussion: • What does the sender need to do for the retransmission? Transport Layer state 2.a Wait for ack packet or time out timeout State In State 1 1 Sender waits for data Data available Send Data Send Data Wait for data state 2.b 24 This version has a fatal flaw! What happens if ACK corrupted/lost? sender doesn’t know what happened at receiver! can’t just retransmit: possible duplicate Transport Layer Handling duplicates: sender retransmits current pkt if ACK garbled or didn’t arrive sender adds sequence number to each pkt receiver discards (doesn’t deliver up) duplicate pkt receiver must specify seq # of pkt being ACKed 25 discussion Sender: seq # added to pkt two seq. #’s (0,1) will suffice. Why? must check if received ACK corrupted twice as many states state must “remember” whether “current” pkt has 0 or 1 seq. # Receiver: must check if received packet is duplicate state indicates whether 0 or 1 is expected pkt seq # receiver sends ACK for last pkt received OK receiver must explicitly include seq # of pkt being ACKed note: receiver can not know if its last ACK received OK at sender Transport Layer 26 Stop & wait in action Transport Layer 27 Stop & wait in action Transport Layer 28 Performance of stop & wait Stop & wait works, but performance stinks ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet: L 8000bits d trans 8 microsecon ds 9 R 10 bps U sender: utilization – fraction of time sender busy sending U sender = L/R RTT + L / R = .008 30.008 = 0.00027 microsec onds 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link network protocol limits use of physical resources! Transport Layer 29 stop-and-wait operation sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK RTT ACK arrives, send next packet, t = RTT + L / R U = sender Transport Layer L/R RTT + L / R = .008 30.008 = 0.00027 microsec onds 30 Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-tobe-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver Two generic forms of pipelined protocols: go-Back-N, selective repeat Transport Layer 31 Pipelining: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK RTT ACK arrives, send next packet, t = RTT + L / R Increase utilization by a factor of 3! U sender = 3*L/R RTT + L / R Transport Layer = .024 30.008 = 0.0008 microsecon ds 32 Pipelining Protocol Go-back-N: big picture: Sender can have up to N unacked packets in pipeline Rcvr only sends cumulative acks Doesn’t ack packet if there’s a gap Sender has timer for oldest unacked packet If timer expires, retransmit all unacked packets Transport Layer 33 Go-Back-N Sender: k-bit seq # in pkt header “window” of up to N, consecutive unack’ed pkts allowed ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may receive duplicate ACKs (see receiver) timer for each in-flight pkt timeout(n): retransmit pkt n and all higher seq # pkts in window Transport Layer 3-34 Go Back N Receiver: ACK-only: always send ACK for correctly-received pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum out-of-order pkt: discard (don’t buffer) -> no receiver buffering! Re-ACK pkt with highest in-order seq # Transport Layer 35 GBN in action Transport Layer 3-36 Transport Control Protocol Enhanced GBN protocol Segment structure reliable data transfer and data transfer issues flow control connection management TCP congestion control Transport Layer 37 TCP: Overview 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 socket door application writes data application reads data TCP send buffer TCP receive buffer RFCs: 793, 1122, 1323, 2018, 2581 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 socket door overwhelm receiver segment Transport Layer 38 TCP segment structure 32 bits URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) source port # dest port # sequence number acknowledgement number head not UA P R S F len used RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) Transport Layer checksum Receive window Urg data pnter Options (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept application data (variable length) 39 TCP reliable data transfer TCP creates reliable service on top of IP’s unreliable service Pipelined segments Cumulative acks TCP uses single retransmission timer Transport Layer The sequence number for a segment is the first byte-stream # of the first byte in the segment. 40 TCP sender events: data rcvd from app: Create segment with seq # 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 acknowledges previously unacked segments Transport Layer update what is known to be acked start timer if there are outstanding segments 41 TCP seq. #’s and ACKs Seq. #’s: byte stream “number” of first byte in segment’s data ACKs: 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 Transport Layer Host A User types ‘C’ Host B host ACKs receipt of ‘C’ host receives ACK time 42 TCP: retransmission scenarios Host A X loss Sendbase = 100 SendBase = 120 SendBase = 100 SendBase = 120 time lost ACK scenario Transport Layer Host B Seq=92 timeout Host B Seq=92 timeout timeout Host A time premature timeout 43 TCP retransmission scenarios (more) timeout Host A Host B X loss SendBase = 120 time Cumulative ACK scenario Transport Layer 44 Interactive data flow Overhead for each packet: 40 bytes (20 TCP header + 20 IP header) to a total of 160 bytes for sending and receiving ‘C’. If the receiver waits a while, it can piggyback the data packet Delayed ack: Wait up to 200ms for next segment. If no next segment, send ACK. Should sender use delayed acks too? [Stevens figure 19.3] Transport Layer Host A User types ‘C’ Host B host ACKs receipt of ‘C’, Host echoes back ‘C’ host ACKs receipt of echoed ‘C’ simple telnet scenario time 45 Nagle Algorithm [RFC 896] Nagle’s alg: Quantifying overhead: how much control bytes per data bytes? with piggyback 2/120-> only 1.6% of the bits sent are data. LANs usually not congested so it might be okay. Small packets, termed tinygrams over congested WAN – bad news. New data can’t be sent until outstanding data is acked. Small amounts of data are collected and sent in a single segment when ack arrives. Self clocking: the faster the ack comes back, the faster data is sent. Slow links cause fewer segments to be sent. Transport Layer [Stevens 19.4] 46 TCP ACK generation [RFC 1122, RFC 2581] Event at Receiver TCP Receiver action Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Delayed ACK. Wait up to 200ms for next segment. If no next segment, send ACK Arrival of in-order segment with expected seq #. One other segment has ACK pending Immediately send single cumulative ACK, ACKing both in-order segments Arrival of out-of-order segment higher-than-expect seq. # . Gap detected Immediately send duplicate ACK, indicating seq. # of next expected byte Arrival of segment that partially or completely fills gap Immediate send ACK, provided that segment starts at lower end of gap Transport Layer 47 Fast Retransmit Time-out period often relatively long: long delay before resending lost packet Detect lost segments via duplicate ACKs. Sender often sends many segments back-toback If segment is lost, there will likely be many duplicate ACKs. Transport Layer If sender receives 3 dup. ACKs for the same data, it supposes that segment after ACKed data was lost: fast retransmit: resend segment before timer expires 48 Host A Host B timeout X time Figure 3.37 Resending a segment after triple duplicate ACK Transport Layer 49 Fast retransmit algorithm: event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } a duplicate ACK for already ACKed segment Transport Layer fast retransmit 50 TCP Round Trip Time and Timeout Q: how to set TCP timeout value? longer than RTT but RTT varies too short: premature timeout unnecessary retransmissions too long: slow reaction to segment loss Transport Layer 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 SampleRTT 51 TCP Round Trip Time and Timeout EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT Exponential weighted moving average influence of past sample decreases exponentially fast typical value: = 0.125 [Retransmission example in Stevens 21.1] Transport Layer 52 Example RTT estimation: RTT: gaia.cs.umass.edu to fantasia.eurecom.fr 350 RTT (milliseconds) 300 250 200 150 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) SampleRTT Transport Layer Estimated RTT 53 TCP Round Trip Time and Timeout Setting the timeout EstimtedRTT plus “safety margin” large variation in EstimatedRTT -> larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT: DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (typically, = 0.25) Then set timeout interval: Discuss: [Stevens 21.2, 21.4, 21.6, 21.7] TimeoutInterval = EstimatedRTT + 4*DevRTT Transport Layer 54 TCP Flow Control receive side of TCP connection has a receive buffer: flow control sender won’t overflow receiver’s buffer by transmitting too much, too fast speed-matching app process may be service: matching the send rate to the receiving app’s drain rate slow at reading from buffer Transport Layer 55 TCP Flow control: how it works Rcvr advertises spare (Suppose TCP receiver discards out-of-order segments) spare room in buffer = RcvWindow = RcvBuffer-[LastByteRcvd LastByteRead] Transport Layer room by including value of RcvWindow in segments Sender limits unACKed data to RcvWindow guarantees receive buffer doesn’t overflow Discuss: [Stevens 20.1, 20.4, 20.5, 20.6] 56 Delayed Duplicates Problem A user asks for a connection Due to congestion the packet is caught in a traffic jam The user asks again for the connection Destination accepts 2nd connection request User sends info to dest. Info gets caught in a traffic jam User sends info again Dest receives the info Connection is closed by both parties The original connection request and user info find their way to the destination. Transport Layer 57 TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments initialize TCP variables: seq. #s buffers, flow control info (e.g. RcvWindow) As seen in the previous slide, due to the delayed duplicates problem a simple 2-way handshake is not suffice. Possible solutions: A transport address can be used only once. (impossible for client-server model) Each connection is given an identifier by the originator. (requires indefinite history to be saved by the transport layer) Transport Layer TCP’s Solution: Three way handshake: Step 1: client host sends TCP SYN segment to server specifies initial seq # no data Step 2: server host receives SYN, replies with SYNACK segment server allocates buffers specifies server initial seq. # Step 3: client receives SYNACK, replies with ACK segment, which may contain data 58 TCP Connection Management (cont.) Connection Establishment: client server Step 1: client sends SYN segment to server with its ISN (Initial Sequence Number) Step 2: server receives SYN, replies with SYN+ACK (client’s ISN+1) and its own ISN. Step 3: client receives SYN+ACK, replies with ACK (server’s ISN+1). Transport Layer 59 TCP Connection Management (cont.) Closing a connection: client closes socket: clientSocket.close(); client close Step 1: client end system close FIN, replies with ACK. Closes connection, sends FIN. Transport Layer timed wait sends TCP FIN control segment to server Step 2: server receives server closed 60 TCP Connection Management (cont.) Step 3: client receives FIN, replies with ACK. client server closing Enters “timed wait” will respond with ACK to received FINs closing Step 4: server, receives Note: with small modification, can handle simultaneous FINs. Transport Layer timed wait ACK. Connection closed. closed closed 61 TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle [Tanenbaum 6.33] Transport Layer 62 Principles of Congestion Control Congestion: informally: “too 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) a top-10 problem! Transport Layer 63 TCP congestion control: additive increase, multiplicative decrease Approach: increase transmission rate (window size), Saw tooth behavior: probing for bandwidth congestion window size probing for usable bandwidth, until loss occurs additive increase: increase CongWin by 1 MSS every RTT until loss detected multiplicative decrease: cut CongWin in half after loss Transport Layer congestion window 24 Kbytes 16 Kbytes 8 Kbytes time time 64 TCP Congestion Control: details sender limits transmission: LastByteSent-LastByteAcked min(CongWin,RcvWindow) Let’s assume that RcvWindow is not a constraint (for simplicity) Roughly, rate = CongWin Bytes/sec RTT CongWin is dynamic, function of perceived network congestion Transport Layer How does sender perceive congestion? loss event = timeout or 3 duplicate acks TCP sender reduces rate (CongWin) after loss event three mechanisms: AIMD slow start conservative after timeout events 65 TCP Slow Start When connection begins, CongWin = 1 MSS Example: MSS = 500 bytes & RTT = 200 msec initial rate = 20 kbps When connection begins, increase rate exponentially fast until first loss event available bandwidth may be >> MSS/RTT desirable to quickly ramp up to respectable rate Transport Layer 66 TCP Slow Start (more) When connection Host B RTT begins, increase rate exponentially until first loss event: Host A double CongWin every RTT done by incrementing CongWin for every ACK received Summary: initial rate is slow but ramps up exponentially fast Transport Layer time 67 Refinement: inferring loss After 3 dup ACKs: CongWin is cut in half window then grows linearly Part of Fast Recovery But after timeout event: CongWin instead set to 1 MSS; window then grows exponentially (This is SS) to a threshold (ssthresh), then grows linearly Transport Layer Philosophy: 3 dup ACKs indicates network capable of delivering some segments timeout indicates a “more alarming” congestion scenario 68 Refinement Q: When should the exponential increase switch to linear? A: When CongWin gets to 1/2 of its value before timeout. Implementation: Variable Threshold (ssthresh) At loss event, Threshold is set to 1/2 of CongWin just before loss event Transport Layer 69 Summary: TCP Congestion Control When CongWin is below Threshold, sender in slow-start phase, window grows exponentially. When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly. When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold. When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS. Transport Layer 70 TCP sender congestion control State Event TCP Sender Action Commentary Slow Start (SS) ACK receipt for previously unacked data CongWin = CongWin + MSS, If (CongWin > Threshold) set state to “Congestion Avoidance” Resulting in a doubling of CongWin every RTT Congestion Avoidance (CA) ACK receipt for previously unacked data CongWin = CongWin+MSS * (MSS/CongWin) Additive increase, resulting in increase of CongWin by 1 MSS every RTT SS or CA Loss event detected by triple duplicate ACK Threshold = CongWin/2, CongWin = Threshold, Set state to “Congestion Avoidance” Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS. SS or CA Timeout Threshold = CongWin/2, CongWin = 1 MSS, Set state to “Slow Start” Enter slow start SS or CA Duplicate ACK Increment duplicate ACK count for segment being acked CongWin and Threshold not changed Transport Layer 71 TCP throughput What’s the average throughout of TCP as a function of window size and RTT? Ignore slow start Let W be the window size when loss occurs. When window is W, throughput is W/RTT Just after loss, window drops to W/2, throughput to W/2RTT. Average throughout: .75 W/RTT Transport Layer 72 TCP Futures: TCP over “long, fat pipes” Example: 1500 byte segments, 100ms RTT, want 10 Gbps throughput Requires window size W = 83,333 in-flight segments Throughput in terms of loss rate: 1.22 MSS RTT L ➜ L = 2·10-10 Wow New versions of TCP for high-speed Transport Layer 73 TCP Fairness Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K TCP connection 1 TCP connection 2 Transport Layer bottleneck router capacity R 74 Why is TCP fair? Two competing sessions: Additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally equal bandwidth share R loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput R Transport Layer 75 Fairness (more) Fairness and UDP Multimedia apps often do not use TCP do not want rate throttled by congestion control Instead use UDP: pump audio/video at constant rate, tolerate packet loss Research area: TCP friendly Transport Layer Fairness and parallel TCP connections nothing prevents app from opening parallel connections between 2 hosts. Web browsers do this Example: link of rate R supporting 9 connections; new app asks for 1 TCP, gets rate R/10 new app asks for 11 TCPs, gets R/2 ! 76 Chapter 3: Summary principles behind transport layer services: multiplexing, demultiplexing reliable data transfer flow control congestion control instantiation and implementation in the Internet UDP TCP Transport Layer Next: Socket programming over TCP After that: leaving the network “edge” (application, transport layers) into the network “core” 77 Connection-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 Transport Layer 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 78 Connection-oriented demux (cont) P1 P4 P5 P2 P6 P1P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 client IP: A DP: 80 S-IP: A D-IP:C Transport Layer SP: 9157 server IP: C DP: 80 S-IP: B D-IP:C Client IP:B 79 Connection-oriented demux: Threaded Web Server P1 P2 P4 P1P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 client IP: A DP: 80 S-IP: A D-IP:C Transport Layer SP: 9157 server IP: C DP: 80 S-IP: B D-IP:C Client IP:B 80