tcp连接建立后(tcp连接建立后无法收发数据)

TCP server 为什么一个端口可以建立多个连接？我一直对这个问题有个疑问，今天看到一个论坛里面的讨论，看到了一些回答，解决了我的疑惑，并且我搜索了一些其他资料，记录在这里。TCP server 可以，TCP client 也可以。一个套接字只能建立一个连接，无论对于 server 还是 client。TCP server 可以，TCP client 也可以。一个套接字只能建立一个连接，无论对于 server 还是 client。注意报错消息是：[Errno 106] (EISCONN) Transport endpoint is already connectedman 2 connect 说得很清楚了：Generally, connection-based protocol sockets may successfully connect() only once; connectionless protocol sockets may use connect() multiple times to change their association.就是说，TCP 套接字最多只能调用 connect 一次。那么，你的监听套接字调用 connect 了几次？来点有意思的。一个套接字不能连接两次，并不代表一个本地地址不能用两次，看！*加粗文字加粗文字*>>> import socket>>> s = socket.socket()# since Linux 3.9, 见 man 7 socket>>> s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)>>> s2 = socket.socket()>>> s2.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)>>> s.bind(('127.0.0.1', 12345))>>> s2.bind(('127.0.0.1', 12345))# 都可以使用同一本地地址来连接哦>>> s.connect(('127.0.0.1', 80))>>> s2.connect(('127.0.0.1', 4321))>>> netstat -npt | grep 12345(Not all processes could be identified, non-owned process infowill not be shown, you would have to be root to see it all.)tcp        0      0 127.0.0.1:4321          127.0.0.1:12345         ESTABLISHED 18284/python3tcp        0      0 127.0.0.1:12345         127.0.0.1:4321          ESTABLISHED 4568/python3tcp        0      0 127.0.0.1:80            127.0.0.1:12345         ESTABLISHED -tcp        0      0 127.0.0.1:12345         127.0.0.1:80            ESTABLISHED 4568/python3123456789101112131415161718端口重用引发的惨案再接下来分析：一个TCP连接需要由四元组来形成，即(src_ip,src_port,dst_ip,dst_port)。假设有客户端建立了连接(src_ip1,src_port1,dst_ip1,dst_port1)，那么，如果我们还有listen在(src_ip1,src_port1)，那么当(dst_ip1,dst_port1)发送消息过来，系统应该把消息给谁？所以就说明了客户端占用了某一端口时，该端口就不能被其它进程listen了。那么，对于有些童鞋，可能还有这样的疑问，是否一台机器就只能建立65535个连接了（端口16位限制）？非也，一个连接由四元组(src_ip,src_port,dst_ip,dst_port)形式，那么当(src_ip,src_port)一定时，变化的(dst_ip,dst_port)就可以建立更多连接了。可能有些童鞋还有疑问，作为一个服务器监控一个端口，比如80端口，它为什么可以建立上百万个连接？首先要明白一点，当accept出来后的新socket，它所占用的本地端口依然是80端口，很多新手都以为是一个新的随机端口。由四元组就很容易分析到了，同一个(src_ip,src_port)，它所对应的(dst_ip,dst_port)可以无穷变化，这样就可以建立很多个客户端的请求了。以后遇到奇怪的问题，可以简单的采用四元组原理分析一下了。网络编程释疑之：单台服务器上的并发TCP连接数可以有多少一个人也可以建立 TCP 连接呢希望对你有帮助，祝你好运！

socket底层是传输层的协议，主要是TCP和UDP 发生你说的这种情况，下面几种可能1、你打开的socket是udp，udp是不会确保消息送达目的端的，但是也不会出现每次都只接收到休眠前的第一条消息的情况。而且你描述的问题并不是udp通信，是tcp通信。2、你打开的socket是tcp，这种情况下，两端的主机要先进行三次握手，之后才能传输信息。三次握手之后，通信双方共同维持连接。一旦其中一方发送数据时发现，发送出去的数据无法及时收到对应的ack导致timeout，会进行一个延迟重发的操作，一旦延迟重发次数达到上限，便会发出终止数据包结束会话。很明显，服务端休眠时无法完成三次握手操作，这时客户端会终止此次tcp连接，转为不停发送探测数据包探测目标主机是否可达。这个时候发送的数据自然无法被接收到。3、缓存设置的问题，接着上面第三种可能性，当你发送数据的时候，实际上是先写入socket底层buff空间。然后将数据打包发出去。如果前面的数据没有及时发送出去导致buff溢出，后面再投向socket的信息会被丢掉。 4、以上都是我瞎扯的，服务器都休眠了你还想别人有回应，咋不上天？

