计算机网络第五版教学Chapter3AriesHE.ppt

本章小结 应用层协议原理 客户服务器模式 WEB和HTTP 非持久连接和持久连接 请求报文和响应报文 cookie、cache、条件GET FTP 两个连接、两个端口、服务器两类进程 EMAIL SMTP、POP3、IMAP DNS 分布式、层次结构 GET /icwork/? search=product HTTP/1.1 Accept:image/gif,image/x-xbitmap,image/jpeg,image/ pjpeg,application/vnd.ms-powerpoint,application /vnd.ms-excel,application/msword,*.* Accept-Language:en-us Accept-Encoding:gzip,deflate User-Agent:Mozilla/4.0(compatible;MSIE 5.01;Windows NT 5.0;DigExt) Host::8080 Referer:/header.html Connection:Keep-Alive Chapter 3 Transport Layer Computer Networking: A Top Down Approach 4rd edition. Jim Kurose, Keith Ross Chapter 3: Transport Layer Our goals: understand principles behind transport layer services: multiplexing/demultipl exing reliable data transfer flow control congestion control learn about transport layer protocols in the Internet: UDP: connectionless transport TCP: connection-oriented transport TCP congestion control Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control 从通信和信息处理的角度看，传输层 向它上面的应用 层提供通信服务，它属于面向通信部分的最高层，同 时也是用户功能中的最低层。 物理层 网络层 传输层 应用层 数据链路层 面向信息处理 面向通信 用户功能 网络功能 传输层在协议层次结构中的位置 问题的提出 计算机网络最本质的活动是分布在不同地理 位置的主机之间的进程通信，以实现各种网 络服务功能; 网络层 及以下的各层实现 了网络中主机之间 的通信，但是数据通信不是最终的目的; 设置传输层 的主要目的就是要实现实现 分布式进进 程通信。 问题的提出 需要一套传输控制机制，更可靠、更方便 和有效的传送数据，且将这种机制与应用 程序分离开，并向应用程序提供一致的数 据流传送接口。 传输层就是应上 述要求而产生的 网络环境中分布式进程通信需要解决 进程命名与寻址方法 多重协议的识别 进程间相互作用的模式 进程寻址与端口 在一台计算机中，不同的进程用进程号或进程标识（ process ID）惟一地标识出来。 网络环 境中完整的进程标识应该 是： 本地主机地址-本地进程标识 ； 远程主机地址-远程进程标识。 进程地址也叫做端口号（port number）。 端口就是运输层 服务访问 点 TSAP。 端口的作用就是让应用层的各种应用进程都能将其数据 通过端口向下交付给运输层 ，以及让运输层 知道应当 将其报文段中的数据向上通过端口交付给应用层相应的 进程。 从这个 意义上讲，端口是用来标志应用层的进程。 多重协议的识别 网络环 境中一个进程的全网惟一的标识需要一个三元 组来表示：协议，本地地址，本地端口号。 网络环 境中一个完整的进程通信标识需要一个五元组 来表示： 协议 本地地址 本地端口号 远地地址 远地端口号 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 application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport transport layer: logical communication between processes 5 4 3 2 1 传输层提供应用进程间的逻辑通信 主机 A主机 B 应用进程应用进程 路由器 1路由器 2 AP1 LAN2WAN AP2 AP3 AP4 IP 层 LAN1 AP1 AP2 AP4 5 4 3 2 1 网络层协议的作用范围 传输层协议 TCP 和 UDP 的作用范围 AP3 Transport 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 传输层协议和网络层协议的主要区别 应用进程 应用进程 IP 协议的作用范围 （提供主机之间的逻辑通信） TCP 和 UDP 协议的作用范围 （提供进程之间的逻辑通信） 因 特 网 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” application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport 传输层数据单元 传输层 之间传输 的报文叫做传输协议数 据单元（ Transport Protocol Unit，TPDU）； TPDU有效载荷是应用层的数据。 网络层 ：Datagaram 传输层 ：Segment H T T P F T P S M T P T F T P D N S T e l n e t S N M P 2123255369161 TCP UDP 应用层 传输层 TCP和UDP都用端口(port)号来识别应用层实体，以便准确地 把信息提交给上层对应的协议（进程）。 port 80 传输层向上提供可靠的和不可靠的逻辑通信信道 ？ 应 用 层 传 输 层 发 送 进 程 接 收 进 程 接 收 进 程 数据数据 全双工可靠信道 数据数据 使用 TCP 协议 使用 UDP 协议 不可靠信道 发 送 进 程 TCP 与 UDP UDP 在传传送数数据之前不需要先建立连连接。对方的传输 层在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 是一种最 有效的工作方式。 TCP 则则提供面向连连接的服务务。由于 TCP 要提供可靠 的、面向连接的传输服务，因此不可避免地增加了许 多的开销。这不仅使协议数 据单元的首部增大很多 ，还要占用许多的处理机资源。 Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Multiplexing/demultiplexing application transport network link physical P1 application transport network link physical application transport network link physical P2 P3 P4 P1 host 1host 2 host 3 = process= socket delivering received segments to correct socket Demultiplexing at rcv host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) Multiplexing at send host: Multiplexing/demultiplexing 应 用 层 运 输 层 网 络 层 TCP 报文段 UDP 用户数据报 应用进程 TCP 复用 IP 复用 UDP 复用 TCP 报文段 UDP 用户数据报 应用进程 端口端口 TCP 分用UDP 分用 IP 分用 IP 数据报IP 数据报 发送方 接收方 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 DatagramSocket mySocket2 = new DatagramSocket(12535); 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) DatagramSocket serverSocket = new DatagramSocket(6428); Client IP:B P2 client IP: A P1 P1 P3 server IP: C SP: 6428 DP: 9157 SP: 9157 DP: 6428 SP: 6428 DP: 5775 SP: 5775 DP: 6428 SP provides “return address” 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 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) Client IP:B P1 client IP: A P1 P2P4 server IP: C SP: 9157 DP: 80 SP: 9157 DP: 80 P5P6P3 D-IP:C S-IP: A D-IP:C S-IP: B SP: 5775 DP: 80 D-IP:C S-IP: B Connection-oriented demux: Threaded Web Server Client IP:B P1 client IP: A P1 P2 server IP: C SP: 9157 DP: 80 SP: 9157 DP: 80 P4P3 D-IP:C S-IP: A D-IP:C S-IP: B SP: 5775 DP: 80 D-IP:C S-IP: B Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control UDP: User Datagram Protocol RFC 768 “no frills,” “bare bones” (简 约)Internet transport protocol “best effort” service, UDP segments may be: lost delivered out of order to app 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 UDP 只在 IP 的数据报服务之上增加了很少一点的功能 ，即端口的功能和差错检测错检测 的功能。 虽然 UDP 用户数据报只能提供不可靠的交付，但 UDP 在某些方面有其特殊的优点。 发送数据之前不需要建立连接 UDP 的主机不需要维持复杂的连接状态表。 UDP 用户数据报只有8个字节的首部开销。 网络出现的拥塞不会使源主机的发送速率降低。 UDP: 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 Application data (message) UDP segment format lengthchecksum Length, in bytes of UDP segment, including header 伪首部源端口目的端口长 度检验和 数 据首 部 IP 数据报 122222字节 发送在前 数 据首 部UDP 用户数据报 UDP长度源 IP 地址目的 IP 地址017 字节44112 Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP 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) 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) 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) Reliable data transfer: getting started send side receive side rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer udt_send(): called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv(): called when packet arrives on rcv-side of channel deliver_data(): called by rdt to deliver data to upper Reliable data transfer: getting started Well: Incrementally渐进的 develop sender, receiver sides of reliable data transfer protocol (rdt) consider only unidirectional单向的 data transfer but control info will flow on both directions! use finite state machines (FSM) to specify sender, receiver state 1 state 2 event causing state transition actions taken on state transition state: when in this “state” next state uniquely determined by next event event actions Building a reliable data transfer protocol Rdt1.0 Rdt2.0 Rdt 2.1 Rdt 2.2 Rdt 3.0 Rdt1.0: reliable transfer over a reliable channel underlying channel perfectly reliable no bit errors no loss of packets separate FSMs(有限状态机) for sender, receiver: sender sends data into underlying channel receiver read data from underlying channel Wait for call from above packet = make_pkt(data) udt_send(packet) rdt_send(data) extract (packet,data) deliver_data(data) Wait for call from below rdt_rcv(packet) sender receiver Rdt2.0: channel with bit errors underlying channel may flip bits（比特翻转） in packet checksum to detect bit errors the question: how to recover from errors: acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors sender retransmits pkt on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0): error detection receiver feedback: control msgs (ACK,NAK) rcvr-sender rdt3.0: channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) checksum, seq. #, ACKs, retransmissions will be of help, but not enough Approach: sender waits “reasonable” amount of time for ACK retransmits if no ACK received in this time if pkt (or ACK) just delayed (not lost): retransmission will be duplicate, but use of seq. #s already handles this receiver must specify seq # of pkt being ACKed requires countdown timer Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 full duplex data:全双工数据流 bi-directional data flow in same connection 一个连接有两个方向的数据流 MSS: maximum segment size MSS：最大段大小 connection-oriented:面向连接 handshaking (exchange of control msgs) inits 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 server: contacted by client Socket connectionSocket = welcomeSocket.accept(); Three way handshake:三次握手 Step 1: client host sends TCP SYN segment to server客户端发SYN段 specifies initial seq #指明序列号 no data没有数据 Step 2: server host receives SYN, replies with SYNACK segment回复 ACK段 server allocates buffers分配缓存 specifies server initial seq. #定义 服务端序号 Step 3: client receives SYNACK, replies with ACK segment, which may contain data客户端接收ACK回复 ACK段，里面没有数据 TCP Connection Management (cont.) Closing a connection:关闭连 接 client closes socket: clientSocket.close(); 客户端关闭socket Step 1: client end system sends TCP FIN control segment to server 客户端发 送FIN控制段 Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN. 服务 器端发FIN的确认，关闭连接 ，发送FIN client FIN server ACK ACK FIN close close closed timed wait TCP Connection Management (cont.) Step 3: client receives FIN, replies with ACK. 客户端收到 FIN回复确认 Step 4: server, receives ACK. Connection closed. 服务器端 收到确认，关闭连接 client FIN server ACK ACK FIN closing closing closed timed wait closed 服务器 SYN = 1, seq = x CLOSEDCLOSED 主动打开 被动打开 A B 客户 TCP 的连接建立用三次握手建立 TCP 连接 A 的 TCP 向 B 发出连接请求报文段，其首部中的 同步位 SYN = 1，并选择序号 seq = x，表明传送 数据时的第一个数据字节的序号是 x。 服务器 SYN = 1, seq = x SYN = 1, ACK = 1, seq = y, ack= x 1 B 的 TCP 收到连接请求报文段后，如同意，则 发回确认。 B 在确认报文段中应使 SYN = 1，使 ACK = 1， 其确认号 ack = x 1，自己选择的序号 seq = y。 CLOSEDCLOSED 主动打开 被动打开 A 客户 B TCP 的连接建立用三次握手建立 TCP 连接 服务器 SYN = 1, seq = x ACK = 1, seq = x + 1, ack = y 1 SYN = 1, ACK = 1, seq = y, ack= x 1 A 收到此报文段后向 B 给出确认，其 ACK = 1， 确认号 ack = y 1。 A 的 TCP 通知上层应用进程，连接已经建立。 主动打开 被动打开 A 客户 B 通知 应用 进程 服务器 SYN = 1, seq = x ACK = 1, seq = x + 1, ack = y 1 数据传送 SYN = 1, ACK = 1, seq = y, ack= x 1 B 的 TCP 收到主机 A 的确认后，也通知其上层 应用进程：TCP 连接已经建立。 以后就可以传送数据了。 主动打开 被动打开 A 客户 B 通 知 应 用 进 程 ACK = 0, seq = x + 1, ack = y 1 在数据包丢失、重复和延迟的情况下， 3次握手法是保证连接无二义性的充要条件。 FIN = 1, seq = u 主动关闭 数据传送 A B 客户 服务器 CLOSED TCP 的连接释放 数据传输结束后，通信的双方都可释放连接。 现在 A 的应用进程先向其 TCP 发出连接释放 报文段，并停止再发送数据，主动关闭 TCP 连接。 A 把连接释放报文段首部的 FIN = 1，其序号 seq = u，等待 B 的确认。 被动关闭 FIN = 1, seq = u ACK = 1, seq = v, ack= u 1 数据传送 通知 应用 进程 B 发出确认，确认号 ack = u 1， 而这个报文段自己的序号 seq = v。 TCP 服务器进程通知高层应用进程。 从 A 到 B 这个方向的连接就释放了，TCP 连接 处于半关闭状态。B 若发送数据，A 仍要接收。 主动关闭 数据传送 A B 客户 服务器 TCP 的连接释放 被动关闭 FIN = 1, seq = u ACK = 1, seq = v, ack= u 1 FIN = 1, ACK = 1, seq = w, ack= u 1 被动关 闭 数据传送 若 B 已经没有要向 A 发送的数据， 其应用进程就通知 TCP 释放连接。 数据传送 主动关闭 数据传送 A B 客户 服务器 TCP 的连接释放 被动关闭 通知 应用 进程 半关闭状态 FIN = 1, seq = u ACK = 1, seq = v, ack= u 1 ACK = 1, seq = u + 1, ack = v 1 FIN = 1, ACK = 1, seq = v, ack= u 1 半关闭状态 关闭状态 数据传送数据传送 主动关闭 数据传送 A B 客户 服务器 被动关闭 通知 应用 进程 被动关闭 A 向 B 发送确认后，TCP 连接进入关闭状态。 Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control TCP reliable data transfer TCP creates rdt service on top of IPs unreliable service TCP在IP层之上提供了可靠的数据出传输服务 Pipelined segments 段的流水线传输 Cumulative acks累计确认 TCP uses single retransmission timer TCP使用单个重传时 钟 Retransmissions are triggered by:重传被下面事件触发 timeout events超时事件 duplicate acks重复确认 TCP: retransmission scenarios重传方案 Host A Seq=100, 20 bytes data ACK=100 time premature timeout 过早超时 Host B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data Seq=92 timeout ACK=120 Host A Seq=92, 8 bytes data ACK=100 loss timeout lost ACK scenario Host B X Seq=92, 8 bytes data ACK=100 time Seq=92 timeout SendBase = 100 SendBase = 120 SendBase = 120 Sendbase = 100 TCP retransmission scenarios (more) Host A Seq=92, 8 bytes data ACK=100 loss timeout Cumulative ACK scenario累计确认 Host B X Seq=100, 20 bytes data ACK=120 time SendBase = 120 Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control TCP Flow Control receive side of TCP connection has a receive buffer:接收方有 一个接收缓冲区 speed-matching service: matching the send rate to the receiving apps drain rate速度匹配：将发送方的 发送速率和接收方的排空速 率匹配 app process may be slow at reading from buffer应用程序从 缓冲区读数据可能会比较慢 sender wont overflow receivers buffer by transmitting toomuch, too fast不会由于发送方发太多发 太快而让接收方缓冲区溢出 flow control TCP Flow control: how it works (Suppose TCP receiver discards out-of-order segments) spare room in buffer = RcvWindow = RcvBuffer-LastByteRcvd - LastByteRead 假设TCP将失序的段丢弃 缓冲区的空闲空间=接收窗口大小=接收缓冲区-（最后一个接收到的字节- 应用程序最后一个读的字节） Sender limits unACKed