计算机网络-第五章-运输层

5.1 运输层概述

之前所介绍的计算机网络体系结构中的物理层、数据链路层以及网络层，它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。
但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。

如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。

运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等)，它使应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道。

根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输协议，即
面向连接的TCP和无连接的UDP，这两种协议就是本章要讨论的主要内容。

5.2 端口号、复用和分用

端口号

运行在计算机.上的进程使用进程标识符PID来标志。

因特网上的计算机并不是使用统一的操作系统, 不同的操作系统(windows, Linux, Mac OS)又使用不同格式的进程标识符。

为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识。

TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程。

• 端口号使用16比特表示，取值范围0~65535：
  • 熟知端口号：0~1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议，例如：FTP使用21/20，HTTP使用80，DNS使用53
  • 登记端口号：1024~49151，为没有熟知端口号的应用程序使用。使用这类端口号必须在IANA按照规定的手续登记，以防止重复。例如：Microsoft RDP微软远程桌面使用的端口是3389
  • 短暂端口号：49152~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。
• 端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中不同计算机中的相同端口号是没有联系的。

复用与分用

发送方的复用和接收方的分用

多个进程 利用一个运输层协议（或者称为运输层接口）发送数据称为 复用

多个进程利用一个运输层协议（或者称为运输层接口）接收数据称为 分用。

运输层使用端口号来区分不同应用进程。

TCP/IP体系的应用层常用协议所使用的运输层熟知端口号

5.3、UDP和TCP的对比

• UDP 和 TCP 是TCP/IP体系结构运输层中的两个重要协议

• 使用UDP协议的通信双方可以随时发送数据
• 使用TCP协议的通信双方 ，在进行通信之前，必须使用三报文握手来建立连接；数据传输结束后，必须使用四报文挥手来释放连接。

正因如此，UDP支持单播、多播以及广播，而TCP只支持单播(因为要握手挥手)

---

下面来看具体的使用情况：

• UDP对应用进程交下来的报文既不合并也不拆分，而是保留这些报文的边界

换句话说，UDP是面向应用报文的

---

发送方

• TCP会把应用进程交付下来的数据块看作是一连串无结构的字节流，TCP并不知道这些待传送的字节流的含义，TCP会将他们编号，并存储在自己发送缓存中；
• TCP会根据发送策略，提取一定量的字节构建TCP报文并发送。

接收方

• 一方面从所接受到的TCP报文段中，取出数据载荷部分并存储在接收缓存中；一方面将接收缓存中的一些字节交付给应用进程；
• TCP不保证接收方应用进程所收到的数据块与发送方发送的数据块，具有对应大小的关系；
• 接收方的应用进程必须有能力识别收到的字节流，把它还原成有意义的应用层数据。

TCP是面向字节流的，这正是TCP实现可靠传输、流量控制、以及拥塞控制的基础

---

• UDP向上层提供无连接不可靠传输服务
  (适用于IP电话、视频会议等实时应用)
• TCP向上层提供面向连接的可靠传输服务
  (适用于要求可靠传输的应用，例如文件传输)

---

再来看一下UDP与TCP的首部格式

UDP：

TCP：

总结

用户数据报协议UDP(User Datagram Protocol)

• 无连接
• 支持一对一、一对多、多对一和多对多交互通信。
• 对应用层交付的报文直接打包，面向应用报文
• 尽最大努力交付，也就是不可靠；不使用流量控制和拥塞控制。
• 首部开销小，仅8字节

传输控制协议TCP(Transmission Control Protocol)

• 面向连接
• 每一条TCP连接只能有两个端点EP，只能是一对一通信。
• 面向字节流
• 可靠传输，使用流量控制和拥塞控制。
• 首部最小20字节，最大60字节

5.3 TCP的流量控制

• 一般来说，我们总是希望数据传输得更快一些。
  • 但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。
• 所谓流量控制(flow control)就是让发送方的发送速率不要太快，要让接收方来得及接收。
• 利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
  • TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小。
  • TCP发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文(零窗口探测报文也有重传计时器，不用担心丢失)

流程见下图：

发送窗口调控为0后，接收方调整报文若在发送过程中丢失可能导致发送方等待调控报文，接收方等待数据报文，引发死锁局面，为打破该局面，使用计时器和零窗口探测报文：

