微信做网站网站郑州网站建设设计

当前位置： 首页 > news >正文

微信做网站网站,郑州网站建设设计,招远网站建设招聘,网站顾客评价目录 四次挥手状态变化 流量控制 PSH标记位 URG标记位 滑动窗口 快重传 拥塞控制 延迟应答 mtu TCP异常情况 四次挥手状态变化 之前我们讲了四次挥手的具体过程以及为什么要进行四次挥手#xff0c;下面是四次挥手的状态变化 那么我们下面可以来验证一下CLOSE_WAIT这…目录 四次挥手状态变化 流量控制 PSH标记位 URG标记位 滑动窗口 快重传 拥塞控制 延迟应答 mtu TCP异常情况 四次挥手状态变化 之前我们讲了四次挥手的具体过程以及为什么要进行四次挥手下面是四次挥手的状态变化 那么我们下面可以来验证一下CLOSE_WAIT这个状态这个状态出现的条件是后调用close的一方比如服务器调用close之前调用完close就进入last_ack我们可以很容易模拟出来直接比如让客户端先调用close不让服务器端调用close即可这样就可以看到这个状态 用指令netstat -natpa表示all 这就证明一件事情如果我们发现服务器上有大量close_wait状态的时候这就意味着大概率我们写的服务器有BUG主要是没有close fd 我们把服务器进程关掉就看不到这个状态了因为进程结束会把所有文件描述符释放掉 我们可以看到图中有一个time_wait的状态对这个就是等待一段时间这个状态实际上是先调用close的一方收到对方的close并给应答后处于的一种状态这个状态通常持续的时间是分钟级别的所以我们也可以较容易的看到 这样虽然服务器进程已经关闭但是这里的端口仍然是被占用的这也就是为什么立即启动服务器会bind err 所以我们的处理方法就是设置地址复用 那么等待的时间是多少呢 TCP协议规定主动关闭连接的一方要处于TIME_WAIT状态等待两个MSL的时间才能回到CLOSED状态 MSL是 Maximum Segment Lifetime报文在网络中最大存活时间我们可以看Linux中它是多长 也就是一分钟所以TIME_WAIT的时间就是两分钟 下面解释一下为什么会等待这么长的时间 1.因为有可能我关闭了服务器后立马又绑定相同的IP和端口这是其实是发给上一次连接的数据由于阻塞在了网络中一段时间现在发到了服务器这样旧报文就会影响新连接 2.或者说四次挥手的最后一次ACK可能会丢如果等待了2个MSL对方没收到ACK就会超时重传这是处于TIME_WAIT的我们就可以重新发ACK。总之就是又重传的机会保证让对方也关闭连接。 流量控制 有下面这样一种场景如果A给B发消息非常快导致B的缓冲区被打满了那么新来的数据就会被丢弃尽管TCP有超时重传机制但是这样其实是不合理的因为发送的数据被丢掉就会白白占用网络资源不仅如此如果A发送的过于慢这也会导致效率低下。 这上面的问题就和我们要说的流量控制有关B可以通过应答ACK报文通告给A自己缓冲区剩余空间的大小那么A就可以选择加快或减慢发送的速度 这里就是B就是通过报头中的16位窗口大小将自己缓冲区的大小通告给A的 那如果B的缓冲区满了A和B就不进行数据交互了那么A是如何知道B什么时候有空间呢 A会向B发送窗口探测B会向A发送窗口更新通知这两种机制是会同时存在的。 PSH标记位 那如果B一直没空间A就会给B发的报头中把PSH标记位 置一当然PSH标记位的应用场景不只是会这么极端就是让B尽快向上交付当然取走缓冲区中的数据取决于应用层这里的意思是应用层调用read的时候不要阻塞即使要读走的内容很少也要尽量读走 URG标记位 这个标记位 置一是指16位紧急指针有效16位紧急指针中存着紧急数据在报文数据中的偏移量广义的指针就是指能找到想要的数据即可这个紧急数据一般是一个字节通常是上层应用层规定好的。 这个大概的应用场景是比如客户端要给服务器上传数据上传到一半不想上传了但是此时服务器TCP缓冲区中还有很多数据这些数据其实都不想上传了有了紧急指针就可以不按序到达TCP协议可以让上层先把带有紧急指针的报文读上去这样就可以停止上传了 滑动窗口 我们之前说过TCP发消息可以串行发就是发一条消息等一个应答但是这样发送效率太低。所以TCP一次发多条报文然后等应答。 那么问题就来了一次发多条这些消息都是无需等待确认应答而可以继续发的数据这个数量是怎么看的呢 其实无需等待应答而可以继续发送数据的最大值就是滑动窗口的大小 我们可以认为滑动窗口就是发送缓冲区的一部分区域这个区域是连续的其中的数据都是暂时不需要应答而可以直接发送的数据 如果不考虑网络情况滑动窗口的大小一般是对方接收缓冲区中剩余空间的大小其实这个数据在三次握手的时候接收方就可以通过报头中的16位窗口大小告诉发送方了 我们可以把滑动窗口认为成下面的样子 其实简单来说要维护一个窗口其实就是维护一段数组空间可以把缓冲区看成char类型的数组只需要两个整型变量即可一个表示窗口开始位置一个表示结束位置。 我们之前说过超时重传机制就是对于已发送但是未收到应答的报文进行保存万一报文丢失触发超时重传我们得找到那个报文其实报文正好就存在于滑动窗口中 并且这个滑动窗口只能是向右滑动可以变大可以变小直至为零。因为滑动窗口的大小就取决于对方接收缓冲区的大小暂时先这样理解后面会说其实跟网络状况也有关系 快重传 为了提高发送笑效率TCP引入了快重传策略就是当收到3个报文中具有同样的确认序号时就会重发滑动窗口的最左边的报文。 因为我们知道确认序号的意义就是确认序号之前的报文全部都收到了接收方之所以会发三个同样的确认序号就是它收到了滑动窗口中间的一些报文但是滑动窗口最左边滑动窗口内的报文没有收到接收方收到报文后必须发确认应答并且确认序号只能是滑动窗口左边滑动窗口外的已经收到的数组下标 如果没有3个呢那就会触发超时重传 所以快重传其实是一个提效的策略而超时重传则是一个兜底的策略 就以为有了上面的策略所以才不会害怕滑动窗口最左侧丢包。 那如果是滑动窗口中间或最右侧丢包呢这种情况其实最终还是转化成最左侧丢包因为收到应答的报文会被分离出滑动窗口 对方在收到一批报文时会发回一批应答报文如果这个应答报文是乱序的呢 1.首先应答报文也是有序号的不用担心乱序问题 2.就算是乱序的比如先收到确认序号是3001后收到2001其实收到3001是就已经能确定2000收到了2001其实就可以直接丢弃了 所以就算一部分应答报文会丢失后面的应答报文也会通告情况所以是允许部分应答报文丢失的这一切还是要归功于确认序号的意义上确认序号之前的报文全部都收到了 接收数据的一方是要对报文进行排序后才能放到接收缓冲区的 我们上面说流量控制其实滑动窗口就是流量控制的具体实现 缓冲区终归是有限的那到头了怎么办我们可以把缓冲区认为成是一个环状结构滑动窗口就在这个环上循环 拥塞控制 我们发送数据看的其实不仅是通信双方的主机还有网络 所以拥塞控制就是用来衡量网络的健康状况的 如果网络拥塞了那么就会导致大面积丢包如果发送量超过拥塞窗口就会导致网络拥塞 什么控制发送量呢就是滑动窗口 每次发送数据包的时候将拥塞窗口和接收端主机反馈的窗口大小作比较取较小的值作为实际发送的窗口 所以滑动窗口的大小就是对方接收能力和拥塞窗口的最小值 拥塞探测和TCP发送数据其实是同时进行的拥塞控制的核心算法其实就是指数级增长因为指数级增长一开始为慢启动不会给拥塞的网络增加太多的压力然后一旦发现网络状况较好就会增长的很快尽快恢复通信但是到了后面又开始比例增长否则指数级增长过快了大致是下面这样 延迟应答 这个意思就是收到数据后先等待一段时间当然这个时间不会超过超时重传的时间就是为了可能上层会取走一部分数据这时就可以向发送方通报更大的接收能力了 mtu Maximum Transmission Unit缩写MTU中文名是最大传输单元。  MTU是 数据链路层 的概念 这个值我们可以通过ifconfig命令看到是1500字节 所以网络中能够传输的最大数据包大小是1500字节 TCP异常情况 如果进程崩溃掉了那么已经建立好连接的双方就会正常进行四次挥手 如果是机器重启导致进程退出同样会执行上面的操作所以有进程时的重启会比没进程时慢一些 如果网线断开或者突然断电那么这方就直接关闭连接了对方会发消息或者由于保活策略发一些试探性报文如果没有应答就会断开连接