计算机网络 运输层笔记

重点

停止等待协议、ARQ协议、TCP报文段首部格式，滑动窗口、流量控制、拥塞控制。

运输层重要概念：

• 端口和套接字的意义。
• 无连接的UDP的特点。
• 面向连接的TCP的特点。
• 在不可靠的网络上实现可靠传输的工作原理，停止等待协议和ARQ协议。
• TCP的滑动窗口、流量控制、拥塞控制和连接管理。

套接字

源IP地址和目的IP地址以及源端口号和目的端口号的组合称为套接字。其用于标识客户端请求的服务器和服务。

运输层协议概述

网络层和运输层的区别：

网络层为主机之间提供逻辑通信，运输层为应用进程间提供端口对端口的逻辑通信。

如图，IP协议只确保了主机间的通信，但是没有具体到是哪个应用进程，运输层则是具体到了应用进程。

运输层的两个主要协议

• 用户数据报协议 UDP
• 传输控制协议 TCP

区别：

UDP在传输数据前不需要先建立连接。
TCP提供面向连接的服务，在传送数据前必须先建立连接，数据传送结束后要释放连接。

常用的UDP协议应用：

• DNS域名系统
• 多媒体通信

常用的TCP协议应用：

• 电子邮件 SMTP
• 文件传输FTP
• http传输

5.2 UDP

UDP只在IP的服务上增加了复用、分用、和差错检测的功能。

UDP特点：

• UDP是无连接的，即发送数据前不需要建立连接，因此减少了时延。
• UDP使用尽最大努力交付，不保证可靠传输。
• UDP是面向报文的，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。因此，应用程序必须选择合适大小的报文，如果报文太长，UDP把它交给IP层后，IP可能会对他进行分片，这会降低IP层的效率。如果太短，会使IP数据包的首部相对长度太大，降低IP层的效率。
• UDP没有拥塞控制。
• UDP支持一对一，一对多，多对一，多对多的交互通信。
• UDP的首部开销小，只有8个字节，TCP有20个。

UDP的首部格式

• 源端口 —— 需要对方回信时选用，不需要时可全0
• 目的端口
• 长度 —— UDP用户数据报的长度，最小值为8
• 检验和 —— 检测传输中是否出错，出错就丢弃
  
  如图：上面有一个伪首部，它并不是UDP数据报真正的首部，只是在计算检验和是，临时添加在UDP用户数据报前面，得到一个临时的UDP数据报。

IP数据报的检验和只检测IP数据报的首部，而UDP的检测是吧首部和数据部分一起都检验。

TCP协议

特点：

1. 面向连接 —— 在使用TCP协议之前，必须先建立连接。传输完毕后，必须释放连接。
2. 每个TCP连接只能有两个端点，一对一。
3. 提供可靠交付的服务。无差错、不丢失、不重复、按序到达。
4. 全双工通信（即通信的双方可以同时发送和接收信息的信息交互方式），连接两端都设有发送缓存和接收缓存，用来临时存放数据。
5. 面向字节流。TCP中的"流"指的是流入进程或从进程流出的字节序列

面向字节流的含义：

虽然应用程序和TCP的交互是一次一个数据块，但TCP把应用程序交来的数据仅仅看成一串无结构的字节流。TCP并不知道所传送的字节流的含义，也不保证接收方收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系。（如发送方应用程序交给TCP共10个数据块，但接收方的TCP可能只用了4个数据块处理，交付给上层的应用程序）

TCP和UDP在发送报文时方式不同，TCP不关心应用一次把多长的报文发送到TCP的缓存中，而是根据对方给出的窗口值和当前网络拥塞程度决定报文段应该包含多少字节。

TCP的连接

TCP连接的端点叫做套接字（socket）或插口，例如，IP地址是192.8.3.5，端口号是80，那么套接字就是 192.8.3.5:80

5.4 可靠传输的原理

TCP的报文段是交给IP层传送的，但IP层只能提供最大努力服务，也就是说TCP下面的网络所提供的是不可靠的传输，因此TCP必须采取措施才能让通信变的可靠。

停止等待协议

1. 出现差错情况

发送完一个分组就停止发送，等待对方的确认，收到确认后才发送下一个分组。

