自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

兩將軍問題和TCP三次握手

網(wǎng)絡(luò) 網(wǎng)絡(luò)管理
本文記錄了兩將軍問題: 對(duì)于不可靠信道,無數(shù)次確認(rèn)都不能百分百達(dá)成可靠共識(shí)。TCP 三次握手是在兩個(gè)方向確認(rèn)包的序列號(hào), 增加了超時(shí)重試, 是兩將軍問題的一個(gè)工程解。

兩將軍問題,又被稱為兩將軍悖論、兩軍問題, 是一個(gè)經(jīng)典的計(jì)算機(jī)思想實(shí)驗(yàn)。

首先, 為避免混淆,我們需要認(rèn)識(shí)到兩將軍問題雖然與拜占庭將軍問題相關(guān),但兩者不是一個(gè)東西。拜占庭將軍問題是一個(gè)更通用的兩將軍問題版本, 通常在分布式系統(tǒng)故障容錯(cuò)、區(qū)塊鏈中廣泛討論也會(huì)猶豫。

1.兩將軍問題

兩支軍隊(duì),駐扎在兩個(gè)山頭,山谷里的同一伙敵人,兩將軍只有同時(shí)發(fā)起進(jìn)攻才能獲勝,兩將軍約定時(shí)間的的唯一方式是派遣信使通過山谷,山谷處于敵占區(qū)。如果信使被俘獲了,那么信息將會(huì)丟失。

現(xiàn)象一:A將軍先派遣信使向 B 將軍傳遞“晚上 10 點(diǎn)一起進(jìn)攻”,但是 A 將軍不知道信使能否穿越敵占區(qū),由于擔(dān)心自己成為唯一進(jìn)攻方,A 將軍可能會(huì)猶豫是否按計(jì)劃進(jìn)攻; 此時(shí) B 將軍收到后可以派遣信使確認(rèn)收到,B的信使也可能被俘獲,由于擔(dān)心A沒有收到確認(rèn)信號(hào)而退縮,B將軍也會(huì)猶豫;再次確認(rèn)也不能解決,因?yàn)樵俅未_認(rèn)的新信使也可能被俘獲。因此交替確認(rèn)是無止盡的。

現(xiàn)象二:將軍A派遣信使,過了很長(zhǎng)時(shí)間未收到回復(fù),將軍A不知道是自己的信使被俘獲了還是將軍B的確認(rèn)信使被俘獲了。

我們意識(shí)到即使雙方不斷確認(rèn)已收到對(duì)方的上一條信息,也無法確保對(duì)方已與自己達(dá)成共識(shí)。

兩將軍問題是無解的,目前的tcp三次握手、四次揮手都是工程解(這個(gè)一會(huì)再聊)。

2.兩將軍問題的頭腦風(fēng)暴

許多人試圖解決/緩解雙將軍問題,提出了一些能落地的實(shí)踐。

這里我們依舊假設(shè)通道的不確定性,信使只會(huì)被俘獲,但是不會(huì)叛變篡改。

2.1 霰彈打鳥

如果A將軍每次派遣100名信使(編號(hào)1到100),期待B將軍最差也能收到一名信使的信息。

B將軍根據(jù)收到的信使數(shù)量,評(píng)估這條通道的可靠性,并根據(jù)概率也派遣合適數(shù)量的確認(rèn)信使。

eg:  A將軍派遣100信使,B將軍收到10名信使的信息,B將軍基本可確認(rèn)這條信道可靠度為10%,B將軍最少應(yīng)派出10名信使(根據(jù)概率會(huì)有1名信使到達(dá)對(duì)岸)。

2.2 間歇性重試

霰彈打鳥的姿勢(shì)太費(fèi)信使了,但至少可幫助B將軍提高信心,達(dá)成共識(shí)。

還有一種少費(fèi)信使(并能提高將軍信心)的策略,假設(shè)跨越山谷到達(dá)對(duì)岸并返回耗時(shí)20min, A將軍可間隔20min派遣信使到對(duì)岸,直到收到對(duì)岸B將軍的首次信使確認(rèn)(就不再派遣)。

以上兩種策略是對(duì)速度和成本的權(quán)衡,采用哪一種取決于哪一種更適合我們遇到的問題。

3. 為什么說tcp三次握手[1]是雙將軍問題的工程解?

圖片

知乎上有個(gè)問題: TCP 為什么是三次握手,而不是兩次或四次?[2]有三個(gè)回答角度。

①TCP 為什么是三次握手,而不是兩次或四次?- 朋克雪球兔的回答 - 知乎[3]

