type
Post
status
Published
date
Apr 7, 2025
slug
summary
tags
面试
网络
硕士
category
技术
icon
password
tcp如何保证可靠
TCP通过握手挥手建立连接、校验和、序列号确认、滑动窗口、动态重传及拥塞控制等机制，在不可靠的IP层上实现了端到端的可靠传输。其设计平衡了效率与安全性，例如通过SACK减少重传冗余、通过拥塞控制适应网络波动。实际应用中需注意半包/粘包问题（需应用层定义消息边界）及校验和的局限性（无法完全检测多比特错误）
如何用UDP实现可靠传输/QUIC
在应用层实现序列号和确认应答机制，就是为每个数据包添加递增序列号，接收方通过ack报文确认已接受的数据包。并且超时未确认则重传。通过滑动窗口机制避免乱序。这相当于把tcp在应用层又实现了一遍。
但是也可以采用类似QUIC的设计。quic的头部分为长头部和短头部，只有在建立连接的时候使用长头部，连接建立后使用短头部。从而降低连接开销。
quic采用动态协商的连接ID标识连接，而不是五元组（源、目的IP；源目的端口；协议）表示。这样能够支持无缝切换网络，并且不易被追踪。
quic采用严格递增的序列号，因此重传的序列号也不一样。避免出现TCP中的ACK歧义问题（第一次响请求的ACK在网络中堵塞，重传后又发了ACK，无法知道这两个ACK哪一个是重传的，从而不能准确计算RTT）。并且可以支持乱序确认，因为TCP丢包会导致窗口不滑动，而quic中的序列号是严格递增的，可以通过更大的序列号确认后续重发的包。
之所以支持乱序确认，是因为数据包内容的顺序不是依赖packet number，而是依赖stream id和stream offset表示的。数据接收方根据stream id将数据归类，再根据stream offset重新排序。
流量控制方面，quic对每个流限制了最大偏移量，防止一个流数据量过大耗尽缓冲区。quic对所有的流的总数据量也有限制，避免整体资源超出限制。根据RTT时间和缓冲区的处理速率动态调整每个流的最大偏移量和所有流的总数据量。
拥塞控制和TCP差不多，但是可以根据不同应用选择不同拥塞控制算法，而TCP只能用同一套拥塞控制算法。
队头阻塞问题
有哪些拥塞控制算法
经典的有慢启动、拥塞避免、拥塞发生、快恢复。这是reno算法
还有更多的，但是这里看不完了。
三次握手的过程
三次握手的过程是1. 服务器监听某个端口2.客户端发送第一次握手报文，包括随机初始化序列号、SYN标志并进入syn sent状态3.客户端返回第二次握手syn ack，是对第一次握手的确认，包括确认应答号是第一次握手的序列号+1，随机初始化序列号，SYN和ACK标志并进入syn rcvd状态3. 客户端返回第三次握手报文，包括确认应答号是序列号+1，而且可以携带数据包。进入established状态，4. 服务器收到第三次回收进入established状态
注意序列号代表报文第一个字节的编号，下一个序列号是上一个序列号+上一个报文长度。确认应答号是期望收到的字节编号。例如上一个请求序列号是1，长度1000，则成功收到的确认应答号是1001，下一个报文序列号是1001。
每一次握手丢失会怎么样
首先，tcp有超时重传机制，如果迟迟收不到应答会重发请求或者响应。重发次数可以设置，每一次重发间隔是指数增长的。不过，第一次握手、第二次握手、普通报文和挥手阶段重传的参数是不一样的。
如果第一次握手丢失，会导致一直收不到ack应答，导致触发重传。一直收不到应答则最终建立连接失败。
如果第二次握手丢失，会导致服务端收不到第三次握手，服务端会重传ACK。此外客户端会认为是第一次握手丢失，所以会各自重传第一次握手。注意，如果客户端重传第一次握手后收到迟到的ACK响应，会与当前期望的ack不匹配，认为是旧连接，从而丢弃迟到的ack报文。如果重传次数耗尽，就会关闭连接。
如果第三次握手丢失，服务器会以为第二次握手丢失从而重传第二次握手，客户端根据重传的第二次握手重新发送第三次握手，但是客户端不会主动重传第三次握手。
什么是syn flood 攻击，有什么危害，如何解决
如果攻击者伪造不同ip大量发起第一次握手而不发送第三次握手，就会导致服务器处于大量syn rcvd状态，从而占用服务器的系统资源。
处于syn rcvd的连接放在服务器的半连接队列中，半连接队列过多会导致无法为新连接分配资源，导致服务器无法响应正常请求。
可以增大半连接队列、减少第二次握手的重传次数以快速释放无效连接，或者启用syn cookie技术，就是服务器收到第一次握手后不为连接分配资源，而是再响应报文中嵌入一个cookie值，客户端返回携带正确cookie的第三次握手才会为连接分配资源。
什么是半连接队列和全连接队列
半连接队列是服务端收到第一次握手后，处于syn rcvd状态的连接队列，全连接队列是服务端收到第三次握手后处于established状态的连接队列。
半连接队列用于临时存放未完成握手的连接请求，全连接队列用于缓存已经建立但是来不及被处理的连接。
半连接队列采用哈希表存储，为了收到第三次握手后快速根据tcp四元组定位特定连接。全连接队列使用链表存储，只需要先进先出取出队列头部即可。
四次挥手的过程
连接双方都可以主动关闭连接，1.主动关闭放发送第一次挥手，就是设置FIN位的报文，表示主动关闭方不再发送数据但是可以接收数据，进入fin wait 1状态2.被动关闭方发送第二次握手，就是一个ack报文，表示知道关闭请求，但是自己可能还有数据要发送，可以接着发送数据。如果没有数据发送也可以将第三次挥手合并到第二次挥手一起发送。第二次挥手发送后被动关闭放进入close wait状态。3.被动关闭方没有数据要发送了，则发送携带FIN标志位的第三次挥手并进入last ack状态4.主动关闭方收到第三次挥手并发送ack报文，进入time wait状态5. 被动关闭方收到第四次挥手进入closed状态。
每一次挥手丢失会怎么样
第一次挥手丢失，会导致主动关闭方收不到ack响应，重发第一次挥手。超过最大重传次数后就强制断开连接
第二次挥手丢失，主动关闭方会认为第一次挥手丢失，从而重传第一次挥手，被动关闭方收到重发的第一次挥手，就再发第二次挥手。
主动关闭方收到第二次挥手后进入fin wait2状态，如果主动关闭方用close关闭，则代表不再收发数据，因此close wait会有超时时间，如果超时时间内未收到第三次挥手则直接关闭连接。如果是shutdown关闭连接则是不发，但是可以收，因此主动关闭方可以一直处于finwait2.
第三次挥手丢失则收不到ack，被动关闭方会重发第三次挥手。和第一次挥手相似。
第四次挥手丢失，则被动发送方认为第三次挥手丢失，则重发第三次挥手。
time wait和close wait过多的原因，怎么解决
time wait是四次挥手结束后，主动发起关闭的一方进入的状态。作用是1. 防止旧连接干扰，吸收网络中残留的数据包，避免影响后续新建的同端口连接（序列号虽然随机但是可以回绕，如果序列号刚好符合下一个同端口连接则会导致数据错乱）2.如果最后一次ACK丢失则另一方会重发FIN，这时可以重发ACK避免异常关闭连接，持续2MSL，认为数据包全部死亡。
time wait过多说明连接频繁断开，可能是因为频繁使用短连接、或者大量客户端建立连接后不发送数据导致长连接超时、或者http长连接请求的数量达到上限（每个长连接只能处理上限次请求就要关闭）。
timewait过多会导致占用系统资源和端口资源。占用系统资源指会占用文件描述符、内存和CPU。占用端口资源是指timewait时无法对相同IP相同端口发起连接。对于客户端来说，端口资源有限，占满会导致新连接报错。对于服务端，虽然监听单一端口，但是可以处理不同客户端，只是不能和刚才这个客户端马上建立连接。但是都会占用系统资源。
解决timewait过多可以开启长连接代替短连接、排查是否有网络问题导致大量连接超时、允许复用timewait窗口（开启tcp_te_reuse和tcp_timestamp，通过引入时间戳区分新旧数据包）、调高长连接请求上限。
close wait是被动关闭方发送第二次挥手ACK后进入的状态，该状态允许被动关闭方继续发送数据。
close wait过多的原因是被动关闭方可能由于代码缺陷没有正确关闭连接。
close wait过多会导致占用系统资源（文件描述符、内存等）、占用端口。
如果暂时close wait过多可以重启服务强制释放连接。但是根本在于排查代码的缺陷，需要正确关闭连接。
close和shutdown关闭
close是关闭socket的文件描述符，并减少引用计数，当引用计数减为0就会真正释放资源并出发4次挥手。close会完全关闭双向通信，无法会通过套接字进行读或写操作
shutdown是关闭指定方向的通信，而不是减少引用计数。
close会立即发送fin包，可能丢弃缓冲区的未发送数据，导致数据丢失。如果接收缓冲区有未读数据则会发rst而不是fin。shutdown会等待缓冲区处理完毕再发fin。
主动调用close后，直接进入timewait，只有3次挥手，调用shutdown有4次
什么时候会用rst报文
- 目标端口未开放，则服务器直接回复rst拒绝连接
- 重复syn报文，例如一个syn报文在网络阻塞，然后重传新的syn并且建立了连接，就会返回rst终止无效请求
- 连接一方因为异常终止连接，又重启，收到对方继续发的数据就会返回rst
- 接收到数据包序列号不在滑动窗口范围内，或者数据包校验错误，会发rst
- 尝试连接timewait状态的服务器会rst
- 接收方缓冲区溢出，处理不过来
- tcp保活机制检测长时间无活动
Linux查看已连接socket、端口的命令
ss命令可以看，参数-a是所有，-t是tcp，-u是udp，-l是监听端口，-p是展示进程信息
netstat可以看，参数一样，但是性能没有ss好
TCP和UDP区别
tcp是面向连接的有序可靠传输，udp是无连接的不可靠传输。
tcp需要复杂的重传和建立释放连接开销，头部大。udp传输效率高但是可能丢失，头部小。
tcp适合文件传输、网页浏览等需要可靠性的场景，udp适合实时性高，如视频通话等场景。
在电梯间内网络不稳定，如何解决音视频信号传输卡顿
可以动态调整码率，减少传输数据量。
采用quic协议，首次握手时间仅需1rtt，后续可以0rtt握手。并且支持多路复用，允许并行传输数据流，支持前向纠错，发送冗余数据包，可以减少重传次数。并且切换网络可以保持连接不中断，避免重建连接。最后内置tls加密，不需要专门加密握手。
因为弱网条件丢包率高容易卡顿，需要通过quic改善可靠性。
TCP拥塞控制过程
TCP拥塞控制的主要过程可以简化为以下几个阶段：
慢启动（Slow Start）TCP连接建立后，拥塞窗口（cwnd）初始化为1个MSS（最大报文段长度）。 每收到一个ACK确认，cwnd增加1个MSS，因此cwnd呈指数增长。 当cwnd达到慢启动阈值（ssthresh）时，进入拥塞避免阶段
拥塞避免（Congestion Avoidance）在拥塞避免阶段，cwnd每经过一个RTT（往返时间）增加1个MSS，呈线性增长。 目的是避免cwnd增长过快导致网络拥塞
拥塞发生（Congestion Detection）如果发生超时，TCP认为网络拥塞严重，将ssthresh设置为cwnd的一半，cwnd重置为1，重新进入慢启动阶段。 如果收到3个重复ACK（快速重传），TCP认为发生部分丢包，进入快速恢复阶段
快速恢复（Fast Recovery）在快速恢复阶段，ssthresh设置为cwnd的一半，cwnd减半并加上3个MSS，然后进入拥塞避免阶段。 目的是在部分丢包的情况下快速恢复传输效率
总结：TCP拥塞控制通过慢启动、拥塞避免、拥塞发生和快速恢复四个阶段动态调整发送速率，避免网络拥塞并提高传输效率
两个进程可以用同一个端口吗
如果是不同协议，如一个是TCP，一个是UDP，则各自端口空间独立，可以重用。
如果是同一协议，但是不是同一IP，也可以重用。因为可以配置多个网卡，转发到不同应用。
内核通过四元组表示连接，如果四元组相同，默认不能显式绑定同一IP地址的同一端口。
如果开启SO_REUSEADDR选项，则可以复用timewait状态的端口。或者开启tcp_tw_reuse和tcp时间戳，也可以重用time wait状态的端口
如果开启SO_REUSEPORT选项，则可以多个进程绑定同一个IP和端口。绑定同样IP和端口的连接放到一条哈希冲突链上，
socket怎么重用连接
为了避免频繁创建和销毁socket，可以使用socket连接池。原理是预创建多个socket，需要用到连接时取出，用完归还。
初始化时创建一组socket放入池中，避免后面请求时同步的三次握手建立连接。需要使用连接时从池中获取空闲连接，用完后归还到池中而不是关闭。从而允许下次再用。
需要定期检查连接的有效性，发送心跳包探测连接是否断开。
连接池可以动态扩展和收缩，根据当前负载和资源消耗。
空闲连接超时后需要释放，避免资源泄漏。
一条TCP连接上可以发多少个http请求
短连接模式下，每个http请求结束后会立即释放tcp连接。
长连接模式下，多个http请求可以复用一条tcp连接。理论上只要tcp存在，则可以发的http请求没有上限，但是服务端会限制单个tcp连接处理的http请求次数，这个参数可以调整。
socket连接中，如果客户端在read()的时候服务器挂掉，会怎么做？客户端有感知吗
- 如果是服务器进程崩溃了，则内核会回收其socket资源，并发送FIN报文，触发四次挥手。客户端的read会立刻返回0，表示对方已经关闭连接，所以客户端有感知
- 如果服务器宕机， a. 如果开启了tcp保活机制，则一段时间后会发送探测报文，探测报文多次无响应会断开连接 b. 如果没有开启则会一直阻塞，直到客户端下一次给服务器发送报文得不到响应，并且超时重传也得不到响应才会断开