引言: 集中一点,登峰造极。
先把流程图贴上来 :
为什么这么复杂? 因为TCP是可靠性传输。
确认可靠传输的前提: TCP连接管理机制
用TCP报文中标志位控制 :
三次握手(建立连接) : 两次连接请求(SYN)+两次应答(ACK)
流程 : 服务端进入LISTEN状态后,客户端向服务端发送SYN连接请求,服务端收到后会发送ACK应答和SYN连接请求,客户端收到后再向服务端发送ACK应答,此时连接建立成功。
四次挥手(断开连接) : 两次断开请求(FIN)+两次应答(ACK)
流程 : 主动断开方不确定,主动断开方发送FIN断开请求,被动方回复ACK应答进入CLOSE_WAIT状态,被动方关闭连接后再发送FIN断开请求,主动断开方回复ACK应答进入TIME_WAIT状态,被动方收到ACK后关闭,2MSL后主动方关闭,此时连接断开成功。
Q1: 为什么服务端要先进入LISTEN状态?
A1: 在应用层就是调用listen函数,使socket变为被动状态,允许其他客户端和服务器建立连接。
Q2: 怎么才算建立连接成功?断开连接成功?
A2: 两端都进入ESTABLISHED状态,都进入COLSED状态。
Q3: 为什么要有TIME_WAIT状态,直接关闭不好吗?
A3: 重传控制 , 为了保证最后一个ACK丢了还能重传,确定对方确认。客户端进程已经没有了,但是TCP连接还存在,如果被动方没收到ACK,就会超时重传FIN,这样
Q4: 为什么是2MSL?
A4: 连接存在就会占用内存,所以不可能一直存在,等2MSL就会强制中断。
1.保证被动方可以超时重传FIN
2.MSL是一个数据报从一端走到另一端所消耗的最长时间,2MSL能保证两个传输中未被接收或者迟到的报文段消失(否则如果服务器立刻重启,会收到上一进程的数据,此时信息可能错误)
Q5: 为什么是三次握手,四次挥手?
A5: 三次握手是因为服务端接收到SYN后,可以直接发送SYN和ACK应答用来同步。
服务器收到FIN后,内核主动回应ACK,应用层调用了close才会发送FIN。也可以是三次挥手,用捎带应答。
Q6: 如果客户端突然出现故障怎么办?
A6: TCP处理异常设有保活定时器: 如果一定时间内没有收到任何发送方的数据,此时就发一个心跳包,发若干次后,如果没回应就断开连接。
Q7: 为什么不能用两次握手或者四次握手?
A7: 三次能确保对方具有收发数据的能力,并且保存异常连接的一方只可能是客户端,不会浪费服务器资源。
如果是两次,客户端给服务器发消息,服务器收到后再给客户端发消息,不能确保客户端是否能收到消息。所以需要客户端再回复给服务器表示我能收到消息。
四次也就多余了。
如果是两次,容易让服务器收到SYN"洪水攻击",浪费服务器资源。四次也可能会浪费服务器资源。
Q8: 连接建立一定成功吗?
A8: 不一定. 三次握手也都是普通的报文,都有可能丢。
前两个报文丢了,建立不成功,双方不会为了维护这个连接而长时间保持这个失败的连接。
第三个报文丢了,客户端连接成功,服务器不会长时间保存这个半连接,客户端会长时间保持这个连接,会浪费客户端资源。