5.4 TCP的拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分， 网络性能就要变坏。这种情况就叫做拥塞(congestion)。

• 在计算机网络中的链路容量(即带宽)、 交换结点中的缓存和处理机等,都是网络的资源。

若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。

---

拥塞控制的四种算法

• 慢开始(slow-start)
• 拥塞避免(congestion avoidance)
• 快重传(fast retransmit)
• 快恢复(fast recovery)

下面介绍这四种拥塞控制算法的基本原理，假定如下条件：

1. 数据是单方向传送，而另一个方向只传送确认。
2. 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定。
3. 以最大报文段MSS的个数为讨论问题的单位，而不是以字节为单位。

• 发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。
  • 拥塞窗口cwnd的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大一些；但只要网络出现拥塞， 拥塞窗口就减少一些。
  • 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文(即发生超时重传)。
• 发送方将拥塞窗口作为发送窗口swnd，即swnd = cwnd。
  • 真正的发送窗口值 = Min(接收方窗口值，拥塞窗口值)
• 发送方还需维护一个慢开始门限ssthresh状态变量：
  • 当cwnd < ssthresh时，使用慢开始算法；
  • 当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法；
  • 当cwnd = ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。

---

下面具体介绍拥塞控制的四种算法，并用拥塞窗口与传输轮次的坐标图表示

传输轮次：

• 指发送方给接收方发送数据报文段后，接收方给发送方发发回相应的确认报文段
• 一个传输轮次所经历的时间其实就是往返时间，往返时间并非是恒定的数值
• 使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去，并受到了对已发送的最后一个报文段的确认

拥塞窗口：

• 它会随网络拥塞程度，以及所使用的拥塞控制算法动态变化

慢开始(slow-start)

• 目的：用来确定网络的负载能力或拥塞程度。
• 思路：由小到大逐渐增大拥塞窗口数值(加倍增加，指数增加)。
• 两个变量：
  • 拥塞窗口（cwnd）：初始拥塞窗口值：2 种设置方法。窗口值逐渐增大。
    • 1 至 2 个最大报文段 （旧标准）
    • 2 至 4 个最大报文段 （RFC 5681）
  • 慢开始门限（ssthresh）：防止拥塞窗口增长过大引起网络拥塞。

• 拥塞窗口成倍增加，直到大于慢开始门限值，此后要改用拥塞避免算法

拥塞避免(congestion avoidance)

• 思路：让拥塞窗口 cwnd 缓慢地增大，避免出现拥塞。每经过一个传输轮次，拥塞窗口 cwnd = cwnd + 1。
• 在拥塞避免阶段，具有 “加法增大” (Additive Increase) 的特点。

若在传输过程中出现部分报文段丢失，这必然会造成发送方对这些丢失报文段的超时重传。

若出现了重传计时器超时，那么系统判断网络很可能出现了拥塞，此时：

• 将ssthresh值更新为发生拥塞时cwnd值的一半
• 将cwnd重置为1，并重新开始执行慢开始算法

注：“慢开始”是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢；
“拥塞避免”并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞；

---

慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法(TCP Tahoe版本)。

• 有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。
  • 这将导致发送方超时重传，并误认为网络发生了拥塞；
  • 发送方把拥塞窗口cwnd又设置为最小值1，并错误地启动慢开始算法，因而降低了传输效率。

1990年又增加了两个新的拥塞控制算法(改进TCP的性能)，这就是快重传和快恢复(TCP Reno版本)。

快重传(fast retransmit)

所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。

• 要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认；
• 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认；
• 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
• 对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞(进而降低拥塞窗口cwnd为1)。使用快重传可以使整个网络的吞吐量提高约20%。

快恢复(fast recovery)

发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法。

• 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半；开始执行拥塞避免算法。
• 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些, 即等于新的ssthresh + 3。
  • 既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络
  • 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中；
  • 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。

---

整体算法执行过程：

5.6 TCP超时重传时间的选择

超时重传时间的选择是TCP最复杂的问题之一。

简单来说，超时重传时间RTO应该略大于往返时间RTT，但是由于TCP下面是复杂的互联网，不同情况下的RTT相差很大

