(python)为什么端口x向自己发出tcp连接请求,连接到的不是listen状态的x呢?_其他语言_编程问答 问题: (python)为什么端口x向自己发出tcp连接请求,连接到的不是listen状态的x呢?
描述:

问题如下:
我在python下测试端口X连接自己的例子,发现一个问题百思不得其解,希望大牛点播:
首先第一步:我在实验中对本机8000端口进行监听
然后第二步:从本机8000端口发出tcp连接,连接本机8000端口,这时我以为连接成功后,第一步监听的程序会返回一个连接后的sock,然而并不是这样,真相是第二步中8000发出的connect他返回的sock,可以自己进行send和recv
最后第三步:从本机8001端口发出tcp连接,连接本机8000端口,这时第一步中的监听成功返回连接的sock,这个sock就是第三步中8001与第一步中8000的连接

代码如下
第一步,终端一:
from socket import *
t1 = socket()
t1.setsockopt(SOL_SOCKET,SO_REUSEPORT,1)
t1.bind(("127.0.0.1",8000))
t1.listen(1)
s,a = t1.accept() //进入阻塞

第二步,终端二:
from socket import *
t2 = socket()
t2.setsockopt(SOL_SOCKET,SO_REUSEPORT,1)
t2.bind(("127.0.0.1",8000))
t2.connect(("127.0.0.1",8000)) //t1仍旧阻塞

第三步,终端三:
from socket import *
t3 = socket()
t3.bind(("127.0.0.1",8001))
t3.connect(("127.0.0.1",8000)) //这时t1返回连接sock

求问大牛,这是为什么??
为什么t3连接的是t1,但t2的连接的却是t2自己呢?
t2连接自己:

t3连接t1:



解决方案1:

python的socket默认是单进程状态,是堵塞的,所以支持多个进程绑定同一个端口,目的是当一个进程阻塞的时候,同一端口的其他空闲进程进行响应。
t2.connect很好理解啊,首先A端口connect B端口,那么A端口肯定也要listen啊,因为tcp是三次握手信号,所以connect默认listen不用像accept之前要先listen一下。所以t2 connect 8000的同时也listen 8000 那么t2和t1谁的距离近就不用说了吧,就近原则(或者底层lru缓存,t1 8000->t2 8000 connect 8000 t2)

上一篇如何调用多个文件夹中的python文件?
下一篇(python)如何在virtualenv中使用cx_Oracle这个包呢
明星图片
相关文章
《 (python)为什么端口x向自己发出tcp连接请求,连接到的不是listen状态的x呢?》由码蚁之家搜集整理于网络,
联系邮箱:mxgf168#qq.com(#改为@)