在本文中，我们将详细介绍被微信面麻了，问的太细节了的各个方面，同时，我们也将为您带来关于366tool微信域名防封系统，免费分享怎么样才能让被微信屏蔽的网址允许访问的教程、MySQL太细碎了，我硬生生

在本文中，我们将详细介绍被微信面麻了，问的太细节了的各个方面，同时，我们也将为您带来关于366tool微信域名防封系统，免费分享怎么样才能让被微信屏蔽的网址允许访问的教程、MySQL太细碎了，我硬生生捋出了一条核心大主线！、PHP随机获取未被微信屏蔽的域名(微信域名检测)、QQ/微信里被禁止访问的网页怎么处理 如何检测域名是否被微信封禁 屏蔽的有用知识。

本文目录一览：

• 被微信面麻了，问的太细节了
• 366tool微信域名防封系统，免费分享怎么样才能让被微信屏蔽的网址允许访问的教程
• MySQL太细碎了，我硬生生捋出了一条核心大主线！
• PHP随机获取未被微信屏蔽的域名(微信域名检测)
• QQ/微信里被禁止访问的网页怎么处理 如何检测域名是否被微信封禁 屏蔽

被微信面麻了，问的太细节了

大家好，我是小林。

上周有个读者在面试微信的时候，被问到既然打开 net.ipv4.tcp_tw_reuse 参数可以快速复用处于 TIME_WAIT 状态的 TCP 连接，那为什么 Linux 默认是关闭状态呢?

好家伙，真的问好细节!

当时看到读者这个问题的时候，我也是一脸懵逼的，经过我的一番思考后，终于知道怎么回答这题了。

其实这题在变相问「如果 TIME_WAIT 状态持续时间过短或者没有，会有什么问题?」

因为开启 tcp_tw_reuse 参数可以快速复用处于 TIME_WAIT 状态的 TCP 连接时，相当于缩短了 TIME_WAIT 状态的持续时间。

可能有的同学会问说，使用 tcp_tw_reuse 快速复用处于 TIME_WAIT 状态的 TCP 连接时，是需要保证 net.ipv4.tcp_timestamps 参数是开启的(默认是开启的)，而 tcp_timestamps 参数可以避免旧连接的延迟报文，这不是解决了没有 TIME_WAIT 状态时的问题了吗?

是解决部分问题，但是不能完全解决，接下来，我跟大家聊聊这个问题。

什么是 TIME_WAIT 状态?

TCP 四次挥手过程，如下图：

客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态服务器收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。客户端在经过 2MSL 一段时间后，自动进入 CLOSE 状态，至此客户端也完成连接的关闭。你可以看到，两个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。

这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。

可以看到，TIME_WAIT 是「主动关闭方」断开连接时的最后一个状态，该状态会持续 2MSL(Maximum Segment Lifetime) 时长，之后进入CLOSED 状态。

MSL 指的是 TCP 协议中任何报文在网络上最大的生存时间，任何超过这个时间的数据都将被丢弃。虽然 RFC 793 规定 MSL 为 2 分钟，但是在实际实现的时候会有所不同，比如 Linux 默认为 30 秒，那么 2MSL 就是 60 秒。

MSL 是由网络层的 IP 包中的 TTL 来保证的，TTL 是 IP 头部的一个字段，用于设置一个数据报可经过的路由器的数量上限。报文每经过一次路由器的转发，IP 头部的 TTL 字段就会减 1，减到 0 时报文就被丢弃。

MSL 与 TTL 的区别：MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。

TTL 的值一般是 64，Linux 将 MSL 设置为 30 秒，意味着 Linux 认为数据报文经过 64 个路由器的时间不会超过 30 秒，如果超过了，就认为报文已经消失在网络中了。

为什么要设计 TIME_WAIT 状态?

设计 TIME_WAIT 状态，主要有两个原因：

防止历史连接中的数据，被后面相同四元组的连接错误的接收;保证「被动关闭连接」的一方，能被正确的关闭;

原因一：防止历史连接中的数据，被后面相同四元组的连接错误的接收

为了能更好的理解这个原因，我们先来了解序列号(SEQ)和初始序列号(ISN)。

