计算机网络（六）运输层

计算机网络（六）运输层

  • 计算机网络体系中的物理层、数据链路层以及网络层共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信

  • 但是在计算机网络中真正进行通信的实体是位于通信两端主机中的进程

  • 如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又被称作端到端协议；即运输层直接为应用进程间的逻辑通信提供服务，但是运输层之间并没有实际存在的物理连接，它向高层用户屏蔽了网络核心的细节（如网络拓扑、采用的路由选择协议等），使得进程好像看见的是在两个运输层实体之间存在一条端到端的逻辑通信信道。

    image-20230608093049752

  • 应用之间进行网络通信的时候，在运输层使用不同的端口来对应不同的应用进程，然后通过网络层及其下层来传输应用层报文；接收方的运输层根据不同的端口将收到的应用层报文交付给应用层中相应的应用进程

    image-20230608093508883

    端口不是实际的物理端口，而是为了区分不同应用进程的标识符

1 运输层端口号、复用与分用

1.1 端口号
  • 运行在计算机上的进程使用PID进程标识符来标志，但是不同操作系统的计算机使用的是不同格式的进程标识符，因此需要使用统一的方法对TCP/IP体系的进程进行标识
  • TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程
  • 端口号使用16位比特标识，因此取值范围为0~65535，端口号又分为
    • 熟知端口号：0~1023，分派给TCP/IP体系中比较重要的应用层协议，如FTP使用21/20，HTTP使用80，DNS使用53
    • 登记端口号：1024~49151，为没有熟知端口号的应用进程使用，需要按规定手续登记防止重复，如微软远程桌面程序RDP端口号为3389
    • 短暂端口号：49152~65535，留给用户进程选择暂时使用。当服务器收到用户进程的报文时，就知道了客户进程所使用的动态端口号，通信结束后，这个端口号可以供其他客户进程以后使用
  • 端口号只具有本地意义，即只是为了标识本计算机应用层的各进程，在因特网中不同计算机的相同端口号是没有联系的
1.2 发送方的复用和接收方的分用

  • 发送方发送的应用报文在运输层使用UDP协议进行封装为UDP用户数据报，称为UDP复用，被TCP协议封装成TCP报文段的过程就称作TCP复用

  • 然后不论是UDP用户数据报还是TCP报文段都要被网络层的IP协议封装成IP数据报，称为IP复用

    IP数据报首部中协议字段的值用来表名IP数据报的数据载荷部分封装的是何种协议数据单元，如

    6表示TCP报文段

    17表示封装的是UDP用户数据报

  • 接收方的网络层在接收到IP数据报后进行IP分用，首先检查IP数据报的协议字段，根据数据载荷部分所使用的的协议将数据载荷通过运输层熟知端口号交付给运输层的UDP或者TCP

    image-20230608110946628

2 UDP和TCP

2.1 UDP

​ 用户数据报协议UDP(User Datagram Protocol)，是运输层最重要的协议之一

  • UDP是无连接的，即使用UDP通信的双发可以随时发送数据

  • UDP支持单播、多播以及广播，即支持一对一、一对多以及一对全的通信

  • UDP是面向应用报文的，即UDP对上层交付的应用报文既不合并也不拆分，保留报文边界发送

    详细来说：在对上层应用层报文的处理上，UDP直接对其添加首部使之成为UDP用户数据报进行发送；接收方的传输层收到UDP用户数据报后去掉UDP首部然后将应用层报文交付给应用进程

  • UDP向上层提供的是无连接、不可靠的服务，意思是接收方在接收发送方发送的用户数据报的时候，若发现传输过程中收到干扰产生了误码，就通过该数据报首部的校验和字段的值来检查产生误码的情况，但仅仅丢弃数据报不做任何处理

  • UDP适用于实时应用，如IP电话、视频会议等等

  • UDP用户数据报首部仅8字节，结构为

    image-20230608135837823
2.2 TCP