如果发送方A发送了数据包给接收方B，过程中数据包丢失，B由于没收到所以不会发送任何信息给A，A只要超过一定时间没收到确认，就认为刚刚发送的分组丢失了，因此重新传送前面发送过的数据包，这叫做超时重传，而具体超过多少时间要重传，需要设置一个超时计时器。

3.确认丢失和确认迟到

确认丢失：

上图中的（a）情况，A发送数据给B，B收到了并且返回数据，但返回的数据在回去的路程中丢失了，因此A在一定的时间内没收到确认，他就会重新传一次数据给B，B收到后会丢弃上次的重复的数据包，重新返回数据包给A

确认迟到

上图b情况，接收方会收到迟到的确认，但是什么也不做。

上述这些可靠传输协议，重传的请求是自动进行的。

停止等待协议的优缺点

优点： 简单
缺点： 信道利用率太低

流水线传输 —— 解决停止等待协议的低效问题

发送方可以连续发送多个分组，不必每发送一个分组就停下来等待对方的确认
它需要用到 ARQ协议和滑动窗口协议

连续ARQ协议

上图(a)表示发送方维持的发送窗口，它的意义是，位于发送窗口内的5个分组都可以连续发送出去，不需要等待对方的确认。因此信道利用率提高了。

接收方采用的是累计确认的方式，接收方不必对收到的分组逐个发送确认，而是收到几个分组后，对按序到达的最后一个分组发送确认。

累计确认的优缺点

优点：容易实现，即使确认丢失也不必重传。
缺点是：不能向发送方反映出接收方已经正确收到的所有分组的信息。

例子：

如果发送方发送了前 5 个分组，而中间的第 3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。

这叫做 Go-back-N（回退 N），表示需要再退回来重传已发送过的 N 个分组。
可见当通信线路质量不好时，连续 ARQ 协议会带来负面的影响。

5.5 TCP报文段的首部格式

TCP虽然是面向字节流，但TCP的传送数据单元却是报文段。

一个TCP报文段分为首部和数据两部分，TCP的全部功能都体现在它首部中各字段的作用。

TCP报文段首部的前20个字节是固定的，后面有4n个字节是根据需要而增加的选项，因此TCP首部的最小长度是20字节。

首部各字段的意义如下：

1. 源端口和目的端口 —— 各占2个字节，TCP的分用功能是通过端口实现的。
2. 序号—— 占4个字节，序号范围是[0, 2^32 - 1]，共2^32（4 294 976 296）个序号。序号增加到2^32 - 1 后，下一个序号又回到0。 TCP是面向字节流的。在一个TCP连接中传送的字节流中的每一个字节都按照顺序编号。整个传送的字节流的起始序号必须在连接建立时设置。首部中序号字段指的是本报文段所发送的数据的第一个字节的序号。
   例如，报文段的序号字段值是301，而携带的数据共有100字节，这表明：第一个字节的序号是301，最后一个字节的序号是400。显然，下一个报文段的数据序号应从401开始。
3. 确认号 —— 占4个字节，期望收到对方下一个报文段的第一个数据字节的序号。
   例如：B正确收到了A发送的报文段，其序号字段值是501，而数据长度是200字节（序号501~700），因此B期望收到A的下一个数据序号是701。

（注：若确认号=N，则表明：到N-1为止的所有数据已正确接受）
序号字段有32位长度，可对4GB的数据进行编号，一般情况下可保证当序号重复使用时，旧序号的数据早已通过网络达到终点了。

4. 数据偏移 —— 占4位，它表示的就是真实的TCP数据，它偏离首部的距离(这个主要是由于TCP选项这个块的内容所导致的，因为我们并不知道这个选项的内容有多少，所以需要存储数据偏移)。这个字段实际上是指出TCP报文段的首部长度，由于首部中选项字段的长度不确定，因此数据偏移字段是必要的。
5. 保留 —— 占6位，保留为今后使用，目前应置为0.
6. 下面有6个控制位，用来说明报文段的性质

