先介紹擁塞控制的基本條件：
在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路效能就要變壞，這種情況叫做擁塞。在計算機網路中的鏈路容量（即頻寬）、交換節點中的快取和處理機等，都是網路資源
若出現擁塞而不進行控制，整個網路的吞吐量將隨輸入負荷的增大而下降。
好吧，一本正經果然不適合剛開始想學習的人。舉個例子：交通十字路口是有紅路燈的，如果沒有按照大部分中國司機的習慣就是往死裡擠，然後道路只有那麼寬，車子擁擠的越來越多，自然交通就癱瘓了，這裡可以理解為擁塞了。所以要保持道路暢通就需要控制，所以就有了紅綠燈，也就是要進行擁塞控制。
再用個**釋下理想的擁塞控制是如何的： 輸入負載：單位時間內輸入網路的吞吐數量
吞吐量：單位時間內從網路輸出的吞吐數量。
剛開始時，吞吐量等於網路輸入的負載，所以曲線呈45度上公升，隨著網路輸入負載的增多超過某一限度時。由於網路資源受限，吞吐量不再增長而保持水平線，也就是吞吐量達到飽和。同時也說明輸入的負載有一部分丟失掉了（在分組的丟失使擁塞的預兆），例如輸入到網路中的某些分組被某個節點丟棄了，雖然如此在理想的擁塞控制下，網路的吞吐量維持到可達到的最大值。四種tcp擁塞控制演算法：滿開始演算法、擁塞避免演算法、快重傳、快恢復。
下面介紹四種擁塞控制演算法的基本原理，為了更好的理解擁塞控制演算法的使用。假設如下條件：
1、資料是單方向傳送，而另乙個方向只傳送確認。
2、接收方總是有足夠大的緩衝空間，因而傳送方傳送視窗的大小由網路擁塞程度來決定。
3、以tcp報文段的個數來討論問題單位，而不是位元組。
慢啟動呈指數增長。達到慢開始門限值之後開始使用擁塞控制演算法——線性加1。
直到傳送方接受到的報文段小於自身傳送的報文時，報文中途丟失了，重傳計時器超時，這個時間則會判斷出現了擁塞。
整個過程如下圖：
這裡再思考一下，慢開始和擁塞避免演算法會不會有侷限性。首先以報文丟失就作為擁塞的預兆好像不太合理，萬一只是途**現了意外而不是擁塞導致的呢，那麼這裡重新執行滿開始演算法會不會導致效率降低了。所以針對這種情況，後期提出了兩個新的擁塞控制演算法（改變tcp的效能）——快重傳和快 恢復。用來解決誤以為網路發生擁塞的情況。
慢開始和擁塞避免演算法侷限性：有時，個別報文會在網路中丟失，但實際網路並未發生擁塞。
這將導致傳送發超時傳送，並誤以為網路發生了擁塞；
傳送發錯誤的啟動慢開始演算法，並把擁塞視窗cwnd又設定為最小值1，因為降低了效率。
快重傳演算法：讓傳送發盡早知道發生了個別報文段的丟失。
所謂的快重傳，就是使傳送方盡快重傳，而不是等待超時重傳計時器超時再重傳。
要求接收方不要等待自己傳送資料時在進行捎帶確定，而是要立即傳送確認；
即使收到了失序的報文段也是立即發出對方收到的報文段的重複確認；
傳送方一旦收到三個連續的重複確認，就將相應的報文段立即重傳，而不是等待該報文段的超時重傳計時器超時再重傳。
具體過程見下圖：
整個擁塞控制流程就是這樣，是不是發現也就那麼一回事。
Dockerfile看這篇就夠了
dockerfile是用來構建docker映象的構建檔案，是由一系列命令和引數構成的指令碼。構建三步驟 1.編寫dockerfile檔案 2.docker build 3.docker run 1 每條保留字指令都必須為大寫字母且後面要跟隨至少乙個引數 2 指令按照從上到下，順序執行 3 表示注釋 ...
Git 學習看這篇就夠了！
git是乙個開源的分布式版本控制系統，可以有效 高速的處理從很小到非常大的專案版本管理。可能新手會問 git和github有什麼關係啊？git是乙個版本控制工具 github是乙個用git做版本控制的專案託管平台 git 和github的關係 git的使用也是實際開發工作中不必可少的 必須熟練掌握的...
入門Webpack，看這篇就夠了
參見 需要注意的是 1.npm install g webpack 全域性安裝 2.npm init 建立package.json 3.建立webpack.config.js 4.因為是全域性安裝，所以打包檔案只需在終端執行 webpack 命令 我之前的錯誤之處在於我是先全域性安裝的，然後又按照文...