TCP篇
基本认知
TCP和UDP的区别?
TCP 和 UDP 可以使用同一个端口吗?
可以的
传输层中 TCP 和 UDP在内核中是两个完全独立的软件模块。可以根据协议字段来选择不同的模块来处理。
TCP 连接建立
TCP 三次握手过程是怎样的?
- 一次握手:客户端发送带有 SYN=1同步标志和SEQ序号=x 的数据包 -> 服务端,该报文不包含应用层数据,然后客户端进入 SYN_SENT 状态,等待服务端的确认;
- 二次握手:服务端发送带有 SYN=1和ACK=1的标志位以及确认应答号x+1+自己的序号y 的数据包 –> 客户端,该报文也不包含应用层数据,然后服务端进入 SYN_RECD 状态;
- 三次握手:客户端发送带有 ACK=1的标志位和确认应答号ACK=y+1的数据包 –> 服务端,这次报文可以携带客户到服务端的数据,然后客户端和服务端都进入ESTABLISHED 状态,完成 TCP 三次握手。
为什么是三次握手?不是两次、四次?
- 三次握手才可以阻止重复历史连接的初始化(主要原因)
如果第一次握手的时候,客户端宕机了,而且这个 SYN 报文还被网络阻塞了,服务端并没有收到,接着客户端重启后,又重新向服务端建立连接,这时候如果旧的连接比新的连接先到达,如果是两次握手,就会直接建立了连接,浪费了资源。只有在服务器发送了ack客户端新连接发现不是自己想要的时候才会去终止旧连接。而如果是三次握手,服务器还会有一个ack确认的过程,新的握手发现不是自己想要的ack确认号就会去终止旧的握手信号,在连接之前就能终止。
- 三次握手才可以保证双方的通信的可靠
由于要保证发出去的消息并且收到确认,所以要一来一回,因为服务器的确认和发序号合在了一起,所以只需要三次握手就可以,而不是四次。
- 三次握手才可以避免资源浪费
为什么每次建立 TCP 连接时,初始化的序列号都要求不一样呢?
- 为了防止历史报文被下一个相同四元组的连接接收(主要方面);
即如果有历史报文没发送出去,初始化序列号还是和之前一样,就有可能导致历史数据刚好落在服务器接受窗口范围内被接受。
- 为了安全性,防止黑客伪造的相同序列号的 TCP 报文被对方接收;
第一次握手丢失了,会发生什么?
会超时重传,而且重传的 SYN 报文的序列号都是一样的,重传的次数可以设置,超时的时候每次是之前的二倍。达到最大重传次数后,再等待一段时间(时间为上一次超时时间的 2 倍),客户端则会断开连接。
第二次握手丢失了,会发生什么?
客户端迟迟没有收到确认,就会触发超时重传机制,重传 SYN 报文。
服务端这边由于发送了SYN标志的报文,但是没有没法出去,会触发超时重传机制,重传 SYN-ACK 报文。
第三次握手丢失了,会发生什么?
由于服务器一直收不到客户端发送的ACK确认号,所以会超时重传,达到最大重传次数后会断开连接。
TCP断开连接
TCP 四次挥手过程是怎样的?
在断开TCP连接时,需要通过四次挥手来断开,过程是:
(1)客户端向服务端发送FIN=1和序列号SEQ=x的数据包,用来关闭客户端到服务端的数据传送。然后客户端进入 FIN-WAIT-1 状态。
(2)服务端接收FIN后,向客户端发送ACK(ACK=x+1),表示我接收到了断开连接的请求,客户端可以不发数据了,不过服务端这边可能还有数据正在处理。这时候然后服务端进入 CLOSE-WAIT 状态,客户端收到ACK确认号后进入 FIN-WAIT-2 状态。
(3)服务端处理完所有数据后,向客户端发送FIN=1和序列号SEQ=y的数据包,表示服务端现在可以断开连接,然后服务端进入 LAST-ACK 状态。
(4)客户端接收到服务端的FIN,向服务端发送ACK(ACK=y+1),表示客户端也会断开连接。客户端进入TIME-WAIT状态,服务端在收到 ACK (ACK=y+1)标志的数据包后进入 CLOSE 状态。此时如果客户端等待 2MSL 后依然没有收到回复,就证明服务端已正常关闭,随后客户端也进入CLOSE状态。
为什么挥手需要四次?
第一次挥手丢失了,会发生什么?
如果第一次挥手丢失了,那么客户端迟迟收不到被动方的 ACK 的话会超时重传,重传的次数可以设置,超时的时间每次是之前的二倍。达到最大重传次数后,再等待一段时间(时间为上一次超时时间的 2 倍),客户端则会断开连接。
第二次挥手丢失了,会发生什么?
第三次挥手丢失了,会发生什么?
和上面一样,服务端第三次挥手发送FIN数据包,如果丢失,也是会超时重传,超过最大重传次数后,再等待一段时间后断开连接。
而客户端由于是通过 close 函数关闭连接的,处于 FIN_WAIT_2 状态是有时长限制的,如果在tcp_fin_timeout 时间内还是没能收到服务端的第三次挥手(FIN 报文),客户端就会断开连接。
第四次挥手丢失了,会发生什么?
由于第四次挥手是发送ACK确认好,不会重传,所以第四次挥手丢失了,服务器会超时重传FIN的报文。客户端在重新收到这个FIN报文后,就会重置这个2MSL的等待时间。
为什么 TIME_WAIT 等待的时间是 2MSL?
也就是说MSL是报文最大的生存时间
因为2MSL可以保证在2MSL内,如果客户端发送的ACK确认报文丢失,服务端超时重发FIN能够被客户端接受到,这样一来一回刚好两个MSL。
为什么需要 TIME_WAIT 状态?
1、防止历史连接中的数据,被后面相同四元组的连接错误的接收
2、保证「被动关闭连接」的一方,能被正确的关闭
TIME-WAIT 作用是等待足够的时间以确保最后的 ACK 能让被动关闭方接收,从而帮助其正常关闭。即:如果主动关闭连接的一方没有这个等待时间而直接关闭,当它的ACK丢失的时候,被动关闭方就不能被正确关闭,有这个等待时间,就会在等待时间内查看是否FIN会超时重发。
TIME_WAIT 过多有什么危害?
服务器出现大量 TIME_WAIT 状态的原因有哪些?
1、不管是客户端还是服务器端关闭了长连接机制,都会导致服务器使用完一次HTTP后,主动断开连接。
服务器出现大量 CLOSE_WAIT 状态的原因有哪些?
如果已经建立了连接,但是客户端突然出现故障了怎么办?
如果已经建立了连接,但是服务端的进程崩溃会发生什么?
拔掉网线后,原本的TCP连接还存在吗?
Socket 编程
针对 TCP 应该如何 Socket 编程?
即:
第一次握手,Connect主动打开,发起连接请求
第二次握手,服务端accept阻塞,connect返回成功
第三次握手,accept返回成功
没有 accept,能建立 TCP 连接吗?
没有 listen,能建立 TCP 连接吗?
为什么可以?
半连接队列和全连接队列保存TCP三次握手时的连接的信息,但是半连接队列和全连接队列都是在执行 listen 方法时,内核自动创建的。
如果没有listen,就没有半连接队列和全连接队列保存TCP的连接信息,但内核还有个全局 hash 表,可以用于存放 sock 连接的信息,因此客户端和客户端之间如果没有listen也是可以进行TCP连接的。
相似的问题:
服务端没有 listen,客户端发起连接建立,会发生什么?
服务端如果只 bind 了 IP 地址和端口,而没有调用 listen 的话,由于没有listen,就没有半连接队列和全连接队列保存TCP的连接信息,就无法找到相应的socket,客户端对服务端发起了连接建立,服务端会回 RST 报文,连接失败。
TCP 重传、滑动窗口、流量控制、拥塞控制
TCP的可靠性怎么保证的?
TCP 是通过序列号、确认应答、重传机制、连接管理以及滑动窗口控制等机制实现可靠性传输的。
重传机制
超时重传
<font style="color:rgb(71, 101, 130);">RTT</font>
指的是数据发送时刻到接收到确认的时刻的差值,也就是包的往返时间。
超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。
快速重传
SACK 方法
Duplicate SACK
Duplicate SACK 又称 <font style="color:rgb(71, 101, 130);">D-SACK</font>
,其主要使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。
滑动窗口
流量控制
拥塞控制
慢启动
拥塞避免算法
拥塞发生
拥塞发生的情况:
1、超时重传:重传计时器超时才会重传
2、快速重传:收到三次同一个数据包的ACK,就会立即重传,不必等到计时器超时
即快恢复:
课本: