TCP连接管理

TCP-【建立连接】-3次握手

TCP-【释放连接】-4次挥手

TCP-【建立连接】-3次握手

请添加图片描述

状态解读：

CLOSED: client处于关闭状态

LISTEN:server处于监听状态，等待client连接

SYN-RCVD(同步已接受）:表示server接收到了SYN报文，当收到client的ACK报文后，server进入ESTABLISHED状态

SYN-SENT(同步已发送)：表示client已发送SYN报文，等待server的第二次握手

ESTABLISHED:表示连接已经建立

前两次握手的特点：

SYN字段都设置为1
数据部分长度都为0
TCP头部长度一般都是32字节
- 固定头部：20字节
- 选项部分：12字节
双方会交换确认一些信息
- MSS（最大发送段的长度）、是否支持SACK、Window scale（窗口缩放比例）等
- 这些信息都存放在TCP头部的选项部分中（12字节）

TCP-建立连接-面试知识点

为什么建立连接的时候，要进行3次握手？2次不行吗

主要目的；防止server端一直等待，浪费资源
如果只需要2次握手，可能会出现的情况

假设client发送的第一个连接请求报文段，因为网络延迟，在连接释放后某个时间才到达server
本来是一个早已失效的连接请求，但server收到此失效请求后，误认为是client再次发送的一个新的连接请求
于是server就向client发送确认报文段，新的连接就建立了
由于现在的client并没有真正想连接服务器的意愿，因此不会理睬server的确认，也不会向server发送数据
但server却认为新的建立已连接，并一直等待client发来数据，就这样server很多资源被白白浪费

采用三次握手的办法可以防止上述现象发生
client没有向server发出确认，server由于收不到确认，就知道client并没有建立连接

2、第3次握手失败了，会如何处理？

此时server状态为SYN-RCVD,若等不到client的ACK，server会重新发送SYN+ACK（1，1）包
如果server多次重发SYN+ACK都等不到client的ACK就会发送RST包，关闭连接

请添加图片描述

TCP-【释放连接】-4次挥手

请添加图片描述

状态：

FIN-WAIT-1:表示想主动关闭连接

向对方发送FIN报文，此时进入到FIN-WAIT-1状态

CLOSE-WAIT:表示在等待关闭

当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时进入CLISE-WAIT状态
在此状态下，需要考虑自己是否还有数据要发送给对方，如果没有，发送FIN报文给对方

FIN-WAIT-2:只要对方发送ACK确认后，主动方会处于FIN-WAIT-2状态，然后等待对方发送FIN报文

CLOSING:罕见的例外状态

表示双方同时发送FIN报文（此时没有主动和被动方一说）
双方都主动关闭连接

LAST-ACK(最后确认）：被动关闭一方在发送FIN报文后，最后处于等待主动方的ACK报文

当被动方收到主动方的ACK后，就进入CLOSED

TIME-WAIT（时间等待）:表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即进入了CLOSE状态

如果主动方在FIN-WAIT-1状态下，就受到了被动方的FIN和ACK标志的报文
此时就主动方直接进入TIME-WAIT

TCP释放连接的细节

TCP/IP协议栈的设计上，允许任何一方先发起断开请求
主动方发送ACK后，需要有个TIME-WAIT阶段，等待一段时间后，再真正关闭连接
- 一般等待2倍的MSL(最大分段生存期)
  - MSL是TCP报文在Internet最长生存周期
  - TCP标准都有一个确定的MSL值，某RFC建议为2分钟
  - MSL可以防止本次连接中产生的数据包误传到下一次连接中（因为本次连接中的数据包会在2MSL时间内消失掉）
如果主动方发送完ACK立马释放连接，然后因为网络原因，被动方没有收到client的ACK，被动方就会重新发送FIN
- 这时可能出现的情况
  1. 主动方没有任何响应，被动方在那里干等，甚至多次重发FIN，浪费资源
  2. 主动方（假设为client）有个新的应用程序刚好分配了同一个端口，新的应用程序收到FIN立马开始执行断开操作，本来它可能想跟新的server建立连接