•  本文是[计算机网络](https://www.bilibili.com/video/BV1c4411d7jb?spm_id_from=333.999.0.0)的笔记，图片也从视频中截取。
  

5.1运输层概述

• 端口：用来区分不同应用进程的表示符。
• 在学习运输层时，我们简单地认为运输层为应用进程间的逻辑通信提供服务。
• 逻辑通信：运输层之间的通信好像是沿水平方向传送数据，事实上并没有一条水平方向的物理连接。
  

5.2运输层端口号、复用和分用的概念

（1）发送方的复用和接收方的分用

• UDP复用：应用进程发送应用报文，在运输层使用UDP协议进行封装。
• TCP复用：应用进程发送应用报文，在运输层使用TCP协议进行封装。
• IP复用：在网络层使用IP协议封装成IP数据报。
• IP数据报中协议字段的值表明IP数据报的数据载荷部分封装的是何种协议数据单元。

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

• 不管在运输层使用UDP或者TCP协议，在网络层都是用IP协议。

5.3TCP和UDP的对比

• 使用UDP协议的双方可以随时发送数据。

• 使用TCP协议的双方通信之前必须三报文握手建立连接，结束后必须使用四报文挥手来释放连接。

• 连接指的是逻辑链接关系，而不是物理连接。
  

• 某个局域网上使用UDP协议进行通信的四台主机。

• 任何一台主机都可以向其他三台主机发送广播；也可以向某个多播组发送多播；还可以向某台主机发送单播。

• TCP仅支持单播。
  

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

• UDP是面向应用报文的。

• 发送方的TCP把应用进程交付下来的数据块仅仅看成一连串、无结构的字节流。

• TCP不知道待传送的字节流的含义，仅将他们编号，并存储在自己的发送缓存中。

• TCP根据发送策略，从发送缓存中提取一定数量的字节，构建TCP报文段并发送。

• TCP接受方TCP，一方面从所接收到的TCP报文段中，取出数据载荷部分并存储在接受缓存中；一方面将接受缓存中的一些字节交付给应用进程。

• TCP不保证接收方应用进程所收到的应用进程块和发送方应用进程所发出的数据块具有对应大小的关系；字节流完全一致。

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

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

• TCP的两端可以同时进行TCP报文段的发送和接受，即全双工通信。
  
  

• 由于UDP不提供可靠传输的服务，仅仅实在网络层的基础上添加了用于区分应用进程的端口，因此首部十分简单。

• TCP要实现多种服务。

（1）小结

5.4TCP的流量控制

• 在主机A和B建立TCP连接时，B告诉A：我的接受窗口的大小。（在本例中为400）
• 主机A将自己的发送窗口设置为相同值，这意味着主机A在未收到主机B发来的确认时，可将序号在窗口内的全部数据发送出去。
• 主机A将发送窗口内序号1~100的数据封装成一个TCP报文段发送出去，还能发送300字节。
• sep为TCP报文段首部中序号字段，取值1表示TCP报文段数据载荷的第一个字节的序号为1。DATA表示TCP数据报文段。
• 主机A将发送窗口内序号101~200的数据封装成一个TCP报文段发送出去，还能发送200字节。
• 主机A将发送窗口内序号201~300的数据封装成一个TCP报文段发送出去，还能发送100字节。但是丢失了。
• 主机B对主机A以前的数据进行累计确认，并在累计确认中将窗口字段的值调整为300（流量控制）。
• ACK为TCP报文段首部中的标志位，取值1表示这是一个TCP确认报文段。
• ack为TCP报文段首部中确认号字段，取值201表示201之前的数据已全部正确接收，现在希望收到序号201及与以后的数据。
• rwnd为TCP报文段中的窗口字段，取值300表示自己的接受窗口大小为300。
• 主机A收到该累计确认后，将发送窗口向前滑动，使已发送并收到确认的这些数据的序号移出发送窗口。
• 由于主机B将自己的窗口调整为300，主机A也将自己的发送窗口调整为300。
• 目前发送窗口内的需要为201~500，其中201-300是已发送的数据，若重传计时器超时，他们会被重传。
• 301~500未发送，可分别封装在一个TCP报文段中发送。
• 主机A将发送缓存中1~200的数据删除了，因为收到了累计确认。
• 为了解决ACK丢失问题，TCP为每个连接设有一个持续计时器，只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。
• 若持续计时器超时，就发送一个零窗口探测报文，仅携带一字节的数据。
• 对方在确认这个探测报文段时，给出自己现在的接受窗口值。
• 如果是0，那么收到这个报文段的一方就重新启动持续计时器；
• 如果不是0，那么死锁的局面就被打破了。
• 零窗口探测报文段也有重传计时器，超时后，零窗口探测报文段会被重传。
• TCP规定即使接受窗口为0，也必须接受零窗口探测报文段、确认报文段、以及携带紧急数据的报文段。

5.5TCP的拥塞控制

• 输入负载：单位时间内输入给网络的分组数量。
• 吞吐量：单位时间内从网络输出的分组数量。
  
  

（1）慢开始和拥塞避免

• 传输轮次：发送方给接收方发送数据报文段后，接收方给发送方发回相应的确认报文段。
• 一个传输轮次所经历的时间其实就是往返时间。
• 往返时间并非是恒定的数值。
• 使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去，并收到了已发送的最后一个报文段的确认。
• 拥塞窗口会随网络拥塞程度和所使用的拥塞控制算法动态变化。
• 在TCP双方建立逻辑连接关系时，拥塞窗口的值被设置为1，还需设置慢开始门限的初始值。
• 在执行满开始时，发送方每收到一个对新报文段的确认时就把拥塞窗口值加一，然后开始下一轮的传输。
• 当拥塞窗口值增长到慢开始门限值时，就改为执行拥塞避免算法。
• 拥塞避免算法：每个传输轮次结束后，拥塞窗口只能线性加一。
• 发送报文段时，在传输过程中丢失了几个，会造成发送方对这些丢失报文段的超时重传。
• 发送方以此判断网络中出现了拥塞，进行以下工作：
• ①将满开始门限值更新为发生拥塞时拥塞窗口值的一半；
• ②将拥塞窗口值减小为1，并重新执行慢开始算法；

（2）快重传和快恢复

5.6TCP超时重传时间的选择

• 超时重传时间RTO
• 设置的比RTT小，会引起不必要的重传；使网络负荷增大。
• 远大于RTT，使重传推迟的时间太长，使网络空闲时间增大，降低了传输效率。
• 所以应设置为略大于往返时间RTT的值。
  
  
• 如果测量的RTT样本不正确，那么所计算出的RTTs和RTTD也不正确，进而RTO也不正确。
  
  
  

5.7TCP可靠传输的实现

• 接收方只能对按序收到的数据中的最高序号给出确认。
• 具体实现看之前的滑动窗口或者看视频（要写的太多了）
  

5.8TCP的运输连接管理

（1）TCP的连接建立

• 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客户进程发送TCP连接请求确认报文段，并进入同步已接收状态。
• 该报文首部中的同步位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段。
• 序号字段seq被设置了一个初始值y，作为服务器进程所选择的初始序号。
• 确认号字段ack的值被设置为了x+1，这是对客户进程所选择的初始序号的确认。
• 请注意这个报文段也不能携带数据。（请注意：TCP规定SYN被设置位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连接，进行可靠的数据传输了。

（2）TCP的连接释放

• 假设客户进程的应用程序通知其主动关闭TCP连接，
• TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态。
• 该报文段首部中的终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段。
• 同时也对之前收到的报文段进行确认。序号seq字段的值设置为u，它等于客户进程之前已传送过的数据的最后一个字节的序号加1。
• 请注意：TCP规定FIN被设置位1的报文段不能携带数据，但要消耗掉一个序号。
• 确认号ack字段的值设置为v，它等于TCP客户进程之前已收到的、数据的最后一个字节的序号加1。
• TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段并进入关闭等待状态。
• 该报文段首部中的确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段。
• 序号seq字段的值被设置为v，它等于服务器进程之前已传送过的数据的最后一个字节的序号加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服务器进程可能又发送了一些数据。
• 请注意：TCP规定FIN被设置位1的报文段不能携带数据，但要消耗掉一个序号。
• 确认号ack字段的值设置为u+1，这是对之前收到的TCP连接释放报文段的重复确认。
• TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，之后进入时间等待状态。
• 该报文段首部中的确认位ACK被设置为1，表明这是一个普通的TCP确认报文段。
• 序号seq字段的值被设置为u+1，之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号。
• 确认号ack字段的值设置为w+1，这是对所收到的TCP连接释放报文段的确认。
• TCP服务器进程收到该报文段后就进入关闭状态。
• 而TCP客户进程还要经历2MSL后才能进入关闭状态，确保收到最后一个TCP确认报文段而进入关闭状态。
• 就可以使本次连接持续时间内所产生的所有报文段都从网络中消失，使下一个新的TCP连接中不会出现旧的报文段。
• TCP允许不同的实现可根据具体情况使用更小的MSL值。
  

5.9TCP报文段的首部格式

• 与可靠传输相关的序号字段、确认号字段，确认标志位ACK。