序列号，是 TCP 一个头部字段，标识了 TCP 发送端到 TCP 接收端的数据流的一个字节，因为 TCP 是面向字节流的可靠协议，为了保证消息的顺序性和可靠性，TCP 为每个传输方向上的每个字节都赋予了一个编号，以便于传输成功后确认、丢失后重传以及在接收端保证不会乱序。序列号是一个 32 位的无符号数，因此在到达 4G 之后再循环回到 0。初始序列号，在 TCP 建立连接的时候，客户端和服务端都会各自生成一个初始序列号，它是基于时钟生成的一个随机数，来保证每个连接都拥有不同的初始序列号。初始化序列号可被视为一个 32 位的计数器，该计数器的数值每 4 微秒加 1，循环一次需要 4.55 小时。给大家抓了一个包，下图中的 Seq 就是序列号，其中红色框住的分别是客户端和服务端各自生成的初始序列号。

通过前面我们知道，序列号和初始化序列号并不是无限递增的，会发生回绕为初始值的情况，这意味着无法根据序列号来判断新老数据。

假设 TIME-WAIT 没有等待时间或时间过短，被延迟的数据包抵达后会发生什么呢?

服务端在关闭连接之前发送的 SEQ = 301 报文，被网络延迟了。接着，服务端以相同的四元组重新打开了新连接，前面被延迟的 SEQ = 301 这时抵达了客户端，而且该数据报文的序列号刚好在客户端接收窗口内，因此客户端会正常接收这个数据报文，但是这个数据报文是上一个连接残留下来的，这样就产生数据错乱等严重的问题。为了防止历史连接中的数据，被后面相同四元组的连接错误的接收，因此 TCP 设计了 TIME_WAIT 状态，状态会持续 2MSL 时长，这个时间足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。

原因二：保证「被动关闭连接」的一方，能被正确的关闭

如果客户端(主动关闭方)最后一次 ACK 报文(第四次挥手)在网络中丢失了，那么按照 TCP 可靠性原则，服务端(被动关闭方)会重发 FIN 报文。

假设客户端没有 TIME_WAIT 状态，而是在发完最后一次回 ACK 报文就直接进入 CLOSED 状态，如果该 ACK 报文丢失了，服务端则重传的 FIN 报文，而这时客户端已经进入到关闭状态了，在收到服务端重传的 FIN 报文后，就会回 RST 报文。

服务端收到这个 RST 并将其解释为一个错误(Connection reset by peer)，这对于一个可靠的协议来说不是一个优雅的终止方式。

为了防止这种情况出现，客户端必须等待足够长的时间确保对端收到 ACK，如果对端没有收到 ACK，那么就会触发 TCP 重传机制，服务端会重新发送一个 FIN，这样一去一来刚好两个 MSL 的时间。

但是你可能会说重新发送的 ACK 还是有可能丢失啊，没错，但 TCP 已经等待了那么长的时间了，已经算仁至义尽了。

tcp_tw_reuse 是什么?

在 Linux 操作系统下，TIME_WAIT 状态的持续时间是 60 秒，这意味着这 60 秒内，客户端一直会占用着这个端口。要知道，端口资源也是有限的，一般可以开启的端口为 32768~61000 ，也可以通过如下参数设置指定范围：

net.ipv4.ip_local_port_range 那么，如果如果主动关闭连接方的 TIME_WAIT 状态过多，占满了所有端口资源，则会导致无法创建新连接。

不过，Linux 操作系统提供了两个可以系统参数来快速回收处于 TIME_WAIT 状态的连接，这两个参数都是默认关闭的：

net.ipv4.tcp_tw_reuse，如果开启该选项的话，客户端(连接发起方) 在调用 connect() 函数时，内核会随机找一个 TIME_WAIT 状态超过 1 秒的连接给新的连接复用，所以该选项只适用于连接发起方。net.ipv4.tcp_tw_recycle，如果开启该选项的话，允许处于 TIME_WAIT 状态的连接被快速回收，该参数在 NAT 的网络下是不安全的!详细见这篇文章介绍：字节面试：SYN 报文什么时候情况下会被丢弃?要使得上面这两个参数生效，有一个前提条件，就是要打开 TCP 时间戳，即 net.ipv4.tcp_timestamps=1(默认即为 1)。

