要找做冲压件的厂去哪个网站找,富阳建立网站的,国内做彩票网站违法么,网页版微信二维码TCP协议的相关实验 一、理解listen的第二个参数1、实验现象2、TCP 半连接队列和全连接队列3、关于listen的第二个参数的一些问题4、SYN洪水Ⅰ、什么是SYN洪水攻击Ⅱ、如何解决SYN洪水攻击#xff1f; 二、使用Wireshark分析TCP通信流程 一、理解listen的第二个参数
在编写TCP… TCP协议的相关实验 一、理解listen的第二个参数1、实验现象2、TCP 半连接队列和全连接队列3、关于listen的第二个参数的一些问题4、SYN洪水Ⅰ、什么是SYN洪水攻击Ⅱ、如何解决SYN洪水攻击 二、使用Wireshark分析TCP通信流程 一、理解listen的第二个参数
在编写TCP套接字的服务器代码时在进行了套接字的创建和绑定之后需要调用listen函数将创建的套接字设置为监听状态此后服务器就可以调用accept函数获取建立好的连接了。其中listen函数的第一个参数就是需要设置为监听状态的套接字而listen的第二个参数我们一般设置为163264128可是为什么要设置为这些值呢listen函数的第二个参数具体的含义是什么呢下面我们先看代码的实验结果再来说为什么。
1、实验现象
下面的代码通过一个实验来说明listen的第二个参数的具体含义
先编写TCP套接字的服务器端代码服务器初始化时依次进行套接字创建、绑定、监听但服务器初始化后不调用accept函数获取底层建立好的连接。为了方便验证这里将listen函数的第二个参数设置为1。
#include iostream
#include cstring
#include unistd.h
#include sys/socket.h
#include sys/types.h
#include arpa/inet.h
#include netinet/in.h
#include pthread.hconst int port 8081;
const int num 1;int main()
{// 1. 创建监听套接字int listen_sock socket(AF_INET, SOCK_STREAM, 0);if (listen_sock 0){std::cerr socket error std::endl;return 1;}int opt 1;setsockopt(listen_sock, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt));// 2. 绑定struct sockaddr_in local;memset(local, 0, sizeof(local));local.sin_port htons(port);local.sin_family AF_INET;local.sin_addr.s_addr INADDR_ANY;if (bind(listen_sock, (struct sockaddr*)local, sizeof(local)) 0){std::cerr bind error std::endl;return 2;}// 3. 监听if (listen(listen_sock, num) 0){std::cerr listen error std::endl;return 3;}//启动服务器while(true){//不调用accept获取连接sleep(1);}return 0;
}运行服务器后使用netstat -natp | grep 进程名命令可以看到该服务器当前正处于监听状态。 接下来新建三个会话在三个会话中我们都使用telnet进行连接我们的服务器程序。 然后此时我们使用netstat -natp | head -2 netstat -natp | grep 8081进行查看连接状态。 我们发现三个telnet客户端连接的状态都是ESTABLISH状态而对于服务器端却只有两个ESTABLISH状态和一个SYN_RECV状态。 对于SYN_RECV的状态也就意味着服务器没有收到客户端的ACK但是这里并不是这样的(丢包的概率是很小的)对刚才客户端发来的ACK服务器即使收到了但是服务器不能让自己进入ESTABLISH状态原因后面说。 然后你后面使用更多的客户端连接服务器你会发现只有两个客户端能和服务器建立正常的连接其他的都会让服务器处于SYN_RCVD状态而这个状态不稳定如果一直无法进行三次握手就会直接放弃建立连接。
2、TCP 半连接队列和全连接队列
实际TCP在进行连接管理时在内核中存在两个连接队列
全连接队列accept队列全连接队列用于保存已经处于ESTABLISHED状态但没有被上层调用accept取走的连接。半连接队列 SYN 队列半连接队列用于保存处于SYN_SENT和SYN_RECV状态的连接也就是还未完成三次握手的连接。
而全连接队列的长度实际会受到listen第二个参数的影响全连接队列的长度由两个值决定
用户层调用listen时传入的第二个参数backlog。系统变量net.core.somaxconn默认值为128。
真实的全连接队列的长度等于listen传入的backlog和系统变量net.core.somaxconn中的较小值加1。
通过以下命令可以查看系统变量net.core.somaxconn的值。
sudo sysctl -a | grep net.core.somaxconn因为我们实验时设置listen第二个参数的值为1此时在服务器端全连接队列的长度就为2因此服务器最多只允许有两个处于ESTABLISHED状态的连接。
所以第三个客户端发来建立连接请求时此时服务器端就会新增状态为SYN_RECV的状态于是放入半连接队列当中即使服务端收到了客户端的ACK响应但是全连接队列已经满了于是第三个连接就没有办法进入全连接队列于是一直处于SYN_RECV状态。 在linux中可以使用 ss 命令来查看 TCP 全连接队列的情况
但需要注意的是 ss 命令获取的 Recv-Q/Send-Q 在「LISTEN 状态」和「非 LISTEN 状态」所表达的含义是不同的。
l 显示正在监听 ( listening ) 的 socketn 不解析服务名称t 只显示 tcp socket
在「LISTEN 状态」时Recv-Q/Send-Q 表示的含义如下
Recv-Q当前全连接队列的大小也就是当前已完成三次握手并等待服务端 accept() 的 TCP 连接Send-Q值等于listen的第二个参数表示当前全连接最大队列长度 - 1上面的输出结果说明监听 8081 端口的 TCP 服务最大全连接长度为 2
在「非 LISTEN 状态」时Recv-Q/Send-Q 表示的含义如下 Recv-Q已收到但未被应用进程读取的字节数Send-Q已发送但未收到确认的字节数 3、关于listen的第二个参数的一些问题
1. 问不考虑其他参数是不是listen的第二个参数为多少服务器就可以同时处理几个连接
答案是不是我们这个实验中我们没有使用accept函数于是导致了建立的连接无法从全连接队列中取走如果我们使用了accept函数连接被取走服务器就可以对连接进行处理全连接队列里面有连接进入有连接被取走服务器可以同时对所有已经取走的连接进行处理。
所以这个全连接队列本质是一个缓冲区用来存放操作系统暂时没有办法处理的连接这个模型本质也是一个生产者消费者模型。
生产者半连接队列消费者操作系统缓冲区全连接队列
2. 问为什么底层要维护连接队列
一般当服务器压力较大时连接队列的作用才会体现出来如果服务器压力本身就不大那么一旦底层有连接建立成功上层就会立马将该连接读走并进行处理。
服务器端启动时一般会预先创建多个服务线程为客户端提供服务主线程从底层accept上来连接后就可以将其交给这些服务线程进行处理 如果向服务器发起连接请求的客户端很少那么连接一旦在底层建立好就被主线程立马accept上来并交给服务线程处理了。 但如果向服务器发起连接请求的客户端非常多当每个服务线程都在为某个连接提供服务时底层再建立好连接主线程就不能获取上来了此时底层这些已经建立好的连接就会被放到全连接队列当中只有等某个服务线程空闲时主线程就会从这个全连接队列当中获取建立好的连接。 如果没有这个连接队列那么当服务器端的服务线程都在提供服务时其他客户端发来的连接请求就会直接被拒绝但有可能正当这个连接请求被拒绝时某个服务线程提供服务完毕此时这个服务线程就无法立马得到一个连接为之提供服务所以一定有一段时间内这个服务线程是处于闲置状态的直到再有客户端发来连接请求。
而如果设置了连接队列当某个服务线程提供完服务后如果连接队列当中有建立好的连接那么主线程就可以立马从连接队列当中获取一个连接交给该服务线程进行处理此时就可以保证服务器几乎是满载工作的。
3. 问为什么连接队列既不能太长
虽然维护连接队列能让服务器处于几乎满载工作的状态但连接队列也不能设置得太长。
第一服务器维护连接也是需要成本的连接队列设置的越长系统就要花费越多的成本去维护这个队列。第二如果队列太长也就意味着在队列较尾部的连接需要等待较长时间才能得到服务此时客户端的请求也就迟迟得不到响应。此外与其维护一个很长的连接占用大量暂时用不到的资源造成客户端等待过久还不如将部分资源节省出来给服务器使用让服务器更快的为客户端提供服务。
4、SYN洪水
Ⅰ、什么是SYN洪水攻击
我们都知道 TCP 连接建立是需要三次握手假设攻击者用大量的假IP地址发送初始连接请求SYN数据包让服务端建立连接然后切换IP继续发服务端每接收到一个 SYN 报文就进入SYN_RCVD 状态但服务端发送出去的 ACK SYN 报文无法得到未知 IP 主机的 ACK 应答久而久之就会占满服务端的半连接队列使得服务端不能为正常用户服务。
SYN 攻击方式最直接的表现就会把 TCP 半连接队列打满这样当 TCP 半连接队列满了后续再在收到 SYN 报文就会丢弃导致客户端无法和服务端建立连接。
Ⅱ、如何解决SYN洪水攻击
首先这一定是一个综合性的解决方案TCP作为传输控制协议需要对其进行处理而上层应用层也要尽量避免遭到SYN洪水攻击。
在应用层
比如应用层可以记录向服务器发起连接建立请求的主机信息如果发现某个主机多次向服务器发起SYN请求但从不对服务器的SYNACK进行ACK响应此时就可以对该主机进行黑名单认证此后该主机发来的SYN请求一概不进行处理。
在传输层
现在核心的问题就是半连接队列被占满了但不能简单的扩大半连接队列就算半连接队列再大恶意用户也能发送更多的SYN请求来占满并且维护半连接队列当中的连接也是需要成本的。
于是TCP为了防范SYN洪水攻击引入了syncookie机制
开启 syncookies 功能就可以在不使用 SYN 半连接队列的情况下成功建立连接相当于绕过了 SYN 半连接来建立连接。
syncookie的工作机制如下 当服务器收到一个SYN请求时它会生成一个加密的SYN cookie该cookie包含了客户端的IP地址、端口号和服务器使用的一些其他信息并将cookie 值放到第二次握手报文的「序列号」里然后服务端回第二次握手给客户端 服务器不会保存任何关于该SYN连接的状态即该链接不会进入半连接队列中但是服务器会保存cookie的值。 客户端收到SYN ACK应答后会解析其中的SYN cookie并将其存储起来。 客户端发送带有解析出的SYN cookie的ACK应答给服务器。 服务器接收到ACK应答后会验证ACK中的SYN cookie是否有效。如果有效服务器会根据SYN cookie中的信息创建连接(进入全连接队列)并提供服务。
可以看到当开启了 tcp_syncookies 了即使受到 SYN 攻击而导致半队列满时也能保证正常的连接成功建立。
通过使用syncookie机制服务器可以避免存储大量未完成的连接状态从而抵御SYN洪水攻击。这种机制的优势是能够快速且有效地处理大量的SYN请求并且不需要为每个半连接维护状态信息减少了服务器的负担。
net.ipv4.tcp_syncookies 参数主要有以下三个值
0 值表示关闭该功能1 值表示仅当 SYN 半连接队列放不下时再启用它2 值表示无条件开启功能
那么在应对 SYN 攻击时只需要设置为 1 即可。 二、使用Wireshark分析TCP通信流程
wireshark是 windows 下的一个网络抓包工具. 虽然 Linux 命令行中有 tcpdump 工具同样能完成抓包,但是 tcpdump 是纯命令行界面,使用起来不如 wireshark 方便。
下载 wireshark 打开wireshark 2.6.5主界面如下选择对应的网卡(这里我们选择WLAN)点击即可进行捕获该网络信息开始抓取网络包。 在使用Wireshark时可以通过设置过滤器来抓取满足要求的数据包。 针对IP进行过滤
抓取指定源地址的包ip.src 源IP地址。抓取指定目的地址的包ip.dst 目的IP地址。抓取源或目的地址满足要求的包ip.addr IP地址等价于ip.src 源IP地址 or ip.dst 目的IP地址。抓取除指定IP地址之外的包!(表达式)。
针对协议进行过滤
抓取指定协议的包协议名只能小写。抓取多种指定协议的包协议名1 or协议名2。抓取除指定协议之外的包not 协议名 或 !协议名。
针对端口进行过滤以TCP协议为例
抓取指定端口的包tcp.port 端口号。抓取多个指定端口的包tcp.port 2048抓取端口号高于2048的包。
针对长度和内容进行过滤
抓取指定长度的包udp.length 30 http.content_length 20。抓取指定内容的包http.request.urimatches 指定内容。 这里我们抓取指定源IP地址或目的IP地址的数据包选择完毕记得按回车。 在windows 的CMD使用 telnet 作为客户端连接上服务器 telnet [ip] [port] 当我们用telnet命令连接该服务器后就可以抓取到三次握手时双方交互的数据包。 而当我们退出telnet连接后就可以抓取到四次挥手时双方交互的数据包。此处四次挥手时进行了捎带应答第二次挥手和第三次挥手合并在了一起第二个包不是TCP数据包是SSH数据包
在 TCP 挥手过程中「没有数据要发送」并且「开启了 TCP 延迟确认机制」那么第二和第三次挥手就会合并传输这样就出现了三次挥手。
