计算机网络—

计算机网络——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状态。