JWangL5's Blog
分类 系列 文章 相册 关于我
JWangL5's Blog

目录

网络笔记 | 09. 运输层TCP协议

卢旺 avatar卢旺  收录于  类别 机枢织序 和 系列 计算机网络
     约 11255 字   预计阅读 50 分钟 
运输层内容框架
  • 计算机网络体系结构中的物理层、数据链路层和网络层，他们共同解决了将主机通过异构网络互联起来的问题，实现了主机到主机的通信
  • 但实际上，在计算机网络中，进行通信的真正实体，是位于通信两端主机中的进程
  • 如何为运行在不同主机上的应用进程提供直接的通信服务，是运输层的任务，运输层协议又称为端到端协议
  • 引入
    • 运行中在计算机上的进程使用进程标识符PID来标志
    • 但因特网上的计算机并不是使用统一的操作系统，不同的操作系统又使用不同格式的进程标识符
    • 为了使运行不同操作系统的计算机的应用进程之间能够进行通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识
  • TCP/IP体系的运输层使用端口号来区分应用层的不同进程
    • 端口号使用16比特标识，取值范围为0～65535
    • 有3类
      • 熟知端口号：0～1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议
        • 例如：FTP使用21/20，HTTP使用80，DNS使用53
      • 登记端口号：1024～49151，为没有熟知端口号的应用程序使用。使用这类端口号必须在IANA按照规定的手续登记，以防止重复
        • 例如：Microsoft RDP微软远程桌面使用的端口是3389
      • 短暂端口号：49152～65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用
    • 端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中，不同计算机中的相同端口号是没有联系的
  • 发送方的复用与接收方的分用
    • 发送方的某些应用进程所发送的不同应用报文，在运输层使用UDP协议进行封装，称为UDP复用
    • UDP封装而成的用户数据报或TCP封装而成的报文段，都需要在网络层使用IP协议封装为IP数据报，该过程称为IP复用
    • 在接收方也有类似的过程，相同的IP数据报，需要根据其首部协议字段的值，将其用不同的协议进行解析，该过程称为IP分用
  • 举例：DNS解析和Web请求（具体先不写了，有点长，但很符逻辑）
    • 在网络拓扑中，用户PC、DNS服务器、Web服务器通过交换机进行互联，处于同一个以太网中
    • 假设Web服务器的域名为www.porttest.com，在DNS服务器中记录有该域名对应的IP地址192.168.0.3​
    • 当我们在用户PC中使用网页浏览器访问Web服务器中内容时，用户PC中的DNS客户端进程会发送一个DNS查询请求报文，其对应的内容为www.porttest.com所对应的IP地址是什么？
    • DNS的查询请求报文需要使用运输层的UDP协议，封装成UDP用户数据报，其源进程端口号可以在短暂端口号中选择一个未被占用的端口号，用于表示DNS客户端进程，目的端口号为53，这是DNS服务器客户端进程所使用的熟知端口号
    • 之后，将UDP用户数据报封装在IP数据报中，通过以太网发送给DNS服务器，DNS服务器收到该数据报后，从中解封出UDP用户数据报，UDP用户数据报首部的目的端口号为53，意味着需要将其数据载荷部分，即DNS查询请求报文，交付给本服务器中的DNS服务器端进程
    • DNS服务器端进程解析DNS查询请求报文的内容，后按其要求查找对应的IP地址；之后，会给用户PC发送DNS响应报文，其内容为“域名www.porttest.com所对应的IP地址为192.168.0.3”，该响应报文被封装为UDP用户数据报格式，再将其封装为IP数据报，通过以太网发给用户PC
    • 用户PC收到该数据报后，从中解封出UDP用户数据报，根据目的端口号，将数据部分交付给DNS客户端进程
    • DNS客户端进程解析DNS响应报文的内容，就可直到自己之前所请求的Web服务器的域名所对应的IP地址
    • 此时，用户PC的HTTP客户端进程可以向Web服务器发送HTTP请求报文了，该请求报文使用运输层的TCP协议封装称TCP报文段，源端口号为未被占用的源端口，目的端口字段值设置为80
    • 随后将该报文封装在IP数据报中，通过以太网发送给Web服务器，Web服务器收到该数据报后，从中解封出TCP报文段，根据目的端口号80，将数据载荷交付给本服务器中的HTTP服务器端进程
    • HTTP服务端进程解析报文请求的内容，并按其要求查找页面内容，后给用户PC发送HTTP响应报文，其内容正是用户所请求的页面内容
    • 该HTTP响应报文需要使用运输层的TCP协议封装成TCP报文段，其首部中的源端口好字段设置为熟知端口号80，目的端口号与请求报文中的源端口号一致
    • 随后将TCP报文端封装在IP数据报中，通过以太网发送给用户PC，用户PC在收到该数据报后，从中解封出TCP报文段，根据目的端口号将数据交付给HTTP客户端进程，并由其进一步解析该响应报文的内容，并在网页浏览器中进行显示

  • UDP和TCP是TCP/IP体系结构运输层中的两个重要协议，其使用频率仅低于网际层的IP协议

  • 有些应用需要使用TCP提供服务，有些应用则需要UDP协议来提供服务

    • UDP（User Datagram Protocol，用户数据报协议）
    • TCP（Transmission Control Protocol，传输控制协议）

  • 对比1：是否连接

    • UDP是无连接的，用户可以随时发送数据
    • 而TCP是面向连接的，用户必须经过三报文握手建立连接之后再进行数据传输，数据传输结束后，必须使用四报文回收来释放连接
    • 这里的连接是逻辑意义上的，不是物理连接

  • 对比2：多播与广播

    • 局域网下使用UDP通信的主机，任何一台主机都可以下其他主机发送广播，向某一个多播组发送多播，还可以向某台主机发送单播；即UCP支持单播、多播以及广播
    • 使用TCP进行通信的主机在数据传输前需要先建立连接，连接建立后通信双方就像有了一条可靠的传输信道，双方基于该信道通信；因而，TCP仅支持单播（一对一通信）

  • 对比3：对数据报文的处理

    • 应用层UDP直接给应用层报文添加一个UDP首部，随后发送给接收方，接收方直接去掉首部后交付给应用进程
    • 即是说，UDP对应用进程交付下来的数据报文，既不合并也不拆分，保留了这些报文的边界
    • 可以总结说，UDP是面向应用报文的
    • 但对于TCP协议，其将应用进程交付下来的数据块看作是一系列的字节流，TCP并不在意这些字节流的含义，只是将他们编号并存储在自己的发送缓存中。在发送数据时，TCP根据发送策略，从发送缓存中提取一定数量的字节，构建TCP报文段并发送；接收方一方面从接收到的TCP报文段中提出数据载荷并存储在接收缓存中，一方面也将接收缓存中的一些字节交付给应用进程
    • TCP不保证接收发应用进程接收到的数据块与发送方应用进程所发送的数据块具有对应大小关系，但字节必须完全一样；例如发送方可能发出了10个块来表示全部数据，但接收方可能只上交了4个块来表示全部数据
    • 接收方的应用进程必须有能力识别收到的字节流，并将其还原为有意义的应用层数据
    • 这可以总结为：TCP是面向字节流的

  • 对比4：可靠或不可靠服务

    • 接收方UDP可以通沟该数据报手段中的校验和字段的值，检查出产生误码的情况，但其仅仅只是丢弃该数据报，什么也不做
    • 在发送过程中，UDP数据报若是被某个路由器丢弃了，发送方UDP不做什么处理
    • 即是说，UDP向上层提供的是无连接不可靠的传输服务，对于传输中出现的误码，UDP并不关心
    • 基于这个特点，UDP更适用与IP电话、视频会议等实时应用
    • 对于TCP而言，尽管网际层IP协议向上提供的是无连接、不可靠的传输服务，但只要运输层是使用TCP协议，就可以向上层提供面向连接的可靠传输服务
    • 可以将该过程想想成为，数据通过基于TCP连接的可靠信道进行传输，不会出现误码、丢失、乱序、重复等传输差错
    • TCP向上层提供的是面向连接的可靠传输服务，可以应用于文件传输等可靠传输应用

  • 对比5：首部结构

    • UDP数据报由首部和数据载荷两部分构成，其首部仅有4个字段，每个字段占2个字节，分别是源端口、目的端口、长度、校验和
    • 而TCP协议首部就复杂的多，其固定长度20字节，可变部分最大40字节，其不仅仅需要保障可靠传输，还需要提供流量控制、拥塞控制等服务
  • 一般来说，我们总是希望数据传输得更快一些，但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。
  • 所谓流量控制(flow control)就是让发送方的发送速率不要太快，要让接收方来得及接收。
  • 利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制（和之前将的回退N帧很像）
    • 当A需要给B发送数据时，B可以对A进行流量控制
    • 在传输开始时，B会告诉A自己的接收窗口大小，A会根据该信息调整自己的发送窗口大小（下图案例中最初是400）
    • 下图所示的信息是一个发送案例
    • 值得一提的是，发送方首先需要将数据缓存在发送缓存区，随着发送确认而移出缓存区
    • 主机B可以随时调整发送方的滑动窗口大小，进而实现对发送速率的控制
    • 主机A发送的数据若丢失了，会在重传计时器超时之后再次发送
    • ​image​
    • 此时，发送端滑动窗口被调整为了0，发送方不再发送数据
    • 过了一段时间，如果主机B有了空闲的接收缓存区，可以发送确认信息调整滑动窗口大小
    • 但如果该信息不幸丢失了，A会一直等待B发送非零窗口通知，B会等待A发送数据，此时如果不采取措施，就会形成死锁局面，一直等待下去
    • ​image​
    • 当发送方收到零窗口通知时，就需要启动一个持续计时器，当计时器超时时，则发送一个零窗口探测报文段（仅1字节数据）
    • 接收方在确认零窗口探测报文段时，需给出自己当前的接收窗口值，如果窗口仍旧为0，发送方在接收到后重置持续计时器；如果不是0，就可以继续发送数据，打破死锁的局面
    • 接收方没有缓存怎么接收零窗口探测报文段？TCP规定，即使接收方的接收窗口为0，也必须接收零窗口探测报文段、确认报文段、以及携带有紧急数据的报文段
    • 零窗口探测报文段丢失怎么办？零窗口探测报文段也有重传计时器的功能，当一定时间内没有收到反馈，会再一次发送
  • 练习
  • 问题引入
  • 四种算法：
    • 问题背景假设和算法应用背景
    • 慢开始与拥塞避免
      • 有一个叫做慢开始门限ssthres的状态变量，控制着慢开始算法与避免拥塞算法的切换
      • 拥塞窗口的初始值为1，而发送窗口的值取能发送数据大小和拥塞窗口的最小值，通常发送窗口值受限于拥塞窗口值
      • 当发送窗口小于该阈值时，用慢开始算法，发送窗口大小按照指数规律增大，达到阈值后，则线性增大（每次增加1）
      • 当线性增大到一定程度之后，若出现损失，则认为网络达到了阈值，此时执行2个动作
        • 将慢开始阈值调整为当前窗口大小的一半
        • 将发送窗口重新设置为1，重新开始执行慢开始算法
      • ​image​
      • 需要注意的是，慢开始是指一开始向网络注入的报文段少，并不是指发送窗口增长速度慢
      • 另外，拥塞避免也并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为线性增长规律，使网络比较不容易出现拥塞
      • 这两个算法是1988年提出的TCP拥塞控制算法（TCP Tahoe版本）
    • 快重传与快恢复
      • 1900年，有新增的两个算法以改进TCP性能（TCP Reno版本）
      • 背景
        • 有时，个别报文段的丢失并不意味着网络发生了拥塞，
        • 偶尔的丢失同样会导致发送方的超时重传，并误认为拥塞的发生，限制网络的性能
        • 采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失
      • 所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传
        • 即是说，要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认
        • 即使收到了失序的报文段，也要立即发出对已收到的报文段的重复确认
        • 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的计时器超时后再重传
        • ​image​
        • 对于个别丢失的报文段，发送方不会超时重传，也就不会误认为出现了拥塞，进而降低拥塞窗口为1
        • 使用快重传可以使整个网络的吞吐量提高约20%
      • 快恢复
        • 发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段，于是不启动慢开始算法，而是执行快恢复算法
        • 在该算法中，执行2个操作
          • 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半，开始执行避免拥塞算法
          • 也有的快回复实现，是把快回复开始时的拥塞窗口值cwnd值再增大一些，即等于新的ssthresh+3
            • 其基本想法是说，既然已经收到了3个重复的确认，就表明已经有3个数据报文段已经离开了网络
            • 其不再消耗网络资源，而是停留在接收方的接收缓存中
            • 此时网络中不是堆积了报文段，而是减少了3个报文段
            • 因此可以适当把拥塞窗口再扩大一些
        • 举例 ​image​
    • 练习

  • 超时重传事件的选择是TCP最复杂的问题之一

    • 如果将超时重传时间RTO设置为小于往返时间RTT，这会造成不必要的重传，使网络负荷增大
    • 但若将其设置得远大于RTT，则会使网络空闲时间增大，降低传输效率
    • 由此可知，超时重传时间RTO应略大于往返时间RTT
    • 但实际上，由于网络环境和路由方式的不同，数据的发送可能经过1个高速率网络或多个低速率的网络，并且每个IP数据报的转发路由也可能不同，这会使得每一次测的往返时间都不一样

  • RTT的测量

    • 不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO
    • 利用每次测量得到的RTT样本，计算加权平均往返时间RTTs（又称为平滑的往返时间）
    • 使用该方法得到的加权平均往返时间RTTs，比测量出的RTT值更加平滑
    • 超时重传时间RTO应略大于加权平均往返时间RTTs

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

    • $$ RTO=RTT_S + 4 \times RTT_D $$

  • 如何测量RTT

    • 复杂的情况

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

      • 在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RTT样本。

      • 也就是出现重传时，不重新计算RTTs，进而超时重传时间RTO也不会重新计算。

      • 但这又引起了新的问题，如果报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延

      • 因此在原来得出的重传时间内，不会收到确认报文段，于是就重传报文段

      • 但根据Karn算法，不考虑重传的报文段的往返时间样本，超时重传时间也就无法更新，这会导致报文段反复被重传

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

      • 举例修正的Karn算法

        • ​image​

  • 可靠传输的实现

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

    • 滑动窗口的实现

      • 对于发送窗口
      • 可以使用3个指针来表示发送窗口的状态
      • 对于接收窗口

    • 几点补充

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

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

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

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

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

        • 但是，接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源
        • TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC1122]
        • 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据

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

  • 练习

