日升时奋斗，日落时自省
目录
TCP协议：
特点：有连接的、可靠传输、面向字节流、全双工
可靠性传输：是TCP内部的机制，和编码关系不大，咱们感知的不是很清楚
TCP详细图解
（1）首部长度
4位首部长度：一个TCP报头，长度是可变的，不是像UDP一样固定8个字节
因此，首部长度就描述了TCP报头具有多长，另外，选项之前的部分是固定长度（20字节）
首部长度 - 20字节 ==得到的就是选项部分的长度
20字节表示的就是 源端口号+目的端口号+序号+确定序号+窗口大小+验证和+紧急指针+首部长度的大框框
首部长度解释：4bit位
注：重要提示！！！ 首部长度的单位 不是字节 是4字节
举例（针对选项和首部长度的联系）：
如果首部长度值为5 ，表示整个TCP的报头长度是20字节（相当于没有选项）
选项=首部长度-20字节=20-20=0
如果首部长度值为10，表示整个TCP的报头长度是40字节
选项=首部长度-20字节=40-20=20字节
TCP报文=TCP报头（首部）+TCP载荷
（首部包含了选项及以上 载荷就是数据）
（2）保留位
保留（resevered）位：顾名思义 占个位置起来先不用，进行程序开发的时候，其中一个重点考虑的事情就是可扩展性。有些功能可能暂时不需要，但不代表以后不会再开发。
此处TCP的保留6位，也是为了以后的扩展考虑的，对于网络协议来说，扩展升级，是一件成本极高的事情，这里以UDP提一下这方面的弊端，UDP报文长度是2字节，因此一个包最大64kb，现在能不能把UDP协议升级一下，让UDP能够支持更大的长度，比如把报头长度使用4字节表示；此情况理论上可以，但是修改后的操作系统如何让全世界能够进行更新升级（升级设备涉及广泛 计算机、路由器、手机等等都需要）不是技术问题，而是使用问题，很难做到替代当前所有的设备
“保留位”的引入此时升级操作就会成本低不少，如果后续TCP引入了一些新的功能，就可以使用这些保留位字段
注：对于TCP本来的报头结构的影响是比较小的，老的设备即使不升级也能兼容
（3）选项
option（选项）=>optional（可选的，可有可无的）此处的选项相当于对这个TCP报文的一些属性进行解释说明的
TCP内部的工作机制：
TCP 可靠传输 是怎样做到可靠的
可靠传输不是说一定能把消息发给接收方（因为这个可靠跟网线没有关系，物理设备都断了，那就不可能发过去了）
此处是尽可能把数据传输过去，同时，如果还是传输不过去，至少能知道
1、确认应答
提示：实现可靠传输的最核心机制
TCP进行可靠性传输，最主要就是靠这个确认应答机制
其实简单化就是 A 给 B 发了个消息，B收到之后就会返回一个 应答报文（ACK），此时，A收到应答之后，就知道了刚才发的数据已经顺利到达B了
更加复杂的情况：
很明显，此处这里的应答就错乱的，表达意思出现歧义
总结：网络“后发先至”现象客观存在，无法避免，因此应答报文到达的顺序也是可能发生变动的。此时就需要考虑如何规避这种顺序错乱带来歧义
如何解决上述“后发先至” ，看的出来以上出现问题的原因在于顺序上出错，办法很简单，给传输的数据，和应答报文都进行编号。
引入序号以后此时就不怕顺序乱了，及时顺序乱了，序号就是最好判断方法
1.1、序号编辑
那序号是怎样编号的，当然不是以上编辑的序号不是按照“一条两条”这样的方式来编号的...TCP是面向字节流的，TCP的序号也是按照字节编号的
TCP的字节的序号是依次累加的，这个依次累加的过程对于后一条数据说，起始字节的序号就是上一个数据的最后一个字节的序号，每个TCP数据报报头填写的序号只需要写TCP数据的头一个字节的序号即可。
TCP知道了头一个字节的序号，再根据TCP报文长度，可以知道每个字节的序号，确认序号的取值，是收到的数据的最后一个字节的序号+1
总述：
<1>TCP可靠传输能力，最主要就是通过确认应答机制来保证的
<2>通过应答报文，就可以让发送方清楚的知道传输是否成功
<3>引入了序号和确认序号，针对多组数据进行详细的区分
2、超时重传
讨论确认应答的时候，只是讨论了顺利传输的情况，同样会产生问题：丢包？？？
丢包，涉及到两种情况：
<1>发的数据丢了
<2>返回的ACK丢了
发送方看到的结果，就是没有收到ACK区分不了是哪种情况，都是丢包的情况，针对丢包TCP是要处理的，因为丢包是一个概率性事件，（而且通常情况下，丢包概率已经很小了），重新发一下这个数据报，其实还是很大的概率成功传输（这里下面在做详细解释）
TCP直接引入重传机制：
在丢包的时候，就要重新再发一次同样的数据（到底当前这个传输，是丢包了，还是ACK走的慢，还没有被接收到）
此处TCP就直接引入了一个时间阈值，发送方发了一个数据之后，就会等待ACK，此时开始计时。如果在时间阈值之内，也没有收到ACK，无论是否ACK是在路上，还是彻底丢了，都视为是丢包了
超时重传，超过一定时间，还没响应，就重新传输
这个超时时间，具体是多少ms？ 这个时间可以配置，并且不同系统上面的默认值可能存在差别
以上带有重复数据或者操作（关键时候）可能会带来重大影响，但是针对以上重复数据或者操作带来的影响
TCP对于这种重复数据的传输，是有特殊处理，去重，TCP存在一个“接收缓冲区”这样的存储空间，（接收方操作系统内核里的一段内存）每个TCP的socket对象，都有一个接收缓冲区（发送缓冲区）
主机B 收到的 主机A的数据
其实是B的网卡读取到数据了，然后把这个数据放到B的对应的socket的接收缓冲区中，此处更像是一个优先级队列，根据数据序号，TCP很容易识别当前接收缓冲区里的这两条数据是否是重复的
自己本有这个功能，如果重复了，则把后来的这份数据就直接丢弃了，保证了应该程序调用read读取到的数据，一定是不重复的
TCP使用这个接收缓冲区，对收到的数据进行重新排序，使应用程序read到的数据是保证有序的（与发送顺序一致）
总结：由于去重和重新排序机制的存在，发送方只要发现ACK没有按时到达，就会重传数据，即使重复了，即使顺序乱了，接收方会处理好的
相应问题：
超时重传次数：重传的数据是否存在再次丢包？有可能，所以可能会重传N次（此处的N不是无限的），重传不会一直进行，重传几次还没有结果其实也就没有必要了，可能此时的网络出现问题了
举例：
传输丢包概率假设为：5% 第二次传输丢包的概率：5%*5%=0.25%
第三次还丢包的话，可想而知 0.25%*5% 等于的数字是何等的小，连续丢包能丢几次呀，概率实在太小了，所以多次丢包大可能是网络出现问题了，因为正常丢包不会太多次
因此，重新传输到一定次数的时候，就不会再继续重传，会认为网络故障，接下来TCP会尝试重置连接（网络重连），如果重置还是失败了，彻底断开连接
注：超时重传次数，可以配置
重传的时候，第一次重传和第二次重传，超时时间间隔，并不一样，执行重传时间上不是均匀的，一般情况，重传的次数越大，超时时间间隔就越大，因为超时重传次数越多，重传成功的概率就越小，此时重传的太快也是浪费资源，不如多等等（总结：超时时间变大，重传的频率降低）
总述：
<1>可靠传输是TCP最核心的部分，TCP的可靠传输就是通过 确认应答 + 超时重传 两者都是具体体现，共同支撑整体的TCP可靠性
<2>其中确认应答描述的是传输顺利的情况
<3>超时重传描述的是传输出现问题的情况
3、连接管理
连接管理：涉及到建立连接和断开连接
那连接（Connection）又是什么？？？如何做到连接的
以结婚类比：大体上结婚还是要有法律认可的结婚手段才是连接，法定结婚就是领证；领取的结婚证两个人一人一份，内容相同，但是针对两个人各自关注点不同
男方：认为了连接上了就是 这个结婚证上写 我老婆是这个女人
女方：认为了连接上了就是 这个结婚证上写 我老公是这个男人
这就是建立连接完成了
TCP 建立连接 ：
断开连接：针对实际上来说，离婚就是断开连接
此处A和B把自己存储的连接信息（数据结构）删除，连接就是断开了
3.1、三次握手
建立连接（三次握手）
通信双方各自要记录对方的信息，彼此之间要相互认同（图解）
上面看着也可以叫做“四次握手” 也能叫“三次握手”
只要不合并就可以叫做“四次握手”，针对这个就有两个问题？？？
为啥中间这两次要合并？不合并可以吗？
合并原因是：封装分用， 每次都要封装分用，都是要消耗成本的，所以必须合并，降低封装分用的成本
再问两次握手行不行？？？
答案：针对计算机肯定不行（图解）
总结：三次握手，本质上是“四次”交互，为了降低封装分用的成本，必须进行合并操作；通信双方，各自要向对方发起一个“建立连接”的请求，同时，再各自向对方回应一个ACK。
三次握手另外一个重要作用：验证通信双方各自的发送能力和接收能力是否正常，同时也一定程度的保证了TCP传输的可靠性（起到的不是关键作用，辅助作用）
此处再举一个实例：
三次握手的意义：
<1>让通信双方各自建立双方的“认同”
<2>验证通信双方各自的发送能力和接收能力是否可行
<3>在握手过程中，双方来协商一些重要的参数
以上都是简单以实例表现出出握手，以上实例每次的握手是一次通信同时也是一种协议
3.2、四次挥手
四次挥手就是断开连接，“挥手”和“握手”都只是形象的叫法，都是客户端服务器的数据交互
四次挥手和三次握手非常类似，都是通信双方各自向对方发起一个断开连接的请求，同时再各自给对方一个回应
以上是举例理解四次挥手 （下面详细解析）
TIME_WAIT保持连接不断开，那能保持多久？？约定一个时间为 2MSL
如果经历了2MSL时间还是没有收到 重传的FIN 就认为这个ACK就正常到达了（认为对方没有重传FIN）
2MSL 指的是，互联网上两个节点之间数据传输消耗的最大时间，（约定俗成）MSL具体的准数是多少？？一般情况下是60s（秒）
针对以上解释对四次挥手可能有点迷离：
四次挥手要做的事情这里简短的比喻一下：
<1>A发送 FIN
<2>B发送ACK
<3>B发送FIN
<4>A发送ACK
仅仅以上四次交互构成四次挥手（最后一个ACK没有丢包的情况下）
4、滑动窗口
TCP依存可靠性，所以传输效率就降低了很多比不上UDP（无可靠性）（可靠性和传输效率本身是相互矛盾的），TCP也有一些其他方法来补救传输效率，但是补救后仍然不及UDP，只是为了减少传输效率上针对TCP的影响；
滑动窗口的本质就是降低了确认应答，等待ACK消耗的时间
缩短渠道批量发送，批量等待，把多份等待时间合并成了一份
滑动窗口基本理解就是如上图解析，但是有数据传输就有可能会丢包（以下解释丢包情况）
5、流量控制
这是一种干预发送的窗口大小的机制
滑动窗口，窗口越大，传输效率就越高（一份时间，等的ACK就越多），当然窗口不能是无限大
<1>完全不等ACK，可靠性能否保障画上问号
<2>窗口太大，也会消耗大量的系统资源
<3>发送速度太快，接收方处理不过来，发了也白发
接收方的处理能力，就是一个很重要的约束依据，发送方法的速度，不能超出接收方的处理能力
流量控制要做的工作就是这个，根据接收方的处理能力，协调发送方的发送速度
那既然接收方的处理能决定发送的速度，如何探测接收处理能力？？
直接看接收方接收缓冲区的剩余大小
6、拥塞控制
流量控制和拥塞控制共同决定发送方的窗口大小是多少
流量控制：针对的是接收方的处理能力
拥塞控制：描述传输过程中的中间节点的处理能力
发送方按照滑动窗口的方式发送，此时“窗口大小”描述了发送速率
拥塞窗口和流量控制的窗口，共同决定了发送方实际的发送窗口（拥塞窗口和流量控制窗口的较小值）
7、延时应答
同样也是提升效率的机制，也是在滑动窗口的基础之上
滑动窗口的关键，让窗口大小在有限的范围之内扩大一点，传输速度就快一点
因此要做的是，在接收方能够处理的前提下，尽可能的把把窗口大小放大一点
延时收到数据之后，不是立即返回ACK 而是稍微等会再返回
等待的时间里，接收方的应用程序，将接受缓冲区的数据给消费一下，此时剩余的空间会更大
8、捎带应答
也是提高效率的方式，在延时应答的基础上，引入的捎带应答
服务器客户端程序，最典型的模型，就是“一回一答” （此处举例解释捎带应答）
9、面向字节流
面向字节流 引入问题：粘包问题
重点：针对解决方法
<1>约定好分隔符
<2>约定每个包的长度
两个任选其中一个就可以了
10、异常情况
异常情况不可抗拒因素
(1)进程关闭的情况
<1>进程崩溃了
进程没了，对应的PCB就没了，对应的文件描述符表就释放了，相当于socket.close()
此时内核会继续完成四次挥手，此时其实仍然是一个正常断开的流程
<2>主机关机（按照正常流程关机）
主机正常关机要先杀进程，然后才正式关机（杀死进程的过程中，也就是和上面一样触发四次挥手）
（2）进程来不及关闭
<1>主机掉电
<2>网络断开
假设是接收方掉电了（断网）
显然是来不及挥手，发送方仍然在继续发数据，发完数据要等待ACK，都断电了，ACK是真的等不到了，超时重传，再怎么重传，也收不到ACK，重传几次，还没有应答，尝试重置TCP连接，显然这个重置也会失败，最终面临的就是放弃连接
假设是发送方掉电了（断网）
接收方发现，没数据了，没数据是发送方挂了，还是发送方要组织下语言，稍等会再发？？？
接收方不知道现在发送方的特殊情况 那先等
接收方需要周期性的给发送方发送一个消息，确认下对方是否还工作正常
周期性发送消息：心跳包（确认通信双方是处在正常的工作状态）
<1>心跳，是周期性的
<2>如果心跳结束，那就是没了
3440
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
