tcp请求（jmeter发送tcp请求）

大家好！今天让创意岭的小编来大家介绍下关于tcp请求的问题，以下是小编对此问题的归纳整理，让我们一起来看看吧。

开始之前先推荐一个非常厉害的Ai人工智能工具，一键生成原创文章、方案、文案、工作计划、工作报告、论文、代码、作文、做题和对话答疑等等

只需要输入关键词，就能返回你想要的内容，越精准，写出的就越详细，有微信小程序端、在线网页版、PC客户端

官网：https://ai.de1919.com

本文目录:

• 1、一文搞懂TCP的三次握手和四次挥手

• 2、怎么解决在window下高并发TCP请求端口被占用有关问题

• 3、tcp发请求数据里为什么后面会自动填充很多零

• 4、TCP连接相关

一、一文搞懂TCP的三次握手和四次挥手

TCP的三次握手和四次挥手实质就是TCP通信的连接和断开。

三次握手：为了对每次发送的数据量进行跟踪与协商，确保数据段的发送和接收同步，根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系，并建立虚连接。

四次挥手：即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。

TCP三次握手、四次挥手时序图

TCP协议位于传输层，作用是提供可靠的字节流服务，为了准确无误地将数据送达目的地，TCP协议采纳三次握手策略。

三次握手原理：

第1次握手：客户端发送一个带有SYN（synchronize）标志的数据包给服务端；

第2次握手：服务端接收成功后，回传一个带有SYN/ACK标志的数据包传递确认信息，表示我收到了；

第3次握手：客户端再回传一个带有ACK标志的数据包，表示我知道了，握手结束。

其中：SYN标志位数置1，表示建立TCP连接；ACK标志表示验证字段。

可通过以下趣味图解理解三次握手：

三次握手过程详细说明：

1、客户端发送建立TCP连接的请求报文，其中报文中包含seq序列号，是由发送端随机生成的，并且将报文中的SYN字段置为1，表示需要建立TCP连接。（SYN=1，seq=x，x为随机生成数值）；

2、服务端回复客户端发送的TCP连接请求报文，其中包含seq序列号，是由回复端随机生成的，并且将SYN置为1，而且会产生ACK字段，ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP建立请求已得到验证。（SYN=1，ACK=x+1，seq=y，y为随机生成数值）这里的ack加1可以理解为是确认和谁建立连接；

3、客户端收到服务端发送的TCP建立验证请求后，会使自己的序列号加1表示，并且再次回复ACK验证请求，在服务端发过来的seq上加1进行回复。（SYN=1，ACK=y+1，seq=x+1）。

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

四次挥手原理：

第1次挥手：客户端发送一个FIN，用来关闭客户端到服务端的数据传送，客户端进入FIN_WAIT_1状态；

第2次挥手：服务端收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），服务端进入CLOSE_WAIT状态；

第3次挥手：服务端发送一个FIN，用来关闭服务端到客户端的数据传送，服务端进入LAST_ACK状态；

第4次挥手：客户端收到FIN后，客户端t进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，服务端进入CLOSED状态，完成四次挥手。

其中：FIN标志位数置1，表示断开TCP连接。

可通过以下趣味图解理解四次挥手：

四次挥手过程详细说明：

1、客户端发送断开TCP连接请求的报文，其中报文中包含seq序列号，是由发送端随机生成的，并且还将报文中的FIN字段置为1，表示需要断开TCP连接。（FIN=1，seq=x，x由客户端随机生成）；

2、服务端会回复客户端发送的TCP断开请求报文，其包含seq序列号，是由回复端随机生成的，而且会产生ACK字段，ACK字段数值是在客户端发过来的seq序列号基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP断开请求已经得到验证。（FIN=1，ACK=x+1，seq=y，y由服务端随机生成）；

