主页：xgxy.cug.edu.cn/rjgcx/lzw 传输层和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 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

传输层的角色 Application layer Transport 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

传输层的角色 Application layer 传输层 Network 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

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

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

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

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

logical end-end transport 传输协议的逻辑视图 为运行于不同主机的应用进程提供 逻辑通信 运行于端主机 发送端: 将应用消息分成块, 并传递到网络层 接收端: 重组块为消息, 发送到应用层 对于应用层有多个传输协议 Internet: TCP和UDP (主要) application transport network data link physical network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical

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

Payload 16-bit Total Length (Bytes) 16-bit Identification 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

4 5 Payload 16-bit Total Length (Bytes) 16-bit Identification Type of Service (TOS) 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

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

4 5 Payload 16-bit Total Length (Bytes) 16-bit Identification Type of Service (TOS) 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 6 = TCP 17 = 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

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

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

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

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

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

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

TCP

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

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

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

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

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

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

TCP头 Data Source port Destination port Sequence number 被解释成应答字段值之外的偏移 Acknowledgment HdrLen Flags Advertised window Checksum Urgent pointer Options (variable) Data

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Minute Break

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

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

分段与序列号

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

在…条件下使用TCP“分段” Host A 当…时分段: Host B 段满 (最大段尺寸), 未满, 但超时, 或 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

TCP段（Segment） IP包 TCP包 TCP段（segment） 不大于最大传送单元 (MTU) 如, 在以太网中最多1,500字节 IP Data TCP Data (segment) TCP Hdr IP Hdr IP包 不大于最大传送单元 (MTU) 如, 在以太网中最多1,500字节 TCP包 IP包中带有TCP头和数据 TCP头 20字节长 TCP段（segment） 不多于最大段尺寸 (MSS) 字节 例, 流中的最大1460个连续的字节 MSS = MTU – (IP头) – (TCP头)

序列号 主机A 主机B ISN (初始序列号) 序列号 =首字节 TCP Data 应答（ACK） 序列号 = 下一个期望的字节 HDR 应答（ACK） 序列号 = 下一个期望的字节 TCP Data TCP HDR 主机B

初始序列号 (ISN) 最开始字节的序列号 实际问题 因此，TCP需要改变ISN 在建立连接时, 主机交换ISNs IP地址和端口号唯一确定一个连接 尽管最终这些端口号会两次使用 … 一个旧包还在传送(still in flight)的机率很小 … 并且可能与一个新的连接相关联 因此，TCP需要改变ISN 由32位时钟，每 4微秒走一次来设置 … 仅在每4.55小时循环一次 在建立连接时, 主机交换ISNs

建立连接:TCP三次握手

建立TCP连接 三次握手建立连接 B A 每个主机把其ISN 告知其他主机 SYN 每个主机把其ISN 告知其他主机 SYN ACK ACK Data 三次握手建立连接 主机A发送一个同步SYN (open; “同步序列号”) 给主机B 主机B返回一个同步应答 (SYN ACK) 主机A发送一个ACK来应答SYN ACK

TCP头 Data Source port Destination port Sequence number Flags: SYN ACK FIN RST PSH URG Acknowledgment HdrLen Flags Advertised window Checksum Urgent pointer Options (variable) Data 参见Unix系统中的/usr/include/netinet/tcp.h

A告知B它希望开始（Open）一个连接… 第1步: A的初始SYN包 A’s port B’s port A’s Initial Sequence Number Flags: SYN ACK FIN RST PSH URG (Irrelevant since ACK not set) 5=20B Flags Advertised window Checksum Urgent pointer Options (variable) A告知B它希望开始（Open）一个连接…

第2步: B的SYN-ACK包 B’s port A’s port B’s Initial Sequence Number Flags: FIN RST PSH URG ACK = A’s ISN plus 1 20B Flags Advertised window Checksum Urgent pointer Options (variable) B告知A它接收, 并且准备好听下一个字节… … 在接收到此包后, A可以开始发送数据

A 告知 B 现在差不多已经可以开始发送数据了 第3步: A对SYN-ACK的应答 A’s port B’s port A’s Initial Sequence Number Flags: SYN ACK FIN RST PSH URG B’s ISN plus 1 20B Flags Advertised window Checksum Urgent pointer Options (variable) A 告知 B 现在差不多已经可以开始发送数据了 … 在接收到包后, B可以开始发送数据

SYN + ACK, SeqNum = y, Ack = x + 1 时序图: 3次握手 被动 Open 主动 Open 服务器 listen() 客户端 (发起者) connect() SYN, SeqNum = x SYN + ACK, SeqNum = y, Ack = x + 1 ACK, Ack = y + 1 accept()