②(TCP 為什么是三次握手,而不是兩次或四次?- 車小胖的回答 - 知乎[4]

③TCP 為什么是三次握手,而不是兩次或四次?- wuxinliulei的回答 - 知乎[5]

希望大家仔細(xì)讀一讀。

首先我們要知道:

三次握手是為了在兩個(gè)方向上同步(syn)序列號(hào)(seq=m),同步一次序列號(hào)需要一去一回兩個(gè)包,倆方向就4個(gè)包。第2,3個(gè)包由一側(cè)發(fā)出可以合并到一起所以最后三個(gè)包。

但是根據(jù)雙將軍問題,誰說一來一回兩個(gè)包就能確保同步成功。

為了緩解雙將軍問題,tcp3次握手增加了超時(shí)重試的機(jī)制。(注意:重試只在信息同步的發(fā)起方)

第一個(gè)包:A發(fā)送給B的SYN中途丟失,沒有到達(dá)B

A會(huì)周期性超時(shí)重傳,直到收到B的確認(rèn)。

第二個(gè)包,即是發(fā)送給A的SYN+ACK 中途丟失,沒有到達(dá)A

B會(huì)周期性超時(shí)重傳,直到收到A的確認(rèn)

第三個(gè)包:即A發(fā)送給ACK 中途丟失,沒有到達(dá)B

A發(fā)完ACK,單方面認(rèn)為tcp Established狀態(tài),而B顯然認(rèn)為tcp為Active狀態(tài)。

a. 假定此時(shí)雙方都沒有數(shù)據(jù)發(fā)送,B會(huì)周期性超時(shí)重傳,直到收到A的確認(rèn),收到之后B的TCP 連接也為 Established狀態(tài),雙向可以發(fā)包。

b. 假定此時(shí)A有數(shù)據(jù)發(fā)送,B收到A的 Data + ACK,自然會(huì)切換為established 狀態(tài),并接受A的 Data。

c. 假定B有數(shù)據(jù)發(fā)送,數(shù)據(jù)發(fā)送不了,會(huì)一直周期性超時(shí)重傳SYN + ACK,直到收到A的確認(rèn)才可以發(fā)送數(shù)據(jù)。

  • https://finematics.com/two-generals-problem/? https://www.bilibili.com/read/cv16604716

總結(jié)

本文記錄了兩將軍問題: 對(duì)于不可靠信道,無數(shù)次確認(rèn)都不能百分百達(dá)成可靠共識(shí)。

TCP 三次握手是在兩個(gè)方向確認(rèn)包的序列號(hào), 增加了超時(shí)重試, 是兩將軍問題的一個(gè)工程解。

    引用鏈接

    [1] tcp三次握手: https://blog.csdn.net/weixin_35942339/article/details/112733885

    [2] TCP 為什么是三次握手,而不是兩次或四次?: https://www.zhihu.com/question/24853633/answer/573627478

    [3] TCP 為什么是三次握手,而不是兩次或四次?- 朋克雪球兔的回答 - 知乎: https://www.zhihu.com/question/24853633/answer/200721662

    [4] (TCP 為什么是三次握手,而不是兩次或四次?- 車小胖的回答 - 知乎: https://www.zhihu.com/question/24853633/answer/115173386

    [5] TCP 為什么是三次握手,而不是兩次或四次?- wuxinliulei的回答 - 知乎: https://www.zhihu.com/question/24853633/answer/63668444

    責(zé)任編輯:武曉燕 來源: 精益碼農(nóng)
    相關(guān)推薦

    2023-10-24 15:22:09

    TCPUDP

    2015-10-13 09:42:52

    TCP網(wǎng)絡(luò)協(xié)議

    2023-09-07 16:46:54

    TCP數(shù)據(jù)傳遞

    2021-04-30 13:32:17

    TCP三次握手網(wǎng)絡(luò)協(xié)議

    2024-10-16 08:38:37

    TCP編號(hào)信息

    2021-01-29 06:11:08

    TCP通信三次握手

    2021-05-18 12:27:40

    TCP控制協(xié)議

    2020-12-08 06:34:16

    TCP握手SYN 報(bào)文

    2019-06-12 11:26:37

    TCP三次握手四次揮手

    2019-05-14 10:09:06

    TCP連接握手

    2017-09-25 21:27:07

    TCP協(xié)議數(shù)據(jù)鏈

    2014-09-19 09:46:46

    TCPIP

    2024-01-12 08:23:11

    TCPACK服務(wù)器

    2021-03-08 18:08:08

    TCP Connect 協(xié)議

    2022-07-25 07:07:35

    TCP客戶端服務(wù)器

    2024-10-09 20:54:16

    2020-06-29 14:50:47

    TCP狀態(tài)ACK

    2021-05-28 09:08:20

    TCP連接序列號(hào)

    2021-07-03 17:47:25

    TCP控制協(xié)議

    2023-10-28 09:07:57

    TCP面試三次握手
    點(diǎn)贊
    收藏

    51CTO技術(shù)棧公眾號(hào)