tcp understandings

TCP Understandings

2010 年 12 月

主讲：孟宁电话： 0512-68839302E-mail ： mengning@ustc.edu.cn主页： http://staff.ustc.edu.cn/~mengning地址：苏州工业园区独墅湖高等教育区仁爱路 166 号明德楼 A302室

TCP Understandings

♦ 字节流与序号♦ Port Numbers

♦ Concurrent Servers

♦ TCP 的交互数据流– Nagle 算法

♦ TCP 的成块数据流– 滑动窗口协议，慢启动，拥塞控制

TCP Basis

传输层的责任：1. 创建进程到进程的通信2. 提供传输层控制机制（流量控制、差错控制、分组确认等）3. 为进程提供连接机制

TCP通过使用端口号来完成进程到进程的通信使用滑动窗口协议完成流量控制使用确认分组、超时和重传来完成差错控制

TCP 是面向连接的、可靠的传输协议TCP 是专门设计用于在不可靠的 Internet 上提供可靠的、

端到端的字节流通信的协议。

Stream Delivery Service

TCP是专门设计用于提供可靠的、端到端的字节流通信的协议，它使得进程与进程之间好像如同由“管道”连接一般。

发送方 TCP 实体将应用程序的输出流分为不超过 64k 字节（实际通常为 1500 字节）的数据片段（ piece ），并将每个数据片段封装在一个IP 分组中发送出去。 接收方 TCP 实体根据字节序号（ 32 位）将接收到的各个数据片段组装成连续的字节流交给应用程序。

buffers of a TCP socket

Sending and receiving buffers

白色：表示空位置灰色：已发送但还没确认字节红色：将要发送的字节

白色：表示空位置红色：接收到的字节

TCP segments

报文段：若干个字节构成的 TCP分组，报文段的长度不尽相同，大约是几百字节～几千字节。

字节编号与序号♦ 字节号： TCP 对所有发送的字节都编了号。♦ 起始字节号：第一个字节的编号，在 0 ～

232-1 之间随机产生的一个数。♦ 序号： TCP 给每个报文指派一个序号，该

序号就是该报文段中的第一个字节数据的字节号。

♦ 确认号： TCP 通信中的一方期望接收的下一个字节的编号。（确认号是累计的）

TCP segments Example

Suppose a TCP connection is transferring a file of 5000 bytes. The first byte is numbered 10001. What are the sequence numbers for each segment if data is sent in five segments, each carrying 1000 bytes?SolutionThe following shows the sequence number for each segment:

Segment 1 ➡ Sequence Number: 10,001 (range: 10,001 to 11,000)

Segment 2 ➡ Sequence Number: 11,001 (range: 11,001 to 12,000)

Segment 3 ➡ Sequence Number: 12,001 (range: 12,001 to 13,000)

Segment 4 ➡ Sequence Number: 13,001 (range: 13,001 to 14,000)

Segment 5 ➡ Sequence Number: 14,001 (range: 14,001 to 15,000)

Port Numbers

50000

Well-known ports used by TCPWell-known ports used by TCP

Concurrent Servers

•使用一个四元组来标识一个连接：（本机 IP ：端口号，对端 IP ：端口号）

TCP 的交互数据流♦ 按分组数量计算，一半的 TCP 报文段包含

块数据，一半则包含交互数据♦ 按字节计算，则成块数据与交互数据的比

例约为 90% 和 10%

♦ 显然 TCP 需要处理这两类数据，但是处理算法则有所不同

♦ 经受时延的确认和 Nagle 算法

经受时延的确认♦ 通常 TCP 在接收到数据时并不立即发送 A

CK ，而是推迟发送，以便将 ACK 与需要沿改方向发送的数据一起发送。也称为“数据捎带 ACK” 。

♦ 绝大多数实现采用时延 200ms

♦ 检测超时使用 500ms 的定时器

Nagle 算法 [RFC896]

