1 / 75

传输层和 TCP

传输层和 TCP. E-mail ： 24035234@qq.com 主页： xgxy.cug.edu.cn/rjgcx/lzw. 日程安排（ Agenda ）. 传输层（ Transport Layer ） TCP. 传输层（ Transport Layer ）. 传输层的角色 Role of Transport Layer. 应用层（ Application layer ） 特殊应用的通信 如 , 超文本传输协议 (HTTP), 文件传输协议 (FTP), 网络新闻传输协议 (NNTP) Transport layer

kennan-sosa
Download Presentation

传输层和 TCP

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. 传输层和TCP E-mail：24035234@qq.com 主页：xgxy.cug.edu.cn/rjgcx/lzw

  2. 日程安排（Agenda） • 传输层（Transport Layer） • TCP

  3. 传输层（Transport Layer）

  4. 传输层的角色Role of Transport Layer • 应用层（Application layer） • 特殊应用的通信 • 如, 超文本传输协议 (HTTP), 文件传输协议 (FTP), 网络新闻传输协议 (NNTP) • Transport layer • Communication between processes (e.g., socket) • Relies on network layer; serves the application layer • E.g., TCP and UDP • Network layer • Logical communication between nodes • Hides details of the link technology • E.g., IP

  5. 传输层的角色 • Application layer • Communication for specific applications • E.g., HyperText Transfer Protocol (HTTP), File Transfer Protocol (FTP), Network News Transfer Protocol (NNTP) • Transport layer • Communication between processes (e.g., socket) • Relies on network layer; serves the application layer • E.g., TCP and UDP • 网络层 • 结点间的全局通信 • 隐藏链路技术的细节 • 如, IP

  6. 传输层的角色 • Application layer • Communication for specific applications • E.g., HyperText Transfer Protocol (HTTP), File Transfer Protocol (FTP), Network News Transfer Protocol (NNTP) • 传输层 • 进程间通信(如, socket) • 依赖于网络层; 服务于应用层 • 如, TCP 和 UDP • Network layer • Logical communication between nodes • Hides details of the link technology • E.g., IP

  7. 传输层的角色 • 为应用层提供公共的端到端服务 • 为应用处理网络（Deal with network on behalf of applications） • 为网络处理应用（Deal with applications on behalf of networks） • 本可以在应用中构建, 但希望实现公共部分以使应用开发容易一些 • 由于TCP运行于端主机, 这是关于软件模块化, 而非全局网络结构

  8. 此处应该解决什么问题? • 应用按文件来思考 • 网络处理包 • 传输层需要在两者间转换 • 主机把传入的数据放在哪里? • IP 仅指向下一层协议 • 如何将数据放到正确的应用中? • 传输需要组合（demultiplex）传入的数据 • 可靠性 (对于应用需要的场合) • 失效（Corruption）? • 公平地共享网络?

  9. 处理这些需要些什么? • 在字节流和包间进行翻译 • 仅跟踪流中的数据 • 发送端不应覆盖（overwhelm）接收端的缓冲区 • 合成（Demultiplexing）: 应用进程标识 • 可靠性: 应答ACK及相关内容 • 还没有讨论的问题: 环路时间（RTT）估计, 格式 • 损坏: 校验和checksum • 公平地共享网络: 本学期后部

  10. 结论? • 传输层非常容易! • 本节余下的内容将深入细节（Rest of lecture just diving into details） • 但要等到拥塞控制时（But just wait until you get to congestion control）…

  11. 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 传输协议的逻辑视图 • 为运行于不同主机的应用进程提供 逻辑通信 • 运行于端主机 • 发送端: 将应用消息分成块, 并传递到网络层 • 接收端: 重组块为消息, 发送到应用层 • 对于应用层有多个传输协议 • Internet: TCP和UDP (主要)

  12. UDP 和 TCP: 非常不同 • 数据报消息服务 (UDP) • “最佳效果best-effort” IP的无褶扩展 • 进程间Multiplexing/Demultiplexing • 可靠, 在序发送 (TCP) • 连接建立和挂机 • 丢弃损坏包 • 丢失包重发 • 流控制 • 拥塞控制 • 服务不可用 • 延时 和/或 确保带宽 • 会话在改变IP地址时存活

  13. 4-bit Header Length 8-bit Type of Service (TOS) 4-bit Version 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

  14. 8-bit Type of Service (TOS) 5 4 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Payload

  15. 8-bit Type of Service (TOS) 5 4 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 6 = TCP17 = UDP 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Payload

  16. 8-bit Type of Service (TOS) 5 4 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 6 = TCP17 = UDP 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address 16-bit Source Port 16-bit Destination Port More transport header fields …. Payload

  17. 主机接收IP数据报 每个数据报都有源和目标IP 地址, 每个数据报携带一个传输层段 每个段有源端口和目标端口号 主机使用IP地址和端口号将块导向合适的套接字socket 对移动性的含义? 复用及合成Multiplexing and Demultiplexing 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format

  18. 端口 • 需要确定哪个应用得到哪个包 • 解决方案: 将每个套接字映射到一个端口 • 客户机必须知道服务器端口 • 对UDP和TCP使用分离的16位端口地址空间 • (src_IP, src_port, dst_IP, dst_port)确定 TCP连接 • 什么是连接? • 关于UDP如何? • 著名端口(0-1023): 每个人都同意在这些端口上运行何种服务 • 如, ssh:22, http:80 • 短暂端口(49152 到 65535可变的): 指定给客户端 • e.g. 聊天客户端, p2p网络

  19. UDP: 不可靠的发送 • 进程间轻量级通信 • 避免由于重新排序，可靠传递带来的延时和超载 • 发送消息到套接字，并从套接字接收消息 • 用户数据报协议 (UDP; RFC 768 - 1980!) • IP 加上端口号支持（反）复用(de)multiplexing • 对包内容的错误检查（可选） • (校验和字段 = 0 意即 “不检查校验和checksum”) SRC port DST port checksum length DATA

  20. 为什么有人使用UDP? • 对发送何种数据及何时发送的细粒度控制 • 应用进程一写到套接字中，就发送 • … UDP将包装数据并发送包 • 连接建立无延时 • UDP 仅发送（blasts away）而没有任何正式的预先要求 • … 从而避免引入任何不必要的延时 • 无连接状态 • 无缓冲区分配, 序列号, 时钟 … • … 使一次处理多个活动的客户端较易 • 较小的包头负担 • UDP头只有8个字节

  21. “Address for bbc.co.uk?” “212.58.224.131” 使用UDP的知名应用 • 多媒体实时流 • 重发丢失/损坏的包通常是无意义的（pointless）- 在包重发时，已经太晚了 • 如., 打电话, 视频会议, 游戏 • 现代流协议使用TCP (和HTTP) • 简单查询协议如域名系统 • 连接建立延时将使费用加倍 • 如果需要让应用重发会比较简单

  22. 传输控制协议 (TCP) • 基于连接的(今天) • 显式建立和挂断TCP会话（session） • 字节流（Stream-of-bytes）服务(今天) • 发送和接收字节流，而非消息 • 拥塞控制(后面讲) • 对网络路径的容量，动态适应 • 可靠, 在序发送 (前面讲了, 但快速复习) • 确保字节流 (最终)完整无缺的到达 • 会有损坏和丢失 • 流控制(前面讲了, 但快速复习) • 确保发送端不淹没（overwhelm）接收端

  23. TCP

  24. TCP支持可靠的发送 • 校验和（Checksum） • 用于在接收端检测数据损坏 • …导致接收端丢弃包 • 序列号（Sequence numbers） • 用于检查数据丢失 • ... 并以原来的顺序把数据整合好 • 重发（Retransmission） • 发送端重发丢失或者损坏的数据 • 基于对环路时间的超时检查 • 快速重传算法用于快速重传

  25. TCP头 Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data

  26. TCP头 Source port Destination port 这些应该 是熟悉的 Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data

  27. TCP头 Source port Destination port 此段中携带数据的起始序列号 (字节偏移) Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data

  28. TCP头 Acknowledgment （应答）给出接收到的最高有序序列号后的序列号 “下一个是什么” 如果接收端发送从序列号S开始的N个有序字节，那么其ack将是S+N. Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data

  29. 应答（ACKing）和序列号 • 发送端发送包 • 数据从序列号X开始 • 包含有B个字节 • X, X+1, X+2, ….X+B-1 • 在接收到包后, 接收端发送ACK • 如果X之前的所有数据都已经接收到: • ACK应答 X+B (因为那是下一个期望的字节) • 如果已经接收到的最高字节是某个较小的值Y • ACK应答Y+1 • 即使之前已经被应答过

  30. TCP头 Source port Destination port Sequence number TCP滑动窗口用于接收数据的可用缓冲区空间. 被解释成应答字段值之外的偏移 Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data

  31. 滑动窗口流控制 • 公告窗口: W • 可以发送在下一个期望字节后的W个字节 • 接收端使用W来防止发送端冲跨缓冲区 • 发送端在路上（ in flight）的限制字节数

  32. 滑动窗口的性能 • 考虑 UCB和NYC间的1 Mbps路径(100msec RTT) • Q1: 窗口W=12.5KB时，能传输多快? • A: 12.5KB/100msec ~ 1Mbps (可以填满管道) • Q2: 如果路径是1Gbps怎么样? • A2: 仍然可以发送1Mbps • 窗口需要完全使用路径: • 带宽-延时之乘积 • 1 Gbps * 100 msec = 100 Mb = 12.5 MB • 注: 大窗口 = 路上（in flight）的包更多

  33. 公告窗口限制率 • 发送端的发送速度不超过 W/RTT bytes/sec • 接收端在处理了已经到达的数据后，公告有更多的空间 • 在最初的TCP设计中, 这是控制发送端速率的唯一协议机制 • 丢失了什么?

  34. 实现滑动窗口 • 发送端和接收端都维护一个窗口 • 发送端: 还未应答的（ACK’ed） • 接收端: 还未发送到应用的 • 窗口的左边界 : • 发送端: 未应答数据的开始 • 接收端: 未发送数据的开始 • 对于发送端: • 窗口大小 = 在发送路上的数据最大值 • 对于接收端: • 窗口大小 = 未发送数据的最大值

  35. Sender Window Receiver Window 滑动窗口 • 允许更大的数据在传递中“in flight” • 允许发送端比接收端在更前面 • … 尽管在前面不是很远 发送进程 接收进程 TCP TCP Last byte read Last byte written Next byte needed Last byte ACKed Last byte received Last byte can send

  36. 滑动窗口（续） • 发送端: 在新数据应答后，窗口前进 • 接收端: 在进程消费数据后窗口前进 • 接收端向发送端公告，其窗口当前在何处结束 (“右手边界”) • 发送到不走过此界限 • 通过设置其窗口大小的值为不超过接收端的右边界来确保

  37. Sender Window 滑动窗口 • 对于发送端, 当收到新数据的回应时, 窗口前进 (向前滑动) Sending process TCP Last byte written Last byte ACKed Last byte can send

  38. Sender Window 滑动窗口 • 对于发送端, 当收到新数据的回应时, 窗口前进 (向前滑动) Sending process TCP Last byte written Last byte ACKed Last byte can send

  39. Receiver Window 滑动窗口 • 对接收端, 当接收进程处理（consumes）数据后, 窗口向前滑动 Receiving process TCP Last byte read Next byte needed Last byte received

  40. 滑动窗口 • 对接收端, 当接收进程处理（consumes）数据后, 窗口向前滑动 Receiving process TCP Last byte read Next byte needed Receiver Window Last byte received

  41. TCP头 Source port Destination port Sequence number TCP头中以4-字节的字为单位的个数;5 = 无选项（options）时 Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data

  42. TCP头 Source port Destination port Sequence number “必须是零”保留6位 Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data

  43. TCP头 Source port Destination port Sequence number 很快会论及此 Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data

  44. TCP头 Source port Destination port Sequence number 用于URG标志以表示紧急数据 (不作进一步讨论) Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data

  45. 5 Minute Break

  46. Anagram Contest • What does this numerical anagram have to do with this alphabetical one? Don’t ignore capitals…. • Alphabetical: Stern Alpaca • Numerical: 01277779

  47. Anagram Contest • What does this numerical anagram have to do with this alphabetical one? Don’t ignore capitals…. • Alphabetical: Stern Alpaca • Numerical: 01277779 • Lancaster, PA was capital of US on 09/27/1777

  48. 分段与序列号

  49. TCP“字节流”服务 主机A Byte 0 Byte 1 Byte 2 Byte 3 Byte 80 主机B Byte 0 Byte 1 Byte 2 Byte 3 Byte 80

  50. 在…条件下使用TCP“分段” Host A Byte 0 Byte 1 Byte 2 Byte 3 Byte 80 • 当…时分段: • 段满 (最大段尺寸), • 未满, 但超时, 或 • 由应用“推动Pushed”. TCP Data TCP Data Host B Byte 0 Byte 1 Byte 2 Byte 3 Byte 80

More Related