农村网站做移动,o2o网站建设最好公司,网站ip地址是什么,如何做产品众筹网站说一说 TCP 的四次挥手。
挥手即终止 TCP 连接#xff0c;所谓的四次挥手就是指断开一个 TCP 连接时。需要客户端和服务端总共发出四个包#xff0c;已确认连接的断开在 socket 编程中#xff0c;这一过程由客户端或服务端任意一方执行 close 来触发。这里我们假设由客户端…说一说 TCP 的四次挥手。
挥手即终止 TCP 连接所谓的四次挥手就是指断开一个 TCP 连接时。需要客户端和服务端总共发出四个包已确认连接的断开在 socket 编程中这一过程由客户端或服务端任意一方执行 close 来触发。这里我们假设由客户端主动触发 close。四次挥手的流程如图 数据传送完毕之后呢双方都可释放连接。
最开始的时候客户端和服务端都处于 establish 的状态。然后客户端主动关闭服务器被动关闭首先客户端进程发出连接释放报文并且停止发送数据。在该数据报的报头中呢TCP flags 中的 finish 就等于1我们这里假设此时的客户端定义的序列号。为 sequ 该值等于前面 establish 状态下数据最后一次发送的时候。已经传送过来的数据的最后一个字节的序号加上一。此时客户端就进入了 finish wait 1 这么一个终止等待一的状态。TCP 规定。即使并报文段不携带任何数据也要消耗掉一个序号。回执的时候它的义务会加一就像这里。那当我们的服务器收到连接释放报文了之后也要发出确认报文及 ack1。这里作为回应我们的小写的 ack它的 sequence number 也就成为了 u1。并且也携带上了自己的序列号就是我们的这个 seqv。此时服务端就进入了 close wait 这么一个关闭等待的状态。这个状态比较重要大家呢在这里呢先留下一个印象 TCP 服务器通知高层的应用进程客户端要释放跟服务器通信的连接。这时候会处于半关闭的状态即客户端已经没有数据要发送了
但是服务器若要发送数据客户端还是能够接受的。这个状态还要持续一段时间该时间等于整个 close bay 状态所持续的时间那客户端收到服务器的确认请求后也就是第二次挥手的时候呢。此时客户端就进入了 finish wait 2 及终止等待二这个状态。等待服务器发送释放连接报文就是等待它发送第三次回收的请求。因此在这段时间内呢还有可能还需要接受服务器发送的最后的数据服务器将最后的数据发送完毕后呢。就会向客户端呢发送连接释放报文这里就是 finish1 ack 还是等于 u1。由于在半关闭的状态服务器很可能又发送了一些数据此时的序号呢我们就已经变为了 w。此时服务器就进入了 last ack 的这么一个状态了啊在发送这个 finish 报文的时候它就进入了 last ack 及最后确认的状态。等待客户端的最终确认客户端在收到服务器的连接释放报文之后必须发出确认。即 ack1。然后再将服务器发过来的这个 w 变成 w1 回发回去通过这个小 ack 回发回去而自己的序号呢此时我们假定为 u。那么它就是 u1而自己的序号呢也就是按照之前的报文的序号加一就是u1。此时客户端就进入了 time wait。即时间等待的状态注意此时客户端的 TCP 连接还没有释放必须经过二乘上 msl 的时间后呢。我们的这个连接才真正的释放才进入到 close 的状态。MSL 及最长报文段寿命。rfc 793 定义了 msl 的值为两分钟而 linux 设置成了 30 秒而咱们的服务器只要收到了客户端发出的确认。立即就进入 close 的状态了可以看到服务器结束 TCP 的连接时间要比客户端稍早一些。以上便是四次挥手的主要流程。
总结
咱们来总结一下 TCP 采用四次挥手来释放连接在第一次挥手的过程中呢client 向 server 呢发送了一个报文。用来关闭 client 到 server 的数据传送。 client 呢就进入到了 finish wait 1 这么一个状态当中。在第二次挥手的过程中我们的这个 server 在收到了 client 发来的包文之后。会发送一个 ack 给 client并且我们的小写的 ack 及确认序号就是我们之前收到的这个 client 发来的。序号加一。那 server 就会进入到了 close wait 的状态。在第三次挥手的过程中server 又继续向 client 发送了一个 finish 的数据包。用来关闭 server 到 client 的数据传送。server 就进入了到了 last ack 的状态那在第四次挥手的过程中client 在收到 server 发来的 fin 包之后呢client 就会进入到了摊位状态接着发送一个 ack 给 server 确认序号。之前收到的这个 server 序号加上一。这我就进入到了 close 状态那 client 在等待 2 msl 的时间之后也会进入到 close 的状态。从而完成四次挥手。
我们注意到在 TCP 的四次挥手的状态图中从 time wait 到 close 状态有一个超时设置。这个超时设置是二乘上 msl。那为什么需要等待这一段时间为什么不直接给转换成 close 状态主要有两个原因第一个原因呢就是time状态呢它是用来保证有足够的时间让对端收到 ack。如果被动关闭的那方没有收到 ack 呢就会触发被动端重发 finish 包一来一去正好是两个msl。第二点就是有足够的时间让这个连接不会跟后面的连接混在一起因为有些路由器会缓存 IP 数据包。如果连接被重用了那么这些延迟收到的包呢就有可能会跟新连接混在一起
那咱们为什么需要四次回收来中断连接呢前面我们说过全双工的意思是允许数据在两个方向上同时传输及待同一时间服务器可以发送数据给客户端客户端也可以发送数据给服务器。而因为 TCP 是全双工的所以发送方和接收方都需要 finish 报文和 ack 报文也就是说。发送方和接收方各只需两次挥手即可只不过有一方是被动的所以看上去就成了所谓的四次挥手。
TCP滑动窗口
面试过程中经常会被问到TCP 的滑动窗口想要回答这个问题咱们先来弄清楚两个 TCP 概念。那就分别是RTT和RTO。
RTT和RTO
RTT发送一个数据包到收到对应的ACK所花费的时间RTO重传时间间隔
再通俗的讲就是我一开始预先算一个定时器时间如果你回复了 ack那重传定时器就自动失效也就是说不用重传了。如果没有回复给我 ack然后 RTO 定时器的时间又到了我就重传由于 RTO 是本次发送当前数据包所预估的超时时间。那么 RTO 就需要一个很好的算法来统计来更好的预测这次的超时时间。RTO 不是固定写死的配置而是经过 RTT 计算出来的。有了 RTT 才能计算出 RTO。基于 RTO我们便有了重传机制才能支撑起咱们接下来要介绍的滑动窗口。
TCP使用滑动窗口做流量控制和乱序重排
保证TCP的可靠性保证TCP的流控特性
前面我们了解到 TCP 会将数据拆分成段进行发送出于效率和传输速度的考虑我们不可能等一段一段数据去发送等到上一段数据被确认之后再发送下一段数据。这个效率呢是非常低的。
我们是要实现对数据的批量发送。TCP 必须要解决可靠传输以及包乱序的问题。所以 TCP 需要知道网络实际的数据处理带宽或是数据处理速度这样才不会引起网络拥塞导致丢包。TCP 使用滑动窗口及 sliding window 呢做流量控制与乱序重排 TCP 的滑动窗口主要有两个作用。 第一个作用是提供 TCP 的可靠性第二个作用是提供 TCP 的流控特性。前面咱们学习的 TCP 报文头里面呢有一个字段叫做 window 我们也可以叫做 advertise window用于接收方通知发送方自己还有多少缓冲区可以接收数据发送方根据接收方的处理能力来发送数据不会导致接收方处理不过来。这便是流量控制同时滑动窗口机制还体现了 TCP 面向自节流的设计思路。咱们来大致了解一下窗口有关数据的计算过程。
窗口数据的计算过程 如图所示左图是 TCP 协议的发送端缓冲区而右图是接收端缓冲区。左边往右边发数据两个图中下面的长方形表示要发送的数据流里面假设装满了数据并且需要按照顺序从左向右发送或者接收。咱们假设对应的数据段位置序号也是从左到右去增长的对于发送方来讲呢lastbyetacked指向收到的连续最大的 ack 的位置也就是从左端算起连续已经被接收端的程序呢发送 ack 回执确认已收到的这个 sequence number。而 lastbytesend 呢指向已发送的最后一个字节的位置该位置呢只是发出去了但是还没有收到 ack 的回应而 last byWritten指向上层应用已写完的最后一个字节的位置及当前程序已经准备好的需要发送到最新的一个数据段这段是发送出去但是还没有收到确认的这段呢是已经发送出去并且已经收到接收端的确认了的我们可以看到从 lastbyeack到 lastbywritten都是没有出现间隔的都是连续的对于接收方来讲 last by read 指向上层应用已经读完的最后一个字节的位置也就说我收到了发送方的数据。并且已经处理并且给他回执了的数据的最后一个位置 而 Next by expected 指向收到的连续最大的 sequence 的位置。比如说这段呢我是已经收到了但是还没有给你发送回执而 last by receive 呢是指向已收到的最后一个字节的位置。可以看到 next by expected 和 last by receive 中间呢有一些 sequence 还没有到达对应的是空白的区域。此时咱们可以根据上面的数值计算出接收方的 advertise window 的大小 之后呢回发给发送方让其计算出。发送方的剩余可发送的数据大小及 effective window 的大小一个是 advertise window就我能够接受的窗口一个是你还可以发送的数据及effective window。此时我们的 advertise window 及接收方还能处理的数据的量是可以通过这个公式来计算的其中 max receive buffer是指接收方能接收的最大数据量也可以理解为接收端缓存池的大小。而 last by receive-last by read 就表示的是我们当前接收方已未接收到的数据或者还没有接收到的.
TCP会话的发送方 滑动原理如图所示了我们先从原滑动窗口来说起它是虚线部分组成。前面我们已经知道滑动窗口里面包含了已经发送但是还没有收到接收端的确认的数据以及还没有发送但是允许向接收方发送的数据咱们假设原先的滑动窗口的边界呢是从 32 到 51。我们假设已发送但未被确认的序号呢是 32 到 40。此时如果 32 和 33 都没有被确认而 34 被确认的。咱们的这个窗口也不会向右滑动只有等到 32 到 34 都被确认之后及连续被确认之后滑动窗口才会被移动。那在此时没被移动之前咱们需要大于或者等于 52 的数据及窗口外的数据是不能被发送的。此时我们假设从 32 到 35 都被确认了只要滑动窗口会向右移动四位到 36 这个位置的地方。进而我们的程序就能发送后面的 52 到 55 的数据了。对于 TCP 的接收方来讲在某一时刻在它的接收缓存内呢会存在三种状态。
第一种状态是已接收并且已发送回执的状态。第二种是未接收但是可以接收也就是准备接收的这种状态。第三个是未接收并且不能接收的状态因为达到了窗口的预值了是不能接收的。那由于 ack 直接由 TCP 站回复默认没有应用延迟不存在已接收但是未回复 ack 的这种状态。其中未接收并且准备接收的这一段空间呢就称为接收窗口了。由于接收窗口的滑动机制和前面发送方的一致这里我们就不做重复讲解了。
TCP会话的接收方 经过上面的讲解我们得知 TCP 最基本的传输可靠性来源于确认重传机制。 TCP 的滑动窗口的可靠性也是建立在卷重传基础上的。发送窗口只有收到接收端对于本段发送窗口内字节的 ack 确认才会移动发送窗口的左边界。接收窗口只有在前面所有的段都确认的情况下才会移动左边界当在前面还有字节未接收。但收到后面的字节的情况下呢窗口是不会移动的并不对后续字节确认以此确保对端。会对这些数据呢进行重传。以上便是滑动窗口的基本原理滑动窗口的大小可以依据一定策略动态调整。应用会根据自身的处理能力的变化通过本端 TCP 接收窗口大小的控制来实现对端的发送窗口进行流量限制。 如果本文对你有帮助可以关注我第一时间获取更多精彩文章。读者小伙伴也可以在我的个人网站程序员波特获取更多Java相关技术系列教程共享电子书、Java学习路线、视频教程、简历模板和面试题等学习资源。