​ 传输控制协议TCP（Transmission Control Protocol），是运输层最重要的协议之一

  • TCP是面向连接的，即使用UDP通信的双发在进行数据传输之前必须使用“三报文握手”建立连接，连接成功后才能进行数据传输，数据传输结束后必须进行“四次报文挥手”来释放连接

    这里的连接指的是逻辑连接关系，而不是物理连接

  • TCP仅支持单播，也就是一对一的通信；这是由于TCP要求通信双方必须使用“三报文握手”建立连接，然后基于TCP的可靠逻辑信道进行通信

  • TCP是面向字节流的，意思是发送方的TCP把应用层交付的应用报文仅仅看做是一连串无结构的字节流，TCP不关心字节流的含义仅仅将编号存储在自己的发送缓存中，TCP然后从发送缓存中提取一定数量的字节添加TCP首部构成TCP报文段进行发送；

    接收方TCP一方面从接收到的TCP报文段中提取数据载荷部分存储在接收缓存中，另一方面则将缓存中的交付给应用进程。

    image-20230608135046379

    TCP不保证接收方应用进程所收到的数据块与发送方应用进程所发出的收据块具有对应的大小关系（这里指的数据块大小可以不同，因为对字节流进行了编号），但是接收方收到的字节流必须和发送方应用进程发出的字节流完全一样

    并且接收方的应用进程必须有能力识别收到的字节流，把它还原成有意义的应用层数据

    实际过程中，TCP连接的双方可以同时进行数据的发送与接收，也就是全双工通信

  • TCP向上层提供的是面向连接、可靠的服务，使用TCP通信的双方基于TCP建立的可靠信道进行数据传输，不会出现误码、丢失、乱序、重复的传输差错

  • TCP适用于需要进行可靠传输的应用，如文件传输

  • TCP报文段的首部最小20字节，最大60字节，结构为：

    image-20230608135912930

3 TCP的流量控制（时间窗口原理）

​ TCP的流量控制，就是利用滑动窗口机制，让发送方的发送速率不要太快免得接收方来不及接收，具体来说

  • 在通信双方建立TCP连接时，发送方首先根据自己发送窗口的大小将发送窗口内一定序号的数据按序封装成TCP报文段发送出去

    image-20230608142931233

    seq是TCP报文段首部中的序号字段，1表示TCP报文段数据载荷的第一个字节的序号是1

    DATA表示这是一个TCP数据报文段

  • 如果这时候发送的TCP报文段丢失了，接收方主机会对已经收到的数据进行累计确认，调整接收窗口并对发送方主机进行流量控制

    image-20230608143205403

    rwnd是TCP报文段首部的窗口字段，表示接收窗口大小

    ACK是TCP报文段首部中的标志位，1表示TCP确认报文段

    ack是TCP报文段首部中的确认号字段，201表示序号201之前的数据已经全部被正确接收

  • 发送方主机在收到累计确认后，将发送窗口向前滑动，使已发送并收到确认的这些数据移出发送窗口，并在发送缓存中删除这些数据；调整发送窗口大小为接收窗口大小；同时如果重传计时器超时，就会重传丢失报文段

  • 当发送窗口内的全部数据都发送出去了，发送方就不能发送新数据了，重复上面步骤就完成了在流量控制下的TCP数据传输

  • 而当接收方进行累计确认的时候将接收窗口调整为0进行流量控制的时候，发送方收到累计确认的时候就不能发送新数据了；而当接收方的接收缓冲区又有了空间，就会重新调整接收窗口大小并通告发送主机

    image-20230608155223789

  • 但是如果上面的非零窗口通知丢失了，那么发送主机一直在等待非零窗口通知，而接收主机也一直在等待发送主句的发送数据，如果不采取措施这种互相等待而形成的死锁局面将一直持续下去

    image-20230608155419631

  • 为了解决上面的问题，TCP设计了一个持续计时器，发送方在收到接收方的零窗口通知的时候，就会启动一个持续计时器，当持续计时器超时，发送主机立即发送一个仅携带一字节数据的零窗口探测报文段，接收方在收到该零窗口探测报文段后会给出自己的接收窗口大小进行通告，如果发送方仍收到一个零窗口通知就会再开启一个持续计时器，否则继续发送数据

    image-20230608155901629

    TCP规定接收方主机的接收窗口无论是否为0，都必须接收零窗口探测报文段、确认报文段以及携带有紧急数据的报文段

    零窗口探测报文段也有重传计时器，如果零窗口探测报文段丢失导致计时器超时，就会重发该零窗口探测报文段

    image-20230608160743454

