对于TCP的理解

目录

三次握手

 TCP三次握手怎么解决不可靠问题?

TCP如何在保证可靠性的前提下提高效率？（滑动窗口协议）

TCP为什么是三次握手而不是二次握手？

TCP四次挥手

为什么客户端需要等待超时时间?（此时服务端迟迟没有收到确认包就会再次发送FIN请求释放连接）

---

三次握手

当客户端向服务端发起连接时，（第一次握手）客户端向服务端发送一包请求连接包（SYN=1，ACK=0，seq=x）询问服务端能否建立连接，(第二握手)如果服务端同意的话会向客户端回包（SYN=1，ACK=1，seq=y）,(第三次握手)当客户接收的同意连接的请求后需要向服务端发送确认报文（ACK=1，seq=x+1,ack=y+1)

其中：x为本次TCP通信的字节流的初始序号。TCP规定：SYN=1的报文段不能有数据部分，但要消耗掉一个序号。

 TCP三次握手怎么解决不可靠问题?

tcp协议需要在不可靠的信道上保证建立可靠的连接，一包数据可能会被拆成多包发送，如何处理丢包问题，这些数据包到达的先后顺序不同，如何处理乱序问题
发送缓冲： 针对此问题，tcp协议为每一个连接建立了一个发送缓冲区

针对每一份报文都有发送的序列号和长度，对端接收到此报文回发送报文进行确认（其中确认号ACK会等于序列号加长度也就是对端下一份数据报的起始序列号）

TCP如何在保证可靠性的前提下提高效率？（滑动窗口协议）

由于确认应答的机制，发送端每发送一份数据都要等待对方的应答才能发送下一份数据。这样的结果无非导致大部分时间都耗在了等待ACK确认上。所以为了保证效率，采用滑动窗口协议（一次性发送多波数据）

 参考文章：文章更详细（包括对于丢包情况的分析以及拥塞控制的了解）(131条消息) TCP协议详细图解（含三次握手、滑动窗口等十大机制）_窗口滑动协议图解_Scintillator. /的博客-优快云博客https://blog.youkuaiyun.com/qq_45792749/article/details/124808553?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522168464152416782427487279%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=168464152416782427487279&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduend~default-1-124808553-null-null.142%5Ev87%5Einsert_down28,239%5Ev2%5Einsert_chatgpt&utm_term=tcp%E6%BB%91%E5%8A%A8%E7%AA%97%E5%8F%A3%E5%8D%8F%E8%AE%AE&spm=1018.2226.3001.4187

TCP为什么是三次握手而不是二次握手？

总结了文章的答案，原因有以下三种。

原因一:防止失效的连接请求报文段被服务端接收，从而产生错误。（避免资源浪费）

失效的连接请求：若客户端向服务端发送的连接请求丢失，客户端等待应答超时后就会再次发送连接请求，此时，上一个连接请求就是失效的。

由于第一次请求网络堵塞，客户端（认为失效）超时重发，当第二连接建立完后，第一次连接到达，这时服务器又会建立一次连接，而客户端则认为这次连接已失效，并不会在这条链路上传数据，所以这时就会造成资源的浪费。

反驳：服务器会有超时机制，资源的浪费会被回收，所以这个不是主要原因。

原因二：TCP需要确认通信双方的序列号，所以需要三次握手。

当客户端请求服务端建立连接时，服务端会发送ack和seq（其中ack用于告知对方下一份数据包的序列号），服务端发送了seq，此时客户端也应向服务端发送ack用于确认。这样一来一回才能确保双方序列号被可靠的同步。

原因三：阻止历史连接（原因三和原因一差不多，只不过原因一是从服务端建立多个连接（新SYN比旧SYN先到）却没有完全使用的角度来分析，而原因三是从旧SYN比新SYN先到的角度分析。

若是二次握手，当服务端接收到旧SYN就立刻建立其连接，接着发送ack给对端，对端发现序列号对不上就会（发送RST）请求断开，但发送RST的途中，对端已建立完成连接（会给自己发送数据），最后这些数据接收不到（浪费资源）

---

参考文章：

TCP为什么需要三次握手而不是两次？ - SanjiApollo - 博客园 (cnblogs.com)

(130条消息) tcp 为什么要三次握手，两次不行吗？为什么？_为什么tcp连接需要三次握手,两次不可以吗,为什么_倾听铃的声的博客-优快云博客

TCP四次挥手

 第一次挥手：客户端向服务端发送FIN包，请求服务器释放连接，随后客户端进入 FIN-WAIT-1 阶段，即半关闭阶段，并且停止向服务端发送通信数据。

第二次挥手：服务端接收到FIN包后回复ACK报文（告知对端自己已经知道他要释放连接了），然后进入CLOSE-WAIT阶段。

第三次挥手：当服务端把数据包发完之后发送FIN包给客户端，这是第三次挥手。

第四次挥手：客户端接收到服务端发送的FIN包后进入FIN-WAIT-2阶段，然后回复ACK包，进入超时等待状态，经过超时时间后关闭连接。而服务端接收到ACK包后立即关闭连接。

为什么客户端需要等待超时时间?（此时服务端迟迟没有收到确认包就会再次发送FIN请求释放连接）

这是保证对方已经收到ACK包，因为假设客户端送完最后一包ACK包后就释放了连接，一旦ACK包在网络中丢失，服务端将一直保留在最后确认状态。