网络编程端口状态都有哪些？

向右看齐 2024-03-23 12:38 43阅读 0赞

## 参考大佬流程图 ##

![在这里插入图片描述][5ee2570d507a4a289cea008b06b2b6c9.png_pic_center]  
![在这里插入图片描述][c6ad493dcc114db8a153185bf4b0fe5d.png_pic_center]  
**参考：[计算机网络基础及 TCP、HTTP 协议详解][TCP_HTTP]**

--------------------

## TCP报文 ☞ 标志位 ##

> 标志位共6个，含义如下
> 
>  *  `SYN`：发起一个新连接。
>  *  `FIN`：释放一个连接。
>  *  `ACK`：确认序号有效,确认接收到消息。
>  *  `URG`：紧急指针（urgent pointer）有效。
>  *  `PSH`：接收方应该尽快将这个报文交给应用层。
>  *  `RST`：重置连接。

> 注意：  
> `序号ack`和`标志位ACK`不是一个东西，`确认方ack`=`发起方seq+1`，两端配对

--------------------

## 三次握手阶段 ##

### 客户端侧： ###

#### `CLOSED`（持续状态） ####

> 关闭状态

#### `SYN_SENT` （非常短暂） ####

> `SYN_SENT`状态表示请求连接，当你要访问其它的计算机的服务时首先要发个同步信号给该端口，此时状态为`SYN_SENT`，如果连接成功了就变为`ESTABLISHED`，此时`SYN_SENT`状态非常短暂。

##### 冲击波或震荡波攻击 #####

> 但如果发现`SYN_SENT`非常多且在向不同的机器发出，那你的机器可能中了冲击波或震荡波之类的病毒了。这类病毒为了感染别的计算机，它就要扫描别的计算机，在扫描的过程中对每个要扫描的计算机都要发出了同步请求，这也是出现许多`SYN_SENT`的原因。

#### `ESTABLISHED`（持续状态） ####

> `ESTABLISHED`的意思是建立连接。表示两台机器正在通信。

--------------------

### 服务端侧： ###

#### `CLOSED`（持续状态） ####

> 关闭状态

#### `LISTENING`（持续状态） ####

> FTP服务启动后首先处于侦听`LISTENING`状态。

#### `SYN-RCVD`（非常短暂） ####

> 当服务器收到客户端发送的同步信号时，将标志位ACK和SYN置1发送给客户端，此时服务器端处于`SYN_RCVD`状态，  
> 如果连接成功了就变为`ESTABLISHED`，正常情况下`SYN_RCVD`状态非常短暂。  
> 如果发现有很多`SYN_RCVD`状态，那你的机器有可能被`SYN Flood`的`DoS`(拒绝服务攻击)攻击了。

##### SYN Flood攻击（SYN洪水攻击）攻击原理 #####

> 在进行三次握手时，攻击软件向被攻击的服务器发送SYN连接请求(握手的第一步)，但是这个地址是伪造的，如攻击软件随机伪造了51.133.163.104、65.158.99.152等等地址。服务器 在收到连接请求时将标志位 ACK和 SYN 置1发送给客户端(握手的第二步)，但是这些客户端的IP地址都是伪造的，服务器根本找不到客户机，也就是说握手的第三步不可能完成。这种情况下服务器端一般会重试(`再次发送SYN+ACK给客户端`)并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为`SYN Timeout`，一般来说这个时间是分钟的数量级(`大约为30秒-2分钟`);一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。此时从正常客户的角度看来，服务器失去响应，这种情况我们称做： 服务器端受到了`SYN Flood攻击（SYN洪水攻击）`

#### `ESTABLISHED`（持续状态） ####

> `ESTABLISHED`的意思是建立连接。表示两台机器正在通信。

##### 为什么不能用两次握手进行连接？ #####

> 3次握手完成两个重要的功能
> 
> 1.  双方都确认好自己收发功能没问题。
> 2.  确认初始序列号。
> 
> **参考：**  
> [OSI网络模型 + TCP三次握手、四次挥手 + Socket、TCP、HTTP三者之间的区别和原理][OSI_ _ TCP_ _ Socket_TCP_HTTP]

##### 如果已经建立了连接，但是客户端突然出现故障了怎么办？ #####

> TCP还设有一个`保活计时器`，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为`2小时`，若2小时还没有收到客户端的任何数据，服务器就会发送一个`探测报文段`，以后每隔`75秒`钟发送一次。若一连发送`10个`探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。  
> **参考：**  
> [OSI网络模型 + TCP三次握手、四次挥手 + Socket、TCP、HTTP三者之间的区别和原理][OSI_ _ TCP_ _ Socket_TCP_HTTP]

--------------------

## 四次挥手阶段 ##

### 客户端侧： ###

#### `FIN_WAIT1`（非常短暂） ####

#### `FIN_WAIT2`（非常短暂） ####

#### `TIME_WAIT`（持续2MSL） ####

> 客户端主动调用close()断开连接，收到对方确认后状态变为`TIME_WAIT`。

> **`Read More`**  
> TCP协议规定`TIME_WAIT`状态会一直持续`2MSL(即两倍的分段最大生存期)`，以此来确保旧的连接状态不会对新连接产生影响。处于`TIME_WAIT`状态的连接占用的资源不会被内核释放，所以作为服务器，在可能的情况下，尽量不要主动断开连接，以减少`TIME_WAIT`状态造成的资源浪费。目前有一种避免`TIME_WAIT`资源浪费的方法，就是关闭socket的LINGER选项。但这种做法是TCP协议不推荐使用的，在某些情况下这个操作可能会带来错误。

--------------------

### 服务端侧： ###

#### `CLOSE_WAIT`（此状态是为了Server端所有的报文都发送完） ####

> 客户端主动关闭连接或者网络异常导致连接中断，这时服务器的状态会变成`CLOSE_WAIT` 此时我方要调用`close()`来使得连接正确关闭

##### 为什么连接的时候是三次握手，关闭的时候却是四次握手？ #####

> 发起一个新连接时，因为当Server端收到Client端的`SYN`连接请求报文后，可以直接发送`SYN+ACK`报文。其中`ACK`报文是用来应答的，`SYN`报文是用来同步的。  
> 但是关闭连接时，当Server端收到`FIN`报文时，可能当前还有报文未发送，故并不会立即关闭`SOCKET`，所以只能先回复一个`ACK`报文，告诉Client端，“你发的`FIN`报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送`FIN`报文，因此不能一起发送。故需要四步握手。  
> **参考：**  
> [OSI网络模型 + TCP三次握手、四次挥手 + Socket、TCP、HTTP三者之间的区别和原理][OSI_ _ TCP_ _ Socket_TCP_HTTP]

#### `LAST_ACK`（非常短暂） ####

--------------------

## 参考 ##

**[解决端口冲突问题（查询端口占用进程并kill） 1. 查看端口占用][kill_ 1.]**  
**[TCP三次握手与四次挥手（详解）][TCP]**

[5ee2570d507a4a289cea008b06b2b6c9.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/446b5ca119924eaa995c146254cfc5ce.png
[c6ad493dcc114db8a153185bf4b0fe5d.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/7113107fc8b44a9e9dd2eeb961f5ad54.png
[TCP_HTTP]: https://blog.csdn.net/wangbo818/article/details/104256810
[OSI_ _ TCP_ _ Socket_TCP_HTTP]: https://blog.csdn.net/weixin_44278698/article/details/124744562
[kill_ 1.]: https://cloud.tencent.com/developer/article/1157090
[TCP]: https://blog.csdn.net/wuyangyang555/article/details/127151730