【网络基础知识】详解TCP/IP协议栈
一、TCP/IP协议栈
TCP/IP协议栈是一个网络通信模型，它定义了电子设备如何通过网络进行相互通信。这个模型是基于分层的概念构建的，TCP属于传输层，IP属于网络层，每一层负责不同的网络通信任务。
传输层提供端到端的数据传输服务。TCP提供可靠的、面向连接的服务，确保数据的完整性和顺序，TCP 通过三次握手建立连接
网络层负责数据包从源到目的地的传输和路由选择。主要协议是IP（Internet Protocol，网际协议），负责数据包的寻址和路由。包括IP地址分配、路由协议等。通过 IP 地址进行寻址和路由，将数据包从源头路由到目的地。
二、什么是TCP三次握手四次挥手
TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP连接的建立和终止需要使用特定的握手过程，即所谓的“三次握手”和“四次挥手”。
TCP三次握手（TCP Three-Way Handshake）
- SYN（同步序列编号） - 客户端选择一个初始序列号x，发送一个SYN包到服务器，以开始一个连接请求。此时，客户端进入SYN_SENT状态。
- SYN-ACK（同步-确认） - 服务器收到SYN包后，如果同意连接，会分配TCP资源，并发送一个SYN-ACK包。服务器选择自己的初始序列号y，并确认客户端的序列号x（ACK(x+1)）。此时，服务器进入SYN_RCVD状态。
- ACK（确认） - 客户端收到SYN-ACK包后，会发送一个ACK包给服务器，确认服务器的序列号y（ACK(y+1)）。客户端此时进入ESTABLISHED状态。服务器收到ACK包后，也进入ESTABLISHED状态。
完成这三次握手后，TCP连接建立成功，数据可以开始传输。
TCP四次挥手（TCP Four-Way Wavehand）
- FIN（结束） - 当客户端完成数据传输并希望断开连接时，它发送一个FIN包，进入FIN-WAIT-1状态。
- ACK（确认） - 服务器收到FIN包后，发送一个ACK包确认，并进入CLOSE-WAIT状态。客户端收到ACK包后，进入FIN-WAIT-2状态。
- FIN（结束） - 服务器完成数据传输后，发送一个FIN包给客户端，请求关闭其端的连接。
- ACK（确认） -客户端收到服务器的FIN包后,发送一个ACK包进行确认,然后进入TIME-WAIT状态.经过一段时间(称为2MSL即最大报文段生存时间的两倍)后,客户端确保服务器接收到最终的ACK包,然后关闭连接.服务器收到ACK后,关闭连接。
完成这四次挥手后，TCP连接被完全关闭。
为什么是三次握手和四次挥手？
- 三次握手确保了双方的接收和发送通道都是开放的，可以开始可靠地传输数据。
- 四次挥手是因为TCP连接是全双工的，即客户端和服务器都可以独立地开始和结束数据发送。因此，每个方向的连接都需要单独关闭。
三次握手和四次挥手是TCP协议的核心特性，确保了连接的建立和终止都是可靠和有序的。
三、TCP四次挥手客户端为什么要在TIME-WAIT状态等待2MSL最大报文段生存时间的2倍后再关闭连接？有什么原因吗？
TCP四次挥手过程中客户端在TIME-WAIT状态等待2MSL（（Maximum Segment Lifetime）,最大报文段生存时间的2倍）的原因主要包括以下几点1. 确保数据传输的完整性 - 在数据传输结束后，可能还有数据包在网络中未到达目的地。TIME-WAIT状态确保了即使最后一个确认（ACK）在网络中丢失，发送方也能够重传FIN包，从而保证连接的可靠关闭。
2. 允许旧的数据包在网络中消失 - 由于网络延迟或重传，可能存在一些旧的数据包在连接关闭后仍然在网络上。2MSL时长可以确保这些旧的数据包在新连接建立之前在网络中消失，避免与新连接的数据包混淆。
3. 防止“已失效”的FIN包影响新连接 - 如果客户端立即关闭连接，之前发送的FIN包可能在网络中延迟到达服务器，导致服务器错误地再次关闭一个已经不存在的连接。等待2MSL可以确保这种情况不会发生。
4. 处理延迟到达的ACK包 - 如果在四次挥手的最后阶段，服务器由于某些原因未能及时接收到客户端的最终确认（ACK），服务器可能会重传FIN包。TIME-WAIT状态确保客户端能够接收到这个迟到的FIN包并进行适当的处理。
5. 遵循TCP规范 - TCP协议规范要求等待2MSL时长，这是一个标准的做法，用于确保所有实现都能够在关闭连接时保持一致的行为。
6. 避免新旧连接混淆 - 如果客户端很快就重新尝试与同一服务器建立连接，等待2MSL可以确保前一个连接的所有数据包都已经从网络中清除，避免与新连接混淆。
2MSL的时长通常设置为120秒，但这个值可以根据网络环境和需求进行调整。等待2MSL是TCP连接管理的一个重要部分，它确保了TCP连接的可靠性和数据传输的完整性。
2MSL的等待时间虽然可能导致连接释放的延迟,但它对于维护TCP连接的可靠性和防止数据包混淆至关重要。在某些场景下，如果应用程序需要快速重用端口，可以通过设置SO_REUSEADDR套接字选项来缩短或绕过TIME-WAIT状态。
四、详细生动形象的解释下这段话：由于网络延迟或重传，可能存在一些旧的数据包在连接关闭后仍然在网络上。2MSL时长可以确保这些旧的数据包在新连接建立之前在网络中消失，避免与新连接的数据包混淆。
让我们用一个生动的比喻来解释这个概念想象一下，网络就像一条繁忙的高速公路，而TCP连接就像是在这条高速公路上行驶的一辆汽车。当汽车（TCP连接）到达目的地后，它需要安全地离开高速公路，以避免发生事故或阻碍交通。在这个过程中，“2MSL”（最大报文段生存时间的两倍）就像是一个"清洁时间"，确保汽车离开后，它可能遗留在路面上的任何碎片（旧的数据包）都被清理干净，这样新汽车（新的TCP连接）就不会因为这些碎片而发生故障或混淆。
现在，让我们更详细地分解这个过程：
- 汽车行驶（TCP连接）：汽车在高速公路上行驶，就像TCP连接在网络上传输数据。
- 汽车到达目的地（连接关闭请求）：汽车到达目的地后，司机希望安全地离开高速公路。这就像TCP连接中的一方请求关闭连接。
- 遗留碎片（旧数据包）：在汽车行驶过程中，可能会有一些碎片从车上掉落，比如丢失的货物或车辆部件。这就像在TCP连接过程中，由于网络延迟或重传，一些旧的数据包可能仍然在网络上。
- 清理时间（2MSL时长）：汽车离开后，高速公路管理部门会等待一段时间，以确保所有遗留的碎片都被清理干净。这个等待时间就是2MSL时长，它确保了所有旧的数据包都有足够的时间在网络中消失(坐等消失好dege残忍)。
- 新汽车上路（新TCP连接建立）：在清理时间过后，新汽车可以安全地上路，不必担心与旧汽车的碎片发生冲突。这就像在TCP连接关闭后，新的连接可以在没有旧数据包干扰的情况下建立。
- 避免混淆（确保数据包正确归属）：若没有这个清理时间，新汽车可能会遇到旧汽车的碎片，这可能导致混淆，比如新汽车可能会错误地将旧碎片当作自己的部件。在TCP连接中，若没有2MSL时长，新连接可能接收到旧数据包，导致数据混淆或错误。
通过这个比喻，我们可以理解2MSL时长的重要性：它为网络提供了一个"清洁"期，确保旧的数据包在新的TCP连接建立之前被清除，从而维护了网络通信的清晰和准确。
五、TCP四次挥手是由服务端还是客户端发起的?
TCP四次挥手（Four-way handshake）是TCP连接终止过程中使用的术语，用于描述两个通信端点（客户端和服务器）如何通过发送特定的TCP段来关闭它们的连接。四次挥手不是由服务端或客户端单方面发起的，而是由任何一端发起的断开连接的过程。
以下是TCP四次挥手的四个步骤：
- FIN_WAIT_1：主动关闭方（可以是客户端或服务端）发送一个FIN（结束）标志位被设置的TCP段，用来关闭主动方到被动方的连接。
- CLOSE_WAIT：被动关闭方接收到FIN后，发送一个ACK（确认）标志位被设置的TCP段作为回应，并进入CLOSE_WAIT状态。此时被动关闭方可以准备关闭它的写入方向。
- LAST_ACK：被动关闭方发送一个FIN标志位被设置的TCP段，请求关闭其到主动关闭方的连接。
- TIME_WAIT：主动关闭方接收到这个FIN后，发送一个ACK标志位被设置的TCP段作为回应，并进入TIME_WAIT状态。经过足够的时间以确保被动关闭方接收到最终的ACK后，主动关闭方关闭连接。
在TCP连接生命周期中，任何一方都可以在完成数据传输后决定关闭连接，因此可以是客户端或服务端发起四次挥手过程。通常发起连接关闭的一方会首先发送FIN，而另一方会响应并最终关闭它的发送方向，完成连接的完全关闭。
六、TCP四次挥手各个阶段及所处状态
TCP的四次挥手过程中的"LAST_ACK"阶段是被动关闭方响应主动关闭方的FIN请求并发送自己的FIN包之后，等待主动关闭方确认的阶段。
以下是TCP四次挥手的各个阶段，包括LAST_ACK阶段的详细说明
- FIN_WAIT_1：主动关闭方（可以是客户端或服务器）决定关闭连接，并发送一个FIN标志位被设置的TCP段，进入此状态。
- CLOSE_WAIT：被动关闭方接收到FIN后，发送一个ACK确认，并进入CLOSE_WAIT状态，此时主动关闭方接收到ACK后进入FIN_WAIT_2状态。
- FIN_WAIT_2：主动关闭方在接收到被动关闭方的ACK后，进入此状态，等待接收被动关闭方的FIN请求。
- LAST_ACK：当被动关闭方准备好关闭连接时，它发送一个自己的FIN标志位被设置的TCP段。这个FIN段被发送后，被动关闭方进入LAST_ACK状态，等待主动关闭方对此FIN的确认。
- TIME_WAIT：主动关闭方接收到来自被动关闭方的FIN后，发送一个ACK确认，并进入TIME_WAIT状态。在2MSL时长后，主动关闭方确保被动关闭方接收到了最终的ACK，然后关闭连接。
- CLOSED：在TIME_WAIT超时后，主动关闭方关闭连接，进入CLOSED状态。同时，被动关闭方在发送完FIN并接收到最终的ACK后，也会进入CLOSED状态。
LAST_ACK是被动关闭方在发送完FIN并等待最终确认的阶段。这个阶段确保了TCP连接的完全关闭，并且所有未完成的事务都已处理完毕。
七、详述TCP的头部包含啥
TCP（传输控制协议）头部是TCP数据包的重要组成部分，用于控制数据的传输和确保数据的可靠性。TCP头部包含以下主要字段1. 源端口号（Source Port） - 16位：标识发送方的端口号。
2. 目的端口号（Destination Port） - 16位：标识接收方的端口号。
3. 序列号（Sequence Number） - 32位：用于在数据流中标识字节的顺序。这个序列号用于确保数据包的顺序和完整性。
4. 确认号（Acknowledgment Number） - 32位：当ACK标志位被设置时，此字段包含期望收到的下一个数据包的序列号，表示到目前为止已经成功接收了多少数据。
5. 数据偏移（Data Offset） - 4位：指示TCP头部的长度（以32位字为单位）。因为TCP头部可能包含选项字段，所以头部的长度可能会变化。
6. 保留（Reserved） - 6位：这些位必须设置为0，为将来使用保留。
7. 标志位（Flags） - 6位：控制TCP的不同功能，包括SYN、ACK、PSH、RST、URG、ECE和CWR。
8. 窗口大小（Window Size） - 16位：用于流量控制，指示接收方可以接收的最大数据量。
9. 校验和（Checksum） - 16位：包含头部、数据和其他一些信息的校验和，用于错误检测。
10. 紧急指针（Urgent Pointer） - 16位：当URG标志位被设置时，此字段指示数据中紧急数据的结束位置。
11. 选项（Options） - 可变长度：包含附加的TCP配置选项，如最大报文段长度（MSS）、窗口缩放因子、选择性确认（SACK）、时间戳等。
12. 填充（Padding） - 可变长度：确保TCP头部是32位字对齐的填充字节。
TCP头部的设计使得它既能够提供可靠的数据传输，又能够适应不同的网络环境和应用需求。通过序列号和确认号，TCP能够确保数据包的顺序和完整性。通过窗口大小，TCP能够进行流量控制，避免发送方发送过多数据导致接收方处理不过来。通过各种标志位，TCP能够控制连接的建立、维护和释放。通过选项字段，TCP能够支持各种高级特性和优化。
八、UDP和TCP的区别
UDP（User Datagram Protocol，用户数据报协议）和TCP（Transmission Control Protocol，传输控制协议）是两种在传输层使用的协议，它们在网络通信中扮演着重要的角色，但具有不同的特性和用途。以下是UDP和TCP的主要区别1. 连接性 - TCP：面向连接的协议。在数据传输开始之前，需要通过三次握手建立连接。
- UDP：无连接的协议。数据传输前不需要建立连接，直接发送数据。
- 可靠性 - TCP：提供可靠的数据传输服务，通过序列号、确认应答、重传机制等确保数据正确送达。
- UDP：不保证数据的可靠性，不进行错误检测和重传，可能发生数据丢失或乱序。
- 速度 - TCP：由于需要维护连接状态和进行错误处理，通常速度较慢。
- UDP：传输速度快，适合对实时性要求高的应用。
- 数据传输方式 - TCP：面向字节流的传输，数据被看作是一连串的字节流。
- UDP：面向报文的传输，数据被分割成一个个的数据报。
- 拥塞控制 - TCP：具有拥塞控制机制，可以根据网络状况调整数据传输速率。
- UDP：不进行拥塞控制，不考虑网络拥塞情况。
- 流量控制 - TCP：具有流量控制机制，通过滑动窗口协议来控制发送速率。
- UDP：不进行流量控制。
- 序列号和确认 - TCP：使用序列号和确认应答机制来确保数据的顺序和完整性。
- UDP：不使用序列号和确认机制。
- 用途 - TCP：适用于需要可靠传输的应用，如Web浏览（HTTP）、文件传输（FTP）、邮件传输（SMTP）等。
- UDP：适用于对实时性要求高的应用，如在线游戏、实时视频会议、DNS查询等。
- 头部开销 - TCP：头部开销较大，包含序列号、确认应答、窗口大小等控制信息。
- UDP：头部开销较小，只包含源端口、目的端口和长度等基本信息。
- 错误处理 - TCP：能够检测数据在传输过程中的错误，并进行重传。
- UDP：不提供错误检测和重传机制。
选择UDP或TCP取决于应用的需求。如果需要可靠、有序的数据传输，TCP是更好的选择。如果需要快速传输且可以容忍一定程度的数据丢失，UDP可能更合适。
- UDP：不提供错误检测和重传机制。