什么是TCP呢？由三个单词组成的Transport Control Protocol，字面理解是传输控制协议，可以理解为比特同学要想在网络泳池里游泳，那么他必须学习传输层控制技能，并且要掌握相应的动作——协议，他才能在畅游世界网络这个超大型游泳池。TCP：一个传输层协议，提供Host-To-Host的可靠传输，支持全双工，是一个面向连接的协议。TCP工作在传输层，它的上层是应用层，应用就是人们常用的微信、抖音、王者荣耀等服务工作的协议。两台不同的设备使用微信聊天，发送语音，需要实现Host-To-Host的数据通信，那么就可以直接调用TCP协议进行。调用TCP通信时需要指定通信的端口，不同的端口对应不同应用，不同IP对应不同的主机，也就是不同的设备。这就涉及到网络地址——IP地址，工作在网络层，当然TCP层只负责把对应的IP地址和端口传给网络层即可，具体业务由网络层来实现。互联网层，即Network Layer，提供地址和地址间的通信，只关注地址到地址Address-To-Address间通信，具体设备间通信由数据链路层实现，数据链路层关注MAC地址间通信，具体的物理设备，传输介质由物理层负责。以上就是TCP/IP协议常用的层级分割，最终目的就是为Host-To-Host服务，实现应用到应用的通信服务。什么是连接和会话呢？连接事需要通信双方相互配合来实现的，是双方达成的一种即时的状态约定，保证通信双方都在线，都有能力为接下来的数据传输做出尽快的响应，我们称之为连接。连接是网络行为状态的记录，既然连接需要双方共同努力，那么就需要双方都有一个对象来记忆当前传输的数据类型，对方的端口、已经传输了多少，效率怎么样等等一些关注点。那么与之相关联的另一个名词会话（Session），是什么意思呢，会话是应用的行为。大家每次用微信聊天时都会有一个窗口，用来发送信息，你来我往，这个窗口中会有很多条信息，我们称之为会话，当我们在会话进行中，连接一定是在通信状态的。聊一会，累了，退出微信了，但是一般我们不会删除我们的会话内容，这时会话还在，但是连接已经中断。双工/单工问题想想自己理解的是什么？单工：任何时间，数据只能单向发送，单工至少需要一条线路半全双工：某一时候可以双向发送数据，至少需要一条线路全双工：任何时刻都可以双向发送数据，大于一条线路这里线路不一定真实存在物理线路，可能采用模拟的形式实现TCP是一个全双工协议，数据任何时刻都可以双向发送，这说明服务器和客户端可以根据需要选择任意时刻发送和接收信息，所以呢都可以被称为主机（Host）可靠性的定义TCP可以提供可靠性，那么可靠性具体的实现方式是什么呢？可靠性指数据无损传输。发送主机按照顺序发送数据，数据通过网络传输，收不同网络条件限制，数据不会按照发送时的顺序到达接收方，这时我们就需要一种算法来保证接收方可以还原出发送方的顺序。这里还有一个概念叫多播，发送方同时发送给多个接收方信息，如果接收方中有一个接收到了这条信息，我们的可靠性就必须保证其他接收方也必须接收到相同的信息，这里我们不讨论多播。TCP的握手和挥手TCP是一个面向连接的连接的协议，握手是建立连接的过程，挥手是断开连接的过程。TCP的基本操作以上三种操作以后，另一方必须立即给发起方返回一个ACK（Ackknowledgement），这是TCP保证可靠性的要求。如果一方不回复发送方ACK，发送方则认为接收方没有收到信息，会重新发送。建立连接的过程-三次握手三次握手的形成和TCP要求每次发送方发送信息以后，接收方必须返回ACK确认有直接的关系上图描述了TCP建立连接的过程，分为6步：TCP建立连接的过程如上，那么为什么是三次呢？第二步服务端做准备，因为是首次收到发送数据请求，无需处理，可以立刻进入数据交互状态，所以可以立刻发送给客户端SYN，告诉客户端，我已准备好，所以第三步和第四步可以合并为一次握手——ACK-SYN，然后客户端回应ACK，连接建立完成以上就是三次握手了具体在数据交互过程，ACK和SYN等需要用标识位来标记，在实际应用中，我们一般使用1来表示开启，0表示关闭。那么四次挥手为什么是四次呢，主要是因为，挥手时服务端收到FIN以后，不能马上回复FIN，因为自身还有任务没有处理完，所以上面所说的6步中，第3、4步就不能一起回复，只能先回复ACK，等自身任务处理完毕，才能告诉客户端，我已经准备好，可以关闭连接，这样就需要4次数据交互，如下图：

TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次连接通信过程中必不可少的。因此，运输连接就有三个阶段：连接建立，数据传送和连接释放。需要解决以下3个问题：连接建立这个过程，需要在客户端和服务器之间，交换3个TCP报文段，也就是三次握手????x3。????请注意，在本例中，A主动打开连接，B被动打开连接一开始，B就在准备接受客户进程的连接请求，然后服务器进程就处于 LISTEN （收听）状态，等待客户的连接请求。如有，即作出响应。A的TCP客户进程像B发出连接请求报文段，这时，首部中的同步位SYN = 1，同时选择一个初始序号 seq = x 。TCP规定????，SYN报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。B收到连接请求的报文段后，如同意建立连接，则向A发送确认。在确认报文段中，应把SYN位和ASK位都置1，确认号是 ack = x + 1 ，同时也为自己选择一个初始序号 seq = y 。请注意，这个报文段也不能携带数据。但同样要消耗掉一个序号。这时，TCP服务器进程进入SYN-RCVD（同步收到）状态。TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号 ack = y + 1 ，而自己的序号 seq = x + 1 。TCP的标准规定????，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是 seq = x +1 。这时，TCP连接已经建立????，A进入ESTABLISHED（已建立连接）状态。当B收到A的确认后，也进入ESTABLISHED（已建立连接）???? Q:为什么A最后还有发送一次确认呢？????A:主要是为了防止已失效的连接请求报文段突然又传送到B，因而产生错误。所谓“已失效的连接请求报文段”是这样产生的。????考虑一种正常情况，A 发出连接请求????，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发出了两个连接请求的报文段，其中第一个丢失????，第二个到达了B????，没有“已失效的连接请求报文段”。????现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某个网络节点长时间的滞留????，以至延误到连接释放以后的某个时间才到达B。本来这是一个 早已失效的报文段 ，但是B收到此时小的连接请求的报文段之后，误以为是A又发出一次新的连接请求。于是向A发出确认报文段，同意建立连接。假定不采用报文握手。那么只要B发出确认之后，新的连接就建立了。由于现在A并没有发出建立连接的请求，因此不会理睬B的确认????，也不会向B发送数据，但B确以为新的运输连接已经建立，并一直等待A发来的数据。B的许多资源就这样白白浪费了。

① idle（空闲）：idle是bgp连接的第一个状态，在空闲状态，bgp在等待一个启动事件，启动事件出现以后，bgp初始化资源，复位连接重试计时器（connect-retry），发起一条tcp连接，同时转入connect（连接）状态。②connect（连接）：在connect状态，bgp发起第一个tcp连接，如果连接重试计时器（connect-retry）超时，就重新发起tcp连接，并继续保持在connect状态，如果tcp连接成功，就转入opensent状态，如果tcp连接失败，就转入active状态。③active（活跃）：在active状态，bgp总是在试图建立tcp连接，如果连接重试计时器（connect-retry）超时，就退回到connect状态，如果tcp连接成功，就转入opensent状态，如果tcp连接失败，就继续保持在active状态，并继续发起tcp连接。④opensent（打开消息已发送）：在opensent状态，tcp连接已经建立，bgp也已经发送了第一个open报文，剩下的工作，bgp就在等待其对等体发送open报文。并对收到的open报文进行正确性检查，如果有错误，系统就会发送一条出错通知消息并退回到idle状态，如果没有错误，bgp就开始发送keepalive报文，并复位keepalive计时器，开始计时。同时转入openconfirm状态。⑤openconfirm（打开消息确认）状态：在openconfirm状态，bgp发送一个keepalive报文，同时复位保持计时器，如果收到了一个keepalive报文，就转入established阶段，bgp邻居关系就建立起来了。如果tcp连接中断，就退回到idle状态。⑥established（连接已建立）：在established状态，bgp邻居关系已经建立，这时，bgp将和它的邻居们交换update 报文，同时复位保持计时器。