易县做网站,中装建设集团有限公司董事长是谁,网站美工做专题尺寸多少,如何在网站做文档资料#x1f351;个人主页#xff1a;Jupiter. #x1f680; 所属专栏#xff1a;Linux从入门到进阶 欢迎大家点赞收藏评论#x1f60a; 目录 连接管理机制三次握手三次握手的目的三次握手的步骤第一次握手第二次握手第三次握手注意#xff1a; 为什么建立连接是三次握手个人主页Jupiter. 所属专栏Linux从入门到进阶 欢迎大家点赞收藏评论 目录 连接管理机制三次握手三次握手的目的三次握手的步骤第一次握手第二次握手第三次握手注意 为什么建立连接是三次握手而不是一次两次或则四次确保双方通信能力防止失效连接请求为什么不是一次或两次握手为什么不是四次或更多次握手 四次挥手第一次挥手第二次挥手第三次挥手第四次挥手 为什么需要四次挥手服务端状态转化 理解 TIME_WAIT 状态理解 CLOSE_WAIT 状态 连接管理机制
在正常情况下, TCP 要经过三次握手建立连接, 四次挥手断开连接
三次握手 三次握手的目的
三次握手的主要目的是确保客户端和服务器之间的连接是可靠的即双方都能确认自己与对方的发送与接收功能是正常的。
三次握手的步骤
第一次握手
客户端客户端向服务器发送一个SYN同步序列编号报文段并将SYN标志位置为1。同时客户端随机生成一个初始序列号seqx将其放在TCP报文段的序列号字段中然后发送给服务器。此时客户端进入SYN_SENT同步已发送状态。服务器服务器收到客户端的SYN报文段后确认客户端请求建立连接。
第二次握手
服务器服务器将自己的SYN标志位置为1表示同意建立连接。同时服务器将ACK确认标志位置为1表示确认收到客户端的SYN报文段并将确认号设置为客户端的序列号加1即ackx1。此外服务器也随机生成一个自己的初始序列号seqy并将其放在TCP报文段的序列号字段中然后发送给客户端。此时服务器进入SYN_RCVD同步收到状态。客户端客户端收到服务器的SYNACK报文段后确认服务器已经准备好建立连接。
第三次握手
客户端客户端将ACK标志位置为1表示确认收到服务器的SYN报文段。同时客户端将确认号设置为服务器的序列号加1即acky1并将自己的序列号设置为seqx1因为客户端已经发送了一个SYN报文段所以序列号需要加1。然后客户端将ACK报文段发送给服务器。此时客户端进入ESTABLISHED已建立连接状态。服务器服务器收到客户端的ACK报文段后确认客户端已经准备好进行数据传输。此时服务器也进入ESTABLISHED状态完成三次握手连接建立。
注意 只有监听listen了服务器才允许受理 SYN连接请求。 connect只是发起了三次握手 accept不参与三次握手如果三次握手没有完成accept会阻塞accept只是三次握手结束后才会返回 三次握手不能保证100能建立好连接而是经历了三次握手客户端与服务端都认为建立好连接了。
当客户端将最后一个ACK发出去的时候并且这个ACK是没有应答的客户端就认为连接已经建立好了。但是在客户端发送了ACK之后可能会出现一些原因导致服务端没有建立好连接这个时候服务端就会给客户端发送RST报头让其关闭连接并且重新三次握手。
所谓的连接重置就是让双方重新进行三次握手。
为什么建立连接是三次握手而不是一次两次或则四次
确保双方通信能力
第一次握手客户端发送一个SYN报文给服务器表示请求建立连接并随机生成一个序列号seq。这一步主要是让服务器知道客户端有发送数据的能力并且准备好接收服务器的响应。第二次握手服务器收到客户端的SYN报文后回复一个SYNACK报文。其中ACK表示确认收到客户端的SYN报文ackseq1SYN表示服务器也请求建立连接并随机生成一个序列号seq2。这一步让客户端知道服务器有接收数据的能力并且也准备好接收客户端的确认。第三次握手客户端收到服务器的SYNACK报文后回复一个ACK报文其中ACK表示确认收到服务器的SYN报文ackseq21。这一步是让客户端和服务器都确认对方已经准备好进行通信从而确保双方的数据发送和接收能力都正常。
防止失效连接请求
三次握手还可以有效防止已失效的连接请求报文段被误认为是新的连接请求。例如如果客户端发送的SYN报文在网络中丢失那么客户端会重新发送SYN报文。此时如果服务器收到了两次SYN报文而只回复了一次SYNACK报文那么客户端就无法确定哪个SYN报文被成功接收并回复从而可能导致连接建立失败或混乱。而三次握手机制通过要求客户端对服务器的SYNACK报文进行确认可以确保连接建立的准确性。
为什么不是一次或两次握手
一次握手无法确认双方的通信能力也无法防止失效的连接请求。并且如果一个客服端一直给服务端发送连接请求会造成SYN洪水攻击。 两次握手虽然可以确认服务器的接收能力和客户端的发送能力但无法确认客户端的接收能力。这可能导致服务器发送大量数据给客户端而客户端由于某些原因如网络故障无法接收或确认这些数据从而造成资源浪费和连接混乱。
为什么不是四次或更多次握手
四次其实三次握手实际上也是四次握手只是第中间一次是捎带应答或更多次握手虽然可以进一步增加连接的可靠性但也会增加连接的建立时间和复杂度。TCP协议设计时需要在可靠性和效率之间做出平衡。三次握手已经足够确保连接的可靠性和准确性同时也不会引入过多的开销和复杂度。
四次挥手 TCP的四次挥手是TCP连接释放的过程用于终止客户端和服务器之间的连接。这个过程确保了双方都能正确地关闭连接并释放资源避免了数据丢失或资源泄露。以下是TCP四次挥手的详细过程
第一次挥手
发起者客户端 动作客户端发送一个FINFinish报文段给服务器用来关闭客户端到服务器的数据传输。FIN报文段的标志位FIN被设置为1表示客户端已经没有数据要发送给服务器了。 状态变化客户端进入FIN_WAIT_1状态等待服务器的确认。
第二次挥手
接收者服务器 动作服务器收到客户端的FIN报文段后发送一个ACK报文段给客户端确认收到了客户端的关闭连接请求。ACK报文段 的确认号被设置为收到的FIN报文段的序号加1表示服务器已经准备好接收客户端关闭连接的请求。 状态变化服务器进入CLOSE_WAIT状态表示服务器已经同意关闭连接但还需要完成一些清理工作如发送剩余的数据。同时客户端收到服务器的ACK报文段后进入FIN_WAIT_2状态继续等待服务器的关闭连接请求。
第三次挥手
发起者服务器 动作当服务器完成所有数据的发送后包括可能的剩余数据它会向客户端发送一个FIN报文段用来关闭服务器到客户端的数据传输。FIN报文段的标志位FIN被设置为1表示服务器也没有数据要发送给客户端了。 状态变化服务器进入LAST_ACK状态等待客户端的确认。
第四次挥手
接收者客户端 动作客户端收到服务器的FIN报文段后发送一个ACK报文段给服务器确认收到了服务器的关闭连接请求。ACK报文段的确认号被设置为收到的FIN报文段的序号加1表示客户端已经准备好关闭连接。 状态变化客户端在发送完ACK报文段后会进入TIME_WAIT状态等待一段时间通常是2MSL即两倍的最大报文段生存时间以确保服务器已经完全关闭连接。服务器在收到客户端的ACK报文段后会关闭连接进入CLOSED状态。客户端在等待时间结束后如果没有收到任何来自服务器的报文段也会关闭连接进入CLOSED状态。
为什么需要四次挥手 TCP连接是全双工的即数据可以在两个方向上同时传输。因此每个方向上的连接都需要独立关闭。这就是为什么需要两次FIN报文一次来自客户端一次来自服务器和两次ACK报文一次确认客户端的FIN一次确认服务器的FIN的原因。 确保数据可靠传输四次挥手过程中的每次报文交换都是对之前动作的确认。例如客户端发送FIN报文后等待服务器的ACK报文确认服务器发送FIN报文后也等待客户端的ACK报文确认。这种确认机制确保了数据的可靠传输直到连接完全关闭。 释放资源四次挥手过程还负责适当地释放在建立连接时分配的资源如端口号、内存缓冲区等。这是确保系统资源得到有效利用和管理的重要步骤。 关闭顺序的灵活性任一端客户端或服务器都可以主动发起关闭连接的请求。这种双向的关闭过程确保双方都同意关闭并且各自的数据传输都已经结束。
注意
当客户端给服务端发送FIN报文请求断开连接时如果服务端也正好有断开连接的意图并且服务端此时已经没有数据需要发送给客户端了那么服务端可能会采取“捎带应答”的方式将ACK报文和自身的FIN报文合并发送从而实现TCP连接的三次挥手过程。
第一次挥手后客户端已经把文件描述符关闭了那么后面服务端向客户端发送应答客户端怎么知道的呢
在TCP的四次挥手过程中客户端和服务端之间的通信是通过TCP连接来维持的这种连接状态在操作系统层面由TCP/IP协议栈管理。当客户端决定关闭连接时它会发起第一次挥手FIN包但此时客户端可能并没有完全关闭其TCP连接即TCP状态机可能还未到达CLOSED状态特别是如果客户端的TCP栈还在等待服务端的确认ACK时。
系统中有系统调用可以实现把一个文件描述符 设置只将写/读/读写 关闭。
完整流程图 服务端状态转化
[ CLOSED - LISTEN ] 服务器端调用 listen 后进入 LISTEN 状态, 等待客户端连接;[ LISTEN - SYN_RCVD ] 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端发送 SYN 确认报文.[ SYN_RCVD - ESTABLISHED ] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED 状态, 可以进行读写数据了.[ ESTABLISHED - CLOSE_WAIT ] 当客户端主动关闭连接(调用 close), 服务器会收到结束报文段, 服务器返回确认报文段并进入 CLOSE_WAIT;[ CLOSE_WAIT - LAST_ACK ] 进入 CLOSE_WAIT 后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用 close 关闭连接时, 会向客户端发送FIN, 此时服务器进入 LAST_ACK 状态, 等待最后一个 ACK 到来(这个 ACK 是客户端确认收到了 FIN)[ LAST_ACK - CLOSED ] 服务器收到了对 FIN 的 ACK, 彻底关闭连接.
客户端状态转化:
[ CLOSED - SYN_SENT ] 客户端调用 connect, 发送同步报文段;[ SYN_SENT - ESTABLISHED ] connect 调用成功, 则进入 ESTABLISHED 状态, 开始读写数据;[ ESTABLISHED - FIN_WAIT_1 ] 客户端主动调用 close 时, 向服务器发送结束报文段, 同时进入 FIN_WAIT_1;[ FIN_WAIT_1 - FIN_WAIT_2 ] 客户端收到服务器对结束报文段的确认, 则进入 FIN_WAIT_2, 开始等待服务器的结束报文段;[ FIN_WAIT_2 - TIME_WAIT ] 客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出 LAST_ACK;[ TIME_WAIT - CLOSED ] 客户端要等待一个 2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会进入 CLOSED 状态.
理解 TIME_WAIT 状态
现在做一个测试,首先启动 server,然后启动 client,然后用 Ctrl-C 使 server 终止,这时马上再运行 server, 结果是: 这是因为,虽然 server 的应用程序终止了,但 TCP 协议层的连接并没有完全断开,因此不能再次监听同样的 server 端口. 我们用 netstat 命令查看一下: TCP 协议规定,主动关闭连接的一方要处于 TIME_ WAIT 状态,等待两个MSL(maximum segment lifetime)的时间后才能回到 CLOSED 状态。 我们使用 Ctrl-C 终止了 server, 所以 server 是主动关闭连接的一方, 在TIME_WAIT 期间仍然不能再次监听同样的 server 端口; MSL 在 RFC1122 中规定为两分钟,但是各操作系统的实现不同, 在 Centos7 上默认配置的值是 60s; 可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看 msl 的值; 想一想, 为什么是 TIME_WAIT 的时间是 2MSL? TCP协议中的TIME_WAIT状态持续时间为2MSL两倍的最大段生存时间这一设计是为了确保数据包的可靠传输以及连接的正确终止。具体原因如下 确保所有数据包在网络中消失 在TCP连接关闭过程中可能存在一些尚未到达目的地的旧数据包。这些数据包可能由于网络延迟、路由循环或其他原因而滞留。等待2MSL的时间可以确保这些数据包在网络中超时并被丢弃从而避免它们干扰新的连接。 确保最后一个ACK报文段被正确接收 当连接的一方发送最后一个ACK报文段后这个ACK可能会在网络中丢失。如果接收方没有收到这个ACK它将重新发送FIN报文段。发送方必须等待足够长的时间以确保接收方收到了ACK并且不会重新尝试关闭连接。等待2MSL的时间可以确保发送方有足够的时间重新发送ACK报文段以防接收方没有收到。 防止旧连接的数据包干扰新连接 如果旧的连接没有正确关闭并且新的连接使用相同的四元组源IP地址、源端口、目标IP地址、目标端口建立那么旧的数据包可能会干扰新连接的数据流。等待2MSL的时间可以确保所有旧的数据包已经消失从而避免这种干扰。
解决 TIME_WAIT 状态引起的 bind 失败的方法
在 server 的 TCP 连接没有完全断开之前不允许重新监听, 某些情况下可能是不合理的
服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求.这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量 TIME_WAIT 连接。由于我们的请求量很大, 就可能导致 TIME_WAIT 的连接数很多, 每个连接都会占用一个通信五元组(源 ip, 源端口, 目的 ip, 目的端口, 协议). 其中服务器的 ip 和端口和协议是固定的. 如果新来的客户端连接的 ip 和端口号TIME_WAIT 占用的链接重复了, 就会出现问题.
使用 setsockopt()设置 socket 描述符的 选项 SO_REUSEADDR 为 1, 表示允许创建端口号相同但 IP 地址不同的多个 socket 描述符
理解 CLOSE_WAIT 状态
小结: 对于服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥手没有正确完成. 这是服务器上的一个 BUG大概率是没有正确关闭自己的socket导致。 只需要加上对应的 close 即可解决问题.
