TCP协议

MLuhuihui

已于 2022-03-15 20:58:51 修改

阅读量503

点赞数 1

分类专栏：计算机网络文章标签： tcp/ip 网络

于 2022-03-15 19:56:55 首次发布

本文链接：https://blog.csdn.net/MLuhuihui/article/details/123505829

版权

计算机网络专栏收录该内容

9 篇文章 1 订阅

订阅专栏

1 TCP概述

2 TCP协议的实现

2.1 TCP协议的可靠数据传输

TCP协议的ACK和GBN协议是一样的，都是累加式的，即ACK之前的数据都已经收到了，接收方返回的ACK就是下一个希望接受到的。

如果发送方一直从接收方接受同一个ACK，就说明这个数据很有可能丢了，因为接收方一直跟我说，我要这个我要这个，你给的不对，哈哈哈哈。

2.2 TCP流量控制

如果RcvWindow=0，发送方会持续发送很小的信息，以便返回RcvWindow大小。

2.3 TCP连接管理

终于来啦终于来啦，三次握手四次挥手，为了这碗醋包的这盘饺子啊。

2.3.1 三次握手

在建立TCP协议的时候，一般来说，客户都是请求发起者，服务端接受请求建立连接。这个过程一般分为3步：

1.服务端新建套接字，绑定地址信息后开始监听，进入LISTEN状态。客户端新建套接字绑定地址信息后调用connect，发送连接，即发送一个SYN报文段，并进入SYN_SENT状态，等待服务器的确认。（SYN段是不携带任何的信息的，但是要将SYN标志位要置1，需要传递客户机选择的初始序列号）

2.服务端一旦监听到连接请求，就会将连接放入内核等待队列中，如果服务器想要建立连接的话，就会向客户端答复一个SYN+ACK报文段，进入SYN_RCVD状态。此时服务器会为这个连接分配必要的缓冲等资源，并且告知客户端，自己的初始的序列号。

3.客户端收到SYN+ACK报文后向服务端发送确认报文段ACK（此时SYN的标志位就不再置1了），并进入ESTABLISHED状态，开始读写数据。服务端一旦收到客户端的确认报文，就进入ESTABLISHED状态，就可以进行读写数据了。

值得注意的是，在建立过程中，client_isn以及server_isn都是随机生成的，ISN全称是Initial Sequence Number，是TCP发送方的字节数据编号的原点，告诉对方我要开始发送数据的初始化序列号。ISN如果是固定的，攻击者很容易猜出后序的确认号，为了安全起见，避免被第三方猜到从而发送伪造的RST报文，因此ISN是动态生成的。

在第二次握手的时候，服务器会给此次连接分配必要的缓冲等资源，并且等待第三次握手，即客户端发送ACK信息。在这个过程中，服务器会等待一段时间，如果第三次握手发送的ACK信息迟迟不来，服务器就会取消掉这一次连接建立并且释放掉分配的资源。

但是，试想一下，如果段时间内有大量的连接建立请求，并且都在白嫖完服务器分配的资源之后，不发送第三次握手的ACK信息，这时候会发生什么？这就是SYN泛洪攻击，或者说是DDOS分布式拒绝服务攻击。

2.3.2 四次挥手

TCP协议的关闭，一般来说，分为4步，也就是常说的四次挥手。TCP连接的拆除客户端和服务器都能发起，一般来说是客户端发起。

1.客户端主动调用close时，向服务端发送结束报文段FIN报文段，同时进入FIN_WAIT1状态；

2.服务器收到FIN报文段后，就会回复一个ACK，关闭连接并进入CLOSE_WAIT状态，此时如果服务端有数据要发送的话，客户端依然需要接收。客户端收到服务器对结束报文段的确认ACK，就会进入到FIN_WAIT2状态，开始等待服务器的结束报文段FIN；

3.服务器端数据发送完毕后，当服务器真正调用close关闭连接时，会向客户端发送结束报文段FIN包，此时服务器进入LAST_ACK状态，等待客户端最后一个ACK的到来；

4.客户端收到服务器的FIN结束报文段，并且回复最后一个ACK（此时会进入等待状态TIME_WAIT，如果持续接受到FIN报文段，就会重新发送ACK）；服务器收到了对结束报文段确认的ACK，进入CLOSED状态，断开连接。而客户端要等待2MSL的时间，才会进入到CLOSED状态。

为什么连接时只要3次握手，断开要4次挥手呢，为什么要多一次？

其实在TCP握手的时候，接收端将SYN包和ACK确认包合并到一个包中发送的，所以减少了一次包的发送。

对于四次挥手，由于TCP是全双工通信，主动关闭方发送FIN请求不代表完全断开连接，只能表示主动关闭方不再发送数据了。而接收方可能还要发送数据，就不能立即关闭服务器端到客户端的数据通道，所以就不能将服务端的FIN包和对客户端的ACK包合并发送，只能先确认ACK，等服务器无需发送数据时在发送FIN包，所以四次挥手时需要四次数据包的交互。

这就是为什么客户端在接受到了ACK后，需要进入FIN_WAIT_2阶段了，这个时候，还需要持续接受服务端的信息，等待服务端的FIN到来。服务端FIN到来之后，在发送一个ACK回去，让服务器完成关闭。

整个三次握手，四次挥手的过程中的客户端和服务端的流程就如下图啦！

2.4 TCP拥塞控制原理

2.4.1 拥塞控制成因

据说可靠传输问题是网络10大问题之一，拥塞控制也是10大问题之一，是网络数据传输中亟需解决的。

分组丢失问题不是已经在之前的可靠性传输中解决了吗？为什么现在还要解决。我就当兰顺老师的例子啊，相当的形象。可靠性传输解决的丢失，相当于是从我们个人的角度来说的，也就是客户端和服务器之间，而拥塞控制解决的，是整个宏观上的问题，即整个网络上的丢失问题。有个弹幕说的是真好，如果按照可靠性传输定义的那样解决分组丢失问题，那越挤越丢，越丢越发，越发越挤，为了一个客户的理论，把整个网络都给搞死了。