4 TCP的拥塞控制

​ 拥塞表示对网络中某一资源的需求超过了该资源所能够提供的部分，网络性能就要变坏；计算机网络中的链路容量（即带宽）、交换节点的缓存和处理机等，都是网络的资源；如果出现了拥塞而不控制，则整个网络的吞吐量会随着符合的增大而下降。

image-20230611135003369
4.1 四种拥塞控制算法

image-20230611140011828

​ 拥塞算法的基础是发送方和接收方各自维护的一些状态变量，包括

  • 发送方维护一个拥塞窗口 (cwnd)的状态变量，其值取决于网络的拥塞程度，并且动态变化

    • 维护的原则是：当网络没有出现拥塞，拥塞窗口就调大一些，如果出现拥塞就调小一些
    • 判断是否出现拥塞的依据是发送方是否按时收到接收方发送的确认报文（即是否触发超时计时器的超时重传）

  • 发送方将拥塞窗口作为发送窗口(swnd)，即swnd=cwnd

  • 发送方维护一个慢开始门限(ssthresh)，并且

    • 当cwnd < ssthresh，使用慢开始算法
    • 当cwnd > ssthresh，使用拥塞避免算法
    • 当cwnd = ssthresh，既可以使用慢开始算法也可以使用拥塞避免算法

  • 慢开始

    image-20230611140239275

    即每次发送方在接收到接收方的确认报文之后，都将拥塞窗口的大小变为原来的一倍，比如上面初始拥塞窗口为1，然后变为2、4、8、16最终达到慢开始门限开始使用拥塞避免算法

    慢开始算法指的是一开始向网络注入的报文段少，而不是指拥塞窗口的增长速度慢

  • 拥塞避免

    image-20230611140914089
    • 即达到慢开始门限后，每次发送方收到接收方的确认报文后，都将拥塞窗口的大小线性加一
    • 一旦网络出现拥塞，即触发了超时计时器的超时重传，则
      • ①将慢开始门限调整为发生拥塞时的拥塞窗口的值的一半
      • ②将拥塞窗口的值减少为1，重新开始执行慢开始算法

    拥塞避免算法并不能够完全避免拥塞，而是在拥塞避免阶段控制拥塞窗口的大小线性变化，使网络比较不容易出现拥塞

​ 有时候，个别报文段会在网络传输中丢失，这时候并没有发生网络堵塞，但是发送方迟迟收不到接收方的确认报文进而导致超时计时器超时重发，触发拥塞避免算法将发送方的拥塞窗口调为1并错误地开始了慢开始算法，大大降低了传输的速率，因此又引入了下面两种拥塞控制算法：

  • 快重传：采用快重传的目的是让发送方尽早知道发生了个别报文段的丢失

    • 即使收到了失序的报文段，也要立即发出已收到的报文段的重复确认
    • 发送方一旦收到三次连续的重复确认，就立即对报文段进行超时重传，而不是而不是等到超时计时器超时再重传
    • 因此对于个别丢失的报文，采用快重传的发送方不会出现超时重传，也就不会被误认为出现了网络拥塞，使用快重传可以使整个网络的吞吐量提高20%
    image-20230611142908792

    如上，M3报文段丢失后，接收方收到M4、M5、M6报文段仍然立即发送已经收到的报文段即M2的确认报文，发送方在收到三次连续的重复确认后，就可以提前对M3报文进行重发，而不是等到超时计时器超时再发送，从而避免了慢开始算法

  • 快恢复

    发送方一旦接收到三个连续的重复确认报文，就知道只是丢失了个别报文段而不是发生网络拥塞，因此会执行快恢复算法而不是慢开始算法，下面是两种快恢复算法：

    • 将慢开始门限和拥塞窗口大小变为当前拥塞窗口的一半，开始执行拥塞避免算法
    • 将慢开始门限的值再增大一些，sshThresh += 3因为：
      • 既然发送方收到了三个连续重复确认，表名已经有3个报文段此刻经过网络传输到接收方并存储在接收放的接收缓存中，也就是这三个报文段不占用网络的资源，因此可以把拥塞窗口调大一些

