目录
TCP协议
重点掌握！！
最大的特点是可靠传输
可靠传输，并不是发送方能把数据100%传输给接收方，而是发送之后能够知道接收方是否收到数据，一旦发现对方没收到，就可以通过一系列手段来补救
引入可靠性的代价：传输效率变低，复杂程度提高
1.确认应答（达成可靠传输最核心的机制）
假设发送方先后发送两条数据A、B，接收方针对两条数据响应a、b，为了避免接收方发出的数据b比a先到，而让发送方误以为b是针对A的响应，出现歧义，TCP使用“序号”和“确认序号”描述数据先后关系
按照字节来编号（TCP面向字节流）
如何区分数据报是普通数据还是ack应答数据？
ACK这一位为1表示当前数据报是应答报文，此时数据报中的“确认序号”字段生效
ACK这一位为0表示当前数据报是一个普通报文，此时数据报中的“确认序号”不生效
常见面试题：
TCP如何保证可靠传输？
正确答案：通过确认应答为核心，借助其他机制辅助，最终完成可靠传输
错误答案：三次握手/四次挥手保证了可靠传输...
2.超时重传
网络传输过程中出现丢包时，发送方势必收不到ACK了，此时使用超时重传机制，针对确认应答进行补充
为什么会丢包？
路由器/交换机可以理解为高速上的收费站，数据太多时可以理解为收费站堵车了
传输时交换机/路由器的数据报太多了（堵车），一下子处理不过来，会把其中大部分数据报直接丢弃掉。此时数据报就在网络上消失了
TCP传输中丢包又分为两种情况
①传输的数据丢失了
②返回的ACK丢失了
重传操作能大幅度减少丢包概率（比如10%的丢包概率 重传丢包概率为10%*10%=1%）
等待时间超过多少发送方会触发重传？
①初始的等待时间可配置，不同系统上不一定一样，也可以通过修改一些内核参数引起时间变化
②等待时间也会动态变化，每经历一次超时，等待时间都会变长（第二次的等待时间比第一次的等待时间长，第三次比第二次长...若时间拉长到一定程度，很有可能网络出现严重故障，此时放弃tcp连接）
重传有可能会导致接收方收到两条相同的数据（如果发生在转钱这种场景下，是很大的bug！）TCP又是如何解决的呢？
TCP中有一个接收缓冲区的内存空间，保存当前已经收到的数据以及数据的序号，如果发送来的数据在接收缓冲区中已经存在，接收方就会直接丢弃
接收缓冲区不仅能去重，还能对数据重新排序，确保发送的数据与读取一致
3.连接管理（建立连接 断开连接）（三次握手 四次挥手）
三次握手 建立连接
（三次握手为面试中网络部分的重点！！）
syn为1则表示这个报文是同步报文段，为0则不是
syn同步报文段，一个特殊的tcp数据报，没有载荷，不携带任务
（主动发起的一方为客户端，被动接受的一方为服务器）
握手完成，A和B记录了对方的信息（构成了逻辑上的连接）
本质上就是通信双方都要给对方发起syn，也都要给对方反馈ack，把中间两次合并为一次一起发送，构成了三次握手
四次握手？没必要，合并为三次效率高
二次握手？不能保证双方都能接收、能发送
三次握手的作用
①投石问路，确认当前网络畅通
②让发送方和接收方都能确认自己的发送能力和接收能力正常
③让通信双方在握手过程中针对一些重要参数进行协商（比如tcp通信过程中的序号从几开始就是协商出来的 每次连接建立的时候都会协商出一个较大的数字，和上一次不一样的值。这是为了在网络不好的时候，客户端和服务器之间的连接断开，重连后旧数据姗姗来迟，而旧数据应当丢弃，通过比较序列号发现与当前正常的数据序列号差异很大，就可以得知数据为之前的旧数据，直接丢弃~）
四次挥手 断开连接
建立连接，一般都是客户端主动发起
断开连接，客户端和服务器都可以主动发起
FIN结束报文段
中间两次挥手能否合并？不一定
ACK和第二个FIN触发的时机不同，ACK是内核响应的，B收到FIN就会立即返回ACK。而第二个FIN是应用程序的代码触发的，B这边调用了close方法，才会触发FIN（三次握手中ack和第二个syn都是内核触发的，同一时机，可以合并）
clientSocket.close();这也就意味着，代码close没写/没执行到，第二个FIN就有可能一直发不出去
正常的四次挥手，就是正常的流程断开连接；如果没有挥完四次，会出现异常的流程断开
TCP中有延时应答机制（后续会讲），能够拖延ACK回应的时间，使ACK有机会和下一个FIN合并
TIME_WAIT会出现在主动断开连接的一方
目的是防止最后一个ACK丢失
如果最后一个ACK丢失了，B就会超时重传FIN，但如果没有TIME_WAIT A直接closed释放连接了，就收不到FIN也就返回不了ACK了，而此时B也就永远收不到ACK了
TIME_WAIT等待多久？
假设网络上两个节点通信消耗最大时间为MSL（可配置的参数），此时TIME_WAIT时间就是2MSL
4.滑动窗口
（前三个机制都是在保证ACK的可靠，可靠性的保证势必会降低效率，而滑动窗口就是降低可靠性对传输效率的影响）
滑动窗口机制下出现丢包会如何解决呢？
①ack丢了
不需要重传
（1001ack丢失，但2001ack到了，表明2001之前的数据都已经确认传输成功了）
（确认序号表示的含义是当前序号之前的数据都已经确认收到了，你应当从确认序号这里继续发送）
②数据报丢失
上述重传没有冗余操作，哪个数据丢失重传哪个，快速重传（滑动窗口下，超时重传的变种）
如果通信双方传输的数据量小、不频繁，仍然以普通的确认应答和普通的超时重传
如果数据量大，则进入滑动窗口模式，按快速重传的方式处理
滑动窗口越大，传输效率越高，但传输速度太快时，接收方可能会处理不过来，出现丢包情况，所以窗口大小要适中
（TCP前提是可靠性，在确保可靠的基础上提高效率）
5.流量控制
站在接收方的角度，反向制约发送方的传输速率
发送方的发送速率，不应该超过接收方的处理能力
A传输的数据，会先到达B的接收缓冲区中，B的应用程序调用read方法从接收缓冲区中读数据（一旦被read了 就充接收缓冲区中删除了）
接收方每次收到数据之后，都会把缓冲区的剩余空间大小通过ack返回给发送方，发送方按照这个数值大小调整下一轮发送速度
6.拥塞控制
考虑通信过程中中间节点的情况
中间节点情况复杂，难以量化，通过实验的方式找到合适的值（木桶原理）
让A先按照较小的速度传输（小的窗口），如果传输顺利，没有丢包，再尝试用更大的窗口，更高的速度传输，随着窗口不停增大，达到一定程度，如果出现丢包，就把窗口大小调小，如果还是丢包，继续调小，如果不丢包，就尝试调大
流量控制和拥塞控制都限制发送方的发送窗口大小，最终的大小取两者窗口大小的较小值
7.延时应答
A把数据发送给B，B立即返回ack给A（正常）
有时B会等一会再返回ack给A（延时应答）
延时返回是为了给接收方更多时间读取缓冲区数据，让缓冲区剩余空间变大，返回的窗口也就更大了
8.捎带应答
在延时应答的基础上，进一步提高效率
ack是内核立即返回的，response是应用程序代码返回的，两者时机不同
tcp引入延时应答之后，ack不一定是立即返回的，在等待过程中，如果response计算好了，两者就可以一起返回，两个数据报合并为一个，提高效率
9.面向字节流
针对粘（nian）包问题（多个应用层数据包传输时容易出现）
在接收缓冲区中，这三个应用层数据包的数据以字节形式紧紧挨在一起
相比之下UDP这样面向数据报的通信方式没有这种问题
如何解决粘包问题？
核心思路：通过定义好应用层协议，明确数据包之间的边界
a.引入分隔符
b.引入长度
10.异常情况的处理
a.进程崩溃
进程没了，文件描述表也就释放了，相当于调用socket.close（），进行正常的四次挥手断开连接（tcp的连接，可以独立于进程存在）（进程没了 tcp连接不一定没）
b.主机关机（正常流程）
在进行关机的时候，会触发强制终止操作（与a相同），触发FIN，对方收到后返回FIN和ACK，此时不仅是进程没了，整个系统也可能关闭了，如果在系统关闭之前对端的ACK和FIN到了，此时系统还可以返回ACK（正常四次挥手），如果系统关闭后ACK和FIN到，无法进行后续ACK响应，接收方以为FIN丢包，重传FIN，重传几次都没响应，自然会放弃连接
c.主机掉电（非正常）
这种情况来不及发送FIN
c1接收方掉电，那么发送方一直等待ack，触发超时重传，触发tcp连接重置功能，发起“复位报文段”，如果复位报文段发过去也没效果，此时就会释放连接
c2发送方掉电，那么接收方一直等待数据到达
tcp中提供了心跳包机制，接收方会周期性给发送方发送一个特殊的、不携带业务的数据包， 并期待对方返回应答，如果重复多次对方都没有应答，就会单方面释放连接
d.网线断开
与主机掉电类似
TCP与UDP对比
TCP可靠传输，适用于大部分场景
UDP效率更高，适用于可靠性不敏感，性能敏感的场景
TCP可以传输大数据包，UDP有64kb限制
UDP自身支持广播传输（把数据发送给局域网所有的机器），TCP不支持，需要写额外的代码实现
经典面试题：如何基于UDP实现可靠传输？
本质上就是在考察TCP，照抄TCP可靠传输的机制
①确认应答②确认序号③超时重传...
3017
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
