2、如果是本地，可以先暂时选择跳过域名校验
在项目设置中选择
勾选就好了
一：TCP建立过程
1服务器先创建TCB(传输控制块),准备接受客户端的连接请求，然后服务器处于listen状态
2客户端创建TCB，准备发送请求连接报文段，此时首部的同步位syn=1(syn不携带数据，所以要消耗一个序列号)，选择一个初始序号seq=x,然后这时候，客户端从closed状态->syn-sent(同步已发送)状态。
3服务器接收请求报文，同意连接之后，则向客户端发送确认报文，此时确认报文同部位syn=1,ACK=1,
确认号ack=x+1,但是syn=1，会消耗一个序号，所以要设置seq=y。此时服务器的状态是syn-rcvd(同步已接收)。
4客户端接收确认报文，还要向服务器发送确认报文，确认报文ACK=1,确认号为ack=y+1,因为ACK可以携带数据，不需要消耗序号。发送完之后，这时候客户端处于established状态
5服务器收到确认报文，这时候也处于了established状态。
PS：同步位syn=1，不携带数据段，所以需要消耗一个序列号，而ACK可以携带数据段。
二：为什么客户端最后一次还需要发送一次确认。
这主要为了防止已失效的连接请求报文段突然传到服务端，因而产生错误。
三：TCP三次握手的缺陷
1SYN FLOOD攻击
SYN-FLOOD是一种常见的DDos攻击，拒绝服务攻击。通过网络服务所在的端口发送大量伪造原地址的攻击报文，发送到服务端，造成服务端上的半开连接队列被占满，从而阻止其他用户进行访问。
它的数据报特征是大量syn包，并且缺少最后一步的ACK回复。
原理：攻击者首先伪造地址，对服务器发起syn请求，服务器回应syn+ACK，而真实的IP会认为我没有发送请求，不做回应，而服务端没有收到回应，服务器就不知道是否发送成功，默认情况下重试5次 syn_retries，这样的话，对于服务器内存和带宽有很大的消耗。
2解决SYN FLOOD方法
(1)无效连接监控
不停监视半开连接和不活动连接，当半开连接数和不活动连接数到达一定值时候，就释放系统资源。
伤敌1000，自损8000
(2)延缓TCB方法
SYN FLOOD的关键是利用了，syn数据报一到，系统就分配TCB资源。
那么我们有两种方法资源问题
Syn cache
这种技术在收到Syn时不急着分配TCB，而是先回应一个ACK报文，并在一个专用的HASH表中保存这种连接，直到收到正确的ACK，才分配TCB。
(3)Syn Cookie
用一种特殊的算法生成sequence number，算法考虑到对方的信息和己方信息，收到对方的ACK报文后，验证之后才决定是否生成TCB
环境：服务器系统：centos 72
站点环境：nginx
遇到问题：
1、微信小程序端请求服务器登陆接口，服务端收到请求后向微信接口服务器请求数据，请求成功后返回数据给客户端，但是请求微信接口服务器经常性出现超时问题，请求超时时间设置成10S依然会提示超时，只有偶尔的一两次会请求成功；
解决方法：
1、首先在服务器上通过终端先ping一下微信的接口域名：apiweixinqqcom;如果发现域名解析ip地址时间非常长的话说明是dns解析超时的问题；
2、找到原因后，更改服务器etc/resolvconf文件中的dns服务器地址
你可以测试一下哪个dns在你服务器上解析速度最快你就把相应的ip地址放到最上面就可以了；
3、基本上你调整过之后，你在访问微信的登陆授权接口基本上就是毫秒级别的；
备注：windows系统的服务器如果也是dns解析慢的问题，也可以参考这种方式进行修改，不过估计文件路径不一样可以自行百度；
小程序的>
欢迎分享，转载请注明来源：内存溢出
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）