a站为什么会凉,制作网站的软件有那个免费,有没有专门做家纺的网站,专业云南做网站文章目录 UDP协议#xff1f;什么是校验和#xff1f;基于UDP的应用层协议(了解) TCP协议确认应答(可靠性机制)超时重传(可靠性机制)连接管理(可靠性机制)三次握手(重点)四次挥手(重点) 三次握手和四次挥手时客户端和服务器的状态滑动窗口(效率机制)流量控制(效率机制)窗口探… 文章目录 UDP协议什么是校验和基于UDP的应用层协议(了解) TCP协议确认应答(可靠性机制)超时重传(可靠性机制)连接管理(可靠性机制)三次握手(重点)四次挥手(重点) 三次握手和四次挥手时客户端和服务器的状态滑动窗口(效率机制)流量控制(效率机制)窗口探测(效率机制)拥塞控制机制(效率机制)延时应答(效率机制)捎带应答(效率机制)粘包问题异常情况处理 TCP和UDP的区别 UDP协议 UDP它是属于TCP/IP协议族中的一种。是无连接的协议发送数据前不需要建立连接因为不需要建立连接所以可以在网络上以任何可能的路径传输至于有没有传输到目的地UDP是不关心的所以UDP它是天然支持广播的就类似学校的广播只需要将声音传递给每个学生即可不需要学生的回复 学习一个协议最主要的就是去理解协议报文的格式 什么是校验和 在网络传输中因为一些外部因素的干扰就可能会出现数据传输出错的情况针对于这种情况接收方就需要有办法能够识别出出错的数据而校验和就是一种检验的手段。 举个例子例如你的妈妈告诉你说“去往超市给我买 西红柿黄瓜土豆菠菜 这四种菜”这里不仅告诉你了要买哪些菜而且还告诉你了是四种四种就好比一个校验和所以买完菜以后就可以检查一下是否是四种来确定是否买完了所以这就是一种校验 在计算机中校验和其实本质上是一个字符串体积比原始数据更小但又是通过原始数据生成的原始数据相同得到的校验和就一定相同反之校验和相同原始数据大概率相同但是理论上也会存在不同的情况而这种情况的概率也是非常低的。 如何基于校验和完成数据校验呢 发送方把要发送的数据整理好(假设为data1)通过一定的算法计算出校验和checksum1发送方把 data1 和 checksum1 一起通过网络发送出去接收方接收到数据(称为data2) 和 校验和checksum1而 data2 可能会和 data1 不一样接收方再根据 data2 按照相同的算法重新计算校验和得到checksum2对比 checksum1 和 checksum2 是否相同如果不同则认为 data1 和 data2 一定不相同如果 checksum1 和 checksum2 相同则认为 data1 和 data2 大概率是相同的 这里的计算校验和的算法都有简单累加算法、md5 、CRC等 简单累加算法把当前要计算校验和的数据每个字节都进行累加把结果保存到变量中累加过程中就算有溢出也没有关系如果中间某个数据出现传输错误的情况第二次计算的校验和和第一次就会不同但是这种算法有一定概率不太靠谱因为也可能会因为比特位的原因导致两个不同的数据得到相同的校验和 md5算法 md5有两个特点 1.定长不管原始数据多长计算得到的md5都是固定长度 2.分散给定两个原始数据就算是其中一个字节不同得到的md5都会差异很大 3.不可逆从原始数据计算 md5 很容易但是将 md5 还原成原始数据计算量就非常庞大了理论上是不可行的 基于UDP的应用层协议(了解) NFS网络文件系统TFTP简单文件传输协议DHCP动态主机配置协议BOOTP启动协议DNS域名解析协议 TCP协议 TCP报文格式 下面针对上表中的每个属性进行讲解 4位首部长度一个数据报 首部(报头) 载荷首部长度也就是报头长度表示该TCP头部有多少个32位bit(有多少个4字节)4位所表示的最大长度是15所以报头就是60字节而且TCP的报头是可变长的这一点也就和UDP不同UDP的报头固定就是8个字节而TCP这里在有选项的情况下报头可以更长 保留位 UDP有个问题数据报的总长度就是64kb报头固定就是八个字节而TCP这里就留了一个心眼就是我现在不用但是先占个位置后面如果有需要再使用。 6位标志位 URG紧急指针是否有效 ACK确认号是否有效 PSH提示接收端应用程序立刻从TCP缓冲区中把数据读走 RST对方要求重新建立连接所以携带RST标识的数据报也称为复位报文段 FIN通知对方本端要断开连接携带FIN标识的数据报也称为结束报文段 关于以上标识的用法在下面进行讲解 报文中的其他属性均在下面各个机制中进行讲解 TCP协议最大的特点就是可靠传输(TCP初心) 这里说的可靠传输不是说数据能够100%的传输给对方而是退而求其次当发送方发出去数据后能够知道接收方是否收到了数据一旦发现接收方没有收到数据就可以通过一系列的手段进行补救而发送方是根据TCP中的确认应答机制从而知道接收方是否收到了数据 确认应答(可靠性机制) 确认应答发送方把数据发送给接收方后接收方就会给发送方返回一个应答报文(ACK),发送方如果收到这个应答报文了就知道自己的数据是否发送成功了 后发先至 在传输数据时呢可能会出现一种这样的情况第二条数据比第一条数据优先到达这就是后发先至 对于后发先至的情况TCP就要做两个处理 确保应答报文和发出去的数据能够对上号也就是我先后发出的两条数据你给我的响应报文也都是可以对上号的不会出现歧义如果出现先发后至的现象时能够让应用程序这边仍然按照正常的顺序来理解 所以就用到了TCP报文中的 32位序号和 32位确认序号 对发出去的数据进行编号然后就可以根据这个序号进行应答这样就可以对应起来了而且在确认应答数据包里会有一个确认序号就算发生了后发先至也会根据确认序号对应答数据报进行排序这样就避免了信息出错。就实现了TCP的可靠传输所以确认应答就是实现可靠传输的最核心的机制 还需要注意的就是TCP是面向字节流的所以这里的序号也不是按照“一条两条”来编号的而是按照字节进行编号的每一个ACK中都带有对应的确认序列号意思是告诉发送者我收到了这些数据下一次你从哪开始发如下图(下图只是一个例子并不是真实的情况) 而在TCP报文中也使用了一个标志位来表示哪些数据包是普通数据包哪些数据包是应答数据包 如果这一位是 1表示当前数据包是一个应答报文此时该数据包中的“确认序号字段”就能够生效 如果这一位是 0表示当前数据包是一个普通报文此时数据包中的“确认序号字段”不会生效 超时重传(可靠性机制) 以上就是关于确认应答机制的讲解确认应答它是一个比较理想的情况但是如果网络传输过程中出现丢包了发送方就无法收到ACK了那么就需要使用超时重传针对确认应答进行补充。 补充为什么会丢包 举个例子比如我们在高速公路上开车时会有收费站在平时高速上的车比较少在收费站这里不会出现堵车的情况但是在国庆时高速上收费站就会出现堵车几个小时的情况在网络上数据包在传输时会经过很多的交换机和路由器而这些交换机和路由器就是“收费站”在数据包非常多的情况下在路由器这里就会出现“堵车”而路由器的处理就会很粗暴并不会把这些数据包给保存好进行处理而是会把大部分的数据包直接丢弃掉此时这个数据包就丢失了 由于丢包是一个随机事件所以在TCP的传输过程中丢包存在两种情况 传输的数据丢了返回的ACK丢了 无论出现上述的那种情况发送方都会进行“重新传输”第二次第三次….随着次数的增加那么出现丢包的概率就会非常小 假设一次丢包的概率是 10%那么两次传输都丢包的概率就是 10%*10% 1%所以重传操作大幅度提升了数据能够被传过去的概率 所以当引入“可靠性”时也是会付出代价的这个代价就是1.这个过程非常复杂2影响传输效率所以这也就是UDP能够不被TCP完全取代的意义在特别需要性能的场景下UDP还是会比TCP更胜一筹 发送方何时进行重传 发送方发出去数据之后会等待一段时间如果在这个时间之内ack来了此时就认为数据到达了如果超过了等待时间就会触发重传机制~~这里的初始等待时间不同的系统上都不一定也可以通过修改一些内核的参数引起这里的时间变化而且等待的时间也会动态变化每经历一次超时等待的时间就会变长这里的变长当然也不是无限的拉长而是拉长到一定时间后就会认为数据再怎么重传也没用了就会触发TCP的重置连接操作。 还有一个问题就是如果是ACK丢了如果触发了超时重传重新再传一次数据那么在接收方这里就会收到两条同样的数据所以针对这样的问题TCP也已经解决了TCP会有一个“接收缓冲区”就是一个内存空间会保存当前已经接收的数据以及数据的序号如果接收方发现当前发送方发来的数据已经存在于接收缓冲区中了接收方就会直接把这个后来的数据给丢弃掉也就进行了去重就确保了应用程序读到的只有一条数据。 所以接收缓冲区不仅仅可以进行去重还能进行排序确保发送的顺序和应用程序读取的顺序是一致的这也就用到了序列号和确认序列号 连接管理(可靠性机制) 三次握手(重点) 建立连接的过程就叫做三次握手 TCP这里的握手也就是给对方传输一个简短的没有业务的数据报通过这个数据包来唤起对方的注意从而触发后续的操作 挥手也是同样的操作 TCP的三次握手TCP在建立连接的过程中需要通信双方一共“打三次招呼”才能够完成建立连接如下图 第一步 假如 A 想要和 B 建立连接A就会主动发起握手动作A就会给B发送一个没有任何意义的数据包也就是syn(同步报文段)这个同步报文段也是一个比较特殊的 TCP 数据包因为它是没有载荷的(没有携带任何业务数据的)就是在TCP的报头里面有一个 SYN 标志位在接收方这里如果发现这个SYN标志位为1就会知道这是一个同步报文段 第二步 B 收到这个同步报文段后就会使用TCP的应答机制给 A 返回一个ack(应答报文)告诉A你发送的数据包我收到了同时呢B 还会给 A 也发送一个 syn(同步报文段) 第三步 A 收到 B 发来的 ack 后就知道了 第一次给 B 发的 syn同步报文段B已经收到了同时也收到B发来的syn后就会再给B返回一个ack应答报文然后B就能知道给A发的ack 和 同步报文段 A已经收到了 建立连接的过程其实是通信双方都要给对方发起 syn 也都要给对方返回 ack总的来讲一共是四次交互了但是中间两次恰好可以合并成一次 经过上述过程后握手就完成了此时A 和 B 就记录了对方的信息连接就完成了 三次握手是要解决什么问题通过四次握手是否可行通过两次握手是否可行 因为TCP的初心就是可靠传输而可靠传输的核心机制是确认应答 和超时重传要进行这样的机制就需要有一个大前提就是当前的网络必须是通畅的如果网络都出现故障了那么就不可能实现可靠传输了。 所以三次握手的第一个核心作用就是投石问路确认当前网络是否是通畅的。第二个作用就是要让发送方和接收方都能确认自己的发送能力和接受能力 举个例子 例如我在和女朋友双排打游戏而且我们都带着耳机和麦克风进行沟通所以在打游戏前我就要和女朋友测试以下耳机和麦克风是否可用所以第一、我就会先hello 一声然后她听见后站在它的角度她就知道了她的耳机和我的麦克风是没问题的但是我是不知道的第二、然后她就会再喊 hello hello 然后我就可以听见了这时候站在我的角度我就知道了我的耳机和我的麦克风以及她的麦克风她的耳机都是没问题的但是她还不知道她的麦克风能不能用呀所以第三、我就会再 hello hello hello 几声这时候她就知道了她的麦克风她的耳机以及我的麦克风我的耳机都是可用的所以接下来就可以开黑了~~ 如果是两次握手的话最后的 hello hello hello 我不喊她是不知道他的麦克风是否是能用的而如果是四次握手的话可以是可以但是就已经是画蛇添足有点多余了 第三个核心作用让通信双方在握手的过程中针对一些重要的参数进行协商 举个例子就比如我们的手机和充电头的功率假如我们的手机是支持90w的功率充电头支持60w的功率当插上电以后手机中的芯片和充电头的芯片就来握手在这个过程中就会针对使用多大的功率进行协商以及确定最后的使用功率 在这握手的过程中协商的信息是有好几个的例如最典型的就是TCP通信过程中的序号是从几开始每次连接时一般都会协商一个比较大的和上次不一样的值 这样搞的目的也就是为了避免“前朝的剑斩本朝的官”因为有的时候网络如果不太好客户端与服务器就可能会断开连接再重新建立新的连接此时旧连接时发的数据就可能在建立好的新连接中发过来而这种迟到的数据应该丢弃掉以防止上个朝代的数据影响到本朝代的逻辑所以就是通过序号的设定规则来区分这个数据是上个朝代的还是这个朝代的。 四次挥手(重点) 断开连接的过程叫做四次挥手 建立连接一般都是客户端发起的谁发起连接谁就是客户端而断开连接客户端和服务端都可以发起。 假如A 想要和 B 断开连接A 就会给 B 发送一个 FIN 结束报文段然后 B 就会给 A 再返回一个 ACK 和一个 FIN最后 A 就会再返回一个 ACK此时就断开了这个时候就相当于 A 和 B 都把对端的信息删除了 这里的 四次挥手 和 三次握手 不同此处的四次挥手是否能将中间的两次合二为一这个是不一定的 不能合并的原因是ACK 和 第二个 FIN 的触发时机是不同的因为 ACK 是系统内核响应的 在 B 这边收到 FIN 后 就会立即返回 ACK 而第二个 FIN 是应用程序的代码触发的B 这边的 FIN 是在B这边的socket 对象被close 时才会被发起的从 B 收到 FIN(同时返回ACK)再到执行 close这中间要经历多少代码经历多长时间是不确定的就看代码是怎么写的了。而三次握手中的 ACK 和 SYN 都是内核触发的是同一时机所以可以合并如果B这边的代码没有close或没执行到是不是第二个FIN就一直发不出去 首先呢这个四次挥手它是一个正常流程的断开连接如果说没有挥完四次它就是一个异常的流程也是会断开连接的。 以上是不能合并的原因能合并的原因是在TCP中还有一个机制延时应答机制它能够拖延 ACK 的回应时间一旦ACK滞后了就有机会和下一个FIN合在一起了 三次握手和四次挥手时客户端和服务器的状态 下图是TCP经历三次握手和四次挥手的一个状态转换图 listen状态服务器状态。服务器这边将 socket 创建好并且把端口号绑定好此时就会进入 listen 状态此时就允许客户端随时建立连接了。 ESTABUSHED 状态客户端、服务器都会有的状态表示连接建立完成接下来就可以进行正常通信了 服务器端状态转化 【CLOSED-LISTEN】 服务器调用listen后进入LISTEN状态等待客户端连接 【LISTEN - SYN_RCVD】一旦监听到连接请求(同步报文段)就将该连接放入内核的等待队列中并向客户端发送ACK确认报文。 【SYN_RCVD - ESTABLISHED】服务端一旦收到客户端的应答报文就进入ESTABLISHED状态就可以进行读写数据了 【ESTABLISHED - CLOSE_WAIT】当客户端铸锻关闭连接(调用close)服务器会收到结束报文段服务器返回应答报文并进入CLOSE_WAIT状态 【CLOSE_WAIT - LAST_ACK】进入CLOSE_WAIT后说明服务器准备关闭连接当服务器真正调用close关闭连接时会向客户端发送FIN此时服务器就进入了LAST_ACK状态进行最后的确认等待最后一个ACK的到来 【LAST_ACK - CLOSED】服务器收到FIN的ACK后进入CLOSED彻底关闭连接 客户端状态转化 【CLOSED - SYN_SENT】客户端发送同步报文后进入SYN-SENT 【SYN-SENT - ESTABLISHED】发送成功后(收到synack)进入ESTABLISHED状态开始读写数据 【ESTABLISHED - FIN_WAIT_1】客户端主动调用close时向服务器发送结束报文段同时进入FIN_WAIT_1 【FIN_WAIT_1 - FIN_WAIT_2】客户端收到服务器对结束报文的确认(返回的ACK)则进入FIN_WAIT_W开始等待服务器的结束报文段 【FIN_WAIT_2 - TIME_WAIT】客户端收到服务器发来的结束报文段进入TIME_WAIT并发出最后的ACK 【TIME_WAIT - CLOSED】客户端要等待一个2MSL(Max Segment Life报文最大生存时间)的时间才会进入CLOSED状态 为什么TIME_WAIT要等待2MSL MSL是TCP报文的最大生存时间因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失否则服务器立刻重启可能会收到来自上一个进程的迟到的数据但是这种数据很可能是错误的同时也是在理论上保证最后一个报文可靠到达假设最后一个ACK丢失那么服务器会再重发一个FIN。这时虽然客户端的进程不在了但是TCP连接还在仍然可以重发LAST_ACK 滑动窗口(效率机制) 确认应答机制超时重传机制连接管理机制都是在保证TCP的可靠性由于TCP引入了可靠传输多出了一些等待ACK的时间所以单位时间内传输的数据就会减少影响了传输效率所以就使用了滑动窗口来降低可靠传输对性能的影响 如下图 一次发送1000个字节的数据那么在主机A这边还要再一直等待主机B这边的ACK这种一发一收的情况效率就比较低 如下图使用滑动窗口来批量传输数据 一批一批的传输如上图四个段为一批在传输前四个段时不需要等待任何ACK直接发送这一批传输完后开始接收ACK窗口大小就是指每一批传输的最大数据量上图窗口的大小就是4000字节收到第一个ACK后滑动窗口向下移动 就这样同时返回ACK同时发送接下来的数据这个窗口中始终保持着4000字节的数据操作系统内核为了维护这个滑动窗口需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答只有确认应答过的数据才能从缓冲区中移除如果一直没有移除的话就表示丢包了至于发生丢包后的措施在下面讲解窗口越大则网络的吞吐率就越高 **如果出现丢包现象该怎么办**针对这种现象就有两种情况 情况1传输过程中ACK 丢了 这种情况不需要我们进行任何处理这时候确认序号就起到了大作用确认序号表示的含义是当前序号之前的数据已经确认收到了下一个应该从序号这里继续发送就比如下图2001的ack丢了但是3001的ack到了此时就表示3001之前的数据都已经确认传输成功了包含 2001 数据的情况 情况2传输过程中数据丢了 例如下图1001~2000 的数据丢了所以在返回 ACK 时无论当前传输的数据是多少都会一直索要 1001同时窗口中的数据还会继续发送等到主机A察觉到 1001 这个数据丢失了就会重传 1001~2000 传输完之后就会继续从下图 8001 开始因为虽然 1001 丢了但是其他的数据还是在正常的传输当丢失的数据补上之后就会继续按照当前应该传输的数据继续向下以此类推 TCP针对于这一块会有动态的调整如果通信双方传输的数据量比较小也不频繁就仍然是普通的确认应答和普通的超时重传如果通信双方传输的数据量比较大也比较频繁就会进入到滑动窗口模式 通过滑动窗口的方式传输数据效率是会得到提升窗口越大传输的效率就越大但是窗口设置的太大也是不太好的因为如果传输的速度太快就可能使接收方处理不过来此时接收方就会出现丢包发送方还得重传为了控制发送方的发送速度在接收方就利用流量控制机制进行调整 流量控制(效率机制) 流量控制是站在接收方的角度反向制约发送方的传输速度发送方的发送的速度不应该超过接收方的处理能力 那么它是如何对窗口进行调整的呢 答案首先发送方发送数据到接收方数据到达接收方的系统内核中因为TCP Socket对象带有接收缓冲区所以发送方给接收方发送的数据就会放在接收缓冲区中随后接收方的应用程序从接收缓冲区中读取数据读取过的数据就会从缓冲区中删除所以想要知道接收方处理能力的速度通过接收缓冲区剩余的大小就可以间接的知道如果接收缓冲区空间大就意味着处理能力强剩余空间小处理能力就较弱从而动态的调整滑动窗口的大小 在返回应答报文中接收缓冲区剩余空间的大小也会记录在报文中的16位窗口大小这个属性中但是他并不是只有16位的大小在报头中的选项部分里有一项是“窗口扩展因子”通过这个窗口扩展因子让16位窗口大小表示一个更大的值 窗口探测(效率机制) 在滑动窗口机制下传输数据它是批量传输的在这个过程中如果接收方还没有来得及处理接收缓冲区中的数据那么发送方每传过去一段数据接收缓冲区剩余的空间就减小一些等到剩余空间为0时此时发送方就会意识到现在不能再继续发送数据了要等待接收方处理了一些数据后再继续发送而此时发送方具体要等待多长时间呢这个发送方是不知道的所以发送方就会周期性的给接收方发送一个不带任何业务数据的 “窗口探测包”这个探测包就只是为了触发ACK为了查询接收方这边的接收缓冲区剩余空间大小 拥塞控制机制(效率机制) 在通信过程中是需要通过很多交换机和路由器进行转发的在这个转发的过程中任何一个节点处理能力达到了上限都可能会对发送方产生影响都可能会影响到可靠传输就算是接收方还有处理数据的能力但是如果中间的某个节点不给力那么仍然是会影响整个通信的情况所以流量控制机制它考虑的接收方的处理数据的情况拥塞控制机制就衡量了通信过程中中间节点的情况 拥塞控制机制具体是什么样的 因为流量控制机制是通过接收缓冲区剩余的大小来对接收方的处理能力进行了量化而通信过程中数据在中间节点上进行转发时这个过程是更加复杂的很难进行直接量化所以拥塞控制就通过 “实验” 的方式来找到一个合适的值 例如先让发送方按照比较低的速度通过小一点的窗口发送数据如果数据传输的过程非常顺顺利没有丢包在尝试使用更大的窗口更高的速度进行发送就这样一点一点的去试探这个底线在哪里随着窗口大小不停的增大达到一定程度可能某个中间节点就会出现问题此时这个节点就可能会出现丢包之后发送方发现丢包了就再把窗口大小调整小就这样来回的进行调整窗口大小逐渐达成 “动态平衡”这样的一个过程就被称为 “拥塞控制”。 下面通过图可以更直观的看出动态变化现象 在慢开始阶段发送的次数会比较慢窗口的大小会按照指数规律(翻倍)进行扩大达到一定的阈值后也就是图中ssthresh的初始值 16指数增长就会变成线性增长线性增长到一定程度中间某个设备可能就顶不住了就会出现丢包现象一旦触发丢包也就是图中网络阻塞时就会把窗口再缩小重新进行前面的 慢开始 - 指数增长 -线性增长并且会根据当前丢包窗口的大小重新指定开始线性增长的阈值也就是图中的新的 ssthresh 值12就是为了避免指数增长时一下就达到了丢包的极限 上图是TCP经典版本的拥塞控制TCP对拥塞控制又进行了一个改善如下图 原来的版本它把之前积累的速度一下子给清零了继续又从指数增长的过程开始了但是我们已经知道了阈值前的窗口大小是不会丢包的所以就没有必要再从头开始了就可以直接从新设定的阈值的地方开始线性增长这样也就提高了效率 流量控制 和 拥塞控制 都是在限制发送方的滑动窗口大小最终发送的窗口大小也是取决于 流量控制 和 拥塞控制 中的窗口的较小值。 延时应答(效率机制) 当 发送方 发送数据给 接收方 时接收方就会立即返回 ACK 给发送方这是一种正常情况但是也有的时候为提高效率发送方发送数据给接收方后接收方等一会儿再返回ACK给发送方此时就是 “延时应答”。 延时应答机制本质也是为了提高传输效率因为发送方的窗口大小就是传输效率的关键而流量控制这里就是根据接收缓冲区的剩余空间来决定发送速率的如果能够有办法让流量控制这里计算的值较大让发送方的窗口更大点发送速率更快点(而这个变大的前提也是能够让接收方能处理过来)所以就可以通过延时返回 ACK 给接收方更多的时间来读取接收缓冲区的数据此时接收方读完数据以后接收缓冲区的剩余空间就变大了返回的窗口大小也就可以变得更大了 捎带应答(效率机制) 捎带应答是在延时应答的基础上进一步的提高效率 在网络通信中往往都是 “一问一答”的通信模型如下图 当 A 给 B 发送了一个Request请求后在 B 这边系统会立即返回一个 ACK给 A而响应的业务数据 Response 需要等应用程序执行完在返回所以这两个返回的时机是不同的由于 TCP 引入了延时应答所以ACK 不一定立即返回可能会等一会儿而在这个等一会的过程过程中 B 正好将 Response 给计算好了计算好之后就会将 Response 返回与此同时也就会将刚才要返回的 ACK 也顺带带上这就是 “捎带应答机制”本来是要传输两个tcp数据包(进行两次封装分用)因为捎带机制就可以将两个包合并成一个所以也就提高了效率 粘包问题 因为 TCP 是面向字节流的所以这里就会出现一个问题- “粘包问题”而“粘包问题”并不是TCP独有的而是所有面向字节流的机制都有类似的情况此处的 “包” 指的是应用层数据包如果同时有多个应用层数据包被传输过去此时就容易出现粘包问题 如下图讲解 假设AAABBBCCC是三个应用层的数据包发送给 接收方B 后会放在接收缓冲区中因为此时面向的是字节流所以在接收缓冲区中是按照字节的形式紧紧挨在一起接收方的应用程序在读取数据时可以按照读取1个字节2个字节……N个字节的方式读取但是最终的目的是为了得到完整的应用层数据包但是此时 B 的应用程序就不知道缓冲区里的数据从哪里到哪里是一个完整的应用层数据包在解析数据时就不知道该如何解析了这样的一个情况就是“粘包问题” 相比之下像 UDP 这样面向数据包的通信方式就没有上述问题因为UDP通信过程中是以数据报为单位的UDP 的接收缓冲区中相当于是一个一个的 数据报对象应用程序就可以以数据报为单位进行读取 如何解决粘包问题 答案核心思路通过定义好应用层协议明确应用层数据包的边界规定这个边界就有两种方式 1、引入分隔符 在每一段数据的最后都加一个\n表示\n前的数据是一个完整的数据包 2、引入长度 在数据的头部加上整个数据的长度在接收方读取数据时根据头部的数据长度读取完整的数据包 异常情况处理 如果在使用TCP的过程中出现意外会如何处理例如以下的几种异常情况 1.通信过程中进程崩溃 进程异常终止对应的文件描述符表也就释放了此时就会触发四次挥手就会触发 FIN 对方收到之后自然就会返回 FIN 和 ACK这边再进行 ACK然后双方断开连接TCP的连接是可以独立于进程存在的进程没了TCP连接不一定会消失 2.主机关机(正常流程) 进行关机时就会先触发强制终止进程操作这时候就相当于回到了上面第一种情况了但是在关机时不仅仅是进程没了整个系统也可能关闭了如果在系统关闭之前ACK 和 FIN 到了此时还是进行正常的四次挥手如果系统已经关闭了ACK 和 FIN 迟到了无法进行后续 ACK响应了站在对端的角度对端以为是自己的 FIN 丢包了就会重传 FIN 重传几次后都没有响应自然就会放弃连接。因为四次挥手就是一个友好的断开过程在断开前会打一声招呼如果在多次打招呼后都没有得到响应也是会断开连接的 3.主机掉电(非正常) 主机掉电是一瞬间的事情就来不及杀死进程来不及发送FIN一下子就没了站在对端主机的角度对端是不知道这个掉电的事情的。 第一种情况 1、如果是 发送方 发送数据接收方掉电发送方发送后就会等待 ACK等不到ACK后就会触发超时重传如果一直等不到ACK就会触发 TCP 的连接重置功能发起 “复位报文段”也就是将 RST 进行标记这个复位报文段发过去之后就期望对方返回一个 ACK 但是此时接收方已经掉电了无法返回这个ACK此时就没有产生效果此时发送方这边就会自动放弃连接 第二种情况 2、如果接收方正在接收数据发送方掉电此时接收方还在等待数据到达但是发送方已经掉电了数据发送不过去而在接收方的角度就无法区分发送方已经掉电了还是发送方根本没发送数据针对这种情况TCP 还提供了 “心跳包机制”在接收方这里它会周期性的给发送方发送一个特殊的不携带业务数据的数据包并且期望对方返回一个应答。如果对方没有应答并且重复了多次之后仍然没有就会视为对方挂了此时就可以单方面的释放连接了 4.网线断开 这里的网线断开和主机掉电是非常类似的假设 A 正在给 B 发送数据一旦网线断开A 就会触发 超时重传 - 连接重置 - 单方面的释放连接 B 就会触发心跳包机制 - 发现对端没有任何响应 - 单方面释放连接。 TCP和UDP的区别 1.TCP是有连接的UDP是无连接的 这里的连接是抽象的概念这种连接是指建立连接的双方各自保存对方的信息 按照TCP协议进行通信时发送数据前要建立连接连接完成之后才能进行通信 UDP是无连接的协议发送数据前不需要建立连接是没有可靠性 举个例子 TCP通信可看作打电话 李三(拨了个号码)喂是王五吗 王五哎您谁啊 李三我是李三我想给你说点事儿你现在方便吗 王五哦我现在方便你说吧。 甲那我说了啊 乙你说吧。 (连接建立了接下来就是说正事了…) UDP通信可看为学校里的广播 播音室喂喂喂全体操场集合 2.TCP是可靠传输UDP是不可靠传输 网络通信过程中A给B发送的数据并不是100%就可以发送成功的因为再牛逼的技术也敌不过挖掘机的一铲子如果你传输数据的光纤断了那么这是肯定不会传过去的或者说就算是无线通信 它们虽然牛逼但是它们数据传输的速率/稳定性是一定不如有线的而且在无线通信过程中意外因素也会更多 所以在A给B发消息时B这一方是否接收到了消息A自己是可以感知到的(根据确认应答机制)进一步的如果发送失败就可以采取一定的重传措施之类的所以虽然不能达到100%但是也采取了一些重传机制进行弥补就会非常可靠 而UDP就没有内置可靠传输它就是消息发出去后UDP就继续做自己的事情就才不会管你到底有没有成功。 既然可靠传输听起来这么美好为啥UDP也不搞一个呢 因为这就像是我们生活中想要更好的东西需要更高的代价去交换的而这里的可靠传输要付出的代价就是 1.机制更复杂 2.传输效率会降低 3.TCP是面向字节流的UDP是面向数据报的 网络通信中TCP是以字节为单位进行传输的比如要传100字节的数据它可以每次传10字节分十次传完也可以每次传50个字节两次传完也可以一次传完这就是字节流的意思。 UDP是以数据报为单位进行传输的数据报的大小只有64kb并且不能够拆分和合并 4.TCP和UDP都是全双工的 一个信道允许双向通信就是全双工 一个信道只允许单向通信就是半双工 代码中使用一个Socket对象就可以实现发送数据也能接收数据 而UDP就没有内置可靠传输它就是消息发出去后UDP就继续做自己的事情就才不会管你到底有没有成功。 既然可靠传输听起来这么美好为啥UDP也不搞一个呢 因为这就像是我们生活中想要更好的东西需要更高的代价去交换的而这里的可靠传输要付出的代价就是 1.机制更复杂 2.传输效率会降低 5.TCP只支持点对点通信UDP支持一对一、一对多、多对一、多对多