主要是tcp拥塞控制还有一些面试题

7.14自己面

es6比较重要

解构赋值

三点运算符

map filter可以用break跳出循环吗为什么：不可以，本来就是迭代方法，如果跳出了就不能处理后续的元素，

vue生命周期 this问题：第一个周期就已经存在了

Css3 transform属性：perspective(n)，为 3D 转换元素定义透视视图。

 

-----牛客上腾讯一面

1. AJAX原理 readystate码的含义

   https://www.cnblogs.com/666666CFH88888888/p/9832401.html这个博客写的很好我就不自己写了

2. 介绍http有什么字段

   1. 请求行：请求方法、请求地址、协议版本等等

   2. 请求头：浏览器的信息，接受的语言格式，等i一下浏览器想发送给服务器的信息

   3. 请求主体：发送数据放在这里

3. 响应报文

   1. 状态行：请求是否成功+状态码

   2. 响应头：服务器的信息+服务器想告诉浏览器的信息

      

   3. 响应体：正常用户看到的内容

4. udp和tcp的区别

   1. udp是无连接的，tcp面向连接传输

   2. udp支持多对一，一对多，一对一，tcp只能有两个 端点一对一通信

   3. udp对应用层交付的报文直接打包，tcp是面向字节流的，就是上层传下来的数据会被分成数据包接收端也不管顺序但是可以还原成发送一模一样的字节流

   4. udp尽最大努力交付不可靠，tcp是可靠传输丢包什么的会进行流量控制和拥塞控制

   5. udp首部小8字节，tcp首部大20-60因为需要控制很多东西

5. https://www.cnblogs.com/tuyang1129/p/12439862.html这篇写的拥塞控制感觉很好，还有b站湖科大教书匠的计算机网络视频，我自己用自己的话在这里再记一下

tcp拥塞控制

1. 起因：主机ab通话，由主机a发送数据给主机b的时候不是直达，而是通过网络中的路由器等等，-----

   路由器先储存这些数据，然后再从中取出，根据数据中的地址转发给下一个离主机b近的路由器或者直接到达主机b-----

   有一个问题就是路由器的内存是有限的，如果同一时间到达的数据太多路由器接受不了就只能丢弃一部分，或者路由器数据本来就多后来的数据就要等很长时间才能转发

   所以网络中数据太多，路由器处理不过来或者太慢就是网络拥塞

2. tcp关于拥塞：因为tcp协议是保证数据完整传输的协议，所以他会重传数据，高频率的重传网络就越来越拥塞

3. 是什么：就是在网络发送拥塞时，减小发送数据的速度同时在网络不堵的时候发快一点，尽量的利用网络资源

4. 控制的方法：

   1. 端到端：由发送端自己判断是否拥塞调整传输速率

   2. 网络辅助：由路由器告诉发送方

      1. 直接向发送方发送报文报告情况

      2. 路由器更改数据中的标志提示拥塞情况，然后数据到达接收端，接收端根据标志在响应报文中包含这个拥塞情况

5. tcp采取第一种方式控制拥塞情况，那就产生问题

   1. 如何判断拥塞

      1. 发送数据后规定时间没有收到回应可以判定堵塞

      2. 发送数据后收到同一条报文的四次确认，可认为丢失-------------这种情况就是根据tcp传输数据的特点：发送12345个数据段，接受端收到1的时候会返回2的确认报文也就是说我收到了2之前的下一次我就想要2了--------收到2之后返回3的确认报文------但是现在3迟迟未到-------4到了储存下来还是返回3的确认---5到了还是如此----然后3才到又发现缓存里面有45就返回6的确认报文表示之前的我都收到了，

         若发送方接收到对同一条报文的三次冗余确认（也就是四次确认），就认为这条报文的下一条已经丢失，于是不管计时器是否超时，都直接重传这条报文的下一条。快速重传的条件发生，发送方将认为出现了拥塞导致丢包。

         所以tcp判断拥塞就是判断有没有丢包

   2. 拥塞之后怎么改变传输速率

      1. 首先tcp传输数据是吧数据分成很多编好号的数据包，而且一次发送不是一个数据段，是在一个窗口区间的编号一起发送，当最早发的数据被确认的时候，窗口就是迁移继续这样发送

      2. 所以限制数据发送速率就是限制窗口大小

      3. tcp程序会有一个拥塞窗口的变量---cwnd，被发送没有收到确认的数据的序号就会在这里，堵塞了就减小这个窗口，没有堵塞就增大

   3. 用啥算法来改变调整窗口大小

      • MSS：最大报文段长度，TCP双方发送的报文段中，包含的数据部分的最大字节数；

      • cwnd：拥塞窗口，TCP发送但还没有得到确认的报文的序号都在这个区间；

      • RTT：往返时间，发送方发送一个报文，到接收这个报文的确认报文所经历的时间；

      • ssthresh：慢启动阈值，慢启动阶段，若cwnd的大小达到这个值，将转换到拥塞避免模式；

        三种模式要相互转换

        例如初始cwnd=1 ssthresh=16

      1. 慢启动

         每传一次数据cwnd成倍增长26816 指数增长

         当cwnd=ssthresh=16的时候就变成拥塞避免

      2. 拥塞避免

         这个时候每传一次数据cwnd+1，线性增长，当cwnd=24的时候如果一直没有接收到回应那可以认为发送拥塞了就会超时重传，这个时候

         ssthresh=cwnd/2=12，cwnd=1重新开始慢启动算法，然后当cwnd=ssthresh=12的时候又开始拥塞避免

         然后假如当cwnd=16的时候，接受到了同一个报文三次重复确认，但是也许并没有发生拥塞所以就启动快重传

      3. 快重传-快速恢复：重传数据时就更新ssthresh=当前cwnd/2=8，而cwnd更新为ssthresh 的值==8，然后开始拥塞避免阶段

6. 流量控制

   1. 原因：数据发送的过快接受放来不及接受会造成数据丢书

   2. 是什么：发送方的发生速率不要太快，接收方来得及接受

   3. 怎么控制：滑动窗口机制，窗口指发送未收到确认的数据段都在这里

      1. 由接收方控制流量，收到的数据会发送确认确认之后发送方的窗口会向前滑动发送接下来的字节

      2. 当接收方没有内存会告诉发送方能接受的字节为0 ，但是这个消息可能会丢失，丢失之后发送方和接收方都会一直等待对方发送数据，会形成死锁

      3. 首先如果接收方收到0字节通知会启动一个持续计时器，计时器超时的话会发送一个0窗口探测报文，接收方收到就会返回自己现在能接受的数据大小，死锁解除，如果还是0就再开启一个计时器-----------如果零窗口探测报文丢失的话，也有一个计时器，这个计时器超时探测报文也会重传