目录
[TCP/UDP 对比](#TCP/UDP 对比)
TCP核心机制五：流量控制
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继⽽引起丢包重传等等⼀系列连锁反应.如下图：
因此TCP⽀持根据接收端的处理能⼒, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);
++ACK不能携带应用数据，那这个数据怎么反馈给发送方呢？++
回忆我们的TCP⾸部中, 有⼀个16位窗⼝字段, 就是存放了窗⼝⼤⼩信息;
++那么问题来了, 16位数字最⼤表⽰65535（64KB）, 那么TCP窗⼝最⼤就是65535字节么?++
不是的.选项中，可以设置一个特殊的选项"窗口扩展因子"，发送方的窗口大小=
窗口大小<<窗口扩展因子。实际窗⼝⼤⼩是 窗⼝字段的值左移 M 位;
流量控制，也不是TCP独有的机制.其他的协议，也可能会涉及到流量控制（比如，数据链路层中有的协议，也支持流量控制）
TCP核心机制六：拥塞控制
虽然TCP有了滑动窗⼝这个⼤杀器, 能够⾼效可靠的发送⼤量的数据. 但是如果在刚开始阶段就发送⼤量的数据, 仍然可能引发问题.
因为⽹络上有很多的计算机, 可能当前的⽹络状态就已经⽐较拥堵. 在不清楚当前⽹络状态下, 贸然发送⼤量的数据, 是很有可能引起雪上加霜的.
TCP引⼊ 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的⽹络拥堵状态, 再决定按照多⼤的速度传输数据;
下面介绍拥塞控制中，窗口大小具体的变化过程......
TCP核心机制七：延迟应答
TCP核心机制八：捎带应答
延时应答，梢带应答，都是TCP提升性能的机制~~
TCP之所以复杂，不仅仅在考虑可靠传输，要在可靠传输的基础上，尽可能提高效率~~
TCP核心机制九：面向字节流
粘包问题
TCP核心机制十：异常处理
（1）进程崩溃
Java中的体现，就是抛出异常，但是没人catch,最终异常到了JVM这里，JVM进程就会直接嘎了~
看起来是崩溃，挺严重，实际上操作系统会进行善后.当进程崩溃的时候进程中的PCB就要被回收=>PCB中的文件描述符表里对应的所有文件，也都会被系统自动关闭
其中针对socket文件，也就会触发正常的关闭流程(TCP四次挥手)
（2）主机关机（正常流程的关机）
（3）主机掉电（拔电源）
（4）网线断开
总结
这十个只是咱们讲到的十个重要机制，不是TCP一共只有十个机制！
TCP更多机制的详情，rfc标准文档https://www.ietf.org/rfc/rfc9293.html
简历上干万不能出现"熟练掌握TCP十大特性"这样的说法~~
可以写熟悉TCP协议的常见特性~~
回到TCP报头结构还有几个属性没讲到......
++**URG:**紧急指针是否有效++
URG是和紧急指针配合使用的，为1时紧急指针能够生效
紧急指针里保存的是一个偏移量~~
TCP正常情况来说，都是按照顺序来传输数据~~
紧急指针，就是让后面的数据插队，根据紧急指针的偏移量，把指定位置的数据，优先发送出去
特殊场景的特殊方案.不是一个通用的方案.日常开发中很少直接涉及到~~
++**PSH:**提⽰接收端应⽤程序⽴刻从TCP缓冲区把数据读⾛++
PSH催促标志位，带有这个标志位的数据，就相当于提醒接收方，要尽快的来处理这个数据
(也是特殊场景下的特殊方案)
TCP/UDP 对比
我们说了TCP是可靠连接, 那么是不是TCP⼀定就优于UDP呢? TCP和UDP之间的优点和缺点, 不能简单, 绝对的进⾏⽐较
• TCP⽤于可靠传输的情况, 应⽤于⽂件传输, 重要状态更新等场景;
• UDP⽤于对⾼速传输和实时性要求较⾼的通信领域, 例如, 早期的QQ, 视频传输等. 另外UDP可以⽤ 于⼴播;
归根结底, TCP和UDP都是程序员的⼯具, 什么时机⽤, 具体怎么⽤, 还是要根据具体的需求场景去判定.
⽤UDP实现可靠传输(经典⾯试题)参考TCP的可靠性机制, 在应⽤层实现类似的逻辑; 例如:
• 引⼊序列号, 保证数据顺序;
• 引⼊确认应答, 确保对端收到了数据;
• 引⼊超时重传, 如果隔⼀段时间没有应答, 就重发数据;
• ......
编写应用层代码的时候，首先引入确认应答，接收方返回ack,
为了能够区分ck应答谁，引入序号和确认序号，约定确认序号的规则...
考虑丢包的情况，引入超时重传...
为了进一步提高传输效率，引入滑动窗口，引入快速重传
为了限制滑动窗口，引入流量控制/拥塞控制...
把TCP的这些机制都吹出来就行了~~
TCP协议上半部分内容在上篇文章计算机网络-传输层 TCP协议（上）-CSDN博客
至此TCP协议的全部内容就介绍完啦*★,°*:.☆(￣▽￣)/$:*.°★* 😊。