为什么端口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仍旧阻塞

clipboard.png

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

clipboard.png

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

t3连接t1:

clipboard.png
clipboard.png

阅读 2.4k
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)

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题