TCP协议详解（3）
拥塞控制
为了我们更好的理解什么是拥塞我们举一个例子来理解
就好比就业，如果一个班级中，毕业的学生有100人，如果有1,2个人没有找到工作，那么此时我们或许会认为，这是那一两个人的自己本身的问题！
但是如果有95人没有找到工作！——那么我们就会认为这是环境的问题！
==这说明同样是找不到工作！但是找不到工作的人的多少，会让我们有不同的看法==
现在有两个主机
==TCP的可靠性不仅仅是考虑了双方主机的问题！它也考虑了路上网络的问题！==
==而这时候的策略我们就不该选择超时重传了！——因为这时候已经出现问题的网络！，如果再次出现大量的报文！只会加重网络的故障问题！==
如果我们只是一台主机，那么问题可能不会很严重！但是网络上可不止有一台主机！这一群主机在互相通信！一旦网络出现了问题，那么除了我们本身的主机！其他的主机大概率也是会识别出来网络出现问题了！都出现了大面积的丢包！如果我们选择了超时重传！而这个网络下的主机都是tcp，那么其他的主机也会一起超时重传！而网络出现问题，本身就是因为这些主机在通信！（例如：因为传输数据太多，导致某一个节点或者某一些节点来不及做数据转发最后导致大面积的丢包）而这些主机又几乎是在同一时间发送大量的报文！那么就会加剧网络的问题！
==所以无论是我们主机，还是其他主机都不应该大量传输报文！，当所有的主机都不发送大量的报文的时候，这样就会让网络的压力就减小了！网络本身有自我的修复能力的！当压力减少！网络缓过来后我就能继续正常通信了！——这就是拥塞控制！==
==这就是为什么有拥塞控制的背景！==
虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍 然可能引发问题.
因为网络上有很多的计算机**, 可能当前的网络状态就已经比较拥堵**. 在不清楚当前网络状态下, 贸然发送大量的数据, 是很有可能引起雪上加霜的.
==TCP引入慢启动机制,即 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据==
如果一个报文都得不到应答，说明网络阻塞的太厉害了！那么过一会再发送一次报文！
如果发了一个报文得到了响应！那么第二次可以多发一点点，第二次收到响应，那么第三次就继续发送多一点，然后就是不断的增多
==这就是拥塞控制的原理==
上面的这种策略就是慢启动策略！
1.首先我们要引入一个概念——拥塞窗口！
什么是拥塞窗口呢？不要被这些抽象的名字给迷惑了！
像是我们的滑动窗口，16位窗口大小，16位窗口大小其实本质就是一个整数——只不过取了一个名字叫窗口大小！滑动窗口本质就是两个下标
==当我发送数据的时候！我们该如何知道发送了网络拥塞了呢？——我们说是出现大面积丢包的时候！但是丢包丢多少呢？而且一旦丢包的时候！那么就已经出现了！但是我们最好能做到防范于未然！即当我们的数据量一旦发送超过了某一个数字！可能会发送网络拥塞！我们最好不要让网络已经拥塞了再去解决！==
所以就引入一个概念！拥塞窗口！——==拥塞窗口的本质就是一个数字！==
==我们认为超过这个数字的时候！可能会发送网络拥塞的问题！==
这个数字因为没有在报头里面所以很难看出来！
我们上面说的什么滑动窗口，16位窗口大小！都是指接收方的接收能力！但是我们都没有考虑网络本身吞吐能力！所以就要有这个拥塞窗口来表示这个网络的吞吐能力！
2.发送开始的时候, 定义拥塞窗口大小为1
只要窗口大小为1，那么发送方就不能，或者尽量的不要超过拥塞窗口！
不能因为接收方的接收能力还很强！所以就一直大量的发送报文！
==明白之后我们就要重新认识一下什么是窗口大小！==
一般来说拥塞窗口会大一些！但是如果窗口大小更大！那么就会选用拥塞窗口！
3.每次收到一个ACK应答, 拥塞窗口加1
4.每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, ==取较小的值作为实际发送的窗口（滑动窗口）==
像上面这样的拥塞窗口增长速度, 是指数级别的. "慢启动" 只是指初使时慢, 但是增长速度非常快
指数增长只是前期慢！后期增长是非常快的！——那么为什么我们不使用线性增长呢？
之所以用指数增长是因为tcp要在可靠性和速度之间找一个平衡！
如果我们发一个报文，响应了，两个报文响应了！4个报文也响应了！那么此时就不是应该考虑网络的问题了！而是要考虑让网络通信的过程尽快恢复！——==而我们就可以利用指数增长前期慢增长的特点，让网络有缓冲的时间，让它恢复过来了！一旦网络恢复，那么就要立刻开始恢复网络通信过程！这就可以利用指数增长的后期快的过程来加速这个过程！==
那么指数级的增长，让拥塞窗口变得很大有影响吗？——没有！因为窗口大小是由接收方能力和拥塞窗口的较小值决定的！拥塞窗口变的很大！也只表示网络状况很健康！
==但是我们也是不能放任它一直增长下去==
1.为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.
2.此处引入一个叫做慢启动的阈值
3.当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长
==所以就有了以下的策略==
ssthresh——就是指数增长到线性增长的阈值
当遇到网络拥塞的时候，就会立刻将乘法减小，阈值也会减小原来的一半
当TCP开始启动的时候, ==慢启动阈值等于窗口最大值==
在每次超时重发的时候,==慢启动阈值会变成原来窗口大小的一半==, 同时拥塞窗口置回1（启动慢启动算法）
慢启动的发生！说明已经真实的遇到了网络拥塞！
像是上图，我们在拥塞窗口的最大是24的时候遇到了网络拥塞！
一旦开始超时重发！我们的==慢启动阈值==就变成了24/2 = 12!这就是,==慢启动阈值会变成原来窗口大小的一半==，同时拥塞窗口置为1，说明开始拥塞控制！
之所以会有这种策略是因为，不同时间段内的网络压力是不一样的！所以网络拥塞的窗口大小也是不同的！所以在任何主机里面拥塞窗口一定是一个变量！拥塞窗口的大小也不应该有TCP自己去定！而是应该去尝试！当发生了网络拥塞！去一次次的尝试——==指数增长在增长的时候除了为我们发送报文做指导！还为下一次更新拥塞窗口大小做准备！==
==所以指数增长和线性增长都是一个探测的过程！探测到网络拥塞了，那么就更新阈值然后重新来一遍上面的算法==
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.——保证了既有一定的可靠性又有一定的效率！
延迟应答
什么是延迟应答呢？我们举个例子：
==因为这个思想我们也可以说延迟应答可以增加网络的吞吐量！==
==或许读者会有一些问题==
1.如果等了一会但是上方没有取走呢？——这是一个概率问题！当我们发送很多的数据量，的时候一定会有大概率的情况窗口就是增大的！
2.那么如果窗口更新了！但是因为网络问题导致发送的数据量（拥塞窗口变小）其实并没有增加呢？——这也是一个概率问题！网络拥塞不是正常情况！那么就是一个小概率事件！大部分情况还是该怎么发就怎么发！
滑动窗口的实现
1.假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
2.但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
3.在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
4.如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;
一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输 效率
那么所有的包都可以延迟应答么?
肯定也不是; 数量限制: 每隔N个包就应答一次;
时间限制: 超过最大延迟时间就应答一次;
具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;
==上面我们说过超时重传！——延迟应答的时间是不能比超时重传还要长的！==
我们延迟应答！跳过一个报文再去应答这会不会出问题呢？——当然不会！==因为我们有确认序号！==
不一定所有的报文都要有应答！流例如10012000报文不应答！直到发送3001-4000的报文才应答！——只要我们返回的确认序号是4001！那么就保证了4001以前的报文都已经被收到了！——那么就其实不需要应答1001-2000
捎带应答
当我们主机A给主机B发消息的时候，主机B就要对主机A发送ACK报文进行确认！——这是没有问题的！
但是我们要记住ACK应答，本质ACK就是一个标志位！是以报文作为载体的！而是报文就有报头！有效载荷！
在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 "一发一收" 的. 意味着客户端给服务器说 了 "How are you", 服务器也会给客户端回一个 "Fine, thank you";
那么这个时候ACK就可以搭顺风车, 和服务器回应的 "Fine, thank you" 一起回给客户端
==这种携带数据的确认——就是捎带应答！而真实网络通信的时候这也是很常见的！==
面向字节流
创建一个TCP的socket, 同时在内核中创建一个发送缓冲区 和一个接收缓冲区
调用write时, 数据会先写入发送缓冲区中;
如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
然后应用程序可以调用read从接收缓冲区拿数据;
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做全双工
由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如
写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次
像是UDP，对方发一次！那么接收方就只能收一次——不会出现对方发10次！但是接收方一次就读取完毕了！也必须读取10次！
因为UDP会让每次收到的报文都独立的分开让上层去读取！这种报文和报文再UDP层有明显的边界的问题就是面向数据包
而TCP根本不关心数据是什么！你要读取几个就读取几个！
虽然TCP不关心，但是应用层关心！所以这就要应用层自己去维护！自己去保证数据的完整性！
粘包问题——修改
在我自己写的那个网络版本的计算器里面！我们自定义了协议！然后我们是基于TCP协议来进行通信！
而一个TCP连接里面可能不止有一个报文！可能有很多个！——但是我们网络版本的计算器，我们可以发送很多个！——==然后我们的重点就是读取一个完整的报文！==
但是如果我们没有将这个工作做好！例如：将第一个报文少读了，或者多读了从而影响了第二个报文！——==这种情况就是粘包或者沾包问题！==
好比吃包子，包子紧紧的堆放在一起，当我们拿起一个包子的时候，就可能连着将其他的包子一起拿起来！
==避免粘包问题的方式也很简单！——明确两个包之间的边界！==
==那么我们有什么办法来明确边界呢？==
1. 对于定长的包, 保证每次都按固定大小读取即可; 例如有一个的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;
2. 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段（自描述字段）, 从而就知道了包的结束位置;
3. 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序员自己来定的, 只要保证分隔 符不和正文冲突即可);
==以上的这些都是应用层在做的！TCP本身不提供这些实现！应用层要自己来实现！==
对于UDP协议来说, 是否也存在 "粘包问题" 呢?
对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用 层. 就有很明确的数据边界.
站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"的情况
==明白了这几点我们就可以明白！为什么UDP协议的报文结构里面有一个16位报文长度！而TCP报文结构里面，只有一个报头长度！但是没有有效载荷的长度！==
因为TCP之所以不需要有效载荷的字段，是因为TCP协议是面向字节流的！序号已经保证数据的起始位置！校验和保证了数据的完整性！收到TCP报文的时候！又不需要直接向上进行交付！要把数据放进接收缓冲区里面！所以收到数据直接放进接收缓冲区里面即可！和历史的数据都是糅合在一起了！但是因为TCP是面向字节流的！不需要进行区分！——让上层去自己处理！这就是为什么TCP不需要这个字段的原因！
TCP连接异常问题
我们这里讨论的连接异常不是指，那些什么握手失败，网络阻塞之类的！而是一些特殊的场景
场景一：客户端和服务器中的一个进程突然挂掉了那么会发生什么？连接会直接断开吗？
我们要明白一点，连接不是由我们进程直接维护的！因为连接从建立到关闭！都是我们去调用操作系统的系统调用接口来完成的！
我们可以举一个相似的例子：我们进程new或者malloc出来了一个内存空间！如果进程挂掉了！这个申请的内存空间还在吗？——肯定是不在的！即使我们进程最后没有去释放掉我们申请的空间！但是这个资源依旧会被系统回收释放！
==这个例子告诉我们！凡是操作系统资源的，只要进程挂掉了，那么操作系统会自己回收这些资源的！——因为我们进程挂掉了！也是操作系统来"收尸""的！==
==所以客户端和服务器如果挂掉了！那么操作系统会来回收我们曾经建立的连接！就跟关闭文件一样！==
==这个和我们自己调用close是没有区别的！也会有四次握手！==
场景二：如果这时候是有一方的操作系统正常关机了呢！那么会发生什么？
例如：我们重启windown系统的时候，在关机之前，Windows会提醒，还有些应用没有关闭！是否要强制关闭！
正常关机的时候，关机之前操作系统也要正常的杀掉用户进程！也就是说关机之前还是要退出进程的！——换句话说正常关机和我们直接退出进程没有任何区别！
==而有连接也会先断开连接然后杀死进程！然后也会触发四次挥手==
场景三：如果是直接拔网线，断开电源呢？
如果是拔网线，断开电源操作系统是没有时间反应的！
例如：客户端是突然断电关机！——==客户端直接关闭是没有时间发起四次挥手的！然后连接就关闭了！==
而服务器是会认为连接是正常的！
对于服务器来说就是多了一个一直不会发送消息的连接！但是服务器也有自己的保活策略！会定期的询问客户端！如果没有回复就会断开连接！
==这些保活策略是一般是由应用层来提供的！TCP自己虽然有提供一些策略但是很鸡肋==
TCP协议总结
可靠性策略
1.校验和
2.序列号(按序到达)
3.确认应答
4.超时重发
5.连接管理
6.流量控制
7.拥塞控制
提高效率的策略
1.滑动窗口
2.快速重传
3.延迟应答
4.捎带应答
其他策略
定时器(超时重传定时器, 保活定时器, TIME_WAIT定时器等)
