关于某墙的端口封锁

[plan9]

最近看到好多人发帖说到墙会封锁端口,个人感觉这个端口应该不是墙干的,而是你的服务商干的

因为好多服务商提供给你的都是一个局域网的ip,而公网ip是由好多人共有的,但是一个ip只能有6万多个端口,所以如果你长时间使用某个端口的,可能会被你的服务商切断连接,或者你所在的ip已经使用了超过单个ip最大端口数也会被切断连接

判断是否是这种原因的话很简单,过一段时间再连接同样的端口试试,如果可以连接的话应该就是这个问题

比如你用浏览器去下载一下大文件,经常出现下着下着就断了的情况,这种情况也有很大原因是你使用的是局域网ip

而对于最近这次墙的升级,个人感觉改用udp的openvpn应该会有一定的作用,不过这个我没试过,不知道是否准确,大家被封的vpn都是什么类型的?

[Kymair]

@plan9 在端口复用这个上面，@cabbala 确实是对的，你在本地做一个实验即可。

或者参考我的结果
https://gist.github.com/4361955

[Kymair]

http://gist.github.com/4361955

[plan9]

@Kymair
netstat显示的只是监听用端口吧?
实际上服务器会打开一个新的端口连接的,当然这里的端口理解成文件描述符比较好

[Kymair]

@plan9 你可以看到我是按IP grep的，除了80以外并没有新的连接产生。

[plan9]

@Kymair
我的意思是netstat命令应该只是显示监听的端口
比如你通过80连接服务器,然后跟服务器通信的时候会使用另外一个端口,但是netstat显示的只是你监听的端口

上面这句话前半句有依据,后半句没有...

[clino]

@plan9 "你不可能一个端口同时跟两台机器进行通信把?"这有什么不可能的?对于服务端程序来说,对于提供nat服务的ip来说都是必须具备的能力.

[Kymair]

@plan9 不是。你可以google "single port multiple connectionss site:stackoverflow.com" 读一下那几个问题和回答。

[Kymair]

@plan9 :-) 我觉得在谈到“连接”时很容易产生一种错觉，时常误以为真有像电话网络那样的独占连接存在，但TCP/IP是基于包的。
IP只是为了找到对应的host, port只是为了找到对应host上的对应process. 多个client同时连接server的同一个端口是没问题的，server内部是可以用source IP, source port区分开来的。

[plan9]

@clino
tcp通信中ip是用来区别不同机器的,而端口是来区别同一个机器的里不同服务的
每当你连接外部的服务器的时候,系统会自动分配给你一个端口,这个端口是不重复的
而服务端,我已经说了很多次了,通信的用端口并不是监听的端口,服务器端会打开一个新的端口来与client进行通信,而原来的监听用的端口会继续对过来的连接进行监听

>>另外补充一个Linux的iptables内的NAT特性，它会尽量保持端口不变。就如我的例子中所说的那样，192.168.0.2和192.168.0.3的sport都是8888，它通过NAT转换后，端口也是8888，除非这个端口被提前用作它用。
如果NAT只是将源地址替换成一个IP地址，端口保持不变的话是无法区分两个连接的，所以NAT后会修改其中一个源端口的

根据Kymair讲的,路由会维护一个port pool,这个prot pool应该就是保证端口不重复的

[plan9]

@Kymair
可能我说的不清楚...
一般写tcp程序的时候
服务端通常会
bind(),listen(),accept(),而accept会返回一个新的文件描述符,服务器通过这个文件描述符与客户端进行通信,这就是我说的服务端会通过新的端口与客户端进行通信

而客户端会socket(),connect(),而socket也会返回一个新的文件描述符,这也就是我说的没建立一个新的连接,都会分配一个新的端口的意思

[rankjie]

看了此贴，我又默默抱起了我的 [数据通信与网络] ...走了...

[plan9]

@Kymair
我理解你的意思了,你说的是不考虑这个[虚拟的连接]的情况,单纯从tcp/ip来看,只是一些包而已
我考虑的是假想这个连接是真是存在的,而process之间正是通过这个虚拟的连接来进行通信的

角度不一样,看待问题的方式也不一样,所以产生了分歧

[enj0y]

楼主说得不对。想想可能么？香港、美国、日本，所有机房都这样做了？

[clino]

@plan9 "通信的用端口并不是监听的端口,服务器端会打开一个新的端口来与client进行通信,而原来的监听用的端口会继续对过来的连接进行监听" 你真的确定是这样吗?实际情况是这样吗? 你这样的说法我能不能得出一个服务端ip连接的客户端不能超过65535?
那你看看这篇"完成端口模型：并发连接数达到9.1万！ " http://zhanyonhu.blog.163.com/blog/static/16186044201042055221518/
再参考这篇 "单机最大tcp连接数" http://wanshi.iteye.com/blog/1256282

nat服务程序和服务端程序的行为差别主要在于nat服务需要对接受和发送的包做地址替换,这部分其实我之前贴的已经解释清楚了,只是你不认真去看而已

[clino]

@plan9 才看到你说的这句"而客户端会socket(),connect(),而socket也会返回一个新的文件描述符,这也就是我说的没建立一个新的连接,都会分配一个新的端口的意思"
原来你说的文件描述符等同于"端口"啊...
那你知道你所谓的这个"端口"的限制是多少?是65535吗?

[plan9]

@clino
非要逼我去查书...
UNIX网络编程 第四章第六节
他们返回的实际上是文件描述符,但是书中写的是返回的是一个socket,每个socket都有自己的ip跟端口
监听用的socket称作listening socket,通信用的socket称作connected socket

而且问了一下,linux内核每次新建一个socket确实会分配一个新的端口

[clino]

@plan9 "而且问了一下,linux内核每次新建一个socket确实会分配一个新的端口" 这句话依据在哪里??? 照你这么说一台 http 服务器的80端口根本不可能并发超过 65535 个客户端连接.

那么再贴几个链接:
http://www.cnblogs.com/Solstice/archive/2011/07/01/2095411.html

在真实的 Linux 系统中，可以通过调整内核参数来支持上百万并发连接，具体做法见：
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3

至于nat服务的实现,根本不可能使用 socket 编程接口,因为实际上nat是对tcp协议的hack

[plan9]

@clino 内核会分配端口跟修改内核参数可以支持65535以上兵法有矛盾吗？

nat前面已经有人回答了，路由会维护一个port pool，也会分配端口的，我没说路由是用socket接口实现的

[clino]

@plan9 另外也可以去google下 "linux kernel tuning for c500k"

你的想法看起来也是不稀奇的,被称为"The 64k Connection Myth"

看这段的最后一句,如果这种想法是对的,那么DDoS将会是非常容易的
"The 64k Connection Myth

It’s a common misconception that you can only accept 64,000 connections per IP address and the only way around it is to add more IPs. This is absolutely false.

The misconception begins with the premise that there are only so many ephemeral ports per IP. The truth is that the limit is based on the IP pair, or said another way, the client and server IPs together. A single client IP can connect to a server IP 64,000 times and so can another client IP.

Were this myth true it would be a significant and easy-to-exploit DDoS vector."

[clino]

@plan9 "内核会分配端口跟修改内核参数可以支持65535以上兵法有矛盾吗" 你看到的内核参数修改是修改支持65535端口吗? TCP协议没有对65535这个端口上限做限制吗?你自己修改了内核参数就可以突破TCP协议的限制吗?