transport := &http.Transport{
Proxy: func(request *http.Request) (u *url.URL, err error) {
host, ok := <-scannerChan
if !ok {
return nil, errors.New("scanner channel closed")
}
return &url.URL{Host: fmt.Sprintf("%s:%s", ip, port)}, nil
},
//Proxy: http.ProxyURL(&url.URL{Host: fmt.Sprintf("%s:%s", ip, port)}),
DialContext: (&net.Dialer{
KeepAlive: -1,
}).DialContext,
DisableKeepAlives: true,
MaxIdleConns: 1000,
MaxIdleConnsPerHost: -1,
MaxConnsPerHost: 0,
IdleConnTimeout: 0,
DisableCompression: true,
}

#23 说得对

@tim0991 #24 可以并发啊，Transport.Proxy 只是一个函数，每次请求都会调用。你对 scanner 封装成一个闭包函数就可以了。

Google 一下 too many time wait 就知道啦，就是修改内核参数。

但是感觉这个不是正确的思路。

我会选择编写自己的 proxy 函数，每次返回一个 ip port，这样就可以只用一个 httpClient 和一个 httpTransport，就可以利用 MaxIdleConnsPerHost，控制打开的连接数。

Google 一下 too many time wait"

在本机测试了一下，结论 TIMEWAIT 太多，TIMEWAIT 都会占用 fd

试一下在关闭之前：
io.Copy(ioutil.Discard, resp.Body)

@skyeycirno 机票没有黄牛，是因为机票一直都是实名制购票！

如果你所理解的黄牛，就是那群坐在电脑前帮人购票并收取佣金的人。
请问你订购机票的时候，你是直接到 GDS 上订机票的吗？不是，你是经过一个“代理”，去 GDS 上订购机票，还要支付他费用。这个“代理”就是你今天所理解的“黄牛”。

补充#74，如果要绝对平等，那就用最原始的方式，无论社会地位高低，无论贫富，无论是否有知识，打一架，打赢的有火车票。
如果要绝对公平，对不起，没有绝对公平。公平是行政手段，改变每一个人能力值，让强者多一点障碍，让弱者多一点优势。但无论你出台什么政策，都会有反对声音。

最后，不要尝试用你的技术思维想着怎么改变社会问题。

楼主的提问很有意思，也反映很多人还没理解问题的时候，就开始想答案。

楼主有两个问号：如果你来设计 12306，怎么杜绝或者抑制黄牛？现在想想，有什么设计可以让真正需要的人买到票吗？
但其实这两个问题并不是同一个问题。

如果你来设计 12306，怎么杜绝或者抑制黄牛？
首先，什么是黄牛，我的理解，黄牛就是可以屯着票倒卖，如果票卖不出去，就丢掉或者退票，最终造成社会资源的浪费。在使用实名制购票的机制下，已经有效地抑制黄牛的活动——没有人能够囤票。（当然，内部操作那些已经不是 12306 能够解决的范畴了）

有什么设计可以让真正需要的人买到票吗？
问这个问题之前，首先要问问，我们火车有浪费掉的座位吗？难道最终拿着票坐上火车的人，就不是真正需要买票的人吗？你总不能说你买不到票，就说真正需要火车票的人买不到票吧？

最后之所以还有人不满，有两个原因，运力不足——更深层的是地区发展不平衡，这个不多说了。
另一个是“公平”还是“平等”的问题。
有人用技术手段抢票，有人手动抢，这叫不公平，但这是平等的。
那让不会使用电脑的人先买票吧，会用的电脑的晚一点买，这叫公平，但不平等。
这个问题无解。

楼主的提问很有意思，也反映很多人还没理解问题的时候，就开始想答案。

楼主有两个问号：如果你来设计 12306，怎么杜绝或者抑制黄牛？现在想想，有什么设计可以让真正需要的人买到票吗？

和老师在同一个城市里奋斗，不好吗？

每天早上回公司，就是 update 所有软件和环境……

提供 http 服务的那个程序，是不是从 udp 读取数据啊？如果没有设置超时时间，而服务端又没有返回，或者数据丢了，都会导致客户端一直等待的哦。最好把你连接 udp 的函数贴一下

@koebehshian 你还能看到状态，你确定你的情况是 udp 链接越来越多？

@Immortal #3 udp 没有状态的

TLV 了解下

先丢进 KafKa 啊，数据库慢慢挑，估计你现在只管采集，连怎么使用数据都不知道

只留本科和硕士的经历就够啦

排序再拼接，一般是用于 query 参数的处理，你无法确保 client 的签名是 key 的顺序与 server 签名时 key 的顺序一致，所以一般会约定先按 key 排序再签名
body 的参数不应该篡改，直接当做 byte 数组进行签名
签名信息一般放在 header 中直接提取，而不是像你例子中那样，需要反序列化之后才能提取，这样多浪费计算资源