Networking winsock和linux套接字之间的区别

我正在开发一个类似FTP的程序，将大量小文件下载到Xbox 360 devkit（使用Winsock）上，并将其移植到Playstation3（也是一个devkit，使用linux AFAIK）。该程序使用BSD样式的套接字（TCP）。两个程序都与同一服务器通信，下载相同的数据。程序以如下方式循环遍历所有文件：

for each file send(retrieve command) send(filename) receive(response) test response receive(size) receive(data) 对于每个文件 发送（检索命令） 发送（文件名） 接收（应答） 测试响应 接收（大小） 接收（数据） 在Xbox360上，整个下载需要1:27，最后一次发送和第一次接收之间的时间约为14秒。这对我来说似乎很合理

Playstation3实现对相同数据采用4:01。瓶颈似乎在最后一次发送和第一次接收之间，这占用了3:43的时间。网络和磁盘时间都明显少于Xbox 360

这两个devkit与我的PC位于同一个交换机上，我的PC提供文件服务，并且在该交换机上没有其他流量

我试过设置

TCP\u NODELAY

标志，但没有显著改变。我还尝试将

SO_SNDBUF

/

SO_RCVBUF

设置为625KB，这也不会显著影响时间

我假设Winsock和linux之间的TCP/IP堆栈实现存在差异；我是否可以设置一些套接字选项，使linux实现的行为更像Winsock？还有什么我没有解释的吗

唯一的解决方案似乎是重写它，以便它将所有文件请求一起发送，然后全部接收

---

不幸的是，索尼的实现没有TCP_CORK选项，所以我不能说这是否是区别。

你想要

TCP_CORK

。它将防止部分帧被发送，从而提高吞吐量（以延迟为代价），就像winsock一样

int v,vlen;
v=1; vlen=sizeof(v);
setsockopt(fd, IPPROTO_TCP, TCP_CORK, &v, &vlen);

设置

v=0

以在接收前刷新帧：

int v,vlen;
v=0; vlen=sizeof(v);
setsockopt(fd, IPPROTO_TCP, TCP_CORK, &v, &vlen);

---

在大多数Unix上，您可以通过使用

writev（）

或

sendfile（）

进一步提高吞吐量。…

Wireshark是您的朋友，嗅嗅嗅电线——查看每个数据包的顺序，看看是否能发现差异/问题

在高延迟链路上，您确实希望确保尽可能多地缓冲，以保持每个TCP数据包最大化

发送合并通常是个好主意。它仅在发送端有多个未确认的帧排队时触发。通常，只有当您知道自己在做什么并且系统提供了全面的缓冲时，才应该禁用此功能，否则禁用此功能肯定会对高延迟网络上的系统性能产生负面影响

---

对于最高吞吐量，缓冲区demarc应该是路径MTU的精确系数。

您使用哪种FTP模式，被动还是主动？另外，您会说“最后一次发送和第一次接收之间的时间大约为14秒。这对我来说似乎很合理。”我很惊讶等待14秒回复RETR命令是合理的，尤其是当PS3的时间更长时。