关于 TCP 中的三次握手

TCP

握手

可靠

可不可以

27 replies • 2019-07-17 10:28:01 +08:00

BBCCBB

Jul 16, 2019

1

TCP 为什么是三次握手，而不是两次或四次？ - HioHio 的回答 - 知乎
https://www.zhihu.com/question/24853633/answer/573627478

特么百度一下就有的东西，你还发上来

BBCCBB

Jul 16, 2019

2

双方需要协商初始序列号，肯定需要 ack，所以三次是必要的

v2byy

OP

Jul 16, 2019

3

@BBCCBB 哈哈，我发现我还看过知乎上的这个问题

v2byy

OP

Jul 16, 2019

4

@BBCCBB 但是在前两次握手中，双方都已经将 seq 发给对方了啊

cjpjxjx

Jul 16, 2019 via iPhone

2

5

三次握手：
“喂，你听得到吗？”
“我听得到呀，你听得到我吗？”
“我能听到你，今天 balabala ……”

两次握手：
“喂，你听得到吗？”
“我听得到呀”
“喂喂，你听得到吗？”
“草，我听得到呀！！！！”
“你 TM 能不能听到我讲话啊！！喂！”
“……”

四次握手：
“喂，你听得到吗？”
“我听得到呀，你听得到我吗？”
“我能听到你，你能听到我吗？”
“……不想跟傻逼说话”

作者：匿名用户
链接： https://www.zhihu.com/question/24853633/answer/114872771
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

CEBBCAT

Jul 16, 2019

6

实践了多少年的东西，不是不让你提问，实在是人总是觉得自己想到了别人没想到的事儿。

积极探索很好啊，但不经思考和验证就发到网络上浪费大家时间就不好了

v2byy

OP

Jul 16, 2019

7

@cjpjxjx 例子里的两次握手，是指有包丢了的情况。如果假设链路可靠，不会丢包呢？

BBCCBB

Jul 16, 2019

8

发给对方不代表对方收到了。所以需要 ack 确认！ 5 楼那个答案不可信。。。

mansurx

Jul 16, 2019

1

9

是时候拿出这张祖传老图了。

关于握手次数，楼主可以看下 QUIC 协议~

azh7138m

Jul 16, 2019

2

10

S ———- syn ————> C
S < —— syn&ack ———— C
S ————- ack —————> C

> 假设链路很可靠

ack 啥，直接发就是了，重新发明 UDP ？

goofool

Jul 16, 2019

11

假设不成立

kljsandjb

Jul 16, 2019 via iPhone

12

为了保证双方的收发能力都没问题

taogen

Jul 16, 2019 via Android

13

三次握手和可靠数据传输没有任何关系。三次握手是建立连接，可靠数据传输是由传输层和链路层相关算法实现。

pagxir

Jul 16, 2019 via Android

14

TCP 设计的一个目的就是运行在不可靠链路之上的。。。

xfriday

Jul 16, 2019

2

15

没有第三次握手，可以伪造源 ip 的

v2byy

OP

Jul 16, 2019

16

@azh7138m 链路可靠，也需要拥塞控制啊，要考虑双方的收发能力吧

v2byy

OP

Jul 16, 2019

17

@taogen 正如上面回答的，握手协商双方的 seq，如果没有 seq 号，链路层收到差错包，将之丢弃，就是通过 seq 来重传的，我觉得还是有关系的。

lhx2008

Jul 16, 2019 via Android

18

@v2byy 链路绝对可靠就不需要拥塞控制，链路也是可靠的，所以不存在绝对可靠的链路

zivyou

Jul 16, 2019

19

@lhx2008 链路绝对可靠也是需要拥塞控制的吧。发送方滑动窗口大小必须要考虑接收方的接收能力，不然包会被接收方丢弃。

OhYee

Jul 16, 2019 via Android

20

假设链路很可靠用 udp 啊
tcp 三次握手和链路可靠不可靠又没啥关系

zhng920823

Jul 16, 2019

21

@azh7138m #10 S 和 C 方向是不是反了

CEBBCAT

Jul 16, 2019

22

@v2byy #17 链路层管你个锤子的 SEQ

CEBBCAT

Jul 16, 2019

1

23

> https://github.com/jawil/blog/issues/14

“已失效的连接请求报文段”的产生在这样一种情况下：client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。”

现在你知道为什么要有第三次握手了吗？

petelin

Jul 16, 2019

24

#15 #23 楼正解

azh7138m

Jul 16, 2019

25

@zhng920823 哦，那把 C 换成 M 吧（
其实只是想说明下 A/B，下意识写成了 CS，然后 ZZ 了一下，就。。。

nnnToTnnn

Jul 17, 2019

26

@cjpjxjx 第四次是挥手

shuizhengqi

Jul 17, 2019

27

假设链接可靠，为什么还需要握手，直接发不就完了