连接的三个阶段：建立TCP连接、数据传送、释放TCP连接

  • 三个核心问题

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

  • 具体过程

    • 主动发起建立TCP连接的应用进程称为TCP客户，被动等待建立TCP连接的应用进程称为TCP服务器

    • TCP服务的建立需要在两者间交换3个TCP报文段

    • 最初，两端的TCP进程都处于关闭状态，TCP服务器进程首先创建传输控制块，用来存储TCP连接中的一些重要信息，比如TCP连接表、指向发送和接收缓存的指针、指向重传的队列的指针、当前的发送和接收序号

    • 之后，服务器进程进入监听状态，准备接受TCP客户进程的连接请求（被动打开连接）

    • TCP客户进程在启动后，首先也是创建传输控制块，在需要建立TCP连接时，向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态

      • TCP连接请求报文段首部中的同部位SYN被设置为1，表明这是一个TCP连接请求报文段；序号seq被设置为了一个初始值x，作为TCP客户进程所选择的初始序号
      • 需要注意，TCP规定SYN被设置为1的报文段不能携带数据，但要消耗掉1个序号

    • TCP连接建立是由TCP客户进程主动发起的，称为主动打开连接

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

      • 该报文段首部重点 同部位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段
      • 序号seq被设置为了一个初始值y，作为TCP服务器进程所选择的初始序号
      • 确认号ack的值被设置为了x+1，表示是对TCP客户进程所选择的初始序号的确认
      • 注意：这个报文段也不能携带数据，因为其SYN为1，同样消耗掉1个序号

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

      • 该报文段首部中的确认为ACK被设置为1，表明这是一个普通的TCP确认报文段
      • 序号字段seq被设置为x+1，这是因为TCP客户端进程发送的第一个TCP报文段的序号为x（不携带数据），第二个报文段为x+1
      • 注意，TCP规定普通的TCP确认报文段可以携带数据，但如果不携带数据，则不消耗序号，下一个数据报文段的序号仍是x+1
      • 确认号字段ack被设置为y+1，这是对TCP服务器进程所选择的初始序号的确认

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

    • 此时，TCP双方都进入了连接已建立状态，他们可以基于已建立好的TCP连接，进行可靠的数据传输了

  • 问题：为什么TCP客户进程最后还要发送一个普通的TCP确认报文段呢？是否可以使用两报文握手来建立连接呢？

    • 采用三报文握手而不是两报文，是为了防止已失效的连接请求段突然又传送到了TCP服务器，因而导致错误

  • 练习

  • 在数据传输完成后，客户端或服务器双方都可以使用四报文挥手的方式释放连接

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

    • 该报文段中的终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认
    • 序号seq字段的值设置为u，他等于TCP客户进程之前已传送过的、数据的最后一个字节的序号加1
    • TCP规定，终止位FIN等于1的报文段即使不携带数据，也要消耗掉1个序号
    • 确认号ack字段的值设置为v，他等于TCP客户进程之前已收到的、数据的最后一个字节的序号加1

  • 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连接释放是由TCO客户进程主动发起的，因此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连接释放报文段虽然不携带数据，但要消耗掉1个序号
    • 确认号ack字段的值设置为w+1，这是对所收到的TCP连接释放报文段的确认

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

    • MSL（Maximum Segment Lifetime）指，最长报文段寿命，RFC793建议为2分钟
    • 也就是说，TCP客户进程进入时间等待状态之后还需要经过4分钟才能进入关闭状态
    • 这完全是从工程上考虑的，对于现在的网络，MSL取为2分钟可能太长了，因此TCP允许不同的实现可根据具体情况使用更小的MSL值

  • TCP客户进程在发送完最后一个确认报文段后，为什么不直接进入关闭状态？

    • 如果TCP客户端发送的最后一封TCP确认报文段在发送后就直接进入关闭状态
    • 若当该报文丢失，就会触发TCP服务器进程对之前所发送的TCP连接释放报文段的超时重传，并仍处于最后确认状态
    • 重传的TCP连接释放报文段到达TCP客户进程后，由于TCP客户进程已处于关闭状态，因此不理睬该报文段，这边会造成TCP服务器进程反复重传TCP连接释放报文段，并一直处于最后确认状态而无法进入关闭状态
    • 因此时间等待状态以及处于该状态2MSL时长，可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态
    • 另外，TCP客户进程在发送完最后一个TCP确认报文段后，再经过2MLS时长，就可以使本次连接持续时间内所产生的所有报文段都从网络中消失
    • 这样可以使下一个新的TCP连接中，不会出现旧链接中的报文段

  • TCP保活计时器的作用

    • 设想，TCP双方已经建立了连接，后来，TCP客户进程所在的主机突然出现了故障，随后TCP服务器进程以后就不能再收到TCP客户进程发来的数据

    • 因此，应该有措施使TCP服务器进程不要再白白等待下去

    • 保活计时器就是TCP服务器进程发现这种状态的策略

      • TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器（2小时定时）
      • 若保活计时器定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时后，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后则每隔75秒钟发送一次
      • 若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器进程就认为TCP客户进程所在主机出了故障，
        接着就关闭这个连接
  • 为了实现可靠传输，TCP采用了面向字节流的方式，但TCP在发送数据时，是从发送缓存取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后进行发送
    • 一个TCP报文段由首部和数据载荷两部分构成
    • TCP的全部功能都体现在它首部中各字段的作用

  • 由20字节固定首部和最大40字节的扩展首部构成

    • 应用进程相关

      • 源端口号，占16比特，用来标识发送该TCP报文段的应用进程
      • 目的端口号，占16比特，用来标识接收该TCP报文段的引用进程
      • 其内容根据上层应用的报文来填写，如根据HTTP请求/响应报文中的源端口和目的端口来填写

    • 可靠传输相关

      • 序号字段，占32比特，取值范围为$[0, 2^{32}-1]$，序号增加到最后一个后，下一个序号就又回到0
      • 序号字段指出，本TCP报文段数据载荷的第一个字节的序号
      • 确认号字段，占32比特，取值范围为$[0, 2^{32}-1]$，序号增加到最后一个后，下一个序号就又回到0
      • 确认号字段指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认
      • 若确认号=n，则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据
      • 只有当确认标志位ACK，取值为1时，确认号字段才有效，为0时无效
      • TCP规定，在连接建立后，所有传送的TCP报文段都必须把ACK设置为1

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

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

    • 保留字段，占6比特，为今后使用，目前应置为0

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

      • 窗口值作为接收方让发送方设置其发送窗口的依据
      • 是以接收方能力来控制发送方的发送能力，实现流量控制
      • 实际的发送窗口，应为接收窗口与拥塞窗口的最小值

    • 校验和字段，占16比特，用来检查整个TCP报文段在传输过程中是否出现了误码，包括首部和数据载荷两部分

      • 与UDP类似，在计算校验和时，需要在TCP报文段前面加上12字节的伪首部

    • 同步标志位SYN，该标志位在TCP连接建立时用来同步序号，表明这是一个TCP连接请求报文段或连接请求的确认报文段

    • 终止标志位FIN，用来释放TCP连接，表明其是一个TCP连接的释放报文段

    • 复位标志位RST，用来复位TCP连接

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

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

    • 紧急操作

      • 紧急标志位URG取值为1时，紧急指针字段有效，否则无效
      • 紧急指针字段，占16比特，以字节为单位，用来指明紧急数据的长度
      • 当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面，并立即封装到一个TCP报文段中进行发送
      • 紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据
      • 接收方接收到紧急标志位为1的报文段后，会按照紧急指针字段的值，从报文段数据载荷部分，取出紧急数据，并直接上交应用进程，而不必在接收缓存中排队

    • TCP报文段还包含40字节的选项部分，增加选项可以增加TCP的功能，目前有以下选项

      • 最大报文段长度MSS选项：TCP报文段数据载荷部分的最大长度

      • 窗口扩大选项：可以用于扩大窗口，提高吞吐率

      • 时间戳选项

        • 用来计算往返时间RTT
        • 用于处理序号超范围的情况，又称为防止序号绕回PAWS

      • 选择确认选项，用于实现选择确认功能

      • 由于选项的长度可变，因此使用填充来确保报文段首部能被4整除（因为数据偏移字段，也就是首部长度字段，是以4字节为单位的）

‍

更新于 2025-08-08
 | 主页