5 TCP超时重传时间的选择

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

  • 超时重传时间RTO应略大于往返时间RTTO
  • image-20230611145713883
  • image-20230611145748589
  • image-20230611145810813

6 TCP可靠传输的实现

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

  • 发送方首先根据接收方发送的确认报文构造出自己的发送窗口，确认报文段包括

    • rwnd：接收窗口的大小
    • ack：接收方希望收到的下一个数据的序号
    image-20230611152135014

  • 发送方构造的发送窗口为：

    image-20230611153112021
    • 发送窗口内部数据表示发送方准备发送的数据以及已经发送并且没有收到确认的数据（这部分仍要保存在发送缓存中，防止超时重发）
    • 发送窗口后沿外的数据表示已经发送并收到确认的数据，可以从发送缓存中删除
    • 发送窗口前沿外的数据表示不允许发送的数据

  • 接着发送方就可以根据构造的发送窗口来发送数据了，接收方此时接收到的数据可能是无序的即某些丢失或者仍滞留在网络中的数据，接收方也可以接收他们并存入接收缓存，但是在发送确认报文的时候只能发送已确认接收过的最高数据分组序号

    image-20230612103910465

  • 当未按顺序达到的报文到达接收方后，接收方将其存入接收缓存，并将接收到的数据交付给应用进程，最后调整滑动窗口大小向前移动滑动窗口，删除落在滑动窗口外的缓存数据，并向发送方发送确认报文段（包括接收窗口大小rwnd和目前已确认接收过的最高数据分组序号ack）

    image-20230612110404306

  • 发送方在接收到确认报文后，一方面根据接收窗口大小改变发送窗口大小，另一方面根据ack号删除发送缓存中确认的数据分组，并移动发送滑动窗口

​ 额外事项：

  • 虽然发送方的发送窗口是根据接收方的接收窗口设置的，但发送方的发送窗口并不是时刻和接收方的接收窗口一样大，主要有两个原因：

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

  • 接收方对于不按序到达的数据，也是先临时存放在接收窗口中，等到字节流中缺少的字节收到后，再按序交付给上层的应用进程

    TCP对于这点并不是严格地规定，只是对于不按序到达的数据一律丢弃的话，会降低网络资源的利用率，即导致发送方重复发送数据

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

    接收方也不能过分推迟发送确认，否则会导致不必要的超时重传

  • TCP的通信是全双工通信，因此通信的双方都在发送和接收报文段，因此每一方都有自己的发送窗口和接收窗口。

7 TCP连接管理

image-20230612135359795
  • TCP是面向连接的协议，它基于运输连接来传送TCP报文段
  • TCP连接管理就是使运输连接的建立和释放都能够正常地运行
  • TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程
  • TCP的运输连接包括以下三个阶段：
    • “三报文握手”建立TCP连接
    • 数据传送
    • “四报文挥手”释放TCP连接
7.1 “三报文握手”建立TCP连接

