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就再開啟一個計時器-----------如果零視窗探測報文丟失的話，也有一個計時器，這個計時器超時探測報文也會重傳