• 如果超时重传时间RTO的值设置得比RTT的值小很多，这会引起报文段不必要的重传，使网络负荷增大
• 如果超时重传时间RTO的值设置得远大于RTT的值，这会使重传时间推迟的太长，使网络的空闲时间增大，降低传输效率

所以不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO。

但是可以利用每次测量得到的RTT样本，计算加权平均往返时间RTTs(又称为平滑的往返时间)，显然，超时重传时间RTO应略大于加权平均往返时间RTTs.

---

RFC6298建议使用下式计算超时重传时间RTO

---

实际上，RTT的测量还是比较复杂的，尤其是出现超时重传时，由于发送的是同样的TCP报文段，那么RTT的起始时间到底是开始发送报文段时的时间还是重传时的时间很难判断。

针对出现超时重传时无法测准往返时间RTT的问题，Karn提出了一个算法：

在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RTT样本。也就是出现重传时，不重新计算RTTs，进而超时重传时间RTO也不会重新计算。

• 这又引起了新的问题。设想出现这样的情况：报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。这会导致报文段反复被重传。

因此，要对Karn算法进行修正。方法是：报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是将新RTO的值取为旧RTO值的2倍。

5.7 TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口来实现可靠传输。

• 发送方在未收到接收方的确认时，可将发送窗口内还未发送的数据全部发送出去；
• 接收方只接收序号落入发送窗口内的数据。

虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。

• 网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
• 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。

对于不按序到达的数据应如何处理，TCP并无明确规定。

• 如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据。
• TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。

TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。

• 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。

  TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 1122]。

• 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。

TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口。

5.8 TCP的运输连接管理

TCP是面向连接的协议，它基于运输连接来传送TCP报文段。

TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。

TCP的运输连接管理就是使运输连接的建立和释放都能正常地运行。

TCP的连接建立

TCP的连接建立要解决以下三个问题：

• 使TCP双方能够确知对方的存在；
• 使TCP双方能够协商一些参数(如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等)；
• 使TCP双方能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配。

---

TCP使用“三报文握手”建立连接

• TCP 连接的建立采用客户服务器方式。
• 主动发起连接建立的应用进程叫做TCP客户 (client)。
• 被动等待连接建立的应用进程叫做TCP服务器 (server)。

“握手”需要在TCP客户端和服务器之间交换三个TCP报文段

---

过程：

最初两端的TCP进程都处于关闭状态。

• 一开始，TCP服务器进程首先创建传输控制块，用来存储TCP连接中的一些重要信息。
  • 例如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针，当前的发送和接收序号等。
• 之后，就准备接受TCP客户端进程的连接请求，此时TCP服务器进程就进入监听状态，等待TCP客户端进程的连接请求。

TCP服务器进程是被动等待来自TCP客户端进程的连接请求，因此成为被动打开连接。

由于TCP连接建立是由TCP客户端主动发起的，因此称为主动打开连接。

• TCP客户进程也是首先创建传输控制块。

• 然后，在打算建立TCP连接时，向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态。

  TCP连接请求报文段首部中：

  • 同步位SYN被设置为1，表明这是一个TCP连接请求报文段；
  • 序号字段seq被设置了一个初始值x，作为TCP客户端进程所选择的初始序号。

  注：TCP规定SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号。

• TCP服务器进程收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态。

  TCP连接请求确认报文段首部中：

  • 同步位SYN和确认为ACK都设置为1，表明这是一个TCP连接请求确认报文段；
  • 序号字段seq被设置了一个初始值y，作为TCP服务器进程所选择的初始序号；
  • 确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号(seq)的确认。

  注：这个报文段也不能携带数据，因为它是SYN被设置为1的报文段，但同样要消耗掉一个序号。

• TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并进入连接已连接状态。

  普通的TCP确认报文段首部中：

  • 确认位ACK被设置为1，表明这是一个普通的TCP确认报文段；
  • 序号字段seq被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，所以TCP客户进程发送的第二个报文段的序号为x+1；
  • 确认号字段ack被设置为y+1，这是对TCP服务器进程所选择的初始序号的确认。

  注：TCP规定普通的TCP确认报文段可以携带数据，但如果不携带数据，则不消耗序号，下次发送数据报文段序号仍是x+1。