​ 三次握手过程：

  • 两台基于TCP通信的主机中，某个应用程序主动发起TCP连接的主机称作TCP客户，另一台中被动等待TCP连接建立的应用进程称作TCP服务器

  • 最初两端的TCP进程都处于关闭状态，TCP服务器进程首先创建传输控制块进入监听状态准备接收TCP客户的连接请求，这个过程被称作被动打开连接。传输控制块存储TCP连接中的一些重要信息如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针、当前发送和接收的序号等

  • TCP客户进程也是首先创建传输控制块，在打算建立连接时向TCP服务器发送TCP连接请求报文段，并进入同步已发送状态，TCP连接请求报文段首部中的同步位SYN被设置为1，表明这是一个TCP连接请求报文段；序号字段seq被设置了一个初始值x，作为TCP客户进程所选择的初始序号。这个过程因为是TCP客户进程主动发起的，因此被称作主动打开连接。

    TCP规定同步位SYN为1的报文段不能携带数据，但是要消耗一个序号

    image-20230612140153815

  • TCP服务器在收到TCP客户端的连接请求报文段后，如果同意连接，就向TCP客户端发送针对TCP连接请求的确认，并进入同步已接收状态，该连接请求确认报文段首部的同步位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段；序号字段seq被设置初始值y，表示TCP服务器端选择的初始序号；确认序号ack的值为x+1，表示对TCP客户端初始序号x的确认

    TCP规定同步位SYN为1的报文段不能携带数据，但是要消耗一个序号，因此TCP连接请求确认报文段同样不能携带数据，但是要消耗一个序号

    image-20230612140956289

  • TCP客户端在收到服务器端的连接请求确认报文段后，还要发送一个普通TCP确认报文段进行TCP连接请求确认的确认，进入连接已建立状态，该TCP确认报文段的首部的同步位SYN为0、确认位ACK为1表示这是一个普通TCP确认报文段；序列号seq为x+1因为第一个连接请求报文段的序列号为x，确认序号ack为y+1，表示对连接请求确认报文段首部中序号y的确认。服务器端收到该TCP确认报文段后也同样进入连接已建立状态，接下来即可进行数据传输

    image-20230612141550092

    由于该TCP确认报文段同步位SYN为0、确认位ACK为1，所以这是一个普通TCP确认报文段，因此不携带数据就不会消耗序号，也就意味着下面连接建立后客户端发送的TCP报文段首部序号仍为x+1

​ TCP连接建立要解决的问题：

  • 使TCP双方都能够知道对方的存在
  • 使TCP双方都能够协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）
  • 使TCP双方能够对运输实体资源（缓存大小、连接表中的项目等）进行分配
7.2 第三次握手是否多余？能否改为两次握手
image-20230612143001941

​ 不能，如果使用两次握手的方式，TCP客户端进程在第一次发送连接请求报文段在网络传输中出现延时，导致客户端超时计时器的超时重传，待两次握手建立连接后客户端和服务器端均进入连接已建立状态，这时候直接进行数据传输并最后释放TCP连接，但是如果这时候延迟的第一次连接请求报文段又到达了TCP服务器，则就会使得TCP服务器进程误认为TCP客户端进程又发出连接请求，而向客户端发送连接请求确认并等待客户端的再次确认，而客户端根据首部序号字段不会理睬从而导致服务器端一直在等待造成资源浪费。

7.3 “四报文挥手”TCP的连接释放

  • 数据传输接收后，通信的双方都处于连接已建立状态都可以释放连接

  • 应用进程通知TCP进程主动关闭连接的时候，TCP进程就会发送TCP连接释放报文段，并进入终止等待一状态，该TCP连接释放报文段首部的终止位FIN和ACK的值都设置为1，表明这是一个TCP连接释放报文段；序号字段seq的值设置为u，即该TCP进程之前已经传送过的数据的最后一个字节序号+1、确认序号字段ack设置为v即该TCP进程已经收到的数据的最后一个字节的序号+1

    image-20230612150649146

    TCP规定终止位FIN为1的报文段不能携带数据，但是要消耗一个序号

  • 收到TCP连接释放报文段的另一个TCP进程如果想要释放连接，就发送一个普通的TCP确认报文并进入关闭等待状态，并通知高层应用断开TCP连接。该TCP确认报文段的确认位ACK为1，表明这是一个普通确认报文段；序号字段seq的值为v即该TCP进程已经传送过的数据的最后一个字节的序号+1（也与TCP连接释放报文段的确认序号匹配）、确认序号字段ack值为u+1是对TCP连接释放报文段的确认，而收到该普通TCP确认报文段的TCP进程则会进入终止等待状态2

    image-20230612151801411

    这时候从第一个TCP进程到第二个TCP进程的连接已经被释放了，此时处于半连接状态，即第一个TCP进程已经没有数据需要向后者发送了，但是如果后者想要发送数据，第一个TCP进程还要接收，这个状态可能还要持续一段时间

  • 如果后者的应用进程已经没有数据需要发送了，就会通知其TCP进程发送TCP连接释放报文段释放TCP连接，并进入最后确认状态，因为连接释放请求是第一个TCP进程主动发起的，因此这个过程又被称作被动关闭连接。该TCP连接释放报文段的终止位FIN为1、确认位ACK也为1表明这是一个TCP连接释放报文段；序号字段seq为w因为在半连接状态下该TCP进程可能又向另一个已经关闭TCP发送了很多数据、确认序号ack值为u+1是对TCP连接释放报文段的确认

    image-20230612151946913

  • 最后第一个TCP进程必须针对第二个TCP进程发送的TCP连接释放报文发送普通的TCP确认报文，并进入时间等待状态，该报文首部的确认位ACK的值为1表明该报文是一个普通的TCP确认报文；序号字段seq的值u+1（之前该TCP进程发送的TCP连接释放报文虽然不携带数据但是占用一个序号）、确认序号字段ack的值为w+1是对另一个TCP进程发送的连接释放报文段的确认。第二个TCP进程收到该确认报文后就会进入关闭状态，而第一个TCP进程也会等待2MSL后也进入关闭状态。

    MSL(Maximum Segment Lifetime)意思是最长报文段寿命、RFC793建议为两分钟

    image-20230612175829339