3、服务端在回复完客户端的TCP断开请求后，不会马上进行TCP连接的断开，服务端会先确保断开前，所有传输到A的数据是否已经传输完毕，一旦确认传输数据完毕，就会将回复报文的FIN字段置1，并且产生随机seq序列号。（FIN=1，ACK=x+1，seq=z，z由服务端随机生成）；

4、客户端收到服务端的TCP断开请求后，会回复服务端的断开请求，包含随机生成的seq字段和ACK字段，ACK字段会在服务端的TCP断开请求的seq基础上加1，从而完成服务端请求的验证回复。（FIN=1，ACK=z+1，seq=h，h为客户端随机生成）

至此TCP断开的4次挥手过程完毕。

LISTEN：等待从任何远端TCP 和端口的连接请求。

SYN_SENT：发送完一个连接请求后等待一个匹配的连接请求。

SYN_RECEIVED：发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。

ESTABLISHED：表示一个打开的连接，接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。

FIN_WAIT_1：等待远端TCP 的连接终止请求，或者等待之前发送的连接终止请求的确认。

FIN_WAIT_2：等待远端TCP 的连接终止请求。

CLOSE_WAIT：等待本地用户的连接终止请求。

CLOSING：等待远端TCP 的连接终止请求确认。

LAST_ACK：等待先前发送给远端TCP 的连接终止请求的确认（包括它字节的连接终止请求的确认）

TIME_WAIT：等待足够的时间过去以确保远端TCP 接收到它的连接终止请求的确认。

TIME_WAIT 两个存在的理由：

          1.可靠的实现tcp全双工连接的终止；

          2.允许老的重复分节在网络中消逝。

CLOSED：不在连接状态（这是为方便描述假想的状态，实际不存在）。

二、怎么解决在window下高并发TCP请求端口被占用有关问题

执行以下操作之一：

在 Windows XP 或 Windows Server 2003 计算机上的命令提示中输入以下命令，显示此计算机上 TCP/IP 协议所使用的活动连接：

复制

netstat -n

这将列出绑定到客户端计算机的 TCP/IP 地址以及 TCP/IP 地址与远程服务器通信所使用的端口。如果列出的端口使用了所有可用的端口，则出现了 TCP/IP 端口耗尽现象。

在基于 Windows Server 2003 的客户端计算机的命令提示中输入以下命令，以显示 TCP/IP 协议所使用的活动连接：

复制

netstat -b

这将列出绑定到客户端计算机的 TCP/IP 地址、TCP/IP 地址与远程服务器通信所使用的端口以及使用这些端口的应用程序。此信息可以帮助您确定那个客户端应用程序正在使用过多的 TCP/IP 端口。

与 TCP/IP 端口耗尽有关的问题

当客户端应用程序尝试使用 TCP/IP 套接字连接到 BizTalk Server，或当 BizTalk 应用程序尝试使用 TCP/IP 套接字连接到服务器时，可能会出现类似于下面的情况：

复制

System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.

- 或者 -

复制

Unable to connect to the remote server

System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted.

当出现这些错误时，还可能出现以下问题：

客户端应用程序可能无法连接到 BizTalk Server。

BizTalk 应用程序服务可能无法连接到远程 SQL 服务器。

BizTalk Server 适配器可能无法连接到远程服务器。

客户端应用程序预留的每个端口均占用内核内存。如果预留了数目超常的客户端端口，Windows 内核内存的占用率将相应增加。

原因

如果客户端计算机中存在数目超常的 TCIP/IP 套接字连接，则客户端计算机上可能出现 TCP/IP 端口耗尽的情况。如果多个客户端应用程序都在建立连接，则可能出现这种情况。

如果所有可用的临时端口都分配给了客户端应用程序，则客户端将出现 TCP/IP 端口耗尽的情况。当 TCP/IP 端口耗尽时，将无法预留客户端端口，并且尝试通过 TCP/IP 套接字连接到服务器的客户端应用程序也将出错。

在高负载情况下，比处于正常负载时更容易出现 TCP/IP 端口耗尽的情况。

解决方法

执行以下步骤以避免 TCP/IP 端口耗尽及其相关问题：

验证客户端应用程序没有生成过多的 TCP/IP 套接字连接。这一点可以用上面提到的方法来检查，即在 Windows Server 2003 和 Windows XP 上运行 netstat -n，或者在 Windows Server 2003 和 2008 上运行 netstat -b。

如果某个客户端应用程序使用了数量超常的 TCP/IP 套接字连接，则应考虑重新设计客户端应用程序，以便更有效地使用 TCP/IP 套接字连接。

注意

如果为 BizTalk 应用程序服务 (BTSNTSvc.exe) 实例预留了数量超常的客户端端口，则需验证配置为在 BizTalk 应用程序服务中运行的任何自定义代码都没有建立过多的 TCP/IP 套接字连接。

如果大量客户端应用程序要启动已知数量的 TCP/IP 套接字连接，但没有足够数量的可用临时端口来满足连接请求，则需要进行以下注册表修改。

警告

如果注册表编辑器使用不当，则可能会产生严重问题，导致重新安装操作系统。Microsoft 不保证可以解决因注册表编辑器使用不当而造成的问题。请慎用注册表编辑器，风险自负。在修改注册表之前，请务必备份注册表，并确保您知道在发生问题时如何使用备份进行还原。有关如何备份、还原及修改注册表的详细信息，请参阅 Microsoft 知识库文章“Microsoft Windows 注册表说明”，网址为http://go.microsoft.com/fwlink/?LinkId=62729。

增加动态分配到客户端 TCP/IP 套接字连接的临时端口的上限。

降低客户端 TCP/IP 套接字连接的超时值（默认值为 240 秒）

启动注册表编辑器。

在注册表中，浏览到并单击以下注册表项。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

在“编辑”菜单中单击“新建”、“DWORD 值”，然后添加以下注册表值，以缩短关闭连接时，该连接处于 TIME_WAIT 状态的时间。当连接处于 TIME_WAIT 状态时，套接字对无法重新使用：

值名称

TcpTimedWaitDelay

值数据

<在此输入一个 30 到 240 之间的十进制值。>

关闭注册表编辑器。

注意

必须重新启动计算机，此更改才会生效。

注意

此值的有效范围为 30 到 300（十进制）之间。默认值为 240。

启动注册表编辑器。

在注册表中，浏览到并单击以下注册表项。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

在“编辑”菜单中单击“新建”、“DWORD 值”，然后添加以下注册表值，以增加可以动态分配到客户端的临时端口的数量：

值名称

MaxUserPort

值数据

<在此输入一个 5000 到 65534 之间的十进制值>

关闭注册表编辑器。

注意

必须重新启动计算机，此更改才会生效。

注意

增加用于客户端 TCP/IP 连接的临时端口的范围将占用 Windows 内核内存。请勿将此设置的值增加至超过容纳客户端应用程序套接字连接所需要的值，以便尽可能降低对 Windows 内核内存的不必要占用。

三、tcp发请求数据里为什么后面会自动填充很多零

数据部分不是偶数。

在RFC1071的文档中，有一个C语言的的代码来求解校验和。在UDP报文校验和计算的时候，如果报文的数据部分不是偶数个字节，则在最后面填充0。

四、TCP连接相关

为什么要有三次握手，因为如果只有两次握手，那么

第一次：客户端发送一个syn包给服务器，里面有一个随机生成的syn，然后客户端处于syn_send状态

第二次：服务端收到客户端发来的syn包之后，确认syn包，也就是生成一个ack=syn+1，然后再自己随机生成一个syn包，即syn+ack包，然后返回给客户端，自己变成syn_recv状态

第三次：客户端收到服务端发来的syn+ack包之后，确认ack是正确的之后，返回一个ack=syn+1给服务端，此包发送完毕，客户端进入了ESTABLISHED状态，服务端收到ack包后也进入ESTABLISHED状态。

