TCP 3次握手

TCP（传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。在TCP/IP协议族中，TCP提供了一种机制来确保数据在不可靠的网络环境中能够正确无误地传输。为了建立一个可靠的连接，TCP使用了三次握手（Three-Way Handshake）过程。这个过程确保了双方都准备好进行数据交换，并且能够同步各自的序列号和确认号。

三次握手的原因和步骤如下：

防止已失效的连接请求报文段突然又传到了服务端，因而产生错误。 在网络中，由于网络延迟或者重传，可能会有旧的连接请求（SYN）报文在网络中滞留。如果服务端直接接受这个旧的SYN报文并发送SYN-ACK，那么这个连接就会建立在过时的信息上，这可能导致数据传输错误。三次握手可以确保双方都发送了新的信息，从而避免这种情况。
确保双方都准备好进行数据交换。 三次握手确保了客户端和服务器都准备好了，并且双方都能够接收和发送数据。这个过程包括了双方的确认，即客户端确认服务器的SYN-ACK，服务器确认客户端的ACK。

三次握手的具体步骤：

客户端发送SYN报文：客户端向服务器发送一个SYN（同步）报文，其中包含一个随机生成的序列号（Seq=X）。这个报文表明客户端希望建立连接。
服务器发送SYN-ACK报文：服务器收到SYN报文后，会发送一个SYN-ACK（同步确认）报文给客户端。这个报文包含服务器的序列号（Seq=Y）和一个确认号（Ack=X+1），表示服务器已经准备好通信。
客户端发送ACK报文：客户端收到SYN-ACK报文后，会发送一个ACK（确认）报文给服务器。这个报文包含客户端的序列号（Seq=X+1）和一个确认号（Ack=Y+1），表示客户端已经准备好接收数据。

完成这三次握手后，TCP连接就建立了，双方可以开始传输数据。这个过程确保了双方都能够同步序列号和确认号，从而为后续的数据传输提供了可靠的基础。

连接的建立就是通信双方确认自己收发能力都ok的过程。

让我们用一个简单的比喻来解释TCP的三次握手。

想象一下，你和你的朋友小王想要通过信件来建立一个秘密通信。你们需要确保信件能够安全、准确地传递给对方，而且双方都准备好开始通信了。所以，你们决定用一种特殊的握手方式来确认一切就绪。

你（客户端）给小王（服务器）写信：
- 你开始写信，告诉小王你想开始通信。这就像是你向小王挥手，说：“嘿，我想和你通信！”（但是这时候你不能直接发送数据，因为你不知道小王有没有收到你的消息，你就不知道自己的收发消息能力是否ok，连接还未建立）
小王回信确认：
- 小王收到你的信后，他会回信告诉你他收到了你的信。这就像是小王回应你的挥手，说：“我收到了你的信，我也准备好了！”（但是小王这时候也不能开始传输数据，因为小王接受到你的消息，说明小王收消息ok，但是小王不知道自己发消息是否ok）
你再次回信确认：
- 你收到小王的回信后，你会再次写信告诉他你收到了他的确认。这就像是你再次挥手，说：“我也收到了你的确认，我们现在可以开始通信了！”（你收到消息之后说明你的收发消息都ok，小王收到你的消息也说明他的发消息能力ok，好了，收发消息能力确认完毕，连接建立！）

这个过程就像是你们两个人互相确认对方都准备好了，而且都收到了对方的信号。这样，你们就可以开始安全地传递秘密信件了。这就是TCP的三次握手，它确保了双方都准备好通信，并且能够同步各自的信息，从而保证了通信的可靠性。

TCP 4次挥手

TCP（传输控制协议）在断开连接时使用四次挥手（Four-Way Handshake）的过程，这是为了确保双方都能够安全地关闭连接，并且确保所有的数据都已经传输完成。四次挥手的目的是为了允许双方各自发送和接收最后一个数据包，然后优雅地关闭连接。下面是四次挥手的详细步骤及其原因：

