写在前面
六个标志位
TCP的urg,ack,psh,rst,syn,fin是TCP协议中的6个标志位，用于控制TCP连接的建立、维护和关闭。
| 标志位 | 标志描述 |
|---|---|
| URG（Urgent） | 表示紧急数据，当该标志位被设置时，表明TCP包中的紧急数据需要尽快传输。 |
| ACK（Acknowledgment） | 表示确认，用于确认收到的数据包的序号，表示接收方期望接收的下一个字节的序号。 |
| PSH（Push） | 表示推送，当该标志位被设置时，表明发送方应该尽快将数据发送给接收方，而不需要等待缓冲区填满。 |
| RST（Reset） | 表示复位，当该标志位被设置时，表明TCP连接出现错误，需要进行重置，即强制关闭连接。 |
| SYN（Synchronize） | 表示同步，用于建立连接时进行同步序号的交换，即发送方和接收方协商初始序列号。 |
| FIN（Finish） | 表示结束，当该标志位被设置时，表明发送方已经发送完所有数据，请求关闭连接。 |
这些标志位的组合和设置状态不同，可以实现不同的TCP连接状态和控制操作。
ISN（初始化序列号）
初始化序号（英文为：Initial Sequence Number，简称ISN）。
三次握手
基本过程
三次握手是建立TCP连接的过程，它确保客户端和服务器之间的通信能够正常进行。以下是三次握手的详细过程：
1. 客户端发送SYN报文段：(SYN=1, ACK=0, ISNx)
客户端向服务器发送一个TCP报文段，其中SYN标志位被设置为1，表示客户端请求建立连接。客户端还会选择一个随机的初始序列号（ISN, 可记为ISNx）作为起始的序列号，并将这个ISNx放在报文段的序列号字段中。
2. 服务器发送SYN-ACK报文段：(SYN=1, ACK=1, ISNy, ISNx+1)
服务器收到客户端的SYN报文段后，会发送一个TCP报文段作为回应。其中SYN标志位被设置为1，表示服务器同意建立连接。服务器也会选择一个随机的初始序列号（ISN，可记为ISNy），并将这个ISNy放在报文段的序列号字段中。同时，服务器会将确认号字段设置为客户端的ISNx加1，表示确认收到客户端的初始序列号。这样，服务器和客户端都知道对方的初始序列号了。
3. 客户端发送ACK报文段：(SYN=0, ACK=1, ISNy+1, ISNx+1)
客户端收到服务器的SYN-ACK报文段后，会发送一个TCP报文段作为确认。其中ACK标志位被设置为1，表示确认服务器的初始序列号。客户端会将确认号字段设置为服务器的ISN加1，表示确认收到服务器的初始序列号。同时，客户端也会将自己的初始序列号放在序列号字段中。
经过这三次握手，客户端和服务器都知道对方的初始序列号，并确认对方的初始序列号。此时，TCP连接建立成功，双方可以开始进行数据传输。
需要注意的是，三次握手过程中，每次发送的报文段都需要等待对方的确认才能进行下一步操作。这样可以确保双方都能够正确地收到对方的数据包，并建立可靠的连接。
异常情况
在三次握手过程中，可能会出现一些异常情况，例如超时、丢包、重复发送等。下面是几种可能的异常情况和处理方式：
1. 超时：如果某个阶段的报文段在一定时间内没有收到对方的响应，就会发生超时。这可能是由于网络延迟或拥塞造成的。处理超时的方式是重新发送对应的报文段，直到收到对方的响应或达到最大重传次数。
2. 丢包：在网络传输过程中，报文段有可能会丢失。这可能是由于网络拥塞、链路故障等原因造成的。处理丢包的方式是等待一段时间，如果在一定时间内没有收到对方的响应，就重新发送对应的报文段。
3. 重复发送：在网络传输过程中，可能会出现报文段重复发送的情况。这可能是由于网络延迟、丢包后的重传等原因造成的。处理重复发送的方式是接收方在收到重复的报文段时，忽略掉重复的报文段，只处理第一次接收到的报文段。
4. 错误的序列号：在三次握手过程中，如果接收方收到的序列号不正确，可能会导致连接建立失败。处理错误的序列号的方式是重新发送对应的报文段，直到接收方收到正确的序列号为止。
5. 拒绝连接：在三次握手过程中，服务器可能会拒绝客户端的连接请求。这可能是由于服务器资源不足、访问限制等原因造成的。处理拒绝连接的方式是客户端可以尝试连接其他可用的服务器，或者等待一段时间后重新发送连接请求。
以上是一些可能出现的异常情况和处理方式，具体的处理方式会根据具体的网络环境和应用场景而有所不同。在实际应用中，还需要考虑网络安全、性能优化等因素来保证连接的可靠性和稳定性。
异常宕机情况
如果在三次握手过程中，服务器或客户端宕机，会出现不同的情况：
服务器宕机：
如果在客户端发送SYN报文段后，服务器宕机，客户端将无法收到服务器的回应。客户端会等待一段时间，如果在超时时间内没有收到服务器的回应，客户端会重新发送SYN报文段。这个过程会重复多次，直到客户端达到最大重传次数。
如果服务器在客户端达到最大重传次数之前恢复，客户端会收到服务器的回应，连接可以继续建立。但如果服务器在客户端达到最大重传次数之后才恢复，连接建立将失败。
客户端宕机：
如果在服务器收到客户端的SYN报文段后，客户端宕机，服务器将无法收到客户端的确认。服务器会等待一段时间，如果在超时时间内没有收到客户端的确认，服务器会重新发送SYN-ACK报文段。这个过程会重复多次，直到服务器达到最大重传次数。
如果客户端在服务器达到最大重传次数之前恢复，服务器会收到客户端的确认，连接可以继续建立。但如果客户端在服务器达到最大重传次数之后才恢复，连接建立将失败。
总结来说，在三次握手过程中，如果其中一方宕机，会导致连接建立失败。为了避免这种情况，可以通过设置合理的超时时间和重传次数来提高连接的可靠性。另外，还可以使用心跳机制来检测连接的存活状态，及时发现并处理宕机的情况。
心跳机制
心跳机制是一种用于检测连接的存活状态的方法，它通过定期发送心跳消息来确认连接的可用性。
在网络通信中，发送方定期发送心跳消息给接收方，接收方收到心跳消息后，可以发送一个确认消息给发送方，表示连接仍然存活。
心跳机制的工作原理如下：
1. 发送方定期发送心跳消息：
发送方会定期发送心跳消息给接收方，通常是以固定的时间间隔发送。心跳消息可以是一个特定的报文或者简单的PING消息，用于告知接收方连接的存活状态。
2. 接收方接收心跳消息：
接收方会在指定的端口上监听心跳消息，并等待心跳消息的到达。一旦接收到心跳消息，接收方就知道发送方仍然活跃。
3. 接收方发送确认消息：
接收方在收到心跳消息后，可以选择发送一个确认消息给发送方，表示连接仍然存活。确认消息可以是一个特定的报文或者简单的PONG消息。
4. 发送方接收确认消息：
发送方在发送心跳消息后，等待一段时间来接收接收方的确认消息。如果发送方在超时时间内收到了确认消息，就知道连接仍然存活。如果超过了超时时间仍然没有收到确认消息，发送方可以认为连接已断开。
通过心跳机制，发送方和接收方可以定期交换心跳消息，以确认连接的存活状态。如果在一定的时间内没有收到心跳消息或确认消息，就可以认为连接已断开，可以采取相应的处理措施，如重新建立连接或进行错误处理。
心跳机制在网络通信中广泛应用，特别是在长连接场景下，如TCP、WebSocket等协议中，用于保持连接的稳定性和可靠性。
四次挥手
基本过程
四次挥手是用于关闭TCP连接的过程，它包括以下步骤：
1. 发送方发送关闭连接请求：(FIN=1)
发送方首先发送一个FIN（Finish）报文段给接收方，表示发送方已经没有数据要发送了，希望关闭连接。发送方进入FIN_WAIT_1状态。
2. 接收方发送确认关闭请求：(ACK=1)
接收方收到发送方的FIN报文段后，发送一个ACK（Acknowledgment）报文段给发送方，确认关闭请求。接收方进入CLOSE_WAIT状态。
3. 接收方发送关闭连接请求：(FIN=1,)
接收方在发送完所有数据后，也会发送一个FIN报文段给发送方，表示接收方已经没有数据要发送了，也希望关闭连接。接收方进入LAST_ACK状态。
4. 发送方发送确认关闭请求：(ACK=1)
发送方收到接收方的FIN报文段后，发送一个ACK报文段给接收方，确认关闭请求。发送方进入TIME_WAIT状态。
在TIME_WAIT状态下，发送方会等待一段时间（通常是2倍的最大报文段生存时间，即2MSL）后才关闭连接。
这个等待时间是为了确保接收方收到了发送方的确认，并且接收方的确认也能够传达到发送方。
如果发送方在TIME_WAIT状态下收到了FIN报文段，就说明接收方没有收到ACK报文段（因为接收方此时在LAST_ACK状态，等待发送方的ACK报文段来进入下一个状态，如果没有接收到ACK报文段就重发一份FIN报文段）
那么发送方就继续发送ACK报文段，并进入TIME_WAIT状态，直到直到时间结束都没有收到FIN报文段才进入CLOSED状态关闭连接。
在等待时间结束后，发送方关闭连接，进入CLOSED状态，连接彻底关闭。
接收方在收到发送方的确认后，也会关闭连接，进入CLOSED状态。
需要注意的是，四次挥手过程中，每个报文段都需要对方进行确认。这是因为TCP是一种可靠的协议，确保数据的可靠传输。
通过四次挥手，双方可以协商并确认关闭连接，确保数据的完整性和可靠性。