SYN攻击，当第二次握手服务端发送了syn+ack包之后，收到客户端发送的ack之前这段时间的tcp链接成为半连接，此时服务端处于syn_recv状态。当大量客户端随机IP疯狂发送tcp链接请求时，客户端以为是不同用户的请求，所以队列中全是半连接，然后导致服务器宕机，正常请求被丢弃。

第一个包发送过程丢失

A会周期性超时重传，直到收到B的确认

第二个包发送过程丢失

B会周期性超时重传，直到收到A的确认

第三个包发送过程丢失

A发送完数据后单方面进入TCP的ESTABLISHED状态，B还处于半链接：

TCP协议为什么需要三次握手？

第一次：客户端发送一个fin给服务端表示自己要断开连接了，然后进入fin_wait_1状态

第二次：服务端收到fin后，发送一个ack=fin+1给客户端，服务端进入close_wait状态，客户端进入fin_wait_2状态

第三次：服务端发送一个fin，用来关闭服务端到客户端的数据传输，服务端进入last_ack状态

第四次：客户端收到fin后，进入time_wait状态，然后发送一个ack=fin+1给服务端，服务端确认后进入close状态，完成四次挥手

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。

答案解析：

浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。

在 HTTP/1.0 中，一个http请求收到服务器响应后，会断开对应的TCP连接。这样每次请求，都需要重新建立TCP连接，这样一直重复建立和断开的过程，比较耗时。所以为了充分利用TCP连接，可以设置头字段 Connection: keep-alive ，这样http请求完成后，就不会断开当前的TCP连接，后续的http请求可以使用当前TCP连接进行通信。

第一次访问有初始化连接和SSL开销

初始化连接和SSL开销消失了，说明使用的是同一个TCP连接。

HTTP/1.1 将 Connection 写入了标准，默认值为 keep-alive 。除非强制设置为 Connection: close ，才会在请求后断开TCP连接。

所以这一题的答案就是：默认情况下建立的TCP连接不会断开，只有在请求头中设置 Connection: close 才会在请求后关闭TCP连接。

HTTP/1.1 中，单个TCP连接，在同一时间只能处理一个http请求，虽然存在Pipelining技术支持多个请求同时发送，但由于实践中存在很多问题无法解决，所以浏览器默认是关闭，所以可以认为是不支持同时多个请求。

HTTP2 提供了多路传输功能，多个http请求，可以同时在同一个TCP连接中进行传输。

页面资源请求时，浏览器会同时和服务器建立多个TCP连接，在同一个TCP连接上顺序处理多个HTTP请求。所以浏览器的并发性就体现在可以建立多个TCP连接，来支持多个http同时请求。

Chrome浏览器最多允许对同一个域名Host建立6个TCP连接，不同的浏览器有所区别。

补充

如果图片都是HTTPS的连接，并且在同一域名下，浏览器会先和服务器协商使用 HTTP2 的 Multiplexing 功能进行多路传输，不过未必所有的挂在这个域名下的资源都会使用同一个TCP连接。如果用不了HTTPS或者HTTP2（HTTP2是在HTTPS上实现的），那么浏览器会就在同一个host建立多个TCP连接，每一个TCP连接进行顺序请求资源。

参考：

[1]. 第8题-浏览器HTTP请求并发数和TCP连接的关系

以上就是关于tcp请求相关问题的回答。希望能帮到你，如有更多相关问题，您也可以联系我们的客服进行咨询，客服也会为您讲解更多精彩的知识和内容。

推荐阅读：

tcp请求（jmeter发送tcp请求）

ChatGPT有中文吗（chatcrypt）

tcp心跳机制（tcp 心跳）

又好看又实用的字体（又好看又实用的字体有哪些）

怎么做电商平台（买卖天猫店铺的平台）