5.8.3 TCP连接管理（一）TCP连接建立

最新推荐文章于 2024-07-24 21:15:45 发布

肆悟先生

最新推荐文章于 2024-07-24 21:15:45 发布

阅读量1k

点赞数

分类专栏：网络技术与应用文章标签： java 开发语言

本文链接：https://blog.csdn.net/nytcjsjboss/article/details/131503711

版权

网络技术与应用专栏收录该内容

89 篇文章 27 订阅

订阅专栏

文章详细介绍了TCP连接的管理，特别是通过Wireshark工具观察TCP的三次握手过程。在三次握手中，不仅建立了连接，还协商了最大报文段长度(MSS)。同时，文章提到了TCP三次握手的潜在缺陷，如SYNFlood攻击，这种攻击能消耗服务器资源，导致拒绝服务。

摘要由CSDN通过智能技术生成

5.8.3 TCP连接管理（一）TCP连接建立

我们知道TCP是面向连接的传输协议，在传输连接的建立和释放是每一次面向连接通信必不可少的过程，因此传输连接的管理使得传输连接的建立和释放的过程都能够正常的进行。

一、使用Wireshark查看TCP传输连接的管理过程

我们可以使用Wireshark可以直观的分析TCP的连接建立，数据通信和连接释放等全过程。

打开Wireshark选择监听的网卡
点击开始按钮，并在浏览器中输入清华大学网址并访问。为了能够检测到我们需要的TCP报文段，需要持续一小段时间后停止采集报文。
在Wireshark的显示过滤器输入过滤条件，ip.addr==166.111.4.100(这是清华大学网站对应的IP地址)，只观察IP为166.111.4.100排除其他的干扰报文。
在Wireshark统计菜单栏中选择流量图，如图

勾选限制显示过滤器、流类型选择TCP Flows、地址选择任何。
通过以上设置我们就可以观察TCP流。我们可以看到主机192.168.0.23访问清华大学网站的所有TCP报文段的交互情况。如图包括端口、序号、确认号、标志位等置位情况等等一目了然。

二、TCP连接建立过程

TCP连接建立采用的过程被称为TCP三次握手，TCP报文段首部SYN和FIN置1时报文段需要消耗一个序号，只有ACK置位的报文段是不需要消耗序号的。

如图

这是主机A：192.168.0.23与清华大学服务器B：116.111.4.100之间的TCP三次握手连接建立的过程。

第一步如图
第一步主机A的TCP向服务器B的TCP发送的连接请求报文段，其首部中的同步比特SYN=1，同时选择一个初始序号Seq=0（这是一个相对序号。）
第二步如图
第二步服务器的TCP收到连接请求报文段后发回确认，确认中ACK=1，这其中确认号字段Ack=1，因为之前的连接请求的SYN=1，需要消耗掉一个序号，所以服务器B此时希望接收的序号应该是’1’，即确认号Ack=1

因为连接是双向的所以服务器B也发出和主机A的连接请求，在报文段当中同时也应该将SYN置为1，选择服务器自己的一个初始序号，Seq=0，当然这也是一个相对序号。
第三步如图

第三步，主机A的TCP收到此报文后，还要服务器B发出确认，其确认序号为序号Seq=1，注意由于ACK置一的报文段，并不消耗掉序号，所以在主机A发往服务器B的第一个数据的序号仍然是序号字段等于1。

以上就是通过Wireshark采集的TCP报文段验证了三次握手的过程。

三、三次握手补充

当然三次握手还有一个很重要的功能，就是通信双方协商最大报文段长度MSS的过程，当客户端发起一个TCP连接时，通过TCP中的SYN置一报文段中的MSS选项字段来协商TCP报文数据载荷的最大值，客户端的SYN报文的MSS值表示后续服务器发送的数据载荷的最大值限定。

如图是FDDI网络和以太网进行协商一个MSS的一个过程。
在FDDI网络中，它的默认的报文段的值是4312个字节，而以太网只能接受最大报文段长度值是1460个字节，所以双方只能协商出双方网络中取小的一个值，也就是1460个字节，从而避免产生网络的IP分片。
TCP三次握手缺陷

当然TCP三次握手并不完美，SYNflood是当前最为流行的拒绝服务攻击或者是分布式的拒绝服务攻击的方式之一。这就是一种利用TCP的三次握手中的缺陷而发送大量TCP伪造的请求，从而使得服务器资源耗尽，或者CPU负荷满载或者内存不足等连接方式。

这种攻击方式的问题就出现在TCP的三次握手中。如图
我们假设一个用户向服务器发送了SYN=1的报文之后，突然死机或者掉线了，那么此时服务器会发出SYN=1，ACK=1的报文之后是没有办法收到来自客户端的第三次的握手报文，这种情况下服务器只能是重新的去试探再一次的发出SYN=1，ACK=1的第二次的握手报文，并在等待一段时间之后丢弃没有完成的半连接，这段时间就被称为SYN Timeout时间，这个时间大概是从30秒到2分钟之间。

这里一个用户出现这样的情况并不会导致服务器的宕机，但是如果有大量的恶意攻击者出现这种情况，服务器为了维护如此庞大的半连接的列表而耗费非常非常多的资源，即便是非常简单的保存遍历方式也会消耗非常多的CPU和内存的资源，同时还需要对半连接进行SYN+ACK的第二次握手报文的重试。如果TCP/IP的协议栈不够强大，最后的结果往往是堆栈溢出或崩溃。从而导致服务器端不能够接受客户端的正常请求。此时的服务器就是收到了SYNflood攻击也就是洪水攻击。