TCP八股

张开发
2026/4/13 21:41:52 15 分钟阅读

分享文章

TCP八股
文章目录TCPTCP连接如何确保可靠性确认应答序号与确认序号超时重传连接管理三次握手(建立连接)四次挥手(断开连接)滑动窗口快速重传流量控制拥塞控制TCP和UDP的区别UDP怎么实现可靠传输TCP连接三次握手的过程, 为什么是三次, 可以是两次或者更多吗?TCP连接四次挥手的过程, 为什么会是四次TCPTCP连接如何确保可靠性有一系列的机制来保证可靠性确认应答发送数据包后,回复ACK包,告诉对方确认收到序号与确认序号每个数据包都分配序号, 用来区分每个数据包和ACKACK带上确认序号, 表示这个序号之前的数据已收到根据序号乱序重排, 确保双发收发数据一致超时重传数据包可能丢失, 发送方发送数据包后等待ACK, 若一段时间没有等到, 就重传滑动窗口批量发送数据, 批量接收数据. 接收方按序号缓存数据, 收到的包先存起来, 等缺失包补齐之后再上交给应用层快速重传如果多次收到同一个确认序号的ACK, 立即重传该包, 无需等待超时流量控制接收方可以告知对方自己的处理能力, 调整窗口大小, 防止数据包被淹没拥塞控制根据网络拥堵状况, 动态调整窗口大小, 减小网络拥堵造成的影响确认应答是什么确认应答类似对话中的嗯, 点头, 没有实际的意义, 表示回应.在网络中就是接收方在收到TCP数据包后, 返回一个没有载荷, 只有报头的数据包回应, 表示确认收到为什么因为网络通信通常是乱序, 所以需要有办法识别和排序数据包, 因此需要引入序号和确认序号序号与确认序号序号是什么TCP是面向字节流的, 每一个字节都有自己的编号这些编号是连续的, 递增的TCP报头的序号就是TCP数据包载荷的第一个字节的编号确认序号是什么表示的是在这个字节之前的所有数据已经全部收到确认序号是应答报文(ACK)中的有效字段当且仅当ACK字段为1时才会生效具体含义是收到的最后一位1为什么上一个数据包和下一个之间可以无缝拼接的当接收方收到包之后可以根据序号排序, 确保收发一致超时重传是什么当接收方在一段时间内没有收到应答ACK报文时, 就会认为数据包已丢失, 重新发送数据包为什么丢包有两种, 一种是ACK丢了, 一种是数据包丢了发送方方没办法辨别统一重发数据包接收方有一个接收缓冲区如果收到重复的数据包, 直接丢弃即可连接管理三次握手(建立连接)握手是什么握手就是对话前的打招呼, 在网络中是只有报头的数据包, 没有载荷建立连接的过程发送方发送SYN请求建立连接接收方返回SYNACK同意建立连接发送方再返回ACK表示建立连接完成实际上是四次, 中间的SYN和ACK合并成了一次为什么验证链路是否通畅确认双方收发能力是否正常协商参数, 比如起始序号, 防止过期数据包影响发送四次挥手(断开连接)挥手是什么就是双方各自删除对方的信息, 彻底断开连接断开连接的过程主动方发送FIN报文请求断开连接被动方返回ACK, 确认收到断开请求被动方发送FIN, 表示自己也要断开主动方发送ACK, 表示断开成功为什么不能合并因为三次握手ACK和SYN都是由内核自动处理的, 时机一致, 可以合并四次挥手中的ACK是内核处理的, FIN是由应用层触发的(比如调用close()方法), 时机不一定一致, 所以不能合并滑动窗口是什么滑动动窗口就是批量发送数据的一种形式为什么没有滑动窗口, 就是一发一答, 比较低效有滑动窗口, 就是发送一批数据, 等待一批ACK, 把多次等待ACK的时间合并成一份, 所以更高效过程假设一组数据 1-1001-2001-3001-4001-5001滑动窗口为1-4000, 大小为4000, 表示的含义是 发送1-4000的数据, 接收1-4000的ACK当收到1001的ACK时, 就立即发送4001的数据包, 窗口为1001-5000, 窗口大小不变, 窗口右移丢包如何应对滑动窗口的前提是可靠性丢包分为两种, ACK丢包和数据包丢包ACK丢包不用处理, 因为ACK的含义是到这个字节前的数据已全部收到下一个ACK的含义可以涵盖上一个因为是等待一批ACK, 会丢失一部分, 不可能全丢后面的ACK可以弥补前面的丢失, 无需重传数据包丢了假设发送1数据包, 返回ACK1001发送1001数据包, 丢包发送2001数据包, 由于没有1001-2000, 返回的ACK仍然是1001发送3001数据包, 返回的ACK还是1001这时连续三次返回ACK1001, 发送方意识到1001包丢了立刻重传1001当接收方收到1001包后, 补齐了1-4000的缺口, 返回ACK4001表示下一个从4001开始发快速重传这就是快速重传机制, 是搭配滑动窗口用的快速识别哪个数据包丢失, 针对性的重传流量控制是什么流量控制是限制发送方的发送速度, 根据接收缓冲区大小来动态调整窗口大小为什么因为通信是双方的事, 发送方发送的快了, 接收方要有能力处理具体原理接收方有一个接收缓冲区, 这个缓冲区类似阻塞队列, 生产消费者模型如果发送方发送特别快, 接收方处理的慢, 缓冲区就会满, 如果再强行发送数据, 就会导致丢包这就需要根据接收方的处理速度来制约发送方的发送速度缓冲区空闲空间小, 接收方处理能力弱, 减小窗口, 限制发送方发送缓冲区空闲空间大, 接收方处理能力强, 增大窗口, 允许发送方多发送TCP中的反馈机制接收方在接收到数据后, 会把缓冲区大小, 通过ACK反馈给发送方当ACK标志位1时, 窗口大小字段才有效缓冲区满了该怎么办当缓冲区满了, 窗口大小0, 双方停止发送, 陷入等待发送方会定期发送窗口探测包, 触发ACK反馈, 询问窗口大小接收方在处理了一些数据后, 窗口变大, 会主动发送窗口更新通知数据包, 让发送方恢复发送拥塞控制是什么也是限制发送方发送速度, 是从传输链路的视角来看的基本思想把传输链路的中间节点(比如路由器, 交换机)视为一个整体, 不关注内部细节, 通过动态调整窗口大小来找到合适的发送速度窗口变化过程初始阶段:慢启动刚开始拥塞窗口很小,发送的速度很慢, 因为网络拥堵情况未知, 先小心试探指数增长:没有丢包, 说明网络通畅, 窗口指数增长, 以比较短的时间增长到较大的窗口线性增长:当窗口增长到一个阈值后, 即使没有丢包, 也会停止指数增长, 变为线性增长, 防止增长太快导致突然拥堵出现丢包:减速和窗口调整当出现丢包时, 说明网络拥堵, 此时减小窗口大小, 减慢发送速度窗口变为新的阈值, 然后线性增长(不再指数增长)TCP和UDP的区别UDP是无连接, 不可靠, 面向数据报, 半双工TCP是有连接, 可靠, 面向数据流, 全双工连接TCP连接会保存对端信息UDP不会可靠性TCP有一系列机制来保证可靠性UDP不管发出去的数据是否会顺利达到面向数据流/报TCP是面向字节流的, 和文件流一个特点UDP一次发送或接收一个完整的UPD数据报双工TCP是全双工的, 一个通信链路, 既能发送也能接收数据UDP是半双工的, 一个通信链路, 只能发送或接收UDP怎么实现可靠传输UDP不属于连接型协议, 因而具有资源消耗小, 处理速度快的优点传输层无法保证数据的可靠传输, 只能通过应用层来实现了实现时参照TCP的机制, 在UDP数据报载荷定义一个头部, 包含一些需要的字段确认应答首先增加一个确认应答的机制,在发送数据包之后, 接收方需要返回一个ACK数据包, 来表示确认收到因为网络通信通常是乱序的, 所以需要有办法识别和排序数据包, 因此需要引入序号和确认序号序号和确认序号需要用序号和确认序号来区分每个数据包和ACK首先要把发送的数据每一个字节都编一个号, 这些编号是连续的, 递增的序号就是载荷的第一个字节的编号确认序号是应答报文的有效字段, 当ACK为1时才会生效, 具体含义是收到的最后一位1上一个数据包和下一个数据包可以根据序号无缝拼接当接收方收到包之后可以根据序号排序, 确保收发一致超时重传就是在一段时间内没有收到应答报文时, 就会认为数据包已丢失, 重新发送数据包重传的时间不固定, 第一次的时间为t1, t1t2这样设计的原因是, 如果第一次重传没有成功吗说明当前的网络状况可能较差, 需要更长的等待时间TCP连接三次握手的过程, 为什么是三次, 可以是两次或者更多吗?三次握手的过程:发送方发送SYN请求建立连接接收方返回SYNACK同意建立连接发送方再返回ACK表示建立连接完成实际上是四次, 中间的SYN和ACK合并成了一次三次是确认双方收发能力是否正常的最少次数假如是两次接收方无法确认发送方是否真的想建立连接如果发送方的SYN是延迟的旧包接收方会错误地建立连接并分配资源多次理论上可以, 但不需要, 因为不能提供更多有效信息, 还会增加开销三次就足够确认双方收发能力正常TCP连接四次挥手的过程, 为什么会是四次挥手就是双方各自删除对方的信息, 彻底断开连接过程:主动方发送FIN报文请求断开连接被动方返回ACK, 确认收到断开请求被动方发送FIN, 表示自己也要断开主动方发送ACK, 表示断开成功中间的两次不能合并因为三次握手的ACK和SYN都是由内核自动处理的, 时机一致, 可以合并四次挥手中的ACK是内核处理的, FIN是由应用层触发的(比如调用close()方法), 时机不一定一致, 所以不能合并如果是强行合并成三次被动方收到FIN后必须立即关闭正在传输的文件数据会丢失无法保证数据传输的完整性

更多文章