鍍金池/ 問答/Linux  網(wǎng)絡(luò)安全/ 關(guān)于TCP三次握手問題的深究

關(guān)于TCP三次握手問題的深究

三次握手的流程和基礎(chǔ)我都知道,各位不用跟我講解基礎(chǔ)概念


問題在于為什么不能進(jìn)行二次握手的問題
1.從客戶端傳送到服務(wù)器的信息在網(wǎng)絡(luò)中延遲了很久才傳到,服務(wù)器接受到消息后,返回確認(rèn)信息,但是此時(shí)客戶端的連接已近關(guān)閉,但服務(wù)器還是一直等待,這樣會造成服務(wù)器資源的浪費(fèi)

這種能理解

2.從客戶端傳送到服務(wù)器的信息在網(wǎng)絡(luò)中延遲了很久才傳到,服務(wù)器接受到消息后,返回確認(rèn)信息,但是客戶端已經(jīng)放棄了第一次的連接,發(fā)送了第二次連接的請求,當(dāng)客戶端收到請求后會認(rèn)為這是第二次請求的確認(rèn),從而建立連接。

好,問題就在這,在發(fā)送連接請求和確認(rèn)連接請求的時(shí)候,我們都會發(fā)送序號和確認(rèn)號,假設(shè)第一次客戶端發(fā)送請求時(shí)的序號為x,那么服務(wù)器返回確認(rèn)信息的包中的確認(rèn)號就應(yīng)該是x+1,那客戶端發(fā)送的第二次連接請求的序號顯然不會為x,假設(shè)為y,那么當(dāng)客戶端收到服務(wù)器返回的確認(rèn)信息中確認(rèn)號為x+1,就應(yīng)該不會建立連接,因?yàn)樗枰却且粋€(gè)確認(rèn)號為y+1的。
那么這第二種問題就不應(yīng)該存在。
本人對tcp的理解只停留在概念上,沒有做過實(shí)際上對于tcp的研究,所以可能有某些地方理解上出現(xiàn)了問題,希望大家能指出。
我覺得可能的答案:
1.客戶端不會對確認(rèn)號進(jìn)行確認(rèn),但是為什么?
2.兩次發(fā)送請求的序號相同(應(yīng)該不可能,隨機(jī)生成的)
3.這種問題不存在

回答
編輯回答
情皺

1 TCP提供可靠的鏈接,兩次握手,客戶端能夠確認(rèn)自己發(fā)給服務(wù)器的數(shù)據(jù)服務(wù)器能收到,自己也能收到服務(wù)器的數(shù)據(jù),但是服務(wù)器并不知道自己發(fā)給客戶端的數(shù)據(jù)客戶端是否能收到,。所以需要三次握手

2、“網(wǎng)絡(luò)中延遲了很久才傳到” ,說明的你的網(wǎng)絡(luò)太爛,TCP握手失敗。需要改進(jìn)網(wǎng)絡(luò)

2018年5月1日 08:22
編輯回答
熊出沒

https://102.alibaba.com/detai... 你可以去看看,希望能幫到你1

2017年2月20日 00:37
編輯回答
墨小白

TCP 基礎(chǔ)待加強(qiáng)。

一般而言,有兩個(gè)地方可區(qū)別不同的 TCP 會話

  1. 序列號
    通常連接雙方的初始序列號是個(gè)隨機(jī)數(shù),而且是不可預(yù)測的。
    例外:在受到 SYN 洪水攻擊時(shí),服務(wù)器可能使用特別數(shù)作為序列號,詳情 https://en.wikipedia.org/wiki...
  2. 客戶端的連接端口
    絕大部分的客戶端使用操作系統(tǒng)分配的動態(tài)(本地)端口,理論上每次連接都不一樣。
2018年5月2日 18:12