《他强由他强，清风拂山岗；他横由他横，明月照大江》之一

基础篇

网络基础

1、TCP三次握手

握手过程
第一次握手（SYN）
客户端发送一个SYN（同步序列编号）数据包到服务器以初始化一个连接。
在这个数据包中，客户端会设置一个随机的初始序列号（Sequence Number, 简称Seq），这个序列号用于同步会话并确保数据按顺序传输。
第二次握手（SYN-ACK）
服务器收到客户端的SYN请求后，会回应一个SYN-ACK（同步和确认）数据包。
服务器的SYN-ACK数据包中会包含服务器自己的一个随机序列号，并且还会对客户端的初始序列号进行确认（ACK），即客户端序列号的值加1（Seq+1）。
第三次握手（ACK）
客户端收到服务器的SYN-ACK响应后，发送一个ACK（确认）数据包。
这个ACK数据包确认了服务器的初始序列号，即服务器序列号的值加1。这样，每一方都知道对方已经准备好进行数据传输。
完成这三步握手后，TCP连接就建立起来了，客户端和服务器开始传输数据。这个过程确保了：
双方都知道对方的存在。
序列号被同步，确保了数据可以按顺序、可靠地传输。
这种方法是非常重要的，因为它可以防止旧的重复连接初始化数据干扰新的连接，这种情况在网络延迟较大的情况下可能发生。同时，三次握手还可以防止客户端错误地初始化未准备好通信的服务器。
四次挥手
第一次挥手
客户端发送一个FIN（结束）数据包给服务器来表示客户端已经没有数据要发送了，即客户端请求关闭向服务器的数据传输。
第二次挥手
服务器收到这个FIN数据包后，发送一个ACK（确认）数据包作为回应。
这个ACK数据包只是确认了已接收到客户端的终止请求，并不意味着服务器已经准备好关闭连接。
第三次挥手
服务器继续发送剩余的数据给客户端。一旦服务器也没有数据要发送，那么它将发送自己的FIN数据包给客户端来表示服务器端也已经没有数据要发送了。
第四次挥手
客户端收到服务器的FIN数据包后，将发送一个ACK数据包作为回应，确认服务器端的关闭请求。
客户端会等待足够长的时间（称为2MSL，Maximum Segment Lifetime，最大段生存时间）以确保服务器收到了其ACK数据包。在这段等待时间结束后，客户端关闭连接。
完成这四步挥手后，TCP连接被完全关闭，双方都不再发送数据。

四次挥手的过程比三次握手复杂，因为当发送方发送FIN请求关闭连接时，接收方可能仍有数据要发送。接收方必须处理完这些剩余数据，然后才能发送自己的FIN数据包。这意味着断开连接的双方都可以独立地关闭它们的发送操作，而不必同时关闭接收操作，从而实现了TCP连接的优雅关闭。
CLOSE-WAIT
当一个TCP连接的一方（通常是服务器）接收到对方（客户端）发送的FIN报文，表明对方想要关闭连接时，该方会发送一个ACK报文作为应答，并进入CLOSE-WAIT状态。
这时，接收FIN报文的一方应该通知应用层准备关闭连接。应用程序在完成所有数据发送之后，需要执行关闭操作来发送FIN报文给对方。
CLOSE-WAIT状态表示正在等待本地应用程序（服务器端）关闭连接。
TIME-WAIT
当TCP连接的主动关闭方（通常是客户端）发送完自己的FIN报文并接收到对方的ACK报文后，会进入TIME-WAIT状态。
TIME-WAIT状态持续的时间是2MSL（Maximum Segment Lifetime，最大报文段生存时间）。该时间足够保证对方能够接收到最后一次发送的ACK报文。
之所以需要TIME-WAIT状态，是为了确保TCP连接可靠终止，并处理可能出现的迟到的报文（如重新发送的FIN报文）。
查看TIME-WAIT状态的连接数量
在Unix/Linux系统中，可以使用netstat命令来查看TIME-WAIT状态的连接数量：

netstat -an | grep TIME_WAIT | wc -l

这条命令会列出所有状态为TIME-WAIT的连接，并通过wc -l计算数量。

TIME-WAIT过多的可能原因和解决方法
TIME-WAIT状态过多可能是因为服务器处理了大量的短暂连接，每个连接在关闭时都要经历TIME-WAIT状态。这种情况在高并发的Web服务器或API服务器上较为常见。如若不进行适当的配置，过多的TIME-WAIT连接可能会耗尽服务器的可用端口。

解决方法可能包括：

优化应用设计：使用长连接（如HTTP的Keep-Alive）而不是短连接，减少连接的频繁建立和关闭。

调整系统参数：

在Linux系统中，可以调整/proc/sys/net/ipv4/tcp_tw_reuse和/proc/sys/net/ipv4/tcp_tw_recycle参数来改变TIME-WAIT连接的处理方式。
还可以调整/proc/sys/net/ipv4/tcp_fin_timeout来减少TIME-WAIT状态的持续时间。
使用负载均衡：将流量分散到多个服务器上，减少单个服务器上的连接数。

设置逆向代理：使用逆向代理服务器（如Nginx）来管理连接并减少应用服务器的负载。

在调整系统参数时，需要谨慎操作，因为不当的设置可能会违反TCP协议的规范，导致连接问题或安全问题。通常情况下，优化应用设计和使用负载均衡是更为推荐的做法。