• 6-1. 紧急URG，当URG = 1，会通知系统此报文段有紧急数据，应尽快传送，不要按照原来的排队顺序，TCP会把紧急数据插入到报文段数据的最前面
• 6-2. 确认**ACK**，仅当ACK = 1，确认号字段才有效，TCP规定当连接建立后，所有传送的报文段都必须把ACK置为1。
• 6-3. 推送PSH，接收方收到PSH=1的报文段，会尽快地交付接收应用进程，而不再等到整个缓存都填满才交付。
• 6-4. 复位RST，当RST=1，表明TCP连接出现严重差错，必须释放连接，然后重新建立连接。
• 6-5. 同步**SYN**，在建立连接时用来同步序号。当SYN = 1而ACK = 0时，表明这是一个连接请求报文段。对方若同意连接，则应在响应的报文中使SYN = 1和ACK=1.因此，SYN = 1就表示这是一个连接请求或连接接受报文。
• 6-6. 终止FIN，用来释放连接。

7.窗口 占2个字节。窗口指的是发送本报文段的一方的接收窗口（而不是自己的发送窗口），窗口值告诉对方：从本报文段首部中的确认号算起，接收方允许对方发送的数据量（单位：字节）

例如：发送了一个报文段，其确认号是 701，窗口字段值为 1000。这就告诉对方：“从 701 序号开始算起，我（发送此报文段的一方）的接收缓存空间还可以接收 1000 个字节数据，字节序号是 701 - 1700，你在给我发送数据时，必须要考虑到这一点”。窗口字段值明确的指出了现在允许对方发送的数据量，窗口值通常是在不断的动态变化着。

窗口指出现在允许对方发送的数据量。窗口值经常动态变化着。

8.检验和 占2个字节，检验范围包括首部和数据两部分。和UDP一样，在报文段前面加上伪首部。但应把伪首部第4个字段的17改为6（TCP协议号是6）
9. 紧急指针 占2个字节，仅在URG = 1时才有意义。指出本报文段中紧急数据的字节数。
10. 选项 长度可变，最长可达40字节，当没有使用选项时，TCP首部长度是20字节。

5.6 TCP可靠传输的实现

发送窗口：发送方A在没有收到接收方B的的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已发送过的数据，在未收到确认之前都必须暂时保留，一边在超时重传时使用。

• 发送方后沿：表示已发送且已收到确认
• 前沿：表示还不允许发送的

发送窗口由窗口前沿和后沿位置共同确定。

后沿可能的情况：

1. 不动（没有收到新的确认）
2. 前移（收到了新的确认）

不可能向后移动，因为不能撤销已收到的确认。

发送缓存

发送缓存用来存放：

1. 发送应用程序传给发送方TCP准备发送的数据
2. TCP已经发出但还未收到确认的数据

接收缓存

接收缓存用来存放：

1. 按序到达，但还未被应用程序读取的数据
2. 未按序到达的数据

注意点

• 发送窗口A是根据接收窗口B设置的，但在同一时刻，A的发送窗口并不总是和B一样大，因为通过网络传送窗口值，可能有一定时间的延迟。此外，窗口A可能根据网络拥塞情况适当缩小发送窗口。

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

• 接收方必须有累积确认的功能

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

5.6.2 超时重传时间的选择

运输层的超时计时器重传时间为多少？

TCP采用了自适应算法，记录了报文段的发出时间和受到相应确认的时间。两个时间之差就是报文段的往返时间RTT。

超时重传时间RTO略大于加权平均往返时间RTTs。

5.6.3 选择确认SACK

如果收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？

可以使用选择确认来处理。

略。。。

5.7 流量控制

利用滑动窗口实现流量控制。

我们希望数据传送得快一些，但如果发送方数据发的太快，接收方可能来不及接收，就会造成数据的丢失。

流量控制（flow control）： 让发送方的发送速率不要太快，让接收方来得及接收。

例子：

如图所示，在连接建立时，B告诉A： 我的接收窗口rwnd=400，因此发送方的发送窗口不能超过接收窗口。注意，TCP的窗口单位是字节，不是报文段

设每个报文段为100字节长，报文段序号初始值为1（seq=1）。图中大写ACK表示首部确认位，ack为确认字段的值。

5.7.2 传输效率 略

5.8 拥塞控制

若网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况就叫做拥塞。

拥塞控制往往由许多因素引起，单纯的增加资源或是更换高速率链路，不一定能够解决问题。

