上篇文章我为大家介绍和演示了关于 UDP 和 TCP 两个协议的网络编程两个协议的网络编程还是有一定的区别我个人感觉 TCP 的网络编程会比 UDP 的复杂不少也更需要我们去理解并且熟练地掌握。这篇文章我将为大家介绍关于 TCP 协议中的十大核心机制。TCP 的特点有连接可靠传输面向字节流全双工1. TCP 报文段首部格式解析2. 十大核心机制1.确认应答2.超时重传3.连接管理4.滑动窗口5.流量控制6.拥塞控制7.延时应答8.捎带应答9.面向字节流10.异常情况TCP 报文段首部格式解析在讲解十个核心机制之前我们先对这张表进行一个大概的了解16位源端口号发送方应用程序的端口号告诉接收方我是谁16位目的端口号接收方应用程序的端口号告诉网络要把数据传输给谁32位序列号数据包的编号TCP将一个大的数据拆分成很多个小块进行发送这个序列号给数据块排队使用接收方收到乱序的包后可以根据这个序号把它们重新拼成正确的顺序。32位确认序列号期望下一个收到字节的序列号这是接收方给发送方的反馈意思是“在这个序号之前的数据我都收到了请发下一个”。它是TCP可靠传输的核心。4位首部长度表示TCP头部有多长告诉接收方数据从哪里开始读取。图中右侧标注的“20 字节”指的是标准头部的最小长度。保留6位暂时不需要设置设置为0。这个是吸取了UDP的教训URG (Urgent):紧急指针有效表示包里有紧急数据需要优先处理。ACK (Acknowledgment):确认序号有效。连接建立后所有传送的报文段都必须把ACK置为1。PSH (Push):提示接收方尽快把数据交给应用程序不要在缓存里赖着。RST (Reset):连接出错要求复位重置连接。SYN (Synchronize):非常重要。用于发起一个新连接。我们在“三次握手”建立连接时主要看这个标志。FIN (Finish):结束连接。表示“我说完了我要挂电话了”。16位窗口大小接收方告诉发送方我现在还可以接收多少数据流量控制。如果接收方处理不过来窗口大小变小发送方就会减慢发送速度防止把接收方“撑死”。16位校验和用于校验数据在传输的过程中是否损坏接收方收到数据后会算一遍如果算出来的结果和这个值不一样说明数据出错了比如路上被干扰了这个包就会被丢弃。16位紧急指针只有当 URG 标志为 1 时才有效。它告诉系统紧急数据在哪里结束十大核心机制1.确认应答TCP可靠传输的核心机制但是在网络传输的过程中可能会出现 “先发后至” 的情况比如网络卡断了一下发送方发送了俩条信息我这边可能先收到发送方最后发来的那一条信息然后才收到发送方最早发送过来的信息这样信息的含义就可能会出现错误~~~此时TCP报文段首部格式中有32位序列号和32位确认序列号32位序列号针对传输的数据进行编号32位确认序列号给ACK报文使用关联当前这个ACK是应答哪个数据的32为确认序列号有俩种理解方式1.从1001之前的数据我已经接收到了2.对方正在想你索要1001之后的数据应答报文时一种特殊的报文通常没有载荷并且在报头的标志位中将ACK设置为1总结一下什么叫做可靠性什么是可靠性 -- 发送出去的信息发送方能知道接收方是否接收到了靠什么做到 --- 确认应答如何实现 --- 发送方发送数据给接收方接收方接收到数据并且返回一个应答报文可能出现的问题 --- 先发后至如何解决先发后至问题 --- 通过序列号和确认序列号解决2.超时重传在网络传输的过程中可能会出现丢包的概率情况是无法避免的当发送方发送一个数据但迟迟没有接收到接收方返回的ACK这时发送方可能会意识到可能是数据丢了所以会选择在发送一次数据但是如果是ACK丢包了那么也会导致发送方发送俩分同样的数据过来这时如果这俩份数据是扣款数据难道会扣款俩次吗不会的接收方知道我已经接收到的数据的序列号范围如果发现新收到的数据已经在序列号的范围内说明这个数据已经接受过了就会将重复的数据丢弃所以TCP不仅仅解决了可靠传输问题还解决了数据的传输顺序问题数据重复传输的问题但是超时重传的重传也并不是无限次数的重传如果连续传输多次都没有达到对方说明可能出现了非常严重的网络故障问题从而放弃对TCP的连接直接将对方保留的信息删除因为网络故障如果一直重传也没有任何意义没必要消耗大量的资源和时间~~~3.连接管理连接管理分为俩部分1.建立连接三次握手2.断开连接四次挥手这个核心机制我会单独出一篇文章讲讲滴~~~~4.滑动窗口提高效率引入滑动窗口是为了提高效率因为TCP为了确保可靠连接肯定多多少少会损失一定的效率滑动窗口的本质其实就是批量发送批量等待ACK窗口大小越大批量传输的数据越多整体的传输效率越高~~~当滑动窗口 “丢包” 该如何处理呢ACK丢失的情况就不需要做任何的处理因为ACK的确认序号后后一个ACK可以包含前一个但是如果是数据丢失那么服务器就会一直向客户端索要丢失的数据直到客户端反应过来然后重新发送丢失的数据服务器才停止索要要注意服务器是会记录哪些数据已经接收到了哪些数据是丢失的然后就会一直向客户端索要丢失了的那段数据这个机制称之为快速重传5.流量控制保证可靠性传输当滑动窗口传输的数据越大传输的效率也就越大如果窗口特别的大是否可以呢当然不行如果传输的特别快接收方可能就处理不过来就可能照成接收方丢包的情况流量控制就是针对滑动窗口的大小进行控制的~~~~​​​流量控制机制流量控制是根据接收方的处理能力来反向限制发送方的发送速度窗口大小1.如何衡量接收方的处理能力根据缓冲区剩余空间的大小如果缓冲区剩余空间还有很多那么发送方就可以将窗口大小调大反之就要将窗口大小调小2.衡量之后如何通知发送方对窗口大小做出限制呢把接收方缓冲区剩余空间大小的值通过ACK通知发送给发送方16位窗口大小就是填写缓冲区剩余空间大小的值发送方按照这个值确定下一轮窗口大小的值该多大如果缓冲区已经满了那么发送方就要停止发送但是如果暂停发送那么接收方就不会发送ACK了吗那发送方要如何直到什么时候可以继续发送数据了呢 ------- 发送方会时不时的发送一个窗口探测询问接收方我可以发送数据了吗接收方会根据缓冲区剩余空间大小给发送方返回一个ACK告诉接收方我缓冲区剩余空间还有多少如果为0那么就继续暂停发送如果为2000那就可以发送俩段数据过来~~~~窗口探测没有载荷只是为了触发ACK为了得到新的窗口大小的值6.拥塞控制提高效率拥塞控制和流量控制类似都是针对滑动窗口的大小进行限制流量控制是针对接收方缓冲区剩余空间大小做出限制拥塞控制是针对通信路径的处理能力做出限制因为通信路径中间的状况是非常复杂的数据都是一点点进行尝试相当于我们去当一个陌生的城市城市之间道路非常复杂我们想去一个地方只能一点点的尝试不断询问路人~~~拥塞控制的机制刚开始发送数据的时候按照一个比较小的速度发送数据比较小窗口如果数据可以送达并且没有丢包情况那么就加大速度加大窗口大小如果数据有丢包情况那么就减小速度减小窗口大小所以窗口的大下并不是一个固定值而是动态变化的窗口大小最终取决于流量控制和拥塞控制的较小值~~~~~拥塞控制变化规律图初始情况下是一个以非常小的窗口启动慢启动在不丢包的情况下指数增长每个轮次都会时窗口大小翻倍增长当窗口大小增长到了阈值就会从指数增长更改为线性增长如果增长的太快下一个轮次可能会直接丢包在线性增长的过程中如果发生丢包情况就立即缩小窗口大小缩小窗口大小有俩种方式1.老方式回到 “慢开始” 状态然后重新指数增长然后线性增长2.新方式回到阈值位置然后线性增长阈值 丢包时窗口大小 / 2 7.延时应答提升传输效率服务器并没有立即返回客户端发送的1-1000的ACK而是等到下一轮数据才给客户端返回2001的ACK此处的延时应答就可以给应用程序留更多的处理时间返回的ACK数目就可以减少在延时发送的这个时间段内应用程序处理的数据越多接下来发送的数据就越快~~~8.)捎带应答配合延时应答当客户端发送一个请求服务器在根据请求计算响应需要一定的时间如果计算的这段时间刚好遇上了延时应答就会顺便将ACK和响打包成一个数据包然后一起发送过去就好比四次挥手也可以是三次挥手如果刚好遇到延时应答就顺便将ACK和响应打包成一个数据包一并发送过去就变成了三次挥手~~~~9.面向字节流在面向字节流的过程中可能会出现粘包的现象的问题在传输过程中每个数据包都是单独分开的但是当数据发送到缓冲区的时候就会出现粘包情况当数据在缓冲区的时候此处在应用层上根本区分不出从哪到哪是一个完整的应用层数据包那么该如何解决粘包问题呢1.引入分隔符用特殊的符号作为包的开头和结束例如使用\n2.在数据开头的地方添加一个固定的属性说明数据包的长度10.异常情况1.进程崩溃和四次挥手是完全相同的通过socket.close触发~~~即使进程崩溃客户端没了但是TCP的连接还在操作系统内核中后续还是可以处理挥手的情况操作系统会自动对文件资源进行释放清理PCB的文件描述符表2.主机关机正常关机正常的关机需要一定的时间在这段时间里足够让客户端和服务器进行四次挥手的过程~~~3.主机关机掉电在这种特殊的情况下程序根本来不及进行四次挥手的操作1.如果是接收方掉电了就不会给发送方返回ACK那么发送方就会超时重传然后通过几次超时重传发送方还是接收不到接收方的ACK就会主动放弃链接2.如果是发送方掉电了接收方并不知道发送方咋回事接收方只能定期给发送方发送一个 “心跳包”这个心跳包不携带业务只是为了触发一次ACK如果发送方能返回ACK那么接收方就继续等待如果接收方发了心跳包没有接收到发送方返回的ACK此时接收方就主动断开连接~4.网线断开网线断开就是将主动关机的俩个机制结合起来接收方周期性发送心跳包这个心跳包不携带业务只为了触发一次ACK如果发送方没有给接收方返回ACK接收方就会主动断开连接~~~~发送方给接收方返回响应数据如果接收方迟迟没有返回ACK就会触发超时重传在几次重传过程中还是没有接收到接收方的ACK那么发送方就会主动放弃连接~~~