2、常见网络服务分层

应用层：HTTP、SMTP、DNS、FTP
​传输层：TCP 、UDP
​网络层：ICMP 、IP、路由器、防火墙
​数据链路层：网卡、网桥、交换机
​物理层：中继器、集线器

3、TCP和UDP区别和使用场景

TCP（传输控制协议）
连接导向：在数据传输之前，TCP会建立一个连接，通过三次握手过程确保连接的可靠性。
可靠性：TCP提供了可靠的数据传输，确保数据无差错、不丢失、不重复，并且按序到达。
流控制：TCP使用滑动窗口协议进行流量控制。
拥塞控制：TCP有拥塞控制机制，可以避免网络中的过度拥堵。
双向字节流：TCP提供双向数据传输的字节流服务，不保留边界。
适用场景：适用于要求高可靠性的场景，如网页浏览、文件传输、电子邮件、数据库操作等。
UDP（用户数据报协议）
无连接：UDP是无连接的，发送数据之前不需要建立连接。
尽力而为：UDP尽最大努力交付数据，但不保证可靠性。数据可能丢失或顺序错乱。
无流控制和拥塞控制：没有流量控制和拥塞控制功能，因此可能导致网络拥塞。
数据报文：UDP以数据报文的形式发送信息，保留了消息的边界。
适用场景：适用于对实时性要求高、可以容忍一定丢包的场景，如音视频通信、在线游戏、实时广播、DNS查询等。
总结
TCP提供可靠的、面向连接的传输服务，适合于那些需要确保数据完整性和顺序性的应用。它通过一系列复杂的协议机制（如错误检测、确认重传、流量控制和拥塞控制）来保证这一点。
UDP则提供简单的、不可靠的、无连接的数据传输服务，适合于那些对实时性要求高、对数据丢失不敏感的应用。UDP由于其低延迟和较小的协议开销，常用于那些对网络质量要求不太高的场景。
选择TCP或UDP通常取决于应用程序对数据传输的具体需求。一些应用可能还会结合使用TCP和UDP来利用各自的优势。

4、TCP滑动窗口和拥塞控制

TCP滑动窗口和拥塞控制是TCP协议中用于流量控制和网络拥塞避免的两种关键机制。

TCP滑动窗口（Flow Control）
滑动窗口是TCP协议中用于实现流量控制的一种机制。它确保发送方不会因发送过多的数据而淹没接收方。接收方根据自身的缓冲区大小来通知发送方当前能够接受的最大数据量（窗口大小）。窗口大小可以动态调整，这就是"滑动"的由来。

这个窗口包含了一个按顺序发送但尚未被确认的数据序列，它的大小反映了发送方可以在不需要进一步确认的情况下发送的数据量。当接收方处理了一些数据并释放了缓冲区空间时，它会通过发送ACK（确认）信息并更新窗口大小，从而允许发送方发送更多的数据。这样，滑动窗口可以在两端之间来回"滑动"。

TCP拥塞控制（Congestion Control）
TCP的拥塞控制机制是为了防止网络过度拥塞，保证网络中的数据在有限的网络容量下能够平稳有效地传输。拥塞控制通常通过以下几种算法实现：

慢启动（Slow Start）：连接开始时，拥塞窗口大小从1个数据包开始，并在每次收到ACK时加倍，以快速增加网络中的数据量（指数增长）。

拥塞避免（Congestion Avoidance）：当拥塞窗口达到一个阈值（ssthresh）时，算法将从指数增长改为线性增长，即每个RTT（往返时间）只增加1个数据包的窗口大小。

快重传（Fast Retransmit）：当发送方收到三个重复的ACK时，意味着可能有数据包丢失，它不会等待重传定时器到期，而是立即重传丢失的数据包。

快恢复（Fast Recovery）：在快重传之后，ssthresh设为当前拥塞窗口的一半，拥塞窗口设为ssthresh加3个数据包大小，然后进入拥塞避免阶段。如果再次收到重复ACK，拥塞窗口将继续增加，但如果收到新的ACK，拥塞窗口重置为ssthresh大小。

拥塞控制和流量控制虽然都涉及窗口大小调整，但它们解决的问题不同。流量控制防止发送方淹没接收方，而拥塞控制防止发送方过度加载网络。这两个机制一起作用，确保TCP的可靠性和稳定性。

5、TCP粘包的原因和解决办法

TCP粘包是指在TCP传输数据时，多个数据包粘连在一起形成一个大的数据包发送和接收的现象。由于TCP是一个面向流的协议，它并不保留消息的边界，从而可能导致粘包问题。下面是粘包发生的几个原因以及相应的解决方法。
粘包的原因：
发送方原因：
应用程序为了效率，可能会缓冲数据，直到积累了足够多的数据后一次性发送。
Nagle算法可能会导致小包的合并，以减少网络上的小包数量。
接收方原因：
接收方的TCP缓冲区可能一次性读取了多个数据包。
接收应用程序可能不及时读取接收到的数据，使得多个TCP数据包在接收缓冲区中累积。
网络原因：
网络层可能会基于路径MTU（最大传输单元）或其他标准合并多个小包。
解决方法：
消息定界符：
使用特殊的字符或字符串作为消息的结束标识，例如