计算机网络-笔记-第五章-运输层
目录
五、第五章——运输层
1、运输层概述
2、运输层端口号、复用、分用
（1）熟知端口号、登记端口号、短暂端口号
（2）熟知端口号
（3）发送方复用、接收方分用
3、UDP与TCP对比
（1）UDP
（2）为什么TCP面向字节流、UDP面向报文？
4、TCP各种机制
（1）TCP——流量控制
（2）拥塞控制
（2）拥塞控制 ——慢开始 & 拥塞避免
（2）拥塞控制 ——快重传 & 快恢复
（2）拥塞控制 ——总结
（3）TCP——超时重传
（4）TCP——可靠传输
（5）TCP——连接建立（※）
（6）TCP——连接释放（※）
（7）TCP——首部格式
（8）TCP——首部格式——端口、序号、确认号
（9）TCP——首部格式——数据偏移、保留、窗口
（10）TCP——首部格式——标志位、紧急指针
（11）TCP——首部格式——校验和、填充、选项
五、第五章——运输层
1、运输层概述
网络层实现了主机与主机
运输层实现端口到端口（进程与进程）
运输层协议 = 端到端协议
2、运输层端口号、复用、分用
（1）熟知端口号、登记端口号、短暂端口号
注意：端口号的范围——0~65535
端口号是用于标识应用程序或服务的通信端口。它是一个16位的数字，范围从0到65535。
0到1023是熟知端口号（Well-known Ports），
1024到49151是登记端口号（Registered Ports），
49152到65535是短暂端口号（Dynamic or Private Ports）。
熟知端口号是广泛使用和标准化的一些常用端口号，由IANA指定。
登记端口号是由IANA进行登记但没有被广泛使用或标准化的一些端口号，范围在1024到49151之间。
短暂端口号是临时分配给客户端的端口号，范围在49152到65535之间。
（2）熟知端口号
（3）发送方复用、接收方分用
发送方复用（Sender Multiplexing）和接收方分用（Receiver Demultiplexing）是指通过端口号来将多个应用程序的数据进行区分和传输的过程。
发送方复用是指发送方的运输层将来自不同应用程序的数据进行合并，并使用源端口号将这些数据分配给不同的传输连接。每个传输连接都与一个唯一的目标端口号相关联，这样在接收端可以根据目标端口号将数据正确地交付给对应的应用程序。
接收方分用是指接收方的运输层根据目标端口号将到达的数据进行分发，确保这些数据被正确地交付给相应的应用程序。接收方依靠目标端口号来识别传输连接，并将数据传递给相应的应用程序，从而实现数据的分发和传输。
通过发送方复用和接收方分用，不同应用程序的数据可以共享同一个网络连接，并通过运输层使用端口号进行区分和传输。
这种复用和分用的机制有效地提高了网络资源的利用率和通信效率。
3、UDP与TCP对比
注意：TCP面向字节流、UDP面向报文
| 特性 |
TCP |
UDP |
| 连接性 |
面向连接 |
无连接 |
| 可靠性 |
提供可靠的数据传输 |
不保证可靠性 |
| 传输顺序 |
保证数据按照发送顺序进行传输 |
不保证数据按照发送顺序进行传输 |
| 消息边界 |
无消息边界，数据流进行分段和重组 |
有消息边界，保持消息的完整性 |
| 开销 |
较大的开销，提供错误检测、重传和流量控制机制 |
较小的开销，不提供错误检测和重传机制 |
（1）UDP
UDP是一个无连接协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。
（2）为什么TCP面向字节流、UDP面向报文？
TCP 面向字节流：
TCP 将数据视为字节流，发送端将连续的字节流分成合适的大小（根据网络状况动态调整）进行发送，接收端再将其按照相同的字节顺序重组成原始数据。
发送的字节流被切割成多个 TCP 分段（Segment），每个分段都有序号，以便接收端可以按正确的顺序重组。TCP 在传输过程中会提供流量控制、拥塞控制和丢失重传等机制，确保数据可靠地到达。由于 TCP 的可靠性保证，它能够提供一个高层次的抽象，将应用程序的数据传输看作一个连续的字节流。
UDP 面向报文：
UDP 则将数据视为报文，每个 UDP 分组（Datagram）都是一个独立的消息单元，具有自己的头部和标识信息。
UDP 不对数据进行切割或重新组装，发送方的每个报文都作为一个独立的实体发送给接收方。每个报文都有自己的标识信息，接收方根据报文的边界来区分不同的报文。
由于 UDP 不提供可靠性保证，发送的报文可能会丢失、重复或乱序到达。应用程序需要自己处理这些问题，因此 UDP 提供了一个更加轻量级和低开销的传输机制。
总结：
TCP 是面向字节流的协议，它提供可靠的、有序的、基于连接的数据传输。
UDP 是面向报文的协议，它提供简单的、无连接的、不可靠的数据传输。
TCP 的面向字节流特性使其适合于需要可靠性和顺序性的应用，
UDP 的面向报文特性使其适合于快速传输和对实时性要求较高的应用。
报文：就是独立的数据单元（所以丢了也问题不大）
字节流：就是连续的数据，相互是需要拼接的（所以要保障可靠性）
4、TCP各种机制
（1）TCP——流量控制
不太发送太快，速度要一致！！！
1、建立连接：主机告诉服务器，自己的窗口大小（服务器就会调整自己的流量窗口，和目的主机同步）
2、当窗口中的数据包发送后，就开始计时，如果一直到超时，都没有得到ACK确认，就重发！
3、服务器当得到ACK确认后，就可以根据相关信息，移动和调整窗口，继续发数据
1、当主机窗口为0时，服务器会开启（0窗口计时器）
2、持续发送探测报文，以此等待主机有空闲窗口，进行接收信息
3、期间，如果报文如果有丢失，就会进入死锁局面
4、在TCP中，当出现网络丢包或连接中断情况时，并不会直接导致死锁局面。TCP具有超时重传机制和连接恢复机制，可以通过重发数据、重新建立连接等措施来处理异常情况。
习题
（2）拥塞控制
慢开始、拥塞避免、快重传、快恢复
（2）拥塞控制 ——慢开始 & 拥塞避免
通过（慢开始 & 拥塞避免）算法，让发送数据的量维持在一定的值！！！
cwnd：可发送一次性报文段的个数
swnd：发送窗口
ssthresh：慢开始门限阈值
这两个算法——容易让传输效率降低！！（具体原因看下图）
（2）拥塞控制 ——快重传 & 快恢复
快重传：报文段丢失了，就让对方快速告诉我（连续喊我3次，那么我就信了，就重传）
不会因为报文段的丢失，傻傻的等着超时再重传，而导致后面传输的数据都失效！
（其实，就是两者约定好，当发生了这种情况该怎么做）协议就是这样滴~
快恢复：不是像拥塞避免那样，直接把发送窗口的值置为1（太der了）
（2）拥塞控制 ——总结
慢开始：发送数据的段数，从1开始，当段数小于【门限阈值】时，段数为指数上升
拥塞避免：当段数大于【门限阈值】时，段数逐步+1
注意：当发生了【超时重传】时，将会把发送窗口大小设为1
快重传：当发生【个别报文段】丢失时（不是通道拥塞，超时造成的），由接受方喊3次，然后重传
快恢复：当出现【个别掉点】时，就让【发送窗口大小】和【门限阈值】设置为【当前发送窗口大小的一半】——以此实现快恢复（与超时重传情况下不同哟！）
习题：
慢开始（Slow Start）：
- 在 TCP 建立连接后，发送方会将发送窗口大小初始化为一个较小的值。
- 发送方起初以指数级别递增发送段的数量，即每次窗口大小翻倍，因此称为慢开始。
- 当达到一个门限阈值（通常由拥塞窗口大小决定）时，发送方会进入拥塞避免阶段。
拥塞避免（Congestion Avoidance）：
- 在拥塞避免阶段，发送方每经过一个往返时间就将拥塞窗口（发送窗口大小）加1，使得发送段的数量逐渐增加
- 通过逐渐增加发送段的数量来控制发送速率，以避免网络拥塞。
超时重传（Timeout Retransmission）：
- 如果发送方在一定时间内未收到接收方的确认 ACK，就会认为有段丢失或网络状况不佳，触发超时重传机制。
- 在超时重传时，将发送窗口大小设置为1，重新发送丢失的数据段。
快重传（Fast Retransmit）：
- 当接收方接收到乱序的报文段，但后续的报文段已经到达时，会立即向发送方发送重复的 ACK 确认。
- 当发送方连续收到3个相同的确认 ACK 时，会立即重传下一个未收到确认的报文段，而无需等待超时。
快恢复（Fast Recovery）：
- 当发送方收到快重传的确认 ACK 后，会将拥塞窗口大小设置为当前发送窗口大小的一半，并进行拥塞避免。
- 这样可以快速恢复发送方的发送速率，而不需要执行慢开始的过程。
流量控制（Flow Control）：
- TCP 使用滑动窗口机制来进行流量控制，确保发送方不会淹没接收方。
- 接收方通过发送窗口大小告知发送方自己的可接收能力，发送方会根据接收窗口大小来控制发送速率。
（3）TCP——超时重传
超时重传时间的选择是TCP最复杂的问题之一
超时阈值太小（容易超时）、太大（空闲时间较大，传输效率降低）
超时重传时间（计算公式采用——加权平均）——在每一次成功传输后
但是！难以正确计算【超时重传时间】（具体情况，看下图）
Karn算法：
既然你重传后，无法正确计算【往返时间】，那么我就不管【重传这一情况】。
弊端：如果网络环境一直保持拥塞，就会一直导致重传（因为你没有考虑重传的计算，就不会修改超时时间阈值）
修正：重传后，把RTO增大一些
模拟练习 （这个公式有点难记，忘记了，可以再去看看视频结尾）
5.6 TCP超时重传时间的选择_哔哩哔哩_bilibili
公式
（4）TCP——可靠传输
字节为单位——滑动窗口
利用三个指针——我们可以确认很多东西（窗口大小，已发送数据，未发送数据）
注意事项！！！
双方窗口可能不一样大、全双工、数据如何处理、如何确认收到？
习题
（5）TCP——连接建立（※）
不能用两报文握手（毕竟，相当于你主机发送一个建立连接，服务器就会进入连接状态）
这是非常不好滴（对服务器来说，太容易被恶搞了）
虽然对于这个三报文握手，仍有SYN洪水和ACK洪水，但是总比两报文要好一点点
seq：随机的值
通过三次握手的过程，双方确认了对方的能力与意愿建立连接，并确保了初始序列号的一致性。这有助于避免恶意主机的滥用和预防网络中的重复连接。
尽管三次握手不能完全消除洪水攻击的风险，但它是确保连接可靠性和安全性的基本机制。
在实际应用中，还可以采取其他安全措施，如防火墙、入侵检测系统（IDS）、反洪水限制等来进一步增强网络的安全性和可靠性。
（6）TCP——连接释放（※）
四次挥手
当主机故障后，服务器如何判别？
每隔一段时间，就发送一个【探测报文】，如果连续10次无响应，就自动断开连接！
（7）TCP——首部格式
这里可以和IP数据报、数据帧；进行对比记忆（源IP/MAC地址和目的IP/MAC地址）
源端口、目的端口
序号、确认号、确认标志位ACK
重点！！！（千万别被搞混了）
认真看看下面的图！（客户和服务器发送的信息）
我已经写上了每一个数据的意义！（这两个是在相互交流的哟！！！）
（8）TCP——首部格式——端口、序号、确认号
（9）TCP——首部格式——数据偏移、保留、窗口
注意：偏移量（重点！！！）窗口（用来流量控制的！）
