这里主要是这样的Qt写了一个服务端,在开发环境下,没出现任何问题,但在生产环境下,就出现问题了。 使用Fiddler的简单抓了下包: 发现Body只有27045,而请求里面确是这样的。 这里
这里主要是这样的Qt写了一个服务端,在开发环境下,没出现任何问题,但在生产环境下,就出现问题了。
使用Fiddler的简单抓了下包:
发现Body只有27045,而请求里面确是这样的。
这里就很有意思了。
这里的Qt服务端,在发送完数据后,会主动和客户端断开连接。不像其他的web服务器,需要等客户端来断开连接。
这里用curl请求会有报错:
transfer closed with 25527 bytes remaining to read大体上的意思就还有这么多位的数据没读,通道就被关闭了。
在Qt服务端关于关闭的代码是这样的:
tcpSocket->write(HttpResponse::message(json->toJson()).toUtf8());tcpSocket->waitForBytesWritten();
tcpSocket->disconnectFromHost();
并且这个tcpSocket->write的返回值,也是正确的,说明的确把要发送的数据送到了网卡中让其发送。并且waitForBytesWritten也是返回true的。
个人感觉主要的问题就是tcpSocket->waitForBytesWritten(),可能是Qt的一个BUG,我这里用的是5.5.1
感觉这里Qt做的没有我想象中的那样。
这里的解决办法有3个:
①数据分包发送,有些web服务器会把发送的数据分成几个包发送给客户端。这种方式就能解决上面的问题。
②简单修改下代码逻辑,比如改成了这样的:
qint64 writeSize = tcpSocket->write(HttpResponse::message(json->toJson()).toUtf8());qDebug() << "writeSize: " << writeSize;
if(!tcpSocket->waitForBytesWritten(10 * 1000)){
qDebug() << "error:" << tcpSocket->errorString();
}
if(!tcpSocket->waitForDisconnected(10 * 1000)){
tcpSocket->disconnectFromHost();
}
delete json;
delete tcpSocket;
③加一个waitForDisconnected()如下:
tcpSocket->disconnectFromHost();tcpSocket->waitForDisconnected();
建议优先用第三种,不行就再考虑第一种和第二种。