客户端发送FIN报文：

客户端完成数据发送后，会发送一个FIN（结束）报文给服务器，告诉服务器客户端没有更多的数据要发送了。（这个步骤的目的是让服务器知道客户端准备关闭连接，并且客户端已经发送了所有数据）

服务器发送ACK报文：

服务器收到客户端的FIN报文后，会发送一个ACK（确认）报文给客户端，确认收到了客户端的FIN报文。（这个步骤确保了客户端知道服务器已经收到了关闭连接的请求）

服务器发送FIN报文：

当服务器也准备好关闭连接，并且所有的数据都已经发送和处理完成时，服务器会发送一个FIN报文给客户端。（这个步骤告诉客户端服务器也准备关闭连接，并且服务器已经发送了所有数据）

客户端发送最后的ACK报文：

客户端收到服务器的FIN报文后，会发送最后一个ACK报文给服务器，确认收到了服务器的FIN报文。（这个步骤是为了让服务器知道客户端已经准备好关闭连接，并且客户端已经收到了服务器的所有数据）

四次挥手完成后，TCP连接就被关闭了。这个过程确保了双方都有机会发送和确认最后一个数据包，从而避免了数据丢失。此外，四次挥手也允许服务器在客户端发送FIN之前继续发送数据，直到服务器也准备好关闭连接。这样，即使在客户端关闭连接之前，服务器也可以继续处理和发送数据，直到它也准备好关闭连接。

TCP和UDP对比

TCP（传输控制协议）和UDP（用户数据报协议）是两种主要的传输层协议，它们在网络通信中扮演着不同的角色。以下是从多个方面对TCP和UDP进行比较的详细解释：

连接类型：
- TCP是面向连接的协议，它在数据传输前需要建立一个稳定的连接。这就像打电话之前需要拨号，电话接通后才能通话。
- UDP是无连接的协议，它不需要预先建立连接就可以直接发送数据。这就像你可以直接在公共留言板上留言，不需要先确认对方是否在线。
可靠性：
- TCP提供可靠的数据传输，它通过确认应答、重传机制、序列号和流量控制来确保数据包按顺序到达并且没有错误。
- UDP不保证数据包的可靠传输，它不提供确认应答、重传机制或错误检测。数据包可能会丢失、重复或乱序到达。
速度和效率：
- TCP由于其可靠性机制，通常比UDP慢，因为它需要更多的时间来确认数据包的传输状态。
- UDP由于没有这些额外的确认和重传机制，传输速度更快，适合对实时性要求高的应用，如视频流和在线游戏。
数据完整性：
- TCP通过序列号和确认应答来确保数据的完整性，如果数据包丢失或损坏，TCP会请求重传。
- UDP不检查数据包的完整性，如果数据包丢失或损坏，它不会请求重传。
头部开销：
- TCP的头部比UDP的头部大，因为它包含了更多的控制信息，如序列号、确认号和校验和等。
- UDP的头部较小，只有8个字节，因为它不包含TCP的那些控制信息。
应用场景：
- TCP适用于需要可靠数据传输的应用，如网页浏览、文件传输和电子邮件。
- UDP适用于对实时性要求高、可以容忍数据丢失的应用，如视频会议、在线游戏和流媒体传输。
连接建立和关闭：
- TCP需要三次握手来建立连接，四次挥手来关闭连接，这个过程相对复杂。
- UDP没有连接建立和关闭的过程，它直接发送数据包，这使得它的通信过程更简单。
流量控制和拥塞控制：
- TCP有流量控制和拥塞控制机制，可以根据网络状况调整数据传输速率，避免网络拥塞。
- UDP没有这些控制机制，它只是简单地发送数据包，不考虑网络状况。

总结来说，TCP和UDP各有优势，选择使用哪种协议取决于应用的需求。如果应用需要可靠的数据传输和错误检测，TCP是更好的选择；如果应用对实时性有较高要求，并且可以容忍数据丢失，那么UDP可能更适合。