拥塞控制与流量控制关系密切，但也存在差别。

拥塞控制和流量控制的区别：

拥塞控制：防止过多数据注入到网络中，这样可以使网络中的路由器或链路不致过载，拥塞控制是一个全局性的过程，涉及到所有的主机、路由器等。

流量控制：点对点通信量的控制，是个端到端的问题。

例子：
设某个光纤网络的链路速率是1000Gb/s，有一台服务器以1Gb/s的速率向一台普通PC进行发送数据。显然网络本身带宽是足够大的，因而不存在产生拥塞的问题。但流量控制是必须的，因为服务器必须经常停下来，以便个人电脑来得及接收。

例子2：
如果有另一个网络，链路传输速率为1Mbit /s，有1000台计算机连接在这个网络上。假设其中500台分别向其余500台计算机以100 kbit/s 的速率发送文件，那么现在问题不是计算机是否来得及接收，而是网络的输入负载超过了网络所能承受的。

5.8.2 拥塞控制方法

拥塞控制4种算法：

• 慢开始
• 拥塞避免
• 快重传
• 快恢复

1. 慢开始和拥塞避免

这里讨论的拥塞控制叫做基于窗口的拥塞控制。发送方要维持一个叫做拥塞窗口cwnd的状态变量，它的大小取决网络的拥塞程度，并且动态变化。发送方让自己的发送窗口等于拥塞窗口

如果网络没有拥堵，窗口就可以增大一些，以便发送更多分组，提高网络的利用率。
如果网络拥塞，则减小窗口，减少注入网络的分组数，以缓解网络的拥堵。

发送方如何知道网络发生了拥堵？

网络发生拥塞时，路由器会丢弃分组，只要发送方没有按时收到确认报文，或者说只要出现了超时，就可以猜想网络出现了拥堵。

慢开始算法

当主机开始发送数据时，由于不清楚网络的负荷情况，所以不要把大量数据字节注入到网络中，而是先探测，由小到大逐渐增大窗口数值。

在刚开始发送报文段时，先把拥塞窗口 cwnd 设置为最大报文段 MSS 的数值。

之后在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个 MSS 的数值。

用这样的方法逐步增大发送方的拥塞窗口 cwnd，从而使分组注入到网络的速率更加合理。

如下图所示，每经过一个传输轮次（transmission round），拥塞窗口 cwnd 就加倍。

慢开始的“慢”并不是指 cwnd 的增长速率慢，而是指在 TCP 开始发送报文段时先设置 cwnd = 1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大 cwnd。这当然比按照大的 cwnd 一下子把许多报文段突然注入到网络中要“慢得多”。

慢开始有没有什么缺陷？或者没有考虑完善的情况？

我们已经知道，拥塞窗口 cwnd 每经过一个传输轮次，拥塞窗口 cwnd 就加倍。如果拥塞窗口增长速率过大，也会带了网络拥塞。为了解决这个问题，还需要设置一个慢开始门限 ssthresh。

慢开始门限 ssthresh 规则如下：

• 当cwnd < ssthresh时，使用上述的慢开始算法。
• 当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法。
• 当cwnd = ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。

拥塞避免

避免算法的思路是让拥塞窗口cwnd缓慢地增大，即经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是像慢开始阶段那样加倍增长。

TCP的运输连接管理 （三次握手，四次挥手）

运输连接有3个阶段，即建立连接、数据传送、释放连接。

TCP连接建立过程主要解决三个问题：

1. 让每一方能够确知对方的存在。
2. 允许双方协商一些参数（如窗口最大值、是否扩大窗口、时间戳选项）
3. 对运输实体资源进行分配（如缓存大小）

5.9.1 TCP的连接建立

客户端和服务器之间交换三个TCP报文段。