♦ 交互数据产生的小分组在广域网上会增加拥塞的可能性。

♦ Nagle 算法要求一个 TCP 连接最多只能有一个未被确认的小分组，在该分组的确认到达之前不能发送其他的小分组。同时 TCP 收集这些小分组，并在确认到来时以一个分组的方式发送出去。

♦ 自适应性：确认到达的越快，数据也就发送得越快。

关闭 Nagle 算法♦ 对时延要求高的应用有时需要关闭 Nagle

算法，比如 X 窗口系统服务器，鼠标移动必须无时延发送。

♦ Socket API 用户可以使用 TCP_NODELAY选项来关闭 Nagle 算法。

停止等待协议♦ 数据发送方在发送下一个数据块之前需要

等待接收已发送数据的确认。♦ 发送方必须每发送一个分组就停下来等待

确认。♦ TFTP 协议即使用这种方法传送数据。

滑动窗口协议♦ 滑动窗口覆盖缓存的一部分，这部分（即

窗口）就是主机可以发送而不必考虑从另一个主机发来的确认。当发送出的数据得到确认时，这个窗口便在缓存上滑动。

♦ TCP 的滑动窗口是面向字节的。

Example

窗口大小♦ 接收缓存的大小是该连接上所能够通告的最大窗口大小

♦ 发送和接收缓冲区的大小– 4.2BSD 是 2K– 4.3BSD 是 4K– 8K– 16K

慢启动 slow start

♦ 在发送方与接收方之间存在多个路由器和速率较慢的链路时，一些路由器缓存分组过多可能导致耗尽存储空间。

♦ 因而 TCP 需要一种算法来使新分组进入网络的速率与另一端返回确认的速率相同。

♦ 慢启动 slow start 算法为发送方增加另一个窗口 -- 拥塞窗口（ congestion window,cwnd ）

慢启动 slow start 算法♦ 拥塞窗口初始化为 1 个报文（ cwnd 以字节

为单位，但慢启动以报文段大小为单位增加）

♦ 发送方取minimum(cwnd,rwnd) 为发送上限

♦ 发送方发送一个报文然后等待 ACK ，收到ACK 则拥塞窗口从 1变为 2 ，即可发送 2个报文，收到 2 个 ACK ，拥塞窗口就增加为 4 ，这是一种指数增加关系。

拥塞控制

♦ 由于当前网络传输介质的可靠性越来越高，所以 TCP假定超时（丢失报文）就是网络拥塞造成的，可根据超时来判断是否发生拥塞。

♦ 网络和接收方的容量是造成拥塞的两个潜在问题，发送方必须维持两个窗口：接收方承认的窗口和拥塞窗口，发送的有效窗口是这两个窗口中较小的一个。

拥塞控制算法♦ Internet的拥塞控制算法：初始设置门限（临界）值

（ threshold ）为 64kB ，若发生超时，将临界值设为当前拥塞窗口的 1/2 ，并将拥塞窗口恢复为最大段长度，执行慢启动算法，直至拥塞窗口达到临界值，此后要求拥塞窗口按线性增加（每次只增加一个最大段长度），直至最终达到接收窗口大小或发生超时；若超时再将临界值设为当前拥塞窗口的 1/2 ，重复上述过程。

慢启动与拥塞避免

快速重传与快速恢复

TCP congestion policy

TCP 软件包

传输控制块 TCBs

虚线：服务器端

实线：客户机端

红线：非正常情况

MSL:30s～ 120s

主模块接收： TCP 报文段、或来自应用程序的报文、或超时事件

1.查找 TCB表。2.若（相应的 TCB未找到）

1.创建 TCB项目，并设定它的状态为 CLOSED

3.找到相应的 TCB表项的状态。

Case （状态）♦ CLOSED:♦ LISTEN:♦ SYN-SENT:♦ SYN-RCVD:♦ ESTABLISHED:♦ FIN-WAIT-1:♦ FIN-WAIT-2:♦ CLOSING:♦ TIME-WAIT:♦ CLOSE-WAIT:♦ LAST-ACK:

