linuxtcp断开触发

⑴ linux C 进行TCP网络连接，怎样设置连接超时时间

如果你确定,真的不需要等这么久,或者用户希望可以随时中上连接过程,那么一般是用 非阻塞模式来做的. 看看我的这段连接代码(节选),可以作为TCP连接的典范:

bool CRemoteLink::Connect()
{
OnDisconnected(); // 如果已经连接，则断开

if(!m_bUseProxy)
{

m_iConnStatus = SS_CONNECTING; // 正在连接状态
GNTRACE ("开始连接到远程服务器[%s][%ld]...\n", m_strip.c_str(), m_port);

// 建立套接字, 准备连接到服务器
m_socket = ::socket(AF_INET, SOCK_STREAM, 0);
if (socket < 0) {
if(m_pCallBack)
m_pCallBack->OnSocketError(SE_CREATE, MSG_SE_CREATE);
return false;
}

// 设为异步操作方式
unsigned long on = 1;
if (::ioctlsocket(m_socket, FIONBIO, &on) < 0) {
::closesocket(m_socket);
if(m_pCallBack)
m_pCallBack->OnSocketError(SE_CREATE, MSG_SE_CREATE);
return false;
}

sockaddr_in addr;
memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = inet_addr(m_strip.c_str());
addr.sin_port = htons(m_port);

int rt;
rt = ::connect(m_socket, (sockaddr *) &addr, sizeof(addr));
if (rt == 0) {
OnConnected();
return true;
}

// ==================================================================
timeval to;

// 首先建立连接
fd_set wfds;
fd_set efds;
FD_ZERO(&wfds);
FD_ZERO(&efds);

// test shutdown event each 100ms.
to.tv_sec = 0;
// CONNECT_TIMEOUT;
to.tv_usec = 100000;

int it = 0;
while(!m_meShutdown.Wait(0) && !m_meConnStop.Wait(0))
{
FD_SET(m_socket, &wfds);
FD_SET(m_socket, &efds);
int n = select(m_socket + 1, NULL, &wfds, &efds, &to);

if (n > 0) {
if(FD_ISSET(m_socket, &wfds))
{
OnConnected();
return true;
}
else
{
//int err = ::WSAGetLastError();
//const char* msg = GetLastErrorMessage(err);
GNTRACE ("CRemoteLink::Connect : connection attempt failed!\n");
if(m_pCallBack)
m_pCallBack->OnSocketError(SE_CONN, MSG_SE_CONN);
break;
}
} else if (n < 0) { // Select Error
int err = ::WSAGetLastError();
const char* msg = GetLastErrorMessage(err);
GNTRACE ("CRemoteLink::Connect : Select Error.[%d] - %s\n", err, msg);
if(m_pCallBack)
m_pCallBack->OnSocketError(err, msg);
break;
}
else
{
it += 100;
if(it > 30000) // 连接超时 -- (30S)
{
GNTRACE ("CRemoteLink::Connect : Time out.\n");
if(m_pCallBack)
m_pCallBack->OnSocketError(SE_TIMEOUT, MSG_SE_TIMEOUT);
break;
}
}
}
if(m_meConnStop.Wait(0))
{
GNTRACE("连接过程进行时被取消。\n");
}
}
else
{
// 通过代理服务器连接

⑵ 检查tcp 有没有断开 linux

client/server端recv：
①对端close(fd)检测(超时检测)：recv 返回0，说明缓存区数据被读完，实测两种情况，对端没有再发数据，对端fd被关闭了。
通过select超时来检测，当超时如2s，我们认为对端连接断开，应关闭本地的fd。
②网线断开/断电关机检测(超时检测)：recv 返回-1，errno == EAGAIN，意为“没有可读写数据,缓冲区无数据”。
所以此时需要select超时检测，若超时，要么对端没有再发数据，要么对端的网线断了或者直接断电了。
超过我们判定为对端不在线，关闭本地的fd。

⑶ linux中tcp连接断开重莲时服务器应该怎么处理

断开重连，还是需要重新建立tcp三次握手，建立连接。

⑷ Linux里面tcp和tcp6区别是什么

指代不同
TCP：是一种面向连接的、可靠的、基于字节流的传输层通信协议。
TCP6：是互联网工程任务组设计的用于替代ipv4的下一代ip协议。
功能不同
TCP：适应支持多网络应用的分层协议层次结构，连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。
TCP6：ipv6具有更大的地址空间，ipv4中规定ip长度为32，最大地址个数为2^32，IPv6中ip地址的长度为128，即最大地址个数为2^128。与32位地址空间对比，其地址空间增加了2^128-2^32个。
特点不同
TCP：TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。
TCP6：不仅能解决网络地址资源数量的问题，而且也解决了多种接入设备连入互联网的障碍。

⑸ Linux 下怎么释放 TCP 连接

先用ps命令找到哪些服务正在调用该阻塞的端口； 再用kill -s 19 #进程编号#暂停掉该项服务，也可以直接kill掉； 这样资源就释放出来了

⑹ linux tcp连接状态有哪些

TCP连接状态详解
LISTEN： 侦听来自远方的TCP端口的连接请求
SYN-SENT： 再发送连接请求后等待回匹配的连接请求
SYN-RECEIVED：再答收到和发送一个连接请求后等待对方对连接请求的确认
ESTABLISHED： 代表一个打开的连接
FIN-WAIT-1： 等待远程TCP连接中断请求，或先前的连接中断请求的确认
FIN-WAIT-2： 从远程TCP等待连接中断请求
CLOSE-WAIT： 等待从本地用户发来的连接中断请求
CLOSING： 等待远程TCP对连接中断的确认
LAST-ACK： 等待原来的发向远程TCP的连接中断请求的确认
TIME-WAIT： 等待足够的时间以确保远程TCP接收到连接中断请求的确认
CLOSED： 没有任何连接状态

⑺ 关于linux系统下TCP通信 服务器read函数一直读取数据却什么都读不到的问题

采用多线程编程，主进程负责等待连接到来，收到连接请求后父进程派生一个线程去处理该版通信过程，权通信处理交给该线程，父进程继续循环等待连接请求。通信结束，该线程结束。
当然也可以采用信号触发方式，当连接请求到来时，触发父进程派生一个线程去处理该请求。

⑻ 如何使用linux命令关闭一个socket

在linux的网络编程抄，特别是TCP的编程中，SIGPIPE信号错误是一个比较常见的问题，我猜测你是在使用TCP的socket吧，如果是这样的话，很有可能是你在向一个已经处于关闭状态的socket写数据，因为TCP是面向连接的协议。如果对方将socket给close掉了，而你还继续往这个socket写数据，就会触发这个信号。因此，建议你在write之前检查一下对方是否已经close掉了这个socket。如果回答得不对，可以继续追问哈

⑼ Linux中TCP通信中 send函数 如何判断 何时断开连接了

1 确认链路是否连通状态，最好加心跳机制， 如果一定时间没有收到心跳包，或者没有回复心跳
就应认为此链路已经坏掉了，需要关闭，重新连接！

2 至于发送数据，应该检查对应的api的返回值，是否已经成功发送或者接受定长数据！
没有完成应该重新发送或者接受

3 网络数据问题，可以用抓包工具直接抓包看数据，可以看的比较透彻
工具 Linux下用tcpmp，windows用wirekshark

⑽ c# TCP/IP 自动断开

TCP/IP建立与断开连接详细过程

TCP协议连接建立时3次握手的过程。

简述TCP协议连接建立时3次握手的过程。

根据TCP头部，说明下列3个包在连接建立过程中的次序.

...P..FI>.3.7...

................

004062b700564a2a01030302b..VJ*....（1）

.....P3.7.......

...............V

00404a2a0000000001030300J*........（2）

.....P3.7.FI>...

...K.......VJ6..

004062b7b.（3）

解：

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

1）是第二次握手，flags位上为12，二进制是00010010，即表示有syn和ack.

2）是第一次握手，flags位上为02，二进制是00000010，即表示有syn没有ack。

3）是第三次握手，flags位上为10，二进制是00010000，即表示有ack没有syn。

该连接访问的是80端口，是为HTTP（HyperTextTransportProtocol，超文本传输协议）开放的，

第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

完成三次握手，客户端与服务器开始传送数据。

tcp-断开连接:

主要部分，四次握手：

断开连接其实从我的角度看不区分客户端和服务器端，任何一方都可以调用close(orclosesocket)之类

的函数开始主动终止一个连接。这里先暂时说正常情况。当调用close函数断开一个连接时，主动断开的

一方发送FIN(finish报文给对方。有了之前的经验，我想你应该明白我说的FIN报文时什么东西。也就是

一个设置了FIN标志位的报文段。FIN报文也可能附加用户数据，如果这一方还有数据要发送时，将数据附

加到这个FIN报文时完全正常的。之后你会看到，这种附加报文还会有很多，例如ACK报文。我们所要把握

的原则是，TCP肯定会力所能及地达到最大效率，所以你能够想到的优化方法，我想TCP都会想到。

当被动关闭的一方收到FIN报文时，它会发送ACK确认报文(对于ACK这个东西你应该很熟悉了)。这里有个

东西要注意，因为TCP是双工的，也就是说，你可以想象一对TCP连接上有两条数据通路。当发送FIN报文

时，意思是说，发送FIN的一端就不能发送数据，也就是关闭了其中一条数据通路。被动关闭的一端发送

了ACK后，应用层通常就会检测到这个连接即将断开，然后被动断开的应用层调用close关闭连接。

我可以告诉你，一旦当你调用close(orclosesocket)，这一端就会发送FIN报文。也就是说，现在被动

关闭的一端也发送FIN给主动关闭端。有时候，被动关闭端会将ACK和FIN两个报文合在一起发送。主动

关闭端收到FIN后也发送ACK，然后整个连接关闭(事实上还没完全关闭，只是关闭需要交换的报文发送

完毕)，四次握手完成。如你所见，因为被动关闭端可能会将ACK和FIN合到一起发送，所以这也算不上

严格的四次握手---四个报文段。

在前面的文章中，我一直没提TCP的状态转换。在这里我还是在犹豫是不是该将那张四处通用的图拿出来，

不过，这里我只给出断开连接时的状态转换图，摘自<TheTCP/IPGuide>：

给出一个正常关闭时的winmp信息：

14:00:38.819856IPcd-zhangmin.1748>220.181.37.55.80:F1:1(0)ack1win65535

14:00:38.863989IP220.181.37.55.80>cd-zhangmin.1748:F1:1(0)ack2win2920

14:00:38.864412IPcd-zhangmin.1748>220.181.37.55.80:.ack2win65535

补充细节：

关于以上的四次握手，我补充下细节：

1.默认情况下(不改变socket选项)，当你调用close(orclosesocket，以下说close不再重复)时，如果

发送缓冲中还有数据，TCP会继续把数据发送完。

2.发送了FIN只是表示这端不能继续发送数据(应用层不能再调用send发送)，但是还可以接收数据。

3.应用层如何知道对端关闭？通常，在最简单的阻塞模型中，当你调用recv时，如果返回0，则表示对端

关闭。在这个时候通常的做法就是也调用close，那么TCP层就发送FIN，继续完成四次握手。如果你不调用

close，那么对端就会处于FIN_WAIT_2状态，而本端则会处于CLOSE_WAIT状态。这个可以写代码试试。

4.在很多时候，TCP连接的断开都会由TCP层自动进行，例如你CTRL+C终止你的程序，TCP连接依然会正常关

闭，你可以写代码试试。

特别的TIME_WAIT状态：

从以上TCP连接关闭的状态转换图可以看出，主动关闭的一方在发送完对对方FIN报文的确认(ACK)报文后，

会进入TIME_WAIT状态。TIME_WAIT状态也称为2MSL状态。

什么是2MSL？MSL即MaximumSegmentLifetime，也就是报文最大生存时间，引用<TCP/IP详解>中的话：“

它(MSL)是任何报文段被丢弃前在网络内的最长时间。”那么，2MSL也就是这个时间的2倍。其实我觉得没

必要把这个MSL的确切含义搞明白，你所需要明白的是，当TCP连接完成四个报文段的交换时，主动关闭的

一方将继续等待一定时间(2-4分钟)，即使两端的应用程序结束。你可以写代码试试，然后用netstat查看下。

为什么需要2MSL？根据<TCP/IP详解>和<TheTCP/IPGuide>中的说法，有两个原因：

其一，保证发送的ACK会成功发送到对方，如何保证？我觉得可能是通过超时计时器发送。这个就很难用

代码演示了。

其二，报文可能会被混淆，意思是说，其他时候的连接可能会被当作本次的连接。直接引用<TheTCP/IPGuide>

的说法：Thesecondistoprovidea“bufferingperiod”betweentheendofthisconnection

andanysubsequentones.Ifnotforthisperiod,

connectionscouldbemixed,creatingconfusion.

TIME_WAIT状态所带来的影响：

当某个连接的一端处于TIME_WAIT状态时，该连接将不能再被使用。事实上，对于我们比较有现实意义的

是，这个端口将不能再被使用。某个端口处于TIME_WAIT状态(其实应该是这个连接)时，这意味着这个TCP

连接并没有断开(完全断开)，那么，如果你bind这个端口，就会失败。

对于服务器而言，如果服务器突然crash掉了，那么它将无法再2MSL内重新启动，因为bind会失败。解决这

个问题的一个方法就是设置socket的SO_REUSEADDR选项。这个选项意味着你可以重用一个地址。

对于TIME_WAIT的插曲：

当建立一个TCP连接时，服务器端会继续用原有端口监听，同时用这个端口与客户端通信。而客户端默认情况

下会使用一个随机端口与服务器端的监听端口通信。有时候，为了服务器端的安全性，我们需要对客户端进行

验证，即限定某个IP某个特定端口的客户端。客户端可以使用bind来使用特定的端口。

对于服务器端，当设置了SO_REUSEADDR选项时，它可以在2MSL内启动并listen成功。但是对于客户端，当使

用bind并设置SO_REUSEADDR时，如果在2MSL内启动，虽然bind会成功，但是在windows平台上connect会失败。

而在linux上则不存在这个问题。(我的实验平台：winxp,ubuntu7.10)

要解决windows平台的这个问题，可以设置SO_LINGER选项。SO_LINGER选项决定调用close时，TCP的行为。

SO_LINGER涉及到linger结构体，如果设置结构体中l_onoff为非0，l_linger为0，那么调用close时TCP连接

会立刻断开，TCP不会将发送缓冲中未发送的数据发送，而是立即发送一个RST报文给对方，这个时候TCP连

接就不会进入TIME_WAIT状态。

如你所见，这样做虽然解决了问题，但是并不安全。通过以上方式设置SO_LINGER状态，等同于设置SO_DONTLINGER

状态。

断开连接时的意外：

这个算不上断开连接时的意外，当TCP连接发生一些物理上的意外情况时，例如网线断开，linux上的TCP实现

会依然认为该连接有效，而windows则会在一定时间后返回错误信息。

这似乎可以通过设置SO_KEEPALIVE选项来解决，不过不知道这个选项是否对于所有平台都有效。