• TCP服务器进程收到该确认报文段后也进入连接已建立状态

现在，TCP双方都进入了连接已建立状态，它们可以基于已建立好的TCP连接，进行可靠的数据传输。

---

思考：三报文握手最后一次握手能不能去掉，反正都收到服务器端的连接请求确认了，直接进入连接已建立状态不是也可以吗？

其实第三次握手主要是防止已失效的连接请求报文段突然又传送到了TCP服务器，因而导致错误。

发送一个连接请求报文段后超时了，客户端重传一个连接请求，并建立连接，通信结束后释放连接，结果好巧不巧，结束以后，之前超时的那个连接请求报文段”反复横跳“后到达服务器端了，服务器端就同意连接，发送连接请求确认，并自己进入连接已建立状态，一直等着客户端和他通信，然而客户端并不知道此时有连接建立，这样服务器端就会白白浪费资源。

TCP的连接释放

• TCP 连接释放过程比较复杂。
• 数据传输结束后，通信的双方都可以在数据传送结束后发出连接释放的通知

---

TCP通过“四报文挥手”来释放连接

过程：

现在TCP客户进程和TCP服务器进程都处于连接已建立状态

• 假设TCP客户进程的应用进程通知其主动关闭TCP连接，TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态

  TCP连接释放报文段首部中：

  • 终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认；
  • 序号seq字段的值设置为u，它等于TCP客户进程之前已传送过的数据的最后一个字节的序号加1；
  • 确认号ack字段的值设置为v，它等于TCP客户进程之前已收到的、数据的最后一个字节的序号加1。

  请注意：TCP规定终止位FIN等于1的报文段即使不携带数据，也要消耗掉一个序号。

• TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段并进入关闭等待状态

  普通的TCP确认报文段首部中：

  • 确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段；
  • 序号seq字段的值设置为v，它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1，这也与之前收到的TCP连接释放报文段中的确认号匹配；
  • 确认号ack字段的值设置为u+1，这是对TCP连接释放报文段的确认。

TCP服务器进程应该通知高层应用进程，TCP客户进程要断开与自己的TCP连接。此时，从TCP客户进程到TCP服务器进程这个方向的连接就释放了。
这时的TCP连接属于半关闭状态，也就是TCP客户进程已经没有数据要发送了。
但如果TCP服务器进程还有数据要发送，TCP客户进程仍要接收，也就是说从TCP服务器进程到TCP客户进程这个方向的连接并未关闭。

• TCP客户进程收到TCP确认报文段后就进入终止等待2状态，等待TCP服务器进程发出的TCP连接释放报文段。
• 若使用TCP服务器进程的应用进程已经没有数据要发送了，应用进程就通知其TCP服务器进程释放连接。

由于TCP连接释放是由TCP客户进程主动发起的，因此TCP服务器进程对TCP连接的释放称为被动关闭连接。

• TCP服务器进程发送TCP连接释放报文段并进入最后确认状态。

  该报文段首部中：

  • 终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认；
  • 序号seq字段的值为w，这是因为在半关闭状态下，TCP服务器进程可能又发送；
  • 确认号ack字段的值为u+1，这是对之前收到的TCP连接释放报文段的重复确认。

• TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，之后进入时间等待状态。

  该报文段首部中：

  • 确认为ACK的值被设置为1，表明这是一个普通的TCP确认报文段；
  • 序号seq字段的值设置为u+1，这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号；
  • 确认号ack字段的值设置为w+1，这是对所收到的TCP连接释放报文段的确认。

• TCP服务器进程收到该报文段后就进入关闭状态，而TCP客户进程还要经过2倍MSL后才能进入关闭状态。

  • MSL(Maximum Segment Lifetime)，最长报文段寿命，RFC793建议为2分钟， 这时间其实有点太长了，TCP允许根据具体情况使用更小的MSL。

---

思考：TCP客户进程在发送完最后一个确认报文后，为什么不直接进入关闭状态？而是要进入时间等待状态？

时间等待状态以及处于该状态2MSL时长，可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态。