CLOSED:

1.若（收到来自应用程序的“被动打开”报文）1.把状态改为 LISTEN 。

2.若（收到来自应用程序的“主动打开”报文）1.发送 SYN 报文段。2.把状态改变为 SYN-SENT 。

3.若（收到任何报文段）1.发送 RST 报文。

4.若（收到任何其他报文段）1.发出差错报文。

5.返回

LISTEN:

1.若（收到来自应用程序的“发送数据”报文）1.发送 SYN 报文段。2.把状态改变为 SYN-SENT 。

2.若（收到 SYN 报文段）1.发送 SYN＋ ACK 报文段。2.把状态改变为 SYN-RCVD 。

3.若（收到任何其他报文段或报文）1.发出差错报文。

4.返回。

SYN-SENT:

1.若（超时）1.把状态改变为 CLOSED 。

2.若（收到 SYN 报文段）1.发送 SYN＋ ACK 报文段。2.把状态改变为 SYN-RCVD 。

3.若（收到 SYN+ACK 报文段）1.发送 ACK 报文段。2.把状态改变为 ESTABLISHED 。

4.若（收到任何其他报文段或报文）1.发出差错报文。

5.返回

SYN-RCVD:

1.若（收到 SYN 报文段）1.把状态改变为 ESTABLISHED 。

2.若（超时）1. 发送 RST 报文段。2.把状态改变为 CLOSED 。

3.若（收到来自应用程序的“关闭”报文）1. 发送 FIN 报文段。2.把状态改变为 FIN-WAIT-1 。

4.若（收到 RST 报文段）1.把状态改变为 LISTEN 。

5.若（收到任何其他报文段或报文）1. 发出差错报文。

6.返回。

ESTABLISHED:

1.若（收到 FIN 报文段）1. 发送 ACK 报文段。2.把状态改变为 CLOSE-WAIT

2.若（收到来自应用程序的“关闭”报文）1. 发送 FIN 报文段。2.把状态改变为 FIN-WAIT-1 。

3.若（收到 RST或 SYN 报文段）1. 发出差错报文。

4.若（收到数据或 ACK 报文段）1.调用输入模块。

5.若（收到来自应用程序的“发送数据”报文）1.调用输出模块。

6.返回。

FIN-WAIT-1:

1.若（收到 FIN 报文段）1.发送 ACK 报文段。2.把状态改变为 CLOSING 。

2.若（收到 FIN+ACK 报文段）1.发送 ACK 报文段。2.把状态改变为 TIME-WAIT 。

3.若（收到 ACK 报文段）1.把状态改变为 FIN-WAIT-2 。

4.若（收到任何其他报文段或报文）1.发出差错报文。

5.返回。

FIN-WAIT-2:

1.若（收到 FIN 报文段）1.发送 ACK 报文段。2.把状态改变为 TIME-WAIT 。

2.返回

CLOSING:

1.若（收到 ACK 报文段）1.把状态改变为 TIME-WAIT 。

2.若（收到任何其他报文段或报文）1.发出差错报文。

3.返回

TIME-WAIT:

1.若（超时）1.把状态改变为 CLOSED 。

2.若（收到其他任何报文或报文段）1.发出差错报文。

3.返回。

CLOSE-WAIT:

1.若（收到来自应用程序的“关闭”报文）1.发送 FIN 报文段。2.把状态改变为 LAST-ACK 。

2.若（收到任何其他报文或报文段）1.发出差错报文。

3.返回。

输入模块♦ 处理数据♦ 发送 ACK

♦ 接收窗口大小的声明♦ checksum验证

输出模块♦ 发送数据♦ 超时重发数据重传计时器：处理重传时间，

即对确认报文的等待时间。♦ 坚持计时器：处理 0 接收窗口的等待时间。

谢谢大家！