TCP
2019-08-29 本文已影响0人
l1n3x
状态转移图
TCP状态转移图三次握手
1. 客户端: SYN = 1 Seq = x
2. 服务端: ACK = 1 ACKNum = x + 1 | SYN = 1 Seq = y
3. 客户端: ACK = 1 ACKNum = y + 1
需要注意是第二次服务端的操作,服务端既要对客户端的握手信号进行应答ACK = 1 ACKNum = x + 1
还要对客户端发起新的握手信号SYN = 1 Seq = y
,因此会出现ACK
与 SYN
同时出现的情况。
四次挥手
1. 客户端: FIN = 1 Seq = x
2. 服务器: ACK = 1 ACKNum = x + 1
3. 服务器: FIN = 1 Seq = y (CLOSE WAIT)
4. 客户端: ACK = 1 ACKNum = y + 1 (TIME WAIT)
其中客户端和服务端都会发送一次FIN
都会响应一次ACK
。这里有两个需要注意的状态:
TIME WAIT
TIME WAIT 只会出现在发起关闭的那一端。面试常会问到两个问题:
- 为什么需要 TIME WAIT 这个状态?
由于当客户端发出 ACK 后,服务端可能会收不到这个 ACK。此时服务端会再次发起 FIN。如果客户端不进行等待,则可能在新连接中收到上一次服务端发送的 FIN。这个 FIN 并不属于新连接的任何一个状态,这时客户端会发起 RST 重置连接。为了避免这个状况,所以需要 TIME WAIT 这个状态。 - 如果服务端大量出现这个状态有什么害处,应该怎么避免?
出现 TIME WAIT 后,服务端既不能发送数据,也不能接受数据。但是由于为了维护连接的完整性,依然会等待2MSL(2倍报文最大周期)。因此占用了资源,却无法传输数据。此外,如果使用SELECT
这个多路复用机制,还存在最大为1024的连接限制。当 TIME WAIT 过多,往往会导致打开文件过多的错误
。为了避免这种情况,应该:
a. 因此 TIME WAIT 只会出现主动断开连接的一段,所以服务端尽量不主动断开连接。、
b. 减少 MSL 等待时间
CLOSE WAIT
CLOSE WAIT 只会出现在被动断开服务的一端。同样,出现 CLOSE WAIT 同样会占用服务器资源。由于 CLOSE WAIT 是出现在被动断开的端,因此在收到客户端的关闭连接之后,应该尽快想客户端发起关闭连接请求。