开启了 tcp_timestamps 参数，TCP 头部就会使用时间戳选项，它有两个好处，一个是便于精确计算 RTT ，另一个是能防止序列号回绕(PAWS)，我们先来介绍这个功能。

序列号是一个 32 位的无符号整型，上限值是 4GB，超过 4GB 后就需要将序列号回绕进行重用。这在以前网速慢的年代不会造成什么问题，但在一个速度足够快的网络中传输大量数据时，序列号的回绕时间就会变短。如果序列号回绕的时间极短，我们就会再次面临之前延迟的报文抵达后序列号依然有效的问题。

为了解决这个问题，就需要有 TCP 时间戳。

试看下面的示例，假设 TCP 的发送窗口是 1 GB，并且使用了时间戳选项，发送方会为每个 TCP 报文分配时间戳数值，我们假设每个报文时间加 1，然后使用这个连接传输一个 6GB 大小的数据流。

32 位的序列号在时刻 D 和 E 之间回绕。假设在时刻B有一个报文丢失并被重传，又假设这个报文段在网络上绕了远路并在时刻 F 重新出现。如果 TCP 无法识别这个绕回的报文，那么数据完整性就会遭到破坏。

使用时间戳选项能够有效的防止上述问题，如果丢失的报文会在时刻 F 重新出现，由于它的时间戳为 2，小于最近的有效时间戳(5 或 6)，因此防回绕序列号算法(PAWS)会将其丢弃。

防回绕序列号算法要求连接双方维护最近一次收到的数据包的时间戳(Recent TSval)，每收到一个新数据包都会读取数据包中的时间戳值跟 Recent TSval 值做比较，如果发现收到的数据包中时间戳不是递增的，则表示该数据包是过期的，就会直接丢弃这个数据包。

为什么 tcp_tw_reuse 默认是关闭的?

通过前面这么多铺垫，终于可以说这个问题了。

开启 tcp_tw_reuse 会有什么风险呢?我觉得会有 2 个问题。

第一个问题

我们知道开启 tcp_tw_reuse 的同时，也需要开启 tcp_timestamps，意味着可以用时间戳的方式有效的判断回绕序列号的历史报文。

但是在看我看了防回绕序列号算法的源码后，发现对于 RST 报文的时间戳即使过期了，只要 RST 报文的序列号在对方的接收窗口内，也是能被接受的。

下面 tcp_validate_incoming 函数就是验证接收到的 TCP 报文是否合格的函数，其中第一步就会进行 PAWS 检查，由 tcp_paws_discard 函数负责。

static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb, const struct tcphdr *th, int syn_inerr)

