Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

关于“为什么TCP连接请求是三报文握手,而TCP连接释放是四报文握手”的答案 #2

Closed
DDERGOU opened this issue Apr 12, 2020 · 1 comment

Comments

@DDERGOU
Copy link

DDERGOU commented Apr 12, 2020

抛砖引玉:
1、连接请求的三报文握手其实也可以拆分为4报文握手,即第二次的报文段可以拆分为两次发送,先发ACK报文段确认,再发SYN报文段请求连接,只是可以合并发,其实连接请求也可以理解为四报文握手的,下面解释。
2、TCP是全双工通信的,这点提前点明一下。
3、为什么TCP需要三报文握手?这里的过程通俗地说就是,我要确保你会接收我的消息,你也要确保我会接收你的消息。
一报文握手肯定不合理;
二报文握手,就是A发送SYN报文段请求连接,B响应ACK报文段,即建立全双工通信。这样的通信还是不可靠的。例如,A端发送了SYN请求连接请求,但是出现网络拥塞,SYN报文段无法到达B端,A端超时重发,但是依然没有收到ACK报文确认报文,这时候A取消了连接请求,但是因为网络拥塞停留在广域网中的SYN突然又成功发送出去了,B端收到SYN请求后响应ACK报文,直接建立连接,并进入了消息接收的状态。可是A端此时并不会接收B端响应的ACK确认报文。这就导致了B端建立了一个无效连接,如果B端不主动发送消息,则需要等Keepalive Timer定时器进行连接关闭。
三报文握手,其实是四报文握手,不过被主动连接端的ACK报文和SYN报文合并了而已。三报文握手就可以确保上面的问题不会出现。因为双方都必须收到对方的ACK报文才会真正建立连接,超时会重发,重发不行就直接重置连接(RST报文)。
4、为什么连接释放需要四报文握手?其实原理和连接请求的三报文握手(可以理解为四报文握手)一样的,全双工通信,必须我确保你关闭了,你确保我关闭了。否则还是会有可能出现一端关闭,一段没关闭的情况。

@yuanguangxin
Copy link
Owner

很细致

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants