计算机网络——TCP篇

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，就会立即重传，不必等到计时器超时

即快恢复：

课本：

快速恢复？？和课本不一样