如果应答（SYN）包丢失会怎样? 假设SYN包丢失 最终结果是没有SYN-ACK到达 TCP发送端该怎样设置定时器? 包在网络中丢失, 或: 服务器丢弃该包 (如, 侦听队列满) 最终结果是没有SYN-ACK到达 发送端设置定时器并等待 SYN-ACK … 并在必要时重传SYN TCP发送端该怎样设置定时器? 发送端对接收端距离多远没有任何信息 很难猜出一个合理的等待时间 应该 (RFCs 1122 & 2988) 使用缺省的3秒 其它实现，取而代之使用6秒

SYN丢失及Web下载 用户点击超级连接 如果SYN丢失… 用户触发一个“连接”的“中止” 浏览器创建套按字并进行一个“连接” 延时3-6秒: 可以是非常长 用户可能不耐烦 … 两次点击超级链接, 或点击“reload” 用户触发一个“连接”的“中止” 浏览器建立一个新套接字及另一个“连接” 基本的, 强制一个更快的发送一个新的SYN包! 有时非常有效, 且页面很快就过来了

挂断连接

正常终止, 一次一边 B A 结束 (FIN) 以关闭并接收余下的字节 其它主机应答应答一个8位字节来确认 关闭A端连接, 但B端不关闭 ACK FIN ACK ACK SYN SYN ACK Data ACK 现在连接半关闭 A 现在连接关闭 超时 避免再生 如果ACK丢失 B将重新发送FIN time 结束 (FIN) 以关闭并接收余下的字节 FIN 在序列空间中占用一个8位字节 其它主机应答应答一个8位字节来确认 关闭A端连接, 但B端不关闭 直到B同样发送一个FIN 然后A作应答 Why timer? Will get packet with no state!!

正常终止, 两边一起 和之前一样, 但B用A的FIN的应答来设置FIN B A FIN FIN + ACK ACK ACK SYN SYN ACK Data ACK A 现在连接关闭 time 超时 避免再生 如果ACK丢失 B将重新发送FIN 和之前一样, 但B用A的FIN的应答来设置FIN

突然终止 B A RST Data RST ACK SYN SYN ACK Data ACK A发送一个RESET (RST)给B 即 time A发送一个RESET (RST)给B 如, 因为A上的应用进程崩溃 即 B不应答RST 从而, RST未可靠的发送 并且: 任何传输中数据丢失 但: 如果B发送任何更多内容, 并将引出另一RST

可靠性: TCP重发

设置超时值 发送端设置一个超时以等待应答（ACK） TCP 设置重发超时 (RTO) 为RTT的函数 但: 如何测量RTT? 太短: 不必要的重浪费带宽 太长: 当包丢失时有附加的延时 TCP 设置重发超时 (RTO) 为RTT的函数 期望ACK在发送数据后大约RTT时间到达 … 加一点松驰以允许一些可变因素 (如, 排队, MAC) 但: 如何测量RTT? 且: 对RTT的好的估计是什么样的? 且: 对“slop”的好的估计是什么?

问题: 含糊的测量 如何区分实际的ACK和重发包的ACK? Sender Receiver Sender Receiver Original Transmission Original Transmission SampleRTT ? ACK SampleRTT ? Retransmission Retransmission ACK

Karn/Partridge算法 仅对初次发送测量SampleRTT 同样, 使用指数回退（backoff） 一旦一个段被重发, 不对其作进一步测量 同样, 使用指数回退（backoff） 每次RTO定时期过期, 设置RTO  2·RTO (直到到达最大值  60 sec) 每次新的测量到达 (= 初始发送成功), 将RTO折到计算值 RTO ： retransmision time out

下一步 将单次RTT测量值转换成RTT的一个估计，使我们能用其进行计算RTO 挑战: 对RTT平均, 但最近值更重要

指数平均 指数平均: Estimate(n) = α Estimate(n-1) + (1-α) Value(n) 展开: Estimate(n) = (1-α) Sum {αk Value(n-k)} 历史数据的权重指数减少

RTT 估计 使用指数平均: SampleRTT EstimatedRTT Time

Jacobson/Karels算法 用观察变化计算 “slop” 标准差需要昂贵的求平方根运算 取而代之，使用平均差 Deviation = | SampleRTT – EstimatedRTT | EstimatedDeviation: 对方差进行指数平均 RTO = EstimatedRTT + 4 x EstimatedDeviation

这一切都很有意思, 但….. 实现通常使用粗-粒度时钟 又怎样? 因此我们依赖于重复ACKs 典型的是500毫秒 以上算法很大程度上无关 招致超时是昂贵的 因此我们依赖于重复ACKs