「這就是三次握手啊， 我給你分析一下啊， 這三次握手主要是為了驗證我這邊和縣衙那邊的發信/收信能力沒問題， 這樣就證明連線是通的， 可以正式發貨了。」小結：其實三次握手按照上面的描述就很好理解，只是三次握手我感覺這還是有小概率事件握手失敗的，比如第三次握手的時候，正好對方網路斷開了，那麼此時傳送過去的資料對方是收不到的。不過這種事件可以忽略。不然你想，不管進行多少次握手，都是存在可能性出現連線不上的情況的。第一次握手：京城發信，縣衙收到了，此時縣衙就會明白：京城發信能力和自己的收信能力是沒問題的。
第二次握手：縣衙發信，京城收到了，此時京城就會明白：京城的發信和收信都是好的， 縣衙的發信和收信也都是沒問題的。 要不然收不到縣衙的回信 ， 但是縣衙還不知道自己的發信功能如何？所以需要第三次握手：
第三次握手：京城發信，縣衙收到了，此時京城已經確認，雙發的收信，發信都是沒問題的， 這次回應的目的只是消除縣衙對自己的發信功能和京城的收信功能的擔憂而已。
當然，可以說現在計算機的基石就是電訊號來實現的，雖然電訊號很快，但是還是存在較大的延時。聽說過一種量子計算機，是通過量子方面的規律實現的，乙個粒子對中的任意乙個粒子變換的狀態，另乙個粒子也會即時更新狀態。如果使用這種理論真正的創造出了量子計算機。我感覺就太牛了！
郵差說： 「隨便你了， 反正你是告不贏的， 這是內閣首輔大人確定的， 我們用的叫滑動視窗協議， 如果視窗n=1 , 即發乙個等著確認乙個， 那樣就太慢了， 我這個郵差也不能一直被你占用， 我們把n的值設大一點， 例如n=3, 就是為了能夠像流水線那樣做事, 一邊發包裹， 一邊收確認， 這樣快一點。」其實第一次從書本上去理解滑動視窗協議的時候，完全是一頭霧水，不過通過老劉這種**，其實就好理解一些了。說到底滑動視窗的協議就是為了讓傳送速度與成功率達到乙個合適的程度。
這就是所謂的虛電路， 綠色部分為連線通道， 所有的訊息都從同乙個通道上傳送
虛電路，就想象成乙個想象中的電路吧。從模擬來看的話，虛電路的缺點就是太浪費資源了。因為需要資源去維護這樣乙個電路。
不過這倒是乙個有意思的思路， 不需要事先建立真正的連線通道， 每個編號小塊走的路可能也不一樣， 完全由中間節點的衙役們來決定馬匹的下乙個路徑是哪乙個虛電路的特點是需要維護一條虛擬的電路，作為一條安全的連線通道， 通訊時資料從這條虛擬的電路中通過。而分組交換（這裡的分組，我看有的書上解釋為資料報）則沒有維護什麼安全通道，而是採用了失敗重傳的方式。即在傳輸資料報的時候，過程中是有路由器覺得選擇哪種路徑去傳輸的。
其實失敗重傳機制的原理也很簡單，就是在傳送資料報的時候，可以將資料報分解為幾份，然後每份在傳輸的時候會有乙個超時時間。且分組傳遞的時候，使用視窗滑動協議來解決速率的問題。
讀碼農翻身之作業系統
1 基本流程 程式首先儲存在硬碟中，當被作業系統裝載後，進入記憶體，然後被cpu執行。2 作業系統裝載程式的流程 a 虛擬記憶體 每個程式可能會認為自己有較大的 如3g 的記憶體，而實際上並不是就分配給了你3g的物理記憶體，而是虛擬記憶體。虛擬記憶體中使用頁表把 在硬碟中的位置記錄下來，等真正需要執...
讀碼農翻身之MVCC 多版本併發控制
多版本併發控制要解決的問題，其實就是基於可重複讀的情況下，可以在讀的時候不用加鎖，也可以實現可重複讀。可重複讀的流程如下所示 小強在讀取b的資訊時候，需要加鎖 1 假設資料庫中有一張users的表，裡面有如下一行資料 2 先給這行資料新增兩個隱藏的字段 其中事務id表明這行資料是哪個事務操作的。事務...
讀碼農翻身之加鎖還是不加鎖，這是乙個問題
首先，就我個人的意見，實際工作中，如果介面只涉及到資料的查詢，我感覺是沒有必要加鎖的，只有那些涉及到資料的更新時，才考慮加鎖。1 樂觀鎖和悲觀鎖 上一章我們討論到了自旋鎖以及其優化的各種鎖，從某種意義上來說，由於這種鎖是以共享變數一定會被執行緒同時修改這種悲觀的想法設計的，所以有些地方稱之為悲觀鎖，...