1 / 24

CSE 461: Transport Layer Connections

CSE 461: Transport Layer Connections. Naming Processes/Services. Process here is an abstract term for your Web browser (HTTP), Email servers (SMTP), hostname translation (DNS), RealAudio player (RTSP), etc. How do we identify for remote communication?

Download Presentation

CSE 461: Transport Layer Connections

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CSE 461: Transport Layer Connections

  2. Naming Processes/Services • Process here is an abstract term for your Web browser (HTTP), Email servers (SMTP), hostname translation (DNS), RealAudio player (RTSP), etc. • How do we identify for remote communication? • Process id or memory address are OS-specific and transient • So TCP and UDP use Ports • 16-bit integers representing mailboxes that processes “rent” • typically from OS • Identify endpoint uniquely as (IP address, protocol, port) • OS converts into process-specific channel, like “socket”

  3. Processes as Endpoints

  4. Picking Port Numbers • We still have the problem of allocating port numbers • What port should a Web server use on host X? • To what port should you send to contact that Web server? • Servers typically bind to “well-known” port numbers • e.g., HTTP 80, SMTP 25, DNS 53, … look in /etc/services • Ports below 1024 reserved for “well-known” services • Clients use OS-assigned temporary (ephemeral) ports • Above 1024, recycled by OS when client finished

  5. User Datagram Protocol (UDP) • Provides message delivery between processes • Source port filled in by OS as message is sent • Destination port identifies UDP delivery queue at endpoint

  6. UDP Delivery Application Application Application process process process Kernel boundary Ports Message Queues DeMux on Port # Packets arrive

  7. UDP Checksum • UDP includes optional protection against errors • Checksum intended as an end-to-end check on delivery • So it covers data, UDP header

  8. Transmission Control Protocol (TCP) • Reliable bi-directional bytestream between processes • Message boundaries are not preserved • Connections • Conversation between endpoints with beginning and end • Flow control • Prevents sender from over-running receiver buffers • Congestion control • Prevents sender from over-running network buffers

  9. TCP Header Format • Ports plus IP addresses identify a connection

  10. TCP Header Format • Sequence, Ack numbers used for the sliding window

  11. TCP Header Format • Flags may be URG, ACK, PUSH, RST, SYN, FIN

  12. TCP Header Format • Advertised window is used for flow control

  13. TCP Connection Establishment • Both connecting and closing are (slightly) more complicated than you might expect • That they can work is reasonably straightforward • Harder is what to do when things go wrong • TCP SYN+ACK attack • Close looks a bit complicated because both sides have to close to be done • Conceptually, there are two one-way connections • Don’t want to hang around forever if other end crashes

  14. Three-Way Handshake • Opens both directions for transfer Active opener Passive listener (client) (server) SYN, SequenceNum = x , y 1 + SYN + ACK, SequenceNum = x Acknowledgment = ACK, Acknowledgment = y + 1 +data

  15. Some Comments • We could abbreviate this setup, but it was chosen to be robust, especially against delayed duplicates • Three-way handshake from Tomlinson 1975 • Choice of changing initial sequence numbers (ISNs) minimizes the chance of hosts that crash getting confused by a previous incarnation of a connection • But with random ISN it actually proves that two hosts can communicate • Weak form of authentication

  16. TCP State Transitions CLOSED Active open /SYN Passive open Close Close LISTEN SYN/SYN + ACK Send/ SYN SYN/SYN + ACK SYN_RCVD SYN_SENT ACK SYN + ACK/ACK Close ESTABLISHED /FIN Close /FIN FIN/ACK FIN_WAIT_1 CLOSE_WAIT FIN/ACK ACK Close /FIN ACK + FIN/ACK FIN_WAIT_2 CLOSING LAST_ACK Timeout after two ACK ACK segment lifetimes FIN/ACK TIME_WAIT CLOSED

  17. Again, with States Active participant Passive participant (client) (server) SYN_SENT LISTEN SYN, SequenceNum = x SYN_RCVD , y 1 + SYN + ACK, SequenceNum = x Acknowledgment = ESTABLISHED ACK, Acknowledgment = ESTABLISHED y + 1 +data

  18. Connection Teardown • Orderly release by sender and receiver when done • Delivers all pending data and “hangs up” • Cleans up state in sender and receiver • TCP provides a “symmetric” close • both sides shutdown independently

  19. TCP Connection Teardown Web server Web browser FIN_WAIT_1 FIN CLOSE_WAIT ACK LAST_ACK FIN FIN_WAIT_2 TIME_WAIT ACK … CLOSED CLOSED

  20. The TIME_WAIT State • We wait 2MSL (two times the maximum segment lifetime of 60 seconds) before completing the close • Why? • ACK might have been lost and so FIN will be resent • Could interfere with a subsequent connection

  21. Berkeley Sockets interface • Networking protocols implemented in OS • OS must expose a programming API to applications • most OSs use the “socket” interface • originally provided by BSD 4.1c in ~1982. • Principle abstraction is a “socket” • a point at which an application attaches to the network • defines operations for creating connections, attaching to network, sending and receiving data, closing connections

  22. TCP (connection-oriented) Server Socket() Bind() Client Listen() Socket() Accept() Connection Establishmt. Connect() Block until connect Data (request) Send() Recv() Process request Data (reply) Send() Recv()

  23. UDP (connectionless) Server Socket() Client Bind() Socket() Recvfrom() Bind() Block until Data from client Sendto() Data (request) Process request Data (reply) Sendto() Recvfrom()

  24. Key Concepts • We use ports to name processes in TCP/UDP • “Well-known” ports are used for popular services • Connection setup and teardown complicated by the effects of the network on messages • TCP uses a three-way handshake to set up a connection • TCP uses a symmetric disconnect

More Related