7.4 “四次挥手”的第四次挥手是否有必要？

​ 即那么为什么第一个TCP进程在发送完最后一个TCP确认报文后，不直接进入关闭状态而是要进入时间等待状态呢？

image-20230612180420518

​ 第四次挥手是有必要的，因为如果第四次TCP确认报文段在网络中丢失了，那么会触发接收方上次TCP报文段的超时重发，而如果此时发送方在发送完成确认报文段直接进入关闭状态的话就不能对超时重发的报文段进行回应，造成接收方的不断超时重发浪费网络资源。

7.5 TCP心跳检测
  • TCP服务器进程每收到一次TCP客户进程发来的数据，就重新设置并启动心跳计时器（两小时定时）
  • 若心跳计时器定时周期内未收到TCP客户进程发来的数据，则心跳计时器到时后，TCP服务器进程会向TCP客户端进程发送一个探测报文段，以后每隔75秒发送一次，连续发送10个探测报文段仍然没有TCP客户端的响应，则TCP服务器进程就认为TCP客户端进程所在主机出现了故障，接着就会关闭这个连接

8 TCP报文段首部

​ TCP为了实现可靠传输，采用了面向字节流的方式，但是TCP在发送数据的时候，是从发送缓存中取出一部分或者全部字节给其添加一个TCP首部使之成为TCP报文段后发送的。

​ TCP报文段首部格式：

image-20230612190244477

  • 和IP数据报的首部格式类似，都是由20字节的固定首部和40字节的扩展首部构成的

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

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

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

    image-20230612191132968

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

  • 确认标志位ACK：占1个比特位，表示该TCP报文是否为确认报文，只有当该位为1确认号字段ack才有效

    TCP规定，在连接建立后所有传送的TCP报文都必须将首位的确认标志ACK置为一

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

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

  • 复位标志位RST：用来复位TCP连接，当该值为1的时候，表明TCP连接出现了异常，必须释放连接再重新建立连接

    RST置一还可以用来拒绝一个非法的报文段或者拒绝打开一个TCP连接

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

  • 紧急标志位URG：取值为1的时候紧急指针生效

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

  • 数据偏移：占4个比特，以4字节为单位，表示TCP报文段的数据载荷部分举例TCP报文的起始有多远。这个字段实际上也指出了TCP首部的大小

    如数据偏移为0101，则首部大小为5 * 4 = 20 字节

  • 窗口：占16比特，以字节为单位，指出发送本报文一方的接收窗口，这样就让窗口值作为接收方让发送方设置其发送窗口的依据，即以接收方的接收能力来控制发送方的发送能力，也就是流量控制

    发送窗口的大小还收到拥塞窗口大小的影响，应该取拥塞窗口和接收窗口的最小值

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

  • 选项：长度可变，包含：

    • 最大报文长度MSS选项：TCP报文段数据载荷部分的最大长度
    • 窗口扩大选项：为了扩大窗口（提高吞吐率）
    • 时间戳选项
      • 计算往返时间RTT
      • 处理序号超范围的情况，又称为防止序号绕回PAWS
    • 选择确认选项
posted @ 2023-06-12 19:45  Tod4  阅读(230)  评论(0)    收藏  举报