{

struct tcp_sock *tp = tcp_sk(sk);

/* RFC1323: H1. Apply PAWS check first. */

if (tcp_fast_parse_options(sock_net(sk), skb, th, tp) &&

tp->rx_opt.saw_tstamp &&

tcp_paws_discard(sk, skb)) {

if (!th->rst) {

....

goto discard;

}

/* Reset is accepted even if it did not pass PAWS. */

} 当 tcp_paws_discard 返回 true，就代表报文是一个历史报文，于是就要丢弃这个报文。但是在丢掉这个报文的时候，会先判断是不是 RST 报文，如果不是 RST 报文，才会将报文丢掉。也就是说，即使 RST 报文是一个历史报文，并不会被丢弃。

假设有这样的场景，如下图：

客户端向一个还没有被服务端监听的端口发起了 HTTP 请求，接着服务端就会回 RST 报文给对方，很可惜的是 RST 报文被网络阻塞了。由于客户端迟迟没有收到 TCP 第二次握手，于是重发了 SYN 包，与此同时服务端已经开启了服务，监听了对应的端口。于是接下来，客户端和服务端就进行了 TCP 三次握手、数据传输(HTTP应答-响应)、四次挥手。因为客户端开启了 tcp_tw_reuse，于是快速复用 TIME_WAIT 状态的端口，又与服务端建立了一个与刚才相同的四元组的连接。接着，前面被网络延迟 RST 报文这时抵达了客户端，而且 RST 报文的序列号在客户端的接收窗口内，由于防回绕序列号算法不会防止过期的 RST，所以 RST 报文会被客户端接受了，于是客户端的连接就断开了。上面这个场景就是开启 tcp_tw_reuse 风险，因为快速复用 TIME_WAIT 状态的端口，导致新连接可能被回绕序列号的 RST 报文断开了，而如果不跳过 TIME_WAIT 状态，而是停留 2MSL 时长，那么这个 RST 报文就不会出现下一个新的连接。

可能大家会有这样的疑问，为什么 PAWS 检查要放过过期的 RST 报文。我翻了 RFC 1323 ，里面有一句提到：

It is recommended that RST segments NOT carry timestamps, and that RST segments be acceptable regardless of their timestamp. Old duplicate RST segments should be exceedingly unlikely, and their cleanup function should take precedence over timestamps.

大概的意思：建议 RST 段不携带时间戳，并且无论其时间戳如何，RST 段都是可接受的。老的重复的 RST 段应该是极不可能的，并且它们的清除功能应优先于时间戳。

RFC 1323 提到说收历史的 RST 报文是极不可能，之所以有这样的想法是因为 TIME_WAIT 状态持续的 2MSL 时间，足以让连接中的报文在网络中自然消失，所以认为按正常操作来说是不会发生的，因此认为清除连接优先于时间戳。

而我前面提到的案例，是因为开启了 tcp_tw_reuse 状态，跳过了 TIME_WAIT 状态，才发生的事情。

有同学会说，都经过一个 HTTP 请求了，延迟的 RST 报文竟然还会存活?

一个 HTTP 请求其实很快的，比如我下面这个抓包，只需要 0.2 秒就完成了，远小于 MSL，所以延迟的 RST 报文存活是有可能的。

第二个问题

开启 tcp_tw_reuse 来快速复用 TIME_WAIT 状态的连接，如果第四次挥手的 ACK 报文丢失了，有可能会导致被动关闭连接的一方不能被正常的关闭，如下图：

总结

tcp_tw_reuse 的作用是让客户端快速复用处于 TIME_WAIT 状态的端口，相当于跳过了 TIME_WAIT 状态，这可能会出现这样的两个问题：

历史 RST 报文可能会终止后面相同四元组的连接，因为 PAWS 检查到即使 RST 是过期的，也不会丢弃。如果第四次挥手的 ACK 报文丢失了，有可能被动关闭连接的一方不能被正常的关闭;虽然 TIME_WAIT 状态持续的时间是有一点长，显得很不友好，但是它被设计来就是用来避免发生乱七八糟的事情。

《UNIX网络编程》一书中却说道：TIME_WAIT 是我们的朋友，它是有助于我们的，不要试图避免这个状态，而是应该弄清楚它。

366tool微信域名防封系统，免费分享怎么样才能让被微信屏蔽的网址允许访问的教程

做微信广告域名、小说域名、影视域名或者H5网页域名的朋友是不是经常会遇到域名被微信拦截的问题，大多数的朋友都会抱怨为什么别人跟自己推的内容相似度极高，确可以高枕无忧地推广，而自己的域名一推刚起量就被封了。我可以告诉你他
们肯定用了市面上的防封技术。应此需求，特写了下面这篇文章分享一段自己研究微信域名防封的心得。

 

第一步：你需要有一个微信域名检测接口，目的是实时监测自己域名的访问状态。推荐使用r8date免费测试，快速而且
稳定，用这么久没出过问题。

第二步：配置你的程序，用三套域名A、B、C，比如说分享出去的域名是A，这里面A被称作是主域名，此方案可参考366TooL免费测试平台。

点开后跳到B，跳转之前检测一下B有没有被封，这里面的B就称作是落地域名。通常情况下落地域名B需要准备几十甚至上百个，利用域名检测接口可以轻松实现被封自动切换。

具体实现技术代码可参考：

<!DOCTYPE html>
<html xmlns="http://www.366tool.com/1999/xhtml">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <title>loading</title>
        <script type=text/javascript src="http://libs.baidu.com/jquery/1.9.0/jquery.min.js"></script>
    </head>
    
    <body>
        
        
    <script type="text/javascript">
        $(function () {
            get_share();
        });
        
        function get_share(){
            var user = getQueryString(''user'');
            var url = getQueryString(''url'');
            $.ajax({
             type: "get",
             async: false,
             url: ''http://api.weixin139.com/jumpurl/index/get_url.html'',
             data:{user:user,url:url},
             dataType: "jsonp",
             jsonp: "callback",
             jsonpCallback:"checkHandler",
             success: function(data){
                 window.location.href=data.url;
             },
         });
        }
        
        function getQueryString(name) {
            var reg = new RegExp("(^|&)" + name + "=([^&]*)(&|$)", "i");
            var r = window.location.search.substr(1).match(reg);
            if (r != null) return unescape(r[2]);
            return null;
        }
 
        </script>
 
    </body>
</html>

那C是干什么用的呢，微信早已改变了分享规则，通过JSSDK分享域名必须是公众号后台绑定域名，不能像以前那样想分享什么域名就可以分享什么域名了。

 

C域名专门用作分享，在B域名下触发分享条件以后跳到C域名，自定义分享出去以后，C域名从程序上设置又跳回到A。

 

这样A->B->C->A循环跳转

 

 

这样就有一个问题，如果A或者是C封了怎么办呢，大家可以自己研究一下我推荐的366tool的实现原理！

MySQL太细碎了，我硬生生捋出了一条核心大主线！

最近项目增加，缺人手，面试不少，但匹配的人少的可怜。跟其他组的面试官聊，他也抱怨了一番，说候选人有点儿花拳绣腿，回答问题不落地，拿面试最常问的MySQL来说，并不只是懂“增删改查”、表关联就万事大吉了。

千万条数据，走索引还是慢，怎么解决？

千万级数据，分库分表怎么做？

主从延迟怎么解决？

这些关于实践以及底层的问题会是面试时区分你和竞争者的一个关键指标，同时也会对我们的实际工作产生真正价值。

 

我们服务于业务，问题的根源也在于业务量极大或者场景复杂，面对这样的状况，我们需要清楚解决的基本逻辑。

（MySQL逻辑架构）

 

拿MySQL优化来说，主要分4个方向：SQL语句跟索引、表结构、系统配置、硬件。总优化思路就是最大化利用索引、尽可能避免全表扫描、减少无效数据查询：

1、减少数据访问：设置合理的字段类型，启用压缩，通过索引访问等减少磁盘 IO。

2、返回更少的数据：只返回需要的字段和数据分页处理，减少磁盘 IO 及网络 IO。

3、减少交互次数：批量 DML 操作，函数存储等减少数据连接次数。

4、减少服务器 CPU 开销：尽量减少数据库排序操作以及全表查询，减少 CPU 内存占用 。

5、分表分区：使用表分区，可以增加并行操作，更大限度利用 CPU 资源。

 

当然，掌握了这些基本原则，我们还是会面临一些难题。比如通过分表来解决大表问题，分表主键如何选择，分表后的跨表查询怎么解决？大事务会导致锁定太多的数据，造成大量的阻塞和超时，出现主从延迟，这要通过什么方式来改善？

MySQL确实是个庞杂的体系，掌握的越深入，我们能做的事情也就越多。

观察周围的大牛你就会发现，他们的关键特征之一，就是能解决别人解决不了的问题，一是懂，二是快，而我们首先要做的就是先在懂上吃透。

 

前段时间和玄姐（前58集团技术委员会主席、阿里云MVP、腾讯云TVP）聊，收获颇多。他谈到，以架构师的思路和视野学习 MySQL ，既能够夯实分库分表、分布式部署等核心技术点，又能够掌握普通开发者，难以触及的 MySQL 架构设计方法论。你在数据库层面，在工作中、团队里、面试时，也就拥有了同行难以复制的核心竞争力。

为帮助更多开发工程师、架构师掌握 MySQL 核心，玄姐联手快狗打车CTO沈剑老师，结合10多年一线大厂实践经验，打磨了一套《3天挑战架构师级MySQL海量数据设计与实践》在线专栏课。3天时间，名师将带你深入学习架构师级 MySQL，掌握核心架构技术，并在千亿级企业真实海量数据案例中（电商、微信等），培养你的 MySQL 实战能力。

原价 ¥ 499 ，限时  ¥9.8 立刻学习！

还能免费领【 10套私房干货视频合集 】

和【 阿里、字节必问面试题 】

本公号仅 前50名有效，先到先得

课程原价499，现在花 9.8 就能拿下，半杯奶茶，换来名师精心打磨的千亿级企业MySQL架构师技术实战课，相当划算！ 5 月17 - 19日，20:00-22:00 ，3天精讲 ，绝对是市面上非常高质量的一门MySQL架构设计实践精品课， 也是P7架构师必须掌握的核心技能！

勤学福利：除了免费资料外，上课学习期间还有好礼等你拿，活动真实有效，记得联系助教老师哦~

01

我为什么向你推荐这门课？

3天时间，搞定3大核心知识点。 主讲东哥将结合他在58集团的高级架构师经验，手把手带你掌握 MySQL 架构体系设计，揭秘存储、锁、事务等核心技术原理，并在腾讯、阿里的真实项目中，加深你对分库分表等核心技能的理解。

模块一：MySQL 架构体系深入剖析

全面拆解 MySQL 架构体系设计，教会你如何通过架构师的视角，审视数据库核心架构的技术要点，彻底拆解存储引擎、锁、事务原理与架构设计。

模块二：千亿级海量数据分库分表方法论

深入讲解在千亿级海量数据并发场景下，MySQL 如何通过分库分表方案，满足业务需求，同时解读一线大厂惯用的分库分表方法论，助你轻松搞定面试难题。

模块三：真实案例实战篇

彻底揭秘电商平台商品数据、推送消息数据等分库分表真实案例实战，同时包含，万亿级微信消息数据真实场景解读，以及阿里巴巴 Seata 应用设计实战。

02

3天时间，你能学会什么？

通过学习，你将精通包括MySQL架构设计深入剖析篇、千亿级企业海量数据分库分表方法论提炼篇、千亿级企业海量数据真实案例设计与实践等核心实战内容，通过通俗易懂的企业案例式讲解，带你真正掌握架构师级MySQL海量数据设计与实践，从而在成为优秀架构师的路上越走越快！

在真实项目实践中，获取和提升以下能力：

• 掌握MySQL架构体系的设计原理；

• 掌握MySQL存储引擎、索引、事务等实现原理；

• 掌握千亿级企业海量数据分库分表设计方法论；

• 掌握海量数据分库分表带来的数据路由与分布式事务解决方案设计能力；

• 掌握千亿级企业海量数据真实案例（电商、微信等）设计与实践；

• 具备架构师灵活应用、优化和分析数据库的能力，再也不用担心微服务下数据分片的问题，具备应对海量数据存储的设计能力。

03

谁带你学？有哪些课程服务？

架构师级 MySQL 的真实项目实战课

你需要真正掌握它！

15个节点名师打造的干货内容

3天精讲

原价499，限时扫码9.8

体系化搞懂主流数据库 MySQL 实战！

还能免费领【10套私房干货视频合集】

和【阿里、字节必问面试题】

本公众号仅限 前50名 特惠购买

购买后请您耐心等待课程顾问通过

 

关于奈学教育

点击“ 阅读原文 ”，了解更多课程内容！

PHP教程
<?PHP
$url = "https://api.weixin139.com/weixin/domain/auto_check_list?user=xxx&key=xxx&type=1";
$con = get_msg($url);
$data = json_decode($con,true);
$count = count($data)-1;
$rand = rand(0,$count);
echo $data[$rand]['domain'];
function get_msg($url){
 $ch = curl_init();
 curl_setopt($ch,CURLOPT_TIMEOUT,1);
 curl_setopt($ch,CURLOPT_RETURNTRANSFER,CURLOPT_URL,$url);
 curl_setopt($ch,CURLOPT_SSL_VERIFYPEER,false);
 curl_setopt($ch,CURLOPT_SSL_VERIFYHOST,false);
 $data = curl_exec($ch);
 if($data){
  curl_close($ch);
  return $data;
 }else {
  $error = curl_errno($ch);
  curl_close($ch);
  return false;
 }
}