【Linux网络】传输层协议TCP（2）连接管理、三次握手、四次挥手

hello~ 很高兴见到大家! 这次带来的是Linux网络中关于网络基础这部分的一些知识点,如果对你有所帮助的话,可否留下你宝贵的三连呢?个 人 主 页: 默|笙文章目录一、连接管理机制1.1 连接与三次握手连接管理三次握手1.2 四次挥手连接管理与理解 TIME_WAIT 状态MSL地址重用/端口复用四次挥手一、连接管理机制这个图紧挨着的两根线代表的是两端TCP层各自的状态流转再旁边则是应用层所干的事情。1.1 连接与三次握手连接管理首先服务端应用层必须要有一个描述符处于监听状态LISTEN这个时候就可以等待客户端来建立连接了。而客户端则调用 connect 告诉系统可以发送连接请求了。三次握手完全是由系统传输层协议TCP替我们完成的。三次握手完成之后就代表建立好了一个连接。这个连接可以看作是双向的两个逻辑通道客户端向服务端发送以及服务端向客户端发送它们彼此之间的地位完全相等全双工通信。服务端应用层的 accept 负责将已经建立好的连接从内核队列中拿出来此时返回一个新的描述符 connfd它本身并不参与也不负责三次握手建立连接的过程。也就是说即使没有调用 accept内核也能够完成三次握手建立连接。但是如果应用层一直不把这些连接取出来的话一共能够积压多少个呢listen 函数的第二个参数backlog就是用来控制这个全连接队列容量的。在没有 accept 的情况下内核能够建立并积压的已完成握手的连接数量上限是 backlog 1 个。这些没有被 accept 取走的连接都是被内核管理在全连接队列里面的。调用 accept 的本质就是从这个队列的头部取出一个已经建立好的连接结构体并分配一个新的描述符给应用层去通信。如果全连接队列满了后续新完成握手的连接就无法成功入队了内核默认会丢弃客户端发来的第三次握手 ACK导致客户端误以为连接已建立直到发数据时才收到 RST 报错。所以这个 backlog 的数量不宜过大否则大量连接会在队列中排队等待超时白白浪费内存资源。打个比方有一家餐厅店里的座位应用层正在处理的连接虽然满了但是只要外面等候区全连接队列还没坐满店员就会询问新来客人新的连接完成三次握手的意愿。客人愿意等的话店员就分配一个号让客人在外面先坐着。这些在外面坐着的客人就是已经完成三次握手、在内核里等待被 accept 取走的连接。但是如果连外面等候区全连接队列也坐满了这个时候如果再来客人正常情况下如果没有开启特殊设置店员其实是“假装发号”甚至直接不理睬的内核默认会直接丢弃第三次握手的ACK客户端以为自己排上号了其实只是个假象直到客人想点菜发数据时才会被店员冷冰冰地赶走回个 RST。所以全连接队列外面的等候区不宜过长因为外面等的客人太多既占用内存资源又会让客人客户端等得不耐烦与其无限扩大等候区不如直接把店面扩大一点提升应用层调用 accept 的速度、采用多线程或 epoll 等多路复用技术这样才能真正招待更多的客人。三次握手三次握手为什么是三次三次握手中每一次报文发送都完成一次握手动作。客户端发出第三次ACK后进入ESTABLISHED状态认为连接已经建立服务端收到这个ACK后进入ESTABLISHED状态认为连接建立完成。TCP发送数据之前先确认双方的通信意愿和当前信道的通畅程度三次握手就是为此服务的。双方的意愿指一方发出请求后能收到对方应答更是确认对方有没有好的发送和接受能力有应答就说明对方愿意通信双方都收到对方应答通信意愿就得到确认。信道通畅指当前网络路径上双方可以正常收发报文网络路径不通畅时数据无法正常传输后续数据传输的可靠性再由确认、重传等机制保障。三次握手以较小成本验证信道通畅和双方通信意愿。三次足以完成确认四次、五次同样可以完成但会增加开销采用三次即可。两次握手后客户端可以确认服务端收到了自己的请求并确认服务端具备发送和接受能力但服务端还需第三次握手来确认客户端已收到自己的回应并确认客户端具备接收能力。一次握手只确认客户端发出了请求只能够确认客户端有接受能力。因此三次握手是必要且足够的最小次数。这个过程打个比方就像男女生交往前要问过双方意愿网络相当于双方父母和外部环境双方父母同意、环境支持交往就不会有太大问题。三次握手就是用较小成本确认双方都有意愿、信道能够正常收发为后续通信打好基础。1.2 四次挥手连接管理与理解 TIME_WAIT 状态一般应用层调用 close 时就是告诉系统本端不再发送新数据了可以发送 FIN 请求断开连接了。假如 A 和 B 通信如果 A 调用了 close系统就会发送标志位 FIN1 的报文之后 A 进入 FIN_WAIT_1 状态B 收到后就知道 A 不再发送数据了之后给予回应并进入 CLOSE_WAIT 状态A 收到这个回应后进入 FIN_WAIT_2 状态。如果 B 还有数据要发送那么它就不会立刻发送 FIN而是等数据发送完毕之后再发送 FIN进入 LAST_ACK 状态等待 A 的回应而 A 收到 B 的 FIN 请求后会发送回应然后进入 TIME_WAIT 状态等这个 TIME_WAIT 状态结束之后才会真正把连接关闭而 B 则是要得到回应才会关闭连接。只有进入 CLOSED 才会把这个连接结构体真正从内核中删掉之前的状态改变只是修改了这个结构体里面对应的属性而已。发送 FIN 之后只是说本端没有新数据要发送了只是关闭了从 A 到 B 这个方向的通道从 B 到 A 这个方向的通道没有关闭所以 A 还可以接收 B 发来的数据这就是 TCP 的半关闭机制。在最后一次 ACK 之前的报文丢了之后都可以因为对方没有收到回应而通过超时重传机制重新发送但是最后一次 ACK 的可靠性需要额外保障它丢了应该怎么办所以首先发出 FIN 的一方在发出最后的 ACK 之后会进入一个 TIME_WAIT 状态这个 TIME_WAIT 状态会等待 2MSL 时间等待对方可能重传的 FIN 报文因为如果 ACK 丢了那么对方就会重发新的 FIN 报文主动关闭方收到后重发 ACK 并重新计时如果 2MSL 内没有收到新的 FIN那么就可以认为对方已经正常收到了最后的 ACK。MSLMSL 指的是一个报文能在网络里面的最大生存时间。双方通信因为超时重传等机制肯定会发送很多重复的报文那么那些没有到达对方的报文会去哪里其中“丢失的报文”已经在传输途中被网络丢掉了不存在了而“延迟的旧报文”还在网络或某个路由器里短暂游荡受 TTL 限制TTL 耗尽后也会被丢弃。如果下一次进行通信某个延迟旧报文的源 IP、源端口、目的 IP、目的端口还与之后通信的报文一样那么会不会造成数据的写入错误问题接收方没有接收应该接收的报文而是接收了延迟旧报文这是有可能的序列号机制会降低这种风险但旧报文仍可能落入接收窗口。TCP 协议规范RFC 793最初将 MSL 定义为 2分钟。这是一个理论上的参考基准但允许各系统根据实际情况调整。比如Linux系统它设置的就是30s。设立这个 TIME_WAIT 状态不仅仅是为了处理最后 ACK 丢失后对方重传 FIN 报文的情况也是为了让这次通信中延迟的旧报文在网络里面消失减少上述旧报文干扰后续同四元组连接的问题。主动关闭方等待 2MSL 后进入 CLOSED连接控制块随后释放。主动断开连接方之后会进入 TIME_WAIT 状态而被动断开连接的一方收到应答后是直接断开连接。地址重用/端口复用SO_REUSEADDR 是要改的“选项名”而 opt 1 就是你要给它设的“值”。连起来的意思就是我要把 listenfd 这个套接字的 SO_REUSEADDR 选项设置为 1开启状态。处于 TIME_WAIT 状态时端口号仍然被占据着只有进入 CLOSED、释放掉连接结构体之后这个端口号才会被释放。这就是服务器主动关闭连接后需要等待一两分钟才能再次启动的原因服务器不能随意改端口号这一两分钟对应的就是 2MSL 的等待时间。我们可以通过调用 setsockopt 函数来解决这个问题使用 setsockopt() 设置 socket 描述符的选项 SO_REUSEADDR 为 1表示允许绑定相同的端口号让处于 TIME_WAIT 状态下的端口号可以被直接拿来绑定。四次挥手四次挥手同样需要确认双方的意愿因此包含两次请求FIN和两次响应ACK。三次握手中接收方的响应和请求可以合并成一个报文发送四次挥手中被动断开的一方收到请求后可能还有数据没有发送完因此它会先发送响应ACK继续把剩余数据发送完毕然后再单独发送断开请求FIN。这样被动断开方的响应和请求就分开发送了从而形成了四次挥手。如果服务器上出现大量 CLOSE_WAIT 状态通常说明服务器已收到对端的 FIN 并回复了 ACK但应用层没有及时调用 close或 shutdown关闭 socket导致本端没有继续发送 FIN四次挥手未完成。解决方法是在所有连接结束路径上确保正确关闭 socket加上对应close。今天的分享就到此结束啦,如果对读者朋友们有所帮助的话,可否留下宝贵的三连呢~~让我们共同努力, 一起走下去!