• A主动打开连接，B被动打开连接
• B的TCP服务器进程先常见传输控制块TCB，准备接受客户进程的连接请求。然后服务器进程处于LISTEN状态，等待客户的连接请求。
• A的TCP进程也是先创建传输控制块TCB，然后在打算建立TCP连接时，向B发出连接请求报文段，这时首部的同步位SYN=1，同时选择一个厨师序号seq=x。TCP规定，SYN报文段（即SYN=1的报文段）不能携带数据，但要消耗掉一个序号。这时候和护短进入SYN-SENT状态。
• B收到连接请求报文后，如统一建立连接，则向A发送确认。在确认报文段中吧SYN位和ACK位都置为1，确认号是ack=x+1，同时为自己选择一个初始序号seq=y。这个报文段也不能携带数据，但要消耗掉一个序号。这时TCP服务器进程进入SYN-RCVD状态。
• A收到B的确认后，向B发出确认。确认报文段的ACK置为1，确认号ack=y+1，自己的序号seq=x+1.TCP规定，**ACK报文段可以携带数据，但如果不懈怠数据则不消耗序号，**这种情况下，下一个数据报文段序号仍是seq=x+1。这时TCP连接已建立。

为什么A最后还要发送一次确认呢？

这是为了防止已失效的连接请求报文段突然传送到了B，因而产生错误。

“三次握手” 的目的是为了防止已失效的链接请求报文突然又传送到了服务端，因而产生错误。

正常的情况：A 发出连接请求，但因连接请求报文丢失而未收到确认，于是 A 再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A 共发送了两个连接请求报文段，其中第一个丢失，第二个到达了 B。没有 “已失效的连接请求报文段”。

现假定出现了一种异常情况：即 A 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段。但 B 收到此失效的连接请求报文段后，就误认为是 A 再次发出的一个新的连接请求。于是就向 A 发出确认报文段，同意建立连接。

假设不采用“三次握手”，那么只要 B 发出确认，新的连接就建立了。由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据。但 B 却以为新的运输连接已经建立，并一直等待 A 发来数据。这样，B 的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。

5.9.2 TCP连接释放（四次挥手）

数据传输结束后，通信双方都可以释放连接。现在A和B都处于established状态。A的应用进程先向其TCP发出连接释放报文段，并停止在发送数据，主动关闭TCP连接。A把报文段首部位的终止控制位FIN置为1，其序号seq=u，它等于前面已传送过的数据的最后一个字节的序号加1.这时A进入FIN-WAIT-1状态，等待B的确认。FIN报文段即使不携带数据，也消耗一个序号。

B收到连接释放报文段后，即发出确认，确认号是ack=u+1，seq是v，等于前面B已传送过数据的最后一个字节的序号加1，然后B进入CLOSE-WAIT状态。TCP服务器进程这时候应同志高层应用进程，因而从A到B这个方向的连接就释放了，这时候TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收，B到A这个方向的连接并未关闭，这个状态可能会持续一段时间。

A收到B的确认后，进入FIN-WAIT-2状态，等待B发出的连接释放报文段。

若B已经没有要向A发送的数据，应用进程就通知TCP释放连接。这时B发出的报文段FIN必须为1。假定B的序号为W（半关闭状态B可能又发送了一些数据）。B还必须重复上次已发送过的确认号ack=u+1。这时B进入LAST-ACK状态，等待A的确认。

A收到B的连接释放报文段后，必须对此发出确认，在确认报文段中把ACK置为1，确认号ack=w+1,而自己的序号是seq=u+1。然后进入TIME-WAIT(时间等待)状态。请注意，现在的TCP连接还没有释放掉。必须经过时间等待计时器（TIME-WAIT timer）设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命（Maximum Segment Lifetime）,通常是两分钟。因此，A进入到TIME-WAIT状态后，要经过4分钟才能进入到CLOSED状态，才能开始建立下一个新的连接。

为什么A在TIME-WAIT状态必须等待2MSL时间

1. 为了保证A发送的最后一个ACK报文能够到达B。这个ACK报文有可能丢失，因而使处于在LAST-ACK状态的B收不到A发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，A就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着A重传一次确认，重新启动2MSL计数器。最后A和B都正常进入到CLOSED状态。如果A在TIME_WAIT状态不等一段时间而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN+ACK报文段。B就无法按照正常步骤进入CLOSED状态。

2. 防止“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。B只要收到了A发出的确认，就进入 CLOSED状态。同样，B在撤销相应的传输控制块TCB后，就结束了这次的TCP连接。可以看到，B结束TCP连接的时间要比A早些。

相关题目

https://www.sohu.com/a/352225908_1