网络原理 - TCP/IP文章目录网络原理 - TCP/IP前言一、应用层自定义协议流程二、传输层协议TCP核心机制介绍1 确认应答2.超时重传3.连接管理(面试常考4.滑动窗口5.流量控制6.拥塞控制7.延时应答8.捎带应答(配合延时应答)9.面向字节流10.异常情况1.进程崩溃2.主机关机(正常流程关机)3.主机关机(掉电)4.网线断开TCP常用状态经典面试题总结前言一、应用层自定义协议流程确定传输的数据信息确定传输的数据格式跟据需求 , 确定交互信息有哪些 , 请求 , 响应组织好数据格式组织数据格式 , 现在比较流行的3. xml(带宽消耗太多4. json(当前流行的方案之一请求{userId:1234,position:“123E45N”}5. google protobuf(也是当前流行的方案之一 ,但是可读性差一点 , 是二进制的除了自定义协议之外 , 还有大佬们研究好的现成的协议 : HTTP协议二、传输层协议UDP , TCPUDP协议格式每个协议都是报头载荷载荷就是应用程序包 , 应用程序包就是前面构造的XML格式的数据包或者是Json这样的数据包前面要加一个报头4各部分 ,每个部分2字节第一各部分 , 16位源端口号第二个部分16位目的端口号问题:一个进程能否绑定多个端口号能 , 工作中很常见 , 一个socket绑定到一个端口 , 一个进程可以创建多个socket问题 :一个端口号的是否可以被多个进程绑定我们认为是不能的第三个部分叫做UDP长度 , 整个报文长度 , 包含包头加载荷UDP最大传输长度64KB , 如果超出 , 就会截断如何解决应用层拆包组包本来一次相应返回10条广告 , 拆成两个UDP数据报 , 各自返回5条广告但实现成本高 , 网路传输可能会出现问题 , 会丢包 , 会顺序错乱建议换成TCP , TCP对于单个数据报的长度没有限制UDP当前使用的时候提前预估 你的数据有多长第四个部分 , 16位UDP检验和验证传输数据是否出错发送之前把数据准备好了 , 把这个数据每个字节代入到公式计算得到结果 , 校验和发送时把数据和校验和一起发送接收方收到数据和校验和接收方把数据代入到同样的公式计算得到结果再继续校验udp适用于本身不容易丢包对传输效率要求高的TCP16位源端口号16位目的端口号32位序号针对传输数据进行编号第一个字节的编号32位确认序号给ack(应答)报文使用关联这个ack是应答那个数据 最后一个字节的编号加一Tcp包头长度是不固定到因为选项 长度是不固定的剩下是20字节4位首部长度 表示TCP报头长度 4bit(就是1111)表示范围是0-15单位是4字节因此选项的长度是4的倍数首部最大长度是60保留(6位 ) 现在不用先占个位置说不定以后会用以后扩展的时候方便6个标志位16位创客大小16位校验和和UDP差不多16位紧急指针选项TCP核心机制介绍可靠传输 和代码关系不大TCP内部支持实现机制可靠传输不是100%能够送达消息给对方但知道对方是否收到1 确认应答核心机制1确认应答实现可靠传输的核心机制怎么做到 考确认应答后发先至情况出现原因传输数据的顺序错了解决引入编号重新排队但TCP是面向字节流的 不存在第一条第二条这样的概念因此针对字节进行编号应答报文和响应区别2.超时重传丢包发现达到一定时间没有返回ack重现传一下重传次数越多到达概率越大包会丢ack也会丢主机不知道哪个丢了只知道ack没有返回所以会重传数据有问题如果这个数据是扣款操作完蛋了重传动作是操作系统内核自动触发和应用程序无关传输的数据也是先到达接收方的操作系统内核对于接收方来说内核会给TCP的socket分配一个“接收缓冲区”(内存空间接收方的应用程序调用read这样的操作把缓存中的数据取走重传的数据到达缓存接收方会根据序号进行去重新数据丢掉所以应用程序仍然是读到一份数据因此不会重复扣款数据重新排队的过程也是在接受缓冲区中进行的TCP解决了可靠性也解决了数据传输顺序。数据重复传输的问题重传达到一定次数发送方认为是网络故障放弃当前TCP连接超时重传和确认应答是TCP实现可靠传输的核心机制网上很多资料是错的说TCP可靠传输核心机制是三次握手 错3.连接管理(面试常考建立连接断开连接是操作系统内核完成的面试常考TCP如何建立连接的如何断开连接的建立连接流程为“三次握手”握手:不包含业务数据的数据包没有载荷业务:应用程序中实现的一些功能握手流程客户端发送syn(同步报文)给服务器只有爆头没有载荷这样的豹纹需要标志一下TCP六个标志位里面第五个标志位syn设为一确认应答同样存在ack返回也相当于一次握手服务器返回ack服务端也发送给你syn客户端返回ack三次握手这不是4次服务器ack syn合并成一次ack为1就是应答报文同时syn为1就是同步报文及时应答也是发送连接合并原因:效率网络传输需要一系列封装分用多线程的同步含义其实是互斥TCP的同步含义是通知画图三次握手意义是什么1、初步验证通信是否通畅后续可靠传输大前提2、也是在验证通信双方发送能力和接收能力是否正常3协商关键参数 三次握手进行必要协商比如32位序号序号起始数值32位序号不是从一开始数据传输的时候有一个包没有传输到再次连接的时候到了不应该处理通过32位序号判断tcp的三次握手是在验证当前环境是否符合可靠传输的前提断开连接四次挥手 和握手类似都只有报头没有载荷没有业务断开连接客户端和服务器都可能先发起假设客户端先发finfin就是第六位标志位1发送fin2发ack2发fin1再发ack这里中间两步能不能合并不一定建立连接的时候ack和syn都是操作系统控制是相同时机因此可以控制ack返回时机是内核控制收到fin后触发fin返回时机是应用程序控制应用调用socket.close才会触发finsocket接收到fin信息到close之间的时间可能还有几百毫秒因为有别的逻辑时机不同合并不了4.滑动窗口为提高效率前面的“可靠效率”对效率是有损伤的只是减少损失批量传输一个大小称为窗口大小收到头一组的窗口向后挪动不会影响可靠传输丢包如何处理ack丢包不需要处理ack的确认序号后一个能包含前一个证明前一个已经到达数据丢包1到7千的数据1001到2千丢了连续发几个其他序号的数据但是反馈的确认序号都是1001的那么就能证明1001丢了就需要快速重传会重传1001到2千这个数据这个数据一补齐后接下来所要的就是70015.流量控制流量控制就是对滑动窗口大小进行控制否则流窗口特别大传输的特别快接收方处理不过来数据进入缓冲区后缓冲区满了缓冲区不会自动扩容只会让的新数据被丢弃流量控制根据接收方的处理能力来反向限制发送方的发送速度也就是窗口大小1.接收方的处理能力怎样衡量接收缓冲区剩余空间大小2.衡量了之后如何通知发送方做出限制把接受缓冲区剩余空间大小是通过ack通知发送方就放在16位窗口大小的地方上述机制保证的是TCP传输的可靠性不是安全性TCP是一个安全传输协议。这个说法是错误的6.拥塞控制和流量控制类似都是对滑动窗口做出限制。流量控制依据接收方的处理能力应在控制依据通信路径的处理能力刚开始按比较慢的速度发送数据没有丢包加大速度指数增长窗口大小达到阈值改为线性增长增长一定程度丢包了丢包后窗口缩小老式方案回到慢开始状态改为线性增长新式方案回到阈值线性增长新的阈值是丢包位置窗口大小2减小速度窗口大小不是固定值时刻动态变化也就是动态平衡而实际发送窗口大小看两个控制的较小值7.延时应答在滑动窗口的基础上提高效率如何让窗口大一点它是根据剩下空间的大小来衡量如果延迟返回这个数据可能应用程序就消费了一部分窗口大一点同时返回ack数目也可以减小8.捎带应答(配合延时应答)因为有延时应答返回ack的时候就可以把ack和响应一起合并成一个数据包Ack关键的只有包头不需要载荷响应数据关键的是载荷和四次挥手很像四次挥手可能会三次就是因为捎带应答9.面向字节流面向自节流的过程中可能涉及到粘包zhan nian这两个音都有TCP的缓存区里面数据包和包之间边界不明显但凡是自己留的方式传输都涉及粘包问题Udp也有缓冲区但它有节点每一个节点都是一个datagram packet解决方案1.引入分隔符特殊符号作为包的结束或者开头标记2.在数据开头的地方添加一个固定的属性表示数据包的长度如果使用线程框架框架一般把这个就处理好除非我们修改框架基于TCP原生开发10.异常情况1.进程崩溃和四次挥手完全相同正常通过close触发进程退出操作系统自动对文件资源进行释放(操作系统清理PCBPCB中的文件描述表)等价于调用close进程没了 连接还在还可以处理后续挥手过程2.主机关机(正常流程关机)先强制结束所有应用程序相当于进程崩溃正常关机会用一段时间足够四次挥手完成如果挥手没有完成发送fin后关机了服务器正常发送ack和fin但是他不会再收到ack了再重传多次fin后还没有ack单方面放弃连接服务器会把自己持有的客户端信息删掉3.主机关机(掉电)电源没了直接关机接收方掉电ACK无了发送放超市存储经过几次重传之后没有ack发送方只放弃连接给对方复位报文六个标志位第四位RST发送方突然沉默解除后无法区分什么情况是对方挂了还是休息一会接收方周期性给对方发一个“心跳包”不携带业务只为了触发一次ack没有ack噶了接收方主动断开连接心跳包是TCP常见的但我们一般自己实现这样的机制因为TCP太慢了4.网线断开发送方就相当于主机关机第一种情况接送放主机关机第二种情况TCP常用状态LISTEN 服务器持有状态服务器准备就绪随时可以有客户端连上连接时的状态ESTABLISHED 这个是客户端和服务器端都会涉及到的状态表示链接已经建立接下来可以进行网络通信了断开连接状态CLOSE_WAIT断开连接的时候收到FIN的一方会进入的状态收到FIN进入这个状态直到一方主动发出FIN服务器上出现了很多这个状态就是出现bug了TIMA_WAIT主动断开连接一方会进入的状态等待一定时间处理最后一个ACK丢包的情况或者重传如果此时他彻底释放TCP连接的话重传的fin就没人能处理了没有人能返回ack了等待时间是2MSLMSL表示网络传输过程中从一端到另一端的最大理论时间一般来说默认时间是一min如果服务器上存在大量的time wait此时意味着大量的链接都是服务器主动断开的服务器可以转客户端可以看看看自己代码怎么写的掂量掂量是不是出现bugTCP层和应用层要区分好就像断开连接和拒绝访问断开连接是TCP层拒绝访问是应用层六个标志位剩下两个URG表示紧急指针有效正常来说按顺序读取紧急指针是插队让后面的被读取。根据16位紧急指针来看从哪开始读这个机制现在已经不用了PSH催促标志位尽快交给应用程序但也没啥用选项是根据不同操作区分这里面的用途经典面试题如何基于udp实现可靠传输照搬TCP机制应答机制后发先至序号排序去重丢包超时重传建立连接先看是否通畅三次握手再进一步提高效率滑动窗口延时应答捎带应答流量应答拥塞控制TCP可靠UDP性能高总结