要是客户端发送完确定报文段后就进入关闭状态不管事儿了，万一确认报文段丢失了，服务器端收不到确认报文，那么超时后又会重传连接释放报文段，但是客户端已经关闭了，不理服务器了，那服务器就只好一直超时重发而且还没用。
另外，TCP客户进程在发送完最后一个TCP确认报文段后，在经过2MSL时长，就可以使本次连接持续时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的TCP连接中，不会出现旧连接中的报文段。

---

TCP保活计时器

TCP双方建立了连接以后，TCP客户进程所在的主机突然出现了故障，那么TCP服务器进程以后就不能再收到TCP客户进程发来的数据，因此，应当采取措施使TCP服务器进程不要再白白等待下去，为此引入了保活计时器。

• TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器(2小时定时)。
• 若保活计时器定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时后，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后则每隔75秒钟发送一次。 若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器进程就认为TCP客户进程所在主机出了故障，接着就关闭这个连接。

5.9 TCP报文段的首部格式

为了实现可靠传输，TCP采用了面向字节流的方式。

但TCP在发送数据时，是从发送缓存取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后进行发送。

• 一个TCP报文段由首部和数据载荷两部分构成；
• TCP的全部功能都体现在它首部中各字段的作用。

下面具体说明：

• 源端口：占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程。

• 目的端口：占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程。

• 序号seq：占32比特，取值范围[0,2^32-1]，序号增加到最后一个后，下一个序号就又回到0。用来指出本TCP报文段数据载荷的第一个字节的序号。

• 确认号ack：占32比特，取值范围[0,2^32-1]，确认号增加到最后一个后，下一个确认号就又回到0。用来指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。

  • 若确认号=n,则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据。

• 数据偏移：占4比特，并以4字节为单位。用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。

  • 这个字段实际上是指出了TCP报文段的首部长度。
    首部固定长度为20字节，因此数据偏移字段的最小值为(0101)2
    首部最大长度为60字节，因此数据偏移字段的最大值为(1111)2

• 保留：占6比特，保留为今后使用，但目前应置为0。

• 紧急标志位URG：取值为1时紧急指针字段有效；取值为0时紧急指针字段无效。

• 确认标志位ACK：取值为1时确认号字段才有效；取值为0时确认号字段无效。

  • TCP规定，在连接建立后所有传送的TCP报文段都必须把ACK置1。

• 推送标志位PSH：接收方的TCP收到该标志位为1的报文段会尽快上交应用进程，而不必等到接收缓存都填满后再向上交付。

• 复位标志位RST：用来复位TCP连接。

  • 当RST置1时，表明TCP连接出现了异常，必须释放连接，然后再重新建立连接。
  • RST置1还可以用来拒绝一个非法的报文段或拒绝打开一个TCP连接。

• 同步标志位SYN：在TCP连接建立时用来同步序号。

• 终止标志位FIN：用来释放TCP连接。

• 窗口：占16比特，以字节为单位。指出发送本报文段的一方的接收窗口。

  • 窗口值作为接收方让发送方设置其发送窗口的依据。(需要注意，发送窗口还取决于拥塞窗口的大小)
  • 这是以接收方的接收能力来控制发送方的发送能力，也就是所谓的流量控制。

• 校验和：占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。
  在计算校验和时，要在TCP报文段的前面加上12字节的伪首部。

• 紧急指针：占16比特，以字节为单位，用来指明紧急数据的长度。

  • 当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据。

• 选项：

  • 最大报文段长度MSS选项：TCP报文段数据载荷部分的最大长度。
  • 窗口扩大选项：为了扩大窗口(提高吞吐率)。
  • 时间戳选项：
    • 用来计算往返时间RTT
    • 用于处理序号超范围的情况，又称为防止序号绕回PAWS.
  • 选择确认选项

• 选项：

  • 最大报文段长度MSS选项：TCP报文段数据载荷部分的最大长度。
  • 窗口扩大选项：为了扩大窗口(提高吞吐率)。
  • 时间戳选项：
    • 用来计算往返时间RTT
    • 用于处理序号超范围的情况，又称为防止序号绕回PAWS.
  • 选择确认选项

• 填充：由于选项的长度可变，因此使用填充来确保报文段首部能被4整除

(因为数据偏移字段，也就是首部长度字段，是以4字节为单位的)